LecturaDe configurar a defender: dónde estamos
En los cursos de fundamentos e IAM aprendió a construir bien: dejar los buckets privados, recortar las políticas a mínimo privilegio, activar MFA en la cuenta raíz. Eso reduce la probabilidad de un incidente, pero no la lleva a cero. Este curso empieza donde termina aquel: asumiendo que, tarde o temprano, algo saldrá mal, y que su trabajo es darse cuenta y reaccionar.
Dónde estamos: de la prevención a la detección y respuesta
La seguridad defensiva se suele describir en funciones: identificar qué tiene, proteger lo importante, detectar lo que pasa, responder a lo que detecta y recuperar lo afectado. Es el esquema del marco de ciberseguridad del NIST. Los fundamentos cubrían identificar y proteger. Aquí vivimos en detectar y responder.
El cambio de mentalidad es grande. En prevención usted se pregunta "¿esto está bien configurado?". En detección y respuesta se pregunta "¿qué está pasando ahora mismo en la cuenta y quién lo hizo?". La materia prima para contestar no es la configuración, sino el registro de todo lo que ocurre: cada llamada a la API de la nube queda anotada en un log de auditoría, y ese log es su cámara de seguridad.
Breve historia y contexto
La idea de registrar las llamadas a la API llegó temprano a la nube pública. AWS lanzó CloudTrail en 2013, varios años después de EC2 y S3, cuando quedó claro que las cuentas crecían y nadie sabía quién había hecho qué. Azure consolidó su Activity Log y Google sus Cloud Audit Logs en los años siguientes. La detección automática vino después: GuardDuty apareció en 2017, y Azure Security Center (hoy Microsoft Defender for Cloud) y Security Command Center maduraron en paralelo.
El orden importa: primero la nube aprendió a registrar, y solo cuando hubo registros se pudo detectar sobre ellos. Por eso este curso también empieza por la visibilidad.
Por qué importa en el trabajo del defensor
Los incidentes en la nube rara vez son "alguien entró al servidor". Son credenciales filtradas que se usan desde otro país, una llave de acceso que apareció en un repositorio público, un rol con permisos de más que alguien asumió, un bucket que quedó abierto. Todo eso deja rastro en los registros, pero solo si usted sabe dónde mirar y qué patrón busca.
Roles que hacen este trabajo: analista de SOC con cuentas en la nube, ingeniero de detección, respondedor de incidentes, equipo de seguridad en la nube. Si no se domina, un compromiso puede pasar semanas sin verse, acumulando factura y robando datos; el informe anual de brechas de Verizon repite, año tras año, que las credenciales robadas son una de las vías de entrada más comunes.
Dónde se usa
| Lugar | Qué defiende |
|---|---|
| Equipo de seguridad en la nube | La postura y las alertas de una o varias cuentas |
| SOC con carga en la nube | Triaje de alertas de GuardDuty o Defender junto con las del resto de la empresa |
| Respuesta a incidentes | Contención y forense cuando ya hay un compromiso |
| Auditoría y cumplimiento | Que los registros existan, se conserven y nadie los apague |
Conceptos clave
| Concepto | Qué significa |
|---|---|
| Registro de auditoría | Bitácora de cada llamada a la API de la cuenta: quién, qué, cuándo y desde dónde |
| Evento de gestión | Acción sobre el plano de control (crear, borrar, cambiar permisos) |
| Evento de datos | Acceso al contenido (leer o escribir un objeto de un bucket) |
| Detección | Regla o servicio que convierte eventos en una alerta accionable |
| Falso positivo | Alerta que, tras revisarla, resulta ser actividad legítima |
| Contención | Acciones para cortar el acceso del atacante y limitar el daño |
| CSPM | Gestión de la postura: revisa la configuración contra buenas prácticas |
A lo largo del curso verá estos términos aplicados a los tres grandes proveedores. No memorice los nombres de cada servicio; entienda el papel que cumple y busque el equivalente cuando lo necesite.