ภัยคุกคาม API 10 อันดับแรกของ OWASP

คุณกําลังดูเอกสารประกอบของ Apigee Edge
ไปที่เอกสารประกอบของ Apigee X info

เอกสารนี้อธิบายแนวทางต่างๆ ที่คุณใช้ใน Apigee เพื่อจัดการกับช่องโหว่ด้านความปลอดภัยที่ OWASP ระบุ ดูแนวทางเพิ่มเติมที่บันทึกไว้สำหรับ Apigee ได้ที่ตัวเลือกการบรรเทาความเสี่ยง 10 อันดับแรกของ OWASP ปี 2021 ใน Google Cloud

บทนำ

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

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

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

แอปพลิเคชันสำหรับผู้บริโภคควรถือว่าไม่เชื่อถือได้หรือ "สาธารณะ" เนื่องจากคุณไม่สามารถควบคุมแพลตฟอร์มที่แอปทำงานอยู่ สมมติว่าแอปสาธารณะใดๆ อาจถูกบุกรุกได้ จึงไม่น่าเชื่อถือที่จะบังคับใช้การควบคุมการเข้าถึง (API1, API5), กรองข้อมูลการตอบกลับ (API6) หรือจัดเก็บข้อมูลลับของลูกค้า (API2) อย่างปลอดภัย เช่น คีย์ API หรือโทเค็นการเข้าถึง คําแนะนําบางส่วนที่ได้จากการตรวจสอบ OWASP Top 10 ปี 2019 มีดังนี้

  • พิจารณาว่าแอปไคลเอ็นต์ประเภทใดจะใช้ API ของคุณ (SPA, อุปกรณ์เคลื่อนที่ หรือเบราว์เซอร์) และออกแบบรูปแบบการตรวจสอบสิทธิ์ ให้สิทธิ์ และความปลอดภัยที่เหมาะสม
  • ใช้ขั้นตอน OAuth หรือ OpenID Connect "ไคลเอ็นต์สาธารณะ" เสมอ (ขอแนะนําอย่างยิ่งให้ใช้ PKCE)
  • พิจารณาตรรกะทางธุรกิจของแอป กำหนดข้อมูลจำเพาะ OpenAPI ก่อน และออกแบบพร็อกซี API เพื่อกรองข้อมูลการตอบกลับทั้งหมดจากแบ็กเอนด์ภายใน Apigee โปรดอย่าใช้ตรรกะโค้ดแอปดาวน์สตรีมเพื่อดำเนินการนี้
  • กรองคำขอข้อมูลทั้งหมดที่มี PII ที่เฉพาะเจาะจงของผู้ใช้เพื่ออนุญาตเฉพาะข้อมูลจากแบ็กเอนด์ที่เป็นของผู้ใช้ที่ส่งคำขอ

API1:2019 การอนุญาตระดับออบเจ็กต์ใช้งานไม่ได้

คำอธิบายภัยคุกคาม

การตรวจสอบการให้สิทธิ์ที่ไม่เพียงพอของคำขอเข้าถึงออบเจ็กต์ทำให้ผู้โจมตีดําเนินการที่ไม่ได้รับอนุญาตได้โดยใช้โทเค็นการเข้าถึงซ้ำ ภัยคุกคามนี้เกิดจากการกำหนดค่าการตรวจสอบการให้สิทธิ์ที่ไม่ถูกต้อง Apigee มีนโยบาย VerifyApiKey, OAuth และ JSON Web Token (JWT) ซึ่งช่วยป้องกันช่องโหว่นี้ แต่คุณต้องกำหนดค่านโยบายเหล่านี้อย่างถูกต้องเพื่อป้องกันภัยคุกคามนี้

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

ในแง่การติดตั้งใช้งาน Apigee คุณต้องพิจารณา 2 ด้านหลักๆ ดังนี้

  • ความสมบูรณ์ของโทเค็นการเข้าถึง
  • การบังคับใช้การควบคุมการเข้าถึง

ความสมบูรณ์ของโทเค็นการเข้าถึง

การตรวจสอบว่าโทเค็นที่ไคลเอ็นต์ที่ส่งคำขอระบุไม่ได้ถูกดัดแปลงเป็นสิ่งสําคัญ โดยต้องใช้ขั้นตอน OAuth หรือ OpenID Connect ที่ถูกต้องพร้อมกับกลไกการตรวจสอบหรือการลงนามในข้อมูลเข้าสู่ระบบที่เหมาะสม Apigee รองรับขั้นตอน OAuth ที่ใช้กันโดยทั่วไปทั้งหมด

นโยบายการยืนยันโทเค็นการเข้าถึงของ Apigee มีดังนี้

การบังคับใช้การควบคุมการเข้าถึง

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

Apigee มีกลไกหลัก 2 อย่างสำหรับการยืนยันและการบังคับใช้นโยบายการให้สิทธิ์ ดังนี้

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

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

ใช้ตัวแปรโฟลว์ที่มีให้สำหรับนโยบาย OAuth หรือ JWT เพื่อประเมินคําขอเข้าถึงโดยใช้คำสั่งโฟลว์แบบมีเงื่อนไข

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

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

API2:2019 การตรวจสอบสิทธิ์ของผู้ใช้ใช้งานไม่ได้

