10 האיומים המובילים ב-API של OWASP

אתם צופים במסמכי התיעוד של Apigee Edge.
כדאי לעיין במסמכי התיעוד של Apigee X. מידע

במסמך הזה מתוארות גישות שונות שאפשר להשתמש בהן ב-Apigee כדי לטפל בפגיעויות אבטחה שזוהו על ידי OWASP. במאמר אפשרויות להפחתת הסיכון של 10 נקודות התורפה המובילות של OWASP בשנת 2021 ב-Google Cloud מפורטות גישות נוספות שמתועדות ב-Apigee.

מבוא

‫OWASP היא קהילה פתוחה שמטרתה לעזור לארגונים לפתח, לרכוש ולתחזק אפליקציות וממשקי API מהימנים. במסגרת פרויקט אבטחת ה-API של OWASP,‏ OWASP מפרסמת את סיכוני האבטחה הקריטיים ביותר לאפליקציות אינטרנט ולממשקי REST API, ומספקת המלצות לטיפול בסיכונים האלה.

במסמך הזה נדון בגישות להגנה מפני התקפות נפוצות שמבוססות על API, כפי שזוהו ב-OWASP's 2019 top ten API security threats. נושא משותף בקרב האיומים המובילים שמודגשים ברשימה האחרונה הוא איומים שנובעים ממיקום לא תקין של אמצעי בקרה לאימות ולהרשאה, כמו הסתמכות על סינון של נתונים שמוחזרים על ידי בקשת API באפליקציות לקוח, באמצעות שימוש באנטי-תבנית של הסתמכות על אפליקציית הלקוח שצורכת את הנתונים כדי לבצע אכיפה של בקרת גישה.

מערכת האקולוגית של ממשקי ה-API ממשיכה לצמוח בקצב מהיר, ולצערנו, ניצול לרעה של ממשקי API שמוביל לחילוץ נתונים על ידי תוקפים הופך לאחד מוקטורי המתקפה הנפוצים ביותר כיום. האבטחה ממשיכה להיות בראש סדר העדיפויות של Apigee, עם מספר תכונות חדשות כמו Advanced API Ops, שכוללת תכונות לזיהוי אנומליות. עם זאת, חשוב מאוד לתכנן ולהטמיע נכון את תכונות האבטחה של Apigee כדי להקטין את הסיכוי להתקפות מוצלחות על ממשקי ה-API שלכם.

אפליקציות לצרכנים נחשבות לאפליקציות לא מהימנות או 'ציבוריות', כי אין לכם שליטה בפלטפורמה שבה האפליקציה פועלת. צריך להניח שכל אפליקציה ציבורית עלולה להיפרץ, ולכן אי אפשר לסמוך עליה שתאכוף בקרת גישה (API1,‏ API5), תסנן נתונים בתגובה (API6) או תשמור בצורה בטוחה סודות של לקוחות (API2) כמו מפתחות API או טוקנים לגישה. חלק מההמלצות מבוססות על בדיקה של 10 הבעיות המובילות של OWASP משנת 2019:

  • קובעים אילו סוגים של אפליקציות לקוח ישתמשו בממשקי ה-API (SPA, נייד או מבוסס-דפדפן), ומתכננים את דפוסי האימות, ההרשאה והאבטחה המתאימים.
  • תמיד משתמשים בתהליכי OAuth או OpenID Connect של 'לקוח ציבורי' (מומלץ מאוד להשתמש ב-PKCE)
  • כדאי לחשוב על הלוגיקה העסקית של האפליקציה, להגדיר קודם את מפרט OpenAPI ולתכנן את שרתי ה-proxy של ה-API כך שיסננו את כל נתוני התגובה מהקצה העורפי בתוך Apigee. אל תסתמכו על לוגיקת קוד של אפליקציה במורד הזרם כדי לבצע את הפעולה הזו.
  • מסננים את כל בקשות הנתונים שמכילות PII ספציפי למשתמש כדי לאפשר רק נתונים מהקצה העורפי ששייכים למשתמש ששלח את הבקשה.

‫API1:2019 Broken object level authorization

תיאור האיום

אימות הרשאה לא מספיק של בקשת גישה לאובייקט מאפשר לתוקף לבצע פעולה לא מורשית על ידי שימוש חוזר בטוקן גישה. האיום הזה נגרם בגלל הגדרה לא תקינה של אימותי הרשאה. ‫Apigee מספקת כללי מדיניות של VerifyApiKey,‏ OAuth ו-JSON Web Token‏ (JWT), שעוזרים להגן מפני הפגיעות הזו. עם זאת, חשוב מאוד להגדיר את כללי המדיניות האלה בצורה נכונה כדי למנוע את האיום הזה.

כדי למנוע את האיום הזה, חשוב שצוותי פיתוח האפליקציות והאבטחה ישתפו פעולה באופן הדוק. הרשאות הן נושא מורכב, והרשאות גרנולריות יעילות דורשות הבנה מעמיקה של הלוגיקה העסקית של האפליקציה.

יש שני היבטים עיקריים שצריך לקחת בחשבון מנקודת מבט של הטמעה ב-Apigee:

  • שלמות אסימון הגישה
  • אכיפת בקרת גישה

תקינות של טוקן גישה

חשוב מאוד לוודא שהטוקן שסופק על ידי הלקוח המבקש לא עבר שינוי. כדי לעשות זאת, צריך להשתמש בתהליך הנכון של OAuth או OpenID Connect, יחד עם מנגנון האימות או החתימה המתאים של פרטי הכניסה. ‫Apigee תומך בכל תהליכי OAuth הנפוצים.

כללי מדיניות לאימות טוקנים של גישה ב-Apigee כוללים:

אכיפת בקרת גישה

אחרי שמאמתים את התוקף של אסימון הגישה, חשוב מאוד להטמיע מדיניות לאכיפת בקרת גישה כדי להעריך כל בקשת API נכנסת בהשוואה להרשאות הגישה של אסימון ההרשאה.

