AWS কীভাবে সিদ্ধান্ত নেয়: Explicit Deny, Implicit Deny, Allow

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

• একটা request যাচাইয়ের তিনটা সম্ভাব্য ফল বুঝিয়ে বলতে পারবে: explicit deny, implicit deny আর allow। আর বলতে পারবে explicit deny কেন সবসময় জেতে।
• একজন user কয়েকটা group-এ থাকলে আর তাদের policy একটা আরেকটার উল্টো বললে, সে কী পারবে আর কী পারবে না, হাতে-কলমে বের করতে পারবে।
• একটা policy statement কখন একটা request-এর সঙ্গে “মেলে”, ঠিক করতে পারবে: action, resource, condition আর principal দেখে।
• এক account-এর ভেতরের একটা request-এর জন্য AWS কোন কোন ধরনের policy পড়ে, তার তালিকা দিতে পারবে। আর বলতে পারবে কোনগুলো permission দেয়, কোনগুলো শুধু সীমা টানে।
• পুরো যাচাইয়ের ধাপগুলো (Deny, RCP, SCP, resource-based, identity-based, boundary, session) ধরে এগোতে পারবে, আর জানবে কখন ফল যোগফল (union) আর কখন মিল (intersection)।
• condition আর NotAction দিয়ে Deny-এর পাহারা লিখতে পারবে, যেমন Region পাহারা, global service আটকে না দিয়েই।
• একটা request কেন deny হলো, খুঁজে বের করতে পারবে: error message, encode করা authorization message, CloudTrail আর policy simulator দিয়ে।

#প্রতিটা request-এর একটা রায় হয়

২.১ lesson-এ তুমি policy লিখেছ: JSON document, যেখানে লেখা থাকে কোন principal কোন resource-এ কোন action চালাতে পারবে। কিন্তু policy একা কিছুই করে না। তার কাজ শুরু হয় যখন কেউ একটা request পাঠায়: “Alice arn:aws:s3:::reports/q3.csv-এ s3:GetObject চালাতে চায়”।

ঠিক তখন AWS-কে একটা প্রশ্নের উত্তর দিতে হয়: allow, নাকি deny? এটা সে করে প্রতিটা API call-এর জন্য, call-টা console থেকে আসুক, CLI থেকে, SDK থেকে বা অন্য কোনো AWS service থেকে। সেকেন্ডে লাখ লাখ বার। AWS-এর যে অংশ এই উত্তর দেয়, তাকে সাধারণত বলা হয় policy engine (AWS-এর documentation-এ নাম enforcement code)। কাজটা হয় তিন ধাপে:

1. Authenticate: request-টা কে sign করেছে, যাচাই করা (একজন user, একটা role session, নাকি root user)। কয়েকটা service, যেমন public bucket-ওয়ালা S3, নাম-পরিচয় ছাড়া request-ও নেয়।
2. Request context বানানো: policy যা যা জানতে চাইতে পারে, সব জড়ো করা। principal (কে), action (কী), resource (কীসের ওপর), আর environment: কোন IP address থেকে এল, কখন এল, কোন Region-এ, MFA ব্যবহার হয়েছে কি না, principal আর resource-এর tag, call-টা TLS দিয়ে এসেছে কি না।
3. যাচাই: এই context-এর ওপর যত policy খাটে, সব পড়া, আর তিনটা ফলের ঠিক একটায় পৌঁছানো।

খেয়াল করো, “না” শোনার দুটো আলাদা রাস্তা আছে, আর দুটোর সমাধান একদম উল্টো। পুরো lesson জুড়ে এটা মাথায় রাখবে।

#তিনটা নিয়ম

এই lesson-এর সবকিছু ঘুরেফিরে তিনটা নিয়মে আসে। আগে এগুলো পাকা করে নাও।

#নিয়ম ১: default-ভাবে সব বন্ধ

