Cloud নিরাপত্তার ভিত্তি — misconfiguration, audit log আর defense in depth

১ · তালা শক্ত, কিন্তু চাবি দরজায় ঝুলছে

পর্ব ৩১ থেকে ৩৩-এ পরিচয়, অনুমতি আর secret দেখেছেন। এবার পুরো ছবিটি এক জায়গায় আনার সময়। প্রশ্নটি সহজ: আপনার cloud account এই মুহূর্তে কতটা নিরাপদ, আর সেটি আপনি কীভাবে জানবেন? এই সামগ্রিক অবস্থাকে বলে security posture, বাংলায় নিরাপত্তার অবস্থান।

এই “শাটার খোলা” অবস্থাকেই বলে misconfiguration: কোনো সেবা ত্রুটি ছাড়াই চলছে, কিন্তু তার সেটিং ভুল। Software-এর bug নয়, তাই কোনো patch এটি সারায় না।

ভুল এত বেশি হয় কেন? কারণগুলো cloud-এর গুণ থেকেই আসে। একটি API call-এ সেটিং বদলায়, তাই ভুলও এক সেকেন্ডে হয়। সেবার সংখ্যা বিশাল, প্রত্যেকটির সেটিং আলাদা। “আজকের জন্য খুলে দিই” বলা অস্থায়ী নিয়ম মাসের পর মাস থেকে যায়। আর দল বড় হলে কেউ নিশ্চিত থাকেন না, কোন জিনিসের মালিক কে।

শেষ সারিটি একটু আলাদা। অন্য চারটি ভুল দরজা খোলে, এটি ক্যামেরা বন্ধ করে। তাই একে ছোট ভাববেন না। আর বাস্তবের ঘটনায় একটি ভুল প্রায় একা থাকে না। কয়েকটি মাঝারি ভুল জোড়া লেগে বড় ক্ষতি করে। এই কারণেই একটি ভুলের blast radius, মানে ক্ষতি কতদূর ছড়াতে পারে, সেটিও সমান গুরুত্বপূর্ণ।

২ · Shared responsibility — দর্শন নয়, চেকলিস্ট

পর্ব ২-এ আপনি shared responsibility দেখেছেন। AWS-এর জনপ্রিয় ভাষায় provider সামলায় “security of the cloud”, আর গ্রাহক সামলান “security in the cloud”. কথাটি সুন্দর, কিন্তু কাজের নয়, যতক্ষণ না একে প্রশ্নে ভাঙা হয়। প্রতিটি সেবার জন্য একটিই প্রশ্ন: এই কাজটি যদি না হয়, দোষ কার?

শেষ দুটি সারি লক্ষ করুন। SaaS পর্যন্ত গেলেও পরিচয় আর ডেটা আপনার হাত থেকে সরে না। সেবার ধরন বদলালে দায় কমে, শূন্য হয় না। সূক্ষ্ম ভাগ provider আর সেবাভেদে আলাদা, তাই সেই সেবার অফিসিয়াল নথি দেখে নিশ্চিত হওয়াই নিয়ম। এবার একে একটি ব্যবহারযোগ্য তালিকায় আনি। নতুন যেকোনো সেবা চালুর আগে নিচের প্রশ্নগুলো ধরে এগোন।

নতুন সেবার দায়িত্ব-চেকলিস্ট

• এই resource-এর মালিক কে, আর সেটি tag হিসেবে লেখা আছে
• এটি internet থেকে দেখা যায় কি না জানি, আর দেখা গেলে তার লিখিত কারণ আছে
• কে কে এতে পৌঁছাতে পারেন, সেই তালিকা মানুষ আর সেবা দুটি মিলিয়ে দেখেছি
• ডেটার শ্রেণি জানি, এনক্রিপশন চালু, চাবি কে নিয়ন্ত্রণ করেন তাও জানি
• Patch কে দেবেন আর কখন, সেটি ঠিক করা আছে
• Audit আর access log চালু, এবং সেগুলো কোথায় যায় জানি
• Backup আছে, আর restore করে দেখা হয়েছে (পর্ব ২৪)
• কিছু ঘটলে কাকে ডাকা হবে, সেটি লেখা আছে

৩ · Audit log — কে, কখন, কোথা থেকে, কী করলেন

