Cloud নিরাপত্তা — shared responsibility, misconfiguration আর CNAPP

১ · কার দায় কতটা: IaaS, PaaS আর SaaS

ধরুন আপনি ব্যবসা করবেন, আর জায়গা নেবেন তিনভাবে। মার্কেটে একটি খালি দোকান ভাড়া নিলে তাক, তালা, আলমারি, কর্মচারী, সবই আপনার। সাজানো দোকান ভাড়া নিলে তাক আর বিদ্যুৎ মালিকের, কিন্তু মাল সাজানো আর কর্মচারী আপনার। আর হোটেলের ঘর নিলে প্রায় সবই হোটেলের। তবু ঘরের চাবি কাকে দেবেন, আর গয়না টেবিলে ফেলে রাখবেন কি না, সে সিদ্ধান্ত আপনার। হোটেলের ঘরে চুরি হলে প্রথম প্রশ্নই হবে, দরজা কে খোলা রেখেছিল?

এই তিনটিই IaaS, PaaS আর SaaS. আর কাজের এই ভাগের নাম shared responsibility. বিস্তারিত চেকলিস্ট আছে Cloud & DevOps কোর্সের Cloud নিরাপত্তার ভিত্তি পর্বে, আর SaaS vendor-এর চুক্তির দিক দেখেছেন পর্ব ৭১-এ। এখানে আমরা নিরাপত্তা বিশ্লেষকের প্রশ্নটি করব: কোন স্তরে ভুল হলে আমাকেই ধরতে হবে?

২ · Cloud-এর ঝুঁকির ছবি: পরিচয়ই নতুন সীমানা

অফিসের পুরোনো নিরাপত্তা ছিল দুর্গের মতো: বাইরে firewall, ভেতরে নিশ্চিন্ত। Cloud-এ সব কাজই একটি API call. সেই API internet থেকেই পাওয়া যায়, যদি হাতে বৈধ credential থাকে। তাই যাঁর চাবি আছে, তিনি দেয়াল না ভেঙেই ঢুকতে পারেন। একেই বলা হয় identity is the new perimeter. ব্যাংকের লকার রুমে দারোয়ান থাকলেও, আসল প্রশ্ন হয়ে দাঁড়ায় কার হাতে কোন চাবি।

আর একটি বদলও আছে। আগে একটি server বসাতে সপ্তাহ লাগত। এখন একটি ভুল সেটিং এক মিনিটে হাজারো ফাইল প্রকাশ্য করতে পারে। গতি বেড়েছে, ভুলের গতিও বেড়েছে।

দুটি প্রকাশিত ঘটনা

৩ · Misconfiguration ধরা: CSPM ভেতরে কী করে

মহল্লার পাহারাদার রাতে প্রতিটি দরজা ঠেলে দেখেন, কোনটি খোলা। CSPM (Cloud Security Posture Management) ঠিক এই কাজটি করে। সে provider-এর API থেকে সেটিং পড়ে, নিয়মের সাথে মেলায় আর একটি finding লেখে। সে দরজা খোলে না, শুধু অবস্থা পড়ে। সাধারণত এই পড়ার জন্য একটি read-only role লাগে, আর সেটিও একটি বড় চাবি, তাই তাকেও সুরক্ষিত রাখতে হয়।

নিচের খেলনা scanner মেমরির কিছু বানানো resource পড়ে। কোনো আসল cloud-এ সে যায় না। লক্ষ করুন, severity শুধু সেটিং দিয়ে নয়, ডেটার ধরন দিয়েও ঠিক হচ্ছে।

