Zero Trust - Vertraue nie, überprüfe immer

Im Mai 2021 unterzeichnete Präsident Joe Biden eine Exekutivanordnung zur Einführung des Zero Trust-Sicherheitsmodells für föderierte Behörden. Dies ist für die US-Regierung zu einer der wichtigsten Prioritäten geworden. Föderierte Behörden haben bis September 2024 Zeit, das Zero Trust-Modell umzusetzen. Die Vereinigten Staaten haben aus erster Hand erfahren, wie die Cyber-Bedrohungen immer raffinierter werden. Im Mai 2021 wurde die Colonial Pipeline, eine amerikanische Ölpipeline, Opfer eines Ransomware-Angriffs, der zu einem sechstägigen Stillstand führte. Der Angriff führte zu Treibstoffengpässen, Flugverschiebungen, Tankstellen, denen der Treibstoff ausging, und in die Höhe schießenden Treibstoffpreisen.

Ende 2020 wurde auch SolarWinds, ein Systemmanagement-Tool zur Überwachung von Netzwerken und Infrastrukturen, gehackt. Es wurde eine Hintertür in das System eingeschleust, die es den Hackern ermöglichte, in die Netzwerke von Tausenden von Organisationen einzudringen, darunter auch von Bundesbehörden. Das Ausmaß des Hacks war enorm und machte ihn zum größten jemals identifizierten Hack. Der SolarWinds-Hack war ein großer Weckruf für die US-Regierung und führte zur Einführung des Zero-Trust-Sicherheitsmodells als Reaktion darauf.

Was ist Zero Trust?

Zero Trust ist ein Sicherheitsmodell, das auf dem Prinzip "never trust, always verify" basiert. Das bedeutet, dass alle Benutzer, Geräte und Anwendungen überprüft werden müssen, bevor ihnen Zugang zum Netzwerk gewährt wird. Zero Trust ist kein Produkt, das man kaufen kann, sondern eher eine Strategie zur Sicherung von Lösungen. Einige Produkte, wie z.B. Azure, können jedoch zur Implementierung von Zero Trust verwendet werden. John Kindervag entwickelte das Modell im Jahr 2010, aber es dauerte fast ein Jahrzehnt, bis es von der Branche angenommen wurde. Dies war auf eine Kombination von Faktoren zurückzuführen, darunter die Verlagerung auf mobile und Cloud-Lösungen und die Professionalisierung der Internetkriminalität.

Traditionell würden wir eine Firewall vor unser Netzwerk stellen und implizites Vertrauen innerhalb unseres Netzwerks nutzen.

Warum brauchen wir Zero Trust

Die Zeiten haben sich geändert, und wir haben eine dynamischere Arbeitsweise angenommen. Insbesondere nach Covid haben sich die Menschen von der Büroarbeit auf die Arbeit von zu Hause verlagert. Das bedeutet, dass die Menschen von ungesicherten öffentlichen Netzwerken aus auf Arbeitslasten zugreifen und verschiedene Geräte wie Handys oder Tablets verwenden. Folglich sollten die Anwendungen nicht nur über das Unternehmensnetzwerk verfügbar sein. Früher gab es nur einen einzigen Zugangspunkt für Anwendungen innerhalb des Netzwerks. Heutzutage ist das nicht mehr möglich, und wir haben uns von einem geschlossenen Perimeter entfernt. Das hat dazu geführt, dass unsere Infrastruktur anfälliger für Angriffe aus verschiedenen Richtungen geworden ist.

Cyberkriminelle sind immer bestrebt, einen Schritt voraus zu sein und werden bei ihren Bemühungen, in unsere Netzwerke und Systeme einzudringen, immer intelligenter und kreativer. Sie suchen nach Schwachstellen in unseren Sicherheitssystemen, und manchmal sind diese Schwachstellen die Menschen selbst. Social Engineering ist inzwischen so ausgeklügelt, dass psychologische Manipulation eingesetzt wird, um Zugang zu hochprivilegierten Konten zu erhalten. Früher dachten wir, Schwachstellen gäbe es nur in unserer Software und Hardware. Sobald ein Cyberkrimineller jedoch Zugriff auf ein Mitarbeiterkonto hat, kann er sich Zugang zu internen Systemen und wertvollen Daten verschaffen. Zero Trust ist eine Antwort auf diese Bedrohung.

Grundsätze des Zero Trust Modells

Explizit überprüfen

Das traditionelle Sicherheitsmodell stützte sich auf implizites Vertrauen. Es ging davon aus, dass alles im Netzwerk sicher sei und jeder innerhalb des Netzwerks uneingeschränkten Zugang habe. Diese Annahme ist jedoch überholt, und wir können uns nicht mehr auf die Vorstellung verlassen, dass hinter der Tür alles sicher ist. Firewall. Mit Zero Trust verifizieren wir jede Identität, unabhängig davon, ob die Anfrage von innerhalb oder außerhalb des Netzwerks kommt. Unser Ziel ist es, alle Datenpunkte zu authentifizieren und zu autorisieren, denn Zero Trust geht davon aus, dass böse Akteure überall zu finden sind, auch innerhalb Ihres Unternehmens.

Verwenden Sie den Zugriff mit den geringsten Rechten

Anstatt pauschalen Zugriff auf Identitäten zu gewähren, sollten wir nach den Prinzipien von Zero Trust anbieten. den am wenigsten privilegierten Zugriff. Verwenden Sie Identity Access Management (IAM), um einer Identität nur die minimalen Zugriffsrechte zuzuweisen erforderlich um einen Vorgang abzuschließen. In vielen Fällen ist es nicht notwendig, einer Identität permanenten Zugriff zu gewähren, insbesondere wenn es sich um hoch privilegierten Zugriff handelt. Verwenden Sie stattdessen Just-In-Time (JIT) und Just-Enough-Access (JEA) Mechanismen.

Verletzung annehmen

