เหตุใด Zombie API และ Shadow API จึงน่ากลัว

คำถาม: Zombie API และ Shadow API แตกต่างกันอย่างไร

Nick Rago, CTO ภาคสนาม, Salt Security: Zombie API และ Shadow API เป็นผลพลอยได้จากความท้าทายที่ใหญ่กว่าที่องค์กรต่างๆ กำลังดิ้นรนเพื่อแก้ไขในปัจจุบัน: API แผ่ขยาย

ในขณะที่บริษัทต่างๆ พยายามที่จะเพิ่มมูลค่าทางธุรกิจที่เกี่ยวข้องกับ API ให้สูงสุด API ก็ได้แพร่หลายมากขึ้น การเปลี่ยนแปลงทางดิจิทัล การปรับปรุงแอปให้ทันสมัยเป็นไมโครเซอร์วิส สถาปัตยกรรมแอปที่เน้น API เป็นหลัก และความก้าวหน้าในวิธีการปรับใช้ซอฟต์แวร์อย่างต่อเนื่องอย่างรวดเร็ว ได้กระตุ้นให้เกิดการเติบโตอย่างรวดเร็วของจำนวน API ที่สร้างและใช้งานโดยองค์กรต่างๆ ผลจากการผลิต API ที่รวดเร็วนี้ ทำให้ API แพร่หลายได้แสดงให้เห็นในหลายทีมที่ใช้ประโยชน์จากแพลตฟอร์มเทคโนโลยีหลายแพลตฟอร์ม (ระบบเดิม, Kubernetes, VM ฯลฯ) ผ่านโครงสร้างพื้นฐานแบบกระจายหลายแห่ง (ศูนย์ข้อมูลในองค์กร ระบบคลาวด์สาธารณะหลายแห่ง ฯลฯ) . เอนทิตีที่ไม่พึงประสงค์ เช่น zombie API และ shadow API เกิดขึ้นเมื่อองค์กรไม่มีกลยุทธ์ที่เหมาะสมในการจัดการ API sprawl

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

เนื่องจากโดยหลักแล้วพวกมันจะถูกลืมไปแล้ว Zombie API จึงไม่ได้รับการแพตช์ การบำรุงรักษา หรือการอัปเดตอย่างต่อเนื่องในความสามารถด้านการทำงานหรือความปลอดภัยใดๆ ดังนั้น zombie API จึงกลายเป็นความเสี่ยงด้านความปลอดภัย อันที่จริง Salt Security ก็มี”สถานะความปลอดภัยของ APIรายงานระบุว่า zombie APIs เป็นข้อกังวลด้านความปลอดภัย API อันดับ 1 ขององค์กรจากการสำรวจสี่ครั้งที่ผ่านมา

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

• API อาจไม่มีการรับรองความถูกต้องและประตูการเข้าถึงที่เหมาะสม
• API อาจเปิดเผยข้อมูลที่ละเอียดอ่อนอย่างไม่เหมาะสม
• API อาจไม่ปฏิบัติตามแนวทางปฏิบัติที่ดีที่สุดจากจุดยืนด้านความปลอดภัย ทำให้เกิดความเสี่ยงต่อหลายๆ ด้าน OWASP API ความปลอดภัย 10 อันดับแรก ภัยคุกคามจากการโจมตี

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

นอกเหนือจากความเสี่ยงแล้ว API ที่เพิ่มขึ้นและการเกิดขึ้นของ API แบบซอมบี้และเงายังขยายไปไกลกว่า API ที่พัฒนาขึ้นภายในองค์กรอีกด้วย API ของบริษัทภายนอกที่ใช้งานและใช้งานเป็นส่วนหนึ่งของแอปพลิเคชันแบบแพ็กเกจ บริการที่ใช้ SaaS และส่วนประกอบโครงสร้างพื้นฐานยังอาจทำให้เกิดปัญหาได้หากไม่ได้รับการจัดทำรายการ ควบคุม และบำรุงรักษาอย่างเหมาะสม

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