Gerenciando configurações de regra

A especificação da herança do termo comercial, a definição das convenções de acesso aos dados, a precedência da ação da regra e a precedência do método de mascaramento antes da criação das regras de proteção de dados simplificam o comportamento das regras criadas e protegem os dados de forma consistente.

Determine se você deseja que os termos comerciais que têm termos comerciais dependentes de é um tipo de relacionamento também sejam incluídos quando as regras de proteção de dados forem avaliadas.

Escolha entre dois tipos de convenções de acesso a dados para regras de proteção de dados. É possível permitir o acesso aos dados, a menos que uma regra o impeça ou negar o acesso aos dados, a menos que uma regra o permita.

Também é possível escolher uma prioridade para regras e métodos de mascaramento. A precedência da ação de regra é aplicada quando várias regras têm ações diferentes que se aplicam aos mesmos valores dos dados O método de mascaramento é aplicado quando várias regras que possuem diferentes métodos de mascaramento se aplicam aos mesmos valores de dados

Antes de criar regras de proteção de dados, planeje e avalie quem as regras permitirão acessar os dados ou negarão acesso a eles. Projetar suas regras após o seu planejamento cuidadoso fornece uma base sólida para determinar os critérios para aplicar as regras e as ações de execução correspondentes Esse processo de planejamento cuidadoso também minimiza a chance de uma futura decisão de alternar o acesso à regra. Se você decidir posteriormente mudar seu paradigma de acesso para suas regras, deverá primeiro excluir todas as regras existentes e, em seguida, recriar as novas regras para essa classe de regras.

As seguintes opções de termos comerciais, convenções e precedências se aplicam às regras de proteção de dados.

Permissões necessárias

Você deve ser um administrador de conta do IBM Cloud para configurar convenções de regra.

Decisão de aplicação da regra de proteção de dados

Qualquer atividade que executa a consulta de uma decisão de avaliação sobre o acesso a dados é um evento auditável. Os eventos auditáveis são gerados e encaminhados para o serviço de log de auditoria. Você pode acompanhar as seguintes decisões de aplicação como eventos de auditoria quando o Enviar avaliações de políticas para registros de auditoria caixa de seleção está marcada:

  • wdp-policy-service.policy_item.evaluateItem– Avaliar um item.
  • wdp-policy-service.policy_item.evaluateItems– Avaliar itens.
  • wdp-policy-service.policy_resource.evaluateResource– Avaliar um recurso.
  • wdp-policy-service.policy_resource.evaluateResources– Avaliar recursos.

Avaliando regras e herança de termo de negócios

Selecione Herança de termos de negócios quando quiser que termos de negócios dependentes de uma relação de tipo hierárquico sejam incluídos quando as regras de proteção de dados forem avaliadas. Por exemplo, o termo de negócios Empréstimo possui um tipo de relacionamento com Empréstimo de estudante e Empréstimo pessoal. O termo comercial Empréstimo e seus subtipos Empréstimo para estudantes e Empréstimo pessoal estão todos incluídos quando as regras de proteção de dados são avaliadas. Para obter mais informações sobre os relacionamentos de tipo hierárquicos entre termos de negócios, consulte Projetando termos de negócios

Permitindo acesso à convenção de dados

O comportamento padrão na convenção permitir acesso é para que o acesso a dados seja concedido. Se você deseja proteger dados específicos, deve-se gravar regras que negam explicitamente determinados acessos a dados com base em atributos do usuário ou de dados

Com a convenção de dados de acesso permitido, as regras de proteção de dados têm essas ações disponíveis:

  • Nega o acesso a dados
  • Mascarar dados
  • Filtrar linhas

Um exemplo de uso dessa convenção pode incluir a criação de regras de proteção de dados que permitem que todos os funcionários da empresa acessem os dados de colegas de trabalho em geral, mas restrinjam o acesso às informações de folha de pagamento Para fazer isso, é possível gravar uma regra especificando que qualquer ativo que contenha atributos que denotem que está relacionado aos dados da folha de pagamento deve ser negado para qualquer usuário que não esteja no departamento de recursos humanos Assim, todos os dados de todos os tipos são permitidos, e apenas a exceção de dados de folha de pagamento para funcionários que não estão em recursos humanos é negada.

A convenção de acesso permitido é a convenção de dados padrão para regras de proteção de dados.

Negando acesso à convenção de dados

O comportamento padrão para a convenção negar acesso é negar acesso aos dados. Se você desejar revelar dados específicos, deverá gravar regras que permitam explicitamente que usuários específicos vejam os dados. Em um ambiente no qual a maior parte do acesso a dados precisa ser restrito, a convenção de negação permite gravar algumas regras nas quais os dados são permitidos em vez de gravar uma regra para cada caso em que os dados devem ser restritos.

