הגדרת ניהול סודות דרך AWS Secrets Manager

AWS Secrets Manager: היכן דולפים סודות בסביבה שלכם

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

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

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

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

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

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

מה נותנים אחסון מרוכז ורוטציה של סודות

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

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

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

אפשרויות אחסון סודות: השוואת גישות

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

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

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

לכן משתני סביבה משאירים בדרך כלל לדברים קטנים, ואת סודות העבודה מעבירים לשירות ענן — למשל AWS Secrets Manager, שבו רוטציה וביקורת מובנות בשירות עצמו.

הטמעת Secrets Manager: שלבי עבודה ובדיקות

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

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

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

מדיניות גישה, סכמות ותקנות רוטציה

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

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

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

מקרה בוחן: רוטציה של מפתחות גישה בלי לעצור שירותים

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

מה היה לפני השינויים

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

מה שינו ומה התקבל

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

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

מה לעשות אם סודות כבר התפזרו בתצורות

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

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

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

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

שאלות נפוצות על ניהול סודות וגישה

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

איך מפרידים הרשאות בין שירותים, אנשים וסביבות?

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

מה נכנס ליומן הפניות?

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

מה יקרה אם הגישה אבדה?

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

נדון בסכמת העבודה שלכם עם סודות

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

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

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