Security และ Compliance เบื้องต้น

ไอเดียหลักในหนึ่งประโยค

นอกจาก dashboard และ alert แล้ว Datadog ยังครอบคลุม cloud security posture และ runtime threat, การตรวจจับข้อมูลอ่อนไหว และ access control ระดับละเอียด — ซึ่งอย่างหลังปกป้องการตัดสินใจเรื่อง cost และ reliability ที่สอนมาก่อนหน้าในคอร์สนี้โดยตรง ถ้าคุณอ่านให้ออกว่าแต่ละ permission ให้สิทธิ์อะไรจริง ๆ

🐶 ที่มาของข้อมูลในบทนี้

ไม่มีอะไรถูกส่งไป Datadog และไม่ได้ใช้บัญชีจริง ข้อเท็จจริงเรื่อง product และ permission quote จาก docs.datadoghq.com (ดึงเมื่อ 2026-09-30 พร้อม URL ในบรรทัด) fence ของ Terraform validate ด้วย terraform init + terraform validate กับ provider DataDog/datadog 4.22.0 ที่ pin ไว้ ใช้ key ปลอมและ validate = false สิ่งที่ต้องมี org จริง (UI แสดงอะไร, terraform plan resolve ได้ค่าอะไร) ระบุไว้ว่าเป็นข้อมูลจาก docs เท่านั้น

Cloud Security Management: ตอนนี้เรียกว่าอะไร

ตระกูล product ที่บทนี้เรียกว่า Cloud Security Management (CSM) ถูกเปลี่ยนชื่อและแบ่งใหม่มาหลายรอบ บทความเก่า (และ output ของ AI ที่เก่า) ยังพูดว่า CSPM (Cloud Security Posture Management) ซึ่งเป็นแค่ครึ่ง posture สิ่งที่ docs ปัจจุบันบอกจริง ๆ

