Guia de conceitos do Microsoft BHOLD Suite

O Microsoft Identity Manager 2016 (MIM) permite que as organizações gerenciem todo o ciclo de vida das identidades de usuário e suas credenciais associadas. Ele pode ser configurado para sincronizar identidades, gerenciar centralmente certificados e senhas e provisionar usuários em sistemas heterogêneos. Com o MIM, as organizações de TI podem definir e automatizar os processos usados para gerenciar identidades desde a criação até a desativação.

O Microsoft BHOLD Suite estende esses recursos do MIM adicionando controle de acesso baseado em função. O BHOLD permite que as organizações definam funções de usuário e controlem o acesso a dados e aplicativos confidenciais. O acesso é baseado no que é apropriado para essas funções. O BHOLD Suite inclui serviços e ferramentas que simplificam a modelagem das relações de função dentro da 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 aplicados corretamente aos usuários. Esses recursos são totalmente integrados ao MIM, fornecendo uma experiência perfeita para usuários finais e funcionários de TI.

Este guia ajuda você a entender como o BHOLD Suite funciona com o MIM e aborda os seguintes tópicos:

• Controle de acesso baseado em função
• Atestado
• Reportagem
• Conector de Gerenciamento de Acesso

O BHOLD não é recomendado para novas implantações. O Microsoft Entra ID agora fornece revisões de acesso, que substituem os recursos da campanha de atestado BHOLD, e gerenciamento de direitos, que substitui os recursos de atribuição de acesso.

Controle de acesso baseado em função

O método mais comum para controlar o acesso do usuário a dados e aplicativos é por meio do DAC (controle de acesso discricionário). Na maioria das implementações comuns, cada objeto significativo tem um proprietário identificado. O proprietário tem a capacidade de conceder ou negar acesso ao objeto a outras pessoas com base em identidade individual ou associação de grupo. Na prática, o DAC normalmente resulta em uma infinidade de grupos de segurança, alguns que refletem a estrutura organizacional, outros que representam agrupamentos funcionais (como tipos de trabalho ou atribuições de projeto) e outros que consistem em coleções improvisadas de usuários e dispositivos vinculados para fins mais temporários. À medida que as organizações crescem, a associação a esses grupos torna-se cada vez mais difícil de gerenciar. Por exemplo, se um funcionário for transferido de um projeto para outro, os grupos usados para controlar o acesso aos ativos de projetos deverão ser atualizados manualmente. Nesses casos, não é incomum que erros ocorram, erros que podem impedir a segurança ou a produtividade do projeto.

O MIM inclui recursos que ajudam a atenuar esse problema fornecendo controle automatizado sobre a associação de grupo e lista de distribuição. No entanto, isso não aborda a complexidade intrínseca de grupos proliferantes que não estão necessariamente relacionados uns aos outros de forma estruturada.

Uma maneira de reduzir significativamente essa proliferação é implantando o RBAC (controle de acesso baseado em função). O RBAC não desloca o DAC. O RBAC baseia-se no DAC fornecendo uma estrutura para classificar usuários e recursos de TI. Isso permite que você torne explícita a relação deles e os direitos de acesso apropriados de acordo com essa classificação. Por exemplo, atribuindo a um usuário atributos que especificam as atribuições de trabalho e projeto dos usuários, o usuário pode receber acesso às ferramentas necessárias para o trabalho do usuário e os dados que o usuário precisa para contribuir para um projeto específico. Quando o usuário assume um trabalho diferente e diferentes atribuições de projeto, alterar os atributos que especificam o cargo do usuário e os projetos bloqueiam automaticamente o acesso aos recursos necessários apenas para a posição anterior dos usuários.

