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

כרגע מוצג התיעוד של Apigee Edge.
כניסה למסמכי התיעוד של Apigee X. מידע

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

מבוא

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

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

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

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

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

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

תיאור האיום

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

API2:2019 לא עובד עם אימות משתמשים

תיאור האיום

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

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

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

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

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

תכנון אבטחה

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

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

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

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

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

ניהול טראפיק

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

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

ניהול

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

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

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

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

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

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

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

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

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

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

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

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

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

Apigee Sense

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

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

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

פעולות API מתקדמות

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

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

API מתקדם Ops משתמש במנגנון ההתראות הקיים של API Monitoring כדי להוסיף את סוגי ההתראות המתקדמים הבאים:

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

API3:2019 חשיפה מופרזת של נתונים

תיאור האיום

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

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

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

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

בקטעים הבאים נבחן את הנושאים הבאים:

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

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

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

לשם כך, ב-Apigee משתמשת בשלושה כללי מדיניות עיקריים:

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

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

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

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

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

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

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

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

  • ליצור או לשנות ערכים מורכבים של גוף ההודעה, כמו ערכים של בקשות ותגובה.
  • שכתוב כתובות URL, למשל, כדי לבצע אנונימיזציה של כתובת URL של נקודת קצה (endpoint) של יעד.

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

טיפול בכשלים

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

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

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

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

תיאור האיום

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

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

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

הגבלת הקצב של יצירת הבקשות לפי המדיניות בנושא מכסות ו-Spke Arrest

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

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

מעקה ספייק

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

מכסות

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

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

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

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

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

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

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

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

תיאור האיום

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

סוג ההתקפה שמתואר באיום הזה נגרם בדרך כלל בגלל סינון לא מספיק של בקשת API, וכך מאפשר לתוקפים לבצע פעולות לא מורשות או לגשת למשאב מוגן. בנוסף ללוגיקה של תנאים, שמאפשרת לסנן בקשות לפי אסימוני גישה או הצהרות על זכויות יוצרים, ב-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 Specification Validation) מאפשרת לאמת בקשה או הודעת תגובה נכנסות מול מפרט OpenAPI 3.0 (JSON או YAML). המדיניות הזו מאפשרת:

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

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

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

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

הגדרה שגויה של אבטחה ב-API7:2019

תיאור האיום

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

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

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

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

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

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

דוחות אבטחה של API

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

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

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

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

מעקב באמצעות API

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

איור: Apigee API Monitoring מספק מגוון רחב של כלים למעקב אחר בעיות, לחקירה ולטיפול בהן. היא משתמשת בתכונות הבינה המלאכותית של Google Cloud Platform.

Apigee Sense

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

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

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

API8:2019 הזרקה

תיאור האיום

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

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

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

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

המדיניות RegularExpressionProtection מחלצת מידע מהודעה (לדוגמה, URI Path, Query Param, Header, Form Param, Variable, XML Payload או JSON Payload) ומבצעת הערכה של התוכן לפי ביטויים רגולריים מוגדרים מראש. אם ביטוי רגולרי מסוים מוגדר כ-true, ההודעה תיחשב כאיום והיא תידחה. ביטוי רגולרי (regex) הוא קבוצה של מחרוזות שמציינות דפוס במחרוזת. ביטויים רגולריים מאפשרים לבצע הערכה פרוגרמטית של תוכן כדי לאתר דפוסים. אפשר להשתמש בביטויים רגולריים, למשל, כדי להעריך כתובת אימייל על מנת לוודא שהיא בנויה כראוי.

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

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

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

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

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

דוחות אבטחה של API

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

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

API9:2019 ניהול נכסים בלתי הולם

תיאור האיום

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ניהול קהלים לתיעוד API

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

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

ווי הזזה

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

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

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

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

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

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

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

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

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

API10:2019 אין מספיק רישום ביומן ומעקב

תיאור האיום

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

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

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

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

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

חבילת התפעול של Google ב-Cloud: הפקת המרב מהשילוב המקורי של כלים של Google למעקב ולרישום ביומן.

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

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

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