Guia de Envio de Certificação do Microsoft 365

Neste artigo:

• Introdução
• Pré-requisitos
• Especificação de certificação do Microsoft 365 Atualizações
• Escopo de certificação
• Processo de Certificação
• Envio de documento inicial
• Atividades de coleta e avaliação de evidências
• Critérios de certificação
• Segurança de Aplicativo
• Segurança Operacional
• Segurança e privacidade de tratamento de dados
• Revisão opcional de estruturas de conformidade externa
• Apêndice A
• Apêndice B
• Apêndice C
• Apêndice D
• Apêndice E
• Apêndice F
• Apêndice G
• Saiba mais
• Glossário

Introdução

Parte do programa microsoft 365 App Compliance, a Certificação Microsoft 365 oferece garantia e confiança às organizações empresariais de que os dados e a privacidade são adequadamente protegidos ao integrar aplicativos/suplementos de desenvolvedores de terceiros à plataforma microsoft 365. Aplicativos e suplementos que passam pela validação serão designados Microsoft 365 Certificados em todo o ecossistema do Microsoft 365.

Ao participar do programa de Certificação do Microsoft 365, você está concordando com esses termos complementares e para cumprir qualquer documentação que se aplique à sua participação no programa de Certificação do Microsoft 365 com a Microsoft Corporation ("Microsoft", "nós", "nós" ou "nosso"). Você representa e nos garante que tenha autoridade para aceitar esses termos complementares de Certificação do Microsoft 365 em nome de si mesmo, de uma empresa e/ou de outra entidade, conforme aplicável. Podemos alterar, alterar ou encerrar esses 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 suplementares ou se encerrarmos esses termos complementares, você deverá parar de participar do programa de Certificação do Microsoft 365.

Este documento destina-se a ISVs (Fornecedores Independentes de Software) para fornecer informações sobre o processo de Certificação do Microsoft 365, pré-requisitos para iniciar o processo e detalhes de controles de segurança específicos que os ISVs devem ter em vigor. Informações gerais do programa de Conformidade de Aplicativo do Microsoft 365 podem ser encontradas na página do programa de conformidade de aplicativo do Microsoft 365.

Importante

Atualmente, a Certificação microsoft 365 é aplicável a todos:

• Aplicativos do Microsoft Teams (Tabs, Bots etc.) .
• Aplicativos/suplementos do Sharepoint
• Suplementos do Office (Word, Excel, PowerPoint, Outlook, Project, OneNote)
• Webapps

Pré-requisitos

Atestado do Editor

Antes de receber o processo de Certificação do Microsoft 365, você deve ter concluído o Atestado do Editor. No entanto, você pode iniciar o processo de Certificação do Microsoft 365 antes de concluir o Atestado do Editor.

Leia a Especificação de Certificação do Microsoft 365

A Microsoft recomenda que todos os ISVs (Fornecedor Independente de Software) leiam esta Especificação de Certificação do Microsoft 365 em sua totalidade para garantir que todos os controles aplicáveis estejam sendo atendidos pelo ambiente no escopo e pelo aplicativo/suplemento. Isso ajudará a garantir um processo de avaliação suave.

Especificação de certificação do Microsoft 365 Atualizações

Atualizações à especificação de Certificação do Microsoft 365 são antecipadas aproximadamente a cada seis ou 12 meses. Essas atualizações podem introduzir novos domínios de segurança de destino e/ou controles de segurança. Atualizações será baseado em comentários de desenvolvedores, alterações no cenário de ameaças e para aumentar a linha de base de segurança do programa à medida que ele amadurecer.

OS ISVs que já iniciaram a avaliação de certificação do Microsoft 365 podem continuar a avaliação com a versão da Especificação de Certificação do Microsoft 365 válida quando a avaliação foi iniciada. Todos os novos envios, incluindo a recertificação anual, serão necessários para serem avaliados em relação à versão publicada.

Observação

Você não é obrigado a cumprir todos os controles dentro desta Especificação de Certificação do Microsoft 365 para receber uma certificação. No entanto, os limites de passagem (que não serão divulgados) estão em vigor para cada um dos domínios de segurança discutidos dentro desta Especificação de Certificação do Microsoft 365. Alguns controles serão classificados como uma "Falha Dura", o que significa que a falta desses controles de segurança resultará em uma avaliação com falha.

Escopo de certificação

O ambiente no escopo é o ambiente que dá suporte à entrega do código de aplicativo/suplemento e dá suporte a todos os sistemas de back-end com os quais o aplicativo/suplemento pode estar se comunicando. Quaisquer ambientes conectados adicionais também serão incluídos no escopo, a menos que a segmentação adequada esteja em vigor E os ambientes conectados não possam afetar a segurança do ambiente no escopo. Quaisquer ambientes de recuperação de desastre também precisarão ser incluídos no escopo da avaliação, pois esses ambientes seriam necessários para atender ao serviço caso algo acontecesse com o ambiente primário. O termo componentes do sistema no escopo faz referência a TODOS os dispositivos e sistemas que são usados no ambiente no escopo. Os componentes no escopo incluem, mas não se limitam a:

• Os aplicativos Web(s).
• Servidores.
• Firewalls (ou equivalentes).
• Interruptores.
• Balanceadores de carga.
• Infraestrutura virtual.
• Portais de gerenciamento Web do provedor de nuvem

Importante

O ambiente no escopo deve ter um DMZ e o ambiente de suporte do aplicativo/suplemento deve ser segmentado dos sistemas de negócios internos e ambientes corporativos limitando assim o escopo das atividades de avaliação apenas aos sistemas no escopo. Os analistas de certificação validarão as técnicas de segmentação durante a avaliação, juntamente com a revisão de relatórios de teste de penetração que deveriam ter incluído testes para validar a eficácia de quaisquer técnicas de segmentação em uso.

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

Quando o IaaS e/ou PaaS for usado para dar suporte à infraestrutura do aplicativo ou à entrega de código de suplemento em análise, o provedor de plataforma de nuvem será responsável por alguns dos controles de segurança avaliados durante todo o processo de certificação. Portanto, os analistas de certificação precisarão ser fornecidos com verificação externa independente das melhores práticas de segurança pelo provedor de plataforma de nuvem por meio de relatórios de conformidade externa, como [PCI DSS] Atestado de Conformidade (AOC), relatórios ISO27001 ou [SOC 2] Tipo II.

O Apêndice F fornece detalhes de quais controles de segurança provavelmente serão aplicáveis com base nos seguintes tipos de implantação e com base em saber se o aplicativo/suplemento exfiltra dados do Microsoft 365 ou não:

• ISV hospedado
• IaaS hospedado
• PaaS/host sem servidor
• Híbrida hospedada
• Hospedado compartilhado

Quando o IaaS ou o PaaS for implantado, você precisará fornecer evidências do ambiente hospedado nesses tipos de implantação.

Amostragem

As solicitações de evidência em suporte à avaliação de certificação devem ser baseadas em uma amostra dos componentes do sistema no escopo em consideração a diferentes sistemas operacionais, função primária do dispositivo e diferentes tipos de dispositivo. Um exemplo adequado será selecionado no início do processo de certificação. A tabela a seguir deve ser usada como um guia sobre qual tamanho de exemplo pode ser:

Tamanho da população	Amostra
<5	1
>5 & <10	2
>9 & <25	3
>24	4

Observação

Se forem identificadas discrepâncias entre dispositivos incluídos no exemplo inicial, o tamanho da amostra poderá ser aumentado durante a avaliação.

Processo de Certificação

Antes de iniciar o processo de certificação, você precisará ter concluído com êxito seu Atestado de Editor. Depois de concluído, o processo de Certificação do Microsoft 365 prossegue da seguinte maneira:

Preparação

1. Navegue até o centro de parceiros e examine a documentação concluída do Publisher Attestation . Se necessário, você pode editar e atualizar suas respostas; no entanto, se você fizer isso, precisará reenviar sua documentação de atestado para aprovação. Se o envio for superior a três meses, exigiremos que você reenviar o Publisher Attestation para revisão e validação.
2. Leia atentamente o Guia de Envio de Certificação do Microsoft 365 para entender o que será necessário de você. Verifique se você poderá atender aos requisitos de controle especificados no Guia de Envio de Certificação do Microsoft 365.
3. No centro de parceiros, selecione "Iniciar Certificação". Isso o levará ao portal inicial de envio de documentos. Envie seu Envio inicial de documento. Isso nos ajudará a determinar o que está no escopo de sua avaliação com base em como seu aplicativo é arquiteto e lida com dados do cliente. Verifique esta página com frequência para ver se o envio foi aceito.

Observação

Para todos os aplicativos do office, você pode referenciar nosso Guia de Usuário dos Aplicativos do Office. Para todos os WebApps, você pode referenciar nosso Guia de Usuário do Aplicativo SaaS.

Avaliação

1. Depois que o envio inicial do documento for aceito, o conjunto de controles de segurança necessários para seu aplicativo será exibido automaticamente no portal. Em seguida, você será obrigado a enviar evidências para cada controle que demonstre que o controle está em vigor. Tenha em mente que você terá 60 dias para enviar todas as provas. Um analista examinará suas evidências e aprovará o controle ou solicitará evidências novas ou adicionais. Verifique esta página com frequência para ver se suas evidências foram aceitas.

Certificação

1. Depois que o envio for validado por um analista, você será notificado da sua decisão de certificação. Os aplicativos premiados com uma certificação receberão um selo em seu aplicativo no AppSource e nas páginas de documentos da Microsoft . Você pode ler sobre os benefícios completos da certificação aqui.

Revisão e recertificação

Se seu aplicativo sofrer alterações significativas em qualquer ponto, você será obrigado a nos notificar.

