המלצות להגנה על סודות אפליקציה
חל על המלצה זו של Well Architected Framework Reliability של Power Platform:
SE:07 | ניתן להגן על סודות של אפליקציות על ידי הקשחת האחסון שלהם והגבלת הגישה והמניפולציה ועל ידי ביצוע ביקורת על פעולות אלו. יש להפעיל תהליך רוטציה אמין וקבוע שיכול לאלתר רוטציות למקרי חירום. |
---|
מדריך זה מתאר את ההמלצות לאבטחת מידע רגיש בעומסי עבודה. ניהול נכון של סודות הוא חיוני לשמירה על האבטחה והשלמות של האפליקציה, עומס העבודה והנתונים הנלווים. טיפול לא נכון בסודות עלול להוביל לפרצות מידע, הפרעות בשירות, הפרות רגולטוריות ובעיות אחרות.
אישורים, כגון מפתחות API, Open Authorization (OAuth) ומפתחות מעטפת מאובטחת (SSH) הם סודות. דרישות תאימות עלולות לגרום להתייחסות להגדרות תצורה שאינן נחשבות סודיות, כאל סודות של אפליקציות.
הגדרות
מונח | הגדרה |
---|---|
אישורים | קבצים דיגיטליים המחזיקים את המפתחות הציבוריים להצפנה או פענוח. |
אישורים | מידע המשמש לאימות זהות המפרסם או הצרכן בערוץ תקשורת. |
סריקת אישורים | תהליך אימות קוד המקור כדי לוודא שהסודות אינם כלולים. |
הצפנה | התהליך שבו הנתונים הופכים לבלתי קריאים וננעלים באמצעות קוד סודי. |
מקש | קוד סודי המשמש לנעילה או ביטול נעילה של נתונים מוצפנים. |
גישה עם הרשאות מינימליות | עיקרון אפס אמון שמטרתו למזער קבוצה של הרשאות להשלמת פונקציית עבודה. |
זהות מנוהלת | זהות המוקצית למשאבים ומנוהלת על ידי Azure. |
לא סודי | מידע שאינו מסכן את מצב האבטחה של עומס העבודה אם הוא דלף. |
סיבוב | התהליך של עדכון שוטף של סודות כך שאם הם נחשפים לסכנה, הם זמינים רק לזמן מוגבל. |
סוד | רכיב חסוי של המערכת המאפשר תקשורת בין רכיבי עומס עבודה. אם הם דולפים, סודות עלולים לגרום לפרצה. |
X.509 | תקן המגדיר את המבנה של אישורי מפתח ציבורי. |
חשוב
לא להתייחס אל 'לא סודות' כאל סודות. סודות דורשים קפדנות תפעולית שמיותרת עבור 'לא סודות' ועשויה לגרום לעלויות נוספות.
הגדרות אפליקציה שאינן סודות, כגון כתובות ה- URL של ממשקי ה- API שהאפליקציה זקוקה להם, צריכות להישמר בנפרד מקוד האפליקציה או סודות האפליקציה. כדי לאחסן את תצורת האפליקציה, יש לשקול להשתמש במחבר מותאם אישית או במשתני סביבה. אפשרות נוספת היא להשתמש בטבלת Dataverse לאחסון מטה נתונים לגבי תצורת האפליקציה. עם זאת, נדרש למצוא דרך למלא נתונים אלה בסביבה חדשה, כגון העברת נתוני תצורה מפיתוח לבדיקה או ייצור. ניתן להשתמש בזרימות נתונים כדי להשיג זאת.
אסטרטגיות מרכזיות בתכנון
יש לקחת בחשבון את הדברים הבאים לפני אחסון וניהול סודות:
- סודות שנוצרו צריכים להישמר באחסון מאובטח עם בקרות גישה קפדניות.
- רוטציה של סודות היא פעולה יזומה, בעוד שביטול הוא תגובתי.
- רק לזהויות מהימנות צריכה להיות גישה לסודות.
- יש לשמור על נתיב ביקורת כדי לבדוק ולאמת את הגישה לסודות.
בנו אסטרטגיה סביב נקודות אלו כדי לסייע במניעת גניבת זהות, להימנע מהתכשות ולמזער חשיפה מיותרת למידע.
שיטות עבודה בטוחות לניהול סודות
אנו ממליצים שלמפתחות יהיו שלושה תפקידים נפרדים: משתמש, מנהל מערכת ומבקר. הבחנה בין תפקידים עוזרת להבטיח שרק לזהויות מהימנות תהיה גישה לסודות ברמת ההרשאה המתאימה. יש ללמד מפתחים, מנהלי מערכת ואנשי צוות רלוונטיים אחרים לגבי החשיבות של שיטות עבודה מומלצות לניהול סודות ואבטחה.
מפתחות ששותפו מראש
ניתן לשלוט בגישה על ידי יצירת מפתחות נפרדים עבור כל צרכן. לדוגמה, לקוח, כמו אפליקציה או זרימה, מתקשר עם API של צד שלישי באמצעות מפתח ששותף מראש. אם לקוח אחר צריך לגשת לאותו API, עליו להשתמש במפתח אחר. אין לשתף מפתחות גם אם לשני צרכנים יש אותם דפוסי גישה או תפקידים. טווחי צרכנים עשויים להשתנות עם הזמן, ולא ניתן לעדכן באופן עצמאי הרשאות או להבחין בדפוסי שימוש לאחר שיתוף מפתח. גישה נבדלת גם מקלה על הביטול. אם מפתח של צרכן נחשף לסכנה, קל יותר לבטל או לעשות רוטציה למפתח זה מבלי להשפיע על צרכנים אחרים.
הנחיה זו חלה על סביבות שונות. אין להשתמש באותו מפתח הן בסביבות טרום ייצור והן בסביבות ייצור. אם האחריות ליצירת מפתחות משותפים מראש היא שלך, יש לוודא שיצרת מפתחות מרובים כדי לתמוך במספר לקוחות.
מידע נוסף: המלצות לניהול זיהות וגישה.
אחסון סודות
יש להשתמש במערכת ניהול סודות, כמו Azure Key Vault, כדי לאחסן סודות בסביבה מוקשחת, להצפין במנוחה ובמעבר, ולבקר את הגישה והשינויים בסודות. אם נדרש ממך לאחסן סודות של אפליקציות, יש לשמור אותם מחוץ לקוד המקור כדי לאפשר רוטציה קלה.
מערכת ייעודית לניהול סודות מקלה על אחסון, הפצה ושליטה בגישה לסודות אפליקציה. רק לזהות ושירותים מורשים צריכה להיות גישה למאגרי סודות. ניתן להגביל את הגישה למערכת באמצעות הרשאות. יש להחיל תמיד הגישה עם הרשאה מינימלית בעת הקצאת הרשאות.
צריך גם לשלוט בגישה ברמת הסודות. לכל סוד צריכה להיות גישה רק טווח של משאב יחיד. יש ליצור גבולות בידוד כך שרכיב יוכל להשתמש רק בסודות שהוא צריך. אם רכיב ממודר נחשף לסכנה, הוא לא יכול להשיג שליטה על סודות אחרים ואולי על כל עומס העבודה. אחת הדרכים לבודד סודות היא להשתמש במספר כספות מפתח. אין עלויות נוספות ליצירת כספות מפתח נוספות.
הטמעת ביקורת ומעקב אחר גישה לסודות. יש לתעד את מי שניגש לסודות ומתי כדי לזהות פעילות לא מורשית או חשודה. למידע על רישום מנקודת מבט של אבטחה, יש לעיין במאמר המלצות לניטור וזיהוי איומים.
רוטציה של סודות
יש להקים תהליך ששומר על היגיינת הסודות. אורך החיים של סוד משפיע על הניהול של הסוד הזה. כדי לצמצם את וקטורי ההתקפה, יש לבטל את הסודות ולהחליף אותם בסודות חדשים בתדירות גבוהה ככל האפשר.
יש לטפל בזהירות באסימוני גישה של OAuth, תוך התחשבות באורך החיים שלהם. מומלץ לשקול אם יש להתאים את חלון החשיפה לתקופה קצרה יותר. אסימוני רענון חייבים להיות מאוחסנים בצורה מאובטחת עם חשיפה מוגבלת לאפליקציה. אישורים מחודשים צריכים להשתמש גם במפתח חדש. מידע על אסימוני רענון: אסימוני רענון מאובטח OAuth 2.0 מטעם רענון.
יש להחליף סודות לאחר שהם מגיעים לסוף חייהם, אינם משמשים עוד לעומס העבודה, או אם הם נחשפו לסכנה. לעומת זאת, אין להוציא משימוש סודות פעילים אלא אם כן מדובר במקרה חירום. אתה יכול לקבוע את המצב של סוד על ידי הצגת יומני גישה. תהליכי רוטציה של סודות לא אמורים להשפיע על המהימנות או הביצועים של עומס העבודה. יש להשתמש באסטרטגיות שבונות יתירות בסודות, בצרכנים ובשיטות גישה לרוטציה חלקה.
שיטות עבודה בטוחות לשימוש בסודות
כמחולל או מפעיל סודות, אמורה להיות לך היכולת להפיץ סודות בצורה בטוחה. ארגונים רבים משתמשים בכלים כדי לשתף סודות בצורה מאובטחת הן בתוך הארגון והן חיצונית לשותפים. בהיעדר כלי, קיים תהליך למסירה נכונה של אישורים לנמענים מורשים. תוכניות ההתאוששות שלך מאסון צריכות לכלול נהילי שחזור סודות. יש להקים תהליך למצבים שבהם מפתח נחשף לשכנה או דלף ויש צורך לשחזר אותו לפי דרישה. יש לשקול את שיטות העבודה המומלצות הבאות בעת שימוש בסודות:
יש למנוע תכנות נוקשה
אין לתכנת סודות בתכנות נוקשה כטקסט סטטי בנכסי קוד כגון זרימות ענן ויישומי בד ציור, קובצי תצורה ובערוצי בנייה-פריסה. שיטת עבודה מסוכנת זו הופכת את הקוד לפגיע מכיוון שהסודות נחשפים לכל מי שיש לו גישת קריאה.
יש להשתמש בכלים שמזהים מעת לעת סודות שנחשפו בקוד האפליקציה ובכלי בניה. ניתן להוסיף כלים אלה כחלק מערוצי הפריסה שלך כדי לסרוק אישורים לפני שקוד המקור מתחייב לפריסה. יש לבדוק ולחטא יומני אפליקציה באופן קבוע כדי להבטיח שלא נרשמו סודות בטעות. ניתן גם לחזק את הזיהוי באמצעות ביקורות עמיתים.
הערה
אם כלי הסריקה מגלים סוד, סוד זה חייב להיחשב כחשוף לסכנה. יש לבטל אותו.
תגובה לרוטציה של סודות
כבעל עומס עבודה, נדרש ממך להבין את תוכנית הרוטציה של הסודות ואת המדיניות כדי שתוכל לשלב סודות חדשים עם הפרעה מינימלית למשתמשים. כאשר מבצעים רוטציה לסוד, עלול להיווצר חלון שבו הסוד הישן אינו תקין, אך הסוד החדש טרם נוצר. במהלך חלון זמן זה, הרכיב שאליו עומס העבודה מנסה להגיע לא יאשר בקשות. ניתן למזער בעיות אלה על ידי בניית לוגיקת ניסיון חוזר בקוד. אתה יכול גם להשתמש בדפוסי גישה במקביל המאפשרים לך לקבל מספר אישורים שניתן לשנות בבטחה מבלי שישפיעו זה על זה.
יש לעבוד עם צוות התפעול ולקחת חלק בתהליך ניהול השינויים. יש ליידע את בעלי האישורים בעת הוצאה משימוש של חלק מעומס העבודה שמשתמש באישורים שאינם נחוצים עוד.
יש לשלב אחזור סודות ותצורה בערוץ הפריסה האוטומטי שלך. אחזור סודות עוזר להבטיח שסודות יאוחזרו אוטומטית במהלך הפריסה. אתה יכול גם להשתמש בדפוסי הזרקה סודיים כדי להכניס סודות לקוד אפליקציה או לתצורה בזמן הפעלה, מה שמונע מסודות להיחשף בטעות ליומנים או לבקרת גרסאות.
סיוע של Power Platform
הסעיפים הבאים מתארים תכונות של Power Platform ויכולות שבהן אפשר להשתמש כדי לנהל את סודות היישום.
שימוש בסודות Azure Key Vault
משתני סביבה מאפשרים לבצע הפניה לסודות המאוחסנים ב- Azure Key Vault. סודות אלה הופכים לאחר מכן לזמינים לשימוש בזרימות Power Automate ומחברים מותאמים אישית. שימו לב שהסודות אינם זמינים לשימוש בהתאמות אישיות אחרות או באופן כללי דרך ה- API.
הסודות האמיתיים מאוחסנים ב- Azure Key Vault ומשתנה הסביבה מבצע הפניה למיקום סוד של Key Vault. שימוש בסודות Azure Key Vault עם משתני סביבה דורש שתקבע את תצורת Azure Key Vault כך ש- Power Platform יוכל לקרוא את הסודות הספציפיים שברצונך לבצע אליהם הפניה. מידע נוסף: שימוש במשתני סביבה בפתרונות ושימוש במשתני סביבה במחברים מותאמים אישית של הפתרון.
שימוש בבודק הפתרונות
באמצעות התכונה 'בודק הפתרונות', באפשרותך לבצע בדיקת ניתוח סטטי עשירה בפתרונות שלך לעומת קבוצה של כללים המומלצים לעבודה ולזהות דפוסים בעייתיים אלה במהירות. לאחר השלמת הבדיקה, תקבל דוח מפורט המפרט את הבעיות שזוהו, את הרכיבים ואת הקוד המושפעים וכן קישורים לתיעוד המתאר כיצד לפתור כל בעיה. יש לבדוק את בכללי בודק הפתרונות הזמינים בקטגוריית אבטחה. מידע נוסף: שימוש בבודק הפתרונות לאימות הפתרונות שלך
שימוש בפעולות CyberArk
CyberArk מציעה פלטפורמת אבטחת זהות המאבטחת זהויות של אנשים ושל מחשבים מקצה לקצה. זרימות שולחן עבודה של Power Automate מאפשרות לך לאחזר אישורים CyberArk. מידע נוסף: פעולות CyberArk.
למידע נוסף
- שימוש במשתני סביבה בפתרונות
- שימוש במשתני סביבה במחברים מותאמים אישית של פתרונות
- השתמש בבודק הפתרונות כדי לאמת את הפתרונות שלך
- פעולות CyberArk
- משימה של סורק אישורים של Azure DevOps
- הגדר את הרחבת Microsoft Security DevOps Azure DevOps
- הגדרת GitHub Advanced Security עבור Azure DevOps
- המלצות לניטור וזיהוי איומים
- המלצות לניהול זהויות וגישה
רשימת תיוג של אבטחה
עיין במכלול ההמלצות המלא.