একদম নতুন একটা IAM user বা role কিছুই করতে পারে না। bucket-এর তালিকা দেখতে পারে না, console-এর dashboard দেখতে পারে না, এমনকি নিজের password-ও বদলাতে পারে না, যদি না কোনো policy সেটা allow করে। প্রতিটা request শুরু হয় “deny” দিয়ে, আর সেটা বদলাতে একটা Allow লাগে।

এটাই implicit deny। “implicit” মানে কেউ এটা লেখেনি: কোনো policy “হ্যাঁ” না বললে এমনিতেই এটা হয়। যে policy শুধু EC2 নিয়ে কথা বলে, সে S3 নিয়ে কিছুই বলে না। তাই S3-এর বেলায় সে চুপ, আর চুপ থাকা মানে “না”।

#নিয়ম ২: explicit Allow default-টা তুলে দেয়

"Effect": "Allow" লেখা একটা statement request-এর সঙ্গে মিলে গেলে default deny বদলে allow হয়ে যায়। Allow-টা কোথা থেকে এল, তাতে কিছু যায় আসে না: user-এর নিজের inline policy, কোনো managed policy, user-এর যেকোনো group, নাকি resource-এর গায়ে বসানো resource-based policy। শর্ত শুধু এটুকু: কেউ deny করবে না, আর কোনো সীমা আটকাবে না।

#নিয়ম ৩: explicit Deny সব Allow-কে হারায়

"Effect": "Deny" লেখা একটা statement request-এর সঙ্গে মিলে গেলে যাচাই সেখানেই শেষ, ফল Deny। কয়টা Allow আছে, সেগুলো কত নির্দিষ্ট, কোথা থেকে এসেছে, কিছুই আর গোনা হয় না।

policy-গুলোর মধ্যে কোনো বড়-ছোট নেই। s3:*-এর ওপর একটা Deny ঠিক এই object-এর ঠিক s3:GetObject-এর Allow-কেও হারিয়ে দেয়। firewall বা CSS-এর অভ্যাস থেকে অনেকে ভাবে “যে নিয়ম বেশি নির্দিষ্ট, সে-ই জেতে”। AWS IAM-এ তা না: মিলে যাওয়া Deny সবসময় জেতে।

#এক user, কয়েকটা group

কোর্সের নোটের উদাহরণ এটা, আর পরীক্ষায় এই বিষয়টা সবচেয়ে বেশি এই চেহারাতেই আসে।

একজন user কয়েকটা group-এ থাকতে পারে (১০টা পর্যন্ত)। এক group-এর ভেতরে আরেক group রাখা যায় না। user-এর identity-based permission মানে user-এর গায়ে লাগানো সব policy, আর সে যত group-এ আছে তাদের প্রতিটার সব policy, সব এক স্তূপে। AWS group-গুলোকে কোনো ক্রমে সাজায় না: কোনো group-এর বেশি privilege নেই, আগে-পরে বলে কিছু নেই, “শেষে যোগ করা group জেতে” বলেও কিছু নেই। পুরো স্তূপটা ওই তিন নিয়মেই যাচাই হয়।

Alice আছে Group A আর Group B দুটোতেই।

শেষ সারিটা ইচ্ছে করে বানানো, খুব চেনা একটা নকশা: একটা group-এ টিমকে বড়সড় অধিকার দাও, আর “এটা কখনো না” ধরনের নিয়মগুলো (backup মোছা, logging বন্ধ করা, organization ছেড়ে যাওয়া) একটা Deny-তে রাখো, যেটা সবার ওপর খাটে।

#একটা statement কখন মেলে?

“মিলে যাওয়া Deny” আর “মিলে যাওয়া Allow”, এই কথার পেছনে একটা নির্দিষ্ট নিয়ম আছে। একটা statement একটা request-এর ওপর খাটে শুধু তখন, যখন নিচের সবগুলো মেলে:

কোনো একটা অংশ না মিললে statement-টা খাটেই না: ধরে নাও ওটা ওখানে নেই। এর একটা গুরুত্বপূর্ণ ফল আছে:

• যে Allow-এর condition মিথ্যা, সে কিছুই দেয় না। ওই statement থেকে কোনো allow আসে না।
• যে Deny-এর condition মিথ্যা, সে কিছুই আটকায় না। ওই statement থেকে কোনো deny আসে না।

condition কখনো একটা Allow-কে Deny বানিয়ে দেয় না। “X না হলে deny” চাইলে উল্টো condition দিয়ে একটা Deny লিখতে হয় (“X না হলে Deny”), যেমনটা নিচের Region পাহারায় করা হয়েছে।

বাস্তবে বেশির ভাগ access denied error আসে দুটো ভুল থেকে:

• bucket বনাম object। s3:ListBucket কাজ করে bucket-এর ARN-এ (arn:aws:s3:::reports); s3:GetObject কাজ করে object-এর ARN-এ (arn:aws:s3:::reports/*)। policy-তে শুধু reports/* থাকলে যে file-গুলোর নাম তুমি আগে থেকে জানো সেগুলো পড়তে পারবে, কিন্তু তালিকা দেখতে পারবে না।
• তুমি যে action ভাবছ বনাম tool আসলে যে action চালায়। console আর অনেক tool একটা click-এর জন্য কয়েকটা action চালায়। “bucket দেখো” পাতাটা হয়তো ListBucket, GetBucketLocation আর GetBucketPolicy তিনটাই চালায়। যেকোনো একটার Allow না থাকলেই error দেখাবে।

#policy-গুলো কোথায় থাকে

এক account-এর ভেতরের একটা request ছয় ধরনের policy-র সামনে পড়তে পারে। এরা দুই দলে ভাগ: যারা permission দেয়, আর যারা শুধু সীমা টানে।

সীমা টানার দলের policy কখনো কিছু দেয় না। একটা permissions boundary s3:* allow করলেও user S3 ছুঁতে পারে না; এর মানে শুধু S3 কেড়ে নেওয়া হয়নি। একটা SCP সব allow করলেও কেউ administrator হয়ে যায় না।

পুরনো access control list-ও আছে (S3 ACL, VPC network ACL)। তবে নতুন bucket-এ S3 ACL default-ভাবে বন্ধ থাকে, আর এখানকার যুক্তিতে এরা কিছু বদলায় না।

#এক account-এর ভেতরে পুরো যাচাইয়ের ধাপ

principal আর resource একই account-এ থাকলে AWS এই ক্রমে request যাচাই করে (IAM User Guide-এর “Policy evaluation logic” থেকে, অক্টোবর ২০২৬-এ মিলিয়ে দেখা):

1. ১. কোথাও explicit Deny আছে কি না খোঁজো

   AWS প্রতিটা ধরনের, যত policy খাটে সবগুলো পড়ে: identity-based, resource-based, permissions boundary, session policy, SCP আর RCP। কোনো Deny statement মিলে গেলে চূড়ান্ত সিদ্ধান্ত Deny। পরের কোনো ধাপ আর এটা বদলাতে পারে না।

2. ২. RCP

   account যদি এমন organization-এ থাকে যেখানে RCP চালু, তাহলে RCP-কে এই resource-এ এই action allow করতে হবে। বাস্তবে RCPFullAWSAccess নামের একটা RCP সবসময় লাগানো থাকে, আর সেটা খোলা যায় না। তাই RCP কোনো request থামায় শুধু explicit Deny দিয়ে, আর সেটা ১ নম্বর ধাপেই ধরা পড়ে যায়।

3. ৩. SCP

   account কোনো organization-এ থাকলে, তার ওপর যে SCP-গুলো খাটে সেগুলোকে action-টা allow করতে হবে। কোনো SCP allow না করলে সিদ্ধান্ত Deny (SCP থেকে আসা implicit deny)। management account-এর ওপর SCP খাটে না।

4. ৪. Resource-based policy

   resource-এর গায়ে যদি এমন resource-based policy থাকে যেটা এই principal-কে allow করে, তাহলে সেই Allow একাই যথেষ্ট হতে পারে। IAM user-এর নাম সরাসরি লেখা থাকলে সত্যিই যথেষ্ট: user-এর নিজের policy আর boundary কিছু না বললেও সিদ্ধান্ত Allow। কিন্তু IAM role-এর ARN লেখা থাকলে, সেই Allow-কেও role-এর permissions boundary আর session policy পার হতে হয় (৬ আর ৭ নম্বর ধাপ)। এমন কোনো Allow না থাকলে সামনে এগোও।

5. ৫. Identity-based policy

   user-এর (তার সব group-সহ) বা role-এর policy-কে action-টা allow করতে হবে। কেউ না করলে, আর ৪ নম্বর ধাপেও কিছু না পেলে, সিদ্ধান্ত Deny (implicit)।

6. ৬. Permissions boundary

   user বা role-এর permissions boundary থাকলে, সেটাকেও action-টা allow করতে হবে। না করলে সিদ্ধান্ত Deny।

7. ৭. Session policy

   principal যদি একটা role session বা federated user session হয়, আর তাকে একটা session policy দেওয়া হয়ে থাকে, তাহলে session policy-কেও action-টা allow করতে হবে। না করলে Deny। session policy না থাকলে, বা principal আদৌ কোনো session না হলে (যেমন IAM user), সিদ্ধান্ত Allow।

Associate পরীক্ষার জন্য হুবহু এই ক্রম মুখস্থ করতে হবে না। কিন্তু এখান থেকে যে দুটো কথা বেরিয়ে আসে, সেগুলো জানতেই হবে: কোথাও explicit Deny থাকলে সে জেতে, আর একটা Allow-কে যত সীমা খাটে সবগুলো পার হতে হয়।

#যোগফল আর মিল (union আর intersection)

বেশির ভাগ প্রশ্নের উত্তর শেষে এসে দাঁড়ায় একটা জিজ্ঞাসায়: দুই ধরনের policy কি যোগ হয়, নাকি তাদের মিলটুকু নেওয়া হয়?

আলাদা account-এর মধ্যে request হলে (account A-র Alice account B-র একটা bucket পড়তে চায়) নিয়ম বদলে যায়: দুই দিককেই allow করতে হবে। account A-র identity policy আর account B-র resource policy, দুটোকেই। তখন একটা Allow আর যথেষ্ট না। ২.৪ lesson আর ২০ নম্বর chapter-এ এটা আছে।

#এক অনুচ্ছেদে permissions boundary

permissions boundary হলো একটা managed policy, যেটা কোনো user বা role-এর ছাদ হিসেবে বসানো হয়। খুব চেনা একটা ব্যবহার: তুমি developer-দের তাদের Lambda function-এর জন্য role বানাতে দিলে, কিন্তু শর্ত দিলে যে প্রতিটা নতুন role-এ এমন একটা boundary থাকবে যেখানে IAM আর billing নেই। তারা যত দরাজ policy-ই লাগাক, role-টা boundary-র বেশি কিছু কখনো করতে পারবে না। ফলে কেউ নিজেকে administrator বানিয়ে ফেলতে পারবে না। boundary বসানো যায় user আর role-এ, group-এ না। ২০ নম্বর chapter-এ এটা বিস্তারিত আছে।

#হাতে-কলমে request যাচাই

যেকোনো request-এর জন্য এই ক্রমে চারটা প্রশ্ন করো:

1. কোনো Deny মেলে? প্রতিটা policy দেখো, condition আর NotAction-সহ। মিললে থামো: denied।
2. প্রতিটা সীমা কি allow করে? SCP (organization-এ থাকলে, আর management account না হলে), permissions boundary (থাকলে), session policy (session হলে আর policy দেওয়া থাকলে)। একটাও না করলে থামো: denied।
3. অন্তত একটা দেওয়ার জায়গা কি allow করে? একটা identity-based policy, অথবা (একই account-এ) এই principal-এর নাম লেখা একটা resource-based policy। কেউ না করলে denied (implicit)।
4. না হলে: allowed।

#উদাহরণ ১: condition-ওয়ালা Deny

{
  "Version": "2012-10-17",
  "Statement": [
    { "Effect": "Allow", "Action": "s3:*", "Resource": "*" },
    {
      "Effect": "Deny",
      "Action": "s3:*",
      "Resource": "*",
      "Condition": { "NotIpAddress": { "aws:SourceIp": "203.0.113.0/24" } }
    }
  ]
}

• অফিস থেকে request, 203.0.113.25: Deny-এর condition (“source IP 203.0.113.0/24-এর ভেতরে না”) মিথ্যা, তাই Deny খাটে না। Allow মেলে: allowed।
• বাসা থেকে request, 198.51.100.7: condition সত্যি, Deny মিলে যায়: denied, যদিও Allow-টা তখনও আছে।
• Alice-এর হয়ে কোনো AWS service request পাঠালে (যেমন তার চালু করা একটা stack একটা bucket বানাচ্ছে): তখন source IP হয় ওই service-এর, অফিসের না। তাই এই Deny সেটাও আটকে দেয়। এজন্যই AWS-এর নিজের উদাহরণে এমন পাহারার সঙ্গে "Bool": {"aws:ViaAWSService": "false"} যোগ করা থাকে।

#উদাহরণ ২: identity আর resource মিলে যোগফল

Carol-এর নিজের কোনো S3 permission নেই। reports bucket-এ এই bucket policy আছে, আর Carol একই account-এ:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Principal": { "AWS": "arn:aws:iam::111122223333:user/carol" },
    "Action": "s3:GetObject",
    "Resource": "arn:aws:s3:::reports/*"
  }]
}

• Carol reports/q3.csv পড়ছে: কোথাও Deny নেই, bucket policy-তে তার নাম আছে: allowed। একই account, তাই একটা Allow-ই যথেষ্ট।
• Carol bucket-এর তালিকা দেখতে চাইছে: bucket policy শুধু object-এর ওপর GetObject allow করে, তার identity policy কিছুই allow করে না: denied (implicit)।
• Carol অন্য একটা bucket থেকে পড়ছে: কোথাও Allow নেই: denied (implicit)।

#উদাহরণ ৩: boundary

Dave-এর identity policy হলো AdministratorAccess (*-এর ওপর * Allow)। তার permissions boundary allow করে শুধু ec2:*, cloudwatch:* আর s3:*।

• ec2:RunInstances: দুটোই allow করে: allowed।
• iam:CreateUser: তার policy allow করে, boundary করে না: denied।
• s3:GetObject, কিন্তু bucket policy Dave-কে deny করে: explicit Deny: denied।

#উদাহরণ ৪: SCP

Erin একটা member account-এর administrator। তার OU-তে এমন একটা SCP আছে যেটা সব allow করে, শুধু দুটো Region-এর বাইরে ec2:*-এ Deny।

• eu-west-1-এ ec2:RunInstances: কোনো Deny মেলে না, SCP allow করে, তার policy allow করে: allowed।
• একই কাজ us-east-1-এ: SCP-র Deny মিলে যায়: denied। administrator হয়েও লাভ নেই; SCP পুরো account-এর মাথার ওপরে।
• একই request management account-এর একজন user-এর কাছ থেকে: সেখানে SCP খাটে না: allowed।

#উদাহরণ ৫: দুইবার deny হওয়া একটা request

Frank-এর কোনো policy-ই নেই, আর Group B (তার একমাত্র group) s3:DeleteObject deny করে। Frank একটা object মুছতে চাইল। এটা implicit deny, নাকি explicit? Explicit: কেউ Allow খোঁজার আগেই ১ নম্বর ধাপে মিলে যাওয়া Deny ধরা পড়ে। error message-এ লেখা থাকবে “explicit deny”, আর Allow যোগ করে কোনো লাভ হবে না।

#Deny দিয়ে পাহারা

explicit Deny-কে যেহেতু কেউ হারাতে পারে না, তাই যে নিয়ম কেউ ভাঙতে পারবে না সেটার জন্য এটাই ঠিক হাতিয়ার, পরে কাকে কী permission দেওয়া হলো তাতে কিছু যায় আসে না। কিন্তু রোজকার access control-এর জন্য এটা ভুল হাতিয়ার: সেখানে permission-টা না দিলেই হলো। Deny বেশি হয়ে গেলে policy বুঝে ওঠাই কঠিন হয়ে যায়।

চেনা কিছু পাহারা:

• বিপজ্জনক কাজে MFA বাধ্যতামূলক: aws:MultiFactorAuthPresent মিথ্যা হলে Deny (২.৩ lesson)।
• শুধু অফিসের network থেকে: aws:SourceIp তোমার range না হলে Deny (উদাহরণ ১)।
• শুধু অনুমোদিত Region-এ: aws:RequestedRegion তোমার তালিকায় না থাকলে Deny (নিচে দেখো)।
• পাহারাদারকে পাহারা: সবার জন্য cloudtrail:StopLogging, cloudtrail:DeleteTrail আর backup vault মোছা Deny।
• tag দেখে নিয়ম: caller-এর team tag আর instance-এর team tag না মিললে instance stop করা Deny।

#NotAction দিয়ে Region পাহারা

তুমি চাও কেউ যেন আয়ারল্যান্ড (eu-west-1) আর ফ্রাংকফুর্ট (eu-central-1)-এর বাইরে কিছু বানাতে না পারে, data কোথায় থাকবে সেই নিয়ম মানতে আর খরচ হাতে রাখতে। সবচেয়ে সোজা যেটা মাথায় আসে, সেটা কাজ করে না:

{
  "Effect": "Deny",
  "Action": "*",
  "Resource": "*",
  "Condition": { "StringNotEquals": { "aws:RequestedRegion": ["eu-west-1", "eu-central-1"] } }
}

IAM, STS (global endpoint), Organizations, Route 53, CloudFront, Support-এর মতো global service তাদের request সামলায় us-east-1-এ। তাই Action: "*" দিলে এই পাহারা IAM-এর প্রতিটা call deny করে দেয়, আর administrator-রা user বা role কিছুই সামলাতে পারে না।

সমাধান হলো NotAction: “এগুলো ছাড়া বাকি সব action deny করো”, আর ব্যতিক্রমের তালিকায় global service-গুলো।

{
  "Sid": "DenyOutsideApprovedRegions",
  "Effect": "Deny",
  "NotAction": [
    "iam:*", "sts:*", "organizations:*", "route53:*", "cloudfront:*",
    "support:*", "budgets:*", "waf:*", "globalaccelerator:*"
  ],
  "Resource": "*",
  "Condition": {
    "StringNotEquals": { "aws:RequestedRegion": ["eu-west-1", "eu-central-1"] }
  }
}

এভাবে পড়ো: “Region যদি এই দুটোর কোনোটা না হয়, তাহলে global service ছাড়া বাকি সব deny”। এই পাহারা বেশির ভাগ সময় SCP হিসেবে লেখা হয়, যাতে পুরো account ঢাকা পড়ে (২০ নম্বর chapter)। তবে identity policy-তেও এটা একইভাবে কাজ করে।

#Allow-এর সঙ্গে NotAction আর NotResource: সাবধান

Allow-এর সঙ্গে NotAction মানে “এগুলো ছাড়া বাকি সব action allow”, আর তার মধ্যে AWS ভবিষ্যতে যত নতুন action যোগ করবে সেগুলোও পড়ে। AWS-এর managed policy PowerUserAccess ঠিক এভাবেই বানানো: IAM, Organizations আর account management ছাড়া সব allow করে। তুমি যদি সত্যিই এটা চাও, ঠিক আছে। কিন্তু যদি একটা সরু তালিকা থেকে এক-দুটো জিনিস বাদ দিতে চেয়েছিলে, তাহলে এটা বিপজ্জনক।

NotResource resource-এর বেলায় ঠিক একইভাবে কাজ করে। NotResource দিয়ে একটা Deny (“এই bucket ছাড়া সব deny”) কোনো principal-কে একটা resource-এর ভেতরে আটকে রাখার খুব চেনা উপায়।

#access deny হলে: কেন হলো খুঁজে বের করা

কিছু একটা access denied error দিয়ে fail করলে এই ধাপগুলো ধরে এগোও।

1. পুরো error message পড়ো

   এখন বেশির ভাগ service বলে দেয় request-টা কোন ধরনের policy আটকেছে, আর সেটা implicit নাকি explicit। যেমন: “User: arn:aws:iam::111122223333:user/alice is not authorized to perform: s3:GetObject on resource: … because no identity-based policy allows the s3:GetObject action”, অথবা “… with an explicit deny in a service control policy”। implicit মানে: ঠিক জায়গায় একটা Allow যোগ করো। explicit মানে: Deny-টা খুঁজে বের করো।

2. encode করা authorization message decode করো

   EC2 আর আরও কিছু service বিস্তারিত না দিয়ে একটা encode করা message সহ UnauthorizedOperation error ফেরত দেয়, কারণ বিস্তারিতে এমন তথ্য থাকতে পারে যা বাইরে যাওয়া উচিত না। যার sts:DecodeAuthorizationMessage permission আছে, সে aws sts decode-authorization-message --encoded-message <blob> চালাতে পারে। ফেরত আসা JSON-এ থাকে action, resource, পুরো request context, আর কোনো explicit Deny মিলেছিল কি না।

3. CloudTrail-এ খোঁজো

   CloudTrail API call লিখে রাখে: কে call করল, কোন source IP থেকে, কোন action, আর errorCode কী (AccessDenied, UnauthorizedOperation)। ঠিক কী চেষ্টা করা হয়েছিল, এখানে দেখা যায়, আর সেটা প্রায়ই user যা ভাবছে তার সঙ্গে মেলে না। মনে রেখো, management event default-ভাবেই লেখা হয়, কিন্তু S3 object-এর call আর অন্য data event দেখা যায় শুধু তখন, যখন কোনো trail সেগুলো লেখে।

4. policy simulator দিয়ে পরীক্ষা করো

   IAM policy simulator (console-এ, অথবা aws iam simulate-principal-policy) তোমার বলে দেওয়া action আর resource-এর ওপর একটা user বা role-এর policy যাচাই করে, আর কোন statement মিলেছে সেটা দেখায়। নতুন কোনো পাহারা বসানোর আগে পরীক্ষা করতে, আর সমাধানটা ঠিক কি না প্রমাণ করতে এটা ব্যবহার করো।

5. বদলানোর পর কয়েক সেকেন্ড অপেক্ষা করো

   IAM eventually consistent। এইমাত্র বদলানো একটা policy সব জায়গায় কার্যকর হতে কয়েক সেকেন্ড লাগতে পারে। যে script একটা role বানিয়েই সঙ্গে সঙ্গে ব্যবহার করে, তাতে retry রাখো।

IAM Access Analyzer আরও দুটো যাচাই যোগ করে, যেগুলো পরে দেখবে: policy validation (policy লেখার সময়ই ভুল আর ঝুঁকিপূর্ণ ধরন, যেমন NotAction-ওয়ালা Allow, নিয়ে সতর্ক করে) আর unused access finding।

#system design আর পরীক্ষায় এটা কীভাবে আসে

• আগে least privilege, তারপর Deny। ছোট, নির্দিষ্ট permission দাও। সবার জন্য খাটতে হবে এমন অল্প কয়েকটা নিয়মের জন্যই শুধু একটা shared Deny রাখো।
• দায়িত্ব ভাগ করে রাখা। একটা group বা SCP-তে রাখা “কখনো না” ধরনের shared Deny (backup মোছা, logging বন্ধ করা, organization ছেড়ে যাওয়া) তোমাকে বাঁচায়, এমনকি কেউ ভুল করে AdministratorAccess পেয়ে গেলেও।
• boundary দিয়ে দায়িত্ব দেওয়া। টিমকে role বানাতে দাও, কিন্তু প্রতিটায় একটা permissions boundary বাধ্যতামূলক করো, যাতে কেউ নিজের ক্ষমতা বাড়িয়ে নিতে না পারে।
• পুরো organization জুড়ে পাহারা। Region আর নিষিদ্ধ service-এর জন্য SCP, আর “organization-এর বাইরে থেকে আমাদের data-য় কেউ হাত দিতে পারবে না” ধরনের নিয়মের জন্য RCP।

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

CLI সেট করা থাকলে (১.৩ lesson) এগুলো চালিয়ে দেখো। এরা কিছুই বদলায় না।

# Will alice be allowed to read one object, and which statement decides?
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111122223333:user/alice \
  --action-names s3:GetObject s3:DeleteObject \
  --resource-arns arn:aws:s3:::reports/q3.csv \
  --query 'EvaluationResults[].[EvalActionName,EvalDecision]' --output table
# EvalDecision is allowed, implicitDeny or explicitDeny

# Test a draft policy and a context key without attaching anything
aws iam simulate-custom-policy \
  --policy-input-list file://region-guard.json \
  --action-names ec2:RunInstances \
  --context-entries ContextKeyName=aws:RequestedRegion,ContextKeyValues=us-east-1,ContextKeyType=string

# Decode an EC2 UnauthorizedOperation message
aws sts decode-authorization-message --encoded-message "<paste the blob>" \
  --query DecodedMessage --output text | python -m json.tool

# Recent denied management calls by one user (CloudTrail event history, last 90 days)
aws cloudtrail lookup-events \
  --lookup-attributes AttributeKey=Username,AttributeValue=alice --max-results 50 \
  --query 'Events[].CloudTrailEvent' --output text | grep -o '"errorCode":"[A-Za-z.]*"'

তারপর একটা test account-এ নোটের উদাহরণটা নিজে বানিয়ে দেখো: AmazonS3FullAccess দিয়ে Group A বানাও, Group B-তে s3:*-এর জন্য একটা inline Deny দাও, একটা test user-কে দুটোতেই রাখো, আর ওই user-এর credential দিয়ে aws s3 ls চালাও। তারপর user-কে Group B থেকে সরিয়ে আবার চালাও।

#সারসংক্ষেপ

মূল কথা

• প্রতিটা request-এর ফল হয় explicit deny, implicit deny অথবা allow। সব শুরু হয় deny দিয়ে; একটা Allow default-টা তুলে দেয়; মিলে যাওয়া Deny সব Allow-কে হারায়।
• implicit deny (চুপ থাকা) কোনো নিষেধ না। নিষেধ করতে পারে শুধু explicit Deny।
• একজন user-এর identity-based permission হলো তার নিজের আর তার সব group-এর policy-র যোগফল। group-এর কোনো অগ্রাধিকার নেই।
• একটা statement খাটে শুধু তখন, যখন তার action, resource, condition (আর principal) সব মেলে। condition মিথ্যা হলে statement-টা যেন নেই-ই; সেটা কখনো Allow-কে Deny বানায় না।
• দেয়: identity-based আর resource-based policy। সীমা টানে: permissions boundary, session policy, SCP, RCP। সীমা টানার দল কখনো কিছু দেয় না।
• একই account: identity + resource = union। identity ∩ boundary, ∩ SCP, ∩ session policy = intersection। আলাদা account: দুই দিককেই allow করতে হয়।
• SCP আর RCP কখনো management account-এর ওপর খাটে না। root user-এর কোনো Allow লাগে না, তবু SCP (member account-এ) আর resource policy-র explicit Deny তাকে থামাতে পারে।
• পাহারার জন্য explicit Deny ব্যবহার করো (MFA, IP, Region, log রক্ষা)। Region পাহারায় NotAction দিয়ে global service বাদ দাও, কারণ ওরা চলে us-east-1-এ।
• খুঁজে বের করতে: message পড়ো (implicit নাকি explicit, কোন ধরনের policy), EC2-র encode করা message STS দিয়ে decode করো, CloudTrail-এ খোঁজো, policy simulator-এ পরীক্ষা করো, আর বদলানোর পর কয়েক সেকেন্ড সময় দাও।

নিজেকে যাচাই করো: AWS কীভাবে সিদ্ধান্ত নেয়৩৭টি প্রশ্ন