Gehen Sie davon aus, dass sich böswillige Akteure im Netzwerk befinden und ergreifen Sie entsprechende Maßnahmen zum Schutz der Ressourcen. Im Falle eines Hacks ist es wichtig, den Radius des Angriffs zu minimieren. Eine Möglichkeit, dies zu erreichen, besteht darin, Arbeitslasten durch Netzwerksegmentierung so weit wie möglich zu isolieren. Achten Sie jedoch darauf, Ihre Architektur einfach zu halten, denn Komplexität kann zu zusätzliche Sicherheitsrisiken.

Zero Trust umsetzen

Die fünf Schritte zur Annäherung an Zero Trust.

1. Definieren Sie die zu schützende Fläche. Zerlegen Sie Ihre Umgebung in kleinere Teile, die Sie schützen müssen.
2. Zeichnen Sie die Transaktionsflüsse auf. Untersuchen Sie Abhängigkeiten, eingehende und ausgehende Verbindungen und wie Daten durch das Netzwerk fließen.
3. Entwerfen Sie eine Zero Trust-Umgebung. Nutzen Sie die Zero Trust-Prinzipien, um eine Architektur zum Schutz Ihrer Schutzoberfläche zu entwerfen.
4. Erstellen Sie Zero Trust Sicherheitsrichtlinien. Verwenden Sie die Kipling-Methode (wer, was, wann, wo, warum, wie), um Sicherheitsrichtlinien zu entwickeln.
5. Überwachen und pflegen. Überwachen Sie Signale, um Risiken zu erkennen, Risiken zu beheben und die Zero Trust Architektur und Sicherheitsrichtlinien zu verbessern.

Die Angriffsfläche eines Unternehmens bezieht sich auf die Bereiche, in denen sich böswillige Akteure unbefugt Zugang zum Netzwerk verschaffen können. Die Angriffsfläche ist in der Regel recht groß, da das gesamte Internet als Teil der Angriffsfläche betrachtet werden kann. Wir bezeichnen die Anwendungen oder Systeme, die wir mit Zero Trust schützen wollen, als Schutzflächen. Eine Organisation kann über mehrere schützen Oberflächen, die jeweils mit ein DAAS-Element (Daten, Anwendungen, Assets, Dienste). Diese Ressourcen sind in jedem Element definiert. schützen die Oberfläche.

Um zu veranschaulichen, wie man die Prinzipien von Zero Trust in der Praxis anwendet, werde ich die SmartMoney-Anwendung des fiktiven Unternehmens OneFinance als ein Beispiel. Bitte beachten Sie, dass dieser Artikel nicht bieten eine erschöpfende Liste aller Azure-Dienste und -Funktionen, die zum Schutz von Anwendungen verwendet werden können. Stattdessen liegt der Schwerpunkt auf der SmartMoney-Anwendung.

Nutzen Sie die Prinzipien von Zero Trust, um SmartMoney zu sichern.

SmartMoney ist eine Anwendung, die von dem fiktiven Unternehmen OneFinancedas die Finanzdaten von Tausenden von Kunden verwaltet. SmartMoney hilft Kunden, Einblick in ihre persönlichen Finanzen zu erhalten und bietet Beratung, um finanziell unabhängig zu werden. Die Kundendienstabteilung ist für die Verwaltung aller Kundendaten zuständig. Auf der Grundlage dieser Daten bietet die Fachabteilung zur Verfügung. Beratung für Kunden, wie sie Kosten sparen und monatliche Budgets erstellen können. Vor zwei Jahren, OneFinance hat alle seine Arbeitslasten auf Microsoft Azure migriert. Die Mitarbeiter verwenden ihr Azure AD-Konto zur Authentifizierung. Die SmartMoney-Lösung ist in eine Frontend-Anwendung und eine Backend-Anwendung aufgeteilt, die enthält eine Reihe von APIs. Die Daten werden in Azure SQL und im Azure-Speicherkonto gespeichert. Sehen Sie sich die aktuelle Architektur in der Abbildung unten an.

Während der COVID-19-Pandemie, OneFinancehat, wie viele andere Unternehmen auch, seinen Mitarbeitern erlaubt, von zu Hause aus zu arbeiten, um Betriebsunterbrechungen zu vermeiden. Vor der Pandemie war die Anwendung nur von der IP-Adresse des Büros aus zugänglich. Die Liste der erlaubten IPs wurde erweitert, um sicherzustellen, dass die Mitarbeiter von zu Hause aus mit der Anwendung arbeiten konnten.

OneFinance hat viele Anwendungen, von denen einige intern von Mitarbeitern genutzt werden, während andere für Kunden öffentlich zugänglich sind. SmartMoney wurde als geschützte Oberfläche identifiziert, die wir durch die Einhaltung der Zero Trust-Prinzipien schützen wollen. Andere geschützte Oberflächen könnten das HR-System, das Intranet oder die öffentliche Website sein.

Aktuelle Architektur

Das Zero Trust Sicherheitsmodell besteht aus sechs Verteidigungsbereichen: Identität, Endpunkt, Anwendungen, Daten, Netzwerk und Infrastruktur. Jeder dieser Bereiche bietet eine Schicht des Schutzes. In diesem Artikel werde ich mich auf vier Verteidigungsbereiche zur Sicherung von SmartMoney konzentrieren. Ich beginne mit dem Bereich Netzwerkschutz.

Erstellen Sie einen Mikro-Perimeter und verwenden Sie Netzwerksegmentierung

Traditionell haben wir zentralisierte, netzwerkbasierte Perimeter, um Arbeitslasten im Netzwerk zu sichern. Eine Firewall wird vor dem Netzwerk platziert, um böswillige Benutzer draußen zu halten. Jede Arbeitslast, die innerhalb des Netzwerks ausgeführt wird, hat die gleiche Angriffsfläche. Bei diesem Ansatz werden alle Anfragen innerhalb des Netzwerks als vertrauenswürdig eingestuft. Mit Zero Trust schaffen wir Mikro-Perimeter für jede Schutzfläche.

