DevOps Fundamentals · โมดูล Compliance และ Security

CI/CD และ Compliance: ทำให้ทางที่ถูกต้องเป็นทางที่ง่ายที่สุด

Pipeline ระดับ enterprise 9 stage และกฎ 6 ฉบับที่จะเจอในงานจริง อธิบายด้วยข้อมูล ตัวเลข และตัวอย่างการ implement

เมษายน 2026 · เอกสารประกอบการสอน

Executive summary

Pipeline ที่ดีทำให้ developer เร็วขึ้นและตอบ auditor ได้พร้อมกัน เพราะ control ถูกทำให้อัตโนมัติ ไม่ใช่ถูกถอดออก

การตรวจต้องย้ายไปต้นทาง

ข้อผิดพลาดที่พบหลัง release แพงกว่าตอนออกแบบราว 100 เท่า และองค์กรที่ deploy บ่อยกลับมี change failure rate ต่ำกว่า 3 เท่า Pipeline 9 stage คือกลไกที่ทำให้เกิดผลนี้: lint, build, test, security, package, staging, verify, production, post-deploy

Compliance คือหลักฐาน ไม่ใช่ความรู้สึกปลอดภัย

กฎทั้ง 6 ฉบับ (HIPAA, GDPR, PDPA, PCI DSS, SOC 2, ISO 27001) ถามคำถามเดียวกัน: ใครทำอะไร เมื่อไหร่ ผ่านกลไกไหน แบบแผน Requirement, Control, Evidence ใช้ได้กับทุกฉบับ และ control 8 อย่างครอบคลุมทั้ง 6 กฎ

Control ที่มองไม่เห็นตอนล้มเหลว ไม่ใช่ control

องค์กรพบ breach ด้วยตัวเองเพียง 42% กรณีศึกษาไฟล์ประกันที่ "สำเร็จ" 4 คืนโดยไม่ถึงปลายทางแสดงว่า การตรวจว่า job รัน ไม่เท่ากับการตรวจว่าผลลัพธ์เกิดขึ้น

ที่มา: IBM Systems Sciences Institute; DORA State of DevOps 2023; IBM Cost of a Data Breach 20242

ส่วนที่ 1

GitLab CI/CD pipeline ระดับ enterprise

ทำไมต้องมีหลาย stage แต่ละ stage ตอบคำถามอะไร และอย่างน้อยต้องมีอะไรอยู่ในนั้น

ทำไมต้นทุนของข้อผิดพลาดและผลลัพธ์ของทีมที่ทำได้ดี

อะไร9 stage และคำถามที่แต่ละ stage ตอบ

อย่างไรControl ขั้นต่ำ หลักฐาน และตัวอย่าง config

ส่วนที่ 1 · ทำไม

ข้อผิดพลาดที่พบหลัง release แพงกว่าที่พบตอนออกแบบราว 100 เท่า ดังนั้น pipeline ต้องย้ายการตรวจทุกอย่างไปไว้ต้นทาง

ต้นทุนสัมพัทธ์ในการแก้ข้อผิดพลาด 1 รายการ ตามขั้นตอนที่พบ (ออกแบบ = 1)

ความหมายต่อการออกแบบ pipeline

ทุกอย่างที่ตรวจได้ด้วยเครื่อง ต้องตรวจก่อน merge ไม่ใช่หลัง deploy: lint, unit test, security scan
Merge request คือจุดที่ถูกที่สุดในการปฏิเสธ change ที่ไม่ผ่านเกณฑ์ เพราะยังไม่มีใครต้องรอ rollback
Stage ที่ตรวจช้า (E2E, DAST) ยังคุ้มถ้าเทียบกับต้นทุน 100 เท่าของการพบบน production

หลักการข้อแรกของ pipeline: ยิ่งจับได้เร็ว ยิ่งถูก และ "เร็ว" ที่สุดคือก่อน code จะรวมเข้า branch หลัก

ที่มา: IBM Systems Sciences Institute อัตราส่วนที่ถูกอ้างอิงกว้างขวางในงาน software engineering ตัวเลขเป็นค่าประมาณ ไม่ใช่ค่าคงที่ของทุกองค์กร4

ส่วนที่ 1 · ทำไม

องค์กรที่ deploy บ่อยกว่ากลับพังน้อยกว่า: ทีมระดับ elite มี change failure rate 5% เทียบกับ 64% ของทีมระดับ low และกู้คืนเร็วกว่าหลายร้อยเท่า

Change failure rate สัดส่วน deploy ที่ทำให้เกิดปัญหาบน production

EliteLow

การ deploy บ่อยไม่ได้สร้างความเสี่ยง การ deploy ด้วยขั้นตอนที่คนต้องจำเองต่างหากที่สร้าง

DORA 4 metrics เทียบ elite กับ low performer

Metric	Elite	Low	Stage ที่ขับเคลื่อน
Deployment frequency	หลายครั้งต่อวัน	1 ครั้งต่อ 1 ถึง 6 เดือน	build once, deploy อัตโนมัติ
Lead time for changes	น้อยกว่า 1 วัน	1 ถึง 6 เดือน	ตรวจใน MR, needs แทน stage รอ
Change failure rate	5%	64%	test, security, staging verify
Failed deployment recovery	น้อยกว่า 1 ชั่วโมง	1 สัปดาห์ ถึง 1 เดือน	rollback job, post-deploy check

ที่มา: DORA, Accelerate State of DevOps Report 2023 (Google Cloud) ค่าของกลุ่ม elite และ low5

ส่วนที่ 1 · อะไร

Pipeline ระดับ enterprise มี 9 stage และแต่ละ stage ตอบคำถามที่ต่างกัน 1 ข้อ ตั้งแต่ "code ถูกรูปแบบไหม" จนถึง "ผู้ใช้ได้ผลลัพธ์จริงไหม"

1 lint

2 build

3 test

4 security

5 package

6 staging

7 verify

8 production

9 post-deploy

code ตรงมาตรฐานทีมไหม

สร้าง artifact ซ้ำได้ไหม

behavior เดิมยังอยู่ไหม

มีช่องโหว่หรือ secret ไหม

image ระบุตัวตนและเซ็นแล้วไหม

ระบบทั้งชิ้นทำงานร่วมกันไหม

ผ่าน E2E และ DAST ไหม

ใครอนุมัติ ถอยกลับได้ไหม

ผู้ใช้ได้ผลลัพธ์จริงไหม

โครงไฟล์ .gitlab-ci.yml ระดับองค์กร

stages: [lint, build, test, security, package,
         deploy-staging, verify, deploy-prod, post-deploy]

include:
  # template กลางของ platform team, pin ที่ major version
  - project: platform/ci-templates
    ref: v2
    file: /base.yml
  # template security ของ GitLab
  - template: Jobs/SAST.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml
  - template: Jobs/Container-Scanning.gitlab-ci.yml
  - template: DAST.gitlab-ci.yml

workflow:
  rules:
    - if: $CI_PIPELINE_SOURCE == "merge_request_event"
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

หลักการ 4 ข้อที่ทุก stage ต้องเคารพ

