Governance — multi-account, landing zone, tag, quota আর compliance

১ · এক account-এ সব রাখা কেন ভেঙে পড়ে

একটি কাল্পনিক অনলাইন বাজার অ্যাপের গল্প ধরি। শুরুতে তিনজন প্রকৌশলী, একটি cloud account. Test server, production database, ছবি রাখার bucket, সব এক জায়গায়। কাজ দ্রুত চলে, কারও কোনো সমস্যা নেই।

তিন বছর পর দলে চল্লিশজন। এখন একই account-এ যা ঘটছে:

• ভুলের ঢেউ: একজন intern test পরিষ্কার করতে script চালালেন, আর একই account-এর production VM-ও মুছে গেল।
• চাবির ঝুঁকি: CI-এর একটি access key ফাঁস হলো। সেই key দিয়ে সবকিছুতে হাত দেওয়া যায়, কারণ সব একই account-এ।
• বিলের ধাঁধা: মাসের বিল $৪০,০০০. অর্থ বিভাগ জানতে চায় কোন দলের কত। কেউ বলতে পারেন না।
• সীমার লড়াই: Data দলের একটি batch job পুরো quota খেয়ে ফেলল। ঠিক তখনই production-এর autoscaling নতুন VM পেল না।
• প্রমাণের অভাব: একটি কার্ড পেমেন্ট পার্টনার জানতে চান, cardholder data কে কে ছুঁতে পারে। উত্তর দাঁড়ায় “প্রায় সবাই”।

লক্ষ করুন, এর কোনোটিই কারিগরি বাগ নয়। এগুলো কাঠামোর সমস্যা। এই কাঠামোর শাস্ত্রটিকেই বলে cloud governance: কে কী করতে পারবে, খরচ কার ঘাড়ে যাবে, কোন নিয়ম কীভাবে মানা হবে আর তার প্রমাণ কোথায় থাকবে, এসবের ব্যবস্থা।

Multi-account কৌশলের মূল যুক্তি হলো blast radius ছোট রাখা। পর্ব ৫-এ zone আর region দিয়ে যন্ত্রের ব্যর্থতার পরিধি কমিয়েছিলাম। Account একই কাজ করে মানুষের ভুল, চুরি যাওয়া পরিচয় আর খরচের জন্য। এক account-এর ভেতরে IAM দিয়েও ভাগ করা যায়, কিন্তু সেটি একই ঘরের ভেতরে পর্দা টানার মতো। একটি ভুল policy পর্দা সরিয়ে দিতে পারে। অন্য account থেকে ঢুকতে হলে স্পষ্ট অনুমতি লাগে, সেটি দেয়ালে দরজা কাটার মতো।

২ · Account-এর গাছ — organization, OU, subscription, project

অনেক account থাকলে তাদের একটি মালিকানার গাছে সাজানো হয়। ওপরে থাকে organization, যার নিচে দলে দলে account. গাছের ওপরের ডালে কোনো নিয়ম বসালে তা নিচের সব ডালে নামে। একে বলে resource hierarchy. এতে একশো account-এ আলাদা করে একই নিয়ম বসাতে হয় না।

নিচের ছবিটি একটি প্রচলিত নকশা। নাম আর আকার প্রতিষ্ঠানভেদে বদলায়, ভাবনাটি মোটামুটি এক।

প্রতিটি account-এর কাজ আলাদা:

প্রথম সতর্কতা: management account-এ কিছু চালাবেন না। AWS-এ SCP management account-এর ওপর খাটে না, তাই সেখানে workload রাখা মানে সবচেয়ে ক্ষমতাবান জায়গাটিই সবচেয়ে কম পাহারায় রাখা।

তিন provider-এ একই ভাবনা

Environment আর blast radius-এর ভাগ

কীভাবে ভাগ করবেন? সবচেয়ে প্রচলিত উত্তর দুই অক্ষে: দল আর environment. যেমন payments-dev, payments-prod. একটি environment-এর ভুল অন্যটিতে যায় না, একটি দলের ভুল অন্য দলে যায় না। PCI-এর মতো বিশেষ ডেটা থাকলে তার জন্য আলাদা account, যাতে অডিটের আওতা সেখানেই সীমিত থাকে। এখানে সীমাও আছে। প্রতিটি microservice-এ একটি করে account নিলে network আর পরিচয়ের জঞ্জাল বাড়ে। মোটামুটি নিয়ম: account-এর দেয়াল ততটুকুই টানুন, যতটুকু আলাদা মালিক, আলাদা ঝুঁকি বা আলাদা খরচের হিসাব চায়। পর্ব ৭-এর Conway-র কথাটি এখানেও খাটে: account-এর সীমা প্রায়ই দলের সীমার ছায়া।

