Visão geral da estrutura de Certificação do Microsoft 365

Este artigo fornece informações detalhadas sobre a Certificação Microsoft 365, incluindo uma lista dos controles de segurança necessários e diretrizes para ISVs e desenvolvedores.

A Certificação Microsoft 365 é uma auditoria independente de segurança e privacidade de aplicativos, suplementos, agentes e ambiente de back-end de suporte (coletivamente chamados de aplicativos) que se integra à plataforma Microsoft 365. Os aplicativos aprovados serão designados como Certificados pelo Microsoft 365 em todo o ecossistema do Microsoft 365 e poderão ser encontrados facilmente nos marketplaces do Microsoft 365 por meio de filtros de pesquisa focados em conformidade e identidade visual. Os ISVs terão a oportunidade de compartilhar os atributos de conformidade de seus aplicativos em páginas dedicadas dentro desse conjunto de documentação.

A Certificação Microsoft 365 está disponível para os seguintes tipos de aplicativos:

  • Suplementos do Microsoft 365 (Word, Excel, Outlook, PowerPoint, OneNote, Project)
  • Aplicativos do Teams
  • Soluções do SharePoint
  • Aplicativos Web (SaaS)
  • Extensões do Copilot

Importante

A Certificação Microsoft 365 é uma revisão rigorosa da segurança e conformidade de um aplicativo em relação à estrutura da Certificação Microsoft 365 e requer um compromisso substancial de tempo e recursos para ser concluída. Antes de começar, examine as estruturas de controle de conformidade para verificar se seu aplicativo está qualificado. Se você tiver alguma dúvida, envie um e-mail appcert@microsoft.compara .

Termos

Ao participar do programa de Certificação Microsoft 365, você concorda com estes termos suplementares e em conformidade com qualquer documentação que se aplique à sua participação no programa de Certificação Microsoft 365 com a Microsoft Corporation ("Microsoft", "nós", "nos" ou "nosso"). Você declara e garante que tem autoridade para aceitar estes termos suplementares da Certificação Microsoft 365 em seu nome, de uma empresa e/ou de outra entidade, conforme aplicável. Podemos alterar, corrigir ou rescindir estes termos suplementares a qualquer momento. Sua participação contínua no programa de Certificação do Microsoft 365 após qualquer alteração ou alteração significa que você concorda com os novos termos complementares. Se você não concordar com os novos termos complementares ou se rescindirmos estes termos suplementares, você deverá parar de participar do programa de Certificação Microsoft 365.

Pré-requisitos

Antes que a Certificação Microsoft 365 possa ser concedida, um aplicativo deve concluir o seguinte:

Verificação do fornecedor Quando um aplicativo tem um fornecedor verificado, a organização que publica o aplicativo foi verificada como autêntica pela Microsoft. A verificação de um aplicativo inclui o uso de uma conta do Microsoft Cloud Partner Program (CPP) que foi verificada e a associação da PartnerID verificada a um registro de aplicativo. Obter verificação do editor

O Atestado de Fornecedor é um processo de autoatendimento em que os ISVs (desenvolvedores de aplicativos) respondem a um conjunto de perguntas sobre suas práticas de segurança, como o manuseio de dados confidenciais. Depois de concluído, o aplicativo receberá uma página de documentos que eles podem compartilhar com os clientes, que inclui as respostas fornecidas.

Revise os critérios de controle. Nem sempre é um requisito cumprir todos os controles para obter uma certificação. No entanto, limites (que não serão divulgados) estão em vigor para cada um dos três domínios de segurança discutidos neste documento de visão geral e devem ser ultrapassados. O não cumprimento de controles críticos rotulados como "falha grave" resultará na reprovação da avaliação.

Prazo de envio

Existem duas etapas para o processo de envio para obter a certificação:

Etapa 1: Apresentação inicial do documento (prazo de 14 dias)

Nesse estágio, o ISV deve enviar documentação que forneça uma visão geral do ambiente de suporte do aplicativo. Isso inclui, mas não está limitado a:

  • Diagrama de arquitetura/fluxo de dados

  • Listas de componentes do sistema

  • Inventários de ativos de software

Um analista examinará essa documentação para definir o escopo da avaliação. O ISV tem 14 dias para preencher e carregar a documentação necessária. O não cumprimento desse prazo pode atrasar o processo ou resultar em falha no envio.

Estágio 2: Revisão completa das evidências (prazo de 60 dias)

Uma vez definido o escopo, o ISV prosseguirá para a fase de coleta de evidências. Nesta etapa:

  1. O ISV deve carregar evidências em relação a todos os controles aplicáveis definidos no escopo.

  2. Essa evidência passará por revisão, revisões (se necessário) e um processo final de perguntas e respostas.

  3. O teste de penetração também pode ser realizado durante esse período.

O ISV tem 60 dias para concluir esta etapa, a partir da primeira apresentação de evidências, que inclui:

  • Carregando evidências para todos os controles

  • Revisão e comentários do analista

  • Quaisquer revisões necessárias nas evidências enviadas

  • Conclusão do processo de P e R

Não cumprimento do prazo

Se o ISV não puder concluir o processo dentro do prazo de 60 dias, a avaliação falhará. No entanto, a critério do analista, uma prorrogação de até 60 dias adicionais pode ser concedida em circunstâncias válidas, tais como:

  • Feriados sazonais
  • Atrasos nos testes de penetração
  • Alterações internas
  • Tempo necessário para implementar as mudanças necessárias para atender aos requisitos de controle

Nenhuma outra extensão pode ser concedida, uma vez esgotados os dois prazos de 60 dias.

Escopo da certificação

O ambiente no escopo abrange todos os sistemas e infraestrutura necessários para fornecer o código do aplicativo, suplemento ou agente, juntamente com todos os sistemas de back-end de suporte com os quais o aplicativo/suplemento/agente pode se comunicar. Quaisquer ambientes adicionais conectados ao ambiente no escopo também devem ser incluídos no escopo, a menos que a segmentação adequada seja implementada e os ambientes conectados não possam comprometer a segurança do ambiente no escopo.

Observação: todos os ambientes de recuperação de desastre separados também devem ser incluídos no ambiente no escopo, pois esses ambientes podem ser essenciais para manter a continuidade do serviço em caso de falhas no ambiente primário.

