Elimine los puntos ciegos en la seguridad de la nube con Penetration Testing

La mayoría de la gente piensa que mudarse a la nube automáticamente los hace seguros. Existe la creencia común de que, dado que Amazon, Microsoft o Google se encargan de los servidores físicos y los hipervisores, la "parte de seguridad" básicamente está cubierta. Pero esta es la realidad: el proveedor de la nube asegura la nube, pero tú sigues siendo responsable de asegurar todo lo que pones en la nube.

Se llama el Modelo de Responsabilidad Compartida, y es donde la mayoría de las empresas tropiezan. Dejan un bucket abierto, configuran incorrectamente un permiso de S3 u olvidan parchear una máquina virtual, y de repente, tienen un punto ciego enorme. Un punto ciego no es solo una configuración faltante; es una brecha en la visibilidad que no sabes que existe hasta que alguien más la encuentra, generalmente alguien que no está invitado.

Esta es la razón por la cual el Penetration Testing (o pentesting) ya no es solo un "nice to have" para la auditoría anual. Si estás ejecutando un negocio digital moderno, es probable que estés lidiando con una mezcla de contenedores, funciones serverless y APIs heredadas. La superficie de ataque es enorme. No puedes simplemente ejecutar un escáner de vulnerabilidades y darlo por terminado. Los escáneres encuentran agujeros conocidos; los pentesters encuentran vías de acceso.

En esta guía, vamos a hablar sobre cómo encontrar realmente esos puntos ciegos, por qué las herramientas automatizadas no son suficientes y cómo construir una cadencia de pruebas que mantenga tu infraestructura ajustada sin ralentizar a tus desarrolladores.

La anatomía de un punto ciego de seguridad en la nube

Antes de sumergirnos en las soluciones, necesitamos entender contra qué estamos luchando realmente. Un "punto ciego" en la seguridad de la nube es esencialmente una vulnerabilidad que no es detectada por tus herramientas de monitoreo y seguridad actuales.

¿Por qué sucede esto? Porque los entornos de la nube son dinámicos. Puedes crear un nuevo entorno en segundos. Un desarrollador podría crear un área de pruebas temporal para probar una función, abrir el Puerto 22 a todo Internet por "solo una hora" y luego olvidarse de ello. Es posible que tu política de seguridad estática no detecte eso en tiempo real, o que la alerta quede enterrada bajo una montaña de otros registros.

El problema de la "Shadow IT"

La Shadow IT es una fuente clásica de puntos ciegos. Esto sucede cuando los equipos implementan recursos en la nube, como una pequeña base de datos o una nueva herramienta SaaS, sin informar al equipo de IT o de seguridad. Si el equipo de seguridad no sabe que el recurso existe, no puede monitorearlo, no puede parchearlo y, ciertamente, no puede hacerle un Penetration Test. Estos activos "olvidados" son minas de oro para los atacantes porque a menudo carecen de los controles de seguridad estándar aplicados al resto de la organización.

Errores de configuración: el asesino silencioso

Vemos esto constantemente. Un entorno de nube es tan seguro como su configuración. Una sola casilla de verificación en una política de IAM (Identity and Access Management) puede otorgar accidentalmente a un usuario de bajo nivel privilegios administrativos en toda la cuenta. Para un escáner de vulnerabilidades, el sistema parece estar "en funcionamiento". Pero para un pentester, esa configuración incorrecta es una puerta abierta.

Sobreexposición de la API

Las aplicaciones modernas en la nube dependen de las APIs para comunicarse entre sí. A menudo, estas APIs están documentadas internamente, pero algunos endpoints quedan expuestos a la internet pública. Si esos endpoints no tienen una autenticación estricta o limitación de velocidad, se convierten en un camino directo a tus datos. La mayoría de las organizaciones tienen una idea general de sus APIs, pero pocas tienen un mapa completo y actualizado de cada endpoint y quién puede acceder a ellos.

Por qué el escaneo de vulnerabilidades tradicional no es suficiente

Si ya estás utilizando un escáner de vulnerabilidades, es posible que te preguntes por qué necesitas un Penetration Testing. Es una pregunta justa. Los escáneres son geniales para lo que son: verifican los "known-knowns". Buscan una versión específica de software que tenga un CVE (Common Vulnerabilities and Exposures) conocido y lo marcan.

