Desenvolver aplicativos seguros no Azure

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

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

  • Implementação
  • Verificação

Implementação

O foco da fase de implementação é estabelecer as práticas recomendadas para prevenção antecipada, detecção e remoção problemas de segurança do código. Imagine que seu aplicativo é usado de maneiras que você não pretendia. Isso ajuda você a se proteger contra o uso indevido acidental ou intencional do aplicativo.

Executar revisões de código

Antes de fazer verificar o código, faça revisões de código para aumentar sua qualidade geral 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 em códigos não executados. A análise de código estático usa técnicas como verificação de contaminação e análise de fluxo de dados.

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

Validar e limpar todas as entradas do aplicativo

Trate todas as entradas como não confiáveis para proteger seu aplicativo das vulnerabilidades mais comuns de aplicativos Web. Os dados não confiáveis são um veículo para ataques de injeção. A entrada para o seu aplicativo inclui parâmetros na URL, entradas do usuário, dados do banco de dados ou de uma API e tudo o que for transmitido que um usuário possa manipular. Um aplicativo deve validar que os dados estão sintática e semanticamente válidos antes de usar os dados de alguma forma (incluindo exibi-los ao usuário).

Valide a entrada no início do fluxo de dados para ter certeza de que apenas os dados formados corretamente entrarão no fluxo de trabalho. Você não quer que dados malformados persistam em seu banco de dados ou criem um problema em um componente downstream.

As listas de bloqueados e de permitidos são duas abordagens gerais para executar a validação da sintaxe de entrada:

  • Tentativas da lista de bloqueados de verificar se determinada entrada do usuário não apresenta conteúdo "conhecido como 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 permitidos baseada em caracteres é uma forma de lista de permitidos em que um aplicativo verifica se a entrada do usuário contém apenas caracteres "corretos" ou se 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 contém exatamente dois números.

A lista de permitidos é a abordagem preferida para a criação de software seguro. A lista de bloqueados está propensa a erros, pois é impossível pensar em uma lista completa de entradas potencialmente inadequadas.

Faça isso 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 os 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, oferece defesas em camadas para aumentar a segurança do sistema como um todo.

O escape garante que tudo seja exibido como saída. Ele também permite que o intérprete saiba que os dados não devem ser executados, e isso impede o sucesso dos ataques. Essa é outra técnica de ataque comum chamada XSS (Script entre sites).

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 poderia fazer com que o banco de dados fosse roubado, apagado ou modificado. Seu aplicativo também pode ser usado para executar comandos mal-intencionados no sistema operacional que hospeda seu banco de dados.

Use consultas parametrizadas ou procedimentos armazenados. Ao usar consultas parametrizadas, você poderá invocar o procedimento de seu código com segurança e transmiti-lo a uma cadeia de caracteres sem se preocupar com 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. Confira Removendo cabeçalhos de servidor padrão nos sites do Azure.

Separar os dados de produção

Seus dados de produção, ou dados "reais", não devem ser usados para desenvolvimento, teste ou outra finalidade além da pretendida pela empresa. Um conjunto de dados mascarado (anonimizado) deve ser usado em todo o desenvolvimento e teste.

Isso significa que menos pessoas têm acesso aos dados reais, o que reduz a 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 ataques de força bruta e adivinhação baseada em dicionário, você precisará implementar uma política de senha forte para fazer com que os usuários criem uma senha complexa (por exemplo, tamanho mínimo de 12 caracteres e exigência de caracteres alfanuméricos e especiais).

O Azure Active Directory B2C ajuda no gerenciamento de senhas com a oferta de redefinição de senha self-service, redefinição de senha forçada e muito mais.

Para se proteger contra ataques em contas padrão, verifique se todas as chaves e senhas são substituíveis e se são geradas ou substituídas depois que você instala recursos.

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

Validar uploads de arquivos

Se seu aplicativo permitir uploads de arquivos, considere as precauções que você pode tomar nessa atividade arriscada. A primeira etapa em muitos ataques é inserir código mal-intencionado em um sistema que está sob ataque. O uso de um upload de arquivo ajuda o invasor a realizar a primeira etapa. O OWASP oferece soluções para validar um arquivo e garantir a segurança do que você está carregando.