Além disso, os ambientes de backup remoto também devem ser incorporados ao escopo, pois podem armazenar dados confidenciais da Microsoft. Portanto, controles de segurança adequados devem ser implementados para esses ambientes.

O termo componentes de sistema no escopo inclui todos os dispositivos e sistemas usados ativamente no ambiente definido no escopo. Esses componentes incluem, mas não estão limitados a:

  • Aplicativos web
  • Servidores (físicos ou virtuais, localizados no local ou na nuvem)
  • Opções
  • Balanceadores de Carga
  • Infraestrutura Virtual
  • Portais de gerenciamento da Web do provedor de nuvem
  • Recursos de nuvem (Máquinas Virtuais, Serviços de Aplicativos, contas de Armazenamento, Bancos de Dados etc.)

Importante

Os componentes do sistema voltados para o público são particularmente vulneráveis a ataques de agentes de ameaças externas e, portanto, correm maior risco. Normalmente, esses sistemas devem ser isolados dos componentes do sistema interno por meio da implementação de controles de segurança de rede (NSCs), como uma zona desmilitarizada (DMZ). A finalidade de uma DMZ é atuar como uma zona tampão, limitando a confiança estendida a sistemas externos e aumentando a segurança para proteger sistemas e dados internos. Embora uma DMZ ainda possa ser ideal em alguns casos, as arquiteturas de nuvem modernas geralmente dependem de medidas de segurança alternativas adaptadas para cenários de implantação específicos.

Infraestrutura como Serviço (IaaS), Plataforma como Serviço (PaaS) e Software como Serviço (SaaS)

Quando IaaS e/ou PaaS são usados para dar suporte ao ambiente no escopo em análise, o provedor da plataforma de nuvem será responsável por alguns dos controles de segurança avaliados durante todo o processo de certificação. Os analistas precisarão receber verificação externa independente das melhores práticas de segurança pelo provedor da plataforma de nuvem por meio de relatórios de conformidade externos, como relatórios PCI-DSS, Atestado de Conformidade (AOC), ISO 27001 ou SOC 2 Tipo II.

Para obter detalhes sobre quais controles de segurança provavelmente são aplicáveis ao tipo de implantação e se o ambiente processa ou transfere dados do Microsoft 365, consulte o Apêndice C. Os tipos de implantação incluem:

  • ISV Hosted: aplicativo hospedado por fornecedores independentes de software
  • IaaS hospedado: infraestrutura fornecida por plataformas de nuvem de terceiros.
  • PaaS/Serverless Hosted: Aplicativos com média de arquitetura baseada em plataforma ou sem servidor.
  • Hospedado Híbrido: uma combinação de componentes locais e hospedados na nuvem.
  • Hospedado compartilhado: ambientes de nuvem compartilhados utilizados por vários locatários.

Nos casos em que a IaaS ou a PaaS estão em uso, as evidências devem validar se a implantação está alinhada com os controles de segurança esperados para a arquitetura relevante.

Amostragem

Para garantir uma avaliação completa, a amostragem dos componentes do sistema no escopo deve considerar fatores como sistemas operacionais, função de dispositivo primário, tipo de dispositivo (por exemplo, servidores, roteadores, controles de segurança de rede) e localização geográfica. As amostras são selecionadas no início do processo de certificação com base nessas considerações. A tabela abaixo orienta o tamanho da amostragem com base na população de componentes no escopo:

Tamanho da população Amostra
<=5 1
>5 & <10= 2
>10 & <=30 3
>30 4

Isso garante uma avaliação representativa da conformidade do ambiente em diversas configurações e modelos de implantação.

Observação

Se forem identificadas discrepâncias entre os dispositivos durante a avaliação, o tamanho da amostra pode ser ajustado para garantir a apresentação adequada do ambiente.

Visão geral do processo de certificação

Para iniciar o processo de certificação do Microsoft 365:

  1. Atestado de Fornecedor Acesse o Partner Center e preencha o formulário Atestado de Fornecedor. Observação: se o seu envio tiver mais de três meses, você deverá reenviá-lo para análise e validação.

  2. Iniciar certificação Uma vez no Partner Center, selecione a opção "Iniciar certificação" para iniciar o envio inicial do documento. Esta etapa ajuda os analistas de certificação a identificar o escopo da avaliação com base na arquitetura do seu aplicativo e como ele gerencia os dados da Microsoft.

A certificação é realizada em duas etapas principais:

  1. Envio inicial de documentos Nesta fase, você fornece detalhes importantes para ajudar os analistas a entender o design do seu aplicativo, o fluxo de dados e o ambiente no escopo. Os analistas determinarão os controles de segurança aplicáveis e descreverão os componentes do sistema que exigem evidências. Você deve fornecer documentação precisa para facilitar essa revisão, o que representa aproximadamente 5% do processo geral.

  2. Revisão Completa de Evidências Nesta etapa, você envia evidências detalhadas que demonstrem conformidade com os controles de segurança para o ambiente no escopo. Os analistas trabalharão em estreita colaboração com você durante esta fase para revisar, esclarecer e verificar seus envios. Essa fase leva o restante do processo.

Avaliação

Assim que o Envio Inicial de Documentos for aprovado, uma lista de controles de segurança necessários será exibida no portal. Você tem 60 dias para fornecer evidências para cada controle, confirmando que ele está em vigor e operacional. Os analistas analisarão suas evidências e as aprovarão ou solicitarão detalhes ou revisões adicionais.

Certificação

Depois que seu envio for revisado e validado por um analista, você receberá uma notificação sobre a decisão de certificação. Os aplicativos que atenderem aos critérios de certificação receberão um selo, que será exibido na listagem do AppSource e nas páginas associadas do Microsoft Docs. Essas páginas também fornecerão relatórios detalhados sobre os atributos de segurança e conformidade do aplicativo.

Revisão e recertificação

Os aplicativos Certificados pelo Microsoft 365 devem passar por uma recertificação anual para garantir a conformidade contínua com os padrões da Microsoft. O processo de recertificação envolve a reavaliação dos controles no escopo para confirmar se eles estão alinhados com o ambiente atual. Você pode iniciar o processo de recertificação até 90 dias antes da expiração da certificação para evitar interrupções. As certificações permanecerão válidas durante esse período.

