בואו נתכנן את הצעד הבא באבטחת הארגון
השאירו פרטים לשיחה
בדיקות חדירות: המדריך והשירות המרכזי / מבדק חדירות לסביבות ענן
מבדק חדירות ענן בוחן את הקשרים בין זהויות, הרשאות, שירותים ונתונים בסביבת הענן. חיבור מותר לכאורה יכול ליצור נתיב גישה שלא תוכנן, במיוחד כאשר כמה חשבונות ושירותים חולקים משאבים. הבדיקה נועדה להבין אילו פעולות אפשר לבצע במסגרת הרשאה נתונה, מה חשוף ומה משמעות החשיפה עבור הפעילות העסקית. יש להגדיר במפורש את הסביבה ואת מגבלות ספק הענן לפני כל פעילות.
אבטחת ספק הענן ואבטחת הסביבה שלכם
ספק הענן אחראי לשכבות מסוימות של השירות, והלקוח אחראי להגדרות ולרכיבים שנמצאים בשליטתו בהתאם למודל השירות. מבדק של הסביבה שלכם אינו בדיקה של תשתית הספק. הוא יכול להתייחס לזהויות, להגדרות רשת, לנתונים, ליישומים ולחיבורים שהארגון מנהל. לפני העבודה בודקים את מדיניות הספק העדכנית ואת סוג הפעילות המותר לכל שירות. גם אם לא נדרש אישור מקדים לפעילות מסוימת, עדיין קיימים גבולות. ניסיונות מניעת שירות או פעולות שפוגעות בלקוחות אחרים אינם חלק אוטומטי מההיקף.
זהויות והרשאות: המסלול אל המשאבים
בענן, זהות של משתמש או שירות יכולה להיות משמעותית יותר ממיקום ברשת. בוחנים מי יכול להניח תפקיד, לקרוא סוד, לשנות הגדרה או להפעיל עומס עבודה. הרשאה רחבה אחת יכולה להתחבר לקשר אמון ולהשפיע על שירות נוסף. לכן נדרש מיפוי של משתמשים, תפקידים, זהויות שירות והרשאות בין חשבונות. בדיקה מועילה אינה מסתפקת ברשימה של מדיניות שנראית רחבה; היא מסבירה מה אפשר לעשות באמצעותה ובאילו תנאים. המטרה היא לזהות גישה עודפת ולתעד מסלול מבוקר, בלי לבצע שינויים שאינם נדרשים להוכחת ההשפעה.
אחסון, מסדי נתונים וסודות
משאבי אחסון ומסדי נתונים צריכים להתאים לרגישות המידע ולמודל הגישה העסקי. בוחנים חשיפה ציבורית, הרשאות קריאה וכתיבה וקשרים בין שירותים שצורכים את המידע. סודות ומפתחות נבדקים לפי אופן השמירה, הגישה והשימוש בהם. לא כל משאב ציבורי הוא ממצא, ולא כל משאב פנימי מוגן היטב. חשוב להבין מי אמור להגיע אליו ומה נחשב חריגה. איסוף הראיות צריך להיות מצומצם: אפשר להדגים הרשאה באמצעות משאב ייעודי או רשומת בדיקה, במקום להעתיק נתונים רגישים. את חומרת החשיפה קובעים לפי ההקשר ולא לפי שם השירות בלבד.
רשתות, עומסי עבודה ונתיבי ניהול
הבדיקה יכולה לכלול שירותים חשופים, גבולות בין רשתות ונתיבי גישה לממשקי ניהול. בסביבות שמפעילות מכונות וירטואליות, קונטיינרים או פונקציות חשוב להבין את הקשר בין זהות עומס העבודה לבין המשאבים שאליהם הוא מגיע. הפרדה ברשת אינה מחליפה הגבלת הרשאות, והגבלת הרשאות אינה מחליפה בדיקת חשיפה. כאשר יש חיבור לסביבה מקומית, צריך להגדיר אם גם הצד הזה נכלל במבדק. אחרת עלולים להסיק מסקנה רחבה מדי ממסלול שנבדק רק בחלקו. תצורה שמשתנה באמצעות קוד תשתית צריכה להיבחן יחד עם תהליך הפריסה הרלוונטי.
סקירת תצורה מול מבדק חדירות ענן
סקירת תצורה בוחנת הגדרות מול דרישות ובקרות. מבדק חדירות בוחן גם את היכולת להשתמש בחשיפה כדי להגיע להשפעה מוגדרת. שני סוגי העבודה משלימים זה את זה, אך התוצרים שונים. אם ההזמנה היא לסקירת תצורה בלבד, אין להציג אותה כתרגיל תקיפה מלא. בהצעה כדאי להגדיר אם מדובר בבדיקה עם זהות נתונה, בבחינה מבחוץ או בשילוב של כמה נקודות התחלה. נדרשת גם התייחסות לרמת הגישה שניתנת לצוות הבדיקה ולמשאבים שניתן לשנות. החלטות אלה משפיעות על הכיסוי ועל משמעות התוצאה.
ניטור ותיקון שאינם נשארים בדוח
ממצא בענן יכול לדרוש שינוי במדיניות הרשאות, בתשתית כקוד או בתהליך ניהול זהויות. כדי שהתיקון לא ייעלם בפריסה הבאה, חשוב לזהות היכן נמצאת ההגדרה המקורית ומי אחראי לה. כדאי לבדוק גם אם הפעילות יצרה אירועי ניטור זמינים, כאשר זה חלק מההיקף. הדוח צריך להפריד בין חולשה שמאפשרת גישה לבין פער שמקשה לזהות אותה. בבדיקה חוזרת בוחנים את ההרשאות והתצורה המעודכנות ואת הדרך שבה הן נפרסות. מבדק אפליקציה נפרד עשוי להידרש גם כאשר תשתית הענן הוגדרה כראוי, משום שלוגיקה עסקית אינה נפתרת בשינוי תשתית בלבד.
איך מתכננים מבדק שאפשר לפעול לפי התוצאות שלו?
מבדק מועיל מתחיל בהגדרת השאלות שהארגון רוצה לקבל עליהן תשובה. האם משתמש יכול להגיע למידע של לקוח אחר? האם גישה מוגבלת מאפשרת התקדמות למערכת קריטית? האם צוות האבטחה מסוגל לזהות פעולה חשודה בזמן? את השאלות האלה מתרגמים להיקף עבודה, לתרחישים ולתוצרים. כך אפשר להבין מה נבדק בפועל, מה נשאר מחוץ לתחום ואילו מגבלות משפיעות על המסקנות. הצעת עבודה טובה מציגה את ההנחות האלה מראש, במקום להשאיר אותן לפרשנות בסיום הפרויקט.
גבולות, הרשאות ותיאום
לפני תחילת הפעילות מגדירים רשימת נכסים, בעלות על המערכות, חשבונות בדיקה, חלון פעילות ואנשי קשר. מגדירים גם פעולות אסורות, ספי עומס ותהליך עצירה במקרה של השפעה לא צפויה. שירות של צד שלישי אינו הופך לחלק מהבדיקה רק מפני שהוא מחובר למערכת שלכם. לכל רכיב נדרשת הרשאה מתאימה. בסביבה פעילה עדיף להשתמש בנתוני בדיקה ובחשבונות ייעודיים, ולתאם מראש כיצד יישמרו ראיות בלי להעתיק מידע אישי או עסקי מעבר לנדרש.
הוכחת השפעה בלי לגרום נזק
הבדיקה מתקדמת ממיפוי להבנת מנגנוני ההגנה ולבחינה מבוקרת של חולשות. כאשר נמצא נתיב אפשרי, המטרה היא לאסוף ראיות שמספיקות כדי להסביר את הסיכון ולתקן אותו. אין צורך להרחיב גישה או להוציא מאגר שלם כדי להראות שבעיית הרשאות קיימת. אפשר להגדיר מראש דוגמת מידע בטוחה ותנאי הצלחה מוסכמים. אם מתגלה ממצא חמור במהלך העבודה, דרך הדיווח וההסלמה צריכה להיות ברורה, כדי שהצוות האחראי יוכל להגיב בלי להמתין לדוח הסופי.
תיעדוף, תיקון ובדיקה חוזרת
בסיום חשוב לחבר בין חומרת הממצא לבין ההקשר של המערכת: רגישות המידע, חשיפה לאינטרנט, הרשאות נדרשות והשפעה תפעולית אפשרית. רשימת חולשות לבדה אינה מספיקה. צוותי הפיתוח והתשתיות צריכים לדעת מהו שורש הבעיה, אילו רכיבים מושפעים ואיך יוכלו לוודא שהתיקון יעיל. בדיקה חוזרת מתייחסת לגרסה ולתצורה המעודכנות, ומבדילה בין ממצא שנסגר, ממצא שנסגר חלקית וממצא שלא ניתן לאמת בגלל שינוי בהיקף או בהנגשת הסביבה.
מה להכין לקראת שיחת תיחום?
כדאי להכין תיאור קצר של המערכת, תרשים רכיבים, רשימת ממשקים ותפקידים, מידע על סביבת הבדיקה ומועד היעד העסקי. אין צורך לשלוח סיסמאות או מידע רגיש בטופס פנייה. בשיחה אפשר לברר אילו חומרים יועברו בערוץ מוסכם, מי מאשר את הפעילות ומי אחראי לתיקונים. אם קיימים ממצאים קודמים, אפשר להשתמש בהם לתכנון העבודה ולזיהוי אזורים שדורשים תשומת לב. אין להסיק מהיעדר ממצאים שהמערכת חסינה; התוצאה משקפת את ההיקף, התנאים והזמן שהוגדרו לבדיקה.
איך מודדים התקדמות לאחר המבדק?
כדאי להגדיר לכל ממצא גורם אחראי, מועד יעד והחלטה מתועדת. לפעמים אפשר לתקן מיד, ולפעמים נדרש שינוי במערכת או תיאום עם ספק. גם במקרה כזה חשוב להבחין בין טיפול בשורש הבעיה לבין אמצעי זמני שמקטין חשיפה. החלטה לדחות תיקון צריכה לכלול הסבר, מגבלה מפצה ומועד בחינה מחדש. כך נשמר הקשר בין הדוח לבין העבודה בפועל, גם כאשר כמה צוותים חולקים אחריות על אותו תהליך.
לאורך הזמן אפשר לעקוב אחר מספר הממצאים הפתוחים לפי חומרה, משך הזמן עד לתיקון וחזרת בעיות מאותו סוג. המדדים האלה מסייעים לזהות צורך בהדרכה, בבקרות פיתוח או בשינוי תצורה. הם אינם מבטיחים שלא יימצאו חולשות חדשות. כאשר מתחלפת גרסה, נוסף ממשק או משתנה מודל ההרשאות, צריך לבחון אם ההיקף הקודם עדיין מייצג את המערכת. בדיקה תקופתית מועילה יותר כאשר היא מתבססת על השינויים שהתרחשו ועל הסיכונים שהארגון רוצה להקטין.
בשיחת הסיכום רצוי להפריד בין מסר להנהלה לבין פירוט לצוותים הטכניים. ההנהלה צריכה להבין את המשמעות ואת סדר העדיפויות; אנשי המקצוע צריכים לקבל ראיות והמלצות שאפשר ליישם. לפני סגירת הפרויקט כדאי לוודא שהדוח הועבר בערוץ מוסכם ושברור מי שומר את החומרים, מי מקבל גישה אליהם ואילו ראיות יימחקו לפי ההסכם. ההנחיות האלה מגינות גם על המידע שנאסף במהלך הבדיקה.
תחומים משלימים שכדאי להכיר
לעיון במסגרת המקצועית: מדיניות בדיקות חדירה של AWS. מסגרת מקצועית מסייעת לתכנון; הכיסוי בפועל מוגדר בהצעת העבודה.
נגדיר יחד היקף שמתאים למערכת שלכם
לתמונה הרחבה ולבחירת סוג המבדק, עברו אל שירות בדיקות החדירות של ExploiX. לתיאום שיחת תיחום אפשר לפנות לצוות עם תיאור קצר של המערכת והצורך העסקי.
שאלות נפוצות
האם אפשר לבדוק AWS או Azure בלי אישור ספק?
הדבר תלוי בשירות ובסוג הפעילות. לפני כל מבדק בודקים את מדיניות הספק העדכנית ומגדירים פעילות מותרת. הרשאת הארגון אינה מתירה לבדוק את תשתית הספק או להשפיע על לקוחות אחרים.
האם סקירת הגדרות היא מבדק חדירות?
לא בהכרח. סקירה בוחנת תצורה ובקרות, בעוד מבדק יכול לכלול אימות מבוקר של נתיבי גישה. יש להגדיר בהצעה מה מתבצע בפועל ואילו מסקנות ניתן להסיק.
מה נדרש כדי לבדוק הרשאות בענן?
מיפוי חשבונות, משאבים וזהויות, תיאור יחסי אמון ונקודת התחלה מוסכמת. הגישה ניתנת לפי ההיקף, ואיסוף ראיות מתוכנן כך שלא יחשוף מידע מעבר לנדרש.
האם הבדיקה כוללת Kubernetes?
רק אם הוא נכלל במפורש בהיקף. יש לתחום אשכולות, עומסי עבודה, זהויות וגבולות רשת. שירות מנוהל עשוי להציב מגבלות על השכבות שניתן לבדוק.
איך מטפלים בממצא של הרשאות עודפות?
מזהים את ההרשאה ואת מקור ההגדרה, מצמצמים לפי צורך עסקי ובודקים שהשירות ממשיך לתפקד. נדרש לוודא שהתיקון נשמר גם בתהליך הפריסה ובתצורת התשתית.
האם מבדק ענן מחליף בדיקת אפליקציה?
לא. בדיקת ענן עוסקת בזהויות ובמשאבי התשתית; אפליקציה יכולה להכיל בעיות הרשאות ולוגיקה עסקית משלה. את השילוב בין הבדיקות מתכננים לפי הארכיטקטורה.