🖼️ See the drawing + lab 🏠 Course home 🌿 Branch on GitHub ✏️ View source

🖼️ आकृती आणि labThe drawing + lab पूर्ण पानावर उघडा ↗Open full page ↗

🧾 धडा 12 — Audit आणि incident response: नोंदवही आणि पहिला तास

📍 तुम्ही इथे आहात: 12 पैकी धडा 12 — शेवटचा धडा! · मागील: lesson-11-least-privilege

📦 या ब्रँचमध्ये काय आहे

संपूर्ण कोर्स, आणि शेवटचा टप्पा: auditor सारखा credential report (iam/data/credential-report.csv) वाचणे, CloudTrail मध्ये चोरलेली key ओळखणे (iam/data/cloudtrail.json), आणि फुटलेल्या key च्या incident च्या पहिल्या तासासाठी runbook.

🧒 5 वर्षांच्या मुलाला समजावल्यासारखे

दर शुक्रवारी ओळखपत्र कार्यालय स्वतःच्या नोंदी वाचते: कोणाकडे कार्ड आहे, कोणाकडे जादा चावी आहे, प्रत्येक चावी किती जुनी आहे, कोणी दुसरे कुलूप कधीच लावले नाही. जुन्या चाव्या आणि नसलेली कुलपे दुरुस्त करण्याच्या यादीत जातात.

एका रात्री नोंदवहीत काहीतरी विचित्र दिसते: कतरिनाची चावी, जी फक्त सकाळी शाळेतच वापरली जाते, ती रात्री 2 वाजता दुसऱ्या शहरातून वापरली गेली, आणि कतरिना कधीच जात नाही अशा खोल्या उघडण्याचा प्रयत्न झाला. दारांनी नाही म्हटले — पण पुढचे दार काय म्हणते हे पाहण्यासाठी कार्यालय थांबत नाही. ते:

चावी बंद करते, 2. तिच्याने आधीच दिलेले सगळे पास रद्द करते,
अनोळखी व्यक्तीने कशाला हात लावला ते पाहण्यासाठी प्रत्येक खोलीत फिरते, 4. कतरिनाला नवी चावी देते,
चावी बाहेर कशी गेली ते शोधून काढते.

🗺️ आकृती

flowchart LR
    cr["📋 credential report<br/>katrina: no MFA · key 329 days"]
    ct["🚨 CloudTrail<br/>AKIAEXAMPLEKATRINA01 · 02:03 · us-east-1 · new IP<br/>GetCallerIdentity · RunInstances · CreateUser"]
    k1["1 deactivate the key"]
    k2["2 revoke sessions"]
    k3["3 find what it created"]
    k4["4 rotate"]
    k5["5 find how it leaked"]
    cr -.->|"weekly"| ct
    ct --> k1 --> k2 --> k3 --> k4 --> k5

🗺️ काढलेली आकृती + एक lab: https://school-edh.pages.dev/iam/lesson-diagrams.html#l12

❓ काय

Credential report — प्रत्येक IAM user (आणि root user) साठी एक CSV ओळ: password चालू आहे का आणि शेवटचा कधी वापरला, MFA चालू आहे का, प्रत्येक access key ची स्थिती, शेवटचे rotate कधी केले, शेवटच्या वापराची तारीख, region आणि service. या repo मधील नमुन्यात त्यापैकी सहा columns ठेवले आहेत. तो generate-credential-report ने तयार करा.
Auditors कशावर बोट ठेवतात — keys असलेला किंवा MFA नसलेला root; MFA नसलेले console users; 90 दिवसांपेक्षा जुन्या keys; 90 दिवस न वापरलेल्या keys (त्या delete करा); काहीच activity नसलेले users.
CloudTrail — प्रत्येक API call चे management events (कोण, key, action, region, source IP, error code) default ने 90 दिवस Event history मध्ये नोंदवतो; S3 कडे जाणारा trail ते तुम्हाला हवे तितके दिवस ठेवतो. Data events (जसे s3:GetObject) चालू करावे लागतात.
चोरलेल्या key ची लक्षणे — नवा source IP किंवा region, विचित्र वेळ, सुरुवातीला GetCallerIdentity (कोणत्याही permission ची गरज नसलेला "मी कोण?" call), मग AccessDenied चाचपण्यांचा भडिमार — न वापरलेल्या regions मध्ये RunInstances, CreateUser. GuardDuty नेमक्या याच patterns साठी findings देतो.
Runbook — (1) update-access-key --status Inactive; (2) sessions revoke करा: आधीच दिलेली तात्पुरती credentials संपेपर्यंत वैध राहतात, म्हणून aws:TokenIssueTime सह एक Deny जोडा (roles साठी console चे Revoke active sessions हेच करते); (3) key ने जे काही बनवले — users, keys, roles, instances — ते access key ID ने CloudTrail मध्ये शोधा; (4) नवी credentials द्या — त्याहून चांगले, roles कडे वळा; (5) गळती शोधा (git commit, log, laptop) आणि कारण दुरुस्त करा.

