De SysAdmin a Cloud Security Engineer: una ruta desde la infraestructura

Por qué los sysadmins son fuertes cloud security engineers

Los administradores de sistemas han pasado años construyendo el modelo mental exacto que el trabajo de cloud security exige: cómo los sistemas se interconectan, cómo se concede y revoca el acceso, dónde viven los modos de fallo y cómo operar bajo cambio. La transición no es reconstruir esa intuición. Es reorientarla de racks y forests de Active Directory a cuentas AWS y roles IAM.

El cambio es real pero acotado. La cloud cambia las herramientas, la velocidad y las superficies de fallo. No cambia cómo se ve la buena seguridad de infraestructura. Los hiring managers lo saben, y por eso los sysadmins compiten con fuerza por los roles descritos en la página de carrera de cloud security engineer y la página de carrera de security engineer.

Por qué la disciplina sysadmin se traslada directamente a cloud security

Cloud security no es una disciplina fundamentalmente nueva. Es seguridad de infraestructura con un modelo operativo distinto. Las disciplinas que ya practicas como sysadmin se proyectan de forma cercana a cómo los equipos de cloud security pasan realmente sus días.

La cadencia de parches se convierte en gestión de vulnerabilidades para AMIs, imágenes base de contenedor y versiones de servicios gestionados. El backup y la recuperación se vuelven ingeniería de resiliencia y restauración validada frente a escenarios de ransomware. La higiene de cuentas de usuario se vuelve ciclo de vida IAM y gobernanza de cuentas break-glass. La segmentación de red entre VLANs on-premises se vuelve diseño de VPC con subredes privadas, security groups y enrutado por Transit Gateway.

El trabajo del día a día en el que los sysadmins son buenos, vigilar logs, validar cambios, sostener la línea del menor privilegio, es exactamente el trabajo que distingue a un cloud security engineer útil de alguien que solo aprueba un examen. Las plataformas cloud hacen que la automatización sea más fácil y rápida, pero la disciplina de fondo es la misma que ha mantenido estables los entornos on-premises la última década.

Por eso los hiring managers valoran a los sysadmins para roles cloud security. Los reconvertidos desde puro desarrollo a menudo carecen de instinto operativo, y los analistas de seguridad puros suelen carecer de experiencia de infraestructura. Los sysadmins llegan con ambas.

El modelo mental cloud que necesitas (responsabilidad compartida, identity-first, todo como código)

Tres cambios mentales separan a los sysadmins que aterrizan en roles cloud security de los que se atascan.

El primero es la responsabilidad compartida. El proveedor cloud es responsable de la seguridad de la plataforma. Tú eres responsable de la seguridad en la plataforma. Suena obvio, pero la mayoría de los incidentes cloud rastrean a clientes que mal configuran algo que el proveedor ya aseguraba por defecto. Tu trabajo es el lado del cliente del límite.

El segundo es el pensamiento identity-first. Las redes on-premises trataban el perímetro como control primario. La cloud trata la identidad como control primario. Cada llamada API, cada workload, cada interacción cross-account está mediada por IAM. AWS IAM, Azure RBAC y Microsoft Entra ID, Google Cloud IAM y Workload Identity Federation son el nuevo perímetro. Si no entiendes role chaining, condition keys, control de acceso basado en atributos y flujos assume-role, no puedes hacer cloud security en profundidad.

El tercero es todo como código. La cloud security en click-ops se estanca rápido. Los equipos modernos describen redes, identidad, reglas de detección y baselines de cumplimiento en Terraform, OpenTofu, Pulumi o Bicep. Los pull requests son cómo ocurre el cambio. La revisión de código es cómo se filtra el riesgo. Si nunca has gestionado infraestructura mediante control de versiones, esa brecha es lo más grande a cerrar.

El stack de skill IaC security (Terraform + Checkov + Pulumi + Open Policy Agent)

La infrastructure as code es el punto de entrada para shift-left security en plataformas cloud. El stack mínimo viable:

Terraform u OpenTofu para infraestructura declarativa. Pulumi si tu equipo prefiere lenguajes de propósito general como TypeScript o Python. CloudFormation y Bicep siguen siendo válidos en tiendas AWS y Azure respectivamente.

Análisis estático con Checkov, tfsec, KICS o Trivy. Estos escáneres detectan buckets S3 públicos, flags de cifrado faltantes, security groups demasiado permisivos y políticas IAM con acciones wildcard antes de que lleguen a producción. La mayoría de equipos cloud security gatean los pull requests con al menos una de estas herramientas.

Policy as code con Open Policy Agent y Conftest, o Sentinel si operas Terraform Cloud. Esto te permite codificar reglas específicas de la organización, por ejemplo prohibir balanceadores públicos en cuentas de producción o exigir tags para atribución de coste y respuesta a incidentes.

Detección de drift con AWS Config, Azure Policy o módulos personalizados de GCP Security Command Center. El punto no es solo encontrar drift, sino retroalimentarlo al repositorio IaC como fuente de verdad.

Si puedes construir un pequeño repositorio de referencia que provisione una landing zone hardened, escanee cada cambio con Checkov y bloquee merges en violaciones de policy, tienes un artefacto de portfolio que mapea directamente sobre una descripción de puesto cloud security engineer.

Kubernetes Security es el cliff de skill más duro (y donde la demanda es mayor)

Kubernetes es donde la cloud security separa a los candidatos fuertes del resto. La plataforma expone más superficie de configuración que cualquier cuenta cloud, y la mayoría de los clústeres en producción están mal configurados de alguna forma material.

Los skills que importan:

Role-Based Access Control más allá de cluster-admin. Los workloads reales necesitan roles namespaced, service accounts con scope y higiene de bindings. La service account por defecto en cada namespace es la ruta de escalada de privilegios más común.

NetworkPolicy como primera capa de segmentación, seguida de policies de service mesh en Istio, Linkerd o Cilium para entornos que las necesiten. Sin NetworkPolicy, cualquier pod puede hablar con cualquier otro pod, el equivalente cloud de una VLAN plana.

Pod Security Admission, el reemplazo de PodSecurityPolicy obsoleto. La mayoría de equipos pares PSA con OPA Gatekeeper o Kyverno para control de admisión más rico: bloquear contenedores privilegiados, exigir usuarios no-root, imponer allow-lists de registry y exigir imágenes firmadas.

Workload identity. Los pods deben autenticarse a las APIs cloud mediante IRSA en AWS, Workload Identity en GCP o Azure AD Workload Identity. Las credenciales estáticas de larga vida en variables de entorno de contenedor son el patrón de brecha cloud-native más grande.

Controles de cadena de suministro incluidos generación de SBOM con Syft, escaneo de vulnerabilidades con Trivy o Grype, y verificación de firmas con Cosign y Sigstore. SLSA y in-toto proveen el vocabulario de framework, y cualquier equipo que se tome la cadena de suministro en serio esperará que los conozcas.

Si construyes profundidad genuina en Kubernetes Security, te vuelves difícil de reemplazar. La página de carrera de security engineer marca Kubernetes como un requisito senior recurrente.

CSPM, CWPP, CNAPP: qué significan estos acrónimos en realidad

El mercado de tooling cloud security está denso de acrónimos. Tres importan para cualquier sysadmin que entre.

Cloud Security Posture Management, o CSPM, evalúa continuamente la configuración cloud contra benchmarks como CIS, PCI DSS o baselines internas. AWS Security Hub, Azure Defender for Cloud, GCP Security Command Center y herramientas de terceros como Wiz, Prisma Cloud y Orca son los ejemplos principales. CSPM responde a la pregunta, ¿está esta cuenta configurada como dijimos que debería estar?

Cloud Workload Protection Platforms, o CWPP, monitorizan workloads en ejecución por amenazas: máquinas virtuales, contenedores y serverless. AWS GuardDuty para detección de amenazas en runtime, Microsoft Defender for Servers, Microsoft Sentinel para correlación SIEM y herramientas runtime como Falco son CWPP. CWPP responde, ¿está pasando algo malo ahora mismo?