ב-Apigee יש שני מנגנונים עיקריים לאימות ולאכיפה של מדיניות הרשאות:

  • פנימי: שימוש בתהליכים מותנים כדי להעריך בקשות גישה על סמך הצהרות שחולצו כמשתני תהליך מאסימון הרשאה
  • הוענקה: באמצעות הפניה לשירות לפתרון לניהול גישה של צד שלישי

הגישה הפנימית (שמוצגת באיור שלמעלה) מומלצת אם מודל בקרת הגישה פשוט יחסית. לדוגמה, אם אפשר להשתמש בטענות שחולצו מטוקן גישה כדי להעריך ולאשר ישירות בקשה לאובייקט API.

אפשר להשתמש במשתני הזרימה שזמינים למדיניות OAuth או JWT כדי להעריך בקשות גישה באמצעות הצהרות זרימה מותנות.

הגישה להענקת גישה (שמוצגת באיור שלמעלה) מומלצת כשאי אפשר להשתמש ישירות בטענות שחולצו מאסימון גישה כדי לאשר בקשת API לאובייקט בקצה העורפי, או לסוגים מורכבים יותר של תהליכי OAuth שדורשים קריאה נפרדת לשרת הרשאות כדי לקבל אסימון גישה.

באמצעות מדיניות ההפניה לשירות, אפשר לבקש החלטה לגבי מדיניות הרשאות משירות צד שלישי, או לקבל מידע נוסף על הטענה לגבי הסוכן המבקש כדי לקבל החלטה לגבי בקרת גישה באמצעות זרימה מותנית

‫API2:2019 אימות משתמשים פגום

תיאור האיום

מדיניות אימות משתמשים שלא מיושמת בצורה טובה מאפשרת לתוקפים להתחזות למשתמשים לגיטימיים על ידי ניצול פגמים בהטמעות של אימות. הנה כמה עקרונות שחשוב לזכור כשמטמיעים שיטות אימות:

  • תמיד צריך לאמת גם את סוכן המשתמש (האפליקציה) וגם את המשתמש ששולח את הבקשה
  • להשתמש בתבניות של אימות והרשאה בהענקת גישה, ולהימנע מהעברת סיסמאות ישירות בבקשת API
  • תמיד צריך לאמת את החתימה של פרטי הגישה, ולוודא שלכל פרטי הגישה שבהם נעשה שימוש מוגדר תאריך תפוגה.
  • כדי למנוע התקפות ברוט פורס, אפשר להגדיר מכסות ולהשתמש ב-Apigee Sense כדי לזהות התקפות ברוט פורס שמבוססות על בוטים ולהגיב להן.

בפרדיגמה של מבחוץ פנימה, עיצוב ה-API מבוסס על תרחישי השימוש של הצרכנים בנתונים, ולא על המבנה של הנתונים הקיימים במערכות העורפיות שלכם. האבטחה היא מרכיב קריטי בעיצוב ממשקי API לצרכנים חיצוניים. מערכות עורפיות לא נבנות בדרך כלל עם הטמעות אימות חזקות מספיק לחשיפה לרשתות ציבוריות. כאן נכנס לתמונה Apigee, בשילוב עם פתרון לניהול זהויות והרשאות גישה, שיכול להציע פתרונות חזקים להגנה מפני האיום הזה.

יש כאן כמה רכיבים חשובים שכדאי להביא בחשבון, ונתייחס לכולם בקטעים הבאים:

  • תכנון אבטחה: שימוש מלא בתכונות של Apigee להטמעה של דפוסי אימות
  • ניהול: מוודאים שנעשה שימוש עקבי בדפוסי האימות המתוכננים בכל מוצרי ה-API שפורסמו
  • אבטחה תפעולית: יכולת לזהות התנהגויות חשודות או חריגות וניסיונות לעקוף או לפרוץ פרוקסי של ממשקי API מאומתים

עיצוב אבטחה

המטרה של תכנון אבטחה היא להטמיע בצורה נכונה תהליכי אימות ושילוב עם כלים של צד שלישי לניהול זהויות. תכנון האבטחה הוא שלב קריטי, והוא מתחיל בהבנה של סוג תהליך האימות הנכון שצריך להשתמש בו על סמך סוג האפליקציה שתשתמש בנקודות הקצה של ה-API. השלב הבא הוא להגדיר, יחד עם צוות הזהויות, את דפוסי השילוב שרוצים ליישם עם פתרון הזהויות.

מסמכי ה-RFC של OpenID Connect ו-OAuth מספקים מספר רב של תהליכי אימות והרשאה מוקצים, וגם את הגורמים שמעורבים בתהליכים האלה. זהו נושא מורכב, ולא מפתיע שאימות פגום הוא אחד מהאיומים העיקריים על API לפי OWASP. הסבר מקיף על הטמעה נכונה של תקני זהות לא נכלל במסמך הזה, אבל ב-Apigee יש הרבה משאבים נוספים שיעזרו לכם להבין טוב יותר את תהליכי העבודה של OAuth, כמו הספר הדיגיטלי והשידור באינטרנט האלה, והטמעה לדוגמה.

מדיניות אימות

מדיניות Apigee שעוזרת לטפל בבעיות שקשורות לזהות ולאימות כוללת:

  • אימות או יצירה של אסימוני גישה, אסימוני רענון או אסימונים של תהליך התגובה כשמשתמשים במסגרת OAuth 2.0. הערה: מבחינה טכנית, OAuth הוא מסגרת הרשאות מוקצית, אבל נעשה בו שימוש נרחב בדפוסי אימות מוקצים או מאוחדים
  • אימות, פענוח ויצירה של אסימוני אינטרנט מסוג JSON וחתימות אינטרנט מסוג JSON של OpenID Connect 1.0
  • יצירה ואימות של טענות נכוֹנוּת (assertions) של SAML
  • אימות מפתחות API
  • קוד אימות הודעות המבוסס על גיבוב (HMAC) אימות

ניהול תנועה

