AWS CloudTrail

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

• AWS CloudTrail কী রেকর্ড করে, বুঝিয়ে বলতে (API call আর sign-in: কে, কী করল, কখন, কোথা থেকে, আর কাজটা হলো কি না), আর কী রেকর্ড করে না সেটাও।
• Event history ব্যবহার করতে: default-এই চালু, প্রতিটা Region-এ গত ৯০ দিনের management event, ফ্রি, শুধু পড়া যায়।
• একটা trail বানাতে: multi-Region না single-Region, management account বা delegated administrator থেকে organization trail, S3-এ পাঠানো (গড়ে মোটামুটি ৫ মিনিটে) আর চাইলে CloudWatch Logs-এও, SNS notification, SSE-KMS।
• Event-এর ধরনগুলো আলাদা করে চিনতে: management (read আর write, default-এ চালু, প্রথম কপি ফ্রি), data (S3 object, Lambda Invoke, DynamoDB item…, default-এ বন্ধ, টাকা লাগে), Insights (অস্বাভাবিক API call rate আর error rate) আর network activity event (VPC endpoint)।
• Audit log বছরের পর বছর রাখতে আর প্রমাণ করতে যে কেউ বদলায়নি: S3 Lifecycle দিয়ে Glacier, Athena, log file integrity validation, bucket-এর সুরক্ষা আর আলাদা একটা log archive account।
• EventBridge দিয়ে যেকোনো রেকর্ড হওয়া API call-এ কয়েক সেকেন্ডে সাড়া দিতে, root sign-in-সহ; আর CloudTrail Lake কোথায় বসে (আর ২০২৬-এ তার অবস্থা কী) তা জানতে।

#CloudTrail কেন: account-এর CCTV camera

অধ্যায় ১৯ চারটা service নিয়ে, যারা একটা AWS account-এর ওপর নজর রাখে, আর পরীক্ষা scenario-র শব্দ দেখে এদের একটাকে বেছে নিতে বলে। Performance-এর সংখ্যা আর application-এর log হলো CloudWatch (লেসন ১৯.১ থেকে ১৯.৪); কিছু ঘটলে সাথে সাথে সাড়া দেওয়া হলো EventBridge (১৯.৫); একটা resource দেখতে কেমন ছিল আর নিয়ম মেনে চলছে কি না, সেটা Config (১৯.৭)। এই লেসন চার নম্বরটা নিয়ে: কে কোন API call করেছে।

#সমস্যাটা কী

শুক্রবার রাত ১১টা, ঢাকার একটা online shop। DynamoDB-র orders table উধাও। Application বন্ধ, backup থেকে ডেটা ফিরবে ঠিকই, কিন্তু ম্যানেজাররা সবচেয়ে স্বাভাবিক প্রশ্নটাই করেন: কে মুছল, কোথা থেকে, আর এটা ভুল না হামলা? কেউ মনে করতে পারছে না সে করেছে। Table নিজে কিছু বলতে পারবে না; সে তো আর নেই-ই।

AWS-এ প্রতিটা কাজ, সেটা console-এ একটা click হোক, CLI-র একটা command, application থেকে SDK call, নাকি তোমার হয়ে অন্য কোনো AWS service-এর call, শেষ পর্যন্ত একটা AWS API-র কাছে request হয়ে যায়। প্রতিটা request যদি লিখে রাখা হয়, তাহলে প্রশ্নের উত্তর আছে। সেই লিখে রাখা খাতাটাই AWS CloudTrail।

#CloudTrail জিনিসটা কী

AWS CloudTrail তোমার AWS account-এর API call আর sign-in-এর কাজকর্ম রেকর্ড করে, governance, compliance, operational আর risk audit-এর জন্য:

• প্রতিটা account-এ এটা default-এই চালু। গত ৯০ দিনের management কাজকর্ম পেতে কিছুই চালু করতে হয় না।
• Console, CLI, SDK আর অন্য AWS service থেকে আসা call রেকর্ড করে (CloudFormation তোমার হয়ে একটা instance বানালে রেকর্ডে লেখা থাকে call-টা CloudFormation করেছে)।
• প্রতিটা রেকর্ড বলে কে call করেছে (IAM user, role session, root user, নাকি কোনো AWS service), কী call হয়েছে (service আর action, parameter-সহ), কখন (UTC সময়ে), কোথা থেকে (source IP address, Region, user agent), আর কাজ হয়েছে কি না (ব্যর্থ হলে AccessDenied-এর মতো error code)।
• রেকর্ডগুলো অনেকদিন রাখা যায় S3-এ, খোঁজা যায় CloudWatch Logs-এ, query করা যায় Athena দিয়ে, আর EventBridge দিয়ে নিজে থেকে ব্যবস্থা নেওয়া যায়।

#একটা event record দেখতে কেমন

প্রতিটা call একটা JSON event হয়ে যায়। শুক্রবার রাতের ঘটনারটা, ছোট করে:

