บทที่ 1: Secure Software Concepts

บทนี้สร้างภาษากลางสำหรับวิเคราะห์ความมั่นคงปลอดภัยของซอฟต์แวร์ โดยเริ่มจาก security properties ที่ระบบต้องรักษา แล้วเชื่อมไปยัง identity, evidence, governance และ design principles ที่ใช้ตัดสินใจเมื่อข้อจำกัดขัดกัน เป้าหมายไม่ใช่ การท่องคำจำกัดความ แต่เป็นการเลือกหลักการและ control ที่เหมาะกับ asset, threat และบริบททางธุรกิจ

[!IMPORTANT] เนื้อหาและข้อฝึกในบทนี้จัดทำขึ้นเพื่อการศึกษา ไม่ใช่ official ISC2 material, ไม่ได้รับการรับรองจาก ISC2 และไม่ใช่ข้อสอบจริงหรือ exam dump

ขอบเขตของ Domain นี้อยู่ที่แนวคิดและเหตุผลเชิง design รายละเอียดการบริหาร กิจกรรมตลอด Software Development Life Cycle (SDLC) อยู่ใน บทที่ 2 การทำ requirements, architecture, code และ test อยู่ในบทที่ 3–6 ตามลำดับ

วัตถุประสงค์การเรียนรู้และ exam outline mapping

เมื่ออ่านบทนี้จบ คุณต้องแยกความหมายของ security properties ออกจากกลไกที่ใช้ บรรลุ properties เหล่านั้น และให้เหตุผลได้ว่า design principle ใดลด risk ชนิดใด ตารางนี้ map เนื้อหากับ objective 1.1 และ 1.2 ที่บันทึกไว้ใน master outline

Objective	หัวข้อสอบที่ครอบคลุม	สิ่งที่คุณต้องทำได้
1.1 Understand core concepts	Confidentiality	ระบุผู้รับข้อมูลที่ได้รับอนุญาตและป้องกันการเปิดเผยโดยไม่ได้รับอนุญาต
1.1 Understand core concepts	Integrity	แยก data integrity, system integrity และหลักฐานการเปลี่ยนแปลงที่ตรวจสอบได้
1.1 Understand core concepts	Availability	วิเคราะห์ความพร้อมใช้ร่วมกับ capacity, dependency, recovery และ security policy
1.1 Understand core concepts	Authentication	อธิบายการพิสูจน์ claim ของ subject, service หรือ artifact และข้อจำกัดของ assurance
1.1 Understand core concepts	Authorization	อธิบาย policy decision และ enforcement หลัง authentication โดยใช้ least privilege
1.1 Understand core concepts	Accountability	เชื่อม action กับ actor ผ่าน identity, audit trail, time และการคุ้มครอง log
1.1 Understand core concepts	Nonrepudiation	ระบุหลักฐานที่ช่วยโต้แย้งการปฏิเสธการกระทำ โดยไม่สับสนกับ authentication
1.1 Understand core concepts	Governance, Risk, and Compliance (GRC)	แยกทิศทางและอำนาจตัดสินใจ การจัดการความไม่แน่นอน และหลักฐานการปฏิบัติตามข้อผูกพัน
1.2 Understand security design principles	Least privilege	จำกัดสิทธิ์ตามงาน ขอบเขต และเวลา
1.2 Understand security design principles	Segregation of duties	แบ่งอำนาจที่ขัดกันเพื่อไม่ให้คนหรือ component เดียวทำธุรกรรมสำคัญครบวงจร
1.2 Understand security design principles	Defense in depth	วาง controls หลายชั้นที่ไม่พังด้วยสาเหตุเดียวกัน
1.2 Understand security design principles	Resiliency	รักษาหรือกู้คืนบริการที่จำเป็นเมื่อถูกโจมตีหรือส่วนประกอบล้มเหลว
1.2 Understand security design principles	Economy of mechanism	ลดความซับซ้อนของ security mechanism ให้ตรวจสอบและใช้งานได้อย่างถูกต้อง
1.2 Understand security design principles	Complete mediation	ตรวจทุก access ที่เกี่ยวข้องกับ protected resource ณ จุดบังคับ policy ที่เชื่อถือได้
1.2 Understand security design principles	Open design	วาง security บน secret ที่จัดการได้ เช่น key ไม่ใช่การปิดบัง design หรือ algorithm
1.2 Understand security design principles	Least common mechanism	ลดกลไกและ state ที่ผู้ใช้หรือ trust domain หลายกลุ่มต้องใช้ร่วมกัน
1.2 Understand security design principles	Psychological acceptability	ทำให้เส้นทางที่ปลอดภัยเข้าใจง่ายและเหมาะกับงาน เพื่อลดการหลบเลี่ยง control
1.2 Understand security design principles	Component reuse	ใช้ component ที่เหมาะสมและผ่านการประเมิน พร้อมจัดการ provenance, configuration และ lifecycle risk

การอ่านแบบเชื่อมโยงสำคัญกว่าการจำทีละแถว ตัวอย่างเช่น authentication ที่แข็งแรง ไม่ช่วย confidentiality หาก authorization อนุญาตกว้างเกินไป และ audit log ที่ดี ไม่สร้าง accountability หากทุก service ใช้ shared identity เดียวกัน

แนวคิดหลัก

Security เป็นคุณสมบัติของระบบในบริบทหนึ่ง ไม่ใช่ชื่อผลิตภัณฑ์หรือสถานะที่ได้มา ครั้งเดียว คุณจึงต้องเริ่มจาก asset และวัตถุประสงค์ ระบุสิ่งที่อาจผิดพลาด แล้วเลือก controls ที่ลด risk ได้โดยไม่ทำลายภารกิจหลักของระบบ

Asset, threat, vulnerability, risk และ control

คำห้าคำนี้สร้างโซ่เหตุผลพื้นฐาน Asset คือสิ่งที่มีคุณค่าต่อองค์กรหรือผู้มีส่วนได้เสีย Threat คือสาเหตุหรือเหตุการณ์ที่อาจใช้หรือกระตุ้น weakness ส่วน vulnerability คือ weakness ที่อาจถูก exploit หรือทำให้ control ล้มเหลว เมื่อพิจารณาความไม่แน่นอน ของเหตุการณ์และผลกระทบต่อวัตถุประสงค์ เราเรียกผลนั้นว่า risk และใช้ control เพื่อ ปรับเปลี่ยน risk

ตัวอย่างเช่น ฐานข้อมูลเงินเดือนเป็น asset ผู้โจมตีภายในเป็น threat การที่บัญชี รายงานผลมีสิทธิ์แก้ไขข้อมูลเป็น vulnerability ความเสี่ยงคือการแก้เงินเดือนโดยไม่ ได้รับอนุญาตซึ่งอาจสร้างความเสียหายทางการเงินและความเชื่อมั่น การแยกสิทธิ์อ่านกับ สิทธิ์เขียน การอนุมัติสองคน และ immutable audit trail เป็น controls คนละชนิด

แผนภาพนี้เน้นว่า vulnerability ไม่เท่ากับ risk โดยอัตโนมัติ และ control ไม่ทำให้ risk หายไปทั้งหมด การตัดสินใจต้องพิจารณา residual risk หลังใช้ controls แล้ว รวมถึงผู้มีอำนาจยอมรับผลที่เหลือ ไม่ใช่ให้ developer ตัดสินใจแทนเจ้าของ risk

Confidentiality

การรักษาความลับ (confidentiality) หมายถึงการป้องกันการเปิดเผยข้อมูลแก่ subject ที่ไม่ได้รับอนุญาต Subject อาจเป็นบุคคล service, process, device หรือองค์กร และการเปิดเผยอาจเกิดผ่าน response, log, cache, backup, metadata, timing หรือ ข้อความ error ไม่ใช่เฉพาะการอ่านฐานข้อมูลโดยตรง

การออกแบบ confidentiality ต้องตอบคำถามอย่างน้อยสี่ข้อ ได้แก่ ข้อมูลใดมีความไว ใครมีสิทธิ์รับข้อมูล ภายใต้ purpose และเงื่อนไขใด และข้อมูลเคลื่อนผ่านหรือพักอยู่ ที่ใด Controls ที่พบบ่อยมี access control, encryption, tokenization, data minimization, masking และ isolation แต่แต่ละ control แก้คนละปัญหา Encryption at rest ลดผลจากการสูญหายของ storage media แต่ไม่หยุด application ที่ถูกยึด และมี key ใช้งานอยู่แล้วจากการอ่าน plaintext

Confidentiality ยังมี trade-off กับ availability และ usability ตัวอย่างเช่น การบังคับ re-authentication บ่อยเกิน risk อาจทำให้ผู้ใช้หาทางเก็บ session หรือ credential อย่างไม่ปลอดภัย หลัก psychological acceptability จึงช่วยให้ control ใช้งานได้จริงโดยไม่ลด policy ที่จำเป็น

Integrity

