5 práticas recomendadas para criar um controle de acesso moderno para aplicações em nuvem

Recentemente, conversei com Or Weis — embaixador da Snyk — sobre controle de acesso na nuvem. Or é empreendedor e mora em Tel Aviv, onde fundou a Permit.io, uma solução que permite aos desenvolvedores incorporar permissões e controles de acesso a qualquer produto em minutos, sem o trabalho de recriá-los constantemente.

Na conversa, abordamos vários assuntos, como:

• Por que é tão importante usar sempre controles de acesso modernos na nuvem

• Por que RBAC não é suficiente

• Segurança e conformidade

• As diferentes camadas de controle de acesso na nuvem

• O efeito cascata do IAM

• Como reduzir a superfície de ataque ao criar controles de acesso

Além disso, também conversamos sobre práticas recomendadas de controle de acesso que você pode começar a aplicar às suas aplicações em nuvem. Neste artigo, vamos recapitular essas práticas com informações diretamente da conversa completa. Para conhecê-las em mais detalhes, recomendo assistir à discussão na íntegra:

Play Video: Building Modern Access-Control for Cloud Applications with Or Weis | SnykLIVE Recording

5 práticas recomendadas para controles de acesso modernos na nuvem

Seja para criar o controle de acesso por conta própria, com código aberto ou usando ferramentas proprietárias, estas cinco práticas recomendadas ajudam a garantir que sua solução seja preparada para o futuro, confiável e ofereça proteções para estabilizar e proteger seu sistema.

1. Desacople o código das políticas

2. Projete para atualizações orientadas a eventos (desacople os dados do código)

3. Crie um back office para as partes interessadas

4. Crie uma interface para os clientes

5. Implemente GitOps

1. Desacople o código das políticas

A primeira prática recomendada, e provavelmente a mais importante, é desacoplar as políticas do código. É comum vermos pessoas incorporando a lógica de autorização à própria lógica da aplicação. No fim das contas, isso resulta em código espaguete, com condições “if” que consultam o banco de dados e outras fontes para verificar a lógica de autorização — e, ao mesmo tempo, também consultam a lógica da aplicação. Com o tempo, as duas acabam se misturando. Assim, à medida que os desenvolvedores adicionam novas condições, fica quase impossível entender quais partes da condição “if” tratam da autorização e quais pertencem à aplicação.

O resultado é que, quando você quiser atualizar a camada de autorização ou a própria aplicação, precisará verificar tudo linha por linha e refatorar — o que leva à dolorosa realidade da refatoração. Por isso, queremos desacoplar as políticas do código. Queremos adotar política como código (PaC) e gerenciar esse código separadamente, de preferência como um microsserviço independente que os outros componentes da aplicação possam consultar para obter a lógica necessária.

As perguntas naturais de quem está começando nessa área podem ser:

1. Quem controla o acesso a esse serviço?

2. O que vem primeiro: a autenticação ou a aplicação?

Para falar a verdade, esse é um universo complexo e altamente recursivo chamado autorização da autorização. Em resumo, você pode minimizar o controle de acesso da camada seguinte e, muitas vezes, limitá-lo exclusivamente à autenticação. Assim, quando seus microsserviços se conectam ao microsserviço de autorização, isso só é permitido se tiverem uma identidade verificada por esse microsserviço. As camadas tornam tudo mais complexo, mas a maioria das ferramentas tenta resolver esse problema para você ou, pelo menos, reduzir bastante o trabalho.

Vale lembrar que, idealmente, queremos criar um microsserviço separado para a autorização. Esse microsserviço não precisa ser perfeito. No início, pode ser tão simples quanto uma função que sempre retorna “true”. Embora não queiramos construir tudo desde o primeiro dia, precisamos deixar os pontos de integração preparados da maneira certa para poder aprimorá-los gradualmente quando surgirem novos requisitos. Seja uma função Lambda, um pequeno contêiner ou o que você preferir, ela precisa poder evoluir separadamente e ser refatorada com facilidade à medida que novos requisitos surgirem.

2. Projete para atualizações orientadas a eventos (desacople os dados do código)

A segunda prática recomendada é adotar uma abordagem orientada a eventos. Sistemas complexos têm políticas complexas, que mudam junto com a própria aplicação. Se você projetar sua aplicação para ser orientada a eventos desde o início, será mais fácil gerenciar atualizações futuras.

Veja um exemplo. Imagine uma política simples: somente usuários que pagaram por um recurso podem usá-lo. Essa informação já não fica no seu banco de dados nem faz parte da aplicação. Ela está em um serviço de terceiros, como Stripe, Chargebee ou PayPal. Por isso, precisamos propagar as informações desses serviços em tempo real, à medida que mudam, e fazer com que elas afetem nossa camada de autorização.

A melhor maneira de fazer isso é adotar uma abordagem orientada a eventos. Na prática, isso significa receber webhooks desses serviços ou componentes externos e propagá-los para nossa camada de autorização. Isso é chamado de “desacoplar os dados do código” e é tão importante quanto desacoplar as políticas do código.

3. Back office para as partes interessadas + 4. Interface para os clientes

Como sabemos que teremos clientes e outras partes interessadas (como gerentes de produto, empresas de segurança etc.), também sabemos que essas pessoas vão querer interfaces para gerenciar o controle de acesso. Não precisamos criá-las desde o primeiro dia, mas devemos estar preparados para desenvolver e disponibilizar essas interfaces quando os requisitos surgirem.

Queremos ter um back office onde as diferentes partes interessadas possam gerenciar a aplicação e interfaces para os próprios clientes, permitindo que convidem usuários, atribuam funções e até configurem políticas. Como a maioria dos engenheiros concorda, o melhor serviço é aquele que permite que o usuário se sirva sozinho.

5. Implemente GitOps

Por fim — e isso nos traz de volta à política como código —, simplifique a segurança com GitOps. Estamos falando de gerenciar regras e instruções complexas em um ambiente em constante mudança, com várias partes interessadas. A melhor maneira de fazer isso é por meio de código. Assim como adotamos infraestrutura como código e segurança como código, também devemos adotar política como código.

Se você gerenciar as políticas como código separado (de preferência em uma estrutura adequada para isso) em um repositório Git, poderá gerenciar com elegância versões, testes, benchmarks e revisões de código. Assim, você não precisa reinventar a roda para gerenciar as políticas e conectá-las ao seu sistema.

Mantenha-se sempre atualizado

Tenha estas cinco práticas recomendadas em mente ao começar a construir algo. Isso pode poupar meses de refatoração mais adiante, simplesmente por você saber que esses desafios vão surgir.

Por fim, agradeço muito a Or Weis por conversar comigo e compartilhar sua experiência sobre o assunto. Se tiver dúvidas sobre esse tema, recomendamos entrar em contato com Or Weis pelo Twitter ou LinkedIn, ou participar do Discord da comunidade DevSecCon e perguntar diretamente a ele.