Vue d’ensemble de l’infrastructure de certification Microsoft 365

Cet article fournit des informations détaillées sur la certification Microsoft 365, notamment une liste des contrôles de sécurité requis et des conseils destinés aux éditeurs de logiciels indépendants et aux développeurs.

La certification Microsoft 365 est un audit indépendant de la sécurité et de la confidentialité des applications, des compléments, des agents et de l’environnement backend de prise en charge (collectivement appelés applications) qui s’intègrent à la plateforme Microsoft 365. Les applications qui réussissent seront désignées comme certifiées Microsoft 365 dans l’ensemble de l’écosystème Microsoft 365 et pourront être trouvées facilement dans les places de marché Microsoft 365 via des filtres de recherche axés sur la conformité et une personnalisation. Les éditeurs de logiciels indépendants auront la possibilité de partager les attributs de conformité de leur application sur des pages dédiées au sein de cet ensemble de documentation.

La certification Microsoft 365 est disponible pour les types d’applications suivants :

  • Compléments Microsoft 365 (Word, Excel, Outlook, PowerPoint, OneNote, Project)
  • Applications Teams
  • Solutions SharePoint
  • Applications web (SaaS)
  • Extensions Copilot

Importante

La certification Microsoft 365 est un examen rigoureux de la sécurité et de la conformité d’une application par rapport au cadre de certification Microsoft 365 et nécessite un engagement considérable en temps et en ressources. Avant de commencer, passez en revue les infrastructures de contrôle de conformité pour vérifier que votre application est éligible. Si vous avez des questions, envoyez un e-mail appcert@microsoft.comà .

Termes

En participant au programme de certification Microsoft 365, vous acceptez ces conditions supplémentaires et vous vous conformez à toute documentation d’accompagnement qui s’applique à votre participation au programme de certification Microsoft 365 avec Microsoft Corporation (« Microsoft », « nous », « notre » ou « nos »). Vous nous déclarez et garantissez que vous êtes habilité à accepter les présentes conditions supplémentaires de la Certification Microsoft 365 en votre nom ou au nom d’une entreprise et/ou d’une autre entité, selon le cas. Nous pouvons changer, amender ou résilier ces conditions supplémentaires à tout moment. Votre participation continue au programme de certification Microsoft 365 après tout changement ou amendement signifie que vous acceptez les nouvelles conditions supplémentaires. Si vous n’acceptez pas les nouvelles conditions supplémentaires ou si nous mettons fin à ces conditions supplémentaires, vous devez arrêter de participer au programme de certification Microsoft 365.

Configuration requise

Avant que la certification Microsoft 365 puisse être attribuée, une application doit remplir les étapes suivantes :

Vérification de l’éditeur Lorsqu’une application a un éditeur vérifié, l’organisation qui publie l’application a été vérifiée comme authentique par Microsoft. La vérification d’une application inclut l’utilisation d’un compte Microsoft Cloud Partner Program (CPP) qui a été vérifié et l’association du PartnerID vérifié à une inscription d’application. Obtenir Éditeur vérifié

L’attestation Publisher est un processus en libre-service dans lequel les développeurs d’applications (ISV) répondent à une série de questions sur leurs pratiques de sécurité, telles que le traitement des données sensibles. Une fois l’opération terminée, l’application reçoit une page de documentation qu’elle peut partager avec les clients, qui inclut les réponses fournies.

Examinez les critères de contrôle. Il n’est pas toujours nécessaire de se conformer à tous les contrôles pour obtenir une certification. Cependant, des seuils (qui ne seront pas divulgués) sont en place pour chacun des trois domaines de sécurité abordés dans le présent document d’aperçu et doivent être dépassés. Le non-respect des contrôles critiques étiquetés « échec dur » entraînera l’échec de l’évaluation.

Structure des coûts

ISV travaillera avec le cabinet d’audit pour payer la certification. Pour plus d’informations et pour créer un compte auprès du cabinet d’audit Claranet - cliquez ici.

Type d’audit Éléments inclus Qualifications
Standard Évaluation complète par rapport à tous les contrôles applicables Nécessaire pour les nouvelles évaluations et les recertifications qui ne sont pas admissibles à un audit satellite. Nécessaire si une recertification ne répond pas aux critères de risque définis pour un audit satellite
Audit satellite Lorsque les critères sont remplis, réduction de l’ensemble des contrôles pour les deuxième et troisième années d’évaluation Admissible après avoir obtenu la certification standard la première année. Pour l’année 2 et l’année 3 si aucun changement important n’a eu lieu et réussissent l’évaluation des risques
Prolongation Peut être créé sur demande, inclut l’heure de création de rapports Ajouté uniquement lorsqu’une soumission nécessite plus de temps avec l’auditeur
Taux journalier pentest Pentest défini par mission et conforme aux exigences de certification qui couvre l’ensemble du périmètre convenu de l’évaluation Nécessaire si l’application n’a pas déjà effectué de test d’intrusion tiers fiable au cours des 12 derniers mois
Clone Confirmation d’une soumission clonée, examen de tout contrôle nécessitant des preuves supplémentaires Une application qui partage le même environnement back-end qu’une application qui a récemment terminé la certification

Délai d’envoi

Le processus de soumission pour obtenir la certification comporte deux étapes :

Étape 1 : Présentation initiale du document (délai de 14 jours)

À ce stade, l’éditeur de logiciels indépendant doit soumettre une documentation qui fournit une vue d’ensemble de l’environnement de prise en charge de son application. Il s’agit notamment, mais pas exclusivement, des éléments suivants :

  • Diagramme architectural/flux de données
  • Listes des composants système
  • Inventaires des actifs logiciels

Un analyste examinera cette documentation pour définir la portée de l’évaluation. L’ISV dispose de 14 jours pour terminer et télécharger la documentation requise. Le non-respect de ce délai peut retarder le processus ou entraîner l’échec de la soumission.

Étape 2 : Examen complet des données probantes (délai de 60 jours)

Une fois la portée définie, l’ISV passera à la phase de collecte de preuves. À ce stade :

  1. L’ISV doit télécharger des preuves par rapport à tous les contrôles applicables définis à partir du champ d’application.

  2. Ces preuves feront l’objet d’un examen, de révisions (si nécessaire) et d’un processus final de questions/réponses.

  3. Des tests d’intrusion peuvent également être effectués pendant cette période.

L’ISV dispose de 60 jours pour terminer cette étape, à compter de la première présentation de preuves, qui comprend :

  • Téléchargement de preuves pour tous les contrôles
  • Examen et commentaires des analystes
  • Toute révision nécessaire des preuves soumises
  • Achèvement du processus de questions/réponses

Non-respect de l’échéance

Si l’ISV ne peut pas terminer le processus dans le délai de 60 jours, l’évaluation échouera. Toutefois, à la discrétion de l’analyste, une prolongation maximale de 60 jours supplémentaires peut être accordée dans des circonstances valides, telles que :

  • Vacances saisonnières
  • Retards dans les tests d’intrusion
  • Changements internes
  • Temps nécessaire pour mettre en œuvre les changements nécessaires afin de répondre aux exigences de contrôle

Aucune autre prolongation ne peut être accordée, une fois que les deux délais de 60 jours ont été épuisés.

Étendue de la certification

L’environnement dans l’étendue englobe tous les systèmes et infrastructures nécessaires pour fournir le code de l’application, du complément ou de l’agent, ainsi que tous les systèmes principaux de prise en charge avec lesquels l’application/le complément/l’agent peut communiquer. Tout environnement supplémentaire connecté à l’environnement dans l’étendue doit également être inclus dans l’étendue, sauf si une segmentation adéquate est mise en œuvre et que les environnements connectés ne peuvent pas compromettre la sécurité de l’environnement dans l’étendue.

Remarque : Tout environnement distinct de reprise après sinistre doit également être inclus dans l’environnement dans le champ d’application, car ces environnements peuvent être essentiels au maintien de la continuité des services en cas de défaillance de l’environnement principal.

En outre, les environnements de sauvegarde à distance doivent également être incorporés dans l’étendue, car ils peuvent stocker des données Microsoft sensibles. Par conséquent, des contrôles de sécurité adéquats doivent être mis en œuvre pour ces environnements.

Le terme « composants système dans l’étendue » inclut tous les appareils et systèmes activement utilisés dans l’environnement dans l’étendue défini. Ces composants comprennent, sans s’y limiter :

  • Applications Web
  • Serveurs (physiques ou virtuels, locaux ou dans le cloud)
  • Commutateurs
  • Équilibreurs de charge
  • Infrastructure virtuelle
  • Portails de gestion web des fournisseurs de cloud
  • Ressources cloud (Machines virtuelles, App Services, comptes de stockage, bases de données, etc.)

Importante

Les composants système destinés au public sont particulièrement vulnérables aux attaques par des acteurs de menace externes et présentent donc un risque plus élevé. En règle générale, ces systèmes doivent être isolés des composants internes du système par la mise en œuvre de contrôles de sécurité réseau (NSC), tels qu’une zone démilitarisée (DMZ). L’objectif d’une zone démilitarisée est d’agir comme une zone tampon, limitant la confiance accordée aux systèmes externes et renforçant la sécurité pour protéger les systèmes et les données internes. Bien qu’une zone démilitarisée puisse encore être idéale dans certains cas, les architectures cloud modernes s’appuient souvent sur des mesures de sécurité alternatives adaptées à des scénarios de déploiement spécifiques.

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

Lorsque l’IaaS et/ou le PaaS sont utilisés pour prendre en charge l’environnement concerné à l’étude, le fournisseur de la plateforme Cloud sera responsable de certains des contrôles de sécurité évalués tout au long du processus de certification. Les analystes devront bénéficier d’une vérification externe indépendante des meilleures pratiques de sécurité par le fournisseur de la plate-forme Cloud par le biais de rapports de conformité externes tels que PCI-DSS, Attestation de conformité (AOC), ISO 27001 ou SOC 2 Type II.

Pour plus d’informations sur les contrôles de sécurité susceptibles de s’appliquer au type de déploiement et si l’environnement traite ou transfère les données Microsoft 365, consultez l’Annexe C. Les types de déploiement comprennent :

  • Hébergé par un éditeur de logiciels indépendant : Application hébergée par des éditeurs de logiciels indépendants.
  • Hébergement IaaS : infrastructure fournie par des plateformes cloud tierces.
  • PaaS/Serverless Hosted : Applications faisant la moyenne de l’architecture basée sur une plate-forme ou sans serveur.
  • Hébergement hybride : mélange de composants sur site et hébergés dans le cloud.
  • Mutualisé : environnements cloud partagés utilisés par plusieurs locataires.

Dans les cas où IaaS ou PaaS est utilisé, les preuves doivent valider que le déploiement s’aligne sur les contrôles de sécurité attendus pour l’architecture concernée.

Échantillonnage

Pour garantir une évaluation approfondie, l’échantillonnage des composants système concernés doit prendre en compte des facteurs tels que les systèmes d’exploitation, la fonction principale du périphérique, le type de périphérique (par exemple, serveurs, routeurs, contrôles de sécurité réseau) et l’emplacement géographique. Les échantillons sont sélectionnés au début du processus de certification en fonction de ces considérations. Le tableau ci-dessous guide la taille de l’échantillonnage en fonction de la population des composantes dans l’étendue :

Taille de la population Échantillon
<=5 1
>5 & <10= 2
>10 & <=30 3
>30 4

Cela garantit une évaluation représentative de la conformité de l’environnement dans diverses configurations et modèles de déploiement.

Remarque

Si des écarts sont identifiés entre les appareils au cours de l’évaluation, la taille de l’échantillon peut être ajustée pour assurer une présentation adéquate de l’environnement.

Vue d’ensemble du processus de certification

Pour commencer le processus de certification Microsoft 365 :

  1. Attestation de l’éditeur Accédez à l’Espace partenaires et remplissez le formulaire d’attestation de l’éditeur. Remarque : Si votre soumission date de plus de trois mois, vous devez la soumettre à nouveau pour examen et validation.

  2. Démarrer la certification Une fois dans l’Espace partenaires, sélectionnez l’option « Démarrer la certification » pour commencer l’envoi initial de votre document. Cette étape permet aux analystes de certification d’identifier l’étendue de l’évaluation en fonction de l’architecture de votre application et de la façon dont elle gère les données Microsoft. À ce stade, vous devrez créer un compte auprès de Claranet Limited.

La certification se déroule en deux grandes étapes :

  1. Envoi initial du document À ce stade, vous fournissez des détails clés pour aider les analystes à comprendre la conception de votre application, le flux de données et l’environnement dans l’étendue. Les analystes détermineront les contrôles de sécurité applicables et décriront les composants du système nécessitant des preuves. Vous devez fournir une documentation précise pour faciliter cet examen, ce qui représente environ 5 % du processus global.

  2. Examen complet des preuves À cette étape, vous soumettez des preuves détaillées démontrant la conformité aux contrôles de sécurité pour l’environnement concerné. Les analystes travailleront en étroite collaboration avec vous pendant cette phase pour examiner, clarifier et vérifier vos soumissions. Cette phase prend le reste du processus.

Évaluation

Une fois la soumission initiale du document approuvée, une liste des contrôles de sécurité requis apparaîtra dans le portail. Vous avez 60 jours pour fournir des preuves pour chaque contrôle, confirmant qu’il est en place et opérationnel. Les analystes examineront vos preuves et les approuveront ou demanderont des détails ou des révisions supplémentaires.

Certification

Une fois votre soumission examinée et validée par un analyste, vous recevrez un avis concernant la décision de certification. Les applications qui répondent aux critères de certification recevront un badge, qui s’affichera sur leur liste AppSource et sur les pages Microsoft Docs associées. Ces pages fourniront également des rapports détaillés sur les attributs de sécurité et de conformité de l’application.

Révision et renouvellement de la certification

Les applications certifiées Microsoft 365 doivent faire l’objet d’une recertification annuelle pour garantir une conformité continue aux normes de Microsoft. Le processus de recertification consiste à réévaluer les contrôles dans le champ d’application pour confirmer qu’ils correspondent à l’environnement actuel. Vous pouvez commencer le processus de recertification jusqu’à 90 jours avant l’expiration de la certification pour éviter toute interruption. Les certifications resteront valables pendant cette période.

Si la recertification n’est pas terminée avant la date d’expiration, la certification sera révoquée. Par conséquent :

  • Le badge de certification et la personnalisation de l’application seront supprimés.

  • Les éditeurs de logiciels indépendants ne seront plus autorisés à commercialiser l’application en tant que Microsoft 365 certifiée.

En cas de modifications importantes apportées à l’application en dehors de la période de recertification prévue, les éditeurs de logiciels indépendants doivent informer le programme de conformité des applications Microsoft pour s’assurer que l’application reste conforme.

Envoi initial du document

Votre soumission initiale doit inclure les informations suivantes :

Présentation de la documentation Détails de la documentation
Description de l’application/complément/agent Description de l’objectif et des fonctionnalités de l’application/complément/agent. Cela doit permettre à l’analyste de certification de bien comprendre le fonctionnement de l’application/du complément/de l’agent et son utilisation prévue.
Rapport de test d’intrusion Un rapport de test d’intrusion réalisé au cours des 12 derniers mois. Ce rapport doit inclure l’environnement qui prend en charge le déploiement de l’application/du complément/de l’agent, ainsi que tout environnement supplémentaire qui prend en charge le fonctionnement de l’application/du complément/de l’agent. Remarque : Si l’ISV n’effectue pas actuellement de tests d’intrusion annuels, l’équipe d’audit peut en effectuer un à un coût supplémentaire.
Diagrammes d’architecture Diagramme d’architecture logique représentant une vue d’ensemble générale de l’infrastructure de prise en charge de l’application. Cela doit inclure tous les environnements d’hébergement et l’infrastructure de soutien prenant en charge l’application. Ce diagramme DOIT représenter tous les différents composants du système de soutien dans l’environnement pour aider les analystes de certification à comprendre les systèmes dans le champ d’application et à déterminer l’échantillonnage. Veuillez également indiquer quel type d’environnement d’hébergement est utilisé ; Hébergement ISV, IaaS, PaaS ou hybride. Remarque : Lorsque le SaaS est utilisé, veuillez indiquer les différents services SaaS utilisés pour fournir des services de soutien au sein de l’environnement.
Empreinte publique Détaillant toutes les adresses IP et URL publiques utilisées par l’infrastructure de prise en charge. Cela doit inclure la gamme complète d’adresses IP routables allouées à l’environnement, à moins qu’une segmentation adéquate n’ait été mise en œuvre pour diviser la gamme d’utilisation (une preuve adéquate de segmentation sera requise).
Diagrammes de flux de données Diagrammes de flux détaillant les éléments suivants :
✓ Flux de données Microsoft 365 vers et depuis l’application/le complément/l’agent (y compris EUII et OII.)
✓ Flux de données Microsoft 365 au sein de l’infrastructure de support (le cas échéant).
✓ Diagrammes mettant en évidence où et quelles données sont stockées, comment les données sont transmises à des tiers externes (y compris des détails sur quels tiers) et comment les données sont protégées en transit sur des réseaux ouverts/publics et au repos.
Détails du point de terminaison d’API Une liste complète de tous les points de terminaison d’API utilisés par votre application. Pour mieux comprendre l’étendue de l’environnement, fournissez des emplacements de point de terminaison d’API dans votre environnement.
Autorisations de l’API Microsoft Fournir une documentation détaillant TOUTES les API Microsoft utilisées, ainsi que les autorisations demandées pour que l’application/le complément/l’agent fonctionne, ainsi qu’une justification des autorisations demandées
Types de stockage de données Stockage et traitement des données Documents décrivant :
✓ Dans quelle mesure les données Microsoft 365 EUII et OII sont-elles reçues et stockées ?
✓ La durée de conservation des données.
✓ Pourquoi les données Microsoft 365 sont-elles capturées.
✓ Emplacement de stockage des données Microsoft 365 (doit également être inclus dans les diagrammes de flux de données fournis ci-dessus).
Confirmation de conformité Documentation de prise en charge des infrastructures de sécurité externes incluses dans la soumission de l’attestation de l’éditeur ou à prendre en compte lors de l’examen des contrôles de sécurité de la certification Microsoft 365. Actuellement, les quatre éléments suivants sont pris en charge :
✓ Attestation de conformité PCI DSS (AOC).
✓ Rapports SOC 2 Type I/Type II.
✓ ISMS / IEC - 1S0/IEC 27001 Déclaration d’applicabilité (SOA) et certification.
✓ Package d’autorisation FedRAMP FedRAMP et rapport d’évaluation de la préparation FedRAMP.
Dépendances web Documentation répertoriant toutes les dépendances utilisées par l’application avec les versions en cours d’exécution.
Inventaire des logiciels Un inventaire des logiciels à jour qui inclut tous les logiciels utilisés dans l’environnement dans l’étendue ainsi que les versions.
Inventaire du matériel Inventaire matériel à jour utilisé par l’infrastructure de prise en charge. Cela sera utilisé pour faciliter l’échantillonnage lors de la phase d’évaluation. Si votre environnement inclut le PaaS, fournissez des détails sur les services/ressources cloud consommés.

Activités de collecte et d’évaluation de données probantes

Les analystes de certification devront examiner les preuves de tous les composants du système dans l’ensemble d’échantillons défini. Les types de preuves requises pour appuyer le processus d’évaluation comprennent l’un ou l’ensemble des éléments suivants :

Collecte de preuves

  • Documentation initiale, mise en évidence dans le guide de soumission de la documentation initiale
  • Documents de stratégie
  • Traiter les documents
  • Paramètres de configuration du système
  • Changer des tickets
  • Enregistrements de contrôle des modifications
  • Rapports système
  • Compte-rendu de réunion
  • Contrats/accords

Diverses méthodes seront utilisées pour recueillir les preuves nécessaires à la réalisation du processus d’évaluation. Cette collecte de preuves peut prendre la forme de :

  • Documents
  • Captures d’écran
  • Entrevues
  • Partage d’écran

Les techniques de collecte de preuves utilisées seront déterminées au cours du processus d’évaluation. Pour obtenir des exemples précis du type de preuve requis dans votre soumission, consultez le Guide des exemples de preuves.

Partage des preuves

