Non-Human Database Access · บทหลัก

คุณทำทะเบียน Non-Human Identity แล้ว แต่ไม่เคยถามว่ามันเข้าถึงอะไรได้บ้าง

ทราฟฟิกฐานข้อมูลส่วนใหญ่ของคุณไม่ใช่มนุษย์อีกต่อไป การควบคุมทุกอย่างที่คุณมี ทั้ง Single Sign-On การขออนุมัติผ่าน Ticket การทบทวน Session และหลักการ Four-Eyes บน Production ล้วนตั้งอยู่บนสมมติฐานว่าปลายทางอีกด้านคือมนุษย์ เมื่อถอดมนุษย์ออกไป การควบคุมแต่ละข้อก็เหลือสถานะเพียงพิธีกรรม

Infozense Knowledge Engineering · CIO · CISO · Head of Data · ~6 นาที

นี่คือ บทหลัก ของชุดบทความ Non-Human Database Access โดย Infozense ใจความสำคัญในบรรทัดเดียว: โครงการ Non-Human Identity ของคุณทำทะเบียน Credential แล้วหยุดอยู่หน้าประตูฐานข้อมูล จึงไม่มีใครตอบได้ว่า Identity เหล่านั้นอ่านอะไรได้และแก้ไขอะไรได้บ้างจริง ๆ ส่วนบทย่อยจะพาไล่ดูทีละ Gate

Connection ที่ติดป้ายว่า “Development”

นี่คือเรื่องเล็ก ๆ ที่เราวัดมาจริง เพราะมันบอกทุกอย่างเกี่ยวกับเรื่องใหญ่

เมื่อ CLI ฐานข้อมูลสมัยใหม่สร้าง Connection ขึ้นมา มันจะติดป้าย Connection นั้นว่า Development เป็นค่าเริ่มต้น เปิด Auto-Commit และปิดการยืนยันก่อนแก้ไขข้อมูล ค่าเหล่านี้สมเหตุสมผลสำหรับนักพัฒนาที่ทดลองกับฐานข้อมูลชั่วคราวบนเครื่องตัวเอง

งาน Reconcile รายคืนของคุณต่อเข้า Production ผ่านโปรไฟล์นั้นพอดี Pipeline ที่สร้างตารางลูกค้าใหม่ก็เช่นกัน ไม่มีใครเลือกค่าเหล่านั้นสำหรับ Production มันเป็นเพียงสิ่งที่เครื่องมือทำเมื่อไม่มีใครสั่งเป็นอย่างอื่น และไม่มีใครอยู่ตรงนั้นเพื่อสั่งเป็นอย่างอื่น

การเข้าถึงฐานข้อมูลโดยผู้ใช้ที่ไม่ใช่มนุษย์ ไม่ได้ถูกกำกับดูแลอย่างย่ำแย่ แต่ไม่ถูกกำกับดูแลเลยตั้งแต่ต้น

การควบคุมทุกอย่างที่คุณมี ตั้งอยู่บนสมมติฐานว่ามีมนุษย์

Single Sign-On ตั้งอยู่บนสมมติฐานว่ามีคนมายืนยันตัวตน การขอสิทธิ์ผ่าน Ticket ตั้งอยู่บนสมมติฐานว่ามีคนยื่นคำขอและมีอีกคนอนุมัติ การทบทวน Session ตั้งอยู่บนสมมติฐานว่าทุก Session มีชื่อเจ้าของ หลักการ Four-Eyes บน Production ตั้งอยู่บนสมมติฐานว่ามีสายตาสองคู่ และการ Recertify ทุกไตรมาสตั้งอยู่บนสมมติฐานว่ามีหัวหน้างานที่ตอบได้ว่าคนคนนี้ยังต้องใช้สิทธิ์นี้อยู่หรือไม่

เมื่อถอดมนุษย์ออกไป การควบคุมทุกข้อข้างต้นเหลือสถานะเพียงพิธีกรรม Credential ยังใช้งานได้ Grant ยังอยู่ครบ และไม่มีอะไรเพิกถอนตัวเองเมื่อมนุษย์ที่มันถูกออกแบบมาเพื่อรองรับไม่ได้อยู่ตรงนั้นแล้ว

