اپنے ذریعے نہ بنائے ہوئے کلاؤڈ اسٹیٹ کو محفوظ بنانا

آپ کو ابھی ایک کلاؤڈ اکاؤنٹ کی کلیدیں دی گئی ہیں جو تین سال سے بغیر نگرانی کے بڑھ رہا ہے۔ کوئی دستاویزات نہیں چھوڑے۔ IAM میں 40 roles ہیں جن میں wildcard permissions ہیں، S3 buckets ہیں جو کوئی یاد نہیں رکھتا کہ کس نے بنائیں، اور جو آخری شخص network topology کو سمجھتا تھا وہ 2022 میں کمپنی سے چلا گیا۔ یہ زیادہ تر جاب پوسٹنگز سے زیادہ عام ہے، اور پہلا مہینہ بعد میں سب کچھ کے لیے ٹون سیٹ کرتا ہے۔

کچھ بھی دیکھنے سے پہلے انوینٹری حاصل کریں

فوری طور پر چیزوں کو قفل کرنے کی جلدی کو روکیں۔ آپ کو پہلے ایک map چاہیے۔ aws resourcegroupstaggingapi get-resources کو ہر region میں چلائیں، صرف us-east-1 میں نہیں — ٹیمیں ap-southeast-2 میں ٹیسٹ resources بناتے ہیں اور بھول جاتے ہیں۔ اگر AWS Config پہلے سے فعال ہے تو اسے pair کریں، یا اگر نہیں ہے تو اب اسے چالو کریں۔ Azure پر، az resource list --output table کو spreadsheet میں pipe کرنا پہلی بار کے لیے اچھا کام کرتا ہے۔ GCP پر، Cloud Asset Inventory کا gcloud asset search-all-resources آپ کو وہی view دیتا ہے۔

بلنگ کے خلاف cross-reference کریں۔ جو کچھ بھی پیسے خرچ کر رہا ہے وہ آپ کی resource inventory میں نظر آنا چاہیے؛ جو کچھ بھی inventory میں ہے اور کوئی حالیہ سرگرمی نہیں ہے وہ archival کے لیے ایک امیدوار ہے۔ یہاں discrepancies عام طور پر وہ جگہ ہے جہاں خطرناک چیزیں چھپی ہوتی ہیں — orphaned EC2 instances public IPs کے ساتھ، بھولے ہوئے RDS snapshots unencrypted بیٹھے ہوئے، load balancers کچھ بھی نہیں کی طرف اشارہ کر رہے ہیں۔

IAM کو آڈٹ کریں جیسے یہ ایک crime scene ہو

ہر IAM policy کو pull کریں اور "Action": "*" کو "Resource": "*" کے ساتھ دیکھیں۔ یہ combination ایک مٹھی بھر break-glass admin roles کے باہر موجود نہیں ہونا چاہیے، اور یہاں تک کہ ان کے پاس MFA enforcement اور CloudTrail alerting منسلک ہونی چاہیے۔ IAM Access Analyzer استعمال کریں external accounts تک رسائی دینے والے roles تلاش کرنے کے لیے — یہ دونوں intentional cross-account trust relationships اور غلطیوں کو پکڑتا ہے جب کوئی غلط account ID کے خلاف Terraform module test کر رہا ہو۔

90 دن سے پرانی access keys کو aws iam generate-credential-report کے ساتھ چیک کریں۔ وراثت میں ملے ہوئے estates میں ہمیشہ long-lived keys ہوتی ہیں جو service accounts سے جڑی ہوتی ہیں، کبھی کبھی Lambda environment variable میں یا Jenkins job میں hardcoded ہوتی ہیں۔ انہیں rotate کریں، لیکن اسے stage کریں — ایک key کو ختم کرنا جو ایک nightly batch job 2 AM پر منحصر ہے یہ ہے کہ آپ اپنے پہلے ہفتے میں page کیسے ہوتے ہیں۔

حملہ آور سے پہلے عوامی exposure تلاش کریں

