Introdução

Propósito

Este documento fornece um conjunto de práticas e diretrizes comprovadas a ser levado em consideração ao proteger o ambiente do IBM Cognos 10 BI.

O público destinado a este documento são os administradores de aplicativo do IBM Cognos 10 BI, que serão responsáveis por projetar a arquitetura do IBM Cognos 10 e/ou desenvolvimento do projeto. O conteúdo não é relevante ao usuário final pois a maioria das recomendações precisam ser implementadas pelos administradores do IBM Cognos antes do roll out do usuário final.

Aplicabilidade

As recomendações e práticas descritas neste documento não são específicas a nenhuma plataforma ou arquitetura de implementação. São fornecidos exemplos baseados em uma instalação do Windows embora todas as declarações se apliquem a produtos listados na página de capa (incluindo liberações de Fix Pack (FP) e Refresh Pack (RP)) a menos que seja indicado de outra forma explicitamente.

Exclusões e Exceções

Apesar de projetadas para serem genéricas, para serem aplicáveis à maioria das instalações, algumas declarações podem não se aplicar a ambientes específicos. Deve-se tomar consideração especial para garantir que as recomendações dadas aqui correspondam aos requisitos definidos para sua implementação e sigam as políticas de segurança aplicáveis a seu ambiente.

Voltar para parte superior

Diretrizes sobre Proteção de Ambientes IBM Cognos 10 BI

Os produtos IBM Cognos 10 oferecem recursos de segurança flexíveis e versáteis que facilitam a integração na maioria, se não todos, os ambientes de segurança existentes. O desafio é iniciar a partir de uma configuração de base sólida que é suficiente para ambientes de teste e/ou desenvolvimento e então mover para implementações e integrações de segurança. O IBM Cognos 10 oferece tudo isso pronto para usar.

Os capítulos a seguir descreverão algumas diretrizes e recomendações violadas pela ferramenta usada para configurá-las. Serão tratados tópicos de autenticação e autorização e fornecidas algumas Melhores Práticas a serem seguidas.

Antes de começar, a primeira etapa é definir claramente os requisitos, abaixo, está uma lista de questões que devem ser respondidas em relação à segurança do IBM Cognos 10 BI antes de iniciar a implementação.

• Qual(is) origem(ns) de autenticação está(ão) sendo usada(s)? As origens de autenticação mais comuns são LDAP e Active Directory, mas há outras. Certifique-se de que haja um contato disponível para ajudá-lo a entender o conteúdo e estruturas de origem de autenticação assim como as informações técnicas necessárias como servidor, porta e credenciais necessários. Uma informação específica pode ser necessária para seguir algumas recomendações de Melhor Prática.
• Você está usando um único namespace de segurança ou diversos namespaces de segurança? Dependendo do requisito, alguém pode enfrentar o desafio de autenticar “automaticamente” um usuário para diversos namespaces mediante o login. Embora não seja suportado pelo IBM Cognos 10 BI, pode ser resolvido com técnicas de script do .NET ou JavaScript.
• Os usuários serão autenticados no IBM Cognos BI explicitamente ou deverá haver algum tipo de Single Sign-On (SSO) baseado em autenticação de alguma outra camada de segurança? Se a SSO de outra origem para o IBM Cognos 10 for necessária, certifique-se de avaliar se é um recurso fácil de ter ou que você deve ter. Se for necessário, resolva o desafio de SSO tecnicamente antes de definir a autorização, já que SSO pode ter implicações nos namespaces necessários ou sua configuração. Em especial, a SSO pode impactar a programação, pois muitas credenciais de SSO podem não ser apropriadas por serem armazenadas com programações porque podem expirar. Isto faz com que seja solicitado dos usuários o nome de usuário e senha, os quais eles podem não saber, já que são acostumados com SSO.
• As mesmas credenciais usadas para autenticar no IBM Cognos BI 10 também devem ser usadas para autenticar em um banco de dados de consulta (pass-through de usuário)? Esta pode ser uma configuração complexa e desafiadora e não suportada em todas as combinações de origem de autenticação e bancos de dados. Avalie se as alternativas que usam conexões de banco de dados armazenados são possíveis, mas observe que isto pode ter implicações na autorização, pois as conexões devem ser mantidas e protegidas adequadamente no IBM Cognos 10 BI.
• Que nível de segurança é necessário? Este sistema é acessível externa ou somente internamente? É uma Melhor Prática recomendada implementar o protocolo Secure Socket Layer (SSL) no servidor da web que hospeda o IBM Cognos 10 BI Gateway se o sistema for acessível externamente. É mais provável que as políticas de segurança da sua empresa demandarão isto e possivelmente outras medidas de segurança adicionais. Isto terá implicações na configuração de SSL no IBM Cognos 10 BI.
• Quão particulares são os dados para usuários internos/externos? Dependendo do requisito de segurança, você desejará observar a criptografia dos arquivos temporários e a criptografia de todo o tráfego sobre a rede mesmo internamente. Novamente, essas considerações têm implicações na configuração da instalação do IBM Cognos 10 BI.
• O IBM Cognos 10 BI será integrado a outros produtos IBM como Lotus Connections, IBM Cognos TM1 ou IBM Cognos Planning? A integração pode implicar mudanças na segurança após o fato se não planejada com cuidado. Discuta cenários de integração com seu representante IBM Cognos antes de executar qualquer implementação de segurança.

Esses são apenas alguns dos exemplos, mas o que isso demonstra é quantos aspectos de segurança podem se tornar relevantes ao IBM Cognos 10 BI. Obviamente, há muitos aspectos de segurança a se considerar, mas a boa notícia é que todos eles podem ser tratados no IBM Cognos 10 BI. As recomendações de Melhor Prática listadas neste documento referem-se à aplicabilidade geral. Para obter mais tópicos específicos, tente pesquisar documentos no website do developerWorks da IBM localizados em http://www.ibm.com/developerworks/data/library/cognos/cognosprovenpractices.html.

Voltar para parte superior

IBM Cognos Configuration

Esta seção discutirá as definições e itens de configuração relacionados à segurança que estão especificados no IBM Cognos Configuration. São implementados normalmente após a instalação e fornecem a base para as tarefas subsequentes que são tratadas posteriormente.

Instalação Segura

Conta de Serviço

A primeira decisão que afeta a segurança pode já ter sido feita.É possível que o IBM Cognos 10 tenha sido instalado em sua plataforma usando uma conta particular e essa conta possa ter privilégios suficientes de sistema de arquivos para executar a instalação. Entretanto, é possível que as políticas ou o ambiente demandem que contas específicas sejam usadas para execução em um aplicativo. Referimo-nos a essa conta como a Conta de Serviço.

O IBM Cognos 10 BI é para a maior parte um aplicativo da web Java que é implementado em um servidor de aplicativo Java como IBM WebSphere. Apesar de pronto para uso, o IBM Cognos 10 é distribuído pré-implementado em Apache Tomcat, que não é um servidor de aplicativos Java, mas um subconjunto de um. Para o propósito desta explicação, no entanto, simplesmente nos referimos ao Apache Tomcat como um servidor de aplicativos.