// Toy CSPM. Fake resources in memory, no real cloud API is called.
const resources = [
  { id: 'bucket-invoices', type: 'bucket', data: 'personal', public: true, enc: true, owner: 'finance' },
  { id: 'bucket-website', type: 'bucket', data: 'public', public: true, enc: true, owner: 'web', reason: 'static site' },
  { id: 'bucket-logs', type: 'bucket', data: 'internal', public: false, enc: true, owner: null },
  { id: 'db-orders', type: 'database', data: 'personal', public: false, enc: false, owner: 'shop' },
  { id: 'vm-admin', type: 'vm', ports: [22], from: '0.0.0.0/0', tokenMeta: false, enc: true, owner: 'ops' },
  { id: 'vm-web', type: 'vm', ports: [443], from: '0.0.0.0/0', tokenMeta: true, enc: true, owner: 'web' },
];
// Our own teaching rules. Each severity depends on context, not only on the setting.
const rules = [
  { id: 'PUB-1', msg: 'public bucket, no recorded reason',
    hit: r => r.type === 'bucket' && r.public && !r.reason,
    sev: r => (r.data === 'public' ? 'LOW' : r.data === 'personal' ? 'CRITICAL' : 'HIGH') },
  { id: 'ENC-1', msg: 'encryption at rest is off', hit: r => !r.enc,
    sev: r => (r.data === 'personal' ? 'HIGH' : 'MEDIUM') },
  { id: 'NET-1', msg: 'admin port open to the whole internet',
    hit: r => r.type === 'vm' && r.from === '0.0.0.0/0' && r.ports.some(p => [22, 3389].includes(p)),
    sev: () => 'HIGH' },
  { id: 'IMD-1', msg: 'token-based metadata access not required',
    hit: r => r.type === 'vm' && !r.tokenMeta, sev: () => 'MEDIUM' },
  { id: 'OWN-1', msg: 'no owner on record', hit: r => !r.owner, sev: () => 'LOW' },
];
const rank = { CRITICAL: 0, HIGH: 1, MEDIUM: 2, LOW: 3 };
const findings = [];
for (const r of resources)
  for (const rule of rules)
    if (rule.hit(r)) findings.push({ sev: rule.sev(r), rule: rule.id, id: r.id, msg: rule.msg });
findings.sort((a, b) => rank[a.sev] - rank[b.sev]);
for (const f of findings) console.log(f.sev.padEnd(8), f.rule, f.id.padEnd(15), f.msg);
const clean = resources.filter(r => !findings.some(f => f.id === r.id)).map(r => r.id);
console.log(findings.length, 'findings in', resources.length, 'resources; clean:', clean.join(', '));

নিয়ম আসে কোথা থেকে

নিয়ম নিজে বানাতে হয় না। CIS Benchmark-এর AWS, Azure ও Google Cloud Foundations সংস্করণ প্রতিটি account-এর মৌলিক সেটিং ধরে যাচাইয়ের ধাপ দেয়, আর Level 1 ও Level 2 নামে দুই মাত্রা রাখে। Version দ্রুত বদলায়, তাই CIS-এর সাইট দেখবেন। CSA Cloud Controls Matrix (CCM) আরও ওপরের কাঠামো। Cloud Security Alliance-এর পাতা অনুযায়ী v4.1 (জানুয়ারি ২০২৬) ১৭টি domain-এ ২০৭টি control ধরে, আর সেগুলোকে ISO 27001-এর মতো standard-এর সাথে মেলায়। সহজ ভাগ: CIS বলে “এই সেটিং দেখুন”, CCM বলে “এই control থাকা চাই, কে দায়ী”। পর্ব ৩০-এ CIS, পর্ব ৬৯-এ compliance, আর পর্ব ৭১-এ CCM থেকে তৈরি CAIQ দেখেছেন।

৪ · Attack path আর toxic combination: রক্ষকের চোখে

তিন হাজার finding-এর তালিকা হাতে নিয়ে কোনো দল এগোতে পারে না। এর বদলে একটি অন্য প্রশ্ন করুন: internet থেকে আমার সবচেয়ে সংবেদনশীল ডেটা পর্যন্ত কোনো পথ আছে কি? রেললাইনের কথা ভাবুন। একটি ফিশপ্লেট ঢিলা হলে মেরামত দরকার। কিন্তু ওই জায়গায় যদি সিগন্যালও খারাপ হয়, আর ট্রেনও পূর্ণ গতিতে আসে, তবে তিনটি ছোট সমস্যা মিলে একটি বড় দুর্ঘটনার ঝুঁকি।

