Privileged access — admin account, secret vault আর just-in-time access

১ · কেন privileged account সবার আগে নিশানা

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

Privileged account হলো সেই মাস্টার চাবি। এই account সাধারণ কাজের বাইরে যায়: user তৈরি করে, অনুমতি বদলায়, log মুছতে পারে, সব ডেটা পড়তে পারে, backup নষ্ট করতে পারে। Privileged access মানে এমন অধিকার, যা নিরাপত্তা নিয়ন্ত্রণ নিজেই বদলাতে পারে বা অনেক সিস্টেমে একসাথে পৌঁছায়।

রক্ষকের হিসাব: কেন এখানেই আগে খরচ

আক্রমণকারী সাধারণত প্রথমেই admin হয়ে ঢোকে না। সে একটি সাধারণ account দিয়ে শুরু করে, তারপর আরও বড় অধিকার খোঁজে। পর্ব ৫-এর ভাষায় privilege escalation, lateral movement আর persistence, এই তিন ধাপ প্রায়ই একটি বৈধ privileged account-এর ওপর নির্ভর করে। MITRE ATT&CK-এ Valid Accounts (T1078) আলাদা technique হিসেবে আছে। কারণ বৈধ login দেখতে স্বাভাবিক কাজের মতো লাগে, malware-এর মতো নয়।

রক্ষকের দিক থেকে তিনটি যুক্তি:

• Blast radius বড়: একটি domain admin বা cloud root-এর ভুল বা চুরি পুরো প্রতিষ্ঠানে পৌঁছায়। সংখ্যায় এরা অল্প, ঝুঁকিতে অনেক বেশি।
• প্রমাণও এদের হাতে: যে log মুছতে পারে, তার কাজ ধরা কঠিন। তাই log-কে admin-এর নাগালের বাইরে পাঠানো জরুরি।
• খরচ কম, লাভ বেশি: ৫০ জনের প্রতিষ্ঠানে privileged মানুষ হয়তো ৮ জন। ৫০ জনের চেয়ে ৮ জনকে ভালোভাবে রক্ষা করা সহজ।

২ · কারা privileged — পাঁচ ধরন আর non-human identity

“Admin” বললে সাধারণত একজন মানুষের কথা মনে আসে। বাস্তবে privileged পরিচয়ের বড় অংশ মানুষ নয়। পাঁচটি ধরন আলাদা করে চিনে নিন, কারণ প্রতিটির ঝুঁকি আলাদা।

Non-human identity-র তালিকা

Non-human identity (NHI) মানে মানুষ নয় এমন পরিচয়: service account, API key, OAuth app (পর্ব ১৮), CI/CD token, certificate, bot, AI agent. এদের MFA থাকে না, ছুটিও হয় না, আর চাকরি ছাড়ার মতো কোনো দিনও আসে না। তাই এগুলো নীরবে থেকে যায়। OWASP Non-Human Identities Top 10 (২০২৫) তালিকার প্রথম ঝুঁকিই Improper Offboarding, অর্থাৎ অপ্রয়োজনীয় NHI সরিয়ে না ফেলা। একই তালিকায় আছে secret leakage, overprivileged NHI, long-lived secret আর Human Use of NHI. শেষেরটি মানে মানুষের service account দিয়ে login করা।

Inventory-র প্রতিটি সারিতে অন্তত এগুলো থাকবে:

• নাম ও ধরন: কোন secret, কোন সিস্টেমের
• মালিক: একজন মানুষ বা দল, যিনি জবাব দেবেন
• উদ্দেশ্য ও অধিকার: কী কাজে, কতটুকু scope
• ব্যবহারকারী: কোন কোন app এটি পড়ে
• শেষ rotation ও শেষ ব্যবহার: বয়স আর ঘুমন্ত কি না
• মেয়াদ: কবে বদলাবে বা বাতিল হবে

৩ · Standing privilege সরানো — just-in-time আর just-enough