คำอธิบายภัยคุกคาม

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

  • ตรวจสอบสิทธิ์ทั้ง User Agent (แอป) และผู้ใช้ที่ส่งคำขอเสมอ
  • ใช้รูปแบบการตรวจสอบสิทธิ์และการให้สิทธิ์ที่มอบสิทธิ์ และหลีกเลี่ยงการส่งรหัสผ่านโดยตรงภายในคำขอ API
  • ตรวจสอบลายเซ็นของข้อมูลเข้าสู่ระบบเสมอ และตรวจสอบว่าข้อมูลเข้าสู่ระบบทั้งหมดที่ใช้มีเวลาหมดอายุที่กําหนดไว้
  • ป้องกันการใช้กำลัง brute force โดยการกําหนดโควต้าและใช้ Apigee Sense เพื่อตรวจหาและตอบสนองต่อการใช้กำลัง brute force ที่เกิดจากบ็อต

ในกระบวนทัศน์จากภายนอกสู่ภายใน การออกแบบ API จะสร้างขึ้นโดยอิงตาม Use Case ของผู้บริโภคสำหรับข้อมูล ไม่ใช่โครงสร้างของข้อมูลที่มีอยู่เดิมในระบบแบ็กเอนด์ และความปลอดภัยเป็นองค์ประกอบสําคัญเมื่อออกแบบ API สําหรับผู้บริโภคภายนอก ระบบแบ็กเอนด์มักไม่ได้สร้างขึ้นโดยใช้การตรวจสอบสิทธิ์ที่รัดกุมเพียงพอสำหรับการเปิดเผยต่อเครือข่ายสาธารณะ ด้วยเหตุนี้ Apigee จึงผสานรวมกับโซลูชัน Identity and Access Management เพื่อมอบโซลูชันที่มีประสิทธิภาพในการปกป้องภัยคุกคามนี้

องค์ประกอบหลัก 2 อย่างที่ต้องพิจารณามีดังนี้ ซึ่งเราจะกล่าวถึงในหัวข้อต่อๆ ไป

  • การออกแบบความปลอดภัย: ใช้ประโยชน์จากฟีเจอร์ของ Apigee อย่างเต็มที่เพื่อติดตั้งใช้งานรูปแบบการตรวจสอบสิทธิ์
  • การกํากับดูแล: ตรวจสอบว่าการใช้รูปแบบการตรวจสอบสิทธิ์ที่ออกแบบไว้ถูกต้องและสม่ำเสมอในผลิตภัณฑ์ API ที่เผยแพร่ทั้งหมด
  • ความปลอดภัยด้านปฏิบัติการ: ความสามารถในการตรวจจับพฤติกรรมที่น่าสงสัยหรือผิดปกติ รวมถึงการพยายามหลีกเลี่ยงหรือใช้วิธีถอดรหัสแบบ Brute Force กับพร็อกซี API ที่ตรวจสอบสิทธิ์แล้ว

การออกแบบเพื่อความปลอดภัย

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

RFC ของ OpenID Connect และ OAuth มีขั้นตอนการตรวจสอบสิทธิ์และการให้สิทธิ์ที่มอบสิทธิ์จำนวนมาก รวมถึงผู้ที่เกี่ยวข้องในขั้นตอนเหล่านี้ หัวข้อนี้เป็นหัวข้อที่ซับซ้อน และไม่น่าแปลกใจเลยที่การตรวจสอบสิทธิ์ที่ไม่สมบูรณ์เป็นหนึ่งในภัยคุกคาม API ยอดนิยมของ OWASP การให้ข้อมูลเบื้องต้นที่ครอบคลุมเกี่ยวกับการใช้งานมาตรฐานการระบุตัวตนที่ถูกต้องนั้นอยู่นอกขอบเขตของเอกสารนี้ แต่ Apigee มีแหล่งข้อมูลเพิ่มเติมมากมายที่จะช่วยให้เข้าใจขั้นตอน OAuth ได้ดียิ่งขึ้น เช่น ebook นี้และเว็บแคสต์ รวมถึงตัวอย่างการใช้งาน

นโยบายการตรวจสอบสิทธิ์

นโยบายของ Apigee ที่ช่วยจัดการข้อกังวลเกี่ยวกับตัวตนและการตรวจสอบสิทธิ์ ได้แก่

การจัดการการรับส่งข้อมูล

ฟีเจอร์การจัดการการเข้าชมของ Apigee ต่อไปนี้จะช่วยป้องกันจากการโจมตีด้วยวิธี Brute Force

  • นโยบายการหยุดการเพิ่มขึ้นอย่างฉับพลัน สำหรับการตั้งค่าขีดจำกัดอัตราเฉลี่ยแบบต่อเนื่องโดยรวมในพร็อกซี API
  • นโยบายโควต้าสำหรับกำหนดขีดจำกัดอัตราที่ละเอียดให้กับพร็อกซี API โดยอิงตามโควต้าที่กำหนดโดยคีย์แอป นักพัฒนาแอป หรือโควต้าผลิตภัณฑ์ API
  • นโยบายการแคชสำหรับการแคชโทเค็นการเข้าถึงที่จัดเก็บไว้ตามเวลาที่หมดอายุที่กําหนด รวมถึงความสามารถในการinvalidate (เช่น ในกรณีที่มีการบุกรุกโทเค็นการเข้าถึงที่ถูกต้อง)

การกำกับดูแล

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

Apigee มีฟีเจอร์และเครื่องมือจํานวนมากเพื่อรักษาความสมบูรณ์ของการติดตั้งใช้งานและป้องกันข้อผิดพลาดในการกําหนดค่าที่ไม่ถูกต้อง

การควบคุมการเข้าถึงตามบทบาท (RBAC)

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

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

โฟลว์ที่แชร์

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

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

การรายงานความปลอดภัย

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