Pero la seguridad no se trata solo de parchear software. Se trata de lógica.

La diferencia entre un escaneo y una prueba

Un escaneo de vulnerabilidades es como caminar alrededor de una casa y verificar si las puertas están cerradas con llave. Un Penetration Test es como si alguien realmente intentara abrir la cerradura, trepar por la chimenea o engañar al propietario para que abra la puerta.

Los pentesters buscan cadenas de ataque. Una cadena de ataque es una secuencia de pequeños problemas, aparentemente insignificantes, que, cuando se combinan, conducen a un compromiso total del sistema. Por ejemplo:

1. Un atacante encuentra un sitio de desarrollo antiguo y olvidado (Punto Ciego 1).
2. Encuentran una manera de subir un pequeño archivo a ese sitio (Vulnerabilidad 1).
3. Usan ese archivo para robar una cookie de sesión para un usuario con pocos privilegios (Vulnerabilidad 2).
4. Encuentran un rol de IAM mal configurado que permite a un usuario con pocos privilegios listar todos los buckets de S3 (Punto Ciego 2).
5. Encuentran un bucket que contiene copias de seguridad de la base de datos y descargan tu lista de clientes.

Un escáner habría marcado "software desactualizado" en el sitio de desarrollo, pero no te habría dicho que este camino específico conduce a los datos de tus clientes. Ese es el valor de un enfoque de prueba nativo de la nube avanzado o dirigido por humanos.

La falsa sensación de seguridad

El mayor peligro de depender únicamente de los escáneres es el efecto de la "casilla de verificación verde". Cuando tu panel muestra cero vulnerabilidades de alto riesgo, te sientes seguro. Pero los escáneres no detectan fallas lógicas, controles de acceso rotos y configuraciones incorrectas complejas. Si solo confías en el escáner, en realidad no estás seguro; simplemente estás "compliant" con la definición limitada de seguridad de tu herramienta.

Mapeo de tu superficie de ataque en la nube

No puedes probar lo que no sabes que tienes. El primer paso para eliminar los puntos ciegos es un proceso riguroso de descubrimiento de activos.

External Attack Surface Management (EASM)

EASM es la práctica de observar tu organización desde afuera hacia adentro. Esto significa buscar cada dirección IP, dominio y bucket en la nube asociado con tu marca.

Para hacer esto de manera efectiva, debes buscar:

• Subdominios Olvidados: test-api.company.com o dev-portal.company.com.
• Registros DNS Huérfanos: Registros que apuntan a un recurso en la nube que ha sido eliminado, el cual puede ser reclamado por un atacante (Subdomain Takeover).
• Puertos de Administración Expuestos: SSH (22), RDP (3389), o puertos de bases de datos (3306, 5432) dejados abiertos al mundo.

Descubrimiento y Mapeo Interno

Una vez que tienes mapeado el perímetro exterior, necesitas mirar dentro. Esto implica auditar tu consola de la nube.

• Roles IAM: ¿Quién tiene "AdministratorAccess"? ¿Hay roles con permisos excesivamente amplios?
• Arquitectura de Red: ¿Tienes VPCs (Virtual Private Clouds) que están interconectadas de maneras que permiten el movimiento lateral?
• Almacenamiento de Datos: ¿Dónde están los datos sensibles? ¿Están encriptados en reposo? ¿Está activado el registro de acceso?

Integrando el Descubrimiento con Penetrify

Aquí es donde una plataforma como Penetrify se convierte en un punto de inflexión. En lugar de buscar manualmente activos en una hoja de cálculo, la arquitectura nativa de la nube de Penetrify te permite integrarte directamente con tu entorno. Te ayuda a identificar estos activos y luego pasar inmediatamente a la fase de evaluación. Al automatizar el descubrimiento y el escaneo inicial, elimina el "ruido" para que los testers manuales puedan centrarse en las cadenas de ataque de alto valor mencionadas anteriormente.

Estrategias Avanzadas de Penetration Testing para la Nube

Una vez que tienes tu mapa, necesitas una estrategia. El Penetration Testing en la nube es diferente del Penetration Testing de red tradicional porque la "red" está definida por software. No estás enchufando un portátil a una toma de pared; estás interactuando con una API.

Pruebas para la Escalamiento de Privilegios

