Übersicht über das Microsoft 365-Zertifizierungsframework

Dieser Artikel enthält ausführliche Informationen zur Microsoft 365-Zertifizierung, einschließlich einer Liste der erforderlichen Sicherheitskontrollen und Anleitungen für ISVs und Entwickler.

Die Microsoft 365-Zertifizierung ist eine unabhängige Sicherheits- und Datenschutzprüfung von Apps, Add-Ins, Agents und unterstützenden Back-End-Umgebungen (zusammenfassend als Apps bezeichnet), die in die Microsoft 365-Plattform integriert sind. Apps, die erfolgreich sind, werden im gesamten Microsoft 365-Ökosystem als Microsoft 365-zertifiziert gekennzeichnet und können über Compliance-orientierte Suchfilter und Branding leicht in Microsoft 365-Marktplätzen gefunden werden. ISVs haben die Möglichkeit, die Complianceattribute ihrer App auf speziellen Seiten innerhalb dieses Dokumentationssatzes zu teilen.

Die Microsoft 365-Zertifizierung ist für die folgenden Anwendungstypen verfügbar:

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

Wichtig

Die Microsoft 365-Zertifizierung ist eine strenge Überprüfung der Sicherheit und Compliance einer App anhand des Microsoft 365-Zertifizierungsframeworks und erfordert einen erheblichen Zeit- und Ressourcenaufwand. Bevor Sie beginnen, überprüfen Sie bitte die Frameworks für die Konformitätskontrolle , um sicherzustellen, dass Ihre App berechtigt ist. Wenn Sie Fragen haben, senden Sie 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 halten alle Begleitdokumentationen ein, die für Ihre Teilnahme am Microsoft 365-Zertifizierungsprogramm mit Microsoft Corporation ("Microsoft", "wir", "uns" oder "unser") gelten. Sie versichern und garantieren uns, dass Sie befugt sind, diese ergänzenden Bedingungen für die Microsoft 365-Zertifizierung im Namen von Ihnen selbst, einem Unternehmen und/oder einer anderen juristischen Person zu akzeptieren. Wir können diese Ergänzungsbedingungen jederzeit ändern, ergänzen oder beenden. Ihre fortgesetzte Teilnahme am Microsoft 365-Zertifizierungsprogramm nach einer Änderung oder Ergänzung bedeutet, dass Sie den neuen ergänzenden Bedingungen zustimmen. Wenn Sie den neuen Ergänzungsbedingungen nicht zustimmen oder wenn wir diese Ergänzungsbedingungen kündigen, müssen Sie die Teilnahme am Microsoft 365-Zertifizierungsprogramm beenden.

Voraussetzungen

Bevor die Microsoft 365-Zertifizierung vergeben werden kann, muss eine App die folgenden Schritte ausführen:

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

Publisher Attestation ist ein Self-Service-Prozess, bei dem App-Entwickler (ISVs) eine Reihe von Fragen zu ihren Sicherheitspraktiken, z. B. dem Umgang mit vertraulichen Daten, beantworten. Nach Abschluss des Vorgangs erhält die App eine Dokumentationsseite, die sie mit Kunden teilen kann und die ihre bereitgestellten Antworten enthält.

Überprüfen Sie die Kontrollkriterien. Es ist nicht immer eine Voraussetzung, alle Kontrollen zu erfüllen, um eine Zertifizierung zu erhalten. Für jeden der drei in diesem Übersichtsdokument erörterten Sicherheitsbereiche gelten jedoch Schwellenwerte (die nicht offengelegt werden). Die Nichterfüllung kritischer Kontrollen mit der Bezeichnung "Hard Fail" führt dazu, dass die Bewertung nicht besteht.

Kostenstruktur

ISV wird mit der Wirtschaftsprüfungsgesellschaft zusammenarbeiten, um die Zertifizierung zu bezahlen. Für weitere Informationen und um ein Konto bei der Wirtschaftsprüfungsgesellschaft Claranet einzurichten, klicken Sie hier.

Überwachungstyp Inhalt Qualifikationen
Standard Vollständige Bewertung anhand aller anwendbaren Kontrollen Erforderlich für neue Bewertungen und Rezertifizierungen, die sich nicht für ein Satellitenaudit qualifizieren. Erforderlich, wenn eine Rezertifizierung die für ein Satellitenaudit festgelegten Risikokriterien nicht erfüllt
Satelliten-Überwachung Wenn die Kriterien erfüllt sind, reduzierte Kontrolle für das zweite und dritte Bewertungsjahr Berechtigt nach Abschluss der Standardzertifizierung im Jahr 1. Für Jahr 2 und Jahr 3, wenn keine wesentlichen Änderungen stattgefunden haben und die Risikobewertung bestehen
Zusatz in der Verlängerung Auf Anfrage baubar, inklusive Berichtszeit Wird nur hinzugefügt, wenn eine Einreichung mehr Zeit beim Auditor benötigt
Pentest-Tagessatz Pentest-Umfang nach Auftrag und in Übereinstimmung mit den Zertifizierungsanforderungen, der den gesamten vereinbarten Umfang der Bewertung abdeckt Erforderlich, wenn die App in den letzten 12 Monaten nicht bereits über einen seriösen 3rd-Party-Pentest verfügt
Klonen Bestätigung einer geklonten Einreichung, Überprüfung aller Kontrollen, die zusätzliche Nachweise erforderten Eine App, die dieselbe Back-End-Umgebung wie eine App verwendet, die kürzlich die Zertifizierung abgeschlossen hat

Zeitrahmen für die Einreichung

Der Einreichungsprozess zur Zertifizierung besteht aus zwei Phasen:

Phase 1: Ersteinreichung des Dokuments (14-Tage-Zeitrahmen)

In dieser Phase muss der ISV Unterlagen vorlegen, die einen Überblick über die unterstützende Umgebung seiner App bieten. Dies beinhaltet, ist aber nicht beschränkt auf:

  • Architekturdiagramm/Datenfluss
  • Listen der Systemkomponenten
  • Software-Asset-Inventare

Ein Analyst überprüft diese Dokumentation, um den Umfang der Bewertung festzulegen. Der ISV hat 14 Tage Zeit, um die erforderlichen Unterlagen auszufüllen und hochzuladen. Die Nichteinhaltung dieser Frist kann den Prozess verzögern oder zu einer fehlgeschlagenen Einreichung führen.

Stufe 2: Vollständige Überprüfung der Evidenz (60-Tage-Zeitrahmen)

Sobald der Umfang definiert wurde, fährt der ISV mit der Phase der Beweiserhebung fort. In dieser Phase:

  1. Der ISV muss Nachweise für alle anwendbaren Kontrollen hochladen, die anhand des Bereichs definiert sind.

  2. Diese Nachweise werden einer Überprüfung, Überarbeitungen (falls erforderlich) und einem abschließenden Q/A-Prozess unterzogen.

  3. Während dieser Zeit können auch Penetrationstests durchgeführt werden.

Der ISV hat 60 Tage Zeit, um diese Phase abzuschließen, beginnend mit der ersten Beweiseinreichung, die Folgendes umfasst:

  • Hochladen von Nachweisen für alle Kontrollen
  • Überprüfung und Feedback durch Analysten
  • Alle erforderlichen Überarbeitungen der eingereichten Nachweise
  • Abschluss des Q/A-Prozesses

Nichteinhaltung der Frist

Wenn der ISV den Prozess nicht innerhalb des Zeitrahmens von 60 Tagen abschließen kann, schlägt die Bewertung fehl. Nach Ermessen des Analysten kann jedoch unter triftigen Umständen eine Verlängerung von bis zu 60 weiteren Tagen gewährt werden, wie z. B.:

  • Saisonale Feiertage
  • Verzögerungen bei Penetrationstests
  • Interne Änderungen
  • Erforderliche Zeit für die Implementierung notwendiger Änderungen zur Erfüllung der Kontrollanforderungen

Weitere Verlängerungen können nicht gewährt werden, sobald beide 60-Tage-Fristen ausgeschöpft sind.

Umfang der Zertifizierung

