Se você já implementou o Grafana Cloud em uma organização de engenharia em crescimento, este padrão pode parecer familiar: tudo começa de forma simples. Você convida alguns colegas, concede acesso e os dashboards começam a surgir. Então, o time cresce. O número de stacks também.
Com o tempo, um modelo que antes parecia ágil e empoderador começa a soar arriscado, difícil de entender e ainda mais difícil de reverter. Este artigo foca em como evitar esse ponto de ruptura.
Anteriormente, discutimos o modelo de stack única, onde times e pastas do Grafana gerenciam o multi-tenancy. Esse modelo escala bem operacionalmente, mas apenas se a sua abordagem de identidade e acesso acompanhar o ritmo. Para empresas brasileiras que buscam eficiência operacional, a pergunta central é: Como fornecer acesso rápido e automatizado aos engenheiros sem transformar toda a conta do Grafana Cloud em uma superfície administrativa compartilhada?
A resposta não está em mais atribuições manuais ou processos burocráticos, mas em um modelo de identidade em camadas, utilizando o SCIM como o mecanismo de viabilização em escala.
O ponto de partida: acesso padrão do Grafana Cloud
A maioria dos times começa com o modelo de acesso padrão. Os usuários são adicionados diretamente no portal do Grafana Cloud e recebem um role (perfil) organizacional, como admin, editor ou viewer. Esse role é herdado automaticamente como um basic role por todas as stacks da conta.
A autenticação é intencionalmente simples, via usuário/senha ou social login (Google/GitHub). Para times pequenos, essa agilidade é uma vantagem, permitindo produtividade imediata.
No entanto, esse modelo assume que qualquer pessoa que precise acessar o Grafana também deve ter visibilidade e permissões em toda a conta. À medida que o uso cresce, essa premissa torna-se indefensável. O acesso universal dificulta auditorias, governança e revogação de acessos. A solução é separar onde o Grafana é administrado de onde ele é efetivamente utilizado.
Este diagrama mostra o modelo de acesso padrão do Grafana Cloud, onde a superfície de acesso compartilhada torna-se difícil de gerenciar conforme times e stacks proliferam.
Por que o SCIM é vital para operação em escala
Para organizações que utilizam Okta ou Entra ID (antigo Azure AD), o provisionamento via SCIM é o que torna o modelo de identidade em camadas prático. Em vez de criar times manualmente, o SCIM permite que seu Identity Provider (IdP) envie usuários e times para o Grafana de forma automatizada. O seu IdP torna-se o "sistema de registro" (system of record).
O SCIM também viabiliza o deprovisioning imediato. Quando um usuário é desligado ou desativado no IdP, seu acesso à stack do Grafana é removido em tempo real, reduzindo drasticamente riscos de segurança com contas inativas ou gaps no offboarding.
Além disso, o SCIM garante o "day-zero readiness": novos engenheiros já encontram seus dashboards e permissões prontos ao logar pela primeira vez. Com a disponibilidade geral do SCIM para stacks do Grafana Cloud, essa abordagem é acessível muito antes de o caos operacional se instalar.
Nota de segurança: O SCIM utiliza credenciais (tokens ou service accounts). Trate-as como segredos críticos: armazene em um vault (como HashiCorp Vault ou AWS Secrets Manager), rotacione regularmente e monitore anomalias no provisionamento.
Camada 1: O portal Grafana Cloud como cofre administrativo
O portal do Grafana Cloud atua como o control plane da sua conta, governando faturamento, criação de stacks e configurações críticas. Por representar todo o seu footprint de observabilidade, ele deve ser tratado como um espaço administrativo restrito.
Na prática, o acesso ao portal deve ser limitado a um pequeno grupo de administradores de plataforma ou observabilidade. A maioria dos engenheiros não precisa logar em grafana.com. Manter esse grupo reduzido diminui o blast radius (raio de exposição) de erros e simplifica auditorias de compliance.
É recomendável gerenciar esse acesso de forma declarativa (via Terraform) e manter uma conta de "break glass" (acesso de emergência) segura e fora do SSO, para garantir o acesso caso o provevador de identidade fique indisponível.
Camada 2: A stack do Grafana como espaço de trabalho automatizado
A stack do Grafana é onde os times de engenharia residem. É aqui que exploram dashboards, investigam alertas e gerenciam incidentes. Nesta camada, a prioridade muda do controle estrito para a automação previsível.
Em ambientes com maior rigor de segurança, os engenheiros devem autenticar-se diretamente na URL da stack (ex: sua-empresa.grafana.net). O SSO em nível de stack reduz o risco de o portal administrativo se tornar um caminho de acesso não pretendido a dados de produção.
Este diagrama ilustra o modelo em camadas: acesso administrativo restrito ao portal e acesso direto dos engenheiros às stacks via IdP, com SCIM sincronizando usuários e times automaticamente.
Conclusão e monitoramento
Automatizar a governança de acesso não apenas libera o time de tarefas repetitivas (FinOps/DevOps), mas fecha brechas críticas de SecOps. Uma vez que o SCIM esteja operando, recomendamos configurar alertas para logs de provisionamento para identificar:
- Picos inesperados na criação de usuários.
- Exclusões em massa não planejadas.
- Alterações em times/grupos sensíveis.
Essa separação entre governança centralizada no IdP e execução na stack é o blueprint ideal para empresas que precisam escalar sem perder o controle.
Artigo originalmente publicado por Sarah Constant em Grafana Labs blog on Grafana Labs.
