Netzwerkzugangskontrollen (NAC) auf Basis von IEEE 802.1X stehen seit Jahren bereit. Viele Unternehmen und Behörden scheuen jedoch die Einführung. Dies liegt sowohl an der komplexen Inbetriebnahme und dem Management solcher Systeme als auch den zugehörigen Prozessen auf den Clientsystemen. Dazu zählt beispielsweise die Verteilung von Zertifikaten zur Client-authentifizierung, deren Rückruf und Überwachung der Ablaufdaten.

Zahlreiche Anbieter wollen die Komplexität mit cloudbasierter NAC vereinfachen. Jedoch sind viele IT-Sicherheitsverantwortliche skeptisch, da Ausfälle von NAC-Systemen erhebliche Auswirkungen auf den Geschäftsbetrieb haben können. Bei einer Störung der Internetanbindung steht zudem bei Cloudsystemen logischerweise kein NAC zur Verfügung. Für Cloud-Only-Organisationen, die sowieso komplett abhängig von Onlinediensten sind, stellt dies kein entscheidendes Entscheidungskriterium dar, denn die Internetanbindung ist sowieso ein geschäftskritischer Baustein. Daher muss sie entsprechend den Verfügbarkeitsanforderungen mit dem passenden Redundanzkonzept ausgelegt sein.

Falls jedoch auch lokale Dienste während eines Ausfalls der Internetanbindung zur Verfügung stehen sollen, braucht es ein Fail-Open-Konzept der Netzwerkkomponenten wie Switches oder WLAN-Access-Points. Soll wiederum aus Sicherheitsgründen bei einem Ausfall der NAC überhaupt kein Zugriff gegeben sein, erfordert das Design für die NAC-Prozesse entsprechend ein Fail-Safe, also eine Ablehnung bei fehlender Erreichbarkeit des NAC. Dazu sei jedoch fairerweise zu sagen, dass Admins diese Prozesse auch beim Ausfall lokaler Systeme betrachten müssen.

Andere IT-Verantwortliche zweifeln an der Sicherheit der Übertragung von Authentifizierungs- und Autorisierungsdaten. Dies liegt daran, dass native RADIUS-Übertragungen im Standard unverschlüsselt über UDP stattfinden. Die Daten sind mit einem symmetrischen Schlüssel (Shared Secret) authentifiziert. Somit könnte ein Angreifer potenziell sowohl Credentials mitlesen als auch die Autorisierungsentscheidungen manipulieren.

AGNI basiert auf einer cloudnativen Microservice-Architektur und besaß in der uns bereitgestellten Beta-Version den KI-Assistenten AVA. Neben Arista-Netzwerkkomponenten kann der Admin auch solche von Aruba, Cisco und Cisco Meraki anbinden. Zudem integriert es sich in das WLAN-Management "CV-CUE" und in CVaaS (CloudVision-as-a-Service) für die Verwaltung von Arista-Switches und -Routern, um Geräte- und Nutzerdaten mit entsprechendem Kontext auszutauschen.

Das Produkt soll laut Hersteller möglichst einfach und auf die Kernfunktionen fokussiert sein. Neben den Authentifizierungs- und Autorisierungsfunktionen bietet es vorbereitete Onboarding-Prozesse. Hierzu stehen eine integrierte PKI und Prozesse für Massenprovisionierung sowie ein Selbst-Registrierungsprozess für Unique Pre-shared Keys (UPSK) bereit – hierzu später mehr. DHCP, DNS und HTTP-Agenten erlauben ein sogenanntes Fingerprinting, um beispielsweise das Client-Betriebssystem von Endgeräten zu ermitteln. Auch eine Integration mit Aristas Network Detection and Response (NDR) als auch mit Drittanbieter-XDR-Diensten ist möglich.

Neben den NAC-Funktionen liefert AGNI über ein sogenanntes Cloud-Gateway auch die Möglichkeit, die Authentication-, Authorisation- und Accounting (AAA)-Dienste zur Administration von Netzwerkkomponenten über TACACS+ zu steuern. Dieses Cloud-Gateway kommt in Kombination mit dem RADIUS-Proxy auch für die lokalen Geräte ohne RadSec-Unterstützung zum Einsatz.

