নিরাপত্তার log — কী রাখবেন, কোথায় রাখবেন আর কতদিন

১ · Log হলো রক্ষকের স্মৃতি

একটি অফিসের গেটে দারোয়ানের রেজিস্টার খাতা ভাবুন। কে ঢুকলেন, কখন, কার কাছে এলেন, কখন গেলেন। সাধারণ দিনে কেউ এই খাতা খোলে না। কিন্তু যেদিন অফিসের একটি ল্যাপটপ হারায়, সেদিন এই খাতাই একমাত্র সাক্ষী। খাতায় ফাঁকা পাতা থাকলে, বা তিন মাস পরের ঘটনা জানতে গিয়ে খাতাটিই ফেলে দেওয়া হয়েছে দেখলে, প্রশ্নের উত্তর আর পাওয়া যায় না।

Audit log বা নিরাপত্তার log হলো যন্ত্রের সেই রেজিস্টার খাতা। Prevention সবসময় কাজ করবে না, এই ধরে নিয়েই পর্ব ২-এ আমরা detective control দেখেছি। Detection, তদন্ত আর পুনরুদ্ধার তিনটিই দাঁড়িয়ে থাকে log-এর ওপর। SIEM যত দামিই হোক, যে ঘটনা log হয়নি তা সে ধরতে পারে না।

এই পর্বে প্রশ্নটি নিরাপত্তার: কী রাখলে তদন্ত সম্ভব, আর কী রাখলে নতুন ক্ষতি হয়। Agent, buffer, Loki বা Elasticsearch-এর মতো অবকাঠামো চালানোর কাজ দেখতে Centralized logging পর্বটি পড়ুন। আমরা সেগুলো আবার বলব না। Metric আর trace-এর সাথে log-এর সম্পর্ক আছে observability-তে।

২ · কী রাখবেন — নয়টি উৎস আর তাদের প্রশ্ন

“সব log করুন” শুনতে সহজ, কিন্তু কাজের নয়। তাতে খরচ বাড়ে, আসল ঘটনা ডুবে যায়, আর ব্যক্তিগত তথ্য জমে। ভালো পদ্ধতি হলো প্রশ্ন থেকে শুরু করা: তদন্তে আমার কোন প্রশ্নের উত্তর লাগবে? নিচের নয়টি উৎস বেশিরভাগ প্রতিষ্ঠানের ভিত্তি।

এগুলোর জন্য বিশেষ পণ্য লাগবে, এমন নয়। Linux-এ auditd process আর ফাইলের ঘটনা লেখে (পর্ব ৩০). Windows-এ logon আর process creation-এর জন্য Event 4624, 4625 আর 4688 পরিচিত (পর্ব ৩১). Network flow আর sensor-এর সীমা আপনি পর্ব ২৩-এ দেখেছেন। Cloud-এ AWS CloudTrail, Azure Activity Log বা Google Cloud Audit Logs-এর মতো সেবা আছে। অনেক প্রদানকারীর ক্ষেত্রে management কাজ সাধারণত লেখা হয়, কিন্তু ডেটা পড়ার ঘটনা আলাদা করে চালু করতে হয়। নিজের প্রদানকারীর নথি দেখে নিন।

তিনটি পরিচিত নির্দেশিকা কী বলে

৩ · কী কখনো রাখবেন না

Log সাধারণত database-এর চেয়ে কম পাহারায় থাকে। বেশি মানুষ পড়তে পারেন, কপি হয় অনেক জায়গায়, মুছতে দেরি হয়। তাই log-এ secret ঢোকা মানে সেই secret-এর ওপর সব নিয়ন্ত্রণ চলে যাওয়া। পর্ব ১৩-এর সব সুরক্ষা অর্থহীন, যদি login request-এর পুরো body কোথাও লেখা হয়ে যায়।

# Unsafe: the whole request lands in the log, secrets and all.
logger.info("login request: %s", request.body)

# Safe: an explicit allow-list of fields, nothing else.
logger.info("login", extra={
    "event": "login", "user_id": user.id,
    "result": "failure", "reason": "bad_password",
    "src_ip": client_ip, "request_id": request_id,
})

মূল শিক্ষা হলো allow-list. “এই ক্ষেত্রগুলো বাদ” তালিকা সবসময় অসম্পূর্ণ থাকবে, আর নতুন ক্ষেত্র যোগ হলে সেটি ফাঁকি দেবে। “শুধু এই ক্ষেত্রগুলো লেখা হবে” তালিকা নিরাপদ দিকে ব্যর্থ হয়। সাথে pipeline-এ log redaction রাখুন দ্বিতীয় স্তর হিসেবে, আর repository-তে secret scanning-এর মতো পরীক্ষা চালান।