Au cours du processus de certification, les éditeurs de logiciels indépendants peuvent choisir de partager leurs preuves de conformité directement avec des clients potentiels. La case à cocher située dans la boîte de dialogue de téléchargement de fichier, qui est cochée par défaut, accorde aux administrateurs Microsoft 365 l’accès à la preuve de certification de l’application dans le Centre d’administration Teams et le Centre d’administration Microsoft 365. (Les administrateurs Microsoft 365 sont responsables de la configuration, de la gestion et de la sécurisation des services et des ressources Microsoft 365 au sein d’une organisation.) Cette transparence vise à simplifier la diligence raisonnable pour les organisations qui évaluent de nouvelles demandes afin d’accélérer la prise de décision. Si un ISV préfère ne pas rendre ces preuves publiques, il peut simplement décocher la case au moment de la soumission, conservant ainsi un contrôle total sur la manière et le moment où ses documents de conformité sont divulgués.

Activités d’évaluation

Les analystes de certification examineront les preuves soumises pour vérifier que tous les contrôles requis pour la certification Microsoft 365 sont satisfaits. Pour accélérer le processus, assurez-vous que tous les documents spécifiés dans la soumission initiale de la documentation sont complets et fournis à l’avance.

Au cours de l’examen, les analystes évalueront les preuves de la soumission initiale et de l’attestation de l’éditeur. Ils détermineront la portée de l’enquête, l’échantillonnage et la nécessité de preuves supplémentaires. Les analystes utiliseront toutes les informations collectées pour évaluer la conformité à la spécification de certification Microsoft 365 et décider si votre application répond aux contrôles définis.

Critères de certification des applications

L’application et son infrastructure de prise en charge, ainsi que la documentation de prise en charge, seront évaluées dans les trois domaines de sécurité suivants :

  1. Sécurité de l’application
  2. Sécurité opérationnelle
  3. Gestion des données, sécurité et confidentialité

Chacun de ces domaines de sécurité comprend des contrôles clés spécifiques englobant une ou plusieurs exigences qui seront évaluées dans le cadre du processus d’évaluation. Pour garantir que la certification Microsoft 365 inclut les développeurs de toutes tailles, chacun des domaines de sécurité est évalué à l’aide d’un système de notation pour déterminer un score global pour chacun des domaines. Les scores pour chacun des contrôles de certification Microsoft 365 sont attribués entre 1 (faible) et 3 (élevé) en fonction du risque perçu de non-implémentation de ce contrôle. Chacun des domaines de sécurité aura une note de pourcentage minimale pour être considéré comme une réussite. Certains facteurs entraînent des défaillances automatiques, notamment :

  • Utilisation d’autorisations d’API qui n’adhèrent pas au principe de moindre privilège (PoLP)

  • Absence de rapports de tests d’intrusion lorsque requis.

  • Absence de défenses anti-programme malveillant.

  • Échec de l’implémentation de l’authentification multifacteur (MFA) pour l’accès administratif.

  • Processus de correction manquants ou insuffisants.

  • Absence de déclaration de confidentialité RGPD conforme.

Sécurité de l’application

Le domaine de sécurité des applications évalue les domaines suivants :

  • Tests d’intrusion
  • Validation des autorisations de l’API Graph
  • IA responsable

Test d’intrusion

Les tests d’intrusion sont essentiels pour identifier et atténuer les risques associés à l’application ou au complément et à son environnement de prise en charge. Cela garantit que l’application fournit des garanties de sécurité adéquates aux clients.

Les tests d’intrusion sont obligatoires pour toute application qui se connecte à des services externes qui ne sont pas hébergés ou gérés par Microsoft. Si l’application est déployée en tant que solution autonome qui utilise uniquement des services Microsoft tels que GraphAPI, les tests d’intrusion peuvent ne pas être nécessaires. Toutefois, les applications hébergées dans Azure doivent subir des tests d’intrusion pour garantir la sécurité de l’environnement dans l’étendue.

Étendue des tests d’intrusion

Test d’infrastructure : pour les infrastructures internes et externes, les tests d’intrusion doivent être effectués dans l’environnement de production en direct qui prend en charge l’application, le complément ou l’agent. Cela inclut les opérations suivantes :

Environnement dans lequel l’application, le complément ou le code de l’agent est hébergé (généralement référencé dans le fichier manifeste).

Tout environnement supplémentaire qui interagit avec ou prend en charge le fonctionnement de l’application/du complément/de l’agent (par exemple, si l’application/le complément/l’agent communique avec d’autres applications web en dehors de Microsoft 365).

Lors de la définition de la portée des tests d’intrusion, il est essentiel d’inclure tous les systèmes ou environnements connectés susceptibles d’avoir un impact sur la sécurité de l’environnement concerné.

Recommandations

Test de pénétration des applications Web : Il est recommandé que les tests de pénétration des applications Web soient effectués directement sur l’environnement de production en direct. Toutefois, les tests d’applications web peuvent être effectués dans un environnement de test/UAT (User Acceptance Testing), à condition que le rapport de test d’intrusion confirme que la même base de code est utilisée en production au moment du test.

Validation de la segmentation : Si des techniques de segmentation sont utilisées pour isoler les environnements dans le champ d’application des autres, le rapport de test d’intrusion doit valider l’efficacité de ces techniques de segmentation. Cela garantit qu’aucune vulnérabilité n’est introduite par le processus de segmentation.

Exigences en matière de tests d’intrusion

Les rapports de tests d’intrusion seront examinés pour s’assurer qu’aucune vulnérabilité ne répond aux critères d’échec automatique suivants, décrits dans les contrôles ci-dessous.

Type de critère Contrôles des tests d’intrusion
Critères généraux Les tests d’intrusion de l’application Web (authentifiés et non authentifiés) et de l’infrastructure interne (le cas échéant) et externes DOIVENT avoir lieu chaque année (tous les 12 mois) et être effectués par une société indépendante réputée.
La correction des vulnérabilités critiques et à haut risque identifiées DOIT être achevée dans un délai d’un mois à compter de la fin des tests d’intrusion, ou plus tôt selon le processus de mise à jour corrective documenté de l’ISV.
L’empreinte externe complète (adresses IP, URL, points de terminaison d’API, etc.) DOIT être inclus dans le champ d’application des tests d’intrusion et doit être clairement documenté dans le rapport d’essai d’intrusion.
À moins que l’environnement ne s’aligne sur le PaaS, l’ensemble des réseaux internes DOIT être inclus dans le champ d’application des tests d’intrusion et doit être clairement documenté dans le rapport de test d’intrusion.
Les tests d’intrusion des applications Web DOIVENT inclure toutes les classes de vulnérabilité ; par exemple, le Top 10 OWASP le plus récent ou le Top 25 CWE SANS. La recommandation est que cela soit détaillé dans le rapport d’essais d’intrusion, sinon il sera difficile de le démontrer.
Les vulnérabilités critiques et à haut risque ou les vulnérabilités considérées comme une défaillance automatique DOIVENT être testées à nouveau par la société de tests d’intrusion et clairement mises en évidence comme corrigées dans le rapport de test d’intrusion.
Critères de défaillance automatique : Présence d’un système d’exploitation ou d’une bibliothèque JavaScript non pris en charge.
Présence de comptes administratifs par défaut, énumérables ou devinables.
Présence de risques d’injection SQL.
Présence de scripts intersites.
Présence de vulnérabilités de traversée de répertoire (chemin d’accès au fichier).
Présence de vulnérabilités HTTP, par exemple le fractionnement des réponses d’en-tête, la contrebande de requêtes et les attaques de désynchronisation.
Présence de divulgation du code source (y compris LFI).
Tout score critique ou élevé tel que défini par les directives de gestion des correctifs CVSS.
Toute vulnérabilité technique importante qui peut être facilement exploitée pour compromettre une grande quantité d’EUII ou d’OUI.