Como as funções podem ser contidas em funções de forma hierárquica, (por exemplo, as funções de gerente de vendas e representante de vendas podem ser contidas na função mais geral de vendas), é fácil atribuir direitos apropriados a funções específicas e ainda fornecer direitos apropriados a todos que compartilham a função mais inclusiva também. Por exemplo, em um hospital, toda a equipe médica poderia ter o direito de ver os registros de um paciente, mas apenas médicos (um subrole da função médica) poderiam receber o direito de inserir prescrições para o paciente. Da mesma forma, os usuários que pertencem à função clerical poderiam ter acesso negado aos registros dos pacientes, exceto para os funcionários de cobrança (um subrole da função clerical), que poderiam ter acesso a essas partes de um registro de pacientes que são obrigados a cobrar o paciente pelos serviços prestados pelo hospital.

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

Objetos de modelos de funções BHOLD

Com o BHOLD Suite, você pode especificar e organizar funções em sua organização, mapear usuários para funções e mapear permissões apropriadas para funções. Essa estrutura é chamada de modelo de função e contém e conecta cinco tipos de objetos:

• Unidades organizacionais
• Usuários
• Funções
• Permissões
• Aplicativos

Unidades organizacionais

As orgUnits (unidades organizacionais) são os principais meios pelos quais os usuários são organizados no modelo de função BHOLD. Cada usuário deve pertencer a pelo menos um OrgUnit. (Na verdade, quando um usuário é removido da última unidade organizacional no BHOLD, o registro de dados do usuário é excluído do banco de dados BHOLD.)

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 à seguinte:

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 mororganizaçãoalganizatinal) ou a unidade organizacional raiz do BHOLD (que sempre existe) poderia ser usada para essa finalidade. OrgUnits que representam as divisões corporativas chefiadas pelos vice-presidentes seriam colocadas na unidade organizacional corporativa. 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 gerentes regionais de vendas seriam colocadas na unidade organizacional do gerente de vendas da região leste. Os associados de vendas, que não gerenciam outros usuários, seriam membros da unidade organizacional do gerente de vendas da região leste. Observe que os usuários podem ser membros de uma unidade organizacional em qualquer nível. Por exemplo, um assistente administrativo, que não é gerente e se reporta diretamente a um vice-presidente, seria membro da unidade organizacional do vice-presidente.

Além de representar a estrutura organizacional, as unidades organizacionais também podem ser usadas para agrupar usuários e outras unidades organizacionais de acordo com critérios funcionais, como para projetos ou especialização. O diagrama a seguir mostra como as unidades organizacionais seriam usadas para agrupar associações de vendas de acordo com o tipo de cliente:

Neste exemplo, cada associado de vendas pertenceria a duas unidades organizacionais: uma representando o lugar do associado na estrutura de gerenciamento da organização e outra representando a base de clientes do associado (varejo ou corporativo). Cada unidade organizacional pode receber funções diferentes que, por sua vez, podem receber permissões diferentes para acessar os recursos de TI da organização. Além disso, os papéis podem ser herdados das unidades organizacionais principais, simplificando o processo de transmissão desses papéis para os usuários. Por outro lado, funções específicas podem ser impedidas de serem herdadas, garantindo que uma função específica esteja associada somente às unidades organizacionais apropriadas.

OrgUnits podem ser criados no BHOLD Suite usando o portal da Web do BHOLD Core.

Usuários

Conforme observado acima, cada usuário deve pertencer a pelo menos uma unidade organizacional (OrgUnit). Como as unidades organizacionais são o principal mecanismo para associar um usuário a funções, na maioria das organizações um determinado usuário pertence a várias OrgUnits para facilitar a associação de funções a esse usuário. Em alguns casos, no entanto, pode ser necessário associar uma função a um usuário além de qualquer OrgUnits ao qual o usuário pertence. Consequentemente, um usuário pode ser atribuído diretamente a uma função, bem como obter funções das OrgUnits às quais o usuário pertence.

