Resource Delegation: ক্লাউড পরিবেশে অ্যাক্সেস কন্ট্রোলের দুর্বলতা এবং রিসোর্স হাইজ্যাকিং!

ক্লাউডে delegation বলতে বোঝায় একটি identity-কে অন্য একটি identity-এর resource অ্যাক্সেস করার অনুমতি দেওয়া। AWS-এ এটি প্রধানত দুটি pattern-এ ঘটে: Identity-based policies (একটি user বা role-এর সাথে attached) এবং Resource-based policies (একটি resource যেমন S3 bucket-এর সাথে attached যা বলে কোন principal এটি অ্যাক্সেস করতে পারবে)।

Azure-এ Azure RBAC (Role-Based Access Control) এবং Azure AD অ্যাপ্লিকেশন এর মাধ্যমে delegation ঘটে। Managed Identities, OAuth 2.0 consent এবং subscription-level role assignment—সবগুলো delegation pattern।

GCP-তে IAM service account, service account impersonation এবং Workload Identity Federation প্রধান delegation প্রক্রিয়া। প্রতিটি প্ল্যাটফর্মে delegation-এর কিছু সাধারণ থিম আছে: trust relationship, scoped permission, এবং policy evaluation logic।

সমস্যা শুরু হয় যখন এই delegation overly permissive হয়, transitive trust সঠিকভাবে restrict করা হয় না, বা attacker-এর নিয়ন্ত্রণাধীন একটি resource অন্য সংস্থার মূল্যবান অ্যাক্সেস পায়।

AWS Identity and Access Management হলো সবচেয়ে জটিল IAM সিস্টেমগুলোর একটি, যেখানে privilege escalation-এর বহু paths রয়েছে।

iam:PassRole Abuse: এটি সম্ভবত সবচেয়ে সাধারণ AWS privilege escalation vector। যদি একজন user-এর কাছে iam:PassRole permission থাকে এবং একই সাথে একটি service launch করার permission থাকে (যেমন lambda:CreateFunction, ec2:RunInstances), তাহলে তারা একটি high-privileged role পাস করে সেই role-এর অধিকার অর্জন করতে পারে। উদাহরণ: একজন junior developer-এর কাছে শুধু Lambda function তৈরির অধিকার আছে, কিন্তু সে যদি AdministratorAccess role পাস করতে পারে, তাহলে effectively সে admin।

AssumeRole Confusion: একটি IAM role-এর trust policy ভুলভাবে configured হলে যেকোনো AWS account থেকে assume করা যায়। "Principal": "*" বা "Principal": {"AWS": "*"}—এই ধরনের misconfiguration সম্পূর্ণ public role তৈরি করে। যদি external_id condition না থাকে, তাহলে confused deputy attack সম্ভব।

Cross-Account Resource Sharing: S3 bucket policy যা একটি partner account-কে অ্যাক্সেস দেয়, কিন্তু সেই partner account compromise হলে আক্রমণকারী আপনার resource-এও অ্যাক্সেস পায়। AWS Lake Formation, RAM (Resource Access Manager), এবং KMS key policy সব ক্ষেত্রেই এই ঝুঁকি বিদ্যমান।

Lambda Resource Policy: যদি একটি Lambda function-এর resource policy "*" principal-কে invoke অনুমোদন করে, তাহলে যেকোনো AWS account সেই function invoke করতে পারে। যদি function-এর execution role-এ sensitive permission থাকে, এটি একটি পূর্ণাঙ্গ privilege escalation।

SNS/SQS Subscription: SNS topic বা SQS queue-এর policy ভুলভাবে কনফিগার করা হলে cross-account subscription সম্ভব হয়, যা sensitive notification বা message লিকের কারণ হতে পারে।

Azure-এ Resource Manager এবং Azure AD আলাদা কিন্তু সংযুক্ত systems। delegation এই দুই layer-এই ঘটে।

