Descrição geral da arquitetura de Certificação do Microsoft 365
Este artigo fornece informações detalhadas, incluindo a lista de controlos de segurança de Certificação do Microsoft 365, e suporte para ISVs e programadores submetidos à Certificação do Microsoft 365.
A Certificação do Microsoft 365 é uma auditoria independente de segurança e privacidade de aplicações, suplementos e ambiente de back-end de suporte (coletivamente referido como aplicações) integrado na plataforma do Microsoft 365. As aplicações que passam serão designadas Microsoft 365 Certificadas em todo o ecossistema do Microsoft 365 e podem ser encontradas facilmente nos marketplaces do Microsoft 365 através de filtros de pesquisa e imagem corporativa focados na conformidade. Os ISVs terão a oportunidade de partilhar os respetivos atributos de conformidade de aplicações em páginas dedicadas neste conjunto de documentação.
A Certificação do Microsoft 365 está disponível para os seguintes tipos de aplicações:
- Suplementos do Microsoft 365 (Word, Excel, Outlook, PowerPoint, OneNote, Project)
- Aplicativos do Teams
- Soluções do SharePoint
- Aplicações Web (SaaS)
Importante
A Certificação do Microsoft 365 é uma revisão rigorosa da segurança e conformidade de uma aplicação relativamente à arquitetura de Certificação do Microsoft 365 e requer um tempo substancial e um compromisso de recursos para concluir. Reveja as arquiteturas de controlo de conformidade para ver se a sua aplicação é elegível antes de iniciar a certificação. Para quaisquer perguntas, envie um e-mail para appcert@microsoft.com.
Termos
Ao participar no programa de Certificação do Microsoft 365, está a concordar com estes termos suplementares e a cumprir qualquer documentação associada 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"). O Utilizador representa e garante-nos que tem autoridade para aceitar estes termos suplementares de Certificação do Microsoft 365 em nome de si, de uma empresa e/ou de outra entidade, conforme aplicável. Podemos alterar, alterar ou cessar estes termos suplementares em qualquer altura. A sua participação contínua no programa de Certificação do Microsoft 365 após qualquer alteração ou emenda significa que concorda com os novos termos suplementares. Se não concordar com os novos termos suplementares ou se terminarmos estes termos suplementares, tem de deixar de participar no programa de Certificação do Microsoft 365.
Pré-requisitos
Antes de ser possível atribuir a Certificação do Microsoft 365, uma aplicação tem de concluir o seguinte:
Verificação do publicador Quando uma aplicação tem um publicador verificado, a organização que publica a aplicação é verificada como autenticada pela Microsoft. Verificar uma aplicação inclui a utilização de uma conta CPP (Microsoft Cloud Partner Program) que foi verificada e associar o PartnerID verificado a um registo de aplicação. Obter a verificação do publicador
O Atestado do Publisher é um processo self-service em que os ISVs respondem a um conjunto de perguntas sobre as práticas de segurança e processamento de dados da aplicação. As aplicações podem ser atestadas pelo publicador no Centro de Parceiros da Microsoft e receber filtros de mau estado e dedicados no Marketplace do Microsoft AppSource após a conclusão.
Rever os critérios de controlo Não é necessário cumprir todos os controlos para que seja concedida uma certificação. No entanto, os limiares (que não serão divulgados) estão implementados para cada um dos três domínios de segurança abordados neste documento de descrição geral e têm de ser transmitidos. Alguns controlos serão classificados como uma "falha difícil", o que significa que a falta destes controlos de segurança resultará numa avaliação falhada.
Importante
Período de tempo de submissão: Em média, o processo de avaliação deve demorar 30 dias, desde que os ISVs possam marcar submissão status com frequência e responder a comentários e pedidos de provas suplementares de forma oportuna. Após iniciar o processo de certificação, é permitido um máximo de 60 dias para concluir a avaliação. Se todas as submissões não tiverem sido concluídas dentro do período de 60 dias, a submissão será emitida uma falha e o processo terá de ser iniciado novamente. Estes resultados não serão tornados públicos.
Âmbito de certificação
O ambiente no âmbito suporta a entrega do código de aplicação/suplemento e suporta quaisquer sistemas de back-end com os quais a aplicação/suplemento possa estar a comunicar. Quaisquer ambientes adicionais ligados ao ambiente no âmbito também serão incluídos no âmbito, a menos que esteja implementada uma segmentação adequada E os ambientes ligados a não possam afetar a segurança do ambiente no âmbito.
Quaisquer ambientes de recuperação após desastre separados também terão de ser incluídos no ambiente no âmbito, uma vez que estes ambientes seriam necessários para satisfazer o serviço caso algo acontecesse ao ambiente primário. Os ambientes de cópia de segurança remotos também terão de ser incluídos, uma vez que estes ambientes podem armazenar dados da Microsoft e, por conseguinte, terão de estar implementados controlos de segurança adequados.
O termo componentes do sistema no âmbito referencia todos os dispositivos e sistemas que são utilizados no ambiente de âmbito definido. Os componentes no âmbito incluem, mas não estão limitados a:
- Aplicações Web
- Servidores (físicos ou virtuais que podem ser no local ou na cloud)
- Controlos de Segurança de Rede (NSCs), como firewalls
- Opções
- Balanceadores de carga
- Infraestrutura virtual
- Portais de gestão Web do fornecedor de cloud
- Recursos da cloud (Máquinas Virtuais, Serviço de Aplicativo, Contas de Armazenamento, Instâncias do EC2, etc.)
Importante
Os componentes do sistema destinados ao público são suscetíveis a ataques de atores de ameaças externas e, portanto, estão em risco muito maior. Normalmente, estes sistemas seriam segmentados de outros componentes internos do sistema através de um controlo de segurança de rede (NSC) que cria uma zona desmilitarizada (DMZ). A intenção é que a rede de perímetro seja menos fidedigna do que a rede interna e que a segurança adicional ajude a proteger ainda mais os sistemas internos e os dados caso os sistemas destinados ao público fiquem comprometidos. Idealmente, seria utilizada uma rede de perímetro. No entanto, tal não é viável ou mesmo necessário em alguns cenários de implementação.
Infraestrutura como Um Serviço (IaaS), Plataforma como Serviço (PaaS) e Software como um Serviço (SaaS)
Quando IaaS e/ou PaaS são utilizados para suportar o ambiente no âmbito em análise, o fornecedor de plataforma cloud será responsável por alguns dos controlos de segurança avaliados ao longo do processo de certificação. Os analistas terão de ser fornecidos com uma verificação externa independente das melhores práticas de segurança pelo fornecedor da plataforma cloud através de relatórios de conformidade externos, como relatórios PCI DSS, Atestado de Conformidade (AOC), ISO 27001 ou SOC 2 Tipo II.
O Apêndice C fornece detalhes sobre os controlos de segurança que provavelmente serão aplicáveis com base nos seguintes tipos de implementação e com base no facto de a aplicação ter ou não os dados do Microsoft 365:
- ISV Alojado
- IaaS Alojado
- PaaS/Alojado Sem Servidor
- Alojado Híbrido
- Alojado Partilhado
Quando a IaaS ou a PaaS são implementadas, têm de ser fornecidas provas que validem o alinhamento do ambiente com estes tipos de implementação.
Amostragem
Os pedidos de provas de suporte da avaliação de certificação devem basear-se numa amostra dos componentes do sistema no âmbito em consideração de diferentes sistemas operativos, função primária do dispositivo, diferentes tipos de dispositivo (ou seja, Servidores, NSCs, Routers, etc.) e localização. Será selecionado um exemplo adequado no início do processo de certificação. A tabela seguinte deve ser utilizada como um guia onde 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 ponto a ponto
Para iniciar a Certificação do Microsoft 365:
Navegue para o Centro de Parceiros e conclua o Atestado do Publisher. Se a submissão tiver mais de três meses, submissa novamente para revisão e validação.
No centro de parceiros, selecione "Iniciar Certificação" para iniciar a submissão do documento inicial. Isto ajudará os analistas de certificação a determinar o que está no âmbito da avaliação com base na arquitetura da aplicação e na forma como processa os dados da Microsoft.
Dica
Siga o guia de procedimentos para obter instruções passo a passo para obter a sua aplicação Microsoft 365 Certificado.
O processo de certificação é realizado ao longo de duas fases, conforme descrito abaixo:
A Submissão inicial de Documentos ajuda o analista a compreender a aplicação, os fluxos de dados, a definir o ambiente no âmbito, a identificar que controlos de segurança são aplicáveis e a determinar os componentes do sistema a partir dos quais as provas terão de ser recolhidas. O ISV tem de fornecer informações pedidas para ajudar o analista de certificação a concluir esta fase do processo, que corresponde a aproximadamente 5% do processo global.
A Análise Completa de Provas é o processo pelo qual o ISV submete artefactos de provas que demonstram como o ambiente no âmbito está a cumprir os controlos de segurança. Haverá múltiplas interações entre o ISV e o analista durante esta fase de auditoria, que é o resto do processo.
Avaliação
Assim que a submissão inicial do documento tiver sido aceite, o conjunto de controlos de segurança será automaticamente apresentado no portal. Os ISVs devem fornecer provas para cada controlo que demonstre que o controlo está em vigor e têm 60 dias para apresentar todas as provas. Um analista irá rever as provas e aprovar o controlo ou pedir provas novas ou adicionais.
Certificação
Depois de uma submissão ter sido validada por um analista, os ISVs são notificados da decisão de certificação. As aplicações atribuídas a uma certificação receberão um distintivo na respetiva aplicação no AppSource e páginas dedicadas de documentos da Microsoft com relatórios detalhados dos respetivos atributos de segurança e conformidade.
Rever e recertificar
As aplicações certificadas do Microsoft 365 são necessárias para serem recertificadas anualmente. Isto exigirá a revalidação dos controlos no âmbito relativamente ao ambiente no âmbito atual. Este 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 recertificaçã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 expiração, a certificação de aplicações status será revogada. Todas as marcas de certificação, ícones e badging serão removidos da sua aplicação e os ISVs serão proibidos de anunciar a sua aplicação como Microsoft 365 Certified.
Se uma aplicação sofrer alterações significativas fora do período de tempo de submissão de recertificação, é pedido que notifique o Programa de Conformidade de Aplicações da Microsoft para quaisquer atualizações.
Submissão inicial do documento
A submissão inicial tem de incluir as seguintes informações:
| Descrição Geral da Documentação | Detalhes da Documentação |
|---|---|
| Descrição da aplicação/suplemento | Uma descrição da finalidade e funcionalidade da aplicação/suplemento. Isto deve fornecer ao analista de certificação uma boa compreensão de como a aplicação/suplemento funciona e qual é a utilização pretendida |
| Relatório de testes de penetração | Um relatório de testes de penetração foi concluído nos últimos 12 meses. Este relatório tem de incluir o ambiente que suporta a implementação da aplicação/adicionar juntamente com qualquer ambiente adicional que suporte o funcionamento da aplicação/suplemento. Nota: se o ISV não realizar atualmente testes de penetração anuais, a Microsoft cobrirá os custos dos testes de caneta através do processo de certificação. |
| Diagramas de arquitetura | Um diagrama de arquitetura lógica que representa uma descrição geral de alto nível da infraestrutura de suporte da aplicação. Isto tem de incluir todos os ambientes de alojamento e a infraestrutura de suporte que suporta a aplicação. Este diagrama TEM de ilustrar todos os diferentes componentes do sistema de suporte no ambiente para ajudar os analistas de certificação a compreender os sistemas no âmbito e a ajudar a determinar a amostragem. Indique também que tipo de ambiente de alojamento é utilizado; ISV Alojado, IaaS, PaaS ou Híbrido. Nota: Quando o SaaS for utilizado, indique os vários serviços SaaS que são utilizados para fornecer serviços de suporte no ambiente. |
| Espaço público | Detalhar todos os ENDEREÇOS IP públicos e URLs utilizados pela infraestrutura de suporte. Isto deve incluir o intervalo de IP encaminhável completo alocado ao ambiente, a menos que tenha sido implementada uma segmentação adequada para dividir o intervalo em utilização (será necessária uma prova adequada da segmentação) |
| Diagramas de fluxo de dados | Diagramas de fluxo que detalham o seguinte: |
| ✓ Os dados do Microsoft 365 fluem de e para a Aplicação/Suplemento (incluindo EUII e OII.) | |
| ✓ Fluxos de dados do Microsoft 365 na infraestrutura de suporte (quando aplicável). | |
| ✓ Diagramas que realçam onde e que dados são armazenados, como os dados são transmitidos a terceiros externos (incluindo detalhes de que terceiros) e como os dados são protegidos em trânsito através de redes abertas/públicas e inativos. | |
| Detalhes do ponto final da API | Uma lista completa de todos os Pontos Finais da API utilizados pela sua aplicação. Para ajudar a compreender o âmbito do ambiente, forneça localizações do ponto final da API no seu ambiente. |
| Permissões da API da Microsoft | Forneça documentação que detalha todas as APIs da Microsoft que são utilizadas juntamente com as permissões que estão a ser pedidas para a aplicação/suplemento funcionar, juntamente com uma justificação para as permissões pedidas |
| Tipos de armazenamento de dados | Armazenamento de dados e processamento de documentos que descrevem: |
| ✓ Até que ponto estão a ser recebidos e armazenados os Dados EUII e OII do Microsoft 365 | |
| ✓ O período de retenção de dados. | |
| ✓ Por que motivo os Dados do Microsoft 365 estão a ser capturados. | |
| ✓ Onde os Dados do Microsoft 365 são armazenados (também deve ser incluído nos diagramas de fluxo de dados fornecidos acima). | |
| Confirmação de conformidade | Documentação de suporte para estruturas de segurança externas incluídas na submissão do Atestado do Publisher ou a considerar ao rever os controlos de segurança de Certificação do Microsoft 365. Atualmente, são suportados os quatro seguintes: |
| ✓ Atestado PCI DSS de Conformidade (AOC). | |
| ✓ Relatórios SOC 2 Tipo I/Tipo II. | |
| ✓ Declaração de Aplicabilidade (SoA) e Certificação do ISMS / IEC - 1S0/IEC 27001. | |
| ✓ FedRAMP FedRAMP Authorization Package (Pacote de Autorização FedRAMP) e FedRAMP Readiness Assessment Report (Relatório de Avaliação de Preparação da FedRAMP). | |
| Dependências Web | Documentação que lista todas as dependências utilizadas pela aplicação com versões em execução atuais. |
| Inventário de software | Um inventário de software atualizado que inclui todo o software utilizado no ambiente no âmbito, juntamente com as versões. |
| Inventário de hardware | Um inventário de hardware atualizado utilizado pela infraestrutura de suporte. Isto será utilizado para ajudar na amostragem ao realizar a fase de avaliação. Se o seu ambiente incluir PaaS, forneça detalhes sobre os serviços cloud/recursos consumidos. |
Atividades de recolha e avaliação de provas
Os analistas de certificação terão de rever as provas em todos os componentes do sistema no conjunto de exemplo definido. Os tipos de provas necessários para suportar o processo de avaliação incluem qualquer um ou todos os seguintes:
Recolha de provas
- Documentação inicial realçada no guia de submissão da documentação inicial
- Documentos de política
- Processar documentos
- Definições de configuração do sistema
- Alterar bilhetes
- Alterar registos de controlo
- Relatórios do sistema
- Atas da reunião
- Contratos/contratos
Serão utilizados vários métodos para recolher as provas necessárias para concluir o processo de avaliação. Esta recolha de provas pode ter a forma de:
- Documentos
- Capturas de tela
- Entrevistas
- Partilha de ecrã
As técnicas de recolha de provas utilizadas serão determinadas durante o processo de avaliação. Para obter exemplos específicos do tipo de provas necessárias na sua submissão, veja o Guia de Provas de Exemplo.
Atividades de avaliação
Os analistas de certificação irão rever as provas fornecidas para determinar se todos os controlos da Certificação do Microsoft 365 foram cumpridos.
Para reduzir a quantidade de tempo necessário para concluir a avaliação, qualquer documentação detalhada na Submissão da Documentação Inicial deve ser fornecida com antecedência.
Os analistas de certificação irão primeiro rever os elementos de prova fornecidos a partir da submissão da documentação inicial e as informações do Atestado do Publicador para identificar as linhas adequadas de consulta, o tamanho da amostragem e a necessidade de obter mais provas, conforme detalhado acima. Os analistas de certificação irão analisar todas as informações recolhidas para tirar conclusões sobre como e se está a cumprir os controlos nesta Especificação de Certificação do Microsoft 365.
Critérios de certificação de aplicações
A aplicação e a infraestrutura de suporte e a documentação de suporte serão avaliadas nos três domínios de segurança seguintes:
- Segurança da aplicação
- Segurança operacional/implementação segura
- Segurança e privacidade do processamento de dados
Cada um destes domínios de segurança inclui controlos 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 do Microsoft 365 é inclusiva para programadores de todos os tamanhos, cada um dos domínios de segurança é avaliado através de um sistema de classificação para determinar uma classificação geral de cada um dos domínios. As classificações para cada um dos controlos de Certificação do Microsoft 365 são alocadas entre 1 (baixa) e 3 (alta) com base no risco percebido de que esse controlo não está a ser implementado. Cada um dos domínios de segurança terá uma marca de percentagem mínima para ser considerado um passe. Alguns elementos desta especificação incluem alguns critérios de falha automática:
- As permissões da API não seguem o princípio do menor privilégio (PoLP).
- Não existem relatórios de testes de penetração quando são necessários.
- Não existem defesas antimalware.
- A autenticação Multi-Factor não está a ser utilizada para proteger o acesso administrativo.
- Sem processos de aplicação de patches.
- Nenhum aviso de privacidade do RGPD adequado.
Segurança da aplicação
O domínio de segurança da aplicação concentra-se em três áreas:
- Validação de Permissão do GraphAPI
- Verificações de Conectividade Externa
- Testes de Penetração
Validação de permissões do GraphAPI
A validação da permissão GraphAPI é realizada para validar que a aplicação/suplemento não pede permissões excessivamente permissivas. Isto é realizado ao verificar manualmente que permissões são pedidas. Os analistas de certificação irão fazer referência cruzada a estas verificações relativamente à submissão do Atestado do Publisher e avaliar o nível de acesso que está a ser pedido para garantir que as práticas de "privilégio mínimo" estão a ser cumpridas. Quando os analistas de certificação acreditam que estas práticas de "privilégio mínimo" não estão a ser cumpridas, os analistas de certificação terão uma discussão aberta com o ISV para validar a justificação comercial para as permissões que estão a ser pedidas. Todas as discrepâncias relativas à submissão do Atestado do Publisher encontradas durante esta revisão terão de ser corrigidas.
Verificações de conectividade externa
Como parte da avaliação, será efetuada uma descrição simplificada da funcionalidade das aplicações para identificar quaisquer ligações que estejam a ser efetuadas fora do Microsoft 365. Quaisquer ligações que não sejam identificadas como sendo da Microsoft ou ligações diretas ao seu serviço serão sinalizadas e abordadas durante a avaliação.
Testes de penetração
Uma revisão adequada dos riscos associados à aplicação/suplemento e ao ambiente de suporte é essencial para fornecer aos clientes garantias sobre a segurança da aplicação/suplemento. Os testes de segurança de aplicações sob a forma de testes de penetração têm de ser realizados se a sua aplicação tiver alguma conectividade a qualquer serviço não publicado pela Microsoft. Se uma vez implementada a sua aplicação funcionar de forma autónoma, acedendo apenas ao serviço Microsoft, como o GraphAPI, os testes de penetração não são necessários. Os testes de penetração continuam a ser necessários se o ambiente no âmbito estiver alojado no Azure.
Âmbito dos testes de penetração
Para testes de penetração de infraestrutura interna e externa, todas as atividades de teste de penetração TÊM de ser realizadas no ambiente de produção em direto que suporta a implementação da aplicação/suplemento (por exemplo, onde o código da aplicação/suplemento está alojado, que normalmente será o recurso no ficheiro de manifesto), juntamente com quaisquer ambientes adicionais que suportem o funcionamento da aplicação/suplemento (por exemplo, se a aplicação/suplemento falar com outras aplicações Web fora do Microsoft 365). Ao definir o âmbito dos testes de penetração, é necessário ter cuidado para garantir que todos os sistemas ou ambientes "ligados" que possam ter impacto na segurança do ambiente no âmbito também estão incluídos em TODAS as atividades de testes de penetração.
Recomenda-se que os testes de penetração de aplicações Web sejam realizados no ambiente de produção em direto. No entanto, seria aceitável efetuar testes apenas à aplicação Web através de um ambiente de teste/UAT, desde que seja confirmado no relatório de testes de penetração que a mesma base de código estava a funcionar no ambiente de teste/UAT no momento do teste.
Quando as técnicas são utilizadas para segmentar os ambientes no âmbito de outros ambientes, as atividades de teste de penetração TÊM de validar a eficácia das técnicas de segmentação. Isto tem de ser detalhado no relatório de testes de penetração.
Observação
Os testes de penetração internos têm de ser realizados, a menos que o ambiente de alojamento seja classificado apenas como PaaS.
Requisitos de testes de penetração
Os relatórios de testes de penetração serão revistos para garantir que não existem vulnerabilidades que cumpram os seguintes critérios de falha automática descritos nos controlos abaixo.
| Tipo de Critérios | Controlos de teste de penetração |
|---|---|
| Critérios gerais | A aplicação Web (autenticada e não autenticada) e os testes de penetração internos (se aplicável) e de infraestrutura externa têm de ser realizados anualmente (a cada 12 meses) e realizados por uma empresa independente de renome. |
| A remediação de vulnerabilidades críticas e de alto risco identificadas tem de ser concluída no prazo de um mês após a conclusão do teste de penetração ou mais cedo, dependendo do processo de aplicação de patches documentado do ISV. | |
| Requisitos de espaço externos completos (endereços IP, URLs, pontos finais da API, etc.) TEM de ser incluído no âmbito dos testes de penetração e deve estar claramente documentado no relatório de testes de penetração. | |
| A menos que o ambiente se alinhe com a PaaS, as redes internas completas TÊM de ser incluídas no âmbito dos testes de penetração e devem estar claramente documentadas no relatório de testes de penetração. | |
| Os testes de penetração de aplicações Web TÊM de incluir todas as classes de vulnerabilidade; por exemplo, o OWASP Top 10 ou SANS Top 25 CWE mais recente. A recomendação é que isto esteja detalhado no relatório de testes de penetração, caso contrário, será difícil de demonstrar. | |
| As vulnerabilidades ou vulnerabilidades críticas e de alto risco consideradas como uma falha automática têm de ser retestadas pela empresa de testes de penetração e claramente realçadas como fixas no relatório de testes de penetração. | |
| Critérios de falha automática: | Presença de um sistema operativo não suportado ou biblioteca JavaScript não suportada. |
| Presença de contas administrativas predefinidas, enumeráveis ou adivinhos. | |
| Presença de riscos de injeção de SQL. | |
| Presença de scripts entre sites. | |
| Presença de vulnerabilidades do percurso do diretório (caminho do ficheiro). | |
| Presença de vulnerabilidades HTTP, por exemplo, Divisão de respostas de cabeçalho, Contrabando de pedidos e ataques de Dessincronização. | |
| Presença de divulgação do código fonte (incluindo LFI). | |
| Qualquer classificação crítica ou alta, conforme definido pelas diretrizes de gestão de patches cvSS. | |
| Qualquer vulnerabilidade técnica significativa que possa ser facilmente explorada para comprometer uma grande quantidade de EUII ou UOI. |
Importante
Os relatórios têm de ser capazes de fornecer garantias suficientes de que tudo o que está detalhado na secção de requisitos de testes de penetração acima pode ser demonstrado.
Requisitos e regras de testes de penetração complementares
- Para ISVs que atualmente não se dedicam a testes de penetração, os testes de penetração podem ser realizados gratuitamente para a Certificação do Microsoft 365. A Microsoft irá dispor e cobrir os custos de um teste de penetração até 12 dias de testes manuais. Os custos dos testes de penetração são calculados com base no número de dias necessários para testar o ambiente no âmbito. Quaisquer despesas que excedam os 12 dias de teste serão da responsabilidade do ISV.
- Os ISVs serão obrigados a apresentar provas e a receber aprovação para 50% dos controlos no âmbito antes da realização do teste de penetração. Para começar, preencha a submissão inicial do documento e opte por ter testes de penetração incluídos como parte da sua avaliação. Será contactado para definir o âmbito e agendar o teste de penetração quando tiver concluído 50% dos controlos.
- O relatório emitido assim que o teste de caneta estiver concluído será fornecido ao ISV assim que tiver concluído a certificação. Este relatório, juntamente com a Certificação do Microsoft 365, pode ser utilizado para mostrar aos potenciais clientes que o seu ambiente está seguro.
- Os ISVs também serão responsáveis por demonstrar que as vulnerabilidades identificadas no teste de penetração foram remediadas antes da atribuição de uma certificação, mas não precisam de produzir um relatório limpo.
Uma vez organizado um teste de penetração, o ISV é responsável pelas taxas associadas ao reagendamento e cancelamentos da seguinte forma:
| Reagendar a escala temporal das taxas | Proporção a pagar |
|---|---|
| Reagendar pedido recebido mais de 30 dias antes da data de início agendada. | 0% a Pagar |
| Reagendar pedido recebido 8 a 30 dias antes da data de início agendada. | 25% a Pagar |
| Reagendar o pedido recebido dentro de 2 a 7 dias antes da data de início agendada com uma data de remarcação da empresa. | 50% a Pagar |
| Reagendar pedido recebido menos de 2 dias antes da data de início. | A pagar a 100% |
| Escala temporal da taxa de cancelamento | Proporção a pagar |
|---|---|
| O pedido de cancelamento recebeu mais de 30 dias antes da data de início agendada. | 25% a Pagar |
| O pedido de cancelamento recebeu 8 a 30 dias antes da data de início agendada. | 50% a Pagar |
| Pedido de cancelamento recebido no prazo de 7 dias antes da data de início agendada. | 90% a Pagar |
Segurança operacional
Este domínio mede o alinhamento dos processos de implementação e infraestrutura de suporte de uma aplicação com as melhores práticas de segurança.
Controles
| Família de controlo | Controls |
|---|---|
| Formação de sensibilização | Forneça provas de que a organização fornece formação de sensibilização de segurança estabelecida aos utilizadores do sistema de informações (incluindo gestores, executivos superiores e contratantes) como parte da formação inicial para novos utilizadores ou quando necessário por alterações do sistema de informações. |
| Forneça provas de uma frequência definida pela organização de formação de sensibilização. | |
| Forneça provas de documentação e monitorização de atividades de deteção de segurança do sistema de informações individuais, mantendo registos de formação individuais numa frequência definida pela organização. | |
| Proteção contra software maligno - antivírus | Forneça provas de que a solução antimalware está ativada e ativada em todos os componentes do sistema de exemplo e configurada para cumprir os seguintes critérios: |
| Se o antivírus estiver ativado, essa análise no acesso é ativada e as assinaturas estão atualizadas no prazo de um dia e bloqueia automaticamente software maligno ou alertas e quarentenas quando é detetado software maligno. | |
| OU, se EDR/NGAV (Deteção e Resposta de Pontos Finais/Antivírus de Próxima Geração), a análise periódica está a ser efetuada, os registos de auditoria são gerados e são mantidos atualizados continuamente e têm capacidades de auto-aprendizagem. | |
| Se EDR/NGAV bloquear software maligno conhecido e identificar e bloquear novas variantes de software maligno com base em comportamentos de macro, bem como ter capacidades de lista segura completas. | |
| Proteção contra software maligno - controlos de aplicações | Forneça provas de que existe e está atualizada uma lista aprovada de software/aplicações com justificação comercial. |
| Que cada aplicação é submetida a um processo de aprovação e aprovação antes da implementação | |
| Essa tecnologia de controlo de aplicações está ativa, ativada e configurada em todos os componentes do sistema de exemplo, conforme documentado. | |
| Gestão de patches – classificação de aplicação de patches e riscos | Forneça documentação de política que regule a forma como as novas vulnerabilidades de segurança são identificadas e atribuídas uma classificação de risco. |
| Forneça provas de como as novas vulnerabilidades de segurança são identificadas. | |
| Forneça provas que demonstrem que todas as vulnerabilidades recebem uma classificação de risco depois de identificadas. | |
| Forneça provas de que todos os componentes de sistema de exemplo estão a ser patchedin em linha com os timeframes de aplicação de patches definidos pelas organizações e os sistemas operativos não suportados e os componentes de software não estão a ser utilizados. Quando aplicável, deve incluir a base de código se for utilizada tecnologia sem servidor ou PaaS, ou a infraestrutura e a base de código, se for utilizada a IaaS. | |
| Diretrizes de período de aplicação de patches: Crítica – no prazo de 14 dias, Alta – No prazo de 30 dias, Médio – no prazo de 60 dias. | |
| Análise de vulnerabilidades | Indique a infraestrutura trimestral e os relatórios de análise de vulnerabilidades de aplicações Web. A análise tem de ser realizada relativamente a toda a quantidade de espaço público (endereços IP e URLs) e aos intervalos de IP internos. |
| Forneça provas de que as remediações de vulnerabilidades identificadas durante a análise de vulnerabilidades são corrigidas de acordo com o período de aplicação de patches documentado. | |
| Controlos de Segurança de Rede (NSC) | Forneça provas de que os Controlos de Segurança de Rede (NSC) estão instalados no limite do ambiente no âmbito e instalados entre a rede de perímetro e as redes internas. |
| E se a IaaS híbrida, no local, também fornecer provas de que todo o acesso público termina na rede de perímetro. | |
| Confirme que todos os Controlos de Segurança de Rede (NSC) estão configurados para remover o tráfego não explicitamente definido na base de regras e que as revisões de regras de Controlos de Segurança de Rede (NSC) são realizadas pelo menos a cada 6 meses. | |
| Alterar controlo | Forneça provas de que quaisquer alterações introduzidas nos ambientes de produção são implementadas através de pedidos de alteração documentados que contêm o impacto da alteração, detalhes dos procedimentos de back-out, testes a serem realizados, revisão e aprovação por pessoal autorizado. |
| Forneça provas de que existem ambientes separados para que: ambientes de desenvolvimento e teste/teste imponham a separação de deveres do ambiente de produção, a separação de deveres seja imposta através de controlos de acesso, os dados de produção confidenciais não estejam a ser utilizados nos ambientes de desenvolvimento ou teste/teste. | |
| Desenvolvimento/implementação de software seguro | Forneça políticas e procedimentos que suportem o desenvolvimento de software seguro e incluam normas do setor e/ou melhores práticas para codificação segura. Tais como Open Web Application Security Project (OWASP) Top 10 ou SysAdmin, Audit, Network and Security (SANS) Top 25 Common Weakness Enumeration (CWE). |
| Forneça provas de que os repositórios de código estão protegidos de modo a que: todas as alterações de código sejam submetidas a um processo de revisão e aprovação por um segundo revisor antes de serem intercaladas com main ramo, se existirem controlos de acesso adequados, todo o acesso é imposto através da autenticação multifator (MFA) | |
| Forneça provas de que todas as versões efetuadas nos ambientes de produção são revistas e aprovadas antes da respetiva implementação. | |
| Account management | Forneça provas de que as credenciais predefinidas estão desativadas, removidas ou alteradas nos componentes do sistema de exemplo. |
| Forneça provas de que está em curso um processo para proteger (proteger) contas de serviço e que este processo foi seguido. | |
| Forneça provas de que: as contas de utilizador exclusivas são emitidas para todos os utilizadores, os princípios de menor privilégio de utilizador estão a ser seguidos no ambiente, uma política de palavra-passe/frase de acesso forte ou outras mitigações adequadas estão em vigor, um processo está em vigor e é seguido, pelo menos, a cada três meses para desativar ou eliminar contas não utilizadas no prazo de três meses. | |
| Confirme que a MFA está configurada para todas as ligações de acesso remoto e todas as interfaces administrativas não consola, incluindo o acesso a quaisquer repositórios de código e interfaces de gestão da cloud. | |
| Registo de eventos de segurança, revisão e alertas | Forneça provas de que um mínimo de 30 dias de dados de registo de eventos de segurança estão imediatamente disponíveis, com 90 dias de registos de eventos de segurança retidos. |
| Forneça provas de que os registos estão a ser revistos periodicamente e quaisquer potenciais eventos/anomalias de segurança identificados durante o processo de revisão são investigados e resolvidos | |
| Forneça provas de que as regras de alerta estão configuradas para que os alertas sejam acionados para investigação para os seguintes eventos de segurança, quando aplicável: criação/modificações de contas com privilégios, atividades ou operações de alto risco, eventos de software maligno, adulteração do registo de eventos, eventos IDPS /WAF. (se configurado) | |
| Gestão de riscos de informações | Forneça provas de que um processo/política de gestão de riscos de segurança de informações formal ratificado está documentado e estabelecido. |
| Forneça provas de que uma avaliação formal dos riscos de segurança de informação a nível da empresa é realizada, pelo menos, anualmente. | |
| OU para Análise de Risco Direcionada: uma análise de risco direcionada é documentada e executada no mínimo a cada 12 meses para cada instância em que não existe um controlo tradicional ou uma melhor prática da indústria, em que uma limitação de design/tecnologia cria um risco de introdução de uma vulnerabilidade no ambiente ou coloca utilizadores e dados em risco, por suspeita ou confirmação de compromisso. | |
| Confirme que a avaliação do risco de segurança de informações inclui componentes do sistema ou recursos afetados, ameaças e vulnerabilidades ou equivalentes, matrizes de impacto e probabilidade ou equivalentes, a criação de um plano de tratamento de risco/registo de risco. | |
| Forneça provas de que tem em vigor um processo de gestão de riscos que avalia e gere riscos associados a fornecedores e parceiros empresariais e pode identificar e avaliar alterações e riscos que podem afetar o seu sistema de controlos internos. | |
| Resposta a incidentes de segurança | Indique o plano/procedimento de resposta a incidentes de segurança ratificado (IRP). |
| Forneça provas que descrevam a forma como a sua organização responde a incidentes, mostrando como é mantida e que inclui detalhes da equipa de resposta a incidentes, incluindo informações de contacto, um plano de comunicação interna durante o incidente e comunicação externa a partes relevantes, como intervenientes principais, marcas de pagamento e adquirentes, entidades reguladoras (por exemplo, 72 horas para o RGPD), autoridades de supervisão, diretores, clientes, bem como passos para atividades como classificação de incidentes, contenção, mitigação, recuperação e regresso às operações comerciais normais, consoante o tipo de incidente | |
| Forneça provas de que todos os membros da equipa de resposta a incidentes receberam formação anual que lhes permite responder a incidentes. | |
| Forneça provas de que a estratégia de resposta a incidentes e a documentação de suporte são revistas e atualizadas com base em ambas as lições aprendidas a partir de um exercício de topo de tabela, lições aprendidas ao responder a um incidente, alterações organizacionais. | |
| Plano de continuidade de negócio e plano de recuperação após desastre | Forneça provas de que a documentação existe e é mantida, que descreve o plano de Continuidade do Negócio. |
| Forneça provas de que o plano de continuidade de negócio detalha o pessoal relevante e as respetivas funções e responsabilidades, incluindo: funções empresariais com requisitos e objetivos de contingência associados, procedimentos de cópia de segurança de sistemas e dados, configuração e agendamento/retenção, prioridade de recuperação e metas de período de tempo, um plano de contingência que detalha ações, passos e procedimentos a seguir para devolver sistemas de informação críticos, funções empresariais e serviços a funcionar em caso de um plano de contingência interrupção inesperada e não agendada, um processo estabelecido que abrange o eventual restauro completo do sistema e o regresso ao estado original. | |
| Forneça provas de que a documentação existe, é mantida e descreve o plano de recuperação após desastre e inclui no mínimo: pessoal e respetivas funções, responsabilidades e processo de escalamento, inventário dos sistemas de informações utilizados para suportar funções e serviços empresariais críticos, procedimentos e configuração de cópias de segurança de sistemas e dados, um plano de recuperação que detalha as ações e procedimentos a seguir para restaurar sistemas e dados de informação críticos para o funcionamento. | |
| Forneça provas de que o plano de continuidade do negócio e o plano de recuperação após desastre estão a ser revistos pelo menos a cada 12 meses para garantir que se mantém válido e eficaz em situações adversas. | |
| Forneça provas de que o plano de continuidade do negócio é atualizado com base na revisão anual do plano, todo o pessoal relevante que recebe formação sobre as suas funções e responsabilidades atribuídas nos planos de contingência, os planos estão a ser testados através da continuidade do negócio ou exercícios de recuperação após desastre, os resultados dos testes são documentados, incluindo lições aprendidas com o exercício ou alterações organizacionais. |
Segurança e Privacidade do Processamento de Dados
Os dados em trânsito entre o utilizador da aplicação, os serviços intermediários e os sistemas do ISV terão de ser protegidos pela encriptação através de uma ligação TLS que suporte um mínimo de TLS v1.1. (Recomenda-se o TLS v1.2+ ). ConsulteApêndice A.
Quando a sua aplicação obtém e armazena os dados do Microsoft 365, terá de implementar um esquema de encriptação de armazenamento de dados que siga a especificação, conforme definido no Apêndice B.
Controles
| Família de Controlo | Controls |
|---|---|
| Dados em Trânsito | Forneça provas de que valida que a Configuração do TLS é TLS1.2 ou superior nos requisitos de configuração do perfil TLS e que é mantido e mantido um inventário de chaves e certificados fidedignos. |
| As provas mostram que a compressão TLS está desativada para todos os serviços destinados ao público que processam pedidos Web para impedir a fuga de informações da Taxa de Compressão Made Easy (CRIME) e o TLS HSTS está ativado e configurado para 180 dias em todos os sites. | |
| Dados inativos | Forneça provas de que os dados inativos estão encriptados de acordo com os requisitos do perfil de encriptação, utilizando algoritmos de encriptação como a Standard de Encriptação Avançada (AES), RSA e Twofish com tamanhos de chave de encriptação de 256 bits ou superiores. |
| Retenção de Dados, cópia de segurança e eliminação | Indique a prova de que um período de retenção de dados aprovado é formalmente estabelecido e documentado. |
| Forneça provas de que os dados são retidos apenas para o período de retenção definido, conforme discutido no controlo anterior. | |
| Forneça provas de que os processos estão em vigor para eliminar dados de forma segura após o respetivo período de retenção. | |
| Forneça provas de que um sistema de cópia de segurança automatizado está implementado e configurado para efetuar cópias de segurança em horas agendadas. | |
| Forneça provas de que as informações de cópia de segurança são testadas em conformidade com o procedimento de agendamento de cópias de segurança e restauradas periodicamente para confirmar a fiabilidade e integridade dos dados. | |
| Forneça provas de que os controlos de acesso e os mecanismos de proteção adequados (ou seja, cópias de segurança imutáveis) são implementados para garantir que as cópias de segurança/instantâneos do sistema estão protegidos contra o acesso não autorizado e para garantir a confidencialidade, integridade e disponibilidade dos dados de cópia de segurança. | |
| Gestão de Acesso a Dados | Forneça provas de que é mantida uma lista de utilizadores com acesso a dados e/ou chaves de encriptação. Incluindo a justificação comercial para cada pessoa e a confirmação de que esta lista de utilizadores foi formalmente aprovada com base nos privilégios de acesso necessários para a respetiva função de trabalho e os utilizadores são configurados com os privilégios descritos na aprovação. |
| Forneça provas de que é mantida uma lista de todos os terceiros com os quais os dados são partilhados e os contratos de partilha de dados estão em vigor com todos os terceiros que consomem dados. | |
| Privacidade | A sua organização tem um sistema de Gestão de Informações de Privacidade (PIM) estabelecido, implementado e mantido que mantém o compromisso de liderança através de uma política ou outra forma de documentação/sistema informatizado para a forma como os seus esforços de gestão 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 PII. |
| Forneça provas de processos para verificar se a minimização do PII está a decorrer, a eliminação e a eliminação do PII estão a ser efetuadas no final do período de processamento, existem controlos para a transmissão pii, incluindo qualquer confidencialidade, o registo de transferência do PII de um país/região para outro existe com o consentimento expresso para o fazer. | |
| RGPD | Forneça provas de que os titulares dos dados são capazes de gerar SARs, que o ISV é capaz de identificar todas as localizações dos dados dos titulares dos dados ao responder a um pedido de SARs, que existe um período de retenção para cópias de segurança que permite que os clientes que pedem a remoção de dados através de SAR sejam removidos à medida que as cópias de segurança sem interrupção durante um período são removidas (ciclo de vida das eliminações/reescritas mais antigas). |
| Indique o aviso de privacidade que deve conter todos os elementos necessários da seguinte forma: detalhes orancionais (nome, endereço e outras informações pessoais identificáveis), o tipo de dados pessoais que estão a ser processados, durante quanto tempo os dados pessoais serão mantidos, a legalidade do processamento de dados pessoais, os direitos dos titulares dos dados; incluindo: direitos do titular dos dados, direito a ser informado, direito de acesso pelo titular dos dados, direito à eliminação, direito à restrição do processamento, direito à portabilidade dos dados, direito à oposição, direitos em relação à tomada de decisões automatizada, incluindo criação de perfis. | |
| HIPAA | Forneça provas de que existe uma política para o tratamento hipAA e HIPAA na sua organização para funcionários, empreiteiros, fornecedores, etc. Verifique se a nossa organização garante confidencialidade, integridade e disponibilidade do ePH. |
| Verifique se: forneça proteção contra utilizações razoavelmente previstas ou divulgações de tais informações que não são permitidas pela regra de privacidade, garanta a conformidade com a regra de segurança pela respetiva força de trabalho. Forneça uma cópia de segurança de dados e um plano de recuperação após desastre em 164.308 (a)(7)(ii)(A) e 164.308 (a)(7)(ii)(B). |
Revisão opcional das arquiteturas de conformidade externa
Embora não seja necessário, se estiver atualmente em conformidade com o ISO 27001, PCI DSS, FedRAMP ou SOC2, pode optar por utilizar estas certificações para satisfazer alguns dos controlos de Certificação do Microsoft 365. Os analistas tentarão alinhar as arquiteturas de segurança externa existentes com a arquitetura de Certificação do Microsoft 365. No entanto, se a documentação de suporte não conseguir garantir que os controlos de Certificação do Microsoft 365 foram avaliados como parte da auditoria/avaliação das arquiteturas de segurança externas, terá de fornecer provas adicionais de que esses controlos estão em vigor.
A documentação tem de demonstrar adequadamente que o ambiente no âmbito da Certificação do Microsoft 365 foi incluído no âmbito destas estruturas de segurança externas. A validação destas estruturas de segurança será cumprida ao aceitar provas de certificações válidas realizadas por empresas externas de renome. Estas empresas de renome devem ser membros de organismos internacionais de acreditação para programas de conformidade relevantes. Veja Normas de Certificação e Conformidade ISO para ISO 27001 e Avaliadores de Segurança Qualificados (QSA) para PCI DSS.
A tabela seguinte destaca as arquiteturas externas e a documentação exigida pelos analistas de certificação como parte deste processo de validação:
| Standard | Requisitos |
|---|---|
| ISO 27001 | Será necessária uma versão pública da Declaração de Aplicabilidade (SOA) e uma cópia do certificado ISO 27001 emitido. A SOA resume a sua posição sobre cada um dos 114 controlos de segurança de informações e será utilizada para identificar se existe alguma exclusão de controlos que não sejam satisfatoriamente detalhados no certificado ISO 27001. Se isto não puder ser determinado ao rever a versão destinada ao público da SOA, o analista poderá precisar de acesso ao SOA completo se a ISO 27001 for utilizada para validar alguns dos controlos de segurança de Certificação do Microsoft 365. Além de validar o âmbito das atividades de avaliação iso 27001, os analistas também confirmarão a validade da empresa de auditoria, conforme descrito acima. |
| PCI DSS | Tem de ser fornecido um documento válido do Atestado de Conformidade (AOC) de Nível 1 que identifique claramente a aplicação no âmbito e os componentes do sistema. Uma AOC de autoavaliação não será aceite como prova do cumprimento das melhores práticas de segurança. O AOC será utilizado para determinar quais dos controlos 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) tem de estar atualizado (emitido nos últimos 15 meses e o período de tempo declarado iniciado nos últimos 27 meses) para ser utilizado como prova de conformidade com qualquer um dos controlos de avaliação nesta estrutura de Certificação do Microsoft 365. |
| FedRAMP | O Federal Risk and Authorization Management Program (FedRAMP) é um programa do governo federal dos EUA criado em 2011. Fornece uma abordagem padronizada para avaliação de segurança, autorização e monitorização contínua para produtos e serviços cloud. |
| Framework | Considerações adicionais |
|---|---|
| ISO 27001 | Apêndice C: Recolha de Provas – Deltas para ISO 27001. |
| PCI DSS | Apêndice D: Recolha de Provas – Deltas para PCI DSS. |
| SOC 2 | Apêndice E: Recolha de Provas – Deltas para SOC 2. |
Observação
Embora as normas/estruturas de segurança externas mencionadas acima possam ser submetidas como prova para cumprir alguns dos controlos de Certificação do Microsoft 365, a aprovação da Certificação do Microsoft 365 não significa que uma aplicação transmitirá com êxito uma auditoria relativamente a essas normas/arquiteturas. A Especificação de Certificação do Microsoft 365 é apenas um pequeno subconjunto dessas normas/arquiteturas de segurança que permite à Microsoft obter um nível de garantia em referência à sua postura de segurança.
Requisitos para utilizar arquiteturas de conformidade externas
✓ O ambiente no âmbito E todos os processos empresariais de suporte têm de ser incluídos no âmbito de quaisquer estruturas de conformidade de segurança externa suportadas e devem ser claramente indicados na documentação fornecida.
✓ Os quadros de conformidade de segurança externos suportados têm de estar atualizados, ou seja, nos últimos 12 meses (ou no prazo de 15 meses, se a reavaliação estiver a ser realizada e os elementos de prova puderem ser fornecidos).
✓ As estruturas de conformidade de segurança externa suportadas têm de ser executadas por uma empresa acreditada independente.