המלצות לבדיקות אבטחה
חלה על ההמלצה הזו Power Platform על רשימת אבטחה מתוכננת היטב:
| SE:09 | קבע משטר בדיקות מקיף המשלב גישות למניעת בעיות אבטחה, אימות יישומי מניעת איומים ובדיקת מנגנוני זיהוי איומים. |
|---|
בדיקות קפדניות הן הבסיס לתכנון אבטחה טוב. בדיקה היא צורה טקטית של אימות כדי לוודא שהבקרות פועלות כמתוכנן. בדיקה היא גם דרך פרואקטיבית לאיתור נקודות תורפה במערכת.
קבעו את רמת הקפדנות של בדיקה באמצעות חזרות ואימות מנקודות מבט רבות. חשוב לכלול נקודות מבט מבפנים החוצה שבודקות פלטפורמה ותשתית והערכות מבחוץ פנימה שבודקות את המערכת בתור תוקף חיצוני.
מדריך זה מספק המלצות לבדיקת מצב האבטחה של עומס העבודה שלכם. יישמו את שיטות הבדיקה הללו כדי לשפר את עמידות עומס העבודה שלכם בפני מתקפות ולשמור על סודיות, שלמות וזמינות משאבים.
הגדרות
| מונח | הגדרה |
|---|---|
| בדיקות אבטחה של אפליקציות (AST) | A Microsoft טכניקת מחזור חיים של פיתוח אבטחה (SDL) המשתמשת במתודולוגיות בדיקת קופסה לבנה ו-Black Box כדי לבדוק פרצות אבטחה בקוד. |
| בדיקה מסוג קופסה שחורה | מתודולוגיית בדיקה שמאמתת התנהגות אפליקציה גלויה חיצונית בלי לדעת מה קורה בחלק הפנימי של המערכת. |
| צוות כחול | צוות שמגן מפני המתקפות של הצוות האדום בתרגיל משחק מלחמה. |
| בדיקות חדירה | מתודולוגיית בדיקה המשתמשת בטכניקות פריצה אתיות כדי לאמת את הגנות האבטחה של מערכת. |
| צוות אדום | צוות שממלא תפקיד של יריב ומנסה לפרוץ למערכת בתרגיל משחק מלחמה. |
| מחזור חיים של פיתוח אבטחה (SDL) | קבוצה של שיטות עבודה מסופקות על ידי Microsoft תומכות בדרישות הבטחת אבטחה ותאימות. |
| מחזור חיים של פיתוח אבטחה (SDLC) | תהליך רב שלבי ושיטתי לפיתוח מערכות תוכנה. |
| בדיקה מסוג קופסה לבנה | מתודולוגיית בדיקה שבה מבנה הקוד ידוע למיישם. |
אסטרטגיות מרכזיות בתכנון
בדיקה היא אסטרטגיה שאינה ניתנת למשא ומתן, במיוחד לאבטחה. היא מאפשר לכם לגלות באופן יזום בעיות אבטחה ולטפל בהן לפני שניתן יהיה לנצל אותן ולוודא שבקרות האבטחה שיישמתם פועלות כמתוכנן.
היקף הבדיקות חייב לכלול את היישום, את התשתית ואת התהליכים האוטומטיים והאנושיים.
הערה
הנחיה זו עושה הבחנה בין בדיקה לתגובה לאירוע. למרות שבדיקה היא מנגנון זיהוי שבאופן אידיאלי מתקן בעיות לפני הייצור, אין לבלבל בינה לבין התיקון או החקירה שנעשים כחלק מהתגובה לאירוע. ההיבט של התאוששות מתקריות אבטחה מתואר בהמלצות לתגובה לאירוע אבטחה.
היו מעורבים בתכנון הבדיקה. ייתכן שצוות עומס העבודה לא יתכנן את מקרי הבדיקה. משימה זו לרוב מרוכזת בארגון או מבוצעת על-ידי מומחי אבטחה חיצוניים. צוות עומס העבודה צריך להיות מעורב בתהליך התכנון הזה כדי להבטיח שהבטחות אבטחה משתלבות עם הפונקציונליות של האפליקציה.
חשבו כמו תוקף. תכננו את מקרי הבדיקה בהנחה שהמערכת הותקפה. כך תוכלו לחשוף את הפגיעויות הפוטנציאליות ולתעדף את הבדיקות בהתאם.
הפעילו בדיקות באופן מובנה ועם תהליך שניתן לחזור עליו. עצבו את קפדנות הבדיקות סביב קצב, סוגי מבחנים, גורמי נהיגה ותוצאות רצויות.
השתמשו בכלי המתאים לעבודה. השתמשו בכלים המוגדרים לעבוד עם עומס העבודה. אם אין לכם כלי, קנו אותו. אל תבנו אותו. כלי אבטחה הם ייחודיים, ובניית כלי משלכם עשויה להכניס סיכונים. נצלו את המומחיות והכלים המוצעים על-ידי צוותי SecOps מרכזיים או גורמים חיצוניים אם לצוות עומס העבודה אין את המומחיות הזו.
הגדירו סביבות נפרדות. ניתן לסווג בדיקות כהרסניות או לא הרסניות. בדיקות לא הרסניות אינן פולשניות. הן מציינות שיש בעיה, אבל לא משנות את הפונקציונליות כדי לתקן את הבעיה. בדיקות הרסניות הן פולשניות ועלולות לפגוע בפונקציונליות על-ידי מחיקת נתונים ממסד נתונים.
בדיקה בסביבות ייצור נותנת לכם את המידע הטוב ביותר אך גורמת להכי הרבה הפרעה. בדרך כלל עושים רק בדיקות לא הרסניות בסביבות ייצור. בדיקה בסביבות שאינן סביבות ייצור בדרך כלל פחות מפריעות, אך עשויות שלא לייצג במדויק את תצורת סביבת הייצור בדרכים החשובות לאבטחה.
אפשר ליצור שיבוט מבודד של סביבת הייצור שלכם באמצעות תכונת העתקת הסביבה. אם הגדרתם ערוצי פריסה, תוכלו גם לפרוס את הפתרונות שלכם לסביבת בדיקה ייעודית.
העריכו תמיד את תוצאות הבדיקה. בדיקה היא מאמץ מבוזבז אם התוצאות אינן משמשות לתעדוף פעולות ולביצוע שיפורים במעלה הזרם. תעדו את הנחיות האבטחה, כולל שיטות עבודה מומלצות, שגיליתם. תיעוד שכולל תוצאות ותוכניות תיקון מלמד את הצוות על הדרכים השונות שבהן תוקפים עשויים לנסות לפרוץ את האבטחה. ערכו הדרכות אבטחה קבועות למפתחים, מנהלי מערכת ובודקים.
כשאתם מעצבים את תוכניות הבדיקה שלכם, חשבו על השאלות הבאות:
- באיזו תדירות אתם מצפים שהבדיקה תפעל, וכיצד היא משפיעה על הסביבה שלכם?
- מהם סוגי הבדיקות השונים שכדאי להפעיל?
באיזו תדירות אתם מצפים שהבדיקות יופעלו?
בדקו את עומס העבודה באופן קבוע כדי לוודא ששינויים אינם מציבים סיכוני אבטחה ושאין רגרסיות. הצוות חייב גם להיות מוכן להגיב לאימותי אבטחה ארגוניים שעלולים להתבצע בכל עת. יש גם בדיקות שאפשר להפעיל בתגובה לאירוע אבטחה. הסעיפים הבאים מספקים המלצות לגבי תדירות הבדיקות.
בדיקות שגרתיות
בדיקות שגרתיות מתבצעות בקצב קבוע, כחלק מהליכי ההפעלה הסטנדרטיים וכדי לעמוד בדרישות התאימות. בדיקות שונות עשויות להתבצע בקצבים שונים, והעיקרון הוא שהן מתבצעות מעת לעת ולפי לוח זמנים.
יש לשלב את הבדיקות הללו ב-SDLC מכיוון שהן מספקות הגנה מעמיקה בכל שלב. גוונו את חבילת הבדיקה כדי לוודא שיש הבטחות לזהות, אחסון ושידור נתונים וערוצי תקשורת. בצעו את אותן בדיקות בנקודות שונות במחזור החיים כדי לוודא שאין רגרסיות. בדיקות שגרתיות עוזרות לבסס רף ראשוני. אבל זו רק נקודת התחלה. כשמגלים בעיות חדשות באותן נקודות של מחזור החיים, מוסיפים מקרי בדיקה חדשים. הבדיקות גם משתפרות עם החזרה.
בכל שלב, בדיקות אלו צריכות לאמת קוד שנוסף או הוסר או הגדרות תצורה שהשתנו כדי לזהות את השפעת האבטחה של השינויים הללו. כדאי לשפר את יעילות הבדיקות באמצעות אוטומציה, יחד עם ביקורות עמיתים.
שקלו להפעיל בדיקות אבטחה כחלק מצינור אוטומטי או הפעלת בדיקה מתוזמנת. ככל שמגלים מוקדם יותר את בעיות האבטחה, כך קל יותר למצוא את הקוד או שינוי התצורה שגורם להן.
אל תסתמכו רק על בדיקות אוטומטיות. השתמשו בבדיקות ידניות כדי לזהות נקודות תורפה שרק מומחיות אנושית יכולה לתפוס. בדיקה ידנית טובה למקרי שימוש מחקריים ומציאת סיכונים לא ידועים.
בדיקות מאולתרות
בדיקות מאולתרות מספקות אימות נקודתי של הגנות אבטחה. התראות אבטחה שעשויות להשפיע על עומס העבודה באותו זמן מפעילות את הבדיקות הללו. דרישות ארגוניות עשויות להצריך גישה של השהייה ובדיקה כדי לאמת את יעילותן של אסטרטגיות הגנה אם ההתראה תדרדר למצב חירום.
היתרון של בדיקות מאולתרות הוא מוכנות לאירוע אמיתי. בדיקות אלו יכולות להיות פונקציה מאלצת לבצע בדיקות קבלת משתמש (UAT).
צוות האבטחה עשוי לבדוק את כל עומסי העבודה ולהפעיל את הבדיקות הללו לפי הצורך. כבעלי עומס עבודה, עליכם לעזור לצוותי אבטחה ולשתף איתם פעולה. הסכימו עם צוותי אבטחה על זמן ביצוע מספיק כדי שתוכלו להתכונן. הסבירו לצוות ולבעלי העניין שלכם שהשיבושים אלו נחוצים.
במקרים אחרים, ייתכן שתידרשו להפעיל בדיקות ולדווח על מצב האבטחה של המערכת מפני האיום הפוטנציאלי.
פשרה: מכיוון שמבחנים מאולתרים הם אירועים מפריעים, צפו לתעדף מחדש את המשימות, מה שעלול לעכב עבודה מתוכננת אחרת.
סיכון: יש סיכון של הלא נודע. בדיקות מאולתרות עשויות להיות מאמצים חד פעמיים ללא תהליכים או כלים מבוססים. אבל הסיכון העיקרי הוא ההפרעה הפוטנציאלית לקצב העסקים. עליכם להעריך את הסיכונים האלה ביחס ליתרונות.
בדיקות מסוג מקרה אבטחה
ישנן בדיקות שמגלות את הגורם למקרה ביטחוני במקורו. יש לפתור פערי אבטחה אלה כדי לוודא שהאירוע לא יחזור על עצמו.
המקרים גם משפרים את מקרי הבדיקה לאורך זמן על-ידי חשיפת פערים קיימים. הצוות צריך ליישם את הלקחים שנלמדו מהאירוע ולשלב שיפורים באופן שוטף.
מהם סוגי הבדיקות השונים?
ניתן לסווג בדיקות לפי טכנולוגיה ולפי מתודולוגיות בדיקה. שלבו את הקטגוריות והגישות הללו בתוך הקטגוריות האלה כדי לקבל כיסוי מלא.
על-ידי הוספת מספר בדיקות וסוגי בדיקות, תוכלו לחשוף:
- פערים בבקרות אבטחה או בקרות מפצות.
- תצורות שגויות.
- פערים ביכולת צפייה ובשיטות זיהוי.
תרגיל טוב של מידול איומים יכול להצביע על אזורים מרכזיים כדי להבטיח כיסוי ותדירות של בדיקות. להמלצות על מידול איומים, ראו המלצות לאבטחת מחזור חיים של פיתוח.
ניתן להפעיל את רוב הבדיקות המתוארות בסעיפים אלה כבדיקות שגרתיות. עם זאת, יכולת החזרה עלולה לגרור עלויות במקרים מסוימים ולגרום להפרעה. שקלו את הפשרות האלה בזהירות.
בדיקות המאמתות את מערך הטכנולוגיה
הנה כמה דוגמאות לסוגי בדיקות ואזור המיקוד שלהן. רשימה זו אינה סופית. בדקו את המערך כולו, כולל מערך האפליקציות, הקצה החזיתי, הקצה העורפי, ממשקי API, מסדי נתונים וכל שילוב חיצוני.
- אבטחת נתונים: בדוק את האפקטיביות של הצפנת נתונים ובקרות גישה כדי להבטיח שהנתונים מוגנים כראוי מפני גישה בלתי מורשית וחבלה.
- רשת וקישוריות: בדוק את חומות האש שלך כדי לוודא שהן מאפשרות רק תעבורה צפויה, מותרת ובטוחה לעומס העבודה.
- יישום: בדוק את קוד המקור באמצעות טכניקות בדיקת אבטחת יישומים (AST) כדי לוודא שאתה פועל לפי נוהלי קידוד מאובטח וכדי לתפוס שגיאות בזמן ריצה כמו פגיעה בזיכרון ובעיות הרשאות.
- זהות: הערך אם הקצאות התפקיד והבדיקות המותנות פועלות כמתוכנן.
מתודולוגיית בדיקה
ישנן נקודות מבט רבות על מתודולוגיות בדיקה. אנחנו ממליצים על בדיקות המאפשרות ציד איומים על-ידי הדמיית התקפות בעולם האמיתי. הן יכולות לזהות גורמי איום פוטנציאליים, את הטכניקות שלהם ואת הניצול לרעה המהווה איום על עומס העבודה. הפכו את המתקפות למציאותיות ככל האפשר. השתמשו בכל וקטורי האיומים הפוטנציאליים שאתם מזהים במהלך מידול האיומים.
הנה כמה יתרונות של בדיקה באמצעות התקפות בעולם האמיתי:
- כאשר אתם הופכים את ההתקפות הללו לחלק מהבדיקות השגרתיות, אתם משתמשים בנקודת מבט מבחוץ-פנימה כדי לבדוק את עומס העבודה ולוודא שההגנה יכולה לעמוד בהתקפה.
- על סמך הלקחים שלמד, הצוות משדרג את הידע והמיומנות שלו. הצוות משפר את המודעות למצב ויכול להעריך בעצמו את נכונותם להגיב לאירועים.
דוגמאות לבדיקות מדומות כוללות בדיקות מסוג קופסה שחורה וקופסה לבנה, בדיקות חדירה ותרגילי משחק מלחמה.
בדיקות מסוג קופסה שחורה וקופסה לבנה
סוגי בדיקות אלה מציעים שתי נקודות מבט שונות. בבדיקות קופסה שחורה, החלק הפנימי של המערכת אינו גלוי. במבחני קופסה לבנה, לבודק יש הבנה טובה של האפליקציה ואפילו גישה לקוד, יומנים, טופולוגיית משאבים ותצורות לביצוע הניסוי.
בדיקות המדמות התקפות באמצעות בדיקות חדירה
מומחי אבטחה שאינם חלק מצוותי ה-IT או צוותי האפליקציה של הארגון עורכים בדיקות חדירה, או בדיקת pentesting. הם מסתכלים על המערכת באופן שבו שחקנים זדוניים מסתכלים על משטח תקיפה. המטרה שלהם היא למצוא פערי אבטחה על-ידי איסוף מידע, ניתוח נקודות תורפה ודיווח על התוצאות.
ייתכן שהמתרגלים יזדקקו לגישה לנתונים רגישים בכל הארגון. פעלו לפי כללי ההתקשרות כדי להבטיח שלא נעשה שימוש לרעה בגישה. עיין במשאבים המפורטים ב מידע קשור.
בדיקות המדמות התקפות באמצעות תרגילי משחק מלחמה
במתודולוגיה זו של מתקפות מדומות, ישנם שני צוותים:
- הצוות האדום הוא היריב שמנסה לדמות התקפות בעולם האמיתי. אם הוא מצליח, תוכלו למצוא פערים בתכנון האבטחה ולהעריך את הכלת רדיוס הפגיעה של ההפרות שנגרמו.
- צוות הכחול הוא צוות עומס העבודה שמתגונן מפני ההתקפות. בדיקות אלה בודקות את יכולתם לזהות את המתקפות, להגיב להן ולתקן את התוצאות. הן מאשרות את ההגנות שיושמו כדי להגן על משאבי עומס העבודה.
אם עורכים אותם כבדיקות שגרתיות, תרגילי משחק מלחמה יכולים לספק נראות מתמשכת והבטחה שההגנה שלכם פועלת כפי שתוכננה. תרגילי משחק מלחמה יכולים לבדוק ברמות שונות בעומסי העבודה שלכם.
בחירה פופולרית לדמות תרחישי תקיפה מציאותיים היא ה Microsoft מגן ל Office 365 אימון סימולציית תקיפה.
למידע נוסף, ראו תובנות ודוחות לאימון סימולציית תקיפה.
למידע על הגדרת Red-Team ו- Blue-Team, ראה Microsoft Cloud Red Teaming.
סיוע ל- Power Platform
Microsoft פתרון Sentinel for Microsoft Power Platform מאפשר ללקוחות לזהות פעילויות חשודות שונות, כגון:
- הפעלה של Power Apps ממקומות גיאוגרפיים לא מורשים
- הרס נתונים חשוד על ידי Power Apps
- מחיקה בכמות גדולה של Power Apps
- התקפות דיוג בוצעו ב- Power Apps
- פעילות זרימה ב- Power Automate על ידי עובדים שעוזבים
- מחברי Microsoft Power Platform שנוספו לסביבה
- עדכון או הסרה של מדיניות למניעת אובדן נתונים מ- Microsoft Power Platform
למידע נוסף, ראה Microsoft פתרון Sentinel ל Microsoft Power Platform סקירה כללית.
לתיעוד המוצר, ראה יכולות ציד ב Microsoft Sentinel.
Microsoft Defender for Cloud מציעה סריקת פגיעות עבור תחומי טכנולוגיה שונים. למידע נוסף, ראה אפשר סריקת פגיעות עם Microsoft ניהול פגיעות של Defender.
הנהלים של DevSecOps משלבים בדיקות אבטחה כחלק מתפיסה של שיפור שוטף ומתמשך. תרגילי משחק מלחמה הם תרגול נפוץ המשולב בקצב העסקים ב Microsoft. לקבלת מידע נוסף, ראו אבטחה ב- DevOps (DevSecOps).
Azure DevOps תומך בכלים של צד שלישי שאפשר להפוך לאוטומטיים כחלק מצינורות האינטגרציה הרציפה/פריסה רציפה (CI/CD). למידע נוסף, ראו הפעלת DevSecOps עם Azure ו-GitHub.
מידע קשור
ניתן למצוא את בדיקות החדירה והערכות האבטחה העדכניות ביותר ב Microsoft פורטל אמון שירות.
Microsoft מבצעת בדיקות מקיפות של שירותי ה Microsoft ענן. בדיקה זו כוללת בדיקות חדירה, עם תוצאות שפורסמו ב- Service Trust Portal עבור הארגון שלכם. הארגון שלכם יכול לבצע בדיקת חדירה משלו בשירותי Microsoft Power Platform ו- Microsoft Dynamics 365. כל בדיקות החדירה חייבות לעמוד ב Microsoft חוקי בדיקת חדירה בענן. חשוב לזכור שבמקרים רבים, ה Microsoft ענן משתמש בתשתית משותפת כדי לארח את הנכסים והנכסים שלכם השייכים ללקוחות אחרים. עליכם להגביל את כל מבחני החדירה לנכסים שלכם ולהימנע מהשלכות לא רצויות עבור לקוחות אחרים סביבכם.
פעלו לפי כללי ההתקשרות כדי לוודא שלא נעשה שימוש לרעה בגישה. להדרכה על תכנון וביצוע של מתקפות מדומות, ראו:
אפשר לדמות התקפות מניעת שירות (DoS) ב-Azure. הקפידו לעקוב אחר המדיניות שנקבעה בבדיקות סימולציה של Azure DDoS Protection.
רשימת תיוג של אבטחה
עיין במכלול ההמלצות המלא.