nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Vzorce nasazení pro zpřístupnění zabezpečených služeb ArcGIS Enterprise externím uživatelům

NoahMayer

Úvod

Bezpečnost hraje velkou roli v procesu návrhu podnikové architektury. Bezpečnostní politiky se liší mezi organizacemi a jsou vyžadovány různé vzory nasazení, aby vyhověly těmto požadavkům a omezením. V tomto příspěvku se pokusím řešit některá z běžnějších bezpečnostních omezení a navrhnout vzory nasazení, které je splňují.

Toto rozhodně není vyčerpávající seznam všech dostupných bezpečnostních požadavků a vzorů bezpečnostní architektury.

Tento příspěvek se zaměří na vzory architektury pro zpřístupnění zabezpečených zdrojů ArcGIS Enterprise externím klientům, tj. systémům s požadavkem na přístup mimo interní síť organizace, přes DMZ, například pro podporu přístupu terénních pracovníků bez VPN.

Existují další úvahy, které hrají roli při rozhodování o tom, který vzor použít, které tento příspěvek nepokrývá, jako například kolik zdrojů, např. hardware, licence a personál, bude pro každý vzor potřeba.

Abychom zjednodušili a zaměřili se na bezpečnostní aspekt vzoru architektury, všechny architektury v tomto příspěvku nejsou vysoko dostupné, ale každá může být upravena na vysoko dostupnou architekturu bez změny vzoru.

DMZ Reverse Proxy

Začněme nejběžnějším vzorem nasazení systému ArcGIS Enterprise orientovaným na externí přístup, používajícím reverse proxy v DMZ.

Obrázek 1 - DMZ Reverse Proxy

Obrázek 1 - DMZ Reverse Proxy.PNG

V tomto vzoru jsou všechny komponenty ArcGIS Enterprise hostovány v interní síti za firewallem a reverse proxy (může to být komerční reverse proxy jako F5 nebo NetScaler, open-source reverse proxy jako Nginx nebo HAProxy, nebo druhá sada ArcGIS Web Adaptors) je nasazena v DMZ a předává externí požadavky do ArcGIS Enterprise.

Portal ArcGIS Enterprise podporuje pouze jeden DNS pro veřejnou URL portálu (web context URL) a pro podporu externího přístupu musí být použito externě resolvovatelné DNS jméno pro web context URL portálu, např. https://gis.company.com/portal.

Ve většině případů tento vzor zahrnuje implementaci Split Domain Name System (Split DNS), tj. interní požadavky na DNS ArcGIS Enterprise (např. gis.company.com) budou rozřešeny na IP stroje interních web adaptérů, takže interní uživatelé zůstanou za firewallem a externí požadavky na DNS ArcGIS Enterprise budou rozřešeny na IP DMZ reverse proxy.

Použití Web Application Firewallu (WAF) před DMZ reverse proxy je bezpečnostní nejlepší praxí, protože přidává další bezpečnostní kontroly. Esri udržuje dokument (vyžaduje organizační přihlášení) na https://trust.arcgis.com s seznamem koncových bodů, které mohou být bezpečně filtrovány z externího přístupu k zamítnutí externího přístupu k potenciálně citlivým zdrojům ve vaší lokalitě ArcGIS Enterprise.

Speciální bezpečnostní omezení

Žádný neautentizovaný přístup do interní sítě

V federovaném systému ArcGIS Enterprise je portal odpovědný za autentizaci a autorizaci uživatelů. Ve výše uvedeném vzoru, když uživatel provede požadavek na ArcGIS Enterprise, ArcGIS Enterprise nejprve zkontroluje, zda požadavek na zabezpečený zdroj (např. službu) obsahuje platné autentizační informace, a pokud ne, vrátí ArcGIS Enterprise klientovi odpověď s přesměrováním k autentizaci u nakonfigurovaného poskytovatele identity, např. SAML nebo OpenID Connect.

Ve výše uvedené architektuře je neautentizovaný požadavek od externího klienta předán z DMZ reverse proxy do interního web adaptéra a od web adaptéra do portálu nebo serveru ArcGIS Enterprise před tím, než ArcGIS Enterprise vrátí klientovi odpověď s přesměrováním.

