IAM ও ক্লাউড মিসকনফিগারেশন

১ · IAM কী — এবং কেন এটি সবচেয়ে গুরুত্বপূর্ণ ক্লাউড কন্ট্রোল

IAMIdentity and Access Managementএকটি ক্লাউড প্ল্যাটফর্মের সেই সিস্টেম যা নির্ধারণ করে কোন identity (ইউজার, সার্ভিস, অ্যাপ্লিকেশন) কোন রিসোর্সে কোন action চালাতে পারবে। হলো ক্লাউডের সেই স্তর যা ঠিক করে দেয় — কে (identity: একজন ইউজার, একটি সার্ভিস অ্যাকাউন্ট, একটি অ্যাপ্লিকেশন) কী করতে পারবে (action: read, write, delete...) কোন রিসোর্সে (একটি নির্দিষ্ট স্টোরেজ বাকেট, একটি ডেটাবেস, একটি সার্ভার)। L51-এ আমরা শিখেছি Shared Responsibility Model-এ IAM কনফিগারেশন সম্পূর্ণভাবে কাস্টমারের দায়িত্ব — ক্লাউড প্রোভাইডার এটি আপনার হয়ে ঠিক করে দেয় না।

এই কারণেই বাস্তব ক্লাউড ব্রিচের বিশ্লেষণে বারবার একই প্যাটার্ন দেখা যায়: আক্রমণকারী কোনো জটিল zero-day এক্সপ্লয়েট ব্যবহার করেনি — বরং একটি ভুলভাবে কনফিগার করা IAM পলিসি বা পাবলিকলি-এক্সপোজড রিসোর্স খুঁজে পেয়েছে। IAM সিকিউর রাখা মানে জটিল ক্রিপ্টোগ্রাফি নয় — এটি মূলত সঠিক ডিসিপ্লিন ও অডিট-এর ব্যাপার।

২ · Least Privilege — ক্লাউড রোলে প্রয়োগ

L31-এ আমরা Principle of Least PrivilegeLeast Privilegeপ্রতিটি অ্যাকাউন্ট/প্রসেসকে শুধুমাত্র তার কাজের জন্য প্রয়োজনীয় ন্যূনতম অনুমতি দেওয়া — এর বেশি কিছু নয়। নীতি দেখেছিলাম ফাইল-পারমিশনের প্রেক্ষাপটে। ক্লাউডে এই একই নীতি IAM পলিসিতে প্রয়োগ হয়: একটি ব্যাকআপ সার্ভিসের রোলকে শুধু নির্দিষ্ট বাকেটে read/write অনুমতি দিন — পুরো অ্যাকাউন্টের সব রিসোর্সে সব action করার অনুমতি নয়।

৩ · একটি IAM পলিসি সেট অডিট করা

নিচের toy উদাহরণে চারটি simulated IAM পলিসি আছে — এদের কোনোটিই কোনো বাস্তব ক্লাউড অ্যাকাউন্টের সাথে সংযুক্ত নয়, এগুলো শুধু in-memory Python dictionary। audit_policy() ফাংশনটি প্রতিটি পলিসির actions ও resources লিস্টে "*" (wildcard) আছে কি না পরীক্ষা করে একটি ফাইন্ডিংস লিস্ট রিটার্ন করে — বাস্তব ক্লাউড সিকিউরিটি টুলিং (যেমন AWS IAM Access Analyzer) ঠিক এই একই ধরনের লজিক অনেক বড় স্কেলে চালায়।

policies = {
    "read-only-reports": {
        "actions": ["s3:GetObject"],
        "resources": ["arn:aws:s3:::company-reports/*"],
    },
    "backup-service": {
        "actions": ["s3:GetObject", "s3:PutObject"],
        "resources": ["arn:aws:s3:::company-backups/*"],
    },
    "legacy-admin-role": {
        "actions": ["*"],
        "resources": ["*"],
    },
    "deploy-bot": {
        "actions": ["ec2:StartInstances", "ec2:StopInstances"],
        "resources": ["*"],
    },
}

def audit_policy(policy):
    findings = []
    if "*" in policy["actions"]:
        findings.append("wildcard ACTION (\"*\") — যেকোনো action চালানোর অনুমতি")
    if "*" in policy["resources"]:
        findings.append("wildcard RESOURCE (\"*\") — যেকোনো resource-এ প্রয়োগযোগ্য")
    return findings

print("IAM পলিসি অডিট রিপোর্ট")
print("-" * 42)
for name, policy in policies.items():
    findings = audit_policy(policy)
    if findings:
        print(f"[ঝুঁকিপূর্ণ] {name}")
        for f in findings:
            print(f"   -> {f}")
    else:
        print(f"[নিরাপদ]    {name} — সঠিকভাবে স্কোপড (scoped)")
    print()

৪ · প্রতিরক্ষা চেকলিস্ট

• প্রতিটি পলিসিতে নির্দিষ্ট action ও resource ARN লিখুন — কখনো "সাময়িক সুবিধার জন্য" wildcard নয়।
• নিয়মিত অ্যাক্সেস রিভিউ চালান — কোনো রোল/ক্রেডেনশিয়াল দীর্ঘদিন অব্যবহৃত থাকলে তা revoke করুন।
• স্টোরেজ বাকেটে "block public access" ডিফল্টভাবে চালু রাখুন — শুধু স্পষ্ট প্রয়োজনে সুনির্দিষ্টভাবে খুলুন।
• স্বয়ংক্রিয় IAM-অডিট টুলিং ব্যবহার করুন — ম্যানুয়াল রিভিউ স্কেলে ভুল করে, স্বয়ংক্রিয় স্ক্যানিং প্রতিটি পলিসি ধারাবাহিকভাবে পরীক্ষা করে (L54-এ DevSecOps পাইপলাইনে এই ধরনের স্বয়ংক্রিয় গেট আমরা বিস্তারিত দেখব)।