Cloud IAM — identity, role, policy আর temporary credential

১ · দুটি প্রশ্ন — আপনি কে, আর আপনি কী করতে পারেন

পর্ব ২৫ থেকে ৩০ পর্যন্ত আমরা network সাজিয়েছি। সেখানে প্রশ্ন ছিল packet কোথায় যাবে। এই মডিউলে প্রশ্ন বদলাচ্ছে: কে কী করতে পারবে। Cloud-এ VM বানানো, bucket মোছা, database খোলা, সবই একটি API call. আর প্রতিটি API call-এর আগে একটি পাহারাদার সিদ্ধান্ত নেয়। সেই পাহারাদারই IAM.

এই দুই কাজের নাম:

• Authentication (সংক্ষেপে authn): আপনি যা দাবি করছেন, আপনি কি তা-ই? প্রমাণ হতে পারে password, MFA কোড, স্বাক্ষরিত অনুরোধ বা token.
• Authorization (সংক্ষেপে authz): পরিচয় মেনে নেওয়ার পর, এই কাজটি কি আপনি করতে পারেন?

Web-এর ভাষায় পার্থক্যটি status code-এও দেখা যায়। 401 মানে পরিচয় প্রমাণ হয়নি। 403 মানে পরিচয় চেনা গেছে, কিন্তু অনুমতি নেই। তাই AccessDenied দেখলে password বদলে লাভ নেই। সমস্যা policy-তে।

প্রতিটি অনুরোধের চার অংশ

সব cloud-এর IAM মূলত চারটি প্রশ্নের উত্তর মেলায়। একটি বাক্যে: “নাদিয়া (কে) পড়তে (কী) চান reports ফোল্ডারের ফাইল (কোনটি), অফিসের network থেকে (কোন শর্তে)।”

ছবির সবচেয়ে গুরুত্বপূর্ণ কথাটি হলো default deny: কিছু না লেখা থাকলে উত্তর “না”। নতুন পরিচয়ের কোনো ক্ষমতা নেই। এখানেই least privilege শুরু হয়: যতটুকু কাজ, ঠিক ততটুকু অনুমতি।

২ · চার চরিত্র — user, group, role আর service account

পর্ব ৬-এ (Cloud ব্যবহারের পথ) দেখেছেন, root বা owner account প্রতিদিনের কাজে ব্যবহার করা ঠিক নয়। তাহলে প্রতিদিনের কাজ হবে কোন পরিচয়ে? চারটি চরিত্র আছে।

একটি নিয়ম প্রায় সব জায়গায় খাটে: অনুমতি মানুষকে নয়, group বা role-কে দিন। কর্মী বদলালে শুধু সদস্যপদ বদলায়, policy-তে হাত দিতে হয় না। এই ধারণাটিই RBAC.

নামগুলো সব cloud-এ এক নয়। AWS-এ “service account” নামে আলাদা কিছু নেই, সাধারণত role ব্যবহার হয়। Google Cloud-এ service account একটি আসল resource. Azure-এ মেশিনের পরিচয় হলো service principal বা managed identity. আর Kubernetes-এর ServiceAccount আরেকটি জিনিস, যা cluster-এর ভেতরে থাকে।

৩ · তিন cloud, দুই ভাবনা — policy বনাম role assignment

প্রথমে মূল পার্থক্যটি দুই লাইনে দেখুন। AWS-এ আপনি সাধারণত একটি JSON নিয়মের কাগজ লিখে পরিচয়ের গায়ে লাগান। Azure আর Google Cloud-এ আপনি বলেন: “এই পরিচয়কে, এই জায়গায়, এই role দিলাম।” প্রথমটিকে বলে identity policy, দ্বিতীয়টিকে scope-এ role assignment.

এই তুলনা একটি সরল চিত্র। আসল ব্যবস্থায় ব্যতিক্রম আছে, আর নাম ও সুবিধা বদলায়। যেমন Azure আর Google Cloud-এ শর্তযুক্ত অনুমতি আছে, আর AWS-এও resource-এর নিজের policy আছে। তাই কাজে নামার আগে সেই সময়ের official docs দেখে নিন।

