User, Group ও Policy Document

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

• authentication (তুমি কে?) আর authorization (তুমি কী করতে পারবে?) আলাদা করে চিনতে পারবে, আর বলতে পারবে IAM-এর কোন অংশ কোন কাজটা করে।
• IAM কেন global service, আর তাতে user, group আর policy-র ওপর কী প্রভাব পড়ে, বুঝিয়ে বলতে পারবে।
• root user, IAM user আর IAM group-কে যার যে কাজ সেই কাজেই লাগাতে পারবে, আর group-এর নিয়মগুলো জানবে (শুধু user থাকে, ভেতরে group রাখা যায় না, একজন user সর্বোচ্চ ১০টা group-এ)।
• অনুমতি দেওয়ার সময় principle of least privilege মেনে চলতে পারবে।
• AWS managed, customer managed আর inline policy-র মধ্যে ঠিকটা বেছে নিতে পারবে।
• JSON policy-র প্রতিটা অংশ পড়তে আর লিখতে পারবে: Version, Id, Statement, Sid, Effect, Principal, Action, NotAction, Resource আর Condition; আর ARN ঠিকভাবে লিখতে পারবে।
• identity-based আর resource-based policy আলাদা করতে পারবে, আর policy ভরসা করার আগে IAM Access Analyzer আর policy simulator দিয়ে যাচাই করতে পারবে।

#একটা account, অনেক হাত

নতুন AWS account-এ শুরুতে identity থাকে একটাই: যে email আর password দিয়ে তুমি sign up করেছ। তুমি যা কিছু বানাও (server, database, bucket), সব ওই account-এর, আর সব কিছুর বিলও দেয় ওই account।

কিছুদিনের মধ্যেই একই account-এ আরও মানুষ আর program-কে কাজ করতে হয়:

• একজন developer, যে application deploy করে;
• একজন operations engineer, যে রাতে server restart দেয়;
• একজন auditor, যাকে সব দেখতে হবে কিন্তু কিছু বদলানো চলবে না;
• আর application নিজে, যে S3-এ file লেখে আর database থেকে পড়ে।

sign up-এর password সবার সাথে ভাগ করলে বিপদ: সবাই সব করতে পারবে, কে কী করল কেউ বলতে পারবে না, আর একটা password ফাঁস হলেই পুরো account শেষ। এই সমস্যার সমাধান AWS Identity and Access Management (IAM)। এটা দিয়ে account-এর ভেতরে আলাদা আলাদা identity বানানো যায়, প্রত্যেককে ঠিক যতটুকু দরকার ততটুকু অনুমতি দেওয়া যায়, আর প্রতিটা request সেই অনুমতির সাথে মিলিয়ে দেখা হয়।

IAM ব্যবহারের জন্য কোনো টাকা লাগে না। টাকা লাগে শুধু তোমার user আর application যেসব resource বানায়, সেগুলোর।

#Authentication আর authorization

AWS-এ যেকোনো request (console-এ একটা click, একটা CLI command, code থেকে একটা API call) দুটো আলাদা যাচাই পার হয়:

authentication শেষ হলে authorization-এর জন্য AWS একটা request context বানায়। তাতে থাকে:

• principal: কে চাইছে (IAM user, role, বা root user);
• action: কী করতে চায়, যেমন s3:GetObject বা ec2:StartInstances;
• resource: কীসের ওপর করতে চায়, তার ARN দিয়ে লেখা;
• environment: কোন IP address থেকে request এল, কোন Region-এ যাচ্ছে, কখন, connection-এ TLS আছে কিনা;
• resource সম্পর্কে তথ্য, যেমন তার tag।

AWS এই context-কে মেলায় যত policy প্রযোজ্য তার সবগুলোর সাথে। default উত্তর হলো না: কোনো policy স্পষ্ট করে allow করলে (আর কেউ deny না করলে) তবেই request পাস। policy-গুলো একে অপরের উল্টো কথা বললে কী হয়, সেই পুরো সিদ্ধান্তের হিসাব lesson 2.2-এ।

#IAM একটা global service

বেশির ভাগ AWS service regional: একটা EC2 instance থাকে একটা Region-এ, একটা AMI-ও একটা Region-এর (lesson 4.3)। IAM আলাদা। IAM global: তুমি user, group, role বা policy বানালে সেটা একসাথে account-এর সব Region-এ থাকে। IAM console-এ Region বেছে নেওয়ার কিছু নেই, আর alice নামের user একই password আর একই অনুমতি নিয়ে মুম্বাইতেও কাজ করতে পারে, আয়ারল্যান্ডেও।