Service Principal Abuse: একটি Azure AD application-কে যদি Subscription Owner role দেওয়া হয়, তাহলে সেই application-এর credentials (client secret বা certificate) compromise হলে পুরো subscription হাতছাড়া। অনেক DevOps automation এই pattern ব্যবহার করে, তাই service principal credentials-এর secure storage অত্যন্ত গুরুত্বপূর্ণ।

Managed Identity Misuse: Azure VM, App Service, বা Function-এ Managed Identity attach করা হয়। যদি সেই compute resource compromise হয়, attacker IMDS (Instance Metadata Service) endpoint থেকে token পেয়ে যায় এবং সেই identity-এর সব অধিকার পায়। সাধারণত Managed Identity-গুলোকে শুধু necessary permission দেওয়া উচিত, কিন্তু production-এ প্রায়শই Contributor বা Owner role দেওয়া হয়।

Owner Role Assignment: একটি গভীর সমস্যা হলো Azure RBAC-তে Owner role-এর কাছে Microsoft.Authorization/*/Write permission আছে, অর্থাৎ Owner অন্যদের role assign করতে পারে। যদি একটি কম privileged service principal-এর কাছে Owner role থাকে একটি resource group-এ, সেই principal নিজের জন্য আরো অধিকার assign করতে পারে।

Consent Phishing: Multi-tenant Azure AD application-এ user বা admin consent-এর মাধ্যমে delegation ঘটে। আক্রমণকারীরা একটি malicious application তৈরি করে যা broad permission (যেমন Mail.Read, Files.ReadWrite.All) চায় এবং phishing-এর মাধ্যমে user-দের consent দিতে বাধ্য করে। একবার consent হলে, application-টি stealthily ডেটা exfiltrate করতে পারে।

Conditional Access Bypass: যদি একটি subscription বা service principal-এ Conditional Access policy strictly enforced না হয়, MFA bypass সম্ভব।

GCP-এর IAM model আপাতদৃষ্টিতে সরল, কিন্তু এতেও সূক্ষ্ম দুর্বলতা রয়েছে।

Service Account Impersonation: যদি একজন user-এর কাছে iam.serviceAccountTokenCreator role থাকে একটি high-privileged service account-এ, তারা সেই account impersonate করে privilege escalate করতে পারে। gcloud auth print-access-token --impersonate-service-account= কমান্ড দিয়ে এটি ট্রিভিয়াল।

Service Account Key Creation: iam.serviceAccountKeyAdmin role থাকলে একজন user যেকোনো service account-এর জন্য নতুন key তৈরি করতে পারে এবং সেই key দিয়ে সরাসরি authenticate করতে পারে।

Workload Identity Federation Misuse: এটি একটি modern feature যা external identity provider (যেমন GitHub Actions, GitLab CI) থেকে service account impersonate করার অনুমতি দেয়। যদি pool বা provider configuration overly permissive হয় (যেমন attribute.repository=* allow করা), যেকোনো GitHub user আপনার GCP environment-এ অ্যাক্সেস পেতে পারে।

Project-Level Permission Inheritance: GCP-তে organization → folder → project → resource এই hierarchy-তে permission inherited হয়। একটি organization-level role যেকোনো child resource-এ প্রয়োগ হয়।

কিছু বাস্তব scenarios যেখানে delegation দুর্বলতা resource hijacking-এর দিকে নিয়ে যায়:

Cryptomining Hijacking: Attackers compromised credentials দিয়ে massive EC2 বা VM instances চালু করে cryptocurrency mining করে। ক্ষতিগ্রস্ত সংস্থা মাসিক bills-এ ছয় বা সাত অঙ্কের অপ্রত্যাশিত খরচ দেখতে পায়।

Data Exfiltration: একটি S3 bucket-এর resource policy যা cross-account read অনুমোদন করে এবং সেই account compromise হলে—সমস্ত sensitive ডেটা leaked।

Spam এবং Phishing Infrastructure: AWS SES বা SendGrid-এর অপব্যবহার করে cloud-hosted phishing campaigns চালানো।

Lateral Movement to On-Premise: একটি hybrid environment-এ Azure AD Connect synced account compromise on-premise Active Directory পর্যন্ত পৌঁছাতে পারে।

ক্লাউড পরিবেশে delegation-related আক্রমণ শনাক্ত করতে বিশেষ approach প্রয়োজন।

CloudTrail/Activity Log Monitoring: AWS CloudTrail-এ AssumeRole, PassRole, CreatePolicy ইভেন্ট নিয়মিত মনিটর করতে হবে। Azure Activity Log এবং Azure AD Audit Log-এ অস্বাভাবিক role assignment বা service principal creation watch করা।

IAM Analyzer Tools: AWS IAM Access Analyzer external access শনাক্ত করে। Azure-এ Microsoft Defender for Cloud এবং Entra Permissions Management (formerly CloudKnox) over-privileged identities খুঁজে বের করে। GCP-এ Recommender এবং Policy Analyzer ব্যবহার করা হয়।

Open-Source Tools: PMapper AWS IAM policy graph তৈরি করে privilege escalation path বিশ্লেষণ করে। Pacu AWS pentesting framework। MicroBurst এবং ROADtools Azure-এর জন্য। ScoutSuite এবং Prowler multi-cloud auditing।

Anomaly Detection: GuardDuty (AWS), Microsoft Defender for Cloud, Chronicle Security Operations (GCP)—সবই behavioral anomaly শনাক্ত করে যেমন unusual API call from new geography, dormant service principal-এর হঠাৎ ব্যবহার।

ক্লাউড delegation-এর নিরাপত্তা জোরদার করতে কিছু মৌলিক নীতি অনুসরণ করতে হবে।

Least Privilege Principle: প্রতিটি identity-এর শুধু minimum necessary permission থাকা উচিত। AWS-এ wildcard permissions (*:*) সম্পূর্ণ পরিহার করা। Service-specific এবং resource-specific scoping।

Conditional Permissions: IAM policy-তে condition keys ব্যবহার—যেমন AWS-এ aws:SourceIp, aws:SourceVpce, aws:MultiFactorAuthPresent। Azure-এ Conditional Access policy। GCP-এ IAM Conditions।

External ID for Cross-Account Trust: AWS-এ যখন third-party-কে অ্যাক্সেস দেন, sts:ExternalId condition বাধ্যতামূলক করুন। এটি confused deputy attack প্রতিরোধ করে।

Avoid Long-Lived Credentials: AWS Access Key, Azure service principal secret, GCP service account key-এর মতো long-lived credentials এর পরিবর্তে workload identity, OIDC federation এবং short-lived token ব্যবহার।

Service Control Policies (SCP) এবং Management Group Policy: AWS Organizations SCP এবং Azure Management Group-এ guardrail policy দিয়ে এমন কাজ ব্লক করা যা কোনো child account/subscription-এ allow হওয়া উচিত নয়—যেমন root user creation, region restriction।

Multi-Factor Authentication: সকল privileged role-এ MFA বাধ্যতামূলক, FIDO2-based hardware key পছন্দনীয়।

Privileged Access Management: AWS-এ IAM Identity Center-এর permission set, Azure-এ PIM (Privileged Identity Management) দিয়ে JIT (Just-In-Time) access।

Regular Access Review: ত্রৈমাসিক access review—কোনো dormant account, unused role, এবং over-privileged identity শনাক্ত এবং remediate করা।

Infrastructure as Code Scanning: Terraform, CloudFormation, ARM template-এ Checkov, tfsec, KICS দিয়ে নিরাপত্তা scanning। CI/CD pipeline-এ এই গুলো integrate করা।

Secret Management: AWS Secrets Manager, Azure Key Vault, GCP Secret Manager—সব credential এই গুলোতে rotate করা।