Auditoría de seguridad cloud (AWS, Azure, GCP)
Un pentesting cloud mide hasta dónde llega un atacante dentro de AWS, Microsoft Azure o Google Cloud cuando ya tiene una clave de acceso, una cuenta de usuario o la dirección de un almacenamiento que quedó abierto. Es el mismo trabajo que un pliego llama test de intrusión, aplicado a la capa que configuras tú: identidades, permisos, red, almacenamiento y registro de actividad.
Comprobamos quién puede acceder de verdad a qué: roles y políticas de IAM, reglas de cortafuegos, redes virtuales, permisos sobre buckets y contenedores de almacenamiento, secretos olvidados en las cadenas de CI/CD y debilidades de la identidad federada — Entra ID (antes Azure AD), inicio de sesión único y cuentas de servicio. Todo lo que sea alcanzable desde internet se revisa además por separado.
No te entregamos la lista de todas las desviaciones detectadas, sino un orden de trabajo: qué hay que cambiar esta semana y qué puede esperar a la próxima ventana de mantenimiento. El retest posterior a las correcciones va incluido en el precio.
Confían en nosotros
Qué resuelve una auditoría de seguridad cloud
AWS, Microsoft y Google protegen la infraestructura que explotan ellos. Cómo queda configurado tu entorno por dentro sigue siendo responsabilidad tuya: es el modelo de responsabilidad compartida, y esa mitad es justo la que auditamos — modelo de permisos, segmentación de red, ajustes de almacenamiento y trazas. Ahí empiezan casi todas las fugas de datos y casi todas las escaladas de privilegios.
Una revisión automatizada de configuración compara tus ajustes con las recomendaciones del fabricante. Es útil, pero no responde a la única pregunta que decide un presupuesto: ¿esa desviación es explotable de verdad y hasta dónde lleva? Eso lo verificamos a mano, con prueba de explotación.
Saber qué es explotable de verdad
Una alerta de cumplimiento no es una vulnerabilidad. Validamos cada desviación a mano y al informe solo llega lo que un atacante puede encadenar, con la ruta de ataque reconstruida.
Medir el alcance de una cuenta comprometida
Si mañana se filtra el token de alguien de desarrollo, ¿hasta dónde lleva? Partimos de un acceso con pocos privilegios y subimos: roles acumulados, políticas demasiado amplias y relaciones de confianza entre cuentas y suscripciones.
Ver la exposición real de la información
Buckets legibles sin autenticación, copias de seguridad olvidadas, instantáneas de bases de datos compartidas de más y secretos abandonados en variables de entorno o en el historial de un repositorio.
Comprobar si habrías visto el ataque
Nuestras acciones dejan rastro. Comparamos lo que registraron tus trazas de auditoría con lo que hicimos en realidad y te decimos qué pasó desapercibido.
El modelo de responsabilidad compartida: dónde acaba tu proveedor y dónde empiezas tú
Es la confusión más cara que vemos al cerrar un alcance cloud. Que tu proveedor declare conformidad con el ENS, publique informes SOC 2 o figure en el Catálogo de Productos y Servicios STIC (CPSTIC) del CCN acredita la seguridad de la plataforma del proveedor, no la de lo que tú despliegas encima. El bucket que alguien abrió «solo un momento» para una migración, el rol con permisos comodín que nadie se atrevió a recortar y la cuenta de servicio de un proyecto cerrado hace dos años son tuyos, y ninguna acreditación del proveedor los cubre.
El propio ENS lo dice para el caso cloud. La medida [op.nub.1] Protección de servicios en la nube del Anexo II del RD 311/2022 obliga, ya desde la categoría BÁSICA, a exigir garantías adicionales cuando el servicio contratado a un tercero no es conforme con el ENS, y entre esas garantías el texto enumera literalmente la «Auditoría de pruebas de penetración (pentesting)» en [op.nub.1.2 a)]. Dicho de otro modo: cuanto menos acreditado esté el servicio que contratas, más peso recae sobre la prueba técnica de tu lado del contrato.
En la práctica el trabajo se reparte en tres capas. La del proveedor —hipervisor, red física, centros de datos— no la tocamos ni tenemos derecho a tocarla. La tuya —identidades, permisos, redes virtuales, almacenamiento, claves, trazas— es la que auditamos entera. Y la intermedia —servicios gestionados que configuras tú pero opera el proveedor, como una base de datos gestionada o un clúster de Kubernetes operado por la plataforma— se reparte, y conviene escribir en el alcance de qué lado cae cada elemento antes de empezar.
Alcance
Qué revisamos en una auditoría cloud
Una auditoría cloud no se agota en la gestión de identidades. Según cómo esté montado tu entorno, el alcance cubre todos o parte de los ocho dominios siguientes; se cierra en la reunión de alcance y queda escrito en el presupuesto.
AWS, Azure, GCP y Microsoft 365
Los tres hiperescalares y sus servicios nativos. En muchas organizaciones españolas el cloud empieza por Microsoft 365 y Entra ID: lo incluimos en el alcance por defecto. Un entorno íntegramente en AWS o una base multicloud nos resultan igual de familiares.
IAM y privilegios excesivos
Quién tiene qué, dónde cede el mínimo privilegio y qué roles acumulan permisos que nunca debieron cruzarse. Las políticas genéricas, los roles de servicio olvidados y las claves de acceso sin rotación son la primera ruta de escalada que aparece.
Almacenamiento expuesto
S3, Blob Storage, Cloud Storage: permisos, cifrado, instantáneas y copias de seguridad. Los datos personales reciben un tratamiento aparte en el informe, porque una fuga activa el art. 33 del RGPD y la notificación a la AEPD en 72 horas.
Secretos en las cadenas de CI/CD
Claves de API, tokens de despliegue y credenciales de servicio en variables de pipeline, imágenes de contenedor, historial de repositorios y registros de compilación. Hoy es una de las vías de entrada más rentables para un atacante.
Contenedores y Kubernetes
EKS, AKS, GKE y clústeres autogestionados: RBAC, cuentas de servicio, políticas de admisión, escape de contenedor y acceso a la API del clúster desde un pod comprometido.
Segmentación de red
VPC y VNet, grupos de seguridad, reglas de cortafuegos, emparejamientos y enlaces híbridos hacia la red interna, en la práctica bastante más permisivos de lo que describe el esquema de arquitectura.
Servicios expuestos a internet
Puntos de entrada abiertos, entornos de preproducción olvidados, interfaces de administración alcanzables desde fuera y funciones serverless invocables sin autenticación.
Trazas y detección
Qué registran CloudTrail, Azure Monitor o Cloud Logging, qué dispara una alerta y si tu equipo —o el proveedor que te presta la detección— nota nuestras acciones mientras están ocurriendo.
Enfoques
Caja negra, caja gris y caja blanca
El enfoque decide lo que realmente compras: una prueba de caja negra mide tu exposición vista desde fuera; una de caja blanca mide la solidez de tu configuración. En cloud, donde casi todo el riesgo vive detrás de la autenticación, recomendamos caja gris en la gran mayoría de los proyectos. El enfoque se cierra en la reunión de alcance y se escribe en el presupuesto, porque determina directamente las jornadas que hay que prever.
Caja negra (black box)
Empezamos sin ningún acceso, como un atacante que acaba de fijarse en tu organización: inventario de dominios y recursos expuestos, buscadores de servicios, repositorios públicos, almacenamiento accesible sin autenticación y credenciales ya filtradas en circulación. Mide tu superficie de exposición real, pero deja a oscuras todo lo que ocurre tras el inicio de sesión.
Caja gris (grey box)
Nos entregas una cuenta o un rol con privilegios limitados, como el que tendría alguien de desarrollo o un proveedor externo. Partimos de ahí y buscamos hasta dónde se puede subir. Es lo que recomendamos en cloud: reproduce el escenario más frecuente —una credencial comprometida— y cubre en unos días lo que a una caja negra le costaría semanas.
Caja blanca (white box)
Acceso de lectura a la configuración, a las políticas de IAM, a las plantillas de infraestructura como código y, si procede, al código de las funciones. La cobertura es máxima y el informe se convierte en un plan de remediación directamente aplicable. Es el enfoque para antes de una puesta en producción, una migración o una auditoría de certificación.
Qué te obliga realmente en España (y qué no)
Conviene empezar por lo que todavía no está en vigor, porque es donde más se confunde el mercado. La NIS2 no está transpuesta en España. El Anteproyecto de Ley de Coordinación y Gobernanza de la Ciberseguridad pasó su primera lectura en el Consejo de Ministros el 14 de enero de 2025 y aún no ha entrado en las Cortes; el 9 de julio de 2026 la Comisión Europea llevó a España ante el Tribunal de Justicia de la Unión Europea por ese retraso, en el procedimiento INFR(2024)0270. Una auditoría que se te ofrezca «para cumplir la NIS2» se apoya, hoy, en una obligación que en España todavía no tiene ley que la desarrolle.
Lo que sí está en vigor son tres cosas distintas. El RDL 12/2018 y su reglamento de desarrollo, el RD 43/2021, que siguen aplicándose a los operadores de servicios esenciales y a los proveedores de servicios digitales designados. Y, sin necesidad de transposición alguna, el Reglamento de Ejecución (UE) 2024/2690, directamente aplicable desde su entrada en vigor, que afecta de lleno a este sector: fija los requisitos técnicos y metodológicos para los proveedores de servicios de computación en nube, de centros de datos, de redes de distribución de contenidos, de servicios gestionados y de servicios gestionados de seguridad, entre otros. Si tu empresa presta alguno de esos servicios, ese reglamento te obliga hoy, con España transpuesta o sin transponer.
Su Anexo dedica el punto 6.5, «Pruebas de seguridad», exactamente a este trabajo: exige una política de pruebas documentada, un alcance y una frecuencia decididos en función del riesgo, una metodología y unos resultados documentados, y la corrección de los hallazgos críticos. No pide un sello ni un proveedor de una lista concreta; pide evidencia de que las pruebas se hacen, con qué criterio y qué ocurrió después. El informe y el retest están escritos para servir de esa evidencia.
Si trabajas con el sector público español, el marco es el ENS (RD 311/2022). Su art. 31 somete los sistemas de categoría MEDIA y ALTA a una auditoría regular ordinaria al menos cada dos años, y su art. 38 separa los caminos: autoevaluación en categoría BÁSICA, certificación por una entidad acreditada en MEDIA y ALTA. Dentro del Anexo II, el refuerzo R6 de la medida [op.mon.3] incluye un subapartado cuyo título es literalmente «Pruebas de penetración» ([op.mon.3.r6.3]), exigible en categoría ALTA. Y, como decíamos arriba, [op.nub.1.2 a)] nombra la misma prueba ya desde BÁSICA cuando el servicio cloud de un tercero no es conforme con el ENS.
Otras dos obligaciones cruzan casi cualquier entorno cloud. El art. 32.1.d) del RGPD exige «un proceso de verificación, evaluación y valoración regulares de la eficacia de las medidas técnicas y organizativas para garantizar la seguridad del tratamiento»: una auditoría periódica con retest documentado es la forma más directa de acreditarlo ante la AEPD. Y el Reglamento (UE) 2022/2554 (DORA), aplicable desde el 17 de enero de 2025, impone a las entidades financieras un programa de pruebas de resiliencia operativa digital, con pruebas dirigidas por amenazas al menos cada tres años para las entidades que designe la autoridad competente (art. 26).
Ninguna de estas normas te obliga a contratar a un proveedor establecido en España ni inscrito en un registro nacional. Todas piden lo mismo: una metodología que se pueda revisar, un alcance justificado por el riesgo, resultados documentados y prueba de que los hallazgos críticos se corrigieron.
Última verificación del marco normativo citado: 12 de septiembre de 2026.
Alcance, autorización y las reglas de cada proveedor cloud
El alcance se cierra antes del presupuesto, no después. Listamos las cuentas de AWS, las suscripciones de Azure, los proyectos de GCP y los tenants de Microsoft 365 implicados, los servicios activos, los clústeres, los entornos excluidos de forma expresa y la ventana de intervención. Lo que no figura en el documento de alcance no se prueba; lo que figura, se prueba entero. Si a mitad del trabajo aparece un recurso que nadie había inventariado —y aparece casi siempre—, te lo decimos y decides tú si entra.
Un entorno cloud no se prueba solo con nuestras reglas: también con las del proveedor. AWS, Microsoft y Google publican cada uno su política de pruebas de intrusión. Buena parte de lo que se ejecuta contra recursos propios está permitido sin trámite previo; algunas categorías exigen aviso o declaración; y hay acciones prohibidas por mucho mandato que tengas, como la denegación de servicio o cualquier prueba dirigida a la infraestructura compartida o a recursos de otros clientes. Revisamos esas reglas para cada plataforma del alcance antes de empezar, preparamos la declaración cuando hace falta y dejamos escrito en el informe qué comprobaciones quedaron fuera por este motivo.
Todas nuestras pruebas se ejecutan con mandato escrito y dentro de un alcance definido en contrato. En España, acceder a un sistema de información sin la debida autorización es delito (art. 197 bis del Código Penal), y también lo es dañar datos o programas ajenos (art. 264 y siguientes). La autorización escrita de quien es titular del sistema es exactamente lo que separa nuestro trabajo de esos tipos penales, y por eso no se empieza sin ella. Si tu entorno lo gestiona un integrador o te llega en modo SaaS, hace falta además su autorización por escrito: te ayudamos a formalizarla durante el alcance.
En el mismo documento fijamos las reglas del ejercicio (rules of engagement): quién es el contacto técnico de guardia, por qué canal te avisamos de un hallazgo crítico sin esperar al informe, qué acciones se anuncian antes de ejecutarse —modificar una política, crear un rol, borrar un recurso— y qué se prueba en preproducción en lugar de en producción. La denegación de servicio y las acciones destructivas quedan excluidas por principio.
Metodología
Cómo trabajamos, paso a paso
Nos apoyamos en marcos y guías públicos en lugar de en un método propio imposible de verificar: PTES para la conducción del proyecto, la guía OWASP WSTG para las interfaces web y las API que exponen tus servicios cloud, los CIS Benchmarks de AWS, Azure y GCP como base de comparación de configuraciones y la matriz MITRE ATT&CK Cloud para nombrar las técnicas empleadas. Así tu equipo puede releer cada hallazgo sin tener que creernos. El detalle está en nuestras metodologías de testing y en cómo aplicamos las guías de OWASP.
La parte automatizada existe —inventario de recursos, recogida de configuración, detección de desviaciones—, pero sirve para encuadrar el trabajo manual, no para sustituirlo: ocupa la primera jornada; el resto lo hace a mano una persona del equipo de pentesting.
Alcance y autorización
Definimos contigo los objetivos, las cuentas y suscripciones implicadas, los recursos críticos y las acciones excluidas. Recibes un documento de alcance, un calendario y un presupuesto cerrado. El mandato escrito y, si hace falta, el aviso al proveedor cloud se resuelven en esta fase.
Reconocimiento y recogida de configuración
Inventario de lo expuesto desde internet y lectura de la configuración: políticas y roles de IAM, servicios activos, segmentación de red, ajustes de almacenamiento y trazas. Levantamos el mapa de los permisos reales, que siempre se aparta un poco del organigrama.
Explotación y movimiento lateral
Comprobamos qué desviaciones son explotables de verdad y hasta dónde llevan: escalada de privilegios, salto de una cuenta a otra, acceso a la información y rebote del cloud hacia la red interna. Cada hallazgo va respaldado por su prueba de explotación.
Informe y sesión de presentación de resultados
Recibes el informe redactado en español, con los hallazgos ordenados por criticidad, y después lo presentamos por videoconferencia a tu equipo técnico y a dirección. Las preguntas se resuelven en esa sesión, no por correo electrónico tres semanas más tarde.
Retest
Cuando hayas corregido, volvemos a probar las vulnerabilidades identificadas y emitimos un informe de verificación. Va incluido en el precio, sin coste adicional, dentro de los 90 días siguientes a la entrega del informe.
Entregables
Entregables: informe, presentación de resultados y retest
Un entregable de test de intrusión se dirige a dos públicos: quien corrige y quien decide el presupuesto. El nuestro está escrito para los dos, en español.
Resumen ejecutivo
Tres páginas sin jerga: nivel de riesgo global, qué hay que corregir primero y qué esfuerzo supone. Legible por un comité de dirección o por un cliente que te esté auditando.
Informe técnico detallado
Cada hallazgo con su criticidad (CVSS), la ruta de ataque reconstruida, las evidencias que la sostienen y la corrección concreta que hay que aplicar en AWS, Azure, GCP o Entra ID.
Plan de remediación priorizado
Los hallazgos ordenados por la pareja riesgo/esfuerzo, para que tu equipo sepa por dónde empezar el lunes en lugar de recibir cien desviaciones sin ningún orden.
Exportación a Jira o Azure DevOps
Los hallazgos en el formato que espera tu herramienta de seguimiento, para que entren directamente en tu ciclo de desarrollo.
Sesión de presentación de resultados
Una sesión con tu equipo de cloud y, si quieres, con dirección. Repasamos las rutas de ataque y respondemos a las preguntas en directo.
Retest incluido
Una contra-auditoría completa después de las correcciones, incluida en el precio y sin coste adicional, con un informe de verificación que puedes usar en tu expediente de cumplimiento o ante tu cliente.
Comparativa
¿Auditoría cloud o revisión automatizada de configuración?
Una revisión automatizada inventaria deprisa las desviaciones respecto a las recomendaciones del fabricante. Un test de intrusión demuestra cuál de esas desviaciones acaba en incidente y qué obtiene el atacante con ella. Son complementarias: sencillamente no responden a la misma pregunta.
| Criterio | Revisión automatizada de configuración | Auditoría de seguridad cloud |
|---|---|---|
| Objetivo | Detectar desviaciones de configuración respecto a las buenas prácticas. | Demostrar que una desviación es explotable y medir el impacto que tiene. |
| Método | Comprobaciones automáticas contra una configuración de referencia. | Prueba manual, encadenado de rutas de ataque y movimiento lateral. |
| Profundidad | Cobertura amplia, sin prueba de explotación. | Verificación dirigida, con prueba de explotación que lo respalda. |
| Falsos positivos | Abundantes: se señala cada desviación, sea alcanzable o no. | Descartados durante la prueba; al informe solo llega lo demostrado. |
| Entregable | Lista de desviaciones y recomendaciones genéricas. | Informe priorizado, plan de remediación y retest incluido. |
| Cadencia | Continua, integrada en la cadena de despliegue. | Puntual: en cada cambio relevante y al menos una vez al año. |
¿No tienes claro por cuál empezar? Un análisis de vulnerabilidades te da el mapa del terreno y la auditoría cloud entra después sobre lo más expuesto. Ver también pentesting de aplicaciones web y test de intrusión de infraestructura.
Testimonios
Lo que dicen nuestros clientes
¿Por qué confiarnos tu auditoría cloud?
Somos un proveedor europeo, una empresa establecida en la Unión Europea, y no tenemos ninguna acreditación expedida por un organismo público español. Preferimos escribirlo aquí antes que dejar que lo descubras más tarde. A cambio ponemos sobre la mesa tres compromisos verificables.
Certificaciones del equipo
Retest incluido, sin coste adicional
Después de tus correcciones volvemos a probar cada vulnerabilidad identificada y te entregamos un informe de verificación por escrito. Está incluido en el precio inicial, dentro de los 90 días siguientes a la entrega. Un informe que nadie vuelve a comprobar no demuestra nada.
Precios publicados
Las horquillas en euros y el número de jornadas están publicados antes de la primera llamada, no después de tres reuniones. Sabes lo que cuesta un proyecto cloud de cinco jornadas antes de escribirnos, y el presupuesto que sale de la reunión de alcance es cerrado.
Sabes quién prueba
Las personas asignadas a tu proyecto aparecen con nombre en el presupuesto, con sus certificaciones individuales (OSCP, OSWE, CISSP). Hablas con ellas durante la prueba, no con una capa intermedia de gestión.
Tratamiento de datos y soberanía
La pregunta sale en casi todos los alcances cloud en España y merece una respuesta clara. Auditamos tu tenant, no lo alojamos. Haxoris no es proveedor de infraestructura, ni distribuidor, ni integrador: no tenemos ningún interés en que te quedes en una plataforma o en otra, y ningún dato de tu producción pasa por una infraestructura que explotemos nosotros en tu lugar. La prueba se ejecuta desde nuestros equipos de auditoría, sobre los accesos que abres tú y que cierras tú.
Haxoris es una empresa establecida en la Unión Europea, y eso cambia el papeleo de forma muy concreta. El RGPD se aplica directamente a nuestro tratamiento: no hay transferencia internacional del capítulo V, no hacen falta cláusulas contractuales tipo, no hay que documentar una evaluación de impacto de las transferencias ni apoyarse en una decisión de adecuación revisable, y el material del proyecto no queda sometido a la jurisdicción de un tercer país ni a normas de acceso extraterritorial como la CLOUD Act estadounidense. Con un proveedor cuya matriz está fuera de la Unión, cada uno de esos puntos es un trámite —o un riesgo residual— que alguien de tu equipo jurídico tiene que resolver antes de firmar.
Los accesos que nos confías son nominativos, quedan limitados al alcance acordado y se revocan al terminar. El material recogido durante la prueba —capturas, extractos de configuración, evidencias de explotación— se conserva cifrado dentro de la Unión Europea, se trata bajo el RGPD y se destruye a tu petición o al vencimiento contractual. La relación de nuestros encargados del tratamiento te la entregamos antes de firmar, si la pides.
Si tu entorno tiene requisitos particulares de localización o de confidencialidad, dilo en la reunión de alcance: ajustamos el plazo de conservación de las evidencias, el canal de entrega del informe y el nivel de cifrado de los intercambios. El detalle de nuestros compromisos está en la página sobre Haxoris.
Qué no hacemos
Nombrar los límites es lo que hace creíble el resto. No certificamos. Haxoris no es entidad de certificación y no está acreditada por ENAC: no expedimos certificaciones de conformidad con el ENS, ni el Distintivo de Conformidad, ni certificados de ISO/IEC 27001. Esos documentos los emite un organismo de certificación acreditado; nuestro informe técnico es la evidencia que le presentas a ese organismo o a la entidad que te audite.
No realizamos TLPT. Las pruebas dirigidas por amenazas del art. 26 del Reglamento (UE) 2022/2554 (DORA) exigen proveedores que cumplan los requisitos del art. 27 del mismo reglamento y un marco supervisado por la autoridad competente. Un ejercicio de Red Team nuestro puede ser una buena preparación previa, pero ni lo sustituye ni lo prestamos.
No trabajamos con información clasificada. Tratar materia clasificada exige una habilitación de seguridad concedida por la Oficina Nacional de Seguridad, que no tenemos. Si el sistema que quieres auditar maneja información clasificada, ese alcance queda fuera y te lo decimos en la primera conversación, no en la factura.
No somos una empresa de seguridad privada. Prestamos servicios de seguridad informática; esta actividad no figura entre las reservadas del art. 5.1 de la Ley 5/2014 y no requiere autorización del Ministerio del Interior. Tampoco indagamos sobre personas concretas: el reconocimiento en fuentes abiertas que hacemos se limita a la superficie de exposición de la organización que nos contrata y al alcance pactado por escrito.
Y un último límite, este técnico antes que jurídico: no probamos la infraestructura del proveedor cloud ni los recursos de otros clientes. Esa capa no es tuya, no puedes autorizarla y ningún contrato firmado contigo nos daría derecho a tocarla.
Preguntas frecuentes
01 ¿Cuánto cuesta una auditoría de seguridad cloud?
El precio sigue al alcance: número de cuentas, suscripciones y proyectos, servicios activos, complejidad del modelo de permisos y presencia o no de contenedores. Un proyecto acotado a un solo proveedor arranca en torno a los 2.500 € (IVA no incluido); un entorno de producción repartido entre varias cuentas y varias plataformas se sitúa bastante por encima.
Las horquillas y la tarifa por jornada están publicadas: conoces el orden de magnitud antes de la primera llamada, y el presupuesto que sale de la reunión de alcance es cerrado. El retest está incluido en ese precio.
02 ¿Cuántas jornadas hay que prever?
Entre 5 y 15 jornadas en la gran mayoría de los proyectos cloud. Una cuenta única con una decena de servicios activos son 3 a 5 jornadas; un entorno multicuenta con Entra ID, clústeres de Kubernetes y cadenas de CI/CD pide más bien de 10 a 15. Cuenta dos o tres semanas de calendario entre el arranque y la sesión de presentación de resultados.
El número de jornadas se cierra en el alcance y figura en el presupuesto. No facturamos ninguna jornada adicional sin acuerdo previo por escrito.
03 ¿Caja negra o caja gris para un entorno cloud?
Caja gris, en la mayoría de los casos. Una prueba de caja negra mide tu exposición desde internet, que es útil saberlo, pero deja fuera todo lo que ocurre una vez que el atacante está dentro — y en cloud ahí es donde vive casi todo el riesgo: privilegios excesivos, relaciones de confianza entre cuentas y secretos accesibles desde una máquina de rebote.
En caja gris nos entregas una cuenta con privilegios limitados y las jornadas contratadas se dedican a avanzar en lugar de a descubrir. La caja blanca, con acceso de lectura a la configuración y a las plantillas de infraestructura como código, da la cobertura más completa: es la opción sensata antes de una puesta en producción o de una auditoría de certificación.
04 ¿Hay que avisar al proveedor cloud?
Depende de la plataforma y de las acciones previstas. AWS, Microsoft y Google publican cada uno su política de pruebas de intrusión: buena parte de lo que se ejecuta contra recursos propios está permitido sin trámite previo, algunas categorías exigen aviso o declaración, y otras acciones están prohibidas por mucho mandato que tengas, como la denegación de servicio o las pruebas dirigidas a la infraestructura compartida o a recursos de otros clientes.
Revisamos esas reglas para cada plataforma del alcance durante la fase de alcance, preparamos la declaración cuando hace falta y documentamos en el informe las comprobaciones que quedaron fuera por este motivo. Si tu entorno lo gestiona un integrador o te llega en modo SaaS, hace falta además su autorización por escrito.
05 ¿Sirve una auditoría cloud para el ENS o para la NIS2?
Para el ENS, el informe es insumo técnico de la auditoría regular del art. 31 del RD 311/2022 y cubre la prueba que el Anexo II nombra en [op.mon.3.r6.3] y en [op.nub.1.2 a)]. No sustituye a la certificación: esa la firma una entidad de certificación acreditada, y Haxoris no lo es.
Para la NIS2, en España todavía no hay ley de transposición. Lo que sí es directamente aplicable es el Reglamento de Ejecución (UE) 2024/2690, cuyo Anexo exige en el punto 6.5 una política de pruebas de seguridad documentada, con alcance y frecuencia basados en el riesgo, metodología y resultados documentados y corrección de los hallazgos críticos. El informe y el retest están pensados para servir de esa evidencia.
06 ¿Puede la auditoría afectar a la producción?
El riesgo nunca es cero y no vamos a decirte lo contrario; se gestiona. Excluimos por principio la denegación de servicio y las acciones destructivas, acordamos una ventana de intervención y un canal de aviso directo, y las manipulaciones sensibles —cambiar una política, crear un rol, borrar un recurso— se anuncian antes de ejecutarse o se repiten en preproducción.
Cualquier vulnerabilidad crítica te la comunicamos de inmediato, durante la prueba, sin esperar a la entrega del informe.
07 ¿Hace falta contratar a un proveedor establecido en España?
Para un test de intrusión encargado por una empresa privada sobre un entorno propio, no. Ninguna norma española exige que el proveedor esté establecido en España ni inscrito en un registro. Lo que sí cambia con el origen del proveedor es el papeleo de protección de datos: al estar establecidos en la Unión Europea, el RGPD se nos aplica directamente y no hay transferencia internacional que documentar.
Hay tres excepciones reales y conviene conocerlas: la certificación del ENS, que expiden entidades acreditadas por ENAC; el TLPT del art. 26 de DORA, reservado a proveedores que cumplen su art. 27; y cualquier trabajo con información clasificada, que exige habilitación de la Oficina Nacional de Seguridad. No prestamos ninguno de los tres, y lo decimos antes de que lo preguntes. Puedes ver cómo trabajamos en sobre Haxoris y qué dicen quienes ya nos han contratado en testimonios.