ความถูกต้องครบถ้วน (integrity) หมายถึงการป้องกันการสร้าง เปลี่ยน ลบ หรือจัดลำดับ ข้อมูลและพฤติกรรมระบบโดยไม่ได้รับอนุญาต Integrity ไม่ได้แปลว่า “ข้อมูลเป็นจริง” เสมอไป หากผู้ใช้ที่ได้รับอนุญาตกรอกค่าผิด checksum ที่ถูกต้องเพียงยืนยันว่าค่าไม่ เปลี่ยนตามกลไกที่ตรวจ ไม่ได้ยืนยันความถูกต้องทางธุรกิจ

มอง integrity อย่างน้อยสามระดับได้ดังนี้

• Data integrity: ค่าและความสัมพันธ์ของข้อมูลเปลี่ยนตาม rule ที่กำหนด เช่น ยอดรวมต้องเท่ากับผลรวมรายการและ state transition ต้องถูกลำดับ
• System integrity: code, configuration และ execution environment ทำงานตาม intended state โดยไม่มี component ที่ถูกแก้ไขหรือคำสั่งที่ไม่ได้รับอนุญาต
• Process integrity: ขั้นตอนสำคัญเกิดตาม workflow และ authorization ที่กำหนด เช่น ผู้สร้าง vendor ไม่สามารถอนุมัติการจ่ายเงินให้ vendor เดียวกัน

Hash ช่วยตรวจการเปลี่ยนแปลงเมื่อค่า hash ที่คาดหวังได้รับการป้องกัน Message Authentication Code (MAC) ช่วยตรวจ integrity และแหล่งที่มาระหว่างผู้ถือ shared secret แต่ไม่เหมาะเป็นหลักฐาน nonrepudiation ระหว่างผู้ถือ key เหล่านั้น เพราะ ทุกฝ่ายสร้าง MAC เดียวกันได้ Digital signature ช่วยผูก artifact กับ private key แต่ assurance ยังขึ้นกับการปกป้อง key, identity proofing, certificate status, time evidence และ verification process

Availability

ความพร้อมใช้ (availability) หมายถึงการที่ผู้ได้รับอนุญาตเข้าถึงข้อมูลหรือบริการ ที่จำเป็นได้ภายในเงื่อนไขเวลาที่ภารกิจกำหนด Availability ไม่ใช่แค่ uptime ของ process หากระบบตอบ HTTP 200 แต่ข้อมูลล้าสมัยจนตัดสินใจไม่ได้ หรือ dependency สำคัญไม่ทำงาน ระบบอาจไม่พร้อมใช้ในเชิงธุรกิจ

การออกแบบ availability ต้องพิจารณา fault domain, capacity, rate limiting, graceful degradation, redundancy, failover, backup, recovery, dependency และ operational visibility Redundancy เพิ่มความทนทานได้ต่อเมื่อสำเนาไม่พังจาก common cause เดียวกัน เช่น configuration ที่ผิดถูก deploy ไปทุก region พร้อมกัน หรือ credential กลางถูกยึดแล้วเข้าถึงทุก replica ได้

Availability อาจขัดกับ fail secure ตัวอย่างเช่น identity provider ล่ม ระบบอาจ fail closed เพื่อป้องกัน unauthorized access หรือใช้ authorization decision ที่ cache ไว้ช่วงสั้นเพื่อรักษาบริการสำคัญ ทางเลือกที่เหมาะขึ้นกับ asset, freshness, revocation risk และผลจากการปฏิเสธบริการ จึงต้องกำหนด policy ก่อนเกิด incident

ความสัมพันธ์ของ CIA triad

Confidentiality, Integrity และ Availability หรือ CIA triad เป็น objectives ที่ ช่วยตั้งคำถาม ไม่ใช่ checklist ที่แยกจากกัน ระบบหนึ่งอาจต้องให้น้ำหนักต่างกันตาม ข้อมูล transaction และช่วงเวลา และ control เดียวอาจส่งผลบวกหรือลบหลาย objective

แผนภาพแสดงว่า CIA ต้องทำงานตลอดเส้นทาง ไม่ใช่เฉพาะ database Policy enforcement ช่วย confidentiality และ integrity ขณะที่ monitoring กับ recovery ช่วย availability แต่ key service และ audit system กลายเป็น dependencies ที่ต้อง ออกแบบ security และ resiliency ของตนเองด้วย

Authentication

การพิสูจน์ตัวตน (authentication) คือกระบวนการสร้าง assurance ว่า claim ของ subject เป็นจริงในระดับที่เหมาะกับ risk Claim อาจเป็น “ผู้ใช้คือบุคคลนี้,” “service นี้เป็น workload ที่ได้รับอนุญาต” หรือ “artifact นี้มาจาก build pipeline ที่ระบุ” Authentication จึงไม่จำกัดอยู่ที่หน้า login

Authentication factor มักจัดจากสิ่งที่ subject รู้ มี หรือเป็น รวมถึง signal ของ device และบริบทเพื่อประกอบ risk decision Multi-factor authentication มี คุณค่าเมื่อ factors เป็นอิสระพอสมควร การถาม password และ PIN ซึ่งเป็นสิ่งที่รู้ ทั้งคู่ไม่ได้ให้ความหลากหลายแบบ factor คนละประเภท นอกจากนี้การมีหลาย factor ไม่แก้ session theft, insecure recovery flow หรือ phishing-resistant gap โดย อัตโนมัติ

วงจร identity ที่ต้องคำนึงมี enrollment, credential issuance, storage, use, rotation, recovery, revocation และ termination Authentication แข็งแรงที่หน้า login แต่ recovery อ่อนทำให้ assurance ทั้งระบบต่ำลง เช่นเดียวกับ service identity ที่ใช้ credential อายุยาวร่วมกันหลาย workload ซึ่งทำให้ attribution และ revocation แย่ลง

Authorization

การอนุญาต (authorization) คือการตัดสินใจว่า authenticated subject ทำ action ใดกับ resource ใดได้ภายใต้เงื่อนไขใด Authentication ตอบว่า subject น่าจะเป็นใคร ส่วน authorization ตอบว่า subject นั้นทำอะไรได้ ความสำเร็จของขั้นแรกไม่ให้สิทธิ์ ในขั้นที่สองโดยอัตโนมัติ

องค์ประกอบของ authorization ที่มีประโยชน์ ได้แก่ subject, action, resource, context และ policy ตัวอย่าง context คือ tenant, time, device assurance, transaction amount หรือ purpose รูปแบบ policy ที่พบบ่อยมี Role-Based Access Control (RBAC), Attribute-Based Access Control (ABAC), discretionary และ mandatory models การเลือกรูปแบบต้องเหมาะกับความซับซ้อน การอธิบายผล และภาระ บริหาร policy

Authorization ต้องใช้ complete mediation และป้องกันทั้ง vertical privilege escalation เช่น user กลายเป็น admin และ horizontal privilege escalation เช่น ผู้ใช้คนหนึ่งอ่าน record ของผู้ใช้อีกคน API ที่ตรวจ role แต่ไม่ตรวจ ownership ของ object ยังมีช่องโหว่ แม้ authentication และ role assignment ถูกต้อง

Accountability

ความรับผิดชอบตรวจสอบย้อนกลับได้ (accountability) คือความสามารถในการเชื่อม action กับ actor และบริบทเพื่อให้ตรวจสอบและรับผิดชอบได้ Accountability ต้องพึ่ง identity ที่จำแนก actor ได้ authorization ที่กำหนดขอบเขต event record ที่ครบ time ที่ น่าเชื่อถือ และการป้องกัน audit trail จากการแก้ไขหรือลบ

Log ปริมาณมากไม่เท่ากับ accountability Event ต้องตอบคำถามที่จำเป็น เช่น ใครทำ อะไรกับ resource ใด เมื่อใด ผ่านช่องทางใด ผลเป็นอย่างไร และ policy decision ใด เกี่ยวข้อง โดยไม่บันทึก secret หรือ sensitive data เกินจำเป็น Shared account, missing correlation identifier, clock ที่ไม่สอดคล้อง และสิทธิ์ลบ log ของผู้ที่ ถูกตรวจล้วนลด attribution

Accountability เป็นทั้ง deterrent และ detective capability แต่ไม่ทดแทน preventive control การบันทึกว่าข้อมูลถูกขโมยไม่ได้ป้องกันการขโมย และ log ที่ไม่มี เจ้าของตรวจหรือไม่มี retention ที่เหมาะสมอาจไม่มีคุณค่าต่อการตอบสนอง incident

Nonrepudiation

การไม่อาจปฏิเสธการกระทำโดยไม่มีข้อโต้แย้งต่อหลักฐาน (nonrepudiation) คือการมี หลักฐานที่สนับสนุนการพิสูจน์ origin, submission, delivery หรือ approval จนฝ่ายที่ เกี่ยวข้องปฏิเสธได้ยากตาม assurance ที่ต้องการ Nonrepudiation ไม่ได้เกิดจาก authentication หรือ log เพียงอย่างเดียว และไม่มีเทคโนโลยีเดียวรับประกันข้อสรุป ทางกฎหมายในทุกเขตอำนาจ

