Shadow SaaS: כשכל מחלקה קונה לעצמה אפליקציה בענן

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

זהו Shadow SaaS: שימוש באפליקציות ענן שלא עברו תהליך מסודר של IT, אבטחת מידע ורכש. לרוב זו אינה עקיפה מכוונת, אלא הדרך המהירה לפתור בעיה עסקית. אבל כשזה חוזר שוב ושוב, נוצרת שכבה שלמה של כלים שאף אחד לא באמת מנהל.

לא לבלבל בין המושגים

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

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

הבעיה אינה האפליקציה, אלא הערפל

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

איפה הסיכון מופיע ביום יום?

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

מגילוי למדיניות מדורגת

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

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

שליטה בלי לעצור את העסק

Shadow SaaS אינו סימן שהעובדים עושים משהו לא בסדר, אלא שהעסק מצא דרך לזוז מהר יותר מהתהליך הרשמי. התפקיד של IT ואבטחת מידע הוא לבנות מסלול שבו אפשר להמשיך לזוז מהר, אבל עם רשימת כלים ידועה, בעלים לכל אפליקציה, הרשאות נקיות ותהליך סגירה כשהשימוש נגמר. בינת יכולה לסייע בבניית שכבת ניהול שמשלבת זהויות, SSO, אבטחת ענן, CASB או SSPM, ניטור ושירותים מנוהלים, כך שהשליטה לא באה על חשבון המהירות.