নিরাপত্তার মূলনীতি — least privilege, defense in depth আর fail secure

১ · Tool বদলায়, নীতি বদলায় না

একটি কাল্পনিক অনলাইন বাজারের কথা ভাবুন। প্রতিষ্ঠানটি দামি firewall কিনেছে, antivirus বসিয়েছে, password-এ বড় হাতের অক্ষর বাধ্যতামূলক করেছে। তবু একদিন দেখা গেল, পুরো গ্রাহক তালিকা বাইরে চলে গেছে। তদন্তে যা বের হলো, তাতে কোনো জটিল কৌশল নেই। এক support কর্মীর account-এ পুরো database দেখার অনুমতি ছিল, যদিও তাঁর কাজে লাগত মাত্র কয়েকটি অর্ডার। সেই account-এর password চুরি হলো, আর কেউ টেরই পেল না।

সমস্যাটি tool-এর অভাব নয়। সমস্যা হলো নীতির অভাব। প্রতিটি tool-এর পেছনে একটি প্রশ্ন থাকে: কাকে কতটুকু দেওয়া হবে, একটি বাধা ভাঙলে পরেরটি কী, আর কিছু নষ্ট হলে সিস্টেম কোন দিকে যাবে? এই প্রশ্নগুলোর উত্তর যে চিন্তার কাঠামো থেকে আসে, সেটিই নিরাপত্তার মূলনীতি।

পর্ব ০২-এ কথা হয়েছে কী রক্ষা করতে হবে: confidentiality, integrity, availability. এই পর্বের প্রশ্ন হলো, সেটি কীভাবে নকশা করতে হবে। নিয়ন্ত্রণ বাছাইয়ের আগে এই নীতিগুলো মাথায় থাকলে অনেক দামি ভুল শুরুতেই আটকে যায়।

২ · আটটি নকশা-নীতি আর দুটি বাড়তি নোট

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

Open design আর Kerckhoffs-এর উত্তরাধিকার

Open design-এর শিকড় আরও পুরোনো। ১৮৮৩ সালে Auguste Kerckhoffs সামরিক cryptography নিয়ে লিখেছিলেন, পদ্ধতিটি শত্রুর হাতে পড়লেও যেন সিস্টেম ভেঙে না পড়ে। Kerckhoffs-এর নীতি আর ১৯৪৯ সালে Claude Shannon-এর “শত্রু সিস্টেমটি জানে” কথাটি একই চিন্তা। পর্ব ০৭ (Cryptography-র ভিত্তি) এই নীতি থেকেই শুরু হবে। উল্টো চর্চাটির নাম security through obscurity, অর্থাৎ শুধু লুকিয়ে রেখে নিরাপদ থাকার আশা। গোপনীয়তা বাড়তি বাধা হতে পারে, কিন্তু একমাত্র ভিত্তি হলে একবার ফাঁসেই সব শেষ, আর নকশা বদলানো চাবি বদলানোর মতো সহজ নয়।

দুটি বাড়তি নোট, যা লেখকেরা আলাদা করে রেখেছিলেন

লেখকেরা এ দুটিকে ভৌত নিরাপত্তার ধারণা বলেছিলেন, যা কম্পিউটারে পুরোপুরি খাটে না। কম্পিউটার নিজেই হিসাব করতে পারে, তাই work factor হঠাৎ কমে যেতে পারে; আর log-ও মুছে ফেলা যায়। তবু আজ দুটিই জীবন্ত। Work factor-এর একটি ছোট হিসাব দেখুন:

৩ · Least privilege আর default deny — ভুলকেও নিরাপদ দিকে ঠেলে দেওয়া

Least privilege ক্ষতির সীমা ঠিক করে। অনুমতি যত ছোট, চুরি যাওয়া account বা ভুল প্রোগ্রাম তত কম ক্ষতি করতে পারে। একে বলা হয় blast radius কমানো। শুরুর কাল্পনিক ঘটনায় support কর্মীর account-এ শুধু নিজের টিকিটের অর্ডার দেখার অনুমতি থাকলে password চুরি হলেও পুরো তালিকা বের হতো না।

