GuardDuty, Inspector, Macie আর Security Hub

এই লেসন শেষে তুমি পারবে

• বোঝাতে, আটকানোর ব্যবস্থা থাকার পরেও কেন ধরার ব্যবস্থা লাগে, আর কোন service কোন প্রশ্নের উত্তর দেয়: কেউ হামলা করছে কি না (GuardDuty), কোথায় হামলা হতে পারে (Inspector), সংবেদনশীল ডেটা কোথায় (Macie), সব মিলিয়ে ছবিটা কী (Security Hub), ঘটনাটা ঘটল কীভাবে (Detective)।
• বলতে, Amazon GuardDuty কী কী পড়ে, protection plan বাড়তি কী যোগ করে, কোথায় তার agent লাগে, আর একটা finding EventBridge দিয়ে কীভাবে নিজে থেকেই ব্যবস্থা নেওয়ায় গড়ায়।
• বলতে, Amazon Inspector কীভাবে EC2 instance (SSM Agent দিয়ে বা EBS snapshot থেকে), ECR image আর Lambda function-এ CVE আর network-এ খোলা পথ খোঁজে, কীভাবে score দেয় আর আবার scan করে।
• Amazon Macie দিয়ে S3-এ ব্যক্তিগত তথ্য আর ঝুঁকিপূর্ণ bucket setting খুঁজতে, managed আর custom data identifier আর allow list কাজে লাগিয়ে।
• বোঝাতে, AWS Security Hub কী জড়ো করে, তার security standard-এর জন্য কেন AWS Config লাগে, আর ২০২৫-এ পুরোনো service-টা Security Hub CSPM হয়ে যাওয়ায় কী বদলেছে।
• Scenario-র keyword দেখে ঠিক service বাছতে আর দেখতে-কাছাকাছি service বাদ দিতে, WAF, Shield, Config আর CloudTrail-সহ।

#শুধু আটকানো না, ধরাও লাগে

#তালা যথেষ্ট না

এই অধ্যায়ের আগের লেসনগুলো ছিল আটকানো নিয়ে: ডেটা encrypt করো (২১.১–২১.৫), request ছাঁকো আর বন্যা সামলাও (২১.৬)। কিন্তু আটকানোর ব্যবস্থা চুপচাপ ব্যর্থ হয়। একজন developer ভুল করে একটা access key public repository-তে push করে দেয়। গত মাসে নিরাপদ ছিল এমন একটা library-র আজ নতুন CVE বের হয়। কেউ “শুধু একটা report-এর জন্য” customer-এর তালিকা একটা bucket-এ export করে রাখে, তারপর ভুলে যায়। এর কোনোটাই কোনো তালায় ধাক্কা দেয় না; কিন্তু কেউ নজর রাখলে সবগুলোই চোখে পড়ে।

AWS এই নজর রাখার কাজটা আলাদা আলাদা managed service-এ ভাগ করেছে, প্রত্যেকে একটা করে প্রশ্নের উত্তর দেয়:

#Amazon GuardDuty: হুমকি ধরা

#GuardDuty কীসের দিকে নজর রাখে

Amazon GuardDuty হলো একটা বুদ্ধিমান threat detection service। সে তোমার account-এর কাজকর্ম সারাক্ষণ বিশ্লেষণ করে, আর কিছু খারাপ বা অননুমোদিত মনে হলে finding তোলে। সে তিনটা কৌশল মেলায়:

• Threat intelligence: AWS আর partner-দের কাছ থেকে পাওয়া পরিচিত খারাপ IP address আর domain-এর তালিকা (mining pool, command-and-control server, পরিচয় লুকানোর proxy)।
• Machine learning আর anomaly detection: প্রতিটা user, role আর instance-এর জন্য কোনটা স্বাভাবিক তা সে শিখে নেয়, আর যা স্বাভাবিক না সেটা ধরে (কখনো call হয়নি এমন API, নতুন কোনো দেশ থেকে, রাত ৩টায়)।
• পরিচিত হামলার ধরন: port probe করা, AWS-এর বাইরে থেকে credential ব্যবহার, DNS query-র ভেতরে ডেটা লুকিয়ে পাঠানো, এমন আচরণের rule।

চালু করার সাথে সাথে GuardDuty তিনটা foundational data source পড়তে শুরু করে:

• CloudTrail management event: control plane-এর প্রতিটা API call, যেমন RunInstances, CreateTrail বা PutBucketPolicy। অস্বাভাবিক API call আর অননুমোদিত deployment এখানেই ধরা পড়ে।
• EC2 instance-এর VPC flow log: অদ্ভুত traffic, পরিচিত খারাপ IP-র সাথে যোগাযোগ।
• Amazon-provided resolver-এর DNS log: দখল হয়ে যাওয়া instance mining pool খুঁজছে, বা চুরি করা ডেটা DNS query-র ভেতরে লুকিয়ে পাঠাচ্ছে।

