Freigeben über

Übersicht über das Microsoft 365-Zertifizierungsframework

  • Artikel

Dieser Artikel enthält ausführliche Informationen, einschließlich der Liste der Sicherheitskontrollen für die Microsoft 365-Zertifizierung und der Unterstützung für ISVs und Entwickler, die einer Microsoft 365-Zertifizierung unterzogen werden.

Die Microsoft 365-Zertifizierung ist eine unabhängige Sicherheits- und Datenschutzüberwachung von Apps, Add-Ins und unterstützenden Back-End-Umgebungen (zusammen als Apps bezeichnet), die in die Microsoft 365-Plattform integriert werden. Apps, die erfolgreich sind, werden im gesamten Microsoft 365-Ökosystem als Microsoft 365 certified eingestuft und können problemlos in Microsoft 365-Marketplaces über complianceorientierte Suchfilter und Branding gefunden werden. ISVs haben die Möglichkeit, ihre App-Kompatibilitätsattribute auf dedizierten Seiten in diesem Dokumentationssatz zu teilen.

Die Microsoft 365-Zertifizierung ist für die folgenden Arten von Anwendungen verfügbar:

  • Microsoft 365-Add-Ins (Word, Excel, Outlook, PowerPoint, OneNote, Project)
  • Teams-Apps
  • SharePoint-Lösungen
  • Web-Apps (SaaS)

Wichtig

Die Microsoft 365-Zertifizierung ist eine strenge Überprüfung der Sicherheit und Compliance einer App mit dem Microsoft 365-Zertifizierungsframework und erfordert einen erheblichen Zeit- und Ressourcenaufwand. Überprüfen Sie die Compliancekontrollframeworks , um zu ermitteln, ob Ihre App berechtigt ist, bevor Sie mit der Zertifizierung beginnen. Bei Fragen senden Sie bitte eine E-Mail appcert@microsoft.coman .

Bedingungen

Durch die Teilnahme am Microsoft 365-Zertifizierungsprogramm erklären Sie sich mit diesen ergänzenden Bedingungen einverstanden und mit allen Begleitdokumentationen einverstanden, die für Ihre Teilnahme am Microsoft 365-Zertifizierungsprogramm mit der Microsoft Corporation gelten ("Microsoft", "wir", "uns" oder "unser"). Sie versichern und garantieren uns, dass Sie berechtigt sind, diese ergänzenden Bedingungen für die Microsoft 365-Zertifizierung im Eigenen Namen, eines Unternehmens und/oder einer anderen Juristischen Person zu akzeptieren, sofern zutreffend. Wir können diese ergänzenden Bedingungen jederzeit ändern, ändern oder beenden. Ihre fortgesetzte Teilnahme am Microsoft 365-Zertifizierungsprogramm nach jeder Änderung oder Änderung bedeutet, dass Sie den neuen ergänzenden Bedingungen zustimmen. Wenn Sie den neuen ergänzenden Bedingungen nicht zustimmen oder wenn wir diese ergänzenden Bedingungen kündigen, müssen Sie die Teilnahme am Microsoft 365-Zertifizierungsprogramm beenden.

Voraussetzungen

Bevor die Microsoft 365-Zertifizierung erteilt werden kann, muss eine App Folgendes ausführen:

Herausgeberüberprüfung Wenn eine App über einen verifizierten Herausgeber verfügt, wurde der organization, der die App veröffentlicht, von Microsoft als authentisch überprüft. Die Überprüfung einer App umfasst die Verwendung eines CPP-Kontos (Microsoft Cloud Partner Program), das überprüft wurde, und das Zuordnen der überprüften PartnerID zu einer App-Registrierung. Überprüfen des Herausgebers

Publisher Attestation ist ein Self-Service-Prozess, bei dem ISVs eine Reihe von Fragen zu den Sicherheits- und Datenverarbeitungspraktiken ihrer App beantworten. Apps können vom Herausgeber im Microsoft Partner Center bestätigt werden und erhalten nach Abschluss des Vorgangs Badging- und dedizierte Filter im Microsoft AppSource-Marketplace.

Überprüfen der Kontrollkriterien Es ist nicht erforderlich, alle Kontrollen einzuhalten, um eine Zertifizierung zu erhalten. Für jede der drei sicherheitsrelevanten Domänen, die in diesem Übersichtsdokument erläutert werden, gelten jedoch Schwellenwerte (die nicht offengelegt werden) und müssen übergeben werden. Einige Kontrollen werden als "harter Fehler" klassifiziert, was bedeutet, dass das Fehlen dieser Sicherheitskontrollen zu einer fehlerhaften Bewertung führt.

Wichtig

Übermittlungszeitrahmen: Im Durchschnitt sollte der Bewertungsprozess 30 Tage dauern, sofern ISVs in der Lage sind, die Einreichung status häufig zu überprüfen und rechtzeitig auf Kommentare und ergänzende Beweisanträge zu reagieren. Nach Beginn des Zertifizierungsprozesses sind maximal 60 Tage zulässig, um die Bewertung abzuschließen. Wenn nicht alle Übermittlungen innerhalb des 60-tägigen Zeitraums abgeschlossen wurden, wird der Übermittlung ein Fehler ausgestellt, und der Prozess muss erneut gestartet werden. Diese Ergebnisse werden nicht veröffentlicht.

Zertifizierungsbereich

Die Bereichsumgebung unterstützt die Übermittlung des App-/Add-In-Codes und alle Back-End-Systeme, mit denen die App bzw. das Add-In möglicherweise kommuniziert. Alle zusätzlichen Umgebungen, die mit der In-Scope-Umgebung verbunden sind, werden ebenfalls in den Bereich aufgenommen, es sei denn, eine angemessene Segmentierung ist vorhanden. Die verbundenen Umgebungen können die Sicherheit der bereichsinternen Umgebung nicht beeinträchtigen.

Alle separaten Notfallwiederherstellungsumgebungen müssen auch in die Bereichsumgebung eingeschlossen werden, da diese Umgebungen erforderlich wären, um den Dienst zu erfüllen, wenn etwas mit der primären Umgebung passiert. Remotesicherungsumgebungen müssen ebenfalls einbezogen werden, da diese Umgebungen Möglicherweise Microsoft-Daten speichern und daher angemessene Sicherheitskontrollen vorhanden sein müssen.

Der Begriff systeminterne Komponenten bezieht sich auf ALLE Geräte und Systeme, die innerhalb der definierten Bereichsumgebung verwendet werden. Zu den In-Scope-Komponenten gehören, sind jedoch nicht beschränkt auf:

  • Webanwendung(en)
  • Server (physisch oder virtuell, die lokal oder in der Cloud sein können)
  • Netzwerksicherheitskontrollen (NSCs), z. B. Firewalls
  • Optionen
  • Lastenausgleichsmodule
  • Virtuelle Infrastruktur
  • Webverwaltungsportale für Cloudanbieter
  • Cloudressourcen (Virtual Machines, App Service, Speicherkonten, EC2-Instanzen usw.)

Wichtig

Öffentlich zugängliche Systemkomponenten sind anfällig für Angriffe von externen Bedrohungsakteuren und sind daher einem viel größeren Risiko ausgesetzt. In der Regel würden diese Systeme mit einer Netzwerksicherheitssteuerung (Network Security Control, NSC) weg von anderen internen Systemkomponenten segmentiert, um eine demilitarisierte Zone (DMZ) zu erstellen. Die DMZ ist weniger vertrauenswürdig als das interne Netzwerk und zusätzliche Sicherheit würde dazu beitragen, die internen Systeme und Daten weiter zu schützen, wenn die öffentlich zugänglichen Systeme kompromittiert werden. Im Idealfall wird eine DMZ verwendet, dies ist jedoch in einigen Bereitstellungsszenarien nicht möglich oder sogar erforderlich.

Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS) und Software-as-a-Service (SaaS)

Wenn IaaS und/oder PaaS zur Unterstützung der zu prüfenden Bereichsumgebung verwendet werden, ist der Cloudplattformanbieter für einige der Sicherheitskontrollen verantwortlich, die während des Zertifizierungsprozesses bewertet werden. Analysten müssen mit einer unabhängigen externen Überprüfung bewährter Sicherheitsmethoden durch den Cloudplattformanbieter über externe Complianceberichte wie PCI DSS, Nachweis der Compliance (AOC), ISO 27001 oder SOC 2 Type II-Berichte bereitgestellt werden.

Anhang C enthält Details dazu, welche Sicherheitskontrollen basierend auf den folgenden Bereitstellungstypen und basierend darauf, ob die App Microsoft 365-Daten exfiltriert, wahrscheinlich anwendbar sind:

  • IsV gehostet
  • IaaS gehostet
  • PaaS/serverlos gehostet
  • Hybrid gehostet
  • Freigegeben gehostet

Wenn IaaS oder PaaS bereitgestellt wird, müssen Nachweise zur Überprüfung der Ausrichtung der Umgebung an diese Bereitstellungstypen bereitgestellt werden.

Probenahme

Beweisanträge zur Unterstützung der Zertifizierungsbewertung sollten auf einer Stichprobe der systeminternen Komponenten basieren, die verschiedene Betriebssysteme, die primäre Funktion des Geräts, verschiedene Gerätetypen (z. B. Server, NSCs, Router usw.) und den Standort berücksichtigen. Ein geeignetes Beispiel wird zu Beginn des Zertifizierungsprozesses ausgewählt. Die folgende Tabelle sollte als Leitfaden verwendet werden, bei dem die Stichprobenentnahme auf der Grundlage der oben beschriebenen Faktoren bestimmt wird:

Größe der Population Beispiel
<=5 1
>5 & <10= 2
>10 & <=30 3
>30 4

Hinweis

Wenn Abweichungen zwischen den in der ursprünglichen Stichprobe enthaltenen Geräten festgestellt werden, kann die Stichprobengröße während der Bewertung erhöht werden.

End-to-End-Zertifizierungsprozess

So beginnen Sie mit der Microsoft 365-Zertifizierung:

  1. Navigieren Sie zu Partner Center , und schließen Sie den Herausgebernachweis ab. Wenn die Übermittlung älter als drei Monate ist, übermitteln Sie sie erneut zur Überprüfung und Validierung.

  2. Wählen Sie im Partner Center "Zertifizierung starten" aus, um mit der ersten Dokumentübermittlung zu beginnen. Dies hilft Zertifizierungsanalysten zu bestimmen, was für die Bewertung auf Der Grundlage der App-Architektur und der Verarbeitung von Microsoft-Daten vorgesehen ist.

Tipp

Befolgen Sie die Schritt-für-Schritt-Anleitung , um Ihre App microsoft 365 zertifizieren zu lassen.

Der Zertifizierungsprozess wird wie unten beschrieben in zwei Phasen durchgeführt:

Die anfängliche Dokumentübermittlung hilft dem Analysten, die App und datenflüsse zu verstehen, die bereichsinterne Umgebung zu definieren, zu identifizieren, welche Sicherheitskontrollen anwendbar sind, und die Systemkomponenten zu bestimmen, von denen Beweise gesammelt werden müssen. Der ISV muss die angeforderten Informationen bereitstellen, um den Zertifizierungsanalysten bei der Durchführung dieser Phase des Prozesses zu unterstützen, was ungefähr 5 % des Gesamtprozesses entspricht.

Vollständige Beweisüberprüfung ist der Prozess, bei dem der ISV Beweisartefakte übermittelt, die veranschaulichen, wie die umgebung im Gültigkeitsbereich die Sicherheitskontrollen erfüllt. Während dieser Prüfungsphase, die den restlichen Prozess umfasst, werden mehrere Interaktionen zwischen dem ISV und dem Analysten stattfinden.

Bewertung

Sobald die anfängliche Dokumentübermittlung akzeptiert wurde, werden die Sicherheitskontrollen automatisch im Portal angezeigt. ISVs müssen für jede Kontrolle nachweisen, dass die Kontrolle vorhanden ist, und 60 Tage Zeit haben, alle Beweise vorzulegen. Ein Analyst überprüft die Beweise und genehmigt entweder die Kontrolle oder fordert neue oder zusätzliche Beweise an.

Zertifizierung

Sobald eine Übermittlung von einem Analysten überprüft wurde, werden ISVs über die Zertifizierungsentscheidung benachrichtigt. Apps, die eine Zertifizierung erhalten, einen Badge auf ihrer Anwendung in AppSource sowie dedizierte Microsoft-Dokumentationsseiten mit detaillierten Berichten zu ihren Sicherheits- und Complianceattributen.

Überprüfung und Erneute Zertifizierung

Microsoft 365 Certified Apps müssen jährlich erneut zertifiziert werden. Dies erfordert die erneute Überprüfung der Bereichssteuerelemente für die aktuelle Bereichsumgebung. Dieser Prozess kann bis zu 90 Tage vor Ablauf der Zertifizierung beginnen. Vorhandene Zertifizierungen laufen während des Rezertifizierungszeitraums nicht ab. Die erneute Zertifizierung für alle Programme läuft am einjährigen Jahrestag Ihrer Microsoft 365-Zertifizierung ab.

Wenn die Zertifizierung nicht vor dem Ablaufdatum verlängert wird, wird die App-Zertifizierung status widerrufen. Alle Badgings, Symbole und das zugehörige Zertifizierungsbranding werden aus Ihrer App entfernt, und ISVs dürfen Ihre App nicht als Microsoft 365 Certified bewerben.

Wenn eine Anwendung außerhalb des Zeitrahmens für die Erneutezertifizierungsübermittlung wesentliche Änderungen erfährt, werden ISV aufgefordert, das Microsoft App Compliance-Programm über updates zu benachrichtigen.

Anfängliche Dokumentübermittlung

Ihre erste Übermittlung muss die folgenden Informationen enthalten:

Dokumentationsübersicht Dokumentationsdetails
App-/Add-In-Beschreibung Eine Beschreibung des Zwecks und der Funktionalität der App bzw. des Add-Ins. Dies sollte dem Zertifizierungsanalysten ein gutes Verständnis dafür vermitteln, wie die App/das Add-In funktioniert und welche Verwendung sie beabsichtigt hat.
Penetrationstestbericht Ein Penetrationstestbericht, der innerhalb der letzten 12 Monate abgeschlossen wurde. Dieser Bericht muss die Umgebung enthalten, die die Bereitstellung der App/add unterstützt, sowie jede zusätzliche Umgebung, die den Betrieb der App/Add-In unterstützt. Hinweis: Wenn der ISV derzeit keine jährlichen Penetrationstests durchführt, übernimmt Microsoft die Kosten für Stifttests über den Zertifizierungsprozess.
Architekturdiagramme Ein logisches Architekturdiagramm, das eine allgemeine Übersicht über die unterstützende Infrastruktur der App darstellt. Dies muss alle Hostingumgebungen und die unterstützende Infrastruktur umfassen, die die App unterstützt. Dieses Diagramm MUSS alle verschiedenen unterstützenden Systemkomponenten innerhalb der Umgebung darstellen, um Zertifizierungsanalysten dabei zu helfen, systeme im Umfang zu verstehen und die Stichprobenentnahme zu bestimmen. Geben Sie auch an, welcher Hostingumgebungstyp verwendet wird. ISV gehostet, IaaS, PaaS oder Hybrid. Anmerkung: Wenn SaaS verwendet wird, geben Sie die verschiedenen SaaS-Dienste an, die verwendet werden, um unterstützende Dienste innerhalb der Umgebung bereitzustellen.
Öffentlicher Fußabdruck Details aller öffentlichen IP-Adressen und URLs, die von der unterstützenden Infrastruktur verwendet werden. Dies muss den vollständigen routingfähigen IP-Adressbereich umfassen, der der Umgebung zugeordnet ist, es sei denn, eine angemessene Segmentierung wurde implementiert, um den verwendeten Bereich aufzuteilen (es ist ein angemessener Nachweis für die Segmentierung erforderlich).
Datenflussdiagramme Flussdiagramme, die Folgendes beschreiben:
✓ Microsoft 365 Datenflüsse zu und von der App/Add-In (einschließlich EUII und OII.)
✓ Microsoft 365 Datenflüsse innerhalb der unterstützenden Infrastruktur (sofern zutreffend).
✓ Diagramme, die zeigen, wo und welche Daten gespeichert werden, wie Daten an externe Dritte weitergegeben werden (einschließlich Details zu welchen Dritten), und wie Daten während der Übertragung über offene/öffentliche Netzwerke und ruhende Netzwerke geschützt werden.
Api-Endpunktdetails Eine vollständige Liste aller API-Endpunkte, die von Ihrer App verwendet werden. Um den Umgebungsbereich besser zu verstehen, geben Sie API-Endpunktstandorte in Ihrer Umgebung an.
Microsoft-API-Berechtigungen Stellen Sie eine Dokumentation mit allen Microsoft-APIs bereit, die zusammen mit den berechtigungen verwendet werden, die für die App/das Add-In angefordert werden, zusammen mit einer Begründung für die angeforderten Berechtigungen.
Datenspeichertypen Datenspeicherung und -verarbeitung von Dokumenten, die Folgendes beschreiben:
✓ In welchem Umfang werden Microsoft 365-Daten EUII und OII empfangen und gespeichert?
✓ Die Datenaufbewahrungsdauer.
✓ Warum die Microsoft 365-Daten erfasst werden.
✓ Wo Microsoft 365-Daten gespeichert werden (sollten auch in den oben angegebenen Datenflussdiagrammen enthalten sein).
Konformitätsbestätigung Unterstützende Dokumentation für externe Sicherheitsframeworks, die in der Herausgebernachweisübermittlung enthalten sind oder bei der Überprüfung der Microsoft 365-Zertifizierungssicherheitskontrollen berücksichtigt werden müssen. Derzeit werden die folgenden vier unterstützt:
✓ PCI DSS Attestation of Compliance (AOC).
✓ SOC 2 Typ I/Typ II Berichte.
✓ ISMS / IEC - 1S0/IEC 27001 Statement of Applicability (SoA) und Zertifizierung.
✓ FedRAMP FedRAMP-Autorisierungspaket und FedRAMP Readiness Assessment Report.
Webabhängigkeiten Dokumentation, die alle Abhängigkeiten auflistet, die von der App mit aktuellen ausgeführten Versionen verwendet werden.
Softwarebestand Eine aktuelle Softwareinventur, die alle in der Bereichsumgebung verwendeten Software zusammen mit den Versionen enthält.
Hardwareinventar Ein aktueller Hardwarebestand, der von der unterstützenden Infrastruktur verwendet wird. Dies wird verwendet, um die Stichprobenentnahme bei der Durchführung der Bewertungsphase zu unterstützen. Wenn Ihre Umgebung PaaS enthält, geben Sie Details zu den genutzten Clouddiensten/Ressourcen an.

Aktivitäten zur Sammlung und Bewertung von Beweisen

Zertifizierungsanalysten müssen Beweise für alle Systemkomponenten innerhalb des definierten Beispielsatzes überprüfen. Zu den Arten von Beweisen, die zur Unterstützung des Bewertungsprozesses erforderlich sind, gehören folgende:

Beweissammlung

  • Erste Dokumentation, hervorgehoben im Leitfaden zur Übermittlung der ersten Dokumentation
  • Richtliniendokumente
  • Dokumente verarbeiten
  • Systemkonfigurationseinstellungen
  • Tickets ändern
  • Änderungssteuerungsdatensätze
  • Systemberichte
  • Besprechungsprotokolle
  • Verträge/Vereinbarungen

Es werden verschiedene Methoden verwendet, um die für den Abschluss des Bewertungsprozesses erforderlichen Beweise zu sammeln. Diese Beweissammlung kann folgende Formen haben:

  • Dokumente
  • Screenshots
  • Interviews
  • Bildschirmfreigabe

Die verwendeten Methoden zur Beweissammlung werden während des Bewertungsprozesses ermittelt. Spezifische Beispiele für die Art von Nachweisen, die in Ihrer Übermittlung erforderlich sind, finden Sie im Leitfaden zu Beispielen für Nachweise.

Bewertungsaktivitäten

Zertifizierungsanalysten überprüfen die bereitgestellten Beweise, um festzustellen, ob alle Kontrollen für die Microsoft 365-Zertifizierung erfüllt wurden.

Um den Zeitaufwand für die Durchführung der Bewertung zu verkürzen, sollten die in der Anfänglichen Dokumentationsübermittlung beschriebenen Unterlagen im Voraus bereitgestellt werden.

Zertifizierungsanalysten überprüfen zunächst die beweise aus der ursprünglichen Dokumentationsübermittlung und die Herausgebernachweisinformationen, um geeignete Untersuchungslinien, Stichprobengröße und die Notwendigkeit weiterer Nachweise zu ermitteln, wie oben beschrieben. Zertifizierungsanalysten analysieren alle gesammelten Informationen, um Rückschlüsse darauf zu ziehen, wie und ob Sie die Kontrollen in dieser Microsoft 365-Zertifizierungsspezifikation erfüllen.

App-Zertifizierungskriterien

Die App und ihre unterstützende Infrastruktur sowie die unterstützende Dokumentation werden in den folgenden drei Sicherheitsdomänen bewertet:

  1. Anwendungssicherheit
  2. Betriebssicherheit/sichere Bereitstellung
  3. Sicherheit und Datenschutz bei der Datenverarbeitung

Jede dieser Sicherheitsdomänen umfasst bestimmte Schlüsselkontrollen, die eine oder mehrere Anforderungen umfassen, die im Rahmen des Bewertungsprozesses ausgewertet werden. Um sicherzustellen, dass die Microsoft 365-Zertifizierung für Entwickler aller Größen gilt, wird jede der Sicherheitsdomänen mithilfe eines Bewertungssystems bewertet, um eine Gesamtbewertung aus jeder der Domänen zu ermitteln. Die Bewertungen für jede der Microsoft 365-Zertifizierungskontrollen werden basierend auf dem wahrgenommenen Risiko, dass diese Kontrolle nicht implementiert wird, zwischen 1 (niedrig) und 3 (hoch) zugeordnet. Jede der Sicherheitsdomänen verfügt über eine Mindestprozentmarke, die als bestanden gilt. Bestimmte Elemente dieser Spezifikation enthalten einige Kriterien für automatische Fehler:

  • API-Berechtigungen, die nicht dem Prinzip der geringsten Rechte (PoLP) folgen.
  • Es werden keine Penetrationstests gemeldet, wenn dies erforderlich ist.
  • Keine Anti-Malware-Abwehr.
  • Die mehrstufige Authentifizierung wird nicht zum Schutz des Administratorzugriffs verwendet.
  • Keine Patchprozesse.
  • Kein geeigneter Datenschutzhinweis der DSGVO .