En la nube, el objetivo de un atacante no suele ser "bloquear el servidor", sino obtener privilegios más altos. Los pentesters buscan formas de pasar de una función Lambda comprometida a un rol de Administrador Completo.

Las rutas comunes incluyen:

• Roles de Paso: ¿Puede un usuario crear un nuevo recurso y asignarle un rol que tenga más poder que el propio usuario?
• Errores de Configuración de Políticas: ¿Existen permisos "Comodín" (por ejemplo, s3:*) que permitan a un usuario hacer cosas que no debería?
• Fugas de Credenciales: ¿Hay claves de acceso de AWS codificadas en un repositorio público de GitHub o almacenadas en una variable de entorno no encriptada?

Evaluación de la Seguridad de Contenedores y Kubernetes

Si estás utilizando Docker o K8s, tus puntos ciegos acaban de crecer. Los contenedores comparten el kernel del sistema operativo host, lo que crea nuevos riesgos.

• Escape de Contenedor: ¿Puede un atacante salir del contenedor y acceder a la máquina host subyacente?
• Error de Configuración de Kubelet: ¿Está expuesto el servidor Kubernetes API sin autenticación?
• Vulnerabilidades de Imagen: ¿Estás utilizando una imagen base de una fuente no confiable que contiene una puerta trasera?

Pruebas de Seguridad Serverless (Lambda, Azure Functions)

Serverless no significa "no hay servidores que gestionar"; significa "servidores que no ves". Este es un gran punto ciego.

• Inyección de Eventos: ¿Puede un atacante enviar una carga maliciosa a través de una cola SQS o un API Gateway que la función Lambda ejecute posteriormente?
• Funciones con Exceso de Privilegios: ¿Tiene tu función Lambda de "envío de correo electrónico" también permiso para eliminar tablas en DynamoDB? (No debería).
• Agotamiento de Tiempo de Espera y Recursos: ¿Puede un atacante activar miles de funciones para acumular una factura masiva o causar una Denegación de Servicio (DoS)?

Cómo Construir un Ciclo de Vida de Pruebas Continuas

El Penetration Test "una vez al año" está muerto. En un mundo de pipelines de CI/CD donde el código se despliega diez veces al día, una auditoría anual queda obsoleta en el momento en que termina. Necesitas un enfoque continuo.

Avanzando Hacia el "Penetration Testing Continuo"

El Penetration Testing continuo no se trata de tener a un humano hackeando tu sistema 24/7 (aunque ese es un lujo que algunos tienen). Se trata de integrar las pruebas de seguridad en cada etapa del ciclo de vida del desarrollo.

Fase	Actividad de Seguridad	Objetivo
Diseño	Modelado de Amenazas	Identificar los puntos ciegos antes de que se escriba una sola línea de código.
Desarrollo	SAST (Static Analysis)	Detectar secretos codificados y fallos básicos del código.
Construcción	SCA (Software Composition Analysis)	Identificar bibliotecas de terceros vulnerables.
Despliegue	Escaneo Automatizado	Asegurarse de que no lleguen a producción errores de configuración obvios.
Post-Despliegue	Penetration Testing Dirigido	Utilizar Penetrify para encontrar cadenas de ataque complejas y fallos lógicos.

Estableciendo una Cadencia de Pruebas

Dependiendo de tu perfil de riesgo, debes variar la frecuencia de tus pruebas:

• Sistemas Críticos (Pasarelas de pago, BDs de Usuarios): Pruebas dirigidas mensuales o monitorización continua.
• Lanzamientos de Funciones Principales: Un Penetration Test enfocado en la nueva funcionalidad antes de que se ponga en marcha.
• Infraestructura General: Evaluaciones trimestrales a gran escala.

El Bucle de Retroalimentación: Del Hallazgo a la Solución

El error más común que cometen las empresas es tratar un informe de Penetration Test como una "lista de tareas" que se ignora. Para eliminar realmente los puntos ciegos, necesitas un bucle:

1. Identificar: El pentester encuentra una vulnerabilidad.
2. Validar: El equipo de seguridad confirma que es un riesgo real, no un False Positive.
3. Remediar: Los desarrolladores corrigen el código o la configuración.
4. Verificar: El pentester vuelve a probar para asegurarse de que la corrección realmente funciona y no ha roto nada más.
5. Prevenir: Actualizar el escáner automatizado o la política de CI/CD para asegurar que este fallo específico nunca regrese.

