Bóveda de secretos
AiHummer almacena cada credencial: tokens de canal, contraseñas SMTP/IMAP, tokens OAuth, claves LLM por inquilino (BYOK), en un bóveda de secretos encriptados. La bóveda utiliza cifrado de sobre para que el valor en reposo nunca sea legible únicamente desde la base de datos, y está diseñada de manera que un secreto nunca se colocó en el contexto del modelo ni en los registros.
Cifrado de sobres
La bóveda utiliza una jerarquía de claves de dos niveles:
- A clave maestra (KEK) — suministrado como
AIHUMMER_MASTER_KEY, codificado en base64 Valor de 32 bytes: envuelve y desenrolla las claves de datos. Nunca abandona el host y nunca se escribe en la base de datos. - A clave de cifrado de datos (DEK) por inquilino cifra los valores secretos reales con AES-256-GCM (cifrado autenticado). Cada inquilino tiene su propia DEK, así que las llaves de un inquilino no pueden descifrar los secretos de otro inquilino.
Los valores secretos se almacenan como texto cifrado; la DEK se almacena envuelta por la KEK. La descifrado ocurre en la memoria en el momento en que se necesita un secreto (por ejemplo, cuando un conector se autentica), y el texto plano se descarta posteriormente.
AIHUMMER_MASTER_KEY (KEK) ──wraps──▶ per-tenant DEK ──AES-256-GCM──▶ secret value[!NOTE] La bóveda depende de PostgreSQL
pgcryptoextensión. Asegúrate de que lo sea disponible en su base de datos — es parte de los requisitos estándar del sistema.
La llave maestra
La clave maestra es un valor de arranque: se lee del entorno al iniciar y es no configurable desde la interfaz de administración. El instalador (y el gateway en el primer inicio) siempre crea AIHUMMER_MASTER_KEY — no es opcional, porque los secretos en reposo, la bóveda de credenciales y el BYOK por inquilino dependen de ello. Por lo tanto, una instalación estándar siempre tiene uno.
# /home/.aihummer/etc/gateway.env
# 32 random bytes, base64-encoded
AIHUMMER_MASTER_KEY=Base64Of32RandomBytes==Puedes generar uno con:
openssl rand -base64 32[!WARNING] La llave maestra es necesaria para descifrar todo en la bóveda. Trátala como la raíz de tus secretos y haz una copia de seguridad por separado de la base de datos — si si lo pierdes, los valores encriptados no se pueden recuperar. Ver Operaciones para guía de respaldo.
Si falta la llave maestra
Debido a que la clave siempre está aprovisionada, una instalación estándar siempre tiene un cofre funcional. El comportamiento aquí es un guardia de fallo cerrado para el caso poco común en el que AIHUMMER_MASTER_KEY está de alguna manera sin configurar (por ejemplo, un archivo env editado a mano): la bóveda y todo lo que depende de ella están deshabilitada — el almacenamiento de secretos en reposo, la bóveda de credenciales y las claves BYOK por inquilino están todos desactivados. Esto es deliberado: el producto no recurre silenciosamente a almacenar secretos en texto plano.
Los secretos nunca llegan al modelo
Esta es la propiedad más importante de la bóveda, y es estructural en lugar de un recordatorio de política.
[!DANGER] Los secretos son nunca inyectado en el aviso del sistema, la conversación historia, o cualquier texto visible del modelo, y ellos son nunca escrito en registros. Las herramientas que necesitan una credencial la resuelven desde la bóveda en el momento de la llamada, internamente la puerta de enlace, y úsala para autenticar la solicitud saliente — solo el modelo siempre ve el resultado de la llamada de la herramienta, no el secreto.
Porque la interactividad está impulsada por la llamada de herramientas (ver Barreras de protección y defensa contra la inyección de indicaciones), no existe un camino por el cual un aviso pueda pedirle al modelo que “lea” un secreto almacenado: el modelo no tiene una copia de él para leer.
Credenciales compartidas y por usuario
La bóveda distingue entre compartida credenciales (a nivel de espacio de trabajo) y personal Credenciales (por usuario). Los tokens OAuth2 por usuario obtenidos a través del flujo de Conexiones se almacenan en la bóveda y son resueltos por el usuario que actúa, con una alternativa de espacio de trabajo cuando sea apropiado. Esto permite que la misma herramienta actúe en nombre de diferentes usuarios con su propia autorización, sin exponer nunca el token de un usuario a otro.
¿A dónde vamos ahora?
- RBAC y claves API con alcance — quién puede leer o cambiar configuración respaldada por vault.
- Seguridad a nivel de fila — aislamiento por inquilino en el base de datos que respalda la bóveda.
- Barreras de protección y defensa contra la inyección de indicaciones — por qué el modelo nunca puede ser engañado para revelar un secreto.