Cloud-এ প্রায় সব কাজ শেষ পর্যন্ত একটি API call. তাই provider সেই call-গুলো লিখে রাখতে পারে। এই রেকর্ডই audit log. একে ভাবুন লঞ্চঘাটের প্রবেশ-খাতা হিসেবে: কে এলেন, কখন, কোন গেট দিয়ে, কী নিয়ে গেলেন, আর প্রহরী তাঁকে ঢুকতে দিলেন কি না।

Audit log-এর একটি event-এর ভেতরে যা থাকে, নিচের সংক্ষিপ্ত নমুনায় দেখুন। এটি CloudTrail-এর গঠন মেনে লেখা, তবে সব field নেই, আর account নম্বর কাল্পনিক।

{
  "eventTime": "2026-10-12T04:15:41Z",
  "eventSource": "signin.amazonaws.com",
  "eventName": "ConsoleLogin",
  "awsRegion": "us-east-1",
  "sourceIPAddress": "203.0.113.44",
  "userIdentity": {
    "type": "IAMUser",
    "accountId": "123456789012",
    "userName": "karim"
  },
  "responseElements": { "ConsoleLogin": "Success" },
  "additionalEventData": { "MFAUsed": "No" }
}

এখানে উত্তর আছে পাঁচটি প্রশ্নের: কে (userIdentity), কখন (eventTime), কোথা থেকে (sourceIPAddress), কী (eventName), আর ফল কী (responseElements). যে পরিচয় কাজটি করছে, তাকে বলে principal: সে মানুষ, role বা কোনো সেবা, যেকেউ হতে পারে।

Log দুই ধরনের কাজ লেখে। Management event হলো নিয়ন্ত্রণের কাজ: VM বানানো, policy বদলানো, bucket মোছা। Data event হলো ডেটার কাজ: একটি object পড়া বা function চালানো। দ্বিতীয়টির সংখ্যা বিশাল, তাই সাধারণত নিজে থেকে চালু থাকে না, আর চালু করলে খরচ বাড়ে। এই একটি কথা না জানলে ঘটনার দিন অবাক হবেন: bucket-এর সেটিং কে বদলালেন জানা যাবে, কিন্তু কে কোন ফাইল পড়লেন, জানা যাবে না।

সংখ্যাগুলো লেখার সময়ের, আর provider-ভেদে বদলাতে পারে। যাচাই করে নেবেন। মূল ধারণা একই: নিজে থেকে যা থাকে, তা অল্প দিনের। দীর্ঘদিনের জন্য আপনাকে পাঠানোর ব্যবস্থা করতে হবে।

আলাদা, সুরক্ষিত account-এ পাঠানো

ধরুন একজন অনুপ্রবেশকারী কোনোভাবে admin ক্ষমতা পেলেন। Log একই account-এর bucket-এ থাকলে তিনি সেটিও মুছতে পারেন। তাই পরিণত প্রতিষ্ঠান একটি log archive account রাখে। সেখানে প্রায় কেউ ঢোকেন না, আর সব account-এর log সেখানেই জমা হয়। দোকানের সিসিটিভির রেকর্ডার যদি দোকানের ক্যাশবাক্সের পাশে থাকে, চোর সেটিও তুলে নেয়। রেকর্ডার থাকা উচিত অন্য ঘরে, অন্য চাবিতে।

• লেখা যায়, মোছা যায় না: log জমা হওয়া bucket-এ শুধু লেখার অনুমতি, সাথে versioning আর object lock.
• সত্যতা প্রমাণ: Log integrity validation চালু রাখুন। CloudTrail-এর এই সুবিধায় hash আর digital signature দিয়ে পরে দেখানো যায়, কোনো file বদলানো হয়নি।
• সব region: ব্যবহার না করা region-ও ধরুন। সেখানকার কার্যকলাপ ঠিক সেই কারণেই সন্দেহজনক।
• Alert: Log বন্ধ করার চেষ্টাটিই সবচেয়ে বড় সংকেতগুলোর একটি।

কত দিন রাখবেন — retention

