Proteger los datos no termina cuando viajan por la red. También necesitas blindarlos cuando están guardados en un servidor, y ahí es donde entra data at rest y el servicio Key Management Service de AWS. Si trabajas con bases de datos en la nube, entender cómo funciona el cifrado en reposo te permite cerrar una de las puertas más sensibles de tu infraestructura.

¿Qué diferencia hay entre data at rest y data in transit?

Los datos viven en dos estados y cada uno necesita una protección distinta.

Data in transit es la información que se mueve por la web. La proteges con certificados SSL, que cifran los datos mientras viajan entre el cliente y el servidor.

Data at rest es la información que está quieta, guardada dentro de una base de datos o un servidor. Aunque hablemos de "la nube", esos datos no flotan en el aire: viven en el computador de alguien más, en un dispositivo físico real. Si alguien obtiene acceso a ese dispositivo, podría leer la información. Por eso la data at rest debe estar cifrada con una clave de seguridad.

¿Qué es data at rest? Es la información almacenada en un servidor o base de datos que no se está moviendo por la red. Necesita cifrado para que, si alguien accede al dispositivo físico, no pueda leerla.

¿Qué es AWS KMS y para qué sirve?

El servicio que te da claves de cifrado para proteger tus datos en reposo se llama Key Management Service, o KMS. Su función es generar, almacenar y administrar las llaves criptográficas que cifran la información dentro de servicios como RDS, Lambda o Secrets Manager.

Aquí aparece una confusión común: KMS no es lo mismo que Secrets Manager. Secrets Manager es donde guardas API keys y credenciales, y esas credenciales a su vez se cifran usando una clave de KMS. Uno almacena secretos, el otro provee las llaves para cifrarlos.

¿KMS y Secrets Manager son lo mismo? No. Secrets Manager guarda credenciales y API keys; KMS provee las claves de cifrado que protegen esos secretos y otros datos.

¿Cómo verifico que mi base de datos RDS está cifrada?

Desde la consola de AWS puedes confirmarlo en pocos pasos [1:05].

• Entra a RDS y selecciona tu base de datos.
• Abre el menú de configuración en la parte inferior.
• Revisa la sección de storage: ahí verás que la encripción está habilitada por defecto.
• Identifica la KMS key asociada, que en este caso se llama AWS RDS.

Al hacer clic sobre la clave, accedes a su configuración: la policy de uso, el tipo de llave (simétrica) y la información criptográfica completa. Esta clave pertenece al grupo de AWS Managed Keys, llaves administradas directamente por AWS.

¿Puedo usar mis propias claves de cifrado en AWS?

Sí. AWS ofrece llaves por defecto que ya son seguras, pero también puedes importar las tuyas si tu organización lo requiere. Dentro del menú de KMS encuentras las AWS Managed Keys, donde aparecen las claves que se han creado automáticamente para los servicios del proyecto [1:48].

En un proyecto típico vas a ver llaves para:

• Lambda, que cifra el código y las variables de entorno.
• Secrets Manager, que cifra las credenciales almacenadas.
• RDS, que cifra la base de datos en reposo.

Todos estos servicios viven en servidores físicos de AWS, y al estar cifrados, nadie puede leer su contenido sin la llave correspondiente. Ese es el punto clave del cifrado en reposo: aunque alguien acceda al hardware, los datos siguen siendo ilegibles.

¿Este conocimiento sirve solo para AWS?

No. El concepto de data at rest, el uso de claves simétricas y la separación entre gestión de secretos y gestión de llaves son estándares en la industria. Puedes aplicar la misma lógica en Google Cloud, Azure o incluso en infraestructura on premise. Cambia el nombre del servicio, pero la idea de cifrar lo que está guardado y proteger las llaves que lo descifran se mantiene igual.

Con esto ya tienes una visión clara de cómo proteger tus datos en sus dos estados. ¿Has revisado si las bases de datos de tus proyectos tienen la encripción habilitada? Cuéntame en los comentarios qué servicios usas para gestionar tus claves.