CSA: segurança, senhas, LDAP, SSL, SSO, XSS (somente no local)

ccppmop1591
Use a CSA (
Clarity
System Administration - Administração do Sistema do CA PPM) para gerenciar a segurança, definir as senhas do servidor de banco de dados, ativar o SSL, integrar com servidores LDAP, configurar o SSO e gerenciar URLs externos.
2
Gerenciar senhas do servidor de banco de dados
Use uma senha de servidor para proteger cada servidor. Se o servidor está em um agrupamento, a senha do servidor não concede acesso a outros servidores do agrupamento.
Para minimizar o risco de acesso não autorizado, altere a senha em cada servidor periodicamente.
  1. Altere a senha do servidor de banco de dados. Para obter mais informações, consulte a documentação do banco de dados de terceiros.
  2. Altere a senha da CSA.
  3. Reinicie os serviços depois de alterar a senha do servidor de banco de dados.
Criptografar senhas de servidor
Para proteger um arquivo de senhas do servidor, você pode criptografá-lo. Você pode ativar a criptografia AES de senhas do servidor por meio do arquivo
properties.xml
. Esse método de criptografia requer o uso de uma senha separada (chave) para criptografar as senhas no arquivo
properties.xml
. Mantenha essa chave não criptografada protegida.
A vantagem de usar a criptografia no servidor é que você só precisa proteger essa única chave, que é armazenada em um arquivo acessível pelo servidor. A chave só é necessária na inicialização do servidor. Depois que o
Classic PPM
estiver em execução, você poderá proteger o arquivo-chave com outra camada de criptografia. Se o arquivo for mantido em um local de armazenamento removível, você poderá desconectar o dispositivo e bloquear o arquivo de forma segura.
Quando você ativar a criptografia de senhas do servidor, as senhas em texto não criptografado do arquivo
properties.xml
serão criptografadas da próxima vez que o
Classic PPM
acessar o arquivo. Se a criptografia estiver ativada e você editar o arquivo
properties.xml
diretamente, poderá digitar senhas em texto não criptografado. Da próxima vez que o arquivo for acessado (por exemplo, quando um serviço for implantado ou iniciado), as senhas em texto não criptografado serão criptografadas.
Para criptografar as senhas do servidor, primeiro você deve criar um arquivo-chave válido que seja acessível para o servidor e que contenha o arquivo de propriedades. Cada servidor deve ter acesso ao arquivo-chave (pela rede) ou a uma cópia dele (no disco local do servidor).
Siga estas etapas:
  1. Efetue logon na CSA.
  2. Clique em
    Página inicial
    ,
    Servidores
    .
  3. Clique no nome do servidor.
  4. Clique na guia
    Segurança
    .
  5. Escolha uma opção e clique em
    Salvar
    .
    • Para ativar a criptografia usando uma chave de sistema, selecione a opção
      Utilizando a chave de sistema
      no campo
      Criptografar senhas
      . Essa opção usa uma chave codificada que é fornecida com o produto. Essa é a menos segura das duas opções. Se a chave de uma instalação do
      Clarity
      se tornar conhecida, a chave de todas as instalações também o serão. Essa opção desencoraja eventuais observadores. Se um funcionário estiver vendo a chave do sistema sem más intenções, ele não verá nenhuma senha. No entanto, se um invasor estiver tentando acessar o sistema intencionalmente e já obteve acesso a arquivos no servidor, provavelmente conseguirá descriptografar as senhas.
    • Para ativar a criptografia usando um arquivo-chave personalizado, selecione a opção
      Utilizando o arquivo-chave personalizado
      . Digite o caminho completo e o nome do arquivo-chave personalizado no campo
      Arquivo-chave
      . Essa opção exige que você crie um arquivo-chave e o torne acessível para todos os servidores que estiverem executando o
      Classic PPM
      . O arquivo-chave fica devidamente protegido, de modo que um invasor se depararia com a tarefa praticamente impossível de descriptografar as senhas sem uma chave.
      Se você criptografa senhas com um arquivo-chave personalizado, altere esse arquivo. Caso contrário, as senhas serão perdidas (não será possível descriptografá-las). Nesse caso, você deve inserir novamente as senhas.
Alterar senhas do servidor de banco de dados
Siga estas etapas:
  1. Altere a senha do servidor de banco de dados no próprio banco de dados.
    Para obter mais informações, consulte a documentação do banco de dados de terceiros.
  2. Altere a senha do servidor de banco de dados na CSA com a nova senha que você inseriu. Efetue logon na CSA.
  3. Interrompa os serviços Aplicativo
    Clarity
    (app) e Segundo plano do
    Clarity
    (bg) executando as seguintes ações:
    1. Clique em Página inicial, Todos os serviços.
    2. Marque as caixas de seleção ao lado de Aplicativo
      Clarity
      e Segundo plano do
      Clarity
      e clique em Interromper.
      Os serviços são interrompidos.
  4. Clique em Página inicial, Servidores.
  5. Clique em Propriedades e na guia Banco de dados.
  6. Na seção Conexão interna: Niku, preencha os seguintes campos:
    • Senha
      Digite uma nova senha.
    • Confirmar senha
      Digite a senha novamente.
  7. Clique em Salvar.
  8. Reinicie os serviços Segundo plano do
    Clarity
    (bg) e Aplicativo
    Clarity
    (app):
    1. Clique em Página inicial, Todos os serviços.
    2. Marque as caixas de seleção ao lado de Segundo plano do
      Clarity
      (bg) e Aplicativo
      Clarity
      (app) e clique em Iniciar.
Configurar o SSL (Secure Sockets Layer) no Apache Tomcat
SSL é um protocolo de transmissão de dados entre os nós. Ele usa um método de criptografia para proteger os dados contra o acesso não autorizado e se baseia em duas chaves: uma chave pública, conhecida de todos, e uma chave privada (secreta), conhecida apenas pelo destinatário da mensagem.
  • Como as etapas desta seção se referem a componentes de terceiros, o suporte é limitado.
  • Decida onde você pretende instalar o SSL. Por exemplo, para melhorar o desempenho, use outro servidor, não o servidor de aplicativos.
  • O comando
    keytool
    do Java representa uma forma conhecida de criação e gerenciamento de certificados SSL. Há outras ferramentas e comandos disponíveis.
  • As etapas relacionadas se aplicam a muitos, mas não a todos os ambientes. Além disso, as etapas podem ser até inadequadas para alguns ambientes. Você deve usar, especificamente, os certificados autoassinados (não adquiridos de um fornecedor certificado, como Verisign ou Thawte). Esses certificados podem exigir várias instalações antes de instalar o certificado real. Os nomes desses certificados variam.
  • Siga as instruções do seu fornecedor de certificado SSL em vez de depender unicamente das etapas dessa página. Os fornecedores podem exigir que você modifique as etapas ou comandos específicos.
  • Para fins de teste, use a chave privada fornecida com o
    Classic PPM
    .
Quando o protocolo HTTP é usado junto com o SSL, é chamado de "HTTPS".
Quando o SSL estiver ativado no serviço do aplicativo, todos os dados transferidos entre aplicativos cliente (como um navegador da web ou o Open Workbench) serão criptografados. Os dados são criptografados antes de serem enviados e são descriptografados antes de serem recebidos. Sem a criptografia SSL, uma entidade não autorizada poderia ler os dados e roubar informações confidenciais, como nomes de usuário e senhas.
Siga estas etapas:
As etapas dessa página se aplicam apenas quando você instala o
Classic PPM
pela primeira vez. Você também poderá instalar um certificado renovado quando o antigo expirar.
4
4
Gere um par de chaves pública e privada
Use o comando
keytool
do Java para gerar um par de chaves pública e privada e para criar uma CSR (solicitação de assinatura de certificado).
As etapas desta página fornecem somente os parâmetros Java necessários. Para obter informações completas sobre todos os parâmetros para os comandos Java, consulte o site de documentação da Oracle.
Antes de colocar o sistema em produção, crie um arquivo de keystore para a chave privada e distribua-o para todos os servidores de aplicativos. Se já tiver outro arquivo de keystore, você também poderá usá-lo com o
Classic PPM
.
Siga estas etapas:
  1. Abra o servidor de aplicativos do
    Classic PPM
    , abra um prompt de comando e gere um par de chaves pública e privada emitindo o seguinte comando:
    keytool -genkey -keystore /<Clarity Home Directory>/config/.keystore -keyalg RSA -storepass keystore
  2. Defina os seguintes valores:
    • -genkey
      Essa opção gera um keystore, se ainda não existir um. O keystore contém a chave pública e a chave pública modelo.
    • keystore
      Especifica o caminho e o nome de arquivo do arquivo de keystore. Por padrão, o keystore é denominado
      .keystore
      e está localizado no diretório
      /<Diretório local do Clarity>/config/
      .
    • keyalg
      Especifica o algoritmo a ser usado para gerar o par de chaves (neste exemplo, RSA).
    • storepass
      A senha usada para proteger o keystore (que deve ter ao menos seis caracteres). Essa senha é fornecida para todos os comandos que acessam o keystore.
  3. Quando solicitado, digite as informações adequadas sobre a organização.
  4. Pressione
    Enter
    quando o sistema solicitar que você digite a senha da chave. A senha da chave e a senha do keystore devem ser as mesmas.