GuardDuty এগুলো পড়ে নিজের আলাদা feed থেকে। তোমাকে CloudTrail trail বানাতে হয় না, VPC Flow Logs বা Route 53 Resolver query logging চালু করতে হয় না, আর চালু করলেও GuardDuty-র কিছু বদলায় না; ওগুলো তোমার নিজের কাজের জন্য (লেসন ১৯.৬ আর ২২.৩)। এই foundational detection-এর জন্য তোমার instance-এ কিছুই install করতে হয় না, তাই performance-এ কোনো প্রভাব পড়ে না। চালু করতে একটা click; নতুন account ৩০ দিনের free trial পায়, তারপর বিশ্লেষণ করা event-এর পরিমাণ অনুযায়ী দাম।

GuardDuty Regional: একটা detector একটা Region পাহারা দেয়। প্রতিটা Region-এ চালু করো, যেগুলো ব্যবহার করো না সেগুলোতেও, কারণ চুরি করা key হাতে হামলাকারী ঠিক ওইসব Region-এই instance চালাতে পছন্দ করে।

#Protection plan

Foundational উৎসের বাইরে GuardDuty দেয় ইচ্ছামতো চালু করার মতো কিছু protection plan, প্রত্যেকটা আরেকটা উৎসের দিকে নজর রাখে। প্রথমবার GuardDuty চালু করলে Runtime Monitoring বাদে সবগুলো চালু হয়ে যায় আর trial-এর মধ্যে থাকে; যেকোনোটা তুমি বন্ধ করতে পারো।

#Finding আর নিজে থেকে ব্যবস্থা

Finding হলো একটা সম্ভাব্য সমস্যা নিয়ে GuardDuty-র report। তার type-এর নাম দেখেই বোঝা যায় ব্যাপারটা কী, ThreatPurpose:ResourceType/ThreatFamily.Variant!Artifact আকারে, যেমন:

• CryptoCurrency:EC2/BitcoinTool.B!DNS: একটা instance crypto-currency mining-এর সাথে যুক্ত একটা domain খুঁজছে। Crypto-mining-এর জন্য GuardDuty-র আলাদা finding আছে, কারণ দখল হওয়া instance-এর সবচেয়ে সাধারণ পরিণতিই এটা।
• UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS: একটা instance-এর role-এর credential AWS-এর বাইরে থেকে ব্যবহার হচ্ছে।
• Trojan:EC2/DNSDataExfiltration: একটা instance DNS query-র ভেতরে ডেটা লুকিয়ে পাঠাচ্ছে।

প্রতিটা finding-এর একটা severity আছে: Low (১.০–৩.৯), Medium (৪.০–৬.৯), High (৭.০–৮.৯) আর Critical (৯.০–১০.০, attack sequence-এর জন্য)। কাজে লাগার মতো কিছু tool:

• Sample finding প্রতিটা type-এর একটা করে finding বানিয়ে দেয়, যাতে হামলা ছাড়াই তুমি তোমার alert-এর ব্যবস্থা পরীক্ষা করতে পারো।
• Suppression rule প্রত্যাশিত finding নিজে থেকেই archive করে দেয় (যেমন তুমি নিজেই ইচ্ছা করে যে security scanner চালাও)।
• Trusted IP list আর threat list দিয়ে নিজের চেনা ভালো আর চেনা খারাপ address যোগ করা যায়।

GuardDuty খোঁজে; সে আটকায় না, ঠিকও করে না। ব্যবস্থা নেওয়ার অংশটা তুমি বানাও Amazon EventBridge দিয়ে (লেসন ১৯.৫): প্রতিটা নতুন finding default event bus-এ যায়, সাধারণত পাঁচ মিনিটের মধ্যে (আগের finding-এর update default হিসেবে প্রতি ৬ ঘণ্টায় যায়; চাইলে ১৫ মিনিট বা ১ ঘণ্টা করা যায়)। একটা EventBridge rule মেলায় source: aws.guardduty আর একটা severity, তারপর target করে SNS (মানুষের জন্য email বা chat) বা Lambda (নিজে থেকে ব্যবস্থা: quarantine security group দিয়ে instance আলাদা করা, তদন্তের জন্য snapshot নেওয়া, ফাঁস হওয়া access key বন্ধ করা, NACL বা WAF-এ একটা IP আটকানো)। কয়েক ধাপের ব্যবস্থার জন্য target হতে পারে একটা Step Functions workflow বা Systems Manager Automation runbook।