Você também será obrigado a passar pela recertificação anualmente. Isso exigirá a revalidação dos controles no escopo em relação ao seu ambiente atual. Esse processo pode começar até 90 dias antes da expiração da sua certificação. Sua certificação existente não expirará durante o período de recertificação. A certificação em todos os programas expira no aniversário de um ano da certificação do Microsoft 365.

Se sua certificação não for renovada antes da data de validade, a status de certificação de aplicativos será revogada. Todos os ícones, ícones e identidade visual de certificação associados serão removidos do aplicativo e você será proibido de anunciar seu aplicativo como Certificado do Microsoft 365.

Importante

Período de envio: Prevê-se que, em média, o processo de avaliação deva levar 30 dias, desde que você possa marcar seu envio status com frequência e responder a comentários e solicitações de evidências suplementares em tempo hábil. Ao iniciar o processo de certificação, é permitido concluir a avaliação no máximo 60 dias. Se todas as submissões não tiverem sido concluídas no período de 60 dias, o envio será emitido uma falha e o processo deverá ser iniciado novamente. Esses resultados não serão tornados públicos.

Envio inicial de documento

O envio inicial do documento ajudará os analistas de certificação a executar o escopo e determinar o que estará no escopo de sua avaliação. Depois disso, você será obrigado a enviar documentação de suporte e evidências usadas para realizar a avaliação. Seu envio inicial deve incluir as informações especificadas abaixo. Para obter diretrizes adicionais, consulte o Guia inicial de envio de documentos.

Visão geral da documentação	Detalhes da documentação
Descrição do aplicativo/suplemento	Uma descrição da finalidade e funcionalidade do aplicativo/suplemento. Isso deve fornecer ao analista de certificação uma boa compreensão de como o aplicativo/suplemento 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. Este relatório deve incluir o ambiente que dá suporte à implantação do aplicativo/adicionar junto com qualquer ambiente adicional que dê suporte à operação do aplicativo/suplemento. Observação: se você não fizer testes anuais de penetração, poderá optar por fazê-los por meio do processo de certificação.
Diagramas de arquitetura	Um diagrama de arquitetura lógica que representa uma visão geral de alto nível da infraestrutura de suporte do seu aplicativo/suplemento. Isso deve incluir todos os ambientes de hospedagem e a infraestrutura de suporte que dá suporte ao aplicativo/suplemento. Este diagrama DEVE retratar todos os diferentes componentes do sistema de suporte no ambiente para ajudar os analistas de certificação a entender sistemas no escopo e ajudar a determinar a amostragem. Indique também qual tipo de ambiente de hospedagem é usado; ISV hospedado, IaaS, PaaS ou Híbrido. Nota: Onde o SaaS é usado, indique os vários serviços SaaS usados para fornecer os 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 o intervalo de IP roteável completo alocado para o ambiente, a menos que a segmentação adequada tenha sido implementada para dividir o intervalo em uso (serão necessárias evidências adequadas de segmentação)
Diagramas de fluxo de dados	Diagramas de fluxo detalhando o seguinte:
	✓ O Microsoft 365 Data flui de e para o Aplicativo/Suplemento (incluindo EUII e OII ).
	✓ O Microsoft 365 Data flui 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 listagem 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 da 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 que o aplicativo/suplemento funcione junto com uma justificativa para as permissões solicitadas