Para obter um certificado autoassinado, exporte o arquivo .cer da chave privada que tiver gerado e ignore o próximo procedimento. Não crie uma CSR (solicitação de assinatura de certificado). Nesse caso, não é necessário ter uma CSR. Para exportar o arquivo, use o seguinte comando:
keytool –export -file <file_name.cer> -keystore <ClarityHome/config/.keystore> -storepass keystore
Criar uma CSR (Certificate Signing Request - Solicitação de assinatura de certificado)
Para sistemas de produção, substitua o certificado de teste por um certificado atestado real. Para obter um certificado atestado, crie uma solicitação de assinatura de certificado (CSR - Certificate Signing Request) e a envie para uma autoridade de certificação. A autoridade de certificação gera um certificado real que autentica a chave pública. A CSR é uma solicitação de um certificado SSL real com base nas informações do seu sistema. A CSR não é instalada. Você instala o certificado real fornecido pelo seu provedor de SSL em resposta à CSR. Sempre siga as instruções do seu provedor de SSL. Geralmente, são necessários comandos específicos para instalar certificados raiz ou intermediários. Os fornecedores podem exigir a instalação de outros certificados.
Siga estas etapas:
  1. No servidor de aplicativos do
    Classic PPM
    , abra um prompt de comando e emita o seguinte comando:
    keytool -certreq -keystore /<Clarity Home Directory>/config/.keystore -keyalg RSA -file ca_ppm.csr
  2. Quando uma senha for solicitada, digite a senha padrão (
    keystore
    ).
  3. Defina os seguintes valores:
    • -certreq
      Gera uma solicitação de assinatura de certificado (CSR).
    • keystore
      Especifica o caminho e o nome de arquivo do arquivo de keystore. Por padrão, o keystore é denominado
      .keystore
      e está localizado no diretório <pasta principal do Clarity>/config/.
    • keyalg
      Especifica o algoritmo (RSA) a ser usado para gerar o par de chaves.
    • file
      Especifica o nome (ca_ppm.csr) do arquivo de solicitação de certificado gerado.
  4. Em um navegador da web, abra o site da autoridade de certificação e forneça o conteúdo do arquivo CSR que você gerou.
    Use o processo especificado pela autoridade de certificação. A CSR é fornecida pela autoridade de certificação.
  5. Copie o novo certificado (por exemplo, ca_ppm.cer) fornecido pelo seu provedor de SSL no servidor de aplicativos do
    Classic PPM
    .
    A chave privada não é afetada.
  6. Faça backup do arquivo de keystore, copiando-os em outro volume. Enquanto você espera pelo certificado real, não modifique o arquivo keystore. Quaisquer alterações podem causar problemas quando você importar o certificado real. Se você não puder importar o certificado real ou se alguém alterar o arquivo, será possível começar de novo. Não gere outra CSR, ou aguarde por uma nova cópia do certificado real. Economize tempo tendo um backup do arquivo de keystore.
Instalar os certificados
Se você tiver recebido um certificado do seu fornecedor de SSL, importe a resposta da autoridade de certificação e substitua o certificado autoassinado por uma cadeia de certificados. No fim da cadeia está o certificado emitido pela autoridade de certificação para autenticar a sua chave pública. O próximo certificado da cadeia é o que autentica a chave pública da autoridade de certificação.
Importe os certificados para criar uma cadeia de certificados. Para os certificados autoassinados ou certificados criados nos seus próprios servidores de certificado, o criador fornece os certificados. Como criador, você configurar as relações de confiança/cadeias para fazer com que o SSL funcione perfeitamente como certificados que você compra de fornecedores de SSL. Importe qualquer certificado raiz ou intermediário, outros certificados e o certificado real fornecido pelo seu provedor de SSL em resposta à CSR.
Siga essas etapas para criar um arquivo de keystore que contenha a chave privada combinada com o certificado assinado da autoridade de certificação.
Siga estas etapas:
  1. Abra o servidor de aplicativos do
    Classic PPM
    , abra um prompt de comando e emita o seguinte comando:
    keytool -import -keystore /<Clarity Home Directory>/config/.keystore -keyalg RSA -file
    Clarity
    - Source.cer -trustcacerts
    Talvez você precise importar o certificado intermediário raiz da autoridade de certificação para o seu arquivo keystore antes de importar o seu certificado. Consulte a documentação de terceiros da autoridade de certificação para obter mais informações.
  2. Digite a senha do keystore e pressione Enter.
  3. Digite
    yes
    .
Distribuir o arquivo de keystore para servidores de aplicativos
Se houver mais de um servidor com serviços de aplicativo, distribua o keystore para todos eles.
Siga estas etapas:
  1. Efetue logon na CSA.
  2. Interrompa todos os serviços executando as seguintes ações:
    1. Clique em Página inicial, Todos os serviços.
    2. Selecione todos os serviços e clique em Parar.
  3. Clique em Distribuir, Distribuir tudo.
  4. Marque a caixa de seleção ao lado de todos os servidores e clique em Distribuir.
  5. Reinicie todos os serviços executando as seguintes ações:
    1. Clique em Página inicial, Todos os serviços.
    2. Selecione todos os serviços e clique em Iniciar.
      O arquivo de keystore é distribuído para os servidores com serviços de aplicativo.
Definir o local e a senha do arquivo de keystore
Repita estas etapas para cada servidor do agrupamento.
Siga estas etapas:
  1. Efetue logon na CSA.
  2. Clique no ícone Propriedades para alterar o servidor.
  3. Clique na guia Segurança.
  4. Preencha os campos a seguir e salve:
    • Keystore de SSL
      Informe o local do arquivo de keystore. Se você deixar o campo vazio, será usado o valor padrão
      <Diretório local do clarity>/config/.keystore
      .
    • Senha do SSL
      Digite a senha do keystore (o valor padrão é
      keystore
      ).
    • Confirmar senha
      Digite a senha do keystore novamente.
  5. Interrompa e inicie todos os serviços executando as seguintes ações:
    1. Abra Início e clique em Todos os serviços.
    2. Clique no ícone Selecionar tudo, para selecionar todos os serviços, e clique em Parar.
    3. Clique no ícone Selecionar tudo, para selecionar todos os serviços, e clique em Iniciar.
Ativar o SSL em cada servidor
A configuração de Manuseio de SSL determina como o aplicativo se comporta em relação ao SSL. A configuração contém as seguintes opções:
  • Derivar da configuração de portas (implícito)
    Deriva se as portas do servidor web estiverem ativadas ou desativadas. Essa configuração emula o comportamento do SSL das releases anteriores (antes da Versão 13.0).
  • O SSL foi usado, porém processado internamente (externo)
    Especifica que o balanceador de carga ou outro terminal anterior encerre o SSL fora do servidor de aplicativos.
  • Alternar para HTTPS somente em páginas sensíveis (híbridas)
    Especifica que o
    Classic PPM
    alterna ativamente entre HTTP e HTTPS para páginas seguras e não seguras.
  • Oferece suporte a HTTP e HTTPS sem alternância (ambos)
    Especifica que ambos, HTTP e HTTPS, estão ativos. Não tente alternar entre os dois.
  • Oferece suporte somente ao HTTPS (completo)
    Especifica todos os SSL. Tudo é criptografado. Alterne para SSL, se necessário.
  • Oferece suporte somente ao HTTP (nenhum)
    Não especifica o SSL. Tudo fica em branco.
Essas etapas explicam como configurar o manuseio de SSL com a opção Oferece suporte somente ao HTTPS. Se você selecionar Derivar da configuração de portas como opção de Manuseio de SSL, serão necessárias as seguintes configurações de campo adicionais para cada instância de aplicativo:
  • HTTP ativado
    Desmarque a caixa de seleção.
  • HTTPS ativado
    Marque a caixa de seleção.
Para ativar o SSL, conclua estas etapas para cada servidor:
Siga estas etapas:
  1. Efetue logon na CSA.
  2. Clique em Página inicial, Servidores.
  3. Clique no nome do servidor que você deseja configurar.
  4. Clique na guia Propriedades.
  5. Clique na guia Aplicativo.
  6. Na seção Servidor de aplicativos, preencha o seguinte campo:
    • Manuseio de SSL
      Marque a opção denominada
      Oferece suporte somente ao HTTPS
      .
  7. Preencha os seguintes campos de todas as seções Instância do aplicativo
    que estiverem associadas ao servidor:
    • Porta HTTPS
      Digite a porta que deseja usar para o tráfego HTTPS.
    • URL de entrada HTTPS
      Digite o URL HTTPS (incluindo a porta).
      Exemplo:
      https://ca_ppm.mycompany.com:8443
  8. Salve as alterações.
  9. Interrompa e reinicie os serviços de aplicativo executando as seguintes ações:
    1. Clique em
      Página inicial
      ,
      Todos os serviços
      .
    2. Selecione cada serviço que deseja parar e clique em
      Parar
      .
    3. Selecione cada serviço que deseja reiniciar e clique em
      Iniciar
      .
Ativar SSL para páginas protegidas por senha
É possível ativar o SSL somente para páginas que contêm senhas de usuário. Com essa configuração, os usuários são redirecionados automaticamente entre páginas seguras e não seguras do aplicativo. O redirecionamento será possível com a ativação simultânea dos protocolos HTTP e HTTPS.
Com essa configuração, ambas as portas nos sistemas operacionais UNIX devem ser maior do que 1024. Como exceção, você pode usar os números de porta regulares caso use um comando SUDO para iniciar os serviços com permissões de raiz. Essa exceção não se aplica quando você estiver usando instalações com carga balanceada ou com proxy. Nesses casos, use intervalos de porta personalizados. Em ambientes que não sejam de produção, você ainda poderá optar por não usar o balanceador de carga (com o descarregamento de SSL opcional). Você ainda
poderia
usar as portas tradicionais anteriores a 1024.
Siga estas etapas:
  1. Efetue logon na CSA.
  2. Clique em
    Página inicial
    ,
    Servidores
    .
  3. Clique no ícone
    Propriedades
    do servidor que deseja configurar.
  4. Clique na guia
    Aplicativo
    .
  5. Na seção
    Servidor de aplicativos
    , preencha o seguinte campo:
    • Manuseio de SSL
      Selecione a opção
      Alternar para HTTPS somente em páginas sensíveis
      .
  6. Preencha os seguintes campos de todas as seções Instância do aplicativo
    que estiverem associadas ao servidor:
    • HTTP ativado
      Marque a caixa de seleção.
    • HTTPS ativado
      Marque a caixa de seleção.
    • Porta HTTPS
      Digite a porta a ser usada para o tráfego HTTPS.
      No UNIX, os números de porta HTTP e HTTPS devem ser maiores que 1024, a menos que você use um comando SUDO.
    • URL de entrada HTTP
      Digite o URL HTTPS (incluindo a porta).
      Exemplo:
      http://ca_ppm.mycompany.com:8080
    • URL de entrada HTTPS
      Digite o URL HTTPS (incluindo a porta).
      Exemplo:
      https://ca_ppm.mycompany.com:8443
  7. Configure mais servidores.
  8. Pare e reinicie cada serviço de aplicativo:
    1. Clique na guia
      Serviços
      .
    2. Selecione cada serviço que deseja parar e clique em
      Parar
      .
    3. Selecione cada serviço que deseja reiniciar e clique em
      Iniciar
      .