ฟีเจอร์ Advanced API Ops ใหม่ของ Apigee มีการรายงานความปลอดภัยขั้นสูง ซึ่งช่วยให้ทีมปฏิบัติการและทีมรักษาความปลอดภัยดูรายงานเกี่ยวกับพร็อกซี API ทั้งหมดได้อย่างง่ายดาย และมุ่งเน้นที่การปฏิบัติตามนโยบายด้านความปลอดภัย เช่น การใช้โฟลว์ที่แชร์ การรายงาน การบันทึก และการแจ้งเตือนเป็นองค์ประกอบหลักของความปลอดภัยของ API ซึ่งจะกล่าวถึงรายละเอียดเพิ่มเติมในส่วน API10: การบันทึกไม่เพียงพอ แต่จากมุมมองของการป้องกันความเสี่ยงที่เกิดจากการตรวจสอบสิทธิ์ที่ไม่สมบูรณ์ ข้อมูลเหล่านี้มีประโยชน์อย่างยิ่งในการตรวจสอบการปฏิบัติตามมาตรฐานการตรวจสอบสิทธิ์ที่กําหนดไว้ซึ่งติดตั้งใช้งานเป็นเวิร์กโฟลว์ที่แชร์

การรักษาความปลอดภัยในการดําเนินการ

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

Apigee Sense

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

Apigee Sense ช่วยให้คุณปกป้อง API จากรูปแบบคำขอต่อไปนี้ได้

  • ลักษณะการทํางานอัตโนมัติที่ผสานรวมกับพฤติกรรมของมนุษย์
  • การพยายามอย่างต่อเนื่องจาก IP เดียวกัน
  • อัตราข้อผิดพลาดที่ผิดปกติ
  • คำขอของไคลเอ็นต์ที่น่าสงสัย
  • การ Crawl ข้อมูล
  • การรวบรวมคีย์และการโจมตีด้วยกำลัง brute force การตรวจสอบสิทธิ์
  • ช่วงที่มีกิจกรรม
  • รูปแบบทางภูมิศาสตร์

การดำเนินการขั้นสูงของ API

แม้ว่า Sense จะออกแบบมาเพื่อตรวจหาและตอบสนองต่อภัยคุกคามประเภทบอตโดยเฉพาะ แต่ Advanced API Ops มีทั้งการตรวจหาความผิดปกติและการแจ้งเตือนขั้นสูง

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

การดำเนินการขั้นสูงของ API สร้างขึ้นจากกลไกการแจ้งเตือนการตรวจสอบ API ที่มีอยู่เพื่อเพิ่มประเภทการแจ้งเตือนขั้นสูงต่อไปนี้

  • การแจ้งเตือนการจราจรทั้งหมด ส่งการแจ้งเตือนเมื่อการเข้าชมเปลี่ยนแปลงตามเปอร์เซ็นต์ที่ระบุในช่วงระยะเวลาหนึ่ง เช่น คุณสามารถส่งการแจ้งเตือนเมื่อการเข้าชมเพิ่มขึ้น 5% ขึ้นไปเป็นเวลา 1 ชั่วโมง หรือลดลง 10% ขึ้นไปเป็นเวลา 1 สัปดาห์
  • การแจ้งเตือนความผิดปกติ Edge จะตรวจหาปัญหาการเข้าชมและประสิทธิภาพแทนที่คุณจะต้องกำหนดปัญหาล่วงหน้าด้วยตนเอง จากนั้นจึงส่งการแจ้งเตือนสำหรับความผิดปกติเหล่านี้ได้
  • การแจ้งเตือนการหมดอายุของ TLS ส่งการแจ้งเตือนเมื่อใบรับรอง TLS ใกล้หมดอายุ

API3:2019 การเปิดเผยข้อมูลมากเกินไป

คำอธิบายภัยคุกคาม

API ที่เผยแพร่อาจเปิดเผยข้อมูลมากกว่าที่จำเป็น โดยอาศัยแอปไคลเอ็นต์ในการกรองข้อมูลที่จำเป็น หากผู้โจมตีค้นหา API พื้นฐานโดยตรง ก็จะเข้าถึงข้อมูลที่ละเอียดอ่อนได้

หลักการทําการออกแบบ "จากภายนอกสู่ภายใน" ประการหนึ่งของ Apigee สําหรับการออกแบบ API คือการประหยัดข้อมูล ทำงานร่วมกับนักออกแบบ UX และนักพัฒนาซอฟต์แวร์เพื่อแสดงข้อมูลผ่าน API ที่จําเป็นภายใน UI ของแอปเท่านั้น ระบบแบ็กเอนด์ไม่ได้สร้างขึ้นเพื่อรูปแบบการใช้งานแบบสาธารณะ ดังนั้นงานแรกๆ ของการออกแบบที่มุ่งเน้น API เป็นหลักด้วย Apigee คือการลดข้อมูลที่เปิดเผยให้เหลือน้อยที่สุดที่จำเป็นเพื่อมอบผลิตภัณฑ์ API ที่ยอดเยี่ยมให้แก่ลูกค้าและนักพัฒนาซอฟต์แวร์

หลักการออกแบบอีกประการหนึ่งของ Apigee คือความสามารถในการนํากลับมาใช้ใหม่ นอกจากข้อกังวลด้านความปลอดภัยแล้ว การใช้แอปเพื่อกรองข้อมูลที่ได้จาก API ยังส่งผลให้ต้องพอร์ตตรรกะการกรองนั้นไปยังทุกแพลตฟอร์มที่คุณพัฒนาแอปด้วย

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

ส่วนถัดไปจะอธิบายวิธีต่อไปนี้

  • เขียนคำขอและการตอบกลับบริการแบ็กเอนด์ใหม่เพื่อลดการเปิดเผยข้อมูล
  • ใช้การจัดการข้อบกพร่องเพื่อป้องกันไม่ให้ข้อความแสดงข้อผิดพลาดที่ละเอียดมากเปิดเผยข้อมูลสภาพแวดล้อมที่ละเอียดอ่อนเกี่ยวกับบริการแบ็กเอนด์ต่อผู้โจมตี

