Apêndice e glossário da documentação de Conformidade de Aplicativos Microsoft 365

Apêndice A

Requisitos de configuração do Perfil TLS

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

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

A compactação TLS DEVE ser desabilitada.

Apêndice B

Requisitos de configuração de perfil de criptografia

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

Criptografia simétrica

Encryption

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

• Apenas o modo CBC é permitido. Cada operação de criptografia deve usar um vetor de inicialização (IV) novo e gerado aleatoriamente.

• O uso de codificações de fluxo, como RC4, NÃO É permitido.

Funções de hash

• Todo novo código deve usar SHA-256, SHA-384 ou SHA-512 (coletivamente chamados de SHA-2). A saída pode ser truncada para não menos que 128 bits

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

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

Autenticação de mensagem

• Todo o novo código DEVE usar HMAC com uma das funções de hash aprovadas. A saída do HMAC pode ser truncada para não menos que 128 bits.

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

• A chave HMAC DEVE ter pelo menos 128 bits. Chaves de 256 bits são recomendadas.

Algoritmos assimétricos

Encryption

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

Assinaturas

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

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

Troca de chaves

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

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

Apêndice C

Coleta de evidências – Delta para a ISO 27001

Quando você já tiver atingido ISO27001 conformidade, os seguintes deltas (lacunas) não totalmente cobertos pela ISO 27001 precisarão, no mínimo, ser revisados como parte desta Certificação Microsoft 365.

Observação

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

Proteção contra malware - antivírus

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

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

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

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

Gerenciamento de patches – Aplicação de patch

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

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

Verificação de vulnerabilidade

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

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

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

• Corrija todos os problemas de risco crítico e alto de acordo com a classificação de risco para verificação interna.

• Corrija todos os problemas de risco crítico, alto e médio de acordo com a classificação de risco para verificação externa.

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

Controle de Alterações

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

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

• Impacto documentado.

• Detalhes de quais testes de funcionalidade devem ser realizados.

• Detalhes de todos os procedimentos de retirada.

• Demonstrar que o teste de funcionalidade é realizado depois que as alterações são concluídas.

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

Gerenciamento de Conta

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

• Demonstre como os *s são implementados para atenuar ataques de repetição (por exemplo, MFA, Kerberos).

• Demonstre como as contas que não são usadas há 3 meses são desativadas ou excluídas.

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

• Tamanho mínimo da senha de 8 caracteres.

• Limite de bloqueio de conta de no máximo 10 tentativas.

• Histórico de senhas de, no mínimo, cinco senhas.

• Imposição do uso de senhas fortes.

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

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

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

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

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

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

• As assinaturas do IDPS DEVEM ser mantidas atualizadas, no último dia.

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

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

• O IDPS DEVE ser configurado para alertas.

Log de Eventos

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

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

• Demonstrar como um mínimo de 30 dias de dados de registro em log estão imediatamente disponíveis, com 90 dias sendo retidos.

Revisando (registrando dados)

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

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

Alertas

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

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

• Demonstre como a equipe está disponível 24 horas por dia, 7 dias por semana, para responder a alertas de segurança.

Gerenciamento de Risco

Como as auditorias da ISO 27001 não avaliam especificamente alguns elementos dos processos de avaliação de riscos, isso exigirá que você:

• Demonstrar que um processo formal de gerenciamento de riscos é estabelecido.

Resposta a Incidentes

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

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

• Procedimentos de resposta específicos para modelos de ameaças esperadas.

• Recursos de tratamento de incidentes alinhados à Estrutura de Segurança Cibernética do NIST (Identificar, Proteger, Detectar, Responder, Recuperar).

• O IRP abrange os sistemas no escopo.

• Treinamento anual para a equipe de resposta a incidentes.

Apêndice D

Coleta de Evidências - Deltas para PCI DSS

Quando você já tiver atingido a conformidade com o PCI DSS, os seguintes deltas (lacunas) não totalmente cobertos pelo PCI DSS precisarão, no mínimo, ser revisados como parte desta Certificação Microsoft 365.

Observação

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

Proteção contra Malware \u2012 Controle de Aplicativo

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

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

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

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

• Demonstre que, em todos os componentes do sistema amostrados, o controle de aplicativos é configurado conforme documentado.

Gerenciamento de patches - Classificação de risco

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

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

Verificação de vulnerabilidade

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

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

Controle de Alterações

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

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

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

• Demonstrar que o teste de funcionalidade é realizado depois que as alterações são concluídas.

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

Desenvolvimento/Implantação Segura de Software

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

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

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

Gerenciamento de Conta

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

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

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

• Tamanho mínimo da senha de 8 caracteres.

• Limite de bloqueio de conta de no máximo 10 tentativas.

• Histórico de senhas de, no mínimo, cinco senhas.

• Imposição do uso de senhas fortes.

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

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

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

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

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

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

Gerenciamento de Risco

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

• Demonstre que a avaliação de risco inclui matrizes de impacto e verossimilhança.

Resposta a Incidentes

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

• Demonstrar que os recursos de tratamento de incidentes se alinham à Estrutura de Segurança Cibernética do NIST (Identificar, Proteger, Detectar, Responder, Recuperar).

Apêndice E

Coleta de Evidências \u2012 Deltas para SOC 2

Quando você já tiver atingido a conformidade com o SOC 2, os seguintes deltas (lacunas) não totalmente cobertos pelo SOC 2 precisarão ser revisados como parte desta Certificação Microsoft 365.