Ativar uma conexão segura do JDBC entre os servidores de bancos de dados e aplicativos do
Clarity
em hosts separados com SSL
Para conformidade com diretivas de segurança de informações e outras estruturas, você pode precisar criptografar aplicativos, como ao mover o
Clarity
para o AWS, Azure, entre outros servidores de nuvem no nível do banco de dados e do aplicativo.
Você pode definir determinados parâmetros na sequência de caracteres de conexão do banco de dados no arquivo de propriedades do
Clarity
para ativar o SSL.
  1. Siga as etapas acima para instalar o certificado SSL no Oracle ou SQL Server.
  2. Adicione os seguintes atributos no elemento do banco de dados do arquivo de propriedades do
    Clarity
    :
    1. Adicionar
      useURL="true"
    2. Ao atributo
      url
      , adicione
      encryptionmethod=SSL
      , como mostrado abaixo:
    <database id="Niku" vendor="mssql" serviceName="niku" password="xxxxxx" upgradeStatus="upgradeNotNeeded" schemaName="niku" username="xxxxxxx" host="sqlservere.clarity.com" url="jdbc:clarity:sqlserver://sqlserver.clarity.com:1433;DatabaseName=NNNNN_STAGE;InsensitiveResultSetBufferSize=0;ProgramName=Clarity;encryptionmethod=ssl;" driver="com.ca.clarity.jdbc.sqlserver.SQLServerDriver" instanceName="" serviceId="NNNNN_STAGE" jndiDatabaseId="jdbc/NikuDS" useURL="true"/>
  3. A criptografia de rede do Oracle também é suportada. Adicione o seguinte parâmetro no URL do seu JDBC:
    DataIntegrityLevel=required
  4. Abra o arquivo
    sqlnet.ora
    e confirme se ele contém as seguintes configurações de parâmetro:
    SQLNET.ENCRYPTION_SERVER = required
    SQLNET.CRYPTO_CHECKSUM_SERVER = required
    A configuração
    required
    ativa o serviço de criptografia ou integridade e não permite a conexão se o cliente não estiver ativado para o serviço de segurança. Esta é a configuração padrão para implantações de banco de dados no serviço de nuvem de banco de dados.
  5. Reinicie os serviços.
Para verificar se a conexão de rede está criptografada por SSL, execute um rastreamento de pacote wireshark e filtre o endereço IP do banco de dados e o número da porta do SQL Server definidos na sequência de caracteres de conexão.
Configurar o
Classic PPM
para trabalhar com descarregadores de SSL
Em um serviço de aplicativo de SSL, os dados transferidos entre aplicativos cliente são criptografados antes de serem enviados e são descriptografados antes de serem recebidos. A criptografia de pacotes SSL pode causar um desempenho mais lento em servidores de aplicativos. Para lidar com SSL, use um balanceador de carga ou servidor proxy em vez dos servidores de aplicativos.
Se for usado um offloader SSL externo, como um balanceador de carga ou um proxy reverso, o offloader SSL criptografará o tráfego HTTP do
Classic PPM
. O off-loader se comunica com o cliente usando HTTPS. Essa configuração pode melhorar o desempenho, mas requer um certo grau de configuração do offloader e do dispositivo no
Classic PPM
.
Certifique-se de que qualquer off-loader de SSL que você usar tenha uma função de regravação de URL ativada.
Siga estas etapas:
  1. Efetue logon na CSA.
  2. Clique em
    Página inicial
    ,
    Servidores
    .
  3. Clique no ícone
    Propriedades
    do servidor que deseja configurar.
  4. Clique na guia
    Aplicativo
    .
  5. Na seção
    Servidor de aplicativos
    , preencha o seguinte campo:
    • Manuseio de SSL
      Marque a opção
      O SSL foi usado, porém processado internamente
      .
  6. Para quaisquer instâncias de aplicativo que não a do servidor de aplicativos do
    Classic PPM
    , faça as seguintes configurações:
    • HTTP ativado
      Especifica que o HTTP seja usado para fazer a comunicação. Marque a caixa de seleção.
    • URL de entrada HTTP
      Indica o URL que você deseja usar para o tráfego entre o
      Classic PPM
      e um cliente. Um offloader SSL se torna o front-end do
      Classic PPM
      , da mesma forma que um balanceador de carga é o front-end em um ambiente de vários servidores. Como o URL do off-loader de SSL é seguro, digite um URL HTTPS neste campo usando o seguinte formato:
      https://<nome do host>:CA Portal.
    • HTTPS ativado
      Essa caixa de seleção não se aplica quando você utiliza um off-loader SSL. Desmarque essa caixa de seleção.
  7. Salve as alterações.
Configurar o
Clarity
para usar HTTPS
As etapas abaixo destinam-se a um ambiente não agrupado do
Clarity
.
Neste procedimento, você gera um keystore e uma solicitação de certificado. Depois de importar os certificados, faça ajustes na CSA.
Para uma implementação de arquitetura com balanceamento de carga, ative o SSL com a instalação do certificado no balanceador de carga, e não nos servidores de aplicativos. Na guia
Aplicativo
, altere o valor do campo
Manuseio de SSL
para
O SSL foi usado, porém processado internamente
.
Siga estas etapas:
  1. Efetue logon no servidor que hospeda o
    Clarity
    .
  2. Vá para um diretório para armazenar a chave privada. Por exemplo:
    C:\ppm150101
  3. Prepare as respostas para os prompts na etapa 5 agora, com antecedência.
  4. Gere um keystore com o seguinte comando: "keytool -genkey -keystore C:\ppm15101\keystore.jks -keyalg RSA -storepass changeit"
    Observe que "Keystore.jks" é o nome do keystore, com a senha "changeit". Altere a senha para uma mais forte ao executar esse comando.
  5. Serão exibidos vários prompts solicitando o preenchimento de detalhes do servidor e da organização. Use as informações que você preparou na etapa 3. As autoridades de certificação podem fornecer-lhe todos os detalhes necessários. Entre em contato com eles caso não consiga responder todos os prompts sozinho.
  6. Quando
    o nome e o sobrenome
    forem solicitados, insira o nome completo do servidor sem
    http://
    nem
    https://
    no nome.
  7. Gere uma solicitação de certificação:
    keytool -certreq -keystore C:\ppm15101\keystore.jks -keyalg RSA -file myRequest0.cer
  8. Para obter um certificado para seu servidor, envie esse arquivo para a autoridade de certificação.
  9. Verifique se possui esses certificados prontos antes da importação para o keystore:
    1. certificado do servidor
    2. certificado intermediário
    3. certificado raiz
      (Consulte a autoridade de certificação sobre os certificados raiz e intermediário)
  10. Importe o certificado raiz (substituindo o nome do keystore, o caminho, o nome do certificado, o patch e outros parâmetros):
    keytool -import -keystore C:\ppm15101\keystore.jks -keyalg RSA -file root.cer -trustcacerts -alias root
  11. Importe o certificado intermediário:
    keytool -import -keystore C:\ppm15101\keystore.jks -keyalg RSA -file intermediate.cer -trustcacerts -alias intermediate
  12. Importe o certificado do servidor:
    keytool -import -keystore C:\ppm15101\keystore.jks -keyalg RSA file server.cer -trustcacerts -alias server