{
  "eventVersion": "1.10",
  "userIdentity": {
    "type": "AssumedRole",
    "arn": "arn:aws:sts::111122223333:assumed-role/ops-admin/rafi",
    "accountId": "111122223333",
    "sessionContext": { "attributes": { "mfaAuthenticated": "true" } }
  },
  "eventTime": "2026-10-30T17:02:44Z",
  "eventSource": "dynamodb.amazonaws.com",
  "eventName": "DeleteTable",
  "awsRegion": "ap-southeast-1",
  "sourceIPAddress": "198.51.100.7",
  "userAgent": "aws-cli/2.17.0 Python/3.12 Linux",
  "requestParameters": { "tableName": "orders" },
  "responseElements": { "tableDescription": { "tableStatus": "DELETING" } },
  "readOnly": false,
  "eventType": "AwsApiCall",
  "managementEvent": true,
  "eventCategory": "Management",
  "recipientAccountId": "111122223333"
}

শুক্রবারের প্রশ্নের উত্তর প্রথম কয়েক লাইনেই আছে: রাফি, MFA দিয়ে ops-admin role-এ ঢুকে, CLI থেকে, 198.51.100.7 IP থেকে, ঢাকার সময়ে রাত ১১:০২-এ। একটা script ভুল environment-এর দিকে তাক করা ছিল। CloudTrail ঘটনাটা আটকায়নি; কয়েক মিনিটের মধ্যে team-কে হুবহু বলে দিয়েছে কী হয়েছিল, আর তারপর সমাধান এসেছে (একটা SCP, আর production table-এ deletion protection চালু)।

#Event history: কিছু না করেই চালু

CloudTrail ব্যবহার শুরু করতে কিছু বানাতে হয় না। Account খোলার দিন থেকেই Event history আছে:

• এতে থাকে প্রতিটা Region-এ গত ৯০ দিনের management event (read আর write)। যে Region-এ call হয়েছিল সেখানে খোঁজো; IAM-এর মতো global service দেখা যায় us-east-1-এ।
• এটা ফ্রি, console-এ খোঁজা যায় (একবারে একটা attribute দিয়ে filter: event name, user name, resource type বা নাম, event source, access key, read-only, event ID), aws cloudtrail lookup-events দিয়েও, আর CSV বা JSON হিসেবে download করা যায়।
• এটা বদলানো যায় না: কেউ এর event edit বা মুছতে পারে না, আর তোমার trail-এ কী বদলাচ্ছ তাতে এর কিছু যায় আসে না।
• এতে data event, network activity event বা ৯০ দিনের পুরোনো কিছু থাকে না, আর মেয়াদ বাড়ানোও যায় না।

“গত কয়েক সপ্তাহে কী হয়েছে?” প্রশ্নের জন্য Event history-ই প্রথম জায়গা। কিন্তু এটা audit-এর archive না: জানালাটা সামনে সরতেই থাকে, আর গত বছর নিয়ে auditor-এর প্রশ্নে এখানে কিছুই পাওয়া যাবে না।

#Trail: ৯০ দিনের পরেও event রেখে দেওয়া

Trail হলো একটা configuration, যেটা CloudTrail-এর event তোমার বাছা একটা S3 bucket-এ পাঠায়, আর চাইলে CloudWatch Logs-এ, আর (default event bus হয়ে) EventBridge-এ। Trail থাকলে event যতদিন খুশি রাখা যায়, আর data, Insights আর network activity event-ও যোগ করা যায়।

#Multi-Region নাকি single-Region

• Multi-Region trail account-এর সব চালু Region-এর event রেকর্ড করে একটা bucket-এ পাঠায়। সাথে global service-এর event-ও (IAM, STS-এর global endpoint, CloudFront, Route 53…) রেকর্ড করে, যেগুলো us-east-1-এর event হিসেবে লেখা হয়। এটাই best practice, আর console-এ বানানো প্রতিটা trail multi-Region।
• Single-Region trail শুধু যে Region-এ বানানো হয়েছে সেটা রেকর্ড করে। এটা বানানো যায় শুধু CLI বা API দিয়ে, যেখানে --is-multi-region-trail না দিলে এটাই default। us-east-1-এর বাইরে একটা single-Region trail IAM-এর সব পরিবর্তন মিস করে, audit-এ এটা একটা চেনা ফাঁক।
• একটা account-এ প্রতি Region-এ সর্বোচ্চ ৫টা trail থাকতে পারে। Bucket যেকোনো Region-এ হতে পারে।

(Slide বলে trail “default-এ” সব Region-এ চলে: console-এর বেলায় সত্যি, CLI আর API-র বেলায় উল্টো।)

#পৌঁছানো আর খুঁটিনাটি