#অনেক account, প্রতিটা Region

একটা organization-এ AWS Organizations দিয়ে একটা account-কে (সাধারণত একটা security tooling account, management account না) GuardDuty-র delegated administrator বানাও (লেসন ২০.১)। সেখান থেকে সব member account-এ GuardDuty চালু করো, পরে বানানো account-এর জন্য auto-enable রাখো, protection plan এক জায়গা থেকে ঠিক করো, আর সব account-এর finding এক জায়গায় দেখো। প্রতিটা Region-এর জন্য এটা আবার করো (বা console-এর multi-Region setup ব্যবহার করো), কারণ detector Regional। Administrator যা manage করে, member সেটা বন্ধ করতে পারে না।

#Amazon Inspector: দুর্বলতা খোঁজা

#Inspector কী scan করে

Amazon Inspector হলো একটা স্বয়ংক্রিয় vulnerability management service। সে নিজেই তোমার workload খুঁজে বের করে, আর সারাক্ষণ সেগুলোতে software দুর্বলতা আর অনিচ্ছাকৃত network খোলা পথ খোঁজে। সে ঠিক তিন ধরনের resource দেখে:

• EC2 instance: operating system-এর package (আর Linux-এ Python, Java, Node.js library-র মতো application language package) জানা CVE-র সাথে মেলানো, সাথে network reachability।
• Amazon ECR-এর container image: push করার সময় scan, তারপর সারাক্ষণ। এটাই ECR-এর enhanced scanning, যেটা আসলে Inspector; ECR-এর basic scanning একবারের, শুধু OS-এর scan (লেসন ১৪.১)।
• Lambda function: standard scanning function deploy বা update হলে তার package dependency যাচাই করে; code scanning তোমার নিজের code-ও পড়ে, code-এ লিখে রাখা secret, injection-এর ফাঁক আর দুর্বল cryptography-র মতো সমস্যা খুঁজতে।

এর বাইরে সে কিছু দেখে না: RDS engine না, S3 object না, on-premises server না (patch করার কাজটা Systems Manager Patch Manager-এর, লেসন ২৫.৩)।

#Inspector EC2 কীভাবে scan করে: agent না snapshot

EC2-এর জন্য Inspector-এর লাগে install করা software-এর তালিকা। সেটা পাওয়ার দুটো পথ:

• Agent-based: SSM Agent (Systems Manager) দিয়ে। Instance-টাকে managed instance হতে হবে: agent চলছে, সাথে AmazonSSMManagedInstanceCore-সহ একটা instance profile (বা Default Host Management Configuration)। Inspector SSM association বানায়, যেগুলো তালিকা সংগ্রহ করে। এতে scan চলে সারাক্ষণ: নতুন instance, নতুন install করা package বা প্রাসঙ্গিক নতুন CVE এলেই আবার scan।
• Agentless: যেসব instance SSM-এর managed না, hybrid scan mode-এ Inspector তাদের volume-এর EBS snapshot নেয়, EBS direct API দিয়ে পড়ে, package scan করে, তারপর snapshot মুছে দেয়, মোটামুটি ২৪ ঘণ্টায় একবার।

Agent-based mode-এ রাখা account-এ SSM Agent ছাড়া একটা instance দেখায় Unmanaged EC2 instance: কোনো finding নেই, আর কেউ coverage page না খুললে কোনো সতর্কবার্তাও নেই। Private subnet-এর instance-এর Systems Manager পর্যন্ত পৌঁছাতে VPC endpoint (বা NAT gateway) লাগে।

#সারাক্ষণ scan, risk score আর finding

Inspector সারাক্ষণ চলে: তোমাকে assessment-এর schedule ঠিক করতে হয় না (পুরোনো Inspector Classic-এ করতে হতো, আর slide-এর diagram-এ এখনো তার “assessment run” দেখা যায়)। কোনো resource-এ package install বা remove হলে, image push হলে, function update হলে, আর সেটাকে প্রভাবিত করে এমন নতুন CVE প্রকাশ হলে সে আবার scan করে। তুমি সমস্যাটা ঠিক করলে পরের scan সেটা দেখে নিজেই finding বন্ধ করে দেয়। তবে ECR image-এর বেলায় এটা চলে শুধু re-scan window-এর ভেতরের image-এ: যেগুলো re-scan duration-এর মধ্যে push হয়েছে বা শেষবার ব্যবহার হয়েছে (ECS/EKS-এ চলছে)। অক্টোবর ২০২৬ থেকে যে account ECR scanning চালু করে, তাদের default ৭ দিন (পুরোনো account-এ ১৪ বা ৯০ দিন, বদলানো যায়)। এর চেয়ে পুরোনো, পড়ে থাকা image আর নজরে থাকে না। Network reachability বিশ্লেষণ হয় মোটামুটি প্রতি ১২ ঘণ্টায়, security group, NACL, route table আর gateway দেখে (কোনো packet পাঠানো হয় না)।

