လေ့ကျင့်ခန်း — ဒေတာဘေ့စ် လုံခြုံရေး Audit တစ်ခု

နားလည်ထားရမယ့် အချက်

Security audit ဆိုတာ security topic တွေကို တစ်ခုချင်းစီ သင်ယူတာနဲ့ မတူပါဘူး။ ယခင်သင်ခန်းစာတွေမှာ authentication၊ least privilege၊ network access၊ TLS၊ secrets management နဲ့ SQL injection ကို သီးခြား concept တွေအနေနဲ့ မိတ်ဆက်ခဲ့ပါတယ်။

အစစ်အမှန် audit တစ်ခုဆိုတာ run နေတဲ့ system တစ်ခုလုံးကို ကြည့်ပြီး layer တိုင်းမှာ ဒီ concept တွေကို တကယ် အကောင်အထည်ဖော်ထားလားလို့ မေးခွန်းထုတ်တာပါ — concept တစ်ခုချင်းစီကို တစ်ပိုင်းတစ်စ မှန်အောင်လုပ်ထားပေမယ့် system တစ်ခုလုံးအနေနဲ့ အန္တရာယ်ရှိနေနိုင်လို့ပါ။

ဒီ exercise က သေးငယ်ပြီး လက်တွေ့ကျတဲ့၊ ရည်ရွယ်ချက်ရှိရှိ ချို့ယွင်းအောင်ပြုလုပ်ထားတဲ့ setup တစ်ခုကို ပေးထားပါတယ် — အောက်က characteristic ခြောက်ခုစလုံးက setup ထဲမှာ ရှိနေပါတယ်။

• database operation အားလုံးအတွက် (read-only reporting အပါအဝင်) shared admin account တစ်ခုတည်းကို အသုံးပြုနေသည်။
• connection string နဲ့ password ကို source control ထဲ commit လုပ်ထားသော config file ထဲတွင် hardcode လုပ်ထားသည်။
• database server ကို public internet မှ တိုက်ရိုက် ချိတ်ဆက်နိုင်ပြီး၊ connection ကို ကန့်သတ်မည့် firewall rule လုံးဝမရှိပါ။
• connection သည် TLS ကို ဘယ်တော့မှ negotiate မလုပ်သဖြင့် traffic များကို encrypt မလုပ်ဘဲ ပို့ဆောင်နေသည်။
• backup များကို ညတိုင်း run နေသော်လည်း test-restore တစ်ကြိမ်မှ မလုပ်ဖူးသေးပါ။
• query အချို့သည် user input ကို query string ထဲသို့ တိုက်ရိုက် concatenate လုပ်ထားသည်။

သင့်ရဲ့တာဝန်ကတော့ တကယ့် auditor တစ်ယောက် လုပ်မယ့်နည်းလမ်းအတိုင်း layer တစ်ခုချင်းစီကို ဘာမှားနိုင်လဲ၊ ဘာလို့ အရေးကြီးလဲ လို့ မေးခွန်းထုတ်ပြီး၊ နောက်ပိုင်း practical section ထဲက worked answer key နဲ့ ပြန်စစ်ဖို့ပါပဲ။

FLAWED DATABASE SETUP (AUDIT TARGET)
------------------------------------
FLAWED DATABASE SETUP (AUDIT TARGET)
-----
[ Web App ]
     |
     | connects with ONE shared "admin" account
     | (same account for writes AND read-only reports)
     v
[ Config file -- committed to git repo ]
     | connection string + password in PLAIN TEXT
     v
[ Database Server ]
     | NO TLS -- traffic sent unencrypted
     | reachable from 0.0.0.0/0 -- NO FIREWALL RULE
     v
[ Public Internet ] <-- anyone can attempt to connect

[ Nightly Backup Job ]
     | backups are created on schedule
     | NEVER test-restored -- unknown if usable
     v
[ ??? ] -- recovery path is unverified

လက်တွေ့ scenario နဲ့ ချိတ်ကြည့်မယ်

ဒီ exercise ထဲက setup ကို တကယ် audit လုပ်ရင် layer တစ်ခုချင်းစီအလိုက် ဘယ်လိုလုပ်ဆောင်မလဲဆိုတာ ဒီမှာ ပြထားပါတယ် — production ကို မထိခိုက်ခင် careful engineer တစ်ယောက် လုပ်မယ့်နည်းလမ်းအတိုင်းပါ။

