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

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

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

เกริ่นนำ

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

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

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

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

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

API1:2019 การให้สิทธิ์ระดับออบเจ็กต์ที่เสียหาย

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

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

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

มี 2 ปัจจัยหลักที่ควรพิจารณาจากมุมมองด้านการใช้งาน Apigee คือ

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

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

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

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

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

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

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

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

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

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

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

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

API2:2019 การตรวจสอบสิทธิ์ผู้ใช้ที่เสียหาย

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

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

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

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

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

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

การออกแบบการรักษาความปลอดภัย

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

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

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

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

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

ฟีเจอร์การจัดการการรับส่งข้อมูลของ Apigee ต่อไปนี้ช่วยป้องกันการโจมตีแบบบรูตฟอร์ซได้

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

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

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

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

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

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

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

ขั้นตอนที่แชร์

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

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

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

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

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

การรักษาความปลอดภัยในการปฏิบัติงาน

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

Apigee Sense

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

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

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

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

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

การตรวจจับความผิดปกติทำงานโดยใช้โมเดลปัญญาประดิษฐ์ (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 นโยบายช่วยให้คุณดำเนินการต่อไปนี้กับข้อความเหล่านั้นได้

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

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

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

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

โค้ดขั้นตอนช่วยให้คุณทำสิ่งต่อไปนี้ได้

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

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

การจัดการความผิดพลาด

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

ขั้นตอนที่แชร์

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

API4:2019 การขาดทรัพยากรและการจำกัดอัตรา

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

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

ปัญหานี้แก้ไขได้ง่ายด้วยฟีเจอร์ของ Apigee ดังต่อไปนี้

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

การจำกัดอัตราด้วยนโยบายการจับกุมและโควต้า

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

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

การจับกุม

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

โควต้า

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

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

นโยบายนี้มีความละเอียดกว่าการจับกุม Spike มากกว่า และควรใช้ควบคู่กับนโยบายนี้

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

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

การตรวจจับภัยคุกคามด้วย Advanced API Ops Monitoring

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

API5:2019 การให้สิทธิ์ระดับฟังก์ชันขัดข้อง

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

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

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

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

  • สิ่งที่ได้รับการคุ้มครองคืออะไร นึกถึงกลยุทธ์ผลิตภัณฑ์ API และใช้การแบ่งกลุ่มฟังก์ชันเชิงตรรกะเมื่อใช้แนวทางปฏิบัติแนะนำของ RESTful เพื่อออกแบบเส้นทางและทรัพยากรที่พร็อกซี ผลิตภัณฑ์ และแอปของ Apigee API แสดง
  • ใครกำลังเข้าถึงทรัพยากร 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

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

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

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

ประเภทของการโจมตีที่อธิบายไว้ในภัยคุกคามนี้มักเกิดจากการกรองคำขอ 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 Specification Validation) ทำให้คุณตรวจสอบคำขอหรือข้อความตอบกลับที่เข้ามาใหม่กับข้อกำหนดเฉพาะของ OpenAPI 3.0 (JSON หรือ YAML) ได้ นโยบายนี้ช่วยให้คุณดำเนินการต่อไปนี้ได้

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

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

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

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

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

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

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

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

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

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

โฟลว์และฮุกโฟลว์ที่แชร์

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

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

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

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

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

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

การตรวจสอบ API

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

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

Apigee Sense

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

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

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

การฉีด API8:2019

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

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

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

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

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

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

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

การจัดการกลุ่มเป้าหมายสำหรับเอกสารประกอบของ API

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

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

ตะขอเกี่ยว

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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