Cloud IAM: ক্লাউড সার্ভারের অ্যাক্সেস কন্ট্রোল এবং আইডেন্টিটি ম্যানেজমেন্ট!

Cloud IAM হলো একটি ফ্রেমওয়ার্ক যা ক্লাউড পরিবেশে authentication (আপনি কে?) এবং authorization (আপনি কী করতে পারবেন?) নিয়ন্ত্রণ করে। এটি নিশ্চিত করে যে শুধুমাত্র সঠিক ব্যক্তি বা সিস্টেম সঠিক রিসোর্সে, সঠিক সময়ে, সঠিক উদ্দেশ্যে অ্যাক্সেস পাচ্ছে।

Gartner-এর একটি গবেষণা অনুসারে, ২০২৫ সালের মধ্যে ৯৯ শতাংশ ক্লাউড নিরাপত্তা ব্যর্থতা গ্রাহকের নিজস্ব ভুলের কারণে ঘটবে, যার মধ্যে IAM-এর misconfiguration অন্যতম প্রধান। Capital One, Verizon, এবং Accenture-এর মতো বড় প্রতিষ্ঠানের ব্রিচের মূল কারণই ছিল overprivileged IAM role।

Cloud IAM-এর চারটি মূল উপাদান রয়েছে:

• Identities: Users, Groups, Roles, Service Accounts
• Resources: S3 bucket, VM, ডাটাবেস, API ইত্যাদি
• Permissions: কী অ্যাকশন নেওয়া যাবে তার তালিকা
• Policies: এসব permission কীভাবে প্রয়োগ হবে তার নিয়ম

প্রতিটি ক্লাউড প্রোভাইডার তাদের নিজস্ব IAM মডেল ব্যবহার করে, যদিও মূল ধারণা একই।

AWS IAM: AWS-এ Users, Groups, Roles এবং Policies-এর মাধ্যমে অ্যাক্সেস নিয়ন্ত্রিত হয়। Policy লেখা হয় JSON ফর্ম্যাটে এবং এতে Effect (Allow/Deny), Action, Resource, এবং Condition থাকে। Identity-based policy ব্যবহারকারীর সাথে যুক্ত হয়, আর Resource-based policy রিসোর্সের সাথে। AWS-এ আছে IAM Identity Center (পূর্বে AWS SSO) যা multi-account environment-এ centralized identity management প্রদান করে।

Azure AD ও Azure RBAC: Microsoft-এর Azure Active Directory (এখন Entra ID নামে পরিচিত) হলো cloud-native identity platform। Azure-এ permissions দেওয়া হয় Role-Based Access Control (RBAC)-এর মাধ্যমে, যেখানে built-in role যেমন Owner, Contributor, Reader, এবং custom role ব্যবহার করা যায়। Conditional Access policy দিয়ে location, device compliance, এবং risk level-এর ভিত্তিতে অ্যাক্সেস নিয়ন্ত্রণ করা যায়।

Google Cloud IAM: GCP-তে permission দেওয়া হয় principal-এ role assign করার মাধ্যমে। Role তিন ধরনের—Basic (Owner, Editor, Viewer), Predefined (নির্দিষ্ট সার্ভিসের জন্য), এবং Custom। GCP-এর hierarchical structure (Organization → Folder → Project → Resource) policy inheritance সহজ করে।

Authentication হলো IAM-এর প্রথম প্রবেশদ্বার। দুর্বল authentication থাকলে পরবর্তী সব নিরাপত্তা স্তর অর্থহীন হয়ে পড়ে।

Password-based Authentication: এটি সবচেয়ে প্রচলিত হলেও সবচেয়ে দুর্বল। NIST SP 800-63B অনুসারে passphrase ব্যবহার, password rotation কমিয়ে দেওয়া, এবং breached password database-এর সাথে যাচাই করার সুপারিশ করা হয়।

