Guia de Conceitos do Microsoft BHOLD Suite

  • Artigo

Microsoft Identity Manager 2016 (MIM) permite às organizações gerir todo o ciclo de vida das identidades dos utilizadores e as respetivas credenciais associadas. Pode ser configurado para sincronizar identidades, gerir centralmente certificados e palavras-passe e aprovisionar utilizadores em sistemas heterogéneos. Com o MIM, as organizações de TI podem definir e automatizar os processos utilizados para gerir identidades desde a criação até à descontinuação.

O Microsoft BHOLD Suite expande estas capacidades do MIM ao adicionar controlo de acesso baseado em funções. O BHOLD permite que as organizações definam funções de utilizador e controlem o acesso a dados e aplicações confidenciais. O acesso baseia-se no que é adequado para essas funções. O BHOLD Suite inclui serviços e ferramentas que simplificam a modelação das relações de função na organização. O BHOLD mapeia essas funções para direitos e para verificar se as definições de função e os direitos associados são corretamente aplicados aos utilizadores. Estas capacidades estão totalmente integradas no MIM, proporcionando uma experiência totalmente integrada tanto para os utilizadores finais como para a equipa de TI.

Este guia ajuda-o a compreender como o BHOLD Suite funciona com o MIM e aborda os seguintes tópicos:

  • Controlo de acesso baseado em funções
  • Atestado
  • Relatórios
  • Conector de Gestão de Acesso

O BHOLD não é recomendado para novas implementações. Microsoft Entra ID fornece agora revisões de acesso, que substitui as funcionalidades de campanha de atestado BHOLD e a gestão de direitos, que substitui as funcionalidades de atribuição de acesso.

Controlo de acesso baseado em funções

O método mais comum para controlar o acesso dos utilizadores a dados e aplicações é através do controlo de acesso discricionário (DAC). Nas implementações mais comuns, cada objeto significativo tem um proprietário identificado. O proprietário tem a capacidade de conceder ou negar o acesso ao objeto a outras pessoas com base na identidade individual ou na associação a grupos. Na prática, o DAC normalmente resulta numa panóplia de grupos de segurança, alguns que refletem a estrutura organizacional, outros que representam agrupamentos funcionais (como tipos de trabalho ou atribuições de projetos) e outros que consistem em coleções improvisadas de utilizadores e dispositivos que estão ligados para fins mais temporários. À medida que as organizações crescem, a associação a estes grupos torna-se cada vez mais difícil de gerir. Por exemplo, se um funcionário for transferido de um projeto para outro, os grupos que são utilizados para controlar o acesso aos recursos dos projetos têm de ser atualizados manualmente. Nestes casos, não é incomum que ocorram erros, erros que podem impedir a segurança ou produtividade do projeto.

O MIM inclui funcionalidades que ajudam a mitigar este problema ao fornecer controlo automatizado sobre a associação a grupos e listas de distribuição. No entanto, isto não aborda a complexidade intrínseca de grupos proliferadores que não estão necessariamente relacionados entre si de forma estruturada.

Uma forma de reduzir significativamente esta proliferação é através da implementação do controlo de acesso baseado em funções (RBAC). O RBAC não desloca o DAC. O RBAC baseia-se no DAC ao fornecer uma arquitetura para classificar utilizadores e recursos de TI. Isto permite-lhe explicitar a relação deles e os direitos de acesso adequados de acordo com essa classificação. Por exemplo, ao atribuir a um utilizador atributos que especifiquem o cargo de utilizador e as atribuições de projeto, pode ser concedido ao utilizador acesso às ferramentas necessárias para o trabalho do utilizador e aos dados que o utilizador precisa de contribuir para um projeto específico. Quando o utilizador assume uma tarefa diferente e atribuições de projeto diferentes, alterar os atributos que especificam o cargo do utilizador e os projetos bloqueiam automaticamente o acesso aos recursos apenas necessários para a posição anterior dos utilizadores.

Uma vez que as funções podem ser contidas em funções de forma hierárquica(por exemplo, as funções de gestor de vendas e representante de vendas podem ser contidas na função mais geral das vendas), é fácil atribuir direitos adequados a funções específicas e ainda assim fornecer direitos adequados a todos os que partilham o papel mais inclusivo também. Por exemplo, num hospital, todo o pessoal médico poderia ter o direito de ver os registos de um paciente, mas apenas os médicos (uma subrole da função médica) poderiam ter o direito de introduzir receitas para o paciente. Da mesma forma, os utilizadores pertencentes à função clerical poderiam ser impedidos de aceder aos registos dos pacientes, exceto aos escriturários de faturação (uma subrólea da função clerical), a quem poderia ser concedido acesso às partes de um registo de pacientes que são necessários para cobrar ao paciente os serviços prestados pelo hospital.

