Role, STS ও IAM Security Tool

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

• বুঝিয়ে বলতে পারবে role কেন দরকার: long-term key ছাড়াই permission, যেটা AWS STS অস্থায়ী credential হিসেবে দেয়।
• একটা role-এর দুটো policy পড়তে আর লিখতে পারবে: trust policy (কে assume করতে পারবে) আর permission policy (assume করার পর কী করতে পারবে)।
• একটা AssumeRole call ধাপে ধাপে বুঝতে পারবে, আর চারটা চেনা ভুল ধরতে পারবে: caller-কে বিশ্বাস করা হয়নি, caller-এর অনুমতি নেই, token-এর মেয়াদ শেষ, role chaining-এ এক ঘণ্টার বেশি চাওয়া।
• instance profile, service role আর service-linked role দিয়ে EC2, Lambda আর অন্য service-কে permission দিতে পারবে।
• external ID আর MFA condition দিয়ে এক account থেকে আরেক account-এ নিরাপদ access বানাতে পারবে, আর জানবে federation আর IAM Identity Center কোথায় বসে।
• একটা access key ফাঁস হলে কী করতে হয় জানবে, আর Credentials Report, Access Advisor আর IAM Access Analyzer দিয়ে একটা account যাচাই করতে পারবে।

#long-term key-এর ঝামেলা

লেসন ২.১ থেকে ২.৩ পর্যন্ত প্রতিটা identity ছিল একজন IAM user: একজন মানুষ, যার একটা password আছে, আর CLI বা SDK-র জন্য একটা access key (একটা access key ID আর একটা secret access key, লেসন ১.৩)। এই key-গুলো long-term: যতদিন না কেউ বন্ধ করছে, ততদিন পৃথিবীর যেকোনো জায়গা থেকে, দিনে-রাতে, এগুলো চলতেই থাকে।

একজন engineer নিজের laptop-এ কাজ করলে এতে সমস্যা নেই। কিন্তু একটু বড় হলেই ব্যাপারটা ভেঙে পড়ে:

• EC2-এর একটা application-কে S3 পড়তে হবে। key যদি config file-এ, user data-য় বা code-এ রাখো, তাহলে যে-ই ওই file, image বা repository পড়তে পারবে, সে-ই key পড়ে ফেলবে। key-এর মেয়াদ কখনো ফুরায় না, তাই আজ চুরি হওয়া কপি আগামী বছরও কাজ করবে।
• একটা Lambda function-কে DynamoDB-তে লিখতে হবে। এখানে কোনো laptop নেই, কোনো মানুষও নেই; key-টা টাইপ করবে কে?
• অন্য একটা AWS account-এর এক সহকর্মীকে তোমার log দেখতে হবে। তোমার account-এ তার জন্য IAM user বানালে আরও একটা password আর key সামলাতে হবে, আর সে টিম বদলালে user-টা মুছতে কারও মনে থাকবে না।
• একটা কোম্পানির নিজস্ব directory-তে ২,০০০ কর্মী আছে। ২,০০০টা IAM user বানানো মানে নতুন কেউ এলে, কেউ বিভাগ বদলালে, কেউ চলে গেলে, প্রতিবার একই কাজ দুই জায়গায় করা।

চারটারই উত্তর একটা IAM role: এমন একটা identity, যার permission আছে, কিন্তু নিজের কোনো password বা access key নেই। বিশ্বস্ত কেউ বা কিছু role-টা assume করে, আর AWS STS (Security Token Service) ফেরত দেয় অস্থায়ী credential, যেগুলোর মেয়াদ নিজে থেকেই ফুরিয়ে যায়, ১৫ মিনিট থেকে কয়েক ঘণ্টার মধ্যে।

#role জিনিসটা কী

role-ও user-এর মতোই একটা IAM identity, তারও একটা ARN আছে, যেমন arn:aws:iam::111122223333:role/app-reader। তফাত হলো, role-টা তুমি কীভাবে হয়ে ওঠো।