Cloud-এ এই পথের নাম attack path. পথের প্রতিটি ধাপ একা দেখলে ছোট, কিন্তু মিলে গেলে যে বিপদ, তাকে অনেক cloud নিরাপত্তা পণ্য বলে toxic combination. শব্দটি access control-এর বইয়ে আরেক অর্থেও আসে: একজনের হাতে দুটি পরস্পরবিরোধী অধিকার (পর্ব ১৯)। মূল ভাবনা একই, ক্ষতি আসে যোগফল থেকে। রক্ষকের কাজ হামলা করা নয়, নিজের মানচিত্রে পথটি খুঁজে সবচেয়ে সস্তা আংটাটি ভাঙা।

এই চিন্তাটিই একটি গ্রাফের সমস্যা। Resource হলো বিন্দু, “পৌঁছাতে পারে” হলো রেখা। নিচের কোড কাল্পনিক resource-এর ওপর internet থেকে সংবেদনশীল ডেটার পথ খোঁজে। এটি কোনো হামলার ধাপ নয়, নিজের মানচিত্র পড়া।

// Toy attack path graph for defenders. Fake resources, in memory only.
const nodes = {
  'internet': {}, 'vm-dev': {}, 'role-dev': {}, 'bkt-assets': {},
  'vm-web': { unpatched: true }, 'vm-batch': { unpatched: true },
  'role-web': { broad: true }, 'role-batch': { broad: true },
  'bkt-cust': { sensitive: true }, 'db-orders': { sensitive: true },
};
const edges = {
  'internet': ['vm-web', 'vm-dev'],
  'vm-web': ['role-web'], 'vm-dev': ['role-dev'], 'vm-batch': ['role-batch'],
  'role-web': ['bkt-assets', 'bkt-cust'], 'role-dev': ['bkt-assets', 'db-orders'],
  'role-batch': ['bkt-cust', 'db-orders'],
};
function paths(g, at = 'internet', seen = [at], out = []) {
  if (nodes[at].sensitive) out.push(seen);
  for (const next of g[at] || [])
    if (!seen.includes(next)) paths(g, next, [...seen, next], out);
  return out;
}
const toxic = p => p.some(n => nodes[n].unpatched) && p.some(n => nodes[n].broad);
function report(label, g) {
  const found = paths(g);
  console.log(label + ':', found.length, 'path(s) to sensitive data');
  for (const p of found) console.log(' ', toxic(p) ? 'TOXIC ' : 'review', p.join(' -> '));
}
report('Before', edges);
report('After narrowing role-web', { ...edges, 'role-web': ['bkt-assets'] });
const reach = (at, seen = new Set([at])) => {
  for (const x of edges[at] || []) if (!seen.has(x)) { seen.add(x); reach(x, seen); }
  return seen;
};
const hidden = Object.keys(nodes).filter(n => !reach('internet').has(n));
console.log('Not reachable from internet:', hidden.join(', '));

৫ · CSPM, CIEM, CWPP আর CNAPP: কে কোন প্রশ্নের উত্তর দেয়

Stepper-এ দেখলেন, পথের চারটি বিন্দু চারটি আলাদা উৎস থেকে এসেছে। Cloud নিরাপত্তার সংক্ষিপ্ত নামগুলো এখান থেকেই। নামগুলো মূলত বাজারের শ্রেণি, কোনো standard নয়, তাই সংজ্ঞা vendor-ভেদে কিছুটা আলাদা।

Gartner ২০২১ সালের আগস্টের একটি প্রতিবেদনে CNAPP নামটি সামনে আনে বলে সাধারণত ধরা হয়, আর ধারণাটি ছিল আলাদা যন্ত্রের alert এক প্রেক্ষাপটে আনা। সুবিধা হলো সংযোগ: stepper-এর মতো পথ দেখা। ঝুঁকিও আছে: একটি পণ্যের সব অংশ সমান ভালো নয়, আর একক vendor-এর ওপর নির্ভরতা বাড়ে। ছোট দলের জন্য provider-এর নিজের সেবাই শুরু হিসেবে যথেষ্ট হতে পারে। উদাহরণ হিসেবে AWS-এ Security Hub, Azure-এ Defender for Cloud, Google Cloud-এ Security Command Center. নামগুলো সুপারিশ নয়, আর plan ও ক্ষমতা বদলায়।

