הגדרת Azure Key Vault מקצה לקצה: סודות, מפתחות, תעודות

הגדרת Azure Key Vault: היכן דולפים סודות ומפתחות

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

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

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

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

מה נותן אחסון מנוהל של סודות ומפתחות

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

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

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

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

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

אפשרויות חיבור אפליקציות לכספת סודות

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

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

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

סדר הטמעה: מביקורת סודות ועד מסירה

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

1. ביקורת סודות. עורכים מלאי של כספות סיסמאות במאגרים, משתני צינורות, תצורות אפליקציות וקבצים בשרתים. עבור כל רשומה מתעדים בעלים, קריטיות, משך חיים וכפילויות — בלי זה רוטציה ומחיקה בלתי אפשריות.
2. תרשים הפרדת גישה. מפרידים כספות לפי סביבות, נותנים תפקידים על סודות מסוימים במקום הרשאות על כל המתאר. עומסי עבודה קוראים ערכים דרך זהויות מנוהלות, חשבונות שירות עם מפתחות ארוכי טווח מוציאים משימוש, וגישה ציבורית סוגרים.
3. מיגרציית סודות. מעבירים בשלבים, עם ניהול גרסאות והשוואת ערכים לתקן. אפליקציות וצינורות מפנים לקריאה מהכספת, העתקים ישנים מסומנים למחיקה ומוסרים אחרי תקופת ביקורת.
4. הגדרת רוטציה. קובעים משך חיים ולוח זמנים להחלפת סיסמאות ומפתחות, מאוטמטים חידוש והתראות לבעלים. בנפרד בודקים שהשירות קולט גרסה חדשה בלי אתחול והתערבות ידנית.
5. בדיקת כשלים. מריצים תרחישים: אי-זמינות כספת, גישה שנשללה, סוד שנשכח, מחיקה שגויה. מפעילים הגנה מפני אובדן בלתי הפיך ושחזור מגיבוי.
6. קבלה ומסירה. בודקים הרשאות מכל סביבה לפי תרחישי ביקורת, מוסרים מפת כספות, מטריצת תפקידים, נוהל רוטציה וסדר שחזור. צוות התורנות מקבל הוראות וניתוח אירועים טיפוסיים.

מדיניות גישה, תפקידים ותרשימי אחסון מפתחות

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

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

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

מקרה בוחן: איך סודות עברו מקובצי תצורה לכספת

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

מה שינינו

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

מדדים לפני ואחרי

34 שירותים עברו מיגרציה. כשלים בגלל תעודות שפג תוקפן ומפתחות לא מסונכרנים — 3-4 ברבעון — נעלמו: החידוש מתבצע בלי מעורבות אדם. רוטציית מפתח היא פעולה אחת במקום חלון מתוכנן עם מעבר בין צוותים, ושחזור גישה אחרי החלפת עובד — דקות במקום שעות.

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

במה שונה כספת סודות ממשתני סביבה

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

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

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

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

שאלות נפוצות על אינטגרציה של כספת עם שירותים

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

איך מתחברים שירותים מחוץ לענן?

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

איך מתבצעת רוטציה בלי השבתה?

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

מה עם גישה אחרי העברת פרויקט?

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

נדון במשימה ונחזור עם הערכה ותוכנית עבודה

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

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

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