Dominando el Penetration Testing para arquitecturas de nube híbrida

La mayoría de las empresas hoy en día no están simplemente "en la nube" o "en las instalaciones". Están atrapadas en algún punto intermedio. Tal vez hayas movido tus aplicaciones orientadas al cliente a AWS o Azure, pero tus datos financieros principales aún residen en un servidor heredado en una sala con clima controlado en tu sótano. O quizás estés utilizando una configuración híbrida para equilibrar la elasticidad de la nube con el estricto control de la infraestructura privada. Es una forma práctica de crecer, pero desde una perspectiva de seguridad, es una pesadilla.

El problema es que la "superficie de ataque" en una nube híbrida es extraña. No solo estás defendiendo un perímetro; estás defendiendo un puente. A los atacantes no les importa dónde viven tus datos; buscan el eslabón más débil en la conexión entre tu centro de datos privado y tu proveedor de nube pública. Si tu configuración de la nube es laxa, un atacante puede saltar desde un bucket S3 mal configurado directamente a tu red corporativa interna. Si tu VPN local está desactualizada, eso se convierte en la puerta de entrada a tu entorno de nube.

Dominar el Penetration Testing para arquitecturas de nube híbrida significa que tienes que dejar de pensar en silos. No puedes simplemente ejecutar un escaneo en tus activos de la nube y luego ejecutar una auditoría separada en tus servidores locales. Tienes que probar el flujo. Tienes que pensar como un atacante que quiere atravesar esos límites.

En esta guía, vamos a desglosar exactamente cómo abordar esto. Cubriremos las vulnerabilidades específicas que plagan las configuraciones híbridas, cómo construir una estrategia de pruebas que realmente encuentre cosas y cómo pasar de "verificaciones de cumplimiento" anuales a un estado de seguridad continua.

Por qué las arquitecturas de nube híbrida son un campo minado de seguridad

Cuando te mueves a un modelo de nube puro, confías en las herramientas de seguridad del proveedor. Cuando te mantienes puro en las instalaciones, controlas todo. Pero en un modelo híbrido, tienes una "responsabilidad compartida" que a menudo se malinterpreta.

El problema más común es la suposición de que la conexión entre la nube y el centro de datos es inherentemente segura. Muchos equipos configuran una VPN de sitio a sitio o una línea dedicada (como AWS Direct Connect o Azure ExpressRoute) y asumen que, debido a que es un túnel "privado", no necesitan preocuparse por la segmentación interna. Este es un error masivo. Si un atacante gana un punto de apoyo en un servidor web basado en la nube, y ese servidor tiene una ruta a la base de datos local a través del túnel, el atacante está efectivamente dentro de tu casa.

Luego está la crisis de identidad. La gestión de usuarios a través de Active Directory en las instalaciones y un proveedor de identidad (IdP) en la nube a menudo conduce a una "acumulación de permisos". Las personas obtienen acceso a cosas que no necesitan, y cuando dejan la empresa, su acceso se revoca en un lugar pero persiste en otro.

La "brecha de visibilidad"

En una configuración tradicional, tienes un firewall. Ves el tráfico. En una configuración híbrida, tienes tráfico "invisible". Los servicios nativos de la nube, como las funciones Lambda o los clústeres de Kubernetes administrados, a menudo se comunican de maneras que las herramientas de monitoreo locales tradicionales no pueden ver. Esto crea un punto ciego. Podrías estar registrando cada paquete que llega a tu servidor local, pero no tienes idea de que una llamada API no autorizada en tu entorno de nube está extrayendo datos de tu servidor SQL local.

La complejidad como vulnerabilidad

La complejidad es el enemigo de la seguridad. Cuando tienes diferentes conjuntos de reglas para tus grupos de seguridad en la nube y tus reglas de firewall locales, ocurren errores. Un desarrollador podría abrir un puerto para pruebas en la nube y olvidarse de cerrarlo, sin darse cuenta de que este puerto proporciona una ruta directa a un sistema heredado interno sensible.

Planificación de tu estrategia de Penetration Testing híbrido

No puedes simplemente "improvisar" con un entorno híbrido. Si comienzas a ejecutar escaneos agresivos sin un plan, es probable que bloquees un servidor heredado o actives el sistema de defensa automatizado de un proveedor de nube, lo que podría hacer que tu cuenta se marque o se limite.