Wir sollten davon ausgehen, dass es irgendwann zu einem Verstoß kommt und dass ein böswilliger Benutzer erhalten Zugang zum Netzwerk. Ein Angreifer könnte sich über eine unserer Anwendungen Zugang verschaffen, wenn es eine Hintertür oder eine Schwachstelle in einem der Drittanbieterpakete gibt. Wir sollten Arbeitslasten durch Netzwerksegmentierung isolieren, um den Explosionsradius zu minimieren. Jede Arbeitslast kann in einem eigenen Bereich platziert werden. und Netzwerksicherheitsgruppen können verwendet werden, um Datenverkehr nur für bestimmte Zwecke zuzulassen. Der gesamte Datenverkehr sollte standardmäßig verweigert werden.

Nachfolgend finden Sie die neue Architektur für die SmartMoney-Anwendung. Im weiteren Verlauf des Artikels führe ich Sie durch die Implementierung und zeige Ihnen, wie jeder Dienst auf der Grundlage der Zero Trust Prinzipien Schutz bietet.

Neue Architektur

Die SmartMoney-Anwendung ist öffentlich zugänglich. Der Zugriff ist jedoch auf IP-Adressen aus dem OneFinance-Büro und den Wohnungen der Mitarbeiter beschränkt. Dieser Ansatz führt zu einer großen Angriffsfläche, da jeder im Internet die Anwendung potenziell bedrohen kann. Auch wenn die Aktivierung von VPN nicht unbedingt eine Zero Trust-Verbesserung darstellt, möchten wir die Angriffsfläche so weit wie möglich reduzieren. Indem wir VPN aktivieren, stellen wir sicher, dass die Anwendung nur privat verfügbar ist. Wir sollten jedoch davon ausgehen, dass irgendwann ein böswilliger Benutzer VPN-Zugang erhält und sich innerhalb des Netzwerks befindet. Aus diesem Grund sollte der Workload in einem isolierten VNET erstellt und vorzugsweise in mehrere Subnetze aufgeteilt werden. Die Architektur zeigt, dass sich die Frontend-Anwendung in einem von der Backend-Anwendung getrennten Subnetz befindet. Eine Netzwerksicherheitsgruppe sorgt dafür, dass nur Datenverkehr aus dem Frontend-Subnetz in das Backend-Subnetz gelangen kann. Andere Arbeitslasten von OneFinance, wie z.B. das ERP, laufen in ihrem eigenen VNET. Zwischen dem ERP und dem SmartMoney VNET ist kein Datenverkehr erlaubt.

In der neuen Architektur folge ich dem Hub-Spoke-Modell, einem weit verbreiteten Architekturmuster. Der Hub ist ein zentraler Punkt für die Konnektivität, über den der gesamte ein- und ausgehende Datenverkehr läuft. Die Firewall im Hub überwacht und beschränkt den Verkehr. Die Spokes können die im Hub platzierten Dienste wiederverwenden.

Null Vertrauen Prinzipien

Explizit überprüfen	Mit Hilfe von Netzwerksicherheitsgruppen können wir den gesamten Datenverkehr im Netzwerk filtern. Mit Sicherheitsregeln können wir ein- und ausgehenden Datenverkehr für bestimmte IP-Adressen und Ports zulassen oder blockieren.
Geringste Berechtigung	Netzwerksicherheitsgruppe - Service-Tags helfen sicherzustellen, dass nur AppServices im Frontend-Subnetz mit einem AppService im Backend-Subnetz kommunizieren können.
Angenommen, ein Verstoß	Jeder Workload läuft in einem isolierten Netzwerk oder Subnetz.

Sicherheit ist eine gemeinsame Verantwortung von Cloud-Anbietern und ihren Kunden

Standardmäßig sind die PaaS-Dienste in Azure öffentlich zugänglich. Die SmartMoney-Anwendung verwendet ein Speicherkonto und eine SQL-Datenbank zum Speichern von Daten. Obwohl Azure sichere Dienste bietet, sollten Sie nicht davon ausgehen, dass Ihre Arbeitslasten allein durch die Nutzung von Azure gesichert sind. Microsoft weist ausdrücklich darauf hin, dass die Verantwortung für die Sicherheit zwischen Azure und dem Kunden geteilt wird.

Azure bietet viele Optionen zur Sicherung Ihres Speicherkontos. Ihr Speicherkonto kann jedoch ungesichert bleiben, wenn Sie Ihre Container nicht privat machen oder Shared Keys über Azure AD zur Authentifizierung verwenden. Wenn Ihr PaaS-Dienst nur von Ressourcen in Ihrem VNET genutzt wird, empfiehlt es sich, Private Link zu verwenden. Private Link stellt sicher, dass der Datenverkehr über den Microsoft-Backbone und nicht über das Internet läuft. Wenn Sie Private Link aktivieren, werden ein privater Endpunkt und eine private DNS-Zone erstellt. Wenn sich die Backend-Anwendung mit dem Speicherkonto verbindet, erkennt Azure, dass Private Link aktiviert ist. Der private Endpunkt wird nun für die Kommunikation mit dem Speicherkonto verwendet.

In der Architektur von SmartMoney wird ein neues Subnetz für private Endpunkte des Speicherkontos und des SQL-Servers erstellt. Es gibt Netzwerksicherheitsgruppen, die nur Datenverkehr vom Backend-Subnetz zum privaten Endpunkt-Subnetz zulassen. Infolgedessen können Ressourcen im Frontend-Subnetz diese Dienste nicht direkt erreichen.

Null Vertrauen Prinzipien

Explizit verifizieren	Indem wir die private Verbindung aktivieren, stellen wir sicher, dass nur Datenverkehr aus dem Netzwerk auf die PaaS-Dienste zugreifen kann.
Angenommen, eine Sicherheitslücke wird ausgenutzt	Wenn eine Sicherheitslücke in der Front-End-Anwendung ausgenutzt wird, hat der böswillige Benutzer keinen Zugriff auf das Speicherkonto oder den SQL-Server.