Retention আন্দাজে ঠিক হয় না। তিনটি প্রশ্ন আছে: নিয়ম কত দিন চায়, একটি অনুপ্রবেশ ধরা পড়তে কত দিন লাগতে পারে, আর খরচ কত। উদাহরণ হিসেবে কার্ড-পেমেন্টের মান PCI DSS কমপক্ষে ১২ মাস রাখতে বলে, যার সাম্প্রতিক ৩ মাস সাথে সাথে বিশ্লেষণের জন্য হাতের কাছে থাকতে হবে। বাংলাদেশে আপনার খাতে কোন নিয়ম খাটে, সেটি নিয়ন্ত্রক সংস্থার নির্দেশনা আর আইনি পরামর্শ দেখে নিশ্চিত করুন (পর্ব ৩৫)। ব্যবহারিক কৌশল হলো দুই ধাপ: নতুন log খোঁজা-সহজ জায়গায়, পুরোনো log সস্তা storage-এ। এই সরানোর কাজটি পর্ব ২১-এর lifecycle rule দিয়ে নিজে থেকেই হয়।

এবার খাতা পড়ি। নিচের script-এ CloudTrail-এর JSON-কে আমরা এক লাইনের সরল রূপে এনেছি, যাতে পর্ব ৯-এর awk দিয়েই পড়া যায়। দুটি প্রশ্ন: কে MFA ছাড়া console-এ ঢুকলেন, আর কে কী মুছলেন?

set -euo pipefail
export LC_ALL=C
cd "$(mktemp -d)"
cat > audit.log <<'LOG'
2026-10-12T03:02:11Z type=IAMUser user=rahim event=ConsoleLogin result=Success mfa=Yes ip=198.51.100.7
2026-10-12T03:40:52Z type=AssumedRole user=sso-nadia event=ConsoleLogin result=Success mfa=No ip=198.51.100.9
2026-10-12T04:15:09Z type=IAMUser user=karim event=ConsoleLogin result=Failure mfa=No ip=203.0.113.44
2026-10-12T04:15:41Z type=IAMUser user=karim event=ConsoleLogin result=Success mfa=No ip=203.0.113.44
2026-10-12T04:25:18Z type=IAMUser user=karim event=DeleteBucketPolicy result=Success mfa=- ip=203.0.113.44
2026-10-12T04:31:57Z type=IAMUser user=karim event=DeleteTrail result=AccessDenied mfa=- ip=203.0.113.44
2026-10-12T05:10:26Z type=Root user=root event=ConsoleLogin result=Success mfa=No ip=203.0.113.80
2026-10-12T06:44:12Z type=AssumedRole user=ci-deployer event=TerminateInstances result=Success mfa=- ip=198.51.100.7
2026-10-12T06:45:30Z type=AssumedRole user=ci-deployer event=RunInstances result=Success mfa=- ip=198.51.100.7
LOG

# Turn key=value pairs into named fields, then apply one condition per report.
report() {
  awk -v cond="$1" '{
    split("", f); f["time"] = $1
    for (i = 2; i <= NF; i++) { split($i, kv, "="); f[kv[1]] = kv[2] }
    hit = 0
    if (cond == "nomfa")
      hit = f["event"] == "ConsoleLogin" && f["result"] == "Success" &&
            f["mfa"] != "Yes" && f["type"] != "AssumedRole"
    if (cond == "delete")
      hit = f["event"] ~ /^(Delete|Terminate|Remove)/
    if (hit) print f["time"], f["user"], f["event"], f["result"], f["ip"]
  }' audit.log
}
echo "== console login without MFA"
report nomfa
echo "== deletion events"
report delete
echo "== deletion events per user"
report delete | cut -d' ' -f2 | sort | uniq -c | sort -rn

একটি MFA-হীন login বা একটি মোছার কাজ একা কিছু প্রমাণ করে না। অস্বাভাবিকতা বোঝা যায় তুলনায়। প্রতিটি principal-এর স্বাভাবিক আচরণ আগে থেকে জানা থাকলে নতুন কিছু চোখে পড়ে। এই ধারণাকে বলে anomaly detection. নিচের সিমুলেটরে একটি কাল্পনিক CI পরিচয়ের ৩০ দিনের স্বাভাবিক আচরণের সাথে একদিনের কাজ মেলানো হয়েছে।

