HashiCorp Vault: הגדרת ניהול סודות ארגוני

הטמעת HashiCorp Vault: ניהול סודות מרכזי

אנו מסייעים לחברות לחסל חוב טכנולוגי הקשור לאחסון סודות בקבצי .env וב-Kubernetes Secrets על ידי הטמעת HashiCorp Vault. זה לא רק vault.hcl — זה כולל תכנון קלאסטר עמיד לתקלות, הגדרת auto-unseal, אינטגרציה עם CI/CD, והבטחת ביקורת גישה מלאה. המהנדסים שלנו מוסמכים על ידי HashiCorp ובעלי ניסיון של למעלה מ-5 שנים עם Vault. על פי מחקרים, 80% מפרצות הנתונים קשורות לפרטי כניסה שנפגעו, כשהעלות הממוצעת עולה על 4 מיליון דולר. Vault מפחית סיכון זה בסדר גודל, עם חיסכון פוטנציאלי של עד 3.6 מיליון דולר לכל אירוע שנמנע, מה שהופך אותו לכלי חיוני.

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

למה Vault עדיף על סיסמאות סטטיות

בניגוד ל-LastPass או 1Password, Vault לא רק מאחסן סיסמאות — הוא מייצר דינמית פרטי כניסה זמניים למסדי נתונים, שירותי ענן ו-APIs. לדוגמה, אם סוד נפגע, הוא חי לא יותר מ-TTL מוגדר (בדרך כלל שעה), ולאחר מכן Vault מבטל אותו אוטומטית. זה מקטין את חלון הפגיעות פי 144 בהשוואה לסיסמאות סטטיות שעשויות להישאר תקפות למשך שבועות.

ארכיטקטורה: Standalone לעומת HA Cluster

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

תצורת Vault (ui = true cluster_addr = "https://vault-1.internal:8201" api_addr = "https://vault-1.internal:8200" storage "raft" { path = "/opt/vault/data" node_id = "vault-1" retry_join { leader_api_addr = "https://vault-2.internal:8200" } retry_join { leader_api_addr = "https://vault-3.internal:8200" } } listener "tcp" { address = "0.0.0.0:8200" tls_cert_file = "/opt/vault/tls/vault.crt" tls_key_file = "/opt/vault/tls/vault.key" tls_client_ca_file = "/opt/vault/tls/ca.crt" } seal "awskms" { region = "eu-central-1" kms_key_id = "alias/vault-unseal" } ) עבור Raft HA:

ui = true
cluster_addr = "https://vault-1.internal:8201"
api_addr = "https://vault-1.internal:8200"

storage "raft" {
  path = "/opt/vault/data"
  node_id = "vault-1"

  retry_join {
    leader_api_addr = "https://vault-2.internal:8200"
  }

  retry_join {
    leader_api_addr = "https://vault-3.internal:8200"
  }
}

listener "tcp" {
  address = "0.0.0.0:8200"
  tls_cert_file = "/opt/vault/tls/vault.crt"
  tls_key_file = "/opt/vault/tls/vault.key"
  tls_client_ca_file = "/opt/vault/tls/ca.crt"
}

seal "awskms" {
  region = "eu-central-1"
  kms_key_id = "alias/vault-unseal"
}

seal "awskms" — auto-unseal באמצעות AWS KMS. קריטי לייצור: בלעדיו, כל אתחול צומת דורש הזנת מפתח unseal ידני. עם auto-unseal, Vault מבצע unseal אוטומטית בעת ההפעלה באמצעות מפתח KMS.

כיצד שירותים מאמתים את עצמם מול Vault

Vault אינו עובד עם שם משתמש/סיסמה יחיד לכולם. כל לקוח מאמת את עצמו באמצעות השיטה שלו:

Kubernetes Auth — פודים מאמתים באמצעות אסימוני ServiceAccount JWT. Vault מאמת את האסימון דרך Kubernetes API.

vault auth enable kubernetes
vault write auth/kubernetes/config \
    kubernetes_host="https://kubernetes.default.svc" \
    token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)"
vault write auth/kubernetes/role/myapp \
    bound_service_account_names=myapp \
    bound_service_account_namespaces=production \
    policies=myapp-policy \
    ttl=1h

AWS IAM Auth — מופעי EC2 ופונקציות Lambda מאמתים באמצעות תפקידי IAM. Vault מאמת את החתימה באמצעות AWS STS vault auth enable kubernetes vault write auth/kubernetes/config \ kubernetes_host="https://kubernetes.default.svc" \ token_reviewer_jwt="$(cat /var/run/secrets/kubernetes.io/serviceaccount/token)" vault write auth/kubernetes/role/myapp \ bound_service_account_names=myapp \ bound_service_account_namespaces=production \ policies=myapp-policy \ ttl=1h .

AppRole — עבור מערכות CI/CD ללא שיטת אימות מובנית. Role ID מאוחסן במערכת ה-CI, Secret ID נוצר דינמית ותקף פעם אחת (GetCallerIdentity).