• အစစ်အမှန် audit တစ်ခုက least privilege၊ secrets handling၊ network access၊ encryption in transit၊ backup verification စတဲ့ framework-neutral concept တွေကို layer တစ်ခုချင်းစီအလိုက် တကယ် အကောင်အထည်ဖော်ထားလားလို့ စစ်ဆေးတာဖြစ်ပြီး၊ concept တစ်ခုချင်းစီကို နားလည်ထားလားဆိုတာကို စစ်ဆေးတာ မဟုတ်ပါဘူး။
• commit လုပ်ထားတဲ့ secret တစ်ခုဟာ commit လုပ်လိုက်တဲ့ခဏတည်းမှာပဲ ချို့ယွင်းသွားပါပြီ — နောက်ပိုင်း file ကို ဖျက်လိုက်တာက exposure ကို ပြန်ပြင်ပေးမှာ မဟုတ်ဘဲ credential ကို rotate လုပ်မှသာ ဖြေရှင်းပေးပါလိမ့်မယ်။
• test မလုပ်ရသေးတဲ့ backup တစ်ခုဟာ အတည်ပြုပြီးသား recovery plan မဟုတ်ပါဘူး — backup အလုပ်လုပ်လား သိနိုင်တဲ့ တစ်ခုတည်းသောနည်းလမ်းက တကယ် restore လုပ်ကြည့်တာပါပဲ။

အတူတူ စမ်းရေးကြည့်မယ်

function auditDatabaseSetup(setup) {
  const issues = [];

  if (setup.usesSharedAdminAccount) {
    issues.push(
      "Shared admin/superuser account used for all access -- violates " +
      "least privilege; app writes, read-only reporting, and human " +
      "operators should each use separate, narrowly scoped credentials."
    );
  }
  if (setup.credentialsHardcoded) {
    issues.push(
      "Credentials hardcoded in a committed config file -- move to " +
      "environment variables or a secrets manager, and rotate the " +
      "exposed credentials immediately."
    );
  }
  if (setup.publiclyExposed) {
    issues.push(
      "Database reachable directly from the public internet -- " +
      "restrict network access with a firewall/security-group rule " +
      "that allows only the app servers."
    );
  }
  if (!setup.usesTLS) {
    issues.push(
      "Connections are not encrypted with TLS -- credentials and " +
      "data can be read by anyone observing the network traffic."
    );
  }
  if (!setup.backupsRestoreTested) {
    issues.push(
      "Backups exist but have never been test-restored -- an " +
      "unverified backup is not a confirmed recovery path."
    );
  }
  if (!setup.usesParameterizedQueries) {
    issues.push(
      "User input is concatenated directly into queries -- " +
      "vulnerable to SQL injection; use parameterized queries " +
      "or prepared statements instead."
    );
  }

  return issues;
}

const flawedSetup = {
  usesSharedAdminAccount: true,
  credentialsHardcoded: true,
  publiclyExposed: true,
  usesTLS: false,
  backupsRestoreTested: false,
  usesParameterizedQueries: false,
};

const hardenedSetup = {
  usesSharedAdminAccount: false,
  credentialsHardcoded: false,
  publiclyExposed: false,
  usesTLS: true,
  backupsRestoreTested: true,
  usesParameterizedQueries: true,
};

console.log("Flawed setup issues found:", auditDatabaseSetup(flawedSetup).length);
console.log("Hardened setup issues found:", auditDatabaseSetup(hardenedSetup).length);

Flawed setup ကို run လိုက်ရင် `Flawed setup issues found: 6` ဟု log ထုတ်ပြီး၊ ဆိုထားတဲ့ ပြဿနာခြောက်ခုစလုံး (shared admin, hardcoded credentials, public exposure, no TLS, untested backups, non-parameterized queries) ကို string array အဖြစ် ပြန်ပေးပါတယ်။ hardenedSetup ကို run လိုက်ရင်တော့ `Hardened setup issues found: 0` ဟု log ထုတ်ပြီး empty array ပြန်ပေးပါတယ်။

OWASP Database Security Cheat Sheet — How Databases Work