Descrição geral da arquitetura de Certificação do Microsoft 365
Este artigo fornece informações detalhadas sobre a Certificação do Microsoft 365, incluindo uma lista dos controlos de segurança necessários e orientações para ISVs e programadores.
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 atributos de conformidade da respetiva aplicação 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)
- Extensões do CoPilot
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. Antes de começar, reveja as arquiteturas de controlo de conformidade para verificar se a sua aplicação é elegível. Se tiver dúvidas, 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 programadores de aplicações (ISVs) completam um conjunto de perguntas sobre as suas práticas de segurança, como o processamento de dados confidenciais. Depois de concluída, a aplicação receberá uma badging e uma listagem especiais no marketplace do Microsoft AppSource.
Rever os critérios de controlo Nem sempre é um requisito estar em conformidade com 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. Não cumprir os Controlos críticos identificados como "falha grave" resultará na falha da avaliação.
Período de tempo de submissão
Existem duas fases no processo de submissão para obter a certificação:
Fase 1: Submissão Inicial do Documento (período de tempo de 14 dias)
Nesta fase, o ISV tem de submeter documentação que forneça uma descrição geral do ambiente de suporte da aplicação. Isto inclui, mas não se limita a:
- Diagrama de arquitetura/Fluxo de dados
- Listas de componentes do sistema
- Inventários de ativos de software
Um analista irá rever esta documentação para definir o âmbito da avaliação. O ISV tem 14 dias para concluir e carregar a documentação necessária. O não cumprimento deste prazo pode atrasar o processo ou resultar numa submissão falhada.
Fase 2: Revisão Completa de Provas (período de tempo de 60 dias)
Assim que o âmbito tiver sido definido, o ISV avançará para a fase de recolha de provas. Nesta fase:
- O ISV tem de carregar provas relativamente a todos os controlos aplicáveis definidos a partir do âmbito.
- Estas provas serão analisadas, revisões (se necessário) e um processo final de GQ.
- Se necessário, os testes de penetração também podem ser realizados durante este período de tempo.
O ISV tem 60 dias para concluir esta fase, a partir da primeira submissão de provas, que inclui:
- Carregar Provas para todos os controlos
- Análise e feedback dos analistas
- Quaisquer revisões necessárias às provas submetidas
- Conclusão do processo de GQ
Falha ao Cumprir o Prazo
Se o ISV não conseguir concluir o processo dentro do período de 60 dias, a avaliação falhará. No entanto, a critério do analista, pode ser concedida uma extensão de até 60 dias adicionais em circunstâncias válidas, tais como:
- Feriados sazonais
- Atrasos nos testes de penetração
- Alterações internas
- Tempo necessário para implementar as alterações necessárias para cumprir os requisitos de controlo
Não é possível conceder mais extensões, uma vez esgotados ambos os intervalos de tempo de 60 dias.
Âmbito de certificação
O ambiente no âmbito abrange todos os sistemas e infraestruturas necessários para entregar a aplicação ou o código do suplemento, juntamente com quaisquer sistemas de back-end de suporte com os quais a aplicação/suplemento possa comunicar. Quaisquer ambientes adicionais ligados ao ambiente no âmbito também devem ser incluídos no âmbito, a menos que seja implementada uma segmentação adequada e os ambientes ligados não possam comprometer a segurança do ambiente no âmbito.
Nota: todos os ambientes de recuperação após desastre separados também têm de ser incluídos no ambiente no âmbito, uma vez que estes ambientes podem ser essenciais para manter a continuidade do serviço em caso de falhas de ambiente primário.
Além disso, os ambientes de cópia de segurança remota também têm de ser incorporados no âmbito, uma vez que podem armazenar dados confidenciais da Microsoft. Por conseguinte, têm de ser implementados controlos de segurança adequados para estes ambientes.
O termo componentes do sistema no âmbito inclui todos os dispositivos e sistemas utilizados ativamente no ambiente definido no âmbito. Estes componentes incluem, mas não estão limitados a:
- Aplicativos web
- Servidores (físicos ou virtuais, localizados no local ou na cloud)
- Opções
- Balanceadores de Carga
- Infraestrutura Virtual
- Portais de gestão Web do fornecedor de cloud
- Recursos na cloud (Máquinas Virtuais, Serviços de aplicações, Contas de armazenamento, Bases de Dados, etc.)
Importante
Os componentes do sistema destinados ao público são particularmente vulneráveis a ataques por parte de agentes de ameaças externas e, portanto, com maior risco. Normalmente, estes sistemas devem ser isolados dos componentes internos do sistema através da implementação de controlos de segurança de rede (NSCs), como uma zona desmilitarizada (DMZ). O objetivo de uma rede de perímetro é agir como uma zona de memória intermédia, limitando a confiança alargada a sistemas externos e melhorando a segurança para salvaguardar os sistemas e dados internos. Embora uma rede de perímetro ainda possa ser ideal em alguns casos, as arquiteturas de cloud modernas dependem frequentemente de medidas de segurança alternativas adaptadas a cenários de implementação específicos.
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.
Para obter detalhes sobre quais os controlos de segurança que são provavelmente aplicáveis ao tipo de implementação e se o ambiente processa ou transfere dados do Microsoft 365, consulte Apêndice C. Os Tipos de implementação incluem:
- ISV Alojado: Aplicação alojada por Fornecedores Independentes de Software
- IaaS Alojado: infraestrutura fornecida por plataformas de cloud de terceiros.
- PaaS/Sem Servidor Alojado: aplicações com uma média de arquitetura baseada na plataforma ou sem servidor.
- Anfitrião Híbrido: uma combinação de componentes alojados no local e na cloud.
- Alojados partilhados: ambientes de cloud partilhados utilizados por vários inquilinos.
Nos casos em que IaaS ou PaaS está em utilização, as provas têm de validar que a implementação está alinhada com os controlos de segurança esperados para a arquitetura relevante.
Amostragem
Para garantir uma avaliação completa, a amostragem dos componentes do sistema no âmbito tem de considerar fatores como sistemas operativos, função do dispositivo principal, tipo de dispositivo (por exemplo, servidores, routers, controlos de segurança de rede) e localização geográfica. Os exemplos são selecionados no início do processo de certificação com base nestas considerações. A tabela abaixo orienta o tamanho da amostragem com base na população de componentes no âmbito:
| Tamanho da População | Amostra |
|---|---|
| <=5 | 1 |
| >5 & <10= | 2 |
| >10 & <=30 | 3 |
| >30 | 4 |
Isto garante uma avaliação representativa da conformidade do ambiente em diversas configurações e modelos de implementação.
Observação
Se forem identificadas discrepâncias entre dispositivos durante a avaliação, o tamanho da amostra poderá ser ajustado para garantir uma apresentação adequada do ambiente.
Descrição geral do processo de certificação
Para iniciar o processo de Certificação do Microsoft 365:
Atestado do Publisher Aceda ao Centro de Parceiros e preencha o formulário Atestado do Publisher. Nota: se a submissão tiver mais de três meses, tem de voltar a submetê-la para revisão e validação.
Inicie a Certificação Uma vez no Centro de Parceiros, selecione a opção "Iniciar Certificação" para iniciar a submissão do documento inicial. Este passo ajuda os analistas de certificação a identificar o âmbito da avaliação com base na arquitetura da sua aplicação e na forma como gere os dados da Microsoft.
A certificação é realizada em duas fases main:
Submissão de Documento Inicial Nesta fase, irá fornecer detalhes fundamentais para ajudar os analistas a compreender a estrutura, o fluxo de dados e o ambiente no âmbito da aplicação. Os analistas determinarão os controlos de segurança aplicáveis e descreverão os componentes do sistema que requerem provas. Tem de fornecer documentação precisa para facilitar esta revisão, que representa aproximadamente 5% do processo geral.
Análise de Provas Completa Nesta fase, submete provas detalhadas que demonstram a conformidade com os controlos de segurança para o ambiente no âmbito. Os analistas trabalharão em estreita colaboração consigo durante esta fase para rever, esclarecer e verificar as suas submissões. Esta fase requer o resto do processo.
Avaliação
Assim que a Submissão Inicial do Documento for aprovada, será apresentada uma lista dos controlos de segurança necessários no portal. Tem 60 dias para fornecer provas para cada controlo, confirmando que está em vigor e operacional. Os analistas irão rever as suas provas e aprová-la ou pedir detalhes ou revisões adicionais.
Certificação
Depois de a submissão ter sido revista e validada por um analista, receberá uma notificação sobre a decisão de certificação. As aplicações que cumpram com êxito os critérios de certificação receberão um distintivo, que será apresentado na listagem do AppSource e nas páginas de Microsoft Docs associadas. Estas páginas também fornecerão relatórios detalhados sobre os atributos de segurança e conformidade da aplicação.
Rever e recertificar
As aplicações certificadas do Microsoft 365 têm de ser submetidas a uma recertificação anual para garantir a conformidade contínua com as normas da Microsoft. O processo de recertificação envolve reavaliar os controlos no âmbito para confirmar que estão alinhados com o ambiente atual. Pode iniciar o processo de recertificação até 90 dias antes de a certificação expirar para evitar quaisquer interrupções. As certificações permanecerão válidas durante este período.
Se a recertificação não for concluída antes da data de expiração, a certificação será revogada. Como resultado:
O distintivo de certificação e a imagem corporativa da aplicação serão removidos.
Os ISVs deixarão de ser autorizados a comercializar a aplicação como Microsoft 365 Certified.
Se existirem alterações significativas na aplicação fora do período de recertificação agendado, os ISVs têm de informar o Programa de Conformidade de Aplicações da Microsoft para garantir que a aplicação permanece em conformidade.
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 submetidas para verificar se todos os controlos necessários para a Certificação do Microsoft 365 são cumpridos. Para agilizar o processo, certifique-se de que toda a documentação especificada na Submissão da Documentação Inicial está concluída e fornecida com antecedência.
Durante a revisão, os analistas irão avaliar as provas da submissão inicial e do atestado do Publisher. Determinarão o âmbito da investigação, o lado da amostragem e se são necessárias provas adicionais. Os analistas utilizarão todas as informações recolhidas para avaliar a conformidade com a especificação de Certificação do Microsoft 365 e decidir se a sua aplicação cumpre os controlos definidos.
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. Determinados fatores resultam em falhas automáticas, incluindo
Utilização de permissões de API que não cumprem o princípio do menor privilégio (PoLP)
Falta de relatórios de testes de penetração quando necessário.
Ausência de defesas antimalware.
Falha ao implementar a autenticação multifator (MFA) para acesso administrativo.
Processos de aplicação de patches em falta ou insuficientes.
Aviso de privacidade da falta de conformidade do RGPD .
Segurança da aplicação
O domínio de segurança da aplicação avalia as seguintes áreas:
- Validação de Permissão do GraphAPI
- Testes de Penetração
Validação de permissões do GraphAPI
Isto garante que a aplicação ou o suplemento não pede permissões excessivas ou excessivamente permissivas. Os analistas de certificação analisam manualmente as permissões pedidas pela aplicação e cruzam marcar-las relativamente à submissão do Atestado do Publisher.
O objetivo é confirmar que as permissões pedidas cumprem o princípio do menor privilégio. Se os analistas descobrirem que a aplicação está a pedir permissões que excedem o necessário, irão contactar o ISV para validar a justificação comercial para estas permissões. Todas as discrepâncias identificadas entre as permissões pedidas e a submissão do atestado do Publisher têm de ser resolvidas durante esta revisão.
Testes de penetração
Os testes de penetração são fundamentais para identificar e mitigar riscos associados à aplicação ou suplemento e ao respetivo ambiente de suporte. Isto garante que a aplicação fornece garantias de segurança adequadas aos clientes.
Os testes de penetração são obrigatórios para qualquer aplicação que se ligue a serviços externos não alojados ou geridos pela Microsoft. Se a aplicação for implementada como uma solução autónoma que utiliza apenas serviços Microsoft, como o GraphAPI, os testes de penetração poderão não ser necessários. No entanto, as aplicações alojadas no Azure têm de ser submetidas a testes de penetração para garantir a segurança do ambiente no âmbito.
Âmbito dos testes de penetração
Testes de infraestrutura: para a infraestrutura interna e externa, os testes de penetração têm de ser realizados no ambiente de produção em direto que suporta a aplicação ou o suplemento. Isso inclui:
O ambiente onde o código da aplicação ou do suplemento está alojado (normalmente referenciado no ficheiro de manifesto)
Quaisquer ambientes adicionais que interajam ou suportam o funcionamento da aplicação/suplemento (por exemplo, se a aplicação/suplemento comunicar ith outras aplicações Web fora do Microsoft 365).
Ao definir o âmbito para testes de penetração, é fundamental incluir todos os sistemas ou ambientes ligados que possam afetar a segurança do ambiente no âmbito.
Recomendações
Testes de Penetração de Aplicações Web: recomenda-se que os testes de penetração de aplicações Web são realizados diretamente no ambiente de produção em direto. No entanto, os testes de aplicações Web podem ser realizados num ambiente de teste/UAT (Testes de Aceitação do Utilizador), desde que o relatório de testes de penetração confirme que a mesma base de código está a ser utilizada na produção no momento do teste.
Validação da Segmentação: se forem utilizadas técnicas de segmentação para isolar ambientes no âmbito de outros, o relatório de testes de penetração tem de validar a eficácia destas técnicas de segmentação. Isto garante que não são introduzidas vulnerabilidades através do processo de segmentação.
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 não realizam atualmente testes de penetração, a Microsoft oferece um serviço de teste de penetração gratuito como parte do processo de Certificação do Microsoft 365. Este serviço abrange até 12 dias de testes manuais, com custos adicionais para todos os dias necessários para além deste ser da responsabilidade do ISV.
Principais requisitos
Requisitos de Pré-Teste: o ISV tem de submeter provas e receber aprovação para 50% dos controlos no âmbito antes de agendar o teste de penetração.
Relatório de Teste: este relatório, juntamente com a Certificação do Microsoft 365, pode ser utilizado para demonstrar aos clientes que o seu ambiente está seguro.
Remediação de vulnerabilidades: os ISVs são responsáveis por resolver quaisquer vulnerabilidades identificadas durante os testes antes de a certificação poder ser concedida. No entanto, não é necessário um relatório de limpo, apenas provas de confirmação de que as vulnerabilidades foram adequadamente resolvidas.
Considerações adicionais
Uma vez organizado um teste de penetração, o ISV é responsável por cobrir quaisquer taxas associadas a reagendamentos ou cancelamentos.
| 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 pedido recebido dentro de 2 a 7 dias antes da data de início agendada com uma data de reserva firme. | 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 corrigidos em conformidade 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 em vigor, por exemplo "crítico – no prazo de 14 dias, elevado – 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 a remediação de vulnerabilidades identificadas durante a análise de vulnerabilidades é corrigida 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
Para garantir a segurança dos dados, todos os dados em trânsito entre o utilizador da aplicação, os serviços intermediários e os sistemas ISV têm de ser encriptados através da ligação TLS (Transport Layer Security). No mínimo, é necessário o TLS 1.2, com o TLS 1.3 ou superior vivamente recomendado. Para obter mais detalhes, veja Apêndice A.
Para aplicações que obtêm ou armazenam dados do Microsoft 365, é obrigatório implementar um esquema de encriptação de armazenamento de dados. Isto tem de estar alinhado com as especificações descritas 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 organizacionais (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 da arquitetura de conformidade externa
Se a sua organização já estiver em conformidade com estruturas de segurança externas, como ISO 27001, PCI DSS, FedRAMP ou SOC 2 Tipo 2, pode optar por tirar partido destas certificações para satisfazer alguns dos controlos de Certificação do Microsoft 365. Os analistas terão como objetivo alinhar as suas arquiteturas de segurança externa existentes com os requisitos de Certificação do Microsoft 365.
No entanto, se a sua documentação de suporte não demonstrar que os controlos de Certificação do Microsoft 365 foram explicitamente avaliados como parte da auditoria ou avaliação da arquitetura externa, tem de fornecer provas adicionais para verificar se estes controlos estão em vigor.
Requisitos de Documentação
A documentação tem de demonstrar claramente que o ambiente no âmbito da Certificação do Microsoft 365 está incluído no âmbito das eternas estruturas de segurança. A validação destes quadros será cumprida ao aceitar provas de certificações válidas emitidas por auditores de terceiros respeitáveis e credenciados.
Estes auditores de terceiros devem ser membros de organismos internacionais de acreditação, tais como:
Normas de Certificação e Conformidade para ISO 27001
Avaliadores de Segurança de Qualidade (QSA) para PCI DSS
Para obter detalhes adicionais, veja as diretrizes e normas específicas para as arquiteturas externas relevantes para a sua certificação.
A tabela abaixo descreve as arquiteturas e documentação necessárias aceites pelos analistas de certificação como parte do 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 ou estruturas de segurança externas possam ser submetidas como prova de suporte para cumprir determinados controlos de Certificação do Microsoft 365, obter a Certificação do Microsoft 365 requer uma avaliação separada. Alcançar a Certificação do Microsoft 365 não implica que a aplicação tenha aprovado totalmente as auditorias para estas arquiteturas externas. A Especificação de Certificação do Microsoft 365 concentra-se num subconjunto específico de controlos derivados destas arquiteturas para fornecer à Microsoft um nível mais elevado de garantia relativamente à postura de segurança da sua aplicação.
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.