หลักฐานที่แข็งแรงอาจประกอบด้วย digital signature, protected private key, verified identity binding, trusted time evidence, certificate status, immutable record, transaction content ที่ canonicalized และกระบวนการ custody หาก key ถูก แชร์หรือ operator ใช้ key แทนผู้อนุมัติ หลักฐานอาจพิสูจน์เพียงว่า key ถูกใช้ ไม่ได้ พิสูจน์ว่าบุคคลที่อ้างเป็นผู้กระทำจริง

แยกคำเหล่านี้ให้ชัด:

• Authentication สร้าง assurance ต่อ identity claim ณ จุดหนึ่ง
• Authorization ตัดสินว่าการกระทำได้รับอนุญาตหรือไม่
• Accountability ทำให้ติดตามการกระทำไปยัง actor และบริบทได้
• Nonrepudiation เสริมคุณภาพหลักฐานเพื่อโต้แย้งการปฏิเสธการกระทำ

Governance, Risk, and Compliance

Governance, Risk, and Compliance (GRC) เป็นสามมุมที่เชื่อมกันแต่ไม่ใช่สิ่งเดียว Governance กำหนดทิศทาง หลักการ อำนาจ บทบาท และการกำกับดูแล Risk management จัดการผลของความไม่แน่นอนต่อวัตถุประสงค์ ส่วน compliance แสดงว่าปฏิบัติตาม ข้อผูกพันที่เกี่ยวข้อง เช่น policy, contract, regulation หรือ standard ที่องค์กร เลือกใช้

ความสัมพันธ์ที่ถูกต้องเริ่มจากวัตถุประสงค์และ risk ไม่ใช่เริ่มจาก checklist เพียง อย่างเดียว Compliance เป็นข้อจำกัดขั้นต่ำในบางบริบท แต่ “compliant” ไม่ได้แปลว่า “secure” เพราะข้อกำหนดอาจไม่ครอบคลุม threat ใหม่ การตั้งค่าจริง หรือ asset เฉพาะ ของระบบ ในทางกลับกัน control ที่ลด risk ได้ดีแต่ไม่มี evidence อาจพิสูจน์การปฏิบัติ ตามข้อผูกพันไม่ได้

Governance ระบุว่าใครตัดสินใจและรับผิดชอบ เช่น ใครอนุมัติ policy ใครเป็น risk owner ใครให้ exception และ exception หมดอายุเมื่อใด ทีมพัฒนามีหน้าที่ให้ข้อมูล ทางเทคนิคและดำเนิน controls แต่ไม่ควรยอมรับ business risk ที่เกินอำนาจของตน

การจัดการ risk โดยทั่วไปมีทางเลือก reduce, avoid, transfer หรือ share และ accept การเลือกต้องบันทึก rationale, owner, residual risk, เงื่อนไข และวันทบทวน การซื้อ ประกันอาจ transfer ผลกระทบทางการเงินบางส่วน แต่ไม่โอนชื่อเสียง ภาระลูกค้า หรือ ความรับผิดชอบในการรักษาระบบทั้งหมด

หลักการออกแบบความมั่นคงปลอดภัย

Design principles เป็นเลนส์ตรวจ reasoning ไม่ใช่สูตรสำเร็จ หลักการหลายข้อมัก สนับสนุนกัน แต่บางครั้งเกิด trade-off เช่น การเพิ่ม defense layer ทำให้ mechanism ซับซ้อนขึ้น คุณต้องเลือก design ที่ลด risk โดยรวมและยังตรวจสอบได้

Least privilege

Least privilege คือการให้เฉพาะสิทธิ์ขั้นต่ำที่จำเป็นต่อหน้าที่ ในขอบเขตและระยะเวลา ที่จำเป็น คำว่า “ขั้นต่ำ” ต้องพิจารณาทั้ง action, resource, tenant, environment, time และ condition ไม่ใช่แค่ชื่อ role

การใช้ least privilege ที่มีประสิทธิผลประกอบด้วย default deny, permission ที่ ละเอียดพอเหมาะ, just-in-time elevation, separate administrative identity, short-lived credential, periodic review และ revocation เมื่อหน้าที่สิ้นสุด Service account ที่มีสิทธิ์ครอบคลุมทุก tenant เพราะ “แก้ปัญหาง่าย” ขยาย blast radius ของ credential theft อย่างมาก

Trade-off คือ permission ที่ละเอียดเกินไปสร้าง policy sprawl และ operational friction ทีมอาจแก้ด้วย wildcard permission จึงต้องออกแบบ role ตามงานจริง ให้ เครื่องมืออธิบาย denial ได้ และทดสอบ policy เหมือน code

Segregation of duties

Segregation of duties (SoD) หรือการแบ่งแยกหน้าที่ ป้องกันไม่ให้ actor หรือ component เดียวควบคุมขั้นตอนที่ขัดกันครบวงจร ตัวอย่างคือผู้สร้างรายการจ่ายเงิน ไม่เป็นผู้อนุมัติรายการเดียวกัน และผู้เขียน production change ไม่สามารถ bypass review พร้อม deploy โดยไม่มี evidence

SoD มีสองรูปแบบที่ควรแยก Static SoD ห้ามถือ role ที่ขัดกันพร้อมกัน ส่วน Dynamic SoD อาจถือหลาย role ได้แต่ห้ามทำ action ที่ขัดกันใน transaction เดียวกัน Four-eyes approval เป็น control หนึ่ง แต่ต้องมั่นใจว่าผู้อนุมัติมีข้อมูล ความเป็นอิสระ และเวลา พอ ไม่ใช่เพียงกดอนุมัติตามพิธี

องค์กรขนาดเล็กอาจแยกบุคคลไม่ได้ครบ จึงใช้ compensating controls เช่น immutable logging, independent retrospective review, transaction limit และ alert แต่ต้อง ยอมรับว่า detective control ไม่เท่ากับ preventive SoD และต้องบันทึก residual risk

Defense in depth

Defense in depth คือการใช้ controls หลายชั้นที่มี failure modes ต่างกันเพื่อลด โอกาสที่ชั้นเดียวล้มแล้ว asset ถูก compromise ตัวอย่างคือ phishing-resistant authentication, least-privilege authorization, input validation, network segmentation, runtime monitoring และ protected backup ซึ่งหยุดหรือจำกัดคนละช่วง ของ attack path

การมีเครื่องมือหลายชิ้นไม่เท่ากับ defense in depth หากทุกชั้นพึ่ง shared identity, configuration หรือ decision engine เดียวกัน Common-mode failure ทำให้หลายชั้น ล้มพร้อมกัน เช่น policy ผิดชุดเดียวถูกเผยแพร่ไป gateway และ service ทุกตัว

Defense in depth มีต้นทุน latency, complexity, false positive และ operational ownership ทุก layer ต้องมีวัตถุประสงค์ ผู้รับผิดชอบ วิธีตรวจ effectiveness และ failure behavior ชัดเจน ไม่เช่นนั้นจะกลายเป็น control accumulation ที่ให้ความ มั่นใจลวง

Resiliency

Resiliency คือความสามารถในการเตรียม รับแรงกระทบ รักษาบริการสำคัญ ปรับตัว และกู้คืน จากการโจมตี ความผิดพลาด หรือการเปลี่ยนแปลงที่ไม่คาดคิด Availability เป็นผลลัพธ์ หนึ่ง ส่วน resiliency ครอบคลุมเส้นทางก่อน ระหว่าง และหลัง disruption

แนวทางประกอบด้วย fault isolation, bounded resource use, graceful degradation, redundancy across failure domains, tested recovery, queue หรือ retry ที่มี bound, backpressure, circuit breaker และ operational playbook Retry ที่ไม่มี limit อาจ เปลี่ยน failure เล็กเป็น retry storm จึงต้องใส่ jitter, cap และ idempotency

Resiliency ไม่ได้หมายถึงเปิดทุกอย่างต่อเมื่อ security dependency ล่ม ระบบต้อง กำหนด safe degraded mode ตามภารกิจ เช่น อนุญาตให้อ่านข้อมูลฉุกเฉินแบบจำกัดพร้อม audit แต่หยุดการเปลี่ยนสิทธิ์ และต้องตรวจสอบสิทธิ์ย้อนหลัง การตัดสินใจนี้ต้องผ่าน risk governance ก่อน incident

Economy of mechanism

Economy of mechanism คือการทำ security mechanism ให้เล็ก เรียบง่าย และเข้าใจได้ เท่าที่ตอบ requirement Complexity เพิ่มโอกาส defect, misconfiguration, hidden interaction และ review gap กลไกที่รวม authentication, policy, business workflow และ logging ไว้ในฟังก์ชันเดียวมักทดสอบและให้เหตุผลยาก

ความเรียบง่ายไม่เท่ากับความสามารถน้อยเกินจำเป็น และไม่บังคับให้รวมทุกอย่างไว้ใน component เดียว บางครั้งการแยก policy decision จาก enforcement ทำให้ interface ชัดและตรวจสอบง่ายขึ้น แม้จำนวน component เพิ่มเล็กน้อย เป้าหมายคือ conceptual simplicity และ trusted computing base ที่จำกัด ไม่ใช่นับจำนวนไฟล์

