Visão geral do guia de evidências de exemplo de certificação do Microsoft 365

  • Artigo

Este guia de evidência de exemplo ajuda os ISVs a produzir as evidências corretas necessárias para concluir a Certificação do Microsoft 365. Este documento inclui a intenção de cada controle e todas as sub-partes de um controle, maneiras potenciais em que as evidências poderiam ser coletadas para controles com documentos de evidência de exemplo, políticas e capturas de tela. Além disso, este guia fornece assistência sobre como estruturar evidências enviadas.

Todos os exemplos compartilhados neste documento não representam a única evidência que pode ser usada para provar que os controles estão sendo atendidos. Estas são diretrizes para o tipo de evidência que pode ajudar os analistas de certificação a decidir se o controle foi atendido pelo ISV.

Observe: as interfaces reais, as capturas de tela e a documentação usadas para atender aos requisitos de certificação variam dependendo do uso do produto, da instalação do sistema e dos processos internos. Observe que, quando a política ou a documentação do procedimento são necessárias, o ISV deve enviar versões completas dos documentos reais e não capturas de tela, como talvez mostrado em alguns dos exemplos.

Todas as capturas de tela que devem ser enviadas devem ser capturas de tela inteira com qualquer URL, usuário conectado (verifique se o nome do usuário conectado está visível na captura de tela) com o carimbo de data e hora incluídos. Para sistemas baseados em Linux, inclua essas informações com/sobre as evidências de controle usando o prompt de comando para produzi-la.

Todas as evidências quando enviadas precisam ter menos de 3 meses de idade para garantir que, quando você concluir a certificação, as evidências ainda sejam relevantes e não obsoletas. Se isso não for seguido, você poderá ser solicitado a coletar novas evidências.

Observe também: nenhuma API beta pode ser usada para fins dessa certificação ou qualquer exemplo usado nesse processo.

É recomendável que você siga essas diretrizes para evitar que sua avaliação seja adiada devido a evidências insuficientes.

Observação

Se você iniciou a Certificação microsoft 365 antes de 12 de dezembro de 2023, consulte o guia de evidências de exemplo herdado.

Estrutura de certificação do Microsoft 365

A certificação foi estruturada em torno de três domínios de segurança:

Um teste de penetração é necessário para certificação e será revisado no domínio de segurança do aplicativo. Consulte as seções 3 e 4 da estrutura de envio de evidências para obter mais informações.

Os domínios de segurança são divididos em grupos de controle para ajudar os ISVs a entender a estrutura das tarefas e dividir a coleção de evidências em peças pequenas e gerenciáveis. Esses grupos de controle foram alinhados com estruturas comuns de resourcing empresarial para ajudar a identificar equipes internas para obter suporte, ao mesmo tempo em que permitem que as equipes trabalhem em paralelo para acelerar o processo de coleta de evidências.

Controles(s): Descrição da Atividade de Avaliação – Esses controles e número associado (No.) são retirados diretamente da lista de verificação de certificação do Microsoft 365.

Intenção: a intenção de por que o controle de segurança está incluído no programa e o risco específico que ele visa mitigar. A esperança é que essas informações forneçam aos ISVs o raciocínio por trás do controle para entender melhor os tipos de evidências que precisam ser coletadas e o que os ISV devem prestar atenção e ter consciência e compreensão na produção de suas evidências.

Diretrizes de evidência de exemplo: fornecidas para ajudar a orientar as tarefas de coleta de evidências na Certificação do Microsoft 365. Isso permite que os ISV's vejam claramente exemplos do tipo de evidência que pode ser usado pelo Analista de Certificação que o usará para criar uma determinação confiante de que um controle está em vigor e mantido – não é de forma alguma exaustivo por natureza.

Exemplo de evidência: esta seção fornece capturas de tela de exemplo e imagens de possíveis evidências capturadas em cada um dos controles dentro da Certificação Microsoft 365, especificamente para os Domínios de Segurança Operacional e Segurança de Dados e Segurança de Privacidade. Observe que qualquer informação com setas vermelhas e caixas nos exemplos é para ajudar ainda mais sua compreensão dos requisitos necessários para atender a qualquer controle.