התכונות הבאות של ניהול תנועה ב-Apigee עוזרות להגן מפני מתקפות כוח ברוטלי:

  • המדיניות Spike Arrest, להגדרת הגבלת קצב כוללת של ממוצע נע ב-proxy ל-API
  • מדיניות בנושא מכסות, להגדרת מגבלות מפורטות על קצב הבקשות לשרתי proxy ל-API על סמך מכסות שמוגדרות על ידי מפתחות אפליקציות, מפתחים או מכסות של מוצרי API
  • מדיניות שמירת נתונים במטמון, לשמירת נתונים במטמון של אסימוני גישה מאוחסנים על סמך תאריכי התפוגה המוגדרים שלהם, וגם היכולת לבטל פרטי כניסה שנשמרו במטמון (לדוגמה, במצב שבו אסימון גישה תקף נפרץ)

ניהול

אבטחה היא תהליך מתמשך, ולא פרויקט של 'הגדרה ושכחה'. אחת הסיבות העיקריות לפרצות אבטחה היא הגדרה שגויה. אחרי שמגדירים את תהליכי האימות, את דפוסי השילוב של הזהויות ואת מדיניות ניהול התנועה שקשורה לאימות, חשוב מאוד להטמיע אותם בצורה נכונה ועקבית.

‫Apigee מספק מספר תכונות וכלים שמבטיחים את שלמות ההטמעה ומונעים שגיאות בהגדרות.

בקרת גישה מבוססת-תפקידים (RBAC)

לא משנה אם אתם עובדים בארגון גדול או בסטארט-אפ קטן, כדי להימנע משגיאות בהגדרות צריך לוודא שרק האנשים והצוותים הנכונים יכולים לגשת להגדרות של שרתי proxy ל-API ולשנות אותן. ‫API תוכניות נתמכות על ידי צוותים רב-תחומיים בארגון. חשוב מאוד להקפיד שכל צוות יקבל רק את ההרשאות הנדרשות כדי לבצע את העבודה שלו כחלק מהשימוש ב-API.

‫Apigee מספק תכונות לניהול גישה מבוססת-תפקידים. התכונות האלה מאפשרות להקצות משתמשים לתפקידים מוגדרים מראש או ליצור תפקידים בהתאמה אישית שמתאימים לצוותי ה-API. הגדרה וניהול נכונים של הקצאת תפקידים הם קריטיים כדי לאפשר לכם להרחיב את תוכנית ה-API שלכם בצורה מאובטחת. אפשר גם להשתמש בפדרציה כדי לבצע אינטגרציה עם ספריית החברה הקיימת, וכדי לצמצם את הצורך בניהול של קבוצה שנייה של פרטי כניסה לאדמין ב-Apigee.

תהליכי עבודה משותפים

Shared flows מאפשרים להגדיר מדיניות ומשאבים באובייקט שאפשר להשתמש בו שוב, וליישם אותו בשרתי proxy ל-API. לדוגמה, יכול להיות שצוותי האבטחה שלכם תכננו יחד כמה דפוסי עיצוב של אימות בהתבסס על סוג האפליקציה שצורכת API. מפתח API לא צריך להיות מומחה לזהויות כדי לעשות שימוש חוזר בזה, הוא רק צריך לדעת מהו התהליך המשותף הנכון כדי להוסיף אותו להגדרת ה-proxy ל-API הקיימת באמצעות מדיניות Flow callout.

איור: Shared Flows הם חבילות של כללי מדיניות ולוגיקה מותנית שאפשר להשתמש בהן שוב, והן מאפשרות לשמור על תבנית מורכבת.

אבטחה תפעולית

אחרי שממשקי ה-API שלכם עוברים לייצור באמצעות דפוסי האימות הנכונים עם ניהול בסיסי של תנועת גולשים, צוות ה-SecOps צריך גם להיות מסוגל לנטר פעילות חשודה ולהגיב לה, שלרוב מתחילה בניסיונות לפגוע בפרטי האימות.

Apigee Sense

‫Apigee Sense מגן על ממשקי ה-API מפני תעבורת בקשות לא רצויה, כולל התקפות מלקוחות זדוניים. ‫Apigee Sense מנתח את תעבורת הנתונים של בקשות API ומזהה דפוסים שעשויים לייצג בקשות לא רצויות. בעזרת הניתוח הזה, תוכלו לזהות לקוחות ששולחים בקשות לא רצויות, ואז לפעול כדי לאשר, לחסום או לסמן את הבקשות האלה. בעתיד, התכונות של Sense יכללו את האפשרות להפעיל באופן אוטומטי אימות ReCAPTCHA בתנועה חשודה.

באמצעות Apigee Sense, אתם יכולים להגן על ממשקי ה-API מפני דפוסי בקשות שכוללים:

  • התנהגות אוטומטית שמשתלבת עם התנהגות אנושית
  • ניסיונות חוזרים ונשנים מאותה כתובת IP
  • שיעורי שגיאות חריגים
  • בקשות לקוח חשודות
  • סריקת נתונים
  • איסוף מפתחות ומתקפות כוח ברוטלי על אימות
  • פרצי פעילות
  • דפוסים גיאוגרפיים

Advanced API Ops

‫Sense תוכנן במיוחד לזיהוי איומים שדומים לבוטים ולתגובה להם, אבל Advanced API Ops כולל גם זיהוי אנומליות וגם הגדרה של התראות מתקדמות.

התכונה לזיהוי אנומליות פועלת באמצעות מודלים של בינה מלאכותית (AI) ולמידת מכונה (ML) שמוחלים על נתוני ה-API ההיסטוריים שלכם. לאחר מכן, המערכת יכולה לשלוח התראות בזמן אמת על תרחישים שלא חשבתם עליהם, כדי לשפר את הפרודוקטיביות שלכם ולקצר את הזמן הממוצע לפתרון (MTTR) של בעיות ב-API.

התכונה 'פעולות מתקדמות ב-API' מבוססת על מנגנון ההתראות הקיים של פיקוח על API, ומוסיפה את סוגי ההתראות המתקדמים הבאים:

  • התראות על אנומליות. ‫Edge מזהה בעיות בתנועה ובביצועים במקום שתצטרכו לקבוע אותן מראש בעצמכם. אחר כך אפשר ליצור התראה לגבי האנומליות האלה
  • התרעות על תפוגה של TLS. התראה מופיעה כשאישור TLS מתקרב למועד התפוגה