Quando um usuário não está ativo dentro da organização (embora esteja ausente para licença médica, por exemplo), o usuário pode ser suspenso, o que revoga todas as permissões do usuário sem remover o usuário do modelo de função. Ao retornar ao dever, o usuário pode ser reativado, o que restaura todas as permissões concedidas pelas funções do usuário.

Os objetos para usuários podem ser criados individualmente no BHOLD por meio do portal da Web do BHOLD Core ou usando o Conector de Gerenciamento de Acesso com o Serviço de Sincronização do FIM para importar informações do usuário de fontes como o Active Directory Domain Services ou aplicativos de recursos humanos.

Os usuários podem ser criados diretamente no BHOLD sem usar o Serviço de Sincronização do FIM. Isso pode ser útil ao modelar funções em um ambiente de pré-produção ou teste. Você também pode permitir que usuários externos (como funcionários de um subcontratado) sejam atribuídos a funções e, portanto, dado acesso aos recursos de TI sem serem adicionados ao banco de dados do funcionário; no entanto, esses usuários não poderão usar os recursos de autoatendimento do BHOLD.

Funções

Conforme observado anteriormente, no modelo RBAC (controle de acesso baseado em função), as permissões são associadas a funções em vez de usuários individuais. Isso possibilita conceder a cada usuário as permissões necessárias para executar as funções do usuário alterando as funções do usuário em vez de conceder ou negar separadamente as permissões do usuário. Como consequência, a atribuição de permissões não requer mais a participação do departamento de TI, mas pode ser executada como parte do gerenciamento do negócio. Uma função pode agregar permissões para acessar sistemas diferentes, diretamente ou por meio do uso de subróles, reduzindo ainda mais a necessidade de envolvimento de TI no gerenciamento de permissões de usuário.

É importante observar que as funções são um recurso do próprio modelo RBAC; normalmente, as funções não são provisionadas para aplicativos de destino. Isso permite que o RBAC seja usado junto com aplicativos existentes que não foram projetados para usar funções ou alterar as definições de função para atender às necessidades de alterar modelos de negócios sem precisar modificar os próprios aplicativos. Se um aplicativo de destino for projetado para usar funções, você poderá associar funções no modelo de função BHOLD com funções de aplicativo correspondentes tratando as funções específicas do aplicativo como permissões.

No BHOLD, você pode atribuir uma função a um usuário principalmente por meio de dois mecanismos:

• Atribuindo uma função a uma unidade organizacional (unidade organizacional) da qual o usuário é membro
• Atribuindo uma função diretamente a um usuário

Opcionalmente, uma função atribuída a uma unidade organizacional pai pode ser herdada por suas unidades organizacionais membros. Quando uma função é atribuída ou herdada por uma unidade organizacional, ela pode ser designada como uma função efetiva ou proposta. Se for uma função efetiva, todos os usuários na unidade organizacional receberão a função. Se for uma função proposta, ela deverá ser ativada para que cada usuário ou unidade organizacional membro se torne eficaz para os membros desse usuário ou da unidade organizacional. Isso possibilita atribuir aos usuários 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 receber datas de início e término, e os limites podem ser colocados no percentual de usuários em uma unidade organizacional para a qual uma função pode ser eficaz.

O diagrama a seguir ilustra como um usuário individual pode receber uma função no BHOLD:

Neste diagrama, a função A é atribuída a uma unidade organizacional como uma função herdável e, portanto, é herdada por suas unidades organizacionais membros e todos os usuários dentro dessas unidades organizacionais. A função B é atribuída como uma função proposta para uma unidade organizacional. Ele deve ser ativado antes que um usuário na unidade organizacional possa ser autorizado com as permissões da função. A função C é uma função efetiva, portanto, suas permissões se aplicam imediatamente a todos os usuários na unidade organizacional. A função D está vinculada diretamente ao usuário e, portanto, suas permissões se aplicam imediatamente a esse usuário.

Além disso, uma função pode ser ativada para um usuário com base nos atributos de um usuário. Para obter mais informações, consulte autorização baseada em atributo.