Tipos de armazenamento de dados	Armazenamento e tratamento de dados de documentos que descrevem:
	✓ Até que ponto os seus clientes Microsoft 365 Data EUII e OII estão sendo recebidos e armazenados
	✓ O período de retenção de dados.
	✓ Por que o cliente Microsoft 365 Data está sendo capturado.
	✓ Em que o cliente Microsoft 365 Data é armazenado (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 Publisher Attestation ou a serem consideradas ao revisar os controles de Certificação do Microsoft 365. Atualmente, há suporte para os três a seguir:
	✓ Atestado de Conformidade do PCI DSS DSS (AOC).
	✓ RELATÓRIOS SOC 2 Tipo E/Tipo II.
	✓ ISMS / IEC – 1S0/IEC 27001 Instrução de Aplicabilidade (SoA) e Certificação.
Dependências da Web	Documentação que lista todas as dependências usadas pelo aplicativo/suplemento 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 executar a fase de avaliação. Se o ambiente incluir o PaaS, forneça detalhes dos serviços consumidos.

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

Os analistas de certificação precisarão examinar evidências em todos os componentes do sistema dentro do conjunto de exemplo definido. Os tipos de evidência necessários para dar suporte ao processo de avaliação incluem qualquer um ou todos os seguintes:

Coleção de Evidências

• Documentação inicial, realçada na seção Envio de Documentação Inicial acima
• Documentos de política
• Processar documentos
• Configurações do sistema
• Alterar tíquetes
• Alterar registros de controle
• Relatórios do sistema

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

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

As técnicas de coleta de evidências usadas serão determinadas durante o processo de avaliação. Para obter exemplos concretos do tipo de evidência necessário em seu envio, consulte o Guia de Evidências de Exemplo.

Atividades de avaliação

Os analistas de certificação examinarão as evidências fornecidas para determinar se você cumpriu adequadamente os controles dentro desta Especificação de Certificação do Microsoft 365.

Sempre que possível e para reduzir o tempo necessário para concluir a avaliação, qualquer ou toda a documentação detalhada no Envio de Documentação Inicial deve ser fornecida com antecedência.

Os analistas de certificação primeiro examinarão as evidências fornecidas a partir do envio da documentação inicial e das informações do Publisher Attestation para identificar linhas apropriadas de investigação, tamanho da amostragem e a necessidade de obter mais evidências conforme detalhado acima. Os analistas de certificação analisarão todas as informações coletadas para tirar conclusões sobre como e se você estiver atendendo aos controles dentro desta Especificação de Certificação do Microsoft 365.

Critérios de certificação de aplicativo

Seu aplicativo, infraestrutura de suporte e documentação de suporte serão avaliados nos seguintes domínios de segurança:

1. Segurança de Aplicativo
2. Segurança Operacional /Implantação Segura
3. Segurança e privacidade de tratamento de dados

Cada um desses domínios de segurança inclui controles de chave específicos que abrangem um ou mais requisitos específicos 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 de Certificação do Microsoft 365 são alocadas entre 1 (baixa) e 3 (alta) com base no risco percebido de que esse controle não seja atendido. Cada um dos domínios de segurança terá uma marca percentual mínima a ser considerada uma passagem. Alguns elementos dessa especificação incluem alguns critérios de falha automáticos:

• Permissões de API que não seguem o princípio de mínimo privilégio (PoLP).
• Nenhum relatório de teste de penetração quando é necessário.
• Sem defesas anti-malware
• A autenticação multifator não está sendo usada para proteger o acesso administrativo.
• Nenhum processo de patch.
• Nenhum aviso de privacidade de GDPR adequado.

Segurança de Aplicativo

O domínio de segurança do aplicativo se concentra nas três áreas a seguir:

• Validação de permissão do GraphAPI
• Verificações de conectividade externa
• Teste de Segurança do Aplicativo

Validação de permissão do GraphAPI

A validação de permissão graphAPI é realizada para validar que o aplicativo/suplemento não solicita permissões excessivamente permissivas. Isso é realizado verificando manualmente quais permissões são solicitadas. Os analistas de certificação cruzarão essas verificações em relação ao envio do Publisher Attestation e avaliarão o nível de acesso solicitado para garantir que práticas de "mínimo privilégio" estejam sendo atendidas. Quando os analistas de certificação acreditam que essas práticas de "privilégio mínimo" não estão sendo atendidas, os analistas de certificação terão uma discussão aberta com você para validar a justificativa comercial para as permissões que estão sendo solicitadas. Todas as discrepâncias em relação ao envio do Publisher Attestation encontradas durante esta revisão também receberão comentários para que seu Atestado de Editor possa ser atualizado.

Verificações de conectividade externa

Como parte da avaliação, um analista executará um passo a passo leve da funcionalidade dos aplicativos para identificar conexões fora do Microsoft 365. Todas as conexões que não forem identificadas como sendo da Microsoft ou conexões diretas com seu serviço serão sinalizadas e discutidas durante a avaliação.

Teste de Segurança do Aplicativo

Uma revisão adequada dos riscos associados ao seu ambiente de aplicativo/suplemento e suporte é essencial para fornecer aos clientes garantia na segurança do aplicativo/suplemento. O teste de segurança do aplicativo na forma de teste de penetração DEVE ser realizado se o aplicativo tiver alguma conectividade com qualquer serviço não publicado pela Microsoft. Se seu aplicativo opera autônomo sem conectividade com qualquer serviço ou back-end que não seja da Microsoft, o teste de penetração não será necessário.

Escopo de teste de penetração

Atividades de teste de penetração devem ser realizadas no ambiente de produção ao vivo que dá suporte à implantação do aplicativo/suplemento (por exemplo, onde o código de aplicativo/suplemento é hospedado, que normalmente será o recurso dentro do arquivo de manifesto) juntamente com qualquer ambiente adicional que dê suporte à operação do aplicativo/suplemento (por exemplo, se o aplicativo/suplemento conversar com outros aplicativos Web fora do Microsoft 365). Ao definir o escopo, é necessário tomar cuidado para garantir que todos os sistemas ou ambientes "conectados" que possam afetar a segurança do ambiente no escopo também sejam incluídos em TODAS as atividades de teste de penetração.

Quando as técnicas são usadas para segmentar os ambientes no escopo de outros ambientes, as atividades de teste de penetração devem validar a eficácia das técnicas de segmentação. Isso deve ser detalhado no relatório 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.

Requisitos de teste de penetração

Tipo de critério	Controles de teste de penetração
Critérios Gerais	Controls
	Os testes de penetração de aplicativo e infraestrutura devem ocorrer anualmente (a cada 12 meses) e conduzidos por uma empresa independente respeitável.
	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 mais cedo, dependendo do processo de patch documentado.
	A pegada externa completa (Endereços IP, URLs, Pontos de Extremidade de API etc.) DEVE ser incluído no escopo do teste de penetração e deve ser documentado no relatório de teste de penetração.
	O teste de penetração de aplicativo Web DEVE incluir todas as classes de vulnerabilidade; por exemplo, o OWASP Top 10 ou OWAS Top 25 CWE mais atual.
	Não é necessário testar novamente as vulnerabilidades identificadas pela empresa de testes de penetração— a correção e a autoavaliação são suficientes, no entanto, evidências adequadas para demonstrar correção suficiente devem ser fornecidas durante a avaliação.
Critérios de falha automática:	Controls
	Presença de um sistema operacional sem suporte.
	Presença de contas administrativas padrão, enumeráveis ou adivináveis.
	Presença de riscos de injeção de SQL.
	Presença de script entre sites.
	Presença de vulnerabilidades de travessia de diretório (caminho do arquivo).
	Presença de vulnerabilidades HTTP, por exemplo, divisão de resposta de cabeçalho, contrabando de solicitações e ataques Desync.
	Presença de divulgação de código-fonte (incluindo LFI).
	Qualquer pontuação crítica ou alta, conforme definido pelas diretrizes de gerenciamento de patch do 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 de que tudo detalhado na seção Especificação de Teste de Segurança do Aplicativo pode ser demonstrado.

Requisitos e regras de teste de penetração complementar

• Para ISVs que atualmente não se envolvem em testes de penetração, os testes de penetração podem ser realizados gratuitamente na Certificação microsoft 365. A Microsoft organizará e cobrirá o custo de um teste de penetração para até 12 dias de teste manual. Os custos de testes de penetração são calculados com base no número de dias necessários para testar o ambiente. Quaisquer despesas que excedam 12 dias de teste serão de responsabilidade do ISV.
• Os ISVs serão necessários para enviar evidências e receber aprovação para 50% dos controles no escopo antes do teste de penetração ser realizado. Para começar, preencha o envio inicial do documento e opte por ter testes de penetração incluídos como parte de sua avaliação. Você será contatado para escopo e agendar seu teste de penetração quando concluir 50% dos controles.
• O relatório emitido depois que o pentest for concluído será fornecido ao ISV após a conclusão da certificação. Este relatório junto com sua Certificação microsoft 365 pode ser usado para mostrar aos clientes potenciais que seu ambiente está seguro.
• Os ISVs também serão responsáveis por demonstrar que as vulnerabilidades identificadas no teste de penetração foram corrigidas antes de uma certificação ser concedida, mas não precisam produzir um relatório limpo.

Depois que um teste de penetração é organizado, o ISV é responsável por taxas associadas a reagendamento e cancelamentos da seguinte maneira:

Escala de tempo da taxa de reagendamento	Proporcional a pagar
A solicitação de reagendamento recebeu mais de 30 dias antes da data de início agendada.	0% a pagar
A solicitação de reagendamento recebeu de 8 a 30 dias antes da data de início agendada.	25% a pagar
Reagendar a solicitação recebida dentro de 2 a 7 dias antes da data de início agendada com uma data de remarcação da empresa.	50% a pagar
A solicitação de reagendamento recebeu menos de dois dias antes da data de início.	100% a pagar

Escala de tempo da taxa de cancelamento	Proporcional a pagar
A solicitação de cancelamento recebeu mais de 30 dias antes da data de início agendada.	25% a pagar
A solicitação de cancelamento recebeu de 8 a 30 dias antes da data de início agendada.	50% a pagar
Solicitação de cancelamento recebida dentro de 7 dias antes da data de início agendada.	90% a pagar

Segurança Operacional

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

Controles

Família control	Controls
Proteção contra Malware – Antivírus	Forneça a documentação da política que rege práticas e procedimentos antivírus.
	Forneça evidências demonstradas de que o software antivírus está em execução em todos os componentes do sistema amostrados.
	Forneça evidências demonstrativas de que as assinaturas antivírus estão atualizadas em todos os ambientes (dentro de 1 dia).
	Forneça evidências demonstrativas de que o antivírus está configurado para executar verificação ou verificação periódica no acesso em todos os componentes do sistema amostrados. Observação: se a verificação de acesso não estiver habilitada, um mínimo de verificação diária e alertas devem ser habilitados.
	Forneça evidências demonstrativas de que o antivírus está configurado para bloquear automaticamente malware ou quarentena e alerta em todos os componentes do sistema amostrados.
Controles de Aplicativo: SOMENTE necessário se o anti-malware tradicional não for usado	Forneça evidências demonstrativas de que os aplicativos são aprovados antes de serem implantados.
	Forneça evidências demonstrativas de que existe e mantém uma lista completa de aplicativos aprovados com justificativa comercial.
	Forneça documentação de suporte detalhando que o software de controle de aplicativo está configurado para atender a mecanismos de controle de aplicativo específicos. (Exemplo: listagem permitida: sample1, sample3, assinatura de código)
	Forneça evidências demonstrativas de que o controle do aplicativo está configurado conforme documentado de todos os componentes do sistema amostrados.
Gerenciamento de Patch – 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 uma pontuação de risco.
	Forneça evidências de como novas vulnerabilidades de segurança são identificadas.
	Forneça evidências que demonstrem que todas as vulnerabilidades recebem uma classificação de risco depois de identificadas.
Gerenciamento de Patch – Patching	Forneça a documentação da política para a correção de componentes do sistema no escopo que inclua um período mínimo de patch adequado para vulnerabilidades de risco crítico, alto e médio; e descomissionamento de qualquer software e sistemas operacionais sem suporte.
	Forneça evidências demonstrativas de que todos os componentes do sistema amostrados estão sendo corrigidos.
	Forneça evidências demonstrativas de que todos os sistemas operacionais e componentes de software sem suporte não são usados no ambiente.
Verificação de vulnerabilidades	Forneça os relatórios trimestrais de verificação de vulnerabilidades de infraestrutura e aplicativo Web. A verificação precisa ser realizada em relação a toda a pegada pública (endereços IP e URLs) e intervalos de IP internos.
	Forneça evidências demonstrativas de que as correções de vulnerabilidades identificadas durante a verificação de vulnerabilidades são corrigidas de acordo com seu período de tempo de patch documentado.
Firewalls	Forneça a documentação de política que rege práticas e procedimentos de gerenciamento de firewall.
	Forneça evidências demonstradas de que todas as credenciais administrativas padrão são alteradas antes da instalação em ambientes de produção.
	Forneça evidências demonstrativas de que os firewalls estão instalados no limite do ambiente no escopo e instalados entre a rede de perímetro (também conhecida como DMZ, zona desmilitarizada e sub-rede exibida) e redes confiáveis internas.
	Forneça evidências demonstrativas de que todo o acesso público termina na zona desmilitarizada (DMZ).
	Forneça evidências demonstrativas de que todo o tráfego permitido por meio do firewall passa por um processo de aprovação.
	Forneça evidências demonstrativas de que a base de regras de firewall está configurada para remover o tráfego não definido explicitamente.
	Forneça evidências demonstradas de que o firewall dá suporte apenas a criptografia forte em todas as interfaces administrativas que não são de console.
	Forneça evidências demonstrativas de que você está executando revisões de regra de firewall pelo menos a cada 6 meses.
Firewall de Aplicativo Web (WAF) (OPCIONAL): O crédito adicional será recompensado por satisfazer os seguintes controles.	Forneça evidências demonstrativas de que o WAF (Firewall de Aplicativo Web) está configurado para monitorar, alertar e bloquear o tráfego mal-intencionado ativamente.
	Forneça evidências demonstrativas de que o WAF dá suporte ao descarregamento de SSL.
	Forneça evidências demonstrativas de que o WAF está protegido contra algumas ou todas as seguintes classes de vulnerabilidades de acordo com o Conjunto de Regras do Núcleo OWASP (3.0 ou 3.1)
Alterar controle	Forneça a documentação da política que rege os processos de controle de alterações.
	Forneça evidências demonstrativas de que ambientes de desenvolvimento e teste impõem a separação de tarefas do ambiente de produção.
	Forneça evidências demonstrativas de que dados confidenciais de produção não são usados nos ambientes de desenvolvimento ou teste.
	Forneça evidências demonstrativas de que as solicitações de alteração documentadas contêm o impacto da alteração, os detalhes dos procedimentos de back-out e dos testes a serem realizados.
	Forneça evidências demonstrativas de que as solicitações de alteração passam por um processo de autorização e de saída.
Desenvolvimento/implantação de software seguro	Forneça políticas e procedimentos que dão suporte ao desenvolvimento e à implantação de software seguros, incluindo diretrizes de práticas recomendadas de codificação segura contra classes de vulnerabilidade comuns, como, OWASP Top 10 ou SANS Top 25 CWE.
	Forneça evidências demonstrativas de que as alterações de código passam por um processo de revisão e autorização por um segundo revisor.
	Forneça evidências demonstrativas de que os desenvolvedores passam por treinamento seguro de desenvolvimento de software anualmente.
	Forneça evidências demonstrativas de que os repositórios de código são protegidos com MFA (autenticação multifator).
	Forneça evidências demonstrativas de que os controles de acesso estão em vigor para proteger repositórios de código.
Gerenciamento de Conta	Forneça a documentação de política que rege práticas e procedimentos de gerenciamento de conta.
	Forneça evidências demonstrativas de que as credenciais padrão estão desabilitadas, removidas ou alteradas entre os componentes do sistema amostrados.
	Forneça evidências demonstrativas de que a criação, modificação e exclusão da conta passam por um processo de aprovação estabelecido.
	Forneça evidências demonstrativas de que um processo está em vigor para desabilitar ou excluir contas não usadas dentro de três meses.
	Forneça evidências demonstrativas de que uma política de senha forte ou outras mitigações adequadas para proteger as credenciais do usuário estão em vigor. O seguinte deve ser usado como uma diretriz mínima: comprimento mínimo de senha de 8 caracteres, limite de bloqueio da conta de no máximo 10 tentativas, histórico de senha de um mínimo de 5 senhas, aplicação do uso de senha forte
	Forneça evidências demonstrativas de que contas de usuário exclusivas são emitidas para todos os usuários.
	Forneça evidências demonstrativas de que princípios de privilégio mínimo estão sendo seguidos dentro do ambiente.
	Forneça evidências demonstrativas de que um processo está em vigor para proteger ou endurecer contas de serviço e o processo está sendo seguido.
	Forneça evidências demonstrativas de que o MFA está configurado para todas as conexões de acesso remoto e todas as interfaces administrativas não console.
	Forneça evidências demonstrativas de que a criptografia forte está configurada para todas as conexões de acesso remoto e todas as interfaces administrativas não console, incluindo acesso a quaisquer repositórios de código e interfaces de gerenciamento de nuvem.
	Forneça evidências demonstrativas de que o MFA é usado para proteger o portal de administração que você usa para gerenciar e manter todos os registros DNS (serviço de nome de domínio público).
Detecção e prevenção de intrusão (OPCIONAL): Crédito adicional será recompensado por satisfazer os controles a seguir	Forneça evidências demonstrativas de que os Sistemas de Detecção e Prevenção de Intrusão (IDPS) são implantados no perímetro dos ambientes no escopo.
	Forneça evidências demonstrativas de que as assinaturas IDPS são mantidas atuais (dentro de 24 horas).
	Forneça evidências demonstrativas de que o IDPS está configurado para dar suporte à inspeção TLS de todo o tráfego Web de entrada.
	Forneça evidências demonstrativas de que o IDPS está configurado para monitorar todos os fluxos de tráfego de entrada.
	Forneça evidências demonstrativas de que o IDPS está configurado para monitorar todos os fluxos de tráfego de saída.
Registro em log de eventos de segurança	Forneça a documentação da política para melhores práticas e procedimentos que regem o registro em log de eventos de segurança.
	Forneça evidências demonstrativas que mostram que o registro em log de eventos de segurança está configurado em todos os componentes do sistema amostrados para registrar os seguintes eventos: acesso do usuário aos componentes do sistema e ao aplicativo, Todas as ações tomadas por um usuário de alto privilégio, acesso lógico inválido tenta criação ou modificação de conta privilegiada, adulteração de log de eventos, Desabilitação de ferramentas de segurança (como anti-malware ou registro em log de eventos), log anti-malware (como atualizações, detecção de malware e falhas de verificação)., eventos IDPS e WAF, se configurados
	Forneça evidências demonstrativas de que os eventos de segurança registrados contêm as seguintes informações mínimas: Usuário, Tipo de evento, Data e hora, êxito ou indicadores de falha, Rótulo que identifica o sistema afetado
	Forneça evidências demonstrativas de que todos os componentes do sistema amostrados são sincronizados com o tempo para os mesmos servidores primários e secundários.
	Forneça evidências demonstrativas quando sistemas públicos estão em uso de que os logs de eventos de segurança estão sendo enviados para uma solução de log centralizada não dentro da rede de perímetro.
	Forneça evidências demonstrativas para mostrar que a solução de log centralizada está protegida contra adulteração não autorizada de dados de log.
	Forneça evidências demonstradas de que um mínimo de 30 dias de dados de registro em log de eventos de segurança está disponível imediatamente, com 90 dias de logs de eventos de segurança sendo mantidos.
Revisões de log de eventos de segurança	Forneça a documentação da política que rege práticas e procedimentos de revisão de log.
	Forneça evidências demonstrativas de que os logs são revisados diariamente por uma ferramenta humana ou automatizada para identificar possíveis eventos de segurança.
	Forneça evidências demonstradas de que possíveis eventos de segurança e anomalias são investigados e corrigidos.
Alertando	Forneça a documentação da política que rege práticas e procedimentos de alerta de eventos de segurança.
	Forneça evidências demonstrativas de que os alertas são disparados para triagem imediata para os seguintes tipos de eventos de segurança: criação ou modificações de conta privilegiada, eventos de vírus ou malware, adulteração de log de eventos, IDPS ou eventos WAF
	Forneça evidências demonstrativas mostrando que a equipe está sempre disponível, todos os dias, todos os dias, para responder aos alertas de segurança.
Gerenciamento de risco	Forneça evidências demonstrativas de que um processo formal de gerenciamento de risco de segurança de informações está estabelecido.
	Forneça evidências demonstrativas de que uma avaliação formal de risco ocorre anualmente, no mínimo.
	Forneça evidências demonstradas de que a avaliação de risco de segurança da informação inclui ameaças, vulnerabilidades ou o equivalente.
	Forneça evidências demonstradas de que a avaliação de risco de segurança da informação inclui impacto, matriz de risco de probabilidade ou equivalente.
	Forneça evidências demonstradas de que a avaliação de risco de segurança da informação inclui um registro de risco e um plano de tratamento.
Resposta a incidentes	Forneça o IRP (plano de resposta a incidentes de segurança).
	Forneça evidências demonstradas de que o IRP de segurança inclui um processo de comunicação documentado para garantir a notificação oportuna aos principais stakeholders, como marcas de pagamento e adquirentes, órgãos reguladores, autoridades de supervisão, diretores e clientes.
	Forneça evidências demonstradas de que todos os membros da equipe de resposta a incidentes concluíram o treinamento anual ou um exercício superior da tabela.
	Forneça evidências demonstrativas para mostrar que o IRP de segurança é atualizado com base em lições aprendidas ou alterações organizacionais.

Segurança e privacidade de tratamento de dados

Os dados em trânsito entre o usuário do aplicativo, os serviços intermediários e os sistemas do ISV serão necessários para serem protegidos pela criptografia por meio de uma conexão TLS com suporte a um mínimo de TLS v1.1. ConsulteApêndice A.

Quando seu aplicativo recuperar e armazenar dados do Microsoft 365, você será necessário para implementar um esquema de criptografia de armazenamento de dados que siga a especificação conforme definido no Apêndice B.

Controles

Família control	Controls
Dados em Trânsito	Forneça evidências demonstrativas de que a configuração do TLS atende ou excede os requisitos de criptografia dentro dos requisitos de configuração de perfil do TLS
	Forneça evidências demonstrativas de que a compactação TLS está desabilitada em todos os serviços voltados para o público que lidam com solicitações da Web.
	Forneça evidências demonstrativas de que a segurança de transporte estrita http do TLS está habilitada e configurada como >= 15552000 em todos os sites.
Dados em repouso	Forneça evidências demonstrativas de que os dados em repouso são criptografados de acordo com os requisitos de perfil de criptografia, usando algoritmos de criptografia como AES, Blowfish, TDES e tamanhos de chave de criptografia de 128 bits e 256 bits.
	Forneça evidências demonstrativas de que a função de hash ou a autenticação de mensagem (HMAC-SHA1) só é usada para proteger dados em repouso de acordo com os requisitos de perfil de criptografia.
	Forneça um inventário mostrando todos os dados armazenados, incluindo o local de armazenamento e a criptografia usada para proteger os dados.
Retenção e descarte de dados	Forneça evidências demonstrativas de que um período de retenção de dados aprovado e documentado está formalmente estabelecido.
	Forneça evidências demonstrativas de que os dados retidos correspondem ao período de retenção definido.
	Forneça evidências demonstradas de que os processos estão em vigor para excluir dados com segurança após o período de retenção.
Gerenciamento de Acesso de Dados	Forneça uma lista de todos os indivíduos com acesso a chaves de dados ou criptografia, incluindo a justificativa comercial.
	Forneça evidências demonstrativas de que os indivíduos amostrados que têm acesso a dados ou chaves de criptografia foram formalmente aprovados, detalhando privilégios necessários para sua função de trabalho.
	Forneça evidências demonstrativas de que os indivíduos amostrados que têm acesso a dados ou chaves de criptografia só têm os privilégios incluídos na aprovação.
	Forneça uma lista de todos os terceiros com os quais os dados do cliente são compartilhados.
	Forneça evidências demonstrativas de que todos os terceiros que consomem dados do cliente têm contratos de compartilhamento em vigor.
GDPR (se aplicável)	Forneça um processo de SAR (solicitação de acesso de assunto) documentado e forneça evidências que demonstrem que os indivíduos de dados são capazes de gerar SARs.
	Forneça evidências demonstrativas de que você é capaz de identificar todos os locais dos dados dos titulares de dados ao responder a um SAR.
	Você mantém um aviso de privacidade que deve conter os detalhes das empresas (Nome, Endereço etc.).
	Você mantém um aviso de privacidade que deve explicar os tipos de dados pessoais que estão sendo processados.
	Você mantém um aviso de privacidade que deve explicar a legalidade do processamento de dados pessoais
	Você mantém um aviso de privacidade que explica em detalhes os direitos do titular dos dados: Direito de ser informado, Direito de acesso pelo titular dos dados, Direito à eliminação, Direito à restrição de processamento, Portabilidade do Direito aos dados, Direito ao objeto, Direitos em relação à tomada de decisão automatizada, incluindo criação de perfil.
	Você mantém um aviso de privacidade que deve explicar por quanto tempo os dados pessoais serão mantidos.

Revisão opcional de estruturas de conformidade externa

Embora não seja necessário, se você estiver atualmente em conformidade com ISO 27001, PCI DSS ou SOC2, você poderá optar por usar essas certificações para atender a alguns dos controles de Certificação do Microsoft 365. Os analistas de certificação tentarão alinhar as estruturas de segurança externas existentes à especificação de Certificação do Microsoft 365. No entanto, se a documentação de suporte não puder fornecer garantia de que os controles de certificação do Microsoft 365 foram avaliados como parte da auditoria/avaliação das estruturas de segurança externas, você precisará fornecer evidências adicionais dos controles ditos em vigor.

A documentação deve demonstrar adequadamente que o ambiente no escopo da Certificação Microsoft 365 foi incluído no escopo dessas estruturas de segurança externas. A validação dessas estruturas de segurança será atendida aceitando evidências de certificações válidas conduzidas por empresas terceirizadas externas respeitáveis. Essas empresas respeitáveis devem ser membros de órgãos de credenciamento internacionais para programas de conformidade relevantes. Consulte Padrões de Certificação e Conformidade iso para ISO 27001 e QSA (Assistentes de Segurança Qualificada) para PCI DSS.

A tabela a seguir destaca as estruturas externas e a documentação exigidas pelos analistas de certificação como parte desse processo de validação:

Standard	Requisitos
ISO 27001	Será necessária uma versão pública da Instrução de Aplicabilidade (SOA) e uma cópia do certificado ISO 27001 emitido. O SOA resume sua posição em cada um dos 114 controles de segurança de informações e será usado para identificar se há qualquer exclusão de controles que não sejam satisfatoriamente detalhados no certificado ISO 27001. Se isso não puder ser determinado examinando a versão voltada para o público do SOA, o analista poderá precisar de acesso ao SOA completo se o ISO 27001 for usado para validar alguns dos controles de Especificação de Certificação do Microsoft 365. Além de validar o escopo das atividades de avaliação iso 27001, os analistas também confirmarão a validade da empresa de auditoria, conforme descrito acima.
PCI DSS	Um documento AOC ( Atestado de Conformidade) Nível 1 válido deve ser fornecido identificando claramente os componentes do aplicativo e do sistema no escopo. Um AOC de autoavaliação não será aceito como evidência de melhores práticas de segurança de reunião. O AOC será usado para determinar qual dos controles de 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 I ou Tipo II) deve ser atual (emitido nos últimos 15 meses e o período declarado iniciado nos últimos 27 meses) para ser usado como evidência de conformidade com qualquer um dos controles de avaliação dentro desta Especificação de Certificação do Microsoft 365.