প্রতিটা finding পায় একটা Inspector score: Inspector শুরু করে দুর্বলতার database-এ থাকা CVE-র CVSS base score দিয়ে, তারপর তোমার পরিবেশ অনুযায়ী সেটা বদলায়। Internet থেকে খোলা পথ আছে এমন instance-এ network দিয়ে exploit করা যায় এমন CVE-র score উঁচুই থাকে; ভেতরে ঢোকার কোনো network পথ নেই এমন instance-এ একই CVE-র score কম হয়। “গুরুত্ব ঠিক করার জন্য প্রতিটা দুর্বলতার সাথে একটা risk score থাকে” কথাটার মানে এটাই।

Finding দেখা যায় Inspector console-এ, আর যায় EventBridge-এ (ticket খোলা, deployment আটকানো, কাউকে খবর দেওয়ার জন্য) আর Security Hub-এ। AWS Organizations থাকলে একজন delegated administrator সব account-এ Inspector চালু করে দেয়।

#GuardDuty না Inspector?

Notes এক লাইনে বলে দেয়: GuardDuty নজর রাখে চলমান হামলা আর সন্দেহজনক আচরণের ওপর (threat); Inspector খোঁজে software-এর ভুল আর ফাঁক (vulnerability)।

Vulnerability হলো খোলা জানালা; threat হলো সেই জানালা দিয়ে কারও ঢোকা। Inspector-এর finding ঠিক করলেই GuardDuty-র finding কমে।

#Amazon Macie: S3-এ সংবেদনশীল ডেটা

#Macie কী খুঁজে পায়

Amazon Macie হলো পুরোপুরি managed একটা data security আর data privacy service। সে machine learning আর pattern matching দিয়ে Amazon S3-এ সংবেদনশীল ডেটা খুঁজে বের করে, যেমন personally identifiable information (PII): নাম, ঠিকানা, phone number, email address, credit card number, bank account number, passport number, জাতীয় পরিচয়পত্রের নম্বর, সাথে private key আর AWS secret key-র মতো credential।

সে কাজ করে শুধু S3-এ। RDS, DynamoDB বা EBS-এর ডেটা তার নাগালের বাইরে (চেনাতে চাইলে আগে S3-এ export করো)।

কোনটা সংবেদনশীল, Macie ঠিক করে এগুলো দিয়ে:

• Managed data identifier: অনেক দেশের অনেক ধরনের ডেটার জন্য AWS-এর নিজের বানানো detector (credit card number, আমেরিকার social security number, passport number, কয়েকটা দেশের জাতীয় পরিচয়পত্র আর tax number, AWS secret access key…)। ভরসা করার আগে তালিকায় তোমার দেশ আছে কি না দেখে নাও।
• Custom data identifier: তোমার নিজের detector: একটা regular expression, চাইলে সাথে কিছু keyword যা কাছাকাছি থাকতেই হবে, আর সর্বোচ্চ কত দূরত্বে। Managed তালিকায় নেই এমন format-এর জন্য এগুলো: বাংলাদেশের NID number, ভেতরের customer ID, ঋণ account-এর format।
• Allow list: যেসব লেখা বা pattern Macie-কে উপেক্ষা করতে হবে, যেমন তোমার নিজের public hotline number বা test data, যাতে আসল finding বাড়তি শব্দের নিচে চাপা না পড়ে।

সে দুইভাবে খোঁজে:

• Automated sensitive data discovery: Macie সারাক্ষণ তোমার সব bucket থেকে প্রতিনিধি কিছু object বেছে নিয়ে পরীক্ষা করে, আর কম খরচে একটা মানচিত্র বানায় কোথায় সংবেদনশীল ডেটা থাকার সম্ভাবনা। শত শত bucket জুড়ে বড় ছবিটা দেখার জন্য ভালো।
• Sensitive data discovery job: তুমি bucket, নমুনা কতটা গভীরে নেবে আর filter বেছে দাও, তারপর job একবার চালাও বা schedule করো (রোজ, সপ্তাহে, মাসে)। নির্দিষ্ট কিছু bucket-এর গভীর, লক্ষ্যভেদী audit-এর জন্য ভালো।

