Partilhar via

Desenvolver aplicativos seguros no Azure

Neste artigo, apresentamos atividades e controles de segurança a serem considerados ao desenvolver aplicativos para a nuvem. São abordadas questões de segurança e conceitos a considerar durante as fases de implementação e verificação do Microsoft Security Development Lifecycle (SDL). O objetivo é ajudá-lo a definir atividades e serviços do Azure que você pode usar para desenvolver um aplicativo mais seguro.

As seguintes fases do SDL são abordadas neste artigo:

  • Implementation
  • Verification

Implementation

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 seu aplicativo é usado de maneiras que você não pretendia que ele fosse usado. Isso ajuda você a se proteger contra o uso indevido acidental ou intencional do seu aplicativo.

Realizar revisões de código

Antes de integrar o código, realize revisões de código para aumentar a qualidade geral do software e reduzir o risco de introdução de erros. Podes usar o Visual Studio para gerir o processo de revisão de código.

Executar análise de código estático

A análise estática de código (também conhecida como análise de código-fonte) é realizada como parte de uma revisão de código. A análise de código estático geralmente refere-se à execução de ferramentas de análise de código estático para encontrar vulnerabilidades potenciais em código não executante. A análise estática de código utiliza técnicas como verificação de taint e análise de fluxo de dados.

O Azure Marketplace oferece ferramentas para programadores que realizam análises estáticas de código e auxiliam nas revisões de código.

Valide e limpe todas as entradas para a sua aplicação

Trate todas as entradas como não confiáveis para proteger seu aplicativo contra as vulnerabilidades mais comuns do aplicativo Web. Dados não confiáveis são um veículo para ataques de injeção. A entrada para seu aplicativo inclui parâmetros na URL, entrada do usuário, dados do banco de dados ou de uma API e tudo o que é passado que um usuário pode potencialmente manipular. Uma aplicação deve validar que os dados são sintaticamente e semanticamente válidos antes de utilizar os dados de qualquer forma (incluindo a sua apresentação ao utilizador).

Valide a entrada no início do fluxo de dados para garantir que apenas os dados formados corretamente entrem no fluxo de trabalho. Você não quer que dados malformados persistam em seu banco de dados ou acionem um mau funcionamento em um componente downstream.

Listas de bloqueio e listas de autorização são duas abordagens gerais para realizar a validação da sintaxe de entrada.

  • A lista de bloqueio tenta verificar se uma determinada entrada do usuário não contém conteúdo "conhecido por ser malicioso".

  • A listagem de permissões tenta verificar se uma determinada entrada do utilizador corresponde a um conjunto de entradas reconhecidas como seguras. Lista de aprovação baseada em caracteres é uma forma de lista de aprovação em que uma aplicação verifica se a entrada do utilizador contém apenas caracteres conhecidos como seguros ou se a entrada corresponde a um formato conhecido.

    Por exemplo, isso pode envolver a verificação de que um nome de usuário contém apenas caracteres alfanuméricos ou se contém exatamente dois números.

Allowlisting é a abordagem preferida para a criação de software seguro. A lista de bloqueio é propensa a erros porque é impossível pensar em uma lista completa de entradas potencialmente ruins.

Faça esse trabalho no servidor, não no lado do cliente (ou no servidor e no lado do cliente).

Verificar as saídas do seu aplicativo

Qualquer informação que você(s) apresente visualmente ou dentro de um documento deverá sempre ser codificada e escapada. A fuga, também conhecida como codificação de saída, é usada para ajudar a garantir que dados não confiáveis não sejam 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 é mostrado como saída. Escapar também permite ao interpretador saber que os dados não são destinados a ser executados, o que impede que os ataques funcionem. Esta é outra técnica comum de ataque chamada cross-site scripting (XSS).

Se você estiver usando uma estrutura da Web de terceiros, poderá verificar suas opções de codificação de saída em sites usando o cheat sheet de prevenção OWASP XSS.

Usar consultas parametrizadas ao entrar em contato com o banco de dados