Standing privilege মানে যে অধিকার সবসময় চালু থাকে, কাজ থাকুক বা না থাকুক। ব্যাংকের উদাহরণে এটি হলো ভল্টের চাবি সারাবছর ম্যানেজারের পকেটে থাকা। ম্যানেজার ঘুমাচ্ছেন, বিয়েবাড়িতে আছেন, তখনও চাবিটি চুরি হলে ভল্ট খোলে।

দুটি ধারণা এই সমস্যা কমায়। এরা আলাদা, আবার একসাথেই সবচেয়ে কার্যকর:

হিসাব করে দেখা

একজন admin-এর standing অধিকার বছরে 24 × 365 = ৮,৭৬০ ঘণ্টা। ধরা যাক ৮ জন admin. মোট ৮ × ৮,৭৬০ = ৭০,০৮০ privileged ঘণ্টা। JIT-এ ধরা যাক প্রতি জন সপ্তাহে কয়েকবার অল্প সময়ের জন্য অধিকার নেন। নিচের calculator সব সংখ্যাই অনুমান ধরে চলে। দ্বিতীয় ভাগে দেখুন, মানুষ যদি প্রতিবার ৮ গুণ লম্বা সময় চান, তাহলে কী হয়।

// Standing-privilege exposure: privileged hours per year, before and after JIT.
// All numbers are assumptions for a made-up organisation of about 50 people.
const YEAR_HOURS = 24 * 365, WEEKS = 52;
const groups = [
  { name: 'server admins', people: 4, grantsPerWeek: 3, hoursPerGrant: 1 },
  { name: 'database admins', people: 2, grantsPerWeek: 2, hoursPerGrant: 2 },
  { name: 'cloud admins', people: 2, grantsPerWeek: 2, hoursPerGrant: 1 },
];
function report(label, stretch) {
  let before = 0, after = 0;
  console.log(`--- ${label}`);
  for (const g of groups) {
    const b = g.people * YEAR_HOURS;
    const a = g.people * g.grantsPerWeek * WEEKS * g.hoursPerGrant * stretch;
    before += b; after += a;
    console.log(`${g.name.padEnd(16)} before ${String(b).padStart(6)}h  after ${String(a).padStart(6)}h`);
  }
  const pct = (1 - after / before) * 100;
  console.log(`total            before ${String(before).padStart(6)}h  after ${String(after).padStart(6)}h`);
  console.log(`reduction ${pct.toFixed(1)}%, active at a random moment ${(after / before * 100).toFixed(1)}%`);
}
report('short grants, as planned', 1);
report('people always ask for 8x longer', 8);

৪ · JIT কীভাবে চলে — অনুরোধ থেকে মেয়াদ শেষ

JIT-এর লক্ষ্য zero standing privilege: স্বাভাবিক সময়ে কারও কাছে উঁচু অধিকার থাকে না, থাকে শুধু অনুরোধ করার যোগ্যতা। অনুমোদন পর্ব ৩-এর maker-checker নীতি মানে: যিনি চাইছেন, তিনি নিজে অনুমোদন করতে পারেন না। নিচে একটি কাল্পনিক অনলাইন বাজারের ঘটনা। Rumi-কে সকালে একটি database সমস্যা ঠিক করতে হবে।

এবার একই নিয়ম কোডে দেখুন। নিচের broker একটি খেলনা। ঘড়িও নকল (মিনিটে), আর কোনো আসল সিস্টেমে হাত দেয় না। লক্ষ করুন, মেয়াদ শেষের কাজ কোনো মানুষের ওপর নির্ভর করে না।

// Toy JIT broker on a simulated clock (minutes). Touches no real system.
const POLICY = { maxMinutes: 60, approvers: { 'db-admin': ['tania', 'sohel'] } };
const grants = [], audit = [];
const log = (t, msg) => audit.push(`t=${String(t).padStart(3)} ${msg}`);