Se a recertificação não for concluída antes da data de expiração, a certificação será revogada. Como resultado:

  • O selo de certificação e a identidade visual do aplicativo serão removidos.

  • Os ISVs não terão mais permissão para comercializar o aplicativo como Certificado Microsoft 365.

Se houver alterações significativas no aplicativo fora do período de recertificação agendado, os ISVs deverão informar o Programa de Conformidade de Aplicativos da Microsoft para garantir que o aplicativo permaneça em conformidade.

Submissão inicial do documento

Seu envio inicial deve incluir as seguintes informações:

Visão geral da documentação Detalhes da documentação
Descrição do aplicativo/suplemento/agente Uma descrição da finalidade e da funcionalidade do aplicativo/suplemento/agente. Isso deve fornecer ao analista de certificação uma boa compreensão de como o aplicativo/suplemento/agente funciona e qual é o uso pretendido.
Relatório de teste de penetração Um relatório de teste de penetração concluído nos últimos 12 meses. Esse relatório deve incluir o ambiente que dá suporte à implantação do aplicativo/suplemento/agente, juntamente com qualquer ambiente adicional que dê suporte à operação do aplicativo/suplemento/agente. Observação: se o ISV não realizar testes de penetração anuais no momento, a equipe de auditoria poderá concluí-los por um custo adicional.
Diagramas de arquitetura Um diagrama de arquitetura lógica que representa uma visão geral de alto nível da infraestrutura de suporte do aplicativo. Isso deve incluir todos os ambientes de hospedagem e a infraestrutura de suporte que dão suporte ao aplicativo. Este diagrama DEVE descrever todos os diferentes componentes do sistema de suporte dentro do ambiente para ajudar os analistas de certificação a entender os sistemas no escopo e ajudar a determinar a amostragem. Indique também o tipo de ambiente de hospedagem usado; ISV hospedado, IaaS, PaaS ou híbrido. Observação: Quando o SaaS é usado, indique os vários serviços SaaS usados para fornecer serviços de suporte no ambiente.
Pegada pública Detalhando todos os endereços IP públicos e URLs usados pela infraestrutura de suporte. Isso deve incluir toda a faixa de IP roteável alocada ao ambiente, a menos que uma segmentação adequada tenha sido implementada para dividir a faixa em uso (será necessária evidência adequada de segmentação).
Diagramas de fluxo de dados Diagramas de fluxo detalhando o seguinte:
✓ Microsoft 365 Fluxos de dados de e para o Aplicativo/Suplemento/Agente (incluindo EUII e OII).
✓ Microsoft 365 Os fluxos de dados dentro da infraestrutura de suporte (quando aplicável).
✓ Diagramas destacando onde e quais dados são armazenados, como os dados são passados para terceiros externos (incluindo detalhes de quais terceiros) e como os dados são protegidos em trânsito em redes abertas/públicas e em repouso.
Detalhes do ponto de extremidade da API Uma lista completa de todos os pontos de extremidade de API usados pelo seu aplicativo. Para ajudar a entender o escopo do ambiente, forneça locais de ponto de extremidade de API em seu ambiente.
Permissões de API da Microsoft Forneça documentação detalhando TODAS as APIs da Microsoft que são usadas, juntamente com quais permissões estão sendo solicitadas para o funcionamento do aplicativo/suplemento/agente, juntamente com uma justificativa para as permissões solicitadas
Tipos de armazenamento de dados Armazenamento de dados e manuseio de documentos que descrevam:
✓ Até que ponto os dados do Microsoft 365 EUII e OII estão sendo recebidos e armazenados
✓ O período de retenção de dados.
✓ Por que os dados do Microsoft 365 estão sendo capturados.
✓ Onde os dados do Microsoft 365 são armazenados (também deve ser incluído nos diagramas de fluxo de dados fornecidos acima).
Confirmação de conformidade Documentação de suporte para estruturas de segurança externas incluídas no envio do Atestado do Fornecedor ou a serem consideradas ao revisar os controles de segurança da Certificação Microsoft 365. Atualmente, há suporte para os quatro seguintes:
✓ Atestado de Conformidade (AOC) do PCI DSS .
✓ Relatórios SOC 2 Tipo I/Tipo II.
✓ ISMS / IEC - 1S0/IEC 27001 Declaração de Aplicabilidade (SoA) e Certificação.
✓ FedRAMP , Pacote de Autorização do FedRAMP e Relatório de Avaliação de Prontidão do FedRAMP.
Dependências da Web Documentação listando todas as dependências usadas pelo aplicativo com as versões em execução atuais.
Inventário de software Um inventário de software atualizado que inclui todos os softwares usados no ambiente no escopo, juntamente com as versões.
Inventário de hardware Um inventário de hardware atualizado usado pela infraestrutura de suporte. Isso será usado para ajudar na amostragem ao realizar a fase de avaliação. Se o seu ambiente incluir PaaS, forneça detalhes dos serviços de nuvem/recursos consumidos.

Atividades de coleta e avaliação de evidências

Os analistas de certificação precisarão analisar as evidências em todos os componentes do sistema dentro do conjunto de amostras definido. Os tipos de evidências necessárias para apoiar o processo de avaliação incluem qualquer um ou todos os seguintes:

Coleta de evidências

  • Documentação inicial, realçada no guia de envio de documentação inicial
  • Documentos de política
  • Documentos de processo
  • Definições de configuração do sistema
  • Alterar tíquetes
  • Registros de controle de alterações
  • Relatórios do sistema
  • Atas de reunião
  • Contratos/acordos

Vários métodos serão usados para coletar as evidências necessárias para concluir o processo de avaliação. Essa coleta de evidências pode ser na forma de:

  • Documentos
  • Capturas de tela
  • Entrevistas
  • Compartilhamento de tela

As técnicas de coleta de evidências utilizadas serão determinadas durante o processo de avaliação. Para exemplos específicos do tipo de evidência exigida em seu envio, consulte o Guia de Evidências de Amostra.

Compartilhamento de evidências

