Desenvolver aplicações seguras no Azure
Neste artigo, apresentamos atividades e controlos de segurança a considerar quando desenvolver aplicações para a cloud. As perguntas e conceitos de segurança a considerar durante as fases de implementação e verificação do Ciclo de Vida de Desenvolvimento de Segurança (SDL) da Microsoft são abordados. O objetivo é ajudá-lo a definir atividades e serviços do Azure que pode utilizar para desenvolver uma aplicação mais segura.
As seguintes fases de SDL são abordadas neste artigo:
- Implementação
- Verificação
Implementação
O foco da fase de implementação é estabelecer as melhores práticas para a prevenção precoce e detetar e remover problemas de segurança do código. Suponha que a sua aplicação é utilizada de formas que não pretendia que fosse utilizada. Isto ajuda-o a proteger-se contra utilizações indevidas acidentais ou intencionais da sua aplicação.
Efetuar revisões de código
Antes de dar entrada do código, realize revisões de código para aumentar a qualidade geral do código e reduzir o risco de criação de erros. Pode utilizar o Visual Studio para gerir o processo de revisão de código.
Efetuar a análise de código estático
A análise de código estático (também conhecida como análise de código fonte) é efetuada como parte de uma revisão de código. A análise de código estático refere-se frequentemente à execução de ferramentas de análise de código estático para encontrar potenciais vulnerabilidades em código não executado. A análise de código estático utiliza técnicas como a verificação de taint e a análise do fluxo de dados.
Azure Marketplace oferece ferramentas de programação que executam a análise de código estático e ajudam nas revisões de código.
Validar e limpar todas as entradas da sua aplicação
Trate todas as entradas como não fidedignos para proteger a sua aplicação contra as vulnerabilidades de aplicações Web mais comuns. Os dados não fidedignos são um veículo para ataques de injeção. A entrada para a sua aplicação inclui parâmetros no URL, entradas do utilizador, dados da base de dados ou de uma API e tudo o que é transmitido que um utilizador possa potencialmente manipular. Uma aplicação deve validar que os dados são sintaticamente e semanticamente válidos antes de a aplicação utilizar os dados de qualquer forma (incluindo apresentá-lo de volta ao utilizador).
Valide a entrada no início do fluxo de dados para garantir que apenas os dados devidamente formados entram no fluxo de trabalho. Não quer que os dados com formato incorreto persistam na sua base de dados ou que acionem uma avaria num componente a jusante.
A lista de bloqueios e a lista de permissões são duas abordagens gerais para efetuar a validação da sintaxe de entrada:
A lista de bloqueios tenta verificar se uma determinada entrada de utilizador não contém conteúdo "conhecido por ser malicioso".
A lista de permissões tenta verificar se uma determinada entrada de utilizador corresponde a um conjunto de entradas "bem conhecidas". A lista de permissões baseada em carateres é uma forma de lista de permissões em que uma aplicação verifica se a entrada do utilizador contém apenas carateres "bem conhecidos" ou que a entrada corresponde a um formato conhecido.
Por exemplo, isto pode envolver verificar se um nome de utilizador contém apenas carateres alfanuméricos ou que contém exatamente dois números.
A lista de permissões é a abordagem preferencial para a criação de software seguro. A lista de bloqueios é propensa a erros porque é impossível pensar numa lista completa de entradas potencialmente incorretas.
Esta ação funciona no servidor, não no lado do cliente (ou no servidor e no lado do cliente).
Verificar as saídas da aplicação
Qualquer saída que apresente visualmente ou dentro de um documento deve ser sempre codificada e escapada. A fuga, também conhecida como codificação de saída, é utilizada para ajudar a garantir que os dados não fidedignos não são um veículo para um ataque de injeção. A fuga, combinada com a validação de dados, fornece defesas em camadas para aumentar a segurança do sistema como um todo.
Escapar garante que tudo é apresentado como saída. Escapar também permite que o interpretador saiba que os dados não se destinam a ser executados, o que impede que os ataques funcionem. Esta é outra técnica de ataque comum denominada scripting entre sites (XSS).
Se estiver a utilizar uma arquitetura Web de terceiros, pode verificar as suas opções de codificação de saída em sites através da folha de truques e dicas de prevenção OWASP XSS.
Utilizar consultas parametrizadas quando contactar a base de dados
Nunca crie uma consulta de base de dados inline "de imediato" no seu código e envie-a diretamente para a base de dados. O código malicioso inserido na sua aplicação pode potencialmente fazer com que a base de dados seja roubada, eliminada ou modificada. A sua aplicação também pode ser utilizada para executar comandos maliciosos do sistema operativo no sistema operativo que aloja a base de dados.
Em vez disso, utilize consultas parametrizadas ou procedimentos armazenados. Quando utiliza consultas parametrizadas, pode invocar o procedimento a partir do seu código em segurança e transmitir-lhe uma cadeia sem se preocupar com o facto de este ser tratado como parte da instrução de consulta.
Remover cabeçalhos de servidor padrão
Os cabeçalhos como Server, X-Powered-By e X-AspNet-Version revelam informações sobre o servidor e as tecnologias subjacentes. Recomendamos que suprima estes cabeçalhos para evitar a impressão digital da aplicação. Veja Remover cabeçalhos de servidor padrão em sites do Azure.
Segregar os dados de produção
Os seus dados de produção, ou dados "reais", não devem ser utilizados para desenvolvimento, teste ou qualquer outra finalidade que não o pretendido pela empresa. Um conjunto de dados mascarado (anonimizado) deve ser utilizado para todo o desenvolvimento e teste.
Isto significa que menos pessoas têm acesso aos seus dados reais, o que reduz a superfície de ataque. Também significa que menos funcionários vêem dados pessoais, o que elimina uma potencial violação da confidencialidade.
Implementar uma política de palavras-passe segura
Para se defender contra estimativas baseadas em força bruta e dicionário, tem de implementar uma política de palavras-passe forte para garantir que os utilizadores criam uma palavra-passe complexa (por exemplo, 12 carateres de comprimento mínimo e que requerem carateres alfanuméricos e especiais).
O Azure Active Directory B2C ajuda-o com a gestão de palavras-passe ao fornecer reposição personalizada de palavra-passe, forçar a reposição de palavra-passe e muito mais.
Para se defender contra ataques a contas predefinidas, verifique se todas as chaves e palavras-passe são substituíveis e se são geradas ou substituídas depois de instalar os recursos.
Se a aplicação tiver de gerar palavras-passe automaticamente, certifique-se de que as palavras-passe geradas são aleatórias e de que têm elevada entropia.
Validar carregamentos de ficheiros
Se a sua aplicação permitir carregamentos de ficheiros, considere as precauções que pode tomar para esta atividade de risco. O primeiro passo em muitos ataques é colocar algum código malicioso num sistema que está a ser atacado. A utilização de um carregamento de ficheiros ajuda o atacante a fazê-lo. O OWASP oferece soluções para validar um ficheiro para garantir que o ficheiro que está a carregar é seguro.
A proteção antimalware ajuda a identificar e remover vírus, spyware e outro software malicioso. Pode instalar Microsoft Antimalware ou uma solução de proteção de ponto final de parceiro da Microsoft (Trend Micro, Broadcom, McAfeeMicrosoft Defender Antivírus no Windows e Endpoint Protection).
Microsoft Antimalware inclui funcionalidades como proteção em tempo real, análise agendada, remediação de software maligno, atualizações de assinaturas, atualizações do motor, relatórios de exemplos e recolha de eventos de exclusão. Pode integrar soluções de Microsoft Antimalware e parceiros com Microsoft Defender para a Cloud para facilitar a implementação e deteções incorporadas (alertas e incidentes).
Não colocar conteúdo sensível em cache
Não coloque conteúdos confidenciais em cache no browser. Os browsers podem armazenar informações sobre a colocação em cache e o histórico. Os ficheiros em cache são armazenados numa pasta como a pasta Ficheiros Temporários da Internet, no caso do Internet Explorer. Quando estas páginas forem novamente referidas, o browser apresenta as páginas da respetiva cache. Se forem apresentadas informações confidenciais (endereço, detalhes do cartão de crédito, Número de segurança social, nome de utilizador) ao utilizador, as informações poderão ser armazenadas na cache do browser e recuperáveis ao examinar a cache do browser ou ao premir o botão Anterior do browser.
Verificação
A fase de verificação envolve um esforço abrangente para garantir que o código cumpre os princípios de segurança e privacidade que foram estabelecidos nas fases anteriores.
Localizar e corrigir vulnerabilidades nas dependências da aplicação
Analise a sua aplicação e as respetivas bibliotecas dependentes para identificar quaisquer componentes vulneráveis conhecidos. Os produtos disponíveis para efetuar esta análise incluem o OWASP Dependency Check, o Snyk e o Black Duck.
Testar a aplicação num estado operacional
O teste de segurança de aplicações dinâmicas (DAST) é um processo de teste de uma aplicação num estado operacional para encontrar vulnerabilidades de segurança. As ferramentas DAST analisam programas enquanto executam para encontrar vulnerabilidades de segurança, tais como danos na memória, configuração insegura do servidor, scripting entre sites, problemas de privilégios de utilizador, injeção de SQL e outras preocupações de segurança críticas.
O DAST é diferente do teste de segurança de aplicações estáticas (SAST). As ferramentas SAST analisam o código fonte ou as versões compiladas do código quando o código não está a ser executado para encontrar falhas de segurança.
Execute o DAST, preferencialmente com a ajuda de um profissional de segurança (um avaliador de vulnerabilidades ou de teste de penetração ). Se um profissional de segurança não estiver disponível, pode executar o DAST manualmente com um scanner de proxy Web e alguma formação. Ligue um scanner DAST desde cedo para garantir que não introduz problemas de segurança óbvios no seu código. Veja o site OWASP para obter uma lista de detetores de vulnerabilidades de aplicações Web.
Efetuar testes de fuzz
Nos testes de fuzz, induz a falha do programa ao introduzir deliberadamente dados mal formados ou aleatórios numa aplicação. Induzir a falha do programa ajuda a revelar potenciais problemas de segurança antes de a aplicação ser lançada.
A Deteção de Riscos de Segurança é o serviço de teste de fuzz exclusivo da Microsoft para encontrar erros críticos de segurança no software.
Realizar revisão da superfície de ataque
Rever a superfície de ataque após a conclusão do código ajuda a garantir que quaisquer alterações de estrutura ou implementação a uma aplicação ou sistema foram consideradas. Ajuda a garantir que quaisquer novos vetores de ataque criados como resultado das alterações, incluindo modelos de ameaças, foram revistos e mitigados.
Pode criar uma imagem da superfície de ataque ao analisar a aplicação. A Microsoft oferece uma ferramenta de análise de superfície de ataque denominada Attack Surface Analyzer. Pode escolher entre muitas ferramentas ou serviços de análise de vulnerabilidades e testes dinâmicos comerciais, incluindo o Detetor de Superfície de Ataque OWASP, Aracnídeo e w3af. Estas ferramentas de análise pesquisam a sua aplicação e mapeiam as partes da aplicação que estão acessíveis através da Web. Também pode procurar ferramentas de programador semelhantes no Azure Marketplace.
Realizar testes de penetração de segurança
Garantir que a sua aplicação é segura é tão importante como testar qualquer outra funcionalidade. Torne os testes de penetração uma parte padrão do processo de compilação e implementação. Agende testes de segurança regulares e análise de vulnerabilidades em aplicações implementadas e monitorize portas abertas, pontos finais e ataques.
Executar testes de verificação de segurança
A Solução de Segurança do Inquilino do Azure (AzTS) do Secure DevOps Kit para o Azure (AzSK) contém SVTs para vários serviços da plataforma do Azure. Executa estes SVTs periodicamente para garantir que a sua subscrição do Azure e os diferentes recursos que compõem a sua aplicação estão num estado seguro. Também pode automatizar estes testes com a funcionalidade de extensões de integração/implementação contínua (CI/CD) do AzSK, o que torna os SVTs disponíveis como uma extensão do Visual Studio.
Passos seguintes
Nos artigos seguintes, recomendamos controlos de segurança e atividades que o possam ajudar a conceber e implementar aplicações seguras.