Secrets Management: Vault, KMS, ולמה .env בפרודקשן זו טעות

מאת צוות מדיה דיל · 03.09.2026 · אבטחת מידע · 6 דק׳

הבעיה עם .env בפרודקשן, סודות דינמיים ב-Vault, Envelope Encryption ב-KMS, רוטציה אוטומטית, Least Privilege, והזרקת סודות נכונה ב-CI/CD.

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

למה .env בפרודקשן זו טעות

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

HashiCorp Vault: סודות דינמיים ולא סטטיים

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

Cloud KMS ו-Envelope Encryption

שירותי KMS (AWS KMS, GCP Cloud KMS) לא בהכרח מחזיקים את הסוד עצמו אלא מצפינים אותו — Envelope Encryption מצפין את הנתון עם מפתח נתונים (Data Key), ואת מפתח הנתונים עצמו מצפינים עם מפתח מאסטר שנשמר ב-KMS ולעולם לא עוזב אותו. גם אם הנתון המוצפן דולף, הוא חסר ערך בלי גישה למפתח המאסטר.

רוטציה אוטומטית: לא רק אירוע תגובה לדליפה

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

Least Privilege: לא כל שירות צריך את כל הסודות

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

OAuth Tokens כחלופה לסודות סטטיים

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

Secrets ב-CI/CD: הזרקה ב-Runtime, לא אפייה לתוך האימג'

סוד שנכתב לתוך Dockerfile או Environment Variable שנאפה לתוך אימג' Docker נשאר בכל Layer של האימג' לצמיתות, גם אם נמחק בשלב מאוחר יותר. הגישה הנכונה היא הזרקת סודות ב-Runtime בלבד — דרך Secret Manager שהאימג' פונה אליו כשהוא כבר רץ, כך שהאימג' עצמו נשאר נקי ובר-שיתוף בלי חשש.

ביקורת: מי ניגש למה ומתי

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

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

תגיות: Secrets Management · HashiCorp Vault · KMS · אבטחת מידע · DevOps

← חזרה לבלוג · צור קשר