Zero trust architecture — NIST SP 800-207 থেকে বাস্তবায়ন

১ · দুর্গের দেয়াল কেন যথেষ্ট রইল না

পুরোনো জমিদার বাড়ি ভাবুন। চারপাশে উঁচু দেয়াল, ফটকে দারোয়ান। ভেতরে ঢুকলে সব ঘর খোলা, কেউ আর প্রশ্ন করে না। এবার একটি ব্যাংক ভাবুন। ফটক পার হলেই লকার খোলে না। লকার কক্ষে আলাদা রেজিস্টার, আলাদা পরিচয় যাচাই, দুটি চাবি আর ক্যামেরা। প্রথমটি perimeter মডেল, দ্বিতীয়টি zero trust-এর কাছাকাছি।

Perimeter মডেলের ভিত্তি হলো implicit trust: অফিসের network-এ আছেন, তাই বিশ্বস্ত। এই ধারণা তিন কারণে ভেঙেছে।

• দেয়ালের ভেতর আর বাইরে মুছে গেছে। কর্মী বাড়ি থেকে কাজ করেন, ডেটা SaaS-এ, সার্ভার cloud-এ, ফোন ব্যক্তিগত।
• একটি ফাঁকই যথেষ্ট। একটি phishing বা চুরি হওয়া VPN login মানে ভেতরে পা রাখা। এরপর lateral movement আটকানোর কিছু থাকে না।
• ভেতরের ট্রাফিক দেখা হয় না। Firewall দেখে north-south traffic, কিন্তু ক্ষতি ছড়ায় east-west traffic-এ।

আক্রমণকারীর দিক থেকে দেখুন: তার লক্ষ্য দেয়াল ভাঙা নয়, একটি বৈধ পরিচয় পাওয়া। রক্ষকের দিক থেকে প্রশ্নটি তাই বদলে যায়। “কীভাবে ঢোকা ঠেকাব” নয়, বরং “কেউ ঢুকে পড়লে সে কতদূর যেতে পারবে, আর কত দ্রুত ধরা পড়বে”। NIST-এর ভাষায় network-কে আগে থেকেই আক্রান্ত ধরে নিয়ে নকশা করতে হয়। মানসিকতার পরিচয় পেয়েছেন পর্ব ৩-এ, আর remote access-এর দিক দেখেছেন পর্ব ২৫-এ। এখানে পুরো architecture.

২ · NIST SP 800-207 — সাতটি tenet আর তিনটি ভূমিকা

NIST সংজ্ঞা দিয়েছে সাতটি basic tenet বা মূল নীতি দিয়ে। নথিটি নিজেই বলে, এগুলো আদর্শ লক্ষ্য, প্রতিটি পুরোপুরি বাস্তবায়ন নাও হতে পারে। আরেকটি সীমা: এগুলো প্রতিষ্ঠান আর সহযোগীদের কাজের জন্য, সাধারণ গ্রাহকের ওপর চাপানোর জন্য নয়।

এবার ভূমিকাগুলো। ব্যাংকের লকার কক্ষের উদাহরণে ফিরি। শাখা ব্যবস্থাপক ফাইল দেখে অনুমতি দেন। অপারেশন অফিসার স্লিপ তৈরি করে দারোয়ানকে জানান। দারোয়ান দরজায় স্লিপ মিলিয়ে ঢুকতে দেন, আর সময় শেষ হলে বের করে দেন।

PE আর PA মিলে PDP (পর্ব ১৯)। অনেক পণ্যে দুটি একসাথে থাকে; NIST আলাদা করে যুক্তির সুবিধার জন্য। PEP-এর পেছনের জায়গাকে বলে implicit trust zone, যাকে যত ছোট রাখা যায় তত ভালো।

Control plane আর data plane আলাদা রাখার কারণ সহজ। সিদ্ধান্তের পথ সাধারণ ব্যবহারকারীর নাগালে থাকলে আক্রমণকারী সিদ্ধান্তকেই প্রভাবিত করার চেষ্টা করবে। এখন একটি অনুরোধকে পুরো পথে হাঁটিয়ে দেখি। সুমাইয়া কাল্পনিক একটি প্রতিষ্ঠানের হিসাব বিভাগের কর্মী, বাড়ি থেকে সংবেদনশীল ledger app খুলছেন। সব মান আর নম্বর এই পর্বের toy policy থেকে, যা পরের অংশে কোডে দেখবেন। ধাপের ক্রম NIST-এর device agent/gateway মডেল অনুসরণ করে।