function expire(now) {                 // automatic expiry: nobody has to remember
  for (const g of grants) {
    if (!g.ended && g.expires <= now) {
      g.ended = true;
      log(g.expires, `EXPIRE ${g.user} ${g.role}`);
    }
  }
}
function request(t, user, role, minutes, approver) {
  expire(t);
  const tag = `${user} ${role} ${minutes}m`;
  if (approver === user) return log(t, `DENY   ${tag}: self-approval`);
  if (!POLICY.approvers[role].includes(approver)) return log(t, `DENY   ${tag}: not an approver`);
  if (minutes > POLICY.maxMinutes) return log(t, `DENY   ${tag}: over ${POLICY.maxMinutes}m limit`);
  grants.push({ user, role, expires: t + minutes, ended: false });
  log(t, `GRANT  ${tag}: by ${approver}, until t=${t + minutes}`);
}
function use(t, user, role) {
  expire(t);
  const ok = grants.some(g => g.user === user && g.role === role && !g.ended);
  log(t, `${ok ? 'ALLOW ' : 'BLOCK '} ${user} uses ${role}`);
}
request(0, 'rumi', 'db-admin', 30, 'rumi');
request(1, 'rumi', 'db-admin', 240, 'tania');
request(2, 'rumi', 'db-admin', 30, 'tania');
use(10, 'rumi', 'db-admin');
use(20, 'farid', 'db-admin');
use(31, 'rumi', 'db-admin');
use(33, 'rumi', 'db-admin');
console.log(audit.join('\n'));

যা নিয়ে সতর্ক থাকবেন

• না দেখেই অনুমোদন: দিনে ৩০টি অনুরোধ এলে approver না পড়েই হ্যাঁ চাপেন। একে approval fatigue বলে, মানে অনুমোদনের ক্লান্তি। নিচু ঝুঁকির কাজ নীতি দিয়ে স্বয়ংক্রিয় করে দিলে মানুষের চোখ বাকি কাজে থাকে।
• Approver না থাকলে: সবাই ছুটিতে থাকলে বা সবাই JIT-নির্ভর হলে কেউ অনুমোদন করতে পারে না। তাই বিকল্প approver আর break-glass লাগে (অংশ ৮)।
• Grant-এর ফাঁকে অধিকার বাড়ানো: এক ঘণ্টার admin নতুন user বা key বানিয়ে রাখতে পারে। তাই grant-এর সময়ে নতুন credential তৈরি হলে alert দিন।

৫ · PAM আর admin-এর আলাদা জগৎ

PAM (privileged access management) কোনো একটি product নয়, একগুচ্ছ নিয়ন্ত্রণের নাম। মোটামুটি তিনটি ধারণা এর কেন্দ্রে। Product ছাড়াও এদের ছোট রূপ বানানো যায়।

Recording-এ গোপনীয়তার প্রশ্নও আছে। পর্দায় গ্রাহকের তথ্য থাকলে recording নিজেই সংবেদনশীল ডেটা হয়ে যায়। তাই কে দেখবে, কতদিন থাকবে, আর কর্মীরা এটি জানেন কি না, সবই আগে ঠিক করুন।

আলাদা admin account আর PAW

Phishing আসে email-এ, malware আসে ব্রাউজারে। যে account দিয়ে আপনি email পড়েন, সেটিই যদি domain admin হয়, তাহলে একটি ভুল ক্লিকই পুরো প্রতিষ্ঠানের দরজা। তাই নিয়ম দুটি:

• আলাদা admin account: দৈনন্দিন কাজের জন্য rumi, admin কাজের জন্য rumi-admin. Admin account-এ email নেই, web ব্রাউজিং নেই। CIS Controls v8-এর Safeguard 5.4 এই কথাই বলে, আর NIST SP 800-53-এর AC-6(2) বলে নিরাপত্তার বাইরের কাজে privileged নয় এমন account ব্যবহার করতে।
• Privileged access workstation (PAW): শুধু admin কাজের জন্য শক্ত করে সাজানো কম্পিউটার। Email বা অচেনা software চলে না। ছোট প্রতিষ্ঠানে আলাদা যন্ত্র না থাকলে অন্তত আলাদা browser profile বা শক্ত করা ভার্চুয়াল মেশিন একটি আপস। মনে রাখবেন, এটি পুরো PAW-এর সমান সুরক্ষা নয়, কারণ নিচের যন্ত্রটি দূষিত হলে ওপরটিও ঝুঁকিতে পড়ে।