Log-এর ভেতরে যা ঢোকে, তার অনেকটাই বাইরের মানুষের লেখা: username, URL, User-Agent. এতে নতুন লাইনের চিহ্ন থাকলে কেউ নকল log লাইন বানাতে পারে। একে বলে log injection. প্রতিকার হলো structured log আর control character শোধন (পর্ব ৪৬). আবার log পড়ার পর্দায় সেই লেখা encoding ছাড়া দেখালে XSS-এর ঝুঁকিও আসে (পর্ব ৪০).

৪ · Structured log আর common schema

পাঁচটি অফিসের পাঁচ রকম খাতা ভাবুন। কেউ লেখেন “নাম”, কেউ “আগন্তুক”, কেউ “ভিজিটর”। এক জায়গায় বসে সব মেলাতে গেলে আগে ভাষা এক করতে হবে। Log-এও তাই। Free text লাইন মানুষ পড়তে পারে, কিন্তু যন্ত্রকে প্রতিটি format আলাদা করে শেখাতে হয়। Structured log মানে প্রতিটি তথ্য আলাদা নামের ক্ষেত্রে, সাধারণত JSON আকারে।

Common schema আরেক ধাপ এগোয়: সব উৎস একই ক্ষেত্রের নাম ব্যবহার করবে। তাহলে একটি rule সব উৎসে চলবে। কয়েকটি পরিচিত উদাহরণ:

এগুলো উদাহরণ, সুপারিশ নয়। আপনার SIEM যেটি ভালো বোঝে সেটি নিন, বা একটি ছোট নিজস্ব অভিধান লিখুন। আসল কথা হলো সবাই একই নাম মানছে কি না। নিচের ডায়াগ্রামে একটি login-এর পুরো যাত্রা দেখুন।

{"ts":"2026-10-31T02:10:00.412Z",
 "event":"login", "result":"success",
 "user":"tania", "mfa":"totp",
 "src":"198.51.100.7",
 "request_id":"req-7f31"}

... আগের সব ক্ষেত্র অপরিবর্তিত ...
"host":"web-1"
"read_at":
  "2026-10-31T02:10:00.530Z"

from:   web-1 agent
to:     collector.example.com
status: delivered
received_at: 2026-10-31T02:10:01.020Z
পথ বন্ধ থাকলে agent-এর buffer-এ অপেক্ষা

{"@timestamp":
  "2026-10-31T02:10:00.412Z",
 "event.category":"authentication",
 "event.outcome":"success",
 "user.name":"tania",
 "source.ip":"198.51.100.7",
 "host.name":"web-1"}

asset:     web-1, গুরুত্ব high
user:      tania, হিসাব বিভাগ
rule:      failure-then-success
result:    alert নয়
আগে কোনো ব্যর্থতা নেই
delay:     0.608 s (received − ts)

৫ · ঘড়ি মিললে তবেই গল্প মেলে

তিনজন সাক্ষী তিনটি আলাদা ঘড়ি দেখে সময় বললে আদালতে গল্প মেলে না। Log-এও তাই। তদন্তের ভিত্তি হলো ক্রম: কোনটি আগে, কোনটি পরে। দুটি ভিন্ন সমস্যা এখানে গুলিয়ে যায়।

• Time zone: বাংলাদেশের সময় UTC-র ছয় ঘণ্টা আগে (+06:00). একটি লাইনে local সময় আছে কিন্তু offset নেই, তাহলে অন্য উৎসের সাথে মেলানো কঠিন। তাই log-এ UTC লিখুন, দেখানোর সময় বদলান। RFC 3339 ধরনের 2026-10-31T02:10:00Z format এই অস্পষ্টতা দূর করে।
• Clock skew: যন্ত্রের ঘড়ি সত্যিই আগে বা পিছে চলছে। সমাধান NTP. CIS safeguard 8.4 অন্তত দুটি time source বলে। ঘড়ি হঠাৎ অনেকটা সরলে সেটিও log-এ আসা উচিত, কারণ সময় বদলানো প্রমাণ নষ্ট করার একটি উপায়ও হতে পারে।