Fazer alterações na CSA
  1. Efetue logon na CSA e clique na guia
    Segurança
    .
  2. No campo
    Keystore de SSL
    , insira o caminho totalmente qualificado para seu keystore.
  3. Preencha os campos
    Senha de SSL
    e
    Confirmar senha
    .
  4. Clique na guia
    Aplicativo
    .
  5. Altere
    Manuseio de SSL
    para
    Oferece suporte a HTTP e HTTPS sem alternância
    .
  6. Na seção
    Instância do aplicativo: app
    , selecione
    HTTPS ativado
    .
  7. Altere o valor em Porta HTTPS para um número alocado para o aplicativo
    Clarity
    (depende da organização). Por exemplo, o número da porta pode ser 8043
  8. Altere URL de entrada HTTPS para o nome exato do servidor fornecido durante a geração do keystore.
  9. Reinicie o serviço do aplicativo
  10. Verifique se o HTTPS está funcionando. Para isso, navegue usando HTTPS (use o número da porta e o URL corretos. Por exemplo, o URL pode ser https://nomedoservidor.organizacao.com:8043/)
  11. Altere Manuseio de SSL para Oferece suporte somente ao HTTPS.
  12. Reinicie o serviço do aplicativo.
Se você importou um certificado da maneira incorreta e deseja excluí-lo, um comando como este pode ser usado: "keytool -keystore c:\ppm15101\keystore.jks -alias root -delete"
Outro comando muito útil para listar todos os certificados em um keystore é: "keytool -keystore c:\ppm15101\keystore.jks -list" e para ativar o modo detalhado, use "keytool -keystore c:\ppm15101\keystore.jks -list -v"
Finalmente, os caminhos mencionados aqui destinam-se a um sistema operacional Windows. Altere-os para a convenção de especificação de caminho do Linux, caso o aplicativo tenha sido criado com base nesse sistema operacional. Tudo, exceto os caminhos, permanece igual.
Integrar o
Classic PPM
ao LDAP (Lightweight Directory Access Protocol)
Pode ser benéfico usar uma interface LDAP (Lightweight Directory Access Protocol) para autorizar o acesso em todos os aplicativos. Um servidor de diretório central controla o acesso para que os usuários possam ter um nome de usuário e senha para todos os aplicativos. Há suporte às seguintes opções:
  • O protocolo LDAP v2 (simples) usa um pequeno subconjunto da funcionalidade LDAP que inclui autenticação (texto não criptografado ou SSL), ligação e pesquisa.
  • Controle LDAP v3 para resultados em páginas, como definido no RFC 2696.
Para sincronizar os usuários entre o servidor de diretório e o
Classic PPM
, o sistema faz uma busca em lote dos usuários no servidor de diretório. As definições de configuração de LDAP do
Classic PPM
especificam o tamanho do lote.
Os cookies gerados por sessão contêm um token que é usado para acessar os dados da sessão. O token é mantido no cache para ambientes com um único aplicativos ou em um banco de dados para ambientes agrupados. O navegador da web do usuário deve aceitar os cookies do
Classic PPM
que são gerados por sessão para que eles não sejam gravados em disco. Quando o usuário faz logoff, as informações da sessão no banco de dados e em cache correspondentes ao cookie são excluídas.
Ao integrar o
Classic PPM
com um servidor LDAP, você obtém os seguintes benefícios:
  • Simplificação da administração de nome e senha do usuário. A TI só precisa gerenciar um par de nome de usuário e senha de um usuário.
  • Suporte para autenticação. A equipe de TI só precisa cuidar de um lugar em que os usuários podem ter problemas de autenticação.
  • Aprimoramento da usabilidade. Os usuários só precisam lembrar de um único nome de usuário e de uma senha.
  • Aprimoramento na gestão de usuários. O nome de usuário e as informações de email podem ser armazenados no LDAP.
  • Aprimoramento da segurança. Usar um único nome de usuário e uma única senha facilita o uso de senhas complexas e possibilita alterá-las com mais frequência. A probabilidade de escolher uma senha familiar é reduzida quando há somente uma senha para lembrar.
A rotina LDAP - Sincronizar usuários novos e alterados sincroniza as entradas LDAP. A rotina armazena a data e hora da última execução bem-sucedida, além de armazenar informações na tabela CMN_DIRECTORY_SERVERS do banco de dados. A rotina sincronizará as entradas durante a próxima execução em segundo plano. A rotina sincronizará apenas as entradas de usuário recém-criadas ou alteradas cujo carimbo de hora seja maior do que o valor encontrado na propriedade CMN_DIRECTORY_SERVERS.LAST_SYNC_DATE.
  • O
    Classic PPM
    não verifica se um usuário em um grupo ou em uma pesquisa especificada pela CSA está ativo ou inativo no LDAP. O
    Classic PPM
    verifica apenas se o usuário está presente em um grupo do
    Classic PPM
    ou se um atributo que está sendo pesquisado está presente no
    Classic PPM
    .
  • O
    Classic PPM
    não reconhece os grupos aninhados no LDAP. Antes de executar a rotina
    LDAP - Sincronizar usuários novos e alterados
    ou
    LDAP - Sincronizar usuários obsoletos
    , certifique-se de que os usuários estejam associados a um grupo do
    Clarity
    que possa ser encontrado pela pesquisa da CSA. Os usuários em grupos aninhados dentro do grupo LDAP do
    Classic PPM
    não são verificados quando as rotinas de sincronização LDAP são executadas.
  • Um usuário que esteja desativado no servidor LDAP será desativado no
    Classic PPM
    da próxima vez que a rotina de sincronização for executada. Se um usuário for reativado no servidor LDAP, ele não será reativado no
    Classic PPM
    ; será necessário reativar o recurso.
Antes de implementar o LDAP, escolha um servidor LDAP compatível.
Configure o
Classic PPM
para a autenticação LDAP em cada servidor que estiver executando um serviço de aplicativo. Para executar essas etapas, configure um servidor LDAP. Se você tiver um agrupamento de servidores do
Classic PPM
, repita essas etapas em cada servidor do agrupamento.
Siga estas etapas:
  1. Crie um recurso como sendo o usuário de teste a ser usado para acessar o
    Classic PPM
    como usuário LDAP.
    O usuário de teste deve ter a mesma ID de usuário no
    Classic PPM
    que o usuário sAMAccountName do LDAP no Microsoft Active Directory ou na interface de outras implementações de LDAP.
  2. Decida como definir os usuários LDAP que têm acesso ao
    Classic PPM
    .
    Você pode ativar a autenticação em grupo especificando um grupo ou criando uma combinação de atributo/valor no LDAP, ou ambos. Você pode definir essa configuração na página de segurança
    Servidor: Propriedades
    na CSA.
  3. Defina as propriedades do servidor LDAP.
  4. Configure o
    Classic PPM
    para a autenticação.
  5. Interrompa e reinicie todos os serviços do
    Classic PPM
    .
Definir as propriedades do servidor LDAP
Você pode definir as propriedades do servidor LDAP na CSA.
Siga estas etapas:
  1. Efetue logon na CSA.
  2. Clique no ícone
    Propriedades
    do servidor que deseja configurar.
  3. Clique na guia
    Segurança
    .
  4. Na seção
    Servidor LDAP
    , preencha os campos:
    • URL:
      define o URL do servidor LDAP. Se o servidor LDAP estiver ativado para SSL, use o protocolo LDAPS no URL (em vez do protocolo LDAP padrão).
    • Contexto raiz:
      define o contexto de nomenclatura LDAP, por exemplo: "ou=Pessoas, dc=niku, dc=com".
    • Usuário de pesquisa:
      define o nome de usuário com as credenciais apropriadas para ligação ao servidor LDAP.
    • Senha:
      define a senha e a confirma no campo Confirmar senha.
    • Filtro da pesquisa:
      define a sequência de caracteres do filtro de pesquisa (conforme definido no RFC 2254).
    • Formato de data/hora:
      define o formato de data e hora usado pelo servidor LDAP.
    • Nome do grupo:
      ativa a autenticação em grupo. Digite o nome do grupo e, no campo Identificador do grupo, digite a ID do grupo.
    • Permitir usuários que não sejam LDAP:
      indica que é permitido o acesso ao
      Classic PPM
      usando métodos de autenticação alternativos.
    • Usar associações do grupo
      : marque esta caixa de seleção (desmarcada por padrão) se for necessário melhorar o desempenho com a rotina LDAP - Sincronizar usuários obsoletos. A rotina usa associações do grupo na sincronização e requer uma relação inversa dos usuários com os grupos em seu LDAP. O valor padrão é
      memberOf
      . No entanto, você pode especificar outro valor no próximo campo.
    • Identificador do grupo para usuários
      : se precisar especificar outro valor, além do atributo padrão
      memberOf
      , insira o identificador de grupo suportado pelo seu LDAP aqui.
      Usar associações do grupo
      e
      Identificador do grupo para usuários
      estão disponíveis no patch 15.5.1.1.
  5. Clique em
    Salvar
    .
  6. Interrompa e inicie todos os serviços do
    Classic PPM
    executando as seguintes ações:
    1. Clique em
      Página inicial
      ,
      Todos os serviços
      .
    2. Clique no ícone
      Selecionar tudo
      , para marcar a caixa de seleção ao lado de cada serviço, e clique em
      Parar
      .
    3. Clique no ícone
      Selecionar tudo
      , para marcar a caixa de seleção ao lado de cada serviço, e clique em
      Iniciar
      .
  7. Clique em
    Salvar
    .
  8. Na CSA, clique na guia
    Aplicativo
    .
  9. Na seção
    Servidor de aplicativos
    , selecione
    Usar LDAP
    e clique em
    Salvar
    .
Sincronização LDAP
Estão disponíveis as seguintes rotinas de sincronização LDAP, que funcionam em conjunto para sincronizar o
Classic PPM
com o LDAP:
  • Rotina LDAP - Sincronizar usuários novos e alterados
    Esta rotina sincroniza os registros LDAP com registros do
    Classic PPM
    sincronizando os usuários que você adiciona ao grupo LDAP do
    Classic PPM
    . A rotina também ativa os usuários no servidor do
    Classic PPM
    . Se você usar a opção de filtro de pesquisa e alterar um atributo para um usado pelo
    Classic PPM
    , o usuário será ativado no servidor do
    Classic PPM
    . A ativação ocorrerá da próxima vez que a rotina for executada. A rotina armazena a data e hora da última execução bem-sucedida na tabela CMN_DIRECTORY_SERVERS do banco de dados. A rotina sincroniza apenas as entradas de usuário recém-criadas ou alteradas. O carimbo de hora da sincronização deve ser maior do que o valor encontrado no campo CMN_DIRECTORY_SERVERS.LAST_SYNC_DATE.
  • Rotina LDAP - Sincronizar usuários obsoletos
Esta rotina desativará os usuários que você remover do grupo LDAP do
Classic PPM
no servidor LDAP ou cujo registro não contenha mais o atributo de pesquisa escolhido. Esta rotina não verifica se um usuário em um grupo LDAP do
Classic PPM
ou em uma pesquisa especificada pela CSA está ativo ou inativo no LDAP. Para desativar usuários do
Classic PPM
usando a rotina, remova-os do grupo LDAP do
Classic PPM
ou remova o atributo de pesquisa especificado na CSA. Essas rotinas de sincronização funcionam adequadamente se você configurou corretamente as seções Servidor LDAP e Mapeamento de atributo LDAP na CSA.
É necessário selecionar uma programação para cada rotina.
Melhor prática
: execute essas rotinas à noite.
Para sincronizar o banco de dados com o servidor de diretório, exclua todas as linhas da tabela de banco de dados CMN_DIRECTORY_SERVERS e execute a rotina em segundo plano novamente. Também é possível executar a rotina para um grupo específico de modo que somente os registros desses usuários sejam afetados.
Forçar a rotina LDAP - Sincronizar usuários novos e alterados para executar uma sincronização completa
Talvez seja necessário substituir o comportamento da rotina
LDAP - Sincronizar usuários novos e alterados
para que você possa forçar uma sincronização completa.
Siga estas etapas:
  1. Excluir a linha da tabela de banco de dados CMN_DIRECTORY_SERVERS.
  2. Execute (ou agende) a rotina novamente.
Solucionar problemas de LDAP
Veja a seguir alguns problemas comuns de LDAP e as maneiras de resolvê-los:
  • Para depurar o processo de autenticação LDAP, ative as mensagens de depuração registradas pelo componente de segurança. Interrompa todos os serviços em segundo plano, exceto aquele no qual você está ativando as mensagens de depuração. Reinicie o serviço em segundo plano para que as alterações entrem em vigor e verifique o arquivo de registro (bg-ca.log).
  • Quando você analisa as mensagens de erro dos registros do
    Classic PPM
    , podem aparecer códigos de erro específicos de LDAP.
    Consulte a documentação de LDAP de terceiros para obter descrições de códigos de erro específicos de LDAP.
  • Se você não conseguir efetuar logon no
    Classic PPM
    utilizando um nome de usuário e uma senha LDAP, considere estas informações:
    • Você está usando uma conta LDAP ativa que também existe como conta ativa no
      Classic PPM
      ?
    • Você ativou a configuração LDAP selecionando o campo Usar LDAP na página de propriedades do servidor de aplicativos na CSA?
    • Você digitou corretamente a ID de usuário no campo Usuário de pesquisa e a senha no campo Senha da página de propriedades do servidor de segurança na CSA?
    • Consulte os arquivos de registro para obter mensagens mais específicas.
    • O tempo de processamento das rotinas
      LDAP - Sincronizar usuários obsoletos
      e
      LDAP - Sincronizar usuários novos e alterados
      depende do número de usuários que são carregados do serviço de diretório no
      Classic PPM
      . Especificamente, números grandes podem tornar o tempo de processamento mais lento.
Solucionar problemas de rotinas de sincronização LDAP
Quando uma rotina de sincronização LDAP ou processo de autenticação não funcionar como esperado, execute qualquer uma das seguintes tarefas:
  • Verifique os arquivos de registro da sincronização LDAP no diretório /niku/Clarity/logs/ldapsync.
  • Verificar o arquivo *users*.xml. Esse arquivo contém uma lista de nomes de usuário extraídos do servidor LDAP. Se o arquivo estiver faltando, a comunicação entre o
    Classic PPM
    e o servidor LDAP não foi bem-sucedida.
  • Verifique o arquivo *sync*.xml. Esse arquivo contém os resultados de uma sessão de importação de usuários de gateway. Se o arquivo estiver faltando, a comunicação entre o
    Classic PPM
    e o gateway não foi bem-sucedida.
  • Ative as mensagens de depuração no componente de segurança executando as seguintes tarefas:
    1. Edite o arquivo
      bg-logger.xml
      e adicione a categoria
      com.niku.security
      .
    2. Defina a prioridade como
      depuração
      .
    3. Reinicie o serviço Segundo plano do
      Clarity
      (bg) para que as alterações entrem em vigor.
    4. Verifique o arquivo bg-ca.log.
    5. Se você tiver vários serviços de segundo plano no agrupamento, encerre todos, exceto um. Ter apenas um serviço em segundo plano garante que a rotina está sendo executada no servidor que você está depurando. Você também pode ativar a depuração em todos os serviços individualmente.
Verificar os registros de sincronização LDAP
Verifique os registros de transações de sincronização LDAP no seguinte diretório:
<Clarity Home Directory>/logs/ldapsync
Os arquivos de registro relacionados às rotinas Usuários novos e alterados são:
  • ldapusers_nm_*.xml: lista de usuários encontrados no servidor de diretório para sincronização com o
    Classic PPM
    .
  • ldapsync_nm_*.xml: lista de mensagens de êxito/erro/aviso relacionadas a essa rotina de sincronização.
Os arquivos de registro que estão relacionados à rotina
LDAP - sincronizar usuários obsoletos
são:
  • ldapusers_ia_*.xml: lista de usuários a serem desativados no
    Classic PPM
    .
  • ldapsync_ia_*.xml: lista de mensagens de êxito/erro/aviso relacionadas a essa rotina de sincronização.
Ativar mensagens de depuração
O componente de segurança registra as mensagens de depuração. Interrompa todos os serviços em Segundo plano do
Clarity
(bg) na sua implementação, exceto aquele no qual você está ativando as mensagens de depuração. Reinicie o serviço Segundo plano do
Clarity
(bg) para que as alterações entrem em vigor e verifique o arquivo de registro (bg-niku.log).
Siga estas etapas:
  1. Efetue logon na CSA.
  2. Clique em Página inicial, Servidores.
  3. Clique no ícone Registros do servidor para o qual você deseja ativar mensagens de depuração.
  4. Clique na subguia Editar configuração.
  5. Na seção Categorias, clique em Adicionar categoria.
  6. Digite o seguinte valor para o novo item de linha:
    • Nome
      Digite
      com.niku.security
      .
    • Nível de prioridade
      Selecione Depurar na lista suspensa.
  7. Salve as alterações.
    As mensagens de depuração são ativadas.
Configurar LDAP e SSL
Quando um servidor LDAP está em execução com SSL (Secure Socket Layer), você deve configurar o LDAP e o SSL. O administrador do
Classic PPM
deve instalar o certificado de segurança confiável para o servidor LDAP no computador que está executando os serviços em Segundo plano do
Clarity
(bg). Para instalar o certificado, use o keytool fornecido com o Java JDK 7.
Emita os seguintes comandos no prompt de comando:
keytool -import -v -trustcacerts -alias <alias> -file <certificate file name> -keystore cacerts
Exemplo:
$cd $JAVA_HOME/jre/lib/security $keytool -import -v -trustcacerts -alias NikuLdapServer -file TrustedRootCert.der -keystore cacerts
Configurar o SSO (Single Sign-On - Logon único) para o
Classic PPM
O logon único é um processo de autenticação que permite aos usuários acessar vários sistemas com um único nome de usuário e senha. Com o logon único, depois que o servidor usar as informações armazenadas no diretório LDAP para autenticar a identidade de um usuário, ele permite o acesso às informações necessárias de acordo com os privilégios de acesso do usuário.
Você pode configurar o SSO para integrar o
Classic PPM
com o aplicativo de portal interno em que o usuário é autenticado. O SSO elimina a necessidade de os usuários informarem seus nomes e senhas repetidamente quando alternam de um aplicativo para outro. O aplicativo de portal tem links (URLs) para outros aplicativos internos. Depois que o aplicativo de portal é chamado, os usuários não veem caixas de diálogo de autenticação e são levados diretamente ao aplicativo. O aplicativo de portal tem um plugin de SSO que direciona os usuários para que eles façam logon no portal e, em seguida, os leva até o aplicativo adequado. Dessa maneira, os usuários não podem marcar uma página como favorita e voltar a ela posteriormente sem primeiro fazer logon.
O SSO oferece os seguintes benefícios:
  • Administração de nome de usuário/senha A TI só precisa gerenciar um nome de usuário/senha de um usuário.
  • Suporte para autenticação. A equipe de TI só precisa cuidar de um lugar em que os usuários podem ter problemas de autenticação.
  • Usabilidade. Os usuários só precisam lembrar de um nome de usuário e senha, e só precisam efetuar logon uma vez.
  • Segurança. Um único nome de usuário e senha facilitam o uso de senhas complexas e sua alteração com mais frequência. A probabilidade de um usuário escolher uma senha familiar é reduzida quando há somente uma senha para lembrar.
Melhor prática
: se você estiver usando o CA SiteMinder ou outro software de SSO, configure-o para permitir caracteres de colchetes angulares (< e >) no URL. Por exemplo, se você estiver usando o SiteMinder, desative CssChecking. Caso contrário, um URL com colchetes angulares gerará um erro quando o
Classic PPM
tentar interpretá-lo. Colchetes angulares podem aparecer em um URL, provavelmente criados por um processo que usa condições como <, <=, > ou >=).
Siga estas etapas:
  1. Configure o servidor do SSO e o servidor proxy para apontar para o
    Classic PPM
    e para fazer com que ele transmita um token de autenticação que contenha um nome de usuário válido do
    Classic PPM
    .
    Configure o servidor de SSO para que o URL de entrada seja:
    http://<server>/niku/nu#action:npt.overview
  2. Efetue logon na CSA e clique em Página inicial, Servidores.
  3. Clique no nome do servidor que você deseja configurar.
  4. Clique na subguia Aplicativo.
  5. Para usar o LDAP, na seção Servidor de aplicativos, marque a caixa de seleção Usar LDAP.
    Se o LDAP estiver ativo, os clientes que não são de navegador usarão o mesmo nome de usuário e senha.
  6. Na seção Instância do aplicativo, marque a caixa de seleção Usar Sign-on único e clique em Salvar.
  7. Clique na guia Segurança.
  8. Na seção Criptografia, preencha os seguintes campos:
    • Keystore de SSL
      Define o caminho para o arquivo de keystore.
      Exemplo:
      <caminhodekeystore>/servidor.keystore).
    • Senha do SSL
      Define a senha do keystore. Depois de digitar a senha, confirme no campo Confirmar senha.
  9. Na seção Servidor LDAP, preencha os seguintes campos:
    • URL
      Define o URL do servidor LDAP.
    • Contexto raiz
      Define o contexto de nomenclatura do servidor LDAP, por exemplo: "ou=Pessoas, dc=niku, dc=com".
    • Usuário de pesquisa
      Define o nome de usuário com as credenciais apropriadas para ligação ao servidor LDAP.
    • Senha
      Define a senha do servidor LDAP. Depois de digitar a senha, confirme-a novamente no campo Confirmar senha.
    • Tamanho do lote
      Permite a operação síncrona. Defina o tamanho do lote usando os seguintes critérios:
      • 0. Permite todos os resultados recebidos do servidor à medida que são gerados.
      • Um número diferente de zero. As mensagens são bloqueadas até que
        n
        mensagens sejam recebidas do servidor. A enumeração prossegue enquanto mais mensagens são colocadas na fila.
      • O tamanho padrão do lote é 1. Uma enumeração de resultados de pesquisa de uma operação de pesquisa síncrona retorna as mensagens à medida que são recebidas do servidor.
    • Filtro da pesquisa
      Define a sequência de caracteres do filtro de pesquisa (conforme definido no RFC 2254).
    • Formato de data/hora
      Define o formato de data e hora usado no servidor LDAP.
    • Nome do grupo
      Define o grupo que está ativado para autenticação de grupo.
    • Identificador do grupo
      Especifica a ID do grupo que está ativado para a autenticação em grupo.
    • Permitir usuários que não sejam LDAP
      Indica se usuários não LDAP têm permissão para acessar o aplicativo usando um método alternativo de autenticação.
  10. Na seção Mapeamento de atributo LDAP, preencha os seguintes campos:
    Nome de usuário
    Especifica o atributo de nome de usuário.
    Nome
    Especifica o atributo de primeiro nome.
    Sobrenome
    Especifica o atributo de sobrenome.
    Nome completo
    Especifica o atributo de sobrenome.
    Endereço de email
    Especifica o atributo de endereço de email.
    Modificar registro de hora
    Especifica o atributo para a modificação do carimbo de hora.
  11. Na seção Logon único, preencha os seguintes campos:
    Nome do token
    Especifica o cookie HTTP que o
    Classic PPM
    aceita como token de autenticação válido para iniciar uma sessão de usuário.
    Tipo do token
    Especifica o tipo de token. Os valores são:
    Cookie.
    O token está contido em um cookie.
    Cabeçalho.
    O token está contido no cabeçalho da mensagem.
    Parâmetro.
    O token é fornecido em um parâmetro.
    URL de logoff
    Define o URL totalmente qualificado que será exibido quando o usuário efetuar logoff.
    URL de erro de autenticação
    Define o URL totalmente qualificado que será exibido quando não for possível autenticar o usuário.
  12. Salve as alterações.
  13. Reinicie o aplicativo e efetue logon no
    Classic PPM
    como administrador do aplicativo.
    A página de configurações do sistema é exibida.