Build once, promote many. Image ที่ขึ้น production ต้องเป็น digest เดียวกับที่ผ่าน test ห้าม build ใหม่ต่อ environment
ตรวจก่อน merge ไม่ใช่หลัง. Stage 1 ถึง 4 รันบน merge request ไม่ผ่านห้าม merge
Template กลาง. Platform team ดูแล job ที่เหมือนกันทุก repo ทีม dev เขียนเฉพาะส่วนที่ต่าง
Production ต้องมีคนกดและมีบันทึก. Protected environment, approval rule, rollback ที่ซ้อมแล้ว

5 stage แรก (สีน้ำเงินเข้ม) ป้องกันของเสียเข้าระบบ 4 stage หลัง (สีน้ำเงิน) พิสูจน์ว่าของดีถึงผู้ใช้

ที่มา: GitLab CI/CD documentation; แนวปฏิบัติของทีมที่บรรยาย6

ส่วนที่ 1 · อย่างไร · stage 1 ถึง 3

Lint, build และ test ทำให้เกิด artifact เพียงชิ้นเดียวที่ผ่านการตรวจก่อน merge และผูกกับ commit ที่ระบุตัวตนได้

Stage	อย่างน้อยต้องมี	ถ้าไม่มี	หลักฐานที่ได้
1 lint	Linter, formatter และ type check ตาม stack ใช้ config เดียวกับ editor `--max-warnings 0` block merge	Review ครึ่งหนึ่งเป็นเรื่อง style; unused code และ type ผิดหลุดถึง production	job log ผูก commit SHA, MR status
2 build	Lock file และ `npm ci`; artifact ออกทางเดียวพร้อม expiry; version = commit SHA; cache แยกตาม lock file	"บนเครื่องผมรันได้"; rollback ไม่ได้เพราะ build ใหม่ได้ของไม่เหมือนเดิม	artifact ชื่อผูก SHA, ไฟล์ VERSION ในตัว artifact
3 test	Unit test ทุก MR; รายงาน JUnit และ coverage; threshold ที่ตกลงกัน; test flaky ต้องแก้ไม่ใช่ retry; test เส้นทางล้มเหลว	ทุก change ต้องทดสอบมือ; bug เดิมกลับมาซ้ำ; ตอบ auditor ไม่ได้ว่า change ถูกทดสอบอย่างไร	JUnit report, coverage diff ใน MR

build:
  stage: build
  image: node:20
  cache: { key: { files: [package-lock.json] }, paths: [node_modules/] }
  script:
    - npm ci --prefer-offline
    - npm run build
    - echo "$CI_COMMIT_SHA" > dist/VERSION
  artifacts: { name: "app-$CI_COMMIT_SHORT_SHA", paths: [dist/], expire_in: 1 week }

unit-test:
  stage: test
  needs: [build]
  script: npm test -- --ci --coverage --reporters=jest-junit
  artifacts:
    when: always
    reports:
      junit: junit.xml
      coverage_report: { coverage_format: cobertura, path: coverage/cobertura-coverage.xml }

อาการที่พบบ่อยในองค์กร: มี test แต่ตั้ง allow_failure: true มาตั้งแต่ปีก่อน ไม่มีใครรู้ว่ามันแดงมานานแค่ไหน Control ที่ไม่ block ไม่ใช่ control

ที่มา: GitLab CI/CD documentation7

ส่วนที่ 1 · อย่างไร · stage 4

84% ของ codebase มีช่องโหว่จาก open source ดังนั้น security scan ต้องรันทุก commit ใน pipeline ไม่ใช่ audit ปีละครั้ง

สัดส่วน codebase เชิงพาณิชย์ที่ตรวจพบ (n = 1,067)

ช่องโหว่ส่วนใหญ่ไม่ได้อยู่ใน code ที่เราเขียน แต่อยู่ใน library ที่เราดึงมา และ library เปลี่ยนสถานะจากปลอดภัยเป็นไม่ปลอดภัยได้ทุกวันโดยที่ code เราไม่เปลี่ยน

Scan 4 ชนิดที่ต้องอยู่ใน stage security

ชนิด	หาอะไร	นโยบาย
SAST	Pattern อันตรายใน code เช่น SQL injection, XSS, hardcoded password	Critical และ high ห้าม merge ยกเว้น exception ที่มีเจ้าของ เหตุผล และวันหมดอายุ
Secret detection	Token, key, password ใน diff และ git history
Dependency scanning	Library เทียบฐาน CVE และออก SBOM (CycloneDX)
License check	License ที่บริษัทห้าม เช่น GPL ในผลิตภัณฑ์ปิด

include:
  - template: Jobs/SAST.gitlab-ci.yml
  - template: Jobs/Secret-Detection.gitlab-ci.yml
  - template: Jobs/Dependency-Scanning.gitlab-ci.yml
secret_detection:
  variables: { SECRET_DETECTION_HISTORIC_SCAN: "true" }
dependency_scanning:
  artifacts: { reports: { cyclonedx: "gl-sbom-*.cdx.json" } }
# block merge: Security & Compliance > Policies > Merge request approval

ที่มา: Synopsys, Open Source Security and Risk Analysis Report 2024 (ตรวจ 1,067 codebase ใน 17 อุตสาหกรรม); GitLab documentation8

ส่วนที่ 1 · อย่างไร · stage 5

Image ที่ขึ้น production ต้องระบุด้วย digest และมีลายเซ็นจาก pipeline จึงจะพิสูจน์ได้ว่าเป็นของเดียวกับที่ผ่านการตรวจ

Control ขั้นต่ำใน stage package

Tag image ด้วย commit SHA และอ้างอิงด้วย digest ตอน deploy ห้ามใช้ latest
Push เข้า registry ขององค์กรเท่านั้น (GitLab Container Registry, ECR)
Container scanning หลัง push เพราะ base image มีช่องโหว่ของตัวเองที่ scanner ระดับ code มองไม่เห็น
Base image จาก list ที่ platform team ดูแลและ patch สม่ำเสมอ
Sign ด้วย cosign ผ่าน OIDC ของ GitLab ไม่ต้องเก็บ private key และ cluster ปฏิเสธ image ที่ไม่มีลายเซ็น

SolarWinds 2020: build system ถูกฝัง backdoor ลูกค้ากว่า 18,000 รายรับ update ที่ "ถูกต้อง" ไป นี่คือเหตุผลที่ต้องเซ็นและตรวจ provenance ของ artifact ไม่ใช่แค่ตรวจ code

ตัวอย่าง config

package:
  stage: package
  image: gcr.io/kaniko-project/executor:debug
  needs: [unit-test, sast, dependency_scanning]
  script:
    - /kaniko/executor --context "$CI_PROJECT_DIR"
        --destination "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
  rules:
    - if: $CI_COMMIT_BRANCH == $CI_DEFAULT_BRANCH

container_scanning:
  needs: [package]
  variables:
    CS_IMAGE: "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
    CS_SEVERITY_THRESHOLD: HIGH