৬ · নিজের server-এ — sudo নীতি আর SSH certificate

এই অংশের সব config শুধু নিজের বা অনুমোদিত server-এর জন্য। অন্যের সিস্টেমে হাত দিতে লিখিত অনুমতি লাগে, বিস্তারিত পর্ব ৬-এ। আগে একটি SSH session খোলা রেখে পরিবর্তন করুন, যাতে ভুলে নিজেই বাইরে আটকে না যান।

Sudo-তে just-enough

sudo একজন user-কে অন্য user হিসেবে, সাধারণত root হিসেবে, নির্দিষ্ট command চালাতে দেয়। নিয়ম থাকে sudoers ফাইলে। বিপজ্জনক অভ্যাস হলো ALL=(ALL) ALL, যা কার্যত পুরো root দেয়। নিচের উদাহরণ একটি web দলকে শুধু nginx চালানোর অধিকার দেয়:

# /etc/sudoers.d/90-webops  (mode 0440, owner root)
Cmnd_Alias WEB_SVC  = /usr/bin/systemctl reload nginx, \
                      /usr/bin/systemctl restart nginx
Cmnd_Alias WEB_LOGS = /usr/bin/journalctl -u nginx --no-pager -n 200

Defaults:%webops timestamp_timeout=5, use_pty
Defaults:%webops logfile=/var/log/sudo-webops.log
Defaults:%webops log_input, log_output

%webops ALL=(root) WEB_SVC, WEB_LOGS

এই snippet-টি sudo 1.9.15-এর visudo -cf দিয়ে parse করে দেখা হয়েছে, আর ফল এসেছে parsed OK. লাইনগুলোর অর্থ:

• Cmnd_Alias: command-এর নাম দেওয়া তালিকা। পুরো path আর পুরো argument লেখা আছে, তাই অন্য service বা অন্য argument মিলবে না।
• timestamp_timeout=5: sudo ৫ মিনিট পরে আবার password চাইবে।
• use_pty: command আলাদা pseudo-terminal-এ চলে। এতে root প্রক্রিয়া থেকে user-এর terminal-এ হাত বাড়ানোর পথ বন্ধ হয়।
• logfile: sudo-র ব্যবহার আলাদা ফাইলে লেখে। আসল ব্যবহারে এই log বাইরের সিস্টেমেও পাঠান।
• log_input, log_output: session-এর ইনপুট আর আউটপুট রেকর্ড করে, যা sudoreplay দিয়ে দেখা যায়। ইনপুট রেকর্ডে টাইপ করা গোপন তথ্যও ধরা পড়তে পারে, তাই দরকার বুঝে চালু করুন।
• --no-pager: root হিসেবে pager না খোলার জন্য। Pager বা editor-এর মতো program থেকে অন্য command চালানো যায়। তাই sudo-র তালিকায় এদের রাখবেন না। ফাইল সম্পাদনার জন্য sudoedit আছে।

ফাইলটি সবসময় visudo -f দিয়ে সম্পাদনা করুন, কারণ একটি syntax ভুল সবার sudo বন্ধ করে দিতে পারে। /etc/sudoers.d/-তে ফাইলের নামে . থাকলে বা শেষে ~ থাকলে sudo সেটি সাধারণত উপেক্ষা করে। পরে sudo -l -U rumi দিয়ে একজনের চূড়ান্ত অধিকার দেখে নিন।

দীর্ঘস্থায়ী key বনাম SSH certificate

