Como explorar listas de controle de acesso

Explore as ACLs (Access Control Lists, listas de controle de acesso).

Todas as regras da lista de controle de acesso especificam:

• O tipo de decisão, o tipo de regra e a operação que definem a ACL
• O objeto que está sob proteção
• As condições necessárias para acessar o objeto

Componentes da ACL

O tipo de decisão define se os usuários terão permissão para acessar o objeto se as condições forem atendidas ou negará o acesso ao objeto, a menos que as condições sejam atendidas.

Tipo de decisão	Descrição
Deny-Unless	Restrinja o acesso ao recurso, negando o acesso explicitamente a menos que as condições sejam aprovadas. Para obter mais informações, consulte acl-denial-behavior.html#acl-denial-behavior__section_qnd_snl_zbc.
Allow-If	Permita o acesso ao recurso se as condições forem aprovadas.

O objeto é o destino para o qual o acesso precisa ser controlado. Cada objeto consiste em um tipo e nome que identificam exclusivamente uma tabela, campo ou registro específicos. Com o campo Aplica-se a, os usuários têm controle granular sobre os registros específicos aos quais essa ACL se aplicará.

Por exemplo, todas estas entradas especificam um objeto:

Tipo	Nome	Objeto protegido
registro	[incident].[--None--]	A tabela de incidente.
registro	[incidente].[ativo]	O campo "Ativo" na tabela "Incidente".
registro	[incident] Aplica-se a: Prioridade = P1	Somente incidentes de prioridade 1 na tabela de incidentes.
REST_Endpoint	user_role_inheritance	O registro para a Scripted REST API user_role_inheritance.

Cada operação descreve uma ação válida que o sistema pode executar no objeto especificado. Alguns objetos, como registros, oferecem suporte a várias operações, enquanto outros objetos, como REST_Endpoint, oferecem suporte somente a uma operação.

Por exemplo, todas essas entradas especificam uma operação:

Tipo	Nome	Operação	Operação protegida
registro	[incidente].[-- Nenhum --]	criar	Criando registros na tabela de incidente.
registro	[incidente].[ativo]	gravar	Atualizando o campo Ativo na tabela de Incidente.
REST_Endpoint	user_role_inheritance	executar	Executar a Sripted REST API user_role_inheritance.

As condições especificam em que momento alguém pode acessar a operação e o objeto nomeados. Os administradores de segurança podem especificar requisitos das condições adicionando:

• Uma ou mais funções do usuário na lista Requer função.
• Um ou mais atributos de segurança que precisam ser avaliados como verdadeiros.
• Uma ou mais condições de dados.
• Um script que é avaliado como verdadeiro ou falso ou define a variável answer como verdadeira ou falsa.

Para ter acesso a um objeto e uma operação, um usuário deve ser aprovado em todas as condições relacionadas em um controle de acesso. Por exemplo, este controle de acesso restringe o acesso às operações de exibição na tabela de incidentes.

Para atualizar um registro na tabela de incidentes, um usuário deve ter as funções listadas e o registro deve atender à condição.

Tipo de condição	Requisito	Descrição
Requer função	Requer função:itil	Permita que somente usuários com a função itil atualizem incidentes.
Atributos de segurança	UserIsAuthenticated	Somente usuários autenticados podem atualizar incidentes.
Condição de dados	[Incident state] [is not] [Closed]	Permita atualizações somente em registros de incidentes ativos.

Comportamento Aplica-se a

O campo Aplica- se a determina se uma ACL se aplica a registros, enquanto a condição de dados avalia uma ACL que já foi aplicada. Aplica-se a especifica se a ACL afeta um registro específico; se estiver vazio, a ACL se aplicará a todos os registros. Aplica-se a pode ser usado para imposição de ACL granular, enquanto "Condição de dados" é um critério de avaliação.

Nota:

Aplica-se a faz distinção entre maiúsculas e minúsculas.

Comportamento padrão de negação

Por padrão, o mecanismo de ACL negará o acesso completamente se uma ACL estiver vazia ou for inválida. As ACLs vazias são definidas como ACLs sem um ou mais destes componentes:

• Função definida
• Atributo de segurança
• Condição de dados
• Script

As ACLs inválidas são definidas como:

• ACLs com funções que não existem (por exemplo, não têm uma linha no banco de dados)
• ACLs com atributos de segurança que não existem (por exemplo, não têm uma linha no banco de dados)
• ACLs com um script que contém "answer=true" ou "true"

Se o sistema detectar que o usuário está criando uma ACL, ele solicitará que o usuário selecione uma função ou um atributo de segurança existente.

