Freigeben über

Übersicht über das Microsoft 365-Zertifizierungsframework

  • Artikel

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 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, die Complianceattribute ihrer App 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)
  • CoPilot-Erweiterungen

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. Bevor Sie beginnen, überprüfen Sie die Compliancesteuerungsframeworks , um zu überprüfen, ob Ihre App berechtigt ist. Wenn Sie Fragen haben, senden Sie eine E-Mail an appcert@microsoft.com.

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 App-Entwickler (ISVs) eine Reihe von Fragen zu ihren Sicherheitsmethoden beantworten, z. B. den Umgang mit vertraulichen Daten. Nach Abschluss des Vorgangs erhält die App spezielle Badging- und Listing-Einträge im Microsoft AppSource-Marketplace.

Überprüfen der Kontrollkriterien Es ist nicht immer eine Voraussetzung, 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. Wenn kritische Kontrollen nicht erfüllt werden, die als "harter Fehler" bezeichnet werden, führt dies dazu, dass die Bewertung fehlschlägt.

Übermittlungszeitrahmen

Der Übermittlungsprozess umfasst zwei Phasen, um die Zertifizierung zu erreichen:

Phase 1: Anfängliche Dokumentübermittlung (Zeitrahmen von 14 Tagen)

In dieser Phase muss der ISV eine Dokumentation übermitteln, die einen Überblick über die unterstützende Umgebung seiner App bietet. Dies umfasst, ist aber nicht beschränkt auf:

  • Architekturdiagramm/Datenfluss
  • Systemkomponentenlisten
  • Softwareressourcenbestände

Ein Analyst wird diese Dokumentation überprüfen, um den Umfang der Bewertung zu definieren. Der ISV hat 14 Tage Zeit, um die erforderliche Dokumentation abzuschließen und hochzuladen. Wenn diese Frist nicht eingehalten wird, kann dies den Prozess verzögern oder zu einer fehlgeschlagenen Übermittlung führen.

Phase 2: Vollständige Beweisüberprüfung (Zeitrahmen von 60 Tagen)

Nachdem der Bereich definiert wurde, fährt der ISV mit der Beweissammlungsphase fort. In dieser Phase:

  1. Der ISV muss Beweise für alle anwendbaren Kontrollen hochladen, die aus dem Bereich definiert sind.
  2. Dieser Beweis wird überprüft, (falls erforderlich) überarbeitet und ein abschließender QA-Prozess durchgeführt.
  3. Bei Bedarf können während dieser Zeit auch Penetrationstests durchgeführt werden.

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

  • Hochladen von Beweisen für alle Steuerelemente
  • Analystenbewertung und Feedback
  • Alle erforderlichen Überarbeitungen der vorgelegten Nachweise
  • Abschluss des QA-Prozesses

Versäumnis der Frist

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

  • Saisonale Feiertage
  • Verzögerungen bei Penetrationstests
  • Interne Änderungen
  • Zeitaufwand für die Implementierung der erforderlichen Änderungen, um die Kontrollanforderungen zu erfüllen

Es können keine weiteren Erweiterungen gewährt werden, sobald beide 60-Tage-Zeitrahmen erschöpft sind.

Zertifizierungsbereich

Die Bereichsumgebung umfasst alle Systeme und Infrastruktur, die zum Bereitstellen der App oder des Add-In-Codes erforderlich sind, sowie alle unterstützenden Back-End-Systeme, mit denen die App/Add-In kommunizieren kann. Alle zusätzlichen Umgebungen, die mit der Bereichsumgebung verbunden sind, müssen ebenfalls in den Bereich eingeschlossen werden, es sei denn, eine angemessene Segmentierung wird implementiert und die verbundenen Umgebungen können die Sicherheit der bereichsinternen Umgebung nicht gefährden.

Hinweis: Alle separaten Notfallwiederherstellungsumgebungen müssen auch in die Bereichsumgebung eingeschlossen werden, da diese Umgebungen bei Ausfällen der primären Umgebung für die Aufrechterhaltung der Dienstkontinuität von entscheidender Bedeutung sein können.

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

Der Begriff systeminterne Komponenten umfasst alle Geräte und Systeme, die aktiv in der definierten Bereichsumgebung verwendet werden. Diese Komponenten umfassen, sind aber nicht beschränkt auf:

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

Wichtig