SSH key সুবিধাজনক, কিন্তু সাধারণ public key-এর কোনো মেয়াদ নেই। authorized_keys-এ একবার ঢুকলে কর্মী চলে যাওয়ার পরও সেটি থেকে যেতে পারে। NIST IR 7966 (২০১৫) বড় প্রতিষ্ঠানে এই অনিয়ন্ত্রিত SSH key-এর সমস্যা নিয়েই লেখা। SSH certificate অন্য পথ নেয় (OpenSSH 5.4, ২০১০ থেকে): আপনার নিজের একটি CA user-এর public key-তে সই করে, মেয়াদ আর principal লিখে দেয়। Server শুধু CA-কে বিশ্বাস করে। প্রতিটি server-এ user-এর key ঢোকাতে হয় না। PKI-র ধারণা পর্ব ১১-এ, আর SSH-এর ভেতরের কাজ SSH ও দূরের server পর্বে আছে।

JIT-এর সাথে এটি দারুণ মেলে: grant মানে ১ ঘণ্টার একটি certificate. একটি পরীক্ষার ফোল্ডারে দুটি খেলনা key বানিয়ে OpenSSH 10.2 দিয়ে এটি চালানো হয়েছে, আর পরে private key দুটি মুছে ফেলা হয়েছে:

ssh-keygen -s user_ca -I rumi-TICKET-4821 -n rumi-admin \
  -V +1h -z 1001 -O clear -O permit-pty admin_key.pub
ssh-keygen -L -f admin_key-cert.pub

admin_key-cert.pub:
        Type: ssh-ed25519-cert-v01@openssh.com user certificate
        Key ID: "rumi-TICKET-4821"
        Serial: 1001
        Valid: from 2026-10-31T19:47:00 to 2026-10-31T20:48:22
        Principals:
                rumi-admin
        Critical Options: (none)
        Extensions:
                permit-pty

এটি আসল আউটপুট, শুধু public key আর CA-র fingerprint-এর দুটি লাইন ছোট রাখার জন্য বাদ দেওয়া হয়েছে। মেয়াদের শুরু আর শেষের মধ্যে ১ ঘণ্টা ১ মিনিটের একটু বেশি, কারণ ঘড়ির সামান্য অমিল সামলাতে ssh-keygen শুরুর সময় একটু পিছিয়ে দেয়। -O clear -O permit-pty port forwarding-এর মতো বাকি সুবিধা বাদ দিয়েছে। এটিই just-enough.

Server-এর দিকের নিয়ম নিচে। এখানকার keyword-গুলো OpenSSH-এর sshd_config manual-এর, তবে পুরো ফাইলটি কোনো আসল server-এ চালিয়ে পরীক্ষা করা হয়নি। তাই আপনার server-এ বসিয়ে অবশ্যই আগে sudo sshd -t চালান, আর version-ভেদে আচরণ মিলিয়ে নিন।

# /etc/ssh/sshd_config.d/10-admin.conf
PermitRootLogin no
PasswordAuthentication no
KbdInteractiveAuthentication no
AuthenticationMethods publickey
AllowGroups ssh-admins
MaxAuthTries 3
LogLevel VERBOSE

# Trust certificates from our own user CA, and nothing else
TrustedUserCAKeys /etc/ssh/user_ca.pub
AuthorizedPrincipalsFile /etc/ssh/principals/%u
AuthorizedKeysFile none
RevokedKeys /etc/ssh/revoked_keys

AllowAgentForwarding no
AllowTcpForwarding no
X11Forwarding no

• PermitRootLogin no: সরাসরি root login বন্ধ, তাই log-এ আসল মানুষের নাম আসে।
• PasswordAuthentication no, KbdInteractiveAuthentication no: password অনুমান করার পথ বন্ধ।
• AllowGroups: শুধু একটি দলের সদস্য SSH করতে পারেন।
• LogLevel VERBOSE: কোন key বা certificate দিয়ে login হলো, তা log-এ আসে।
• TrustedUserCAKeys, AuthorizedPrincipalsFile: CA-র সই থাকতে হবে, আর certificate-এর principal এই ফাইলে থাকতে হবে। %u মানে login user-এর নাম।
• AuthorizedKeysFile none: পুরোনো ধরনের key দিয়ে login বন্ধ। এটি চালুর আগে নিশ্চিত হোন certificate-এর পথ কাজ করছে।
• RevokedKeys: বাতিল key-এর তালিকা। ফাইলটি থাকা চাই। sshd পড়তে না পারলে সবার public key login বন্ধ হয়ে যায়।