🤔 का

कारण प्रतिबंध कधीच परिपूर्ण नसतो. Credentials public repos मधून काही मिनिटांत फुटतात, आणि attackers पुढचे काम automate करतात. घाबरवणारा प्रसंग आणि आपत्ती यांच्यातला फरक म्हणजे कोणी किती लवकर नोंदवही वाचते आणि पहिल्या तासाचा किती सराव झाला आहे.

🔧 कसे (या repo मध्ये)

iam/demo.py मधील audit() credential report वाचते (ठरलेल्या तारखेला, 2026-09-27, म्हणजे आकडे कधीच बदलत नाहीत) आणि MFA नसलेले passwords, 90 दिवसांपेक्षा जुन्या keys आणि 90 दिवस न वापरलेल्या keys वर बोट ठेवते. मग ते CloudTrail events वाचते, आदल्या दिवसावरून katrina चे नेहमीचे IPs शिकते, आणि नव्या IP मधून आलेला प्रत्येक event चिन्हांकित करते.

🧪 करून पाहा

python3 iam/demo.py audit
python3 - <<'EOF'
import csv, json
from datetime import date
today = date(2026, 9, 27)
for r in csv.DictReader(open("iam/data/credential-report.csv")):
    if r["access_key_1_active"] == "true":
        print(r["user"].ljust(9), "key age", (today - date.fromisoformat(r["access_key_1_last_rotated"])).days, "days")
events = json.load(open("iam/data/cloudtrail.json"))
key = [e for e in events if e["accessKey"] == "AKIAEXAMPLEKATRINA01"]
print("AKIAEXAMPLEKATRINA01 used from:", sorted({e["sourceIPAddress"] for e in key}), "in", sorted({e["awsRegion"] for e in key}))
print("denied calls:", [e["eventName"] for e in key if e.get("errorCode")])
EOF
python3 iam/test_iam.py

खऱ्या account वर (AWS CLI आणि credentials लागतात) — आधी audit, मग पहिला तास:

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 --decode > credential-report.csv
aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAEXAMPLEKATRINA01 --max-results 50
aws iam update-access-key --user-name katrina --access-key-id AKIAEXAMPLEKATRINA01 --status Inactive
cat > revoke-older-sessions.json <<'JSON'
{"Version": "2012-10-17", "Statement": [{"Effect": "Deny", "Action": "*", "Resource": "*",
  "Condition": {"DateLessThan": {"aws:TokenIssueTime": "2026-09-27T03:00:00Z"}}}]}
JSON
aws iam put-user-policy --user-name katrina --policy-name revoke-older-sessions --policy-document file://revoke-older-sessions.json

✅ तपासा — तुम्हाला काय दिसायला हवे

audit <root_account>, aishwarya आणि ci-robot साठी ✅ छापते; ⚠️ katrina password without MFA, key 329 days old; ⚠️ dipika password without MFA, key 931 days old, key unused > 90 days → delete; मग सहा CloudTrail ओळी, ज्यात 198.51.100.77 मधून आलेल्या katrina च्या तीन events वर 🚨 असते (GetCallerIdentity, sa-east-1 मध्ये RunInstances आणि CreateUser, शेवटच्या दोन्हींवर AccessDenied), आणि पाच पायऱ्यांचा runbook. तुमचा snippet key चे वय 329, 931 आणि 28 दिवस (katrina, dipika, ci-robot), तीन regions मधले key चे दोन IPs, आणि denied calls: ['RunInstances', 'CreateUser'] छापतो. Tests शेवटी 12/12 passed दाखवतात.

🏁 तुम्ही आत्ताच काय सिद्ध केले

तुम्ही कार्यालयाच्या स्वतःच्या नोंदी auditor सारख्या वाचू शकता, पहिल्या काही calls वरूनच चोरलेली key ओळखू शकता, आणि पहिला तास योग्य क्रमाने हाताळू शकता.

⚠️ नेहमीच्या चुका

