¿Es seguro usar una cuenta de AD para ejecutar un grupo de aplicaciones en IIS con el fin de proporcionar permisos de lectura / escritura SQL a una aplicación web?

0

He estado trabajando en una aplicación web de intranet que proporciona acceso de lectura / escritura basado en roles a una base de datos.

Se me ha pedido que configure la aplicación IIS para usar una cuenta de AD para el grupo de aplicaciones, a fin de proporcionar los permisos de la base de datos. La razón de esto es evitar el acceso de lectura / escritura a los usuarios individuales.

Me preocupa la posibilidad de que se agregue un código malicioso al servidor y de que luego tenga acceso a la base de datos en virtud del grupo de aplicaciones. ¿Es esta una preocupación valida? ¿Existen otros riesgos o inquietudes con este enfoque?

    
pregunta Beofett 20.03.2018 - 15:11
fuente

1 respuesta

1
  

Desde mi punto de vista, tu preocupación es válida. Y gestionando el acceso desde   su servidor web IIS a su base de datos de servidor SQL con tal   La configuración es un buen enfoque. También es cierto que si tu web   el servidor está comprometido por una ejecución de código malicioso ( source ),   el atacante podría aumentar los privilegios, recopilar credenciales, hacerse pasar por cualquier cuenta del grupo de aplicaciones de IIS y obtener acceso a su servidor SQL. Puedo sugerir las siguientes recomendaciones de seguridad específicas para aumentar la seguridad de su arquitectura:

Gestión del ciclo de vida de la cuenta de servicio:

  • Defina una rotación de la política de contraseñas para cambiar las contraseñas con frecuencia (algunas soluciones de Password Access Management pueden resolver este problema)
  • Usa una política de contraseña compleja
  • Para reducir la carga de trabajo de los puntos anteriores, use Cuentas de servicio administradas ( fuente ). Proporcionarán cuentas con contraseñas complejas y rotación automática
  • Respete el privilegio mínimo (como lo menciona @Jeroen) para cada uno de sus Grupos de aplicaciones y nunca otorgue privilegios de administrador completo o administrador de base de datos a una cuenta de servicio
  • Usar autenticación Kerberos (no activada por defecto). Esto requerirá varias configuraciones ( fuente ) y uso de SPN

Seguridad del servidor:

  • Habilite el registro avanzado de Windows y registro de PowerShell para detectar comportamientos extraños (como proceso nuevo, bloqueo de la aplicación, inicios de sesión fallidos, nuevo servicio, movimiento lateral ...)
  • Habilitar SQL Server logging
  • Habilitar registros de IIS (archivos de formato txt)
  • No almacene servidores front-end en la misma red o subred que sus servidores de sensibilidad (por ejemplo: servidores de base de datos, AD, PKI, ...) y use un firewall para filtrar solo el tráfico necesario (en su caso, el puerto usado por su instancia de SQL).
  • Cambie su servidor IIS al modo Core ( source ) para reducir su exposición superficial
  

Al final, no hay una solución "mágica" para resolver su problema, excepto siguiendo las mejores prácticas de seguridad básicas y avanzadas. Tener un recolector de registros (por ejemplo: SIEM) también será útil para aumentar la cobertura de seguridad de todos sus recursos de registro (firewall, Windows, Linux, Unix, enrutadores, IDS, IPS, ...).

    
respondido por el Michel de Crevoisier 21.03.2018 - 14:16
fuente

Lea otras preguntas en las etiquetas