এক কাজ, তিন cloud-এ। লক্ষ করুন কোথায় scope বলা হচ্ছে।

# উদাহরণ: এখানে চালানোর জন্য নয়। সব নাম ও id ভুয়া।

# AWS: আগে লেখা policy একটি role-এর গায়ে লাগানো
aws iam attach-role-policy \
  --role-name app-reader \
  --policy-arn arn:aws:iam::123456789012:policy/ReportsRead

# Azure: একটি resource group scope-এ role assignment
az role assignment create \
  --assignee 00000000-0000-0000-0000-000000000000 \
  --role "Storage Blob Data Reader" \
  --scope /subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/example-rg

# Google Cloud: project-এর allow policy-তে একটি binding
gcloud projects add-iam-policy-binding example-project \
  --member="serviceAccount:app-reader@example-project.iam.gserviceaccount.com" \
  --role="roles/storage.objectViewer"

৪ · Policy document-এর গঠন — একটি JSON লাইন ধরে পড়া

এবার AWS ধরনের একটি policy পড়ি। কারণ এই JSON বিন্যাস সবচেয়ে বেশি দেখা যায়, আর পর্ব ৩০-এ একটি bucket policy দেখেছেন। লক্ষ্য: একজন শুধু reports/ ফোল্ডারের ফাইল দেখতে ও পড়তে পারবেন।

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListOnlyReportsFolder",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::example-bucket",
      "Condition": {
        "StringLike": { "s3:prefix": ["reports/*"] }
      }
    },
    {
      "Sid": "ReadReportFiles",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-bucket/reports/*"
    }
  ]
}

লক্ষ করুন, এই JSON-এ Principal নেই। কারণ এটি identity policy: যার গায়ে লাগানো, সে-ই principal. Bucket policy-র মতো resource policy-তে কিন্তু Principal লিখতেই হয়, কারণ কাগজটি resource-এর গায়ে।

Group থেকে আসল অনুমতি

একজন মানুষের আসল ক্ষমতা কোনো একটি কাগজে লেখা থাকে না। তাঁর সব group আর সরাসরি লাগানো policy মিলিয়ে যা হয়, সেটিই। এই পর্বে শুধু Allow ধরছি, তাই হিসাবটি একটি union. Action-গুলো বোঝার সুবিধার জন্য বানানো।

// From groups to effective permissions. Allow-only model: Deny comes in lesson 32.
const policies = {
  ReadLogs:     ["logs:Read"],
  StorageRead:  ["storage:GetObject", "storage:ListBucket"],
  RestartApp:   ["compute:RestartService"],
  DbAdmin:      ["db:*"],
  StorageWrite: ["storage:PutObject"],
};
const groups = {
  developers: ["ReadLogs", "StorageRead"],
  oncall:     ["ReadLogs", "RestartApp"],
  dba:        ["DbAdmin"],
};
const users = {
  rafi:   { groups: ["developers"], direct: [] },
  nadia:  { groups: ["developers", "oncall"], direct: [] },
  tanvir: { groups: ["developers", "oncall", "dba"], direct: ["StorageWrite"] },
};
function effective(name) {
  const u = users[name], from = new Map();
  const add = (p, via) => policies[p].forEach((a) =>
    from.set(a, [...(from.get(a) || []), via]));
  u.groups.forEach((g) => groups[g].forEach((p) => add(p, g)));
  u.direct.forEach((p) => add(p, "direct"));
  return from;
}
const can = (perms, action) => [...perms.keys()].some((a) =>
  a === action || (a.endsWith("*") && action.startsWith(a.slice(0, -1))));
for (const name of Object.keys(users)) {
  const e = effective(name);
  console.log(`${name}: ${e.size} permissions, can drop db: ${can(e, "db:DropTable")}`);
  for (const [a, via] of e) console.log(`   ${a.padEnd(23)} from ${via.join(" + ")}`);
}

rafi: 3 permissions, can drop db: false
   logs:Read               from developers
   storage:GetObject       from developers
   storage:ListBucket      from developers
nadia: 4 permissions, can drop db: false
   logs:Read               from developers + oncall
   storage:GetObject       from developers
   storage:ListBucket      from developers
   compute:RestartService  from oncall
tanvir: 6 permissions, can drop db: true
   logs:Read               from developers + oncall
   storage:GetObject       from developers
   storage:ListBucket      from developers
   compute:RestartService  from oncall
   db:*                    from dba
   storage:PutObject       from direct

৫ · স্থায়ী key কেন ঝুঁকি, অস্থায়ী credential কেন ভালো

ঝুঁকির সময় আর rotation-এর হিসাব

ধরে নিই, একটি key ফাঁস হলো আর ধরা পড়তে ৩০ দিন লাগল। ঝুঁকির সময় ৩০ × ২৪ = ৭২০ ঘণ্টা। এবার ১ ঘণ্টার token ধরুন। কেউ জারির মুহূর্তেই কপি করলেও তা সর্বোচ্চ ১ ঘণ্টা চলে। পার্থক্য ৭২০ গুণ। এখানে ৩০ দিন একটি অনুমান, আসল সময় প্রতিষ্ঠান-ভেদে আলাদা।

Rotation-এর খাটুনিও হিসাব করুন। ১০০টি key, ৯০ দিনে একবার বদল। বছরে প্রায় ১০০ × ৩৬৫ ÷ ৯০ ≈ ৪০৬ বার। প্রতিবার ২০ মিনিট ধরলে প্রায় ১৩৫ ঘণ্টা। Key rotation ভালো, তবে key না থাকা আরও ভালো।

যেসব key এখনো আছে, সেগুলোর বয়স নজরে রাখতে হয়। নিচের ছোট auditor একটি কৃত্রিম ঘড়িতে চলে, দিন গোনে। নিয়ম তিনটি: ৪৫ দিন অব্যবহৃত হলে বন্ধ, ৯০ দিন বয়স হলে বদল, নইলে ঠিক আছে।

// A credential age auditor on a simulated clock (days). now = 0 is audit day.
const MAX_AGE = 90, MAX_IDLE = 45;
const keys = [
  { id: "ci-deploy",  born: -200, usedDaily: true },
  { id: "backup-job", born: -70,  usedDaily: true },
  { id: "old-intern", born: -130, lastUsed: -80 },
  { id: "report-bot", born: -10,  usedDaily: true },
];
function verdict(k, now) {
  const age = now - k.born;
  const idle = k.usedDaily ? 0 : now - k.lastUsed;
  if (k.state === "disabled") return `disabled (age ${age})`;
  if (idle >= MAX_IDLE) return `DISABLE idle ${idle}d`;
  if (age >= MAX_AGE) return `ROTATE age ${age}`;
  return `ok age ${age}`;
}
for (let now = 0; now <= 90; now += 30) {
  console.log(`--- day ${now}`);
  for (const k of keys) {
    const v = verdict(k, now);
    console.log(`${k.id.padEnd(11)} ${v}`);
    // the auditor acts: rotate resets the age, idle keys get disabled
    if (v.startsWith("ROTATE")) k.born = now;
    if (v.startsWith("DISABLE")) k.state = "disabled";
  }
}
const live = keys.filter((k) => k.state !== "disabled").length;
console.log(`rotations per year if all ${live} live keys stay: ${(live * 365 / MAX_AGE).toFixed(1)}`);

--- day 0
ci-deploy   ROTATE age 200
backup-job  ok age 70
old-intern  DISABLE idle 80d
report-bot  ok age 10
--- day 30
ci-deploy   ok age 30
backup-job  ROTATE age 100
old-intern  disabled (age 160)
report-bot  ok age 40
--- day 60
ci-deploy   ok age 60
backup-job  ok age 30
old-intern  disabled (age 190)
report-bot  ok age 70
--- day 90
ci-deploy   ROTATE age 90
backup-job  ok age 60
old-intern  disabled (age 220)
report-bot  ROTATE age 100
rotations per year if all 3 live keys stay: 12.2

৬ · Role assume করা — token, মেয়াদ আর confused deputy

Role পরার কাজকে বলে assume role. যে সেবা এই অস্থায়ী credential জারি করে, AWS-এ তার নাম STS (Security Token Service). অন্য cloud-এ একই কাজের অন্য নাম আছে। ধারণাটি এক: পরিচয় প্রমাণ করুন, role চান, মেয়াদসহ একটি প্রমাণ নিন।

একটি role-এর দুটি দরজা থাকে।

1. Trust policy: কে এই role পরতে পারবে?
2. Permission policy: role পরার পর কী কী করা যাবে?

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::123456789012:user/nadia" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "Bool": { "aws:MultiFactorAuthPresent": "true" }
      }
    }
  ]
}

অনুরোধটি এরকম। নিচের উত্তর নমুনা, কোনো আসল account-এর নয়।

# উদাহরণ: এখানে চালানোর জন্য নয়। Account id আর নাম ভুয়া।
aws sts assume-role \
  --role-arn arn:aws:iam::123456789012:role/db-admin \
  --role-session-name nadia-restore \
  --serial-number arn:aws:iam::123456789012:mfa/nadia \
  --token-code 123456 \
  --duration-seconds 900

{
  "Credentials": {
    "AccessKeyId": "ASIAEXAMPLEEXAMPLE00",
    "SecretAccessKey": "example-not-a-real-secret",
    "SessionToken": "example-session-token",
    "Expiration": "2026-10-31T05:15:00+00:00"
  },
  "AssumedRoleUser": {
    "AssumedRoleId": "AROAEXAMPLEEXAMPLE00:nadia-restore",
    "Arn": "arn:aws:sts::123456789012:assumed-role/db-admin/nadia-restore"
  }
}

একটি খেলনা STS

নিচের simulator-এ কোনো আসল cloud নেই। আছে একটি কৃত্রিম ঘড়ি, যা সেকেন্ড গোনে। পরীক্ষা করা হচ্ছে চারটি জিনিস: মেয়াদের সীমা, অনুমতি, trust আর মেয়াদ ফুরানো।

// A toy STS with a simulated clock. Nothing here talks to a real cloud.
function mulberry32(a) { return () => { a |= 0; a = a + 0x6D2B79F5 | 0;
  let t = Math.imul(a ^ a >>> 15, 1 | a); t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t;
  return ((t ^ t >>> 14) >>> 0) / 4294967296; }; }
const rand = mulberry32(31);
let clock = 0; // seconds
const roles = {
  "app-reader": { trust: ["vm-17"], maxTtl: 3600, perms: ["storage:GetObject"] },
  "db-admin":   { trust: ["nadia"], maxTtl: 900,  perms: ["db:Restore"] },
};
function assume(who, role, ttl) {
  const r = roles[role];
  if (!r.trust.includes(who)) return console.log(`t=${clock} ${who} -> ${role}: REFUSED, not in trust policy`);
  const life = Math.min(ttl, r.maxTtl);
  const token = "tmp-" + Math.floor(rand() * 0xffffff).toString(16).padStart(6, "0");
  console.log(`t=${clock} ${who} -> ${role}: asked ${ttl}s, got ${life}s, ${token}`);
  return { token, role, exp: clock + life };
}
function call(c, action) {
  let res = "ALLOW";
  if (clock >= c.exp) res = "DENY ExpiredToken";
  else if (!roles[c.role].perms.includes(action)) res = "DENY no permission";
  console.log(`t=${clock} ${c.token} ${action}: ${res}`);
}
let cred = assume("vm-17", "app-reader", 7200);
call(cred, "storage:GetObject");
call(cred, "storage:PutObject");
assume("vm-17", "db-admin", 900);
clock = 3300; const next = assume("vm-17", "app-reader", 3600); // renew 5 min early
clock = 3599; call(cred, "storage:GetObject"); // old token still valid
clock = 3600; call(cred, "storage:GetObject"); // old token dead
call(next, "storage:GetObject"); // new one works

t=0 vm-17 -> app-reader: asked 7200s, got 3600s, tmp-ac18f9
t=0 tmp-ac18f9 storage:GetObject: ALLOW
t=0 tmp-ac18f9 storage:PutObject: DENY no permission
t=0 vm-17 -> db-admin: REFUSED, not in trust policy
t=3300 vm-17 -> app-reader: asked 3600s, got 3600s, tmp-d6008e
t=3599 tmp-ac18f9 storage:GetObject: ALLOW
t=3600 tmp-ac18f9 storage:GetObject: DENY ExpiredToken
t=3600 tmp-d6008e storage:GetObject: ALLOW

মেয়াদ বেছে নেওয়া একটি trade-off. ছোট মেয়াদে ঝুঁকি কম, তবে token সেবার ওপর নির্ভরতা বেশি। আর সাধারণ অবস্থায় জারি করা token মেয়াদের আগে নিজে থেকে বাতিল হয় না। তাই জরুরি অবস্থায় আলাদা ব্যবস্থা লাগে, যেমন AWS-এ পুরোনো session-কে deny করার নিয়ম। বেশিরভাগ কাজে ১৫ মিনিট থেকে ১ ঘণ্টা একটি প্রচলিত শুরু।

Confused deputy — আপনার হয়ে কাজ করা তৃতীয় পক্ষ

ধরুন একটি বাইরের প্রতিষ্ঠান আপনার cloud-এর খরচ বিশ্লেষণ করে দেয়। এজন্য আপনি একটি role বানিয়ে তাদের account-কে trust করলেন। তারা একইভাবে অনেক গ্রাহকের role পরে। এখন অন্য এক গ্রাহক তাদের ফর্মে আপনার role-এর ঠিকানা দিয়ে দিলে কী হবে? বিশ্বস্ত সেবাটি নিজের ক্ষমতা দিয়ে ভুল জনের হয়ে কাজ করতে পারে। একে বলে confused deputy: ক্ষমতাবান সহকারী যে বুঝতে পারে না, সে কার হয়ে কাজ করছে।

সেই সংকেতটিই external ID. সেবাদাতা প্রতিটি গ্রাহকের জন্য একটি অনন্য মান তৈরি করে দেয়। আপনি সেটি trust policy-র শর্তে বসান। সেবাদাতা role চাওয়ার সময় যে গ্রাহকের কাজ করছে, তারই মান পাঠায়। অন্য গ্রাহকের অনুরোধে অন্য মান যাবে, তাই শর্ত মিলবে না।

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::111122223333:root" },
      "Action": "sts:AssumeRole",
      "Condition": {
        "StringEquals": { "sts:ExternalId": "customer-7f3a-example" }
      }
    }
  ]
}

৭ · Workload identity — মেশিনকে key ছাড়া পরিচয়

প্রোগ্রামকে পরিচয় দেওয়ার পুরোনো পথ ছিল একটি key কোথাও লিখে রাখা। আধুনিক পথকে বলে workload identity: প্রোগ্রাম কোথায় চলছে, সেটিই তার পরিচয়ের প্রমাণ। Platform সেই প্রমাণ দিয়ে অস্থায়ী credential এনে দেয়।

শেষ দুটির মূল ধারণা একই: federation. Cloud একটি বাইরের প্রতিষ্ঠানের স্বাক্ষর বিশ্বাস করে। Kubernetes বা CI বলে, “এই job আমার, এর নাম এই।” Cloud স্বাক্ষর আর শর্ত মিলিয়ে অল্প সময়ের credential দেয়। CI-তে কোনো স্থায়ী secret জমা রাখতে হয় না।

VM-এ আসলে কী ঘটে, ধাপে ধাপে দেখুন। সময় আর মেয়াদগুলো উদাহরণ, provider-ভেদে আলাদা। পর্ব ১৫-এ metadata service আর IMDSv2 দেখেছেন।

আরেকটি কথা। Instance role সেই VM-এর সব প্রোগ্রামের জন্য একটিই পরিচয়। SSRF ত্রুটিতে এই credential ঝুঁকিতে পড়তে পারে (পর্ব ১৫). তাই IMDSv2 চালু রাখুন, আর role-কে শুধু দরকারি অনুমতি দিন।

৮ · মানুষের access — SSO, MFA, break-glass আর review

প্রতিটি cloud account-এ আলাদা user বানালে কর্মী চলে যাওয়ার দিন দশ জায়গায় মুছতে হয়, আর একটি জায়গা ভুলে যাওয়া সহজ। সমাধান হলো পরিচয় এক জায়গায় রাখা। সেই জায়গার নাম identity provider (IdP), আর এক login-এ সব জায়গায় ঢোকা হলো SSO.

IdP আর cloud কথা বলে দুটি মানে: SAML ২.০ (২০০৫) আর OIDC ১.০ (২০১৪). AWS-এ এই কাজের সেবা IAM Identity Center, যার আগের নাম AWS SSO. Azure-এ Entra ID নিজেই IdP. Google Cloud-এ Cloud Identity বা Workforce Identity Federation. কারখানার গেটের উপমায়: গেটে একবার কার্ড, ভেতরে প্রতিটি সেকশনে আলাদা খাতা নেই।

MFA — সব MFA সমান নয়

MFA password-এর পাশে দ্বিতীয় প্রমাণ চায়। কিন্তু দ্বিতীয় প্রমাণের শক্তি আলাদা।

Passkey আর hardware key আসল সাইটের ঠিকানার সাথে বাঁধা থাকে। ভুয়া পাতায় এগুলো কাজই করে না। তাই ক্ষমতাবান পরিচয়ের জন্য এগুলোই প্রথম পছন্দ।

Break-glass — আগুনের সময়ের চাবি

IdP নিজেই বন্ধ থাকলে কী হবে? তখন কেউ cloud-এ ঢুকতে পারবেন না। এই দিনের জন্য রাখা হয় break-glass account: কাচের বাক্সে রাখা জরুরি চাবির মতো। সাধারণ নিয়মগুলো:

• দুটি রাখুন, যাতে একটি নষ্ট হলে অন্যটি থাকে। এগুলো IdP-র ওপর নির্ভর করবে না।
• শক্ত MFA, যেমন hardware key, আলাদা নিরাপদ জায়গায় রাখুন।
• প্রতিদিনের কাজে কখনো ব্যবহার করবেন না। ব্যবহার হলেই alert যাবে।
• নিয়মিত পরীক্ষা করুন। পরীক্ষা না করা চাবি জরুরি দিনে খুলবে, এমন নিশ্চয়তা নেই।
• ব্যবহারের পরে password আর প্রমাণ বদলান, আর কেন লেগেছিল তা লিখে রাখুন।

Access review আর সাময়িক অধিকার

অনুমতি দেওয়া সহজ, সরানো সবাই ভুলে যায়। Access review মানে নিয়মিত সময়ে মালিককে জিজ্ঞেস করা: এই মানুষ বা মেশিনের কি এখনো এই অনুমতি দরকার? ভালো review-তে শেষ ব্যবহারের তথ্য সাথে থাকে। তিন মাস ব্যবহার হয়নি এমন অনুমতি সরানোর পক্ষে সেটিই প্রমাণ।

আরেকটি ভালো অভ্যাস হলো just-in-time access: বড় ক্ষমতা সবসময় হাতে না রেখে দরকারের সময় চেয়ে নেওয়া, ১ ঘণ্টার জন্য। Azure-এ Privileged Identity Management এই ধরনের সুবিধা দেয়। তানভীরের db:* থাকলে তিনি সারা বছর ঝুঁকি বয়ে বেড়ান। সাময়িক অধিকারে সেই ঝুঁকি শুধু কাজের সময়টুকুতে থাকে।

৯ · পুরোনো key খোঁজা আর downtime ছাড়া সরানো

নতুন নকশা সহজ। আসল কাজ হলো পুরোনো account-এ যা জমে আছে, তা খুঁজে সরানো। AWS-এ credential report নামে একটি CSV পাওয়া যায়, যাতে প্রতিটি user-এর MFA আর key-র অবস্থা থাকে। নিচে সেই ধরনের একটি ছোট, কাটছাঁট করা নমুনা। ফাইলটি block-এর ভেতরেই বানানো, আর তারিখ নির্দিষ্ট।

set -euo pipefail
report=$(mktemp)
# A trimmed credential report (sample data, fictional users).
cat > "$report" <<'EOF'
user,password_enabled,mfa_active,key_active,key_last_rotated,key_last_used
<root_account>,true,false,true,2024-02-11,2024-03-02
nadia,true,true,false,N/A,N/A
rafi,true,false,true,2026-09-20,2026-10-30
tanvir,true,true,true,2025-11-03,2026-10-30
ci-deploy,false,false,true,2026-01-15,2026-10-31
old-intern,true,false,true,2026-02-01,2026-05-10
report-bot,false,false,true,2026-10-02,2026-10-31
EOF
awk -F, -v today=2026-10-31 -v max_age=90 -v max_idle=45 '
function days(s,    a, y, m) { split(s, a, "-"); y = a[1]; m = a[2]
  if (m <= 2) { y--; m += 12 }
  return 365*y + int(y/4) - int(y/100) + int(y/400) + int(306*(m+1)/10) + a[3] }
BEGIN { now = days(today) }
NR == 1 { next }
$1 == "<root_account>" && $4 == "true" { print "CRITICAL root has an access key" }
$1 == "<root_account>" && $3 == "false" { print "CRITICAL root has no MFA" }
$1 != "<root_account>" && $2 == "true" && $3 == "false" { print "NO-MFA  " $1; nomfa++ }
$1 != "<root_account>" && $4 == "true" {
  age = now - days($5); idle = now - days($6); keys++
  if (age > max_age)   { printf "OLD-KEY %-11s age %d days\n", $1, age; old++ }
  if (idle > max_idle) { printf "IDLE    %-11s idle %d days\n", $1, idle; unused++ } }
END { printf "summary: %d active keys, %d old, %d idle, %d users without MFA\n", keys, old, unused, nomfa }
' "$report"
rm -f "$report"

CRITICAL root has an access key
CRITICAL root has no MFA
NO-MFA  rafi
OLD-KEY tanvir      age 362 days
OLD-KEY ci-deploy   age 289 days
NO-MFA  old-intern
OLD-KEY old-intern  age 272 days
IDLE    old-intern  idle 174 days
summary: 5 active keys, 3 old, 1 idle, 2 users without MFA

চলমান সেবা থেকে key সরানো

একটি key মুছে দিলেই কাজ শেষ নয়। সেটি কে ব্যবহার করছে না জেনে মুছলে রাতের বেলায় কিছু থেমে যেতে পারে। নিরাপদ পথটি দেখুন। ধরে নিই, report-bot সেবা ৩টি VM-এ চলে, প্রতিটি ঘণ্টায় ৪০টি call করে।

১০ · AI-এর যুগে IAM যাচাই

AI একটি policy কয়েক সেকেন্ডে লিখে দেয়। কিন্তু এখানে তার ভুল প্রায়ই নীরব। সবচেয়ে সহজ যে policy দিয়ে কাজ চলে, সেটি হলো সব খুলে দেওয়া। Error চলে যায়, ঝুঁকি থেকে যায়।

AI-এর দেওয়া IAM বদল হাতে পেলে — যাচাইয়ের চেকলিস্ট

• কোনো * action, resource বা principal নেই, থাকলে তার লিখিত কারণ আছে
• প্রতিটি action official docs-এ মিলিয়েছি
• Resource-এর ধরন action-এর সাথে মেলে: bucket বনাম object
• নতুন কোনো স্থায়ী key তৈরি হচ্ছে না
• Trust policy-তে নির্দিষ্ট principal আর দরকারি শর্ত আছে
• Scope সবচেয়ে নিচের স্তরে
• Throwaway পরিবেশে একটি allow আর একটি deny পরীক্ষা করেছি
• terraform plan বা diff পড়েছি, অপ্রত্যাশিত বদল নেই
• কোনো secret, account id বা আসল log prompt-এ যায়নি
• আসল cloud-এ পরীক্ষার পর resource মুছেছি, আর budget alert চালু আছে