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

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

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

บทนำ

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

เอกสารนี้จะกล่าวถึงแนวทางในการป้องกันการโจมตีที่พบบ่อยซึ่งอิงตาม API ตามที่ระบุ โดยภัยคุกคามด้านความปลอดภัยของ API 10 อันดับแรกของ OWASP ปี 2019 ภัยคุกคามยอดนิยมที่ไฮไลต์ในรายการล่าสุดมักเกิดจากการวางการควบคุมการตรวจสอบสิทธิ์และการให้สิทธิ์ที่ไม่เหมาะสม เช่น การพึ่งพาการกรองข้อมูลที่ส่งคืนโดยคำขอ 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) ซึ่งช่วยป้องกันช่องโหว่นี้ แต่สิ่งสำคัญคือต้องกำหนดค่านโยบายเหล่านี้ อย่างถูกต้องเพื่อป้องกันภัยคุกคามนี้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

องค์ประกอบสำคัญที่ควรพิจารณามี 2 อย่าง ซึ่งจะกล่าวถึงในส่วนถัดไป

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

เมื่อ 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

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

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

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

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

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

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

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

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

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

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

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

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

Apigee ใช้ 3 นโยบายหลักต่อไปนี้เพื่อดำเนินการดังกล่าว

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

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

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

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

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

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

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

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

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

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

การจัดการข้อบกพร่อง

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

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

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

API4:2019 Lack of resources & rate limiting

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

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

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

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

การจำกัดอัตราคำขอด้วยโควต้าและนโยบายการป้องกันการเพิ่มขึ้นของทราฟิก

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

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

การจับกุมในช่วงที่เพิ่มขึ้น

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

โควต้า

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

การตรวจสอบ API

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

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

Apigee Sense

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

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

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

API8:2019 การแทรก

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

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

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

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

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

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

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

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

แพลตฟอร์ม Apigee มีแนวทางอื่นๆ ในการตรวจสอบความถูกต้องของอินพุตดังนี้

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Flow Hooks

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

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

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

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

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

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

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

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

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

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

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

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

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

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