Configurar o SSO (Single Sign-On - Logon único) para o
Clarity
Para ativar a implementação de SSO para o
Clarity
, configure o servidor do SSO, conforme descrito no procedimento a seguir. Os exemplos fornecidos para as definições de configuração são aplicáveis ao servidor de SSO do SiteMinder. As configurações podem ser diferentes para você, dependendo do servidor de SSO que estiver usando.
Antes de configurar o servidor do SSO para o
Clarity
, certifique-se de que o SSO esteja ativado para o
Classic PPM
. Consulte Configurar SSO para o
Classic PPM
para obter detalhes. Se o SSO não estiver configurado para o
Classic PPM
, o SSO para o
Clarity
não funcionará.
Siga estas etapas:
  1. Proteja os seguintes URLs para o
    Clarity
    :
    https://<server:port>/pm*
    https://<server:port>/ppm/rest/*
    Exemplo do SiteMinder
    :
    No domínio existente com o realm do
    Classic PPM
    , crie dois realms:
    Crie um realm que inclua uma regra para proteger as APIs REST
    • Nome:
      regra da API do REST do
      Clarity
    • Descrição
      : regra para proteger as APIs REST do
      Classic PPM
    • Atributos
      ,
      Recurso
      : ppm/rest/*
    • Caixa de listagem
      Ação
      ,
      Ação do agente web
      : selecione Get, Post, Put, Delete e Head
    Crie um realm que inclua uma regra para proteger o
    Clarity
    • Nome
      : nova regra de UI do
      Classic PPM
    • Descrição:
      regra para proteger o
      Clarity
    • Atributos
      ,
      Recurso
      : pm*
    • Caixa de listagem
      Ação
      ,
      Ação do agente web
      : selecione Get, Post, Put, Delete e Head
      Depois de definir as regras, vá para a guia Regras e adicione a
      resposta
      existente do SSO do
      Classic PPM
      a cada nova regra. A resposta define o nome do cookie de nome de usuário e o formato de valor que o SSO do
      Classic PPM
      espera.
    image2017-1-27 9:44:40.png
  2. Configure as seguintes propriedades para o Agente web:
    1. Adicione o seguinte URL à lista de URLs de logoff existente:
      https://<server:port>/ppm/rest/v1/auth/logout
    2. Adicione o seguinte URL à lista de URLs ignorados:
      https://<server:port>//pm/js/core/layout/logout.html
    3. Adicione as seguintes extensões de arquivo à lista de extensões ignoradas:
      • .woff
      • .svg
      • .ttf
      • .eot
    4. Remova as aspas simples (se o valor existir) da lista de caracteres inválidos de URL.
    5. Remova as aspas simples (se o valor existir) da lista de caracteres de consulta inválidos.
Exemplo do SiteMinder:
Modifique as seguintes propriedades do agente:
  • IgnoreExt
    : adicione as extensões de arquivo .woff, .svg, .ttf e .eot à lista de extensões ignoradas.
  • IgnoreUrl
    : adicione /pm/js/core/layout/logout.html à lista de URLs ignorados.
  • LogoffUri
    : adicione /ppm/rest/v1/auth/logout à lista URI de logoff.
  • BadUrlChars
    : remova o valor de aspas simples, se existir.
  • BadQueryChars
    : remova o valor de aspa simples, se existir.
Usar LDAP com SSO
Você pode usar o LDAP com SSO.
Melhor prática
: embora o SSO não exija o LDAP para ser ativado, use LDAP com SSO pelos seguintes motivos:
  • Os clientes que não são de navegador têm a maioria das vantagens do SSO.
  • Apenas com o SSO, as informações de usuário, como nomes e email, ainda precisam ser gerenciadas no
    Classic PPM
    . Com LDAP, os dados são mantidos no servidor de diretório.
Usar LDAP sem SSO
O SSO oferece algumas vantagens adicionais em relação ao LDAP. Os usuários devem digitar o nome de usuário e a senha para efetuar logon no
Classic PPM
, mas todas as outras vantagens ainda se aplicam ao LDAP. A configuração do sistema é muito mais fácil para o LDAP sozinho. Com o LDAP, não é necessário ter um servidor proxy ou SSO, e somente uma instância do
Classic PPM
é necessária.
Definir opções para vulnerabilidades XSS (Cross-Site Scripting - Scripts entre Sites)
Ataques de scripts entre sites (XSS) inserem scripts mal-intencionados em sites considerados confiáveis. Um invasor XSS usa um aplicativo web para enviar códigos mal-intencionados a um usuário final, geralmente, como um script de navegador. Esses ataques têm êxito quando um aplicativo web inclui os dados de entrada do usuário na saída que ele gera, sem validar ou codificar os dados de entrada.
O navegador do usuário final não pode determinar se o script é mal-intencionado. Como o script mal-intencionado parece ser de uma fonte confiável, o navegador executa o código. O código pode acessar cookies, tokens de sessão e outras informações confidenciais.
Para corrigir as vulnerabilidades XSS, todas as entradas fornecidas pelo usuário que são enviadas de volta ao navegador devem ser verificadas como seguras por meio da validação de entrada. A entrada do usuário deve ter escape adequado antes de sua inclusão na página de saída. Uma codificação de saída apropriada garante que os dados inseridos pelo usuário sejam sempre tratados como texto no navegador em vez de como conteúdo ativo que pode ser executado.
Como uma proteção contra as vulnerabilidades XSS, a partir da Release 14.1 e 14.2, o aplicativo trata da validação e das restrições (escape) da entrada do usuário. Para solicitar alterações nas configurações de restrição padrão ou obter assistência com problemas de segurança de XSS, entre em contato com ca.com/support.
5
5
XSS: validação de entrada do usuário
O
Classic PPM
faz a validação de toda a entrada de usuário que é enviada de volta ao navegador para garantir que esteja protegida contra XSS. O produto compara a entrada do usuário com um conjunto de padrões de sequência de caracteres que normalmente são usadas para XSS. Se qualquer parte da entrada do usuário corresponder a um dos padrões comuns, o
Classic PPM
restringirá a sequência de caracteres XSS (com escapes) na entrada do usuário.
O produto restringe a sequência de caracteres XSS inserindo caracteres de escape antes e depois dela. Esses caracteres são visíveis ao usuário final. Os caracteres de escape instruem o navegador a ignorar qualquer script ou marca HTML que esteja vinculada à entrada do usuário.
Por padrão, a detecção de XSS está ativada. Atributos de URL e links de sites estão liberados dessa verificação. Para obter mais informações sobre como alterar essas configurações, consulte Definir restrições de entrada do usuário XSS.
XSS: restrições de entrada do usuário
A entrada do usuário que contiver um dos padrões de XSS comuns deverá receber os caracteres de escape antes de ser incluída na página de saída. Essa codificação da saída garante que a entrada do usuário será tratada como texto e que o conteúdo ativo não possa ser executado. Opções administrativas permitem ativar ou desativar as restrições XSS (com caracteres de escape).
Para alterar a configuração de qualquer opção, execute as instruções SQL do banco de dados.
Siga estas etapas:
  1. Acesse a tabela CMN_OPTION_VALUES do banco de dados.
  2. Atualize a opção específica na entrada da tabela. Para obter mais informações sobre cada opção, consulte as descrições das opções.
  3. Descarregue o cache.
XSS: opção de restrição
Esta opção restringe a sequência de caracteres XSS na entrada do usuário caso ela corresponda ao padrão da opção CMN.XSS.PATTERNS. Essa opção de sistema se aplica a todo o
Classic PPM
, exceto aos atributos de URL e links do site. É possível definir restrições para atributos de URL e links de sites por meio de opções separadas.
  • RESTRICT.APP.XSS
    Valores = true (restrições ativas), false (restrições desativadas)
    Padrão = True
O conteúdo de HtmlPortlet não é restrito (com caracteres de escape). Os portlets HTML executam qualquer script do conteúdo HTML, que é o comportamento esperado.
Para alterar a opção RESTRICT.APP.XSS, atualize a tabela CMN_OPTION_VALUES do banco de dados usando a seguinte instrução SQL:
update cmn_option_values set value='false|true' where option_id = (select id from cmn_options where option_code=' RESTRICT.APP.XSS')
Observações de segurança
: a aplicação desse comando de atualização não impede que um portlet HTML seja codificado com o Javascript e que o Javascript seja executado na máquina cliente. Como administrador, seu foco estará nos servidores e em protegê-los das vulnerabilidades Meltdown e Spectre. Não se preocupe tanto com códigos Javascript potencialmente mal-intencionados nas máquinas cliente, já que você não tem tanto controle sobre eles.
Para iniciar um ataque mais grave, o invasor deve ser capaz de executar o código no processador da vítima. Para processar sites modernos, qualquer mecanismo web do JavaScript deve permitir que algum código JavaScript não confiável seja executado no processador do usuário. Qualquer Javascript que faça parte de um portlet HTML será executado na máquina cliente no navegador e não no servidor. O
Clarity
não executa o Javascript no servidor.
As restrições de XSS filtram os parâmetros dentro dos registros e os URLs que puderem conter algum código Javascript mal-intencionado, se forem enviados de volta ao navegador do cliente, serão executados na máquina cliente e causarão danos somente a ela. Essas restrições são processadas pelos filtros no aplicativo web que trabalha em uma solicitação enviada do cliente ao servidor na expectativa de que a resposta para o cliente será executada ou redirecionada de forma que o cliente não seja comprometido. Um portlet HTML que seja codificado por um usuário com o Javascript não passa por esses filtros. Trata-se de uma resposta a uma ação que foi solicitada ao
Clarity
, por exemplo, a exibição de um portlet. As respostas não passam pelo filtro. Então, um usuário que codifique um portlet HTML e coloque o Javascript nele só terá o Javascript executado em sua própria máquina cliente.
XSS: opção de valor do atributo de URL
Esta opção restringe o valor do atributo de URL (que você criou com o Studio) quando o valor corresponder a um padrão da opção CMN.XSS.PATTERNS.
  • RESTRICT.URL.ATTR.XSS
    Valores = true (restrições ativas), false (restrições desativadas)
    Padrão = False
Para alterar a opção RESTRICT.URL.ATTR.XSS, atualize a tabela CMN_OPTION_VALUES do banco de dados usando a seguinte instrução SQL:
update cmn_option_values set value='false|true' where option_id = (select id from cmn_options where option_code=' RESTRICT.URL.ATTR.XSS')
XSS: opção de links para sites
Essa opção restringirá o valor de entrada de Links para sites se o valor corresponder a um padrão da opção CMN.XSS.PATTERNS.
  • RESTRICT.SITE.LINKS.XSS
    Valores = true (restrições ativas), false (restrições desativadas)
    Padrão = False
Para alterar a opção RESTRICT.SITE.LINKS.XSS, atualize a tabela CMN_OPTION_VALUES do banco de dados usando a seguinte instrução SQL:
update cmn_option_values set value='false|true' where option_id = (select id from cmn_options where option_code=' RESTRICT.SITE.LINKS.XSS')
XSS: opção de padrões comuns XSS
Essa opção define os padrões de sequência de caracteres que normalmente são usados para XSS. Você pode adicionar valores a essa opção para incluir mais padrões de sequência de caracteres.
  • CMN.XSS.PATTERNS
    String patterns = </script> <script(.*?)> <script>(.*?)</script> alert(.*?) eval\\((.*?)\\) expression\\((.*?)\\) javascript: onerror(.*?)= onload(.*?)= src[\r\n]*=[\r\n]*\\\"(.*?)\\\" src[\r\n]*=[\r\n]*\\\'(.*?)\\\'
Para adicionar padrões, acesse a tabela CMN_OPTION_VALUES do banco de dados e inclua os novos padrões na opção CMN.XSS.PATTERNS.
Exemplo: adicione o novo padrão "onfocus" à opção CMN.XSS.PATTERNS
Oracle
CMN_OPTION_VALUES_INS_SP('CMN.XSS.PATTERNS','true','true','onfocus(.*?)=',1);
MSSQL
EXEC CMN_OPTION_VALUES_INS_SP 'CMN.XSS.PATTERNS','true','true','onfocus(.*?)=',1
Cabeçalhos de resposta de segurança: X-XSS-Protection e X-Content-Type-Options
Os navegadores têm dois cabeçalhos de resposta de segurança ativados por padrão para uma camada adicional de proteção.
  • X-XSS-Protection
    : o cabeçalho
    X-XSS-Protection
    força o filtro XSS a entrar no modo Ativar, mesmo se estiver desativado. Suportado pelos navegadores Internet Explorer, Chrome e Safari, esse cabeçalho de resposta interrompe o carregamento das páginas quando o navegador detecta ataques de XSS refletidos. Esse cabeçalho não é necessário em navegadores modernos quando os aplicativos implementam uma CSP (Content-Security-Policy - Política de Segurança de Conteúdo) que desativa o uso de JavaScript embutido não seguro. Embora a segurança do
    Clarity
    seja forte nesse sentido, o aplicativo ainda fornece essa proteção para usuários de navegadores antigos que ainda não oferecem suporte à CSP.
  • X-Content-Type-Options
    : o
    X-Content-Type-Options
    cabeçalho é um marcador usado pelo servidor para impedir alterações nos tipos MIME publicados nos cabeçalhos Content-Type.
Embora seja improvável, no caso de problemas, você poderá desativar os cabeçalhos individuais ou todos os cabeçalhos na resposta de rede com os seguintes comandos SQL:
  • Para desativar
    X-Content-Type-Options: nosniff
    delete from cmn_option_values where option_id in (select id from cmn_options where option_code like 'ENABLED_RESPONSE_HEADERS%') and value like 'X-Content-Type%'
  • Para desativar
    X-XSS-Protection: 1; mode=block
    delete from cmn_option_values where option_id in (select id from cmn_options where option_code like 'ENABLED_RESPONSE_HEADERS%') and value like 'X-XSS-Protection%'
  • Para desativar todos os cabeçalhos:
    call CMN_OPTION_VALUES_DEL_SP('ENABLED_RESPONSE_HEADERS');
URLs externos
A propriedade externalUrl é uma configuração de aplicativo opcional que oferece suporte para esquemas de autenticação federada ou externa em mensagens de notificação. Quando o externalUrl não é especificado, as mensagens de notificação do
Classic PPM
que contêm URLs usam a propriedade entryUrl padrão.
A propriedade entryUrl padrão aponta diretamente para o servidor do
Classic PPM
. A propriedade externalUrl faz com que a solicitação seja roteada primeiro para um servidor externo que fornece autenticação de logon para a sessão. O servidor externo redireciona a solicitação original para o
Classic PPM
utilizando o SSO (Single Sign-On - Sign-On Único). Esse método garante que o usuário não precise efetuar logon diretamente no
Classic PPM
. Quando o usuário clica em um link de notificação, a autenticação externa ocorre e a solicitação é encaminhada para o
Classic PPM
. Se o usuário já estiver conectado, a solicitação será encaminhada automaticamente sem interrupções.
O URL externo não substitui o URL de entrada padrão, eles funcionam juntos. Os dois criam um URL composto que inclui endereços externos e internos, codificadas para garantir que os URLs incorporados sejam transmitidos corretamente. A rota de autenticação pode incluir vários servidores, assim geralmente as URLs incluem parâmetros de consulta que informam a cada servidor para onde redirecionar depois de processar a solicitação.
A propriedade externalUrl oferece suporte para as seguintes macros:
  • ${entryurl}
    Insere a propriedade de configuração entryUrl atual.
  • replace(regex,replacement,text)
    Substitui todas as instâncias de 'regex' por 'replacement' em 'text'.
  • encode()
    Substitui o texto por texto codificado em UTF-8.
As macros podem ser combinadas e aninhadas.
Especifique os caracteres XML restritos, como E comercial, usando o nome de entidade equivalente (, &). Não fazer isso pode impedir que todos os serviços do
Classic PPM
sejam iniciados.
Por exemplo: criação de um URL externo
A rota de autenticação de um determinado ambiente determina o externalUrl. A rota de autenticação inclui especificamente os endereços de cada servidor da rota e os parâmetros exigidos por cada um dos servidores. Antes de definir esse valor, determine a rota reunindo informações.
Por exemplo, considere o seguinte ambiente:
  • Servidor 1
    Finalidade
    : servidor de autenticação externa
    Endereço
    : http://auth.somecompany.com
    Parâmetros necessários
    : REDIRECT
    Descrição
    : autentica (chamando o logon, se necessário) e redireciona para o endereço especificado no parâmetro REDIRECT
  • Servidor 2
    Finalidade
    : servidor de autenticação interna
    Endereço
    : http://sso.mycompany.com
    Parâmetros necessários
    : TARGET
    Descrição
    : chama o Single Sign On interno e encaminha a solicitação para o endereço especificado no parâmetro TARGET.
  • Servidor 3
    Finalidade
    : servidor de aplicativos do
    Classic PPM
    Endereço
    : http://ca_ppm.mycompany.com
    Parâmetros necessários
    : todos os parâmetros padrão do
    Classic PPM
    Descrição
    : endereço especificado em entryUrl.
Para resumir, as solicitações vão primeiro para http://auth.somecompany.com, que é o sistema de gestão de identidades externo. Em seguida, as solicitações vão para um servidor interno do Single Sign On, em http://sso.mycompany.com, e, finalmente, para o servidor em http://ca_ppm.mycompany.com.
Siga estas etapas:
  1. A construção do URL externo começa quando você adiciona a primeira parada, o servidor de autenticação externo:
    externalUrl=http://auth.somecompany.com
    Esse servidor requer um parâmetro, REDIRECT, que instrui o servidor para onde rotear a solicitação após o processamento. Nesse exemplo, a solicitação é para ir para o servidor de autenticação interna:
    externalUrl=http://auth.somecompany.com?REDIRECT=http://sso.mycompany.com
  2. O servidor SSO interno exige um parâmetro interno, TARGET, que contém o URL de entrada padrão do
    Classic PPM
    . A macro ${entryurl} se expande automaticamente para a configuração atual de entryUrl quando notificações são enviadas:
    externalUrl=http://auth.somecompany.com?REDIRECT=http://sso.mycompany.com?TARGET=${entryurl}
  3. O URL externo está quase concluído, mas ainda resta uma etapa.
    O parâmetro REDIRECT do Servidor 1 contém caracteres que devem ser codificados em UTF-8 para serem transmitidos com segurança em uma sequência de caracteres de consulta. A macro de codificação considera que:
    externalUrl=http://auth.somecompany.com?REDIRECT=encode(http://sso.mycompany.com?TARGET=${entryurl})
    Servidor 2 também tem um parâmetro que deve ser codificado:
    externalUrl=http://auth.somecompany.com?REDIRECT=encode(http://sso.mycompany.com?TARGET=encode(${entryurl}))
    As macros encode() são aninhadas. O aninhamento faz com que a macro interna seja duplamente codificada, que significa que o texto codificado em UTF-8 é codificado uma segunda vez. Essa codificação dupla é necessária porque Servidor 1 decodifica todo o parâmetro REDIRECT na primeira parada e Servidor 2 espera um parâmetro codificado em UTF-8. A macro de codificação pode ser aninhada quantas vezes forem necessárias para garantir que o último parâmetro tenha a codificação correta.
O ciclo de vida da solicitação
Quando é gerado um novo email de notificação do
Classic PPM
, as propriedades externalUrl e entryUrl são usadas para gerar um URL clicável adequado para o evento. O URL padrão (sem usar externalUrl) pode se parecer com:
http://ca_ppm.mycompany.com/niku/nu#action:timeadmin.currentTimesheet
Com externalUrl ativado como nesse exemplo, o URL gerado seria parecido com este:
externalUrl=http://auth.somecompany.com?REDIRECT=http%3A%2F%2Fsso.mycompany.com%3FTARGET%3Dhttp%253A%252F%252Fca_ppm.mycompany.com%252Fniku%252Fnu%2523action%253Atimeadmin.currentTimesheet
O exemplo anterior se trata de um URL que aponta para o Servidor 1 e um único parâmetro com os endereços e propriedades do Servidor 2 e do Servidor 3 codificados em UTF-8 (o URL de entrada duas vezes). Quando um usuário clica nessa URL, a solicitação é enviada ao Servidor 1 (http://auth.somecompany.com). O servidor 1 decodifica o parâmetro (todo o texto após REDIRECT=) em:
http://sso.mycompany.com?TARGET=http%3A%2F%2Fca_ppm.mycompany.com%2Fniku%2Fnu%23action%3Atimeadmin.currentTimesheet
O Servidor 1 usa o URL para redirecionar para Servidor 2. A sequência de caracteres do parâmetro para o Servidor 2 ainda está codificada, apesar de toda a sequência de caracteres de consulta ter sido decodificada pelo Servidor 1. O exemplo mostra o efeito da codificação dupla. O Servidor 2, por sua vez, decodifica o parâmetro TARGET para produzir:
http://ca_ppm.mycompany.com/niku/nu#action:timeadmin.currentTimesheet
O URL anterior é o final. O URL é decodificado e está pronto para ser processado pelo
Classic PPM
. No decorrer do processo, os Servidores 1 e 2 executaram suas tarefas de autenticação. Quando a solicitação finalmente chegar ao
Classic PPM
, ela conterá o token de autenticação do Single Sign On adequado para identificar o usuário. Além de gerar o URL correto quando a notificação é produzida, o
Classic PPM
não tem envolvimento no processo de autenticação.
Solucionando problemas de URLs externas
A chave para resolver problemas com um URL externo é entender quais valores são esperados por todos os servidores da cadeia. Assim que você conhecê-los, poderá se certificar de que os URLs e parâmetros sejam adequadamente codificados em cada ponto. É possível verificar manualmente um determinado URL de notificação executando as etapas a seguir.
Siga estas etapas:
  1. Obtenha um utilitário de decodificação UTF-8. É possível baixar um utilitário simples.
  2. Gere um email de notificação usando a configuração atual de URL externa.
  3. Examine o URL e verifique se a primeira parte dele aponta para Servidor 1. A primeira parte do URL inclui tudo até o primeiro caractere de ponto de interrogação.
  4. Descarte tudo, até e inclusive o primeiro ponto de interrogação, deixando a sequência de parâmetro passada para Servidor 1.
  5. Decodifique o restante da sequência uma vez usando o utilitário de decodificação UTF-8.
    A sequência de caracteres decodificada representa os parâmetros passados para o Servidor 1. Verifique se os parâmetros estão corretos.
  6. Descarte o nome do parâmetro (no nosso exemplo, REDIRECT) e verifique se a primeira parte do URL aponta para o Servidor 2. Novamente, tudo até o ponto de interrogação é incluído na primeira parte do URL.
  7. Novamente, descarte tudo até o ponto de interrogação e decodifique o restante da sequência de caracteres de uma vez.
  8. Verifique os seguintes pontos:
    • A primeira parte do URL aponta para o servidor do
      Classic PPM
      .
    • O restante da sequência de caracteres de consulta contém os parâmetros padrão do
      Classic PPM
      .
    • Os parâmetros não estão codificados.
Como o
Classic PPM
rastreia as sessões de usuário?
Um cookie de sessão leva um token que é usado para acessar os dados da sessão que permaneceram nos seguintes locais:
  • Cache (para ambientes com um único aplicativo)
  • Banco de dados (para ambientes agrupados)
Isso gera limitações em nosso ambiente?
O navegador da web do usuário final deve aceitar cookies do
Classic PPM
. Os cookies se baseiam na sessão, portanto, não são gravados em disco.
Os balanceadores de carga ou agrupamentos são afetados por essa técnica?
O balanceamento de carga e o funcionamento em agrupamento funcionam bem com essa técnica. Muitas empresas fazem o balanceamento de carga do
Classic PPM
e agrupam-no.
Uma sessão pode ser interceptada inadvertidamente ou deliberadamente?
Para roubar a sessão de um usuário intencionalmente, seria necessário rastrear o tráfego HTTP para selecionar os cabeçalhos que contêm o cookie de autenticação. Esse token, no entanto, só é válido enquanto o usuário real está conectado. Quando o usuário faz logoff, as informações da sessão contidas no banco de dados/cache que o
Classic PPM
compara com o valor do cookie são excluídas.
Como manter as IDs de sessão fora dos registros?
Como medida de segurança, você pode configurar o
Classic PPM
para impedir que os valores de ID de sessão apareçam em seus arquivos de registro. Para impedir que esses valores apareçam, edite o arquivo logger.xml. Substitua o padrão de registro (%u:%s:%a) pelo padrão (%U:%a).
Os exemplos a seguir mostram os resultados do uso de ambos os padrões de registro no arquivo logger.xml.
Exemplo: (%u:%s:%a)
Essa linha de código mostra como o padrão de exibição do valor de ID de sessão aparece no arquivo logger.xml.
<param name="ConversionPattern" value="%-5p %d{ISO8601} [%t] %c{2} (%u:%s:%a) %m\r\n"/>
Esse padrão produz os registros em um arquivo de registro com o valor de ID de sessão. O registro a seguir do arquivo app-ca.log mostra o valor de ID de sessão (em negrito):
DEBUG 2014-08-18 19:52:02,949 [http-bio-80-exec-3] odf.view (ca_ppm:admin:
5077018__8DF3B2A0-F398-4A4B-BC35-E9A012065CE0
:npt.overview) Adding view FILTER_VIEW_LOADER::USER:NIKU.ROOT to transient cache
Exemplo: (%U:%a)
Essa linha de código mostra como o padrão para evitar o valor de ID de sessão aparece no arquivo logger.xml.
<param name="ConversionPattern" value="%-5p %d{ISO8601} [%t] %c{2} (%U:%a) %m\r\n"/>
Esse padrão produz um registro em um arquivo de registro sem o valor de ID de sessão. O exemplo a seguir é um registro do arquivo app-ca-service.log que não mostra nenhum valor de ID de sessão.
DEBUG 2014-08-18 19:52:02,494 [http-bio-80-exec-3] in.service (admin:npt.overview)
O
Classic PPM
oferecerá suporte aos padrões de registro adicionais da seguinte tabela se o layout estiver definido como NikuLayout no arquivo logger.xml do appender.
Opção de padrão
Propósito
u
Cria a ID de usuário com a ID de inquilino no registro.
Exemplo: (%u) cria a saída (clarity:admin) no registro.
U
Cria a ID de usuário no registro.
Exemplo: (%U) cria a saída (admin) no registro.
s
Cria a ID da sessão no registro.
Exemplo: (%s) cria a saída (5077018__8DF3B2A0-F398-4A4B-BC35-E9A012065CE0) no registro.
a
Cria a ID da ação no registro.
Exemplo: (%a) cria a saída (npt.overview) no registro.
Para obter mais informações sobre os padrões log4j da versão 1.2 que têm suporte, consulte a Classe PatternLayout na documentação da API em https://logging.apache.org.