• CloudTrail মোটামুটি প্রতি ৫ মিনিটে bucket-এ gzip করা JSON log file লেখে, আর একটা event সাধারণত API call-এর গড়ে মোটামুটি ৫ মিনিটের মধ্যে পৌঁছায়। এটা real time না, আর কোনো guarantee-ও নেই।
• File যায় একটা নির্দিষ্ট ধাঁচের prefix-এ: AWSLogs/<account-id>/CloudTrail/<region>/<yyyy>/<mm>/<dd>/। Organization trail এর সাথে organization ID যোগ করে।
• Bucket policy-কে CloudTrail service-কে bucket-এর ACL দেখতে আর object লিখতে দিতে হয়, ভালো হয় aws:SourceArn condition দিয়ে শুধু তোমার trail-এ সীমাবদ্ধ রাখলে। Console এই policy তোমার হয়ে লিখে দেয়।
• Encryption: log file at rest সবসময় encrypted থাকে। নতুন trail-এর জন্য console customer managed key দিয়ে SSE-KMS প্রস্তাব করে; না নিলে SSE-S3। SSE-KMS হলে পড়তে চাইলে S3-এর access-এর সাথে key-তে kms:Decrypt-ও লাগে (লেসন ২১.২)।
• SNS notification প্রতিটা নতুন log file পৌঁছানোর খবর দিতে পারে, যাতে log process করার system জানে কখন পড়তে হবে।
• CloudWatch Logs-এ পাঠালে একই event একটা log group-এ যায় (সেখানে লিখতে CloudTrail-এর একটা IAM role লাগে)। Event-এর ওপর metric filter আর alarm এভাবেই হয়, যেমন ব্যর্থ sign-in-এর ওপর (লেসন ১৯.২ আর ১৯.৩)।
• Bucket-এ পৌঁছানো না গেলে (মুছে গেছে, policy ভেঙেছে) CloudTrail ৩০ দিন ধরে চেষ্টা চালিয়ে যায়, আর ওই event-গুলোর টাকাও লাগে। ভাঙা trail ঠিক করো বা মুছে দাও।

#Organization trail

AWS Organizations-এ একটা organization trail organization-এর প্রতিটা account-এর event এক জায়গায় লগ করে:

• এটা বানানো হয় management account-এ, অথবা CloudTrail-এর জন্য একটা delegated administrator account-এ (note-এ লেখা “master account”, যেটা management account-এর পুরোনো নাম)।
• এটা সব member account-এ নিজে থেকেই লাগে, পরে যারা যোগ হয় তাদেরও।
• Member account trail-টা দেখতে পারে, কিন্তু বদলাতে বা মুছতে পারে না, আর default-এ এর log file পড়তেও পারে না।
• Best practice হলো এটা আলাদা একটা log archive account-এর bucket-এ পাঠানো, যেটা শুধু security team-এর নিয়ন্ত্রণে। Organizations, SCP আর delegated administrator আছে লেসন ২০.১-এ।

#Event-এর ধরন: কোনটা রেকর্ড হয়

CloudTrail কাজকর্মকে চার ধরনের event-এ ভাগ করে। শুধু প্রথমটা default-এ চালু।

#Management event (control plane)

Management event হলো তোমার account-এর resource-এর ওপর কাজ: বানানো, সাজানো, মোছা, আর তাদের configuration পড়া। Note আর slide-এর উদাহরণ: RunInstances (EC2), CreateBucket (S3), CreateUser আর AttachRolePolicy (IAM, security সাজানো), CreateSubnet (EC2, routing), CreateTrail (logging চালু করা)। Console sign-in-ও management event হিসেবে রেকর্ড হয়।

• Default-এ চালু, Event history-তে আর প্রতিটা নতুন trail-এ।
• দুই ভাগে: write event (কিছু বদলাতে পারে: DeleteTable) আর read event (কিছু বদলায় না: DescribeInstances, ListBuckets, GetSecretValue)। Trail সব, শুধু read, বা শুধু write লগ করতে পারে।
• Volume কমাতে trail চাইলে AWS KMS event বাদ দিতে পারে (Encrypt, Decrypt, GenerateDataKey হলো read management event, আর সংখ্যায় অনেক হতে পারে), RDS Data API event-ও।
• খরচ: প্রতিটা Region-এ management event-এর প্রথম কপি ফ্রি। একই management event আবার লগ করা দ্বিতীয় একটা trail-এর খরচ প্রতি ১,০০,০০০ event-এ ২ USD।

#Data event (data plane)

Data event হলো কোনো resource-এর ওপর বা ভেতরে কাজ, সাধারণত বিপুল সংখ্যায়:

• S3 object-স্তরের কাজ: GetObject, PutObject, DeleteObject (read আর write আলাদা করে লগ করা যায়)।
• Lambda function চালানো: Invoke API।
• DynamoDB item-স্তরের কাজ: GetItem, PutItem, DeleteItem, query।
• আর আরও অনেক ধরনের resource: S3 Express One Zone, SNS publish, EBS direct API, ইত্যাদি।