Anwendungssicherheit

Die Anwendungssicherheitsdomäne konzentriert sich auf drei Bereiche:

  • GraphAPI-Berechtigungsüberprüfung
  • Externe Konnektivitätsprüfungen
  • Penetrationstests

GraphAPI-Berechtigungsüberprüfung

Die Überprüfung der GraphAPI-Berechtigung wird durchgeführt, um zu überprüfen, ob die App/das Add-In keine übermäßig freizügigen Berechtigungen anzufordern. Dies erfolgt durch manuelle Überprüfung, welche Berechtigungen angefordert werden. Zertifizierungsanalysten verweisen auf diese Überprüfungen mit der Übermittlung des Herausgebernachweises und bewerten die angeforderte Zugriffsebene, um sicherzustellen, dass die Praktiken mit den geringsten Rechten eingehalten werden. Wenn Zertifizierungsanalysten der Meinung sind, dass diese Praktiken der "geringsten Rechte" nicht erfüllt werden, führen Zertifizierungsanalysten eine offene Diskussion mit dem ISV, um die geschäftliche Begründung für die angeforderten Berechtigungen zu überprüfen. Alle Abweichungen zur Übermittlung des Herausgebernachweises, die während dieser Überprüfung gefunden wurden, müssen korrigiert werden.

Externe Konnektivitätsprüfungen

Im Rahmen der Bewertung wird eine einfache exemplarische Vorgehensweise der Anwendungsfunktionalität durchgeführt, um alle Verbindungen zu identifizieren, die außerhalb von Microsoft 365 hergestellt werden. Alle Verbindungen, die nicht als Microsoft oder direkte Verbindungen mit Ihrem Dienst identifiziert werden, werden während der Bewertung gekennzeichnet und erläutert.

Penetrationstests

Eine angemessene Überprüfung der Risiken, die mit der App/dem Add-In und der unterstützenden Umgebung verbunden sind, ist unerlässlich, um Kunden sicherheit in Bezug auf die Sicherheit der App/Add-Ins zu bieten. Anwendungssicherheitstests in Form von Penetrationstests MÜSSEN durchgeführt werden, wenn Ihre Anwendung mit einem Dienst verbunden ist, der nicht von Microsoft veröffentlicht wurde. Wenn Ihre App nach der Bereitstellung eigenständig auf den Microsoft-Dienst wie GraphAPI zugreift, ist kein Penetrationstest erforderlich. Penetrationstests sind weiterhin erforderlich, wenn die bereichsinterne Umgebung in Azure gehostet wird.

Penetrationstestbereich

Sowohl für interne als auch für externe Infrastruktur-Penetrationstests müssen alle Penetrationstests in der Live-Produktionsumgebung durchgeführt werden, die die Bereitstellung der App/Des-Add-Ins unterstützt (z. B. in dem der App-/Add-In-Code gehostet wird, der in der Regel die Ressource in der Manifestdatei ist), zusammen mit allen zusätzlichen Umgebungen, die den Betrieb der App/Add-Ins unterstützen (z. B. , wenn die App/das Add-In mit anderen Webanwendungen außerhalb von Microsoft 365 kommuniziert). Bei der Definition des Umfangs für Penetrationstests muss darauf geachtet werden, dass alle "verbundenen" Systeme oder Umgebungen, die sich auf die Sicherheit der bereichsinternen Umgebung auswirken können, auch in ALLE Penetrationstestaktivitäten einbezogen werden.

Es wird empfohlen, Penetrationstests für Webanwendungen für die Liveproduktionsumgebung durchzuführen. Es wäre jedoch akzeptabel, nur die Webanwendung mithilfe einer Test-/UAT-Umgebung zu testen, sofern im Penetrationstestbericht bestätigt wird, dass zum Zeitpunkt des Tests genau dieselbe Codebasis innerhalb der Test-/UAT-Umgebung ausgeführt wurde.

Wenn Techniken verwendet werden, um die In-Scope-Umgebungen von anderen Umgebungen zu segmentieren, MÜSSEN Penetrationstestaktivitäten die Wirksamkeit dieser Segmentierungstechniken überprüfen. Dies muss im Penetrationstestbericht ausführlich beschrieben werden.

Hinweis

Interne Penetrationstests müssen durchgeführt werden, es sei denn, die Hostingumgebung wird nur als PaaS klassifiziert.

Anforderungen an Penetrationstests

Die Berichte zu Penetrationstests werden überprüft, um sicherzustellen, dass keine Sicherheitsrisiken vorhanden sind, die die folgenden automatischen Fehlerkriterien erfüllen, die in den folgenden Kontrollen beschrieben sind.

Kriterientyp Penetrationsteststeuerungen
Allgemeine Kriterien Webanwendungen (authentifiziert und nicht authentifiziert) und sowohl interne (falls zutreffend) als auch externe Infrastruktur-Penetrationstests MÜSSEN jährlich (alle 12 Monate) stattfinden und von einem seriösen unabhängigen Unternehmen durchgeführt werden.
Die Behebung von identifizierten kritischen und risikoreichen Sicherheitsrisiken MUSS innerhalb eines Monats nach Abschluss des Penetrationstests oder je nach dokumentiertem Patchprozess des ISV früher abgeschlossen werden.
Der vollständige externe Speicherbedarf (IP-Adressen, URLs, API-Endpunkte usw.) MUSS in den Rahmen der Penetrationstests aufgenommen werden und muss im Penetrationstestbericht klar dokumentiert sein.
Sofern die Umgebung nicht an PaaS ausgerichtet ist, müssen die vollständigen internen Netzwerke in den Rahmen von Penetrationstests einbezogen und im Penetrationstestbericht eindeutig dokumentiert werden.
Penetrationstests für Webanwendungen MÜSSEN alle Sicherheitsrisikoklassen enthalten. Beispielsweise die aktuellsten OWASP Top 10 oder SANS Top 25 CWE. Die Empfehlung lautet, dass dies im Penetrationstestbericht ausführlich beschrieben wird, andernfalls ist es schwierig, dies nachzuweisen.
Kritische und risikoreiche Sicherheitsrisiken oder Sicherheitsrisiken, die als automatischer Fehler eingestuft werden , MÜSSEN vom Penetrationstestunternehmen erneut getestet und im Penetrationstestbericht deutlich als behoben hervorgehoben werden.
Kriterien für automatische Fehler: Vorhandensein eines nicht unterstützten Betriebssystems oder einer nicht unterstützten JavaScript-Bibliothek.
Vorhandensein von standardmäßigen, aufzählbaren oder erratenden Administratorkonten.
Das Vorhandensein von Risiken für die Einschleusung von SQL-Befehlen.
Vorhandensein websiteübergreifender Skripts.
Vorhandensein von Sicherheitsrisiken im Verzeichnisdurchlauf (Dateipfad).
Vorhandensein von HTTP-Sicherheitsrisiken, z. B. Aufteilen von Headerantworten, Anforderungsschmuggel und Desync-Angriffe.
Vorhandensein einer Offenlegung des Quellcodes (einschließlich LFI).
Alle kritischen oder hohen Bewertungen, wie in den CVSS-Patchverwaltungsrichtlinien definiert.
Jede erhebliche technische Sicherheitslücke, die leicht ausgenutzt werden kann, um eine große Menge von EUII oder OUI zu kompromittieren.

Wichtig

Berichte müssen in der Lage sein, genügend Sicherheit zu bieten, dass alles, was im abschnitt Penetrationstestanforderungen oben beschrieben ist, nachgewiesen werden kann.