Wir haben einen Mikro-Perimeter für die SmartMoney-Anwendung implementiert, indem wir sie innerhalb eines isolierten Netzwerks platziert haben. Dadurch wird der Explosionsradius im Falle eines Einbruchs minimiert. Die verschiedenen Komponenten der Anwendung sind in Subnetze unterteilt, und der Datenverkehr wird mithilfe von Netzwerksicherheitsgruppen explizit überprüft. Dies war der erste Schritt zum Schutz unserer Anwendung. Der nächste Schritt ist die Sicherung der Daten.

Kennen Sie Ihre Daten und sichern Sie sie

Wenn Sie Ihre Daten nicht kennen, können Sie sie nicht richtig schützen

Daten sind die Grundlage für alles, was wir tun. Einige der größten Unternehmen sind auf Daten angewiesen, um Einnahmen zu erzielen. Ein Datendiebstahl oder ein Ransomware-Angriff kann diesen Unternehmen und ihren Endbenutzern jedoch erheblichen Schaden zufügen. Der erste Schritt bei der Sicherung von Daten besteht darin, die Daten, die Sie haben, zu ermitteln und zu identifizieren. Sobald dies geschehen ist, klassifizieren Sie die Daten mit einer Sensibilitätskennzeichnung, damit Sie wissen, welche Daten eine höhere Sicherheitsstufe benötigen als andere.

Nachfolgend finden Sie ein Beispiel für die Datenklassifizierung für die SmartMoney-Anwendung.

Streng vertraulich	Persönliche und finanzielle Daten des Kunden.
Vertraulich	Beratung für Kunden auf der Grundlage ihrer Daten.
Allgemein	SmartMoney-Handbücher für neue Mitarbeiter.
Öffentlich	Marketingtext für die SmartMoney-Anwendung.

Anhand der Sensibilitätskennzeichnung können wir die Auswirkungen einer Datenverletzung und von Datenverlusten ermitteln. Die Datenermittlung muss keine manuelle Aufgabe sein. Azure SQL umfasst Data Discovery & Classifications, eine Funktion, die Ihre Datenbank automatisch nach Spalten mit sensiblen Daten durchsucht. Sie überwacht und prüft auch die Abfrageergebnisse und versieht sie mit einer Sensibilitätskennzeichnung. Auf der Grundlage der Empfehlungen sollten Sie Maßnahmen ergreifen, um diese Daten zu schützen.

Standardmäßig sind alle von Azure gespeicherten Daten im Ruhezustand verschlüsselt. Zur Verschlüsselung der Daten werden Plattformschlüssel verwendet, aber es ist auch möglich, Kundenschlüssel (BYOK) zu verwenden. Sie denken vielleicht, gut, das bedeutet, dass ich gegen Datenschutzverletzungen geschützt bin? Nein, Verschlüsselung im Ruhezustand bedeutet, dass Ihre Daten geschützt sind, wenn sich ein Eindringling Zugang zu einem Rechenzentrum verschafft und das Laufwerk mit Ihren Daten stiehlt. Die Daten auf der Festplatte sind verschlüsselt, also für den Eindringling nutzlos. Wann immer Sie auf die Daten auf der Festplatte zugreifen, z.B. wenn Sie ein Speicherkonto verwenden, werden die Daten entschlüsselt, so dass Sie sie nutzen können. Von diesem Zeitpunkt an liegt es in Ihrer Verantwortung, die Daten zu schützen. Eines der ersten Dinge, die wir tun können, ist die Verschlüsselung von Daten während der Übertragung. In der SmartMoney-Anwendung wollen wir sicherstellen, dass sowohl die Frontend- als auch die Backend-Anwendungen über HTTPS laufen. Dies schützt uns vor einem Man-in-the-Middle-Angriff. TLS ist für Azure-Speicherkonten standardmäßig aktiviert und kann nicht ausgeschaltet werden.

Die Verschlüsselung von Daten im Ruhezustand und bei der Übertragung ist das absolute Minimum, das wir immer tun sollten. In einigen Fällen, insbesondere bei Finanzdaten, ist es unerlässlich, zusätzliche Einschränkungen für sensible Informationen vorzunehmen. Wenn Sie von einem Sicherheitsverstoß ausgehen, müssen Sie den schlimmsten Fall in Betracht ziehen, z. B. was ein böswilliger Benutzer mit den durchgesickerten Kreditkartendaten tun könnte.

Die SmartMoney-Anwendung ermöglicht es Mitarbeitern, Banktransaktionen von Kunden zu importieren. Einige Daten, wie z.B. die Kontonummer, sollten jedoch für die Mitarbeiter des Kundendienstes niemals sichtbar sein. Eine Möglichkeit, dies zu erreichen, ist die Verwendung der dynamischen Maskierung in Azure SQL. Mit dieser Funktion werden Daten automatisch maskiert, wenn sie durch eine Abfrage abgerufen werden. Zum Beispiel würde eine Kreditkartennummer als XXXX-XXXX-XXXX-1234 erscheinen, wenn sie maskiert wird.

Wenn sich Angreifer Zugang zu den Anmeldedaten der Datenbank verschaffen, können sie die gesamte Datenbank kompromittieren. Dies würde es dem Angreifer ermöglichen, ein Backup zu erstellen oder SQL Management Studio für den Zugriff auf sensible Daten zu verwenden. Um dieses Problem zu lösen, bietet Azure SQL die Funktion Always Encrypted. Mit dieser Funktion werden die Daten auf dem Client mithilfe eines Datenbanktreibers verschlüsselt und dann in der Datenbank gespeichert. Die Daten können von der Client-Anwendung nur im Klartext eingesehen werden. Die Daten bleiben auch dann verschlüsselt, wenn ein Administrator mit SQL Management Studio auf die Datenbank zugreift.

Die Daten werden mit einem Content Encryption Key (CEK) verschlüsselt, der in der Datenbank gespeichert wird, nachdem er mit einem Customer Master Key (CMK) verschlüsselt wurde. Normalerweise wird der CMK in Azure Key Vault gespeichert. Mit diesem Ansatz sind sensible Daten geschützt, falls die SQL-Anmeldeinformationen kompromittiert werden.