এগুলো default-এ বন্ধ, কারণ একটা ব্যস্ত bucket বা function ঘণ্টায় লাখ লাখ event বানায়। প্রতিটা trail-এ advanced event selector দিয়ে চালু করতে হয়, যেটা দিয়ে logging একটা bucket, একটা prefix, একটা action (eventName)-এ সীমাবদ্ধ রাখা যায়, বা একটা role বাদ দেওয়া যায়। খরচ: প্রতি ১,০০,০০০ data event-এ ০.১০ USD। Data event কখনো Event history-তে আসে না।

#Insights event

CloudTrail Insights অস্বাভাবিক কাজকর্ম ধরে: তোমার account আর Region-এ API call আর API error-এর স্বাভাবিক হার কত (baseline) সেটা শিখে নেয়, আর এখনকার হার সেখান থেকে অনেক দূরে সরে গেলে একটা Insights event লেখে। দুই ধরনের:

• API call rate: মিনিটে কতগুলো write management event।
• API error rate: মিনিটে কতগুলো management call ব্যর্থ হচ্ছে (read আর write)।

২০২৫-এর নভেম্বর থেকে একটা trail data event-এর ওপরও দুই ধরনের Insights চালাতে পারে। Insights default-এ বন্ধ, আর যত event বিশ্লেষণ করে তার হিসাবে টাকা লাগে (প্রতি Insights ধরনে প্রতি ১,০০,০০০ management event-এ ০.৩৫ USD)। খুঁটিনাটি পরের অংশে।

#Network activity event (পাশের কথা, ২০২৪–২৫)

Network activity event তোমার VPC endpoint দিয়ে যাওয়া AWS API call endpoint-এর মালিকের জন্য রেকর্ড করে, endpoint policy যেগুলো আটকে দেয় সেগুলোসহ (VpceAccessDenied)। যেমন এতে দেখা যায় তোমার organization-এর বাইরের credential তোমার KMS বা S3 endpoint ব্যবহার করার চেষ্টা করছে। এগুলো default-এ বন্ধ, advanced event selector দিয়ে service ধরে ধরে বাছতে হয়, আর প্রতি ১,০০,০০০-এ ০.১০ USD। জিনিসটা নতুন, পরীক্ষায় কমই আসে; VPC endpoint আছে লেসন ২২.২-এ।

এবার নিজে কয়েকটা আসল কাজ ঠিক ঘরে ফেলো। ফাঁদগুলোর দিকে চোখ রেখো: একটা KMS decrypt, একটা secret পড়া, আর একটা sign-in।

#CloudTrail Insights: অস্বাভাবিক কাজ ধরা

Insights হলো এই প্রশ্নের জন্য: “এই মুহূর্তে অদ্ভুত কিছু হচ্ছে কি?”, প্রতিটা সম্ভাব্য হামলার জন্য আলাদা rule না লিখেই। Slide-এ এমন কিছু সমস্যার কথা আছে যা এটা সামনে আনে: ভুলভাবে resource বানানো (একটা script দরকারের চেয়ে অনেক বেশি instance চালু করছে), service limit-এ ঠেকে যাওয়া, হঠাৎ অনেক IAM action, আর নিয়মিত রক্ষণাবেক্ষণের কাজে ফাঁক (রাতের একটা job হঠাৎ বন্ধ হয়ে গেছে)।

কীভাবে কাজ করে:

• Insights একটা trail-এর management event (আর চালু থাকলে data event) Region ধরে ধরে বিশ্লেষণ করে স্বাভাবিক call আর error হারের একটা baseline বানায়, আর সেটা বারবার ঠিক করতে থাকে।
• হার baseline থেকে ছিটকে গেলে Start চিহ্ন দেওয়া একটা Insights event লেখে; হার স্বাভাবিকে ফিরলে মিলিয়ে একটা End event আসে, কতক্ষণ চলল আর কোন user, user agent আর error code সবচেয়ে বেশি জড়িত ছিল তা-সহ।
• Insights event যায় trail-এর S3 bucket-এর আলাদা একটা folder-এ, console-এর Insights page-এ ৯০ দিন দেখা যায়, আর EventBridge-এ পাঠানো হয় (যাতে একটা rule কাউকে ডাকতে পারে)।
• একটা trail-এ প্রথমবার Insights চালু করার পরে প্রথম Insights event আসতে ৩৬ ঘণ্টা পর্যন্ত লাগতে পারে।

#বছরের পর বছর log রাখা: S3, lifecycle, Athena আর CloudWatch Logs

Event history রাখে ৯০ দিন। নিয়মকানুন প্রায়ই এর চেয়ে অনেক বেশি চায়: একটা bank-এর কয়েক বছরের audit রেকর্ড লাগতে পারে, একটা হাসপাতালের সাত বছর। Note আর slide-এর ধাঁচটা এমন:

১. একটা multi-Region trail (বা organization trail) একটা S3 bucket-এ log file পাঠায়। S3 যতদিন চাও ততদিন রাখে।

