Restrições de acesso aos dados nas funções 1s. Direitos de acesso ao SCP. RLS. Informações gerais e configurações. Restringir o acesso no nível do registro

Todas as configurações de direitos do usuário que faremos no âmbito deste artigo estão localizadas na seção 1C 8.3 "Administração" - "Configurações de usuários e direitos". Esse algoritmo é semelhante na maioria das configurações em formulários gerenciados. O programa 1C Accounting será usado como exemplo, mas a configuração de direitos em outros programas (1C UT 11, 1C ZUP 3, 1C ERP) é feita exatamente da mesma maneira.

Vamos para a seção "Usuários" da janela de configurações. Aqui vemos dois hiperlinks: "Usuários" e "Configurações de login". A primeira delas permite ir diretamente à lista de usuários desta infobase. Antes de criar um novo usuário, considere as possíveis configurações de login (hiperlink à direita).

Neste formulário de configuração, você pode definir a complexidade da senha (pelo menos 7 caracteres, conteúdo obrigatório de vários tipos de caracteres, etc.). Aqui você também pode especificar o comprimento da senha, seu período de validade e a proibição de acesso ao programa para usuários que não tenham atividade por um determinado período de tempo.

Agora você pode ir diretamente para adicionar um novo usuário ao 1C. Você pode fazer isso clicando no botão "Criar", conforme mostrado na imagem abaixo.

Em primeiro lugar, indicamos o nome completo - “Antonov Dmitry Petrovich” e selecionamos um indivíduo no diretório correspondente. Aqui você também pode especificar o departamento em que nosso funcionário trabalha.

O nome de login "AntonovDP" foi substituído automaticamente como abreviatura do nome completo "Antonov Dmitry Petrovich". Defina uma senha e autenticação para 1C Enterprise. Aqui você também pode especificar se este usuário tem permissão para alterar a senha por conta própria.

Suponha que queremos que Dmitry Petrovich Antonov esteja disponível na lista de seleção ao iniciar esta infobase. Para fazer isso, você precisa definir o sinalizador no item "Mostrar na lista de seleção". Como resultado, a janela de autorização ao iniciar o programa será semelhante à mostrada na figura abaixo.

Vamos prestar atenção a outra configuração importante no cartão do guia do usuário - "É permitido fazer login no programa". Se o atraso não for definido, o usuário simplesmente não poderá entrar nesta infobase.

Direitos de acesso

Depois de preencher todos os dados do cartão do usuário - Antonov Dmitry Petrovich, vamos anotá-los e proceder à definição dos direitos de acesso, conforme mostrado na figura abaixo.

Diante de nós, abrimos uma lista de perfis de acesso previamente inseridos no programa. Marque as caixas necessárias.

Acessar perfis de grupo

Os perfis do grupo de acesso podem ser configurados no formulário principal para configurar usuários e direitos. Vá para a seção "Acessar grupos" e clique no hiperlink "Acessar perfis de grupo".

Vamos criar um novo grupo a partir do formulário de lista aberto. Na seção tabular da guia "Ações permitidas (funções)", é necessário marcar as caixas das funções que afetarão os direitos de acesso dos usuários incluídos no grupo que estamos criando. Todas essas funções são criadas e configuradas no configurador. Eles não podem ser modificados ou criados no modo de usuário. Você só pode escolher em uma lista existente.

RLS: Restrição de acesso em nível de registro

Permite configurar de forma mais flexível o acesso aos dados do programa em determinadas seções. Para ativá-lo, defina o sinalizador no item de mesmo nome no formulário de configurações de usuário e direitos.

Observe que habilitar essa configuração pode afetar adversamente o desempenho do sistema. A questão é que o mecanismo RLS altera todas as solicitações dependendo das restrições definidas.

Vamos para o perfil de grupo de acesso "Grupo de teste" que criamos anteriormente. A figura abaixo mostra que após habilitar a restrição de acesso no nível do registro, uma aba adicional "Restrições de acesso" apareceu.

Vamos supor que queremos que os usuários aos quais o grupo de teste está atribuído tenham acesso aos dados de todas as organizações nesta infobase, exceto aquelas especificadas no perfil.

Na seção tabular superior, defina a restrição de acesso por organização. Na parte inferior, esclareceremos que não será fornecido acesso a dados (documentos, diretórios, etc.) para a organização Roga LLC.

