Modelagem de ameaças no contexto de arquiteturas de microsserviço

9 min de leitura
Patrocinado
Imagem de: Modelagem de ameaças no contexto de arquiteturas de microsserviço
Avatar do autor

Equipe TecMundo

@tec_mundo

Por Anton McConville

Atualizado em 4 de agosto de 2020 | Publicado em 24 de abril de 2020

Se a privacidade e a segurança dos dados fossem recursos fáceis, instantâneos e imediatos que você pudesse incorporar aos aplicativos, então não haveria violações de dados ou invasão da privacidade destes dados.

A verdade é que não há uma única solução mágica para a segurança de sistemas de software. No entanto, existem blocos de construção sólidos e bons hábitos de segurança que podem fundamentalmente ajudar a mitigar ameaças.

Este artigo considera a privacidade e a segurança como parte do design ao longo da vida de um aplicativo modelo. Especificamente, descrevo o conceito de modelagem de ameaças e discuto o processo que minha equipe utilizou para incorporar medidas de segurança em um aplicativo móvel que chamamos de Banco Modelo.

Contexto

No início deste ano, minha equipe recebeu uma solicitação de recurso para um de nossos aplicativos móveis que exigiria o armazenamento de informações pessoais. No lançamento da primeira versão do nosso aplicativo, evitamos totalmente o armazenamento de informações pessoais para simplificar a responsabilidade acumulada no aplicativo. A fim de implementar uma solução para essa solicitação de recurso, precisamos entender o que realmente seria necessário para construir uma versão do aplicativo que lidasse bem com privacidade e segurança.

Em nosso aplicativo do Banco Modelo, o backend é totalmente baseado em cloud, sendo executado a partir de Kubernetes e serviços de bancos de dados no IBM Cloud.

Como muitos outros aplicativos, nosso aplicativo móvel teve início como um conceito simples, construído o mais rápido possível por uma pequena equipe montada às pressas; não há especialistas em segurança no time. Portanto, essa solicitação de recurso nos forçou a entender melhor a segurança nativa em cloud.

Na IBM, temos processos, pessoas e mecanismos em nossas construções para proteger dados confidenciais de maneiras mais controladas. Embora nossa equipe possa consultar todos esses recursos, eu queria entender como seria criar aplicativos nativos em cloud privados e seguros para uma startup.

No final do ano passado, participei de uma palestra muito interessante na KubeCon, na qual fui introduzido ao conceito de modelagem de ameaças e à útil metodologia STRIDE, um acrônimo e framework para a consideração de ameaças a um sistema.

Modelagem de ameaças com STRIDE

IBMMetodologia STRIDE

A modelagem de ameaças é um processo onde ameaças potenciais, vulnerabilidades ou a ausência de salvaguardas podem ser identificadas e enumeradas. Dessa maneira, as mitigações podem ser priorizadas.

O objetivo da modelagem de ameaças é fornecer aos defensores uma análise de quais controles ou defesas precisam ser incluídos, dada a natureza do sistema, o provável perfil do invasor, os vetores de ataque mais esperados e os ativos mais desejados por um agressor.

Recentemente, todos nós acumulamos experiência em primeira mão da modelagem de ameaças na vida real, conforme aprendemos a sobreviver em uma pandemia. Identificamos a ameaça de ser infectados, ou de superfícies que tocamos, ou a ameaça de infectar outras pessoas. Depois, pensamos em maneiras de barrar essas ameaças através de distanciamento social, lavando mais as mãos e usando máscaras. Cada interação que temos é considerada e medida para ameaças do vírus. Esse é um exemplo de modelagem de ameaças.

A modelagem de ameaças em sistemas de software é uma ideia semelhante. Seja a partir de um vírus digital ou de um ataque digital, precisamos considerar as ameaças e encontrar maneiras de proteger o sistema. A metodologia STRIDE ajuda nesse processo, destacando a consideração de seis áreas de ameaça. O diagrama que desenhei no início desta seção representa essa metodologia.

