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 Ihrem organization 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 der organization die Daten jedoch nicht benötigt, um seine Dienst- oder Geschäftsfunktion auszuführen, sollten die Daten nicht gespeichert werden, da dies das Risiko der organization unnötig erhöht.

Ziel dieser Kontrolle ist es, zu bestätigen, dass die organization einen genehmigten Datenaufbewahrungszeitraum für alle relevanten Arten von Daten 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 gesetzliche 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 organization 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, einschließlich Datenbanken, Dateifreigaben, Archiven und Sicherungen) die definierte Datenaufbewahrungsrichtlinie nicht überschreiten. Beispiele für zulässige Screenshots:

• Datenbankdatensätze mit einem Datumsfeld, das in der Reihenfolge der ältesten Datensätze durchsucht wird, und/oder
• Dateispeicherorte mit Zeitstempeln, die innerhalb des Aufbewahrungszeitraums liegen. Hinweis: Alle persönlichen oder sensiblen Kundendaten sollten im Screenshot bearbeitet werden.
• Sicherungsdatensätze, die zeigen, dass Sicherungsdaten innerhalb des definierten Aufbewahrungszeitraums aufbewahrt und nach diesem Zeitraum ordnungsgemäß gelöscht 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 das organization über ein automatisiertes Sicherungssystem verfügt, das so konfiguriert ist, dass Sicherungen zu vordefinierten Zeiten ausgeführt werden.

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 die Azure Database for MySQL, bei der es sich um eine verwaltete instance 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 sind Momentaufnahme, wobei die erste Momentaufnahme Sicherung unmittelbar nach der Erstellung eines Servers geplant wird und weitere Momentaufnahme Sicherungen einmal täglich erstellt werden.

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

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, die diesem Steuerelement entsprechen, hängen vom Prozess des organization und dem Verfahren 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 des Azure Database for MySQL aus einem 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 sind, von denen die Datenbank wiederhergestellt wird, können wir die Bereitstellung initiieren. Beachten Sie, dass unsere Datenbank-instance jetzt "test" heißt.

Nach insgesamt fünf Minuten wurde die SQL-Datenbank erfolgreich und vollständig aus dem Sicherungs-Momentaufnahme wie folgt wiederhergestellt.

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 der organization 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 Datenbank implementiert sind instance, um den Zugriff auf autorisierte Personen basierend auf der Rolle des Auftrags einzuschränken.

Beispielbeweis:

Azure SQL Automatisierte Sicherungen von Datenbanken und Azure SQL verwalteten Instanzen werden von Azure verwaltet, und ihre Integrität liegt in der Verantwortung der Azure-Plattform. Kein Benutzer hat Zugriff darauf, und sie werden im Ruhezustand verschlüsselt, ohne dass die Möglichkeit von Ransomware-Angriffen besteht. 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 ein organization ein effektives Datenschutzinformationssystem einrichten kann, muss er sich darüber im Klaren sein, welche personenbezogenen Daten er enthält und zu welchem Zweck diese Daten verarbeitet und gespeichert werden. Ein organization sollte den Informationsfluss und die Art der Verarbeitung zuordnen, wobei erkannt wird, dass verschiedene Arten der Verarbeitung auftreten können.

Kontrolle Nr. 10 – Personenbezogene Daten

Stellen Sie beweise, dass Ihre organization:

A) Führt ein aktuelles Inventar aller erfassten, verarbeiteten und gespeicherten personenbezogenen Daten, einschließlich des Zwecks für jedes Datenelement. 

B) Entwirft Datensammlungsformulare so, dass sie nur Felder enthalten, die für den Geschäftszweck erforderlich sind, und implementiert pflicht- und optionalen Felder entsprechend. 

C) Entwickelt und erzwingt Richtlinien, die die Arten von personenbezogenen Daten, die gesammelt werden können, und die Zwecke, für die sie verwendet werden können, angeben. 

D) Ermöglicht benutzern, die Verarbeitung oder breite Verbreitung ihrer persönlichen, nicht geschäftlichen wesentlichen Daten zu deaktivieren. 

Absicht:

Mit dieser Kontrolle soll sichergestellt werden, dass Sie den Datenschutz einhalten, der sich auf die Sammlung von Daten bezieht, um sicherzustellen, dass es eine Rechtfertigung für die erfassten Daten gibt und transparent ist, was und warum Daten gesammelt werden. Es ist auch wichtig, dass Benutzer (betroffene Personen) die Möglichkeit haben, die Verarbeitung zu deaktivieren.  

Richtlinien:

Dieses Steuerelement könnte wie folgt belegt werden:

A) Stellen Sie eine aktuelle Version des Datensatzes der Verarbeitungsaktivitäten (RoPA) des organization (siehe Artikel 30 der DSGVO) oder ein ähnliches Dokument bereit, in dem die Datenelemente und der Zweck der Verarbeitung ausführlich beschrieben sind (siehe Dsgvo Artikel 5.1.b). 

In den meisten Fällen wäre dies eine Excel-Tabelle (die aus Tools wie OneTrust extrahiert werden könnte). 

Wenn die Datei zu groß ist oder vertrauliche Daten enthält, kann ein Auszug bereitgestellt werden, der alle Datenfelder für eine bestimmte Stichprobe von Daten zeigt, die teilweise bearbeitet werden können, solange die Beweise die Sicherheit bieten können, dass die RoPA vorhanden ist. 

Nicht konform: Die Datensätze sind nicht vorhanden, sind sehr alt/veraltet oder fehlen Schlüsselfelder. 

B) Stellen Sie zum Zweck der "Datenminimierung" (siehe Dsgvo-Artikel 5.1.c) alle Formulare bereit, die zum Abrufen von Daten verwendet werden, sei es online, mit Tablets oder ähnlichen Geräten (z. B. in einer Konferenz) oder Papier. Diese können leere Vorlagen sein. 

Nicht konform: Die Formulare enthalten Pflichtfelder, die für den beabsichtigten Zweck der Verarbeitung nicht erforderlich sind. Beispielsweise die Frage nach Telefonnummern, Alter oder Geschlecht, um eine Broschüre per E-Mail oder an eine Postanschrift zu senden.  

C) Aus Gründen der "Rechtmäßigkeit, Fairness und Transparenz" (siehe DSGVO-Artikel 5.1.a) muss die Datenschutzrichtlinie (für Mitarbeiter bestimmt) die Datenschutzerklärung (für Benutzer/Kunden) eingerichtet werden. In der Regel sollte der Datenschutzhinweis auf der Website der organization öffentlich verfügbar sein.  

Nicht konform: Die Richtlinien sind nicht vorhanden oder es fehlen Schlüsselelemente. 

Wichtige Elemente:

Datenschutzerklärung/Hinweis: Erhebung und Nutzung von Informationen, verarbeitete Datenelemente, Zweck(en) der Verarbeitung, Rechtmäßigkeit der Verarbeitung, Datenübertragungen in andere Länder, Rechte betroffener Personen, Datenspeicherung und -aufbewahrung.  

D) Für den Opt-Out-Mechanismus (siehe Artikel 4.11 der DSGVO, Artikel 6 der DSGVO und Artikel 7 der DSGVO), in der Regel auf einer Webseite. Überprüfen Sie die Navigation, der der Benutzer folgen muss, um zu dieser Seite zu gelangen (z. B. ist sie leicht zu finden?). 

Nicht konform: Keine klare Opt-Out-Funktionalität oder "generisches" Opt-Out ohne Granularität. 

Beispielbeweis:

Für A):

Für B):

Für C):

Für D):

Steuerung Nr. 11 – Benutzerbewusstsein

Stellen Sie Beweise bereit, die Benutzern Folgendes bekannt sind:

A) wer Zugriff auf seine Daten hat

B) wer Zugang zu den Räumen hat, in denen er arbeitet

C) wer zugriff auf seine Daten durch Freigabe oder Datenflüsse erhalten könnte, damit er fundierte Entscheidungen treffen kann.

Absicht:

Mit dieser Kontrolle soll nachgewiesen werden, dass das Datenschutzprinzip "Transparenz" (siehe DSGVO-Artikel 5.1.a) erfüllt ist.

Richtlinien:

Um dies zu demonstrieren, sollte idealerweise eine Form der Benutzerbestätigung (z. B. um die Datenschutzrichtlinie gelesen zu haben) vorhanden und aufgezeichnet werden.

In der Praxis bieten nur die Datenschutzrichtlinie (für Mitarbeiter) und die Datenschutzerklärung (für Benutzer und Kunden) ausreichende Details zu den folgenden:

- An wen personenbezogene Daten weitergegeben werden (Auftragsverarbeiter, Unterauftragsverarbeiter, Dritte, Auftragnehmer usw.).

Nicht konform: Es liegen keine Bestätigungen vor, oder die Datenschutzrichtlinie/Datenschutzerklärung ist nicht vorhanden.

Beispielbeweis:

OR

Kontrolle Nr. 12 – Vereinbarungen zur Datenverarbeitung (DATA Processing Agreements, DPAs)

Stellen Sie einen Nachweis für die Datenverarbeitungsvereinbarung bereit, die eine Liste aller genehmigten 3. Parteien/Unterverarbeiter enthalten sollte.

Absicht:

Um sicherzustellen, dass Sie gegenüber den betroffenen Personen transparent sind und sicherstellen, dass sie darüber informiert werden, welche Dritten/Unterauftragsverarbeiter Zugriff auf ihre Daten haben könnten, welche Rolle sie bei der Verarbeitung spielen (Datenverantwortlicher, Datenverarbeiter), ihre jeweiligen Zuständigkeiten und Sicherheitsmechanismen.

Auch wenn die Weitergabe von Daten datenübermittlungen in Gebiete außerhalb der EU (dsgvo) umfassen würde, sind Details des Mechanismus, um sicherzustellen, dass die Übertragungen rechtmäßig sind. (Siehe DSGVO Artikel 5 und DSGVO Artikel 44-50)

Für die DSGVO müssen die Für die Verarbeitung vorgesehenen Gebiete eine der folgenden Bedingungen erfüllen:

- Ein Mitgliedstaat der Europäischen Union sein.

- Von der Europäischen Kommission als "angemessene Garantien" angesehen werden. Die aktuelle Liste finden Sie hier: Angemessenheit des Datenschutzes für Nicht-EU-Länder

Stand: 13^. Juni 2025:

- Seien Sie Teil des Datenschutz-Frameworks (DPF), und werden Sie hier aufgeführt: Datenschutz-Framework

– Binden von Unternehmensregeln (Binding Corporate Rules, BCRs)

- Standard Vertragsklauseln (SC) eingerichtet haben.

Richtlinien:

Der Beweis könnte durch stichprobenweise eine Reihe von Datenverarbeitungsvereinbarungen (Data Processing Agreement, DPA) mit vorhandenen Unterverarbeitern sein. In bestimmten Fällen verfügen Organisationen möglicherweise nicht über DPAs, sondern über Nachtrage zu Verträgen oder "Datenschutzklauseln".

Nicht konform:

- Die Liste der 3^rd-Parteien / Unterverarbeiter fehlt.

- Es werden keine Details zu den Empfängerländern angegeben.

- Die Länder sind nicht als "geeignete Länder" aufgeführt, und es gibt keine BCRs oder SC.

Beispielbeweis:

Dieses Beispiel zeigt ein Beispiel für eine DPA von IAPP, oder ein Beweis könnte ein verwandtes Dokument sein, das die Parteien auflistet, für die die Daten freigegeben werden.

