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

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

בכל קובץ הגדרות, בכל סביבה, בכל פריסה. זה היה סיוט. Key Vault משנה את כל זה. במקום לפזר סודות ברחבי הקוד וקובצי ההגדרות, אתם שומרים אותם במקום מרכזי אחד. האפליקציות שלכם מבקשות אותם בזמן הריצה רק כשהן זקוקות להם. ומכיוון שהכל מרוכז במקום אחד, ניתן להחליף סוד במקום אחד בלבד. וכל אפליקציה שמשתמשת בו תמשוך את הערך החדש באופן אוטומטי, ללא שינויי קוד או פריסות מחדש. אבל העניין הוא ש-Key Vault אינו רק מנהל סיסמאות עבור האפליקציות שלך. זהו שירות הבטחה מרכזי. כל שירות ב-Azure יכול להשתלב איתו. App Service, Functions, AKS, Data Factory, Synapse, Logic Apps וצינורות DevOps כולם יודעים לתקשר עם Key Vault. הוא הופך לעמוד הסדרה של ארכיטקטורת הענן המאובטחת שלך. וברגע שמגדירים אותו נכון, מפסיקים לחלוטין לחשוב על ניהול אישורים. מה ניתן להחסן בו? עכשיו, כשאתה יודע מהו Key Vault, בוא נדבר על מה שבאמת ניתן לשים בתוכו. ישנן שלוש קטגוריות עיקריות, סודות, מפתחות ותעודות. לכל אחת תפקיד שונה, והבנת ההבדלים תעזור לך להשתמש ב-Key Vault בצורה הנכונה.

נתחיל בסודות. זהו הפריט הנפוץ ביותר שאנשים מאחסנים. סודות הם אחרוזות חיבור, מפתחות API, סיסמאות למסעד נתונים, מפתחות לחשבונות איחסון, בעיקרון כל אישורי הגישה היומיומיים שהאפליקציות שלך צריכות כדי לתקשר עם שירותים אחרים. במקום להכניס אותם לקוד או לקובץ ההגדרות, אתה מאחסן אותם ב-Key Vault. האפליקציה שלך מושכת אותם בזמן הריצה, ואף אחד לא רואה אותם בטקסט גלוי. חשוב על זה כעל מגירה נעולה בארון הטיוק הדיגיטלי שלך. הבאים בתור הם מפתחות. אלו הם מפתחות הצפנה עבור נתונים במצב מנוחה. אם אתה משתמש במפתחות המנוהלים על ידי הלקוח עבור יחסון ב-Azure, מסדי נתונים של סיקוואל או הצפנת דיסקים של מכונות וירטואליות, המפתחות הללו יכולים לשכון ב-Key Vault. זה מעניק לך שליטה מלאה על מי יכול להשתמש בהם ומתי. ואם אתה זקוק למפתחות מבוססי חומרה עבור רגולציה, גרסת הפרימיום מציעה הגנת HSM. לאחר מכן יש לנו תעודות. תעודות TLS וSSL עבור אפליקציות האינטרנט, ה-API והשירותים הפנימיים שלך. Key Vault יכול להחסן אותן, לנהל את מחזור החיים שלהן, ואף לחדש אותן אוטומטית כשהן קרובות לפקיעת תוקף.

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

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

המודל השני הוא Azure RBSC, בקרת גישה מבוססת תפקידים. זו הדרך המודרנית. היא משתמשת בזהויות של Enter ID, והיא עקבית לאופן שבו אתם מנהלים הרשאות בכל מקום אחר ב-Azure. אם אתם כבר יודעים איך לתת למישהו גישה לחשבון נחסון או למכונה וירטואלית, אתם כבר יודעים איך לתת גישה ל-Key Vault. אותה מערכת, אותם דפוסים. הנה כלל הזהב, הרשאות מינימליות. תנו רק את הגישה המינימלית שמישהו צריך, לא יותר מזה. אם מישהו צריך רק לקרוא סודות, אל תתנו לו הרשאה ליצור או למחוק אותם. אם מישהו צריך רק לנהל תעודות, אל תתנו לו גישה למפתחות. הרשו לי לעבור על התפקידים העיקריים. יש לכם את Key Vault Reader. זה מאפשר למישהו להציג רשימת סודות, אך לא לקרוא את הערכים שלהם. Key Vault Secrets User. זה מאפשר למישהו לקרוא בפועל את ערכי הסודות. ו-Key Vault Secrets Officer. זה מאפשר למישהו ליצור, לעדכן ולמחוק סודות. שימו לב לדפוס. כל תפקיד ספציפי לנתונים שבתוך הכספת, לא לכספת עצמה. כעת, השבו זאת לתפקידים הכלליים, בעלים, תורם, קורא. תפקידים אלו חלים על הכספת כמשאב, לא על המידע שבתוכה.

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

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