Anforderungen und Regeln für ergänzende Penetrationstests

  • Für ISVs, die derzeit keine Penetrationstests durchführen, können Penetrationstests kostenlos für die Microsoft 365-Zertifizierung durchgeführt werden. Microsoft übernimmt die Kosten für einen Penetrationstest für bis zu 12 Tage für manuelle Tests. Die Kosten für Penetrationstests werden basierend auf der Anzahl der Tage berechnet, die zum Testen der umgebung im Gültigkeitsbereich erforderlich sind. Alle Kosten, die 12 Tage der Prüfung überschreiten, sind sache des ISV.
  • ISVs sind verpflichtet, Nachweise vorzulegen und die Genehmigung für 50 % der Kontrollen im Gültigkeitsbereich zu erhalten, bevor der Penetrationstest durchgeführt wird. Füllen Sie zunächst Ihre erste Dokumentübermittlung aus, und wählen Sie penetrationstests in Ihre Bewertung ein. Wenn Sie 50 % der Steuerelemente abgeschlossen haben, werden Sie kontaktiert, um den Penetrationstest zu planen und zu planen.
  • Der Bericht, der nach Abschluss des Stifttests ausgegeben wird, wird dem ISV zur Verfügung gestellt, sobald er die Zertifizierung abgeschlossen hat. Dieser Bericht kann zusammen mit Ihrer Microsoft 365-Zertifizierung verwendet werden, um potenziellen Kunden zu zeigen, dass Ihre Umgebung sicher ist.
  • ISVs sind auch für den Nachweis verantwortlich, dass die im Penetrationstest identifizierten Sicherheitsrisiken vor der Vergabe einer Zertifizierung behoben wurden, aber keinen sauber Bericht erstellen müssen.

Sobald ein Penetrationstest eingerichtet wurde, ist der ISV für die Gebühren im Zusammenhang mit Neuplanung und Stornierung wie folgt verantwortlich:

Zeitskala für die Neuplanung von Gebühren Zahlbarer Anteil
Eine Neuplanungsanforderung, die mehr als 30 Tage vor dem geplanten Startdatum empfangen wurde. 0% Zahlbar
Die Neuplanungsanforderung wurde 8 bis 30 Tage vor dem geplanten Startdatum empfangen. 25% Zahlbar
Eine Neuplanungsanforderung, die innerhalb von 2 bis 7 Tagen vor dem geplanten Startdatum mit einem festen Umbuchungsdatum empfangen wurde. 50% Zahlbar
Anforderung zur Neuplanung, die weniger als 2 Tage vor dem Startdatum empfangen wurde. 100% Zahlbar
Zeitskala für Stornierungsgebühren Zahlbarer Anteil
Die Stornierungsanforderung wurde mehr als 30 Tage vor dem geplanten Startdatum empfangen. 25% Zahlbar
Die Stornierungsanforderung wurde 8 bis 30 Tage vor dem geplanten Startdatum empfangen. 50% Zahlbar
Stornierungsanfrage, die innerhalb von 7 Tagen vor dem geplanten Startdatum empfangen wurde. 90% Zahlbar

Operative Sicherheit

Diese Domäne misst die Ausrichtung der unterstützenden Infrastruktur und Bereitstellungsprozesse einer App mit bewährten Sicherheitsmethoden.

Steuerelemente

