No AX2012 novos termos foram adicionados, estes termos podem ser vistos na imagem abaixo, esta imagem é o diagrama de arquitetura de segurança do AX2012.
Vamos entender cada passo desta arquitetura.
Autenticação.
Por padrão somente os usuários de domínio autenticados no AD DS podem acessar o AX2012. Este usuário deve ser membro de no minimo uma role, caso contrario este usuário não terá nenhuma permissão no AX2012.
O AX2012 poderá utilizar outros métodos de autenticação diferentes do padrão
Autorização.
Autorização é o controle de acesso à aplicação do AX2012. As permissões de segurança são utilizadas para controlar o acesso aos elementos da aplicação tais como menus, itens do menu, botões de ação e comandos, relatórios e campos no AX Client e no Enterprise Portal.
No AX2012 as permissões de segurança individuais são combinadas dentro de "privilégios" e estes "privilégios" são combinados dentro das "duties". Para que uma role possua determinadas permissões é necessários que privilégios e duties sejam concedidos e estas roles.
Segurança de Dados.
A autorização é utilizada para conceder permissões enquanto a segurança de dados é utilizada para negar permissões em tabelas, campos e linhas do banco de dados.
A utilização deste recurso permite que você limite o acesso a dados transacionais. As politicas de segurança de dados podem limitar o acesso a dados baseados em datas, baseados em dados de usuários.
A segurança de nível de registro pode ser utilizada para limitar o acesso a dados baseados em query. Nas próximas versões do AX a segurança em nível de registro se tornará obsoleta, por este motivo é aconselhado que seja utilizado as politicas de segurança de dados.
Dica de prova:
Extensible Data Security Framework pode ser utilizado para restringir acesso a dados baseados em data, baseados em dados do usuário e em dados baseados em query!
Agora vamos nos aprofundar no conceito de autorização do AX2012, entendendo o que significa cada um de seus termos.
Na segurança baseada em regras (Role-Based Security), o acesso é garantido as "Security Roles" e não aos usuários individualmente. O usuário membro de uma security role terá acesso ao conjunto de privilégios associados a aquela Security role.
Nesta versão do AX, as Security Roles são alinhadas com a estrutura de negócios. Os usuários são adicionados as security roles baseados em suas responsabilidades na organização, domínio, e em sua participação em cada processo do negócio.
Este modelo de segurança é hierárquico, em cada elemento desta hierarquia temos um diferente nível de detalhes.
Permissões representam o acesso a objetos protegidos individualmente, como menus, tabelas e itens.
Privilégios são compostos por permissões e representam o acesso a determinadas tarefas como cancelar uma ordem de pagamento.
Duties são compostos por privilégios e representam parte de um processo de negocio como manter transações bancárias.
Duties e privilégios podem ser utilizados para conceder as devidas permissões de acesso ao Dynamics AX.
Para que seja possível acessar o Dynamics AX2012 é necessário que o usuário seja membro de pelo menos uma security role. Esta secutiry role a qual o usuário faz parte determinará quais atividades o usuário poderá executar no AX. Os administradores podem aplicar politicas de segurança de dados para limitar o acesso que os usuários podem ter em determinados dados. Por exemplo, um usuário pertencente a uma role deve ter acesso a dados de apenas uma organização. O administrador pode ainda especificar o nível de acesso que o usuário de uma role terá em dados antigos, atuais e novos dados do sistema. Por exemplo, um usuário pode ter privilégios para visualizar dados de todos os períodos, mas pode alterar apenas os dados do período atual.
No AX2012 é possível especificar as permissões para grupos do AD. Imagine que você tenha um grupo do AD adicionado a uma role no AX, este grupo tem permissão para controlar as funções de RH do AX. Caso um novo funcionário entre para este departamento, basta adiciona-lo a este grupo no AD e este usuário já terá acesso ao AX com as permissões necessários para executar suas atividades. O mesmo é valido para quando este usuário for desativado no AD, desta forma este já não terá mais acesso ao AX.
As security roles podem ser organizadas hierarquicamente, desta forma podemos definir que uma security role é baseada em outra security role. Por exemplo, a security role pode ser "Gerente de Vendas" pode ser definida como parente da security role "Gerente", desta forma os membros da role "Gerente de Vendas" poderão executar todas as atividades da security role "Gerente".
O Microsoft Dynamics AX2012 já possui secutiry roles pré-definidas, estas podem ser editadas para que se adaptem as necessidades de cada caso, novas security roles também podem ser criadas caso necessário.
Dica de Prova:
O Dynamics AX já possui Security Roles padrões pré-definidas!
Process Cicles.
Proccess Cicles é um conjunto de atividades coordenadas nas quais um ou mais participantes consome, produzem e utilizam recursos econômicos para alcançar o objetivo da organização.
Para ajudar os administradores a localizarem as "duties" que devem ser associadas a roles, as duties foram organizadas por processos das quais elas fazem parte. Por exemplo, no processo (process cicle) de contabilidade você pode encontrar a duties Manter Diários e Manter Transações Bancarias.
Duties.
Duties correspondem a partes de um processo. O administrador deve conceder duties para as secutiry roles, uma duty pode ser concedida a mais de uma security role.
No modelo de segurança para o Microsoft Dynamics AX, duties contem privilégios. Por exemplo, a duty Manter transações bancarias contém os privilégios de Gerar recibos de depósito e Cancelar privilégios de pagamentos. Embora tanto as duties os quantos privilégios podem ser atribuídos às funções de segurança, recomendamos que você use as duties para conceder acesso ao Microsoft Dynamics AX.
Privilegies.
No modelo de segurança para o Microsoft Dynamics AX, um privilégio especifica o nível de acesso que é necessário para realizar um trabalho, resolver um problema, ou completar uma tarefa. Privilégios podem ser atribuídos diretamente a security roles. No entanto, para facilitar a manutenção, recomendamos que você atribua apenas duties a security roles.
Um privilégio contém permissões para objetos individuais de aplicativos, como elementos de interface de usuário e tabelas. Por exemplo, o privilégio Cancelar pagamentos contém permissões para os itens do menu, campos e tabelas que são necessárias para cancelar pagamentos.
Por padrão, os privilégios são fornecidos para todos os recursos do Microsoft Dynamics AX. O administrador pode modificar as permissões que estão associados com um privilégio, ou criar novos privilégios.
Permissions.
Cada função no Microsoft Dynamics AX, como um formulário ou um serviço, é acessado através de um ponto de entrada. Os itens do menu, itens de conteúdo web, e operações de serviços são referidos coletivamente como pontos de entrada.
No modelo de segurança para o Microsoft Dynamics AX, permissões agrupam os objetos que podem ser protegidos e os níveis de acesso que são necessários para executar uma função. Isso inclui todas as tabelas, campos, formulários ou métodos que são acessados através do ponto de entrada.
Apenas os desenvolvedores podem criar ou modificar as permissões. Para mais informações sobre como trabalhar com permissões, consulte a documentação do desenvolvedor do Microsoft Dynamics AX. Esteja ciente de que modificar permissões pode afetar seus requisitos de licenciamento.
Neste post tentei explicar o que significam as Security Roles, Process Cicles, Duties, Privilegies e Permissions no AX2012.
Sugiro que ao ler este post você tente visualizar o conteúdo das funções de segurança no AX2012, isso vai ajudar!
Nos próximos posts vou iniciar uma sequência onde mostrarei como instalar o AX e todos os seus recursos disponíveis esta sequência será longa, mas ficará bem interessante. Depois de termos o AX instalado voltaremos a trabalhar com os usuários e permissões no AX2012!
Nenhum comentário:
Postar um comentário