Importante

Les rapports doivent être en mesure de fournir suffisamment d’assurance pour que tout ce qui est détaillé dans la section sur les exigences des tests d’intrusion ci-dessus puisse être démontré.

Validation des autorisations de l’API Graph

Cela garantit que l’application, le complément ou l’agent ne demande pas d’autorisations excessives ou trop permissives. Les analystes de certification examinent manuellement les autorisations demandées par l’application et les case activée croisées par rapport à la soumission d’attestation Publisher.

L’objectif est de confirmer que les autorisations demandées respectent le principe de moindre privilège. Si les analystes constatent que l’application demande des autorisations qui dépassent ce qui est nécessaire, ils s’engagent avec l’éditeur de logiciels indépendant pour valider la justification commerciale de ces autorisations. Toute divergence identifiée entre les autorisations demandées et la soumission d’attestation de l’éditeur doit être traitée et résolue au cours de cette révision.

IA responsable

Les informations soumises en réponse aux contrôles d’IA responsable seront examinées en même temps que le fichier manifeste de l’application fourni par l’éditeur de logiciels indépendant. Cela permet à l’analyste de vérifier la case activée l’intégration de Microsoft Copilot avec l’application en cours de certification, ce qui permet de bien comprendre comment les deux interagissent et quelles actions sont entreprises pour le compte du client. Nous reconnaissons qu’il est essentiel que l’IA soit utilisée de manière responsable et lorsque le client est pleinement informé. À condition que les informations partagées s’alignent sur les fonctionnalités d’application attendues et sur le Standard d’IA responsable de Microsoft ou le centre de ressources d’intelligence artificielle responsable & fiable du NIST, ces contrôles seront considérés comme approuvés (sous réserve des vérifications habituelles des questions/réponses).

L’objectif est de poursuivre la collaboration avec Microsoft pour fournir certains détails de cette case activée sur les pages publiques pertinentes, afin de permettre aux clients de prendre des décisions en toute connaissance de cause sur l’utilisation de leurs données en ce qui concerne Copilot et l’application associée.

Sécurité opérationnelle

Ce domaine mesure l’alignement de l’infrastructure de prise en charge et des processus de déploiement d’une application sur les meilleures pratiques de sécurité.

Contrôles