‫API3:2019 חשיפת נתונים מוגזמת

תיאור האיום

יכול להיות ש-API שפורסם יחשוף יותר נתונים מהנדרש, ויסתמך על אפליקציית הלקוח כדי לבצע את הסינון הנדרש. אם תוקף ישלח שאילתה ישירות ל-API הבסיסי, הוא יוכל לגשת למידע אישי רגיש.

אחד מעקרונות התכנון של Apigee ל-API, שנקרא outside-in, הוא data parsimony. כדאי לעבוד עם מעצבי חוויית המשתמש והמפתחים כדי לחשוף נתונים רק דרך ממשקי API שנדרשים בממשק המשתמש של האפליקציה. מערכות עורפיות לא נועדו לדפוסי שימוש ציבוריים, ולכן אחת המשימות הראשונות של עיצוב API first עם Apigee היא לצמצם את הנתונים שנחשפים למינימום הנדרש כדי לספק מוצר API מצוין ללקוחות ולמפתחים שלכם.

עוד אחד מעקרונות העיצוב של Apigee הוא שימוש חוזר. בנוסף לבעיות אבטחה, אם מסתמכים על אפליקציה לסינון הנתונים שמסופקים על ידי API, צריך להעביר את לוגיקת הסינון הזו לכל פלטפורמה שמפתחים עבורה אפליקציה.

מבחינת אבטחה, האיום הזה נובע מהעברת סמכות לאכיפת הרשאות לאפליקציה, אבל לעיתים קרובות בפלטפורמה או במערכת הפעלה שאין לכם שליטה עליהן. כבר הסברנו בAPI1 וב-API2 כמה חשוב להטמיע נכון אימות והרשאה כדי למנוע גישה לא מורשית לנתונים.

בקטעים הבאים נסביר איך:

  • כתיבה מחדש של בקשות ותגובות לשירותי קצה עורפיים כדי לצמצם את חשיפת הנתונים
  • הטמעת טיפול בשגיאות כדי למנוע חשיפה של מידע רגיש על הסביבה לתוקפים לגבי שירותי הקצה העורפי, באמצעות הודעות שגיאה מפורטות

שכתוב תשובות ובקשות

בדרך כלל, מערכות עורפיות לא מיועדות לשימוש באפליקציות ציבוריות או ברשתות ציבוריות לא מהימנות. ‫Apigee Edge תוכנן כדי לאפשר לכם לפרוס מוצרי API ציבוריים על ידי הגנה על הקצה העורפי שלכם מפני חשיפת נתונים.

כדי לעשות את זה, Apigee משתמש בשלוש מדיניות מרכזיות:

  • הקצאת הודעה
  • הערות על קוד
  • טיפול בשגיאות

הקצאת מדיניות בנושא הודעות

מדיניות הקצאת הודעה משנה או יוצרת הודעות חדשות של בקשות ותגובות במהלך התהליך של ה-proxy ל-API. המדיניות מאפשרת לכם לבצע את הפעולות הבאות בהודעות האלה:

  • הוספה של פרמטרים חדשים של טופס, כותרות או פרמטרים של שאילתה להודעה
  • העתקה של מאפיינים קיימים מהודעה אחת להודעה אחרת
  • הסרה של כותרות, פרמטרים של שאילתות, פרמטרים של טפסים ו/או מטען ייעודי (payload) של הודעות מהודעה
  • הגדרה של ערך מאפיינים קיימים בהודעה

באמצעות הפעולה 'הקצאת הודעה', בדרך כלל מוסיפים, משנים או מסירים מאפיינים של הבקשה או התגובה. עם זאת, אפשר גם להשתמש בפעולה Assign Message כדי ליצור הודעת בקשה או תגובה בהתאמה אישית ולהעביר אותה ליעד חלופי, כמו שמתואר במאמר בנושא יצירת הודעות בקשה בהתאמה אישית.

שכתוב מורכב באמצעות קוד בהתאמה אישית

כדי לטפל בנתונים מורכבים ולשכתב כללים מורכבים שחורגים מהיכולות של Assign message policy (הקצאת מדיניות להודעות), אפשר להשתמש בשפות פרוצדורליות כמו JavaScript,‏ Java או Python. אתם יכולים להוסיף קוד בהתאמה אישית ל-proxy ל-API ואז לקרוא לו ממדיניות שנוספה לזרימת ה-proxy. התמיכה בקוד פרוצדורלי נועדה להקל עליכם להטמיע טיפול מורכב במשתני זרימה, בתקלות ובגופי הבקשות והתגובות.

בעזרת קוד פרוצדורלי, אפשר:

  • ליצור או לתפעל ערכים מורכבים של גוף הבקשה, כמו ערכי בקשה ותגובה.
  • לשכתב כתובות URL, למשל כדי להסתיר כתובת URL של נקודת קצה של יעד.

‫Apigee Edge כולל מדיניות נפרדת לשפות נתמכות: מדיניות JavaScript, מדיניות Java Callout ומדיניות Python Script.

טיפול בשגיאות

‫Apigee מאפשר לכם לבצע טיפול מותאם אישית בחריגים באמצעות מדיניות מסוג Raise Fault. המדיניות Raise Fault (העלאת תקלה), שהיא וריאציה של המדיניות Assign Message (הקצאת הודעה), מאפשרת ליצור תגובה מותאמת אישית לתקלה בתגובה למצב שגיאה.

תהליכי עבודה משותפים

אפשר להשתמש ברצפי פעולות משותפים כדי לאכוף סטנדרטיזציה של הודעות שגיאה. לדוגמה, אפשר להשתמש באותן מדיניות מוגדרות שמזהות קוד שגיאת HTTP ספציפי מהקצה העורפי כדי לשכתב את תגובת השגיאה ולהחזיר הודעת שגיאה כללית.

‫API4:2019 חוסר משאבים והגבלת קצב

תיאור האיום

אם לא מטמיעים מדיניות להגבלת קצב הבקשות, התוקפים יכולים להעמיס על ה-backend באמצעות התקפות מניעת שירות (DoS).