Null Vertrauen Prinzipien

Verletzung annehmen

Wenn Sie Always Encrypted verwenden, hat ein böswilliger Benutzer keinen Zugriff auf sensible Daten. Nur die Client-Anwendung kann die Daten entschlüsseln.

---

Ransomware-Angriffe können einer Organisation erheblichen Schaden zufügen. Ein Angreifer verschafft sich Zugriff auf das Netzwerk oder den PaaS-Dienst und verschlüsselt alle Daten, so dass sie für das Unternehmen unzugänglich sind. Die einzige Möglichkeit für ein Unternehmen, den Zugriff auf die Daten wiederzuerlangen, besteht darin, die Ransomware an die Hacker zu bezahlen. Oft kündigen Hacker einen erfolgreichen Angriff öffentlich an, um den Druck auf das Unternehmen zu erhöhen, das Lösegeld zu zahlen. Leider machen sich viele Unternehmen erst dann Gedanken über Ransomware-Bedrohungen, wenn es bereits zu spät ist.

Wenn wir den Zero Trust-Ansatz verfolgen, sollten wir von Beginn eines Projekts an von einer Sicherheitsverletzung ausgehen. Das bedeutet, dass wir zu jedem Zeitpunkt die Möglichkeit eines Ransomware-Angriffs in Betracht ziehen müssen. Daher müssen wir unsere Daten gegen ein solches Ereignis schützen. Wie bereits erwähnt, sind viele Unternehmen auf ihre Daten angewiesen, daher sollte der Schutz der Daten oberste Priorität haben. Eine Möglichkeit, Daten zu schützen, ist die Erstellung von Backups. SmartMoney verwaltet viele Dokumente für Kunden in einem Speicherkonto. Mit Azure Backup Vault können wir Sicherungskopien aus dem Blob-Speicher erstellen. Es gibt zwei Möglichkeiten, Backups zu erstellen: operative Backups und Tresor-Backups. Operative Backups sind eine lokale Lösung, d.h. die Daten werden lokal auf dem Speicherkonto gespeichert. Dies schützt die Daten vor versehentlichem Löschen und Beschädigung. Bei Tresor-Backups werden die Daten in den Tresorraum verschoben und dort geschützt. Bei einem Ransomware-Angriff versucht der Hacker in der Regel, die Backups zu finden und sie unbrauchbar zu machen. Vaulted Backups werden an einem anderen Ort gespeichert und schützen Sie daher vor Ransomware-Angriffen.

Null Vertrauen Prinzipien

Explizit überprüfen	Nur Benutzerkonten mit hohen Rechten können auf die gesicherten Backups zugreifen.
Einbruch annehmen	Die Verwendung von Vaulted Backups schützt uns vor Ransomware-Angriffen.

Die Sicherung von Daten ist für Organisationen wie OneFinance unerlässlich. Eines der wichtigsten Prinzipien von Zero Trust ist es, von einer Sicherheitslücke auszugehen und diese von Beginn des Projekts an im Auge zu behalten. In Azure SQL haben wir unsere sensiblen Daten mit Datenmasken und Always Encrypted geschützt. Darüber hinaus haben wir den Backup Vault verwendet, um die Daten im Azure-Speicherkonto vor Ransomware-Angriffen zu schützen. Als nächstes steht die Identität an.

Identitäten verifizieren und sichern

Eines der Ziele von Zero Trust ist es, das Vertrauen zu beseitigen. In der Vergangenheit haben wir eine Firewall vor unser Netzwerk gestellt und allen Nutzern darin implizit vertraut. Mit Zero Trust sollten wir jedoch niemandem mehr vertrauen, egal ob er sich innerhalb oder außerhalb des Netzwerks befindet. Alle Operationen, die von einer Identität ausgeführt werden, sollten überprüft werden, um sicherzustellen, dass der Zugriff für diese Identität angemessen ist.

In Microsoft Azure werden alle Identitäten zentral in Azure Active Directory gespeichert. OneFinance verfügt über mehrere Anwendungen, wie SmartMoney, das HR-System, ERP und das Intranet. Um auf jede Anwendung zuzugreifen, müssen sich die Benutzer authentifizieren. Wann immer möglich, sollten wir Single Sign-On (SSO) verwenden, damit die Benutzer ihre gleiche Identität in allen Anwendungen verwenden können. Dieser Ansatz macht es einfacher, Identitäten zu pflegen, verringert die Sicherheitsrisiken durch verlorene Passwörter und bietet eine bessere Benutzererfahrung.

Azure Active Directory unterstützt OpenID Connect, OAuth und SAML für die Implementierung von SSO. Benutzer können über die URL My Apps Microsoft.com die ihnen zugewiesenen Anwendungen anzeigen und darauf zugreifen.

Vorteile der Verwendung von SSO

• Eine Identität für alle Anwendungen
• Entziehen Sie den Zugang von einer zentralen Stelle aus und gelten Sie für alle Anwendungen
• Erzwingen Sie starke Authentifizierung in allen Anwendungen

Das Zero Trust-Modell erfordert die Überprüfung aller externen und internen Anfragen, um die Sicherheit zu gewährleisten. Insider-Bedrohungen oder Social-Engineering-Angriffe können dazu führen, dass die Anmeldedaten von Mitarbeitern preisgegeben werden. Wir sollten eine starke Authentifizierung implementieren, indem wir die Multi-Faktor-Authentifizierung (MFA) aktivieren, um zu verhindern, dass ein böswilliger Benutzer kompromittierte Anmeldedaten verwendet.

Die Wahrscheinlichkeit, dass Konten kompromittiert werden, liegt bei mehr als 99,9%, wenn Sie MFA verwenden.

