כל צוות מגיע בשלב כלשהו למצב שבו פרטי ההתחברות נמצאים ביותר מדי מקומות: קובץ .env בכל מחשב נייד, הודעה מוצמדת ב-Slack, גיליון בשם "logins", משתנה CI שמישהו הגדיר לפני שנתיים. מנהל סודות בענן קיים כדי לרכז את כל זה במקום אחד, מוצפן, עם בקרת גישה ויומן ביקורת.
המדריך הזה מסביר מה מנהל סודות בענן עושה, איך בוחרים בין האפשרויות העיקריות, איך מטמיעים אותו בלי הגירה ארוכה, ומה הדבר היחיד שהוא לא עושה: להעביר סוד לאדם שלא נמצא בתוך חשבון הענן שלכם.
מה מנהל סודות בענן עושה
מנהל סודות שומר ערכים רגישים ומוסר אותם לזהויות מורשות לפי בקשה. התכונות הבסיסיות זהות אצל כל הספקים:
- אחסון מוצפן במנוחה, עם מפתחות שנשמרים בשירות ניהול המפתחות של הספק, ו-TLS בזמן ההעברה.
- גישה לפי זהות: לכל סוד יש מדיניות שקובעת אילו משתמשים, תפקידים או עומסי עבודה רשאים לקרוא אותו, לכתוב אותו או להחליף אותו. אפליקציה מזדהה בזהות משלה, לא בסיסמת מאסטר.
- יומן ביקורת של כל קריאה, כתיבה והחלפה: מי, מה ומתי.
- גרסאות והחלפה: אפשר להכין ערך חדש, להעביר אליו את האפליקציות ולהוציא משימוש את הגרסה הישנה. מנהלי סודות רבים מחליפים פרטי התחברות למסדי נתונים באופן אוטומטי.
- שליפה בזמן ריצה: האפליקציה מושכת את הסוד כשהיא עולה או כשהיא צריכה אותו, כך שהערך אף פעם לא נכתב בקוד, באימג'ים או בקובצי תצורה.
סוד הוא כל דבר שמעניק גישה. תצורה שרק מתארת התנהגות, כמו מספר פורט או feature flag, שייכת לתצורה הרגילה. ערבוב של השניים ממלא את מאגר הסודות ברעש והופך את מאגר התצורה למסוכן.
איך בוחרים
ההחלטה תלויה בדרך כלל במקום שבו עומסי העבודה רצים ובמספר העננים שאתם משתמשים בהם.
| אפשרות | מתאים במיוחד ל | שימו לב ל |
|---|---|---|
| AWS Secrets Manager / Parameter Store | עומסי עבודה שכבר רצים ב-AWS, זהויות IAM בכל מקום | תמחור לפי סוד ב-Secrets Manager; Parameter Store זול יותר לערכים פשוטים |
| Google Secret Manager | פרויקטים ב-GCP, עומסי עבודה ב-Cloud Run וב-GKE | אפשרויות השכפול בין אזורים |
| Azure Key Vault | עומסי עבודה ב-Azure, צורך בניהול מחזור החיים של תעודות | כספות נפרדות לכל סביבה כדי שהמדיניות תישאר פשוטה |
| HashiCorp Vault | ריבוי עננים או שרתים מקומיים, פרטי התחברות דינמיים לטווח קצר | תפעול עצמי, אלא אם משתמשים בגרסה המתארחת |
| Doppler, Infisical, 1Password Secrets Automation | צוותים קטנים שרוצים סנכרון נוח למפתחים לפלטפורמות רבות | ספק נוסף בשרשרת האמון |
ארבע שאלות מכריעות את רוב הבחירות. האם הוא משתלב בכלי הפריסה ובסביבת הריצה שלכם בלי קוד חיבור ייעודי? האם עומסי העבודה יכולים להזדהות מולו בזהות שכבר יש להם? האם הוא מחליף את סוגי פרטי ההתחברות שיש לכם בפועל? והאם יומני הביקורת שלו מגיעים למקום שצוות האבטחה כבר מסתכל בו? מחירים, אזורים ואישורי תאימות באים אחרי ארבע השאלות האלה.
הטמעה בלי פרויקט של חצי שנה
- מיפוי והגדרת אחראים. רשמו כל סוד, איפה הוא נמצא, מה משתמש בו ומי אחראי עליו. האחראי קובע את מדיניות ההחלפה ואת רשימת הגישה.
- קודם הזהויות. צרו את התפקידים או חשבונות השירות לכל עומס עבודה ולכל סביבה לפני שאתם מעבירים ערך אחד. מדיניות גישה שאומרת "השירות הזה, הסביבה הזאת, קריאה בלבד" היא כל העניין.
- הגירה לפי סדר הסיכון. קודם סיסמאות של מסדי נתונים בסביבת הייצור ומפתחות תשלום, אחר כך מפתחות API של צד שלישי, ואחר כך כל השאר. הסירו כל ערך מהקוד, ממשתני ה-CI ומקובצי התצורה כשהוא עובר, והחליפו אותו בדרך פנימה, כי הערך הישן כבר הועתק לכל מיני מקומות.
- שינוי הדרך שבה אפליקציות קוראות סודות. החליפו ערכים שמקודדים בקוד וקובצי סביבה בקריאה ל-SDK של מנהל הסודות כשהאפליקציה עולה, או הזריקו אותם דרך האינטגרציה המובנית של הפלטפורמה.
- הפעלת החלפה אוטומטית לכל מה שמנהל הסודות יכול להחליף בעצמו, וכתיבת פונקציית החלפה או נוהל עבודה לכל השאר.
- התראה על חריגות. קריאה של סוד מזהות חדשה, קפיצה בכמות הקריאות או קריאה מאזור שאתם לא פורסים אליו מצדיקות הקפצה של התורן.
הטעויות הנפוצות צפויות: להשאיר את העותקים הישנים במקומם אחרי ההגירה, לתת לעומס עבודה גישת קריאה לכל המאגר במקום לסודות שלו בלבד, ולרשום את הערך שנשלף ביומני האפליקציה.
הפער שמנהל סודות לא סוגר
מנהל סודות בנוי למכונות ולאנשים שנמצאים בתוך מערכת הזהויות שלכם. הוא לא בנוי לרגע שבו פרטי התחברות צריכים להגיע למישהו מחוצה לה: קבלן חיצוני שצריך סיסמה זמנית למסד נתונים, לקוח שמקבל את פרטי ההתחברות הראשונים שלו כמנהל, מהנדס של ספק שצריך טוקן לאחר צהריים אחד, עובד חדש ביום הראשון שלו לפני שחשבון ה-SSO שלו קיים.
המסירות האלה קורות בכל מקרה, ובלי דרך מאושרת הן קורות באימייל ובצ'אט, בדיוק המקומות שמנהלי סודות היו אמורים להוציא מהם את פרטי ההתחברות. הדרך המאושרת היא קישור סודי חד-פעמי. הערך מוצפן בדפדפן שלכם לפני שהוא נשמר, ההודעה מכילה רק קישור, העותק השמור מושמד בפעם הראשונה שהקישור נפתח, ותוקף הקישור פג לפי טיימר אם אף אחד לא פותח אותו.
הדפוס שעובד: מנהל הסודות הוא מקור האמת של הערכים, והקישור החד-פעמי הוא מנגנון המסירה כשאדם מחוץ למערכת צריך ערך פעם אחת. צרו את פרטי ההתחברות, שמרו אותם במנהל הסודות, שלחו אותם לאדם בקישור חד-פעמי, והחליפו אותם כשהגישה שלו מסתיימת. המאמר קישורים סודיים לעומת מנהלי סיסמאות מחיל את אותו היגיון על מנהל הסיסמאות של הצוות, והמדריך להעברת פרטי התחברות בין צוותים מכסה את השגרה.
רשימת בדיקה קצרה
- לכל סוד יש אחראי, מדיניות גישה וכלל החלפה.
- עומסי עבודה מזדהים בזהות משלהם, אף פעם לא במפתח משותף.
- אחרי ההגירה אין אף סוד בקוד, באימג'ים, במשתני CI או בצ'אט.
- הקריאות נרשמות ביומן במקום שמישהו באמת מסתכל בו.
- אנשים מחוץ למערכת הזהויות מקבלים סודות בקישור חד-פעמי, לא בהודעה.
עשו את חמשת הדברים האלה, ומנהל הסודות יפסיק להיות מוצר שקניתם ויהפוך לסיבה שפרטי ההתחברות הפסיקו לדלוף.