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 dos usuários 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 aposentadoria.

O Microsoft BHOLD Suite amplia 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. BHOLD mapeia essas funções para direitos e para verificar se as definições de função e direitos associados são corretamente aplicados aos usuários. Esses recursos são totalmente integrados ao MIM, proporcionando uma experiência perfeita tanto para os usuários finais quanto para a equipe de TI.

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

• Controlo de acesso baseado em funções
• Atestado
• Apresentação de relatórios
• Conector de gerenciamento de acesso

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

Controlo de acesso baseado em funções

O método mais comum para controlar o acesso do usuário a dados e aplicativos é por meio do controle 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 acesso ao objeto a outras pessoas com base na identidade individual ou na associação ao 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 que são vinculados para fins mais temporários. À medida que as organizações crescem, a pertença 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 usados para controlar o acesso aos ativos do projeto deverão ser atualizados manualmente. Nesses casos, não é incomum que ocorram erros, erros que podem prejudicar a segurança ou a produtividade do projeto.

O MIM inclui recursos que ajudam a mitigar esse problema, fornecendo controle automatizado sobre a associação a grupos e listas de distribuição. No entanto, isso não aborda a complexidade intrínseca da proliferação de grupos que não estão necessariamente relacionados entre si de forma estruturada.

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

Como as funções podem estar contidas nas funções de forma hierárquica (por exemplo, as funções de gerente de vendas e representante de vendas podem estar contidas na função mais geral de vendas), é fácil atribuir direitos apropriados a funções específicas e, ainda assim, fornecer direitos apropriados a todos que compartilham a função mais inclusiva 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 subfunção da função médica) poderiam ter o direito de introduzir prescrições para o doente. Da mesma forma, os usuários pertencentes à função de escriturário poderiam ter acesso negado aos registros de pacientes, exceto para os funcionários de faturamento (uma subfunção da função de escritório), que poderiam ter acesso às partes de um registro de pacientes que são necessárias para faturar o paciente pelos serviços prestados pelo hospital.

