אבטחת מידע בענן היא הגנה על הנתונים, הזהויות והרשתות שהעסק מפעיל בענן, והאחריות עליה משותפת: הספק מאבטח את התשתית, והעסק מאבטח את ההגדרות, ההרשאות, ההצפנה והגיבוי שלו. בפועל מתחילים באימות רב-שלבי, הרשאות מינימליות, הצפנה וגיבוי נפרד, ומוסיפים ניטור ו-SD-WAN כשיש סניפים. השירות של טלקום אקספרט מיועד לעסקים ולארגונים בלבד.
| תחום | הסיכון הנפוץ בענן | הבקרה הראשונה |
|---|---|---|
| זהויות והרשאות | גניבת סיסמה או הרשאת מנהל מיותרת | אימות רב-שלבי והרשאה מינימלית |
| הגדרות הענן | אחסון או שרת שנחשפו לציבור בטעות | סקירת תצורה תקופתית |
| נתונים | מחיקה, תקלה או כופרה | הצפנה וגיבוי נפרד מהחשבון הראשי |
| רשת וסניפים | גישה רחבה מדי דרך VPN | SD-WAN ומדיניות גישה לפי משתמש ומכשיר |
עיקרי הדברים
- לפי מודל האחריות המשותפת של AWS, הספק אחראי לאבטחה של הענן עצמו, והלקוח אחראי לאבטחה בתוך הענן, בהתאם לשירותים שבחר.
- בשרת וירטואלי שהעסק מנהל, מערכת ההפעלה, היישומים והגדרות חומת האש בענן הם באחריות העסק.
- NIST SP 800-207 קובע שאין אמון מובנה במשתמש או במכשיר רק בשל מיקומם ברשת, ושיש לאמת ולהרשות את שניהם לפני הגישה.
- לפי NIST SP 800-215, SASE משלב פונקציות רשת ואבטחה ומספק אותן כשירות ענן אחד, ו-SD-WAN מאפשר להגדיר מדיניות גישה, ניתוב ותעדוף במקום מרכזי.
- מערך הסייבר הלאומי ממליץ לעסק קטן על אימות דו-שלבי, הצפנה בתווך ובשרתים וגיבוי.
- טלקום אקספרט מתכננת ומטמיעה אבטחת ענן וחיבורי סניפים לעסקים ולארגונים בלבד.
העמוד הזה מתמקד בענן וברשת שמחברת אליו. את התמונה הרחבה של הגנת הקצה, ההדרכה והרגולציה בעסק תמצאו בעמוד על שירותי אבטחת מידע לעסקים.
מהי אבטחת מידע בענן?
מחשוב ענן (מוסבר גם במדריך מה זה מחשוב ענן), לפי ההגדרה של NIST ב-SP 800-145, הוא מודל לגישה לפי דרישה, דרך הרשת, למאגר משותף של משאבים כמו שרתים, אחסון ויישומים. ההגדרה כוללת חמישה מאפיינים חיוניים, שלושה מודלי שירות (SaaS, PaaS ו-IaaS) וארבעה מודלי פריסה. אבטחת מידע בענן היא מכלול הבקרות שמגן על המשאבים האלה: מי נכנס, מה הוא רואה, איך הנתונים מוצפנים, איך מזהים פעילות חריגה ואיך משחזרים אחרי תקלה.
העובדה שהמידע יושב אצל ספק גדול אינה מבטלת את האחריות של העסק. כשמערכת הענן מוגדרת בצורה שגויה, למשל אחסון שפתוח לציבור או משתמש עם הרשאת מנהל מיותרת, התשתית של הספק נשארת תקינה והמידע חשוף בכל זאת.
מהם סוגי שירותי אבטחת מידע בענן?
| סוג השירות | מה הוא עושה | מה לבדוק |
|---|---|---|
| ניהול זהויות והרשאות (IAM) | קובע מי נכנס ומה מותר לו, כולל אימות רב-שלבי | הרשאה מינימלית וסקירה תקופתית של משתמשים וספקים |
| הצפנה | מגנה על נתונים בשידור ובאחסון | מי מחזיק את מפתחות ההצפנה ואיך הם מנוהלים |
| חומת אש ופילוח רשת בענן | מגבילה תעבורה בין רכיבים ובין הענן לאינטרנט | כללים מתועדים וסגירת כל פורט שאינו נחוץ |
| ניטור ויומני אירועים | מזהה גישה חריגה ושינויי תצורה | איפה נשמרים היומנים, כמה זמן ומי מקבל התראה |
| גיבוי ושחזור | מאפשר לחזור לעבודה אחרי מחיקה, תקלה או כופר | עותק נפרד מהחשבון הראשי ובדיקת שחזור |
| גישה מאובטחת לסניפים ועובדים (SD-WAN, ZTNA, SASE) | מחברת משתמשים ויישומים תחת מדיניות אחת | איך מאמתים משתמש ומכשיר לפני גישה |
מי אחראי על אבטחת המידע בענן, הספק או העסק?
AWS מגדירה את החלוקה כאבטחה של הענן לעומת אבטחה בתוך הענן. הספק אחראי להגנה על התשתית שמריצה את השירותים: החומרה, התוכנה, הרשת והמתקנים. החלק של הלקוח תלוי בשירותים שבחר. בשרת וירטואלי מסוג EC2, לדוגמה, הלקוח מנהל את מערכת ההפעלה, כולל עדכוניה, את היישומים ואת הגדרות חומת האש בענן (Security Groups). יש גם בקרות משותפות: הספק מעדכן את התשתית שלו, והלקוח מעדכן את מערכת ההפעלה והיישומים שלו.
| משימה | באחריות מי | הערה |
|---|---|---|
| אבטחה פיזית של מרכז הנתונים והחומרה | הספק | אבטחה "של" הענן |
| עדכוני התשתית של הספק | הספק | בקרה משותפת, החלק של הספק |
| עדכוני מערכת הפעלה ויישומים בשרת שהעסק מנהל | העסק | בשירות מנוהל החלוקה שונה ומוגדרת בחוזה |
| חומת אש בענן והגדרות רשת | העסק | הגדרה שגויה חושפת מידע גם כשהתשתית תקינה |
| משתמשים, הרשאות ואימות רב-שלבי | העסק | הגדרה ובקרה שוטפת |
| הצפנה וגיבוי של נתוני העסק | לפי השירות | לקרוא בחוזה מה הספק מספק ומה העסק מוסיף |
החלוקה משתנה בין מודלי השירות. ככל שהספק מפעיל יותר מהמערכת, כמו ביישום SaaS, חלק גדול יותר מהתפעול עובר אליו, אבל הנתונים, המשתמשים וההרשאות נשארים של העסק. לכן קוראים את החוזה ואת מסמך האחריות של הספק לפני המעבר, ולא מניחים שהכול מכוסה.
איך מנהלים זהויות והרשאות בענן?
בענן אין קצה רשת פיזי שאפשר לסגור, ולכן ההזדהות היא קו ההגנה הראשון. כלל העבודה הוא לתת לכל עובד, ספק ומערכת אוטומטית את ההרשאות הדרושות לתפקידו בלבד.
- אימות רב-שלבי: מערך הסייבר הלאומי מציין שאימות דו-שלבי יוצר רובד אבטחה מול גניבת סיסמאות, גם כשהגניבה בוצעה בפישינג. מפעילים אותו לכל חשבון מנהל ולכל גישה למידע רגיש.
- הרשאה מינימלית: נציג שירות צריך הרשאת קריאה לרשומות רלוונטיות ולא הרשאת מנהל שיכולה למחוק מסד נתונים.
- חשבונות מנהל נפרדים: מנהל המערכת משתמש בחשבון נפרד לעבודה ניהולית, ולא בחשבון שבו הוא קורא דואר.
- סקירה ועזיבת עובדים: מסירים גישה ביום עזיבה, וסוקרים הרשאות של עובדים וספקים לפחות פעם בשנה.
- ניטור כניסות: התראה על כניסה ממיקום חריג או בשעה חריגה מאפשרת לחסום חשבון לפני שנגרם נזק.
איך מצפינים ומגבים נתונים בענן?
מערך הסייבר הלאומי ממליץ להצפין מידע גם בתווך, למשל בפרוטוקול מאובטח כמו HTTPS, וגם בשרתים ובמחשבי החברה. בענן מבקשים מהספק להצפין נתונים באחסון ובשידור, ומבררים מי מחזיק את מפתחות ההצפנה ואיך אפשר להחליף אותם.
הגיבוי הוא ההגנה האחרונה מול מחיקה, תקלה ותוכנת כופר. כלל 3-2-1 של US-CERT קובע שלושה עותקים, על שני סוגי מדיה, עותק אחד מחוץ לאתר העסק. בסביבת ענן המשמעות היא עותק שנשמר בחשבון נפרד או אצל ספק אחר, שלא אפשר למחוק מתוך החשבון הראשי, ובדיקת שחזור לפי לוח זמנים. שירות שמבצע זאת בעבור העסק מוסבר בעמוד גיבוי בענן מנוהל. מדריך StopRansomware של CISA מוסיף שהגיבויים צריכים להיות מנותקים ומוצפנים, כי תוכנות כופר מחפשות גיבויים נגישים כדי להצפין או למחוק אותם. מבנה שירותי הענן ואפשרויות האחסון מפורטים בעמוד שירותי ענן לעסקים.
איך משתנה האבטחה בענן ציבורי, פרטי והיברידי?
NIST מגדיר ענן פרטי כתשתית לשימוש בלעדי של ארגון אחד, ענן ציבורי כתשתית הפתוחה לשימוש הציבור הרחב, וענן היברידי כשילוב של שניהם. ההבדל באבטחה מתבטא בשליטה ובעלות.
- ענן ציבורי: התשתית משותפת למספר רב של לקוחות, והספק מפעיל בקרות אחידות. העסק מקבל כלי אבטחה מובנים, אבל השליטה במיקום הנתונים ובתשתית מוגבלת יותר, והאחריות המשותפת חלה במלואה.
- ענן פרטי: שליטה גדולה יותר בהגדרות ובבידוד, בתמורה לעלות הקמה ותחזוקה ולצורך בצוות מקצועי.
- ענן היברידי: מאפשר להשאיר מידע רגיש בסביבה אחת ויישומים פחות רגישים בסביבה אחרת. האתגר הוא מדיניות הרשאות והצפנה אחידה בשתי הסביבות, ובקרה על המעבר של נתונים ביניהן.
מהם הסיכונים והחסרונות של מעבר לענן מבחינת אבטחה?
המעבר לענן מפחית חלק מהסיכונים, כמו כשל חומרה וגישה פיזית לשרת, ומוסיף אחרים. אלה החסרונות והסיכונים שכדאי למפות לפני המעבר:
- הגדרות שגויות: רוב החשיפות בענן נובעות מהגדרה ולא מפריצה לתשתית, למשל אחסון שנפתח לציבור או כלל חומת אש רחב מדי.
- חשבון מנהל אחד: פריצה לחשבון בעל הרשאות רחבות נותנת לתוקף שליטה בכל הסביבה, כולל בגיבויים שנשמרים באותו חשבון.
- תלות בספק: בלי אפשרות לייצא נתונים ודיסקים, היציאה מהשירות הופכת יקרה ומסובכת.
- שימוש לא מאושר: עובדים שמעלים מידע לשירותי ענן פרטיים יוצרים חשיפה שהעסק אינו רואה.
- תלות באינטרנט: כשהקו נופל, העובדים מאבדים גישה למערכות, ולכן קו גיבוי הוא חלק מהתכנון ולא תוספת.
כל אחד מהסיכונים האלה ניתן לטיפול בבקרה ידועה, ולכן החסרונות אינם סיבה להישאר במשרד אלא רשימת בדיקה למעבר.
איך מספקים בישראל תקשורת מאובטחת לענן בגישת SD-WAN?
הרשת שמחברת את הסניפים והעובדים לענן היא חלק מהאבטחה, והעמוד על SD-WAN מרחיב על הטכנולוגיה עצמה. NIST מציין בפרסום SP 800-215 שחיבור VPN קלאסי מנתב את תעבורת המשתמשים המרוחקים אל קצה הרשת הארגונית ומשם החוצה לענן, מה שמוסיף מרחק והשהיה, ושיש לו מגבלות נוספות כמו חולשות שמתפרסמות מעת לעת ומגבלת מספר משתמשים בציוד חומרה.
כדי להתמודד עם זה מתפתחות שלוש גישות משלימות:
| מושג | מה הוא | מה הוא נותן לאבטחה |
|---|---|---|
| SD-WAN | רשת מרחבית מוגדרת תוכנה, שמפרידה את מישור הבקרה ממישור הנתונים | הגדרה מרכזית של מדיניות גישה, ניתוב ותעדוף תעבורת יישומים בכל הסניפים |
| ZTNA | גישה לפי עקרון Zero Trust | אימות משתמש ומכשיר לפני גישה ליישום, ולא גישה כללית לכל הרשת |
| SASE | שילוב פונקציות רשת ואבטחה כשירות ענן אחד | אותן בקרות אבטחה לכל משתמש וסניף, בלי להחזיר את התעבורה למשרד |
לפי NIST SP 800-215, השירותים ב-SASE אינם חדשים, אלא מסופקים יחד כחבילה אחת ולא כפתרונות נקודתיים נפרדים. המסמך מתייחס גם ל-CASB (Cloud Access Security Broker), רכיב שיושב בין המשתמשים לספקי הענן, מזהה שימוש ביישומי ענן לא מאושרים (Shadow IT), אוכף מדיניות ומתריע על תצורות שגויות.
עבור עסק עם כמה סניפים, SD-WAN מעל קווי אינטרנט ותמסורת מאפשר לשלב כמה חיבורים ולכוון תעבורה לפי חשיבותה. איכות הקו עצמו קובעת את התוצאה, ולכן כדאי לבחון גם את קו התמסורת שמחבר כל אתר. אין מחיר לפתרון כזה בלי תכנון: הוא תלוי במספר האתרים, בקצבים, בציוד ובדרישות האבטחה.
איך בוחרים פתרון אבטחה בענן לפי גודל העסק?
עסק של עשרה עובדים שעובד על שירותי תוכנה כשירות אינו צריך את אותה ארכיטקטורה כמו רשת של עשרה סניפים. הטבלה מסדרת את הצעדים לפי הגודל, ומערך הסייבר הלאומי ממליץ להתחיל גם בעסק קטן באימות דו-שלבי, הצפנה וגיבוי.
| סוג העסק | מתחילים מ | מוסיפים אחר כך |
|---|---|---|
| עסק קטן שעובד בשירותי תוכנה כשירות | אימות רב-שלבי, הרשאות לפי תפקיד וגיבוי נפרד | ניטור כניסות חריגות |
| עסק בינוני עם שרתים בענן | סקירת הגדרות, חומת אש בענן והצפנה | ניהול זהויות מרוכז ויומני אירועים |
| עסק עם כמה סניפים ועובדים מרחוק | SD-WAN ומדיניות גישה אחת | ZTNA או SASE לפי הצורך |
הסדר חשוב יותר מהמוצר. עסק שהפעיל אימות רב-שלבי וגיבוי מבודד סגר את רוב הסיכונים הנפוצים, וכל כלי נוסף מוסיף שכבה על בסיס יציב. לכן לא כדאי לרכוש פתרון מתקדם לפני שהבסיס קיים.
איך בוחרים ספק אבטחת מידע בענן?
- תקנים: האם הספק מציג עמידה בתקן ISO/IEC 27001 או בדוח בקרה חיצוני, ומה היקף ההסמכה. מבקשים תעודה או דוח בתוקף ולא מסתפקים בהצהרה.
- הצפנה ומפתחות: הצפנה בשידור ובאחסון, ומי שולט במפתחות.
- מיקום הנתונים: איפה נשמרים הנתונים והגיבויים, ואילו גורמים נוספים מעבדים אותם.
- ניטור ודוחות: גישה ליומני אירועים, התראות בזמן אמת ודוחות אבטחה.
- טיפול באירוע: מה הספק מתחייב לעשות, מתי הוא מודיע ללקוח ובאילו ערוצים.
- תמיכה: מענה אנושי בעברית וזמני תגובה שכתובים בהסכם.
- גמישות: מסלולים לעסק קטן ולארגון גדול, אפשרות להרחיב בלי להחליף ארכיטקטורה.
- יציאה: איך מוציאים את הנתונים בסיום ההתקשרות ומתי הם נמחקים אצל הספק.
בקשו הדגמה או תקופת ניסיון כשאפשר. הניסיון מראה לא רק את הטכנולוגיה, אלא גם את איכות השירות ואת הקלות שבה אפשר ליישם אותה.
מהם שירותי אבטחה מנוהלים בענן ומה הם כוללים?
בשירות אבטחה מנוהל ספק מפעיל עבור העסק חלק מהבקרות במקום שהעסק יפעיל אותן בעצמו. התוכן משתנה בין ספקים, ולכן מבקשים רשימה כתובה של מה כלול ומה נשאר באחריות העסק. מרכיבים נפוצים:
- בדיקה תקופתית של הגדרות החשבונות והשירותים בענן ורשימת תיקונים לפי דחיפות.
- ניטור של יומני כניסה ושינויי תצורה, והתראה על פעילות חריגה.
- טיפול בהתראות: מי בודק אותן, תוך כמה זמן ומה נעשה כשהן אמיתיות.
- דוח תקופתי על הממצאים, התיקונים ושינויי ההרשאות.
- ליווי באירוע: מי מנתק, מי משחזר ומי מדווח ללקוחות ולרשויות.
הגנת הקצה, ההדרכה והרגולציה הרחבה נדונות בעמוד על שירותי אבטחת מידע לעסקים שלמעלה, והעמוד הזה מתמקד בחלק שקשור לענן ולרשת שמחברת אליו.
מה לשאול ספקית תקשורת שמציעה אבטחה בענן?
ספקיות התקשורת הגדולות בישראל, בזק, פרטנר, סלקום והוט, מציעות לעסקים שירותי תקשורת וענן, ולעיתים גם שירותי אבטחה נלווים. ההרכב, התנאים והמחירים משתנים בין ספקית לספקית ובין חבילה לחבילה, ולכן מבקשים אותם בכתב ובודקים מול האתר הרשמי של הספקית. השאלות החשובות הן אלה:
- האם השירות מכסה רק הגנה בסיסית על התעבורה, או גם ניטור ותגובה לאירועים.
- מי מנהל את ההגדרות: הספקית או העסק, ואיך מתבצע שינוי.
- איזו רמת שירות מוגדרת בחוזה וכיצד נמדדת.
- מה נשאר באחריות העסק גם כשהשירות מנוהל, כמו משתמשים, הרשאות וגיבויים פנימיים.
- מה קורה בסיום ההתקשרות ובמעבר לספק אחר.
מה אומרת רגולציית הפרטיות על מידע אישי בענן?
עסק שמעלה לענן מאגר מידע אישי נשאר אחראי לו. לפי מדריך הרשות להגנת הפרטיות ממאי 2025, תיקון 13 הרחיב את ההגדרה של "מחזיק" וכעת היא כוללת כל גורם חיצוני שמעבד מידע עבור הארגון, ו"עיבוד" כולל גם אחסון והעתקה. ספק ענן, ספק גיבוי או ספק ניהול נכנסים אפוא להגדרה. כמו כן, הרשות יכולה להטיל עיצומים כספיים על הפרה של חובות הבקרה והפיקוח על גורם חיצוני. בפועל מגדירים בהסכם עם הספק מה הוא מעבד, איפה ולמשך כמה זמן, ומי מדווח במקרה של אירוע. זהו תיאור כללי, והבדיקה המשפטית נעשית לגופו של כל עסק.
אבטחת מידע בענן עם טלקום אקספרט
טלקום אקספרט מלווה עסקים במעבר לענן ובהגנה עליו, בניהול של מהנדס תקשורת עם מעל 25 שנות ניסיון. הדגש הוא על החיבור בין שלושה דברים שנהוג לטפל בהם בנפרד: הגדרות הענן, הזהויות והרשת שמחברת את הסניפים. הליווי כולל סקירה של ההגדרות הקיימות, תכנון גישה מאובטחת לסניפים ולעובדים מרחוק ובחינת הצעות של ספקים לפי הרשימות שלמעלה. השירות ניתן לעסקים ולארגונים בלבד.
שירותי אבטחת ענן שטלקום אקספרט מתכננת ומלווה
אחרי שמיפיתם את הסיכונים ואת הבקרות, אפשר לבקש הצעה לפי הסביבה של העסק. בכל שורה בטבלה אפשר לבקש הצעת מחיר בווטסאפ.
| שירות | מה מקבלים |
|---|---|
| סקירת הגדרות אבטחה בחשבונות הענן | מעבר מסודר על חשבונות הענן של העסק, בדיקת הרשאות משתמשים, משאבים החשופים לציבור, הצפנה ומדיניות הגישה, ומסירת רשימת תיקונים לביצוע. |
| אימות רב-שלבי וניהול זהויות | הפעלת אימות דו-שלבי לכל המשתמשים, הגדרת הרשאה מינימלית לכל משתמש ולכל ספק חיצוני וסגירת חשבונות ישנים או מיותרים. |
| גיבוי מבודד ובדיקת שחזור לנתוני הענן | הקמת עותק גיבוי בנפרד מחשבון הענן הראשי והרצת בדיקת שחזור מתועדת, כדי לוודא שהנתונים ניתנים לשחזור בפועל. |
| תכנון SD-WAN וגישה מאובטחת לסניפים | תכנון חיבור הסניפים והעובדים המרוחקים לרשת אחת מנוהלת, עם מדיניות אבטחה אחידה לכל האתרים וכללי ניתוב לתעבורה. |
| קבלו הצעת מחיר | |
לייעוץ ללא התחייבות: 077-8123111.
שאלות נפוצות על אבטחת מידע בענן
SASE (Secure Access Service Edge) הוא מונח לארכיטקטורה שמשלבת פונקציות רשת ואבטחה ומספקת אותן כשירות ענן אחד. לפי NIST השירותים עצמם אינם חדשים, אלא מסופקים יחד ולא כפתרונות נקודתיים נפרדים. הוא רלוונטי בעיקר לעסק עם כמה סניפים ועובדים מרחוק שרוצה מדיניות אבטחה אחת לכולם.
מתחילים בבירור אם העסק מחזיק מאגר מידע אישי ואילו תקנות חלות עליו. בהסכם עם הספק מגדירים מה הוא מעבד, איפה ולמשך כמה זמן, כי תיקון 13 הרחיב את ההגדרה של גורם חיצוני שמעבד מידע והוסיף עיצומים על הפרת חובת הפיקוח עליו. כדאי להיוועץ בעורך דין או בממונה על הגנת הפרטיות לפני העברת מאגר לענן.
לא תמיד. NIST מציין ש-VPN מנתב את תעבורת המשתמשים לענן דרך קצה הרשת הארגונית, מה שמוסיף מרחק והשהיה, ושיש לו מגבלות נוספות בציוד חומרה. עסק שמפעיל בעיקר יישומי SaaS מסתפק לרוב באימות רב-שלבי ובהרשאות, ופתרונות כמו ZTNA מעניקים גישה ליישום מסוים אחרי אימות משתמש ומכשיר.
התופעה נקראת Shadow IT: שימוש ביישומי ענן, כמו שיתוף קבצים או ועידות, שלא אושרו על ידי הארגון. NIST מתאר רכיב בשם CASB שיושב בין המשתמשים לספקי הענן, מזהה את השימוש הזה ואוכף מדיניות. לצד כלי כזה קובעים נוהל כתוב שמפרט אילו שירותים מותרים ומדריכים את העובדים.
לפי NIST אין אמון מובנה במשתמש או במכשיר רק בגלל המיקום שלהם ברשת, והאימות וההרשאה נעשים לפני כל גישה למשאב. בפועל זה אימות רב-שלבי, בדיקה שהמכשיר מעודכן ומוגן, והרשאה לפי תפקיד בלבד. אין צורך ברכישת מערכת אחת כדי להתחיל, וניתן ליישם את העקרון בהדרגה.
מערך הסייבר הלאומי ממליץ לעדכן את סקר הסיכונים ואת מיפוי הנכסים אחת לשנה לפחות. את ההרשאות כדאי לסקור גם בכל עזיבה או כניסה של עובד או ספק, ובכל שינוי משמעותי בארכיטקטורה. סקירה כזו מגלה משתמשים מיותרים והגדרות חשיפה שנשארו פתוחות.
