Versioning, la primera l\u00ednea y en muchos casos la \u00fanica necesaria<\/h3>\n
Activar el versionado en los objetos almacenados en los buckets es, en muchos casos, la \u00fanica medida necesaria para proteger la informaci\u00f3n. Independientemente del ciclo de vida de los objetos almacenados, el versionado nos permite sobrevivir a p\u00e9rdidas o modificaciones equivocadas y accidentales de los datos. Por ejemplo, si nuestros objetos son modificados constantemente por alguna aplicaci\u00f3n, tiene sentido que se almacenen versiones de las mismas por si la aplicaci\u00f3n 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\u00edan ser modificados nunca, tiene sentido activar el versionado por si sucede alg\u00fan incidente que borre accidentalmente los datos.<\/p>\n
Cuando un objeto que se encuentra en un bucket versionado es eliminado, no se pierde la informaci\u00f3n instant\u00e1neamente, por el contrario, se a\u00f1ade un \u00abdelete marker\u00bb el cual funciona como un marcador de posici\u00f3n. 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\u00e1 a su lugar y puede ser usado sin ninguna limitaci\u00f3n.<\/p>\n
Por supuesto, si lo que se necesita es eliminar permanentemente los datos se pueden eliminar las versiones previas al \u00abdelete marker\u00bb.\u00a0 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\u00e1nica 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 \u00abdelete marker\u00bb podemos hacer uso del siguiente comando:<\/p>\n
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\u00f3n de los \u00abdelete markers\u00bb para recuperar la informaci\u00f3n versionada:<\/p>\n aws s3api delete-object –bucket DOC-EXAMPLE-BUCKET –key example.txt –version-id ‘example. <\/p>\n Hay escenarios donde la informaci\u00f3n es simplemente demasiado importante para estar almacenada en un solo lugar, \u00bfqu\u00e9 pasar\u00eda si las credenciales de la cuenta en la que est\u00e1n los buckets se filtran y un actor malicioso decide eliminar los buckets?<\/strong> \u00bfY si alguno de los arquitectos Cloud o miembro del equipo DevOps aplica por equivocaci\u00f3n una configuraci\u00f3n equivocada en el c\u00f3digo de IaC que elimina el bucket y por tanto toda informaci\u00f3n almacenada en \u00e9l?<\/strong>\u00a0Para estos casos simplemente no existe manera de recuperar los objetos perdidos.<\/p>\n Para evitar estos casos, la mejor opci\u00f3n es replicar los datos y almacenarlos en una cuenta alternativa,<\/strong> puede ser en la misma regi\u00f3n en la que originalmente estaban los datos o en otra, esto dependiendo de los requisitos de conformidad que debemos cumplir. Para la mayor\u00eda de veces, utilizar Same Region Replication (SRR) que no es otra cosa que replicar la informaci\u00f3n a otro bucket en la misma regi\u00f3n pero en una cuenta con accesos diferentes y quiz\u00e1 menos laxos, es suficiente para mantener los datos seguros. Esto gracias a que de por s\u00ed 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\u00f3n) y por lo tanto la informaci\u00f3n est\u00e1 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\u00f3n en el bucket a uno que se encuentre en una regi\u00f3n diferente.<\/p>\n Estas replicaciones generan una replicaci\u00f3n inmediata desde el momento en que se activa, es decir, cualquier nuevo objeto que se cree en el bucket original, ser\u00e1 instant\u00e1neamente replicado al nuevo bucket, tanto en SRR como en CRR. Sin embargo, esto no funciona a posteriori instant\u00e1neamente, puesto que los datos que ya existieran anteriormente en el bucket no van a ser instant\u00e1neamente replicados al nuevo bucket.\u00a0 Por suerte existe Batch replication, que nos permite hacer un volcado de la informaci\u00f3n desde un bucket a otro una vez activada la replicaci\u00f3n, para ello simplemente necesitamos un Role con accesos suficientes a los buckets y que pueda ser asumido por S3 para realizar la replicaci\u00f3n. La siguiente imagen explica desde una perspectiva de alto nivel como funciona este proceso:<\/p>\n <\/p>\n Una de las alternativas paralelas en la que quiz\u00e1 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\u00f1adido de seguridad para los inicios de sesi\u00f3n es tambi\u00e9n posible activarla para que no permita que se borre informaci\u00f3n del bucket o todo el bucket completo.<\/p>\n <\/p>\n Cabe resaltar que para S3 es transparente si la informaci\u00f3n est\u00e1 almacenada como versiones de objetos o como copias de seguridad en otro bucket, el precio por uso ser\u00e1 el mismo. Consecuentemente, si no se presta atenci\u00f3n 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\u00f3n.<\/p>\n En este blog no vamos a realizar un an\u00e1lisis a profundidad de las diferentes clases que existen, basta con ojear en la web de AWS (https:\/\/aws.amazon.com\/es\/s3\/ <\/p>\n AWS S3 nos ofrece una gama de servicios considerable en cuanto a proteger nuestra informaci\u00f3n se trata. Si bien no existe una gu\u00eda general que sirva a todos los casos, con las soluciones que hemos explorado aqu\u00ed 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.<\/p>\n \u00bfQuieres mejorar la seguridad de tu organizaci\u00f3n?\ud83d\udee1 Nuestros expertos pueden ayudarte con tu caso concreto. No dudes en escribirnos \ud83d\ude80<\/p>\n<\/blockquote>\nReplicaci\u00f3n objetos SRR, CRR y Batch Replication<\/h3>\n
![](\"https:\/\/lh6.googleusercontent.com\/b8HqwRxVewFtzvcCPFfAbnY7GxSzlVeoZAlVIN5fzBBxeiTP4ibaGVLPQ7g82uPaac8GQFLmsJHWj87Di8qXH2g8xt3OmMaYPl3kfSqQHyYpTFaZflNqr6T_WU_QbHnw2hmTDcyksj5Mo1c9Xq8\")
Multi-Factor Authentication<\/h3>\n
Reduciendo la factura de S3 por medio de las clases de almacenamiento<\/h3>\n
Conclusi\u00f3n<\/h3>\n
\n