Least privilege শুধু মানুষের জন্য নয়। একটি web server যদি root হিসেবে চলে, তার একটি ত্রুটি পুরো মেশিনের ত্রুটি হয়ে দাঁড়ায়। OS-এর দিক থেকে এর ভিত্তি Operating Systems-এর protection পর্বে আছে, আর বাস্তব নকশা আসবে পর্ব ১৯ (Authorization model) ও পর্ব ২০-এ (Privileged access).

Fail-safe defaults কথাটির অর্থ হলো: default deny. প্রশ্নটি “এই কাজ কি নিষিদ্ধ?” নয়, প্রশ্নটি “এই কাজের অনুমতি কি স্পষ্টভাবে দেওয়া আছে?” পার্থক্যটি শোনায় ছোট, কিন্তু ফল উল্টো। Saltzer ও Schroeder-এর যুক্তিটি সুন্দর: অনুমতি-ভিত্তিক ব্যবস্থায় ভুল হলে কাউকে আটকে দেয়, তিনি অভিযোগ করেন, ভুল দ্রুত ধরা পড়ে। আর নিষেধ-ভিত্তিক ব্যবস্থায় ভুল হলে কাউকে ঢুকতে দেয়, কেউ অভিযোগ করে না, ভুলটি চুপচাপ থেকে যায়।

নিচের toy simulator একই অনুরোধগুলো দুই ধরনের নিয়মে চালায়। ইচ্ছা করে দুই নিয়মেই একটি করে বানান ভুল রাখা হয়েছে। এখানে সবকিছু memory-র ভেতরের খেলনা ডেটা, কোনো আসল সিস্টেম নয়। চালিয়ে দেখুন:

// Toy permission check on in-memory requests. Nothing real is touched.
const requests = [
  ['cashier', 'invoice.read'], ['cashier', 'refund.approve'],
  ['intern', 'customer.export'], ['intern', 'report.read'],
  ['report-bot', 'backup.delete'],      // new action, nobody wrote a rule
  ['guest-77', 'invoice.read'],         // unknown identity
];
// What the owner really wants to be allowed:
const legit = new Set(['cashier invoice.read', 'intern report.read']);
// Default allow: list what is forbidden. Note the typo "refund.aprove".
const denied = new Set(['cashier refund.aprove', 'intern customer.export']);
// Default deny: list what is granted. Same kind of typo: "report.raed".
const granted = new Set(['cashier invoice.read', 'intern report.raed']);

const defaultAllow = key => !denied.has(key);
const defaultDeny  = key => granted.has(key);

let unsafeAllows = 0, refusedValid = 0;
console.log('request'.padEnd(30), 'default-allow', ' default-deny');
for (const [who, act] of requests) {
  const key = who + ' ' + act;
  const a = defaultAllow(key), d = defaultDeny(key);
  console.log(key.padEnd(30), (a ? 'ALLOW' : 'deny').padEnd(14), d ? 'ALLOW' : 'deny');
  if (a && !legit.has(key)) unsafeAllows++;
  if (!d && legit.has(key)) refusedValid++;
}
console.log('\nunsafe allows under default-allow:', unsafeAllows);
console.log('valid work refused under default-deny:', refusedValid, '(someone will complain)');

Complete mediation — প্রথম দরজায় যাচাই যথেষ্ট নয়