২. একটা S3 Lifecycle rule পুরোনো file সস্তা storage-এ সরায়, যেমন ৯০ দিন পরে Glacier Flexible Retrieval-এ, বা যেগুলো প্রায় কখনোই পড়া হবে না সেগুলো Glacier Deep Archive-এ, আর রাখার মেয়াদ শেষ হলে মুছে দেয় (লেসন ১০.৫)।

৩. প্রশ্ন করতে Athena S3-এর log file-এর ওপর সরাসরি SQL চালায় (slide-এর “S3-এ log করো আর Athena ব্যবহার করো”), CloudTrail format-এর তৈরি table definition দিয়ে, Region আর তারিখ ধরে partition করে (লেসন ১৭.১)। Glacier Flexible Retrieval বা Deep Archive-এর file আগে restore করতে হয়।

৪. Event-এর কোনো ধরন দেখে alert চাইলে trail CloudWatch Logs-এও পাঠায়, যেখানে একটা metric filter মিলে যাওয়া event গোনে আর একটা alarm SNS-কে জানায়।

#Audit trail-কে রক্ষা করা

যাদের audit হচ্ছে তারাই যদি audit log বন্ধ বা edit করতে পারে, সেই log কিছুই প্রমাণ করে না। হামলাকারীরা এটা জানে: সাবধানী অনুপ্রবেশকারী প্রথমেই logging থামাতে বা log মুছতে চেষ্টা করে। সুরক্ষার চারটা স্তর।

#১. কেউ camera বন্ধ করতে পারবে না

• Organization trail ব্যবহার করো: member account, তাদের administrator-রাও, এটা থামাতে, বদলাতে বা মুছতে পারে না।
• একটা SCP যোগ করো, যেটা একটা break-glass role ছাড়া সবার জন্য cloudtrail:StopLogging, cloudtrail:DeleteTrail আর cloudtrail:UpdateTrail (আর log bucket মোছা) নিষেধ করে (লেসন ২০.১; explicit deny-এর ধারণা আছে লেসন ২.২-এ)।
• তবু ওই call-গুলোর ওপর নজর রাখো: StopLogging-এর চেষ্টাটাও রেকর্ড হয়, আর একটা EventBridge rule এর ওপর alert দিতে পারে।

#২. কেউ footage মুছতে পারবে না

• Log পাঠাও আলাদা একটা log archive account-এর bucket-এ। তার bucket policy CloudTrail-কে লিখতে আর security team-কে পড়তে দেয়; workload account-এর কারও কোনো access নেই।
• Compliance mode-এ S3 Object Lock চালু করো (কেউ, archive account-এর root user-ও, retention-এর তারিখের আগে কোনো object মুছতে বা ওপরে লিখতে পারে না), অন্তত MFA Delete-সহ versioning (লেসন ১০.৯)।
• SSE-KMS দিয়ে encrypt করো, এমন একটা key দিয়ে যার policy শুধু CloudTrail-কে encrypt আর auditor-দের decrypt করতে দেয়।

#৩. যে কেউ প্রমাণ করতে পারবে footage অক্ষত: log file integrity validation

Log file integrity validation চালু থাকলে (console নতুন trail-এ এটা চালু করে দেয়; CLI-তে --enable-log-file-validation দিতে হয়) CloudTrail:

• প্রতি ঘণ্টায় একটা digest file একই bucket-এ লেখে (আলাদা একটা digest prefix-এ), যেখানে ওই ঘণ্টায় দেওয়া প্রতিটা log file-এর তালিকা থাকে তার SHA-256 hash-সহ;
• প্রতিটা digest file একটা private key দিয়ে sign করে, SHA-256 with RSA দিয়ে, আর প্রতিটা নতুন digest-এ আগের digest-এর hash আর signature বসিয়ে দেয়, ফলে digest-গুলো একটা না-ভাঙা শিকল হয়ে থাকে।

এরপর aws cloudtrail validate-logs CloudTrail-এর public key দিয়ে signature যাচাই করে আর প্রতিটা log file-এর hash নতুন করে বের করে। কোন log file বদলানো, মোছা বা সরানো হয়েছে, আর কোন digest file নেই বা বদলেছে, সব জানিয়ে দেয়। Validation কারসাজি ধরে; আটকায় না, তাই এটা ১ আর ২ নম্বর স্তরের সাথে মিলিয়ে চলে। পরীক্ষার ভাষা: “প্রমাণ করো log file-এ কেউ হাত দেয়নি” বা “CloudTrail log-এর integrity” → log file integrity validation।

#৪. কেউ চেষ্টা করলেই alert

StopLogging, DeleteTrail, data event বাদ দেওয়া PutEventSelectors, বা log bucket-এর policy বদলের ওপর একটা EventBridge rule (পরের অংশ) কয়েক সেকেন্ডে alert পাঠায়।

#API call-এ সাড়া দেওয়া: CloudTrail আর EventBridge