Processo de avaliação da ACL

Uma regra de ACL somente concederá ao usuário o acesso a um objeto se ele atender a todas as condições exigidas pela regra de ACL correspondente.

• A condição deve ser avaliada como verdadeira.
• O script deve ser avaliado como verdadeiro ou retornar uma variável de resposta com o valor verdadeiro.
• O usuário deve ter uma das funções na lista de funções necessárias. Se a lista estiver vazia, esta condição será avaliada como verdadeira.
• [Somente regras de ACL de registro] As regras de ACL correspondentes em nível de tabela e de campo devem ser avaliadas como verdadeiras.

Figura 1. Condições de avaliação da ACL

Sempre que uma sessão solicita dados, o sistema pesquisa regras de controle de acesso que correspondam ao objeto e à operação solicitados. Se houver uma regra de controle de acesso correspondente, o sistema avaliará se o usuário possui as condições necessárias para acessar o objeto e a operação. Se uma regra de controle de acesso especificar mais de uma condição, o usuário deverá atender a todas as condições para ter acesso ao objeto e à operação. A falha em cumprir qualquer condição impedirá que o usuário acesse o objeto e a operação correspondentes.

Se um usuário não atender às condições da primeira regra correspondente, o sistema avaliará as condições da próxima regra correspondente, conforme as especificações da ordem de processamento do controle de acesso. Se o usuário não atender às condições de nenhuma regra de controle de acesso correspondente, o sistema negará o acesso ao objeto e à operação solicitados.

Nota:

Se não houver regras de controle de acesso correspondentes para o objeto e a operação solicitados, o sistema concederá ao usuário o acesso a eles. Na prática, é raro o sistema não encontrar regras correspondentes porque o sistema tem um conjunto de regras de controle de acesso padrão que protegem todas as operações de registro.

Os efeitos de ter o acesso negado a um objeto dependem da regra de ACL em que o usuário falhou. Por exemplo, a falha em uma regra de ACL de operação de leitura impede que o usuário veja o objeto. Dependendo do objeto protegido, a regra de ACL oculta um campo em um formulário, oculta linhas de uma lista ou impede que um usuário acesse uma página de IU. A tabela a seguir contém a lista completa de resultados de falha de uma regra de ACL para uma determinada operação e tipo de objeto.

Verificações de ACL de antes e depois da consulta

Sua instância verifica as regras de ACL antes e depois que um usuário faz uma consulta. Uma vez que informações diferentes estão disponíveis antes e depois de uma consulta, os resultados podem ser diferentes.

Verificação de ACL antes da consulta

Antes que a sua instância execute uma consulta ao banco de dados, ela verifica as regras de ACL para cada campo na tabela consultada para determinar quais campos um usuário pode acessar. Esta verificação examina somente as funções do usuário e verifica se essas funções permitem o acesso aos campos. Como essa verificação é executada antes da consulta, a ACL não tem acesso aos registros na tabela, portanto, não pode levar esses dados em conta. Scripts e condições que dependem do conhecimento do conteúdo de um registro não são avaliados.

Se o usuário não tiver acesso de leitura neste ponto, o valor do campo não será mostrado para o usuário.

Verificação de ACL depois da consulta

Após a consulta, sua instância verifica cada registro retornado pela consulta. Durante esta verificação, existe o contexto para a ACL; portanto, as partes de função, condição e script da ACL são avaliadas. Se o usuário não tiver acesso de leitura neste ponto, o valor do campo não será mostrado para o usuário; no entanto, o usuário verá o rótulo do campo se suas funções permitirem o acesso ao campo.

Operação	Resultados da falha de uma regra de ACL no objeto
execute	O usuário não pode executar scripts em um registro ou página de IU.
criar	O usuário não pode ver a ação de IU Novo nos formulários. O usuário também não pode inserir registros em uma tabela usando protocolos de API, como serviços da Web. Uma ACL de criação com uma condição que exige que um campo contenha um valor específico pode ser avaliada como falsa. Os campos em novos registros são considerados vazios até que o registro seja salvo.
lido	O usuário não pode ver o objeto em formulários ou listas. O usuário não pode recuperar os registros usando protocolos de API como serviços da Web.
gravar	O usuário vê um campo somente leitura em formulários e listas e não pode atualizar registros usando protocolos de API, como serviços da Web.
excluir	O usuário não pode ver a ação de IU Excluir a partir dos formulários. O usuário também não pode remover os registros de uma tabela usando os protocolos de API como serviços da Web.
edit_task_relations	O usuário não pode definir relacionamentos entre tabelas de tarefas.
edit_ci_relations	O usuário não pode definir relacionamentos entre tabelas Item de configuração [cmdb_ci].
save_as_template	Usado para controlar os campos que devem ser salvos quando um modelo é criado.
add_to_list	O usuário não pode exibir ou personalizar colunas específicas na mecânica da lista.
list_edit	O usuário não pode atualizar registros (linhas) de uma lista.
report_on	O usuário não pode criar um relatório na tabela de ACL. Para obter mais informações, consulte Restringir criação de relatório com uma regra de ACL.
report_view	O usuário não pode exibir o conteúdo de um relatório na tabela de ACL ou no campo de ACL. Para obter mais informações, consulte Reporting.
personalize_choices	O usuário não pode clicar com o botão direito do mouse em um campo de lista e selecionar Configurar opções.