key deactivate करण्याऐवजी आधी delete करणे — deactivate करणे उलटवता येते आणि पुरावा व्यवस्थित राहतो
key deactivate करणे आणि तिच्याने आधीच दिलेले sessions विसरणे
CloudTrail फक्त एकाच region मध्ये, किंवा फक्त 90 दिवसांची event history — नंतर शोधायला trail नाही
key rotate करणे पण ती कशी फुटली ते न शोधणे — ती पुन्हा फुटते

🏭 प्रत्यक्ष वापरात हे का महत्त्वाचे: सराव केलेला, वरील patterns वर GuardDuty alert देणारा फुटलेल्या key चा runbook AWS चालवणाऱ्या प्रत्येक team साठी नेहमीचा आहे. पायरी 4 ची सर्वोत्तम आवृत्ती म्हणजे "फुटायला दीर्घकाळाची key नव्हतीच" — धडे 05, 06 आणि 10.

🎓 ओळखपत्र कार्यालय आता तुमचे आहे

ओळखपत्र कार्यालय → कार्डे आणि वर्गांच्या याद्या → लिखित नियम → deny जिंकतो → कार्डे नव्हे, टोप्या → secrets नसलेले badges → "फक्त तेव्हाच…" → छते → दोन दरवाजे, दोन चाव्या → एकच front desk → वापरले जाते तेवढेच ठेवा → नोंदवही आणि पहिला तास. तुम्ही फक्त IAM शिकला नाहीत — तुम्ही ओळखपत्र कार्यालय चालवू शकता. 🪪🎓

शाळेतील पुढची दारे: AWS school या policies ज्या services चे रक्षण करतात त्या बनवते; CI/CD school धडा 06 चा OIDC role खऱ्या pipeline मध्ये कामाला लावते; Kubernetes school मध्ये IRSA आणि Pod Identity राहतात.

git checkout main
python3 iam/demo.py     # one last run, for fun

🧾 Lesson 12 — Audit & incident response: the logbook and the first hour

📍 You are here: Lesson 12 of 12 — the final lesson! · Previous: lesson-11-least-privilege

📦 What's in this branch

The complete course, plus the last mile: reading the credential report (iam/data/credential-report.csv) like an auditor, spotting a stolen key in CloudTrail (iam/data/cloudtrail.json), and the runbook for the first hour of a leaked-key incident.

🧒 Explain like I'm 5

Every Friday the ID office reads its own records: who has a card, who has a spare key, how old each key is, who never set up the second lock. Old keys and missing locks go on a list to fix.

One night the logbook shows something odd: Katrina's key, which is only ever used in the school in the morning, was used at 2 a.m. from another city, trying to open rooms Katrina never visits. The doors said no — but the office does not wait to find out what the next door says. It:

switches the key off, 2. cancels any passes already issued with it,
walks every room to see what the stranger touched, 4. gives Katrina a new key,
finds out how the key got out.

🗺️ Diagram

flowchart LR
    cr["📋 credential report<br/>katrina: no MFA · key 329 days"]
    ct["🚨 CloudTrail<br/>AKIAEXAMPLEKATRINA01 · 02:03 · us-east-1 · new IP<br/>GetCallerIdentity · RunInstances · CreateUser"]
    k1["1 deactivate the key"]
    k2["2 revoke sessions"]
    k3["3 find what it created"]
    k4["4 rotate"]
    k5["5 find how it leaked"]
    cr -.->|"weekly"| ct
    ct --> k1 --> k2 --> k3 --> k4 --> k5

🗺️ Drawn version + a lab: https://school-edh.pages.dev/iam/lesson-diagrams.html#l12

❓ What