#একটা role-এর দুটো policy

প্রতিটা role-এর দুই রকম policy থাকে, আর এই দুটো গুলিয়ে ফেলাই role নিয়ে সবচেয়ে বেশি হওয়া ভুল।

1. trust policy উত্তর দেয় কে এই role assume করতে পারবে। এটা role-এর গায়েই লাগানো একটা resource-based policy, আর role-এর একমাত্র জায়গা যেখানে Principal লেখা থাকে। এর action হলো sts:AssumeRole (federation-এর জন্য sts:AssumeRoleWithSAML, sts:AssumeRoleWithWebIdentity)।
2. permission policy উত্তর দেয় assume করার পর role কী কী করতে পারবে। এগুলো সাধারণ identity-based policy (managed বা inline), ঠিক লেসন ২.১-এ user-এর গায়ে যেমন লাগাতে, আর যাচাই হয় লেসন ২.২-এর একই নিয়মে।

একটা trust policy, যেটা EC2 service-কে role assume করতে দেয়:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": { "Service": "ec2.amazonaws.com" },
      "Action": "sts:AssumeRole"
    }
  ]
}

আর একটা permission policy, যেটা একটা bucket পড়তে দেয়:

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

trust policy-র Principal এগুলোর যেকোনোটা হতে পারে:

principal ARN-এ :root মানে root user না। এর মানে “এই account”, আর এভাবেই শেষ সিদ্ধান্তটা ওই account-এর নিজের IAM policy-র হাতে ছেড়ে দেওয়া হয়।

#ধাপে ধাপে AssumeRole

1. caller STS-এর কাছে চায়

   যার হাতে আগে থেকেই কোনো credential আছে (কোনো user-এর access key, অন্য কোনো role-এর session, EC2 service, federation-এর token), সে sts:AssumeRole call করে: সঙ্গে দেয় role ARN, একটা session name যেটা log-এ দেখা যাবে, আর চাইলে কতক্ষণের জন্য চায় সেটা।

2. STS দুই দিকই যাচাই করে

   request পাস হয় কেবল তখনই, যখন দুই দিকই হ্যাঁ বলে: role-এর trust policy-তে এই caller-এর নাম আছে (আর MFA বা external ID-র মতো condition থাকলে সেগুলোও মিলেছে), এবং caller-এর নিজের identity policy ওই role ARN-এ sts:AssumeRole করতে দেয়। caller আর role একই account-এ হলে, আর trust policy-তে caller-এর নাম হুবহু লেখা থাকলে, শুধু trust policy-ই যথেষ্ট; দুই account-এর মাঝে হলে দুটোই সবসময় লাগে।

3. STS অস্থায়ী credential ফেরত দেয়

   চারটা জিনিস আসে: একটা access key ID (শুরু হয় ASIA দিয়ে, যেখানে long-term key শুরু হয় AKIA দিয়ে), একটা secret access key, একটা session token, আর একটা মেয়াদ শেষের সময়। প্রতিটা request-এ তিনটা অংশই পাঠাতে হয়; token ছাড়া শুধু key দুটো কোনো কাজের না।

4. caller এখন role হিসেবে কাজ করে

   এই credential দিয়ে sign করা request-গুলো চলে arn:aws:sts::111122223333:assumed-role/app-reader/<session-name> হিসেবে। প্রতিটা request যাচাই হয় role-এর permission policy দিয়ে, caller-এর আগের policy দিয়ে না: role assume করা মানে session চলাকালীন নিজের permission ছেড়ে দেওয়া।

5. session নিজে থেকেই শেষ হয়

   মেয়াদ শেষ হলে ওই credential দিয়ে পাঠানো প্রতিটা request expired-token error পায়। caller শুধু আবার role assume করে নেয়। কাউকে কিছু rotate বা delete করতে হয় না।

#একটা session কতক্ষণ চলে