Vamos, então, analisar as ameaças à nossa arquitetura de software de aplicativo móvel.

Modelagem de ameaças para nosso exemplo de aplicativo nativo em cloud

Esta é a arquitetura de cloud básica para nosso aplicativo de cartão de crédito do Banco Modelo.

IBMExemplo de arquitetura de cloud

O aplicativo em execução usa HTTPS em um domínio que é direcionado aos microsserviços hospedados sendo executados no Red Hat® OpenShift® no IBM Cloud™. Uma pessoa pode criar uma conta (por meio do IBM App ID) utilizando um nome gerado para fins de teste. Então, quando uma pessoa clica no botão home do aplicativo, ela pode clicar nos vários ícones do aplicativo disponíveis para criar transações de cartão de crédito.

Nosso software em cloud para oferecer suporte ao recurso possui três microsserviços. Para obter mais detalhes, você pode ler sobre a arquitetura do aplicativo móvel.

Como exercício, considere os diferentes elementos do modelo de ameaças STRIDE para tal sistema e algumas ideias iniciais para impedir ameaças. Esta não é uma lista compreensiva, apenas um conjunto de opções que identificamos para nosso caso de uso.

Spoofing

No contexto da segurança da informação (e especialmente da segurança de rede), um ataque de spoofing é quando uma pessoa ou programa falsifica dados para obter uma vantagem ilegítima, efetivamente identificando-se como outra pessoa ou programa.

Considere as seguintes ideias para impedir esses tipos de ameaças:

  • Disponibilize o aplicativo móvel através de fontes confiáveis como a App Store da Apple, Google Play Store ou um domínio seguro reconhecível (consulte o IBM Domain Name Services);

  • Utilize protocolos de autenticação padronizados do mercado, como por exemplo o IBM Cloud App ID;

  • Utilize um provedor de cloud com o mais alto nível de certificação governamental (consulte o IBM Cloud Security).

Adulteração

Adulteração refere-se a muitas formas de sabotagem, mas o termo geralmente significa modificação intencional de produtos de forma a torná-los prejudiciais ao consumidor.

Considere as seguintes ideias para impedir esses tipos de ameaças:

  • Construa com plataformas de contêiner de criptografia compatíveis com o Federal Information Processing Standard (FIPS), como Red Hat OpenShift 4.3;

  • Faça a varredura do código em busca de vulnerabilidades, com, por exemplo, o IBM AppScan.

Repúdio

Em segurança da informação, não repúdio significa um serviço que fornece prova da integridade e origem dos dados ou uma autenticação confirmada como genuína com alto nível de confiança.

Considere as seguintes ideias para impedir esses tipos de ameaças:

Divulgação de informação

A divulgação de informações é a disseminação indesejada de tecnologia de dados ou privacidade. Existem questões legais e políticas a serem consideradas. A divulgação de informações é uma violação da privacidade ou proteção de dados. O desafio da privacidade de dados é usar dados e, ao mesmo tempo, proteger as preferências de privacidade dos indivíduos e suas informações de identificação pessoal.

Considere as seguintes ideias para impedir esses tipos de ameaças:

Negação de serviço

Um ataque de negação de serviço (às vezes chamado de DoS Attack) é um ataque cibernético no qual o perpetrador tem o objetivo de tornar uma máquina ou recurso de rede indisponível para seus usuários pretendidos, interrompendo temporariamente ou indefinidamente os serviços de um host conectado à Internet.

Considere as seguintes ideias para impedir esses tipos de ameaças:

  • Utilize ferramentas confiáveis de hospedagem em clouds públicas, por exemplo, em nosso caso: IBM Cloud Internet Services;

  • Considere a limitação de taxa.

Elevação de privilégios

O escalonamento de privilégios é o ato de explorar um bug, falha de design ou lacuna na configuração em um sistema operacional ou aplicativo de software para obter acesso elevado a recursos que normalmente são protegidos de um aplicativo ou usuário.