Una estrategia real requiere un enfoque por fases. Primero debes mapear la arquitectura, luego definir los límites y finalmente ejecutar una serie de pruebas específicas.

Fase 1: Descubrimiento y mapeo de activos

No puedes probar lo que no sabes que existe. En un entorno híbrido, la "TI en la sombra" es rampante. Alguien podría haber creado un entorno de prueba en GCP que todavía está conectado al LDAP corporativo.

• Inventario de la nube: Utiliza herramientas para enumerar cada instancia, bucket y función sin servidor.
• Inventario local: Audita tus servidores físicos, máquinas virtuales y dispositivos de red.
• Mapeo de conexiones: Documenta exactamente cómo se comunican los dos entornos. ¿Es una VPN? ¿Un circuito dedicado? ¿Qué puertos están abiertos? ¿Qué rangos de IP son de confianza?

Fase 2: Definición del alcance

La expansión del alcance es un peligro real en el Penetration Testing. Debes tener claro qué está "dentro del alcance" y "fuera del alcance".

Por ejemplo, ¿tienes permiso para probar la infraestructura subyacente del proveedor de la nube? (Pista: Por lo general, no. Pruebas tu configuración en su infraestructura). ¿Tienes permiso para realizar pruebas de denegación de servicio (DoS) en el enlace híbrido? Probablemente no, porque si ese enlace se cae, todo tu negocio podría detenerse.

Fase 3: Modelado de amenazas

No te limites a ejecutar una herramienta. Pregunta: "¿Quién quiere mis datos y cómo los obtendría?"

• Escenario A: Un atacante compromete una aplicación web basada en la nube e intenta moverse lateralmente al sistema de nómina local.
• Escenario B: La computadora portátil de un empleado está infectada, se conecta a la oficina a través de una VPN y el atacante utiliza esa ruta para acceder a la consola de administración de la nube.
• Escenario C: Un bucket de almacenamiento en la nube mal configurado filtra una clave secreta que permite a un atacante crear nuevos usuarios administrativos en el entorno híbrido.

Prueba de la conexión nube a tierra

El "puente" es donde ocurren la mayoría de los fallos híbridos. Esta es la parte más crítica de su Penetration Test. Querrá comprobar si la separación entre sus entornos es una pared real o solo una sugerencia.

Probando la VPN y las conexiones directas

Si está utilizando una VPN de sitio a sitio, la primera pregunta es: ¿está cifrada correctamente? ¿Está utilizando protocolos obsoletos?

Más allá del cifrado, observe el enrutamiento. Muchas organizaciones permiten la comunicación "cualquiera a cualquiera" a través del enlace híbrido. Esto significa que cualquier VM comprometida en la nube puede hacer ping a cualquier servidor local. Un penetration tester intentará escanear la red local desde una instancia en la nube comprometida. Si pueden ver su controlador de dominio o su servidor de copias de seguridad, tiene un problema de segmentación.

Comprobación de las reglas del firewall y los grupos de seguridad

Los grupos de seguridad en la nube tienen estado, pero los firewalls locales a menudo operan de manera diferente. Esta falta de coincidencia conduce a "agujeros".

• Reglas permisivas: Busque reglas 0.0.0.0/0 en sus grupos de seguridad en la nube. Incluso si es solo para un puerto, ese es un punto de entrada potencial.
• Exceso de confianza en el enlace híbrido: Compruebe si su firewall local trata todo el tráfico procedente del rango de IP de la nube como "de confianza". Si lo hace, cualquier brecha en la nube es una brecha automática de la red local.

Probando el puente de identidad

La mayoría de las configuraciones híbridas utilizan alguna forma de sincronización de identidad (como Azure AD Connect). Este es un objetivo de alto valor.

Si un atacante puede comprometer una cuenta de bajo privilegio en la nube, ¿puede usarla para escalar privilegios en las instalaciones? Esto sucede a menudo a través de ataques de "golden ticket" o explotando relaciones de confianza mal configuradas entre el inquilino de la nube y el bosque local.

Pruebe esto durante su prueba:

1. Comprometa una cuenta de usuario estándar en la nube.
2. Compruebe si hay credenciales o scripts almacenados en el entorno de la nube que puedan contener contraseñas de cuentas de servicio locales.
3. Intente utilizar esas credenciales para acceder a un recurso interno local a través del enlace híbrido.

Evaluación de la capa de la nube: puntos débiles comunes

Si bien la conexión es el puente, la nube en sí proporciona los puntos de entrada. La mayoría de los "ataques a la nube" no son en realidad ataques al proveedor de la nube, sino ataques a la configuración del usuario.

Almacenamiento mal configurado (el síndrome del "cubo con fugas")

Es un cliché porque sucede todos los días. Los buckets de S3 o los Azure Blobs se dejan públicos.

Un penetration tester utilizará herramientas para encontrar buckets de acceso público. Pero el peligro real en una configuración híbrida es cuando esos buckets contienen archivos de configuración, archivos .env o claves SSH que brindan acceso al entorno local. Encontrar un "backup_config.json" en un bucket público es a menudo el "golden ticket" que necesita un atacante.

Exceso de permisos de roles IAM

La gestión de identidades y accesos (IAM) es el nuevo perímetro. Si un desarrollador le da a una instancia en la nube AdministratorAccess solo para "que funcione", ha creado un riesgo enorme.

Si un atacante obtiene acceso shell a una instancia en la nube (a través de una vulnerabilidad RCE en una aplicación web), lo primero que hace es verificar el servicio de metadatos (por ejemplo, 169.254.169.254). Quieren ver qué rol IAM está adjunto a esa instancia. Si ese rol tiene permisos para modificar la configuración de la red o acceder a otros servicios en la nube, el atacante puede moverse lateralmente a través de su entorno en la nube incluso antes de tocar sus servidores locales.

Vulnerabilidades de Serverless y Contenedores

Si está utilizando funciones Lambda o Kubernetes (EKS/AKS/GKE), tiene nuevos riesgos.

• Escapes de contenedores: Si un contenedor se está ejecutando como root, un atacante podría "escapar" al nodo host. Desde allí, pueden ver todos los demás contenedores en ese nodo y potencialmente acceder a la API subyacente del proveedor de la nube.
• Inyección de funciones: Las funciones Serverless a menudo toman la entrada de las solicitudes web. Si esa entrada no se desinfecta, puede tener una inyección de comandos que permita a un atacante ejecutar código en el entorno de la nube, potencialmente robando secretos de las variables de entorno.

Evaluación de la capa local: el riesgo heredado

Por lo general, el lado local de una nube híbrida es donde vive lo "viejo". Los sistemas heredados rara vez se actualizan porque "si no está roto, no lo arregles". Pero en un mundo híbrido, "no roto" no significa "seguro".

Fallos en la gestión de parches

Sus instancias en la nube podrían actualizarse automáticamente a través de una canalización CI/CD, pero su servidor de archivos local probablemente esté ejecutando Windows Server 2012.

Un penetration tester buscará vulnerabilidades sin parches (como EternalBlue o PrintNightmare) en sus servidores locales. Una vez que obtienen un punto de apoyo en un servidor local, pueden usarlo como un punto de pivote para atacar la consola de administración de la nube si el servidor local ha guardado credenciales o tokens de sesión.

El peligro de las redes planas

Muchas redes locales son "planas", lo que significa que una vez que está dentro, puede ver todo. En una configuración híbrida, esto es letal. Si el puente de la nube aterriza en una red local plana, el "radio de explosión" de un compromiso de la nube se extiende a todos y cada uno de los dispositivos de su oficina.

La solución: Implemente la microsegmentación. El enlace híbrido debe aterrizar en una "DMZ" o una VPC/VNet de tránsito específica. A partir de ahí, el tráfico debe filtrarse estrictamente. Solo las aplicaciones específicas de la nube que necesitan comunicarse con la base de datos local específica deben poder hacerlo.

Interfaces de gestión no seguras

En las instalaciones, es común encontrar consolas de administración antiguas (IPMI, iDRAC, vSphere) que son accesibles a través de la red. Si estos están expuestos al enlace híbrido, un atacante basado en la nube podría reiniciar sus servidores físicos o reinstalar el sistema operativo.

Tutorial paso a paso: un escenario de movimiento lateral

Para entender cómo encaja todo esto, repasemos un escenario de ataque hipotético. Esto es exactamente lo que parece un Penetration Test profesional al probar una arquitectura híbrida.

La Configuración: Una empresa tiene un frontend nativo de la nube (AWS) y un backend on-prem (Centro de Datos Privado). Están conectados a través de una VPN Site-to-Site.