# Two approved internal time sources. Host names are placeholders.
server ntp1.example.com iburst
server ntp2.example.com iburst
# On your own Linux server, read the current offset with: chronyc tracking

এবার তিনটি উৎসের ঘটনা জোড়া দেখুন। সংখ্যাগুলো কাল্পনিক। VPN-এর ঘড়ি ঠিক আছে, app server ২ মিনিট পিছিয়ে, আর database local সময় লেখে, ৫ সেকেন্ড এগিয়ে।

VPN  02:10:00Z  tania login ok
APP  02:08:30Z  tania admin export
DB   08:11:05   select 12000 rows
Login-এর আগেই export?
DB ছয় ঘণ্টা পরে?

VPN  02:10:00Z
APP  02:08:30Z
DB   02:11:05Z   (08:11:05 − 6 ঘণ্টা)
এখন একই ভাষা, কিন্তু APP এখনো VPN-এর আগে

VPN  offset    0 s
APP  offset −120 s   (ঘড়ি পিছিয়ে)
DB   offset   +5 s   (ঘড়ি এগিয়ে)
সত্য সময় = লেখা সময় − offset

VPN  02:10:00Z
APP  02:08:30 + 120 s = 02:10:30Z
DB   02:11:05 −   5 s = 02:11:00Z

02:10:00Z  VPN  tania login ok
02:10:30Z  APP  tania admin export
02:11:00Z  DB   select 12000 rows
প্রতিটি ধাপে ব্যবধান ৩০ s
মূল সময়গুলো আলাদা ক্ষেত্রে রাখা আছে

৬ · একটি auth log পড়া

এবার একটি বাস্তব ধাঁচের log পড়ি। Debian ধাঁচের Linux-এ /var/log/auth.log, Red Hat ধাঁচে /var/log/secure, আর systemd-এর journal-এও এই তথ্য থাকে। আপনি নিজের server-এই এই কাজ করবেন। অন্যের system-এর log দেখার অনুমতি লাগে (পর্ব ৬).

Oct 31 02:11:12 web-1 sshd[2215]: Failed password for rafi from 203.0.113.50 port 51133 ssh2

নিচের block নিজের ভেতরে একটি নির্দিষ্ট নমুনা ফাইল বানায়, তারপর সেটিই পড়ে। কোনো আসল log বা system-এ হাত দেয় না। Field গোনা হয়েছে লাইনের শেষ থেকে ($(NF-3)), কারণ শুরুর দিকের username বাইরের মানুষ নিয়ন্ত্রণ করে, আর শেষের দিকটি sshd নিজে লেখে।

# Fixed sample built here. Addresses and names are made up.
cat > auth.log <<'EOF'
Oct 31 02:11:04 web-1 sshd[2210]: Failed password for invalid user admin from 203.0.113.50 port 51122 ssh2
Oct 31 02:11:06 web-1 sshd[2210]: Failed password for invalid user test from 203.0.113.50 port 51124 ssh2
Oct 31 02:11:09 web-1 sshd[2213]: Failed password for root from 203.0.113.50 port 51130 ssh2
Oct 31 02:11:12 web-1 sshd[2215]: Failed password for rafi from 203.0.113.50 port 51133 ssh2
Oct 31 02:11:40 web-1 sshd[2218]: Failed password for tania from 198.51.100.7 port 40110 ssh2
Oct 31 02:12:01 web-1 sshd[2219]: Accepted publickey for sohel from 198.51.100.20 port 40220 ssh2
Oct 31 02:12:31 web-1 sshd[2221]: Accepted password for rafi from 203.0.113.50 port 51140 ssh2
Oct 31 02:13:05 web-1 sudo:     rafi : TTY=pts/1 ; PWD=/home/rafi ; USER=root ; COMMAND=/usr/bin/tar czf /tmp/c.tgz /srv/data
EOF
echo "== failed logins by source =="
awk '/sshd.*Failed password/ {print $(NF-3)}' auth.log | sort | uniq -c | sort -k1,1nr -k2
echo "== failed logins by username =="
awk '/sshd.*Failed password/ {print $(NF-5)}' auth.log | sort | uniq -c | sort -k1,1nr -k2
echo "== success from a source that failed earlier =="
awk '/sshd.*Failed password/ {bad[$(NF-3)]++}
     /sshd.*Accepted/ && ($(NF-3) in bad) {
       print $3, $(NF-5), "from", $(NF-3), "after", bad[$(NF-3)], "failures"}' auth.log