sign:
  stage: package
  image: bitnami/cosign:latest
  needs: [package]
  id_tokens:
    SIGSTORE_ID_TOKEN: { aud: sigstore }
  script:
    - cosign sign --yes "$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"

หลักฐาน: registry บอกได้ว่า digest ไหนถูก push โดย pipeline ไหนจาก commit ไหน; ลายเซ็นตรวจได้ที่ cluster ด้วย admission controller (Kyverno, Sigstore policy controller)

ที่มา: GitLab documentation; Sigstore; รายงานสาธารณะกรณี SolarWinds Orion (2020)9

ส่วนที่ 1 · อย่างไร · stage 6 และ 7

Staging ต้องรับ image เดียวกับที่จะขึ้น production และรับเฉพาะข้อมูลที่ปิดบังแล้ว จึงจะทดสอบระบบทั้งชิ้นได้โดยไม่ละเมิดกฎ

Control ขั้นต่ำ

Deploy staging อัตโนมัติทุก merge เข้า branch หลัก ด้วย digest จาก stage package
Staging สร้างจาก IaC ชุดเดียวกับ production ต่างกันแค่ตัวแปร
Integration หรือ E2E test รันกับ staging (Playwright, Cypress, Postman)
DAST ยิงระบบที่รันจริงเพื่อหาช่องโหว่ที่ SAST มองไม่เห็น: auth, header, TLS
ข้อมูลใน staging เป็นข้อมูลสังเคราะห์หรือข้อมูลจริงที่ pseudonymize แล้ว ห้ามใช้ PII หรือ PHI จริง

ถ้าไม่มี: ปัญหา integration แรกไปเจอตอนลูกค้าใช้ migration ที่พังจะพังบน production เป็นครั้งแรก และการใช้ข้อมูลลูกค้าจริงใน staging เท่ากับให้ developer ทุกคนเห็น PII ซึ่งละเมิด PDPA, GDPR และ HIPAA พร้อมกัน

ตัวอย่าง config

