1 การรักษาความปลอดภัยของ API คืออะไร?
บทนีครอบคลุมหัวข้อดังนี
 ความปลอดภัยของ API คืออะไร
 ความปลอดภัยโดยการออกแบบสําหรับ API คืออะไร
 ทําไมความปลอดภัยของ API จึงมีความสําคัญ
 เวกเตอร์การโจมตีใน API คืออะไร
 ความปลอดภัยของ API เข้ากับวงจรการพัฒนา API อย่างไร
 จะติดตามความก้าวหน้าในด้านความปลอดภัยของ API ได้อย่างไร
APIs อยู่ทกุ ที โดยคิดเป็ น 57% ของการใช้งานทราฟฟิ กบนเว็บทังหมด (https://www.cloudflare.com/2024-apisecurity-management-report/) APIs เป็ นเสมือนเครืองยนต์ทีขับเคลือนอินเทอร์เน็ต ทําให้องค์กรสามารถให้บริการผ่าน
อินเทอร์เฟซทีกําหนดไว้อย่างชัดเจน พวกมันช่วยขับเคลือนแอปพลิเคชันบนเว็บเบราว์เซอร์และมือถือ สนับสนุนการสือสาร
ระหว่างบริการต่าง ๆ เพิมความรวดเร็วในการทํางานอัตโนมัติ และสร้างอินเทอร์เฟซทีเป็ นมาตรฐานสําหรับแพลตฟอร์มหลัก ๆ
มากขึนเรือย ๆ องค์กรต่าง ๆ เริมตระหนักถึงประโยชน์ของ APIs ในการปรับปรุงบริการ อัตโนมัตกิ ระบวนการ และเปิ ดโอกาส
ทางธุรกิจใหม่ ๆ
แต่ประเด็นคือ APIs เป็ นเสมือนประตูเข้าสู่ระบบของเรา ทุกครังทีเราสร้าง API เราได้เปิ ดช่องทางให้ผใู้ ช้เข้าถึงข้อมูล
และฟั งก์ชนั ของระบบ แน่นอนว่านีคือเป้าหมายของ API: เพือเปิ ดเผยข้อมูลและฟังก์ชนั และเมือ APIs ถูกนําไปใช้และรักษา
ความปลอดภัยอย่างเหมาะสม APIs เป็ นสิงทีดี แต่ปัญหาคือ เมือ APIs ไม่ได้รบั การรักษาความปลอดภัยอย่างเหมาะสม
แฮกเกอร์ใช้ประโยชน์จาก APIs ทีไม่มีความปลอดภัยทีเพียงพอเพือเจาะเข้าสู่ระบบของเรา สิงนีนํามาซึงการละเมิด
ความปลอดภัย การละเมิดกฎหมายคุม้ ครองข้อมูลส่วนบุคคล เช่น กฎ GDPR ของยุโรป และค่าปรับจํานวนมากในอุตสาหกรรม
การเงินและการดูแลสุขภาพ APIs มีความจําเป็ นในการให้ระบบของเราทํางานต่อไปได้ แต่พวกมันก็อาจสร้างความเสียงต่อ
ธุรกิจและชือเสียงของเราได้เช่นกัน
รายงานเทรนด์ดา้ นความปลอดภัย API ของ Salt Security ในไตรมาสแรกของปี 2023 พบว่าการโจมตี API เพิมขึนถึง
400% ในไตรมาสแรกของปี 2023 ตามการวิจยั ของ Akamai ในปี 2022 องค์กรต่าง ๆ ประสบกับการโจมตีทางไซเบอร์มากกว่า
9
พันล้านครัง
โดยบางองค์กรเผชิญกับการโจมตีมากกว่า
10
ล้านครังต่อวัน
(https://www.akamai.com/blog/security/attack-surface-workout-web-application-api-attacks) และการละเมิด API
ไม่ได้มีราคาถูก โดยค่าเฉลียความเสียหายจากการละเมิด API อยู่ที 6.1 ล้านดอลลาร์สหรัฐ ตามรายงานการวิจยั ของ Kong
(https://konghq.com/blog/enterprise/apis-are-mission-critical)
คําถามทีชัดเจนคือ เราจะจัดการกับความปลอดภัยของ API อย่างไร? เราต้องทําอะไรเพือให้แน่ใจว่า APIs ของเรามี
ความปลอดภัย? หากคําถามเหล่านีกําลังรบกวนใจคุณ คุณมาถูกทีแล้ว
ในบทนี คุณจะได้เรียนรูว้ ่า API Security คืออะไร และทําไมมันถึงมีความสําคัญ คุณจะได้เรียนรูเ้ กียวกับช่องทางการ
โจมตีใน API และตามทีคุณจะได้คน้ พบ การรักษาความปลอดภัย API ไม่ได้มีแค่เรืองการยืนยันตัวตน (authentication) และ
การให้สิทธิการเข้าถึง (authorization) แต่ยงั มีรายละเอียดอืน ๆ ทีต้องพิจารณาอีกมากมาย คุณจะได้เรียนรูว้ ่า Security-byDesign คืออะไร และวิธีนาํ มาปรับใช้กบั APIs สุดท้าย คุณจะได้เรียนรูว้ ่า API Security เข้ากับวงจรการพัฒนา API ได้อย่างไร
และวิธีการติดตามให้ทนั กับการเปลียนแปลงอย่างรวดเร็วในด้านความปลอดภัยของ API
1.1 ความปลอดภัยของ API คืออะไร?
ความปลอดภัยของ API (API Security) เป็ นสาขาทีศึกษาเกียวกับช่องโหว่ของ API และวิธีการป้องกัน ช่องโหว่เหล่านี
ครอบคลุมทุกส่วนของแอปพลิเคชันและระบบทีมีผลต่อความปลอดภัยของ API เช่น การยืนยันตัวตน (authentication) การให้
สิทธิการเข้าถึง (authorization) การจัดการข้อมูลทีผูใ้ ช้ป้อน (user input manipulation) การตรวจสอบความถูกต้องของข้อมูล
(data validation) และอืน ๆ รูปที 1.1 แสดงภาพรวมของสาขาความปลอดภัย API ใช้เวลาสักครูเ่ พือศึกษารูปนีอย่างละเอียด
เนืองจากเป็ นตัวแทนของแนวคิดพืนฐานสําหรับหัวข้อในหนังสือเล่มนี
รูปที . สาขาความปลอดภัยของ API ครอบคลุมทุกสิงทีอาจส่งผลต่อความปลอดภัยของ API ของเรา รวมถึงการออกแบบ API (API
design) การนําไปใช้งาน (implementation) สถาปั ตยกรรม (architecture) และโครงสร้างพืนฐาน (infrastructure) ทุกองค์ประกอบเหล่านีมี
บทบาทสําคัญในการรักษา API ของเราให้ปลอดภัยและมันคง
คําจํากัดความ
ความปลอดภัยของ API (API Security) คือการศึกษาช่องโหว่ของ API และวิธีการจัดการกับช่องโหว่เหล่านัน ความ
ปลอดภัยของ API ทีดีจะต้องมีการมองภาพรวม (holistic approach) และครอบคลุมทุกองค์ประกอบในระบบทีอาจ
ส่งผลต่อความปลอดภัยของ API เช่น การออกแบบ API (API design) การจัดการข้อมูลทีผูใ้ ช้ป้อน (user input
manipulation) การใช้ไลบรารีและการพึงพาภายนอก (external libraries and dependencies) หรือการป้องกัน
ฐานข้อมูล (database protection)
ความปลอดภัยของ API ทีดีตอ้ งการมุมมองแบบองค์รวม (holistic view) ต่อ API ของเรา ดังทีคุณเห็นในรูปที 1.1 ช่อง
ทางการโจมตีทกุ ประเภทใน API ล้วนมีความเกียวข้องกับความปลอดภัยของ API ซึงรวมถึงองค์ประกอบต่าง ๆ เช่น การนํา API
ไปใช้งาน (API implementation) การจัดการการกําหนดค่า (configuration management) และโครงสร้างพืนฐาน
(infrastructure) ทีใช้ในการปฏิบตั ิการของ API ยกตัวอย่างเช่น API ส่วนใหญ่ใช้ฐานข้อมูลเพือเก็บข้อมูลอย่างถาวร และหาก
เกิดช่องโหว่ในความปลอดภัยของฐานข้อมูลก็จะทําให้ความปลอดภัยของ API ถูกทําลาย ดังนัน ความปลอดภัยของข้อมูลและ
ฐานข้อมูลจึงมีความสําคัญต่อความปลอดภัยของ API
นอกจากนี ดังทีคุณเห็นในรูปที 1.1 การออกแบบ API ทีดีจะช่วยส่งเสริมให้เราจัดการกับปั ญหาด้านความปลอดภัย
ตังแต่เนิน ๆ ในระยะการออกแบบ (design stage) ซึงสิงนีเรียกว่า "ความปลอดภัย API แบบ shift-left" (shift-left API security)
และคุณจะได้เรียนรูเ้ พิมเติมเกียวกับแนวคิดนีในบทที 3 และบทที 5
รูปที . ในการรักษาความปลอดภัยให้กบั API ของเรา ขันแรกเราจะต้องระบุชอ่ งทางการโจมตี (attack vectors) เช่น การออกแบบ API
(API design) และฐานข้อมูล (database) จากนันเราจําลองภัยคุกคามทีอาจเกิดขึน (model the possible threats) และสุดท้ายเราจะเพิม
ความปลอดภัยให้กบั API ของเราโดยใช้มาตรการทีป้องกันการโจมตีเหล่านัน
ดังทีคุณเห็นในรูปที 1.2 งานของเราคือการระบุทุกส่วนของระบบทีอาจส่งผลต่อความปลอดภัยของ API จําลองภัย
คุกคามทีอาจเกิดขึน และนํามาตรการรักษาความปลอดภัยทีเหมาะสมมาใช้ โดยกระบวนการจะเป็นดังนี:
1. การระบุชอ่ งทางการโจมตี (Identifying attack vectors): เราจะตรวจสอบทุกองค์ประกอบในระบบทีอาจ
ส่งผลกระทบต่อสถานะความปลอดภัยของ API โดยต้องมองภาพรวมของ API อย่างรอบด้าน ทังการนํา API
ไปใช้งาน (implementation) โครงสร้างพืนฐาน (infrastructure) ทีใช้ในการปฏิบตั ิการของ API การออกแบบ
(design) ระบบการยืนยันตัวตน (authentication system) การจัดการการกําหนดค่า (configuration
management) และอืน ๆ ทุกองค์ประกอบทีผูใ้ ช้สามารถเข้าถึงได้โดยตรงถือเป็ นช่องทางการโจมตี
2. การจําลองภัยคุกคามใน API (Modelling API threats): ในขันตอนนี เราจะระบุวา่ มีการโจมตีประเภทใดบ้างที
อาจเกิดขึน โดยการจําลองภัยคุกคามทีดีจะต้องชัดเจนเกียวกับประเภทของการโจมตี วิธีการโจมตี และ
ผลกระทบทีอาจเกิดขึนต่อแอปพลิเคชันและธุรกิจ การวิเคราะห์นีมีความสําคัญอย่างมาก เพราะเป็ นข้อมูล
พืนฐานทีใช้กาํ หนดมาตรการรักษาความปลอดภัย
3. การรักษาความปลอดภัย API (Securing APIs): ในขันตอนนี เรานําผลการวิเคราะห์จากขันตอนก่อนหน้ามา
ปฏิบตั ิจริงเพือจัดการกับช่องโหว่ต่าง ๆ ตัวอย่างเช่น หากพบช่องโหว่ในการออกแบบ API เราจะปรับปรุงการ
ออกแบบให้มคี วามปลอดภัยมากขึน เราตรวจสอบให้แน่ใจว่ามีการจัดการข้อมูลทีผูใ้ ช้ป้อนในทุกจุดของ API
อย่างระมัดระวัง หากเราพบว่าฐานข้อมูลมีความเสียง เราจะย้ายฐานข้อมูลไปยังเครือข่ายส่วนตัว (private
network) และเปลียนข้อมูลรับรองการเข้าถึง (access credentials) อย่างสมําเสมอ
ในบทถัดไป คุณจะได้เรียนรูว้ ธิ ีการปกป้องทุกชันของระบบ API ของคุณอย่างเหมาะสมและมีประสิทธิภาพ
เราจะพูดถึงการจําลองภัยคุกคาม (threat modelling) ในรายละเอียดเพิมเติมในหัวข้อ 2.2 สําหรับคําถามในตอนนีคือ
เราจะระบุช่องทางการโจมตี (attack vectors) ในระบบของเราได้อย่างไร? โดยมีสองกลยุทธ์ทสามารถใช้
ี
ได้:
1. การใช้การทดสอบอัตโนมัติ (using automated testing)
2. การวิเคราะห์ดว้ ยตนเอง (doing manual analysis)
เราจะพูดถึงการทดสอบอัตโนมัตใิ นบทที 12 และในส่วนนีจะมุง่ เน้นไปทีการวิเคราะห์ดว้ ยตนเอง (manual
รูปที . ในการวิเคราะห์ช่องทางการโจมตี (attack vectors) เราจะพิจารณาจากสามแกนของความปลอดภัย API ได้แก่ การออกแบบ API
(API design) การนําไปใช้งาน (implementation) และสถาปัตยกรรม (architecture) เราตังคําถามกับตัวเองว่า ช่องโหว่ทีเราเปิ ดเผยในแต่ละ
แกนคืออะไร ลักษณะของช่องโหว่เหล่านันเป็ นอย่างไร และผลกระทบทีจะเกิดขึนมีอะไรบ้าง
ดังทีคุณเห็นในรูปที 1.3 การแบ่งการวิเคราะห์ช่องทางการโจมตี (attack vectors) ออกเป็ นสามชันช่วยให้การวิเคราะห์มี
ประสิทธิภาพมากขึน เราเรียกชันเหล่านีว่า สามแกนของความปลอดภัย API (three axes of API security):
 การออกแบบ API (API design): การออกแบบ API อาจเปิ ดเผยช่องโหว่ได้บ่อยครังในรูปแบบทีคาดไม่ถงึ
ตัวอย่างเช่น การใช้อินทิเจอร์แบบไม่มีขอบเขต (unbound integers) อาจนําไปสู่การโจมตีแบบ big integer
attacks; การเปิ ดเผย integer ID ทําให้การโจมตีแบบเจาะผิวหน้า (surface attacks) ง่ายขึน และการไม่มีการ
จัดการหน้าข้อมูลทีเหมาะสม (pagination) ทําให้ระบบเสียงต่อการทํางานหนักเกินไป (overloads) คุณจะได้
เรียนรูเ้ พิมเติมเกียวกับช่องโหว่เหล่านีในบทที 5 และวิธีการจัดการกับปั ญหาเหล่านี
 การนํา API ไปใช้งาน (API implementation): การนํา API ไปใช้งานเป็ นแหล่งทีมาหลักของช่องโหว่ ดังนันเรา
จึงต้องใส่ใจกับโค้ดอย่างระมัดระวังและทําการทดสอบอย่างละเอียด การปฏิบตั ิตามแนวทางปฏิบตั ิทีดีทีสุด
(best practices) และการใช้รูปแบบทีมันคง เช่น Data Transfer Objects (DTOs) การตรวจสอบความถูกต้อง
ของข้อมูลทีรับเข้าและส่งออก (data validation for incoming and outgoing payloads) และการใช้
พารามิเตอร์สาํ หรับการส่งคําสังฐานข้อมูลทังหมด (parametrizing database queries) จะช่วยลดช่องโหว่ได้
คุณจะได้เรียนรูว้ ิธีทาํ ให้การนํา API ไปใช้งานปลอดภัยในบทที 3 และบทที 12
 สถาปัตยกรรม (Architecture): สถาปัตยกรรมของระบบมีผลกระทบอย่างมากต่อความปลอดภัยของ API
โดยรวมถึงองค์ประกอบต่าง ๆ เช่น โครงสร้างเครือข่าย (network topology) การจัดเก็บข้อมูล (data storage)
ทรัพยากรการประมวลผล (computing resources) ตัวกระจายโหลด (load balancers) และ API Gateways
วิธีการแก้ไขปัญหาด้านสถาปัตยกรรมจะกําหนดว่า API ของเราสามารถขยายตัว (scale) ได้อย่างไร ข้อมูล
สําคัญสามารถเข้าถึงได้จากเครือข่ายสาธารณะหรือเครือข่ายส่วนตัวหรือไม่ และอืน ๆ คุณจะได้เรียนรูเ้ พิมเติม
เกียวกับการออกแบบสถาปั ตยกรรม API ทีปลอดภัยในบทที 8
 การปฏิบตั ิการ (Operations): การปฏิบตั ิการมีบทบาทสําคัญในการรักษาความปลอดภัยไซเบอร์ ซึงรวมถึง
การเฝ้าระวัง API อย่างใกล้ชดิ และการวิเคราะห์การโต้ตอบของผูใ้ ช้เพือตรวจจับพฤติกรรมทีเป็ นอันตราย
รวมถึงการระบุและควบคุมการละเมิดความปลอดภัยให้เร็วทีสุด คุณจะได้เรียนรูว้ ิธีการติดตังระบบเฝ้าระวัง
และตรวจจับภัยคุกคามสําหรับ API ของคุณในบทที 12 และบทที 13
หมายเหตุ
สามแกนของความปลอดภัย API (The three axes of API security) เป็ นกรอบแนวคิดสําหรับการวิเคราะห์ช่องโหว่ใน
API ของเรา สามแกนนีประกอบด้วย: การออกแบบ API (API design) การนําไปใช้งาน (implementation) และ
สถาปัตยกรรม (architecture) แต่ละแกนมีช่องโหว่เฉพาะตัวทีแตกต่างกัน และเราจําเป็ นต้องวิเคราะห์วา่ ผูไ้ ม่หวังดี
สามารถใช้ประโยชน์จากช่องโหว่เหล่านีเพือสร้างความเสียหายต่อระบบของเราได้อย่างไร
นอกเหนือจากองค์ประกอบเหล่านี ยังมีพนที
ื อืน ๆ ทีเราต้องพิจารณา เช่น การจัดการการกําหนดค่าและความลับ
(configuration and secrets management) การจํากัดอัตราการใช้งาน (rate-limiting) การจัดการเวอร์ชนั ของ API (API
versioning) และอืน ๆ ตลอดหนังสือเล่มนี คุณจะได้เรียนรูว้ ิธีระบุช่องโหว่ดา้ นความปลอดภัยในองค์ประกอบเหล่านีทังหมด
และวิธีจดั การกับช่องโหว่เหล่านันอย่างเหมาะสม
1.2 ความปลอดภัย API โดยการออกแบบคืออะไร?
ความปลอดภัยโดยการออกแบบ (Security by design) เป็ นแนวคิดในด้านความปลอดภัยไซเบอร์ทีหมายถึงการทําให้
ซอฟต์แวร์ของเรามีความปลอดภัยตังแต่พนฐาน
ื
ดังทีคุณเห็นในรูปที 1.4 ความปลอดภัยโดยการออกแบบหมายถึงการเลือน
ความกังวลด้านความปลอดภัยไปทางซ้าย (shift-left) นันคือการเริมต้นตังแต่ตน้ กระบวนการ ในระยะการออกแบบ (design
stage) เป้าหมายคือการระบุและจัดการช่องโหว่ดา้ นความปลอดภัยตังแต่เนิน ๆ เพือหลีกเลียงปัญหาทีไม่คาดคิดเมือโค้ดของ
เราถูกนําไปใช้งาน (deployed)
รูปที . ในวิธีการแบบดังเดิมสําหรับความปลอดภัยของ API เรามักรอจนกว่าจะถึงขันตอนการปรับใช้ (deployment) เพือรันการทดสอบ
และค้นหาช่องโหว่ ซึงมักทําให้พบช่องโหว่นบั ร้อย และเราต้องย้อนกลับไปทีจุดเริมต้นของกระบวนการหลายครังเพือแก้ไขปั ญหาเหล่านัน แต่
ด้วยแนวทางความปลอดภัยโดยการออกแบบ (security by design) เราให้ความสําคัญกับความปลอดภัยในทุกขันตอนของวงจรการพัฒนา
(development cycle) ส่งผลให้เกิดปัญหาน้อยลงเมือเราทําการทดสอบหลังการปรับ
คําจํากัดความ
ความปลอดภัยของ API โดยการออกแบบ (API security by design) เป็ นแนวทางทีนําประเด็นด้านความปลอดภัยมา
พิจารณาในกระบวนการพัฒนาตังแต่ระยะการออกแบบ (design stage) และตลอดทังวงจรการพัฒนา API (API
development cycle) เพือให้มนใจว่
ั าการนําไปใช้งานและกระบวนการส่งมอบ API มีความปลอดภัย วิธีการนีเรียกอีก
อย่างว่า "การเลือนความปลอดภัยไปทางซ้าย" (shifting left on security)
แนวทางเดียวกันนีสามารถนํามาใช้กบั API ได้เช่นกัน ก่อนทีเราจะสร้าง API เราต้องออกแบบมันเสียก่อน ซึงในระยะนี
ถือเป็ นโอกาสทีดีในการเริมจัดการกับช่องโหว่ อย่างไรก็ตาม ความปลอดภัยโดยการออกแบบ (secure by design) ไม่ได้ใช้
เฉพาะกับการออกแบบ API เท่านัน แต่ยงั รวมถึงการออกแบบ การนําไปใช้งาน (implementation) และการแก้ปัญหาด้าน
สถาปัตยกรรม (architectural solution) ทีมันคงปลอดภัยตังแต่เริมต้น ทังนี การนําแนวคิดนีไปปฏิบตั ิจริงหมายความว่า
อย่างไร? มาดูกนั ว่า ความปลอดภัยโดยการออกแบบ ทํางานอย่างไรในแต่ละแกนของความปลอดภัย API
1.2.1 การออกแบบ API (API design)
แนวปฏิบตั ิทีดีทีสุดคือการเริมต้นวงจรการพัฒนา API ด้วยระยะการออกแบบ (design stage) ซึงเรียกว่า API-first หรือ
ทีเฉพาะเจาะจงกว่านันคือ API design first วิธีนช่ี วยให้ทีมพัฒนาและผูม้ ีส่วนได้ส่วนเสียในธุรกิจสามารถตกลงกันได้เกียวกับ
วิธีการทํางานของ API ก่อนทีจะเริมงานใด ๆ ทังในฝั งผูผ้ ลิต (producer) หรือผูบ้ ริโภค (consumer)
ตามรายงาน State of the API Report ปี 2023 ของ Postman (https://www.postman.com/state-of-api/api-firststrategies/) พบว่า 75% ของผูต้ อบแบบสอบถามเห็นด้วยว่าแนวทาง API-first ช่วยให้นกั พัฒนาสามารถส่งมอบ API ทีดียงขึ
ิ น
ได้เร็วขึน การใช้ API design first ช่วยสร้างความสอดคล้องระหว่างซอฟต์แวร์และเป้าหมายทางธุรกิจ และยังช่วยให้สามารถ
พัฒนาไคลเอนต์และเซิรฟ์ เวอร์ของ API ได้อย่างอิสระต่อกัน
หมายเหตุ
มีการถกเถียงกันอย่างมากเกียวกับความหมายของแนวคิด API-first และ API-design first รวมถึงวิธีทีดีทีสุดในการนําไป
ปฏิบตั ิจริง หากคุณต้องการข้อมูลเชิงลึกเพิมเติมเกียวกับประเด็นนี ลองดูบทความของ David Biesack เรือง “API
Design First is not API Design First” (15 กุมภาพันธ์ 2023, API Design Matters,
https://apidesignmatters.substack.com/p/api-design-first-is-not-api-design) และการบรรยายของ Daniel Kocot
เรือง “API First… Not” ในงาน 2023 Platform Summit ทีจัดขึนระหว่างวันที 16-18 ตุลาคม 2023 ณ กรุงสตอกโฮล์ม
(https://youtu.be/aJsmK3XRjjY)
การเริมต้นวงจรการพัฒนา API ด้วยระยะการออกแบบ (design stage) ยังเป็ นประโยชน์ในมุมมองด้านความปลอดภัย
อีกด้วย การเริมต้นด้วยการออกแบบช่วยให้เรามีโอกาสทําให้ API ของเรามีความแข็งแกร่งและปลอดภัยตังแต่ก่อนทีเราจะเริม
ลงมือพัฒนา
ทําไมสิงนีจึงสําคัญ? องค์กรหลายแห่งมักรอจนกระทัง API ถูกปรับใช้ในสภาพแวดล้อมการพัฒนาหรือการทดสอบ
(development/test environment) ก่อนทีจะดําเนินการทดสอบความปลอดภัยของ API กล่าวอีกนัยหนึงคือ องค์กรส่วนใหญ่
ปฏิบตั ิต่อความปลอดภัยเหมือนเป็ นปั ญหาในระหว่างการทํางาน (runtime issue) ซึงเป็ นคุณลักษณะทีสามารถทดสอบได้
เฉพาะกับแอปพลิเคชันทีกําลังทํางานอยู่เท่านัน แต่นีเป็ นมุมมองทีค่อนข้างสันเกียวกับความปลอดภัย
ตามทีคุณจะได้เรียนรูใ้ นหนังสือเล่มนี ยังมีสงที
ิ สามารถทําได้มากมายจากมุมมองของการออกแบบเพือให้มนใจว่
ั า API
ของเรามีความปลอดภัยและเชือถือได้ การจัดการกับปั ญหาด้านความปลอดภัยตังแต่ระยะการออกแบบ ช่วยให้เราสามารถ
เลือนแนวทางด้านความปลอดภัยไปทางซ้าย (shift-left) และส่งมอบ API ทีมีความปลอดภัยตังแต่การออกแบบ (secure by
design)
เคล็ดลับ
ช่องโหว่ของ API จํานวนมากสามารถจัดการได้ในระยะการออกแบบ การออกแบบ API ให้มคี วามปลอดภัยช่วยลด
จํานวนช่องโหว่ทีพบในระหว่างการทดสอบในระยะการทํางาน (runtime testing) ซึงหมายความว่าเรามีโอกาสน้อยที
จะต้องย้อนกลับมาทําวงจรการพัฒนา API ใหม่ทงหมดเพื
ั
อแก้ไขปัญหาเหล่านี ดังนัน อย่ารอจนถึงขันตอนการปรับใช้
(deployment) เพือเริมทดสอบความปลอดภัย!
จากมุมมองของการออกแบบ (design point of view) เราต้องการให้แน่ใจว่า เอนด์พอยต์ (endpoints) ของ API เปิ ดเผย
การดําเนินการ (operations) ทีกําหนดไว้อย่างชัดเจน เราควรใช้รูปแบบการออกแบบ API ทีดี เช่น การจัดการหน้าข้อมูล
(pagination) หลีกเลียงการเปิ ดเผย Resource IDs ทีคาดเดาได้งา่ ย เช่น อินทิเจอร์ทีเพิมขึนตามลําดับ (incremental integers)
หลีกเลียงโครงสร้างข้อมูล (data schemas) ทียืดหยุ่นมากเกินไปซึงทําให้การตรวจสอบความถูกต้องของข้อมูล (data
validation) ทําได้ยาก และจํากัดการป้อนข้อมูลของผูใ้ ช้ให้มากทีสุดเท่าทีจะเป็ นไปได้เพือลดโอกาสในการแทรกโค้ดทีเป็ น
อันตราย (malicious code injection) คุณจะได้เรียนรูเ้ พิมเติมเกียวกับหัวข้อนีในบทที 5
1.2.2 การใช้งาน API
เมือเราออกแบบ API เสร็จแล้ว ขันตอนต่อไปคือการใช้งานจริง ในขันตอนนี สิงสําคัญคือการเลือกใช้ไลบรารีทีมีความ
แข็งแกร่งและเสถียร ซึงช่วยให้การใช้งาน API มีความปลอดภัยมากขึน ภาษาส่วนใหญ่มเี ฟรมเวิรก์ เฉพาะสําหรับ API เช่น
FastAPI
สําหรับ
Python
(https://github.com/fastapi/fastapi),
FeathersJS
สําหรับ
Node
(https://github.com/feathersjs/feathers) หรือ Spring สําหรับ Java (https://github.com/spring-projects/springframework)
จากมุมมองการใช้งาน เราต้องการให้โค้ดของเราสอดคล้องกับข้อกําหนดของ API อย่างถูกต้อง เพือให้มนใจในความ
ั
สอดคล้องนี เราทําการทดสอบการใช้งานกับข้อกําหนดดังกล่าว เราเรียกวิธีการนีว่า การทดสอบสัญญา (contract-testing) วิธี
ทีได้รบั ความนิยมในการทดสอบสัญญาคือการใช้เครืองมือ
fuzz
testers
เช่น
Schemathesis
(https://github.com/schemathesis/schemathesis/) และ restler-fuzzer (https://github.com/microsoft/restler-fuzzer)
ตามทีคุณจะได้เรียนรูใ้ นบทที 12 fuzz testers เป็ นเครืองมือทีสร้าง payload ทังทีถูกต้องและไม่ถกู ต้องเพือทดสอบว่า API
จัดการกับ payload เหล่านันอย่างไร
คําแนะนํา
อย่าทําสิงเดิมซําใหม่! ใช้เฟรมเวิรก์ สําหรับการพัฒนา API เพราะเฟรมเวิรก์ เหล่านีมาพร้อมกับฟังก์ชนั ในตัวทีช่วยให้งาน
ด้านการตรวจสอบความถูกต้องของข้อมูล (data validation) และการจัดรูปแบบข้อมูล (data serialization) เป็ นเรืองง่าย
ขึน ทําให้คุณมีงานทีต้องทําลดลง จงใช้แนวทาง zero-trust โดยการตรวจสอบและล้างข้อมูลทังหมดให้ปลอดภัย และ
อย่าลืมตรวจสอบการใช้งานด้วย fuzz testers!
ใช้รูปแบบทีได้รบั การยอมรับอย่างดีเพือถ่ายโอนและล้างข้อมูลระหว่างเลเยอร์ของแอปพลิเคชัน ตัวอย่างเช่น การใช้
Data Transfer Objects (DTOs) ช่วยให้เราถ่ายโอนเฉพาะข้อมูลทีจําเป็ นจากเลเยอร์ API ไปยังเลเยอร์ธุรกิจและฐานข้อมูล
และจากฐานข้อมูลไปยังเลเยอร์อนๆ
ื นอกจากนี ยังสําคัญทีจะต้องใช้การพารามิเตอร์ไลซ์ (parameterize) กับคําสังฐานข้อมูล
ทังหมดเพือลดความเสียงจาก SQL injection สุดท้าย เราต้องใช้แนวทาง zero-trust โดยการตรวจสอบความถูกต้องของข้อมูล
อย่างละเอียดไม่ว่าจะมีแหล่งทีมาใดก็ตาม
1.2.3 สถาปั ตยกรรม
สถาปั ตยกรรมคือการผสมผสานของตัวเลือกทีเราตัดสินใจเพือทําให้ API สามารถทํางานได้จริง เราต้องตัดสินใจว่าควร
ใช้ฐานข้อมูลประเภทใด เซิรฟ์ เวอร์และรูปแบบการปรับใช้งานแบบใด และจะกําหนดค่าโครงสร้างเครือข่าย ทอปอโลยี ไฟร์
วอลล์ และอืนๆ อย่างไร
ในขันตอนนี เรามีโอกาสทีจะทําให้การตังค่าของเรามีความปลอดภัยตังแต่แรกเริม ตัวอย่างเช่น เราสามารถวาง
ฐานข้อมูลไว้ในเครือข่ายส่วนตัว (private network) เพือป้องกันการเข้าถึงจากภายนอกระบบของเรา เราควรกําหนดค่าไฟร์
วอลล์ให้มีขอ้ จํากัดสูงสุด โดยอนุญาตให้เข้าถึงได้เฉพาะจากแหล่งทีเชือถือได้เท่านัน เราต้องเลือกรูปแบบการปรับใช้งานที
สามารถปรับขนาดได้เพือตอบสนองความต้องการของผูใ้ ช้ API นอกจากนี เรายังต้องการส่วนประกอบทีเผชิญหน้ากับผูใ้ ช้ เช่น
ตัวจัดการโหลด (load balancer) หรือ API Gateway ทีสามารถจัดการการควบคุมปริมาณการใช้งาน (throttling) และการ
จํากัดอัตรา (rate-limiting)
คําแนะนํา
สถาปั ตยกรรมและโครงสร้างพืนฐานมีบทบาทสําคัญในการปกป้อง API ของเรา เมือได้รบั การออกแบบอย่างเหมาะสม
ใช้ประโยชน์จากโครงสร้างเครือข่ายทีปลอดภัย (secure network topologies) เพือจํากัดการเข้าถึงทรัพยากรทีมี
ความสําคัญ และใช้เทคโนโลยี เช่น ตัวจัดการโหลด (load balancers) และ API Gateways เพือจัดการกับทราฟฟิ กทีเข้า
มาอย่างปลอดภัย
สิงสําคัญคือต้องสามารถทําซําสถาปั ตยกรรมของเราได้อย่างแม่นยําในสภาพแวดล้อมต่างๆ
โดยการใช้โครงสร้าง
พืนฐานในรูปแบบโค้ด (infrastructure as code) เป็ นเครืองมือช่วย เราสามารถใช้เครืองมือ เช่น Terraform, CloudFormation
หากคุณปรับใช้งานบน AWS หรือ Cloud Build หากคุณใช้ Google Cloud เพือทําให้โครงสร้างพืนฐานเป็ นแบบอัตโนมัติใน
รูปแบบโค้ด คุณจะได้เรียนรูเ้ พิมเติมเกียวกับแนวปฏิบตั ิทีดีทีสุดด้านสถาปัตยกรรมในบทที 8
1.3 ทําไมความปลอดภัยของ API จึงสําคัญ?
เราได้อธิบายไปแล้วว่าความปลอดภัยของ API คืออะไร แต่ทาํ ไมมันถึงมีความสําคัญ? API เปรียบเสมือนประตูเข้าสู่
ระบบของเรา ซึงหมายความว่า API ช่วยให้ผใู้ ช้งานสามารถเข้าถึงข้อมูลและฟังก์ชนั การทํางานจากบริการของเราได้ หาก API
ของเราไม่ได้รบั การป้องกันอย่างเหมาะสม อาจเปิ ดช่องให้ผไู้ ม่ประสงค์ดีเข้าถึงข้อมูลและการดําเนินการทีพวกเขาไม่ควรเข้าถึง
ทําให้เซิรฟ์ เวอร์ของเราล่ม เกิดพฤติกรรมทีไม่พงึ ประสงค์ และส่งผลเสียต่อธุรกิจของเรา
จากรายงาน State of Software Quality | API 2023 ของ SmartBear ระบุวา่ ความปลอดภัยของ API เป็ นประเด็นสําคัญ
อันดับ 2 ขององค์กรต่างๆ โดยเฉพาะในธุรกิจทีเกียวข้องกับการเงิน การธนาคาร การประกันภัย การป้องกันประเทศ และ
อุตสาหกรรมทีเกียวข้องกับข้อมูลทีมีความสําคัญ
ซึงจัดให้ความปลอดภัยของ
API
เป็ นเรืองสําคัญอันดับแรก
(https://smartbear.com/state-of-software-quality/api/) สิงที SmartBear พบนีไม่น่าแปลกใจ เนืองจากการโจมตี API มี
แนวโน้มเพิมขึน จากรายงาน State of API Security Q1 2023 ของ Salt Security พบว่าการโจมตี API เพิมขึนถึง 400% ในไตร
มาสแรกของปี 2023 (https://salt.security/api-security-trends) และตามข้อมูลของ Gartner คาดการณ์ว่า API จะกลายเป็ น
ช่องทางการโจมตีทีพบบ่อยทีสุดบนเว็บไซต์ [1] หากคุณใช้งาน API ในการผลิตหรือกําลังวางแผนทีจะใช้ API ความปลอดภัย
ควรเป็ นหนึงในลําดับความสําคัญสูงสุดของคุณ
API มักจะเปิ ดเผยข้อมูลทีสําคัญและกระบวนการทํางานของผูใ้ ช้ ซึงทําให้ API เป็ นเป้าหมายทีมีแนวโน้มจะถูกเจาะ
ระบบได้ง่าย ตัวอย่างเช่น เมือวันที 19 มกราคม 2023 T-Mobile ได้เปิ ดเผยว่าข้อมูลส่วนบุคคลทีสามารถระบุตวั ตนได้ (PII) ของ
ลูกค้า 37 ล้านราย ถูกขโมยไปเนืองจากการควบคุมการเข้าถึงทีไม่เหมาะสมและการตรวจสอบสิทธิทีอ่อนแอใน API ของพวก
เขา [2] การละเมิดความปลอดภัยเช่นนีอาจทําให้องค์กรของคุณต้องเสียค่าใช้จ่ายมหาศาล จากการวิจยั ของ Kong พบว่า
ค่าใช้จา่ ยเฉลียของการละเมิด API อยู่ที $6.1 ล้าน (https://konghq.com/blog/enterprise/apis-are-mission-critical)
เหตุการณ์ความปลอดภัยของ API ยังสามารถสร้างความเสียหายในรูปแบบทีไม่ชดั เจนนัก การไม่มีการจํากัดอัตราการ
ใช้งาน (rate-limiting) หรือการวัดผลการใช้งาน API (API metering) อาจเปิ ดโอกาสให้แฮ็กเกอร์ขโมยข้อมูลสําคัญจากเว็บไซต์
ของคุณได้ ในขณะเดียวกัน หากเราไม่สามารถตรวจจับกิจกรรมทีเป็ นอันตรายได้ แฮ็กเกอร์อาจทําลายโมเดลธุรกิจของเรา
ตัวอย่างภัยคุกคามทีพบบ่อยสําหรับเว็บไซต์อคี อมเมิรซ์ คือการสกัลปิ ง (scalping) ซึงเป็ นการซือสินค้าทังหมดในสต็อกทีมี
ความต้องการสูง เพือนําไปขายต่อในราคาทีแพงกว่า เราเห็นรูปแบบภัยคุกคามเช่นนีเกิดขึนทัวโลก ตัวอย่างเช่น ในสหราช
อาณาจักร หน่วยงานขับขีและยานพาหนะ (DVSA) ต้องรับมือกับผูใ้ ช้ทประสงค์
ี
รา้ ยทีซือช่องสอบใบขับขีทังหมดแล้วนําไปขาย
ต่อในราคาทีสูงกว่ามาก [3]
ปั ญหานีรุนแรงยิงขึนเมือองค์กรไม่มีความสามารถในการมองเห็นข้อมูลการใช้งานอย่างเหมาะสม องค์กรส่วนใหญ่ไม่มี
ตัวชีวัดเกียวกับการใช้งาน API และยิงไม่ตอ้ งพูดถึงการตรวจสอบกิจกรรมของผูใ้ ช้แบบเรียลไทม์ทีสามารถใช้ในการระบุ
พฤติกรรมทีเป็ นอันตราย จากรายงาน Cost of Data Breach Report 2024 ของ IBM ระบุว่า องค์กรต้องใช้เวลาเฉลีย 258 วัน
ในการระบุและควบคุมการละเมิดความปลอดภัย (https://newsroom.ibm.com/2024-07-30-ibm-report-escalating-databreach-disruption-pushes-costs-to-new-highs) ในสถานการณ์ที API ถูกโจมตีอยู่ตลอดเวลา สิงนีไม่อาจยอมรับได้อีก
ต่อไป เราสามารถและต้องทําให้ดีกว่านี และหนังสือเล่มนีจะสอนคุณถึงวิธีการ
เหตุการณ์ดา้ นความปลอดภัยของ API ไม่เพียงสร้างความเสียหายทางการเงินให้กับธุรกิจเท่านัน แต่ทีสําคัญยิงกว่านัน
คือ ทําลายชือเสียงขององค์กรคุณ หากลูกค้าไม่สามารถไว้วางใจในความสามารถของคุณในการจัดการข้อมูลของพวกเขา
อย่างปลอดภัย สุดท้ายพวกเขาจะเลิกใช้แพลตฟอร์มของคุณ
นอกเหนือจากความเสียหายทีเกิดขึนกับธุรกิจของเราแล้ว ลูกค้าคือผูท้ ีต้องรับผลกระทบในท้ายทีสุด เมือข้อมูลลูกค้าถูก
เปิ ดเผยหรือผูใ้ ช้งานทีไม่ประสงค์ดีสามารถเข้าถึงบัญชีของพวกเขาได้ ลูกค้าของเราจะต้องเผชิญกับผลกระทบทางการเงินและ
ส่วนตัว ในฐานะองค์กรด้านเทคโนโลยี คุณมีหน้าทีในการปกป้องข้อมูลของลูกค้า และการรักษาความปลอดภัยให้กับ API ของ
คุณอย่างเหมาะสมถือเป็ นส่วนหนึงของพันธกิจนี
API เป็ นทังความจําเป็ นและความเสียง เราต้องการ API เพือให้บริการเทคโนโลยีของเราสู่โลกภายนอก แต่ API ก็
สามารถเป็ นช่องทางทีทําลายโมเดลธุรกิจของเราได้เช่นกัน เพือให้ API ของเราสร้างคุณค่าให้กบั ธุรกิจโดยไม่ก่อให้เกิดความ
เสียหาย เราต้องรักษาความปลอดภัยให้กับ API อย่างเหมาะสม
1.4 ช่องทางการโจมตีทีไม่คาดคิด
ทําไมการโจมตี API ถึงพบได้บ่อยและยากต่อการจัดการ? ทังทีเราสร้าง API กันมาหลายสิบปี แล้ว แต่ความปลอดภัย
ของ API ยังคงเป็ นสิงทีเข้าใจกันได้นอ้ ยเมือเทียบกับเว็บไซต์แบบดังเดิม API เปิ ดเผยช่องทางการโจมตีใหม่ๆ และบางครังก็เป็ น
ช่องทางทีไม่คาดคิด ตัวอย่างเช่น API เปิ ดเผยพารามิเตอร์ผ่าน URL และ payload ของคําขอ (request payloads) ซึงค่าของ
พารามิเตอร์เหล่านีจะถูกส่งไปยังฐานข้อมูลโดยตรง สิงนีสร้างโอกาสทีไม่เหมือนใครให้กับผูโ้ จมตีในการใช้เทคนิค
injection และการโจมตีรูปแบบอืนๆ กับแอปพลิเคชันของเรา
SQL
รูปที . ทุกพารามิเตอร์อินพุตใน API ถือเป็ นช่องทางการโจมตี รวมถึง URL, พารามิเตอร์ใน query และ path, request headers และ
payloads การปล่อยให้ผใู้ ช้งานป้อนข้อมูลได้โดยไม่มกี ารจํากัด จะเปิ ดโอกาสให้แฮ็กเกอร์ส่งคําขอทีเป็ นอันตรายไปยัง API ของเรา เพือสร้าง
ความเสียหายต่อระบบหรือทําให้เกิดพฤติกรรมทีไม่คาดคิด
อย่างทีคุณเห็นในรูปที 1.5 ทุกพารามิเตอร์อินพุตใน API ของเราคือช่องทางการโจมตีทีอาจเกิดขึนได้ และดังทีคุณจะได้
เรียนรูใ้ นบทที 5 การไม่มีขอ้ จํากัดในพารามิเตอร์เหล่านียิงทําให้สถานการณ์แย่ลง เพือเข้าใจเหตุผล ลองพิจารณาตัวอย่างการ
แบ่งหน้า (pagination) การแบ่งหน้าคือความสามารถในการแบ่งชุดข้อมูลออกเป็ นส่วนย่อยๆ เพือให้เราสามารถประมวลผลได้
สะดวกและมีประสิทธิภาพมากขึน เราจําเป็ นต้องใช้การแบ่งหน้าใน endpoints ทีแสดงชุดข้อมูล เช่น แคตตาล็อกสินค้าบน
เว็บไซต์อคี อมเมิรซ์
รูปแบบการแบ่งหน้าทีดีชว่ ยให้ผใู้ ช้เลือกได้ว่าต้องการดูจาํ นวนไอเท็มต่อหน้าเท่าใด ต้องการดูหน้าทีเท่าไร ต้องการ
เรียงลําดับไอเท็มอย่างไร และต้องการกรองไอเท็มแบบไหน พารามิเตอร์อินพุตทังหมดนีเป็ นช่องทางการโจมตี ตัวอย่างเช่น เมือ
กรองไอเท็มในรายการ ผูโ้ จมตีอาจกําหนดค่าพารามิเตอร์ตวั กรองให้เป็ น payload สําหรับ SQL injection เช่น GET
/products?filter='; DROP TABLE users;-- หากค่าของพารามิเตอร์ตวั กรองถูกส่งเข้าไปในคําสังฐานข้อมูลโดยตรง อาจเกิด
ผลลัพธ์ทเลวร้
ี ายอย่างยิง
ผูโ้ จมตียงั สามารถใช้พารามิเตอร์อินพุตสําหรับการโจมตีประเภทอืนๆ ได้ เช่น การโจมตีดว้ ยจํานวนเต็มขนาดใหญ่ (big
integer attacks) ตัวอย่างเช่น เมือเลือกจํานวนไอเท็มต่อหน้า ค่าทีสมเหตุสมผลอาจเป็ น 10 หรือ 20 แต่ผใู้ ช้ทเป็
ี นอันตรายอาจ
ร้องขอ 100 ล้านไอเท็มต่อหน้า การร้องขอจํานวนไอเท็มจํานวนมากจาก API ของเราจะสร้างแรงกดดันมหาศาลต่อฐานข้อมูล
และอาจทําให้เว็บไซต์ของเราล่มได้
วัตถุประสงค์ของการโจมตี API ไม่ได้มีเพียงแค่การสร้างความเสียหายให้ฐานข้อมูลหรือทําให้เว็บไซต์ล่มเท่านัน ผูโ้ จมตี
ยังสามารถใช้ช่องโหว่เพือก่อให้เกิดพฤติกรรมทีไม่พึงประสงค์ในระบบหรือทําให้เกิดข้อผิดพลาด ตัวอย่างเช่น ในการแบ่งหน้า
(pagination) ของแคตตาล็อกสินค้า ผูใ้ ช้อาจร้องขอหน้าที -20 ในสถานการณ์นี เซิรฟ์ เวอร์อาจล่ม หรืออาจคืนชุดข้อมูลแบบสุ่ม
ให้กบั ผูใ้ ช้ ซึงอาจนําไปสู่การรัวไหลของข้อมูล
อีกหนึงช่องทางการโจมตีทีสําคัญคือ request payloads เราใช้ request payloads เพือส่งข้อมูลไปยังเซิรฟ์ เวอร์ผ่านคํา
ขอแบบ POST, PUT หรือ PATCH โดยทัวไปเพือสร้างหรืออัปเดตทรัพยากร ช่องโหว่ทีพบได้บ่อยใน request payloads คือการ
อนุญาตให้มีคณ
ุ สมบัติ (properties) เพิมเติม ตัวอย่างเช่น API ในฟิ นเทคอาจมี endpoint สําหรับทําและอัปเดตการชําระเงิน
โดยปกติแล้ว คําขอการชําระเงินจะผ่านการตรวจสอบบางอย่าง เช่น ตรวจสอบว่าบัญชีของคุณมีเงินเพียงพอสําหรับการชําระ
เงินหรือไม่ อย่างไรก็ตาม หาก request payloads อนุญาตให้มีคณ
ุ สมบัติเพิมเติม ผูโ้ จมตีทีเป็ นอันตรายอาจสามารถ
ปรับเปลียนสถานะของการชําระเงินและหลีกเลียงการตรวจสอบเหล่านีได้ น่าแปลกใจทีช่องโหว่นพบได้
ี
บ่อยใน API ของฟิ นเทค
[4]
ไม่เพียงแค่ขอ้ มูลทีผูใ้ ช้ป้อนเข้ามาเท่านันทีเป็ นปั ญหา แต่การกําหนดสิทธิ (authorization) ก็เป็นเรืองทีท้าทายมากขึน
ใน API โดยปกติแล้ว เราใช้โทเคนแบบไร้สถานะ (stateless tokens) ในการกําหนดสิทธิ API ซึงเป็ นโทเคนทีมีขอ้ มูลทังหมดที
เราต้องใช้ในการยืนยันว่าผูใ้ ช้สามารถเข้าถึง API ได้ แต่เราจะบอกได้อย่างไรว่าโทเคนไหนถูกต้องและโทเคนไหนไม่ถกู ต้อง?
ตามทีคุณจะได้เรียนรูใ้ นบทที 6 โทเคนสําหรับการเข้าถึง (access tokens) มีส่วนประกอบพิเศษทีเรียกว่า signature ซึงบอกเรา
ว่าโทเคนนันถูกต้องหรือไม่ การใช้วธิ ีการเซ็นชือ (signing algorithms) ทีแข็งแกร่งและตรวจสอบลายเซ็นของโทเคนอย่าง
ถูกต้องเป็ นสิงสําคัญอย่างยิง แม้ว่าจะดูเหมือนเป็ นเรืองพืนฐาน แต่หลายองค์กรกลับล้มเหลวในการตรวจสอบลายเซ็นของโท
เคนอย่างเหมาะสม ตัวอย่างเช่น Auth0 (https://apisecurity.io/issue-81-vulnerabilities-microsoft-teams-auth0-smarthome-hubs/) และ Microsoft (https://apisecurity.io/issue-115-vulnerabilities-solarwinds-ledger-outlook-new-pluginjetbrains-ides/) ก็เคยมีกรณีลกั ษณะนีเช่นกัน
API บางตัวใช้ endpoint หรือพารามิเตอร์เฉพาะสําหรับการเข้าถึงของผูด้ แู ลระบบ (admin access) ตัวอย่างเช่น API
อาจมี endpoint สําหรับผูด้ แู ลระบบอยู่ภายใต้เส้นทาง URL เช่น example.com/admin หรือในโดเมนย่อยของผูด้ แู ลระบบ เช่น
admin.example.com ขณะทีบาง API ใช้ header พิเศษ เช่น X-User: admin เพือระบุผใู้ ช้ทีเป็ นผูด้ แู ลระบบ กลยุทธ์เหล่านีไม่
มีสงใดผิ
ิ ดพลาดโดยตัวมันเอง ตราบใดทีเราใช้การกําหนดสิทธิการเข้าถึงทีแข็งแกร่งใน endpoint เหล่านัน อย่างไรก็ตาม API
จํานวนมากถูกสร้างขึนภายใต้สมมติฐานว่ามีเพียงผูใ้ ช้ทีถูกต้องเท่านันทีจะเข้าถึง endpoint ของผูด้ ูแลระบบได้ ซึงแน่นอนว่า
สิงนีเปิ ดโอกาสให้เกิดการละเมิดการเข้าถึงผูด้ แู ลระบบ
อีกหนึงช่องโหว่ทีเกิดขึนในช่วงไม่กีปี ทีผ่านมาเรียกว่า
การเข้าถึงกระบวนการทางธุรกิจทีสําคัญโดยไม่มีขอ้ จํากัด
(unrestricted access to sensitive business flows) (https://owasp.org/API-Security/editions/2023/en/0xa6unrestricted-access-to-sensitive-business-flows/) ช่องโหว่นีเกิดขึนเมือผูใ้ ช้ทเป็
ี นอันตรายใช้ API ของเราในทางทีผิดเพือ
แสวงหาประโยชน์จากโมเดลธุรกิจของเรา ตัวอย่างเช่น บนเว็บไซต์อีคอมเมิรซ์ ผูใ้ ช้ทีเป็ นอันตรายอาจซือสินค้าทังหมดในสต็อก
ของสินค้ายอดนิยมเพือนําไปขายต่อในราคาทีสูงขึน ซึงเรียกว่า scalping API มีความเสียงต่อการโจมตีประเภทนี เนืองจากมัก
ถูกใช้ในการสือสารแบบไร้สถานะระหว่างเครืองจักร (stateless machine-to-machine communication) ซึงทําให้การแยกแยะ
ระหว่างผูใ้ ช้ทีถูกต้องและผูใ้ ช้ทเป็
ี นอันตรายเป็ นเรืองยาก คุณจะได้เรียนรูว้ ิธีจดั การกับช่องโหว่นีเพือปกป้องโมเดลธุรกิจของคุณ
ในบทที 5
1.5 ความปลอดภัยของ API มีบทบาทอย่างไรในวงจรการพัฒนา API?
กระบวนการพัฒนา API ทัวไปประกอบด้วย 4 ขันตอนหลัก ได้แก่ การออกแบบ การพัฒนา การทดสอบ และการ
ปฏิบตั ิการ มาดูกนั ว่าในแต่ละขันตอนมีอะไรเกิดขึนบ้าง:
 การออกแบบ (Design): ในขันตอนการออกแบบ เรารวบรวมข้อกําหนด ตัดสินใจเลือกสไตล์ของ API ทีจะใช้
และรวบรวมการออกแบบของเราให้อยู่ในรูปแบบข้อกําหนดอย่างเป็ นทางการ (formal specification) ขณะที
เรากําลังออกแบบ นีเป็ นโอกาสทีดีในการสร้างแบบจําลองภัยคุกคาม (threat modelling) เพือระบุภยั คุกคาม
ทีอาจเกิดขึน (คุณจะได้เรียนรูเ้ พิมเติมเกียวกับการสร้างแบบจําลองภัยคุกคามในส่วนที 2.2) นอกจากนี ยัง
เป็ นช่วงเวลาทีดีในการเขียน unit tests เพือใช้ตรวจสอบความถูกต้องของการพัฒนาภายหลัง สิงสําคัญคือ
ควรทําขันตอนนีโดยความร่วมมืออย่างใกล้ชดิ กับทีมธุรกิจ เพือให้การออกแบบสอดคล้องกับตัวเลือกและ
ความเสียงทีเราต้องการรับ
 การพัฒนา (Implementation): เมือเรามีการออกแบบ API แล้ว ก็ถึงเวลาสร้าง ในขันตอนนี เราจะเขียนโค้ด
เพือใช้งาน API และตัดสินใจเกียวกับประเภทโครงสร้างพืนฐานที API ต้องการ รวมถึงการตังค่าและกําหนดค่า
ต่างๆ
 การทดสอบ (Testing): หลังจากทีเราได้พฒ
ั นา API แล้ว ก็ถึงเวลาทดสอบ ในอุดมคติ เราควรเขียน unit tests
ไว้ล่วงหน้าและในระหว่างขันตอนการพัฒนา หลังจากพัฒนา API เสร็จ เราควรใช้ fuzz testers เพือตรวจสอบ
ความถูกต้องของการพัฒนา ใช้การทดสอบแบบ end-to-end เพือให้แน่ใจว่าระบบทังหมดทํางานได้อย่าง
น่าเชือถือ และทดสอบการทํางานร่วมกันระหว่าง API และลูกค้า (client) เป็ นต้น
 การปฏิบตั ิการ (Operations): เมือเรามันใจว่า API ทํางานตามทีคาดไว้ ก็ถงึ เวลานําไปใช้ในระบบการผลิต
(production) และตรวจสอบพฤติกรรมและประสิทธิภาพของ API ในส่วนของการปฏิบตั ิการ เราควรตรวจสอบ
ให้แน่ใจว่าเรามีการบันทึกข้อมูลทีละเอียด สามารถติดตามกิจกรรมของผูใ้ ช้ และมีการมองเห็นทีชัดเจนในทุก
กระบวนการทํางานและข้อผิดพลาด
ความปลอดภัยมีบทบาทอย่างไรในวงจรการพัฒนานี? เป้าหมายของการรักษาความปลอดภัย API ตังแต่ขนตอนการ
ั
ออกแบบ (security-by-design) คือการปรับเปลียนความกังวลด้านความปลอดภัยไปทีจุดเริมต้นของวงจรการพัฒนา API เรา
เริมคิดถึงความปลอดภัยตังแต่กา้ วแรกของกระบวนการพัฒนา API และดําเนินการในแต่ละขันตอนตามแนวทางปฏิบตั ิทีดีทีสุด
ด้านความปลอดภัย รูปที 1.6 แสดงให้เห็นว่าแนวคิด security by design เข้ามามีบทบาทในวงจรการพัฒนา API อย่างไร มาดู
กันว่าหลักการนีทํางานอย่างไรในทางปฏิบตั ิ
รูปที . แนวคิด security by design เข้ากันได้กบั ทุกขันตอนของวงจรการพัฒนา API โดยแนวคิดนีส่งเสริมให้เราพิจารณาการออกแบบ การ
พัฒนา การทดสอบ และการปฏิบตั ิการจากมุมมองด้านความปลอดภัย
ในขันตอนการออกแบบ เราต้องการให้แน่ใจว่าการออกแบบ API ของเรามีความปลอดภัย แนวคิดหลักคือไม่ควรหลงไป
กับรายละเอียดด้านความปลอดภัยมากเกินไปในขณะทีกําลังออกแบบ แต่ให้พจิ ารณาว่าการออกแบบของเรามีผลต่อความ
ปลอดภัยอย่างไร ตัวอย่างเช่น นีคือช่วงเวลาทีเราควรพิจารณาว่าจะเปิ ดเผยพารามิเตอร์ประเภทใดให้กบั ผูใ้ ช้ และจะป้องกัน
ไม่ให้พวกเขาใช้พารามิเตอร์เหล่านีในทางทีผิด เช่น การโจมตีดว้ ย SQL injection หรือการโจมตีประเภทอืนๆ ได้อย่างไร
เมือออกแบบการปฏิบตั ิการและกระบวนการใช้งานของผูใ้ ช้
เราควรพิจารณาว่ากระบวนการเหล่านี ส่งผลต่อความ
ปลอดภัยอย่างไร ตัวอย่างเช่น หากเรากําลังออกแบบ API สําหรับอีคอมเมิรซ์ เราจะป้องกันการโจมตีแบบ scalping ได้
อย่างไร? ใน API สําหรับบริการแชร์รถ ทีมีการมอบคูปองส่วนลดสําหรับการสมัครใช้งานผ่านการแนะนํา (referral signup) เรา
จะป้องกันผูใ้ ช้งานทีเป็ นอันตรายจากการสร้างบัญชีปลอมได้อย่างไร? หรือใน API สําหรับฟิ นเทค เราจะทําให้แน่ใจได้อย่างไร
ว่าผูโ้ จมตีไม่สามารถข้ามการตรวจสอบทีจําเป็ นทังหมดก่อนดําเนินการธุรกรรม?
การแก้ปัญหาเหล่านีส่งผลโดยตรงต่อ
ประสบการณ์ของผูใ้ ช้ ดังนันจึงสําคัญทีจะต้องดําเนินการออกแบบร่วมกับผูม้ ีส่วนได้สว่ นเสียทางธุรกิจ ตลอดทังเล่มนี คุณจะ
ได้เรียนรูก้ ลยุทธ์ในการสร้างแบบจําลองภัยคุกคามเหล่านีและวิธีจดั การกับมัน
เมือเสร็จสินการออกแบบแล้ว ก็ถงึ เวลาย้ายไปทีขันตอนการพัฒนา จากมุมมองของ security-by-design เราต้องการให้
แน่ใจว่าเราใช้เฟรมเวิรก์ และไลบรารีทีแข็งแกร่งและปลอดภัย และอัปเดตให้ทนั สมัยอยูเ่ สมอ การพัฒนาของเราจะเกียวข้องกับ
การจัดการข้อมูลจริงในสภาพแวดล้อมการใช้งานจริง ดังนันจึงสําคัญอย่างยิงทีจะต้องตรวจสอบความถูกต้องของข้อมูลอย่าง
ละเอียดในทุกระดับของระบบ การนําหลักการความปลอดภัยแบบ zero-trust มาใช้ เราควรตรวจสอบและล้างข้อมูลทังขาเข้า
และขาออก นอกจากนี การพารามิเตอร์ไลซ์ (parameterize) คําสังฐานข้อมูลทังหมด และการใช้รูปแบบทีได้รบั การยอมรับ
สําหรับการจัดการข้อมูลอย่างปลอดภัย เช่น Data Transfer Objects (DTOs) ก็เป็ นแนวทางปฏิบตั ิทีดี คุณจะได้เรียนรูเ้ พิมเติม
เกียวกับกลยุทธ์การพัฒนาทีปลอดภัยตลอดทังเล่มนี
หลังจากทีเราได้พฒ
ั นา API เสร็จเรียบร้อยแล้ว ก็ถึงเวลาทดสอบมันอย่างเต็มที! เป้าหมายหลายประการในขันตอนนีคือ
เพือให้มนใจว่
ั าการพัฒนาของเราสอดคล้องกับการออกแบบ API อย่างสมบูรณ์แบบ แสดงพฤติกรรมทีถูกต้อง และมีความ
ปลอดภัยและแข็งแกร่ง เราใช้เครืองมือ เช่น fuzz testers เพือตรวจสอบการพัฒนาของเซิรฟ์ เวอร์ให้ตรงกับข้อกําหนดของ API
และใช้เครืองมือทดสอบความปลอดภัย API เพือให้มนใจว่
ั าการพัฒนามีความปลอดภัย นอกจากนี การเขียน unit tests เพือ
ยืนยันพฤติกรรมของ API ตามทีคาดหวัง และการทดสอบแบบ end-to-end ทีจําลองการทํางานของผูใ้ ช้ก็ถือเป็ นแนวทาง
ปฏิบตั ิทีดี
สุดท้ายก็ถึงเวลาปรับใช้งาน API และดําเนินการในสภาพแวดล้อมจริง เราต้องการให้กระบวนการ Continuous
Integration and Delivery (CI/CD) ของเราทดสอบ API อย่างละเอียดและป้องกันไม่ให้เราปล่อย API ทีไม่ปลอดภัยออกไป เรา
ต้องการมีระบบการตรวจสอบและการสังเกตการณ์ (monitoring and observability) ของ API ทีมีคุณภาพระดับโลก เรา
ต้องการรูว้ ่า API ของเราถูกใช้งานอย่างไร และสามารถตรวจจับและบล็อกพฤติกรรมทีเป็ นอันตรายได้ทนั ทีทีมันเกิดขึน
1.6 ภูมิทศั น์ทเปลี
ี ยนแปลงอย่างรวดเร็วของความปลอดภัย API
เมือเราเข้าใจแล้วว่า security-by-design คืออะไร และเราจะนําไปใช้ในทุกขันตอนของวงจรการพัฒนา API ได้อย่างไร
มาลองพิจารณาสถานะปัจจุบนั และอนาคตของความปลอดภัย API กัน
ความปลอดภัย API เป็ นสาขาทีกําลังพัฒนาอย่างรวดเร็ว เราได้ยินข่าวเกียวกับเหตุการณ์ดา้ นความปลอดภัยแทบทุก
สัปดาห์ และอัตราการละเมิด API ก็กาํ ลังเพิมสูงขึนอย่างรวดเร็วเช่นกัน APIs กําลังกลายเป็ นช่องทางการโจมตีทีพบบ่อยทีสุด
ในระบบของเรา และสถานการณ์กาํ ลังแย่ลงเรือยๆ ทําไมถึงเป็ นเช่นนัน? มี 4 ปั จจัยทีส่งผลต่อแนวโน้มนี ได้แก่ การเติบโตอย่าง
รวดเร็วของ API, ความซับซ้อนทีเพิมขึนของ API, จํานวนอุปกรณ์ทีเชือมต่อทีเพิมขึน และล่าสุดคือการเพิมของ AI เชิง
สร้างสรรค์ (Generative AI) มาดูกนั ว่าปั จจัยเหล่านีมีบทบาทอย่างไรบ้าง
จํานวน API ทีมีอยู่บนอินเทอร์เน็ตกําลังเติบโตอย่างรวดเร็ว องค์กรแทบทุกแห่งทีมีระบบเทคนิคภายในของตนเองใช้
API เราใช้ API เพือทําให้งานภายในเป็ นอัตโนมัติ เพือสร้างการเชือมต่อระหว่างไมโครเซอร์วิส เพือให้สามารถเชือมต่อกับแอป
พลิเคชันบนเบราว์เซอร์และมือถือ และเพือส่งมอบผลิตภัณฑ์ ตามรายงาน The API Security Trends Report ปี 2022 ของ
Noname (https://nonamesecurity.com/resources/api-security-trends-report) องค์กรขนาดใหญ่ใช้ API มากกว่า 25,000
รายการโดยเฉลีย และจํานวนดังกล่าวมีแนวโน้มทีจะเพิมขึนต่อไป การเติบโตอย่างรวดเร็วของ API ทําให้การจัดการ การพัฒนา
ความปลอดภัย และการมองเห็นกิจกรรมทังหมดของ API เป็ นเรืองทีท้าทายมากขึน ซึงสิงนีทําให้การรักษาความปลอดภัยของ
API มีความยากลําบากมากขึนตามไปด้วย
แต่ไม่ได้เป็ นเพียงแค่การเติบโตของจํานวน API เท่านัน API ยังมีความซับซ้อนมากขึนอีกด้วย! แอปพลิเคชันเว็บ
สมัยใหม่เป็ นตัวแทนของกระบวนการใช้งานทีซับซ้อน เช่น การจองวันหยุด การสมัครขอสินเชือทีอยู่อาศัย การยืนแบบฟอร์ม
หรือการทํางานร่วมกันแบบเรียลไทม์ในเอกสารเดียวกัน เมือเราออกแบบ API เราจําเป็ นต้องแยกกระบวนการใช้งานทีซับซ้อน
เหล่านีออกเป็ นขันตอนย่อย ๆ ทีเป็ นอิสระและไม่มีสถานะ ข้อผิดพลาดในกระบวนการออกแบบอาจเปิ ดโอกาสให้เกิดการ
ละเมิดและการบิดเบือนโมเดลธุรกิจของเราได้
ตัวอย่างเช่น ในการสมัครขอสินเชือทีอยู่อาศัย ผูใ้ ห้กจู้ ะตรวจสอบหลายสิงในตัวผูส้ มัคร เช่น รายได้ การจ้างงาน
สถานภาพสมรส จํานวนผูท้ ีอยู่ในอุปการะ การประเมินมูลค่าทรัพย์สิน คะแนนเครดิต เป็ นต้น การตรวจสอบบางส่วนอาจต้อง
ดําเนินการตามลําดับทีเฉพาะเจาะจง และอาจมีความเกียวข้องกัน หากเราไม่สามารถจําลองกระบวนการใช้งานและข้อมูลที
ป้อนเข้าได้อย่างถูกต้องและปลอดภัย ผูใ้ ช้ทีมีเจตนาร้ายอาจสามารถข้ามขันตอนการตรวจสอบและได้รบั การอนุมตั ิสินเชือใน
กรณีทไม่
ี ควรได้รบั อนุมตั ิ
ในขณะที API ทีมุ่งเน้นผูใ้ ช้งานต้องเผชิญกับความท้าทายด้านความปลอดภัยทีเพิมขึน Internet of Things (IoT) กลับ
เป็ นพืนทีทีมีโอกาสเกิดเหตุการณ์ดา้ นความปลอดภัยมากยิงกว่า เมือใดก็ตามทีอุปกรณ์เชือมต่อกับอินเทอร์เน็ต อุปกรณ์นนก็
ั
จะง่ายต่อการถูกแฮ็กมากขึน ด้วยเหตุนี IoT จึงเปิ ดโอกาสพิเศษให้ผไู้ ม่หวังดีสามารถยึดและขโมยรถยนต์อจั ฉริยะ เจาะเข้าบ้าน
และขโมยของจากร้านค้า [5]
จํานวนอุปกรณ์อจั ฉริยะทีเชือมต่อกับ API กําลังเพิมขึนอย่างรวดเร็วควบคู่ไปกับการเติบโตของบ้านอัจฉริยะ ร้านค้า
อัจฉริยะ เมืองอัจฉริยะ และอืน ๆ การปกป้องอุปกรณ์ IoT เป็ นเรืองทีท้าทาย บางอุปกรณ์ถกู ออกแบบให้มคี ีย ์ API ทีถูกฝังไว้
อย่างถาวร ดังนันใครก็ตามทีได้อปุ กรณ์นนไปสามารถขโมยคี
ั
ยแ์ ละเข้าถึง API ได้ ผูใ้ ช้ทมีี เจตนาร้ายอาจปลอมแปลงการ
เชือมต่อระหว่างอุปกรณ์และ API ซึงทําให้พวกเขาสามารถเข้าถึงข้อมูลทีละเอียดอ่อนได้ สุดท้าย อุปกรณ์ทีเชือมต่อยังเสียงต่อ
การถูกโจมตีแบบยึดครอง (Hijacking Attacks) ซึงหมายความว่าผูไ้ ม่หวังดีสามารถควบคุมอุปกรณ์ได้ เข้าถึงเครือข่ายส่วนตัว
หรือเปลียนการใช้งานของอุปกรณ์เพือโจมตีแบบ DDoS และอืน ๆ อีกมากมาย [6]
สุดท้าย การเติบโตของ Generative AI กําลังทําให้การรักษาความปลอดภัย API เป็ นเรืองทีท้าทายมากยิงขึน แอปพลิเค
ชันหลายตัวใช้การจดจําใบหน้าหรือเสียงเพือทําการตรวจสอบความปลอดภัยในการเข้าถึง แต่การมีอยู่ของ Deepfake ที
แพร่หลายทําให้การตรวจสอบเหล่านันเสียงต่อการถูกโจมตีมากขึน [7] ด้วยการเติบโตของ Generative AI ไม่เคยง่ายอย่างนีมา
ก่อนทีจะเจาะระบบเว็บไซต์ ตามทีเราจะเห็นในเนือหาทังเล่ม ผูไ้ ม่หวังดีสามารถใช้ประโยชน์จากโมเดลภาษา (Large
Language Models หรือ LLMs) เช่น ChatGPT เพือสร้างกลยุทธ์การโจมตี เช่น SQL Injection และสร้างโค้ดทีจําเป็ นต่อการ
ดําเนินการโจมตีได้ นอกจากนี เรายังคาดว่าโมเดลทีเชียวชาญด้านความปลอดภัยทางไซเบอร์จะมีการพัฒนาออกมาในอนาคต
อันใกล้ ซึงจะทําให้การโจมตีเว็บไซต์ง่ายขึนกว่าเดิม [8]
นักพัฒนาจํานวนมากขึนกําลังใช้ Generative AI เป็ นผูช้ ่วยในการเขียนโค้ดในงานพัฒนาซอฟต์แวร์ประจําวัน เช่น การ
เข้าใจข้อผิดพลาด การหาตัวอย่างโค้ด หรือการสร้างโค้ดส่วนต่าง ๆ โดยสมบูรณ์ การใช้ Generative AI ในการพัฒนาซอฟต์แวร์
สามารถเพิมประสิทธิภาพการทํางานของนักพัฒนาได้ แต่ก็สามารถทําให้แอปพลิเคชันเว็บมีช่องโหว่ได้เช่นกัน หากผลลัพธ์จาก
โมเดล AI ไม่ได้รบั การตรวจสอบ ทดสอบ และแก้ไขอย่างรอบคอบ ในเนือหาของทังเล่มนี เราจะเรียนรูว้ ิธีการจัดการกับความท้า
ทายเหล่านี
1.7 ใครคือผูอ้ า่ นของหนังสือเล่มนี และสิงทีคุณจะได้เรียนรู ้
API มีอยู่ทวไปบนอิ
ั
นเทอร์เน็ต ระบบแทบทุกระบบใช้บริการภายนอก เช่น การประมวลผลการชําระเงิน การระบุ
ตําแหน่งทางภูมิศาสตร์ และการส่งอีเมลผ่าน API และจํานวนแอปพลิเคชันทีเปิ ด API เพือวัตถุประสงค์ตา่ ง ๆ เช่น การเชือมต่อ
ระหว่างไมโครเซอร์วิส หรือการใช้งานโดยแอปพลิเคชันบนมือถือและเบราว์เซอร์ ก็กาํ ลังเพิมขึนเรือย ๆ ทุกสถานการณ์เหล่านี
ก่อให้เกิดภัยคุกคามด้านความปลอดภัยทังต่อผูบ้ ริโภคและผูใ้ ห้บริการ หนังสือเล่มนีเหมาะสําหรับทุกคนทีอยู่ในด้านใดด้าน
หนึงของ API
หากคุณเป็ นผูใ้ ช้งาน API หนังสือเล่มนีเหมาะสําหรับคุณ หากคุณเป็ นผูใ้ ห้บริการ API แม้กระทัง API ทีเรียกว่า "API
ภายใน" หนังสือเล่มนีก็เหมาะสําหรับคุณ หากคุณเป็ นผูอ้ อกแบบระบบแบบกระจายทีต้องพึงพา API หนังสือเล่มนีเหมาะ
สําหรับคุณ หรือหากองค์กรของคุณส่งมอบผลิตภัณฑ์และบริการผ่าน API หนังสือเล่มนียิงเหมาะสําหรับคุณอย่างแน่นอน
ในงานของฉัน ฉันมีโอกาสได้พดู คุยกับองค์กรต่าง ๆ เกียวกับความปลอดภัยของ API และได้สมั ภาษณ์บคุ คลในทุก
ระดับ ตังแต่นกั พัฒนามือใหม่ไปจนถึง CTO ประสบการณ์ของฉันแสดงให้เห็นว่าความปลอดภัยของ API เป็ นหัวข้อทีคนส่วน
ใหญ่ยงั เข้าใจได้ไม่ดีนกั ซึงไม่นา่ แปลกใจนัก เพราะดังทีได้กล่าวไปก่อนหน้านี API เปิ ดช่องทางการโจมตีในรูปแบบทีคาดไม่ถึง
และวิธีการรักษาความปลอดภัยแบบดังเดิมสําหรับแอปพลิเคชันนันไม่เพียงพอสําหรับ API ความหวังของฉันคือ หนังสือเล่มนี
จะช่วยลดช่องว่างของทักษะนี สร้างความตระหนักรูเ้ กียวกับความเสียงทีเกียวข้องกับ API และส่งเสริมแนวปฏิบตั ดิ า้ นความ
ปลอดภัยทีดียิงขึนในการพัฒนา API
หนังสือเล่มนีจะสอนให้คณ
ุ รูจ้ กั ประเภทหลัก ๆ ของช่องโหว่ดา้ นความปลอดภัยของ API และทีสําคัญคือวิธีการปกป้อง
API ของคุณจากช่องโหว่เหล่านัน คุณจะได้เรียนรูเ้ กียวกับ
 การประยุกต์ใช้หลักการและแนวปฏิบตั ิทีดีทีสุดของความปลอดภัย API
 การจัดการกับประเภทหลักของช่องโหว่ดา้ นความปลอดภัย API
 การออกแบบ API ให้มีความปลอดภัยตังแต่ตน้
 การระบุและแก้ไขข้อบกพร่องในกระบวนการออกแบบ API
 การทําให้กระบวนการระบุและแก้ไขช่องโหว่ใน API เป็ นอัตโนมัติ
 การพัฒนา API ตามแนวปฏิบตั ิทีดีทีสุดด้านความปลอดภัย
 การออกแบบสถาปัตยกรรม API ให้มีความปลอดภัย
 การใช้การควบคุมการอนุญาตเข้าถึงทีแข็งแกร่งกับ API ของคุณ
 การนําความปลอดภัยระดับมาตรฐานทางการเงินมาใช้กบั API
 การดําเนินงาน API อย่างปลอดภัย
 การใช้การสังเกตการณ์ API (API Observability) เพือตรวจจับกิจกรรมของผูใ้ ช้ทีเป็ นอันตรายและตอบสนอง
ต่อกิจกรรมนัน
เมือคุณอ่านหนังสือเล่มนีจบ คุณจะเข้าใจถึงช่องโหว่หลัก ๆ ที API ต้องเผชิญทังหมด และวิธีการจัดการกับช่องโหว่
เหล่านัน คุณจะรูว้ ธิ ีการสร้าง API ทีมีความปลอดภัยตังแต่ขนตอนการออกแบบ
ั
คุณจะสามารถพิจารณาประเด็นด้านความ
ปลอดภัยทังในขันตอนการออกแบบ API และในกระบวนการจําลองการโต้ตอบของผูใ้ ช้งาน คุณจะรูว้ ิธีการพัฒนาและออกแบบ
สถาปั ตยกรรม API ให้มีความปลอดภัย คุณจะสามารถทําให้กระบวนการระบุและจัดการช่องโหว่ดา้ นความปลอดภัยใน API
เป็ นระบบอัตโนมัติ
ตามข้อมูลจาก Cloudflare (https://www.cloudflare.com/2024-api-security-management-report/) พบว่า 57%
ของปริมาณการใช้งานอินเทอร์เน็ตทังหมดผ่าน API ดังนันความหวังของฉันคือหนังสือเล่มนีจะช่วยให้นกั พัฒนาซอฟต์แวร์ทวั
โลกสามารถสร้างอินเทอร์เน็ตทีปลอดภัยยิงขึน
1.8 สรุป
 เหตุการณ์ดา้ นความปลอดภัยของ API ก่อให้เกิดค่าใช้จา่ ยสูงสําหรับองค์กร การละเมิดความปลอดภัยอาจ
นําไปสู่การถูกปรับเป็ นจํานวนมาก ในขณะทีการเปิ ดเผยช่องโหว่ในกระบวนการใช้งานของผูใ้ ช้อาจเปิ ดโอกาส
ให้แฮ็กเกอร์บิดเบือนโมเดลธุรกิจของเรา ซึงอาจส่งผลต่อการสูญเสียรายได้และความเสียหายต่อชือเสียง
 ทุกพารามิเตอร์อินพุตใน API ถือเป็ นช่องทางโจมตี ไม่ว่าจะเป็ นพารามิเตอร์ใน URL query หรือ path, ข้อมูล
payloads ทีร้องขอ, หรือ headers
 "ความปลอดภัยตังแต่การออกแบบ" (Security by Design) เป็นแนวทางทีสนับสนุนให้เราขยับกลยุทธ์ความ
ปลอดภัย API ให้เกิดขึนในขันตอนการออกแบบ ด้วยแนวทางนี เราจะคํานึงถึงประเด็นด้านความปลอดภัย
ตังแต่ขนตอนการพั
ั
ฒนา API
 เราสามารถจัดการกับช่องโหว่ดา้ นความปลอดภัยหลายประเภทได้ในขันตอนการออกแบบ เช่น การสร้าง
กระบวนการใช้งานของผูใ้ ช้ทีปลอดภัย การจํากัดข้อมูลอินพุตของผูใ้ ช้ และการหลีกเลียงการเปิ ดเผย
คุณสมบัติฝังเซิรฟ์ เวอร์ในข้อมูลอินพุตของผูใ้ ช้
 "ความปลอดภัยตังแต่การออกแบบ" ยังส่งเสริมให้เราใช้กลยุทธ์การพัฒนาอย่างปลอดภัย เช่น การใช้
พารามิเตอร์ในคําสังฐานข้อมูล
และการหลีกเลียงการกําหนดค่าจํานวนมากโดยไม่ได้ตงใจ
ั
(Mass
Assignment)
 เราจําเป็ นต้องทดสอบ API ของเราอย่างต่อเนืองเพือค้นหาช่องโหว่ และต้องทําให้กระบวนการทดสอบเป็ น
อัตโนมัติให้มากทีสุดเท่าทีจะเป็ นไปได้
 โซลูชนั ด้านสถาปั ตยกรรมทีปลอดภัย เช่น การวางฐานข้อมูลในเครือข่ายส่วนตัว การใช้ API Gateway ทีมี
ความแข็งแกร่ง และการบังคับใช้นโยบายไฟร์วอลล์ทีเข้มงวด ล้วนมีบทบาทสําคัญในด้านความปลอดภัย API
 เราต้องเฝ้าติดตาม API ของเราอย่างต่อเนือง และวิเคราะห์กิจกรรมของผูใ้ ช้แบบเรียลไทม์เพือค้นหาพฤติกรรม
ทีเป็ นอันตราย และตอบสนองต่อพฤติกรรมนันได้อย่างทันเวลา
 จํานวน API และอุปกรณ์ IoT ทีเชือมต่อทีเพิมขึน ความซับซ้อนทีมากขึนของ API และการเกิดขึนของ
Generative AI ล้วนแต่เป็ นความท้าทายใหม่ ๆ ทีไม่เหมือนเดิมในด้านความปลอดภัย API ในปั จจุบนั
[1] วิคเตอร์ เดย์, “เหตุใดความปลอดภัยของ API จึงกลายเป็ นภัยคุกคามทีเติบโตอย่างรวดเร็วต่อองค์กรทีขับเคลือน
ด้วยข้อมูล,” VentureBeat, 23 พฤศจิกายน 2022 (https://venturebeat.com/security/why-api-security-is-a-fast-growingthreat-to-data-driven-enterprises/).
[2] ทิม คีรี, “การละเมิดข้อมูลของ T-Mobile แสดงให้เห็นว่าความปลอดภัยของ API ไม่สามารถมองข้ามได้,”
VentureBeat, 20 มกราคม 2023 (https://venturebeat.com/security/t-mobile-data-breach-shows-api-security-cant-beignored/).
[3] จอน อันโกด-โธมัส, “สถานการณ์ทียุ่งเหยิง: ผูเ้ รียนขับรถถูกบังคับให้ซือตารางสอบในตลาดมืด เนืองจากบริษัทจอง
ช่องสอบไว้ล่วงหน้า,” The Guardian, 3 กันยายน 2023 (https://www.theguardian.com/uk-news/2023/sep/03/anabsolute-mess-learner-drivers-forced-to-buy-tests-on-black-market-as-companies-block-book-slots).
[4] ฉันได้พดู ถึงตัวอย่างของช่องโหว่นีในงานบรรยาย “API Security by Design” ที Open Security Summit, 16
มกราคม 2024 (https://youtu.be/gJinDI_Ma1Y).
[5] นิค เซอร์ปาตานู, “รถยนต์ทีเชือมต่ออินเทอร์เน็ตคือช่องทางโจมตีถดั ไป,” Forbes, 7 กันยายน 2022
(https://www.forbes.com/sites/tanium/2022/09/07/the-connected-car-is-the-next-attack-vector/).
[6] ปูจา คูมาริ และ อังกิต คูมาร์ เจน, “การศึกษาแบบครอบคลุมเกียวกับการโจมตีแบบ DDoS ผ่านเครือข่าย IoT และ
มาตรการตอบโต้,”
Computers
&
Security,
127
(เมษายน
2023)
[มีให้บริการออนไลน์:
https://www.sciencedirect.com/science/article/abs/pii/S0167404823000068].
[7] ทิมรู ์ ยูนซู อฟ, “ตัวตนสังเคราะห์ – มุมมองจากความปลอดภัยแอปพลิเคชัน,” งานนําเสนอที OWASP’s London
Chapter Meetup, 28 กุมภาพันธ์ 2023 (บันทึกการบรรยายมีให้บริการออนไลน์: https://youtu.be/vQZayZV_C90).
[8] บิล ดอร์ฟเฟลด์, “เหตุใด Generative AI จึงเป็ นภัยคุกคามต่อความปลอดภัยของ API,” Security Boulevard, 20
กรกฎาคม 2023 (https://securityboulevard.com/2023/07/why-generative-ai-is-a-threat-to-api-security/).
2 การปรับความปลอดภัยของ API ให้สอดคล้องกับองค์กรของคุณ
บทนีครอบคลุมหัวข้อดังนี
 การประเมินท่าทีดา้ นความปลอดภัยของ API ของคุณ
 การสร้างแบบจําลองภัยคุกคามสําหรับ API ของคุณ
 การเริมต้นเส้นทางความปลอดภัยของ API ด้วยสิงทีทําได้ง่ายก่อน
 การสร้างโปรแกรมความปลอดภัยของ API สําหรับองค์กรของคุณ
 การได้รบั การสนับสนุนจากองค์กรของคุณเพือจัดการกับความปลอดภัยของ API
 การจัดการตรวจสอบด้านความปลอดภัยของ API
ดังทีเราได้เห็นในบทที 1, API กําลังกลายเป็ นช่องทางหลักของการโจมตีบนอินเทอร์เน็ต หากคุณทํางานหรือกําลัง
วางแผนทีจะทํางานกับ API สิงสําคัญคือการเริมคิดถึงความปลอดภัยตังแต่เนินๆ คําถามคือ คุณจะนําความปลอดภัยมา
รวมเข้ากับการพัฒนา API ของคุณได้อย่างไร? คุณจะปรับความปลอดภัยให้สอดคล้องกับเป้าหมายและความต้องการของ
ผลิตภัณฑ์ได้อย่างไร? และคุณจะดําเนินการตรวจสอบความปลอดภัยอย่างต่อเนืองเป็ นส่วนหนึงของกระบวนการพัฒนา API
ได้อย่างไร?
การพัฒนาซอฟต์แวร์เป็ นกิจกรรมทีเกียวข้องกับสังคม เราสร้างซอฟต์แวร์เป็ นส่วนหนึงของทีม ซึงเป็ นส่วนหนึงของ
องค์กรทีใหญ่กว่า การพัฒนาซอฟต์แวร์นนเกี
ั ยวข้องกับการพูดคุยกับผูม้ ีส่วนได้ส่วนเสียทีหลากหลาย การทําความเข้าใจความ
ต้องการของผลิตภัณฑ์ การจัดลําดับความสําคัญของฟี เจอร์และข้อกังวล และการทํางานร่วมกันเพือไปสู่ทางออกทีเหมือนกัน
เราต้องคํานึงถึงกําหนดเวลา
ซึงหมายความว่าไม่ใช่ทกุ ฟี เจอร์จะได้รบั ความสนใจเท่าเทียมกันหรือได้รบั การพัฒนาในเวลา
เดียวกัน
ตัวอย่างเช่น สไตล์และประสิทธิภาพของส่วนติดต่อผูใ้ ช้งาน (UI) มีผลโดยตรงต่อประสบการณ์ผใู้ ช้งาน (UX) ดังนันเรา
จึงให้ความสําคัญกับสิงเหล่านี แต่สงที
ิ เกียวกับความปลอดภัยของ API ล่ะ? ความปลอดภัยของ API ก็มีผลกระทบโดยตรงต่อ
ผูใ้ ช้เช่นกัน แต่ผลกระทบนันอาจไม่ชดั เจน จนกว่าคุณจะเผชิญกับเหตุการณ์การละเมิดข้อมูล
เราสามารถพูดถึงประเด็นทางเทคนิคของความปลอดภัยของ API ได้มากเท่าทีเราต้องการ แต่หากเราไม่จดั การกับ
ประเด็นทางสังคม เราอาจล้มเหลวในการปรับความปลอดภัยให้สอดคล้องกับเป้าหมายของผลิตภัณฑ์ เราจะนําเสนอ
ความสําคัญของความปลอดภัยของ API อย่างไร? เราจะทําให้ผมู้ ีส่วนได้ส่วนเสียเข้าใจถึงความสําคัญและจัดสรรเวลาในการ
ทํางานกับเรืองนีได้อย่างไร? และเราจะปรับองค์กรของเราให้สอดคล้องกับกลยุทธ์ความปลอดภัยของ API ทีเหมาะสมได้
อย่างไร?
ในบทนี คุณจะได้เรียนรูก้ ลยุทธ์ในการปรับความปลอดภัยของ API ให้สอดคล้องกับเป้าหมายขององค์กร เพือให้ความ
ปลอดภัยได้รบั การจัดลําดับความสําคัญอย่างเหมาะสม ขันตอนแรกคือการประเมินท่าทีดา้ นความปลอดภัยของ API เพือทํา
ความเข้าใจว่าเรายืนอยูจ่ ดุ ไหนและต้องจัดการกับอะไรเป็ นอันดับแรก
คุณจะได้เรียนรูว้ ิธีการสร้างแบบจําลองภัยคุกคาม
สําหรับ API ของคุณเพือทําความเข้าใจความเสียง และวิธีการดําเนินการโปรแกรมความปลอดภัยของ API ทีสอดคล้องกับ
เป้าหมายขององค์กรของคุณ
2.1 การประเมินท่าทีดา้ นความปลอดภัยของ API
ท่าทีดา้ นความปลอดภัยของคุณหมายถึงความสามารถในการป้องกัน ระบุ ตอบสนอง และฟื นตัวจากภัยคุกคามด้าน
ความปลอดภัย เพือทีจะกําหนดว่าท่าทีดา้ นความปลอดภัยของคุณดีเพียงใด คุณต้องทําการประเมิน ในประสบการณ์ของฉัน
หลายองค์กรไม่ได้ประเมินท่าทีดา้ นความปลอดภัยของตนจนกว่าจะเกิดเหตุการณ์สาํ คัญ เช่น การระดมทุนทีเกียวข้องกับการ
ตรวจสอบสถานะ หรือการตรวจสอบด้านกฎระเบียบ ฉันขอแนะนําว่าอย่ารอจนกว่าจะเกิดเหตุการณ์เหล่านี แต่ให้เริมต้นทันที
ดังทีเราได้เห็นในบทที 1 การละเมิดข้อมูลส่งผลเสียหายต่อองค์กรของคุณ การประเมินท่าทีดา้ นความปลอดภัยจะช่วยให้คณ
ุ
ทราบว่าคุณพร้อมทีจะรับมือกับเหตุการณ์ดา้ นความปลอดภัยเหล่านีมากน้อยเพียงใด และทังหมดนีเริมต้นจากการประเมิน
ท่าทีดา้ นความปลอดภัย
มีกรอบการทํางานหลายอย่างทีช่วยคุณประเมินท่าทีดา้ นความปลอดภัย เช่น NIST SP 800-53, CIS และ ISO/IEC
27001 เป็ นต้น [1] กรอบการทํางานเหล่านีให้คาํ แนะนําทีครอบคลุมและละเอียดเพือช่วยเสริมความปลอดภัยให้องค์กรของคุณ
โดยบางส่วนเท่านันทีเกียวข้องโดยตรงกับความปลอดภัยของ API รูปที 2.1 แสดงการเชือมโยงข้อกําหนดทีพบบ่อยทีสุดใน
กรอบการทํางานด้านความปลอดภัยทางไซเบอร์เข้ากับความปลอดภัยของ API
รูปที . การเชือมโยงข้อกําหนดทีพบบ่อยทีสุดในกรอบการทํางานด้านความปลอดภัยทางไซเบอร์สาํ หรับความปลอดภัยของ API
มาดูแต่ละหมวดในรูปที 2.1 พร้อมคําถามทีคุณต้องตอบในแต่ละหมวด:
 การจัดการข้อมูล (Data inventory): คุณเก็บข้อมูลประเภทใด? คุณรวบรวมข้อมูลอย่างไร? คุณจัดเก็บข้อมูล
ไว้ทไหน?
ี
คุณจัดเก็บข้อมูลไว้นานเท่าใด? คุณมีรายการข้อมูลทีอัปเดตอย่างสมําเสมอหรือไม่? ข้อมูลนีถูก
เปิ ดเผยผ่าน API อย่างไร? จุดเชือมต่อข้อมูลทีอ่อนไหวทีสุดคืออะไร?
 พืนทีเสียงต่อการโจมตี (Attack surface): คุณเปิ ดเผยจุดเชือมต่อ (endpoints) จํานวนเท่าใด? คุณมี API กี
เวอร์ชนั ทีใช้งานอยู่? มีช่องทางอืนใดบ้างทีผูไ้ ม่ประสงค์ดีสามารถเข้าถึงระบบของคุณได้ (เช่น ฐานข้อมูล
เซิรฟ์ เวอร์ Continuous Integration เป็ นต้น)?
 การยืนยันตัวตนและการกําหนดสิทธิ (Authentication and authorization): คุณใช้แนวทางปฏิบตั ทิ ดีี ทีสุดและ
มาตรฐานสําหรับการยืนยันตัวตนและการกําหนดสิทธิหรือไม่? จุดเชือมต่อการเข้าสู่ระบบของคุณได้รบั การ
ป้องกันอย่างเพียงพอจากการโจมตีแบบ brute force และรูปแบบอืนๆ หรือไม่? คุณออกโทเคนการเข้าถึง
(access tokens) ทีมีลายเซ็นทีแข็งแกร่งหรือไม่? โทเคนการเข้าถึงของคุณมีขอ้ มูลทีอ่อนไหวหรือไม่? คุณ
หมุนเวียนคียล์ ายเซ็น (signing keys) เป็ นประจําหรือไม่?
 การควบคุมการเข้าถึง (Access controls): จุดเชือมต่อทังหมดของคุณได้รบั การป้องกันหรือไม่? คุณมีกฎการ
เข้าถึงทีเข้มงวดสําหรับจุดเชือมต่อทีอ่อนไหวหรือไม่? นโยบายการเข้าถึงถูกบังคับใช้อย่างเพียงพอหรือไม่?
ใครบ้างในองค์กรของคุณทีมีสิทธิเข้าถึงทรัพยากรทีอ่อนไหว และพวกเขาเข้าถึงได้อย่างไร? การควบคุมการ
เข้าถึงถูกดําเนินการอย่างถูกต้องหรือไม่?
 การพัฒนาอย่างปลอดภัย (Secure implementation): คุณใช้รูปแบบการพัฒนาทีปลอดภัยหรือไม่? คุณใช้
ไลบรารี API ทีเหมาะสมเพือจัดการการตรวจสอบความถูกต้องของข้อมูลหรือไม่? การพึงพา (dependencies)
ของคุณปลอดภัยหรือไม่? การออกแบบและสถาปัตยกรรมของ API ของคุณปลอดภัยหรือไม่? คุณตรวจสอบ
และทดสอบโค้ดก่อนทีจะปล่อยใช้งานหรือไม่?
 การทดสอบความปลอดภัย (Security testing): คุณดําเนินการทดสอบความปลอดภัยแบบอัตโนมัติสาํ หรับ
API ของคุณเป็ นประจําหรือไม่? คุณเคยดําเนินการทดสอบเจาะระบบ (penetration test) เฉพาะทางสําหรับ
API ของคุณหรือไม่?
 การวิเคราะห์ความเสียง (Risk analysis): ความเสียงด้านความปลอดภัยหลักสําหรับองค์กรของคุณคืออะไร?
เมือคุณได้รบั รายการช่องโหว่ คุณรูว้ ิธีจดั ลําดับความสําคัญของมันหรือไม่?
 การตรวจจับเหตุการณ์ (Incident detection): คุณมีการสังเกตการณ์ API (API observability) หรือไม่? คุณ
วิเคราะห์กจิ กรรม API อย่างต่อเนืองเพือค้นหากิจกรรมทีเป็ นอันตรายหรือไม่? คุณได้รบั การแจ้งเตือนเมือมี
การตรวจพบภัยคุกคามหรือไม่?
 แผนตอบสนองต่อเหตุการณ์ (Incident response plan): คุณมีแผนตอบสนองอย่างละเอียดสําหรับเหตุการณ์
ด้านความปลอดภัยหรือไม่? มีการตอบสนองบางส่วนของคุณทีเป็ นแบบอัตโนมัติหรือไม่? แผนตอบสนองของ
คุณสอดคล้องกับข้อกําหนดด้านกฎระเบียบของคุณหรือไม่?
 การฝึ กอบรมและการสร้างความตระหนัก (Training and awareness): พนักงานทุกคนในบริษัทของคุณรับรู ้
ถึงความเสียงทีเกียวข้องกับ API หรือไม่? คุณจัดการฝึ กอบรมอย่างต่อเนืองเพือให้พนักงานของคุณทันกับภัย
คุกคามล่าสุดหรือไม่?
คําตอบของคุณต่อคําถามข้างต้นจะเป็ นตัวกําหนดระดับความพร้อมและความเป็ นผูใ้ หญ่ (maturity) ในด้านความ
ปลอดภัยของ API หากคุณไม่สามารถตอบคําถามข้อใดได้ แสดงว่าความพร้อมด้านความปลอดภัยของ API ของคุณอยูใ่ น
ระดับตํา ตัวอย่างเช่น หากคุณไม่มีรายการข้อมูล (data inventory) หรือไม่ได้ทาํ การแมปพืนทีเสียงต่อการโจมตี (attack
surface) นันหมายความว่าความพร้อมของคุณในด้านเหล่านีอยูใ่ นระดับตํา เพือประเมินท่าทีดา้ นความปลอดภัยของ API คุณ
ต้องจัดการกับความพร้อมด้านความปลอดภัยของ API ของคุณก่อน เมือคุณสามารถตอบคําถามเหล่านันได้ คุณจึงสามารถ
ประเมินระดับความเป็ นผูใ้ หญ่ได้
ตัวอย่างเช่น การมีบนั ทึก (logs) และข้อมูลจากระบบซอฟต์แวร์ (telemetry) เป็ นจุดเริมต้นทีดี แต่หากคุณไม่ได้
ตรวจสอบบันทึกเหล่านันอย่างต่อเนืองเพือค้นหากิจกรรมทีเป็ นอันตราย ระดับความเป็ นผูใ้ หญ่ในด้านนีของคุณยังอยูใ่ นระดับ
ตํา ตารางที 2.1 แสดงวิธีการทีเรียบง่ายและสามารถนําไปปฏิบตั ิได้ในการประเมินท่าทีดา้ นความปลอดภัยของ API ของคุณ
ตารางที . แบบสอบถามการประเมินท่าทีดา้ นความปลอดภัยของ API ตอบ “ใช่” เฉพาะเมือคุณมีความพร้อม
% ในหมวดหมู่นัน
ตัวอย่างเช่น หากคุณได้ทาํ การแมปพืนทีเสียงต่อการโจมตี (attack surface) ไปแล้ว % นันยังถือว่าเป็ น “ไม่” และหากรายการข้อมูล (data
inventory) ของคุณได้รบั การอัปเดตเป็ นประจํา แต่ไม่ได้อปั เดตต่อเนืองทุกครังทีมีการเปลียนแปลง นันยังถือว่าเป็ น “ไม่”
Data Inventory:
Is your data inventory up to date and continuously updated?
Attack surface:
Is your attack surface completely mapped and always up to date?
Authentication and authorization:
Do you follow best practices and standards for authentication and authorization?
Access controls:
Do you have secure and strict access controls and are they continuously updated?
Secure implementation:
Do you use secure design and implementation patterns?
Security testing:
Do you continuously test your APIs for security?
Risk analysis:
Have you mapped out your API business risks and are they continuously updated?
Incident detection:
Do you have proper API observability and automated detection of malicious activity?
Incident response plan:
Do you have a detailed response plan for security breaches and is it continuously
updated?
Training and awareness:
Do you continuously train your staff on API security?
Mature
Yes
Not Mature
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
Yes
No
ตารางที 2.1 ให้กรอบการทํางานทีเรียบง่ายสําหรับการประเมินท่าทีดา้ นความปลอดภัยของ API คําถามในกรอบการ
ทํางานนีเป็ นแบบสองตัวเลือก (binary) ซึงหมายความว่าคุณจะอยู่ในสถานะ "เป็ นผูใ้ หญ่" (mature) หรือ "ไม่เป็ นผูใ้ หญ่" (not
mature) อย่างใดอย่างหนึง หากคุณต้องการวิธีการทีมีความละเอียดมากขึน คุณสามารถเลือกให้คะแนนในแต่ละหมวดตังแต่
0 ถึง 5 ได้ ตัวอย่างเช่น คุณอาจมีรายการข้อมูล (data inventory) ทีอัปเดตล่าสุด แต่แทนทีจะอัปเดตทุกครังทีโปรไฟล์ขอ้ มูลของ
คุณเปลียนแปลง คุณอาจอัปเดตเป็ นรายปี รายเดือน หรือรายสัปดาห์ คุณสามารถกําหนดคะแนนทีสะท้อนสถานการณ์ของคุณ
ได้ดียงขึ
ิ น และจัดลําดับความสําคัญในการปรับปรุงความปลอดภัยตามความต้องการของธุรกิจของคุณ
คําเตือนเกียวกับท่าทีดา้ นความปลอดภัยของ API: ผูใ้ ห้บริการหลายรายในพืนทีนีอ้างว่าสามารถจัดการท่าทีดา้ นความ
ปลอดภัยของ API โดยอัตโนมัตไิ ด้ทงหมด
ั
แม้วา่ การทํางานอัตโนมัติในบางส่วนจะเป็ นไปได้ แต่ไม่สามารถทําได้ทงหมด
ั
การ
จัดการท่าทีดา้ นความปลอดภัยนันรวมถึงสิงต่างๆ เช่น การฝึกอบรม การกําหนดความเสียงทางธุรกิจ การเขียนแผนตอบสนอง
ต่อเหตุการณ์ และอืนๆ ซึงสิงเหล่านีไม่สามารถทําให้เป็ นอัตโนมัติได้ แม้แต่ในกรณีของการทดสอบความปลอดภัยทางเทคนิค
เพียงอย่างเดียว ก็ไม่สามารถทําให้เป็ นอัตโนมัติได้ทงหมดเช่
ั
นกัน ดังที Corey Ball ผูเ้ ขียนหนังสือ Hacking APIs ชีให้เห็นว่า
เครืองมือทดสอบความปลอดภัยของ API แบบอัตโนมัติส่วนใหญ่ไม่สามารถตรวจพบปัญหาส่วนใหญ่ได้ แม้ในกรณีที API ถูก
ออกแบบให้มชี ่องโหว่โดยตังใจ และในหลายกรณี การตรวจจับช่องโหว่ตอ้ งอาศัยความรูเ้ กียวกับโดเมนธุรกิจ ซึงเครืองมือ
อัตโนมัติไม่สามารถเข้าใจได้ [2] ดังนัน ควรระวังผูใ้ ห้บริการทีอ้างว่าสามารถระบุช่องโหว่ดา้ นความปลอดภัยทังหมดใน API
ของคุณได้ทงหมด
ั
ฉันจะพูดเพิมเติมเกียวกับเรืองนีในบทที 12
องค์ประกอบพืนฐานของการประเมินท่าทีดา้ นความปลอดภัยของ API คือการสร้างแบบจําลองภัยคุกคาม (threat
modeling) การสร้างแบบจําลองภัยคุกคามช่วยให้คณ
ุ เข้าใจความเสียงด้านความปลอดภัยของคุณ ทําแผนทีพืนทีเสียงต่อการ
โจมตี และเตรียมแผนตอบสนองต่อเหตุการณ์ ในส่วนถัดไป คุณจะได้เรียนรูว้ ิธีสร้างแบบจําลองภัยคุกคามสําหรับ API ของคุณ
2.2 การสร้างแบบจําลองภัยคุกคามเป็ นกิจกรรมทีทําร่วมกันในทีม
การสร้างแบบจําลองภัยคุกคาม (Threat modeling) เป็ นการวิเคราะห์ลกั ษณะด้านความปลอดภัยของระบบของคุณ
เป้าหมายของการสร้างแบบจําลองภัยคุกคามคือการระบุช่องโหว่และวิธีทีผูไ้ ม่ประสงค์ดีสามารถใช้ประโยชน์จากช่องโหว่นนั
แนวคิดคือการพิจารณาสถานการณ์ต่างๆ หรือแบบจําลองภัยคุกคามทีแสดงถึงวิธีทีผูใ้ ช้ทีเป็ นอันตรายสามารถบรรลุเป้าหมาย
ของพวกเขา เช่น การเจาะเข้าฐานข้อมูล การเข้าถึงทรัพยากรหรือกระบวนการโดยไม่ได้รบั อนุญาต การยกระดับสิทธิ ของตน
หรือการฉีดเนือหาทีเป็ นอันตราย
การสร้างแบบจําลองภัยคุกคามเป็ นกิจกรรมทีมีประโยชน์มากสําหรับการสร้างความตระหนักเกียวกับช่องโหว่ของระบบ
แม้แต่แบบจําลองภัยคุกคามง่ายๆ ดังทีแสดงในรูปที 2.2 ก็สามารถให้ขอ้ มูลเชิงลึกได้อย่างมากเกียวกับวิธีทีผูไ้ ม่ประสงค์ดี
สามารถเจาะเข้าสู่ระบบของคุณ และสิงทีเราจําเป็ นต้องทําเพือรักษาความปลอดภัยและตรวจจับการโจมตี รูปที 2.2 เป็ น
ตัวอย่างของแบบจําลองการโจมตีดว้ ย SQL Injection ซึงสามารถเลียงการควบคุมการเข้าถึงของผูใ้ ช้ในจุดเชือมต่อรายการ
ข้อมูล (listing endpoint) ได้ ดังทีแบบจําลองเน้นให้เห็น การโจมตีเกิดขึนเนืองจากการพารามิเตอร์ของคําค้นหา (query
parameters) ทีไม่มีขอ้ จํากัด และการทีคําสังฐานข้อมูลไม่ได้ถกู พารามิเตอร์ นีคือข้อเสนอแนะทีสามารถนําไปปฏิบตั ิได้จาก
แบบจําลอง: เราต้องกําหนดข้อจํากัดสําหรับอินพุตของผูใ้ ช้และทําการพารามิเตอร์สาํ หรับคําสังฐานข้อมูล
รูปที . ผูใ้ ช้ทีเป็ นอันตรายเลียงการควบคุมการเข้าถึงทังหมดบนจุดเชือมต่อ GET /products โดยใช้ประโยชน์จากช่องโหว่ SQL Injection ใน
API
แบบจําลองภัยคุกคามทีดีจะแสดงให้เห็นว่า การโจมตีเกิดขึนในระบบของเราอย่างไร และส่วนประกอบใดบ้างทีได้รบั
ผลกระทบ ตัวอย่างเช่น แบบจําลองในรูปที 2.2 แสดงการโจมตีทีเกียวข้องกับ API และฐานข้อมูล สําหรับระบบทีซับซ้อนมาก
ขึน อาจรวมถึงส่วนประกอบต่างๆ เช่น API gateways, load balancers, บริการและฐานข้อมูลหลายตัว, queues และ streams
รวมถึงส่วนประกอบอืนๆ โดยปกติ แต่ละส่วนของระบบจะถูกดูแลโดยทีมทีแตกต่างกัน ดังนัน แบบจําลองภัยคุกคามทีดีจึงต้อง
ได้รบั ข้อมูลจากทุกทีม การสร้างแบบจําลองภัยคุกคามทีมีประสิทธิภาพเป็ นความพยายามร่วมกันทีรวมทีมต่างๆ เข้าด้วยกัน
เพือให้ได้มมุ มองทีครอบคลุมของระบบเรา
คําถามคือ เราจะสร้างแบบจําลองภัยคุกคามได้อย่างไร? เพือส่งเสริมแนวทางปฏิบตั ิทีดีทีสุดในการสร้างแบบจําลองภัย
คุกคาม กลุ่มผูน้ าํ ในอุตสาหกรรมได้สร้าง Threat Modeling Manifesto (https://www.threatmodelingmanifesto.org/) ขึนมา
มันกําหนดคุณค่าและหลักการสําคัญของการสร้างแบบจําลองภัยคุกคาม รวมถึงคําถามสําคัญทีแบบจําลองภัยคุกคามทุก
แบบต้องตอบให้ได้:
 เรากําลังทํางานกับอะไรอยู่?
 อะไรทีอาจผิดพลาดได้?
 เราจะทําอะไรเกียวกับมัน?
 เราทําได้ดีพอหรือยัง?
ดังทีแสดงในรูปที 2.3 คําถามแต่ละข้อเป็ นตัวแทนของแต่ละขันตอนในกระบวนการสร้างแบบจําลองภัยคุกคาม เพือช่วย
ให้เราดําเนินกระบวนการนีได้อย่างมีประสิทธิภาพ Open Worldwide Application Security Project (OWASP) ได้จดั ทําคู่มอื
ทีมีประโยชน์เกียวกับการสร้างแบบจําลองภัยคุกคาม
(https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html) คู่มอื นีแบ่งกระบวนการสร้าง
แบบจําลองภัยคุกคามออกเป็ น 4 ขันตอน ซึงแต่ละขันตอนสอดคล้องกับคําถามใน Threat Modeling Manifesto ดังนี:
1.
2.
3.
4.
การแยกส่วนประกอบของแอปพลิเคชัน (application decomposition): เรากําลังทํางานกับอะไรอยู่?
การระบุและจัดลําดับภัยคุกคาม (threat identification and ranking): อะไรทีอาจผิดพลาดได้?
การตอบสนองและลดความเสียง (response and mitigations): เราจะทําอะไรเกียวกับมัน?
การตรวจสอบและการยืนยัน (review and validation): เราทําได้ดีพอหรือยัง?
มาดูรายละเอียดในแต่ละขันตอนกัน
รูปที 2.1 การนําทางโค้ดของคุณจะง่ายขึนหากคุณจัดระเบียบโค้ดเป็ นไดเรกทอรีและแยกไฟล์ออกจากกัน แทนทีจะเก็บแอปพลิเคชันทังหมด
ไว้ในไฟล์ยาวๆ ไฟล์เดียว
รูปที 2.3 คําถามแต่ละข้อใน Threat Modeling Manifesto สอดคล้องกับขันตอนในกระบวนการสร้างแบบจําลองภัย
คุกคาม ในตัวอย่างนี เราแสดงให้เห็นว่าการสร้างแบบจําลองช่องโหว่ SQL injection ในจุดเชือมต่อรายการข้อมูล (listing
endpoint) ดําเนินการอย่างไร และวิธีทีเราจัดการแก้ไขปั ญหาดังกล่าว
2.2.1 การแยกส่วนประกอบของแอปพลิเคชัน (Application decomposition)
ขันตอนแรกคือการแยกส่วนประกอบของแอปพลิเคชัน ซึงสอดคล้องกับคําถาม "เรากําลังทํางานกับอะไรอยู่?" แนวคิด
คือการทําความเข้าใจว่า ข้อมูล ไหลผ่านระบบอย่างไร และส่วนประกอบใดบ้างทีมีสว่ นร่วมในการประมวลผลข้อมูล เนืองจาก
เรามุง่ เน้นไปทีการโต้ตอบของผูใ้ ช้ (ทีอาจเป็ นอันตราย) วิธีทเป็
ี นประโยชน์คือการใช้ แผนภาพการไหลของข้อมูล (Data Flow
Diagrams: DFDs)
DFDs ทีดีช่วยให้เรามองเห็นว่า ข้อมูล ไหลผ่านระบบอย่างไร และส่วนประกอบใดทีเกียวข้อง ตัวอย่างเช่น จะเกิดอะไร
ขึนเมือผูใ้ ช้อปั เดตทรัพยากรผ่าน API แต่ละส่วนประกอบทีมีส่วนร่วมในการประมวลผลข้อมูลนันแสดงถึงช่องทางทีอาจถูก
โจมตีได้ (attack vector)
รูปที 2.4 แสดง DFD ของการทีผูใ้ ช้อปั เดตโปรไฟล์ของตนพร้อมกับรูปภาพโปรไฟล์ (avatar) โดยใช้ URL ภายนอก โดย
เน้นในสีแดงเพือแสดงช่องทางการโจมตีทีอาจเกิดขึน (potential attack vectors)
รูปที . แผนภาพการไหลของข้อมูล (DFD) แสดงกรณีทีผูใ้ ช้อปั เดตรูปภาพโปรไฟล์ (avatar) ของตนโดยใช้ URL ภายนอก ในกรณีนี URL
อาจถูกใช้เพือทําการสแกนพอร์ตภายในเครือข่ายส่วนตัวของเรา เข้าถึงบริการภายใน ฐานข้อมูลของเรา ทําให้โทเคนการเข้าถึงรัวไหล และ
อืนๆ
2.2.2 การระบุและจัดลําดับภัยคุกคาม (Threat identification and ranking)
ขันตอนถัดไปคือการระบุและจัดลําดับภัยคุกคาม ซึงสอดคล้องกับคําถาม "อะไรทีอาจผิดพลาดได้?" ในขันตอนนี เรา
พยายามคิดในมุมมองของแฮ็กเกอร์ และมองหาวิธีทีพวกเขาอาจเจาะระบบหรือใช้งานระบบในทางทีผิด
เพือช่วยในการสร้างแบบจําลองกลยุทธ์การโจมตี เราใช้กรอบการทํางานสําหรับการสร้างแบบจําลองภัยคุกคาม เช่น
STRIDE ซึงเป็ นกรอบการทํางานทีนิยมใช้ในการจัดหมวดหมู่ภยั คุกคามทีเป็ นไปได้
หมายเหตุ
กรอบการทํางาน STRIDE ถูกพัฒนาโดย Loren Kohnfelder และ Garg Praerit ในปี 1999 ขณะทํางานที Microsoft ใน
เอกสารชือ “The Threats to our Products” แม้วา่ เอกสารดังกล่าวจะไม่มใี ห้ดาวน์โหลดบนเว็บไซต์ของ Microsoft แล้ว
แต่คณ
ุ สามารถดาวน์โหลดได้จากเว็บไซต์ของ Adam Shostack ที URL ต่อไปนี:
https://shostack.org/files/microsoft/The-Threats-To-Our-Products.docx
Adam Shostack ยังเป็ นผูเ้ ขียนหนังสือทียอดเยียมเกียวกับการสร้างแบบจําลองภัยคุกคามชือ Threat Modeling:
Designing for Security (Wiley, 2014)
นอกเหนือจาก STRIDE ยังมีกรอบการทํางานอืนๆ สําหรับการสร้างแบบจําลองภัยคุกคาม เช่น LINDDUN, OCTAVE,
PASTA, TRIKE, และ VAST คุณสามารถอ่านเพิมเติมเกียวกับกรอบการทํางานเหล่านีได้ใน OWASP’s Threat
Modeling Cheat Sheet ทีลิงก์น:ี
https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html
รูปที 2.5 แสดงให้เห็นว่า หมวดหมู่ภยั คุกคามของ STRIDE สามารถโจมตีระบบได้จากทุกมุม เรามาแยกย่อยแต่ละ
หมวดหมู่:
 Spoofing (การปลอมแปลง): ความเสียงในการขโมยข้อมูลประจําตัวของผูใ้ ช้และเข้ายึดบัญชีของผูใ้ ช้อืน
 Tampering (การดัดแปลง): ความเสียงในการแก้ไขข้อมูลหรือทําการอัปเดตข้อมูลทีไม่ตงใจ
ั
 Repudiation (การปฏิเสธความรับผิดชอบ):
อันตรายได้ [3]
ความเสียงทีไม่สามารถตรวจพบและติดตามกิจกรรมทีเป็ น
 Information Disclosure (การเปิ ดเผยข้อมูล): ความเสียงในการรัวไหลของรายละเอียดระบบ การตังค่าคอน
ฟิ ก หรือข้อมูลทีอ่อนไหว (การละเมิดข้อมูล)
 Denial of Service (การปฏิเสธการให้บริการ): ความเสียงทีระบบจะไม่สามารถใช้งานได้
 Elevation of Privileges (การยกระดับสิทธิ): ความเสียงทีผูโ้ จมตีจะได้รบั สิทธิทีพวกเขาไม่มี
รูปที . แต่ละหมวดหมู่ภยั คุกคามใน STRIDE แสดงถึงกลยุทธ์ทีแตกต่างกันในการเจาะระบบของเราหรือขโมยข้อมูลจาก API ของเรา
หน้าทีของเราคือการระบุสิงทีอาจผิดพลาดในแต่ละหมวดหมูเ่ หล่านี ตัวอย่างเช่น ผูใ้ ช้งานทีเป็ นอันตรายสามารถขโมย
โทเคนการเข้าถึงได้อย่างไร? พวกเขาสามารถหลีกเลียงการควบคุมการเข้าถึงได้อย่างไร? พวกเขาสามารถเข้าถึงข้อมูลของ
ผูใ้ ช้งานรายอืนได้อย่างไร? หรือพวกเขาจะสามารถขโมยรายละเอียดการกําหนดค่าของระบบของเราได้อย่างไร? จัดการประชุม
ระดมความคิดกับทีมของคุณเพือค้นหาภัยคุกคามทีอาจเกิดขึน หรือเล่นเกม เช่น Elevation of Privilege [4] เพือช่วยใน
กระบวนการคิด
ด้วยการเติบโตของเครืองมือ Generative AI ทีช่วยในการพัฒนาซอฟต์แวร์ แอปพลิเคชันจํานวนมากได้เกิดขึนในด้าน
ความปลอดภัยทางไซเบอร์ เช่น STRIDE GPT ของ Matt Adam (https://github.com/mrwadams/stride-gpt) [5] คุณสามารถ
พิจารณาใช้เครืองมือ เช่น STRIDE GPT หากต้องการคําแนะนําเพิมเติมและความช่วยเหลือในการสร้างโมเดลภัยคุกคาม
วิธีทีดีทีสุดในการตอบคําถามข้างต้นคือการนําเสนอผูใ้ ช้งานและการไหลของข้อมูลทีเกียวข้องกับภัยคุกคามแต่ละอย่าง
และวิเคราะห์ช่องโหว่ของระบบ ตัวอย่างเช่น องค์กรหลายแห่งใช้ระบบการจัดการผูใ้ ช้งานทีมีขนตอนการอนุ
ั
ญาตแบบกําหนด
เอง รูปที 2.6 แสดงให้เห็นช่องโหว่ทวไปในระบบเหล่
ั
านีทีช่วยให้ผใู้ ช้งานทีเป็ นอันตรายสามารถรับโทเคนการเข้าถึงจากผูใ้ ช้งาน
รายอืนได้โดยการทําลายลายเซ็นทีไม่รดั กุมและสร้างโทเคนของตนเองขึนมา [6]
รูปที . ช่องโหว่ทวไปในเซิ
ั
รฟ์ เวอร์การอนุญาตแบบกําหนดเองคือการออกโทเคนทีมีลายเซ็นทีไม่รดั กุม ในตัวอย่างนี ผูไ้ ม่หวังดีสามารถ
ทําลายลายเซ็นของโทเคนและสร้างโทเคนทีมีสิทธิผูด้ แู ลระบบขึนมาได้
เมือเราระบุภยั คุกคามต่อระบบของเราได้แล้ว ขันตอนต่อไปคือการจัดลําดับความสําคัญของภัยคุกคามเหล่านัน เรา
จัดลําดับภัยคุกคามตามความเป็ นไปได้ทีจะเกิดขึนและผลกระทบต่อธุรกิจ
เกณฑ์การจัดลําดับความสําคัญจะขึนอยู่กบั
ลักษณะขององค์กรและธุรกิจของเราโดยเฉพาะ ตัวอย่างเช่น การโจมตีดว้ ย SQL Injection อาจถูกใช้เพือขโมยหรือทําลาย
ข้อมูลในระบบของเรา หากการออกแบบ API ของเรามีช่องโหว่ต่อการโจมตี SQL Injection นันถือเป็ นสัญญาณอันตราย
อย่างไรก็ตาม หากเราใช้การพารามิเตอร์ในคําสังฐานข้อมูลทังหมดและมีไฟร์วอลล์สาํ หรับแอปพลิเคชันเว็บ (Web Application
Firewall หรือ WAF ซึงเราจะเรียนรูเ้ พิมเติมในบทที 8) SQL Injection จะถือเป็ นภัยคุกคามทีมีโอกาสเกิดตํา
การจัดลําดับความสําคัญควรดําเนินการร่วมกับผูม้ ีส่วนได้สว่ นเสียอย่างใกล้ชิด และถือเป็ นโอกาสทีดีในการสร้างความ
ตระหนักรูเ้ กียวกับความเสียงด้านความปลอดภัยของ API กับพวกเขา
2.2.3 การตอบสนองและการลดผลกระทบ
เมือเราระบุและจัดลําดับความสําคัญของภัยคุกคามต่อ API ของเราได้แล้ว ขันตอนต่อไปคือการตอบคําถามว่า “เราจะ
ทําอะไรกับมัน?” เราต้องกําหนดการตอบสนองต่อภัยคุกคามแต่ละอย่าง Adam Shostack ผูเ้ ขียนหนังสือทีมีชอเสี
ื ยง Threat
Modeling: Designing for Security (Wiley, 2014) ได้แยกประเภทการตอบสนองไว้ดงั นี:
 Mitigate: ทําให้ระบบแข็งแกร่งขึนเพือลดความเป็ นไปได้ของภัยคุกคาม ตัวอย่างเช่น การใช้งานการจํากัด
จํานวนคําขอ (rate-limiting) ใน API เพือป้องกันการโจมตีแบบ brute-force
 Eliminate: หากฟี เจอร์ทเป็
ี นต้นเหตุของภัยคุกคามไม่สาํ คัญต่อธุรกิจ ให้ลบฟี เจอร์นนออก
ั
ตัวอย่างเช่น หาก
API ของเราอนุญาตให้ผใู้ ช้งานส่ง URL ทีระบบของเราจะดึงข้อมูลมา เช่น รูปภาพหรือรายละเอียดของบริษัท
ผูไ้ ม่หวังดีอาจใช้ฟีเจอร์นีเพือทําการสแกนพอร์ต (port scanning) หรือการโจมตีอืน ๆ หากฟี เจอร์นีไม่จาํ เป็ น
สําหรับแอปพลิเคชันของเรา เราอาจตัดสินใจลบมันออก
 Transfer: หากค่าใช้จ่ายในการจัดการภัยคุกคามสูงเกินไป เราอาจเลือกทีจะโอนความรับผิดชอบไปยังตัวแทน
อืน เช่น ลูกค้า ตัวอย่างเช่น หาก API ของเราอนุญาตให้สร้างลิงก์ทีแชร์ได้สาํ หรับทรัพยากรทีมีขอ้ มูลสําคัญสูง
เราอาจตัดสินใจว่าความรับผิดชอบอยู่ทีผูใ้ ช้งานในการตรวจสอบให้แน่ใจว่าลิงก์นนถู
ั กส่งไปยังผูร้ บั ที
เหมาะสมเท่านัน และปิ ดการใช้งานลิงก์เมือพบการเข้าถึงทีน่าสงสัย
 Accept: หากภัยคุกคามมีระดับความเสียงทียอมรับได้สาํ หรับธุรกิจ เราอาจเลือกทีจะไม่ดาํ เนินการใด ๆ
ตัวอย่างเช่น หาก API ของเราให้ส่วนลดแก่ลกู ค้าทีแนะนําผูใ้ ช้งานใหม่เข้าสู่แพลตฟอร์ม ผูไ้ ม่หวังดีอาจใช้ช่อง
โหว่นีเพือสร้างผูใ้ ช้งานปลอม อย่างไรก็ตาม หากเว็บไซต์ของเราอยูใ่ นช่วงเริมต้นของการเติบโต เราอาจ
ตัดสินใจว่านีเป็ นต้นทุนเล็กน้อยทียอมรับได้เพือขยายฐานผูใ้ ช้งานของเรา
การตอบสนองต่อภัยคุกคามของเรามีผลกระทบโดยตรงต่อธุรกิจ Mitigate หมายถึงการเพิมงานเพือทําให้ระบบ
แข็งแกร่งขึน ในขณะที Eliminate หมายถึงการลบฟี เจอร์ออกจากแอปพลิเคชันของเรา และ Transfer หมายถึงการเปลียนแปลง
รูปแบบความรับผิดชอบในธุรกิจของเรา ด้วยเหตุนี การนําผูม้ ีส่วนได้ส่วนเสียทีเกียวข้องมาร่วมพิจารณาเพือตัดสินใจเลือกการ
ตอบสนองทีเหมาะสมทีสุดต่อแต่ละภัยคุกคามจึงเป็ นเรืองสําคัญ
2.2.4 การทบทวนและการตรวจสอบความถูกต้อง
เมือเราได้กาํ หนดวิธีการตอบสนองต่อภัยคุกคามของเราแล้ว ก็ถงึ เวลาทีจะตอบคําถามสุดท้าย: "เราทํางานได้ดีพอหรือ
ยัง?" นีเป็ นช่วงเวลาทีดีในการทบทวนงานทังหมดทีเราทํามาก่อนหน้านีและรวมทีมของเราเข้าด้วยกัน ระบบ DFD ของเรา
สะท้อนระบบของเราได้อย่างถูกต้องหรือไม่? เราระบุภยั คุกคามทังหมดได้ครบถ้วนหรือยัง? เราได้เชิญทีมและผูม้ ีสว่ นได้ส่วน
เสียทีเกียวข้องเข้าร่วมในกระบวนการสร้างแบบจําลองภัยคุกคามและการแก้ไขปั ญหาหรือยัง? เราสามารถตรวจสอบได้หรือไม่
ว่าการตอบสนองต่อภัยคุกคามของเราทํางานได้ผล?
จัดการประชุมสรุปกับทีมของคุณเพือสะท้อนถึงกระบวนการสร้าง
แบบจําลองภัยคุกคามของคุณและระบุการปรับปรุงสําหรับอนาคต
คํานิยาม
ในกระบวนการพัฒนาซอฟต์แวร์แบบ Agile การประชุมสรุปงาน (retrospective) เป็ นการประชุมทีมทีจัดขึนเมือสินสุด
รอบการทํางาน (iteration) หรือโครงการ เพือพูดคุยเกียวกับโอกาสในการปรับปรุงสําหรับรอบการทํางานในอนาคต และ
ระบุสิงทีได้ผลดีทีทีมควรทําต่อไป หากต้องการเรียนรูเ้ พิมเติมเกียวกับการประชุมสรุปงาน สามารถศึกษาได้จากหนังสือ
Retrospectives Antipatterns โดย Aino Vonge Corry (Addison-Wesley, 2020)
คําถามสําคัญในจุดนีคือ: เราควรทําการสร้างแบบจําลองภัยคุกคามเมือไหร่? คําตอบคือ ตลอดเวลา! การสร้าง
แบบจําลองภัยคุกคามควรเป็ นกิจกรรมทีทําอย่างต่อเนืองเพือประเมินช่องโหว่ของระบบและรวบรวมผูม้ ีส่วนได้ส่วนเสียทังหมด
มาร่วมกันตระหนักถึงความสําคัญของความปลอดภัยของ API ระบบของเรามีแนวโน้มทีจะพัฒนาและเปลียนแปลงอยู่
ตลอดเวลา ดังนันจึงเป็ นความคิดทีดีทีจะจัดการฝึ กสร้างแบบจําลองภัยคุกคามทุกๆ สองสามเดือน (เช่น ทุกไตรมาสหรือปี ละ
สองครัง) เพือประเมินระบบของเราใหม่ โดยในอุดมคติแล้ว เราควรเริมทําการสร้างแบบจําลองภัยคุกคามตังแต่ชว่ งต้นของ
กระบวนการออกแบบ API ซึงจะช่วยให้ความปลอดภัย “ถูกรวมไว้” ใน API ของคุณตังแต่แรก แทนทีจะ “เพิมเติมเข้าไป
ภายหลัง” [7]
2.3 ลงมือทําเดียวนี!
เราควรเริมจัดการกับความปลอดภัยของ API เมือไหร่และอย่างไร? เมือคุณเรียนรูเ้ พิมเติมเกียวกับความปลอดภัยของ
API และผลกระทบทีมีต่อองค์กรของคุณ คุณอาจต้องการจัดการทุกอย่างพร้อมกันในทันที แต่ความจริงคือ คุณไม่สามารถก้าว
จากจุดเริมต้นไปสู่ความเชียวชาญได้ในชัวข้ามคืน การพัฒนาให้องค์กรมีความเป็ นผูใ้ หญ่ในด้านความปลอดภัยของ API อาจ
ใช้เวลาหลายเดือนหรือแม้แต่หลายปี หากคุณเริมต้นเส้นทางความปลอดภัยของ API โดยการรับมือกับปัญหาทีซับซ้อนทีสุด
ตังแต่ตน้ ความก้าวหน้าอาจดูชา้ และทําให้คณ
ุ และทีมรูส้ กึ หมดกําลังใจ คําแนะนําของฉันคือเริมต้นด้วยการจัดการกับสิงทีทํา
ได้ง่ายแต่ให้ผลกระทบมากทีสุดต่อองค์กรของคุณ สิงนีจะช่วยสร้างแรงผลักดันและความมันใจในความสามารถของคุณในการ
จัดการความปลอดภัยของ API
แล้วสิงทีง่ายแต่ให้ผลกระทบมากทีสุดคืออะไร? ขึนอยู่กบั ว่าคุณอยู่ในระดับใดของการพัฒนาความปลอดภัยของ API
ลองย้อนกลับไปดูตาราง 2.1 เพือกําหนดระดับความพร้อมของคุณ หากระดับความพร้อมด้านความปลอดภัยของ API ของคุณ
ตํา ให้เริมจากจุดนัน ตัวอย่างเช่น องค์กรหลายแห่งมีปัญหาในการอัปเดตเอกสาร API ของพวกเขา หรือบางองค์กรไม่มเี อกสาร
ทีเหมาะสมเลย ซึงหมายความว่าพวกเขาไม่ทราบว่าพืนทีเสียงต่อการโจมตีของตนเป็ นอย่างไร หากนันคือกรณีของคุณ ให้
เริมต้นทีนัน (ดูรายละเอียดเพิมเติมในส่วน 3.5 เกียวกับวิธีการจัดทําเอกสาร API ของคุณ)
แล้วถ้าพืนทีเสียงต่อการโจมตีของคุณอยู่ภายใต้การควบคุมแล้วล่ะ? อ่านต่อไป ในส่วนนี ฉันจะอธิบายขันตอนที
สามารถปฏิบตั ิได้ซงองค์
ึ กรใดๆ สามารถทําได้เพือปรับปรุงท่าทีดา้ นความปลอดภัยของ API รวมถึงการเสริมความแข็งแกร่ง
ให้กบั ระบบการยืนยันตัวตนและการให้สิทธิ การใช้ไลบรารี API ทีเหมาะสม และการใช้เครืองมือป้องกันบนคลาวด์ มาดู
รายละเอียดกัน!
2.3.1 จัดทําเอกสาร API ของคุณ
ตามรายงาน State of API Security Q1 2023 ของ Salt Security พบว่า มีเพียง 19% ขององค์กรทีรูส้ กึ มันใจว่าเอกสาร
API ของพวกเขามีความถูกต้อง [8] หากองค์กรของคุณอยู่ในกลุม่ อีก 81% นันถือเป็ นข่าวร้ายสําหรับองค์กรของคุณ และเป็ น
ข่าวดีสาํ หรับแฮกเกอร์ ดังทีคุณจะได้เรียนรูใ้ นส่วน 3.5 การจัดทําเอกสารเป็ นพืนฐานสําคัญของความปลอดภัย API และ
เอกสารก็มีหลายรูปแบบ ในกรณีนี เรากําลังมองหาการกําหนด API อย่างเป็ นทางการ หากไม่มีการกําหนดอย่างเป็ นทางการ
คุณไม่สามารถยืนยันได้ว่า API ของคุณถูกนําไปใช้อย่างถูกต้องหรือไม่ และคุณไม่สามารถทดสอบความปลอดภัยตามการ
ออกแบบของมันได้ จากประสบการณ์ของฉันในการทํางานกับองค์กรทีขายสินค้าและบริการผ่าน API เอกสาร API ทีล้าสมัย
หรือไม่ถกู ต้องยังส่งผลให้ลกู ค้าไม่พึงพอใจและสูญเสียธุรกิจอีกด้วย
หากคุณขาดการกําหนด API อย่างเป็ นทางการ หรือไม่มีการกําหนดเลย ฉันขอแนะนําให้คณ
ุ เริมต้นจากจุดนีก่อน การ
กําหนด API คือเอกสารทีบันทึกการออกแบบของ API ของเรา และดังทีคุณจะได้เรียนรูใ้ นบทที 4 และ 5 เราสามารถจัดการกับ
ช่องโหว่ของ API ได้หลายอย่างด้วยการเสริมความแข็งแกร่งให้กบั การออกแบบ เมือคุณมีการกําหนดอย่างเป็ นทางการ
เรียบร้อยแล้ว ขันตอนต่อไปทีดีทีสุดคือการใช้เอกสารนีในการทดสอบความปลอดภัยตามการกําหนด และตรวจสอบว่า API
ของคุณถูกนําไปใช้อย่างถูกต้องหรือไม่ ในบทที 12 คุณจะได้เรียนรูว้ ิธีการทดสอบดังกล่าว
2.3.2 เสริมความแข็งแกร่งในการยืนยันตัวตนและการอนุญาต
อีกหนึงวิธีทง่ี ายแต่ส่งผลกระทบอย่างมากต่อธุรกิจของคุณคือการปรับปรุงการยืนยันตัวตนและการอนุญาต
(Authentication and Authorization) หากคุณดูรายการภัยคุกคามด้านความปลอดภัย API 10 อันดับแรกของ OWASP
(https://owasp.org/API-Security/editions/2023/en/0x11-t10/ และดูเพิมเติมในบทที 5) คุณจะพบว่า 4 ใน 10 รายการ
เกียวข้องกับการยืนยันตัวตนและการอนุญาตทีอ่อนแอ (API1:2023, API2:2023, API3:2023 และ API5:2023) นอกจากนี
ตามทีผูเ้ ชียวชาญด้าน API ชันนําอย่าง Eric Newcomer ได้กล่าวไว้ การอนุญาตยังคงเป็ นความท้าทายทีใหญ่ทีสุดในด้าน
ความปลอดภัยของ API [9] ทีจริงแล้ว API หลายตัวถูกพัฒนาด้วยสมมติฐานว่าคําขอทังหมดทีได้รบั การยืนยันตัวตนเป็ นคําขอ
ทีถูกต้อง ซึงหมายความว่ามาตรการควบคุมการเข้าถึง (Access Control) บนจุดเชือมต่อทีสําคัญมักจะไม่มี หรือไม่เพียงพอ
[10] ยกตัวอย่างเช่น ในงานทีปรึกษาของผูเ้ ขียน ได้พบ API จํานวนมากทีไม่ได้บงั คับใช้การควบคุมการเข้าถึงตามผูใ้ ช้ใน
ฟั งก์ชนั เช่น DELETE และ PUT ซึงหมายความว่าผูใ้ ช้ทียืนยันตัวตนแล้วสามารถอัปเดตหรือลบทรัพยากรทีเป็ นของผูใ้ ช้อืนได้
ง่ายๆ นีคือทางลัดสู่การเกิดการรัวไหลของข้อมูล (Data Breach)
หากคุณไม่เคยทํามาก่อน ผูเ้ ขียนแนะนําให้คณ
ุ ตรวจสอบการควบคุมการเข้าถึงในทุกจุดเชือมต่อของ API จะดียงขึ
ิ น
หากคุณสร้างการทดสอบแบบอัตโนมัติเพือรันการตรวจสอบเหล่านีซํา ๆ คุณจะได้เรียนรูเ้ กียวกับการทดสอบประเภทนีเพิมเติม
ในบทที 12 แต่ตามทีคุณเห็นในภาพที 2.7 คุณสามารถเริมต้นได้แบบง่ายๆ เช่น สร้างผูใ้ ช้สองคน คือ A และ B พร้อมกับ
ทรัพยากรจํานวนหนึงทีเชือมโยงกับแต่ละคน จากนันตรวจสอบว่าผูใ้ ช้ A สามารถเข้าถึงทรัพยากรทีผูใ้ ช้ B ควรจะเป็ นเจ้าของได้
หรือไม่ หากสามารถทําได้ นันแสดงว่าคุณมีช่องโหว่ดา้ น Broken Object Level Authorization (BOLA) ให้แน่ใจว่าคุณได้แก้ไข
ปั ญหานี และรันการทดสอบแบบเดียวกันนีทุกครังทีมีการเปลียนแปลง API ในอนาคต แม้ว่านีจะเป็ นงานทีน่าเบือ และยิง API
มีขนาดใหญ่และซับซ้อนมากเท่าไร การสร้างชุดการทดสอบ (Test Suite) ก็จะใช้เวลามากขึนเท่านัน แต่ขออย่าเพิงท้อแท้ ให้
ดําเนินการทีละขันตอน การแก้ไขช่องโหว่ในจุดเชือมต่อเพียงจุดเดียวก็ถือว่าเป็ นประโยชน์อย่างมากต่อองค์กรของคุณแล้ว
รูปที . เริมทดสอบการควบคุมการเข้าถึงของคุณด้วยสถานการณ์ทีง่าย ๆ ตัวอย่างเช่น สร้างผูใ้ ช้สองคน คือ A และ B ให้ผใู้ ช้ A ทําการ
ชําระเงิน และตรวจสอบว่าผูใ้ ช้ B สามารถเข้าถึงรายละเอียดการชําระเงินของผูใ้ ช้ A ได้หรือไม่
อีกหนึงช่องโหว่ทีพบได้บ่อยเกียวข้องกับการยืนยันตัวตนทีอ่อนแอ การยืนยันตัวตนและการอนุญาตเป็ นกระบวนการที
ซับซ้อน สําหรับ API นัน เรามีมาตรฐานจํานวนมากทีจําเป็ นต้องเข้าใจเพือให้สามารถดําเนินการยืนยันตัวตนและการอนุญาต
ได้อย่างปลอดภัย (เราจะทบทวนเรืองนีในบทที 6 และ 7) น่าเสียดายทีหลายองค์กรตกหลุมพรางคิดว่าพวกเขาสามารถ
หลีกเลียงมาตรฐานเหล่านีและสร้างระบบยืนยันตัวตนและการอนุญาตแบบง่าย ๆ ของตนเองได้ ผลลัพธ์ทีได้มกั จะเป็ นระบบ
ยืนยันตัวตนทีอ่อนแอ ซึงอาจถูกโจมตีเพือยึดบัญชีผใู้ ช้รายอืนหรือเข้าถึงข้อมูลประจําตัวผูด้ แู ลระบบได้ [11] หากคุณได้เลือก
เส้นทางการสร้างระบบยืนยันตัวตนและการอนุญาตของคุณเอง ผูเ้ ขียนแนะนําให้คณ
ุ ทําการตรวจสอบระบบโดยด่วน คุณ
อาจจะพบกับ "ความประหลาดใจ" บางอย่างทีไม่คาดคิด
แล้วในส่วนของโทเค็นการเข้าถึง (Access Tokens) ของคุณล่ะ? มาตรฐานสูงสุดสําหรับ API คือสเปก JSON Web
Token (JWT) ซึงเราจะศึกษารายละเอียดในบทที 6 พร้อมทังทางเลือกอืน ๆ JWT สามารถมีความปลอดภัยและทรงพลังมาก
แต่ก็สามารถถูกตังค่าผิดพลาดได้ง่ายจนทําให้ขอ้ ดีทงหมดสู
ั
ญเสียไป ตัวอย่างเช่น โทเค็น JWT ของคุณมีขอ้ มูลส่วนบุคคลหรือ
ข้อมูลทีเป็ นความลับหรือไม่? เพราะมันไม่ควรมี คุณใช้วิธีการเซ็นชือ (Signing Algorithm) แบบใด? ไลบรารีตรวจสอบ JWT
ของคุณอนุญาตให้ระบุอลั กอริธมึ แบบสุ่มได้หรือไม่? เพราะหากเป็ นเช่นนัน โทเค็น JWT ของคุณจะมีช่องโหว่อย่างมาก และ
สุดท้าย แต่ไม่ทา้ ยสุด: คุณกําลังใช้โทเค็นการเข้าถึงจริง ๆ หรือเปล่า หรือกําลังใช้โทเค็นสําหรับยืนยันตัวตน (ID Tokens) แทน?
2.3.3 ใช้ไลบรารี API ทีเหมาะสม
คําแนะนําหนึงทีผูเ้ ขียนมอบให้กบั ทุกองค์กรทีทํางานด้วยคือการใช้ไลบรารี API ทีเหมาะสม API นันดูเหมือนจะเรียบ
ง่าย แต่จริง ๆ แล้วซับซ้อนกว่าทีคิด หลังจากทังหมดแล้ว การจัดการ URL query parameters และ request payloads จะยาก
แค่ไหน? ในความเป็ นจริง มันซับซ้อนมาก ซึงเป็ นเหตุผลว่าทําไมเราจึงมีไลบรารีและระบบนิเวศต่าง ๆ ทีสร้างขึนเพือจัดการเรือง
นี โอกาสทีดีทีสุดในการสร้าง API ทีแข็งแกร่งคือการใช้หนึงในไลบรารีเหล่านี ยกตัวอย่างเช่น หากคุณมีเซิรฟ์ เวอร์เว็บทีสร้าง
ด้วย Flask และต้องการเพิม API ให้ใช้ไลบรารี Flask API ทีเหมาะสม เช่น APIFlask (https://github.com/apiflask/apiflask)
หรือ Flask-smorest (https://github.com/marshmallow-code/flask-smorest) หากคุณใช้ Django ให้ใช้ Django Rest
Framework (https://github.com/encode/django-rest-framework) หรือ Django Ninja (https://github.com/vitalik/djangoninja)
หากคุณมี API ทีสร้างไว้แล้วโดยไม่ได้ใช้ไลบรารี API ทีเหมาะสม คุณจะต้องทําการย้ายระบบ (Migration) เพือให้งาน
ย้ายระบบจากไลบรารีหรือเฟรมเวิรก์ หนึงไปอีกอันหนึงง่ายขึน
ผูเ้ ขียนใช้สถาปัตยกรรมแบบหกเหลียม
(Hexagonal
Architecture หรือ HA) HA หรือสถาปั ตยกรรมแบบพอร์ตและอะแดปเตอร์ (Ports and Adapters) จะช่วยแยกส่วนของชันธุรกิจ
(Business Layer) ออกจากส่วนทีเป็ นการพึงพาภายนอก (Ports) และใช้อะแดปเตอร์ (Adapters) เพือเชือมต่อกับพอร์ต
เหล่านัน ชัน API ของแอปพลิเคชันคุณคือส่วนทีใช้ประกาศเส้นทาง (Routes) และประมวลผลคําขอ (Requests) และใน HA
ชัน API นีถือว่าเป็ นพอร์ต เนืองจากชัน API ถูกแยกออกจากกันอย่างอิสระ การเปลียนไปใช้เฟรมเวิรก์ อืนจึงเพียงแค่ตอ้ งอัปเดต
ชัน API ของคุณเท่านัน [12]
เช่นเคย ให้ดาํ เนินการทีละขัน เริมต้นด้วยส่วนเล็ก ๆ ของ API ของคุณ และย้ายจุดเชือมต่อ (Endpoints) ทีละจุด คุณจะ
สัมผัสถึงประโยชน์ได้ในทันที
2.3.4 ใช้เครืองมือป้องกันบนระบบคลาวด์
สุดท้ายนี หากคุณยังไม่ได้ใช้งาน API Gateway หรือ Web Application Firewall (WAF) การใช้เทคโนโลยีเหล่านีจะช่วย
ปรับปรุงสถานะความปลอดภัยของ API ของคุณได้ทนั ที API Gateway สามารถจัดการการตรวจสอบโทเค็นการเข้าถึงที
ปลอดภัย (Secure Access Token Validation), การป้องกัน DDoS, การจํากัดอัตราการร้องขอ (Rate Limiting) และอืน ๆ ใน
หลายกรณี API Gateway ยังช่วยลดพืนทีทีอาจตกเป็ นเป้าหมายของการโจมตีได้อกี ด้วย ยกตัวอย่างเช่น หลายองค์กรประสบ
ปั ญหาเกียวกับ Shadow APIs ซึงก็คือ API และจุดเชือมต่อ (Endpoints) ทีไม่มีเอกสารกํากับอยู่ในโค้ดของคุณ [13] API
Gateway ช่วยให้คณ
ุ กําหนดได้วา่ Endpoint ใดบ้างทีสามารถเปิ ดเผยได้ ซึงจะช่วยลดความเสียงจาก Shadow Endpoints ได้
ในลักษณะเดียวกัน WAF คือไฟร์วอลล์ทีตรวจสอบทราฟฟิ ก HTTP และปกป้องแอปพลิเคชันจากภัยคุกคามบนเว็บที
เป็ นทีรูจ้ กั เช่น การโจมตีดว้ ย SQL Injection และ Server-Side Request Forgery (SSRF) WAF รุน่ ใหม่สามารถใช้ขอ้ มูล
จําเพาะของ API (API Specification) เพือปรับการป้องกันให้เหมาะสมกับความต้องการเฉพาะของ API ของเรา
คุณสามารถผสาน API Gateway กับ WAF เพือเพิมการป้องกันได้อีกขัน WAF จะเพิมชันการป้องกันเพิมเติมสําหรับคํา
ขอทีน่าสงสัย การโจมตีดว้ ย SQL Injection, บอท, และอืน ๆ อย่างไรก็ตาม มีคาํ เตือนสําคัญอยู่อย่างหนึง: งานวิจยั แสดงให้เห็น
ว่าเทคโนโลยีอย่าง API Gateway และ WAF อาจทําให้องค์กรมีความมันใจในความปลอดภัยของ API มากเกินไป [14] อย่าตก
หลุมพรางนี API Gateway และ WAF มีประโยชน์ แต่ไม่เพียงพอทีจะปกป้อง API ของคุณได้อย่างสมบูรณ์ ตัวอย่างเช่น ทังสอง
เทคโนโลยีนีไม่สามารถป้องกัน OWASP API1:2023 Broken Object Level Authorization ซึงเกิดขึนเมือผูใ้ ช้สามารถเข้าถึง
ทรัพยากรทีไม่ใช่ของตนเองได้
ดังทีคุณเห็น มีหลายสิงทีคุณสามารถเริมทําได้ทนั ทีเพือจัดการกับความปลอดภัยของ API ในองค์กรของคุณ สิงเหล่านี
คือ "ผลไม้ทีเก็บง่าย" ทีจะให้ผลลัพธ์ทคุี ม้ ค่ามากทีสุด เมือคุณมีความก้าวหน้าในเส้นทางการรักษาความปลอดภัย API คําถาม
ทีสําคัญก็คือ คุณจะทําให้แนวทางการรักษาความปลอดภัยของคุณเป็ นระบบและทําให้ทกุ คนปฏิบตั ิตามได้อย่างไร? นีคือ
หัวข้อทีจะกล่าวถึงในส่วนต่อไป
2.4 การสร้างโปรแกรมความปลอดภัย API
เมือองค์กรของคุณเติบโตขึนและ API ของคุณมีขนาดใหญ่และซับซ้อนมากขึน คําถามทีชัดเจนคือ คุณจะทําอย่างไรให้
API ของคุณยังคงปลอดภัยอยู่เสมอ? หลายครังโครงการด้านความปลอดภัยของ API เริมต้นจากผูส้ นับสนุนเพียงคนเดียว ซึง
อาจเป็ นคุณผูอ้ ่าน เมือคุณเริมตระหนักถึงความสําคัญของความปลอดภัยของ API คุณอาจต้องการเป็ นผูน้ าํ ในการผลักดัน
ประเด็นนีในองค์กรของคุณ สิงทีคุณจะตระหนักคือ ความปลอดภัยของ API ไม่ใช่งานของคนเพียงคนเดียวหรือทีมใดทีมหนึง
ความปลอดภัยของ API เป็ นความรับผิดชอบของทุกคน โดยความปลอดภัยต้องเป็ นส่วนหนึงของกระบวนการพัฒนา API แล้ว
คุณจะทําได้อย่างไร? ด้วยการสร้างโปรแกรมความปลอดภัย API
โปรแกรมความปลอดภัย API คือการสรุปกลยุทธ์ความปลอดภัยของ API ของคุณ มันจะอธิบายวิสยั ทัศน์และเป้าหมาย
รวมถึงแผนการทีคุณจะใช้เพือบรรลุเป้าหมายเหล่านัน หากคุณไม่เคยจัดการกับความปลอดภัยของ API ในระดับองค์กรมา
ก่อน อย่าตังเป้าหมายทีทะเยอทะยานเกินไปในตอนเริมต้น คุณต้องมองสิงทีสามารถทําได้จริงอย่างสมเหตุสมผล และต้อง
ได้รบั การสนับสนุนจากองค์กรของคุณ (ดูในหัวข้อ 2.5) ทีสําคัญ คุณต้องมีการกํากับดูแล (Governance) ทีมีประสิทธิภาพ
เพือให้แน่ใจว่าทุกอย่างสอดคล้องกัน และกลยุทธ์ความปลอดภัย API ของคุณได้รบั การดําเนินการ
ผูเ้ ชียวชาญด้าน API ชันนําอย่าง Lorna Mitchell ได้กล่าวถึงส่วนผสมสําคัญของการกํากับดูแล API (API Governance)
ทีประสบความสําเร็จ หรือทีเธอเรียกว่า “การกํากับดูแลทีไม่มีนาตา”
ํ
[15] ดังนี:
 เขียนมาตรฐานของคุณและทําให้มนั เรียบง่าย เอกสารนีเป็ นสิงสําคัญในการทําให้ทกุ คนเข้าใจตรงกันเกียวกับ
ความปลอดภัยของ API ดังนันควรเขียนให้กระชับและตรงประเด็น พร้อมทังเข้าถึงได้งา่ ย (เช่น เก็บไว้ใน
GitHub repository แทนทีจะเป็ นหน้าเอกสารกระจัดกระจายบน Confluence) คุณสามารถทําให้เอกสารนีมี
ประโยชน์มากขึนได้โดยการใส่ตวั อย่างโค้ดและอ้างอิงแหล่งข้อมูลภายนอก
 รับฟั งความคิดเห็นจากผูม้ ีสว่ นเกียวข้องในองค์กรของคุณ รวมถึงสถาปนิก นักพัฒนา ผูจ้ ดั การผลิตภัณฑ์ และ
คนอืน ๆ คนมักจะมีสว่ นร่วมมากขึนเมือพวกเขารูส้ กึ ว่าความคิดเห็นของพวกเขาได้รบั การรับฟั ง นีจึงเป็ นวิธีทีดี
ในการได้รบั การสนับสนุนจากทุกฝ่ าย
 ทําให้เป็ นระบบอัตโนมัติ หากคุณเคยอยู่ในแวดวงซอฟต์แวร์มาสักระยะ คุณจะรูว้ ่าการบังคับใช้กฎเกณฑ์นัน
ทําได้ยากหากไม่มีระบบอัตโนมัติ ตัวอย่างเช่น ใช้เครืองมืออย่าง Spectral เพือทดสอบการออกแบบ API ของ
คุณด้านความปลอดภัย หรือใช้ Schemathesis เพือทดสอบการทํางานจริงของ API
เมือองค์กรของคุณเติบโตขึนในด้านความเชียวชาญและความมันใจในความปลอดภัยของ API คุณอาจต้องการ
ยกระดับสิงทีคุณทําไปอีกขัน หากคุณได้รบั การสนับสนุนทีเพียงพอจากองค์กรของคุณ นีคือตอนทีคุณสามารถก้าวข้ามสิง
พืนฐานและจัดการกับปั ญหาทีซับซ้อนมากขึน เช่น รวมการฝึ กอบรมด้านความปลอดภัยของ API เป็ นส่วนหนึงของโปรแกรม
วางแผนการตอบสนองต่อเหตุการณ์ (Incident Response Plan) หรือทํางานเกียวกับเทคนิคการตรวจจับภัยคุกคามขันสูง (เรา
จะพูดถึงในบทที 9)
ในการทําสิงเหล่านี คุณจะต้องได้รบั การสนับสนุนจากส่วนทีเหลือขององค์กร ซึงเป็ นหัวข้อในส่วนถัดไป
2.5 ทําให้ความปลอดภัยของ API สอดคล้องกับองค์กรของคุณ
องค์กรส่วนใหญ่มกั ต้องการพัฒนาซอฟต์แวร์ให้เร็วทีสุดเท่าทีจะเป็ นไปได้ ซึงมักแลกมากับความปลอดภัย อย่างไรก็
ตาม คุณไม่สามารถผลักดันแนวทางนีไปได้ไกลนักก่อนทีจะเผชิญกับการละเมิดข้อมูล (Data Breach) ดังที Corey Ball ได้
กล่าวไว้ว่า “ถ้าคุณไม่ทดสอบ [API ของคุณ] อาชญากรไซเบอร์ทีไหนสักแห่งจะทําแทนคุณ” [16] จากประสบการณ์ของผูเ้ ขียน
องค์กรส่วนใหญ่ให้ความสําคัญกับความปลอดภัยของ API แต่พวกเขามักขาดความรูห้ รือคําแนะนําว่าจะรักษาความปลอดภัย
ให้กบั API อย่างมีประสิทธิภาพได้อย่างไร วิธีแก้ปัญหาทีพบได้ทวไปคื
ั อการมอบหมายงานด้านความปลอดภัยของ API ให้กบั
ทีมความปลอดภัยทางไซเบอร์ อย่างไรก็ตาม ดังทีเราได้กล่าวถึงในส่วนก่อนหน้า ความปลอดภัยของ API ไม่ใช่งานของคนเพียง
คนเดียวหรือทีมใดทีมหนึง เราจําเป็ นต้องได้รบั ความร่วมมือจากทุกคน
เหตุผลทีความปลอดภัยของ API เป็ นหน้าทีของทุกคนในองค์กร คือทุกอย่างใน API ของเรา ตังแต่การออกแบบลําดับ
การทํางานของผูใ้ ช้ (User Flows) ไปจนถึงการเลือก Query Parameters และรายละเอียดการพัฒนา ล้วนส่งผลโดยตรงต่อ
สถานะความปลอดภัยของ API นอกจากนี ดังทีได้กล่าวในบทที 1 ความปลอดภัยของแอปพลิเคชันแบบดังเดิมไม่เพียงพอทีจะ
ปกป้อง API ของเราได้ เราต้องการแนวทางทีครอบคลุมยิงขึน ซึงครอบคลุมทังการออกแบบ การพัฒนา สถาปัตยกรรม และการ
ดําเนินงาน
การจัดการความปลอดภัยของ API อย่างถูกต้องอาจดูเหมือนเป็ นการเพิมงานให้กบั องค์กร และอาจทําให้การพัฒนา
ซอฟต์แวร์ชา้ ลงทันที เช่น ผูจ้ ดั การผลิตภัณฑ์จะต้องคํานึงถึงความปลอดภัยเมือออกแบบ User Flows นักพัฒนาจะต้องคุน้ เคย
กับไลบรารีทีเหมาะสมสําหรับการพัฒนา API เรียนรูก้ ารใช้งาน JWT อย่างถูกต้อง และศึกษามาตรฐานโปรโตคอล เช่น Open
Authorization (OAuth) และ OpenID Connect (OIDC) พวกเขาจะต้องทําการทดสอบทีเข้มงวดและครอบคลุมทังการ
ออกแบบและการพัฒนา API แล้วคุณจะทําให้สิงเหล่านีมีเหตุผลและได้รบั การยอมรับจากองค์กรของคุณได้อย่างไร?
พิจารณาต้นทุนของการไม่ทาํ หากคุณล้มเหลวในการจัดการความปลอดภัยของ API อย่างเหมาะสม คุณเสียงทีจะเกิด
การละเมิดข้อมูล ซึงมักมาพร้อมกับค่าปรับจํานวนมากและการสูญเสียความไว้วางใจในธุรกิจของคุณ ตามการวิจยั ของ IBM
ค่าใช้จา่ ยเฉลียทัวโลกของการละเมิดข้อมูลในปี 2023 อยู่ที 4.45 ล้านดอลลาร์สหรัฐ [17] สําหรับองค์กรขนาดเล็ก การละเมิด
ข้อมูลอาจหมายถึงการสินสุดของธุรกิจ และน่าเสียดายทีการละเมิดข้อมูล API กําลังเพิมขึน โดยมักเกิดจากความผิดพลาด
พืนฐาน เช่นในเดือนกันยายนปี 2022 บริษัท Optus ซึงเป็ นบริษัทโทรคมนาคมทีใหญ่เป็ นอันดับสามของออสเตรเลีย ประสบกับ
การละเมิดข้อมูล API ทีส่งผลกระทบต่อผูใ้ ช้สงู สุดถึง 10 ล้านราย ข้อมูลส่วนตัวทีถูกละเมิดรวมถึงชือ ทีอยู่ เบอร์โทรศัพท์ และ
แม้แต่หมายเลขพาสปอร์ตและใบขับขี [18] ค่าใช้จ่าย? สูงถึง 140 ล้านดอลลาร์สหรัฐ เพือทําการตรวจสอบการละเมิดและ
ชดเชยให้กบั ลูกค้าทีได้รบั ผลกระทบ [19]
เห็นได้ชดั ว่าคุณไม่สามารถละเลยความปลอดภัยของ API ได้ หากคุณไม่ให้ความสําคัญกับเรืองนีอย่างจริงจัง คุณอาจ
ต้องจ่ายในราคาทีแพงกว่ามาก คําถามคือ คุณสามารถจัดการความปลอดภัยของ API อย่างเหมาะสมได้จริงหรือไม่? จะทําให้
การส่งมอบซอฟต์แวร์ของคุณช้าลงหรือทําให้องค์กรของคุณสูญเสียความได้เปรียบในการแข่งขันหรือเปล่า ? คําตอบคือ ไม่เลย
หากคุณทํามันอย่างถูกต้อง
รูปที 2.8 แสดงวงจรการพัฒนา API ทัวไปในหลายองค์กร ดังทีคุณเห็น เราผ่านขันตอนดังต่อไปนี:
1.
2.
3.
4.
เราเริมต้นด้วย ขันตอนการออกแบบ API (API Design Stage)
จากนันดําเนินต่อด้วย การพัฒนา (Implementation)
หลังจากนันทําการ ปรับใช้การเปลียนแปลง (Deployment) และสุดท้าย
เรา รันชุดการทดสอบด้านความปลอดภัย ซึงโดยทัวไปมักเป็ นการทดสอบด้วยมือ
หากเราพบช่องโหว่ดา้ นความปลอดภัย เราจะต้องย้อนกลับไปทีจุดเริมต้นของกระบวนการ ออกแบบ API ใหม่ พัฒนาซํา
ปรับใช้ใหม่ และทําการทดสอบความปลอดภัยอีกครัง วนลูปไปเรือย ๆ จนกว่าจะไม่พบปั ญหา
กระบวนการนีไม่เพียงแต่ชา้ เท่านัน แต่ดงั ที Dan Barahona ได้เน้นยํา กระบวนการนี ไม่สามารถปรับขนาดได้ (Doesn’t
Scale) [20] และเพือประหยัดเวลา องค์กรมักจบลงด้วยการตัดขันตอนบางอย่างออกจากกลยุทธ์การทดสอบความปลอดภัย
ซึงเป็ นสิงทีเพิมความเสียงอย่างมากในระยะยาว
รูปที . วงจรการพัฒนา API ทัวไปเริมจาก ขันตอนการออกแบบ จากนันเข้าสู่ การพัฒนา และตามด้วย การปรับใช้ เมือปรับใช้แล้ว เราจะรัน
การทดสอบด้านการทํางาน (Functional Tests) และสุดท้ายคือการทดสอบด้านความปลอดภัย (Security Tests) หากพบปั ญหาใด ๆ ใน
ระหว่างขันตอนการทดสอบ เราจะต้องย้อนกลับไปเริมต้นกระบวนการใหม่อกี ครัง ตังแต่การออกแบบ การพัฒนา การปรับใช้ และการทดสอบ
อีกครัง
ความปลอดภัยของ API โดยการออกแบบ (API Security by Design) ใช้วิธีการทีแตกต่างไปในการจัดการความ
ปลอดภัยของ API ดังทีแสดงในรูปที 2.9 วิธีนีเริมจัดการกับความปลอดภัยตังแต่จดุ เริมต้นของกระบวนการพัฒนา API – ตังแต่
ขันตอนการออกแบบ
ทุกอย่างเริมต้นด้วย การออกแบบลําดับการทํางานของผูใ้ ช้ (User Flows) และ พารามิเตอร์อินพุตทีปลอดภัย จากนัน
เราทําการทดสอบการออกแบบ API เพือค้นหาช่องโหว่ และจะดําเนินการพัฒนาได้ก็ต่อเมือการออกแบบนันปลอดภัย หรือเมือ
โปรไฟล์ความเสียงของการออกแบบนันอยู่ในระดับทียอมรับได้ตามการทําโมเดลภัยคุกคาม (Threat Modeling)
จากนัน เราจึงพัฒนา API โดยใช้ รูปแบบการพัฒนาทีปลอดภัย (Secure Implementation Patterns) และตรวจสอบ
ความถูกต้องของการพัฒนา เมือถึงขันตอนการปรับใช้และการรันการทดสอบด้านความปลอดภัย เราจะพบปั ญหาน้อยลงมาก
ซึงหมายความว่าเราจะต้องวนซํากระบวนการทีแสดงในรูปที 2.8 น้อยลง
วิธีนีช่วยให้เราสามารถปล่อย API ได้เร็วขึน และมีความมันใจมากขึนในสถานะความปลอดภัยของ API ของเรา
รูปที . ด้วยแนวทางความปลอดภัยของ API โดยการออกแบบ (API Security by Design) เราจัดการกับความปลอดภัยตังแต่ขนตอนการ
ั
ออกแบบ API และตลอดทุกขันตอนของการพัฒนา
ตรวจสอบให้แน่ใจว่าคุณสามารถแสดงหลักฐานให้กับธุรกิจเห็นได้ว่าแนวทางใหม่ของคุณในการรักษาความปลอดภัย
ของ API นันได้ผล แล้วคุณจะทําอย่างไร? ใช้ ตัวชีวัด (Metrics) ดังทีผูเ้ ชียวชาญด้าน API Operations (APIOps) อย่าง Ikenna
Nwaiwu ชีให้เห็นว่า ผลลัพธ์ทสามารถวั
ี
ดได้เป็ นหนึงในเครืองมือสือสารทีมีประสิทธิภาพมากทีสุด และช่วยให้คณ
ุ ได้รบั การ
สนับสนุนจากองค์กร [21]
ตัวอย่างเช่น:
 ปั จจุบนั คุณต้องวนซํากระบวนการในรูปที 2.8 กีครัง?
 ใช้เวลานานแค่ไหนในการพา API จากขันตอนการออกแบบไปสู่การปรับใช้ในระบบผลิตจริง (Production)?
 คุณมีขอ้ มูลจําเพาะของ API (API Specification) หรือไม่?
 เมือคุณทดสอบ API ด้วยปลักอิน OWASP ของ Spectral (ซึงจะเรียนรูใ้ นบทที 12) พบข้อผิดพลาดด้านความ
ปลอดภัยกีรายการ?
 เมือคุณใช้เครืองมือทดสอบแบบ Fuzz เช่น Schemathesis (ซึงจะกล่าวถึงในบทที 12) พบข้อผิดพลาดกี
รายการเมือรันกับ API ของคุณ?
การติดตามตัวชีวัดเหล่านีและตัวชีวัดทีคล้ายกันจะช่วยคุณสร้างกรณีศกึ ษา (Case) เพือสนับสนุนแนวทางทีแข็งแกร่ง
สําหรับการรักษาความปลอดภัย API และองค์กรของคุณจะขอบคุณสําหรับสิงนีในภายหลัง
2.6 การรับมือกับการตรวจสอบความปลอดภัยของ API
ในโลกอุดมคติ องค์กรต่าง ๆ จะเริมปรับปรุงท่าทีดา้ นความปลอดภัยของ API ด้วยตนเอง แต่ในหลายกรณี จําเป็ นต้องมี
การตรวจสอบเพือกระตุน้ ให้เกิดการตืนตัว การตรวจสอบสามารถเกิดขึนได้ดว้ ยหลายเหตุผล ตัวอย่างเช่น นักลงทุนมักจะ
ตรวจสอบระบบของคุณก่อนทีจะลงทุนในธุรกิจของคุณ หากธุรกิจของคุณกําลังจะถูกเข้าซือ ผูซ้ ือก็มกั จะต้องการทราบว่าพวก
เขากําลังซือแพลตฟอร์มทีออกแบบมาอย่างดี หรือหากคุณจะเริมต้นความร่วมมือกับธุรกิจใหม่ ธุรกิจอีกฝ่ ายก็มกั จะต้องการ
ทราบว่า API ของคุณปลอดภัยหรือไม่ บ่อยครัง แทนทีจะดําเนินการตรวจสอบความปลอดภัยของลูกค้าบนแพลตฟอร์มของคุณ
นักลงทุน ผูเ้ ข้าซือ และพันธมิตรทางธุรกิจมักจะกําหนดให้คณ
ุ มีการรับรองด้านความปลอดภัย เช่น ISO/27001, HIPAA, SOC
หรือ PCI DSS โดยเฉพาะในภาคส่วนทีมีความอ่อนไหว เช่น การดูแลสุขภาพ การเงิน และการป้องกันประเทศ
คุณจะรับมือกับการตรวจสอบเหล่านีจากมุมมองด้านความปลอดภัยของ API ได้อย่างไร? สําหรับการเริมต้น ระดับของ
การตรวจสอบจะขึนอยู่กบั ลักษณะของธุรกิจของคุณ หากคุณนําเสนอผลิตภัณฑ์และบริการโดยตรงผ่าน API และเกียวข้องกับ
ข้อมูลทีมีความอ่อนไหว API ของคุณจะได้รบั ความสนใจอย่างมากในระหว่างการตรวจสอบ ในทางกลับกัน หากคุณเกี ยวข้อง
กับข้อมูลทีไม่มีความอ่อนไหว และ API ของคุณมีบทบาทรองต่อธุรกิจ หรือเป็ น “API อรรถประโยชน์” (utility APIs) ตามที
Kristof van Tomme กล่าวไว้ [22] API ของคุณจะได้รบั ความสนใจน้อยลงจากผูต้ รวจสอบ
ไม่ว่าคุณจะมี API ประเภทใดก็ตาม คําแนะนําของฉันคือการเตรียมพร้อมทีจะตอบคําถามในเชิงลึกเกียวกับท่าทีดา้ น
ความปลอดภัยของคุณ ย้อนกลับไปดูตารางที 2.1 และตรวจสอบให้แน่ใจว่าคุณเข้าใจคําถามส่วนใหญ่ในตารางนัน
ตัวอย่างเช่น มีความแตกต่างอย่างมากระหว่างการไม่รูเ้ ลยว่า “พืนผิวการโจมตีของ API” (API attack surface) ของคุณมี
ลักษณะอย่างไร กับการมีแผนทีเบืองต้น และยิงดีกว่านันหากคุณสามารถระบุเป็ นเปอร์เซ็นต์ของพืนทีทีทําการแมปไว้ได้ คุณ
ต้องแสดงให้เห็นถึงความมุ่งมันในการปรับปรุงท่าทีดา้ นความปลอดภัยของคุณอย่างต่อเนือง และบางครัง ผูม้ ีส่วนได้ส่วนเสีย
เช่น นักลงทุน อาจเรียกร้องให้คณ
ุ รายงานความคืบหน้าเป็ นประจํา
คุณจะไม่ได้รบั การสนับสนุนจากองค์กรของคุณในการปรับปรุงท่าทีดา้ นความปลอดภัยของ API มากเท่ากับตอนที
เผชิญกับการตรวจสอบ คุณอาจไม่สามารถจัดการทุกอย่างได้ในครังเดียว แต่นเป็
ี นโอกาสทีดีทีจะวางแผนกลยุทธ์ดา้ นความ
ปลอดภัยของ API หากคุณยังไม่มี นอกจากนียังเป็ นโอกาสทียอดเยียมในการเริมต้นจัดการกับสิงทีทําได้ง่าย ๆ ทีเราได้กล่าวถึง
ในหัวข้อ 2.3 หากนีเป็ นการตรวจสอบครังแรกของคุณ ไม่มใี ครคาดหวังให้คณ
ุ สมบูรณ์แบบ สิงทีสําคัญกว่าคือการแสดงให้เห็น
ถึงการตระหนักรูใ้ น “หนีทางเทคนิคด้านความปลอดภัย” (security technical debt) แผนงานสําหรับการแก้ไข และความมุง่ มัน
ทีจะดําเนินการ อย่าลืมกําหนดผลลัพธ์ทีวัดผลได้ตามทีเราได้กล่าวถึงในหัวข้อ 2.5 เมือเวลาผ่านไป คุณจะถูกคาดหวังให้แสดง
ให้เห็นถึงความก้าวหน้าและความเป็ นผูใ้ หญ่ในด้านนี ซึงตัวชีวัด (metrics) เป็ นหนึงในวิธีทีดีทีสุดในการแสดงสิงนี
สุดท้าย อย่าลืมว่ามีผเู้ ชียวชาญทีพร้อมให้ความช่วยเหลือเสมอหากคุณต้องการ การตรวจสอบความปลอดภัยของ API
เป็ นหนึงในโมเดลธุรกิจทีประสบความสําเร็จมากทีสุดในช่วงไม่กีปี ทีผ่านมา และมีหลายบริษทั ทีให้บริการในด้านนี เช่น
42Crunch, APISec, SWO2 และอืน ๆ อย่างไรก็ตาม โปรดจําไว้วา่ การใช้ผใู้ ห้บริการจากภายนอกไม่ใช่ขอ้ อ้างในการไม่สร้างกล
ยุทธ์ดา้ นความปลอดภัยของ API ของคุณเอง หากคุณมี API คุณต้องเป็ นเจ้าของการจัดการท่าทีดา้ นความปลอดภัยของ API
และทํางานเพือให้ได้มาซึงวิธีการออกแบบ API ทีมีความปลอดภัยตังแต่แรก (API security by design)
2.7 สรุป
 เส้นทางการรักษาความปลอดภัยของ API ของคุณเริมต้นด้วยการประเมินท่าทีดา้ นความปลอดภัยของ API
องค์กรทีมีความเป็ นผูใ้ หญ่ในด้านความปลอดภัยของ API จะมีสงต่
ิ อไปนี:
o การสํารวจข้อมูล (Data inventory) กล่าวคือ พวกเขารูว้ ่าข้อมูลทีมีความอ่อนไหวใดบ้างทีเปิ ดเผย
และอยู่ทใด
ี
o แผนทีพืนผิวการโจมตี (Attack surface map) กล่าวคือ พวกเขารูว้ ่ามีจดุ เชือมต่อ (endpoints)
ใดบ้างทีสามารถเข้าถึงได้ผ่าน API
o การรับรองตัวตนและการอนุญาต (Authentication and authorization) ทีปฏิบตั ิตามแนวปฏิบตั ิและ
มาตรฐานทีดีทีสุด เช่น OAuth, OIDC และ JWTs
o การควบคุมการเข้าถึงทีแข็งแกร่ง (Robust access controls) เพือให้มนใจว่
ั าผูใ้ ช้จะไม่สามารถ
เข้าถึงข้อมูลทีไม่เหมาะสมได้
o การใช้งานทีปลอดภัย (Secure implementation) โดยปฏิบตั ิตามข้อกําหนดของ API อย่างเคร่งครัด
o การทดสอบความปลอดภัยแบบอัตโนมัติ (Automated security testing) ด้วยเครืองมือทดสอบการ
ออกแบบ (design-testing tools) เครืองมือทดสอบแบบสุ่ม (fuzzy testers) และชุดทดสอบทีกําหนด
เอง
o การวิเคราะห์ความเสียง (Risk analysis) ทีช่วยให้สามารถจัดลําดับความสําคัญของช่องโหว่ทีรูจ้ กั
ได้อย่างรวดเร็ว
o การตรวจจับเหตุการณ์ (Incident detection) ทีช่วยให้มองเห็นพฤติกรรมของผูใ้ ช้ทีน่าสงสัยและ
เหตุการณ์ดา้ นความปลอดภัยแบบเรียลไทม์
o แผนการตอบสนองต่อเหตุการณ์ (Incident response plans) เพือให้เรารูว้ ่าจะต้องทําอะไรเมือเกิด
เหตุการณ์ขึน
o การฝึ กอบรมอย่างต่อเนือง (Continuous training) เพือสร้างความตระหนักรูเ้ กียวกับช่องโหว่ดา้ น
ความปลอดภัยของ API
 การสร้างแบบจําลองภัยคุกคาม (Threat modeling) เป็ นกิจกรรมทียอดเยียมในการมองเห็นช่องโหว่ของ API
ของคุณในภาพรวม และส่งเสริมความร่วมมือในทีม
 แบบจําลองภัยคุกคามทีดีจะตอบคําถามดังต่อไปนีจาก Threat Modeling Manifesto:
o เรากําลังทํางานกับอะไร?
o อะไรทีอาจผิดพลาดได้?
o เราจะทําอะไรเกียวกับมัน?
o เราทําได้ดีพอหรือยัง?
 เพือจัดการกับคําถามของ Threat Modeling Manifesto เราแบ่งกระบวนการสร้างแบบจําลองภัยคุกคาม
ออกเป็ นขันตอนดังนี:
o การวิเคราะห์องค์ประกอบของแอปพลิเคชัน (Application decomposition)
o การระบุและจัดอันดับภัยคุกคาม (Threat identification and ranking)
o การตอบสนองและการลดผลกระทบ (Response and mitigations)
o การทบทวนและการตรวจสอบความถูกต้อง (Review and validation)
 เราใช้วิธีการ เช่น STRIDE ในการสร้างแบบจําลองภัยคุกคาม (Threat modeling) โดย STRIDE ช่วยระบุ
ประเภทของภัยคุกคามดังต่อไปนี:
o Spoofing: ความเสียงจากการขโมยข้อมูลรับรองของผูใ้ ช้
o Tampering: ความเสียงจากการอัปเดตข้อมูลโดยไม่ตงใจหรื
ั
อไม่พึงประสงค์
o Repudiation: ความเสียงจากการไม่สามารถตรวจจับกิจกรรมทีเป็ นอันตรายได้
o Information Disclosure: ความเสียงจากการรัวไหลของข้อมูลทีมีความอ่อนไหว
o Denial of Service: ความเสียงจากการทีระบบไม่สามารถให้บริการได้
o Elevation of Privileges: ความเสียงทีผูโ้ จมตีสามารถแอบอ้างเป็ นผูด้ แู ลระบบ (Admin privileges)
 วิธีทีดีทีสุดในการเริมต้นจัดการกับความปลอดภัยของ API คือการเริมต้นจากสิงทีทําได้งา่ ย เช่น การสร้างแผน
ทีพืนผิวการโจมตีของคุณ (mapping out your attack surface) การปรับปรุงเอกสารประกอบ API (fixing your
API documentation) หรือการนํามาตรฐานการรับรองตัวตนและการอนุญาต (authentication and
authorization standards) มาใช้
 โปรแกรมความปลอดภัยของ API (API security program) เป็ นกรอบแนวทางของกลยุทธ์ดา้ นความปลอดภัย
ของ API และวิธีทีคุณจะนําไปปฏิบตั ิ
 คุณต้องได้รบั การสนับสนุนจากองค์กรของคุณเพือผลักดันโปรแกรมความปลอดภัยของ API ให้กา้ วหน้า:
o รับความคิดเห็นจากผูม้ ีส่วนได้ส่วนเสีย (stakeholders) เพือกระตุน้ ให้พวกเขามีส่วนร่วม
o สร้างตัวชีวัด (metrics) ทีแสดงให้เห็นถึงประโยชน์ทีองค์กรของคุณได้รบั จากโปรแกรมนี
 เพือเตรียมตัวสําหรับการตรวจสอบความปลอดภัยของ API (API security audit) ให้แน่ใจว่าคุณสามารถตอบ
คําถามในเชิงลึกเกียวกับท่าทีดา้ นความปลอดภัยของคุณได้ คุณต้องแสดงให้เห็นถึงความตระหนักรูใ้ นหนีทาง
เทคนิคปัจจุบนั (technical debt) และความมุง่ มันในการแก้ไขปัญหาเหล่านัน
[1] สําหรับบทสรุปของกรอบการทํางานด้านความปลอดภัยทางไซเบอร์หลัก ดู Kim Crawley, 8 Steps to Better
Security (Wiley, 2021), หน้า 89-108
[2] Corey Ball, “Earning Confidence in your API Security”, นําเสนอทีงาน APIDays Paris, 6-8 ธันวาคม 2023
[3] Repudiability ในเอกสารต้นฉบับ
[4] Elevation of Privilege เป็ นเกมไพ่ทีเกียวกับการสร้างแบบจําลองภัยคุกคาม (threat modeling) สร้างโดย Adam
Shostack ในปี 2010 (https://shostack.org/games/elevation-of-privilege)
[5] หากต้องการเรียนรูเ้ พิมเติมเกียวกับ STRIDE GPT โปรดดูการนําเสนอของ Matt Adam เรือง “AI-Driven Threat
Modelling with STRIDE GPT” ที Open Security Summit (15 มกราคม 2024) (https://open-securitysummit.org/sessions/2024/mini-summits/jan/threat-modeling/ai-driven-threat-modelling-with-stride-gpt/)
[6] มีเครืองมือโอเพ่นซอร์สมากมายสําหรับทดสอบความแข็งแกร่ง (หรือการเจาะ) ลายเซ็นของ JWT สามารถอ่าน
เพิมเติมได้บนเว็บไซต์
OWASP:
https://owasp.org/www-project-web-security-testing-guide/latest/4Web_Application_Security_Testing/06-Session_Management_Testing/10-Testing_JSON_Web_Tokens
[7]
มุกนียืมมาจาก
OWASP’s
Threat
Modeling
(https://cheatsheetseries.owasp.org/cheatsheets/Threat_Modeling_Cheat_Sheet.html)
Cheat
Sheet
[8] Salt Security, State of API Security Q1 2023, หน้า 12 (https://content.salt.security/rs/352-UXR417/images/SaltSecurity-Report-State_of_API_Security.pdf) และยังสามารถดู Radware’s The 2022 State of API
Security ซึงพบว่า 62% ขององค์กรมี API มากกว่า 30% ทีไม่มเี อกสารกํากับ
[9] Eric Newcomer, “API Security: Is Authorization the Biggest Threat?”, The NewStack (12 มิถนุ ายน 2023,
https://thenewstack.io/api-security-is-authorization-the-biggest-threat/)
[10] จากรายงานของ Salt Security พบว่า 78% ของการโจมตี API ดําเนินการโดยผูใ้ ช้ทีผ่านการรับรองตัวตนแล้ว
(State of API Security Q1 2023, หน้า 4)
[11] จากรายงานของ Salt Security พบว่า 40% ของเหตุการณ์ความปลอดภัยของ API ในไตรมาสที 1 ปี 2023 เกียวข้อง
กับการรับรองตัวตน และการยึดครองบัญชี (account takeover) เป็ นช่องโหว่ทน่ี ากังวลเป็ นอันดับสองสําหรับองค์กร (State of
API Security Q1 2023, หน้า 4 และ 8)
[12] หากคุณต้องการดูตวั อย่างสถาปั ตยกรรมแบบหกเหลียม (hexagonal architecture) สําหรับ API โปรดดูบทที 7
ของหนังสือ Microservice APIs (Manning, 2022)
[13] เราจะพูดถึง Shadow APIs อย่างละเอียดในหัวข้อ 3.4 แต่สาํ หรับภาพรวมอย่างรวดเร็ว โปรดดูบทความของ Nick
Rago, “Are You Haunted by Zombie, Shadow and Ghost APIs?”, Salt Security Blog (28 ตุลาคม 2022,
https://salt.security/blog/are-you-haunted-by-zombie-shadow-and-ghost-apis)
[14] ตามรายงาน The 2022 State of API Security โดย Radware พบว่า “มีความเชือทีผิดว่าการใช้ API Gateways
และ WAFs แบบดังเดิมนันเพียงพอทีจะป้องกัน API จากช่องโหว่และการโจมตีโดยบอทอัตโนมัติได้” โดยมี 28.6% ขององค์กร
ทีใช้ API Gateways และ 21.2% ใช้ WAFs เป็ นวิธีหลักในการระบุการโจมตี API
[15] Lorna Mitchell, “API governance without tears”, การบรรยายทีงาน APIDays London, 19 กันยายน 2023
(สไลด์การนําเสนอสามารถดูได้ที https://noti.st/lornajane/PiwFuR#sxdiYSF)
[16] คําอ้างอิงจาก “API Security 101: Establishing & Managing a Secure API Program,” เวบบินาร์โดย Andrew
Binder และ Dan Barahona จัดโดย Redspin เมือ 11 กุมภาพันธ์ 2021 (วิดีโอบันทึกสามารถดูได้บน YouTube:
https://youtu.be/cMN6yr4nBUo; คําพูดปรากฏในนาทีที 36:20)
[17] IBM, Cost of a Data Breach Report 2023
[18] Andrew Greene, “Optus rejects insider claims of 'human error' as possible factor in hack affecting
millions of Australians,” ABC News (23 กันยายน 2022, https://www.abc.net.au/news/2022-09-23/optus-rejectsclaim-hack-likely-result-of-human-error/101468846)
นอกจากนียังสามารถดูการวิเคราะห์ในบริบทของอุตสาหกรรม
โทรคมนาคมโดย Traceable: “The Telecom Industry: Why APIs Are Becoming their Worst Nightmare,” Traceable Blog
(https://www.traceable.ai/blog-post/the-telecom-industry-api-security-worst-nightmare)
[19] Zoe Samios, “Optus hack to cost at least $140 million,” The Sydney Morning Herald (10 พฤศจิกายน 2022,
https://www.smh.com.au/business/companies/optus-puts-aside-140m-to-replace-customers-hacked-identitydocuments-20221110-p5bx4g.html)
[20] Dan Barahona และ Andrew Binder, “API Security 101: Establishing & Managing a Secure API Program,”
เวบบินาร์โดย Andrew Binder และ Dan Barahona จัดโดย Redspin เมือ 11 กุมภาพันธ์ 2021 (วิดีโอบันทึกสามารถดูได้บน
YouTube: https://youtu.be/cMN6yr4nBUo)
[21] โปรดดูการบรรยายของ Ikenna Nwaiwu “From 2.5 weeks to 1 day: Improving API delivery outcome,” ทีงาน
APIDays London, 19 กันยายน 2023 (วิดีโอบันทึกสามารถดูได้บน YouTube: https://youtu.be/4GLD0DTI8DI) และหนังสือ
ทีจะเผยแพร่เร็ว ๆ นีของเขา Automating API Delivery (Manning, 2024) โดยเฉพาะบทที 11
[22] Kristof van Tomme, “APIs are Interface Utilities: The Future of APIs Beyond Project and Product Mindset,”
Pronovix Blog, 10 มกราคม 2024 (https://pronovix.com/articles/apis-are-interface-utilities)
3 หลักการด้านความปลอดภัยของ API
บทนีครอบคลุมหัวข้อดังนี
 สิงทีการเลือนซ้ายหมายถึงสําหรับความปลอดภัยของ API และผลกระทบต่อวงจรการพัฒนา
 โมเดลความปลอดภัย Zero Trust และการนําไปใช้กบั API
 เหตุใดเราต้องรักษาความปลอดภัยของ API ภายในของเรา
 ความสําคัญของเอกสารประกอบ API เพือความปลอดภัยตังแต่การออกแบบ
 ตําแหน่ง วิธีการ และเหตุผลในการตรวจสอบความถูกต้องของข้อมูลใน API ของเรา
 บทบาทของความปลอดภัยในกระบวนการส่งมอบอย่างต่อเนือง
คุณกําลังสร้าง API และเมือดําเนินการไปครึงทาง คุณเริมสงสัยว่า API ของคุณจะมีความปลอดภัยหรือไม่ เมือใกล้ถึง
วันเปิ ดตัว ผูจ้ ดั การของคุณก็ตอ้ งการยืนยันเช่นกันว่าด้านความปลอดภัยได้รบั การดูแลแล้ว คุณจึงรีบค้นหาแหล่งข้อมูล
ออนไลน์ เช่น API-Security-Checklist ของ Shieldify (https://github.com/shieldfy/API-Security-Checklist) เพือรวบรวม
รายการตรวจสอบด้านความปลอดภัยสําหรับ API และทําเครืองหมายในช่องทังหมด คุณมันใจว่าคุณได้จดั การเรืองความ
ปลอดภัยสําหรับ API เรียบร้อยแล้ว
เมือใกล้วนั เปิ ดตัว ทีม QA และทีมความปลอดภัยทางไซเบอร์ของคุณได้ทดสอบ API อย่างเข้มข้น ผลการทดสอบ
ออกมาเป็ นไปในเชิงบวก ทุกอย่างดูเหมือนจะเรียบร้อย คุณจึงเดินหน้าต่อไปกับการเปิ ดตัว อย่างไรก็ตาม สองสัปดาห์ต่อมา
API ของคุณก็ถกู โจมตี ทําไมถึงเป็ นเช่นนันได้? ปั ญหาของแนวทางนีคือการปล่อยให้เรืองความปลอดภัยเป็ นเรืองทีต้องจัดการ
ในนาทีสดุ ท้าย ซึงถือว่ามองเรืองความปลอดภัยเป็ นเพียงเรืองรองเท่านัน
ดังนัน เราจะทําให้ API ของเรามีความปลอดภัยได้อย่างไร? ดังทีคุณจะได้เรียนรูใ้ นบทนี ความปลอดภัยเริมต้นตังแต่
ขันตอนการออกแบบ API เราต้องตรวจสอบว่าโฟลว์การใช้งานของผูใ้ ช้มีความปลอดภัยหรือไม่? เราได้แยกโมเดลข้อมูลสําหรับ
การอ่าน (read-only) และการเขียน (write) ออกจากกันอย่างชัดเจนหรือไม่? เรากําลังเปิ ดเผยข้อมูลจากฝังเซิรฟ์ เวอร์ผ่านการ
ป้อนข้อมูลของผูใ้ ช้หรือเปล่า? การป้อนข้อมูลของผูใ้ ช้ถูกจํากัดขอบเขตไว้อย่างเพียงพอหรือยัง? และทีสําคัญทีสุดคือ การ
ออกแบบของเราได้รบั การบันทึกอย่างถูกต้องหรือไม่? หลักการสําคัญประการหนึงของความปลอดภัย API คือ "คุณไม่สามารถ
ปกป้องสิงทีคุณไม่รูจ้ กั ได้" และในบทนี คุณจะได้เรียนรูว้ ิธีใช้เอกสาร API เพือเสริมสร้างความปลอดภัย
นอกจากนี ความปลอดภัยยังมีบทบาทในกลยุทธ์ดา้ นเทคโนโลยีและการดําเนินการ เช่น เราได้ใช้ไลบรารีและเฟรมเวิรก์
ทีเหมาะสมสําหรับการตรวจสอบความถูกต้องของ API และข้อมูลหรือไม่? ข้อผิดพลาดทีพบบ่อยคือการเริมสร้าง API โดยไม่ได้
ใช้เฟรมเวิรก์ เหล่านี ซึงมักนําไปสู่การสร้าง API ทีมีช่องโหว่ดา้ นความปลอดภัยขนาดใหญ่ ดังทีคุณจะได้เห็นในบทนี เรามักมี
ไลบรารีสาํ หรับงานทัวไป เช่น การสร้าง API การจัดการการตรวจสอบข้อมูล และการตรวจสอบโทเคนการเข้าถึง (access
token) ซึงช่วยเพิมโอกาสในการสร้าง API ทีปลอดภัย
ในหนังสือเล่มนี คุณจะได้เรียนรูเ้ กียวกับภัยคุกคามทีพบบ่อยต่อ API และช่องโหว่ในการออกแบบ รวมถึงวิธีป้องกันภัย
เหล่านีผ่านการใช้รูปแบบการออกแบบ การดําเนินการ และสถาปั ตยกรรม โดยพืนฐานของรูปแบบเหล่านีคือชุดของหลักการ
ด้านความปลอดภัย เช่น Shift-left security และ Zero-trust security model ในบทนี คุณจะได้เรียนรูเ้ กียวกับหลักการด้าน
ความปลอดภัยเหล่านีและวิธีทีช่วยปรับปรุงความปลอดภัยของ API ของคุณ เราจะเริมต้นด้วยหลักการทีสําคัญทีสุด: Shift-left
security
3.1 ความปลอดภัยของ API ด้วยหลักการ Shift Left
มีแนวทางพืนฐานสองประการสําหรับความปลอดภัยของซอฟต์แวร์: เราสามารถเพิมความปลอดภัยเข้าไปในแอปพลิเค
ชันในภายหลัง หรือเราสามารถสร้างความปลอดภัยเข้าไปในแอปพลิเคชันตังแต่ตน้ ดังทีแสดงในภาพที 3.1 ปั ญหาของการเพิม
ความปลอดภัยในภายหลัง (bolt-on security) คือการปฏิบตั ิต่อซอฟต์แวร์ของเราเหมือนเป็ นกล่องดํา (black box) โดยเน้นการ
ตรวจสอบช่องโหว่ทวไป
ั เช่น การขาด SSL การเข้ารหัสทีอ่อนแอ การโจมตีแบบ Cross-Site Scripting (XSS) การรัวไหลของ
การตังค่า การไม่มกี ารป้องกันทีจุดเชือมต่อ (unprotected endpoints) เป็ นต้น
อย่างไรก็ตาม ดังที Dan Barahona ผูก้ ่อตัง APISec ชีให้เห็น การใช้แนวทางนีไม่เพียงพอสําหรับความปลอดภัยของ
API เนืองจากการโจมตี API ส่วนใหญ่มกั เกิดจากข้อบกพร่องในตรรกะทางธุรกิจและการควบคุมการเข้าถึง (business and
access control logic) [1]
ภาพที 3.1 โดยทัวไป เรามักดําเนินการทดสอบความปลอดภัยของ API ในช่วงท้ายของวงจรชีวิตการพัฒนาซอฟต์แวร์ (Software
Development Life Cycle - SDLC) ซึงแนวทางนีเรียกอีกอย่างว่าการเพิมความปลอดภัยเข้าไปในแอปพลิเคชันภายหลัง (bolting security
onto our applications)
ตัวอย่างเช่น ในปี 2019 PingSafe พบช่องโหว่ใน API ของ Uber ทีทําให้ผโู้ จมตีสามารถยึดบัญชีผใู้ ช้อืนได้ เนืองจาก
ลําดับโฟลว์การใช้งานทีมีช่องโหว่ โดยผูโ้ จมตีสามารถส่งหมายเลขโทรศัพท์ทีถูกต้องไปยังจุดเชือมต่อ (endpoint) และหาก
หมายเลขนันมีอยูใ่ นระบบ PingSafe จะได้รบั user ID ทีสอดคล้องกัน จากนันข้อมูลนีสามารถถูกนําไปใช้กับการทํางาน
getConsentScreenDetails ซึงรัวไหลโทเคนการเข้าถึง (access token) ของผูใ้ ช้ [2]
Uber แก้ไขช่องโหว่นีโดยการเพิมความแข็งแกร่งให้กบั การควบคุมการเข้าถึง API (API access controls) และออกแบบ
การตอบสนอง (responses) ใหม่เพือเปิ ดเผยข้อมูลทีมีความอ่อนไหวน้อยลง.
ภาพที . การสร้าง API ทีปลอดภัยโดยการออกแบบ (secure by design) จําเป็ นต้องจัดการกับความปลอดภัยตังแต่ช่วงต้นของวงจรชีวิต
การพัฒนาซอฟต์แวร์ (SDLC) และลดระยะเวลาของวงจรการตอบกลับ (feedback loop) โดยการประเมินช่องโหว่อย่างสมําเสมอ แนวทางนี
เรียกว่าการสร้างความปลอดภัยเข้าไปในแอปพลิเคชันตังแต่ตน้ (building security into our applications)
โชคดีสาํ หรับ Uber ทีช่องโหว่นีถูกค้นพบผ่านโปรแกรม bug bounty ของพวกเขา อย่างไรก็ตาม ผูโ้ จมตีส่วนใหญ่มกั จะ
ไม่ปรานีเมือพบช่องโหว่ใน API ของคุณ และพวกเขามักจะใช้ช่องโหว่เหล่านันเพือประโยชน์ของตนเอง เพือป้องกันช่องโหว่
เหล่านี เราจําเป็ นต้องสร้างความปลอดภัยเข้าไปใน API ของเรา ซึงหมายถึงการจัดการกับความปลอดภัยตังแต่ช่วงต้นของ
วงจรการพัฒนา นีคือสิงทีเราเรียกว่า API security by design
คําจํากัดความ
โปรแกรม Bug Bounty คือโปรแกรมทีองค์กรเสนอค่าตอบแทนให้กบั บุคคลทีรายงานข้อผิดพลาด (bugs), ช่องโหว่ดา้ น
ความปลอดภัย (security exploits), และปั ญหาด้านความปลอดภัยอืน ๆ บนเว็บไซต์ของพวกเขา หากดําเนินการอย่าง
เหมาะสม โปรแกรม Bug Bounty จะมีประสิทธิภาพสูงในการค้นหาช่องโหว่สาํ คัญบนเว็บไซต์ของเรา แพลตฟอร์มยอด
นิยมสําหรับการจัดการโปรแกรม Bug Bounty คือ HackerOne (https://www.hackerone.com/)
ดังทีแสดงในภาพที 3.2 ทุกอย่างเริมต้นทีขันตอนการออกแบบ เราต้องถามตัวเองว่า โฟลว์การใช้งานของเรามีช่องโหว่
หรือไม่? เรากําลังเปิ ดเผยข้อมูลทีมีความอ่อนไหวมากเกินไปในบางการทํางานหรือเปล่า? เรามีการควบคุมการเข้าถึง (access
controls) ทีแข็งแกร่งหรือไม่? เราจะมันใจได้อย่างไรว่าผูใ้ ช้จะไม่สามารถแก้ไขคุณสมบัติฝังเซิรฟ์ เวอร์ได้? จุดเชือมต่อ
(endpoints) และพารามิเตอร์ใดบ้างทีต้องมีความยืดหยุ่นโดยการออกแบบ และด้วยเหตุนีจึงต้องมีการตรวจสอบความ
ปลอดภัยเพิมเติม? การตอบคําถามเหล่านีตังแต่เริมต้นการพัฒนา API เป็ นวิธีทีดีทีสุดในการสร้างความปลอดภัยเข้าไปใน API
ของเรา
คําจํากัดความ
Security by design คือแนวคิดในด้านความปลอดภัยทางไซเบอร์ทีผนวกความปลอดภัยเข้าไปในทุกขันตอนของวงจร
ชีวิตการพัฒนาซอฟต์แวร์ (SDLC) แนวคิดนีมุ่งเน้นการจัดการกับช่องโหว่ในทุกขันตอนของ SDLC ก่อนทีจะก้าวไปยัง
ขันตอนถัดไป เพือสร้างซอฟต์แวร์ทีมีความปลอดภัยตังแต่ฐานราก
การจัดการด้านความปลอดภัยตังแต่ขนตอนการออกแบบถื
ั
อเป็ นโอกาสทองในการสร้างฐานทีมันคงสําหรับ API ของเรา
แต่ API security by design ไม่ได้หยุดอยู่แค่ขนตอนนี
ั
เป้าหมายคือการนําแนวคิด security by design มาใช้ในทุกขันตอนของ
กระบวนการพัฒนา API ตัวอย่างเช่น เราใช้รูปแบบการพัฒนาทีปลอดภัยหรือไม่? การดําเนินการ (implementation) เป็ นไป
ตามข้อกําหนดของ API อย่างถูกต้องหรือไม่? เรามีการทดสอบอัตโนมัติเพือตรวจสอบการควบคุมการเข้าถึง (access
controls) หรือเปล่า?
การผนวกความปลอดภัยเข้าไปในทุกขันตอนของกระบวนการพัฒนาช่วยลดโอกาสในการพบช่องโหว่ในช่วงท้ายของ
โครงการ ดังทีเราได้เห็นในบทที 2 วิธีนีช่วยให้เราสามารถเปิ ดตัว API ได้เร็วขึนและมันใจมากขึน.
คําจํากัดความ
API specification คือคําอธิบายอย่างเป็ นทางการของ API ของคุณ โดยใช้มาตรฐานการจัดทําเอกสาร เช่น OpenAPI
API security by design เป็ นตัวอย่างของสิงทีเราเรียกว่า shift-left ด้านความปลอดภัย (security). Shift-left เป็ น
แนวคิดในกระบวนการพัฒนาซอฟต์แวร์ทีสนับสนุนให้เราแก้ไขปัญหาต่าง ๆ ตังแต่เนิน ๆ โดยการสร้างคุณภาพเข้าไปในระบบ
ของเรา ประโยชน์ของการ shift-left ด้านความปลอดภัยได้รบั การพิสจู น์มาเป็ นเวลาหลายปี แล้ว ดังทีแสดงในงานวิจยั ของทีมที
อยู่เบืองหลัง DevOps Research and Assessment (DORA).
หมายเหตุ
ทีม DevOps Research and Assessment (DORA) ก่อตังโดย Nicole Forsgren, Jez Humble, และ Gene Kim เพือ
ศึกษาวิธีการทีช่วยให้กระบวนการพัฒนาสามารถส่งมอบซอฟต์แวร์ทีมีคุณภาพสูงได้อย่างรวดเร็ว DORA เผยแพร่
รายงานประจําปี ทีมีชอว่
ื า State of DevOps และในปั จจุบนั เป็ นส่วนหนึงของ Google Cloud หากต้องการเรียนรูเ้ พิมเติม
เกียวกับ DORA สามารถอ่านบทความของ Jez Humble เรือง “DORA’s Journey: An Exploration” บน Medium (2
กุมภาพันธ์ 2019, https://medium.com/@jezhumble/doras-journey-an-exploration-4c6bfc41e667).
ในรายงาน State of DevOps Report ปี 2015 ทีม DORA พบว่าองค์กรทีจัดการปั ญหาด้านคุณภาพตังแต่เนิน ๆ มี
แนวโน้มทีจะปล่อยซอฟต์แวร์ได้บ่อยขึนและมันใจมากขึน (https://services.google.com/fh/files/misc/state-of-devops2015.pdf) สิงนีสามารถนํามาใช้กบั ด้านความปลอดภัยได้เช่นกัน ในรายงาน State of DevOps Report ปี 2016 พบว่าองค์กร
ที "ผนวกความปลอดภัยเข้าไปในงานประจําวัน แทนทีจะเพิมความปลอดภัยในช่วงท้าย… ใช้เวลาน้อยลงอย่างมากในการ
จัดการกับปั ญหาด้านความปลอดภัย" [3]
คําจํากัดความ
Shift-left คือแนวคิดในกระบวนการพัฒนาซอฟต์แวร์ทีมุ่งสร้างคุณภาพให้กบั ซอฟต์แวร์ โดยสนับสนุนการทดสอบ
บ่อยครังและการส่งมอบฟี เจอร์เป็ นชุดเล็ก ๆ ปรัชญานีได้รบั แรงบันดาลใจจากแนวคิด Total Quality Management
(TQM) ของ W. Edwards Deming ซึงใน Fourteen Points for the Transformation of Management ของเขา Deming
ได้สนับสนุนให้ผจู้ ดั การ "เลิกพึงพาการตรวจสอบเพือให้ได้คณ
ุ ภาพ... โดยการสร้างคุณภาพเข้าไปในผลิตภัณฑ์ตงแต่
ั
แรกเริม" [4]
API ก็ไม่ใช่ขอ้ ยกเว้นเช่นกัน จากรายงาน API Security Report ปี 2022 ของ S&P Global พบว่า 35% ของผูต้ อบ
แบบสอบถามรายงานว่าโครงการถูกเลือนออกไปเนืองจากความกังวลด้านความปลอดภัยของ API ในจํานวนนี 87% เชือว่า
ความล่าช้าเหล่านีสามารถป้องกันได้หากมีการผนวกความปลอดภัยเข้าไปในกระบวนการทํางานประจําวัน [5] และไม่ใช่เพียง
เรืองความเร็วเท่านัน – การ shift-left ด้านความปลอดภัยของ API ยังช่วยให้เรามีโอกาสน้อยลงทีจะพบปั ญหาด้านความ
ปลอดภัยในขันตอนการผลิตอีกด้วย
เพือแสดงให้เห็นถึงประโยชน์ของการ shift-left ด้านความปลอดภัยของ API ลองนึกภาพว่าเราต้องการเพิมพารามิเตอร์
sort_by ใน GET /products endpoint เพือให้ผใู้ ช้สามารถจัดเรียงสินค้าได้ตามปัจจัยต่าง ๆ เช่น ราคา คะแนนรีวิวเฉลีย เป็ น
ต้น ช่องโหว่ทีพบได้บ่อยในพารามิเตอร์ประเภทนีคือการโจมตีแบบ SQL injection หากใช้แนวทาง bolt-on security เรามักจะ
ไม่ตรวจพบช่องโหว่นีจนกว่า API จะถูกปรับใช้ในสภาพแวดล้อมการทดสอบและผ่านชุดการทดสอบด้านความปลอดภัย
วิธีแก้ไขทีเป็ นไปได้คือการใช้ regular expression กับพารามิเตอร์เพือป้องกัน SQL injection เช่น การจํากัดค่าของ
พารามิเตอร์ให้เป็ นคําเดียวทีไม่มชี ่องว่าง อย่างไรก็ตาม ดังทีแสดงในภาพที 3.3 วิธีนียังคงเปิ ดช่องโหว่ใน API อยู่ โดยการ
อนุญาตให้ผใู้ ช้จดั เรียงรายการด้วยคําใด ๆ ก็ได้ ผูใ้ ช้สามารถค้นพบคุณสมบัติทีซ่อนอยูข่ อง product model และพยายามแก้
ไขมันผ่านคําร้อง PUT หรือ PATCH ได้.
ภาพที . ผูโ้ จมตีคน้ พบคุณสมบัตฝิ ังเซิรฟ์ เวอร์ทีเรียกว่า discount และใช้คณ
ุ สมบัตินีเพือปรับส่วนลดของสินค้าจนเป็ น
%
Security by design จัดการกับปั ญหานีตังแต่เริมต้น ตัวอย่างเช่น ดังทีแสดงในภาพที 3.4 เราจํากัดพารามิเตอร์ sort_by
ให้เลือกค่าได้เฉพาะทีกําหนดไว้ล่วงหน้า (enumeration) เช่น price และ review การจํากัดนีช่วยกําจัดช่องโหว่ SQL injection
ตังแต่ขนตอนการออกแบบ
ั
และด้วยเหตุนี การทดสอบด้านความปลอดภัยของเราจึงผ่านได้อย่างราบรืนเมือดําเนินการในช่วง
ท้ายของกระบวนการพัฒนา.
ภาพที 3.4 Bolt-on security มีแนวโน้มทีจะนําไปสู่การแก้ไขปัญหาด้านความปลอดภัยแบบเฉพาะหน้า ตัวอย่างเช่น หากการทดสอบของเรา
พบช่องโหว่ SQL injection เราอาจแก้ไข API ด้วยรูปแบบ regex pattern ในขณะที built-in security จะจํากัดค่าทีอนุญาตโดยใช้
enumeration ซึงอ้างอิงจากโมเดลข้อมูลของเรา.
คําเตือน การ shift-left ด้านความปลอดภัยนํามาซึงประโยชน์มากมาย แต่ไม่ใช่วธิ ีแก้ปัญหาทีครอบคลุมทุกอย่าง (silver
bullet) และไม่ควรเป็ นกลยุทธ์ดา้ นความปลอดภัยเพียงอย่างเดียวของคุณ สําหรับการทําให้ shift-left security สร้างคุณค่าได้
จริง คุณต้องปฏิบตั ิตามเกณฑ์ตอ่ ไปนี:
 ระบุโฟลว์การใช้งานทีมีความอ่อนไหวตังแต่ขนตอนการออกแบบ
ั
และมันใจว่าได้รบั การป้องกันอย่าง
เหมาะสม ร่วมมือกับผูเ้ ชียวชาญด้านความปลอดภัยในองค์กรของคุณเพือออกแบบ payloads ทีปลอดภัย ลด
การเปิ ดเผยข้อมูลให้เหลือน้อยทีสุด จํากัดการป้อนข้อมูลของผูใ้ ช้ และอืน ๆ นอกจากนี ให้เขียนกรณีทดสอบ
(test cases) เพือให้มนใจว่
ั าการพัฒนาเป็ นไปตามข้อกําหนดเหล่านี
 จัดทําเอกสาร API อย่างถูกต้อง: ดังทีเราจะได้เห็นในส่วนที 3.4 เอกสาร API มีบทบาทสําคัญในด้านความ
ปลอดภัย เพราะช่วยให้คณ
ุ สามารถตรวจพบช่องโหว่ตงแต่
ั ขนตอนการออกแบบและอื
ั
นๆ
 ใช้เครืองมือทีเหมาะสมในการทดสอบ API ทังในขันตอนการออกแบบและการรัน: ระบบนิเวศของผูใ้ ห้บริการ
ด้านความปลอดภัย API เต็มไปด้วยเครืองมือทีตรวจสอบ API ของคุณด้วยการทดสอบทัวไป ตรวจสอบ
เครืองมือเหล่านีก่อนใช้งานและมันใจว่าเครืองมือเหล่านันตรงตามข้อกําหนดในการทดสอบของคุณ (คุณจะ
ได้เรียนรูเ้ พิมเติมเกียวกับเรืองนีในบทที 12)
การรักษาความปลอดภัยแบบ Shift-left ก็ไม่สามารถทดแทนการทดสอบคุณภาพ (QA) และการทดสอบความปลอดภัย
ทางไซเบอร์อย่างครอบคลุมในช่วงท้ายของวงจรชีวิตการพัฒนาซอฟต์แวร์ (SDLC) ได้ และการทดสอบเหล่านันมักจะช่วยตรวจ
พบช่องโหว่ใหม่ ๆ อยู่เสมอ และอย่าลืมว่า เหตุการณ์ดา้ นความปลอดภัยไม่ใช่เรืองของ "ถ้าเกิดขึนหรือไม่" แต่เป็ นเรืองของ
"เมือไหร่จะเกิด" การรักษาความปลอดภัยแบบ Shift-left จะทํางานได้ดีทีสุดเมือใช้รว่ มกับการสังเกตการณ์ทีมีประสิทธิภาพ การ
ตรวจจับภัยคุกคามและการตอบสนองแบบอัตโนมัติ รวมถึงคูม่ ือขันตอน (runbook) สําหรับดําเนินการเมือเกิดการละเมิดความ
ปลอดภัย บททีเหลือนีจะอธิบายหลักการทีคุณจําเป็ นต้องใช้เพือสร้างกลยุทธ์การรักษาความปลอดภัยแบบ Shift-left ที
เหมาะสม โดยเริมจากคําถามสําคัญ: เราสามารถไว้วางใจอะไรได้บา้ ง?
3.2 API แบบ Zero Trust
แอปพลิเคชันเว็บสมัยใหม่ประกอบด้วยการไหลเวียนของข้อมูลทีซับซ้อน ดังทีแสดงในภาพที 3.5 การดําเนินการเพียง
หนึงครังอาจต้องมีการประมวลผลข้อมูลจากผูใ้ ช้ ดึงข้อมูลเพิมเติมจาก API ของบุคคลทีสาม ทําการตรวจสอบกับบริการ
ภายใน และเผยแพร่เหตุการณ์ไปยังคิวข้อความเพือการประมวลผลเพิมเติม คําถามทีสถาปนิกด้านความปลอดภัยทุกคนต้อง
พิจารณาในทีนีคือ: เราสามารถไว้วางใจสิงใดในกระบวนการเหล่านีได้บา้ ง? เราไว้วางใจข้อมูลจากผูใ้ ช้ได้หรือไม่? เราไว้วางใจ
API ของบุคคลทีสามได้หรือไม่? เราไว้วางใจบริการภายในได้หรือไม่? แล้วฐานข้อมูลของเราเองล่ะ?
ภาพที . แอปพลิเคชันสมัยใหม่ประกอบด้วยการไหลเวียนของข้อมูลทีซับซ้อน เช่น การไหลของคําขอเมือไคลเอนต์ส่งคําขอมายังเซิรฟ์ เวอร์
API ของเรา หรือการไหลของการตอบกลับเมือเราส่งคําตอบกลับไปยังคําขอ และการไหลของ API บุคคลทีสามเมือเราติดต่อกับบริการ
ภายนอก
คําตอบทีดีทีสุดสําหรับคําถามเหล่านีคือ โมเดลการรักษาความปลอดภัยแบบ Zero Trust แนวคิดของ Zero Trust
Security ถูกนําเสนอโดย John Kindervag ขณะทํางานที Forrester Research ซึงเป็ นองค์กรวิจยั ด้านความปลอดภัยไซเบอร์
ชันนํา [6] โมเดลของ Kindervag ชีให้เห็นว่า "ความไว้วางใจ" เป็ นจุดอ่อนสําคัญในระบบของเรา และเสนอให้ปฏิเสธการเข้าถึง
โดยค่าเริมต้นสําหรับทราฟฟิ กทุกประเภท ไม่ว่าจะมีแหล่งทีมาใดก็ตาม ซึงมักจะสรุปเป็ นคําพูดสัน ๆ ว่า "อย่าไว้วางใจอะไรเลย
ตรวจสอบเสมอ" นอกจากนี Kindervag ยังแนะนําให้มีการตรวจสอบ การวิเคราะห์ และการประเมินทราฟฟิ กทังหมดอย่าง
ต่อเนือง เพือระบุแหล่งทีมาของกิจกรรมทีน่าสงสัย
ภาพที . โมเดลสถาปั ตยกรรม Zero Trust ตามมาตรฐาน NIST ตรวจสอบทราฟฟิ กอย่างต่อเนือง เพือค้นหาพฤติกรรมทีเป็ นอันตราย
เน้นการบังคับใช้การควบคุมการเข้าถึงทีแข็งแกร่งและการ
ในช่วงไม่กีปี ทีผ่านมา แนวคิดเกียวกับ Zero Trust Security ได้พฒ
ั นาไปอย่างมาก และในปี 2020 สถาบันมาตรฐาน
และเทคโนโลยีแห่งชาติสหรัฐฯ (NIST) ได้พฒ
ั นากรอบแนวทางปฏิบตั ิทีดีทีสุดสําหรับการนําสถาปัตยกรรม Zero Trust มาใช้ ซึง
เรียกว่ามาตรฐาน NIST 800-207 [7] ดังทีแสดงในภาพที 3.6 มาตรฐาน NIST 800-207 กําหนดหลักการสําหรับ Zero Trust
Security ไว้ดงั นี:
1. เราปฏิบตั ิต่อแหล่งข้อมูลทังหมดเสมือนเป็ นทรัพยากร
2. เราตรวจสอบทราฟฟิ กทังหมดโดยไม่คาํ นึงถึงแหล่งทีมา
3. เราบังคับใช้การควบคุมการเข้าถึงตามผูใ้ ช้ โดยอิงตามโมเดลการให้สิทธิตําสุด (least-privileged model) ซึง
หมายความว่าผูใ้ ช้สามารถเข้าถึงเฉพาะทรัพยากรทีตนเป็ นเจ้าของหรือได้รบั อนุญาตให้ตรวจสอบและ/หรือ
จัดการเท่านัน
4. เราใช้นโยบายแบบไดนามิกในการกําหนดสิทธิการเข้าถึงของผูใ้ ช้ กล่าวคือ เราสามารถเปลียนแปลงสิทธิการ
เข้าถึงของผูใ้ ช้ได้ตลอดเวลา
5. เราตรวจสอบความสมบูรณ์ของทรัพยากรทังหมด หากทรัพยากรใดถูกบุกรุก เราจะจํากัดการเข้าถึงเพือ
ปกป้องผูใ้ ช้และระบบของเรา
6. เราตรวจสอบว่าทราฟฟิ กทังหมดมีขอ้ มูลรับรองสําหรับการยืนยันตัวตนและการอนุญาตทีคาดหวัง
7. เราตรวจสอบทราฟฟิ กทังหมดอย่างต่อเนืองเพือค้นหากิจกรรมทีน่าสงสัยและประเมินสถานะความปลอดภัย
ของระบบ
ภาพที . API แบบ Zero Trust ใช้หลักการของ NIST - เพือปกป้องทรัพยากรและจุดเชือมต่อทังหมด โดยบังคับใช้การควบคุมการ
เข้าถึงทีแข็งแกร่ง และตรวจสอบความถูกต้องของข้อมูลในทุกกระบวนการไหลเวียนของข้อมูล
สิงเหล่านีหมายถึงอะไรสําหรับ API? มันหมายถึงการกําจัดความไว้วางใจออกจากทุกส่วนในระบบของเรา อย่าไว้วางใจ
ผูใ้ ช้ใด ๆ ไม่ว่าพวกเขาจะผ่านการยืนยันตัวตนหรือไม่กต็ าม และไม่ว่าพวกเขาจะมีบทบาทอะไรในระบบ แม้กระทังในกรณีที
พวกเขาอ้างว่ามีสิทธิในระดับผูด้ แู ลระบบก็ตาม รวมถึง API ทีพวกเขาขอเข้าถึง ไม่วา่ จะเป็ น API ภายนอกหรือภายใน
โดยเฉพาะ API ภายใน (ดูเพิมเติมในหัวข้อ 3.4 เกียวกับ API ภายใน) แล้วเราหมายความว่าอย่างไรเมือเรากล่าวว่าเราไม่
สามารถไว้วางใจผูใ้ ช้ใด ๆ ได้? ดังทีแสดงในภาพที 3.7 โมเดลความปลอดภัยแบบ Zero Trust มีผลกระทบในวงกว้างต่อความ
ปลอดภัยของ API Zero Trust APIs ปกป้องทุกจุดเชือมต่อ (endpoint) ของตน บังคับใช้การตรวจสอบความถูกต้องใน
กระบวนการไหลของข้อมูลทังหมด เช่น คําขอ การตอบกลับ การผสานรวมกับบุคคลทีสาม และอืน ๆ และตรวจสอบกิจกรรม
ทังหมดอย่างต่อเนืองเพือค้นหาพฤติกรรมทีน่าสงสัย
รายการด้านล่างนีแสดงลักษณะสําคัญของ Zero Trust APIs:
1. ปกป้องจุดเชือมต่อ (endpoint) ทังหมดของคุณ
2. อย่าเปิ ดเผยจุดเชือมต่อหรือการดําเนินการทีไม่จาํ เป็ น
3. ตรวจสอบให้แน่ใจว่าการเรียก API ทุกครังมีแอตทริบิวต์ทถูี กต้องในการเข้าถึงระบบของคุณ เช่น ส่วนหัว
(headers) โทเค็น ข้อมูลรับรอง เป็ นต้น
4. บังคับใช้การควบคุมการเข้าถึงตามผูใ้ ช้สาํ หรับทรัพยากรทังหมด โดยยึดตามโมเดลการเข้าถึงทีให้สิทธิตําสุด
(least-privileged access model)
5. ตรวจสอบความถูกต้องของข้อมูลในคําขอ API ทังหมด รวมถึง payload และพารามิเตอร์ใน URL query และ
path
6. ตรวจสอบความถูกต้องของข้อมูลทังหมดก่อนทีจะส่งกลับไปยังผูใ้ ช้
7. ตรวจสอบความถูกต้องของข้อมูลทังหมดทีมาจาก API บุคคลทีสามก่อนประมวลผล
8. ตรวจสอบความถูกต้องของข้อมูลทังหมดทีมาจากบริการภายใน
9. ตรวจสอบกิจกรรมของผูใ้ ช้อย่างต่อเนืองเพือค้นหาพฤติกรรมทีน่าสงสัยและตอบสนองต่อสิงเหล่านัน
ลักษณะสําคัญชุดแรก (ข้อ 1-4) เกียวข้องกับการควบคุมการเข้าถึง Zero Trust APIs ปกป้องจุดเชือมต่อ (endpoint)
ทังหมดของตน API ส่วนใหญ่มแี นวคิดเกียวกับทรัพยากรแบบส่วนตัว (private) และแบบสาธารณะ (public) โดยทรัพยากร
แบบสาธารณะสามารถเข้าถึงได้โดยทุกคน
ในขณะทีทรัพยากรแบบส่วนตัวจะสามารถเข้าถึงได้เฉพาะผูท้ ีมีสิทธิทีถูกต้อง
เท่านัน แม้ในกรณีทีจุดเชือมต่อ (endpoint) สามารถเข้าถึงได้โดยสาธารณะสําหรับผูใ้ ช้ทุกคน เราก็ตอ้ งการมันใจว่าจะไม่มกี าร
ใช้งานในทางทีผิด ตัวอย่างเช่น แค็ตตาล็อกสินค้าบนอีคอมเมิรซ์ อาจเข้าถึงได้โดยผูใ้ ช้ทกุ คน แต่เราไม่ตอ้ งการให้ผไู้ ม่ประสงค์ดี
มาดึงข้อมูลทังหมดไปในทางทีไม่เหมาะสม
แล้วทรัพยากรแบบส่วนตัวหรือทีจํากัดการเข้าถึงตามผูใ้ ช้ล่ะ? API ส่วนใหญ่ใช้ JWT (JSON Web Token) เพืออนุญาต
การเข้าถึง JWT มีการอ้างสิทธิ (claims) เกียวกับสิทธิของผูใ้ ช้ในการเข้าถึง API บทบาท (role) และสิทธิพิเศษ (privileges)
รวมถึง ID ทีเป็ น opaque ซึงใช้ระบุผใู้ ช้ และข้อมูลอืน ๆ ดังทีแสดงในภาพที 3.8 งานของเราคือการตรวจสอบการอ้างสิทธิแต่
ละรายการเพือประเมินสิทธิของผูใ้ ช้ในการเข้าถึงทรัพยากรทีร้องขอ
ภาพที 3.8 ในการอนุญาตคําขอ (authorize request) เราตรวจสอบความถูกต้องของทุกองค์ประกอบและคุณสมบัติของ JWT รวมถึงลายเซ็น
การอนุญาต (Authorization) เป็ นหนึงในช่องโหว่ทีใหญ่ทีสุดใน API โดยเฉพาะในเรืองของการควบคุมการเข้าถึง [8]
ตัวอย่างเช่น ช่องโหว่ดา้ นความปลอดภัยของ API ทีพบได้บ่อยคือการสมมติว่าผูใ้ ช้ทีผ่านการยืนยันตัวตน (authenticated
users) ทุกคนเป็ นผูใ้ ช้ทีถูกต้องตามกฎหมาย และด้วยเหตุนีจึงผ่อนปรนการควบคุมการเข้าถึงสําหรับการดําเนินการทีได้รบั การ
ยืนยันตัวตน อย่างไรก็ตาม จากรายงานของ Salt Security พบว่า 78% ของการโจมตี API มาจากผูใ้ ช้ทีผ่านการยืนยันตัวตน
แล้ว [9] ซึงเป็ นปั ญหาสําคัญอย่างยิงในจุดเชือมต่อ (endpoint) ทีเปิ ดเผยข้อมูลหรือการดําเนินการทีมีความอ่อนไหว เช่น
การอัปเดตหรือการลบทรัพยากร ตัวอย่างเช่น ในเดือนกุมภาพันธ์ 2022 นักวิจยั ด้านความปลอดภัยทีใช้ชอว่
ื า Tree of Alpha
ได้คน้ พบช่องโหว่ใน API ของ Coinbase ซึงทําให้ผใู้ ช้สามารถขายสินทรัพย์ทีพวกเขาไม่ได้เป็ นเจ้าของได้ [10]
เพือป้องกันการละเมิดการอนุญาต ควรนําโมเดล Zero Trust Security มาใช้ตงแต่
ั เริมต้นการพัฒนา API ในขันตอนการ
ออกแบบ API เป็ นช่วงเวลาทีเหมาะสมในการตัดสินใจว่าจุดเชือมต่อ (endpoint) หรือการดําเนินการใดต้องการการดูแลเป็ น
พิเศษในแง่มมุ ของความปลอดภัย ตัวอย่างเช่น ดังทีแสดงในภาพที 3.9 ในแอปพลิเคชันอีคอมเมิรซ์ ผูใ้ ช้ทกุ คนอาจสามารถ
เรียกดูแค็ตตาล็อกสินค้าออนไลน์ได้ แต่เฉพาะผูใ้ ช้ทีผ่านการยืนยันตัวตนเท่านันทีสามารถอัปโหลดสินค้าลงระบบได้ และ
เฉพาะเจ้าของรายการสินค้านันเท่านันทีสามารถอัปเดตหรือลบรายการสินค้าได้
ภาพที . บนแพลตฟอร์มอีคอมเมิรซ์ ผูใ้ ช้ทีไม่ได้รบั การยืนยันตัวตนสามารถเรียกดูแค็ตตาล็อกสินค้าได้ แต่ไม่สามารถอัปโหลดสินค้าใหม่
หรือเปลียนแปลงรายละเอียดของสินค้าได้
การสร้างโปรไฟล์ดา้ นความปลอดภัยของ API ของเรา เช่นในภาพที 3.9 ช่วยให้เรามองเห็นได้ชดั เจนว่าควรเพิมการ
ควบคุมการเข้าถึงในส่วนใดบ้าง เราสามารถใช้ขอ้ มูลนีเพือเขียนการทดสอบการควบคุมการเข้าถึง และตรวจสอบให้แน่ใจว่า
การใช้งาน API สอดคล้องกับโมเดลความปลอดภัยของเรา ซึงเป็ นวิธีทีดีในการนํากลยุทธ์ความปลอดภัยของ API แบบ Shiftleft มาใช้
นอกจากการควบคุมการเข้าถึงทีแข็งแกร่งแล้ว Zero Trust APIs ยังต้องบังคับใช้การตรวจสอบความถูกต้องอย่าง
เข้มงวดในกระบวนการไหลของข้อมูลทังหมด ส่วนถัดไปจะอธิบายวิธีการดําเนินการดังกล่าว
3.3 ตรวจสอบทุกอย่าง!
มีคาํ กล่าวทีเป็ นทีนิยมในวงการซอฟต์แวร์วา่ "อย่าไว้วางใจไคลเอนต์" ความคิดนีคือเราไม่สามารถควบคุมได้วา่ ผูใ้ ช้จะมี
ปฏิสมั พันธ์กับแอปพลิเคชันของเราอย่างไร ดังนันเราจึงต้องบังคับใช้การตรวจสอบ (validation) และการล้างข้อมูล
(sanitization) อย่างเข้มงวดกับข้อมูลทังหมดทีส่งมายังเซิรฟ์ เวอร์ของเรา
ภาพที 3.10 แสดงรูปแบบทัวไปสําหรับการสร้างแอปพลิเคชันเว็บสมัยใหม่ทีใช้เฟรมเวิรก์ แบบ Single Page
Application (SPA) ในฝังส่วนหน้า (frontend) หรือทีเรียกกันว่าไคลเอนต์ (client) และใช้ API ในฝังส่วนหลัง (backend)
คําถามทีมักเกิดขึนในบริบทนีคือ: เราสามารถไว้วางใจไคลเอนต์วา่ จะส่งข้อมูลทีถูกต้องมายังเซิรฟ์ เวอร์ของเราได้หรือไม่?
ภาพที . รูปแบบทีได้รบั ความนิยมสําหรับการสร้างแอปพลิเคชันเว็บคือการใช้เฟรมเวิรก์ แบบ Single Page Application (SPA) เช่น React
ในฝังส่วนหน้า (frontend) และเชือมต่อกับ API ในฝังส่วนหลัง (backend)
ดังทีแสดงในภาพที 3.11 แอปพลิเคชันฝั งไคลเอนต์ชว่ ยจํากัดการป้อนข้อมูลของผูใ้ ช้และทําให้มนใจว่
ั าผูใ้ ช้จะส่งข้อมูล
ทีถูกต้องเท่านัน แต่ไม่มีสงใดที
ิ จะป้องกันไม่ให้ผใู้ ช้เข้าถึงเซิรฟ์ เวอร์ของเราโดยตรงได้ ความจริงคือ แอปพลิเคชันสมัยใหม่มกั
เปิ ดเผย API ในฝังส่วนหลัง (backend) ซึงผูใ้ ช้สามารถใช้งานได้อย่างถูกต้องผ่านไคลเอนต์ประเภทใดก็ได้ เช่น เทอร์มินลั
บรรทัดคําสัง (command-line terminal)
สิงนีหมายความว่าอย่างไรต่อโมเดลภัยคุกคาม (threat model) ของเรา?
มันหมายความว่าเราไม่สามารถคาดหวังได้ว่าผูใ้ ช้ทกุ คนจะส่งข้อมูลทีถูกต้อง และผูโ้ จมตี (threat actors) จะส่งคําขอที
เป็ นอันตราย (malicious requests) ทันทีเมือมีโอกาส
ภาพที . แอปพลิเคชันฝังไคลเอนต์มาพร้อมกับฟั งก์ชนั การตรวจสอบความถูกต้องของข้อมูล (data validation) ซึงช่วยให้มนใจว่
ั าผูใ้ ช้จะ
ส่งเฉพาะข้อมูลทีถูกต้องไปยังเซิรฟ์ เวอร์ของเราเท่านัน
ดังนัน เราสามารถไว้วางใจผูใ้ ช้ว่าจะส่งข้อมูลทีถูกต้องมายังเซิรฟ์ เวอร์ของเราได้หรือไม่? ไม่มีทางอย่างแน่นอน
เมือรับข้อมูลเข้าสู่ระบบของเรา เราต้องจัดการกับความเสียงสองประเภท:
 ความเสียงจากข้อมูลทีมีรูปแบบผิดปกติ (malformed) หรือข้อมูลทีไม่ถกู ต้อง (invalid)
 ความเสียงจากข้อมูลทีเป็ นอันตราย (malicious data)
ข้อมูลทีเป็ นอันตราย เป็ นสิงทีเข้าใจได้ในตัวมันเอง ตัวอย่างเช่น คําสัง SQL ทีเป็ นอันตรายหรือคําสังการประมวลผลที
อาจก่อให้เกิดความเสียหายหากมันเล็ดลอดเข้าสู่ระบบของเรา
แล้วข้อมูลทีมีรูปแบบผิดปกติหรือไม่ถกู ต้องล่ะ? ข้อมูลทีมีรูปแบบผิดปกติหรือไม่ถกู ต้อง คือข้อมูลทีไม่สอดคล้องกับข้อ
สมมติของโมเดลข้อมูล (data models) ของเรา เมือข้อมูลเหล่านีเข้าสู่ระบบ มันจะก่อให้เกิดข้อผิดพลาดทีสับสนและปั ญหาการ
ผสานระบบ (integration problems) ตัวอย่างเช่น ดังทีแสดงในภาพที 3.12 ระบบของเราอาจตังสมมติฐานเกียวกับข้อจํากัด
ของค่าข้อมูลบางประเภทในโมเดลข้อมูล และหากเราไม่บงั คับใช้ขอ้ จํากัดเหล่านัน แอปพลิเคชันของเราจะล้มเหลวเมือข้อมูล
นันถูกใช้งานในบริบทอืน ๆ
ภาพที . โมเดลข้อมูลพืนฐานใน API แค็ตตาล็อกหนังสือกําหนดว่ารูปแบบของหนังสือ (book formats) สามารถเป็ นได้เฉพาะ "printed"
หรือ "eBook" เท่านัน แต่ผใู้ ช้ระบุรูปแบบของหนังสือใหม่ว่า "digital" เมือข้อมูลนีถูกโหลดในบริบทอืน จะทําให้เกิดข้อผิดพลาดเนืองจากแอป
พลิเคชันไม่สามารถจัดการกับค่าทีไม่ถกู ต้องได้
เพือป้องกันความเสียงจากข้อมูลทีผิดรูปแบบหรือเป็ นอันตราย เราจําเป็ นต้องตรวจสอบความถูกต้องของข้อมูลทังหมด
ทีส่งมายังเซิรฟ์ เวอร์ของเราโดยไม่คาํ นึงถึงแหล่งทีมาของข้อมูลนัน แล้วสําหรับการไหลของข้อมูลอืน ๆ ล่ะ? ดังทีเราเห็นใน
หัวข้อก่อนหน้า (รูปที . ซึงได้นาํ มาแสดงซําในรูปที . เพือความสะดวก) แอปพลิเคชันสมัยใหม่มกี ารไหลของข้อมูลที
ซับซ้อน เช่น การไหลของคําขอ การไหลของการตอบสนอง การไหลของข้อมูลระหว่างฐานข้อมูลกับแอปพลิเคชัน และอื น ๆ เรา
สามารถไว้วางใจได้หรือไม่วา่ ข้อมูลทีไหลผ่านช่องทางเหล่านันปลอดภัยและถูกต้อง? คําตอบคือ ไม่ เราไม่สามารถไว้วางใจได้
เพือให้เข้าใจเหตุผล ลองมาดูรายละเอียดเกียวกับการไหลของข้อมูลเหล่านีบางส่วนกัน
รูปที . แอปพลิเคชันสมัยใหม่ประกอบด้วยการไหลของข้อมูลทีซับซ้อน เช่น การไหลของคําขอ การไหลของการตอบสนอง การไหลของ
API จากบุคคลทีสาม และอืน ๆ
ดังทีแสดงในรูปที 3.14 การไหลของข้อมูลจากบุคคลทีสามเกียวข้องกับการดึงข้อมูลจาก API ของบุคคลทีสาม ในแอป
พลิเคชันสมัยใหม่ การไหลของข้อมูลลักษณะนีเป็ นเรืองปกติมาก เราใช้แอปพลิเคชันจากบุคคลทีสามเพือทํางานทีซับซ้อนแต่
พบได้ทวไป
ั เช่น การส่งอีเมล การทําแผนทีพิกดั การจัดการปฏิทิน การชําระเงิน การลงนามเอกสาร การดึงข้อมูลโปรไฟล์ผใู้ ช้
จากแอปพลิเคชันบุคคลทีสาม และอืน ๆ
รูปที . แอปพลิเคชันสมัยใหม่ใช้ API ของบุคคลทีสามเพือจ้างงานทีพบได้ทวไปแต่
ั
มีความซับซ้อน เช่น การประมวลผลการชําระเงิน การ
ส่งอีเมล หรือการแก้ไขพิกดั ตําแหน่งของสถานที
สิงใดทีอาจผิดพลาดได้ในกรณีนี? การดึงข้อมูลจากแอปพลิเคชันของบุคคลทีสาม ดําเนินการกับข้อมูลเหล่านัน และ
จัดเก็บข้อมูลไว้ในเซิรฟ์ เวอร์ของพวกเขา ทําให้เราตกอยู่ในความเสียงจากรูปแบบภัยคุกคามของพวกเขาโดยตรง ดังทีแสดงใน
รูปที 3.15 หากแอปพลิเคชันของบุคคลทีสามมีชอ่ งโหว่ ผูไ้ ม่หวังดีอาจสามารถแทรกโค้ดทีเป็ นอันตรายหรือข้อมูลทีผิดพลาดเข้า
สู่ระบบของพวกเขาได้ และข้อมูล/โค้ดทีเป็ นอันตรายนันสามารถเล็ดลอดเข้าสู่ระบบของเราได้เช่นกัน ปัญหานีเรียกว่า "การ
บริโภค API ทีไม่ปลอดภัย" (Unsafe Consumption of APIs) และถือเป็ นหนึงในช่องโหว่สาํ คัญของ API สมัยใหม่
คําแนะนํา
"การบริโภค API ทีไม่ปลอดภัย" (Unsafe Consumption of APIs) ได้ถกู รวมอยู่ในรายการ OWASP Top 10 ของภัย
คุกคามต่อ API ในปี 2023 สําหรับคําอธิบายโดยย่อเกียวกับช่องโหว่นี สามารถตรวจสอบได้ทีเว็บไซต์ทางการ:
https://owasp.org/API-Security/editions/2023/en/0xaa-unsafe-consumption-of-apis/
เราจะเจาะลึกในหัวข้อนีเพิมเติมในหัวข้อ 4.10 แต่สาํ หรับตอนนี ขอเพียงกล่าวว่า คุณต้องใช้การตรวจสอบความถูกต้อง
(validation) และการทําความสะอาดข้อมูล (sanitization) ทีเข้มงวดกับข้อมูลทีมาจาก API ของบุคคลทีสาม
รูปที . ผูไ้ ม่หวังดีอปั เดตรายละเอียดของตนด้วยโค้ดทีเป็ นอันตรายบนผูใ้ ห้บริการยืนยันตัวตนภายนอก ต่อมาพวกเขาลงทะเบียนกับ
เว็บไซต์ของเราโดยนํารายละเอียดของตนจากผูใ้ ห้บริการภายนอกมาใช้ และโค้ดทีเป็ นอันตรายของพวกเขาทํางานกับฐานข้อมูลของเรา ส่งผล
ให้ตารางผูใ้ ช้ (users) ถูกลบออก
แล้วข้อมูลทีมาจากบริการภายในของเราเองล่ะ? แน่นอนว่าทุกสิงทีมาจากระบบของเราต้องปลอดภัยและถูกต้องใช่
ไหม? ไม่ใช่เสมอไป! ก่อนอืน การเชือมต่อระหว่างบริการ (service-to-service integrations) มีความซับซ้อน ดังทีแสดงในรูปที
3.16 แม้แต่ความผิดพลาดเพียงเล็กน้อยในรูปแบบ payload model ก็สามารถนําไปสู่ขอ้ ผิดพลาดทีลุกลามได้ ตัวอย่างเช่น ลอง
จินตนาการว่าบริการ A ตรวจสอบสถานะการชําระเงินกับบริการ B หากบริการ A คาดหวังค่าในรูปแบบ enumeration เช่น
"pending" หรือ "paid" แต่บริการ B ส่งค่ากลับมาเป็ น "processing" บริการ A อาจเกิดความล้มเหลว และผูใ้ ช้ปลายทางจะได้รบั
ข้อความแสดงข้อผิดพลาดทีสร้างความสับสน
เพือป้องกันสถานการณ์นี คุณต้องตรวจสอบความถูกต้องของข้อมูลทีมาจากบริการอืนเสมอ และแสดงข้อผิดพลาดที
เหมาะสมเมือได้รบั ข้อมูลทีไม่ถกู ต้อง นอกจากนี ควรแจ้งเตือนทีมทีเกียวข้องทันทีเพือให้รบั ทราบปัญหา
รูปที . เมือเราไม่ได้ตรวจสอบความถูกต้องของการตอบสนองจากบริการอืน เราเสียงทีจะกระตุน้ ให้เกิดข้อผิดพลาดลุกลาม ซึงนําไปสู่
ข้อผิดพลาดทีสร้างความสับสนให้กบั ผูใ้ ช้ของเรา
ปั ญหาทังหมดเหล่านีมารวมกันในกระบวนการไหลของข้อมูลตอบกลับ (response data flow) ทุกคําขอทีส่งไปยัง API
ของเราจําเป็ นต้องมีการตอบกลับ และบ่อยครังการตอบกลับนันจะมีขอ้ มูลอยู่ดว้ ย ยกเว้นการตอบกลับแบบ 204 ซึงไม่มีขอ้ มูล
[11] ดังทีแสดงในรูปที 3.17 การสร้างการตอบกลับมักเกียวข้องกับการดึงข้อมูลจากฐานข้อมูลของเรา การรวบรวมข้อมูลจาก
บริการอืน ๆ API ของบุคคลทีสาม และสุดท้ายคือการนําข้อมูลทังหมดมารวมกันในรูปแบบ payload เดียว กระบวนการนีทําให้
การไหลของข้อมูลตอบกลับต้องเผชิญกับความเสียงจากการไหลของข้อมูลทังจากบุคคลทีสามและการเชือมต่อระหว่างบริการ
แต่ยงั มีอีกเรืองทีต้องพิจารณา แล้วข้อมูลทีมาจากฐานข้อมูลของเราเองล่ะ? ข้อมูลเหล่านันสามารถไว้วางใจได้หรือไม่? คําตอบ
คือ ไม่เสมอไป
รูปที . การสร้าง payload สําหรับการตอบกลับมักเกียวข้องกับการรวบรวมข้อมูลจากแหล่งต่าง ๆ เช่นในตัวอย่างนี ผูใ้ ช้รอ้ งขอสถานะของ
คําสังซือของตน ซึงในกรณีนี บริการจัดการคําสังซือจะรวบรวมข้อมูลจาก API ของบุคคลทีสาม บริการภายในอืน ๆ และฐานข้อมูลของตนเอง
ดังทีแสดงในรูปที 3.18 มีหลายวิธีทีข้อมูลในฐานข้อมูลของเราอาจถูกเปลียนแปลงได้ ไม่วา่ จะเป็ นการเปลียนแปลงด้วย
ตนเอง สคริปต์ทีทํางานผิดพลาด หรือการย้ายข้อมูลทีผิดพลาด โปรดจําไว้วา่ เหตุการณ์ดา้ นความปลอดภัยทางไซเบอร์ไม่ใช่
เรืองของ "จะเกิดหรือไม่" แต่เป็ นเรืองของ "เมือไหร่จะเกิด" และเราต้องเตรียมพร้อมรับมือกับเหตุการณ์เหล่านี
ตรวจสอบให้แน่ใจว่าคุณตรวจสอบความถูกต้องของข้อมูลทีดึงจากฐานข้อมูลเสมอ โดยใช้ไลบรารีสาํ หรับตรวจสอบ
สคีมา (schema validation libraries) หรือ Object Relational Mappers (ORMs) ซึง ORMs ช่วยสร้างการจับคู่แบบหนึงต่อ
หนึงระหว่างโมเดลของเราและตารางในฐานข้อมูล และ ORMs ทีดีจะช่วยตรวจสอบข้อกําหนด เช่น ค่าในรูปแบบ enumeration
รูปที . ฐานข้อมูลของเราอาจเสียหายได้หลายวิธี เช่น สคริปต์ทีทํางานผิดพลาด การย้ายข้อมูลทีผิดพลาด หรือการเปลียนแปลงด้วยตนเอง
หากเราไม่ตรวจสอบความถูกต้องของข้อมูลทีดึงมาจากฐานข้อมูล เราเสียงทีจะเกิดข้อผิดพลาดลุกลามและสร้างความสับสนในแอปพลิเคชัน
ของเรา
อะไรทีเหลืออยู่ในกระบวนการไหลของข้อมูลตอบกลับ? ดังทีแสดงในรูปที 3.19 ขันตอนสุดท้ายคือการรวบรวมข้อมูลที
เราได้มาจากแหล่งต่าง ๆ และจัดเรียงให้เป็ น payload เดียว ก่อนทีจะส่ง payload ไปยังผูใ้ ช้ ตรวจสอบให้แน่ใจว่าข้อมูลนัน
สอดคล้องกับสคีมาของ API ทีถูกต้อง การตรวจสอบ payload ในขันตอนนีช่วยให้คณ
ุ มันใจว่าจะไม่ส่งข้อมูลทีผิดรูปแบบไปยัง
ลูกค้า และยังช่วยให้คณ
ุ สามารถแสดงข้อผิดพลาดทีชัดเจนเมือข้อมูลทีไม่ถกู ต้องรัวไหลเข้าสู่ payload ซึงจะช่วยเพิม
ความสามารถในการมองเห็นและติดตามปัญหาได้
รูปที . Zero Trust API ช่วยให้ผใู้ ช้มนใจว่
ั าจะได้รบั ข้อมูลทีถูกต้อง โดยการตรวจสอบความถูกต้องของข้อมูลจากทุกแหล่ง โดยไม่คาํ นึงถึง
ทีมาของข้อมูล
เป็ นทีชัดเจนว่าเราต้องตรวจสอบความถูกต้องของการไหลของข้อมูลทังหมดเพือปกป้องความปลอดภัยและความ
สมบูรณ์ของระบบของเรา คําถามสําคัญทีตามมาคือ: แล้ว API ภายในล่ะ? เราจะมาพูดถึงเรืองนีในหัวข้อถัดไป
. ไม่มีสิงทีเรียกว่า Internal API
องค์กรต่าง ๆ สร้าง API ด้วยวัตถุประสงค์ทแตกต่
ี
างกัน เช่น การนําเสนอผลิตภัณฑ์และบริการผ่าน API หรือเพือ
สนับสนุนการเชือมต่อระหว่างส่วนประกอบภายใน อีกหนึงการใช้งาน API ทีได้รบั ความนิยมคือการทําให้กระบวนการภายใน
เป็ นแบบอัตโนมัติ ซึงรูจ้ กั กันในชือ Back-office API เนืองจากไม่ได้เกียวข้องโดยตรงกับการขาย Back-office API มีบทบาทใน
การจัดการพนักงานและเงินเดือน การเตรียมการคาดการณ์ยอดขาย การจัดการโครงการ และกระบวนการภายในอื น ๆ
เนืองจากลักษณะเฉพาะตัว Back-office API จึงเปิ ดเผยข้อมูลทีมีความอ่อนไหวสูง เช่น ข้อมูลของพนักงาน ลูกค้า
ความลับทางธุรกิจ และความลับทางการค้า ยิงองค์กรมีขนาดใหญ่ขึนเท่าไร จํานวน API ประเภทนีก็ยิงมากขึนตามไปด้วย
เนืองจาก Back-office API มีไว้สาํ หรับการใช้งานภายใน จึงมักถูกเข้าใจว่าเป็ น “Internal API” หมายความว่าไม่ได้เป็ น
สาธารณะ รายละเอียดของการนําไปใช้จะแตกต่างกันไปในแต่ละองค์กร แต่บ่อยครัง “Internal API” จะทํางานอยู่ในเครือข่าย
ส่วนตัว ดังทีแสดงในรูปที . การแบ่งเครือข่ายออกเป็ นกลุม่ ย่อย (subnets) ทีมีระดับการเข้าถึงทีแตกต่างกันเรียกว่า
Network Segmentation ซึงเป็ นแนวปฏิบตั ิดา้ นความปลอดภัยทีมีประสิทธิภาพมาก แต่ไม่ควรเป็นกลยุทธ์ดา้ นความปลอดภัย
เพียงอย่างเดียวของเรา
รูปที . องค์กรมักมีทงั Public API และ Internal API โดย Public API สามารถเข้าถึงได้โดยผูใ้ ช้งานภายนอกทังหมด ในขณะที Internal
API มีไว้สาํ หรับพนักงานเท่านัน Internal API ช่วยทําให้งานภายใน เช่น การจัดการลูกค้าและสินค้าคงคลังเป็ นแบบอัตโนมัติ และเนืองจาก
ข้อมูลทีมีความอ่อนไหวทีมันเก็บไว้ Internal API จึงทํางานอยู่ในเครือข่ายส่วนตัว
ตามธรรมเนียม ทีมรักษาความปลอดภัยทางไซเบอร์มกั มองว่า Internal API มีความเสียงน้อยกว่า เพราะมันทํางานอยู่
ในเครือข่ายส่วนตัว น่าเสียดายทีความคิดนีทําให้ Back-office API มักไม่ได้รบั ความสนใจมากพอในด้านการออกแบบและการ
รักษาความปลอดภัย ซึงทําให้มนั กลายเป็ นระเบิดเวลาทางด้านความปลอดภัย Internal API มักประสบปั ญหาขาดการควบคุม
การอนุญาตและการเข้าถึง (authorization and access controls) การเปิ ดเผยข้อมูลมากเกินไป (excessive data exposure)
การขาดเอกสารประกอบ และอืน ๆ ดังนัน หาก Internal API กลายเป็ นสาธารณะโดยไม่ได้ตงใจเนื
ั
องจากข้อผิดพลาดในการตัง
ค่าหรือการปรับใช้ (deployment) ความปลอดภัยของเราจะถูกละเมิดในทันที
แล้วความเป็ นไปได้ทีจะเกิดเหตุการณ์นีมีมากแค่ไหน? จากข้อมูลของ Salt Security ในปี
พบว่า % ของการโจมตี
API ทังหมดพุ่งเป้าไปที Internal API [ ] และเรามีเหตุผลทีจะเชือว่าความเสียงนีจะเพิมขึนในอีกไม่กีปี ขา้ งหน้า
ตัวอย่างของเหตุการณ์นเกิ
ี ดขึนในเดือนกันยายน
กับ Optus ซึงเป็ นผูใ้ ห้บริการโทรคมนาคมรายใหญ่อนั ดับสาม
ของออสเตรเลีย ตามข้อมูลจากแหล่งข่าวภายใน Optus ได้สร้าง Customer Identity API ขึนมาเพือใช้ในโครงการทีใหญ่กว่า
ซึงเกียวข้องกับการเปิ ดใช้งานระบบยืนยันตัวตนแบบสองปั จจัย (two-factor authentication) API นีถูกออกแบบมาสําหรับการ
ใช้งานภายใน และควรจะทํางานในเครือข่ายส่วนตัวเท่านัน จึงไม่มกี ารควบคุมการเข้าถึงใด ๆ เช่น การยืนยันตัวตน
(authentication) หรือการอนุญาต (authorization) อย่างไรก็ตาม API ดังกล่าวกลับถูกปรับใช้โดยไม่ได้ตงใจใน
ั
"เครือข่าย
ทดสอบทีสามารถเข้าถึงอินเทอร์เน็ตได้" และส่งผลให้ขอ้ มูลลูกค้านับล้านรายการรัวไหล [ ]
เราสามารถเรียนรูอ้ ะไรจากกรณีขอ้ มูลรัวไหลของ Optus ได้บา้ ง?
 ประการแรก API ทุกตัวจะต้องได้รบั การป้องกันอย่างเพียงพอด้วยระบบการยืนยันตัวตน (authentication)
และการอนุญาต (authorization) ทีมีความแข็งแกร่ง ยิง API เปิ ดเผยข้อมูลทีมีความอ่อนไหวมากเท่าไร การ
ควบคุมการเข้าถึง (access controls) ก็ตอ้ งเข้มงวดมากขึนเท่านัน
 บทเรียนทีสอง ไม่มีสิงทีเรียกว่า Internal API ไม่ว่า API จะถูกปรับใช้ในเครือข่ายส่วนตัวหรือไม่กต็ าม ก็ถือว่า
เป็ นการแบ่งแยกทีไม่สมเหตุสมผล ความเสียงจากความผิดพลาดของมนุษย์ในการปรับใช้ API หรือการตังค่า
เครือข่ายมีอยูเ่ สมอ วิธีทดีี ทีสุดในการป้องกันการรัวไหลของข้อมูลคือการใช้ Zero Trust Security Model กับ
API ทังหมดของเรา
อย่างไรก็ตาม สิงนีไม่ได้หมายความว่าการปรับใช้ Internal API ในเครือข่ายส่วนตัวจะไม่มีประโยชน์ Network
Segmentation ยังคงเป็ นวิธีการรักษาความปลอดภัยทีมีประสิทธิภาพ และสิงทีไม่ควรเป็ นสาธารณะก็ไม่ควรเปิ ดเผยสู่
สาธารณะ แต่เครือข่ายส่วนตัวไม่ควรเป็ นกลยุทธ์หลักหรือกลยุทธ์เดียวของเรา ในความเป็ นจริง ตามที Kindervag เน้นยําว่า
“[n]etwork segmentation is a tactic and a tool, not a strategy for building secure networks.” หรือ "การแบ่งเครือข่าย
เป็ นเครืองมือและยุทธวิธี แต่ไม่ใช่กลยุทธ์สาํ หรับสร้างเครือข่ายทีปลอดภัย"
เพือป้องกัน API ของเราอย่างเหมาะสม เราต้องมีวธิ ีการทีมีรากฐานลึกกว่านัน เราต้อง Shift Left ด้านความปลอดภัย ซึง
หมายถึงการผนวกหลักการด้านความปลอดภัยทีอธิบายไว้ในบทนีตังแต่ระยะแรกของการพัฒนา
คําถามทียังคงเหลืออยูค่ ือ: เราจะรูไ้ ด้อย่างไรว่าเรากําลังปกป้องทรัพย์สินทังหมดของเราอยู่? เราจะมาพูดถึงคําถามนีใน
หัวข้อถัดไป!
. คุณไม่สามารถปกป้องสิงทีคุณไม่รู ้
เราเข้าใจดีว่าเราต้องปกป้อง API ทังหมดของเรา ไม่วา่ จะเป็ น Public API หรือ Private API แต่คาํ ถามสําคัญคือ API
ของเราอยู่ทีไหน? หนึงในความเสียงทีใหญ่ทีสุดทีองค์กรต้องเผชิญในด้าน API คือการขาดเอกสารประกอบ (documentation)
ซึงเป็ นส่วนหนึงของปัญหาทีใหญ่กว่าทีเรียกว่า API Sprawl
API Sprawl หมายถึงการเพิมจํานวนของ API ภายในองค์กรอย่างรวดเร็ว โดยไม่มกี ารติดตาม ตรวจสอบ หรือประเมิน
สถานะความปลอดภัยของ API เหล่านันอย่างเหมาะสม อุตสาหกรรมด้านความปลอดภัยของ API ได้ตงชื
ั อทีน่าสนใจสําหรับ
ประเภทของ API ทีเกิดขึนในสถานการณ์ API Sprawl เช่น Shadow APIs, Zombie APIs, และ Ghost APIs [14]
รูปที . แสดงความแตกต่างระหว่างประเภทของ API เหล่านี และย่อหน้าต่อไปนีจะอธิบายรายละเอียดเพิมเติม
เกียวกับแต่ละประเภท
รูปที . API Sprawl เพิมความเสียงต่อการเกิด Shadow API, Zombie API และ Ghost API ซึง API เหล่านีมักได้รบั การป้องกันน้อยกว่า
และเมือแฮกเกอร์คน้ พบ API เหล่านี อาจนําไปสู่การรัวไหลของข้อมูลได้
เมือองค์กรเริมดําเนินโครงการ Digital Transformation การย้ายระบบไปยัง Cloud การปรับปรุงแอปพลิเคชันให้ทนั สมัย
และโครงการอืน ๆ ทีคล้ายคลึงกัน องค์กรมักจําเป็ นต้องเผยแพร่ API เพือแสดงฟังก์ชนั การทํางานและบริการใหม่ ๆ น่าเสียดาย
ที API จํานวนมากเหล่านีถูกสร้างขึนอย่างเร่งรีบ (ad-hoc) โดยไม่มกี ารวางแผน ออกแบบ ทดสอบ หรือประเมินความปลอดภัย
อย่างเหมาะสม API เหล่านีทีถูกสร้างขึน “โดยไม่เป็ นทีสังเกต” รูจ้ กั กันในชือ Shadow APIs
Shadow APIs มักไม่มเี อกสารประกอบ ไม่ได้ถกู รวมไว้ในรายการ API กลางขององค์กร และมีเพียงสมาชิกไม่กีคนใน
องค์กรเท่านันทีทราบถึงการมีอยูข่ องมัน
คําจํากัดความ
API Sprawl คือการเพิมจํานวนของ API อย่างไม่มกี ารควบคุม มักเกิดการซําซ้อนของฟั งก์ชนั การทํางานทีมีอยู่แล้ว และ
ไม่มีเอกสารประกอบ
คําจํากัดความ
Shadow APIs คือ API ทีถูกสร้างและปล่อยใช้งาน "โดยไม่เป็ นทีสังเกต" โดยไม่ได้ผ่านกระบวนการทดสอบและ
ประเมินผลอย่างเหมาะสม API เหล่านีมักไม่มเี อกสารประกอบ มีความปลอดภัยน้อย และมักถูกลืมอย่างรวดเร็ว ซึงทําให้
เกิดช่องโหว่ในระบบ
คําจํากัดความ
Zombie APIs คือ API ทีถูกยกเลิกการใช้งานแล้ว หรือเวอร์ชนั เก่าของ API ทีเราลืมปิ ดการใช้งาน API เหล่านีไม่ได้รบั การ
ดูแลรักษาอีกต่อไป แต่ยงั คงถูกเปิ ดเผยอยู่บนอินเทอร์เน็ต
คําจํากัดความ
Ghost APIs คือ API ทีถูกเปิ ดเผยโดยไลบรารีหรือโครงสร้างพืนฐานของเรา Ghost APIs จะไม่เป็ นปัญหา ตราบใดทีเรา
รับทราบถึงการมีอยูข่ องมันและดําเนินมาตรการป้องกันทีเหมาะสม
ในทีสุด API เงา (Shadow APIs) หลายตัวก็มกั จะถูกลืมไป โดยยังคงเผยแพร่อยู่แต่ไม่มีใครดูแลหรือจัดการกับมันอีก
API ทีถูกลืมเหล่านีเรียกว่า "Zombie APIs" หรือ API ซอมบี ส่วน API ผี (Ghost APIs) คืออะไร? Ghost APIs คือ API ทีเรา
ไม่ได้สร้างขึนมาเอง แต่ถกู พัฒนาขึนโดยผูอ้ นื ดังนันจึงถูกเรียกว่า "เขียนแทน" (ghostwritten) ยกตัวอย่างเช่น ไลบรารีแบบ
โอเพนซอร์สทีอาจเปิ ดเผยจุดเชือมต่อ (endpoints) โดยไม่ได้มีเอกสารอธิบายไว้อย่างชัดเจน หรืออาจมีการพึงพา
(dependencies) ทีเป็ นอันตราย ซึงเปิ ดช่องโหว่หรือ Backdoor ให้กบั ผูโ้ จมตีได้
ในเดือนพฤศจิกายน 2020 ทีมรักษาความปลอดภัยของ NPM ได้ลบไลบรารีทีชือว่า “twilio-npm” ออกจากทีเก็บโค้ด
(repository) เนืองจากตรวจพบว่าไลบรารีดงั กล่าวเปิ ดเผย Backdoor ผ่าน TCP ดูรายละเอียดเพิมเติมได้จากบทความของ
Pierluigi Paganini เรือง “Malicious NPM library removed from the repository due to backdoor capabilities,” ในเว็บไซต์
Security Affairs วันที 3 พฤศจิกายน 2020 (https://securityaffairs.com/110348/malware/npm-library-backdoor.html)
ในทํานองเดียวกัน บริการคลาวด์บางครังอาจเปิ ดเผยจุดเชือมต่อสําหรับการกําหนดค่าและการจัดการ ยกตัวอย่างเช่น
อินสแตนซ์ AWS EC2 จะเปิ ดเผยจุดเชือมต่อทีเรียกว่า Instance Metadata Service (IMDS) ซึงช่วยให้สามารถดึงคียก์ ารเข้าถึง
AWS (AWS Access Keys) และรายละเอียดอืน ๆ ได้ จุดเชือมต่อ IMDS นีสามารถเข้าถึงได้จากภายในอินสแตนซ์ EC2 เท่านัน
แต่ก็อาจถูกโจมตีผา่ นกลยุทธ์ทีเรียกว่า Server-Side Request Forgery (SSRF) ซึงทําให้ผโู้ จมตีสามารถสังให้ระบบเรียก API
ไปยังจุดเชือมต่อใด ๆ ทีต้องการ
ปั ญหานีมีขนาดใหญ่เพียงใด? จากรายงาน The 2022 API Security Trends Report ของ S&P พบว่า องค์กรต่าง ๆ ใช้
API เฉลีย 15,564 ตัว โดยองค์กรขนาดใหญ่ทมีี พนักงานมากกว่า 10,000 คนใช้ API เฉลียถึง 25,592 ตัว และจํานวน API ที
องค์กรใช้งานนันกําลังเติบโตอย่างรวดเร็วในอัตราเฉลีย 201% ในช่วง 12 เดือนก่อนหน้าการสํารวจ นอกจากนี API จํานวนมาก
ยังไม่มเี อกสารประกอบอย่างชัดเจน ซึงไม่นา่ แปลกใจเลยทีกลายเป็ นหนึงในข้อกังวลด้านความปลอดภัยสูงสุดสําหรับองค์กร
[16]
ทําไมปัญหานีถึงสําคัญ? ประการแรก เพราะ Shadow APIs และ Zombie APIs มักมีมาตรการรักษาความปลอดภัยที
อ่อนแอกว่า ซึงทําให้เกิดความเสียงต่อความปลอดภัยของระบบ ประการทีสอง หากคุณไม่ทราบจํานวน API ทีคุณใช้งานอยู่
คุณก็ไม่สามารถประเมินได้ว่าพืนทีโจมตี (Attack Surface) ของคุณมีลกั ษณะอย่างไร ตามทีได้กล่าวไว้ในหัวข้อ 2.1 การทํา
แผนทีพืนทีโจมตีเป็ นขันตอนเบืองต้นทีสําคัญสําหรับการเตรียมความพร้อมด้านความปลอดภัยของ API และจําเป็ นต่อการ
ประเมินมาตรการรักษาความปลอดภัยของ API โดยรวม
แล้วคุณจะทําแผนทีพืนทีโจมตีและติดตาม API ทังหมดได้อย่างไร? คําตอบคือคุณจําเป็ นต้องมีเอกสารประกอบ API
ดังที Bruno Pedro ได้กล่าวไว้วา่ มีเอกสาร API หลายประเภท เช่น ข้อกําหนด (Specifications) บทแนะนํา (Tutorials) คู่มอื
วิธีใช้งาน (How-to Guides) ตัวอย่างโค้ด (Code Samples) และการบันทึกการเปลียนแปลง (Changelogs) [17] หากคุณ
นําเสนอผลิตภัณฑ์และบริการผ่าน API โดยตรง การใช้กลยุทธ์การจัดทําเอกสารทังหมดนีถือเป็ นแนวทางทีดี เพือมอบ
ประสบการณ์ทีดีให้กบั นักพัฒนา (Developer Experience) และลดระยะเวลาทีนักพัฒนาต้องใช้จนถึงการเรียก API ครังแรก
(Time to First Call) [18]
เครืองมือทีดีทีสุดสําหรับการจัดทําเอกสารพืนทีโจมตี (Attack Surface) ของคุณคือ API Specification หรือข้อกําหนด
ของ API โดย API Specification เป็ นคําอธิบายอย่างเป็ นทางการของ API ซึงใช้มาตรฐานการจัดทําเอกสาร เช่น OpenAPI
สําหรับ REST APIs หรือ Schema Definition Language สําหรับ GraphQL API Specifications นันมีความชัดเจนและ
สามารถอ่านได้โดยเครือง (Machine-Readable) ซึงหมายความว่าเราสามารถใช้ประโยชน์จากมันสําหรับการทดสอบอัตโนมัติ
การประเมินผล และการจัดทํารายการ (Cataloguing) หากคุณยังไม่มีขอ้ กําหนดมาตรฐานสําหรับ API ของคุณ นันคือปัญหา
แรกทีคุณต้องแก้ไขเพือปรับปรุงมาตรการรักษาความปลอดภัยของระบบ
แม้วา่ API Specifications จะมีประโยชน์ในการทําความเข้าใจการทํางานของ API เพียงตัวเดียว แต่ถา้ คุณต้องจัดการ
API นับร้อยหรือนับพันตัวล่ะ? คุณจําเป็ นต้องมี API Catalog หรือระบบจัดเก็บรายการ API API Catalog เป็ นเครืองมือทีช่วย
ให้คณ
ุ ติดตาม API ทังหมดในทีเดียว ด้วย Catalog นี คุณสามารถค้นหาและสํารวจฟังก์ชนั ทีมีอยูแ่ ล้วภายในองค์กรของคุณ
ทําไมสิงนีถึงมีประโยชน์? เพราะเมือคุณมี API มากถึง 15,000 ตัว และกําลังวางแผนจะสร้าง API ตัวใหม่ อาจเป็ นไปได้
ว่าคุณไม่จาํ เป็ นต้องสร้างเพิม เพราะ API ทีคุณต้องการอาจมีอยู่แล้วใน Catalog สําหรับองค์กรขนาดใหญ่ API Catalog จึงเป็ น
เครืองมือสําคัญในการจัดการปัญหา API ทีกระจายตัวอยู่มากมาย (API Sprawl)
คําจํากัดความ
API Catalog คือรายการของ API ทังหมดทีคุณมี API Catalog ทีดีจะมีคาํ อธิบายเกียวกับ API แต่ละตัว และช่วยให้เรา
สามารถค้นหาและสํารวจฟังก์ชนั ทีมีอยู่แล้ว เพือหลีกเลียงการสร้าง API ซํา
คุณจะสร้าง API Catalog ได้อย่างไร? วิธีการอาจเรียบง่ายเพียงแค่สร้างรายการ API ทีมีอยู่ พร้อมระบุเวอร์ชนั และ
คําอธิบายของแต่ละ API โดยทัวไปแล้ว APIs.json (https://apisjson.org/) เป็ นมาตรฐานอ้างอิงในด้านนี APIs.json เป็ น
ข้อกําหนดแบบเปิ ด (Open Specification) สําหรับการทําดัชนี API ซึงคล้ายกับ sitemap.xml สําหรับเว็บไซต์ และยังรองรับ
องค์ประกอบทีมนุษย์อา่ นได้ เช่น ข้อมูลการกําหนดราคา ข้อกําหนดการให้บริการ เป็ นต้น เมือไม่นานมานี Kevin Smith ซึงเป็ น
นักกลยุทธ์ดา้ นเทคโนโลยีอาวุโสจาก Vodafone ได้เสนอร่างมาตรฐานอินเทอร์เน็ตทีกําหนดตําแหน่งสําหรับ API Catalog
ภายใต้ URI ทีเป็ นทีรูจ้ กั นันคือ /.well-known/api-catalog [19]
แน่นอนว่า API Catalog จะมีประโยชน์สงู สุดเมือคุณสามารถมองเห็นได้วา่ องค์กรของคุณกําลังพัฒนา API อะไรอยู่และ
เพือวัตถุประสงค์อะไร แต่ในกรณีของ Shadow APIs ทีทีมพัฒนาของคุณอาจนําไปใช้งานโดยไม่ได้รบั การตรวจสอบ คุณอาจ
ต้องสํารวจเครืองมือเชิงพาณิชย์ทีสามารถตรวจสอบทราฟฟิ ก API ของคุณเพือค้นหา API ทังหมด และสร้างรายการ API แบบ
อัตโนมัติในทันที [20] ดังทีแสดงในภาพ 3.22 วิธีการนีมีประสิทธิภาพอย่างมากสําหรับการค้นหา Shadow APIs และ Zombie
APIs เมือใช้รว่ มกับการจัดทํารายการสินทรัพย์ (Assets) ทีคุณรูจ้ กั อยู่แล้ว
พืนทีของ API Catalog กําลังอยู่ในช่วงพัฒนาอย่างต่อเนือง ดังนันควรทําการค้นคว้าตัวเลือกต่าง ๆ ทีเหมาะสมก่อน
ตัดสินใจเลือกใช้เครืองมือใด ๆ
รูปที . เครืองมือสังเกตการณ์ API (API Observability Tools) จะตรวจสอบทราฟฟิ กของคุณและค้นหาพืนทีโจมตีทีไม่ได้รบั การบันทึกไว้
(Undocumented Attack Surface) โดยการตรวจสอบว่า API Server ของคุณยอมรับคําขอ (Requests) ใดบ้าง
เมือคุณค้นพบ Shadow APIs ของคุณแล้ว วิธีทีดีทีสุดคือการปรับปรุงความปลอดภัยของ API โดยการเลือน
กระบวนการความปลอดภัยไปไว้ในช่วงเริมต้น (Shift Security Left) ซึงหมายถึงการวางแผนและจัดทํา API Catalog ก่อนการ
นํา API ไปใช้งาน คุณจะต้องประสานงานกับองค์กรของคุณเพือให้แน่ใจว่าทุกคนเข้าใจถึงความจําเป็ นของกระบวนการนี (ดู
คําแนะนําเพิมเติมในหัวข้อ 2.5) และต้องมีกลไกในการป้องกันการปรับใช้ API โดยไม่ได้รบั อนุญาต
ในบทที 8 คุณจะได้เรียนรูว้ ิธีการออกแบบระบบจัดการตัวตนและการเข้าถึง (Identity and Access Management IAM) โดยยึดหลักการสิทธิขันตําสุด (Least-Privileged Principle) เพือสร้างกระบวนการปรับใช้งานทีมีโครงสร้างและโปร่งใส
3.6 DevSecOps สําหรับ API
เราได้เรียนรูส้ ิงสําคัญหลายอย่างเกียวกับการเลือนกระบวนการความปลอดภัยของ API ไปไว้ในช่วงเริมต้น (Shift-Left
Security) ความปลอดภัยแบบ Zero Trust ความสําคัญของการตรวจสอบความถูกต้องของการไหลของข้อมูลทังหมด และการ
ทําแผนทีพืนทีโจมตี (Attack Surface) คําถามต่อมาคือ ทุกอย่างเหล่านีจะเชือมโยงเข้ากับวงจรการพัฒนาซอฟต์แวร์
(Software Development Life Cycle - SDLC) ได้อย่างไร? และกระบวนการสร้าง API ตามหลักการ Shift-Left Security มี
ลักษณะเป็ นอย่างไร?
ในหัวข้อนี เราจะสํารวจบทบาทของความปลอดภัยในกระบวนการพัฒนา API ตามทีแสดงในรูปที 3.23 ซึงแสดงโมเดล
ของ SDLC ทีเหมาะสมทีสุดสําหรับ API และในส่วนทีเหลือของหัวข้อนี เราจะลงรายละเอียดของแต่ละขันตอนทีแสดงในรูปที
3.23
รูปที . การเลือนกระบวนการความปลอดภัยไปไว้ในช่วงเริมต้น (Shift-Left on Security) หมายถึงการประเมินช่องโหว่ในทุกขันตอนของ
วงจรการพัฒนา (Development Cycle) และจะไม่ดาํ เนินการต่อจนกว่าจะมีการจัดการกับช่องโหว่นันเรียบร้อยแล้ว
ดังทีแสดงในรูปที 3.24 ทุกอย่างเริมต้นทีขันตอนการออกแบบ (Design) ในขันตอนนี เราจะมุง่ เน้นไปทีความสามารถที
เราต้องการนําเสนอผ่าน API ประเภทของข้อมูลทีเรายินดีเปิ ดเผย และการไหลของผูใ้ ช้งาน (User Flows) ทีจะช่วยให้ลกู ค้าของ
เราบรรลุเป้าหมาย นีเป็ นโอกาสสําคัญทีจะระบุการดําเนินงานทีมีความอ่อนไหวซึงจําเป็ นต้องพิจารณาด้านความปลอดภัย
เพิมเติม ผลลัพธ์จากกระบวนการนีคือ API Specification ซึงจะอธิบายข้อกําหนดของเราอย่างละเอียด
รูปที . การออกแบบ API เป็ นโอกาสทีดีในการประเมินความเปราะบางของการไหลของผูใ้ ช้งาน (User Flows) และกําหนดจุดทีเรา
จําเป็ นต้องให้ความใส่ใจเป็ นพิเศษในมุมมองด้านความปลอดภัย เราจะเขียนการทดสอบทังในด้านฟั งก์ชนั การทํางานและความปลอดภัยเพือ
สะท้อนถึงความคาดหวังของเรา
ในขันตอนต่อมา เราจะใช้ API Specification เป็ นเอกสารสําคัญ (Artifact) สําหรับตรวจสอบความถูกต้องของการ
พัฒนา (Implementation) และประเมินมาตรการความปลอดภัย (Security Posture) ของเรา ดังนันจึงเป็ นสิงสําคัญทีผูม้ ีส่วน
เกียวข้องทุกคนจะต้องสามารถเข้าถึงเอกสารนีได้ และเราควรมีระบบติดตามการเปลียนแปลง การใช้ Git Repository เป็ นวิธีที
ยอดเยียมในการบรรลุเป้าหมายทังสองข้อ
หากในอนาคตเราจําเป็ นต้องเปลียนแปลง API ขันตอนแรกคือการแก้ไขที API Specification และการใช้ Git จะทําให้
กระบวนการนีง่ายขึน เพียงแค่สร้าง Pull Request (PR) ขึนมา ทุกฝ่ ายทีเกียวข้องสามารถร่วมกันพิจารณาและตรวจสอบการ
เปลียนแปลงได้ใน PR ดังทีแสดงในรูปที 3.25 คุณสามารถจัดการ API Specifications ได้ใน Repository กลาง (Common
Repository) หรือจะเก็บ API Specification ไว้ใน Repository ของโค้ดทีพัฒนา API นันโดยตรงก็ได้
ส่วนตัวแล้ว ฉันพบว่าแนวทางหลัง (เก็บ Specification ไว้ใน Repository ของ API) มีความสะดวกมากกว่า แต่การใช้
Repository กลางอาจช่วยให้มองเห็นภาพรวมของการพัฒนา API ทังหมดได้ดียิงขึน และช่วยบังคับใช้มาตรฐานเดียวกันทัวทัง
องค์กร
รูปที . บางองค์กรชอบใช้ Repository แบบรวมศูนย์ (Centralized Repository) ทีรวบรวม API Specifications ทังหมดไว้ดว้ ยกัน ซึงช่วย
ให้มองเห็นภาพรวมของ API ทังหมดได้ชดั เจนขึน และช่วยอํานวยความสะดวกในการบังคับใช้แนวทางปฏิบตั ิทีเป็ นมาตรฐานเดียวกัน
ในขณะทีบางองค์กรชอบเก็บ API Specification ไว้ใน Repository ของแอปพลิเคชันทีเกียวข้อง ซึงช่วยให้ง่ายต่อการทดสอบการพัฒนากับ
Specification นันโดยตรง
ก่อนทีเราจะเข้าสู่ขนตอนการพั
ั
ฒนา (Implementation) เราควรทดสอบการออกแบบ (Design) เพือระบุช่องโหว่และ
แก้ไขปั ญหาเหล่านัน คุณจะได้เรียนรูเ้ พิมเติมเกียวกับการทดสอบ API ประเภทนีในบทที 12 ดังที Ikenna Nwaiwu ผูเ้ ชียวชาญ
ด้าน APIOps ชีให้เห็นว่า นีเป็ นโอกาสทีดีในการเขียนการทดสอบฟั งก์ชนั การทํางาน (Functional Tests) และการทดสอบด้าน
ความปลอดภัย (Security Tests) รวมถึงกําหนดตัวชีวัดประสิทธิภาพทีสําคัญ (KPIs) สําหรับ API ขันตอนนีมีความสําคัญอย่าง
ยิงในการสร้างความเข้าใจทีตรงกันระหว่างผูม้ ีส่วนเกียวข้องทุกฝ่ าย
ในขันตอนนี API Specification ยังเป็ นเพียงสมมติฐาน (Hypothesis) ของสิงทีเราต้องการสร้าง เมือเราลงมือพัฒนา
API และทําการทดสอบ เราจะค้นพบข้อบกพร่องในดีไซน์เดิม และทําให้ Specification มีการเปลียนแปลงและพัฒนาขึนตาม
เวลา ดังนัน คําแนะนําของฉันคือให้คุณตังใจออกแบบให้ดีทีสุดเท่าทีจะทําได้ แต่ไม่จาํ เป็ นต้องใช้เวลากับมันมากเกินไป เพราะ
สุดท้ายแล้วมันจะต้องมีการเปลียนแปลงอยู่ดี
นอกจากนี อย่าลืมเวอร์ชนั API ของคุณ (Versioning) เพราะในบางจุด คุณอาจจําเป็ นต้องแนะนําการเปลียนแปลงทีไม่
สามารถเข้ากันได้กบั เวอร์ชนั ก่อนหน้า (Non-Backwards Compatible Changes) การใช้เวอร์ชนั จะช่วยให้การเปลียนผ่าน
ระหว่างเวอร์ชนั เป็ นไปอย่างราบรืน หากต้องการเรียนรูเ้ กียวกับกลยุทธ์การจัดการเวอร์ชนั ของ API (API Versioning
Strategies) สามารถศึกษาต่อได้ในหนังสือ Microservice APIs ของ Jose Haro Peralta ในภาคผนวก B: “Managing an API’s
lifecycle”
คําจํากัดความ
Mock Server คือเซิรฟ์ เวอร์ทจํี าลองพฤติกรรมของ API ของคุณตาม API Specification เครืองมือทีได้รบั ความนิยม
สําหรับการใช้งาน Mock Server ได้แก่ Prism (https://github.com/stoplightio/prism), WireMock
(https://github.com/wiremock/wiremock) และ Microcks (https://github.com/microcks/microcks) หากต้องการ
รายละเอียดเพิมเติมเกียวกับการทํางานของ Mock Server และวิธีการใช้งาน สามารถศึกษาได้ในบทที 7 ของหนังสือ
Microservice APIs โดย Jose Haro Peralta
เมือ API Specification พร้อมแล้ว ก็ถงึ เวลาลงมือพัฒนา (Build) หาก API จะถูกใช้งานโดยเบราว์เซอร์หรือแอปพลิเค
ชันบนมือถือ เราสามารถพัฒนาส่วน Backend และ Frontend ไปพร้อมกันได้ดว้ ยความช่วยเหลือจาก Mock Servers ดังที
แสดงในรูปที 3.26 นอกจากนี เรายังสามารถสร้าง Software Development Kits (SDKs) ซึงช่วยให้นกั พัฒนาทํางานกับ API ได้
ง่ายขึน [21]
รูปที . เมือเราได้สร้าง API Specification ขึนมาแล้ว เราสามารถพัฒนาส่วน API Client และ Server ไปพร้อมกันได้ ในระหว่างการพัฒนา
ส่วน Client เราสามารถจําลอง Backend ด้วย Mock Servers และตรวจสอบความถูกต้องของการพัฒนาส่วน Server โดยเปรียบเทียบกับ
Specification เพือให้มนใจว่
ั าการเชือมต่อทํางานได้อย่างถูกต้อง
อย่าลืมว่านีเป็ นโอกาสของเราในการตรวจสอบว่า API Design ตอบโจทย์ความต้องการและข้อจํากัดของเรา หาก
จําเป็ นต้องมีการเปลียนแปลง เราต้องการทราบให้เร็วทีสุด ดังนัน ควรลดรอบเวลาการรับข้อมูลย้อนกลับ (Feedback Loop)
โดยการปรับใช้งานการเปลียนแปลงเล็ก ๆ อย่างสมําเสมอ
ดังทีแสดงในรูปที 3.27 Continuous Integration Pipeline ของคุณมีบทบาทสําคัญในขันตอนนี โดยช่วยทดสอบการ
พัฒนาของคุณก่อนทีจะนําไปปรับใช้งานจริง
รูปที . Continuous Integration and Delivery (CI/CD) Pipeline มีบทบาทสําคัญในการรับรองว่ามีเพียงโค้ดทีเชือถือได้และปลอดภัย
เท่านันทีจะถูกนําไปปรับใช้งาน หากการทดสอบใด ๆ ของเราล้มเหลว เราจะย้อนกลับไปทีขันตอนการออกแบบ (Design Stage) เพือประเมิน
ช่องโหว่ของ API อีกครัง
คุณอาจต้องการดําเนินการทดสอบ QA และการทดสอบความปลอดภัยแบบแมนนวล (Manual QA and Security
Tests) ซึงในอุดมคติแล้ว การทดสอบเหล่านีเป็ นการตรวจสอบเชิงลึกทียากต่อการทําให้อตั โนมัติ (Automate) และมุง่ เน้นไปที
การแก้ไขช่องโหว่ทเครื
ี องมืออัตโนมัติอาจตรวจจับได้ยาก
ยกตัวอย่างเช่น หากเรามีเว็บไซต์อีคอมเมิรซ์ API ของเรามีความเสียงต่อการโจมตีแบบ Scalping หรือไม่? (เช่น การซือ
สินค้าทังหมดในสต็อกเพือนําไปขายต่อในราคาทีสูงกว่า) ผูโ้ จมตีสามารถดึงข้อมูลสินค้าทังหมดของเรา (Scraping) ได้หรือไม่?
หรือระบบของเรามีการป้องกันการโจมตีแบบ Brute Force Authentication อย่างเพียงพอหรือไม่?
เช่นเคย หาก API ของเรายังคงมีชอ่ งโหว่ดา้ นการออกแบบ เราจําเป็ นต้องทราบปั ญหาให้เร็วทีสุดเท่าทีจะเป็ นไปได้
ดังนันควรดําเนินการทดสอบเหล่านีเป็ นประจํา และทําให้อตั โนมัติเมือสามารถทําได้
สุดท้าย ดังทีแสดงในรูปที 3.28 เมือ API พร้อมสําหรับการใช้งาน เราจึงนํา API ไปเผยแพร่ในระบบการผลิต
(Production) และเพิม API นันเข้าไปใน Catalog ของเรา
รูปที . หากการประเมินช่องโหว่แบบแมนนวลรอบสุดท้ายผ่านไปด้วยดี เราจะเข้าสูข่ ันตอนสุดท้ายของวงจรการพัฒนา API (API
Development Life Cycle) นันคือการเผยแพร่ API ไปยัง API Catalog และนํา API ออกใช้งานจริง (Release)
นีคือบทสรุปของภาพรวมเกียวกับหลักการด้านความปลอดภัยของ API (API Security) คุณได้เรียนรูว้ ่า API Security by
Design คืออะไร และวิธีทีช่วยให้เราปรับกลยุทธ์ดา้ นความปลอดภัยไปไว้ในช่วงเริมต้น (Shift Security to the Left) คุณได้
เรียนรูว้ ิธีนาํ โมเดล Zero Trust Security มาใช้กบั API รวมถึงตําแหน่งและวิธีการตรวจสอบความถูกต้องในกระแสข้อมูล (Data
Flows) และการใช้เอกสารเพือช่วยในการประเมินช่องโหว่ (Vulnerability Assessment)
สุดท้าย คุณได้เรียนรูว้ ิธีผสานทุกสิงเข้ากับวงจรการพัฒนาซอฟต์แวร์ (Software Development Life Cycle) โดยทําการ
ประเมินช่องโหว่ในทุกขันตอนของการพัฒนา ในส่วนทีเหลือของหนังสือ เราจะลงลึกในรายละเอียดเกียวกับการประเมินช่อง
โหว่ ประเภทของช่องโหว่ใน API และวิธีปกป้องแอปพลิเคชันของเราจากช่องโหว่เหล่านัน
3.7 สรุป
 Shift-Left Security เป็ นแนวทางทีกระตุน้ ให้เราจัดการกับช่องโหว่ในทุกขันตอนของวงจรการพัฒนาซอฟต์แวร์
(SDLC)
 การแก้ไขปั ญหาด้านความปลอดภัยตังแต่เนิน ๆ ช่วยให้เราสร้างความปลอดภัยลงใน API ได้ตงแต่
ั ตน้ หาก
จัดการความปลอดภัยในช่วงท้าย จะนําไปสู่โซลูชนั ทีไม่มีประสิทธิภาพและแอปพลิเคชันทีมีความเสียงมากขึน
 Security by Design ช่วยให้การเลือนกระบวนการความปลอดภัยไปไว้ในช่วงเริมต้น (Shift Left on Security)
เป็ นไปได้ โดยการจัดการกับช่องโหว่ตงแต่
ั ขนตอนการออกแบบซอฟต์
ั
แวร์
 เมือเรานํา Security by Design มาใช้กบั API จะช่วยลดโอกาสในการพบช่องโหว่รา้ ยแรงในช่วงท้ายของ
SDLC ทําให้เราสามารถเผยแพร่ได้เร็วขึนและมันใจมากขึน
 Zero Trust Security สนับสนุนให้เรากําจัดความไว้วางใจออกจากระบบ และตรวจสอบทราฟฟิ กทังหมดไม่ว่า
จะมาจากทีใด
 Zero Trust APIs จะตรวจสอบข้อมูลในทุกกระแสข้อมูล (Data Flows) รวมถึง API จากบุคคลทีสาม ฐานข้อมูล
ของเรา บริการภายใน การร้องขอข้อมูล (Request) และการตอบกลับข้อมูล (Response)
 ไม่มีสิงทีเรียกว่า Internal API ความปลอดภัยแบบ Zero Trust หมายถึงการใช้มาตรการรักษาความปลอดภัย
ในระดับเดียวกันกับ API ทังหมด
 การขาดเอกสาร API ทีดีหรือไม่มเี อกสารเลยทําให้เราไม่ทราบว่าเรามี API กีตัวหรือ API แต่ละตัวทํางาน
อย่างไร
 API Sprawling คือการเพิมจํานวน API ทีซําซ้อนและไม่มเี อกสาร ประกอบไปด้วย:
o Shadow APIs: API ทีไม่ได้รบั การบันทึกและถูกนําไปใช้งานแบบ "ใต้เรดาร์" โดยไม่มกี ารตรวจสอบ
มากนัก
o Zombie APIs: เวอร์ชนั API ทีล้าสมัยซึงเราลืมปิ ดการใช้งาน
o Ghost APIs: API ทีถูกเปิ ดเผยโดยไลบรารีหรือระบบของบุคคลทีสาม
 API Catalogs ช่วยเราจัดการกับ API Sprawl โดยช่วยให้คน้ หา API ได้ง่ายขึน
 เพือเลือนกระบวนการความปลอดภัยของ API ไปไว้ช่วงเริมต้น (Shift Left on API Security) ให้เริมจากการ
ประเมินช่องโหว่ในขันตอนการออกแบบ จัดการกับความปลอดภัยในทุกขันตอนของ SDLC และแก้ไขช่องโหว่
ทันทีทีการทดสอบล้มเหลวก่อนดําเนินการต่อ
[1] Andrew Binder และ Dan Barahona, “API Security 101: การสร้างและการจัดการโปรแกรม API ทีปลอดภัย,” การ
สัมมนาออนไลน์จดั โดย Redspin เมือวันที 11 กุมภาพันธ์ 2021 (การบันทึกวิดีโอสามารถดูได้บน YouTube:
https://youtu.be/cMN6yr4nBUo)
[2] Anand Prakash, “ฉันเกือบแฮ็กบัญชี Uber ทังหมดได้ - แต่เลือกทีจะรายงานแทน,” HackerNoon, 13 กันยายน
2019 (https://hackernoon.com/how-i-could-have-hacked-all-uber-accounts-rtzl3z72)
[3] รายงานสถานะ DevOps ปี 2016, หน้า 28 (https://dora.dev/publications/pdf/state-of-devops-2016.pdf)
[4] W. Edwards Deming, Out of the Crisis, The MIT Press (Cambridge, MA), หน้า 22
[5] S&P Global, รายงาน API Security ปี 2022 (https://nonamesecurity.com/wpcontent/uploads/2023/06/Whitepaper-451-Research-Trends-Report.pdf), หน้า 11-12
[6] John Kindervag, “สร้างความปลอดภัยให้กบั DNA ของเครือข่ายของคุณ: สถาปั ตยกรรม Zero Trust Network,”
Forrester Research (5 พฤศจิกายน 2010) และ “ไม่มีศูนย์กลางทีเปราะบางอีกต่อไป: โมเดล Zero Trust ของการรักษาความ
ปลอดภัยข้อมูล,” Forrester Research (23 มีนาคม 2016)
[7] Scott Rose, Stu Mitchell และ Sean Connelly, “Zero Trust Architecture,” NIST Special Publication 800-207,
สิงหาคม 2020 (https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-207.pdf)
[8] Eric Newcomer, “API Security: การอนุญาตเป็ นภัยคุกคามทีใหญ่ทีสุดหรือไม่?” The New Stack (12 มิถนุ ายน
2023, https://thenewstack.io/api-security-is-authorization-the-biggest-threat/)
[9] Salt Security, รายงานสถานะ API Security ไตรมาสที 1 ปี 2023, หน้า 4
[10] Aner Morag, “Coinbase แก้ไขช่องโหว่ API ทีทําให้คณ
ุ สามารถขาย Bitcoin โดยทีคุณไม่ได้เป็ นเจ้าของ,”
Security Boulevard, 20 กุมภาพันธ์ 2022 (https://securityboulevard.com/2022/02/coinbase-fixes-vulnerable-api-thatlet-you-sell-bitcoin-you-didnt-own/)
[11] สําหรับภาพรวมของประเภทการตอบกลับใน API ทีพบได้ทวไป
ั ดูได้ในส่วนที 4.6 ของหนังสือของฉัน Microservice
APIs (Manning, 2022)
[12] Salt Security, รายงานสถานะ API Security ไตรมาสที 1 ปี 2023, หน้า 4 (https://content.salt.security/rs/352UXR-417/images/SaltSecurity-Report-State_of_API_Security.pdf)
[13] Andrew Greene, “Optus ปฏิเสธข้อกล่าวหาเรือง ‘ความผิดพลาดของมนุษย์’ ว่าเป็ นปัจจัยทีอาจทําให้เกิดการ
โจมตีทมีี ผลกระทบต่อชาวออสเตรเลียหลายล้านคน,” ABC News, 23 กันยายน 2022 (https://www.abc.net.au/news/202209-23/optus-rejects-claim-hack-likely-result-of-human-error/101468846)
[14] สําหรับภาพรวมทียอดเยียมเกียวกับปั ญหานี อ่านบทความของ Nick Rago “คุณกําลังถูกหลอกหลอนด้วย
Zombie, Shadow และ Ghost APIs อยู่หรือไม่?” Salt Security Blog, 28 ตุลาคม 2022 (https://salt.security/blog/are-youhaunted-by-zombie-shadow-and-ghost-apis)
[15] Nick Frichette, “ขโมยข้อมูลรับรอง EC2 Metadata ผ่าน SSRF,” Hacking The Cloud, 1 สิงหาคม 2020
(https://hackingthe.cloud/aws/exploitation/ec2-metadata-ssrf/)
[16] Salt Security, รายงานสถานะ API Security ไตรมาสที 1 ปี 2023 (https://content.salt.security/rs/352-UXR417/images/SaltSecurity-Report-State_of_API_Security.pdf). 36% ระบุวา่ Zombie APIs เป็ นจุดเจ็บปวดด้านความ
ปลอดภัยทีสําคัญ และ 34% ระบุถึง Shadow APIs เช่นกัน
[17] Bruno Pedro, “ห้าปัจจัยสําคัญของเอกสาร API ทีดี,” The API Changelog, 8 ธันวาคม 2023
(https://apichangelog.substack.com/p/five-elements-of-good-api-documentation)
[18] Joyce Lin, “ตัวชีวัด API ทีสําคัญทีสุดคือเวลาในการเรียกครังแรก,” TechCrunch, 12 กรกฎาคม 2021
(https://techcrunch.com/2021/07/12/the-most-important-api-metric-is-time-to-first-call)
[19] Kevin Smith, “api-catalog: URI ทีรูจ้ กั กันดีเพือช่วยในการค้นหา API,” IETF Internet-Draft, 4 พฤษภาคม 2023
(https://www.ietf.org/archive/id/draft-smith-api-catalog-00.html)
[20] หากต้องการเรียนรูเ้ กียวกับความเป็ นไปได้ในด้านนี ดูการบรรยายของ Dan Gordon เรือง “API Catalog: The First
Step in Protecting your APIs” ทีงาน APIDays New York, 27-28 กรกฎาคม 2022 (การบันทึกวิดีโอสามารถดูได้บน
YouTube: https://youtu.be/ZMBN5muGtD4)
[21] หากต้องการเรียนรูเ้ กียวกับการสร้าง SDK อัตโนมัติ ดูการบรรยายทียอดเยียมของ Sidney Maestre เรือง “You
Don’t Need SDKs, Wait Maybe You Do?” ที Platform Summit 2023, 16-18 ตุลาคม, สต็อกโฮล์ม (การบันทึกวิดีโอสามารถ
ดูได้บน YouTube: https://youtu.be/ezEQ5ewLP4A)