پذیرش دسترسی از راه دور VPC به آزمون‌های رد نیاز دارد

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

برای آزمون‌ها از حساب‌های جداگانه استفاده کنید و آن‌ها را طوری برچسب بزنید که کسی هویت آزمایشی را با یک استثنای واقعی اشتباه نگیرد.

مرز را به‌صورت نتایج مورد انتظار بنویسید

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

ورود به پایگاه داده را جدا از مسیر شبکه آزمایش کنید. یک درگاه TCP قابل دسترس نباید باعث موفقیت یک حساب پایگاه داده تأییدنشده شود و عضویت در VPN نباید نقش IAM ابری بسازد یا دسترسی مدیریتی به API بدهد. این‌ها سه کنترل مستقل هستند و مستقل از هم شکست می‌خورند.

مسیر مجوز نیست

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

به همین دلیل آزمون‌های رد سمت سرور را هدف می‌گیرند: آن نتایج با ویرایش کلاینت تغییر نمی‌کنند.

کنترل در واقع کدام منبع را می‌بیند؟

آدرس منبعی که یک کنترل ارزیابی می‌کند به معماری دروازه بستگی دارد. دروازه‌ای که روی EC2 میزبانی می‌شود ممکن است یک استخر مسیریابی‌شده را ارسال کند، آن را به آدرس خودش ترجمه کند یا پس از NAT آدرس متفاوتی ارائه دهد؛ Client VPN مدیریت‌شده به زیرشبکه متصل می‌شود و مدل خودش را دنبال می‌کند. گروه‌های امنیتی و فهرست‌های ACL شبکه هر چیزی را که پس از این پردازش برسد می‌بینند. بررسی یک قاعده با فرض نادرست درباره منبع، روشی رایج برای ساختن مرزی است که درست به نظر می‌رسد و ترافیک نادرست را می‌پذیرد.

هر نتیجه را با کوچک‌ترین رویداد مفید مرتبط کنید: هویت و نشست، منبع، عملیات، زمان و تصمیم. یک فراخوان API در CloudTrail، یک رکورد جریان VPC و یک گزارش نشست VPN به پرسش‌های متفاوتی پاسخ می‌دهند و هیچ‌کدام به‌تنهایی حسابرسی برنامه نیست.

یک هویت را بازنشسته کنید و دوباره آزمایش کنید

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

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

جدول را همراه با استقرار نگه دارید و وقتی دروازه تغییر کرد دوباره آن را اجرا کنید. آزمون‌ها ارزان هستند؛ فرض‌های پشت آن‌ها نه.