Paso 1: La Brecha Inicial El atacante encuentra una versión obsoleta de un CMS en el sitio web. Utiliza un exploit conocido para obtener una shell de bajos privilegios en el servidor web.

Paso 2: Reconocimiento en la Nube El atacante consulta el Servicio de Metadatos de AWS. Descubre que la instancia tiene un rol IAM llamado App-Server-Role. Al verificar los permisos, descubre que este rol tiene permiso para leer desde un bucket S3 llamado company-configs.

Paso 3: Exfiltración de Secretos El atacante descarga el contenido del bucket y encuentra un archivo llamado db_connect.txt. Este archivo contiene la dirección IP de un servidor SQL on-prem y una contraseña de cuenta de servicio.

Paso 4: Cruzando el Puente El atacante intenta conectarse a la dirección IP on-prem. Debido a que la VPN permite todo el tráfico desde la VPC de AWS a la subred on-prem, la conexión se realiza correctamente.

Paso 5: Escalada On-Prem El atacante utiliza la cuenta de servicio para iniciar sesión en el servidor SQL. Descubre que el servidor SQL se está ejecutando como Administrador Local. Utilizando un exploit de escalada de privilegios (como una vulnerabilidad conocida del kernel), obtiene acceso SYSTEM completo al servidor on-prem.

Paso 6: Compromiso Total del Dominio Ahora dentro de la red on-prem, el atacante usa mimikatz para volcar la memoria y encontrar las credenciales de un Administrador de Dominio que inició sesión en ese servidor hace una semana. El atacante ahora posee todo el bosque de identidades corporativas.

La Lección: El "hack" no ocurrió debido a un gran fallo. Ocurrió debido a una cadena de pequeños fallos: un CMS sin parches $\rightarrow$ rol IAM con privilegios excesivos $\rightarrow$ secretos en un bucket S3 $\rightarrow$ falta de segmentación de red en la VPN.

Cómo Automatizar y Escalar las Pruebas Híbridas

Hacer un Penetration Test manual una vez al año es como hacerse un examen físico una vez al año y asumir que estás sano todos los días intermedios. En una nube híbrida, las cosas cambian cada hora. Alguien añade una regla a un grupo de seguridad; alguien levanta una nueva VM; alguien actualiza un fragmento de código.

Necesitas una forma de hacer que este proceso sea continuo.

Escaneo Continuo de Vulnerabilidades

No puedes simplemente escanear tus IPs. Necesitas un escáner "consciente de los activos". Esto significa una herramienta que sepa cuándo se crea una nueva instancia en tu nube y la añada automáticamente a la lista de escaneo. También debería ser capaz de alcanzar a través del enlace híbrido para comprobar el estado de tus activos on-prem.

El Papel de la Simulación de Brechas y Ataques (BAS)

Las herramientas BAS te permiten ejecutar "playbooks" de ataques. Puedes simular el escenario de ataque "Cloud-to-Ground" descrito anteriormente cada semana. Si un cambio de configuración abre repentinamente un agujero en tu firewall, la herramienta BAS lo detectará en la siguiente ejecución, en lugar de esperar a que un probador humano lo encuentre seis meses después.

Integración con tu Flujo de Trabajo

El mayor problema con las pruebas de seguridad es el "Informe en PDF". Un PDF de 100 páginas de vulnerabilidades es donde la seguridad va a morir.

Necesitas que los resultados de tus pruebas se alimenten directamente a tu sistema de tickets (Jira, ServiceNow, etc.). Si se encuentra una vulnerabilidad de alta gravedad en el enlace híbrido, debería activar automáticamente un ticket para el equipo de red.

Aprovechando Penetrify para la Seguridad Híbrida

Aquí es donde una plataforma como Penetrify se convierte en un punto de inflexión. Intentar gestionar todo esto manualmente —el escaneo, las pruebas manuales, el mapeo y la remediación— es un trabajo de tiempo completo para un equipo grande.

Penetrify proporciona una arquitectura nativa de la nube que resuelve el dolor de cabeza de la infraestructura. En lugar de tener que configurar tus propias "cajas de ataque" on-prem y en la nube, Penetrify te permite desplegar evaluaciones de seguridad bajo demanda. Cierra la brecha proporcionando tanto escaneo automatizado como experiencia manual, lo que significa que obtienes la velocidad de una herramienta con el pensamiento crítico de un humano. Tanto si eres una empresa de mercado medio que intenta escalar su seguridad sin contratar a cinco nuevos ingenieros, como si eres una empresa que gestiona una web híbrida compleja, Penetrify te ayuda a identificar esas vulnerabilidades de "puente" antes de que lo haga un atacante real.

