AWS Security Hub remediation خودکار کریں، پہلے sandbox میں کیوں آزمانا ہے
AWS Security Hub کی remediation خودکار کرنے کا محفوظ راستہ یہ ہے کہ Automated Security Response on AWS کو پہلے الگ non-production account اور محدود Region میں deploy کیا جائے۔ ایک example finding پر remediation دستی طور پر چلائیں، resource کی اصل حالت اور مکمل execution trace کی تصدیق کریں، پھر صرف اسی آزمودہ control کے لیے automation فعال کریں۔
Sandbox ضروری ہے کیونکہ fully automated mode صرف آزمائشی resource تک محدود نہیں رہتا: فعال control سے مطابقت رکھنے والی دوسری findings بھی خودکار تبدیلی شروع کر سکتی ہیں۔ الگ ماحول میں پہلا test کرنے سے IAM trust، cross-account routing، runbook کے اثر اور audit evidence کو production resources سے دور جانچنا ممکن ہوتا ہے۔
1۔ Lab کی حد اور prerequisites طے کریں
قابلِ نقل lab کے لیے ایک Security Hub administrator account اور ایک member account رکھیں۔ Single-account deployment بھی ممکن ہے، مگر الگ member account cross-account permissions اور production سے علیحدگی دونوں کو واضح بناتا ہے۔ ابتدا میں صرف وہ Region شامل کریں جہاں test resource اور finding بننی ہے۔
Deployment سے پہلے Security Hub کی administrator-member ترتیب، finding aggregation اور متعلقہ account اور Region میں AWS Config recording مکمل کریں۔ اگر consolidated control findings استعمال ہو رہی ہیں تو admin اور member stacks میں Security Control playbook کا انتخاب ایک جیسا ہونا چاہیے۔ Lambda.1 آزمانے کے لیے صرف غیر حساس test function استعمال کریں اور پہلے سے طے کریں کہ public permission ہٹنے کے بعد اصل configuration بحال کرنی ہے یا function حذف کرنا ہے۔
- Administrator اور member account IDs، Region، owner اور lab ختم کرنے کی تاریخ درج کریں۔
- CloudFormation یا StackSets چلانے والی identity کی permissions پہلے جانچیں۔
- جان بوجھ کر insecure resource بنانے کی داخلی منظوری اور monitoring exception حاصل کریں۔
- Test resource کو production traffic، secrets اور حساس code سے الگ رکھیں۔
2۔ تین deployment layers درست ترتیب سے نصب کریں
AWS کی stack deployment ہدایات کے مطابق پہلے Security Hub administrator account میں admin template، پھر ہر member account کے ایک Region میں member-roles template، اور آخر میں مطلوبہ accounts اور Regions میں member template نصب ہوتا ہے۔ Member-roles stack global cross-account IAM roles بناتا ہے، جبکہ member stack remediation runbooks اور منتخب playbooks فراہم کرتا ہے؛ multi-account ماحول کے لیے AWS StackSets کی سفارش کرتا ہے۔
- Admin stack کو Security Hub administrator account میں deploy کریں اور صرف مطلوبہ security standard یا Security Control playbook منتخب کریں۔
- Admin deployment مکمل ہونے کے بعد member-roles template ہر آزمائشی account میں صرف ایک Region میں نصب کریں۔ Security Hub admin account ID درست دیں۔
- Member template ان تمام accounts اور Regions میں deploy کریں جہاں test finding remediate ہونی ہے۔ Member اور member-roles stacks میں ایک ہی namespace رکھیں۔
- ہر operation کے CloudFormation events اور Outputs دیکھیں۔ CREATE_COMPLETE صرف infrastructure بننے کی تصدیق ہے، کامیاب remediation کی نہیں۔
اس تقسیم سے orchestration، cross-account permissions اور remediation documents الگ رہتے ہیں۔ Admin stack مکمل ہونے کے باوجود target account میں درست role یا runbook موجود نہ ہو تو workflow finding وصول کر سکتا ہے مگر resource کی تبدیلی مکمل نہیں ہوگی۔
3۔ Lambda.1 finding کو دستی طور پر remediate کریں
شرطی lab scenario میں member account کی ایک test Lambda function پر ایسی resource policy بنائیں جو public invocation کی اجازت دے اور Lambda.1 finding پیدا کرے۔ اگر یہ configuration آپ کے guardrails یا داخلی پالیسی کے خلاف ہے تو ASR کا کوئی دوسرا supported control چنیں؛ test کے لیے production exception کو خاموشی سے bypass نہ کریں۔
Finding administrator account تک پہنچنے کے بعد Security Hub CSPM console میں اسی resource کی Lambda.1 finding منتخب کریں اور Actions سے Remediate with ASR چلائیں۔ ابھی automated remediation فعال نہ کریں۔ Initiation اور completion کی SNS notifications محفوظ کریں، پھر member account میں Lambda resource policy دیکھ کر تصدیق کریں کہ public access واقعی ہٹ گئی ہے؛ صرف notification یا finding status کو کافی ثبوت نہ سمجھیں۔
4۔ Finding سے resource change تک trace جوڑیں
AWS کی remediation trace دکھاتی ہے کہ administrator account کی Remediate_with_ASR_CustomAction EventBridge rule finding کو SO0111-ASR-Orchestrator Step Functions workflow تک پہنچاتی ہے، workflow target account اور Region میں Systems Manager Automation چلاتا ہے، اور Lambda.1 کا آخری remediation document public access policy منسوخ کرتا ہے۔ اسی سلسلے کو finding ID اور execution IDs کے ذریعے ملانا cross-account routing کے functional test کا اصل ثبوت ہے۔
- EventBridge rule میں متعلقہ event اور orchestrator target کی موجودگی دیکھیں۔
- SO0111-ASR-Orchestrator کی execution history میں finding، target account، Region اور ہر state کا نتیجہ چیک کریں۔
- Member account کے Systems Manager Automation میں control runbook اور آخری remediation execution تلاش کریں۔
- Administrator account کے SO0111-ASR log group میں اسی control اور execution کا outcome ملائیں۔
- اگر Action Log فعال کیا ہے تو CloudTrail میں resource-changing API call کو وقت، principal اور resource کے ساتھ correlate کریں۔
Production gate اسی وقت پاس کریں جب operator finding سے resource change تک مسلسل trace دکھا سکے، ناکام execution کا قابلِ عمل error ملے اور rollback یا configuration restoration کا طریقہ پہلے سے لکھا ہو۔ کامیاب stack deployment یا SNS success message اکیلا اس gate کے لیے کافی نہیں۔
5۔ صرف ایک آزمودہ control کی automation فعال کریں
AWS کی fully automated remediation ترتیب کے مطابق ہر supported control کی configuration administrator account کی DynamoDB table میں ہوتی ہے؛ Lambda.1 کا automatedRemediationEnabled فعال کرنے پر solution کے scope میں اس control سے مطابقت رکھنے والے تمام resources اہل ہو جاتے ہیں۔ Account IDs، organizational units اور resource tags کے filters administrator account کے Parameter Store میں /ASR/Filters/ کے تحت Include، Exclude یا Disabled mode سے مقرر ہوتے ہیں، اور یہ filters manual invocations پر لاگو نہیں ہوتے۔
پہلی activation کو ایک control، منظور شدہ account set اور واضح resource tag تک محدود رکھیں۔ پہلے Include filters محفوظ کرکے ان کی values دوبارہ پڑھیں، پھر Lambda.1 کی configuration فعال کریں۔ اسی محدود scope میں test policy دوبارہ بنائیں اور manual run میں استعمال ہونے والی evidence chain کو خودکار execution کے لیے بھی مکمل کریں۔
- Runbook کے IAM roles میں مطلوبہ remediation کے لیے ضروری permissions کا جائزہ لیں۔
- Scope میں موجود ہر public Lambda function کے owner سے permission ہٹانے کی منظوری لیں۔
- SNS subscriptions، CloudWatch alarms اور failure notification کے وصول کنندگان طے کریں۔
- Repeated failure، غیر متوقع resource change یا scope mismatch کے لیے stop condition لکھیں۔
- مشاہدے کی منظور شدہ مدت مکمل ہونے سے پہلے دوسرا control، account یا Region شامل نہ کریں۔
6۔ Cleanup اور cost checkpoint مکمل کریں
Lab بند کرتے وقت پہلے control کی automatedRemediationEnabled value واپس false کریں، پھر test Lambda function اور اس کی غیر محفوظ policy حذف کریں۔ اس کے بعد member، member-roles اور admin stacks یا StackSets کو dependency کے مطابق ہٹائیں اور ہر target account میں deletion status چیک کریں۔ Retained IAM roles، log groups یا KMS keys حذف کرنے سے پہلے audit-retention ضرورت اور جاری executions کی تصدیق کریں۔
Cost checkpoint میں Security Hub، AWS Config recording، Systems Manager Automation، Step Functions، Lambda، CloudWatch Logs، CloudTrail اور KMS کے استعمال کو شامل کریں؛ صرف CloudFormation stack کی موجودگی لاگت کی مکمل تصویر نہیں دیتی۔ Lab record میں owner، آخری execution ID، محفوظ audit evidence، باقی retained resources اور ان کی طے شدہ deletion date درج کرکے کام ختم کریں۔
یہ بھی پڑھیں:
ہمارا نیوز لیٹر سبسکرائب کریں
ویب 3، AI اور کرپٹو کی تازہ خبریں براہ راست اپنے اِن باکس میں پائیں۔