O que é RBAC?

RBAC (Role-Based Access Control) é um modelo de controle de acesso baseado em funções que é usado para gerenciar permissões de usuários em um sistema. Esse modelo é usado para garantir que usuários tenham acesso apenas às informações e recursos que são relevantes para suas funções ou responsabilidades.

No RBAC, as funções são definidas com base nas tarefas e responsabilidades de um usuário ou grupo de usuários em um sistema. Cada função tem um conjunto de permissões que determina quais ações um usuário pode realizar em relação a um recurso específico. Por exemplo, um usuário pode ser atribuído à função de administrador e ter permissão para criar e excluir contas de usuário, enquanto outro usuário pode ser atribuído à função de usuário padrão e ter permissão apenas para visualizar informações.

Esse modelo de controle de acesso é amplamente utilizado em sistemas de informação, como bancos de dados, aplicativos de gerenciamento de conteúdo e sistemas operacionais, entre outros. Ele ajuda a garantir a segurança do sistema e a proteger informações confidenciais, garantindo que apenas usuários autorizados possam acessar recursos específicos.

Algumas funções comuns no modelo RBAC incluem:

1. Administrador: Essa função geralmente tem acesso total ao sistema e permissões para realizar todas as atividades, incluindo a criação, modificação e exclusão de outros usuários e funções.
2. Gerente: Essa função geralmente tem acesso limitado e permissões para gerenciar recursos e usuários em uma determinada área ou departamento.
3. Funcionário: Essa função é comumente atribuída aos usuários regulares que precisam acessar recursos específicos para realizar suas tarefas diárias, como ler e editar documentos ou visualizar informações do cliente.
4. Convidado: Essa função é normalmente usada para usuários externos, como visitantes ou clientes, que têm permissões limitadas para acessar apenas algumas informações ou recursos específicos.
5. Auditor: Essa função é normalmente atribuída a usuários que precisam monitorar e auditar atividades em um sistema, mas não têm permissão para fazer mudanças ou alterar dados.

Essas são apenas algumas das funções comuns no modelo RBAC. As funções exatas e as permissões associadas a elas podem variar de acordo com as necessidades específicas do sistema e as políticas de segurança da organização.

Exemplo de configuração adequada do RBAC

Um exemplo de configuração adequada do modelo RBAC seria uma empresa de varejo que usa um sistema de gerenciamento de estoque. Nesse caso, a configuração RBAC poderia incluir as seguintes funções e permissões:

1. Administrador: Esta função teria acesso completo ao sistema, incluindo a capacidade de criar, modificar e excluir contas de usuário, além de ter acesso a todas as funcionalidades do sistema.
2. Gerente de estoque: Essa função teria permissão para gerenciar os níveis de estoque e fazer pedidos de reposição, além de criar e gerenciar contas de usuários para a equipe do depósito.
3. Equipe do depósito: Esta função teria acesso a informações de estoque relevantes para suas tarefas diárias, como receber e processar pedidos de reposição, atualizar níveis de estoque e gerar relatórios.
4. Gerente de vendas: Essa função teria permissão para gerenciar o inventário disponível nas lojas, além de criar e gerenciar contas de usuário para a equipe de vendas.
5. Equipe de vendas: Esta função teria acesso a informações de estoque relevantes para suas tarefas diárias, como verificar a disponibilidade de produtos para clientes e fazer pedidos de reposição específicos.
   
6. Auditor: Esta função teria permissão para visualizar atividades de estoque e vendas para fins de auditoria, mas não teria permissão para fazer alterações no sistema.

Essa configuração garantiria que apenas usuários autorizados tivessem acesso às informações relevantes para suas funções, o que ajudaria a manter a integridade do sistema de gerenciamento de estoque e proteger informações confidenciais.

Vulnerabilidades

Embora o modelo RBAC seja uma abordagem robusta para o controle de acesso, ele não é imune a vulnerabilidades. Algumas das vulnerabilidades mais comuns incluem:

1. Privilégios excessivos: se um usuário é atribuído a uma função com privilégios excessivos, ele pode ter acesso a recursos e informações que não são necessários para suas tarefas diárias, aumentando o risco de vazamento de informações ou de acesso não autorizado.
2. Privilégios insuficientes: se um usuário é atribuído a uma função com privilégios insuficientes, ele pode não ter acesso aos recursos e informações necessários para realizar suas tarefas, o que pode afetar negativamente a eficiência e a eficácia do sistema.
3. Permissões mal configuradas: se as permissões associadas a uma função são mal configuradas, um usuário pode ter acesso a recursos que não deveria ter, ou pode ser impedido de acessar recursos necessários para suas tarefas diárias.
4. Ataques de engenharia social: os usuários podem ser convencidos a fornecer suas credenciais de login a um atacante por meio de phishing ou outras técnicas de engenharia social, permitindo que o atacante acesse recursos que normalmente não teria acesso.
   
5. Erros de implementação: erros de programação ou configuração podem permitir que usuários acessem recursos que não deveriam ter acesso ou que contornem o controle de acesso RBAC.

Essas são apenas algumas das vulnerabilidades comuns encontradas no modelo RBAC. Para evitar essas vulnerabilidades, é importante implementar as práticas recomendadas de segurança e manter o controle de acesso RBAC atualizado e bem configurado.

Revisando a segurança do modelo RBAC
Revisar a segurança do modelo RBAC é uma prática importante para garantir que o sistema esteja protegido contra vulnerabilidades e riscos de segurança. Aqui estão algumas etapas que podem ser seguidas para revisar a segurança do RBAC:

1. Avaliar a estrutura de RBAC: revise a estrutura de RBAC atual e avalie se ela está configurada corretamente, ou seja, se as funções estão definidas adequadamente e as permissões associadas a cada função são apropriadas e relevantes para a tarefa desempenhada pelo usuário.
2. Analisar as permissões de acesso: revise as permissões de acesso de usuários individuais e verifique se elas estão em conformidade com a política de segurança da organização.
3. Revisar os logs de auditoria: analise os logs de auditoria do sistema para identificar quaisquer tentativas de acesso não autorizado e outras atividades suspeitas.
4. Verificar a implementação do RBAC: verifique se o modelo RBAC está implementado corretamente e se os controles de acesso estão sendo aplicados corretamente em todo o sistema.
5. Realizar testes de penetração: conduza testes de penetração para identificar vulnerabilidades no sistema e determinar a eficácia do modelo RBAC em impedir ataques cibernéticos.
   
6. Atualizar o RBAC: faça as atualizações necessárias no modelo RBAC para corrigir quaisquer vulnerabilidades encontradas e melhorar a segurança do sistema.

Essas são apenas algumas etapas que podem ser seguidas para revisar a segurança do modelo RBAC. É importante realizar essas revisões regularmente para garantir que o sistema esteja sempre protegido contra as últimas ameaças de segurança.

Pentesting pode ajudar na revisão de segurança do RBAC?

Sim, o Pentesting (teste de penetração) pode ser uma ferramenta valiosa para ajudar na revisão de segurança do modelo RBAC.

O Pentesting é uma técnica de teste de segurança que simula um ataque cibernético em um sistema para identificar e explorar vulnerabilidades e falhas de segurança. Durante um teste de penetração, os testadores tentam assumir o controle do sistema e obter acesso a recursos e informações que não deveriam estar disponíveis para eles.

Ao aplicar o Pentesting em um sistema com o modelo RBAC implementado, os testadores podem identificar vulnerabilidades específicas do RBAC, como funções com privilégios excessivos ou insuficientes, permissões mal configuradas e outros erros de implementação. Os resultados do teste podem ser usados para ajudar a aprimorar a configuração e a política de segurança do RBAC e corrigir quaisquer vulnerabilidades identificadas.