Steuerelementfamilie Controls
Bewusstseinsschulung Stellen Sie den Nachweis bereit, dass die organization Benutzern des Informationssystems (einschließlich Managern, leitenden Führungskräften und Auftragnehmern) im Rahmen der erstausbildung für neue Benutzer oder bei Bedarf durch Änderungen des Informationssystems eine fundierte Schulung zum Sicherheitsbewusstsein bietet.
Nachweise für eine organization definierte Häufigkeit des Bewusstseinstrainings.
Stellen Sie Nachweise für die Dokumentation und Überwachung einzelner Aktivitäten zur Sicherheitsbewusstsein des Informationssystems bereit, während Sie einzelne Trainingsdatensätze über eine organization definierte Häufigkeit aufbewahren.
Schutz vor Schadsoftware – Antivirus Stellen Sie einen Beweis dafür bereit, dass Ihre Antischadsoftwarelösung aktiv und für alle erfassten Systemkomponenten aktiviert und so konfiguriert ist, dass sie die folgenden Kriterien erfüllt:
Wenn Virenschutz, ist diese Überprüfung bei Zugriff aktiviert und die Signaturen sind innerhalb von 1 Tag auf dem neuesten Stand, und es blockiert automatisch Schadsoftware oder Warnungen und quarantänet, wenn Schadsoftware erkannt wird.
ODER wenn EDR/NGAV (Endpunkterkennung und -antwort/Antivirus der nächsten Generation) regelmäßig überprüft wird, Überwachungsprotokolle generiert werden, und es wird ständig auf dem neuesten Stand gehalten und verfügt über Selbstlernfunktionen.
Wenn EDR/NGAV dann bekannte Schadsoftware blockiert und neue Malware-Varianten basierend auf Makroverhalten sowie vollständigen Safelist-Funktionen identifiziert und blockiert.
Schutz vor Schadsoftware – Anwendungssteuerungen Stellen Sie nachweisbare Beweise bereit, dass eine genehmigte Liste von Software/Anwendungen mit geschäftlicher Begründung vorhanden ist und auf dem neuesten Stand ist.
Dass jede Anwendung einem Genehmigungsprozess unterzogen wird und sich vor der Bereitstellung abmeldet
Diese Anwendungssteuerungstechnologie ist für alle erfassten Systemkomponenten aktiv, aktiviert und konfiguriert, wie dokumentiert.
Patchverwaltung – Patching und Risikorangfolge Stellen Sie eine Richtliniendokumentation bereit, die steuert, wie neue Sicherheitsrisiken identifiziert und einer Risikobewertung zugewiesen werden.
Stellen Sie Beweise dafür bereit, wie neue Sicherheitsrisiken identifiziert werden.
Stellen Sie Beweise bereit, die belegen, dass allen Sicherheitsrisiken nach der Identifizierung eine Risikorangfolge zugewiesen wird.
Stellen Sie den Nachweis bereit, dass alle erfassten Systemkomponenten gepatcht werden, und zwar mit den von der Organisation definierten Patchzeitrahmen und nicht unterstützten Betriebssystemen und Softwarekomponenten, die nicht verwendet werden. Dies sollte ggf. Codebasis umfassen, wenn serverlose Technologie oder PaaS verwendet wird, oder sowohl Infrastruktur als auch Codebasis, wenn IaaS verwendet wird.
Richtlinien für den Patchzeitrahmen: Kritisch – innerhalb von 14 Tagen, Hoch – Innerhalb von 30 Tagen, Mittel – Innerhalb von 60 Tagen.
Überprüfung auf Sicherheitsrisiken Stellen Sie die vierteljährlichen Berichte zur Überprüfung von Sicherheitsrisiken in Infrastruktur und Webanwendung bereit. Die Überprüfung muss für den gesamten öffentlichen Speicherbedarf (IP-Adressen und URLs) und interne IP-Adressbereiche durchgeführt werden.
Stellen Sie nachweisbare Beweise dafür bereit, dass Korrekturen von Sicherheitsrisiken, die während der Überprüfung auf Sicherheitsrisiken identifiziert wurden, gemäß Ihrem dokumentierten Patchzeitrahmen gepatcht werden.
Netzwerksicherheitskontrollen (Network Security Controls, NSC) Stellen Sie beweise, dass Netzwerksicherheitskontrollen (Network Security Controls, NSC) an der Grenze der bereichsinternen Umgebung und zwischen dem Umkreisnetzwerk und internen Netzwerken installiert sind.
UND bei hybridem, lokalem IaaS wird auch nachgewiesen, dass der gesamte öffentliche Zugriff im Umkreisnetzwerk endet.
Überprüfen Sie, ob alle Netzwerksicherheitskontrollen (Network Security Controls, NSC) so konfiguriert sind, dass Datenverkehr gelöscht wird, der nicht explizit in der Regelbasis definiert ist, und dass die Regelüberprüfungen von Netzwerksicherheitskontrollen (Network Security Controls, NSC) mindestens alle 6 Monate durchgeführt werden.
Änderungssteuerung Stellen Sie den Nachweis bereit, dass änderungen, die in Produktionsumgebungen eingeführt werden, durch dokumentierte Änderungsanforderungen implementiert werden, die die Auswirkungen der Änderung, Details zu Back-Out-Verfahren, durchzuführende Tests, Überprüfungen und Genehmigungen durch autorisiertes Personal enthalten.
Stellen Sie beweise, dass separate Umgebungen vorhanden sind, sodass: Entwicklungs- und Test-/Stagingumgebungen die Trennung von Aufgaben von der Produktionsumgebung erzwingen, die Aufgabentrennung wird über Zugriffssteuerungen erzwungen, sensible Produktionsdaten werden in den Entwicklungs- oder Test-/Stagingumgebungen nicht verwendet.
Sichere Softwareentwicklung/-bereitstellung Stellen Sie Richtlinien und Verfahren bereit, die eine sichere Softwareentwicklung unterstützen und Branchenstandards und/oder bewährte Methoden für die sichere Codierung enthalten. Beispielsweise Open Web Application Security Project (OWASP) Top 10 oder SysAdmin, Audit, Network and Security (SANS) Top 25 Common Weakness Enumeration (CWE).
Stellen Sie den Nachweis bereit, dass Coderepositorys so geschützt sind: Alle Codeänderungen durchlaufen einen Überprüfungs- und Genehmigungsprozess durch einen zweiten Prüfer, bevor sie mit Standard Branch zusammengeführt werden. Entsprechende Zugriffssteuerungen sind vorhanden, der gesamte Zugriff wird durch mehrstufige Authentifizierung (Multi-Factor Authentication, MFA) erzwungen.
Stellen Sie den Nachweis bereit, dass alle in den Produktionsumgebungen vorgenommenen Releases vor ihrer Bereitstellung überprüft und genehmigt werden.
Kontoverwaltung Stellen Sie einen Beweis dafür bereit, dass Standardanmeldeinformationen in den systemkomponenten der Stichprobe entweder deaktiviert, entfernt oder geändert wurden.
Stellen Sie den Nachweis bereit, dass ein Prozess zum Sichern (Härten) von Dienstkonten vorhanden ist und dass dieser Prozess befolgt wurde.
Stellen Sie den Nachweis bereit, dass: Eindeutige Benutzerkonten für alle Benutzer ausgestellt werden, Prinzipien der geringsten Benutzerberechtigungen innerhalb der Umgebung befolgt werden, eine Richtlinie für sichere Kennwörter/Passphrasen oder andere geeignete Abhilfemaßnahmen vorhanden sind, ein Prozess eingerichtet und mindestens alle drei Monate befolgt wird, um Konten zu deaktivieren oder zu löschen, die nicht innerhalb von drei Monaten verwendet werden.
Überprüfen Sie, ob MFA für alle Remotezugriffsverbindungen und alle Verwaltungsschnittstellen ohne Konsole konfiguriert ist, einschließlich des Zugriffs auf Coderepositorys und Cloudverwaltungsschnittstellen.
Protokollieren, Überprüfen und Warnen von Sicherheitsereignissen Stellen Sie den Nachweis bereit, dass Daten zur Protokollierung von Sicherheitsereignissen im Wert von mindestens 30 Tagen sofort verfügbar sind, wobei 90 Tage lang Sicherheitsereignisprotokolle aufbewahrt werden.
Stellen Sie beweise, dass Protokolle regelmäßig überprüft werden und potenzielle Sicherheitsereignisse/Anomalien, die während des Überprüfungsprozesses identifiziert wurden, untersucht und behoben werden.
Stellen Sie den Nachweis bereit, dass Warnungsregeln so konfiguriert sind, dass Warnungen ggf. zur Untersuchung für die folgenden Sicherheitsereignisse ausgelöst werden: Erstellung/Änderungen privilegierter Konten, privilegierte/hoch riskante Aktivitäten oder Vorgänge, Schadsoftwareereignisse, Manipulation von Ereignisprotokollen, IDPS/WAF-Ereignisse. (falls konfiguriert)
Informationsrisikomanagement Stellen Sie beweise, dass eine ratifizierte richtlinie/ein prozess für das Risikomanagement der Informationssicherheit dokumentiert und eingerichtet wurde.
Nachweisen, dass mindestens jährlich eine formelle unternehmensweite Informationssicherheitsrisikobewertung durchgeführt wird.
ODER für eine gezielte Risikoanalyse: Eine gezielte Risikoanalyse wird mindestens alle 12 Monate für jeden instance dokumentiert und durchgeführt, in dem keine herkömmliche Kontrolle oder branchenüblich bewährte Methode vorhanden ist, bei der eine Entwurfs-/technologische Einschränkung das Risiko birgt, dass eine Sicherheitslücke in die Umgebung eingeht oder Benutzer und Daten gefährdet. bei Verdacht oder Bestätigung des Kompromisses.
Überprüfen Sie, ob die Bewertung des Informationssicherheitsrisikos Systemkomponenten oder betroffene Ressourcen, Bedrohungen und Sicherheitsrisiken oder gleichwertige, Auswirkungs- und Wahrscheinlichkeitsmatrizen oder Äquivalente, die Erstellung eines Risikoregisters/Risikobehandlungsplans umfasst.
Stellen Sie den Nachweis bereit, dass Sie über einen Risikomanagementprozess verfügen, der Risiken im Zusammenhang mit Lieferanten und Geschäftspartnern bewertet und verwaltet, und Sie können Änderungen und Risiken identifizieren und bewerten, die sich auf Ihr System interner Kontrollen auswirken könnten.
Reaktion auf Sicherheitsvorfälle Geben Sie Ihren ratifizierten Plan/IRP (Security Incident Response Plan/IRP) an.
Stellen Sie Beweise bereit, die angeben, wie Ihr organization auf Vorfälle reagiert, wie sie verwaltet werden, und dass sie Details zum Reaktionsteam für Vorfälle enthalten, einschließlich Kontaktinformationen, einen internen Kommunikationsplan während des Vorfalls und externe Kommunikation mit relevanten Parteien wie wichtigen Beteiligten, Zahlungsmarken und Käufern, Aufsichtsbehörden (z. B. 72 Stunden für die DSGVO), Aufsichtsbehörden, Direktoren, Kunden sowie Schritte für Aktivitäten wie Klassifizierung, Eindämmung, Entschärfung, Wiederherstellung und Rückkehr zum normalen Geschäftsbetrieb abhängig von der Art des Incidents
Stellen Sie den Nachweis bereit, dass alle Mitglieder des Incident Response-Teams jährliche Schulungen erhalten haben, die es ihnen ermöglichen, auf Vorfälle zu reagieren.
Stellen Sie Beweise dafür bereit, dass die Strategie zur Reaktion auf Vorfälle und die unterstützende Dokumentation überprüft und aktualisiert werden, basierend auf den Erkenntnissen, die aus einer Table Top-Übung gewonnen wurden, den Erkenntnissen aus der Reaktion auf einen Incident und organisatorischen Änderungen.
Geschäftskontinuitätsplan und Notfallwiederherstellungsplan Stellen Sie den Nachweis bereit, dass eine Dokumentation vorhanden ist und verwaltet wird, die den Geschäftskontinuitätsplan beschreibt.
Stellen Sie die Details des Geschäftskontinuitätsplans für die relevanten Mitarbeiter und ihre Rollen und Zuständigkeiten bereit, einschließlich: Geschäftsfunktionen mit zugehörigen Notfallanforderungen und -zielen, System- und Datensicherungsverfahren, Konfiguration und Planung/Aufbewahrung, Wiederherstellungsprioritäts- und Zeitrahmenziele, ein Notfallplan, in dem Aktionen, Schritte und Verfahren beschrieben werden, die befolgt werden müssen, um kritische Informationssysteme, Geschäftsfunktionen und Dienste im Falle eines unerwartete und ungeplante Unterbrechung, ein etablierter Prozess, der die letztendliche vollständige Systemwiederherstellung abdeckt und in den ursprünglichen Zustand zurückkehrt.
Stellen Sie den Nachweis bereit, dass Dokumentation vorhanden ist, verwaltet wird und den Notfallwiederherstellungsplan beschreibt und mindestens enthält: Personal und ihre Rollen, Zuständigkeiten und Eskalationsprozess, Inventar der Informationssysteme, die zur Unterstützung kritischer Geschäftsfunktionen und -dienste verwendet werden, System- und Datensicherungsverfahren und -konfiguration, ein Wiederherstellungsplan, der die Maßnahmen und Verfahren detailliert beschreibt, die befolgt werden müssen, um kritische Informationssysteme und Daten für den Betrieb wiederherzustellen.
Stellen Sie den Nachweis bereit, dass der Geschäftskontinuitätsplan und der Notfallwiederherstellungsplan mindestens alle 12 Monate überprüft werden, um sicherzustellen, dass er in ungünstigen Situationen gültig und wirksam bleibt.
Stellen Sie beweise, dass der Geschäftskontinuitätsplan auf der Grundlage der jährlichen Überprüfung des Plans aktualisiert wird, alle relevanten Mitarbeiter, die Schulungen zu ihren Rollen und Zuständigkeiten erhalten, die in den Notfallplänen zugewiesen sind, die Pläne werden durch Geschäftskontinuitäts- oder Notfallwiederherstellungsübungen getestet, die Testergebnisse werden dokumentiert, einschließlich der Erkenntnisse aus der Übung oder organisatorischen Änderungen.

