نقش فایروال‌ها در تکامل امنیت شبکه

همانطور که از ابتدای کار اینترنت، نرم‌افزار آنتی‌ویروس یکی از مفاهیم بنیادی امنیت PC بوده است، فایروال‌ها نیز یکی از مفاهیم بنیادی امنیت شبکه بوده‌اند.

امروزه، چشم‌انداز‌ برنامه‌های کاربردی و تهدیدات باعث شده است فایروال‌های مبتنی بر پورت قدیمی برای حفاظت از شبکه‌های سازمانی و داده‌های حساس ناکارآمد باشند. برنامه‌های کاربردی مجرایی هستند که همه‌چیز در آن جریان دارد؛ مسیری برای زندگی شخصی و کاری ما که مزایا و ریسک‌های خود را نیز دارند. این ریسک‌ها شامل تهدیدات جدید و نوظهور، نشت داده و عدم تطبیق‌پذیری هستند.

در این فصل نحوه کار فایروال‌های قدیمی و اینکه چرا نمی‌توانند به چالش‌های برنامه کاربردی و تهدیدات امروزی پاسخ دهند مطرح می‌شود و بیان می‌شود که مشکلات نشت داده و تطبیق‌پذیری چگونه امنیت شبکه و نیاز به یک فایروال بهتر را تعریف می‌کنند.

عدم کارآمدی فایروال‌های قدیمی به نسبت فایروال‌های نسل بعدی یا NGFW

یک فایروال در ساده‌ترین حالت خود، جریان ترافیک را بین یک شبکه معتمد (مثل یک LAN سازمانی) و یک شبکه عمومی یا غیرمعتمد (مثل اینترنت) کنترل می‌کند.  فایروال‌هایی که امروزه بیشتر از همه پیاده‌سازی می‌شوند مبتنی بر پورت (یا همان فیلترینگ Packet) یا نوعی از آن (مثل بررسی Stateful) هستند. دلیل محبوبیت این فایروال‌ها این است که کار کردن با آن‌ها و حفظ و نگهداری آن‌ها نسبتاً ساده است، معمولاً گران‌قیمت نیستند، توان عملیاتی بالایی دارند و بیش از دو دهه است که طراحی متداولی بوده‌اند.

در سرعت بالای عصر اینترنت، گذشتن تقریباً دو دهه بدین معنی است که فایروال‌های مبتنی بر پورت شبیه یک تکنولوژی قرون وسطایی هستند. در حقیقت امنیت شبکه معمولاً به ادوار تاریک شبکه می‌شود؛ Perimeter شبکه شبیه به دیوارهای یک قلعه است و یک فایروال مثل پلی متحرک دسترسی را کنترل می‌کند. مثل یک پل متحرک که یا بالا است یا پایین، فایروال مبتنی بر پورت هم برای کنترل ترافیک فقط دو گزینه دارد: اجازه دادن یا مسدود کردن.

فایروال‌های مبتنی بر پورت (و انواع آن‌ها) از آدرس‌های IP مبدأ/مقصد و اطلاعات پورت TCP/UDP استفاده می‌کنند تا مشخص شود که آیا یک Packet باید اجازه‌ی عبور بین شبکه‌های مختلف یا بخش‌های مختلف شبکه را داشته باشد یا خیر. فایروال چند بایت اول TCP Header را در یک IP Packet بررسی می‌کند تا پروتکل برنامه کاربردی تعیین شود؛ مثلاً SMTP (پورت ۲۵) و HTTP (پورت ۸۰).

اکثر فایروال‌ها طوری پیکربندی شده‌اند که اجازه دهند ترافیکی که از شبکه معتمد شروع می‌شود از شبکه غیرمعتمد عبور کند، مگر اینکه با یک قاعده‌ی مشخص مسدود شده باشد. مثلاً ممکن است Simple Network Management Protocol یا SNMP به‌طور مشخص مسدود شده باشد تا از منتقل شدن ناخواسته‌ی برخی از اطلاعات شبکه به اینترنت جلوگیری شود. این امر از طریق بلاک کردن پورت‌های ۱۶۱ و ۱۶۲ UDF، فارغ از آدرس IP مبدأ یا مقصد ممکن است.