echo "== sudo commands =="
awk -F'COMMAND=' '/sudo:/ && NF > 1 {print $2}' auth.log

৭ · Log-কে কেউ বদলালে জানবেন কীভাবে

যে যন্ত্র দখল হয়েছে, তার log-কে বিশ্বাস করা যায় না। অনুপ্রবেশকারী root হলে স্থানীয় ফাইল মুছতে বা বদলাতে পারে। অভ্যন্তরীণ ঝুঁকিতেও (insider threat) একই কথা। পোস্ট অফিসের সিলমোহর যেমন চিঠির সময়ের প্রমাণ, কারণ সেটি প্রেরকের হাতে নেই, log-এর প্রমাণও তেমনি থাকতে হবে সন্দেহভাজনের নাগালের বাইরে। তিনটি স্তর একে অন্যের পরিপূরক।

Hash chain-এর সূত্র সরল: d[i] = SHA-256(d[i-1] | line[i]). শুরুতে d[0] হলো একটি জানা মান, এখানে ৬৪টি শূন্য। পর্ব ৯-এ আপনি দেখেছেন, input-এর একটি অক্ষর বদলালে hash সম্পূর্ণ বদলে যায়। নিচের সংখ্যাগুলো আসল SHA-256-এর প্রথম ১২ অক্ষর।

02:10:00 login ok user=tania
  src=198.51.100.7
d1 = 49f0d3dd3c81

d1 = 49f0d3dd3c81
02:11:30 role change user=tania
  role=admin by=sohel
d2 = 43935149832a

d2 = 43935149832a
02:12:05 export rows=12000 user=tania
d3 = 4f9e4bdbf1ef

web-1-এ: লাইন ১–৩, d1, d2, d3
বাইরে:   d3 = 4f9e4bdbf1ef
web-1-এর admin এটি বদলাতে পারেন না

02:11:30 role change user=tania
  role=viewer by=sohel
আগে ছিল role=admin

লাইন ১ মিলল
  নতুন 49f0d3dd3c81
  জমা  49f0d3dd3c81
লাইন ২ ভাঙল
  নতুন cb3b7924cec1
  জমা  43935149832a
লাইন ৩ ভাঙল
  নতুন 7e1d54819364
  জমা  4f9e4bdbf1ef
প্রথম ভাঙা লাইন: ২

কিন্তু এখানে একটি বড় ফাঁদ আছে। Hash-এ কোনো গোপন চাবি নেই। যে ফাইল বদলাতে পারে, সে সব hash নতুন করেও লিখতে পারে। নিচের কোড সেটিই দেখায়।

# Toy hash chain over fixed log lines. Real SHA-256, made-up data.
import hashlib
GENESIS = "0" * 64

def link(prev, line):
    return hashlib.sha256(f"{prev}|{line}".encode()).hexdigest()

def chain(lines):
    digests, prev = [], GENESIS
    for line in lines:
        prev = link(prev, line)
        digests.append(prev)
    return digests

def first_bad(lines, stored):
    for i, digest in enumerate(chain(lines)):
        if digest != stored[i]:
            return i + 1
    return None

log = ["02:10:00 login ok user=tania src=198.51.100.7",
       "02:11:30 role change user=tania role=admin by=sohel",
       "02:12:05 export rows=12000 user=tania"]
stored = chain(log)
anchor = stored[-1]            # copied off the host at once
for line, digest in zip(log, stored):
    print(digest[:12], line)
print("clean log, first bad line:", first_bad(log, stored))
edited = log.copy()
edited[1] = edited[1].replace("role=admin", "role=viewer")
print("edited log, first bad line:", first_bad(edited, stored))
rebuilt = chain(edited)        # someone recomputes every digest on the host
print("rebuilt digests, first bad line:", first_bad(edited, rebuilt))
print("rebuilt tip matches off-host anchor:", rebuilt[-1] == anchor)

৮ · কোথায় রাখবেন, কতদিন, কত খরচে

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

Hot storage-এ detection আর দ্রুত খোঁজা চলে। Cold storage তদন্তের জন্য, ফিরিয়ে আনতে সময় বা খরচ লাগতে পারে। Log ফিরিয়ে আনার পরীক্ষাও করে দেখুন। যে archive কখনো খোলা হয়নি, তার ওপর ভরসা করা যায় না। মেয়াদ শেষে মুছে ফেলাও নীতির অংশ। তবে মামলা বা তদন্ত চললে সংশ্লিষ্ট log আলাদা করে রাখতে হতে পারে, একে বলে legal hold.