৩ · Trust algorithm আর policy নকশা

PE-র ভেতরের যুক্তিকে NIST বলে trust algorithm. দুটি অক্ষে এর রকম ভাগ হয়।

• Criteria বনাম score: Criteria-ভিত্তিক নিয়মে সব শর্ত পূরণ হতে হয়। Score-ভিত্তিক নিয়মে প্রতিটি উৎসের ওজন মিলিয়ে একটি confidence হিসাব হয়, আর বার পার হলে access মেলে।
• Singular বনাম contextual: Singular নিয়মে প্রতিটি অনুরোধ আলাদা। Contextual নিয়মে সাম্প্রতিক ইতিহাস দেখা হয়। একই account হঠাৎ অনেক বেশি record চাইলে singular নিয়ম কিছু টের পায় না, contextual পায়। NIST contextual-কে আদর্শ বলে, তবে অবকাঠামো সবসময় তা দেয় না।

নিচের toy engine score আর একটি কড়া নিয়ম একসাথে ব্যবহার করে। বাস্তব পণ্য এভাবেই চলবে, এমন দাবি নেই; ওজনগুলো বানানো, শেখার জন্য।

// Toy policy engine (score-based). No real system; every name and weight is made up.
const POINTS = {
  auth: { passkey: 40, totp: 30, password: 10 },
  device: { managed: 35, byod: 15, unknown: 0, unhealthy: 0 },
  place: { usual: 20, newcity: 10, impossible: 0 },   // office and home are both "usual"
};
const BAR = {                  // resource sensitivity: score needed
  low: { allow: 50, stepUp: 30 },
  medium: { allow: 70, stepUp: 50 },
  high: { allow: 90, stepUp: 65 },
};
function decide(r) {
  if (r.device === 'compromised') return { score: 0, verdict: 'DENY (hard rule)' };
  const score = POINTS.auth[r.auth] + POINTS.device[r.device] + POINTS.place[r.place];
  const { allow, stepUp } = BAR[r.sens];
  return { score, verdict: score >= allow ? 'ALLOW' : score >= stepUp ? 'STEP-UP' : 'DENY' };
}
const REQUESTS = [
  ['sumaiya', 'ledger', 'high', 'totp', 'managed', 'usual'],
  ['sumaiya', 'ledger', 'high', 'passkey', 'managed', 'usual'],
  ['karim', 'wiki', 'low', 'password', 'byod', 'usual'],
  ['karim', 'crm', 'medium', 'totp', 'byod', 'newcity'],
  ['vendor', 'wiki', 'low', 'totp', 'unknown', 'usual'],
  ['nadia', 'ledger', 'high', 'password', 'unknown', 'impossible'],
  ['rafiq', 'wiki', 'low', 'passkey', 'compromised', 'usual'],
];
const tally = {};
console.log('user    resource sens   auth     device      place      score verdict');
for (const [user, res, sens, auth, device, place] of REQUESTS) {
  const d = decide({ sens, auth, device, place });
  tally[d.verdict] = (tally[d.verdict] || 0) + 1;
  console.log(user.padEnd(8) + res.padEnd(9) + sens.padEnd(7) + auth.padEnd(9) + device.padEnd(12) +
    place.padEnd(11) + String(d.score).padStart(5) + ' ' + d.verdict);
}
console.log('totals:', JSON.stringify(tally));

user    resource sens   auth     device      place      score verdict
sumaiya ledger   high   totp     managed     usual         85 STEP-UP
sumaiya ledger   high   passkey  managed     usual         95 ALLOW
karim   wiki     low    password byod        usual         45 STEP-UP
karim   crm      medium totp     byod        newcity       55 STEP-UP
vendor  wiki     low    totp     unknown     usual         50 ALLOW
nadia   ledger   high   password unknown     impossible    10 DENY
rafiq   wiki     low    passkey  compromised usual          0 DENY (hard rule)
totals: {"STEP-UP":3,"ALLOW":2,"DENY":1,"DENY (hard rule)":1}

