دسترسی VPN به VLAN: پیش از قواعد، ماتریس را بسازید
نقش‌ها در یک طرف، سرویس‌ها در طرف دیگر. پنج بررسی، طراحی مبهم دسترسی VPN به VLAN را به جدولی تبدیل می‌کند که مالک فایروال می‌تواند اجرا کند.
با ماتریس شروع کنید، نه با سینتکس فایروال. جدولی که نقش‌ها در یک طرف آن و سرویس‌ها در طرف دیگر است را می‌توان مالک یک برنامه بازبینی کند، مالک امنیت درباره‌اش بحث کند و هر کسی که دروازه را در دست دارد پیاده‌اش کند. این بازبینی از عیب‌یابی قواعدی که هیچ‌کس بر آن توافق نکرده ارزان‌تر است.
یک ساعت نوشتنش بعداً یک هفته باستان‌شناسی قواعد را صرفه‌جویی می‌کند. طراحی از این می‌گوید که چه کسی به کدام سرویس می‌رسد، و همین بخشی است که از شماره‌گذاری دوباره جان سالم به در می‌برد.
گام 1: پیش از شبکه‌ها، نقش‌ها را نام ببرید
از آدم‌ها شروع کنید، نه از سوئیچ. هر گروهی را که از راه دور وصل می‌شود بنویسید و همان یک جمله‌ای را که می‌گوید آن گروه چه می‌کند، مثل کارکنان انبار که سطح موجودی را می‌خوانند یا پیمانکاری که یک یکپارچه‌سازی را نگهداری می‌کند. اگر دو گروه دسترسی یکسانی بگیرند، برای این منظور یک نقش‌اند.
اگر نقشی فقط به‌خاطر یک چارت سازمانی وجود دارد، همین‌جا بایستید. نقشی که نیاز سرویس متمایزی ندارد به ردیفی از خانه‌های یکسان تبدیل می‌شود، و ردیف‌های یکسان کسی را وسوسه می‌کنند که بعداً برای راحتی یک زیرشبکه کامل اعطا کند. بر اساس کاری که آدم‌ها می‌کنند تقسیم کنید، نه بر اساس کسی که هزینه‌هایشان را امضا می‌کند. شش نقش برای یک دفتر کوچک معمولاً زیاد است و سه اغلب درست است.
گام 2: هر خانه را به یک گزاره سرویس تبدیل کنید
خانه‌ای که «برنامه‌ها» می‌گوید قابل آزمون نیست. خانه‌ای که می‌گوید «HTTPS به میزبان ERP روی 443، از استخر کارکنان» قابل آزمون است. هر نام شبکه را با یک مقصد، یک پروتکل و یک درگاه جایگزین کنید، سپس وابستگی‌ای را اضافه کنید که سرویس بدون آن کار نمی‌کند، مثل حل‌کننده داخلی یا ارائه‌دهنده هویت.
| Check | Passes when | Stop if |
|---|---|---|
| Destination named | Host and port appear in the cell | Cell names a VLAN or a subnet |
| Direction stated | Initiator and responder are both clear | Cell implies two-way access |
| Dependency listed | DNS or identity path is explicit | Whole infrastructure range is granted |
| Negative case written | At least one denied pair is recorded | Only allow rules exist |
ستون جهت گران‌ترین اشتباه‌ها را می‌گیرد. اجازه به کارکنان برای باز کردن یک برنامه به معنای اجازه به سرورهای برنامه برای باز کردن اتصال برگشتی به لپ‌تاپ کارکنان نیست، و قاعده‌ای باحالت که جهت اول را مجاز می‌کند اغلب طوری خوانده می‌شود که گویی دومی را هم مجاز می‌کند.
گام 3: تصمیم بگیرید هویت کجا به سیاست تبدیل می‌شود
کسی باید یک نشست تأییدشده را به نقشی تبدیل کند که دروازه می‌تواند اعمالش کند. گزینه‌های پشتیبانی‌شده شامل سیاست گروهی است که بک‌اند احراز هویت ارائه می‌دهد، ویژگی‌های نشست مورد اعتماد، یا استخرهای نشانی جداگانه برای هر نقش. هر سه کار می‌کنند؛ برچسبی که کلاینت می‌فرستد کار نمی‌کند. مکانیزمی را انتخاب کنید که دروازه شما مستند کرده، نه آن یکی که یک پست انجمن توصیف می‌کند.
اختصاص نشانی‌ای که فقط به نظر می‌رسد متعلق به یک VLAN است، همان بی‌پاسخ در لباس دیگر است. راهنمای Netgate برای قواعد فایروال OpenVPN این تفکیک را روشن می‌کند: اجازه دادن به بالا آمدن تونل تصمیمی متفاوت از اجازه دادن به عبور ترافیک از آن است.
بنویسید کدام مکانیزم را انتخاب کردید و کجا پیکربندی شده است. وقتی نقشی تغییر می‌کند، آن یادداشت تفاوت بین یک ویرایش و جست‌وجو در سه رابط است. همچنین به حساب‌رس می‌گوید اول کجا را نگاه کند.
گام 4: مراقب نشانی مبدأیی باشید که مقصد می‌بیند
سیاست ارسال باید در مرز با مبدأ واقعی همخوانی داشته باشد. اگر دروازه کلاینت‌های VPN را به نشانی خودش ترجمه می‌کند، هر فایروال پایین‌دستی یک مبدأ می‌بیند و توانایی تصمیم‌گیری بر اساس نقش را از دست می‌دهد. اگر نشانی کلاینت را حفظ کند، مسیر بازگشت باید برای آن استخر وجود داشته باشد.
پیش از نوشتن قواعد نهایی هر دو جهت را آزمون کنید، سپس مبدأ مشاهده‌شده را کنار هر خانه ثبت کنید. همان بررسی را از دو نقش متفاوت اجرا کنید و نتیجه را مقایسه کنید. اگر هر دو نشانی دروازه را نشان دهند، تمایز نقش‌ها از قبل از دست رفته است. ماتریسی که نشانی‌های حفظ‌شده را فرض می‌کند در حالی که دروازه ترجمه مبدأ انجام می‌دهد، در نخستین ACL پایین‌دستی شکست می‌خورد.
گام 5: پیش از تحویل هر خانه را آزمون کنید
هر خانه مجاز را به یک عملیات نماینده و هر خانه ممنوع را به یک حالت منفی تبدیل کنید. هر دو را از یک کلاینت در نقش واقعی اجرا کنید، نه از کنسول دروازه، چون کنسول مسیری را که آزمون می‌کنید دور می‌زند.
# allowed: staff role reaches the ERP endpoint
curl -sS -o /dev/null -w '%{http_code}\n' --max-time 5 https://erp.internal.example/health
# denied: the same role must not reach a management host
nc -vz -w 3 10.30.5.11 22
# observed source address at the destination
sudo tcpdump -ni any 'tcp port 443 and host 10.30.20.15'حالت منفی‌ای که وصل می‌شود یک یافته است، نه یک تصادف، و تا زمانی که قاعده اصلاح نشود جای آن در ماتریس به‌عنوان خانه شکست‌خورده است. فرمان‌های آزمون را کنار جدول نگه دارید تا بازبین بعدی آن‌ها را دوباره اجرا کند نه اینکه استدلال را از نو بسازد.
جدول تمام‌شده بیشتر از دروازه‌ای که برایش نوشته شده عمر می‌کند. قواعد با فریمور و فروشنده تغییر می‌کنند، اما ردیفی که می‌گوید پیمانکاری به یک سرویس پروژه می‌رسد تا وقتی آن کار تغییر کند درست می‌ماند.