৭ · Secret vault, rotation আর secret sprawl

Secret manager, KMS আর envelope encryption-এর পুরো কাজ Secrets ও KMS পর্বে আছে। এখানে শুধু privileged access-এর চোখে দেখব। Key-এর জীবনচক্র আগেই পর্ব ১৪-এ পেয়েছেন।

Secret sprawl মানে একই secret ছড়িয়ে থাকা: কোডে, .env ফাইলে, chat-এ, wiki-তে, CI-এর log-এ, কারও browser-এ। মহল্লায় একটি বাড়ির ডুপ্লিকেট চাবি ছয় জনের কাছে থাকলে, তালা যত ভালোই হোক, চাবির হিসাব আর থাকে না। Secret vault সব চাবি এক জায়গায় আনে, আর চারটি জিনিস দেয়:

• অনুমতি: কে কোন secret পড়তে পারে, তা নীতিতে লেখা
• Log: কে কখন পড়ল, তার হিসাব
• Rotation: নিয়ম করে নতুন মানে বদল
• Dynamic secret আর lease: চাওয়ার মুহূর্তে বানানো স্বল্পমেয়াদি credential, যা মেয়াদ শেষে নিজে থেকে বাতিল হয়। একে JIT-এর যন্ত্র-সংস্করণ বলা যায়।

মেয়াদের হিসাব

ধরুন একটি secret নীরবে ফাঁস হলো, আর কেউ টের পেল না। ফাঁসের সময়টি rotation চক্রের যেকোনো জায়গায় হতে পারে। Rotation-ই তখন একমাত্র যা চোরের সময় শেষ করে। চক্রের দৈর্ঘ্য T হলে সবচেয়ে খারাপ ক্ষেত্রে চুরি করা secret T সময় চলবে, আর ফাঁসের সময় সমান সম্ভাবনায় ছড়ানো ধরলে গড়ে T/2 সময়।

• ৯০ দিনের rotation: সবচেয়ে খারাপ ৯০ দিন = ২,১৬০ ঘণ্টা, গড়ে ৪৫ দিন = ১,০৮০ ঘণ্টা
• ১ ঘণ্টার dynamic secret: সবচেয়ে খারাপ ১ ঘণ্টা, গড়ে ৩০ মিনিট
• সবচেয়ে খারাপ ক্ষেত্রে পার্থক্য: ২,১৬০ ÷ ১ = ২,১৬০ গুণ

এই হিসাব ধরে নেয় চোর secret দিয়ে নিজের জন্য নতুন পথ বানায়নি। বানালে rotation একা যথেষ্ট নয়। আর নতুন ঝুঁকিও আছে: সব চাবি এক vault-এ মানে vault-ই নতুন মাস্টার চাবি। তার admin, backup আর প্রথম প্রবেশের চাবি, যাকে secret zero বলে, সবচেয়ে কঠোরভাবে রক্ষা করতে হয়।

কোন secret-এর আগে কাজ

নিচের report একটি খেলনা inventory পড়ে। দিনগুলো নকল ক্যালেন্ডারের সংখ্যা, নামগুলো বানানো। এটি বয়স, মালিক, ঘুমন্ত অবস্থা আর একাধিক ব্যবহারকারী দেখে সিদ্ধান্তের তালিকা বানায়।

