Protección de datos en el diseño

La sección de protección de datos del pilar de seguridad de AWS se organiza en tres partes: clasificación de los datos, protección en reposo y protección en tránsito. Azure, en su pilar de seguridad, pide lo mismo con otras palabras: clasificar los datos según su tipo, sensibilidad y riesgo, y cifrarlos en reposo, en tránsito y durante el procesamiento según el nivel asignado.

El orden importa. Sin clasificación no se sabe qué almacén merece la clave propia, qué flujo exige canal cifrado ni qué dato puede quedar abierto. Un cifrado aplicado a todo por igual desperdicia esfuerzo en lo público y puede quedarse corto en lo confidencial.

Abre SELECT * FROM almacenes_datos. Cada fila trae la clasificación (publico, interno, confidencial o personal), si cifra en reposo y quién gestiona la clave. Filtra por los que no cifran: el resultado tendrá más de una fila, y no todas son un problema por igual.

El cifrado en tránsito protege lo que cruza entre componentes y hacia terceros. Un flujo en texto claro con datos personales puede leerse en cualquier punto del camino. Abre SELECT * FROM flujos_datos y filtra por canal = 'texto-claro'.

La retención también es protección: un dato que ya no se conserva no se puede filtrar. La política interna fija cuánto tiempo puede guardarse cada tipo de dato, y el diseño a veces lo ignora porque «por si acaso» es más cómodo que borrar.

Compara, para el almacén de pedidos, los días que conserva el diseño con los que manda la política.

El almacén del catálogo aparece sin cifrar en reposo y sin clave, y el flujo hacia él va en texto claro. Pero su clasificación es pública: son precios y fotos de productos que cualquiera ve en la web. Marcarlo como hallazgo de cifrado llenaría el informe de ruido y escondería lo importante. Lo que sí merece preguntarse en un dato público es quién puede modificarlo, porque ahí se protege la integridad, no la confidencialidad.