৬ · Audit trail: কী রাখবেন, কিসে alert দেবেন

অফিসের রেজিস্টার খাতায় যেমন লেখা থাকে কে এলেন, কখন, কার কাছে, তেমনি cloud audit trail-এ লেখা থাকে কোন পরিচয় কোন API call করল। Log-এর গঠন আর সেটআপ আছে Cloud নিরাপত্তার ভিত্তি পর্বে, আর log রক্ষার নীতি পর্ব ৫৫-এ। বিশ্লেষকের কাছে তিনটি বিষয় জরুরি:

• দুই ধরনের event: Management event বলে কে সেটিং বদলাল। Data event বলে কে কোন ফাইল পড়ল। দ্বিতীয়টি অনেক provider-এ নিজে থেকে চালু থাকে না, আর খরচ বাড়ায়। তাই শুধু সংবেদনশীল storage-এ চালু করা একটি বাস্তব মাঝপথ।
• Log আলাদা জায়গায়: যে account-এ ঘটনা ঘটছে, log সেখানে থাকলে দখলকারীও মুছতে পারেন। আলাদা account-এ, অপরিবর্তনীয় storage-এ রাখুন (Governance দেখুন)।
• Provider, SaaS, workload: Cloud-এর log, SaaS-এর log আর VM-এর log একসাথে SIEM-এ না এলে একটি ঘটনার গল্প টুকরো হয়ে থাকে (পর্ব ৫৬)।

যেগুলোতে সাধারণত alert দেওয়া হয়

নিচের খেলনা ব্যবস্থায় ১০টি বানানো event আছে। ঠিকানাগুলো documentation-এর জন্য সংরক্ষিত, ঘড়িও কাল্পনিক। লক্ষ করুন, কিছু নিয়ম একটি event দেখেই বাজে, আর একটি নিয়ম কয়েকটি event মিলিয়ে দেখে।

// Toy cloud audit log. Fake identities, documentation IP addresses, simulated clock.
const events = [
  { t: '09:02', who: 'alice', act: 'Login', mfa: true, ip: '198.51.100.7' },
  { t: '09:10', who: 'ci-deploy', act: 'UpdateService', ip: '198.51.100.20' },
  { t: '13:40', who: 'bob', act: 'Login', mfa: false, ip: '198.51.100.8' },
  { t: '14:01', who: 'ci-deploy', act: 'ListBuckets', ip: '203.0.113.9' },
  { t: '14:02', who: 'ci-deploy', act: 'GetPolicy', denied: true, ip: '203.0.113.9' },
  { t: '14:02', who: 'ci-deploy', act: 'ListUsers', denied: true, ip: '203.0.113.9' },
  { t: '14:03', who: 'ci-deploy', act: 'ListRoles', denied: true, ip: '203.0.113.9' },
  { t: '14:05', who: 'ci-deploy', act: 'CreateAccessKey', target: 'backup-svc', ip: '203.0.113.9' },
  { t: '14:07', who: 'ci-deploy', act: 'DisablePublicBlock', ip: '203.0.113.9' },
  { t: '14:09', who: 'ci-deploy', act: 'StopLogging', ip: '203.0.113.9' },
];
const knownIps = { 'ci-deploy': ['198.51.100.20'], alice: ['198.51.100.7'], bob: ['198.51.100.8'] };
const single = [
  ['CRIT', e => e.act === 'StopLogging', 'audit logging stopped'],
  ['HIGH', e => e.act === 'DisablePublicBlock', 'public access block turned off'],
  ['HIGH', e => e.act === 'CreateAccessKey' && e.target !== e.who, 'key created for another identity'],
  ['MED', e => e.act === 'Login' && !e.mfa, 'login without MFA'],
  ['MED', e => !knownIps[e.who].includes(e.ip), 'identity used from a new address'],
];
const alerts = [];
for (const e of events)
  for (const [sev, test, msg] of single)
    if (test(e)) alerts.push({ t: e.t, sev, who: e.who, msg, act: e.act });