Sicherheit und Datenschutz bei der Datenverarbeitung

Daten, die zwischen dem Anwendungsbenutzer, zwischengeschalteten Diensten und den Systemen des ISV übertragen werden, müssen durch Verschlüsselung über eine TLS-Verbindung geschützt werden, die mindestens TLS v1.1 unterstützt. (TLS v1.2 und höher wird empfohlen). SieheAnhang A.

Wenn Ihre Anwendung Microsoft 365-Daten abruft und speichert, müssen Sie ein Verschlüsselungsschema für die Datenspeicherung implementieren, das der in Anhang B definierten Spezifikation folgt.

Steuerelemente

Steuerelementfamilie Controls
Daten während der Übertragung Stellen Sie einen Nachweis bereit, der überprüft, ob die TLS-Konfiguration TLS1.2 oder höher ist , und dass ein Inventar vertrauenswürdiger Schlüssel und Zertifikate aufbewahrt und verwaltet wird.
Stellen Sie beweise, dass die TLS-Komprimierung für alle öffentlich zugänglichen Dienste deaktiviert ist, die Webanforderungen verarbeiten, um zu verhindern, dass Das Komprimierungsverhältnis-Informationsleck made Easy (CRIME) verhindert wird, und TLS HSTS ist für 180 Tage an allen Standorten aktiviert und konfiguriert.
Ruhende Daten Stellen Sie beweise, dass ruhende Daten gemäß den Anforderungen des Verschlüsselungsprofils verschlüsselt werden, indem Verschlüsselungsalgorithmen wie Advanced Encryption Standard (AES), RSA und Twofish mit Verschlüsselungsschlüsselgrößen von 256 Bit oder höher verwendet werden.
Datenaufbewahrung, Sicherung und Entsorgung Stellen Sie den Nachweis bereit, dass ein genehmigter Datenaufbewahrungszeitraum formal festgelegt und dokumentiert ist.
Stellen Sie einen Beweis dafür bereit, dass Daten nur für den definierten Aufbewahrungszeitraum aufbewahrt werden, wie in der vorherigen Kontrolle erläutert.
Stellen Sie den Nachweis bereit, dass Prozesse vorhanden sind, um Daten nach dem Aufbewahrungszeitraum sicher zu löschen.
Stellen Sie beweise, dass ein automatisiertes Sicherungssystem vorhanden und so konfiguriert ist, dass Sicherungen zu geplanten Zeiten ausgeführt werden.
Stellen Sie Beweissicherungsinformationen bereit, die gemäß dem Sicherungsplanungsverfahren getestet und regelmäßig wiederhergestellt werden, um die Zuverlässigkeit und Integrität der Daten zu bestätigen.
Stellen Sie beweise geeignete Zugriffssteuerungen und Schutzmechanismen (d. h. unveränderliche Sicherungen) 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.
Datenzugriffsverwaltung Stellen Sie einen Beweis dafür bereit, dass eine Liste von Benutzern mit Zugriff auf Daten und/oder Verschlüsselungsschlüssel verwaltet wird. Einschließlich der geschäftlichen Begründung für jede Person und bestätigung, dass diese Liste der Benutzer basierend auf den Zugriffsberechtigungen, die für ihre Auftragsfunktion erforderlich sind, formal genehmigt wurde, und Die Benutzer sind mit den in der Genehmigung beschriebenen Berechtigungen konfiguriert.
Stellen Sie den Nachweis bereit, dass eine Liste aller Dritten, mit denen Daten geteilt werden, verwaltet wird und dass Vereinbarungen zur Datenfreigabe mit allen Drittanbietern bestehen, die Daten verarbeiten.
Datenschutz Hat Ihr organization ein PIM-System (Privacy Information Management) eingerichtet, implementiert und verwaltet, das eine Verpflichtung der Führung durch eine Richtlinie oder eine andere Form der Dokumentation / eines computerisierten Systems für die Wahrung Ihrer Bemühungen zur Verwaltung von Datenschutzinformationen in Bezug auf Die Vertraulichkeit und Integrität des Systems beinhaltet? Bestimmt Rollen, Zuständigkeiten und Autoritäten jeder Person, die das System unterhält, einschließlich PII-Verarbeitern und Controllern.
Stellen Sie Nachweise für Prozesse bereit, um zu überprüfen, ob die Minimierung von PII stattfindet, die Identifizierung und Löschung von PERSONENBEZOGENen Daten am Ende des Verarbeitungszeitraums erfolgt, Kontrollen für die Übermittlung von personenbezogenen Informationen einschließlich jeglicher Vertraulichkeit vorhanden sind, Aufzeichnungen der Übertragung von personenbezogenen Daten von einem Land/einer Region in ein anderes mit ausdrücklicher Zustimmung dazu vorhanden.
DSGVO Stellen Sie beweise, dass betroffene Personen in der Lage sind, SARs zu erheben, dass der ISV in der Lage ist, alle Speicherorte der Daten betroffener Personen zu identifizieren, wenn er auf eine SARs-Anforderung antwortet, dass es einen Aufbewahrungszeitraum für Sicherungen gibt, der die Entfernung von Daten über SARs anfordert, wenn rollierende Sicherungen über einen Bestimmten Zeitraum entfernt werden (Lebenszyklus der ältesten Sicherungslöschungen/umgeschrieben).
Stellen Sie den Datenschutzhinweis bereit, der alle erforderlichen Elemente wie folgt enthalten sollte: Oranisierungsdetails (Name, Adresse und andere personenbezogene Informationen), die Art der verarbeiteten personenbezogenen Daten, wie lange personenbezogene Daten aufbewahrt werden, die Rechtmäßigkeit der Verarbeitung personenbezogener Daten, die Rechte betroffener Personen; einschließlich: Rechte der betroffenen Person, Recht auf Information, Recht auf Auskunft der betroffenen Person, Recht auf Löschung, Recht auf Einschränkung der Verarbeitung, Recht auf Datenübertragbarkeit, Recht auf Widerspruch, Rechte im Zusammenhang mit automatisierter Entscheidungsfindung einschließlich Profilerstellung.
HIPAA Stellen Sie den Nachweis bereit, dass eine Richtlinie für die HIPAA- und HIPAA-Behandlung innerhalb Ihrer organization für Mitarbeiter, Auftragnehmer, Lieferanten usw. vorhanden ist. Überprüfen Sie unsere organization die Vertraulichkeit, Integrität und Verfügbarkeit von ePH gewährleistet.
Vergewissern Sie sich, dass Sie: Schutz vor vernünftigerweise erwarteten Verwendungen oder Offenlegungen solcher Informationen bereitstellen, die durch die Datenschutzregel nicht zulässig sind, die Einhaltung der Sicherheitsregel durch ihre Mitarbeiter sicherstellen. Stellen Sie einen Datensicherungs- und Notfallwiederherstellungsplan unter 164.308 (a)(7)(ii)(A) und 164.308 (a)(7)(ii)(B) bereit.

