Visão geral do controle de acesso baseado em função (RBAC) de dados

Compatível com:

O controle de acesso baseado em função de dados (RBAC de dados) é um modelo de segurança que usa funções de usuário individuais para restringir o acesso do usuário aos dados em uma organização. Com o RBAC de dados, os administradores podem definir escopos e atribuí-los aos usuários para garantir que eles só possam acessar os dados necessários para as funções de trabalho.

Esta página oferece uma visão geral do RBAC de dados e ajuda você a entender como os rótulos e escopos funcionam juntos para definir permissões de acesso aos dados.

Diferença entre o RBAC de dados e o RBAC de recursos

O RBAC de dados e o RBAC de recursos são métodos para controlar o acesso em um sistema, mas se concentram em aspectos diferentes.

O RBAC de recursos controla o acesso a recursos ou funcionalidades específicos em um sistema. Ele determina quais recursos estão acessíveis aos usuários com base nas funções deles. Por exemplo, um analista júnior pode ter acesso apenas para visualizar painéis, mas não para criar ou modificar regras de detecção, enquanto um analista sênior pode ter permissões para criar e gerenciar regras de detecção. Para mais informações sobre o RBAC de recursos, consulte Configurar o controle de acesso a recursos usando o IAM.

O RBAC de dados controla o acesso a dados ou informações específicos em um sistema. Ele controla se um usuário pode visualizar, editar ou excluir dados com base nas funções dele. Por exemplo, em um sistema de gestão de relacionamento com o cliente (CRM), um representante de vendas pode ter acesso aos dados de contato do cliente, mas não aos dados financeiros, enquanto um gerente financeiro pode ter acesso aos dados financeiros, mas não aos dados de contato do cliente.

O RBAC de dados e o RBAC de recursos são usados com frequência para fornecer um sistema de controle de acesso abrangente. Por exemplo, um usuário pode ter permissão para acessar um recurso específico (RBAC de recursos) e, dentro desse recurso, o acesso a dados específicos pode ser restrito com base na função dele (RBAC de dados).

Planejar a implementação

Para planejar a implementação, revise a lista de papéis e permissões predefinidos do Google Security Operations e alinhe-os às necessidades da sua organização. Crie uma estratégia para definir escopos e rotular os dados recebidos. Verifique se você tem o papel de leitor de papéis (roles/iam.roleViewer) para gerenciar escopos. Identifique quais membros precisam ter acesso aos dados nesses escopos.

Se a organização exigir políticas do IAM além dos papéis predefinidos do Google SecOps, crie papéis personalizados para atender a requisitos específicos.

Papéis do usuário

Os usuários podem ter acesso aos dados com escopo (usuários com escopo) ou acesso global aos dados (usuários globais).

  • Os usuários com escopo têm acesso limitado aos dados com base nos escopos atribuídos. Esses escopos restringem a visibilidade e as ações a dados específicos. As permissões específicas associadas ao acesso com escopo são detalhadas na tabela a seguir.

  • Os usuários globais não têm escopos atribuídos e têm acesso irrestrito a todos os dados no Google SecOps. As permissões específicas associadas ao acesso global são detalhadas na tabela a seguir.

O acesso global substitui o acesso com escopo. Se um usuário tiver um papel global e um papel com escopo, ele terá acesso a todos os dados, independentemente das restrições impostas pelo papel com escopo.

Os administradores do RBAC de dados podem criar escopos e atribuí-los aos usuários para controlar o acesso aos dados no Google SecOps. Para restringir um usuário a determinados escopos, é necessário atribuir a ele o papel de acesso restrito a dados da API Chronicle (roles/chronicle.restrictedDataAccess) junto com um papel predefinido ou personalizado. O papel de acesso restrito a dados da API Chronicle identifica um usuário como um usuário com escopo. Não é necessário atribuir o papel de acesso restrito a dados da API Chronicle aos usuários que precisam de acesso global a dados.

Os papéis a seguir podem ser atribuídos aos usuários:

Tipo de acesso Papéis Permissões
Acesso global predefinido Os usuários globais podem receber qualquer um dos papéis predefinidos do IAM.
Acesso somente leitura com escopo predefinido Acesso restrito a dados da API Chronicle (roles/chronicle.restrictedDataAccess) e leitor de acesso restrito a dados da API Chronicle (roles/chronicle.restrictedDataAccessViewer) Leitor de acesso restrito a dados da API Chronicle
Acesso com escopo personalizado Acesso restrito a dados da API Chronicle (roles/chronicle.restrictedDataAccess) e papel personalizado (para definição de RBAC de recursos) Permissões personalizadas nos recursos
Acesso global personalizado Permissão chronicle.globalDataAccessScopes.permit e acesso global a dados da API Chronicle (roles/globalDataAccess) Permissões globais nos recursos

A seguir, há uma descrição de cada tipo de acesso apresentado na tabela:

Acesso global predefinido:esse acesso normalmente é necessário para usuários que precisam de acesso a todos os dados. É possível atribuir um ou mais papéis a um usuário com base nas permissões necessárias.

Acesso somente leitura com escopo predefinido:esse acesso é para usuários que precisam de acesso somente leitura. O papel de acesso restrito a dados da API Chronicle identifica um usuário como um usuário com escopo. O papel de leitor de acesso restrito a dados da API Chronicle concede acesso de visualização aos usuários nos recursos.

Acesso com escopo personalizado:o papel de acesso restrito a dados da API Chronicle identifica um usuário como um usuário com escopo. O papel personalizado especifica os recursos que o usuário pode acessar. Os escopos adicionados ao papel de acesso restrito a dados da API Chronicle especificam os dados que os usuários podem acessar nos recursos.

Para verificar se os escopos personalizados do RBAC funcionam corretamente, inclua a permissão chronicle.dataAccessScopes.list ao criar os papéis personalizados. No entanto, não inclua as permissões chronicle.DataAccessScopes.permit ou chronicle.globalDataAccessScopes.permit. Essas permissões podem ser incluídas se você tiver usado o editor de API Chronicle ou o administrador de API Chronicle predefinido como ponto de partida para os papéis personalizados.

Acesso global personalizado:esse acesso é para usuários que precisam de permissões irrestritas nos recursos atribuídos. Para conceder acesso global personalizado a um usuário, especifique a permissão chronicle.globalDataAccessScopes.permit além do papel personalizado atribuído ao usuário.

Papéis do usuário para painéis

O acesso aos painéis é controlado por dois fatores principais: a função funcional de um usuário e o escopo de acesso a dados. A combinação desses dois elementos determina o acesso ao painel. O papel atribuído a um usuário muda diretamente a interface e os recursos disponíveis. A seguir, estão os papéis predefinidos mais comuns que concedem aos usuários acesso aos painéis:

Tipo de acesso Papéis Descrição
Leitor roles/chroniclesiem.viewer Concede acesso somente leitura. Os usuários podem abrir e interagir com todos os painéis, mas não podem criar nem editar.
Editor roles/chroniclesiem.editor Concede acesso a todos os dados e permissões, incluindo a capacidade de criar, editar e excluir painéis personalizados.
Administrador roles/chroniclesiem.admin Concede permissões completas, semelhantes ao papel de editor, com acesso a todos os dados.
Leitor restrito roles/chroniclesiem.restrictedViewer Semelhante ao papel de leitor, mas todos os dados exibidos no painel são filtrados de acordo com o escopo do registro atribuído ao usuário (RBAC de dados).

Para mais informações sobre o RBAC de dados e o RBAC de recursos, consulte Diferença entre o RBAC de dados e o RBAC de recursos.

Permissões para papéis personalizados

É possível definir permissões granulares criando papéis personalizados.

As permissões a seguir se aplicam aos painéis:

  • chronicle.dashboards.list: permite que os usuários vejam a lista de painéis disponíveis.

  • chronicle.dashboards.get: permite que os usuários abram e visualizem o conteúdo de um painel.

  • chronicle.dashboards.create: permite que os usuários criem novos painéis.

  • chronicle.dashboards.update: permite que os usuários editem e salvem mudanças nos painéis atuais.

  • chronicle.dashboards.delete: permite que os usuários excluam painéis personalizados.