// Compare one day of audit events with each principal's normal behaviour.
const baseline = {
  'ci-deployer': { actions: ['PutObject', 'UpdateService'], ips: ['198.51.100.7'], regions: ['ap-south-1'], hours: [8, 20] },
  'nadia': { actions: ['DescribeInstances', 'GetObject'], ips: ['198.51.100.9'], regions: ['ap-south-1'], hours: [8, 20] },
};
const SENSITIVE = ['StopLogging', 'DeleteTrail', 'CreateAccessKey', 'AttachUserPolicy', 'PutBucketPolicy'];
const events = [
  ['10:05', 'ci-deployer', 'PutObject', '198.51.100.7', 'ap-south-1'],
  ['10:06', 'ci-deployer', 'UpdateService', '198.51.100.7', 'ap-south-1'],
  ['11:30', 'nadia', 'DescribeInstances', '198.51.100.9', 'ap-south-1'],
  ['15:12', 'nadia', 'ListBuckets', '198.51.100.9', 'ap-south-1'],
  ['02:41', 'ci-deployer', 'ListUsers', '203.0.113.50', 'ap-south-1'],
  ['02:44', 'ci-deployer', 'CreateAccessKey', '203.0.113.50', 'ap-south-1'],
  ['02:47', 'ci-deployer', 'RunInstances', '203.0.113.50', 'eu-north-1'],
  ['02:52', 'ci-deployer', 'StopLogging', '203.0.113.50', 'ap-south-1'],
].map(([time, who, action, ip, region]) => ({ time, who, action, ip, region }));

function flagsFor(e) {
  const b = baseline[e.who], hour = Number(e.time.slice(0, 2)), flags = [];
  if (!b.actions.includes(e.action)) flags.push('new-action');
  if (!b.ips.includes(e.ip)) flags.push('new-ip');
  if (!b.regions.includes(e.region)) flags.push('new-region');
  if (hour < b.hours[0] || hour >= b.hours[1]) flags.push('odd-hour');
  if (SENSITIVE.includes(e.action)) flags.push('sensitive');
  return flags;
}
const scored = events.map(e => {
  const flags = flagsFor(e);
  return { ...e, flags, score: flags.length + (flags.includes('sensitive') ? 2 : 0) };
});
scored.filter(e => e.score >= 1).sort((a, b) => b.score - a.score || a.time.localeCompare(b.time))
  .forEach(e => console.log(e.score, e.time, e.who, e.action, '[' + e.flags.join(', ') + ']'));
const byWho = {};
scored.forEach(e => { byWho[e.who] = (byWho[e.who] || 0) + e.score; });
Object.entries(byWho).forEach(([who, s]) => console.log(`${who}: total ${s}, ${s >= 5 ? 'OPEN INCIDENT' : 'review later'}`));

৪ · পাহারার যন্ত্র — threat detection, CSPM আর CIS Benchmark

হাতে log পড়া শেখার জন্য ভালো, প্রতিদিনের কাজের জন্য নয়। এখানে দুই আলাদা ধরনের যন্ত্র আসে, আর এই দুটিকে গুলিয়ে ফেলা নতুনদের সাধারণ ভুল।

এদের প্রতিটি রিপোর্টকে বলে finding: একটি নির্দিষ্ট resource-এ একটি নির্দিষ্ট সমস্যার রেকর্ড। Finding নিজে থেকে কিছু সারায় না। অনেক দল ধরে নেয়, সেবা চালু করলেই কাজ শেষ। আসলে কাজ শুরু হয় সেখান থেকে, কারণ finding কারও চোখে না পড়লে তার কোনো মূল্য নেই। এই দুই ধারার ওপরে অনেক প্রতিষ্ঠান সব log আর finding এক জায়গায় আনার জন্য SIEM ব্যবহার করে।

নাম আর tier নিয়মিত বদলায়, আর এগুলো সাধারণত ব্যবহার-ভিত্তিক বিলে চলে। চালুর আগে সেই সেবার pricing পাতা দেখুন। এসবের বাইরে Prowler-এর মতো open-source posture scanner-ও আছে। লক্ষ্য একই: সেটিং পড়া, নিয়মে মেলানো, রিপোর্ট দেওয়া।

কিন্তু “ভালো সেটিং” কোনটি, সেটি ঠিক করল কে? এর একটি বহুল ব্যবহৃত উত্তর CIS Benchmark. অলাভজনক সংস্থা Center for Internet Security বিভিন্ন বিশেষজ্ঞের সম্মতিতে এই নির্দেশিকা বানায়। AWS, Azure, Google Cloud, Linux, Kubernetes, সবকিছুর আলাদা Benchmark আছে। প্রতিটি সুপারিশে কারণ, যাচাইয়ের পথ আর প্রতিকার লেখা থাকে। সাধারণত দুটি স্তর থাকে: Level 1 প্রায় সবার জন্য, Level 2 বেশি সংবেদনশীল পরিবেশের জন্য। Version সময়ের সাথে বদলায়, তাই নম্বর মুখস্থ করার দরকার নেই।