אפשר לטפל באיום הזה בקלות באמצעות התכונות הבאות של Apigee:

  • ‫Quotas and Spike Arrest policies בתור אמצעי בקרה מונעים להגבלת התנועה בבקשות API נכנסות
  • ‫Apigee Sense לזיהוי דינמי של מתקפות שמבוססות על בוטים ולתגובה להן
  • מעקב מתקדם אחר API והתראות כאמצעי בקרה לגילוי התקפות DDoS בזמן שהן מתרחשות

הגבלת קצב של יצירת בקשות באמצעות מכסות ומדיניות של עצירות בנקודות שיא

‫Apigee מספק שתי מדיניות להגבלת קצב:

  • Spike arrest מספק מדיניות כללית, שמוגדרת ברמת ה-proxy ל-API, להגבלת קצב הבקשות הנכנסות לשרת קצה עורפי
  • מכסות מספקות כלי מדיניות מפורט לאכיפת מדיניות מכסות, ברמת proxy ל-API או ברמת מוצר API

מעצר של ספייק

מדיניות Spike Arrest מגנה מפני עליות חדות בתנועה. המדיניות הזו מגבילה את מספר הבקשות שמעובדות על ידי proxy ל-API ונשלחות אל ה-Backend, כדי להגן מפני עיכובים בביצועים וזמן השבתה. ההגבלה מתבססת על ערך ממוצע נע שמוגדר במדיניות.

מכסות

המדיניות Quota מאפשרת להגדיר את מספר הודעות הבקשה ש-proxy ל-API מאפשר במשך תקופה מסוימת, כמו דקה, שעה, יום, שבוע או חודש. אפשר להגדיר את המכסה כך שתהיה זהה לכל האפליקציות שניגשות ל-proxy ל-API, או להגדיר את המכסה על סמך:

  • המוצר שמכיל את proxy ל-API
  • האפליקציה ששולחת את הבקשה ל-API
  • מפַתח האפליקציה
  • קריטריונים רבים אחרים

המדיניות הזו מפורטת יותר מהמדיניות 'מניעת עליות פתאומיות בתנועה', ובדרך כלל מומלץ להשתמש בה במקביל למדיניות הזו.

זיהוי בוטים באמצעות Apigee Sense

באמצעות Apigee Sense, אתם יכולים לבצע פעולה כדי לאפשר, לחסום או לסמן במפורש בקשות מלקוחות ספציפיים, מטווחים של כתובות IP או מארגונים של מערכות אוטונומיות, על סמך התנהגות זדונית או חשודה של הלקוחות או המיקומים האלה. ‫Apigee Edge מחיל את הפעולות האלה על בקשות לפני שהן מעובדות על ידי שרתי ה-proxy של ה-API. לדוגמה, אפשר לזהות טווח כתובות IP או לקוח ספציפי שמציג התנהגות של ניסיון לנחש סיסמה בכוח, ואז לחסום אותו או לסמן אותו.

זיהוי איומים באמצעות Advanced API Ops Monitoring

אפשר להשתמש בהתראה על תנועת נתונים כדי להציג התראה כשחלים שינויים בתנועת הנתונים בסביבה, בשרת proxy או באזור, בשיעור מסוים ובטווח זמן מסוים. התכונה הזו יכולה להציג התראה באופן דינמי אם התנועה חורגת באופן משמעותי מהתפוקה הצפויה, כמו במקרה של מתקפת DDoS. אפשר לשלוח את ההתראות האלה בקלות לפתרון של צד שלישי לרישום ביומן ולניטור.

‫API5:2019 הרשאה ברמת פונקציה לא תקינה

תיאור האיום

האיום הזה הוא וריאציה של API1, והוא גם פגיעות בהרשאה. במקרה של איום כזה, התוקף יכול לבצע פעולות על ידי שליחת בקשות לפונקציות שאין לו הרשאה לגשת אליהן. לדוגמה, תוקף יכול לשנות או למחוק נתונים שיש לו הרשאה רק לקרוא אותם, אם נקודת קצה של API לא מאמתת את פועל הבקשה של HTTP, על ידי החלפת GET ב-PUT או ב-DELETE. לחלופין, אם לא מטמיעים בנתיב של URI של משאב API בקרת גישה מספיק מחמירה, יכול להיות שנקודת קצה ל-API תאפשר לתוקף לצפות בנתונים של משתמש אחר פשוט על ידי שינוי הנתיב בבקשה.

סוג האיום הזה מדגיש את היתרון בשימוש ב-Apigee כשכבת תיווך והפשטה, כי הרבה מערכות עורפיות – שלא מיועדות לגישה ציבורית – עשויות לספק כברירת מחדל נקודת קצה אחת להפעלת פונקציות מרובות של לוגיקה עסקית, כולל פונקציות ניהוליות בסיכון גבוה.

האלמנטים הרעיוניים לצמצום הסבירות לאיום הזה מחולקים בדרך כלל לקטגוריות הבאות:

  • מה מוגן? כדאי לחשוב על אסטרטגיית מוצרי ה-API שלכם, וליישם פילוח לוגי של הפונקציונליות כשמשתמשים בשיטות מומלצות ל-RESTful כדי לעצב את הנתיבים והמשאבים שנחשפים על ידי שרתי proxy ל-API, מוצרים ותכונות של אפליקציות ב-Apigee.
  • למי יש גישה למשאבי ה-API? מגדירים את דמויות המשתמשים ברמה גבוהה ומטמיעים הרשאות גישה שמוגדרות כברירת מחדל לפי העיקרון של 'ההרשאה המינימלית' באמצעות חלק מתכונות האימות וההרשאה של Apigee, כפי שמתואר במאמרים API1 ו-API2.
  • איך נאכפת מדיניות הגישה שלכם? משתמשים בתהליכים מותנים ובשגיאות כדי לאמת את נתיב כתובת ה-URL ואת הפועל של כל בקשות ה-API.

דיאגרמה: בתרשים הזה מוצג אופן האכיפה של הרשאה ברמת הפונקציה ב-Apigee, באמצעות היקפי הרשאות שמופיעים בתוך טוקן גישה כהרשאות גישה.