অফিসের সকালের গেটে পরিচয়পত্র দেখা হলো। দুপুরে চাকরি চলে গেলেও বিকেলে ওই কর্মী যদি সার্ভার-কক্ষে ঢুকতে পারেন, তবে গেট-পাহারা অর্থহীন। সফটওয়্যারে এর রূপ হলো দীর্ঘমেয়াদি session বা token: অনুমতি প্রত্যাহার হলো, কিন্তু পুরোনো token এখনো কাজ করছে। আরেকটি রূপ হলো শুধু login পাতায় যাচাই রেখে ভেতরের URL-এ যাচাই না রাখা, যা broken access control-এর পরিচিত চেহারা (পর্ব ৩৮)।

৪ · Defense in depth — স্তর তখনই কাজের, যখন স্তরগুলো স্বাধীন

কোনো একটি নিয়ন্ত্রণ নিখুঁত নয়। Defense in depth এই সত্যটি মেনে নিয়ে শুরু করে: একটি বাধা ভাঙলে পরেরটি থাকবে, আর কেউ বাধা পার হওয়ার চেষ্টা করলে সেটি ধরা পড়বে। আক্রমণকারীর চোখে পৃথিবীটা এমন: তাঁর শুধু একটি পথ লাগে। রক্ষকের চোখে পৃথিবীটা হলো, পথটি লম্বা, ধীর আর শব্দময় করে তোলা। মহল্লার গেট, ভবনের দারোয়ান, ফ্ল্যাটের দরজা, সিন্দুক আর রাতের পাহারা এই একই চিন্তা।

একটি অনুরোধ স্তরগুলোর মধ্য দিয়ে কীভাবে যায়, সেটি ধাপে ধাপে দেখুন। ঘটনাটি কাল্পনিক: কারও চুরি যাওয়া password দিয়ে একটি পুরোনো support account থেকে পুরো গ্রাহক তালিকা নামানোর চেষ্টা। লক্ষ করুন, কোন স্তর কী জানে আর কী জানে না।

গুণের হিসাব আর তার শর্ত

ধরুন তিনটি স্তর একটি খারাপ অনুরোধ ফসকায় যথাক্রমে ০.৩০, ০.১০ আর ০.২০ সম্ভাবনায় (সংখ্যাগুলো কল্পিত)। স্তরগুলো স্বাধীন হলে তিনটিই ফসকানোর সম্ভাবনা গুণ হয়:

কিন্তু গুণ করার অধিকার আসে একটি শর্ত থেকে: স্বাধীনতা। ধরুন একটি common cause আছে, যা c সম্ভাবনায় সব স্তর একসাথে অকেজো করে। তখন হিসাব হয়:

লোডশেডিংয়ের একটি ছবি মনে রাখুন। ভবনের electronic গেট, CCTV আর alarm, তিনটিই একই বিদ্যুৎ লাইনে চলে। কাগজে তিন স্তর, বাস্তবে বিদ্যুৎ গেলে একটিও নেই। নিচের ছবিতে ছিদ্রগুলো দেখুন। এই “ছিদ্রওয়ালা পনিরের টুকরো” ছবিটি James Reason-এর দুর্ঘটনা-বিশ্লেষণের Swiss cheese model থেকে জনপ্রিয় হয়েছে।

এবার সূত্র আর simulation মিলিয়ে দেখি। Seed নির্দিষ্ট, তাই প্রতিবার একই ফল আসবে। সব সংখ্যা কল্পিত:

// Toy model with assumed numbers. Each layer misses a bad request with
// probability p. With chance c one common cause blinds every layer at once.
function mulberry32(a) {
  return () => { a = a + 0x6D2B79F5 | 0; let t = Math.imul(a ^ a >>> 15, 1 | a);
    t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t; return ((t ^ t >>> 14) >>> 0) / 4294967296; };
}
const miss = [0.30, 0.10, 0.20];      // firewall, MFA, segmentation
const c = 0.02, N = 200000, rnd = mulberry32(2026);

const allMiss = miss.reduce((a, p) => a * p, 1);
console.log('formula, independent :', allMiss.toFixed(5));
console.log('formula, common cause:', (c + (1 - c) * allMiss).toFixed(5));

