لقد ورثت فوضى سحابية. من أين تبدأ؟

لقد تولّيت للتو حسابًا سحابيًا (أو عشرة) بنته شخص آخر على مدى ثلاث سنوات دون توثيق، ومع فريق متغيّر من المتعاقدين، وقناة Slack باسم #aws-help لم تكن نشطة منذ 2022. هذا أحد أكثر المواقف شيوعًا في عمل أمان السحابة، وهو محرج لأنك مسؤول عن شيء لا يمكنك شرحه بعد.

إليك كيفية الانتقال من عدم الرؤية إلى موضع دفاعي دون إهدار الموارد.

توقف عن التخمين واحصل على جرد أولًا

لا يمكنك تأمين ما لا تراه. قبل لمس سياسة IAM واحدة، نفّذ عملية جرد:

• AWS: aws organizations list-accounts لرؤية الهيكل الكامل للحساب، ثم Steampipe أو AWS Config aggregators لسحب الموارد عبر الحسابات إلى عرض واحد قابل للاستعلام.
• Azure: استعلامات Resource Graph (az graph query) عبر الاشتراكات، لأن نموذج tenant/subscription في Azure يخفي الامتداد بسهولة.
• GCP: gcloud asset search-all-resources على مستوى المؤسسة.

تحقق من هذا مقابل بيانات الفواتير. الفواتير لا تكذب حول ما يعمل، حتى عندما تكذب الوسوم والتوثيق. إذا رأيت إنفاقًا على خدمة لم يذكرها أحد أثناء الاستقبال، فهذا هو الاكتشاف الأول.

أوجد من يمكنه فعل ماذا قبل العثور على ما هو معطوب

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

شغّل AWS IAM Access Analyzer أو أدوات بأسلوب iam-lint لتمييز الأذونات غير المستخدمة خلال آخر 90 يومًا. عمليًا، الحسابات الموروثة تقريبًا دائمًا لديها مستخدم IAM واحد على الأقل مع مفاتيح وصول طويلة الأجل كان من المفترض أن تكون