Retention কীভাবে ঠিক করবেন

Retention তিনটি টানের মাঝখানের সিদ্ধান্ত। তদন্ত চায় বেশি দিন, কারণ অনুপ্রবেশ অনেক সময় দেরিতে ধরা পড়ে (dwell time). Privacy চায় কম দিন, কারণ যা নেই তা ফাঁসও হয় না। আর বিল চায় কম। তাই আগে প্রশ্ন করুন: এই log কোন ঝুঁকির তদন্তে লাগবে? কোনো আইন বা চুক্তি কী বলে? নিচের সংখ্যাগুলো সর্বজনীন নিয়ম নয়, শুধু উদাহরণ।

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

একটি কাল্পনিক অনলাইন বাজারের জন্য নিচের হিসাব। সূত্র সরল: দৈনিক GB = events × গড় bytes ÷ 10⁹. স্থির অবস্থায় জমা = দৈনিক GB × দিন। সব দাম ধরে নেওয়া, কোনো প্রদানকারীর আসল দাম নয়। নিজের সংখ্যা বসিয়ে চালিয়ে দেখুন।

// Log volume and retention cost. Every volume and price is ASSUMED, not a quote.
const sources = [           // name, events per day, average bytes
  ['network flows',    40e6,  200],
  ['DNS queries',      20e6,  150],
  ['web and app',      15e6,  500],
  ['endpoint process', 10e6,  600],
  ['cloud audit',       2e6, 1000],
  ['auth and admin',  0.5e6,  400],
];
const PRICE = { ingest: 20, hot: 3, cold: 0.4 }; // assumed taka per GB (hot, cold: per month)
const COLD_RATIO = 5;                            // assumed compression in cold storage

let gbDay = 0, events = 0;
for (const [name, n, bytes] of sources) {
  const gb = n * bytes / 1e9;
  gbDay += gb; events += n;
  console.log(name.padEnd(18), gb.toFixed(1).padStart(5), 'GB/day');
}
console.log('total'.padEnd(18), gbDay.toFixed(1).padStart(5), 'GB/day,',
            Math.round(events / 86400), 'events/s on average');

function monthly(gb, hotDays, coldDays) {
  const ingest = gb * 30 * PRICE.ingest;
  const hot = gb * hotDays * PRICE.hot;
  const cold = gb / COLD_RATIO * coldDays * PRICE.cold;
  return Math.round(ingest + hot + cold);
}
const plans = [
  ['A: hot 30 + cold 335',  gbDay, 30, 335],
  ['B: hot 365',            gbDay, 365, 0],
  ['C: hot 180 + cold 185', gbDay, 180, 185],
  ['D: plan A, flows cut 75%', gbDay - 8 * 0.75, 30, 335],
];
for (const [label, gb, h, c] of plans)
  console.log(label.padEnd(26), 'taka per month:', monthly(gb, h, c));

৯ · যে উৎস চুপ, সে সবচেয়ে বিপজ্জনক

SIEM-এর পর্দা সবুজ থাকলে দুটি অর্থ হতে পারে: কিছু ঘটেনি, অথবা খবর আসা বন্ধ হয়ে গেছে। পাহারাদার ঘুমিয়ে পড়লে মহল্লা শান্তই মনে হয়। তাই দুটি নিয়মিত কাজ দরকার।

• Log source inventory: একটি তালিকা, কোন system কী log পাঠানোর কথা, মালিক কে। এটি asset inventory-র সাথে মেলালে detection gap বেরিয়ে আসে।
• Silent source alert: প্রতিটি উৎসের জন্য আলাদা সীমা। DNS resolver ৫ মিনিট চুপ মানে সমস্যা। Admin console কয়েক ঘণ্টা চুপ থাকা স্বাভাবিক।

Log বন্ধ হওয়া নিজেই নিরাপত্তা ঘটনা হতে পারে। ATT&CK-এ audit বন্ধ করা বা log মোছা একটি পরিচিত আচরণ হিসেবে তালিকাভুক্ত। তাই audit নীতি বদলের ঘটনাও alert-এর তালিকায় রাখুন। আবার সাধারণ কারণও হয়: disk ভরে গেছে, certificate-এর মেয়াদ শেষ, format বদলে parser ভেঙেছে। শেষেরটি সবচেয়ে চুপিসারে ঘটে। Parser (log-এর লেখা ভেঙে ক্ষেত্র বের করার program) ভাঙলে log আসছে, কিন্তু ক্ষেত্র ফাঁকা। তাই সংখ্যার পাশাপাশি ক্ষেত্রের মানও পরীক্ষা করুন।