Multi-Factor Authentication (MFA): MFA দ্বিতীয় স্তরের নিরাপত্তা যোগ করে—কিছু আপনি জানেন (পাসওয়ার্ড), কিছু আপনার কাছে আছে (মোবাইল), কিছু আপনি (বায়োমেট্রিক)। FIDO2 hardware token (YubiKey) সবচেয়ে নিরাপদ, কারণ এটি phishing-resistant।

Single Sign-On (SSO): SAML 2.0 বা OpenID Connect-এর মাধ্যমে একটি identity provider থেকে একাধিক সার্ভিসে লগইন করা যায়। এতে user experience উন্নত হয় এবং password sprawl কমে।

Federated Identity: এন্টারপ্রাইজ পরিবেশে on-premise AD-কে cloud IdP-এর সাথে federate করা হয়। AWS-এ IAM Identity Center, Azure-এ Entra Connect এই কাজ করে।

Passwordless Authentication: Microsoft Authenticator, Windows Hello, এবং passkeys-এর মাধ্যমে password ছাড়াই authentication সম্ভব হচ্ছে, যা phishing ও credential stuffing প্রায় অসম্ভব করে তোলে।

Authorization-এর সবচেয়ে গুরুত্বপূর্ণ নীতি হলো Principle of Least Privilege (PoLP)—কোনো identity-কে তার প্রয়োজনীয় কাজের জন্য ন্যূনতম permission দেওয়া।

RBAC (Role-Based Access Control): ব্যবহারকারীর ভূমিকার উপর ভিত্তি করে অ্যাক্সেস দেওয়া হয়। উদাহরণ: Database Administrator-কে ডাটাবেসে full access, কিন্তু compute resource-এ কোনো access নেই।

ABAC (Attribute-Based Access Control): ব্যবহারকারী, রিসোর্স এবং পরিবেশের attribute-এর ভিত্তিতে অ্যাক্সেস নির্ধারিত হয়। AWS-এ tag-based authorization এর একটি উদাহরণ—কেউ শুধু সেই EC2 instance-এ অ্যাক্সেস পাবে যার Department=Finance tag আছে।

PBAC (Policy-Based Access Control): Open Policy Agent (OPA) ব্যবহার করে centralized policy management করা হয়, যা Kubernetes এবং microservices পরিবেশে জনপ্রিয়।

একটি ভালো AWS IAM policy-এর উদাহরণ:

{
  "Version": "2012-10-17",
  "Statement": [{
    "Effect": "Allow",
    "Action": ["s3:GetObject"],
    "Resource": "arn:aws:s3:::company-data/*",
    "Condition": {
      "IpAddress": {"aws:SourceIp": "203.0.113.0/24"},
      "Bool": {"aws:MultiFactorAuthPresent": "true"}
    }
  }]
}

এই policy শুধু নির্দিষ্ট IP থেকে এবং MFA verified ব্যবহারকারীকে S3 object পড়ার অনুমতি দেয়।

মানুষ ছাড়াও ক্লাউডে অসংখ্য machine identity রয়েছে—application, container, Lambda function, CI/CD pipeline। এদের জন্য static access key ব্যবহার বিপজ্জনক কারণ এসব key সহজেই Git repository-তে accidentally commit হয়ে যায়।

AWS IAM Roles for EC2/Lambda: static credential-এর পরিবর্তে temporary credential ব্যবহার করুন। Instance Metadata Service (IMDSv2) ব্যবহার করুন যা SSRF আক্রমণ প্রতিরোধ করে।

Workload Identity Federation: GCP এবং Azure-এ external workload (যেমন GitHub Actions) থেকে static key ছাড়াই ক্লাউডে অ্যাক্সেস পাওয়া যায় OIDC token exchange-এর মাধ্যমে।

Secrets Management: API key, database password ইত্যাদি AWS Secrets Manager, Azure Key Vault, বা HashiCorp Vault-এ সংরক্ষণ করুন। Automatic rotation enable করুন।

