Der von Forrester im Jahr 2010 erstmals geprägte Begriff Zero Trust" bezieht sich auf einen neuen Sicherheitsansatz, der auf der kontinuierlichen Überprüfung der Vertrauenswürdigkeit jedes Geräts, jedes Benutzers und jeder Anwendung in einem Unternehmen beruht.
Vor dem Zero-Trust-Konzept verließen sich die meisten Sicherheitsteams auf einen "Trust but Verify"-Ansatz, bei dem ein starker defensiver Perimeter im Vordergrund stand. Bei diesem Modell wird davon ausgegangen, dass alles innerhalb des Netzwerkrands (einschließlich der Benutzer, Ressourcen und Anwendungen eines Unternehmens) vertrauenswürdig ist, so dass die Sicherheitsteams diesen Benutzern und Ressourcen standardmäßig Zugriff und Berechtigungen gewähren. Im Gegensatz dazu musste alles, was sich außerhalb des Netzwerks befand, erst geprüft werden, bevor der Zugriff gewährt wurde.
Während bei der traditionellen Sicherheit gilt: "Vertraue, aber überprüfe", heißt es bei Zero Trust: "Vertraue nie, überprüfe immer". Zero-Trust-Sicherheit gibt niemals wirklich etwas "frei". Stattdessen werden bei Zero Trust alle Ressourcen als außerhalb des Unternehmensnetzwerks stehend betrachtet, wobei Benutzer, Ressourcen, Geräte und Anwendungen kontinuierlich überprüft werden, bevor nur das erforderliche Mindestmaß an Zugriff gewährt wird. Die Einrichtung eines Zero-Trust-Sicherheitsprogramms erfordert die Koordination mehrerer IT-Komponenten und einen umfassenden Ansatz.
Wie hat sich das Konzept des Nullvertrauens im Laufe der Zeit verändert?
Zero-Trust-Implementierungen haben sich im Laufe der Zeit verändert. Trotz des eingängigen Namens müssen Organisationen nicht Null Vertrauen Absolutisten - Es wäre unpraktisch, wenn nicht sogar unmöglich, immer alles zu überprüfen.
Stattdessen entwickelte sich Zero Trust von einem binären Konzept, bei dem nichts von Natur aus sicher ist und alles überprüft werden muss, zu einem viel differenzierteren und dynamischeren Konzept. Heute umfasst Zero Trust umfassendere Datensätze, Risikoprinzipien und dynamische, risikobasierte Richtlinien, um eine solide Grundlage für Zugriffsentscheidungen und eine kontinuierliche Überwachung zu schaffen. Die Zero-Trust-Verteidigung stützt sich auf eine Vielzahl von Quellen wie Bedrohungsdaten, Netzwerkprotokolle, Endpunktdaten und andere Informationen, um Zugriffsanfragen und Benutzerverhalten zu bewerten. NIST hat Dokumente veröffentlicht, in denen sie sich für ein Null-Vertrauen ausspricht und diesen umfassenderen, dynamischeren Ansatz ausweitet.
In jüngster Zeit hat das Interesse an Zero Trust stark zugenommen, was auf Markttrends zurückzuführen ist, die sich infolge der weltweiten Pandemie beschleunigt haben:
- 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.
Die Aushöhlung 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 Name "Zero Trust" neu war und Aufmerksamkeit erregte, ist die Aufgabe, wie man in der von Natur aus nicht vertrauenswürdigen Welt des Internets Vertrauenswürdigkeit herstellen kann, bereits seit mehr als vier Jahrzehnten Thema der akademischen Forschung. Tatsächlich geht die Gründung von RSA vor fast vier Jahrzehnten auf akademische Arbeiten in den späten 1970er Jahren zurück, die sichere Kommunikation und Transaktionen in einem nicht vertrauenswürdigen Raum 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 immer mehr an Popularität gewonnen. Die durch die COVID-19-Pandemie ausgelösten Störungen 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 sinnvollen und geprüften Ansatz für Unternehmen, die mit dem Tempo der digitalen Transformation nicht Schritt halten können.
Im August 2020 veröffentlichte das NIST NIST Sonderveröffentlichung 800-207: Zero Trust Architektur, die logischen Komponenten einer Zero-Trust-Architektur, mögliche Entwurfsszenarien und Bedrohungen enthält. Außerdem wird ein allgemeiner Fahrplan für Organisationen vorgestellt, die die Zero-Trust-Prinzipien verfolgen wollen.
Im Folgenden werden Elemente der Architektur beschrieben und Produkte und Funktionen im RSA-Portfolio, die mit der Zero-Trust-Architektur übereinstimmen, kurz skizziert.
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.
In der Zero-Trust-Architektur ist dies eine einzige logische Komponente, die jedoch in zwei verschiedene Komponenten unterteilt werden kann: die Client- (z. B. Agent auf dem Laptop des Benutzers) und die Ressourcenseite (z. B. Gateway-Komponente vor der Ressource, die den Zugang kontrolliert) oder eine einzelne Portalkomponente, die als Gatekeeper für die Kommunikationspfade fungiert. Hinter dem Punkt der Richtliniendurchsetzung befindet sich die implizite Vertrauenszone, in der die Unternehmensressource untergebracht ist.
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 bekannten Identitätsmanagementsysteme (z. B. Microsoft AD / Azure AD / AWS AD) integrieren, um Identitäten nahtlos mit Richtlinien, Verwaltung und Methoden zu verbinden, 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.