Überprüfen Sie außerdem die Mechanismen für Datenübertragungen außerhalb der EU.

Kontrolle Nr. 13 – Datenschutz-Folgenabschätzungen (DPIAs)

Nachweisen, dass Ihr organization Datenschutz-Folgenabschätzung (Data Protection Impact Assessment, DPIA) durchführt

     OR

Geben Sie den Namen der Bewertung im Zusammenhang mit Datenschutz und Datenschutz an, mit der diese Datenschutzüberprüfung verknüpft ist.

Absicht:

Mit dieser Kontrolle soll sichergestellt werden, dass Sie die potenziellen Risiken für die Rechte und Freiheiten von Personen bewerten, insbesondere im Zusammenhang mit der Einführung neuer Technologien oder der neuartigen Verwendung bestehender Technologien. (Siehe DSGVO-Artikel 35)

Richtlinien:

Diese Kontrolle würde durch Überprüfen einer aktuellen DPIA oder einer zugehörigen Bewertungsdokumentation bewertet werden.

Nicht konform:

Eine DPIA sollte die folgenden Elemente aufweisen:

- Identifizierung der Notwendigkeit einer DPIA.

- Beschreibung der geplanten Verarbeitung, einschließlich Umfang, Kontext und Zweck(en).

- Bewertung der Notwendigkeit und Verhältnismäßigkeit.

- Ermittlung und Bewertung von Risiken.

- Ermittlung von Maßnahmen zur Risikominderung.

- Aufgezeichnete Ergebnisse.

Wenn eines der oben genannten Elemente fehlt oder nur auf einer perfunktory-Ebene ausgeführt wird, kann dieses Steuerelement als nicht konform markiert werden.

Beispielbeweis:

Die vollständige Vorlage einer DPIA finden Sie auf der Website des ICO hier dpia-template.docx

Kontrolle Nr. 14 – Biometrische Daten

Interagiert die Anwendung mit biometrischen Daten? Falls ja,

Nachweisen, dass biometrische Daten die rechtliche Überprüfung bestanden haben, geschützt sind und die Benutzer informiert sind und die Möglichkeit erhalten, die Erfassung biometrischer Daten zu aktivieren bzw. zu deaktivieren.

Absicht:

Diese Kontrolle ist an einem angemessenen Schutz biometrischer Daten interessiert, der gemäß Artikel 9 der DSGVO als besondere Kategorie von Daten eingestuft wird.  Die Verwendung biometrischer Daten wurde einer Rechtmäßigkeitsanalyse unterzogen.

Richtlinien:

Die Verwendung biometrischer Daten muss eine rechtliche Überprüfung durchlaufen, sodass dies im Rahmen der Beweissammlung bereitgestellt werden muss. Wenn keine vorhanden ist, fordern Sie die Vorlage an, die verwendet werden würde (um deren Bereitschaft zu überprüfen).

Nicht konform:

Die rechtliche Überprüfung der Verarbeitung biometrischer Daten sollte Folgendes umfassen:

- Rechtsgrundlage der Verarbeitung (eine oder mehrere der folgenden):

Zustimmung	Vertragserfüllung	Sonstige gesetzliche Verpflichtung
Zustimmung	Vertragserfüllung	Sonstige gesetzliche Verpflichtung
Vitale Interessen	Gemeinnutz	Berechtigtes Interesse

- Listet eine gültige Bedingung für die Verarbeitung biometrischer Daten auf (eine oder mehrere der folgenden):

Explizite Zustimmung des Benutzers	Beschäftigung oder soziale Sicherheit
Explizite Zustimmung des Benutzers	Beschäftigung oder soziale Sicherheit
Schutz vitaler Interessen	Legitime Aktivitäten
Personenbezogene Daten, die von der betroffenen Person offensichtlich veröffentlicht werden	Geltendmachung, Ausübung oder Verteidigung von Rechtsansprüchen
Erhebliches öffentliches Interesse	Präventions- oder Arbeitsmedizin
Öffentliches Interesse im Bereich der öffentlichen Gesundheit	Archivierungszwecke im öffentlichen Interesse, wissenschaftliche oder historische Forschung

