IAM Identity Center, Directory Service আর Control Tower

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

• Workforce identity (যারা তোমার AWS account বানায় আর চালায়) আর customer identity (যারা তোমার app ব্যবহার করে) আলাদা করতে, আর সেই অনুযায়ী IAM Identity Center না Amazon Cognito, বেছে নিতে।
• IAM Identity Center কীভাবে কাজ করে বুঝিয়ে বলতে: একটা access portal, একটাই identity source (নিজের directory, Active Directory, অথবা SAML 2.0 আর SCIM দিয়ে জোড়া বাইরের কোনো IdP), permission set যেটা প্রতিটা assign করা account-এ AWSReservedSSO_ নামের IAM role হয়ে যায়, আর user বা group-কে account-এর সাথে জোড়ার assignment।
• Console-এর বাইরেও Identity Center ব্যবহার করতে: aws configure sso দিয়ে CLI, SAML 2.0 দিয়ে business application, user attribute-কে session tag বানিয়ে ABAC, organization instance বনাম account instance, delegated administration আর session duration; আর জানতে কী একে এখনও সীমিত করে (SCP) আর কী ভুল হয় (কেউ চলে গেলে, আবার provision করা)।
• Microsoft Active Directory (domain controller, object, OU, tree, forest, GPO, Kerberos) এতটা বুঝতে, যাতে directory-র প্রশ্ন পড়ে ধরতে পারো।
• পরীক্ষার keyword দেখে AWS Managed Microsoft AD, AD Connector আর Simple AD-এর মধ্যে বাছতে: এদের মাপ, trust, MFA-র উপায়, কোন service-এর সাথে চলে; আর ২০২৫–২৬-এর বদলগুলো জানতে (Hybrid Edition, নতুন customer-এর জন্য Simple AD বন্ধ)।
• AWS Control Tower কী বানায় বুঝিয়ে বলতে (Organizations, Identity Center, CloudTrail আর Config-এর ওপর একটা landing zone, Log Archive আর Audit account-সহ Security OU, Account Factory), আর এর control কীভাবে কাজ করে: preventive, detective আর proactive, সাথে drift আর তার মেরামত।

#কেন: অনেক account, অনেক মানুষ, একটাই সদর দরজা

লেসন ২০.১-এ আমরা AWS Organizations-এর নিচে একটা কোম্পানিকে অনেকগুলো AWS account-এ ভাগ করেছি, আর লেসন ২০.২-এ দেখেছি ঠিক কোন policy কী আটকায়। একটা প্রশ্ন বাকি থেকে গেল: মানুষ এতগুলো account-এ ঢুকবে কীভাবে?

পুরোনো উত্তর ছিল প্রতিটা account-এ প্রতিজনের জন্য একটা করে IAM user। ৪০টা account আর ৩০০ জন engineer হলে সেটা দাঁড়ায় ১২,০০০ পর্যন্ত user, ১২,০০০ password, আর laptop-এ laptop-এ access key। কেউ চাকরি ছাড়লে কাউকে মনে রাখতে হয় তার কোন কোন account ছিল। লেসন ২.৪-এ আধুনিক নিয়মটা আমরা আগেই পেয়েছি: মানুষ পাবে federation দিয়ে অস্থায়ী credential, কখনো long-term key না। কোম্পানির মাপে এই নিয়মটা চালু রাখতে AWS-এর তিনটা উত্তর আছে, এই লেসন সেগুলো নিয়েই:

• IAM Identity Center: কর্মীদের জন্য একবার sign-in, আর প্রতিটা account-এর permission এক জায়গা থেকে।
• AWS Directory Service: AWS-এ Microsoft Active Directory, Windows workload-এর জন্য আর identity source হিসেবে।
• AWS Control Tower: আগে থেকে বানানো, শাসনের মধ্যে থাকা একটা multi-account environment, যেখানে প্রথম দিন থেকেই Identity Center আর guardrail চালু।

#কর্মীদের identity বনাম customer-দের identity

তোমার বানানো জিনিসে দুই ধরনের মানুষ sign in করে, আর AWS-এর দুই ধরনের জন্য দুটো আলাদা service আছে। লেসন ১৫.৭-এ এই তুলনাটা দেখানোর কথা দেওয়া ছিল।

#IAM Identity Center কী আর কেন

AWS IAM Identity Center (আগের নাম AWS Single Sign-On, ২০২২-এ নাম বদলেছে; পরীক্ষার প্রশ্নে যেকোনোটা থাকতে পারে) তোমার কর্মীদের একবার sign-in দিয়ে ঢুকতে দেয়:

• তোমার organization-এর প্রতিটা AWS account-এ, AWS access portal, console আর CLI দিয়ে;
• আগে থেকে জোড়া business cloud application-এ (Microsoft 365, Salesforce, Box, Slack আর আরও অনেক);
• SAML 2.0 বোঝে এমন যেকোনো custom application-এ (বা OAuth 2.0);
• EC2 Windows instance-এ, Systems Manager Fleet Manager-এর remote desktop দিয়ে, local administrator-এর password ভাগাভাগি না করেই।

এটা AWS Organizations-এর সাথে গভীরভাবে বাঁধা: সুপারিশ করা setup হলো একটা organization instance, management account-এ চালু করা, যেটা প্রতিটা member account-এর access সামলাতে পারে। Identity Center-এর নিজের কোনো দাম নেই; মানুষ যেসব AWS resource ব্যবহার করে, শুধু সেগুলোর টাকা লাগে।

#একটাই identity source

Identity Center একবারে ঠিক একটা identity source-এর সাথে জোড়া থাকে:

SCIM (System for Cross-domain Identity Management) দুই জায়গার copy একসাথে মিলিয়ে রাখে: IdP-তে কেউ যোগ দিলে, team বদলালে বা চলে গেলে, AWS-এ কাউকে হাত না দিয়েই সেই বদল Identity Center-এ পৌঁছে যায়। পরে identity source বদলানো যায়, কিন্তু সেটা ঝামেলার (আগের user, group আর assignment মুছে যেতে পারে), তাই শুরুতেই ঠিক করে নাও।

#Permission set, account আর assignment

কে কোথায় কী করতে পারবে, ঠিক করে তিনটা জিনিস:

• Permission set হলো permission-এর একটা template: AWS managed policy, customer managed policy (নাম ধরে লাগানো), একটা inline policy, দরকারে একটা permissions boundary, আর একটা session duration (default ১ ঘণ্টা, সর্বোচ্চ ১২ ঘণ্টা)।
• Organization-এর একটা AWS account (বা একটা OU, যেখান থেকে account বাছবে)।
• Assignment এগুলোকে জোড়ে: একজন user বা একটা group + একটা account + একটা permission set।

Assignment করলে Identity Center permission set-টা ওই account-এ provision করে: সে একটা IAM role বানায়, যার নাম AWSReservedSSO_ আর তারপর permission set-এর নাম আর একটা এলোমেলো suffix (যেমন AWSReservedSSO_DevReadOnly_3f2a9c1d7b6e4a10), /aws-reserved/sso.amazonaws.com/ path-এর নিচে; এই role-কে বিশ্বাস করে শুধু একটা SAML provider, যেটাও Identity Center ওই account-এ বানিয়ে দেয়। তাই note-এ যেমন বলা, permission set শুধু role-এর “মতো” না: প্রতিটা account-এ সেটা সত্যিকারের একটা IAM role হয়ে যায়। একটা account-এ একটা permission set-এর একটাই role, আর সেখানে ওই set যাদের assign করা, সব user আর group সেটাই ভাগ করে ব্যবহার করে।

কয়েকটা ফলাফল, যেগুলোর ওপর পরীক্ষার প্রশ্ন আর বাস্তবের গোলমাল দুটোই ঘোরে:

• Permission set বদলালেই role বদলায় না। Account-এর role-গুলো update হয় permission set আবার provision করলে (save করলে console নিজেই করে; API দিয়ে করলে provision-permission-set call করতে হয়)। তার আগ পর্যন্ত account-গুলো একে outdated দেখায়।
• Customer managed policy নাম ধরে লাগে। প্রতিটা target account-এ ঠিক ওই নামের (আর path-এর) একটা policy থাকতে হবে, নইলে সেখানে provision ব্যর্থ হয়।
• SCP তবুও খাটে। Role-টা member account-এর একটা সাধারণ IAM role, তাই তার OU-র SCP অন্য যেকোনো principal-এর মতোই এর সীমা টানে, আর resource-এর account-এর RCP ঠিক করে দেয় সেই resource-এ এটা কতটা কী করতে পারবে (লেসন ২০.২)। Region-lock করা OU-তে AdministratorAccess permission set-ও Region-lock-এর মধ্যেই থাকে।
• Management account আলাদা। SCP কখনো একে সীমিত করে না (লেসন ২০.১), আর delegated administrator সেখানে provision করা permission set সামলাতে পারে না। Management account-এ মানুষের access যত কম রাখা যায়, তত ভালো।

Matrix-টা চালিয়ে দেখো: প্রতিটা ঘর একটা assignment, আর সেটা কোন role হবে তা নির্ভর করে permission set আর account-এর ওপর।

#একটা sign-in কীভাবে হয়

বাইরের IdP থাকলে portal-এর ধাপগুলো, slide-এর login diagram-এর মতোই:

1. Access portal খোলা

   User organization-এর AWS access portal URL খোলে (যেমন https://d-1234567890.awsapps.com/start)। বাইরের IdP থাকলে Identity Center একটা SAML request-সহ browser-কে সেখানে পাঠিয়ে দেয়।

2. IdP-তে পরিচয় যাচাই

   IdP নিজের নিয়মে password আর MFA যাচাই করে, তারপর একটা sign করা SAML assertion ফেরত পাঠায়। AWS password কখনো দেখেই না।

3. Account আর permission set বাছা

   Portal শুধু সেই account আর permission set দেখায়, যেগুলো user বা তার group-এ assign করা, সাথে assign করা application।

4. Role-এর credential পাওয়া

   Identity Center ওই account-এর AWSReservedSSO_ role-এর অস্থায়ী credential নিয়ে console খুলে দেয় (বা credential CLI-র হাতে দেয়)। Session চলে permission set-এর session duration যতক্ষণ।

CLI-র জন্য aws configure sso একটা profile রাখে (start URL, Region, account, permission set), আর aws sso login browser দিয়ে একটা token নেয়; এরপর CLI নিজেই অল্প সময়ের role credential এনে নবায়ন করতে থাকে। Laptop-এ কোনো access key রাখতে হয় না।

#Application আর ABAC

Application assignment business application-এ single sign-on দেয়। Catalogue-এর app হলে (Microsoft 365, Salesforce, Box…) setup ধাপে ধাপে দেখিয়ে দেয়; custom SAML 2.0 application হলে metadata আদান-প্রদান করতে হয়: application-এর sign-in URL আর audience, Identity Center-এর certificate আর metadata file, আর কোন কোন attribute পাঠাবে। তারপর user একই portal থেকে app খোলে।

Attribute-based access control (ABAC)-এ permission set বাড়াতে না থেকে permission চলে user-এর attribute অনুযায়ী। তুমি attributes for access control চালু করো, আর Identity Center identity store বা IdP থেকে বাছাই করা attribute (department, cost center, পদ, locale…) session tag হিসেবে পাঠায়। তখন একটাই permission set বলতে পারে: resource-এর tag আর caller-এর tag মিললে তবেই access, condition-এ aws:PrincipalTag/department দিয়ে (লেসন ২০.২-এ condition key-গুলো আছে)। কেউ বিভাগ বদলালে policy না, একটা attribute বদলাও।

#Instance, administration আর Region

• Organization instance (সুপারিশ করা): management account-এ চালু করা হয়; একমাত্র এটাতেই আছে multi-account permission, portal-এ AWS account-এ ঢোকা, customer managed SAML 2.0 application আর delegated administrator। এটা একটা home Region-এ থাকে।
• Account instance: একটা account-এ বাঁধা (member account বা আলাদা একটা account), শুধু সেখানেই দেখা যায়, শুধু application assignment-এর জন্য (যেমন কোনো team একটা AWS managed application পরীক্ষা করে দেখছে)। এটা দিয়ে AWS account-এ access দেওয়া যায় না।
• Delegated administrator: একটা member account-কে Identity Center চালানোর দায়িত্ব দেওয়া যায়, যাতে security team-কে management account-এ কাজ করতে না হয়। Management account-এ provision করা permission set সে সামলাতে পারে না।
• Session duration: permission set-এর duration ঠিক করে AWS account-এর session (১ থেকে ১২ ঘণ্টা); access portal-এর session-এর নিজের আলাদা setting আছে (default ৮ ঘণ্টা)।
• Encryption: organization instance তার ডেটা customer managed KMS key দিয়ে encrypt করে রাখতে পারে (লেসন ২১.২)।

#এক পাতায় Microsoft Active Directory

পরীক্ষার অনেক প্রশ্ন ধরে নেয় তুমি জানো Active Directory কী। Microsoft Active Directory (AD), আরও ঠিক করে বললে AD Domain Services, Windows Server-এ চলে, আর Windows PC-ওয়ালা বেশির ভাগ কোম্পানির directory এটাই:

• এটা object-এর একটা database: password-সহ user account, computer, printer, file share আর security group।
• এটা চালায় domain controller: যেসব server database-এর একটা copy রাখে আর প্রতিটা sign-in যাচাই করে, Kerberos দিয়ে (প্রতিটা domain controller-এ একটা KDC ticket দেয়), আর বিকল্প হিসেবে পুরোনো NTLM দিয়ে। Application এতে LDAP দিয়েও প্রশ্ন করে (encrypt করা অবস্থায়: LDAPS)।
• এটা এক জায়গা থেকে security সামলাতে দেয়: একবার account বানাও, group-এ রাখো, আর domain-কে বিশ্বাস করে এমন প্রতিটা server, share আর app সেটাই ব্যবহার করে। Group Policy Object (GPO) একটা container-এর সব computer-এ setting পৌঁছে দেয় (screen lock, password-এর নিয়ম, USB drive বন্ধ)।
• Object থাকে একটা domain-এর ভেতরের organizational unit-এ; কয়েকটা domain মিলে হয় tree (একটা parent আর তার child domain, একই DNS নামের নিচে), আর কয়েকটা tree মিলে একটা forest, সবচেয়ে বাইরের security-র সীমানা।
• দুটো forest-কে trust দিয়ে জোড়া যায়, তাতে একটার user অন্যটার resource ব্যবহার করতে পারে। Trust হতে পারে one-way বা two-way।

লেসন ১২.২-এ ৫০০ কর্মীর কোম্পানির উদাহরণটা ছিল: AD না থাকলে প্রতিটা PC-তে আলাদা account লাগে; AD থাকলে যেকোনো কর্মী যেকোনো PC-তে sign in করতে পারে, আর সব permission সামলানো হয় এক জায়গা থেকে। Cloud-এ এটা আনার তিনটা উপায় AWS দেয়।

#AWS Directory Service: AD চালানোর তিন উপায়

AWS Directory Service AWS-এ Windows আর LDAP workload-এর জন্য directory দেয়। Note, slide আর পরীক্ষা, তিন জায়গাতেই একই তিনটা বিকল্পের তুলনা।

#AWS Managed Microsoft AD

AWS Managed Microsoft AD (পুরো নাম AWS Directory Service for Microsoft Active Directory) হলো একটা সত্যিকারের Microsoft Active Directory (Windows Server-এর domain controller), যেটা AWS তোমার VPC-তে তোমার হয়ে চালায়:

• High availability: দুটো Availability Zone-এ দুটো domain controller; AWS এগুলোর ওপর নজর রাখে, patch করে, snapshot নেয় আর নষ্ট হলে বদলে দেয়। চাপ বাড়লে আরও domain controller যোগ করা যায়, আর (Enterprise Edition-এ) directory অন্য Region-এ replicate করা যায়।
• Edition: Standard (ছোট আর মাঝারি প্রতিষ্ঠান, মোটামুটি ৩০,০০০ object পর্যন্ত, আন্দাজ ৫,০০০ কর্মী) আর Enterprise (মোটামুটি ৫,০০,০০০ object পর্যন্ত)।
• Trust: তোমার on-premises AD বা অন্য কোনো AD-এর সাথে one-way বা two-way forest trust (আর external trust), তাতে user আগের account-ই রাখে আর AWS-এর directory resource ধরে রাখে (একে বলে “resource forest”)।
• আসল AD-র feature: GPO, schema extension, LDAPS, fine-grained password policy, domain-এ join করা instance থেকে Windows PowerShell দিয়ে administration।
• তোমার RADIUS server দিয়ে MFA।
• যাদের সাথে চলে: EC2 Windows আর Linux instance-এর seamless domain join, RDS for SQL Server (Windows authentication; RDS for Oracle আর PostgreSQL-এর Kerberos-ও), FSx for Windows File Server, WorkSpaces, Amazon QuickSight, Amazon Connect, আর identity source হিসেবে Identity Center। অন্য account-এর সাথে share করা যায়।
• এটা একা একটা পুরো directory-ও: এতেই user বানিয়ে সবকিছু AWS-এ সামলাতে পারো।

#AD Connector

AD Connector কোনো directory না। এটা তোমার VPC-তে বসানো একটা directory gateway (proxy), যেটা sign-in আর খোঁজাখুঁজির request তোমার on-premises domain controller-এ পাঠিয়ে দেয়, আর AWS-এ কোনো credential বা directory-র ডেটা cache করে না:

• User আর group সামলানো হয় শুধু on-premises-এ, চেনা tool দিয়েই; তোমার password, lockout আর মেয়াদের নিয়ম যেমন ছিল তেমনই খাটে।
• Domain controller পর্যন্ত একটা network-এর পথ লাগে: Site-to-Site VPN বা Direct Connect (লেসন ২২.৪ আর ২২.৫), domain-এর নাম resolve করার মতো DNS, আর AD-তে সীমিত অধিকারের একটা service account।
• মাপ: Small আর Large, প্রতি সেকেন্ডে কতগুলো কাজ সামলায় সেই হিসাবে; user-এর কোনো বাঁধা সীমা নেই; চাপ বেশি হলে কয়েকটা connector-এ ভাগ করে দাও। প্রতিটা domain-এর জন্য একটা connector।
• MFA: তোমার on-premises RADIUS server দিয়ে।
• যাদের সাথে চলে: WorkSpaces, QuickSight, WorkMail, AD credential দিয়ে AWS Management Console, EC2 instance-কে on-premises domain-এ seamless domain join, আর Identity Center। RDS for SQL Server-এর সাথে চলে না, transitive trust বোঝে না, অন্য account-এর সাথে share করা যায় না, আর শুধু নিজের VPC-কেই সেবা দেয়।
• দুর্বল জায়গা: সবকিছু link-এর ওপর নির্ভর করে। VPN বা Direct Connect connection বন্ধ হলে connector ব্যবহার করে এমন কোনো কিছুতেই কেউ sign in করতে পারে না।

#Simple AD

Simple AD হলো Samba 4 দিয়ে চলা, AD-এর সাথে মানানসই একটা directory, AWS-এ একা চলে। এটা Microsoft AD না:

• মাপ: Small, ৫০০ user পর্যন্ত (প্রায় ২,০০০ object) আর Large, ৫,০০০ user পর্যন্ত (প্রায় ২০,০০০ object)।
• যা পারে: user account আর group, group policy, Kerberos-ভিত্তিক single sign-on, LDAP, EC2 Linux আর Windows instance-এর domain join, WorkSpaces আর WorkMail, প্রতিদিনের snapshot।
• যা পারে না: অন্য কোনো domain-এর সাথে trust (তাই on-premises AD-র সাথে জোড়া যায় না), MFA, schema extension, LDAPS, PowerShell-এর AD cmdlet, AD recycle bin, RDS for SQL Server, FSx, আর Identity Center।

#কোন directory বাছবে

Note-এর পরীক্ষার keyword, যেমন আছে তেমনই:

• “On-premises AD-র সাথে trust relationship বানাতে হবে” → AWS Managed Microsoft AD।
• “কোম্পানির policy-তে AD-র কোনো credential বা password cloud-এ রাখা নিষেধ” → AD Connector।
• “কম খরচ, সাধারণ AD feature, cloud-এ একা চলবে, trust লাগবে না” → Simple AD।

#Active Directory-র সাথে Identity Center

Identity Center-এর AD setup-এর slide-এ AD-কে Identity Center-এর source বানানোর তিনটা উপায় দেখানো:

1. AWS Managed Microsoft AD-র সাথে জোড়া: integration একেবারে তৈরি; user আর group এখানেই থাকতে পারে।
2. Two-way trust দিয়ে নিজের চালানো AD: user থাকে on-premises forest-এ; Managed AD সেটাকে trust করে, আর Identity Center জোড়ে Managed AD-র সাথে।
3. AD Connector দিয়ে নিজের চালানো AD: Identity Center জোড়ে connector-এর সাথে, connector proxy করে on-premises AD-তে।

Simple AD চলে না। যেসব কোম্পানি আগে থেকেই AD-কে Microsoft Entra ID-তে sync করে, তারা অনেক সময় সোজা Entra ID-কেই বাইরের IdP হিসেবে Identity Center-এর সাথে জুড়ে দেয়।

#AWS Control Tower

হাতে একটা ভালো multi-account environment বানানো মানে: organization আর তার OU বানাও, একটা log archive account, একটা audit account, পুরো organization জুড়ে CloudTrail আর Config, Identity Center, SCP, আর এমন একটা প্রক্রিয়া যেটা নতুন account বানালে তাতে এসব আগে থেকেই থাকবে। AWS Control Tower AWS-এর best practice মেনে এগুলো তোমার হয়ে করে দেয়, আর পরেও শাসন চালিয়ে যায়।

#Landing zone

Landing zone মানে well-architected একটা multi-account environment। Control Tower-এ এটা বসালে (management account থেকে, তোমার বাছা একটা home Region-এ) সে আগের চেনা service-গুলোর ওপরই বানায়:

• AWS Organizations: OU আর account বানাতে Control Tower এটাই ব্যবহার করে (লেসন ২০.১)।
• দুটো shared account-সহ একটা Security OU: Log Archive (প্রতিটা account-এর CloudTrail আর Config log রাখার কেন্দ্রীয় S3 bucket) আর Audit (security team-এর পড়ার আর notification পাওয়ার access, যেখানে Config-এর finding জমা হয় আর notification যায়)।
• আগে থেকে সাজানো group আর permission set-সহ IAM Identity Center (বা তোমার নিজের IdP)।
• শাসনে রাখা Region-গুলোর জন্য পুরো organization জুড়ে একটা CloudTrail trail (লেসন ১৯.৬) আর AWS Config recording (লেসন ১৯.৭)।
• OU-গুলোর ওপর control (guardrail), আর একটা dashboard, যেখানে OU, account, চালু control আর নিয়ম না মানা resource দেখা যায়।

Account Factory এমন নতুন account বানায় যেগুলো আগে থেকেই enroll করা: বাছা OU-তে রাখা, প্রথম মিনিট থেকেই logging, Config, Identity Center-এর access আর OU-র control-সহ। এটা console-এর একটা wizard (পেছনে AWS Service Catalog) আর একটা API। Account Factory for Terraform একই account বানানোর কাজ Terraform pipeline থেকে চালায়, যেসব team সবকিছু code হিসেবে রাখে তাদের জন্য। আগে থেকে থাকা account-ও enroll করা যায়, আর আগের OU register করা যায়।

#Control (আগের নাম guardrail)

AWS এখন guardrail-কে বলে control (documentation, console আর slide-এ দুটো শব্দই চলে)। Control হলো সহজ ভাষায় লেখা একটা নিয়ম, যেটা একটা OU-তে লাগানো হয়, তাই OU-র প্রতিটা account সেই নিয়মে চলে। প্রতিটা control-এর একটা behaviour আছে:

আর একটা guidance-এর স্তর: mandatory (Control Tower নিজে যেসব resource বসিয়েছে সেগুলো রক্ষা করে; সবসময় চালু, আর landing zone 4.0 থেকে কোনগুলো বসবে তা নির্ভর করে তুমি কোন integration চালু করেছ তার ওপর), strongly recommended (প্রচলিত best practice) আর elective (যেসব কাজ অনেক বড় প্রতিষ্ঠান বন্ধ রাখে সেগুলো আটকানো)। SCP-র মতোই control management account-কে সীমিত করে না।

Slide-এর detective উদাহরণ: একটা Config rule member account-এ tag-ছাড়া resource খোঁজে; কোনো resource NON_COMPLIANT হলে control সেটা dashboard-এ দেখায়, একটা SNS topic admin-দের জানায়, আর একটা Lambda function ঠিক করে দিতে পারে (হারানো tag বসিয়ে)। জানানো আর ঠিক করার ব্যবস্থা তোমাকে বানাতে হবে (যেমন Config-এর compliance বদলের ওপর EventBridge দিয়ে); Control Tower শুধু রিপোর্ট করে।

#Drift কী

Drift মানে landing zone আর Control Tower যেমন বসিয়েছিল তেমন নেই, কারণ কেউ Control Tower-কে পাশ কাটিয়ে বদল করেছে, সাধারণত Organizations console-এ: enroll করা account register করা OU থেকে সরিয়ে নেওয়া, Control Tower-এর OU মুছে ফেলা, Control Tower-এর SCP খুলে ফেলা বা বদলানো, বা organization থেকে কোনো account সরিয়ে দেওয়া। Control Tower drift ধরে ফেলে আর জানায় (Audit account-এর topic আর console দিয়ে; landing zone 4.0 থেকে management account-এ EventBridge event হিসেবে)। ঠিক করতে হয় Control Tower থেকেই: account update করো, OU আবার register করো, বা landing zone repair (reset) করো। নিয়ম: organization-এর বদল Control Tower দিয়ে করো, তার পাশ দিয়ে না।

#কী কী ভুল হয়

• চলে যাওয়া কেউ কিছুক্ষণ access রাখে: IdP-তে user বন্ধ হয়েছে, কিন্তু আগে দেওয়া role session মেয়াদ শেষ না হওয়া পর্যন্ত চলে। Session duration ছোট রাখো; জরুরি অবস্থার জন্য explicit Deny যোগ করো; SCIM provisioning আসলেই চালু কি না দেখো।
• Permission set বদলেও “কিছুই হলো না”: বদলানো হয়েছে, কিন্তু আবার provision করা হয়নি। যেসব account এটা ব্যবহার করে, সবগুলোতে আবার provision করো।
• একটা account-এ provision ব্যর্থ: permission set-এ নাম দেওয়া customer managed policy সেখানে নেই, বা কোনো SCP Identity Center-এর IAM কাজ আটকাচ্ছে। প্রতিটা account-এ policy-টা বানাও (Account Factory বা CloudFormation stack set এটা করে দিতে পারে)।
• কেউ IAM-এ একটা AWSReservedSSO_ role বদলেছে: পরের provision-এ বদলটা মুছে যায়। তার বদলে permission set বদলাও।
• AdministratorAccess দিয়েও কিছু একটা করা যাচ্ছে না: account-এর OU-র কোনো SCP বা RCP সেটা deny করছে। এটাই হওয়ার কথা।
• AD Connector-এর সব sign-in ব্যর্থ: VPN বা Direct Connect link বন্ধ, domain controller-এ DNS forwarding ভাঙা, service account-এর password-এর মেয়াদ শেষ, বা security group আর on-premises firewall AD-র port আটকাচ্ছে (DNS 53, Kerberos 88, LDAP 389…)। বাড়তি link রাখো; cloud-কে একা চলতে হলে trust-সহ Managed AD নাও।
• Trust তৈরি হচ্ছে না: Simple AD trust করতেই পারে না; Managed AD হলে দুই দিকের conditional DNS forwarder, দুই network-এর মধ্যে খোলা port, আর trust-এর দিক দেখো (trust-এর ওপর Identity Center-এ two-way লাগে)।
• RDS for SQL Server directory ব্যবহার করতে পারছে না: সেটা AD Connector বা Simple AD ছিল; RDS-এর লাগে Managed Microsoft AD।
• Control Tower drift দেখাচ্ছে: কোনো account বা SCP সরাসরি Organizations-এ বদলানো হয়েছে। Control Tower দিয়ে repair করো।
• নতুন একটা account শাসনের বাইরে: সেটা Account Factory দিয়ে না, Organizations-এ বানানো, আর কখনো enroll করা হয়নি। Enroll করো।

#System design-এ identity

ভালোভাবে শাসিত একটা AWS ব্যবস্থায় অধ্যায় ২০-এর সবকিছু একসাথে কাজ করে:

1. Control Tower organization বানায়: Security OU (Log Archive, Audit), প্রতিটা environment-এর জন্য Workloads OU, একটা Sandbox OU, preventive আর detective control (নিচের SCP-গুলো লেসন ২০.১ বুঝিয়েছে)।
2. Identity Center মানুষের ঢোকার একমাত্র পথ: কোম্পানির IdP-র সাথে জোড়া (বা Managed AD বা AD Connector দিয়ে AD-র সাথে), কাজ অনুযায়ী permission set (শুধু পড়া, developer, database admin, administrator), প্রতিটা account-এর জন্য group-এ assign করা, ছোট session, IdP-তে MFA, আর যেখানে permission attribute অনুযায়ী চলে সেখানে ABAC।
3. Workload IAM role ব্যবহার করে, কখনো মানুষের credential না (লেসন ২.৪)।
4. Windows workload (EC2 Windows, RDS for SQL Server, FSx for Windows, WorkSpaces) Managed Microsoft AD-তে join করে, কোম্পানির forest-কে trust করে; অথবা AWS-এ কিছুই রাখা না গেলে আর link ভরসাযোগ্য হলে AD Connector ব্যবহার করে।
5. App-এর customer sign in করে Cognito দিয়ে, কর্মীদের থেকে পুরোপুরি আলাদা।

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

এই command-গুলো AWS CLI v2-এর। Identity Center-এর command চলে management account-এ (বা delegated administrator account-এ), Identity Center-এর Region-এ। Directory আর Control Tower-এর resource-এ টাকা লাগে; কাজ শেষে মুছে ফেলো।

# ১. Identity Center instance আর তার identity store খুঁজে বের করো
aws sso-admin list-instances
# { "Instances": [ { "InstanceArn": "arn:aws:sso:::instance/ssoins-72231a1b2c3d4e5f",
#                    "IdentityStoreId": "d-9067a1b2c3", "Status": "ACTIVE" } ] }
INST=arn:aws:sso:::instance/ssoins-72231a1b2c3d4e5f

# ২. Identity store-এ একটা group খোঁজো (IdP থেকে SCIM দিয়ে sync হওয়া)
aws identitystore list-groups --identity-store-id d-9067a1b2c3 \
  --filters AttributePath=DisplayName,AttributeValue=Developers
# { "Groups": [ { "GroupId": "9a67a1b2-c3d4-70e5-f6a7-b8c9d0e1f2a3", "DisplayName": "Developers" } ] }
aws identitystore list-users --identity-store-id d-9067a1b2c3 --max-results 2

# ৩. একটা permission set: ReadOnlyAccess, ৪ ঘণ্টার session
aws sso-admin create-permission-set --instance-arn $INST \
  --name DevReadOnly --session-duration PT4H
# { "PermissionSet": { "PermissionSetArn": "arn:aws:sso:::permissionSet/ssoins-72231a1b2c3d4e5f/ps-1a2b3c4d5e6f7a8b", ... } }
PS=arn:aws:sso:::permissionSet/ssoins-72231a1b2c3d4e5f/ps-1a2b3c4d5e6f7a8b
aws sso-admin attach-managed-policy-to-permission-set --instance-arn $INST \
  --permission-set-arn $PS --managed-policy-arn arn:aws:iam::aws:policy/ReadOnlyAccess

# ৪. Developers group-কে এই permission set দিয়ে Dev account-এ assign করো
aws sso-admin create-account-assignment --instance-arn $INST \
  --target-id 111122223333 --target-type AWS_ACCOUNT \
  --permission-set-arn $PS \
  --principal-type GROUP --principal-id 9a67a1b2-c3d4-70e5-f6a7-b8c9d0e1f2a3
# { "AccountAssignmentCreationStatus": { "Status": "IN_PROGRESS", "RequestId": "..." } }

# ৫. পরে permission set বদলালে, যেখানে যেখানে ব্যবহার হয় সব জায়গায় আবার provision করো
aws sso-admin provision-permission-set --instance-arn $INST \
  --permission-set-arn $PS --target-type ALL_PROVISIONED_ACCOUNTS

# ৬. Dev account-এ assignment যে role বানাল
aws iam list-roles --path-prefix /aws-reserved/sso.amazonaws.com/ --query 'Roles[].RoleName'
# [ "AWSReservedSSO_DevReadOnly_3f2a9c1d7b6e4a10" ]

# ৭. User হিসেবে: একবার CLI profile বানাও, তারপর sign in
aws configure sso
# SSO session name (Recommended): hospital
# SSO start URL [None]: https://d-9067a1b2c3.awsapps.com/start
# SSO region [None]: ap-southeast-1
# ... There are 2 AWS accounts available to you. -> Dev (111122223333)
# ... Using the role name "DevReadOnly"
# CLI profile name [DevReadOnly-111122223333]: dev
aws sso login --profile dev
aws sts get-caller-identity --profile dev
# { "Account": "111122223333",
#   "Arn": "arn:aws:sts::111122223333:assumed-role/AWSReservedSSO_DevReadOnly_3f2a9c1d7b6e4a10/nusrat@example.com" }

# ৮. Directory Service: দুই AZ-এর দুই subnet-এ একটা Managed Microsoft AD (Standard Edition)
aws ds create-microsoft-ad --name aws.corp.example.com --short-name AWSCORP \
  --password '<admin-password>' --edition Standard \
  --vpc-settings VpcId=vpc-0a1b2c3d4e5f67890,SubnetIds=subnet-0aa11bb22cc33dd44,subnet-0ee55ff66aa77bb88
# { "DirectoryId": "d-906a1b2c3d" }

# ৯. On-premises domain corp.example.com-এর সাথে two-way forest trust
aws ds create-trust --directory-id d-906a1b2c3d \
  --remote-domain-name corp.example.com --trust-password '<trust-password>' \
  --trust-direction Two-Way --trust-type Forest \
  --conditional-forwarder-ip-addrs 10.20.0.10 10.20.0.11

# ১০. On-premises domain controller দেখানো একটা AD Connector (Small)
aws ds connect-directory --name corp.example.com --short-name CORP --size Small \
  --password '<service-account-password>' \
  --connect-settings VpcId=vpc-0a1b2c3d4e5f67890,SubnetIds=subnet-0aa11bb22cc33dd44,subnet-0ee55ff66aa77bb88,CustomerDnsIps=10.20.0.10,10.20.0.11,CustomerUserName=svc-adconnector

# ১১. একটা Simple AD (Small): শুধু যেসব account আগে থেকেই Simple AD ব্যবহার করে
aws ds create-directory --name lab.example.com --password '<admin-password>' --size Small \
  --vpc-settings VpcId=vpc-0a1b2c3d4e5f67890,SubnetIds=subnet-0aa11bb22cc33dd44,subnet-0ee55ff66aa77bb88

aws ds describe-directories --query 'DirectoryDescriptions[].[DirectoryId,Name,Type,Edition,Size,Stage]'
# [ [ "d-906a1b2c3d", "aws.corp.example.com", "MicrosoftAD", "Standard", null, "Active" ],
#   [ "d-906a4e5f6a", "corp.example.com", "ADConnector", null, "Small", "Active" ] ]

# ১২. Control Tower: একটা OU-তে detective control চালু করো, তারপর চালু থাকাগুলোর তালিকা দেখো
aws controltower enable-control \
  --control-identifier arn:aws:controlcatalog:::control/<control-id> \
  --target-identifier arn:aws:organizations::111122223333:ou/o-a1b2c3d4e5/ou-ab12-cdef3456
# { "operationIdentifier": "a1b2c3d4-...", "arn": "arn:aws:controltower:ap-southeast-1:111122223333:enabledcontrol/..." }
aws controltower list-enabled-controls \
  --target-identifier arn:aws:organizations::111122223333:ou/o-a1b2c3d4e5/ou-ab12-cdef3456

# ১৩. Code হিসেবে landing zone: manifest file থেকে একটা বানাও, তারপর দেখো
aws controltower create-landing-zone --landing-zone-version 4.0 --manifest file://manifest.json
aws controltower list-landing-zones

Console-এও করে দেখো: Identity Center-এ Settings → Attributes for access control খুলে department map করো; তারপর Control Tower-এ Controls খুলে behaviour (preventive, detective, proactive) দিয়ে filter করো, দেখো কোনটা কী দিয়ে বানানো।

#সারাংশ

মূল কথাগুলো

• কর্মী বনাম customer: কর্মীরা AWS account আর business app-এ → IAM Identity Center; তোমার app-এর user → Cognito।
• Identity Center (আগের নাম AWS SSO): AWS Organizations-এর সব account, SAML 2.0 app (Microsoft 365, Salesforce…) আর EC2 Windows-এর জন্য একটাই portal; একটাই identity source: নিজের directory, Active Directory (Managed AD বা AD Connector) বা SAML 2.0 + SCIM-সহ বাইরের IdP (Entra ID, Okta, Google Workspace)।
• Permission set (policy + ১–১২ ঘণ্টার session duration) + account + user/group = assignment; provision করলে প্রতিটা account-এ সত্যিকারের একটা IAM role তৈরি হয়, AWSReservedSSO_…। বদলালে আবার provision লাগে; SCP তবুও সীমা টানে; management account আলাদা।
• CLI: aws configure sso, aws sso login, অল্প সময়ের credential। ABAC: attributes for access control → session tag → aws:PrincipalTag। Organization instance (management account, অনেক account) বনাম account instance (শুধু app)। IdP-তে বাদ দিলে আর SCIM থাকলে সব জায়গা থেকে access যায়; আগে দেওয়া session মেয়াদ পর্যন্ত চলে।
• AD-র মূল কথা: domain controller, object, OU, domain, tree, forest, GPO, Kerberos, trust।
• Managed Microsoft AD: আসল AD, দুই AZ-এ দুটো domain controller, Standard (~৩০,০০০ object) / Enterprise (~৫,০০,০০০), on-premises AD-র সাথে forest trust, RADIUS দিয়ে MFA, RDS for SQL Server, FSx, WorkSpaces আর EC2-এর seamless domain join-এর সাথে চলে। Hybrid Edition (২০২৫) তোমার নিজের domain-কেই বাড়ায়।
• AD Connector: proxy, AWS-এ কিছুই cache হয় না, VPN বা Direct Connect লাগে, Small/Large, on-premises RADIUS দিয়ে MFA, RDS for SQL Server চলে না; link বন্ধ → sign-in ব্যর্থ।
• Simple AD: Samba 4, Small ≤ ৫০০ / Large ≤ ৫,০০০ user, trust নেই, MFA নেই, RDS for SQL Server নেই; জুলাই ২০২৬ থেকে নতুন customer-এর জন্য বন্ধ।
• Control Tower: Organizations, Identity Center, CloudTrail আর Config-এর ওপর landing zone; Log Archive আর Audit-সহ Security OU; Account Factory (আর Terraform-এর জন্যও); control: preventive (SCP/RCP), detective (Config rule), proactive (CloudFormation hook); mandatory / strongly recommended / elective; drift ধরা আর মেরামত; dashboard।

নিজেকে যাচাই করো: Identity Center, Directory Service আর Control Tower৩২টি প্রশ্ন