Se o IBM Cognos 10 for executado usando a saída do pacote Apache Tomcat, há um serviço chamado cognosbootstrapservice.exe que iniciará o Apache Tomcat e pode ser configurado no IBM Cognos 10 BI Cognos Configuration. Em plataformas Windows, este serviço é registrado como um Serviço do Windows, executado pela conta Local System por padrão. Em plataformas UNIX/LINUX, o serviço é executado pela conta que chama o script de início cogconfig.sh . Portanto, a Conta de Serviço é a conta que executa o servidor de aplicativos.

Se o IBM Cognos 10 BI for implementado em um servidor de aplicativos diferente, normalmente esse servidor determinará a conta usada para executar o IBM Cognos 10 BI e, portanto, a Conta de Serviço.

É importante escolher uma Conta de Serviço adequada, porque:

• Esta conta instanciará o Java Runtime Environment (JRE) que hospeda o IBM Cognos 10 e todos os outros processos criados pelo IBM Cognos 10 como BiBusTKServerMain, CAM_LPSvr, BmtMDProviderMain e outros. Todos os processos IBM Cognos 10, quer Java ou nativos, requerem privilégios do sistema de arquivos de diferentes níveis para o diretório de instalação do IBM Cognos 10 e seus subdiretórios.
• Esta conta será usada para acesso da impressora.
• Se em execução em plataformas Windows, esta conta será usada para interação necessária de Microsoft Kerberos para SSO com IBM Cognos 10 e possivelmente para autenticação em bancos de dados Microsoft como SQL Server ou Analysis Services.
• Esta conta será usada para criar arquivos temporários e arquivos transitórios.
• Esta conta será usada para interagir com os recursos de log da plataforma quando o IBM Cognos 10 está sendo configurado para direcionar a saída de Auditoria aos recursos de log do sistema operacional.

Uma Melhor Prática é usar uma conta chamada especificamente designada ao IBM Cognos 10 para executar a instalação (fornece propriedade de sistema de arquivos) e a execução do IBM Cognos 10. A conta da instalação e a Conta de Serviço podem ser diferentes, mas deve-se tomar cuidado adicional em relação às permissões do sistema de arquivos.

Em plataformas Windows em que se usa uma conta de domínio chamada como a Conta de Serviço em vez de Local System ou Network Service, a conta deve ser permitida para autenticar na máquina e deve ter privilégios suficientes de sistema de arquivos assim como ser configurada adequadamente no Controle de Conta do Usuário. Dependendo do uso de recursos sofisticados como Kerberos SSO, o passthrough de usuário para bancos de dados Microsoft e log nos loggers do sistema operacional, podem ser necessários privilégios adicionais do Windows.

Em plataformas Linux/UNIX, a Conta de Serviço deve compartilhar um grupo primário com a conta de instalação para simplificar a questão do acesso do sistema de arquivos. A Conta de Serviço e seu grupo primário devem receber acesso total ao diretório de instalação incluindo subdiretórios e todas as permissões do sistema de arquivos para “outros” devem ser revogadas. É recomendado que a propriedade do diretório e subdiretórios de instalação deve ser concedida ao proprietário da instalação e o grupo primário compartilhado apenas.

Informações sobre a Conta de Serviço podem ser localizadas no link a seguir do Centro de Informações do IBM Cognos 10.

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.inst_cr_winux.10.1.0.doc/inst_cr_winux_id3223ConfigureAUserAccountForCognos8.html#ConfigureAUserAccountForCognos8

Arquivos Temporários

Como a maioria dos produtos, o IBM Cognos 10 BI utiliza arquivos temporários durante o decorrer das funções de relatório ordinárias. Por padrão, arquivos temporários são gravados em uma pasta temporária no disco. O local padrão para isto é <COG_ROOT>/temp do tdbtool, em que <COG_ROOT> denota o diretório de instalação do IBM Cognos 10 BI. O diretório é configurável no IBM Cognos Configuration, no entanto. A propriedade é chamada Temporary files location e reside na seção Ambiente .Para restringir o acesso aos arquivos temporários encontrados neste diretório, é sugerido que as permissões do sistema de arquivos sejam configuradas para somente permitir o controle total da Conta de Serviço no diretório, o acesso a todas as outras contas deve ser negado. Se o local do arquivo temporário for movido para um diretório fora do diretório de instalação do IBM Cognos 10 BI, é possível que seja necessário ajustar as permissões do sistema de arquivos.

O IBM Cognos 10 BI também pode salvar arquivos de sessão do usuário no sistema de arquivos local para ajudar a reduzir a carga no Content Manager. Se este recurso for configurado, o local especificado para os arquivos de sessão de usuário deverá ser acessível pela Conta de Serviço apenas. Lembre-se de que este recurso afeta apenas instâncias instaladas dos componentes da Camada do Aplicativo. Para obter mais informações sobre salvar arquivos de sessão de usuário no sistema de arquivos local, consulte o link a seguir do Centro de Informações do IBM Cognos 10.

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id281asg_content_manager.html#asg_content_manager

Criptografando Arquivos Temporários

Se modelos ou relatórios visualizados recentemente contiverem dados particulares, deverá ser tomada precaução extra ao lidar com esses arquivos temporários que são gerados. O IBM Cognos 10 BI oferece a capacidade de criptografar esses arquivos temporários, de modo que eles não possam ser visualizados por consumidores não autorizados. Isto não se aplica a arquivos de sessão de usuário, no entanto. A propriedade para ativar criptografia de arquivo temporário pode ser modificada usando o IBM Cognos Configuration. A propriedade é chamada Encrypt temporary files? e reside na seção Ambiente .O valor deve ser configurado como True para ativar este recurso. A criptografia aplicada é baseada em uma chave baseada em sessão que é alimentada para o cipher de confidencialidade configurado.

Senhas do Dispatcher

A partir do IBM Cognos BI 8.4, há uma propriedade de senha do Dispatcher que deve corresponder entre todas as instâncias instaladas dos Dispatchers, incluindo instalações apenas dos componentes de Camada de Aplicativo e Content Manager. A senha atua de forma semelhante a um segredo compartilhado, pois evita que os Dispatchers que não conhecem o segredo se juntem ao sistema do IBM Cognos 10 BI. Como uma Melhor Prática, esta senha deve ser alterada do padrão em todas as instalações de Camada de Aplicativo e Content Manager. A propriedade para configurar a senha do Dispatcher pode ser modificada usando o IBM Cognos Configuration. A propriedade é chamada Dispatcher password e reside na seção Ambiente .

Banco de Dados do Content Store

O banco de dados do Content Store é o repositório central para o sistema do IBM Cognos 10 BI. Deve ser óbvio que é necessário tomar o máximo de precaução para garantir que o banco de dados esteja disponível e protegido adequadamente. O componente Content Manager do IBM Cognos 10 BI manipula o acesso ao banco de dados do Content Store por meio de uma única signon de banco de dados. A signon é especificada no IBM Cognos Configuration e será salva em um formato criptografado no arquivo de configuração principal do IBM Cognos 10 BI <COG_ROOT>\configuration\cogstartup.xml. Entretanto, se o banco de dados for acessível de fora do IBM Cognos 10 BI, isto irá comprometer a estabilidade e segurança do sistema do IBM Cognos 10 BI. Embora os dados particulares sejam salvos em formato criptografado no Content Store, não serão criptografadas saídas de relatório ou outras informações que não sejam necessariamente particulares por padrão, portanto, é importante garantir que nenhuma conta tenha acesso de leitura/gravação no banco de dados do Content Store e no nível do banco de dados. Isto deve ser implementado no nível de banco de dados. Para obter detalhes, consulte seu administrador de banco de dados.