Permissões

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

As permissões são específicas para aplicativos. O BHOLD fornece uma única exibição unificada de permissões para que as permissões possam ser associadas a funções sem exigir que os gerentes de função entendam os detalhes de implementação das permissões. Na prática, sistemas diferentes podem impor uma permissão de forma diferente. O conector específico de aplicativo do Serviço de Sincronização do FIM para o aplicativo determina como as alterações de permissão para um usuário são transmitidas a esse aplicativo.

Aplicativos

O BHOLD implementa um método para aplicar o RBAC (controle de acesso baseado em função) a aplicativos externos. Ou seja, quando o BHOLD é provisionado com usuários e permissões de um aplicativo, o BHOLD pode associar essas permissões aos usuários atribuindo funções aos usuários e vinculando as permissões às funções. O processo em segundo plano do aplicativo pode mapear as permissões corretas para seus usuários com base no mapeamento de função/permissão no BHOLD.

Desenvolvendo o modelo de função do BHOLD Suite

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

Antes de usar o Gerador de Modelo, você deve criar uma série de arquivos que definem os objetos que o Gerador de Modelo usa para construir o modelo de função. Para obter informações sobre como criar esses arquivos, consulte a Referência Técnica do Microsoft BHOLD Suite.

A primeira etapa no uso do Gerador de Modelos BHOLD é importar esses arquivos para carregar os blocos de construção básicos no Gerador de Modelo. Quando os arquivos tiverem sido carregados com êxito, você poderá especificar os critérios que o Gerador de Modelo usa para criar várias classes de funções:

• Funções de associação atribuídas a um usuário com base nas OrgUnits (unidades organizacionais) às quais o usuário pertence
• Funções de atributo atribuídas a um usuário com base nos atributos do usuário no banco de dados BHOLD
• Funções propostas que estão vinculadas a uma unidade organizacional, mas devem ser ativadas para usuários específicos
• Funções de propriedade que concedem a um usuário controle sobre unidades organizacionais e funções para as quais um proprietário não é especificado nos arquivos importados

Depois que o Gerador de Modelo cria essas funções no modelo de função, você pode exportar o modelo de função para o banco de dados BHOLD na forma de um arquivo XML.

Recursos avançados do BHOLD

Seções anteriores descreveram os recursos básicos do RBAC (controle de acesso baseado em função) no BHOLD. Esta seção descreve recursos adicionais no BHOLD que podem fornecer segurança e flexibilidade aprimoradas para a implementação do RBAC pela sua organização. Esta seção fornece visões gerais dos seguintes recursos do BHOLD:

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

Cardinalidade

Cardinalidade refere-se à implementação de regras de negócios projetadas para limitar o número de vezes que duas entidades podem estar relacionadas umas às outras. No caso do BHOLD, as regras de cardinalidade podem ser estabelecidas para funções, permissões e usuários.

Você pode configurar uma função para limitar o seguinte:

• O número máximo de usuários para os quais uma função proposta pode ser ativada
• O número máximo de subfunções que podem ser vinculadas à função
• O número máximo de permissões que podem ser vinculadas à função

Você pode configurar uma permissão para limitar o seguinte:

• O número máximo de funções que podem ser vinculadas à permissão
• O número máximo de usuários que podem receber a permissão

Você pode configurar um usuário para limitar o seguinte:

• O número máximo de funções que podem ser vinculadas ao usuário
• O número máximo de permissões que podem ser atribuídas ao usuário por meio de atribuições de função

Separação de funções

A separação de funções (SoD) é um princípio de negócios que busca impedir que indivíduos obtenham a capacidade de executar ações que não devem estar disponíveis para uma única pessoa. Por exemplo, um funcionário não deve poder solicitar 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 sua exposição ao risco de erro ou má conduta dos funcionários.

