IAM policy evaluation — allow, deny, least privilege আর ভুল অনুমতি ধরা

১ · গুদামঘরের গেট — default deny আর explicit deny

একটি কাল্পনিক অনলাইন বাজার অ্যাপের কথা ভাবুন। রাতে report বানানোর একটি প্রোগ্রাম চলে। একদিন ভোরে দেখা গেল, report হয়নি। Log-এ শুধু একটি লাইন: AccessDenied. একই সপ্তাহে নিরাপত্তা দল জানাল, ওই প্রোগ্রামের role চাইলে পুরো storage মুছে দিতে পারে। অথচ তার কাজ শুধু কয়েকটি ফাইল পড়া।

প্রথমটি কম অনুমতির সমস্যা, দ্বিতীয়টি বেশি অনুমতির। দুটোর সমাধান একই জায়গায়: বুঝতে হবে cloud একটি অনুরোধের ওপর ঠিক কীভাবে রায় দেয়। পর্ব ৩১-এ দেখেছেন identity, role আর policy কী। এই পর্বে দেখব সেগুলো একসাথে কীভাবে কাজ করে, অর্থাৎ policy evaluation.

রক্ষী কী দেখে রায় দেন? প্রতিটি API অনুরোধের সাথে চারটি তথ্য আসে, যাকে বলে request context:

এবার নিয়মের গঠন। AWS-এর ভাষায় একটি policy হলো JSON দলিল, যার ভেতরে এক বা একাধিক statement থাকে। নিচেরটি মাত্র একটি কাজের অনুমতি দেয়:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadReports",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::example-bucket/reports/*"
    }
  ]
}

Version-এর তারিখটি policy ভাষার সংস্করণ, আজকের তারিখ নয়, তাই এটি বদলাবেন না। Sid একটি নাম, যা error আর log পড়তে সাহায্য করে। Resource-এর লম্বা ঠিকানাকে বলে ARN. বাকি দুটি লাইনই আসল কথা: কোন Effect, কোন Action.

সব statement মিলিয়ে একটি অনুরোধের ফল তিনটির একটি হয়:

এই শেষ কথাটি firewall থেকে আলাদা। পর্ব ২৭-এ দেখেছেন network ACL-এ প্রথম মিলে যাওয়া নিয়মই শেষ কথা, তাই ক্রম জরুরি। IAM-এ তা নয়। Engine সব statement দেখে, তারপর রায় দেয়।

২ · পুরো শিকল — ছয় ধরনের নিয়ম একসাথে

বড় প্রতিষ্ঠানে একটি অনুরোধের ওপর শুধু একটি policy খাটে না। কারখানার উদাহরণেই ফিরি। ম্যানেজারের চিঠি, গুদামের নিজের তালিকা, পদের সর্বোচ্চ সীমা, আজকের গেটপাস আর মালিকের সাধারণ নোটিশ, সবই একসাথে কাজ করে। AWS-এর নামগুলো দিয়ে তালিকাটি এমন:

এগুলোর সাথে থাকে condition, যা যেকোনো statement-এর গায়ে বসে। আর পর্ব ২৮-এর endpoint policy-ও একটি বাড়তি সীমা, যদি অনুরোধ ওই endpoint দিয়ে আসে। “Guardrail” শব্দটির অর্থ রাস্তার পাশের বেড়া। সে গাড়ি চালায় না, শুধু খাদে পড়া আটকায়।

ছবিটি মনে রাখার একটি সহজ সূত্র আছে। শুধু identity-র দিক থেকে দেখলে যে কাজগুলো সত্যিই করা যায়, সেগুলো হলো সব স্তরের ছেদ (intersection), অর্থাৎ effective permission:

ছোট একটি হিসাব দেখুন। Identity policy দিল {Get, Put, Delete}. Boundary-র সীমা {Get, Put, List}. Session policy-র সীমা {Get, List}. তিনটির ছেদ শুধু {Get}. Identity-তে Delete থাকলেও boundary-তে নেই। Boundary-তে List থাকলেও identity-তে নেই। যে স্তর একেবারে নেই, সেটিকে হিসাব থেকে বাদ দিন। আর identity-তে Allow না থাকলে, শুধু boundary থাকায় কিছুই পাওয়া যায় না।

