TL; DR
רוב פרצות ה-API נובעות מהרשאה שבורה, ולא מהתפרצויות אקזוטיות. שלוש מתוך חמש הקטגוריות המובילות של עשרת ה- OWASP API Security Top 10 הן כשלים בהרשאות, בהובלת בולה.
אי אפשר לאבטח את מה שלא יודעים שקיים. ניהול מלאי לא תקין היא קטגוריית סיכון OWASP משלה, והיא הבסיס שעליה תלויה כל בקרה אחרת.
לתפוס חשיפה לפני הפריסה, לא אחריה. ניתוח סטטי של קוד ומפרטי API מוצא נקודת קצה פגומה ב-a pull request, בעלות של אחד commitבדיקות זמן ריצה מוצאות את אותה בעיה בזמן אמת, במחיר של אירוע.
זוהי רשימת תיוג שיש להפעיל באופן רציף. על כל pull request, לא סקירה טרום-השקה: 10 אימונים, החל ממלאי והרשאה ועד להגבלת קצב, חשיפת נתוני תגובה ואמון עם צד שלישי.
משטח התקיפה של ה-API שלך גדל עם כל pull requestרוב הצוותים מגלים שנקודת קצה נחשפת רק לאחר שהיא פעילה וסופגת תנועה, מה שאומר שהתיקון היה עולה לאדם אחד. commit "בסקירה כעת עולה דוח תקרית." מדריך זה עובר על שיטות עבודה מומלצות לאבטחת API אשר באמת תקפות בסביבת ייצור, מאורגן כרשימת בדיקה שתוכלו להריץ מול בסיס הקוד שלכם כיום, ולא רשימה של עקרונות מופשטים שאף אחד לא מיישם.
מדוע שיטות עבודה מומלצות לאבטחת API נראות שונות כעת
ממשקי API היו בעבר רקמת החיבור בין מערכות. כיום הם הממשק העיקרי כמעט לכל דבר: אפליקציות מובייל, אינטגרציות שותפים, סוכני בינה מלאכותית, מיקרו-שירותים פנימיים. שינוי זה שינה את מה ששיטות העבודה המומלצות להגנה על API צריכות לכסות. זה כבר לא מספיק לאבטח את ה-API שתיעדת; אתה צריך לתת דין וחשבון על אלה שהצוותים שלך בנו ושכחו לרשום.
שני מספרים מסבירים מדוע זה חשוב. OWASP API Security Top 10 ממקם בעיות של הרשאות פגומות בשלוש מתוך חמש הקטגוריות המובילות שלו, כלומר רוב אירועי ה-API בעולם האמיתי נובעים מקומץ דפוסים שניתן למנוע, ולא מ-zep-days אקזוטיים. וניהול מלאי לא תקין נמצא באותה רשימה כמו קטגוריית סיכון משלו: צוותים נפרצים דרך ממשקי API שלא ידעו שעדיין פועלים.
זהו הנושא העובר בכל סעיף למטה. שיטות עבודה מומלצות לניהול API מתחילות בידיעה מה יש לך, לא רק בהגנה על מה שזכרת לתעד.
סקירה כללית של שיטות עבודה מומלצות לאבטחת API
לפני רשימת הבדיקה המפורטת, הנה הגרסה הקצרה: מה ליישם, מפני מה זה באמת מגן, ובאיזו דחיפות.
התייחסו לשורה "נדרש" כקו בסיס שאינו ניתן למשא ומתן עבור כל API, פנימי או פונה לציבור. פריטי העדיפות "גבוהה" הם מה שמבדיל תוכנית שתופסת בעיות ב... pull request מאחד שמגלה זאת בדוח אירוע.
רשימת בדיקה של שיטות עבודה מומלצות לאבטחת API
1. בנה מלאי מלא לפני שאתה בונה הגנה
אינך יכול להגן על נקודת קצה שאתה לא יודע שקיימת. התחיל כל מאמץ של שיטות עבודה מומלצות להגנה על API עם רשימת מלאי אמיתית: כל נקודת קצה, השיטה שלה, הנתיב שלה, השירות והמודול אליהם היא שייכת, והאם היא דורשת אימות. בדוק זאת מקוד המקור וממפרטי ה-API שלך (OpenAPI, Swagger) יחד, לא מתיעוד בלבד, מכיוון שהפער בין השניים הוא בדיוק המקום שבו מסתתרות נקודות קצה נשכחות ויתומות.
היכן Xygeni מתאים: אבטחת API של Xygeni בונה את המלאי הזה ישירות מקוד המקור של האפליקציה וממפרטי ה-API שלך, וחושף את נקודות הקצה שהצוות שלך תיעד ואת אלה שאף אחד לא תיעד, לפני שאף אחת מהן מגיעה לייצור.
2. אכיפת הרשאה ברמת האובייקט והפונקציה
הרשאות פגומות ברמת האובייקט וברמת הפונקציה נמצאות באופן עקבי בראש רשימת עשרת קטגוריות האבטחה המובילות של OWASP API. הנוהג המומלץ אינו "הוספת אימות", אלא בדיקה, בכל בקשה, האם המשתמש הספציפי הזה מותר לגשת האובייקט הספציפי הזה, לא רק האם הם בכלל מחוברים. אימות עונה על השאלה מיהו מישהו. הרשאה עונה על השאלה במה מותר להם לגעת, ויש לבדוק זאת בכל פעם, לא להניח זאת מטוקן תקף.
3. אימות וחיטוי של כל מה שה-API מקבל
כל פרמטר, כותרת ושדה גוף נחשבים לקלט לא אמין עד שיוכח אחרת. יש לאכוף אימות סכימה קפדני, לדחות שדות בלתי צפויים (זוהי ההגנה שלך מפני הקצאה המונית), ולעולם לא לסמוך על נתונים המסופקים על ידי הלקוח כדי לקבוע את היקף הגישה או לוגיקת התמחור.
4. הגבלת קצב ומצערת מתוכננים, לא כמחשבה שלאחר מעשה
צריכת משאבים בלתי מוגבלת מאפשרת ללקוח יחיד להתיש את התשתית שלך או להגדיל עלויות על שירותי backend בתשלום לפי שימוש. קבע מגבלות לכל נקודת קצה, לכל משתמש ולכל מפתח API, וודא שהמגבלות מתאימות לעלות בפועל של הפעולה, ולא למספר קבוע שמוחל בכל מקום.
5. התייחסו לכל תגובה כדליפת נתונים פוטנציאלית
חשיפת נתונים מוגזמת מתרחשת כאשר ממשק API מחזיר יותר ממה שהלקוח צריך ומסתמך על ממשק הקצה כדי לסנן אותו. זהו הרגל, לא טעות נדירה, וזו אחת מהפרות הנפוצות ביותר של שיטות עבודה מומלצות להגנה על ממשק API מכיוון שהוא בלתי נראה עד שמישהו בודק תגובות גולמיות במקום את ממשק המשתמש המעובד.
היכן Xygeni מתאים: אבטחת ה-API של Xygeni מסמנת חשיפה ל-PII ישירות בתגובות ה-API, ומזהה שיתוף יתר לפני המשלוח במקום לאחר שלקוח או רגולטור שמים לב.
6. שמרו על מלאי מדויק ועדכני של API, כולל אלו שהוצאו משימוש
לא תקין מלאי ניהול הוא קטגוריה משלו ברשימת OWASP מסיבה מסוימת: גרסאות API שהוצאו משימוש וסביבות staging לא מתועדות עדיין נגישות לעתים קרובות, ולעתים קרובות עדיין פגיעות, הרבה אחרי שמישהו זוכר שהן קיימות. תוכנית שיטות עבודה מומלצות לניהול API צריכה לכלול הוצאה משימוש, לא רק גילוי.
7. בדקו היטב את מה שה-API שלכם נותן אמון מצדדים שלישיים
צריכה לא בטוחה של ממשקי API של צד שלישי היא סיכון שלא מוערך מספיק. מפתחים נוטים לסמוך על נתונים המגיעים מ-API אחר יותר מאשר על קלט משתמש, וזה בדיוק הפוך; אינטגרציה של צד שלישי היא עדיין מקור חיצוני ולא מאומת ויש לאמת אותה באותו אופן.
8. הציבו ראיות בפני המפתחים, לא רק התראות
ממצא שאומר "הרשאה שבורה בנקודת קצה זו" הוא כרטיס שמישהו צריך לחקור לפני שהוא יכול אפילו להתחיל לתקן אותו. ממצא שמצביע על הקובץ, המחלקה, המתודה והשורה המדויקים הוא משהו שמפתח יכול לפעול עליו באופן מיידי. זוהי שיטת עבודה מומלצת עבור תוכנית האבטחה עצמה, לא רק עבור ה-API: ממצאים הדורשים חקירה לפני תיקון מאטים את הכל.
היכן Xygeni מתאים: כל ממצא של אבטחת ה-API של Xygeni מצביע על המטפל, הקובץ, המחלקה, המתודה והשורה שהציגה אותו המדויקים, כך שהתיקון מתחיל ברגע שהממצא מגיע.
9. מצא חשיפה לפני הפריסה, לא אחריה
בדיקות API בזמן ריצה מראות לך שנקודת קצה חשופה ברגע שהיא כבר משרתת תעבורה. ניתוח סטטי של קוד ומפרטי API מוצא את אותה חשיפה בזמן שהיא עדיין נמצאת ב- pull request, כאשר התיקון עולה אחד commit במקום תגובה לאירוע. שיטות העבודה המומלצות ביותר לניהול API מתייחסות לגילוי סטטי כשכבה הראשונה, כאשר בדיקות זמן ריצה הן בדיקה שנייה ומשלימה של מה שכבר קיים.
היכן Xygeni מתאים: אבטחת ה-API של Xygeni היא סטטית מעצם עיצובה, מנתחת קוד ומפרטים לפני השחרור, ועובדת לצד קסיגני DAST לכיסוי בזמן ריצה של יישומים שכבר נמצאים בתהליכי ייצור.
10. שמרו על סיכון ה-API באותו מקום כמו שאר סיכוני האפליקציה שלכם.
ממשקי API אינם נכשלים בנפרד. פגיעות ב-API נמצאת לעתים קרובות במורד הזרם של בעיית תלות, הגדרה שגויה pipeline, או סוד שדלף. התייחסות לאבטחת API ככלי נפרד עם קונסולה משלו פירושה אובדן ההקשר הזה בדיוק כשהדבר הכי חשוב.
היכן Xygeni מתאים: אבטחת API יושבת לצד SAST, SCAסודות, IaCו-DAST בפלטפורמת Xygeni אחת, כך שממצא API גלוי ליד הקוד וסיכון התלות שיצרו אותו, לא בנפרד. login.
הפיכת רשימת הבדיקה להרגל
שיטות עבודה מומלצות לאבטחת API פועלות רק כנוהג מתמשך, לא כסקירה טרום-השקה. הפעל ניתוח מלאי וניתוח סטטי על כל pull request, לא פעם ברבעון. התייחסו לנקודת קצה חדשה ולא מתועדת באותו אופן שבו הייתם מתייחסים לתלות חדשה ולא מתועדת: כמשהו שיש לחקור באופן מיידי, לא בסופו של דבר. ומדדו את שיטות העבודה המומלצות שלכם להגנה על ה-API באותו אופן שבו אתם מודדים כל חלק אחר של SDLC, לפי כמה מוקדם אתה מגלה את הבעיה, לא רק אם בכלל גילית אותה.
תשובות מהירות: שאלות ותשובות על שיטות עבודה מומלצות לאבטחת API
המנות העיקריות
- מלאי בא לפני הגנה. אינך יכול להחיל הרשאות, מגבלות קצב או בקרות נתונים על נקודת קצה שאינך יודע על קיומה, וניהול מלאי לא תקין הוא סיכון בפני עצמו ברשימת 10 הבחינות המובילות של אבטחת API של OWASP.
- הרשאה, ולא רק אימות, היא המקום שבו מתרחשות רוב הפריצות. שלושה מתוך חמשת סיכוני האבטחה המובילים של OWASP API הם כשלים בהרשאות. בדיקת מיהו מישהו אינה זהה לבדיקת מה מותר לו לגעת.
- ניתוח סטטי לוכד את מה שבדיקות זמן ריצה לוכדות מאוחר מדי. מציאת חשיפה ב- pull request עולה אחד commitמציאתו בעלויות הייצור היא תקרית.
- כל תגובה היא דליפת נתונים פוטנציאלית. חשיפה מוגזמת לנתונים היא הרגל, לא טעות נדירה, והיא בלתי נראית עד שמישהו בודק תגובות API גולמיות במקום את ממשק המשתמש המעובד.
- שיטות עבודה מומלצות לאבטחת API עובדות רק כהרגל מתמשך, לרוץ על כל pull request, לא סקירה רבעונית או רשימת בדיקה לפני השקה.
- סיכון API לא צריך להיות בכלי נפרד. שיטות העבודה המומלצות ביותר להגנה על API מתייחסות לממצאי API כחלק מאותה תמונת סיכונים כמו קוד, תלות ו... pipeline security, לא קונסולה מבודדת.
שאלות נפוצות
מהן שיטות העבודה המומלצות ביותר לאבטחת API שכדאי להתחיל איתן?
התחילו עם מלאי. אינכם יכולים להחיל בדיקות הרשאה, מגבלות קצב או בקרות חשיפת נתונים על נקודת קצה שאינכם יודעים על קיומה, לכן מלאי מלא ומדויק של כל נקודת קצה של API הוא הבסיס שכל שאר הרשימות ברשימת בדיקה זו תלויות בו.
מה ההבדל בין שיטות עבודה מומלצות לאבטחת API לבין שיטות עבודה מומלצות לאבטחת יישומים כלליים?
ממשקי API מציגים סיכונים ששיטות כלליות של AppSec אינן מכסות במלואן: הרשאה ברמת אובייקטים ופונקציות בקנה מידה גדול, הסכנה הספציפית של אמון בתגובות API של צד שלישי, והאתגר של מעקב אחר נקודות קצה מיושנות או לא מתועדות. שיטות עבודה מומלצות לאבטחת API הן שיטות עבודה מומלצות לאבטחת יישומים, המיושמות על החלקים של משטח התקיפה שהכי קל לשכוח.
האם בדיקות אבטחה של API צריכים להתבצע לפני או אחרי הפריסה?
שניהם, אבל נקודת המינוף הגבוהה ביותר היא לפני כן. ניתוח סטטי של קוד ומפרטי API חושף את החשיפה בזמן שהוא עדיין... pull requestבדיקות זמן ריצה (DAST) מאמתות את מה שבאמת נגיש לאחר שהאפליקציה מופעלת. הסתמכות על בדיקות זמן ריצה בלבד פירושה שכל תיקון עולה יותר ממה שהיה צריך.
באיזו תדירות יש לעדכן מלאי של API?
באופן רציף, באופן אידיאלי על כל pull requestמלאי שנבנה פעם אחת ונבדק רבעוני כבר אינו מעודכן ברגע שנקודת קצה חדשה נשלחת, וזה בדיוק הפער שניהול מלאי לא תקין מנצל.
האם שיטות עבודה מומלצות לניהול API חלות על ממשקי API פנימיים, ולא רק על אלו הפונים לציבור?
כן. ממשקי API פנימיים לרוב מוגבלים ברמת אבטחה נמוכה יותר מכיוון שהם "אינם חשופים לאינטרנט", אך הם עדיין מטפלים במידע רגיש ועדיין נגישים לכל מי שיש לו גישה לרשת פנימית, כולל חשבון פרוץ או גורם פנימי.