Der initiale Zugriff auf AGNI erfolgt über das sogenannte "WiFi Launchpad" im Internet und nach einem Klick auf das AGNI-Symbol über Single Sign-on (SSO). Ein dedizierter Login steht nicht bereit. Das initiale Dashboard gibt Auskunft über die Anzahl der eingerichteten Benutzer, der Endgeräte und der Netzwerkkomponenten wie Switches und WLAN-Access-Points. Zudem gibt es auch eine grafische Übersicht über die aktiven Sessions und die häufigsten Fehlergründe samt der Standorte, die davon betroffen sind. Der Menübaum befindet sich links und gliedert sich in die Unterpunkte Monitoring, Access Control, Identity, Configuration und Concourse.

Der RADIUS-Dienst stellt die Kernaufgabe von NAC dar und ermöglicht es, den Zugriff auf das Netzwerk zu steuern. Die entsprechend notwendige TLS-verschlüsselte Anbindung der Switche erklären wir im nächsten Abschnitt. In AGNI muss der Admin für NAC zunächst im Bereich "Access Control / Networks" ein verkabeltes oder drahtloses Netzwerk mit der gewünschten Authentifizierungsmethode anlegen. Hierzu stehen Varianten mit Clientzertifikaten (EAP-TLS), MAC-Authentifizierung oder Captive-Portal bereit. Im Fall von drahtlosen Netzen auch noch UPSK, um mit individuellen Pre-shared Keys (PSKs) je Client arbeiten zu können. Arista ist derzeit der einzige Anbieter, der WPA3 mit individuellen PSKs je Client unterstützt. Bei drahtlosen Netzwerken braucht es zudem das Hinterlegen der SSID, für die der Authentifizierungsdienst bereitsteht. Somit entfallen lange Suchen nach den richtigen RADIUS-Attributen für drahtlose oder verkabelte Netze sowie der Differenzierung der SSID, wie es bei klassischen NAC-Systemen üblich ist.

Neben reinem "Erlauben" und "Verbieten" bietet AGNI im Menüpunkt "Access Control / Segments" auch detailliertere Regelwerke beziehungsweise Richtlinien. So kann anhand von Attributen des Netzwerks (Name oder Authentifizierungsmethode), des Clients oder der Netzwerkkomponente, die die Authentifizierung an AGNI sendet, eine Entscheidung über die Autorisierung fallen. Dergestalt ist AGNI in der Lage, den Zugriff auf das Netzwerk zu erlauben oder zu verbieten als auch VLANs oder dynamische ACLs zuzuweisen. Diese Richtlinien kann der Admin beispielsweise auch je Lokation oder Zugriffspunkt unterschiedlich gestalten, um sensitive örtliche Bereiche oder kritische Netzwerke besonders zu schützen.

Aber auch Aufteilungen nach Nutzergruppen, wie beispielsweise Steuerung von Zugriffen auf Serverressourcen, sind auf diese Weise möglich. Beispielsweise erhalten Mitarbeiter der Personalabteilung Zugriff auf Server mit Mitarbeiterdaten, wohingegen die Forschungsabteilung auf diese keine Berechtigung erhält. So erfolgt eine dynamische Segmentierung des Netzwerks. Dynamische ACLs muss der Systemverwalter zuvor jedoch unter "Access Control / ACLs" anlegen.

Im Gegensatz zu anderen On-Premises-Produkten sind in AGNI jedoch nur Prüfungen gegen alle definierten Bedingungen ("Match All") möglich, eine "Oder"- Verknüpfung hingegen nicht. Dies lässt sich aber über multiple, aneinandergereihte Regeln erreichen. Allerdings kann der AGNI-Admin Regeln auch temporär deaktivieren oder in den sogenannten "Monitor Modus" schalten, um nur das "Matching" zu prüfen. Aktionen wie VLAN-Zuweisungen ignoriert AGNI dabei zunächst. Die Latenz beim initialen Zugriff auf das Netzwerk war bei unseren Tests zwar merkbar, aber nicht produktiv relevant.

Bevor Switches oder Access Points Authentifizierungen an AGNI übersenden können, muss zunächst eine RadSec-Verbindung bestehen. Dafür bedarf es zunächst einer gegenseitigen TLS-Authentifizierung (mTLS) zwischen der Netzwerk- komponente und AGNI. Die jeweilige Netzwerkkomponente baut dann einen TCP-Socket über Port 2083 und folglich einen TLS-Tunnel zu AGNI auf. Über diesen können die Switches oder APs dann Authentifizierungsanfragen senden.