Die Multi-Faktor-Authentifizierung (MFA) kann für Identitäten in Active Directory erzwungen werden. Dabei müssen Benutzer eine zusätzliche Form der Identifizierung angeben. Zu den Verifizierungsmethoden gehören Microsoft Authenticated App, FIDO2-Sicherheitsschlüssel, SMS und Sprachanruf. MFA kann über die Sicherheitsvorgaben aktiviert werden, wenn Sie Azure AD kostenlos oder eine eigenständige Microsoft 365-Lizenz verwenden, oder mit Conditional Access, wenn Sie Azure AD Premium oder Microsoft 365 Business haben. Sie kann für bestimmte Benutzer oder Gruppen aktiviert werden. Es ist wichtig, dass Sie Ihr Break-Glass-Konto ausschließen. Dieses spezielle Konto mit hohen Rechten kann in einem Notfall verwendet werden, und Sie möchten verhindern, dass es gesperrt wird.

Nach der COVID-Pandemie arbeiten viele OneFinance-Mitarbeiter weiterhin von zu Hause aus. SmartMoney speichert eine Menge sensibler Daten, und das Unternehmen muss verhindern, dass diese Daten in die falschen Hände geraten. Daher möchten wir MFA durchsetzen, wenn Mitarbeiter versuchen, sich von außerhalb des Büros bei der Anwendung anzumelden. Mit bedingten Zugriffsrichtlinien können wir auswählen, welche Benutzer, Geräte, Cloud-Anwendungen und Standorte eine Multi-Faktor-Authentifizierung erfordern.

Null Vertrauen Prinzipien

Explizit verifizieren	Die Aktivierung von MFA bietet eine größere Sicherheit, dass Benutzer die sind, die sie vorgeben zu sein.
Angenommen, es gibt einen Einbruch	Wenn die Benutzerdaten kompromittiert werden, kann der böswillige Benutzer sie nicht verwenden, da MFA aktiviert ist.

Die Verwendung des am wenigsten privilegierten Zugriffs ist eines der wichtigsten Prinzipien von Zero Trust. Mit Privileged Identity Management können Sie einen zeit- und genehmigungsbasierten Zugriff ermöglichen. Benutzer erhalten nur dann Zugriff, wenn sie eine bestimmte Aufgabe mit den geringsten Privilegien erledigen müssen, wodurch ein pauschaler Zugriff vermieden wird. Wenn ein Benutzer beispielsweise Zugriff auf ein Speicherkonto benötigt, um Dateien in einem bestimmten Container zu lesen, geben wir ihm (oder seiner Gruppe) nur Lesezugriff auf den Container und nicht auf das gesamte Speicherkonto.

Bei der Implementierung des Zero Trust Sicherheitsmodells müssen Sie von einem Sicherheitsverstoß ausgehen. Stellen wir uns vor, dass ein Benutzerkonto kompromittiert wurde und der Eindringling dieses Konto für den Zugriff auf das Speicherkonto verwendet. Wenn das Prinzip des am wenigsten privilegierten Zugriffs nicht befolgt würde, hätte der Eindringling Zugriff auf das gesamte Speicherkonto - mit allen Konsequenzen. Wenn jedoch nur Zugriffsrechte für bestimmte Aufgaben vergeben werden, wäre der Radius des Einbruchs minimal.

Das Kundenservice-Team verwaltet die Finanzdaten von Kunden in der SmartMoney-Anwendung. Sie erstellen neue Datensätze, aktualisieren Daten und entfernen irrelevante Informationen. Das Finanzexpertenteam kann die Berichtsfunktion nutzen, um diese Daten zu analysieren und jedem Kunden eine persönliche Beratung zukommen zu lassen. Das Kundenteam sollte nur die Berechtigung haben, Datensätze zu erstellen, zu ändern und zu löschen, während die Finanzexperten nur die Berechtigung haben sollten, auf die Berichtsfunktion zuzugreifen.

Gelegentlich müssen Kundendaten in SmartMoney gelöscht werden, aber es ist wichtig, dass Sie die Personen, die dies tun können, einschränken. PIM ermöglicht die Implementierung von Just-in-Time (JIT) Zugriff. Anstatt einer Identität permanenten Zugriff zu gewähren, kann eine Identität für eine Rolle freigeschaltet werden. Wenn ein Benutzer Zugriff benötigt, muss er die Zuweisung aktivieren und begründen, warum er den Zugriff benötigt. Sie wählen auch, wie lange sie diese Rolle benötigen. Ein Manager muss die Zuweisung genehmigen. Wenn der Zeitraum abgelaufen ist, wird die Zuweisung automatisch entfernt. Für die Verwendung von PIM ist eine Active Directory P2-Lizenz erforderlich.

Die Implementierung von Just-in-Time (JIT) und Just-Enough-Access (JEA) ermöglicht eine bessere Kontrolle darüber, wer wann auf was zugreifen darf. Normalerweise wird dies nur einmal konfiguriert. Es kann jedoch vorkommen, dass Mitarbeiter befördert werden oder die Abteilung wechseln, so dass eine regelmäßige Überprüfung der Zugriffsrechte in Privileged Identity Management (PIM) unerlässlich ist. Durch diese Überprüfungen können wir überprüfen, ob die Zugriffsrechte für jeden Benutzer angemessen sind.

Null Vertrauen Prinzipien

Geringste Berechtigung

Die Aktivierung von JIT (Just-in-Time) und JEA (Just-Enough-Access) mit PIM stellt sicher, dass Benutzer nur für einen kurzen Zeitraum Zugriff auf eine bestimmte Aufgabe haben.

---

Von Januar 2021 bis Dezember 2021 haben wir mehr als 25,6 Milliarden Brute-Force-Angriffe auf die Azure AD-Authentifizierung abgewehrt - Microsoft

Die Anzahl der Anmeldeereignisse kann enorm sein, da sich die Benutzer jeden Tag und manchmal sogar mehrmals täglich anmelden, um auf Anwendungen zuzugreifen. Dies kann zu Millionen von Anmeldevorgängen führen. Mit Azure Identity Protection können wir die Anmeldemuster der Benutzer überwachen und Risiken wie anonyme IP-Adressen, untypische Reisen, neue Länder, mit Malware verknüpfte IP-Adressen, unbekannte Anmeldeeigenschaften, durchgesickerte Anmeldedaten oder Passwort-Spray erkennen.