Estrutura de envio de evidências

O envio de evidências contra todos os controles aplicáveis será realizado por meio do Partner Center, exceto para avaliações em suporte às certificações de registro de conformidade e contact center da Microsoft. Normalmente, eles precisarão passar por um processo manual, ignore esta seção e consulte a próxima seção sobre como concluir a certificação se você estiver gravando de conformidade & contact center.

Para garantir que os analistas de certificação possam identificar facilmente as evidências fornecidas e revisá-las com êxito, siga estas recomendações:

  1. Para cada uma das seções, verifique se a evidência é claramente rotulada antes do envio. Se houver mais de uma evidência por controle, coloque a evidência em um único arquivo word/pdf, incluindo um comentário sobre o que as evidências estão mostrando. Se a evidência consiste em vários documentos word/pdf, ou seja, com suporte à documentação, carregue-as como arquivos individuais. Não os coloque em um arquivo zip para carregar no Partner Center, pois não aceitamos arquivos zip devido ao risco de malware.

  2. Todas as informações de estrutura externa devem ser dadas na íntegra sem redações (só permitiremos que o nome parcial de indivíduos seja redigido desses relatórios, pois isso se enquadraria em PII (Informações Pessoais Identificáveis)) - Todas as partes dos relatórios devem ser incluídas, por exemplo, a Instrução ISO 27001 de Aplicabilidade (SOA) e Certificado, o relatório completo do SOC 2 Tipo 2 e/ou o Atestado de Conformidade PCI-DSS completo (AOC). Todos os documentos são cobertos pelo contrato do Microsoft Partner Center na Cláusula 7.

A seção 7(a) inclui o seguinte NDA:

Imagem do documento NDA

  1. Um relatório de teste de penetração não redigido completo deve ser enviado por meio do Partner Center quando solicitado - OBSERVE SE isso não for fornecido, os analistas de certificação não poderão concluir a auditoria para sua Certificação microsoft 365.

  2. Teste de penetração de aplicativos Web e infraestrutura interna e externa – um relatório de teste de penetração é necessário para todos os ambientes de hospedagem.

    • Para IaaS (Infraestrutura como serviço) ou ISV hospedado (local, data center privado) é necessário um teste interno e externo de infraestrutura e aplicativo Web.

    • Para Plataforma como serviço 'PaaS/Serverless', o teste de caneta deve ser do seu aplicativo Web e da infraestrutura de suporte subjacente.

Observação: teste de penetração complementar – o teste gratuito de caneta da Microsoft é limitado apenas a doze dias. Se fizermos o escopo do teste de caneta, seu aplicativo exigirá mais de 12 dias de teste, então você será solicitado a pagar pelos dias adicionais, além disso, se você precisar de testes de caneta fora do horário, isso também incorrerá em custos adicionais. O serviço de teste de caneta fornecido também é limitado a um teste de caneta (incluindo um novo teste) por ano, por exemplo, se você tiver seu teste de penetração realizado em 1º de setembro de 2022, você não poderá obter outro até 31 de agosto de 2023.

Isso é aplicável a todas as tentativas de envio, o que significa que isso se aplica ao ciclo de envio atual, bem como se você decidir fechar o envio atual e reiniciar o processo mais tarde no mesmo ano, você não terá direito a um teste de caneta adicional, pois um já havia sido realizado para você.

  1. Todos os ISVs devem concluir o envio inicial do documento dentro de 14 dias (isso inclui quaisquer atrasos e encaminhamentos com seu analista) depois de receberem o email de início do tíquete da equipe de administração da Microsoft. O prazo de 14 dias é para conclusão completa, revisão e movimentação do envio para o estágio completo de evidências. Os ISVs devem estar verificando regularmente para ver se o analista precisou de alterações ou solicitou informações ou documentos adicionais. Durante o período de 14 dias, os ISVs podem enviar as informações necessárias quantas forem necessárias, no entanto, tenha em mente que, se o envio não estiver sendo trabalhado ativamente, ele será considerado obsoleto e fechado no Partner Center e a certificação precisará ser reiniciada. Em determinadas circunstâncias, um ISV pode ser fornecido até 30 dias para conclusão. Se um ISV não conseguir concluir o envio inicial do documento dentro do prazo determinado, o envio será fechado.

