Recomendações para testes de segurança
Aplica-se a esta Power Platform recomendação de lista de verificação de segurança bem arquitetada:
| SE:09 | Estabeleça um regime de teste abrangente que combine abordagens para evitar problemas de segurança, validar implementações de prevenção de ameaças e testar mecanismos de deteção de ameaças. |
|---|
Testes rigorosos são a base de um bom design de segurança. Os testes são uma forma tática de validação para garantir que os controlos estão a funcionar conforme esperado. Os testes são também uma forma proativa de detetar vulnerabilidades no sistema.
Estabeleça o rigor dos testes através da cadência e verificação a partir de múltiplas perspetivas. Deve incluir pontos de vista de dentro para fora que testam a plataforma e a infraestrutura, e avaliações externas que testam o sistema como um atacante externo.
Este guia fornece recomendações para testar a postura de segurança da sua carga de trabalho. Implemente esses métodos de teste para melhorar a resistência da carga de trabalho a ataques e manter a confidencialidade, integridade e disponibilidade de recursos.
Definições
| Termo | Definição |
|---|---|
| Testes de segurança de aplicações (AST) | Uma Microsoft técnica SDL (Security Development Lifecycle - Ciclo de vida de desenvolvimento de segurança) que usa metodologias de teste de caixa branca e caixa preta para verificar vulnerabilidades de segurança no código. |
| Testes de caixa preta | Uma metodologia de teste que valida o comportamento da aplicação visível externamente, sem conhecimento dos elementos internos do sistema. |
| Equipa azul | Uma equipa que defende contra os ataques da equipa vermelha num exercício de jogo de guerra. |
| Testes de penetração | Uma metodologia de teste que utiliza técnicas éticas de hacking para validar as defesas de segurança de um sistema. |
| Equipa vermelha | Uma equipa que desempenha o papel de um adversário e tenta atacar o sistema num exercício de jogo de guerra. |
| Ciclo de Vida do Desenvolvimento de Segurança (SDL) | Um conjunto de práticas fornecidas que Microsoft suporta a garantia de segurança e os requisitos de conformidade. |
| Ciclo de vida do desenvolvimento de software (SDLC) | Um processo sistemático e em várias fases para o desenvolvimento de sistemas de software. |
| Testes de caixa branca | Uma metodologia de teste onde a estrutura do código é conhecida pelo profissional. |
Principais estratégias de design
Os testes são uma estratégia inegociável, especialmente para a segurança. Permite descobrir e resolver proactivamente problemas de segurança antes que estes possam ser explorados e verificar se os controlos de segurança que implementou estão a funcionar como previsto.
O âmbito dos testes deve incluir a aplicação, a infraestrutura e os processos automatizados e humanos.
Nota
Esta orientação faz uma distinção entre testes e resposta a incidentes. Embora o teste seja um mecanismo de deteção que corrige idealmente problemas antes da produção, não deve ser confundido com a correção ou investigação que é feita como parte da resposta a incidentes. O aspeto da recuperação de incidentes de segurança é descrito em Recomendações para resposta a incidentes de segurança.
Envolva-se no planeamento de testes. A equipa de carga de trabalho pode não projetar os casos de teste. Essa tarefa normalmente é centralizada na empresa ou concluída por especialistas externos em segurança. A equipa de carga de trabalho deve estar envolvida nesse processo de design para garantir que as garantias de segurança se integrem à funcionalidade da aplicação.
Pense como um atacante. Projete seus casos de teste com a suposição de que o sistema foi atacado. Dessa forma, pode descobrir as vulnerabilidades potenciais e priorizar os testes em conformidade.
Execute testes de forma estruturada e com um processo repetível. Desenvolva o rigor dos seus testes em torno da cadência, tipos de testes, fatores determinantes e resultados pretendidos.
Utilize a ferramenta certa para a tarefa. Utilize ferramentas configuradas para trabalhar com a carga de trabalho. Se não tiver uma ferramenta, compre-a. Não a compile. As ferramentas de segurança são altamente especializadas e criar a sua própria ferramenta pode introduzir riscos. Aproveite a experiência e as ferramentas oferecidas pelas equipas centrais de SecOps ou por meios externos se a equipa de carga de trabalho não tiver essa experiência.
Configure ambientes separados. Os testes podem ser classificados como destrutivos ou não destrutivos. Os testes não destrutivos não são invasivos. Indicam que há um problema, mas não alteram a funcionalidade para remediar o problema. Os testes destrutivos são invasivos e podem danificar a funcionalidade ao excluir dados de um banco de dados.
Os testes em ambientes de produção fornecem as melhores informações, mas causam mais interrupções. Existe a tendência para fazer apenas testes não destrutivos em ambientes de produção. Normalmente, os testes em ambientes de não produção causam menos interrupções, mas podem não representar com precisão a configuração do ambiente de produção de formas importantes para a segurança.
Pode criar um clone isolado do seu ambiente de produção utilizando a funcionalidade de cópia de ambientes. Se tiver pipelines de implementação configurados, também poderá implementar as suas soluções num ambiente de teste dedicado.
Avalie sempre os resultados dos testes. Os testes são um esforço desperdiçado se os resultados não forem utilizados para priorizar ações e fazer melhorias a montante. Documente as diretrizes de segurança, incluindo as melhores práticas, que descobrir. A documentação que captura resultados e planos de remediação educa a equipa sobre as várias maneiras pelas quais os invasores podem tentar violar a segurança. Realize formações regulares de segurança para programadores, administradores e testadores.
Ao projetar os seus planos de teste, pense nas seguintes perguntas:
- Com que frequência espera que o teste seja executado e de que forma afeta o ambiente?
- Quais são os diferentes tipos de teste que deve executar?
Com que frequência espera que os testes sejam executados?
Teste a carga de trabalho regularmente para garantir que as alterações não introduzem riscos de segurança e que não há regressões. A equipa também tem de estar pronta para responder às validações de segurança organizacional que possam ser realizadas em qualquer altura. Também há testes em que pode executar em resposta a um incidente de segurança. As secções seguintes fornecem recomendações sobre a frequência dos testes.
Testes de rotina
Os testes de rotina são realizados com uma cadência regular, como parte de seus procedimentos operacionais padrão e para atender aos requisitos de conformidade. Podem ser executados vários testes em cadências diferentes, mas a chave é eles serem realizados periodicamente e de acordo com um agenda.
Deve integrar esses testes no seu SDLC porque eles fornecem defesa em profundidade em cada fase. Diversifique o conjunto de testes para verificar as garantias de identidade, armazenamento e transmissão de dados e canais de comunicação. Realize os mesmos testes em diferentes pontos do ciclo de vida para garantir que não há regressões. Os testes de rotina ajudam a estabelecer uma referência inicial. No entanto, isso é apenas um ponto de partida. À medida que descobre novos problemas nos mesmos pontos do ciclo de vida, adiciona novos casos de teste. Os testes também melhoram com a repetição.
Em cada etapa, esses testes devem validar o código que é adicionado ou removido ou as definições de configuração que foram alteradas para detetar o impacto na segurança dessas alterações. Deve melhorar a eficácia dos testes com automatização, equilibrada com revisões por pares.
Considere a execução de testes de segurança como parte de um pipeline automatizado ou de uma execução de teste agendada. Quanto mais cedo descobrir os problemas de segurança, mais fácil será encontrar o código ou a alteração de configuração que os causa.
Não confie apenas em testes automatizados. Use testes manuais para detetar vulnerabilidades que apenas a perícia humana pode detetar. Os testes manuais são úteis para os casos de utilização exploratórios e para encontrar riscos desconhecidos.
Testes improvisados
Os testes improvisados fornecem validação pontual no tempo das defesas de segurança. Os alertas de segurança que podem afetar a carga de trabalho nesse momento acionam esses testes. Os mandatos organizacionais podem exigir uma mentalidade de pausa e teste para verificar a eficácia das estratégias de defesa se o alerta escalar para uma emergência.
A vantagem dos testes improvisados é a preparação para um incidente real. Estes testes podem ser uma função forçada para fazer testes de aceitação dos utilizadores (UAT).
A equipa de segurança poderá auditar todas as cargas de trabalho e executar estes testes conforme necessário. Como proprietário da carga de trabalho, necessita de facilitar e colaborar com equipas de segurança. Negocie tempo de entrega suficiente com as equipas de segurança para que se possa preparar. Reconheça e comunique à sua equipa e aos intervenientes que estas interrupções são necessárias.
Noutros casos, pode ser necessário executar testes e relatar o estado de segurança do sistema contra a ameaça potencial.
Compensação: Como os testes improvisados são eventos disruptivos, espere repriorizar tarefas, o que pode atrasar outros trabalhos planejados.
Risco: Há risco do desconhecido. Os testes improvisados podem ser esforços pontuais sem processos ou ferramentas estabelecidas. Mas o risco predominante é a potencial interrupção do ritmo dos negócios. É necessário avaliar esses riscos em relação aos benefícios.
Testes de incidentes de segurança
Existem testes que detetam a causa de um incidente de segurança na sua origem. Estas lacunas de segurança têm de ser resolvidas para garantir que o incidente não se repete.
Os incidentes também melhoram os casos de teste ao longo do tempo, descobrindo lacunas existentes. A equipa deve aplicar as lições aprendidas com o incidente e incorporar melhorias de forma rotineira.
Quais são os diferentes tipos de testes?
Os testes podem ser categorizados por tecnologia e por metodologias de teste. Combine essas categorias e abordagens dentro dessas categorias para obter uma cobertura completa.
Ao adicionar vários testes e tipos de testes, pode descobrir:
- Lacunas nos controlos de segurança ou nos controlos de compensação.
- Configurações incorretas.
- Lacunas nos métodos de observabilidade e deteção.
Um bom exercício de modelação de ameaças pode apontar para áreas chave para garantir a cobertura e a frequência dos testes. Para obter recomendações sobre a modelação de ameaças, consulte Recomendações para garantir um ciclo de vida de desenvolvimento.
A maioria dos testes descritos nestas secções podem ser executados como testes de rotina. No entanto, a repetibilidade pode incorrer em custos em alguns casos e causar interrupções. Considere esses compromissos cuidadosamente.
Testes que validam a pilha de tecnologia
Seguem-se alguns exemplos de tipos de testes e as suas áreas de foco. Esta lista não é exaustiva. Teste toda a pilha, incluindo a pilha de aplicações, front-end, back-end, APIs, bases de dados e quaisquer integrações externas.
- Segurança de dados: teste a eficácia da criptografia de dados e dos controles de acesso para garantir que os dados estejam devidamente protegidos contra acesso não autorizado e adulteração.
- Rede e conectividade: teste seus firewalls para garantir que eles permitam apenas tráfego esperado, permitido e seguro para a carga de trabalho.
- Aplicativo: teste o código-fonte por meio de técnicas de teste de segurança de aplicativo (AST) para garantir que você siga práticas de codificação segura e para detetar erros de tempo de execução, como corrupção de memória e problemas de privilégio.
- Identidade: avalie se as atribuições de função e as verificações condicionais funcionam como pretendido.
Metodologia de teste
Existem muitas perspetivas sobre as metodologias de teste. Recomendamos testes que permitam a procura de ameaças ao simular ataques do mundo real. Podem identificar potenciais agentes de ameaça, as suas técnicas e suas explorações que representam uma ameaça à carga de trabalho. Torne os ataques o mais realistas possível. Use todos os vetores de ameaças potenciais que identificar durante a modelação de ameaças.
Seguem-se algumas vantagens de testar através de ataques do mundo real:
- Quando faz desses ataques uma parte dos testes de rotina, usa uma perspetiva de fora para dentro para verificar a carga de trabalho e certificar-se de que a defesa pode resistir a um ataque.
- Com base nas lições aprendidas, a equipa atualiza os seus conhecimentos e o nível de competência. A equipa melhora a consciência situacional e pode autoavaliar a sua prontidão para responder a incidentes.
Alguns exemplos de testes simulados incluem testes de caixa preta e caixa branca, testes de penetração e exercícios de jogos de guerra.
Testes de caixa preta e caixa branca
Esses tipos de teste oferecem duas perspetivas diferentes. Nos testes de caixa preta, o sistema interno não é visível. Em testes de caixa branca, o testador tem um bom entendimento da aplicação e tem inclusivamente acesso ao código, registos, topologia de recursos e configurações para conduzir a experiência.
Testes que simulam ataques através de testes de penetração
Os especialistas em segurança que não fazem parte das equipas de TI ou de aplicações da organização realizam testes de penetração ou pentesting. Olham para o sistema da mesma forma que os agentes mal-intencionados abordam uma superfície de ataque. O objetivo é encontrar lacunas de segurança através da recolha de informações, análise de vulnerabilidades e comunicação dos resultados.
Os profissionais podem precisar de acesso a dados confidenciais em toda a organização. Siga as regras de interação para garantir que o acesso não é utilizado indevidamente. Consulte os recursos listados em Informações relacionadas.
Testes que simulam ataques através de exercícios de jogos de guerra
Nesta metodologia de ataques simulados, existem duas equipas:
- A equipa vermelha é o adversário que tenta modelar ataques do mundo real. Se for bem-sucedida, encontrará lacunas no seu projeto de segurança e avaliará a contenção do raio de explosão das suas violações.
- A equipa azul é a equipa da carga de trabalho que se defende dos ataques. Testam a sua capacidade de detetar, responder e remediar os ataques. Validam as defesas que foram implementadas para proteger os recursos da carga de trabalho.
Se forem realizados como testes de rotina, os exercícios de jogos de guerra podem fornecer visibilidade contínua e garantia de que suas defesas funcionam conforme projetado. Os exercícios de jogos de guerra podem ser testados em todos os níveis dentro de suas cargas de trabalho.
Uma escolha popular para simular cenários de ataque realistas é o treinamento Microsoft de simulação Defender Office 365 forAttack.
Para mais informações, consulte Informações e relatórios para formação em simulação de ataques.
Para obter informações sobre a configuração de equipa vermelha e equipa azul, consulte Microsoft Cloud Red Teaming.
Facilitação do Power Platform
Microsoft A solução Sentinel for Microsoft Power Platform permite que os clientes detetem várias atividades suspeitas, tais como:
- Execução do Power Apps a partir de localizações geográficas não autorizadas
- Destruição de dados suspeitos pelo Power Apps
- Eliminação em massa do Power Apps
- Ataques de phishing efetuados através do Power Apps
- Atividade de fluxos do Power Automate por colaboradores de saída
- Conectores do Microsoft Power Platform adicionados a um ambiente
- Atualização ou remoção de políticas de prevenção de perda de dados do Microsoft Power Platform
Para obter mais informações, consulte Microsoft Solução Sentinel para Microsoft Power Platform obter uma visão geral.
Para obter a documentação do produto, consulte Recursos de caça no Microsoft Sentinel.
Microsoft O Defender for Cloud oferece verificação de vulnerabilidades para várias áreas de tecnologia. Para obter mais informações, consulte Habilitar a verificação de vulnerabilidades com Microsoft o Defender Vulnerability Management.
A prática de DevSecOps integra testes de segurança como parte de uma mentalidade de melhoria contínua e permanente. Os exercícios de jogos de guerra são uma prática comum que está integrada no ritmo dos negócios Microsoft. Para mais informações, consulte Segurança em DevOps (DevSecOps).
O Azure DevOps suporta ferramentas de terceiros que podem ser automatizadas como parte dos pipelines de integração contínua/implementação contínua (CI/CD). Para mais informações, consulte Ativar DevSecOps com o Azure e o GitHub.
Informações relacionadas
Os mais recentes testes de penetração e avaliações de segurança podem ser encontrados no Portal de Confiança do Microsoft Serviço.
Microsoft realiza testes extensivos dos Microsoft serviços de nuvem. Este teste inclui testes de penetração, com resultados publicados no Portal de Confiança do Serviço da sua organização. A sua organização pode executar um teste de penetração próprio nos serviços do Microsoft Power Platform e do Microsoft Dynamics 365. Todos os testes de penetração devem seguir as Microsoft Regras de Engajamento do Teste de Penetração na Nuvem. É importante lembrar que, em muitos casos, a Microsoft nuvem usa infraestrutura compartilhada para hospedar seus ativos e ativos pertencentes a outros clientes. Tem de limitar todos os testes de penetração aos seus ativos e evitar consequências não intencionais para outros clientes ao seu redor.
Siga as regras de interação para garantir que o acesso não é utilizado indevidamente. Para obter orientações sobre como planear e executar ataques simulados, consulte:
Pode simular ataques de negação de serviço (DoS) no Azure. Certifique-se de seguir as políticas estabelecidas nos Testes de simulação da Proteção contra DDoS do Azure.
Lista de verificação de segurança
Consulte o conjunto completo de recomendações.