0Pricing
Cyber Security Academy · Lección

Vaults y almacenes de secretos

Centralice los secretos con herramientas como Vault.

Vaults y almacenes de secretos es una lección gratuita de Cyber Security Academy en CoddyKit. Esta es la lección 2 de 4. Puedes leer la lección completa abajo gratuitamente — luego la practicas en el navegador con un editor de código integrado y un tutor de IA 24/7. Forma parte de la ruta de aprendizaje de Cyber Security Academy, y tu progreso se sincroniza en la web y la app de CoddyKit. El curso de Cyber Security Academy incluye 4 lecciones en total.

Qué resuelve un almacén de secretos

Un almacén de secretos (o vault) es un servicio centralizado y reforzado cuya única función es almacenar secretos, controlar el acceso a ellos y auditarlo. Sustituye los archivos dispersos y las variables de entorno que provocan la proliferación.

Un buen gestor de secretos proporciona cuatro capacidades fundamentales:

  • Almacenamiento centralizado: una única fuente de verdad autorizada.
  • Control de acceso: políticas detalladas sobre quién y qué puede leer cada secreto.
  • Registro de auditoría: un registro de cada acceso para la respuesta ante incidentes.
  • Cifrado: secretos cifrados en reposo y en tránsito.

Algunos ejemplos son HashiCorp Vault, AWS Secrets Manager, Azure Key Vault y GCP Secret Manager.

Cómo está estructurado HashiCorp Vault

HashiCorp Vault es un gestor de secretos de código abierto muy utilizado. Organiza sus funciones en motores de secretos conectables montados en rutas.

  • Motor KV: almacena secretos estáticos de clave-valor.
  • Motor de bases de datos: genera credenciales de bases de datos dinámicas y de corta duración.
  • Motor PKI: emite certificados TLS bajo demanda.
  • Motor Transit: proporciona cifrado como servicio sin exponer las claves.

Puede interactuar con Vault mediante una API HTTP o la CLI. Cada ruta se rige por políticas que determinan quién puede leer o escribir en ella.

# Enable a KV v2 secrets engine at the 'secret/' path
vault secrets enable -path=secret kv-v2

# Write and read a static secret
vault kv put secret/app/db password='S3cr3t' user='app'
vault kv get secret/app/db

El modelo de sellado y desellado

Vault protege sus datos mediante un mecanismo de sellado/desellado. Cuando Vault se inicia, está sellado: sabe dónde están los datos cifrados, pero no puede descifrarlos.

La clave maestra que descifra el almacenamiento está cifrada a su vez mediante una clave de desellado. Mediante Shamir's Secret Sharing, esa clave de desellado se divide en varios fragmentos que se distribuyen entre distintos operadores.

Debe proporcionarse un umbral configurable (por ejemplo, 3 de 5 fragmentos) para reconstruir la clave y desellar Vault. Ninguna persona puede desellarlo por sí sola, lo que protege frente al compromiso interno.

# Initialize Vault: 5 key shares, threshold of 3 to unseal
vault operator init -key-shares=5 -key-threshold=3

# Each operator supplies one shard until threshold is met
vault operator unseal <shard-1>
vault operator unseal <shard-2>
vault operator unseal <shard-3>

Autenticación: ¿Quién es usted?

Antes de leer cualquier secreto, un cliente debe autenticarse para obtener un token. Vault admite muchos métodos de autenticación adaptados a distintas identidades:

  • AppRole para aplicaciones y sistemas de CI (ID de rol + ID secreto).
  • Kubernetes utiliza el token de la cuenta de servicio del pod.
  • AWS/GCP/Azure IAM confía en la identidad de la plataforma en la nube.
  • OIDC/LDAP para usuarios humanos mediante SSO.

El principio clave es que la identidad proviene de la plataforma, no de una contraseña de larga duración. Un pod de Kubernetes demuestra quién es mediante su propio token de cuenta de servicio; no hay ningún secreto de arranque que pueda filtrarse.

# App authenticates via AppRole to receive a token
vault write auth/approle/login \
  role_id="db-app-role" \
  secret_id="$WRAPPED_SECRET_ID"
# Response includes client_token used for subsequent reads

Autorización mediante políticas

La autenticación demuestra la identidad; las políticas determinan qué puede hacer esa identidad. Las políticas de Vault se escriben en HCL y siguen el principio de mínimo privilegio: conceden únicamente las rutas y capacidades que necesita una carga de trabajo.