Puntos Ciegos Comunes en la Seguridad de la Nube (Y Cómo Solucionarlos)

Seamos prácticos. Aquí están algunos de los puntos ciegos más frecuentes que vemos y los pasos concretos que puedes tomar para cerrarlos.

1. El Bucket S3 / Azure Blob "Abierto"

Le pasa a los mejores. Un bucket se configura como público para una transferencia rápida y permanece así durante tres años.

• El Punto Ciego: Crees que los datos son internos, pero están indexados por motores de búsqueda como GrayhatWarfare.
• La Solución: Implementa "Block Public Access" a nivel de cuenta. Utiliza políticas IAM para conceder acceso a usuarios/roles específicos en lugar de hacer que el recurso sea público. Utiliza herramientas automatizadas (como las de Penetrify) para alertarte en el momento en que un bucket se vuelve público.

2. Cuentas de Servicio con Exceso de Privilegios

Los desarrolladores a menudo dan a una cuenta de servicio AdministratorAccess porque es "más fácil que averiguar qué permisos específicos se necesitan".

• El Punto Ciego: Si esa cuenta de servicio se ve comprometida (por ejemplo, a través de una clave filtrada), el atacante tiene las llaves del reino.
• La Solución: Principio del Mínimo Privilegio (PoLP). Utiliza herramientas como AWS Access Analyzer para ver qué permisos se están utilizando realmente y elimina los que no lo están.

3. Interfaces de Gestión No Protegidas

Dejar un panel de control de Jenkins, un panel de control de Kubernetes o un panel de administración de bases de datos expuesto a Internet.

• El Punto Ciego: Asumes que "nadie conoce la URL", pero los atacantes utilizan escáneres de fuerza bruta para encontrar rutas comunes como /admin o /jenkins.
• La Solución: Coloca estas interfaces detrás de una VPN o una solución de Zero Trust Network Access (ZTNA). Nunca expongas los puertos de gestión directamente a la web.

4. Falta de Agregación de Registros

Tener registros es una cosa; ser capaz de verlos es otra.

• El Punto Ciego: Un atacante está aplicando fuerza bruta lentamente a tu API. Los registros están registrando los fallos, pero están dispersos en diez servicios diferentes, y nadie los está mirando.
• La Solución: Centraliza tus registros en un sistema SIEM (Security Information and Event Management). Configura alertas para "patrones inusuales", como 1.000 inicios de sesión fallidos desde una sola IP en un minuto.

Paso a Paso: Cómo Ejecutar tu Primer Penetration Test en la Nube

Si nunca has hecho un Penetration Test profesional, el proceso puede parecer abrumador. Aquí tienes un sencillo recorrido de cómo hacerlo bien.

Paso 1: Define el Alcance

No digas simplemente "probar todo". Eso es una receta para un informe vago. Sé específico.

• Dentro del Alcance: VPC de Producción, la API del Cliente, el Backend de la Aplicación Móvil.
• Fuera del Alcance: El sistema de correo electrónico corporativo, las herramientas SaaS de terceros (como Salesforce) o los ataques DDoS (que pueden bloquear tu sitio).
• Restricciones: ¿Puede el tester intentar exfiltrar datos? ¿Puede crear nuevos usuarios?

Paso 2: Establece las Reglas de Compromiso (RoE)

Esta es esencialmente la parte "legal". Necesitas un acuerdo escrito que diga que el Penetration Test está autorizado.

• Tiempo: ¿Cuándo deben realizarse las pruebas? (por ejemplo, durante las horas de poco tráfico).
• Comunicación: ¿Quién es el punto de contacto si algo se rompe?
• Informes: ¿Cómo se informarán las vulnerabilidades? (¿Inmediatamente para las "Críticas", o todas a la vez al final?).

Paso 3: Reconocimiento y Descubrimiento

El tester comienza recopilando inteligencia. Utilizará herramientas para encontrar subdominios, puertos abiertos y credenciales filtradas. Aquí es donde encuentran tus puntos ciegos.

Paso 4: Análisis de Vulnerabilidades

El tester analiza los hallazgos. No sólo encuentran un "agujero"; averiguan qué les permite hacer ese agujero. Podrían encontrar una versión antigua de Apache y comprobar si es vulnerable a un exploit específico.