Se as estruturas de segurança externas tiverem sido incluídas no Publisher Attestation, os analistas de certificação precisarão marcar a validade dessas estruturas de conformidade de segurança como parte da avaliação da Certificação do Microsoft 365.

Framework	Considerações adicionais
ISO 27001	Apêndice C: Coleta de Evidências – Deltas para ISO 27001.
PCI DSS	Apêndice D: Coleção de Evidências – Deltas para PCI DSS.
SOC 2	Apêndice E: Coleta de Evidências – Deltas para SOC 2.

Observação

Embora os padrões/estruturas de segurança externa acima mencionados possam ser enviados como evidência para atender a alguns dos controles de Certificação do Microsoft 365, passar pela Certificação Microsoft 365 não significa que você passará com êxito uma auditoria contra esses padrões/estruturas. A Especificação de Certificação do Microsoft 365 é apenas um pequeno subconjunto desses padrões/estruturas de segurança que permite à Microsoft obter um nível de garantia em referência à sua postura de segurança.

Requisitos para usar estruturas de conformidade externas

✓ O ambiente de suporte de aplicativo/suplemento E todos os processos empresariais de suporte devem ser incluídos no escopo de quaisquer estruturas de conformidade de segurança externa com suporte e devem ser claramente indicados na documentação fornecida.