A proteção antimalware ajuda a identificar e remover vírus, spyware e outros softwares mal-intencionados. Você pode instalar o Microsoft Antimalware ou uma solução de proteção de pontos de extremidade do 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 de mecanismo, relatórios de exemplos e coleção de eventos de exclusão. Você pode integrar o Microsoft Antimalware e as soluções de parceiros com o Microsoft Defender para Nuvem para facilidade de implantação e detecções internas (alertas e incidentes).

Não armazenar conteúdo confidencial em cache

Não armazenar conteúdo confidencial no navegador. Os navegadores podem armazenar informações em seus caches e históricos. Os arquivos armazenados em cache são salvos em uma pasta, como a pasta Arquivos de Internet Temporários no caso do Internet Explorer. Quando essas páginas são consultadas novamente, o navegador as exibe por meio do cache. Se informações confidenciais (endereço, detalhes do cartão de crédito, número do seguro social, nome de usuário) forem exibidas para o usuário, elas poderão ser armazenadas no cache do navegador e ser recuperadas examinando o cache do navegador ou pressionando o botão Voltar do navegador.

Verificação

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

Localizar e corrigir vulnerabilidades em suas dependências de aplicativo

Você examina seu aplicativo e as bibliotecas dependentes para identificar os componentes vulneráveis conhecidos. Os produtos que estão disponíveis para realizar essa verificação incluem Verificação de Dependência do OWASP, Snyk e Black Duck.

Testar o aplicativo em um estado operacional

O DAST (teste de segurança do aplicativo dinâmico) é 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 inseguro, script entre sites, problemas de privilégio de usuário, injeção de SQL e outras preocupações de segurança críticas.

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

Faça o DAST preferencialmente com a assistência de um profissional de segurança (um testador de penetração ou avaliador de vulnerabilidade). Se um profissional de segurança não estiver disponível, você poderá fazer o DAST por conta própria com um scanner de proxy da Web e algum treinamento. Conecte um scanner DAST logo no início para não introduzir problemas de segurança óbvios em seu código. Consulte o site OWASP para obter uma lista de scanners de vulnerabilidade de aplicativos Web.

Fazer teste de fuzzing

No teste de fuzzing, você induz a falha do programa com a apresentação deliberada de dados incorretos ou aleatórios a um aplicativo. A indução em falha do programa ajuda a revelar possíveis problemas de segurança antes do lançamento do aplicativo.

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

Fazer o exame da superfície de ataque

O exame da superfície de ataque após a conclusão do código ajuda a garantir que todas as alterações no design ou na implementação em um aplicativo ou sistema tenham sido consideradas. Ele ajuda a garantir que todos os novos vetores de ataque criados como resultado das alterações, incluindo modelos de ameaça, tenham sido examinados e atenuados.

Você pode criar uma imagem da superfície de ataque examinando o aplicativo. A Microsoft oferece uma ferramenta de análise da superfície de ataque chamada Analisador de Superfície de Ataque. Você pode escolher entre vários serviços ou ferramentas de teste dinâmico e exame de vulnerabilidade, incluindo o Detector de Superfície de Ataque OWASP, o Arachni e o w3af. Essas ferramentas de verificação rastreiam seu aplicativo e mapeiam as partes do aplicativo que podem ser acessadas pela Web. Você também pode pesquisar ferramentas de desenvolvedor semelhantes no Azure Marketplace.

Executar teste de penetração de segurança

Verificar se seu aplicativo é seguro é tão importante quanto testar qualquer outra funcionalidade. Torne os testes de penetração uma parte padrão do processo de build e de implantação. Agende testes de segurança e verificações de vulnerabilidade regulares em aplicativos implantados e monitore em busca de ataques e de portas e pontos de extremidade abertos.

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 ter certeza de que sua assinatura do Azure e os diferentes recursos que compõem seu aplicativo estão 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 torna o SVTs disponível como extensão do Visual Studio.

Próximas etapas

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