- Überlegungen zur Verwendung von Alternativen anstelle biometrischer Daten.

Wenn eines der oben genannten Elemente fehlt oder nur auf einer perfunktory-Ebene ausgeführt wird, kann dieses Steuerelement als nicht konform markiert werden.

Beispielbeweis:

Quellen:

- DSGVO Artikel 9 – Verarbeitung besonderer Kategorien von Daten: Art. 9 DSGVO – Verarbeitung besonderer Kategorien personenbezogener Daten – Datenschutz-Grundverordnung (DSGVO)

- ICO "Wie verarbeiten wir biometrische Daten rechtmäßig?": Wie verarbeiten wir biometrische Daten rechtmäßig? | ICO

 

Steuerung Nr. 15 – Datenerkenntnisse

Stellen Sie beweise, dass Metriken nur aggregierte und anonymisierte Daten ohne individuell identifizierbare Daten anzeigen. Der Mandant sollte in der Lage sein, seine bevorzugte untere Aggregationsebene zu konfigurieren, wobei für das Produkt ein absolutes Minimum von 5 zulässig ist.

Absicht:

Mit diesem Steuerelement soll sichergestellt werden, dass Sie die status anonymisierter und pseudonymisierter Daten während des gesamten Datenlebenszyklus implementiert haben und beibehalten. (Siehe

Richtlinien:

Um zu veranschaulichen, dass dieses Steuerelement vorhanden ist, sollten Beweise über die GUI oder CLI bereitgestellt werden, um Folgendes zu veranschaulichen:

– Konfiguration auf Benutzerebene für die niedrigsten Grenzwerte von Aggregationsebenen.

– Ein Beispiel für Metriken.

Bewerten Sie, ob der Benutzer einen Schwellenwert für seine bevorzugten Aggregationsebenen auf mindestens 5 konfigurieren kann. Die Beweise sollten zeigen, dass in der Stichprobe der Metriken nur anonymisierte Daten vorhanden sind.

Nicht konform:

- Benutzer können ihre Aggregationsstufen nicht auf mindestens 5 anpassen, oder die dafür erforderlichen technischen Fähigkeiten können vom typischen Benutzer nicht erwartet werden.

- Personenbezogene Daten sind in der Metrikstichprobe vorhanden; Beispiel: Name, Nachname, ID, Kundennummer, Telefonnummer, E-Mail-Adresse, Postanschrift, Bankverbindung, nächste Angehörige usw.

Beispielbeweis:

Screenshots der Konfigurationseinstellungen mit den spezifischen Details.

Beispiel für gesammelte Metriken. Fragen Sie vielleicht nach dem Prozess zum Erreichen der Anonymisierung.

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 in diesem Abschnitt nicht die gesamte Verordnung behandelt wird, werden einige der wichtigsten Elemente der DSGVO behandelt, um zu gewährleisten, dass die organization die DSGVO ernst nimmt.

Regelung Nr. 16

Stellen Sie Beweise bereit, die die Einhaltung der Rechte der betroffenen Personen belegen, indem Sie Folgendes zeigen:

A) Sar-Erleichterung (Subject Access Request):

Dokumentation, die bestätigt, dass betroffene Personen über ihr Recht auf Zugriff auf ihre personenbezogenen Daten informiert werden und Anträge auf Zugang zu Antragstellern (Subject Access Requests, SARs) an Ihre organization übermitteln können.

 

B) Datenermittlung und SAR-Erfüllung:

Nachweis für die Fähigkeit Ihrer organization, alle personenbezogenen Daten, die sich auf eine einzelne betroffene Person beziehen, in allen Systemen und Repositorys als Reaktion auf eine SAR zu finden und abzurufen.

Absicht:

Mit dieser Kontrolle soll sichergestellt werden, dass angemessene Mechanismen vorhanden sind, mit denen betroffene Personen Anfragen zu ihren personenbezogenen Daten stellen können, die bei der organization gespeichert sind, und dass die Erfüllung legitimer Anfragen gründlich ist. (Siehe Dsgvo Artikel 15).

Richtlinien:

A) Die Datenschutzerklärung sollte Details zur Erstellung einer SAR enthalten, die die folgenden Methoden verwenden könnte:

– Verwenden eines Webformulars, das vom organization bereitgestellt wird

– Verwenden einer vom organization angegebenen E-Mail-Adresse

– Verwenden einer Telefonnummer/eines Webchats, die vom organization

- Verwendung einer Aufsichtsbehörde (z. B. der ICO im Vereinigten Königreich)

Fordern Sie einen Nachweis der methode an; Bildschirmaufnahmen sollten ausreichend sein.

B) Ein RoPA oder ein ähnliches Dokument kann verwendet werden, um die Orte zu identifizieren, an denen sich die personenbezogenen Daten der betroffenen Person befinden, sei es digital oder als Teil von Ablagesystemen (physisch).

Alternativ können E-Discovery-Übungen das gleiche Ergebnis erzielen.

Fordern Sie einen Nachweis für den Prozess/Workflow an, der zur Erfüllung einer SAR verwendet würde, und eine Erklärung, wie festgestellt wurde, dass der Prozess gründlich ist und keine personenbezogenen Daten fehlen würden, die sich auf die betroffene Person beziehen.

Nicht konform:

A) Auf der Website der organization werden keine Informationen bereitgestellt (in der Regel in der Datenschutzerklärung).

B) Beweise deuten darauf hin, dass der Prozess zur Erfassung der personenbezogenen Daten nicht gründlich ist oder keine technischen Details enthält (z. B. keine Namen/Speicherorte für Datenbanken angegeben).

Beispielbeweis:

A) Im Folgenden finden Sie Beispiele dafür, welche Beweise für Punkt A vorgelegt werden könnten.

– Webformular:

Quelle: Subject Access Request - Police Care Uk

- Email Adresse/Telefonnummer:

Quelle: Welche? Datenschutzerklärung - Welche?

- Webchat:

Quelle: Stellen Sie eine Antragstellerzugriffsanforderung an HMRC – GOV.UK

- Über eine Aufsichtsbehörde (z.B. die ICO):

Quelle: Stellen Sie Ihre Antragstellerzugriffsanforderung | ICO

B) Vorgelegte Beweisartefakte detaillierte Abläufe oder Prozessbeschreibungen mit ausreichenden technischen Details, die plausibel zur Erfüllung der SAR verwendet werden könnten.

Kontrolle Nr. 17

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

A) Die Identität und Kontaktdaten des organization und Datenschutzbeauftragten (DPO), falls zutreffend.

B) Die personenbezogenen Datentypen, die Ihre organization verarbeitet (Name, Nachname, Kundennummer, E-Mail-Adresse, Telefonnummer usw.). Auch die personenbezogenen Datenquellen (z. B. woher die personenbezogenen Daten stammen), falls der organization sie nicht direkt von den betroffenen Personen erhalten hat.

C) Zweck(e) der Verarbeitung personenbezogener Daten.

D) Die rechtsgrundlage für die Verarbeitung personenbezogener Daten (einschließlich legitimer Interessen, sofern relevant).

E) Ihre organization teilt personenbezogene Daten mit.

F) Angaben dazu, wie lange personenbezogene Daten aufbewahrt werden.

G) Einzelheiten zu den Rechten der betroffenen Personen:

• Auskunftsrecht

• Auskunftsrecht

• Recht auf Berichtigung

• Recht auf Löschung

• Recht auf Einschränkung der Verarbeitung

• Recht auf Datenübertragbarkeit

• Widerspruchsrecht

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

