Como explorar as listas de controle de acesso
Explorar Listas de controle de acesso (ACL).
Componentes de ACLs
- O objeto e a operação que estão sendo protegidos
- As permissões necessárias para acessar o objeto
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.
Por exemplo, todas essas entradas especificam um objeto:
| Tipo | Nome | Objeto protegido |
|---|---|---|
| registro | [incidente].[--Nenhum--] | A tabela de incidente. |
| registro | [incidente].[ativo] | O campo ativo na tabela de Incidente. |
| 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 | Executando a scripted REST API user_role_inheritance. |
- Uma ou mais funções de usuário na lista Requer função.
- Uma ou mais condições.
- Um script que é avaliado como verdadeiro ou falso ou define a variável de
respostacomo verdadeiro ou falso.
Para ganhar acesso a um objeto e operação, um usuário deve passar em todas as permissões listadas em um controle de acesso. Por exemplo, este controle de acesso restringe o acesso às operações de gravação na tabela de incidente.
Para atualizar um registro na tabela de incidente, um usuário deve ter as funções listadas e o registro deve atender à condição.
| Tipo de permissão | Requisito | Descrição |
|---|---|---|
| Requer função | Requer função:itil | Permita apenas que usuários com a função de itil atualizem incidentes. |
| Condição | [Estado do incidente] [não está] [Fechado] | Permita somente atualizações em registros de incidentes ativos. |
Processo de avaliação de ACL
Uma regra de ACL só concede a um usuário acesso a um objeto se o usuário atender a todas as permissõ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 no nível de tabela e de campo correspondentes devem ser avaliadas como verdadeiras.
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 tem as permissões necessárias para acessar o objeto e a operação. Se uma regra de controle de acesso especificar mais de uma permissão, o usuário deverá atender a todas as permissões para ganhar acesso ao objeto e à operação. A falha em qualquer verificação de permissão impede que o usuário acesse o objeto e a operação correspondentes.
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 uma 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
- Verificação de ACL antes da consulta
Antes de sua instância executar uma consulta de 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 essa verificação, há contexto para a ACL, portanto, a função, a condição e as partes de 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 a ele. No entanto, o usuário verá o rótulo do campo se suas funções permitirem 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 sempre é 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 também não pode recuperar 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 registros de uma tabela usando 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 ACL ou no campo 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 de curinga existentes |
|---|---|---|
| Script chamável pelo cliente inclui | Os usuários devem atender às permissões de duas regras de ACL:
|
Por padrão, não há regras de curinga (*) para esses tipos de objeto. Se você criar uma regra de ACL de caractere curinga para um desses objetos, a regra de ACL se aplicará a todos os objetos desse tipo. |
| Processadores | ||
| Páginas de IU | Os usuários devem atender às permissões de duas regras de ACL:
|
Por padrão, há regras de tabela de caracteres curinga (*) para as operações de criação, leitura, gravação e exclusão e regras de campo de 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 de curinga fornecidas. |
| Registro |
Várias regras de ACL no mesmo ponto na ordem de processamento
Se duas ou mais regras corresponderem no mesmo ponto na ordem de processamento, o usuário deve ser aprovado em qualquer uma das permissõ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 o usuário ter falhado em qualquer outra regra de ACL de campo no mesmo ponto na 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
Você pode criar regras de ACL para objetos no mesmo escopo da regra de ACL. Você também pode criar regras de ACL para tabelas com pelo menos um campo que esteja no mesmo escopo da regra de ACL.
- É 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, é possível usar um script para avaliar as permissões.
- Se a tabela estiver em um escopo diferente, você não poderá usar um script para avaliar as permissões.
- Você não pode criar ou modificar regras de ACL para objetos que estão em um escopo diferente da aplicação selecionada no seletor de aplicações, incluindo a adição de uma função a uma ACL em um escopo diferente.
- Você pode criar regras de tabela de caracteres curinga (*) somente no escopo global.
- Você pode criar regras de campo de curinga (*) somente para tabelas no mesmo escopo que a regra de ACL.