// Correlation: 3 denied calls by one identity is a pattern, one denial is not.
const denied = {};
for (const e of events) if (e.denied) (denied[e.who] ||= []).push(e.t);
for (const [who, ts] of Object.entries(denied))
  if (ts.length >= 3) alerts.push({ t: ts[2], sev: 'HIGH', who, msg: ts.length + ' denied calls in a burst', act: '-' });
alerts.sort((a, b) => a.t.localeCompare(b.t));
for (const a of alerts) console.log(a.t, a.sev.padEnd(4), a.who.padEnd(10), a.act.padEnd(18), a.msg);
const ci = alerts.filter(a => a.who === 'ci-deploy').length;
console.log(events.length, 'events ->', alerts.length, 'alerts; ci-deploy has', ci, '= 1 incident to triage');

বাস্তবে এমন নিয়ম Sigma-র মতো নিরপেক্ষ ফরম্যাটে লেখা যায়। নিচে AWS-এর log ক্ষেত্র ধরে একটি উদাহরণ। আসল পরিবেশে চালানোর আগে নিজের field-এর নাম মিলিয়ে নিন।

title: Cloud Audit Logging Stopped or Deleted
status: experimental
description: Detects a change that stops or removes the audit trail
logsource:
    product: aws
    service: cloudtrail
detection:
    selection:
        eventSource: cloudtrail.amazonaws.com
        eventName:
            - StopLogging
            - DeleteTrail
            - UpdateTrail
    condition: selection
falsepositives:
    - Approved change by the platform team
level: high

৭ · Key-এর অপব্যবহার ধরা আর workload identity

স্থায়ী access key হলো এমন বাড়ির চাবি, যা বছরের পর বছর কেউ বদলায় না, আর কপি হলে তালা বুঝতেও পারে না। Long-lived credential-এর বিপদ সহজ: ফাঁসের দিন থেকে বাতিলের দিন পর্যন্ত পুরো সময়টাই ঝুঁকি। Key-এর বিস্তারিত আছে Cloud IAM আর Secret আর KMS পর্বে। বিশ্লেষক প্রথমে key-এর একটি হিসাব চান।

// Toy key report. Fake key ids, fixed "today" so the output never changes.
const TODAY = '2026-10-31';
const MAX_AGE = 90, IDLE = 60;
const keys = [
  { id: 'key-01', owner: 'ci-deploy', made: '2026-09-20', used: '2026-10-30', on: true, scope: 'deploy' },
  { id: 'key-02', owner: 'report-app', made: '2025-02-11', used: '2026-10-29', on: true, scope: 'read-data' },
  { id: 'key-03', owner: 'old-intern', made: '2024-06-03', used: '2024-12-15', on: true, scope: 'admin' },
  { id: 'key-04', owner: null, made: '2026-01-15', used: null, on: true, scope: 'read-data' },
  { id: 'key-05', owner: 'backup-svc', made: '2026-08-01', used: '2026-10-28', on: false, off: '2026-10-20', scope: 'backup' },
];
const day = s => Date.parse(s + 'T00:00:00Z') / 86400000;
const ago = s => day(TODAY) - day(s);

function review(k) {
  if (!k.on) return k.used > k.off ? ['INVESTIGATE', 'used after disable date'] : ['OK', 'disabled'];
  const idle = k.used ? ago(k.used) : ago(k.made);
  if (idle > IDLE) return [k.scope === 'admin' ? 'DISABLE NOW' : 'DISABLE', 'idle ' + idle + ' days'];
  if (ago(k.made) > MAX_AGE) return ['ROTATE', 'age ' + ago(k.made) + ' days'];
  return ['OK', 'in policy'];
}
console.log('key     owner       age   scope      action       why');
const tally = {};
for (const k of keys) {
  const [act, why] = review(k);
  tally[act] = (tally[act] || 0) + 1;
  console.log(k.id.padEnd(7), (k.owner || '(none)').padEnd(11), String(ago(k.made)).padStart(3),
    ' ', k.scope.padEnd(10), act.padEnd(12), why);
}
console.log(JSON.stringify(tally));
const active = keys.filter(k => k.on);
const avg = active.reduce((s, k) => s + ago(k.made), 0) / active.length;
console.log('active keys:', active.length, '| average age:', avg.toFixed(1), 'days');