এবার একটি ছোট posture scanner নিজের হাতে দেখি। JSON-এ একটি কাল্পনিক account-এর resource তালিকা, আর প্রতিটি নিয়মের একটি severity ও ওজন।

// Posture scanner over a fake inventory. Severity weights are our own teaching scheme.
const WEIGHT = { critical: 10, high: 5, medium: 2, low: 1 };
const inventory = JSON.parse(`[
  {"id":"bucket-invoices","type":"bucket","public":true,"encrypted":true,"logged":false},
  {"id":"bucket-site","type":"bucket","public":true,"encrypted":true,"logged":true,"publicReason":"static site"},
  {"id":"bucket-backup","type":"bucket","public":false,"encrypted":false,"logged":true},
  {"id":"vm-web","type":"vm","worldPorts":[443],"diskEncrypted":true,"patchAgeDays":12},
  {"id":"vm-admin","type":"vm","worldPorts":[22,443],"diskEncrypted":false,"patchAgeDays":95},
  {"id":"db-orders","type":"db","public":true,"encrypted":true},
  {"id":"user-ci","type":"iam","actions":["*"],"mfa":false},
  {"id":"role-report","type":"iam","actions":["s3:GetObject"],"mfa":true},
  {"id":"audit-trail","type":"log","enabled":false}
]`);
const rules = [
  ['bucket', 'critical', 'public without a recorded reason', r => !r.public || !!r.publicReason],
  ['bucket', 'medium', 'not encrypted at rest', r => r.encrypted],
  ['bucket', 'low', 'access logging is off', r => r.logged],
  ['vm', 'high', 'admin port open to the world', r => !r.worldPorts.some(p => [22, 3389].includes(p))],
  ['vm', 'medium', 'disk not encrypted', r => r.diskEncrypted],
  ['vm', 'high', 'no patch for over 30 days', r => r.patchAgeDays <= 30],
  ['db', 'critical', 'database reachable from the internet', r => !r.public],
  ['iam', 'critical', 'wildcard permission', r => !r.actions.includes('*')],
  ['iam', 'high', 'no MFA', r => r.mfa],
  ['log', 'high', 'audit logging disabled', r => r.enabled],
];
let total = 0, earned = 0;
const failed = [];
for (const res of inventory) for (const [type, sev, text, pass] of rules) {
  if (res.type !== type) continue;
  total += WEIGHT[sev];
  if (pass(res)) earned += WEIGHT[sev]; else failed.push({ sev, id: res.id, text });
}
failed.sort((a, b) => WEIGHT[b.sev] - WEIGHT[a.sev]);
failed.forEach(f => console.log(f.sev.toUpperCase().padEnd(9), f.id.padEnd(16), f.text));
console.log(`failed: ${failed.length}, score: ${Math.round(100 * earned / total)}/100`);

৫ · কোনটি আগে — severity আর ঝুঁকির হিসাব

প্রথমবার scanner চালালে শত শত finding দেখা অস্বাভাবিক নয়। সব সমান জরুরি মনে হলে আসলে কিছুই জরুরি থাকে না। একে বাছাই করার কাজকে বলে triage, হাসপাতালের জরুরি বিভাগের মতো: বুকে ব্যথার রোগী আগে, হাতে ছড়ে যাওয়া রোগী পরে।

সবচেয়ে পরিচিত সরল সূত্র, যা NIST SP 800-30-এর মতো ঝুঁকি-নির্দেশিকার ধারণার সহজ রূপ:

Provider-এর দেওয়া severity আপনার ব্যবসা চেনে না। একটি test VM-এ “High” আর payment database-এর “Medium”-এর মধ্যে দ্বিতীয়টি আগে দেখতে হতে পারে। তাই পাঁচটি প্রশ্নে নিজের হিসাব মিলিয়ে নিন।

• উন্মুক্ত কি না: internet থেকে পৌঁছানো যায়, নাকি শুধু ভেতর থেকে?
• ডেটা কী: গ্রাহকের ব্যক্তিগত বা পেমেন্টের তথ্য, নাকি কাল্পনিক test ডেটা?
• ক্ষমতা কত: এই resource-এর role কতদূর পৌঁছায়?
• সক্রিয় ব্যবহার আছে কি: এই দুর্বলতা বাস্তবে ব্যবহার হচ্ছে বলে জানা গেছে?
• অন্য স্তর আছে কি: অন্য কোনো পাহারা এটিকে আংশিক ঢেকে রেখেছে?