کنترل پورت استاتیک نسبتاً آسان است. فایروال‌‌های بررسی Stateful به برنامه‌های کاربردی پویایی می‌پردازند که از بیش از یک پورت تعریف‌شده (مثل پورت‌هایFTP 20 و ۲۱) استفاده می‌کنند. وقتی که رایانه یا سروری روی شبکه‌ی معتمد یک Session را با رایانه یا سرور روی شبکه غیرمعتمد آغاز می‌کند، اتصالی ایجاد می‌گردد. روی فایروال‌های بررسی Packet به‌صورت Stateful، موقتاً یک قاعده‌ی پویا ایجاد می‌شود که امکان پاسخ‌ دادن را از رایانه یا سرور روی شبکه غیرمعتمد فراهم می‌کند. در غیر این صورت، ترافیک برگشتی باید به‌صورت واضحی مجاز باشد یا اینکه قواعد دسترسی باید به‌صورت دستی روی فایروال ایجاد شود (که کاربردی نیست).

تمام این مواردی در صورتی خوب کار می‌کنند که همه افراد طبق قانون رفتار کنند. متأسفانه این قواعد بیشتر مثل دستورالعمل هستند و همه‌ی افراد در اینترنت آن‌ها را رعایت نمی‌کنند.

امروزه اکثر ترافیکی که از شبکه‌های سازمانی عبور می‌کند مربوط به اینترنت است و این محدود به جستجو در وب نیست. اینترنت نسل جدیدی از برنامه‌های کاربردی را ایجاد کرده است که هم برای استفاده شخصی و هم کسب‌و‌کار توسط کاربران شبکه مورد استفاده قرار می‌گیرند. بسیاری از این برنامه‌های کاربردی به افزایش بهره‌وری کاربر و کسب‌و‌کار کمک می‌کنند، درحالی‌که برخی دیگر پهنای باند زیادی را مصرف می‌کنند، ریسک‌های امنیتی غیرضروری ایجاد می‌کنند و بدهکاری کسب‌و‌کار را افزایش می‌دهند؛ مثلاً به دلیل افشای داده و تطبیق‌پذیری که در ادامه به هر دو مورد پرداخته خواهد شد. همچنین بسیاری از این برنامه‌های کاربردی از تکنیک‌های «دسترس‌پذیری» استفاده می‌کنند تا از فایروال‌های مبتنی بر پورت فرار کنند؛ تکنیک‌هایی مثل استفاده از پورت‌های غیراستاندارد، Port-hopping و Tunneling.

مهندسان IT تلاش کرده‌اند نقص‌های موجود در فایروال‌های مبتنی بر پورت قدیمی را جبران کنند و برای این هدف یا آن‌ها را با پراکسی احاطه می‌کنند و یا از سیستم‌های پیشگیری از نفوذ، فیلترینگ URL و دستگاه‌های پرهزینه و پیچیده‌ی دیگر استفاده می‌کنند که همگی در چشم‌انداز تهدیدات و برنامه‌های کاربردی امروز ناکارآمد هستند.

نشت داده یک مشکل است

نشت‌ داده‌های حساس یا خصوصی به‌صورت عمومی و در مقیاس بزرگ بسیار متداول شده‌اند. مثال‌های زیادی از نشت داده‌ی تصادفی یا عمدی دائماً خبرساز می‌شوند و می‌بینیم که ده‌ها هزار شماره کارت اعتباری توسط فروشندگان بزرگ افشا می‌شود یا شماره‌های تأمین اجتماعی توسط آژانس‌های دولتی، سازمان‌های سلامت یا کارمندان لو می‌رود. مثلاً در دسامبر سال ۲۰۰۸، یک برنامه کاربردی اشتراک فایل Peer-to-Peer (P2P) که به‌درستی پیکربندی نشده بود، دیتابیس اطلاعات شخصی ۲۴۰۰۰ سرباز ارتش را در دامین عمومی افشا کرد. متأسفانه چنین حوادثی منفرد نیستند؛ مرکز پزشکی Walter Reed متعلق به ارتش آمریکا، یک پیمانکار ارتش آمریکا که روی Marine One کار می‌کرد و شرکت فایزر، همگی دچار چنین نقض‌های امنیتی شدیدی شده‌اند. در تمام این موارد، داده‌های حساس از طریق یک برنامه کاربردی افشا شده بود که به‌طور شفاف منع شده بود اما این ممنوعیت توسط تکنولوژی اجرایی نشده بود.

