RBAC: o começo de uma nova era para a GoCache
Depois de alguns meses de dedicação da equipe, temos orgulho em anunciar o lançamento de nosso painel multiusuário com gerenciamento de acesso via RBAC (Role Based Access Control). Pode parecer algo pouco significativo, mas o contexto e as premissas usadas no desenvolvimento são um marco para a evolução do posicionamento da GoCache.
TL:DR
- O multiusuário e o RBAC são os primeiros passos de uma evolução do posicionamento da GoCache
- O foco de nosso trabalho são empresas de tecnologia em crescimento, em processo de amadurecimento de suas práticas em DevOps e SRE, apoiadas ou não por MSPs e consultorias
- Buscamos um modelo que pudesse ser flexível e versátil, mas sem complicar a vida de quem gerencia os controles de acesso
Novo posicionamento
Tem sido nítida a mudança no mercado de tecnologia nos últimos anos. Aplicações web e mobile têm cada vez mais protagonismo na estratégia de entrega de valor de empresas de diferentes verticais. Isso tem pressionado bastante os limites aceitáveis de performance, disponibilidade e, principalmente, segurança dessas aplicações. Por sua vez, novas práticas de desenvolvimento e operação vem emergindo para suportar este aumento de escala demandado, sem sair dos limites de qualidade aceitáveis mencionados anteriormente.
Porém, essas mudanças organizacionais não costumam vir sem um preço. Conceitos emergentes como microsserviços costumam não ser tão compatíveis com aplicações mais legadas, ou até mesmo com aplicações de empresas mais novas, mas que acabaram de encontrar seu fit com o mercado, uma vez que sua missão recente era provar valor e ainda era muito cedo para gastar recursos com preparação para escala.
É nessa hora que hora que a organização é posta em cheque. A implantação de mudanças de arquitetura, de processos e culturais, que elevariam a produtividade, concorrem com os mesmos recursos empregados nas antigas rotinas mais onerosas, em um ambiente com mais pressão por entregas e com uma expansão de equipe demorada e trabalhosa. Mesmo com a importante ajuda de MSPs e consultorias auxiliando na modernização da plataforma, o período de instabilidade demora meses, gerando mais riscos para a resiliência e principalmente, para a segurança das aplicações.
Por isso, a GoCache resolveu entrar também nessa batalha. Já estava no DNA usar nossa tecnologia para resolver problemas mais amplos de nossos clientes, como por exemplo, elaborar estratégias de cache dinâmico para reduzir o consumo do servidor de origem dos mesmos. Ampliaremos nossa capacidade de solução de problemas de resiliência e segurança para além do proporcionado por CDN/WAF, mas, especialmente dentro de um contexto: empresas digitais com pressões por escala, reestruturando suas equipes e processos. Nesse momento, o gerenciamento de infra e segurança da aplicação precisa ser compartilhado entre diferentes pessoas, times e até mesmo com outras organizações, como MSPs e consultorias. É aí que o multiusuário e o RBAC tornam-se um passo importante.
Por que RBAC
Tendo em vista segurança em primeiro lugar, é fundamental seguir o princípio do menor privilégio em uma ferramenta de infraestrutura e segurança gerida por pessoas em diferentes papéis. Dessa forma, o modelo de controle de acesso baseado em papéis (Role-based Access Control ou RBAC) veio de forma natural.
Alguém pode estar se perguntando por que não usar um modelo mais simples, como por exemplo, definir as permissões individualmente para cada usuário (conhecido tecnicamente como DAC ou Discretionary Access Control). O que parece mais simples quando você tem poucos usuários pode se tornar um inferno à medida que sua equipe cresce, e ainda pode piorar ambientes dinâmicos e/ou com rotatividade, como costuma ser o caso de empresas ganhando escala. A cada nova pessoa, você teria que definir cada permissão que ela pode ter. A cada mudança de posição dela, você precisaria rever cada um desses itens. A cada revisão de políticas de acesso da empresa, você teria que mapear cada usuário afetado e fazer a correção um por um.
Por outro lado, existem modelos mais flexíveis e modernos, como o ABAC (Attribute-based Access Control), em que as políticas de acesso são implementadas de acordo com atributos do usuário, dos recursos e do contexto. O problema desta abordagem, é que traria uma complexidade desnecessária em toda a experiência de uso da GoCache, uma vez que o administrador seria obrigado a definir atributos para cada usuário, como cargo e squad, e também dos recursos, como por exemplo, qual squad é dono do recurso. E também teria que desenvolver um processo para garantir que essas informações estivessem sempre corretamente atualizadas. Desenvolvemos o controle de acesso no formato RBAC, mas buscando trazer o melhor compromisso entre simplicidade e flexibilidade em seu design, como mostraremos a seguir.
Como o RBAC da GoCache se diferencia de outras CDNs?
Poderíamos adotar uma abordagem mais minimalista como a da Cloudflare, em que os papéis já são pré-definidos em agrupamentos genéricos de privilégios para todos os domínios da conta, como “Somente Leitura”, “Analytics” e “Cache Purge”. Mas logo na fase de pesquisa, percebemos que as políticas de acesso para cada papel podem variar muito de empresa para empresa. Ex.: em algumas empresas o suporte pode fazer limpeza de cache, em outras não. Em outras, um analista jr de segurança pode apenas gerenciar os IPs bloqueados pelo Firewall, mas não pode desativar o WAF. Daí podem derivar dois problemas: o privilégio de um papel pode ser permissivo demais e a cada novo usuário, ou mudança na organização, o administrador precisaria fazer match entre as políticas de sua empresa e quais papéis predefinidos ele deveria escolher para um usuário.
Outro problema, é o acesso a todos os domínios da conta. Temos clientes, como MSPs e consultorias de ecommerce, que fazem o gerenciamento da GoCache para seus clientes. E uma das demandas que aparecem com certa frequência, é a necessidade de compartilhar alguns recursos para seus clientes, como limpeza de cache, mas sem o mesmo ter acesso a todos os domínios dos outros clientes. Uma outra necessidade que pode surgir está relacionada a empresas que se compõe de múltiplos squads. O uso da GoCache como um gateway de entrada da aplicação, a partir das smart rules, em que são criadas regras de roteamento para diferentes serviços de acordo com o padrão de URL, vem se tornando mais comum. E uma tendência atual, é que a gestão de cada serviço seja delegada ao seu respectivo squad, portanto, a configuração de um squad não pode conflitar com o squad vizinho.
A Fastly tem uma abordagem para contornar esse problema, mas ainda tem suas limitações. Nela, cada usuário deve ter um papel e apenas um. Todos dão acesso a todas as propriedades da conta, com exceção de apenas um, o “Engineer”. Quando você configura este papel, você define em quais serviços o usuário pode limpar cache e/ou visualizar as configurações, ou fazer tudo. Além de faltar granularidade, essa configuração trabalhosa tem que ser feita em cada usuário com papel de engineer, mesmo que exista mais de um com o mesmo tipo de papel na empresa. Buscamos uma abordagem mais granular, mas procurando combater a complexidade por meio de duas características, como você verá a seguir: reuso e contexto de negócio.
Como funciona o RBAC da GoCache?
O painel multiusuário e controle de acesso RBAC da GoCache é dividido em 4 elementos: Usuários, Grupos de Usuários, Listas de Domínios e Modelos de Permissões. O grupo de usuários basicamente tem a mesma função dos “Papéis” no modelo RBAC. O que diferencia o modelo da GoCache é que ao definir um papel, no caso, um grupo de usuários, você já define o escopo onde um conjunto de privilégios será aplicado, sendo o escopo uma lista dos domínios em que você quer dar algum privilégio, e o conjunto de privilégios em si, é definido no que chamamos modelo de permissões. Abaixo, você pode ver um diagrama para entender melhor como funciona.
Diagrama do funcionamento do RBAC da GoCache
Exemplo da implementação de um grupo de usuários
Como o próprio nome diz, a granularidade mínima do escopo é por domínio. Optamos por isso em um primeiro momento, para evitar problemas de usabilidade, principalmente por haver configurações que podem afetar um domínio inteiro e gerar conflitos de interpretação. Mas estamos pesquisando formas de permitir mais granularidade, portanto, se for algo que faça sentido para sua empresa, entre em contato conosco, pois seu feedback pode ser importante para criarmos uma experiência incrível na resolução deste problema.
No modelo de permissões, você pode definir as ações (criar, atualizar, excluir, ler e ordenar) pertinentes em cada recurso de nosso painel/API. Por exemplo: você pode criar um modelo em que o usuário pode apenas atualizar entradas de DNS existentes, mas não pode criar ou excluir. Em um primeiro momento, pode parecer complexo, mas a intenção é que você configure isso apenas uma vez e possa reusá-lo em diferentes grupos de usuários. Além disso, trazer modelos já prontos de casos de uso comuns, como Todas as Permissões, Apenas Leitura, Apenas Limpeza de Cache e Permissões para Financeiro.
Exemplo de um modelo de Permissões.
Exemplo de Uso
Suponha que sua empresa seja uma plataforma de e-commerce com milhares de clientes. Ela acabou de se fundir com outra plataforma, e, por causa disso, metade dos domínios apontam para uma aplicação, metade para outra, sendo cada uma gerida por times diferentes. Os domínios de sua própria empresa também estão presentes na mesma conta, sendo alguns usados para o site institucional e landing pages, geridos pela equipe de marketing, e outros para abrigar seus painéis de controle, geridos por outros times específicos. Uma empresa desse perfil provavelmente ainda teria outros papéis, mas vamos parar por aqui para não ficar extenso. Como ficaria a configuração?
Podemos primeiro, criar os grupos de usuários “Time Aplicação A” e “Time Aplicação B”. De acordo com as políticas de sua empresa, esses times têm permissão somente para configurar Smart Rules, Cache e ver Analytics, apenas dos domínios das aplicações que eles gerem. O primeiro passo é criar um modelo de permissões com o nome “Times de aplicações” e ativar os privilégios que condizem com essa política, dentro desse modelo. Depois, você agrupa os domínios de cada aplicação nas listas “Aplicação A” e “Aplicação B”. São milhares de domínios? Não tem problema! Você pode gerir essas listas de domínios, assim como todos os recursos do multiusuário e RBAC, via API, podendo integrar com seus pipelines de automação, assim, sempre que um domínio de seus novos clientes entrar na GoCache, você já atualiza ele em sua devida lista de domínios. Por fim, é só vincular a lista de domínios “Aplicação A” e o modelo de permissões “Times de aplicações” no grupo de domínios “Time Aplicação A”, e fazer o mesmo de forma análoga com o time B.
Para dar privilégio ao time de marketing, o processo é o mesmo. Vamos supor que o marketing pode fazer exatamente o mesmo que os times de aplicação, mas apenas nos domínios da empresa. Você reaproveita o modelo de permissões já criado “Times de aplicações”, cria a lista de domínios “Marketing”, contendo apenas os domínios da empresa voltados a marketing, e vincula ambos ao grupo de usuários “Marketing”. Agora sobraram apenas os times responsáveis pelos dashboards. Se sua política for a mesma que a dos times de desenvolvimento, mas com a adição de gestão de DNS, você pode copiar o modelo de permissões times de desenvolvimento, adicionar as opções de DNS e renomeá-lo como “Times de dashboards”. Em seguida, você cria as listas de domínios de cada dashboard, e as vincula junto com o modelo de permissões aos seus respectivos grupos de usuários. Por último, você adiciona cada usuário ao seu respectivo grupo de usuários.
Visão final do exemplo de uso do RBAC
Esse é apenas o começo
Nossos clientes evoluíram, e estamos evoluindo junto para apoiá-los ainda mais neste momento difícil, mas recompensador. O multiusuário e RBAC são passos importantes para suportar essa evolução organizacional, mas apenas a base do que está por vir. O que estiver ao nosso alcance em termos de tratamento de tráfego web para trazer muito mais resiliência e segurança para aplicações, faremos, mas sempre de olho abordagem mais descomplicada que conseguirmos.