Além disso, todos os ISVs devem concluir sua certificação dentro de 60 dias após a transferência da fase inicial de envio do documento para a fase completa de coleta de evidências. Isso inclui quaisquer revisões e comentários fornecidos pelo assessor/auditor durante todo o processo. O prazo de 60 dias é para conclusão completa, revisão e qa final de suas evidências, isso significa que os ISVs devem enviar suas evidências pelo menos duas semanas antes da data de conclusão para garantir que a certificação seja concluída a tempo. Durante o período de 60 dias, os ISVs podem enviar evidências ao Partner Center quantas vezes for necessário. No entanto, tenha em mente que o envio final, conforme indicado, é pelo menos duas semanas antes da data de conclusão para dar aos analistas de certificação tempo para examinar e a QA o envio. Depois que seus 60 dias terminarem, os ISVs serão necessários para iniciar o processo novamente.

Se surgirem problemas durante o processo de certificação, o analista de certificação poderá conceder uma possível extensão para preocupações válidas. Um analista pode, a seu critério, conceder uma extensão de tempo até um máximo de 30 dias adicionais se os ISVs forem vistos trabalhando ativamente em seu envio. Observe que, se for dada uma extensão de 0 a 30 dias, o ISV precisará garantir que as evidências estão disponíveis para revisão duas semanas antes da data de término da extensão.

Se concedida uma extensão, mas as evidências tiverem mais de 3 meses de idade, ela poderá potencialmente falhar, pois essa evidência talvez potencialmente considerada como obsoleta devido ao tempo entre quando foi fornecida e a QA final, o que significará que novas evidências para esse controle serão necessárias. Depois que o tempo de extensão terminar, não haverá mais extensões e espera-se que o ISV envie suas evidências (pelo menos duas semanas antes do final da extensão), se não for enviado, o envio será classificado como com falha e será fechado. Se nenhum trabalho ativo no envio tiver começado a qualquer momento durante os 60 dias iniciais ou durante o tempo de extensão (até 30 dias), o envio será classificado como abandonado e será fechado.

Se o envio tiver sido classificado como abandonado, o ISV precisará reiniciar o processo com um novo atestado e novas evidências, pois as evidências atuais serão consideradas obsoletas. Observe que os ISVs têm permissão para apenas um envio em um ano. Se, por qualquer motivo, um ISV abandonar o processo depois de estar na fase completa de coleta de evidências e sua apresentação tiver sido marcada como abandonada, eles não poderão reiniciar o processo até o ano seguinte.

Estrutura de envio manual de evidências – registro de conformidade & contact center

Para ajudar a garantir que os analistas de certificação possam identificar facilmente as evidências fornecidas e revisá-las com êxito, siga estas recomendações para a estrutura de envio de evidências se enviar manualmente por solicitação da equipe de certificação.

  1. Crie um único documento, que pode ser facilmente revisado (ou seja, em Word ou PDF), para cada grupo de controle de segurança (por exemplo, antivírus, gerenciamento de patch etc.).

  2. Nomeie o único documento após o Grupo de Controle de Segurança para deixar claro o que o documento contém.

  3. Adicione seus artefatos de evidência a ele, referencie a documentação de suporte da sua organização que dá suporte ao grupo de controle e quaisquer anotações adicionais para o analista de certificação explicando qual é o artefato e como essa evidência atende ao controle (isso ajudará seus Analistas de Certificação se você nomear as imagens com seus números de controle, ou seja, Segurança de Dados e Controle de Privacidade nº 1).

Observação: lembre-se de que, quando a amostragem for usada, os artefatos precisam ser retirados de cada dispositivo no conjunto de exemplos, verifique se o artefato também exibe o nome do sistema para validar que o artefato é do dispositivo que está sendo avaliado e que nenhum dado é obscurecido ou redigido.

  1. Todas as informações de estrutura externa devem ser dadas na íntegra sem redações (só permitiremos que o nome dos indivíduos seja redigido desses relatórios à medida que estes se enquadram no PII) - Todas as partes dos relatórios devem ser incluídas, por exemplo, Declaração ISO 27001 de Aplicabilidade (SOA) e Certificado, relatório completo SOC 2 Tipo 2 e/ou Atestado completo de Conformidade PCI-DSS (AOC) Relatório HIPAA completo ou FedRAMP. Todos os documentos são cobertos pelo contrato do Microsoft Partner Center na seção 7.