Credential report — one CSV row per IAM user (and the root user): password enabled and last used, MFA active, each access key's status, last rotated, last used date, region and service. The sample in this repo keeps six of those columns. Generate it with generate-credential-report.
What auditors flag — root with keys or without MFA; console users without MFA; keys older than 90 days; keys unused for 90 days (delete them); users with no activity.
CloudTrail — records management events for every API call (who, key, action, region, source IP, error code) by default for 90 days in Event history; a trail to S3 keeps them for as long as you want. Data events (like s3:GetObject) need to be turned on.
Signs of a stolen key — a new source IP or region, odd hours, GetCallerIdentity first (the "who am I?" call that needs no permission), then a burst of AccessDenied probes — RunInstances in unused regions, CreateUser. GuardDuty raises findings for exactly these patterns.
The runbook — (1) update-access-key --status Inactive; (2) revoke sessions: temporary credentials already issued stay valid until they expire, so attach a Deny with aws:TokenIssueTime (for roles, the console's Revoke active sessions does this); (3) search CloudTrail by access key ID for everything it created — users, keys, roles, instances; (4) issue new credentials — better, move to roles; (5) find the leak (a git commit, a log, a laptop) and fix the cause.

🤔 Why

Because prevention is never perfect. Credentials leak through public repos within minutes, and attackers automate what they do next. The difference between a scare and a disaster is how fast someone reads the logbook and how rehearsed the first hour is.

🔧 How (in this repo)

audit() in iam/demo.py reads the credential report (on a fixed date, 2026-09-27, so the numbers never drift) and flags passwords without MFA, keys older than 90 days and keys unused for 90 days. Then it reads the CloudTrail events, learns katrina's normal IPs from the day before, and marks every event from a new one.

🧪 Try it

python3 iam/demo.py audit
python3 - <<'EOF'
import csv, json
from datetime import date
today = date(2026, 9, 27)
for r in csv.DictReader(open("iam/data/credential-report.csv")):
    if r["access_key_1_active"] == "true":
        print(r["user"].ljust(9), "key age", (today - date.fromisoformat(r["access_key_1_last_rotated"])).days, "days")
events = json.load(open("iam/data/cloudtrail.json"))
key = [e for e in events if e["accessKey"] == "AKIAEXAMPLEKATRINA01"]
print("AKIAEXAMPLEKATRINA01 used from:", sorted({e["sourceIPAddress"] for e in key}), "in", sorted({e["awsRegion"] for e in key}))
print("denied calls:", [e["eventName"] for e in key if e.get("errorCode")])
EOF
python3 iam/test_iam.py

On a real account (needs the AWS CLI and credentials) — the audit, then the first hour:

aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 --decode > credential-report.csv
aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAEXAMPLEKATRINA01 --max-results 50
aws iam update-access-key --user-name katrina --access-key-id AKIAEXAMPLEKATRINA01 --status Inactive
cat > revoke-older-sessions.json <<'JSON'
{"Version": "2012-10-17", "Statement": [{"Effect": "Deny", "Action": "*", "Resource": "*",
  "Condition": {"DateLessThan": {"aws:TokenIssueTime": "2026-09-27T03:00:00Z"}}}]}
JSON
aws iam put-user-policy --user-name katrina --policy-name revoke-older-sessions --policy-document file://revoke-older-sessions.json

✅ Verify — what you should see

audit prints ✅ for <root_account>, aishwarya and ci-robot; ⚠️ katrina password without MFA, key 329 days old; ⚠️ dipika password without MFA, key 931 days old, key unused > 90 days → delete; then six CloudTrail lines with 🚨 on katrina's three events from 198.51.100.77 (GetCallerIdentity, RunInstances in sa-east-1 and CreateUser, the last two with AccessDenied), and the five-step runbook. Your snippet prints key ages 329, 931 and 28 days (katrina, dipika, ci-robot), the key's two IPs across three regions, and denied calls: ['RunInstances', 'CreateUser']. The tests end with 12/12 passed.

🏁 What you just proved

You can read the office's own records like an auditor, recognise a stolen key from its first few calls, and run the first hour in the right order.

⚠️ Common mistakes

deleting the key first instead of deactivating it — deactivating is reversible and keeps the evidence tidy
deactivating the key and forgetting the sessions already issued with it
CloudTrail only in one region, or only the 90-day event history — no trail to search later
rotating the key and not finding how it leaked — it leaks again

🏭 Why this matters in production: a leaked-key runbook, rehearsed, with GuardDuty alerting on the patterns above, is standard for any team that runs AWS. The best version of step 4 is "there was no long-lived key to leak" — lessons 05, 06 and 10.

🎓 The ID office is yours

The ID office → cards and class lists → the written rules → deny wins → hats, not cards → badges without secrets → "only when…" → ceilings → two doors, two keys → one front desk → trim to what is used → the logbook and the first hour. You didn't just learn IAM — you can run the ID office. 🪪🎓

Next doors in the school: the AWS school builds the services these policies protect; the CI/CD school puts lesson 06's OIDC role to work in a real pipeline; the Kubernetes school is where IRSA and Pod Identity live.

git checkout main
python3 iam/demo.py     # one last run, for fun

← Previousleast privilege Finished! Take the quiz →check what stuck

This page is the lesson's README from the lesson-12-audit-incidents branch, shown here so the whole School stays on one site. Code files open on GitHub at the same branch.