Há muitas camadas nas quais pensar quanto a privilégio: gerenciamento de bases de dados, gerenciamento de endpoint e gerenciamento de contêiner, havendo muitas abordagens para gerenciar essas camadas. Considere maneiras de combater ameaças nas seguintes camadas de privilégio:

Este artigo e a lista apresentada não pretendem ser um guia definitivo para proteger seu aplicativo. A intenção é oferecer um exemplo de como funciona a modelagem de ameaças e algumas das soluções que podem ajudar a impedir ameaças.

GDPR e privacidade desde a concepção

A General data Protection Regulation (GDPR) – em português, Regulamento Geral sobre a Proteção de Dados (GDPR) ­– é uma regulamentação da União Europeia que ajuda as pessoas a obter controle sobre a forma como as empresas utilizam seus dados pessoais. Foi implementada em 28 de maio de 2018 e sua violação pode resultar em uma multa de 4% da receita anual da sua empresa, ou €20 milhões, prevalecendo a quantia mais elevada entre os dois.

IBMA GDPR

Os dados não podem ser protegidos a menos que sejam seguros. É por isso que a GDPR está relacionada à segurança quando você projeta pensando em privacidade. Além das implicações financeiras da GDPR, as violações de dados podem deixar seres humanos de carne e osso vulneráveis às implicações do mundo real.

*Saiba mais sobre a GDPR neste guia do desenvolvedor para a GDPR.*

Para citar o texto GDPR Privacy By Design:

O termo “Privacidade desde a concepção” significa nada mais do que “proteção de dados através do design de tecnologia”. Por trás disso está a ideia de que a proteção de dados em procedimentos de processamento de dados é mais bem cumprida quando já está integrada na tecnologia quando criada.

Eu gosto bastante da ideia de dar um passo para trás ao projetar um aplicativo e tentar modelar não apenas as ameaças de segurança a um sistema de software, mas as ameaças apresentadas pelo abuso de dados pessoais de uma pessoa dentro do sistema.

Em nosso aplicativo do Banco Modelo, criamos algumas UIs exploratórias para mostrar alguns conceitos de privacidade em ação.

IBMBanco Modelo 1

É um aplicativo móvel simulado para um banco fictício. Você pode entrar no aplicativo e simular transações com cartão de crédito.

IBMBanco Modelo 2

Quando os usuários criam uma conta, eles marcam uma caixa de seleção para sinalizar seu consentimento.

IBMBanco Modelo 3

Na visualização da conta, os usuários podem excluir dados, o que torna os dados de rastreamento anônimos, permitindo que sejam utilizados para análises, mas não conectados a nenhum usuário específico.

Há outros aspectos que queríamos deixar claros em nossa UI, por exemplo, Right to Restriction of Processing e Automated Individual Decision Making/Profile.

Ao criar seu aplicativo, é importante projetar as APIs e controles para todos esses aspectos do gerenciamento de dados. Você pode ver como criamos essas APIs para o aplicativo do Banco Modelo.

Resumo

Este artigo apresentou privacidade e segurança como considerações de design ao longo da vida de um aplicativo modelo. Esperamos que agora você tenha uma visão de como funciona a modelagem de ameaças e as diferentes maneiras de usar o modelo de ameaças STRIDE para criar aplicativos seguros. Veja como colocamos esses conceitos em prática no no seguinte padrão de código: Focus on data privacy with a back end for a mobile bank app.

Próximos passos

Utilize o código-fonte aberto e as instruções no conteúdo a seguir para entender as etapas que seguimos para construir o aplicativo seguro do Banco Modelo em cloud com OpenShift 4.3:

...

Quer ler mais conteúdo especializado de programação? Conheça o IBM Blue Profile e tenha acesso a matérias exclusivas, novas jornadas de conhecimento e testes personalizados. Confira agora mesmo, consiga as badges e dê um upgrade na sua carreira!

…..

Quer dar o próximo grande passo na sua jornada profissional? Participe do Cloud Training, um curso online e gratuito que vai te preparar para o exame da certificação IBM Cloud Foundations. Inscreva-se já!

Modelagem de ameaças no contexto de arquiteturas de microsserviço