Boas práticas para políticas ABAC

Considere as seguintes melhores práticas para o desenho de políticas ABAC e governação de etiquetas.

Padronizar atributos e nomeação

Estabeleça uma taxonomia consistente de etiquetas antes de criar políticas. Concordem nos nomes das chaves das tags, valores permitidos e convenções de nomes entre equipas. Um conjunto pequeno e bem definido de etiquetas é mais fácil de gerir do que uma proliferação de etiquetas ad hoc.

Por exemplo, use uma única sensitivity etiqueta com valores controlados (public, internal, confidential, restricted) em vez de múltiplas etiquetas sobrepostas como is_sensitive, data_class, e pii_level.

Controlar quem pode definir etiquetas

A marcação é uma delimitação de segurança no ABAC. Se um utilizador puder alterar etiquetas num ativo de dados, pode alterar quais as políticas que se aplicam a ele. Etiquetas erradas ou em falta podem deixar os dados desprotegidos ou inacessíveis porque as políticas só se aplicam quando as etiquetas corretas estão implementadas.

Definir regras de recurso, para dados não classificados

Não presuma que todos os objetos estão corretamente etiquetados. Use a automação para impor padrões de etiquetagem e implementar mecanismos de recuo para dados não classificados:

  • Aplique uma etiqueta restritiva por defeito (como classification : unverified) a novos objetos até que um gestor de dados os reveja.
  • Crie uma política que restrinja o acesso a objetos com a etiqueta padrão.

Para um exemplo detalhado, veja Impedir acesso até que colunas sensíveis sejam etiquetadas.

Definir políticas no âmbito mais elevado aplicável

Anexe políticas ao nível do catálogo ou esquema sempre que possível. Políticas ao nível de mesa são raras e deveriam ser exceção.

As políticas com âmbito de catálogo avaliam relativamente a todas as tabelas do catálogo, e as políticas com âmbito de esquema avaliam relativamente a todas as tabelas do esquema. Quando adiciona novas tabelas, as políticas existentes aplicam-se desde que as suas etiquetas correspondam às condições da apólice.

Evitar a expansão política

O ABAC foi concebido para reduzir o número de regras de controlo de acesso, não para as aumentar. Se as equipas criarem demasiadas etiquetas e políticas, o resultado torna-se difícil de gerir e auditar.

  • Analise os seus requisitos de governação antes de criar políticas.
  • Comece com um pequeno número de políticas abrangentes, como mascaramento de PII num catálogo ou filtragem regional por linhas.
  • Evite criar uma política separada para cada caso extremo.
  • Reveja periodicamente as políticas e consolide as sobrepostas.

Um grande número de apólices e condições complexas pode atrasar as verificações de autorização. Consulte Considerações de Desempenho para mais detalhes.

Auditar subsídios diretos e políticas ABAC GRANT em conjunto

Sugestão

Os privilégios efetivos de um utilizador sobre um objeto securável correspondem à união das concessões diretas e das políticas ABAC GRANT. Ao analisar o acesso, verifique tanto as concessões diretas como as políticas ABAC GRANT. Analisar apenas um deles pode dar-lhe uma visão incompleta dos privilégios efetivos do utilizador. Consulte as políticas da ABACGRANT.

Prefiro TO/EXCEPT para segmentação principal

Para políticas de filtro de linhas e de máscara de coluna, utilize as cláusulas TO e EXCEPT da política para definir a que utilizadores e grupos a política se aplica. Isto mantém a lógica da UDF simples. A EXCEPT cláusula exclui utilizadores específicos da política por completo, para que não estejam sujeitos a qualquer filtragem ou mascaramento. Quando é necessária lógica condicional complexa, funções identidade, como is_account_group_member() dentro dos UDFs, continuam a ser uma opção válida.

Para as políticas GRANT, TO e EXCEPT são os únicos mecanismos para identificar os principals abrangidos, porque as políticas GRANT não utilizam UDFs.

Também pode direcionar utilizadores por um atributo de identidade, como department. Quando o atributo já existe no seu provedor de identidade, uma política de mascaramento de coluna abrange todos os valores do atributo, pelo que evita criar um grupo e uma política separados para cada valor. Certifique-se de que os utilizadores sem valor para o atributo não têm acesso por defeito. Veja Mascarar uma coluna baseada nos atributos do utilizador que faz a consulta.

Para mais detalhes, veja Abordagem para direcionar os diretores.

Plano para avaliação dinâmica de políticas

As políticas do ABAC são dinâmicas. Ao contrário dos filtros de linhas ao nível da tabela e das máscaras de coluna, que são diretamente visíveis na definição da tabela, as políticas ABAC avaliam no momento da consulta com base na identidade do utilizador e nas pertenças aos grupos, bem como nas etiquetas do objeto de dados no âmbito da política. Isto pode dificultar que os consumidores de dados e os proprietários de tabelas compreendam quais as regras de acesso aplicáveis a uma determinada tabela.

  • Use SHOW EFFECTIVE POLICIES para determinar o que se aplica a uma tabela específica.
  • Documente a sua taxonomia de etiquetagem, políticas e abordagem de gestão de grupo para que as equipas possam compreender o modelo de governação sem ter de inspecionar cada política individualmente.
  • Se a transparência for crítica para uma tabela específica, considere usar filtros de linha ao nível da tabela e máscaras de coluna para esse caso isolado. Certifica-te de abordar primeiro possíveis conflitos.

Mais informações

Topic Description
Considerações sobre desempenho Como o design das políticas ABAC afeta o desempenho das consultas e como otimizar e testar as suas políticas.
Quando usar ABAC vs filtros de linhas a nível de tabela e máscaras de colunas Diferenças de âmbito, propriedade e como escolher entre as duas abordagens.
OpenSharing e ABAC Como partilhar tabelas protegidas por ABAC através do OpenSharing, gerir políticas do lado do destinatário e configurar vistas locais do destinatário.
Utilize o RBAC com ABAC Como se comportam as políticas ABAC quando os utilizadores assumem uma função no âmbito do RBAC, incluindo o comportamento da função de identidade (current_user(), is_member, is_account_group_member) e os padrões de utilização combinada.