Errores Comunes en el Penetration Testing Híbrido

He visto a muchos equipos "hacer" Penetration Testing, pero lo hacen de una manera que proporciona una falsa sensación de seguridad. Aquí están las trampas más comunes:

1. Pruebas en un Entorno "Limpio"

Algunas empresas crean un entorno de "staging" que se parece a su configuración híbrida, pero es "más limpio" que la producción. Esto es inútil. La producción es donde está el "desorden". La producción es donde viven las antiguas reglas heredadas. Si no pruebas el entorno real donde se encuentran los datos, no estás encontrando riesgos reales.

2. Ignorar la Ruta "Ground-to-Cloud"

Todo el mundo se preocupa de que la nube sea el punto de entrada. ¿Pero qué pasa con el camino inverso? Un atacante entra en una estación de trabajo local a través de phishing, y luego utiliza el enlace híbrido para acceder a la consola de gestión de la nube. Si tu consola de administración de la nube es accesible desde la red corporativa interna sin Autenticación Multifactor (MFA), estás completamente abierto.

3. Confiar Únicamente en Herramientas Automatizadas

Los escáneres automatizados son geniales para encontrar parches faltantes, pero son terribles para encontrar fallos lógicos. Un escáner no te dirá: "Oye, este rol IAM es demasiado poderoso para esta aplicación específica". Sólo te dirá que el servidor está parcheado. Necesitas exploración manual para encontrar las rutas de movimiento lateral.

4. Omitir el Paso de "Verificación de la Remediación"

Un patrón común:

1. La prueba encuentra una vulnerabilidad.
2. El equipo de desarrollo dice "¡Lo arreglé!"
3. El equipo de seguridad lo marca como "Cerrado".

Nunca hagas esto. Siempre vuelve a probar. A menudo, una "solución" simplemente mueve la vulnerabilidad a otro lugar o en realidad no resuelve la causa raíz.

Lista de verificación de seguridad de la nube híbrida

Si te estás preparando para un Penetration Test o estás haciendo una autoauditoría, usa esta lista de verificación para asegurarte de que has cubierto las bases.

Red y conectividad

• Audita todas las configuraciones de VPN de sitio a sitio y Direct Connect.
• Verifica que el enlace híbrido aterrice en una subred restringida (no en la red central local).
• Comprueba si hay algún bloque CIDR 0.0.0.0/0 o excesivamente amplio en los grupos de seguridad de la nube.
• Confirma que los firewalls locales están filtrando el tráfico que viene de la nube.
• Mapea todos los puertos y protocolos permitidos a través del puente híbrido.

Identidad y acceso

• Revisa los roles de IAM para el "Principio de Privilegio Mínimo."
• Audita la sincronización de identidades (por ejemplo, AD Connect) en busca de rutas de escalada de privilegios.
• Asegúrate de que se requiera MFA para todo el acceso a la consola de administración de la nube, incluso desde la red interna.
• Comprueba si hay credenciales/secretos codificados en el almacenamiento en la nube o en las variables de entorno.
• Verifica que las cuentas "huérfanas" (antiguos empleados) se eliminen tanto de los sistemas en la nube como de los locales.

Infraestructura y aplicaciones

• Escanea todos los buckets de almacenamiento en la nube de acceso público en busca de permisos abiertos.
• Audita los servidores heredados locales en busca de vulnerabilidades críticas sin parches.
• Prueba el aislamiento de contenedores para garantizar que un pod comprometido no pueda acceder al nodo host.
• Verifica que las funciones sin servidor tengan acceso restringido a los recursos internos.
• Asegúrate de que el registro centralizado esté capturando el tráfico tanto en la nube como en las instalaciones locales.

Comparación: Pentesting tradicional vs. Pentesting de nube híbrida

Característica	Pentesting tradicional	Pentesting de nube híbrida
Perímetro	Claramente definido (Firewall)	Fluido (IAM, API, VPN, VPC)
Enfoque	Externo $\rightarrow$ Interno	Nube $\leftrightarrow$ Local $\leftrightarrow$ Nube
Herramientas	Escáneres de red, Metasploit	Herramientas nativas de la nube, auditores de IAM, BAS
Velocidad	Periódico (anual/trimestral)	Continuo/Bajo demanda
Área de riesgo	Errores de software, puertos abiertos	Errores de configuración, relaciones de confianza
Responsabilidad	Totalmente interna	Compartida (tú + proveedor de la nube)