৩ · Landing zone আর account vending

Landing zone হলো কোড দিয়ে বানানো একটি প্রস্তুত multi-account পরিবেশ: organization-এর গাছ, পরিচয়, log, guardrail, network আর budget, সব শুরু থেকেই ঠিক করা। AWS Control Tower, Azure landing zones আর Google Cloud-এর enterprise foundations blueprint এই ভাবনার তিনটি উদাহরণ। অনেকে Terraform দিয়ে নিজের মতো বানান। কোনোটি অপরিহার্য নয়, ভাবনাটিই আসল।

Landing zone থাকলে নতুন account বানানো একটি যান্ত্রিক কাজ হয়ে যায়। একে বলে account vending: ভেন্ডিং মেশিনে টাকা দিলে যেমন নির্দিষ্ট প্যাকেট বের হয়, তেমনি একটি অনুরোধ দিলে নিয়ম মানা account বের হয়। হাতে বানালে প্রতিটি account একটু আলাদা হয়, কিছু log বন্ধ থাকে, কেউ network ভুলে যান। একই জিনিস একশোবার হাতে করলে drift অবধারিত।

অনুরোধটি সাধারণত Git-এ একটি ছোট ফাইল। নিচের YAML একটি কাল্পনিক বিন্যাস, কোনো নির্দিষ্ট টুলের নয়:

account: payments-prod
ou: workloads/prod
owner_team: payments
owner_email: payments-lead@example.com
cost_center: cc-4102
data_class: confidential
budget_usd_monthly: 800
regions:
  - ap-south-1
  - ap-southeast-1
vpc:
  size: /20
  connect_to_hub: true

এবার এই অনুরোধ থেকে একটি account জন্ম নেওয়ার পথ দেখুন। Payments দলের জন্য নতুন production account লাগবে:

৪ · Guardrail — আগে আটকানো, পরে ধরা

ফ্লাইওভারের পাশের রেলিং গাড়ি চালায় না, শুধু গাড়িকে পড়ে যাওয়া থেকে বাঁচায়। Guardrail তেমনি কাউকে কিছু করার অনুমতি দেয় না, শুধু একটি সীমা টানে যার বাইরে কেউ যেতে পারবেন না। Developer-এর admin অধিকার থাকলেও সেই সীমা থাকে।

একটি SCP দেখতে কেমন

AWS-এর SCP দিয়ে উদাহরণ দিই। Azure Policy আর Google-এর Organization Policy একই লক্ষ্যে কাজ করে, লেখার ধরন আলাদা। JSON-এর গঠন IAM policy-র মতো। নিয়ম মূল্যায়নের পুরো হিসাব পর্ব ৩২-এ।

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "DenyOutsideAllowedRegions",
      "Effect": "Deny",
      "NotAction": ["iam:*", "organizations:*", "route53:*", "cloudfront:*", "support:*", "sts:*"],
      "Resource": "*",
      "Condition": {
        "StringNotEquals": { "aws:RequestedRegion": ["ap-south-1", "ap-southeast-1"] }
      }
    },
    {
      "Sid": "DenyInstanceWithoutTeamTag",
      "Effect": "Deny",
      "Action": "ec2:RunInstances",
      "Resource": "arn:aws:ec2:*:*:instance/*",
      "Condition": { "Null": { "aws:RequestTag/team": "true" } }
    }
  ]
}

প্রথম নিয়মটি পড়ুন: অনুরোধের region তালিকায় না থাকলে সব কাজ নিষেধ, শুধু NotAction-এর কাজগুলো বাদে। ওই বাদের তালিকাটি জরুরি। IAM আর DNS-এর মতো global service-এর API একটি নির্দিষ্ট region দিয়ে যায়। তালিকা না দিলে region নিয়মে এগুলোও আটকে যাবে, আর হঠাৎ দেখবেন লগইনের কাজেও সমস্যা হচ্ছে। দ্বিতীয় নিয়মটি বলছে, team tag ছাড়া VM তৈরির অনুরোধ নিষেধ। বাদের তালিকাটি এখানে শুধু নমুনা। আপনার ব্যবহৃত service অনুযায়ী তা যাচাই করতে হবে, AWS-এর হালনাগাদ উদাহরণ দেখে।