Um benefício adicional do RBAC é a capacidade de definir e impor a separação de deveres (SoD). Isto permite que uma organização defina combinações de funções que concedem permissões que não devem ser mantidas pelo mesmo utilizador, para que um determinado utilizador não possa receber funções que permitam ao utilizador iniciar um pagamento e autorizar um pagamento, por exemplo. O RBAC fornece a capacidade de impor essa política automaticamente em vez de ter de avaliar a implementação efetiva da política por utilizador.

Objetos de modelo de função BHOLD

Com o BHOLD Suite, pode especificar e organizar funções na sua organização, mapear utilizadores para funções e mapear as permissões adequadas para funções. Esta estrutura é denominada modelo de função e contém e liga cinco tipos de objetos:

  • Unidades organizacionais
  • Utilizadores
  • Funções
  • Permissões
  • Aplicações

Unidades organizacionais

As unidades organizacionais (OrgUnits) são o principal meio pelo qual os utilizadores estão organizados no modelo de função BHOLD. Cada utilizador tem de pertencer a, pelo menos, uma OrgUnit. (Na verdade, quando um utilizador é removido da última unidade organizacional no BHOLD, o registo de dados do utilizador é eliminado da base de dados BHOLD.)

Importante

As unidades organizacionais no modelo de função BHOLD não devem ser confundidas com unidades organizacionais no Active Directory Domain Services (AD DS). Normalmente, a estrutura da unidade organizacional no BHOLD baseia-se na organização e nas políticas da sua empresa e não nos requisitos da sua infraestrutura de rede.

Embora não seja necessário, na maioria dos casos as unidades organizacionais são estruturadas no BHOLD para representar a estrutura hierárquica da organização real, semelhante à abaixo:

exemplo de organograma

Neste exemplo, o modelo de função seria uma unidade organizacional para a corporação como um todo (representada pelo presidente, porque o presidente não faz parte de uma unidade mororganizationalganizatinal), ou a unidade organizacional de raiz BHOLD (que sempre existe) poderia ser utilizada para esse fim. As organizações que representam as divisões empresariais chefiadas pelos vice-presidentes seriam colocadas na unidade organizacional empresarial. Em seguida, as unidades organizacionais correspondentes aos diretores de marketing e vendas seriam adicionadas às unidades organizacionais de marketing e vendas e as unidades organizacionais que representam os gestores de vendas regionais seriam colocadas na unidade organizacional do gestor de vendas da região leste. Os associados de vendas, que não gerem outros utilizadores, tornar-se-iam membros da unidade organizacional do gestor de vendas da região leste. Tenha em atenção que os utilizadores podem ser membros de uma unidade organizacional em qualquer nível. Por exemplo, uma assistente administrativa, que não é gerente e reporta diretamente a um vice-presidente, seria membro da unidade organizacional do vice-presidente.

Além de representarem a estrutura organizacional, as unidades organizacionais também podem ser utilizadas para agrupar utilizadores e outras unidades organizacionais de acordo com critérios funcionais, como para projetos ou especialização. O diagrama seguinte mostra como as unidades organizacionais seriam utilizadas para agrupar os associados de vendas de acordo com o tipo de cliente:

organização de projeto de exemplo

Neste exemplo, cada associado de vendas pertenceria a duas unidades organizacionais: uma que representa o lugar do associado na estrutura de gestão da organização e outra que representa a base de clientes do associado (retalho ou empresa). Cada unidade organizacional pode ser atribuída a diferentes funções que, por sua vez, podem ser atribuídas permissões diferentes para aceder aos recursos de TI da organização. Além disso, as funções podem ser herdadas de unidades organizacionais principais, simplificando o processo de propagação de funções para os utilizadores. Por outro lado, as funções específicas podem ser impedidas de serem herdadas, garantindo que uma função específica está associada apenas às unidades organizacionais adequadas.

As orgUnits podem ser criadas no BHOLD Suite com o portal Web BHOLD Core.

Utilizadores

Conforme indicado acima, todos os utilizadores têm de pertencer a, pelo menos, uma unidade organizacional (OrgUnit). Uma vez que as unidades organizacionais são o mecanismo principal para associar um utilizador a funções, na maioria das organizações um determinado utilizador pertence a várias OrganizaçõesUnits para facilitar a associação de funções a esse utilizador. No entanto, em alguns casos, pode ser necessário associar uma função a um utilizador para além de quaisquer OrgUnits a que o utilizador pertença. Consequentemente, um utilizador pode ser atribuído diretamente a uma função, bem como obter funções das OrgUnits às quais o utilizador pertence.

Quando um utilizador não está ativo na organização (enquanto estiver ausente para licença médica, por exemplo), o utilizador pode ser suspenso, o que revoga todas as permissões do utilizador sem remover o utilizador do modelo de função. Ao regressar ao serviço, o utilizador pode ser reativado, o que restaura todas as permissões concedidas pelas funções do utilizador.

Os objetos para utilizadores podem ser criados individualmente no BHOLD através do portal Web BHOLD Core ou através do Access Management Connector com o Serviço de Sincronização do FIM para importar informações de utilizadores de origens como Active Directory Domain Services ou aplicações de recursos humanos.

Os utilizadores podem ser criados diretamente no BHOLD sem utilizar o Serviço de Sincronização do FIM. Isto pode ser útil ao modelar funções num ambiente de pré-produção ou teste. Também pode permitir que os utilizadores externos (como funcionários de um subcontratante) sejam atribuídos funções e, assim, terem acesso aos recursos de TI sem serem adicionados à base de dados dos funcionários; no entanto, estes utilizadores não poderão utilizar as funcionalidades de gestão personalizada do BHOLD.

Funções

Como indicado anteriormente, no modelo de controlo de acesso baseado em funções (RBAC), as permissões estão associadas a funções e não a utilizadores individuais. Isto permite dar a cada utilizador as permissões necessárias para desempenhar as funções do utilizador ao alterar as funções do utilizador em vez de conceder ou negar separadamente as permissões de utilizador. Como consequência, a atribuição de permissões já não requer a participação do departamento de TI, mas pode ser realizada como parte da gestão da empresa. Uma função pode agregar permissões para aceder a diferentes sistemas, diretamente ou através da utilização de subroles, reduzindo ainda mais a necessidade de envolvimento de TI na gestão de permissões de utilizador.

É importante ter em atenção que as funções são uma funcionalidade do próprio modelo RBAC; normalmente, as funções não são aprovisionadas para aplicações de destino. Isto permite que o RBAC seja utilizado juntamente com as aplicações existentes que não foram concebidas para utilizar funções ou para alterar as definições de função para satisfazer as necessidades de alterar modelos de negócio sem ter de modificar as próprias aplicações. Se uma aplicação de destino for concebida para utilizar funções, pode associar funções no modelo de função BHOLD às funções de aplicação correspondentes ao tratar as funções específicas da aplicação como permissões.

No BHOLD, pode atribuir uma função a um utilizador principalmente através de dois mecanismos:

  • Ao atribuir uma função a uma unidade organizacional (unidade organizacional) da qual o utilizador é membro
  • Ao atribuir uma função diretamente a um utilizador

Opcionalmente, uma função atribuída a uma unidade organizacional principal pode ser herdada pelas unidades organizacionais membros. Quando uma função é atribuída ou herdada por uma unidade organizacional, pode ser designada como uma função eficaz ou proposta. Se for uma função eficaz, é atribuída a função a todos os utilizadores na unidade organizacional. Se for uma função proposta, tem de ser ativada para que cada utilizador ou unidade organizacional membro se torne eficaz para os membros desse utilizador ou unidade organizacional. Isto permite atribuir aos utilizadores um subconjunto das funções associadas a uma unidade organizacional, em vez de atribuir automaticamente todas as funções da unidade organizacional a todos os membros. Além disso, as funções podem ser dadas datas de início e de fim e podem ser colocados limites na percentagem de utilizadores numa unidade organizacional para a qual uma função pode ser eficaz.

O diagrama seguinte ilustra como um utilizador individual pode ser atribuído a uma função no BHOLD:

atribuição de função

Neste diagrama, a função A é atribuída a uma unidade organizacional como uma função herdável, pelo que é herdada pelas unidades organizacionais membros e por todos os utilizadores nessas unidades organizacionais. A função B é atribuída como uma função proposta para uma unidade organizacional. Tem de ser ativado antes de um utilizador na unidade organizacional poder ser autorizado com as permissões da função. A função C é uma função efetiva, pelo que as respetivas permissões aplicam-se imediatamente a todos os utilizadores na unidade organizacional. A função D está ligada diretamente ao utilizador e, por isso, as respetivas permissões aplicam-se imediatamente a esse utilizador.

Além disso, uma função pode ser ativada para um utilizador com base nos atributos de um utilizador. Para obter mais informações, veja Autorização baseada em atributos.

Permissões

Uma permissão no BHOLD corresponde a uma autorização importada de uma aplicação de destino. Ou seja, quando o BHOLD está configurado para funcionar com uma aplicação, recebe uma lista de autorizações que o BHOLD pode ligar a funções. Por exemplo, quando Active Directory Domain Services (AD DS) é adicionado ao BHOLD como uma aplicação, recebe uma lista de grupos de segurança que, como permissões BHOLD, podem ser ligados a funções no BHOLD.

As permissões são específicas das aplicações. O BHOLD fornece uma vista única e unificada de permissões para que as permissões possam ser associadas a funções sem exigir que os gestores de funções compreendam os detalhes de implementação das permissões. Na prática, diferentes sistemas podem impor uma permissão de forma diferente. O conector específico da aplicação do Serviço de Sincronização do FIM para a aplicação determina como as alterações de permissão para um utilizador são fornecidas a essa aplicação.

Aplicações

O BHOLD implementa um método para aplicar o controlo de acesso baseado em funções (RBAC) a aplicações externas. Ou seja, quando o BHOLD é aprovisionado com utilizadores e permissões de uma aplicação, o BHOLD pode associar essas permissões aos utilizadores ao atribuir funções aos utilizadores e, em seguida, associar as permissões às funções. Em seguida, o processo em segundo plano da aplicação pode mapear as permissões corretas para os utilizadores com base no mapeamento de funções/permissões no BHOLD.

Desenvolver o modelo de função do BHOLD Suite

Para o ajudar a desenvolver o seu modelo de função, o BHOLD Suite fornece o Gerador de Modelos, uma ferramenta que é fácil de utilizar e abrangente.

Antes de utilizar o Gerador de Modelos, tem de criar uma série de ficheiros que definem os objetos que o Gerador de Modelos utiliza para construir o modelo de função. Para obter informações sobre como criar estes ficheiros, consulte Referência Técnica do Microsoft BHOLD Suite.

O primeiro passo na utilização do Gerador de Modelos BHOLD é importar estes ficheiros para carregar os blocos modulares básicos para o Gerador de Modelos. Quando os ficheiros tiverem sido carregados com êxito, pode especificar critérios que o Gerador de Modelos utiliza para criar várias classes de funções:

  • Funções de associação atribuídas a um utilizador com base nas Organizações (unidades organizacionais) às quais o utilizador pertence
  • Funções de atributo atribuídas a um utilizador com base nos atributos do utilizador na base de dados BHOLD
  • Funções propostas associadas a uma unidade organizacional, mas que têm de ser ativadas para utilizadores específicos
  • Funções de propriedade que concedem a um utilizador controlo sobre unidades organizacionais e funções para as quais um proprietário não é especificado nos ficheiros importados

Importante

Ao carregar ficheiros, selecione a caixa de verificação Reter Modelo Existente apenas em ambientes de teste. Nos ambientes de produção, tem de utilizar o Gerador de Modelos para criar o modelo de função inicial. Não pode utilizá-lo para modificar um modelo de função existente na base de dados BHOLD.

Depois de o Gerador de Modelos criar estas funções no modelo de função, pode exportar o modelo de função para a base de dados BHOLD na forma de um ficheiro XML.

Funcionalidades avançadas do BHOLD

As secções anteriores descreveram as funcionalidades básicas do controlo de acesso baseado em funções (RBAC) no BHOLD. Esta secção descreve funcionalidades adicionais no BHOLD que podem proporcionar maior segurança e flexibilidade à implementação do RBAC pela sua organização. Esta secção fornece uma descrição geral das seguintes funcionalidades do BHOLD:

  • Cardinalidade
  • Separação de deveres
  • Permissões adaptáveis ao contexto
  • Autorização baseada em atributos
  • Tipos de atributo flexíveis

Cardinalidade

Cardinalidade refere-se à implementação de regras empresariais concebidas para limitar o número de vezes que duas entidades podem estar relacionadas entre si. No caso do BHOLD, podem ser estabelecidas regras de cardinalidade para funções, permissões e utilizadores.

Pode configurar uma função para limitar o seguinte:

  • O número máximo de utilizadores para o qual uma função proposta pode ser ativada
  • O número máximo de subroles que podem ser ligados à função
  • O número máximo de permissões que podem ser associadas à função

Pode configurar uma permissão para limitar o seguinte:

  • O número máximo de funções que podem ser associadas à permissão
  • O número máximo de utilizadores a quem é concedida a permissão

Pode configurar um utilizador para limitar o seguinte:

  • O número máximo de funções que podem ser ligadas ao utilizador
  • O número máximo de permissões que podem ser atribuídas ao utilizador através de atribuições de funções

Separação de deveres

A separação de deveres (SoD) é um princípio empresarial que procura impedir que os indivíduos obtenham a capacidade de realizar ações que não devem estar disponíveis para uma única pessoa. Por exemplo, um funcionário não deve poder pedir um pagamento e autorizar o pagamento. O princípio do SoD permite que as organizações implementem um sistema de verificações e saldos para minimizar a sua exposição ao risco devido a erro ou má conduta dos colaboradores.

O BHOLD implementa o SoD ao permitir-lhe definir permissões incompatíveis. Quando estas permissões são definidas, o BHOLD impõe o SoD ao impedir a criação de funções ligadas a permissões incompatíveis, quer estejam ligadas diretamente ou através da herança, e ao impedir que os utilizadores sejam atribuídos a múltiplas funções que, quando combinadas, concederiam permissões incompatíveis, novamente por atribuição direta ou por herança. Opcionalmente, os conflitos podem ser substituídos.

Permissões adaptáveis ao contexto

Ao criar permissões que podem ser modificadas automaticamente com base num atributo de objeto, pode reduzir o número total de permissões que tem de gerir. As permissões adaptáveis ao contexto (CAPs) permitem-lhe definir uma fórmula como um atributo de permissão que modifica a forma como a permissão é aplicada pela aplicação associada à permissão. Por exemplo, pode criar uma fórmula que altera a permissão de acesso a uma pasta de ficheiros (através de um grupo de segurança associado à lista de controlo de acesso da pasta) com base no facto de um utilizador pertencer a uma unidade organizacional (unidade organizacional) que contenha funcionários a tempo inteiro ou contratados. Se o utilizador for movido de uma unidade organizacional para outra, a nova permissão é aplicada automaticamente e a permissão antiga é desativada.

A fórmula CAP pode consultar os valores dos atributos que foram aplicados a aplicações, permissões, unidades organizacionais e utilizadores.

Autorização baseada em atributos

Uma forma de controlar se uma função ligada a uma unidade organizacional (unidade organizacional) é ativada para um determinado utilizador na unidade organizacional é utilizar a autorização baseada em atributos (ABA). Ao utilizar o ABA, só pode ativar automaticamente uma função quando determinadas regras baseadas nos atributos de um utilizador forem cumpridas. Por exemplo, pode associar uma função a uma unidade organizacional que fica ativa apenas para um utilizador se o cargo do utilizador corresponder ao título da tarefa na regra ABA. Isto elimina a necessidade de ativar manualmente uma função proposta para um utilizador. Em vez disso, uma função pode ser ativada para todos os utilizadores numa unidade organizacional que tenham um valor de atributo que satisfaça a regra ABA da função. As regras podem ser combinadas, para que uma função seja ativada apenas quando os atributos de um utilizador satisfazem todas as regras ABA especificadas para a função.

É importante ter em atenção que os resultados dos testes de regras do ABA estão limitados pelas definições de cardinalidade. Por exemplo, se a definição de cardinalidade de uma regra especificar que não pode ser atribuída uma função a mais de dois utilizadores e se uma regra ABA ativar uma função para quatro utilizadores, a função será ativada apenas para os dois primeiros utilizadores que passarem no teste ABA.

Tipos de atributo flexíveis

O sistema de atributos no BHOLD é altamente extensível. Pode definir novos tipos de atributos para objetos como utilizadores, unidades organizacionais (unidades organizacionais) e funções. Os atributos podem ser definidos para ter valores que são números inteiros, booleanos (sim/não), endereços alfanuméricos, de data, hora e de e-mail. Os atributos podem ser especificados como valores únicos ou uma lista de valores.

Atestado

O BHOLD Suite fornece ferramentas que pode utilizar para verificar se foram concedidas permissões adequadas a utilizadores individuais para realizarem as suas tarefas empresariais. O administrador pode utilizar o portal fornecido pelo módulo Atestado BHOLD para conceber e gerir o processo de atestado.

O processo de atestado é realizado através de campanhas em que os administradores de campanha têm a oportunidade e os meios para verificar se os utilizadores pelos quais são responsáveis têm acesso adequado às aplicações geridas pelo BHOLD e as permissões corretas nessas aplicações. Um proprietário de campanha é designado para supervisionar a campanha e garantir que a campanha está a ser realizada corretamente. Uma campanha pode ser criada para ocorrer uma vez ou de forma periódica.

Normalmente, o administrador de uma campanha será um gestor que irá atestar os direitos de acesso dos utilizadores pertencentes a uma ou mais unidades organizacionais pelas quais o gestor é responsável. Os administradores podem ser selecionados automaticamente para os utilizadores que estão a ser atestados numa campanha com base em atributos de utilizador ou os administradores de uma campanha podem ser definidos ao listá-los num ficheiro que mapeia todos os utilizadores a serem atestados na campanha para um administrador.

Quando uma campanha começa, a BHOLD envia uma mensagem de notificação por e-mail aos administradores e proprietários da campanha e, em seguida, envia lembretes periódicos para ajudá-los a manter o progresso na campanha. Os administradores são direcionados para um portal de campanha onde podem ver uma lista dos utilizadores pelos quais são responsáveis e as funções atribuídas a esses utilizadores. Os administradores podem então confirmar se são responsáveis por cada um dos utilizadores listados e aprovar ou negar os direitos de acesso de cada um dos utilizadores listados.

Os proprietários de campanha também usam o portal para monitorizar o progresso da campanha, e as atividades de campanha são registadas para que os proprietários da campanha possam analisar as ações que foram realizadas no decorrer da campanha.

Relatórios

O módulo BHOLD Reporting dá-lhe a capacidade de ver informações no modelo de função através de uma variedade de relatórios. O módulo BHOLD Reporting fornece um vasto conjunto de relatórios incorporados, além de incluir um assistente que pode utilizar para criar relatórios personalizados básicos e avançados. Quando executa um relatório, pode apresentar imediatamente os resultados ou guardar os resultados num ficheiro do Microsoft Excel (.xlsx). Para ver este ficheiro com o Microsoft Excel 2000, Microsoft Excel 2002 ou Microsoft Excel 2003, pode transferir e instalar o Microsoft Office Compatibility Pack para formatos de ficheiro do Word, Excel e PowerPoint.

Utiliza principalmente o módulo BHOLD Reporting para produzir relatórios baseados em informações de função atuais. Para relatórios gerados para auditoria de alterações às informações de identidade, o Forefront Identity Manager 2010 R2 tem uma capacidade de relatório para o Serviço FIM que é implementado no System Center Service Manager Data Warehouse. Para obter mais informações sobre relatórios do FIM, veja a documentação do Forefront Identity Manager 2010 e forefront Identity Manager 2010 R2 na Biblioteca Técnica do Forefront Identity Management.

As categorias abrangidas pelos relatórios incorporados incluem o seguinte:

  • Administração
  • Atestado
  • Controlos
  • Controlo de Acesso para dentro
  • Registo
  • Modelação
  • Estatísticas
  • Fluxo de trabalho

Pode criar relatórios e adicioná-los a estas categorias ou pode definir as suas próprias categorias nas quais pode colocar relatórios personalizados e incorporados.

À medida que cria um relatório, o assistente orienta-o ao longo do fornecimento dos seguintes parâmetros:

  • Identificar informações, incluindo nome, descrição, categoria, utilização e audiência
  • Campos a apresentar no relatório
  • Consultas que especificam que itens devem ser analisados
  • Ordem pela qual as linhas devem ser ordenadas
  • Campos utilizados para dividir o relatório em secções
  • Filtra para refinar os elementos que são devolvidos no relatório

Em cada fase do assistente, pode pré-visualizar o relatório tal como o definiu até agora e guardá-lo se não precisar de especificar parâmetros adicionais. Também pode voltar aos passos anteriores para alterar os parâmetros que especificou anteriormente no assistente.

Conector de Gestão do Access

O módulo BHOLD Suite Access Management Connector suporta a sincronização inicial e contínua de dados no BHOLD. O Access Management Connector funciona com o Serviço de Sincronização do FIM para mover dados entre a base de dados BHOLD Core, o metaverso do MIM e as aplicações de destino e arquivos de identidade.

As versões anteriores do BHOLD exigiam vários MAs para controlar o fluxo de dados entre o MIM e as tabelas de bases de dados BHOLD intermédias. No BHOLD Suite SP1, o Access Management Connector permite-lhe definir agentes de gestão (MAs) no MIM que fornecem a transferência de dados diretamente entre o BHOLD e o MIM.

Passos seguintes