Preguntas frecuentes: Dominar la seguridad de la nube híbrida

P: ¿Necesito notificar a mi proveedor de la nube antes de realizar un Penetration Test? R: En el pasado, tenías que pedir permiso para casi todo. Hoy en día, AWS, Azure y GCP tienen listas de "Servicios permitidos". Para la mayoría de las pruebas estándar (escanear tus propias instancias, atacar tus propias aplicaciones), no necesitas notificarlos. Sin embargo, si estás haciendo algo agresivo como una prueba DDoS o probando la estructura subyacente, debes consultar la política del proveedor para evitar que se suspenda tu cuenta.

P: ¿Qué es más peligroso: el lado de la nube o el lado local? R: Ninguno es inherentemente "más" peligroso; simplemente tienen diferentes modos de fallo. El lado de la nube falla debido a una mala configuración (por ejemplo, un bucket S3 abierto). El lado local falla debido a la negligencia (por ejemplo, un servidor sin parches de 2016). El verdadero peligro es la interacción entre los dos.

P: ¿Con qué frecuencia debo probar mi arquitectura híbrida? R: Si perteneces a una industria regulada (HIPAA, PCI DSS, SOC 2), es probable que tengas un requisito de pruebas anuales o semestrales. Pero, ¿honestamente? Deberías realizar escaneos automatizados semanalmente y Penetration Testing manuales profundos cada vez que realices un cambio significativo en tu arquitectura (por ejemplo, cambiar tu proveedor de VPN o migrar una nueva aplicación central a la nube).

P: ¿Puedo usar herramientas de código abierto para las pruebas híbridas? R: Sí, herramientas como Nmap, Burp Suite y Metasploit siguen siendo esenciales. Para el lado de la nube, herramientas como Prowler o Scout Suite son excelentes para auditar las configuraciones. Sin embargo, el desafío no son las herramientas, sino la correlación de los datos. Esta es la razón por la que una plataforma como Penetrify es útil; organiza los hallazgos en una imagen coherente de tu riesgo real.

P: ¿Qué es lo más importante que puedo hacer para asegurar mi enlace híbrido? R: Deja de confiar en la naturaleza "privada" del enlace. Trata la conexión entre tu nube y tu centro de datos como si fuera la internet pública. Requiere autenticación en cada salto, encripta todo y utiliza un enfoque de "Zero Trust". Si una aplicación en la nube necesita comunicarse con una base de datos local, debería ser lo único que se le permita hacer, en un puerto específico, y solo después de que se haya autenticado.

Próximos pasos prácticos

Si te sientes abrumado por la complejidad de tu configuración híbrida, no intentes arreglar todo a la vez. Comienza con estos tres pasos:

1. Mapee el puente: Dedique una tarde a documentar cada una de las formas en que su entorno de nube se comunica con su entorno local. Si encuentra una conexión que no reconoce, ciérrela o investíguela de inmediato.
2. Refuerce la IAM: Revise sus roles de nube más utilizados. Si un rol tiene AdministratorAccess o FullS3Access pero solo necesita leer un bucket específico, cámbielo. Esta es la forma más rápida de reducir su radio de explosión.
3. Ejecute una prueba dirigida: No espere a su auditoría anual. Elija un activo local de alto valor e intente ver si puede acceder a él desde una instancia de nube con pocos privilegios. Si puede, acaba de encontrar su primera prioridad principal para la remediación.

La seguridad no es un destino; es un proceso de refinamiento constante. Cuanto más pruebe, más se dará cuenta de que los "muros" que pensaba que tenía a menudo son solo cortinas. Al adoptar una estrategia de Penetration Testing que tenga en cuenta el entorno híbrido, pasa de suponer que está seguro a saber exactamente dónde están sus carencias.

Si desea dejar de adivinar y comenzar a validar su seguridad, Penetrify puede ayudarlo a automatizar las partes aburridas de este proceso al tiempo que le brinda la información experta necesaria para proteger su arquitectura híbrida. Visite penetrify.cloud para ver cómo puede comenzar a identificar y corregir vulnerabilidades antes de que se conviertan en titulares.