এবার একটি ছোট evaluator চালিয়ে দেখুন। OU-র গাছ ধরে নিয়ম সংগ্রহ হয়, প্রতিটি প্রস্তাবিত কাজ পরীক্ষা হয়, আর শেষে IAM-এর উত্তরও লাগে।

// Guardrail evaluator: walk from the account's OU up to the root.
// A guardrail can only deny. IAM must still allow the action.
const above = { prod: 'workloads', dev: 'workloads', workloads: 'root', sandbox: 'root', root: null };
const chain = ou => (ou ? [ou, ...chain(above[ou])] : []);
const okRegion = ['ap-south-1', 'ap-southeast-1'];

const rules = [
  { id: 'deny-region',  at: 'root',      mode: 'deny',   hit: a => !okRegion.includes(a.region) },
  { id: 'require-tags', at: 'workloads', mode: 'deny',   hit: a => !(a.tags.includes('team') && a.tags.includes('env')) },
  { id: 'no-public',    at: 'prod',      mode: 'deny',   hit: a => a.public === true },
  { id: 'big-vm-note',  at: 'dev',       mode: 'detect', hit: a => (a.vcpu || 0) > 16 },
];

const both = ['team', 'env'];
const proposed = [
  { what: 'vm-a',     ou: 'dev',     region: 'ap-south-1',     tags: both,     iam: true },
  { what: 'vm-b',     ou: 'dev',     region: 'us-east-1',      tags: both,     iam: true },
  { what: 'vm-c',     ou: 'prod',    region: 'ap-southeast-1', tags: ['team'], iam: true },
  { what: 'bucket-d', ou: 'prod',    region: 'ap-south-1',     tags: both,     iam: true, public: true },
  { what: 'vm-e',     ou: 'dev',     region: 'ap-south-1',     tags: both,     iam: true, vcpu: 32 },
  { what: 'vm-f',     ou: 'sandbox', region: 'ap-south-1',     tags: [],       iam: true },
  { what: 'vm-g',     ou: 'prod',    region: 'ap-south-1',     tags: both,     iam: false },
];

for (const a of proposed) {
  const hits = rules.filter(r => chain(a.ou).includes(r.at) && r.hit(a));
  const deny = hits.find(r => r.mode === 'deny');
  const notes = hits.filter(r => r.mode === 'detect').map(r => r.id);
  const verdict = deny ? `DENY  by ${deny.id} (set at ${deny.at})`
    : !a.iam ? 'DENY  no IAM allow'
    : 'ALLOW' + (notes.length ? `, finding: ${notes}` : '');
  console.log(a.what.padEnd(9), a.ou.padEnd(8), verdict);
}

এবার একই ঘটনা ধাপে ধাপে দেখি, যেমনটি একজন developer দেখেন। AI-এর দেওয়া একটি Terraform snippet-এ region রয়ে গেছে us-east-1:

৫ · Log আর security account — প্রমাণ যেন মোছা না যায়

কোনো অনুপ্রবেশকারী prod account-এর admin পরিচয় পেলে প্রথমে কী করবেন? পায়ের ছাপ মুছবেন। Log যদি সেই account-এই থাকে, তিনি সেটিও মুছতে পারবেন। তাই log রাখা হয় অন্য account-এ, যেখানে workload-এর পরিচয়ের কোনো লেখার বা মোছার অধিকার নেই।

• Log archive account: সব account-এর audit log (AWS CloudTrail, Azure Activity Log, Google Cloud Audit Logs), নানা সার্ভিসের log আর flow log এখানে জমে। Storage-এ object lock বা একই ধরনের ব্যবস্থা আর স্পষ্ট retention থাকে।
• Security account: সব account-এর finding এক পর্দায় আসে। নিরাপত্তা টুলের প্রশাসন management account থেকে এখানে দেওয়া হয়। একে অনেক provider-এ delegated admin বলে।
• Guardrail দিয়ে তালা: “কেউ audit log বন্ধ করতে পারবেন না”, “log bucket-এর policy বদলানো যাবে না”, এগুলো root-এর প্রথম দিকের নিয়ম। Log বন্ধ করার ঘটনা নিজেই একটি উচ্চ-অগ্রাধিকারের alert.