Conceitos de Autenticação

A autenticação do IBM Cognos 10 BI funciona recusando a autenticação para uma origem de autenticação externa por meio de um software chamado provedor de autenticação. Cada provedor de autenticação conecta-se a um tipo de origem de autenticação como LDAP, Microsoft Active Directory ou SAP BW e implementa lógica para ler objetos de segurança e manipular processos de autenticação com ele. Mais importante ainda, muitos provedores de autenticação fornecem suporte a SSO. Exceto para um tipo especial de provedor, cada provedor de autenticação expõe os objetos lidos da origem externa da autenticação na forma de um namespace para IBM Cognos 10 BI. Para um único sistema do IBM Cognos 10 BI, diversos namespaces podem ser configurados ao mesmo tempo e, portanto, usuários de diversas origens de autenticação podem acessar o IBM Cognos 10 BI.

Há um namespace especial no IBM Cognos 10 BI chamado Cognos . Não está conectado a nenhuma origem de autenticação e não pode conter usuários, mas somente grupos e funções. O namespace do Cognos não está disponível para autenticação, mas é usado para fornecer uma camada de mapeamento lógico para objetos de segurança de namespaces conectados a origens de autenticação externas e objetos de autorização definidas pelo aplicativo. Um administrador criaria grupos e funções no namespace do Cognos e designaria objetos de segurança, como usuários, grupos e funções para esses objetos criados no namespace do Cognos. Conceitos de autorização serão discutidos posteriormente no documento.

Ambos os namespaces externos e o namespace do Cognos são configurados no IBM Cognos Configuration. Também há algumas configurações gerais que influenciam a autenticação aplicada independentemente do tipo de namespace. Começaremos com algumas Melhores Práticas para especificar as configurações gerais.

Tempo Limite de Inatividade

A configuração do tempo limite de inatividade especifica quantos segundos levará antes que a sessão autenticada de um cliente com o IBM Cognos 10 BI seja considerada expirada. Uma configuração de expiração mais curta pode levar a prompts de autenticação mais frequentes, uma configuração de expiração mais longa aumenta o risco de alguém acessar um navegador em uma estação de trabalho não auxiliada se nenhuma proteção de trava de tela for usada. Se a SSO estiver configurada, no entanto, o usuário será autenticado novamente de forma silenciosa no plano de fundo sem qualquer impacto negativo. É recomendado ter a SSO configurada sempre que possível. O tempo limite de inatividade é configurado no IBM Cognos Configuration configurando a propriedade Inactivity timeout in seconds localizada na seção Security > Authentication . Como uma Melhor Prática, deve ser configurada de acordo com sua política de segurança. Um bom ponto de partida é 900 segundos ou 15 minutos. Isto é um quarto do valor padrão de 3600 segundos, mas representa uma boa troca entre o consumo de recurso para toda sessão ativa e para conveniência do usuário.

Criptografia de Passaporte

Uma autenticação bem-sucedida levará à criação de objetos de sessão na memória no componente Content Manager. Esses objetos de sessão conterão dados particulares do usuário. Se necessário, é possível criptografar esses objetos da memória para impedir o acesso às informações por malware ou outros leitores de memória. Para ativar a criptografia, use o IBM Cognos Configuration para configurar a propriedade Enable the encryption of passport credentials? localizada na seção Security > Authentication como True. Lembre-se de que isto terá um leve impacto no desempenho de autenticação e outras operações que requerem acesso às credenciais do usuário. Como uma Melhor Prática, deixe desativada a menos que seja explicitamente necessário à sua política de segurança.

Compartilhamento de sessão

Quando diversos clientes (Framework Manager, Transformer, Planning, etc.) em uma única estação de trabalho acessam o mesmo sistema do IBM Cognos 10 BI, é possível que eles compartilhem uma sessão autenticada. Embora isto ajude a reduzir o número de sessões ativas simultâneas que existam no IBM Cognos 10, é potencialmente menos seguro que ter sessões gerenciadas separadamente para cada cliente. Por outro lado, é necessário para alcançar SSO entre diversos clientes em uma única estação de trabalho. A propriedade para configurar no IBM Cognos Configuration é Allow session information to be shared between client applications? na seção Security > Authentication .O valor padrão para esta propriedade é Falso e a Melhor Prática é deixá-lo como False a menos que haja diversos aplicativos de cliente em uma única estação de trabalho para a qual a SSO é desejada.

Restringindo acesso ao IBM Cognos Connection

Quando um namespace está configurado para autenticação, subentende-se que todos os usuários da origem de autenticação subjacente devem ser capazes de autenticar-se no IBM Cognos BI e acessar o IBM Cognos Connection. Isto, no entanto, pode nem sempre ser o caso, já que pode haver um requisito mínimo para limitar o acesso a um subconjunto de todos os usuários contidos na origem de autenticação configurada. No IBM Cognos 10 BI, isto pode ser alcançado utilizando a propriedade de configuração Restrict access to members of the built-in namespace na seção Security > Authentication no IBM Cognos Configuration. Se essa propriedade for configurada como True, o acesso será negado a qualquer usuário que não seja um membro do namespace do Cognos direta ou indiretamente. O namespace do Cognos é o namespace integrado usado para mapear usuários, grupos e funções de origens de autenticação externas para um modelo de segurança definido específico a aplicativos. Para obter mais informações em relação ao namespace do Cognos, consulte a seção titulada “Authorization Concepts and Best Practice”. ao designar um usuário ou um grupo/função de um namespace externo do qual o usuário é membro a um grupo ou função no namespace do Cognos, o usuário se torna um membro do namespace do Cognos implicitamente.

Exemplo: Os usuários Robert Smith e Marla Spears estão definidos em uma origem LDAP que é configurada como um namespace LDAP para o IBM Cognos 10. Robert está designado à função de Consumidores no namespace do Cognos, enquanto Marla não está designada a nenhum grupo ou função no namespace do Cognos. Se o acesso Restrito a membros da propriedade integrada namespace? estiver configurado como True, Robert poderá autenticar-se no IBM Cognos 10 e ter acesso ao Cognos Connection, mas Marla não, porque ela não é um membro de nenhum grupo ou função no namespace do Cognos.

Autorrenovar credenciais confiáveis

A partir do IBM Cognos 10, há um novo recurso que permite que o IBM Cognos 10 BI atualize “automaticamente” credenciais armazenadas para programações. Este recurso pode ser configurado no IBM Cognos Configuration pela propriedade Automatically renew trusted credential na seção Security > Authentication .Para entender o impacto desta configuração, precisamos observar alguns detalhes.

Quando um usuário cria uma credencial confiável a ser salva com uma programação ou para fornecê-la a um usuário diferente para usar em relatórios em execução em vez de o usuário salvar as credenciais, há um objeto criado que contém credenciais para todos os namespaces para os quais o usuário está atualmente autenticado. Como resultado, devido a um único usuário pode autenticar-se em diversos namespaces em uma única sessão, credenciais confiáveis podem potencialmente conter diversos conjuntos de credenciais, um para cada namespace. O primeiro namespace ao qual a sessão está autenticada é chamado de namespace primário.