Log পেছনে ফিরে দেখার জন্য। প্রায়ই চাই নির্দিষ্ট কোনো call হলেই সঙ্গে সঙ্গে ব্যবস্থা নিতে। CloudTrail তার event একই Region-এর Amazon EventBridge-এর default event bus-এ পাঠায়, যেখানে event pattern-ওয়ালা একটা rule এদের যেকোনোটা মিলিয়ে Lambda, SNS, SQS বা Step Functions-এর মতো target চালাতে পারে (rule, pattern আর target আছে লেসন ১৯.৫-এ)।

Slide-এর উদাহরণ, আর note-এর root user-এর গল্প:

• কেউ DynamoDB-তে DeleteTable call করল → CloudTrail লগ করল → EventBridge rule → SNS alert।
• কেউ একটা স্পর্শকাতর IAM role-এ AssumeRole call করল → CloudTrail → EventBridge → SNS।
• কেউ security group-এর inbound rule বদলাল (AuthorizeSecurityGroupIngress) → CloudTrail → EventBridge → SNS, অথবা একটা Lambda function, যেটা port 22-এ 0.0.0.0/0-এর জন্য খোলা rule সরিয়ে দেয়।
• কেউ root user দিয়ে sign in করল → CloudTrail → EventBridge → security team-কে SNS email আর একটা Lambda function, যেটা একটা incident খোলে।

এটা কাজ করাতে যা জানতে হবে:

• Bus-এ যেসব ধরনের event আসে: AWS API Call via CloudTrail (API call), AWS Console Sign In via CloudTrail (sign-in), AWS Insight via CloudTrail (Insights), সাথে console action, service event আর network activity event।
• Account-টা logging চালু থাকা একটা trail-এর আওতায় থাকতে হবে (organization trail-ও চলবে)। শুধু Event history থেকে EventBridge-এ কিছু যায় না।
• সাধারণ enabled অবস্থার rule পায় write management event, sign-in, আর trail যেসব data event লগ করে সেগুলো। Read-only management event (Get, List, Describe) rule-এ পৌঁছায় শুধু তখনই, যখন তার state সব CloudTrail management event নেওয়ার জন্য বসানো থাকে।
• Event আসে যে Region-এ call রেকর্ড হয়েছে তার bus-এ। Root user-এর console sign-in রেকর্ড হয় us-east-1, us-east-2 বা us-west-2-এ, আর IAM ও অন্য global service us-east-1-এ। শুধু ap-southeast-1-এ বানানো rule এগুলো কখনো দেখে না। Rule ওই Region-গুলোতে বানাও, অথবা প্রতিটা Region-এ বানিয়ে একটা কেন্দ্রীয় bus-এ forward করো।
• এটা প্রায় real time (কয়েক সেকেন্ড থেকে কয়েক মিনিট), S3-এ log file-এর জন্য অপেক্ষার চেয়ে অনেক দ্রুত।

#কোথায় কোথায় গোলমাল হয়

• “Event-টা নেই।” Event history-তে ভুল Region (call অন্য জায়গায় হয়েছিল; IAM us-east-1-এ), trail ছাড়া ৯০ দিনের বেশি পুরোনো, অথবা এটা একটা data event ছিল যেটা কোনো trail লগ করছিল না।
• CLI দিয়ে বানানো single-Region trail বাকি সব Region আর IAM-এর পরিবর্তন মিস করে। Multi-Region trail ব্যবহার করো।
• Root sign-in-এর rule কখনো চলে না: us-east-1, us-east-2 আর us-west-2-এর বদলে workload-এর Region-এ বানানো হয়েছে, অথবা কোনো trail লগ করছে না।
• S3-এ কোনো log আসে না: bucket policy CloudTrail-কে অনুমতি দেয় না, KMS key policy CloudTrail-কে encrypt করতে দেয় না, বা bucket মুছে গেছে। CloudTrail ৩০ দিন চেষ্টা চালায়, আর trail-এর status-এ delivery error দেখায়।
• Data event-এর বিশাল bill: সব bucket-এর জন্য data event চালু, একটা ব্যস্ত static content bucket-সহ। Advanced event selector দিয়ে দরকারি bucket আর action-এ সীমাবদ্ধ রাখো।
• Management event-এর জন্য দুইবার টাকা: দ্বিতীয় একটা trail একই management event লগ করছে (শুধু প্রথম কপি ফ্রি)। Organization trail-এর সাথে পুরোনো account-ভিত্তিক trail রয়ে যাওয়া এর চেনা কারণ।
• S3-এর file থেকে real time আশা করা: পৌঁছাতে গড়ে মোটামুটি ৫ মিনিট লাগে, guarantee নেই। সঙ্গে সঙ্গে সাড়া দিতে EventBridge ব্যবহার করো।
• Log মুছে ফেলা যায়: trail bucket একই account-এ, Object Lock নেই, MFA Delete নেই, আর S3-এর permission ঢালাও। Validation ক্ষতিটা দেখাবে, কিন্তু ফেরত আনতে পারবে না।
• Insights একদিন ধরে চুপ: চালু করার পরে প্রথম Insights event আসতে ৩৬ ঘণ্টা পর্যন্ত লাগতে পারে; আর সফল read-এর বন্যা কখনো call-rate Insight চালু করে না।
• Athena পুরোনো log পড়তে পারে না: সেগুলো Glacier Flexible Retrieval বা Deep Archive-এ চলে গেছে, আগে restore লাগবে।