Um Geräte ohne RadSec-Unterstützung an AGNI anzubinden, installiert der Admin auf Arista-Switches eine Erweiterung – das Cloud-Gateway. Dieses baut dann eine TLS-verschlüsselte Verbindung zu AGNI auf. Auf dem Switch, auf dem die Cloud-Gateway-Funktion aktiviert ist, muss zudem das RADIUS-Proxy-Feature eingeschaltet sein. Zusätzlich ist das Einrichten aller potenziellen RADIUS-Clients erforderlich, die den RADIUS-Proxy nutzen möchten, also Access Points oder Switches, die unverschlüsselte Anfragen an den RADIUS-Proxy senden. Die Geräte können dann per unverschlüsseltem RADIUS mit dem Cloud-Gateway kommunizieren und dieses wiederum über RadSec mit AGNI. Dies macht die Administration jedoch etwas unübersichtlich, da diese mehrteilig auf Switches und AGNI erfolgt. Die Konfigurationen lassen sich aber mit CloudVision beziehungsweise CVaaS weitestgehend automatisiert erstellen und netzwerkweit verwalten.

Im Fall von Netzwerkkomponenten, die RadSec direkt unterstützen, muss der Admin diese zunächst in AGNI einbinden und gruppieren. Dies kann er manuell mit Hostname, MAC-Adresse und Seriennummer vornehmen. Im Nachgang können noch Lokationsdaten und logische Gruppen von Geräten hinterlegt werden. Auch ein CSV-Import von mehreren Geräten steht bereit. Bei der Integration in Aristas WLAN Management "CV-CUE" erscheinen die Access Points ohne manuelle Konfiguration direkt in AGNI.

Nach dem Eintragen der einzelnen Komponenten lädt der Admin das jeweils zugehörige Clientzertifikat für die Authentifizierung des Switches an AGNI als PKCS12-Datei herunter. Alternativ bietet AGNI das Einreichen eines Certificate Signing Requests (CSR) in Textform an. Das signierte Zertifikat muss der IT-Verantwortliche im Nachgang zusammen mit dem Root-Zertifikat von AGNI auf dem Switch importieren.

Dazu braucht es auf Switches etwas Handarbeit auf der Kommandozeile. Der Aufwand hält sich jedoch in Grenzen und Arista hat dies auch gut dokumentiert. Wir haben in Listing 1 dargestellt, wie die Anbindung an AGNI über RadSec erfolgt: Wir generieren im ersten Schritt einen privaten RSA-4096-Bit-Schlüssel und darauf folgend einen CSR. Als Common Name muss die MAC-Adresse des Switches zum Einsatz kommen und der DNS-Name im Zertifikat muss mit dem Hostnamen des Switches übereinstimmen. Den generierten CSR kopieren wir in AGNI und lassen ihn dort signieren. Im Anschluss laden wir den signierten öffentlichen Schlüssel und das Root-CA-Zertifikat von AGNI herunter und kopieren beide Bestandteile über SCP oder einen USB-Stick auf den Switch. Nachdem die Zertifikate auf dem Switch vorliegen, muss der Netzwerkadmin diese noch in den Zertifikatsstore kopieren. Sobald alle Zertifikate bereitstehen, braucht es noch ein TLS-Profil, das das Root-CA-Zertifikat und das Clientzertifikat inklusive privatem Schlüssel referenziert.

Erst nachdem das Zertifikat und das TLS-Profil vorliegen, parametrisieren wir die eigentliche RadSec-Verbindung und bauen diese im Nachgang auf (Listing 2). Im Anschluss können wir den RadSec Verbindungsstatus in AGNI unter "Configuration / Access Devices / Devices" prüfen.

WLAN-Access-Points, die über CV-CUE administriert werden, gelangen nach Integration von CV-CUE als "Concourse App" automatisch in AGNI und bauen eine RadSec-Verbindung auf. Nun geht es an die Aktivierung von 802.1X auf dem Switch und gezielt auf einzelnen Ports. Ein entsprechendes Beispiel zeigt Listing 3.

Im Anschluss können sich Clients gemäß den eingerichteten Netzwerken und Segmentierungsrichtlinien an einem Switchport authentifizieren. In unserem Test funktionierte eine EAP-TLS Authentifizierung mit einem von AGNI ausgestellten Zertifikat für die Clientauthentifizierung problemlos. Auf Basis einer erfolgreichen Authentifizierung kann AGNI dann auch DHCP, DNS und HTTP-Agenten heranziehen, um ein Profiling durchzuführen. Konkret erkennt AGNI beispielsweise also das Betriebssystem des Clients. Auf Basis dieser Daten lassen sich weitere Segmentierungsregeln erstellen.