Esta política permite que un servicio lea únicamente su propio secreto de base de datos y nada más:

Las capacidades se corresponden con verbos de API: read, create, update, delete y list. Deniegue todo de forma predeterminada; conceda permisos explícitamente.

# policy: billing-app.hcl
path "secret/data/billing/*" {
  capabilities = ["read"]
}
path "database/creds/billing-readonly" {
  capabilities = ["read"]
}
# everything else is implicitly denied

Almacenes de secretos nativos de la nube

Si ejecuta sus cargas en una sola nube, el almacén gestionado del proveedor elimina la carga operativa: no hay que sellar ni desellar, ni servidores que parchear:

  • AWS Secrets Manager se integra con IAM y admite funciones Lambda de rotación integradas.
  • Azure Key Vault almacena secretos, claves y certificados mediante RBAC.
  • GCP Secret Manager ofrece secretos versionados protegidos por vinculaciones de IAM.

El acceso se rige por el IAM de la nube, de modo que una carga de trabajo lee un secreto utilizando su rol existente; no necesita una contraseña independiente. La contrapartida es la dependencia del proveedor y una compatibilidad multinube más limitada que la de Vault.

# Read a secret from AWS Secrets Manager (workload uses its IAM role)
aws secretsmanager get-secret-value \
  --secret-id prod/billing/db \
  --query SecretString --output text

# GCP equivalent
gcloud secrets versions access latest --secret=billing-db

Cifrado como servicio

A veces no desea almacenar un secreto en absoluto: quiere cifrar los datos de la aplicación sin que su aplicación llegue a tener la clave de cifrado. El motor Transit de Vault hace exactamente eso.

La aplicación envía texto plano a Vault, recibe texto cifrado y nunca ve la clave. El descifrado funciona de la misma manera. Esto se denomina cifrado como servicio.

La ventaja es que las claves viven únicamente dentro de Vault, pueden rotarse de forma centralizada y una aplicación comprometida no puede filtrar una clave que nunca tuvo.

# Encrypt data without the app ever seeing the key
vault write transit/encrypt/orders-key \
  plaintext=$(echo -n 'card=4111...' | base64)
# returns: ciphertext=vault:v1:abc123...

# Decrypt later
vault write transit/decrypt/orders-key ciphertext='vault:v1:abc123...'

Inyección de secretos en cargas de trabajo

Un almacén seguro solo es útil si las aplicaciones pueden consumir secretos sin hardcodear la ruta ni el token. Patrones habituales de inyección:

  • Sidecar/agente: un Vault Agent se ejecuta junto a la aplicación, se autentica y escribe los secretos en un volumen compartido en memoria.
  • CSI driver: Kubernetes monta los secretos como archivos mediante el Secrets Store CSI driver.
  • Obtención mediante SDK: la aplicación llama directamente a la API del almacén al iniciarse.

Prefiera montar los secretos en un sistema de archivos en memoria (tmpfs) en lugar de usar variables de entorno, y evite escribirlos en disco, donde podrían persistir.

# Vault Agent template renders a secret to an in-memory file
template {
  contents = "DB_PASS={{ with secret \"secret/app/db\" }}{{ .Data.data.password }}{{ end }}"
  destination = "/run/secrets/db.env"
}

Registro de auditoría y rendición de cuentas

Cada evento de lectura, escritura y autenticación en una bóveda debería registrarse en un registro de auditoría. Esto es lo que permite defender la gestión de secretos durante un incidente.

Los registros de auditoría responden a las preguntas fundamentales: quién accedió a qué secreto, cuándo y desde dónde. Vault aplica hashes a los valores sensibles en los registros para que el propio registro no revele secretos.

Envíe los registros de auditoría a un sistema independiente y con evidencia de manipulación (SIEM), de modo que un atacante que comprometa el host de Vault no pueda borrar también las pruebas de a qué secretos accedió.

# Enable a file audit device (HMAC-hashes secret values)
vault audit enable file file_path=/var/log/vault/audit.log

# Forward to a SIEM/syslog endpoint for tamper resistance
vault audit enable syslog tag="vault" facility="AUTH"

Protección de la bóveda