Requisitos de correspondência da ACL para objetos

Tipo de objeto	Regras de ACL correspondentes necessárias para acessar o objeto	Regras de ACL curinga existentes
Inclusões de script acionáveis pelo cliente	Os usuários devem atender às condições de duas regras de ACL: Todas as regras de ACL curinga para o objeto (se houver alguma regra de ACL para a operação). A primeira regra de ACL que corresponde ao nome do objeto (se houver alguma regra de ACL para a operação).	Por padrão, não há regras de curinga (*) para esses tipos de objeto. Se você criar uma regra de ACL curinga para um desses objetos, então a regra de ACL se aplica a todos os objetos deste tipo.
Processadores
Páginas de IU	Os usuários devem atender às condições de duas regras de ACL: A primeira regra de ACL que corresponde ao campo do registro (se houver alguma regra de ACL para a operação). A primeira regra de ACL que corresponde à tabela de registro (se houver alguma regra de ACL para a operação).	Por padrão, existem regras de tabela curinga (*) para as operações de criação, leitura, gravação e exclusão e regras de campo curinga (*.*) para as operações personalize_choices, create e save_as_template. Ao criar uma tabela, crie regras de ACL para a tabela, a menos que queira usar as regras de ACL curinga fornecidas.
Registro

Nota:

A propriedade (glide.sm.default_mode) de comportamento padrão do gerenciador de segurança determina se os usuários podem acessar objetos que correspondem apenas a regras de ACL da tabela curinga. Quando essa propriedade for definida para Negar acesso, apenas os administradores poderão acessar os objetos que correspondem às regras de ACL da tabela curinga.

Nota:

A regra de ACL do campo curinga (*.*) para a operação de criação reutiliza as mesmas condições da operação de gravação. Isso significa que as condições de criação são iguais às de gravação, a menos que você defina uma regra explícita de ACL para a operação de criação.

Várias regras de ACL no mesmo ponto da ordem de processamento

Se duas ou mais regras corresponderem ao mesmo ponto da ordem de processamento, o usuário deverá cumprir qualquer uma das condições de regras de ACL para acessar o objeto. Por exemplo, se você criar duas regras de ACL de campo para incident.number, um usuário que for aprovado em uma regra terá acesso ao campo de número, independentemente de ter falhado em qualquer outra regra de ACL de campo no mesmo ponto da ordem de processamento.

Função necessária

Usuários administradores normais podem exibir e depurar regras de controle de acesso. No entanto, para criar ou atualizar regras de controle de acesso existentes, os administradores devem elevar os privilégios para a função security_admin. Consulte Elevação para uma função privilegiada para obter instruções.

Regras de ACL em aplicações com escopo

É possível criar regras de ACL para objetos que estejam no mesmo escopo que a regra de ACL. Também é possível criar regras de ACL para tabelas com pelo menos um campo que esteja no mesmo escopo que a regra de ACL.

Para tabelas que estão em um escopo diferente do registro de regra da ACL, os tipos de regras são limitados.

• É possível criar uma regra de ACL para qualquer tabela, página de IU ou outro objeto que esteja no mesmo escopo da regra de ACL.
• É possível criar uma ACL para um campo que esteja no mesmo escopo que a regra de ACL.
  • Se a tabela estiver no mesmo escopo, será possível usar um script para avaliar as condições.
  • Se a tabela estiver em um escopo diferente, não será possível usar um script para avaliar as condições.
• Não é possível criar nem modificar regras de ACL para objetos que estão em um escopo diferente da aplicação que você selecionou no seletor de aplicações, inclusive a adição de uma função a uma ACL que está um escopo diferente.
• É possível criar regras de tabela curinga (*) somente no escopo global.
• É possível criar regras de campo curinga (*) somente para tabelas no mesmo escopo da regra de ACL.