เรื่องนี้จะเป็นแค่เชิงอรรถ ถ้า Connection ที่ไม่ใช่มนุษย์มีอยู่น้อย แต่ความจริงไม่ใช่เช่นนั้น ผลสำรวจในอุตสาหกรรมระบุว่าจำนวน Machine Identity ในองค์กรทั่วไปมากกว่าจำนวนผู้ใช้ที่เป็นมนุษย์อยู่หลายเท่า และช่องว่างนี้กว้างขึ้นทุกปี การควบคุมทั้งหมดถูกสร้างขึ้นเพื่อคนกลุ่มน้อย

โครงการ NHI ของคุณหยุดอยู่หน้าประตูฐานข้อมูล

ข่าวดีคือปัญหานี้มีชื่อเรียกแล้ว Non-Human Identity หรือ NHI ปรากฏอยู่ในลำดับความสำคัญของ CISO มีกลุ่มผู้ให้บริการเป็นของตัวเอง และมีงบประมาณรองรับ ถ้าคุณเริ่มทำโครงการ NHI แล้ว ก็ถือว่านำหน้าองค์กรส่วนใหญ่

ทีนี้ลองดูให้ละเอียดว่าเครื่องมือเหล่านั้นทำอะไร มันค้นหา Identity ทั่วทั้ง Cloud, SaaS, Secret Vault และ CI/CD บอกคุณได้ว่ามี Identity ไหนอยู่บ้าง ใครเป็นเจ้าของ Key หมดอายุหรือยัง และหมุนเวียนครั้งล่าสุดเมื่อไหร่ นั่นเป็นงานที่มีคุณค่าจริง และทั้งหมดนั้นว่าด้วย ตัว Credential

แต่ไม่มีตัวไหนตอบคำถามถัดไปได้ว่า เมื่อ Identity นั้นเข้าไปอยู่ในฐานข้อมูลของคุณแล้ว มันอ่านอะไรได้ และแก้ไขอะไรได้ ทะเบียนที่บอกว่า “Service Account นี้มีอยู่ และรหัสผ่านเก่า 400 วันแล้ว” ไม่ได้บอกคุณว่ามันลบตารางลูกค้าได้ด้วย

นั่นคือประตู ทะเบียนหยุดอยู่ตรงนั้น ส่วนขอบเขตความเสียหายอยู่อีกฝั่งหนึ่ง

คุณทบทวนสิทธิ์ของพนักงานแล้ว แต่ยังไม่ได้ทบทวนสิทธิ์ของ Pipeline

PDPA กำหนดให้คุณต้องเก็บบันทึกว่าข้อมูลส่วนบุคคลถูกประมวลผลอย่างไร และต้องแสดงให้เห็นว่าควบคุมได้ว่าใครเข้าถึงข้อมูลนั้นได้บ้าง ทุกองค์กรที่เอาจริงกับเรื่องนี้ต่างทำการทบทวนสิทธิ์การเข้าถึง และการทบทวนนั้นครอบคลุมเฉพาะพนักงาน ทั้งชื่อ ตำแหน่ง แผนก และไฟล์ตารางที่มีหัวหน้าเซ็นอนุมัติ

ในขณะเดียวกัน Identity ที่อ่านข้อมูลลูกค้าทุกแถวจริง ๆ ทุกคืน ตามตารางเวลา โดยไม่มี Session และไม่มีผู้ตรวจสอบ กลับไม่เคยอยู่ในขอบเขตการทบทวนเลย มันไม่มีชื่อ ไม่มีแผนก และไม่มีหัวหน้าคนไหนเซ็นรับรองให้

การทบทวนสิทธิ์ของคุณครบถ้วนแล้ว — เฉพาะกับ Connection ส่วนน้อยเท่านั้น

พวกมันอยู่ตรงไหนบ้าง

ทีมส่วนใหญ่เมื่อถูกถามให้เดา มักตอบว่ามีสามหรือสี่ตัว แต่จำนวนจริงมักมากกว่านั้นหลายเท่า เพราะ Non-Human Identity ถูกสร้างโดยใครก็ตามที่ต้องใช้ ในจังหวะที่ต้องใช้ และไม่เคยถูกสร้างพร้อมกำหนดวันสิ้นสุด

