מאת: סורין בויאנגיו, Solution Architect לדרום אירופה ב-F5.
אם אתה מבולבל ולא יכול להחליט, זה בסדר. זו הנקודה. נקודות הקצה של האפליקציה וה-API נראות די זהות. הסיבה לכך היא שבמונחים טכניים אם הם RESTful (ורובם כך) הם מופעלים באותו אופן, באמצעות HTTPS ובדרך כלל בשיטת GET. מה ששונה לעתים קרובות הוא הpayload שנשלח עם הבקשה. עבור ממשקי API שמכילים בדרך כלל נתונים מסוימים בפורמט JSON או XML בעוד שבקשות לאפליקציית אינטרנט עשויות להכיל, ובכן, כלום. ובכל זאת, אחד הממצאים המרכזיים מדו"ח אסטרטגיית האפליקציות השנתי של F5 מרמז שארגונים מתייחסים לממשקי API כשונים מאפליקציות בכל הנוגע לאבטחה. אנו מסיקים זאת על סמך הממצא של-41% מהארגונים יש לפחות מספר זהה או גדול יותר של ממשקי API מאשר לאפליקציות, ובכל זאת מייחסים ערך נמוך יותר לאותם שירותי אבטחה שמגנים עליהם.
אתה עשוי לתהות איך ארגונים יגלו יותר ממשקי API מאשר אפליקציות. תודה ששאלת! בעוד שממשקי API המשמשים לתקשורת פנימית בין שירות לשירות (microservices) בהחלט קשורים בקשר הדוק לשירות שהם תומכים בהם, זה לא בהכרח נכון כאשר משתמשים בממשקי API להצגת ממשקים חיצוניים.
מאיפה מגיעים ממשקי API?
קחו בחשבון שבמחקר שלנו משנת 2021, 61% מהמשיבים אמרו לנו שהם "מוסיפים שכבה של ממשקי API כדי לאפשר ממשקי משתמש מודרניים" כשיטת מודרניזציה. בשנת 2022 המספר הזה היה 45%. המשמעות היא שממשקי ה-API המאפשרים ממשקי משתמש מודרניים אינם בהכרח חפצים המחוברים ישירות לאפליקציות. אלה עשויים להיות חזיתות המאפשרות ממשקי משתמש ויישומים מודרניים, כמו אפליקציות ניידות ושירותים דיגיטליים, או שהן עשויות להיות חזיתות שנועדו לאפשר תקשורת בין שותפים ושרשרת אספקה. מקרי שימוש אלו נתמכים על ידי API Gateways וניתוב שכבה 7 במאזני עומסים, אשר לרוב מספקים רמה מסוימת של יכולות טרנספורמציה המאפשרות להם לתרגם מנקודת קצה API לנקודת קצה של אפליקציה, ובכך לאפשר חזית API כמו אלה שגורמות לבניינים ישנים במערב אמריקאיים להופיע. הרבה יותר מרשימים מהם.
וכמובן, מספר לא מבוטל של ממשקי API הם ישויות אשר מספקים שירותים חיצוניים המחוברות לאפליקציות וניגשים אליהן דרך האינטרנט (בדרך כלל HTTPS).
לא משנה איך הם הגיעו לשם, ממשקי API החיצוניים, נתונים להרבה מאותן התקפות כמו האםליקציות. זה נכון במיוחד כאשר מעורבים בוטים, שכן ממשקי API עם תיעוד טוב פשוט מקלים על התוקפים לבצע סקריפטים של התקפות בקנה מידה.
לדוגמה, קצת יותר מ-13% מטרנזקציות המוגנות על ידי F5 Distributed Cloud Bot Defense בשנת 2023 היו אוטומטיות. כלומר, נעשה שימוש בסקריפט או בתוכנה במקום באדם באמצעות דפדפן אינטרנט או אפליקציה לנייד. ארנזקציות אלו מתרחשות הן באמצעות ממשקי API והן באמצעות אפליקציות. חלק מהעסקאות האוטומטיות הללו היו בהחלט "בוטים רעים" שנוכחות פתרון האבטחה מנעה מהם לעשות כל דבר רע שהם ניסו לעשות.
לכן, כאשר הסתכלנו על האופן שבו המשיבים בדו"ח תופסים את ניהול הבוטים על סמך מספר ה-API שדווח, הופתענו לגלות שניהול הבוטים די נמוך בסולם החשיבות.
בעוד שנראה שהחשיבות המיוחסת לשערי API מתאימה למספר ממשקי ה-API המנוהלים, הדבר אינו נכון לגבי ניהול בוטים. למעשה, זה לגמרי הפוך! ככל שמספר ממשקי ה-API גדל, נראה שחשיבות ניהול הבוטים יורדת במהירות.
בהחלט יכול להיות שחלק הארי של ממשקי ה-API הללו הם פנימיים. כלומר, הם ממשקי API east – westבין microservices שאינם חשופים לגורמים חיצוניים שעלולים להיות בוטים רעים עם כוונות זדוניות. אבל בהתבסס על כמות הפרצות בשנה אחרונה אשר בוצעו דרך APIים יכול להיות שהם לא תמיד כל כך פנימיים.
אז, הגיע הזמן להזכיר לאנשים שבעוד שיש מספר בוטים מעצבנים בחוץ, שמשבשים את העסקים על ידי יצירת ביקוש גבוה לסחורות, יש גם מספר לא מבוטל של בוטים שמטרתם היחידה. זה לרחרח נקודות תורפה ולתקוף אותן. גם בממשקי API וגם באפליקציות.
לפיכך, יהיה זה רעיון טוב עבור ארגונים להפעיל מגוון רחב של אפשרויות אבטחה כדי להגן על ממשקי ה-API שלהם ובסופו של דבר, על העסק שלהם. ניהול בוטים הוא ללא ספק אחת מאותן אפשרויות אבטחה וצריך להתייחס אליו כמרכיב קריטי בכל אסטרטגיית אבטחה.
בסופו של יום, לבוטים לא אכפת אם נקודת הקצה הזו שייכת לאפליקציה או ל-API. הם הולכים לתקוף את שניהם. מה שאומר שארגונים צריכים להגן גם על אפליקציות וגם על ממשקי API על ידי זיהוי בוטים ולמנוע מהם לעשות כל דבר רע שהם מנסים לעשות.