Paso 5: Explotación (El "Hackeo")

Esta es la parte en la que la gente piensa cuando oye "Penetration Testing". El tester intenta obtener acceso. Fundamentalmente, un pentester profesional hace esto con cuidado. No quieren borrar tus datos; sólo quieren demostrar que podrían haberlo hecho.

Paso 6: Post-Explotación y Movimiento Lateral

Una vez dentro, el tester pregunta: "¿A dónde puedo ir desde aquí?" Intentan moverse de un servidor web a una base de datos, o de una cuenta de desarrollo a una cuenta de producción. Esto revela el verdadero riesgo de la vulnerabilidad.

Paso 7: Informes y Remediación

Recibes un informe. Un buen informe no sólo dice "Tienes el bug X". Dice:

• Qué es el bug.
• Cómo lo encontraron (para que puedas reproducirlo).
• El nivel de riesgo (Bajo, Medio, Alto, Crítico).
• Exactamente cómo solucionarlo.

Midiendo el Éxito de tu Programa de Penetration Testing

¿Cómo sabes si tu inversión en Penetration Testing está funcionando realmente? No puedes simplemente contar el número de bugs; de hecho, encontrar más bugs en las primeras pruebas es una señal de éxito, significa que estás encontrando los puntos ciegos.

Indicadores Clave de Rendimiento (KPIs) para la Seguridad

Para realizar un seguimiento del progreso, observa estas métricas:

• Tiempo Medio de Reparación (MTTR): ¿Cuánto tiempo transcurre desde el momento en que se informa de un error crítico hasta el momento en que se soluciona? Si tarda tres meses, tu proceso está roto.
• Densidad de Vulnerabilidades: ¿Estás viendo el mismo tipo de errores (por ejemplo, SQL injection) en cada prueba? Si es así, tienes un problema de formación, no un problema de pruebas.
• Porcentaje de "Críticos" Encontrados por Escáneres vs. Pentesters: Si los pentesters están encontrando todos los críticos y los escáneres no encuentran nada, tus escáneres están mal configurados o son insuficientes.
• Crecimiento de la Superficie de Ataque: ¿Está creciendo tu número de activos expuestos más rápido que tu capacidad para protegerlos?

Pasando de "Reactivo" a "Proactivo"

Un programa exitoso mueve la aguja de "Encontrar errores" a "Prevenir errores". Cuando empiezas a ver un patrón, por ejemplo, cada nueva API tiene un fallo de autenticación roto, no te limitas a arreglar la API. Creas una nueva biblioteca de autenticación que todo desarrollador debe usar. Has convertido un hallazgo de Penetration Test en una mejora sistémica.

Penetrify: Cerrando la Brecha Entre las Pruebas y la Reparación

Muchas empresas tienen problemas con el Penetration Testing porque es demasiado caro (contratar a una empresa de renombre para una prueba manual) o demasiado superficial (usar un escáner básico). Aquí es donde Penetrify encaja.

Penetrify cierra esa brecha al proporcionar una plataforma nativa de la nube que combina la velocidad de la automatización con la profundidad de la evaluación profesional.

Por qué Penetrify es Diferente

La mayoría de las herramientas están construidas para una red local. Penetrify está construido para la nube. Entiende los matices de las VPC, los roles de IAM y las arquitecturas serverless.

En lugar de un informe estático que se encuentra en un PDF en el escritorio de alguien, Penetrify te ayuda a:

• Escalar las Pruebas: Ya sea que tengas un entorno o cien, puedes implementar pruebas en todos ellos simultáneamente.
• Integrar Flujos de Trabajo: Los resultados no se quedan solo en un informe; pueden alimentar directamente tu SIEM o sistema de tickets (como Jira), para que los desarrolladores puedan ver la solución en su flujo de trabajo existente.
• Reducir la Sobrecarga: No necesitas configurar hardware complejo en las instalaciones para realizar estas pruebas. Todo se gestiona en la nube, lo que significa que puedes empezar a probar hoy mismo, no el mes que viene.

Al utilizar una plataforma que se especializa en seguridad nativa de la nube, dejas de adivinar dónde están tus puntos ciegos y empiezas a eliminarlos activamente.

FAQ: Preguntas Comunes Sobre el Penetration Testing en la Nube

P: ¿El Penetration Testing no va a bloquear mi entorno de producción?