✓ As estruturas de conformidade de segurança externa com suporte devem ser atuais, ou seja, nos últimos 12 meses (ou dentro de 15 meses, se a reavaliação estiver sendo realizada no momento e as evidências puderem ser fornecidas).

✓ Estruturas de conformidade de segurança externa com suporte devem ser executadas por uma empresa credenciada independente.

Apêndice A

Requisitos de configuração de perfil TLS

Todo o tráfego de rede, seja dentro de uma rede virtual, serviço de nuvem ou um data center, deve ser protegido com um mínimo de TLS v1.1 (TLS v1.2+ é recomendado) ou outro protocolo aplicável. As exceções a esse requisito são:

• Redirecionamento HTTP-to-HTTPS. Seu aplicativo pode responder por HTTP para redirecionar clientes para HTTPS, mas a resposta não deve conter dados confidenciais (cookies, cabeçalhos, conteúdo). Nenhuma outra resposta HTTP além de redirecionamentos para HTTPS e responder a investigações de integridade são permitidas. Confira a seguir.
• Investigações de integridade. Seu aplicativo só poderá responder a investigações de integridade por http se não houver suporte para investigações de integridade HTTPS pela parte de verificação.
• Acesso ao certificado. O acesso aos pontos de extremidade CRL, OCSP e AIA para fins de validação de certificado e verificação de revogação é permitido por HTTP.
• Comunicações locais. Seu aplicativo pode usar HTTP (ou outros protocolos não protegidos) para comunicações que não saem do sistema operacional, por exemplo, conectar-se a um ponto de extremidade do servidor Web exposto em localhost.

A compactação TLS deve ser desabilitada.

Apêndice B

Requisitos de configuração de perfil de criptografia

Somente primitivos e parâmetros criptográficos são permitidos da seguinte maneira:

Criptografia simétrica

Encryption

 ✓ Somente AES, BitLocker, Blowfish ou TDES são permitidos. Qualquer um dos comprimentos >de chave com suporte =128 são permitidos (128 bits, 192 bits e 256 bits) e podem ser usados (chaves de 256 bits são recomendadas).

 ✓ Somente o modo CBC é permitido. Cada operação de criptografia deve usar um vetor de inicialização (IV) gerado aleatoriamente.

 ✓ Uso de cifras de fluxo, como RC4, NÃO é permitido.

Funções de hash

 ✓ Todos os novos códigos devem usar SHA-256, SHA-384 ou SHA-512 (coletivamente conhecido como SHA-2). A saída pode ser truncada para nada menos que 128 bits

 ✓ O SHA-1 só pode ser usado por motivos de compatibilidade.

 ✓ O uso de MD5, MD4, MD2 e outras funções de hash NÃO é permitido, mesmo para aplicativos não criptográficos.

Autenticação de mensagem

 ✓ Todos os novos códigos devem usar o HMAC com uma das funções de hash aprovadas. A saída do HMAC pode ser truncada para nada menos que 128 bits.

 ✓ HMAC-SHA1 só pode ser usado por motivos de compatibilidade.

 ✓ A chave HMAC deve ter pelo menos 128 bits. As chaves de 256 bits são recomendadas.

Algoritmos assimétricos

Encryption

 ✓ RSA é permitido. A chave DEVE ter pelo menos 2.048 bits e o preenchimento OAEP deve ser usado. O uso de preenchimento PKCS só é permitido por motivos de compatibilidade.

Assinaturas

 ✓ RSA é permitido. A chave DEVE ter pelo menos 2.048 bits e o preenchimento PSS deve ser usado. O uso de preenchimento PKCS só é permitido por motivos de compatibilidade.

 ✓ECDSA é permitido. A chave DEVE ter pelo menos 256 bits. A curva NIST P-256, P-384 ou P-521 deve ser usada.

Troca de Chaves

 ✓ ECDH é permitido. A chave DEVE ter pelo menos 256 bits. A curva NIST P-256, P-384 ou P-521 deve ser usada.

 ✓ ECDH é permitido. A chave DEVE ter pelo menos 256 bits. A curva NIST P-256, P-384 ou P-521 deve ser usada.

Apêndice C

Coleta de Evidências – Delta para ISO 27001

Onde você já alcançou ISO27001 conformidade, as seguintes (lacunas) delta não totalmente cobertas pelo ISO 27001 precisarão, no mínimo, ser revisadas como parte desta Certificação microsoft 365.

Observação

Como parte da avaliação de certificação do Microsoft 365, o analista de certificação determinará se algum dos controles iso 27001 mapeados não foi incluído como parte da avaliação iso 27001 e também pode decidir por exemplo controles que foram encontrados para fornecer mais garantia. Todos os requisitos ausentes da ISO 27001 precisarão ser incluídos em suas atividades de avaliação de certificação do Microsoft 365.

Proteção contra Malware – Antivírus

Se a proteção contra malware estiver em vigor usando o controle de aplicativo e for atestada no ISO 27001 Relatório, nenhuma investigação adicional será necessária. Se nenhum controle de aplicativo estiver em vigor, os analistas de certificação precisarão identificar e avaliar evidências de mecanismos de controle de aplicativo para evitar a detonação de malware no ambiente. Isso exigirá que você:

• Demonstre que o software antivírus está sendo executado em todos os componentes do sistema amostrados.

• Demonstre que o antivírus está configurado em todos os componentes do sistema amostrados para bloquear automaticamente o malware, colocar em quarentena & alerta ou alertar.

• O software antivírus DEVE ser configurado para registrar todas as atividades.

Gerenciamento de Patch – Patching

Como as auditorias iso 27001 não avaliam especificamente essa categoria, isso exigirá que você:

• Componentes de software e sistemas operacionais não suportados mais pelo fornecedor não devem ser usados no ambiente. As políticas de suporte devem estar em vigor para garantir que componentes de software/sistemas operacionais sem suporte sejam removidos do ambiente e um processo para identificar quando os componentes de software vão para o fim da vida útil deve estar em vigor

Verificação de vulnerabilidade

Como as auditorias iso 27001 não avaliam especificamente essa categoria, isso exigirá que você:

• Demonstre que a verificação trimestral de vulnerabilidades internas e externas é realizada.

• Confirme se a documentação de suporte está em vigor para correção de vulnerabilidade com base na classificação de risco e de acordo com a especificação da seguinte maneira:

✓ Corrija todos os problemas de risco críticos e altos em linha com a classificação de risco para verificação interna.

✓ Corrija todos os problemas de risco críticos, altos e médios em linha com a classificação de risco para verificação externa.