Některé bezpečnostní politiky zakazují neautentizovaný přístup do intranetové zóny, takže výše uvedená architektura nesplňuje toto omezení.

Žádný HTTPS přístup / Povolen je pouze přístup k databázi z DMZ do interní sítě

Většina bezpečnostních politik povoluje příchozí přístup z DMZ do interní sítě, ale může omezit typ povoleného přístupu podle protokolů nebo portů. Příklady by byly nepovolit HTTPS (Hypertext Transfer Protocol Secure) přístup z DMZ do intranetu nebo povolit pouze přístup k databázi přes vlastní porty.

Ve výše uvedené architektuře DMZ reverse proxy předává požadavky do ArcGIS Enterprise pomocí HTTPS přes port 443, což nesplňuje toto omezení.

Žádný příchozí přístup z DMZ do interní sítě

V některých případech bezpečnostní politiky zakazují jakýkoliv typ příchozího přístupu z DMZ do interní sítě a povolují pouze nepersistentní spojení z intranetu do DMZ.

Vzorce bezpečnostní architektury

Zvažme níže uvedené vzory bezpečnostní architektury a podívejme se, jak každý vzor řeší některá nebo všechna bezpečnostní omezení, která jsme si výše popsali.

DMZ ArcGIS Enterprise Portal a registrované služby

Obrázek 2 - ArcGIS Enterprise Portal Proxy

