آپ نے ایک Cloud Mess کو وراثت میں پایا۔ آپ کہاں سے شروع کریں؟

آپ نے ابھی ایک cloud account (یا دس) کا کنٹرول سنبھالا ہے جسے کوئی اور تین سال میں بغیر کسی documentation کے، معاقدین کی بدلتی ہوئی جماعت کے ساتھ، اور #aws-help نام کے Slack channel کے ذریعے بنایا تھا جو 2022 سے فعال نہیں رہا۔ یہ cloud security کے کام میں سب سے عام صورتحال ہے، اور یہ تکلیف دہ ہے کیونکہ آپ کسی چیز کے لیے ذمہ دار ہیں جسے آپ ابھی تک سمجھا نہیں سکتے۔

یہاں بتایا گیا ہے کہ کیسے صفر visibility سے ایک محفوظ پوزیشن تک پہنچیں بغیر بہت کچھ کے۔

اندازہ لگانا بند کریں اور پہلے ایک inventory حاصل کریں

آپ وہ چیزیں محفوظ نہیں بنا سکتے جو آپ نہیں دیکھ سکتے۔ کسی ایک IAM policy کو چھونے سے پہلے، ایک inventory pass چلائیں:

• AWS: aws organizations list-accounts سے مکمل account structure دیکھنے کے لیے، پھر Steampipe یا AWS Config aggregators سے accounts میں سے resources کو ایک queryable view میں pull کریں۔
• Azure: subscriptions میں Resource Graph queries (az graph query)، کیونکہ Azure کا tenant/subscription model sprawl کو آسانی سے چھپاتا ہے۔
• GCP: organization level پر gcloud asset search-all-resources۔

اس کو billing data کے ساتھ cross-reference کریں۔ Billing سچ بولتا ہے کہ کیا چل رہا ہے، یہاں تک کہ جب tags اور documentation ایسا نہ کریں۔ اگر آپ کسی service پر spend دیکھتے ہیں تو کوئی بھی onboarding میں اس کا ذکر نہیں کیا، یہ آپکی پہلی finding ہے۔

جو کچھ ٹوٹا ہے اس سے پہلے معلوم کریں کہ کون کیا کر سکتا ہے

Misconfigurations سرخیوں میں آتے ہیں، لیکن ایک inherited environment میں identity ہی وہ جگہ ہے جہاں عام طور پر حقیقی exposure رہتا ہے۔ ہر IAM user، role، اور service account کو pull کریں اور تین سوالات پوچھیں: کیا اس کی اب بھی ضرورت ہے، کیا اس کے پاس وہ access ہے جو وہ استعمال نہیں کرتا، اور کیا یہ human یا machine ہے۔

AWS IAM Access Analyzer یا iam-lint-style tooling چلائیں تاکہ آخری 90 دن میں غیر استعمال شدہ permissions کو flag کریں۔ عملی طور پر، inherited accounts میں ہمیشہ کم از کم ایک IAM user ہوتا ہے جس کے پاس long-lived access keys ہوتے ہیں جو