Um benefício adicional do RBAC é a capacidade de definir e aplicar a separação de funções (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, de modo que um determinado usuário não possa receber funções que permitam ao usuário iniciar um pagamento e autorizar um pagamento, por exemplo. O RBAC oferece a capacidade de aplicar essa política automaticamente, em vez de ter que avaliar a implementação efetiva da política por usuário.

Objetos de modelo de função BHOLD

Com o BHOLD Suite, você pode especificar e organizar funções dentro de 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
• Utilizadores
• Funções
• Permissões
• Aplicações

Unidades organizacionais

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

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

Nesta amostra, o modelo seria a unidade organizacional para a corporação como um todo (representada pelo presidente, porque o presidente não faz parte de uma unidade organizacional mãe), ou a unidade organizacional raiz BHOLD (que sempre existe) poderia ser usada para esse fim. Unidades Organizacionais representando as divisões corporativas chefiadas pelos vice-presidentes serão colocadas na Unidade Organizacional Central. 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 representando os gerentes regionais de vendas seriam colocadas na unidade organizacional para o gerente de vendas da região leste. Os vendedores, que não gerenciam outros usuários, seriam tornados 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 é um gerente e se reporta diretamente a um vice-presidente, seria um 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 os associados 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 gestão da organização e outra representando a base de clientes do associado (varejo ou corporativo). A cada unidade organizacional podem ser atribuídas diferentes funções que, por sua vez, podem ser atribuídas diferentes permissões para acessar os recursos de TI da organização. Além disso, as funções podem ser herdadas das unidades organizacionais mãe, simplificando o processo de propagação de funções para os utilizadores. Por outro lado, funções específicas podem ser impedidas de serem herdadas, garantindo que uma função específica seja associada apenas às unidades organizacionais apropriadas.

As OrgUnits podem ser criadas no BHOLD Suite usando o portal Web BHOLD Core.

Utilizadores

Como mencionado 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 quaisquer OrgUnits às quais o usuário pertença. 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 (enquanto está 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 serviço, 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 BHOLD Core ou usando o Access Management Connector com o Serviço de Sincronização do FIM para importar informações do usuário de fontes como Serviços de Domínio Ative Directory 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) recebam funções e, assim, tenham acesso aos recursos de TI sem serem adicionados ao banco de dados de funcionários; no entanto, esses usuários não poderão usar os recursos de autoatendimento BHOLD.

Funções

Como 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 torna possível dar a cada usuário as permissões necessárias para executar as tarefas 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 realizada como parte do gerenciamento do negócio. Uma função pode agregar permissões para acessar diferentes sistemas, diretamente ou por meio do uso de subfunções, reduzindo ainda mais a necessidade de envolvimento de TI no gerenciamento de permissões de usuários.

É importante notar que os papéis são uma característica 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 ao lado de aplicativos existentes que não são projetados para usar funções ou para alterar as definições de função para atender às necessidades de mudança de modelos de negócios sem ter que 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.

Em 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

Uma função atribuída a uma unidade organizacional pai pode opcionalmente ser herdada pelas 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 deve ser ativada para que cada usuário ou unidade organizacional membro se torne efetiva para os membros desse usuário ou unidade organizacional. Isso torna possível 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 limites podem ser colocados na porcentagem de usuários dentro de 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 hereditária 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 eficaz, portanto, suas permissões se aplicam imediatamente a todos os usuários da 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 atributos.

Permissões

Uma permissão em BHOLD corresponde a uma autorização importada de um aplicativo de destino. Ou seja, quando o BHOLD é configurado para trabalhar com um aplicativo, ele recebe uma lista de autorizações que o BHOLD pode vincular a funções. Por exemplo, quando os Serviços de Domínio do Active Directory (AD DS) são adicionados ao BHOLD como um aplicativo, ele recebe uma lista de grupos de segurança que, como permissões do BHOLD, podem ser vinculados a funções no BHOLD.

As permissões são específicas para aplicativos. O BHOLD fornece uma visão única e unificada das 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 da aplicação do Serviço de Sincronização FIM para a aplicação determina como as alterações de permissão para um utilizador são transmitidas a essa aplicação.

Aplicações

BHOLD implementa um método para aplicar controle de acesso baseado em função (RBAC) para aplicativos externos. Ou seja, quando BHOLD é provisionado com usuários e permissões de um aplicativo, BHOLD pode associar essas permissões aos usuários atribuindo funções aos usuários e, em seguida, vinculando as permissões às funções. O processo em segundo plano do aplicativo pode então 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ções do pacote BHOLD Suite

Para ajudá-lo a desenvolver seu modelo, o BHOLD Suite fornece o Model Generator, uma ferramenta 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 Referência técnica do Microsoft BHOLD Suite.

A primeira etapa no uso do BHOLD Model Generator é importar esses arquivos para carregar os blocos de construção básicos no Model Generator. 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 criar essas funções no modelo de função, você poderá exportá-lo para o banco de dados BHOLD na forma de um arquivo XML.

Recursos avançados do BHOLD

As seções anteriores descreveram os recursos básicos do controle de acesso baseado em função (RBAC) 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 BHOLD:

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

Cardinalidade

Cardinalidade refere-se à implementação de regras de negócios que são projetadas para limitar o número de vezes que duas entidades podem estar relacionadas entre si. No caso de BHOLD, 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 empresarial que procura impedir que os indivíduos ganhem a capacidade de realizar ações que não deveriam 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 da SoD permite que as organizações implementem um sistema de freios e contrapesos para minimizar sua exposição ao risco de erro ou má conduta dos funcionários.

BHOLD implementa SoD permitindo que você defina permissões incompatíveis. Quando essas permissões são definidas, o BHOLD impõe a SoD impedindo a criação de funções vinculadas a permissões incompatíveis, sejam elas vinculadas diretamente ou por herança, e impedindo que os usuários recebam várias funções que, quando combinadas, concederiam permissões incompatíveis, novamente por atribuição direta ou por 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 permissões adaptáveis ao contexto (CAPs) 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, pode criar uma fórmula que altere 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 contém funcionários a tempo inteiro 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 atributos

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 atributos (ABA). Usando o ABA, você pode ativar automaticamente uma função somente quando determinadas regras baseadas 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 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 tenham um valor de atributo que satisfaça a regra 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 satisfizerem todas as regras ABA especificadas para a função.

É importante notar que os resultados dos testes de regra ABA são limitados pelas 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 ABA ativar uma função para quatro usuários, a função será ativada apenas para os dois primeiros usuários que passarem no teste ABA.

Tipos de atributos flexíveis

O sistema de atributos em BHOLD é altamente extensível. Você pode definir novos tipos de atributos para objetos como usuários, unidades organizacionais (unidades organizacionais) e funções. Os atributos podem ser definidos para ter valores inteiros, booleanos (sim/não), alfanuméricos, data, hora e endereços de e-mail. 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 de negócios. O administrador pode usar o portal fornecido pelo módulo de atestado BHOLD para projetar e gerenciar o processo de atestado.

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

Normalmente, o administrador de uma campanha será um gerente que atestará os direitos de acesso dos usuários pertencentes a uma ou mais unidades organizacionais pelas quais o gerente é responsável. Os stewards podem ser selecionados automaticamente para os utilizadores que estão a ser atestados numa campanha com base nos atributos do utilizador, ou os stewards de uma campanha podem ser definidos listando-os num ficheiro que mapeia cada utilizador a ser atestado na campanha a um steward.

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 da campanha. Os administradores são direcionados para um portal de campanha, onde podem ver uma lista dos usuários pelos quais são responsáveis e as funções atribuídas a esses usuários. Os administradores podem então 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 no decorrer da campanha.

Apresentação de relatórios

O módulo BHOLD Reporting oferece a capacidade de visualizar informações no modelo de função por meio de uma variedade de relatórios. O módulo BHOLD Reporting fornece um extenso 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. Quando você executa 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, Microsoft Excel 2002 ou 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 BHOLD Reporting principalmente para produzir relatórios baseados em informações de função atuais. Para gerar relatórios para auditar 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 Data Warehouse do System Center Service Manager. Para obter mais informações sobre relatórios 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 cobertas pelos relatórios internos incluem o seguinte:

• Administração
• Atestado
• Controlos
• Controlo de Acesso Interno
• Registo
• Modelo
• Estatísticas
• Fluxo de trabalho

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

À medida que você cria um relatório, o assistente orienta você no fornecimento dos seguintes parâmetros:

• Informações de identificação, incluindo nome, descrição, categoria, uso e público
• Campos a serem exibidos no relatório
• Consultas que especificam quais itens devem ser analisados
• Ordem em que 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 para as etapas anteriores para alterar os parâmetros especificados anteriormente no assistente.

Conector de gerenciamento de acesso

O módulo BHOLD Suite Access Management Connector suporta a sincronização inicial e contínua de dados no BHOLD. O Access Management Connector trabalha em conjunto com o Serviço de Sincronização do FIM para transferir dados entre a base de dados BHOLD Core, o Metaverso do MIM, e aplicações de destino e repositórios de identidade.

As versões anteriores do BHOLD exigiam vários agentes de gestão (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 Access Management Connector permite definir agentes de gerenciamento (MAs) no MIM que fornecem transferência de dados diretamente entre BHOLD e MIM.

Próximos passos

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