No entanto, é importante lembrar que o Pentesting deve ser conduzido com o consentimento da organização proprietária do sistema e seguindo um código de ética profissional estabelecido. Além disso, os testes de penetração não são uma solução única e devem ser combinados com outras práticas recomendadas de segurança, como revisão de código, análise de vulnerabilidades, atualização de software e treinamento de conscientização de segurança para os usuários.

Soluções no mercado
Existem diversas soluções específicas no mercado para implementação e gerenciamento do modelo RBAC. Algumas dessas soluções são:

1. Microsoft Azure RBAC: O Azure RBAC é um serviço de gerenciamento de acesso baseado em funções oferecido pela Microsoft Azure. Ele permite que as organizações gerenciem o acesso a recursos do Azure por meio da atribuição de funções e permissões específicas aos usuários.
2. IBM Security Identity Governance and Intelligence (IGI): O IBM IGI é uma solução de gerenciamento de identidade que inclui funcionalidades avançadas de RBAC para controle de acesso a recursos de TI e gerenciamento de privilégios de usuários.
3. Oracle Identity Management: O Oracle Identity Management é uma plataforma de gerenciamento de identidade e acesso que inclui recursos avançados de RBAC para gerenciamento de acesso a aplicativos, sistemas e dados.
4. RSA Identity Governance and Lifecycle: O RSA Identity Governance and Lifecycle é uma solução de gerenciamento de identidade e acesso que inclui recursos avançados de RBAC para gerenciamento de privilégios de usuários e controle de acesso a recursos críticos.
5. BeyondTrust Privilege Management: O BeyondTrust Privilege Management é uma solução de gerenciamento de privilégios que inclui recursos avançados de RBAC para gerenciamento de acesso privilegiado a sistemas e aplicativos.

Essas são apenas algumas das soluções disponíveis no mercado para implementação e gerenciamento do modelo RBAC. É importante que as organizações avaliem suas necessidades específicas e escolham a solução que melhor atenda às suas necessidades de segurança e gerenciamento de acesso.

A autorização RBAC é crucial, mas não pode ser granular o suficiente para ter autorização nos recursos dos pods (ou em qualquer recurso que gerencie pods). A única granularidade são os verbos da API no próprio recurso, por exemplo, criar em pods. Sem admissão adicional, a autorização para criar esses recursos permite acesso direto e irrestrito aos nós programáveis de um cluster.

Boa Prática Geral
Ultimo privilégio
Idealmente, direitos mínimos de RBAC devem ser atribuídos a usuários e contas de serviço. Somente as permissões explicitamente necessárias para sua operação devem ser usadas. Embora cada cluster seja diferente, algumas regras gerais que podem ser aplicadas são:

• Atribua permissões no nível do namespace sempre que possível. Use RoleBindings em oposição a ClusterRoleBindings para conceder direitos aos usuários somente em um namespace específico.
• Evite fornecer permissões curinga quando possível, especialmente para todos os recursos. Como o Kubernetes é um sistema extensível, fornecer acesso curinga concede direitos não apenas a todos os tipos de objetos que existem atualmente no cluster, mas também a todos os tipos de objetos que serão criados no futuro.
• Os administradores não devem usar contas de administrador de cluster, exceto quando especificamente necessário. Fornecer uma conta com poucos privilégios com direitos de representação pode evitar a modificação acidental dos recursos do cluster.
• Evite adicionar usuários ao grupo system:masters. Qualquer usuário que seja membro desse grupo ignora todas as verificações de direitos RBAC e sempre terá acesso irrestrito de superusuário, que não pode ser revogado removendo RoleBindings ou ClusterRoleBindings. Além disso, se um cluster estiver usando um webhook de autorização, a associação a esse grupo também ignorará esse webhook (as solicitações de usuários que são membros desse grupo nunca serão enviadas ao webhook)
  

Minimize a distribuição de tokens privilegiados
Idealmente, os pods não devem ser atribuídos a contas de serviço que receberam permissões poderosas (por exemplo, qualquer um dos direitos listados em riscos de escalonamento de privilégios). Nos casos em que uma carga de trabalho requer permissões poderosas, considere as seguintes práticas:

• Limite o número de nós executando pods poderosos. Certifique-se de que quaisquer DaemonSets executados sejam necessários e sejam executados com o mínimo de privilégio para limitar o raio de explosão das fugas de contêiner.
  
• Evite executar pods poderosos ao lado de pods não confiáveis ou expostos publicamente. Considere o uso de Taints and Toleration, NodeAffinity ou PodAntiAffinity para garantir que os pods não sejam executados ao lado de pods não confiáveis ou menos confiáveis. Preste atenção especial às situações em que pods menos confiáveis não atendem ao padrão de segurança de pod restrito.

Endurecimento
O padrão do Kubernetes é fornecer acesso que pode não ser necessário em todos os clusters. A revisão dos direitos RBAC fornecidos por padrão pode fornecer oportunidades para aumentar a segurança. Em geral, não devem ser feitas alterações nos direitos fornecidos ao sistema: existem algumas opções para fortalecer os direitos do cluster:

Revise as ligações para o grupo system:unauthenticated e remova-as sempre que possível, pois isso dá acesso a qualquer pessoa que possa entrar em contato com o servidor API em um nível de rede.

Evite a montagem automática padrão de tokens de conta de serviço definindo automountServiceAccountToken: false. Para obter mais detalhes, consulte como usar o token de conta de serviço padrão. Definir esse valor para um pod substituirá a configuração da conta de serviço. As cargas de trabalho que exigem tokens de conta de serviço ainda podem montá-los.

Revisão periódica
É vital revisar periodicamente as configurações do Kubernetes RBAC para entradas redundantes e possíveis escalações de privilégios. Se um invasor conseguir criar uma conta de usuário com o mesmo nome de um usuário excluído, ele poderá herdar automaticamente todos os direitos do usuário excluído, especialmente os direitos atribuídos a esse usuário.

Kubernetes RBAC – riscos de escalonamento de privilégios
No Kubernetes RBAC, há vários privilégios que, se concedidos, podem permitir que um usuário ou uma conta de serviço escale seus privilégios no cluster ou afete sistemas fora do cluster.

Esta seção destina-se a fornecer visibilidade das áreas onde os operadores de cluster devem cuidar, para garantir que eles não permitam inadvertidamente mais acesso aos clusters do que o pretendido.

Listando segredos
Em geral, é claro que permitir o acesso aos segredos permitirá que um usuário leia seu conteúdo. Também é importante observar que o acesso à lista e à exibição também permite que os usuários revelem o conteúdo secreto. Por exemplo, quando uma resposta de lista é retornada (por exemplo, por meio de kubectl get secrets -A -o yaml), a resposta inclui o conteúdo de todos os segredos.

Criação de carga de trabalho
A permissão para criar cargas de trabalho (pods ou recursos de carga de trabalho que gerenciam pods) em um namespace concede implicitamente acesso a muitos outros recursos nesse namespace, como segredos, ConfigMaps e PersistentVolumes que podem ser montados em pods. Além disso, como os pods podem ser executados como qualquer ServiceAccount, conceder permissão para criar cargas de trabalho também concede implicitamente os níveis de acesso à API de qualquer conta de serviço nesse namespace.

Os usuários que podem executar pods privilegiados podem usar esse acesso para obter acesso ao nó e potencialmente elevar ainda mais seus privilégios. Onde você não confia totalmente em um usuário ou outro principal com a capacidade de criar pods adequadamente seguros e isolados, você deve aplicar o padrão de segurança de linha de base ou restrito de pod. Você pode usar a admissão de segurança de pod ou outros mecanismos (de terceiros) para implementar essa aplicação.

Por esses motivos, os namespaces devem ser usados para separar os recursos que exigem diferentes níveis de confiança ou locação. Ainda é considerada uma prática recomendada seguir os princípios de privilégio mínimo e atribuir o conjunto mínimo de permissões, mas os limites dentro de um namespace devem ser considerados fracos.