Überprüfung optionaler externer Complianceframeworks

Obwohl dies nicht erforderlich ist, können Sie, wenn Sie derzeit iso 27001, PCI DSS, FedRAMP oder SOC2 erfüllen, diese Zertifizierungen verwenden, um einige der Microsoft 365-Zertifizierungskontrollen zu erfüllen. Analysten versuchen, vorhandene externe Sicherheitsframeworks an das Microsoft 365-Zertifizierungsframework anzupassen. Wenn die unterstützende Dokumentation jedoch nicht sicherstellen kann, dass die Microsoft 365-Zertifizierungskontrollen im Rahmen der Überwachung/Bewertung externer Sicherheitsframeworks bewertet wurden, müssen Sie zusätzliche Nachweise dafür bereitstellen, dass diese Kontrollen vorhanden sind.

Die Dokumentation muss angemessen nachweisen, dass die bereichsinterne Umgebung für die Microsoft 365-Zertifizierung in den Geltungsbereich dieser externen Sicherheitsframeworks eingeschlossen wurde. Die Validierung dieser Sicherheitsframeworks wird erfüllt, indem der Nachweis gültiger Zertifizierungen akzeptiert wird, die von renommierten externen Drittanbietern durchgeführt werden. Diese seriösen Unternehmen müssen Mitglieder internationaler Akkreditierungsstellen für relevante Compliance-Programme sein. Siehe ISO-Zertifizierung und Konformitätsstandards für ISO 27001 und Qualifizierte Sicherheitsassessoren (QSA) für PCI-DSS.

In der folgenden Tabelle sind die externen Frameworks und die Dokumentation aufgeführt, die von Zertifizierungsanalysten im Rahmen dieses Validierungsprozesses benötigt werden:

Standard Anforderungen
ISO 27001 Eine öffentlich zugängliche Version der Erklärung zur Anwendbarkeit (Statement of Applicability , SOA) und eine Kopie des ausgestellten ISO 27001-Zertifikats sind erforderlich. Der SOA fasst Ihre Position zu jeder der 114 Informationssicherheitskontrollen zusammen und wird verwendet, um zu identifizieren, ob ein Ausschluss von Kontrollen, die im ISO 27001-Zertifikat nicht zufriedenstellend beschrieben sind. Wenn dies nicht durch überprüfen der öffentlichen Version des SOA ermittelt werden kann, benötigt der Analyst möglicherweise Zugriff auf den vollständigen SOA, wenn ISO 27001 verwendet wird, um einige der Sicherheitskontrollen der Microsoft 365-Zertifizierung zu überprüfen. Neben der Überprüfung des Umfangs der ISO 27001-Bewertungsaktivitäten werden die Analysten auch die Gültigkeit des Auditunternehmens wie oben beschrieben bestätigen.
PCI/DSS Es muss ein gültiges AOC-Dokument ( Level 1 Attestation of Compliance ) bereitgestellt werden, in dem die Anwendung und die Systemkomponenten im Bereich eindeutig identifiziert werden. Eine Selbstbewertungs-AOC wird nicht als Beweis für die Erfüllung bewährter Sicherheitsmethoden akzeptiert. Die AOC wird verwendet, um zu bestimmen, welche der Kontrollen der Microsoft 365-Zertifizierungsspezifikation im Rahmen der PCI-DSS-Bewertung bewertet und bestätigt wurden.
SOC 2 Der SOC 2-Bericht (Typ II) muss aktuell sein (ausgestellt innerhalb der letzten 15 Monate und des deklarierten Zeitraums, der innerhalb der letzten 27 Monate begonnen wurde), damit er als Nachweis für die Konformität mit einer der Bewertungskontrollen innerhalb dieses Microsoft 365-Zertifizierungsrahmens verwendet werden kann.
FedRAMP Das Federal Risk and Authorization Management Program (FedRAMP) ist ein 2011 in den USA gegründetes Bundesprogramm. Es bietet einen standardisierten Ansatz für die Sicherheitsbewertung, Autorisierung und kontinuierliche Überwachung von Cloudprodukten und -diensten.
Framework Zusätzliche Überlegungen
ISO 27001 Anhang C: Beweissammlung – Deltas für ISO 27001.
PCI/DSS Anhang D: Beweissammlung – Deltas für PCI-DSS.
SOC 2 Anhang E: Beweissammlung – Deltas für SOC 2.

Hinweis

Obwohl die oben genannten externen Sicherheitsstandards/-frameworks als Nachweise eingereicht werden können, um einige der Microsoft 365-Zertifizierungskontrollen zu erfüllen, bedeutet das Bestehen der Microsoft 365-Zertifizierung nicht, dass eine App erfolgreich eine Überprüfung anhand dieser Standards/Frameworks besteht. Die Microsoft 365-Zertifizierungsspezifikation ist nur eine kleine Teilmenge dieser Sicherheitsstandards/Frameworks, die es Microsoft ermöglichen, ein Maß an Sicherheit in Bezug auf Ihren Sicherheitsstatus zu erlangen.

Anforderungen für die Verwendung externer Complianceframeworks

✓ Die In-Scope-Umgebung UND alle unterstützenden Geschäftsprozesse MÜSSEN in den Rahmen beliebiger unterstützter externer Sicherheits-Compliance-Frameworks aufgenommen werden und müssen in der bereitgestellten Dokumentation klar angegeben werden.

✓ Unterstützte externe Sicherheitscompliance-Frameworks MÜSSEN aktuell sein, d. a. innerhalb der letzten 12 Monate (oder innerhalb von 15 Monaten, wenn die Neubewertung derzeit durchgeführt wird und Beweise vorgelegt werden können).

✓ Unterstützte externe Sicherheits-Compliance-Frameworks MÜSSEN von einem unabhängigen akkreditierten Unternehmen durchgeführt werden.

Weitere Informationen