Die In-Scope-Umgebung umfasst alle Systeme und Infrastrukturen, die für die Bereitstellung des App-, Add-In- oder Agent-Codes erforderlich sind, sowie alle unterstützenden Back-End-Systeme, mit denen die App/das Add-In/der Agent kommunizieren kann. Alle zusätzlichen Umgebungen, die mit der Umgebung im Geltungsbereich verbunden sind, müssen ebenfalls in den Geltungsbereich aufgenommen werden, es sei denn, eine angemessene Segmentierung wird implementiert und die verbundenen Umgebungen können die Sicherheit der Umgebung im Geltungsbereich nicht beeinträchtigen.

Bitte beachten: Alle separaten Disaster-Recovery-Umgebungen müssen ebenfalls in die In-Scope-Umgebung einbezogen werden, da diese Umgebungen für die Aufrechterhaltung der Servicekontinuität im Falle von Ausfällen der primären Umgebung entscheidend sein können.

Darüber hinaus müssen auch Remotesicherungsumgebungen in den Umfang integriert werden, da sie vertrauliche Microsoft-Daten speichern können. Daher müssen für diese Umgebungen angemessene Sicherheitskontrollen implementiert werden.

Der Begriff In-Scope-Systemkomponenten umfasst alle Geräte und Systeme, die aktiv innerhalb der definierten In-Scope-Umgebung verwendet werden. Zu diesen Komponenten gehören u. a. (kein Anspruch auf Vollständigkeit):

  • Webanwendungen
  • Server (physisch oder virtuell, lokal oder in der Cloud)
  • Optionen
  • Lastenausgleichsmodule
  • Virtuelle Infrastruktur
  • Webverwaltungsportale für Cloudanbieter
  • Cloudressourcen (Virtual Machines, App-Dienste, Speicherkonten, Datenbanken usw.)

Wichtig

Öffentlich zugängliche Systemkomponenten sind besonders anfällig für Angriffe externer Bedrohungsakteure und daher einem höheren Risiko ausgesetzt. In der Regel sollten diese Systeme durch die Implementierung von Netzwerksicherheitskontrollen (NSCs), wie z. B. einer demilitarisierten Zone (DMZ), von internen Systemkomponenten isoliert werden. Der Zweck einer DMZ besteht darin, als Pufferzone zu fungieren, das Vertrauen in externe Systeme zu begrenzen und die Sicherheit zu erhöhen, um interne Systeme und Daten zu schützen. Während eine DMZ in einigen Fällen noch ideal sein kann, verlassen sich moderne Cloudarchitekturen häufig auf alternative Sicherheitsmaßnahmen, die auf bestimmte Bereitstellungsszenarien zugeschnitten sind.

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 untersuchten Umgebung verwendet wird, ist der Anbieter der Cloud-Plattform für einige der Sicherheitskontrollen verantwortlich, die während des Zertifizierungsprozesses bewertet werden. Analysten müssen vom Cloud-Plattformanbieter eine unabhängige externe Überprüfung der Best Practices für die Sicherheit durch externe Compliance-Berichte wie PCI-DSS, Attestation of Compliance (AOC), ISO 27001 oder SOC 2 Typ II-Berichte erhalten.

Weitere Informationen dazu, welche Sicherheitskontrollen wahrscheinlich auf den Bereitstellungstyp anwendbar sind und ob die Umgebung Microsoft 365-Daten verarbeitet oder überträgt, finden Sie in Anhang C. Zu den Bereitstellungstypen gehören:

  • ISV Hosted: Anwendung, die von unabhängigen Softwareanbietern gehostet wird.
  • IaaS gehostet: Infrastruktur, die von Cloud-Plattformen von Drittanbietern bereitgestellt wird.
  • PaaS/Serverless Hosted: Anwendungen, die plattformbasierte oder serverlose Architektur mitteln.
  • Hybrid gehostet: Eine Mischung aus lokalen und in der Cloud gehosteten Komponenten.
  • Gemeinsam gehostet: Freigegebene Cloudumgebungen, die von mehreren Mandanten genutzt werden.

In Fällen, in denen IaaS oder PaaS verwendet wird, muss überprüft werden, ob die Bereitstellung mit den erwarteten Sicherheitskontrollen für die jeweilige Architektur übereinstimmt.

Stichproben

Um eine gründliche Bewertung zu gewährleisten, müssen bei der Probenahme der im Umfang enthaltenen Systemkomponenten Faktoren wie Betriebssysteme, Funktion des primären Geräts, Gerätetyp (z. B. Server, Router, Netzwerksicherheitskontrollen) und geografischer Standort berücksichtigt werden. Die Auswahl von Proben erfolgt zu Beginn des Zertifizierungsprozesses auf der Grundlage dieser Überlegungen. Die folgende Tabelle führt die Stichprobengröße basierend auf der Grundgesamtheit der im Bereich befindlichen Komponenten:

Population Size Beispiel
<=5 1
>5 & <10= 2
>10 & <=30 3
>30 4

Dies gewährleistet eine repräsentative Bewertung der Konformität der Umgebung über verschiedene Konfigurationen und Bereitstellungsmodelle hinweg.

Hinweis

Wenn während der Bewertung Abweichungen zwischen den Geräten festgestellt werden, kann die Stichprobengröße angepasst werden, um eine angemessene Darstellung der Umgebung zu gewährleisten.

Übersicht über den Zertifizierungsprozess

So starten Sie den Microsoft 365-Zertifizierungsprozess:

  1. Publisher Nachweis Wechseln Sie zum Partner Center, und füllen Sie das Formular Publisher Nachweis aus. Hinweis: Wenn Ihre Einreichung älter als drei Monate ist, müssen Sie sie zur Überprüfung und Validierung erneut einreichen.

  2. Zertifizierung starten Wählen Sie im Partner Center die Option "Zertifizierung starten" aus, um mit der ersten Dokumentübermittlung zu beginnen. Dieser Schritt hilft Zertifizierungsanalysten, den Umfang der Bewertung basierend auf der Architektur Ihrer App und der Verwaltung von Microsoft-Daten zu identifizieren. Zu diesem Zeitpunkt müssen Sie ein Konto bei Claranet Limited einrichten.

Die Zertifizierung erfolgt in zwei Hauptphasen:

  1. Erste Dokumentübermittlung In dieser Phase geben Sie wichtige Details an, damit Analysten das Design Ihrer App, den Datenfluss und die Umgebung im Umfang verstehen. Analysten bestimmen die anwendbaren Sicherheitskontrollen und skizzieren die systemkomponenten, die einen Nachweis erfordern. Sie müssen genaue Unterlagen bereitstellen, um diese Überprüfung zu erleichtern, die etwa 5 % des Gesamtprozesses ausmacht.

  2. Vollständige Überprüfung der Beweise In dieser Phase reichen Sie detaillierte Nachweise ein, die die Einhaltung der Sicherheitskontrollen für die im Bereich befindliche Umgebung belegen. Analysten arbeiten in dieser Phase eng mit Ihnen zusammen, um Ihre Einreichungen zu überprüfen, zu klären und zu verifizieren. Diese Phase nimmt den Rest des Prozesses in Anspruch.

Bewertung

Sobald die anfängliche Dokumentübermittlung genehmigt wurde, wird eine Liste der erforderlichen Sicherheitskontrollen im Portal angezeigt. Sie haben 60 Tage Zeit, um für jede Kontrolle einen Nachweis zu erbringen und zu bestätigen, dass sie vorhanden und betriebsbereit ist. Analysten überprüfen Ihre Beweise und genehmigen sie oder fordern zusätzliche Details oder Überarbeitungen an.

Zertifizierung

Sobald Ihre Einreichung von einem Analysten geprüft und validiert wurde, erhalten Sie eine Benachrichtigung über die Zertifizierungsentscheidung. Apps, die die Zertifizierungskriterien erfolgreich erfüllen, erhalten ein Badge, das in ihrem AppSource-Eintrag und den zugehörigen Microsoft-Dokumentation-Seiten angezeigt wird. Auf diesen Seiten finden Sie auch ausführliche Berichte zu den Sicherheits- und Complianceattributen der App.