O BHOLD implementa o SoD permitindo que você defina permissões incompatíveis. Quando essas permissões são definidas, o BHOLD impõe o SoD impedindo a criação de funções vinculadas a permissões incompatíveis, sejam elas vinculadas diretamente ou por meio de herança, e impedindo que os usuários sejam atribuídos a várias funções que, quando combinadas, concedem permissões incompatíveis, novamente por atribuição direta ou por meio de herança. Opcionalmente, os conflitos podem ser ignorados.

Permissões adaptáveis ao contexto

Ao criar permissões que podem ser modificadas automaticamente com base em um atributo de objeto, você pode reduzir o número total de permissões que precisa gerenciar. As CAPs (permissões adaptáveis ao contexto) permitem definir uma fórmula como um atributo de permissão que modifica como a permissão é aplicada pelo aplicativo associado à permissão. Por exemplo, você pode criar uma fórmula que altera a permissão de acesso para uma pasta de arquivo (por meio de um grupo de segurança associado à lista de controle de acesso da pasta) com base em se um usuário pertence a uma unidade organizacional (unidade organizacional) que contém funcionários em tempo integral ou contratados. Se o usuário for movido de uma unidade organizacional para outra, a nova permissão será aplicada automaticamente e a permissão antiga será desativada.

A fórmula CAP pode consultar os valores de atributos que foram aplicados a aplicativos, permissões, unidades organizacionais e usuários.

Autorização baseada em atributo

Uma maneira de controlar se uma função vinculada a uma unidade organizacional (unidade organizacional) é ativada para um usuário específico na unidade organizacional é usar a autorização baseada em atributo (ABA). Usando o ABA, você pode ativar automaticamente uma função somente quando determinadas regras com base nos atributos de um usuário forem atendidas. Por exemplo, você pode vincular uma função a uma unidade organizacional que se torna ativa para um usuário somente se o cargo do usuário corresponder ao cargo na regra do ABA. Isso elimina a necessidade de ativar manualmente uma função proposta para um usuário. Em vez disso, uma função pode ser ativada para todos os usuários em uma unidade organizacional que têm um valor de atributo que satisfaça a regra do ABA da função. As regras podem ser combinadas, de modo que uma função seja ativada somente quando os atributos de um usuário atenderem a todas as regras do ABA especificadas para a função.

É importante observar que os resultados dos testes de regra do ABA são limitados por configurações de cardinalidade. Por exemplo, se a configuração de cardinalidade de uma regra especificar que não mais do que dois usuários podem receber uma função e, se uma regra do ABA ativar uma função para quatro usuários, a função será ativada somente para os dois primeiros usuários que passarem no teste do ABA.

Tipos de atributo flexíveis

O sistema de atributos no BHOLD é altamente extensível. Você pode definir novos tipos de atributo para objetos como usuários, unidades organizacionais (unidades organizacionais) e funções. Os atributos podem ser definidos para ter valores inteiros, boolianos (sim/não), alfanuméricos, data, hora e endereços de email. Os atributos podem ser especificados como valores únicos ou uma lista de valores.

Atestado

O BHOLD Suite fornece ferramentas que você pode usar para verificar se usuários individuais receberam permissões apropriadas para realizar suas tarefas comerciais. O administrador pode usar o portal fornecido pelo módulo atestado BHOLD para projetar e gerenciar o processo de atestado.

O processo de atestado é realizado por meio de campanhas nas quais os administradores de campanha têm a oportunidade e os meios para verificar se os usuários pelos quais eles são responsáveis têm acesso apropriado a aplicativos gerenciados pelo BHOLD e permissões corretas dentro desses aplicativos. Um proprietário da campanha é designado para supervisionar a campanha e garantir que a campanha esteja sendo realizada corretamente. Uma campanha pode ser criada para ocorrer uma vez ou em uma base recorrente.