এবার একটি অনুরোধকে পুরো পথ ধরে হাঁটাই। একজন developer us-east-1 region-এ একটি VM চালু করতে চান। তাঁর নিজের policy-তে অনুমতি আছে, কিন্তু প্রতিষ্ঠানের নিয়মে শুধু একটি region অনুমোদিত। নিচের guardrail-টি সেই নিয়ম:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideApprovedRegion",
      "Effect": "Deny",
      "NotAction": ["iam:*", "sts:*", "organizations:*", "support:*"],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": {
          "aws:RequestedRegion": ["ap-southeast-1"]
        }
      }
    }
  ]
}

NotAction মানে “এই কয়টি বাদে সব”। IAM-এর মতো global service-এর কোনো নির্দিষ্ট region নেই, তাই সেগুলো বাদ রাখতে হয়। এখানে তালিকাটি ছোট করে দেখানো হয়েছে। বাস্তবে সব global service-এর তালিকা মিলিয়ে নিন, নইলে guardrail বৈধ কাজও আটকাবে।

৩ · একই account না অন্য account — কার সম্মতি লাগে

এখানে একটি পার্থক্য পরীক্ষায় আর বাস্তবে দুই জায়গাতেই ধরা পড়ে। Same-account-এ resource আর identity, দুই দিকের যেকোনো একটির Allow সাধারণত যথেষ্ট, যদি অন্য কোনো স্তর না আটকায়। কিন্তু cross-account-এ দুই দিকই Allow করতে হবে।

Same-account-এর দ্বিতীয় সারিতে একটি সূক্ষ্মতা আছে। Resource policy কাকে নাম ধরে Allow করছে (user, role, নাকি একটি session), আর boundary বা session policy আছে কি না, তার ওপর ফল বদলাতে পারে। নতুন নকশায় ডকুমেন্টেশন মিলিয়ে নিন। KMS key-ও আলাদা: key policy অনুমতি না দিলে same-account-এও শুধু identity policy যথেষ্ট নয়। সে কথা পর্ব ৩৩-এ।