✓ Demonstrar que a correção é conduzida de acordo com a política de correção de vulnerabilidade documentada.

Firewall – Firewalls (ou tecnologias equivalentes)

Como as auditorias iso 27001 não avaliam especificamente essa categoria, isso exigirá que você:

• Demonstre que os firewalls estão instalados no limite do ambiente no escopo.

• Demonstre que os firewalls estão instalados entre as redes DMZ e confiáveis.

• Demonstre que todo o acesso público termina na DMZ.

• Demonstre que as credenciais administrativas padrão são alteradas antes da instalação no ambiente ao vivo.

• Demonstre que todo o tráfego permitido por meio dos firewalls passa por um processo de autorização, o que resulta na documentação de todo o tráfego com uma justificativa comercial.

• Demonstre que todos os firewalls estão configurados para remover o tráfego não definido explicitamente.

• Demonstre que os firewalls dão suporte apenas a criptografia forte em todas as interfaces administrativas que não são de console.

• Demonstre que as interfaces administrativas não console do firewall expostas à MFA de suporte à Internet.

• Demonstrar que as revisões de regra de firewall são realizadas pelo menos a cada 6 meses

Firewall – WAF (Firewalls de Aplicativo Web)

Crédito adicional será fornecido se um WAF for implantado para ajudar a proteger contra a miríade de ameaças e vulnerabilidades do aplicativo Web às quais o aplicativo pode ser exposto. Quando um WAF ou similar estiver presente, isso exigirá que você:

• Demonstre que o WAF está configurado no modo de defesa ativa ou monitorando mais com alertas.

• Demonstre que o WAF está configurado para dar suporte ao descarregamento de SSL.

• É configurado de acordo com o conjunto de regras do OWASP Core (3.0 ou 3.1) para proteger contra a maioria dos seguintes tipos de ataque:

✓ Problemas de protocolo e codificação.

✓ Injeção de cabeçalho, contrabando de solicitações e divisão de resposta.

✓ Ataques de passagem de arquivo e caminho.

✓ Ataques de RFI (inclusão remota de arquivo).

✓ Ataques de execução de código remoto.

✓ Ataques de injeção php.

✓ Ataques de script entre sites.

✓ Ataques de injeção de SQL.

✓ Ataques de correção de sessão.

Alterar controle

Como as auditorias iso 27001 não avaliam especificamente alguns elementos dos processos de Solicitação de Alteração, isso exigirá que você:

• Demonstre que as solicitações de alteração têm os seguintes detalhes:

✓ Impacto documentado.

✓ Detalhes de quais testes de funcionalidade devem ser realizados.

✓ Detalhes de todos os procedimentos de back-out.

• Demonstre que o teste de funcionalidade é realizado após a conclusão das alterações.

• Demonstre que as solicitações de alteração são assinadas após a realização do teste de funcionalidade.

Gerenciamento de Conta

Como as auditorias iso 27001 não avaliam especificamente alguns elementos dos processos de gerenciamento de conta, isso exigirá que você:

• Demonstre como ✓s são implementados para mitigar ataques de reprodução (por exemplo, MFA, Kerberos).
• Demonstre como as contas que não são usadas há três meses estão desabilitadas ou excluídas.
• ✓ou outras mitigações adequadas devem ser configuradas para proteger as credenciais do usuário. A seguinte política mínima de senha deve ser usada como diretriz:

✓ Comprimento mínimo de senha de 8 caracteres.

✓ Limite de bloqueio da conta de no máximo 10 tentativas.

✓ Histórico de senhas de no mínimo cinco senhas.

✓ Imposição do uso de senhas fortes.

• Demonstre que a MFA está configurada para todas as soluções de acesso remoto.

• Demonstre que a criptografia forte está configurada em todas as soluções de acesso remoto.

• Quando o gerenciamento de DNS público está fora do ambiente no escopo, todas as contas de usuário capazes de fazer modificações de DNS devem ser configuradas para usar o MFA.

Detecção e prevenção de intrusão (OPCIONAL)

Como as auditorias do ISO 27001 não avaliam especificamente alguns elementos dos processos de IDPS (Serviços de Prevenção e Detecção de Intrusões), isso exigirá que você:

• O IDPS DEVE ser implantado no perímetro do ambiente de suporte.

• As assinaturas IDPS DEVEM ser mantidas atuais no último dia.

• O IDPS DEVE ser configurado para inspeção do TLS.

• O IDPS DEVE ser configurado para TODO o tráfego de entrada e saída.

• O IDPS DEVE ser configurado para alerta.

Registro em log de eventos

Como as auditorias iso 27001 não avaliam especificamente alguns elementos dos processos de log de eventos de segurança, isso exigirá que você:

• Demonstre que os sistemas voltados para o público estão fazendo logon em uma solução de log centralizada que não está dentro da DMZ.

• Demonstre como um mínimo de 30 dias de dados de registro em log está disponível imediatamente, com 90 dias sendo retidos.

Revisão (Dados de Log)

Como as auditorias iso 27001 não avaliam especificamente alguns elementos dessa categoria, isso exigirá que você:

• Demonstre como as revisões diárias de log são conduzidas e como exceções e anomalias são identificadas mostrando como elas são tratadas.

Alertando

Como as auditorias iso 27001 não avaliam especificamente alguns elementos dessa categoria, isso exigirá que você:

• Demonstre como os eventos de segurança são configurados para disparar alertas para triagem imediata.

• Demonstre como a equipe está disponível 24/7 para responder aos alertas de segurança.

Gerenciamento de Riscos

Como as auditorias iso 27001 não avaliam especificamente alguns elementos de processos de avaliação de risco, isso exigirá que você:

• Demonstre que um processo formal de gerenciamento de risco está estabelecido.

Resposta a incidentes

Como as auditorias iso 27001 não avaliam especificamente alguns elementos de políticas e processos de resposta a incidentes, isso exigirá que você:

• Demonstre que o plano/procedimento de resposta a incidentes inclui:

✓ Procedimentos de resposta específicos para modelos de ameaça esperados.

✓ Recursos de tratamento de incidentes alinhados ao NIST Cybersecurity Framework (Identificar, Proteger, Detectar, Responder, Recuperar).

✓ O IRP abrange os sistemas no escopo.

✓ Treinamento anual para a equipe de resposta a incidentes.

Apêndice D

Coleta de Evidências – Deltas para DSS PCI

Onde você já alcançou a conformidade do PCI DSS, as seguintes (lacunas) delta não totalmente cobertas pelo PCI DSS precisarão, no mínimo, ser revisadas como parte desta Certificação microsoft 365.

Observação

Como parte da avaliação de certificação do Microsoft 365, o analista de certificação determinará se algum dos controles PCI DSS mapeados não foi incluído como parte da avaliação do PCI DSS e também pode decidir pelos controles de exemplo que foram encontrados para fornecer mais garantia. Todos os requisitos ausentes do DSS PCI precisarão ser incluídos nas atividades de avaliação de certificação do Microsoft 365.

Proteção contra Malware – Controle de Aplicativos

Se a proteção contra malware estiver em vigor por meio do uso do antivírus e for atestada no Relatório PCI DSS, nenhuma investigação adicional será necessária. Se nenhum antivírus estiver em vigor, os analistas de certificação precisarão identificar e avaliar evidências de mecanismos de controle de aplicativo para evitar a detonação de malware no ambiente. Isso exigirá que você:

• Demonstre como a aprovação do aplicativo é conduzida e confirme se isso foi concluído.

• Demonstre que existe uma lista completa de aplicativos aprovados com justificativa comercial.

• Forneça ou demonstre que a documentação de suporte está em vigor detalhando como o software de controle de aplicativo está configurado para atender a mecanismos de controle de aplicativo específicos (ou seja, permissão, assinatura de código etc.).

• Demonstre que, em todos os componentes do sistema amostrados, o controle do aplicativo está configurado como documentado.

Gerenciamento de Patch – Classificação de Risco

Como as auditorias PCI DSS não avaliam especificamente essa categoria, isso exigirá que você:

• Demonstre como a classificação de risco de vulnerabilidades é conduzida.

Verificação de vulnerabilidade

Como as auditorias PCI DSS não avaliam especificamente essa categoria, isso exigirá que você:

• Demonstre que a correção é conduzida de acordo com a política de correção de vulnerabilidade documentada.

Firewall – Firewalls (ou tecnologias equivalentes)

Como as auditorias PCI DSS não avaliam especificamente essa categoria, isso exigirá que você:

• Demonstre que os firewalls dão suporte apenas a criptografia forte em todas as interfaces administrativas que não são de console.

• Demonstre que as interfaces administrativas não console do firewall expostas à MFA de suporte à Internet.

Crédito adicional será fornecido se um WAF (Firewall de Aplicativo Web) for implantado para ajudar a proteger contra a miríade de ameaças e vulnerabilidades do aplicativo Web às quais o aplicativo pode ser exposto. Quando um WAF ou similar estiver presente, isso exigirá que você:

• Demonstre que o WAF está configurado no modo de defesa ativa ou monitorando mais com alertas.

• Demonstre que o WAF está configurado para dar suporte ao descarregamento de SSL.

• É configurado de acordo com o conjunto de regras do OWASP Core (3.0 ou 3.1) para proteger contra a maioria dos seguintes tipos de ataque:

✓ Problemas de protocolo e codificação.

✓ Injeção de cabeçalho, contrabando de solicitações e divisão de resposta.

✓ Ataques de passagem de arquivo e caminho.

✓ Ataques de RFI (inclusão remota de arquivo).

✓ Ataques de execução de código remoto.

✓ Ataques de injeção php.

✓ Ataques de script entre sites.

✓ Ataques de injeção de SQL.

✓ Ataques de correção de sessão.

Alterar controle

Como as auditorias PCI DSS não avaliam especificamente alguns elementos dos processos de Solicitação de Alteração, isso exigirá que você:

• Demonstre que as solicitações de alteração são levantadas antes de serem feitas em ambientes de produção.

• Demonstre que as alterações são autorizadas antes de entrar em produção.

• Demonstre que o teste de funcionalidade é realizado após a conclusão das alterações.

• Demonstre que as solicitações de alteração são assinadas após a realização do teste de funcionalidade.

Desenvolvimento/implantação de software seguro

Como as auditorias PCI DSS não acessam especificamente alguns elementos de processos seguros de desenvolvimento e implantação de software; isso exigirá a você:

• Os repositórios de código DEVEM ser protegidos pela MFA.

• Controles de acesso adequados DEVEM estar em vigor para proteger repositórios de código contra modificações de código mal-intencionadas.

Gerenciamento de Conta

Como as auditorias PCI DSS não avaliam especificamente alguns elementos dos processos de gerenciamento de conta, isso exigirá que você:

• Demonstre como os mecanismos de autorização são implementados para mitigar ataques de reprodução (por exemplo, MFA, Kerberos).

• Políticas de senha fortes ou outras mitigações adequadas devem ser configuradas para proteger as credenciais do usuário. A seguinte política mínima de senha deve ser usada como diretriz:

✓ Comprimento mínimo de senha de 8 caracteres.

✓ Limite de bloqueio da conta de no máximo 10 tentativas.

✓ Histórico de senhas de no mínimo cinco senhas.

✓ Imposição do uso de senhas fortes.

• Demonstre que a criptografia forte está configurada em todas as soluções de acesso remoto.

• Quando o gerenciamento de DNS público está fora do ambiente no escopo, todas as contas de usuário capazes de fazer modificações de DNS devem ser configuradas para usar o MFA.

Detecção e prevenção de intrusão (OPCIONAL)

Como as auditorias PCI DSS não avaliam especificamente alguns elementos dos processos de IDPS (Serviços de Detecção e Prevenção de Intrusões), isso exigirá que você:

• O IDPS DEVE ser configurado para inspeção do TLS.

• O IDPS DEVE ser configurado para TODO o tráfego de entrada e saída.

Gerenciamento de Riscos

Como as auditorias PCI DSS não avaliam especificamente alguns elementos de processos de avaliação de risco, isso exigirá que você:

• Demonstrar que a avaliação de risco inclui matrizes de impacto e probabilidade.

Resposta a incidentes

Como as auditorias PCI DSS não avaliam especificamente alguns elementos de políticas e processos de resposta a incidentes, isso exigirá que o desenvolvedor:

• Demonstre que os recursos de tratamento de incidentes se alinham ao NIST Cybersecurity Framework (Identificar, Proteger, Detectar, Responder, Recuperar).

Apêndice E

Coleta de Evidências – Deltas para SOC 2

Onde você já alcançou a conformidade do SOC 2, as seguintes (lacunas) delta não totalmente cobertas pelo SOC 2 precisarão ser revisadas como parte desta Certificação Microsoft 365.

Observação

Como parte da avaliação de Certificação do Microsoft 365, o analista de certificação determinará se algum dos controles do SOC 2 mapeados não foi incluído como parte de sua avaliação do SOC 2 e também poderá decidir pelos controles de exemplo que foram encontrados para fornecer mais garantia. Todos os requisitos ausentes da avaliação do SOC 2 precisarão ser incluídos como parte das atividades de avaliação de certificação do Microsoft 365.

Proteção contra Malware – Controle de Aplicativos

Se a proteção contra malware estiver em vigor por meio do uso de antivírus e for atestada em seu relatório SOC 2, nenhuma investigação adicional será necessária. Se nenhum antivírus estiver em vigor, os analistas de certificação precisarão identificar e avaliar evidências de mecanismos de controle de aplicativo para evitar a detonação de malware no ambiente. Isso exigirá que você:

• Forneça ou demonstre que a documentação de suporte está em vigor detalhando como o software de controle de aplicativo está configurado para atender a mecanismos de controle de aplicativo específicos (ou seja, permissão, assinatura de código etc.).

• Demonstre como a aprovação do aplicativo é conduzida e confirme se isso foi concluído.

• Demonstre que existe uma lista completa de aplicativos aprovados com justificativa comercial.

• Demonstre que, em todos os componentes do sistema amostrados, o controle do aplicativo está configurado como documentado.

Gerenciamento de Patch – Patching

Como as auditorias do SOC 2 não avaliam especificamente essa categoria, isso exigirá que você:

• Qualquer problema baixo, médio, alto ou crítico deve ser corrigido em janelas normais de atividade de patch.

• Componentes de software e sistemas operacionais não suportados mais pelo fornecedor não devem ser usados no ambiente. As políticas de suporte devem estar em vigor para garantir que componentes de software/sistemas operacionais sem suporte sejam removidos do ambiente e um processo para identificar quando os componentes de software forem de fim de vida devem estar em vigor.

Firewall – Firewalls

Como as auditorias do SOC 2 não avaliam especificamente os controles de alteração para listas de controle de acesso de firewall, isso exigirá que você:

• Demonstre que todo o tráfego permitido por meio dos firewalls passa por um processo de autorização que resulta na documentação de todo o tráfego com uma justificativa comercial.

• Demonstre que as revisões de regra de firewall são realizadas pelo menos a cada seis meses.

Crédito adicional será fornecido se um WAF (Firewall de Aplicativo Web) ou semelhante for implantado para ajudar a proteger contra a miríade de ameaças e vulnerabilidades do aplicativo Web às quais o aplicativo pode ser exposto. Quando um WAF ou similar estiver presente, isso exigirá que você:

• Demonstre que o WAF está configurado no modo de defesa ativa ou monitorando mais com alertas.

• Demonstre que o WAF está configurado para dar suporte ao descarregamento de SSL.