Criação de volume persistente
Se alguém – ou algum aplicativo – tiver permissão para criar PersistentVolumes arbitrários, esse acesso inclui a criação de volumes hostPath, o que significa que um pod obteria acesso ao(s) sistema(s) de arquivos do host subjacente(s) no nó associado.

Conceder essa capacidade é um risco de segurança.

Há muitas maneiras de um contêiner com acesso irrestrito ao sistema de arquivos do host escalar privilégios, incluindo a leitura de dados de outros contêineres e o abuso das credenciais dos serviços do sistema, como o Kubelet.

Você só deve permitir o acesso para criar objetos PersistentVolume para:

• usuários (operadores de cluster) que precisam desse acesso para seu trabalho e em quem você confia,
• os componentes do plano de controle do Kubernetes que criam PersistentVolumes com base em PersistentVolumeClaims que são configurados para provisionamento automático. Isso geralmente é configurado pelo provedor Kubernetes ou pelo operador ao instalar um driver CSI.
  

Quando o acesso ao armazenamento persistente for necessário, os administradores confiáveis devem criar PersistentVolumes e os usuários restritos devem usar PersistentVolumeClaims para acessar esse armazenamento.

Acesso ao sub-recurso de proxy de nós
Os usuários com acesso ao sub-recurso de proxy de objetos de nó têm direitos à API do Kubelet, que permite a execução de comandos em cada pod no(s) nó(s) aos quais eles têm direitos. Esse acesso ignora o log de auditoria e o controle de admissão, portanto, tome cuidado antes de conceder direitos a esse recurso.

Escalar verbo (Escalate verb)
Geralmente, o sistema RBAC impede que os usuários criem funções de cluster com mais direitos do que o usuário possui. A exceção a isso é o verbo escalar. Conforme observado na documentação do RBAC, os usuários com esse direito podem aumentar efetivamente seus privilégios.

Verbo vincular (Bind verb)
Semelhante ao verbo escalar, conceder aos usuários esse direito permite ignorar as proteções integradas do Kubernetes contra o escalonamento de privilégios, permitindo que os usuários criem vinculações a funções com direitos que ainda não possuem.

Verbo representar (Impersonate verb)
Esse verbo permite que os usuários representem e obtenham os direitos de outros usuários no cluster. Deve-se ter cuidado ao concedê-lo, para garantir que permissões excessivas não sejam obtidas por meio de uma das contas representadas.

CSRs e emissão de certificados
A API CSR permite que usuários com direitos de criação para CSRs e direitos de atualização em solicitações/aprovação de assinatura de certificado em que o signatário é kubernetes.io/kube-apiserver-client criem novos certificados de cliente que permitem que os usuários se autentiquem no cluster. Esses certificados de cliente podem ter nomes arbitrários, incluindo duplicatas de componentes do sistema Kubernetes. Isso permitirá efetivamente a escalação de privilégios.

Solicitação de token
Os usuários com direitos de criação em contas de serviço/token podem criar TokenRequests para emitir tokens para contas de serviço existentes.

Controlar webhooks de admissão
Os usuários com controle sobre a validação de configurações de webhook ou as configurações de webhook mutantes podem controlar os webhooks que podem ler qualquer objeto admitido no cluster e, no caso de webhooks mutantes, também podem modificar os objetos admitidos.

Kubernetes RBAC – riscos de negação de serviço
Negação de serviço de criação de objeto
Os usuários que têm direitos para criar objetos em um cluster podem criar objetos grandes o suficiente para criar uma condição de negação de serviço com base no tamanho ou no número de objetos, conforme discutido em etcd usado pelo Kubernetes é vulnerável ao ataque OOM. Isso pode ser especificamente relevante em clusters multilocatários se usuários semiconfiáveis ou não confiáveis tiverem acesso limitado a um sistema.

Uma opção para mitigar esse problema seria usar cotas de recursos para limitar a quantidade de objetos que podem ser criados.

Para saber mais, consulte a documentação

Precisa de ajuda em segurança para a sua empresa? Fale conosco!