ความเสี่ยงอีกด้านคือทีมสร้าง crypto หรือ identity mechanism “แบบง่าย” เอง การ reuse component ที่ผ่านการวิเคราะห์มักปลอดภัยกว่า custom mechanism Economy จึงต้องอ่าน ร่วมกับ component reuse และ open design

Complete mediation

Complete mediation คือการตรวจ authorization ทุก access ที่เกี่ยวข้องกับ protected resource ณ policy enforcement point ที่เชื่อถือได้ ไม่พึ่งการตรวจครั้งแรกแล้วสมมติ ว่าสิทธิ์ยังเหมือนเดิมตลอดไป จุดสำคัญคือ “ทุก access ที่มีผลต่อ policy” ไม่จำเป็น ต้องถาม remote service ทุก instruction

การ cache decision ทำได้หากกำหนด scope, freshness, revocation, invalidation และ failure behavior ตาม risk ตัวอย่างเช่น session token อายุสั้นที่บันทึก audience, scope และ expiry อาจเป็นหลักฐาน decision แบบจำกัด แต่ service ยังต้องตรวจ signature, expiry, audience และ object-level access ทุก request การมี token ไม่ อนุญาตให้ข้าม ownership check

ช่องโหว่ Time-of-Check to Time-of-Use (TOCTOU) เกิดเมื่อสภาพที่ตรวจเปลี่ยนก่อน การใช้ เช่น ตรวจสิทธิ์ path แล้ว attacker สลับ symbolic link ก่อนเปิดไฟล์ การแก้ อาจต้องใช้ atomic operation, immutable identifier, transaction หรือ revalidation ใกล้จุดใช้

Open design

Open design กำหนดว่า security ต้องไม่ขึ้นกับการปิดบัง design หรือ implementation ความลับที่ต้องจัดการควรจำกัดอยู่ที่ค่าเฉพาะ เช่น cryptographic key ไม่ใช่ algorithm หรือ protocol การเปิด design ให้ตรวจสอบช่วยค้น assumption และ defect โดยไม่ทำให้ ระบบอ่อนแอเมื่อเอกสารถูกเปิดเผย

หลักการนี้ไม่บังคับให้เผย source code, architecture หรือ operational detail ต่อ สาธารณะทั้งหมด และไม่ห้ามเก็บข้อมูลที่ช่วยโจมตีเป็นความลับ องค์กรอาจจำกัด access ตาม need-to-know แต่ design ต้องยังปลอดภัยแม้ adversary เข้าใจกลไก การซ่อน URL ผู้ดูแลหรือชื่อ field จึงไม่ใช่ authorization control

Trade-off อยู่ที่การเผยข้อมูลกับ attack enablement วิธีที่เหมาะคือสร้าง internal review ที่มีผู้เชี่ยวชาญหลากหลาย ใช้ standard mechanism และจัดการ disclosure โดย ไม่อ้าง secrecy เป็นรากฐานของ security

Least common mechanism

Least common mechanism คือการลดกลไกและ state ที่ผู้ใช้หรือ trust domain หลายกลุ่ม ใช้ร่วมกัน Shared mechanism สร้าง covert channel, contention, cross-tenant leakage และ blast radius ตัวอย่างคือ shared cache key ที่ไม่รวม tenant identifier ทำให้ tenant หนึ่งได้รับข้อมูลของอีก tenant

การแยกอาจทำที่ process, account, key, queue, database schema, encryption context, namespace หรือ infrastructure ตาม threat model ไม่จำเป็นต้องสร้าง stack แยกทั้งหมด ทุก tenant เพราะต้นทุนสูง แต่ต้องระบุ state ที่แชร์และยืนยันว่า policy boundary ไม่ ถูกข้าม

การแยกมากขึ้นเพิ่มค่าใช้จ่ายและ operational overhead จึงควรใช้ risk-based isolation เช่น แยก key และ administrative plane สำหรับ asset สำคัญ พร้อมใช้ quota, namespacing และ access control กับ shared compute ที่ยอมรับได้

Psychological acceptability

Psychological acceptability คือการทำให้ security mechanism เข้าใจง่าย สอดคล้องกับ mental model และไม่เพิ่ม friction เกินความจำเป็นจนผู้ใช้หลบเลี่ยง control เส้นทาง ที่ปลอดภัยต้องเป็นเส้นทางปกติ พร้อม feedback ที่ช่วยแก้ปัญหาโดยไม่เปิดเผยข้อมูล อ่อนไหว

ตัวอย่างที่ดีคือ password manager และ passkey integration ที่ลดภาระจำ secret, permission prompt ที่บอก resource และเหตุผลอย่างเจาะจง และ error ที่อธิบายขั้นตอน ขอสิทธิ์อย่างถูกต้อง ตัวอย่างที่ไม่ดีคือเตือนทุก action จนเกิด warning fatigue หรือ บังคับ rotation ที่คาดเดาได้จนผู้ใช้เปลี่ยน password เพียงตัวเลขท้าย

หลักการนี้ไม่ใช่ข้ออ้างลด assurance เพื่อความสะดวก แต่บังคับให้ออกแบบ human-system interface เป็นส่วนของ control ถ้า workflow จริงต้องทำงานฉุกเฉิน ควรมี break-glass path ที่จำกัดเวลา บันทึก และ review แทนการผลักให้ผู้ใช้แชร์ credential

Component reuse

Component reuse ลดการเขียนกลไกที่ซับซ้อนซ้ำและเปิดโอกาสใช้ component ที่ผ่านการ วิเคราะห์หรือใช้งานกว้าง แต่ reuse ไม่ได้ปลอดภัยโดยอัตโนมัติ Component นำทั้ง capability, vulnerability, transitive dependency, configuration assumption, license obligation และ lifecycle risk เข้ามา

การตัดสินใจ reuse ต้องพิจารณา fitness for purpose, security history, maintenance, provenance, authenticity, update channel, secure configuration, attack surface, privilege และ exit strategy Wrapper ที่จำกัด interface และ sandbox ที่ลด privilege ช่วยลด blast radius ได้ แต่ไม่ทดแทนการติดตาม vulnerability และ patch

อย่าสับสน “มีผู้ใช้มาก” กับ “ปลอดภัย” Popular component อาจถูกตรวจมากขึ้นและเป็น เป้าโจมตีมากขึ้นพร้อมกัน รายละเอียดการเลือก reusable technology อยู่ใน บทที่ 4 การ integrate และ build อยู่ใน บทที่ 5 และ supplier/provenance อยู่ใน บทที่ 8

การใช้หลายหลักการร่วมกัน

ระบบจริงต้องใช้หลายหลักการพร้อมกัน แผนภาพต่อไปแสดง workflow อนุมัติการเปลี่ยน configuration สำคัญ ซึ่ง least privilege และ SoD จำกัดผู้กระทำ complete mediation ตรวจทุก transition และ evidence สนับสนุน accountability

Workflow นี้ยังใช้ economy of mechanism ด้วยการรวม policy logic ที่ review ได้ ไว้ในจุดตัดสินใจ แต่ไม่สร้าง single point of compromise โดยต้องป้องกัน policy service และ evidence store แยกกัน การใช้ short-lived grant จำกัด blast radius และการบันทึก exact change ป้องกันผู้อนุมัติเห็นเนื้อหาคนละชุดกับสิ่งที่ deploy

ตารางต่อไปช่วยแยกเจตนาของหลักการ ไม่ควรใช้เป็น checklist ตายตัว

Principle	คำถามตรวจ design	Failure ที่มุ่งลด	Trade-off สำคัญ
Least privilege	สิทธิ์แคบตาม action, resource และเวลาหรือไม่	Privilege abuse และ blast radius	Policy complexity และ support burden
Segregation of duties	ใครทำธุรกรรมสำคัญครบวงจรได้หรือไม่	Fraud, error และ unilateral change	Delay และ staffing constraint
Defense in depth	ชั้นป้องกันมี failure mode อิสระหรือไม่	Single-control failure	Complexity, cost และ false positive
Resiliency	ระบบรักษาภารกิจและกู้คืนอย่างไร	Disruption และ cascading failure	Redundancy cost และ stale state
Economy of mechanism	Trusted mechanism เล็กและ review ได้หรือไม่	Defect จาก complexity	อาจต้องลด feature หรือแยก interface
Complete mediation	ทุก access ตรวจ policy ที่เหมาะสมหรือไม่	Stale decision และ bypass	Latency, caching และ dependency
Open design	ความปลอดภัยพึ่ง secrecy ของ design หรือไม่	Obscurity failure	Disclosure management
Least common mechanism	State ใดแชร์ข้าม trust domain	Cross-tenant leak และ common failure	Isolation cost
Psychological acceptability	ผู้ใช้ทำงานตาม policy ได้ง่ายหรือไม่	Workaround และ human error	UX investment และ exception design
Component reuse	รู้ provenance, assumption และ lifecycle หรือไม่	Custom defect และ unmanaged dependency	Supply-chain exposure และ update burden

ภัยคุกคาม ช่องโหว่ และความเสี่ยง