#Bucket inventory আর policy finding

চালু হওয়ামাত্র Macie তোমার S3 general purpose bucket-গুলোর একটা inventory রাখে, আর প্রতিটার নিরাপত্তা আর access control-এর দিকে নজর রাখে: কোন bucket public, কোনটায় default encryption নেই, কোনটা অন্য account-এর সাথে share করা, আর Block Public Access চালু আছে কি না। কোনো bucket-এর অবস্থা খারাপ হলে (Block Public Access বন্ধ, bucket public হয়ে গেল, default encryption সরানো হলো) Macie একটা policy finding তোলে। কোনো object-এ সংবেদনশীল ডেটা পেলে তোলে একটা sensitive data finding, যেমন SensitiveData:S3Object/Personal বা SensitiveData:S3Object/Financial।

Customer managed key দিয়ে SSE-KMS-এ encrypt করা object পড়তে হলে key policy-তে Macie-র service-linked role-কে key ব্যবহারের অনুমতি দিতে হবে (লেসন ২১.২); নইলে object-গুলো বাদ পড়ে যায়। SSE-C দিয়ে encrypt করা object কখনোই বিশ্লেষণ করা যায় না, কারণ AWS সেই key রাখেই না (লেসন ১০.৮)।

Finding যায় EventBridge-এ (event হিসেবে, alert আর automation-এর জন্য), আর চাইলে Security Hub-এ। Macie খবর দেয়; কিছু মোছে না, সরায় না, তালাও দেয় না। AWS Organizations থাকলে Macie-র একজন delegated administrator সব member account-এ Macie চালু করে আর job চালায়। নতুন account bucket monitoring আর automated discovery-র জন্য ৩০ দিনের free trial পায়; discovery job-এর জন্য সবসময় যাচাই করা ডেটার পরিমাণ অনুযায়ী দাম লাগে।

#AWS Security Hub: সব finding এক জায়গায়

#Security Hub কী করে

২০টা account আর কয়েকটা Region-এ পাঁচটা security service থাকলে কেউ সব console খুলে দেখতে পারে না। AWS Security Hub দেয় একটাই দৃশ্য:

• Finding জড়ো করে GuardDuty, Inspector, Macie, IAM Access Analyzer, Firewall Manager, Systems Manager আর অনেক partner product থেকে, একটা format-এ বদলে: AWS Security Finding Format (ASFF)।
• Security standard চালায় (cloud security posture management, CSPM): AWS Foundational Security Best Practices, CIS AWS Foundations Benchmark, PCI আর NIST standard অনুযায়ী স্বয়ংক্রিয় যাচাই। প্রতিটা control (“S3 bucket-এ public access আটকানো থাকা উচিত”, “কোনো security group যেন যেকোনো জায়গা থেকে port 22 খুলে না রাখে”) একটা passed বা failed finding দেয়, আর একটা security score-এ যোগ হয়। বেশিরভাগ control চলে service-linked AWS Config rule হিসেবে, তাই যেসব account আর Region যাচাই করবে, সবখানে AWS Config চালু থাকতে আর record করতে হবে (লেসন ১৯.৭)।
• Cross-Region aggregation: কয়েকটা Region-কে একটা home Region-এর সাথে জোড়ো, আর সেখানেই সব finding দেখো।
• Multi-account: AWS Organizations-এর একজন delegated administrator এক জায়গা থেকে চালু করে, কোথায় কোন standard চলবে তার জন্য central configuration policy-সহ।
• Automation rule: finding আসার সাথে সাথে বদলে দেয় (production account-এর severity বাড়ানো, জানা ভুল সতর্কবার্তা চাপা দেওয়া, একটা note যোগ করা)।
• EventBridge integration: প্রতিটা finding EventBridge-এ যায়; rule চালায় Lambda, Step Functions, SSM Automation বা ticketing system। Custom action দিয়ে analyst এক click-এ বেছে নেওয়া একটা finding কোনো workflow-এ পাঠাতে পারে।

Security Hub শুধু সেই finding দেখায় যেগুলো চালু করার পরে তৈরি হয়েছে, আর শুধু যেসব Region-এ চালু করা হয়েছে সেখানে। ৩০ দিনের free trial আছে; তারপর প্রতিটা যাচাই আর প্রতিটা ঢোকা finding অনুযায়ী দাম।

#Security Hub আর Security Hub CSPM (২০২৫)

#Detective আর অন্যান্য security service

#Amazon Detective