Anwender muss der Admin in AGNI zunächst angelegen. Dies kann im einfachsten Fall lokal geschehen, ein CSV-Import ist jedoch nicht möglich, dafür lassen sich Nutzer gruppieren. Dies kann hilfreich sein, um darauf aufbauende Segmentierungsregeln zu erstellen, also beispielsweise einer Administratorengruppe ein dediziertes VLAN zuzuweisen.

Einfacher geht dies insbesondere bei einer größeren Anzahl an Nutzern über die Integration von externen Identitätsprovidern. Hierzu stehen Microsoft Entra ID, Google Workspace, Okta und OneLogin bereit. Darüber lassen sich die Nutzer authentifizieren und synchronisieren. Eine Schnittstelle an ein lokales Active Directory oder andere LDAP-basierende Verzeichnisdienste steht aktuell noch nicht zur Verfügung, ist jedoch laut Hersteller in der Entwicklung. Dies kann ein entscheidendes Kriterium gegen ein Cloud-NAC darstellen.

Zertifikate stellen noch immer das Maß der Dinge im Bereich der Authentifizierung dar. Eine Kernaufgabe bei der NAC-Implementierung besteht also darin, den Zertifikatslebenszyklus mit Ausstellen, Sperren und Erneuern abzubilden. Hierfür bietet AGNI eine integrierte und vorbereitete PKI. Diese kommt im ersten Schritt bereits bei der Anbindung der Netzwerkkomponenten über RadSec zum Einsatz. Dies ist notwendig, da RadSec eine gegenseitige (Mutual) TLS-Authentifizierung einsetzt. Zertifikate kann der Admin, wie bereits beschrieben, entweder direkt inklusive Private Key auf AGNI generieren oder als CSR einreichen, wobei bei dieser Variante der Private Key auf dem Endgerät verbleibt. Zudem besteht die Möglichkeit des Imports eines ZIP-Archivs mit mehreren CSRs, um eine Massenprovisionierung zu vereinfachen.

Auch eigene Zertifizierungsstellen lassen sich über den Import der entsprechenden CA-Zertifikate als Typ "External" im PEM-Format einbinden. AGNI bietet zudem die Parametrisierung von Zertifikatswiderruflisten (CRLs), wobei jedoch Optionen zum Fehlerhandling und Abrufintervallen fehlen. Der Hersteller teilte auf Nachfrage jedoch mit, dass dies bereits auf der Roadmap ist. Auch die Gültigkeitszeiträume für die Zertifikate sind vordefiniert und lassen sich nicht parametrisieren. Clientauthentifizierungszertifikate sind beispielsweise ein Jahr gültig, Serverauthentifizierungszertifikate drei, ausstellende CAs fünf und Root-CAs zehn Jahre. Dies erscheint für größere Umgebungen nur bedingt geeignet. Eine SCEP-Schnittstelle (Simple Certificate Enrollment Protocol) steht über Intune und JAMF zur Verfügung.

Viele Geräte unterstützen jedoch kein EAP-TLS mitsamt dem Import von Clientzertifikaten. Insbesondere Geräte im IoT-Umfeld sind hierfür bekannt. Zudem unterstützen diese oftmals nur WLAN als Schnittstelle. Captive-Portale (dazu gleich mehr) können in diesem Fall meist ebenfalls nicht zum Einsatz kommen, da die Bestätigung im Browser nicht möglich ist. Als Rückfallebene nutzen viele Administratoren eine Pre-shared-Key-Variante (PSK). Ist dieser PSK jedoch kompromittiert, müssen bei einem Wechsel alle Geräte neue PSKs erhalten. Zudem könnte ein Angreifer potenziell auch den Datenverkehr von anderen Geräten in Kenntnis des PSKs mitlesen oder über die "Teilen"-Funktion von Smart-phones verbreiten.