H) Die Einzelheiten über die Übermittlung personenbezogener Daten in ein Drittland und die getroffenen Sicherheitsvorkehrungen.

I) Das Recht, eine Beschwerde bei einer Aufsichtsbehörde unter Angabe von Kontaktdaten der Aufsichtsbehörde (z. B. der ICO im Vereinigten Königreich) einzureichen.

Absicht:

Ziel ist es, sicherzustellen, dass die veröffentlichte Datenschutzerklärung genügend Details enthält, indem die oben genannten Elemente und Prinzipien gemäß Dsgvo Kapitel 3 enthalten sind.

Richtlinien:

Gemäß Control 10.c müssen Sie einen Datenschutzhinweis veröffentlichen, der den in der Microsoft 365-Zertifizierung enthaltenen Dienst abdeckt. Dieser Datenschutzhinweis muss die oben hervorgehobenen Elemente und Prinzipien enthalten.

Nicht konform:

Weitere Informationen finden Sie unter Control 10.c.

Beispielbeweis:

Weitere Informationen finden Sie unter Control 10.c.

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. Darin werden die technischen und nichttechnischen Maßnahmen beschrieben, die "abgedeckte Einrichtungen" umsetzen müssen, um die Sicherheit der "elektronischen geschützten Gesundheitsinformationen" (E-PHI) zu gewährleisten. Obwohl in diesem Abschnitt nicht die gesamte Verordnung behandelt wird, werden einige der wichtigsten Elemente der HIPAA behandelt, um zu gewährleisten, dass die organization die Anforderung erfüllt und dass die organization die von ihr verarbeiteten Gesundheitsinformationen schützt.

Kontrolle Nr. 18

Geben Sie nachweisbare Beweise für Folgendes an:

• Es gibt eine Richtlinie für die HIPAA- und HIPAA-Behandlung innerhalb Ihrer organization 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 des organization 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 Standard Speicherort/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 erwartet wird, dass der bereitgestellte Beweis auch die Warnungsregeln anzeigt, die basierend auf der Anforderung/Implementierung des organization 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 die Dashboard des Clusters, der auch zeigt, dass bereits ein 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.

Für jeden organization ist es von entscheidender Bedeutung, eine umfassende Risikoanalyse durchzuführen, 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. 19

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 (PHI) vom Gesetz abgedeckt sind, und verbietet unsachgemäße Verwendung und Offenlegung von PHI. Die Absicht dieses Unterpunkts besteht darin, dass ein organization den Zugang und die Nutzung von E-PHI auf diejenigen beschränken muss, die es für autorisierte Zwecke benötigen, und dass sie die erforderliche Mindestregel einhalten müssen, die erfordert, dass sie nur die Mindestmenge an E-PHI verwenden oder offenlegen, 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 vorgelegten Nachweise müssen die technischen Sicherheitsvorkehrungen wie Technologien und Mechanismen, die zum Schutz der elektronischen PHI verwendet werden, und zeigen, wie die organization-Kontrollen den Zugriff und die Verschiebung solcher Daten überprüfen.

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 benutzer vertrauliche Informationen wie personenbezogene Informationen (Personally Identifiable Information, PII) aus den internen Datenbanken des organization in ihre persönlichen E-Mail-Konten, Chatbots und Social-Media-Websites in 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 besteht darin, dass ein organization seine 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 organization anwendbar ist.

Beispiel 1: HIPAA-Benutzerschulung über verwaltungsverfahren

Im nächsten Screenshot zeigt die Folie mit der Kursübersicht eine Zusammenfassung der Kursziele. Wenn die Schulung intern 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 Abschluss status. Der nächste Screenshot bietet eine Übersicht über die Benutzer, denen die Schulung zugewiesen wurde, und die Status die 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 tatsächliche PDF/Word Dokument an, wenn sie in einer digitalen Version vorliegen, oder wenn der Prozess über eine Online-Plattform 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 wird unter HIPAA als PHI 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.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).

• 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).

• 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: 05.03.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