• request-এর DurationSeconds: ৯০০ সেকেন্ড (১৫ মিনিট) থেকে role-এর maximum পর্যন্ত। কিছু না বললে ১ ঘণ্টা।
• role-এর maximum session duration setting: ১ ঘণ্টা (default) থেকে ১২ ঘণ্টা পর্যন্ত। role যতটা দেয়, তার বেশি চাইলে error আসে; চুপচাপ কেটে দেওয়া হয় না।
• role chaining, মানে এমন credential দিয়ে role assume করা যেটা নিজেই আরেকটা role থেকে এসেছে, তার সীমা ১ ঘণ্টা, maximum যা-ই বলুক। chaining-এ এর বেশি চাইলে ব্যর্থ।
• instance profile আর Lambda নিজেদের মতো credential বদলায় (নিচে দেখবে), তাই সেখানে তোমাকে এটা সেট করতে হয় না।

#AssumeRole-এ কোথায় গোলমাল হয়

• caller-এর নাম trust policy-তে নেই। AssumeRole-এই access denied, role-এর permission যত বড়ই হোক। Principal ঠিক করো (বানানটাও দেখো: কোনো user-এর ARN principal হিসেবে লেখা থাকলে আর সেই user পরে মুছে গেলে, principal-টা একটা অচেনা ID হয়ে যায়, আর কারও সাথেই আর মেলে না)।
• caller-এর sts:AssumeRole call করার অনুমতি নেই। দুই account-এর মাঝে এটা খুব হয়: account B-র role account A-কে বিশ্বাস করে, কিন্তু account A-তে কাউকে সেটা assume করার অনুমতি দেওয়া হয়নি।
• session token-এর মেয়াদ শেষ। যে লম্বা script শুরুতে একবার role assume করেছিল, সেটা এক ঘণ্টা পরে ভাঙে। CLI বা SDK-কে একটা profile থেকে role assume করতে দাও (role_arn + source_profile): তারা নিজে থেকেই credential নতুন করে নেয়।
• role chaining-এ এক ঘণ্টার বেশি। যে job একটা role হিসেবে চলে আর তারপর দ্বিতীয় একটা role assume করে, সে দ্বিতীয়টায় এক ঘণ্টার বেশি পায় না।
• অস্থায়ী credential চুরি হয়েছে। মেয়াদ শেষ না হওয়া পর্যন্ত সেগুলো চলবে। অপেক্ষা করা না গেলে role-এ Revoke active sessions ব্যবহার করো: IAM একটা inline policy লাগিয়ে দেয়, যেটা ওই মুহূর্তের আগে দেওয়া সব session-কে সব কিছুতে deny করে (aws:TokenIssueTime), আর নতুন session-গুলো ঠিকঠাক চলে। role-এর permission policy বদলালেও সেটা চালু session-এ সঙ্গে সঙ্গে লাগে, কারণ প্রতিটা request-এ permission নতুন করে যাচাই হয়; credential-গুলো permission-এর কোনো ছবি তুলে রাখে না।

#AWS service-এর জন্য role

slide-এ সবচেয়ে চেনা role-গুলোর তালিকা আছে: EC2 instance role, Lambda function role আর CloudFormation-এর role। সবগুলোর পেছনে একটাই ভাবনা: একটা AWS service তোমার হয়ে কাজ করছে, তাই service-কে key না দিয়ে একটা role দাও।

#EC2: instance profile

IAM নিয়ে পরীক্ষার সবচেয়ে প্রিয় প্রশ্ন এটা: EC2-এর একটা application-কে S3 বা DynamoDB পড়তে হবে; নিরাপদ উপায় কী? উত্তর সবসময় instance-এ একটা IAM role লাগিয়ে দাও, কখনোই access key রেখো না।

EC2 role-টা সরাসরি লাগায় না। সে ব্যবহার করে একটা instance profile, ছোট একটা container, যার ভেতরে থাকে ঠিক একটা role, আর instance-এ আসলে এটাই লাগানো হয়:

• console-এ EC2-এর জন্য role বানালে একই নামের একটা instance profile নিজে থেকেই তৈরি হয়ে যায়, তাই দুটোকে এক জিনিস মনে হয়। CLI বা infrastructure as code দিয়ে কাজ করলে profile বানিয়ে তাতে role ঢোকানোর কাজটা তোমাকেই করতে হয়।
• একটা instance-এ সর্বোচ্চ একটা instance profile, আর একটা instance profile-এ একটা role। permission আরও লাগলে ওই role-এই policy যোগ করো।
• চালু instance-এও instance profile লাগানো, বদলানো বা সরানো যায়; restart লাগে না।

credential কীভাবে application-এর কাছে পৌঁছায় (metadata-র দিকটা লেসন ৪.৩-এ বিস্তারিত দেখেছ):

1. EC2 instance-এর হয়ে role assume করে, আর অস্থায়ী credential রেখে দেয় instance metadata service-এ, iam/security-credentials/<role-name>-এর নিচে।
2. AWS CLI আর প্রতিটা AWS SDK একটা নির্দিষ্ট ক্রমে credential খোঁজে (credential provider chain): command-line option, environment variable, shared ~/.aws/credentials আর ~/.aws/config file, container credential, আর সবশেষে instance profile।
3. মেয়াদ ফুরানোর আগেই AWS IMDS-এ credential নতুন করে দেয়, আর SDK নতুনগুলো তুলে নেয়। application কখনো কোনো key দেখে না, disk-এ চুরি করার মতো কিছুই থাকে না।

#service role আর role তুলে দেওয়া

service role হলো এমন একটা role, যেটা তুমি বানাও কোনো service-এর assume করার জন্য: যেমন Lambda execution role (বিশ্বস্ত principal lambda.amazonaws.com, আর permission হিসেবে CloudWatch-এ log লেখা, একটা DynamoDB table পড়া), বা এমন একটা role, যেটা দিয়ে CloudFormation একটা stack-এর resource বানায়।

কোনো service-এর হাতে role তুলে দেওয়াটাও একটা permission। profile দিয়ে instance launch করতে, বা execution role দিয়ে function বানাতে, ওই role-এ তোমার iam:PassRole লাগে। এই যাচাই না থাকলে, যে developer শুধু Lambda function বানাতে পারে, সে একটা function-এ administrator role লাগিয়ে তা দিয়ে যা খুশি code চালাতে পারত। তাই iam:PassRole সীমিত রাখো ঠিক যে role ARN-গুলো মানুষের সত্যিই লাগে, সেগুলোতে।

#service-linked role

service-linked role হলো এমন role, যেটার মালিক একটা service। তুমি service-টা ব্যবহার শুরু করলে সে নিজেই (সাধারণত নিজে থেকে) এটা বানিয়ে নেয়, যেমন AWSServiceRoleForAutoScaling বা AWSServiceRoleForElasticLoadBalancing।

• এর trust policy আর permission service আগে থেকেই ঠিক করে রেখেছে; তুমি বদলাতে পারো না।
• service আর এটা ব্যবহার না করলেই কেবল মুছতে পারবে (যেমন এর ওপর নির্ভর করা resource-গুলো মুছে ফেলার পর)।
• এটা থাকে /aws-service-role/ path-এর নিচে, তাই এক নজরেই চেনা যায়।

#এক account থেকে আরেক account-এ: cross-account role

যে কোম্পানির dev, prod আর security আলাদা account আছে (এটাই স্বাভাবিক ব্যবস্থা, অধ্যায় ২০), তাদের প্রতিটা account-এ একই মানুষদের জন্য IAM user বানানো উচিত না। বরং:

1. target account-এ (ধরো prod, 111122223333) একটা role বানাও ops-readonly, যার trust policy উৎস account-কে (444455556666) বিশ্বাস করে, আর permission শুধু পড়ার।
2. উৎস account-এ operations group-কে ওই role-এর ARN-এ sts:AssumeRole করার অনুমতি দাও।
3. engineer-রা শুধু একবার, উৎস account-এ sign in করেন, তারপর console-এ Switch role (বা role_arn দেওয়া CLI profile) দিয়ে অস্থায়ী credential-এ prod-এ কাজ করেন।

prod-এ প্রতিটা কাজ CloudTrail-এ লেখা থাকে assumed-role/ops-readonly/<session-name> হিসেবে, তাই কে কী করল সেটা তুমি তখনো জানো।

#role assume করতে MFA বাধ্যতামূলক

sensitive কোনো role-এর trust policy দাবি করতে পারে যে caller কিছুক্ষণ আগেই MFA দিয়ে sign in করেছে (লেসন ২.৩):

{
  "Effect": "Allow",
  "Principal": { "AWS": "arn:aws:iam::444455556666:root" },
  "Action": "sts:AssumeRole",
  "Condition": {
    "Bool": { "aws:MultiFactorAuthPresent": "true" },
    "NumericLessThan": { "aws:MultiFactorAuthAge": "3600" }
  }
}

যে caller শুধু একটা access key ব্যবহার করছে (session-এ কোনো MFA নেই), সে বাতিল হবে। CLI user assume-role-এ --serial-number আর --token-code দিয়ে, বা CLI profile-এ mfa_serial সেট করে, শর্তটা পূরণ করতে পারে।

#third party আর external ID

কোনো monitoring বা খরচ-বিশ্লেষণের vendor প্রায়ই বলে, এমন একটা role বানাও যেটা সে নিজের AWS account থেকে assume করবে। বিপদটার নাম confused deputy: vendor শত শত customer-এর role assume করে, তাই অন্য কোনো customer vendor-এর web form-এ তোমার role ARN বসিয়ে দিয়ে vendor-কে দিয়ে তোমার account পড়িয়ে নিতে পারে।

সমাধান একটা external ID: vendor তোমাকে একটা অনন্য মান দেয়, আর তোমার trust policy সেটা চায়:

"Condition": { "StringEquals": { "sts:ExternalId": "vendor-7f3a91c2" } }

vendor সবসময় যে customer-এর হয়ে কাজ করছে, তার external ID-টাই পাঠায়। অন্য কারও জন্য পাঠানো request-এ থাকে অন্য মান, তাই বাতিল হয়। external ID কোনো password না (vendor তো এটা জানেই); এর কাজ শুধু প্রতিটা role-কে ঠিক customer-এর সাথে বেঁধে রাখা।

#এক পাতায় federation

Federation মানে মানুষ (বা workload) অন্য জায়গায় তাদের যে identity আগে থেকেই আছে, সেটাই রাখে, আর AWS সেই identity provider-কে (IdP) বিশ্বাস করে যে সে ঠিক মানুষটার হয়েই কথা বলছে। তারা কখনো IAM user পায় না: IdP-তে sign in করার পর তারা একটা role assume করে। note-এর কথাটা খাঁটি: প্রতিটা federated login-এর পেছনে একটা role আছে।

Microsoft Active Directory নিজে SAML বলে না; বলে তার সামনে বসানো কোনো IdP (ADFS, Entra ID)। Identity Center, Cognito আর directory service-এর পুরো গল্প অধ্যায় ২০-এ।

#ফাঁস হওয়া আর code-এ বসানো key

note-এ কথাটা সোজাসুজি বলা আছে: প্রশ্নে যদি দেখো কোনো developer source code-এ access key hardcode করেছে বা GitHub-এ push করে দিয়েছে, তাহলে উত্তর সবসময় ওই key-গুলো rotate করা (deactivate করে delete), আর EC2 বা Lambda-য় চলা code-এর জন্য IAM role ব্যবহার করা।