Durante o processo de certificação, os ISVs podem optar por compartilhar suas evidências de conformidade diretamente com clientes potenciais. A caixa de seleção localizada na caixa de diálogo de upload de arquivo, que é marcada por padrão, concede aos administradores do Microsoft 365 acesso às evidências de certificação do aplicativo no Centro de Administração do Teams e no Centro de Administração Microsoft 365. (Os administradores do Microsoft 365 são responsáveis por configurar, gerenciar e proteger os serviços e recursos do Microsoft 365 dentro de uma organização.) Essa transparência visa simplificar a due diligence para organizações que avaliam novos aplicativos para acelerar a tomada de decisões. Caso um ISV prefira não tornar essas evidências públicas, ele pode simplesmente desmarcar a caixa no momento do envio, mantendo controle total sobre como e quando sua documentação de conformidade é divulgada.

Atividades de avaliação

Os analistas de certificação examinarão as evidências enviadas para verificar se todos os controles necessários para a Certificação Microsoft 365 foram atendidos. Para agilizar o processo, certifique-se de que toda a documentação especificada no Envio Inicial da Documentação esteja completa e fornecida com antecedência.

Durante a revisão, os analistas avaliarão as evidências do envio inicial e do atestado do editor. Eles determinarão o escopo da investigação, o lado da amostragem e se evidências adicionais são necessárias. Os analistas usarão todas as informações coletadas para avaliar a conformidade com a especificação de Certificação Microsoft 365 e decidir se o seu aplicativo atende aos controles definidos.

Critérios de certificação de aplicativos

O aplicativo, sua infraestrutura de suporte e a documentação de suporte serão avaliados nos três domínios de segurança a seguir:

  1. Segurança de aplicativos
  2. Segurança operacional
  3. Manuseio de dados, segurança e privacidade

Cada um desses domínios de segurança inclui controles de chave específicos que abrangem um ou mais requisitos que serão avaliados como parte do processo de avaliação. Para garantir que a Certificação Microsoft 365 seja inclusiva para desenvolvedores de todos os tamanhos, cada um dos domínios de segurança é avaliado usando um sistema de pontuação para determinar uma pontuação geral de cada um dos domínios. As pontuações para cada um dos controles da Certificação do Microsoft 365 são alocadas entre 1 (baixo) e 3 (alto) com base no risco percebido de que esse controle não seja implementado. Cada um dos domínios de segurança terá uma marca percentual mínima para ser considerado aprovado. Certos fatores resultam em falhas automáticas, incluindo:

  • Uso de permissões de API que não aderem ao princípio de privilégios mínimos (PoLP)

  • Falta de relatórios de teste de penetração quando necessário.

  • Ausência de defesas antimalware.

  • Falha ao implementar a MFA (autenticação multifator) para acesso administrativo.

  • Processos de aplicação de patch ausentes ou insuficientes.

  • Falta de aviso de privacidade GDPR compatível.

Segurança de aplicativos

O domínio de segurança do aplicativo avalia as seguintes áreas:

  • Testes de Penetração
  • Validação de permissão da API do Graph
  • IA responsável

Teste de penetração

O teste de penetração é fundamental para identificar e atenuar os riscos associados ao aplicativo ou suplemento e seu ambiente de suporte. Isso garante que o aplicativo forneça garantias de segurança adequadas aos clientes.

O teste de penetração é obrigatório para qualquer aplicativo que se conecte a serviços externos não hospedados ou gerenciados pela Microsoft. Se o aplicativo for implantado como uma solução autônoma que usa apenas serviços Microsoft, como o GraphAPI, o teste de penetração pode não ser necessário. No entanto, os aplicativos hospedados no Azure devem passar por testes de penetração para garantir a segurança do ambiente no escopo.

Escopo do teste de penetração

Teste de infraestrutura: para infraestrutura interna e externa, o teste de penetração deve ser realizado no ambiente de produção ao vivo que dá suporte ao aplicativo, suplemento ou agente. Isso inclui:

O ambiente em que o código do aplicativo, suplemento ou agente está hospedado (geralmente referenciado no arquivo de manifesto).

Quaisquer ambientes adicionais que interajam ou dêem suporte à operação do aplicativo/suplemento/agente (por exemplo, se o aplicativo/suplemento/agente se comunicar com outros aplicativos Web fora do Microsoft 365).

Ao definir o escopo do teste de penetração, é fundamental incluir todos os sistemas ou ambientes conectados que podem impactar a segurança do ambiente no escopo.

Recomendações

Teste de penetração de aplicativo Web: é recomendável que o teste de penetração do aplicativo Web seja executado diretamente no ambiente de produção ao vivo. No entanto, o teste de aplicativo Web pode ser realizado em um ambiente de teste/UAT (Teste de Aceitação do Usuário), desde que o relatório de teste de penetração confirme que a mesma base de código está sendo usada na produção no momento do teste.

Validação de segmentação: Se as técnicas de segmentação forem usadas para isolar ambientes no escopo de outros, o relatório de teste de penetração deverá validar a eficácia dessas técnicas de segmentação. Isso garante que nenhuma vulnerabilidade seja introduzida por meio do processo de segmentação.

Requisitos de teste de penetração

Os relatórios de teste de penetração serão revisados para garantir que não haja vulnerabilidades que atendam aos seguintes critérios de falha automática descritos nos controles abaixo.

Tipo de Critério Controles de teste de penetração
Critérios gerais Os testes de penetração de aplicativos da Web (autenticados e não autenticados) e de infraestrutura interna (se aplicável) e externa DEVEM ser realizados anualmente (a cada 12 meses) e conduzidos por uma empresa independente de boa reputação.
A correção de vulnerabilidades críticas e de alto risco identificadas DEVE ser concluída dentro de um mês após a conclusão do teste de penetração ou antes, dependendo do processo de aplicação de patch documentado do ISV.
O volume externo completo (endereços IP, URLs, pontos de extremidade de API etc.) DEVE ser incluído no escopo do teste de penetração e deve ser claramente documentado no relatório de teste de penetração.
A menos que o ambiente se alinhe ao PaaS, todas as redes internas DEVEM ser incluídas no escopo do teste de penetração e devem ser claramente documentadas no relatório de teste de penetração.
O teste de penetração de aplicativos Web DEVE incluir todas as classes de vulnerabilidade; por exemplo, o OWASP Top 10 ou o SANS Top 25 CWE mais recente. A recomendação é que isso seja detalhado no relatório do teste de penetração, caso contrário, será difícil demonstrar.
Vulnerabilidades críticas e de alto risco ou vulnerabilidades consideradas uma falha automática DEVEM ser testadas novamente pela empresa de teste de penetração e claramente destacadas como corrigidas no relatório de teste de penetração.
Critérios de reprovação automática: Presença de um sistema operacional sem suporte ou de uma Biblioteca JavaScript sem suporte.
Presença de contas administrativas padrão, enumeráveis ou adivinháveis.
Presença de riscos de injeção de SQL.
Presença de script entre sites.
Presença de vulnerabilidades de passagem de diretório (caminho de arquivo).
Presença de vulnerabilidades HTTP, por exemplo, divisão de resposta de cabeçalho, contrabando de solicitação e ataques de dessincronização.
Presença de divulgação do código-fonte (incluindo LFI).
Qualquer pontuação crítica ou alta, conforme definido pelas diretrizes de gerenciamento de patches CVSS.
Qualquer vulnerabilidade técnica significativa que possa ser facilmente explorada para comprometer uma grande quantidade de EUII ou OUI.

