ความปลอดภัยของ API แตกต่างจากความปลอดภัยของแอปพลิเคชันทั่วไปอย่างไร

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

ความปลอดภัยของแอปพลิเคชันคืออะไร?

การรักษาความปลอดภัยของแอปพลิเคชัน (AppSec) ใช้การอนุญาต การเข้ารหัส และหลักปฏิบัติในการเขียนโค้ดที่ปลอดภัยเพื่อปกป้องข้อมูลและระบบจากการโจมตีทางไซเบอร์ องค์กรที่ใช้ AppSec ช่วยลดความเสี่ยงของการละเมิดข้อมูล ปกป้องข้อมูลที่ละเอียดอ่อน และรับรองว่าแอปพลิเคชันของตนเป็นไปตามมาตรฐานอุตสาหกรรม

ISACA กำหนดองค์ประกอบที่สำคัญห้าประการของโปรแกรม AppSec ดังนี้:

1. ความปลอดภัยโดยการออกแบบ
2. การทดสอบรหัสที่ปลอดภัย
3. รายการวัสดุซอฟต์แวร์
4. การฝึกอบรมและการตระหนักรู้ด้านความปลอดภัย
5. เกตเวย์ความปลอดภัย WAF และ API และการพัฒนากฎ

ความปลอดภัยของ API คืออะไร?

API หรืออินเทอร์เฟซการเขียนโปรแกรมแอปพลิเคชัน การรักษาความปลอดภัยปกป้อง API จากการโจมตีทางไซเบอร์ การใช้ API มีการขยายตัวอย่างรวดเร็วในช่วงไม่กี่ปีที่ผ่านมา ทำให้องค์กรมีโอกาสในการสร้างสรรค์นวัตกรรมโดยเปิดใช้งานการถ่ายโอนข้อมูลระหว่างแอปพลิเคชัน น่าเสียดายที่การใช้ API เพิ่มขึ้น การโจมตีจึงเกิดขึ้นกับพวกเขาเช่นกัน การวิจัยจาก Salt Security เปิดเผยว่าการโจมตี API เพิ่มขึ้น 400% ระหว่างเดือนมิถุนายนถึงธันวาคม 2022

แอปพลิเคชันเทียบกับภัยคุกคามความปลอดภัยของ API

การทำความเข้าใจความแตกต่างระหว่างความปลอดภัยของ AppSec และ API จำเป็นต้องเข้าใจภัยคุกคามอันดับต้นๆ ของแต่ละสาขาวิชา โชคดีที่ OWASP ซึ่งเป็นองค์กรไม่แสวงผลกำไรที่ต้องการปรับปรุงความปลอดภัยของซอฟต์แวร์ ได้จัดทำรายการภัยคุกคามที่สำคัญที่สุดต่อความปลอดภัยของแอปพลิเคชันและความปลอดภัยของ API ที่ครอบคลุม รายการนี้รู้จักกันในชื่อ OWASP Top Ten โดยรวบรวมข้อมูลจากชุมชนผู้เชี่ยวชาญด้านความปลอดภัยทั่วโลกของ OWASP เพื่อระบุภัยคุกคามที่สำคัญที่สุดต่อแอปพลิเคชันและ API

สิ่งที่น่าสนใจคือ แม้ว่า OWASP จะเผยแพร่รายการความเสี่ยงด้านความปลอดภัยของแอปพลิเคชันเว็บสิบอันดับแรกในปี 2546 แต่ก็เพิ่งเปิดตัวรายการความเสี่ยงด้านความปลอดภัยของ API สิบอันดับแรกในช่วงปลายปี 2562 ความคลาดเคลื่อนนี้แสดงถึงความแตกต่างที่สำคัญอีกประการหนึ่งระหว่างแอปพลิเคชันและความปลอดภัยของ API กล่าวคือ ความปลอดภัยของแอปพลิเคชันเป็นที่ยอมรับกันดี มีการวิจัยอย่างกว้างขวางและผ่านขั้นตอนวิวัฒนาการมากมาย แต่การรักษาความปลอดภัยของ API ไม่ได้เป็นเช่นนั้น

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

OWASP ความเสี่ยงด้านความปลอดภัยของแอปพลิเคชันสิบอันดับแรก (2021)