งาน ETL และ ELT

Credential ที่เก่าที่สุดในองค์กร สร้างครั้งเดียว ไม่เคยหมุนเวียน เพราะการหมุนเวียนทำให้งานตามตารางพัง

CI/CD Pipeline

รัน Migration บน Production จึงมักถือสิทธิ์แก้ไขโครงสร้าง Schema ของคุณ

Service Account ของ BI

บ่อยครั้งเป็นบัญชีเดียวที่ใช้ร่วมกันอยู่หลัง Dashboard ทุกตัวขององค์กร Credential เดียว ข้อมูลของทุกคน

ผู้ใช้ฐานข้อมูลของแอปพลิเคชัน

เกือบทุกครั้งได้รับสิทธิ์มากกว่าที่แอปพลิเคชันใช้จริง เพราะตอนพัฒนามันสะดวกกว่า

Replication และ CDC

ต้องมีสิทธิ์อ่านกว้างและสิทธิ์ Replication ตามการออกแบบ ไม่มีใครตั้งคำถาม เพราะมันจำเป็นจริง ๆ

เครื่องมือ Backup และ DR

การอ่านได้ทั้งหมดคือจุดประสงค์ของมัน ซึ่งเป็นเหตุผลเดียวกับที่ไม่เคยมีใครมาทบทวน

การเชื่อมต่อกับบุคคลที่สาม

Vendor ต่อตรงเข้าฐานข้อมูลของคุณ และไม่มีใครในองค์กรเป็นเจ้าของการทบทวนนั้น

สคริปต์ Migration ที่ใช้ครั้งเดียว

สร้างขึ้นเพื่อโปรเจกต์ที่จบไปหลายปีแล้ว แต่บัญชีนั้นยังใช้งานได้จนถึงวันนี้

AI Agent และ MCP Endpoint

ใหม่ที่สุด มีจำนวนน้อยที่สุด และเป็นตัวที่ได้รับความสนใจทั้งหมด

แบบทดสอบที่ไม่สบายใจนัก

เลือกฐานข้อมูลที่สำคัญที่สุดสามตัวของคุณ แล้วตอบสองคำถามสำหรับทุก Identity ที่ไม่ใช่มนุษย์ซึ่งเชื่อมต่ออยู่ ว่าตอนนี้มันอ่านอะไรได้ และตอนนี้มันแก้ไขอะไรได้

ถ้าใช้เวลาหาคำตอบเกินหนึ่งวัน คำตอบตามตรงคือคุณยังไม่รู้ และบทสนทนาทุกเรื่องที่ตามมา รวมถึงเรื่อง AI Agent ก็เร็วเกินไป เพราะคุณประเมินความเสี่ยงส่วนเพิ่มของ Client ตัวใหม่ไม่ได้ ในเมื่อ Client ที่มีอยู่เดิมยังไม่เคยถูกทำแผนที่

การทำแผนที่นั้นไม่ใช่โครงการ Transformation เป็นงานแบบ Read-Only ทั้งหมด ใช้เวลาราวสองสัปดาห์ และไม่ต้องซื้อซอฟต์แวร์ใหม่

ตรวจสอบการเข้าถึงฐานข้อมูลโดยผู้ใช้ที่ไม่ใช่มนุษย์

ตอนนี้ Pipeline, Job และ Agent ของคุณทำอะไรได้บ้างบน Production?

เราทำแผนที่ทุก Identity ที่ไม่ใช่มนุษย์ซึ่งแตะฐานข้อมูลของคุณ ว่าแต่ละตัวเข้าถึงอะไรได้ แก้ไขอะไรได้ และตัวไหนถือ Credential ที่ไม่เคยหมดอายุ เป็นงาน Read-Only ใช้เวลาสองสัปดาห์ ไม่ต้องใช้ License

ขอรับการตรวจสอบ →

contact@infozense.com  |  +66-82-242-4008  |  Bangkok, Thailand