Der Begriff ‘Zero Trust’, der erstmals 2010 von Forrester geprägt wurde, bezeichnet einen neuen Sicherheitsansatz, bei dem die Vertrauenswürdigkeit jedes Geräts, jedes Benutzers und jeder Anwendung in einem Unternehmen kontinuierlich überprüft wird.
Vor dem Aufkommen des Zero-Trust-Konzepts verfolgten die meisten Sicherheitsteams einen “Trust, but verify”-Ansatz, bei dem der Schwerpunkt auf einem starken Verteidigungsperimeter lag. Dieses Modell geht davon aus, dass alles innerhalb des Netzwerkperimeters (einschließlich der Benutzer, Ressourcen und Anwendungen eines Unternehmens) vertrauenswürdig ist, sodass Sicherheitsteams diesen Benutzern und Ressourcen standardmäßig Zugriff und Berechtigungen gewährten. Im Gegensatz dazu musste alles außerhalb des Perimeters vor der Gewährung des Zugriffs überprüft werden.
Während die traditionelle Sicherheitsphilosophie lautet: “Vertrauen ist gut, Kontrolle ist besser”, lautet das Motto von Zero Trust: “Niemals vertrauen, immer kontrollieren.” Bei Zero Trust wird niemals wirklich etwas ‘freigegeben’. Stattdessen betrachtet Zero Trust alle Ressourcen als außerhalb des Unternehmensnetzwerks liegend und überprüft kontinuierlich Benutzer, Ressourcen, Geräte und Anwendungen, bevor nur das erforderliche Mindestmaß an Zugriff gewährt wird. Die Einrichtung eines Zero-Trust-Sicherheitsprogramms erfordert die Koordination mehrerer IT-Komponenten und einen ganzheitlichen Ansatz.
Wie hat sich das Zero-Trust-Konzept im Laufe der Zeit verändert?
Zero-Trust-Implementierungen haben sich im Laufe der Zeit weiterentwickelt. Trotz des eingängigen Namens müssen Unternehmen nicht unbedingt Zero-Trust-Absolutisten - Es wäre unpraktisch, wenn nicht sogar unmöglich, immer alles zu überprüfen.
Stattdessen hat sich Zero Trust von einem binären Konzept, bei dem nichts von Natur aus sicher ist und alles überprüft werden muss, zu einem weitaus differenzierteren und dynamischeren Ansatz entwickelt. Heute umfasst Zero Trust umfassendere Datensätze, Risikoprinzipien und dynamische, risikobasierte Richtlinien, um eine solide Grundlage für Zugriffsentscheidungen und die kontinuierliche Überwachung zu schaffen. Die Zero-Trust-Abwehr stützt sich auf eine Vielzahl von Quellen, darunter Bedrohungsinformationen, Netzwerkprotokolle, Endpunktdaten und andere Informationen, um Zugriffsanfragen und das Nutzerverhalten zu bewerten. NIST hat Dokumente veröffentlicht, in denen „Zero Trust“ befürwortet und dieser umfassendere, dynamischere Ansatz näher erläutert wird.
In letzter Zeit ist das Interesse an Zero Trust sprunghaft angestiegen, angetrieben durch Markttrends, die sich infolge der globalen Pandemie beschleunigt haben, darunter:
- Beschleunigte digitale Transformation (die Einführung neuer und aufkommender Technologien und Lösungen zur Modernisierung und Beschleunigung der geschäftlichen Interaktionen mit Kunden, Mitarbeitern und Partnern)
- Umstellung auf Cloud / SaaS
- Fernarbeit
- Ausdünnung von VPN-geschützten Vertrauenszonen (Netzwerkperimeter) und die Erkenntnis, dass Firewalls weniger nützlich sind, um Angriffe von innen zu erkennen und abzuwehren, und dass sie Objekte außerhalb des Unternehmensperimeters nicht schützen können
Früher wurde in den meisten IT-Umgebungen von Unternehmen das Vertrauen vor allem über den Standort hergestellt. Die Benutzer griffen von einem unternehmenseigenen Computer innerhalb des Unternehmensgeländes auf Unternehmensressourcen zu. Die physische Anwesenheit auf dem Firmengelände bedeutete, dass ein Benutzer die Anforderungen für die Überprüfung und Legitimierung erfüllt hatte, um Zugang zu den IT-Ressourcen des Unternehmens zu erhalten, die sich in der Regel in einem lokalen Rechenzentrum befanden. Die "vertrauenswürdige Zone" wurde durch zulässige (Schutz-)Technologien wie Firewalls, Intrusion Detection/Protection und andere Ressourcen geschützt.
Im Laufe der Zeit wurden die IT-Perimeter des Campus auf Außenstellen und Satellitenbüros ausgedehnt, wodurch die vertrauenswürdige Zone durch sichere, private Verbindungen zwischen den Standorten effektiv erweitert wurde. In den frühen 2000er Jahren, als neue Zugangsmethoden wie VPN und WiFi aufkamen, kamen neue Technologien hinzu Authentifizierung und die Zugangsberechtigung, um die relative Integrität des Perimeters zu wahren. Dazu gehörten Zwei-Faktoren-Authentifizierung (2FA) Token und den IEEE 802.1x Standard für portbasierte Netzwerkzugangskontrolle (NAC).
Die nachfolgenden Entwicklungen von Cloud Computing, Bring-your-own-device und Hypermobilität haben alles verändert. Unternehmen sind heute auf IT-Ressourcen angewiesen, die weit über die Grenzen einer einzigen vertrauenswürdigen Zone hinausgehen. Darüber hinaus benötigen Mitarbeiter, Partner und Kunden jetzt Zugang zu Systemen von jedem Ort, jeder Zeit und jedem Gerät aus. Die daraus resultierenden Schwachstellen und Sicherheitslücken läuteten eine neue Ära des Hackings ein, in der Sicherheitsverletzungen an der Tagesordnung sind. Der Perimeter von früher ist überholt.
Der Verfall der Perimetersicherheit ebnete den Weg für Zero Trust. Es ist jedoch bemerkenswert, dass das Konzept selbst im Jahr 2010 nicht völlig neu war. Während der Begriff “Zero Trust” neu war und Aufmerksamkeit erregte, ist die Frage, wie man in der von Natur aus nicht vertrauenswürdigen Welt des Internets Vertrauenswürdigkeit herstellen kann, bereits seit mehr als vier Jahrzehnten Gegenstand akademischer Forschung. Tatsächlich ging die Gründung von RSA vor fast vier Jahrzehnten auf wissenschaftliche Arbeiten aus den späten 1970er Jahren zurück, die sichere Kommunikation und Transaktionen in einem nicht vertrauenswürdigen Umfeld ermöglichten.
Als aus den Jahren Jahrzehnte wurden und der digitale Wandel die Wirtschaft und die Gesellschaft erfasste, entwickelten sich die Konzepte für Vertrauen weiter.
Zero Trust hat in den letzten Jahren stetig an Beliebtheit gewonnen. Die durch die COVID-19-Pandemie verursachten Umbrüche haben jedoch das Interesse an wie Unternehmen nach einer größeren Störung ihre Widerstandsfähigkeit aufbauen können.
Wie in den meisten anderen Jahren starteten Sicherheits- und Risikoverantwortliche in das neue Jahrzehnt mit ziemlich ausgefeilten Plänen zur Weiterentwicklung ihrer digitalen Risikomanagementverfahren. Der anfängliche Ausbruch von COVID-19 verlagerte jedoch den Schwerpunkt der Sicherheitsteams auf eher taktische Anforderungen, wie Befähigung von Fernarbeitern, Es ging darum, Änderungen in den Abläufen zu sichern, um die Geschäftsfunktionen aufrechtzuerhalten oder neue Chancen zu nutzen, die Risiken von Dritten und der Lieferkette neu zu bewerten, das Onboarding zu beschleunigen und vieles mehr. Budgets wurden gekürzt oder eingefroren, lange Listen anstehender Projekte wurden zunächst abgearbeitet, dann aber rasch beschleunigt. Die Teams sehen sich nun mit neuen digitalen Initiativen konfrontiert, die sich nicht unbedingt in komplexe, etablierte Sicherheits- und Risikoregelungen einfügen.
Zero Trust bietet eine Grundlage für einen zügigen und geprüften Ansatz für Unternehmen, die Mühe haben, mit dem Tempo der digitalen Transformation Schritt zu halten.
Im August 2020 veröffentlichte das NIST NIST Sonderveröffentlichung 800-207: Zero Trust Architektur, das die logischen Komponenten einer Zero-Trust-Architektur, mögliche Implementierungsszenarien und Bedrohungen umfasst. Außerdem enthält es einen allgemeinen Fahrplan für Organisationen, die die Zero-Trust-Prinzipien umsetzen möchten.
Im Folgenden werden Elemente der Architektur beschrieben und Produkte sowie Funktionen aus dem RSA-Portfolio kurz vorgestellt, die mit der Zero-Trust-Architektur im Einklang stehen.
Es folgen Beschreibungen der einzelnen Elemente (gemäß der Definition in NIST SP 800-207) mit zusätzlichen Verweisen auf RSA-Produkte und -Dienstleistungen, sofern zutreffend.
Policy Engine: Diese Komponente ist für die endgültige Entscheidung über die Gewährung des Zugangs zu einer Ressource für ein bestimmtes Subjekt verantwortlich. Die Policy Engine verwendet die Unternehmensrichtlinien sowie Informationen aus externen Quellen (z. B. CDM-Systeme, Bedrohungsinformationsdienste, die weiter unten beschrieben werden) als Input für einen Vertrauensalgorithmus, um den Zugriff auf die Ressource zu gewähren, zu verweigern oder zu widerrufen. Die Policy Engine ist mit der Policy Administrator Komponente gekoppelt. Die Policy Engine trifft die Entscheidung und protokolliert sie, und der Policy Administrator führt die Entscheidung aus.
RSA Rollen- und attributbasierter Zugang, bedingter Zugang und risikobasierte Analysen sind allesamt grundlegende Komponenten für die Einrichtung eines Entscheidungspunkts und einer Policy Engine.
Politischer Administrator: Diese Komponente ist für den Aufbau bzw. Abbau des Kommunikationspfads zwischen einem Subjekt und einer Ressource zuständig. Sie generiert alle Authentifizierungs- und Authentifizierungs-Token oder Berechtigungsnachweise, die von einem Client für den Zugriff auf eine Unternehmensressource verwendet werden. Sie ist eng mit der Policy Engine verbunden und verlässt sich auf deren Entscheidung, eine Sitzung letztendlich zuzulassen oder zu verweigern. In einigen Implementierungen werden die Policy Engine und der Policy Administrator als ein einziger Dienst behandelt. Der Richtlinienadministrator kommuniziert mit dem Policy Enforcement Point, wenn er den Kommunikationspfad erstellt. Diese Kommunikation erfolgt über die Steuerungsebene.
RSA bietet eine Reihe von Authentifizierungsmethoden und Benutzererfahrungen (z. B. Authentifizierungsauswahl, BYOA), um die Authentifizierung zu verwalten und den Zugriff zu bestimmen, wenn dies von der Durchsetzungsstelle der Richtlinie verlangt wird.
Policy Enforcement Point:
Dieses System ist dafür verantwortlich, Verbindungen zwischen einem Subjekt und einer Unternehmensressource zu ermöglichen, zu überwachen und schließlich zu beenden.
Dies ist eine einzelne logische Komponente in der Zero-Trust-Architektur, die jedoch in zwei verschiedene Komponenten unterteilt werden kann: die Client-Seite (z. B. ein Agent auf dem Laptop des Benutzers) und die Ressourcen-Seite (z. B. eine Gateway-Komponente vor der Ressource, die den Zugriff steuert) oder eine einzige Portal-Komponente, die als Gatekeeper für die Kommunikationswege fungiert. Hinter dem Punkt der Richtliniendurchsetzung befindet sich die implizite Vertrauenszone, in der die Unternehmensressource gehostet wird.
RSA-Produkte können sowohl Richtlinienentscheidungen bestimmen, die von Partner-Policy-Enforcement-Points (VPNs, Websites, Anwendungen usw.) durchgesetzt werden, als auch Richtlinien direkt an Endgeräten durchsetzen.
Die Multi-Faktor-Authentifizierung von SecurID® arbeitet mit einer Vielzahl von Partnergeräten zusammen (Desktops, Server, virtuelle Maschinen, Webserver, Portale, Netzwerkgeräte, Anwendungen usw.), um Benutzer zu authentifizieren und Zugriffsrechte festzulegen.
Richtlinien für den Datenzugang:
Dies sind die Attribute, Regeln und Richtlinien für den Zugang zu Unternehmensressourcen. Diese Regeln können in der Policy Engine kodiert oder von dieser dynamisch generiert werden. Diese Richtlinien sind der Ausgangspunkt für die Autorisierung des Zugriffs auf eine Ressource, da sie die grundlegenden Zugriffsrechte für Konten und Anwendungen im Unternehmen festlegen. Diese Richtlinien sollten auf den definierten Aufgabenrollen und Bedürfnissen des Unternehmens basieren.
SecurID® Verwaltung und Lebenszyklus ist ein idealer Ausgangspunkt für die Autorisierung des Zugriffs auf eine Ressource mit klarem Fokus auf Governance, Transparenz über strukturierte und unstrukturierte Daten sowie Analysen und Intelligenz, um sicherzustellen, dass die Prinzipien der geringsten Privilegien angewendet werden können.
Dieses System ist für die Erstellung, Speicherung und Verwaltung der Benutzerkonten und Identitätsdatensätze des Unternehmens zuständig (z. B. LDAP-Server). Dieses System enthält die erforderlichen Benutzerinformationen (z. B. Name, E-Mail-Adresse, Zertifikate) und andere Unternehmensmerkmale wie Rolle, Zugriffsattribute und zugewiesene Assets. Dieses System nutzt oft andere Systeme (z. B. eine PKI) für Artefakte, die mit Benutzerkonten verbunden sind. Dieses System kann Teil einer größeren föderierten Gemeinschaft sein und kann Mitarbeiter außerhalb des Unternehmens oder Links zu unternehmensfremden Assets für die Zusammenarbeit einschließen.
RSA Identitätslösungen lassen sich in alle gängigen Identitätsmanagementsysteme (z. B. Microsoft AD / Azure AD / AWS AD) integrieren, um Identitäten nahtlos mit den Richtlinien, Verwaltungsfunktionen und Verfahren zu verknüpfen, die für das Funktionieren einer Zero-Trust-Architektur erforderlich sind.
Bedrohungsdaten:
Diese liefern Informationen aus internen oder externen Quellen, die der Policy Engine helfen, Zugangsentscheidungen zu treffen. Dabei kann es sich um mehrere Dienste handeln, die Daten aus internen und/oder mehreren externen Quellen übernehmen und Informationen über neu entdeckte Angriffe oder Schwachstellen liefern. Dazu gehören auch schwarze Listen, neu identifizierte Malware und gemeldete Angriffe auf andere Ressourcen, auf die das Richtlinienmodul den Zugriff von Unternehmensressourcen verweigern möchte.
RSA IAM nutzt interne und externe Signale, um die Sicherheit zu erhöhen (positive Signale) und Bedrohungen zu identifizieren (negative Signale). So können beispielsweise interne Signale wie Benutzerhistorie, Verhaltensanalyse, IP-Adresse, Netzwerk und Standort Faktoren sein, um risikobasierte Authentifizierungs- und Zugriffsentscheidungen zu treffen.
###
Probieren Sie die Demo aus!
Testen Sie die ID Plus Cloud-Multifaktor-Authentifizierungslösung (MFA) - eines der sichersten Produkte auf dem Markt und die weltweit am häufigsten eingesetzte MFA-Lösung. Finden Sie heraus, warum: Melden Sie sich für unsere kostenlose 45-Tage-Testversion an.
