Integração de repositórios de credenciais

Integração com CyberArk® CCP

O Central Credential Provider (CCP) é o método do AAM sem agente usado para integração com o CyberArk, permitindo que a UiPath recupere com segurança credenciais de um cofre sem implantar um agente no servidor. Um certificado de cliente é necessário para garantir a recuperação segura da credencial.

Antes de poder começar a usar os armazenamentos de credenciais do CyberArk® CCP no Orchestrator, primeiramente você deve configurar o aplicativo correspondente e as configurações seguras na interface do PVWA (Password Vault Web Access) do CyberArk®.

Pré-requisitos

• Uma rede que permite a interconectividade entre o serviço do Orchestrator e o servidor do CyberArk.
• O Central Credential Provider do CyberArk® deve ser instalado em uma máquina que permite conexões HTTP.
• CyberArk® Enterprise Password Vault

Para obter mais informações sobre a instalação e configuração de aplicativos do CyberArk®, visite sua página oficial.

Configuração da integração

No PVWA do CyberArk®, você deve executar as seguintes etapas:

1. Crie um aplicativo para sua instância do Orchestrator e adicione certificados de clientes;
2. Crie um seguro e adicione membros para garantir as permissões adequadas.

Criação de um aplicativo do Orchestrator

1. No PVWA da CyberArk®, faça logon com um usuário com permissões para gerenciar aplicativos (requer Gerenciar autorização de usuários).
2. Na guia Aplicativos, clique em Adicionar aplicativo. A janela Adicionar aplicativo será exibida.
   
   

   

   
   
3. Na janela Adicionar aplicativo, especifique as seguintes informações:
   • Campo Name - Um nome personalizado para o aplicativo, como Orchestrator.
   • Descrição – Uma descrição curta para ajudar a especificar o propósito do novo aplicativo.

   • Local - o caminho do aplicativo dentro da hierarquia do Vault. Se um Local não for especificado, o aplicativo será adicionado no mesmo local do usuário que está criando esse aplicativo.

     
     

     

     
     
4. Clique em Adicionar. O aplicativo é adicionado, e seus detalhes são exibidos na página Detalhes do aplicativo.
5. Marque a caixa de seleção Permitir restrições de autenticação estendida.

   Método de autenticação compatível:

   • Client Certificates - the client certificate used for the CyberArk authentication should be at least 2048 bits
6. Configure o método de autenticação. Por exemplo, na guia Autenticação, clique em Adicionar > Número de série do certificado e adicione o identificador exclusivo do certificado do cliente, usado para autenticar o aplicativo solicitante em relação ao CCP.
   
   

   

   
   

Criação de um cofre do Orchestrator

Os seguros são necessários para ajudar você a gerenciar melhor suas contas. Além disso, você pode adicionar membros seguros para garantir a autorização adequada. O CyberArk® recomenda adicionar um provedor de credenciais (um usuário com direitos totais sobre as credenciais pode adicioná-las e gerenciá-las) e o aplicativo criado anteriormente como membros seguros. Este último permite que o Orchestrator encontre e recupere as senhas armazenadas no seguro.

1. Na guia Políticas, a seção Controle de acesso (seguros), clique em Adicionar seguro. A página Adicionar seguro será exibida.
   
   

   

   
   
2. Preencha os campos Nome do cofre e Descrição.
3. Clique em Salvar. A janela Detalhes do cofre é exibida.
   
   

   

   
   
4. Na seção Membros, clique em Adicionar membros. A janela Adicionar membros do cofre é exibida.
   
   

   

   
   
5. Procure o aplicativo criado anteriormente (etapas 2-6) e selecione as seguintes permissões para ele:
   • Exibir membros do cofre
   • Recuperar contas
   • Listar contas

   • Acesso seguro sem confirmação - Apenas se você estiver usando um ambiente de controle duplo e um PIM-PSM v7.2 ou inferior.

     Se você instalar vários provedores de credenciais para essa integração, é recomendável criar um grupo para eles e adicionar o grupo ao Safe uma vez com a autorização acima.

     
     

     

     
     
6. Clique em Adicionar. Sua integração está concluída e você pode começar a provisionar armazenamentos de credenciais do CyberArk® no Orchestrator. Para obter detalhes sobre como armazenar credenciais de Robots, consulte aqui.

Integração do Azure Key Vault

O Azure Key Vault é um plug-in que pode ser usado como um repositório de credenciais com o Orchestrator.

Há dois plug-ins incluídos:

• Azure Key Vault — um plug-in de leitura/gravação (os segredos são criados por meio do Orchestrator)
• Azure Key Vault (somente leitura) — um plug-in somente leitura (é necessário provisionar os segredos no Vault diretamente)

Pré-requisitos

• Os armazenamentos de credenciais do Azure Key Vault usam autenticação RBAC. O Azure Key Vault requer a função Key Vault Secrets Officer, e o Azure Key Vault (somente leitura) requer a função de usuário Key Vault Secrets.

Configuração

No painel Registros de aplicativos do Portal do Azure, siga estas etapas:

1. Crie um novo registro do aplicativo.
2. Copie o ID do aplicativo (cliente) para uso posterior.
3. Acesse Gerenciar > Certificados e segredos > Novo segredo do cliente, e adicione um novo segredo do cliente. Anote a data de expiração escolhida e crie um novo segredo antes disso.
4. Copie o Valor do segredo para uso posterior.

No Azure Key Vault, siga estas etapas:

1. Acesse a página Visão geral do Key Vault, e copie o URI do Vault e o ID do diretório para uso posterior.
2. Selecione Configurações > Políticas de acesso no menu à esquerda.
3. Clique em Adicionar política de acesso.
   As permissões de política de acesso necessárias são Secret Get e Secret Set.
4. No menu suspenso Configurar a partir do modelo (opcional), selecione Gerenciamento de segredo.
5. Clique em Nenhum selecionado na seção Aplicativo autorizado para habilitar o campo Selecionar principal.
6. Insira o nome do registro do aplicativo, confirm se o ID do aplicativo está correto e selecione esse principal.
7. Clique em Adicionar.
8. Clique em Salvar.

Agora você está pronto para usar o URI do Vault, ID do diretório, ID do aplicativo (cliente) e o Valor do segredo para configurar um novo repositório de credenciais.

Usando Azure Key Vault (somente leitura)

Ao usar o plug-in do Azure Key Vault (somente leitura), o administrador do Vault é responsável por provisionar corretamente os segredos que o Orchestrator usará. O formato no qual esses segredos devem ser provisionados difere entre os tipos de segredo (ativo versus senha de robô) e entre mecanismos de segredo.

Para obter instruções sobre como provisionar os segredos, consulte o seguinte:

• Armazenar credenciais de robô não assistido no Azure Key Vault (somente leitura)
• Armazenando ativos no Azure Key Vault (somente leitura)

Integração com o HashiCorp Vault

O HashiCorp Vault é um plug-in que você pode usar como um repositório de credenciais com o Orchestrator.

Há dois plug-ins incluídos:

• HashiCorp Vault — um plug-in de leitura-gravação (os segredos são criados através do Orchestrator)
• HashiCorp Vault (somente leitura) — um plug-in somente leitura (você deve provisionar os segredos no cofre diretamente)

Pré-requisitos

• Uma rede que permite a interconectividade entre o serviço do Orchestrator e o servidor do HashiCorp Vault:

  • A porta API usada pelo HashiCorp cofre para solicitações de API deve ser aberta por qualquer firewall e acessível pela Internet. A porta é 8200 em uma instalação típica.
  • Se o firewall do cliente não permitir De conectividade a partir de qualquer IP da Internet, os endereços IP do Orchestrator devem ser inseridos na lista de permissão. Você pode encontrar uma lista atualizada de IPs na página Endereços IP de saída do Orchestrator.

• Você deve configurar um dos métodos de autenticação compatíveis:

  • AppRole (recomendado)
  • UsernamePassword
  • LDAP
  • Token

    Consulte como configurar a autenticação.

• Você deve configurar um dos mecanismos de segredos compatíveis:

  • KeyValueV1 - Disponível para HashiCorp Vault e HashiCorp Vault (somente leitura)
  • KeyValueV2 - Disponível para HashiCorp Vault e HashiCorp Vault (somente leitura)
  • ActiveDirectory - Disponível apenas para HashiCorp Vault (somente leitura)

  • OpenLDAP - Disponível apenas para HashiCorp Vault (somente leitura)

• O método de autenticação escolhido deve ter uma política que permita os seguintes recursos no caminho em que você planeja armazenar seus segredos:

  • Para o plug-in HashiCorp Vault (somente leitura): read
  • Para o plug-in HashiCorp Vault: create, read, update, delete e, opcionalmente, delete no caminho de metadados, caso esteja usando o mecanismo de segredos KeyValueV2.

Configuração da integração