let indep = 0, corr = 0;
for (let i = 0; i < N; i++) {
  const through = miss.every(p => rnd() < p);
  if (through) indep++;
  if (rnd() < c || through) corr++;
}
console.log('simulated, independent :', (indep / N).toFixed(5));
console.log('simulated, common cause:', (corr / N).toFixed(5));

console.log('\nlayers  independent  with c=0.02   (every layer p=0.20)');
for (let n = 1; n <= 6; n++) {
  const q = 0.2 ** n, w = c + (1 - c) * q;
  console.log(String(n).padStart(6), q.toFixed(6).padStart(12), w.toFixed(6).padStart(12));
}

স্তরের স্বাধীনতা কীভাবে যাচাই করবেন

• একই মানুষ: একজন admin কি সব স্তর একসাথে বন্ধ করতে পারেন? তাঁর একটি account চুরি হলেই সব গেল।
• একই পরিচয়-ব্যবস্থা: VPN, email আর server, সবই কি একই login-এর ওপর? তবে সেগুলো তিন স্তর নয়, এক স্তর।
• একই সফটওয়্যার বা vendor: একই ইঞ্জিনের দুই কপি একই ত্রুটিতে পড়ে। একই update চ্যানেলও একটি অভিন্ন পথ; ২০২০ সালের SolarWinds ঘটনায় প্রকাশিত প্রতিবেদন অনুযায়ী বিশ্বস্ত update পথেই ক্ষতিকর কোড পৌঁছেছিল।
• একই ভৌত ভিত্তি: একই বিদ্যুৎ, একই data center, একই network লাইন।
• একই নীরব ব্যর্থতা: কোনো স্তর বন্ধ হলে কেউ কি জানতে পারবেন? যে স্তর চুপচাপ মরে যায়, হিসাবে সে অনুপস্থিত।

স্তর বাড়ানোর দামও আছে। প্রতিটি নতুন product নিজেও একটি সফটওয়্যার, নিজেও ত্রুটি আনতে পারে, আর economy of mechanism-এর বিরুদ্ধে যায়। তিনটি স্বাধীন, দেখা-যায় এমন স্তর দশটি জড়িয়ে থাকা স্তরের চেয়ে ভালো। Network-এর দিক থেকে স্তর ভাগ করার কাজ segmentation, যা পর্ব ২২-এ বিস্তারিত আসবে।

৫ · Attack surface, secure by default আর secure by design

Attack surface মানে একটি সিস্টেমে বাইরে থেকে পৌঁছানো যায় এমন সব পথের যোগফল: খোলা port, API, login পাতা, upload বক্স, admin panel, এমনকি সেই কর্মীরা যাঁদের কাছে phishing পৌঁছাতে পারে। যে দরজা নেই, তাতে তালা দিতে হয় না, patch-ও করতে হয় না। বাড়িতে দশটি জানালার পাঁচটি যদি অকারণে খোলা থাকে, সবচেয়ে সস্তা নিরাপত্তা হলো সেগুলো বন্ধ করা। পুরোটা বিশ্লেষণ করা হবে পর্ব ০৪-এ (Threat modeling).

পার্থক্যটি বাস্তব। মানুষ বেশিরভাগ সময় default-ই রেখে দেন, তাই default-ই আসল নীতি হয়ে দাঁড়ায়। ২০১৬ সালের Mirai botnet-এর প্রকাশিত বিশ্লেষণে দেখা যায়, বহু IoT যন্ত্র কারখানার default password নিয়েই অনলাইনে ছিল। প্রতি যন্ত্রে আলাদা password দেওয়া একটি নকশার সিদ্ধান্ত, যা লাখো ক্রেতার ভুল একসঙ্গে এড়াতে পারত। ২০২৩ সালে যুক্তরাষ্ট্রের CISA ও কয়েকটি দেশের সংস্থার যৌথ নির্দেশিকা এই দুটি ধারণাকে সামনে আনে; তাদের মূল কথা হলো, নিরাপত্তার বোঝা গ্রাহকের কাঁধে না চাপিয়ে নির্মাতার দায়িত্বে আনা। MFA আর log-এর মতো মৌলিক সুবিধা বাড়তি দামের feature হওয়া উচিত নয়, এটিও সেই বার্তার অংশ।