Uma credencial confiável é importante, pois as credenciais de namespace armazenadas devem ser úteis a todo momento, independentemente de registros de data e hora. Isto descarta bilhetes de SSO como tokens Kerberos ou tokens SAP já que eles irão expirar após um curto período e se tornarão inutilizáveis. Uma credencial confiável adequada, portanto, geralmente é um par que consiste em um nome de usuário e uma senha. Entretanto, para autenticação baseada em SSO no IBM Cognos 10 BI, não há senha disponível para o namespace que pode ser armazenado na credencial confiável. Portanto, este recurso funcionará apenas para autenticação básica, quando o usuário fornecer um nome de usuário e senha para a tela de login. Neste caso, o sistema procurará todas as credenciais confiáveis para esse usuário e as atualizará com as credenciais que eles acabaram de inserir.

Quando a propriedade está configurada como Primary namespace only (o valor padrão), isto significa que essas credenciais confiáveis serão atualizadas com uma única credencial apenas embora o valor de Todos os namespaces implique que essas credenciais para todos os namespaces atualmente autenticados sejam atualizadas. A Melhor Prática é configurar isto como um valor de Primary namespace only se a autenticação para o namespace for a não pela SSO, caso contrário, deverá ser configurada como um valor de Off.

Namespaces

Há algumas diretrizes específicas ao tipo de namespace:

Identificador exclusivo de LDAP

Uma vez que um usuário foi autenticado para obter acesso ao portal do IBM Cognos Connection, uma referência de conta do usuário conhecida como um CAMID é armazenada no banco de dados do Content Store. Este CAMID é parcialmente composto do valor retornado do atributo mapeado para a propriedade Unique identifier para a definição do namespace na seção Security > Authentication no IBM Cognos Configuration. Por padrão, esta propriedade é mapeada para dn (Nome Distinto). Todos os servidores LDAP terão este atributo dn preenchido para cada entrada única, então isto garante que independentemente do tipo de servidor do LDAP, sempre haverá um atributo no qual basear o identificador exclusivo. Esta prática, no entanto, não garante que as contas do usuário sejam realmente exclusivas. Considere o seguinte cenário,

A empresa ABC comprou o IBM Cognos 10 BI e tem oferecido com sucesso o produto a sua base de usuários. Um namespace LDAP foi usado para se conectar ao servidor de diretório corporativo. A configuração padrão de namespace LDAP do IBM Cognos 10 BI é historicamente baseada no Sun One Directory Server, portanto, seu valor para a propriedade do Identificador exclusivo foi configurada como dn. O Vice-presidente da North American Sales, John Q. Smith, é um usuário constante do IBM Cognos 10 BI e tem armazenado relatórios particulares de vendas e previsões em sua parte “My Folders” do portal do IBM Cognos Connection. Usando a convenção de nomenclatura corporativa de “sobrenome, primeira letra inicial”, a conta de usuário de rede é SMITHJ e foi criada na pasta de usuário North America. Isto dá a John Q. Smith um dn de:

uid=SMITHJ, cn=North America, dc=Company ABC, dc=com

Até então, está tudo normal. Entretanto, John Q. Smith decide assumir um cargo em outra empresa, então, sua conta de usuário é removida da hierarquia LDAP corporativa. Alguns meses depois, um gerente prestes a assumir, John X. Smith, é contratado. Mais uma vez, usando as convenções de nomenclatura na Empresa ABC, John X. Smith recebe uma conta de rede de SMITHJ, porque está disponível. Isto dá ao John X. Smith um dn de:

uid=SMITHJ, cn=North America, dc=Company ABC, dc=com

Quando John X. Smith efetua login no IBM Cognos Connection e vai salvar um relatório em “My Folders” pela primeira vez, ele percebe que esta pasta está preenchida com relatórios que contêm dados particulares. A razão disto ter acontecido é porque o identificador exclusivo foi baseado em um atributo que NÃO pode ser exclusivo com o passar dos anos, conforme demonstrado no exemplo anterior. A única forma de garantir que esse tipo de cenário não ocorra é usar um atributo para o identificador exclusivo que fornece valores exclusivos globalmente para cada leitura de entrada do servidor do LDAP.

A maioria dos servidores do LDAP fornece tal atributo, geralmente como parte dos atributos operacionais. Atributos operacionais são apenas de leitura e somente mantidos pelo servidor do LDAP. Alguns navegadores LDAP não os mostrarão por padrão e será necessária uma ação explícita para lê-los/exibi-los. Consulte sua documentação do servidor do LDAP para aprender qual atributo é usado como um identificador exclusivo globalmente de uma entrada. Alguns exemplos são ibm-entryuuid usado pelo LDAP do IBM Tivoli, objectGUID usado pelo Active Directory quando acessado como uma origem de LDAP ou nsuniqueid que é usado pelo servidor Sun One Directory.

A Melhor Prática para namespaces LDAP é usar este atributo exclusivo globalmente para a propriedade do Identificador exclusivo.

É claro que uma infraestrutura de segurança sólida desenvolvida na Empresa ABC não teria permitido que duas contas SMITHJ fossem criadas (pelo menos não com o mesmo identificador exclusivo interno), mas fazer esta simples mudança de configuração adicionará um nível extra de segurança para sua implementação.

OBSERVAÇÃO: O mapeamento de atributo deve ser alterado antes de aplicar autorização no portal do IBM Cognos Connection e/ou de permitir que os usuários acessem o IBM Cognos 10 BI. Se o mapeamento de atributo for uma reflexão tardia e alterado posteriormente, toda a segurança de objetos será anulada e os usuários não visualizarão seu conteúdo pessoal. Isto acontece, pois, após uma mudança nesta configuração, um novo CAMID será criado para cada usuário que efetuar login baseado no novo atributo para o identificador exclusivo, assim, criando basicamente uma nova conta de usuário no Content Store. Também é importante observar que o atributo usado deve ser um atributo disponível para todos os objetos como grupos, pastas e usuários. Se o atributo selecionado apenas existir para usuários, alguns objetos não aparecerão no IBM Cognos Connection ao administrar o namespace.

Conexões LDAP

O provedor de autenticação de LDAP do IBM Cognos 10 BI pode ser configurado de muitas formas em relação à manipulação de conexão e às credenciais usadas para ligar ao servidor do LDAP. Neste momento, muitos destes métodos ainda estão sendo investigados a respeito da melhor maneira de serem implementados.

Basicamente, o provedor usa dois tipos de conexões: uma para procuras de consulta e uma para procuras relacionadas a ações de sessão do usuário.

As conexões de consulta serão estabelecidas usando as credenciais de ligação fornecidas, colocadas em conjunto e, portanto, reutilizadas. O tamanho de conjunto padrão é 20 e as conexões não são fechadas até que o produto seja parado. Para configurar o tamanho do conjunto e influenciar na eliminação de conexões para um provedor desse tipo, é possível especificar minimumLDAPPoolSize e maximumLDAPPoolSize no campo Advanced properties para a definição do namespace na seção Security > Authentication no IBM Cognos Configuration. Se ambas as propriedades estiverem configuradas como 0, as conexões não serão colocadas em conjunto e serão fechadas imediatamente após o uso.

