تأمين بيئة سحابية لم تبنها بنفسك

لقد تسلمت للتو مفاتيح حساب سحابي ظل ينمو دون إشراف لمدة ثلاث سنوات. لم يترك أحد توثيقاً. IAM يحتوي على 40 دور بأذونات wildcard، هناك S3 buckets لا أحد يتذكر إنشاءها، والشخص الأخير الذي فهم طوبولوجيا الشبكة ترك الشركة في 2022. هذا أكثر شيوعاً مما تعترف به معظم إعلانات الوظائف، والشهر الأول يحدد النبرة لكل شيء بعده.

احصل على جرد قبل أن تلمس أي شيء

قاوم الرغبة في البدء بقفل الأشياء على الفور. تحتاج إلى خريطة أولاً. شغّل aws resourcegroupstaggingapi get-resources عبر كل منطقة، وليس فقط us-east-1 — الفرق تحب إطلاق موارد الاختبار في ap-southeast-2 والنسيان عنها. ادمج ذلك مع AWS Config إذا كان مفعلاً بالفعل، أو فعّله الآن إن لم يكن كذلك. على Azure، az resource list --output table مع pipe إلى جدول بيانات يعمل بشكل جيد للمرة الأولى. على GCP، Cloud Asset Inventory مع gcloud asset search-all-resources يعطيك نفس الرؤية.

قارن مع الفواتير. أي شيء يكلف المال يجب أن يظهر في جرد مواردك؛ أي شيء في الجرد بدون نشاط حديث هو مرشح للأرشفة. التناقضات هنا عادة حيث يختبئ الشيء المخيف — EC2 instances مهجورة بعناوين IP عامة، RDS snapshots منسية بدون تشفير، load balancers تشير إلى لا شيء.

دقق في IAM كما لو كانت مسرح جريمة

اسحب كل سياسة IAM وابحث عن "Action": "*" مدمجة مع "Resource": "*". هذا المزيج لا يجب أن يوجد خارج قائمة قليلة من أدوار الإدارة للحالات الطارئة، وحتى تلك يجب أن يكون لديها إنفاذ MFA وتنبيهات CloudTrail مرفقة. استخدم IAM Access Analyzer للعثور على الأدوار التي تمنح الوصول إلى حسابات خارجية — هذا يلتقط علاقات trust عبر الحسابات المقصودة والأخطاء من شخص ما يختبر وحدة Terraform مقابل معرف حساب خاطئ.

تحقق من مفاتيح الوصول الأقدم من 90 يوماً باستخدام aws iam generate-credential-report. الأملاك الموروثة تقريباً دائماً لديها مفاتيح طويلة الأجل مرفقة بحسابات الخدمة، أحياناً مدمجة في متغير بيئة Lambda أو وظيفة Jenkins. أدرها، لكن رتبها — قتل مفتاح تعتمد عليه وظيفة دفعية ليلية في الساعة 2 صباحاً هو كيف تُستدعى أثناء أسبوعك الأول.

جد الكشف العام قبل أن يفعل المهاجم

شغّل فحص قابلية الوصول للشبكة عبر VPCs الخاصة بك. مجموعات الأمان مع 0.0.0.0/0 على أي شيء آخر غير 80/443 تحتاج إلى تبرير، وليس افتراض. أدوات مثل ScoutSuite أو Prowler ستمرّ عبر حساب في دقائق وتخرج تقرير مرتب حسب الشدة — ابدأ هناك بدلاً من بناء قائمة التحقق الخاصة بك من الصفر.

S3 buckets تستحق اهتماماً خاصاً لأنها مكان ألغام الملكية الموروثة الكلاسيكية. تحقق من سياسات bucket وإعدادات Block Public Access على مستوى الحساب؛ قد يكون شخص ما عطّل الإعداد الافتراضي للحساب منذ سنوات لموقع ثابت لمرة واحدة ولم يعده أبداً. aws s3api list-buckets مدمجة مع حلقة تتحقق get-bucket-acl و get-bucket-policy-status على كل واحد يعطيك صورة واضحة في أقل من عشر دقائق لمعظم الحسابات.

أسس السجلات قبل أن تؤسس الثقة

إذا لم تكن CloudTrail أو VPC Flow Logs أو GuardDuty تعمل بالفعل في كل مكان، فعّلها الآن، قبل إجراء أي تغييرات أخرى. تريد سجلاً لما يحدث من هنا فصاعداً، وتريده قبل أن تبدأ بحذف الأشياء، لأن الحذف هو بالضبط عندما تحدث الأخطاء وتُلقى باللوم على الشخص الجديد. أرسل السجلات إلى حساب أو اشتراك منفصل إن أمكن ذلك، بحيث لا يمكن لعبء عمل مخترق أن يمسح أيضاً أدلته.

أعد GuardDuty أو Azure Defender for Cloud مع التنبيهات الموجهة إلى مكان يتحقق فيه الإنسان بالفعل — وليس قناة Slack بها 400 رسالة غير مقروءة. قيمة أدوات الكشف قريبة جداً من الصفر إذا هبطت التنبيهات في فراغ.

أصلح أكبر المشاكل أولاً، وثّق كل شيء

لن تصلح ملكية موروثة في sprint واحد. صنّف حسب نطاق التأثير: تعرض البيانات العام أولاً، ثم الهويات ذات الامتيازات الزائدة، ثم تقسيم الشبكة، ثم كل شيء آخر. اكتب ما تجده وما غيّرته، حتى في Google Doc عادي، لأن الشخص التالي الذي يرث هذا منك يستحق الأفضل مما حصلت عليه.

توقع معارضة عندما تشدد مجموعة أمان ويبدأ اختبار تكامل مطور في الفشل. هذا طبيعي — يعني أن التدقيق يعمل. تحدث مع الفريق الذي يمتلك عبء العمل قبل أن تقلب أي شيء في الإنتاج، واحتفظ بخطة rollback جاهزة للأسبوعين الأولين.

للمزيد حول الأدوات والمنطق وراء تدقيقات السحابة، راجع مقاطع Korra Studio حول IAM hardening وcloud detection engineering — كلاهما يتوافق بشكل جيد مع سير العمل أعلاه.