vault auth enable approle
vault write auth/approle/role/myapp policies=myapp-policy token_ttl=1h
# Получение Role ID и Secret ID
vault read auth/approle/role/myapp/role-id
vault write -force auth/approle/role/myapp/secret-id

מדיניות גישה: עקרון ההרשאות המינימליות

כל יישום מקבל רק את הסודות שהוא צריך:

# policy: myapp-policy.hcl
path "secret/data/production/myapp/*" {
  capabilities = ["read"]
}

path "database/creds/myapp-role" {
  capabilities = ["read"]
}

# Запрет на листинг других секретов
path "secret/data/production/+/*" {
  capabilities = ["deny"]
}

החל: vault auth enable approle vault write auth/approle/role/myapp policies=myapp-policy token_ttl=1h # Получение Role ID и Secret ID vault read auth/approle/role/myapp/role-id vault write -force auth/approle/role/myapp/secret-id

טעות נפוצה: הענקת מדיניות עם # policy: myapp-policy.hcl path "secret/data/production/myapp/*" { capabilities = ["read"] } path "database/creds/myapp-role" { capabilities = ["read"] } # Запрет на листинг других секретов path "secret/data/production/+/*" { capabilities = ["deny"] } ויכולות vault policy write myapp-policy myapp-policy.hcl. משמעות הדבר היא ששירות שנפגע מקבל גישה לכל עץ הסודות. RBAC באמצעות מדיניות הוא הדרך היחידה להימנע מכך.

Vault Agent: הזרקת סודות לפודים של Kubernetes

Vault Agent Injector — קונטיינר sidecar שמתקין סודות כקבצים לתוך הפוד ללא שינויי קוד. הערות פוד:

annotations:
  vault.hashicorp.com/agent-inject: "true"
  vault.hashicorp.com/role: "myapp"
  vault.hashicorp.com/agent-inject-secret-config.env: "secret/data/production/myapp/config"
  vault.hashicorp.com/agent-inject-template-config.env: |
    {{- with secret "secret/data/production/myapp/config" -}}
    DATABASE_URL={{ .Data.data.db_url }}
    API_KEY={{ .Data.data.api_key }}
    {{- end }}

הסודות מופיעים ב-path "secret/*". היישום קורא אותם כקובץ רגיל. בעת סיבוב סוד, Vault Agent מעדכן את הקובץ ויכול לאותת ליישום (SIGHUP) לטעון מחדש את התצורה.

יומן ביקורת וניטור

הפעלת התקן ביקורת היא חובה לייצור:

vault audit enable file file_path=/var/log/vault/audit.log 

כל בקשה ל-Vault מתועדת: מי ביקש, איזה נתיב, חותמת זמן, תוצאה. זה מהווה את הבסיס לניתוח SOC ותגובה לאירועים. Vault לא יתחיל אם יומן הביקורת אינו זמין לכתיבה — זו תכונה, לא באג. HashiCorp Vault מוסמך תחת SOC 2 Type II, המאשר אחסון סודות אמין.

השוואת גישות לניהול סודות

תהליך ההטמעה

1. ביקורת אחסון הסודות הנוכחי — מלאי של קבצי ["read", "list"], Kubernetes Secrets, תצורות CI/CD
2. תכנון היררכיית נתיבים — מבנה annotations: vault.hashicorp.com/agent-inject: "true" vault.hashicorp.com/role: "myapp" vault.hashicorp.com/agent-inject-secret-config.env: "secret/data/production/myapp/config" vault.hashicorp.com/agent-inject-template-config.env: | {{- with secret "secret/data/production/myapp/config" -}} DATABASE_URL={{ .Data.data.db_url }} API_KEY={{ .Data.data.api_key }} {{- end }} , מוסכמת שמות
3. פריסת קלאסטר Vault — Terraform + Ansible, TLS, auto-unseal, אתחול
4. הגדרת שיטות אימות עבור המחסנית (Kubernetes, AWS IAM, AppRole עבור CI)
5. העברת סודות — בשלבים, שירות אחר שירות, עם אימות
6. תיעוד ומסירה — runbook לתפעול: סיבוב root token, החלפת מפתחות unseal, שחזור מאסון

מה כלול בעבודה

• קלאסטר Vault פרוס (HA, auto-unseal, TLS)
• הגדרת שיטות אימות (Kubernetes, AWS IAM, AppRole)
• מדיניות גישה לכל שירות
• אינטגרציה עם CI/CD (GitLab CI, GitHub Actions)
• Vault Agent Injector עבור Kubernetes
• יומן ביקורת וניטור (Prometheus + Grafana)
• תיעוד והדרכת צוות
• אחריות ל-3 חודשים לאחר ההטמעה

העלות מחושבת באופן אישי לאחר ביקורת תשתית. המהנדסים שלנו מחזיקים בהסמכת HashiCorp Certified: Vault Operations Professional וביצעו למעלה מ-30 פרויקטים של ניהול סודות. צרו קשר לייעוץ — נבחן את התשתית שלכם ונציע את הפתרון האופטימלי. הזמינו הטמעת Vault במפתח והעלימו חוב טכנולוגי לנצח.

ויקיפדיה: HashiCorp Vault