A seguir, está um exemplo de como configurar uma versão de desenvolvimento do HashiCorp Vault, em execução num contêiner docker, a ser usado como um repositório de credenciais com o Orchestrator. Os exemplos devem ser adaptados para o seu próprio ambiente. Consulte a documentação oficial do HashiCorp Vault para obter mais detalhes.

Configuração da autenticação

Para começar a configurar e ler segredos, primeiro é necessário configurar o método de autenticação seguindo as seguintes etapas:

1. Abra um shell dentro do contêiner:

   docker exec -it dev-vault sh

2. Faça logon como raiz. Certifique-se de ter o token raiz exibido nos logs para definir uma variável de ambiente com ele, executando o seguinte comando:

   export VAULT_TOKEN=s.hA7RJ5lBqSnKUPd8nrQBaK1f

3. Consulte o status do cofre executando o seguinte comando:

   vault status

4. Adicione um segredo fictício para o Orchestrator no repositório KV:

   vault kv put secret/applications/orchestrator/testSecret supersecretpassword=123456

5. Dê ao Orchestrator acesso ao caminho secret/applications/orchestrator recém-criado. Para isso, primeiro, é necessário criar uma política de leitura e gravação para esse caminho e todos os seus subcaminhos, executando o seguinte comando:

   cat <<EOF | vault policy write orchestrator-policy -
   path "secret/data/applications/orchestrator/*" {
     capabilities = ["create", "read", "update", "delete"]
   }
   path "secret/metadata/applications/orchestrator/*" {
     capabilities = ["delete"]
   }
   EOF

   Observação:

   Ao usar um mecanismo de segredos KeyValueV2, os segredos são gravados e extraídos no caminho <mount>/data/<secret-path>, em vez de <mount>/<secret-path> como no KeyValueV1. Ele não altera nenhum dos comandos de CLI (ou seja, você não especifica os dados no seu caminho).

   No entanto, ele altera as políticas, pois os recursos são aplicados no caminho real. No exemplo anterior, o caminho é secret/data/applications/orchestrator/*, pois estamos trabalhando com um mecanismo de segredos KeyValueV2. Se um KeyValueV1 estivesse sendo usado, o caminho seria secret/applications/orchestrator/*.

   A capacidade de excluir no caminho de metadados é necessária apenas se você quiser garantir que o Orchestrator não deixe para trás chaves de teste ao verificar a conectividade. Se essa capacidade não for concedida, uma chave será criada e deixada para trás ao criar o repositório de credenciais no Orchestrator.

6. Habilite a autenticação usando o método de autenticação userpass e, em seguida, crie um usuário para o Orchestrator e atribua a política criada anteriormente:

   vault auth enable userpass
   vault write auth/userpass/users/orchestrator password=123456 policies=orchestrator-policy

   Observação: o Orchestrator é compatível com vários modos de autenticação. Consulte a documentação do HashiCorp Vault para saber como configurá-los.
7. Confira se você configurou tudo corretamente fazendo logon e tentando ler o segredo criado anteriormente:

   vault login -method=userpass username=orchestrator password=123456

   Saída deste comando:

   WARNING! The VAULT_TOKEN environment variable is set! This takes precedence
   over the value set by this command. To use the value set by this command,
   unset the VAULT_TOKEN environment variable or set it to the token displayed
   below.
   Success! You are now authenticated. The token information displayed below
   is already stored in the token helper. You do NOT need to run "vault login"
   again. Future Vault requests will automatically use this token.
   Key                    Value
   ---                    -----
   token                  s.nwombWQH3gGPDhJumRzxKqgI
   token_accessor         aGJL6Pzc6fRRuP8d8tTjS2Kj
   token_duration         768h
   token_renewable        true
   token_policies         ["default" "orchestrator-policy"]
   identity_policies      []
   policies               ["default" "orchestrator-policy"]
   token_meta_username    orchestratorWARNING! The VAULT_TOKEN environment variable is set! This takes precedence
   over the value set by this command. To use the value set by this command,
   unset the VAULT_TOKEN environment variable or set it to the token displayed
   below.
   Success! You are now authenticated. The token information displayed below
   is already stored in the token helper. You do NOT need to run "vault login"
   again. Future Vault requests will automatically use this token.
   Key                    Value
   ---                    -----
   token                  s.nwombWQH3gGPDhJumRzxKqgI
   token_accessor         aGJL6Pzc6fRRuP8d8tTjS2Kj
   token_duration         768h
   token_renewable        true
   token_policies         ["default" "orchestrator-policy"]
   identity_policies      []
   policies               ["default" "orchestrator-policy"]
   token_meta_username    orchestrator

8. Pegue esse token e use-o em vez do token raiz e, em seguida, tente ler o segredo do teste:

   export VAULT_TOKEN=s.nwombWQH3gGPDhJumRzxKqgI
   vault kv get secret/applications/orchestrator/testSecret

Saída deste comando:

====== Metadata ======
Key              Value
---              -----
created_time     2020-10-12T06:24:41.7827631Z
deletion_time    n/a
destroyed        false
version          1
=========== Data ===========
Key                    Value
---                    -----
supersecretpassword    123456====== Metadata ======
Key              Value
---              -----
created_time     2020-10-12T06:24:41.7827631Z
deletion_time    n/a
destroyed        false
version          1
=========== Data ===========
Key                    Value
---                    -----
supersecretpassword    123456

Observação:

Você também pode habilitar o appRole do Orchestrator executando o seguinte comando:

/ # vault auth enable approle 
/ # vault write auth/approle/role/orchestrator policies=orchestrator-policy 
/ # vault read auth/approle/role/orchestrator/role-id 
/ # vault write -f auth/approle/role/orchestrator/secret-id

Agora, você terá um ID da função e ID do segredo para configurar no Orchestrator.

Configuração do mecanismo de segredos do Active Directory

Para configurar o mecanismo de segredos do Active Directory, siga as seguintes etapas:

1. Habilite o mecanismo de segredos Active Directory executando o seguinte comando:

   vault secrets enable ad

2. Configure as credenciais usadas pelo HashiCorp Vault para se comunicar com o Active Directory para gerar senhas:

   vault write ad/config \
       binddn=$USERNAME \
       bindpass=$PASSWORD \
       url=ldaps://138.91.247.105 \
       userdn='dc=example,dc=com'

3. Configure uma função que mapeie um nome no HashiCorp Vault para uma conta no Active Directory. Quando os aplicativos solicitarem senhas, as configurações de rotação de senha serão gerenciadas por essa função.

   vault write ad/roles/orchestrator service_account_name="[e-mail]"

4. Conceda a orchestrator acesso às suas credenciais em ad/creds/orchestrator usando um método de autenticação, como o AppRole.

   cat <<EOF | vault policy write orchestrator-policy -
   path "ad/creds/orchestrator" {
     capabilities = ["read"]
   }
   EOF

Uso do HashiCorp Vault (somente leitura)

Ao usar o plug-in HashiCorp Vault (somente leitura), o administrador do cofre é responsável por provisionar corretamente os segredos que o Orchestrator usará. O formato no qual esses segredos devem ser provisionados difere entre os tipos de segredo (ativo versus senha de robô) e entre mecanismos de segredo.

Para obter instruções sobre como provisionar os segredos, consulte o seguinte:

Armazenamento de credenciais de robôs não assistidos no HashiCorp Vault (somente leitura)

Armazenamento de ativos no HashiCorp Vault (somente leitura)

Integração com o BeyondTrust

A integração do BeyondTrust é somente leitura e vem na forma de dois plug-ins para escolher: BeyondTrust Password Safe - Managed Accounts e BeyondTrust Password Safe - Team Passwords.

Embora o BeyondTrust Password Safe - Managed Accounts atenda às necessidades de organizações com contas locais e do Active Directory, o BeyondTrust Password Safe - Team Passwords é adequado para os cenários em que as credenciais de grupos pequenos devam ser armazenadas em um ambiente isolado.

A configuração dos dois plug-ins é praticamente idêntica, mas há algumas pequenas diferenças entre elas. Esta página aborda ambos os plug-ins.

Pré-requisitos

• Uma instância do BeyondTrust Server Cloud ou uma instalação local similar
• Credenciais do Beyond Insight

Configuração da integração

1. Faça login na instância do BeyondTrust Server Cloud ou uma instalação local similar usando suas credenciais do Beyond Insights.
2. Crie um Registro de API para o grupo ou contas de serviço da UiPath.
   
   

   

   
   
3. Crie uma Regra de autenticação para permitir conexões de API de entrada da UiPath.
   
   

   

   
   
4. Crie um novo grupo UiPath para as suas contas de serviço da UiPath e adicione as seguintes funcionalidades:
   • Conta protegida por senha

   • Função protegida por senha

     
     

     

     
     
5. Também é necessário atribuir Regras inteligentes:
   • Managed Accounts/Read-Only/Requester são suficientes para solicitações de usuário regulares

   • Para o acesso ISA, a função Assets/ISA é necessária.

     
     

     

     
     
6. Adicione o Registro de API ao grupo.
   
   

   

   
   
7. Crie um Usuário e o atribua ao grupo da UiPath.
   
   

   

   
   
8. As etapas a seguir variam conforme você esteja usando o BeyondTrust Password Safe - Managed Accounts ou BeyondTrust Password Safe - Team Passwords.

BeyondTrust Password Safe - Managed Accounts

Se estiver usando o BeyondTrust Password Safe - Managed Accounts, continue com as seguintes etapas:

1. Adicione suas contas gerenciadas em Sistemas gerenciados.
   

   

   
   

2. Certifique-se de usar Habilitado para API para suas contas gerenciadas.

BeyondTrust Password Safe - Team Passwords

Se estiver usando o BeyondTrust Password Safe - Team Passwords, continue com as seguintes etapas:

1. Acesse a página Team Passwords.
   

   

   
   

2. Opcionalmente, crie uma nova Pasta.

3. Selecione uma Pasta.
4. Use a opção Criar nova credencial.

Integração do Thycotic Secret Server

Observação: a marca Thycotic foi renomeada para Delinea como resultado de uma fusão. Tenha isso em mente ao configurar integrações de armazenamento de credenciais.

Pré-requisitos

• Uma instância em nuvem do Thycotic Secret Server ou instalação local.

Configuração da integração

Importante:

Certifique-se de ler a documentação do Delinea para obter informações atualizadas.

1. Faça login em sua conta do Secret Server.
2. Acesse Admin > Gerenciamento de usuário e clique em Criar usuário. Marque a caixa de seleção Conta do aplicativo para gerar uma conta do aplicativo.
3. Navegue até Administrador > Ver todos > Ferramentas e integrações > Gerenciamento do cliente SDK e configure uma nova regra de integração em Integração do cliente. Anote o nome da regra de integração e a chave.
4. Edite a regra de integração e atribua a Conta de aplicativo criada na Etapa 2.
5. Certifique-se de que a Conta de aplicativo vinculada à regra de integração tenha permissões para os segredos acessados pelo Orchestrator. Você pode atribuir a Conta de aplicativo a um grupo e conceder a esse grupo acesso às pastas necessárias, ou conceder acesso explícito aos segredos.

Integração do AWS Secrets Manager

Sobre o AWS Secrets Manager

O AWS Secrets Manager é uma ferramenta que pode ser usada como um armazenamento de credenciais no Orchestrator.

Ele possui dois plug-ins:

• AWS Secrets Manager
• AWS Secrets Manager (somente leitura)

O plug-in que você pode usar, ou seja, somente leitura ou escrita-leitura, é determinado pelas permissões de política do AWS Identity and Access Management (IAM).

Se você optar por usar o plug-in somente leitura, você deverá vincular um ativo para um conjunto de credenciais que já está disponível no AWS Secrets Manager.

Pré-requisitos

Para usar esse serviço:

• Você precisa ter uma assinatura do AWS.
• Você precisa criar uma política do IAM específica para o Secrets Manager, que você atribuirá à função ou usuário do IAM da conta.

Configuração

Para integrar o AWS Secrets Manager ao Orchestrator, você precisa da chave de acesso e da chave secreta que são geradas após você criar uma Conta do AWS IAM.

• O ID da chave de acesso pode ser encontrado na guia Credenciais de segurança de sua conta do AWS IAM.

• O ID da chave secreta só é fornecido após você criar a conta. Portanto, é importante copiá-lo para uso futuro.

  Se você extraviar ou se esquecer do seu ID da chave secreta, você poderá criar outra chave de acesso e, depois, substituir as informações necessárias no Orchestrator.

Além disso, você precisa verificar a região definida em sua conta da AWS, pois é ela que você inserirá no campo Região ao configurar o novo armazenamento de credenciais.

Como usar o AWS Secrets Manager (somente leitura)

Ao usar o plug-in AWS Secrets Manager (somente leitura), o administrador é responsável por provisionar corretamente os segredos que o Orchestrator usará. O formato no qual esses segredos devem ser provisionados difere entre os tipos de segredo (ativo versus senha de robô) e entre mecanismos de segredo.

Para obter instruções sobre como provisionar os segredos, consulte o seguinte:

• Armazenando credenciais de Unattended Robots no AWS Secrets Manager (somente leitura)
• Armazenando ativos no AWS Secrets Manager (somente leitura)