৬ · ব্যর্থ হলে কোন দিকে — fail secure, fail safe আর fail open

সব নিয়ন্ত্রণ একদিন নষ্ট হবে। বিদ্যুৎ যাবে, server থামবে, network কাটবে। প্রশ্ন হলো, সেই মুহূর্তে সিস্টেম কোন অবস্থায় যাবে। এটি দুর্ঘটনায় ঠিক হতে দেওয়া যায় না, আগেই নকশা করতে হয়।

দুটি দরজা ভাবুন। ব্যাংকের ভল্ট: বিদ্যুৎ গেলে বন্ধই থাকে, কারণ রক্ষা করার জিনিস ভেতরের সম্পদ। ভবনের অগ্নিনির্গমন পথের দরজা: আগুন বা বিদ্যুৎ বিপর্যয়ে মানুষ ভেতর থেকে বের হতে পারতেই হবে, কারণ রক্ষা করার জিনিস প্রাণ। দুটোই সঠিক, কারণ দুটো ভিন্ন ক্ষতি ঠেকায়।

এবার সফটওয়্যারের ভেতরে একই সিদ্ধান্ত দেখুন। একটি কাল্পনিক report service প্রতিটি অনুরোধে একটি authorization service-কে জিজ্ঞেস করে। সেই service হঠাৎ বন্ধ হলো।

1function canExport(user, report) {2  try {3    return authz.check(user, report);4  } catch (outage) {5    audit.log("authz-down", user);6    return FAIL_MODE;7  }8}

দুই চরমের মাঝখানেও পথ আছে। সদ্য যাচাই করা উত্তর অল্প সময়ের জন্য মনে রাখা (cached decision) অনেক বৈধ কাজ বাঁচায়, তবে complete mediation-এ একটু ফাঁক রাখে। নিচের simulation-এ ৩০০ সেকেন্ডে প্রতি সেকেন্ডে একটি অনুরোধ আসে, ১০০ থেকে ১৬০ সেকেন্ডে outage, আর ১১০ সেকেন্ডে একজনের অনুমতি বাতিল হয়। সব সংখ্যা কল্পিত:

// Toy outage: one request per simulated second, 300 seconds. Assumed numbers.
function mulberry32(a) {
  return () => { a = a + 0x6D2B79F5 | 0; let t = Math.imul(a ^ a >>> 15, 1 | a);
    t = t + Math.imul(t ^ t >>> 7, 61 | t) ^ t; return ((t ^ t >>> 14) >>> 0) / 4294967296; };
}
const users = ['u1', 'u2', 'u3', 'u4', 'u5', 'u6', 'u7', 'u8', 'u9', 'bad'];
const OUT_FROM = 100, OUT_TO = 160, REVOKE_AT = 110, TTL = 30;   // u9 loses access at t=110
const entitled = (u, t) => u !== 'bad' && !(u === 'u9' && t >= REVOKE_AT);

function run(mode) {
  const rnd = mulberry32(7), cache = {}, s = { served: 0, refused: 0, leaked: 0 };
  for (let t = 0; t < 300; t++) {
    const u = users[Math.floor(rnd() * users.length)], up = t < OUT_FROM || t >= OUT_TO;
    let ok;
    if (up) { ok = entitled(u, t); cache[u] = { ok, t }; }
    else if (mode === 'fail-open') ok = true;
    else if (mode === 'fail-closed') ok = false;
    else ok = !!cache[u] && t - cache[u].t <= TTL && cache[u].ok;   // cached, short TTL
    const should = entitled(u, t);
    if (ok && should) s.served++;
    if (!ok && should) s.refused++;
    if (ok && !should) s.leaked++;
  }
  return s;
}
console.log('mode        served  refused-valid  allowed-wrongly');
for (const m of ['fail-closed', 'fail-open', 'cached-ttl30']) {
  const s = run(m);
  console.log(m.padEnd(12), String(s.served).padStart(5), String(s.refused).padStart(13), String(s.leaked).padStart(16));
}