A seção 7(a) inclui o seguinte NDA:

Imagem do documento NDA

  1. Um relatório completo de teste de penetração não redigido deve ser enviado ao analista de certificação quando solicitado - OBSERVE SE isso não for fornecido, o analista de certificação não poderá concluir sua Certificação do Microsoft 365.

  2. Infraestrutura interna e externa e aplicativo Web – um relatório de teste de penetração é necessário para todos os ambientes de hospedagem.

    • Para IaaS (Infraestrutura como serviço) ou ISV hospedado (local, data center privado) é necessário um teste interno e externo de infraestrutura e aplicativo Web.

    • Para Plataforma como serviço 'PaaS/Serverless', o teste de caneta deve ser do seu aplicativo Web e da infraestrutura de suporte subjacente.

Teste de penetração complementar – Observe que o teste gratuito de caneta da Microsoft é limitado apenas a doze dias. Se um aplicativo exigir mais de 12 dias de teste, o ISV será solicitado a pagar pelos dias adicionais. Além disso, se o ISV exigir testes de caneta fora do horário comercial normal com base na localização do auditor, isso também incorrerá em custos adicionais. O serviço de teste de caneta fornecido é limitado a um teste de caneta gratuito (incluindo um novo teste) por ano por tentativa de envio.

  1. Todos os ISVs devem concluir o envio inicial do documento dentro de 14 dias (isso inclui quaisquer atrasos e encaminhamentos com seu analista) depois de receberem o email de início do tíquete da equipe de administração da Microsoft. O prazo de 14 dias é para conclusão completa, revisão e movimentação do envio para o estágio completo de evidências. Os ISVs devem estar verificando regularmente para ver se o analista precisou de alterações ou solicitou informações ou documentos adicionais. Durante o período de 14 dias, os ISVs podem enviar as informações necessárias quantas forem necessárias, no entanto, tenha em mente que, se o envio não estiver sendo trabalhado ativamente, ele será considerado obsoleto e fechado no Partner Center e a certificação precisará ser reiniciada. Em determinadas circunstâncias, um ISV pode ser fornecido até 30 dias para conclusão. Se um ISV não conseguir concluir o envio inicial do documento dentro do prazo determinado, o envio será fechado.

Além disso, todos os ISVs devem concluir sua certificação dentro de 60 dias após a transferência da fase inicial de envio do documento para a fase completa de coleta de evidências. Isso inclui quaisquer revisões e comentários fornecidos pelo assessor/auditor durante todo o processo. O prazo de 60 dias é para conclusão completa, revisão e qa final de suas evidências, isso significa que os ISVs devem enviar suas evidências pelo menos duas semanas antes da data de conclusão para garantir que a certificação seja concluída a tempo. Durante o período de 60 dias, os ISVs podem enviar evidências ao Partner Center quantas vezes for necessário. No entanto, tenha em mente que o envio final, conforme indicado, é pelo menos duas semanas antes da data de conclusão para dar aos analistas de certificação tempo para examinar e a QA o envio. Depois que seus 60 dias terminarem, os ISVs serão necessários para iniciar o processo novamente.

Se surgirem problemas durante o processo de certificação, o analista de certificação poderá conceder uma possível extensão para preocupações válidas. Um analista pode, a seu critério, conceder uma extensão de tempo até um máximo de 30 dias adicionais se os ISVs forem vistos trabalhando ativamente em seu envio. Observe que, se for dada uma extensão de 0 a 30 dias, o ISV precisará garantir que as evidências estão disponíveis para revisão duas semanas antes da data de término da extensão.