ভালো policy দেখতে কেমন

Policy লেখা হয় ব্যবসার কাজ ধরে, IP ঠিকানা ধরে নয়। প্রশ্নগুলো: কে, কোন resource, কোন কাজ, কী শর্তে, কে এর মালিক, কবে আবার দেখা হবে। নিচের উদাহরণ একটি কাল্পনিক ফরম্যাট, কোনো পণ্যের syntax নয়।

# উদাহরণ: কাল্পনিক ফরম্যাট
id: ledger-post
owner: finance-lead
resource: ledger
sensitivity: high
subjects: [group:finance]
actions: [read, post]
require:
  auth: phishing-resistant
  device: [managed, healthy, disk-encrypted]
deny_if: [threat_feed.device_flagged]
on_change: re-evaluate-session
mode: audit          # আগে দেখা, পরে enforce
review_by: 2027-03-31

• Policy-কে কোডের মতো রাখুন। Policy as code: review, পরীক্ষা, পুরোনো সংস্করণে ফেরার সুযোগ।
• আগে দেখুন, পরে আটকান। Audit mode-এ নিয়ম কিছু আটকায় না, শুধু লেখে কী আটকে যেত। এই log দেখেই enforcement mode-এ যাওয়া নিরাপদ।
• ব্যতিক্রমের মেয়াদ রাখুন। প্রতিটি policy exception-এর মালিক আর শেষ তারিখ চাই।
• জরুরি পথ রাখুন। Break-glass account শক্তভাবে রক্ষিত, পরীক্ষিত, আর প্রতিটি ব্যবহারে alert.

৪ · Deployment-এর রূপ — একই নীতি, ভিন্ন দরজা

NIST তিনটি approach বলে, যেগুলোর ঝোঁক আলাদা। Enhanced identity governance-এ পরিচয়ই প্রধান। Micro-segmentation-এ gateway বা host firewall দিয়ে resource ঘিরে রাখা হয়। Network infrastructure আর software defined perimeter-এ network স্তরে পথ তৈরি হয়। পূর্ণ সমাধানে সাধারণত এগুলো মিশে থাকে। PEP কোথায় বসবে, তার চারটি রূপ:

ছোট প্রতিষ্ঠানে প্রায়ই মিশ্রণ চলে: নিজের laptop-এ agent, ব্যক্তিগত ফোনে portal, আর পুরোনো ERP-তে enclave gateway. Identity-aware proxy আর ZTNA এই ছকেই পড়ে। মানুষের বাইরে service-এর ক্ষেত্রেও একই নীতি: service account-এর বদলে workload identity, আর service mesh-এ mTLS. Cloud আর container-এর দিক আছে পর্ব ৭২ আর পর্ব ৭৩-এ।

৫ · Continuous verification — session-এর মাঝেই সিদ্ধান্ত বদলায়

ধরুন কেউ লকার কক্ষে ঢুকলেন। পরে ব্যাংক খবর পেল তাঁর পরিচয়পত্র বাতিল। দারোয়ান কি সন্ধ্যা পর্যন্ত অপেক্ষা করবেন? Continuous verification মানে session চলাকালে নতুন তথ্য এলে সিদ্ধান্ত আবার হয়। NIST-এর উদাহরণ: সময় পেরোনো, নতুন resource চাওয়া, resource বদলানো, অস্বাভাবিক আচরণ। শর্তগুলো policy ঠিক করে, যাতে নিরাপত্তা, সুবিধা আর খরচের ভারসাম্য থাকে।

“Continuous” মানে প্রতি সেকেন্ডে নয়। এটি মিলিয়ে তৈরি হয় তিন জিনিসে: ছোট মেয়াদের token, নির্দিষ্ট সময়ে যাচাই, আর ঘটনা ঘটলে সংকেত। সুমাইয়ার session-এ একটি বদল দেখুন।

কত ঘন ঘন যাচাই করবেন? নিচের সিমুলেশনে একই ঘটনা চারটি কৌশলে, আট ঘণ্টার session আর ২০০ জন ধরে। ঘড়িটি কৃত্রিম, আর প্রতি session-এ ৬টি device-সংকেত একটি ধরে নেওয়া সংখ্যা।