Para conexões de sessão do usuário, as credenciais de usuário fornecidas ao efetuar login são usadas para ligar ao provedor a menos que Use bind credentials for search estiver configurada como true. Ao invés, isto acionaria o uso dos valores especificados na propriedade Ligar DN e senha do usuário . Essas conexões permaneceriam conectadas até que a sessão de usuário terminasse. Se alguém quiser minimizar o uso da conexão, pode especificar a propriedade unbindLDAPHandleAfterUse no campo Advanced properties e configurá-la com o valor de true. Usando essas propriedades avançadas juntas, é possível alcançar o mínimo de conexões abertas para o servidor do LDAP.

A Melhor Prática para bases de usuário maiores (ultrapassando 50 usuários logados simultaneamente) é usar a propriedade unbindLDAPHandleAfterUse e deixar o conjunto inalterado, já que as 20 conexões não causarão impacto perceptível no servidor do LDAP. Se suas políticas demandarem manter as conexões abertas a um mínimo, desative o conjunto de conexão de consulta.

Microsoft Active Directory

Ao configurar um namespace do Microsoft Active Directory (AD), é possível utilizar o DNS da Microsoft baseado no serviço de localizador que permite encontrar um controlador de domínio disponível em cenários de failover. Isto permite a capacidade de não especificar um nome ou endereço IP do controlador de domínio específico para o host na propriedade Host and port de um namespace AD, mas sim o alias do DNS do domínio como domain.company.com. Isto permitirá que o serviço do DNS retorne um controlador de domínio disponível em todas as situações e como resultado, será considerado uma Melhor Prática que foi adotada por muitos clientes.

Criptografia

O IBM Cognos 10 BI utiliza conceitos Public Key Infrastructure (PKI) para implementar criptografia e a base para suportar o protocolo Secure Socket Layer (SSL) para comunicação de HTTP criptografada. As particularidades vão além do escopo deste documento, mas algumas configurações devem ser alteradas dos padrões para implementar requisitos básicos de segurança e seguir as Melhores Práticas.

Identity

Cada instância instalada, referente a uma instalação de um ou diversos componentes instalados em um único diretório em uma plataforma suportada, possui uma identidade no IBM Cognos 10 BI. Portanto, mesmo duas instâncias instaladas em dois diretórios separados no mesmo pacote são consideradas entidades diferentes. Isto é relevante quando a criptografia, que é usada para criptografar dados salvos, temporários ou transitórios no IBM Cognos 10 BI, entra em jogo. A identidade, cujo conceito se origina do padrão X.509, é definida por um Nome Distinto composto dos campos Server common name, Organization name e Country or region code na seção Security > Cryptography > Cognos > Identity name do IBM Cognos Configuration. Esses campos devem ser alterados do padrão para garantir que cada instalação tenha uma identidade diferente. Isto é mais importante quando a comunicação interna para o IBM Cognos 10 BI será trocado pela SSL, mas em geral, é uma Melhor Prática definir essas propriedades.

A Melhor Prática é especificar uma propriedade Server common name exclusiva. O valor deve ser o nome de Domain Name System (DNS) completo do servidor. No caso de diversas instâncias instaladas em um único host que compartilha um nome de DNS, ajuste a propriedade Organization name em cada configuração para distinguir as instâncias.

Senha de Serviço de CA

Um dos elementos centrais de um PKI é a Autoridade de Certificação (CA) que representa a raiz da confiança e emite e assina certificados, dessa forma, aprovando a identidade de outras entidades. O IBM Cognos 10 BI contém seu próprio serviço de CA localizado no componente do Content Manager e, por padrão, será usado para assinar os certificados usados pelo IBM Cognos 10 BI. Isto é destinado a instalações em que o cliente não executa serviços de CA corporativos ou os requisitos de segurança permitem usar uma CA possível específica ao aplicativo.

Quando salvar configuração em qualquer instância instalada pela primeira vez, será solicitado ao serviço de CA que assine alguns certificados para essa determinada instância instalada, aprovando a identidade da instância. É, portanto, essencial para a integridade e segurança da implementação do IBM Cognos 10 BI que apenas instâncias confiáveis possuem acesso ao serviço de CA. É por isto que o serviço de CA integrado é protegido por uma senha. Esta senha é especificada no IBM Cognos Configuration na propriedade A senha das configurações de Autoridade de Certificação sob Security > Cryptography > Cognos.

A Melhor Prática é alterar esta senha do padrão. Para fazer isso, especifique uma nova senha na configuração do componente de instalação do Content Manager salvando a configuração pela primeira vez. Em seguida, ajuste a senha para todas as outras instâncias antes do salvamento inicial da configuração em cada instalação.

Senhas do Keystore

Os certificados são armazenados em arquivos especiais chamados keystores. Os arquivos estão em formato binário e são criptografados com base em uma senha necessária para acessá-los. O IBM Cognos 10 BI usa três pares-chave diferentes e certificados correlacionados em cada instância, um para criptografia, um para assinar e um para a Autoridade de Certificação. Cada par-chave e certificado emitido para ele são mantidos em um keystore separado, que é protegido por uma senha.

Cada certificado possui suas próprias configurações em uma seção separada no IBM Cognos Configuration em Security > Cryptography > Cognos. As senhas do keystore são especificadas na propriedade <key purpose> password em que <key purpose> é um keystore de assinatura, keystore de criptografia ou keystore de Autoridade de Certificação.

É considerada uma Melhor Prática alterar as senhas do keystore dos padrões antes de primeiro salvar a configuração para a instância.

Cognos Application Firewall

O Cognos Application Firewall (CAF) é uma ferramenta projetada para complementar a infraestrutura de segurança existente do IBM Cognos 10 BI. Este firewall de aplicativo atua como um proxy inteligente para o Dispatcher do IBM Cognos 10 BI e garante que as solicitações de HTTP e XML recebidas enviadas a ele são seguras para serem manipuladas e que as respostas de saída a clientes ou serviços externos estão codificadas e seguras adequadamente.

Seguras, neste contexto, refere-se aos dados de parâmetro, dados POST HTTP e solicitações maliciosas que estão sendo enviadas ao produto com o objetivo de comprometer-se com a segurança do sistema. As formas mais comuns de dados maliciosos são estouros de buffer, ataques de script de site cruzados (links XSS), seja por meio de injeção de script em páginas inválidas, redirecionamento a outros websites ou injeções de SQL e ataques de identificador de sessão ou baseados em cookies. O Cognos Application Firewall protegerá de forma confiável o IBM Cognos 10 BI contra isso e garantirá que apenas dados e parâmetros validados em geral sejam processados.

O Cognos Application Firewall é controlado por configurações feitas no IBM Cognos Configuration em Security > IBM Cognos Application Firewall. A propriedade Enable CAF validation? deve ser configurada como True para que o CAF seja ativado.

Devido a sua contribuição crítica na segurança e estabilidade gerais do sistema, a Melhor Prática é nunca desativar o CAF em um ambiente de produção.

Domínios ou Host Válidos

A propriedade mais importante da configuração do CAF é a lista de domínios ou hosts válidos para permitir redirecionamento ou extração de dados. Isto se refere a funcionalidade como exibição de um feed em um painel de uma URL externa, incluindo figuras de servidores externos, integração do IBM Cognos TM1 Contributor ou redirecionamento a um host do Lotus Connection para criar uma Atividade.

