Seguridad del almacenamiento cloud y riesgos de exposición de datos

El almacenamiento de objetos en la nube —AWS S3, Azure Blob Storage y Google Cloud Storage (GCS)— almacena archivos como objetos en espacios de nombres planos llamados buckets o contenedores. A diferencia de los sistemas de archivos tradicionales, los permisos se controlan mediante políticas asociadas a buckets y objetos, en lugar de ACL del sistema de archivos. El almacenamiento de objetos es ideal para grandes volúmenes de datos, pero requiere configurar cuidadosamente los permisos, ya que un solo bucket mal configurado puede exponer terabytes de datos confidenciales a Internet.

La vulnerabilidad más común del almacenamiento en la nube es un bucket accesible públicamente: un bucket de almacenamiento cuya política de acceso permite el acceso de lectura anónimo (o el acceso de escritura). Este error de configuración ha provocado decenas de brechas importantes: Verizon (14 millones de registros de clientes), FedEx (119.000 pasaportes) y Capital One (100 millones de solicitudes de tarjetas de crédito). Los atacantes utilizan analizadores automatizados para descubrir buckets públicos en todos los patrones de nombres de cuentas de AWS conocidos, por lo que su detección resulta trivial una vez que existe el error de configuración.

El almacenamiento en la nube utiliza dos tipos de controles de acceso que pueden entrar en conflicto. Las políticas de bucket son documentos JSON asociados al bucket que definen qué entidades pueden realizar determinadas acciones. Las Access Control Lists (ACL) son concesiones de permisos por objeto heredadas. AWS recomienda deshabilitar las ACL en favor de las políticas de bucket para mantener la coherencia. Cuando existen ambas, prevalece la política más permisiva, lo que significa que una ACL demasiado permisiva puede conceder acceso público aunque la política del bucket lo restrinja.

Los proveedores de almacenamiento en la nube ofrecen cifrado del lado del servidor para los objetos en reposo. SSE-S3 (AWS) utiliza automáticamente claves gestionadas por AWS. SSE-KMS utiliza claves gestionadas por el cliente en AWS Key Management Service, lo que proporciona mejores registros de auditoría (cada descifrado se registra en CloudTrail) y control sobre la rotación de claves. SSE-C utiliza claves proporcionadas por el cliente, que este gestiona completamente fuera de AWS. Para datos confidenciales, SSE-KMS con claves gestionadas por el cliente proporciona el mayor control y las mejores evidencias de cumplimiento.

Incluso los datos correctamente cifrados en reposo pueden quedar expuestos si se transmiten por canales sin cifrar. Se debe acceder exclusivamente a todas las API de almacenamiento en la nube mediante HTTPS/TLS. En S3, las políticas de bucket pueden exigir HTTPS denegando las solicitudes con aws:SecureTransport: false. Las URL prefirmadas —URL autenticadas temporales que conceden acceso a objetos durante un tiempo limitado— siempre deben utilizar HTTPS y configurarse con tiempos de expiración breves para reducir al mínimo la ventana de exposición en caso de interceptación.

No todos los datos requieren el mismo nivel de protección. Los datos confidenciales (PII, PHI y registros financieros) deben almacenarse en buckets cifrados y con acceso restringido, con el registro de auditoría habilitado. Los datos menos confidenciales pueden tener un acceso más amplio. Las etiquetas de clasificación de datos deben aplicarse al crear el objeto y utilizarse para dirigir automáticamente los datos al almacenamiento configurado adecuadamente. Las políticas que trasladan automáticamente los datos a un almacenamiento más seguro según las etiquetas de clasificación reducen la probabilidad de que los datos confidenciales terminen en buckets con baja seguridad.

El registro de accesos es fundamental para detectar accesos no autorizados a posteriori y realizar auditorías de cumplimiento. Los registros de acceso de AWS S3 y el registro de eventos de datos de CloudTrail registran cada llamada a la API a nivel de objeto: quién solicitó un objeto, desde qué IP y a qué hora. El registro de diagnóstico de Azure Blob y los registros de auditoría de GCS ofrecen una capacidad similar. Sin estos registros, no hay pruebas forenses cuando se descubre una brecha de datos, lo que hace imposible determinar el alcance de la exposición.

El almacenamiento en la nube suele compartirse entre cuentas (desarrollo, pruebas, producción y socios externos). El acceso entre cuentas configurado sin cuidado puede conceder permisos excesivos. Entre las prácticas recomendadas se incluyen: utilizar identificadores de cuenta explícitos en las políticas de bucket en lugar de entidades principales comodín, utilizar AWS Organizations SCPs para restringir qué cuentas externas pueden recibir acceso, auditar periódicamente las concesiones entre cuentas y preferir AWS PrivateLink al acceso mediante Internet pública para las transferencias de datos entre cuentas.

El control de versiones de objetos conserva todas las versiones de un objeto, incluidas las versiones eliminadas. Esto protege frente a eliminaciones accidentales, el cifrado de objetos por ransomware y las amenazas internas. Para datos críticos, combine el control de versiones con Object Lock (equivalente a S3 Glacier Vault Lock): una política WORM (Write Once, Read Many) que impide cualquier eliminación o modificación durante un periodo de retención definido. Object Lock puede cumplir los requisitos normativos de registros inmutables en los sectores financiero y sanitario.

Las herramientas de Cloud Security Posture Management (CSPM) analizan automáticamente las configuraciones del almacenamiento en la nube comparándolas con referencias de seguridad. Las comprobaciones de CSPM incluyen: ¿hay buckets accesibles públicamente? ¿Está habilitado el cifrado en reposo? ¿Está habilitado el registro? ¿Está habilitado el control de versiones en los buckets críticos? ¿Son demasiado permisivas las políticas de bucket? Las herramientas de CSPM, como Prisma Cloud, Wiz y AWS Security Hub, proporcionan supervisión continua del cumplimiento y alertan sobre desviaciones de configuración antes de que los atacantes las detecten.

Las URL prefirmadas conceden acceso durante un tiempo limitado a objetos específicos sin exigir al destinatario credenciales de AWS. Son útiles para compartir archivos con terceros. Entre los riesgos de seguridad se incluyen: URL con tiempos de expiración excesivamente largos que siguen activas más allá del periodo previsto para compartirlas, URL que los destinatarios reenvían fuera de la audiencia prevista y tokens incluidos en URL que aparecen en los registros del servidor. Establezca siempre el tiempo de expiración más corto viable y evite registrar las URL prefirmadas.

Compruebe su comprensión de los conceptos de CompTIA Security+ (SY0-701) tratados en esta lección.

En esta lección ha aprendido que los errores de configuración de buckets públicos son la causa más común de las brechas de datos en el almacenamiento en la nube, que SSE-KMS proporciona el mayor control de cifrado, con registro de auditoría mediante CloudTrail, y que el control de versiones de objetos combinado con Object Lock protege frente al ransomware y la eliminación interna de datos críticos. A continuación, exploraremos la identidad en la nube mediante roles de IAM y cuentas de servicio.