// Session re-evaluation on a simulated clock (minutes after 09:00). Toy model.
const SHIFT = 480;             // an 8-hour working session
const POSTURE_BAD_AT = 23;     // 09:23: EDR stops on the laptop
const USERS = 200;             // assumed staff who each hold one session
const DEVICE_EVENTS = 6;       // assumed posture events per session, per user
const STRATEGIES = [
  { name: 'login only', every: Infinity },
  { name: 'every 60 min', every: 60 },
  { name: 'every 15 min', every: 15 },
  { name: 'event signal', every: Infinity, signalDelay: 2 },
];
const clock = (m) => {
  const h = 9 + Math.floor(m / 60);
  return String(h).padStart(2, '0') + ':' + String(m % 60).padStart(2, '0');
};
function run(s) {
  for (let t = 0; t <= SHIFT; t++) {           // one tick = one simulated minute
    const timed = t > 0 && t % s.every === 0;
    const pushed = s.signalDelay !== undefined && t === POSTURE_BAD_AT + s.signalDelay;
    if ((timed || pushed) && t >= POSTURE_BAD_AT) return t;   // this check sees the bad posture
  }
  return SHIFT;                                // nothing noticed: the session just ends
}
function checksPerDay(s) {
  const each = s.signalDelay !== undefined ? DEVICE_EVENTS
    : s.every === Infinity ? 0 : Math.floor(SHIFT / s.every);
  return USERS * (1 + each);                   // +1 for the check at login
}
console.log('strategy       session ends  exposed min  policy checks/day');
for (const s of STRATEGIES) {
  const end = run(s);
  console.log(s.name.padEnd(15) + clock(end).padEnd(14) +
    String(end - POSTURE_BAD_AT).padStart(11) + String(checksPerDay(s)).padStart(19));
}

strategy       session ends  exposed min  policy checks/day
login only     17:00                 457                200
every 60 min   10:00                  37               1800
every 15 min   09:30                   7               6600
event signal   09:25                   2               1400

৬ · Microsegmentation আর trust zone-এর আকার

Zero trust-এর মূল প্রতিশ্রুতি ঢোকা বন্ধ করা নয়, নাগাল ছোট করা। Network-এর ভাষায় একে বলে blast radius কমানো। পর্ব ২২-এ zone আর VLAN দেখেছেন। Microsegmentation আরও ছোট: প্রতিটি workload-এর চারপাশে নিজের নিয়ম, default deny সহ, আর নিয়ম লেখা হয় পরিচয় বা ট্যাগ ধরে। মহল্লার ফটকের পাহারা থেকে প্রতিটি ফ্ল্যাটের নিজের তালায় যাওয়ার মতো।

নিচের কোড ৯টি সিস্টেমের একটি কাল্পনিক network-এ দেখে, একটি sales PC আক্রান্ত হলে worst case-এ কতদূর পৌঁছানো যায়। এখানে ধরে নেওয়া হয়েছে পৌঁছানো প্রতিটি যন্ত্রও দখল হয়, তাই পথ ধাপে ধাপে অনুসরণ করা হয়। এটি মেমরিতে একটি graph মাত্র, কোনো packet যায় না। পর্ব ২৫-এর হিসাব ছিল এক ধাপের নাগাল; এখানে পরপর ধাপ।