Figure 2 - ArcGIS Enterprise Portal Proxy.PNG <\/span><\/P> <\/DIV>Na obrázku 2 výše je ArcGIS Enterprise portál v DMZ a ArcGIS Enterprise server v interní síti. Interní samostatný server není federován s portálem – služby jsou publikovány přímo na samostatný server, nakonfigurovaný jako zabezpečený na serveru pomocí aplikačního účtu (vestavěný aplikační účet ArcGIS Enterprise serveru nebo Active Directory / LDAP služební účet), a poté přidány do portálu jako položky z webu s uloženými přihlašovacími údaji. Když je zabezpečená služba ArcGIS Enterprise serveru registrována v portálu s uloženými přihlašovacími údaji, portál vytvoří proxy URL pro tuto službu a všechny požadavky na tuto službu projdou portálem, než jsou přeposlány internímu samostatnému serveru. ArcGIS Enterprise portál také umožňuje definovat omezení rychlosti a specifické referrery, které mohou službu přistupovat.<\/P>Použití výše uvedeného vzoru splňuje omezení žádného neautentizovaného přístupu do interní sítě, protože všechny externí požadavky musí projít portálem v DMZ, který nejprve autentizuje a autorizuje uživatele a teprve poté provede požadavek na službu v interní síti. Uvědomte si, že protože všechny požadavky z portálu na server jsou prováděny pomocí uložených přihlašovacích údajů, ztrácíte schopnost sledování editorů.<\/P>Architektura v tomto vzoru může být rozšířena o interně orientovaný federovaný systém ArcGIS Enterprise s portálem, hostingovým serverem a federovanými servery, jak je znázorněno na obrázku 3.<\/P> <\/P>Obrázek 3 - Rozšířený ArcGIS Enterprise Portal Proxy<\/H3> <\/P> Obrázek 3 - Rozšířený ArcGIS Enterprise Portal Proxy.png <\/span><\/P>Interní replikovaná geodatabáze<\/H2> <\/P>Bezpečnostní politiky některých organizací neumožňují HTTPS přístup z DMZ do intranetu a povolují pouze přístup k databázi, obvykle přes nestandardní porty, a v mnoha případech také neumožňují externí přístup k primární produkční databázi a vyžadují použití samostatné databáze.<\/P>Na obrázku 4 níže je ArcGIS Enterprise nasazen v DMZ a interní replikovaná podniková geodatabáze je použita jako registrovaný zdroj dat pro mapový server. Může být použita buď Esri replikace geodatabáze nebo replikace RDBMS.<\/P> <\/P>Obrázek 4 - Replikace databáze<\/H3> <\/P> Obrázek 4 - Replikace databáze.PNG <\/span><\/P> <\/DIV>Obrázek 5 níže představuje rozšířenou architekturu, která zahrnuje interně orientovaný systém ArcGIS Enterprise v interní síti a externě orientovaný systém ArcGIS Enterprise v DMZ.<\/P> <\/P>Obrázek 5 - Rozšířená replikace databáze<\/H3> <\/P> Obrázek 5 - Rozšířená replikace databáze.PNG <\/span><\/P> <\/DIV>Publikace služeb a spolupráce<\/H2> <\/P>Konečně, pro ty, kteří neumožňují žádný příchozí přístup z DMZ do intranetu, obrázek 6 níže znázorňuje externě orientovaný ArcGIS Enterprise v DMZ a interně orientovaný ArcGIS Enterprise v intranetu, s:<\/P>Službami publikovanými do systému ArcGIS Enterprise v DMZ jako hostované vrstvy a automatizovanými úlohami běžícími podle plánu (např. noční nebo týdenní) pro přepsání hostovaných dat aktualizovanými daty z interního systému ArcGIS Enterprise<\/LI>Vrstvy prvků jsou sdíleny kopírováním z interního systému ArcGIS Enterprise do systému ArcGIS Enterprise v DMZ prostřednictvím distribuované spolupráce s obousměrným sdíleným editováním (představeno ve verzi 10.9)<\/LI><\/OL> <\/P>Obrázek 6 - Publikace služeb a spolupráce<\/H3> <\/P> Obrázek 6 - Publikace služeb a spolupráce.PNG <\/span><\/P> <\/DIV>Omezit přístup externích aplikací k ArcGIS Enterprise<\/H1> <\/P>V některých případech organizace používají ArcGIS Enterprise k podpoře externích integračních aplikací a chtějí omezit přístup externích aplikací filtrováním externích požadavků, povolujíc požadavky pouze ze specifického seznamu nebo rozsahu IP adres či z konkrétních domén.<\/P> <\/P>ArcGIS Online Proxy<\/H2> <\/P>Podobně jako vzor DMZ ArcGIS Enterprise Portál a registrované služby (obrázek 2 výše), i ArcGIS Online funguje jako proxy při registraci zabezpečených služeb buď ze samostatného ArcGIS Enterprise serveru nebo z federovaného systému ArcGIS Enterprise. Na obrázku 7 níže jsou služby z interního systému ArcGIS Enterprise registrovány v ArcGIS Online s uloženými přihlašovacími údaji, ArcGIS Online může přistupovat ke službám přes DMZ reverzní proxy, která je nakonfigurována tak, aby povolovala požadavky pouze z domény ArcGIS Online a blokovala požadavky z jiných zdrojů. Integrační systém webová nebo mobilní aplikace může být registrována u ArcGIS Online pomocí OAuth 2.0 a ArcGIS Identity, takže pouze autentizovaní a autorizovaní uživatelé mohou přistupovat k registrovaným službám. Protože ArcGIS Online bude přistupovat ke službám pomocí uložených přihlašovacích údajů, sledování editorů nebude fungovat. Podobně jako u portálu můžete definovat omezení rychlosti a specifické referrery, které mohou služby přistupovat.<\/P> <\/P>Obrázek 7 - ArcGIS Online a registrované služby<\/H3> <\/P> Obrázek 7 - ArcGIS Online a registrované služby.PNG <\/span><\/P> <\/P>Server Proxy<\/H2> <\/P>Dalším přístupem by bylo použití samostatného webu ArcGIS Enterprise serveru a serverového proxy pro přístup k zabezpečeným službám z integrační webové aplikace.<\/P>Na obrázku 8 níže jsou klienti integrační webové aplikace nakonfigurováni tak, aby odesílali GIS požadavky na proxy hostované na aplikačním serveru integračního systému. Integrační aplikační server je odpovědný za zabezpečení přístupu k proxy, tj. povolit přístup pouze uživatelům autentizovaným aplikací k proxy, a chránit (šifrovat) přihlašovací údaje ArcGIS Enterprise serveru. Proxy spravuje bezpečnost tokenu ArcGIS Enterprise serveru jménem klienta pomocí vestavěného aplikačního účtu serveru nebo Active Directory / LDAP služebního účtu a odesílá požadavek na interní samostatný webový server ArcGIS Enterprise přes DMZ reverzní proxy. Reverzní proxy je nakonfigurována tak, aby povolovala požadavky pouze z IP adres integračních aplikačních serverů (seznam nebo rozsah), blokující požadavky z jiných zdrojů.<\/P> <\/P>Obrázek 8 - Integrující Web App Server Proxy<\/H3> <\/P> Obrázek 8 - Integrace Web App Server Proxy.PNG <\/span><\/P> <\/P>