Cada um dos cenários mencionados acima requer que uma entrada seja incluída na lista de domínios ou hosts válidos para o CAF. O CAF comparará a URL usada para acessar um recurso externo (ao IBM Cognos 10 BI) com a lista de domínios ou hosts válidos e apenas se uma correspondência for encontrada, a solicitação será enviada ao recurso externo. Esta lista de nomes de host ou sufixos de domínio explicitamente permitidos aos quais o acesso é permitido geralmente é mencionada como uma white-list. Qualquer URL que não esteja na white-list seria bloqueada pelo CAF. É possível especificar um nome de host na notação NetBIOS (ex. “MyServer”) ou especificar sufixos de domínio usando curingas (ex. *.domain.com) para permitir todos os hosts de um domínio específico.

A lista separada por vírgulas está especificada no IBM Cognos Configuration na propriedade Security > IBM Cognos Application Firewall > Valid domains or hosts .

A Melhor Prática é nomear explicitamente os hosts se possível e usar mais especificadores gerais de sufixo de domínio apenas em redes confiáveis.

Voltar para parte superior

IBM Cognos Connection

No IBM Cognos 10 BI, o portal do IBM Cognos Connection é onde quase todas as configurações relacionadas a segurança e autorização devem ser especificadas e gerenciadas. Isto começa com a definição de quais objetos externos de segurança como usuários, grupos e funções que são trazidos de origem de autenticação externa serão designados a recursos e funções protegidos, bem como a definição de segurança de objetos para conteúdo de aplicativo como pacotes, relatórios e painéis.

O Centro de Informações do IBM Cognos 10 possui uma quantia considerável de informações sobre detalhes e especificadores nesta área, por isso é lá que consultamos o básico e somente descrevemos recomendações adicionais que agregam valor no que já está documentado.

Conceitos de Autorização e Melhor Prática

A primeira etapa no entendimento da autorização para o IBM Cognos 10 BI é entender os objetos envolvidos. Em outras palavras, a autorização funciona definindo permissões para objetos e funções que podem ser protegidos organizados em uma hierarquia mantida no Content Store. Esta hierarquia de objetos é inicializada mediante o primeiro início do IBM Cognos 10 BI quando as tabelas do Content Store estão criadas e pré-preenchidas com objetos e permissões padrão. Entre esses objetos no namespace do Cognos ao qual funções predefinidas e objetos integrados como o grupo Everyone e o usuário Anonymous são incluídos.

Consulte os links a seguir do Centro de Informações do IBM Cognos 10 abaixo para obter mais informações sobre os objetos integrados e funções predefinidas.

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id16486asg_builtin_entries.html#asg_builtin_entries

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id16550PredefinedEntries.html#PredefinedEntries

As permissões padrão, como qualquer outro conjunto de permissões, definem que tipo de acesso os usuários, grupos ou funções de qualquer namespace, incluindo o namespace do Cognos, possuem ao objeto ou função protegidos. Mediante inicialização, não há designações de objetos de segurança externos a quaisquer permissões no namespace do Cognos. A autorização é definida baseada somente em objetos do namespace do Cognos. Este é, na verdade, um bom ponto de partida para implementar a Melhor Prática sobre autorização uma vez que é a abordagem mais flexível e gerenciável para usar e, portanto, a Melhor Prática para trabalhar.

As permissões de acesso inicial podem ser encontradas nos seguintes links do Centro de Informações do IBM Cognos 10,

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id49368asg_contentmamager_hierarchy.html#asg_contentmamager_hierarchy

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id53448asg_bux_access_permissions.html#asg_bux_access_permissions

Para elaborar, a autorização é definida ao designar usuários, grupos e funções a permissões que, por sua vez, são definidas para um objeto que pode ser protegido como um relatório, programação, função ou capacidade que pode ser protegida. Como os usuários podem apenas originar de namespaces externos, o namespace do Cognos não suporta usuários (com exceção do usuário Anonymous integrado), um administrador teria de designar usuários aos objetos do Cognos que podem ser protegidos explicita ou implicitamente. Refere-se implicitamente a designar grupos ou funções dos quais o usuário é membro.

Se em uma permissão, houver referências explícitas a um usuário, essa permissão é dependente do namespace do qual o usuário se origina. Se o namespace ficar indisponível ou o identificador exclusivo do usuário for alterado, esta referência será rompida. Esta é uma das razões pelas quais o identificador exclusivo de um usuário deve se basear em alguns atributos exclusivos globalmente da origem de autenticação e não em informações dependentes estruturalmente. Para servidores LDAP, o DN é, na verdade, um caminho à entrada. Se o usuário for movido na hierarquia de objeto do LDAP, esse caminho será alterado e se o usuário foi identificado no Cognos pelo DN (que é o padrão), o identificador exclusivo do usuário para o Cognos seria alterado e as permissões seriam rompidas. Seguindo a Melhor Prática para identificadores exclusivos mencionados acima, em especial para namespaces do LDAP, você estará blindado contra isso. O Active Directory é seguro, pois o objectGUID não é dependente das informações estruturais. O cenário também aplica-se a referências implícitas, já que a mesma instrução continua true para referências externas de grupo ou função, elas são identificadas pelo identificador exclusivo para o IBM Cognos 10 BI.

Outro desafio é que é possível que a origem de autenticação subjacente possa precisar ser alterada. Embora hoje um LDAP possa ser usado para o ambiente de teste, em produção, uma instância do Active Directory pode ser usada. Isto significa que, neste caso, objetos de namespaces externos foram designados a permissões e funções diretamente e as referências a esses namespaces também serão rompidas, porque um namespace diferente designará identificadores exclusivos diferentes aos objetos.

Para suavizar esses desafios, há uma Melhor Prática simples para autorização - Todas as referências em permissões, recursos e funções protegidas devem apenas ser feitas em grupos ou funções do namespace do Cognos. Isto significa que apenas grupos e funções criados no namespace do Cognos devem ser usados para definir permissões. Por exemplo, para permitir que um determinado conjunto de usuário use um IBM Cognos 10 Studio, seria usado uma das funções predefinidas do namespace do Cognos ou uma nova função seria criada explicitamente para essa finalidade e essa função seria designada ao recurso correspondente. Apesar de isto poder parecer embaraçoso criar diversos grupos ou funções novos no namespace do Cognos, isso realmente agrega grande valor. Os motivos disto são

• Todas as referências a objetos usadas em permissões permanecerão intactas mesmo se os membros da função/grupo mencionados forem alterados.
• O conteúdo do namespace do Cognos pode ser migrado por meio de implementações para outros Sistemas do IBM Cognos 10.
• A criação ou designação de objetos externos a entradas do namespace do Cognos pode ser automatizada pelo SDK do IBM Cognos 10.

Considere um exemplo simples,

Um projeto é desenvolvido em um ambiente de teste usando um provedor LDAP simples com alguns usuários de teste. A equipe de projeto configura autorização de modo que vários objetos de grupo e função específicos do projeto são incluídas no namespace do Cognos, ignorando ou excluindo as entradas de namespace padrão do Cognos. Na próxima etapa, eles designam usuário e grupos do provedor LDAP a entradas de objetos de namespace do Cognos específicas de projeto e definem em seguida permissões para recursos de estúdio, acesso de pacote e até mesmo filtros de segurança do IBM Cognos Framework Manager (filtros que são desenvolvidos no modelo para consulta de dados), com base nos novos objetos de namespace do Cognos.