תורם לא נשמע כמו מישהו שיכול לקרוא את סיסמאות מסד הנתונים שלכם, אבל בפועל הם יכולים. חישבו על הסיכון. אם תוקף פורץ לחשבון עם תפקיד תורם בחשפת המפתחות שלכם, הוא לא צריך לפרוץ לכספת עצמה. הוא לא צריך לפצח עצפנה. הוא פשוט משנה את מדיניות הגישה, נותן לעצמו גישת קריאה, ושואב בשקט כל סוד ששמרתם, מחרוזות חיבור, מפתחות API, תעודות, הכל. ומכיוון ששינויי מדיניות גישה הם פעילות ניהולית רגילה, ייתכן שזה לא יפעיל שום התראה. אז מהו הפתרון? ראשית, השתמשו באז'ר RBSC עבור גישה למישור הנתונים במקום במדיניות גישה מדור קודם. RBSC מפריד בין ניהול הכספת לבין המידע שבתוכה. שנית, לעולם אל תעניקו את תפקיד הקונטריביוטר בקי וולט למי שלא זקוק לו באופן מוחלט. שלישית, אם כבר יש לכם משתמשים בעלי תפקיד זה, ביצעו להם ביקורת עוד היום. החליפו את הקונטריביוטר בתפקידים ספציפיים יותר, כמו Key Vault Secrets User או Key Vault Secrets Officer. יש טעות שנייה שמחמירה את הראשונה, והיא לשמור את כל הסודות בחשפת אחת. אם יש לכם כספת אחת לכל דבר פיתוח, בדיקות, סטייג'ינג, ייצור וכל האפליקציות שלכם, ואותה כספת נפרצת, הכל חשוף.

זוהי נקודת קשל בודדת. נדבר עוד מעט על אסטרטגיה של ריבוי כספות, אבל העיקרון פשוט. אל תשימו את כל הביצים בסל אחד, במיוחד כשהסל הזה מחזיק את המפתחות לכל התשתית שלכם. Managed Identity, תקן הזהב. אז איך עושים את זה נכון? בואו נדבר על הדרך הטובה ביותר לגשת ל-Key Vault. יש כאן בעיה מהותית. כדי לקבל אישורים מ-Key Vault, האפליקציה צריכה להזדהות, אך כדי להזדהות היא זקוקה לאישורים. איפה מאחסנים את האישורים שהאפליקציה צריכה כדי להשיג אישורים אחרים? זו בעיית הביצה והתרנגולת. התשובה הישנה הייתה Service Principal in Client Secret, אבל הסוד הזה חייב לשבת איפשהו, אולי בקובץ הגדרות, במשתני סביבה או בפייפליין של פריסה. ועכשיו חזרתם לאותה הבעיה. פשוט העברתם את הסוד למקום אחר. Managed Identity פותר זאת לחלוטין. כך זה עובד. כשמפעילים Managed Identity על משאב Azure, כמו Web App, פונקציה או מכונה וירטואלית, Azure יוצרת אוטומטית זהות למשאב הזה ב-Entra ID. הזהות הזו מנוהלת לחלוטין על ידי Azure. אין אישורים ליצור, אין סודות להחליף, אין מה להכסן.

