כיצד AI ישפר את אבטחת ה- API

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

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

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

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

אמצעי אבטחה מבוססי כללים ומדיניות

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

בדיקות אבטחה סטטיות

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

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

בדיקות אבטחה דינמיות

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

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

אימות

אימות עוזר לשערי API לזהות כל משתמש שמפעיל API באופן ייחודי. פתרונות שער API זמינים תומכים בדרך כלל באימות בסיסי, אבטחת OAuth 2.0, אבטחת JWT (JSON Web Token) ואבטחה מבוססת אישורים. שערים מסוימים מספקים גם שכבת אימות נוסף על כך לאימות הרשאות עדין נוסף, המבוסס בדרך כלל על שפות הגדרת מדיניות בסגנון XACML (eXtensible Access Control Markup Language). זה חשוב כאשר ממשק API מכיל מספר משאבים הזקוקים לרמות שונות של בקרת גישה עבור כל משאב.

מגבלות אבטחת ה- API המסורתית

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

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

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

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

המקרה להוספת שכבת אבטחה של AI

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

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

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

שילוב אבטחת API מבוססת מדיניות ומונע AI

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

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

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

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

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

אתגרי שכבת אבטחה מונעי AI

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

  • תקורה נוספת . שכבת האבטחה הנוספת של AI מוסיפה תקורה לזרימת ההודעות. לכן, פתרונות גישור צריכים להיות חכמים מספיק בכדי להתמודד עם איסוף ופרסום מידע מחוץ לזרימת הגישור העיקרית.
  • חיובי שווא . נפח גבוה של תוצאות חיוביות שגויות ידרוש בדיקה נוספת של אנשי מקצוע בתחום האבטחה. עם זאת, עם כמה אלגוריתמים מתקדמים של AI, אנו יכולים להפחית את מספר התוצאות החיוביות המופעלות.
  • חוסר אמון . אנשים מרגישים לא בנוח כאשר הם לא מבינים איך התקבלה החלטה. לוחות מחוונים והתראות יכולים לעזור למשתמשים לדמיין את הגורמים העומדים מאחורי ההחלטה. לדוגמא, אם התראה קובעת בבירור שמשתמש נחסם לגישה למערכת בקצב לא תקין של פי 1,000 ויותר בתוך דקה, אנשים יכולים להבין ולסמוך על החלטת המערכת.
  • פגיעות נתונים . רוב פתרונות ה- AI ומכונת הלמידה מסתמכים על כמויות עצומות של נתונים, שלעתים קרובות רגישות ואישיות. כתוצאה מכך, פתרונות אלה עלולים להיות מועדים להפרות נתונים ולגניבת זהות. עמידה ב- GDPR של האיחוד האירופי (התקנה הכללית להגנת נתונים) מסייעת להפחתת סיכון זה אך אינה מבטלת אותו לחלוטין.
  • מגבלות נתונים מתויגות . מערכות ה- AI החזקות ביותר מאומנות באמצעות למידה מפוקחת, הדורשת נתונים מתויגים המאורגנים כדי להבינו על ידי מכונות. אך לנתונים שכותרתו יש גבולות, והיצירה האוטומטית העתידית של אלגוריתמים קשים יותר ויותר רק תחמיר את הבעיה.
  • נתונים פגומים . האפקטיביות של מערכת AI תלויה בנתונים שהיא מאומנת עליהם. לעתים קרובות מדי, נתונים גרועים קשורים להטיות אתניות, קהילתיות, מגדריות או גזעיות, אשר יכולות להשפיע על החלטות מכריעות לגבי משתמשים בודדים.

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

Sanjeewa Malalgoda הוא אדריכל תוכנה ומנהל שותף להנדסה ב- WSO2, שם הוא מוביל את פיתוח מנהל ה- API של WSO2. Lakshitha Gunasekara הוא מהנדס תוכנה בצוות מנהל ה- API של WSO2. 

-

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