তাড়াটা কেন: bot-রা সারাক্ষণ public repository scan করে, আর নতুন একটা AWS key পেলে কয়েক মিনিটের মধ্যেই ব্যবহার শুরু করে, সাধারণত cryptocurrency mining-এর জন্য দামি instance চালিয়ে। AWS-ও public GitHub scan করে; তোমার কোনো key পেলে সে তোমাকে email করে, একটা support case খোলে, আর user-এর গায়ে একটা quarantine policy (AWSCompromisedKeyQuarantine…) লাগিয়ে দেয়, যেটা সবচেয়ে বেশি অপব্যবহার হওয়া action-গুলো deny করে। এতে ক্ষতি কমে; সমস্যার সমাধান হয় না।

কী করবে, এই ক্রমে:

1. Deactivate করো key-টা, এখনই (deactivate আবার ফেরানো যায়, তাই delete-এর আগে এটাই করো)।
2. খুঁজে বের করো সে কী করেছে: CloudTrail event history-তে key-এর ID দিয়ে খোঁজো; প্রতিটা Region-এ নতুন user, role, key, instance, আর billing-এ কোনো বদল খোঁজো।
3. ক্ষতি ফেরাও: attacker যা বানিয়েছে সব মুছে ফেলো, ফিরে আসার রাস্তা হিসেবে বানানো বাড়তি access key আর user-সহ।
4. ঠিকভাবে বদলাও: AWS-এ চলা code-এর জন্য IAM role, মানুষের জন্য Identity Center বা role; আর long-term key যদি একেবারেই এড়ানো না যায়, তবে নতুন key রাখো secrets store-এ, code-এ কখনো না।
5. Delete করো পুরনো key, আর repository-র history থেকেও সরিয়ে ফেলো (শেষ commit মুছলেই চলবে না)।

#downtime ছাড়া key rotate করা

একটা IAM user-এর দুটো access key থাকতে পারে, ঠিক এই কারণেই, যাতে কোনো বিভ্রাট ছাড়া rotate করা যায়: দ্বিতীয় key বানাও, সব জায়গায় বসাও, last used দেখে নিশ্চিত হও পুরনো key আর কেউ ব্যবহার করছে না, পুরনোটা deactivate করো, কিছুদিন অপেক্ষা করো, তারপর মুছে ফেলো।

#IAM যাচাইয়ের তিনটা tool

note-এ একটা চতুর জোড়ার কথা আলাদা করে বলা আছে: Credentials Report আর Access Advisor। সাথে IAM Access Analyzer যোগ করলে পুরো টুলবক্স হাতে চলে আসে।

note-এর পরীক্ষার কৌশল: “least privilege প্রয়োগ করতে অব্যবহৃত permission কীভাবে খুঁজে সরাবে?” → IAM Access Advisor (last accessed তথ্য)। সব user-এর credential-এর compliance audit → Credentials Report। বাইরের account-এর সাথে share করা resource → IAM Access Analyzer।

#এই অধ্যায়ের IAM best practice

slide-এর checklist, আজ AWS যা সুপারিশ করে তা মিলিয়ে:

• root user ব্যবহার করবে না, শুধু যে কয়েকটা কাজে ওটা লাগেই সেগুলো ছাড়া (লেসন ২.৩)। এতে MFA চালু রাখো, আর root-এর কোনো access key রেখো না।
• মানুষ পাবে অস্থায়ী credential: IAM user-এর বদলে IAM Identity Center বা federation-কে প্রাধান্য দাও। যেখানে IAM user থেকেই যায়, সেখানে একজন মানুষ = একটা user, কখনো ভাগাভাগি না।
• workload পাবে role: instance profile, Lambda execution role, task role, CI-র জন্য OIDC। long-term access key কেবল তখনই, যখন আর কিছুতেই কাজ চলে না, আর তখনো নিয়মিত rotate করে।
• permission দাও group-কে (user-দের জন্য) আর role-কে, একেকজন user-কে আলাদা করে না।
• least privilege: দরকার হলে AWS managed policy দিয়ে শুরু করো, তারপর Access Advisor আর Access Analyzer-এর বানানো policy দিয়ে সেটা ছেঁটে ছোট করো।
• শক্ত password policy, আর যারা sign in করে তাদের সবার জন্য MFA।
• বাড়তি নিরাপত্তার জন্য condition: sensitive role-এ MFA, third party-র জন্য external ID, iam:PassRole শুধু নির্দিষ্ট role-এ।
• নিয়মিত যাচাই করো Credentials Report, Access Advisor আর Access Analyzer দিয়ে; সব কিছু CloudTrail-এ log করো।
• কখনো ভাগাভাগি করবে না IAM user বা access key, আর code, image বা user data-য় কখনো key রাখবে না।

