שמור על אבטחת המידע של אפליקציות ה  Cloud-native  והAPI’s  גם בקצב המהיר בו רצים המפתחים קדימה

אפשר להגיד שפיתוח תוכנה בסביבת cloud-native  כבר נהיה עניין של מיינסטרים בשנים האחרונות, טכנולוגיות כגון Microservices, Serverless computing, containers, API’s  וגם  Infrastructure as a code (IaC) לקחו את הובלת הטרנד הזה. תודות לטכנולוגיות מעלה, ארגונים יכולים להריץ את האפליקציות שלהם באופן מהיר וורסטילי ללא כל תלות במשאבי המחשוב הפיזיים, אבל אליה וקוץ בה, בעוד הגמישות פה חוסכת לנו זמן יקר בכל הקשור לתהליך הפיתוח (SDLC), קיבלנו פה תג מחיר בכל הקשור לאבטחת המידע. 

חששות אבטחת מידע ל Cloud-native applications

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

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

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

כלי ה AppSec המסורתיים לא עומדים בקצב

הכלים המסורתיים שנהגנו לסרוק איתם עד היום (AST) לא נועדו להתמודד עם  Cloud-Native Applications, ומכיוון שכך הם אינם יכולים לספק כיסוי מלא, מדויק ומהיר מספיק כדי להדביק את הקצב של אותו שינוי קוד של האפליקציות המודרניות. 

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

אבטחת מידע בכל הקשור ל  API’s, לא תוכל להתבצע על ידי חסימות של  firewalls  או על ידי כלי ניטור כזה או אחר, אפליקציות מבוססות API מצריכות יחס וניהול בהליך פיתוח והגנה משלהם. בדיוק כמו שנו מכירים כיום בתהליך הפיתוח שמתחיל בשלב ה  Planning, Design  וכו כך אנו חייבים להתייחס ל  API. הכנסה נכונה של  API  חייבת לבוא עם מדיניות ארגונית תוך כדי שימת דגש כ  Business risk  ותוכנית המשך לשלבים מאוחרים המהווים שיגרה.

לא מן הנמנע למנות אחראי ולבנות ״רשימת מלאי״ או תכולה של כל האפליקציות המבוססות  API’s  ולהציג אותם בכל  risk assessment  או בקרת איכות, כמובן שניתן לתעדף ולסמן את אלו בעלי רמת הסיכון הגבוהה יותר. 

בדיקות תקופתיות ואימות נתונים על גדר פעולת חובה

שלב חיוני נוסף הוא להיות מודעים לפרסומים בנוגע ל  OWASP 10  הקשור ל  API Security , אותה יכולת המשכית לבחון ולבדוק בזמן אמת / זמן ריצה את ה  API’s  הקיימים ולחשוף כאלו שהם פגיעים (כולל  Custom, open source, Public-facing API’s ) 

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

כל ארגון חייב להיות בעל יכולת רציפה לבחון בכל זמן בצורה פרואקטיבית את האפליקציות שלו ולאפשר תיקון מהיר ככל שניתן של החולשה שנתגלתה ורק אז לשחרר גירסת פרודקשיין חדשה לאוויר. לאחר מכן מערכת תיעדוף הסיכונים לטיפול תיכנס לפעולה לפי קריטריונים שייקבעו על ידי הארגון או יותר נכון לומר אופי הארגון ( לדוגמא:  PCI, PII,DSS וכו ) קריטריונים של הסקייל אליו הסיכון נוגע (אלפים? מיליונים? ) ולבסוף העלות שעלולה להיגרם מכזה סיכון כגון זליגת נתונים רגישים, התאוששות מאסון, או יכולת להחזרת הגוף העסקי לשיגרה בפרק זמן מסוים וסביר. 

שילוב של כלי סריקה בטכנולוגיית  IAST ( Interactive application security testing)  יכולה לתת מענה מצוין, שכן טכנולוגיה זו איננה מצריכה סריקה נוספת או ביצוע פעולות אימות על ממצאי  False Positive  ויכולה להשתלב באופן כמעט טבעי לתוך ה  Pipeline.  

אז איך Synopsys יכולה לסייע בכל הקשור לעיל:

דוח גרטנר האחרון בכל הקשור ל  cloud-native security  העלה את רף ה  “to-do list”  בצורה דרמתית, בזמן שכל הטכנולוגיות הנפוצות  API Security, SAST,SCA IAST נשארו בכלים קריטיים להליכי פיתוח תוכנה התווספו שתי נקודות קריטיות:  Dynamic Application security Testing (DAST) ו  Application Security Posture management (ASPM). סיקר, Seeker   – כלי בטכנולוגיית  IAST  המכוון בעיקר ל  cloud-native application ,

הכלי נועד לזהות, לבחון ולבצע אימות לכל הקריאות פנימה והחוצה של ה  API’s  בין אם אלו  API  מוצהרים של הארגון או מה שנקרא  shadow API’s  , ביכולת הכלי גם לבחון פונקציות ממחושב  serverless  כגון.  AWS Lambda  או Azure Functions,  וזאת כמו שהזכרנו מעלה ללא כל מאמץ סריקה נוסף מבחינת המערכות וללא כל השפעה על זמני ה  Pipeline. 

הכל מתבצע בצורה אוטומטית ורוכב על הבדיקות הפונקציונאליות שבכל מקרה מתבצעות בשלב ה  staging  של צוותי ה  QA, הכלי יידע להפיק ולהנגיש לצוות ה  DevOps  והסקיוריטי מפה ויזואלית של כל הממצאים הקריטיים כולל קשרים בין מיקרו סרביסים וכולל סרגל כיסוי דפי האפליקציה מבחינת בדיקות QA, יתרון נוסף של המערכת שהיא סורקת רק קוד שבפועל רץ, ללא כל צורך לאבד זמן סריקה יקר לתוך עומק קוד שכלל לא רץ או ירוץ. לסיכומו של עניין, אפשר לראות את   Seeker  כ  gray box  מצד אחד, אנו תוקפים את האפליקציה כאילו איננו מכירים כלל את התוכנה שבפנים ומדמים האקר חיצוני ומצד שני יכולים להצביע במדויק בקוד היכן הבעיה שצריך לפתור כדי לחסוך בזמן יקר של מפתחים.