Quando o desenvolvimento está concluído no ambiente de teste, o aplicativo IBM Cognos 10 que consiste de pacotes, relatórios, etc, é implementado no ambiente de pré-produção que usa o Active Directory com milhares de usuários. Isto implica que diferentes usuários precisarão ser incluídos e referências existentes a objetos de namespace externos serão rompidas.

Entretanto, como o projeto seguiu a Melhor Prática tendo todas as referências em permissões, recursos e funções protegidas feitas somente para grupos e funções do namespace do Cognos, eles podem exportar o aplicativo IBM Cognos 10 para uma implementação que inclui o namespace do Cognos. Isto preservará todas as permissões e no ambiente de destino, a única coisa restante a ser feita será ajustar as designações de usuários e grupos do Active Directory às funções e grupos definidos no namespace do Cognos. Todo o resto permanece intacto sem necessidade de redefinir ou ajustar uma única permissão. Isso economiza muito tempo e mantém o projeto flexível. Além disso, se eles definirem grupos em seu Active Directory para manter os usuários e apenas designarem esses grupos AD aos grupos e funções de namespace do Cognos, eles poderão até gerenciar parte da autorização em AD em vez de no Cognos. Para alguns clientes, isto é importante já que os processos de gerenciamento de acesso ou integração de gerenciamento de identidade podem já estar a postos.

Usuários, Grupos e Funções

Manutenção de Usuário

O IBM Cognos 10 BI armazena seus perfis de usuário e seu conteúdo associado no banco de dados do Content Store.Em um ambiente em que há muitos usuários, isto poderia potencialmente consumir bastante espaço. Usuários que estão sendo removidos de origens de autenticação são uma ocorrência cotidiana na maioria das empresas, portanto, por que manter perfis de usuário e conteúdo desatualizado no Content Store?

A seguinte Melhor Prática presume que o perfil de usuário é excluído no IBM Cognos 10 BI antes de remover a conta do usuário da origem de autenticação.

• Efetue login no IBM Cognos Connection com um ID de usuário que é membro da função Directory Administrator.
• Clique em Launch > IBM Cognos Administration.
• No IBM Cognos Administration, selecione a guia Security .
• Clique no namespace que contém a conta de usuário a ser excluída.
• Localize o usuário cujo perfil precisa ser excluído. Use a função Pesquisar se a hierarquia de namespace for grande e/ou o local da conta de usuário for desconhecido. O ícone de procura é uma lente de aumento e está no canto superior direito.
• Na coluna Ações coluna, clique no linkMore... .
• Clique no link Delete this user's profile para excluir o perfil.
• Clique em OK para confirmar a exclusão do perfil do usuário.

Na maioria dos ambientes, a capacidade de excluir proativamente uma conta de usuário pode não ser uma realidade. Felizmente, o IBM Cognos 10 BI fornece um mecanismo para sincronizar o conjunto de perfis mantidos no Content Store com namespaces externo subjacentes relativos às contas de usuário.

• Como um usuário com acesso administrativo ao IBM Cognos 10, efetue login em todos os namespaces que deverão ser verificados.
• No IBM Cognos Connection, selecione Launch > IBM Cognos Administration.
• Selecione a guia Configuration e clique em Content Administration no menu esquerdo.
• Clique na seta para baixo no botão New Content Maintenance e selecione o link New Consistency Check .
• Insira um nome e descrição opcional e/ou dica de tela, depois clique em Next.
• Selecione o(s) namespace(s) externo(s) a serem verificados pela verificação de consistência e clique em Next. O usuário deve ser autenticado para todos os namespaces selecionados, para que a tarefa funcione efetivamente. Uma autenticação ausente para um namespace neste ponto excluirá o namespace da tarefa.
• Escolha Save and run uma vez para executar a tarefa apenas uma vez, Save and schedule para programar a execução da tarefa para depois e possivelmente em intervalos recorrentes ou Save only para não executar a tarefa e clique em Finish.
• Se for escolhido executar uma vez, especifique um tempo para executar a tarefa de manutenção e depois escolha Find only ou Find and fix quaisquer inconsistências para os namespaces selecionados. Conforme mencionado anteriormente, isto requer que o usuário executando a tarefa seja autenticado agora para todos os namespaces selecionados. Clique em Run para iniciar a tarefa, depois no diálogo seguinte não se esqueça de Visualizar os detalhes da tarefa de manutenção de conteúdo após fechar o diálogo da coluna. Isto encaminhará a uma página que pode ser atualizada clicando em Refresh no canto superior direito até que o status mude para bem-sucedido ou falho. Quaisquer mensagens relativas usuários específicos serão exibidas na lista nesta página.
• Se escolhido programar a tarefa, uma nova programação será salva junto das credenciais confiáveis baseadas na autenticação atual. As credenciais confiáveis incluirão todos os namespaces atualmente autenticados. Especifique o intervalo e tempo de execução e selecione Find only ou Find and fix como o modo a ser usado.

A tarefa executará uma verificação de consistência para verificar se os perfis de usuário armazenados no banco de dados do Content Store estão em sincronia com os usuários no(s) namespace(s) externo(s). Se algum usuário não puder ser localizado na origem de autenticação externa e tiver um perfil existente no Content Store, será logada uma mensagem declarando que a conta não existe mais na origem de autenticação externa. Se o modo Find and Fix não tiver sido selecionado, o perfil do usuário será excluído do Content Store.

É considerada uma Melhor Prática programar uma tarefa de manutenção do Content Store que execute esta ação a pelo menos uma vez ao mês para evitar gasto de espaço no Content Store.

Podem ser encontradas mais informações sobre este tópico no IBM Cognos 10 BI Administration and Security Guide localizado no Centro de Informações do IBM Cognos 10 em

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id8165content_store_maint.html#content_store_maint

Nomenclatura de Função/Grupo

Para ajudar a organizar funções no namespace do Cognos, que pode se tornar muito abundante em uma grande implementação, é recomendado criar pastas para possibilitar uma separação lógica das funções. Os nomes dessas pastas assumem parte do caminho de procura da função. O caminho de procura refere-se ao caminho que descreve o local do objeto na hierarquia de objetos do Content Store. Por exemplo, duas pastas poderiam ser criadas e em cada uma delas, uma função poderia ser criada e o nome da função pode ser o mesmo. Para ilustrar, duas pastas foram criadas no namespace do Cognos, uma chamada Roles East e a outra Roles West. Em cada pasta, uma função chamada Data Administrators foi criada.

Directory > Cognos > Roles East > Data Administrators
Directory > Cognos > Roles West > Data Administrators

As duas funções com o mesmo nome foram permitidas porque o nome da pasta-pai se torna parte do caminho de procura para cada objeto. Ao mesmo tempo, para objetos no namespace do Cognos no ID interno desses objetos, mencionados como CAMID, contém parte de caminho de procura também.

CAMID(":Roles East:Data Administrators")
CAMID(":Roles West:Data Administrators")