• หน้า docs https://docs.datadoghq.com/security/cloud_security_management/ ใช้ชื่อหน้าว่า “Cloud Security” และเปิดด้วย: “Datadog Cloud Security delivers deep visibility, continuous configuration audits, identity risk assessments, vulnerability detection, and real-time threat detection across your entire cloud infrastructure” path ของ URL ยังเป็น cloud_security_management แต่เนื้อหาหน้าไม่ได้ใช้ชื่อ “Cloud Security Management” เลย
• feature ที่ลิสต์: Misconfigurations (“Tracks the security hygiene and compliance posture of your production environment”), Identity Risks และ Vulnerabilities (URL เดียวกัน)
• runtime detection มี section ใน docs ของตัวเอง คือ Workload Protection (https://docs.datadoghq.com/security/workload_protection/): “Datadog Workload Protection provides real-time visibility and defense for your infrastructure by continuously monitoring file, network, and process activity across your environment”
• ชื่อเก่ายังเหลืออยู่แค่ใน navigation tree ของ docs ที่ยังมี entry ชื่อ “Cloud Security Posture Management”

ดังนั้นคำศัพท์ที่ปลอดภัยคือ Cloud Security (CSM เป็นชื่อ umbrella ที่ยังเจอได้ทั่วไป) สำหรับ Misconfigurations / Identity Risks / Vulnerabilities และ Workload Protection สำหรับ runtime threat ถ้าบทเรียน, PR หรือคำตอบของ AI พูดว่า “เปิด CSPM” ให้ถือว่าเป็นแค่ครึ่ง posture และเช็กชื่อ product ปัจจุบันใน docs ก่อนเขียนลง runbook

สองปัญหาที่ตระกูลนี้แก้ ในเชิงแนวคิด

• Posture management (Misconfigurations) — ตรวจ cloud account และ resource อย่างต่อเนื่องเพื่อหา misconfiguration เช่น S3 bucket ที่เปิดอ่านสาธารณะ, IAM policy ที่เปิดกว้างเกิน หรือ security group ที่เปิดให้ทั้งโลก เป็น finding เรื่อง การตั้งค่า ไม่ขึ้นกับว่ามีอะไรเลวร้ายเกิดขึ้นแล้วหรือยัง
• Runtime threats (Workload Protection) — detection rule ที่รันกับ signal สดจาก host, container และ Kubernetes (process, การเข้าถึงไฟล์, network connection) เพื่อจับสิ่งที่เกิดขึ้นจริงตอนนี้ เช่น container ที่ spawn shell ที่ไม่คาดคิด

ประเด็นสำหรับคอร์สนี้: มันไม่ใช่ product แยกที่ต้องติดตั้ง instrumentation ใหม่ — docs ระบุว่า “leverages both the Datadog Agent and Agentless” ส่วนใหญ่จึง reuse Agent และ cloud integration ที่ตั้งไว้ในโมดูล Foundations แล้วชี้ไปที่ rule engine ตัวอื่น ราคาและ feature ที่เปิดในแผนของคุณขึ้นกับ account บทนี้จึงไม่ quote ตัวเลข

Sensitive Data Scanner

Sensitive Data Scanner (SDS) มองหา pattern ที่ตรงกับข้อมูลอ่อนไหว — เลขบัตรเครดิต, API key, IP address, PII หรือ regex ที่กำหนดเอง — ใน telemetry ระหว่างที่ไหลผ่าน Datadog จาก docs (https://docs.datadoghq.com/security/sensitive_data_scanner/): ครอบคลุม “logs, APM spans, RUM events, and events” และ UI มีสี่ action: Redact (แทนด้วย token ที่เลือก), Partially redact, Hash (“non-reversible unique identifier”) และ Mask โดย Mask ใช้ได้กับ log, APM span และ RUM event เท่านั้น ทำได้โดยไม่ต้องแก้สิ่งที่ application log จริง เป็น safety net สำหรับข้อมูลอ่อนไหวที่หลุดเข้า log line เสมอ

config ของ scanner เก็บใน Terraform ได้ด้วย และคำศัพท์ของ provider ไม่ตรงกับคำศัพท์ใน UI fence นี้ validate ผ่านกับ provider 4.22.0

terraform/checkout-sds.tf

resource "datadog_sensitive_data_scanner_group" "checkout_logs" {
  name         = "checkout-api logs"
  description  = "Scan checkout-api logs for card numbers"
  is_enabled   = true
  product_list = ["logs"]

  filter {
    query = "service:checkout-api"
  }
}

resource "datadog_sensitive_data_scanner_rule" "card_number" {
  name       = "credit card number"
  group_id   = datadog_sensitive_data_scanner_group.checkout_logs.id
  is_enabled = true
  pattern    = "\\d{16}"

  text_replacement {
    type = "hash"
  }
}

text_replacement.type รับ none, hash, replacement_string, partial_replacement_from_beginning หรือ partial_replacement_from_end (docs ของ provider สำหรับ datadog_sensitive_data_scanner_rule tag v4.22.0) — ไม่มีค่า redact หรือ mask ส่วน product_list ถูกตรวจตอน validate; ["log"] (เอกพจน์) ที่ดูสมเหตุสมผลจะ fail ในเครื่อง

Error: Invalid enum value
  on main.tf line 27, in resource "datadog_sensitive_data_scanner_group" "logs_group":
  27:   product_list = ["log"]
`invalid value 'log' for SensitiveDataScannerProduct: valid values are [logs
rum events apm]`

docs ยังลิสต์ permission แยกสำหรับ scanner: data_scanner_read, data_scanner_write และ data_scanner_unmask (“Unmask (view) sensitive data that was previously masked”) ทั้งหมด default ที่ Datadog Admin Role (https://docs.datadoghq.com/account_management/rbac/permissions/) — ใครสั่ง unmask ได้สำคัญพอ ๆ กับตัว rule

ตัวอย่างจริง: RBAC ระดับละเอียดสำหรับ Log Management

Security posture และ data scanning เป็นเรื่องเนื้อหาของ telemetry ส่วน RBAC (role-based access control) เป็นเรื่องว่าใครทำอะไรได้ใน Datadog เอง และ Log Management เป็นหนึ่งในที่ที่เห็นความละเอียดนั้นชัดที่สุด — การตัดสินใจว่าอะไรถูก index, exclude หรือ archive คือการตัดสินใจเรื่อง cost โดยตรง

สิ่งที่ docs บอกเกี่ยวกับ log permission (https://docs.datadoghq.com/account_management/rbac/permissions/, default role ในวงเล็บเหลี่ยม)

• logs_modify_indexes [Datadog Standard Role] — “Read and modify all indexes in your account. This includes the ability to grant the Logs Read Index Data and Logs Write Exclusion Filters permission to other roles, for some or all indexes.”
• logs_write_exclusion_filters [Standard] — “Add and change exclusion filters for all or some log indexes. Can be granted in a limited capacity per index to specific roles via the Logs interface or API. If granted from the Roles interface or API, the permission has global scope.”
• logs_write_pipelines [Standard] — “Add and change log pipeline configurations, including the ability to grant the Logs Write Processors permission to other roles”
• logs_write_archives [Admin] — “Add and edit Log Archives.”
• logs_read_archives [Read Only] — “Read Log Archives location and use it for rehydration.”
• logs_generate_metrics [Standard] — “Create custom metrics from logs.”
• logs_write_facets [Standard] — “Create or edit Log Facets.”
• logs_read_data [Read Only] — “Read log data. In order to read log data, a user must have both this permission and Logs Read Index Data.”

Logs RBAC guide ฉบับยาว (https://docs.datadoghq.com/logs/guide/logs-rbac-permissions/) เพิ่มว่า logs_modify_indexes ครอบคลุมอะไรในทางปฏิบัติ: ตั้ง index filter ที่ route log เข้า index, ตั้ง retention ของ index และ “Granting another role the Logs Read Index Data and Logs Write Exclusion Filters permissions” — และ “This permission is global and enables both the creation of new indexes, and the edition of existing ones.”

กับดัก: role ของ log พังได้สามแบบ

1. logs_modify_indexes ไม่ใช่แค่ปุ่มคุม cost แต่เป็นสิทธิ์ในการ delegate และเป็น global ใครถือมันสร้าง index, เปลี่ยน routing filter กับ retention และแจก logs_read_index_data / logs_write_exclusion_filters ให้ role อื่นได้ ไม่มีเวอร์ชัน “แก้ได้เฉพาะ index ของทีมฉัน” — การจำกัดสิทธิ์ exclusion filter ให้เหลือบาง index guide บอกให้ถอด permission แบบ global ออกแล้วให้สิทธิ์ต่อ index ใน UI และ “This configuration is only supported through the UI” ดังนั้น role ที่จัดการด้วย Terraform อย่างเดียวจึงแสดงรูปแบบต่อ index ไม่ได้
2. คอลัมน์ default role อาจทำให้แปลกใจ ตาราง permission ลิสต์ Datadog Standard Role เป็นผู้ถือ default ของ logs_modify_indexes, logs_write_exclusion_filters และ logs_write_pipelines ถ้าคุณเข้าใจว่าเฉพาะทีม platform แก้ index ได้ ต้องเช็กว่า user ไม่ได้ยังอยู่บน managed Standard role docs: user “can clone them to create custom roles with specific permissions”
3. การอ่าน log ต้องใช้สอง permission logs_read_data อย่างเดียวไม่พอให้ user อ่าน log — docs บอกว่า user “must have both this permission and Logs Read Index Data” guide เรียก logs_read_index_data ว่าเป็นวิธีเก่าแบบต่อ index แต่เพิ่มว่า “it is still required to have this permission enabled to access indexed data” custom role “log viewer” ที่ประกอบจาก logs_read_data อย่างเดียวดูถูกต้องตอน review แต่ไม่คืนอะไรเลยให้ user

ฝั่ง Terraform ก็มีจุดบอด data source datadog_permissions expose permissions เป็น map ที่ key คือชื่อ permission ซึ่ง resolve กับ API ตอน plan terraform validate ไม่รู้ key จึงปล่อย key ที่สะกดผิดผ่าน ทดลองรันกับ provider ที่ pin ไว้

resource "datadog_role" "typo" {
  name = "Typo"
  permission { id = data.datadog_permissions.dd_perms.permissions.logs_modify_indexez }
}
$ terraform validate
Success! The configuration is valid.

เทียบกับบทก่อนหน้าที่ attribute สะกดผิด (notify_no_data_timeframe) fail ตอน validate ส่วน ชื่อ permission ที่สะกดผิดจะถูกจับทีหลัง (plan/apply ซึ่งต้องใช้ API จริง — ไม่ได้รันที่นี่ ดังนั้นสิ่งที่ plan พิมพ์จึงไม่ได้พิสูจน์) ให้ review ชื่อ permission ด้วยการอ่าน ไม่ใช่เชื่อว่า validate เขียวแล้วจบ

role สำหรับ investigator แบบ least-privilege ที่อ่าน log ได้ สร้าง log-based metric ได้ และแตะ index ไม่ได้

terraform/log-investigator-role.tf

data "datadog_permissions" "dd_perms" {}

resource "datadog_role" "log_investigator" {
  name = "Log Investigator"

  permission {
    id = data.datadog_permissions.dd_perms.permissions.logs_read_data
  }
  permission {
    id = data.datadog_permissions.dd_perms.permissions.logs_read_index_data
  }
  permission {
    id = data.datadog_permissions.dd_perms.permissions.logs_generate_metrics
  }
}

docs ของ provider ยังอธิบาย default_permissions_opt_out บน datadog_role: “If set to true, the role does not have default (restricted) permissions unless they are explicitly set” และ attribute include_restricted ของ data source ต้องเป็น true จึงจัดการ default permission ใน Terraform ได้ ผมไม่ได้รัน plan เพื่อดูว่า role ใหม่ได้ default อะไร ดังนั้นหลัง apply ครั้งแรกให้ audit role ใน UI แทนที่จะสมมติว่ามันถือแค่สิ่งที่คุณลิสต์ไว้

flowchart LR
  A["Investigator role"] -->|"logs_read_data + logs_read_index_data, logs_generate_metrics"| B["Search logs, build log-based metrics"]
  C["Platform / SRE custom role"] -->|"logs_modify_indexes, logs_write_exclusion_filters, logs_write_pipelines"| D["Change what is indexed, excluded, parsed"]
  D -->|"logs_modify_indexes can also grant read + exclusion rights"| A
  E["Auditor role"] -->|"logs_read_archives"| F["Archive location and rehydration"]
  D -->|"directly affects"| G["Log cost from indexed volume and retention"]

แยกสิทธิ์อ่านออกจากสิทธิ์คุม index/exclusion/archive

🐶 สรุปหนึ่งบรรทัด

Cloud Security (หลายที่ยังเรียก Cloud Security Management หรือ CSM ไม่ใช่แค่ “CSPM”) ครอบคลุม Misconfigurations, Identity Risks และ Vulnerabilities, Workload Protection ครอบคลุม runtime threat, Sensitive Data Scanner จับ pattern อ่อนไหวใน telemetry — และสำหรับ log RBAC logs_modify_indexes เป็น permission แบบ global ที่ delegate ต่อได้ และ managed Standard role ถือเป็น default ส่วน logs_read_data อย่างเดียวอ่าน log ไม่ได้

Reading AI-generated code

🐛 หา bug ในโค้ดนี้

# AI comment: "Read-only role so engineers can search logs and see index config"
data "datadog_permissions" "dd_perms" {}

resource "datadog_role" "log_viewer" {
name = "Log Viewer"

permission {
  id = data.datadog_permissions.dd_perms.permissions.logs_read_data
}
permission {
  id = data.datadog_permissions.dd_perms.permissions.logs_modify_indexes
}
}

เฉลย

อันนี้ validate ผ่าน (terraform validate พิมพ์ Success!) ซึ่งเป็นเหตุผลที่อันตราย มีสองปัญหาที่ validator ไม่เห็น

• คอมเมนต์บอก “read-only” แต่ logs_modify_indexes ไม่ใช่ read permission docs: “Read and modify all indexes in your account” เป็น global และรวมสิทธิ์แจก Logs Read Index Data กับ Logs Write Exclusion Filters ให้ role อื่น วิศวกรทุกคนใน role นี้เปลี่ยน retention และ routing ของทุก index ได้ — และแจกสิทธิ์เพิ่มได้
• role นี้ยังอ่าน log ไม่ได้: docs ต้องการ ทั้ง logs_read_data และ logs_read_index_data เส้นทางอ่านที่ตั้งใจไว้หายไป

วิธีแก้คือเปลี่ยน permission อันตรายเป็นตัวที่จำเป็น (validate กับ provider 4.22.0 แล้ว)

terraform/log-viewer-role-fixed.tf

data "datadog_permissions" "dd_perms" {}

resource "datadog_role" "log_viewer" {
  name = "Log Viewer"

  permission {
    id = data.datadog_permissions.dd_perms.permissions.logs_read_data
  }
  permission {
    id = data.datadog_permissions.dd_perms.permissions.logs_read_index_data
  }
}

Mental Model

แบ่ง permission เป็นสามแถบ: read (logs_read_data + logs_read_index_data, logs_read_archives), shape (logs_write_pipelines, logs_write_facets, logs_generate_metrics — เปลี่ยนวิธีที่ log ถูกเข้าใจ) และ spend (logs_modify_indexes, logs_write_exclusion_filters, logs_write_archives — เปลี่ยนว่าเก็บอะไรและนานแค่ไหน คือตัวบิลนั่นเอง) logs_modify_indexes ยังอยู่ในแถบ “delegate” ด้วยเพราะแจกสิทธิ์ spend/read อีกสองตัวได้ product ด้าน security ก็ใช้หลักเดียวกัน: posture และ runtime product ทำหน้าที่ detect, Sensitive Data Scanner แปลง telemetry และ RBAC ตัดสินว่าใครปิดทั้งหมดนี้ได้

Trade-offs

• Custom role เทียบกับ managed role — managed role ถูกดูแลโดย Datadog และ “may be automatically updated by Datadog as new features are added” เนื้อหาจึงเลื่อนไปใต้เท้าคุณ; custom role (clone หรือเขียนใน Terraform) คงที่และ review ได้ แต่คุณต้องดูแลให้ครบเอง และ logs_read_data ที่ไม่มี logs_read_index_data แสดงว่า role ที่ประกอบมือเพี้ยนแบบเนียน ๆ ได้ง่ายแค่ไหน
• สิทธิ์ exclusion filter แบบ global เทียบกับต่อ index — scope ต่อ index จำกัด blast radius แต่ตาม docs ตั้งได้ผ่าน UI เท่านั้น จึงไม่อยู่ใน Terraform code ของคุณ
• Hash เทียบกับ redact เทียบกับ mask ใน SDS — hash ย้อนกลับไม่ได้, redact/partial redact เก็บ token หรือบางส่วนไว้ debug และ mask ครอบคลุม product แคบที่สุด (log, APM span, RUM event) เลือกตามประเภทข้อมูล; docs ลิสต์ unmask เป็น permission แยก
• Detect posture เทียบกับ detect runtime — Misconfigurations บอกว่าประตูไม่ได้ล็อก Workload Protection บอกว่ามีคนเดินผ่านเข้าไปแล้ว โดยทั่วไปต้องการทั้งคู่ โดยแลกกับการเก็บข้อมูลฝั่ง Agent มากขึ้น

Common Misconceptions

• “CSPM คือชื่อปัจจุบันของ product cloud security ของ Datadog” ชื่อหน้า docs ปัจจุบันคือ “Cloud Security” ที่มี Misconfigurations, Identity Risks และ Vulnerabilities; runtime คือ Workload Protection CSPM เป็นชื่อเก่าที่ครอบคลุมแค่ posture และเหลืออยู่ใน nav tree ของ docs
• “logs_modify_indexes เป็น permission คุม cost เฉพาะทีม platform” default ถือโดย managed Standard role และเป็น global; ยังให้ผู้ถือแจก Logs Read Index Data กับ Logs Write Exclusion Filters ให้ role อื่นได้
• “logs_read_data พอสำหรับอ่าน log” docs ต้องการควบคู่กับ Logs Read Index Data
• “terraform validate เขียวแปลว่า datadog_role ให้สิทธิ์ตามที่ตั้งใจ” มันเช็กแค่รูปทรง HCL; ชื่อ permission เป็น map key ที่ resolve ตอน plan typo จึงผ่าน validate (พิสูจน์ข้างบน)
• “SDS ใช้ชื่อ action ใน Terraform เหมือนใน UI” ค่า text_replacement.type ของ provider คือ none, hash, replacement_string และ partial_replacement_* สองค่า

ใน docs ของ Datadog ปัจจุบัน product ที่หน้าลิสต์ Misconfigurations, Identity Risks และ Vulnerabilities เรียกว่าอะไร และ product ไหนครอบคลุมการเฝ้าดู file/network/process ระดับ runtime

CSPM ครอบคลุมทุกอย่างรวมถึง runtime Cloud Security (ตระกูล CSM) สำหรับ Misconfigurations, Identity Risks และ Vulnerabilities; Workload Protection สำหรับ runtime threat Sensitive Data Scanner ครอบคลุมทั้งสองอย่าง Cloud Cost Management ครอบคลุมทั้งสองอย่าง

Sensitive Data Scanner ทำอะไร และค่า Terraform ไหนเลือกการแทนที่แบบย้อนกลับไม่ได้

ลบ log ที่มี error ทั้งหมด; type = "delete" ตรวจ pattern เช่นเลขบัตรหรือ API key ใน log, APM span, RUM event และ event และ redact, hash หรือ mask ได้; text_replacement type = "hash" แทน Processing Pipeline; type = "grok" scan เฉพาะ metric; type = "redact"

ข้อใดเกี่ยวกับ logs_modify_indexes ถูกต้องตาม docs

ดู setting ของ index ได้อย่างเดียว เป็น global สร้างและแก้ index ได้ และรวมสิทธิ์แจก Logs Read Index Data กับ Logs Write Exclusion Filters ให้ role อื่น จำกัดที่หนึ่ง index ต่อ role โดย default ให้เฉพาะ Datadog Admin Role และยกให้คนอื่นไม่ได้

custom role "Log Viewer" มีแค่ logs_read_data เกิดอะไรขึ้นเมื่อ user ใน role นี้เปิด Log Explorer

อ่านได้ทุก log เพราะ logs_read_data เพียงพอ อ่าน log ไม่ได้: docs บอกว่า user ต้องมีทั้ง logs_read_data และ Logs Read Index Data อ่านได้เฉพาะ log ใน archive Datadog เพิ่ม Logs Read Index Data ให้อัตโนมัติ

คุณสะกด permission key ผิดเป็น data.datadog_permissions.dd_perms.permissions.logs_modify_indexez terraform validate กับ provider 4.22.0 รายงานอะไร

Unsupported argument เหมือน attribute ของ resource ที่สะกดผิด Success — ชื่อ permission เป็น map key ที่ resolve ตอน plan validate จึงจับ typo ไม่ได้ Invalid enum value Sensitive value error

ทำไมการจำกัด logs_write_exclusion_filters ให้เหลือบาง index ถึงลำบากสำหรับ workflow ที่ใช้ Terraform อย่างเดียว

Terraform สร้าง role ไม่ได้เลย Logs RBAC guide บอกว่าการให้สิทธิ์ต่อ index ตั้งที่หน้า Index และ "is only supported through the UI" permission นี้ไม่มีใน provider scope ต่อ index ต้องใช้ Sensitive Data Scanner

Submit

Mark as complete