การเขียนคำตอบและคำขอใหม่

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

Apigee ใช้นโยบายหลัก 3 ข้อในการดำเนินการนี้

  • มอบหมายข้อความ
  • ข้อความไฮไลต์โค้ด
  • การจัดการข้อบกพร่อง

กำหนดนโยบายข้อความ

นโยบายกำหนดข้อความจะเปลี่ยนแปลงหรือสร้างข้อความคำขอและการตอบกลับใหม่ในระหว่างขั้นตอนการส่งผ่าน API นโยบายนี้ช่วยให้คุณดำเนินการต่อไปนี้กับข้อความเหล่านั้นได้

  • เพิ่ม พารามิเตอร์แบบฟอร์ม ส่วนหัว หรือพารามิเตอร์การค้นหาใหม่ลงในข้อความ
  • คัดลอกพร็อพเพอร์ตี้ที่มีอยู่จากข้อความหนึ่งไปยังอีกข้อความหนึ่ง
  • นําส่วนหัว พารามิเตอร์การค้นหา พารามิเตอร์แบบฟอร์ม และ/หรือเพย์โหลดข้อความออกจากข้อความ
  • ตั้งค่าค่าของพร็อพเพอร์ตี้ที่มีอยู่ในข้อความ

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

การเขียนโค้ดใหม่แบบซับซ้อนด้วยโค้ดที่กำหนดเอง

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

โค้ดเชิงกระบวนการช่วยให้คุณทําสิ่งต่อไปนี้ได้

  • สร้างหรือจัดการค่าของเนื้อหาที่ซับซ้อน เช่น ค่าคำขอและค่าการตอบกลับ
  • เขียน URL ใหม่ เช่น เพื่อมาสก์ URL ปลายทางเป้าหมาย

Apigee Edge มีนโยบายแยกต่างหากสำหรับภาษาที่รองรับ ได้แก่ นโยบาย JavaScript, นโยบายข้อความไฮไลต์ของ Java และนโยบายสคริปต์ของ Python

การจัดการข้อผิดพลาด

Apigee ให้คุณจัดการข้อยกเว้นที่กำหนดเองได้โดยใช้นโยบายประเภท Raise Fault นโยบายการแจ้งข้อบกพร่อง ซึ่งเป็นรูปแบบหนึ่งของนโยบายการกําหนดข้อความ ช่วยให้คุณสร้างการตอบกลับข้อบกพร่องที่กําหนดเองเพื่อตอบสนองต่อเงื่อนไขข้อผิดพลาดได้

โฟลว์ที่แชร์

คุณสามารถใช้โฟลว์ที่แชร์เพื่อบังคับใช้มาตรฐานของข้อความแสดงข้อผิดพลาด ตัวอย่างเช่น นโยบายที่กําหนดค่าไว้เดียวกันซึ่งตรวจหารหัสข้อผิดพลาด HTTP ที่เฉพาะเจาะจงจากแบ็กเอนด์สามารถใช้เขียนการตอบกลับข้อผิดพลาดใหม่เพื่อแสดงข้อความแสดงข้อผิดพลาดทั่วไปได้

API4:2019 Lack of resources & rate limiting

คำอธิบายภัยคุกคาม

การไม่ใช้นโยบายการจำกัดอัตราการส่งจะทำให้ผู้โจมตีสามารถโจมตีแบ็กเอนด์ได้ด้วยการโจมตีแบบการปฏิเสธการให้บริการ

ภัยคุกคามนี้จัดการได้ง่ายๆ โดยใช้ฟีเจอร์ต่อไปนี้ของ Apigee

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

การจำกัดอัตราด้วยโควต้าและนโยบายการหยุดการเข้าถึงชั่วคราวเนื่องจากมีจำนวนคำขอสูง

Apigee มีนโยบาย 2 รายการสำหรับการจำกัดอัตราการส่ง

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

Spike Arrest

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

โควต้า

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

  • ผลิตภัณฑ์ที่มีพร็อกซี API
  • แอปที่ขอ API
  • นักพัฒนาแอป
  • เกณฑ์อื่นๆ อีกมากมาย

นโยบายนี้มีความละเอียดมากกว่าการหยุดการเพิ่มขึ้นอย่างฉับพลัน และโดยทั่วไปควรใช้ควบคู่กัน

การตรวจหาบ็อตด้วย Apigee Sense

Apigee Sense ช่วยให้คุณดำเนินการเพื่ออนุญาต บล็อก หรือแจ้งว่าไม่เหมาะสมกับคำขอจากไคลเอ็นต์บางราย ช่วง IP หรือองค์กรระบบอิสระได้อย่างชัดเจน โดยอิงตามไคลเอ็นต์หรือตำแหน่งที่แสดงพฤติกรรมที่เป็นอันตรายหรือน่าสงสัย Apigee Edge จะใช้การดำเนินการเหล่านี้กับคำขอก่อนที่พร็อกซี API จะประมวลผล เช่น ระบบอาจตรวจพบช่วง IP หรือไคลเอ็นต์ที่แสดงพฤติกรรม "การคาดเดาแบบ Brute Force" จากนั้นจึงบล็อกหรือแจ้งว่าไม่เหมาะสม

การตรวจหาภัยคุกคามด้วยการตรวจสอบขั้นสูงของ API Ops

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

API5:2019 การให้สิทธิ์ระดับฟังก์ชันการทำงานที่ใช้งานไม่ได้