Importante

Os relatórios devem ser capazes de fornecer garantia suficiente para que tudo o que é detalhado na seção de requisitos de teste de penetração acima possa ser demonstrado.

Validação de permissão da API do Graph

Isso garante que o aplicativo, suplemento ou agente não solicite permissões excessivas ou excessivamente permissivas. Os analistas de certificação examinam manualmente as permissões solicitadas pelo aplicativo e as marcam com o envio do Atestado do Fornecedor.

O objetivo é confirmar se as permissões solicitadas aderem ao princípio de privilégios mínimos. Se os analistas descobrirem que o aplicativo está solicitando permissões que excedem o necessário, eles entrarão em contato com o ISV para validar a justificativa comercial para essas permissões. Quaisquer discrepâncias identificadas entre as permissões solicitadas e o envio do Atestado do Fornecedor devem ser abordadas e resolvidas durante esta revisão.

IA responsável

As informações enviadas em resposta aos controles de IA responsáveis serão analisadas juntamente com o arquivo de manifesto do aplicativo fornecido pelo ISV. Isso permite que o analista marcar a integração do Microsoft Copilot com o aplicativo passando pela certificação, fornecendo uma compreensão clara de como os dois interagem entre si e quais ações são tomadas em nome do cliente. Reconhecemos que é vital que a IA seja utilizada com responsabilidade e onde o cliente esteja totalmente informado. Desde que as informações compartilhadas estejam alinhadas com a funcionalidade esperada do aplicativo e com o Standard de IA Responsável da Microsoft ou o Centro de Recursos de Inteligência Artificial Confiável & Responsável do NIST, esses controles serão considerados aprovados (sujeitos às verificações usuais de P e R).

A intenção é trabalhar ainda mais com a Microsoft para fornecer alguns detalhes dessa marca nas páginas relevantes voltadas para o público, para permitir que os clientes tomem decisões totalmente informadas sobre o uso de seus dados quando se trata do Copilot e do aplicativo relacionado.

Segurança operacional

Esse domínio mede o alinhamento da infraestrutura de suporte e dos processos de implantação de um aplicativo com as práticas recomendadas de segurança.

Controles