פילוח לוגי באמצעות שרתי proxy ל-API, מוצרים ואפליקציות

‫Apigee מספק ערכת כלים גמישה מאוד שמאפשרת פילוח לוגי של משאבי API, כך שניתן לארוז שרתי proxy ל-API בכל מספר של מוצרי API, שבתורם משמשים את מפתחי האפליקציות שלכם, שיכולים לרשום אפליקציות שמשתמשות במוצרי ה-API שלכם. אפשר להגדיר מדיניות גישה בכל אחת מהרמות האלה.

כדי להטמיע הרשאה ופילוח פונקציונליים יעילים, חשוב להגדיר אסטרטגיית מוצרי API. חלק מהתהליך החשוב והמתמשך הזה הוא הגדרת ה'מי' וה'מה' של מוצרי ה-API שלכם. כדי לעשות את זה, צריך לבחון את משאבי ה-API מנקודת המבט של הלקוח והמפתח, ואז להגדיר בדיוק אילו סוגי בקשות יורשו, עד לרמת משאב הנתיב ופועל ה-HTTP.

איור: מקורות המידע של ה-API שנכללים במוצר API יכולים להגיע מממשק API אחד או יותר, כך שאפשר לשלב בין מקורות מידע כדי ליצור רמות צריכה וגבולות הרשאה.

בקרת גישה ברמת הפונקציה באמצעות היקפי OAuth וטענות JWT

הגישות להרשאה שצוינו למעלה עבור API1:2019 Broken object authorization מתייחסות לבקרת גישה פרטנית ברמת האובייקט, אבל חשוב באותה מידה להתייחס לבקרת גישה גסה ברמת הפונקציה. האם המשתמש ששולח את הבקשה מורשה בכלל לבקש את נתיב כתובת ה-URL הזה? סוג המדיניות הזה מוגדר לרוב לפי פרסונה של משתמש (לקוח, עובד, אדמין, מפתח פנימי או מפתח צד שלישי).

כדי לצמצם את הסיכון לטעות בהגדרה, מומלץ לפעול מול צוות האבטחה כדי לוודא שהטענות לגבי המשתמש ששולח את הבקשה כלולות באסימון הגישה, באמצעות היקפי OAuth או הצהרות JWT.

אימות בקשות באמצעות תהליכים מותנים

ברמת הבסיס, קריאה ל-API בארכיטקטורת REST מורכבת מהרכיבים הבאים:

  • נקודת קצה
  • משאב
  • פועל פעולה
  • כל מספר של מאפייני בקשה נוספים, כמו פרמטרים של שאילתה

סוג המתקפה שמתואר באיום הזה נגרם בדרך כלל בגלל סינון לא מספיק של בקשת API, וכך מאפשר לתוקף לבצע פעולות לא מורשות או לגשת למשאב מוגן. בנוסף ללוגיקה מותנית שמאפשרת לכם לסנן בקשות על סמך טוקנים של גישה או טענות, Apigee מאפשרת הטמעה של לוגיקת סינון שמבוססת על הבקשה עצמה.

אחרי שמבינים ומגדירים בבירור את הלוגיקה העסקית של מוצר API, ואת הפונקציות שממשקי ה-API מאפשרים, השלב הבא הוא להגביל את כל הבקשות שלא עומדות בתנאים האלה באמצעות תכונות המוצר הבאות של Apigee:

  • לוגיקה מותנית ומדיניות Raise Fault כדי להגביל נתיבי משאבים או פעלים בכל שלב בהגדרת זרימת proxy
  • JSON ו-XML מדיניות להגנה מפני איומים כדי להגן מפני התקפות מבוססות תוכן באמצעות מטען ייעודי (payload) של בקשות JSON או XML פגומות

‫API6:2019 הקצאה המונית

תיאור האיום

נתונים לא מסוננים שמועברים דרך ממשקי API לאפליקציות לקוח מאפשרים לתוקפים לנחש מאפיינים של אובייקטים באמצעות בקשות, או להשתמש במוסכמות של שמות נקודות קצה כדי לקבל רמזים לגבי המקום שבו אפשר לבצע שינוי לא מורשה או גישה למאפיינים של אובייקטים של נתונים שמאוחסנים בקצה העורפי.

האיום הזה נוצר כשנתונים לא מסוננים (בדרך כלל בפורמט JSON או XML) נשלחים ללקוח, מה שמאפשר לתוקף לנחש את פרטי ההטמעה הבסיסיים של מערכות ה-Backend שלכם, וגם את שמות המאפיינים של רכיבי נתונים סודיים. התוצאה של סוג כזה של מתקפה עלולה לאפשר לתוקף לקרוא נתונים לא מתאימים או לבצע בהם מניפולציה, או במקרים הגרועים ביותר, לאפשר פגיעות של הרצת קוד מרחוק.

בדרך כלל יש שני היבטים שקשורים לאפשרות של סוג האיום הזה:

  • היבט עיצוב ה-API. אל תסתמכו על לוגיקה של אפליקציה כדי לבצע סינון נתונים בצד הלקוח, כי תוקפים יכולים לנצל אפליקציות ולראות בהן מקור מהימן. תמיד צריך לתכנן את סכימת הנתונים של ה-API כך שתחשוף רק את הנתונים המינימליים והנדרשים כדי להפעיל שירות API
  • היבטים שקשורים להטמעת ה-API. הטמעה של סינון נתונים ואימות סכימה כדי למנוע חשיפה לא מכוונת של נתונים סודיים לאפליקציית לקוח

מנקודת המבט של מוצר Apigee, אנחנו מספקים כמה תכונות שימושיות כדי להבטיח הטמעה חזקה של סינון נתונים בממשקי ה-API שלכם.

מדיניות הסינון של OpenAPI Specification

