Introducción
La seguridad juega un papel importante en el proceso de diseño de arquitectura empresarial. Las políticas de seguridad varían entre organizaciones, y se requieren diferentes patrones de implementación para cumplir con esos requisitos y restricciones. En esta publicación intentaré abordar algunas de las restricciones de seguridad más comunes y sugerir patrones de implementación para satisfacerlas.
Esto no es en modo alguno una lista exhaustiva de todos los requisitos de seguridad disponibles ni de los patrones de arquitectura de seguridad.
Esta publicación se centrará en patrones de arquitectura para exponer recursos asegurados de ArcGIS Enterprise a clientes externos, es decir, sistemas con el requisito de ser accedidos fuera de la red interna de la organización, a través de una DMZ, por ejemplo, para soportar el acceso de trabajadores en campo sin una VPN.
Hay consideraciones adicionales que forman parte de la decisión sobre qué patrón usar, que esta publicación no cubrirá, como cuántos recursos, por ejemplo hardware, licencias y personal, serán necesarios para cada patrón.
Para simplificar y centrarse en el aspecto de seguridad del patrón arquitectónico, todas las arquitecturas en esta publicación no son altamente disponibles, pero cada una puede ajustarse a una arquitectura altamente disponible sin cambiar el patrón.
DMZ Reverse Proxy
Comencemos con el patrón más común para sistemas ArcGIS Enterprise expuestos externamente, usando un reverse proxy en la DMZ.
Figura 1 - DMZ Reverse Proxy
En este patrón, todos los componentes de ArcGIS Enterprise están alojados en la red interna, detrás del firewall, y un reverse proxy (esto puede ser un reverse proxy comercial, como F5 o NetScaler, un reverse proxy open-source como Nginx o HAProxy, o un segundo conjunto de ArcGIS Web Adaptors), se despliega en la DMZ y pasa las solicitudes externas a ArcGIS Enterprise.
El portal ArcGIS Enterprise soporta solo un DNS para la URL pública del portal (la URL del contexto web), y para soportar acceso externo, debe usarse un nombre DNS resoluble externamente para la URL del contexto web del portal, por ejemplo https://gis.company.com/portal.
En la mayoría de los casos, el patrón anterior incluirá la implementación de un Sistema Dividido de Nombres de Dominio (Split DNS), es decir, las solicitudes internas al DNS de ArcGIS Enterprise (por ejemplo gis.company.com) se resolverán a la IP del equipo interno del web adaptor, por lo que los usuarios internos permanecerán detrás del firewall, y las solicitudes externas al DNS de ArcGIS Enterprise se resolverán a la IP del reverse proxy en la DMZ.
Usar un Firewall para Aplicaciones Web (WAF) delante del reverse proxy en la DMZ es una buena práctica de seguridad, ya que añade controles adicionales. Esri mantiene un documento (se requiere inicio de sesión organizacional) en https://trust.arcgis.com con una lista de endpoints que pueden filtrarse con seguridad para denegar acceso externo a recursos potencialmente sensibles en su sitio ArcGIS Enterprise.
Restricciones Especiales de Seguridad
No Acceso No Autenticado a la Red Interna
En un sistema federado ArcGIS Enterprise, el portal es responsable por la autenticación y autorización del usuario. En el patrón anterior, cuando un usuario hace una solicitud a ArcGIS Enterprise, primero se verifica si la solicitud al recurso asegurado (por ejemplo servicio) contiene información válida de autenticación y si no es así, ArcGIS Enterprise devolverá una respuesta redirigiendo al cliente para autenticarse con el proveedor de identidad configurado, por ejemplo SAML u OpenID Connect.
En la arquitectura anterior, una solicitud no autenticada desde un cliente externo pasa desde el reverse proxy en la DMZ a un web adaptor interno y desde el web adaptor al portal o servidor ArcGIS Enterprise antes que ArcGIS Enterprise devuelva una respuesta redirigiendo al cliente.
Algunas políticas de seguridad prohíben acceso no autenticado a la zona intranet y por lo tanto esta arquitectura no cumple con esa restricción.
No Acceso HTTPS / Solo se Permite Acceso a la Base de Datos desde la DMZ a la Red Interna
La mayoría de las políticas de seguridad permiten acceso entrante desde la DMZ hacia la red interna pero pueden limitar el tipo permitido por protocolos o puertos. Ejemplos serían no permitir acceso HTTPS (Hypertext Transfer Protocol Secure) desde DMZ hacia intranet o permitir solo acceso a base datos vía puertos personalizados.
En la arquitectura anterior el reverse proxy en la DMZ pasa las solicitudes a ArcGIS Enterprise usando HTTPS vía puerto 443 lo cual no cumple con esta restricción.
No Acceso Entrante desde la DMZ a la Red Interna
En algunos casos las políticas prohíben cualquier tipo acceso entrante desde DMZ hacia red interna y solo permiten conexiones no persistentes desde intranet hacia DMZ.
Patrones de Arquitectura de Seguridad
Consideremos los siguientes patrones arquitectónicos de seguridad y revisemos cómo cada patrón aborda algunas o todas las restricciones revisadas anteriormente.
DMZ ArcGIS Enterprise Portal y Servicios Registrados
Figura 2 - ArcGIS Enterprise Portal Proxy
<\/span><\/P> <\/DIV>En la figura 2 arriba, hay un portal ArcGIS Enterprise en la DMZ, y un servidor ArcGIS Enterprise en la red interna. El servidor independiente interno no está federado con el portal – los servicios se publican directamente en el servidor independiente, configurado como seguro en el servidor usando una cuenta de aplicación (cuenta de aplicación incorporada de ArcGIS Enterprise server o cuenta de servicio Active Directory / LDAP), y luego se agregan al portal como elementos desde la web con credenciales almacenadas. Cuando un servicio seguro de ArcGIS Enterprise server está registrado en el portal con credenciales almacenadas, el portal crea una URL proxy para ese servicio, y todas las solicitudes a ese servicio pasarán por el portal antes de ser reenviadas al servidor independiente interno. El portal ArcGIS Enterprise también permite definir límite de tasa y referidores específicos que pueden acceder al servicio.<\/P>Usar el patrón anterior cumple con la restricción de no permitir acceso no autenticado a la red interna, ya que todas las solicitudes externas deben pasar por el portal en la DMZ, que primero autentica y autoriza al usuario, y solo entonces realiza una solicitud al servicio en la red interna. Tenga en cuenta que dado que todas las solicitudes del portal al servidor se realizan usando las credenciales almacenadas, se pierde la capacidad de seguimiento del editor.<\/P>La arquitectura en este patrón puede elaborarse para incluir un sistema federado orientado internamente de ArcGIS Enterprise con portal, servidor anfitrión y servidor(es) federados, como se muestra en la figura 3.<\/P> <\/P>Figura 3 - ArcGIS Enterprise Portal Proxy Elaborado<\/H3> <\/P>
<\/span><\/P>Geodatabase Replicada Interna<\/H2> <\/P>Las políticas de seguridad de algunas organizaciones no permiten acceso HTTPS desde la DMZ a la intranet, y solo permiten acceso a bases de datos, usualmente a través de puertos no predeterminados, y en muchos casos tampoco permiten acceso externo a una base de datos primaria de producción, requiriendo el uso de una base de datos separada.<\/P>En la figura 4 abajo, ArcGIS Enterprise está desplegado en la DMZ, y se usa una geodatabase empresarial replicada interna como fuente de datos registrada para el servidor de mapas. Se puede usar replicación geodatabase Esri o replicación RDBMS.<\/P> <\/P>Figura 4 - Replicación de Base de Datos<\/H3> <\/P>
<\/span><\/P> <\/DIV>La figura 5 abajo presenta una arquitectura elaborada que incluye un sistema ArcGIS Enterprise orientado internamente en la red interna y un sistema ArcGIS Enterprise orientado externamente en la DMZ.<\/P> <\/P>Figura 5 - Replicación de Base de Datos Elaborada<\/H3> <\/P>
<\/span><\/P> <\/DIV>Publicación y Colaboración del Servicio<\/H2> <\/P>Finalmente, para aquellos que no permiten ningún acceso entrante desde la DMZ a la intranet, la figura 6 abajo muestra un ArcGIS Enterprise orientado externamente en la DMZ, y un ArcGIS Enterprise orientado internamente en la intranet, con:<\/P>Servicios publicados al sistema ArcGIS Enterprise DMZ como capas alojadas, y tareas automatizadas ejecutándose según un horario (por ejemplo nocturno o semanal) para sobrescribir los datos alojados con datos actualizados del sistema interno ArcGIS Enterprise<\/LI>Las capas temáticas se comparten por copia desde el sistema interno ArcGIS Enterprise al sistema ArcGIS Enterprise DMZ mediante colaboración distribuida con edición compartida bidireccional (introducido en la versión 10.9)<\/LI><\/OL> <\/P>Figura 6 - Publicación y Colaboración del Servicio<\/H3> <\/P>
<\/span><\/P> <\/DIV>Restringir Acceso a Aplicaciones Externas a ArcGIS Enterprise<\/H1> <\/P>En algunos casos, las organizaciones usan ArcGIS Enterprise para soportar aplicaciones externas integradoras y quieren restringir el acceso a aplicaciones externas filtrando solicitudes externas, permitiendo solicitudes solo desde una lista específica o rango de IPs, o desde dominios específicos.<\/P> <\/P>Proxy ArcGIS Online<\/H2> <\/P>Similar al patrón DMZ ArcGIS Enterprise Portal and Registered Services (figura 2 arriba), ArcGIS Online también actúa como proxy cuando registras servicios seguros desde un servidor independiente ArcGIS Enterprise o desde un sistema federado ArcGIS Enterprise. En la figura 7 abajo, los servicios desde un sistema interno ArcGIS Enterprise están registrados en ArcGIS Online con credenciales almacenadas; ArcGIS Online puede acceder a los servicios vía el proxy inverso DMZ, y el proxy inverso está configurado para permitir solicitudes solo desde el dominio ArcGIS Online, bloqueando solicitudes desde cualquier otra fuente. La aplicación web o móvil del sistema integrador puede registrarse con ArcGIS Online usando OAuth 2.0 e Identidad ArcGIS, así solo usuarios autenticados y autorizados pueden acceder a los servicios registrados. Dado que ArcGIS Online accederá a los servicios usando las credenciales almacenadas, el seguimiento del editor no funcionará. Similar al portal, puedes definir límite de tasa y referidores específicos que pueden acceder a los servicios.<\/P> <\/P>Figura 7 - ArcGIS Online y Servicios Registrados<\/H3> <\/P>
<\/span><\/P> <\/P>Proxy del Servidor<\/H2> <\/P>Otra opción sería usar un sitio servidor independiente ArcGIS Enterprise y un proxy del servidor para acceder a servicios seguros desde una aplicación web integradora.<\/P>En la figura 8 abajo, los clientes web app del sistema integrador están configurados para enviar solicitudes GIS a un proxy alojado en el servidor aplicación del sistema integrador. El servidor aplicación integrador es responsable de asegurar el acceso al proxy, es decir permitir solo usuarios autenticados por la app acceder al proxy, y proteger (encriptar) las credenciales del servidor ArcGIS Enterprise. El proxy maneja la seguridad del token del servidor ArcGIS Enterprise en nombre del cliente, usando una cuenta incorporada del servidor o una cuenta servicio Active Directory / LDAP, y envía la solicitud al sitio servidor independiente interno ArcGIS Enterprise vía el proxy inverso DMZ. El proxy inverso está configurado para permitir solicitudes solo desde IPs (lista o rango) del(los) servidor(es) app integrador(es), bloqueando solicitudes desde cualquier otra fuente.<\/P> <\/P>Figura 8 - Proxy Servidor App Web Integrador<\/H3> <\/P>
<\/span><\/P> <\/P>
.png)