Öffentlich zugängliche Systemkomponenten sind besonders anfällig für Angriffe durch externe Bedrohungsakteure und daher ein höheres Risiko. In der Regel sollten diese Systeme durch die Implementierung von Netzwerksicherheitskontrollen (Network Security Controls, NSCs), z. B. einer demilitarisierten Zone (DMZ), von internen Systemkomponenten isoliert werden. Der Zweck einer DMZ besteht darin, als Pufferzone zu fungieren, das Vertrauen zu begrenzen, das auf externe Systeme ausgedehnt wird, und die Sicherheit zu erhöhen, um interne Systeme und Daten zu schützen. Während eine DMZ in einigen Fällen immer noch ideal sein kann, basieren 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 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.

Ausführliche 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 Hosted: Infrastruktur, die von Cloudplattformen von Drittanbietern bereitgestellt wird.
  • PaaS/Serverlos gehostet: Anwendungen, die plattformbasierte oder serverlose Architektur im Durchschnitt verwenden.
  • Hybrid gehostet: Eine Mischung aus lokalen und in der Cloud gehosteten Komponenten.
  • Freigegeben gehostet: Freigegebene Cloudumgebungen, die von mehreren Mandanten genutzt werden.

In Fällen, in denen IaaS oder PaaS verwendet wird, müssen Beweise dafür verwendet werden, dass die Bereitstellung den erwarteten Sicherheitskontrollen für die relevante Architektur entspricht.

Probenahme

Um eine gründliche Bewertung sicherzustellen, müssen bei der Stichprobenentnahme der systeminternen Komponenten Faktoren wie Betriebssysteme, primäre Gerätefunktion, Gerätetyp (z. B. Server, Router, Netzwerksicherheitskontrollen) und geografischer Standort berücksichtigt werden. Beispiele werden zu Beginn des Zertifizierungsprozesses basierend auf diesen Überlegungen ausgewählt. Die folgende Tabelle zeigt die Stichprobengröße basierend auf der Grundgesamtheit von Komponenten im Bereich:

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

Dadurch wird eine repräsentative Bewertung der Konformität der Umgebung über verschiedene Konfigurationen und Bereitstellungsmodelle hinweg sichergestellt.

Hinweis

Wenn bei der Bewertung Abweichungen zwischen 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. Herausgebernachweis Wechseln Sie zum Partner Center, und füllen Sie das Formular Herausgebernachweis aus. Hinweis: Wenn Ihre Übermittlung älter als drei Monate ist, müssen Sie sie zur Überprüfung und Validierung erneut übermitteln.

  2. Zertifizierung starten Wählen Sie einmal im Partner Center die Option "Zertifizierung starten" aus, um mit der ersten Dokumentübermittlung zu beginnen. Dieser Schritt hilft Zertifizierungsanalysten dabei, den Umfang der Bewertung basierend auf der Architektur Ihrer App und ihrer Verwaltung von Microsoft-Daten zu identifizieren.

Die Zertifizierung erfolgt in zwei Standard Phasen:

  1. Anfängliche Dokumentübermittlung In dieser Phase geben Sie wichtige Details an, um Analysten dabei zu helfen, den Entwurf, den Datenfluss und die bereichsinterne Umgebung Ihrer App zu verstehen. Analysten bestimmen die anwendbaren Sicherheitskontrollen und beschreiben die Systemkomponenten, die Nachweise erfordern. Sie müssen eine genaue Dokumentation bereitstellen, um diese Überprüfung zu erleichtern, die etwa 5 % des gesamten Prozesses ausmacht.

  2. Vollständige Beweisüberprüfung In dieser Phase übermitteln Sie detaillierte Nachweise, die die Einhaltung der Sicherheitskontrollen für die bereichsbezogene Umgebung belegen. Analysten arbeiten während dieser Phase eng mit Ihnen zusammen, um Ihre Übermittlungen zu überprüfen, zu klären und zu überprüfen. Diese Phase dauert den Rest des Prozesses.

Bewertung

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

Zertifizierung

Nachdem Ihre Übermittlung von einem Analysten überprüft und überprüft wurde, erhalten Sie eine Benachrichtigung über die Zertifizierungsentscheidung. Apps, die die Zertifizierungskriterien erfolgreich erfüllen, erhalten einen Badge, der auf ihrem AppSource-Eintrag und den zugehörigen Microsoft-Dokumentation Seiten angezeigt wird. Diese Seiten enthalten auch detaillierte Berichte zu den Sicherheits- und Complianceattributen der App.

Überprüfung und Erneute Zertifizierung