// Trust-zone reach on a toy network of 9 systems. In-memory only; no packet is sent.
const HOSTS = ['pc-sales', 'pc-hr', 'file', 'web', 'api', 'db-hr', 'db-fin', 'backup', 'jump'];
const JEWELS = ['db-hr', 'db-fin', 'backup', 'jump'];
const flat = () => HOSTS.flatMap((a) => HOSTS.filter((b) => b !== a).map((b) => [a, b]));
const SEGMENTED = [           // allow-list: only the paths the work really needs
  ['pc-sales', 'web'], ['pc-hr', 'web'], ['pc-sales', 'file'], ['pc-hr', 'file'],
  ['web', 'api'], ['api', 'db-fin'], ['jump', 'db-fin'], ['jump', 'db-hr'], ['jump', 'backup'],
];
const EXCEPTION = [['pc-sales', 'jump']];   // a "temporary" rule nobody removed
// Worst-case reach: assume each host reached can also be taken over, so follow every path.
function reach(start, edges) {
  const seen = new Set([start]), queue = [start];
  while (queue.length) {
    const here = queue.shift();
    for (const [a, b] of edges) {
      if (a === here && !seen.has(b)) { seen.add(b); queue.push(b); }
    }
  }
  seen.delete(start);
  return [...seen];
}
function show(name, edges) {
  const r = reach('pc-sales', edges);
  const jewels = r.filter((h) => JEWELS.includes(h));
  console.log(name.padEnd(22) + String(edges.length).padStart(5) +
    String(r.length).padStart(7) + String(jewels.length).padStart(8) + '  ' + jewels.join(' '));
}
console.log('network                paths  reach  jewels  which');
show('flat zone', flat());
show('allow-list', SEGMENTED);
show('allow-list + exception', [...SEGMENTED, ...EXCEPTION]);

network                paths  reach  jewels  which
flat zone                72      8       4  db-hr db-fin backup jump
allow-list                9      4       1  db-fin
allow-list + exception   10      7       4  jump db-fin db-hr backup

শুরু করবেন কোথা থেকে

• আগে সবচেয়ে দামি জিনিস: Database, backup, admin system. পুরো network একবারে নয়।
• আগে ট্রাফিক দেখুন: কে কার সাথে কথা বলে তা না জেনে নিয়ম লিখলে কাজ থামবে।
• Workstation থেকে workstation বন্ধ করুন: সাধারণত সস্তা, আর lateral movement-এর বড় পথ কমায়। Host firewall দিয়েই শুরু করা যায়।
• Admin পথ এক জায়গায়: Jump host, just-in-time access আর MFA (পর্ব ২০)।

CISA ২০২৫ সালের জুলাইয়ে Microsegmentation in Zero Trust, Part One প্রকাশ করেছে, যেখানে পুরোনো আর নতুন, দুই ধরনের পরিবেশের জন্য ধাপভিত্তিক পরিকল্পনা আছে।

৭ · CISA Zero Trust Maturity Model — আমরা কোথায় আছি

CISA-র Zero Trust Maturity Model Version 2.0 (এপ্রিল ২০২৩) মূলত যুক্তরাষ্ট্রের ফেডারেল সংস্থার জন্য লেখা, তবে যে কেউ নিজের অবস্থান বুঝতে ব্যবহার করতে পারেন। CISA নিজেই বলে, এটি কড়া শর্তের তালিকা নয়, একটি পথনির্দেশ। তাই একে সার্টিফিকেট ভাববেন না। ২০২৬ সালের নভেম্বরে CISA-র সাইটে মডেলের পাতাটি “archived” চিহ্নিত দেখা গেছে, তাই ব্যবহারের আগে এর বর্তমান অবস্থা মিলিয়ে নিন। এতে পাঁচটি pillar, তিনটি cross-cutting capability আর চারটি stage আছে। Version 1.0 (২০২১)-এর তুলনায় নতুন যোগ হয়েছে Initial stage.

তিনটি cross-cutting capability সব pillar-এ চলে: Visibility and Analytics, Automation and Orchestration, Governance. Stage-গুলো সংক্ষেপে: Traditional মানে হাতে সাজানো, স্থির policy, আলাদা আলাদা pillar. Initial মানে স্বয়ংক্রিয়তার শুরু আর প্রথম cross-pillar সমাধান। Advanced মানে কেন্দ্রীয় দৃশ্যমানতা আর ঝুঁকি দেখে অধিকার বদলানো। Optimal মানে পূর্ণ স্বয়ংক্রিয়, just-in-time, ধারাবাহিক নজরদারি। Identity-তে এর একটি উদাহরণ: Initial-এ MFA, Advanced-এ phishing-প্রতিরোধী MFA-র দিকে যাওয়া, Optimal-এ access-এর পরেও ধারাবাহিক যাচাই।

CISA কোনো numeric score দেয় না। নিচের ছোট scorer শুধু একটি নিজ-যাচাইয়ের ধারণা, আর প্রমাণের তালিকা সরলীকৃত। মূল নিয়ম: আগের stage-এর প্রমাণ না থাকলে পরেরটি গোনা হবে না। ক্রমটি (Identity, Devices, Applications, Networks, Data) আমাদের বাস্তবায়নের ক্রম, CISA-র নিয়ম নয়।