การวิเคราะห์ที่ดีไม่เริ่มด้วยชื่อเครื่องมือ แต่เริ่มด้วย threat scenario ที่เชื่อม adversary หรือเหตุการณ์กับ asset ผ่าน vulnerability และอธิบายผลต่อ security objective สถานการณ์เดียวอาจกระทบหลาย property และ controls ต้องตัด attack path ในจุดที่เหมาะสม

แยกคำที่มักสับสน

Threat actor เป็นผู้หรือสิ่งที่อาจก่อเหตุ Threat event คือเหตุการณ์ เช่น credential ถูกใช้โดยผู้ไม่ได้รับอนุญาต Attack vector คือเส้นทางเข้าถึง เช่น phishing link Vulnerability คือ weakness เช่น recovery flow ไม่ตรวจ factor ที่สอง และ impact คือผลต่อวัตถุประสงค์ เช่นข้อมูลลูกค้ารั่ว การใช้คำตรงช่วยให้เลือก control ไม่หลงเป้า

ตัวอย่าง “มี SQL injection risk” ยังไม่ครบ คำอธิบายที่ใช้ตัดสินใจได้มากกว่าคือ “ผู้ใช้อินเทอร์เน็ตส่ง input ที่เปลี่ยนโครงสร้าง query ผ่าน endpoint ค้นหา เพราะ code ต่อ string โดยตรง ทำให้อ่านหรือแก้ record ข้าม tenant ได้” ประโยคนี้ระบุ actor, entry point, weakness, asset และ impact

Threat scenarios ต่อ core concepts

สถานการณ์ต่อไปนี้แสดงความเชื่อมโยงของ threat กับ property โดย control ที่ระบุเป็น ตัวอย่าง ไม่ใช่รายการครบถ้วน

Threat scenario	Vulnerability หรือ exposure	Property ที่เสี่ยง	Control directions
Credential stuffing เข้าบัญชีลูกค้า	Password reuse, ไม่มี rate control และ recovery อ่อน	Authentication, confidentiality, integrity	Phishing-resistant factor, breached-secret detection, rate limit, session protection
API อ่าน record ข้ามผู้ใช้	ตรวจ role แต่ไม่ตรวจ object ownership	Authorization, confidentiality	Central policy, object-level check, negative tests, default deny
Insider แก้รายการและลบหลักฐาน	สิทธิ์สร้าง อนุมัติ และลบ log อยู่บัญชีเดียว	Integrity, accountability	SoD, append-protected evidence, alert, independent review
Dependency ถูกแทนใน build	ไม่ตรวจ provenance หรือ artifact integrity	System integrity, confidentiality	Pin and verify artifact, isolated build, provenance evidence, update governance
Resource exhaustion	Unbounded input, retry และ shared pool	Availability	Input bound, quota, backpressure, isolation, graceful degradation
Cache key ขาด tenant context	Shared mechanism ไม่แยก namespace	Confidentiality, integrity	Tenant-bound key, isolation, access check after cache retrieval
Operator แชร์ signing key	Weak key custody และ attribution	Nonrepudiation, accountability	Individual authorization, protected key use, quorum, key-use audit
Security control ล่มแล้ว bypass	Fail-open behavior ไม่ผ่าน risk decision	Confidentiality, integrity	Explicit failure mode, bounded cache, safe degradation, recovery plan

Attack path และ control independence

ผู้โจมตีมักประกอบ weakness หลายจุดเข้าด้วยกัน เช่น phishing ขโมย session จากนั้น ใช้ excessive permission อ่านข้อมูล แล้วลบ log ผ่าน administrative role เดียวกัน การแก้เฉพาะ password policy ไม่ตัดขั้นตอนที่เหลือ Defense in depth จึงต้องลดทั้ง โอกาสเริ่มต้น การขยายสิทธิ์ ผลกระทบ และเวลาตรวจพบ

แผนภาพนี้แสดงความเป็นอิสระของ controls แต่ละชั้น แม้ session protection ล้ม object-level authorization ยังตัดการเข้าถึง และแม้ข้อมูลบางส่วนถูกอ่าน evidence ที่ผู้โจมตีลบไม่ได้ช่วยลดเวลาตรวจพบและสนับสนุน accountability

ความล้มเหลวจาก assumption และ composition

Component แต่ละตัวอาจปลอดภัยเมื่ออยู่ลำพังแต่ composition ไม่ปลอดภัย ตัวอย่างคือ gateway ตรวจ authentication แล้วส่ง user identifier ผ่าน header แต่ backend เปิดรับ traffic โดยตรงจาก network อื่น ผู้โจมตีจึงสร้าง header เองได้ Assumption ว่า “ทุก request ผ่าน gateway” ไม่ถูก enforce ที่ trust boundary

อีกตัวอย่างคือ service A ตรวจ authorization ก่อนส่ง asynchronous job แต่ worker B ประมวลผลภายหลังโดยไม่ผูก job กับ policy version หรือ expiry หากสิทธิ์ถูกเพิกถอน ระหว่าง queue รอ ระบบต้องกำหนดว่าจะ reauthorize เมื่อ consume หรือถือ decision เดิม ตาม transaction semantics Complete mediation จึงเกี่ยวกับ freshness และจุดใช้ ไม่ใช่เพียงจำนวนการเรียก policy engine

Human, process และ AI-related exposure

Security concept ใช้กับความผิดพลาดที่ไม่มุ่งร้ายด้วย เช่น approver มี warning fatigue, operator เลือก environment ผิด หรือ reviewer ไม่เห็น generated code ที่ ถูกนำเข้า build Psychological acceptability, SoD และ protected evidence ลด risk จาก human-system interaction ได้

ระบบที่ใช้ Machine Learning (ML) หรือ Large Language Model (LLM) ยังต้องใช้หลัก เดียวกัน Prompt, retrieved data, model output, tool permission และ model artifact เป็น assets หรือ untrusted inputs ตามบริบท ตัวอย่างเช่น prompt injection อาจชักนำ agent ให้เรียก tool เกินสิทธิ์ การแก้ไม่ควรพึ่งข้อความสั่ง model เพียงชั้นเดียว แต่ ต้องใช้ authorization ที่ deterministic, least privilege, output validation, data boundary และ monitoring รายละเอียดต้องผูกกับ architecture และ use case ใน บทที่เกี่ยวข้อง ไม่ถือว่า AI สร้างข้อยกเว้นจากหลักพื้นฐาน

Controls และแนวปฏิบัติที่ดี

Control คือมาตรการที่ปรับเปลี่ยน risk และอาจเป็นคน กระบวนการ หรือเทคโนโลยี การ เลือก control ต้องระบุ objective, owner, placement, failure mode, evidence และ ผลข้างเคียง มิฉะนั้นทีมอาจมี control บนเอกสารแต่ไม่ลด risk จริง

ประเภทของ control ตามจังหวะและหน้าที่

การจัดประเภทช่วยค้น coverage gap แต่ control หนึ่งอาจทำได้หลายหน้าที่ขึ้นกับการใช้ งาน ประเภทหลักมีดังนี้

• Preventive control: ลดโอกาสเกิดเหตุ เช่น default deny และ parameterized query
• Detective control: ตรวจเหตุหรือความผิดปกติ เช่น alert จาก denied access ที่ เพิ่มขึ้นผิดปกติ
• Corrective control: แก้สถานะหลังพบปัญหา เช่น revoke token และแก้ misconfiguration
• Deterrent control: ลดแรงจูงใจด้วยการทำให้ทราบว่ามีการกำกับ เช่น notice และ attributable privileged session
• Compensating control: ลด risk เมื่อใช้ control หลักไม่ได้ โดยต้องประเมินว่า coverage เทียบเท่าพอหรือไม่
• Recovery control: คืน capability หรือ data ที่จำเป็น เช่น tested restore และ alternate service path

อย่าตอบโจทย์ preventive control ด้วย logging เพียงอย่างเดียว และอย่าเรียก backup ว่าช่วย confidentiality เว้นแต่ design คุ้มครอง backup จาก unauthorized access พร้อมกัน Control category ต้องสัมพันธ์กับ threat scenario

Secure by design, secure by default และ fail secure

Secure by design จัด security เป็น constraint และ property ตั้งแต่เริ่มกำหนด แนวคิด Secure by default ทำให้ค่าเริ่มต้นจำกัด exposure และ privilege โดยไม่ต้อง รอผู้ใช้ตั้งค่า ส่วน fail secure กำหนดว่าสถานะเมื่อผิดพลาดยังรักษา security policy แม้อาจลด availability สามแนวคิดนี้สนับสนุน design principles แต่ไม่แทนกัน

ตัวอย่าง service ใหม่ควรไม่เปิด public endpoint โดย default, ใช้ workload identity เฉพาะ service, ปฏิเสธ action ที่ไม่ match policy และไม่พิมพ์ secret ลง error เมื่อ policy dependency ล่ม ต้องกำหนดว่า operation ใด fail closed และ operation ใดใช้ bounded cached decision ได้ตาม risk

Control placement ที่ trust boundary

Trust boundary คือขอบเขตที่ข้อมูลหรือการควบคุมข้ามระดับความไว้วางใจและต้องตรวจ หรือบังคับ policy Input ที่ผ่าน client validation ยังเป็น untrusted เมื่อถึง server เพราะ client ถูกแก้ได้ การ validate ที่ boundary ใกล้ resource ช่วยลด assumption แต่ไม่ได้แปลว่าทำซ้ำแบบไม่ประสานกันทุก layer