Amazon Detective তদন্ত করে। সে নিজে থেকেই CloudTrail management event, VPC flow log, GuardDuty finding (আর চাইলে EKS audit log আর Security Hub finding) সংগ্রহ করে, আর machine learning, পরিসংখ্যান আর graph theory দিয়ে একটা behaviour graph বানায়। একটা finding থেকে তুমি একটা entity-তে (একটা IAM role, একটা IP address, একটা instance) চলে যাও আর সময়ের সাথে তার কাজকর্ম দেখো: প্রথম কবে দেখা গেল, কী কী call করল, কোন কোন resource ছুঁলো, তার জন্য স্বাভাবিক কোনটা। Finding group সম্পর্কিত finding-গুলো একসাথে রাখে। Detective কোনো alert তৈরি করে না, কিছু ঠিকও করে না: GuardDuty ধরে, Detective মূল কারণ ব্যাখ্যা করে।

#বাকিদের নিয়ে এক লাইন করে

• AWS CloudTrail লিখে রাখে কে কোন API call করল, কখন, কোথা থেকে: এখানকার সবকিছুর পেছনের audit trail (লেসন ১৯.৬)।
• AWS Config সময়ের সাথে প্রতিটা resource-এর configuration লিখে রাখে আর rule দিয়ে যাচাই করে (“এই volume কি encrypt করা?”); Security Hub-এর standard এর ওপরেই চলে (লেসন ১৯.৭)।
• IAM Access Analyzer খুঁজে দেয় কোন resource তোমার account বা organization-এর বাইরে share করা (external access), কোন role, key আর permission অব্যবহৃত, আর policy যাচাই করে (লেসন ২.৪, লেসন ১০.২)।
• AWS Artifact হলো AWS-এর নিজের compliance report (SOC, ISO certification, PCI) আর BAA-র মতো চুক্তি নিজে নামিয়ে নেওয়ার portal: “auditor-এর জন্য AWS-এর compliance report নামাও” → Artifact।
• AWS Audit Manager তোমার account থেকে সারাক্ষণ প্রমাণ সংগ্রহ করে আর একটা framework-এর (যেমন CIS বা GDPR) সাথে মিলিয়ে তোমার audit-এর প্রস্তুতি নেয়।
• AWS Trusted Advisor-এর best-practice যাচাইয়ের মধ্যে security-র যাচাইও আছে (খোলা port, root-এর MFA, ফাঁস হওয়া access key, public snapshot) (লেসন ২৬.১)।
• WAF, Shield আর Firewall Manager সীমানায় হামলা আটকায় আর সামলায় (লেসন ২১.৬); এরা আটকায়, account-এর ভেতরে দখল হয়ে যাওয়া ধরে না।

#একটা ঘটনা, সবার চোখে

Service-গুলো সবচেয়ে কাজে লাগে একসাথে। নিচের animation-এ একটা online shop-এর ওপর একই হামলা একেক service একেকভাবে দেখে। প্রথম রূপে সতর্কবার্তা উপেক্ষা করা হয়; দ্বিতীয় রূপে তার ওপর ব্যবস্থা নেওয়া হয়।

#কোন service? অনুশীলন করো

#কোথায় কোথায় ভুল হয়

#System design-এ threat detection

#প্রতিটা account-এর জন্য একটা ভিত্তি

Multi-account landing zone-এ threat detection প্রতিটা application-এর আলাদা project না; এটা organization-এর বসানো একটা ভিত্তি (baseline):

1. একটা আলাদা security tooling account হয় GuardDuty, Inspector, Macie, Detective আর Security Hub-এর delegated administrator।
2. প্রতিটা service আগের আর নতুন প্রতিটা member account-এ, প্রতিটা Region-এ, নিজে থেকে চালু হয়।
3. Security Hub একটা home Region-এ জড়ো করে; প্রতিটা account আর Region-এ AWS Config record করে।
4. Security account-এর EventBridge rule Critical আর High finding পাঠায় on-call channel-এ আর ভালোভাবে পরীক্ষা করা remediation function-এ।
5. SCP (লেসন ২০.১) member account-কে GuardDuty, Security Hub বা Config বন্ধ করতে দেয় না।

#সাবধানে automate করো

নিজে থেকে ব্যবস্থা নেওয়া শক্তিশালী, আবার বিপজ্জনকও। ভালো প্রার্থী সেগুলো যেগুলো ফিরিয়ে আনা যায় আর ভালোভাবে বোঝা: instance আলাদা করা (তদন্তের জন্য রেখে দাও), access key বন্ধ করা, Block Public Access আবার চালু করা, একটা IP আটকানো। খারাপ প্রার্থী সেগুলো যেগুলো ধ্বংস করে: instance terminate করা (প্রমাণ হারিয়ে যায়), ডেটা মোছা। শুরু করো খবর দেওয়া দিয়ে, তারপর যে ব্যবস্থাগুলো অনেকবার দেখেছ সেগুলো automate করো। Suppression rule আর allow list ব্যবহার করো, যাতে মানুষের কাছে পৌঁছানো প্রতিটা alert পড়ার মতো হয়; alert-এ ক্লান্ত হয়ে গেলেই আসল finding উপেক্ষিত হয়।