// Secret-age report on a toy inventory. Names and days are made up.
// lastRotated and lastUsed are day numbers on a simulated calendar.
const TODAY = 400;
const inventory = [
  { name: 'pay-gateway-key', owner: 'payments', lastRotated: 330, lastUsed: 400, maxAge: 90, consumers: 3 },
  { name: 'db-report-user', owner: 'data', lastRotated: 180, lastUsed: 399, maxAge: 90, consumers: 1 },
  { name: 'old-sms-token', owner: '', lastRotated: 12, lastUsed: 240, maxAge: 90, consumers: 1 },
  { name: 'ci-deploy-role', owner: 'platform', lastRotated: 395, lastUsed: 400, maxAge: 30, consumers: 1 },
  { name: 'backup-svc-key', owner: 'platform', lastRotated: 250, lastUsed: 398, maxAge: 180, consumers: 2 },
];
function findings(s) {
  const age = TODAY - s.lastRotated, out = [];
  if (!s.owner) out.push('NO-OWNER');
  if (age > s.maxAge) out.push(`OVERDUE+${age - s.maxAge}d`);
  if (TODAY - s.lastUsed > 60) out.push('DORMANT');
  if (s.consumers > 1) out.push('SHARED');
  return { age, out };
}
const rows = inventory.map(s => ({ s, ...findings(s) }))
  .sort((a, b) => b.out.length - a.out.length || b.age - a.age);
for (const { s, age, out } of rows) {
  const owner = (s.owner || '-').padEnd(9);
  console.log(`${s.name.padEnd(16)} ${owner} age ${String(age).padStart(3)}d  ${out.join(' ') || 'ok'}`);
}
const bad = rows.filter(r => r.out.length).length;
console.log(`${bad} of ${rows.length} secrets need action`);

Downtime ছাড়া shared secret বদলানো

দুই version একসাথে বৈধ রাখার মূল কৌশল Secrets ও KMS পর্বে database password দিয়ে দেখানো আছে। এখানে দেখুন একটি vendor-এর API key, যা ধরা যাক দিনে ৯,০০০ call-এ ব্যবহার হয়: orders ৪,০০০, billing আর notify মিলে ৪,৬০০, আর একটি ভুলে যাওয়া report-job ৪০০।

কোডের ভেতরের secret ধরা

Secret কোডে ঢুকলে history-তে থেকে যায়, মুছলেও। পর্ব ১৪-এ এটি দশটি সাধারণ ভুলের একটি। স্তরে স্তরে ঠেকানোর পুরো পথ, pre-commit থেকে push protection, Git নিরাপত্তা পর্বে আছে। Secret scanning ফাইলের ভেতর পরিচিত secret-এর আকৃতি খোঁজে। নিচের খেলনা scanner নিজের বানানো ফাইলে শুধু নকল example-token খোঁজে। কোনো আসল credential বা আসল repository-তে হাত দেয় না।

# Toy secret scanner. The block makes its own files; every value is fake.
dir=$(mktemp -d)
trap 'rm -rf "$dir"' EXIT
cd "$dir" || exit 1
mkdir app tests

cat > app/config.py <<'CFG'
DB_HOST = "db.example.com"
API_TOKEN = "example-token-7f3a91"
CFG
cat > app/deploy.sh <<'CFG'
curl -H "X-Key: example-token-c04e22" https://api.example.com/v1/ping
CFG
cat > app/README.md <<'CFG'
Read API_TOKEN from the vault. Never paste the value here.
CFG
cat > tests/test_login.py <<'CFG'
password = "not-a-real-password"
CFG

echo "--- rule 1: known token shape"
grep -rnE 'example-token-[0-9a-f]{6}' app tests |
  sed -E 's/(example-token-)[0-9a-f]{6}/\1******/'

echo "--- rule 2: generic password assignment"
grep -rnE 'password *= *"' app tests

hits=$(grep -rlE 'example-token-[0-9a-f]{6}' app tests | wc -l)
echo "--- files with a token: $hits"
if [ "$hits" -gt 0 ]; then
  echo "RESULT: block the merge, then revoke and rotate"
fi

৮ · Break-glass আর privileged কাজের নজরদারি

