Sicherheitsdomäne: Sicherheit und Datenschutz für die Datenverarbeitung

Diese Sicherheitsdomäne soll sicherstellen, dass alle von Microsoft 365 genutzten Daten sowohl während der Übertragung als auch im Ruhezustand angemessen geschützt werden. Dieser Bereich stellt auch sicher, dass die Datenschutzbedenken der Verbraucher (betroffene Personen) vom ISV im Einklang mit der DSGVO (General Data Protection Regulation) und hipaa (Health Insurance Portability and Accountability Act von 1996) erfüllt werden.

Daten während der Übertragung

Die Konnektivitätsanforderungen von von Microsoft 365 entwickelten Apps/Add-Ins erfordern die Kommunikation über öffentliche Netzwerke, insbesondere über das Internet. Daher müssen daten während der Übertragung angemessen geschützt werden. Dieser Abschnitt behandelt den Schutz der Datenkommunikation über das Internet.

Steuerelement Nr. 1

Geben Sie für alle folgenden Punkte Nachweise an:

• Überprüfen Sie, ob Ihre TLS-Konfiguration TLS1.2 oder höher ist.

• Ein Inventar der vertrauenswürdigen Schlüssel und Zertifikate wird aufbewahrt und verwaltet.

Absicht: TLS

Mit diesem Unterpunkt soll sichergestellt werden, dass Microsoft 365-Daten, die von Ihrer Organisation genutzt werden, sicher übertragen werden. Die TLS-Profilkonfiguration wird verwendet, um TLS-spezifische Anforderungen zu definieren, die sicherstellen, dass der Datenverkehr vor Man-in-the-Middle-Angriffen geschützt ist.

Richtlinien: TLS

Die einfachste Möglichkeit, dies nachzuweisen, besteht darin, das Qualys SSL Server Test-Tool für ALLE Weblistener auszuführen, einschließlich aller, die auf nicht standardmäßigen Ports ausgeführt werden.

Denken Sie daran, die Option "Ergebnisse nicht auf den Boards anzeigen" zu aktivieren, die verhindert, dass die URL zur Website hinzugefügt wird.

Die Anforderungen an die TLS-Profilkonfiguration können anhand einzelner Überprüfungen nachgewiesen werden. Um bestimmte Einstellungen zu belegen, z. B. das Deaktivieren der TLS-Komprimierung, können Konfigurationseinstellungen, Skripts und Softwaretools verwendet werden.

Beispielbeweis: TLS

Der folgende Screenshot zeigt die Ergebnisse der SSL-Überprüfung von Qualys für die webappfrontdoor-byendbagh6a0fcav.z01.azurefd.net.

Der Abschnitt Protokolle zeigt, dass TLS1.2 das einzige unterstützte/aktivierte Protokoll ist.

Hinweis: Die Zertifizierungsanalysten überprüfen die vollständige Ausgabe der Überprüfung, um zu bestätigen, dass alle Anforderungen der TLS-Profilkonfiguration erfüllt sind. Es wird erwartet, dass Überprüfungen für alle Endpunkte bereitgestellt werden, die öffentlich verfügbar gemacht werden (IP-Adressen und URLs) für die Back-End-Umgebung, die sich im Gültigkeitsbereich befindet. Je nachdem, welche Beweise bereitgestellt wurden, können die Analysten ihren eigenen Qualys-Scan ausführen.

Beispielbeweis: TLS

Der folgende Screenshot zeigt die Konfigurationseinstellungen für TLS in Azure App Service gefolgt von der TLS-Enumeration über PowerShell.

Absicht: Schlüssel und Zertifikate

Mit diesem Unterpunkt soll sichergestellt werden, dass ein umfassendes Inventar vertrauenswürdiger Schlüssel und Zertifikate verwaltet wird, bei dem verschiedene Systeme, Dienste und Anwendungen identifiziert werden, die von diesen kryptografischen Elementen abhängig sind.

Richtlinien: Schlüssel und Zertifikate

Die Beweise müssen belegen, dass ein Inventar vertrauenswürdiger Schlüssel und Zertifikate vorhanden ist und verwaltet wird. Darüber hinaus können anwendbare Beweise für die Tools bereitgestellt werden, die zum Speichern der tatsächlichen Schlüssel und Zertifikate verwendet werden, z. B. Azure Key Vault, HashiCorp Vault Secrets, Confluence Cloud usw.

Beispielbeweis: Schlüssel und Zertifikate

Der folgende Screenshot zeigt, dass ein Schlüssel und ein Zertifikatbestand in Confluence Cloud verwaltet werden.

Der folgende Screenshot zeigt die genehmigte Liste der vertrauenswürdigen Schlüssel und Zertifikate. Es enthält Details wie das Zertifikat, Schlüssel, Cyphers und die Systeme, auf denen sie installiert sind.

Der folgende Screenshot stammt aus hashiCorp Vault. Die Inventurzertifikate, die in der Bestandsliste aufgeführt und aufgezeichnet werden, werden in diesem Onlinetresor gespeichert. HashiCorp Vault ist ein Open-Source-Tool für die Verwaltung von Geheimnissen, Encryption-as-a-Service und Privileged Access Management.

Der folgende Screenshot zeigt einen Auszug des tatsächlichen Zertifikats und der im Onlinetresor gespeicherten Schlüssel.

Hinweis: Es wird davon ausgegangen, dass der Speicherort der Schlüssel über geeignete Zugriffssteuerungen verfügt. Wenn der private Schlüssel kompromittiert wird, könnte jemand den Server mit einem legitimen Zertifikat spoofen.

Beispielbeweis: Schlüssel und Zertifikate

Ein Inventar von vertrauenswürdigen Schlüsseln und Zertifikaten kann auch mit Microsoft 365 Defender verwaltet werden, das ein Inventarfeature bereitstellt, wie im nächsten Screenshot gezeigt.

Der nächste Screenshot zeigt die Details des Zertifikats.

Bitte beachten Sie: Bei diesen Beispielen handelt es sich nicht um Screenshots im Vollbildmodus. Sie müssen Screenshots im Vollbildmodus mit einer beliebigen URL, angemeldetem Benutzer und dem Zeit- und Datumsstempel zur Beweisüberprüfung übermitteln. Wenn Sie ein Linux-Benutzer sind, kann dies über die Eingabeaufforderung erfolgen.

Steuerelement Nr. 2

Geben Sie für alle folgenden Angaben Nachweise an:

• Zeigt, dass die TLS-Komprimierung für alle öffentlichen Dienste deaktiviert ist, die Webanforderungen verarbeiten, um CRIME (Compression Ratio Info-leak Made Easy) zu verhindern.

• Überprüft, ob TLS HSTS aktiviert und für 180 Tage an allen Standorten konfiguriert ist.

Absicht: TLS

• Der ANGRIFF CRIME (Compression Ratio Info-leak Made Easy (CVE-2012-4929)) ist ein Sicherheitsrisiko bei der Komprimierung der Protokolle Secure Sockets Layer (SSL)/Transport Layer Security (TLS). Aus diesem Grund wird empfohlen, die SSL-Komprimierung zu deaktivieren.

• HTTP Strict Transport Security (HSTS) ist ein Sicherheitsmechanismus, der Websites vor Man-in-the-Middle-Angriffen schützt, indem TLS-Verbindungen über ein HTTPS-Antwortheaderfeld namens "Strict-Transport-Security" erzwungen werden.

Richtlinien: TLS

Dies kann mithilfe des Qualys SSL Labs-Tools nachgewiesen werden. Beispielbeweis: TLS

Der folgende Screenshot zeigt, dass die SSL/TLS-Komprimierung deaktiviert ist.

Der nächste Screenshot zeigt, dass HSTS aktiviert ist.

Hinweis: Der Zertifizierungsanalyst überprüft die vollständige Ausgabe, um zu bestätigen, dass alle Anforderungen der TLS-Profilkonfigurationsanforderungen erfüllt sind (Bitte geben Sie Screenshots der vollständigen Scanausgabe an). Je nachdem, welche Beweise bereitgestellt wurden, können die Analysten ihren eigenen Qualys-Scan ausführen.

Weitere Tools, die verwendet werden können, um zu überprüfen, ob HSTS aktiviert ist, sind "HTTP Header Spy" und

securityheaders.com wie in den folgenden Beispielen gezeigt. Zusätzliche Beweise

Screenshots wie Konfigurationseinstellungen der Sicherheitsheader, insbesondere HSTS, können bereitgestellt werden, um den Sicherheitsstatus des öffentlichen Fußabdrucks weiter zu veranschaulichen.

Die nächsten Screenshots zeigen die Azure Front Door-Konfiguration und den Regelsatz, der zum Umschreiben der Header implementiert wurde.

Der nächste Screenshot zeigt die durchgeführte Überprüfung der Sicherheitsheader und dass alle Sicherheitsheader implementiert sind, nicht nur HSTS.

Hinweis: Wenn Qualys SSL Scanner oder Sicherheitsheader verwendet werden, wird davon ausgegangen, dass der vollständige Bericht für eine Überprüfung bereitgestellt wird.

Ruhende Daten

Wenn daten, die von der Microsoft 365-Plattform genutzt werden, von ISVs gespeichert werden, müssen die Daten entsprechend geschützt werden. In diesem Abschnitt werden die Schutzanforderungen von Daten behandelt, die in Datenbanken und Dateispeichern gespeichert sind.

Regelung Nr. 3

Stellen Sie nachweisbare Beweise bereit, dass ruhende Daten gemäß den Anforderungen des Verschlüsselungsprofils verschlüsselt werden, indem Verschlüsselungsalgorithmen wie AES, Blowfish, TDES und Verschlüsselungsschlüsselgrößen von 128-Bit und 256-Bit verwendet werden.

Absicht:

Es ist bekannt, dass einige ältere Verschlüsselungsalgorithmen kryptografische Schwachstellen enthalten, was die Wahrscheinlichkeit erhöht, dass ein Bedrohungsakteur die Daten ohne Kenntnis des Schlüssels entschlüsseln kann. Aus diesem Grund besteht die Absicht dieser Kontrolle darin, sicherzustellen, dass nur branchenweit akzeptierte Verschlüsselungsalgorithmen verwendet werden, um gespeicherte M365-Daten zu schützen.

Richtlinien:

Der Nachweis kann mithilfe von Screenshots bereitgestellt werden, die zeigen, dass die Verschlüsselung verwendet wird, um M365-Daten in Datenbanken und anderen Speicherorten zu schützen. Der Beweis sollte zeigen, dass die Verschlüsselungskonfiguration mit den Konfigurationsanforderungen für das Verschlüsselungsprofil der Microsoft 365-Zertifizierung im Einklang steht.

Beispielbeweis:

Der nächste Screenshot zeigt, dass TDE (Transparent Data Encryption) für die Contoso-Datenbank aktiviert ist. Der zweite Screenshot zeigt die Microsoft-Dokumentationsseite Transparente Datenverschlüsselung für SQL-Datenbank, SQL Managed Instance und Azure Synapse Analytics, die zeigt, dass die AES 256-Verschlüsselung für Azure TDE verwendet wird.

Bitte beachten Sie: In den vorherigen Beispielen wurden keine vollständigen Screenshots verwendet, jedoch müssen ALLE von ISV übermittelten Beweisscreenshots vollständige Screenshots mit der URL, allen angemeldeten Benutzern und Systemzeit und -datum sein.

Beispielbeweis:

Der folgende Screenshot zeigt Azure Storage, der mit Verschlüsselung für Blobs und Dateien konfiguriert ist. Der nächste Screenshot zeigt die Microsoft-Dokumentationsseite Azure Storage-Verschlüsselung für ruhende Daten , die zeigt, dass Azure Storage AES-256 für die Verschlüsselung verwendet.

Datenaufbewahrung, Sicherung und Entsorgung

Wenn ISVs Microsoft 365-Daten nutzen und speichern, besteht das Risiko einer Datenkompromittierung, wenn ein Bedrohungsakteur die ISV-Umgebung kompromittiert. Um dieses Risiko zu minimieren, sollten Organisationen nur die Daten speichern, die sie für die Bereitstellung von Diensten benötigen, und nicht daten, die in Zukunft "von Nutzen sein" könnten. Darüber hinaus sollten Daten nur so lange aufbewahrt werden, wie es für die Bereitstellung der Dienste erforderlich ist, für die die Daten erfasst wurden. Die Datenaufbewahrung sollte definiert und mit Benutzern kommuniziert werden. Sobald die Daten den definierten Aufbewahrungszeitraum überschreiten, muss diese sicher gelöscht werden, damit die Daten nicht wiederhergestellt oder wiederhergestellt werden können.

Steuerung Nr. 4

Bitte weisen Sie nach, dass ein genehmigter Datenaufbewahrungszeitraum formal festgelegt und dokumentiert ist.

Absicht:

Eine dokumentierte und befolgte Aufbewahrungsrichtlinie ist nicht nur wichtig, um einige gesetzliche Verpflichtungen zu erfüllen, z. B. Datenschutzvorschriften wie, aber nicht beschränkt auf die Datenschutz-Grundverordnung (EU-DSGVO) und den Datenschutzgesetz (UK DPA 2018), sondern auch, um das Risiko von Organisationen zu begrenzen. Indem Sie die Datenanforderungen der Organisationen verstehen und verstehen, wie lange daten benötigt werden, damit das Unternehmen seine Funktionen ausführt, können Organisationen sicherstellen, dass Daten ordnungsgemäß gelöscht werden, sobald ihre Nützlichkeit abläuft. Indem die Menge der gespeicherten Daten reduziert wird, verringern Organisationen die Datenmenge, die bei einer Datenkompromittierung verfügbar gemacht würde. Dadurch wird die Gesamtwirkung begrenzt.

Häufig speichern Organisationen Daten, weil es für alle Fälle gut ist. Wenn die Organisation die Daten jedoch nicht benötigt, um ihre Dienst- oder Geschäftsfunktion auszuführen, sollten die Daten nicht gespeichert werden, da dies das Risiko der Organisation unnötig erhöht.

Das Ziel dieser Kontrolle besteht darin, zu bestätigen, dass die Organisation einen genehmigten Datenaufbewahrungszeitraum für alle relevanten Datentypen offiziell festgelegt und dokumentiert hat. Dies umfasst nicht nur die Angabe der Dauer, für die verschiedene Arten von Daten gespeichert werden, sondern auch die Prozeduren für das Löschen von Daten oder die Archivierung nach dem Ablaufdatum.

Richtlinien:

Geben Sie die vollständige Datenaufbewahrungsrichtlinie an, in der klar angegeben ist, wie lange Daten (die alle Datentypen abdecken müssen) aufbewahrt werden sollen, damit das Unternehmen seine Geschäftsfunktionen ausführen kann.

Beispielbeweis:

Der nächste Screenshot zeigt die Datenaufbewahrungsrichtlinie von Contoso.

Hinweis: Diese Screenshots zeigen eine Momentaufnahme eines Richtlinien-/Prozessdokuments. Es wird erwartet, dass ISVs die tatsächliche Unterstützende Richtlinien-/Verfahrensdokumentation freigeben und nicht einfach einen Screenshot bereitstellen.

Steuerung Nr. 5

Zeigen Sie, dass Daten nur für den definierten Aufbewahrungszeitraum aufbewahrt werden, wie in Steuerung 4 erläutert.

Absicht:

Mit diesem Steuerelement soll einfach überprüft werden, ob die definierten Datenaufbewahrungszeiträume eingehalten werden. Wie bereits erwähnt, haben Organisationen möglicherweise eine rechtliche Verpflichtung, dies zu erfüllen, aber auch durch die Aufbewahrung von Daten, die erforderlich sind und so lange wie erforderlich sind, trägt dies dazu bei, das Risiko für die Organisation im Falle einer Datenverletzung zu verringern. Dadurch wird sichergestellt, dass Daten weder übermäßig lange Zeit aufbewahrt noch vorzeitig gelöscht werden, was zu unterschiedlichen Risiken führen kann – rechtlicher, betrieblicher oder sicherheitsbezogener Art.

Richtlinien:

Stellen Sie einen Screenshot-Beweis (oder per Bildschirmfreigabe) bereit, der zeigt, dass gespeicherte Daten (an allen verschiedenen Speicherorten, d. h. Datenbanken, Dateifreigaben, Archiven usw.) die definierte Datenaufbewahrungsrichtlinie nicht überschreiten. Beispiele wären Screenshots von:

• Datenbankdatensätze mit einem Datumsfeld, das in der Reihenfolge des ältesten Datensatzes durchsucht wird, und/oder

• Dateispeicherorte mit Zeitstempeln, die innerhalb des Aufbewahrungszeitraums liegen Hinweis: Alle persönlichen/vertraulichen Kundendaten sollten im Screenshot bearbeitet werden.

Beispielbeweis:

Der folgende Beweis zeigt eine SQL-Abfrage, die den Inhalt der Datenbanktabelle in aufsteigender Reihenfolge im Feld "DATE_TRANSACTION" sortiert zeigt, um die ältesten Datensätze in der Datenbank anzuzeigen. Dies zeigt, dass die Daten weniger als zwei Monate alt sind und den definierten Aufbewahrungszeitraum nicht überschreiten.

Hinweis: Dies ist eine Testdatenbank, daher sind nicht viele Verlaufsdaten darin enthalten.

Hinweis: In den vorherigen Beispielen wurden keine vollständigen Screenshots verwendet, aber ALLE von ISV übermittelten Beweisscreenshots müssen vollständige Screenshots mit URL, angemeldeten Benutzern und Systemzeit und -datum sein.

Steuerelement Nr. 6

Veranschaulichen, dass Prozesse vorhanden sind, um Daten nach dem Aufbewahrungszeitraum sicher zu löschen.

Absicht:

Mit diesem Steuerelement soll sichergestellt werden, dass der Mechanismus zum Löschen von Daten, die den Aufbewahrungszeitraum überschreiten, dies sicher tut. Gelöschte Daten können manchmal wiederhergestellt werden. Daher muss der Löschvorgang robust genug sein, um sicherzustellen, dass die Daten nach dem Löschen nicht wiederhergestellt werden können.

Richtlinien:

Wenn der Löschvorgang programmgesteuert erfolgt, geben Sie einen Screenshot des Skripts an, das dazu verwendet wird. Wenn es nach einem Zeitplan ausgeführt wird, geben Sie einen Screenshot mit dem Zeitplan an. Beispielsweise kann ein Skript zum Löschen von Dateien innerhalb einer Dateifreigabe als CRON-Auftrag konfiguriert werden. Screenshot des CRON-Auftrags mit dem Zeitplan und dem skript, das ausgeführt wird; und geben sie das Skript mit dem verwendeten Befehl an.

Beispielbeweis:

Dies ist ein einfaches Skript, das verwendet werden kann, um alle datensätze zu löschen, die basierend auf dem Datum aufbewahrt werden -30 Tage, wodurch alle aufbewahrten Datensätze gelöscht werden, die älter als 30 Tage nach dem ausgewählten Datenaufbewahrungsdatum sind. Bitte beachten Sie, dass wir das Skript benötigen; Nachweis des ausgeführten Auftrags und der Ergebnisse.

Bitte beachten Sie: In den vorherigen Beispielen wurden keine vollständigen Screenshots verwendet, jedoch müssen ALLE von ISV übermittelten Beweisscreenshots vollständige Screenshots mit der URL, allen angemeldeten Benutzern und Systemzeit und -datum sein.

Beispielbeweis:

Der folgende Screenshot wurde aus der Contoso-Datenaufbewahrungsrichtlinie (aus Steuerung 4) erstellt. Dies zeigt die verfahren, die für die Datenvernichtung verwendet werden.

Hinweis: Dieser Screenshot zeigt eine Momentaufnahme eines Richtlinien-/Prozessdokuments. Es wird erwartet, dass ISVs die tatsächliche Unterstützende Richtlinien-/Verfahrensdokumentation freigeben und nicht einfach einen Screenshot bereitstellen.

Beispielbeweis:

In diesem Beispiel wurde ein Runbook und ein entsprechender Zeitplan in Azure erstellt, um Datensätze sicher zu löschen, deren Enddatum 30 Tage nach Ablauf der Aufbewahrungsrichtlinie für Datensätze erstellt wurde. Dieser Auftrag wird so festgelegt, dass er jeden Monat am letzten Tag des Monats ausgeführt wird.

Der nächste Screenshot zeigt, dass das Runbook bearbeitet wurde, um Datensätze zu finden, und Löschbefehle enthält, die nicht wie das Skript angezeigt werden.

Hinweis: Die vollständige URL und der Benutzername müssen für diese Screenshots angezeigt werden, und ISVs müssen einen Screenshot der Datensatzanzahl vor dem Löschvorgang und einen Screenshot der Anzahl der Datensätze nach dem Löschen anzeigen.

Diese Screenshots sind reine Beispiele für die verschiedenen Möglichkeiten, mit denen dies angegangen werden kann.

Steuerelement Nr. 7

Geben Sie Nachweise an, die folgendes belegen:

• Ein automatisiertes Sicherungssystem ist vorhanden und so konfiguriert, dass Sicherungen zu geplanten Zeiten ausgeführt werden.

• Sicherungsinformationen werden gemäß dem Sicherungsplanungsverfahren getestet und regelmäßig wiederhergestellt, um die Zuverlässigkeit und Integrität der Daten zu bestätigen.

• Geeignete Zugriffssteuerungen und Schutzmechanismen (d. h. unveränderliche Sicherungen) werden implementiert, um sicherzustellen, dass Sicherungen/Systemmomentaufnahmen vor nicht autorisiertem Zugriff geschützt sind und um die Vertraulichkeit, Integrität und Verfügbarkeit der Sicherungsdaten sicherzustellen.

Absicht:

Das Ziel dieses Steuerelements besteht darin, zu bestätigen, dass die Organisation über ein automatisiertes Sicherungssystem verfügt, das für die Ausführung von Sicherungen zu vordefinierten Zeiten konfiguriert ist.

Richtlinien:

Geben Sie Screenshots der Konfigurationseinstellungen ihrer Sicherungslösung an, die zeigen, dass Sicherungen in geplanten Zeiträumen/Intervallen ausgeführt werden. Wenn die Sicherungsplanung automatisch von der Lösung durchgeführt wird, kann dies durch bereitstellung der Herstellerdokumentation unterstützt werden.

Beispielbeweis:

Der folgende Screenshot gilt für Azure Database for MySQL, bei der es sich um eine verwaltete Instanz handelt. Es gibt an, dass eine erste automatisierte Sicherung abgeschlossen wurde.

Der nächste Screenshot, der nach Ablauf eines Zeitraums erstellt wird, zeigt, dass weitere vollständige Sicherungen erstellt wurden. Sicherungen auf flexiblen Servern basieren auf Momentaufnahmen, wobei die erste Momentaufnahmesicherung unmittelbar nach der Erstellung eines Servers geplant wird und weitere Momentaufnahmesicherungen einmal täglich erstellt werden.

Der nächste Screenshot zeigt eine Momentaufnahme der Onlinedokumentation, in der die Sicherungshäufigkeit und die automatisierte Sicherungsfunktion beschrieben werden.

Absicht:

Ziel dieser Kontrolle ist es, zu belegen, dass Sicherungsinformationen nicht nur nach Zeitplan generiert werden, sondern auch zuverlässig sind und ihre Integrität im Laufe der Zeit aufrechterhalten. Um dieses Ziel zu erreichen, werden regelmäßige Tests für die Sicherungsdaten durchgeführt.

Richtlinien:

Die Beweise für diese Kontrolle hängen vom Prozess und verfahren der Organisation zum Testen von Sicherungsdaten ab. Es könnten Beweise dafür bereitgestellt werden, dass Sicherungen erfolgreich getestet wurden, zusammen mit Aufzeichnungen über den Abschluss historischer Tests.

Beispielbeweis:

Der folgende Screenshot zeigt, dass ein Sicherungszeitplan und ein Wiederherstellungsverfahren vorhanden und verwaltet werden und dass eine Sicherungskonfiguration für alle anwendbaren Systeme definiert ist, einschließlich der Häufigkeit der Sicherungen, die auf der Confluence-Plattform ausgeführt werden.

Der nächste Screenshot zeigt eine Seite mit verlaufsbezogenen Datensätzen von Sicherungstests für jedes der anwendbaren Systeme. Beachten Sie, dass auf der rechten Seite der Tabelle auf JIRA-Tickets für jeden der Tests verwiesen wird.

Die nächsten vier Screenshots zeigen den End-to-End-Prozess zum Wiederherstellen von Azure Database for MySQL aus einer Momentaufnahme. Mit der Option "Schnelle Wiederherstellung" können wir den Wiederherstellungsvorgang der SQL-Datenbank initiieren.

Der folgende Screenshot zeigt die Konfigurationsseite, auf der wir die Wiederherstellung anpassen können.

Sobald der Zielspeicherort, das Netzwerk und die Momentaufnahme ausgewählt wurden, von denen die Datenbank wiederhergestellt wird, können wir die Bereitstellung initiieren. Beachten Sie, dass unsere Datenbankinstanz jetzt "test" heißt.

Nach insgesamt fünf Minuten wurde die SQL-Datenbank erfolgreich und vollständig aus der Sicherungsmomentaufnahme wiederhergestellt, wie im Folgenden gezeigt.

Nach Abschluss der Tests wurde gemäß dem Prozess ein JIRA-Ticket erstellt, um die Sicherungstests und Details der durchgeführten Wiederherstellung aufzuzeichnen. Dadurch wird sichergestellt, dass verlaufsbezogene Daten für Compliancezwecke verfügbar sind und dass vollständige Datensätze zur Überprüfung im Fall eines Incidents oder Notfalls vorhanden sind, damit die Organisation eine Ursachenanalyse durchführen kann.

Absicht:

Im Anschluss an die vorherige Steuerung sollten Zugriffssteuerungen implementiert werden, um den Zugriff nur auf einzelne Benutzer zu beschränken, die für die Sicherungsdaten verantwortlich sind. Durch die Einschränkung des Zugriffs begrenzen Sie das Risiko, dass nicht autorisierte Änderungen vorgenommen werden, und führen dadurch unsichere Änderungen ein. Es sollte ein Ansatz mit den geringsten Rechten verwendet werden, um die Sicherungen zu schützen.

Um Daten ordnungsgemäß zu schützen, müssen Organisationen wissen, welche Daten ihre Umgebung/Systeme verbrauchen und wo die Daten gespeichert werden. Sobald dies vollständig verstanden und dokumentiert ist.

Organisationen sind dann in der Lage, nicht nur einen angemessenen Datenschutz zu implementieren, sondern auch in der Lage zu konsolidieren, wo sich die Daten befinden, um den Schutz effektiver zu implementieren. Wenn Daten an so wenigen Stellen wie möglich konsolidiert werden, ist es außerdem viel einfacher, eine angemessene rollenbasierte Zugriffssteuerung (RBAC) zu implementieren, um den Zugriff auf so wenige Mitarbeiter wie nötig zu beschränken.

Richtlinien:

Es sollten Nachweise aus dem verwendeten System/der verwendeten Technologie bereitgestellt werden, der die Zugriffsberechtigungen für die Sicherungen und Sicherungslösungen mit der unterstützenden Dokumentation der genehmigten Zugriffsliste belegt.

Beispielbeweis:

In den folgenden Screenshots ist zu sehen, dass Zugriffssteuerungen in der Datenbankinstanz implementiert sind, um den Zugriff auf autorisierte Personen basierend auf der Auftragsrolle einzuschränken.

Beispielbeweis:

Automatisierte Sicherungen von Azure SQL-Datenbank und Azure SQL Managed Instances werden von Azure verwaltet, und ihre Integrität liegt in der Verantwortung der Azure-Plattform. kein Benutzer hat Zugriff auf sie, und sie sind im Ruhezustand verschlüsselt, ohne die Möglichkeit von Ransomware-Angriffen. Sie werden zum Schutz auch in andere Regionen repliziert.

Datenzugriffsverwaltung

Der Datenzugriff muss auf so wenige Personen wie erforderlich beschränkt werden, um die Wahrscheinlichkeit zu verringern, dass Daten entweder böswillig oder versehentlich kompromittiert werden. Der Zugriff auf Daten und Verschlüsselungsschlüssel sollte auf Benutzer beschränkt werden, die einen legitimen geschäftlichen Bedarf an Zugang haben, um ihre Berufliche Rolle zu erfüllen. Es sollte ein gut dokumentiertes und gut etabliertes Verfahren zum Anfordern des Zugriffs implementiert werden. Der Zugriff auf Daten und Verschlüsselungsschlüssel sollte dem Prinzip der geringsten Rechte folgen.

Steuerung Nr. 8

Stellen Sie Beweise bereit, um zu zeigen, dass eine Liste von Personen mit Zugriff auf Daten und/oder Verschlüsselungsschlüssel:

• wird verwaltet, einschließlich der geschäftlichen Begründung für jede Person.

• wurden auf der Grundlage der Zugriffsberechtigungen, die für ihre Auftragsfunktion erforderlich sind, formal genehmigt.

• werden mit den in der Genehmigung beschriebenen Berechtigungen konfiguriert.

Absicht:

Organisationen sollten den Zugriff auf Daten und Verschlüsselungsschlüssel auf so wenige Mitarbeiter wie möglich beschränken. Mit dieser Kontrolle soll sichergestellt werden, dass der Zugriff der Mitarbeiter auf Daten und/oder Verschlüsselungsschlüssel auf Mitarbeiter beschränkt ist, die einen eindeutigen geschäftlichen Bedarf für diesen Zugriff haben.

Richtlinien:

Dokumentation oder Screenshots interner Systeme, die alle Mitarbeiter mit Zugriff auf Daten und/oder Verschlüsselungsschlüssel dokumentieren, sowie die geschäftliche Begründung, warum diese Personen Zugriff haben, sollten bereitgestellt werden. Diese Liste wird vom Zertifizierungsanalysten verwendet, um Benutzer für die nächsten Steuerelemente zu testen.

Beispielbeweis:

Das folgende Dokument zeigt die dokumentierte Liste der Benutzer mit Zugriff auf Daten und die geschäftliche Begründung.

Hinweis: Dieser Screenshot zeigt ein Richtlinien-/Prozessdokument. Es wird erwartet, dass ISVs die tatsächliche Unterstützende Richtlinien-/Verfahrensdokumentation freigeben.

Absicht:

Der Prozess zum Gewähren des Zugriffs auf Daten und/oder Verschlüsselungsschlüssel muss eine Genehmigung enthalten, um sicherzustellen, dass der Zugriff einer Person für ihre Funktion erforderlich ist. Dadurch wird sichergestellt, dass Mitarbeiter ohne echten Grund für den Zugriff keinen unnötigen Zugriff erhalten.

Richtlinien:

In der Regel können die für das vorherige Steuerelement bereitgestellten Beweise zur Unterstützung dieses Steuerelements beitragen. Wenn es keine formelle Genehmigung für die bereitgestellte Dokumentation gibt, kann der Beweis darin bestehen, dass eine Änderungsanforderung ausgelöst und für den Zugriff innerhalb eines Tools wie Azure DevOps oder Jira genehmigt wird.

Beispielbeweis:

Dieser Satz von Bildern zeigt Jira-Tickets, die erstellt und genehmigt wurden, um (i) den Zugriff auf vertrauliche Daten und/oder Verschlüsselungsschlüssel zu gewähren oder zu verweigern. Diese Abbildung zeigt, dass eine Anforderung in Jira erstellt wurde, um sam daily genehmigung für Verschlüsselungsschlüssel in der Back-End-Umgebung des Systems zu erhalten. Dies erfolgt als nächster Schritt, in dem die schriftliche Autorisierung erteilt wurde.

Dies zeigt, dass die Anforderung, Sam Daily Zugriff zu gewähren, von Jon Smith einer Person aus der Geschäftsleitung genehmigt wurde. (Bitte beachten Sie, dass die Genehmigung von einer Person mit ausreichender Autorität erfolgen muss, um die Änderungsanforderung zuzulassen. Es kann sich nicht um einen anderen Entwickler handeln).)

Das vorherige zeigt einen Workflow in Jira für diesen Prozess. Beachten Sie, dass nichts als Erledigt hinzugefügt werden kann, es sei denn, es wurde der Genehmigungsprozess durchlaufen, der automatisiert ist und daher nicht umgangen werden kann.

Der Project-Vorstand zeigt nun, dass der Zugriff von Sam Daily auf Verschlüsselungsschlüssel genehmigt wurde. Der folgende Backlog zeigt die Anforderungsgenehmigung von Sam Daily und die Person, die für die Arbeit zugewiesen ist.

Um die Anforderungen dieses Steuerelements zu erfüllen, müssen Sie alle diese Screenshots oder ähnliche/gleichwertige Beweise mit einer Erklärung anzeigen, die zeigt, dass Sie die Steuerungsanforderung erfüllt haben.

Bitte beachten Sie: In den vorherigen Beispielen wurden keine vollständigen Screenshots verwendet, jedoch müssen ALLE von ISV übermittelten Beweisscreenshots vollständige Screenshots mit der URL, allen angemeldeten Benutzern und Systemzeit und -datum sein.

Beispielbeweis:

Im nächsten Beispiel wurden Administratorzugriff und Vollzugriffsberechtigungen für einen Benutzer für die Produktionsdatenbank angefordert. Die Anforderung wurde zur Genehmigung gesendet, wie auf der rechten Seite des Bilds zu sehen ist, und dies wurde genehmigt, wie auf der linken Seite dargestellt.

Die nächste Abbildung zeigt an, dass der Zugriff genehmigt und abgemeldet wurde.

Bitte beachten Sie: In den vorherigen Beispielen wurden keine vollständigen Screenshots verwendet, jedoch müssen ALLE von ISV übermittelten Beweisscreenshots vollständige Screenshots mit der URL, allen angemeldeten Benutzern und Systemzeit und -datum sein.

Intent

Die Absicht dieses Unterpunkts besteht darin, zu bestätigen, dass der Daten- und/oder Verschlüsselungsschlüsselzugriff gemäß der Dokumentation konfiguriert ist.

Richtlinien:

Der Beweis könnte durch einen Screenshot bereitgestellt werden, der die Zugriffsberechtigungen für Daten und/oder Verschlüsselungsschlüssel zeigt, die den stichprobenierten Personen gewährt wurden. Nachweise müssen alle Speicherorte abdecken.

Beispielbeweis:

Dieser Screenshot zeigt die Berechtigungen, die dem Benutzer "John Smith" erteilt wurden, die kreuz

anhand der Genehmigungsanforderung für diesen Benutzer als Beweis für das vorherige Steuerelement verwiesen wird.

Bitte beachten Sie: Das folgende Beispiel ist keine Vollbild-Screenshots. Sie müssen Screenshots im Vollbildmodus mit jeder URL, angemeldetem Benutzer und dem Zeit- und Datumsstempel für die Beweisüberprüfung übermitteln. Wenn Sie ein Linux-Benutzer sind, kann dies über die Eingabeaufforderung erfolgen.

Steuerelement Nr. 9

Stellen Sie Beweise für Folgendes bereit:

• Eine Liste aller Drittanbieter, für die Daten freigegeben werden, wird verwaltet.

• Es bestehen Vereinbarungen zur Datenfreigabe mit allen Drittanbietern, die Daten verarbeiten.

Absicht:

Wenn Dritte für die Speicherung oder Verarbeitung von Microsoft 365-Daten verwendet werden, können diese Entitäten ein erhebliches Risiko darstellen. Organisationen sollten einen guten Due Diligence- und Managementprozess von Drittanbietern entwickeln, um sicherzustellen, dass diese Dritten Daten sicher speichern/verarbeiten, und um sicherzustellen, dass sie alle gesetzlichen Verpflichtungen einhalten, die sie möglicherweise haben, z. B. als Datenverarbeiter im Rahmen der DSGVO.

Organisationen sollten eine Liste aller Drittanbieter führen, mit denen sie Daten mit einigen oder allen folgenden Teilen teilen:

• welche Dienste bereitgestellt werden(werden)

• Welche Daten freigegeben werden

• Warum die Daten freigegeben werden

• Wichtige Kontaktinformationen (z. B. Primärer Kontakt, Kontakt zur Benachrichtigung über Sicherheitsverletzungen, DPO usw.)

• Vertragsverlängerung/Ablauf

• Rechtliche/Compliance-Verpflichtungen (d. h. DSGVO, HIPAA, PCI DSS, FedRAMP usw.)

Richtlinien:

Stellen Sie eine Dokumentation mit allen Drittanbietern bereit, für die Microsoft 365-Daten freigegeben werden.

Hinweis: Wenn Dritte nicht in Gebrauch sind, muss dies schriftlich (E-Mail) von einem Mitglied der Geschäftsleitung bestätigt werden.

Beispielbeweis:

Hinweis: - In den vorherigen Beispielen wurden keine vollständigen Screenshots verwendet, aber ALLE von ISV übermittelten Beweisscreenshots müssen vollständige Screenshots mit url, allen angemeldeten Benutzern und Systemzeit und -datum sein.

Beispielbeweis:

Der folgende Screenshot zeigt ein E-Mail-Beispiel für ein Mitglied des Leitenden Führungsteams, das bestätigt, dass keine Drittanbieter zur Verarbeitung von Microsoft 365-Daten verwendet werden.

Bitte beachten Sie: - In diesen Beispielen wurden keine vollständigen Screenshots verwendet, aber ALLE von ISV übermittelten Beweisscreenshots müssen vollständige Screenshots sein, die url, alle angemeldeten Benutzer und Systemzeit und -datum zeigen.

Absicht:

Wenn M365-Daten für Dritte freigegeben werden, ist es wichtig, dass die Daten angemessen und sicher verarbeitet werden. Vereinbarungen zur Datenfreigabe müssen eingerichtet werden, um sicherzustellen, dass Dritte Daten nur nach Bedarf verarbeiten und dass sie ihre Sicherheitsverpflichtungen verstehen. Die Sicherheit einer Organisation ist nur so stark wie das schwächste Glied. Mit dieser Kontrolle soll sichergestellt werden, dass Dritte nicht zu einem schwachen Glied der Organisation werden.

Richtlinien:

Stellen Sie die Vereinbarungen zur Datenfreigabe bereit, die mit den Drittanbietern bestehen.

Beispielbeweis:

Der nächste Screenshot zeigt ein einfaches Beispiel für eine Datenfreigabevereinbarung.

Hinweis: Die vollständige Vereinbarung sollte freigegeben werden und kein Screenshot.

Datenschutz

Datenschutzkonformität und Informationsmanagement sind für den Schutz der Rechte einzelner Personen und die Gewährleistung eines verantwortungsbewussten Umgangs mit Daten von entscheidender Bedeutung. Damit eine Organisation ein effektives Datenschutzinformationssystem einrichten kann, muss sie sich darüber im Klaren sein, welche personenbezogenen Daten sie speichern und zu welchem Zweck diese Daten verarbeitet und gespeichert werden. Eine Organisation sollte den Informationsfluss und die Art und Weise, wie dieser verarbeitet wird, zuordnen und dabei erkennen, dass verschiedene Arten der Verarbeitung auftreten können.

Steuerelement Nr. 10

Verfügt Ihre Organisation über ein PIM-System (Privacy Information Management), das eingerichtet, implementiert und verwaltet wird:

• Hält die Verpflichtung der Führung durch eine Richtlinie oder eine andere Form der Dokumentation/computerisiertes System, wie Ihre Bemühungen zur Verwaltung von Datenschutzinformationen im Bereich der Vertraulichkeit und Integrität des Systems aufrechterhalten werden.

• Bestimmt Rollen, Zuständigkeiten und Autoritäten jeder Person, die das System unterhält, einschließlich PII-Verarbeitern und Controllern.

Absicht:

Ziel dieses Punkts ist es, sicherzustellen, dass eine "Kultur der Privatsphäre" existiert und von der Führung der Organisation durch ein effektives Programm zur Datenschutzkontrolle unterstützt wird. Die Geschäftsleitung der Organisation muss über ihre etablierten Dokumentationen und Prozesse nachweisen, dass es ein effektives Datenschutzmanagementsystem gibt, dass diese Prozesse an den strategischen Zielen der Organisation ausgerichtet sind und innerhalb des Kontexts und der Umstände der Organisation festgelegt werden, sowie sicherstellen, dass das Datenschutzmanagementsystem in die Geschäftsprozesse eingebettet ist.

Richtlinien:

Dies würde durch die Bereitstellung der erstellten Dokumentation der Organisation belegt werden, die die Richtlinie und das Verfahren für das Datenschutzinformationsmanagement (PIM) enthält. Zertifizierungsanalysten überprüfen dies, um sicherzustellen, dass alle in der Kontrolle bereitgestellten Informationen berücksichtigt werden.

Beispielbeweis:

Die folgenden Screenshots zeigen Momentaufnahmen einer PIM-Richtlinie.

Hinweis: Es wird erwartet, dass ISVs die tatsächliche Dokumentation zu unterstützenden Richtlinien/Verfahren freigeben und nicht einfach einen Screenshot bereitstellen.

Intent

Verantwortlichkeit ist eines der wichtigsten Grundsätze im Datenschutzrecht, da sie es einer Organisation ermöglicht, die Risiken im Zusammenhang mit ihrem Umgang mit personenbezogenen Daten zu minimieren, indem geeignete und effektive Richtlinien, Verfahren und Prozesse implementiert werden. Diese Maßnahmen müssen in einem angemessenen Verhältnis zu den Risiken stehen, die je nach Der Menge der verarbeiteten oder übertragenen Daten, ihrer Vertraulichkeit und der verwendeten Technologie variieren können. Um dies zu erreichen, muss jeder Mitarbeiter wissen, wer für die verschiedenen Elemente des Datenschutzmanagementsystems verantwortlich ist, um eine erfolgreiche Implementierung sicherzustellen. Durch eine etablierte Dokumentation, in der die Rollen, Zuständigkeiten und Behörden klar definiert sind, und diese Rollen entsprechend zugewiesen werden, kann eine Organisation sicherstellen, dass ihr Datenschutzmanagementsystem effektiv ist.

Richtlinien:

Dies würde durch die Bereitstellung der erstellten Dokumentation der Organisation belegt werden, in der die Rollen, Zuständigkeiten und Behörden der einzelnen relevanten Personen beschrieben sind. Zertifizierungsanalysten überprüfen dies, um sicherzustellen, dass alle in der Kontrolle bereitgestellten Informationen berücksichtigt werden.

Beispielbeweis:

Die nächsten Screenshots zeigen Momentaufnahmen einer PIM-Richtlinie mit einem Abschnitt der Richtlinie, der die Liste der genehmigten Mitarbeiter enthält.

Hinweis: Es wird erwartet, dass ISVs die tatsächliche Dokumentation zu unterstützenden Richtlinien/Verfahren freigeben und nicht einfach einen Screenshot bereitstellen.

Steuerelement Nr. 11

Stellen Sie Nachweise für Prozesse bereit, um folgendes zu zeigen:

• Die PII-Minimierung findet statt.

• Die Aufhebung der Identifizierung und Löschung erfolgt am Ende des Verarbeitungszeitraums.

• Es gibt Kontrollen für die Übertragung personenbezogener Daten, einschließlich jeglicher Vertraulichkeit.

• Aufzeichnungen über die Übertragung personenbezogener Daten von einem Land/einer Region in eine andere liegen mit ausdrücklicher Zustimmung dazu vor.

Absicht: PII

Die Minimierung personenbezogener Informationen (Personally Identifiable Information) soll sicherstellen, dass eine Organisation nur die Mindestmenge an personenbezogenen Daten sammelt, verwendet und aufbewahrt, die erforderlich sind, um einen bestimmten Zweck innerhalb des Kontexts der Organisation und innerhalb der geschäftlichen Begründung zu erreichen. Beim Umgang mit personenbezogenen Daten muss eine Organisation ermitteln, welche Datenmenge am wenigsten benötigt wird, um dieses Ziel/diese Aufgabe zu erreichen, und sicherstellen, dass nicht mehr als die erforderlichen Mindestdaten gespeichert werden. Durch die Minimierung der Verarbeitung und Speicherung unnötiger personenbezogener Daten stellt eine Organisation sicher, dass das Risiko im Zusammenhang mit Datenmissbrauch, unbefugtem Zugriff und Datenschutzverletzungen reduziert wird.

Richtlinien: PII

Der Nachweis kann durch Konfigurationseinstellungen der Lösung bereitgestellt werden, die verwendet wird, um die Nutzung personenbezogener Informationen zu minimieren, wenn dies über eine automatisierte Plattform erfolgt, oder wenn ein manueller Verwaltungsprozess erfolgt, dann sollten dem Analysten beweise für den Minimierungsprozess und Nachweise der Aufzeichnungen des aufgetretenen Prozesses zur Überprüfung zur Verfügung gestellt werden.

Beispielbeweis: PII

Der folgende Screenshot zeigt, dass eine wiederkehrende monatliche Besprechung geplant ist, bei der alle neuen Daten, die innerhalb dieses Zeitraums innerhalb der Organisation empfangen wurden, überprüft werden und gegebenenfalls alle persönlichen Informationen entfernt werden, die als unnötig erachtet werden.

Im nächsten Screenshot sehen Sie ein Beispiel für ein ausgefülltes Benutzerregistrierungsformular, das zum Onboarding neuer Kunden innerhalb der Plattform verwendet wird.

Der nachfolgende Screenshot zeigt, dass basierend auf der Minimierungsbesprechung und Überprüfung von PII davon ausgegangen wurde, dass einige der vertraulichen Informationen, die im Formular gesammelt wurden, nicht mehr benötigt werden, um den Dienst wieder für den Benutzer bereitzustellen. In der nächsten Abbildung wurden die PII der Schiedsrichter sowie die E-Mail-Adresse entfernt (die Erwartung ist, dass jede Organisation eine geschäftliche Begründung für das Halten oder Entfernen dieser Informationen hat).

Hinweis: Das vorherige ist ein Beispiel für ein mögliches Szenario. Es ist keineswegs umfassend, und bei der Bereitstellung von Beweisen sollte der Prozess zur Minimierung von PERSONENBEZOGENen Informationen klar nachgewiesen werden und sollte für den spezifischen Kontext der Organisation gelten.

Absicht: Datenschutz

Die Absicht dieses Unterpunkts ist vielfältig und umfasst mehrere Techniken und verschiedene Konzepte, aber das allgemeine Ziel besteht darin, dass eine Organisation die Datenschutzbestimmungen erfüllt, indem sichergestellt wird, dass der Datenschutz in der gesamten Organisation verbessert wird.

Beginnend mit der Deidentifikation, bei der es sich um das Entfernen bestimmter Informationen handelt, die verwendet werden können, um eine Person aus Daten zu identifizieren, soll sichergestellt werden, dass alle als vertraulich eingestuften Informationen wie E-Mail-Adresse, Geburtsdatum usw. (durch verschiedene Techniken wie Pseudonymisierung oder Maskierung) in ein Format geändert/konvertiert werden, das es unbrauchbar macht, sie direkt mit einer Person zu verknüpfen. Der Zweck dieses Prozesses besteht nicht nur darin, den Nutzen der Daten zu erhalten, sondern auch sicherzustellen, dass das Risiko im Zusammenhang mit Datenmissbrauch, unbefugtem Zugriff und Datenschutzverletzungen reduziert wird.

Organisationen sollten die Datenaufbewahrung definieren und unnötige Daten am Ende des Verarbeitungszeitraums löschen. Sobald die Daten den definierten Aufbewahrungszeitraum überschreiten, müssen sie sicher gelöscht werden, um sicherzustellen, dass sie nicht wiederhergestellt oder wiederhergestellt werden können. Die Aufbewahrung notwendiger und so langer Daten trägt dazu bei, das Risiko für die Organisation im Falle einer Datenverletzung zu verringern. Dadurch wird sichergestellt, dass Daten weder übermäßig lange Zeit aufbewahrt noch vorzeitig gelöscht werden, was risiken unterschiedlicher Art darstellen kann – rechtlicher, betrieblicher oder sicherheitsbezogener Art.

Richtlinien: Datenschutz

Der Nachweis kann durch Konfigurationseinstellungen des Mechanismus und/oder der Technik erbracht werden, die verwendet werden, um sicherzustellen, dass PII-Daten im Einklang mit den Kontrollanforderungen anonymisiert und gelöscht werden.

Beispielbeweis: Datenschutz

Das Beispiel in den nächsten Screenshots verwendet die integrierte Daten anonymisierungsvorlage von Azure Data Factory, die Teil des Vorlagenkatalogs ist und es uns ermöglicht, eine Reihe von Textdateien von einem Speicherort an einen anderen zu verschieben, während deren Inhalt anonymisiert wird. Es zeigt, dass eine Data Factory in Azure für die Anonymisierung von PERSONENBEZOGENen Informationen vorhanden ist.

Der nächste Screenshot zeigt die Konfiguration der Pipeline zur Anonymisierung personenbezogener Daten. Es nutzt den Code für die Verwendung von Presidio in Azure App Service, um Presidio als HTTP-REST-Endpunkt in der Azure Data Factory-Pipeline aufzurufen, während jede Datei als Azure Blob Storage analysiert und gespeichert wird.

Der folgende Screenshot zeigt die Pipelineschritte und die Logik.

Der letzte Screenshot zeigt eine erfolgreiche Ausführung der Pipeline zur Anonymisierung von personenbezogenen Informationen.

Hinweis: Das vorherige ist ein Beispiel für ein mögliches Szenario. Es ist keineswegs umfassend, und bei der Bereitstellung von Beweisen sollte das Verfahren zur Anonymisierung von personenbezogenen Informationen klar nachgewiesen werden und sollte für den spezifischen Kontext der Organisation gelten.

Beispielbeweis: Datenschutz

Der folgende Screenshot zeigt ein Beispiel für das Löschen von personenbezogenen Informationen am Ende des Verarbeitungszeitraums durch Aktivieren einer Richtlinie für die Lebenszyklusverwaltung für das Speicherkonto in Azure, in dem personenbezogene Informationen gespeichert sind.

Der nächste Screenshot zeigt, dass die Aufbewahrung für einen vordefinierten Zeitraum festgelegt ist, nach dem die Daten automatisch gelöscht werden.

Hinweis: Das vorherige ist ein Beispiel für ein mögliches Szenario. Es ist keineswegs umfassend, und bei der Bereitstellung von Beweisen sollte das Verfahren zum Löschen von PERSONENBEZOGENen Daten und der spezifische aufbewahrungszeitraum klar nachgewiesen werden und sollte für den spezifischen Kontext der Organisation gelten.

Beispielbeweis: Datenschutz

Der letzte Screenshot zeigt, dass eine Aufbewahrungsrichtlinie für die Datenlebenszyklusverwaltung für die Datenübertragung und Speicherung von PII-Daten an verschiedenen Standorten innerhalb der Organisation vorhanden ist, z. B. SharePoint, OneDrive, Geräte, Postfach usw. Diese Richtlinie wird mithilfe von Microsoft Purview aktiviert. Die Aufbewahrungsrichtlinie ist so konfiguriert, dass alle personenbezogenen Daten nach Ablauf des vordefinierten Aufbewahrungszeitraums automatisch gelöscht werden.

Hinweis: Das vorherige ist ein Beispiel für ein mögliches Szenario. Es ist keineswegs umfassend, und bei der Bereitstellung von Beweisen sollte das Verfahren zum Löschen von PERSONENBEZOGENen Daten und der spezifische aufbewahrungszeitraum klar nachgewiesen werden und sollte für den spezifischen Kontext der Organisation gelten.

Absicht: Steuerelemente

Die Absicht dieses Unterpunkts besteht darin, sicherzustellen, dass Organisationen über geeignete technische und administrative/betriebliche Sicherheitsvorkehrungen verfügen, um personenbezogene Informationen während der Verarbeitung und Übertragung zu schützen. Der Schwerpunkt auf Vertraulichkeit bezieht sich auf den Schutz von Daten vor unbefugtem Zugriff und Offenlegung durch technische und administrative Kontrollen wie Verschlüsselung ruhender und übertragener Daten, dokumentierter Zugriffssteuerungslisten und regelmäßiger Überwachung.