Um auf Basis einer WLAN-SSID mit unterschiedlichen PSKs je Nutzer arbeiten zu können, bieten viele Hersteller sogenannte MPSK- oder UPSK-Varianten an. Jedoch unterstützt nur die von Arista die Kombination mit WPA3. Auch die maximale Anzahl der Clients je UPSK ist in AGNI einstellbar. Zudem kann das Cloud-NAC die Kommunikation zwischen Clients mit unterschiedlichen UPSKs unterbinden, sodass beispielsweise die Zeiterfassung im WLAN nicht mit der smarten Kaffeemaschine kommunizieren kann. Es gibt ferner eine Möglichkeit für sogenannte "Shared Devices", also beispielsweise, um Drucker mit UPSK allen anderen Clients bereitzustellen, obwohl diese ansonsten nicht untereinander kommunizieren können.

Klassische NAC-Systeme liefern häufig zur Steuerung der Geräteadministration auch TACACS+-Serverfunktionalitäten (Terminal Access Control Access Control Server) mit, um Konfigurationsbefehle auf aktiven Netzwerkkomponenten, wie Switches, Routern oder WLAN-Controllern, authentifizieren und autorisieren zu können. Dies bringt im Gegensatz zu RADIUS den Vorteil, dass AGNI selbst einzelne Befehle anhand sogenannter Command-Sets und Privilegienlevel dediziert autorisieren kann. TACACS+ verschlüsselt die Anfragen und Antworten im Header und Body mit einem Shared Secret. Jedoch erfolgt dies auf Basis einer unsicheren MD5-Hashing-Funktion. Somit ist dieses Verfahren absolut nicht für die Anbindung an Clouddienste geeignet.

Nun ließe sich klassisches IPSec zur Verschlüsselung auf IP-Ebene zwischen aktiver Netzwerkkomponente und Cloud-NAC einsetzen. Dies bringt jedoch einen nicht unerheblichen Aufwand und Komplexität in der Implementierung mit sich, da der IT-Verantwortliche dies dediziert mit den entsprechenden Versionen und Ciphers auf beiden Seiten konfigurieren müsste.

Daher setzt Arista, wie auch bereits beim RADIUS-Proxy, auf das Cloud-Gateway für TACACS+. Dieses kann der Arista-Admin als Swix-Erweiterung, also einem Image, auf einem Arista-Switch nachinstallieren. Für Redundanzzwecke sind auch multiple Cloud-Gateways auf unterschiedlichen Switches denkbar. Die Installation ist sehr einfach: In AGNI ist nur das Generieren eines Tokens erforderlich, das beim Installieren der Erweiterung an den Switch übergeben wird. Im Anschluss koppelt sich der Switch direkt mit AGNI. Das Cloud-Gateway baut in diesem Fall eine WebSocket-Verbindung über HTTPS, also eine Transportverschlüsselung mit TLS, zu AGNI auf, um eine bidirektionale Kommunikation zwischen AGNI und dem Switch zu ermöglichen. TACACS+-Anfragen und Antworten kapselten die Komponenten folglich in HTTP und übertrugen diese über den TLS-Tunnel.

Neben den Kern- und Zusatzfunktionen gibt es bei NAC-Systemen und TACACS+-Servern Features, um auf Fehlverhalten oder Sicherheitsereignisse zu prüfen. Dies ist notwendig, um bei entsprechenden Audits, wie beispielsweise im Rahmen von Sicherheitszertifizierungen oder -vorfällen, entsprechende Daten vorlegen zu können.

So zeigt AGNI unter dem Menüpunkt "Monitoring / Sessions" bestehende und historische Sessions an. Diese lassen sich auch nach dem aktuellen Status und der Authentifizierungsmethode filtern. Bei aktiven Sessions bietet AGNI auch die Möglichkeit eines Session-Disconnects über einen sogenannten Change of Authorization (CoA), wie es auch andere Produkte anbieten. Mit einem Klick auf die jeweilige Session gelangt der Admin zu den Session-Details. Darin erhält er einen Überblick der MAC- und IP-Adressen, Authentifizierungszeiten, angewandte Segmentierungs- und Autorisierungsregeln sowie die authentifizierende Netzwerkkomponente wie Switch- oder Access-Point-Name.

Selbst Session-Logs sind direkt unter der Session einsehbar, um bei eventuell notwendigem Troubleshooting unterstützen zu können. Die Session-Daten stehen für die letzten 30 Tage bereit. Eine Exportfunktion von Reports gibt es nicht. Hierfür kann jedoch die API oder die Integration mit Drittsystemen heran gezogen werden. Zudem steht unter dem Punkt "System / Audit Viewer" auch ein Audit-Log mit den durchgeführten Konfigurationsanpassungen bereit.