تکنولوژی‌های پیشگیری از نشت داده یا DLP شکل یک نوشدارو به خود گرفته‌اند و توجه بسیاری از سازمان‌های IT را جلب کرده‌اند. متأسفانه، با توجه به حوزه، سایز و طبیعت توزیعی اکثر Datasetهای سازمانی، فقط کشف کردن اینکه داده کجاست و چه کسی صاحب آن است چالش بسیار بزرگی است. به‌علاوه سؤالاتی در مورد کنترل دسترسی، گزارش‌گیری، دسته‌بندی داده، داده At-Rest در مقابل داده در حرکت، Agentهای دسکتاپ و سرور و رمزگذاری، این چالش را بزرگ‌تر می‌کنند. در نتیجه بسیاری از اقدامات DLP در سازمان‌ها به کندی پیش می‌روند و در نهایت موفقیت‌آمیز نیستند.

بسیاری از راهکارهای پیشگیری از دست رفتن داده سعی می‌کنند مقدار خیلی زیادی از عملکردهای امنیت اطلاعات را در راهکاری به کار بگیرند که خودش بسیار سنگین است (و حتی عناصری از مدیریت Storage را نیز دخیل کنند). نیاز به گفتن نیست که گسترده شدن این حوزه به پیچیدگی، زمان و هزینه (هم هزینه‌های مالی و هم زمان کارمندان) اضافه می‌کند. در نتیجه تکنولوژی‌های DLP معمولاً پردردسر هستند و ناکافی هستند (اکثراً روی وب و ایمیل تمرکز می‌کنند) و برای بسیاری از سازمان‌ها کارآمد نیستند. همچنین بسیار پرهزینه‌اند!

به‌علاوه، بسیاری از نقض‌‌های امنیتی اخیر که توسط برنامه‌های کاربردی اشتراک فایل P2P با پیکربندی نامناسب ایجاد شده‌اند را نمی‌شد توسط پیاده‌سازی‌های عادی تکنولوژی‌های DLP کنونی بازار پیشگیری کرد؛ زیرا کنترل برنامه‌های کاربردی مد نظر قرار نگرفته است.

برخی از سازمان‌ها باید یک پیاده‌سازی DLP را در مقیاس بزرگ انجام دهند که باید شامل بازیابی، دسته‌بندی و کاتالوگ‌بندی داده باشد. اما برای اکثر سازمان‌ها، کنترل کردن برنامه‌های کاربردی که برای افشای داده‌های حساس و متوقف کردن انتقال غیرمجاز داده‌های حساس یا خصوصی مثل شماره امنیت اجتماعی و کارت اعتباری مورد استفاده قرار می‌گیرند کافی است. اعمال این کنترل در محدوده‌ی اعتماد (Perimeter شبکه) ایده‌آل است؛ نقطه‌ی مرزبندی (Demarcation) می‌تواند بین داخل و خارج یا بین کاربران داخلی و منابع داخلی در دیتاسنتر باشد. فایروال در بهترین مکان قرار دارد و تمام ترافیک عبوری بین شبکه‌ها و بخش‌های مختلف شبکه را می‌بیند. متأسفانه، فایروال‌های مبتنی بر پروتکل و پورت قدیمی نمی‌توانند کاری در این مورد انجام دهند و نسبت به برنامه‌های کاربردی، کاربران و محتوا آگاهی ندارند. برای اینکه سازمان‌ها بتوانند با یک راهکار فایروال، به‌خوبی به نشت داده پاسخ دهند، باید:

• روی برنامه‌های کاربردی شبکه خود کنترل بدست آورند و مسیرهای نشت داده را محدود کنند
• برنامه‌های کاربردی را که می‌خواهند روی شبکه‌شان باشد اسکن کنند تا داده‌های حساس یا خصوصی پیدا شود
• درک کنند که کدام کاربران این تراکنش‌های برنامه کاربردی را ایجاد می‌کنند و چرا
• پالیسی‌ها و تکنولوژی‌های کنترل مناسبی را پیاده‌سازی کنند تا از نشت داده عمدی یا سهوی جلوگیری شود

اگر سازمان‌ها بتوانند جریان داده‌های حساس یا خصوصی را در Perimeter کنترل کنند، بسیاری از حوادث از دست رفتن داده که خبرساز می‌شوند قابل‌پیشگیری خواهند بود. متأسفانه، زیرساخت‌های امنیتی قدیمی برمبنای فایروال‌های قدیمی توانایی لازم را برای این کار ندارند.