চুরি যাওয়া key কীভাবে ধরা পড়ে

একটি key চুরি হলে log-এ সে বৈধ দেখায়। ধরা পড়ে আচরণে: নতুন ঠিকানা, নতুন অঞ্চল, যে API আগে কখনো ডাকেনি, Denied-এর ঝাঁক। পর্ব ৫৮-এর মতো baseline না থাকলে “নতুন” বোঝাই যায় না। একটি সহজ ফাঁদও আছে: honeytoken, কোনো কাজে লাগে না এমন একটি key, যেটি ব্যবহার হলেই নিশ্চিত সংকেত।

Workload identity মানে প্রোগ্রাম কোথায় চলছে, সেটিই তার পরিচয়ের প্রমাণ। VM, Kubernetes pod বা CI job, federation আর OIDC-এর মতো পথে অল্প মেয়াদের credential পায়। উদাহরণ হিসেবে AWS-এ IAM role, Azure-এ managed identity, Google Cloud-এ attached service account. চুরি গেলেও ক্ষতির সময় ছোট। তবে trust-এর শর্ত ঢিলা হলে, যেমন যেকোনো branch-কে deploy role দিলে, সমস্যা শুধু জায়গা বদলায়। সেই শর্তগুলোই এখন আপনার non-human identity-র audit-এর বিষয়।

৮ · Guardrail, ডেটা সুরক্ষা, multi-cloud আর SaaS posture

আগেই আটকানো

ধরা পড়ার পরে সারানোর চেয়ে ভুলটি হতে না দেওয়া সস্তা। ফ্লাইওভারের রেলিং গাড়ি চালায় না, শুধু পড়ে যাওয়া আটকায়। Guardrail তেমনি admin-এর হাতেও একটি সীমা রাখে। AWS-এর SCP, Azure Policy আর Google-এর Organization Policy একই লক্ষ্যের উদাহরণ। আর policy as code সেই নিয়মকে merge-এর আগেই পরীক্ষা করে। লেখার ধরন আর উদাহরণ আছে Governance পর্বে, মূল্যায়নের হিসাব IAM policy evaluation পর্বে। বিশ্লেষকের জন্য প্রথম পাঁচটি নিয়ম সাধারণত এমন:

1. Audit log বন্ধ বা log account মোছা নিষেধ।
2. প্রতিষ্ঠান জুড়ে public-access block, ব্যতিক্রম শুধু লিখিত অনুমোদনে।
3. অব্যবহৃত অঞ্চল বন্ধ।
4. নতুন VM-এ session-ভিত্তিক metadata বাধ্যতামূলক।
5. মানুষের জন্য স্থায়ী key তৈরি নিষেধ।

আগে “audit” বা শুধু-জানানোর ধরনে চালান, কারণ ভুল guardrail পুরো দলের কাজ থামাতে পারে। Break-glass-এর ব্যতিক্রমও আগে ঠিক করুন।

ডেটা সুরক্ষা: encryption একা যথেষ্ট নয়

Encryption at rest এখন অনেক সেবায় নিজে থেকেই চালু। এতে disk চুরির ঝুঁকি কমে। কিন্তু বৈধ role যদি ফাইল পড়তে চায়, সেবা নিজেই decrypt করে দেয়। Capital One-এর প্রকাশিত তথ্যও এই দিকেই ইঙ্গিত করে: বৈধ role-এর কাছে encryption কোনো দেয়াল নয়। Customer-managed key এখানে একটি দ্বিতীয় তালা দেয়, কারণ ডেটা পড়তে হলে KMS-এ key ব্যবহারের অনুমতিও লাগে, আর সেই ব্যবহার log-এ থাকে। Secret আর KMS পর্বে envelope encryption দেখুন।