কাজের ক্ষেত্রে এর মানে:

• identity সামলাতে হয় account প্রতি একবার, Region প্রতি না।
• কিন্তু identity যেসব resource ব্যবহার করে, সেগুলো regional-ই থাকে। policy চাইলে নির্দিষ্ট Region-এর resource-এর কথা বলতে পারে, আর aws:RequestedRegion condition key দিয়ে কোনো user কোন Region-এ কাজ করতে পারবে তা বেঁধে দেওয়া যায়।
• IAM eventually consistent। তুমি যে বদল করো (নতুন user, বদলানো policy), সেটা এক জায়গায় জমা হয়ে সারা পৃথিবীতে ছড়ায়, তাই সব Region-এ পৌঁছাতে একটু সময় লাগতে পারে। application-এর জরুরি কাজের পথে IAM বদলানো রাখবে না; user আর policy আগেভাগে বানিয়ে রাখো।

#account-এর ভেতরের identity-গুলো

IAM-এ কয়েক রকম identity আছে। এই লেসনে প্রথম তিনটা; role-এর জন্য আলাদা লেসন।

#Root user

root user-এর account-এর সবকিছুতে পুরো অধিকার, billing আর account বন্ধ করাসহ, আর IAM policy দিয়ে তাকে বাঁধা যায় না। ঠিক এ কারণেই রোজকার কাজে root ব্যবহার করবে না: root-এর password একবার চুরি হলে account-টাই attacker-এর হয়ে যায়। নিজের জন্য একটা administrator বানাও, root-এর sign in শক্ত করে সুরক্ষিত করো, তারপর root-এর credential তুলে রাখো। root দিয়ে কী করবে আর কী করবে না, সেটা lesson 2.3-এ।

#IAM user

IAM user হলো তোমার account-এর ভেতরে একটা স্থায়ী identity। তার থাকে:

• একটা নাম, account-এ অনন্য, বড়-ছোট হাতের অক্ষরে পার্থক্য ধরে না (Alice আর alice দুটো একসাথে রাখা যায় না), সর্বোচ্চ ৬৪ অক্ষর;
• একটা ARN, যেটা দিয়ে সব জায়গায় তাকে চেনা যায়, যেমন arn:aws:iam::111122223333:user/alice;
• চাইলে একটা console password, account-এর নিজস্ব sign in পাতায় ঢোকার জন্য (https://111122223333.signin.aws.amazon.com/console, বা তোমার পছন্দের একটা alias);
• চাইলে সর্বোচ্চ দুটো access key, CLI আর code-এর জন্য (lesson 1.3)। দুটো রাখা যায় যাতে নতুনটা বানিয়ে সবকিছু তাতে সরিয়ে তারপর পুরনোটা মুছে ফেলা যায়;
• অনুমতি: user-এর গায়ে সরাসরি লাগানো policy, আর তার group-গুলোর মাধ্যমে পাওয়া policy।

নতুন IAM user কোনো policy allow না করা পর্যন্ত কিছুই করতে পারে না। least privilege শুরু হয় এখান থেকেই।

password আর access key দুটোই দীর্ঘমেয়াদি credential: কেউ বদলে না দেওয়া বা মুছে না ফেলা পর্যন্ত চলতেই থাকে। দুর্বলতাও ওইখানে। AWS এখন পরামর্শ দেয়: মানুষকে ঢোকাও federation বা IAM Identity Center দিয়ে (তারা কোম্পানির নিজের identity system দিয়ে sign in করে আর অস্থায়ী credential পায়), আর workload-কে দাও IAM role। তবু IAM user এখনো খুব চলে, বিশেষ করে ছোট account-এ আর পরীক্ষায়, আর policy নিয়ে যা শিখছ তা সব identity-র বেলায় খাটে।

#IAM group

group দিয়ে অনেক user-এর অনুমতি একসাথে সামলানো যায়। group-এ policy লাগাও, তাতে user যোগ করো, সদস্যরা সবাই সেই অনুমতি পেয়ে যায়। কেউ operations টিমে এলে তাকে operations group-এ যোগ করো; চলে গেলে সরিয়ে দাও।

group-এর নিয়মগুলো:

• group-এ শুধু user থাকে, অন্য group কখনো না। একটার ভেতরে আরেকটা group রাখা যায় না: developers-কে engineering-এর ভেতরে রাখতে পারবে না।
• user-কে group-এ থাকতেই হবে, এমন না। user-এর গায়ে সরাসরি বা inline policy লাগানো যায়।
• একজন user কয়েকটা group-এ থাকতে পারে, সর্বোচ্চ ১০টা। তার অনুমতি হয় সবগুলো মিলিয়ে: তার group-গুলো আর তার নিজের policy যা যা allow করে, সব। কোনো group অন্যটার চেয়ে বেশি গুরুত্ব পায় না; দুটো policy উল্টো কথা বললে সিদ্ধান্ত নেয় lesson 2.2-এর evaluation logic (আর explicit deny জেতে)।
• group কোনো identity না। তার credential নেই, কেউ group হিসেবে sign in করে না, আর resource-based policy-র Principal-এ group-এর নাম দেওয়া যায় না।
• একটা account-এ default নিয়মে ৩০০টা group রাখা যায় (বাড়িয়ে ৫০০), আর ৫,০০০ জন user।

মানুষকে কাজ অনুযায়ী দলে ভাগ করে (developer, operations, auditor) অনুমতি দলকে দেওয়ার এই ধরনকে বলে role-based access control (RBAC)। আরও নমনীয় একটা ধরন আছে, যেখানে user আর resource-এর tag মিলিয়ে অনুমতি দেওয়া হয়: attribute-based access control (ABAC)। এর condition key-গুলো এই লেসনের পরের দিকে দেখবে।

#Principle of least privilege

Least privilege মানে: প্রতিটা identity-কে শুধু তার কাজের জন্য যতটুকু অনুমতি দরকার ততটুকুই দাও, এক চুলও বেশি না। IAM-এর best practice-গুলোর মধ্যে পরীক্ষায় এটাই সবচেয়ে বেশি আসে।

কেন এটা জরুরি:

• কিছু ফাঁস হলে ক্ষতি কম। একটা bucket পড়ার অনুমতিওয়ালা access key ফাঁস হলে attacker একটা bucket-ই পড়তে পারে। administrator-এর key ফাঁস হলে account-টাই তার।
• ভুল ছোট থাকে। bug-ওয়ালা একটা script এমন database মুছতে পারে না, যেটা ছোঁয়ার অনুমতিই তার ছিল না।
• audit সহজ হয়। “production-এর data কে কে মুছতে পারে?” এই প্রশ্নের উত্তর কয়েকটা ছোট policy পড়েই দেওয়া যায়।

কীভাবে মানবে:

1. শুরু করো শূন্য থেকে। নতুন identity-র কোনো অনুমতি থাকে না, আর শুরুটা এমনই হওয়া উচিত।
2. দাও নির্দিষ্ট action (s3:GetObject, s3:* না), নির্দিষ্ট resource-এ (একটা bucket, * না), আর যেখানে কাজে লাগে সেখানে condition (শুধু অফিসের নেটওয়ার্ক থেকে, একটা Region-এ)।
3. project নতুন অবস্থায় একটু চওড়া অনুমতি দিয়ে শুরু করা দোষের না, যেমন একটা AWS managed policy দিয়ে। তারপর টাইট করো: identity-টা আসলে কী কী ব্যবহার করেছে দেখো (IAM Access Advisor কোন service শেষ কবে ব্যবহার হয়েছে দেখায়, lesson 2.4), বাকিটা সরিয়ে দাও।
4. নিয়মিত দেখো। মানুষের কাজ বদলায়; অনুমতিও সেই সাথে বদলানো উচিত।

#Policy: কী জিনিস, আর তিন রকম policy

policy হলো একটা JSON document, যাতে অনুমতির তালিকা থাকে। policy কোনো identity-র (user, group বা role) গায়ে লাগানো থাকলে সেটা identity-based policy: সেটা বলে ওই identity কী করতে পারবে। identity-based policy তিন রকম:

কয়েকটা AWS managed policy, যেগুলোর সাথে দেখা হবে:

• AdministratorAccess: সব resource-এ সব action। শুধু administrator-দের জন্য।
• PowerUserAccess: IAM user, group আর Organizations সামলানো বাদে বাকি সব। sandbox account-এ developer-দের প্রায়ই এটা দেওয়া হয়।
• ReadOnlyAccess: সব পড়া যায়, ভেতরের data-সহ, যেমন S3 object।
• ViewOnlyAccess: resource-এর তালিকা আর বিবরণ দেখা যায়, ভেতরের data পড়া যায় না। একজন auditor-এর যা লাগে, এটা তার কাছাকাছি।
• service-ভিত্তিক policy, যেমন AmazonS3ReadOnlyAccess, আর job-function policy, যেমন DatabaseAdministrator আর SecurityAudit।

AWS managed policy হাতের কাছে পাওয়া যায় ঠিকই, কিন্তু চওড়া, আর AWS এগুলো বদলাতেও পারে। এগুলোতে resource থাকে *, তাই একা এগুলো দিয়ে least privilege খুব কমই মেলে। সাধারণ পথ: AWS managed policy দিয়ে শুরু করো, তারপর সেটা সরিয়ে তোমার resource-এর জন্য লেখা একটা customer managed policy বসাও।

যে সীমাগুলো জেনে রাখা ভালো: একজন user-এ ১০টা managed policy লাগানো যায় (বাড়িয়ে ২০), একটা group-এ ১০টা, একটা role-এ ২০টা (বাড়িয়ে ২৫)। একটা customer managed policy সর্বোচ্চ ৬,১৪৪ অক্ষরের; একজন user-এর সব inline policy মিলিয়ে সর্বোচ্চ ২,০৪৮ অক্ষর (group ৫,১২০, role ১০,২৪০)। ফাঁকা জায়গা গোনা হয় না।

#একটা JSON policy-র ভেতরটা

এই হলো একটা পুরো identity-based policy। এটা যার গায়ে লাগানো, সে একটা bucket-এর তালিকা দেখতে পারবে আর তার ভেতরের object পড়তে-লিখতে পারবে, কিন্তু শুধু অফিসের নেটওয়ার্ক থেকে:

{
  "Version": "2012-10-17",
  "Id": "reports-team-access",
  "Statement": [
    {
      "Sid": "ListTheBucket",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::example-reports"
    },
    {
      "Sid": "ReadWriteObjectsFromOffice",
      "Effect": "Allow",
      "Action": ["s3:GetObject", "s3:PutObject"],
      "Resource": "arn:aws:s3:::example-reports/*",
      "Condition": {
        "IpAddress": { "aws:SourceIp": "203.0.113.0/24" }
      }
    }
  ]
}

ওপর থেকে নিচে অংশগুলো:

#Version: ভাষার version, তোমার edit-এর নম্বর না

"2012-10-17" হলো IAM policy ভাষার এখনকার version। পুরনো "2008-10-17" এখনো আছে, পুরনো জিনিস চালু রাখার জন্য। Version না লিখলে AWS ধরে নেয় policy-টা পুরনো ভাষায় লেখা, আর নতুন সুবিধাগুলো চুপচাপ কাজ করা বন্ধ করে দেয়। সবচেয়ে পরিচিত উদাহরণ: ${aws:username}-এর মতো policy variable বদলায় না, ফলে arn:aws:s3:::home/${aws:username}/* প্রত্যেক user-এর নিজের folder না ধরে হুবহু ওই লেখাটাই খোঁজে। সবসময় লিখবে "Version": "2012-10-17", আর কখনো আজকের তারিখ বসাবে না।

#Effect

প্রতিটা statement হয় allow করে, নয়তো deny। বেশির ভাগ policy কয়েকটা Allow statement-এর তালিকা। Deny statement বসানো হয় বেড়া হিসেবে (“এই bucket কখনো মোছা যাবে না”, “এই কয়টা Region-এর বাইরে কাজ চলবে না”)। default নিয়মটা মনে রাখো: যা allow করা হয়নি, তা এমনিতেই deny। explicit deny কেন সবসময় allow-কে হারায়, সেটা lesson 2.2-এ।

#Action: service prefix, নাম, wildcard

action লেখা হয় service:Operation আকারে: s3:GetObject, ec2:StartInstances, iam:CreateUser, dynamodb:Query। prefix হলো service-এর ছোট নাম, আর নামটা একটা API operation-এর সাথে মেলে।

• কয়েকটা action-এর তালিকা দেওয়া যায়: ["s3:GetObject", "s3:PutObject"]।
• wildcard: * যত খুশি অক্ষরের সাথে মেলে, ? ঠিক একটা অক্ষরের সাথে। s3:* মানে S3-এর সব action; ec2:Describe* মানে EC2-এর সব শুধু-দেখার “describe” call; শুধু "*" মানে সব service-এর সব action।
• action-এর নামে বড়-ছোট হাতের অক্ষরের পার্থক্য ধরা হয় না, তবু documentation-এ যেভাবে লেখা সেভাবেই লেখো।
• বানান ভুল action (s3:GetObjects) চলার সময় কোনো error দেয় না। সেটা স্রেফ কিছুর সাথেই মেলে না, ফলে request deny হয়। নিচের policy editor-এর validation এটা ধরিয়ে দেয়।

wildcard খুব শক্তিশালী, আবার বিপজ্জনকও। আজকের s3:Get* আগামী বছর AWS যেসব নতুন action আনবে সেগুলোও ধরে নেবে। স্পর্শকাতর যেকোনো কিছুতে স্পষ্ট তালিকা দেওয়াই ভালো।

#NotAction: এগুলো বাদে বাকি সব

NotAction ধরে তালিকার action-গুলো বাদে বাকি সব action। এটা deny না; কী করবে তা নির্ভর করে Effect-এর ওপর:

• Allow + NotAction: তালিকার action বাদে সবকিছু allow করে। "Effect": "Allow", "NotAction": "iam:*", "Resource": "*" দিলে IAM বাদে সব service-এ ঢোকা যায়, AWS ভবিষ্যতে যত নতুন service আনবে সেগুলোসহ। খুব চওড়া; জেনেবুঝে ব্যবহার করবে।
• Deny + NotAction: তালিকার action বাদে সবকিছু deny করে। একটা পরিচিত বেড়া: দুটো Region-এর বাইরে সব action deny, তবে global service-গুলো (IAM, Organizations, CloudFront, Route 53…) বাদ দিয়ে, কারণ সেগুলো সবসময় us-east-1-এ call হয়।

NotAction তালিকার action-গুলো কখনো allow-ও করে না, deny-ও করে না; ওই statement সেগুলো নিয়ে কিছু বলেই না। NotResource আর NotPrincipal নিজেদের অংশে একইভাবে কাজ করে, আর খুব কমই সেগুলো সঠিক হাতিয়ার।

#Resource আর ARN

Amazon Resource Name (ARN) পুরো AWS জুড়ে একটা resource-কে অনন্যভাবে চেনায়:

arn:partition:service:region:account-id:resource

• partition: সাধারণ Region-এর জন্য aws (চীনের জন্য aws-cn, আমেরিকার সরকারি Region-গুলোর জন্য aws-us-gov);
• service: s3, ec2, iam, dynamodb…;
• region: global resource-এর বেলায় ফাঁকা;
• account-id: ১২ অঙ্কের account নম্বর; যেখানে লাগে না সেখানে ফাঁকা;
• resource: ধরন আর নাম বা ID, ওই service যেভাবে ঠিক করে দিয়েছে।

আসল উদাহরণ:

Resource-এ একটা ARN দেওয়া যায়, একটা তালিকা দেওয়া যায়, wildcard-ও দেওয়া যায় (arn:aws:s3:::example-*)। "Resource": "*" মানে সব resource।

কিছু action কোনো নির্দিষ্ট resource-এর ওপর কাজই করে না, তাই সেখানে "Resource": "*" দিতেই হয়। বেশির ভাগ list আর describe call এমন: ec2:DescribeInstances একটা Region-এর সব instance-এর তালিকা দেয়, তাই নির্দিষ্ট কোনো instance-এর ARN লেখার উপায় নেই। প্রতিটা action কোন resource আর কোন condition key সমর্থন করে, তা লেখা আছে Service Authorization Reference-এ।

#Condition: statement কখন খাটবে

Condition block একটা statement-কে নির্দিষ্ট পরিস্থিতিতে বেঁধে দেয়। এর গঠন সবসময় operator → key → মান:

"Condition": {
  "StringEquals": { "aws:RequestedRegion": ["eu-west-1", "ap-south-1"] },
  "IpAddress": { "aws:SourceIp": "203.0.113.0/24" }
}

• Operator তুলনা করে: StringEquals, StringLike (* আর ? সহ), StringNotEquals, NumericLessThan, DateGreaterThan, Bool, IpAddress আর NotIpAddress, ArnLike। শেষে IfExists জুড়লে (StringEqualsIfExists) মানে দাঁড়ায় “key-টা না থাকলে মিলেছে বলে ধরো”।
• Key হলো request context-এর তথ্য। global key শুরু হয় aws: দিয়ে; service-এর নিজের key শুরু হয় service prefix দিয়ে, যেমন s3:prefix বা ec2:InstanceType।
• যুক্তি: block-এর প্রতিটা operator আর প্রতিটা key মিলতে হবে (এবং); একটা key-এর কয়েকটা মান মানে যেকোনো একটা মিললেই চলবে (অথবা)। ওপরের উদাহরণ মেলে তখন, যখন request দুই Region-এর যেকোনোটায় যাচ্ছে এবং অফিসের range থেকে আসছে।

যে global key-গুলো প্রায়ই লাগবে:

aws:SourceIp-এর দুটো ফাঁদ: VPC endpoint দিয়ে AWS-এ পৌঁছানো request-এ থাকে private address, তাই aws:SourceIp তার সাথে মেলে না (তখন লাগবে aws:SourceVpce বা aws:VpcSourceIp); আর কোনো AWS service (ধরো একটা deployment tool) তোমার হয়ে অন্য service-কে call করলে source address হয় AWS-এর, তোমার না, তাই কড়া IP নিয়ম তাকে ভেঙে দিতে পারে (এই অবস্থা সামলায় aws:ViaAWSService)।

#Identity-based আর resource-based policy

এতক্ষণ সব policy ছিল কোনো identity-র গায়ে লাগানো। কিছু service-এ policy খোদ resource-এর গায়েও লাগানো যায়: S3 bucket policy, SQS queue policy, SNS topic policy, KMS key policy, Lambda function-এর resource policy, আর IAM role-এর trust policy। এগুলোকে বলে resource-based policy, আর এগুলো সবসময় ওই একটা resource-এর ভেতরে inline থাকে।

একটা bucket policy, যেটা অন্য account-এর একজন user-কে bucket পড়তে দেয়:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "PartnerCanRead",
      "Effect": "Allow",
      "Principal": { "AWS": "arn:aws:iam::444455556666:user/partner-app" },
      "Action": ["s3:GetObject"],
      "Resource": "arn:aws:s3:::example-reports/*"
    }
  ]
}

দুটো একসাথে কীভাবে কাজ করে (পুরো ছবি lesson 2.2-এ):

• একই account-এর ভেতরে যেকোনো একটা হলেই চলে: user-এর identity policy allow করলে, অথবা bucket policy ওই user-কে allow করলে request পাস (যদি না কেউ deny করে)। দুটো ব্যতিক্রম মনে রাখো: KMS key policy আর role-এর trust policy-কে নিজেকেই অনুমতি দিতে হয়।
• দুই account জুড়ে লাগে দুটোই: অন্য account-এর identity policy-কে তার user-কে তোমার bucket-এ call করার অনুমতি দিতে হবে, আর তোমার bucket policy-কে ওই user-কে allow করতে হবে। প্রতিটা account নিজের দিকটা নিজে সামলায়।
• "Principal": "*" মানে যে কেউ, internet-এর নাম-পরিচয়হীন মানুষসহ। bucket policy-তে এটা দিলে data public হয়ে যায়, আর এ কারণেই S3 Block Public Access আছে, default-এ চালুও থাকে।

#ধাপে ধাপে একটা policy বানানো

একটা বাস্তব চাহিদা: “analytics app-টা চলে IAM user report-builder হিসেবে। bucket example-reports-এর input/-এর নিচের গত মাসের input file পড়তে হবে, তৈরি report লিখতে হবে output/-এর নিচে, আর তালিকা দেখতে পারবে শুধু এই দুই folder-এর। কিছু মোছা চলবে না। app চলে অফিসের নেটওয়ার্ক 203.0.113.0/24 থেকে।”

1. action-গুলো লিখে ফেলো

   file পড়া মানে s3:GetObject, লেখা মানে s3:PutObject, তালিকা দেখা মানে s3:ListBucket। মোছা হলো s3:DeleteObject, ওটা আমরা স্রেফ বাদ দিই: যা allow করা হয়নি, তা এমনিতেই deny।

2. প্রতিটা action-এর সাথে তার resource মেলাও

   GetObject যাবে arn:aws:s3:::example-reports/input/*-এ। PutObject যাবে arn:aws:s3:::example-reports/output/*-এ। ListBucket যাবে খোদ bucket-এ, arn:aws:s3:::example-reports। তিনটা আলাদা resource, তাই তিনটা statement।

3. তালিকা দেখাটা সরু করো

   ListBucket পুরো bucket-এর ওপর কাজ করে, তাই কোন folder-গুলো দেখা যাবে সেটা বেঁধে দাও S3-এর condition key s3:prefix দিয়ে।

4. নেটওয়ার্কের condition যোগ করো

   প্রতিটা statement-এ aws:SourceIp সহ IpAddress বসাও। (app কখনো VPC-তে সরে গিয়ে gateway endpoint দিয়ে S3-এ গেলে এই key আর মিলবে না; তখন aws:SourceVpce-তে চলে যাও।)

5. যাচাই করো, test করো, তারপর লাগাও

   policy-টা IAM policy editor-এ বসাও, validation-এর findings পড়ো, policy simulator-এ test করো, তারপরই কেবল report-builder-s3 নামে customer managed policy হিসেবে save করে লাগাও।

ফলাফল:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "ReadInput",
      "Effect": "Allow",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::example-reports/input/*",
      "Condition": { "IpAddress": { "aws:SourceIp": "203.0.113.0/24" } }
    },
    {
      "Sid": "WriteOutput",
      "Effect": "Allow",
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::example-reports/output/*",
      "Condition": { "IpAddress": { "aws:SourceIp": "203.0.113.0/24" } }
    },
    {
      "Sid": "ListOnlyTheTwoFolders",
      "Effect": "Allow",
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::example-reports",
      "Condition": {
        "StringLike": { "s3:prefix": ["input/*", "output/*"] },
        "IpAddress": { "aws:SourceIp": "203.0.113.0/24" }
      }
    }
  ]
}

প্রতিটা statement একটা বাক্যে পড়ে দেখো: “অফিস থেকে input-এর নিচের object পড়তে দাও”; “অফিস থেকে output-এর নিচে object লিখতে দাও”; “অফিস থেকে bucket-এর তালিকা দেখতে দাও, শুধু এই দুই prefix-এর জন্য”। কোনো statement একটা পরিষ্কার বাক্যে পড়া না গেলে, সম্ভবত সেটাতেই গলদ আছে।

#policy-তে যেখানে গোলমাল হয়

#ভরসা করার আগে policy যাচাই

যাচাই না করে কখনো policy লাগাবে না। তিনটা tool সাহায্য করে, সবগুলো বিনা পয়সায়:

• IAM Access Analyzer policy validation। console-এর policy editor-এ নিজে থেকেই চলে, আর access-analyzer validate-policy API দিয়েও চালানো যায়। এটা policy-কে একশোরও বেশি নিয়মের সাথে মিলিয়ে দেখে, আর জানায় error (policy কাজই করবে না: অচল action, ARN-এর গঠন ভুল), security warning (দেখতে যা মনে হয় তার চেয়ে বেশি অনুমতি দেয়, যেমন Allow-এর সাথে NotAction), warning (ভাষার নিয়ম ঠিকঠাক মানেনি) আর suggestion (আরও পরিষ্কার করে লেখার উপায়)।
• Access Analyzer-এর custom policy check একটা বদল নিয়ে নির্দিষ্ট প্রশ্নের উত্তর দেয়, যেমন “নতুন version কি এমন কোনো অনুমতি দেয় যা পুরনোটা দিত না?”, আর deployment pipeline-এর ভেতরেও চালানো যায়।
• IAM policy simulator (https://policysim.aws.amazon.com, বা aws iam simulate-principal-policy) প্রশ্ন করে: “এই user এই resource-এ এই action call করলে, এই context-এ, allow হতো কি, আর কোন statement সিদ্ধান্ত দিল?” আসল call না করেই সত্যিকারের policy-গুলো বিচার করে, তাই DeleteObject নিরাপদে test করা যায়।

identity-টা আসলে যে action-গুলো ব্যবহার করেছে, তা দেখে Access Analyzer একটা শুরুর policy বানিয়েও দিতে পারে, আর অব্যবহৃত অনুমতি দেখাতে পারে। এগুলো, সাথে credentials report আর Access Advisor, আসবে lesson 2.4-এ।

#system design-এ কীভাবে কাজে লাগে

এই লেসন থেকে পরীক্ষার ধাঁচ:

• “কয়েকজন user-এর একই অনুমতি লাগবে; সবচেয়ে কম ঝামেলায়” → তাদের একটা group-এ রাখো আর policy লাগাও group-এ।
• “user-কে অনুমতি দাও, কিন্তু least privilege মেনে” → নির্দিষ্ট action আর resource-ওয়ালা একটা customer managed policy, AdministratorAccess না।
• “policy-টা যেন শুধু এই একজন user-ই পায় আর তার সাথেই মুছে যায়” → একটা inline policy।
• “অনেক group-এ লাগানো একটা policy-র ভুল বদল ফিরিয়ে আনো” → customer managed policy-র আগের version-কে default করো।
• “শুধু কোম্পানির IP range থেকে ঢুকতে দাও” → IpAddress আর aws:SourceIp দিয়ে Condition।
• “আরেকটা account-কে আমাদের S3 bucket-এ ঢুকতে হবে” → একটা bucket policy (resource-based, Principal সহ)।

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

administrator হিসেবে AWS CLI সেট করা থাকলে (lesson 1.3), একটা test account-এ:

# Create a group and a user, and put the user in the group
aws iam create-group --group-name reports-team
aws iam create-user --user-name report-builder
aws iam add-user-to-group --group-name reports-team --user-name report-builder

# Validate the policy from this lesson before using it
aws accessanalyzer validate-policy \
  --policy-type IDENTITY_POLICY \
  --policy-document file://report-builder-s3.json

# Save it as a customer managed policy and attach it to the group
aws iam create-policy --policy-name report-builder-s3 \
  --policy-document file://report-builder-s3.json
aws iam attach-group-policy --group-name reports-team \
  --policy-arn arn:aws:iam::111122223333:policy/report-builder-s3

# Ask the simulator: may this user delete an object? (expect implicitDeny)
aws iam simulate-principal-policy \
  --policy-source-arn arn:aws:iam::111122223333:user/report-builder \
  --action-names s3:DeleteObject s3:GetObject \
  --resource-arns arn:aws:s3:::example-reports/input/jan.csv

# See everything that applies to the user: direct, inline and through groups
aws iam list-groups-for-user --user-name report-builder
aws iam list-attached-user-policies --user-name report-builder
aws iam list-user-policies --user-name report-builder

তারপর ইচ্ছে করে ভুলগুলো করে দেখো: s3:GetObject-কে s3:GetObjects বানিয়ে validation-এর ফল পড়ো; bucket ARN-এর statement-টা সরিয়ে ওই user হিসেবে aws s3 ls s3://example-reports/ চালাও। কাজ শেষে delete-user, delete-group আর delete-policy দিয়ে পরিষ্কার করো (আগে detach করে group থেকে সরিয়ে নিতে হবে)।

#সারসংক্ষেপ

মূল কথাগুলো

• প্রতিটা request-এ IAM দুটো প্রশ্নের উত্তর দেয়: authentication (তুমি কে?) আর authorization (তুমি কি এটা করতে পারবে?)। কোনো policy allow না করা পর্যন্ত default উত্তর না।
• IAM global: user, group, role আর policy সব Region-এ থাকে; তারা যে resource ব্যবহার করে সেগুলো regional। IAM বিনা পয়সায়, আর eventually consistent।
• root user-এর ক্ষমতার কোনো সীমা নেই; রোজকার কাজে কখনো না (lesson 2.3)। IAM user-এর credential দীর্ঘমেয়াদি: একটা password আর/বা সর্বোচ্চ দুটো access key। group-এ থাকে শুধু user, group-এর ভেতরে group রাখা যায় না, group কোনো principal না, আর একজন user সর্বোচ্চ ১০টা group-এ; user-এর অনুমতি হয় সবগুলো মিলিয়ে।
• Least privilege: নির্দিষ্ট action, নির্দিষ্ট resource, দরকার হলে condition; সরু দিয়ে শুরু করো, সময়ের সাথে আরও টাইট করো।
• identity-based policy হয় AWS managed (হাতের কাছে, চওড়া, edit করা যায় না), customer managed (তোমার নিজের, বারবার ব্যবহার করা যায়, ৫টা পর্যন্ত version আর rollback) অথবা inline (এক-জনের-সাথে-এক, identity-র সাথেই মুছে যায়)।
• policy-তে থাকে Version (সবসময় 2012-10-17), ঐচ্ছিক Id, আর Statement, যাতে ঐচ্ছিক Sid, Effect, Action/NotAction, Resource/NotResource, ঐচ্ছিক Condition; আর Principal শুধু resource-based policy-তে।
• ARN: arn:partition:service:region:account:resource। IAM-এর ARN-এ Region নেই; S3-এর ARN-এ Region-ও নেই, account-ও নেই; bucket (bucket) আর তার object (bucket/*) আলাদা resource।
• Condition: operator → key → মান; আলাদা key-গুলোকে সব মিলতে হয়, একটা key-এর কয়েকটা মানের যেকোনো একটা মিললেই চলে। aws:SourceIp, aws:RequestedRegion, ABAC-এর জন্য tag।
• resource-based policy (bucket, queue, key, trust policy) Principal-এর নাম লেখে আর অন্য account-কে ঢুকতে দিতে পারে; দুই account জুড়ে হলে দুই পক্ষকেই allow করতে হয়।
• লাগানোর আগে policy যাচাই করো Access Analyzer validation আর policy simulator দিয়ে।

নিজেকে যাচাই করো: user, group আর policy৩৬টি প্রশ্ন