Intro

Trabajando en proyectos en Dojo4 a menudo me sorprende ver cómo pequeños aumentos en la complejidad técnica se multiplican en importantes consumidores de atención y recursos. Por lo tanto, cuando los proyectos están comenzando, tendemos a favorecer una pila de hosting y aplicaciones simplificada que comparte muchas características comúnmente vistas en servicios de hosting compartidos. Esto incluye opciones como alojar la aplicación y la base de datos juntas, emplear un solo usuario de implementación en el sistema de hosting y un simple monitoreo de tiempo de actividad.

Recientemente, nuestro cliente de larga data, Inspire Commerce, desarrolló un nuevo plan de negocios que requiere que su aplicación cumpla con el estricto Payment Card Industry (PCI) Nivel 1 de cumplimiento de seguridad para procesar, transmitir y almacenar información de tarjetas de crédito. Muchos de los requisitos de seguridad detallados en el estándar de Data Security Standard (DSS) de PCI motivan un cambio significativo en el pensamiento desde la pila enfocada en la simplificación mencionada anteriormente. Esta publicación enumerará brevemente algunos de estos detalles y esbozará nuestras soluciones.

El PCI DSS se divide en 12 secciones que cubren todo, desde la configuración del firewall hasta las políticas de seguridad del personal. Repasaré algunas de las secciones relevantes para la pila de hosting.

1. Instalar y mantener una configuración de firewall para proteger los datos de los titulares de tarjetas

Esta es una sección bastante detallada del DSS que exige la instalación y configuración de servicios de firewall en todos los dispositivos de red, desde estaciones de trabajo, hasta routers, hasta servidores. Utilizando Amazon Web Services (AWS) Elastic Compute Cloud (EC2) como base de nuestra pila de hosting, muchos de estos dispositivos de red están abstraídos de nuestra vista o control. Afortunadamente, AWS es en sí mismo PCI Nivel 1 compatible dejando muchos de estos detalles a los ingenieros de Amazon.

Sin embargo, los firewalls para los nodos EC2 sí requieren alguna consideración. Los nodos EC2 están protegidos por un firewall implementado en la capa de hipervisor y configurado por los Grupos de Seguridad de AWS. Nuestro Grupo de Seguridad básico tiene todos los puertos denegando paquetes con la excepción de 22, 80 y 443 aceptando de todas las fuentes. Ejecutamos Ubuntu Linux en nuestros nodos y fuera de la caja tenemos el firewall de IP Tables configurado con una política abierta.

El PCI DSS se centra en el uso de firewalls para crear redes privadas seguras, o Zonas Desmilitarizadas (DMZ) para sistemas que alojan aplicaciones que procesan datos de tarjetas de pago. Los Grupos de Seguridad de AWS proporcionan un mecanismo útil para crear redes privadas seguras entre los diversos componentes de la pila de aplicaciones. Por ejemplo, al crear un grupo de seguridad WEB y un grupo de seguridad DB, y abrir el puerto de la base de datos en el grupo de seguridad DB solo a las fuentes del grupo de seguridad WEB, el firewall del hipervisor EC2 que se ejecuta en un servidor de base de datos solo permitirá el acceso a la base de datos desde los servidores web que se conectan en la interfaz de red privada interna.

Para redundancia, reflejamos la configuración del Grupo de Seguridad de AWS para el firewall del hipervisor EC2 con el servicio CloudPassage que puede gestionar el firewall IP Tables en la capa del sistema operativo de los sistemas que alojan componentes de la aplicación de procesamiento de tarjetas. CloudPassage organiza las políticas de firewall en Grupos de Servidores que son algo análogos a los Grupos de Seguridad de AWS. Otra gran característica de CloudPassage es el servicio GhostPorts. Configuramos la política del puerto ssh en CloudPassage para aceptar conexiones desde fuentes GhostPort. Para que una máquina cliente se convierta en una fuente GhostPort, un usuario en esa máquina debe autenticarse en el portal de CloudPassage, estar autorizado para abrir GhostPorts para un grupo de servidores y autenticarse con un llavero Yubikey registrado, o responder a un desafío SMS con un teléfono celular registrado. Tras una autenticación y autorización exitosas, CloudPassage configura IP Tables para aceptar conexiones desde la ip de origen de la máquina cliente. Esta es una forma conveniente, segura, temporal y auditable de gestionar el acceso a hosts sensibles.

2. No utilizar las configuraciones predeterminadas del proveedor para las contraseñas del sistema y otros parámetros de seguridad

Esta sección parecería bastante obvia. Un buen ejemplo de la importancia de cambiar la contraseña predeterminada del proveedor es la contraseña predeterminada del Splunk Universal Forwarder changeme.

Sin embargo, enterrado en esta sección hay un requisito de hosting algo no relacionado con el título de la sección. “2.2.1 Implementar solo una función principal por servidor para evitar que las funciones que requieren diferentes niveles de seguridad coexistan en el mismo servidor. (Por ejemplo, los servidores web, los servidores de bases de datos y el DNS deben implementarse en servidores separados)”.

Como se mencionó anteriormente, los grupos de seguridad de AWS hacen que la tarea de separar de manera segura los servicios como los servidores web y de bases de datos en hosts separados sea bastante sencilla.

5. Utilizar y actualizar regularmente el software o programas antivirus

ClamAV hace un trabajo rápido con este requisito en Ubuntu Linux.

8. Asignar un ID único a cada persona con acceso a la computadora

La intención de esta sección es facilitar la auditoría y la responsabilidad eliminando las cuentas de usuario compartidas. Dado que utilizamos un mecanismo de autenticación basado en claves para el acceso de shell seguro, hay tres preocupaciones principales para saber quién hizo qué. En primer lugar, es necesario evitar que el usuario pueda cambiar a otra cuenta de usuario con el comando su. Esto se logra fácilmente eliminando el permiso de ejecución en el binario su y modificar /etc/pam.d para evitar toda autorización su. En segundo lugar, asegúrese de que los archivos authorized_keys para todas las cuentas de usuario contengan solo una entrada. Finalmente, asegúrese de que todas las claves utilizadas para el acceso de shell seguro estén protegidas por contraseña y que haya una política en vigor para prohibir el intercambio de claves entre usuarios.

Ahora, el Demonio de Auditoría de Linux (AuditD) se puede usar para rastrear la actividad del sistema a usuarios específicos.

9. Restringir el acceso físico a los datos de los titulares de tarjetas

El título de esta sección es bastante autoexplicativo. Básicamente, esta sección cubre los temas de restringir el acceso físico al centro de datos a personal autorizado. Similar a la discusión sobre la configuración del firewall del dispositivo de red anterior, esto está cubierto por la certificación PCI Nivel 1 de AWS y los detalles se pueden dejar a Amazon.

10. Rastrear y monitorear todo el acceso a los recursos de red y los datos de los titulares de tarjetas

La motivación de esta sección es “prevenir, detectar o minimizar el impacto de un compromiso de datos”. Esto implica temas como el registro, la gestión de la integridad de los archivos y la detección de intrusiones. Nuestra estrategia comienza con el empleo de un servicio de registro para admitir la agregación de registros, la retención de registros, así como la búsqueda de registros de registro. Estamos utilizando la aplicación Splunk para esta funcionalidad. Configuramos una instancia EC2 para un servidor de registro e instalamos Splunk. Configuramos los Grupos de Seguridad de AWS y los ServerGroups de CloudPassage para el nuevo servidor que tiene el puerto de escucha de Splunk aceptando conexiones desde fuentes de servidores web y db en la interfaz de red privada. Luego configuramos el Splunk Universal Forwarder en los servidores web y db y configuramos los reenviadores para monitorear los registros de la aplicación, apache, mongodb, sys, audit y auth.

Para la monitorización de la integridad de los archivos y la detección de intrusiones, instalamos la aplicación OSSEC en todos nuestros servidores y agregamos todos los registros que OSSEC escribe a los reenviadores de Splunk.