#খরচ

পাঁচটা service-ই ব্যবহার অনুযায়ী দাম নেয় (বিশ্লেষণ করা event, scan করা resource, যাচাই করা ডেটা, ঢোকা finding), আর সবগুলো একটা free trial দিয়ে শুরু হয়। সবখানে সবকিছু চালু করার আগে trial-এর ব্যবহারের হিসাব দেখে নাও: petabyte log-এর ওপর Macie discovery job, বা খুব ব্যস্ত একটা bucket-এ S3 data event monitoring খরুচে হতে পারে। Macie-র automated discovery নমুনা নিয়ে কাজ করে, এজন্যই সেটা সস্তা default।

#নিজে করে দেখো

এই command-গুলো একটা test account-এর জন্য। এগুলো service চালু করে, sample finding বানায়, আর একটা ব্যবস্থা জুড়ে দেয়।

# 1. GuardDuty: enable, create sample findings, list them
aws guardduty create-detector --enable --region ap-south-1
# { "DetectorId": "12abc34d567e8fa901bc2d34e56789f0" }
DET=12abc34d567e8fa901bc2d34e56789f0
aws guardduty create-sample-findings --detector-id $DET \
  --finding-types "CryptoCurrency:EC2/BitcoinTool.B!DNS"
aws guardduty list-findings --detector-id $DET \
  --finding-criteria '{"Criterion":{"severity":{"Gte":7}}}'
# { "FindingIds": [ "a2b4c6d8e0f1a3b5c7d9e1f3a5b7c9d1" ] }
aws guardduty get-findings --detector-id $DET \
  --finding-ids a2b4c6d8e0f1a3b5c7d9e1f3a5b7c9d1 \
  --query 'Findings[].[Type,Severity,Resource.InstanceDetails.InstanceId]'
# [ [ "CryptoCurrency:EC2/BitcoinTool.B!DNS", 8, "i-99999999" ] ]   (sample findings use placeholder IDs)

# 2. Route High findings to email through EventBridge and SNS
aws events put-rule --name guardduty-high \
  --event-pattern '{"source":["aws.guardduty"],"detail-type":["GuardDuty Finding"],"detail":{"severity":[{"numeric":[">=",7]}]}}'
aws events put-targets --rule guardduty-high \
  --targets Id=sec-email,Arn=arn:aws:sns:ap-south-1:111122223333:security-alerts
# (the SNS topic's access policy must allow events.amazonaws.com to publish)

# 3. Inspector: activate EC2, ECR and Lambda scanning, then read critical findings
aws inspector2 enable --resource-types EC2 ECR LAMBDA LAMBDA_CODE
# { "accounts": [ { "accountId": "111122223333", "status": "ENABLING", ... } ] }
aws inspector2 list-coverage \
  --filter-criteria '{"resourceType":[{"comparison":"EQUALS","value":"AWS_EC2_INSTANCE"}]}' \
  --query 'coveredResources[].[resourceId,scanStatus.reason]'
# [ [ "i-0abc1234def567890", "SUCCESSFUL" ], [ "i-0fed9876cba543210", "UNMANAGED_EC2_INSTANCE" ] ]
aws inspector2 list-findings \
  --filter-criteria '{"severity":[{"comparison":"EQUALS","value":"CRITICAL"}]}' \
  --query 'findings[].[title,inspectorScore,resources[0].id]'
# [ [ "CVE-2021-44228 - org.apache.logging.log4j:log4j-core", 10.0,
#     "arn:aws:ecr:ap-south-1:111122223333:repository/shop-api/sha256:4f2e..." ] ]

# 4. Macie: enable, add a custom data identifier for NID numbers, run a one-time job
aws macie2 enable-macie
aws macie2 create-custom-data-identifier --name bd-nid \
  --regex '\b(\d{10}|\d{13}|\d{17})\b' --keywords NID "National ID" \
  --maximum-match-distance 30
