Compartilhar via

Desenvolver aplicativos seguros no Azure

Neste artigo, apresentamos atividades de segurança e controles a serem considerados ao desenvolver aplicativos para a nuvem. Perguntas e conceitos de segurança a serem considerados durante as fases de implementação e verificação do SDL (Ciclo de Vida de Desenvolvimento de Segurança da Microsoft) são abordados. 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 de prevenção precoce e detectar e remover problemas de segurança do código. Suponha que seu aplicativo seja 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 de seu aplicativo.

Executar revisões de código

Antes de integrar o código, realize revisões de código para aumentar a qualidade geral do código e reduzir o risco de criar bugs. Você pode usar o Visual Studio para gerenciar o processo de revisão de código.

Executar 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) é executada como parte de uma revisão de código. A análise de código estático geralmente se refere à execução de ferramentas de análise de código estático para encontrar possíveis vulnerabilidades no código de não execução. A análise de código estático usa técnicas como verificação de mancha e análise de fluxo de dados.

O Azure Marketplace oferece ferramentas de desenvolvedor que executam a análise de código estático e auxiliam nas revisões de código.

Validar e sanitizar cada entrada para seu aplicativo

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 qualquer coisa passada em que um usuário poderia potencialmente manipular. Um aplicativo deve validar se os dados são sintaticamente e semanticamente válidos antes que o aplicativo use os dados de qualquer maneira (incluindo exibi-los de volta para o usuário).

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

A lista de bloqueios e a lista de permissões são duas abordagens gerais para executar a validação da sintaxe de entrada:

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

  • Tentativas da lista de permitidos de verificar se determinada entrada do usuário corresponde a um conjunto de entradas "conhecidas como boas". A lista de permissões baseada em caracteres é uma forma de lista de permissões em que um aplicativo verifica se a entrada do usuário contém apenas caracteres "bons conhecidos" ou que 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 que ele 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 em uma lista completa de entradas potencialmente ruins.

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

Verificar as saídas do aplicativo

Qualquer saída que você apresente visualmente ou dentro de um documento sempre deve ser codificada e com escape. O escape, também conhecido como codificação de saída, é usado para garantir que dados não confiáveis não sejam um veículo para um ataque de injeção. O escape, combinado com a validação de dados, fornece defesas em camadas para aumentar a segurança do sistema como um todo.

O escape garante que tudo seja exibido como saída. O escape também permite que o interpretador saiba que os dados não devem ser executados e isso impede que os ataques funcionem. Essa é outra técnica de ataque comum 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 a folha de referências de prevenção de OWASP XSS.

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

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

Em vez disso, use consultas parametrizadas ou procedimentos armazenados. Ao usar consultas parametrizadas, você pode invocar o procedimento de seu código com segurança e passá-lo em 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 suprimir esses cabeçalhos para evitar a impressão digital do aplicativo. Consulte a remoção de cabeçalhos de servidor padrão em sites do Azure.

Segregar 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 o que a empresa pretendia. Um conjunto de dados mascarado (anônimo) deve ser usado para todo o desenvolvimento e teste.

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 possível 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 que exija caracteres alfanuméricos e especiais).

A ID externa do Microsoft Entra nos locatários externos ajuda no gerenciamento de senhas, fornecendo redefinição de senha self-service e muito mais.

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

Se o aplicativo precisar gerar senhas automaticamente, verifique se as senhas geradas são aleatórias e se elas têm alta entropia.

Validar envios de arquivo

Se o aplicativo permitir uploads de arquivo, considere as precauções que você pode tomar para essa atividade arriscada. A primeira etapa em muitos ataques é colocar algum código mal-intencionado 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 seja seguro.

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

O Microsoft Antimalware inclui recursos como proteção em tempo real, verificação agendada, correção de malware, atualizações de assinatura, atualizações do mecanismo, relatórios de exemplos e coleta de eventos de exclusão. Você pode integrar o Microsoft Antimalware e soluções de parceiros ao Microsoft Defender para Nuvem a fim de facilitar a implantação e as detecções internas (alertas e incidentes).

Não armazenar conteúdo confidencial em cache

Não armazene conteúdo confidencial em cache 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 Arquivos temporários da Internet, no caso do Internet Explorer. Quando essas páginas são referenciadas novamente, o navegador exibe as páginas de seu cache. Se informações confidenciais (endereço, detalhes do cartão de crédito, número de segurança social, nome de usuário) forem exibidas ao usuário, as informações poderão ser armazenadas no cache do navegador e recuperáveis examinando o 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 em suas dependências de aplicativo

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

Testar seu aplicativo em um estado operacional

O DAST (teste dinâmico de segurança de aplicativo) é um processo de teste de um aplicativo em um estado operacional para encontrar vulnerabilidades de segurança. As ferramentas DAST analisam programas enquanto estão em execução para encontrar vulnerabilidades de segurança, como corrupção de memória, configuração de servidor insegura, 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 SAST (teste de segurança de aplicativo estático). As ferramentas SAST analisam o código-fonte ou as versões compiladas do código quando o código não está em execução para encontrar falhas de segurança.

Execute o DAST, preferencialmente com a assistência de um profissional de segurança (um testador de penetração ou um assessor de vulnerabilidade). Se um profissional de segurança não estiver disponível, você poderá executar o DAST por conta própria com um verificador de proxy web e algum treinamento. Conecte um scanner DAST no início para garantir que você não introduza problemas de segurança óbvios em seu código. Consulte o site OWASP para obter uma lista de scanners de vulnerabilidade do aplicativo Web.

Fazer teste de fuzzing

No teste de fuzz, você induz a falha do programa introduzindo deliberadamente dados malformados ou aleatórios em um aplicativo. Induzir falha no programa ajuda a revelar possíveis problemas de segurança antes que o aplicativo seja lançado.

A Detecção de Risco de Segurança é o serviço de teste de fuzz exclusivo da Microsoft para localizar bugs críticos de segurança no software.

Realizar revisão da superfície de ataque

Examinar a superfície de ataque após a conclusão do código ajuda a garantir que qualquer alteração de design ou implementação em um aplicativo ou sistema tenha sido considerada. Isso ajuda a garantir que todos os 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 Attack Surface Analyzer. Você pode escolher entre muitos serviços ou ferramentas de verificação de vulnerabilidades e testes dinâmicos comerciais, incluindo OWASP Attack Surface Detector, Arachni e w3af. Essas ferramentas de verificação rastreiam seu aplicativo e mapeiam as partes do aplicativo que são acessíveis pela Web. Você também pode pesquisar no Azure Marketplace ferramentas de desenvolvedor semelhantes.

Executar testes de penetração de segurança

Garantir que seu aplicativo esteja seguro é tão importante quanto testar qualquer outra funcionalidade. Torne o teste de penetração uma parte padrão do processo de build e implantação. Agende testes de segurança regulares e verificação de vulnerabilidades em aplicativos implantados e monitore portas abertas, pontos de extremidade e ataques.

Executar testes de verificação de segurança

A AzTS (Solução de Segurança do Locatário do Azure) do AzSK (Secure DevOps Kit para Azure) contém SVTs para vários serviços da plataforma Azure. Execute esses 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 CI/CD (integração contínua/implantação contínua) do AzSK, que disponibiliza SVTs como uma extensão do Visual Studio.

Próximas Etapas 

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

  • Last updated on