Richtlinien: Steuerelemente

Der Nachweis kann durch Konfigurationseinstellungen der Schutzmechanismen erbracht werden, die verwendet werden, um sicherzustellen, dass PII-Daten gemäß den Kontrollanforderungen geschützt werden. Solche Mechanismen können Zugriffssteuerungen, RBAC, Verschlüsselung, Verhinderung von Datenverlust usw. umfassen.

Haftungsausschluss: Die gezeigten Beispiele zeigen einige mögliche Szenarien, in denen Steuerelemente angewendet werden, um sicherzustellen, dass PII geschützt sind. Beachten Sie, dass die Art der verwendeten Schutzmechanismen vom Kontext Ihrer Organisation und davon abhängt, wie PII verwendet, gespeichert usw. werden.

Beispielbeweis: Verschlüsselung

Die folgenden Beispiele zeigen die Verschlüsselung von PII am Speicherort, an dem PII gespeichert werden, und die Verschlüsselung während der Übertragung über die Webanwendung/Plattform, bei der Benutzer personenbezogene Informationen eingeben, die im Back-End der Anwendung gespeichert sind.

Die Screenshots zeigen, dass der Speicherort ruhende Daten standardmäßig verschlüsselt hat.

Beachten Sie, dass, wenn die Verschlüsselung nicht von der standardmäßig verwendeten Plattform und Ihrer eigenen Verschlüsselung durchgeführt wird.

-Schlüssel werden verwendet, dann wird erwartet, dass diese Schlüssel angemessen gesichert sind, und es werden Beweise bereitgestellt, um dies zu veranschaulichen.

Der zweite Screenshot zeigt, dass TLS1.2 während der Übertragung für die Anwendung erzwungen wird, in der personenbezogene Informationen erfasst werden.

Beispielbeweis: Zugriffssteuerungen

Der folgende Screenshot zeigt aus Netzwerkperspektive, dass nur der autorisierte/genehmigte IP-Adressbereich, der das sichere Unternehmensnetzwerk ist, auf den PII-Speicherort zugreifen darf.

Der nächste Screenshot zeigt ein Beispiel für Azure PIM und die Benutzerliste mit den berechtigten Zuweisungen. Durch die Verwendung des Just-in-Time-Zugriffs (JIT) können Benutzer für einen begrenzten Zeitraum vorübergehenden Zugriff auf eine privilegierte Rolle oder Ressource erhalten, was das Risiko verringert, dass ein privilegierter Benutzer kompromittiert wird oder Änderungen an der Umgebung, an den Datenspeicherorten usw. vornimmt.

Beispielbeweis: PiI-Übermittlung und Offenlegungsschutz

Diese Screenshots zeigen Microsoft Purview Data Loss Prevention (DLP), eine integrierte Plattform, mit der Organisationen ihre DLP-Richtlinien von einem zentralen Ort aus verwalten können.

Sie können unten sehen, dass eine Richtlinie für "U.K. PII-Daten" aktiviert ist. Dies bietet die Möglichkeit, zu verhindern, dass Benutzer vertrauliche Daten für bestimmte Websites bereitstellen, einschließlich persönlicher E-Mails, generativer KI-Eingabeaufforderungen, Social-Media-Websites und mehr, wenn sie über einen unterstützten Webbrowser aufgerufen werden. Dadurch wird sichergestellt, dass das Risiko potenzieller Vertraulichkeitsverstöße oder nicht autorisierter Offenlegung personenbezogener Daten durch Mitarbeiter verringert wird, da die Organisationsrichtlinie auf alle Geräte/Benutzer am Arbeitsplatz angewendet wird.

Die nächsten Screenshots bieten eine umfassende Übersicht über die Richtlinie, einschließlich des Bereichs, auf den sie angewendet wird. Die Richtlinie ist auf alle Konten an Speicherorten wie SharePoint, Geräte, OneDrive usw. festgelegt.

Der vorherige und der folgende Screenshot zeigt, dass die DLP-Richtlinie festgelegt ist, um zu verhindern, dass Benutzer vertrauliche Informationen wie personenbezogene Informationen (Personally Identifiable Information, PII) kopieren und einfügen.

aus den internen Datenbanken der Organisation in ihre persönlichen E-Mail-Konten, Chatbots und Social-Media-Websites auf unterstützten Browsern.

Absicht: Datensätze

Die Absicht dieses Unterpunkts ist zweifach; es stellt sicher, dass eine effektive Datensatzverwaltung zur Erleichterung der Datengovernance und des Datenschutzes vorhanden ist, während die Einhaltung und Rechenschaftspflicht gewährleistet wird, da die Übertragung personenbezogener Informationen in verschiedene Länder die Navigation durch verschiedene rechtliche Anforderungen umfasst. Vor der Einleitung einer Personenbezogenen Datenübermittlung muss eine Organisation sicherstellen, dass sie eine explizite Zustimmung der betroffenen Person(en) hat, zu der sie gehört. Diese Person(en) muss über die Übertragung, den Zweck der Übertragung und das damit verbundene Risiko informiert werden. Die Aufzeichnung der eingeholten Zustimmung bestätigt die Autorisierung der Übertragung. Die Aufzeichnung der Übertragung(en) sollte auch zusätzliche Details zur Übertragung, Risikobewertung, Auswirkungen auf den Datenschutz und Aufbewahrungszeitraum enthalten.

Richtlinien: Datensätze

Die Nachweise, die für Aufzeichnungen von PiI-Übertragungen und Aufzeichnungen der ausdrücklichen Zustimmung bereitgestellt werden können, hängen davon ab, wie der Übertragungsprozess und die Datensatzverwaltung auf Organisationsebene implementiert werden. Dies kann umfassen, ob die Zustimmung über eine Plattform, geschäftsbedingungen des Diensts oder über von jedem Benutzer ausgefüllte Einwilligungsformulare eingeholt wird. Die vorgelegten Beweise müssen zeigen, dass historische Aufzeichnungen der über einen Zeitraum durchgeführten Übertragungen vorhanden sind und wie diese nachverfolgt werden, sowie Aufzeichnungen über die eingeholte ausdrückliche Zustimmung.

Beispielbeweis: Datensätze

Der nächste Screenshot zeigt ein Beispiel für ein ausgefülltes Zustimmungsformular von einem der Benutzer der Dienste der Organisation. Wir können sehen, dass der Benutzer die explizite Zustimmung, Bestätigung und Das Verständnis der Bedingungen erteilt hat.

Der folgende Screenshot zeigt, dass eine historische Aufzeichnung von PII-Übertragungen vorhanden ist und Details zu den spezifischen piI-Daten enthält, die ausgetauscht werden, den Zweck der Übertragung, das Ursprungsland, das Zielland, den Schutz der Daten während der Übertragung, die Genehmigung usw.

Bitte beachten Sie: Das vorherige ist ein Beispiel für ein mögliches Szenario, es ist keineswegs umfassend, und bei der Bereitstellung von Beweisen sollte der Prozess für die Übertragung von PII-Daten, Datensatzverwaltung usw. klar veranschaulicht werden und sollte für den spezifischen Kontext der Organisation gelten.

DSGVO

Die meisten Organisationen werden Daten verarbeiten, bei denen es sich potenziell um Daten eines europäischen Bürgers (betroffene Personen) handelt. Wenn Daten einer betroffenen Person verarbeitet werden, müssen Organisationen die Datenschutz-Grundverordnung (DSGVO) einhalten. Dies gilt sowohl für Datenverantwortliche (Sie erfassen diese Daten direkt) als auch für Datenverarbeiter (Sie verarbeiten diese Daten im Auftrag eines Datenverantwortlichen). Obwohl dieser Abschnitt nicht die gesamte Verordnung behandelt, behandelt er einige der wichtigsten Elemente der DSGVO, um zu gewährleisten, dass die Organisation die DSGVO ernst nimmt.

Kontrolle Nr. 12

Stellen Sie Beweise bereit, die folgendes belegen:

• Betroffene Personen können SARs erheben.

• Überprüfen Sie, ob Sie (der ISV) in der Lage sind, alle Speicherorte der Daten betroffener Personen zu identifizieren, wenn sie auf eine SARs-Anforderung reagieren.

• Dass es einen Aufbewahrungszeitraum für Sicherungen gibt, der ermöglicht, dass Clients, die das Entfernen von Daten über SARs anfordern, entfernt werden können, wenn rollierende Sicherungen über einen Bestimmten Zeitraum entfernt werden (Lebenszyklus der ältesten Sicherungslöschungen/umgeschrieben).

Absicht:

Die DSGVO umfasst bestimmte Verpflichtungen, die von Organisationen erfüllt werden müssen, die Daten betroffener Personen verarbeiten. Die Verpflichtung für Organisationen zur Verwaltung von Anträgen auf Zugang von Personen (Subject Access Requests, SARs) ist in Artikel 12 enthalten, der gemäß Artikel 12.3 einem Datenverantwortlichen einen Monat nach Erhalt der SAR die Antwort auf die Anfrage erteilt. Eine Verlängerung ist bei Bedarf um weitere zwei Monate und nur dann zulässig, wenn dies gerechtfertigt ist. Selbst wenn Ihre Organisation als Datenverarbeiter fungiert, ist dies weiterhin erforderlich, um Ihren Kunden (dem Datenverantwortlichen) bei der Erfüllung ihrer SARs-Verpflichtungen zu helfen.

Richtlinien:

Geben Sie den dokumentierten Prozess für die Behandlung von SARs an. Beispielbeweis:

Das folgende Beispiel zeigt einen dokumentierten Prozess für die Behandlung von SARs.

Hinweis: Dieser Screenshot zeigt ein Richtlinien-/Prozessdokument. Es wird erwartet, dass ISVs die tatsächliche Unterstützende Richtlinien-/Verfahrensdokumentation freigeben.

Absicht:

Mit dieser Kontrolle soll sichergestellt werden, dass die Organisation über einen stabilen Mechanismus verfügt, um die Daten aller betroffenen Personen zu identifizieren. Dies kann ein manueller Prozess sein, da die gesamte Datenspeicherung gut dokumentiert ist oder andere Tools verwendet werden können, um sicherzustellen, dass alle Daten im Rahmen des SARs-Prozesses gespeichert werden.

Richtlinien:

Der Nachweis kann über eine Liste aller Speicherorte und einen dokumentierten Prozess zum Durchsuchen aller Speicherorte nach Daten bereitgestellt werden. Dies würde alle erforderlichen Befehle zum Suchen nach Daten umfassen, d. h., wenn SQL-Speicherorte enthalten sind, werden bestimmte SQL-Anweisungen detailliert beschrieben, um sicherzustellen, dass die Daten ordnungsgemäß gefunden werden.

Beispielbeweis:

Der nächste Screenshot ist ein Ausschnitt aus der vorherigen SAR-Prozedur, der zeigt, wie Daten gefunden werden.

Die folgenden vier Bilder zeigen, wie die ISV-Datenspeicherorte abgefragt wurden, und der Storage-Explorer wurde verwendet, um einen Drilldown zu den Dateien oder Blobs auszuführen, die aus dem Speicher entfernt werden mussten, um die SARs-Anforderung zu erfüllen.

Hinweis: Da es sich bei diesen Beispielen nicht um Screenshots im Vollbildmodus handelt, müssen Sie Screenshots im Vollbildmodus mit einer beliebigen URL, einem angemeldeten Benutzer und dem Zeit- und Datumsstempel zur Beweisüberprüfung übermitteln. Wenn Sie ein Linux-Benutzer sind, kann dies über die Eingabeaufforderung erfolgen.

Diese Abfrage bestätigt die verwendeten Speicherkonten. Sie können Speicher, Blobs und/oder Dateien mithilfe von Resource Graph-Explorer (Kusto) oder PowerShell (siehe weiter) abfragen und entfernen.

Hinweis: - Für die Beispiele in diesem Abschnitt wurden keine vollständigen Screenshots verwendet, aber ALLE von ISV übermittelten Beweisscreenshots müssen Vollbildscreenshots mit der URL, allen angemeldeten Benutzer und Systemzeit und -datum sein.

Die nächste Abbildung zeigt die Daten, die innerhalb des Blobcontainers für den Client gefunden wurden, der entfernt werden muss. Die folgende Abbildung zeigt die Aktion zum Löschen oder vorläufigen Löschen der Informationen im Blob.

Bitte beachten Sie: Die Beispiele sind keine Screenshots im Vollbildmodus. Sie müssen Screenshots im Vollbildmodus mit einer beliebigen URL, angemeldetem Benutzer und dem Zeit- und Datumsstempel für die Beweisüberprüfung übermitteln. Wenn Sie ein Linux-Benutzer sind, kann dies über die Eingabeaufforderung erfolgen.

Absicht:

Das Ziel dieser Kontrolle besteht darin, nachzuweisen, dass für Sicherungen ein formaler Aufbewahrungszeitraum besteht, der so konzipiert ist, dass die Entfernung von Daten gemäß SARs berücksichtigt wird. Das Aufbewahrungsframework sollte das Auslaufen älterer Sicherungen über einen definierten Zeitraum ermöglichen und sicherstellen, dass alle Daten, die aufgrund einer SAR entfernt wurden, letztendlich aus allen Sicherungen gelöscht werden. Dies ist wichtig, um die Sicherungs- und Datenaufbewahrungspraktiken der Organisation mit den Verpflichtungen aus SARs in Einklang zu bringen und so die gesetzlichen Anforderungen in Bezug auf das Recht auf Löschung zu erfüllen.

Richtlinien:

Der Nachweis kann durch einen Screenshot bereitgestellt werden, der die Sicherungskonfigurationseinstellungen zeigt, die den Zeitraum und die Methodik veranschaulicht, mit denen Sicherungen ausgeführt werden. Der Schwerpunkt sollte auf dem Zeitraum der Sicherungshäufigkeit liegen.

Beispielbeweis:

Der folgende Screenshot zeigt einen Ausschnitt der Konfigurationseinstellungen aus der Azure-Datenbank für MySQL, bei der es sich um eine verwaltete Instanz handelt.

Wir sehen im Screenshot, dass der Aufbewahrungszeitraum für Sicherungen auf 28 Tage festgelegt ist.

Basierend auf dem Sicherungsabschnitt wissen wir, dass Sicherungen auf flexiblen Servern momentaufnahmebasiert sind. Die erste Momentaufnahmesicherung wird unmittelbar nach der Erstellung eines Servers geplant und weitere Momentaufnahmesicherungen werden einmal täglich erstellt.

Die 28-tägige Sicherungsaufbewahrung in Kombination mit der Sicherungshäufigkeit bedeutet, dass die parallele Sicherung bei Erfüllung einer SAR für maximal 27 Tage rolliert und verringert wird, wie durch den Aufbewahrungszeitraum erzwungen, bis alle Benutzerdaten entfernt werden.

Regelung Nr. 13

Bitte geben Sie den Datenschutzhinweis an, der alle erforderlichen Elemente wie folgt enthalten sollte:

• Entitätsdetails (Name, Adresse usw.)

• Details zur Art der verarbeiteten personenbezogenen Daten.

• Gibt an, wie lange personenbezogene Daten aufbewahrt werden.

• Details zur Rechtmäßigkeit der Verarbeitung personenbezogener Daten.

• Details zu den Rechten der betroffenen Person:

  • Auskunftsrecht

  • Auskunftsrecht der betroffenen Person

  • Recht auf Löschung

  • Recht auf Einschränkung der Verarbeitung

  • Recht auf Datenübertragbarkeit

  • Widerspruchsrecht

  • Rechte im Zusammenhang mit automatisierter Entscheidungsfindung, einschließlich Profilerstellung

Absicht:

Artikel 13 der DSGVO enthält spezifische Informationen, die betroffenen Personen zum Zeitpunkt des Erhalts personenbezogener Daten zur Verfügung gestellt werden müssen. Mit dieser Kontrolle soll sichergestellt werden, dass die Datenschutzhinweise der Organisationen den betroffenen Personen einige der wichtigsten Informationen in Artikel 13 zur Verfügung stellen.

Richtlinien:

Dies wird in der Regel durch Die Bereitstellung des Datenschutzhinweises bereitgestellt. Zertifizierungsanalysten überprüfen dies, um sicherzustellen, dass alle informationen, die innerhalb der Kontrolle bereitgestellt werden, in den Datenschutzhinweisen aufgenommen werden.

Beispielbeweis:

Die nächsten Screenshots zeigen Momentaufnahmen einer Datenschutzrichtlinie.

Bitte beachten Sie, dass es sich bei diesen Beispielen nicht um Screenshots im Vollbildmodus handelt. Sie müssen Screenshots im Vollbildmodus mit einer beliebigen URL, einem angemeldeten Benutzer und dem Zeit- und Datumsstempel für die Überprüfung des Nachweises übermitteln. Wenn Sie ein Linux-Benutzer sind, kann dies über die Eingabeaufforderung erfolgen.

Die Bilder einer Datenschutzerklärung zeigen ein Beispiel für eine Online-Datenschutzrichtlinie mit Artikel 13 der DSGVO.

Nachfolgend finden Sie eine Datenschutzrichtlinie, die in Verbindung mit dem zuvor gezeigten Datenschutzhinweis verwendet werden kann.

Die vorherige Abbildung von Azure zeigt, wie Azure so konfiguriert wurde, dass es die Complianceanforderungen der DSGVO für Daten erfüllt, die in einer Back-End-Umgebung gespeichert sind. Die Richtlinie (die von Azure Blueprints angepasst oder erstellt werden kann) ermöglicht es dem ISV, sicherzustellen, dass die Daten des Clients ordnungsgemäß gespeichert werden und dass nur über die angegebenen Metriken darauf zugegriffen werden kann. Außerdem werden Warnungen festgelegt, um die Konformität sicherzustellen, und zeigen nicht konforme Daten oder den Benutzerzugriff auf dem Compliance-Manager-Dashboard an.

Bitte beachten Sie: Da es sich bei den vorherigen Beispielen nicht um Screenshots im Vollbildmodus handelt, müssen Sie Screenshots im Vollbildmodus mit einer beliebigen URL, angemeldetem Benutzer und dem Zeit- und Datumsstempel zur Beweisüberprüfung übermitteln. Wenn Sie ein Linux-Benutzer sind, kann dies über die Eingabeaufforderung erfolgen.

HIPAA (Health Insurance Portability and Accountability Act)

Der Health Insurance Portability and Accountability Act von 1996 (HIPAA) ist ein Bundesgesetz, das für amerikanische Bürger und Gesundheitsorganisationen gilt. Es ist wichtig zu beachten, dass diese Gesetzgebung auch alle Organisationen außerhalb der USA abdeckt, die Gesundheitsdaten amerikanischer Bürger verarbeiten. Die Einführung des Gesetzes ordnete den Sekretär des US-Gesundheitsministeriums (Department of Health and Human Services, HHS) an, Vorschriften zum Schutz der Privatsphäre und Sicherheit bestimmter Gesundheitsinformationen zu entwickeln. Einige Organisationen können Daten verarbeiten, bei denen es sich um potenziell geschützte Gesundheitsinformationen (ePHI) handelt, d. h. individuell identifizierbare Gesundheitsinformationen, die von elektronischen Medien übertragen, in elektronischen Medien aufbewahrt oder in einer anderen Form oder einem anderen Medium übertragen oder verwaltet werden. Wenn Gesundheitsdaten einer betroffenen Person verarbeitet werden, müssen Organisationen HIPAA erfüllen.

HIPAA verfügt über zwei Rechtsvorschriften, die berücksichtigt werden müssen: "Die Datenschutzregel" oder "Standards for Privacy of Individuell identifizierbare Gesundheitsinformationen", die die nationalen Standards für den Schutz bestimmter Gesundheitsinformationen beschreibt, und "Die Sicherheitsstandards" für den Schutz elektronischer geschützter Gesundheitsinformationen, die auch als "Sicherheitsregel" bezeichnet werden. Letzteres legt einen nationalen Satz von Sicherheitsstandards für den Schutz bestimmter Gesundheitsinformationen fest, die in elektronischer Form gespeichert oder übertragen werden.

Aus einer allgemeinen Übersicht ist "The Security Rule" eine praktische Implementierung der Schutzmaßnahmen, die die "Datenschutzregel" bietet. Sie beschreibt die technischen und nicht technischen Maßnahmen, die "betroffene Unternehmen" ergreifen müssen, um die Sicherheit der "elektronischen geschützten Gesundheitsinformationen" (e-PHI) des Einzelnen zu gewährleisten. Obwohl in diesem Abschnitt nicht die gesamte Verordnung behandelt wird, werden einige der wichtigsten Elemente von HIPAA behandelt, um zu gewährleisten, dass die Organisation die Anforderungen erfüllt und dass die Organisation die von ihr verarbeiteten Gesundheitsinformationen schützt.

Regelung Nr. 14

Geben Sie nachweisbare Beweise für Folgendes an:

• Es gibt eine Richtlinie für die HIPAA- und HIPAA-Behandlung innerhalb Ihrer Organisation für Mitarbeiter, Auftragnehmer usw.

• ISV stellt die Vertraulichkeit, Integrität und Verfügbarkeit von ePHI sicher, die er erstellt, empfängt, verwaltet oder überträgt.

• Schutz vor vernünftigerweise erwarteten Bedrohungen und Gefahren für die Sicherheit oder Integrität von ePHI.

Absicht:

Die Absicht dieses Unterpunkts besteht darin, sicherzustellen, dass Organisationen Protokolle eingerichtet haben, die als Standardverfahren für die Verwaltung von Gesundheitsinformationen, den Umgang mit Notfällen und Dienstunterbrechungen sowie den Zugriff der Mitarbeiter auf Gesundheitsinformationen und Schulungen dienen. Darüber hinaus wird von Organisationen erwartet, dass sie diese administrativen Sicherheitsvorkehrungen im Rahmen ihres HIPAA-Sicherheitsprogramms einhalten und erläutern. Dies ist ein wichtiger Aspekt bei der Einhaltung der HIPAA-Vorschriften.

Richtlinien:

Dies würde durch die Bereitstellung der erstellten Dokumentation der Organisation belegt werden, in der die HIPAA-Richtlinie und das Verfahren beschrieben sind. Zertifizierungsanalysten überprüfen dies, um sicherzustellen, dass alle in der Kontrolle bereitgestellten Informationen berücksichtigt werden.

Beispielbeweis:

Die Screenshots zeigen Momentaufnahmen einer HIPAA-Richtlinie. Hinweis: Es wird erwartet, dass ISVs die tatsächliche Dokumentation zu unterstützenden Richtlinien/Verfahren freigeben und nicht einfach einen Screenshot bereitstellen.

Hinweis: Es wird erwartet, dass ein ISV die tatsächliche umfassende Dokumentation zu unterstützenden Richtlinien/Verfahren teilt und nicht einfach einen Screenshot bereitstellt.

Absicht:

Um die Absicht dieses Unterpunkts zu verstehen und die Einhaltung der Sicherheitsregel sicherzustellen, müssen "abgedeckte Entitäten" zunächst wissen, wie die Begriffe für Vertraulichkeit, Integrität und Verfügbarkeit gemäß § 164.304 definiert sind:

• Vertraulichkeit: "die Eigenschaft, dass Daten oder Informationen nicht für unbefugte Personen oder Prozesse zugänglich gemacht oder offengelegt werden."

• Integrität: "Die Eigenschaft, dass Daten oder Informationen nicht auf nicht autorisierte Weise geändert oder zerstört wurden."

• Verfügbarkeit: "Die Eigenschaft, dass Daten oder Informationen auf Anfrage von einer autorisierten Person zugänglich und verwendet werden können."

Die Absicht dieser Anforderung besteht darin, dass die Organisationen technische Sicherheitsvorkehrungen/Maßnahmen wie Zugriff, Überwachung, Integrität und Übertragungskontrollen innerhalb der IT-Infrastruktur implementieren, um die Vertraulichkeit von ePHI sicherzustellen und gleichzeitig die Integrität und Verfügbarkeit für autorisierte Benutzer aufrechtzuerhalten.

Richtlinien:

Der Nachweis kann durch Konfigurationseinstellungen der Schutzmechanismen erbracht werden, die verwendet werden, um sicherzustellen, dass ePHI-Daten gemäß den Kontrollanforderungen geschützt werden. Solche Mechanismen können Zugriffssteuerungen, Notfallzugriffsverfahren, RBAC, Verschlüsselung usw. umfassen.

Beispielbeweis: Zugriffs- und Integritätskontrollen

Der nächste Screenshot zeigt, dass eine Autorisierte Zugriffsliste mit Personen, die über Berechtigungen zum Verarbeiten von ePHI-Speicherorten verfügen, vorhanden ist und innerhalb des HIPAA-Richtliniendokuments verwaltet wird. Darüber hinaus ist in den Screenshots nach der Liste der genehmigten Inventur zu sehen, dass der Schreibzugriff im gesamten Cluster eingeschränkt ist, sodass nur der Administrator und der Datenbankwartungsanalyst lese- und schreibfähig im Cluster ist.

Der nächste Screenshot aus einer der ePHI-Speicherdatenbanken in Atlas Mongo zeigt, dass nur autorisierte Benutzer über den dokumentierten Zugriff verfügen und dass alle Konten über eindeutige Benutzer-IDs verfügen, um die Verantwortlichkeit sicherzustellen.

Der erste Screenshot zeigt den Hauptspeicherort/Datenbankcluster für ePHI.

Der zweite Screenshot zeigt, dass die genehmigten Benutzer nur die Rollen und den Zugriff dokumentiert haben.

Die nächsten beiden Screenshots zeigen eine präzisere Ansicht jeder zugewiesenen Rolle und aller zugehörigen Berechtigungen, die mit der oben genannten Zugriffsgenehmigung im Einklang stehen.

Jede benutzerdefinierte Rolle verfügt über einen Satz von Berechtigungen und zugriffsbereich.