২০১৯ সালের Capital One ব্রিচে attacker একটি misconfigured WAF-এর সুযোগ নিয়ে SSRF আক্রমণ চালিয়ে EC2-এর IAM role-এর temporary credential চুরি করেছিল। সেই role-এর S3 bucket-এ অস্বাভাবিকভাবে বেশি permission ছিল, ফলে ১০ কোটির বেশি গ্রাহকের তথ্য চুরি হয়।

২০২২ সালের Uber ব্রিচে attacker একজন কন্ট্রাক্টরের credential চুরি করে MFA fatigue attack-এর মাধ্যমে ভেতরে ঢুকেছিল। এরপর একটি PowerShell script-এ hardcoded admin password পেয়ে privileged accounts compromise করে।

২০২৩ সালের MGM Resorts attack-এ social engineering-এর মাধ্যমে IT helpdesk-কে প্রতারিত করে MFA reset করানো হয়েছিল, ফলে attacker Okta-তে admin access পায়। এই ঘটনাগুলো দেখায় যে IAM-এর প্রযুক্তিগত দিকের পাশাপাশি process ও training-ও সমান গুরুত্বপূর্ণ।

Privileged account সবচেয়ে আকাঙ্ক্ষিত লক্ষ্য attacker-এর কাছে। তাই এদের বিশেষ সুরক্ষার প্রয়োজন।

Just-in-Time (JIT) Access: Azure PIM (Privileged Identity Management) বা AWS IAM Identity Center-এ temporary elevation feature ব্যবহার করুন। কেউ যখন admin role চায়, তখন approval workflow-এর পর শুধু নির্দিষ্ট সময়ের জন্য access দেওয়া হয়।

Break-Glass Account: জরুরি পরিস্থিতির জন্য একটি বিশেষ account রাখুন যা সাধারণত disabled থাকে এবং hardware MFA দিয়ে protected।

Privileged Access Workstation (PAW): Admin কাজের জন্য dedicated, hardened workstation ব্যবহার করুন যেখানে ইন্টারনেট ব্রাউজিং বা email allowed নয়।

IAM সঠিকভাবে কনফিগার করার পরও নিয়মিত মনিটরিং অপরিহার্য।

AWS CloudTrail ও Access Analyzer: CloudTrail সমস্ত API call লগ করে এবং Access Analyzer unused permissions, external access, এবং policy validation করে।

Azure Sentinel ও Identity Protection: Risky sign-in, impossible travel, এবং leaked credential detect করে।

Permission Boundary ও SCP: AWS-এ Service Control Policy (SCP) দিয়ে account-level guardrail সেট করুন। Permission Boundary দিয়ে maximum permission সীমিত করুন।

Continuous Access Evaluation: Microsoft-এর CAE feature session token revoke করতে পারে যদি risk detect হয়, যা stolen token-এর ব্যবহার কমায়।

Cloud IAM-এর নিরাপত্তা নিশ্চিত করতে নিচের অনুশীলনগুলো অনুসরণ করুন।

Zero Standing Privilege: কাউকেই স্থায়ীভাবে privileged access দেবেন না। সব access JIT হওয়া উচিত।

MFA Everywhere: সব user account, বিশেষ করে privileged-এ MFA বাধ্যতামূলক করুন। Phishing-resistant MFA (FIDO2) ব্যবহার করুন।

Regular Access Review: ত্রৈমাসিকভাবে সব role ও permission পর্যালোচনা করুন। Unused accounts disable করুন।

Root Account Protection: AWS root account বা Azure Global Admin শুধু একেবারে প্রয়োজনীয় ক্ষেত্রে ব্যবহার করুন। Hardware MFA enable করুন এবং credential সুরক্ষিত স্থানে রাখুন।

Infrastructure as Code: Terraform বা CloudFormation দিয়ে IAM policy manage করুন। এতে version control, peer review এবং automated testing সম্ভব হয়।

IAM Policy Testing: AWS IAM Policy Simulator বা Open Policy Agent দিয়ে policy deploy করার আগে test করুন।

Logging ও Alerting: সব IAM change-এ alert সেট করুন। নতুন user creation, policy modification, বা root account login সাথে সাথে notify হওয়া উচিত।