คำอธิบายภัยคุกคาม

ภัยคุกคามนี้มีความหลากหลายใน API1 และเป็นช่องโหว่การให้สิทธิ์ด้วย ภัยคุกคามนี้ทำให้ผู้โจมตีสามารถดําเนินการต่างๆ ได้โดยการส่งคําขอไปยังฟังก์ชันที่ตนไม่มีสิทธิ์เข้าถึง ตัวอย่างเช่น ผู้โจมตีอาจแก้ไขหรือลบข้อมูลที่ตนมีสิทธิ์อ่านเท่านั้นได้หาก API อุปกรณ์ปลายทางไม่ตรวจสอบคํากริยาของคําขอ HTTP โดยแทนที่ GET ด้วย PUT หรือ DELETE หรือหากไม่ใช้การควบคุมการเข้าถึงที่จำกัดเส้นทาง URI ของทรัพยากร API อย่างเพียงพอ เอนด์พอยต์ API อาจอนุญาตให้ผู้โจมตีดูข้อมูลของผู้ใช้รายอื่นได้ง่ายๆ เพียงเปลี่ยนเส้นทางในคำขอ

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

องค์ประกอบแนวคิดในการลดโอกาสที่จะเกิดขึ้นกับภัยคุกคามนี้มักจะแบ่งออกเป็น 3 ส่วน ได้แก่

  • สิ่งที่ได้รับการปกป้อง พิจารณากลยุทธ์ผลิตภัณฑ์ API ของคุณ และใช้การแบ่งกลุ่มฟังก์ชันการทำงานอย่างมีเหตุผลเมื่อใช้แนวทางปฏิบัติแนะนำของ RESTful เพื่อออกแบบเส้นทางและทรัพยากรที่แสดงโดยพร็อกซี API, ผลิตภัณฑ์ และฟีเจอร์แอปของ Apigee
  • ใครกำลังเข้าถึงทรัพยากร API ของคุณ กําหนดบุคคลระดับสูงและใช้การให้สิทธิ์เข้าถึงเริ่มต้นแบบ "มีสิทธิ์น้อยที่สุด" โดยใช้ฟีเจอร์การตรวจสอบสิทธิ์และการให้สิทธิ์ของ Apigee บางรายการตามที่ระบุไว้ใน API1 และ API2
  • มีการบังคับใช้นโยบายการเข้าถึงอย่างไร ใช้โฟลว์แบบมีเงื่อนไขและข้อบกพร่องเพื่อตรวจสอบเส้นทาง URL และคำกริยาของคำขอ API ทั้งหมด

รูปภาพ: แผนภาพนี้แสดงวิธีบังคับใช้การให้สิทธิ์ระดับฟังก์ชันใน Apigee โดยใช้ขอบเขตที่ระบุไว้ในโทเค็นการเข้าถึงเป็นการให้สิทธิ์

การแบ่งกลุ่มตามตรรกะด้วย API พร็อกซี ผลิตภัณฑ์ และแอป

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

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

รูปภาพ: ทรัพยากร API ที่รวมอยู่ในผลิตภัณฑ์ API อาจมาจาก API อย่างน้อย 1 รายการ คุณจึงสามารถผสมผสานทรัพยากรเพื่อสร้างระดับการบริโภคและขอบเขตการให้สิทธิ์

สิทธิ์เข้าถึงระดับฟังก์ชัน ควบคุมด้วยขอบเขต OAuth และข้อมูลอ้างสิทธิ์ JWT

แม้ว่าแนวทางการให้สิทธิ์ที่พิจารณาข้างต้นสำหรับ API1:2019 การอนุญาตออบเจ็กต์ที่ไม่ถูกต้องจะจัดการกับการควบคุมการเข้าถึงแบบละเอียดที่ระดับออบเจ็กต์ แต่การจัดการกับการควบคุมการเข้าถึงแบบหยาบที่ระดับฟังก์ชันก็สำคัญไม่แพ้กัน ผู้ใช้ที่ส่งคำขอได้รับอนุญาตให้ส่งคำขอเส้นทาง URL นี้หรือไม่ นโยบายประเภทนี้มักจะกำหนดตามบุคลิกของผู้ใช้ (ลูกค้า พนักงาน ผู้ดูแลระบบ นักพัฒนาซอฟต์แวร์ภายในหรือบุคคลที่สาม)

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

ขอการยืนยันด้วยขั้นตอนแบบมีเงื่อนไข

การเรียก REST API ในระดับพื้นฐานประกอบด้วยองค์ประกอบต่อไปนี้

  • ปลายทาง
  • ทรัพยากร
  • กริยา
  • แอตทริบิวต์คำขอเพิ่มเติมตามจำนวนที่ต้องการ เช่น พารามิเตอร์การค้นหา

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

เมื่อคุณเข้าใจและกำหนดตรรกะทางธุรกิจของผลิตภัณฑ์ API อย่างชัดเจน รวมถึงฟังก์ชันที่ API อนุญาตแล้ว ขั้นตอนถัดไปคือการจำกัดคำขอที่อยู่นอกเหนือขอบเขตนี้ผ่านฟีเจอร์ผลิตภัณฑ์ Apigee ต่อไปนี้

  • ตรรกะแบบมีเงื่อนไขและนโยบาย Raise Fault เพื่อจำกัดเส้นทางทรัพยากรหรือคำกริยาที่ขั้นตอนใดก็ได้ในการกำหนดค่าโฟลว์พร็อกซี
  • นโยบายการป้องกันภัยคุกคามสำหรับ JSON และ XML เพื่อป้องกันการโจมตีตามเนื้อหาโดยใช้เพย์โหลดคำขอ JSON หรือ XML ที่ไม่ถูกต้อง