מדיניות 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. בנוסף, אפשר להשתמש במדיניות של אימות הודעות כדי לוודא שמטען ייעודי (payload) של הודעת JSON או XML הוא בפורמט תקין. במסגרת האימות, המערכת בודקת את הדברים הבאים בהודעת XML או JSON:

  • יש רכיב בסיס יחיד
  • התוכן לא כולל תווים לא חוקיים
  • האובייקטים והתגים מוטמעים בצורה נכונה
  • תגי הפתיחה והסגירה זהים

‫API7:2019: הגדרת אבטחה שגויה

תיאור האיום

הגדרות אבטחה שגויות הן בדרך כלל תוצאה של הגדרות ברירת מחדל לא מאובטחות, הגדרות לא מלאות או אד-הוק, אחסון בענן שפתוח לגישה, כותרות HTTP שהוגדרו בצורה שגויה, שיטות HTTP מיותרות, שיתוף משאבים בין מקורות (CORS) שמאפשר גישה רחבה והודעות שגיאה מפורטות שמכילות מידע רגיש. לעתים קרובות התוקפים מנסים למצוא פגמים שלא תוקנו, נקודות קצה נפוצות או קבצים וספריות לא מוגנים כדי להשיג גישה לא מורשית או מידע על המערכת שהם רוצים לתקוף. הגדרות אבטחה שגויות עלולות לחשוף לא רק נתוני משתמש רגישים, אלא גם פרטים על המערכת שעלולים להוביל לפריצה מלאה לשרת. בנוסף, יש עוד כמה תרחישי שימוש לנקודות חולשה בהגדרות אבטחה שגויות, למשל:

  • הגדרת TLS לא תקינה
  • הודעות שגיאה עם דוחות קריסות
  • מערכות שלא עודכנו
  • חלוניות ניהול של שרתים או של אחסון חשוף

יש כמה פעולות שארגונים יכולים לבצע כדי לטפל בבעיות שקשורות להגדרות אבטחה שגויות ולצמצם את הסיכון שלהן, כולל:

  1. הקמה של תהליכי אבטחה ותיקון חולשות והפיכתם לתקניים
  2. פיתוח מדיניות ממשל סביב מערכת האקולוגית של ממשקי ה-API
  3. הגבלת הרשאות אדמין והפעלת ביקורת והתראות

תהליכי עבודה משותפים וקטעי הוק (hooks) לזרימה

‫Apigee תומך במושג של זרימה משותפת שמאפשרת למפתחי API לשלב מדיניות ומשאבים בקבוצה שאפשר לעשות בה שימוש חוזר. הזרימה המשותפת מאפשרת לכם לתעד פונקציונליות שאפשר לעשות בה שימוש חוזר במקום אחד, וכך לשמור על עקביות, לקצר את זמן הפיתוח ולנהל את הקוד בקלות רבה יותר. אפשר לכלול תהליך משותף בתוך proxy ל-API ספציפי, או להשתמש בflow hooks כדי להציב תהליכים משותפים ולבצע באופן אוטומטי את הלוגיקה של תהליך משותף לכל proxy ל-API שנפרס באותה סביבה כמו תהליך משותף.

פיקוח על API

‫Apigee מספקת פלטפורמה מקיפה של API Monitoring. פיקוח על API מאפשר לארגונים לזהות באופן יזום בעיות בתעבורת הנתונים ובביצועים של ממשקי API. התכונה פיקוח על API של Apigee פועלת בשילוב עם Apigee Edge for 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 Parsers,‏ ORM,‏ LDAP,‏ OS Commands ו-JavaScript, לבקשות API עלולה לגרום להפעלה של פקודות לא מכוונות או לגישה לנתונים לא מורשית. התוקפים יזינו ל-API נתונים זדוניים דרך כל וקטורי ההזרקה שזמינים, כמו קלט ישיר, פרמטרים, שירותים משולבים וכו', בתקווה שהנתונים יישלחו למפענח. תוקפים יכולים לגלות את הפגמים האלה בקלות כשהם בודקים את קוד המקור באמצעות סורקי נקודות חולשה ו-fuzzers. החדרה מוצלחת עלולה להוביל לחשיפת מידע, לפגוע בסודיות ולגרום לאובדן נתונים, ובמקרים מסוימים היא עלולה גם להוביל למניעת שירות (DoS).

השיטות המומלצות לצמצום שגיאות או מתקפות של החדרת קוד כוללות הגדרה מדויקת של נתוני הקלט, כמו סכימות, סוגים, דפוסי מחרוזות, ביצוע אימות קלט, בדיקות הגבלה ואכיפה שלהן בזמן הריצה. פלטפורמת Apigee מאפשרת לאמת את הנתונים הנכנסים באמצעות מסננים, כדי לאפשר רק ערכים תקינים לכל פרמטר קלט.

‫Apigee Edge, שפועל כשרת לבקשות API נכנסות, בודק שהמבנה של מטען הייעודי (payload) נמצא בטווח מקובל, כלומר מבצע בדיקת מגבלה. אפשר להגדיר פרוקסי של API כך ששגרת אימות הקלט תמיר את הקלט כדי להסיר רצפים של תווים מסוכנים ולהחליף אותם בערכים בטוחים.

מדיניות הגנה על ביטויים רגולריים

המדיניות RegularExpressionProtection מחילה חילוץ של מידע מהודעה (לדוגמה, נתיב URI, פרמטר שאילתה, כותרת, פרמטר טופס, משתנה, מטען ייעודי (payload) של XML או מטען ייעודי (payload) של JSON) ומבצעת הערכה של התוכן הזה בהשוואה לביטויים רגולריים מוגדרים מראש. אם אחד מהביטויים הרגולריים שצוינו מחזיר את הערך True, ההודעה נחשבת לאיום והיא נדחית. ביטוי רגולרי, או regex בקיצור, הוא קבוצה של מחרוזות שמציינות תבנית במחרוזת. ביטויים רגולריים מאפשרים להעריך תוכן באופן פרוגרמטי כדי לזהות דפוסים. לדוגמה, אפשר להשתמש בביטויים רגולריים כדי להעריך כתובת אימייל ולוודא שהיא בנויה בצורה נכונה.

השימוש הנפוץ ביותר ב-RegularExpressionProtection הוא הערכה של מטען ייעודי (payload) מסוג JSON ו-XML לזיהוי תוכן זדוני.