Embora este tipo de convenção de nomenclatura funcione e seja suportado no IBM Cognos 10 BI, não é recomendada uma abordagem. Esta técnica pode levar facilmente a erros ao definir permissões ou segurança de objeto, pois os objetos parecem ser os mesmos quando exibidos na lista de membros. Se a pessoa que aplica a segurança não estiver ciente dos dois grupos distintos, será concedido ou negado acesso incorreto a um objeto. A ilustração a seguir mostra um exemplo disto, já que não há contexto adicional fornecido pelo IBM Cognos Connection para identificar adequada e rapidamente qual objeto de função pertence a qual pasta.

Se a implementação requerer absolutamente funções do mesmo nome a serem criadas, usar uma dica da ferramenta pode ajudar a identificar qual função é qual. Então, simplesmente passando o mouse sobre a elipse (…), a dica da ferramenta exibirá o caminho completo ao objeto, como pode ser visto na seguinte ilustração.

Uma convenção de nomenclatura deve ser estabelecida para evitar nomenclatura duplicada para funções e/ou grupos. Uma prática comum é prefixar as entradas com algo como “F_” para função, “G_” para grupo e incluir prefixos adicionais para indicar de onde eles vêm, se necessário. Por exemplo, “F_HR_Approver” e “F_Marketing_Approver” poderiam ser duas funções de caminho de procura diferente ou até o mesmo caminho. No exemplo acima, o prefixo permite distingui-los.

Permissões

O Centro de Informações do IBM Cognos 10 fornece detalhes suficientes sobre permissões e seu uso. É importante entender os conceitos descritos lá para evitar armadilhas.

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id15131AccessPermissions.html#AccessPermissions

A negação tem prioridade

É possível conceder acesso ou negar acesso às entradas. Acesso negado tem prioridade em relação a acesso concedido. Portanto, quando você nega acesso a uma entrada para usuários, grupos ou funções, mas substitui outras políticas de segurança que concedem acesso à entrada, as permissões de concessão e negação de acesso estão em conflito e o acesso à entrada é sempre negado. Por exemplo, um usuário pertence a dois grupos. Um grupo possui acesso concedido a um relatório e o outro grupo possui acesso negado ao mesmo relatório. O acesso a este relatório é negado para o usuário.

Como uma Melhor Prática, negue acesso apenas quando realmente necessário. Normalmente, é uma melhor prática administrativa conceder permissões explicitamente do que negá-las.

Rompendo herança por substituição explícita apenas

Permissões de acesso são adquiridas de entradas-pai. Se permissões de acesso não estiverem definidas explicitamente, a entrada adquire permissões de sua entrada-pai. É possível substituir esta funcionalidade e romper assim a herança de permissões-pai ao definir explicitamente permissões para a entrada-filha.

Os objetos que existem apenas como filhos de outros objetos sempre adquirem permissões de seus pais. Exemplos de tais objetos são especificações de relatórios e saídas de relatórios. Esses objetos podem ser manipulados usando o SDK do IBM Cognos 10, mas não é possível configurar permissões para esses objetos usando o IBM Cognos Connection.

Excluindo grupos e funções predefinidos

Quando um grupo ou função predefinido é excluído do namespace do Cognos, as permissões de acesso baseadas nele também são excluídas. No IBM Cognos 10, é possível restaurá-las criando um novo grupo ou função no namespace do Cognos com exatamente o mesmo nome que levará ao mesmo ID interno (CAMID). Para grupos ou funções externos (aqueles lidos de uma origem de autenticação externa por meio do provedor de autenticação) verificam como seu provedor de autenticação lida com tais situações. Geralmente, não é possível recriar permissões de acesso se estiverem baseadas em IDs, mas é possível se forem baseadas em nomes. Um exemplo para isto seria um namespace LDAP que usa o atributo DN para o identificador exclusivo que é somente uma cadeia de caractere. Porém, como apontado antes, isto suporta o risco de acesso indesejado a perfis de usuários também e não é uma Melhor Prática, então a declaração sobre exclusão de grupos e funções deve ser considerada aplicável em geral. Não remova grupos ou funções a menos que esteja absolutamente certo de que não precisa mais deles. Todas as permissões designadas ao grupo ou função serão perdidas.

Recursos

No IBM Cognos 10 BI, há muitas funções e recursos protegidos que são controlados ao designar permissões a recursos correspondentes. O link a seguir no Centro de Informações do IBM Cognos 10 contém mais informações sobre funções e recursos protegidos. É importante ler as descrições fornecidas e entender completamente o impacto da permissão de acesso a um recurso ou capacidade para seu design de segurança. Há provavelmente mais tarefas sobre isso do que simplesmente remover o grupo Everyone de vários recursos e funções.

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id15670ReportNetSecuredFunctionsandFeatures.html#ReportNetSecuredFunctionsandFeatures

Após a inicialização das permissões padrão do banco de dados do Content Store serem configuradas, o que permite que uma configuração básica pronta para uso seja iniciada. Os objetos e permissões iniciais do Content Store estão documentados no Centro de Informações do IBM Cognos 10 em

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id49368asg_contentmamager_hierarchy.html#asg_contentmamager_hierarchy

Entretanto, as permissões iniciais nem sempre refletem a configuração ideal para seu design nem implementam qualquer modelo de licenciamento ou compatível com tal. São simplesmente um exemplo de uma configuração que poderia ser usada. Para aplicar efetivamente uma política de segurança, deve-se revisitar vários recursos e modificar as permissões padrão. Consulte o link a seguir no Centro de Informações do IBM Cognos 10 para obter mais informações sobre especificação de configurações de segurança

http://publib.boulder.ibm.com/infocenter/cbi/v10r1m0/topic/com.ibm.swg.im.cognos.ug_cra.10.1.0.doc/ug_cra_id16676SpecifySecuritySettingsAfterInstallation.html#SpecifySecuritySettingsAfterInstallation

Recursos não só existem no nível geral, como também no nível de pacote. Use este recurso para controlar o acesso pelos estúdios do IBM Cognos 10 para pacotes e consequentemente origens de dados.

Como uma Melhor Prática, comece definindo seus objetos no namespace do Cognos e, somente então, designe funções/grupos de namespace do Cognos a recursos.

Credenciais de Origem de Dados

A partir do IBM Cognos 10 BI, há um novo recurso pelo qual os usuários podem gerenciar suas próprias credenciais de banco de dados se for concedido acesso ao recurso de signons Manage own data source . Isto pode remover o ônus de manter ou gerenciar um grande número de signons armazenados do administrador do IBM Cognos 10 e estimular os usuários a manterem suas próprias credenciais.

Como uma Melhor Prática, decida se deseja estimular seus usuários a fazerem isto antes de implementar origens de dados. A razão é que se os usuários tivessem permissão de gerenciar seus signons e no futuro, um administrador definisse um signon estático, isto substituiria qualquer credencial salva pelo usuário, assim, potencialmente, rescindindo relatórios e/ou programações. Isto pode ser difícil de achar e pode exigir um esforço significativo quanto à correção. Como resultado, esta é uma decisão tomada melhor antes do início da implementação.

Sobre o autor

Classificar este artigo

Comentários

Voltar para parte superior

Índice

• Introdução
• Diretrizes sobre Proteção de Ambientes IBM Cognos 10 BI
• IBM Cognos Configuration
• IBM Cognos Connection
• Sobre o autor
• Comentários

Conheça a IBM da sua cidade

A IBM está mais perto do que você imagina!

---

Saiba mais