Recientemente llegó una pregunta de un cliente …
«En una reunión hoy, uno de los miembros de nuestra junta con algunos antecedentes cibernéticos preguntó sobre las medidas de seguridad para nuestro sitio web. Sostuvo que WordPress es más pirateable que Drupal y quería saber qué medidas se habían tomado para asegurar el sitio, dado que [nuestra organización] es un objetivo obvio. Dije que usted es un experto en seguridad e hizo de la seguridad del nuevo sitio un foco durante su diseño..«
«Estoy seguro de que recibiré preguntas de seguimiento sobre esto. ¿Podría darme un resumen de cómo su equipo ha manejado la seguridad para el nuevo sitio, qué medidas de protección existen, qué tipo de monitoreo se realiza para detectar/frustrar los intentos de piratería, y así sucesivamente? De ninguna manera soy un experto en esta área; un poco de información suya nos ayudaría a responder a las preguntas inevitables a seguir.«
Esta fue nuestra respuesta…
Creo que sería útil poner las cosas en contexto. WordPress funciona en más de la mitad de los sitios web del mundo, aproximadamente 75 millones. Drupal, por otro lado, solo opera alrededor de 1 millón de sitios web. Dado el mayor número de sitios web con tecnología de WordPress, habrá un número inherentemente mayor de sitios web pirateados de WordPress. Pero, si sigue los porcentajes, WordPress no necesariamente tiene una mayor tasa de piratería.
Además, es importante recordar que tanto WordPress como Drupal son sitios web impulsados por la comunidad. Por lo tanto, si se descubre una vulnerabilidad, entonces la comunidad de desarrolladores se encargará del problema. Al igual que hay 80 veces más sitios web de WordPress que Drupal, hay muchos más desarrolladores preocupados por mantener WordPress seguro. WordPress tiene un mayor ejército de soldados que ayudan a protegerlo y defenderlo. Dicho esto, WordPress es un objetivo más grande, por lo que es más probable que los piratas informáticos intenten piratear WordPress que Drupal.
Hay una aplicación llamada CVE que monitorea y mide las vulnerabilidades de seguridad. Ha rastreado 287 vulnerabilidades para WordPress y 177 para Drupal. Como puede ver en los resultados de CVE, el miembro de su junta está en lo correcto, Drupal tiene menos vulnerabilidades que WordPress.
Lo que Drupal hace que WordPress no hace es la contenedorización. Con Drupal, puede limitar más fácilmente el daño que cualquier rol de usuario tiene con respecto al alcance y el acceso. Sin embargo, WordPress tiene complementos que emularán lo que Drupal hace fuera de la caja. Pero también debemos recordar que si un hacker obtiene acceso de administrador, sistema o root, lo más probable es que tenga acceso a todo de todos modos. La contenedorización da casi una falsa sensación de seguridad.
También es importante darse cuenta de que, si bien las personas reconocen que WordPress puede ser un poco menos seguro que Drupal, de todos modos prefieren WordPress porque proporciona una experiencia de usuario mucho más agradable para los administradores de contenido y es menos costoso de construir y mantener. La gente elige WordPress sobre Drupal a pesar de la desventaja de seguridad inherente.
Cuando observa el núcleo, es decir, el núcleo de WordPress frente al núcleo de Drupal, ambos son bastante seguros. Donde se encuentran las vulnerabilidades y dónde entran los hackers se pueden clasificar en dos categorías principales:
El error humano sería cuando las personas caen en ataques de phishing. No importa si estamos hablando de Drupal o WordPress o Gmail, ninguno de ellos es seguro si el usuario permite que su nombre de usuario y contraseña lleguen a manos de piratas informáticos. Por lo tanto, su organización necesita mantener una cultura de seguridad.
Si bien la seguridad de Drupal para los módulos de Drupal parece ser generalmente más estricta que la seguridad de WordPress para los complementos de WordPress, el verdadero problema está en la elección, selección y configuración de esos módulos y complementos. Honestamente, creo que los módulos que estábamos usando en el sitio web anterior de Drupal eran más riesgosos que los complementos que seleccionamos en el sitio web actual de WordPress.
LO MÁS RELEVANTE: Si bien ningún sitio web en el planeta es absolutamente seguro, el sitio web tiene múltiples capas de seguridad, monitoreo y protección, incluidos Cloudflare, New Relic y múltiples capas de socket seguro (SSL).
Estos son los pasos adicionales que hemos tomado para asegurar el sitio web:
Arquitectura:
La arquitectura ha sido diseñada para que no haya acceso directo a la aplicación o al servidor de la base de datos. En lugar de alojar todo en un solo servidor o, lo que es peor, un servidor compartido con otros sitios web, el sitio web sigue una arquitectura de microservicios.
En el frente, tenemos Cloudflare para servir contenido HTML, por lo que aprovechamos su capa para filtrar la dirección IP maliciosa identificada y bloquear los intentos de piratería comunes. Para servir archivos, imágenes y activos en general, tenemos Amazon CloudFront. Detrás de Cloudflare se encuentra el servidor de caché, que actúa como un proxy para el servidor de aplicaciones. La base de datos vive en un servidor separado. El servidor de aplicaciones (donde vive WordPress) también está en un servidor separado.
El servidor de aplicaciones, caché y base de datos no son visibles y están completamente cerrados, por lo que solo Cloudflare puede ver el servidor de caché.
Si un visitante intenta obtener acceso a esos servidores individuales, no podrá hacerlo. Solo hemos permitido el acceso a estos servidores a través de un tercer servidor que sigue estrictas políticas de autenticación de seguridad a través de LDAP y autenticación de 2 factores.
Los medios audiovisuales y el contenido estático se alojan en Amazon CloudFront con copias en todo el mundo, por lo que se sirve desde el centro de datos más conveniente.
El acceso SSH y el acceso a través de cualquier puerto están restringidos a direcciones IP específicas.
Seguridad y actualizaciones de WordPress:
Monitoreo: Tenemos monitores configurados para los servidores, por lo que podemos verificar el estado en cualquier momento y recibir notificaciones a Slack si algo no funciona.
Análisis de malware: ejecutamos un análisis semanal automático de malware en el servidor.
Recuperación de desastres:
Incluso si somos súper seguros, siempre existe un riesgo, y necesitamos una forma de revertir el sitio en caso de un intento de piratería exitoso: