قبول الوصول البعيد عبر VPC يتطلب اختبارات رفض
تسجيل الدخول العامل عبر VPN هو الصف الأول في جدول القبول، لا الأخير. اكتب أوامر الرفض المتوقعة لكل دور واختبر الضوابط التي تحددها.
قبول الوصول البعيد هو جدول من النتائج المتوقعة، وليس لقطة شاشة لصفحة تعمل. لكل مجموعة، اكتب ما ينبغي أن ينجح وما ينبغي أن يفشل، ثم شغّل الاثنين مقابل هويات اختبار مخصصة داخل نافذة مضبوطة. عمليات الرفض هي الجزء الذي يثبت الحدود؛ أما تسجيل الدخول الناجح فلا يثبت إلا وجود النفق. كل هذا يعمل مع منتج VPN المختار مسبقًا.
استخدم حسابات منفصلة للاختبارات، وسمِّها بحيث لا يخطئ أحد في اعتبار هوية اختبار استثناءً حقيقيًا.
اكتب الحدود على هيئة نتائج متوقعة
ابدأ من الأدوار لا من المكونات: من يحتاج أي خدمة، ومن أي مكان، وبأي هوية. خذ شبكة VPC توضيحية: مجموعة تحتاج بيئة الاختبار عبر HTTPS، وأخرى تحتاج قاعدة بيانات إنتاج، وثالثة أصغر تدير البوابة نفسها. يحصل كل صف على سماح متوقع ورفض متوقع، بما في ذلك الخدمة المجاورة والحساب المجاور الذي لا ينبغي أن يعمل. هذا الجدول هو معيار القبول، ويمكن للأشخاص الذين لا ينفذون الاختبارات مراجعته.
اختبر تسجيل الدخول إلى قاعدة البيانات بشكل منفصل عن مسار الشبكة. لا ينبغي أن يجعل منفذ TCP قابل للوصول حساب قاعدة بيانات غير معتمد ينجح، ولا ينبغي أن تنشئ عضوية VPN دور IAM سحابيًا أو تمنح وصولًا إداريًا إلى API. هذه ثلاثة ضوابط مستقلة، وهي تفشل بشكل مستقل.
المسار ليس إذنًا
المسار يجعل الطريق ممكنًا؛ لكنه لا يمنح إذنًا. حجب مسار هو بديل ضعيف لقيد يُفرض عند الوجهة، لأن العميل يستطيع دائمًا إضافة مسار خاص به. تبقى مجموعة الأمان ومنحة قاعدة البيانات وتفويض التطبيق نفسه هي الضوابط التي تحسم الأمر. حين ينجح اختبار بشكل غير متوقع، انظر أولًا إلى سياسة الوجهة لا إلى جدول التوجيه الذي أردت للعميل أن يمتلكه.
ولهذا أيضًا تستهدف اختبارات الرفض الجانب الخادم: فهذه النتائج لا يمكن تغييرها بتحرير العميل.
أي مصدر ترى الضابطة فعليًا؟
يعتمد عنوان المصدر الذي تقيّمه الضابطة على هندسة البوابة. قد تمرر بوابة مستضافة على EC2 بركة مُوجَّهة، أو تترجم إلى عنوانها الخاص، أو تقدّم عنوانًا مختلفًا بعد NAT؛ أما Client VPN المُدار فيرتبط بشبكة فرعية ويتبع نموذجه الخاص. ترى مجموعات الأمان وقوائم ACL الشبكية كل ما يصل بعد تلك المعالجة. فحص قاعدة بانطلاق من افتراض خاطئ حول المصدر طريقة شائعة لبناء حدود تبدو صحيحة وتسمح بالمرور الخاطئ.
اربط كل نتيجة بأصغر حدث مفيد: الهوية والجلسة، والمورد، والعملية، والوقت، والقرار. نداء API في CloudTrail وسجل تدفق VPC وسجل جلسة VPN تجيب عن أسئلة مختلفة، ولا واحد منها وحده يُعد تدقيقًا للتطبيق.
أزل هوية ما ثم اختبرها من جديد
أدرج الإزالة في الجدول نفسه. أزل هوية اختبار، وتأكد من رفض جلسة جديدة، ثم تأكد بشكل منفصل من كيفية التعامل مع الجلسات القائمة، لأنها سلوكات مختلفة بمالكين مختلفين. تحقق مما يحدث بعد إعادة تشغيل البوابة أو استبدالها، حتى لا يختفي استثناء مضاف يدويًا بصمت أو يعود أوسع. الحدود التي تدوم حتى النشر التالي فقط ليست حدودًا.
لا شيء من هذا يستبدل الترقيع أو الاستعادة أو العمل على دورة حياة بيانات الاعتماد. إنه يجعل وعدًا أضيق قابلًا للقياس: يصل الأشخاص المناسبون إلى الخدمات المناسبة، بينما تبقى المسارات والحسابات وأسطح الإدارة المجاورة خارج المنحة.
احتفظ بالجدول مع النشر وأعد تشغيله عندما تتغير البوابة. الاختبارات رخيصة؛ أما الافتراضات التي تقف خلفها فليست كذلك.