Un almacén centralizado concentra el riesgo: si la bóveda cae, todo cae. Refuércela como su activo más crítico:

  • Ejecute TLS en todos los endpoints; nunca exponga la API sin cifrado.
  • Mantenga la bóveda en una red privada, protegida por reglas de firewall estrictas.
  • Habilite auto-unseal mediante un KMS en la nube para evitar la gestión manual de fragmentos, pero proteja rigurosamente esa clave de KMS.
  • Use TTL cortos para los tokens y leases renovables, de modo que los tokens robados caduquen rápidamente.
  • Aplique los parches sin demora y supervise los registros de auditoría para detectar anomalías.

La bóveda cambia muchos puntos de fallo por uno solo, defendido con extremo rigor.

Elegir el almacén adecuado

No existe una única herramienta mejor; adapte el almacén a su entorno:

  • Una sola nube y necesidades sencillas: use el gestor nativo (AWS/Azure/GCP) para reducir al mínimo la carga operativa.
  • Multinube o local: HashiCorp Vault proporciona una abstracción coherente y portable.
  • Si necesita secretos dinámicos o cifrado como servicio: los motores de Vault son los más completos.
  • Entornos centrados en Kubernetes: combine un almacén con el controlador CSI o con un operador como External Secrets.

Elija lo que elija, el objetivo es el mismo: una única fuente de verdad auditada y con acceso controlado que sustituya al texto sin cifrar disperso.

Comprobación rápida

Compruebe su comprensión del modelo de protección de Vault.

Resumen: Vault y almacenes de secretos

Ha aprendido a sustituir los secretos dispersos por un almacén centralizado y auditado.

  • Un almacén de secretos proporciona almacenamiento centralizado, control de acceso, registros de auditoría y cifrado.
  • HashiCorp Vault utiliza motores de secretos conectables y un modelo de seal/unseal protegido por Shamir's Secret Sharing.
  • Los métodos de autenticación derivan la identidad de la plataforma (Kubernetes, IAM, AppRole), y las políticas imponen el mínimo privilegio.
  • Los almacenes nativos de la nube (AWS, Azure, GCP) sacrifican portabilidad a cambio de una menor carga operativa.
  • El Transit engine ofrece cifrado como servicio, de modo que las aplicaciones nunca almacenan las claves.
  • Inyecte secretos mediante agentes o CSI en almacenamiento en memoria, registre cada acceso y refuerce la bóveda como su activo más crítico.

A continuación, haremos que los secretos sean aún más seguros generándolos de forma dinámica y con una duración corta.

Preguntas frecuentes

¿La lección «Vaults y almacenes de secretos» es gratis?

Sí — el texto completo de «Vaults y almacenes de secretos» es gratis para leer aquí en la web. Para practicarla de forma interactiva (editor de código integrado y tutor de IA 24/7) y desbloquear el resto del curso de Cyber Security Academy, actualiza a CoddyKit PRO. El curso de Cyber Security Academy incluye 4 lecciones en total.

¿Qué aprenderé en «Vaults y almacenes de secretos»?

Centralice los secretos con herramientas como Vault. Practicas Cyber Security Academy con código real que ejecutas directamente en el navegador, y un tutor de IA 24/7 responde tus preguntas mientras trabajas en la lección.

¿Necesito experiencia previa para empezar Cyber Security Academy?

No se requiere experiencia previa. Cyber Security Academy en CoddyKit está estructurado para principiantes hasta estudiantes avanzados, así que puedes empezar aquí o desde el inicio y avanzar a tu ritmo. Esta es la lección 2 de 4.

¿Cuánto tiempo toma la lección «Vaults y almacenes de secretos»?

La mayoría de las lecciones de CoddyKit toman alrededor de 5–10 minutos. Cada una es compacta e interactiva, así que avanzas constantemente y retomas exactamente por donde dejaste en la web y la app.

¿Puedo escribir y ejecutar código en esta lección de Cyber Security Academy?

Sí. Cada lección de Cyber Security Academy incluye un editor de código integrado, así que escribes y ejecutas código real directamente en tu navegador y obtienes retroalimentación instantánea de IA — sin configuración local necesaria.

Todas las lecciones de este curso

  1. El problema de la proliferación de secretos
  2. Vaults y almacenes de secretos
  3. Secretos dinámicos y leasing
  4. Rotación y detección de claves
← Volver a Cyber Security Academy