Qué cubre una auditoría de seguridad de Drupal
Una auditoría de seguridad de Drupal es una revisión puntual y con límite de tiempo de una plataforma Drupal frente a clases conocidas de riesgo de seguridad: control de acceso, estado de dependencias, configuración, código, infraestructura y protección perimetral. Produce hallazgos clasificados y un plan de remediación priorizado.
Una auditoría no hace segura una plataforma, y ningún conjunto de hallazgos es completo. Informa de lo que una revisión definida, ejecutada con un alcance acordado y con los accesos proporcionados, pudo establecer en la fecha en que se realizó. El trabajo de seguridad es una práctica continua; la auditoría es la medición que indica por dónde empezar.
El alcance cubre dos capas en un mismo compromiso: lo que reside dentro de Drupal (roles, permisos, dependencias, código, sesiones) y lo que lo rodea (cabeceras, secretos, protección perimetral, registro de actividad, separación de entornos). Las líneas de alcance se fijan en la definición del alcance en lugar de quedar implícitas, lo que implica acordar qué sitios, qué idiomas, qué entornos, qué URL y recorridos de muestra, y qué accesos se necesitan. El presupuesto compra una profundidad de revisión, y esa profundidad se establece antes de comenzar el trabajo.
Los hallazgos se clasifican como Muy altos, Altos, Medios o Informativos, por lo que la remediación se secuencia por riesgo en lugar de priorizarse desde una lista plana. No hay deliberadamente un nivel Bajo: una comprobación que caería ahí es o Media o no merece la pena ejecutarla. Cada recomendación incluye una estimación de esfuerzo, de modo que la remediación pueda presupuestarse y dividirse entre lo que se corrige internamente y lo que se subcontrata.
La auditoría es un diagnóstico, y una decisión separada de la remediación. Los hallazgos son tuyos independientemente de quién los implemente.
Han Confiado en Metadrop
Desde la fabricación y los productos químicos especializados hasta ONG humanitarias, asociaciones profesionales y universidades, organizaciones sujetas al RGPD, WCAG y NIS2 en más de 50 países han confiado en Metadrop para trabajos de seguridad, control de acceso y cumplimiento normativo en Drupal.
Lo que dicen los clientes
Los propietarios de plataformas describen qué cambió una vez que se midió la exposición a la seguridad en lugar de asumirla.
Cuándo una auditoría de seguridad de Drupal es el siguiente paso adecuado
- Ya se ha producido un incidente de seguridad, una intrusión, un defacement, un abuso de spam-relay o una fuga de credenciales, y la pregunta es qué más está expuesto.
- Una revisión de cumplimiento salió mal, o está programada la primera: una auditoría ENS, una revisión de preparación NIS2, una evaluación de protección de datos GDPR, una revisión interna de seguridad de TI.
- Un cliente empresarial envió un cuestionario de seguridad y las respuestas deben evidenciarse en lugar de afirmarse.
- Un anexo de licitación solicita una línea base de seguridad. La contratación pública y de la UE suele puntuar la gobernanza de seguridad documentada, y una auditoría con calificación es el artefacto que la responde.
- La plataforma fue heredada, asumida de un proveedor anterior o construida por personas que ya no están, sin una línea base de seguridad documentada ni registro de lo que se endureció.
- Una agencia o integrador de sistemas necesita una lectura independiente de una plataforma de la que ha asumido la responsabilidad, antes de comprometer un presupuesto de remediación. El informe va a quien lo encargue.
- El núcleo o una dependencia ha quedado sin soporte, o el acumulado de actualizaciones ha crecido más allá de lo que nadie está dispuesto a estimar.
- La plataforma contiene datos personales a gran escala: registros de seguidores, contenido relacionado con pacientes, áreas de miembros, formularios de solicitud, donde la exposición de esos datos es el riesgo que se gestiona.
- Una plataforma interna está dentro del alcance junto con el sitio público, una intranet o área de miembros donde todo el valor reside en que la persona equivocada no pueda ver lo que no debe.
La plataforma de un fabricante de electrodomésticos fue asumida de un proveedor anterior y auditada según criterios de seguridad, rendimiento, funcionalidad y accesibilidad. Los hallazgos definieron un plan de acción urgente, y se implementó una CDN y un WAF.
Una auditoría de seguridad y una prueba de penetración responden a preguntas distintas
Una auditoría de seguridad trabaja desde dentro con acceso concedido. Lee la configuración, el modelo de roles y permisos, el árbol de dependencias, el código personalizado, las cabeceras y la configuración de la infraestructura, y luego informa de qué está mal y cuánto costaría arreglarlo. Una prueba de penetración trabaja desde fuera sin ese acceso: intenta explotar la plataforma como lo haría un atacante e informa de qué fue realmente accesible.
Ambas son complementarias. Una auditoría encuentra clases de debilidad a las que una prueba de penetración puede no llegar nunca, y una prueba de penetración demuestra la accesibilidad que una auditoría solo puede inferir.
Metadrop no realiza pruebas de penetración internamente. Cuando una plataforma lo necesita, se encarga a una empresa externa cualificada, un acuerdo elegido por imparcialidad, ya que las pruebas ofensivas tienen más peso cuando no las realiza el equipo que construyó o mantiene la plataforma. La parte de Metadrop es definir el alcance de la prueba de penetración, coordinarla y convertir sus hallazgos en trabajo de remediación priorizado y estimado junto con los hallazgos de la propia auditoría, en un solo plan en lugar de dos.
| Auditoría de seguridad | Prueba de penetración | |
|---|---|---|
| La pregunta que responde | ¿Qué está mal configurado, desactualizado o con exceso de permisos en esta plataforma? | ¿Qué podría alcanzar realmente un atacante desde fuera? |
| El acceso que necesita | Acceso concedido a la configuración, el código y la infraestructura | Sin acceso privilegiado; funciona como lo haría un atacante |
| Lo que produce | Hallazgos clasificados con una estimación de esfuerzo para cada recomendación | Evidencia de qué fue accesible y cómo |
| Quién la realiza en un proyecto de Metadrop | Metadrop, internamente | Una empresa externa cualificada, con el alcance definido y coordinada por Metadrop |
| Cuándo es el primer paso adecuado | No hay una línea base de seguridad documentada, o un cuestionario, licitación o revisión de cumplimiento impulsa la revisión | Las debilidades visibles se han corregido y la accesibilidad es la pregunta abierta |
El escaneo automatizado de vulnerabilidades es una tercera cosa distinta: continuo, económico y bueno en la detección de CVEs conocidos. Se ejecuta como parte del primer paso de la auditoría, y la revisión manual que sigue cubre el juicio que un escáner no puede hacer.
Control de acceso, roles y permisos
El modelo de roles y permisos se lee como un todo, y no permiso a permiso: qué roles existen, a qué puede acceder realmente cada uno y dónde un permiso otorga más de lo que sugiere el nombre del rol. El principio de mínimo privilegio se contrasta con la realidad, lo que saca a la luz roles equivalentes a administrador en manos de personas que no los necesitan, permisos acumulados durante años de solicitudes puntuales y cuentas aún activas de personas que ya no están.
El acceso a nivel de nodo, campo y archivo se revisa allí donde la plataforma restringe el contenido en lugar de publicarlo todo: gestión de archivos privados, visibilidad del contenido no publicado y si una URL directa elude la lista que se suponía que debía controlarlo. Los entornos multilingües y multisitio reciben especial atención, porque las reglas de acceso que se cumplen en un sitio o en un idioma a menudo no se cumplen en todos. Las áreas autenticadas y editoriales también están dentro del alcance, ya que en una intranet, un área de miembros o el back office el modelo de acceso es el modelo de seguridad.
La plataforma de una ONG humanitaria internacional utiliza controles de roles y permisos basados en condiciones que otorgan acceso de forma dinámica según condiciones definidas, en lugar de hacerlo solo mediante roles estáticos.
Postura del núcleo, los módulos y las dependencias
Las versiones del núcleo de Drupal y de los módulos contribuidos se contrastan con los avisos de seguridad vigentes y con su estado de soporte. Una versión del núcleo sin soporte se notifica como un hallazgo de Muy Alto, porque ninguna medida de menor prioridad merece la pena mientras persista. Se revisan tanto el árbol de dependencias de PHP como el de JavaScript, no solo los de Drupal: paquetes de Composer, librerías incorporadas de forma transitiva y paquetes de npm utilizados en la compilación. La exposición de la cadena de suministro constituye una categoría propia, ya que un paquete comprometido en la cadena de herramientas de compilación llega a producción sin que nadie toque el código de la aplicación.
Los módulos abandonados y sin mantenimiento se señalan junto con la ruta de sustitución o eliminación, porque un módulo sin mantenimiento es una decisión de seguridad y no solo deuda técnica. La revisión cubre el proceso de actualización, no solo el estado de la misma: si los parches están programados, quién es el responsable, si existe un entorno de ensayo para validar una versión de seguridad y cuánto tarda actualmente un aviso crítico en llegar a producción. Los ingenieros de Metadrop han publicado sobre el compromiso de la cadena de suministro de npm y sobre por qué la mayoría de las plataformas Drupal no quedaron expuestas, aplicando el mismo razonamiento sobre el árbol de dependencias que emplea esta verificación.
Manejo de entradas, subida de archivos y código personalizado
El código personalizado y de contribución se revisa según los estándares de seguridad de OWASP y de Drupal, trabajando a partir de las categorías que aparecen con frecuencia en las plataformas en producción, en lugar de una enumeración genérica de las diez principales. Los hallazgos a nivel de código que se repiten son manejo inseguro de archivos, inyección de cabeceras mediante entradas no validadas, procesamiento de entradas XML sin ajustes de parser endurecidos, controladores que exponen datos sin comprobar el acceso y salida en bruto que evade el escape de Twig.
Las rutas de subida de archivos se revisan de principio a fin: extensiones permitidas, validación MIME, dónde se almacenan los archivos, si el servidor web puede ejecutar algo en ese directorio y si los archivos privados se sirven a través de la capa de acceso de Drupal según lo previsto. Las superficies de formularios y API, es decir, formularios web, endpoints REST y JSON:API y cualquier ruta personalizada, se revisan en cuanto a autenticación, autorización y limitación de velocidad. Las integraciones de terceros se tratan como una superficie de ataque: cómo llegan las credenciales a ellas, qué datos salen y qué ocurre cuando el extremo remoto devuelve algo inesperado.
Sesiones, autenticación y política de cuentas
La política de contraseñas y cuentas se comprueba según la configuración, no según lo supuesto: aplicación de longitud y complejidad, control de inundación en inicios de sesión fallidos y si la enumeración de usuarios es posible a través de los flujos de inicio de sesión y restablecimiento de contraseña. La cobertura de autenticación multifactor se revisa para cuentas privilegiadas, incluyendo si se puede eludir mediante una ruta de inicio de sesión alternativa. El inicio de sesión único (SSO) y el inicio de sesión federado, SAML u OIDC, se revisan para la asignación de roles, la validación de aserciones y qué ocurre con el acceso cuando alguien se elimina en el sistema upstream.
El manejo de sesiones cubre las banderas de cookies, la duración de la sesión y si una sesión sobrevive a un cambio de privilegios o a un restablecimiento de contraseña. Luego está la propia superficie administrativa: quién puede acceder a /admin y /user/login desde dónde, y si esa accesibilidad es una decisión deliberada o un valor predeterminado heredado.
Encabezados de seguridad y política del lado del navegador
Los encabezados de respuesta se leen tal como se sirven realmente, por entorno y por sitio, porque el valor configurado y el valor entregado no siempre son los mismos cuando hay un proxy o CDN en el camino. El conjunto verificado incluye Content-Security-Policy, Strict-Transport-Security, X-Content-Type-Options, X-Frame-Options o frame-ancestors, Referrer-Policy y Permissions-Policy.
La CSP se evalúa como una política funcional, no como una casilla de verificación: si está en modo de solo informe o de aplicación, cuánto se abre mediante unsafe-inline y si alguien está leyendo el flujo de informes. La propiedad del encabezado es un hallazgo por derecho propio, ya que los encabezados configurados en tres lugares a la vez (módulo de Drupal, servidor web, CDN) es la forma en que una política deja de aplicarse silenciosamente, por lo que la auditoría informa dónde debería vivir cada encabezado en esta plataforma. La divulgación de información a través de encabezados y salida de errores se cubre en la misma pasada: banners de versión, trazas de pila y salida de depuración dejada habilitada en un entorno de producción.
Los ingenieros de Metadrop han publicado sobre cómo mejorar los encabezados HTTP de un sitio de Drupal con un analizador de encabezados público, incluido el conjunto de encabezados de seguridad, utilizando el mismo método que esta verificación.
Manejo de secretos, credenciales y claves
Los secretos en el control de versiones se buscan a lo largo de todo el historial, no solo en la copia de trabajo actual: claves de API, claves privadas, credenciales de bases de datos y tokens que se hayan confirmado en algún momento y nunca se hayan rotado. La revisión también establece dónde residen los secretos en tiempo de ejecución, que pueden ser variables de entorno, un gestor de secretos o un archivo de configuración legible por más personas de las previstas, y si las credenciales de producción son accesibles desde un entorno de desarrollo.
La práctica de rotación también forma parte de esto: si se rota algo alguna vez y cuál es el procedimiento cuando alguien con acceso se va. También lo es la proliferación de cuentas de servicio, es decir, credenciales de integración con un alcance más amplio del necesario para la integración y cuentas compartidas que nadie posee. También se verifica la conectividad cifrada para el acceso administrativo y de despliegue, incluido si alguna ruta a producción sigue sin cifrar.
Tráfico de bots, abuso y protección en el borde
La carga de bots y rastreadores se mide antes de mitigarse, porque la proporción de trabajo en el origen que no es humano determina si la conclusión es un problema de seguridad, un problema de coste o ambos. La protección en el borde se revisa según la configuración existente: si hay un WAF, qué conjuntos de reglas están habilitados, si las reglas están en modo de bloqueo o de registro, y si alguien lee el registro. La limitación de velocidad y la postura ante DDoS en el borde se analizan junto con lo que hace el origen cuando el borde se omite con una solicitud de IP directa.
Los controles de spam y abuso en formularios públicos, es decir, CAPTCHA o equivalente, campos honeypot y límites de envío, se comprueban para ver si siguen funcionando, en lugar de si están instalados. La exposición a relleno de credenciales y enumeración en los puntos finales de inicio de sesión, registro y restablecimiento de contraseña se examina en la misma pasada. El tráfico de rastreadores y scraping de IA también forma parte del panorama, ya que ha crecido hasta representar una parte sustancial de la carga del origen y se gestiona en el borde, no en el código de la aplicación.
Metadrop ha publicado un análisis sobre el impacto del tráfico de bots en los sitios web y cómo mitigarlo, que es el marco que utiliza esta comprobación.
La plataforma de un fabricante de alimentos sin gluten completó una ronda de refuerzo de seguridad tras una revisión de seguridad: una política de seguridad de contenido con informes, cabeceras de seguridad consolidadas, un modo CAPTCHA empresarial y claves privadas y credenciales eliminadas del repositorio de código. La plataforma de un grupo químico multinacional, inestable y pagando por tráfico de bots maliciosos, se movió detrás de la seguridad perimetral de la CDN con un firewall de aplicaciones web y mitigación de DDoS, reduciendo los picos de tráfico fraudulento en aproximadamente un 90%. Esa colaboración también incluyó una auditoría de cumplimiento de cookies del RGPD y desplegó su plan de acción en los sitios del grupo.
Registro, monitorización y señales de estado
Qué se registra, a dónde va y cuánto tiempo se conserva es la primera pregunta, porque un incidente que nadie puede reconstruir es un incidente que nadie puede notificar, y los plazos de notificación son contractuales en los compromisos del sector público y de la UE. El registro de bases de datos en una plataforma de alto tráfico se revisa como una decisión de arquitectura, ya que un pipeline de registros centralizado es el patrón sostenible una vez que crece el volumen.
La alerta se lee para saber qué condiciones generan realmente una alerta, quién la recibe y si se dispara algo antes de que un visitante o un cliente informe del problema. El informe de estado de Drupal se trata como una señal de seguridad operativa, y las advertencias ignoradas durante el tiempo suficiente como para volverse invisibles son con frecuencia los hallazgos más rápidos de la auditoría. El rastro de auditoría para acciones privilegiadas cierra la revisión: quién cambió un permiso, publicó un nodo o alteró una configuración, y si ese registro sobrevive a un despliegue.
Los ingenieros de Metadrop han publicado sobre la gestión de los requisitos del informe de estado de Drupal y sobre la ampliación del sistema de registro de Drupal, ambas partes habituales de esta revisión.
Separación de entornos, copias de seguridad y restauración probada
La separación de desarrollo, staging y producción se verifica para comprobar un aislamiento que se cumple en la práctica, no solo sobre el papel: bases de datos compartidas, datos de producción copiados en un entorno de desarrollo sin anonimizar y entornos de staging accesibles e indexables desde internet. La estrategia de copias de seguridad cubre qué se respalda, con qué frecuencia, dónde se almacena, si está cifrada y si se guarda en un lugar al que un atacante con acceso a producción no pudiera llegar también.
La restauración se comprueba como práctica, no como ajuste: si se ha realizado alguna vez una restauración, cuánto tiempo llevó y qué demostró realmente el último simulacro. Una copia de seguridad que nadie ha restaurado es una suposición. El acceso al pipeline de despliegue forma parte del mismo panorama: quién puede desplegar, si los despliegues son revisables y reversibles, y si el análisis de seguridad se ejecuta en el pipeline antes de que el código llegue a producción.
La postura de la infraestructura y el nivel de alojamiento se evalúa, no se adquiere. Si el resultado es que la plataforma ha superado su plan o su proveedor, consulte Alojamiento Drupal.
Asociación de los hallazgos con ENS, NIS2, GDPR e ISO 27001
Los hallazgos técnicos por sí solos no responden a una cuestión de cumplimiento, por lo que la auditoría también puede ofrecer un análisis de deficiencias que asocia cada hallazgo con el requisito al que afecta, dentro del marco normativo al que se está sujeto. Esto proporciona la traducción técnica de un requisito normativo: qué control no cumple actualmente la plataforma y qué trabajo lo subsanaría. No llega a constituir una opinión legal, una certificación ni una declaración de que la plataforma cumple la normativa, ya que esa determinación corresponde al propio auditor o asesor jurídico.
Los hallazgos relativos al GDPR son aquellos que afectan a la exposición de datos personales a través del control de acceso, la gestión de archivos privados, la retención de registros, los flujos de datos con terceros y la implementación del consentimiento. Una plataforma que filtre datos personales puede aumentar el riesgo de incumplimiento para las organizaciones sujetas a estos requisitos, y la determinación de lo que eso significa para una organización concreta corresponde a su propio asesor jurídico.
La NIS2 eleva las expectativas en torno a la gestión de riesgos, la gestión de incidentes y la seguridad de la cadena de suministro para las entidades dentro de su ámbito de aplicación, y los hallazgos de la auditoría en materia de dependencias, registro de actividad y preparación ante incidentes son los que se asocian a ella. El entregable se presenta como preparado para los requisitos de la NIS2, nunca como cumplimiento de los mismos, y determinar si la NIS2 es aplicable a la organización es una cuestión de alcance que corresponde al departamento jurídico o de cumplimiento.
Los hallazgos relativos a ISO 27001 e ISO 27002 pueden expresarse en relación con las familias de controles con las que ya trabaja una organización certificada o en proceso de certificación, de modo que el resultado de la auditoría se integre en un SGSI existente en lugar de coexistir de forma paralela. Las categorías de OWASP agrupan los hallazgos de código y configuración, que es el vocabulario que ya utilizan la mayoría de los equipos de seguridad empresarial y los cuestionarios.
El ENS es un segmento específico, no la oferta estándar. Un Plan de Seguridad de la Información formal con una matriz completa de asignación de controles ENS es un entregable propio del sector público y de licitaciones de la UE, cuyo alcance se define cuando el contrato lo exige. Para un comprador comercial, la auditoría es más ligera: hallazgos, remediación priorizada y una lectura de deficiencias, sin matriz de asignación de controles.
Metadrop audita desde una base certificada externamente. Esa base es una certificación ENS auditada externamente (Esquema Nacional de Seguridad, Categoría Media, según el RD 311/2022) que abarca más de 64 medidas de seguridad distintas en gestión de riesgos, control de acceso y respuesta ante incidentes, dentro de un sistema de gestión de calidad ISO 9001. El ENS está deliberadamente alineado con el GDPR, las directivas NIS y NIS2, ISO 27001/27002 y las guías de ENISA. Esta es la propia certificación y madurez de procesos de Metadrop, por lo que es lo que fundamenta la auditoría, más que una afirmación sobre lo que logrará cualquier plataforma de un cliente. El ciclo interno de gestión de riesgos de Metadrop —identificar, evaluar, mitigar y monitorizar— refleja la metodología de Gestión de Riesgos de Seguridad de la Información (ITSRM) de la Comisión Europea, y un miembro del equipo posee la certificación ITSRM de ENISA, la Agencia de la UE para la Ciberseguridad.
Los riesgos se presentan de forma que un responsable no técnico pueda actuar sobre ellos. El dossier de hallazgos contiene el detalle técnico, mientras que la presentación expone en términos empresariales qué significa cada hallazgo de prioridad Muy Alta y Alta, porque las personas que aprueban el presupuesto de remediación no leerán el código.
Cómo se realiza la auditoría
El encargo se desarrolla en cinco fases, las dos últimas se contratan por separado.
Alcance de la definición
Acuerda los sitios, entornos, URLs de muestra y recorridos, la profundidad por área de comprobación, y los accesos y herramientas necesarios.Ejecución con límite de tiempo
Un pase automático ejecuta cada comprobación que se ha automatizado, y el tiempo del revisor se dedica entonces a lo que la automatización no puede decidir, es decir, el criterio, el contexto y el muestreo manual. Aquí se capturan las mediciones de referencia de las que depende toda comparación posterior.Presentación
Presenta los hallazgos y las recomendaciones priorizadas a los miembros técnicos y no técnicos del grupo de compra, en un lenguaje que ambos puedan utilizar.Remediación, solo cuando se contrate
Como proyecto, o como trabajo evolutivo dentro de un contrato de mantenimiento de Drupal, siguiendo un flujo de trabajo documentado de triaje a verificación, registrando y triando cada hallazgo, priorizando contigo, parcheando y probando en el entorno de preparación, desplegando y verificando, y luego informando de lo resuelto.
Bucle de consultoría, solo cuando se haya contratado.
Vuelve a medir los indicadores acordados frente a la línea base de la auditoría con una cadencia acordada. Cada indicador rastreado se remonta a una verificación que estableció su línea base.
Qué recibes
El entregable es un informe de hallazgos con cada uno clasificado y vinculado a su evidencia, una lista de recomendaciones priorizadas que incluye una estimación de esfuerzo por elemento para poder presupuestar la corrección y, cuando el análisis de brechas está en el alcance, el mapeo de los hallazgos al marco al que te debes.
| Criticidad | Qué significa la clasificación |
|---|---|
| Muy alta | Un bloqueo; mientras persista, no se puede cumplir el objetivo de la auditoría. |
| Alta | Impacto significativo, corregir en la misma ronda de trabajo. |
| Media | Vale la pena corregir, agruparla. |
| Informativa | Registra un estado o una decisión deliberada; se notifica, nunca se actúa sobre ella. |
No existe un nivel Bajo, por diseño.
Cómo se gestiona tu plataforma durante la revisión: acceso de solo lectura siempre que sea suficiente, credenciales transmitidas mediante un gestor de secretos en lugar de correo electrónico, cualquier prueba que modifique la configuración se ejecuta en un entorno que no sea de producción, y los hallazgos se comparten a través de un canal con control de acceso, ya que una lista de hallazgos es en sí misma material sensible. El estándar propio de Metadrop también se aplica al compromiso: autenticación multifactor en el acceso privilegiado, dispositivos cifrados, acceso con privilegios mínimos a los sistemas de los clientes, residencia de datos en la UE y un proceso documentado de respuesta a incidentes con un compromiso de notificación definido.
Las versiones de Drupal cubiertas van de Drupal 7 a Drupal 11. En una versión sin soporte, la auditoría informa de la exposición y de la ruta de actualización juntas, porque los parches dejan de estar disponibles antes que el riesgo. Los clientes que ya tienen un contrato de mantenimiento reciben una verificación automatizada mensual sin coste adicional, y los aspectos destacados que merecen acción se convierten en tareas; una auditoría contratada es la versión en profundidad, revisada manualmente, de ello.
En las plataformas con mantenimiento, los controles permanentes que Metadrop establece y mantiene incluyen firewalls de aplicaciones web, mitigación de bots y spam, aplicación de políticas de contraseñas, control de acceso a nivel de nodo, secretos en un gestor de claves, cabeceras de seguridad y políticas de seguridad de contenido, que es la práctica que respalda las recomendaciones de la auditoría. Detrás del compromiso están las credenciales permanentes de Metadrop: más de 15 años de especialización en Drupal, estado de Socio Certificado Silver de Drupal, certificación ENS y un historial de cumplimiento de GDPR, WCAG y NIS2 en plataformas que dan servicio a más de 50 países y más de 30 idiomas.
La seguridad es un tema dentro de la familia de auditorías y se puede combinar en un solo compromiso con accesibilidad, SEO técnico, UX/UI o GEO & AEO: un solo alcance, una sola presentación, una sola lista priorizada.
Preguntas frecuentes sobre las auditorías de seguridad de Drupal
¿Qué es una auditoría de seguridad de Drupal?
Una auditoría de seguridad de Drupal es una revisión puntual de una plataforma Drupal frente a clases conocidas de riesgo de seguridad: control de acceso y permisos, estado del núcleo y de las dependencias, código personalizado, cabeceras de seguridad, gestión de secretos, registro de actividad y protección perimetral. Se entrega como hallazgos clasificados con un plan de remediación priorizado. Se realiza con acceso concedido a la plataforma, su configuración y su infraestructura, lo que permite informar de las causas en lugar de los síntomas. También está delimitada en el tiempo, ya que el presupuesto acordado fija la profundidad de la revisión y la muestra, ambos establecidos antes de comenzar el trabajo.
¿Cuál es la diferencia entre una auditoría de seguridad y una prueba de penetración?
Una auditoría de seguridad revisa la plataforma desde dentro con acceso concedido, mientras que una prueba de penetración la ataca desde fuera sin ninguno. La auditoría informa de qué está mal configurado, desactualizado o con exceso de permisos; la prueba de penetración informa de qué fue capaz de alcanzar un atacante realmente. Responden a preguntas diferentes y normalmente se contratan en secuencia, primero la auditoría, porque corregir lo que ya es visible cuesta menos que descubrirlo bajo la simulación de un ataque. En un proyecto de Metadrop, la auditoría se realiza internamente, y cualquier prueba de penetración se encarga a una empresa externa cualificada para garantizar la imparcialidad, siendo Metadrop quien define su alcance, la coordina e integra sus hallazgos en el mismo plan de remediación priorizado.
¿Detectará una auditoría de seguridad de Drupal todas las vulnerabilidades de nuestra plataforma?
Una auditoría de seguridad de Drupal no puede afirmar que su conjunto de hallazgos sea completo, y esta no lo hace. Informa de lo que una revisión definida, contra un alcance y una muestra acordados, pudo establecer en la fecha en que se ejecutó. Lo que pretende es encontrar primero la exposición con mayor probabilidad e impacto, clasificarla y asignarle una estimación de esfuerzo para corregirla, de modo que el presupuesto de remediación vaya donde está el riesgo. El planteamiento honesto es que la auditoría reduce la exposición desconocida y proporciona una base de referencia, y que mantenerla baja es una práctica constante de parcheo, monitoreo y revisión, más que una compra única.
¿Con qué frecuencia debería auditarse la seguridad de una plataforma Drupal?
Una auditoría de seguridad completa cada 6 o 12 meses es la cadencia habitual para una plataforma Drupal de misión crítica, con una adicional activada por un evento en lugar de por el calendario. Los eventos que deberían activarla son una actualización de versión importante, una migración o cambio de plataforma, un traspaso de proveedor, una integración nueva significativa, un incidente de seguridad y una revisión de cumplimiento o presentación de licitación. Entre auditorías, el trabajo relevante es continuo en lugar de periódico: supervisión de dependencias y vulnerabilidades, aplicación rápida de parches de seguridad y revisión de registros de borde.
¿Cuánto tiempo lleva una auditoría de seguridad de Drupal y afecta al sitio en producción?
Una auditoría de seguridad de Drupal se limita al presupuesto acordado, que es lo que determina su duración: un alcance centrado en un único sitio suele durar días, mientras que una gran infraestructura multisitio o multilingüe puede llevar semanas. La revisión es no intrusiva por diseño, con acceso de solo lectura siempre que sea suficiente, una muestra acordada de URL y recorridos en producción, y cualquier cambio de configuración se ejecuta en un entorno de no producción. Lo que más la acorta es tener preparados los accesos, los entornos y la lista de muestra al definir el alcance; esperar por las credenciales es el retraso más común.
¿Cuánto cuesta una auditoría de seguridad de Drupal?
Una auditoría de seguridad de Drupal se presupuesta por proyecto, porque el tiempo es el producto: el presupuesto fija la profundidad de la revisión y el alcance se acuerda antes de comenzar cualquier trabajo. Los factores que determinan el coste son el número de sitios, idiomas y entornos, el tamaño y la antigüedad del código personalizado, cuántas integraciones están incluidas, si se incluyen la infraestructura y las capas periféricas, y si un análisis de brechas de cumplimiento forma parte del entregable. Las tarifas no se publican. Una conversación para definir el alcance es lo que genera una cifra, y es la misma conversación que fija el alcance, de modo que el número y lo que incluye llegan juntos.
¿Se aplica NIS2 a nuestra página web?
La aplicación de la NIS2 es una cuestión sobre tu organización, no sobre tu sitio web. La directiva delimita las entidades por sector, tamaño y criticidad, y su transposición a la legislación nacional difiere según el estado miembro, por lo que esa determinación corresponde a tu departamento legal o de cumplimiento normativo, no a un proveedor técnico. Cuando una organización está dentro del ámbito de aplicación, las obligaciones que afectan a una plataforma pública se refieren a la gestión de riesgos, la detección y notificación de incidentes y la seguridad de la cadena de suministro, que es donde las conclusiones de una auditoría sobre dependencias, registro de actividad y preparación ante incidentes resultan útiles como evidencia. La contribución de Metadrop es la traducción técnica: qué controles no cumple actualmente la plataforma y qué trabajo cerraría esa brecha, expresado como hallazgos preparados para los requisitos de la NIS2 y no como una declaración de cumplimiento.
Nuestro proveedor de alojamiento dice que se encarga de la seguridad, ¿entonces todavía necesitamos una auditoría?
La seguridad del alojamiento y la seguridad de las aplicaciones cubren aspectos distintos. Un proveedor asegura la infraestructura que opera, parcheando el sistema operativo, el perímetro de red y la capa de plataforma, y normalmente no revisa el modelo de roles y permisos, las versiones de los módulos contribuidos, el código personalizado, las cabeceras de seguridad ni los controles de abuso de formularios. Las carencias que esto suele destapar son el tráfico de bots y rastreadores que llega al origen porque no se configuraron reglas perimetrales para este sitio, una vulnerabilidad de módulo divulgada sin parche programado y secretos comprometidos en el repositorio, y ninguna de ellas la detecta la capa de alojamiento por ti. La división práctica se establece mejor por escrito: el informe de auditoría indica qué hallazgos pertenecen a la plataforma, cuáles al proveedor y cuáles a quien mantiene el código. Consulta Alojamiento Drupal para ver dónde se encuentra el límite de la infraestructura.