Seguridad
Lo que garantiza la plataforma, y lo que solo puedes garantizar tú.
Cómo se guardan las claves
De una clave, la plataforma almacena su hash SHA-256 y su prefijo. La clave en claro no se guarda en ningún sitio, así que no se puede recuperar ni mostrar de nuevo: el listado enseña solo el prefijo, suficiente para distinguir una clave de otra sin revelarla.
Consecuencia práctica: nadie del equipo de la plataforma puede leerte una clave para ayudarte a depurar. Si la perdiste, el camino es revocarla y crear otra.
Transporte
Todo va por HTTPS. Una petición por HTTP plano expone la clave a cualquiera en el camino —la cabecera viaja en claro—, así que si tu cliente permite HTTP, desactívalo.
Qué queda registrado
| Qué | Dónde se consulta |
|---|---|
| Última vez que se usó cada clave | Ajustes → Claves de API |
| Quién creó y quién revocó cada clave | Ajustes → Registro de auditoría |
| Cada operación que modifica datos, con su autor | Ajustes → Registro de auditoría |
| Cada lectura de datos de salud, con quién la hizo | Ajustes → Registro de auditoría |
El registro de auditoría encadena sus entradas con un hash, de modo que borrar o alterar una rompe la cadena y se nota. Es lo que permite sostener ante un ente de control que el registro no se tocó.
Lo que te toca a ti
La mayoría de las claves que se filtran se filtran del lado de quien integra.
- Nunca en el repositorio. Ni en un archivo de configuración versionado, ni en un comentario, ni «temporalmente». El historial de git no olvida.
- Variables de entorno o un gestor de secretos. Y distintas por entorno: la clave de pruebas no debe poder tocar producción.
- Nunca en el navegador. Código que corre en el cliente no puede guardar un secreto. Si una pantalla tuya necesita estos datos, que los pida a tu servidor.
- Una clave por sistema. Reparte el límite de peticiones y permite revocar uno sin tumbar los demás.
- Con el permiso mínimo. Créala con un usuario que tenga solo lo que esa integración necesita: la clave hereda sus permisos.
- No la registres en tus logs. Es fácil que una cabecera acabe en un volcado de depuración y de ahí en un sistema de observabilidad de terceros.
bash
# Bien: fuera del código
export GRC_API_KEY="grc_..."
# Mal: en el repositorio
const API_KEY = "grc_Xf8kQ2mPz9vLnR4tYw7bHsJcA1dE6gUi";Si una clave se filtra
Revócala primero, investiga después
- Revócala en
Ajustes → Claves de API. Deja de funcionar de inmediato. - Crea una nueva y despliégala en el sistema afectado.
- Mira el registro de auditoría en el periodo en que estuvo expuesta, para saber qué se hizo con ella.
- Si se consultaron datos personales, evalúa si corresponde reportar el incidente ante la SIC: el plazo corre desde que lo detectas.
Responsable y encargado
Tu empresa es el responsable del tratamiento de los datos personales que consultes por esta API: decide qué datos se recogen y para qué. La plataforma es el encargado: los almacena y procesa por cuenta tuya.
Importa para saber a quién le reclama un titular. Un derecho ARCO —acceso, rectificación, cancelación, oposición— se ejerce ante tu empresa, y cuando esos datos ya están replicados en tus sistemas, atenderlo implica también a esos sistemas, no solo a la plataforma.
Cómo se aplica esto al aislamiento entre empresas está en Aislamiento por empresa.