# { "customDataIdentifierId": "3a1b2c3d-4e5f-6a7b-8c9d-0e1f2a3b4c5d" }
aws macie2 create-classification-job --job-type ONE_TIME --name exports-audit \
  --custom-data-identifier-ids 3a1b2c3d-4e5f-6a7b-8c9d-0e1f2a3b4c5d \
  --s3-job-definition '{"bucketDefinitions":[{"accountId":"111122223333","buckets":["exports-example"]}]}'
# { "jobArn": "arn:aws:macie2:ap-south-1:111122223333:classification-job/...", "jobId": "..." }
aws macie2 list-findings --finding-criteria '{"criterion":{"category":{"eq":["CLASSIFICATION"]}}}'

# 5. Security Hub CSPM: enable with default standards, then read failed controls
aws securityhub enable-security-hub --enable-default-standards
aws securityhub get-findings --max-items 3 \
  --filters '{"ComplianceStatus":[{"Value":"FAILED","Comparison":"EQUALS"}],"SeverityLabel":[{"Value":"HIGH","Comparison":"EQUALS"}]}' \
  --query 'Findings[].[Title,Resources[0].Id]'
# [ [ "Security groups should not allow ingress from 0.0.0.0/0 to port 22",
#     "arn:aws:ec2:ap-south-1:111122223333:security-group/sg-0123456789abcdef0" ] ]

# 6. Clean up the test account
aws guardduty delete-detector --detector-id $DET
aws inspector2 disable --resource-types EC2 ECR LAMBDA LAMBDA_CODE
aws macie2 disable-macie
aws securityhub disable-security-hub

Console-এ ১ নম্বর ধাপের পরে GuardDuty-র Findings page খোলো আর একটা sample finding পুরোটা পড়ো: resource, actor, action, severity। তারপর Security Hub-এর Controls page খুলে সেই control-গুলো খোঁজো যেগুলো “No data” দেখাচ্ছে: ওগুলোই AWS Config-এর অপেক্ষায় বসে আছে।

#সারসংক্ষেপ

মূল কথা

• ধরার ব্যবস্থা আটকানোর ব্যবস্থাকে পূর্ণ করে। প্রতিটা service একটা প্রশ্নের উত্তর দেয়: GuardDuty (এখন হামলা হচ্ছে?), Inspector (কোথায় হামলা হতে পারে?), Macie (সংবেদনশীল ডেটা কোথায়?), Security Hub (সব মিলিয়ে ছবি), Detective (ঘটনাটা কীভাবে ঘটল?)।
• GuardDuty: CloudTrail management event, VPC flow log আর DNS log-এর ওপর ML + threat intelligence + anomaly detection, পড়া হয় নিজের feed থেকে (তোমাকে আর কিছু চালু করতে হয় না)। Protection plan যোগ করে S3 data event, EKS audit log, Runtime Monitoring (agent), Malware Protection (EC2 volume, S3 upload), RDS login, Lambda-র network কার্যকলাপ। Regional, এক click, ৩০ দিনের trial, crypto-mining-এর আলাদা finding। সে শুধু ধরে: EventBridge দিয়ে finding SNS বা Lambda-য় পাঠাও।
• Inspector: শুধু EC2, ECR image আর Lambda-র জন্য সারাক্ষণ vulnerability management। Package-এ CVE, EC2-এর network reachability, Lambda-র code scanning। EC2 scan হয় SSM Agent দিয়ে বা agentless EBS snapshot থেকে (hybrid mode)। নতুন CVE এলে আবার scan, finding-এর score দেয় CVSS থেকে তোমার পরিবেশ অনুযায়ী বদলে, পাঠায় EventBridge আর Security Hub-এ।
• Macie: শুধু S3-এ PII খোঁজার জন্য ML + pattern matching; managed আর custom data identifier, allow list, automated discovery (নমুনা) বনাম discovery job; public, encryption-হীন বা share করা bucket-এর জন্য policy finding-সহ bucket inventory। নাম Amazon Macie; সে খবর দেয়, আটকায় না।
• Security Hub: অনেক service আর account-এর finding (ASFF) জড়ো করে, standard (AWS Foundational Security Best Practices, CIS…) চালায় যার জন্য AWS Config লাগে, automation rule, cross-Region aggregation, EventBridge। ২০২৫ থেকে ওই service-এর নাম Security Hub CSPM, আর নতুন Security Hub তার ওপর exposure জুড়ে দেখায়।
• Detective behaviour graph দিয়ে মূল কারণের তদন্ত করে। Config = setting, CloudTrail = API call, Access Analyzer = বাইরের আর অব্যবহৃত access, Artifact = AWS-এর report, Audit Manager = তোমার প্রমাণ, WAF/Shield = আটকানো।

নিজেকে যাচাই করো: threat detection আর security service৩০টি প্রশ্ন