Se concedida uma extensão, mas as evidências tiverem mais de 3 meses de idade, ela poderá potencialmente falhar, pois essa evidência talvez potencialmente considerada como obsoleta devido ao tempo entre quando foi fornecida e a QA final, o que significará que novas evidências para esse controle serão necessárias. Depois que o tempo de extensão terminar, não haverá mais extensões e espera-se que o ISV envie suas evidências (pelo menos duas semanas antes do final da extensão), se não for enviado, o envio será classificado como com falha e será fechado. Se nenhum trabalho ativo no envio tiver começado a qualquer momento durante os 60 dias iniciais ou durante o tempo de extensão (até 30 dias), o envio será classificado como abandonado e será fechado.

Se o envio tiver sido classificado como abandonado, o ISV precisará reiniciar o processo com um novo atestado e novas evidências, pois as evidências atuais serão consideradas obsoletas. Observe que os ISVs têm permissão para apenas um envio em um ano. Se, por qualquer motivo, um ISV abandonar o processo depois de estar na fase completa de coleta de evidências e sua apresentação tiver sido marcada como abandonada, eles não poderão reiniciar o processo até o ano seguinte.

Criando a estrutura da pasta para a gravação de conformidade & contact center

Siga estas instruções para criar a estrutura de pasta necessária para que o analista examine as evidências fornecidas.

  1. Conclua o envio inicial do documento para que os controles possam ser escopo. Forneça o máximo de detalhes possível e que o diagrama de diagrama de arquitetura e o diagrama de fluxo de dados também tenham o mesmo nível de detalhes.

  2. Crie uma pasta interna ou online e adicione todos os documentos a ela.

    • Rotule a pasta compartilhada real Microsoft Certification

    • Adicione suas informações de Envio de Documento Inicial à pasta Microsoft Certification em uma pasta chamada IDS.

    • Dentro da pasta Certificação, crie quatro pastas com os seguintes nomes:

      • Segurança do Aplicativo (isso é para suas informações de Teste de Caneta)

      • Conformidade (para suas estruturas externas, como SOC 2)

      • Segurança Operacional (sistema operacional)

      • Privacidade do & de Segurança de Dados (DS&P)

    • Dentro das pastas do sistema operacional e do DS&P, crie grupos de controle para cada conjunto de controles, ou seja, Malware, Patch etc. onde você pode adicionar documentos para cada um dos controles (se você quiser ser específico, você pode criar uma pasta para cada controle individual, facilitando o rastreamento de evidências pelo nome do controle – nesse caso, chame estas pastas de Controle X onde X representa o número de controle). Observe que você não poderá criar a estrutura de pasta secundária até que seus controles tenham sido escopo.

Um exemplo de uma estrutura de pastas Pastas raiz:

Uma estrutura de pastas Pastas Raiz

Subpastas dentro da pasta "Evidência":

Subpastas dentro da pasta Evidências

  1. Depois de carregar documentos no compartilhamento, dê permissão à pasta compartilhada e envie um email ao analista de certificação com os detalhes. Envie senhas em um email separado.

  2. Ao reunir evidências, lembre-se de fazer capturas de tela inteira mostrando qualquer usuário conectado, URL e carimbo de data e hora. Se usar o Linux, isso poderá ser feito no prompt de comando. Forneça qualquer explicação quando necessário para cada controle e lembre-se de que para políticas é necessária uma cópia completa da política e não snippets ou capturas de tela.

  3. Faça referência a este documento para ajudar a entender o controle e o tipo de evidência que precisamos.

  4. Qualquer teste de caneta que possa ser necessário não será agendado e você não receberá a documentação para iniciar o processo até ter 50% dos controles aprovados. O teste de caneta será gratuito por apenas 12 dias, no entanto, se o teste de caneta for executado ao longo de 12 dias, você será obrigado a pagar os dias adicionais antecipadamente antes do início do teste.

  5. Depois de receber uma cópia de seus controles com escopo para coletar evidências contra os controles, o ticker será iniciado – você receberá um email nesse sentido e terá 60 dias para concluir todo o processo de certificação, incluindo o teste de caneta.

  6. Tente enviar a primeira iteração dos controles dentro de 30 dias para permitir que quaisquer problemas sejam identificados e revisões solicitadas antes do esgotamento de 60 dias.

Saiba mais