כל היישומים כיום משתמשים בדרך כזו או אחרת בממשקי API (קריאות ל  kernel, SDK’s, ספריות הצפנה ו-SOAP) וזה לא דבר חדש. מה שהיצרנים מכנים אבטחת API כיום מתייחס דווקא לווריאציה שונה של שימוש בממשקי API אלה – אלו שנחשפים ברשת הארגון. מעצם טבעם, ממשקי API החשופים לרשת הארגונית, מאפשרים זרימה חופשית של מידע ואינטראקציה בין רכיבי תוכנה. לתוקפים יש הזדמנויות חדשות לשבש ולנטרל את הרכיבים האלה של המערכות שלך עם חשיפה של נקודות קצה  (EndPoints) לרשתות ציבוריות,  ענן ורשתות פרטיות. אך לא מזמן היינו עדים לפירצות משמעותיות בכמה חברות ידועות (USPS, T-Mobile ו-Salesforce ועוד… ) פירצות שנבעו מחשיפה או שימוש בנקודות קצה לא מאובטחות של API. זה מעלה את השאלה, כיצד תדע אם תהליך אבטחת התוכנה שלך מתייחס לפקדים הדרושים לך כדי להבטיח שממשקי ה- API שבהם אתה משתמש ומייצר מאובטחים? כדי לענות על שאלה זו, תחילה עליך להגדיר כנושא התייחסות:  אבטחת API.

אז מהי בדיוק 'אבטחת API'?

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

 אוקי, הבנו, אז איך מטפלים באבטחת API

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

שילוב ממשקי API

ממשקי API נחלקים לשניים, Front-end clients  כגון דפדפנים, ו Back-end systems  המסמל בעיקר שרתים או קומפוננטות כאלו ואחרות. בהמשך, נקודת קצה אחת של API עשויה בסופו של דבר לשרת שילוב של בקשות  Front-End ו  Back-end כאחד. כאשר נקודות קצה בודדות של API נחשפות למגוון התקשרויות ידועות ובלתי ידועות (כשהן מזינות במידע גופים חיצוניים או נקראות על ידי כלים שמאזנים עומסים), קשה עד בלתי אפשרי לקבוע אילו בקרות אבטחה על נקודת קצה של API בודדת עלינו לאכוף. הפעולה הנכונה לנקוט כאן היא להנחות את שני הקצוות של ה  API לתעד כל פעולה ולקחת אחריות גם אם אתה הצד שצורך את המידע או לחילופין הצד שמספק את המידע, שני הצדדים קשורים ביחד באחריות.

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

בקרות אבטחת מידע

בנוגע לבקרות אבטחה, קיימות מספר שכבות של טיפול באבטחת API: בקרות בתוך הלוגיקה העסקית – Business logic כגון אימות משתמשים ומתן הרשאות מתאימות ולבסוף בקרות אבטחה של ארכיטקטורה המופעלות או מוגדרות על-ידי הארכיטקטורה (API, micro-segmentation).

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

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

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

תכולה

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

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

בדיקות אבטחת מידע

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

Static analysis tools , אשר יעילים בזיהוי בעיות אבטחת תוכנה ספציפיות לשפות , תיכנות, או סוגים מובנים היטב של התקפות injections  כגון sql injection or css, ממשיכים להיות יעילים נגד בסיסי קוד עם שימוש מסיבי של API, אך רק אם כלים אלה גם מדגימים את הספריות והפלטפורמות המשמשות לחשיפת נתיבי API אלה. כלי ניתוח קוד סטטיים מעולם לא עשו עבודה נהדרת בגילוי פגמים בלוגיקה עסקית. פרויקטים כבדי API דורשים יכולת חשיבה חוצת-קודים שמחריפה עוד יותר את הפער הזה. כלי ניתוח סטטיים הם עדיין כלי חשוב בארגז הכלים, אך מנהלי אבטחת מידע צריכים לקחת על עצמם להעריך את יכולתו של כלי למצוא פגמים בקוד שנכתב עם פלטפורמות ה-API הפופולריות ביותר של הארגון שלהם. למרבה המזל, ארגונים שאימצו גישות ניתוח סטטיות כדי להניע את האימוץ של בקרות אבטחה (כגון שימוש בספריות אימות והרשאות) יגלו שהאסטרטגיות שלהם עדיין פועלות עבור אבטחת API.

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

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