Riesgo para los miembros del dominio en un dominio que se extiende a la DMZ

Voy a utilizar el ISC2 como referencia.

Hay 10 dominios generales que son el foco de la seguridad. Aquí hay una descripción general de ellos para referencia.

Discutiste mucho y para esta respuesta voy a intentar concentrarme en (3) que parece preocuparte más:

• Control de acceso
• Criptografía
• Arquitectura y diseño de seguridad

Dominios de seguridad

Antes de entrar en esto, los Dominios de Seguridad son amplios y se centran en muchos aspectos diferentes del dominio identificado. Estoy limitando mis puntos, y están generalizados. Las personas pueden identificar ampliamente el riesgo, pero es difícil saber cuán limitado es ese riesgo sin acceso al medio ambiente.

Control de acceso

Según su escenario, supongo que el RODC se utiliza para la autenticación y / o autorización. Si no, no sé por qué tienes uno sentado ahí afuera. Parece que tiene una buena comprensión de cómo configurar un DC de forma segura, por lo que diría que su mayor riesgo aquí implica los derechos que la Aplicación necesita / tiene para cumplir con sus obligaciones. Supongo que una cuenta de servicio bloqueada para esta aplicación debería ser suficiente. Verificaría con el propietario de la aplicación lo que necesitan para la aplicación

Criptografía

No se discutió específicamente, pero siempre sugiero (o se exige, dependiendo del escenario) que se use una comunicación segura. LDAPS, TLS, etc. deben ser comunes, y si tiene acceso externo a estos sistemas, siempre prefiero los certificados firmados por terceros a los certificados CA internos.

Arquitectura y diseño de seguridad

Esta es probablemente tu pregunta más grande. ¿Es lo que diseñaste una buena implementación? En resumen, lo que describiste está bien, incluso de manera estándar (parece que tengo muchas configuraciones similares).

Este tema es extremadamente amplio y puede hacer muchas preguntas al respecto:

• ¿Cuáles son sus prácticas de aprovisionamiento / desaprovisionamiento para administradores?
• ¿Qué usuarios accederán a la aplicación?
• ¿Se aseguran otros DC de la misma manera?
• Si comprometo un DC reconfigurado en una DMZ diferente, ¿puedo obtener acceso al RO en este?

Podría seguir. (En general, esta es la razón por la que trabajamos en ámbitos, porque las preguntas son infinitas).

Entonces, ¿cuál es la ruta de escalada más probable?

Por experiencia general, el compromiso externo suele ser:

• Error de desarrollo de aplicaciones (E.G SQL Injection)
• Error del servidor de aplicaciones (archivo .htaccess mal configurado E.G)
• Servicio expuesto en el firewall (E.G Telnet abierto a través del Firewall)

Si tiene una confianza razonable en su otro equipo para configurar sus sistemas, debe sentirse razonablemente seguro de que su DMZ está segura. La gran pregunta que debe considerar es: si mi DMZ está comprometida, ¿cuál es mi riesgo para la red interna?

Es probable que su RODC necesite volver al RWDC a través de un Firewall. ¿Qué sucede si una computadora que no es su RODC se conecta al RWDC? Podría ser una bandera roja.

Me preocuparía principalmente por lo que permiten los firewall (s) y cuáles son los privilegios de las cuentas utilizadas en la DMZ en las máquinas internas. La pregunta real es, en mi humilde opinión, qué podría pasar si un atacante pudiera romper la seguridad de una aplicación que se ejecuta en un servidor DMZ:

• ¿Permite el firewall conexiones desde ese servidor a la LAN interna?
• ¿Algún servidor interno (o máquina cliente que tenga recursos compartidos) acepta conexiones de uno de los usuarios utilizados en la DMZ?

Si los riesgos anteriores (DMZ - > zona interna) ya están cubiertos, puede considerar DMZ - > DMZ, es decir, si una aplicación en la DMZ está comprometida, esta cuenta puede hacer algo en otras aplicaciones desde el mismo servidor y qué ocurre con los otros servidores.

Sé que esos son solo consejos, pero es lo mejor que puedo sin más elementos en su configuración real, incluidos los pequeños detalles que se notan en paj28 en su comentario.