למשאב פשוט יש זהות ש-Azure מכירה. ישנם שני סוגים. System Assigned Managed Identity קשורה למשאב ספציפי אחד. אם מוחקים את המשאב, גם הזהות נעלמת. הם חולקים מחזור חיים משותף, מה שהופך את הניהול לפשוט. User Assigned Managed Identity היא זהות עצמאית שניתן להקצות למספר משאבים. היא לא חולקת מחזור חיים עם אף אחד מהם, ולכן היא שימושית כשצריך את אותה זהות במספר שירותים. הנה איך זה נראה בפועל. נניח שיש לכם Web App שצריך לקרום מחרוז את חיבור למסעד נתונים מ-Key Vault. אתם מפעילים System Assigned Managed Identity על ה-Web App. לאחר מכן אתם מעניקים לזהות הזו את תפקיד ה-Key Vault Secrets User בכספת שלכם. וזהו, אין מחרוזות חיבור בקוד ואין Client Secrets בגבצי הגדרות. אפליקציית האינטרנט מאמתת את עצמה מול Key Vault באמצעות הזהות המנוהלת שלה, ואז'ר מטפל בכל ניהול האישורים מאחורי הקלעים. זהו הדבר הקרוב ביותר לאימות ללא אישורים באז'ר. זה משנה את כללי המשחק בתחום האבטחה, כיוון שזה מבטל את וקטור התקיפה הנפוץ ביותר, גניבת אישורים.

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

אין תשלום מכסון לכל סוד. אתה לא משלם עבור כל סיסמה או מפתח API שאתה מאחסן. במקום זאת, אתה משלם לפי פעולה. עבור שכבת הסטנדרט, זה בערך שלושה סנט על כל עשרת אלפים פעולות. קריאה לקבלת סוד נחשבת כפעולה אחת. כך גם יצירת סוד או הצגת רשימת התוכן של הכספת. עבור אפליקציה טיפוסית קטנה עד בינונית, זה מסתכם בפרוטות לחודש. פרוטות במובן המילולי. השווה את זה אלא את WS Secrets Manager. הם גובים 40 סנט לכל סוד לחודש רק עבור היחסון, פלוס עמלות נוספות עבור קריאות API. אם יש לך מאה סודות, זה 40 דולר לחודש לפני שבכלל קראת אחד מהם. עם Azure Key Vault, מאה סודות עם שימוש מתון עשויים לעלות לך 15 סנט. ההבדל גדל במהירות ככל שהקף הפעילות גדל. כעת, קיימת שכבת פרימיום. היא מוסיפה מפתחות מבוססי HSM עבור עומסי עבודה הזקוקים לרמה הגבוהה ביותר של הבטחה קריפטוגרפית. חשוב על עסקאות פיננסיות, נתוני בריאות, מערכות ממשלתיות. העלות לכל פעולה גבוהה יותר, סביב 15 סנט למד מינוס 10 אלפים פעולות עבור סוגי מפתחות מתקדמים, פלוס עמלה חודשית לכל מפתח HSM.

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

מחיקה רכה, סוף דליט, אומרת שאם מישהו מוחק סוד, הוא לא נעלם לצמיתות. הוא עובר למצב שניתן לשחזור לתקופת שמירה שתבחר עד 90 יום. הגנת ניקוי, פורג' פרוטקשן, לוקחת את זה צעד אחד קדימה. אף אחד לא יכול למחוק לצמיתות את הכספת או את תוכנה עד שתקופת השמירה תפוג. יחד, הם מונעים את סוג אובדן הנתונים המקרי שגורם לצוותי הבטחה לא לישון בלילה. איך הכל מתחבר? בואו נחבר את כל זה יחד ונראה איך החלקים משתלבים. כי וולט הוא לא ייבודד. הוא מערכת העצבים המרכזית לסודות בארכיטקטורת האז'ר שלך. כשמבינים איך כל המערכת זורמת, הכל נופל למקום. הנה מה שקורה כשיישום זקוק לסוד. היישום ביקש זאת באמצעות הזהות המנוהלת שלו. הזהות הזו כבר רשומה ב-Entra ID. Azure יצרה אותה אוטומטית כשהפעלת זהות מנוהלת על המשאב. Entra ID מעמד שהזהות לגיטימית, ואז מעביר את הבקשה ל-KeyVault. KeyVault בודק את הרשאות ה-RBSC שהקצאתה. אם לזהות יש את התפקיד הנכון, למשל KeyVault Secrets User, הסוד מוחזר, כל זה קורה במילי שניות. היישום לעולם לא רואה את אישור הכניסה, Credential, ולעולם לא מאכסן סיסמה.