Normalmente, o administrador de uma campanha será um gerente que atestará os direitos de acesso de usuários pertencentes a uma ou mais unidades organizacionais pelas quais o gerente é responsável. Os responsáveis podem ser selecionados automaticamente para os usuários atestados em uma campanha com base em atributos de usuário, ou os responsáveis de uma campanha podem ser definidos listando-os em um arquivo que associa cada usuário atestado na campanha a um responsável.

Quando uma campanha começa, o BHOLD envia uma mensagem de notificação por email para os administradores e proprietários da campanha e 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 usuários para os quais eles são responsáveis e as funções atribuídas a esses usuários. Os administradores podem confirmar se são responsáveis por cada um dos usuários listados e aprovar ou negar os direitos de acesso de cada um dos usuários listados.

Os proprietários da campanha também usam o portal para monitorar o progresso da campanha, e as atividades da campanha são registradas para que os proprietários da campanha possam analisar as ações que foram tomadas durante a campanha.

Reportagem

O módulo relatórios do BHOLD oferece a capacidade de exibir informações no modelo de função por meio de uma variedade de relatórios. O módulo relatórios do BHOLD fornece um amplo conjunto de relatórios internos, além de incluir um assistente que você pode usar para criar relatórios personalizados básicos e avançados. Ao executar um relatório, você pode exibir imediatamente os resultados ou salvar os resultados em um arquivo do Microsoft Excel (.xlsx). Para exibir esse arquivo usando o Microsoft Excel 2000, o Microsoft Excel 2002 ou o Microsoft Excel 2003, você pode baixar e instalar o Pacote de Compatibilidade do Microsoft Office para Formatos de Arquivo do Word, Excel e PowerPoint.

Você usa o módulo relatórios do BHOLD principalmente para produzir relatórios baseados nas informações de função atuais. Para gerar relatórios para auditoria de alterações nas informações de identidade, o Forefront Identity Manager 2010 R2 tem um recurso 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, consulte a documentação do Forefront Identity Manager 2010 e do Forefront Identity Manager 2010 R2 na Biblioteca Técnica do Forefront Identity Management.

As categorias abordadas pelos relatórios internos incluem o seguinte:

• Administração
• Atestado
• Controles
• Controle de acesso interno
• Registrar em log
• Modelo
• Estatísticas
• Fluxo de Trabalho

Você pode criar relatórios e adicioná-los a essas categorias ou definir suas próprias categorias nas quais você pode colocar relatórios personalizados e internos.

À medida que você cria um relatório, o assistente ajuda você a fornecer os seguintes parâmetros:

• Identificando informações, incluindo nome, descrição, categoria, uso e público-alvo
• Campos a serem exibidos no relatório
• Consultas que especificam quais itens devem ser analisados
• Ordem na qual as linhas devem ser classificadas
• Campos usados para dividir o relatório em seções
• Filtros para refinar os elementos retornados no relatório

Em cada estágio do assistente, você pode visualizar o relatório como o definiu até agora e salvá-lo se não precisar especificar parâmetros adicionais. Você também pode voltar às etapas anteriores para modificar os parâmetros que você especificou anteriormente no assistente.

Conector de Gerenciamento de Acesso

O módulo conector de gerenciamento de acesso do BHOLD Suite dá suporte à sincronização inicial e contínua de dados no BHOLD. O Conector de Gerenciamento de Acesso trabalha com o Serviço de Sincronização do FIM para mover dados entre o banco de dados BHOLD Core, o metaverso do MIM e os aplicativos e repositórios de identidade de destino.

As versões anteriores do BHOLD exigiam vários MAs para controlar o fluxo de dados entre o MIM e as tabelas intermediárias do banco de dados BHOLD. No BHOLD Suite SP1, o Conector de Gerenciamento de Acesso permite definir MAs (agentes de gerenciamento) no MIM que fornecem transferência de dados diretamente entre o BHOLD e o MIM.

Próximas etapas

• guia de instalação do BHOLD
• Referência do desenvolvedor BHOLD
• histórico de versões do BHOLD