#System design-এ CloudTrail

• Multi-account landing zone: log archive account-এ একটা organization trail (প্রায়ই Control Tower বসিয়ে দেয়), Object Lock, validation, SSE-KMS, CloudTrail-কে রক্ষা করা একটা SCP, আর কেন্দ্রীয় bucket পড়তে Athena বা SIEM-ধাঁচের কোনো tool।
• Security automation: EventBridge-এ আসা CloudTrail event নিজে থেকে ব্যবস্থা চালায়: public security group rule সরানো, logging আবার চালু করা, অনুমোদিত Region-এর বাইরে বানানো resource-এ tag দেওয়া বা থামানো, root sign-in-এ কাউকে ডাকা।
• Incident-এর তদন্ত: গত কয়েক সপ্তাহের জন্য Event history, আরও পুরোনো event-এর জন্য trail bucket-এর ওপর Athena, আর GuardDuty, যেটা হুমকি খুঁজতে CloudTrail-এর management আর S3 data event পড়ে (লেসন ২১.৭)।
• Compliance: CloudTrail উত্তর দেয় “কে করেছে”, AWS Config উত্তর দেয় “resource দেখতে কেমন ছিল আর নিয়ম মানছিল কি না” (লেসন ১৯.৭)। Auditor-রা সাধারণত দুটোই চান।
• Least privilege: IAM Access Analyzer একটা role আসলে কোন কোন action ব্যবহার করেছে, CloudTrail থেকে পড়ে, তা দেখে policy বানিয়ে দেয় (লেসন ২.৪)।

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

এই command-গুলো AWS CLI v2-এর। Trail আর data event-এ টাকা লাগে (test account-এ সামান্য); শেষে মুছে দিও।

# ১. Event history: গত ৭ দিনে কে DynamoDB table মুছেছে (ফ্রি, management event, এই Region)
aws cloudtrail lookup-events --region ap-southeast-1 \
  --lookup-attributes AttributeKey=EventName,AttributeValue=DeleteTable \
  --start-time 2026-10-24T00:00:00Z \
  --query 'Events[].[EventTime,Username,EventName]' --output table
# -------------------------------------------------------
# |                    LookupEvents                     |
# +----------------------------+-------+----------------+
# |  2026-10-30T17:02:44+00:00 |  rafi |  DeleteTable   |
# +----------------------------+-------+----------------+

# ২. Log file validation আর SSE-KMS-সহ একটা multi-Region trail
#    (bucket আর তার CloudTrail bucket policy, আর KMS key policy আগে থেকেই থাকতে হবে)
aws cloudtrail create-trail --name org-audit \
  --s3-bucket-name audit-logs-example \
  --is-multi-region-trail --enable-log-file-validation \
  --kms-key-id arn:aws:kms:ap-southeast-1:111122223333:key/1234abcd-12ab-34cd-56ef-1234567890ab
aws cloudtrail start-logging --name org-audit
aws cloudtrail get-trail-status --name org-audit --query '[IsLogging,LatestDeliveryTime]'
# [ true, "2026-10-31T06:15:09.112000+06:00" ]

# ৩. শুধু একটা bucket-এর data event, শুধু GetObject (advanced event selector)
aws cloudtrail put-event-selectors --trail-name org-audit --advanced-event-selectors '[
  { "Name": "Management events", "FieldSelectors": [ { "Field": "eventCategory", "Equals": ["Management"] } ] },
  { "Name": "Invoice downloads", "FieldSelectors": [
      { "Field": "eventCategory", "Equals": ["Data"] },
      { "Field": "resources.type", "Equals": ["AWS::S3::Object"] },
      { "Field": "eventName", "Equals": ["GetObject"] },
      { "Field": "resources.ARN", "StartsWith": ["arn:aws:s3:::invoices-example/"] } ] } ]'

# ৪. Call rate আর error rate-এর Insights
aws cloudtrail put-insight-selectors --trail-name org-audit \
  --insight-selectors '[{"InsightType":"ApiCallRateInsight"},{"InsightType":"ApiErrorRateInsight"}]'

# ৫. CloudWatch Logs-এও পাঠানো (log group আর role আগে বানানো)
aws cloudtrail update-trail --name org-audit \
  --cloud-watch-logs-log-group-arn arn:aws:logs:ap-southeast-1:111122223333:log-group:cloudtrail-audit:* \
  --cloud-watch-logs-role-arn arn:aws:iam::111122223333:role/CloudTrailToCloudWatchLogs

