เทคโนโลยียังคงก้าวหน้าในอัตราที่ไม่เคยมีมาก่อน การพัฒนาและการใช้ Application Programming Interfaces (API) เป็นตัวอย่างที่โดดเด่นเป็นพิเศษ
รายงานสถานะความปลอดภัยของ API ของ Salt Labs พบว่าทราฟฟิก API โดยรวมเพิ่มขึ้น 168 เปอร์เซ็นต์ในช่วง 12 เดือน โดยทราฟฟิกการโจมตี API เพิ่มขึ้น 117 เปอร์เซ็นต์ในช่วงเวลาเดียวกัน อาจเป็นเรื่องที่เข้าใจได้ว่า CISO จำนวนมากกำลังพยายามตามให้ทัน
ตามรายงานฉบับเดียวกัน 94 เปอร์เซ็นต์ขององค์กรประสบปัญหาด้านความปลอดภัย API ในช่วง 12 เดือน รวมอยู่ในการจัดกลุ่มนี้เป็นชื่อครัวเรือน เช่น Experian, Peloton และ Starbucks แม้แต่เลโก้ก็ได้ทำการแก้ไขช่องโหว่ API ที่อาจก่อให้เกิดหายนะเมื่อปลายปีที่แล้ว บริษัทขนาดใหญ่ที่มีงบประมาณด้านความปลอดภัยจำนวนมาก มักจะประสบกับเหตุการณ์ด้านความปลอดภัยของ API อยู่เสมอ เห็นได้ชัดว่า เทคนิคการรักษาความปลอดภัยแอปพลิเคชันแบบเดิมๆ ไม่ใช่เรื่องใหม่เมื่อพูดถึงการรักษาความปลอดภัย API
เมื่อคำนึงถึงสิ่งนี้ เราจึงได้พูดคุยกับ Yaniv Balmas รองประธานฝ่ายวิจัยของ Salt Security เพื่อตอบคำถามที่พบบ่อยที่สุดของความปลอดภัยของ API
BN: สถาปัตยกรรมแบบ Zero trust สามารถปกป้อง API ได้หรือไม่
YB: น่าเสียดายที่ความเสี่ยงของ API หลายอย่างไม่สามารถลดลงได้ด้วยความไว้วางใจเป็นศูนย์ เป้าหมายของ Zero Trust คือการจำกัดการเข้าถึง ในขณะที่ API ต้องการการเข้าถึงฟังก์ชัน API ส่วนใหญ่เป็นแบบสาธารณะหรือแบบเปิด ซึ่งออกแบบมาเพื่อใช้งานโดยอินเทอร์เน็ตโดยรวมและฐานลูกค้าขนาดใหญ่ นำเสนอความท้าทายที่ไม่เหมือนใครในการทำให้ไม่ไว้วางใจ
ยิ่งไปกว่านั้น การโจมตี API มักจะเกิดขึ้นในช่องทางที่เชื่อถือได้และเซสชันการตรวจสอบสิทธิ์. ผู้โจมตีทราบว่าสามารถรับคีย์หรือข้อมูลประจำตัวของผู้ใช้ที่ได้รับอนุญาตได้หรือไม่ พวกเขาสามารถเข้าถึงข้อมูลที่มีค่าได้ แฮ็กเกอร์จะไม่ถูกขัดขวางโดยสถาปัตยกรรมแบบ Zero Trust โดยการใช้การสำรองหรือไฮแจ็กเซสชันที่ตรวจสอบความถูกต้องด้วยคุกกี้เซสชันที่ใช้งานอยู่ โทเค็นการตรวจสอบสิทธิ์ ความท้าทายในการตรวจสอบสิทธิ์แบบสองปัจจัย คีย์ API และเนื้อหาการตรวจสอบสิทธิ์อื่นๆ โปรดทราบว่าตามรายงานสถานะของความปลอดภัยของ API พบว่ามีช่องโหว่ถึง 94 เปอร์เซ็นต์เกิดขึ้นกับ API ที่ผ่านการตรวจสอบความถูกต้อง
เมื่อพูดถึงเรื่องความเชื่อถือเป็นศูนย์ องค์กรจะต้องทำมากกว่าหลักการของการรับรองความถูกต้องและการอนุญาต พวกเขาต้องการการป้องกันรันไทม์ API เพื่อตรวจสอบการเข้าถึงและพฤติกรรมของผู้ใช้ที่ได้รับอนุญาตกับทรัพยากร API อย่างต่อเนื่อง ตรวจจับความผิดปกติ และระบุผู้กระทำผิด
BN: ข้อเสนอด้านความปลอดภัยบนคลาวด์สามารถปกป้อง API ได้หรือไม่
YB: แม้ว่าผู้ให้บริการรักษาความปลอดภัยบนคลาวด์บางรายจะมีเครื่องมือต่างๆ เช่น การจัดการ API หรือเกตเวย์ API แต่ผลิตภัณฑ์เฉพาะจุดเช่นนี้ยังไม่เพียงพอสำหรับการปกป้ององค์กรจากการโจมตี API เครื่องมือเหล่านี้มีความสามารถด้านความปลอดภัยของ API ที่จำกัดทั้งที่แอปพลิเคชันและเลเยอร์ API ทำให้ API ไม่ได้รับการป้องกัน การโจมตี API เป็นการเจาะระบบแบบ Zero-day อย่างมีประสิทธิภาพ หมายความว่าเครื่องมือรักษาความปลอดภัยที่ออกแบบมาเพื่อค้นหาพฤติกรรมที่’ไม่ดี’เช่น ลายเซ็นหรือ IP ที่ถูกขึ้นบัญชีดำ เป็นต้น จะไม่สามารถปกป้อง API ได้อย่างถูกต้อง นอกจากนี้ยังเป็นที่น่าสังเกตว่าเนื่องจาก API เป็นตรรกะของแอปพลิเคชัน ลูกค้าระบบคลาวด์จึงมีหน้าที่รับผิดชอบสูงสุดในการปกป้องพวกเขาภายใต้รูปแบบความรับผิดชอบร่วมกันเพื่อความปลอดภัย
BN: เหตุใด IAM, WAF หรือ API จึงทำไม่ได้ เกตเวย์ปกป้อง API หรือไม่
YB: แม้ว่าเกตเวย์ IAM, WAF และ API ล้วนเป็นเครื่องมือที่จำเป็นและสำคัญในทุกกลุ่มความปลอดภัยขององค์กร แต่ก็ขาดการปกป้อง API ส่วนใหญ่เป็นเพราะไม่ ให้การมองเห็นหรือการควบคุมความปลอดภัยที่จำเป็น
ผู้โจมตีจะข้ามการควบคุมการเข้าถึงอย่างสม่ำเสมอ ตลอดจนการเก็บเกี่ยวคีย์และโทเค็น แฮ็กเกอร์ร่วมสมัยเป็นผู้เชี่ยวชาญในการหลีกเลี่ยงการควบคุมการเข้าถึง การแอบดูเซสชันผู้ใช้ที่ผ่านการตรวจสอบสิทธิ์ หรือรวบรวมข้อมูลการตรวจสอบสิทธิ์จากทราฟฟิก ที่เก็บข้อมูลอุปกรณ์ หรือรหัสแอปพลิเคชัน เทคนิคการโจมตีเหล่านี้ไม่สามารถตรวจจับได้ด้วยโซลูชัน IAM, API หรือ WAF
เครื่องมือเหล่านี้ยังตรวจไม่พบปัญหาเฉพาะของ API เช่น การใช้ตรรกะทางธุรกิจในทางที่ผิดและการใช้ประโยชน์จากการให้สิทธิ์ เป็นต้น เนื่องจากเครื่องมือเหล่านี้ใช้ลายเซ็นและกฎในการตรวจจับการโจมตี ที่แย่กว่านั้น ส่วนประกอบการจัดการ API ที่มีอยู่ในตัวอาจถูกใช้ประโยชน์ได้เช่นกัน
ยิ่งไปกว่านั้น IAM, WAF และเกตเวย์ API ล้วนพึ่งพาการใช้พร็อกซี เนื่องจากโมเดลพร็อกซีทำให้การสื่อสาร API ช้าลง โดยทั่วไปแล้วองค์กรต่างๆ จะล้มเหลวในการไกล่เกลี่ยทุก API ที่ใช้กับเกตเวย์หรือ WAF โดยเฉพาะอย่างยิ่งสำหรับ API ภายในหรือภายใน ซึ่งส่งผลให้มองไม่เห็นวิธีใช้งาน API เหล่านั้น
BN: API สามารถรักษาความปลอดภัยด้วยการป้องกันปริมาณงานได้หรือไม่
YB: ความปลอดภัยของปริมาณงาน ความคุ้มครองให้ประโยชน์มากมาย เหนือสิ่งอื่นใด สิ่งเหล่านี้ช่วยในการรักษาความปลอดภัยของโครงสร้างพื้นฐานเพื่อให้แน่ใจว่าคุณไม่ได้เรียกใช้ปริมาณงานในเวอร์ชันซอฟต์แวร์ที่มีช่องโหว่ และยังมีประโยชน์สำหรับการบล็อกการเข้าถึงปริมาณงานสำหรับผู้ใช้ภายนอก อย่างไรก็ตาม พวกเขาขาดการให้ API หรือบริบทระดับแอปพลิเคชัน ดังนั้นจึงไม่สามารถรักษาความปลอดภัยของ API ได้
BN: shift-left มีประสิทธิภาพเพียงใดในการรักษาความปลอดภัย API
YB: แม้ว่าการใช้การรักษาความปลอดภัยในขั้นตอนการพัฒนาจะเป็นแนวทางปฏิบัติที่คุ้มค่า การสนับสนุน shift-left ไม่ได้หมายความว่าทุก API จะปลอดภัยก่อนการผลิตจริง เครื่องมือทดสอบของนักพัฒนาไม่สามารถระบุช่องโหว่ทั้งหมดได้ ไม่สามารถระบุปัญหาด้านความปลอดภัยของ API ทั่วไปจำนวนมากโดยเป็นส่วนหนึ่งของการออกแบบ การพัฒนา และสร้างการสแกนอัตโนมัติด้วยเครื่องมือวิเคราะห์และทดสอบความปลอดภัยทั่วไป–ข้อบกพร่องของตรรกะทางธุรกิจไม่สามารถตรวจพบได้เว้นแต่ว่า API นั้นจะถูกนำไปใช้
เครดิตรูปภาพ: Panchenko Vladimir/ชัตเตอร์สต็อก