แนวปฏิบัติที่ดีคือ normalize และ parse ด้วย grammar ที่ชัด validate ตาม business rule, bind identity และ tenant context, authorize action กับ object, จำกัด resource consumption และ encode output ตาม sink แต่รายละเอียด secure coding อยู่ใน บทที่ 5

Control independence และ common-mode failure

เมื่ออ้าง defense in depth ให้ถามว่าชั้นต่าง ๆ พึ่งอะไรเหมือนกัน ตัวอย่าง controls สองชั้นที่อ่าน policy จาก repository เดียวและ deploy ด้วย privileged pipeline เดียว อาจล้มพร้อมกันหาก repository ถูกแก้ ควรแยก key, approval, enforcement หรือ evidence ตาม risk เพื่อไม่ให้ control ผู้ตรวจถูกแก้โดย actor เดียวกับผู้ถูกตรวจ

ความเป็นอิสระแบบสมบูรณ์มีต้นทุนสูง จึงระบุ critical path และเลือก independent control ในจุดที่ impact สูง เช่น แยก production signing authority จาก source commit authority และเก็บ audit evidence นอก administrative domain ของ workload

ตรวจ effectiveness ไม่ใช่แค่ presence

การมี control ไม่พิสูจน์ว่า control ทำงาน ต้องนิยาม expected behavior และ evidence ตัวอย่างเช่น “มี access control” วัดไม่ได้ แต่ “ทุก request ที่อ่าน payroll record ต้องผ่าน object-level policy โดย default deny และ negative test ยืนยัน cross-tenant denial” เชื่อม requirement, design และ verification ได้

Metric และ reporting ต้องหลีกเลี่ยง vanity metric จำนวน findings อาจเพิ่มเพราะทีม ตรวจดีขึ้น ไม่ใช่ระบบแย่ลง บทที่ 2 จะลงรายละเอียด security metrics, reporting, exception และ governance gate

Decision record สำหรับ security trade-off

การตัดสินใจ design ควรบันทึกบริบท options, threat assumptions, chosen option, controls, residual risk, owner และ review trigger ตัวอย่างเช่นการ cache authorization decision ต้องระบุ time-to-live, revocation sensitivity, scope, fail behavior และ observability ไม่ใช่เพียง “เพื่อ performance”

Decision record ช่วย accountability และ traceability แต่ไม่ใช่หลักฐานว่า decision ถูกเสมอ เมื่อ threat, dependency หรือ usage เปลี่ยน ต้องทบทวน assumption และอาจ เปลี่ยน control

Pseudo code

ตัวอย่าง pseudo code ต่อไปสาธิต policy gate สำหรับการอนุมัติและ execute การจ่ายเงิน โดยรวม authentication, complete mediation, least privilege, dynamic SoD, accountability และหลักฐาน integrity ตัวอย่างนี้ไม่ใช่ code ที่ compile ได้ และละ รายละเอียด cryptography, storage และ error handling ที่ production system ต้องมี

# PSEUDO CODE — authorize a high-impact payment transition

function execute_payment(request, authenticated_session):
    # Treat caller-supplied identity, role, tenant, and amount as untrusted.
    subject = identity_service.verify_session(
        session = authenticated_session,
        required_assurance = policy.assurance_for("payment.execute")
    )
    if subject is INVALID:
        audit.append(event("authentication_denied", request.correlation_id))
        return GENERIC_DENIAL

    # Load canonical server-side state; never authorize from client display data.
    payment = payment_store.load_for_update(request.payment_id)
    if payment is MISSING:
        audit.append(event("resource_not_available", subject.id,
                           request.correlation_id))
        return GENERIC_DENIAL

    decision_context = {
        "subject": subject.id,
        "action": "payment.execute",
        "resource": payment.id,
        "tenant": payment.tenant_id,
        "amount_band": classify_amount(payment.amount),
        "current_state": payment.state,
        "session_assurance": subject.assurance,
        "policy_version": policy.current_version()
    }

    # COMPLETE MEDIATION: evaluate at the protected state transition.
    decision = policy.authorize(decision_context)
    if decision != ALLOW:
        audit.append(protected_event("authorization_denied", decision_context))
        return GENERIC_DENIAL

    # SEGREGATION OF DUTIES: the requester cannot approve the same payment.
    approvals = approval_store.valid_approvals_for(
        payment_id = payment.id,
        exact_content_hash = hash(canonical(payment.business_fields)),
        required_policy_version = decision_context.policy_version
    )
    if approvals.count < 1 or approvals.contains_actor(payment.requested_by):
        audit.append(protected_event("independent_approval_missing",
                                     decision_context))
        return GENERIC_DENIAL

    # Prevent time-of-check/time-of-use races with an atomic transition.
    result = payment_store.atomic_transition(
        id = payment.id,
        expected_state = "APPROVED",
        new_state = "EXECUTING",
        bind_to_hash = hash(canonical(payment.business_fields))
    )
    if result != SUCCESS:
        audit.append(protected_event("state_transition_conflict",
                                     decision_context))
        return SAFE_RETRY_RESPONSE

    # LEAST PRIVILEGE: mint a short-lived, single-payment grant for the executor.
    execution_grant = grant_service.issue(
        audience = "payment-executor",
        action = "settle",
        resource = payment.id,
        tenant = payment.tenant_id,
        expires_in = policy.short_duration(),
        correlation_id = request.correlation_id
    )

    outcome = executor.settle(payment.id, execution_grant)
    audit.append(protected_event(
        "payment_execution_result",
        subject = subject.id,
        payment = payment.id,
        approval_evidence_hashes = approvals.hashes,
        policy_version = decision_context.policy_version,
        outcome = minimize(outcome),
        correlation_id = request.correlation_id
    ))

    return response_without_sensitive_details(outcome)

จุดสำคัญไม่ใช่ syntax แต่เป็นตำแหน่งการตัดสินใจ ระบบโหลด canonical state ก่อน authorize ผูก approval กับ exact content ป้องกันการเปลี่ยนข้อมูลหลังอนุมัติ ใช้ atomic transition ลด TOCTOU และออก grant ที่ scope แคบให้ executor Audit record เก็บข้อมูลพอสำหรับ accountability โดยไม่คัดลอกข้อมูลการเงินทั้งหมด

Pseudo code ยังไม่สร้าง nonrepudiation ที่สมบูรณ์ เพราะต้องกำหนด identity proofing, key custody, signature format, trusted time และ evidence lifecycle เพิ่มเติม การ เรียก protected_event เพียงสื่อว่า evidence ต้องรักษา integrity ไม่ใช่คำรับรอง ผลทางกฎหมาย

ตัวอย่างหรือกรณีศึกษา

กรณีศึกษานี้ใช้ระบบ payroll แบบ multi-tenant เพื่อแสดงว่าการแก้ control จุดเดียว มักไม่พอ บริษัทให้ HR ของลูกค้า upload รายการพนักงาน อนุมัติ payroll และส่งรายการ ไป payment provider ผ่าน SaaS เดียวกัน

สถานการณ์เริ่มต้น

ระบบใช้ login พร้อม second factor แต่ทุก HR manager ได้ role PAYROLL_ADMIN ซึ่งอ่าน แก้ อนุมัติ และ export payroll ได้ทุก record ใน tenant API ตรวจเพียง role และรับ tenant_id จาก request body Worker ใช้ shared credential เพื่อส่ง payment และ application administrator ลบ log ได้

ทีมสรุปในตอนแรกว่า “มี MFA และ encryption จึงปลอดภัย” แต่ reasoning นี้พลาดหลาย ประเด็น:

• Authentication ที่ดีไม่แก้ authorization ที่กว้าง
• Encryption ไม่หยุด application ที่ได้รับ key และอ่านข้อมูลผ่าน API
• Tenant context จาก client เปิดทาง horizontal privilege escalation
• Shared worker credential ทำให้ attribution และ revocation อ่อน
• ผู้สร้างและผู้อนุมัติรายการคนเดียวกันขัด SoD
• ผู้ดูแล workload ลบ evidence ได้ ทำให้ accountability อ่อน

Threat scenario และผลกระทบ

ผู้โจมตีขโมย session ของ HR manager ผ่าน malicious browser extension แล้วแก้ tenant identifier ใน request API ตรวจ role ผ่านและส่งข้อมูล tenant อื่นกลับมา จากนั้นผู้โจมตีสร้าง payroll record, อนุมัติเอง และใช้ export endpoint ดึงข้อมูล จำนวนมาก Alert ไม่ทำงานเพราะ event ไม่มี canonical tenant และ worker ทุกงานใช้ identity เดียวกัน

ผลกระทบครอบคลุม confidentiality จากข้อมูลข้าม tenant, integrity จากรายการจ่ายที่ ถูกแก้, accountability จาก shared identity และ availability หากองค์กรต้องหยุด ระบบทั้งหมดเพื่อสอบสวน นี่แสดงว่า CIA และ identity properties เชื่อมกัน

