Introdução
A segurança desempenha um papel importante no processo de design da arquitetura empresarial. As políticas de segurança variam entre organizações, e diferentes padrões de implantação são necessários para atender a esses requisitos e restrições. Neste post, tentarei abordar algumas das restrições de segurança mais comuns e sugerir padrões de implantação para satisfazê-las.
Esta não é, de forma alguma, uma lista exaustiva de todos os requisitos de segurança disponíveis e padrões de arquitetura de segurança.
Este post focará em padrões de arquitetura para expor recursos protegidos do ArcGIS Enterprise a clientes externos, ou seja, sistemas com a necessidade de serem acessados fora da rede interna da organização, via uma DMZ, por exemplo, para suportar o acesso dos trabalhadores de campo sem uma VPN.
Existem considerações adicionais que fazem parte da decisão sobre qual padrão usar, que este post não abordará, como quantos recursos, por exemplo hardware, licenciamento e equipe, serão necessários para cada padrão.
Para simplificar e focar no aspecto de segurança do padrão arquitetural, todas as arquiteturas neste post não são altamente disponíveis, mas cada uma pode ser ajustada para uma arquitetura altamente disponível sem alterar o padrão.
DMZ Reverse Proxy
Vamos começar com o padrão mais comum de implantação do sistema ArcGIS Enterprise voltado para o exterior, usando um reverse proxy na DMZ.
Figura 1 - DMZ Reverse Proxy