এর পেছনের নীতির নাম separation of duties: যিনি কাজ করেন আর যিনি সেই কাজের হিসাব রাখেন, তাঁরা এক হবেন না। ক্যাশিয়ার নিজের হিসাব নিজে অডিট করেন না। পর্ব ৩৪-এ audit log দিয়ে সন্দেহজনক কাজ ধরা দেখেছেন, আর পর্ব ৬৪-এ log পাঠানোর পাইপলাইন আর তার খরচ আসবে। পর্ব ২৪-এর cross-account copy-ও একই যুক্তির অংশ।

৬ · Tag — কার খরচ, কার দায়

গুদামঘরে হাজার বস্তা। গায়ে লেবেল না থাকলে কোনটি কার, কেউ বলতে পারে না। পর্ব ৬-এ tag দেখেছি একটি account-এর সহায়ক হিসেবে। Organization-এর স্তরে tag হয়ে ওঠে একটি হিসাবব্যবস্থা। কয়েকটি নিয়ম:

তালিকা ছোট রাখুন, ৪–৬টি। প্রতিটি tag-এর একটি ব্যবহারকারী থাকুক। মানের তালিকা নির্দিষ্ট করুন আর ছোট হাতের অক্ষরে রাখুন, কারণ অনেক provider-এ Checkout আর checkout আলাদা মান। এছাড়া নামের ভিন্নতা আছে: AWS আর Azure-এ এগুলো tag, Google Cloud-এ খরচের কাজে সাধারণত label, আর সেখানে tag বলতে আলাদা একটি জিনিস বোঝায় যা নিয়ম চালাতে কাজে লাগে।

Tag বাধ্য করার স্তর

1. সহজ পথ: IaC module-এ ডিফল্ট tag বসান। Terraform-এর AWS provider-এ default_tags এমন একটি সুবিধা। মানুষ না ভাবলেও tag বসে যায়।
2. Pipeline: Tag না থাকলে merge হবে না। বার্তাও পরিষ্কার পাবেন।
3. API guardrail: Tag ছাড়া তৈরি আটকায়। সতর্ক থাকুন, সব resource তৈরির সময় tag নেয় না, তাই সব জায়গায় Deny দিলে কাজ ভাঙতে পারে।
4. Detective রিপোর্ট: সাপ্তাহিক তালিকা, দলের নামে, সবচেয়ে দামি আগে।

দুটি ফাঁদ। প্রথমত, AWS-এ tag-কে বিলে দেখতে হলে আলাদা করে cost allocation tag হিসেবে চালু করতে হয়, আর সাধারণত চালুর পরের খরচই সেভাবে আসে (অতীতের জন্য provider-ভেদে সীমিত সুবিধা থাকতে পারে)। Azure-এ resource group-এর tag নিচের resource নিজে থেকে পায় না, policy বা cost-এর সেটিং লাগে। দ্বিতীয়ত, সব খরচে tag বসে না: support, কিছু data transfer, কিছু কর ধরনের লাইন। তাই ১০০% লক্ষ্য বাস্তবসম্মত নয়।

Tag coverage আর unallocated খরচ

Tag coverage দুইভাবে গোনা হয়, resource-এর সংখ্যায় আর খরচে। খরচের হিসাবই বেশি কাজের, কারণ একশোটি ছোট snapshot-এর চেয়ে একটি দামি database বড়। যে খরচ কোনো দলের ঘাড়ে পড়ে না, তাকে বলে unallocated cost. নিচের হিসাবে দশটি resource, সব দাম ধরে নেওয়া:

// Tag coverage: a tag counts only if its value is on the allowed list.
const teams = ['checkout', 'catalog', 'data'];
const envs = ['prod', 'dev'];
const rows = `vm-web-1,checkout,prod,420
vm-web-2,Checkout,prod,420
db-main,checkout,prod,960
bucket-img,catalog,prod,130
vm-search,catalog,prod,310
vm-test-7,,dev,240
nat-gw-a,,,180
lb-old,,prod,90
vm-ml-exp,data,,520
snap-2023,,,110`.split('\n').map(line => {
  const [id, team, env, usd] = line.split(',');
  return { id, team, env, usd: Number(usd) };
});
const total = rows.reduce((s, r) => s + r.usd, 0);
const pct = n => (100 * n / total).toFixed(1) + '%';
const good = rows.filter(r => teams.includes(r.team) && envs.includes(r.env));
const goodUsd = good.reduce((s, r) => s + r.usd, 0);
console.log(`resources: ${rows.length}, total: $${total}`);
console.log(`fully tagged: ${good.length}/${rows.length} by count, ${pct(goodUsd)} by cost`);
const byTeam = {};
for (const r of rows) {
  const key = teams.includes(r.team) ? r.team : '(unallocated)';
  byTeam[key] = (byTeam[key] || 0) + r.usd;
}
console.log('\ncost by team');
for (const [k, v] of Object.entries(byTeam).sort((a, b) => b[1] - a[1])) {
  console.log(`  ${k.padEnd(14)} $${String(v).padStart(5)}  ${pct(v)}`);
}
console.log('\nfix these first (no valid team, biggest cost)');
rows.filter(r => !teams.includes(r.team)).sort((a, b) => b.usd - a.usd)
  .forEach(r => console.log(`  ${r.id.padEnd(10)} $${r.usd}  team="${r.team}"`));

একই কাজ server বা CI-তে টেক্সট দিয়েও হয়। Provider-এর inventory থেকে পাওয়া CSV থেকে untagged জিনিস খোঁজার একটি নমুনা, পর্ব ৯-এর হাতিয়ার দিয়ে। এখানে CSV-টি ব্লকের ভেতরেই বানানো:

#!/usr/bin/env bash
set -euo pipefail

cat > inventory.csv <<'CSV'
id,type,region,team,env,usd
i-0a1,vm,ap-south-1,checkout,prod,420
i-0a2,vm,ap-south-1,checkout,,420
db-m1,database,ap-south-1,checkout,prod,960
b-img,bucket,ap-southeast-1,catalog,prod,130
i-0c3,vm,ap-southeast-1,,dev,240
nat-1,nat,ap-south-1,,,180
lb-07,loadbalancer,ap-south-1,,prod,90
i-0d9,vm,us-east-1,data,,520
CSV

echo "== missing team or env (biggest cost first) =="
awk -F, 'NR > 1 && ($4 == "" || $5 == "")' inventory.csv |
  sort -t, -k6,6nr |
  awk -F, '{ printf "%-6s %-13s team=%-9s env=%-5s $%d\n", $1, $2,
             ($4 == "" ? "-" : $4), ($5 == "" ? "-" : $5), $6 }'

echo
echo "== cost by team =="
awk -F, 'NR > 1 { t = ($4 == "" ? "(unallocated)" : $4); c[t] += $6 }
         END { for (k in c) printf "%-14s %d\n", k, c[k] }' inventory.csv |
  sort -k2,2nr

echo
echo "== gate =="
awk -F, 'NR > 1 { n++; all += $6; if ($4 != "" && $5 != "") { ok++; good += $6 } }
         END { p = 100 * good / all
               printf "tagged: %d/%d, %.1f%% of cost\n", ok, n, p
               print (p < 80 ? "FAIL: below the 80% target" : "PASS") }' inventory.csv

দলভিত্তিক budget

হিসাব জানা গেলে দলকে তা দেখাতে হয়। দুটি ধাপ আছে। Showback মানে “আপনাদের খরচ এত”, শুধু দেখানো। Chargeback মানে সেই টাকা দলের বাজেট থেকে সত্যিই কাটা। শুরু করুন showback দিয়ে, কারণ tag অসম্পূর্ণ থাকলে chargeback ঝগড়া বাড়ায়। NAT বা transit hub-এর মতো ভাগের খরচ ব্যবহারের অনুপাতে ভাগ করুন, অথবা আলাদা “platform” লাইনে দেখান।