deploy-staging:
  stage: deploy-staging
  needs: [container_scanning, sign]
  environment: { name: staging, url: https://staging.example.com }
  script:
    - kubectl -n staging set image deploy/app
        app="$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
    - kubectl -n staging rollout status deploy/app --timeout=180s

e2e:
  stage: verify
  image: mcr.microsoft.com/playwright:v1.47.0-jammy
  needs: [deploy-staging]
  script: npx playwright test --reporter=junit
  artifacts: { when: always, reports: { junit: results.xml } }

dast:
  stage: verify
  needs: [deploy-staging]
  variables:
    DAST_WEBSITE: https://staging.example.com
    DAST_FULL_SCAN_ENABLED: "true"

ทางเลือกที่ดีกว่าสำหรับองค์กร: pipeline แค่ commit image tag ลง repo ของ manifest แล้วให้ ArgoCD sync (GitOps) cluster จึงไม่ต้องรับ credential จาก runner

ที่มา: GitLab documentation; Playwright; OWASP ZAP (DAST engine ของ GitLab)10

ส่วนที่ 1 · อย่างไร · stage 8

Production ต้องมี approval ที่ระบบบันทึกเอง และ rollback ที่ซ้อมแล้ว เพราะ deploy ที่ถอยกลับไม่ได้คือการเดิมพัน ไม่ใช่การ release

Control ขั้นต่ำ

Protected environment: กำหนดกลุ่มที่ deploy ได้และจำนวน approver
Job เป็น when: manual พร้อม allow_failure: false ให้ pipeline หยุดรอจริง
Deploy ด้วย digest เดียวกับที่ผ่าน staging
Rollback job คลิกเดียว ซ้อมอย่างน้อยไตรมาสละครั้ง
Deploy freeze ในช่วงเสี่ยง เช่น open enrollment หรือสิ้นปี
Deployment ไม่ใช่ release: feature flag เปิดให้ผู้ใช้ทีละกลุ่ม

440 ล้านดอลลาร์ขาดทุนของ Knight Capital ใน 45 นาที (2012) จาก deploy ที่ขึ้นไม่ครบทุก server และไม่มี rollback

ตัวอย่าง config

deploy-prod:
  stage: deploy-prod
  needs: [e2e, dast]
  environment:
    name: production
    url: https://app.example.com
    on_stop: rollback-prod
  when: manual
  allow_failure: false
  resource_group: production   # deploy prod ทีละ 1 pipeline
  script:
    - kubectl -n prod set image deploy/app
        app="$CI_REGISTRY_IMAGE:$CI_COMMIT_SHA"
    - kubectl -n prod rollout status deploy/app --timeout=300s

rollback-prod:
  stage: deploy-prod
  environment: { name: production, action: stop }
  when: manual
  script: kubectl -n prod rollout undo deploy/app

# Settings > CI/CD > Protected environments
#   production: deploy = group release-managers
#   required approvals = 1 จาก group tech-leads

หลักฐาน: หน้า Environment ของ production คือ audit log ทุก deployment มี commit, คนกด, คนอนุมัติ, เวลา ปลอมไม่ได้ ไม่ต้องถ่าย screenshot

ที่มา: GitLab documentation; SEC order In the Matter of Knight Capital Americas LLC (2013)11

ส่วนที่ 1 · อย่างไร · stage 9

"Deploy สำเร็จ" ไม่เท่ากับ "ระบบทำงาน": stage post-deploy ต้องตรวจผลลัพธ์ที่ผู้ใช้เห็นจริงและบอกทุกคนว่าเกิดอะไรขึ้น

Control ขั้นต่ำ

Smoke test ยิง endpoint สำคัญหลัง deploy: health, login, ธุรกรรมหลัก 1 อย่าง และตรวจว่า version ที่ตอบกลับคือ commit ที่เพิ่งขึ้น
เช็ค error rate และ latency 5 ถึง 10 นาทีหลัง deploy เทียบกับก่อน deploy เกิน threshold ให้ rollback
ส่ง deployment marker ไป observability tool (Datadog, Grafana) ให้เห็นบน graph
แจ้ง channel ของทีมพร้อม link ไป pipeline

Rollout status บอกแค่ pod ขึ้น ไม่ได้บอกว่า request ผ่าน ไม่ได้บอกว่า database ต่อได้ Incident ครึ่งหนึ่งเริ่มจาก deploy และ "เพิ่ง deploy ไปเมื่อกี้" คือข้อมูลชิ้นแรกที่คนแก้ปัญหาอยากรู้

ข้อมูลจาก stage นี้คือฐานของ DORA metrics ทั้ง 4: deploy frequency, lead time, change failure rate, recovery time

ตัวอย่าง config

smoke-prod:
  stage: post-deploy
  image: curlimages/curl:8.10.1
  needs: [deploy-prod]
  script:
    - curl -fsS --retry 5 --retry-delay 5 https://app.example.com/healthz
    - curl -fsS https://app.example.com/api/version | grep "$CI_COMMIT_SHORT_SHA"

verify-error-rate:
  stage: post-deploy
  needs: [smoke-prod]
  script:
    # ถาม Datadog: error rate 10 นาทีหลัง deploy เกิน 1% ไหม
    - ./scripts/check-error-rate.sh --window 10m --max 1

annotate:
  stage: post-deploy
  needs: [deploy-prod]
  script:
    - ./scripts/datadog-event.sh "deploy $CI_COMMIT_SHORT_SHA by $GITLAB_USER_LOGIN"
    - ./scripts/slack.sh "#deploys" "live: $CI_PIPELINE_URL"

ที่มา: GitLab documentation; DORA metrics definitions12

ส่วนที่ 1 · สรุป

Pipeline ที่ครบ 9 stage ตอบคำถามของ auditor ได้ทั้ง 6 ข้อโดยไม่มีใครต้องเขียนเอกสารเพิ่ม

คำถามที่ auditor ถาม	Stage ที่ตอบ	หลักฐานที่ระบบสร้างเอง
ใครแก้ code และใครรีวิว	merge request	MR approvals, protected branch, CODEOWNERS
Code ผ่านมาตรฐานและ test อะไรบ้าง	1 lint, 3 test	job log, JUnit report, coverage ผูก commit SHA
ตรวจช่องโหว่อย่างไร	4 security, 5 package	SAST, secret, dependency, container report, SBOM
สิ่งที่ขึ้น prod เป็นสิ่งเดียวกับที่ test ไหม	2 build, 5 package	image digest เดียวกันทุก environment, ลายเซ็น cosign
ใครอนุมัติ deploy production และเมื่อไหร่	8 production	protected environment approval, deployment history
Deploy สำเร็จจริงไหม ถ้าพังทำอย่างไร	9 post-deploy	smoke test, error rate check, rollback job

ทางช้า หลักฐานอ่อน: developer กรอก spreadsheet, เปิด ticket, ส่ง email หาผู้จัดการ, ถ่าย screenshot, upload เข้า drive ทุกอย่างขึ้นกับความจำของคน

ทางเร็ว หลักฐานดีกว่า: เปิด merge request, มีคน approve, CI ตรวจ, pipeline deploy ทุกขั้นมีเวลาและตัวตนบันทึกไว้ Requirement เหมือนเดิม implementation ง่ายกว่าและพิสูจน์ได้ดีกว่า

ที่มา: สังเคราะห์จากสไลด์ 6 ถึง 1213

ส่วนที่ 2

Compliance 6 ฉบับที่จะเจอในงานจริง

HIPAA, GDPR, PDPA, PCI DSS, SOC 2, ISO 27001 แต่ละฉบับ: แนวคิด เหตุผลที่มี ขั้นต่ำที่ต้องทำ บทลงโทษ และ control ใน pipeline ที่ตอบได้

ทำไมต้นทุนของ breach และข้อมูลที่กำหนดกฎ

อะไรกฎ 6 ฉบับด้วยโครงเดียวกัน

อย่างไรControl 8 อย่างที่ครอบคลุมทั้งหมด และกรณีศึกษา

ส่วนที่ 2 · ทำไม

Breach ในธุรกิจสุขภาพแพงที่สุดที่ 9.77 ล้านดอลลาร์ต่อครั้ง สูงกว่าค่าเฉลี่ยทั่วโลก 2 เท่า และเป็นอันดับ 1 ติดต่อกัน 14 ปี

ต้นทุนเฉลี่ยต่อ breach 1 ครั้ง ปี 2024 (ล้านดอลลาร์สหรัฐ)

ทำไมข้อมูลสุขภาพถึงแพงที่สุด

ข้อมูลสุขภาพเปลี่ยนไม่ได้ ต่างจากบัตรเครดิตที่ออกใหม่ได้ ความเสียหายต่อบุคคลจึงถาวร
Regulator บังคับแจ้งเหตุ สอบสวน และติดตามหลายปี ต้นทุนไม่จบที่วันที่พบ
ระบบสุขภาพมี integration กับคู่ค้าจำนวนมาก ทุกจุดเชื่อมคือจุดรั่ว

258 วันเวลาเฉลี่ยตั้งแต่เกิด breach จนระบุและควบคุมได้ ปี 2024

องค์กรที่ใช้ security automation อย่างกว้างขวางมีต้นทุนต่อ breach ต่ำกว่าองค์กรที่ไม่ใช้เฉลี่ย 2.2 ล้านดอลลาร์

ที่มา: IBM Security และ Ponemon Institute, Cost of a Data Breach Report 2024 (604 องค์กร, 16 ประเทศ)15

ส่วนที่ 2 · ทำไม

ข้อมูลที่ถือเป็นตัวกำหนดกฎ ไม่ใช่ขนาดบริษัทหรือ cloud ที่ใช้ และระบบจริงส่วนใหญ่โดน 2 ถึง 3 ฉบับพร้อมกัน

ถ้าระบบจัดการ	กฎ	ประเภท	ขอบเขต	ใครบังคับใช้	โทษสูงสุด
ข้อมูลสุขภาพของคนในสหรัฐ	HIPAA	กฎหมาย	สหรัฐอเมริกา	HHS Office for Civil Rights	ค่าปรับต่อปีต่อประเภทเกิน 2 ล้านดอลลาร์; จำคุกถึง 10 ปี
ข้อมูลส่วนบุคคลของคนใน EU	GDPR	กฎหมาย	EU บังคับทั่วโลก	Data protection authority ของแต่ละประเทศ	20 ล้านยูโร หรือ 4% ของรายได้ทั่วโลก
ข้อมูลส่วนบุคคลของคนในไทย	PDPA	กฎหมาย	ประเทศไทย	คณะกรรมการคุ้มครองข้อมูลส่วนบุคคล	ปรับ 5 ล้านบาท; จำคุก 1 ปี; ค่าเสียหาย 2 เท่า
หมายเลขบัตรชำระเงิน	PCI DSS	สัญญา	ทั่วโลก	เครือข่ายบัตร ผ่านธนาคารผู้รับบัตร	5,000 ถึง 100,000 ดอลลาร์ต่อเดือน; ตัดสิทธิ์รับบัตร
ข้อมูลลูกค้าในฐานะ B2B SaaS (ลูกค้าสหรัฐ)	SOC 2	การรับรอง	ต้นกำเนิดสหรัฐ ใช้ทั่วโลก	ผู้สอบบัญชี CPA อิสระ	ไม่มีค่าปรับ; เสียดีลที่ขั้นจัดซื้อ
ข้อมูลลูกค้าในฐานะ vendor ให้องค์กรใหญ่หรือรัฐ	ISO 27001	การรับรอง	ทั่วโลก	หน่วยรับรองที่ได้รับการรับรองระบบงาน	ไม่มีค่าปรับ; ถูกเพิกถอนใบรับรอง; ตัดสิทธิ์ tender

ตัวอย่าง: แอปคลินิกในไทยที่ขายให้นายจ้างในสหรัฐและรับบัตรเครดิต โดน PDPA, HIPAA และ PCI DSS บนฐานข้อมูลเดียวกัน กฎ 3 แบบ: กฎหมาย ฝ่าฝืนมีค่าปรับและโทษอาญา สัญญา ฝ่าฝืนเสียสิทธิ์ทำธุรกิจ การรับรอง ไม่มีใครปรับ แต่ลูกค้าไม่เซ็นถ้าไม่มี

ที่มา: HHS; EU Regulation 2016/679; พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562; PCI SSC; AICPA; ISO16

ส่วนที่ 2 · อะไร

Compliance ไม่ใช่ "เราปลอดภัยแล้ว" แต่คือหลักฐานว่าใครทำอะไร เมื่อไหร่ ผ่านกลไกไหน แบบแผน Requirement, Control, Evidence ใช้ได้กับทุกกฎ

Requirement

Control

Evidence

สิ่งที่กฎหมายหรือมาตรฐานเรียกร้อง เขียนโดยนักกฎหมาย regulator หรือ auditor

"เฉพาะคนที่ได้รับอนุญาตเท่านั้นที่เปลี่ยน production ได้"

กลไกที่เราสร้างเพื่อให้ requirement เป็นจริงทุกครั้ง ไม่ใช่เฉพาะตอนที่ใครนึกได้

PR approval + protected branch + deploy role ใน CI

บันทึกที่ auditor อ่านได้ในอีก 1 ปีข้างหน้าโดยไม่ต้องถามเรา

Git history, approval record, pipeline run, CloudTrail

ทำไม DevOps ถึงเป็นเจ้าของเรื่องนี้

Pipeline รู้อยู่แล้วว่าใครเปลี่ยนอะไร ใครรีวิว test อะไรรัน artifact ไหนขึ้น และเมื่อไหร่
หลักฐานที่ทำมือช้าและปลอมง่าย หลักฐานอัตโนมัติเร็วกว่าและ auditor เชื่อถือมากกว่า
Security lead เป็นเจ้าของ "ต้องมี control อะไร" DevOps เป็นเจ้าของ "ทำให้ control นั้นเกิดขึ้นเองและมีหลักฐาน"

คำถามที่ auditor ถามจริง

ไม่ถาม "คุณปลอดภัยไหม" แต่ถาม "แสดงหลักฐานว่า control นี้ทำงานเมื่อวันที่ X"
ไม่ถาม "มีนโยบายไหม" แต่ถาม "นโยบายนี้บังคับด้วยอะไร และมีกรณีที่มันถูกข้ามไหม"
Control ที่ไม่ทิ้งหลักฐาน ในสายตา auditor เท่ากับไม่มี control

ที่มา: แนวปฏิบัติการสอบ SOC 2 Type II และ ISO 2700117

ส่วนที่ 2 · HIPAA · กฎหมาย · สหรัฐ 1996

HIPAA ถามว่าใครเข้าถึงข้อมูลสุขภาพและพิสูจน์ได้อย่างไร: control 4 อย่างใน pipeline และ cloud ตอบได้ครบ

ทำไมถึงมี

ปี 1996 ประกันสุขภาพเริ่มส่ง claim อิเล็กทรอนิกส์ ข้อมูลผู้ป่วยไหลระหว่างหลายบริษัท การวินิจฉัยที่หลุดทำให้คนเสียงานหรือเสียประกัน ครอบคลุม PHI ทุกชนิด และบังคับกับ business associate (SaaS, cloud) ด้วย

อย่างน้อยต้องทำ

Risk analysis เป็นลายลักษณ์อักษร ทำซ้ำสม่ำเสมอ
User ID ไม่ซ้ำ least privilege logout อัตโนมัติ
Audit control: log ว่าใครเข้าถึง PHI เก็บ 6 ปี
เข้ารหัสตอนส่งและตอนเก็บ
Business Associate Agreement กับทุก vendor รวม AWS
แจ้งผู้เสียหายภายใน 60 วันเมื่อเกิด breach

ถ้าไม่ทำ: ค่าปรับต่อการละเมิดตามระดับความประมาท เพดานต่อปีเกิน 2 ล้านดอลลาร์ต่อประเภท; จำคุกถึง 10 ปีกรณีขาย PHI; Anthem ยอมความ 16 ล้านดอลลาร์ปี 2018 หลังข้อมูล 79 ล้านรายการรั่ว

Requirement, Control, Evidence

Requirement	Control	Evidence
เข้าถึง PHI เฉพาะผู้ได้รับอนุญาต	SSO + MFA, IAM ตาม role, default read-only, ขอสิทธิ์เพิ่มแบบมีเวลาจำกัดและถอนอัตโนมัติ	ticket ขอสิทธิ์, IAM policy ใน Git, session log
Audit control	Log บันทึก user ID, record ID, action ไม่บันทึกตัว PHI ส่งไป account ที่ล็อก เก็บ 6 ปี	log schema, retention policy, CloudTrail
การเข้ารหัส	KMS บน RDS, S3, EBS; TLS ที่ load balancer; Terraform module ปฏิเสธ resource ที่ไม่เข้ารหัส	terraform plan, AWS Config, KMS policy
PHI ห้ามอยู่ใน telemetry	Structured logging แบบ allowlist field; scrubber ใน log pipeline; non-prod ใช้ข้อมูล de-identified (stage 6)	scanner alert, สุ่มตรวจ log, masking job

ที่มา: HHS, HIPAA Security Rule 45 CFR Part 164; HHS OCR resolution agreement with Anthem (2018)18

ส่วนที่ 2 · GDPR · กฎหมาย · EU 2018

ค่าปรับ GDPR สูงสุด 5 อันดับล้วนเกี่ยวกับการโอนและใช้ข้อมูลเกินวัตถุประสงค์ ไม่ใช่การถูก hack: control จึงต้องอยู่ที่ data flow ไม่ใช่แค่ firewall

ค่าปรับ GDPR สูงสุด (ล้านยูโร)

เพดานโทษ: 20 ล้านยูโร หรือ 4% ของรายได้ทั่วโลกต่อปี แล้วแต่อะไรสูงกว่า และคำสั่งหยุดประมวลผลซึ่งเท่ากับปิดผลิตภัณฑ์

อย่างน้อยต้องทำ

ฐานทางกฎหมายต่อวัตถุประสงค์ เก็บเฉพาะที่จำเป็น
บันทึกรายการประมวลผล; DPA กับ processor; เปิดเผย sub-processor
ตอบสิทธิ์เข้าถึง แก้ไข ลบ โอนย้าย ใน 30 วัน
แจ้งหน่วยงานกำกับใน 72 ชั่วโมงเมื่อเกิด breach

Requirement, Control, Evidence

Requirement	Control	Evidence
จำกัดระยะเวลาเก็บ	Retention เป็น scheduled job ต่อประเภทข้อมูล รวม backup	job history, config ใน Git
สิทธิ์ขอลบ	API ลบเดียวกระจายทุกที่เก็บ รวม search, cache, analytics, third party	log คำขอลบพร้อมเวลาเสร็จ
Data residency	ข้อมูล EU ตรึง region EU; Terraform block region อื่น	terraform plan, AWS Config
Minimization ใน non-prod	Clone จาก prod ถูก pseudonymize ก่อนให้ engineer ใช้	masking job log, scanner report

ที่มา: CMS.Law GDPR Enforcement Tracker; Irish Data Protection Commission; CNPD Luxembourg ตัวเลขปัดเป็นล้านยูโร บางกรณีอยู่ระหว่างอุทธรณ์19

ส่วนที่ 2 · PDPA · กฎหมาย · ไทย 2562

PDPA ใช้ control ชุดเดียวกับ GDPR แต่มีโทษอาญาถึงตัวผู้บริหาร และค่าปรับครั้งแรกในปี 2567 เกิดจากสิ่งพื้นฐาน: ไม่มี DPO และมาตรการรักษาความปลอดภัยไม่พอ

ทำไมถึงมี

ร่างตามแบบ GDPR เพื่อให้บริษัทไทยยังทำธุรกิจกับ EU ได้ ก่อนปี 2565 ข้อมูลส่วนบุคคลในไทยถูกขายและรั่วโดยไม่มีผลทางกฎหมาย บังคับกับทุกองค์กรในไทยและบริษัทต่างชาติที่ให้บริการคนในไทย

โทษ 3 ชั้น

ปกครอง	ปรับสูงสุด 5 ล้านบาทต่อการละเมิด
อาญา	จำคุกสูงสุด 1 ปี และ/หรือปรับ 1 ล้านบาท กรรมการถูกดำเนินคดีได้
แพ่ง	ค่าเสียหายเชิงลงโทษสูงสุด 2 เท่าของความเสียหายจริง

ค่าปรับครั้งแรก ปี 2567: รวม 7 ล้านบาท กับผู้ค้าออนไลน์รายหนึ่งหลังข้อมูลรั่ว จากการไม่แต่งตั้ง DPO ไม่มีมาตรการรักษาความปลอดภัยที่เพียงพอ และไม่แจ้งเหตุตามกำหนด

อย่างน้อยต้องทำ

ความยินยอมหรือฐานทางกฎหมายอื่นก่อนเก็บ วัตถุประสงค์ชัดเจนเป็นภาษาไทย
Privacy notice, บันทึกรายการประมวลผล, DPO ถ้าประมวลผลขนาดใหญ่
มาตรการรักษาความปลอดภัย "ที่เหมาะสมกับความเสี่ยง"
แจ้ง สคส. ภายใน 72 ชั่วโมงเมื่อเกิด breach
โอนข้อมูลออกนอกประเทศเฉพาะที่มีมาตรฐานเพียงพอหรือมีมาตรการรองรับ

Requirement, Control, Evidence

Requirement	Control	Evidence
ติดตามความยินยอม	Consent เป็น record ที่มี version คู่กับ user; service ตรวจก่อนประมวลผล	ตาราง consent + policy version
แจ้ง breach ใน 72 ชม.	Alert เมื่อ export ผิดปกติหรือ auth fail พุ่ง; runbook ระบุผู้แจ้ง สคส.	alert history, runbook, incident timeline
ความปลอดภัยที่เหมาะสม	Baseline เดียวกับ GDPR: MFA, least privilege, encryption, central log, patch (stage 4, 5)	CI scan report, IAM ใน Git
โอนข้ามประเทศ	ทะเบียน SaaS ที่รับข้อมูลคนไทย; ตรวจสัญญาก่อน integration ใหม่	vendor register, DPA ต่อ vendor

ที่มา: พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562 มาตรา 77 ถึง 90; ประกาศคณะกรรมการคุ้มครองข้อมูลส่วนบุคคล; ข่าวสารสำนักงาน สคส. 256720

ส่วนที่ 2 · PCI DSS · สัญญา · v4.0.1 2025

PCI DSS มี 12 ข้อกำหนด แต่ tokenization ผ่านผู้ให้บริการชำระเงินทำให้ภาระส่วนใหญ่ตกที่ผู้ให้บริการ: ลด scope ก่อน แล้วค่อยล็อกสิ่งที่เหลือ

ทำไมถึงมี

ปี 2004 เครือข่ายบัตรแต่ละรายมีกฎของตัวเอง ร้านค้าถูกเจาะตลอดและต้นทุนการฉ้อโกงตกที่ธนาคาร จึงรวมเป็นมาตรฐานเดียว บังคับผ่านสัญญากับธนาคารผู้รับบัตร ไม่ใช่กฎหมาย แต่สัญญารับบัตรทุกฉบับบังคับ

ถ้าไม่ทำ

ค่าปรับผ่านธนาคาร 5,000 ถึง 100,000 ดอลลาร์ต่อเดือนจนกว่าจะแก้
ค่าธรรมเนียมต่อธุรกรรมสูงขึ้น แล้วถูกตัดสิทธิ์รับบัตร
หลัง breach: ค่า forensic, ค่าออกบัตรใหม่, รับผิดต่อการฉ้อโกง

200+ ล้านดอลลาร์ค่ายอมความและค่าใช้จ่ายของ Target หลังบัตร 40 ล้านใบรั่วปี 2013 ผ่าน credential ของผู้รับเหมาระบบปรับอากาศ

12 ข้อกำหนด และใครรับภาระเมื่อ tokenize (SAQ A)

กลุ่ม	ข้อกำหนด	ผู้รับภาระหลัก
เครือข่าย	1 firewall/segmentation, 2 ไม่ใช้ default password	ผู้ให้บริการชำระเงิน + เรา (segmentation)
ข้อมูลบัตร	3 เข้ารหัสที่เก็บ ห้ามเก็บ CVV, 4 TLS ตอนส่ง	ผู้ให้บริการชำระเงิน
ระบบ	5 anti-malware, 6 secure development และ patch	เรา (stage 4, 5)
การเข้าถึง	7 least privilege, 8 MFA, 9 กายภาพ	เรา + cloud provider
ตรวจสอบ	10 log 12 เดือน, 11 ASV scan รายไตรมาส + pen test รายปี	เรา
นโยบาย	12 นโยบายและการอบรม	เรา

Control ใน DevOps: เลขบัตรไม่เคยถึง server ของเรา (Stripe, Omise, Adyen); payment service อยู่ใน namespace ของตัวเองพร้อม network policy deny by default; log bucket แก้ไขไม่ได้ retention 12 เดือน; ASV scan และ pen test อยู่ในปฏิทินพร้อมเจ้าของ

ที่มา: PCI Security Standards Council, PCI DSS v4.0.1 (2024); SAQ A eligibility criteria; รายงานสาธารณะกรณี Target (2013)21

ส่วนที่ 2 · SOC 2 · การรับรอง · AICPA

SOC 2 ไม่มีค่าปรับ แต่การไม่มีรายงาน Type II หมายถึงดีลองค์กรใหญ่หยุดที่ฝ่ายจัดซื้อ และรายงานที่มี exception แย่กว่าไม่มีรายงาน

ทำไมถึงมี

บริษัทย้ายข้อมูลไปอยู่กับ SaaS vendor ลูกค้าทุกรายส่งแบบสอบถาม 300 ข้อให้ vendor ทุกราย SOC 2 แทนที่สิ่งนั้นด้วยรายงานที่ผ่านการสอบทานฉบับเดียว แชร์ภายใต้ NDA

Type I กับ Type II

Type I	Control ถูกออกแบบไว้ ณ จุดเวลาหนึ่ง ใช้เป็นก้าวแรก
Type II	Control ทำงานจริงตลอด 6 ถึง 12 เดือน ลูกค้าต้องการแบบนี้

Trust Services Criteria 5 ด้าน

Security (บังคับทุกราย) และเลือกเพิ่ม Availability, Processing Integrity, Confidentiality, Privacy

ถ้าไม่ทำ: ไม่มี regulator ปรับ ไม่มีอะไรเกิดขึ้น จนกระทั่งทีมจัดซื้อของลูกค้าขอดูรายงาน โดยทั่วไปเสียเวลาขาย 3 ถึง 6 เดือน หรือเสียดีล

Requirement, Control, Evidence

Requirement	Control	Evidence
Change management	ทุก change ผ่าน MR ที่ต้องรีวิว, CI ตรวจ, deploy โดย identity ของ pipeline ไม่มี deploy มือ (stage 8)	branch protection, MR + approval, deploy log
Logical access	SSO ทุกระบบ; joiner/leaver ผ่าน identity provider; ทบทวนรายไตรมาสด้วย script ที่ list ทุกคนที่มีสิทธิ์ prod	IdP audit log, export การทบทวนที่ลงนาม
Availability	Backup ทดสอบ restore อัตโนมัติเข้า environment ชั่วคราวทุกเดือน; uptime monitor จากภายนอก	restore job log, status page history
Incident response	Postmortem template; action item เป็น ticket ที่ link incident และปิดก่อนปิด PIR	incident ticket, PIR, action ที่ปิดแล้ว
Vendor management	ทะเบียน vendor พร้อม SOC 2 หรือ ISO ของ vendor นั้น ทบทวนรายปี	vendor register, review ticket

Pipeline ในส่วนที่ 1 สร้างหลักฐานให้ 2 จาก 5 แถวโดยอัตโนมัติ (change management, incident response ผ่าน deploy log และ post-deploy)

ที่มา: AICPA, Trust Services Criteria (2017, revised 2022); แนวปฏิบัติของผู้สอบ SOC 222

ส่วนที่ 2 · ISO 27001 · การรับรอง · ฉบับ 2022

ISO 27001 รับรองกระบวนการ ไม่ใช่เทคโนโลยี: ความล้มเหลวที่พบบ่อยที่สุดคือ control เขียนไว้ในนโยบายแต่ไม่มีหลักฐานว่าเคยทำงาน

ทำไมถึงมี

ผู้ซื้อทั่วโลก โดยเฉพาะภาครัฐและองค์กรใหญ่นอกสหรัฐ ต้องการใบรับรองเดียวที่ใช้ได้ข้ามประเทศ รับรองระบบบริหารจัดการ (ISMS) แนวคิดคือ security เป็นกระบวนการที่ทำซ้ำ ไม่ใช่ snapshot

Annex A 2022: 93 control ใน 4 กลุ่ม

กลุ่ม Technological 34 ข้อคือส่วนที่ DevOps เป็นเจ้าของโดยตรง

อย่างน้อยต้องทำ

Scope, คำมั่นของผู้บริหาร, วิธีประเมินความเสี่ยง, risk register
Statement of Applicability เลือก control จาก Annex A พร้อมเหตุผล
Internal audit และ management review ทุกปี
สอบรับรอง แล้วสอบติดตามทุกปี สอบใหม่ทั้งหมดทุก 3 ปี

Requirement, Control, Evidence

Requirement	Control	Evidence
ทะเบียน asset	ทุกอย่างใน Terraform ทะเบียนสร้างจาก state ตรวจ drift ทุกคืน	state export, drift report
Vulnerability management	Scan ใน CI และตามตาราง (stage 4, 5); SLA แก้ตาม severity; exception มีเจ้าของและวันหมดอายุ	findings dashboard, exception register
Supplier security	SaaS หรือ library ใหม่ผ่าน review ก่อน integration แรก merge	vendor register, review ticket
ปรับปรุงต่อเนื่อง	Incident action, audit finding, risk item อยู่ใน tracker เดียวกัน มีเจ้าของและกำหนดเสร็จ	รายการที่ปิดต่อไตรมาส, minutes

ถ้าไม่ทำ: ไม่มีค่าปรับ แต่ถูกระงับใบรับรองเมื่อพบ major nonconformity ตัดสิทธิ์ tender ที่ระบุ ISO 27001 และใบรับรองที่หมดอายุเป็นข้อมูลสาธารณะ

ที่มา: ISO/IEC 27001:2022 Annex A; ISO/IEC 27002:202223

ส่วนที่ 2 · อย่างไร

Control 8 อย่างครอบคลุมกฎทั้ง 6 ฉบับเกือบทั้งหมด และ pipeline ในส่วนที่ 1 สร้างหลักฐานให้แล้ว 5 อย่าง: สร้างครั้งเดียว แล้ว map ไปแต่ละกฎ

จำนวนกฎ (จาก 6) ที่แต่ละ control ตอบโดยตรง

Pipeline สร้างหลักฐานให้ต้องสร้างนอก pipeline

สิ่งที่ต่างกันจริง ๆ ระหว่างกฎ

เรื่อง	ความต่าง
นาฬิกาแจ้งเหตุ	HIPAA 60 วัน; GDPR และ PDPA 72 ชั่วโมง
สัญญากับ vendor	HIPAA เรียก BAA; GDPR และ PDPA เรียก DPA
Retention log	HIPAA 6 ปี; PCI DSS 12 เดือน
Retention และการลบข้อมูล	SOC 2 บังคับเฉพาะเมื่อเลือก Privacy

Control ที่เหลือ 3 อย่างนอก pipeline (identity, encryption, backup) เป็นงานของ IaC และ cloud configuration ซึ่ง Terraform ใน Git ให้หลักฐานแบบเดียวกับ pipeline

ที่มา: สังเคราะห์จากข้อกำหนดของกฎทั้ง 6 ฉบับในสไลด์ 18 ถึง 23 "ทางอ้อม" หมายถึงกฎเรียกร้อง "มาตรการที่เหมาะสม" โดยไม่ระบุ control นี้เป็นชื่อ24

ส่วนที่ 2 · กรณีศึกษา

องค์กรพบ breach ด้วยตัวเองเพียง 42%: กรณีไฟล์ประกันที่ "สำเร็จ" 4 คืนโดยไม่ถึงปลายทางแสดงว่าการตรวจว่า job รัน ไม่เท่ากับการตรวจว่าผลลัพธ์เกิดขึ้น

ใครเป็นผู้พบ breach ปี 2024 (สัดส่วนของกรณีทั้งหมด)

Breach ที่ผู้โจมตีเปิดเผยเองมีต้นทุนสูงกว่าที่ทีมภายในพบเฉลี่ยราว 1 ล้านดอลลาร์

ล้มเหลว 2 อย่าง อย่างที่สองคือของจริง

1 Credential ของ SFTP หมดอายุ ไม่มีใครเป็นเจ้าของวันต่ออายุ
2 Control มองไม่เห็น monitoring ตรวจว่า job รัน ไม่ได้ตรวจว่าบริษัทประกันได้รับไฟล์

ลำดับเหตุการณ์

วัน 0, 02:00Credential หมดอายุ upload ล้มเหลว error 1 บรรทัดใน log job รายงาน "สำเร็จ"

วัน 1 ถึง 3เหตุการณ์เดิมทุกคืน ไม่มี metric เปลี่ยน ไม่มี alert ไม่มีใครเปิด log

วัน 4, 10:30ลูกค้าแจ้ง account team ว่าข้อมูล enrollment ไม่ถึง

วัน 4, 11:20เปิด log พบสาเหตุใน 1 ชั่วโมง เปลี่ยน credential ส่งไฟล์ย้อนหลัง 4 ชุด

สัปดาห์เดียวกันUpload error ทำให้ job fail; alert เมื่อไฟล์หรือ ack ไม่มา; expiry check ทุก credential

สิ่งที่เปลี่ยนในระดับระบบ

Outcome monitoring	Alert เมื่อ "ไฟล์ที่คาดว่าจะส่ง 02:00 และ ack ที่คาดว่าจะได้ 03:00" ไม่มาทั้งคู่ ไม่ต้องแก้ code ใน job
Credential lifecycle	ทะเบียน credential และ certificate ภายนอกทั้งหมด เตือนที่ 30 และ 7 วัน มีเจ้าของ
Ownership	ทุก integration มีเจ้าของและ runbook; ตรวจ scheduled transfer อื่นทุกตัวว่ามีช่องโหว่แบบเดียวกันไหม

วัดผลว่าสำเร็จ: ครั้งหน้าที่ไฟล์ไม่ถึง alert ของเราต้องพบในคืนนั้น ก่อนลูกค้าคนใด

ที่มา: IBM Cost of a Data Breach Report 2024; กรณีศึกษาจากแบบฝึกหัด incident review ของผู้บรรยาย รายละเอียดเวลาและระบบถูกปรับเพื่อการสอน25

สรุปและแบบฝึกหัด

สิ่งที่ต้องจำ 4 ข้อ และแบบฝึกหัด 30 นาที: เลือก 1 ระบบ ระบุกฎ แล้วออกแบบ control 5 อย่างพร้อมหลักฐานที่แต่ละอย่างทิ้งไว้

สิ่งที่ต้องจำ

Requirement, Control, Evidence ทุกครั้ง

Control ที่ไม่ทิ้งหลักฐาน ในสายตา auditor เท่ากับไม่มี

ข้อมูลเป็นตัวกำหนดกฎ

ถามก่อนว่าระบบถือข้อมูลอะไรของใคร แล้วกฎจะตามมาเอง

Build ครั้งเดียว ตรวจก่อน merge เลื่อน artifact เดิมขึ้น prod

ต้นทุนข้อผิดพลาดหลัง release สูงกว่า 100 เท่า

ทำ control ให้อัตโนมัติ อย่าถอดออก

Requirement อาจต่อรองไม่ได้ แต่ implementation ต่อรองได้เสมอ

แบบฝึกหัด กลุ่มละ 3 คน

ระบบ	โจทย์
A	แอปจองคิวคลินิกในกรุงเทพ ผู้ป่วย upload ผลแล็บ บริษัทแม่ในสหรัฐเป็นคนตรวจผล
B	ร้านค้าออนไลน์ขายให้ลูกค้าไทยและ EU รับบัตรผ่านผู้ให้บริการชำระเงิน เก็บประวัติคำสั่งซื้อ
C	B2B HR SaaS ขายให้องค์กรใหญ่ เก็บข้อมูลพนักงาน ลูกค้าขอรายงาน security ก่อนเซ็นสัญญา

สิ่งที่ต้องส่ง

กฎที่เกี่ยว	Requirement	Control (ระบุ stage)	Evidence
…	…	…	…
…	…	…	…
…	…	…	…

แหล่งต้นทาง: docs.gitlab.com/ee/ci; hhs.gov/hipaa; gdpr-info.eu; pdpc.or.th; pcisecuritystandards.org; aicpa-cima.com; iso.org26

ภาคผนวก

แหล่งข้อมูลที่ใช้ในเอกสารนี้

สไลด์	ข้อมูล	แหล่งที่มา	หมายเหตุ
4	ต้นทุนแก้ข้อผิดพลาด 1 / 6.5 / 15 / 100	IBM Systems Sciences Institute อ้างอิงใน Dawson et al. และตำรา software engineering ทั่วไป	ค่าประมาณ ต้นฉบับไม่เผยแพร่สาธารณะ ใช้เพื่อแสดงลำดับขนาด
5	DORA elite vs low	Google Cloud, Accelerate State of DevOps Report 2023	ค่าของกลุ่ม elite และ low ในปีนั้น
8	96% / 84% / 74%	Synopsys, Open Source Security and Risk Analysis 2024	1,067 codebase ที่ audit ปี 2023
9, 11, 21	SolarWinds, Knight Capital, Target	รายงานสาธารณะ; SEC order 2013; คดีความและรายงานข่าว	ตัวเลข Target รวมค่ายอมความหลายรายการและค่าใช้จ่ายที่บริษัทรายงาน
15, 25	ต้นทุน breach ตามอุตสาหกรรม, 258 วัน, ผู้พบ breach, 2.2 ล้านดอลลาร์	IBM Security และ Ponemon Institute, Cost of a Data Breach Report 2024	604 องค์กร 16 ประเทศ
16, 18	โทษ HIPAA, Anthem	45 CFR 160.404; HHS OCR resolution agreements	เพดานค่าปรับปรับตามเงินเฟ้อทุกปี
19	ค่าปรับ GDPR	CMS.Law GDPR Enforcement Tracker; DPC Ireland; CNPD Luxembourg	บางกรณีอยู่ระหว่างอุทธรณ์ ตัวเลขปัดเป็นล้านยูโร
20	โทษ PDPA, ค่าปรับครั้งแรก	พ.ร.บ.คุ้มครองข้อมูลส่วนบุคคล พ.ศ. 2562; สำนักงาน สคส.	ตรวจสอบรายละเอียดคดีกับประกาศของ สคส. ก่อนอ้างอิง
21	PCI DSS 12 ข้อกำหนด, SAQ A	PCI SSC, PCI DSS v4.0.1 และ SAQ A	ค่าปรับต่อเดือนเป็นช่วงที่รายงานโดย acquirer ไม่ใช่ตัวเลขทางการของ PCI SSC
23	Annex A 93 control	ISO/IEC 27001:2022	Organizational 37, People 8, Physical 14, Technological 34

ตัวเลขทั้งหมดอ้างอิงถึงกลางปี 2026 ตรวจกับแหล่งต้นทางก่อนนำไปใช้ในเอกสารทางการ27