Los requerimientos de seguridad de nuestros buckets dependen considerablemente del tipo de información que almacenamos en ellos. En muchos casos esta información es crucial en el modelo de negocio y su pérdida implicaría graves consecuencias.
En este blog indagaremos en las distintas capas de defensa que tenemos a nuestra disposición para proteger nuestra información de posibles pérdidas.
Versioning, la primera línea y en muchos casos la única necesaria
Activar el versionado en los objetos almacenados en los buckets es, en muchos casos, la única medida necesaria para proteger la información. Independientemente del ciclo de vida de los objetos almacenados, el versionado nos permite sobrevivir a pérdidas o modificaciones equivocadas y accidentales de los datos. Por ejemplo, si nuestros objetos son modificados constantemente por alguna aplicación, tiene sentido que se almacenen versiones de las mismas por si la aplicación se corrompe y es necesario recuperar las versiones anteriores. Por otro lado, si nuestros datos siguen un modelo WORM (Write Once Read Many) y por tanto, no modificados deberían ser modificados nunca, tiene sentido activar el versionado por si sucede algún incidente que borre accidentalmente los datos.
Cuando un objeto que se encuentra en un bucket versionado es eliminado, no se pierde la información instantáneamente, por el contrario, se añade un «delete marker» el cual funciona como un marcador de posición. Cuando una consulta GET por el objeto llega, simplemente no se retorna nada, como si el objeto no existiera. Sin embargo, si se necesita recuperarlo, basta con eliminar el deletion marker y el objeto regresará a su lugar y puede ser usado sin ninguna limitación.
Por supuesto, si lo que se necesita es eliminar permanentemente los datos se pueden eliminar las versiones previas al «delete marker». Si bien, cuando se habla de grandes cantidades de datos, tanto recuperar como eliminar esto a mano desde la consola de AWS suena como una tarea titánica e imposible, siempre se puede hacer uso de la CLI de amazon y utilizar algunos de sus comandos incluidos. Por ejemplo, si queremos encontrar todos los objetos que cuenten con un «delete marker» podemos hacer uso del siguiente comando:
aws s3api list-object-versions –bucket DOC-EXAMPLE-BUCKET –prefix example.txt –query ‘DeleteMarkers[?IsLatest==`
Con las llaves que retorne la consulta, podemos utilizar otro de los comandos del s3api para realizar la eliminación de los «delete markers» para recuperar la información versionada:
aws s3api delete-object –bucket DOC-EXAMPLE-BUCKET –key example.txt –version-id ‘example.
Replicación objetos SRR, CRR y Batch Replication
Hay escenarios donde la información es simplemente demasiado importante para estar almacenada en un solo lugar, ¿qué pasaría si las credenciales de la cuenta en la que están los buckets se filtran y un actor malicioso decide eliminar los buckets? ¿Y si alguno de los arquitectos Cloud o miembro del equipo DevOps aplica por equivocación una configuración equivocada en el código de IaC que elimina el bucket y por tanto toda información almacenada en él? Para estos casos simplemente no existe manera de recuperar los objetos perdidos.
Para evitar estos casos, la mejor opción es replicar los datos y almacenarlos en una cuenta alternativa, puede ser en la misma región en la que originalmente estaban los datos o en otra, esto dependiendo de los requisitos de conformidad que debemos cumplir. Para la mayoría de veces, utilizar Same Region Replication (SRR) que no es otra cosa que replicar la información a otro bucket en la misma región pero en una cuenta con accesos diferentes y quizá menos laxos, es suficiente para mantener los datos seguros. Esto gracias a que de por sí AWS ya almacena los datos en diferentes zonas de disponibilidad (ubicaciones diferentes aisladas las unas de las otras que se encuentran en una misma región) y por lo tanto la información está protegida en caso de que se elimine en alguna de las zonas de disponibilidad. Pero, en escenarios en los que esto no es suficiente siempre se puede hacer uso de Cross Region Replication (CRR) que es replicar la información en el bucket a uno que se encuentre en una región diferente.
Estas replicaciones generan una replicación inmediata desde el momento en que se activa, es decir, cualquier nuevo objeto que se cree en el bucket original, será instantáneamente replicado al nuevo bucket, tanto en SRR como en CRR. Sin embargo, esto no funciona a posteriori instantáneamente, puesto que los datos que ya existieran anteriormente en el bucket no van a ser instantáneamente replicados al nuevo bucket. Por suerte existe Batch replication, que nos permite hacer un volcado de la información desde un bucket a otro una vez activada la replicación, para ello simplemente necesitamos un Role con accesos suficientes a los buckets y que pueda ser asumido por S3 para realizar la replicación. La siguiente imagen explica desde una perspectiva de alto nivel como funciona este proceso:
Multi-Factor Authentication
Una de las alternativas paralelas en la que quizá a muchos usuarios les conviene indagar es activar la Multifactor Authentication (MFA) para protegerse contra posibles perdidas de los datos por error humano. Al igual que puede usarse la MFA como un añadido de seguridad para los inicios de sesión es también posible activarla para que no permita que se borre información del bucket o todo el bucket completo.
Reduciendo la factura de S3 por medio de las clases de almacenamiento
Cabe resaltar que para S3 es transparente si la información está almacenada como versiones de objetos o como copias de seguridad en otro bucket, el precio por uso será el mismo. Consecuentemente, si no se presta atención a los costos de las versiones o de los backups se puede llegar a incurrir en sobrecostos innecesarios. Por suerte existen distintos tipos de almacenamiento S3 que nos permiten ahorrar costos. AWS presenta 7 clases de almacenamiento, cada una con diferentes objetivos y que permiten hacer un ahorro diferente dependiendo de las necesidades que tengamos con la información.
En este blog no vamos a realizar un análisis a profundidad de las diferentes clases que existen, basta con ojear en la web de AWS (https://aws.amazon.com/es/s3/
Conclusión
AWS S3 nos ofrece una gama de servicios considerable en cuanto a proteger nuestra información se trata. Si bien no existe una guía general que sirva a todos los casos, con las soluciones que hemos explorado aquí basta para darse una idea de que se puede hacer. En muchos casos activar estas configuraciones es sencillo y barato y puede ahorrarnos dolores de cabeza cuando nos encontramos ante un incidente.
¿Quieres mejorar la seguridad de tu organización?🛡 Nuestros expertos pueden ayudarte con tu caso concreto. No dudes en escribirnos 🚀
Configuración de cookies