🕊 En memoria con amor, de quien en vida fue y seguirá siendo mi abuelita nena 🕊
Hola 👋
Te presento mi nueva serie "AWS Security Series v2 - Mapeo de Seguridad en Cloud" la cual contiene una serie de blogs introductorios que te ayudaran a entender en como AWS adopta Seguridad como proveedor de Cloud Computing y además descubrirás como AWS ayuda a sus clientes (aquí entramos tu y yo 😉) en como adoptar una postura de seguridad deseada para nuestro negocio.
Modelo de Seguridad compartida en AWS
El modelo de seguridad que AWS nos ofrece como proveedor Cloud es el siguiente:
Aquí se detalla las responsabilidades que tendrás tu como cliente, y las responsabilidades que tendrá AWS como proveedor.
Entonces, ¿Cómo saber de qué eres responsable como cliente?
Muy fácil, este Modelo de Responsabilidad, se divide en 2 partes.
Seguridad EN la Nube: El cliente es responsable de los servicios que elija para su carga de trabajo y de como use estos servicios.
Por ejemplo: Supongamos que necesitemos almacenar data altamente crítica y la almacenamos en un bucket público, entonces sucede lo obvio, y sufrimos un ataque de Exfiltración de Datos. ¿Quién es el responsable, AWS o Tú?Seguridad DE la Nube: AWs se responsabiliza por proteger la infraestructura que se usa para soportar los servicios que ofrece.
Por ejemplo: Tenemos la necesidad de montar un sitio web en una instancia EC2, y el servidor físico que aloja tu máquina virtual, se recalienta y se apaga por varios minutos. Esto hace que tu sitio web se indisponibilice y pierdas ventas... ¿Quién es el responsable aquí?
Tipos de servicios
Ahora, es necesario conocer los tipos de servicios AWS que podemos usar para nuestras diferentes necesidades:
Infraestructura | Encapsulados | Abstractos |
---|---|---|
¿Pero que significan?
Muy sencillo:
- Servicios de infraestructura: hace referencia a servicios como EC2 por ejemplo.
- Servicios encapsulados: Se dice encapsulados o administrados por AWS como una RDS.
- Servicios abstractos: Se refiere a servicios Severless como una función lambda o un API Gateway.
¿Cómo impacta el modelo de responsabilidad compartida a los tipos de servicios AWS?
Vamos a suponer que para nuestra aplicación, necesitamos una Base de datos. Entonces podríamos decir lo siguiente:
- Servicio de infraestructura: Colocaríamos nuestra Base de datos en una instancia EC2, entonces veamos las responsabilidades que tendría AWS y nosotros como cliente:
AWS | Cliente |
---|---|
Instalación del SO | Control de acceso |
Mantenimiento del servidor físico | Elasticidad/Escalabilidad |
Sistema eléctrico, refrigeración | Alta disponibilidad |
Seguridad física o perimetral | Gestionar la BD |
- Servicio encapsulado: Ahora llevemos nuestra base de datos a una instancia RDS
AWS | Cliente |
---|---|
Escalabilidad | Control de acceso |
Alta disponibilidad | Elasticidad |
Gestión de la BD | --- |
Gestión del SO | --- |
Instalación del SO | --- |
Mantenimiento del servidor físico | --- |
Sistema eléctrico, refrigeración | --- |
Seguridad física o perimetral | --- |
- Servicio abstracto: Finalmente decidimos cambiar a una base de datos serverless como DynamoDB
AWS | Cliente |
---|---|
Escalabilidad | Control de acceso |
Alta disponibilidad | --- |
Gestión de la BD | --- |
Gestión del SO | --- |
Instalación del SO | --- |
Mantenimiento del servidor físico | --- |
Sistema eléctrico, refrigeración | --- |
Seguridad física o perimetral | --- |
Como pudieron ver, las responsabilidades entre el cliente y AWS varia de acuerdo al tipo de servicio AWS que estemos usando.
Continúa aprendiendo en los siguientes blogs de esta serie 🔥
Aquí paramos la tecla ✍
🚀 Te invito a seguirme en mis redes sociales 🚀
🌐 https://bit.ly/gerardokaztro
📺 https://bit.ly/AWSSecurityLATAM
✍ https://bit.ly/DevtoGerardokaztro
🌟 https://linkedin.com/in/gerardokaztro
✍ https://bit.ly/MediumGerardokaztro
🐦 https://twitter.com/gerardokaztro
🤳 https://instagram.com/awssecuritylatam
Top comments (0)