אבטחת SaaS ומה משתנה כשאין לכם שליטה על השרתים

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

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

מה באמת משתנה כשעוברים ל SaaS

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

במילים פשוטות: מרכז הכובד זז משליטה בתשתית לשליטה בגישה ובנתונים.

מודל האחריות המשותפת בעולם SaaS

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

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

הסיכונים הכי נפוצים במערכות SaaS

זהויות והרשאות חלשות

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

קונפיגורציה לא בטוחה

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

Shadow IT

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

דליפת מידע דרך שיתוף וקישורים

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

מחסור בניטור ובתגובה

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

איך בונים אבטחת SaaS בצורה נכונה ומעשית

מתחילים בזהויות כי שם מתחיל הסיכון

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

מה כדאי ליישם כמעט בכל ארגון:

1. התחברות אחודה SSO לכל מערכות SaaS קריטיות
2. MFA חובה, בלי חריגים ובלי חשבונות מיוחדים
3. עיקרון הרשאות מינימליות למשתמשים ולמנהלים
4. סקירת הרשאות תקופתית כולל משתמשים חיצוניים
5. תהליך Joiner-Mover-Leaver ברור: מצטרפים, משני תפקיד, עוזבים

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

מקשיחים את ההגדרות בתוך המערכת

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

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

מנהלים נתונים ולא רק משתמשים

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

גישה פרקטית בשלושה צעדים:

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

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

מחברים לוגים ומגדירים התרעות שמצילות אירועים

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

מה לחבר:
Audit logs, אירועי התחברות, שינויים בהרשאות, יצוא נתונים, יצירת טוקנים, חיבורי API, יצירת משתמשים חדשים, ושיתופים חיצוניים.

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

בדיקת ספקים והיבטים חוזיים

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

מה לבדוק בצורה פרקטית:
תקני אבטחה כמו ISO 27001 או SOC 2 אם רלוונטי, הצפנה במנוחה ובתעבורה, מיקום מידע, מדיניות שמירת לוגים, גיבויים, SLA, זמני תגובה באירוע אבטחה, אפשרות לייצוא נתונים, התחייבות למחיקה בסיום התקשרות, תמיכה ב SSO ו MFA, יכולות הרשאות למשתמשים חיצוניים, ותיעוד אינטגרציות.

תכנית תגובה לאירוע שמתאימה ל SaaS

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

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

טעויות נפוצות שמייצרות סיכון גבוה

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

למי זה מתאים במיוחד

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

איך מדסק עוזרת לכם לאבטח SaaS בלי כאב ראש

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

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