Cross-account-এর একটি bucket policy দেখুন। লক্ষ করুন, এখানে Principal আছে। Identity policy-তে এটি থাকে না, কারণ সেখানে principal হলো যার গায়ে policy লাগানো।

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AllowPartnerRoleToRead",
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::111122223333:role/partner-reader"
      },
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::example-bucket/shared/*"
    }
  ]
}

এই policy একা যথেষ্ট নয়। Account 111122223333-এর ভেতরেও partner-reader role-এর identity policy-তে একই কাজের Allow থাকতে হবে। আরেকটি পথ হলো পর্ব ৩১-এর assume role, অর্থাৎ অন্য account-এর role ধারণ করা। তখন role-এর trust policy বলে কে তাকে ধারণ করতে পারবে, আর ধারণকারীর দিকে sts:AssumeRole-এর Allow লাগে। এটিও দুই পক্ষের সম্মতি। Trust policy-তে "Principal": "*" দেখলে সাথে সাথে থামুন। ওটি প্রায় সবসময় ভুল।

৪ · Wildcard ছড়ায়, condition সরু করে

Policy-তে wildcard দুটি: * মানে যেকোনো অক্ষরের সারি, ? মানে ঠিক একটি অক্ষর। s3:Get* লিখলে “Get” দিয়ে শুরু সব S3 action ধরা পড়ে। লেখা সহজ, কিন্তু চোখে দেখে বোঝা কঠিন এটি কতদূর ছড়াল। তাই নিচের কোডে ২০টি action-এর ছোট একটি নমুনা তালিকায় প্রতিটি pattern মেপে দেখি। আসল তালিকা অনেক বড়, তাই এই শতাংশগুলো শুধু এই নমুনার জন্য।

// How far does each pattern reach? A small sample of action names.
const actions = ['s3:GetObject', 's3:GetBucketPolicy', 's3:GetObjectTagging', 's3:PutObject',
  's3:PutBucketPolicy', 's3:DeleteObject', 's3:DeleteBucket', 's3:ListBucket',
  'ec2:DescribeInstances', 'ec2:DescribeImages', 'ec2:RunInstances', 'ec2:TerminateInstances',
  'iam:GetRole', 'iam:ListRoles', 'iam:PassRole', 'iam:PutRolePolicy', 'iam:CreateAccessKey',
  'sqs:SendMessage', 'sqs:ReceiveMessage', 'sqs:PurgeQueue'];
const toRegex = p => new RegExp('^' + p.replaceAll('.', '[.]').replaceAll('*', '.*').replaceAll('?', '.') + '$');
const expand = (p, list) => list.filter(a => toRegex(p).test(a));

const patterns = ['*', 's3:*', 's3:Get*', 's3:*Object', 's3:?etObject', 'ec2:Describe*', 'iam:*', 'iam:P*'];
for (const p of patterns) {
  const hit = expand(p, actions);
  const pct = (100 * hit.length / actions.length).toFixed(0);
  console.log(p.padEnd(15), String(hit.length).padStart(2), pct.padStart(4) + '%');
}
console.log('s3:*Object ->', expand('s3:*Object', actions).join(' '));
console.log('iam:P*     ->', expand('iam:P*', actions).join(' '));

// The provider adds a new action next year (invented name).
const later = [...actions, 's3:GetFutureThing'];
console.log('s3:Get* before', expand('s3:Get*', actions).length, 'after', expand('s3:Get*', later).length);
console.log('exact list stays', ['s3:GetObject'].length);

এবার উল্টো দিক। Condition একটি statement-কে নির্দিষ্ট পরিস্থিতিতে আটকে দেয়। Condition মিথ্যা হলে statement-টি যেন নেই। চারটি জনপ্রিয় ধরন:

Tag-ভিত্তিক এই পদ্ধতির নাম ABAC. RBAC-এ প্রতিটি project-এর জন্য আলাদা role বানাতে হয়। ABAC-এ একটি নিয়মই বলে “যার project-tag যা, সে শুধু সেই tag-এর জিনিসে কাজ করবে”। নিচে তিনটি ধরন একসাথে:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "StartStopOwnProjectVms",
      "Effect": "Allow",
      "Action": ["ec2:StartInstances", "ec2:StopInstances"],
      "Resource": "arn:aws:ec2:*:123456789012:instance/*",
      "Condition": {
        "StringEquals": {
          "aws:ResourceTag/project": "${aws:PrincipalTag/project}"
        }
      }
    },
    {
      "Sid": "DenyDeleteWithoutMfa",
      "Effect": "Deny",
      "Action": ["s3:DeleteObject", "s3:DeleteBucket"],
      "Resource": "*",
      "Condition": {
        "BoolIfExists": { "aws:MultiFactorAuthPresent": "false" }
      }
    },
    {
      "Sid": "TemporaryAuditRead",
      "Effect": "Allow",
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::example-bucket/audit/*",
      "Condition": {
        "DateLessThan": { "aws:CurrentTime": "2026-12-31T23:59:59Z" }
      }
    }
  ]
}

দ্বিতীয় statement-এর BoolIfExists খেয়াল করুন। শুধু Bool লিখলে স্থায়ী access key-এর অনুরোধে key-টি অনুপস্থিত থাকে, condition মেলে না, আর Deny খাটে না। এই একটি শব্দ না থাকলে নিয়মটি চুপচাপ ফাঁকা হয়ে যায়। Condition-এর ভেতরে দুটি key থাকলে দুটিই সত্য হতে হয়, আর একটি key-এর একাধিক মান থাকলে যেকোনো একটি মিললেই চলে। প্রথমটি AND, দ্বিতীয়টি OR.

এবার একটি ছোট evaluator চালিয়ে দেখুন। এটি আসল engine নয়, শুধু একটি policy-র ভেতরের যুক্তি: default deny, Deny-র জয়, wildcard আর condition. প্রতিটি অনুরোধের নিচে কারণের সারি ছাপা হবে।

const match = (pat, s) => new RegExp('^' + pat.replaceAll('.', '[.]').replaceAll('*', '.*').replaceAll('?', '.') + '$').test(s);
const ARN = 'arn:aws:s3:::example-bucket/*';
const policy = [
  { sid: 'ReadReports', effect: 'Allow', action: 's3:Get*', resource: ARN },
  { sid: 'UploadFromOffice', effect: 'Allow', action: 's3:PutObject', resource: ARN,
    when: { ipPrefix: '10.20.' } },
  { sid: 'DeleteByOps', effect: 'Allow', action: 's3:Delete*', resource: ARN,
    when: { team: 'ops' } },
  { sid: 'DenyDeleteNoMfa', effect: 'Deny', action: 's3:Delete*', resource: '*',
    when: { mfa: false } },
];
const condOk = (w = {}, r) =>
  (w.ipPrefix === undefined || r.ip.startsWith(w.ipPrefix)) &&
  (w.team === undefined || r.team === w.team) &&
  (w.mfa === undefined || r.mfa === w.mfa);
function evaluate(r) {
  const res = 'arn:aws:s3:::example-bucket/' + r.key, trace = [];
  let allowed = false;
  for (const s of policy) {
    if (!match(s.action, r.action) || !match(s.resource, res)) continue;
    if (!condOk(s.when, r)) { trace.push(s.sid + ': condition false'); continue; }
    trace.push(s.sid + ': ' + s.effect);
    if (s.effect === 'Deny') return ['DENY (explicit)', trace];
    allowed = true;
  }
  return [allowed ? 'ALLOW' : 'DENY (implicit)', trace];
}
const base = { key: 'r.csv', ip: '203.0.113.9', team: 'dev', mfa: true };
for (const [action, extra] of [['s3:GetObject', {}], ['s3:PutObject', { ip: '10.20.3.4' }],
  ['s3:PutObject', {}], ['s3:DeleteObject', { team: 'ops' }],
  ['s3:DeleteObject', { team: 'ops', mfa: false }], ['s3:ListBucket', {}]]) {
  const [result, trace] = evaluate({ ...base, ...extra, action });
  console.log(action, JSON.stringify(extra), '=>', result);
  console.log('   ', trace.join(' | ') || 'no statement matched');
}

৫ · Azure আর Google কোথায় আলাদা

এতক্ষণের নামগুলো AWS-এর, কারণ সেখানে স্তরগুলো সবচেয়ে আলাদা করে দেখা যায়। ধারণা তিনটিই এক: default deny, ন্যূনতম অনুমতি, আর ওপর থেকে guardrail. তফাত আসে গঠনে। নিচের সারসংক্ষেপ লেখার সময়ের, service-ভেদে বদলাতে পারে, তাই provider-এর ডকুমেন্টেশন মিলিয়ে নিন।

সবচেয়ে বড় মানসিক বদল inheritance-এ। Azure আর Google-এ ওপরের স্তরে দেওয়া অনুমতি নিচের সব জায়গায় নামে। ফলে একটি project-এ দেখে মনে হতে পারে কারও অনুমতি নেই, অথচ folder স্তরে দেওয়া আছে। তাই সেখানে “কে কী পারে” জানতে শুধু resource নয়, ওপরের সব স্তর দেখতে হয়।

৬ · Least privilege বাস্তবে — ছোট শুরু, log দেখে কমানো

Least privilege মানে কাজের জন্য যতটুকু দরকার ততটুকুই অনুমতি। বলা সহজ। কঠিন হলো, একটি নতুন service-এর দরকার কতটুকু, সেটি শুরুতে কেউ ঠিক জানেন না। তাই একে একবারের কাজ না ভেবে একটি চক্র ভাবুন। সময়ের সাথে অনুমতি জমতেই থাকে, একে বলে permission creep. মেসের ভাড়াটিয়া চলে যাওয়ার পরও চাবি ফেরত না নিলে যা হয়, এটিও তাই।

তিন provider-এই এই কাজের সরঞ্জাম আছে। নাম ও সুবিধা বদলায়, তাই ব্যবহারের আগে ডকুমেন্টেশন দেখুন:

এবার মূল হিসাবটি নিজে করি। একটি role-কে s3:* আর sqs:* দেওয়া আছে। নমুনা তালিকায় তা ১৪টি action. ৯০ দিনের log-এর সাথে মিলিয়ে দেখি কোনটি রাখা যায়, কোনটি নিয়ে জিজ্ঞেস করতে হবে, আর কোনটি বাদ।

// Compare granted actions with an access log. Sample data, 90-day window.
const catalog = ['s3:GetObject', 's3:PutObject', 's3:DeleteObject', 's3:ListBucket',
  's3:GetBucketPolicy', 's3:PutBucketPolicy', 's3:PutBucketAcl', 's3:DeleteBucket',
  'sqs:SendMessage', 'sqs:ReceiveMessage', 'sqs:DeleteMessage', 'sqs:PurgeQueue',
  'sqs:SetQueueAttributes', 'sqs:DeleteQueue'];
const granted = ['s3:*', 'sqs:*'];
const log = `3 s3:GetObject|5 s3:ListBucket|8 sqs:ReceiveMessage|8 sqs:DeleteMessage
12 s3:DeleteObject|20 s3:GetObject|33 s3:PutObject|41 sqs:ReceiveMessage|41 sqs:DeleteMessage
55 s3:ListBucket|60 s3:PutObject|72 s3:GetObject|85 sqs:ReceiveMessage|85 sqs:DeleteMessage
88 s3:PutObject|89 s3:ListBucket|90 s3:GetObject`.split(/[|\n]/).map(l => l.split(' '));

const expand = p => catalog.filter(a => a === p || (p.endsWith('*') && a.startsWith(p.slice(0, -1))));
const allowed = [...new Set(granted.flatMap(expand))];
const seen = {};
for (const [day, action] of log) {
  seen[action] = seen[action] || { hits: 0, last: 0 };
  seen[action].hits++;
  seen[action].last = Math.max(seen[action].last, Number(day));
}
const plan = { KEEP: [], ASK: [], REMOVE: [] };
for (const a of allowed) {
  const s = seen[a];
  if (!s) plan.REMOVE.push(a);
  else if (s.hits < 2) plan.ASK.push(a + ' (hits ' + s.hits + ', last day ' + s.last + ')');
  else plan.KEEP.push(a);
}
for (const k of Object.keys(plan)) console.log(k, plan[k].length, '\n  ' + plan[k].join('\n  '));
const pct = (100 * plan.REMOVE.length / allowed.length).toFixed(1);
console.log('granted', allowed.length, 'removable', plan.REMOVE.length, '=', pct + '%');

একই role-কে এবার ধাপে ধাপে কড়া করি। লক্ষ্য শুধু action কমানো নয়, resource-ও সরু করা, আর কোনো ডাউনটাইম ছাড়া কাজটি শেষ করা।

শেষ policy-টি এমন দাঁড়াল। Resource আলাদা বলে statement-ও আলাদা:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ListReportBucket",
      "Effect": "Allow",
      "Action": ["s3:ListBucket"],
      "Resource": "arn:aws:s3:::example-bucket"
    },
    {
      "Sid": "ReadWriteDeleteReports",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject", "s3:DeleteObject"],
      "Resource": "arn:aws:s3:::example-bucket/reports/*"
    },
    {
      "Sid": "ConsumeJobQueue",
      "Effect": "Allow",
      "Action": ["sqs:ReceiveMessage", "sqs:DeleteMessage"],
      "Resource": "arn:aws:sqs:ap-southeast-1:123456789012:report-jobs"
    }
  ]
}

Lint আর simulator — পরীক্ষার দুই হাতিয়ার

Policy linting মানে code চালানোর আগেই লেখা যাচাই। এটি বানান ভুল, অচল action, *-সহ ঝুঁকিপূর্ণ নকশা ধরে। Policy simulator আসল কাজ না করে বলে দেয় একটি পরিচয়ের একটি অনুরোধে কী রায় হতো। নিচের দুটি AWS CLI কমান্ড শুধু উদাহরণ, চালাতে account লাগবে। এগুলো কিছু বদলায় না, তবে নিজের দায়িত্বে পরীক্ষার account-এ চালান। শেষে role বা ফাইল রেখে দিলে মুছে ফেলুন।

# Lint: check a policy file before it is attached
aws accessanalyzer validate-policy \
  --policy-type IDENTITY_POLICY \
  --policy-document file://report-app-final.json \
  --query 'findings[].[findingType,issueCode]' --output text

# Simulate: what would happen, without doing it
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::123456789012:role/report-app-role \
  --action-names s3:GetObject s3:DeleteBucket \
  --resource-arns "arn:aws:s3:::example-bucket/reports/a.csv" \
  --query 'EvaluationResults[].[EvalActionName,EvalDecision]' \
  --output text

নমুনা আউটপুট, চালিয়ে পাওয়া নয় (version-ভেদে আলাদা হতে পারে):

s3:GetObject     allowed
s3:DeleteBucket  implicitDeny

Simulator-এর সীমাও জানা দরকার। সে আসল অনুরোধ পাঠায় না, আর সব স্তর সবসময় হিসাবে আসে না; যেমন resource policy-র ফল দেখতে সেটি আলাদা করে দিতে হতে পারে। তাই simulator “হ্যাঁ” বললেও একবার throwaway পরিবেশে আসল কাজটি চালিয়ে দেখুন।

৭ · “Access denied” পড়া — স্তর ধরে ধরে

অনেকে access denied দেখলেই বড় অনুমতি দিয়ে দেন। কাজ চলে, কিন্তু নিরাপত্তা হারায়। বদলে error-টি পড়ুন। AWS-এর অনেক service-এ এখন message-এই স্তরের ইঙ্গিত থাকে। নমুনা বার্তা (service-ভেদে আলাদা হতে পারে):

An error occurred (AccessDenied) when calling the GetObject operation:
User: arn:aws:sts::123456789012:assumed-role/report-app-role/i-0abc
is not authorized to perform: s3:GetObject
on resource: "arn:aws:s3:::example-bucket/reports/a.csv"
because no identity-based policy allows the s3:GetObject action

এখানে চারটি উত্তর একসাথে আছে: কে, কী, কোথায়, আর কোন স্তর। “User” অংশে যে নাম, সেটিই আসল পরিচয়। সেটি আপনার ধারণার সাথে না মিললে সমস্যা policy-তে নয়, credential-এ। শেষের বাক্যাংশটি ধরে স্তর চিনুন:

সবসময় এত ভালো বার্তা মেলে না। অনেক app শুধু code-টুকু log করে, বাকিটা ফেলে দেয়। তখন স্তর ধরে খুঁজতে হয়। নিচের স্টেপারে ভোরের সেই report প্রোগ্রামের সমস্যাটিই ধরি।

পুরো টিম বা account-এর ছবি পেতে audit log-কে একসাথে পড়া যায়। আসল CloudTrail JSON-এ আসে; এখানে সেটি সরল করা এক লাইনের নমুনা। পদ্ধতিটি পর্ব ৯-এর।

set -euo pipefail
export LC_ALL=C
# Sample audit log: time, role, action, result, reason. All values are fictional.
cat > audit.log <<'LOG'
2026-03-02T09:14:05Z report-app s3:GetObject Success -
2026-03-02T09:14:07Z report-app kms:Decrypt AccessDenied no-identity-policy
2026-03-02T09:19:07Z report-app kms:Decrypt AccessDenied no-identity-policy
2026-03-02T10:02:11Z dev-role ec2:RunInstances AccessDenied explicit-deny-guardrail
2026-03-02T10:03:40Z dev-role ec2:RunInstances AccessDenied explicit-deny-guardrail
2026-03-02T10:04:02Z dev-role ec2:RunInstances Success -
2026-03-02T11:30:15Z ci-deploy iam:PassRole AccessDenied no-identity-policy
2026-03-02T12:45:51Z report-app kms:Decrypt AccessDenied no-identity-policy
2026-03-02T13:05:09Z backup-job s3:PutObject AccessDenied no-resource-policy
2026-03-02T13:05:39Z backup-job s3:PutObject AccessDenied no-resource-policy
LOG

echo "denied / total:"
awk '$4 == "AccessDenied" { d++ } END { print d " / " NR }' audit.log

echo "top denied (count role action reason):"
grep ' AccessDenied ' audit.log |
  awk '{ print $2, $3, $5 }' | sort | uniq -c | sort -k1,1nr -k2,2

echo "by layer:"
awk '$4 == "AccessDenied" { print $5 }' audit.log | sort | uniq -c | sort -k1,1nr -k2,2

৮ · বাড়তি অনুমতির সাধারণ ভুল — review-এর তালিকা

এই তালিকা policy পর্যালোচনার জন্য। প্রতিটি সারি পড়ুন একজন reviewer-এর চোখে: এখানে বাড়তি অনুমতি কী, আর সরু রূপটি কী।

iam:PassRole নিয়ে একটু বেশি বলা দরকার, কারণ নামটি নিরীহ শোনায়। আপনি যখন একটি VM-কে instance role দেন, বা একটি function-কে role দেন, তখন আসলে আপনি নিজের হাতে থাকা অধিকারে অন্য একটি পরিচয় একটি service-এর হাতে তুলে দিচ্ছেন। তাই pass role আসলে delegation. প্রশ্নটি হলো: কোন role, কোন service-কে? কারখানার ভাষায়, যিনি অন্যের নামে গেটপাস ইস্যু করতে পারেন, তাঁর তালিকায় ঠিক কোন পাস আছে, তা লেখা থাকা চাই। সরু রূপটি এমন:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PassOnlyReportRoleToEc2",
      "Effect": "Allow",
      "Action": ["iam:PassRole"],
      "Resource": "arn:aws:iam::123456789012:role/report-app-role",
      "Condition": {
        "StringEquals": { "iam:PassedToService": "ec2.amazonaws.com" }
      }
    }
  ]
}

৯ · AI-এর যুগে IAM policy

AI-কে শুধু “access denied ঠিক করে দিন” বললে সে প্রায়ই সবচেয়ে সহজ পথ নেয়: *. Error চলে যায়, আর সবাই খুশি। আসল সমস্যাটি তখনই শুরু হয়, কারণ ভুল অনুমতি কোনো error দেয় না। সে চুপচাপ বসে থাকে। Cloud-এর বাকি কাজেও AI একই ধরনের ভুল করে, তাই পুরো তালিকাটি মনে রাখুন:

AI-এর লেখা policy হাতে পেলে — যাচাইয়ের চেকলিস্ট

• প্রতিটি action-এর কারণ নিজের ভাষায় বলতে পারি; * থাকলে তার কারণ লেখা আছে
• প্রতিটি action আর condition key provider-এর অফিসিয়াল তালিকায় মিলিয়েছি
• Linter চালিয়েছি; JSON parse হয়, আর কোনো security warning বাকি নেই
• Simulator-এ অনুমোদিত আর নিষিদ্ধ, দুই রকম অনুরোধই পরীক্ষা করেছি
• iam:PassRole, policy বদলানোর action আর "Principal": "*" আলাদা করে দেখেছি
• Throwaway পরিবেশে চালিয়ে diff পড়েছি; পুরোনো version-এ ফেরার পথ আছে
• Denied log-এ alert আছে, budget alert চালু, আর prompt-এ কোনো আসল secret দিইনি