NAC-Systeme stellen grundsätzlich Authentifizierung und Autorisierung bereit. Jedoch braucht es in vielen Fällen noch zusätzlich Optionen zum Verteilen der Authentifizierungsinformationen, wie beispielsweise bei Zertifikaten oder Optionen beispielsweise zur Sperrung von kompromittierten Endgeräten. Hierzu sind Drittanbieterintegrationen vonnöten. Jedoch differenziert sich in vielen Fällen genau in diesem Bereich die Entscheidungsfindung zwischen cloudbasierten Systemen und Cloud-NAC.

Stehen bei einem Cloud-NAC beispielsweise Schnittstellen zur lokalen PKI-Architektur, dem Mobile Device Management (MDM) oder zur Firewall nicht bereit, kann dies ein Ausschlusskriterium sein.

AGNI hat eine Integration mit dem MDM-System JAMF an Bord. Hierüber besteht die Möglichkeit, EAP-TLS-Zertifikate für die Clientauthentifizierung über die integrierte PKI und das Simple Certificate Enrollment Protocol auf verwaltete Endgeräte zu verteilen. Gleiches kann auch über Microsoft Intune geschehen. Zudem kann AGNI Clientattribute und den Compliance-Status zu Organisationsrichtlinien abfragen und diese für Segmentierungsentscheidungen heranziehen.

Auch PaloAltos Cortex XDR lässt sich an AGNI anflanschen. So kann AGNI über Cortex den sogenannten Posture-Status, also von Validierungen, abfragen und ebenfalls für die Segmentierung nutzen. Auch eine Integration mit dem SIEM-System Splunk ist möglich, was AGNI erlaubt, die Nutzeridentität, die IP-Adresse, das Endgerät und Session-Details der eingehenden Authentifizierungsanfragen an Splunk zu senden. Es bleibt abzuwarten, ob diese Zusammenarbeit nach der Übernahme von Splunk durch Cisco weiterhin gepflegt wird. Alternativ stehen gleiche Funktionalitäten auch für das Open-Source-SIEM von Sumo Logic bereit.

Das eigene Ökosystem von Arista lässt sich natürlich tief in AGNI integrieren. Zu Aristas CloudVision Cognitive Unified Edge (CV-CUE) als integrierte Verwaltungsplattform mit Automatisierungs- und Sicherheitslösung für drahtlose Netze oder das Monitoring von kabelgebundenen Netzwerkinfrastrukturen bietet es entsprechend eine sogenannte Concourse Application zur Nachinstallation. So lassen sich beispielsweise WLAN-Details zwischen AGNI und CV-CUE synchronisieren.

Aber auch die große Management-Plattform CloudVision lässt sich anbinden. Dies bietet die Option, Details von verwalteten Switches wie MAC-Adressen und Netzwerkgerätenamen zu synchronisieren. Auch das Network Detection and Response (NDR) von Arista bietet Verknüpfungen zu AGNI, um risikobasierende Segmentierungsrichtlinien darzustellen. So lassen sich beispielsweise Endgeräte bei kritischen Status sperren. Die Richtlinien basieren auf dem Gerätehersteller, dem Gerätetyp und dem Risikostatus.

AGNI bietet zudem eine gut dokumentierte JSON-basierte API auf Basis von Open-API 3.0. Der API-first-Ansatz ermöglicht eine nahtlose Zusammenarbeit mit Produkten von Drittanbietern und zudem den Austausch von Benutzer- und Clientkontext, Authentifizierungs-Telemetrie und Endgerätestatus. Über die API können Entwickler aber auch eigene Managementapplikationen und Prozesse an AGNI anbinden.

Gerade bei einer geringen Anzahl von Clients kann ein Cloud-NAC die Hürde für den NAC-Einstieg senken. Inwiefern sich dieses für ein Unternehmen eignet, hängt aber auch von dessen Architektur der Identitätsservices und der Verortung von produktiv genutzten Diensten ab. Setzt die Organisation als Identitätsprovider cloudbasierte Systeme wie EntraID ein und hat bisher keine eigene PKI-Architektur, stellt Cloud-NAC eine interessante Option dar. Kommen jedoch lokale Identitätsdienste wie das Active Directory zum Einsatz, stellt ein klassisches On-Premises-NAC jedoch die bessere Wahl dar, um die benötigten Schnittstellen zu bieten. Der nicht zu unterschätzende administrative Aufwand für die Bereitstellung und Pflege für den Admin sinkt im Fall von AGNI nämlich immens.