Freqüentemente, há a necessidade de restringir parcialmente o acesso aos dados. Por exemplo, quando um usuário precisa ver documentos apenas para sua organização. Nesses casos, o 1C usa um mecanismo de restrição de acesso em nível de registro (o chamado RLS - Record Level Security).

Por exemplo, suponha que nos deparamos com a seguinte tarefa. A empresa mantém contabilidade multiempresarial e cada contraparte e usuário do banco de dados pertence a uma organização específica. É necessário fornecer acesso ao diretório “Contractors” de forma que cada usuário possa visualizar, editar e adicionar contrapartes apenas à sua organização.

Para resolver o problema, usaremos a plataforma “1C:Enterprise 8.2″. Vamos criar uma nova configuração em cujas propriedades a opção "Aplicativo gerenciado" será selecionada como modo de inicialização principal.

A seguir, vamos criar o diretório "Organizações" e mais dois diretórios - "Contratores" e "Usuários" com o atributo "Organização". Além dos diretórios, precisamos de dois parâmetros de sessão - “Organização” e “Usuário” (dos tipos apropriados). Os valores desses parâmetros são definidos no início de uma sessão de configuração e são armazenados até que ela termine. São os valores desses parâmetros que usaremos ao adicionar condições de restrição de acesso no nível do registro.

Os parâmetros da sessão são definidos em um módulo especial - “Módulo de sessão”

Neste módulo, descrevemos o procedimento predefinido “SetSessionParameters” no qual chamamos a função do módulo geral pré-preparado “FullPermissions”. Isso é necessário devido às peculiaridades da operação do banco de dados no modo de aplicativo gerenciado, quando parte do código do programa só pode ser executado no lado do servidor (não vou me alongar em explicar esses princípios neste artigo).

Código 1C v 8.x Procedimento para definir os parâmetros da sessão (parâmetros obrigatórios)
FullPermissions.SetSessionParameters();
EndProcedure

Nas propriedades do módulo “FullPermissions”, marque as caixas “Server”, “Server call” e “Privileged” (esta última significa que os procedimentos e funções deste módulo serão executados sem controle de acesso). O texto do módulo ficará assim:

Código 1C v 8.x Função DetermineCurrentUser()
CurrentUser = Directories.Users.FindByName(UserName(), True);
Return CurrentUser;
EndFunctions

Procedimento SetSessionParameters() Exportar
CurrentUser = Determinar CurrentUser();
CurrentOrganization = Diretórios.Organizações.EmptyReference();
Se ValueFilled(CurrentUser) Então
CurrentOrganization = CurrentUser.Organization;
Fim se;
SessionParameters.User = CurrentUser;
SessionParameters.Organization = CurrentOrganization;
EndProcedure

FunctionSessionParameterSet(ParameterName) Exportar
Return ValueFilled(SessionParameters[ParameterName]);
EndFunctions

Função RoleAvailableToUser(RoleName) Exportar
Return RoleAvailable(RoleName);
EndFunctions

No módulo de aplicativo gerenciado, verificaremos a presença de um usuário de configuração no diretório “Usuários” (para simplificar, buscaremos pelo nome) e desligaremos o sistema caso não seja encontrado. Isso é necessário para garantir que os parâmetros da sessão sejam preenchidos.