Microsoft 365 Certified Apps müssen jährlich erneut zertifiziert werden, um sicherzustellen, dass die Standards von Microsoft weiterhin eingehalten werden. Der Prozess der erneuten Zertifizierung umfasst die Neubewertung der bereichsinternen Steuerelemente, um zu bestätigen, dass sie der aktuellen Umgebung entsprechen. Sie können den Prozess der erneuten Zertifizierung bis zu 90 Tage vor Ablauf der Zertifizierung starten, um Unterbrechungen zu vermeiden. Zertifizierungen bleiben während dieses Zeitraums gültig.

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

  • Der Zertifizierungsbadge und das Branding der App werden entfernt.

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

Wenn außerhalb des geplanten Rezertifizierungszeitraums wesentliche Änderungen an der App vorgenommen werden, müssen ISVs das Microsoft App-Complianceprogramm informieren, um sicherzustellen, dass die App konform bleibt.

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 übermittelten Nachweise, um zu überprüfen, ob alle für die Microsoft 365-Zertifizierung erforderlichen Kontrollen erfüllt sind. Um den Prozess zu beschleunigen, stellen Sie sicher, dass alle in der Anfänglichen Dokumentationsübermittlung angegebenen Dokumentationen vollständig und im Voraus bereitgestellt sind.

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

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 Faktoren führen zu automatischen Fehlern, einschließlich

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

  • Fehlende Penetrationstests melden sich bei Bedarf.

  • Fehlende Anti-Malware-Schutzmaßnahmen.

  • Fehler beim Implementieren der mehrstufigen Authentifizierung (Multi-Factor Authentication, MFA) für den Administratorzugriff.

  • Fehlende oder unzureichende Patchprozesse.

  • Mangel an konformen Datenschutzhinweisen der DSGVO .

Anwendungssicherheit

Die Anwendungssicherheitsdomäne wertet die folgenden Bereiche aus:

  • GraphAPI-Berechtigungsüberprüfung
  • Penetrationstests

GraphAPI-Berechtigungsüberprüfung

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

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 das Erforderliche überschreiten, wenden sie sich an den ISV, um die geschäftliche Begründung für diese Berechtigungen zu überprüfen. Alle abweichungen zwischen den angeforderten Berechtigungen und der Übermittlung des Herausgebernachweises müssen während dieser Überprüfung behoben und behoben werden.

Penetrationstests

Penetrationstests sind für die Identifizierung und Abmilderung von Risiken im Zusammenhang mit der App oder dem Add-In und ihrer unterstützenden Umgebung von entscheidender Bedeutung. Dadurch wird sichergestellt, dass die App den Kunden angemessene Sicherheitsgarantien bietet.

Penetrationstests sind für jede App obligatorisch , die eine Verbindung mit externen Diensten herstellt, 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 Apps müssen jedoch Penetrationstests durchlaufen, um die Sicherheit der bereichsinternen Umgebung sicherzustellen.

Penetrationstestbereich

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 oder das Add-In unterstützt. Dies umfasst Folgendes:

Die Umgebung, in der der Code der App oder des Add-Ins gehostet wird (in der Regel wird in der Manifestdatei referenziert)

Alle zusätzlichen Umgebungen, die mit der App/dem Add-In interagieren oder 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).

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

Empfehlungen

Webanwendungsdurchdringungstests: Es wird empfohlen, dass Penetrationstests für Web-Apps direkt in der Liveproduktionsumgebung durchgeführt werden. 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 der Tests in der Produktion verwendet wird.

Segmentierungsvalidierung: Wenn Segmentierungstechniken verwendet werden, um umgebungen im Bereich von anderen zu isolieren, muss der Penetrationstestbericht die Wirksamkeit dieser Segmentierungstechniken überprüfen. Dadurch wird sichergestellt, dass durch den Segmentierungsprozess keine Sicherheitsrisiken eingeführt werden.

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, bietet Microsoft im Rahmen des Microsoft 365-Zertifizierungsprozesses einen kostenlosen Penetrationstestdienst an. Dieser Dienst deckt bis zu 12 Tage der manuellen Tests ab, wobei zusätzliche Kosten für alle erforderlichen Tage über die Verantwortung des ISV hinausgehen.

Wichtige Anforderungen

Vortestanforderungen: ISV muss Nachweise vorlegen und eine Genehmigung für 50 % der im Bereich durchgeführten Kontrollen erhalten, bevor der Penetrationstest geplant wird.

Testbericht: Dieser Bericht kann zusammen mit Ihrer Microsoft 365-Zertifizierung verwendet werden, um Kunden zu zeigen, dass Ihre Umgebung sicher ist.

Behebung von Sicherheitsrisiken: ISVs sind für die Behebung von Sicherheitsrisiken verantwortlich, die während der Tests identifiziert wurden, bevor die Zertifizierung erteilt werden kann. Ein sauber Bericht ist jedoch nicht erforderlich, nur der Nachweis, dass die Sicherheitsrisiken angemessen behoben wurden.