সব JIT যদি একটি login সিস্টেমের ওপর নির্ভর করে, আর সেটিই বন্ধ হয়ে যায়? তখন admin-ও ঢুকতে পারেন না, অথচ ঠিক তখনই admin দরকার। পর্ব ৩-এর break-glass এই সমস্যার সমাধান। লিফটের পাশে কাচে ঢাকা ফায়ার অ্যালার্মের মতো: সবসময় হাতের নাগালে, কিন্তু ভাঙলেই সবাই জানে।

Microsoft-এর emergency access নির্দেশিকা (সিস্টেমভেদে বিবরণ আলাদা, তবে ধারণা সাধারণ) থেকে কয়েকটি শিক্ষা:

• অন্তত দুটি account, যাতে একটির সমস্যায় অন্যটি চলে
• স্বাভাবিক login ব্যবস্থার ওপর নির্ভর নয়, আর MFA-র পদ্ধতিও সাধারণ admin-এর থেকে আলাদা
• FIDO2 security key-এর মতো phishing-প্রতিরোধী পদ্ধতি, আলাদা নিরাপদ জায়গায় রাখা
• প্রতিটি login-এ alert
• অন্তত ৯০ দিনে একবার মহড়া, আর অনুমোদিত মানুষের তালিকা যাচাই
• ব্যবহারের পরে সবসময় পর্যালোচনা

কী কী নজরে রাখবেন

Privileged কাজের log তখনই কাজের, যখন সেটি admin-এর নাগালের বাইরে থাকে আর কেউ তা দেখে। পুরো log-এর পরিকল্পনা পর্ব ৫৫ আর ৫৬-এ পাবেন। এখানে ন্যূনতম তালিকা:

প্রথম সারিটি একটি Sigma নিয়মে লেখা যায়। নিচের উদাহরণে account-এর নাম আর field কাল্পনিক। আপনার log-এর field অনুযায়ী বদলে নিতে হবে:

title: Break-glass account sign-in
id: 6f1e3b7a-2c44-4d10-9b55-0a7c3e5d1f20
status: experimental
description: Any sign-in by an emergency account must reach a human at once.
logsource:
  category: authentication
detection:
  selection:
    user:
      - bg-admin-1
      - bg-admin-2
  condition: selection
falsepositives:
  - Announced quarterly drill
level: critical

৯ · ৫০ জনের প্রতিষ্ঠান কোথা থেকে শুরু করবে

PAM product অনেক প্রতিষ্ঠানের জন্যই বড় ও ব্যয়বহুল। সেটি ছাড়াও বড় অংশ করা যায়। নিচের ধাপগুলো একটি ৫০ জনের কাল্পনিক প্রতিষ্ঠানের জন্য সাজানো, যেখানে নিরাপত্তার পূর্ণকালীন লোক হয়তো নেই। সময়গুলো অনুমান, আপনার অবস্থা অনুযায়ী বদলাবে। অগ্রাধিকারের ক্রমটিই আসল।

১০ · AI-এর যুগে privileged access

AI এখন সাহায্যকারীর চেয়ে বেশি কিছু। AI agent নিজেই command চালায়, cloud-এ কাজ করে। অর্থাৎ সে নিজেও একটি non-human identity, আর privileged হতে পারে। তাকে admin অধিকার দেওয়া মানে prompt injection-এর মতো ঝুঁকিকে সরাসরি production-এ পৌঁছে দেওয়া, যা পর্ব ৫১-এ আসবে। Agent-কেও তাই least privilege, স্বল্পমেয়াদি credential, audit আর বিপজ্জনক কাজে মানুষের অনুমোদন লাগে।

• AI-কে কোনো আসল secret, hostname বা গ্রাহকের তথ্য দিইনি
• প্রতিটি অধিকার কেন লাগবে, তা নিজে ব্যাখ্যা করতে পারি
• visudo -c বা sshd -t চালিয়ে, খোলা session রেখে পরীক্ষা করেছি
• উল্লেখ করা standard বা option মূল উৎসে মিলিয়েছি
• AI agent-এর credential স্বল্পমেয়াদি, আর production-এর কাজে মানুষের অনুমোদন আছে