Najděte více příspěvků označených jako

Configuration & Integration

Architecture & Security

Komentáře

NoahMayer

@spanton you nailed it. You want to expose ArcGIS Enterprise secured resources to external clients when they can't use VPN for any reason.

spanton

Hello @NoahMayer , what would be a common use cases for exposing ArcGIS Enterprise secured resources to external clients? We currently have a DMZ in place but are considering doing away with it; currently our field crews access our maps via VPN.

SimonSchütte_ct

Thank you, I´ll have to give it a try.

DavidHoy

If you were allowing CORS requests to your Portal from AGOL,
you would add the following to your AllowedOrigins

perhaps both these should be allowed and included in the list of URLs allowed to access your proxied service?

NoahMayer

Related to the remote address {someipaddress}:443 requesting access to the internal endpoints: ArcGIS Online uses dynamic IPs, but you should not see requests coming from ArcGIS Online using IP address. Can you test allowing access only from {subscription}.maps.arcgis.com and see if it allows access via the ArcGIS Online proxy?

SimonSchütte_ct

@NoahMayer These are my findings on ArcGIS Online <-> ArcGIS Enterprise Communication:

ArcGIS Online {subscription}.maps.arcgis.com will try to access
machinename.example.com/server/...
and
machinename.example.com/portal/...

Communication is initiated by {subscription}.maps.arcgis.com
and another remoteaddress {someipaddress}:443 (is it a fixed or dynamic IP? generic for ArcGIS Online or specific to subscription?)
requesting access to the internal machinename.example.com server/portal endpoints.

Communication is done using HTTPS: GET, HEAD, POST, OPTIONS

NoahMayer

@SimonSchütte_ct It definitely makes sense that in this use case only a subset of ArcGIS Online domains will be used. If you want to narrow down the list of allowed domains, it will require some testing to find out which domains are used in this use case.

SimonSchütte_ct

ArcGIS Online as Proxy: How to allow access only to requests from ArcGIS Online domain?

@NoahMayer Is there a list of the specific domains that need to be configured? In ArcGIS Trust, there is a document for the WAF and allowed ArcGIS Online domains, but there is nothing mentioned regarding which domains are relevant for this use case.

Some more details on the actual setup and configuration would be appreciated.

NoahMayer

@GeoExplorer
I'm not in a position to say if a two-way replication is more of a problem/threat compared to a one-way replication from corporate database to the database in DMZ and ETL from the database in the DMZ to the corporate database. This is up to your security team to decide. If they have specific questions regarding how the Esri software works, or if they are willing to share their concerns, Esri PS can try to answer their questions and help them with their decisions.

DavidHoy

Hi @GeoExplorer
it would be possible to have 2-way geodatabase replication using a geodata service running on the internal ArcGIS Server. This would only require 443 access through the internal firewall. The synchronisation would be triggered by a python script running on the Server in the DMZ. The python script would require a geodatabase connection (via Oracle client) to the DMZ Geodatabase but a geodata service connection to the "master"geodatabase within the secure network.

GeoExplorer

Dear @NoahMayer,

Thank you for your response.

Cyber Security team in our Organisation has put two-way replication on hold, mentioning no communication from database in DMZ to corporate database network. But approved using one-way replication from corporate database to database in DMZ, which is disconnected replication that is batched to sync overnight.

Do you reckon it is really a problem/threat in enabling two-way replication as compared to One-way replication via custom port (1521)? Suggestion from the cyber security team is to write ETL scripts to bring down the necessary data collected by field users from the DMZ database to the corporate database.

NoahMayer

Dear @GeoExplorer ,

What are the concerns you have regarding using a two-way replication? In general I would prefer to use geodatabase replication over ETL where available, since geodatabase replication has a robust set of capabilities, such as viewing and resolving conflicts, which might be very challenging with ETL. Depending on the concerns you have, you might opt-in to use disconnected replication instead of connected replication.