Código 1C v 8.x Procedimento de operação do pré-sistema (falha)
// todos, exceto o administrador, serão verificados quanto à presença no diretório "Usuários"
Se não FullPermissions.RoleAvailableToUser("FullPermissions") Então
Se NÃO FullPermissions.SessionParameterSet("User") Então
Warning("User """ + Username() + """ não encontrado no diretório!");
Rejeição = verdadeiro;
Retornar;
Fim se;
Fim se;
EndProcedure

Agora podemos ir diretamente para a descrição das restrições de acesso. Para fazer isso, crie a função “Usuário” e vá para a guia “Modelos de restrição”, onde adicionamos um novo modelo “AccountsReadingChange” com o seguinte texto de modelo: WHERE Organização = Organização #Parâmetro(1)

O texto do modelo de restrição é uma extensão da linguagem de consulta. Ao contrário de uma solicitação regular, o texto de restrição deve necessariamente conter a cláusula “WHERE”. Como os valores dos parâmetros de consulta (no nosso caso, é “&Organização”), são usados ​​os valores dos parâmetros de sessão de mesmo nome. Uma construção da forma #Parameter(1) significa que o sistema irá substituir o texto passado como primeiro parâmetro no local onde o template é utilizado neste local. Com a ajuda do modelo fornecido, cada registro da tabela será verificado (no nosso caso, será a pesquisa "Empreiteiros"). Para registros cujo valor do atributo “Organização” corresponda ao especificado no parâmetro de sessão correspondente, a condição descrita no modelo será atendida. Assim, essas entradas estarão disponíveis para leitura, edição ou adição (dependendo de qual desses direitos o modelo se aplica). Vou demonstrar o que foi dito acima com nosso exemplo.

Vamos para a guia “Direitos” da função “Usuário” e abra a lista de direitos no diretório “Contas”. Usaremos o modelo de restrição “AccountsReadChange” para as permissões “Read”, “Change” e “Add”.

Para o direito “Read”, usaremos um template com o parâmetro “OR ThisGroup”. Ao mesmo tempo, os usuários desta função poderão ler não apenas os elementos do diretório "Contas" de sua organização, mas também todos os grupos deste diretório.

#AccountsReadingChange("OU ThisGroup")

Como ao adicionar novos elementos do diretório, o sistema realiza uma leitura implícita de atributos predefinidos (isso é necessário, por exemplo, para numeração), é necessário garantir a leitura desimpedida desses campos. Para fazer isso, adicione uma linha adicional com um texto de restrição vazio à tabela de restrição de acesso a dados e liste os campos aos quais esta regra se aplica - Link, Versão dos dados, Pai, Código.

Assim, a tarefa de restringir o acesso no nível do registro é resolvida. Os usuários com restrições existentes terão acesso para visualizar e editar dados apenas para sua organização.

A plataforma 1C:Enterprise 8 possui um mecanismo integrado para restringir o acesso aos dados no nível do registro. Você pode ler informações gerais sobre isso aqui. Resumindo, o RLS permitirá que você restrinja o acesso aos dados de acordo com algumas condições nos valores dos campos. Por exemplo, você pode restringir o acesso dos usuários aos documentos dependendo do valor do atributo "Organização". Alguns usuários trabalharão com documentos para a organização "Empresa de Gestão" e o restante com a organização "Fábrica de Laticínios". Como um exemplo.

Preparação

O exemplo é implementado na configuração de demonstração do SCP 1.3. Vamos criar um usuário "Storekeeper" e adicionar a ele a função "Storekeeper" de mesmo nome.

Agora vamos prosseguir diretamente para a configuração dos direitos de acesso no nível do registro. Vamos mudar para a interface "Administração do usuário". No menu principal, selecione "Acesso ao nível dos registos -> Opções". Aqui, marcamos a caixa "Restringir o acesso no nível do registro por tipos de objetos" e, na lista de objetos, selecionamos "Organizações".

Assim, habilitamos o uso do RLS. Agora você precisa configurá-lo.

O controle de acesso em nível de registro não é configurado separadamente para cada perfil de usuário ou permissão. RLS é configurado para grupos de usuários. Vamos adicionar um novo grupo de usuários, vamos chamá-lo de "Lojistas"

A composição do grupo no lado direito do formulário mostra uma lista de usuários pertencentes a este grupo. Vamos adicionar o usuário que criamos anteriormente. À esquerda está uma tabela de restrições de acesso. Na configuração RLS, escolhemos que o acesso será limitado apenas por organizações, portanto, vemos apenas um tipo de objeto de acesso. Clique no botão "Configurações de acesso". O processamento para definir permissões para o grupo atual é aberto.

Na lista de objetos de acesso para o grupo, adicione a organização "PPE "Empreendedor"". Deixaremos inalterado o tipo de herança de direitos. O direito ao objeto de acesso será configurado para leitura e gravação. Clique em "OK", as configurações estão prontas. Acabamos de configurar o RLS no nível da organização.

O que o usuário vê

Execute o programa no usuário criado anteriormente e abra o diretório "Organizações". É assim que a lista ficará para o nosso usuário e para um usuário com direitos totais:

Como podemos ver, o usuário lojista vê apenas uma organização para a qual abrimos acesso de leitura. O mesmo se aplica a documentos, como recibos de bens e serviços.

Assim, o usuário não só não verá as organizações cujo acesso não está definido para ele, mas também não poderá ler / escrever documentos e outros objetos na infobase, para os quais os direitos na função no atributo "Organização " estão prontos.

Consideramos o exemplo mais simples de configuração do RLS. No próximo artigo, falaremos sobre a implementação do mecanismo RLS na configuração "Manufacturing Enterprise Management" versão 1.3.

1C possui um sistema de direitos de acesso integrado (esse sistema é chamado de funções 1C). Este sistema é estático - como o administrador definiu os direitos para 1C, que assim seja.

Além disso, existe um sistema dinâmico de direitos de acesso (chamado - RLS 1C). Nele, os direitos 1C são calculados dinamicamente no momento do trabalho do usuário com base nos parâmetros especificados.

Uma das configurações de segurança mais comuns em vários programas é um conjunto de permissões de leitura/gravação para grupos de usuários e, em seguida, inclusão ou exclusão de um usuário de grupos. Por exemplo, um sistema semelhante é usado no Windows AD (Active Directory).

Esse sistema de segurança em 1C é chamado de Funções 1C. As funções 1C estão localizadas na configuração na ramificação Geral / Funções. As funções 1C atuam como grupos para os quais os direitos 1C são atribuídos. Em seguida, o usuário é incluído ou excluído desse grupo.

Ao clicar duas vezes no nome da função 1C, você abrirá o editor de direitos para a função 1C. À esquerda está uma lista de objetos 1C. Selecione qualquer um e as opções para direitos de acesso serão exibidas à direita (no mínimo: ler, adicionar, alterar, excluir).

Para a ramificação superior (o nome da configuração atual), são definidos direitos administrativos 1C e acesso para iniciar várias opções.

Todos os direitos 1C são divididos em dois grupos - direito “simples” e o mesmo direito com a adição de “interativo”. O que isso significa?

Quando um usuário abre um formulário (por exemplo, processamento) e pressiona um botão nele, o programa na linguagem 1C integrada executa determinadas ações, por exemplo, excluir documentos. Pela permissão dessas ações (realizadas programaticamente) - "simplesmente" os direitos de 1C são responsáveis.

Quando um usuário abre um diário e começa a fazer algo no teclado por conta própria (por exemplo, inserir novos documentos), esses são direitos 1C “interativos”.

Um usuário pode ter várias funções disponíveis e, nesse caso, as permissões são adicionadas.

A seção sobre as possibilidades de definir direitos de acesso usando funções é um objeto 1C. Ou seja, você pode ativar o acesso ao diretório ou desativá-lo. Não pode ser ligado nem um pouco.

Para isso, existe uma extensão do sistema de funções 1C chamada 1C RLS. Este é um sistema dinâmico de direitos de acesso que permite restringir parcialmente o acesso. Por exemplo, o usuário só vê os documentos de um determinado depósito e organização e não vê o restante.

Com cuidado! Ao usar o esquema confuso RLS 1C, diferentes usuários podem ter dúvidas ao tentar verificar o mesmo relatório gerado por diferentes usuários.

Você pega um determinado diretório (por exemplo, organizações) e um certo direito (por exemplo, leitura). Você permite a leitura para a função 1C. No painel Data Access Restriction, você define o texto da consulta, que retorna TRUE ou FALSE dependendo das configurações. As configurações geralmente são armazenadas no registro de informações (por exemplo, o registro de informações de configuração Accounting UserAccessRightsSettingsUsers).

Esta solicitação é executada dinamicamente (ao tentar implementar a leitura), para cada entrada de diretório. Assim, para aqueles registros para os quais a consulta de segurança retornou TRUE, o usuário os verá, mas os demais não.
Os direitos 1C que estão sujeitos às restrições RLS 1C são destacados em cinza.

A cópia das mesmas configurações do RLS 1C é feita usando modelos. Você cria um modelo, nomeia-o (por exemplo) MyTemplate, especifica uma solicitação de segurança nele. Em seguida, nas configurações de direitos de acesso 1C, especifique o nome do modelo como este: "#MyTemplate".

Quando um usuário trabalha no modo 1C Enterprise, quando o RLS 1C está em execução, ele pode receber uma mensagem de erro “Direitos insuficientes” (por exemplo, para ler o diretório xxx).

Isso significa que o RLS 1C bloqueou a leitura de vários registros.

Para evitar que tal mensagem apareça, é necessário utilizar a palavra ALLOWED () no texto da solicitação na linguagem 1C integrada.

Por exemplo:

O programa 1C possui um sistema integrado de direitos de acesso, localizado no Configurador - Geral - Funções.

O que caracteriza este sistema e qual é o seu objetivo principal? Permite descrever conjuntos de direitos que correspondem às posições dos usuários ou suas atividades. Este sistema de direitos de acesso é de natureza estática, o que significa que, como o administrador definiu os direitos de acesso para 1C, é. Além do estático, existe um segundo sistema de direitos de acesso - dinâmico (RLS). Neste sistema, os direitos de acesso são calculados de forma dinâmica, dependendo dos parâmetros fornecidos, no decorrer do trabalho.

Funções em 1C

As configurações de segurança mais comuns em diferentes programas são o chamado conjunto de permissões de leitura / gravação para vários grupos de usuários e no futuro: inclusão ou exclusão de um usuário específico dos grupos. Tal sistema, por exemplo, é usado no sistema operacional Windows AD (Active Directory). O sistema de segurança usado no software 1C é chamado de funções. O que é isso? Roles em 1C é um objeto que está localizado na configuração na ramificação: General - Roles. Essas funções 1C são grupos para os quais os direitos são atribuídos. No futuro, cada usuário poderá ser incluído e excluído deste grupo.

Ao clicar duas vezes no nome da função, você abrirá o editor de direitos da função. À esquerda está uma lista de objetos, marque qualquer um deles e à direita você verá opções para possíveis direitos de acesso:

— leitura: obtenção de registros ou seus fragmentos parciais de uma tabela de banco de dados;
- adicionar: novos registros, mantendo os existentes;
— mudança: fazer alterações nos registros existentes;
- exclusão: alguns registros, mantendo o restante inalterado.

Observe que todos os direitos de acesso podem ser divididos em dois grupos principais - este é um direito "simples" e um direito com a adição da característica "interativa". O que significa aqui? E a coisa é a seguinte.

No caso em que o usuário abre algum formulário, por exemplo, processamento, e ao mesmo tempo clica nele com o mouse, o programa na linguagem 1C integrada começa a realizar ações específicas, por exemplo, deletar documentos. Pela permissão de tais ações realizadas pelo programa, os direitos da 1C são responsáveis, respectivamente, "simplesmente".

No caso de o usuário abrir o diário e começar a inserir algo por conta própria no teclado (novos documentos, por exemplo), os direitos 1C "interativos" são responsáveis ​​​​por permitir tais ações. Cada usuário pode ter várias funções disponíveis ao mesmo tempo, então a permissão é adicionada.

RLS em 1C

Você pode ativar o acesso ao diretório (ou documento) ou desativá-lo. Você não pode simplesmente ligá-lo um pouco. Para isso, existe uma certa extensão do sistema de funções 1C, chamada RLS. Este é um sistema dinâmico de direitos de acesso que introduz restrições parciais de acesso. Por exemplo, apenas os documentos de uma determinada organização e depósito ficam disponíveis para a atenção do usuário, ele não vê o resto.

Deve-se ter em mente que o sistema RLS deve ser aplicado com muito cuidado, pois é bastante difícil entender seu intrincado esquema, e diferentes usuários podem ter dúvidas quando, por exemplo, comparam o mesmo relatório, que é gerado a partir de vários Usuários. Vamos considerar tal exemplo. Você escolhe um diretório específico (organizações, por exemplo) e um direito específico (leitura, por exemplo), ou seja, permite a leitura para a função 1C. Ao mesmo tempo, você define o texto da solicitação no painel remoto Restrições de acesso a dados, de acordo com o qual Falso ou Verdadeiro é definido, dependendo das configurações. Normalmente, as configurações são armazenadas em um registro de informações especiais.

Esta consulta será executada dinamicamente (quando for feita uma tentativa de organizar a leitura), para todas as entradas do diretório. Funciona assim: aqueles registros para os quais a solicitação de segurança foi atribuída - Verdade, o usuário verá, mas outros não. Os direitos 1C com restrições estabelecidas são destacados em cinza.

A operação de copiar configurações de RLS idênticas é realizada usando modelos. Para começar, você cria um modelo, nomeando-o, por exemplo, MyTemplate, no qual você reflete a solicitação de segurança. Em seguida, nas configurações de direitos de acesso, especifique o nome deste modelo desta forma: "#MyTemplate".

Quando um usuário trabalha no modo 1C Enterprise, ao conectar-se ao RLS, pode aparecer uma mensagem de erro como: “Direitos insuficientes” (para ler o diretório XXX, por exemplo). Isso indica que o sistema RLS bloqueou a leitura de alguns registros. Para evitar que esta mensagem apareça novamente, você precisa inserir a palavra PERMITIDO no texto da solicitação.

https://zabor-vam.ru/product/metallicheskie/zabory-iz-profnastila/