Design ที่ปรับปรุง

ทีมปรับ design โดย derive tenant จาก server-side membership ไม่รับค่าเป็น authority จาก client ตรวจ object-level authorization ทุก request แยก role ผู้จัดทำกับผู้อนุมัติ และบังคับ independent actor สำหรับ transaction สำคัญ Worker แต่ละ workload ใช้ short-lived identity และ grant เฉพาะ payment

ทีมเพิ่ม append-protected evidence store แยก administrative domain, rate limit export, step-up authentication ก่อน high-impact action, transaction-bound approval, data minimization และ anomaly detection ต่อ tenant Recovery path ถูกออกแบบให้ เพิกถอน session และ grant โดยไม่หยุด read-only payroll history ทั้งระบบ

Trade-offs และ residual risk

SoD เพิ่มเวลาการอนุมัติและลูกค้ารายเล็กอาจมี HR คนเดียว ทีมจึงกำหนด compensating workflow ที่มี transaction cap, delayed settlement และ independent review โดย risk owner อนุมัติ exception เป็นระยะ Object-level checks เพิ่ม latency จึงใช้ local policy data ที่มี version และ bounded freshness แทน bypass

Residual risk ยังรวมการยึดทั้ง requester และ approver, malicious administrator, payment provider compromise และ policy misconfiguration ทีมต้องส่งเรื่องเหล่านี้ ไปยัง lifecycle governance, architecture, testing, operations และ supply chain แทนการประกาศว่า design “ปลอดภัยแล้ว”

Exam tips

ข้อสอบเชิงสถานการณ์มักให้ controls หลายข้อที่ดูมีประโยชน์ คุณต้องหา objective และ ลำดับเหตุผลก่อนเลือกคำตอบที่ดีที่สุด Tips ต่อไปนี้ช่วยแยกแนวคิดที่ชื่อใกล้กัน

• ถ้าคำถามถาม “ใครหรืออะไร” ให้คิด authentication ก่อน แต่ถ้าถาม “ทำ action นี้ กับ object นี้ได้หรือไม่” ให้คิด authorization
• ถ้าต้องตาม action กลับไปหา actor ให้คิด accountability ถ้าต้องโต้แย้งการปฏิเสธ ด้วยหลักฐานที่มี assurance สูง ให้พิจารณา nonrepudiation
• ถ้า user มีสิทธิ์เกินงาน ให้เลือก least privilege ถ้า user เดียวทำขั้นตอนขัดกัน ครบวงจร ให้เลือก segregation of duties
• ถ้าคำตอบเพิ่ม controls หลายชั้น ให้ตรวจว่า layers มี failure modes ต่างกัน จึงจะ เป็น defense in depth ที่มีความหมาย
• ถ้าระบบตรวจสิทธิ์เฉพาะ login หรือ gateway แต่ไม่ตรวจ resource access ให้คิด complete mediation และ object-level authorization
• ถ้าความปลอดภัยพึ่ง URL, algorithm หรือ implementation ที่ “ไม่มีใครรู้” ให้คิด open design ไม่ใช่ defense in depth
• ถ้ากลไกซับซ้อนจน review ยาก ให้คิด economy of mechanism แต่ไม่เลือก custom security mechanism เพียงเพราะ code สั้นกว่า standard component
• ถ้าผู้ใช้หลบเลี่ยง control เพราะ workflow ใช้งานไม่ได้ ให้คิด psychological acceptability และ safe workflow ไม่ใช่ยกเลิก policy โดยไม่มี risk decision
• ถ้าถามว่าใครยอมรับ residual business risk คำตอบควรเป็นผู้มีอำนาจหรือ risk owner ที่เหมาะสม ไม่ใช่ developer หรือ scanner
• ถ้า compliant แต่ยังมี uncovered threat ให้จำว่า compliance ไม่รับประกัน security และ risk management ต้องพิจารณาบริบทจริง

เมื่อคำถามมีคำว่า “BEST,” “MOST,” หรือ “FIRST” ให้แยกว่าโจทย์ต้องการ principle, control หรือ process step คำตอบที่ถูกหลายข้ออาจต่างกันที่ระดับ abstraction และลำดับ กิจกรรม อย่าเลือก implementation detail ก่อนเข้าใจ asset และ risk

Common pitfalls

ข้อผิดพลาดต่อไปนี้เกิดบ่อยทั้งในการสอบและการทำงานจริง เพราะทีมจำชื่อ control แต่ ไม่ได้ตรวจ assumption และขอบเขตของมัน

• ถือว่า authentication สำเร็จแล้วจึงอนุญาตทุก action โดยไม่ตรวจ authorization
• ถือว่า encryption แก้ confidentiality ทุกสถานะ ทั้งที่ endpoint และ key use ยัง เปิดเผย plaintext
• ใช้ hash ธรรมดาเป็นหลักฐานว่าใครสร้างข้อมูล ทั้งที่ทุกคนคำนวณ hash ได้
• เรียก shared-secret MAC ว่า nonrepudiation ระหว่างผู้ถือ secret ทั้งหมด
• เก็บ log มากแต่ใช้ shared identity, time ไม่สอดคล้อง หรือให้ผู้ถูกตรวจลบ log ได้
• ใช้ deny เมื่อ dependency ล่มโดยไม่วิเคราะห์ availability และภารกิจ หรือใช้ allow โดยไม่กำหนด bounded degraded mode
• นับจำนวน security products เป็น defense in depth โดยไม่ตรวจ common-mode failure
• แปล least privilege ว่า “ไม่เป็น admin” แต่ยังให้ wildcard resource และ token อายุยาว
• แปล SoD ว่า “มีสองคน” แม้คนที่สองไม่มีอิสระ ไม่เห็น exact transaction หรือใช้ credential ร่วมกัน
• cache authorization แบบไม่ผูก audience, scope, policy version, expiry และ revocation semantics
• พึ่งความลับของ endpoint หรือ algorithm แทน access control และ key management
• reuse component จาก popularity เพียงอย่างเดียวโดยไม่ประเมิน provenance, configuration และ maintenance
• ทำ security prompt หรือ warning มากจนผู้ใช้กดผ่านอัตโนมัติ แล้วโทษ human error
• ให้ทีมเทคนิคยอมรับ residual business risk ที่เกินอำนาจของทีม
• ถือว่า compliance checklist ครบแล้ว threat ที่ไม่อยู่ใน checklist ไม่สำคัญ

ข้อฝึกทบทวน

คำถามทั้งหมดในส่วนนี้เป็นข้อฝึกที่สร้างขึ้นเองเพื่อทบทวนแนวคิด ไม่ใช่ข้อสอบจริง ของ ISC2 และไม่อ้างอิง exam dump เลือกคำตอบที่ดีที่สุดในบริบทของแต่ละข้อ

ข้อ 1: Authentication กับ authorization

ผู้ใช้ login ด้วย phishing-resistant multi-factor authentication ได้สำเร็จ แต่ เปลี่ยน object identifier ใน URL แล้วอ่าน invoice ของลูกค้ารายอื่นได้ Control ใด แก้ weakness โดยตรงที่สุด

A. เพิ่ม factor authentication อีกหนึ่งชนิด
B. เข้ารหัสฐานข้อมูลด้วย key ที่แข็งแรงขึ้น
C. ตรวจ object-level authorization ทุก request จาก server-side context
D. เพิ่มรายละเอียดใน audit log

ข้อ 2: Segregation of duties

ทีมขนาดเล็กมี operator คนเดียวที่ต้องสร้างและ deploy emergency change แต่ policy ปกติกำหนดให้คนละคนอนุมัติ ทางเลือกใดจัดการ risk ได้ดีที่สุดเมื่อแยกบุคคลล่วงหน้า ไม่ได้

A. ปิด logging เพื่อให้ deploy เร็วขึ้น
B. ใช้ break-glass ที่จำกัดเวลาและ scope พร้อม protected log และ independent review หลังเหตุการณ์
C. มอบ permanent administrator role เพื่อไม่ต้องขอ exception
D. ให้ operator ใช้ shared account ของทีม

ข้อ 3: Defense in depth

ระบบมี gateway และ backend ที่ตรวจ authorization สองครั้ง แต่ทั้งคู่รับ policy จาก cache เดียวซึ่งผู้ดูแล workload แก้ได้ ข้อสรุปใดเหมาะสมที่สุด

A. เป็น defense in depth สมบูรณ์เพราะตรวจสองครั้ง
B. ไม่ต้องตรวจ backend เพราะ gateway ตรวจแล้ว
C. Layers มี common-mode failure จึงต้องป้องกัน policy source และเพิ่มความเป็นอิสระ ตาม risk
D. เปลี่ยน cache เป็นฐานข้อมูลก็แก้ทั้งหมด

ข้อ 4: Nonrepudiation

ผู้อนุมัติสามคนใช้ shared signing key เดียวกันลงนามคำสั่งซื้อ ต่อมาคนหนึ่งปฏิเสธว่า ไม่ได้อนุมัติ จุดอ่อนสำคัญที่สุดของหลักฐานคืออะไร