হাসপাতালের যন্ত্র — যেখানে দুই ভুলই ভয়ংকর

একটি হাসপাতালের জরুরি বিভাগ ভাবুন। রোগীর তথ্য বা ওষুধের ক্যাবিনেট login-সার্ভারের ওপর নির্ভরশীল। Server বন্ধ হলে fail closed মানে ডাক্তার রোগীর allergy দেখতে পারছেন না, যা প্রাণের ঝুঁকি। Fail open মানে সবাই সব দেখতে পারছে। সমাধান সাধারণত break-glass: জরুরি মুহূর্তে একটি বিশেষ পথে প্রবেশ মেলে, কিন্তু কে, কখন, কী দেখলেন, সবটা আলাদাভাবে রেকর্ড হয়, পরে পর্যালোচনা হয়, আর ভুল ব্যবহারে জবাবদিহি থাকে। লক্ষ করুন, এটি S&S-এর compromise recording আর psychological acceptability-র চমৎকার মিলন। একই যুক্তিতে চিকিৎসা যন্ত্র নিজে license বা network-এর জন্য চিকিৎসা থামিয়ে দেওয়া উচিত নয়।

৭ · Separation of duties — এক হাতে পুরো কাজ নয়

Separation of privilege প্রযুক্তিগত ধারণা: দুটি শর্ত পূরণ হতে হবে। Separation of duties এর সাংগঠনিক রূপ: একটি সংবেদনশীল কাজের ধাপগুলো একজনের হাতে থাকবে না, যাতে ভুল বা জালিয়াতির জন্য অন্তত দুজনের ব্যর্থতা বা যোগসাজশ লাগে। অফিসের রেজিস্টার খাতায় একজন হিসাব লেখেন, আরেকজন যাচাই করে সই করেন, ক্যাশিয়ার টাকা দেন। ব্যাংকে এই জুটিকে বলে maker-checker.

একটি কাল্পনিক প্রতিষ্ঠানে একটি vendor payment ধাপে ধাপে দেখুন। সব id কাল্পনিক।

এই নিয়ন্ত্রণের সীমাও জানা দরকার। দুজন মিলে যোগসাজশ করলে এটি একা ঠেকাতে পারে না; তখন কাজ করে পালাক্রমে দায়িত্ব বদল, বাধ্যতামূলক ছুটি আর স্বাধীন audit log. ছোট প্রতিষ্ঠানে যথেষ্ট লোক না থাকলে দ্বিতীয় স্বাক্ষরের বদলে মালিকের পর্যালোচনা বা পরের দিনের মিলিয়ে দেখা ক্ষতিপূরক নিয়ন্ত্রণ হতে পারে। তাড়া আর আবেগ দিয়ে এই ধাপ ভাঙার চাপ আসে, যে কারণে প্রতারকেরা প্রায়ই “এখনই পাঠান, স্যার বলেছেন” ধরনের চাপ দেন। Software-এ এর আত্মীয় হলো একই ব্যক্তির কোড লিখে নিজেই production-এ না পাঠানো (code review).

৮ · Zero trust মনোভাব আর usability — দুটি আধুনিক শিক্ষা

Zero trust — অবস্থানকে বিশ্বাসের কারণ না ভাবা