প্রতিটি account-এ একটি budget থাকুক, যেমন vending-এর $৮০০. শুধু প্রকৃত খরচে নয়, পূর্বাভাসেও সতর্কতা দিন, যাতে মাসের ১২ তারিখেই বোঝা যায় মাস শেষে কোথায় দাঁড়াবে। মনে রাখুন budget alert সাধারণত খরচ থামায় না। Sandbox-এ স্বয়ংক্রিয় ব্যবস্থা নেওয়া যায়, production-এ বন্ধ করে দিলে সেটিই outage. বিস্তারিত অঙ্ক আর FinOps-এর চর্চা পর্ব ৭৩-এ।

৭ · Quota — ঈদের আগে সীমা দেখে নেওয়া

Provider প্রতিটি account-এ সীমা বসায়, এটিই quota বা service limit. কারণ দুটি: ভুল বা চুরি করা account যেন লাখ টাকার VM চালাতে না পারে, আর একজনের চাহিদা যেন অন্যের ক্ষতি না করে। সীমা দুই রকম:

• Soft limit: আবেদন করলে বাড়ে। যেমন অনেক provider-এ region প্রতি VM-এর vCPU.
• Hard limit: বাড়ে না, নকশা বদলাতে হয়। কোন সীমাটি কোন ধরনের, তা provider আর সময়ভেদে আলাদা, তাই নথি দেখে নিন।

নতুন account-এ সীমা প্রায়ই কম থাকে। এজন্যই vending-এর সময় একটি quota template রাখা ভালো। AWS-এ Service Quotas নামে সার্ভিস আছে, Azure আর Google Cloud-এও Quotas পাতা আছে। নিচে AWS CLI-এর উদাহরণ, এখানে চালানো হয়নি:

# সাধারণ on-demand VM-এর vCPU সীমা দেখা
aws service-quotas get-service-quota \
  --service-code ec2 --quota-code L-1216C47A --region ap-south-1

# বাড়ানোর আবেদন (quota code, মান আর region নিজের জন্য মিলিয়ে নিন)
aws service-quotas request-service-quota-increase \
  --service-code ec2 --quota-code L-1216C47A \
  --desired-value 773 --region ap-south-1

এবার হিসাব। একটি অনলাইন বাজার অ্যাপ ঈদের সেলের জন্য বড় হবে। আজ দিন ০, সেল দিন ১৪-তে। সেলের ৫ দিন আগে থেকে load test চালানো হবে, আর সেই test-এর জন্যও সীমা লাগবে। তাই আবেদনের শেষ দিন = ১৪ − ৫ − আবেদনে লাগা সময়। পরিকল্পিত peak-এর ওপর ২০% নিরাপত্তা রাখা হবে।

// Quota headroom check before an Eid sale. All numbers are assumed.
const SAFETY = 1.2;     // keep 20% above the planned peak
const SALE_DAY = 14;    // today is day 0
const TEST_DAYS = 5;    // load test must start this many days before the sale

const quotas = [
  { name: 'vcpu-on-demand',  limit: 320,  used: 164, extra: 480, lead: 7,  canRaise: true },
  { name: 'public-ip',       limit: 5,    used: 4,   extra: 3,   lead: 2,  canRaise: true },
  { name: 'fn-concurrency',  limit: 1000, used: 300, extra: 900, lead: 5,  canRaise: true },
  { name: 'read-replicas',   limit: 5,    used: 1,   extra: 4,   lead: 3,  canRaise: true },
  { name: 'targets-per-tg',  limit: 120,  used: 30,  extra: 120, lead: 0,  canRaise: false },
  { name: 'load-balancers',  limit: 50,   used: 6,   extra: 2,   lead: 0,  canRaise: true },
];

for (const q of quotas) {
  const peak = q.used + q.extra;
  const safe = Math.ceil(peak * SAFETY);
  const free = q.limit - peak;
  let status = 'OK';
  if (safe > q.limit) status = peak > q.limit ? 'OVER' : 'TIGHT';
  let todo = '';
  if (status !== 'OK') {
    todo = q.canRaise
      ? `ask ${safe}, file by day ${SALE_DAY - TEST_DAYS - q.lead}`
      : 'cannot raise: redesign';
  }
  console.log(`${q.name.padEnd(15)} ${String(peak).padStart(4)}/${String(q.limit).padEnd(4)} free ${String(free).padStart(4)}  ${status.padEnd(5)} ${todo}`);
}