API6:2019 การกำหนดแบบเป็นกลุ่ม

คำอธิบายภัยคุกคาม

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

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

โดยทั่วไปแล้ว การให้สิทธิ์ภัยคุกคามประเภทนี้เกี่ยวข้องกับ 2 ด้าน ได้แก่

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

จากมุมมองผลิตภัณฑ์ Apigee เรามีฟีเจอร์ที่มีประโยชน์หลายอย่างเพื่อให้การติดตั้งใช้งานการกรองข้อมูลของ API มีประสิทธิภาพ

นโยบายการกรองข้อกำหนดของ OpenAPI

นโยบาย OASValidation (การตรวจสอบข้อกำหนดของ OpenAPI) ช่วยให้คุณตรวจสอบคําขอขาเข้าหรือข้อความตอบกลับเทียบกับข้อกําหนดของ OpenAPI 3.0 (JSON หรือ YAML) ได้ นโยบายนี้ช่วยให้คุณทำสิ่งต่อไปนี้ได้

  1. ออกแบบ API ของคุณโดยสร้างข้อมูลจำเพาะ OpenAPI (OAS)
  2. ใช้สื่อกลาง การรักษาความปลอดภัย และตรรกะการแคชที่จําเป็นเพื่อแสดงผลิตภัณฑ์ API จากแบ็กเอนด์อย่างปลอดภัยด้วย Apigee
  3. ตรวจสอบคําขอขาเข้าเทียบกับสคีมาข้อมูลที่กําหนดไว้ในข้อกําหนด OAS ซึ่งรวมถึง basepath, verb, request message policy และparameters

นโยบายการตรวจสอบข้อความ SOAP

นโยบายการตรวจสอบข้อความ SOAP ช่วยให้คุณตรวจสอบคําขอที่อิงตาม XML ได้โดยการตรวจสอบข้อความ XML เทียบกับสคีมา XSD หรือตรวจสอบข้อความ SOAP เทียบกับคําจํากัดความ WSDL นอกจากนี้ คุณสามารถใช้นโยบายการตรวจสอบข้อความเพื่อยืนยันว่าเพย์โหลดข้อความ JSON หรือ XML อยู่ในรูปแบบที่ถูกต้อง ซึ่งรวมถึงการยืนยันข้อมูลต่อไปนี้ในข้อความ XML หรือ JSON

  • มีองค์ประกอบรูทรายการเดียว
  • เนื้อหาไม่มีอักขระที่ไม่ถูกต้อง
  • ออบเจ็กต์และแท็กซ้อนกันอย่างถูกต้อง
  • แท็กเริ่มต้นและแท็กสิ้นสุดตรงกัน

API7:2019 การกําหนดค่าการรักษาความปลอดภัยที่ไม่ถูกต้อง

คำอธิบายภัยคุกคาม

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

  • TLS กำหนดค่าไม่ถูกต้อง
  • ข้อความแสดงข้อผิดพลาดที่มีสแต็กเทรซ
  • ระบบที่ไม่มีการแพตช์
  • แผงการจัดการเซิร์ฟเวอร์หรือพื้นที่เก็บข้อมูลที่เปิดเผย

องค์กรต่างๆ สามารถทำตามขั้นตอนต่างๆ เพื่อแก้ไขและบรรเทาปัญหาเกี่ยวกับการกำหนดค่าความปลอดภัยที่ไม่ถูกต้องได้ ดังนี้

  1. การสร้างและกำหนดมาตรฐานกระบวนการทำให้ระบบปลอดภัยและการแพตช์
  2. การพัฒนาการกํากับดูแลเกี่ยวกับระบบนิเวศ API
  3. การจํากัดการเข้าถึงระดับผู้ดูแลระบบ รวมถึงการเปิดใช้การตรวจสอบและการแจ้งเตือน

โฟลว์ที่แชร์และ Flowhook

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

การรายงานความปลอดภัยของ API

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

  • ปฏิบัติตามนโยบายด้านความปลอดภัยและข้อกำหนดในการกำหนดค่า
  • ปกป้องข้อมูลที่ละเอียดอ่อนจากการละเมิดทั้งภายในและภายนอก
  • ระบุ วินิจฉัย และแก้ไขเหตุการณ์ด้านความปลอดภัยในเชิงรุก

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

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

การตรวจสอบ API

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

รูปภาพ: การตรวจสอบ API ของ Apigee มีเครื่องมือที่หลากหลายในการตรวจสอบ วิเคราะห์ และดำเนินการกับปัญหา โดยใช้ประโยชน์จากฟีเจอร์อัจฉริยะที่ดีที่สุดจาก Google Cloud Platform

Apigee Sense

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

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

  • ลักษณะการทํางานอัตโนมัติที่ผสานรวมกับพฤติกรรมของมนุษย์
  • การพยายามอย่างต่อเนื่องจาก IP เดียวกัน
  • อัตราข้อผิดพลาดที่ผิดปกติ
  • คำขอของไคลเอ็นต์ที่น่าสงสัย
  • การ Crawl ข้อมูล
  • การเก็บรวบรวมคีย์
  • ช่วงที่มีกิจกรรม
  • รูปแบบทางภูมิศาสตร์

API8:2019 Injection

คำอธิบายภัยคุกคาม