Public-access block হলো সেই বাইরের সিটকিনি, যা ভেতরের ভুল অনুমতিকেও অকেজো করে। AWS এপ্রিল ২০২৩ থেকে নতুন S3 bucket-এ এটি নিজে থেকে চালু রাখে, তবে পুরোনো bucket-এ এই বদল আসেনি। তাই পুরোনো সম্পদের হিসাব আলাদা করে দেখতে হয়। Azure Storage আর Google Cloud Storage-এ একই লক্ষ্যের সেটিং আছে, নাম আলাদা।

Multi-cloud: মনোযোগের খরচ

দুই cloud মানে দুই গুণ নিরাপত্তা নয়, প্রায়ই দুই গুণ শেখা। প্রতিটির IAM আলাদা, log আলাদা, default আলাদা। একটি হিসাব ধরুন, সব সংখ্যা আমাদের অনুমান: প্রতি cloud-এ ৪০টি জরুরি detection rule, বছরে প্রতিটির পর্যালোচনায় ২ ঘণ্টা। তিন cloud-এ ৪০ × ৩ × ২ = ২৪০ ঘণ্টা, মানে একজনের প্রায় ছয় সপ্তাহ, আর এটি শুধু rule দেখার সময়। Multi-cloud-এর ব্যবসায়িক কারণ থাকতে পারে, কিন্তু সবচেয়ে ভালো জানা cloud-এ ভালো নিরাপত্তা প্রায়ই তিন cloud-এর পাতলা নিরাপত্তার চেয়ে ভালো।

SaaS-এর posture

প্রতিষ্ঠানের ডেটার বড় অংশ এখন email, ফাইল শেয়ার, CRM-এর মতো SaaS-এ। CSPM সেখানে পৌঁছায় না, তাই SSPM বা হাতের চেকলিস্ট লাগে। দেখুন: সব account-এ MFA আর SSO সত্যিই চালু কি, প্রকাশ্য link কয়টি, কোন OAuth app ডেটা পড়ে, প্রাক্তন কর্মীর account বন্ধ কি, আর audit log কত দিন থাকে। Snowflake-এর গ্রাহকদের ঘটনা এই তালিকার প্রথম তিনটি প্রশ্নেরই গল্প।

৯ · Cloud incident: session বন্ধ, snapshot রাখা, তারপর ফেরা

পর্ব ৬১ আর পর্ব ৬২-এর ধাপগুলোই এখানে খাটে। Cloud-এ তিনটি বদল আছে। প্রমাণ দ্রুত হারায়, কারণ autoscaling যন্ত্র মুছে দিতে পারে। Containment-এর প্রথম হাতিয়ার network নয়, identity. আর প্রমাণ সংগ্রহ করা যায় API দিয়ে। কাল্পনিক ঘটনাটি দেখুন।

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

AI একটি finding-এর তালিকা গুছিয়ে দিতে, policy পড়ে ব্যাখ্যা করতে আর log query লিখতে সত্যিই কাজে লাগে। কিন্তু cloud-এ একটি ভুল পরামর্শ এক ক্লিকে পুরো account-এ ছড়ায়। আর AI-কে cloud-এ চালানো agent নিজেই একটি নতুন non-human identity, যার অনুমতিও ছোট রাখতে হয় (পর্ব ৫১)।

AI-এর cloud পরামর্শ ব্যবহারের চেকলিস্ট

• Prompt-এ কোনো key, token, আসল account নম্বর বা ব্যক্তিগত তথ্য নেই
• প্রস্তাবিত policy-র diff লাইন ধরে পড়েছি, wildcard খুঁজেছি
• নিজের পরীক্ষার account-এ চালিয়ে দেখেছি, production-এ নয়
• প্রতিটি API, setting আর CVE মূল নথিতে মিলিয়েছি
• Public করা, role বড় করা আর log বন্ধ করার সিদ্ধান্ত মানুষ নিয়েছেন