// Risk = likelihood x impact (1 to 5 each). L2 is the likelihood after the fix.
const findings = [
  { name: 'invoices bucket public', L: 5, I: 5, L2: 1, hours: 1 },
  { name: 'CI user has wildcard policy', L: 3, I: 5, L2: 1, hours: 8 },
  { name: 'SSH open to the world', L: 4, I: 4, L2: 1, hours: 2 },
  { name: 'audit logging disabled', L: 3, I: 4, L2: 1, hours: 1 },
  { name: 'old TLS on internal API', L: 2, I: 3, L2: 1, hours: 6 },
  { name: 'unused test VM unpatched', L: 3, I: 1, L2: 1, hours: 1 },
];
const band = s => s >= 15 ? 'CRITICAL' : s >= 10 ? 'HIGH' : s >= 5 ? 'MEDIUM' : 'LOW';
const due = { CRITICAL: 'today', HIGH: '7 days', MEDIUM: '30 days', LOW: 'next cycle' };
const rows = findings.map(f => {
  const score = f.L * f.I, left = f.L2 * f.I;
  return { ...f, score, left, perHour: (score - left) / f.hours };
});
console.log('-- order by risk');
[...rows].sort((a, b) => b.score - a.score || a.hours - b.hours).forEach((r, i) => {
  const b = band(r.score);
  console.log(`${i + 1}. ${String(r.score).padStart(2)} ${b.padEnd(8)} ${r.name} (fix by: ${due[b]})`);
});
console.log('-- risk removed per hour of work');
[...rows].sort((a, b) => b.perHour - a.perHour).slice(0, 3).forEach(r =>
  console.log(`${r.perHour.toFixed(1).padStart(4)}  ${r.name} (${r.score} -> ${r.left} in ${r.hours}h)`));
const before = rows.reduce((s, r) => s + r.score, 0);
const after = rows.reduce((s, r) => s + r.left, 0);
console.log(`total risk ${before} -> ${after} if all are fixed`);

এবার একটি finding-এর পুরো জীবন দেখি, ধরা পড়া থেকে আর কখনো না ঘটার ব্যবস্থা পর্যন্ত। প্রেক্ষাপট একটি কাল্পনিক অনলাইন দোকান।

ধাপ ৭-ই আসল লাভ। একই ভুল ঠিক করতে থাকলে আপনি পাহারাদার হয়েই থাকবেন। ভুলটি অসম্ভব করে দিলে প্রকৌশলী হবেন। এই পথের নাম guardrail: এমন স্বয়ংক্রিয় সীমা, যার বাইরে কেউ ভুল করেও যেতে পারে না।

৬ · Defense in depth — পাঁচ স্তরের পাহারা

Defense in depth-এর মূল ভাবনা সরল: যেকোনো একটি পাহারা একদিন ব্যর্থ হবে, তখন পরেরটি থাকতে হবে। ধারণাটি সামরিক কৌশল থেকে এসেছে। পুরোনো দুর্গে শুধু একটি উঁচু দেয়াল থাকত না; পরিখা, বাইরের দেয়াল, ভেতরের দেয়াল, সবই থাকত। Cloud-এ আমরা পাঁচটি স্তর ধরছি। স্তরের নাম বইভেদে একটু আলাদা হয়, ধারণা একই।

এনক্রিপশনের default কী — আর সে কী করে না

এখন বড় cloud-গুলোতে অনেক কিছু নিজে থেকেই এনক্রিপ্ট হয়। ডেটা জমা থাকা অবস্থায় এই সুরক্ষার নাম encryption at rest, আর পথে থাকা অবস্থায় encryption in transit. Default আলাদা আলাদা, আর মনে করে নেওয়া বিপজ্জনক।

লেখার সময়ের এই তথ্য বদলাতে পারে, নিজের সেবায় যাচাই করে নিন। আর এবার সবচেয়ে গুরুত্বপূর্ণ কথাটি।

৭ · Patching আর vulnerability scanning

Misconfiguration আপনার সেটিংয়ের ভুল। Vulnerability হলো software-এর নিজের ত্রুটি। প্রকাশিত ত্রুটি একটি CVE নম্বর পায়। দুটির উত্তরও আলাদা: প্রথমটিতে সেটিং বদলান, দ্বিতীয়টিতে patch দিন।

কোন resource-এ কোন দুর্বল version চলছে, সেটি বের করার কাজই vulnerability scanning. একটি VM-এ agent বসিয়ে স্ক্যান করা যায়, আবার অনেক সেবা disk-এর snapshot পড়ে agent ছাড়াও পারে। Container image স্ক্যান হয় registry-তে (পর্ব ৪১)। মনে রাখুন, শুধু নিজের resource-এই স্ক্যান চালাবেন, আর provider-এর নীতি পড়ে নেবেন।

ফল বিচার করার তিনটি মাপকাঠি আছে, আর এগুলো এক জিনিস নয়।

সিদ্ধান্তের নিয়ম সহজ: CVSS ৯.৮-এর একটি ত্রুটি যদি ভেতরের ল্যাবের VM-এ থাকে, আর CVSS ৭.৫-এর একটি ত্রুটি internet-মুখী server-এ থাকে এবং KEV-এ নাম ওঠে, দ্বিতীয়টি আগে। ডিসেম্বর ২০২১-এর Log4Shell (CVE-2021-44228, CVSS ১০.০) অনেক দলকে শিখিয়েছিল আরেকটি কথা। প্রথম প্রশ্নটি ছিল না “কীভাবে সারাব”, ছিল “আমাদের কোথায় কোথায় এই library আছে?” সম্পদের তালিকা না থাকলে patch শুরুই করা যায় না।

Patch দেওয়ার তিন পথ

Scanner মাঝে মাঝে ভুলও করে। Linux distribution অনেক সময় নিরাপত্তা-সংশোধন পুরোনো version-এই বসায়, version নম্বর বাড়ায় না। তখন শুধু version দেখে বানানো scanner মিথ্যা alarm দেয়, যাকে বলে false positive. Finding বন্ধ করার আগে distribution-এর security advisory দেখুন, আর কারণটি লিখে রাখুন।

৮ · Incident-এর প্রস্তুতি — আলাদা করা, প্রমাণ রাখা, credential বদলানো

সব পাহারার পরও ঘটনা ঘটবে, এই মেনে নিয়েই প্রস্তুতি। NIST SP 800-61 নিরাপত্তা-ঘটনা সামলানোর বহুল ব্যবহৃত নির্দেশিকা। এর ২০১২ সালের সংস্করণে চারটি ধাপ: প্রস্তুতি; শনাক্ত ও বিশ্লেষণ; আটকানো, নির্মূল ও পুনরুদ্ধার; আর ঘটনার পরের কাজ। ২০২৫ সালের নতুন সংস্করণ এটিকে NIST Cybersecurity Framework-এর সাথে মিলিয়েছে। পুরো ব্যবস্থাকে বলে incident response. Severity, ভূমিকা আর on-call-এর বিস্তার পর্ব ৬৭-এ পাবেন; এখানে নিরাপত্তার বিশেষ অংশটুকু।

আগুন লাগলে আপনি ঘর পুড়তে দেন না, আবার পোড়া জায়গাও সাথে সাথে ঝাড়ু দেন না, কারণ তদন্তকারী দেখতে চাইবেন আগুন কোথা থেকে শুরু। Cloud-এও তিনটি কাজ একসাথে সামলাতে হয়। আগুন ছড়ানো থামানো, যাকে বলে containment. প্রমাণ অক্ষত রাখা। আর যা চুরি হয়ে থাকতে পারে, তা অকেজো করা। নিচে ক্রমটি দেখুন।

একই কাজ AWS CLI-তে দেখতে এরকম (উদাহরণ, আইডি কাল্পনিক; চালানোর আগে আপনার runbook দেখুন)। Azure আর Google Cloud-এ ধারণা একই: VM-কে group থেকে সরানো, network নিয়ম বদলানো, disk snapshot.

# 1. Leave the group, but keep capacity: the group starts a replacement
aws autoscaling detach-instances \
  --instance-ids i-0abc1234example \
  --auto-scaling-group-name shop-web \
  --no-should-decrement-desired-capacity

# 2. Swap to a group with no rules
aws ec2 modify-instance-attribute \
  --instance-id i-0abc1234example \
  --groups sg-0quarantexample