// Log source coverage report. Simulated clock and made-up inventory.
const NOW = 720;  // minutes since 00:00 UTC, simulated (12:00)
const sources = [ // host, log type, longest normal silence (min), last event (min)
  { host: 'web-1',  type: 'authentication', maxGap: 30,  last: 716 },
  { host: 'web-2',  type: 'authentication', maxGap: 30,  last: 655 },
  { host: 'dns-1',  type: 'dns',            maxGap: 5,   last: 719 },
  { host: 'fw-1',   type: 'network-flow',   maxGap: 5,   last: 702 },
  { host: 'db-1',   type: 'data-access',    maxGap: 60,  last: 700 },
  { host: 'admin',  type: 'admin-action',   maxGap: 720, last: 310 },
  { host: 'cloud',  type: 'cloud-audit',    maxGap: 60,  last: 690 },
];
const requiredTypes = ['authentication', 'authorization', 'admin-action',
  'config-change', 'data-access', 'network-flow', 'dns', 'process-exec', 'cloud-audit'];
const inventory = ['web-1', 'web-2', 'dns-1', 'fw-1', 'db-1', 'hr-laptop', 'build-1'];

let silent = 0;
for (const s of sources) {
  const gap = NOW - s.last;
  const state = gap > s.maxGap ? 'SILENT' : 'ok';
  if (state === 'SILENT') silent++;
  console.log(s.host.padEnd(6), s.type.padEnd(15), `gap ${gap}m`.padEnd(10),
              `limit ${s.maxGap}m`.padEnd(11), state);
}
const seenTypes = new Set(sources.map(s => s.type));
const seenHosts = new Set(sources.map(s => s.host));
const noType = requiredTypes.filter(t => !seenTypes.has(t));
const noHost = inventory.filter(h => !seenHosts.has(h));
const covered = inventory.length - noHost.length;

console.log('silent sources:', silent, 'of', sources.length);
console.log('log types with no source:', noType.join(', '));
console.log('assets with no logs:', noHost.join(', '));
console.log(`asset coverage: ${covered}/${inventory.length} = ` +
            `${(100 * covered / inventory.length).toFixed(0)}%`);

যিনি পাহারা দেন, তাঁর ওপরও পাহারা, আর কর্মীর privacy

Log দেখায় মানুষ কখন কাজ করলেন, কোন সাইটে গেলেন, কোন ফাইল খুললেন। এটি ক্ষমতা। তাই কয়েকটি নিয়ম মানুন। কর্মীদের আগেই জানান কী লেখা হয় আর কেন। উদ্দেশ্য নিরাপত্তা, এর বাইরে ব্যবহার নয়। Log-এ access সীমিত রাখুন, আর SIEM-এ কে কী খুঁজলেন তারও audit রাখুন। নির্দিষ্ট কর্মীকে নিয়ে তদন্ত হবে অনুমোদিত প্রক্রিয়ায়, ব্যক্তিগত কৌতূহলে নয়। সম্ভব হলে pseudonymization ব্যবহার করুন, তবে মনে রাখবেন এটি পুরো নাম-গোপন করা নয়। নিরাপত্তা সংস্কৃতিতে এর প্রভাব পর্ব ৫৪-এ দেখেছেন: মানুষ নজরদারির ভয় পেলে ভুল রিপোর্ট করা কমে যায়।

১০ · AI-এর যুগে log নিয়ে কাজ

AI একটি log format বোঝাতে, awk লাইন বানাতে আর লম্বা log-এর সারাংশ করতে দারুণ দ্রুত। কিন্তু log-এর ক্ষেত্রে তিনটি ঝুঁকি বিশেষ।

• AI-কে দেওয়া নমুনায় কোনো আসল নাম, ঠিকানা, token নেই
• AI-এর উল্লেখ করা standard, ধারা বা সময়সীমা মূল নথিতে খুঁজে পেয়েছি
• AI-এর লেখা query নিজের পরীক্ষার log-এ চালিয়ে হাতে গুনে মিলিয়েছি
• নতুন logging কোডের পর পরীক্ষার log-এ secret খুঁজেছি
• কোনো মানুষকে প্রভাবিত করে এমন সিদ্ধান্ত মানুষই নিয়েছেন, মূল log দেখে