Vista geral do RBAC de dados
O controlo de acesso baseado em funções de dados (RBAC de dados) é um modelo de segurança que usa funções de utilizador individuais para restringir o acesso dos utilizadores aos dados numa organização. Com o RBAC de dados, os administradores podem definir âmbitos e atribuí-los aos utilizadores para ajudar a garantir que os utilizadores só podem aceder aos dados necessários para as suas funções de trabalho.
Esta página oferece uma vista geral do RBAC de dados e ajuda a compreender como as etiquetas e os âmbitos funcionam em conjunto para definir autorizações de acesso aos dados.
Diferença entre o RBAC de dados e o RBAC de funcionalidades
O CABF de dados e o CABF de funcionalidades são ambos métodos de controlo de acesso num sistema, mas focam-se em aspetos diferentes.
O RBAC de funcionalidades controla o acesso a funcionalidades específicas num sistema. Determina as funcionalidades acessíveis aos utilizadores com base nas respetivas funções. Por exemplo, um analista júnior pode ter acesso apenas para ver painéis de controlo, mas não para criar nem modificar regras de deteção, enquanto um analista sénior pode ter as autorizações para criar e gerir regras de deteção. Para mais informações sobre o CABF de funcionalidades, consulte o artigo Configure o controlo de acesso a funcionalidades através da IAM.
O RBAC de dados controla o acesso a dados ou informações específicos num sistema. Controla se um utilizador pode ver, editar ou eliminar dados com base nas respetivas funções. Por exemplo, num sistema de gestão das relações com clientes (CRM), um representante de vendas pode ter acesso aos dados de contacto dos clientes, mas não aos dados financeiros, enquanto um gestor financeiro pode ter acesso aos dados financeiros, mas não aos dados de contacto dos clientes.
O CABF de dados e o CABF de funcionalidades são frequentemente usados em conjunto para fornecer um sistema de controlo de acesso abrangente. Por exemplo, um utilizador pode ter autorização para aceder a uma funcionalidade específica (RBAC de funcionalidades) e, em seguida, nessa funcionalidade, o respetivo acesso a dados específicos pode ser restrito com base na respetiva função (RBAC de dados).
Planeie a implementação
Para planear a implementação, reveja a lista de funções e autorizações predefinidas do Google SecOps e alinhe-as com as necessidades da sua organização. Crie uma estratégia para definir âmbitos e etiquetar os dados recebidos. Certifique-se de que tem a função de leitor (roles/iam.roleViewer) para gerir âmbitos.
Identifique os membros que têm de ter acesso aos dados nestes âmbitos.
Se a sua organização precisar de políticas de IAM além das funções do Google SecOps predefinidas, crie funções personalizadas para suportar requisitos específicos.
Funções do utilizador
Os utilizadores podem ter acesso aos dados com âmbito (utilizadores com âmbito) ou acesso aos dados global (utilizadores globais).
Os utilizadores com âmbito têm acesso limitado aos dados com base nos âmbitos atribuídos. Estes âmbitos restringem a respetiva visibilidade e ações a dados específicos. As autorizações específicas associadas ao acesso limitado estão detalhadas na tabela seguinte.
Os utilizadores globais não têm âmbitos atribuídos e têm acesso ilimitado a todos os dados no Google SecOps. As autorizações específicas associadas ao acesso global estão detalhadas na tabela seguinte.
O acesso global substitui o acesso com âmbito. Se a um utilizador for atribuída uma função global e uma função com âmbito, este tem acesso a todos os dados, independentemente das restrições impostas pela função com âmbito.
Os administradores da RBAC de dados podem criar âmbitos e atribuí-los a utilizadores para controlar o respetivo acesso aos dados no Google SecOps. Para restringir um utilizador a determinados âmbitos, tem de lhe atribuir a função de acesso restrito a dados da API Chronicle (roles/chronicle.restrictedDataAccess) juntamente com uma função predefinida ou personalizada. A função de acesso restrito aos dados da API Chronicle
identifica um utilizador como um utilizador com âmbito. Não tem de atribuir a função de acesso restrito aos dados do Chronicle aos utilizadores que precisam de acesso global aos dados.
As seguintes funções podem ser atribuídas aos utilizadores:
| Tipo de acesso | Funções | Autorizações |
|---|---|---|
| Acesso global predefinido | Pode conceder aos utilizadores globais qualquer uma das funções IAM predefinidas. | |
| Acesso só de leitura com âmbito predefinido | Acesso a dados restritos da API Chronicle (roles/chronicle.restrictedDataAccess) e visualizador de acesso a dados restritos da API Chronicle (roles/chronicle.restrictedDataAccessViewer)
|
Visualizador de acesso a dados restritos da API Chronicle |
| Acesso personalizado ao nível do âmbito | Acesso a dados restritos da API Chronicle (roles/chronicle.restrictedDataAccess) e função personalizada (para definição de CABF de funcionalidades)
|
Autorizações personalizadas nas funcionalidades |
| Acesso global personalizado | Autorização chronicle.globalDataAccessScopes.permit e acesso global aos dados da API Chronicle (roles/globalDataAccess)
|
Autorizações globais nas funcionalidades |
Segue-se uma descrição de cada tipo de acesso apresentado na tabela:
Acesso global predefinido: este acesso é normalmente necessário para os utilizadores que precisam de aceder a todos os dados. Pode atribuir uma ou mais funções a um utilizador com base nas autorizações necessárias.
Acesso só de leitura predefinido com âmbito: este acesso destina-se a utilizadores que precisam de acesso só de leitura. A função de acesso restrito aos dados da API Chronicle identifica um utilizador como um utilizador com âmbito. A função de visualizador de acesso a dados restritos da API Chronicle concede acesso de visualização aos utilizadores nas respetivas funcionalidades.
Acesso com âmbito personalizado: a função de acesso restrito a dados da API Chronicle identifica um utilizador como um utilizador com âmbito. A função personalizada especifica as funcionalidades às quais o utilizador pode aceder. Os âmbitos adicionados à função de acesso restrito a dados da API Chronicle especificam os dados aos quais os utilizadores podem aceder nas funcionalidades.
Para verificar se os âmbitos personalizados da RBAC funcionam corretamente, inclua a autorização chronicle.dataAccessScopes.list
ao criar as funções personalizadas. No entanto, não inclua as autorizações chronicle.DataAccessScopes.permit nem chronicle.globalDataAccessScopes.permit. Estas autorizações podem ser incluídas se tiver usado o Editor da API Chronicle ou o administrador da API Chronicle pré-criados como ponto de partida para as suas funções personalizadas.
Acesso global personalizado: este acesso destina-se a utilizadores que precisam de autorizações
sem restrições nas funcionalidades atribuídas. Para conceder acesso global personalizado a um utilizador, tem de especificar a autorização chronicle.globalDataAccessScopes.permit, além da função personalizada atribuída ao utilizador.
Controlo de acesso com âmbitos e etiquetas
O Google SecOps permite-lhe controlar o acesso aos dados dos utilizadores através de âmbitos. Os âmbitos são definidos com a ajuda de etiquetas que definem os dados aos quais um utilizador no âmbito tem acesso. Durante o carregamento, os metadados são atribuídos aos dados sob a forma de etiquetas, como o espaço de nomes (opcional), os metadados de carregamento (opcional) e o tipo de registo (obrigatório). Estas são etiquetas predefinidas que são aplicadas aos dados durante o carregamento. Além disso, pode criar etiquetas personalizadas. Pode usar etiquetas predefinidas e personalizadas para definir os seus âmbitos e o nível de acesso aos dados que os âmbitos vão definir.
Visibilidade dos dados com etiquetas de permissão e recusa
Cada âmbito contém uma ou mais etiquetas allow access e, opcionalmente, etiquetas deny access. As etiquetas de acesso permitem que os utilizadores acedam aos dados associados à etiqueta. As etiquetas de negação de acesso negam aos utilizadores o acesso aos dados associados à etiqueta. As etiquetas de negação de acesso substituem as etiquetas de permissão de acesso na restrição do acesso do utilizador.
Numa definição de âmbito, as etiquetas de acesso do mesmo tipo (por exemplo, o tipo de registo) são combinadas através do operador OR, enquanto as etiquetas de tipos diferentes (por exemplo, o tipo de registo e uma etiqueta personalizada) são combinadas através do operador AND. As etiquetas de negação de acesso são combinadas através do operador OR. Quando são aplicadas várias etiquetas de negação de acesso num âmbito, o acesso é negado se corresponderem a QUALQUER UMA dessas etiquetas.
Por exemplo, considere um sistema do Cloud Logging que categoriza os registos através dos seguintes tipos de etiquetas:
Tipo de registo: acesso, sistema, firewall
Espaço de nomes: App1, App2, Database
Gravidade: crítica, aviso
Considere um âmbito denominado registos restritos que tenha o seguinte acesso:
| Tipo de etiqueta | Valores permitidos | Valores recusados |
|---|---|---|
| Tipo de registo | Acesso, firewall | Sistema |
| Espaço de nomes | App1 | App2, base de dados |
| Gravidade | Aviso | Crítico |
A definição do âmbito tem o seguinte aspeto:
Permitir: (Log type: "Access" OR "Firewall") AND (Namespace: "App1") AND (Severity: "Warning")
Recusar: Log type: "System" OR Namespace: App2 OR Namespace: Database OR Severity: "Critical"
Exemplos de registos que correspondem ao âmbito:
- Registo de acesso da App1 com gravidade: aviso
- Registo de firewall da App1 com gravidade: aviso
Exemplos de registos que não correspondem ao âmbito:
- Registo do sistema da App1 com gravidade: aviso
- Registo de acesso da base de dados com gravidade: aviso
- Registo de firewall da App2 com gravidade: crítica
Visibilidade dos dados em eventos enriquecidos
Os eventos enriquecidos são eventos de segurança que foram melhorados com contexto e informações adicionais, além do que os dados de registo não processados contêm. Os eventos enriquecidos só são acessíveis num âmbito se o respetivo evento base for acessível no âmbito e nenhuma das etiquetas enriquecidas incluir nenhuma das etiquetas de negação do âmbito.
Por exemplo, considere um registo não processado que indica uma tentativa de início de sessão falhada a partir de um endereço IP e tem uma etiqueta enriquecida user_risk: high (indica um utilizador de alto risco).
Um utilizador com um âmbito que tenha a etiqueta de negação user_risk: high não consegue ver as tentativas de início de sessão falhadas de utilizadores de alto risco.
Impacto do RBAC de dados nas funcionalidades do Google Security Operations
Depois de configurar o RBAC de dados, os utilizadores começam a ver dados filtrados nas funcionalidades do Google Security Operations. O impacto depende da forma como a funcionalidade está integrada com os dados subjacentes. Para compreender o impacto do RBAC de dados em cada funcionalidade, consulte o artigo Impacto do RBAC de dados nas funcionalidades do Google Security Operations.
O que se segue?
Precisa de mais ajuda? Receba respostas de membros da comunidade e profissionais da Google SecOps.