Um exemplo de uso da convenção de negação para regras de proteção de dados pode ser um catálogo contendo informações pessoais sensíveis que não podem ser visualizadas entre departamentos. Nesse caso, qualquer ativo de dados identificado como marketing sendo acessado por qualquer usuário diferente de um membro do grupo de marketing deve ser negado. No entanto, um usuário que é membro do grupo de usuários de marketing tem permissão para ver ativos que são identificados como marketing. A convenção resulta em acesso negado a todos os usuários a todos os dados, exceto usuários no grupo de usuários de marketing, que têm permissão para acessar dados que são identificados como marketing pela regra de proteção de dados.

Com a convenção de dados de acesso negado, as regras de proteção de dados têm essas ações disponíveis:

  • Permitir o acesso aos dados
  • Mascarar dados
  • Filtrar linhas

Configurando a convenção de acesso a dados

A convenção de regras deve ser definida antes que sua equipe crie regras de proteção de dados. Deve-se excluir quaisquer regras existentes antes de mudar a Convenção Quando você altera a Convenção, as regras têm um conjunto diferente de ações permitidas

Para configurar as convenções de regras, acesse a página Gerenciar configurações de regras selecionando Controle> Regras e, em seguida, clicando em Gerenciar configurações de regras. Como alternativa, você pode chamar a API de configuração de imposição de regras.

As configurações de regra

Convenção de regra para regras de proteção de dados

Para definir a convenção de regra, use a interface de usuário Gerenciar configurações de regra ou chame a API de configuração de imposição de regra e defina " governance_access_type como um desses valores:

Configuração da UI Configuração da API. Convenção
Desbloqueado AEAD Padrão. Segue a convenção permitir que todo autor negue (AEAD). Permite o acesso aos dados, a menos que uma regra os negue Você grava regras que negam acesso a dados, mascara dados e filtra linhas de dados.
Bloqueado DEAA Segue a convenção negar tudo que o autor permite (DEAA). Nega acesso aos dados, a menos que uma regra permita. Você grava regras que permitem o acesso a dados, mascara dados e filtra linhas de dados.
Dica:

Se nenhuma regra de transformação puder ser avaliada, o resultado será padronizado para as seguintes decisões de convenção:

  • Deny para Bloqueado
  • Allow para Desbloqueado

Configurando a precedência para ações de regra e métodos de mascaramento

Depois de definir as convenções de regra, estabelecer uma precedência para regras e métodos de mascaramento ajuda a determinar:

  • A ação a ser aplicada quando várias regras que possuem ações diferentes se aplicam aos mesmos valores de dados
  • O método de mascaramento a ser aplicado quando várias regras que possuem diferentes métodos de mascaramento se aplicam aos mesmos valores de dados

Para configurar precedentes de regras, acesse a página Gerenciar Configurações de Regras selecionando Controle> Regras e, em seguida, clicando em Gerenciar Configurações de Regras.

Precedência de ação de regra

A precedência da ação de regra especifica o acesso de execução mais seguro, mais tolerante ou hierárquico que os usuários têm para um ativo.. As ações, em ordem de leniência, são: Permitir acesso, Máscara e Filtro, Negar acesso.

Um exemplo de aplicação dessa precedência é que os recursos humanos são compartilhados entre o departamento de recursos humanos. A convenção de regra é configurada para negar o acesso Uma regra especifica se um ativo é marcado como um documento de recursos humanos e se o usuário está dentro do grupo de usuários de recursos humanos, em seguida, permitir o acesso Outra regra afirma que, se uma regra contiver informações financeiras do funcionário, essas informações deverão ser mascarados

As informações financeiras do funcionário são mantidas em um banco de dados com tabelas que combinam tarefas, salário e dados de aposentadoria.. A tabela Tarefas possui dados para todos os tipos de funcionários e uma coluna RetireType que indica o status de aposentadoria de funcionários... Uma terceira regra exclui todas as linhas se o valor da coluna RetireType for Retired.

Quando todas as regras estão em vigor, a decisão de Allow access da primeira regra é anulada pela decisão de mascarar dados da segunda regra quando Most secure action wins. A terceira regra filtra todas as linhas em que RetireType está configurado como Retired.

Execução hierárquica como uma precedência de ação de regra

O cumprimento hierárquico é de interesse particular se você precisar de um acesso a dados mais restritivo e ainda desejar gravar regras mais genéricas No entanto, o comportamento resultante é possível escrevendo regras disjuntas para cada combinação de acesso de tipos de usuários e dados. A opção de cumprimento hierárquico como sua precedência de ação de regra, fornece um processo de pensamento simplificado, pensando como duas questões separadas:

  1. Quem pode receber acesso a qual ativo? Em seguida, é possível remover muitas das questões de mascaramento de determinados tipos de dados e simplificar a decisão em apenas duas opções de Allow ou Deny.

  2. Quais dados precisam ser mascarados? Então você pode ignorar o estado da primeira pergunta para conceder acesso. Agora é possível gravar uma regra de mascaramento mais abstrata, como Se o ativo de dados contiver coluna de classe de dados sensitive personal data , edite colunas com classe de dados sensitive personal data. Essa regra fora de uma configuração hierárquica inclui uma concessão implícita de acesso ao ativo com o mascaramento aplicado

