Nota
O acesso a esta página requer autorização. Pode tentar iniciar sessão ou alterar os diretórios.
O acesso a esta página requer autorização. Pode tentar alterar os diretórios.
Este guia de evidências de exemplo ajuda os ISVs a produzir as evidências corretas necessárias para concluir a Certificação Microsoft 365. Este documento inclui a intenção de cada controle e todas as subpartes de um controle, possíveis maneiras pelas quais as evidências podem ser coletadas para controles com documentos, políticas e capturas de tela de evidências de exemplo. Além disso, este guia fornece assistência sobre como estruturar as evidências enviadas.
Quaisquer 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 podem ajudar os analistas de certificação a decidir se o controle foi atendido pelo ISV.
Observação: as interfaces, capturas de tela e documentação reais usadas para atender aos requisitos de certificação variam de acordo com o uso do produto, a configuração do sistema e os processos internos. Onde a documentação de política ou procedimento for necessária, o ISV deverá 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 a serem enviadas devem ser capturas de tela inteira com qualquer URL, usuário conectado (certifique-se de que o nome do usuário conectado esteja visível na captura de tela) com o carimbo de data e hora incluído. Para sistemas baseados em Linux, inclua essas informações com/sobre a evidência de controle usando o prompt de comando para produzi-la.
TODAS as evidências, quando enviadas, precisam ter menos de 3 meses 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 desta certificação ou qualquer amostra usada neste processo.
Recomenda-se que você siga essas diretrizes para evitar que sua avaliação seja adiada devido a evidências insuficientes.
Estrutura de certificação do Microsoft 365
A certificação foi estruturada em torno de três domínios de segurança:
Segurança do aplicativo (incluindo verificações de conectividade, quando necessário)
Um teste de penetração é necessário para a certificação e será revisado no domínio Segurança de Aplicativos. Mais detalhes sobre esse requisito podem ser encontrados nas Seções 3 e 4 da estrutura de envio de evidências.
Para agilizar o processo de certificação, os domínios de segurança são divididos em grupos de controle. Esses grupos de controle ajudam os ISVs (fornecedores independentes de software) a gerenciar a coleta de evidências em etapas menores e mais estruturadas. Eles se alinham com estruturas comuns de recursos corporativos, tornando mais fácil para as equipes internas coordenar esforços e acelerar a coleta de evidências.
Cada controle está associado a uma Descrição da Atividade de Avaliação, derivada diretamente das listas de verificação da Certificação do Microsoft 365. Isso inclui a intenção do controle de segurança, explicando por que ele é necessário e os riscos específicos que visa mitigar. O objetivo é fornecer aos ISVs uma compreensão clara do raciocínio por trás de cada controle, permitindo-lhes determinar o tipo de evidência necessária e garantindo a conscientização ao preparar sua submissão.
Para ajudar na coleta de evidências, foram fornecidas Diretrizes de Evidências de Exemplo. Essas diretrizes oferecem clareza sobre os tipos de evidências aceitáveis que os analistas de certificação podem usar para avaliar se um controle está em vigor e é mantido. No entanto, esses exemplos não são exaustivos e servem como uma referência e não como um requisito estrito.
A seção Exemplo de evidência inclui capturas de tela e imagens de exemplo que demonstram possíveis envios de evidências em vários controles dentro da estrutura de certificação do Microsoft 365. Isso é particularmente relevante para os domínios Segurança Operacional e Tratamento de Dados, Segurança e Privacidade. Todas as imagens de exemplo com setas ou caixas vermelhas destinam-se a realçar detalhes importantes e garantir uma melhor compreensão dos requisitos necessários para atender a controles específicos.
Estrutura de envio de evidências
O envio de evidências em relação a todos os controles aplicáveis será realizado por meio do Partner Center, com exceção para avaliações de registros de conformidade da Microsoft e certificações do contact center . Eles podem passar por um processo manual, pule esta seção e veja a próxima seção sobre como concluir a certificação se você estiver registrando conformidade ou contact center.
Para garantir que os analistas de certificação possam identificar facilmente as evidências fornecidas e revisá-las com sucesso, siga estas recomendações:
Para cada uma das seções, certifique-se de que as evidências sejam claramente rotuladas antes de serem enviadas. Se houver mais de uma evidência por controle, coloque a evidência em um único arquivo de palavra/pdf, incluindo um comentário do que a evidência está mostrando. Se a evidência consistir em vários documentos word/pdf, ou seja, documentação de suporte, carregue-os como arquivos individuais. Não os coloque em um arquivo zip para serem carregados no Partner Center, pois não aceitamos arquivos zip devido ao risco de malware.
Todas as informações da estrutura externa devem ser fornecidas na íntegra, sem redações (permitiremos que apenas o nome parcial dos indivíduos seja redigido desses relatórios, pois isso se enquadraria nas Informações de Identificação Pessoal (PII)) - Todas as partes dos relatórios devem ser incluídas, por exemplo, Declaração de Aplicabilidade (SOA) e Certificado ISO 27001, relatório SOC 2 Tipo 2 completo e/ou Atestado de Conformidade PCI-DSS (AOC) completo. Todos os documentos são cobertos pelo contrato do Microsoft Partner Center sob a Cláusula 7.
A Seção 7 (a) inclui o seguinte NDA:
Um relatório de teste de penetração completo e não editado deve ser enviado ao Partner Center quando solicitado – OBSERVE que, se isso não for fornecido, os analistas de certificação não poderão concluir a auditoria para sua Certificação Microsoft 365.
Teste de penetração de infraestrutura interna e externa e aplicativo da 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 (no local, data center privado) é necessário um teste interno e externo de infraestrutura e aplicativo Web.
Para Plataforma como Serviço "PaaS/Sem Servidor", o teste de penetração deve ser do seu aplicativo Web e da infraestrutura de suporte subjacente.
Observação: Teste de penetração gratuito – O teste de penetração gratuito da Microsoft é limitado a apenas doze dias. Se, ao definir o escopo do seu teste de penetração, seu aplicativo exigir mais de 12 dias de teste, você será solicitado a pagar pelos dias adicionais. Se você exigir o teste de penetração fora do horário comercial, isso também incorrerá em custos adicionais. O serviço de teste de penetração fornecido também é limitado a um teste de penetração (incluindo um reteste) por ano, por exemplo, se você realizou seu teste de penetração em 1º de setembro de 2025, não poderá obter outro até 31 de agosto de 2026.
Isso se aplica a todas as tentativas de envio, o que significa que isso se aplica ao seu ciclo de envio atual, bem como se você decidir encerrar seu envio atual e reiniciar o processo posteriormente no mesmo ano, você não terá direito a um teste de penetração adicional, pois um já havia sido realizado para você.
- Todos os ISVs devem concluir o envio inicial do documento dentro de 14 dias (isso inclui qualquer conversa com seu analista) depois de receberem o email de início de tíquete da equipe de administração da Microsoft. O prazo de 14 dias é para a conclusão completa, revisão e mudança do envio para o estágio completo de evidências. Os ISVs devem verificar regularmente para ver se seu analista exigiu alguma alteração ou solicitou informações ou documentos adicionais. Durante o período de 14 dias, os ISVs podem enviar as informações necessárias quantas vezes forem necessárias. Lembre-se de 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. Sob certas circunstâncias, um ISV pode ser fornecido até 30 dias para a conclusão. Se um ISV não conseguir concluir o envio inicial do documento dentro do prazo determinado, seu envio será encerrado.
Além disso, todos os ISVs devem concluir sua certificação dentro de 60 dias após seu envio, sendo movido do estágio inicial de envio de documentos para o estágio de coleta completa de evidências. Isso inclui quaisquer revisões e feedback fornecidos pelo avaliador/auditor ao longo do processo. O prazo de 60 dias é para a conclusão completa, revisão e Q/A 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 forem necessárias. O envio final é exigido duas semanas antes da data de conclusão para dar aos analistas de certificação tempo para revisar e fazer perguntas e respostas sobre o envio. Após o término dos 60 dias, os ISVs serão obrigados a iniciar o processo novamente.
Se surgirem problemas durante o processo de certificação, o analista de certificação poderá conceder uma extensão potencial para questõ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 estiverem trabalhando ativamente em seu envio. Observe que, se for concedida uma prorrogação de 0 a 30 dias, o ISV precisará garantir que as evidências estejam disponíveis para revisão duas semanas antes da data de término da prorrogação.
Se for concedida uma prorrogação, mas a evidência tiver mais de 3 meses, ela pode falhar no Q/D, pois essa evidência pode ser considerada obsoleta devido ao período de tempo entre quando foi fornecida e o Q/A final, o que significa que novas evidências para esse (s) controle (s) serão necessárias. Assim 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 reprovado e será encerrado. Se nenhum trabalho ativo sobre a submissão tiver sido iniciado a qualquer momento durante os 60 dias iniciais ou durante o tempo de extensão (até 30 dias), a submissão será classificada como abandonada e encerrada.
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 por ano. Se, por qualquer motivo, um ISV abandonar o processo quando estiver no estágio completo de coleta de evidências e seu envio tiver sido marcado como abandonado, ele não poderá 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 sucesso, siga estas recomendações para a estrutura de envio de evidências se enviar manualmente por solicitação da equipe de certificação.
Crie um único documento, que possa ser facilmente revisado (ou seja, em Word ou PDF), para cada grupo de controle de segurança (por exemplo, antivírus, gerenciamento de patches etc.).
Nomeie o documento único com o nome do Grupo de Controle de Segurança para deixar claro o que o documento contém.
Adicione seus artefatos de evidência a ele, faça referência à documentação de suporte da sua organização que dá suporte ao grupo de controle e quaisquer notas adicionais para o analista de certificação explicando o que é o artefato e como essa evidência atende ao controle (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 No.1).
Observação: lembre-se de que, quando a amostragem é usada, os artefatos precisam ser obtidos de cada dispositivo no conjunto de amostras, certifique-se de que o artefato também exiba o nome do sistema para validar se o artefato é do dispositivo que está sendo avaliado e se nenhum dado é obscurecido ou redigido.
- Todas as informações da estrutura externa devem ser fornecidas na íntegra, sem redações (só permitiremos que o nome dos indivíduos seja redigido desses relatórios, pois eles se enquadram nas PII) - Todas as partes dos relatórios devem ser incluídas, por exemplo, Declaração de Aplicabilidade (SOA) e Certificado ISO 27001, relatório SOC 2 Tipo 2 completo e/ou Atestado de Conformidade PCI-DSS (AOC) completo 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:
Um relatório completo de teste de penetração não editado deve ser enviado ao analista de certificação quando solicitado - OBSERVE que, se isso não for fornecido, o analista de certificação não poderá concluir sua Certificação Microsoft 365.
Infraestrutura interna e externa e aplicativo da 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 (no local, data center privado) é necessário um teste interno e externo de infraestrutura e aplicativo Web.
Para Plataforma como Serviço "PaaS/Sem Servidor", o teste de penetração deve ser do seu aplicativo Web e da infraestrutura de suporte subjacente.
Quando a IaC (Infraestrutura como Código) é usada para provisionar ambientes, o teste de penetração em preparo ou pré-produção só pode ser aceito quando o ISV puder demonstrar paridade determinística com a produção por meio dos mesmos modelos de IaC e pipelines de automação de CI/CD. O desvio de configuração manual ou diferenças de segurança específicas do ambiente entre a preparação e a produção não são aceitáveis.
Teste de penetração gratuito - Observe que o teste de penetração gratuito da Microsoft é limitado a apenas 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 penetração 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 penetração fornecido é limitado a um teste de penetração gratuito (incluindo um reteste) por ano por tentativa de envio.
- Todos os ISVs devem concluir o envio inicial do documento dentro de 14 dias (isso inclui qualquer retrocesso e avanço 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 a conclusão completa, revisão e mudança do envio para o estágio completo de evidências. Os ISVs devem verificar regularmente para ver se seu analista exigiu alguma alteração ou solicitou informações ou documentos adicionais. Durante o período de 14 dias, os ISVs podem enviar as informações necessárias quantas vezes forem necessárias, no entanto, lembre-se de 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. Sob certas circunstâncias, um ISV pode ser fornecido até 30 dias para a conclusão. Se um ISV não conseguir concluir o envio inicial do documento dentro do prazo determinado, seu envio será encerrado.
Além disso, todos os ISVs devem concluir sua certificação dentro de 60 dias após seu envio, sendo movido do estágio inicial de envio de documentos para o estágio de coleta completa de evidências. Isso inclui quaisquer revisões e feedback fornecidos pelo avaliador/auditor ao longo do processo. O prazo de 60 dias é para a conclusão completa, revisão e perguntas e respostas finais de suas evidências, isso significa que os ISVs devem enviar as 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 forem necessárias. O envio final é necessário pelo menos duas semanas antes da data de conclusão para dar aos analistas de certificação tempo para revisar e fazer Q/A do envio. Após o término dos 60 dias, os ISVs serão obrigados a iniciar o processo novamente.
Se surgirem problemas durante o processo de certificação, o analista de certificação poderá conceder uma extensão potencial para questõ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 estiverem trabalhando ativamente em seu envio. Observe que, se for concedida uma prorrogação de 0 a 30 dias, o ISV precisará garantir que as evidências estejam disponíveis para revisão duas semanas antes da data de término da prorrogação.
Se for concedida uma prorrogação, mas a evidência tiver mais de 3 meses, ela pode falhar no Q/D, pois essa evidência pode ser considerada obsoleta devido ao período de tempo entre quando foi fornecida e o Q/A final, o que significa que novas evidências para esse (s) controle (s) serão necessárias. Assim 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 reprovado e será encerrado. Se nenhum trabalho ativo sobre a submissão tiver sido iniciado a qualquer momento durante os 60 dias iniciais ou durante o tempo de extensão (até 30 dias), a submissão será classificada como abandonada e encerrada.
Se o envio tiver sido classificado como abandonado, o ISV precisará reiniciar o processo com novas evidências, pois as evidências atuais serão consideradas obsoletas. Observe que os ISVs têm permissão para apenas um envio por ano. Se, por qualquer motivo, um ISV abandonar o processo quando estiver no estágio completo de coleta de evidências e seu envio tiver sido marcado como abandonado, ele não poderá reiniciar o processo até o ano seguinte.
Criação da estrutura de pastas para registro de conformidade & contact center
Siga estas instruções para criar a estrutura de pastas necessária para que o analista examine as evidências fornecidas.
Conclua o envio inicial do documento para que os controles possam ser definidos. Forneça o máximo de detalhes possível e que o diagrama de arquitetura e o diagrama de fluxo de dados também tenham o mesmo nível de detalhe.
Crie uma pasta interna ou online e adicione todos os seus documentos a ela.
Rotular a pasta compartilhada real Certificação Microsoft
Adicione suas informações de envio inicial de documentos à pasta Certificação Microsoft em uma pasta chamada IDS.
Dentro da pasta Certificação, crie quatro pastas com os seguintes nomes:
Segurança do Aplicativo (isto é para suas informações de Teste de Penetração)
Conformidade (para suas estruturas externas, como SOC 2)
Segurança operacional (SO)
Segurança & Privacidade de Dados (DS&P)
Dentro das pastas OS e DS&P, crie grupos de controle para cada conjunto de controles, ou seja, Malware, Patching, etc., onde você pode adicionar documentos para cada um dos controles (se desejar ser específico, você pode criar uma pasta para cada controle individual, facilitando o rastreamento de evidências pelo nome do controle - neste caso, chame essas pastas de Controle X, onde X significa o número do controle). Observe que você não poderá criar a estrutura de pastas secundária até que seus controles tenham sido definidos.
Um exemplo de uma estrutura de pastas Pastas Raiz:
Subpastas dentro da pasta "Evidência":
Depois de carregar documentos no compartilhamento, dê permissão para a pasta compartilhada e envie um email ao analista de certificação com os detalhes. Envie todas as senhas em um email separado.
Ao reunir evidências, lembre-se de fazer capturas de tela em tela inteira mostrando qualquer usuário conectado, URL e carimbo de data e hora. Se estiver usando 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 trechos ou capturas de tela.
Consulte este documento para ajudar a entender o controle e o tipo de evidência de que precisamos.
Qualquer teste de penetração que possa ser necessário não será agendado e você não receberá documentação para iniciar o processo até que 50% de seus controles sejam aprovados. O teste de penetração será gratuito por apenas 12 dias, no entanto, se o teste de penetração durar 12 dias, você deverá pagar os dias adicionais antecipadamente antes do início do teste.
Depois de receber uma cópia de seus controles com escopo para coletar evidências contra os controles, seu ticker será iniciado - você receberá um e-mail para esse efeito e terá 60 dias para concluir todo o processo de certificação, incluindo o teste de penetração.
Tente enviar a primeira iteração dos controles dentro de 30 dias para permitir que quaisquer problemas sejam identificados e revisões solicitadas antes que os 60 dias se esgotem.