Famille de contrôle Controls
Formation de sensibilisation Fournir la preuve que l’organisation offre une formation de sensibilisation à la sécurité établie aux utilisateurs des systèmes d’information (y compris les gestionnaires, les cadres supérieurs et les entrepreneurs) dans le cadre de la formation initiale des nouveaux utilisateurs ou lorsque des changements au système d’information l’exigent.
Fournir la preuve d’une fréquence de formation de sensibilisation définie par l’organisation.
Fournir la preuve de la documentation et de la surveillance des activités individuelles de sensibilisation à la sécurité des systèmes d’information tout en conservant les dossiers de formation individuels sur une fréquence définie par l’organisation.
Protection contre les programmes malveillants - antivirus Fournissez la preuve que votre solution anti-programme malveillant est active et activée sur tous les composants système échantillonnés et configurée pour répondre aux critères suivants :
S’il s’agit d’un antivirus, l’analyse à l’accès est activée et les signatures sont à jour dans un délai d’un jour, et il bloque automatiquement les programmes malveillants ou les alertes et met en quarantaine lorsque des programmes malveillants sont détectés.
OU si EDR/NGAV (Endpoint Detection and Response/Next-Generation Antivirus), une analyse périodique est effectuée, des journaux d’audit sont générés, et il est tenu à jour en permanence et dispose de capacités d’auto-apprentissage.
Si EDR/NGAV, il bloque les programmes malveillants connus et identifie et bloque les nouvelles variantes de programmes malveillants en fonction des comportements des macros et des fonctionnalités complètes de liste fiable.
Protection contre les programmes malveillants - Contrôles d’application Fournir des preuves démontrables qu’une liste approuvée de logiciels/applications avec une justification opérationnelle existe et est à jour.
Que chaque application subisse un processus d’approbation et soit approuvée avant son déploiement.
Cette technologie de contrôle des applications est active, activée et configurée sur tous les composants du système échantillonnés, comme documenté.
Gestion des correctifs : mise à jour corrective et classement des risques Fournissez une documentation de stratégie qui régit la manière dont les nouvelles vulnérabilités de sécurité sont identifiées et auxquelles un score de risque est attribué.
Fournir des preuves de la façon dont les nouvelles vulnérabilités de sécurité sont identifiées.
Fournir des preuves démontrant que toutes les vulnérabilités se voient attribuer un classement de risque une fois identifiées.
Fournir la preuve que tous les composants système échantillonnés sont corrigés conformément aux délais de correction définis par l’organisation et que les systèmes d’exploitation et les composants logiciels non pris en charge ne sont pas utilisés. Le cas échéant, cela devrait inclure la base de code si la technologie serverless ou le PaaS est utilisé, ou à la fois l’infrastructure et la base de code si l’IaaS est utilisé.
Directives de mise à jour corrective en place, par exemple « critique – dans les 14 jours, élevé – dans les 30 jours, moyen – dans les 60 jours ».
Analyse des vulnérabilités Fournir les rapports trimestriels d’analyse de la vulnérabilité de l’infrastructure et des applications web. L’analyse doit être effectuée sur l’ensemble de l’empreinte publique (adresses IP et URL) et des plages d’adresses IP internes.
Fournissez des preuves démontrables que la correction des vulnérabilités identifiées lors de l’analyse des vulnérabilités est corrigée conformément au calendrier de mise à jour corrective documenté.
Contrôles de sécurité réseau (NSC) Fournir la preuve que les contrôles de sécurité réseau (NSC) sont installés à la limite de l’environnement dans l’étendue et installés entre le réseau de périmètre et les réseaux internes.
ET s’il est hybride, sur site, IaaS fournit également la preuve que tout accès public se termine au réseau de périmètre.
Vérifiez que tous les contrôles de sécurité réseau (NSC) sont configurés pour abandonner le trafic non explicitement défini dans la base de règles et que les examens des règles des contrôles de sécurité réseau (NSC) sont effectués au moins tous les 6 mois.
Contrôle des modifications Fournir la preuve que tout changement introduit dans les environnements de production est mis en œuvre par le biais de demandes de changement documentées qui contiennent l’impact du changement, les détails des procédures de retrait, les tests à effectuer, l’examen et l’approbation par le personnel autorisé.
Fournissez la preuve qu’il existe des environnements distincts afin que : les environnements de développement et de test/staging appliquent la séparation des tâches de l’environnement de production, la séparation des tâches est appliquée via des contrôles d’accès, les données de production sensibles ne sont pas utilisées dans les environnements de développement ou de test/intermédiaire.
Développement/déploiement de logiciels sécurisés Fournir des politiques et des procédures qui prennent en charge le développement de logiciels sécurisés et inclure des normes de l’industrie et/ou des meilleures pratiques pour le codage sécurisé. tels que Open Web Application Security Project (OWASP) Top 10 ou SysAdmin, Audit, Network and Security (SANS) Top 25 Common Weakness Enumeration (CWE).
Fournir la preuve que les dépôts de code sont sécurisés de manière à ce que : toutes les modifications de code soient soumises à un processus d’examen et d’approbation par un deuxième réviseur avant d’être fusionnées avec la direction principale, les contrôles d’accès appropriés sont en place, tous les accès sont appliqués par le biais de l’authentification multifacteur (MFA)
Fournir la preuve que toutes les versions intégrées dans l’environnement de production sont examinées et approuvées avant leur déploiement.
Gestion des comptes Fournissez la preuve que les informations d’identification par défaut sont désactivées, supprimées ou modifiées dans les composants système échantillonnés.
Fournir la preuve qu’un processus est en place pour sécuriser (renforcer) les comptes de service et que ce processus a été suivi.
Fournir la preuve que : des comptes d’utilisateur uniques sont émis pour tous les utilisateurs, les principes de moindre privilège des utilisateurs sont suivis dans l’environnement, une politique forte de mot de passe/phrase de passe ou d’autres mesures d’atténuation appropriées sont en place, un processus est en place et suivi au moins tous les trois mois pour désactiver ou supprimer les comptes non utilisés dans les trois mois.
Vérifiez que l’authentification multifacteur est configurée pour toutes les connexions d’accès à distance et toutes les interfaces d’administration autres que la console, y compris l’accès aux référentiels de code et aux interfaces de gestion cloud.
Journalisation, examen et alertes des événements de sécurité Fournir la preuve qu’un minimum de 30 jours de données de journalisation des événements de sécurité est immédiatement disponible, avec 90 jours de journaux des événements de sécurité conservés.
Fournir la preuve que les journaux sont examinés régulièrement et que tout événement/anomalie de sécurité potentiel identifié au cours du processus d’examen est examiné et traité
Fournir la preuve que les règles d’alerte sont configurées de sorte que les alertes soient déclenchées pour investigation pour les événements de sécurité suivants, le cas échéant : création/modification de compte privilégié, activités ou opérations à privilèges/haut risque, événements de programmes malveillants, altération du journal des événements, événements IDPS/WAF. (si configuré)
Gestion des risques liés aux informations Fournir la preuve qu’une politique ou un processus officiel de gestion des risques liés à la sécurité de l’information est documenté et établi.
Fournir la preuve qu’une évaluation formelle des risques de sécurité des informations à l’échelle de l’entreprise est effectuée au moins une fois par an.
OU pour l’analyse ciblée des risques : une analyse ciblée des risques est documentée et effectuée au moins tous les 12 mois pour chaque instance où un contrôle traditionnel ou une pratique exemplaire de l’industrie n’est pas en place, lorsqu’une limitation de conception ou technologique crée un risque d’introduction d’une vulnérabilité dans l’environnement ou met en danger les utilisateurs et les données, en cas de soupçon ou de confirmation de compromis.
Valider que l’évaluation des risques liés à la sécurité de l’information comprend les composants ou ressources du système touchés, les menaces et les vulnérabilités ou équivalent, les matrices d’impact et de probabilité ou l’équivalent, la création d’un registre des risques/plan de traitement des risques.
Fournissez la preuve que vous avez mis en place un processus de gestion des risques qui évalue et gère les risques associés aux fournisseurs et aux partenaires commerciaux et que vous pouvez identifier et évaluer les changements et les risques qui pourraient avoir une incidence sur votre système de contrôles internes.
Réponse aux incidents de sécurité Fournissez votre plan/procédure de réponse aux incidents de sécurité (IRP) ratifié.
Fournir des preuves décrivant comment votre organisation répond aux incidents, montrant comment elle est maintenue, et qu’elles incluent des détails sur l’équipe de réponse aux incidents, y compris les coordonnées, un plan de communication interne pendant l’incident et une communication externe avec les parties concernées telles que les principales parties prenantes, les marques de paiement et les acquéreurs, les organismes de réglementation (par exemple 72 heures pour le RGPD), les autorités de surveillance, directeurs, clients ainsi que les étapes pour les activités telles que la classification des incidents, le confinement, l’atténuation, la récupération et le retour aux opérations commerciales normales selon le type d’incident
Fournir la preuve que tous les membres de l’équipe d’intervention en cas d’incident ont reçu une formation annuelle qui leur permet d’intervenir en cas d’incident.
Fournir la preuve que la stratégie d’intervention en cas d’incident et les documents à l’appui sont examinés et mis à jour en fonction des leçons tirées d’un exercice de simulation, des leçons tirées de l’intervention en cas d’incident ou des changements organisationnels.
Plan de continuité d’activité et plan de reprise d’activité Fournir la preuve qu’il existe et tient à jour la documentation qui décrit le plan de continuité des activités.
Fournir la preuve que le plan de continuité des activités détaille le personnel concerné ainsi que ses rôles et responsabilités, y compris : les fonctions opérationnelles avec les exigences et les objectifs d’urgence associés, les procédures de sauvegarde des systèmes et des données, la configuration et la planification/conservation, les priorités de récupération et les objectifs de calendrier, un plan d’urgence détaillant les actions, les étapes et les procédures à suivre pour remettre en service les systèmes d’information, les fonctions commerciales et les services critiques en cas de interruption imprévue et imprévue, un processus établi qui couvre la restauration complète du système et le retour à l’état d’origine.
Fournir la preuve que la documentation existe, est tenue à jour et décrit le plan de reprise après sinistre et comprend au minimum : le personnel et ses rôles, responsabilités et processus d’escalade, l’inventaire des systèmes d’information utilisés pour soutenir les fonctions et services opérationnels essentiels, les procédures et la configuration de sauvegarde des systèmes et des données, un plan de récupération détaillant les actions et les procédures à suivre pour restaurer les systèmes d’information et les données critiques en fonctionnement.
Fournir la preuve que le plan de continuité des activités et le plan de reprise après sinistre sont révisés au moins tous les 12 mois pour s’assurer qu’ils demeurent valides et efficaces dans des situations défavorables.
Fournir la preuve que le plan de continuité des activités est mis à jour en fonction de l’examen annuel du plan, que tout le personnel concerné reçoit une formation sur les rôles et responsabilités qui leur sont attribués dans les plans d’urgence, que les plans sont mis à l’essai dans le cadre d’exercices de continuité des activités ou de reprise après sinistre, que les résultats des tests sont documentés, y compris les leçons tirées de l’exercice ou les changements organisationnels.