Família de controle Controls
Treinamento de conscientização Fornecer evidências de que a organização fornece treinamento de conscientização de segurança estabelecido para usuários do sistema de informações (incluindo gerentes, executivos seniores e contratados) como parte do treinamento inicial para novos usuários ou quando exigido por alterações no sistema de informações.
Fornecer evidências de uma frequência de treinamento de conscientização definida pela organização.
Forneça evidências de documentação e monitoramento de atividades individuais de conscientização sobre segurança do sistema de informações, mantendo registros de treinamento individuais em uma frequência definida pela organização.
Proteção contra malware - antivírus Forneça evidências de que sua solução antimalware está ativa e habilitada em todos os componentes do sistema amostrados e configurada para atender aos seguintes critérios:
Se for antivírus, essa varredura ao acessar será habilitada e as assinaturas serão atualizadas em um dia e bloqueará automaticamente malware ou alertas e colocará em quarentena quando ele for detectado.
OU se EDR/NGAV (Detecção e Resposta de Ponto de Extremidade/Antivírus de Próxima Geração), a verificação periódica estiver sendo executada, os logs de auditoria serão gerados e ele será mantido atualizado continuamente e terá recursos de autoaprendizagem.
Se for EDR/NGAV, ele bloqueará malware conhecido e identificará e bloqueará novas variantes de malware com base em comportamentos de macro, além de ter recursos completos de lista segura.
Proteção contra malware \u2012 controles de aplicativo Fornecer evidências demonstráveis de que existe e está atualizada uma lista aprovada de software/aplicativos com justificativa comercial.
Que cada aplicativo passe por um processo de aprovação e seja aprovado antes de sua implantação.
Essa tecnologia de controle de aplicativo está ativa, habilitada e configurada em todos os componentes do sistema amostrados, conforme documentado.
Gerenciamento de patches - aplicação de patches e classificação de risco Documentação da política de fornecimento que rege como novas vulnerabilidades de segurança são identificadas e atribuídas a uma pontuação de risco.
Forneça evidências de como novas vulnerabilidades de segurança são identificadas.
Fornecer evidências que demonstrem que todas as vulnerabilidades recebem uma classificação de risco depois de identificadas.
Fornecer evidências de que todos os componentes do sistema amostrados estão sendo corrigidos de acordo com os prazos de correção definidos pela organização e que os sistemas operacionais e componentes de software não suportados não estão em uso. Quando aplicável, isso deve incluir a base de código, se a tecnologia sem servidor ou PaaS for usada, ou a infraestrutura e a base de código, se a IaaS for usada.
Diretrizes de prazo de correção em vigor, por exemplo "crítico – dentro de 14 dias, alto – dentro de 30 dias, médio – dentro de 60 dias".
Varredura de vulnerabilidade Forneça os relatórios trimestrais de verificação de vulnerabilidades da infraestrutura e do aplicativo Web. A verificação precisa ser realizada em relação a toda a área de cobertura pública (endereços IP e URLs) e intervalos de IP internos.
Forneça evidências demonstrativas de que a correção de vulnerabilidades identificadas durante a verificação de vulnerabilidades são corrigidas de acordo com o prazo de aplicação de patch documentado.
NSC (Controles de Segurança de Rede) Forneça evidências de que os NSCs (Controles de Segurança de Rede) estão instalados no limite do ambiente no escopo e instalados entre a rede de perímetro e as redes internas.
E se híbrido, local, IaaS também fornece evidências de que todo o acesso público termina na rede de perímetro.
Valide se todos os NSC (Controles de Segurança de Rede) estão configurados para descartar o tráfego não definido explicitamente na base de regras e se as revisões de regras do NSC (Controles de Segurança de Rede) são realizadas pelo menos a cada 6 meses.
Controle de alterações Fornecer evidências de que quaisquer alterações introduzidas nos ambientes de produção são implementadas por meio de solicitações de alteração documentadas que contêm o impacto da mudança, detalhes dos procedimentos de retirada, testes a serem realizados, revisão e aprovação por pessoal autorizado.
Forneça evidências de que existem ambientes separados para que: ambientes de desenvolvimento e teste/preparo imponham a separação de tarefas do ambiente de produção, a separação de tarefas seja imposta por meio de controles de acesso, dados de produção confidenciais não estejam em uso nos ambientes de desenvolvimento ou teste/preparo.
Desenvolvimento/implantação segura de software Forneça políticas e procedimentos que dão suporte ao desenvolvimento seguro de software e incluam padrões do setor e/ou práticas recomendadas para codificação segura. Como o Open Web Application Security Project (OWASP) Top 10 ou o SysAdmin, Audit, Network and Security (SANS) Top 25 Common Weakness Enumeration (CWE).
Forneça evidências de que os repositórios de código são protegidos para que: todas as alterações de código passem por um processo de revisão e aprovação por um segundo revisor antes de serem mescladas com a ramificação principal, os controles de acesso apropriados estejam em vigor, todo o acesso seja imposto por meio de autenticação multifator (MFA)
Forneça evidências de que todas as versões feitas nos ambientes de produção são revisadas e aprovadas antes de sua implantação.
Account management Forneça evidências de que as credenciais padrão estão desabilitadas, removidas ou alteradas nos componentes do sistema amostrados.
Fornecer evidências de que um processo está em vigor para proteger (fortalecer) contas de serviço e que esse processo foi seguido.
Fornecer evidências de que: contas de usuário exclusivas são emitidas para todos os usuários, os princípios de privilégio mínimo do usuário estão sendo seguidos dentro do ambiente, uma política de senha/senha forte ou outras mitigações adequadas estão em vigor, um processo está em vigor e é seguido pelo menos a cada três meses para desabilitar ou excluir contas não usadas dentro de três meses.
Valide se a MFA está configurada para todas as conexões de acesso remoto e todas as interfaces administrativas que não são do console, incluindo o acesso a quaisquer repositórios de código e interfaces de gerenciamento de nuvem.
Registro de eventos, revisão e alerta de segurança Forneça evidências de que um mínimo de 30 dias de dados de log de eventos de segurança estão imediatamente disponíveis, com 90 dias de logs de eventos de segurança sendo retidos.
Fornecer evidências de que os logs estão sendo revisados periodicamente e que quaisquer eventos/anomalias de segurança potenciais identificados durante o processo de revisão são investigados e resolvidos
Forneça evidências de que as regras de alerta estão configuradas para que os alertas sejam disparados para investigação dos seguintes eventos de segurança, quando aplicável: criação/modificações de contas privilegiadas, atividades ou operações privilegiadas/de alto risco, eventos de malware, violação de log de eventos, eventos de IDPS/WAF. (se configurado)
Gerenciamento de risco de informações Fornecer evidências de que uma política/processo formal de gerenciamento de riscos de segurança da informação ratificada está documentada e estabelecida.
Fornecer evidências de que uma avaliação formal de risco de segurança da informação em toda a empresa é realizada pelo menos uma vez por ano.
OR para análise de risco direcionada: uma análise de risco direcionada é documentada e realizada no mínimo a cada 12 meses para cada caso em que um controle tradicional ou uma melhor prática do setor não esteja em vigor, onde uma limitação de projeto/tecnologia crie um risco de introdução de uma vulnerabilidade no ambiente ou coloque usuários e dados em risco, após suspeita ou confirmação de comprometimento.
Validar se a avaliação de risco de segurança da informação inclui componente do sistema ou recurso afetado, ameaças e vulnerabilidades ou equivalente, matrizes de impacto e verossimilhança ou equivalente, a criação de um registro de risco/plano de tratamento de risco.
Forneça evidências de que você possui processos de gerenciamento de riscos que avaliam e gerenciam riscos associados a fornecedores e parceiros de negócios e pode identificar e avaliar mudanças e riscos que podem afetar seu sistema de controles internos.
Resposta a incidentes de segurança Forneça seu plano/procedimento de resposta a incidentes de segurança (IRP) ratificado.
Forneça evidências descrevendo como sua organização responde a incidentes, mostrando como ela é mantida e que inclui detalhes da equipe de resposta a incidentes, incluindo informações de contato, um plano de comunicação interna durante o incidente e comunicação externa com partes relevantes, como principais partes interessadas, marcas de pagamento e adquirentes, órgãos reguladores (por exemplo, 72 horas para GDPR), autoridades de supervisão, diretores, clientes, bem como etapas para atividades como classificação, contenção, mitigação, recuperação e retorno às operações comerciais normais, dependendo do tipo de incidente
Forneça evidências de que todos os membros da equipe de resposta a incidentes receberam treinamento anual que lhes permita responder a incidentes.
Forneça evidências de que a estratégia de resposta a incidentes e a documentação de suporte são revisadas e atualizadas com base nas lições aprendidas em um exercício de mesa, nas lições aprendidas ao responder a um incidente e nas mudanças organizacionais.
Plano de continuidade de negócios e plano de recuperação de desastres Forneça evidências de que a documentação existe e é mantida, o que descreve o plano de continuidade dos negócios.
Fornecer evidências de que o plano de continuidade de negócios detalha o pessoal relevante e suas funções e responsabilidades, incluindo: funções de negócios com requisitos e objetivos de contingência associados, procedimentos de backup de sistemas e dados, configuração e agendamento/retenção, prioridade de recuperação e metas de prazo, um plano de contingência detalhando ações, etapas e procedimentos a serem seguidos para retornar sistemas de informações críticas, funções de negócios e serviços à operação no caso de um interrupção inesperada e não programada, um processo estabelecido que abrange a eventual restauração completa do sistema e o retorno ao estado original.
Fornecer evidências de que a documentação existe, é mantida e descreve o plano de recuperação de desastres e inclui, no mínimo: pessoal e suas funções, responsabilidades e processo de escalonamento, inventário dos sistemas de informação usados para dar suporte a funções e serviços críticos de negócios, procedimentos e configuração de backup de sistema e dados, um plano de recuperação detalhando ações e procedimentos a serem seguidos para restaurar sistemas de informação e dados críticos para operação.
Fornecer evidências de que o plano de continuidade de negócios e o plano de recuperação de desastres estão sendo revisados pelo menos a cada 12 meses para garantir que permaneçam válidos e eficazes durante situações adversas.
Fornecer evidências de que o plano de continuidade de negócios é atualizado com base na revisão anual do plano, todo o pessoal relevante recebendo treinamento sobre suas funções e responsabilidades atribuídas nos planos de contingência, o(s) plano(s) está(ão) sendo testado(s) por meio de exercícios de continuidade de negócios ou recuperação de desastres, os resultados dos testes são documentados, incluindo lições aprendidas com o exercício ou mudanças organizacionais.