Der nächste Screenshot zeigt aus Netzwerkperspektive, dass nur der autorisierte IP-Adressbereich, der das sichere Unternehmensnetzwerk ist, auf den Cluster zugreifen darf.

Beispielbeweis: Überwachungskontrollen

Diese Screenshots zeigen, dass die Protokollierung und Warnungen für den Datenbankcluster implementiert sind. Der erste Screenshot zeigt, dass Warnungen aktiviert sind. Beachten Sie, dass die Erwartung besteht, dass der bereitgestellte Beweis auch die Warnungsregeln anzeigt, die basierend auf den Anforderungen/der Implementierung der Organisation festgelegt wurden. Der zweite Screenshot zeigt, dass die Datenbanküberwachung aktiviert ist.

Der nächste Screenshot zeigt den Zugriffsverlauf auf den Datenbankcluster, der aufgezeichnet wird. Es wird erwartet, dass Warnungen festgelegt werden und auf den Überwachungsprotokollen basieren, und jeder nicht autorisierte Zugriff, der die vordefinierten Bedingungen nicht erfüllt, löst eine Warnung aus.

Die letzten beiden Screenshots zeigen, dass Überwachungsprotokolle für den Datenbankcluster generiert werden und dass Protokolle zur Analyse exportiert werden können.

Bitte beachten Sie, dass es einen Prozess gibt, um die generierten Überwachungsprotokolle zu analysieren. Es müssen auch Nachweise für den Überprüfungsprozess bereitgestellt werden. Wenn dies programmgesteuert erreicht wird, müssen Screenshots der Konfigurationseinstellungen der Protokollerfassung in der verwendeten Plattform-/Protokollierungslösung sowie Screenshots der Regeln zur Überprüfung bereitgestellt werden.

Beispielbeweis: Verschlüsselungs- und Übertragungskontrollen

Die nächsten Screenshots zeigen, dass der Speicherort ruhende Daten standardmäßig verschlüsselt hat. Beachten Sie folgendes: Wenn die Verschlüsselung nicht von der standardmäßig verwendeten Plattform durchgeführt wird und Ihre eigenen Verschlüsselungsschlüssel verwendet werden, wird davon ausgegangen, dass diese Schlüssel angemessen geschützt sind, und beweise dafür bereitgestellt werden.

Die nächsten beiden Screenshots zeigen, dass der Speicherort daten während der Übertragung standardmäßig verschlüsselt hat. Der erste Screenshot zeigt, dass eine Daten-API mit Lese- und Schreibberechtigungen aktiviert ist.

Eine SSL-Überprüfung des Endpunkts zeigt, dass daten während der Übertragung über TLS 1.2 verschlüsselt werden.

Beispielbeweis: Verfügbarkeits- und Wiederherstellungskontrollen

Der nächste Screenshot zeigt, dass der Datenbankcluster in drei Regionen repliziert wird, um die Verfügbarkeit sicherzustellen. Dies erfolgt standardmäßig von Mongo Atlas. Darüber hinaus ist die Sicherung aktiviert und aktiv.

Der folgende Screenshot zeigt das Sicherungsdashboard des Clusters, das auch zeigt, dass bereits eine Momentaufnahme erstellt wurde.

Die nächsten beiden Screenshots zeigen, dass eine Sicherungsrichtlinie vorhanden ist, um geplante Sicherungen zu unterschiedlichen Zeitpunkten (PIT) durchzuführen.

Im Folgenden wird angegeben, dass eine Aufbewahrungsrichtlinie sowohl für Momentaufnahmen als auch für die Zeitpunktwiederherstellung (Point-in-Time Restore, PIT) vorhanden ist.

Absicht:

Die Absicht dieses Unterpunkts entspricht der Sicherheitsregel, die entwickelt wurde, um Flexibilität und Skalierbarkeit sicherzustellen, sodass eine "abgedeckte Entität" Richtlinien, Verfahren und technologische Lösungen implementieren kann, die für die Größe des Unternehmens, seine Organisationsstruktur und ihre spezifischen Risiken sowie für deren Risikobereitschaft geeignet sind. Aus praktischer Sicht bedeutet dies, dass die geeigneten Sicherheitsmaßnahmen von der Art des Geschäfts des "abgedeckten Unternehmens" sowie von seiner Größe und seinen Ressourcen abhängen.

Es ist wichtig, dass jede Organisation eine umfassende Risikoanalyse durchführt, um potenzielle Risiken und Schwachstellen für die Vertraulichkeit, Integrität und Verfügbarkeit von e-PHI aufzudecken. Durch diese Risikoanalyse können Organisationen dann geeignete Sicherheitskontrollen implementieren, um diese identifizierten Risiken zu mindern.

Richtlinien:

Der Nachweis kann durch die Ausgabe der Risikoanalyse erbracht werden. Wenn die Risikoanalyse über eine Onlineplattform durchgeführt und verwaltet wird, sollten Screenshots der gesamten Ausgabe bereitgestellt werden.

Beispielbeweis:

Die nächsten Screenshots zeigen Momentaufnahmen des Risikobewertungsprozesses, gefolgt von der Risikoanalyse, die durchgeführt wurde, um zu bestimmen, inwieweit Die Kontrollen ordnungsgemäß implementiert werden und wie sie zum Schutz der ePHI funktionieren. Der zweite Screenshot zeigt eine Risikoanalyse für die in der Risikobewertung identifizierten Risiken und die kompensierenden Kontrollen und Risikominderungen, die implementiert wurden, um das Risikoniveau zu verringern.

Beispiel 1: Momentaufnahme des Risikobewertungsprozesses innerhalb der HIPAA-Richtlinie und der durchgeführten Risikoanalyse

Hinweis: Dieser Screenshot zeigt eine Momentaufnahme eines Risikoanalysedokuments, dies ist nur ein Beispiel, und es wird erwartet, dass ISVs die tatsächliche Dokumentation freigeben und nicht einfach einen Screenshot bereitstellen.

Beispiel 2: Screenshots des Risikobewertungsprozesses innerhalb der HIPAA-Richtlinien- und Risikoanalyse (verwaltet in der Confluence Cloud Platform)

Der zweite Screenshot zeigt eine Risikoanalyse für die in der Risikobewertung identifizierten Risiken und die kompensierenden Kontrollen und Risikominderungen, die implementiert wurden, um das Risikoniveau zu verringern. Wir können sehen, dass dies vorhanden ist und in der Confluence-Cloudplattform verwaltet wird.

Kontrolle Nr. 15

Bitte weisen Sie nach, dass Sie (ISV):

• Schützt vor vernünftigerweise erwarteten Verwendungen oder Offenlegungen solcher Informationen, die nach der Datenschutzregel nicht zulässig sind; und

• Stellen Sie sicher, dass die Mitarbeiter die Sicherheitsregel einhalten.

• Datensicherungs- und Notfallwiederherstellungsplan unter 164..308 (a)(7)(ii)(A) und 164.308 (a)(7)(ii)(B).

Intent

Die Datenschutzregel definiert, welche Teile von geschützten Gesundheitsinformationen (Protected Health Information, PHI) vom Gesetz abgedeckt sind, und verbietet unsachgemäße Verwendung und Offenlegung von PHI. Die Absicht dieses Unterpunkts ist, dass eine Organisation den Zugriff und die Nutzung von e-PHI nur auf diejenigen beschränken muss, die es für autorisierte Zwecke benötigen, und dass sie die minimal erforderliche Regel einhalten muss, die erfordert, dass sie nur die Mindestmenge von e-PHI verwenden oder offenlegen muss, die zur Erreichung ihres beabsichtigten Zwecks erforderlich ist.

Es muss eine Kombination aus technischen und administrativen Sicherheitsvorkehrungen vorhanden sein, um die Verwendung von ePHI einzuschränken und sicherzustellen, dass das Risiko der Offenlegung des ePHI verringert wird.

Richtlinien:

Die bereitgestellten Beweise müssen die technischen Sicherheitsvorkehrungen wie Technologien und Mechanismen, die zum Schutz von e-PHI verwendet werden, und zeigen, wie die Organisation den Zugriff und die Bewegung solcher Daten kontrolliert.

Beispielbeweis:

Die nächsten Screenshots zeigen Microsoft Purview Data Loss Prevention (DLP), eine integrierte Plattform, mit der Organisationen ihre DLP-Richtlinien von einem zentralen Ort aus verwalten können.

Sie können unten sehen, dass eine Richtlinie "US HIPAA Enhanced" aktiviert ist. Dies bietet die Möglichkeit, zu verhindern, dass Benutzer vertrauliche Daten auf bestimmte Websites einfügen, einschließlich persönlicher E-Mails, generativer KI-Eingabeaufforderungen, Social-Media-Websites und mehr, wenn der Zugriff über einen unterstützten Webbrowser erfolgt.

Der nächste Screenshot bietet eine umfassendere Übersicht über die Richtlinie, einschließlich des Bereichs, auf den sie angewendet wird. Die Richtlinie ist auf alle Konten an Speicherorten wie SharePoint, Geräte, OneDrive usw. festgelegt.

Wenn Sie die Option "Richtlinie bearbeiten" auswählen, wird eine detailliertere Ansicht der spezifischen verfügbaren Konfigurationen angezeigt.

Die nächsten beiden Screenshots zeigen die Inhaltsdefinition und die Bedingungen, die erfüllt sein müssen, damit die Richtlinie angewendet wird.

Die Richtlinie deckt verschiedene vertrauliche Datentypen sowie eine Reihe von Klassifizierern ab.

Der nächste Abschnitt zeigt die Aktionen, die konfiguriert sind, wenn die in den vorherigen Screenshots gezeigten Bedingungen erfüllt sind.

Der folgende Screenshot zeigt, dass die DLP-Richtlinie festgelegt ist, um zu verhindern, dass ihre Benutzer vertrauliche Informationen wie personenbezogene Informationen (Personally Identifiable Information, PII) aus den internen Datenbanken der Organisation in ihre persönlichen E-Mail-Konten, Chatbots und Social-Media-Websites auf unterstützten Browsern kopieren und einfügen.

Schließlich werden Benutzerbenachrichtigungen so konfiguriert, dass sie Benachrichtigungen und Anleitungen für Benutzer bei der Verarbeitung von ePHI-Daten bereitstellen.

Der folgende Screenshot zeigt den Konfigurationsbereich zum Generieren von Warnungen, wenn ein Incident auftritt.

Absicht:

Die Absicht dieses Unterpunkts ist, dass eine Organisation ihre Mitarbeiter im sicheren und angemessenen Umgang mit e-PHI schulen muss, und dass sie Richtlinien und Verfahren erzwingen müssen, um die Einhaltung der Sicherheitsregel sicherzustellen.

Richtlinien:

Die bereitgestellten Beweise müssen zeigen, dass HIPAA-Training zum Umgang mit ePHI durchgeführt wird und dass Aufzeichnungen über Anwesenheit und Trainingsabschluss vorhanden sind. Dies kann ggf. durch Richtliniendokumentation und verwendete Schulungsmaterialien unterstützt werden.

Beispielbeweis:

Die folgenden Beispiele zeigen die potenziellen Beweise, die vorgelegt werden können, um zu zeigen, dass ein geeignetes HIPAA-Training im Einklang mit der Richtlinie erfolgt.

Der nächste Screenshot zeigt eine Momentaufnahme der HIPAA-Richtlinie mit einem bestimmten Abschnitt, in dem die Anforderung für das Training beschrieben wird. Bitte beachten Sie, dass dies nur ein Beispiel und kein umfassendes Dokument/eine umfassende Implementierung ist. Es wird davon ausgegangen, dass der ISV über einen etablierten Prozess verfügt, der auf seine Organisation anwendbar ist.

Beispiel 1: HIPAA-Benutzerschulung über verwaltungsverfahren

Im nächsten Screenshot zeigt die Folie mit der Kursübersicht eine Zusammenfassung der Kursziele. Wenn das Training inhouse erstellt wird, müssen die Schulungsmaterialien zur Überprüfung bereitgestellt werden. Bitte beachten Sie, dass das vollständige Material eingereicht werden muss und nicht nur ein Screenshot der Zusammenfassung.

Der folgende Screenshot zeigt den Anwesenheitseintrag für die Mitarbeiter, die an der Schulung teilgenommen haben. Der Datensatz zeigt auch die Passbewertung sowie das nächste geplante Trainingsdatum an.

Das zweite Beispiel zeigt, wie Microsoft 365 Defender zum Festlegen und Starten von Trainingskampagnen verwendet werden kann.

Beispiel 2: HIPAA-Benutzerschulung über die Microsoft 365 Defender Attack Simulation Platform (Alle Benutzer)

Der vorherige Screenshot zeigt die HIPAA-Sicherheitstrainingskampagne, die Gesamtdauer in Minuten sowie den Abschlussstatus. Der nächste Screenshot bietet eine Übersicht über die Benutzer, denen die Schulung zugewiesen wurde, und den Trainingsstatus, der den erfolgreichen Abschluss zeigt.

Beispiel 3: HIPAA-Benutzerschulung über die Microsoft 365 Defender Attack Simulation Platform (einzelner Benutzer)

