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

אתם צופים במסמכי העזרה של Apigee Edge.
כניסה למסמכי העזרה של Apigee X. info

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

מבוא

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

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

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

API1:2019 הרשאה לא תקינה ברמת האובייקט

תיאור האיום

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

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

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

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

תקינות של אסימון גישה

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

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

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

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

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

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

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

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

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

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

API2:2019 אימות משתמש שגוי

תיאור האיום

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

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

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

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

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

תכנון אבטחה

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

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

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

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

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

ניהול תנועה

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

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

ניהול

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

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

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

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

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

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

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

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

דיווח על אבטחה

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

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

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

אחרי שה-APIs יהיו בסביבת הייצור עם דפוסי האימות הנכונים וניהול תנועה בסיסי, צוות 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.

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

  • סה"כ התראות על מצב התנועה. שליחת התראה כשיש שינוי של אחוז מסוים בתנועה בטווח זמן מסוים. לדוגמה, אפשר להגדיר התראה כשנפח התנועה עולה ב-5% או יותר לשעה, או יורד ב-10% או יותר בשבוע.
  • התראות על אנומליות. Edge מזהה בעיות שקשורות לתנועה ולביצועים, במקום שתצטרכו לקבוע אותן מראש בעצמכם. לאחר מכן תוכלו להפעיל התראה לגבי החריגות האלה.
  • התרעות על תפוגת תוקף של TLS. שליחת התראה כשתוקף אישור ה-TLS עומד לפוג

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

תיאור האיום

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

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

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

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

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

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

שכתוב של תגובות ובקשות

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

לשם כך, Apigee משתמשת בשלושה כללי מדיניות מפתח:

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

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

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

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

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

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

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

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

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

ב-Apigee Edge יש מדיניות נפרדת לכל שפה נתמכת: מדיניות JavaScript, מדיניות Callout של Java ומדיניות סקריפט של Python.

טיפול בכשלים

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

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

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

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

תיאור האיום

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

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

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

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

ב-Apigee יש שתי מדיניות להגבלת קצב שליחת הבקשות:

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

Spike Arrest

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

מכסות

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

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

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

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

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

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

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

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

תיאור האיום

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

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

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

  • מה מוגן? חשוב לחשוב על האסטרטגיה של מוצרי ה-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 וטענות נכונות (claims) של JWT

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

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

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

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

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

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

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

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

API6:2019 הקצאה בכמות גדולה

תיאור האיום

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

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

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

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

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

מדיניות סינון של מפרט OpenAPI

המדיניות OASValidation (אימות של מפרט OpenAPI) מאפשרת לאמת בקשה או הודעת תגובה נכנסות בהתאם למפרט OpenAPI 3.0 (JSON או YAML). המדיניות הזו מאפשרת לכם:

  1. עיצוב ה-API באמצעות יצירת מפרט OpenAPI ‏ (OAS)
  2. איך מטמיעים את הלוגיקה הנדרשת של תהליך בחירת הרשת (Mediation), האבטחה והאחסון במטמון כדי לחשוף בצורה מאובטחת מוצר API מהקצה העורפי באמצעות Apigee
  3. אימות הבקשות הנכנסות בהתאם לסכימה של הנתונים שמוגדרת במפרט ה-OAS, כולל basepath,‏ verb,‏ request message policy וparameters

המדיניות בנושא אימות הודעות SOAP

מדיניות האימות של הודעות SOAP מאפשרת לאמת בקשות שמבוססות על XML. לשם כך, אפשר לאמת הודעת XML מול הסכימה של XSD או לאמת הודעת SOAP מול הגדרת WSDL. בנוסף, אפשר להשתמש במדיניות האימות של הודעות כדי לוודא שהמטען של הודעה בפורמט JSON או XML תקין. האימות כולל את הפעולות הבאות בהודעה בפורמט XML או JSON:

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

API7:2019 Security misconfiguration

תיאור האיום

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

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

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

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

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

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

דוחות על אבטחת API

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

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

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

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

מעקב אחר 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
  • שיעורי שגיאות חריגים
  • בקשות חשודות מלקוחות
  • סריקה של נתונים
  • איסוף מפתחות
  • פעילות קצרה
  • דפוסים גיאוגרפיים

הזרקה מסוג API8:2019

תיאור האיום

הזרקה לא מהימנה של נתונים, כמו SQL,‏ NoSQL,‏ XML Parsers,‏ ORM,‏ LDAP,‏ OS Commands ו-JavaScript, לבקשות API עלולה לגרום להפעלה של פקודות לא רצויות או לגישה לא מורשית לנתונים. תוקפים יטמיעו ב-API נתונים זדוניים דרך כל וקטור ההזרקה שזמין, כמו קלט ישיר, פרמטרים, שירותים משולבים וכו', בתקווה שהם יישלחו למפרש. תוקפים יכולים לגלות את הפגמים האלה בקלות כשהם בודקים את קוד המקור באמצעות סורקי נקודות חולשה ו-fuzzers. הזרקה מוצלחת עלולה לגרום לחשיפת מידע שתשפיע על הסודיות ועל אובדן הנתונים, או במקרים מסוימים גם להתקפת מניעת שירות (DoS).

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

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

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

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

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

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

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

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

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

דוחות על אבטחת API

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

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

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

תיאור האיום

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

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

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

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

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

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

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

ארגונים וסביבות

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

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

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

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

בקרת גישה מבוססת-תפקיד

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

ניהול קהלים במסמכי התיעוד של ה-API

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

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

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

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

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

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

דיווח על אבטחה

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

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

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

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

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

API10:2019 Insufficient logging & monitoring

תיאור האיום

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

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

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

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

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

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

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

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

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