אף ביטוי רגולרי לא יכול למנוע את כל המתקפות שמבוססות על תוכן, וצריך לשלב כמה מנגנונים כדי להפעיל הגנה מעמיקה. בקטע הזה מתוארים כמה דפוסים מומלצים למניעת גישה לתוכן.

יש עוד כמה גישות לאימות קלט שזמינות בפלטפורמת Apigee:

אימות סוגי תוכן

סוג התוכן מתייחס לתוכן של קובץ שמועבר באמצעות HTTP ומסווג לפי מבנה דו-חלקי. מומלץ ב-Apigee לאמת את סוגי התוכן של הבקשה והתגובה באמצעות לוגיקה מותנית, כמו שמוסבר בהמשך.

API9:2019 ניהול לא תקין של נכסים

תיאור האיום

ניהול לא מספק של הסביבה והפרדה לא מספקת בין הסביבות מאפשרים לתוקפים לגשת לנקודות קצה של API שלא מאובטחות מספיק. בנוסף, היעדר אמצעי הגנה לניהול גישה גורם לחשיפה מיותרת של משאבים שהוצאו משימוש.

כדי להתמודד עם האיום הזה, אפשר להשתמש ביכולות המתקדמות של Apigee לניהול מחזור החיים המלא של 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 Product. מוצרי API מוגדרים על ידי חבילות של משאבים ופעולות שמשויכים לאותו הקשר עסקי ואבטחתי (למשל, תוכנית שירות, דומיין עסקי, קטגוריה, היררכיה של חברה וכו').

באמצעות פורטל המפתחים המשולב של Apigee, אתם יכולים לפרסם מוצרי API ולהגביל את החשיפה של התוכן שפורסם על ידי ניהול קהלי היעד. היכולת הזו תואמת לאסטרטגיית פילוח תוכן שתואמת לדרישות עסקיות ולדרישות אבטחה.

קטעי הוק (hooks) לזרימה

תהליכי הקידום וההפצה של ממשקי API חייבים תמיד לכלול תהליכים של אישור ותאימות לאבטחה. כדי להשיג את המטרה הזו, צוותי API שמשתמשים בכלים המתאימים צריכים להיות מסוגלים ליצור אמצעי הגנה שמבטיחים את הפרדת האחריות, תוך שמירה על מחזורי פיתוח מהירים.

‫Apigee מאפשרת לכם להגדיר הרשאות ניהול אבטחה גבוהות יותר על ידי אכיפת מדיניות גלובלית באמצעות הוקים (hooks) לזרימה. אפשר לנהל את המדיניות הגלובלית הזו כגדרות שמירה עם הרשאות מיוחדות, שאי אפשר לשנות אותן באמצעות מפתחי API. כך מובטח הפרדה בין תחומי האחריות, וגם משפרים את הגמישות על ידי החלת אבטחת ברירת מחדל, וכתוצאה מכך, מספקים תאימות אבטחה לכל ממשקי ה-API שנפרסו בסביבת ביצוע נתונה.

איור: אפשר להגדיר אמצעי בקרה עם הרשאות מיוחדות ב-Apigee באמצעות Flow Hooks ו-Shared Flows. בעלי עניין בתחום האבטחה אחראים על תחזוקה של מדיניות גלובלית שקשורה לאבטחה. התכונות האלה מבטיחות הפרדה בין תחומי האחריות ומקדמות מחזורי חיים של פיתוח זריז.

API10:2019 Insufficient logging & monitoring

תיאור האיום

רישום לא מספיק של פעולות ביומן, מעקב והתראות מאפשרים להתקפות מתמשכות להתבצע בלי שיתגלו. לכן, צריך להגדיר אסטרטגיה לקבלת תובנות לגבי אירועים קריטיים שמשפיעים על העסק.

אלה השיטות המומלצות לניהול אירועים ורישום ביומן עבור ממשקי API:

  • מדיניות ניהול יומנים: תיעוד ואכיפה של כללים לסטנדרטיזציה ולבקרה של רמת הפירוט ביומנים, רמות היומנים, שלמות היומנים, מאגר מרכזי ועוד
  • מדיניות ניהול אירועים: כל אירוע צריך להיות ניתן למעקב עד למקור שלו. בנוסף, צריך לסווג את האירועים לפי רמת הקריטיות וההשפעה העסקית שלהם
  • דוחות וביקורות: בעלי עניין בתחום האבטחה והתפעול צריכים להיות מסוגלים לגשת ליומנים ולאירועים בזמן אמת ולהגיב להם. בנוסף, בעלי עניין יכולים לבצע מחזורי חיזוק כדי להתאים את דפוסי הזיהוי על סמך נתונים היסטוריים.

‫Apigee מספק את הכלים הנדרשים ליצירת אסטרטגיה מקיפה לניהול אירועים ורישום ביומן. הכלים אלה כוללים:

הודעה מדיניות רישום ביומן: יצירת זרמי יומן על סמך נתוני תנועה או מטא-נתונים מתנועת ה-API. אתם יכולים להגדיר את רמת הפירוט של הנתונים בזרם באמצעות לוגיקה מותנית ותבניות של הודעות.

‫Google’s Cloud Operation Suite: אפשר להשתמש בשילוב המובנה עם כלי ניטור ורישום ביומן של Google, שניתנים להרחבה בקלות.

מדיניות בנושא קריאות ל-Service Callout: נוספה תמיכה בזרמי יומנים שנדרשות להם נקודות קצה (endpoint) של HTTP כדי לשלוח אירועים.

‫Analytics: גישה למטא-נתונים היסטוריים של תנועת הגולשים וניתוח שלהם באמצעות דוחות מוכנים לשימוש ו/או דוחות בהתאמה אישית. ליצור ולנהל התראות על סמך מגמות ולהבין אנומליות בתנועה.

פיקוח על API: כמו שמתואר למעלה, הכלי הזה מספק יכולות התראה שאפשר להפעיל אותן על סמך אירועים קריטיים. אפשר לנתח את יומני התנועה ולפעול בהתאם.