Nunca crie uma consulta de base de dados inline de forma improvisada no seu código e envie-a diretamente para a base de dados. O código mal-intencionado inserido em seu aplicativo pode potencialmente fazer com que seu banco de dados seja roubado, apagado ou modificado. Seu aplicativo também pode ser usado para executar comandos mal-intencionados do sistema operacional no sistema operacional que hospeda seu banco de dados.

Em vez disso, use consultas parametrizadas ou procedimentos armazenados. Quando você usa consultas parametrizadas, você pode invocar o procedimento do seu código com segurança e passá-lo uma cadeia de caracteres sem se preocupar que ele será tratado como parte da instrução de consulta.

Remover cabeçalhos de servidor padrão

Cabeçalhos como Server, X-Powered-By e X-AspNet-Version revelam informações sobre o servidor e as tecnologias subjacentes. Recomendamos que você suprima esses cabeçalhos para evitar a impressão digital do aplicativo. Consulte removendo cabeçalhos de servidor padrão em sites do Azure.

Separe seus dados de produção

Seus dados de produção, ou dados "reais", não devem ser usados para desenvolvimento, teste ou qualquer outra finalidade que não seja a pretendida pela empresa. Deve ser utilizado um conjunto de dados mascarado (anonimizado) para todo o desenvolvimento e testes.

Isso significa que menos pessoas têm acesso aos seus dados reais, o que reduz sua superfície de ataque. Isso também significa que menos funcionários veem dados pessoais, o que elimina uma potencial violação de confidencialidade.

Implementar uma política de senha forte

Para se defender contra a força bruta e a adivinhação baseada em dicionário, você deve implementar uma política de senha forte para garantir que os usuários criem uma senha complexa (por exemplo, comprimento mínimo de 12 caracteres e exigindo caracteres alfanuméricos e especiais).

O Microsoft Entra External ID em locatários externos ajuda você com o gerenciamento de senhas, fornecendo redefinição de senha de autoatendimento e muito mais.

Para se defender contra ataques a contas padrão, verifique se todas as chaves e senhas são substituíveis e se são geradas ou substituídas após a instalação de recursos.

Se o aplicativo precisar gerar senhas automaticamente, certifique-se de que as senhas geradas sejam aleatórias e que tenham alta entropia.

Validar carregamentos de ficheiros

Se a sua candidatura permite o carregamento de ficheiros, considere precauções que pode tomar para esta atividade arriscada. O primeiro passo em muitos ataques é colocar algum código malicioso em um sistema que está sob ataque. Usar um upload de arquivo ajuda o invasor a fazer isso. O OWASP oferece soluções para validar um arquivo para garantir que o arquivo que você está carregando é seguro.

A proteção antimalware ajuda a identificar e remover vírus, spyware e outros softwares mal-intencionados. Pode instalar o Microsoft Antimalware ou a solução de proteção de endpoints de um parceiro da Microsoft (Trend Micro, Broadcom, McAfee, Microsoft Defender Antivirus no Windows e Endpoint Protection).

O Microsoft Antimalware inclui funcionalidades como proteção em tempo real, varredura programada, remediação de malware, atualizações de assinaturas, atualizações do motor, relatórios de exemplos e recolha de eventos de exclusão. Você pode integrar o Microsoft Antimalware e soluções de parceiros com o Microsoft Defender for Cloud para facilitar a implantação e deteções internas (alertas e incidentes).

Não armazene em cache conteúdo confidencial

Não armazene em cache conteúdo confidencial no navegador. Os navegadores podem armazenar informações para cache e histórico. Os arquivos armazenados em cache são armazenados em uma pasta como a pasta Temporary Internet Files, no caso do Internet Explorer. Quando essas páginas são referidas novamente, o navegador exibe as páginas de seu cache. Se informações sensíveis (morada, dados do cartão de crédito, número de segurança social, nome de utilizador) forem exibidas ao utilizador, a informação pode ser armazenada na cache do navegador e ser recuperada examinando a cache do navegador ou pressionando o botão Voltar do navegador.

Verification

