Cloud IAM: least privilege, role ও access key সুরক্ষা

IAM (identity and access management) ঠিক করে আপনার cloud account-এর কোন resource-এ কে কী করতে পারবে। এটি সবকিছুর সামনের দরজা, তাই দুর্বল IAM অন্য সব নিরাপত্তা নষ্ট করে।

মূল ধারণা

• Identity: একজন মানুষ (user) বা প্রোগ্রাম (service account বা role)।
• Authentication: আপনি কে তা প্রমাণ (পাসওয়ার্ড ও MFA, বা token)।
• Authorization: তারপর কী করার অনুমতি, policy দিয়ে সংজ্ঞায়িত।
• Policy: একটি নথি যা resource-এ কাজ অনুমতি বা নিষিদ্ধ করে, ঐচ্ছিকভাবে শর্তসহ।
• Role: অনুমতির সেট যা একটি identity স্থায়ী পাসওয়ার্ড বা key ছাড়া সাময়িকভাবে ধারণ করতে পারে।

নাম provider ভেদে আলাদা (AWS IAM, Google Cloud IAM, Azure RBAC), তবে ধারণা একই।

Least privilege

প্রতিটি identity-কে তার কাজের জন্য ন্যূনতম অনুমতি দিন, তার বেশি নয়।

খারাপ: "চালু করতে" সব resource-এ সব কাজের অনুমতি দেওয়া policy (* on *)।

ভালো: নির্দিষ্ট resource-এ শুধু দরকারি কাজ অনুমতি:

{
  "Effect": "Allow",
  "Action": ["s3:GetObject", "s3:PutObject"],
  "Resource": "arn:aws:s3:::my-app-uploads/*"
}

(AWS ধাঁচ দেখানো হলো। অন্য cloud-এ ভিন্ন syntax, ধারণা একই।)

সেখানে পৌঁছানোর টিপ:

• বড় করে শুরু না করে সংকীর্ণ দিয়ে শুরু করুন এবং কিছু প্রত্যাখ্যাত হলে অনুমতি যোগ করুন।
• ব্যক্তিগতভাবে policy না বসিয়ে group বা role ব্যবহার করুন।
• অব্যবহৃত অনুমতি খুঁজে সরাতে provider-এর access analyser টুল ব্যবহার করুন।
• সংবেদনশীল কাজের জন্য শর্ত পছন্দ করুন, যেমন network সীমা বা MFA বাধ্যতামূলক।

মানুষের অ্যাকাউন্ট সুরক্ষা

• Root বা owner অ্যাকাউন্ট তালাবদ্ধ করুন। MFA চালু করুন, তার জন্য access key বানাবেন না, বিরল জরুরি অবস্থার জন্য রাখুন।
• সবার জন্য MFA বাধ্যতামূলক করুন, আদর্শভাবে hardware key বা authenticator app।
• সম্ভব হলে identity provider-এর সাথে single sign-on ব্যবহার করুন, যাতে চলে যাওয়া কর্মীর access এক জায়গাতেই যায়।
• production ও development-এর জন্য আলাদা account বা project রাখুন।

দীর্ঘস্থায়ী access key এড়ান

ফাইলে রাখা স্থায়ী access key cloud account দখলের সবচেয়ে প্রচলিত উপায়ের একটি। Key ফাঁস হয় Git repository, log, chat বার্তা, ল্যাপটপ ও build system দিয়ে।

• অস্থায়ী credential-সহ role পছন্দ করুন: server বা function একটি role পায় এবং স্বয়ংক্রিয়ভাবে স্বল্পস্থায়ী credential পায়, কিছু সংরক্ষিত থাকে না।
• CI/CD-র জন্য workload identity বা OIDC federation ব্যবহার করুন, যাতে pipeline কোনো সংরক্ষিত secret ছাড়া অস্থায়ী access পায়।
• Key ব্যবহার করতেই হলে: সংকীর্ণ scope দিন, ঘুরিয়ে বদলান, কখনো commit করবেন না, অব্যবহৃত key মুছুন।
• Repository-তে secret scanner চালান এবং provider-এর key-ফাঁস alert চালু করুন।

Key ফাঁস হলে breach ধরুন: সঙ্গে সঙ্গে disable করুন, সে কী করেছে audit log-এ দেখুন, সংশ্লিষ্ট secret বদলান, তারপর কীভাবে ফাঁস হলো তদন্ত করুন।

Secret ব্যবস্থাপনা

Database পাসওয়ার্ড ও API key রাখুন secrets manager-এ, কোড বা Git-এর environment ফাইলে নয়। অ্যাপকে শুধু দরকারি secret পড়ার অনুমতি দিন এবং নির্ধারিত সময়ে বদলান।

Audit ও monitor

• সব region-এ audit logging (CloudTrail বা Cloud Audit Logs-এর মতো) চালু করুন এবং log সুরক্ষিত জায়গায় পাঠান।
• ঝুঁকিপূর্ণ ঘটনায় alert দিন: root login, policy বদল, নতুন access key, বন্ধ করা logging, এবং অস্বাভাবিক region বা সময়।
• কার access আছে নিয়মিত পর্যালোচনা করুন এবং পুরোনো অ্যাকাউন্ট সরান।

সাধারণ ভুল

• সর্বত্র wildcard অনুমতি।
• ভাগ করা অ্যাকাউন্ট ও পাসওয়ার্ড।
• MFA না থাকা, বিশেষত admin অ্যাকাউন্টে।
• Repository বা container image-এ access key।
• একই account-এ production ও development।
• মানুষের ভূমিকা বদলের পর অনুমতি পর্যালোচনা না করা।

মূল কথা: দীর্ঘস্থায়ী key-র বদলে role ও অস্থায়ী credential ব্যবহার করুন, যা কাজ করে তার ন্যূনতম privilege দিন, MFA বাধ্যতামূলক করুন, secret রাখুন manager-এ, এবং audit log ও alert রাখুন যাতে অপব্যবহার টের পান।

---

Networking ও Cloud সিরিজ, পর্ব ২ (cloud-এর গোড়া): 3 নম্বর (মোট 5)। আগের লেখা: VPC নকশা: subnet, routing ও security group.