Mit dem Identitätsschutz können Sie eine Benutzer-Risikorichtlinie aktivieren, um kompromittierte Konten zu erkennen, oder eine Anmeldungs-Risikorichtlinie, um ungewöhnliches Verhalten zu erkennen. Die Anzahl der Signale kann jedoch überwältigend sein, und die Beseitigung von Fehlalarmen kann schwierig sein. Es ist möglich, die Reaktion auf Risikoerkennungen zu automatisieren, z.B. die Erzwingung der Multi-Faktor-Authentifizierung (MFA), wenn ein Anmeldungsrisiko erkannt wird. Wenn sich zum Beispiel ein Benutzer aus einem anderen Land anmeldet, können wir ihn zu einem zusätzlichen Authentifizierungsschritt auffordern, indem wir MFA erzwingen. So können Benutzer erkannte Risiken selbst beheben und produktiv bleiben, ohne die Administratoren mit Anmeldeproblemen zu überfordern. In Notfällen kann ein "Break Glass"-Konto verwendet werden, aber auch das kann zu erkannten Risiken führen. Glücklicherweise ist es möglich, Benutzer wie das Break-Glass-Konto von der Risiko-Richtlinie auszuschließen. Administratoren können Anmelde- und Benutzerrisikoberichte im Azure-Portal einsehen. Zur Beseitigung von Fehlalarmen ist es möglich, IP-Adressbereiche oder Länder aus den erkannten Signalen zu entfernen. Um Identity Protection zu nutzen, benötigen Sie eine Azure AD P2-Lizenz.

Die Sicherung von Identitäten ist einer der wichtigsten Verteidigungsbereiche von Zero Trust. Identitäten haben Zugriff auf Anwendungen und sensible Daten. Wir haben Single Sign-On (SSO) aktiviert und die Multi-Faktor-Authentifizierung (MFA) durch die Verwendung von Zugangskontrollen durchgesetzt. Die Verwaltung privilegierter Identitäten (PIM) stellt sicher, dass wir das Prinzip der geringsten Privilegien beim Zugriff auf Zero Trust befolgen.

Fehlkonfigurationen sind die Hauptursache für Datenschutzverletzungen. Im nächsten Abschnitt werde ich erörtern, wie wir Sicherheitsrisiken in unserer Infrastruktur verhindern und erkennen können.

Verwenden Sie Signale zum Schutz Ihrer Infrastruktur

Bei der Umsetzung des Zero-Trust-Modells geht es darum, den gesamten Datenverkehr zu überwachen, der zu und von einer geschützten Oberfläche geht, und Risiken zu beseitigen. Wir sollten die Sicherheit nicht als einmaliges Projekt betrachten, sondern als einen iterativen Prozess. Der gesamte Datenverkehr wird protokolliert, und auf der Grundlage dieser Protokolle können wir die Sicherheit verbessern, um robuster zu werden. Die Einführung neuer Arbeitslasten kann neue Sicherheitsrisiken mit sich bringen. Daher ist eine konsequente Überwachung der gesamten Infrastruktur auf Risiken unerlässlich.

Bei der Entwicklung von Lösungen in der Cloud kann die Anzahl der Signale, die gesammelt werden, überwältigend sein. Es ist unmöglich, all diese Signale zu überwachen und Risiken manuell zu beheben. Azure bietet Defender for Cloud, das Risiken über Abonnements hinweg identifiziert und behebt. Defender verfügt über Funktionen für Cloud Security Posture Management (CSPM) und Cloud Workload Protection Platform (CWPP). Es scannt Abonnements und Ressourcen ständig auf Sicherheitsprobleme. Auf der Grundlage der identifizierten Sicherheitsrisiken und Empfehlungen wird eine Sicherheitsbewertung erstellt. Je höher die Punktzahl, desto besser ist Ihre Cloud-Umgebung abgesichert. CWPP schützt Workloads vor Bedrohungen. Defender bietet Pläne für Server, Container, Datenbanken und Speicher. Konfigurierte Workloads werden gescannt, und Risiken werden auf der Grundlage ihrer Sicherheitsstufe gemeldet.

Defender for Storage analysiert die von Blob-Storage generierten Telemetriedaten. Auf der Grundlage dieser Daten werden Warnungen ausgelöst. Die Telemetrie umfasst Vorgänge mit Blobs wie Erstellen, Aktualisieren und Löschen. Dies hat keine Auswirkungen auf die Leistung des Speicherkontos. Zu den erkannten Risiken gehören ungewöhnliche Zugriffe auf ein Konto, Uploads bösartiger Inhalte, Datenverschlüsselung, ungewöhnliche Datenextraktion usw. Azure verwendet eine Technik namens Reputationsanalyse, um Malware zu erkennen. Das bedeutet, dass Dateien mit einem Hash versehen werden und auf dieser Grundlage die Wahrscheinlichkeit berechnet wird, dass es sich bei diesem Hash um Malware handelt. Wenn Risiken auftreten, werden Warnungen ausgelöst. Es ist wichtig, die Warnungen zu untersuchen und zu prüfen, ob es sich um falsch positive Meldungen handelt. Beispielsweise könnte ein Alarm ausgelöst werden, wenn eine große Menge an Daten auf einmal heruntergeladen wird. Dabei könnte es sich jedoch um einen Mitarbeiter handeln, der einen triftigen Grund hat.

Bis 2022 werden mindestens 95 Prozent der Sicherheitsausfälle in der Cloud auf das Konto des Kunden gehen.