A fase de verificação envolve um esforço abrangente para garantir que o código atenda aos princípios de segurança e privacidade estabelecidos nas fases anteriores.

Localizar e corrigir vulnerabilidades nas dependências do seu aplicativo

Você verifica seu aplicativo e suas bibliotecas dependentes para identificar quaisquer componentes vulneráveis conhecidos. Os produtos que estão disponíveis para executar essa verificação incluem OWASP Dependency Check, Snyk e Black Duck.

Teste seu aplicativo em um estado operacional

O teste dinâmico de segurança de aplicativos (DAST) é um processo de teste de um aplicativo em um estado operacional para encontrar vulnerabilidades de segurança. As ferramentas DAST analisam programas durante a execução para encontrar vulnerabilidades de segurança, como corrupção de memória, configuração insegura do servidor, scripts entre sites, problemas de privilégio do usuário, injeção de SQL e outras preocupações críticas de segurança.

O DAST é diferente do teste estático de segurança de aplicativos (SAST). As ferramentas SAST analisam o código-fonte ou versões compiladas do código quando o código não está em execução para encontrar falhas de segurança.

Realizar DAST, preferencialmente com a ajuda de um profissional de segurança (um testador de penetração ou avaliador de vulnerabilidades). Se um profissional de segurança não estiver disponível, você mesmo pode executar o DAST com um scanner de proxy da Web e algum treinamento. Conecte um scanner DAST logo no início para garantir que você não introduza problemas de segurança óbvios em seu código. Consulte o site OWASP para uma lista de scanners de vulnerabilidades para aplicações web.

Realizar testes de fuzzing

Nos testes de fuzz, induz-se a falha do programa ao introduzir deliberadamente dados mal formados ou aleatórios numa aplicação. Induzir a falha do programa ajuda a revelar possíveis problemas de segurança antes que o aplicativo seja lançado.

A Deteção de Risco de Segurança é o serviço de teste difuso exclusivo da Microsoft para encontrar bugs críticos de segurança no software.

Realizar revisão da superfície de ataque

A revisão da superfície de ataque após a conclusão do código ajuda a garantir que quaisquer alterações de design ou implementação em um aplicativo ou sistema tenham sido consideradas. Ele ajuda a garantir que quaisquer novos vetores de ataque criados como resultado das alterações, incluindo modelos de ameaça, tenham sido revisados e mitigados.

Você pode criar uma imagem da superfície de ataque verificando o aplicativo. A Microsoft oferece uma ferramenta de análise de superfície de ataque chamada Analisador de Superfície de Ataque. Você pode escolher entre muitos testes dinâmicos comerciais e ferramentas ou serviços de varredura de vulnerabilidades, incluindo OWASP Attack Surface Detetor, Arachni e w3af. Essas ferramentas de verificação rastreiam seu aplicativo e mapeiam as partes do aplicativo que podem ser acessadas pela Web. Também pode pesquisar no Azure Marketplace ferramentas de desenvolvimento semelhantes.

Realizar testes de penetração de segurança

Garantir que seu aplicativo esteja seguro é tão importante quanto testar qualquer outra funcionalidade. Tornar os testes de penetração uma parte padrão do processo de construção e implementação. Agende testes de segurança regulares e análise de vulnerabilidades em aplicações implementadas e monitore portas abertas, endpoints e ataques.

Executar testes de verificação de segurança

A Solução de Segurança do Locatário do Azure (AzTS) do Kit de DevOps Seguro para o Azure (AzSK) contém SVTs para vários serviços da plataforma Azure. Você executa essas SVTs periodicamente para garantir que sua assinatura do Azure e os diferentes recursos que compõem seu aplicativo estejam em um estado seguro. Você também pode automatizar esses testes usando o recurso de extensões de integração contínua/implantação contínua (CI/CD) do AzSK, que disponibiliza SVTs como uma extensão do Visual Studio.

Passos seguintes

Nos artigos a seguir, recomendamos controles de segurança e atividades que podem ajudá-lo a projetar e implantar aplicativos seguros.

  • Last updated on