A. Digital signature รักษา confidentiality ไม่ได้
B. Shared key ทำให้ระบุผู้ใช้ key รายบุคคลไม่ได้อย่างน่าเชื่อถือ
C. Hash ของเอกสารมีขนาดคงที่
D. คำสั่งซื้อถูกเก็บในฐานข้อมูล

ข้อ 5: Complete mediation

API ตรวจ role ตอนสร้าง session แล้วเชื่อ role ใน token นาน 24 ชั่วโมง แม้ผู้ดูแล เพิกถอน role แล้ว token เดิมยังแก้ข้อมูลได้ ข้อปรับปรุงใดสอดคล้อง complete mediation มากที่สุดโดยคำนึงถึง performance

A. เลิก authorization และพึ่ง network firewall
B. ใช้ decision ที่ cache แบบไม่มีวันหมดอายุ
C. ใช้ token อายุสั้นที่จำกัด audience และ scope พร้อมกลไก revocation หรือ revalidation สำหรับ action สำคัญ
D. ซ่อน endpoint จาก documentation

ข้อ 6: GRC และ residual risk

หลังใช้ controls แล้วระบบยังมี residual risk ทางธุรกิจเกินระดับที่ทีมพัฒนาตัดสินใจ ได้ ใครควรตัดสินใจ accept risk

A. Developer ที่แก้ defect ล่าสุด
B. Vendor ที่ขาย scanner
C. Risk owner หรือผู้มีอำนาจที่ governance กำหนด พร้อมบันทึก rationale
D. ผู้ใช้คนแรกที่เข้า production

ข้อ 7: Economy of mechanism กับ reuse

ทีมเสนอสร้าง encryption algorithm แบบสั้นเองเพราะ standard library มี code และ configuration มากกว่า การตัดสินใจใดเหมาะสมที่สุด

A. เลือก algorithm ที่สร้างเองเพราะ code น้อยกว่าจึงปลอดภัยกว่าเสมอ
B. เลือก component มาตรฐานที่เหมาะกับ use case และประเมิน configuration, provenance และ maintenance
C. ไม่ใช้ encryption เพราะทุก mechanism มี complexity
D. ซ่อน source code ของ algorithm ที่สร้างเอง

ข้อ 8: Resiliency และ fail secure

โรงพยาบาลต้องอ่าน allergy record ระหว่าง identity provider ขัดข้อง แต่การแก้ข้อมูล โดยผู้ไม่ได้รับอนุญาตมีผลรุนแรง Design ใดให้ reasoning สมดุลที่สุด

A. เปิดทุก action ให้ทุกคนจนระบบ identity กลับมา
B. ปิดระบบทั้งหมดเสมอโดยไม่พิจารณาภารกิจ
C. กำหนดล่วงหน้าให้ใช้ bounded cached authorization สำหรับ read-only emergency access พร้อม audit และหยุด high-risk write
D. ใช้ shared administrator password ในห้องฉุกเฉิน

เฉลยข้อฝึกทบทวน

เฉลยต่อไปนี้อธิบายทั้งเหตุผลของคำตอบที่ดีที่สุดและข้อจำกัดของตัวเลือกอื่น เพื่อ ฝึกแยก property, principle และ control placement ให้ตรงกับ scenario

เฉลยข้อ 1

คำตอบ: C. Weakness คือไม่มี object-level authorization หรือมีแต่ไม่ใช้ tenant context ที่เชื่อถือได้ การตรวจทุก request ใกล้ protected resource แก้ horizontal privilege escalation โดยตรง A เพิ่ม assurance ต่อ identity เดิมแต่ identity นั้นยัง เข้าถึง object ผิดได้ B ลด risk ของ storage บางสถานะ ไม่แก้ API authorization และ D ช่วยตรวจย้อนหลังแต่ไม่ป้องกัน unauthorized read

เฉลยข้อ 2

คำตอบ: B. เมื่อ preventive SoD ทำไม่ได้จริง ระบบต้องใช้ exception ที่จำกัด scope และเวลา เก็บ evidence ที่ operator แก้ไม่ได้ และให้ผู้เป็นอิสระ review เพื่อ เป็น compensating control พร้อมยอมรับ residual risk A และ D ทำลาย accountability ส่วน C เปลี่ยนข้อยกเว้นเป็น privilege ถาวรและขัด least privilege

เฉลยข้อ 3

คำตอบ: C. การตรวจสองชั้นมีคุณค่าเพียงใดขึ้นกับ failure mode หาก policy source เดียวถูกแก้ ทั้งสองชั้นตัดสินผิดพร้อมกัน จึงต้องป้องกัน source, deployment และ evidence หรือเพิ่ม independent constraint ตาม risk A นับจำนวนชั้นอย่างผิวเผิน B เปิดช่อง bypass เมื่อ request ถึง backend โดยตรง และ D เปลี่ยนเทคโนโลยี storage แต่ ไม่แก้อำนาจแก้ policy โดยอัตโนมัติ

เฉลยข้อ 4

คำตอบ: B. Signature แสดงว่า shared private key ถูกใช้ แต่ผู้ถือ key หลายคนสร้าง signature แบบเดียวกันได้ จึง attribution รายบุคคลอ่อน A เป็นจริงว่า signature ไม่ ได้มีเป้าหมายหลักด้าน confidentiality แต่ไม่ใช่จุดอ่อนต่อข้อพิพาทนี้ C เป็นคุณสมบัติ ปกติของ hash และ D ไม่บอกว่า record ถูกป้องกันหรือไม่ จึงไม่ใช่คำตอบตรงที่สุด

เฉลยข้อ 5

คำตอบ: C. Token อายุสั้นและ scope แคบลดช่วง stale authorization ขณะที่ action สำคัญ revalidate หรือรองรับ revocation ตาม risk จึงสมดุล complete mediation กับ performance A สับสน network location กับ authorization B ทำให้ stale decision ถาวร และ D ใช้ obscurity แทน control

เฉลยข้อ 6

คำตอบ: C. Governance ต้องกำหนดผู้มีอำนาจตัดสินใจต่อ business risk และการ ยอมรับต้องมี rationale, conditions และ review trigger ทีมพัฒนาและ vendor ให้ข้อมูล ได้แต่ไม่รับ risk แทนเจ้าของวัตถุประสงค์ ส่วนผู้ใช้ทั่วไปไม่ได้รับมอบ authority เพียงเพราะเริ่มใช้ระบบ

เฉลยข้อ 7

คำตอบ: B. Economy of mechanism สนับสนุนความเรียบง่ายที่ตรวจสอบได้ ไม่ได้ สนับสนุนการประดิษฐ์ cryptography เอง Component ที่เหมาะสมยังต้องประเมิน provenance, configuration และ lifecycle A สรุปจากจำนวนบรรทัดผิด C ละทิ้ง requirement และ D ขัด open design เพราะพึ่ง secrecy ของ implementation

เฉลยข้อ 8

คำตอบ: C. Scenario ต้องรักษาภารกิจอ่านข้อมูลสำคัญพร้อมจำกัด integrity risk การกำหนด degraded mode ล่วงหน้า ใช้ decision ที่ยังสดพอ จำกัด read-only และเก็บ evidence แสดง resiliency กับ fail secure แบบ risk-based A เปิด privilege กว้าง B ละเลย availability และ safety mission ส่วน D ทำลาย attribution, least privilege และ credential security

สรุปบท

Secure Software Concepts เริ่มจาก asset, threat, vulnerability, risk และ control แล้วใช้ Confidentiality, Integrity และ Availability เป็น objectives หลัก Identity properties แยก authentication จาก authorization และใช้ accountability กับ nonrepudiation เพื่อสร้าง evidence ที่เหมาะสม GRC ทำให้มีทิศทาง ผู้รับผิดชอบ และ อำนาจจัดการ residual risk

Design principles ทั้งสิบช่วยตรวจ failure mode จากหลายมุม Least privilege และ SoD จำกัดอำนาจ Defense in depth และ resiliency จำกัดและฟื้นจากความล้มเหลว Economy of mechanism, complete mediation และ open design ทำให้ mechanism ตรวจสอบได้ Least common mechanism ลด shared exposure Psychological acceptability ทำให้ control อยู่รอดใน workflow จริง และ component reuse ลด custom complexity พร้อมนำ supply-chain risk ที่ต้องจัดการเข้ามา

คำตอบที่ดีจึงไม่ใช่ “เพิ่ม security” แบบกว้าง แต่ระบุ property ที่ต้องรักษา threat scenario, control placement, trade-off, evidence และ residual risk owner อย่างชัดเจน

เชื่อมโยงไปยังบทถัดไป

บทที่ 2: Secure Software Lifecycle Management จะนำภาษากลางของบทนี้ไปสร้าง governance ตลอด SDLC โดยกำหนด methodology, standards, roadmap, control gates, documentation, metrics, decommissioning, reporting, integrated risk management และ secure operational practices ในระดับ วงจรชีวิต

เมื่ออ่านบทถัดไป ให้ติดตามว่า principle ถูกแปลงเป็น accountable activity และ evidence อย่างไร ใครเป็น risk owner จุดใดเป็น control gate และ metric ใดวัด effectiveness แทนการนับเพียง presence ของ control