Manuseio de dados, segurança e privacidade

Para garantir a segurança dos dados, todos os dados em trânsito entre o usuário do aplicativo, os serviços intermediários e os sistemas ISV devem ser criptografados usando a conexão TLS (Transport Layer Security). No mínimo, o TLS 1.2 é necessário, sendo o TLS 1.3 ou superior altamente recomendado. Para obter mais detalhes, consulte o Apêndice A.

Para aplicativos que recuperam ou armazenam dados do Microsoft 365, é obrigatório implementar um esquema de criptografia de armazenamento de dados. Isso deve estar alinhado com as especificações descritas no Apêndice B.

Controles

Família de Controle Controls
Dados em trânsito Forneça evidências de que valide se a configuração do TLS é TLS1.2 ou superior dentro dos requisitos de configuração de perfil do TLS e que um inventário de chaves e certificados confiáveis é mantido e mantido.
Fornecer evidências mostram que a compactação TLS está desabilitada para todos os serviços voltados para o público que lidam com solicitações da Web para evitar a taxa de compactação Vazamento de informações facilitado (CRIME) e o TLS HSTS está habilitado e configurado para 180 dias em todos os sites.
Dados em repouso Forneça evidências de que os dados em repouso são criptografados de acordo com os requisitos do perfil de criptografia, usando algoritmos de criptografia como AES (Advanced Encryption Standard), RSA e Twofish com tamanhos de chave de criptografia de 256 bits ou mais.
Retenção, backup e descarte de dados Fornecer prova de que um período aprovado de retenção de dados é formalmente estabelecido e documentado.
Forneça evidências de que os dados são retidos apenas pelo período de retenção definido, conforme discutido no controle anterior.
Fornecer evidências de que existem processos para excluir dados com segurança após o período de retenção.
Forneça evidências de que um sistema de backup automatizado está em vigor e configurado para realizar backups em horários agendados.
Forneça evidências de que as informações de backup são testadas de acordo com o procedimento de agendamento de backup e restauradas periodicamente para confirmar a confiabilidade e a integridade dos dados.
Forneça evidências de que controles de acesso apropriados e mecanismos de proteção (ou seja, backups imutáveis) sejam implementados para garantir que os backups/instantâneos do sistema sejam protegidos contra acesso não autorizado e para garantir a confidencialidade, integridade e disponibilidade dos dados do backup.
Gerenciamento de Acesso a Dados Fornecer evidências de que uma lista de usuários com acesso a dados e/ou chaves de criptografia é mantida. Incluindo a justificativa comercial para cada pessoa e a confirmação, essa lista de usuários foi formalmente aprovada com base nos privilégios de acesso necessários para sua função de trabalho e os usuários são configurados com os privilégios descritos na aprovação.
Fornecer evidências de que é mantida uma lista de todos os terceiros com os quais os dados são compartilhados e que existem acordos de compartilhamento de dados com todos os terceiros que consomem dados.
Privacidade Sua organização tem um sistema de gerenciamento de informações de privacidade (PIM) estabelecido, implementado e mantido que mantém o compromisso da liderança por meio de uma política ou outra forma de documentação/sistema computadorizado de como seus esforços de gerenciamento de informações de privacidade são mantidos para confidencialidade e integridade do sistema. Determina as funções, responsabilidades e autoridades de cada pessoa que mantém o sistema, incluindo Processadores e Controladores de PII.
Fornecer evidências de processos para verificar se a minimização de PII está ocorrendo, se a desidentificação e a exclusão de PII estão sendo feitas no final do período de processamento, se há controles para a transmissão de PII, incluindo qualquer confidencialidade, se existe registro de transferência de PII de um país/região para outro com consentimento expresso para fazê-lo.
RGPD Forneça evidências de que os titulares de dados são capazes de gerar SARs, que o ISV é capaz de identificar todos os locais dos dados dos titulares de dados ao responder a uma solicitação de SARs, que há um período de retenção para backups que permite que os clientes que solicitam a remoção de dados por meio de SARs sejam removidos à medida que os backups contínuos ao longo de um período são removidos (ciclo de vida das exclusões de backup mais antigas/regravadas).
Forneça o aviso de privacidade que deve conter todos os elementos necessários da seguinte forma: detalhes organizacionais (nome, endereço e outras informações pessoais identificáveis), o tipo de dados pessoais que estão sendo processados, por quanto tempo os dados pessoais serão mantidos, a legalidade do processamento de dados pessoais, direitos dos titulares dos dados; incluindo: direitos do titular dos dados, direito de ser informado, direito de acesso pelo titular dos dados, direito de apagamento, direito à restrição de processamento, direito à portabilidade de dados, direito de objeção, direitos em relação à tomada de decisão automatizada, incluindo criação de perfil.
HIPAA Forneça evidências de que: existe uma política para HIPAA e manuseio HIPAA em sua organização para funcionários, prestadores de serviços, fornecedores, etc. Verifique se nossa organização garante a confidencialidade, a integridade e a disponibilidade do ePH.
Verificar se você: fornece proteção contra usos ou divulgações razoavelmente previstos de tais informações que não são permitidos pela regra de privacidade, garantir a conformidade com a regra de segurança por sua força de trabalho. Fornecer um plano de backup de dados e recuperação de desastres sob 164.308 (a) (7) (ii) (A) e 164.308 (a) (7) (ii) (B).