การส่งผ่านข้อมูลที่ไม่เชื่อถือ เช่น SQL, NoSQL, โปรแกรมแยกวิเคราะห์ XML, ORM, LDAP, คำสั่งระบบปฏิบัติการ และ JavaScript ไปยังคำขอ API อาจส่งผลให้มีการเรียกใช้คำสั่งที่ไม่ได้ตั้งใจหรือมีการเข้าถึงข้อมูลโดยไม่ได้รับอนุญาต ผู้โจมตีจะป้อนข้อมูลที่เป็นอันตรายไปยัง API ผ่านเวกเตอร์การแทรกที่มี เช่น อินพุตโดยตรง พารามิเตอร์ บริการที่ผสานรวม และอื่นๆ โดยคาดหวังว่าระบบจะส่งข้อมูลดังกล่าวไปยังโปรแกรมแปล ผู้โจมตีสามารถค้นพบข้อบกพร่องเหล่านี้ได้โดยง่ายเมื่อตรวจสอบซอร์สโค้ดโดยใช้เครื่องมือสแกนหาช่องโหว่และเครื่องมือสร้างข้อมูลเท็จ ในกรณีที่แทรกข้อมูลสำเร็จ อาจนำไปสู่การเปิดเผยข้อมูล ซึ่งส่งผลต่อการรักษาข้อมูลที่เป็นความลับและข้อมูลสูญหาย หรือในบางกรณีอาจนำไปสู่การโจมตีแบบ DoS ด้วย

แนวทางปฏิบัติแนะนำในการลดข้อผิดพลาด/การโจมตีจากการแทรก ได้แก่ การกําหนดข้อมูลอินพุตอย่างเข้มงวด เช่น สคีมา ประเภท รูปแบบสตริง การตรวจสอบอินพุต การตรวจสอบขีดจํากัด และการบังคับใช้ที่รันไทม์ แพลตฟอร์ม Apigee อนุญาตให้ตรวจสอบข้อมูลที่เข้ามาโดยใช้ตัวกรองเพื่ออนุญาตเฉพาะค่าที่ถูกต้องสำหรับพารามิเตอร์อินพุตแต่ละรายการ

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

นโยบายการป้องกันนิพจน์ทั่วไป

นโยบาย RegularExpressionProtection จะดึงข้อมูลจากข้อความ (เช่น เส้นทาง URI, พารามิเตอร์การค้นหา, ส่วนหัว, พารามิเตอร์แบบฟอร์ม, ตัวแปร, เพย์โหลด XML หรือเพย์โหลด JSON) และประเมินเนื้อหานั้นเทียบกับนิพจน์ทั่วไปที่กําหนดไว้ล่วงหน้า หากนิพจน์ทั่วไปที่ระบุประเมินเป็น "จริง" ระบบจะถือว่าข้อความเป็นภัยคุกคามและปฏิเสธข้อความ นิพจน์ทั่วไปหรือที่เรียกสั้นๆ ว่า regex คือชุดสตริงที่ระบุรูปแบบในสตริง นิพจน์ทั่วไปช่วยให้ระบบประเมินเนื้อหาเพื่อหารูปแบบได้แบบเป็นโปรแกรม นิพจน์ทั่วไปอาจใช้เพื่อประเมินอีเมลเพื่อให้แน่ใจว่ามีโครงสร้างที่เหมาะสม

การใช้งาน RegularExpressionProtection ที่พบบ่อยที่สุดคือการหาเนื้อหาที่เป็นอันตรายในเพย์โหลด JSON และ XML

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

แพลตฟอร์ม Apigee มีวิธีการอื่นๆ อีกหลายวิธีในการตรวจสอบอินพุต

ตรวจสอบประเภทเนื้อหา

ประเภทเนื้อหาหมายถึงเนื้อหาของไฟล์ที่โอนผ่าน HTTP และจัดหมวดหมู่ตามโครงสร้าง 2 ส่วน Apigee ขอแนะนำให้ตรวจสอบประเภทเนื้อหาของคำขอและคำตอบโดยใช้ตรรกะแบบมีเงื่อนไขตามที่อธิบายไว้ด้านล่าง

การรายงานความปลอดภัยของ API

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

  • ปฏิบัติตามนโยบายด้านความปลอดภัยและข้อกำหนดในการกำหนดค่า
  • ปกป้องข้อมูลที่ละเอียดอ่อนจากการละเมิดทั้งภายในและภายนอก
  • ระบุ วินิจฉัย และแก้ไขเหตุการณ์ด้านความปลอดภัยในเชิงรุก

API9:2019 การจัดการชิ้นงานไม่เหมาะสม

คำอธิบายภัยคุกคาม

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

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

องค์กร สภาพแวดล้อม และการแก้ไข: ขอบเขตเสมือนจริงและขอบเขตที่จับต้องได้ซึ่งรับประกันการแยกและกระบวนการโปรโมตที่ปลอดภัยผ่านบริบทรันไทม์

การควบคุมการเข้าถึงตามบทบาท: เฉพาะบุคคลที่จำเป็นในทีม API เท่านั้นที่จะมีสิทธิ์จัดการการเปลี่ยนแปลงการกำหนดค่าและกระบวนการโปรโมต

การจัดการกลุ่มเป้าหมายสําหรับเอกสารประกอบ API: เมื่อเผยแพร่ API ในพอร์ทัลสําหรับนักพัฒนาแอปแล้ว คุณจะจํากัดระดับการเข้าถึงเอกสารประกอบได้โดยจัดการกลุ่มเป้าหมาย

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

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

องค์กรและสภาพแวดล้อม

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

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

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

การแก้ไข: การแก้ไขช่วยให้โปรโมต API และฟีเจอร์แต่ละรายการได้อย่างราบรื่นในสภาพแวดล้อมต่างๆ

การควบคุมการเข้าถึงตามบทบาท

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

เอกสารประกอบเกี่ยวกับการจัดการกลุ่มเป้าหมายสําหรับ API