#design-এ সব কিছু কীভাবে মেলে

এই অধ্যায় শেষে একটা সাধারণ কোম্পানির ব্যবস্থা দেখতে এমন:

1. কর্মীরা sign in করেন IAM Identity Center দিয়ে, যেটা কোম্পানির directory-র সাথে জোড়া। প্রত্যেকে পান কয়েকটা permission set, যেগুলো dev, prod আর security account-এ role হিসেবে দেখা যায়।
2. prod-এর web server চলে একটা instance profile নিয়ে, যার role একটা S3 bucket আর একটা Secrets Manager secret পড়তে পারে; launch template IMDSv2 বাধ্যতামূলক রাখে (লেসন ৪.৩)।
3. প্রতিটা Lambda function-এর নিজের execution role, ঠিক যতটুকু সেই function-এর লাগে; developer-রা শুধু ওই role-গুলোই pass করতে পারে (ARN ধরে সীমিত iam:PassRole)।
4. deployment pipeline OIDC দিয়ে একটা deploy role assume করে; pipeline-এ কোনো key নেই।
5. খরচ দেখার একটা vendor external ID দিয়ে একটা শুধু-পড়ার cross-account role assume করে।
6. প্রতি মাসে security টিম Credentials Report দেখে, Access Advisor দিয়ে role-গুলো ছাঁটে, আর Access Analyzer-এর finding ধরে কাজ করে।

এই পুরো ছবিতে কোথাও কোনো long-term key নেই, তাই ফাঁস হওয়ার মতোও কিছু নেই।

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

# 1. এই মুহূর্তে আমি কে? (অন্য কোনো permission না থাকলেও চলে)
aws sts get-caller-identity

# 2. EC2 assume করতে পারে এমন একটা role বানাও, S3-এ শুধু পড়ার অনুমতি দাও, আর instance profile-এ ঢোকাও
cat > trust-ec2.json <<'EOF'
{"Version":"2012-10-17","Statement":[{"Effect":"Allow",
 "Principal":{"Service":"ec2.amazonaws.com"},"Action":"sts:AssumeRole"}]}
EOF
aws iam create-role --role-name app-reader --assume-role-policy-document file://trust-ec2.json
aws iam attach-role-policy --role-name app-reader \
  --policy-arn arn:aws:iam::aws:policy/AmazonS3ReadOnlyAccess
aws iam create-instance-profile --instance-profile-name app-reader
aws iam add-role-to-instance-profile --instance-profile-name app-reader --role-name app-reader

# 3. চালু instance-এ লাগাও (restart ছাড়া), তারপর instance-এ গিয়ে দেখো সে কে
aws ec2 associate-iam-instance-profile --instance-id $ID --iam-instance-profile Name=app-reader
aws sts get-caller-identity     # instance-এ চালাও: ...:assumed-role/app-reader/i-0...

# 4. হাতে একটা role assume করো, আর অস্থায়ী credential-গুলো দেখো
aws sts assume-role --role-arn arn:aws:iam::111122223333:role/ops-readonly \
  --role-session-name alice-test --duration-seconds 900
# -> AccessKeyId (ASIA...), SecretAccessKey, SessionToken, Expiration

