Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
As perguntas frequentes sobre a segurança do Power Platform se dividem em duas categorias:
Como o Power Platform foi projetado para ajudar a mitigar os 10 principais riscos do Open Web Application Security Project® (OWASP)
Perguntas que nossos clientes fazem
Para facilitar a localização das informações mais recentes, novas perguntas são adicionadas ao final deste artigo.
Os 10 principais riscos da OWASP: mitigações no Power Platform
A OWASP (Open Web Application Security Project®) é uma fundação sem fins lucrativos que trabalha para melhorar a segurança do software. Por meio de projetos de software de código aberto liderados pela comunidade, centenas de capítulos em todo o mundo, dezenas de milhares de membros e conferências educacionais e de treinamento líderes, a OWASP Foundation é a fonte para desenvolvedores e tecnólogos protegerem a Web.
Os 10 principais riscos da OWASP é um documento de conscientização padrão para desenvolvedores e outros interessados na segurança de aplicativos Web. Ele representa um amplo consenso sobre os riscos de segurança mais críticos para aplicativos Web. Nesta seção, discutiremos como o Power Platform ajuda a mitigar esses riscos.
A01:2021 Controle de acesso interrompido
- O modelo de segurança do Power Platform é baseado em LPA (Least Privileged Access). O LPA permite que os clientes criem aplicativos com controle de acesso mais granular.
- O Power Platform usa a Plataforma de Identidade da Microsoft do Microsoft Entra ID (Microsoft Entra ID) para autorização de todas as chamadas de API com protocolo OAuth 2.0 padrão do setor.
- O Dataverse, que fornece os dados subjacentes para o Power Platform, tem um modelo de segurança avançado que inclui segurança no nível do ambiente, baseada em função e no nível do registro e do campo.
A02:2021 Falhas criptográficas
Dados em trânsito:
- O Power Platform usa TLS para criptografar todo o tráfego de rede baseado em HTTP. Ele usa outros mecanismos para criptografar o tráfego de rede não HTTP que contém dados confidenciais ou de clientes.
- O Power Platform aplica uma configuração TLS reforçada que habilita o HSTS (HTTP Strict Transport Security):
- TLS 1.2 ou posterior
- Pacotes de criptografia baseados em ECDHE e curvas NIST
- Chaves fortes
Dados inativos:
- Todos os dados do cliente são criptografados antes de serem gravados em mídia de armazenamento não involatile.
O Power Platform usa as práticas recomendadas padrão do setor para evitar ataques de injeção, incluindo:
- Uso de APIs seguras com interfaces parametrizadas
- Aplicação dos recursos em constante evolução das estruturas de front-end para sanear a entrada
- Saneamento da saída com validação do lado do servidor
- Uso de ferramentas de análise estática durante o tempo de compilação
- Revisão do Modelo de Ameaças de cada serviço a cada seis meses, independentemente de o código, design ou infraestrutura ter sido atualizado ou não
- O Power Platform é baseado em uma cultura e metodologia de design seguro. A cultura e a metodologia são constantemente reforçadas por meio das práticas de Security Development Lifecycle (SDL) e Modelagem de Ameaças.
- O processo de revisão de Modelagem de Ameaças garante as ameaças sejam identificadas durante a fase de projeto, mitigadas e validadas para garantir que sejam mitigadas.
- A Modelagem de Ameaças também leva em consideração todas as alterações nos serviços que já estão ativos por meio de revisões regulares contínuas. Depender do modelo STRIDE ajuda a resolver os problemas mais comuns com o design inseguro.
- O SDL da Microsoft é equivalente ao SAMM (OWASP Software Assurance Maturity Model). Ambos se baseiam na premissa de que o design seguro é parte essencial da segurança de aplicativos Web.
A05:2021 Configuração incorreta de segurança
- "Negação Padrão" é um dos fundamentos dos princípios de design do Power Platform. Com "Negação Padrão", os clientes precisam analisar e aceitar novos recursos e configurações.
- Quaisquer configurações incorretas durante o tempo de compilação são detectadas pela análise de segurança integrada usando Ferramentas de desenvolvimento seguro.
- Além disso, o Power Platform passa pelo DAST (Teste de Segurança de Análise Dinâmica) usando um serviço interno baseado nos 10 principais riscos da OWASP.
A06:2021 Componentes vulneráveis e desatualizados
- O Power Platform segue as práticas do SDL da Microsoft para gerenciar componentes de código aberto e de terceiros. Essas práticas incluem manter um inventário completo, realizar análises de segurança, manter os componentes atualizados e alinhá-los com um processo de resposta a incidentes de segurança testado e comprovado.
- Em casos raros, alguns aplicativos podem conter cópias de componentes desatualizados devido a dependências externas. No entanto, depois que essas dependências forem tratadas de acordo com as práticas descritas anteriormente, os componentes serão rastreados e atualizados.
A07:2021 Falhas de identificação e autenticação
- O Power Platform foi criado com base no Microsoft Entra ID e depende dele para identificação e autenticação.
- O Microsoft Entra ajuda o Power Platform a habilitar recursos seguros. Esses recursos incluem logon único, autenticação multifator e uma única plataforma para se envolver com usuários internos e externos com mais segurança.
- Com a próxima implementação do Power Platform do Microsoft Entra ID Avaliação contínua de acesso (CAE), a identificação e a autenticação do usuário serão ainda mais seguras e confiáveis.
A08:2021 Falhas de integridade de software e dados
- O processo de Governança de Componentes do Power Platform aplica a configuração segura dos arquivos de origem do pacote para manter a integridade do software.
- O processo garante que apenas pacotes de origem interna sejam atendidos para abordar o ataque de substituição. O ataque de substituição, também conhecido como confusão de dependências, é uma técnica que pode ser usada para corromper o processo de criação de aplicativos em ambientes corporativos seguros.
- Todos os dados criptografados têm proteção de integridade aplicada antes de serem transmitidos. Todos os metadados de proteção de integridade presentes para dados criptografados recebidos são validados.
Os 10 principais riscos de Low Code/No Code da OWASP: mitigações no Power Platform
Para obter orientações sobre como mitigar os 10 principais riscos de segurança de Low Code/No Code publicados pela OWASP, consulte este documento:
Power Platform - Os 10 Principais Riscos de Low Code/No Code da OWASP (Abril de 2024)
Perguntas de segurança comuns dos clientes
Veja a seguir algumas das perguntas sobre segurança que nossos clientes fazem.
Como o Power Platform ajuda a proteger contra clickjacking?
Clickjacking usa iframes incorporados, entre outros componentes, para sequestrar as interações de um usuário com uma página da Web. É uma ameaça significativa para as páginas de entrada em específico. O Power Platform impede o uso de iframes em páginas de entrada, reduzindo significativamente o risco de clickjacking.
Além disso, as organizações podem usar a Política de Segurança de Conteúdo (CSP) para restringir a incorporação a domínios confiáveis.
O Power Platform dá suporte à Política de Segurança de Conteúdo?
O Power Platform dá suporte à Política de segurança de conteúdo (CSP) para aplicativos baseados em modelo. Não damos suporte aos seguintes cabeçalhos que são substituídos pelo CSP:
X-XSS-ProtectionX-Frame-Options
Como podemos nos conectar ao SQL Server com segurança?
Consulte Usar o Microsoft SQL Server de forma segura com o Power Apps.
Quais criptografias têm suporte do Power Platform? Qual é o roteiro para avançar continuamente em direção a criptografias mais fortes?
Todos os serviços e produtos da Microsoft são configurados para usar os pacotes de criptografia aprovados, na ordem exata indicada pela Microsoft Crypto Board. Para obter a lista completa e a ordem exata, consulte a Documentação do Power Platform.
Informações sobre descontinuações de pacotes de criptografia são comunicadas por meio da documentação de Mudanças importantes do Power Platform.
Por que o Power Platform ainda dá suporte às criptografias RSA-CBC (TLS_ECDHE_RSA_with AES_128_CBC_SHA256 (0xC027) e TLS_ECDHE_RSA_with_AES_256_CBC_SHA384 (0xC028)), que são consideradas mais fracas?
A Microsoft avalia o risco relativo e a interrupção às operações do cliente ao escolher os pacotes de criptografia para dar suporte. Os pacotes de criptografia RSA-CBC ainda não foram corrompidos. Nós os habilitamos para garantir consistência em todos os nossos serviços e produtos e para oferecer suporte a todas as configurações do cliente. No entanto, eles estão na parte inferior da lista de prioridades.
Descontinuaremos essas criptografias no momento certo, com base nas avaliações contínuas da Microsoft Crypto Board.
Porque o Power Automate expõe hashes de conteúdo MD5 em entradas e saídas de gatilho/ação?
O Power Automate passa o valor de hash MD5 de conteúdo opcional retornado pelo Azure Storage como está para seus clientes. Esse hash é usado pelo Azure Storage para verificar a integridade da página durante o transporte como um algoritmo de soma de verificação e não é usado como uma função de hash criptográfico para fins de segurança no Power Automate. Encontre mais detalhes na documentação do Azure Storage sobre como Obter propriedades do blob e como trabalhar com Cabeçalhos de solicitação.
Como é que o Power Platform protege contra ataques de DDoS (negação de serviço distribuído)?
O Power Platform baseia-se no Microsoft Azure e usa proteção contra DDoS do Azure para proteger contra ataques de DDoS.
O Power Platform detecta dispositivos iOS com jailbreak e dispositivos Android desbloqueados por rooting para ajudar a proteger os dados organizacionais?
É recomendável usar o Microsoft Intune. O Intune é uma solução de gerenciamento de dispositivo móvel. Ele pode ajudar a proteger os dados organizacionais, exigindo que usuários e dispositivos atendam a determinados requisitos. Para obter mais informações, consulte as Configurações de política de conformidade do Intune.
Por que os cookies de sessão têm como escopo o domínio pai?
O Power Platform tem como escopo os cookies de sessão ao domínio pai para permitir a autenticação entre organizações. Os subdomínios não são usados como limites de segurança. Eles também não hospedam conteúdo do cliente.
Como podemos definir o tempo limite da sessão do aplicativo após, digamos, 15 minutos?
O Power Platform usa o Microsoft Entra ID para gerenciamento de identidades e acesso. Ele segue a configuração da sessão recomendada do Microsoft Entra ID para obter uma experiência de usuário ideal.
No entanto, você pode personalizar ambientes para que tenham tempos limite de sessão e/ou atividade explícitos. Para mais informações, consulte Aprimoramentos de segurança: sessão do usuário e gerenciamento de acesso.
Com a próxima implementação do Power Platform do Microsoft Entra ID avaliação contínua de acesso, a identificação e a autenticação do usuário serão ainda mais seguras e confiáveis.
O aplicativo permite que um mesmo usuário acesse de mais de um computador ou navegador ao mesmo tempo. Como podemos evitar isso?
O acesso ao aplicativo de mais de um dispositivo ou navegador ao mesmo tempo é uma conveniência para usuários. A próxima implementação do Power Platform Microsoft Entra ID Continuous Access Evaluation ajudará a garantir que o acesso seja de dispositivos e navegadores autorizados e ainda seja válido.
Por que alguns dos serviços do Power Platform expõem cabeçalhos de servidor com informações detalhadas?
Os serviços do Power Platform têm trabalhado para remover informações desnecessárias do cabeçalho do servidor. O objetivo é equilibrar o nível de detalhes com o risco de exposição de informações que pode enfraquecer a postura geral de segurança.
Como as vulnerabilidades Log4j afetam o Power Platform? O que os clientes devem fazer a esse respeito?
A Microsoft avaliou que nenhuma vulnerabilidade Log4j afeta o Power Platform. Veja nossa postagem no blog sobre prevenção, detecção e busca para exploração de vulnerabilidades Log4j.
Como podemos garantir que não haja transações não autorizadas devido a extensões do navegador ou APIs de Cliente da Interface Unificada que permitem a ativação de controles desabilitados?
O modelo de segurança do Power Apps não inclui o conceito de controles desabilitados. A desativação de controles é um aprimoramento da interface do usuário. Você não deve depender de controles desabilitados para fornecer segurança. Em vez disso, use os controles de segurança do Dataverse como segurança em nível de campo para impedir transações não autorizadas.
Quais cabeçalhos de segurança HTTP são usados para proteger os dados de resposta?
| Name | Details |
|---|---|
| Strict-Transport-Security | Isso está definido para max-age=31536000; includeSubDomains em todas as respostas. |
| X-Frame-Options | Está preterido a favor de CSP. |
| X-Content-Type-Options | Isso está definido como nosniff em todas as respostas do ativo. |
| Content-Security-Policy | É definido se o usuário habilita o CSP. |
| X-XSS-Protection | Está preterido a favor de CSP. |
Onde posso encontrar testes de penetração do Power Platform ou Dynamics 365?
Os mais recentes testes de penetração e avaliações de segurança podem ser encontrados no Portal de Confiança de Serviço da Microsoft.
Observação
Para acessar alguns dos recursos do Portal de Confiança de Serviço, você deve entrar como usuário autenticado com sua conta dos serviços em nuvem da Microsoft (conta da organização do Microsoft Entra) e revisar e aceitar o contrato de confidencialidade da Microsoft para materiais de conformidade.
Artigos relacionados
Visão geral de segurança
Autenticação em serviços do Power Platform
Como conectar e autenticar em fontes de dados
Armazenamento de dados no Power Platform