พอร์ทัลนักพัฒนาแอปเป็นองค์ประกอบสําคัญสําหรับความสําเร็จของกลยุทธ์ API เนื่องจากช่วยให้คุณเก็บคลังเอกสารประกอบทั้งหมดที่เกี่ยวข้องกับ API รวมถึงโฮสต์/ปลายทาง ทรัพยากร การดำเนินการ สคีมาเพย์โหลด และอื่นๆ ได้อย่างครอบคลุม ใน Apigee คุณสามารถจัดกลุ่ม API โดยใช้คอนสตรัคต์ผลิตภัณฑ์ API ผลิตภัณฑ์ API กำหนดโดยกลุ่มทรัพยากรและการดำเนินการที่อยู่ในบริบททางธุรกิจและการรักษาความปลอดภัยเดียวกัน (เช่น แพ็กเกจบริการ โดเมนธุรกิจ หมวดหมู่ ลําดับชั้นของบริษัท ฯลฯ)

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

ฮุกการไหล

กระบวนการโปรโมตและเผยแพร่ API ต้องมีกระบวนการปฏิบัติตามข้อกำหนดด้านความปลอดภัยและการรับรองเสมอ ทีม API ที่ใช้เครื่องมือที่เหมาะสมควรสร้างขอบเขตที่รับประกันการแยกความรับผิดชอบและรักษาวงจรการเผยแพร่แบบยืดหยุ่นเพื่อให้มีประสิทธิภาพ

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

รูปภาพ: คุณสามารถกําหนดค่าขอบเขตที่มีสิทธิ์ใน Apigee ผ่านฮุกของโฟลว์และโฟลว์ที่แชร์ ผู้มีส่วนเกี่ยวข้องด้านความปลอดภัยมีหน้าที่รับผิดชอบในการดูแลรักษานโยบายด้านความปลอดภัยทั่วโลก ฟีเจอร์เหล่านี้รับประกันการแยกความรับผิดชอบและส่งเสริมวงจรการพัฒนาแบบ Agile

การรายงานความปลอดภัย

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

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

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

การกําหนดค่า: ความสามารถในการตรวจสอบการกําหนดค่าพร็อกซี API ซึ่งให้ภาพรวมตั้งแต่ต้นจนจบเกี่ยวกับนโยบายทั้งหมดที่บังคับใช้ในระดับพร็อกซี API รวมถึงขอบเขตการบังคับใช้ของโฟลว์ที่แชร์ซึ่งแนบไว้ในระดับองค์กรหรือพร็อกซี

กิจกรรมของผู้ใช้: ติดตามการดำเนินการที่มีความละเอียดอ่อนซึ่งดำเนินการโดยผู้ใช้แพลตฟอร์ม วิเคราะห์กิจกรรมที่น่าสงสัยโดยเจาะลึกกิจกรรมที่น่าสงสัย

API10:2019 การบันทึกและการตรวจสอบไม่เพียงพอ

คำอธิบายภัยคุกคาม

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

กลยุทธ์การจัดการเหตุการณ์และการบันทึกสําหรับ API ควรพิจารณาแนวทางปฏิบัติแนะนําต่อไปนี้

  • นโยบายการจัดการบันทึก: จัดทำเอกสารและบังคับใช้กฎเพื่อกำหนดมาตรฐานและควบคุมระดับการถอดเสียงของบันทึก ระดับบันทึก ความสมบูรณ์ของบันทึก พื้นที่เก็บข้อมูลส่วนกลาง และอื่นๆ
  • นโยบายการจัดการกิจกรรม: รับประกันว่าทุกกิจกรรมควรติดตามแหล่งที่มาได้ นอกจากนี้ เหตุการณ์ควรจัดหมวดหมู่ตามความร้ายแรงและผลกระทบต่อธุรกิจ
  • รายงานและการตรวจสอบ: ผู้มีส่วนเกี่ยวข้องด้านความปลอดภัยและการดำเนินการควรเข้าถึงและดำเนินการกับบันทึกและเหตุการณ์ได้แบบเรียลไทม์ นอกจากนี้ ผู้มีส่วนเกี่ยวข้องยังทํารอบการเสริมเพื่อปรับรูปแบบการตรวจจับตามข้อมูลย้อนหลังได้

Apigee มีเครื่องมือที่จําเป็นในการสร้างกลยุทธ์การจัดการเหตุการณ์และการบันทึกที่ครอบคลุม เครื่องมือเหล่านี้รวมถึงรายการต่อไปนี้

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

ชุดเครื่องมือการดำเนินการบนระบบคลาวด์ของ Google: ใช้ประโยชน์จากการผสานรวมที่พร้อมใช้งานทันทีในเครื่องมือตรวจสอบและการบันทึกที่ปรับขนาดได้สูงจาก Google

นโยบายข้อความไฮไลต์ของบริการ: เพิ่มการรองรับสตรีมบันทึกที่ต้องใช้ปลายทาง HTTP ในการส่งเหตุการณ์

Analytics: เข้าถึงและวิเคราะห์ข้อมูลเมตาการเข้าชมที่ผ่านมาผ่านรายงานที่พร้อมใช้งานและ/หรือรายงานที่กําหนดเอง สร้างและจัดการการแจ้งเตือนตามแนวโน้มและทำความเข้าใจความผิดปกติของการเข้าชม

การตรวจสอบ API: ตามที่อธิบายไว้ก่อนหน้านี้ เครื่องมือนี้มีความสามารถในการแจ้งเตือนที่อาจทริกเกอร์ตามเหตุการณ์ที่สำคัญ บันทึกการเข้าชมสามารถวิเคราะห์และดําเนินการต่อได้