# 5. অথবা CLI-কেই assume আর নবায়ন করতে দাও: ~/.aws/config
# [profile prod-ro]
# role_arn = arn:aws:iam::111122223333:role/ops-readonly
# source_profile = default
# mfa_serial = arn:aws:iam::444455556666:mfa/alice
aws s3 ls --profile prod-ro

# 6. Credentials Report: তৈরি করো, তারপর CSV নামিয়ে decode করো
aws iam generate-credential-report
aws iam get-credential-report --query Content --output text | base64 -d > report.csv

# 7. Access Advisor: এই role কোন কোন service ব্যবহার করেছে, শেষ কবে?
JOB=$(aws iam generate-service-last-accessed-details \
  --arn arn:aws:iam::111122223333:role/app-reader --query JobId --output text)
aws iam get-service-last-accessed-details --job-id $JOB

# 8. key ফাঁস হয়েছে: আগে deactivate, তারপর দেখো সে কী করেছে
aws iam update-access-key --user-name ci-old --access-key-id AKIAEXAMPLE --status Inactive
aws cloudtrail lookup-events --lookup-attributes AttributeKey=AccessKeyId,AttributeValue=AKIAEXAMPLE

#সারসংক্ষেপ

মূল কথাগুলো

• IAM role এমন একটা identity, যার permission আছে কিন্তু কোনো long-term credential নেই। তার trust policy যাকে অনুমতি দেয়, সে role-টা assume করতে পারে আর STS থেকে পায় অস্থায়ী credential: access key ID (ASIA…), secret key, session token, মেয়াদ।
• Trust policy = কে assume করতে পারবে (Principal থাকে শুধু এখানেই)। Permission policy = session কী করতে পারবে। দুই account-এর মাঝে caller-এর নিজের account-এও sts:AssumeRole-এর অনুমতি লাগে।
• session চলে ১৫ মিনিট থেকে role-এর maximum পর্যন্ত (default ১ ঘণ্টা, সর্বোচ্চ ১২ ঘণ্টা); role chaining-এর সীমা ১ ঘণ্টা। মেয়াদ ফুরানো token ব্যর্থ হয়; আবার assume করো। Revoke active sessions চুরি যাওয়া session আগেভাগেই মেরে দেয়।
• EC2 permission পায় instance profile দিয়ে (একটা profile-এ একটা role); credential আসে IMDS থেকে, আর নিজে থেকেই বদলায়। ~/.aws/credentials বা environment variable-এ পড়ে থাকা পুরনো key role-কে টপকে যায়।
• Service role (Lambda execution role, CloudFormation-এর role) তুমি নিজে ঠিক করো; কোনো service-এর হাতে সেটা দিতে লাগে iam:PassRole। Service-linked role আগে থেকেই ঠিক করা, মালিক service নিজে।
• Cross-account: target account-এ এমন একটা role, যেটা উৎস account-কে বিশ্বাস করে, আর উৎস account-এ assume করার অনুমতি। sensitive role-এ MFA condition, third party-র জন্য external ID (confused deputy)।
• Federation (SAML 2.0, OIDC web identity, Cognito, IAM Identity Center) সবসময় শেষ হয় একটা role assume করে। মানুষের ঢোকার জন্য AWS-এর সুপারিশ Identity Center।
• code-এ বসানো বা ফাঁস হওয়া key: deactivate, CloudTrail-এ তদন্ত, পরিষ্কার, role দিয়ে বদল, তারপর delete। long-term key rotate করো দুই key পদ্ধতিতে।
• Credentials Report = পুরো account-এর CSV, প্রতিটা user-এর credential (MFA, key-এর বয়স)। Access Advisor = একটা identity কোন service ব্যবহার করতে পারে আর শেষ কবে করেছে; অব্যবহৃত permission সরানোর tool এটাই। Access Analyzer = বাইরের সাথে share আর অব্যবহৃত access-এর finding, সাথে policy তৈরি।

নিজেকে যাচাই করো: role, STS আর IAM security tool৩৮টি প্রশ্ন