Gestión de contraseñas y secretos en infraestructura: Passbolt, Vault y buenas prácticas

Introducción: El problema crítico de los secretos en producción

Tras más de una década administrando infraestructuras, puedo asegurar que la gestión deficiente de contraseñas y secretos es el vector de ataque más explotado que he visto en compromisos de seguridad. Las clásicas hojas de cálculo compartidas por email, archivos .env en repositorios Git y contraseñas hardcodeadas en scripts siguen siendo norma en demasiadas organizaciones.

La realidad es brutal: un compromiso de una sola credencial administrativa puede deshabilitar años de inversión en seguridad perimetral. Es por esto que herramientas modernas como Passbolt y HashiCorp Vault se han convertido en elementos críticos de cualquier infraestructura seria.

Análisis comparativo: Passbolt vs HashiCorp Vault

Passbolt: Gestión colaborativa de contraseñas

Passbolt es un gestor de contraseñas de código abierto específicamente diseñado para equipos de operaciones. Su fortaleza radica en la facilidad de implementación y en la experiencia de usuario.

Características principales:

• Interfaz web intuitiva y extensión para navegadores
• Cifrado end-to-end usando OpenPGP
• Auditoría completa de acceso a cada credencial
• Soporte para estructuras organizacionales complejas
• API REST para integración programática

Casos de uso ideales:

• Equipos pequeños a medianos (10-100 personas)
• Equipos de helpdesk que necesitan compartir credenciales de forma segura
• Organizaciones con requerimientos de cumplimiento regulatorio (SOC 2, ISO 27001)

HashiCorp Vault: Orquestación de secretos a escala

Vault es más que un gestor de contraseñas: es una plataforma de gestión de identidad y secretos. Proporciona cifrado dinámico, rotación automática y acceso basado en roles.

Características principales:

• Generación dinámica de credenciales (bases de datos, APIs)
• Soporte para múltiples motores de secretos (SSH, PKI, bases de datos)
• Políticas de acceso granulares con Sentinel
• Integración nativa con orquestadores modernos (Kubernetes, Terraform)
• Replicación de alta disponibilidad

Casos de uso ideales:

• Infraestructuras de microservicios en Kubernetes
• Organizaciones con cientos de aplicaciones
• Equipos que requieren rotación automática de credenciales
• Entornos híbridos multi-cloud

Implementación práctica: Passbolt en producción

Aquí un enfoque dockerizado típico:

version: '3.8'
services:
  passbolt:
    image: passbolt/passbolt:4.2-ce
    container_name: passbolt
    restart: always
    ports:
      - "443:443"
    environment:
      PASSBOLT_HOSTNAME: passbolt.empresa.local
      PASSBOLT_SSL_FORCE: "true"
      PASSBOLT_SELENIUM_ACTIVE: "false"
      DB_HOST: postgres
      DB_NAME: passbolt
      DB_USER: passbolt
      DB_PASS: ${DB_PASSWORD}
      DATASOURCES_DEFAULT_USERNAME: passbolt
      DATASOURCES_DEFAULT_PASSWORD: ${DB_PASSWORD}
      APP_FULL_BASE_URL: "https://passbolt.empresa.local"
    depends_on:
      - postgres
    volumes:
      - passbolt_gpg:/var/www/passbolt/config/gpg
      - passbolt_jwt:/var/www/passbolt/config/jwt
    networks:
      - passbolt_network

  postgres:
    image: postgres:15-alpine
    container_name: passbolt_db
    restart: always
    environment:
      POSTGRES_DB: passbolt
      POSTGRES_USER: passbolt
      POSTGRES_PASSWORD: ${DB_PASSWORD}
    volumes:
      - passbolt_db:/var/lib/postgresql/data
    networks:
      - passbolt_network

networks:
  passbolt_network:

volumes:
  passbolt_gpg:
  passbolt_jwt:
  passbolt_db:

Implementación práctica: HashiCorp Vault en Kubernetes

Para entornos containerizados, Vault requiere una aproximación distinta. Aquí la configuración de un agente inyectado:

# Policy de aplicación en Vault
path "secret/data/app/database" {
  capabilities = ["read", "list"]
}

path "database/static-creds/app-user" {
  capabilities = ["read"]
}

# ServiceAccount en Kubernetes
apiVersion: v1
kind: ServiceAccount
metadata:
  name: app-account
  namespace: production

---
# Pod con inyección de Vault
apiVersion: v1
kind: Pod
metadata:
  name: app-pod
  namespace: production
  annotations:
    vault.hashicorp.com/agent-inject: "true"
    vault.hashicorp.com/role: "app-role"
    vault.hashicorp.com/agent-inject-secret-database: "secret/data/app/database"
    vault.hashicorp.com/agent-inject-template-database: |
      {{- with secret "secret/data/app/database" -}}
      export DB_USER="{{ .Data.data.username }}"
      export DB_PASS="{{ .Data.data.password }}"
      {{- end }}
spec:
  serviceAccountName: app-account
  containers:
  - name: app
    image: app:1.0
    command: ["/bin/sh", "-c"]
    args: ["source /vault/secrets/database && exec /start.sh"]

Buenas prácticas fundamentales

1. Nunca comprometer el modo de almacenamiento

Ambas soluciones requieren:

• Almacenamiento backend encriptado (base de datos con TDE o equivalente)
• Backups encriptados en localizaciones geográficamente distribuidas
• Recuperación de desastres probada regularmente

2. Rotación automática de credenciales

En Vault, activar rotación dinámicamente:

vault write -f database/rotate-root/postgres-prod
vault write database/roles/app-role \
  db_name="postgres-prod" \
  creation_statements="CREATE USER \"{{name}}\" WITH PASSWORD '{{password}}';" \
  default_ttl="1h" \
  max_ttl="24h"

3. Auditoría exhaustiva

Registrar:

• Quién accedió a qué secreto
• Cuándo se accedió
• Desde dónde se accedió
• Si tuvo éxito o falló

4. Principio de menor privilegio

Cada aplicación y usuario debe tener acceso ÚNICAMENTE a los secretos que necesita operativamente.

Errores comunes que he visto

• Migración sin planificación: Cambiar de gestor sin runbook de rollback causa indisponibilidades
• Falta de HA: Un único nodo de Vault es un punto único de fallo crítico
• Permisos demasiado permisivos: Dar acc