Por exemplo, é possível criar um papel personalizado de criador de painéis com apenas chronicle.dashboards.create e chronicle.dashboards.list permissions. Um usuário com esse papel pode criar um novo painel, mas não pode editar um painel atual.

Controle de acesso com escopos e rótulos

O Google SecOps permite controlar o acesso aos dados dos usuários usando escopos. Os escopos são definidos com a ajuda de rótulos que definem os dados a que um usuário dentro do escopo tem acesso. Durante a ingestão, os metadados são atribuídos aos dados na forma de rótulos, como namespace (opcional), metadados de ingestão (opcional) e tipo de registro (obrigatório). Esses são rótulos padrão que são aplicados aos dados durante a ingestão. Além disso, é possível criar rótulos personalizados. É possível usar rótulos padrão e personalizados para definir os escopos e o nível de acesso aos dados que os escopos vão definir.

Visibilidade de dados com rótulos de permissão e negação

Cada escopo contém um ou mais rótulos de permitir acesso e, opcionalmente, rótulos de negar acesso. Os rótulos de permissão de acesso concedem aos usuários acesso aos dados associados ao rótulo. Os rótulos de negação de acesso negam o acesso dos usuários aos dados associados ao rótulo. Os rótulos de negação de acesso substituem os rótulos de permissão de acesso na restrição do acesso do usuário.

Em uma definição de escopo, os rótulos de permissão de acesso do mesmo tipo (por exemplo, tipo de registro) são combinados usando o operador OR, enquanto os rótulos de tipos diferentes (por exemplo, tipo de registro e um rótulo personalizado) são combinados usando o operador AND. Os rótulos de negação de acesso são combinados usando o operador OR. Quando vários rótulos de negação de acesso são aplicados em um escopo, o acesso é negado se eles corresponderem a QUALQUER um desses rótulos.

Por exemplo, considere um sistema do Cloud Logging que categoriza registros usando os seguintes tipos de rótulo:

Tipo de registro:acesso, sistema, firewall

Namespace:app1, app2, banco de dados

Gravidade:crítica, aviso

Considere um escopo chamado "Registros restritos" que tem o seguinte acesso:

Tipo de rótulo Valores permitidos Valores negados
Tipo de registro Acesso, firewall Sistema
Namespace App1 App2, banco de dados
Gravidade Alerta Crítico

A definição de escopo é assim:

Permitir: (Log type: "Access" OR "Firewall") AND (Namespace: "App1") AND (Severity: "Warning")

Negar: Log type: "System" OR Namespace: App2 OR Namespace: Database OR Severity: "Critical"

Exemplos de registros que correspondem ao escopo:

  • Registro de acesso do app1 com gravidade: aviso
  • Registro de firewall do app1 com gravidade: aviso

Exemplos de registros que não correspondem ao escopo:

  • Registro do sistema do app1 com gravidade: aviso
  • Registro de acesso do banco de dados com gravidade: aviso
  • Registro de firewall do app2 com gravidade: crítica

Visibilidade de dados em eventos enriquecidos

Eventos enriquecidos são eventos de segurança que foram aprimorados com contexto e informações adicionais além do que os dados de registro brutos contêm. Os eventos enriquecidos só podem ser acessados em um escopo se o evento de base for acessível no escopo e se nenhum dos rótulos enriquecidos incluir nenhum dos rótulos de negação do escopo.

Por exemplo, considere um registro bruto que indica uma tentativa de login com falha de um endereço IP e tem um rótulo enriquecido user_risk: high (indica um usuário de alto risco). Um usuário com um escopo que tem o rótulo de negação user_risk: high não pode ver tentativas de login com falha de usuários de alto risco.

Impacto do RBAC de dados nos recursos do Google Security Operations

Depois que o RBAC de dados é configurado, os usuários começam a ver dados filtrados nos recursos do Google Security Operations. O impacto depende de como o recurso é integrado aos dados subjacentes. Para entender como o RBAC de dados afeta cada recurso, consulte Impacto do RBAC de dados nos recursos do Google Security Operations.

A seguir

Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais do Google SecOps.