Weitere Überlegungen

Sobald ein Penetrationstest eingerichtet wurde, ist der ISV für die Deckung aller Gebühren im Zusammenhang mit Neuplanungen oder Stornierungen 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
Umplanungsanfrage, die innerhalb von 2 bis 7 Tagen vor dem geplanten Startdatum mit einem festen Umbuchungsdatum eingegangen ist. 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 gemäß den von organisationen definierten Patchzeitrahmen gepatcht werden und nicht unterstützte Betriebssysteme und Softwarekomponenten 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.
Es gibt Richtlinien für den Patchzeitrahmen, z. B. "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 die Behebung 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

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

Für Anwendungen, die Microsoft 365-Daten abrufen oder speichern, ist es obligatorisch, ein Verschlüsselungsschema für die Datenspeicherung zu implementieren. Dies muss mit den in Anhang B beschriebenen Spezifikationen übereinstimmen.

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).
Geben Sie den Datenschutzhinweis an, der alle erforderlichen Elemente wie folgt enthalten sollte: Organisationsdetails (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.

Optionale Überprüfung des externen Complianceframeworks

Wenn Ihre organization bereits mit externen Sicherheitsframeworks wie ISO 27001, PCI DSS, FedRAMP oder SOC 2 Typ 2 konform ist, können Sie diese Zertifizierungen nutzen, um einige der Microsoft 365-Zertifizierungskontrollen zu erfüllen. Analysten werden versuchen, Ihre vorhandenen externen Sicherheitsframeworks an den Microsoft 365-Zertifizierungsanforderungen anzupassen.

Wenn Ihre unterstützende Dokumentation jedoch nicht zeigt, dass Die Microsoft 365-Zertifizierungskontrollen explizit als Teil der Überwachung oder Bewertung des externen Frameworks bewertet wurden, müssen Sie zusätzliche Nachweise bereitstellen, um zu überprüfen, ob diese Kontrollen vorhanden sind.

Dokumentationsanforderungen

Die Dokumentation muss eindeutig zeigen, dass die bereichsinterne Umgebung für die Microsoft 365-Zertifizierung im Rahmen der ewigen Sicherheitsframeworks enthalten ist. Die Validierung dieser Frameworks wird erfüllt, indem der Nachweis gültiger Zertifizierungen akzeptiert wird, die von seriösen, akkreditierten 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 Frameworks, die für Ihre Zertifizierung relevant sind.

Die folgende Tabelle enthält die erforderlichen Frameworks und Dokumentationen, die von Zertifizierungsanalysten im Rahmen des Validierungsprozesses akzeptiert wurden.

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

Während externe Sicherheitsstandards oder -frameworks als unterstützende Nachweise eingereicht werden können, um bestimmte Microsoft 365-Zertifizierungskontrollen zu erfüllen, erfordert die Erlangung der Microsoft 365-Zertifizierung eine separate Bewertung. Das Erreichen der Microsoft 365-Zertifizierung bedeutet nicht, dass die App die Überprüfungen 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 für die Verwendung externer Complianceframeworks

Anforderungen für die Verwendung externer Complianceframeworks

Die bereichsinterne Umgebung und alle unterstützenden Geschäftsprozesse müssen in den Geltungsbereich jedes unterstützten externen Sicherheitscompliance-Frameworks einbezogen werden. Diese müssen in den vorgelegten Unterlagen klar dokumentiert sein.

Externe Sicherheitscompliance-Frameworks müssen aktuell sein, was bedeutet, dass sie innerhalb der letzten 12 Monate (oder 15 Monate, wenn eine laufende Neubewertung mit unterstützenden Beweisen überprüft werden kann) bewertet werden sollten.

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

Überprüfungskriterien für externe Frameworks

SOC 2 Typ 2 Bewertung

  • Der SOC 2-Bericht muss ein Typ-2-Bericht 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 Steuerelemente müssen gemäß den Anforderungen eines Typ-2-Berichts fair dargestellt und ordnungsgemäß entworfen werden.
  • 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äß überprüft werden.

ISO 27001-Bewertung

  • Das ISO 27001-Audit muss die in dieser M365-Bewertung angegebene Umgebung enthalten.
  • Das ISO 27001-Zertifikat muss auf dem neuesten Stand sein und für die Entität gelten.
  • 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
  • Der AOC muss das Datum aufweisen.
  • Die AOC muss von der QSA und der Entität abgemeldet werden.

Weitere Informationen