Überprüfung und Rezertifizierung

Microsoft 365-zertifizierte Apps müssen jährlich einer Neuzertifizierung unterzogen werden, um die kontinuierliche Einhaltung der Microsoft-Standards sicherzustellen. Der Rezertifizierungsprozess umfasst die Neubewertung der im Umfang befindlichen Kontrollen, um zu bestätigen, dass sie mit der aktuellen Umgebung übereinstimmen. Sie können den Rezertifizierungsprozess bis zu 90 Tage vor Ablauf der Zertifizierung beginnen, um Unterbrechungen zu vermeiden. Zertifizierungen bleiben während dieses Zeitraums gültig.

Wenn die Rezertifizierung nicht vor dem Ablaufdatum abgeschlossen wird, wird die Zertifizierung widerrufen. Dies führt zu folgendem Ergebnis:

  • Das Zertifizierungsbadge und das Branding der App werden entfernt.

  • ISVs dürfen die App nicht mehr als Microsoft 365-zertifiziert vermarkten.

Wenn es außerhalb des geplanten Neuzertifizierungszeitraums wesentliche Änderungen an der App gibt, müssen ISVs das Microsoft App Compliance Program informieren, um sicherzustellen, dass die App konform bleibt.

Erste Dokumentübermittlung

Ihre anfängliche Übermittlung muss die folgenden Informationen enthalten:

Übersicht über die Dokumentation Details zur Dokumentation
App-/Add-In-/Agent-Beschreibung Eine Beschreibung des Zwecks und der Funktionalität der App/des Add-Ins/Agents. Dadurch sollte der Zertifizierungsanalyst ein gutes Verständnis dafür erhalten, wie die App/das Add-In/der Agent funktioniert und was ihre beabsichtigte Verwendung ist.
Bericht zu Penetrationstests Ein Penetrationstestbericht, der innerhalb der letzten 12 Monate abgeschlossen wurde. Dieser Bericht muss die Umgebung enthalten, die die Bereitstellung der App/des Add-Ins/Agents unterstützt, sowie alle zusätzlichen Umgebungen, die den Betrieb der App/des Add-Ins/Agents unterstützen. Hinweis: Wenn der ISV derzeit keine jährlichen Penetrationstests durchführt, kann das Audit-Team gegen Aufpreis einen durchführen.
Architekturdiagramme Ein logisches Architekturdiagramm, das einen Überblick auf hoher Ebene ü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 Bereich zu verstehen und die Stichprobenentnahme zu bestimmen. Bitte geben Sie auch an, welcher Hostingumgebungstyp verwendet wird. ISV-gehostet, IaaS, PaaS oder Hybrid. Hinweis: Wenn SaaS verwendet wird, geben Sie bitte die verschiedenen SaaS-Dienste an, die zur Bereitstellung unterstützender Dienste innerhalb der Umgebung verwendet werden.
Öffentlicher Fußabdruck Detaillierung aller öffentlichen IP-Adressen und URLs, die von der unterstützenden Infrastruktur verwendet werden. Dies muss den vollständigen routingfähigen IP-Bereich umfassen, der der Umgebung zugewiesen ist, es sei denn, es wurde eine angemessene Segmentierung implementiert, um den verwendeten Bereich aufzuteilen (ein angemessener Nachweis der Segmentierung ist erforderlich).
Datenflussdiagramme Flussdiagramme, in denen Folgendes detailliert beschrieben ist:
✓ Microsoft 365 Datenflüsse zur und von der App/dem Add-In/Agent (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 im Ruhezustand geschützt werden.
Details zum API-Endpunkt Eine vollständige Auflistung 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 bereit, in der ALLE verwendeten Microsoft-APIs aufgeführt sind und welche Berechtigungen für das Funktionieren der App/des Add-Ins/Agents angefordert werden, zusammen mit einer Begründung für die angeforderten Berechtigungen
Datenspeichertypen Datenspeicherung und -verarbeitung Dokumente beschreiben:
✓ Inwieweit werden Microsoft 365-Daten-EUII und -OII empfangen und gespeichert?
✓ Die Aufbewahrungsfrist der Daten.
✓ Warum die Microsoft 365-Daten erfasst werden.
✓ Wo Microsoft 365-Daten gespeichert werden (sollte auch in den oben bereitgestellten Datenflussdiagrammen enthalten sein).
Bestätigung der Konformität Unterstützende Dokumentation für externe Sicherheitsframeworks, die in der Publisher Attestation-Einreichung enthalten sind oder bei der Überprüfung der Sicherheitskontrollen der Microsoft 365-Zertifizierung berücksichtigt werden sollen. Derzeit werden die folgenden vier unterstützt:
✓ PCI-DSS-Konformitätsbescheinigung (AOC).
✓ SOC 2 Typ I/Typ II-Berichte.
✓ ISMS / IEC - 1S0/IEC 27001 Erklärung zur Anwendbarkeit (SoA) und Zertifizierung.
✓ FedRAMP FedRAMP-Autorisierungspaket und FedRAMP-Bereitschaftsbewertungsbericht.
Webabhängigkeiten Dokumentation mit allen Abhängigkeiten, die von der App mit aktuellen Ausführungsversionen verwendet werden.
Softwarebestand Ein aktuelles Softwareinventar, das die gesamte in der Umgebung verwendete Software zusammen mit den Versionen umfasst.
Hardwareinventar Ein aktuelles Hardwareinventar, das 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.

Tätigkeiten zur Beweiserhebung und -bewertung

Zertifizierungsanalysten müssen die Nachweise für alle Systemkomponenten innerhalb des definierten Beispielsatzes überprüfen. Die Arten von Nachweisen, die zur Unterstützung des Bewertungsprozesses erforderlich sind, umfassen einige oder alle der folgenden:

Beweisaufnahme

  • Erste Dokumentation, hervorgehoben im Leitfaden zur Einreichung der Erstdokumentation
  • Richtliniendokumente
  • Dokumente verarbeiten
  • Einstellungen der Systemkonfiguration
  • Tickets ändern
  • Change Control-Datensätze
  • Systemberichte
  • Sitzungsprotokoll
  • Verträge/Vereinbarungen

Es werden verschiedene Methoden verwendet, um die für den Abschluss des Bewertungsprozesses erforderlichen Nachweise zu sammeln. Diese Beweiserhebung kann in Form von:

  • Dokumente
  • Screenshots
  • Interviews
  • Bildschirmfreigabe

Die verwendeten Techniken zur Beweiserhebung werden während des Bewertungsprozesses festgelegt. Spezifische Beispiele für die Art der in Ihrer Einreichung erforderlichen Nachweise finden Sie im Leitfaden für Musternachweise.

Austausch von Beweisen

Während des Zertifizierungsprozesses können ISVs ihre Compliance-Nachweise direkt mit potenziellen Kunden teilen. Über das Kontrollkästchen im standardmäßig aktivierten Dialogfeld zum Hochladen von Dateien erhalten Microsoft 365-Administratoren Zugriff auf die Zertifizierungsnachweise der App im Teams Admin Center und im Microsoft 365 Admin Center. (Microsoft 365-Administratoren sind für die Konfiguration, Verwaltung und Sicherung von Microsoft 365-Diensten und -Ressourcen innerhalb einer organization verantwortlich.) Diese Transparenz zielt darauf ab, die Sorgfaltspflicht für Unternehmen zu vereinfachen, die neue Anwendungen bewerten, um die Entscheidungsfindung zu beschleunigen. Sollte ein ISV es vorziehen, diese Nachweise nicht zu veröffentlichen, kann er das Kontrollkästchen zum Zeitpunkt der Einreichung einfach deaktivieren und behält die volle Kontrolle darüber, wie und wann seine Compliance-Dokumentation offengelegt wird.

Bewertungsaktivitäten

Zertifizierungsanalysten überprüfen die übermittelten Nachweise, um sicherzustellen, dass alle für die Microsoft 365-Zertifizierung erforderlichen Kontrollen erfüllt sind. Um den Prozess zu beschleunigen, stellen Sie sicher, dass alle in der Erstdokumentation angegebenen Unterlagen vollständig sind und im Voraus bereitgestellt werden.

Während der Überprüfung werden die Analysten die Beweise aus der ersten Einreichung und der Herausgeberbescheinigung bewerten. Sie bestimmen den Umfang der Untersuchung, die Stichprobenseite und ob zusätzliche Beweise erforderlich sind. Analysten verwenden alle gesammelten Informationen, um die Compliance mit der Microsoft 365-Zertifizierungsspezifikation zu bewerten und zu entscheiden, ob Ihre App die definierten Kontrollen erfüllt.

Zertifizierungskriterien für Apps

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

  1. Anwendungssicherheit
  2. Operative Sicherheit
  3. Datenverarbeitung, Sicherheit und Datenschutz

Jeder dieser Sicherheitsbereiche enthält spezifische Schlüsselsteuerelemente, die eine oder mehrere Anforderungen umfassen, die im Rahmen des Bewertungsprozesses ausgewertet werden. Um sicherzustellen, dass die Microsoft 365-Zertifizierung für Entwickler jeder Größe inklusiv ist, 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 zwischen 1 (niedrig) und 3 (hoch) zugewiesen, basierend auf dem wahrgenommenen Risiko, dass diese Kontrolle nicht implementiert wird. Jede der Sicherheitsdomänen hat eine Mindestprozentsatzmarke, um als bestanden zu gelten. Bestimmte Faktoren führen zu automatischen Fehlern, wie zum Beispiel:

  • Verwendung von API-Berechtigungen, die nicht dem Prinzip der geringsten Rechte (PoLP) entsprechen

  • Fehlen von Penetrationstestberichten bei Bedarf.

  • Fehlen von Antischadsoftware-Abwehrmaßnahmen.

  • Implementierung der mehrstufigen Authentifizierung (MFA) für Administratorzugriff fehlgeschlagen.

  • Fehlende oder unzureichende Patchingprozesse.

  • Fehlende DSGVO-Datenschutzhinweise .

Anwendungssicherheit

Die Domäne "Anwendungssicherheit" wertet die folgenden Bereiche aus:

  • Penetrationstests
  • Berechtigungsüberprüfung der Graph-API
  • Verantwortungsvolle KI

Penetrationstests

Penetrationstests sind entscheidend für die Identifizierung und Minimierung von Risiken im Zusammenhang mit der App oder dem Add-In und der zugehörigen unterstützenden Umgebung. Dadurch wird sichergestellt, dass die App den Kunden angemessene Sicherheitsgarantien bietet.

Penetrationstests sind für alle Apps obligatorisch , die Verbindungen mit externen Diensten herstellen, die nicht von Microsoft gehostet oder verwaltet werden. Wenn die App als eigenständige Lösung bereitgestellt wird, die nur Microsoft-Dienste wie GraphAPI verwendet, sind möglicherweise keine Penetrationstests erforderlich. In Azure gehostete Anwendungen müssen jedoch Penetrationstests unterzogen werden, um die Sicherheit der Umgebung zu gewährleisten.

Umfang von Penetrationstests

Infrastrukturtests: Sowohl für die interne als auch für die externe Infrastruktur müssen Penetrationstests in der Liveproduktionsumgebung durchgeführt werden, die die App, das Add-In oder den Agent unterstützt. Dies umfasst Folgendes:

Die Umgebung, in der der Code der App, des Add-Ins oder des Agents gehostet wird (in der Regel wird in der Manifestdatei darauf verwiesen).

Alle zusätzlichen Umgebungen, die mit der App/dem Add-In/Agent interagieren oder deren Betrieb unterstützen (z. B. wenn die App/das Add-In/der Agent mit anderen Webanwendungen außerhalb von Microsoft 365 kommuniziert).

Beim Definieren des Umfangs für Penetrationstests ist es wichtig, alle verbundenen Systeme oder Umgebungen einzubeziehen, die sich auf die Sicherheit der Umgebung auswirken können.

Empfehlungen

Penetrationstests für Webanwendungen: Es wird empfohlen, Web-App-Penetrationstests direkt für die Liveproduktionsumgebung durchzuführen. Web-App-Tests können jedoch in einer Test-/UAT-Umgebung (User Acceptance Testing) durchgeführt werden, sofern der Penetrationstestbericht bestätigt, dass dieselbe Codebasis zum Zeitpunkt des Tests in der Produktion verwendet wird.

Validierung der Segmentierung: Wenn Segmentierungstechniken verwendet werden, um Umgebungen im Geltungsbereich von anderen zu isolieren, muss der Penetrationstestbericht die Wirksamkeit dieser Segmentierungstechniken überprüfen. Dadurch wird sichergestellt, dass keine Schwachstellen durch den Segmentierungsprozess eingeführt werden.

Anforderungen für Penetrationstests

Penetrationstestberichte werden überprüft, um sicherzustellen, dass keine Sicherheitsrisiken vorhanden sind, die den folgenden automatischen Fehlerkriterien entsprechen, die in den nachstehenden Kontrollen beschrieben sind.

Kriterientyp Steuerelemente für Penetrationstests
Allgemeine Kriterien Webanwendungstests (authentifiziert und nicht authentifiziert) und sowohl interne (falls zutreffend) als auch externe Infrastrukturpenetrationstests MÜSSEN jährlich (alle 12 Monate) stattfinden und von einem seriösen unabhängigen Unternehmen durchgeführt werden.
Die Behebung identifizierter kritischer und risikoreicher Sicherheitsrisiken MUSS innerhalb eines Monats nach Abschluss des Penetrationstests abgeschlossen sein oder je nach dokumentiertem Patching-Prozess des ISV früher.
Der vollständige externe Fußabdruck (IP-Adressen, URLs, API-Endpunkte usw.) MUSS in den Geltungsbereich der Penetrationstests einbezogen werden und muss im Penetrationstestbericht klar dokumentiert werden.
Sofern die Umgebung nicht auf PaaS ausgerichtet ist, MÜSSEN die vollständigen internen Netzwerke in den Umfang der Penetrationstests einbezogen und im Penetrationstestbericht klar dokumentiert werden.
Penetrationstests für Webanwendungen MÜSSEN alle Schwachstellenklassen umfassen. beispielsweise die aktuelle OWASP Top 10 oder SANS Top 25 CWE. Die Empfehlung lautet, dass dies im Penetrationstestbericht detailliert beschrieben wird, da es sonst schwierig ist, dies nachzuweisen.
Kritische und risikoreiche Schwachstellen oder Schwachstellen, die als automatischer Fehler eingestuft werden, MÜSSEN vom Penetrationstestunternehmen erneut getestet und im Penetrationstestbericht deutlich als behoben gekennzeichnet werden.
Automatische Fehlerkriterien: Vorhandensein eines nicht unterstützten Betriebssystems oder einer nicht unterstützten JavaScript-Bibliothek.
Vorhandensein von Standard-, Aufzählungs- oder erratenen Administratorkonten.
Das Vorhandensein von Risiken durch Einschleusung von SQL-Befehlen.
Vorhandensein von Cross-Site-Scripting.
Vorhandensein von Sicherheitsanfälligkeiten in Directory Traversal (Dateipfad).
Vorhandensein von HTTP-Sicherheitsrisiken, z. B. Header-Antwortaufteilung, Anforderungsschmuggel und Desync-Angriffe.
Vorhandensein einer Offenlegung des Quellcodes (einschließlich LFI).
Jeder kritische oder hohe Score gemäß den CVSS-Patch-Management-Richtlinien.
Jede signifikante technische Schwachstelle, die leicht ausgenutzt werden kann, um eine große Menge an EUII oder OUI zu kompromittieren.

Wichtig

Berichte müssen in der Lage sein, genügend Sicherheit zu bieten, damit alles, was im obigen Abschnitt zu den Anforderungen für Penetrationstests beschrieben wird, nachgewiesen werden kann.

Berechtigungsüberprüfung für Graph-API

Dadurch wird sichergestellt, dass die App, das Add-In oder der Agent keine übermäßigen oder übermäßig freizügigen Berechtigungen anfordert. Zertifizierungsanalysten überprüfen manuell die von der App angeforderten Berechtigungen und vergleichen sie mit der Übermittlung des Herausgebernachweises.

Ziel ist es, zu bestätigen, dass die angeforderten Berechtigungen dem Prinzip der geringsten Rechte entsprechen. Wenn Analysten feststellen, dass die App Berechtigungen anfordert, die über das Erforderliche hinausgehen, wenden sie sich an den ISV, um die geschäftliche Rechtfertigung für diese Berechtigungen zu überprüfen. Alle festgestellten Abweichungen zwischen den angeforderten Berechtigungen und der Publisher Attestation-Übermittlung müssen während dieser Überprüfung angesprochen und behoben werden.

Verantwortungsvolle KI

Die Informationen, die als Reaktion auf die verantwortlichen KI-Kontrollen übermittelt werden, werden zusammen mit der vom ISV bereitgestellten App-Manifestdatei überprüft. Auf diese Weise kann der Analyst die Integration von Microsoft Copilot in die App überprüfen, die die Zertifizierung durchläuft, und erhält ein klares Verständnis dafür, wie die beiden Interaktionen miteinander interagieren und welche Aktionen im Namen des Kunden ausgeführt werden. Wir sind uns bewusst, dass es wichtig ist, dass KI sowohl verantwortungsvoll als auch dort, wo der Kunde umfassend informiert ist, genutzt wird. Vorausgesetzt, dass die freigegebenen Informationen mit der erwarteten App-Funktionalität und dem Responsible AI Standard oder NIST Trustworthy & Responsible Artificial Intelligence Resource Center von Microsoft übereinstimmen, gelten diese Kontrollen als genehmigt (vorbehaltlich der üblichen Q/A-Prüfungen).

Die Absicht besteht darin, weiter mit Microsoft zusammenzuarbeiten, um einige Details dieser Überprüfung auf den relevanten öffentlich zugänglichen Seiten bereitzustellen, damit Kunden vollständig informierte Entscheidungen über die Verwendung ihrer Daten treffen können, wenn es um Copilot und die zugehörige App geht.

Betriebssicherheit

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

Steuerelemente

Steuerelementfamilie Controls
Sensibilisierungstraining Legen Sie den Nachweis vor, dass die organization Informationssystembenutzern (einschließlich Managern, leitenden Angestellten und Auftragnehmern) im Rahmen der Erstschulung für neue Benutzer oder bei Bedarf aufgrund von Änderungen des Informationssystems etablierte Schulungen zum Sicherheitsbewusstsein anbietet.
Stellen Sie den Nachweis einer von der organization definierten Häufigkeit von Sensibilisierungsschulungen bereit.
Bereitstellung von Nachweisen für die Dokumentation und Überwachung einzelner Aktivitäten zur Sensibilisierung für die Informationssystemsicherheit unter Beibehaltung einzelner Schulungsaufzeichnungen über eine von der organization definierte Häufigkeit.
Schutz vor Schadsoftware – Antivirus Stellen Sie den Nachweis bereit, dass Ihre Antischadsoftwarelösung aktiv und für alle Beispielsystemkomponenten aktiviert und so konfiguriert ist, dass sie die folgenden Kriterien erfüllt:
Wenn es sich um ein Antivirenprogramm handelt, ist das Scannen beim Zugriff aktiviert und die Signaturen sind innerhalb eines Tages auf dem neuesten Stand, und es blockiert automatisch Schadsoftware oder Warnungen und wird unter Quarantäne gestellt, wenn Schadsoftware erkannt wird.
ODER wenn EDR/NGAV (Endpoint Detection and Response/Next-Generation Antivirus) ausgeführt wird, werden regelmäßige Scans durchgeführt, Überwachungsprotokolle werden generiert, und es wird kontinuierlich auf dem neuesten Stand gehalten und verfügt über Selbstlernfunktionen.
Wenn EDR/NGAV, blockiert es bekannte Schadsoftware und identifiziert und blockiert neue Schadsoftwarevarianten basierend auf Makroverhalten und verfügt über vollständige Safelist-Funktionen.
Schutz vor schädlicher Software – Anwendungssteuerung Stellen Sie nachweisbare Nachweise dafür bereit, dass eine genehmigte Liste von Software/Anwendungen mit geschäftlicher Begründung existiert und aktuell ist.
Jede Anwendung muss vor der Bereitstellung einem Genehmigungsprozess unterzogen und abgezeichnet werden.
Diese Anwendungssteuerungstechnologie ist aktiv, aktiviert und für alle Beispielsystemkomponenten wie dokumentiert konfiguriert.
Patch-Management – Patching und Risikoeinstufung Bereitstellung einer Richtliniendokumentation, die regelt, wie neue Sicherheitsrisiken identifiziert und eine Risikobewertung zugewiesen werden.
Liefern Sie Nachweise dafür, wie neue Sicherheitsrisiken identifiziert werden.
Stellen Sie Nachweise bereit, dass allen Sicherheitsanfälligkeiten nach der Identifizierung eine Risikoeinstufung zugewiesen wird.
Den Nachweis erbringen, dass alle erfassten Systemkomponenten gemäß den vom Unternehmen festgelegten Patchzeitrahmen gepatcht werden und nicht unterstützte Betriebssysteme und Softwarekomponenten nicht verwendet werden. Dies sollte ggf. die Codebasis umfassen, wenn serverlose Technologie oder PaaS verwendet wird, oder sowohl die Infrastruktur als auch die Codebasis, wenn IaaS verwendet wird.
Es gelten die Richtlinien für den Patch-Zeitrahmen, z. B. "kritisch – innerhalb von 14 Tagen, hoch – innerhalb von 30 Tagen, mittel – innerhalb von 60 Tagen".
Überprüfung von Sicherheitsrisiken Stellen Sie die vierteljährlichen Berichte zur Überprüfung von Infrastruktur- und Webanwendungsschwachstellen bereit. Das Scannen muss für den gesamten öffentlichen Fußabdruck (IP-Adressen und URLs) und interne IP-Bereiche durchgeführt werden.
Stellen Sie nachweisbare Beweise dafür bereit, dass die Behebung von Schwachstellen, die während des Scans nach Sicherheitsrisiken identifiziert wurden, gemäß Ihrem dokumentierten Patching-Zeitrahmen gepatcht werden.
Netzwerksicherheitskontrollen (NSC) Stellen Sie den Nachweis bereit, dass Netzwerksicherheitskontrollen (NSC) an der Grenze der In-Scope-Umgebung und zwischen dem Umkreisnetzwerk und internen Netzwerken installiert sind.
UND wenn Hybrid, On-Prem, IaaS auch den Nachweis erbringen, dass der gesamte öffentliche Zugriff am Umkreisnetzwerk endet.
Vergewissern Sie sich, dass alle Netzwerksicherheitskontrollen (NSC) so konfiguriert sind, dass Datenverkehr verworfen wird, der nicht explizit in der Regelbasis definiert ist, und dass NSC-Regelüberprüfungen mindestens alle 6 Monate durchgeführt werden.
Steuerung der Änderungen Den Nachweis erbringen, dass alle in Produktionsumgebungen eingeführten Änderungen durch dokumentierte Änderungsanforderungen implementiert werden, die die Auswirkungen der Änderung, Einzelheiten zu Backout-Verfahren, durchzuführenden Tests, Überprüfung und Genehmigung durch autorisiertes Personal enthalten.
Stellen Sie den Nachweis bereit, dass separate Umgebungen vorhanden sind, sodass: Entwicklungs- und Test-/Staging-Umgebungen die Trennung von Aufgaben von der Produktionsumgebung erzwingen, die Aufgabentrennung über Zugriffssteuerungen erzwungen wird, sensible Produktionsdaten nicht in den Entwicklungs- oder Test-/Staging-Umgebungen verwendet werden.
Sichere Softwareentwicklung/-bereitstellung Stellen Sie Richtlinien und Verfahren bereit, die die Entwicklung sicherer Software unterstützen und Branchenstandards und/oder bewährte Methoden für sichere Codierung enthalten. Beispiele: 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 gesichert sind, sodass: alle Codeänderungen vor der Zusammenführung mit dem Hauptzweig einem Überprüfungs- und Genehmigungsprozess durch einen zweiten Prüfer unterzogen werden, geeignete Zugriffskontrollen vorhanden sind und der gesamte Zugriff durch Multi-Faktor-Authentifizierung (MFA) erzwungen wird
Legen Sie den Nachweis bereit, dass alle Releases in der/den Produktionsumgebung(en) vor ihrer Bereitstellung überprüft und genehmigt werden.
Kontoverwaltung Stellen Sie den Nachweis bereit, dass Standardanmeldeinformationen in den Beispielsystemkomponenten entweder deaktiviert, entfernt oder geändert wurden.
Erbringen Sie den Nachweis, dass ein Verfahren 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 wurden, dass die geringstprivilegierten Prinzipien innerhalb der Umgebung befolgt werden, dass eine sichere Kennwort-/Passphrasenrichtlinie oder andere geeignete Gegenmaßnahmen vorhanden sind, dass ein Prozess vorhanden ist und mindestens alle drei Monate befolgt wird, um Konten, die innerhalb von drei Monaten nicht verwendet wurden, entweder zu deaktivieren oder zu löschen.
Stellen Sie sicher, dass MFA für alle RAS-Verbindungen und alle nicht konsolenbezogenen Verwaltungsschnittstellen konfiguriert ist, einschließlich des Zugriffs auf Coderepositorys und Cloudverwaltungsschnittstellen.
Ereignisprotokollierung, Überprüfung und Benachrichtigung Weisen Sie nach, dass die Protokolldaten von Sicherheitsereignissen für mindestens 30 Tage sofort verfügbar sind, wobei die Sicherheitsereignisprotokolle 90 Tage aufbewahrt werden.
Legen Sie den Nachweis bereit, dass die Protokolle regelmäßig überprüft werden und dass alle während des Überprüfungsprozess identifizierten potenziellen Sicherheitsereignisse/Anomalien untersucht und behoben werden
Stellen Sie den Nachweis bereit, dass Warnungsregeln so konfiguriert sind, dass Warnungen zur Untersuchung für die folgenden Sicherheitsereignisse ausgelöst werden, sofern zutreffend: privilegierte Kontoerstellung/-änderungen, privilegierte/risikoreiche Aktivitäten oder Vorgänge, Schadsoftwareereignisse, Manipulation des Ereignisprotokolls, IDPS/WAF-Ereignisse. (falls konfiguriert)
Management von Informationsrisiken Weisen Sie nach, dass eine ratifizierte formelle Richtlinie/ein Prozess für das Informationssicherheitsrisikomanagement dokumentiert und festgelegt ist.
Weisen Sie nach, dass mindestens einmal jährlich eine formelle unternehmensweite Risikobewertung der Informationssicherheit durchgeführt wird.
ODER für gezielte Risikoanalysen: Eine gezielte Risikoanalyse wird dokumentiert und mindestens alle 12 Monate für jede Instance durchgeführt, in der keine traditionelle Kontrolle oder ein bewährtes Verfahren der Branche vorhanden ist, wenn eine Design-/Technologiebeschränkung das Risiko birgt, dass eine Sicherheitsanfälligkeit in die Umgebung eingebracht wird oder Benutzer und Daten gefährdet, bei Verdacht oder Bestätigung eines Kompromisses.
Überprüfen, ob die Risikobewertung für die Informationssicherheit betroffene Systemkomponenten oder Ressourcen, Bedrohungen und Schwachstellen oder gleichwertige, Auswirkungs- und Wahrscheinlichkeitsmatrizen oder gleichwertige, die Erstellung eines Risikoregisters/Risikobehandlungsplans umfasst.
Weisen Sie nach, dass Sie über Risikomanagementprozesse verfügen, die Risiken im Zusammenhang mit Lieferanten und Geschäftspartnern bewerten und steuern, und Sie können Änderungen und Risiken identifizieren und bewerten, die sich auf Ihr System interner Kontrollen auswirken könnten.
Reaktion auf Sicherheitsvorfälle Stellen Sie Ihren ratifizierten Reaktionsplan/Verfahren für Sicherheitsvorfälle (IRP) bereit.
Stellen Sie Nachweise bereit, die darlegen, wie Ihre Organization auf Vorfälle reagiert, wie sie gepflegt werden, und dass sie Details zum Vorfallreaktionsteam einschließlich Kontaktinformationen, einen internen Kommunikationsplan während des Vorfalls und externe Kommunikation mit relevanten Parteien wie wichtigen Stakeholdern, Zahlungsmarken und Acquirern, Regulierungsbehörden (z. B. 72 Stunden für DSGVO), Aufsichtsbehörden, Direktoren, Kunden sowie Schritte für Aktivitäten wie Klassifizierung, Eindämmung, Schadensbegrenzung, Wiederherstellung und Rückkehr zum normalen Geschäftsbetrieb je nach Art des Vorfalls
Weisen Sie nach, dass alle Mitglieder des Vorfallreaktionsteams eine jährliche Schulung erhalten haben, die es ihnen ermöglicht, auf Vorfälle zu reagieren.
Stellen Sie den Nachweis bereit, dass die Strategie für die Reaktion auf Vorfälle und die unterstützende Dokumentation überprüft und aktualisiert werden, entweder auf der Grundlage von Erkenntnissen aus einer Tabletop-Übung, Lehren aus der Reaktion auf einen Vorfall oder organisatorischen Veränderungen.
Geschäftskontinuitätsplan und Notfallwiederherstellungsplan Stellen Sie den Nachweis bereit, dass eine Dokumentation vorhanden ist und gepflegt wird, in der der Geschäftskontinuitätsplan beschrieben wird.
Der Geschäftskontinuitätsplan beschreibt das relevante Personal und seine Rollen und Verantwortlichkeiten, einschließlich: Geschäftsfunktionen mit den zugehörigen Notfallanforderungen und -zielen, System- und Datensicherungsverfahren, Konfiguration und Planung/Aufbewahrung, Wiederherstellungspriorität und Zeitrahmenziele, einen Notfallplan mit detaillierten Aktionen, Schritten und Verfahren, die befolgt werden müssen, um kritische Informationssysteme, Geschäftsfunktionen und Dienste im Falle einer Unerwartete und ungeplante Unterbrechung ist ein etablierter Prozess, der die eventuelle vollständige Systemwiederherstellung und die Rückkehr zum ursprünglichen Zustand abdeckt.
Stellen Sie den Nachweis bereit, dass die Dokumentation vorhanden ist, gepflegt wird und den Notfallwiederherstellungsplan umreißt und mindestens Folgendes umfasst: Personal und seine Rollen, Verantwortlichkeiten und Eskalationsverfahren, Bestandsaufnahme der Informationssysteme, die zur Unterstützung kritischer Geschäftsfunktionen und -dienste verwendet werden, System- und Datensicherungsverfahren und -konfiguration, einen Wiederherstellungsplan, in dem Aktionen und Verfahren aufgeführt sind, die zur Wiederherstellung des Betriebs kritischer Informationssysteme und Daten zu befolgen sind.
Weisen Sie nach, dass der Geschäftskontinuitätsplan und der Notfallwiederherstellungsplan mindestens alle 12 Monate überprüft werden, um sicherzustellen, dass sie in widrigen Situationen gültig und wirksam bleiben.
Erbringen Sie den Nachweis, dass der Geschäftskontinuitätsplan auf der Grundlage der jährlichen Überprüfung des Plans aktualisiert wird, alle relevanten Mitarbeiter zu ihren in den Notfallplänen zugewiesenen Rollen und Verantwortlichkeiten geschult werden, 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.

Datenverarbeitung, Sicherheit und Datenschutz

Um die Datensicherheit zu gewährleisten, müssen alle Daten, die zwischen dem Anwendungsbenutzer, den zwischengeschalteten Diensten und den ISV-Systemen übertragen werden, über eine TLS-Verbindung (Transport Layer Security) verschlüsselt werden. TLS 1.2 ist mindestens erforderlich, wobei TLS 1.3 oder höher dringend empfohlen wird. Weitere Einzelheiten finden Sie in Anhang A.

Für Anwendungen, die Microsoft 365-Daten abrufen oder speichern, ist die Implementierung eines Datenspeicherverschlüsselungsschemas obligatorisch. Dies muss mit den in Anhang B beschriebenen Spezifikationen übereinstimmen.

Steuerelemente

Steuerelementfamilie Controls
Daten während der Übertragung Stellen Sie den Nachweis bereit, dass die TLS-Konfiguration innerhalb der Anforderungen an die TLS-Profilkonfiguration TLS1.2 oder höher ist und dass ein Bestand an vertrauenswürdigen Schlüsseln und Zertifikaten geführt und verwaltet wird.
Der Nachweis zeigt, dass die TLS-Komprimierung für alle öffentlich zugänglichen Dienste, die Webanforderungen verarbeiten, deaktiviert ist, um das Komprimierungsverhältnis zu verhindern Info-leak Made Easy (CRIME), und TLS HSTS ist aktiviert und auf allen Websites auf 180 Tage konfiguriert.
Ruhende Daten Weisen Sie nach, dass ruhende Daten gemäß den Anforderungen des Verschlüsselungsprofils verschlüsselt werden, indem Sie Verschlüsselungsalgorithmen wie Advanced Encryption Standard (AES), RSA und Twofish mit Verschlüsselungsschlüsselgrößen von 256 Bit oder höher verwenden.
Datenaufbewahrung, Sicherung und Entsorgung Stellen Sie den Nachweis bereit, dass ein genehmigter Zeitraum für die Datenaufbewahrung formell festgelegt und dokumentiert wurde.
Den Nachweis erbringen, dass Daten nur für den definierten Aufbewahrungszeitraum aufbewahrt werden, wie im vorherigen Kontrollzeitraum beschrieben.
Weisen Sie nach, dass Prozesse vorhanden sind, um Daten nach Ablauf der Aufbewahrungsfrist sicher zu löschen.
Stellen Sie den Nachweis bereit, dass ein automatisiertes Sicherungssystem vorhanden und so konfiguriert ist, dass Sicherungen zu geplanten Zeiten ausgeführt werden.
Bereitstellen von Beweisen Sicherungsinformationen werden gemäß dem Sicherungsplanungsverfahren getestet und regelmäßig wiederhergestellt, um die Zuverlässigkeit und Integrität der Daten zu bestätigen.
Nachweis bereitstellen Geeignete Zugriffskontrollen und Schutzmechanismen (d.h. unveränderliche Backups) werden implementiert, um sicherzustellen, dass Backups / System-Snapshots vor unbefugtem Zugriff geschützt sind und die Vertraulichkeit, Integrität und Verfügbarkeit der Backup-Daten sichergestellt sind.
Verwaltung des Datenzugriffs Den Nachweis erbringen, dass eine Liste der Benutzer mit Zugriff auf Daten und/oder Verschlüsselungsschlüssel geführt wird. Einschließlich der geschäftlichen Begründung für jede Person und der Bestätigung, wurde diese Liste von Benutzern formell basierend auf den Zugriffsberechtigungen genehmigt, die für ihre Funktion erforderlich sind, und die Benutzer werden mit den in der Genehmigung beschriebenen Berechtigungen konfiguriert.
Stellen Sie den Nachweis bereit, dass eine Liste aller Dritten, für die Daten freigegeben werden, geführt wird und dass mit allen Dritten, die Daten konsumieren, Vereinbarungen zur gemeinsamen Nutzung von Daten getroffen wurden.
Datenschutz Verfügt Ihre Organization über ein Privacy Information Management (PIM)-System, das die Führung in Form einer Richtlinie oder einer anderen Form der Dokumentation / eines computergestützten Systems dazu verpflichtet, wie Ihre Bemühungen zur Verwaltung von Datenschutzinformationen für die Vertraulichkeit und Integrität des Systems aufrechterhalten werden? Bestimmt die Rollen, Verantwortlichkeiten und Befugnisse jeder Person, die das System verwaltet, einschließlich PII-Prozessoren und -Controller.
Bereitstellung von Nachweisen von Prozessen zur Überprüfung der Minimierung der PII-Minimierung, der De-Identifizierung und Löschung von PII am Ende des Verarbeitungszeitraums, der Kontrollen für die Übertragung personenbezogener Daten, einschließlich jeglicher Vertraulichkeit, der Aufzeichnung der Übertragung von personenbezogenen Daten aus einem Land/einer Region in ein anderes mit ausdrücklicher Zustimmung besteht.
DSGVO Bereitstellung des Nachweises, dass betroffene Personen in der Lage sind, SARs auszulösen, dass der ISV in der Lage ist, alle Speicherorte der Daten betroffener Personen zu identifizieren, wenn er auf eine SAR-Anfrage reagiert, dass es eine Aufbewahrungsfrist für Backups gibt, die es ermöglicht, dass Clients, die die Entfernung von Daten über SARs anfordern, entfernt werden, wenn parallele Backups über einen bestimmten Zeitraum entfernt werden (Lebenszyklus der ältesten Sicherungslöschungen/-überschreibungen).
Stellen Sie die Datenschutzerklärung bereit, die alle erforderlichen Elemente wie folgt enthalten sollte: organisatorische Details (Name, Adresse und andere personenbezogene Daten), die Art der verarbeiteten personenbezogenen Daten, wie lange personenbezogene Daten aufbewahrt werden, die Rechtmäßigkeit der Verarbeitung personenbezogener Daten, Rechte der betroffenen Personen; Einschließlich: Rechte der betroffenen Person, Recht auf Information, Recht auf Zugang der betroffenen Person, Recht auf Löschung, Recht auf Einschränkung der Verarbeitung, Recht auf Datenübertragbarkeit, Widerspruchsrecht, Rechte in Bezug auf eine automatisierte Entscheidungsfindung einschließlich Profiling.
HIPAA Stellen Sie den Nachweis bereit, dass: eine Richtlinie für HIPAA und HIPAA-Handhabung innerhalb Ihrer organization für Mitarbeiter, Auftragnehmer, Lieferanten usw. vorhanden ist. Überprüfen Sie, ob unsere organization die Vertraulichkeit, Integrität und Verfügbarkeit von ePH gewährleistet.
Stellen Sie sicher, dass: Sie Schutz vor vernünftigerweise erwarteten Verwendungen oder Offenlegungen solcher Informationen bieten, die nach der Datenschutzregel nicht zulässig sind, und die Einhaltung der Sicherheitsregel durch die Mitarbeiter sicherstellen. Bereitstellung eines Datensicherungs- und Notfallwiederherstellungsplans gemäß 164.308 (a)(7)(ii)(A) und 164.308 (a)(7)(ii)(B).

Optionale externe Complianceframeworkprüfung

Wenn Ihre organization bereits externe Sicherheitsframeworks wie ISO 27001, PCI-DSS, FedRAMP oder SOC 2 Type 2 erfüllt, können Sie diese Zertifizierungen nutzen, um einige der Microsoft 365-Zertifizierungskontrollen zu erfüllen. Die Analysten werden versuchen, Ihre bestehenden externen Sicherheitsframeworks an die Anforderungen der Microsoft 365-Zertifizierung anzupassen.

Wenn Ihre unterstützende Dokumentation jedoch nicht nachweist, dass Microsoft 365-Zertifizierungssteuerelemente explizit im Rahmen der Überwachung oder Bewertung des externen Frameworks bewertet wurden, müssen Sie zusätzliche Nachweise erbringen, um zu überprüfen, ob diese Steuerelemente vorhanden sind.

Anforderungen an die Dokumentation:

Aus der Dokumentation muss eindeutig hervorgehen, dass die Umgebung im Umfang der Microsoft 365-Zertifizierung in den Geltungsbereich der ewigen Sicherheitsframeworks eingeschlossen ist. Die Validierung dieser Frameworks wird durch die Annahme des Nachweises gültiger Zertifizierungen erfüllt, die von seriösen, akkreditierten externen Prüfern ausgestellt wurden.

Diese externen Prüfer müssen Mitglieder internationaler Akkreditierungsstellen sein, wie z. B.:

  • Zertifizierungs- und Konformitätsstandards für ISO 27001

  • Quality Security Assessors (QSA) für PCI-DSS

Weitere Informationen finden Sie in den spezifischen Richtlinien und Standards für die externen Rahmenwerke, die für Ihre Zertifizierung relevant sind.

In der folgenden Tabelle sind die erforderlichen Rahmenbedingungen und Dokumentationen aufgeführt, die von Zertifizierungsanalysten im Rahmen des Validierungsprozesses akzeptiert werden.

Standard Anforderungen
ISO 27001 Eine öffentlich zugängliche Version der Erklärung zur Anwendbarkeit (SOA) und eine Kopie des ausgestellten ISO 27001-Zertifikats sind erforderlich. Die SOA fasst Ihre Position zu jeder der 114 Informationssicherheitskontrollen zusammen und wird verwendet, um festzustellen, ob Kontrollen ausgeschlossen werden, die im ISO 27001-Zertifikat nicht zufriedenstellend beschrieben sind. Wenn dies nicht durch Überprüfen der öffentlich zugänglichen Version der SOA festgestellt werden kann, benötigt der Analyst möglicherweise Zugriff auf die vollständige SOA, wenn ISO 27001 verwendet wird, um einige der Sicherheitskontrollen der Microsoft 365-Zertifizierung zu validieren. Neben der Validierung des Umfangs der ISO 27001-Bewertungsaktivitäten bestätigen die Analysten auch die Gültigkeit der oben beschriebenen Prüfgesellschaft.
ISO 22301 Es müssen ein gültiges ISO 22301-Zertifikat vorgelegt werden, das von einer akkreditierten Zertifizierungsstelle ausgestellt wurde, und ein Dokument, das den Umfang der Bewertung des Business Continuity Management Systems (BCMS) beschreibt. Das Zertifikat und die Umfangsdokumentation werden verwendet, um zu überprüfen, ob die Anwendung, die unterstützenden Dienste und die betrieblichen Prozesse im Rahmen eines formellen Business Continuity Management-Programms bewertet wurden. Die Bewertungsanalysten überprüfen den Umfang der Zertifizierung, bestätigen die Gültigkeit der Zertifizierungsstelle und bestimmen, welche Microsoft 365-Zertifizierungs-Geschäftskontinuitätskontrollen durch den ISO 22301-Bewertungsnachweis erfüllt werden können.
ISO 27031 Es muss ein gültiges ISO 27031-Zertifikat oder ein Bewertungsbericht vorgelegt werden, der von einer akkreditierten Zertifizierungs- oder Bewertungsstelle ausgestellt wurde und in dem die Anwendung, die Infrastruktur und die unterstützenden Informations- und Kommunikationstechnologiedienste (IKT) eindeutig angegeben sind. Die Dokumentation wird verwendet, um die IKT-Bereitschaft für die Geschäftskontinuität zu bewerten, einschließlich der Planung der Notfallwiederherstellung, der Wiederherstellungsfähigkeiten und der Resilienzprozesse. Die Bewertungsanalysten überprüfen den Umfang der Bewertung, bestätigen die Gültigkeit der Bewertungs-organization und bestimmen, welche Microsoft 365-Zertifizierungs-, Notfallwiederherstellungs- und Betriebsresilienzkontrollen durch die ISO 27031-Bewertungsnachweise erfüllt werden können
PCI/DSS Es muss ein gültiges Dokument der Stufe 1 über die Konformitätsbescheinigung (Attestation of Compliance , AOC) vorgelegt werden, in dem die Anwendungs- und Systemkomponenten eindeutig identifiziert sind. Ein AOC zur Selbstbewertung wird nicht als Nachweis für die Einhaltung bewährter Sicherheitsmethoden akzeptiert. Das AOC wird verwendet, um zu bestimmen, welche der Microsoft 365-Zertifizierungsspezifikationskontrollen im Rahmen der PCI DSS-Bewertung ausgewertet und bestätigt wurden.
SOC 2 Der SOC 2-Bericht (Typ II) muss aktuell sein (innerhalb der letzten 15 Monate ausgestellt und der erklärte Zeitraum wurde innerhalb der letzten 27 Monate begonnen), damit er als Nachweis der Konformität mit einer der Bewertungskontrollen in diesem Microsoft 365-Zertifizierungsrahmen verwendet werden kann.
FedRAMP Das Federal Risk and Authorization Management Program (FedRAMP) ist ein 2011 von der US-Bundesregierung eingeführtes Programm. Es bietet einen standardisierten Ansatz für die Sicherheitsbewertung, Autorisierung und kontinuierliche Überwachung von Cloud-Produkten und -Diensten.
Framework Zusätzliche Überlegungen
ISO 27001 Anhang C: Sammlung von Beweisen – Deltas für ISO 27001.
PCI-DSS Anhang D: Sammlung von Beweisen – Deltas für PCI-DSS.
SOC 2 Anhang E: Beweiserhebung – Deltas für SOC 2.

Hinweis

Externe Sicherheitsstandards oder Frameworks können zwar als unterstützender Nachweis eingereicht werden, um bestimmte Microsoft 365-Zertifizierungskontrollen zu erfüllen, aber der Erhalt der Microsoft 365-Zertifizierung erfordert eine separate Bewertung. Das Erreichen der Microsoft 365-Zertifizierung bedeutet nicht, dass die App die Audits für diese externen Frameworks vollständig bestanden hat. Die Microsoft 365-Zertifizierungsspezifikation konzentriert sich auf eine bestimmte Teilmenge von Kontrollen, die von diesen Frameworks abgeleitet werden, um Microsoft ein höheres Maß an Sicherheit in Bezug auf den Sicherheitsstatus Ihrer App zu bieten.

Anforderungen zur Verwendung externer Complianceframeworks

Anforderungen für die Verwendung externer Complianceframeworks

Die Umgebung im Umfang und alle unterstützenden Geschäftsprozesse müssen in den Geltungsbereich jedes unterstützten externen Sicherheits-Compliance-Frameworks einbezogen werden. Diese müssen in den mitgelieferten Unterlagen eindeutig dokumentiert werden.

Externe Sicherheits-Compliance-Frameworks müssen aktuell sein, d. h. sie sollten innerhalb der letzten 12 Monate bewertet werden (oder 15 Monate, wenn eine laufende Neubewertung mit unterstützenden Nachweisen verifiziert werden kann)

Externe Sicherheitskonformitätsbewertungen müssen von einem unabhängigen, akkreditierten Unternehmen durchgeführt werden.

Externe Framework-Validierungskriterien

SOC 2 Typ 2-Bewertung

  • Der SOC 2-Bericht muss ein Bericht vom Typ 2 sein
  • Das SOC 2-Audit muss die zu bewertende M365-Umgebung umfassen
  • Das SOC 2-Audit muss innerhalb der letzten 12 Monate abgeschlossen sein
  • Die Kontrollen müssen angemessen dargestellt und ordnungsgemäß gestaltet sein, wie es für einen Bericht des Typs 2 erforderlich ist
  • Das SOC 2-Audit muss von einem qualifizierten externen Dritten durchgeführt werden
  • Die Testverfahren müssen bestätigen, dass Sicherheitskontrollen vorhanden sind und vom Prüfer ordnungsgemäß validiert werden.

ISO 27001-Bewertung

  • Das ISO 27001-Audit muss die in dieser M365-Bewertung angegebene Umgebung einbeziehen
  • Das ISO 27001-Zertifikat muss aktuell und für das Unternehmen anwendbar sein
  • Die ISO 27001 Bewertung muss von einem akkreditierten externen Dritten durchgeführt werden (interne ISO 27001 Audits werden nicht akzeptiert)
  • Die ISO 27001-Bewertung muss innerhalb der letzten 12 Monate abgeschlossen sein

PCI-DSS-Bewertung

  • Das AOC-Dokument muss die zu bewertende M365-Umgebung klar definieren
  • Das AOC muss aktuell sein
  • Das AOC muss von der QSA und dem Unternehmen unterzeichnet werden

Weitere Informationen

  • Last updated on