In der heutigen IT-Branche gibt es viele verschiedene Definitionen, Implementierungsmuster und Implikationen einer Zero-Trust-Architektur (ZTA). Auch wenn Esri keine ZTA-Strategie für eine bestimmte Organisation definieren oder implementieren kann, ist mit ArcGIS eine Reihe von Softwarelösungen und Werkzeugen verfügbar, die in einer IT-Umgebung ausgeführt wird und in zunehmendem Maße den Einschränkungen, Regeln und Richtlinien unterliegt, die von einer ZTA implementiert werden können. Im Folgenden werden einige Überlegungen zur Verwendung von ArcGIS mit einer ZTA beschrieben.
Das ArcGIS-System wurde aus der Perspektive der Softwarearchitektur so konzipiert, dass es auf bestimmten Annahmen bezüglich Netzwerkzugriff, Offenheit und Kompatibilität beruht – ein Ansatz, der auch als implizites Vertrauen bezeichnet wird. Ohne sorgfältiges Verständnis der ZTA-Strategie einer Organisation und ohne eine strukturierte Herangehensweise an die Planung und Implementierung kann die Bereitstellung von ArcGIS in einer ZTA-Umgebung bei diesem Entwurfsansatz Herausforderungen oder funktionale Einschränkungen mit sich bringen.
Esri arbeitet seit jeher daran, dem Bedarf an ZTA-fähigen Bereitstellungsmustern in seinen Softwareversionen gerecht zu werden, und wird dies auch weiterhin tun. In vielerlei Hinsicht unterstützt ArcGIS heute ZTA-ähnliche Sicherheitsmechanismen, da die Software so konfiguriert werden kann, dass vor dem Anzeigen von oder dem Zugreifen auf Daten eine Authentifizierung von allen Benutzern angefordert wird, Berechtigungen sorgfältig verwaltet und alle Benutzer von Remote-Anwendungen oder -Clients authentifiziert werden. Ob die eigenen Sicherheitsanforderungen durch diesen bestehenden Sicherheitsstatus ausreichend erfüllt werden, muss jede Organisation nach sorgfältiger Prüfung und Abwägung für sich selbst entscheiden.
In der Praxis implementieren die meisten Organisationen eine ZTA mit einer Kombination aus neuen Richtlinien, neuen Technologien und neuen Netzwerkarchitekturen. Im Allgemeinen bedeutet dies eine Abkehr von der Netzwerkbereitstellung im WAN-Stil (Wide Area Network), bei der die Kommunikation zwischen Systemen, die sich im selben Netzwerk befinden, weitgehend offen und uneingeschränkt ist und die Authentifizierung mit anwendungsspezifischen Protokollen und Werkzeugen verwaltet wird. Dieser traditionelle Netzwerkansatz beruht auf der Absicherung des Netzwerkperimeters, was zwar gegen bestimmte Bedrohungen wirksam ist, aber den Rest des Netzwerks anfällig für einen externen Angreifer machen kann, dem es gelungen ist, den sicheren Perimeter zu durchdringen.
Die ZTA geht davon aus, dass dieses bisherige Muster eines weitgehend offenen Netzwerkzugriffs von Grund auf unsicher ist. Sie legt nahe, dass Benutzer, Geräte, Anwendungen und Services häufiger, sorgfältiger und an mehr Orten als je zuvor authentifiziert werden sollten. Ein gängiges ZTA-Ziel besteht darin, für eine begrenzte Dauer für jede Netzwerkaktivität, die zwischen zwei Komponenten oder Benutzern eines Systems stattfindet, eine Least-Privileges-Sitzung zu erreichen. Hierfür kann ein ganzes Spektrum von Richtlinien und technischen Ansätzen verwendet werden. Letztlich ist jede Organisation dafür verantwortlich, ihr eigenes ZTA-Konzept zu definieren, die Architektur an dieses Konzept anzupassen und die Compliance im Laufe der Zeit zu überwachen.
Als Software-as-a-Service-Angebot ist ArcGIS Online in der Regel außerhalb der Grenzen einer ZTA-Definition positioniert. Dies liegt daran, dass Esri als Anbieter für die Systemsicherheit und die Systemkontrollen verantwortlich ist und sich die Benutzer auf ihr Vertrauen und ihre Vereinbarung mit Esri verlassen, dass diese Ziele erreicht werden.
In einem SaaS-System greifen alle Benutzer ausschließlich über HTTPS-Anforderungen, die an bekannte und gesicherte REST-Endpunkte gesendet werden, auf ArcGIS Online zu, ohne Zugriff auf die Backend-Systeme, das Netzwerk, in dem sie gehostet werden, oder andere gesicherte Ressourcen zu haben. Neben einer Sicherheitsbaseline für ArcGIS Online bietet Esri eine Vielzahl von Sicherheits- oder Berechtigungseinstellungen. Diese reichen von der Einschränkung des standardmäßigen Benutzerzugriffs über die Steuerung von Berechtigungen bis hin zur Freigabe von Inhalten und können so konfiguriert werden, dass der Sicherheitsbedarf der einzelnen Organisationen in einem SaaS-System erfüllt wird.
ArcGIS Pro ist eine Windows-Desktop-Anwendung, die für eine Vielzahl von Datenanalyse-, Bearbeitungs- und Visualisierungs-Workflows verwendet wird. In diesen Workflows stellt ArcGIS Pro in der Regel eine Verbindung zu Datasets her, die in drei Kategorien unterteilt werden können:
Jedes Mal, wenn für diese Verbindungen eine Authentifizierung erforderlich ist, muss ArcGIS Pro den Authentifizierungsstandard kennen und explizit unterstützen, damit Benutzer eine Verbindung zu dem Datenspeicherort herstellen können. Die Software unterstützt derzeit eine Vielzahl von Authentifizierungsmustern von Datenbankbenutzern bis zu Unternehmensidentitäten oder der Betriebssystemauthentifizierung, Zugriffsschlüsseln und Geheimnissen, Anmeldeinformationen über ein Dienstkonto und anderen. Die ZTA implementiert häufig neue und komplexere Authentifizierungsanforderungen für Speichersysteme. Dazu zählt beispielsweise die Multi-Faktor-Authentifizierung oder die Streichung der Unterstützung für Headless-Dienstkonten oder dedizierte Datenzugriffskonten. Jede Implementierung von ZTA-Sicherheitsmaßnahmen für Datenbanken, Dateisysteme, Web-Services oder andere Datenspeichersysteme muss sorgfältig abgewogen werden, um die potenziellen Auswirkungen auf ArcGIS-Benutzer zu berücksichtigen.
Außerdem sendet ArcGIS Pro HTTPS-Anforderungen bei der Kommunikation mit ArcGIS Enterprise, ArcGIS Online oder anderen externen Web-Services. Wenn diese Anforderungen auf unerwartete Weise oder mithilfe von browserähnlichen ZTA-Umsetzungsmustern wie der cookiebasierten Sitzungsverwaltung gesichert werden, kann ArcGIS Pro möglicherweise keine Verbindung zu diesen Endpunkten herstellen, da derzeit nur einige bekannte und sorgfältig getestete Sicherheitszugriffsmuster für HTTPS-Anforderungen unterstützt werden.
Andere ArcGIS-Desktop-Anwendungen wie ArcGIS Drone2Map, ArcGIS Earth, ArcGIS AllSource, Survey123 oder Insights Desktop können ebenfalls von Entscheidungen zur ZTA-Architektur betroffen sein. Jede dieser Anwendungen verwendet HTTPS-basierte Verbindungen, um Daten abzufragen und zu visualisieren, sodass die gleichen Vorbehalte oder Bedenken relevant sind.
Die Sicherheit mobiler Geräte und Anwendungen ist ein umfangreicher, komplexer und herausfordernder Bereich der Cybersicherheit. Seine Bedeutung hat mit der allgemeinen Einführung von Mobile-App-Workflows in Kombination mit der steigenden privaten Nutzung durch Mitarbeiter und Mitglieder einer Unternehmensumgebung zugenommen. Zu den gängigen Themen der mobilen Sicherheit gehören u. a. Enterprise Mobility Management (EMM), Geräteregistrierung, Endpoint Management, Traffic Management, Mobile Device Management (MDM) und Mobile Application Management (MAM). Eine Vielzahl von Anbieterlösungen zielt ebenfalls darauf ab, die Sicherheit mobiler Workflows zu erhöhen. Hinzu kommen benutzer- und verhaltensbasierte Steuerungen, die dazu beitragen können, diese Probleme zu vermeiden.
Obwohl mobile Geräte VPNs auf Geräte- und App-Ebene unterstützen können, wird das VPN-Konzept als Lösung für die Cybersicherheit in einer ZTA in Frage gestellt. Viele mobile Apps gehen davon aus, dass es internetbasierte Dienste gibt, sodass ein Zugriff über öffentliche Funksignale und verschiedene Standorte möglich ist.
Die ZTA wird häufig für Workflows auf mobilen Geräten implementiert, indem eine Kombination aus gerätebasierter Authentifizierung, Geräteregistrierung und kontinuierlicher Zugriffsüberwachung verlangt wird. Diese Zugriffskontrollen werden oftmals auf Betriebssystem-Ebene implementiert, die nicht immer für die mobilen ArcGIS-Anwendungen zugänglich ist. Beispielsweise kann ein Gerät bei Azure Entra ID registriert werden, um anhand der ID eine bedingte Überprüfung durchzuführen, bevor die Authentifizierung über Azure AD zulässig ist. Wenn die mobile ArcGIS-Anwendung jedoch nicht weiß, dass die Anforderung besteht oder wie auf die Registrierungsinformationen des Geräts zugegriffen werden kann, wird sie nicht an den Entra ID-Endpunkt übertragen, und die Authentifizierung kann fehlschlagen.
ArcGIS Enterprise ist ein serverbasierter Satz von Webanwendungen und Web-Services, auf die Benutzer von einem Client über HTTPS-Anforderungen zugreifen. Bei diesem Client kann es sich um einen Browser, eine mobile App oder eine Desktop-Anwendung handeln. Die Auswirkungen auf diese Clients wurden in den vorherigen Abschnitten erläutert. Aber eine ZTA-Konfiguration kann sich auch auf ArcGIS Enterprise selbst auswirken. Wenn beispielsweise alle internen Netzwerkanforderungen aufgrund einer Systemrichtlinie authentifiziert werden müssen, könnte diese Richtlinie alle Anforderungen zwischen ArcGIS Enterprise-Komponenten enthalten, die entweder durch von ArcGIS verwaltete Token und Schlüssel oder durch eine Benutzer- und Kennwortauthentifizierung gesichert sind. Wenn ein Netzwerk so konzipiert ist, dass jede interne Netzwerkanforderung gefiltert wird, um ein bestimmtes Zertifikat oder einen bestimmten Schlüssel oder Header zu verlangen, werden diese internen Komponentenanforderungen wahrscheinlich blockiert und schlagen fehl.
Die oben genannten Auswirkungen zeigen, wie wichtig es ist, sich mit den Besonderheiten einer Zero-Trust-Implementierung vertraut zu machen, um sich auf ihre potenziellen Auswirkungen auf ArcGIS-Komponenten vorzubereiten. Ein Ansatz zur Erreichung der Zero-Trust-Anforderungen mit ArcGIS besteht darin, den bestehenden Sicherheitsstatus des Systems zu berücksichtigen, bei dem alle Benutzeranforderungen einzeln durch ArcGIS-Token authentifiziert werden, was ein starker Mechanismus ist, und die Benutzeraktivitäten ausreichend zu validieren, um diesen Standard zu erreichen.
Eine gängige Technologie im Rahmen einer Zero-Trust-Architektur sind identitätsbewusste Proxys. Mit diesem Muster können zwar einige Ziele für browserbasierten Datenverkehr erreicht werden, aber der Zugriff von ArcGIS Pro oder mobilen Anwendungen auf ArcGIS Enterprise dürfte beeinträchtigt werden.