1. การควบคุมการเข้าถึงที่ใช้งานไม่ได้ – เมื่อผู้ใช้ที่ไม่ได้รับอนุญาตสามารถเข้าถึงข้อมูลหรือระบบที่ถูกจำกัดได้
2. ความล้มเหลวในการเข้ารหัส – เมื่อบุคคลที่สามเปิดเผยข้อมูลที่ละเอียดอ่อนโดยไม่มีเจตนาเฉพาะอันเนื่องมาจากการขาดหรือมีข้อบกพร่องในการเข้ารหัส
3. การฉีด – เมื่อผู้โจมตีพยายามส่งข้อมูลไปยังแอปพลิเคชันในลักษณะที่จะเปลี่ยนความหมายของคำสั่งที่ส่งไปยังล่าม
4. ฉัน ไม่แน่ใจในการออกแบบ - ความเสี่ยงที่เกี่ยวข้องกับข้อบกพร่องทางสถาปัตยกรรมและการออกแบบ
5. การกำหนดค่าความปลอดภัยไม่ถูกต้อง – เมื่อทีมรักษาความปลอดภัยกำหนดค่าไม่ถูกต้องหรือปล่อยให้การควบคุมความปลอดภัยไม่ปลอดภัย
6. ส่วนประกอบที่มีช่องโหว่และล้าสมัย – เมื่อองค์กรปล่อยให้ส่วนประกอบต่างๆ ไม่ได้รับการอัปเดต
7. ความล้มเหลวในการระบุตัวตนและการรับรองความถูกต้อง (nee Broken Authentication) – เมื่อแอปพลิเคชันเสี่ยงต่อการถูกโจมตีการรับรองความถูกต้อง
8. ความล้มเหลวด้านความสมบูรณ์ของซอฟต์แวร์และข้อมูล – เมื่อโค้ดและโครงสร้างพื้นฐานไม่สามารถป้องกันการละเมิดความสมบูรณ์ได้
9. ความล้มเหลวในการบันทึกและการตรวจสอบความปลอดภัย (nee การบันทึกและการตรวจสอบไม่เพียงพอ) – เมื่อองค์กรล้มเหลวในการตรวจจับการละเมิดข้อมูลเนื่องจากขั้นตอนการบันทึกและการตรวจสอบไม่เพียงพอ
10. การปลอมแปลงคำขอฝั่งเซิร์ฟเวอร์ – เมื่อผู้โจมตีหลอกแอปพลิเคชันให้ส่งคำขอที่สร้างขึ้นไปยังปลายทางที่ไม่คาดคิด แม้ว่าจะได้รับการป้องกันโดยไฟร์วอลล์ VPN หรือรายการควบคุมการเข้าถึงเครือข่าย (ACL) ประเภทอื่น

OWASP ความเสี่ยงด้านความปลอดภัย API สิบอันดับแรก (2023)

