AZ-900
Deep Dive
El principio más importante para entender la seguridad en cloud. Define exactamente quién es responsable de qué en cada capa del stack tecnológico — y cambia según el modelo de servicio.
Contenido
En cloud, la seguridad y gestión no son responsabilidad exclusiva de nadie. Microsoft y tú comparten responsabilidades — la distribución depende del modelo de servicio que uses.
Este modelo existe porque en un datacenter físico, tú controlas absolutamente todo. Al mover cargas a cloud, cedes cierto control al proveedor a cambio de que él gestione esas capas. El modelo define exactamente el límite.
Por qué este concepto existe (y por qué importa)
En 2021, el 48% de las brechas de seguridad en cloud fueron causadas por configuración incorrecta del cliente — no por vulnerabilidades de Microsoft. En todos esos casos, el cliente asumió incorrectamente que "Microsoft lo maneja todo".
Entender este modelo es la diferencia entre una arquitectura segura y un data breach de $4M promedio.
Cada fila del stack tecnológico, quién es responsable según el modelo de servicio.
| Capa del stack | On-Premises | IaaS | PaaS | SaaS |
|---|---|---|---|---|
| Instalaciones físicas | Cliente | Microsoft | Microsoft | Microsoft |
| Hardware (servidores, storage, switches) | Cliente | Microsoft | Microsoft | Microsoft |
| Red física | Cliente | Microsoft | Microsoft | Microsoft |
| Hypervisor / Virtualización | Cliente | Microsoft | Microsoft | Microsoft |
| Sistema Operativo | Cliente | Cliente | Microsoft | Microsoft |
| Middleware / Runtime | Cliente | Cliente | Microsoft | Microsoft |
| Aplicación | Cliente | Cliente | Cliente | Microsoft |
| Datos de la aplicación | Cliente | Cliente | Cliente | Compartida |
| Endpoints (dispositivos de usuario) | Cliente | Cliente | Cliente | Cliente |
| Identidad y acceso (IAM) | Cliente | Cliente | Compartida | Compartida |
| Red y firewall (config) | Cliente | Compartida | Compartida | Microsoft |
Sin importar el modelo de servicio (IaaS, PaaS o SaaS), estas responsabilidades no cambian.
Microsoft SIEMPRE es responsable de:
Tú SIEMPRE eres responsable de:
En IaaS (Azure Virtual Machines), tú tienes el control del SO hacia arriba. Esto significa más poder y más responsabilidad.
Ejemplo: Azure Virtual Machine con Windows Server 2022
Microsoft gestiona:
Tú gestionas:
Escenario real de brecha en IaaS
Empresa X tiene 200 VMs en Azure IaaS. El sysadmin no aplica el parche de Windows de abril (CVE crítico). Un atacante explota la vulnerabilidad, obtiene acceso a 50 VMs, exfiltra datos de clientes.
¿Quién es responsable? El cliente. Microsoft entregó un SO funcional. El cliente fue responsable de parcharlo y no lo hizo. Microsoft NO tiene acceso a la VM para parcharlo sin tu consentimiento.
En PaaS (Azure App Service, Azure SQL Database), Microsoft gestiona el SO y el runtime. Tú solo te preocupas por tu código y datos.
Ejemplo: Azure App Service (Web App)
Microsoft gestiona:
Tú gestionas:
Responsabilidad "compartida" en PaaS: IAM y Red
Red y firewall
Microsoft maneja la red física. Tú configuras las reglas: qué IPs pueden acceder (restrictions), VNet integration, Private Endpoints. Si dejas acceso público abierto por error, es tu responsabilidad.
Identidad y acceso
Microsoft provee Entra ID. Tú decides quién tiene qué roles en tu App Service. Un developer con Owner role que no debería tenerlo = tu error, no de Microsoft.
En SaaS (Microsoft 365, Teams, SharePoint Online), Microsoft gestiona casi todo. Pero tus responsabilidades siguen siendo críticas.
Ejemplo: Microsoft 365 (Exchange Online + SharePoint)
Microsoft gestiona:
Tú sigues siendo responsable de:
Error crítico común en SaaS
Empresa cree que "Microsoft hace backups de Teams/SharePoint" y no implementa Veeam o similar. Empleado borra accidentalmente 3 años de documentos de SharePoint. Microsoft solo garantiza restauración de hasta 93 días en SharePoint (y en Teams el chat deletedo puede ser irrecuperable).
Lección: En SaaS, aún eres responsable de la continuidad de negocio de TUS datos. Microsoft protege su plataforma, no tus datos específicos.
Los errores más comunes — y costosos — ocurren cuando los clientes asumen que Microsoft cubre algo que en realidad es responsabilidad del cliente.
Storage account con acceso público habilitado
Azure Storage permite habilitar "Allow public access" a nivel cuenta. Si activas esto + no tienes logging, expones datos públicamente. Microsoft no lo impide — es una opción legítima. Tú eres responsable de la configuración.
Capital One (2019): $80M multa + 140M cuentas filtradas por misconfiguración de S3.
Contraseñas de admin sin MFA
Entra ID de Microsoft puede requerir MFA — si lo configuras. Si creas cuentas de admin sin MFA y una contraseña débil, Entra ID autentica correctamente al atacante. Microsoft autenticó correctamente; tú no activaste MFA.
99.9% de los ataques de cuenta comprometida son prevenidos por MFA (Microsoft Security Report 2023).
VM con RDP expuesto a internet (puerto 3389)
NSGs permiten todo por defecto si no los configuras. Una VM con RDP/SSH abierto al mundo es un objetivo directo de brute force. Microsoft entregó la VM. Tú configuraste (o no configuraste) el NSG.
Microsoft bloquea 300M+ intentos de autenticación fraudulenta diariamente — muchos contra VMs con puertos abiertos.
Exceso de permisos (violación de least privilege)
Un developer con rol "Contributor" puede borrar accidentalmente todo un grupo de recursos en producción. Azure RBAC permite Contributor. Tú decides quién tiene qué rol. Microsoft no sabe si ese developer debería tener ese permiso o no.
Error humano es la #1 causa de incidents en cloud (Gartner 2024).
Cuando usas Azure, puedes heredar las certificaciones de Microsoft — pero solo para las capas que Microsoft gestiona. Tu capa sigue necesitando cumplimiento.
Certificaciones de Azure (que puedes heredar)
Lo que tú aún debes hacer para compliance
Azure te da las herramientas; tú debes usarlas correctamente.
¿Entendiste este tema?
Pon a prueba lo que acabas de aprender
En el modelo IaaS, ¿de qué es responsable el cliente y no el proveedor de nube?