Cloud-Native Application Protection Platforms, o CNAPP, agrupan CSPM, CWPP, escaneo IaC, analítica de identidad y a veces seguridad de datos en un solo producto. CNAPP es la dirección del mercado y el paraguas bajo el que se sitúan la mayoría de RFPs de proveedores.

No necesitas dominar cada producto. Sí necesitas poder razonar sobre qué control pertenece a qué capa, y articular por qué un hallazgo CSPM que dice bucket S3 público es distinto de un hallazgo CWPP que dice instancia EC2 contactando con C2 conocido.

La decisión de cert de tres clouds: AWS Security Specialty, Azure SC-100, GCP PCSE

Elige una plataforma primero. La familiaridad superficial sobre tres es consistentemente menos contratable que la profundidad real en una.

Ruta AWS: Solutions Architect Associate como prerequisito para vocabulario, luego AWS Certified Security Specialty (SCS-C02) como credencial específica de seguridad. El mayor mercado, el ecosistema de tooling más amplio, la opción por defecto si no tienes otras restricciones. La página de certificación AWS Security Specialty detalla el alcance del examen.

Ruta Azure: AZ-104 para vocabulario fundamental, luego AZ-500 (Microsoft Certified: Azure Security Engineer Associate). Para roles a nivel arquitecto, SC-100 (Cybersecurity Architect Expert) es la credencial senior, a menudo emparejada con SC-200 para trabajo de SOC en Microsoft Sentinel. Fuerte opción para enterprise, industrias reguladas y trabajo gubernamental en Europa. Mira la página de certificación Azure Security Engineer para guía de preparación.

Ruta GCP: Professional Cloud Security Engineer (PCSE) es la credencial focalizada. El mercado es menor que AWS o Azure pero paga bien en empleadores tech-forward. Empareja con Professional Cloud Architect para amplitud. La página de certificación GCP Security resume el examen.

Credenciales cross-platform útiles incluyen CCSP de ISC2 para roles con sesgo a gobernanza, y CKS (Certified Kubernetes Security Specialist) para cualquier equipo que opere clústeres.

Contexto de cumplimiento UE: NIS2, DORA, GDPR para cloud

Los empleadores europeos filtran cada vez más por fluidez en cumplimiento, y el suelo regulatorio ha subido fuertemente.

NIS2, transpuesta a ley nacional en toda la UE, expande el alcance de las obligaciones de ciberseguridad a muchos más sectores y eleva los requisitos sobre reporte de incidentes, seguridad de cadena de suministro y rendición de cuentas de la dirección. Los workloads cloud en sectores en alcance necesitan mapeos de control claros, y la evidencia CSPM suele formar parte del audit trail.

DORA, el Digital Operational Resilience Act, aplica a servicios financieros y a sus terceros críticos, incluidos los proveedores cloud. Obliga a gestión de riesgo ICT, mantenimiento de registro de terceros, threat-led penetration testing para entidades significativas y clasificación rigurosa de incidentes. De los cloud security engineers en bancos, aseguradoras y fintech se espera que conozcan DORA a nivel operativo.

GDPR sigue dando forma a residencia de datos, cifrado y requisitos de logging de accesos. Para cloud, la implicación práctica es que los workloads que manejan datos personales UE necesitan documentación clara de flujo de datos, estrategias de gestión de claves que tengan en cuenta la exposición a sub-procesadores y evidencia auditable de control de acceso.

No se espera que seas abogado. Se espera que traduzcas entre reguladores, auditores e ingenieros, y que sepas qué reglas AWS Config, qué iniciativas Azure Policy o qué hallazgos GCP Security Command Center proveen la evidencia que cada control requiere.

Un plan de transición realista de 9 meses

El timeline de transición que realmente funciona para sysadmins en activo:

Meses 1 a 2: elige una plataforma principal y completa la certificación de architect a nivel associate. La meta es vocabulario de plataforma y la capacidad de navegar consola y CLI bajo presión.

Meses 3 a 4: deep dive en identidad. Construye una organización AWS multi-cuenta con Control Tower o equivalente, configura SSO desde un proveedor de identidad externo, escribe políticas IAM para tres personas de workload realistas y documenta los modos de fallo que encuentres.

Meses 5 a 6: infrastructure as code y escaneo IaC. Reescribe tu entorno de laboratorio en Terraform u OpenTofu, añade Checkov a un hook pre-commit y construye un ruleset mínimo de Open Policy Agent que bloquee almacenamiento público y volúmenes sin cifrar.

Mes 7: seguridad de contenedores y Kubernetes. Levanta un clúster EKS, AKS o GKE, hardéalo contra el benchmark CIS, instala Falco para detección runtime y demuestra generación de SBOM más firma de imagen sobre un workload de ejemplo.

Mes 8: aprueba la certificación específica de seguridad, AWS Security Specialty, AZ-500 o GCP PCSE.

Mes 9: pulido de portfolio y búsqueda de empleo. Publica un write-up del laboratorio, contribuye una regla de detección o un módulo IaC a un proyecto open-source y empieza a aplicar a roles cloud security engineer. El programa del bootcamp está construido alrededor de este tipo de progresión por proyecto y comprime el bucle de aprendizaje para profesionales en activo.

Realidad salarial: de sysadmin a cloud security junior y a senior en la UE

El paisaje retributivo UE recompensa el movimiento con claridad.

Los roles de sysadmin y operaciones de infraestructura en Europa Occidental pagan típicamente entre 35.000 y 45.000 EUR para profesionales mid-level, con especialistas senior on-premises alcanzando los cincuenta y pocos.

Los roles cloud security engineer junior a mid-level, el target realista tras una transición exitosa, pagan entre 55.000 y 80.000 EUR según ubicación y sector. Berlín, Ámsterdam, Dublín, París y Madrid se agrupan alrededor de la mitad de esa banda, con Londres y Zúrich por encima.

Los roles cloud security engineer senior, alcanzados típicamente tres a cinco años tras la transición, pagan entre 75.000 y 95.000 EUR. Especialistas en Kubernetes Security, detection engineering o industrias reguladas empujan el extremo superior.

Los roles cloud security architect en sectores regulados superan regularmente 100.000 EUR en hubs europeos importantes. El trabajo de consultoría en firmas Big 4 y boutiques de seguridad sigue una curva similar con utilización facturable y viajes como variables.

El delta salarial entre sysadmin y cloud security engineer es real, típicamente entre 15.000 y 30.000 EUR en el punto de transición, y la trayectoria de arriba es más empinada que las carreras ops tradicionales. La prima es sostenida y no transitoria porque la demanda supera a la oferta año tras año.

Dónde encaja el bootcamp

El Bootcamp de Ciberseguridad de Unihackers cubre fundamentos de cloud security en el módulo m11 (Security Engineering and Emerging Topics), junto con el contexto de seguridad más amplio que los cloud security engineers necesitan. Para sysadmins con bases fuertes de infraestructura, el bootcamp añade el contexto de seguridad y ofensivo que las bases puras de infraestructura no cubren. Lee el programa para desglose módulo a módulo.

Frenos comunes

Tres patrones explican la mayoría de transiciones sysadmin a cloud security estancadas:

1. Distribuirse entre tres clouds antes de dominar una. La familiaridad superficial vale menos que la profundidad real. La mayoría de roles cloud security senior quieren expertise específica de plataforma.

2. Saltarse infrastructure as code. El trabajo cloud security moderno asume fluidez en IaC. Existen ingenieros cloud security de click-ops pero tienden a estancarse en niveles junior.

3. Subestimar la complejidad de identidad. La identidad cloud es el vector de ataque más común y el skill más difícil de fingir. Construye profundidad genuina aquí.

La transición es real y bien pagada, pero premia la profundidad sobre la amplitud. Los senior cloud security engineers construyeron una plataforma bien primero, después expandieron.