Azure verwendet den Endpunkt blob.core.windows.net, um Blob-Speicherkonten zu erstellen. Öffentlich verfügbare Speicherkonten sind leicht zu finden. Suchen Sie einfach bei Google nach "site:*.blob.core.windows.net" und Sie erhalten über 3 Millionen Ergebnisse. Ein raffinierter Hacker kann ganz einfach ein Skript schreiben, um öffentlich verfügbare Speicherkonten zu finden, nach den Containern und Blobs zu suchen und wertvolle Daten zu finden. Von dort aus kann der Hacker das Unternehmen ausfindig machen und es ins Visier nehmen, um Zugang zu den Zugangsschlüsseln zu erhalten. Sobald sie sich Zugang verschafft haben, haben sie einen Einstiegspunkt in das Unternehmen und können weiter infiltrieren, indem sie Malware hochladen. Defender for Storage erkennt öffentlich zugängliche Speicherkonten und löst einen Alarm aus. Das ist großartig, denn wir können dieses Risiko sofort beseitigen.

Dies liefert uns großartige Informationen über unsere Arbeitslasten in Echtzeit. Vorbeugen ist jedoch besser als Erkennen. Wir sollten alle Fehlkonfigurationen erkennen, bevor wir sie in der Produktion einsetzen.

Definieren Sie den gewünschten Zustand Ihrer Infrastruktur mithilfe von Code und suchen Sie nach Fehlkonfigurationen.

Die Verwendung von Infrastructure as Code (IaC) hat viele Vorteile, z. B. die Verringerung des Risikos menschlicher Fehler, die Gewährleistung von Konsistenz, die Ermöglichung von Automatisierung und die Einsparung von Kosten. Durch die Implementierung einer guten DevOps-Pipeline, die Pull-Requests und Reviews umfasst, können Fehler frühzeitig erkannt werden. Terraform ist ein Open-Source IaC-Tool, das mit vielen Cloud-Diensten funktioniert. Der gewünschte Zustand der Infrastruktur wird in Code geschrieben und lässt sich leicht bereitstellen. Da Terraform Open-Source ist, stehen viele Erweiterungen zur Verfügung. Sicherheitstools wie tfsec und Checkov können den Terraform-Code auf Fehlkonfigurationen und Sicherheitsprobleme überprüfen und ermöglichen es uns, den Ingenieuren schon früh in der DevOps-Pipeline Feedback zu geben.

Wenn wir eine Zero Trust-Architektur entwerfen, wollen wir dies auf organisatorischer Ebene tun. Die definierten Standards gelten für alle Workloads. Mit Azure Policies können wir unsere Azure-Ressourcen von einem zentralen Ort aus steuern. Die Verwendung von Zugriffsschlüsseln stellt beispielsweise ein potenzielles Risiko dar, da jeder diese Zugriffsschlüssel verwenden kann, um auf das Speicherkonto zuzugreifen. Um sicherzustellen, dass Speicherkonten keine Zugriffsschlüssel verwenden, können wir die Richtlinie aktivieren: "Speicherkonten sollten den gemeinsamen Schlüsselzugriff verhindern". Je nachdem, wie die Richtlinie konfiguriert ist, können wir die Ressource verweigern oder prüfen. Wenn Sie eine neue Richtlinie erstellen, sollten Sie zunächst die Option audit verwenden, um zu prüfen, welche Ressourcen betroffen sind. Wenn Sie mit der Option Verweigern beginnen, können Sie möglicherweise Teams blockieren.

Für die SmartMoney-Anwendung haben wir bereits Private Link für das Speicherkonto aktiviert, um sicherzustellen, dass das Speicherkonto nur im VNET erreichbar ist. OneFinance hat viele Arbeitslasten, und einige verwenden Speicherkonten. Um sicherzustellen, dass alle in Abonnements erstellten Speicherkonten Private Link verwenden, können wir die integrierte Richtlinie 'Speicherkonto für die Verwendung einer Private Link-Verbindung konfigurieren' verwenden. Diese Richtlinie konfiguriert Private Link automatisch, wenn es nicht für ein Speicherkonto eingesetzt wird. Richtlinien können auf der Ebene der Verwaltungsgruppe, des Abonnements und der Ressourcengruppe erstellt werden. OneFinance möchte diese Funktion für alle Speicherkonten in allen Abonnements aktivieren, daher ist der beste Ort für die Erstellung dieser Richtlinie die Ebene der Verwaltungsgruppe.

Fehlkonfigurationen sind die Hauptursache für Datenschutzverletzungen. Um dies zu verhindern, empfiehlt sich ein Defense-in-Depth-Ansatz, bei dem mehrere Sicherheitsebenen geschaffen werden. Es ist eine bewährte Praxis, sowohl einen Präventions- als auch einen Erkennungsmechanismus zu implementieren.

1. Prävention - Definieren Sie die Infrastruktur deklarativ mit Terraform.
2. Prävention - Verwenden Sie Tools wie tfsec und Checkov, um Risiken und Sicherheitsverbesserungen frühzeitig in der DevOps-Pipeline zu erkennen.
3. Prävention - Verwenden Sie Pull-Requests und Überprüfungen.
4. Prävention/Erkennung - Azure-Richtlinien helfen dabei, die Infrastruktur mit den Richtlinien Ihres Unternehmens in Einklang zu bringen.
5. Erkennung - Defender for Cloud zur Analyse von Signalen, Erkennung und Beseitigung von Risiken.

Abschließende Worte

Die Welt hat sich verändert und wir müssen akzeptieren, dass böse Akteure überall sind. Dynamische Arbeitsumgebungen, intelligente Geräte und immer raffiniertere Cyberkriminelle vergrößern die Angriffsfläche. Um uns zu schützen, brauchen wir einen neuen Sicherheitsansatz: Null Vertrauen. Dieser Ansatz beseitigt das Vertrauen und geht von einer Verletzung aus.

Mit Zero Trust trauen wir niemandem, nicht einmal unseren Mitarbeitern. In diesem Artikel habe ich die wichtigsten Grundsätze von Zero Trust erläutert, warum wir es brauchen und wie es umgesetzt werden kann. Anhand einer Beispielanwendung habe ich demonstriert, wie Sie die Zero Trust-Prinzipien mit Hilfe von Diensten in Azure umsetzen können. Beachten Sie, dass dies keine umfassende Liste aller Azure-Dienste und -Funktionen war, die Sie nutzen können, aber es sollte Ihnen eine Vorstellung davon geben, warum wir sie nutzen sollten.