بحث پیچیدگی کلاً جالبه علی‌الخصوص در شبکه؛ تاجایی که خوندم و شنیدم اولین بار بحث Complexity رو آقای David Mayer مطرح کرد و حتی برای این موضوع در IRTF هم یک Working-group بنام Network Complexity Research Group درنظر گرفته شد. امیدوارم به مرور بتونم بیشتر راجبش بخونم، بهفمم و بیشتر بنویسم.
اولین مطلب در این بحث رو با امنیت شبکه و کارهایی که میکنیم تا جلوی مخاطرات امنیتی رو بگیریم شروع میکنم.
روز به روز ابزارهای جدید امنیتی تولید می‌شن و با کلی تبلیغات و به‌به و چه‌چه روونه‌ی بازار. و از دست بد روزگار گاهی بدون برنامه و با توهم اشتباه اینکه این ابزار مشکلات امنیتی‌مون رو حل میکنه، سریع میایم قوی‌ترین فایروال‌ها و آنتی،ویروس‌ها و … خرید میکنیم و یکجوری می‌گنجونیم توی شبکه. حالا هزینه‌های فجیعی که در خرید و نصب و راه‌اندازی میشه که هیچ… از برگزاری منافصه گرفته تا هزینه‌ی مشاور و ناظر و خرید و اجرا و نگهداری و … نمیدونم، گاهی فکر میکنم شاید این بحث‌های صرفه‌جوئی در هزینه و کاهش هزینه‌ها و … فقط حرف هست علی‌الخصوص در سازمانها و شرکت‌های بزرگ، بالاخره بودجه‌اش یجوری میرسه یا یکی میرسونه یا یکی میخواد و میرسونَدِش 🙂
اما ای دریغ که بزرگترین مشکلات امنیتی انقدر بزرگ هستند که دیده نمیشن! و حتی گاهی همون پیچیدگی‌ها به ندیدنشون دامن می‌زنه.
یکی از اولین قدم‌های امنیت اطلاعات، فرهنگ‌سازی در سازمانه؛ در معماری کلان فناوری اطلاعات یک سازمان حتماً باید آموزش‌هایی ساده جهت آشنایی و روش‌های جلوگیری از درز اطلاعات برای کاربران خیلی معمول درنظر گرفته بشه. مثل اینکه اطلاعات سازمانی رو روی نرم‌افزارهای چت نباید رد و بدل کرد، نباید روی سرویس‌های ثالث مثل Google Drive و Dropbox و … گذاشت و ازین قبیل موارد.
قطعاً در کنار این موارد هم باید یکسری سیاست‌های امنیتی و بقولی Enforcement وجود داشته باشه؛ مثلاْ محدود کردن پورت‌های USB، اجبار استفاده از رمز مناسب، محدود کردن دسترسی به اینترنت برای کاربران و سرورها، گذردادن ترافیک اینترنت از یک پروکسی و …
راهکارهای سخت‌افزاری و نرم‌افزاری امنیتی جزو ملزومات هستن اما باید مراقب بود که طراحی پیچیده نشه؛ جوری نباشه که اگه ساعت ۲ شب با مهندس شیفت تماس گرفته شد سرش رو بکوبونه به میز و نتونه بفهمه مشکل کجاس.
مثلا یک اتفاقی که خیلی جدیداً شنیده میشه اینه که کلاً بیایم و ترافیک مدیریتی شبکه، ترافیک دیتای داخلی، ترافیک اینترنت و .. رو بطور فیزیکی از هم جدا کنیم. متاسفانه خودم هم دوبار همچین طرحی رو مجبور شدم که بنویسم… خب این کار در کنار هزینه‌های سرسام‌آوری که داره، پیچیدگی‌های خاص خودش رو هم خواهد داشت؛ قبلاً شما داشتین فقط یک شبکه رو نگهداری می‌کردین اما حالا چند شبکه! قبول دارم که بعضی سناریوهای خاص لازمه اما نه اینکه همه‌گیر بشه این کار.
در عمده‌ی شبکه‌های بسیار گسترده، تمام این ترافیک‌ها روی یک بستر فیزیکی هستن اما خب طبعاً با استفاده از راه‌کاری‌های مختلف امنیتی که گاهش شامل مجازی‌سازی هم میشه مثل درنظرگرفتن VLAN مجزا (بله VLAN هم نوعی راه‌کار مجازی‌سازی محسوب میشه) یا VRF مجزا (بحث مجازی‌سازی شبکه هم بسیار شیرین هست و سر فرصت خودش انشاالله راجبش می‌نویسم)
احتمالاً همچین اتفاقی رو خیلیا شاهدش بودن:
هیچوقت یادم نمیره زمانی که وارد بازار کار شدم و در اولین کارم بعنوان یک ادمین مشغول شده بودم، تصمیم گرفتیم که سیاست‌های رمزگذاری در شبکه تعیین کنیم (Password Policy). بعد از کلی مشقات تاییدیه گرفتیم و اجرا شد.
یک روز رفته بودم واحد حسابداری برای فیش حقوقی ام که دیدم یکی از کارمندای حسابداری نام کاربری و رمز ورودش به سیستم حسابداری رو روی برگه نوشته و به خیال خودش کلی امنیت به خرج داده بود و چسبونده بود زیر کیبورد!
می‌بینین؟ فرهنگ‌سازی!
چندسال قبل یک شرکت امنیتی بنام AlgoSec از متخصصان امنیت شبکه نظرخواهی کرده بود و یکی از نتایج جالب اون این بود که بیش از نصف این متخصصین اظهار داشتن پیچیدگی‌های امنیتی و تعدد Security Policy ها بالاخره یک موقعی منجر به درز اطلاعات یا قطعی سرویس شده بوده! حالا بیایم و چندتا فایروال بگذاریم پشت سرِ هم 🙂
نمیخوام وارد بحث معماری و طراحی شبکه و امنیت شبکه بشم اما صرفا در رابطه با همین مورد چند فایروال از شرکت های مختلف: برای یه شبکه معمول، خیلی ساده میشه پیشنهاد کرد که در لایه‌ی ارتباط با اینترنت از یک Firewall (چشم، دیواره‌ی آتش) و یک IPS (سیستم پیشگیری از نفوذ) استفاده کرد که خیلی rule های کلی داشته باشند و از وندور A باشن؛ و حالا در لایه‌های درونی‌تر (برای شبکه‌های بزرگ تر با block های مختلف) از فایروال‌های وندور B با رول‌های خاص و بقولی specific استفاده بشه.
فراموش نکنیم که یک شبکه باید مستندسازی بشه، و پر واضحه که مستندسازی یک شبکه با سیاست‌های امنیتی پیچیده چقدر سخت خواهد بود. اگر میخواین Complexity رو از امنیت شبکه اتون دور کنین، بعد از اینکه این مطلب رو خوندین (و اگر دوس داشتین نظرتون رو گفتین و عضو خبرنامه شدین 🙂 ) برین سراغ مستندسازی شبکه. انشاالله که وجود داره اما اگر نیست، بوجود بیارین.
نه تنها همین مستندسازی باید بروزرسانی بشه، بلکه سیستم‌ها هم باید پس از طی شدن روند حصول اطمینان از پایداری نسخه‌ی جدید، بروزرسانی بشن. کم نبوده نشت اطلاعاتی که بخاطر عدم بروزرسانی یک سیستم‌عامل یا نرم‌افزار رخ داده.
بنظرم پیچیدگی بدترین دشمن امنیت اطلاعات هست! من معتقدم هر چیزی در زندگی باید به اندازه باشه؛ شبکه و امنیت شبکه هم اگر زندگیِ ما نباشه، فارغ از اون نیست.
من بشدت علاقمند به RFC1925 هستم؛ این RFC به زبون ساده 12 حقیقت/قانونِ دنیایِ شبکه رو مطرح میکنه و آخرین قانونِ اون خیلی نزدیک به این بحث هست:
وقتی دیگه ویژگی‌ای برای “اضافه کردن” باقی نمونده، به این معنی نیست که طراحی [پروتکل] به کمال رسیده؛ بلکه زمانی که دیگه چیزی برای کم‌کردن نیست به نقطه‌ی کامل‌بودن نزدیک شده.
حرف زیاد است و مجال کم. لطفاً نظرتون رو بگین و تجربیاتتون درباره‌ی پیچیدگی‌های امنیتی بنویسین.
ضمناً به نصیحت برخی دوستان پیرو همه‌گیر شدن تلگرام در ایران، کانالی برای وبلاگ ایجاد کردم که با عضو شدن میتونین براحتی از مطالب جدید مطلع بشین. ID کانال networkz هست؛ میتونین براحتی با کلیک کردن در اینجا کانال رو ببنین.
بسيار زيبا ، منتظر مقاله هاي مفيد بعدي شما هستيم مهندس جان !!
ممنون مهندس. لطف دارین به بنده.
بسیار عالی بود
اول که خوب در سازمانهایی در ایران که برون سپاری شده سیاست اصلی سازمان ( کاری با نحوه انتخاب اون پیمانکار نداریم) متاسفانه این قضیه خریدن برند های مختلف و ایجاد پروژه های مختلف (برای ایجاد سود آوری) به پیچیدگی شبمه خیلی بیشتر اضافه کرده !!
اما در کل بعضیا فکر می کنند هرچه این شبکه رو بیشتر بپیچوننش خوب نفوذ بهش سخت تر میشه ! در صورتی که همیشه راه های ساده تری هم هست برای نفوذ
اما بحث شیرن مستند سازی خوب اصولا اینجوریه که خیلی وقتا یه تبی شروع می شه و شروع می کنن نقشه شبکه رو میکشن و یه سری داکیومنت در میاد اما بروز نگه داشتن اون مستندات بسیار مهمه ! متاسفانه برای Automation کردن بروز رسانی ها یا حداقل اینکه از حالت فایل word و visio خارج کردنش من فقط netbrain رو پیدا کردم ! که نمیدونم آیا اونقدر خوب هست که بتونم سیستم رو قانع کنم برای خرید لایسنسش ؟!
خیلی دوست دارم راجع به نحوه مستند سازی استاندارد ! و بروزرسانی اون توی سازمان های بزرگ مثل AT and T که شما آشنای دارید به اون سیستم هم بگین تا ما هم اینجا استفاده کنیم
سلام. ممنون از اینکه نظر و تجربه ات رو نوشتی مهندس.
متاسفانه، متاسفانه های زیادی وجود داره اما فکر میکنم بالاخره درست میشه. سختیش صد سال اوله.
در بحث مستندساز خودکار، مجموعه های خیلی گسترده که خودشون نوآور هستن، نیازشون رو خودشون تولید میکنن و AT&T هم از این مورد مستثنی نیست. آمازون هم همینطوره.
اما برای پروژه ها و مشتری هایی که علاقه ندارند محصول AT&T رو استفاده کنن طبعا رو آورده میشه به سولوشن های موجودی. مثلا نمونه ی معروفش NetBrain هست.
اما، اونم یک اما ی بزرگ، اینکه همیشه یک دید انسانی نیاز هست تا چک و تایید کنه.
یک کار دیگه که خیلی جاها انجام میشه اینکه مثلا از یک نرم افزار Open-source مثلا Zabbix استفاده میکنن و براش یکسری Plug-in مینویسن که خودکار یکسری مستندات Generate کنه. یا مثلا با استفاده script های خیلی ساده یک ابزاری درست میکنن که به اصطلاح شبکه رو walk کنه و یک گرافیست تولید کنه. نمونه هاش زیاده و بستگی داره به خلافت اون Engineer و تقاضای مشتری. برادرم اتفاقا خیلی ازین کارا میکنهً
کلا، بحث Automation در شبکه با پیشروی SDN و… خیلی داره جلو میره اما خیلی باید مراقب بود بنظرم. یک نمونه ساده میگم برای همین بحث امنیت. یک مهندس امنیت میاد یکسری Automation ایجاد میکنه برای جلوگیری از حملات یا انجام یکسری Action های خاص در زمان بروز یک حمله؛ اما این خیلی مهمه که بدونیم اون Automation از خودش هوش خاصی نداره و محدوده به تفکر و Policy هایی که به ذهن اون شخص رسیده. پس باید یکی دوره ای این ابزار رو از لحاظ کارایی و صحت عملکرد و… چک کنه.
ممنون.
درود بر شما بسیار عالی–واقعا که چیزی برای کم کردن ندارد
سلام. ممنون از اینکه سر زدید. لطف دارید.
سلام محمد جان
اما جدا از دید کلی و منطقی – بحث آگاهی رسانی های امنیت سایبری و فرآیند های مستمر منطبق با ایزو وزن بیشتری نسبت به تجهیزو دیگر مسال فنی داره : با تشکر
سلام. ممنون از اینکه سر زدین.
دقیقا موافقم. همه ی حرف من در این مطلب هم اینه که اول فرهنگ سازی و و ایجاد آگاهی و در کنارش سعی در دوری جستن از پیچیدگی.
به دعوت جناب دریا از سیسکو به پارسی این مقاله رو خوندم. و اما تجربه من بطور خیلی خلاصه:
به همراه یک ادمین مایکروسافتی در دانشگاه. کمی بعد از مستند سازی تمام توپولوژی از دو منظر سزویس و امنیت، هر دو اخراج و یک ادمین به جای ما دو نفر از فک و فامیل جناب رییس جایگزین شد. ایشان به اصول بسیار ابتدایی شبکه و اکتیو دایرکتوری اشنا بودند. بعد از ما با مطالعه و سعی و خطا اندکی تغییرات غیر بهینه و غیر لازم بوجود اوردند. تنها یاور ایشان برای به ثمر نشاندن سعی و خطا و کسب تجربه شون این بود که از قبل مستندات ما رو داشتند. مشابه این موضوع برای یک از هم ردیفان و هم قطاران خودم هم پیش آمد، البته در یک ادراه دولتی نسبتا بزرگ.
معایب آشکار کردن مستندات و در پی اون عدم پیچیدگی:
صد البته فرض می گیرم شما مسند سازی رو بلد هستید و برای خودتون انجام می دید. مستند سازی هم پروسه هست و هم پروژه. باید یک روال منظم ، پیش رونده باشه. هم خود اتکا باشه و هم ادمین دخیل باشه. به هر حال:
با مستند سازی و آشکار کردنش:
الف – شما حاصل تجارب و سعی و خطای خودتون رو مجانی در اختیار دیگران می ذارید. دیگرانی که ممکنه یک ادمین کار کشته نباشن و این اطلاعات حتی براشون مضر هم باشه.
ب – شما کانفیگ و ظرایف تنظیمات عددی و جایگاه مکانی رول هاتون رو لو می دید. به این ترتیب خلاقیت خودتون رو لو می دید. بسیاری از تنظیمات به لحاظ عددی محاسبه و مرتبط به هم هستند و با اندکی تغییر در اونها ممکنه نتایج بسیار بسیار متغیر بشه. همچنین اکثر رول های فایروالی و همچنین برخی از کانفیگ های دیگه در اثر مرور زمان رشد می کنن. توسعه پیدا می کنن و بهینه می شن. با اشکار کردن اونها یک پیشینه دراز مدت رو در اختیار دیگران میزارید و فرصت انتقاد ات بی اساس رو به اونها میدید. همچنین به احتمال خیلی زیاد از این به بعد باید دایما به دنبال توجیه و اثبات خودتون باشید.
ج – موقعیت شغلیتون رو در خطر جدی قرار می دید.
د – به کار فرما حق و حقوق اضافی اعطا می کنید. منظورم مواردی مثل پسورد و و اینها نیست. این که ادمینی پسورد بزاره و نگه و از شرکت بره نامردی هست. من اینو نمی گم. منظورم بعد آموزشی ای هست که بعد از شما از روی کانفیگتون تحصیل می شه. کارفرما هزینه کرده شما با دانش خودتون شبکه رو سر پا نگه دارید. اما بعد از رفتن شما مگه شما مسیول برپا موندن شبکه هستید که بنا باشه تمام اطلاعات و زحمات شما سالها باقی بمونه؟ من معتقدم دست به کانفیگ نباید زد. اینها حق کارفرما بوده. اما این که بزاری لو بره که چی کار ها کردی یا نه، این حماقته.
ه – همانطور که خودتون وقتی جای جدیدی می رید به به چه چه نمی کنید از اعمال ادمین قبلی، دیگری هم میاد از کانفیگ شما بهره لازمه رو می بره و در نهایت پشت سرتون هم می زنه. به همین راحتی.
ز – فرصت بهینه سازی پویا رو از خودتون می گیرید و در عوض به دیگران این فرصت رو هدیه می دید.
مستند سازی شبکه درست مثل یک نقشه گنج پنهان هست که هر چه شما بهش نزدیک تر میشی نقشه کاملتر می شه. اگر دوست دارید از این نقشه دیگران هم بهره ببرند به خودتون مربوطه. اما من دوست دارم خودم گنج خودمو پیدا کنم.
در مورد کاهش پیچیدگی امنیتی هم حرف برای گفتن زیاد دارم. اما خلاصه تمام صحبت من این هست که اگر چه با پیچیدگی بیشتر در امنیت، چلنج و درگیری بیشتر می شه و حتی موقع به هم ریختن اوضاع، این پیچیدگی مضر هست، اما اگر واقعا دوست دارید امنیت مقبول تری داشته باشید نباید بزارید کسی بدونه این امنیت از چه طرقی کسب شده.
متشکرم که مطالعه کردید.
سلام.
خیلی ممنون از اینکه سر زدید و تجربیاتتون رو به اشتراک گذاشتین. سعی میکنم در حد توانم خوب پاسخ بدم.
اول از همه خیلی متاسفم از اتفاقی که براتون در اون دانشگاه افتاده. بنده هم حداقل 3 بار چنین تجربه ای رو داشتم و کاملاً بهتون حق میدم. متاسفانه این همون فرهنگ اشتباهی هست که امیدوارم روزی اصلاح بشه و اتفاقاً هدفم در این وبلاگ این هست تا اندکی در حد توان و سوادم دیدگاهی که در سایر کشورها باعث پیشرفتشون شده رو نشر بدم همراه با برداشت های شخصی خودم.
مستندسازی در اغلب استانداردها همونطور که فرمودید به عنوان یک پروسه دیده میشه و حتی پروسه هایی در قالب Document Lifecycle Management وجود داره.
الف – خب این مورد نباید مجانی باشه. کسی که مستندسازی میکنه برای کارش باید حقوق “مناسب و صحیح” بگیره. متاسفانه قبول دارم که در ایران این مورد هم تحت تاثیر همون بحث فرهنگ هست. اما از لحاظ اخلاقی وقتی کاری رو قبول میکنیم و براش قراردادی امضا میکنیم موظف هستیم که سعیمون رو بکنیم که بهتری خروجی رو ارائه بدیم و در کار شبکه معمولاً این خروجی مستندسازی هم داره. البته در محیط های role خاصی بعنوان مستندساز هم وجود داره. در رابطه با اینکه برای یک ادمین ضعیف مضر هست کاملا قبول دارم و چه بسی باعث Data Breach هم بشه؛ ولی این مورد باید در پروسه های سازمانی دیده بشه. برای همین هست که معمولاً مستندات دارای کد Confidentiality هستن.
ب، ج، د – این فرمایشتون هم متاسفانه مجدداً بر میگرده به همون بحث فرهنگ کاری و سازمانی…
ه – همانند مورد قبلی. در خارج از کشور اغلب اوقات شخص جدید وقتی وارد میشه ایراد نمیگیره، بلکه میگه حتماً صلاح یا علتی بوده براش (قطعا همیشه افراد با اخلاق های دیگری وجود دارن اما عمدتاً فرهنگ کاری این اجازه رو نمیده). یا خیلی راحت میگن اشتباهی بوده و باید اصلاح بشه. اغلب نامی از شخصی برده نمیشه، چون هدف پیدا کردن مشکل و حل بهینه ی مشکل یا کلاً بهینه سازی یک بستر هست نه اینکه دنبال مقصر گشتن.
ز – همانند موارد قبل
من حس میکنم متاسفانه شما تجربه‌های بدی از مستندسازی داشتید و کاملاً درکتون میکنم. اما نظر شخصی من اینه که باید از خودمون شروع کنیم و سعی کنیم این فرهنگ و تفکر رو نشر بدیم و الا وضعیت همینی هست که میمونه. تفکر شما اتفاقاً تفکر شاید بیشی از متخصصین شبکه ای هست که من در کشور در پروژه های متعدد ملی کار کردم. با احترام، فکر میکنم اشتباهه. در یک پروژه ی ملی یا یک سازمان بزرگ با سرویس های حساس، این که اطلاعات رو پیش خودمون نگه داریم باعث ضربه های بزرگ به اون سازمان، و از همه مهم تر مردم میشه. همینطور که عرض کردم خودم هم از مستندسازی و حتی Knowledge Transfer به مشاور بعدی یا زمانی که بعنوان کارشناس شبکه کار میکردم به کارشناس بعدی، ضربات زیادی خوردم، اما این ضربات سد راهم نشد و باعث شد بیشتر تلاش کنم و با عقیده ای که بهش ایمان داشتم راهم رو ادامه بدم. و وقتی از بالا نگاه میکنم نه تنها باعث ضررم نشده بلکه حس میکنه در مسیری که تا الان طی کردم همین خیلی کمک کننده بوده.
اتفاقا بنظر باید به این فکر کرد که پس فردا یکی بیاد و بگه: “کی بوده مشاور/کارشناس/ادمین قبلی این سازمان که یک مستندسازی درست درمون نکرده از کارا.”
ضمناً همیشه باید “کسی” رو مشخص کرد که منظور کی هست. اگر منظور همکاران در یک تیم هست، یا مدیر اون تیم، یا مشاور یا هرکسی که در پروسه‌ها اجازه‌ی دسترسی به اون “نقشه‌ی پنهان گنج” داده شده، پس مشکلی نیس. البته و صد البته که باید تمام دسترسی به مستندات هم روال AAA داشته باشه و Audit بشه. البته اینا همه برمیگرده به Scale اون سازمان و اینکه تا چه حد همچین سیاست های نیاز هست که خودش یک داستان دیگه اس.
مجدداً ممنونم از وقتی که صرف کردین و امیدوارم، امیدوارم که با تلاش هم، و شروع از خود، روزی برسه که همه با خیال راحت و بدون واهمه از امنیت شغلی، و در یک سیستم با اندک پروسه های مشخص، کار کنن.
موفق باشین.
من واقعا شوکه شدم از این دیدگاه شما. بنظرم شما خیلی به فکر خودتون هستید و منافع خود را کاملا به منافع دیگران ترجیح می دهید. بیخود نیست وضعیت امروز شبکه های کشور این هست.
من یک ادمین تازه کار هستم اما قرار نیست که همیشه تازه کار بمونم. مطالعه می کنم و یاد میگیرم. قرار هم نیست تا زمانی که به چیزی مسلط نیستم کاری انجام بدهم که باعث اختلال گردد. اما اگر همکارانی چون شما داشته باشم احتمالا به زودی دلسرد خواهم شد.
منظورم به صحبت های آقای امیری بود.
سلام مهندس
در رابطه با امنيت كاملا با حرف شما موافقم ما هميشه فكر مي كنيم امنيت را مي شود خريد و نصب كرد حداقل مديران اين طور فكر مي كنند در صورتي كه امنيت مانند دايره هاي دوار هست كه چرخ ش انها هميشگي ست و ما داءما مي بايست به جاي اضافه كردن بي مورد سروريس هاي جديد امنيت شبكه سياست هاي امنيت شبكه را بروز نماييم
به عنوان يك شاگرد اگر بخوام توصيه اي بكنم اين هست كه ما بايد از تجربيات موفق ITIL , ISMS در سازمانها استفاده كنيم
سلام.
ممنون از اینکه سر زدید و نظرتون رو به اشتراک گذاشتین.
موفق باشید.