// Toy maturity scorer. CISA gives no numeric score; this self-check is only an illustration.
const STAGES = ['Traditional', 'Initial', 'Advanced', 'Optimal'];
const ORDER = ['Identity', 'Devices', 'Applications', 'Networks', 'Data']; // our build order
const NEXT = {      // the evidence needed to enter Initial, Advanced, Optimal
  Identity: ['MFA for everyone', 'phishing-resistant MFA', 'continuous validation'],
  Devices: ['inventory + MDM', 'posture in access policy', 'real-time posture'],
  Applications: ['apps behind SSO', 'per-app access, no flat VPN', 'continuous authorization'],
  Networks: ['macro-segmentation', 'micro-segment key systems', 'dynamic micro-perimeters'],
  Data: ['data inventory', 'labels + access by label', 'automated data protection'],
};
// One character per stage: 1 = evidence seen, 0 = not yet. A stage counts only
// if every earlier stage is also met, so "101" cannot score as Optimal.
const stage = (bits) => { const gap = bits.indexOf('0'); return gap < 0 ? 3 : gap; };
function report(title, org) {
  console.log('--- ' + title);
  let target = null;
  for (const p of ORDER) {
    const s = stage(org[p]);
    const odd = org[p].slice(s).includes('1') ? '  claim above a gap' : '';
    console.log(p.padEnd(13) + org[p] + '  ' + STAGES[s].padEnd(12) + odd);
    if (s < 3 && (target === null || s < stage(org[target]))) target = p;
  }
  const s = stage(org[target]);
  console.log(`next: ${target} -> ${STAGES[s + 1]}: ${NEXT[target][s]}`);
}
report('month 0', { Identity: '001', Devices: '000', Applications: '000', Networks: '100', Data: '000' });
report('month 6', { Identity: '110', Devices: '000', Applications: '100', Networks: '100', Data: '000' });
report('month 14', { Identity: '110', Devices: '110', Applications: '110', Networks: '100', Data: '000' });

--- month 0
Identity     001  Traditional   claim above a gap
Devices      000  Traditional 
Applications 000  Traditional 
Networks     100  Initial     
Data         000  Traditional 
next: Identity -> Initial: MFA for everyone
--- month 6
Identity     110  Advanced    
Devices      000  Traditional 
Applications 100  Initial     
Networks     100  Initial     
Data         000  Traditional 
next: Devices -> Initial: inventory + MDM
--- month 14
Identity     110  Advanced    
Devices      110  Advanced    
Applications 110  Advanced    
Networks     100  Initial     
Data         000  Traditional 
next: Data -> Initial: data inventory

মাস ৬-এর ফল হাতে নিয়ে একটি সিদ্ধান্ত নিন। Score পরের কাজের ইঙ্গিত দেয়, সিদ্ধান্ত দেয় মানুষ। ধরে নেওয়া তথ্য: ২০০ জন কর্মী, ২৪০টি device, IT-তে দুজন।

৮ · ২০০ জনের একটি প্রতিষ্ঠানের roadmap

কাল্পনিক “সবুজপথ লজিস্টিকস”: ঢাকায় প্রধান কার্যালয়, চারটি ডিপো, ২০০ জন কর্মী, দুজন IT কর্মী। Cloud email, একটি পুরোনো on-premises ERP, একটি VPN, আর অনেকের ব্যক্তিগত ফোন। সময়গুলো ধরে নেওয়া; আসল সময় প্রতিষ্ঠানভেদে আলাদা। NIST-ও আগে asset, subject আর business process-এর তালিকা চায়, কারণ অসম্পূর্ণ তথ্যে PE ন্যায্য অনুরোধও আটকে দেয়। Shadow IT এখানেই ধরা পড়ে।