• É configurado de acordo com o conjunto de regras do OWASP Core ((3.0 ou 3.1) para proteger contra a maioria dos seguintes tipos de ataque:

 ✓ Problemas de protocolo e codificação.

 ✓ Injeção de cabeçalho, contrabando de solicitações e divisão de resposta.

 ✓ Ataques de passagem de arquivo e caminho.

 ✓ Ataques de RFI (inclusão remota de arquivo).

 ✓ Ataques de execução de código remoto.

 ✓ Ataques de injeção php.

 ✓ Ataques de script entre sites.

 ✓ Ataques de injeção de SQL.

 ✓ Ataques de correção de sessão.

Alterar controle

Como as auditorias do SOC 2 não avaliam especificamente alguns elementos dos processos de Solicitação de Alteração, isso exigirá que o desenvolvedor:

• Demonstre como os ambientes de desenvolvimento/teste são separados do ambiente de produção que impõe a separação de tarefas.

• Demonstre como os dados dinâmicos não são usados nos ambientes de desenvolvimento/teste.

• Demonstre que o teste de funcionalidade é realizado após a conclusão das alterações.

• Demonstre que as solicitações de alteração são assinadas após a realização do teste de funcionalidade.

Desenvolvimento/implantação de software seguro

Como as auditorias do SOC 2 não acessam especificamente alguns elementos de processos seguros de desenvolvimento e implantação de software; isso exigirá a você:

• Você deve ter um processo de desenvolvimento de software estabelecido e documentado que abrange todo o ciclo de vida de desenvolvimento de software.

• Os desenvolvedores devem passar por treinamento seguro de codificação de software pelo menos anualmente.

• Os repositórios de código DEVEM ser protegidos pela MFA.

• Controles de acesso adequados DEVEM estar em vigor para proteger repositórios de código contra modificações de código mal-intencionadas.

Gerenciamento de Conta

Como as auditorias SOC2 não avaliam especificamente alguns elementos dos processos de gerenciamento de conta, isso exigirá que você:

• Demonstre como os mecanismos de autorização são implementados para mitigar ataques de reprodução (por exemplo, MFA, Kerberos).

• Demonstre como as contas que não são usadas há três meses estão desabilitadas ou excluídas.

• Políticas de senha fortes ou outras mitigações adequadas devem ser configuradas para proteger as credenciais do usuário. A seguinte política mínima de senha deve ser usada como diretriz:

 ✓ Comprimento mínimo de senha de 8 caracteres.

 ✓ Limite de bloqueio da conta de no máximo 10 tentativas.

 ✓ Histórico de senhas de no mínimo 5 senhas.

 ✓ Imposição do uso de senhas fortes

• Demonstre que contas de usuário exclusivas são emitidas para todos os usuários.

• Quando o gerenciamento de DNS público está fora do ambiente no escopo, todas as contas de usuário capazes de fazer modificações de DNS devem ser configuradas para usar o MFA.

Detecção e prevenção de intrusões (OPCIONAL).

Como as auditorias do SOC 2 não avaliam especificamente alguns elementos dos processos de IDPS (Serviços de Detecção e Prevenção de Intrusões), isso exigirá que você:

• Assinaturas IDPS DEVEM ser mantidas atuais, no último dia

• IDPS DEVE ser configurado para inspeção do TLS

• O IDPS DEVE ser configurado para TODO o tráfego de entrada e saída

Registro em log de eventos

Como as auditorias do SOC 2 não avaliam especificamente alguns elementos dos processos de log de eventos de segurança, isso exigirá que você:

• Demonstre como, em todos os componentes do sistema dentro do conjunto de exemplo, o sistema a seguir está configurado para registrar os eventos a seguir

 ✓ Acesso do usuário aos componentes do sistema e aos aplicativos.

 ✓ Todas as ações executadas por um usuário com privilégios elevados.

 ✓ Tentativas de acesso lógico inválidas.

Demonstrar que os eventos registrados contêm; no mínimo, as seguintes informações:

 ✓ Usuário.

 ✓ Tipo de evento.

 ✓ Data e hora.

 ✓ Indicador de êxito/falha.

 ✓ Rótulo para identificar o sistema afetado.

• Demonstre que todos os componentes do sistema dentro do conjunto de exemplos estão configurados para utilizar a sincronização de tempo e que eles são iguais aos servidores de tempo primário/secundário.

• Demonstre que os sistemas voltados para o público estão fazendo logon em uma solução de log centralizada que não está dentro da DMZ.

• Demonstre que os sistemas voltados para o público estão fazendo logon em uma solução de log centralizada que não está dentro da DMZ.

• Demonstre como a solução de log centralizada está protegida contra adulteração não autorizada de dados de log.

• Demonstre como um mínimo de 30 dias de dados de registro em log está disponível imediatamente, com 90 dias ou mais sendo retidos.

Gerenciamento de Riscos

Como as auditorias SOC2 não avaliam especificamente alguns elementos de processos de avaliação de risco, isso exigirá que você:

• Demonstre que uma avaliação formal de risco é realizada pelo menos anualmente.

Resposta a incidentes.

Como as auditorias SOC2 não avaliam especificamente alguns elementos de políticas e processos de resposta a incidentes, isso exigirá que você:

• Demonstre que o plano/procedimento de resposta a incidentes inclui:

 ✓ Procedimentos de resposta específicos para modelos de ameaça esperados.

 ✓ Processo de comunicação documentado para garantir a notificação oportuna dos principais stakeholders (marcas/adquirentes de pagamento, órgãos reguladores, autoridades de supervisão, diretores, clientes etc.

Apêndice F

Tipos de implantação de hospedagem

A Microsoft reconhece que você implantará aplicativos e armazenará o código de aplicativo/suplemento em diferentes ambientes de hospedagem. As responsabilidades gerais de alguns dos controles de segurança dentro da Certificação Microsoft 365 dependerão do ambiente de hospedagem que está sendo usado. O apêndice F analisa tipos comuns de implantação e mapeia-os em relação aos controles de segurança avaliados como parte do processo de avaliação. Os seguintes tipos de implantação de hospedagem foram identificados:

Tipos de hospedagem	Descrição
ISV hospedado	Os tipos hospedados no ISV podem ser definidos como onde você é responsável pela infraestrutura usada para dar suporte ao ambiente de aplicativo/suplemento. Isso pode estar fisicamente localizado em seus próprios data centers ou data centers de terceiros com um serviço de co-localização. Em última análise, você tem total propriedade e controle administrativo sobre a infraestrutura de suporte e o ambiente operacional.
IaaS (infraestrutura como serviço) (https://azure.microsoft.com/overview/what-is-iaas/)	A infraestrutura como serviço é um serviço fornecido pelo qual a infraestrutura de suporte físico é gerenciada e mantida em seu nome pelo CSP (provedor de serviços de nuvem). Normalmente, rede, armazenamento, servidores físicos e a infraestrutura de virtualização são responsabilidade do CSP. O Sistema Operacional, Middleware, Runtime, Dados e Aplicativos são responsabilidades de você. Os recursos de firewall também seriam gerenciados e mantidos por terceiros, no entanto, a manutenção da base de regras de firewall normalmente ainda seria responsabilidade dos consumidores.
PaaS (plataforma como serviço/sem servidor) (https://azure.microsoft.com/overview/what-is-paas/)	Com o Platform as a Service, você é provisionado com uma plataforma gerenciada apresentando um serviço que pode ser consumido. Você não precisa executar funções de sysadmin, pois o sistema operacional e a infraestrutura de suporte são gerenciados pelo CSP. Isso normalmente seria usado quando as organizações não querem se preocupar em apresentar um serviço Web e, em vez disso, podem se concentrar na criação do código-fonte do aplicativo Web e na publicação do aplicativo Web nos serviços Web gerenciados pela nuvem. Outro exemplo pode ser um serviço de banco de dados em que a conectividade é dada a um banco de dados, no entanto, a infraestrutura de suporte e o aplicativo de banco de dados são abstraídos do consumidor. Observação: Sem servidor e PaaS são semelhantes, portanto, para fins do Microsoft 365 Certification Hosting Deployment Type's Serverless e PasS são considerados os mesmos
Híbrida hospedada	Com o tipo hospedado híbrido, você pode utilizar vários tipos hospedados para dar suporte a várias partes do ambiente de suporte. Isso pode ser mais o caso em que aplicativos/suplementos são utilizados em várias pilhas do Microsoft 365. Embora a Certificação Microsoft 365 dê suporte a onde aplicativos/complementos em vários serviços do Microsoft 365 são desenvolvidos, uma avaliação de todo o ambiente de suporte (entre aplicativos/suplementos) precisaria ser avaliada de acordo com cada um dos "Mapeamentos de Tipo Hospedado" aplicáveis. Ocasionalmente, você pode utilizar diferentes tipos hospedados para um único suplemento, onde isso está sendo realizado, a aplicabilidade dos critérios ainda precisará seguir os critérios "Mapeamentos de Tipo Hospedado" entre os vários tipos hospedados.
Hospedagem Compartilhada	A hospedagem compartilhada é onde você está hospedando o ambiente em uma plataforma compartilhada por vários consumidores individuais. A Especificação de Certificação do Microsoft 365 não foi gravada para dar conta disso devido à adoção da nuvem, a hospedagem compartilhada não é comum. Se você acredita que isso está sendo usado, entre em contato com a Microsoft, pois requisitos adicionais precisarão ser criados para responder pelos riscos adicionais nesse tipo de hospedagem.

Apêndice G

Saiba mais

Visão geral do Programa de Conformidade de Aplicativo do Microsoft 365 O que é o Atestado do Microsoft 365 App Publisher?O que é a Certificação do Microsoft 365?

Glossário

AIA

*O Acesso de Informações de Autoridade é um descritor de local de serviço usado para localizar o certificado da autoridade de certificado emissora.

CRL

*A Lista de Revogação de Certificados fornece um meio para um ponto de extremidade SSL (Secure Sockets Layer) para verificar se um certificado recebido de um host remoto é válido e confiável.

Pontuação CVSS

*Common Vulnerability Score System é um padrão publicado que mede a vulnerabilidade e calcula uma pontuação numérica com base em sua gravidade.

Diretrizes de gerenciamento de patch do CVSS

• Crítico (9.0 - 10.0)
• Alta (7.0 - 8.9)
• Médio (4.0 – 6.9)
• Baixo (0,0 - 3,9)

DMZ

*A zona desmilitarizada é uma rede intermediária física ou lógica que interage diretamente com redes externas ou não proprietárias, mantendo a rede interna e privada do host separada e isolada.

EUII

Informações identificáveis do usuário final.

RGPD

*O Regulamento Geral de Proteção de Dados é uma regulamentação de privacidade e proteção de dados da União Europeia (UE) para todos os dados dos cidadãos da UE, independentemente de onde seu site de aplicativo esteja localizado.

HSTS

*HTTP Strict Transport Security utiliza um cabeçalho de resposta HTTP instruindo o navegador da Web a acessar apenas o conteúdo por HTTPS. Isso foi projetado para proteger contra ataques de downgrade e sequestro de cookie.

IEC

*Comissão Eletrotécnica Internacional.

ISMOS

*Sistema de Gerenciamento de Segurança de Informações.

ISV

Fornecedores de segurança independentes são indivíduos e organizações que desenvolvem, comercializam e vendem softwares executados em plataformas de software e hardware de terceiros.

ISO 27001

Uma estrutura de especificação do sistema de gerenciamento de segurança de informações para todos os controles técnicos em um processo de gerenciamento de riscos de organizações.

LFI

A Inclusão de Arquivos Local permite que um invasor inclua arquivos em um servidor por meio do navegador da Web.

NIST

O National Institute of Standards (NIST), uma agência não regulatória do Departamento de Comércio dos EUA, oferece diretrizes para organizações do setor privado nos EUA para avaliar e aprovar sua capacidade de prevenir, detectar e responder a ataques cibernéticos.

Alterações não significativas

• Correções de bugs menores.
• Pequenas melhorias de desempenho.
• Sistemas operacionais/bibliotecas/patches de aplicativo de cliente e servidor.

OCSP

O Protocolo de Status do Certificado Online é usado para marcar o status de revogação de certificados digitais X.509.

OII

Informações identificáveis organizacionais.

OWASP

Abra o Projeto de Segurança de Aplicativo Web.

PCI DSS

Padrão de Segurança de Dados do Setor de Cartões de Pagamento, uma organização que mantém padrões para a segurança dos dados do titular do cartão em todo o mundo.

Teste de caneta

O teste de penetração é um método de teste de um aplicativo Web simulando ataques mal-intencionados para encontrar vulnerabilidades de segurança que um invasor poderia explorar.

SAML

A Linguagem de Marcação de Declaração de Segurança é um padrão aberto para a troca de dados de autenticação e autorização entre o usuário, o provedor de identidade e o provedor de serviços.

Dados confidenciais

• Acessar dados de controle.
• Conteúdo do cliente.
• Informações de identidade do usuário final.
• Suporte a dados.
• Dados pessoais públicos.
• Informações de pseudônimo do usuário final.

Alterações significativas

• Realocação do ambiente de hospedagem.
• Atualizações importantes para a infraestrutura de suporte; por exemplo, implementação de um novo firewall, atualizações importantes para serviços frontais, etc.
• Adição de recursos e /ou extensões ao seu aplicativo.
• Atualizações ao aplicativo que captura dados confidenciais adicionais.
• Alterações nos fluxos de dados ou modelos de autorização do aplicativo
• Adição de pontos de extremidade de API ou funções de ponto de extremidade de API.

SOC 2

Controle de Organização de Serviço 2, um procedimento de auditoria técnica composto por cinco Princípios do Serviço de Confiança para garantir que os provedores de serviços gerenciem com segurança os dados e a privacidade dos clientes de uma organização.

SSL

Camada de soquetes seguros.

TLS

Segurança da Camada de Transporte.