GeoExplorer

Hello Noah,

Thank you for providing the various deployment patterns that suit our organization's needs.

We are working on a design to facilitate an external-facing ArcGIS Enterprise to enable field crews to connect and share data via collaboration with external government agencies.

We were considering the architecture provided in Figure 5 of the document you mentioned. Our architecture team suggested placing the replicated geodatabase in the DMZ via port 1521 and running nightly replication instead of hosting it in the corporate network. We are using Oracle database, so allowing port 1521 or any other custom port to let replication work. Noting data is 24 hour delay to external ArcGIS instance.

Could you please advise on the issues associated with having a replicated Oracle database in the DMZ and enabling ArcGIS replication? Is allowing two-way replication a threat? One suggestion is to enable only one-way replication from the internal geodatabase to the external database in the DMZ and to write ETL scripts (FME) to fetch the data from the external database.

ArcGIS Enterprise 10.9.1

Oracle DB - 19c

NoahMayer

@vijaybadugu,

Portal for ArcGIS does not support changing/setting the WebContextURL for an existing ArcGIS Enterprise system that has content, because all the original items have the old, internal domain URLs, and all those will have to be updated to the new DNS alias.

The Services URL in the federation will have to be updated with the new DNS alias because this is how all users will access the services. External users will not be able to resolve your internal domain URLs.

I recommend you collaborate with Esri professional services to assist you with this process.

vbadugu_royomartin

I removed user and group store configurations as I'm using SAML authentication. as I mentioned earlier, It is federated with server,

Service URL

https://<Internal domain> /arcgis

Administration URL

https://<Internal domain>:6443/arcgis

as per old configurations, I did not change anything and anywhere except WebContextURL in arcgis portal admin.all are pointing to internal domain reference.

For above Server Configurations Do I need provide DNS alias or internal domain ?

Every time, I click on Organization tab in ArcGIS Portal, it displays a dialog to sign in. can we bypass this ? after clicking ok, it automatically signed in.

We have a Web application and in that, all map services are pointing to <internal domain>/rest/services/<Service Name>/MapServer. Do I need to change all map services URLs to DNS alias instead of internal domain that we were using till now?

Thanks

DeanMoiler

Hi @vijaybadugu,

You can apply your SAML username to existing users to allow SAML login if you don't want to migrate content / create / delete users. More info here:

Solved: Re: Change Authentication from IWA to other method... - Esri Community

As @DavidHoy says, this won't change the user's username, but it will allow existing users to log in with SAML.

We investigated creating a new domain attribute to hold username@domain to keep this naming format, as we had thousands of users, and have new users created in this format, but the overhead for this attribute was passed over in favour of creating new users with new username format and migrating content and users by script.

vbadugu_royomartin

Can I make both as empty (user store and group store ) ?

DavidHoy

If you just switch to using SAML login, you are correct that new users may appear in your Portal for the <usrname>@domain.net username provided by Azure AD as they start to login (if you have automatic user creation enabled)

There is no back-door way to update existing users to have a new username.

You will need to transfer any content owned by the existing usernames <usrname>@domain to be owned by the new names.

We have handled this by scripting
- create the new users and assign the new users the appropriate type and role
- assign the new usernames to the Groups to match the old username
- transfer ownership of any Portal items to the new user
- disable the existing Username (remove in future)

Once this is complete, the first time a user logs in via SAML, they will find their new username is in place

You cannot have IWA and SAML working at the same time, so User Store Configuration and Group Store configuration cannot be "WINDOWS"

vbadugu_royomartin

Have a another question regarding content transfer, The current user format with IWA is <usrname>@domain. when I moved from the AD to Azure AD, The format of username would be changed to <usrname>@domain.net (email format). How do I transfer the content to new user ? is there a way to update enterprise user without transferring the content ? and we have a bunch of users. when comes to the identity store, can I keep same what it is now "windows" in portal admin

User store configuration:

{ "type": "WINDOWS"

Group store configuration:

{ "type": "WINDOWS",

? do i need to change anything? Actually I disabled the windows authentication and enabled Anonymous enabled.

NoahMayer

@vijaybadugu Yes definitely. SAML and OpenID Connect logins are recommended.

vbadugu_royomartin

We have configured AZURE AD for authenticate SAML for internal and external. is that best practice to go farward

DavidHoy

hi Vijay,

your plan is sound - a split-zone dns arrangement would certainly allow the ArcGIS Enterprise to work for external and internal users.

There are many forms of DNS, so, it is difficult to provide instructions here unless you can be more specific. A bit of web searching for the doc for your particular DNS provider should get you there.

If you cant work it out - it is not a critically bad thing to allow your internal users to have everyone have the FQDN resolve to the Reverse Proxy.

NoahMayer

Hi @vijaybadugu,

What you are describing is a Split (or Split-Brain) DNS configuration: in this configuration, as you described, internal users are directed to the internal server IP (which is a private IP) and external users are directed to the DMZ reverse proxy IP (which is a public IP). The actual configuration depends on how your organization configures DNS.
In many cases, organizations will have:
1. Internal DNS servers, where they would configure A-Records and CNAME records for their internal domain, for example:
A Record: machine1.company.int --> <Machine Internal IP>
CNAME Record: maps.company.com --> machine1.company.int
2. Public DNS service, such as Google or Cloudflare, where they would configure an A Record for the external users, for example:
A Record: maps.company.com --> <DMZ Reverse Proxy Public IP>

In this configuration, all internal users, since they are on the internal network, which is configured to use the internal DNS servers for name resolution, will be directed to the internal server, and all the external users, since they are coming from the Internet, will be directed to the DMZ reverse proxy.

vbadugu_royomartin

I have Question regarding configuration of DMZ with Single machine Deployment, we have been struggling to configure reverse proxy for ArcGIS Enterprise. We recently Upgraded the Enterprise to 11.1. All components are on Same Windows Server (2 WA's, Server, Data store and Portal) Federated IWA. We have Configured the load balancer on DMZ Server and open the 443 to route the traffic from DMZ Server. Here is the Our Requirement, Suppose User or member accessed the URL from External, It should route from the DMZ (Split DNS). If user Accessed from Internal network, it should hit Direct server instead of Routing From DMZ. Is this Possible ? If yes, How I need to configure those ? Please help us .

JeffDeWeese

The only publicly available icons I am aware of are here, but they lack the server type icons, etc.: https://community.esri.com/t5/implementing-arcgis-blog/esri-presentation-icons/ba-p/886935

NoahMayer

@JeffDeWeese can you help?

BrianVillanueva

Hi @NoahMayer , where can I find the stencils used in the diagrams?

MehdiPira1

Very helpful, Thanks @NoahMayer .

NoahMayer

Hi @MartinWennerwald1!

Esri is maintaining an ArcGIS Online domain requirements document in ArcGIS Trust Center. There are tow versions of the document:

Public document (less detailed): https://trust.arcgis.com/en/documents/AGOL_Domain_Requirements.pdf

Customer Accessible Document (more detailed, requires login): https://trust.arcgis.com/en/customer-documents/ArcGIS%20Online%20FQDN%20Requirements%20V1.8%20June%202021.pdf

This document is intended mainly for a forward proxy, to allow users to access ArcGIS Online resources, so you can see the list beyond what's required for setting up the ArcGIS Online Proxy (Fig. 7).

What I would recommend is to view the service URL in the portal item which is created for the registered services, this URL is the proxy URL, and allow only the FQDNs which are used for the proxy:

MartinWennerwald1

Hi Noah

Thanks for a great detailed article.

We are currently working on setting up the ArcGIS Online Proxy setup (Fig. 7), but can't seem to find information on which domains to limit access to. In your article you write : "ArcGIS Online can access the services via the DMZ reverse proxy, and the reverse proxy is configured to allow requests only from ArcGIS Online domain, blocking requests from any other sources."

Where do I find the documentation for what the "arcgis online domain" consists of, specifically with regards to registered services?

Thanks in advance.

/Martin

Připojte se k diskusi

Přihlášení členové mohou přispívat, sledovat aktualizace a další. Nový zde? Zaregistrujte si bezplatný účet.

Přihlásit se
Registrovat se

Rychlé odkazy

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.