Es un temor común, pero el Penetration Testing profesional está diseñado para no ser destructivo. Los pentesters utilizan cargas útiles "seguras" para demostrar que existe una vulnerabilidad sin llegar a bloquear el servicio. Sin embargo, siempre es una buena idea probar en un entorno de pruebas que refleje la producción lo más fielmente posible. Si debes probar en producción, hazlo fuera de las horas punta y vigila de cerca tus herramientas de monitorización.

P: Mi proveedor de la nube (AWS/Azure/GCP) dice que ellos se encargan de la seguridad. ¿Por qué necesito esto?

Ellos se encargan de la seguridad de la infraestructura. Se aseguran de que nadie pueda entrar en el centro de datos y robar un disco duro. Se aseguran de que el hipervisor sea seguro. Pero no saben si has dejado tus claves de API en un repositorio público de GitHub o si tu aplicación tiene un fallo de cross-site scripting (XSS). Tú eres responsable de la "Seguridad EN la Nube".

P: ¿Con qué frecuencia debo hacer esto en realidad?

Si eres una pequeña empresa con un sitio estático, tal vez una vez al año sea suficiente. Pero si eres una empresa de mercado medio o una empresa que publica código a diario, deberías estar haciendo alguna forma de prueba constantemente. Una mezcla de escaneos automatizados diarios y Penetration Tests trimestrales en profundidad es un equilibrio saludable para la mayoría.

P: ¿No puedo simplemente usar una herramienta de código abierto para esto?

Puedes hacerlo, y muchos lo hacen. Herramientas como OWASP ZAP o Metasploit son fantásticas. Pero recuerda: una herramienta no es una prueba. Una herramienta te dice que un puerto está abierto. Un pentester te dice que el puerto abierto le permite acceder a tu base de datos de clientes. Las herramientas de código abierto son geniales para que tus desarrolladores las utilicen durante las compilaciones, pero no son un sustituto de una evaluación de seguridad integral.

P: ¿Cuál es la diferencia entre una prueba de "Caja Negra" y una prueba de "Caja Blanca"?

• Black Box: El tester no tiene ningún conocimiento previo de tu sistema. Empiezan desde cero, como un atacante real. Esto es genial para probar tu perímetro externo.
• White Box: El tester tiene acceso a la documentación, los diagramas de arquitectura y, a veces, al código fuente. Esto es mucho más eficiente porque no pierden tiempo "adivinando" y pueden encontrar fallos lógicos profundamente arraigados mucho más rápido.
• Grey Box: Una mezcla de ambos. Podrían tener una cuenta de usuario estándar pero sin acceso administrativo.

Conclusiones Finales: Tu Lista de Verificación de Seguridad en la Nube

Si te sientes abrumado, empieza con estos cinco pasos prácticos. No intentes arreglarlo todo de golpe, solo empieza a cerrar los mayores puntos ciegos.

1. Audite sus activos públicos: Utilice una herramienta para encontrar cada IP pública, bucket y subdominio que posea. Si encuentra algo que no reconoce, ciérrelo o asegúrelo inmediatamente.
2. Aplique el principio del mínimo privilegio: Revise sus roles de IAM. Encuentre cualquier rol con permisos AdministratorAccess o * e intente reducirlos a solo lo que el usuario realmente necesita.
3. Configure alertas centralizadas: Asegúrese de que sus registros no solo se almacenen, sino que también se supervisen. Configure al menos una alerta "crítica" para cosas como llamadas API no autorizadas o múltiples intentos fallidos de inicio de sesión.
4. Vaya más allá del escáner: Programe un Penetration Test dirigido a su activo más sensible. No solo busque CVEs; pídale al tester que encuentre una "cadena de ataque" que conduzca a sus datos.
5. Construya un ciclo: Integre una plataforma como Penetrify para hacer de la seguridad un proceso continuo en lugar de un evento anual.

La nube ofrece una agilidad increíble, pero esa agilidad puede convertirse fácilmente en una responsabilidad si pierde de vista su superficie de ataque. El objetivo no es ser "inhackeable", nada lo es. El objetivo es ser un objetivo difícil. Al buscar activamente sus propios puntos ciegos, hace que sea exponencialmente más difícil para un atacante encontrar una manera de entrar.

Deje de adivinar sobre su postura de seguridad. Empiece a probar.