# 3. Preserve the disk
aws ec2 create-snapshot \
  --volume-id vol-0abc1234example \
  --description "IR-014 evidence vm-web-3"

চলমান VM আর তার snapshot-এর জন্য বিল চলতে থাকে, কিন্তু প্রমাণের তুলনায় সেটি ছোট দাম। আর এই সব ধাপ ঘটনার রাতে ভাবা যায় না। আগে থেকে runbook লেখা, sg-quarantine বানানো, forensic account তৈরি আর মাঝে মাঝে মহড়া, এটিই আসল প্রস্তুতি।

৯ · নতুন account-এর প্রথম দিন — security baseline

Security baseline হলো প্রতিটি account-এ বাধ্যতামূলক ন্যূনতম ব্যবস্থা। নতুন বাড়িতে উঠে আগে যেমন তালা বদলান, তারপর আসবাব তোলেন, তেমনই। Resource বানানোর আগে এটি করলে খরচ আর পরিশ্রম দুটিই সবচেয়ে কম। ধরুন একটি ছোট দল একটি নতুন account খুলেছে। প্রথম দিনটি দেখি।

নিচের কমান্ডগুলো সেই baseline-এর কয়েকটি ধাপের নমুনা, পূর্ণ সেটআপ নয়। Log bucket-এর policy, নিরাপত্তা-সেবার সংযোগ আর region-ভিত্তিক কাজ আলাদা করে লাগবে। কিছু সেবা বিল তুলতে পারে, আর পরীক্ষার account হলে কাজ শেষে এগুলো বন্ধ করে পরিষ্কার করবেন। বাস্তবে এগুলো হাতে নয়, IaC দিয়ে সব account-এ একইভাবে বসানো হয় (পর্ব ৩৫ আর ৫১)।

# AWS: audit log for all regions, with integrity validation
aws cloudtrail create-trail --name org-trail \
  --s3-bucket-name example-log-archive \
  --is-multi-region-trail --is-organization-trail \
  --enable-log-file-validation
aws cloudtrail start-logging --name org-trail

# AWS: block public access for the whole account
aws s3control put-public-access-block --account-id 123456789012 \
  --public-access-block-configuration \
  BlockPublicAcls=true,IgnorePublicAcls=true,BlockPublicPolicy=true,RestrictPublicBuckets=true

# AWS: safe defaults in this region, then threat detection
aws ec2 enable-ebs-encryption-by-default
aws ec2 modify-instance-metadata-defaults --http-tokens required
aws guardduty create-detector --enable

# Google Cloud: send audit logs to a separate bucket
gcloud logging sinks create audit-sink \
  storage.googleapis.com/example-log-archive \
  --organization=123456789012 --include-children \
  --log-filter='logName:"cloudaudit.googleapis.com"'

# Azure: turn on a Defender plan for servers
az security pricing create --name VirtualMachines --tier Standard

১০ · AI-এর যুগে cloud নিরাপত্তা

AI দ্রুত Terraform, policy বা সমাধান লিখে দেয়। কিন্তু তার লক্ষ্য থাকে “কাজ চলুক”, আর সবচেয়ে সহজে কাজ চলে সব খুলে দিলে। সমস্যা হলে সে অনেক সময় নিরাপত্তা কমিয়ে সমাধান দেয়। আর একটি নতুন ঝুঁকি: log বা finding AI-কে দেওয়ার আগে তার ভেতরের আসল তথ্য মুছতে হবে।

AI-এর নিরাপত্তা-পরামর্শ ব্যবহারের আগে — চেকলিস্ট

• প্রম্পটে কোনো secret, আসল account নম্বর, IP বা গ্রাহকের তথ্য দিইনি
• প্রতিটি * আর 0.0.0.0/0 খুঁজে কারণ যাচাই করেছি
• কোনো পরিবর্তন logging, MFA বা এনক্রিপশন কমাচ্ছে না
• সেবার নাম, flag আর default অফিসিয়াল নথিতে মিলিয়েছি
• --dry-run বা terraform plan দেখে diff পড়েছি, throwaway পরিবেশে পরীক্ষা করেছি
• ধ্বংসাত্মক কমান্ডের প্রভাব বুঝেছি, আর ফেরার পথ আছে
• নতুন সেবার খরচ দেখেছি, budget alert চালু আছে
• Incident-এর পরামর্শ runbook আর দায়িত্বশীল মানুষের সাথে মিলিয়েছি