אבטחת ענן

רוב העסקים בישראל כבר רצים על הענן — AWS, Azure, GCP או לפחות Microsoft 365 ו-Google Workspace. אבל יש פער מסוכן בין התחושה ״הספק הגדול מאבטח אותנו״ לבין המציאות: הרוב המוחלט של אירועי האבטחה בענן לא נובע מפריצה לתשתית של אמזון או מיקרוסופט, אלא מטעויות תצורה בצד הלקוח — דלי אחסון פתוח לעולם, משתמש אדמין בלי MFA, מפתח API ששכחו בקוד. הדף הזה מסביר איפה עובר קו האחריות, מהם הפערים שאנחנו פוגשים שוב ושוב, ומה כוללת סקירת אבטחת ענן מסודרת.

מודל האחריות המשותפת — הספק מאבטח את הענן, אתם את מה שבענן

כל ספקי הענן הגדולים עובדים לפי מודל האחריות המשותפת (Shared Responsibility Model): הספק אחראי על אבטחת התשתית הפיזית, החומרה והשירותים עצמם — ואתם אחראים על כל מה שאתם מריצים ומאחסנים בתוכם: זהויות והרשאות, תצורות, נתונים, קוד וגישה. ככל שהשירות ״מנוהל״ יותר, חלק גדול יותר עובר לספק — אבל האחריות על הנתונים ועל ההרשאות לעולם לא עוברת אליו:

הפערים הנפוצים שאנחנו מוצאים ב-AWS, Azure, GCP וב-Microsoft 365

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

• הרשאות עודפות (Over-privileged IAM). משתמשים ו-Service Accounts עם הרשאות אדמין רחבות ״כי זה היה נוח בהתחלה״, תפקידים שלא נוקו כשעובדים עזבו, ומפתחות גישה בני שנים שאיש לא מסובב.
• חשבונות ללא MFA. במיוחד חשבונות Root/Global Admin וחשבונות ״טכניים״ משותפים — בדיוק החשבונות שתוקף מחפש ראשונים.
• Storage חשוף. דליי S3, Blob Storage או Cloud Storage עם גישה ציבורית או עם הרשאות שיתוף רחבות מדי — לרוב שרידים של בדיקה או אינטגרציה ישנה.
• סודות בקוד. מפתחות API, סיסמאות ו-Connection Strings בתוך ריפוזיטורי, בקבצי תצורה או במשתני סביבה גלויים — במקום ב-Secrets Manager ייעודי.
• היעדר ניטור ותיעוד. CloudTrail/Activity Logs כבויים או לא נשמרים, אף אחד לא מקבל התראה על פעולה חריגה, וכשקורה אירוע — אין ראיות לחקור.

מה כוללת סקירת אבטחת ענן של Cybertis

הסקירה שלנו משווה את הסביבה שלכם ל-Best Practices מוכרים — ובראשם CIS Benchmarks לכל פלטפורמה, לצד המלצות האבטחה הרשמיות של הספק (Well-Architected, Secure Score). אנחנו בודקים שש שכבות:

1. תצורה כללית — הגדרות החשבון/Tenant מול ה-Benchmark הרלוונטי, כולל שירותים שהופעלו ונשכחו.
2. זהויות והרשאות (IAM) — מי יכול לעשות מה, עקרון ההרשאה המינימלית, MFA, פדרציה ו-SSO, וניהול מפתחות גישה.
3. רשת — חשיפה לאינטרנט, Security Groups ו-Firewall Rules, סגמנטציה בין סביבות Production ו-Dev.
4. הצפנה — הצפנת נתונים במנוחה ובתעבורה, ניהול מפתחות (KMS) וסודות.
5. ניטור וגילוי — תיעוד פעילות, התראות על אירועים חריגים, ושילוב עם תהליך תגובה לאירועים.
6. גיבוי ו-DR — האם אפשר לשחזר את העסק אחרי מחיקה, הצפנה זדונית או נפילת Region.

התוצר הוא דוח מדורג לפי סיכון עסקי: מה מסוכן באמת ודורש טיפול השבוע, מה חשוב לרבעון הקרוב, ומה Nice-to-have — כולל הנחיות תיקון מעשיות לצוות ה-DevOps שלכם. בסביבות Multi-cloud או Hybrid אנחנו בודקים גם את התפרים בין הפלטפורמות — פדרציית זהויות, חיבורי רשת בין עננים, וכפילויות בניהול סודות — כי דווקא שם נפערים הפערים שאף כלי אוטומטי של ספק בודד לא רואה. במקרים המתאימים נמליץ להשלים את הסקירה במבחן חדירה שמדמה תוקף בפועל, וכך לאמת שהתיקונים אכן עומדים במבחן המציאות.

ענן ותיקון 13 — מידע אישי בענן הוא סוגיה רגולטורית

אם אתם מאחסנים מידע אישי בענן — לקוחות, עובדים, מועמדים — ספק הענן הוא ״מחזיק״ (מעבד מידע) מבחינת חוק הגנת הפרטיות. המשמעות אחרי תיקון 13: נדרש הסכם עיבוד מידע (DPA) מול הספק, וצריך לבדוק את סוגיית העברת המידע לחו״ל — באיזה Region המידע יושב, והאם ההעברה עומדת בתקנות העברת מידע. רוב הספקים הגדולים מציעים DPA סטנדרטי ובחירת Region — אבל מישהו אצלכם צריך לוודא שזה אכן הוגדר, מתועד ותואם לרמת האבטחה שחלה על המאגרים שלכם לפי תקנות אבטחת מידע. בסקירות שלנו אנחנו בודקים גם את השכבה הזו — כך שהדוח שתקבלו סוגר בבת אחת את הפער הטכני ואת הפער הרגולטורי, במקום שני פרויקטים נפרדים עם שני ספקים.