1. การอนุญาตระดับอ็อบเจ็กต์ที่ใช้งานไม่ได้ – เมื่ออ็อบเจ็กต์ API เช่น ฐานข้อมูลหรือไฟล์ ไม่มีการควบคุมการอนุญาตที่เหมาะสม ทำให้ผู้ใช้ที่ไม่ได้รับอนุญาตเข้าถึงได้
2. การตรวจสอบสิทธิ์ที่ใช้งานไม่ได้ – เมื่อซอฟต์แวร์และวิศวกรความปลอดภัยเข้าใจผิดเกี่ยวกับขอบเขตของการตรวจสอบสิทธิ์ API และวิธีการใช้งาน
3. การอนุญาตระดับคุณสมบัติของวัตถุที่ใช้งานไม่ได้ – การรวมกันของการเปิดเผยข้อมูลมากเกินไปและการกำหนดจำนวนมาก: เมื่อผู้โจมตีใช้ประโยชน์จากการล็อคหรือการอนุญาตที่ไม่เหมาะสมในระดับคุณสมบัติของวัตถุ
4. การใช้ทรัพยากรไม่จำกัด – การตอบสนองคำขอ API ต้องใช้แบนด์วิธเครือข่าย, CPU, หน่วยความจำ และพื้นที่จัดเก็บข้อมูล ผู้ให้บริการจัดทำทรัพยากรอื่นๆ เช่น อีเมล/SMS/โทรศัพท์ หรือการตรวจสอบความถูกต้องทางชีวภาพ ผ่านการผสานรวม API และชำระเงินตามคำขอ การโจมตีที่ประสบความสำเร็จอาจนำไปสู่การปฏิเสธการให้บริการหรือต้นทุนการดำเนินงานที่เพิ่มขึ้น
5. การอนุญาตระดับฟังก์ชันที่ใช้งานไม่ได้ เกี่ยวข้องกับผู้โจมตีที่ส่งการเรียก API ที่ถูกต้องไปยังตำแหน่งข้อมูล API ที่เปิดเผย
6. การเข้าถึงกระแสธุรกิจที่สำคัญอย่างไม่จำกัด – API ที่เสี่ยงต่อความเสี่ยงนี้จะเปิดเผยกระแสธุรกิจ เช่น การซื้อตั๋วหรือการโพสต์ความคิดเห็น โดยไม่ต้องชดเชยว่าฟังก์ชันการทำงานอาจเป็นอันตรายต่อธุรกิจได้อย่างไร หากใช้มากเกินไปในลักษณะอัตโนมัติ สิ่งนี้ไม่จำเป็นต้องมาจากข้อบกพร่องในการใช้งาน
7. การปลอมแปลงคำขอฝั่งเซิร์ฟเวอร์ – เมื่อ API ดึงข้อมูลทรัพยากรระยะไกลโดยไม่ตรวจสอบ URI ที่ผู้ใช้ระบุ ช่วยให้ผู้โจมตีสามารถบังคับแอปพลิเคชันให้ส่งคำขอที่สร้างขึ้นไปยังปลายทางที่ไม่คาดคิด แม้ว่าจะป้องกันโดยไฟร์วอลล์หรือ VPN ก็ตาม
8. การกำหนดค่าความปลอดภัยไม่ถูกต้อง – API และระบบที่รองรับมักจะมีการกำหนดค่าที่ซับซ้อนเพื่อให้สามารถปรับแต่งได้มากขึ้น วิศวกรซอฟต์แวร์และ DevOps อาจพลาดการกำหนดค่าเหล่านี้หรือไม่ปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดด้านความปลอดภัยเกี่ยวกับการกำหนดค่า ซึ่งเป็นการเปิดประตูสู่การโจมตีประเภทต่างๆ
9. การจัดการสินค้าคงคลังที่ไม่เหมาะสม – API เปิดเผยจุดสิ้นสุดมากกว่าเว็บแอปพลิเคชันแบบเดิม ทำให้เอกสารที่เหมาะสมและอัปเดตมีความสำคัญ สินค้าคงคลังที่เพียงพอของโฮสต์และเวอร์ชัน API ที่ใช้งานยังเป็นสิ่งจำเป็นในการบรรเทาปัญหา เช่น เวอร์ชัน API ที่เลิกใช้แล้วและจุดสิ้นสุดการแก้ไขข้อบกพร่องที่เปิดเผย
10. การใช้ API ที่ไม่ปลอดภัย – นักพัฒนามักจะเชื่อถือข้อมูลที่ได้รับจาก API ของบริษัทอื่นมากกว่าข้อมูลที่ผู้ใช้ป้อน และใช้มาตรฐานความปลอดภัยที่อ่อนแอกว่า ในการประนีประนอม API ผู้โจมตีจะติดตามบริการของบุคคลที่สามที่ผสานรวม แทนที่จะพยายามประนีประนอม API เป้าหมายโดยตรง

อย่างที่คุณเห็น แม้ว่าจะมีการทับซ้อนกันอยู่บ้าง แต่แอปพลิเคชันและ API มักตกอยู่ภายใต้ภัยคุกคามที่แตกต่างกันและมีลักษณะเฉพาะ และองค์กรต่างๆ จะต้องตอบสนองตามนั้น ข้อแตกต่างที่สำคัญระหว่างทั้งสองรายการคือ องค์กรสามารถลดความเสี่ยงที่สำคัญทั้งหมดที่เกี่ยวข้องกับความปลอดภัยของแอปพลิเคชันด้วยเครื่องมือและเทคนิคความปลอดภัยอเนกประสงค์แบบดั้งเดิม แต่ความปลอดภัยของ API นั้นแตกต่างกัน

การรักษาความปลอดภัยของ API เป็นปัญหาสมัยใหม่ที่ต้องใช้โซลูชันที่ทันสมัยไม่แพ้กัน องค์กรต่างๆ ไม่สามารถคาดหวังว่าเครื่องมือที่ใช้เพื่อปกป้องแอปพลิเคชันและทรัพย์สินอื่นๆ ของตนจะตอบสนองงานรักษาความปลอดภัยของ API ได้ การรักษาความปลอดภัย API ต้องใช้เครื่องมือรักษาความปลอดภัยเฉพาะ API วิธีการป้องกันแบบดั้งเดิม เช่น เกตเวย์ API และไฟร์วอลล์แอปพลิเคชันเว็บ (WAF) ยังไม่เพียงพอ