Sécurité et confidentialité du traitement des données

Pour assurer la sécurité des données, toutes les données en transit entre l’utilisateur de l’application, les services intermédiaires et les systèmes ISV doivent être chiffrées à l’aide d’une connexion TLS (Transport Layer Security). Au minimum, TLS 1.2 est requis, avec TLS 1.3 ou supérieur fortement recommandé. Pour plus de détails, voir l’annexe A.

Pour les applications qui récupèrent ou stockent des données Microsoft 365, il est obligatoire d’implémenter un schéma de chiffrement du stockage des données. Cela doit être conforme aux spécifications décrites à l’annexe B.

Contrôles

Famille de contrôle Controls
Données en transit Fournir la preuve que la configuration TLS est TLS1.2 ou ultérieure dans les exigences de configuration du profil TLS et qu’un inventaire des clés et certificats de confiance est conservé et mis à jour.
Fournir des preuves montrent que la compression TLS est désactivée pour tous les services publics traitant des requêtes web afin d’éviter la fuite d’informations sur le taux de compression simplifiée (CRIME) et que TLS HSTS est activé et configuré sur 180 jours sur tous les sites.
Données au repos Fournir la preuve que les données au repos sont chiffrées conformément aux exigences du profil de chiffrement, à l’aide d’algorithmes de chiffrement tels que Advanced Encryption Standard (AES), RSA et Twofish avec des tailles de clé de chiffrement de 256 bits ou plus.
Conservation des données, sauvegarde et destruction Fournir la preuve qu’une période de conservation des données approuvée est formellement établie et documentée.
Fournir la preuve que les données ne sont conservées que pendant la période de conservation définie, comme indiqué dans le contrôle précédent.
Fournissez la preuve que des processus sont en place pour supprimer de manière sécurisée les données après leur période de conservation.
Fournir la preuve qu’un système de sauvegarde automatisé est en place et configuré pour effectuer des sauvegardes à des moments planifiés.
Fournir des preuves Les informations de sauvegarde sont testées conformément à la procédure de planification des sauvegardes et restaurées périodiquement pour confirmer la fiabilité et l’intégrité des données.
Fournir des preuves que des contrôles d’accès et des mécanismes de protection appropriés (c.-à-d. des sauvegardes immuables) sont mis en œuvre pour garantir que les sauvegardes et les instantanés du système sont protégés contre les accès non autorisés et pour assurer la confidentialité, l’intégrité et la disponibilité des données de sauvegarde.
Gestion de l’accès aux données Fournir la preuve qu’une liste des utilisateurs ayant accès aux données et/ou aux clés de chiffrement est conservée. Y compris la justification opérationnelle de chaque personne et la confirmation, cette liste d’utilisateurs a été officiellement approuvée en fonction des privilèges d’accès requis pour leur fonction, et les utilisateurs sont configurés avec les privilèges décrits dans l’approbation.
Fournir la preuve qu’une liste de tous les tiers avec lesquels les données sont partagées est conservée et que des accords de partage de données sont en place avec tous les tiers consommant des données.
Confidentialité Votre organisation dispose-t-elle d’un système de gestion de l’information sur la protection de la vie privée (PIM) établi, mis en œuvre et maintenu qui tient à l’engagement de la direction au moyen d’une politique ou d’une autre forme de documentation ou d’un système informatisé sur la façon dont vos efforts de gestion de l’information sur la protection de la vie privée sont maintenus pour la confidentialité et l’intégrité du système ? Déterminer les rôles, les responsabilités et les pouvoirs de chaque personne qui maintient le système, y compris les sous-traitants et les contrôleurs d’informations personnelles.
Fournir la preuve des processus permettant de vérifier que la minimisation des informations personnelles a lieu, que la dépersonnalisation et la suppression des informations personnelles sont effectuées à la fin de la période de traitement, que des contrôles sont en place pour la transmission des informations personnelles, y compris toute confidentialité, que l’enregistrement du transfert des informations personnelles d’un pays/d’une région à l’autre existe avec un consentement explicite à cet effet.
RGPD Fournir la preuve que les personnes concernées sont en mesure de soulever des SAR, que l’éditeur de logiciels indépendants est en mesure d’identifier tous les emplacements des données des personnes concernées lorsqu’il répond à une demande de SARs, qu’il existe une période de conservation pour les sauvegardes qui permet aux clients demandant la suppression de données via des SAR d’être supprimées lorsque les sauvegardes continues sur une période sont supprimées (cycle de vie des suppressions de sauvegarde les plus anciennes/réécriture).
Fournir la déclaration de confidentialité qui doit contenir tous les éléments requis comme suit : détails organisationnels (nom, adresse et autres informations d’identification personnelle), le type de données personnelles traitées, la durée de conservation des données personnelles, la légalité du traitement des données personnelles, les droits des personnes concernées ; notamment : droits de la personne concernée, droit à l’information, droit d’accès par la personne concernée, droit à l’effacement, droit à la limitation du traitement, droit à la portabilité des données, droit à l’opposition, droits relatifs à la prise de décision automatisée, y compris le profilage.
Loi américaine HIPAA Fournir la preuve que : il existe une politique pour la gestion des lois HIPAA et HIPAA au sein de votre organisation pour le personnel, les sous-traitants, les fournisseurs, etc. Verify our organization garantit la confidentialité, l’intégrité et la disponibilité de l’ePH.
Vérifier que vous : assurez la protection contre les utilisations ou divulgations raisonnablement anticipées de ces informations qui ne sont pas autorisées par la règle de confidentialité, assurez le respect de la règle de sécurité par son personnel. Fournir un plan de sauvegarde des données et de reprise après sinistre en vertu des articles 164.308 (a) (7) (ii) (A) et 164.308 (a) (7) (ii) (B).

Examen facultatif du cadre de conformité externe

Si votre organization est déjà en conformité avec des infrastructures de sécurité externes telles que ISO 27001, PCI-DSS, FedRAMP ou SOC 2 Type 2, vous pouvez choisir de tirer parti de ces certifications pour satisfaire à certains des contrôles de certification Microsoft 365. Les analystes s’efforceront d’aligner vos infrastructures de sécurité externes existantes sur les exigences de certification Microsoft 365.

Toutefois, si vos documents justificatifs ne démontrent pas que les contrôles de Certification Microsoft 365 ont été explicitement évalués dans le cadre de l’audit ou de l’évaluation de l’infrastructure externe, vous devez fournir des preuves supplémentaires pour vérifier que ces contrôles sont en place.