تطبیق‌پذیری اختیاری نیست

باوجود بیش از ۴۰۰ قاعده در دنیا که امنیت اطلاعات و حفاظت از داده را الزامی کرده‌اند، سازمان‌ها برای بدست آوردن و حفظ تطبیق‌پذیری دچار چالش هستند. ازجمله این قواعد می‌توان به HIPAA ،FISMA ،FINRA و GLBA در ایالات‌متحده و EU Data Protection Act (DPA) در اروپا اشاره کرد.

اما شاید جالب باشد که اثرگذارترین و معروف‌ترین الزام امنیتی امروز، یک قانون دولتی نیست. استاندارد امنیت داده صنعت کارت اعتباری یا PCI DSS توسط برند‌های بزرگ کارت اعتباری (American Express، MasterCard، Visa و غیره) ساخته شد تا از شرکت‌ها، بانک‌ها و مصرف‌کنندگان در مقابل جعل هویت و استفاده تقلبی از کارت حفاظت گردد. ازآنجایی‌که اقتصادهای دنیا روزبه‌روز بیشتر روی تراکنش‌های کارت‌های اعتباری حساب می‌کنند، ریسک از دست رفتن داده‌های صاحبان کارت افزایش پیدا خواهد کرد و این امر باعث خواهد شد که تلاش برای حفاظت از داده ضروری باشد؛ فارغ از اینکه این تلاش‌ها برمبنای تطبیق‌پذیری است یا خیر.

PCI DSS برای هر کسب‌و‌کاری که کارت‌های اعتباری را منتقل، پردازش یا ذخیره می‌کند، فارغ از تعداد یا مقدار تراکنش‌های پردازش‌شده، قابل‌اعمال است.

شرکت‌هایی که این امر را اجابت نکنند ممکن است به دلیل تخلفات کوچک مشمول جریمه‌های سنگینی تا ۲۵۰۰۰ دلار در ماه برای شوند و برای تخلفاتی که منجر به از دست رفتن یا سرقت داده‌های مالی شود، مشمول حداکثر ۵۰۰۰۰۰ دلار جریمه و از دست دادن اختیار پردازش کارت شوند که باعث می‌شود عملکرد کسب‌و‌کار تقریباً غیرممکن شود.

بااینکه الزامات تطبیق‌پذیری تقریباً به‌طور کامل مبتنی بر بهترین راهکارهای امنیت اطلاعات هستند، مهم است به یاد داشته باشیم که امنیت و تطبیق‌پذیری یکسان نیستند. فارغ از اینکه آیا یک کسب‌و‌کار با PCI تطبیق‌پذیری دارد یا غیر، نقض امنیتی داده می‌تواند بسیار پرهزینه باشد. بنا به تحقیقات انجام شده توسط موسسه Forrester، هزینه‌ی هر ثانیه نقض امنیتی (شامل جریمه‌ها، هزینه پاک‌سازی، فرصت‌های ازدست‌رفته و غیره) بین ۹۰ دلار برای یک شرکت کوچک و  تا ۳۰۵ دلار برای یک شرکت بزرگ متغیر است.

امنیت و تطبیق‌پذیری به هم مرتبط هستند، اما یکسان نیستند!

نسخه ۱.۲ از PCI DSS شامل ۱۲ الزام عمومی و بیش از ۲۰۰ الزام اختصاصی است. از بین این ۱۲ الزام، موارد زیر به‌طور خاص به فایروال مرتبط هستند:

الزام ۱: نصب و حفظ یک پیکربندی فایروال برای حفاظت از داده‌های دارنده کارت

الزام ۵: استفاده و به‌روزرسانی منظم نرم‌افزار یا برنامه‌های آنتی‌ویروس

الزام ۶: توسعه و حفظ سیستم‌ها و برنامه‌های کاربردی ایمن

الزام ۷: ایجاد محدودیت برای داده‌های دارنده کارت بنا به نیاز

الزام ۱۰: ردیابی و نظارت روی منابع و شبکه و داده‌های دارنده کارت

ضمیمه F: برای استفاده از بخش‌بندی شبکه جهت کاهش حوزه‌ی PCI DSS، یک نهاد باید سیستم‌هایی را که داده‌های دارنده کارت را ذخیره، پردازش یا منقل می‌کنند از سایر شبکه جداسازی کند.