Network কোথায়? ধাপ ৩-এ শুরু, আর চলে পরেও; এই ছোট দলের জন্য আগে macro-segmentation, তারপর শুধু দামি সিস্টেমের চারপাশে microsegmentation. যত বড় প্রকল্পই হোক, নিয়ম একই: এক business process ধরে এগোন, পাইলট, মাপা, তারপর বিস্তার। NIST SP 800-207-এর অংশ ৭-এর ধাপও এই পথেই: actor আর asset চেনা, process আর ঝুঁকি দেখা, policy লেখা, সমাধান বাছা, শুরুতে নজরদারি, তারপর বিস্তার।

অগ্রগতি মাপা

“আমরা ৬০% zero trust”, এমন কথার মানে নেই। মাপুন এমন কিছু যা ঝুঁকি বা কাজের সাথে যুক্ত। নিচের KPI-এর সংখ্যাগুলো কাল্পনিক, শুধু হিসাব দেখানোর জন্য। পুরো metric-এর চিন্তা পর্ব ৬৭-এ।

শুধু মাপ রাখা যথেষ্ট নয়। প্রতি ত্রৈমাসিকে একটি নিয়ন্ত্রিত পরীক্ষা করুন: একটি পরীক্ষার account-এর device খারাপ দেখিয়ে session কত দ্রুত বন্ধ হয়, তা মাপুন। এমন পরীক্ষা নিজের পরিবেশে, লিখিত অনুমতিতে করুন। অন্যের সিস্টেমে যাচাই করা অপরাধ হতে পারে (পর্ব ৬)।

৯ · Zero trust কী নয়, আর কোথায় ব্যর্থ হয়

সাধারণ ব্যর্থতা

NIST নিজেও ZTA-র ঝুঁকির তালিকা দেয়: PE বা PA-র সিদ্ধান্ত প্রক্রিয়াকে প্রভাবিত করা, PEP-এ denial of service, চুরি হওয়া credential আর insider threat, এনক্রিপ্টেড ট্রাফিকে দৃশ্যমানতার অভাব, policy আর log-এর ভাণ্ডার নিজেই দামি নিশানা হওয়া, আর বিক্রেতার ওপর নির্ভরতা। PDP তাই একটি নতুন trust anchor, আর তাকে সবচেয়ে কড়া নিরাপত্তায় রাখতে হয়।

ZTA, ZTNA, SSE আর SASE

SSE বা SASE একটি বিতরণের ধরন, যা zero trust-এর PEP হিসেবে কাজ করতে পারে। এগুলো কিনলে zero trust হয় না, আর zero trust-এর জন্য এগুলো বাধ্যতামূলকও নয়। এটি একটি vendor নির্ভরতাও বটে: সেবা বন্ধ হলে আপনার সব access-এ প্রভাব পড়ে।

১০ · AI-এর যুগে zero trust

AI policy খসড়া, log সারাংশ আর gap তালিকায় ভালো সহায়ক। তবে zero trust-এর সিদ্ধান্ত মানুষের কাজ আটকে দিতে পারে, তাই ভুলের দাম বেশি। AI প্রায়ই NIST-এর ধারার নম্বর, CISA-র stage-এর ভাষা বা অস্তিত্বহীন CVE বানিয়ে বলে, পুরোনো crypto (MD5, ECB) পরামর্শ দেয়, আর আত্মবিশ্বাস নিয়ে ভুল ঝুঁকি-রায় দেয়। কাজ দ্রুত করতে broad allow নিয়ম, verify=False বা বড় CORS খোলার পরামর্শও আসে, আর তার লেখা কোডে authorization যাচাই বাদ পড়তে পারে। AI agent নিজেও একটি subject: তারও পরিচয়, সীমিত অধিকার আর log চাই (পর্ব ৫১)।

AI-এর পরামর্শ ব্যবহারের আগে

• Standard-এর দাবি মূল NIST বা CISA দলিলে মিলিয়েছি
• AI-এর লেখা policy আগে audit mode-এ চালিয়েছি, সরাসরি enforce করিনি
• নিয়মে broad wildcard, যাচাই বন্ধ করা বা মেয়াদহীন exception নেই
• Prompt-এ কোনো secret, ব্যক্তিগত ডেটা বা আসল log দিইনি
• মানুষের কাজ আটকে দেয় এমন সিদ্ধান্তে একজন মানুষ দায়িত্ব নিয়েছেন
• Break-glass পথ কাজ করে কি না নিজের পরিবেশে যাচাই করেছি