Visão geral da estrutura de certificação do Microsoft 365
Este artigo fornece informações detalhadas, incluindo a lista de controles de segurança de certificação do Microsoft 365 e suporte para ISVs e desenvolvedores submetidos à Certificação Microsoft 365.
A Certificação microsoft 365 é uma auditoria independente de segurança e privacidade de aplicativos, suplementos e ambiente de back-end (coletivamente chamado de aplicativos) integrando-se à plataforma Microsoft 365. Os aplicativos aprovados serão designados como Microsoft 365 Certificados em todo o ecossistema do Microsoft 365 e podem ser encontrados facilmente nos marketplaces do Microsoft 365 por meio de filtros de pesquisa e identidade visual focados em conformidade. Os ISVs terão a oportunidade de compartilhar atributos de conformidade de seus aplicativos em páginas dedicadas neste conjunto de documentação.
A Certificação microsoft 365 está disponível para os seguintes tipos de aplicativos:
- Suplementos do Microsoft 365 (Word, Excel, Outlook, PowerPoint, OneNote, Project)
- Aplicativos do Teams
- Soluções do SharePoint
- Aplicativos Web (SaaS)
Importante
A Certificação microsoft 365 é uma revisão rigorosa da segurança e conformidade de um aplicativo em relação à estrutura de Certificação do Microsoft 365 e requer um compromisso de tempo e recursos substanciais para ser concluída. Examine as estruturas de controle de conformidade para ver se seu aplicativo está qualificado antes de iniciar a certificação. Para qualquer pergunta, envie um email appcert@microsoft.com.
Termos
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.
Pré-requisitos
Antes que a Certificação do Microsoft 365 possa ser concedida, um aplicativo deve concluir o seguinte:
Verificação do editor Quando um aplicativo tem um editor verificado, a organização que publica o aplicativo foi verificada como autêntica pela Microsoft. Verificar um aplicativo inclui o uso de uma conta CPP (Microsoft Cloud Partner Program) que foi verificada e associar o PartnerID verificado a um registro de aplicativo. Obter o editor verificado
O Publisher Attestation é um processo de autoatendimento em que os ISVs respondem a um conjunto de perguntas sobre as práticas de segurança e tratamento de dados do aplicativo. Os aplicativos podem ser atestados pelo editor no Microsoft Partner Center e receber filtros inválidos e dedicados no Microsoft AppSource marketplace após a conclusão.
Examine os critérios de controle Não é necessário cumprir todos os controles para receber uma certificação. No entanto, os limites (que não serão divulgados) estão em vigor para cada um dos três domínios de segurança discutidos neste documento de visão geral e devem ser passados. 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.
Importante
Período de envio: Em média, o processo de avaliação deve levar 30 dias, desde que os ISVs possam marcar 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.
Escopo de certificação
O ambiente no escopo 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 adicionais conectados ao ambiente no escopo 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 separados de recuperação de desastre também precisarão ser incluídos no ambiente no escopo, pois esses ambientes seriam necessários para atender ao serviço caso algo acontecesse com o ambiente primário. Ambientes de backup remotos também precisarão ser incluídos, pois esses ambientes podem armazenar dados da Microsoft e, portanto, os controles de segurança adequados precisarão estar em vigor.
O termo componentes do sistema no escopo faz referência a TODOS os dispositivos e sistemas que são usados no ambiente definido no escopo. Os componentes no escopo incluem, mas não se limitam a:
- Aplicativos Web
- Servidores (físicos ou virtuais que podem ser on-prem ou na nuvem)
- NSCs (Controles de Segurança de Rede), como firewalls
- Opções
- Balanceadores de carga
- Infraestrutura virtual
- Portais de gerenciamento Web do provedor de nuvem
- Recursos de nuvem (Máquinas Virtuais, Serviço de Aplicativo, Contas de Armazenamento, Instâncias EC2 etc.)
Importante
Os componentes públicos do sistema são suscetíveis a ataques de atores de ameaças externas e, portanto, correm um risco muito maior. Normalmente, esses sistemas seriam segmentados para longe de outros componentes internos do sistema usando um NSC (controle de segurança de rede) criando uma zona desmilitarizada (DMZ). A intenção é que a DMZ seja menos confiável do que a rede interna e a segurança adicional ajudariam a proteger ainda mais os sistemas internos e os dados caso os sistemas voltados para o público fiquem comprometidos. Idealmente, um DMZ seria usado, no entanto, isso não é viável ou mesmo necessário em alguns cenários de implantação.
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 ao ambiente no escopo 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. Os analistas 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 relatórios PCI DSS, Atestado de Conformidade (AOC), ISO 27001 ou SOC 2 Tipo II.
O apêndice C 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 exfiltra dados do Microsoft 365:
- ISV hospedado
- IaaS hospedado
- PaaS/host sem servidor
- Híbrida hospedada
- Hospedado compartilhado
Quando IaaS ou PaaS é implantado, as evidências que validam o alinhamento do ambiente a esses tipos de implantação devem ser fornecidas.
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, diferentes tipos de dispositivo (ou seja, servidores, NSCs, Roteadores etc.) e local. Um exemplo adequado será selecionado no início do processo de certificação. A tabela a seguir deve ser usada como um guia em que a amostragem será determinada com base nos fatores detalhados acima:
| Tamanho da população | Amostra |
|---|---|
| <=5 | 1 |
| >5 & <10= | 2 |
| >10 & <=30 | 3 |
| >30 | 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 de ponta a ponta
Para iniciar a Certificação do Microsoft 365:
Navegue até o Partner Center e conclua o Atestado do Editor. Se o envio for superior a três meses, reenviar para revisão e validação.
No centro de parceiros, selecione "Iniciar Certificação" para iniciar o envio inicial do documento. Isso ajudará os analistas de certificação a determinar o que está no escopo da avaliação com base na arquitetura do aplicativo e como ele lida com os dados da Microsoft.
Dica
Siga o guia de instruções para obter instruções passo a passo para obter seu aplicativo Certificado microsoft 365.
O processo de certificação é realizado em dois estágios, conforme descrito abaixo:
O Envio inicial de Documentos ajuda o analista a entender o aplicativo, os fluxos de dados, definir o ambiente no escopo, identificar quais controles de segurança são aplicáveis e determinar os componentes do sistema dos quais as evidências precisarão ser coletadas. O ISV deve fornecer informações solicitadas para ajudar o analista de certificação a concluir essa fase do processo, que é aproximadamente 5% do processo geral.
A Revisão Completa de Evidências é o processo pelo qual o ISV envia artefatos de evidência demonstrando como o ambiente no escopo está atendendo aos controles de segurança. Haverá várias interações entre o ISV e o analista durante essa fase de auditoria, que é o restante do processo.
Avaliação
Depois que o envio inicial do documento for aceito, o conjunto de controles de segurança será exibido automaticamente no portal. Os ISVs devem fornecer evidências para cada controle que demonstre que o controle está em vigor e têm 60 dias para enviar todas as evidências. Um analista examinará as evidências e aprovará o controle ou solicitará evidências novas ou adicionais.
Certificação
Depois que um envio é validado por um analista, os ISVs são notificados da decisão de certificação. Os aplicativos premiados com uma certificação receberão um selo em seu aplicativo no AppSource e páginas dedicadas de documentos da Microsoft com relatórios detalhados de seus atributos de segurança e conformidade.
Revisar e recertificar
Os aplicativos certificados do Microsoft 365 são necessários para passar pela recertificação anualmente. Isso exigirá a revalidação dos controles no escopo em relação ao ambiente atual no escopo. Esse processo pode começar até 90 dias antes da expiração da certificação. As certificações existentes não expirarão 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 a 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 seu aplicativo, e os ISVs serão proibidos de anunciar seu aplicativo como Certificado do Microsoft 365.
Se um aplicativo sofrer alterações significativas fora do período de envio de recertificação, os ISV's serão solicitados a notificar o Programa de Conformidade do Aplicativo Microsoft para quaisquer atualizações.
Envio inicial de documento
Seu envio inicial deve incluir as seguintes informações:
| Visão geral da documentação | Detalhes da documentação |
|---|---|
| Descrição do aplicativo/suplemento | 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 o ISV não executar testes anuais de penetração no momento, a Microsoft cobrirá o custo do teste de caneta 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 aplicativo. Isso deve incluir todos os ambientes de hospedagem e a infraestrutura de suporte ao aplicativo. 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 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 o Microsoft 365 Data EUII e o OII estão sendo recebidos e armazenados | |
| ✓ O período de retenção de dados. | |
| ✓ Por que os Dados do Microsoft 365 estão sendo capturados. | |
| ✓ Onde os dados do Microsoft 365 são armazenados (também devem ser incluídos 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 ser considerada ao revisar os controles de segurança de certificação do Microsoft 365. Atualmente, há suporte para os quatro 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. | |
| ✓ FedRAMP FedRAMP Authorization Package and FedRAMP Readiness Assessment Report. | |
| Dependências da Web | Documentação que lista todas as dependências usadas pelo aplicativo com 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 de nuvem/recurso 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 no guia de envio de documentação inicial
- Documentos de política
- Processar documentos
- Configurações do sistema
- Alterar tíquetes
- Alterar registros de controle
- Relatórios do sistema
- Atas de reunião
- Contratos/contratos
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 específicos 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 todos os controles da Certificação Microsoft 365 foram atendidos.
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
O aplicativo e sua infraestrutura de suporte e a documentação de suporte serão avaliados nos três domínios de segurança a seguir:
- Segurança do aplicativo
- Segurança operacional/implantação segura
- 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 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 esse controle não ser implementado. 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.
- Não há 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 do aplicativo
O domínio de segurança do aplicativo se concentra em três áreas:
- Validação de permissão do GraphAPI
- Verificações de conectividade externa
- Testes de Penetração
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 o ISV para validar a justificativa comercial para as permissões que estão sendo solicitadas. Quaisquer discrepâncias no envio do Publisher Attestation encontradas durante esta revisão precisarão ser corrigidas.
Verificações de conectividade externa
Como parte da avaliação, um passo a passo leve da funcionalidade dos aplicativos será realizado para identificar quaisquer conexões que estejam sendo feitas 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 penetração
Uma revisão adequada dos riscos associados ao 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 uma vez implantado seu aplicativo opera o acesso autônomo apenas ao serviço da Microsoft, como o GraphAPI, o teste de penetração não será necessário. O teste de penetração ainda será necessário se o ambiente no escopo estiver hospedado no Azure.
Escopo de teste de penetração
Para testes de penetração de infraestrutura interna e externa, todas as 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 quaisquer ambientes adicionais que dão 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 para testes de penetração, é 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 nas atividades de teste de penetração all.
É recomendável que os testes de penetração de aplicativos Web sejam realizados em relação ao ambiente de produção ao vivo. No entanto, seria aceitável realizar testes apenas do aplicativo Web usando um ambiente de teste/UAT, desde que seja confirmado no relatório de teste de penetração que a mesma base de código estava operando no ambiente de teste/UAT no momento do teste.
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.
Observação
O teste de penetração interna deve ser realizado, a menos que o ambiente de hospedagem seja classificado apenas como PaaS.
Requisitos de teste de penetração
Os relatórios de teste de penetração serão revisados para garantir que não haja vulnerabilidades que atendam aos seguintes critérios de falha automática descritos nos controles abaixo.
| Tipo de critério | Controles de teste de penetração |
|---|---|
| Critérios gerais | O aplicativo Web e os testes internos (se aplicáveis) e de penetração de infraestrutura externa 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 do ISV. | |
| 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 claramente documentado no relatório de teste de penetração. | |
| A menos que o ambiente se alinhe ao PaaS, as redes internas completas devem ser incluídas no escopo do teste de penetração e devem ser claramente documentadas no relatório de teste de penetração. | |
| O teste de penetração de aplicativo Web DEVE incluir todas as classes de vulnerabilidade; por exemplo, o OWASP Top 10 ou OWAS Top 25 CWE mais atual. A recomendação é que isso seja detalhado no relatório de teste de penetração, caso contrário, será difícil demonstrar. | |
| Vulnerabilidades ou vulnerabilidades críticas e de alto risco consideradas como uma falha automática DEVEM ser retestadas pela empresa de testes de penetração e claramente realçadas como corrigidas no relatório de teste de penetração. | |
| Critérios de falha automática: | Presença de um sistema operacional sem suporte ou biblioteca JavaScript 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 de requisitos de teste de penetração acima 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 para a 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 no escopo. 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 após a conclusão do teste de caneta 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 | Proporção 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 | Proporção 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 de um aplicativo com as melhores práticas de segurança.
Controles
| Família control | Controls |
|---|---|
| Treinamento de conscientização | Forneça evidências de que a organização fornece treinamento de conscientização de segurança estabelecido para usuários do sistema de informações (incluindo gerentes, executivos seniores e contratados) como parte do treinamento inicial para novos usuários ou quando exigido por alterações no sistema de informações. |
| Forneça evidências de uma frequência definida pela organização de treinamento de conscientização. | |
| Forneça evidências de documentação e monitoramento de atividades individuais de conscientização de segurança do sistema de informações, mantendo registros de treinamento individuais em uma frequência definida pela organização. | |
| Proteção contra malware – antivírus | Forneça evidências de que sua solução anti-malware está ativa e habilitada em todos os componentes do sistema amostrados e configurada para atender aos seguintes critérios: |
| Se o antivírus, essa verificação de acesso estiver habilitada e as assinaturas estiverem atualizadas dentro de um dia e bloqueará automaticamente malware ou alertas e quarentenas quando o malware é detectado. | |
| OU se EDR/NGAV (Detecção de Ponto de Extremidade e Resposta/Antivírus de Próxima Geração) a verificação periódica estiver sendo executada, os logs de auditoria serão gerados e ele será mantido atualizado continuamente e tem recursos de autoatendimento. | |
| Se o EDR/NGAV bloquear o malware conhecido e ele identificar e bloquear novas variantes de malware com base em comportamentos macro, bem como ter recursos de lista de segurança completos. | |
| Proteção contra malware – controles de aplicativos | Forneça evidências demonstrativas de que existe uma lista aprovada de software/aplicativos com justificativa comercial e está atualizada. |
| Que cada aplicativo passa por um processo de aprovação e aprovação antes de sua implantação | |
| Essa tecnologia de controle de aplicativo está ativa, habilitada e configurada em todos os componentes do sistema amostrados, conforme documentado. | |
| Gerenciamento de patchs - patching e classificação de risco | Documentação da política de fornecimento que rege como novas vulnerabilidades de segurança são identificadas e atribuídas 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. | |
| Forneça evidências de que todos os componentes do sistema amostrados estão sendo alinhados com as organizações definidas como timeframes de patch e sistemas operacionais sem suporte e componentes de software não estão em uso. Quando aplicável, isso deve incluir base de código se a tecnologia sem servidor ou o PaaS for usado ou a infraestrutura e a base de código se o IaaS for usado. | |
| Diretrizes de período de patch: Crítico – dentro de 14 dias, Alto – Dentro de 30 dias, Médio – Dentro de 60 dias. | |
| 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. | |
| NSC (Controles de Segurança de Rede) | Forneça evidências de que os NSC (Controles de Segurança de Rede) estão instalados no limite do ambiente no escopo e instalados entre a rede de perímetro e as redes internas. |
| E se Hybrid, On-prem, IaaS também fornecer evidências de que todo o acesso público termina na rede de perímetro. | |
| Valide se todos os NSC (Controles de Segurança de Rede) estão configurados para remover o tráfego não definido explicitamente dentro da base de regras e que as revisões de regra NSC (Controles de Segurança de Rede) são realizadas pelo menos a cada 6 meses. | |
| Alterar o controle | Forneça evidências de que todas as alterações introduzidas nos ambientes de produção são implementadas por meio de solicitações de alteração documentadas que contêm o impacto da alteração, detalhes dos procedimentos de back-out, testes a serem realizados, revisão e aprovação pelo pessoal autorizado. |
| Forneça evidências de que ambientes separados existem para que: ambientes de desenvolvimento e teste/preparo imponham a separação de tarefas do ambiente de produção, a separação de tarefas é imposta por meio de controles de acesso, os dados confidenciais de produção não estão em uso nos ambientes de desenvolvimento ou teste/preparo. | |
| Desenvolvimento/implantação de software seguro | Forneça políticas e procedimentos que dão suporte ao desenvolvimento seguro de software e incluam padrões do setor e/ou melhores práticas para codificação segura. Como o Open Web Application Security Project (OWASP) Top 10 ou SysAdmin, Audit, Network and Security (SANS) Top 25 Common Weakness Enumeration (CWE). |
| Forneça evidências de que os repositórios de código são protegidos para que: todas as alterações de código passem por um processo de revisão e aprovação por um segundo revisor antes de serem mescladas com main branch, os controles de acesso apropriados estão em vigor, todo o acesso é imposto por meio da MFA (autenticação multifator) | |
| Forneça evidências de que todas as versões feitas nos ambientes de produção são revisadas e aprovadas antes de sua implantação. | |
| Account management | Forneça evidências de que as credenciais padrão estão desabilitadas, removidas ou alteradas entre os componentes do sistema amostrados. |
| Forneça evidências de que um processo está em vigor para proteger contas de serviço (harden) e que esse processo foi seguido. | |
| Forneça evidências de que: contas de usuário exclusivas são emitidas para todos os usuários, princípios de privilégio mínimo do usuário estão sendo seguidos dentro do ambiente, uma política forte de senha/senha ou outras mitigações adequadas estão em vigor, um processo está em vigor e seguido pelo menos a cada três meses para desabilitar ou excluir contas não usadas dentro de três meses. | |
| Valide se o MFA está configurado 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. | |
| Eventlogging de segurança, revisão e alertas | Forneça evidências 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. |
| Forneça evidências de que os logs estão sendo revisados periodicamente e quaisquer possíveis eventos/anomalias de segurança identificados durante o processo de revisão são investigados e abordados | |
| Forneça evidências de que as regras de alerta estão configuradas para que os alertas sejam disparados para investigação para os seguintes eventos de segurança, quando aplicável: criação/modificações de conta privilegiada, atividades ou operações de alto risco privilegiados/de alto risco, eventos de malware, adulteração de log de eventos, eventos IDPS /WAF. (se configurado) | |
| Gerenciamento de risco de informações | Forneça evidências de que uma política/processo formal de gerenciamento de risco de segurança de informações ratificada está documentada e estabelecida. |
| Forneça evidências de que uma avaliação formal de risco de segurança da informação em toda a empresa é realizada pelo menos anualmente. | |
| OR for Targeted Risk Analysis: uma análise de risco direcionada é documentada e executada no mínimo a cada 12 meses para cada instância em que um controle tradicional ou prática recomendada do setor não está em vigor, onde uma limitação de design/tecnologia cria o risco de introduzir uma vulnerabilidade no ambiente ou coloca usuários e dados em risco, após suspeita ou confirmação de compromisso. | |
| Valide se a avaliação de risco de segurança da informação inclui componente do sistema ou recurso afetado, ameaças e vulnerabilidades ou matrizes equivalentes, de impacto e de probabilidade ou equivalente, a criação de um plano de tratamento de risco/registro de risco. | |
| Forneça evidências de que você tem um processo de gerenciamento de riscos em vigor que avalia e gerencia riscos associados a fornecedores e parceiros de negócios e pode identificar e avaliar alterações e riscos que podem afetar seu sistema de controles internos. | |
| Resposta a incidentes de segurança | Forneça seu IRP (plano/procedimento de resposta a incidentes de segurança) ratificado. |
| Forneça evidências que descrevem como sua organização responde a incidentes, mostrando como ela é mantida e que inclui detalhes da equipe de resposta a incidentes, incluindo informações de contato, um plano de comunicação interno durante o incidente e comunicação externa a partes relevantes, como principais partes interessadas, marcas de pagamento e adquirentes, órgãos reguladores (por exemplo, 72 horas para GDPR), autoridades de supervisão, diretores, clientes, bem como etapas para atividades como classificação de incidentes, contenção, mitigação, recuperação e retorno às operações comerciais normais, dependendo do tipo de incidente | |
| Forneça evidências de que todos os membros da equipe de resposta a incidentes receberam treinamento anual que lhes permite responder a incidentes. | |
| Forneça evidências de que a estratégia de resposta a incidentes e a documentação de suporte são revisadas e atualizadas com base em qualquer lição aprendida em um exercício de tabela superior, lições aprendidas ao responder a um incidente, alterações organizacionais. | |
| Plano de continuidade de negócios e plano de recuperação de desastre | Forneça evidências de que a documentação existe e é mantida, o que descreve o plano de continuidade dos negócios. |
| Forneça evidências de que o plano de continuidade de negócios detalha o pessoal relevante e suas funções e responsabilidades, incluindo: funções de negócios com requisitos e objetivos de contingência associados, procedimentos de backup de sistema e dados, configuração e agendamento/retenção, prioridade de recuperação e metas de período, um plano de contingência detalhando ações, etapas e procedimentos a serem seguidos para retornar sistemas de informações críticos, funções comerciais e serviços para operação no caso de um plano de contingência detalhando ações, etapas e procedimentos a serem seguidos para retornar sistemas de informações críticos, funções comerciais e serviços para operação no caso de um plano de contingência. interrupção inesperada e não programada, um processo estabelecido que abrange a eventual restauração completa do sistema e retorna ao estado original. | |
| Forneça evidências de que a documentação existe, é mantida e descreve o plano de recuperação de desastres e inclui no mínimo: pessoal e suas funções, responsabilidades e processo de escalonamento, inventário dos sistemas de informações usados para dar suporte a funções e serviços comerciais críticos, procedimentos e configuração de backup de sistemas e dados, um plano de recuperação detalhando ações e procedimentos a serem seguidos para restaurar sistemas de informações críticos e dados em operação. | |
| Forneça evidências de que o plano de continuidade dos negócios e o plano de recuperação de desastres estão sendo revisados pelo menos a cada 12 meses para garantir que ele permaneça válido e eficaz durante situações adversas. | |
| Forneça evidências de que o plano de continuidade dos negócios é atualizado com base na revisão anual do plano, todos os funcionários relevantes que recebem treinamento sobre suas funções e responsabilidades atribuídas nos planos de contingência, os planos/s estão sendo testados por meio de exercícios de continuidade de negócios ou recuperação de desastres, resultados de teste estão documentados, incluindo lições aprendidas com o exercício 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. (O TLS v1.2+ é recomendado). 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 que validem a configuração TLS É TLS1.2 ou superior dentro dos requisitos de configuração de perfil TLS e que um inventário de chaves e certificados confiáveis é mantido e mantido. |
| Fornecer evidências mostra que a compactação TLS está desabilitada para todos os serviços públicos que lidam com solicitações da Web para evitar o vazamento de informações de Taxa de Compactação Facilitado (CRIME) e o TLS HSTS está habilitado e configurado para 180 dias em todos os sites. | |
| Dados em repouso | Forneça evidências de que os dados em repouso são criptografados de acordo com os requisitos de perfil de criptografia, usando algoritmos de criptografia como AES (Advanced Encryption Standard), RSA e Twofish com tamanhos de chave de criptografia de 256 bits ou superiores. |
| Retenção, backup e descarte de dados | Forneça uma prova de que um período de retenção de dados aprovado está formalmente estabelecido e documentado. |
| Forneça evidências de que os dados são mantidos apenas para o período de retenção definido, conforme discutido no controle anterior. | |
| Forneça evidências de que os processos estão em vigor para excluir dados com segurança após o período de retenção. | |
| Forneça evidências de que um sistema de backup automatizado está em vigor e configurado para executar backups em horários agendados. | |
| Fornecer informações de backup de evidências é testado de acordo com o procedimento de agendamento de backup e restaurado periodicamente para confirmar a confiabilidade e integridade dos dados. | |
| Forneça evidências de que os controles de acesso e os mecanismos de proteção apropriados (ou seja, backups imutáveis) são implementados para garantir que backups/instantâneos do sistema sejam protegidos contra acesso não autorizado e para garantir a confidencialidade, integridade e disponibilidade dos dados de backup. | |
| Gerenciamento de Acesso de Dados | Forneça evidências de que uma lista de usuários com acesso a dados e/ou chaves de criptografia é mantida. Incluindo a justificativa comercial para cada pessoa e a confirmação de que essa lista de usuários foi formalmente aprovada com base nos privilégios de acesso necessários para sua função de trabalho e os usuários são configurados com os privilégios descritos na aprovação. |
| Forneça evidências de que uma lista de todos os terceiros com os quais os dados são compartilhados é mantida e os contratos de compartilhamento de dados estão em vigor com todos os terceiros consumindo dados. | |
| Privacidade | Sua organização tem um sistema PIM (Gerenciamento de Informações de Privacidade) estabelecido, implementado e mantido que mantém o compromisso de liderança por meio de uma política ou outra forma de documentação/sistema informatizado para como seus esforços de gerenciamento de informações de privacidade são mantidos para confidencialidade e integridade do sistema. Determina funções, responsabilidades e autoridades de cada pessoa que mantém o sistema, incluindo processadores e controladores de PII. |
| Forneça evidências de processos para verificar se a minimização de PII está ocorrendo, a desmarcar e a exclusão do PII está sendo feita no final do período de processamento, os controles estão em vigor para a transmissão de PII, incluindo qualquer confidencialidade, o registro de transferência de PII de um país/região para outro existe com consentimento expresso para fazê-lo. | |
| RGPD | Forneça evidências de que os indivíduos de dados são capazes de gerar SARs, que o ISV é capaz de identificar todos os locais dos dados dos titulares de dados ao responder a uma solicitação de SARs, que há um período de retenção para backups que permite que clientes que solicitam remoção de dados por meio de SAR sejam removidos à medida que backups de rolagem durante um período são removidos (ciclo de vida das exclusões de backup/reescritas mais antigas). |
| Forneça o aviso de privacidade que deve conter todos os elementos necessários da seguinte maneira: detalhes oranizacionais (nome, endereço e outras informações identificáveis pessoais), o tipo de dados pessoais que estão sendo processados, por quanto tempo os dados pessoais serão mantidos, a legalidade do processamento de dados pessoais, os direitos dos titulares de dados; incluindo: direitos do titular de dados, direito de ser informado, direito de acesso pelo titular dos dados, direito à eliminação, direito à restrição de processamento, direito à portabilidade de dados, direito ao objeto, direitos em relação à tomada de decisão automatizada, incluindo criação de perfil. | |
| HIPAA | Forneça evidências de que: existe uma política para o tratamento HIPAA e HIPAA em sua organização para funcionários, empreiteiros, fornecedores etc. Verifique se nossa organização garante confidencialidade, integridade e disponibilidade de ePH. |
| Verifique se você: forneça proteção contra usos ou divulgações razoavelmente antecipados dessas informações que não são permitidas pela regra de privacidade, certifique-se de conformidade com a regra de segurança por sua força de trabalho. Forneça um plano de backup de dados e recuperação de desastres em 164.308 (a)(7)(ii)(A) e 164.308 (a)(7)(ii)(B). |
Revisão de estruturas de conformidade externa opcionais
Embora não seja necessário, se você estiver atualmente em conformidade com ISO 27001, PCI DSS, FedRAMP ou SOC2, você poderá optar por usar essas certificações para atender a alguns dos controles de Certificação do Microsoft 365. Analistas tentarão alinhar estruturas de segurança externas existentes à estrutura 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 segurança da Certificação 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 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 nesta estrutura de Certificação do Microsoft 365. |
| FedRAMP | O FedRAMP (Federal Risk and Authorization Management Program) é um programa do governo federal dos EUA criado em 2011. Ele fornece uma abordagem padronizada para avaliação de segurança, autorização e monitoramento contínuo para produtos e serviços de nuvem. |
Requisitos para usar estruturas de conformidade externas
✓ O ambiente no escopo 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.