৮ · Compliance — সহজ ভাষায় এরা কী চায়

PCI DSS-এর একটি ব্যবহারিক শিক্ষা হলো আওতা ছোট রাখা। কার্ডের নম্বর আপনার server-এ না এলে, যেমন পেমেন্ট প্রদানকারীর hosted পাতায় পাঠিয়ে শুধু token রাখলে, নিরীক্ষার পরিধি অনেক কমে। আলাদা account এই সীমাটি পরিষ্কার রাখে। GDPR-এর ক্ষেত্রে মনে রাখুন, আপনার কোম্পানি বাংলাদেশে হলেও EU-র মানুষকে পণ্য বা সেবা দিলে তা প্রযোজ্য হতে পারে। সিদ্ধান্তটি আইনজীবীর সঙ্গে আলোচনার বিষয়, প্রকৌশলীর একার নয়।

Provider-এর রিপোর্ট আর আপনার ভাগ

Provider নিজের data center আর platform-এর নিরীক্ষা করায়, আর রিপোর্টগুলো গ্রাহককে দেয়: AWS Artifact, Microsoft-এর Service Trust Portal, Google Cloud-এর Compliance Reports Manager. একটি shared compliance report থেকে আপনি ভৌত নিরাপত্তার মতো নিয়ন্ত্রণ “উত্তরাধিকারে” পান, নিজে আলাদা করে প্রমাণ দিতে হয় না। কিন্তু পর্ব ২-এর shared responsibility এখানেও খাটে। Provider-এর ISO সনদ থাকলেও আপনার খোলা bucket-এর দায় আপনারই। এসব রিপোর্ট শুধু নির্দিষ্ট service আর region-এর জন্য হয়, তাই আওতার তালিকাও মিলিয়ে নিন।

Evidence as code

পুরোনো পদ্ধতি: অডিটের আগের মাসে সবাই মিলে screenshot তোলা। সেটি ক্লান্তিকর, আর এক দিনের ছবি দিয়ে ছয় মাসের কার্যকারিতা বোঝায় না। Evidence as code মানে প্রমাণ নিজে থেকে জমা হয়, প্রতিদিন। প্রতিটি নিয়ন্ত্রণের সঙ্গে একটি স্বয়ংক্রিয় পরীক্ষা জুড়ে দেওয়া হয়, তার ফল সময়সহ পরিবর্তন-অযোগ্য storage-এ যায়।

এই ধারণার সঙ্গে policy as code-এর সম্পর্ক ঘনিষ্ঠ। নিয়ম কোডে থাকে, Git-এ review হয়, তার পরীক্ষাও লেখা যায়। পর্ব ৫৫-এ হাতে-কলমে আসবে। এবার একটি কাল্পনিক SOC 2 Type II প্রস্তুতি দেখি: ৬০টি নিয়ন্ত্রণ, ছয় মাসের সময়কাল।

Exception — নিয়ম ভাঙার নিয়ম

বাস্তবে সব নিয়ম সবসময় মানা যায় না। একটি পুরোনো vendor যন্ত্র হয়তো নির্দিষ্ট region-এই চলে। Exception না থাকলে মানুষ লুকিয়ে পথ খোঁজেন, যা অনেক খারাপ। একটি ভালো exception-এ পাঁচটি জিনিস থাকে: কোন নিয়ম, কেন, ঝুঁকির মালিক কে, কোন বিকল্প সুরক্ষা আছে, আর কবে মেয়াদ শেষ। মেয়াদহীন exception আসলে স্থায়ী নিয়ম বদল, শুধু নাম আলাদা। Exception-ও Git-এ রাখলে guardrail কোড নিজেই তা পড়তে পারে, আর মেয়াদ শেষে নিজে থেকে নিয়ম ফিরে আসে।

বাংলাদেশের প্রেক্ষাপট