# ৬. ৭ বছর রাখো: ৯০ দিন পরে Deep Archive, ২,৫৫৭ দিন পরে মুছে ফেলো
aws s3api put-bucket-lifecycle-configuration --bucket audit-logs-example --lifecycle-configuration '{
  "Rules": [ { "ID": "audit-7y", "Status": "Enabled", "Filter": { "Prefix": "AWSLogs/" },
    "Transitions": [ { "Days": 90, "StorageClass": "DEEP_ARCHIVE" } ],
    "Expiration": { "Days": 2557 } } ] }'

# ৭. Root sign-in alert: rule থাকে us-east-1-এ (us-east-2 আর us-west-2-তেও একই কাজ করো)
aws events put-rule --region us-east-1 --name root-signin-alert --event-pattern '{
  "detail-type": ["AWS Console Sign In via CloudTrail"],
  "detail": { "userIdentity": { "type": ["Root"] } } }'
aws events put-targets --region us-east-1 --rule root-signin-alert \
  --targets Id=sns,Arn=arn:aws:sns:us-east-1:111122223333:security-alerts

# ৮. প্রমাণ করো log বদলানো হয়নি (কয়েক ঘণ্টার digest জমার পরে)
aws cloudtrail validate-logs \
  --trail-arn arn:aws:cloudtrail:ap-southeast-1:111122223333:trail/org-audit \
  --start-time 2026-10-31T00:00:00Z
# Results requested for 2026-10-31T00:00:00Z to 2026-10-31T09:12:45Z
# Results found for 2026-10-31T00:12:01Z to 2026-10-31T09:12:01Z:
#
# 9/9 digest files valid
# 107/107 log files valid

# ৯. পরিষ্কার করো
aws cloudtrail delete-trail --name org-audit
aws events remove-targets --region us-east-1 --rule root-signin-alert --ids sns
aws events delete-rule --region us-east-1 --name root-signin-alert

Console-এও করে দেখো: CloudTrail → Event history খোলো, Event name = ConsoleLogin দিয়ে filter করো, আর একটা event খুলে তার JSON পড়ো। তারপর একটা test bucket থেকে download করা একটা log file edit করে আবার upload করো, আর ৮ নম্বর ধাপ আবার চালাও: বদলানো file-টা invalid দেখাবে।

#সারসংক্ষেপ

মূল কথাগুলো

• CloudTrail = account-এর CCTV: console, CLI, SDK আর AWS service থেকে আসা API call আর sign-in রেকর্ড করে: কে, কী, কখন, কোথা থেকে, কাজ হলো কি না। এটা কোনো কাজ আটকায় না, performance মাপে না, instance বা database-এর ভেতরে দেখে না।
• Event history: default-এই চালু, প্রতিটা Region-এ ৯০ দিনের management event, ফ্রি, খোঁজা যায়, বদলানো যায় না। এর চেয়ে পুরোনো কিছু নেই, data event নেই।
• Trail: S3-এ পাঠায় (গড়ে মোটামুটি ৫ মিনিটে), চাইলে CloudWatch Logs-এ, পৌঁছানোর পরে SNS, SSE-KMS। Console-এর trail multi-Region; CLI-র trail না চাইলে single-Region। Organization trail বানায় management account বা delegated administrator; member-রা বদলাতে পারে না।
• Management event: control plane, read আর write, default-এ চালু, প্রথম কপি ফ্রি। Data event: S3 object, Lambda Invoke, DynamoDB item…, default-এ বন্ধ, টাকা লাগে, advanced event selector দিয়ে সীমা টানো। Insights: অস্বাভাবিক API call rate (write management event) আর error rate, যায় S3, console আর EventBridge-এ। Network activity event: তোমার VPC endpoint দিয়ে যাওয়া call।
• অনেকদিন রাখা: S3-এ trail, Lifecycle দিয়ে Glacier / Deep Archive, query করতে Athena। CloudTrail Lake = event data store-এর ওপর SQL (১০ বছর পর্যন্ত), মে ২০২৬ থেকে নতুন customer-দের জন্য বন্ধ।
• রক্ষা করো: organization trail, StopLogging আর DeleteTrail-এর বিরুদ্ধে SCP, আলাদা log archive account, Object Lock বা MFA Delete, SSE-KMS, আর log file integrity validation (ঘণ্টায় digest, SHA-256 hash, SHA-256 with RSA signature, validate-logs)।
• সাড়া দাও: রেকর্ড হওয়া যেকোনো API call-এ CloudTrail → EventBridge rule → Lambda / SNS (DeleteTable, AuthorizeSecurityGroupIngress, AssumeRole, root sign-in)। Logging চালু থাকা trail লাগে; root sign-in আসে us-east-1, us-east-2 বা us-west-2-এ।

নিজেকে যাচাই করো: AWS CloudTrail৩১টি প্রশ্ন