حوزه معماری امنیت به طراحی و پیاده‌سازی زیرساخت‌ها و سیستم‌های امن می‌پردازد و حدود ۱۸٪ از آزمون +CompTIA Security را تشکیل می‌دهد. در این فصل به اصول معماری شبکه، رمزنگاری و PKI، امنیت ابر و سایر مباحث طراحی امن خواهیم پرداخت.
طراحی شبکه‌ی امن و بخش‌بندی (Secure Network Design)
معماری امن شبکه با بخش‌بندی (Segmentation) و تعریف محدوده‌های امنیتی آغاز می‌شود. ایده این است که بخش‌های مختلف شبکه با سطح اعتماد متفاوت، از هم جدا شوند تا نفوذ به یک بخش، کل شبکه را به خطر نیندازد. چند مفهوم کلیدی در این زمینه:
ناحیه غیرنظامی (DMZ):
یک شبکه نیمه‌امن که بین شبکه داخلی امن و اینترنت قرار می‌گیرد. سرورهایی که باید از اینترنت قابل دسترسی باشند (مثل وب‌سرورهای عمومی، سرورهای ایمیل) در DMZ قرار داده می‌شوند. دیوارآتش ترافیک ورودی اینترنت را تنها به DMZ اجازه می‌دهد و از DMZ به شبکه داخلی نیز ترافیک شدیداً محدود می‌شود. به این ترتیب اگر یک سرور DMZ هک شود، مهاجم برای رسیدن به داده‌های داخلی راه دشوارتری در پیش دارد و می‌توان نفوذ را در همان DMZ مهار کرد.
تفکیک شبکه داخلی:
حتی داخل شبکه سازمان نیز می‌توان سطوح مختلف اعتماد تعریف کرد. برای مثال، شبکه بخش مالی از شبکه میهمانان یا شبکه تولید (OT) جدا باشد. VLANها در سوئیچ‌ها امکان ایجاد شبکه‌های محلی مجازی مجزا روی یک بستر فیزیکی را می‌دهند. معمولاً VLANهای مختلف توسط روتر یا فایروال داخلی از هم جدا و ترافیک بین‌شان پالایش می‌شود. همچنین مفهوم Micro-Segmentation در مراکز داده امروزی (خصوصاً محیط‌های ابری و مجازی) اشاره به ایجاد بخش‌های بسیار جزئی‌تر با استفاده از فایروال‌های توزیع‌شده دارد که ارتباط بین ماشین‌های مجازی را نیز کنترل می‌کند.
طراحی لایه‌ای و توپولوژی امنیتی:
در معماری شبکه، معمولاً لایه‌بندی مشخصی تعریف می‌شود: محیط (Perimeter) شامل فایروال مرزی و IDS/IPS، لایه DMZ برای سرویس‌های بیرونی، لایه داخلی برای کاربران و سرورها، و شاید Subnetهای ویژه برای مدیریت. هر لایه سیاست‌ها و کنترل‌های خاص خود را دارد. برای نمونه، یک شبکه مدیریتی مجزا ممکن است برای دسترسی به سوئیچ‌ها، روترها و سرورها تعریف شود که فقط ادمین‌ها از طریق آن و با VPN یا IPهای خاص بتوانند وارد دستگاه‌ها شوند.
به‌کارگیری این روش‌ها مطابق اصول معماری امنیتی از جمله اصل مرزهای شفاف است که می‌گوید هرچه مرزبندی و چیدمان ترافیک شفاف‌تر باشد، کنترل آن آسان‌تر است. همچنین اصل تحمل خرابی (Fail-Safe) باید رعایت شود؛ یعنی سیستم‌ها طوری طراحی شوند که در صورت بروز خطا یا مشکل، به حالت امن بروند (مثلاً اگر فایروال دچار مشکل شد، به طور پیش‌فرض تمام ترافیک را مسدود کند نه اینکه همه را عبور دهد).
امن‌سازی تجهیزات و پروتکل‌های شبکه
بخش مهمی از معماری امنیتی، سخت‌سازی (Hardening) خود تجهیزات شبکه (سوئیچ، روتر، فایروال) و امن کردن پروتکل‌های ارتباطی است:
سخت‌سازی تجهیزات:
این شامل به‌روزرسانی منظم Firmware دستگاه‌ها، تغییر کلمات عبور پیش‌فرض مدیریتی، غیرفعال کردن سرویس‌های نااستفاده (مثلاً غیرفعال کردن رابط‌های مدیریت وب اگر از SSH استفاده می‌کنید)، محدودسازی آدرس‌های مجاز برای دسترسی مدیریتی (مثلاً فقط IP ادمین)، استفاده از پروتکل‌های امن مدیریتی (SSH به جای Telnet، SNMPv3 به جای v1/v2)، و تقسیم شبکه مدیریت از داده است. همچنین برقراری احراز هویت دو مرحله‌ای برای دسترسی مدیران (اگر دستگاه پشتیبانی کند) و استفاده از سرور متمرکز (مانند TACACS+ یا RADIUS) جهت احراز هویت ادمین‌های تجهیزات توصیه می‌شود.
پروتکل‌های امن:
به عنوان معمار امنیت باید نسخه‌های امن پروتکل‌ها را انتخاب کنید. به طور مثال، استفاده از SSH به جای Telnet برای ارتباط راه دور رمزنگاری‌شده؛ استفاده از TLS 1.2/1.3 به جای نسخه‌های قدیمی SSL/TLS برای رمزنگاری ترافیک وب؛ جایگزینی FTP خام با SFTP یا FTPS برای انتقال فایل؛ استفاده از HTTPS برای تمامی صفحات وب. همچنین پروتکل‌های سطح پایین شبکه مانند ARP و DNS که ذاتی امن نیستند را می‌توان با مکانیزم‌هایی امن‌تر کرد (مثلاً DNSSEC برای افزودن امضای دیجیتال به پاسخ‌های DNS به منظور تضمین یکپارچگی آنها).
شبکه‌های بی‌سیم امن:
در طراحی وایرلس سازمانی، انتخاب روش‌های احراز هویت و رمزنگاری قوی حیاتی است. پروتکل قدیمی WEP به هیچ عنوان امن نیست؛ باید از WPA2 یا ترجیحاً WPA3 استفاده شود. WPA2 با حالت Enterprise (استفاده از 1X و سرور RADIUS) امنیت بیشتری نسبت به حالت Pre-Shared Key دارد و برای شبکه‌های سازمانی توصیه می‌شود. برای جلوگیری از حملات جعل نقطه دسترسی (Evil Twin)، می‌توان از گواهی‌های دیجیتال سمت سرور و احراز هویت مشتری مبتنی بر گواهی (EAP-TLS) استفاده کرد تا کاربر شبکه‌ی جعلی را تشخیص دهد.
زیرساخت کلید عمومی و رمزنگاری (PKI & Cryptography)
رمزنگاری یکی از ارکان معماری امنیتی است که در سطوح مختلف به کار گرفته می‌شود، از رمزنگاری دیسک سخت در یک لپ‌تاپ گرفته تا ارتباطات TLS در اینترنت. زیرساخت کلید عمومی (PKI) به مجموعه‌ای از سخت‌افزار، نرم‌افزار، سیاست‌ها و رویه‌ها برای مدیریت کلیدهای عمومی/خصوصی و گواهی‌های دیجیتال گفته می‌شود. نکات مهم این بخش:
- الگوریتم‌ها و کاربردها: رمزنگاری به دو دسته کلی متقارن و نامتقارن تقسیم می‌شود. الگوریتم‌های متقارن (مثل AES، 3DES) از یک کلید مشترک برای رمزنگاری و رمزگشایی استفاده می‌کنند – سریع هستند و برای حجم زیاد داده (مانند رمزنگاری کل دیسک یا ارتباط VPN) به کار می‌روند. الگوریتم‌های نامتقارن (مثل RSA، ECC) از یک جفت کلید خصوصی/عمومی استفاده می‌کنند – کلید عمومی برای رمز کردن یا تأیید امضا و کلید خصوصی برای رمزگشایی یا ایجاد امضای دیجیتال. این‌ها سنگین‌تر هستند و عمدتاً برای توزیع کلید (مثلاً در آغاز ارتباط TLS برای تبادل کلید نشست) یا امضای دیجیتال و احراز هویت کاربرد دارند. ترکیب این دو نوع در بسیاری از پروتکل‌ها دیده می‌شود: مثلاً در SSL/TLS از RSA/ECDHE برای تبادل کلید متقارن جلسه و سپس AES یا CHACHA20 برای رمزنگاری ترافیک استفاده می‌شود.
- گواهی‌های دیجیتال: در PKI هر کاربر/سرور می‌تواند یک گواهی دیجیتال 509 داشته باشد که شامل کلید عمومی او و اطلاعات هویتی است و توسط یک مرجع صدور گواهی (CA) معتبر امضا شده است. این امضا تضمین می‌کند که مرورگر یا سرویس گیرنده می‌تواند به صحت انتساب کلید عمومی به هویت مذکور اعتماد کند. مثلاً گواهی SSL یک وب‌سرور را یک CA مورد اعتماد امضا می‌کند تا مرورگر مطمئن شود به سایت واقعی متصل است نه جعلی. گواهی‌ها انواع مختلف دارند: گواهی‌های سرور SSL/TLS، گواهی‌های امضای کد نرم‌افزار، گواهی‌های کاربر/سازمانی برای ایمیل امن (S/MIME) و … .
- ساختار PKI سازمانی: یک سازمان می‌تواند PKI داخلی داشته باشد. این معمولاً شامل یک Root CA (مرجع ریشه) است که کاملاً امن نگه داشته می‌شود، و یک یا چند مرجع زیرمجموعه (Intermediate CA) که صدور گواهی‌های نهایی را بر عهده دارند. سیاست‌ها مشخص می‌کنند چه نوع گواهی با چه طول عمری و برای چه منظورهایی صادر شود. لیست ابطال گواهی (CRL) یا پروتکل آنلاین OCSP برای اعلان گواهی‌های باطل‌شده (مثلاً در صورت لو رفتن کلید خصوصی) استفاده می‌شود. برای آزمون، آشنایی با مفاهیم CRL، OCSP، Stapling (الحاق وضعیت OCSP به گواهی) و مفهوم Pinning (محدود کردن CAهای قابل قبول برای یک سرویس) مفید است.
- مدیریت کلیدها: چرخه عمر کلیدهای رمز را باید درنظر گرفت – از تولید امن، توزیع به افراد مجاز، انقضاء و تجدید، تا ابطال و امحاء نهایی. استانداردهایی مانند NIST SP 800-57 راهنمایی برای دوره عمر بهینه کلیدها ارائه می‌دهند (مثلاً کلید AES 256 بیتی می‌تواند حجم بسیار زیادی داده را امن کند اما بهتر است کلیدهای جلسه‌ی TLS مرتب نوسازی شوند تا حملات احتمالی بر یک جلسه به بقیه سرایت نکند). همچنین مدیرت امانت‌سپاری کلید (Key escrow) در سازمان‌هایی که نیاز دارند نسخه‌ای از کلید خصوصی رمزنگاری کاربران برای موارد قانونی نگهداری شود (با ملاحظات حقوقی) مطرح است.
امنیت سیستم‌ها و مجازی‌سازی
در معماری امنیت باید امنیت سیستم‌عامل‌ها، پایگاه‌داده‌ها و محیط‌های مجازی نیز لحاظ شود:
سخت‌سازی سرورها و کلاینت‌ها:
پیش‌تر در مورد سخت‌سازی صحبت کردیم. به صورت خلاصه، برای هر سرور (ویندوز یا لینوکس) چک‌لیست امن‌سازی وجود دارد: غیرفعال‌کردن سرویس‌های پیش‌فرض غیرضروری، به‌روزرسانی‌ها، تنظیم دقیق مجوزهای فایل‌ها، فعال کردن فایروال داخلی (مثلاً Windows Defender Firewall)، تنظیم مکانیزم‌های نظارتی (مانند Audit Policy در ویندوز یا auditd در لینوکس)، استفاده از آنتی‌ویروس/EDR و غیره. برای پایگاه‌داده‌ها نیز اقداماتی چون استفاده از حساب‌های کاربری با حداقل مجوز برای اپلیکیشن‌ها، غیرفعال کردن حساب‌های پیش‌فرض (مثلاً SYSTEM در Oracle)، و رمزنگاری اتصال و داده‌های حساس (Transparent Data Encryption) توصیه می‌شود.
مجازی‌سازی و containerها:
در دیتاسنترهای مدرن، ماشین‌های مجازی (VM) و کانتینرها رایج‌اند. امنیت مجازی‌ساز (Hypervisor) اهمیت بالایی دارد، چرا که نفوذ به Hypervisor یا فرار از VM می‌تواند کل سرور فیزیکی و همه VMهای روی آن را در معرض خطر قرار دهد. به‌روز نگه داشتن نرم‌افزار Hypervisor و اعمال اصول حداقل دسترسی در دسترسی‌های مدیریتی آن (مثلاً جدا کردن شبکه مدیریتی vCenter/ESXi از شبکه‌های معمول) ضروری است. همچنین در محیط‌های Container مانند Docker/Kubernetes، باید تصدیق کرد که Image کانتینر عاری از بدافزار و آسیب‌پذیری هستند (با اسکن‌های امنیتی تصاویر)، جداسازی مناسب بین کانتینرها برقرار است (از قابلیت‌های AppArmor/SELinux یا Seccomp برای محدودسازی دسترسی کانتینر استفاده شود)، و Secret keys (مانند کلید APIها) به طور امن مدیریت شوند (مثلاً در Kubernetes از مکانیزم Secrets به جای قرار دادن مستقیم در فایل‌های پیکربندی).
پردازش ابری (Cloud Security):
بسیاری از سازمان‌ها به زیرساخت‌های ابری مهاجرت کرده‌اند یا ترکیبی هیبریدی دارند. معمار امنیت باید با مدل‌های ابری (IaaS, PaaS, SaaS) و مسئولیت‌های امنیتی هر کدام آشنا باشد. در IaaS (مثل AWS EC2 یا Azure VM)، تأمین‌کننده زیرساخت فیزیکی و هایپروایزر را امن می‌کند ولی پیکربندی سیستم‌عامل و شبکه مجازی بر عهده مشتری است. در PaaS، مشتری مسئول امنیت اپلیکیشن و داده است و در SaaS بیشتر مسئولیت‌ها با ارائه‌دهنده سرویس است (هرچند کاربر همچنان مسئول مدیریت درست دسترسی‌ها و پیکربندی‌های فراهم‌شده است). در معماری ابری باید از سرویس‌های امنیتی داخلی پلتفرم بهره برد؛ مثلاً در AWS از Security Groupها (فایروال‌های مجازی)، AWS Config (برای انطباق پیکربندی)، CloudTrail (لاگ حسابرسی) و سرویس‌های مدیریت کلید (KMS) استفاده شود. اصل حداقل دسترسی در تعریف نقش‌های دسترسی کاربران به منابع ابری (AWS IAM roles) نیز اهمیت وافری دارد.
توسعه امن و امنیت اپلیکیشن‌ها
بخشی از معماری امنیتی مربوط به نحوه توسعه نرم‌افزارهای سازمان است. هر چند جزئیات توسعه نرم‌افزار، بیشتر در آزمون +Security به صورت مفاهیم کلی مطرح می‌شود، اما موارد زیر حائز اهمیت است:
چرخه توسعه امن (Secure SDLC):
تلفیق فعالیت‌های مرتبط با امنیت در هر مرحله از توسعه نرم‌افزار. از فاز طراحی (انجام تحلیل ریسک تهدیدات نرم‌افزار با روش‌هایی مثل Threat Modeling)، تا پیاده‌سازی (استانداردهای کدنویسی امن)، تست (انجام تست‌های امنیتی اتوماتیک و دستی)، استقرار (سخت‌سازی محیط اجرای نرم‌افزار، کانفیگ امن سرورهای وب/اپلیکیشن) و در نهایت نگهداشت (پایش برای آسیب‌پذیری‌های جدید، اعمال به‌روزرسانی‌ها).
اصول کدنویسی امن:
برخی اصول شامل: اعتبارسنجی ورودی‌ها در سمت سرور (جلوگیری از SQLi، XSS)، مدیریت خطا و استثنا به گونه‌ای که اطلاعات فنی به کاربر داده نشود (افشای اطلاعات پنهان نشود)، عدم ذخیره اطلاعات حساس به صورت متن واضح (رمزنگاری یا حداقل هش کردن رمزهای عبور با الگوریتم‌هایی مانند bcrypt همراه با salt)، محافظت در برابر حملات زمان‌بندی‌شده یا رقابتی (مثلاً استفاده صحیح از قفل‌ها برای جلوگیری از Race Condition) و استفاده از توکن‌های ضد-CSRF. همچنین توسعه‌دهندگان باید از توابع/کتابخانه‌های ناامن پرهیز کنند (برای مثال در زبان C، استفاده از توابع امن‌تر به جای strcpy/strncpy).
وابستگی‌های نرم‌افزار و آسیب‌پذیری‌های زنجیره تأمین:
امروزه اکثر برنامه‌ها از کتابخانه‌های Third Party زیادی استفاده می‌کنند. یک بخش از ایمن‌سازی معماری نرم‌افزار، مدیریت وابستگی‌ها است – یعنی رصد مداوم کتابخانه‌های استفاده‌شده برای کشف آسیب‌پذیری‌های اعلام‌شده (مثلاً اگر یک کتابخانه جاوا اسپرینگ آسیب‌پذیری روزصفر دارد، سریع به نسخه امن‌تر ارتقا یابد). ابزارهای ترکیب نرم‌افزار (Software Composition Analysis) در این زمینه به طور خودکار اعلام خطر می‌کنند. همچنین باید فقط از مخازن رسمی و معتبر کتابخانه‌ها استفاده شود تا خطر تزریق کد مخرب در زنجیره تأمین کاهش یابد.
تست و ارزیابی امنیتی نرم‌افزار:
پیش از استقرار یک سامانه‌ی مهم، انجام تست نفوذ اپلیکیشن یا ارزیابی امنیتی کد توصیه می‌شود. ممکن است در آزمون از اصطلاح DevSecOps بشنوید که یعنی ادغام عملیات امنیتی در چرخه CI/CD توسعه. برای مثال، راه‌اندازی Pipelineای که در آن پس از بیلد نرم‌افزار، به‌طور خودکار ابزارهای SAST و DAST اجرا شوند و اگر نقص بحرانی یافت شد، انتشار متوقف گردد. این فرهنگ “Shift Left” در امنیت، ریسک ورود باگ‌های امنیتی به محصول نهایی را کاهش می‌دهد.
ابزارهای مرتبط با معماری امنیتی
برخی ابزار و فناوری‌های قابل ذکر در این حوزه عبارت‌اند از:
فایروال‌های نسل بعد (NGFW):
این فایروال‌ها علاوه بر فیلتر بسته‌ها بر اساس آدرس/پورت (لایه ۳ و ۴)، قابلیت شناسایی کاربردها و محتوا را نیز دارند (لایه ۷). به عنوان مثال، NGFW می‌تواند تشخیص دهد ترافیک روی پورت 80 مربوط به اپلیکیشن Facebook است و بنا به سیاست، آن را مسدود کند. یا دارای IPS یکپارچه هستند که الگوهای حملات شناخته‌شده را در ترافیک تشخیص می‌دهند. در معماری‌های جدید، NGFWها در مرز شبکه، بین VLANهای داخلی حساس، و حتی به صورت مجازی در رایانش ابری به کار گرفته می‌شوند.
سیستم‌های شناسایی نفوذ (IDS/IPS):
این‌ها جزو ضروریات معماری شبکه امن‌اند. IDSها در حالت تشخیص (Passive) الگوهای مشکوک را گزارش می‌دهند؛ IPSها به محض کشف یک حمله اقدام (Drop یا Reject) می‌کنند. ابزارهای معروف: Snort/Suricata (IDS/IPS متن‌باز برای شبکه) و OSSEC (IDS میزبان‌محور برای لاگ‌ها).
سیستم‌های مدیریت اطلاعات و رویدادهای امنیتی (SIEM):
در فصل ۴ به تفصیل می‌آیند، اما ذکرشان در معماری نیز مهم است. SIEM با جمع‌آوری لاگ‌ها از تمامی تجهیزات و اعمال کورلیشن (هم‌بستگی) میان رویدادها می‌تواند حملاتی را که از دید یک سیستم پنهان می‌مانند، آشکار کند. معمار امنیت باید نقاط Telemetry مناسب (مانند ارسال لاگ VPN، فایروال، سرورها و … به SIEM) را طراحی کند تا دید کافی حاصل شود.
راهکارهای کنترل دسترسی شبکه (NAC):
NAC سیستمی است که پیش از اجازه دسترسی یک دستگاه به شبکه سازمان، وضعیت امنیتی آن را می‌سنجد. برای مثال با NAC می‌توان الزام کرد که لپ‌تاپ مهمان یا کارمند، حتماً آنتی‌ویروس فعال و پچ‌های به‌روز داشته باشد، در غیر این صورت به شبکه قرنطینه هدایت شود تا رفع مشکل. NACها همچنین احراز هویت 1X را برای اتصال کلاینت به سوییچ/وای‌فای انجام می‌دهند. از محصولات این حوزه می‌توان Cisco ISE یا Aruba ClearPass را نام برد.
سوالات نمونه فصل ۳ (به همراه پاسخ تشریحی)
سوال 1: شرکت کوچکی می‌خواهد چندین زیردامنه‌ی وب‌سایت خود (مانند blog.example.com, shop.example.com) را با هزینه کمتر و مدیریت آسان امن‌سازی کند. کدام نوع گواهی دیجیتال برای این منظور مناسب‌ترین است؟
A. گواهی Self-Signed جداگانه برای هر زیردامنه
B. گواهی‌های منفرد صادره توسط CA برای هر زیردامنه
C. یک گواهی Wildcard از یک مرجع معتبر
D. گواهی EV (Extended Validation) صادره توسط CA داخلی شرکت
پاسخ: گزینه C صحیح است. یک گواهی Wildcard (مثلاً *.example.com) می‌تواند تمامی زیردامنه‌های example.com را پوشش دهد و توسط یک CA معتبر صادر می‌شود. این راه‌حل مقرون‌به‌صرفه است زیرا تنها یک گواهی خریداری و نصب می‌شود و زیردامنه‌های جدید نیز تحت همان گواهی امن خواهند بود. گزینه A (خودامضا برای هر زیردامنه) امن نیست چون مرورگرها به گواهی خودامضا اعتماد ندارند و اخطار امنیتی می‌دهند. گزینه B (گواهی‌های جداگانه برای هر زیردامنه) از نظر امنیت مشکلی ندارد ولی هزینه و پیچیدگی مدیریت چند گواهی را به همراه دارد. گزینه D (گواهی EV داخلی) نادرست است زیرا EV Certificateها را فقط CAهای عمومی معتبر صادر می‌کنند و EV صرفاً سطح تأیید هویت بالاتر است؛ ضمن اینکه EV همیشه دامنه کاملاً مشخص را پوشش می‌دهد و Wildcard EV موجود نیست. برای شرکت کوچک، گواهی Wildcard انتخاب بهینه است که در منابع آزمون نیز به آن اشاره شده.
سوال 2: مدیر شبکه تصمیم دارد جهت ارتقاء امنیت شبکه محلی، VLANهای مجزایی برای بخش‌های مالی، IT و مهمان ایجاد کند. کدام‌یک از موارد زیر برای تکمیل این معماری و کاهش ریسک حرکات جانبی مهاجم توصیه می‌شود؟
A. استفاده از روتر برای مسیردهی بین VLANها بدون هیچ‌گونه فیلترینگ
B. تنظیم یک فایروال یا ACL بین VLANهای داخلی برای کنترل ترافیک بین بخش‌ها
C. فعال کردن پروتکل‌های مدیریت خودکار VLAN مانند VTP بر روی تمامی سوئیچ‌ها
D. تجمیع همه VLANها در یک VLAN واحد هنگام ارتباط با اینترنت
پاسخ: گزینه B صحیح است. پس از بخش‌بندی به کمک VLANها، تعریف ACL یا قرار دادن فایروال بین VLANها ضروری است تا ارتباطات بین بخش‌های مختلف محدود به موارد مجاز شود. این کار باعث می‌شود حتی اگر مهاجمی به یکی از بخش‌ها نفوذ کرد، به‌راحتی نتواند به بخش دیگر دسترسی پیدا کند (حرکت جانبی محدود می‌شود). گزینه A (مسیردهی بدون فیلترینگ) عملاً VLANها را بی‌اثر کرده و شبکه را دوباره تخت می‌کند. گزینه C (فعال‌سازی VTP) حتی می‌تواند خطرناک باشد چون یک پروتکل مدیریتی است که اگر درست ایمن نشود، امکان دستکاری VLANها توسط مهاجم را می‌دهد – در هر حال ربطی به کنترل ترافیک بین VLANها ندارد. گزینه D (تجمیع VLANها برای اینترنت) معنی دقیقی ندارد؛ هر VLAN می‌تواند مستقلاً به روتر اینترنت وصل شود یا ترجیحاً با NAT مرکزی از طریق فایروال به اینترنت متصل گردند، اما «تجمیع در یک VLAN» توصیه نمی‌شود چون جداسازی امنیتی را از بین می‌برد.
نکات مهم فصل ۳ (High-Yield Points)
- بخش‌بندی شبکه: با تفکیک شبکه به مناطق امن متفاوت (اینترانت، DMZ، شبکه مهمان و …) سطح حمله را کاهش دهید. DMZ برای سرویس‌های خارجی ضروریست. یادگیری اینکه چه سرویس‌هایی در DMZ قرار می‌گیرند و چه ترافیکی بین DMZ و داخل/اینترنت مجاز است، مهم است. هر اتصال غیرضروری بین بخش‌ها یک ریسک است – در آزمون ممکن است از شما بپرسند کدام پورت‌ها/سرویس‌ها باید بین یک سرور وب در DMZ و دیتابیس داخلی باز باشد (مثلاً فقط پورت SQL از DMZ به DB).
- اصول طراحی امن: حداقل امتیاز، دفاع در عمق، نقطه شکست امن، ساده‌سازی از اصول معماری‌اند. به‌طور مثال اصل کلاس‌بندی داده‌ها می‌گوید داده‌ها را بر مبنای حساسیت‌شان دسته‌بندی کنید (Public, Internal, Confidential, Secret) و کنترل‌های متناسب هر سطح را اعمال کنید. همچنین اصل اعتماد صفر (Zero Trust) – به خاطر بسپارید که آزمون به آن توجه دارد – یعنی هیچ segment شبکه یا دستگاه یا کاربری صرفاً به خاطر موقعیتش قابل اعتماد کامل نیست و باید همیشه راستی‌آزمایی شود.
- PKI و کاربردهای آن: PKI فقط درباره وب‌سایت‌ها نیست؛ گواهی‌ها در احراز هویت دوسویه کلاینت-سرور (مثلاً 1X EAP-TLS)، در امضای کد نرم‌افزار (Code Signing Certificate)، در امضای اسناد PDF (Certificate Authority داخلی برای امضای دیجیتال کارمندان) و حتی در زیرساخت‌های رمزنگاری ایمیل (PGP, S/MIME) کاربرد دارند. مفهوم Chain of Trust (زنجیره اعتماد از Root CA به گواهی نهایی) و تفاوت انواع CA (public vs private) را بدانید. همچنین بدانید OCSP چگونه جایگزین لیست ابطال برای چک کردن فوری اعتبار گواهی استفاده می‌شود.
- انواع حملات مرتبط با معماری: برخی تهدیدات سطح معماری عبارت‌اند از: حملات VLAN hopping (سوءاستفاده از پیکربندی نادرست سوییچ‌ها برای خروج از VLAN)، ARP Spoofing و DHCP Spoofing (قابل پیشگیری با پروتکل‌هایی مثل Dynamic ARP Inspection و DHCP Snooping در سوییچ‌های مدیریت‌شده)، تضعیف پروتکل‌ها (مثل Downgrade Attack که مهاجم سعی می‌کند ارتباط امن را به نسخه ناامن بکشاند – جلوگیری: غیرفعال کردن نسخه‌های قدیمی SSL/TLS)، و Cloud-specific attacks (مثل سرقت کلیدهای API ذخیره‌شده در مخازن کد). آشنایی مختصر با این‌ها مفید است تا بتوانید در سناریوهای چندگزینه‌ای، گزینه حمله مرتبط/مقابله مناسب را تشخیص دهید.
- ابزارهای معماری: از ابزارها/تکنولوژی‌های خاص این حوزه در آزمون غافل نشوید: فایروال‌های وب (WAF) که ترافیک HTTP را فیلتر می‌کنند و مقابل حملات وب (SQLi, XSS) می‌ایستند، دروازه‌های امن ایمیل (SEG) برای فیلتر اسپم/بدافزار ایمیل، CASB برای نظارت و کنترل دسترسی به سرویس‌های ابری SaaS، SAN/NASهای ذخیره‌سازی با قابلیت رمزنگاری، و TPM/HSM برای نگهداری امن کلیدهای رمزنگاری در سخت‌افزار. ممکن است آزمون مستقیماً نپرسد «CASB چیست»، اما در یک سوال ترکیبی دانستن نقش آن کمک می‌کند گزینه درست را تشخیص دهید.