Exigences en matière de documentation :

La documentation doit clairement démontrer que l’environnement dans le champ d’application de la certification Microsoft 365 est inclus dans le champ d’application des infrastructures de sécurité éternelles. La validation de ces cadres sera effectuée en acceptant la preuve de certifications valides délivrées par des auditeurs tiers accrédités et réputés.

Ces auditeurs tiers doivent être membres d’organismes d’accréditation internationaux, tels que :

  • Normes de certification et de conformité pour la norme ISO 27001

  • Évaluateurs de sécurité de la qualité (QSA) pour PCI-DSS

Pour plus d’informations, reportez-vous aux instructions et normes spécifiques pour les frameworks externes pertinents pour votre certification.

Le tableau ci-dessous présente les cadres et la documentation requis acceptés par les analystes de certification dans le cadre du processus de validation.

Standard Conditions requises
ISO 27001 Une version publique de la déclaration d’applicabilité (SOA) et une copie du certificat ISO 27001 émis seront requises. La SOA résume votre position sur chacun des 114 contrôles de sécurité de l’information et sera utilisée pour identifier toute exclusion de contrôles qui ne sont pas détaillées de manière satisfaisante dans le certificat ISO 27001. S’il n’est pas possible de le déterminer en examinant la version publique de la SOA, l’analyste devra peut-être accéder à la SOA complète si la norme ISO 27001 peut être utilisée pour valider certains des contrôles de sécurité de la certification Microsoft 365. En plus de valider le périmètre des activités d’évaluation ISO 27001, les analystes confirmeront également la validité de la société d’audit telle que décrite ci-dessus.
ISO 22301 Un certificat ISO 22301 valide délivré par un organisme de certification accrédité et un document décrivant la portée de l’évaluation du système de gestion de la continuité des activités (SMCA) doivent être fournis. Le certificat et la documentation sur la portée seront utilisés pour vérifier que l’application, les services de soutien et les processus opérationnels ont été évalués dans le cadre d’un programme officiel de gestion de la continuité des activités. Les analystes d’évaluation examineront l’étendue de la certification, confirmeront la validité de l’organisme de certification et détermineront quels contrôles de continuité des activités de la certification Microsoft 365 peuvent être satisfaits grâce aux preuves d’évaluation ISO 22301.
ISO 27031 Un certificat ISO 27031 valide ou un rapport d’évaluation délivré par un organisme de certification ou d’évaluation accrédité doit être fourni, identifiant clairement l’application, l’infrastructure et les services de technologie de l’information et de la communication (TIC) pris en charge. La documentation sera utilisée pour évaluer l’état de préparation des TIC à la continuité des activités, y compris la planification de la reprise après sinistre, les capacités de reprise et les processus de résilience. Les analystes d’évaluation examineront la portée de l’évaluation, confirmeront la validité de l’organisation d’évaluation et détermineront quels contrôles de résilience opérationnelle et de récupération d’urgence de certification Microsoft 365 peuvent être satisfaits grâce aux preuves d’évaluation ISO 27031
PCI DSS Un document d’attestation de conformité (AOC) de niveau 1 valide doit être fourni indiquant clairement l’application visée et les composants du système. Un AOC d’auto-évaluation ne sera pas accepté comme preuve du respect des meilleures pratiques de sécurité. L’AOC sera utilisé pour déterminer les contrôles des spécifications de certification Microsoft 365 qui ont été évalués et confirmés dans le cadre de l’évaluation PCI DSS.
SOC 2 Le rapport SOC 2 (type II) doit être à jour (publié au cours des 15 derniers mois et la période déclarée a commencé au cours des 27 derniers mois) pour être utilisé comme preuve de conformité à l’un des contrôles d’évaluation de ce cadre de certification Microsoft 365.
FedRAMP Le programme fédéral de gestion des risques et des autorisations (FedRAMP) est un programme à l’échelle du gouvernement fédéral américain créé en 2011. Il fournit une approche standardisée de l’évaluation de la sécurité, de l’autorisation et de la surveillance continue des produits et services cloud.
Infrastructure Considérations supplémentaires
ISO 27001 Annexe C : Collecte de données probantes – Deltas pour la norme ISO 27001.
PCI-DSS Annexe D : Collecte de données probantes – Deltas pour PCI-DSS.
SOC 2 Annexe E : Collecte de données probantes – Deltas pour le SOC 2.

Remarque

Bien que des normes ou des infrastructures de sécurité externes puissent être soumises comme preuves justificatives pour satisfaire à certains contrôles de certification Microsoft 365, l’obtention de la certification Microsoft 365 nécessite une évaluation distincte. L’obtention de la certification Microsoft 365 n’implique pas que l’application a entièrement réussi les audits de ces infrastructures externes. La spécification de certification Microsoft 365 se concentre sur un sous-ensemble spécifique de contrôles dérivés de ces infrastructures afin de fournir à Microsoft un niveau de garantie supérieur concernant la posture de sécurité de votre application.

Exigences relatives à l’utilisation de cadres de conformité externes

Exigences relatives à l’utilisation de cadres de conformité externe

L’environnement dans le champ d’application et tous les processus métier de support doivent être inclus dans le champ d’application de tout cadre de conformité de sécurité externe pris en charge. Ceux-ci doivent être clairement documentés dans la documentation fournie.

Les cadres de conformité à la sécurité externe doivent être à jour, ce qui signifie qu’ils doivent être évalués au cours des 12 derniers mois (ou 15 mois si une réévaluation continue peut être vérifiée à l’aide de preuves à l’appui)

Les évaluations externes de la conformité à la sécurité doivent être effectuées par une société indépendante et accréditée.

Critères de validation du cadre externe

Évaluation SOC 2 Type 2

  • Le rapport SOC 2 doit être un rapport de type 2
  • L’audit SOC 2 doit inclure l’environnement M365 en cours d’évaluation
  • L’audit SOC 2 doit être réalisé au cours des 12 derniers mois
  • Les contrôles doivent être présentés équitablement et correctement conçus, comme l’exige un rapport de type 2
  • L’audit SOC 2 doit être mené par un tiers externe qualifié
  • Les procédures d’essai doivent confirmer que les contrôles de sécurité sont en place et correctement validés par l’auditeur.

Évaluation ISO 27001

  • L’audit ISO 27001 doit inclure l’environnement spécifié dans cette évaluation M365
  • La certification ISO 27001 doit être à jour et applicable à l’entité
  • L’évaluation ISO 27001 doit être effectuée par un tiers externe accrédité (les audits internes ISO 27001 ne sont pas acceptés)
  • L’évaluation ISO 27001 doit être réalisée au cours des 12 derniers mois

Évaluation PCI-DSS

  • Le document SP doit définir clairement l’environnement M365 en cours d’évaluation
  • L’AOC doit être à jour
  • L’AOC doit être signé par le QSA et l’entité

En savoir plus

  • Dernière mise à jour :