এখানে সতর্কভাবে বলা দরকার। ব্যাংক, আর্থিক প্রতিষ্ঠান, MFS, টেলিকম, স্বাস্থ্য বা সরকারি ডেটা নিয়ে কাজ করলে নিয়ন্ত্রক সংস্থার আলাদা শর্ত থাকতে পারে। যেমন আর্থিক খাতের জন্য বাংলাদেশ ব্যাংকের ICT নিরাপত্তা-বিষয়ক নির্দেশনা আছে। সরকারের আইন-ওয়েবসাইট bdlaws.minlaw.gov.bd অনুযায়ী, ২০২৫ সালের অধ্যাদেশের জায়গায় এখন ব্যক্তিগত উপাত্ত সুরক্ষা আইন, ২০২৬ (২০২৬ সনের ৬৩ নং আইন) আর জাতীয় উপাত্ত ব্যবস্থাপনা আইন, ২০২৬ (২০২৬ সনের ৮০ নং আইন) আছে। দুটিরই তারিখ ১০ এপ্রিল ২০২৬। প্রথম আইনের কিছু ধারা পরে গেজেট প্রজ্ঞাপনে কার্যকর হওয়ার কথা, তাই এখানে কোনো বিধান উদ্ধৃত করছি না (পর্ব ৫-ও দেখুন)। কোনো পুরোনো ব্লগ বা AI-এর কথায় ধারা বা শর্ত ধরে নেবেন না, মূল লেখা পড়ুন। ডেটা দেশের ভেতরে রাখতে হবে কি না, বিদেশি cloud-এ কী অনুমতি লাগবে, তা সংশ্লিষ্ট সংস্থার সর্বশেষ নথি আর আইনজীবীর পরামর্শে ঠিক করুন। প্রকৌশলীর কাজ হলো সিদ্ধান্তটি কার্যকর করা, যেমন region guardrail দিয়ে data residency-র শর্ত মানা।

৯ · যে governance দলকে ধীর করে না — paved road

খারাপ governance-এর চেহারা সবাই চেনেন। নতুন account-এর জন্য ছয় সপ্তাহের টিকিট, প্রতি পরিবর্তনে কমিটির সভা। ফল কী? মানুষ পথ খোঁজেন: ব্যক্তিগত কার্ডে আলাদা account, অফিসের নিয়মের বাইরে shadow IT. নিয়ম যত কষ্টকর, তা এড়ানোর চেষ্টা তত বেশি।

• নিয়মকে কোডে নিন। মানুষের অনুমোদন শুধু উঁচু ঝুঁকির কাজে থাকুক। বাকিটা pipeline আর guardrail-এ।
• ঝুঁকি অনুযায়ী স্তর। Sandbox-এ প্রায় স্বাধীন, dev-এ মাঝারি, prod-এ কড়া। সব জায়গায় prod-এর নিয়ম মানে সবার শেখা বন্ধ।
• ব্যর্থ হলে পথ দেখান। “AccessDenied”-এর সঙ্গে কারণ, সঠিক পথ আর exception-এর লিংক দিন।
• Template আগে দিন। Module, pipeline আর account vending তৈরি থাকলে সঠিক কাজটি লিখতেই হয় না। পর্ব ৬২-তে এটিকেই golden path আর platform হিসেবে দেখব।
• Governance-কেও মাপুন। নতুন account পেতে কত সময় লাগে, কতগুলো exception খোলা, কত % guardrail detective থেকে preventive হলো, unallocated কত। নতুন account যদি এক ঘণ্টায় আসে আর detective finding কমতে থাকে, তাহলে আপনি ঠিক পথে।

১০ · AI-এর যুগে governance

AI খুব দ্রুত SCP, Azure Policy বা Terraform লিখে দেয়। Governance-এর কোডের ভুল কিন্তু অন্য কোডের মতো নয়: একটি ভুল নিয়ম একসঙ্গে সব account-এ লাগে। AI-এর ভুলগুলো চিনে রাখুন:

AI-এর লেখা governance কোড চালুর আগে

• প্রতিটি action, condition key আর quota code সরকারি নথিতে নিজে মিলিয়েছি
• নিয়মটি প্রথমে test OU বা detective মোডে চালিয়ে প্রভাব মেপেছি
• ফিরিয়ে নেওয়ার পথ আর break-glass পরিচয় পরীক্ষা করা আছে
• Git-এ review হয়েছে, plan বা diff দ্বিতীয় একজন পড়েছেন
• AI-এর উদ্ধৃত কোনো আইন বা মানের ধারা মূল নথিতে দেখেছি
• Prompt-এ কোনো secret, আসল account id বা গ্রাহকের ডেটা যায়নি