Neste padrão, todos os componentes do ArcGIS Enterprise são hospedados na rede interna, atrás do firewall, e um reverse proxy (pode ser um reverse proxy comercial, como F5 ou NetScaler, reverse proxy open-source como Nginx ou HAProxy, ou um segundo conjunto de ArcGIS Web Adaptors) é implantado na DMZ e encaminha as solicitações externas para o ArcGIS Enterprise.
O portal do ArcGIS Enterprise suporta apenas um DNS para a URL pública do portal (o URL do contexto web), e para suportar acesso externo, deve ser usado um nome DNS resolvível externamente para o URL do contexto web do portal, por exemplo https://gis.company.com/portal.
Na maioria dos casos, o padrão acima incluirá a implementação de um Sistema Dividido de Nomes de Domínio (Split DNS), ou seja, solicitações internas ao DNS do ArcGIS Enterprise (por exemplo gis.company.com) serão resolvidas para o IP da máquina dos web adaptors internos, assim os usuários internos permanecerão atrás do firewall, e solicitações externas ao DNS do ArcGIS Enterprise serão resolvidas para o IP do reverse proxy na DMZ.
Usar um Web Application Firewall (WAF) na frente do reverse proxy da DMZ é uma prática recomendada de segurança, pois adiciona controles adicionais. A Esri mantém um documento (login organizacional é necessário) em https://trust.arcgis.com com uma lista de endpoints que podem ser filtrados com segurança para negar acesso externo a recursos potencialmente sensíveis em seu site ArcGIS Enterprise.
Restrições Especiais de Segurança
Sem Acesso Não Autenticado à Rede Interna
Em um sistema federado ArcGIS Enterprise, o portal é responsável pela autenticação e autorização do usuário. No padrão acima, quando o usuário faz uma solicitação ao ArcGIS Enterprise, este verificará primeiro se a solicitação ao recurso protegido (por exemplo serviço) contém informações válidas de autenticação e, se não contiver, retornará uma resposta redirecionando o cliente para autenticar-se com o provedor de identidade configurado, por exemplo SAML ou OpenID Connect.
Na arquitetura acima, uma solicitação não autenticada vinda de um cliente externo é passada do reverse proxy da DMZ para um web adaptor interno e deste para o portal ou servidor ArcGIS Enterprise antes que o ArcGIS Enterprise retorne uma resposta redirecionando o cliente.
Algumas políticas de segurança proíbem acesso não autenticado à zona intranet e portanto a arquitetura acima não atende essa restrição.
Sem Acesso HTTPS / Apenas Acesso ao Banco de Dados é Permitido da DMZ para a Rede Interna
A maioria das políticas de segurança permite acesso inbound da DMZ para a rede interna mas pode limitar o tipo permitido por protocolos ou portas. Exemplos seriam não permitir acesso HTTPS (Hypertext Transfer Protocol Secure) da DMZ para a intranet ou permitir apenas acesso ao banco via portas customizadas.
Na arquitetura acima o reverse proxy da DMZ passa as solicitações ao ArcGIS Enterprise usando HTTPS via porta 443, o que não atende à restrição.
Sem Acesso de Entrada da DMZ para a Rede Interna
Em alguns casos políticas de segurança proíbem qualquer tipo de acesso inbound da DMZ para a rede interna e permitem apenas conexões não persistentes da intranet para a DMZ.
Padrões de Arquitetura de Segurança
Vamos considerar os padrões abaixo de arquitetura de segurança e revisar como cada padrão aborda algumas ou todas as restrições que revisamos acima.
Portal ArcGIS Enterprise na DMZ e Serviços Registrados
Figura 2 - Proxy do Portal ArcGIS Enterprise
<\/span><\/P> <\/DIV>Na figura 2 acima, há um portal ArcGIS Enterprise na DMZ e um servidor ArcGIS Enterprise na rede interna. O servidor standalone interno não está federado com o portal – os serviços são publicados diretamente no servidor standalone, configurados como seguros no servidor usando uma conta de aplicativo (conta de aplicativo incorporada do ArcGIS Enterprise server ou conta de serviço Active Directory / LDAP), e então adicionados ao portal como itens da web com credenciais armazenadas. Quando um serviço seguro do ArcGIS Enterprise server é registrado no portal com credenciais armazenadas, o portal cria uma URL proxy para esse serviço, e todas as solicitações para esse serviço passarão pelo portal antes de serem encaminhadas para o servidor standalone interno. O portal ArcGIS Enterprise também permite que você defina limite de taxa e referenciadores específicos que podem acessar o serviço.<\/P>Usar o padrão acima atende à restrição de não permitir acesso não autenticado à rede interna, pois todas as solicitações externas devem passar pelo portal na DMZ, que primeiro autentica e autoriza o usuário, e somente então faz uma solicitação ao serviço na rede interna. Esteja ciente de que, como todas as solicitações do portal para o servidor são feitas usando as credenciais armazenadas, você perde a capacidade de rastreamento do editor.<\/P>A arquitetura neste padrão pode ser elaborada para incluir um sistema federado voltado para a rede interna do ArcGIS Enterprise com portal, servidor hospedado e servidor(es) federado(s), conforme ilustrado na figura 3.<\/P> <\/P>Figura 3 - ArcGIS Enterprise Portal Proxy Elaborado<\/H3> <\/P>
<\/span><\/P>Geodatabase Replicado Interno<\/H2> <\/P>As políticas de segurança de algumas organizações não permitem acesso HTTPS da DMZ para a intranet, permitindo apenas acesso ao banco de dados, geralmente via portas não padrão, e em muitos casos também não permitem acesso externo a um banco de dados primário de produção, exigindo o uso de um banco de dados separado.<\/P>Na figura 4 abaixo, o ArcGIS Enterprise está implantado na DMZ, e um geodatabase corporativo replicado interno é usado como fonte de dados registrada para o servidor de mapeamento. Pode-se usar replicação do geodatabase Esri ou replicação RDBMS.<\/P> <\/P>Figura 4 - Replicação de Banco de Dados<\/H3> <\/P>
<\/span><\/P> <\/DIV>A figura 5 abaixo apresenta uma arquitetura elaborada que inclui um sistema ArcGIS Enterprise voltado para a rede interna na rede interna e um sistema ArcGIS Enterprise voltado para o exterior na DMZ.<\/P> <\/P>Figura 5 - Replicação de Banco de Dados Elaborada<\/H3> <\/P>
<\/span><\/P> <\/DIV>Publicação e Colaboração de Serviços<\/H2> <\/P>Finalmente, para aqueles que não permitem nenhum acesso inbound da DMZ para a intranet, a figura 6 abaixo mostra um ArcGIS Enterprise voltado para o exterior na DMZ e um ArcGIS Enterprise voltado para a intranet na intranet, com:<\/P>Serviços publicados no sistema ArcGIS Enterprise da DMZ como camadas hospedadas, e tarefas automatizadas executadas em uma programação (por exemplo, noturna ou semanal) para sobrescrever os dados hospedados com dados atualizados do sistema ArcGIS Enterprise interno<\/LI>Camadas feature são compartilhadas por cópia do sistema ArcGIS Enterprise interno para o sistema ArcGIS Enterprise da DMZ via colaboração distribuída com edição compartilhada bidirecional (introduzida na versão 10.9)<\/LI><\/OL> <\/P>Figura 6 - Publicação e Colaboração de Serviços<\/H3> <\/P>
<\/span><\/P> <\/DIV>Restringir Acesso Externo a Aplicações ao ArcGIS Enterprise<\/H1> <\/P>Em alguns casos, organizações usam o ArcGIS Enterprise para suportar aplicações externas integradoras e querem restringir o acesso das aplicações externas filtrando solicitações externas, permitindo solicitações apenas de uma lista específica ou intervalo de IPs, ou de domínios específicos.<\/P> <\/P>Proxy do ArcGIS Online<\/H2> <\/P>Sempre semelhante ao padrão DMZ ArcGIS Enterprise Portal and Registered Services (figura 2 acima), o ArcGIS Online também atua como proxy quando você registra serviços seguros tanto do servidor standalone do ArcGIS Enterprise quanto do sistema federado do ArcGIS Enterprise. Na Figura 7 abaixo, serviços provenientes do sistema interno do ArcGIS Enterprise são registrados no ArcGIS Online com credenciais armazenadas; o ArcGIS Online pode acessar os serviços via proxy reverso da DMZ, e o proxy reverso está configurado para permitir solicitações apenas do domínio do ArcGIS Online, bloqueando solicitações provenientes de quaisquer outras fontes. O aplicativo web ou móvel do sistema integrador pode ser registrado no ArcGIS Online usando OAuth 2.0 e Identidade ArcGIS, assim somente usuários autenticados e autorizados podem acessar os serviços registrados. Como o ArcGIS Online acessará os serviços usando as credenciais armazenadas, o rastreamento do editor não funcionará. Semelhante ao portal, você pode definir limite de taxa e referenciadores específicos que podem acessar os serviços.<\/P> <\/P>Figura 7 - ArcGIS Online e Serviços Registrados<\/H3> <\/P>
<\/span><\/P> <\/P>Proxy do Servidor<\/H2> <\/P>Outra abordagem seria usar um site standalone do servidor ArcGIS Enterprise e um proxy do servidor para acessar serviços seguros a partir de um aplicativo web integrador.<\/P>Na figura 8 abaixo, clientes do aplicativo web do sistema integrador estão configurados para enviar solicitações GIS a um proxy hospedado no servidor da aplicação do sistema integrador. O servidor da aplicação integradora é responsável por garantir acesso seguro ao proxy, ou seja, permitir apenas usuários autenticados pelo app acessarem o proxy, além de proteger (criptografar) as credenciais do servidor ArcGIS Enterprise. O proxy gerencia a segurança dos tokens do servidor ArcGIS Enterprise em nome do cliente, usando uma conta incorporada ao servidor ou uma conta Active Directory / LDAP, e envia a solicitação ao site standalone interno do servidor ArcGIS Enterprise via proxy reverso da DMZ. O proxy reverso está configurado para permitir solicitações apenas dos IPs (lista ou intervalo) dos servidores da aplicação integradora, bloqueando solicitações provenientes de quaisquer outras fontes.<\/P> <\/P>Figura 8 - Proxy do Servidor Aplicativo Web Integrador<\/H3> <\/P>
<\/span><\/P> <\/P>