পুরোনো নকশা ছিল দুর্গের মতো: বাইরের দেয়াল শক্ত, ভেতরে সবাই বিশ্বস্ত। মুশকিল হলো, একবার ভেতরে ঢুকলে আর বাধা নেই, আর আজকের কর্মী, ডেটা আর সার্ভার কোনোটিই এক দেয়ালের ভেতরে থাকে না। Zero trust মানে নেটওয়ার্কের অবস্থানকে বিশ্বাসের কারণ হিসেবে না ধরা। অফিসের Wi-Fi-তে থাকা মানেই বিশ্বস্ত নয়। প্রতিটি অনুরোধে পরিচয়, যন্ত্রের অবস্থা আর অনুমতি যাচাই হয়।

ভেবে দেখুন, এটি নতুন কিছু নয়: complete mediation আর least privilege, আধুনিক নেটওয়ার্কে প্রয়োগ করা। আর “কিছুই বিশ্বাস করা হয় না” কথাটি আক্ষরিক নয়; কোথাও না কোথাও একটি trust anchor থাকেই। আজ শুধু মনোভাবটি মনে রাখুন। NIST SP 800-207 (২০২০) ধরে পুরো নকশা আসবে পর্ব ৭৪-এ (Zero trust architecture).

Usability একটি নিরাপত্তা-গুণ

ধরুন একটি অফিসে প্রতি মাসে ১৬ অক্ষরের নতুন password বদলাতে হয়। ফল কী? মনিটরে কাগজ সাঁটা, Dhaka2026!-এর পর Dhaka2027!, আর সহকর্মীর সাথে ভাগাভাগি। নিয়ম কাগজে কঠিন, বাস্তবে দুর্বল। যে নিয়ন্ত্রণ মানুষের কাজে বাধা দেয়, মানুষ তার পাশ কাটানোর পথ বের করেন। তখন নিরাপত্তা নিয়ন্ত্রণটিই ঝুঁকি হয়ে ওঠে।

তাই ভালো নকশা নিরাপদ পথকেই সহজ পথ বানায়। সতর্কবার্তা হবে কম কিন্তু অর্থপূর্ণ, কারণ দিনে পঞ্চাশটি alert পেলে মানুষ সব না দেখেই “OK” চাপেন। Password-এর আধুনিক নীতি পর্ব ১৫-এ, আর phishing-প্রতিরোধী login পর্ব ১৬-এ আসবে। মানুষকে দোষ দেওয়ার বদলে ব্যবস্থা ঠিক করার সংস্কৃতি নিয়ে কথা হবে পর্ব ৫৪-এ।

৯ · AI-এর যুগে এই নীতিগুলো

AI খুব দ্রুত configuration আর কোড লিখে দেয়, আর সেখানেই নীতিগুলো যাচাইয়ের ছাঁকনি হয়ে ওঠে। AI-এর প্রথম লক্ষ্য সাধারণত “error চলে যাক”। Permission error এলে সহজ উত্তর হলো অনুমতি বাড়িয়ে দেওয়া, যা least privilege-এর ঠিক উল্টো।

AI-এর পরামর্শ গ্রহণের আগে চেকলিস্ট

• প্রস্তাবটি কি কোনো check বন্ধ করে বা অনুমতি বাড়িয়ে error সরাচ্ছে? হলে আসল কারণ খুঁজেছি
• ব্যর্থতার পথ পড়েছি: timeout বা exception হলে কোড ALLOW করে, না DENY
• উদ্ধৃত CVE, standard বা function প্রাথমিক উৎসে মিলিয়ে দেখেছি
• আমার নিজের lab-এ পরীক্ষা করেছি এবং diff পড়েছি
• Prompt-এ কোনো secret, password বা ব্যক্তিগত তথ্য দিইনি
• মানুষের ওপর প্রভাব ফেলে এমন সিদ্ধান্ত, যেমন account বন্ধ করা, একজন মানুষ নিয়েছেন; AI-এর আত্মবিশ্বাসী triage-কে প্রমাণ ধরিনি