שתף באמצעות

המלצות לאבטחת מחזור חיים של פיתוח

  • מאמר

חל על המלצה זו של Well Architected Framework Reliability של Power Platform:

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

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

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

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

הגדרות

מונח הגדרה
מחזור חיים של פיתוח אבטחה (SDL) קבוצה של נהלים שניתנים על-ידי Microsoft התומכים בדרישות אבטחה ותאימות.
מחזור חיים של פיתוח אבטחה (SDLC) תהליך רב שלבי ושיטתי לפיתוח מערכות תוכנה.

אסטרטגיות מרכזיות בתכנון

יש לשלב אמצעי אבטחה במספר נקודות במחזור חיי פיתוח התוכנה הקיים (SDLC) כדי להבטיח:

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

הסעיפים הבאים מספקים אסטרטגיות אבטחה עבור השלבים הנפוצים של SDLC.

שלב הדרישות

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

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

כל ההחלטות הללו צריכות להוביל להגדרה טובה של מצב האבטחה של עומס העבודה. תעדו את דרישות האבטחה במפרט מוסכם ושקפו אותן בצבר. המסמך צריך לציין במפורש את ההשקעות באבטחה ואת הפשרות והסיכונים שהעסק מוכן לקחת על עצמו אם ההשקעות אינן מאושרות על-ידי בעלי עניין עסקיים. לדוגמה, אפשר לתעד את הצורך להשתמש בחומת אש של IP בסביבות Power Platform כדי להגן על הנתונים הארגוניים שלכם על-ידי הגבלת הגישה ב-Dataverse למיקומי IP מורשים בלבד. אם בעלי עניין עסקיים אינם מוכנים לשאת בעלות הנוספת של שימוש בפתרון כמו 'סביבות מנוהלות', הם חייבים להיות מוכנים לקבל את הסיכון שבגישה למשאבים ארגוניים ממקומות ציבוריים, כגון בית קפה. כדוגמה נוספת, דמיינו שהאפליקציה שלכם חייבת להתחבר למקור נתונים של צד שלישי. ייתכן של- Power Platform יהיה מחבר מוכן לכך, אך ייתכן שהוא לא תומך בדרישות האימות שאושרו על-ידי צוותי האבטחה שלכם. במקרה זה, ייתכן שבעלי העניין באבטחה יהיו מוכנים לקבל את הסיכון של שימוש בשיטת אימות לא מאושרת. לחלופין, תוכלו לחקור שימוש במחבר מותאם אישית, תוך שקלול היתרונות של זמן פיתוח מוגבר ועיכוב פוטנציאלי של הפרויקט.

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

שלב העיצוב

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

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

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

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

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

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

  • אחסנו את סודות האפליקציה בצורה מאובטחת. יישמו בצורה מאובטחת את השימוש בסודות האפליקציה ובמפתחות משותפים מראש שבהם האפליקציה שלכם משתמשת. אין לאחסן אישורים וסודות אפליקציה בקוד המקור של עומס העבודה (אפליקציה או זרימה). השתמשו במשאבים חיצוניים כמו Azure Key Vault כדי להבטיח שאם קוד המקור שלכם יהפוך לזמין לתוקף פוטנציאלי, הוא לא לקבל גישה נוספת.

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

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

  • הימנעו מקידוד קשיח. הימנעו מקידוד קשיח של כתובות אתרים ומפתחות. לדוגמה, הימנעו מקידוד קשיח של כתובת האתר או המפתח לשירות הקצה האחורי בפעולת HTTP של Power Automate. במקום זאת השתמשו במחבר מותאם אישית או במשתנה סביבה עבור כתובת האתר, וב-Azure Key Vault עבור מפתח ה-API.

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

הערה

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

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

למידע נוסף יש לעיין במאמר המלצות לגבי ניתוח איומים.

שלב הפיתוח והבדיקה

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

הכירו היטב את שיטות הקוד המאובטח

צוות הפיתוח צריך לקבל הדרכה בשיטות קידוד מאובטחות. לדוגמה, מפתחים צריכים להכיר מושגי אבטחה ב- Microsoft Dataverse כדי ליישם מודל אבטחה בעל הרשאות מינימליות, מדיניות אבטחת תוכן עבור יישומים מונחי-דגמים להגבלת הטמעה לתחומים מהימנים, ושיטות אימות של מחבר/שער מקומי.

יש לדרוש מהמפתחים להשלים הכשרה זו לפני שהם מתחילים לעבוד על עומסי עבודה של Power Platform.

בצעו ביקורות עמיתים פנימיות של קוד כדי לקדם למידה מתמשכת.

השתמשו בכלי ניתוח קוד

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

בצעו בדיקות נקודות תורפה

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

כתבו קוד בכמות מספיקה בלבד

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

הגנה על סביבת המפתחים

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

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

אבטחת פריסות קוד

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

שמרו על מלאי עדכני של כל רכיב המשולב באפליקציה

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

אנו ממליצים להשתמש ב- Pipelines for Power Platform עבור הפריסות שלכם. הרחיבו קווי צינור באמצעות GitHub Actions. אם אתם משתמשים בזרימות עבודה של GitHub, העדיפו משימות שנכתבו על-ידי Microsoft. כמו כן, אמתו משימות מכיוון שהן פועלות בהקשר האבטחה של הצינור שלכם.

חקרו את השימוש בעקרונות שירות לפריסה.

שלב הייצור

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

שמרו על גרסאות תוצרים

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

תיקוני חירום

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

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

הערה

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

שמרו על סביבות שונות נפרדות

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

השתמשו בחשיפה מתקדמת

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

שלב התחזוקה

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

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

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

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

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

SDL ב- Microsoft Power Platform

Power Platform בנוי על תרבות ומתודולוגיה של עיצוב מאובטח. הן התרבות והן המתודולוגיה מקבלים חיזוק מתמיד מ‬‏‫נוהלי מחזור החיים של פיתוח האבטחה ‏(SDL) ומידול האיומים של המובילים בענף של Microsoft.

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

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

ה- SDL של מיקרוסופט מקביל ל- OWASP Software Assurance Maturity Model ‏(SAMM). שניהם בנויים על הנחת היסוד שעיצוב מאובטח הוא חלק בלתי נפרד מאבטחת אפליקציות לאינטרנט. למידע נוסף, ראו 10 הסיכונים המובילים של OWASP: פעולות צמצום ב- Power Platform.

סיוע של Power Platform

‬‏‫נוהלי מחזור החיים של הפיתוח (SDL) של Microsoft ממליצים על שיטות מאובטחות שאפשר ליישם במחזור חיי הפיתוח. מידע נוסף זמין במאמר מחזור החיים של הפיתוח של Microsoft.

Defender for DevOps וכלי SAST (‏Static Application Security Testing) כלולים כחלק מ-GitHub Advanced Security ו- Azure DevOps. כלים אלה יכולים לעזור לכם לעקוב אחר ניקוד האבטחה של הארגון שלכם.

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

למידע נוסף

רשימת תיוג של אבטחה

עיין במכלול ההמלצות המלא.

רשימת התיוג של אבטחה