הוא פשוט מקבל את הערך שהוא צריך. עכשיו, תחשוב כמה שירותי Azure יכולים להתחבר לזה. App Service, Functions, AKS, Data Factory, Synapse, Logic Apps, DevOps Pipelines. כולם יודעים איך לדבר עם KeyVault. ניתן להגדיר אפליקציית אינטרנט שתפנה לסוד ישירות בהגדרות היישום שלה. ניתן להגדיר צינור איבוד, Pipeline, של Data Factory, שימשוך מפתח חשבון יחסון מ-KeyVault בזמן הריצה. ניתן להגדיר אשכול קוברנטיז, שימשוך סודות באמצעות מנהל ההתקן, KeyVault CSI. כל שירות משתלב באותה הדרך, תוך שימוש באותה מערכת זהויות, אותם תפקידי RBSC, ואותו רישום ביקורת. תבנית ה-C, CD, היא עוצמתית במיוחד. צינורות האיבוד, Pipelines, שלך מושכים סודות מ-KeyVault בזמן הפריסה. הם לעולם לא שומרים אותם במשתני הפייפליין או בסודות של מאגר הקוד. אם עליך לרענן סיסמת בסיס נתונים, פשוט עדכן אותה ב-KeyVault. בפעם הבאה שהפייפליין ירוץ, הוא ימשוך את הערך החדש באופן אוטומטי. ללא שינויי פייפליין, ללא שינויי קוד וללא פריסות מחדש. זה הדבר שגורם להקל להתחבר.

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

תובנות מעשיות. אז מה עליך לעשות בפועל ממש עכשיו? בוא נהפוך את הידע הזה לפעולה. הנה הדברים שניתן לטפל בהם השבוע. התחל עם מודל ההרשאות שלך. פתח את ה-KeyVault בפורטל, עבור להגדרות הגישה ובדוק מה רשום שם. אם אתה רואה מדיניות גישת כספת, Vault Access Policy, זו הדרך הישנה. עדיף להשתמש בבקרת גישה מבוססת תפקידים של Azure. המעבר הוא פשוט. החלף את מודל ההרשאות והקצה תפקידי RBSC לאותם אנשים שהיו להם מדיינויות גישה. עשה זאת עוד היום. מייקרוסופט ממליצה על כך, והמחקר שדיברנו עליו הראה בדיוק למה. לאחר מכן, בצע ביקורת על חשבונות בעלי תפקיד תורם, Contributor. ב-KeyVault, פתח את לשונית העים בכספת שלך ובדוק למי יש גישת תורם. לכל אדם עם התפקיד הזה צריכה להיות סיבה מוצדקת. ברוב המקרים, הם לא. החליפו את ה-Contributor במה שהוא ספציפי יותר. אם מי שהוא רק צריך לקרוא סודות, תנו לו הרשאת KeyVault Secrets User. אם הוא צריך לנהל סודות, השתמשו ב-KeyVault Secrets Officer. המטרה היא לסגור את נתיב ההסלמה הזה לחלוטין. לאחר מכן, ניצלו את ה-Managed Identity.

כל שירות Azure שזקוק לגישה ל-KeyVault צריך להשתמש בזה. אם יש לכם אפליקציית ווב, פונקציה, דטה פקטורי או מכונה וירטואלית שעדיין משתמשים ב-Service Principal עם Client Secret, עברו ל-Managed Identity. זה פשוט יותר, מאובטח יותר, וזה פותר את בעיית הביצה והתרנגולת שסקרנו. Azure מטפל בניהול האישורים עבורכם מאחורי הקלעים. עוד דבר אחד, הפעילו מחיקה רכה, Soft Delete, והגנת מחיקה, Purge Protection, בכל כספת. מחיקה רכה מופעלת כברירת מחדל בחשפות חדשות, אך הגנת מחיקה לא. הפעילו אותה. ההגדרה הזו מונעת מכל אחד למחוק לצמיתות, כספת או עת תוכנה במהלך תקופת השמירה. זה הציל יותר מצוות אחד מתאויות הרסניות. הנה הקריאה שלכם לפעולה. בדקו את גישת ניהול הסודות הנוכחית שלכם. מצאו סוד אחד שעדיין יושב בקובץ הגדרות, במשתנה סביבה או בתוך הקוד. העבירו אותו לכי וולט השבוע. רק אחד, ברגע שתראו כמה זה פשוט, תרצו להעביר את השאר. הבטחה היא לא הגדרה חד פעמית. זה תהליך מתמשך. כי וולט הופך את התהליך הזה לקל יותר, אבל רק כשמשתמשים בו נכון.

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