اپنے VPCs میں network reachability check چلائیں۔ Security groups جن میں 0.0.0.0/0 ہے 80/443 کے علاوہ کسی چیز پر انہیں justification کی ضرورت ہے، نہ کہ assumption۔ ScoutSuite یا Prowler جیسے tools ایک اکاؤنٹ کو منٹوں میں chew کریں گے اور severity کے لحاظ سے درجہ بندی شدہ report نکالیں گے — اپنی checklist بناتے ہوئے صفر سے شروع کرنے کی بجائے وہاں شروع کریں۔

S3 buckets کو خصوصی توجہ کی ضرورت ہے کیونکہ وہ classic inherited-estate landmine ہیں۔ bucket policies اور account-level Block Public Access settings دونوں کو چیک کریں؛ کسی نے شاید account default کو سال پہلے ایک one-off static site کے لیے disable کیا ہوگا اور اسے کبھی واپس نہیں کیا۔ aws s3api list-buckets کو ہر ایک پر get-bucket-acl اور get-bucket-policy-status کو چیک کرنے والے loop کے ساتھ ملایا جائے تو آپ کو زیادہ تر accounts کے لیے دس منٹ سے بھی کم میں صاف picture ملتی ہے۔

logging قائم کریں trust قائم کرنے سے پہلے

اگر CloudTrail، VPC Flow Logs، یا GuardDuty پہلے سے ہر جگہ چل نہیں رہے ہیں، تو انہیں ابھی چالو کریں، کوئی بھی دوسری تبدیلی کرنے سے پہلے۔ آپ کو اس نقطہ سے آگے کیا ہوتا ہے اس کا record چاہیے، اور آپ کو یہ چیزیں delete کرنے سے پہلے چاہیے، کیونکہ deletion بالکل وہ وقت ہے جب غلطیاں ہوتی ہیں اور نئے آدمی پر الزام لگایا جاتا ہے۔ logs کو الگ account یا subscription میں ship کریں اگر بالکل ممکن ہو، تاکہ ایک compromised workload اپنے ثبوت کو بھی مٹا نہ سکے۔

GuardDuty یا Azure Defender for Cloud کو alerting کے ساتھ سیٹ اپ کریں جو کہیں ایک انسان کو route کیا جائے جو سمجھتا ہے — 400 unread messages والے Slack channel میں نہیں۔ detection tooling کی value قریب تر صفر ہے اگر alerts ایک void میں land کریں۔

سب سے زیادہ آواز والے مسائل کو پہلے ٹھیک کریں، سب کچھ دستاویز کریں

آپ ایک sprint میں وراثت میں ملے ہوئے estate کو ٹھیک نہیں کریں گے۔ Triage کریں blast radius کے لحاظ سے: public data exposure پہلے، پھر overprivileged identities، پھر network segmentation، پھر سب کچھ۔ یہ لکھیں کہ آپ کو کیا ملا اور آپ نے کیا تبدیل کیا، یہاں تک کہ ایک plain Google Doc میں بھی، کیونکہ اگلا شخص جو اس کے ساتھ وراثت میں سے اپنے لیے لے، وہ اس سے بہتر کی سزاوار ہے جو آپ کو ملا۔

Pushback کی توقع کریں جب آپ ایک security group کو tighten کریں اور ایک dev کا integration test fail ہونا شروع ہو۔ یہ عام ہے — اس کا مطلب ہے کہ audit کام کر رہی ہے۔ آپ production میں کوئی بھی چیز flip کرنے سے پہلے اس workload کے مالک ٹیم سے بات کریں، اور پہلے دو ہفتوں کے لیے ایک rollback plan تیار رکھیں۔

کلاؤڈ audits کے پیچھے کے tools اور reasoning کے بارے میں مزید جاننے کے لیے، Korra Studio کے IAM hardening اور cloud detection engineering کے segments دیکھیں — دونوں اوپر دیئے گئے workflow کے ساتھ اچھی طرح pair کرتے ہیں۔