Observação

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

Proteção contra Malware \u2012 Controle de Aplicativo

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

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

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

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

• Demonstre que, em todos os componentes do sistema amostrados, o controle de aplicativos é configurado conforme documentado.

Gerenciamento de patches – Aplicação de patch

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

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

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

Controle de Alterações

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

• Demonstrar como os ambientes de desenvolvimento/teste são separados do ambiente de produção, impondo a separação de tarefas.

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

• Demonstrar que o teste de funcionalidade é realizado depois que as alterações são concluídas.

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

Desenvolvimento/Implantação Segura de Software

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

• Você DEVE ter um processo de desenvolvimento de software estabelecido e documentado cobrindo todo o ciclo de vida de desenvolvimento de software.

• Os desenvolvedores DEVEM passar por treinamento de codificação de software seguro pelo menos uma vez por ano.

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

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

Gerenciamento de Conta

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

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

• Demonstre como as contas que não são usadas há 3 meses são desativadas ou excluídas.

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

• Tamanho mínimo da senha de 8 caracteres.

• Limite de bloqueio de conta de no máximo 10 tentativas.

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

• Imposição do uso de senhas fortes

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

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

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

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

• As assinaturas do IDPS DEVEM ser mantidas atualizadas, no último dia

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

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

Log de Eventos

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

• Demonstre como, em todos os componentes do sistema dentro do conjunto de amostras, o seguinte sistema está configurado para registrar os seguintes eventos

• Acesso do usuário aos componentes do sistema e ao(s) aplicativo(s).

• Todas as ações realizadas por um usuário com altos privilégios.

• Tentativas de acesso lógico inválidas.

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

• Usuário.

• Tipo de evento.

• Data e hora.

• Indicador de sucesso/falha.

• Etiqueta para identificar o sistema afetado.

• Demonstre que todos os componentes do sistema no conjunto de exemplo estão configurados para utilizar a sincronização de horário e que são os mesmos que os servidores de horário primário/secundário.

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

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

• Demonstre como a solução de registro em log centralizado é protegida contra violação não autorizada de dados de registro em log.

• Demonstrar como um mínimo de 30 dias de dados de registro em log estão imediatamente disponíveis, com 90 dias ou mais sendo retidos.

Gerenciamento de Risco

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

• Demonstrar que uma avaliação formal de risco é realizada pelo menos uma vez por ano.

Resposta a Incidentes.

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

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

• Procedimentos de resposta específicos para modelos de ameaças esperadas.

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

Apêndice F

Tipos de implantação de hospedagem

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

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

Glossário

AIA

*O Acesso à Informação da Autoridade é um descritor de local de serviço usado para encontrar o certificado da autoridade certificadora emissora.

CRL

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

Pontuação CVSS

*O Sistema de Pontuação de Vulnerabilidade Comum é um padrão publicado que mede a vulnerabilidade e calcula uma pontuação numérica com base em sua gravidade.

Diretrizes de gerenciamento de patches CVSS

• Crítico (9.0 - 10.0)
• Alta (7,0 - 8,9)
• Médio (4,0 - 6,9)
• Baixa (0,0 - 3,9)

DMZ

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

FedRAMP

O Programa Federal de Gerenciamento de Riscos e Autorizações (FedRAMP) é um programa do governo federal dos EUA estabelecido em 2011. Ele fornece uma abordagem padronizada para avaliação de segurança, autorização e monitoramento contínuo para produtos e serviços em nuvem.

EUII

Informações de identificação do usuário final.

RGPD

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

HSTS

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

IEC

*Comissão Eletrotécnica Internacional.

SGSI

*Sistema de Gestão de Segurança da Informação.

ISV

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

ISO 27001

Uma estrutura de especificação do sistema de gerenciamento de segurança da informação para todos os controles técnicos nos processos de políticas e procedimentos de gerenciamento de riscos de uma organização.

LFI

A inclusão de arquivos locais permite que um invasor inclua arquivos em um servidor por meio do navegador da Web.

NIST

O NIST (Instituto Nacional de Padrões ), uma agência não reguladora do Departamento de Comércio dos EUA, fornece orientação para organizações do setor privado nos EUA avaliarem e aprovarem sua capacidade de prevenir, detectar e responder a ataques cibernéticos.

Alterações não significativas

• Pequenas correções de bugs.
• Pequenas melhorias de desempenho.
• Sistemas operacionais/bibliotecas/patches de aplicativos de cliente e servidor.

OCSP

O protocolo de status de certificado online é usado para marcar o status de revogação de certificados digitais X.509.

OII

Informações de identificação organizacional.

OWASP

Open Web Application Security Project.

PCI DSS

Payment Card Industry Data Security Standard, uma organização que mantém padrões para a segurança dos dados do titular do cartão em todo o mundo.

Teste de penetração

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

SAML

A Security Assertion Markup Language é um padrão aberto para a troca de dados de autenticação e autorização entre o usuário, o provedor de identidade e o provedor de serviços.

Dados confidenciais

• Dados de controle de acesso.
• Conteúdo do cliente.
• Informações de identidade do usuário final.
• Dados de suporte.
• Dados pessoais públicos.
• Informações pseudônimas do usuário final.

Alterações significativas

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

SOC 2

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

SSL

Secure Sockets Layer.

TLS

Transport Layer Security.