x

Normalmente, o sujeito de uma regra é um grupo. É possível aplicar uma regra a um único usuário. No entanto, esta prática normalmente não é recomendada, pois o gerenciamento de regras para usuários em específico pode ser problemática. É mais fácil alterar as regras que se aplicam a um usuário através da adição ou remoção do usuário de um grupo sem ter que alterar as regras. Este tópico pressupõe que a sua política de segurança terá grupos como base, mas você pode ajustar uma política adicionando regras a usuários individuais, caso deseje.

Os templates de domínio definem quatro funções (Usuário Básico, Usuário Avançado, Desenvolvedor e Administrador de Grupo), que são implementados como subgrupos aninhados em um grupo pai para o domínio. Os recursos de usuários no grupo Usuário Básico são determinados pelas regras associadas com a função Usuário Básico, enquanto os recursos de usuários no grupo usuário Avançado são determinados pelas regras associadas com a função Usuário Básico e com a função Usuário Avançado. Os recursos de Usuário Avançado incluem aqueles de posse dos Usuários Básicos. Recursos de Desenvolvedor incluem os de posse de Usuários Avançados, como ilustrado no diagrama abaixo. Administradores de grupo não possuem permissão para executar relatórios ou visualizar a saída da biblioteca. Portanto, seus recursos não sobrepõem os recursos de outros grupos.

Funções de aninhamento simplificam a criação de políticas. Um usuário precisa apenas pertencer a um destes grupos para ter todos os recursos deste tipo de usuário. Um usuário também pode ser adicionado aos grupos Administrador de grupo e um outro grupo caso seja necessário que um indivíduo tenha este conjunto mesclado de habilidades. Regras podem ser aplicadas a um grupo pai para permitir que todos os seus usuários compartilhem conteúdo entre si ou para fornecer controle a administradores de grupo sobre este grupo pai e seus subgrupos.

De forma alternativa, você pode particionar os recursos de usuário em funções distintas sem sobreposição de privilégios. Apesar de permitir maior flexibilidade, este modelo é mais difícil de se administrar, pois os recursos de cada usuário são um conjunto de muitas funções e regras.

Além disso, você pode precisar de grupos de infraestrutura para organizar usuários que necessitam de acesso a todos os recursos no sistema. Por exemplo, um grupo Administração ou Controle de Alterações que possui autoridade para exportar recursos no Repositório, mas não pode executar ou excluir recursos.

Para obter mais informações sobre grupos, consulte Como Gerenciar Usuários e Grupos.

x

Funções são utilizadas para agrupar um conjunto de privilégios frequentemente utilizados. Uma regra de segurança permite ou nega a função para um sujeito para um recurso, com oilustrado na imagem a seguir.

Após determinar como organizar usuários em grupos, você pode criar funções que serão úteis para estes grupos. Se houver um grupo por tipo de usuário, como há nos templates de domínio, uma forma simples de começar é criar uma função por tipo de usuário. É possível criar regras que permitem ou negam cada função a seu respectivo grupo para um recurso particular.

Por exemplo, os templates de domínio já criam uma regra que permite que o grupo BasicUser obtenha a função DomainBasicUser na pasta de domínio e seus filhos. O grupo AdvancedUser tem permissão para obter a função DomainAdvancedUser na pasta de domínio e seus filhos. É possível criar regras similares para fornecer os subgrupos personalizados que você cria com o acesso adequado a um portal de domínio ou a uma página de domínio em um portal comum. Para garantir o acesso de desenvolvedor ao Reporting Server, é possível criar uma regra que fornece ao grupo Desenvolvedor a função DomainDeveloper no nó Reporting Server da árvore de recursos.

Uma função pode ser utilizada em diversas regras, como quando você deseja permitir privilégios em um grupo em diferentes tipos de recursos. Se você desejar fornecer privilégios de desenvolvedores em uma pasta, um portal e um nó Reporting Server, é possível criar uma função que coleta todos os privilégios relevantes e cria uma regra separada para aplicar a função em cada recurso. O WebFOCUS ignora os privilégios que não se aplicam a um subsistema em particular. Também é possível criar uma função separada para desenvolvedores em cada recurso que coleta apenas os privilégios relevantes ao subsistema IBFS associado. Crie uma função para desenvolvedores que especifica a pasta, uma que especifica o portal e outra que especifica o nó Reporting Server. No entanto, é mais fácil manter uma única função.

Observação: Funções que incluem privilégios de sessão não devem ser utilizadas em regras definidas nas ramificações mais baixas do subsistema WFC. Por padrão, o WebFOCUS não procura por privilégios de sessão abaixo de uma certa profundidade com o intuito de diminuir a demanda nos recursos de sistema. A profunidade da pesquisa pode ser alterada por um administrador de sistemas, mas este procedimento não é recomendado.

Para obter mais informações sobre como alterar a profunidade da pesquisa, consulte Configurações de Segurança. Para obter mais informações sobre funções, consulte Como Gerenciar Funções.

x

