ترانزیت رمزنگاری‌شده به دسترسی به اپراتور نمی‌انجامد

دو دروازهٔ تأییدشده ترافیک شبکه‌ای با اعتماد پایین‌تر را از روی یک شبکهٔ انتقال محدود عبور می‌دهند. رمزنگاری بار مفید آن را برای ناظران عادی ترانزیت ناخوانا نگه می‌دارد و این همان بخشی است که مردم اول طراحی می‌کنند و بعد دیگر به آن فکر نمی‌کنند. آنچه رمزنگاری انجام نمی‌دهد این است که تعیین کند طرف کم‌اعتماد به کدام منابع دسترسی دارد. طراحی به دو مرز نیاز دارد: یکی پیرامون گفتگوی منتقل‌شده و دیگری پیرامون دسترسی به خود اپراتور.

مراحل زیر را به ترتیب اجرا کنید و هر شکستی را در هر مرحله به‌عنوان تغییری در طراحی ببینید، نه تنظیمی در پیکربندی.

هر دو مرز را پیش از دست‌زدن به پیکربندی تعریف کنید

مرز نخست گفتگوست: کدام جفت دروازه می‌توانند تونل بسازند و کدام ترافیک درونی اجازهٔ عبور از آن را دارد. مرز دوم اپراتور است: میزبان‌های کم‌اعتماد بیرون از تونل به کدام نشانی‌ها و سرویس‌ها دسترسی دارند. تیم‌ها معمولاً نخست را می‌سازند و دومی را از هر مسیریابی که از قبل وجود داشته به ارث می‌برند و این‌گونه یک طراحی محدود بی‌صدا به طراحی گسترده تبدیل می‌شود. همین ارث‌بری علت ریشه‌ای معمول است وقتی بازبینی نشان می‌دهد میزبان کم‌اعتمادی با چیزی سخن می‌گوید که هیچ‌کس تأییدش نکرده است.

هر دو را به‌صورت فهرست‌هایی از نشانی‌ها، درگاه‌ها و جهت‌ها بنویسید. اگر فهرستی نوشتنی نیست، مرز هنوز تعریف نشده است.

گام 1: تونل بیرونی را محدود کنید

روی رابط رو به اپراتور فقط آنچه تونل لازم دارد را مجاز کنید: IKE روی UDP 500 و 4500 میان دو نشانی دروازه، و ESP جایی که عبور NAT به کار نمی‌رود. هر چیز دیگری را که به این رابط می‌رسد رد کنید، از جمله پروتکل‌های مدیریت. مشخصات ESP خدمات حفاظتی را پوشش می‌دهد؛ اما چیزی دربارهٔ اینکه دروازه‌ها می‌توانند از کدام سرویس‌های خود اپراتور استفاده کنند نمی‌گوید. آن را به‌صورت فهرست مجاز صریح بیان کنید تا سرویس تازه‌منتشرشدهٔ اپراتور به‌طور پیش‌فرض در دسترس نشود.

این همان مجموعه‌قواعدی است که طراحی را به طراحی ترانزیت تبدیل می‌کند، نه به یک ترتیب همتا به همتا.

آن را از طرف کم‌اعتماد بررسی کنید، نه از کنسول دروازه. میزبان آن‌جا باید حتی پیش از بالا آمدن تونل هم در رسیدن به سرور DNS اپراتور شکست بخورد.

گام 2: تصمیم بگیرید دروازهٔ دور چه چیزی تحویل می‌دهد

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

نموداری که در رمزگشایی موفق متوقف می‌شود، مهم‌ترین تصمیم را جا انداخته است.

گام 3: مالکیت را در هر لایه نگه دارید

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

برای هر لایه مالکی تعیین کنید. لایه‌های بی‌مالک همان‌هایی هستند که منحرف می‌شوند.

گام 4: راستی‌آزمایی کنید، سپس آن را به مرجع بسپارید

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

برای محیط‌های تحت نظارت یا طبقه‌بندی‌شده، طراحی را به مرجع امنیتی مسئول ببرید و از معماری جداسازی تأییدشدهٔ آن استفاده کنید. پیکربندی VPN و توضیح مفهومی اعتباربخشی ایجاد نمی‌کند. آن گام کاغذبازی نیست؛ تعیین می‌کند که آیا طراحی اصلاً اجازهٔ وجود دارد یا نه.