A opção para configurar a precedência da decisão de regra para Cumprimento hierárquico pode ser configurada a partir do assistente Gerenciar configurações de regras ou, como alternativa, a partir da configuração do valor HIERARCHICAL para a access_decision_precedence API. A configuração cumprimento hierárquico configura uma avaliação de duas camadas para regras de proteção de dados. A primeira camada avalia as regras para uma decisão, o que resulta em ações Allow ou Deny , sem considerar nenhuma ação de mascaramento Em seguida, somente se a decisão da primeira camada for para acesso Allow , uma segunda camada será avaliada considerando regras com uma ação Transform . Para ver dados mascarados ou brutos, pelo menos uma decisão Allow é necessária.

  • Para Locked convenção, essa decisão Allow pode ser alcançada apenas com uma regra com ação Allow . Na convenção Locked , se você tiver regras que resultam em decisões Transform ou Mask , mas não tiver nenhuma regra Allow que conceda acesso, o resultado permanecerá como Deny. No entanto, se você tiver várias regras com ações de Allow e Transform, então o Allow continuará a avaliar o Transform e a decisão combinada resultante será as ações de mascaramento resultantes
  • Para a convenção Unlocked , a precedência hierárquica se torna equivalente à precedência A ação mais segura ganha (opção de APIRESTRICTIVE ), pois uma decisão Allow da primeira camada hierárquica é alcançável apenas sem regras efetivas que resultem em Deny. Portanto, se você tiver uma ação Deny e uma ação Transform , o resultado para a Execução hierárquica (opção de APIHIERARCHICAL ) e a Ação mais segura vence (opção de APIRESTRICTIVE ) será a ação Deny .

Precedência do método de mascaramento

A precedência do método de mascaramento especifica a transformação de valores de dados da maior privacidade ou do maior utilitário. A precedência é aplicada quando uma ação de regra é Máscara e determina como os valores de dados são mascarados.. Os métodos de mascaramento, em ordem de privacidade, são: Redact, Substitute, Obfuscate. Os métodos de mascaramento, em ordem de utilitário, são: Obfuscate, Substitute, Redact.

Um exemplo de aplicação dessa precedência é uma regra criada por um contador que especifica que os números de cartão de crédito devem ser ofuscados Mascarar os números permite que apenas representantes de solicitações vejam um número de cartão para ajudar os clientes que desejam devolver a mercadoria. O contador criou uma outra regra que edita todos os números de cartão de crédito se você estiver no departamento de vendas.

Quando um funcionário que está no departamento de vendas e no departamento de reclamações acessa as mesmas informações de cartão de crédito, ambos os métodos de mascaramento estão agindo nos mesmos dados.. Se a convenção de regra for mais segura, a precedência do método de mascaramento edita as informações acessadas pelas vendas. No entanto, como o funcionário também está no departamento de reclamações, esse funcionário pode ver os últimos quatro dígitos do número do cartão de crédito ofuscado

Cenário: Aplicando convenções e precedência

O exemplo a seguir combina a convenção de regras, a precedência da ação de regra, e a precedência do método de mascaramento. Usados em conjunto, eles criam opções flexíveis para proteger dados

Clarice criou uma planilha de funcionários e usa as configurações de regras e as regras de proteção de dados para proteger dados de funcionários de outras equipes em sua empresa. Ela protege os dados do funcionário estabelecendo primeiro convenções e precedência para as regras que está criando e, em seguida, projetando as regras.

Cenário: Estabelecendo Convenções e Precedência

Em Gerenciando configurações de regra, Clarice escolheu as opções a seguir:

  • Convenção: convenção de acesso a dados Desbloqueada que segue a convenção permitir que todo autor negue (AEAD).
  • Precedência da ação de regras: A ação mais tolerante vence
  • Precedência do método de mascaramento de regra: Método com a maioria dos ganhos de privacidade

Cenário: criando regras de proteção de dados

A Clarice cria três regras para proteger os dados na Planilha de Funcionários a seguir:

O exemplo de Planilha do Funcionário

Regra 1: If the user group is the Sales team, then deny access to the data in the asset. qualquer pessoa da equipe de Vendas não pode ver nenhum dado de propriedade da Clarice.

Regra 2: If the asset name is Employee Spreadsheet and it contains columns named Last Name, Email Address, then mask by obfuscating all columns named Last Name and Email Address. o exemplo a seguir mostra que as colunas Sobrenome e Endereço de E-mail são ofuscadas na Planilha de Funcionários quando acessadas por alguém em Finanças.

As colunas ofuscadas denominadas de sobrenome e exemplo de endereço de e-mail

Regra 3: If the user group is the Sales team and that user is accessing the Employee Spreadsheet, then mask by redacting the column named Email Address. o exemplo a seguir mostra quando a equipe de Vendas acessa a planilha, o acesso não é negado por causa da precedência da regra tolerante. Eles podem ver os sobrenomes ofuscados. No entanto, como a Clarice selecionou a precedência do método de mascaramento mais privado, os endereços de e-mail são editadas

O exemplo de ofuscar o sobrenome e o endereço de e-mail de edição

Saiba Mais