Während sich das vorherige Beispiel darauf konzentrierte, zu zeigen, dass alle Benutzer die jährliche Schulungskampagne abgeschlossen haben, zeigt das letzte Beispiel gezielte Beweise für den Abschluss für einen Mitarbeiter.

Sie können in den beiden vorherigen Screenshots sehen, dass jeder Mitarbeiter, sobald die Schulungskampagne gestartet wurde, eine E-Mail mit der Bestätigung des Trainingsauftrags und des Fälligkeitsdatums sowie der zugewiesenen Module, der Dauer usw. erhalten hat.

Der folgende Screenshot zeigt mithilfe des in der E-Mail-Benachrichtigung verfügbaren Links die Seite "Trainingszuweisungen" für den Benutzer und die beiden module, die nun abgeschlossen wurden.

Absicht:

Gemäß der HIPAA-Sicherheitsregel sind ein Datensicherungsplan und ein Notfallwiederherstellungsplan für jede "abgedeckte Entität", die elektronische geschützte Gesundheitsinformationen (Electronic Protected Health Information, ePHI) verarbeitet, obligatorisch. Solche Pläne sind Teil der Notfallstrategie, die darauf abzielt, die Verfügbarkeit und Sicherheit von ePHI im Falle eines Notfalls oder eines anderen Ereignisses, das die Systeme, die ePHI enthalten, zu gewährleisten.

Die Absicht des Datensicherungsplans besteht darin, abrufbare identische Kopien von ePHI zu erstellen und zu verwalten. Dies sollte auch regelmäßige Tests der Sicherungen umfassen, um sicherzustellen, dass die Wiederherstellung von Daten möglich ist. Die Absicht des Notfallwiederherstellungsplans besteht darin, alle möglicherweise verlorenen Daten im Falle eines Notfalls wiederherzustellen. Dieser sollte die Schritte angeben, die ausgeführt werden müssen, um den Zugriff auf Daten wiederherzustellen, einschließlich der Art und Weise, wie Dateien aus Sicherungen wiederhergestellt werden sollen.

Richtlinien:

Geben Sie die Vollständige Version des Notfallwiederherstellungsplans/-verfahrens an, der den Sicherungsplan und den Wiederherstellungsplan abdecken sollte. Geben Sie das eigentliche PDF-/Word-Dokument an, wenn sie in einer digitalen Version vorliegen, oder wenn der Prozess über eine Onlineplattform verwaltet wird oder wenn der Export aufgrund von Einschränkungen der Plattform nicht möglich ist, geben Sie Screenshots an, die die gesamte Richtlinie abdecken.

Beispielbeweis:

Der nächste Screenshot zeigt Momentaufnahmen der HIPAA-Sicherheitsrichtlinie mit einer Übersicht über das allgemeine und allgemeine Sicherungsverfahren und den Notfallwiederherstellungsplan.

Hinweis: Dieser Screenshot zeigt eine Momentaufnahme des Richtlinien-/Prozessdokuments. Dies ist nur ein Beispiel, und es wird erwartet, dass ISVs die tatsächliche umfassende Dokumentation zu unterstützenden Richtlinien/Verfahren freigeben und nicht einfach einen Screenshot bereitstellen.

Bücher

Murdoch D. (2018) Blue Team Handbook: Incident Response Edition: A condensed field guide for the Cyber Security Incident Responding Responder. 2. Auflage, Herausgeber: CreateSpace Independent Publishing Platform.

Verweise

• Action Fraud Cyber Crime Reporting Verfügbar unter: https://www.actionfraud.police.uk/ (Zugriff: 10.12.2023).

• EU. (2021) DSGVO-Checkliste für Datenverantwortliche Verfügbar unter: https://gdpr.eu/checklist/ (Zugriff: 10.12.2023).

• Microsoft. (2018) Ereignisprotokollierung (Windows Installer) Verfügbar unter: Ereignisprotokollierung (Zugriff: 05.03.2024).

• Positive Technologien. (2020) Vorgehensweise bei der sicheren Softwareentwicklung Verfügbar unter: https://www.ptsecurity.com/ww-en/analytics/knowledge-base/how-to-approach-secure-software-development/(Abgerufen: 10.12.2023).

• Verordnung (EU) 2016/679 des Europäischen Parlaments und des Rates vom 27. April 2016 zum Schutz natürlicher Personen bei der Verarbeitung personenbezogener Daten und zum freien Verkehr dieser Daten und zur Aufhebung der Richtlinie 95/46/EG (Datenschutz-Grundverordnung) (Text von Bedeutung für den EWR) (2016) Verfügbar unter: https://www.legislation.gov.uk/eur/2016/679/contents (Zugriff: 12.10.2023).

• Sicherheitsmetriken. (2020) Leitfaden zu Sicherheitsmetriken zur PCI-DSS-Compliance. Verfügbar unter: https://info.securitymetrics.com/pci-guide-2020(Zugriff: 10.12.2023).

• Williams J. OWASP Risk Ranking Verfügbar unter: https://owasp.org/www-community/OWASP_Risk_Rating_Methodology (Zugriff: 10.12.2023).

• Qualys. (2014) SSL Labs: New Grades for Trust (T) and Mismatch (M) Issues Available at: https://blog.qualys.com/product-tech/2014/06/17/ssl-labs-new-grades-for-trust-t-and-mismatch-m-issues (Zugriff: 10.12.2023).

• NIST SP800-61r2: Leitfaden zur Behandlung von Computersicherheitsvorfällen Verfügbar unter: https://csrc.nist.gov/publications/detail/sp/800-61/rev-2/final (Zugriff: 10.12.2023).

• Erstellen einer CI/CD-Pipeline mit Azure Pipelines und Google Kubernetes Engine | .NET

• Google Cloud (Zugriff: 10.10.2023).

• Der Notfallwiederherstellungsplan unter: https://www.sans.org/white-papers/1164/ (Zugriff: 10.10.2023).

• https://github.com/ (Zugriff: 10.10.23).

• Sicherheitsrichtlinienvorlagen unter: https://www.sans.org/information-security-policy/ (Zugriff: 10.10.23).

• https://www.openedr.com/ (Zugriff: 02/10/23).

• https://www.atlassian.com/software/confluence (Zugriff: 10.10.23).

• https://www.atlassian.com/software/jira (Zugriff am 28.09.23).

• Business Continuity Plan (BCP) Table Top Exercise Template at: https://www.pivotpointsecurity.com/services/business-continuity-management/table-top-exercise-template/ (Zugriff: 10/10/23).

• Zusammenfassung der HIPAA-Sicherheitsregel | HHS.gov (Zugriff: 18.10.2023).

• Gesundheitsdatenschutzgesetze im digitalen Zeitalter: HIPAA gilt nicht – PMC (nih.gov) (Zugriff: 18/10/2023).

• Was ist der Zweck von HIPAA? Update 2023 (hipaajournal.com) (Zugriff: 18.10.2023).

• Was ist als PHI unter HIPAA betrachtet? Update 2023 (hipaajournal.com) (Zugriff: 18.10.2023).

• HIPAA-Richtlinien und -Verfahren (hipaajournal.com) (Zugriff: 10.18.2023).

• Entwerfen von HIPAA-Richtlinien & administrativen Richtlinien | Dash Solutions (dashsdk.com) (Zugriff: 18.10.2023).

• 45 CFR § 164.304 - Definitionen. | Electronic Code of Federal Regulations (e-CFR) | US-Recht | LII

• / Legal Information Institute (cornell.edu) (Zugriff: 18.10.2023).

• Was ist HIPAA-Compliance? HIPAA-Gesetze & Regeln | Proofpoint UK (Zugriff: 18.10.2023).

• HIPAA Security Rules, Regulations and Standards (training-hipaa.net) ( Zugriff: 18/10/2023).

• Zusammenfassung der HIPAA-Sicherheitsregel | HHS.gov (Zugriff: 18.10.2023).

• SP 800-66 Rev. 1, Ein einführender Ressourcenleitfaden für die Implementierung derHIPAA-Sicherheitsregel (Portability and Accountability Act) für Krankenversicherungen | CSRC (nist.gov) (Zugriff: 18.10.2023).

• Die Sicherheitsregel | HHS.gov (Zugriff: 18.10.2023).

• https://www.hipaajournal.com/hipaa-encryption-requirements (Zugriff: 19.10.2023).

• https://www.hipaajournal.com/hipaa-privacy-rule/ (Zugriff: 19.10.2023).

• https://www.hhs.gov/hipaa/for-professionals/security/laws-regulations/index.html (Zugriff: 19.10.2023).

• https://www.restore.co.uk/Records/Services/Magnetic-Tape-Storage (Zugriff: 19.10.2023).

• https://www.tausight.com/the-ultimate-guide-to-electronic-protected-health-information- ephi/ (Zugriff: 19/10/2023).

• Konfigurieren der Verschlüsselung – MongoDB-Handbuch (Zugriff: 10.19.2023).

• https://its.ucsc.edu/policies/docs/hipaa-risk-analysis.doc (Zugriff: 19.10.2023).

• Microsoft Purview Data Loss Prevention: Ankündigung der allgemeinen Verfügbarkeit mehrerer Funktionen

• Microsoft Community Hub (Zugriff: 24.10.2023).

• 45 CFR § 164.308 - Verwaltungsvorkehrungen. | Electronic Code of Federal Regulations (e-CFR)

• | US-Recht | LII / Legal Information Institute> (cornell.edu) (Abgerufen: 24.10.2023).

• https://www.iow.nhs.uk/Downloads/Policies/Business%20Continuity%20Policy.pdf (Zugriff: 24.10.2023).

• Wann sollten wir Datenschutzinformationen bereitstellen? | ICO (Zugriff: 11.08.2023).

• Wie sollten wir unsere Datenschutzinformationen entwerfen? | ICO (Zugriff: 11.08.2023).

• Accountability Framework | ICO (Zugriff: 08/11/2023).

• ISO 27001 Anforderung 5.1 – Verpflichtung zur Führung & | ISMS.online (Zugriff: 11.08.2023).

• Online Browsing Platform (OBP) (iso.org) (Zugriff: 08/11/2023).

• Klausel 5.3 Organisationsrollen, Zuständigkeiten und Autoritäten – ISO-Schulung (Zugriff: 08/11/2023).

• 5.3 Rollen, Verantwortung und Autorität (iso9001help.co.uk) (Zugriff: 11.08.2023).

• Prinzip (c): Datenminimierung | ICO (Zugriff: 08/11/2023).

• Aufheben der Identifizierung und Erneuten Identifikation von personenbezogenen Daten in großen Datasets unter Verwendung des Schutzes vertraulicher Daten| Cloud Architecture Center | Google Cloud (Zugriff: 11.08.2023).

• Aufheben der Identifizierung vertraulicher Daten | Dokumentation zum Schutz vertraulicher Daten | Google Cloud (Zugriff: 11.08.2023).

• Leitfaden zur Datensicherheit | ICO (Zugriff: 08/11/2023).

• Internationale Datenübertragungen | ICO (Zugriff: 08/11/2023).

• Datensatzverwaltung und -sicherheit | ICO (Zugriff: 08/11/2023).

• ISO 27701 – Datenschutzinformationsmanagement (Zugriff: 08/11/2023).

• ISO 27701 Privacy Information Management System (PIMS) | ISMS.Online (Zugriff: 11.08.2023).

Bilder/Text aus Microsoft-Dokumenten

• https://www.sans.org/information-security-policy/ (Zugriff: 18/02/21).

• Abrufen von Verhaltensanalysen und Anomalieerkennung (Zugriff: 05.03.24).

• Was sind Azure Monitor-Warnungen? (Zugriff: 03/05/24).

• Abrufen von Verhaltensanalysen und Anomalieerkennung

• (Zugriff: 03/05/24).

• Verwalten und Reagieren auf Sicherheitswarnungen in Microsoft Defender für Cloud (Zugriff: 05.03.24).

• Verwalten und Reagieren auf Sicherheitswarnungen in Microsoft Defender für Cloud (Zugriff: 05.03.24).

• https://microsoft.github.io/AzureTipsAndTricks/blog/tip272.html (Zugriff: 09/10/23).

• Was ist Azure Information Protection?

• Transparente Datenverschlüsselung für SQL-Datenbank, SQL Managed Instance und Azure Synapse Analytics (Zugriff:03.05.24).

• Schnellstart: Erstellen einer Richtlinienzuweisung zum Identifizieren nicht konformer Ressourcen (Zugriff: 05.03.24).

• Konfigurieren von Advanced Threat Protection für Azure SQL-Datenbank (Zugriff: 05.03.24).

• Sicherung und Wiederherstellung in Azure Database for MySQL – Flexible Server (Zugriff: 05.03.24).

• Zertifikatbestand (Zugriff: 05.03.24).

• Sicherung und Wiederherstellung in Azure Database for MySQL (Zugriff: 05.03.24).

• https://github.com/microsoft/presidio/blob/main/docs/samples/deployments/data- factory/presidio-data-factory-template-gallery-http.md (Zugriff: 11.08.2023).

Weitere Informationen

• Leitfaden für Beispielbeweise – Übersicht
• Leitfaden zu Beispielen für Nachweise – Vorgänge