Quanto menos funções o sistema possuir, mas fácil será entendê-lo e mantê-lo. O número de regras que formam a política de segurança depende de muitos fatores, como quais subsistemas você deseja expor a usuários, de quantas funções diferentes a sua empresa necessita e quantos domínios você possui. É possível minimizar o número de regras no seu sistema aplicando as regras ao nível mais alto possível da hierarquia IBFS. Em geral, isto significa permitir privilégios no nível mais alto possível, negando-os nos níveis mais baixos , conforme necessário.

Como exemplo, considere um cenário simples onde todos em uma instalação têm acesso a todos o seus recursos e usuários finais precisam fazer apenas uma ou duas coisas: desenvolver relatórios ou executá-los. Você pode implementar isto utilizando simplesmente dois grupos ou duas regras. Os dois grupos são Desenvolvedor de Relatórios e Executador de Relatórios. As duas regras são posicionadas no nó raiz IBFS e, portanto, se aplicam para todas as pastas, portais e recursos do Reporting Server. Uma regra permite que o grupo Desenvolvedor de Relatórios obtenha a função Desenvolvedor de Relatórios na pasta raiz IBFS e todos os seus filhos, e a outro regra permite que o grupo Executador de Relatórios obtenha a função Executador de Relatórios como mesmo escopo. Com uma única regra adicional, é possível ocultar o nó Reporting Server a partir do grupo Executador de Relatórios não permitindo que o grupo obtenha a função Lista neste nó.

Frequentemente, grupos diferentes necessitam de acesso a recursos diferentes. A política de segurança fornecida pelos templates de domínio atende a essa necessidade. Em cada domínio, grupos recebem acesso a seus próprios recursos e nenhum grupo é associado às regras acima das pastas de domínio e portais. Regras especializadas podem ser aplicadas para ajustar a política para atender a necessidades adicionais, como ocultar pastas específicas ou páginas de portal.

É comum que usuários precisem poder interagir com o conteúdo de um contêiner, mas não devem poder afetar o contêiner. Por exemplo, desenvolvedores podem precisar criar e excluir pastas em Sales, mas não devem poder excluir a pasta Sales. É possível garantir isto através da restrição de privilégios específicos com uma regra que é utilizada apenas na pasta. Os templates de domínio restringem Desenvolvedores de Domínio e Administradores de grupo desta forma, para que eles não excluam os contêineres que definem os limites de segurança, como as pastas nas quais possuem controle administrativo.

Para obter mais informações sobre regras, consulte Como Gerenciar Regras.

x

O WebFOCUS possibilita a delegação de responsabilidade para diversas funções administrativas, incluindo:

• Cria grupos e usuários.
• Atribuir usuários aos grupos.
• Criar regras de segurança limitadas, como a não permissão do acesso a uma subpasta para membros de um grupo especial.
• Gerenciar conteúdo privado para usuários.
• Reatribuir a propriedade de recursos, como agendamento ou relatórios.

Os templates de domínio fornecem dois exemplos de como se abordar a criação de uma política de administração de grupo. No template Domínio Empresarial, os administradores de grupo podem ver todos os seus usuários no WebFOCUS dentro da Central de Segurança e adicionar qualquer usuário aos seus grupos gerenciados. No entanto, no template Domínio de Locatários de SaaS, os administradores de grupo podem apenas ver e gerenciar a propriedade para usuários no seu próprio grupo de locatários. Esta diferença de política é implementada através alterando a aplicação da regra que permite que a função DomainGroupAdminScope ao grupo EVERYONE ou ao grupo de locatários. De forma parecida, uma regra que permite que os administradores de grupos empresariais obtenham a função Gerenciar Usuários no grupo pai permite que administradores criem usuários.

Para obter mais informações sobre grupos, consulte Como Gerenciar Usuários e Grupos.

x

É recomendada a utilização das regras IBFS para ocultar ou expor os nós do Servidor de Segurança quando necessário, mas os recurso Funções de Reporting Server e Controle de Acesso para proteger recursos específicos nos servidores. Regras aplicadas aos recursos do Reporting Server abaixo do nó não afetarão o que for processado em outras partes da interface de usário do WebFOCUS. Elas apenas se aplicam à visualização de árvore de recursos. Os recursos de Controle de Acesso ao Reporting Server fornecem melhor segurança para o controle de acesso às definições do mecanismo de servidores, como SQL pass-through ou comandos do sistema operacional, e para pasta de aplicativos que contêm metadados e dados carregados.

x

A segurança do IBFS controla os recursos no Repositório do WebFOCUS e alguns recursos externos, como os nós do Reporting Server. No entanto, o acesso a linhas de dados em um banco de dados ou nomes de campo nos metadados do WebFOCUS é controlado pelos recursos do WebFOCUS Data Security (DBA). É possível utilizar estes recursos de segurança de dados passando o ID de usuário autenticado do WebFOCUS e os grupos de usuários para o Reporting Server.

Para obter mais informações sobre como trocar informações entre o Cliente WebFOCUS e o Servidor de Relatório WebQuery, consulte Detalhes do processamento Principal do WebFOCUS Reporting Server.