Revisão da estrutura de conformidade externa opcional

Se sua organização já estiver em conformidade com estruturas de segurança externas, como ISO 27001, PCI-DSS, FedRAMP ou SOC 2 Tipo 2, você poderá optar por aproveitar essas certificações para atender a alguns dos controles de Certificação do Microsoft 365. Os analistas terão como objetivo alinhar suas estruturas de segurança externas existentes com os requisitos da Certificação Microsoft 365.

No entanto, se sua documentação de suporte não demonstrar que os controles da Certificação Microsoft 365 foram explicitamente avaliados como parte da auditoria ou avaliação da estrutura externa, você deverá fornecer evidências adicionais para verificar se esses controles estão em vigor.

Requisitos de documentação:

A documentação deve demonstrar claramente que o ambiente no escopo da Certificação Microsoft 365 está incluído no escopo das estruturas de segurança eternas. A validação dessas estruturas será realizada aceitando evidências de certificações válidas emitidas por auditores terceirizados credenciados e respeitáveis.

Esses auditores terceirizados devem ser membros de organismos internacionais de acreditação, como:

  • Certificações e Padrões de Conformidade para a ISO 27001

  • QSA (Avaliadores de Segurança da Qualidade) para PCI-DSS

Para obter detalhes adicionais, consulte as diretrizes e padrões específicos das estruturas externas relevantes para sua certificação.

A tabela abaixo descreve as estruturas necessárias e a documentação aceitas pelos analistas de certificação como parte do processo de validação.

Standard Requisitos
ISO 27001 Será necessária uma versão pública da Declaração de Aplicabilidade (SOA) e uma cópia do certificado ISO 27001 emitido. A SOA resume sua posição em cada um dos 114 controles de segurança da informação e será usada para identificar se alguma exclusão de controles não está satisfatoriamente detalhada no certificado ISO 27001. Se isso não puder ser determinado pela revisão da versão pública da SOA, o analista poderá precisar de acesso à SOA completa se a ISO 27001 for usada para validar alguns dos controles de segurança da Certificação Microsoft 365. Além de validar o escopo das atividades de avaliação da ISO 27001, os analistas também confirmarão a validade da empresa de auditoria, conforme descrito acima.
PCI DSS Um documento válido de Atestado de Conformidade (AOC) de Nível 1 deve ser fornecido identificando claramente o aplicativo no escopo e os componentes do sistema. Um AOC de autoavaliação não será aceito como evidência de atender às melhores práticas de segurança. O AOC será usado para determinar quais controles da Especificação de Certificação do Microsoft 365 foram avaliados e confirmados como parte da avaliação do PCI DSS.
SOC 2 O relatório SOC 2 (Tipo II) deve ser atualizado (emitido nos últimos 15 meses e o período de tempo declarado iniciado nos últimos 27 meses) para ser usado como prova de conformidade com qualquer um dos controles de avaliação dentro desta estrutura de Certificação Microsoft 365.
FedRAMP O Programa Federal de Gerenciamento de Riscos e Autorizações (FedRAMP) é um programa do governo federal dos EUA estabelecido em 2011. Ele fornece uma abordagem padronizada para avaliação de segurança, autorização e monitoramento contínuo para produtos e serviços em nuvem.
Framework Considerações adicionais
ISO 27001 Apêndice C: Coleta de evidências – Deltas para a ISO 27001.
PCI-DSS Apêndice D: Coleta de Evidências - Deltas para PCI-DSS.
SOC 2 Apêndice E: Coleta de Evidências - Deltas para SOC 2.

Observação

Embora padrões ou estruturas de segurança externos possam ser enviados como evidência de suporte para atender a determinados controles da Certificação Microsoft 365, obter a Certificação Microsoft 365 requer uma avaliação separada. Obter a certificação do Microsoft 365 não significa que o aplicativo passou totalmente nas auditorias dessas estruturas externas. A Especificação de Certificação do Microsoft 365 concentra-se em um subconjunto específico de controles derivados dessas estruturas para fornecer à Microsoft um nível mais alto de garantia em relação à postura de segurança do seu aplicativo.

Requisitos para usar estruturas de conformidade externas

Requisitos para usar Estruturas de conformidade externas

O ambiente no escopo e todos os processos de negócios de suporte devem ser incluídos no escopo de qualquer estrutura de conformidade de segurança externa com suporte. Estes devem ser claramente documentados na documentação fornecida.

As estruturas de conformidade de segurança externa devem ser atualizadas, o que significa que devem ser avaliadas nos últimos 12 meses (ou 15 meses se uma reavaliação contínua puder ser verificada com evidências de suporte)

As avaliações de conformidade da Segurança Externa devem ser conduzidas por uma empresa independente e credenciada.

Critérios de validação da estrutura externa

Avaliação SOC 2 Tipo 2

  • O relatório SOC 2 deve ser um relatório Tipo 2
  • A auditoria SOC 2 deve incluir o ambiente M365 que está sendo avaliado
  • A auditoria SOC 2 deve ser concluída nos últimos 12 meses
  • Os controles devem ser apresentados de forma justa e projetados adequadamente, conforme exigido para um relatório de tipo 2
  • A auditoria SOC 2 deve ser conduzida por um terceiro externo qualificado
  • Os procedimentos de teste devem confirmar que os controles de segurança estão em vigor e devidamente validados pelo auditor.

Avaliação ISO 27001

  • A auditoria ISO 27001 deve incluir o ambiente especificado nessa avaliação do M365
  • O certificado ISO 27001 deve estar atualizado e aplicável à entidade
  • A avaliação da ISO 27001 deve ser conduzida por um terceiro externo credenciado (auditorias internas da ISO 27001 não são aceitas)
  • A avaliação da ISO 27001 deve ser concluída nos últimos 12 meses

Avaliação PCI-DSS

  • O Documento AOC deve definir claramente o ambiente do M365 que está sendo avaliado
  • O AOC deve estar atualizado
  • O AOC deve ser assinado pelo QSA e pela entidade

Saiba mais

  • Last updated on