Pular para o conteúdo principal
Version: 3.20

Proxy

Introdução

Este livro explicará como usar os proxies senhasegura .

Símbolos usados neste cookbook

Este livro usa os seguintes símbolos para destacar informações que devem ser levadas em consideração para o melhor uso de senhasegura :

info

Info - Informações úteis que podem tornar o uso da solução mais dinâmico.

caution

Caution - Ações e itens que não podem ser ignorados.

  • commands : Dados que devem ser inseridos da mesma forma como descrito neste livro.

  • URLs : Caminhos para acessar páginas da web.
  • <KEYS> : Caminhos de teclado que serão usados para realizar ações.

Arquitetura Proxy

senhasegura fornece tecnologias proxy para muitos protocolos e aplicativos alvo. E também entrega ao usuário três maneiras de se conectar.Cada gateway tem suas características particulares, capacidades de criptografia, segregações e persistência de sessão.

Origem e destino utilizados pelo senhasegura Proxy

Cada sessão de usuário recebe um PID interno de execução separado, sobre camadas com hardening de segurança e abstrações usando as melhores práticas CIS e NIST. Não há possibilidade de compartilhar dados entre as sessões em execução, mesmo quando proveniente do mesmo usuário senhasegura .

Cada sessão senhasegura Proxy é executada em camadas de seguraça e abstrações harnenizadas.

Funcionalidades Proxy

Proxy

As sessões de proxy têm várias funcionalidades que ocorrem em diferentes momentos, e que são realizadas por diferentes tipos de usuários. Vamos então introduzir os tipos de usuários e as etapas de uma sessão, antes de falarmos na prática das funcionalidades.

Os tipos de usuários em uma sessão:

  • Operador: É o usuário que solicita acesso e executa tarefas no dispositivo alvo;

  • Aprovador: O usuário que participa do processo de workflow. Ele tem o poder de decisão se a sessão pode ou não ser executada;

  • Auditor: É o usuário que observa as sessões que já ocorreram procurando por comportamentos, comandos ou vídeos;

  • Administrador: É o usuário que configura todas as opções e funcionalidades de uma sessão e decide as ações de intervenção em sessões em andamento;

Fases da sessão

As sessões são influenciadas em três etapas principais: Antes, Durante e Depois.

Cada passo permite que diferentes ações sejam tomadas, dando maior controle ao Administrador, rastreabilidade ao Auditor, visão ao Aprovador e usabilidade ao Operador.

Ações antes de uma sessão

Antes de uma sessão, o Administrador tem o controle para decidir várias configurações que determinam como o operador fará o login e tirará proveito disso:

  • Conectividade do dispositivo: Além de ser usado em Dashboards, testes de conectividade, troca automatizada de senha e outros módulos, a conectividade determina o tipo de sistema de proxy que será usado para chegar ao dispositivo.

  • Controle de ativação de credenciais: Como visto no módulo Execuções, a credencial pode ser ativada e inativada sob demanda.

  • A política de senha para troca após a sessão: Como visto no módulo Execuções, a credencial pode ser reciclada após o uso em uma sessão proxy.

  • O grupo de acesso e a configuração do workflow: O workflow de uso das credenciais em uma sessão de proxy, bem como a possibilidade de uso emergencial, é configurado pelo administrador nos grupos de acesso.

  • Macros e credenciais RemoteApp: Macros e RemoteApps podem ser configuradas e disponibilizadas em certas credenciais.

  • Comandos auditados globais e segregados: Os comandos auditados para sessões SSH podem ser configurados globalmente ou segregados em Dispositivo, Credencial, Grupo de Acesso ou Origens. Os gatilhos de ação podem ser ligados a comandos, e se o comando for executado, a ação é tomada.

  • Níveis de segurança por protocolo:Cada protocolo pode ter especificações de versão, nível de segurança e algoritmo de criptografia. senhasegura permite a configuração de sistemas de proxies e características específicas do protocolo em nível global e segregado.

  • Ignorando erros no certificado: As conexões RDP normalmente apresentam erros de certificado durante a etapa de conexão. O administrador pode forçar apenas certificados válidos ou ignorar erros de certificado no aperto de mão da conexão.

  • Funcionalidade da sessão: Durante a sessão o usuário pode realizar algumas ações como transferir texto, um arquivo, pressionar <Ctrl+Alt+Del>, realizar uma elevação automatizada de privilégios, etc. Estas ações podem ser permitidas ou bloqueadas em nível global ou segregado.

  • Indexação de textos de entrada e saída: Se a sessão exigir auditoria dos textos digitados e exibidos, você pode configurar se esta auditoria deve ser registrada em nível global ou segregada. Por padrão este recurso está desativado, recomendamos ativá-lo apenas em credenciais e dispositivos que o requeiram.

  • Habilitar wallpaper em sessões RDP?: Algumas empresas utilizam papéis de parede personalizados que contêm informações sobre dispositivos, sessões ou políticas de segurança. Por padrão, a transferência de papel de parede durante sessões do RDP é desativada para melhorar o desempenho do protocolo RDP.

  • Tipos de terminais Linux e Xterm: Alguns sistemas Linux têm diferenças no uso de terminais clientes que utilizam o formato Linux ou Xterm. Isto é influenciado pelo manuseio de códigos ANSI. É possível segregar a configuração do dispositivo para cada terminal.

  • Uso de credenciais pessoais: Alguns dispositivos podem permitir que os usuários do operador utilizem credenciais pessoais que não são gerenciadas pela plataforma, mas que ainda devem estar em conformidade com outras regras de acesso, controle e auditoria. Sob estes cenários, recomendamos que você não indexe textos digitados pelo usuário.

  • Quantidade de sessões proxy simultâneas: A política de segurança pode ser alterada para evitar que um usuário execute mais do que uma certa quantidade de sessões de proxy simultaneamente.

Ações durante uma sessão

Durante a sessão, o usuário operador é passivo a outras funcionalidades que foram previamente configuradas pelo administrador, e outras ações que podem ser imediatamente tomadas pelo administrador.

As configurações devem ser configuradas antes do início de uma sessão. Ela configura vários aspectos da sessão que não podem ser reconfigurados após o início da sessão. Por exemplo, um comando auditado criado ou modificado durante uma sessão SSH em execução não será considerado pelas sessões atuais. Somente novas sessões após a criação do comando serão afetadas.

Vamos entender as ações que podem ocorrer durante a sessão:

  • Execução de comandos auditados: Como vimos, os comandos auditados que foram previamente registrados serão considerados durante a sessão. Se o operador executar estes comandos, a sessão será pontuada com o nível de risco do comando e os administradores serão reportados pelas mensagens SIEM. O usuário do operador ainda pode sofrer uma ação previamente configurada ligada a este comando auditado, como proibir a execução, interromper a sessão proxy, ou mesmo inativar sua conta senhasegura .

  • Avaliação da transferência de arquivos: Os arquivos que são transferidos tanto da estação de trabalho do operador para o dispositivo alvo como do dispositivo alvo para a estação de trabalho do operador podem ser avaliados através de plugins. A demanda por estes plugins deve ser encaminhada à nossa equipe Comercial.

  • Livestream de sessão: Os administradores podem realizar uma visualização ao vivo da sessão em andamento sem o conhecimento do operador. A partir desta janela de visualização, o administrador pode tomar a decisão de interromper a interatividade do operador do usuário. Assim, o operador será notificado de que a interação foi interrompida por um usuário identificado, e não poderá iniciar novas sessões até que esse bloqueio seja liberado. A pré-visualização e a ação de bloqueio são registradas nos logs das sessões.

  • Interrupção da sessão: O administrador pode interromper sem o consentimento do usuário e sem aviso prévio uma sessão em andamento. Esta ação será registrada nos logs da sessão.

  • Elevação do privilégio nas sessões SSH: Durante a sessão SSH o operador do usuário pode realizar a elevação do privilégio através do binário SUDO. Assim, o senhasegura capturará a interatividade do usuário e automatizará a autenticação sem exibir a senha de credencial de acesso.

Ações ao final de uma sessão

Uma vez terminada a sessão, o usuário administrador e o usuário auditor podem observar os detalhes da sessão individualmente e observar a tabela geral das sessões, credenciais e comportamentos dos usuários. A credencial utilizada está disponível para ações de bloqueio ou reciclagem.

Vejamos quais ações estão disponíveis nesta etapa.

  • Eventos da sessão de registro: Durante a sessão, várias ações podem ter ocorrido. Todas essas ações estão disponíveis nos registros das sessões.

  • Vídeo da sessão: A gravação da sessão pode ser reproduzida exatamente como ocorreu.

  • Solicitação de auditoria: A sessão pode ser encaminhada para um ou mais usuários para avaliar a sessão. Esta solicitação é feita por e-mail e a sessão será separada em um relatório de auditoria. O usuário que solicita a auditoria pode escrever um pequeno texto explicando seus motivos.

  • Prevenção de expurgo: Por padrão senhasegura irá expurgar os arquivos de sessão em um intervalo configurável. Mas quando uma sessão é protegida deste expurgo, ela estará disponível pelo tempo que for necessário.

  • Exportação de vídeo da sessão: Se necessário, você pode exportar o vídeo da sessão no formato MP4 para uma auditoria externa.

  • Avaliação de risco: Os comandos auditados detectados na sessão adicionam pontuação à sessão. Esta pontuação é refletida para o Dispositivo, Credencial e Operador do usuário. O administrador tem uma grande visão geral dos riscos envolvidos em seu negócio.

  • Indexação de texto: O texto que foi digitado ou apresentado na sessão está disponível em um relatório que contém o texto de todas as outras sessões que ocorreram. Isto permite que o administrador procure o texto que apareceu em um período de tempo em qualquer dispositivo.

Tecnologias

Agora que você está ciente da funcionalidade, vamos aprender sobre as tecnologias de proxy disponíveis e que funcionalidade elas suportam.

senhasegura Terminal Proxy

O senhasegura Terminal Proxy é um serviço disponível na porta 22 sob o protocolo SSHv2, que auditará as conexões SSH e TELNET alvo.

Possui um terminal simplificado para consulta de credenciais e operações básicas para transferência de arquivos. Mas seu principal objetivo é entregar a conexão ao dispositivo remoto.

Protocolos suportados:

SSH e Telnet.

senhasegura RDP Proxy

O senhasegura RDP Proxy é um serviço disponível na porta 3389 através do protocolo RDP que auditará as conexões RDP alvo.

Ele medeia todas as funcionalidades disponíveis em uma conexão RDP comum entre dispositivos Microsoft Windows, sem interferir na experiência do operador do usuário. Mas com todas as garantias de segurança e auditoria de senhasegura .

Protocolos suportados:

RDP versões 5.2 e superiores.

senhasegura Web Proxy

O senhasegura Web Proxy fornece todos os tipos de conectividade aos dispositivos alvo através de uma interface HTML5 com WebSockets que pode ser acessada por qualquer navegador moderno.

Todas as características que são utilizadas pelos clientes do protocolo padrão estão disponíveis nestas conexões. Algumas funcionalidades podem variar um pouco na usabilidade de rodar em um navegador da web, mas entregam os mesmos objetivos com sucesso.

Por ser um canal mais flexível, sem as limitações de clientes dedicados a protocolos exclusivos, o senhasegura Web Proxy permite sessões de proxy incluindo protocolos e ferramentas particulares, como os sites X11, VNC e HTTP/HTTPS.

Protocolos suportados:

SSH, Telnet, VNC, X11, Citrix VDA, Kubernetes, Websites, Databases ODBC, RDP versões 5.2 e superiores.

info

Para as atividades desta seção, os usuários podem usar qualquer cliente de sua escolha, como PuTTY, MobaXTerm, SecureCRT, Windows RDC e outros.

Chaves de criptografia

Para melhor uso dos proxies no senhasegura é preciso entender que existem dois tipos de conexões:

Uma conexão que se origina através da estação de trabalho do usuário até o cofre.

E outra que sai do cofre até o dispositivo que o usuário deseja acessar. Para que as conexões sejam realizadas de forma segura é necessário que sejam realizadas através de uma criptografia, por isso verifique as chaves de criptografia suportadas por cada proxy.

info

O senhasegura recomenda que sejam utilizados algoritmos de criptografia em sua versão mais recente, por questões de segurança.

senhasegura RDP Proxy

Usa as cifras de acordo com o nível de criptografia.

Estação de trabalho do usuário para o cofre

Utiliza cifras Arcfour(RC4) ou Triple DES caso o nível de criptografia seja FIPS. Os códigos de autenticação de mensagens (MAC) gerados podem usar: MD5 ou SHA-1.

Os protocolos externos de segurança suportados são:

  • TLS 1.0

  • TLS 1.1

  • TLS 1.2 (recomendado)

Cofre para o dispositivo destino

Utiliza cifras Arcfour(RC4) ou Triple DES caso o nível de criptografia seja FIPS. Os códigos de autenticação de mensagens (MAC) gerados podem usar: MD5 ou SHA-1.

Os protocolos externos de segurança suportados são:

  • TLS 1.0

  • TLS 1.1

  • TLS 1.2

  • CredSSP

senhasegura Terminal Proxy

O sistema proxy do senhasegura realiza conexões através dos protocolos SSH ou Telnet.

caution

Quando se utiliza o protocolo Telnet a conexão do cofre até o dispositivo não utiliza criptografia, somente existe criptografia quando o acesso é feito da estação do usuário até o cofre.

Estação de trabalho do usuário para o cofre

O senhasegura suporta as seguintes criptografias:

Ciphers
  • Poly1305

  • AES256-GCM

  • AES128-GCM

  • AES256-CTR

  • AES192-CTR

  • AES128-CTR

MACs
  • hmac-sha2-512-etm

  • hmac-sha2-256-etm

  • hmac-sha2-512

  • hmac-sha2-256

KexAlgorithms
  • curve25519-sha256

  • ecdh-sha2-nistp521

  • ecdh-sha2-nistp384

  • ecdh-sha2-nistp256

  • diffie-hellman-group-exchange-sha256

caution

O uso de algoritmos fracos reduz o escopo de segurança da ferramenta. Consulte nossos especialistas sobre como lidar com sistemas legados.

Uso do Proxy

Aprendemos anteriormente as características e tecnologias disponíveis na plataforma. Agora vamos aprender na prática como estas características são configuradas e utilizadas durante uma sessão proxy.

Características que são válidas para mais de um sistema proxy, tais como indexação de vídeo e texto, serão exemplificadas usando apenas uma única tecnologia proxy para não tornar nosso aprendizado repetitivo.

Configurando o ambiente de proxy

As funcionalidades gerais das sessões de proxy podem ser vistas no menu Configurações ➔ Parâmetros do sistema ➔ Parâmetros do sistema.

Por ser uma tela com vários controles de várias funcionalidades, listaremos aqui apenas os controles que refletem o proxy.

caution

Algumas características em versões anteriores do senhasegura não estão mais presentes nesta documentação. Sugerimos que você evite mudar os parâmetros que não estão neste documento.

Vejamos as configurações na aba Sessão remota.

  • Habilitar transferência de arquivos?: Por padrão marcado com Sim, sinalize se as sessões podem transferir arquivos entre a estação de trabalho de origem e o dispositivo alvo, ou na direção oposta;

  • Enable Ctrl+Alt+Del?: Por padrão marcado com Sim, sinalize se nas sessões gráficas do RDP, se o operador usuário pode pressionar a seqüência de teclas e acessar controles avançados do dispositivo;

  • Habilitar copiar e colar?: Por padrão marcado Sim, sinalize se o operador usuário pode transferir o conteúdo de sua área de transferência para o dispositivo alvo, ou na direção oposta;

  • Ignore certificate errors?: Por padrão marcado com Sim, sinalize se os certificados inválidos nas conexões RDP devem ser ignorados;

  • Enable use of personal credentials?: Por padrão marcado com Não, sinalize se o usuário pode usar as credenciais pessoais para iniciar sessões remotas;

  • Habilitar RAIL over RDP?: Por padrão marcado com Não, sinalize se a tecnologia Microsoft Rails sobre RDP está ativa. Quando ativa, a conexão RemoteApp terá uma usabilidade ainda maior;

  • Habilitar automação de SUDO em sessões Linux?: Por padrão marcado com Não, sinalize se a automação de elevação de privilégios está ativa;

  • Habilitar gatilhos para transferência de arquivos?: Por padrão marcado com Não , sinalize se a transferência de arquivos será avaliada por plugins externos. A demanda por estes plugins deve ser encaminhada à nossa equipe comercial;

  • Tipo de terminal SSH: Por padrão marcado com Linux pode variar como Xterm . Marque o tipo de terminal que será usado nas sessões SSH e Telnet;

  • Habilitar o download para acesso local?: Por padrão marcado com Não , sinalize se o arquivo de extensão RDP ou o arquivo BAT rodando PuTTY1 pode ser gerado por senhasegura e baixado por operadores de usuários facilitando o acesso a uma credencial;

  • Diretório de instalação do PuTTY: Marcar o caminho onde o binário de putty será comumente encontrado nas estações de trabalho dos operadores;

  • Usuários podem alterar diretório de instalação do PuTTY?: Por padrão Não , sinalize se os operadores dos usuários podem alterar o diretório de localização binária no momento do download. Se permitido, os usuários podem escolher um novo local a partir do menu de preferências do usuário;

  • Habilitar wallpaper em sessões RDP?: Por padrão Não , sinalize se o papel de parede da sessão do RDP será apresentado durante a sessão;

  • Incluir hostname no login local em sessões RDP?: Por padrão Não , sinalize se o nome do host de destino será exibido como título da janela;

  • Converter /r/n para /n em sessões SSH realizadas no navegador?: Por padrão Não, sinaliza se os caracteres de fim de linha padrão Microsoft®Windows (\r\n) serão substituídos para formato Unix (\r), ao copiar e colar textos em sessões senhasegura Web Proxy com protocolo SSH.

  • Interface do IPv6 do servidor senhasegura: Nome da interface de rede do IPv6 do servidor senhasegura

  • Profundidade de cor: Profundidade de cor que será usada nas sessões VNC HTTP, apenas. O usuário poderá escolher entre 8 bits até 32 bits, de acordo com a performance que deseja alcançar.

  • Banner de conexão: Ao iniciar uma sessão de proxy, uma mensagem será sempre apresentada ao usuário. Configure esta mensagem nesta propriedade;

  • Indexar textos das sessões?: Por padrão Não, sinalize se os textos da sessão devem ser indexados. Esta configuração deve ser usada em conjunto com as duas outras duas seguintes:

    • Habilitar importação de indice de textos Input?: Por padrão Não, sinalize se os textos de entrada do usuário do operador devem ser indexados. Ou seja, tudo que for digitado será capturado, independentemente de o campo de destino estar mascarado (por exemplo: um campo de senha), ou se o texto em si teve alguma utilidade para a aplicação de destino (por exemplo: um gato andando sobre o teclado);

    • Habilitar importação de indice de textos Output?: Por padrão Não, sinalize se os textos de saída apresentados na tela para o usuário devem ser indexados. Vale lembrar que o texto digitado pelo usuário será gravado se for também uma saída;

  • Habilitar gravação de input do usuário?: Por padrão Sim . Ao contrário das configurações de indexação de texto, esta bandeira de propriedade indica se as entradas serão registradas individualmente na sessão e não está disponível no relatório que cruza todos os textos de todas as sessões;

  • Habilitar gravação de sessão?: Por padrão Sim . Assinale se o vídeo da sessão será gravado. Este vídeo é uma cópia binária otimizada do protocolo que foi transportado. Não confundir com o arquivo MP4 exportado;

  • Habilitar o uso de macro em sessão?: Por padrão Sim , sinalize se é permitido o uso de macros e RemoteApps

  • Ativar expurgo das sessões?: Por padrão Não , sinalize se a plataforma deve descartar automaticamente vídeos de sessões que tenham atingido uma determinada data de expiração;

    • Quantidade de dias para expurgo: Por padrão 90 dias. Marque quantos dias o vídeo deve ser mantido;
  • Quantidade de sessões simultâneas do usuário (zero indica ilimitado): Por padrão 0 , indicando que os usuários podem executar tantas sessões de proxy simultâneas;

  • Habilitar livestream em tempo real?: Por padrão Sim, sinaliza se o administrador pode realizar o monitoramento de livestream na sessão proxy;

Vejamos agora as propriedades disponíveis na sessão Segurança.

  • Forçar autenticação de multifator para iniciar sessão?: Por padrão No, sinaliza se você precisa usar o token 2FA para iniciar sessões de proxy;

  • Habilitar troca de senha após abertura da sessão?: Por padrão No , sinaliza se o senhasegura mudará a senha logo após o início da sessão de proxy;

  • Modo de segurança RDP: Nível de segurança das conexões RDP alvo. Por padrão Automático , onde o cliente e o servidor determinarão o nível de segurança. Por ser uma ponte, o cliente, neste caso, é a plataforma senhasegura . Para configurar o nível de segurança das conexões que chegam ao senhasegura , consulte a seção de configurações do senhasegura RDP Proxy;

  • Habilitar filtro de IPs com permissão para iniciar uma sessão: Se ativo e preenchido, você pode determinar uma lista de IPs, individuais ou em intervalos, que serão permitidos para iniciar uma sessão proxy;

Segregações

Como há muitas configurações na definição de nível global, há a necessidade de segregar algumas dessas configurações para facilitar o gerenciamento da política de segurança e possíveis exceções em dispositivos que não suportam certas configurações.

Por exemplo, alguns dispositivos RDP não suportam o nível de segurança TLS, e devem ser isolados em uma configuração separada se o nível global não estiver configurado no modo Automático.

Outro exemplo são os dispositivos Linux que por decisão estratégica, ou por limitações técnicas, não suportam elevação automatizada de privilégios com SUDO.

Para isolar estes Dispositivos e Credenciais em configurações segregadas, devemos primeiro entender a hierarquia de segregação de senhas.

Níveis de segregação

Através do menu: Configurações ➔ Parâmetros do sistema ➔ Parâmetros segregados, você tem acesso a todas as segregações registradas para sessões proxy.

As segregações respeitam a hierarquia e a ordem de reescrita. Atuando como uma cadeia de camadas de ajustes, a próxima camada terá sempre o poder de reescrever sob a camada anterior:

  1. Parâmetros globais

  2. Parâmetro segregado de grupos de acesso

  3. Parâmetros segregados de dispositivos

  4. Parâmetros segregados de credenciais

  5. Parâmetros segregados por origem

Assim, um parâmetro definido na camada global pode ser sobrescrito pela segregação do grupo de acesso, que por sua vez pode ser sobrescrito pela segregação do dispositivo, e assim por diante.

caution

Dispositivos e credenciais não podem ser incluídos em mais de um parâmetro segregado.

A camada segregadora tem a opção de manter o parâmetro atual inalterado. Portanto, não há a obrigação de definir todos os parâmetros para cada camada.

info

Observe que no campo Profundidade de cor (que é exibido em todos os tipos de segregação) você pode escolher qual profundidade de cor deseja usar nas sessões VNC HTTP, apenas para se adequar ao desempenho desejado. As opções variam de 8 bits a 32 bits.

Imagine um exemplo em que a bandeira de conexão foi definida na camada Global. Assim, todas as sessões de proxy exibirão o mesmo banner.

Mas existe um grupo de acesso específico para funcionários terceirizados que precisam de uma mensagem diferente dos outros. O administrador deve então criar uma segregação em nível de Grupo de acesso, mudar o valor do banner e escolher os grupos de acesso apropriados para essa segregação.

Todas as sessões que ocorrerem a partir desse grupo de acesso terão uma bandeira diferente da bandeira Global.

Se ainda houver um caso em que uma determinada Credencial requer um banner diferente, o administrador pode então criar uma segregação de credenciais, modificar o banner e vincular as credenciais necessárias.

Assim, mesmo que o usuário seja um funcionário terceirizado enquadrado no grupo que já continha segregação, a mensagem de banner será novamente alterada por segregação de credenciais devido a sua prevalência sob segregação de grupo de acesso.

A cada sessão proxy, o senhasegura sempre enquadrará o requerente a um Grupo de Acesso que permita o uso de uma Credencial de Dispositivo. E este usuário começa sempre a partir de uma estação de trabalho fonte. Assim, o senhasegura sempre será capaz de determinar uma combinação apropriada de parâmetros para esta sessão.

A imagem proxy-100 mostra que a configuração Global permite a transferência de arquivos.

Configurações de sessão remota

A imagem proxy-110 demonstra que existem segregações para todas as camadas, e cada segregação tem um nome que deixa clara a intenção de usar.

Relatório de parâmetros segregados

O exemplo da segregação de faixas manteve todos os outros parâmetros inalterados. Apenas o banner foi definido.

Exemplo de segregação de bandeiras

O exemplo de segregação de dispositivos inativou a execução automática de elevação de privilégios e permitiu o uso de credenciais pessoais.

Exemplo de segregação de dispositivos

O exemplo de segregação de credenciais não permite a transferência de arquivos, o uso de prancheta, e não permite o uso da combinação de teclas <Ctrl+Alt+Del>.

Exemplo de segregação de credenciais

O exemplo de segregação de fonte está forçando o uso do 2FA para visualizar senhas e iniciar sessões de proxy e permite a reciclagem imediata de senhas após a sessão de proxy ser aberta.

Exemplo de segregação de origem

Note que existe a possibilidade de que uma sessão tenha que considerar algumas dessas regras, todas ou nenhuma. Tornando as possibilidades de configuração muito flexíveis.

sectionsenhasegura Terminal Proxy

caution

O senhasegura se autentica no dispositivo de destino utilizando os protocolos nativos da sessão solicitada. Entregando ao usuário uma sessão já autenticada, sem risco de expor a credencial usada.

O senhasegura Terminal Proxy é um serviço SSH operando na porta 22 padrão que autentica o usuário do senhasegura usando a mesma conta que o usuário usa na interface web. Este login respeita o mesmo bloqueio de conta e as mesmas configurações 2FA.

Uso básico

Ao fazer o login, o usuário será direcionado para o prompt padrão como na imagemproxy-terminal-100.

Proxy terminal

Este terminal simplificado tem apenas comandos para iniciar uma sessão proxy para um dispositivo remoto e transferir arquivos entre o dispositivo de origem e o dispositivo de destino. Use o comando help para listar os comandos disponíveis.

Para listar as credenciais de acesso, use o comando list.

Credenciais de acesso à lista

Observe que a conectividade disponível é exibida na primeira coluna, e dados de acesso como Nome do usuário, Hostname , e IP são listados a seguir.

caution

Credenciais de domínio não são listadas através deste comando. Para realizar o acesso com credenciais de domínio é necessário utilizar a seguinte sintaxe: ssh dominio\usuário@servidor

Credenciais de máquinas virtuais do módulo de Cloud não são listadas através deste comando. Para realizar o acesso com credenciais de instâncias AWS OpsWorks é necessário utilizar a seguinte sintaxe: list –cloud.

info

Lembre-se que a gestão de máquinas virtuais é realizada pelo módulo Cloud do senhasegura , consulte o Manual Cloud IAM para mais informações.

Para fazer uma conexão SSH a um dispositivo que tenha esta conectividade ligada a uma credencial válida, execute o comando ssh seguido da credencial e do dispositivo como faria em uma conexão SSH padrão. Exemplo: ssh usr01@mylinuxserver ou ssh usr01@172.18.50.201.

Conexão SSH

Para sessões TELNET, basta executar o comando telnet seguido da credencial e do dispositivo da mesma forma. Exemplo: telnet admin@myrouter.

Quando você sair do dispositivo remoto, o usuário retornará ao senhasegura Terminal Proxy prompt.

Acesso usando chave ssh

Para realizar um acesso com chaves ssh utilize a seguinte sintaxe, substituindo as seguintes strings por:

  • keyValue: valor da chave ssh

  • valtServer: instância senhasegura

  • targetDevice: dispositivo que você deseja acessar

  • ssh keyValue@valtServer Acessando a instância;

  • ssh key keyValue@targetDevice Acessando outro dispositivo;

  • ssh key\keyValue@targetDevice Acessando outro dispositivo ou quando uma chave e credencial possuírem o mesmo nome.

2FA token de acesso

caution

De acordo com a Postura de Segurança do Usuário, o uso de 2FA para iniciar uma sessão pode ser obrigatório ou necessário com mais frequência

Se o acesso 2FA estiver configurado, o token será solicitado quando você fizer o login no Terminal Proxy.

2FA token de acesso

Se você configurar para solicitar um token 2FA mesmo ao iniciar sessões proxy, você será solicitado novamente.

O workflow de acesso e as configurações de acesso de emergência também serão aplicados, se necessário.

Fluxo de acesso e emergência

Acesso usando Multihop

Para facilitar o acesso ao dispositivo alvo em aplicações que não fornecem prompts interativos, ou mesmo para facilitar o acesso aos usuários que preferem deixar configurações específicas de conexão salvas, o senhasegura Terminal Proxy aceita uma sintaxe de conexão que contém a credencial de acesso ao destino.

Isso é útil para que os aplicativos possam se conectar diretamente ao destino sem a necessidade de etapas adicionais. Dê uma olhada em suas variações de sintaxe, substituindo as seguintes strings por:

  • valtUser: usuário senhasegura

  • valtServer: instância senhasegura

  • targetUser: credencial que você deseja usar para acesso

  • targetServer: servidor que você deseja acessar

  • valtUser@valtServer Cadeia de conexão padrão somente com o usuário e o servidor senhasegura .

  • valtUser[targetUser@targetServer]@valtServer Conexão contendo o usuário e o servidor senhasegura . A credencial e o dispositivo alvo estão entre parênteses. Neste caso, o Terminal Proxy senhasegura se conectará diretamente ao servidor de destino sem a entrega do terminal intermediário.

    Conexão contendo o usuário e o servidor senhasegura
  • valtUser[targetUser@targetServer]2faToken@valtServer Conexão multihop contendo a ficha OTP.

    Exemplo de conexão Multihop contendo a ficha OTP

Transferência de arquivos

caution

Para a transferência de arquivos, diretamente ao servidor destino, é obrigatório o uso de conexão multihop, pois os binários que trafegam sob SFTP não têm uma maneira de interagir com o terminal intermediário.

A transferência de arquivos não permite o uso de credenciais pessoais devido a uma limitação do protocolo. Não é possível usar uma segunda credencial para autenticação. Somente a conta de usuário senhasegura será utilizada.

info

Se o usuário tiver um token OTP configurado, faça uso do token na cadeia de conexão.

A imagem proxy-terminal-200 usa o programa WinSCP como um exemplo.

O programa WinSCP como exemplo
O programa WinSCP como exemplo

A imagem proxy-terminal-220 utiliza uma versão de linha de comando do SFTP.

O programa WinSCP como exemplo

Para usar o comando scp, use a sintaxe abaixo, substituindo as strings por:

  • fileName: Arquivo a ser transferido

  • vaultServer: Instância senhasegura

  • vaultUser: Credencial que irá autenticar na instância senhasegura

  • fileDestination: Local para onde o arquivo deve ser transferido

  • scp fileName vaultUser@vaultServer Upload de um arquivo para a instância senhasegura .

  • scp vaultUser@vaultServer:fileName fileDestination Download de um arquivo da instância senhasegura para máquina solicitante.

caution

Para transferir um arquivo via SCP de uma máquina do usuário para um servidor destino, são necessárias duas etapas. A primeira etapa ocorre quando esse arquivo é transferido para a instância senhasegura . E na segunda etapa, o usuário conecta no senhasegura Terminal Proxy para transferir o arquivo da instância senhasegura para o servidor destino.

Essas duas etapas existem por não ser possível realizar uma transferência utilizando a sintaxe multihop.

Para facilitar o uso, dê preferência a transferências utilizando SFTP.

Elevação automatizada de privilégios

Os sistemas Linux em conexão SSH têm elevação automática de privilégios usando o binário SUDO. Nestes casos, o usuário terá sua interatividade capturada e senhasegura realizará a elevação usando a mesma credencial usada para autenticar no dispositivo alvo.

Assim, o usuário poderá realizar tarefas elevadas sem ter que saber a senha de credencial.

Observe neste primeiro exemplo que o usuário executa um super comando sem ter que digitar a senha de credencial.

Exemplo de super comando

Se a elevação de privilégios for inativada na sessão, a senha de credencial do dispositivo é solicitada.

A elevação do privilégio é um exemplo inativado

Bloqueio de interatividade e logout obrigatório

Se o administrador ativar o bloqueio de interatividade, o usuário operador será avisado por uma mensagem no canto superior direito.

Exemplo de bloqueio de interatividade

E, se o administrador sair obrigatoriamente da sessão, o usuário também é avisado.

Alerta de logout obrigatoriamente da sessão

SSH RemoteApp

Um RemoteApp em conexão SSH é realizado alavancando os canais do protocolo. A conexão é estabelecida e um canal é aberto diretamente no binário desejado.

Se o binário exigir autenticação, ela pode ser realizada através dos argumentos binários ou pela macro de automatização.

O usuário operador será isolado no binário RemoteApp porque não há nenhum terminal intermediário. Se o usuário fechar o binário da RemoteApp, a sessão é encerrada.

caution

Para a RemoteApp, o recurso de Comando Auditado não estará disponível.

Para configurar a RemoteApp é necessário configurar a macro através do menu PAM ➔ Configurações ➔ Acesso ➔ RemoteApp. Neste relatório, você tem acesso a todas as Macros e RemoteApps registradas na plataforma.

Usaremos a RemoteApp MySQL como um exemplo.

Exemplo de configuração da RemoteApp

Observe que a configuração é preenchida com a localização do binário, e como argumentos, as máscaras serão aplicadas ao usuário, senha e informações adicionais. As informações adicionais serão preenchidas com o nome do banco de dados que será conectado.

Formulário de credencial

Finalmente, configure a credencial com a macro RemoteApp para usar, e se necessário, forneça a credencial de acesso ao dispositivo.

Formulário de credencial- guia Configurações adicionais

Quando você faz o login usando o Terminal Proxy senhasegura, o pedido será apresentado imediatamente.

senhasegura Terminal Proxy

Keep Alive

Para situações em que o administrador ou usuário precisa manter a sessão em inatividade, existe a possibilidade de ativar a configuração Keep Alive. Esta configuração pode ser acessada no menu Settings ➔ System Parameters ➔ Remote session.

Keep Alive

Ativando o parâmetro Ativar "Keep Alive" para sessões SSH?', o senhasegura irá enviar a sessão uma instrução vazia a cada 1 minuto de inatividade, mantendo a sessão em execução.

sectionsenhasegura RDP Proxy

caution

O senhasegura se autentica no dispositivo destino utilizando os protocolos nativos para sessão solicitada. Entregando ao usuário uma sessão já autenticada, sem risco de expor a credencial usada.

O senhasegura RDP Proxy é um servidor RDP em execução na porta padrão 3389. Seu objetivo é realizar o proxy entre o usuário operador e o dispositivo RDP alvo, oferecendo as mesmas funcionalidades descritas acima, sem intervir na usabilidade natural das sessões RDP, comumente em sessões do Microsoft Windows.

Qualquer dispositivo que ofereça a conexão do protocolo RDP pode ser conectado desde que esteja alinhado com os níveis de segurança oferecidos enquanto o senhasegura atua como servidor (na comunicação entre a estação de trabalho do usuário com a plataforma senhasegura ), ou como cliente (na comunicação entre a plataforma senhasegura com o dispositivo servidor alvo).

  • Suporte para Windows RDP versão 5.2 e superior;

  • Suporte para Microsoft®Windows®2003 e superior;

  • Suporte para Linux XRDP servers versão 0.9.x e superior;

  • Suporte para RAIL session connection;

Conexão a um dispositivo remoto

Usando qualquer cliente RDP, faça uma conexão com o servidor senhasegura . Você pode conectar-se ao senhasegura usando a cadeia de conexão multihop para acelerar o preenchimento dos seguintes campos.

RDP example
RDP example

Uma vez conectado ao senhasegura RDP Proxy, você deve preencher os dados de autenticação e os dados do dispositivo remoto a ser conectado.

Se o dispositivo aceitar o uso de credenciais pessoais, forneça a credencial pessoal no campo indicado.

Acesso senhasegura RDP Proxy

Caso seja necessário registrar a justificativa ou solicitar autorização para fazer a conexão.

Acesso usando Multihop

Para facilitar o acesso ao dispositivo alvo use uma sintaxe de conexão que contenha a credencial de acesso ao destino.

Dê uma olhada em suas variações de sintaxe, substituindo as seguintes strings por::

  • valtUser: usuário senhasegura

  • targetUser: credencial que você deseja usar para acessos

  • domain: domínio do dispositivo a ser acessado

  • device: dispositivo que você deseja acessar

  • token: código token para autenticação do acesso

  • valtUser[domain\targetUser@device] Conexão contendo o usuário, dispositivo e domínio

  • valtUser[targetUser@device] Conexão contendo o usuário e o dispositivo

  • valtUser[domain\targetUser@device]token Conexão contendo o usuário, dispositivo e token de acesso

caution

Os usuários com tokens 2FA configurados também serão apresentados ao prompt de token na próxima etapa.

Transferência de arquivos e área de transferência

senhasegura RDP Proxy utiliza o protocolo RDP nativo. Portanto, todos os recursos compartilhados entre o lado cliente e o lado servidor funcionarão como uma conexão RDP natural mesmo com as camadas de monitoramento de senhasegura .

É importante lembrar que a transferência de arquivos deve estar habilitada nos parâmetros de sessão remota para funcionar. Vá até o menu Configurações ➔Parâmetros do sistema ➔Parâmetros do sistema ➔ Sessão remota e escolha a opção Sim no parâmetro *Habilitar transferência de arquivos?**.

Para transferir um arquivo do lado do cliente para o dispositivo de destino, copie o arquivo desejado e cole-o em uma pasta no dispositivo de destino. O senhasegura irá então registrar esta ação e se qualquer plugin de transferência de arquivo estiver ativo, ele será acionado antes que o arquivo atinja o destino de destino.

Para os dados de texto armazenados na área de transferência, os dados serão registrados em textos indexados pela sessão, mas nenhum plugin será acionado.

Você também pode transferir recursos locais para a máquina destino utilizando a conexão de área remota do Microsoft®Windows®.

Compartilhando uma unidade

Bloqueio de interatividade e logout obrigatório

Se o administrador ativar o bloqueio de interatividade, o usuário operador será avisado por uma mensagem no canto superior.

Exemplo de bloqueio da interatividade do RDP

E se o administrador encerrar compulsoriamente a sessão, o usuário também é avisado.

Administrador encerra obrigatoriamente a sessão

Keep Alive

Para situações em que o administrador ou usuário precisa manter a sessão em inatividade, existe a possibilidade de ativar a configuração Keep Alive. Esta configuração pode ser acessada no menu Settings ➔ System Parameters ➔ Remote session.

Keep Alive

Ativando o parâmetro Ativar "Keep Alive" para sessões RDP?', o senhasegura irá enviar a sessão uma instrução de movimento de mouse a cada 1 minuto de inatividade, mantendo a sessão em execução.

2FA token access

caution

De acordo com a Postura de Segurança do Usuário, o uso de 2FA para iniciar uma sessão pode ser obrigatório ou necessário com mais frequência

Se o uso de 2FA estiver configurado, o token será solicitado quando fizer login no proxy RDP.

2FA token access

Seu uso será aplicado nos processos de workflow de acesso e acesso de emergência, se necessário.

Workflow de acesso e acesso emergencial

sectionsenhasegura Web Proxy

caution

O senhasegura se autentica no dispositivo destino utilizando os protocolos nativos para sessão solicitada. Entregando ao usuário uma sessão já autenticada, sem risco de expor a credencial usada.

senhasegura Web Proxy é o proxy que roda diretamente no navegador. Basta ser um navegador moderno com suporte a HTML5 e WebSocket. Você não precisa instalar agentes na estação de trabalho do usuário operador.

Os protocolos de destino são mais abrangentes. Através do navegador da web, o usuário terá acesso aos dispositivos de destino que operam nos seguintes protocolos:

  • SSH and TELNET: Com as mesmas características da senhasegura Terminal Proxy

  • RDP: Com basicamente uma diferença no upload e download de arquivos e sem a possibilidade de compartilhar recursos da máquina fonte. Entretanto, com a mesma usabilidade de operar aplicações remotas;

  • HTTP: Acesso autenticado a um site de destino através de um navegador embutido e isolado;

  • VNC: Acesso protegido a dispositivos com suporte de VNC;

  • X11: Acesso protegido a dispositivos com suporte X11;

É claro que, estando em um navegador, as integrações que ocorreriam naturalmente em clientes dedicados de ponta a ponta não são as mesmas. Mas as principais características são fornecidas por meios rápidos e práticos.

Executando o acesso

As sessões de proxy podem ser iniciadas a partir de diferentes páginas na Interface Web senhasegura :

  • Através do relatório de credenciais no módulo PAM;

  • Através do relatório chave SSH no módulo PAM;

  • Procurando por credenciais no módulo de desktop Desktop

Nestas páginas listadas, quando a credencial ou chave é listada, e se o operador tiver permissão para executar uma sessão de proxy, a ação Iniciar uma sessão de registro pode ser usada.

Esta ação validará as mesmas premissas que outros proxies, exceto apenas a necessidade de autenticação de usuário e senha, uma vez que você já está autenticado pela interface web. Outras etapas, tais como seleção de Macro RemoteApp, digitação de Token e solicitação de Workflow serão apresentadas, se necessário.

A grande diferença está apenas nos protocolos adicionais HTTP, VNC e X11. E a forma como eles transferem os arquivos.

Transferência de arquivos em sessão Web RDP

Ao iniciar uma sessão RDP Web, se você tiver permissão para transferir arquivos tanto nas propriedades da sessão senhasegura quanto no dispositivo alvo, o Web Proxy disponibilizará uma unidade mapeada na sessão alvo em uma unidade mapeada G denominada senhasegura .

Através desta unidade mapeada você terá acesso aos arquivos que foram carregados no destino, bem como arquivos de transferência do destino para o usuário operador usando um download.

Para fazer um upload, basta arrastar um arquivo de sua estação de trabalho de origem para a guia do navegador que hospeda a sessão. Você verá uma barra de progresso para este upload no canto inferior direito da sessão. E ao final da transferência, este arquivo estará disponível na pasta raiz do drive G.

Para baixá-lo, basta copiar um arquivo do dispositivo alvo para a pasta G: \Download. Você receberá um prompt de download no canto inferior direito do navegador. Confirmando, o arquivo será transferido para sua estação de trabalho.

A sessão Web HTTP

A sessão web HTTP acontece em um ambiente isolado contendo um navegador otimizado e protegido para realizar o acesso aos sites. A interatividade do usuário é semelhante à sessão do RDP.

O navegador é configurado para evitar a abertura de novas abas. Todos os componentes gráficos do navegador estão ocultos. Até mesmo os menus de interação e as teclas de atalho estão bloqueadas.

Para criar um website a ser acessado, você precisa de um procedimento complementar, em comparação com outros dispositivos, onde você só precisa do dispositivo com conectividade e uma credencial de acesso.

Os sites da Web exigem uma configuração de autenticação. Esta configuração permite que nosso navegador incorporado realize a automação das etapas de login.

Durante este processo de autenticação, o usuário será presenteado com um banner de proteção que evita que o usuário interfira e veja a autenticação em andamento. Sua interatividade será devolvida somente quando o processo de login terminar com sucesso ou fracasso.

info

Os sites modernos têm passos de confirmação usando Captcha e 2FA/MFA Tokens para evitar que sistemas automatizados realizem acessos indesejados. Nesses casos, o Web Proxy retorna interatividade para que o usuário continue a etapa de autenticação. Normalmente, estas etapas ocorrem após a confirmação do usuário e da senha. Mas se forem necessárias mais etapas automatizadas após o envio externo, você pode continuar a partir deste ponto.

Configuração de um conjunto de dispositivos, credenciais e autenticação web HTTP

Inicialmente registraremos um dispositivo que representará o site.

Se for um website instalado em sua própria infra-estrutura significa que você também terá gerenciamento de usuários de banco de dados e sistema operacional.

Entretanto, a fim de realizar a automação do acesso à web, deve ser criado um dispositivo para representar apenas o Website. Isto nos permite vincular nossa automação ao produto indicado no campo Produto. Esta separação também permite uma melhor segregação nos grupos de acesso.

Em nosso exemplo, registraremos um servidor que está hospedando um serviço de monitoramento Zabbix®2 acessível pela porta 80 com protocolo HTTP.

O campo Tipo de dispositivo deve ser preenchido no Aplicativo Web e os campos Fabricante e Produto podem ser criados automaticamente com o valor desejado, se necessário.

Forma do dispositivo

Na guia conectividade, preencha a conectividade correta para o site que está sendo acessado.

Forma do dispositivo - Aba Conectividade

Agora vamos registrar as etapas de automação. Ir para o menu Configurações ➔ Acesso ➔ Sessão Web . Neste relatório, você verá toda a automação já registrada. Para criar novas, vá para a ação de relatório Novo.

Relatório de parâmetros da sessão Web

Na tela de registro, preencha o campo Modelo Equipamento com o mesmo modelo que o registro do Dispositivo. Esta será a ligação necessária entre a configuração e o dispositivo para realizar a automação.

Formulário de parâmetros da sessão web

No campo Login URL, forneça a URL de login do site. Se o site utiliza autenticação HTTP, forneça sua senha no campo HTTP Auth Realm.

Na grade abaixo, configuraremos cada etapa de autenticação. As ações são compostas dos seguintes campos:

  • Aguardar (ms): Tempo de espera em milissegundos antes de agir. A primeira ação deve ter este tempo ajustado ao tempo de renderização da página;

  • Ação: Este é o tipo de ação que será realizada simulando um usuário que está se autenticando no site. Algumas destas ações têm propriedades adicionais. Consulte nossa documentação oficial para maiores informações;

  • Extra: Este é o tipo de ação que será realizada simulando um usuário que está se autenticando no site. Algumas destas ações têm propriedades adicionais. Consulte nossa documentação oficial para maiores informações;

  • Campo: É o seletor jQuery3 utilizado para identificar o campo alvo da ação;

  • Valor: Este é o valor que será usado para preencher o campo. Os valores podem ser fixados simplesmente digitando seu valor Você pode preencher usando tags como [username] e [password]; As tags personalizadas definidas na aba Additional settings do registro de credenciais, na tabela Campos extras, podem ser usadas aqui;

  • Tentativas: O número de vezes que a automação deve tentar a ação se ela falhar. As razões para o fracasso muitas vezes variam entre um seletor errado, uma ação inadequada ou mesmo não ter tido tempo de tornar a página para automação encontrar o campo desejado;

  • Intervalo (ms): É o tempo que a automação deve esperar até que a ação seja retomada. Curiosamente, que a primeira ação tem um número adequado de tentativas e tempo de intervalo;

As outras etapas de automação podem contar com valores menores para o Aguardar. e o campo de Intervalo, pois geralmente já estarão disponíveis se o primeiro campo já tiver sido encontrado.

info

Para autenticações que incluem etapas posteriores, ajuste o tempo de espera das ações iniciais de cada etapa como se elas fossem as primeiras.

Se você precisar autenticar um Captcha, indique o seletor do elemento que hospeda o componente principal. Somente este componente será apresentado ao usuário para que ele termine o processo. Este isolamento impede que o usuário modifique qualquer outro valor já povoado.

Algumas tecnologias captcha mais sofisticadas precisam apresentar toda a página de autenticação porque não permitem a manipulação do componente que a hospeda. Portanto, terminam a automatização no momento da captcha. A sessão já está sendo gravada e se o usuário modificar a autenticação, você terá o vídeo para provar isso.

Ao fazer o login, você verá o navegador incorporado acessar o site. Quando a página de autenticação for carregada, você será apresentado a um escudo que impede a interação do usuário. Isto significa que a autenticação ainda está em execução.

Progresso da autenticação

No final, se a automação estiver devidamente configurada, o usuário será liberado para usar o site.

Transferência de arquivos

A transferência de arquivos em sessões Web HTTP é similar às sessões Web do RDP. Você deve arrastar o arquivo para a aba que contém a sessão.

Transferência de arquivos

O arquivo será então transferido para um local visível apenas por sua sessão. Uma mensagem de confirmação aparece no canto inferior direito.

Aparece uma mensagem de confirmação

No site que você está operando, se houver um campo de upload, você pode navegar pela pasta principal da sua sessão. Haverá todos os arquivos que você carregou.

Navegando na pasta de casa

Para downloads, a usabilidade é ainda melhor. Você será perguntado se deseja fazer o download do arquivo. Escolha a opção Salvar arquivo e confirme.

Baixe o exemplo do arquivo

Ao final do download, uma mensagem no canto superior direito da bandeira de que um novo download foi feito. Esta mensagem está no navegador incorporado.

No canto inferior direito, você receberá uma mensagem com um link para download. Esta mensagem está em seu navegador. Ou seja, no navegador do usuário do operador.

Este link para download irá baixar o arquivo solicitado do site de destino.

Estas etapas ocorrem porque você deve primeiro baixar o arquivo remoto para a área acessível pelo navegador incorporado, e depois baixar esta área pertencente à sessão Web HTTP em sua estação de trabalho de origem.

Exemplo de download - Sessão Web HTTP

RDP RemoteApp

Uma conexão RDP RemoteApp é realizada através de canais do protocolo.

A conexão é estabelecida e um canal é aberto diretamente no binário desejado.

Se o binário requer autenticação, ela poderá ser realizada através dos argumentos binários ou pela macro de automação.

O usuário do operador será isolado do binário RemoteApp dentro da sessão do RDP. Se o usuário minimizar a janela do aplicativo, não será possível usar outros aplicativos. Além disso, se o usuário fechar o binário RemoteApp, a sessão será encerrada.

caution

Para o RemoteApp, o recurso de comando auditado não estará disponível.

Para configurar o RemoteApp, é necessário configurar a macro através do menu PAM ➔ Settings ➔ Access ➔ RemoteApp. Neste relatório, você tem acesso a todas as macros e RemoteApps registrados na plataforma.

Observe que a configuração é preenchida com a localização do binário e, como argumentos, as máscaras serão aplicadas ao usuário, senha e informações adicionais.

Por fim, configure a credencial com a macro RemoteApp para usar e, se necessário, forneça a credencial de acesso ao dispositivo.

Quando você faz login usando senhasegura RDP Proxy , o aplicativo será apresentado imediatamente.

Iniciando um RemoteApp RDP com o senhasegura Web Proxy
RDP RemoteApp em execução na sessão senhasegura Web Proxy session

2FA token access

caution

De acordo com a Postura de Segurança do Usuário, o uso de 2FA para iniciar uma sessão pode ser obrigatório ou necessário com mais frequência

Se o acesso 2FA estiver configurado, o token será solicitado quando você fizer login no senhasegura Web Proxy .

2FA token access

Se você configurar para solicitar um token 2FA mesmo ao iniciar as sessões de proxy, você será solicitado novamente.

Regras de Workflow de acesso e acesso emergencial também serão aplicados, se necessário.

Regras de workflow e acesso emergencial

Compartilhamento de sessão

Durante a sessão, o operador pode convidar outros usuários ou administradores a participar da mesma sessão. Esse recurso permite a colaboração entre os usuários, facilitando que dois operadores executem ações no mesmo dispositivo de destino.

caution

Esse recurso só está disponível em sessões senhasegura Web Proxy . Os recursos locais, como mouse e teclados devem ser alternados entre os membros. Apenas um usuário pode interagir com o dispositivo de destino por vez.

Para executar um compartilhamento de sessão:

  1. O administrador localizará a sessão de destino no relatório Remote Session;

  2. Clique na ação Compartilhamento de sessão;

  3. No formulário de Compartilhamento de sessão, selecione quais usuários receberão uma sessão dedicada conectada à sessão de destino;

  4. Os usuários selecionados receberão um email com um link para se conectar na sessão compartilhada;

Usando credenciais pessoais

Se o cliente permitir que os usuários usem suas próprias credenciais para autenticação em dispositivos remotos. É necessário que estes dispositivos, ou usuários, sejam devidamente segregados com a permissão para usar uma credencial pessoal.

Nestes casos, quando o usuário acessa o dispositivo, ele fornecerá seu usuário juntamente com o nome do dispositivo administrado pela senhasegura . Neste momento, o sistema de proxy solicitará a senha para a credencial pessoal.

Usando credenciais pessoais
info

O uso de credenciais pessoais não impede o uso de Grupos de Acesso com workflow, 2FA tokens, acesso de emergência, comando auditado, ou qualquer outro mecanismo disponível para sessões proxy.

caution

Recomenda-se que para usuários e dispositivos que utilizam uma credencial pessoal, a indexação de textos digitados não deve ser configurada, a fim de não infringir o direito do usuário à privacidade. Mas se a senha pessoal do usuário, ou seus dados pessoais forem exibidos na tela devido à saída do dispositivo alvo, estes textos podem ser indexados se configurados. E eles estarão presentes no vídeo da sessão.

info

O uso de credenciais pessoais está disponível apenas para senhasegura Terminal Proxy e senhasegura RDP Proxy.

Logs e vídeos das sessões

A aplicação de políticas de segurança e o fornecimento de acesso otimizado aos operadores são passos importantes na operação. Mas a rastreabilidade, velocidade e tomada de decisão com base nos dados das operações são os diferenciais que melhoram o negócio.

Todas as tecnologias de proxies são registradas ao próximo ao formato bruto do protocolo. Todos os dados enviados pelo usuários e dados recebidos pelos usuários são registrados. Desta forma, entradas do usuário, área de transferência, transferência de arquivos, movimento do mouse, gliphs, metadados e todas as outras camadas de abstração de comunicação podem ser identificadas e registradas como realmente são, se o protocolo nativo suportar sua interação.

Diferente de outras soluções de mercado, o senhasegura não realiza capturas de tela em formato de imagem, ou renderização em tempo real de vídeos MP4 ou outros formatos de mídia. A persistência real de protocolo garante uma cópia fiel e otimizada da sessão. Tempos de inatividade são registrados através de timestamp de 4bytes por segundo, diferentemente de capturas de telas que iriam consumir muito mais recursos. A gravação em formato nativo do protocolo já considera o formato de compressão nativo do protocolo.

Veremos agora como avaliar as sessões individualmente e em conjunto. E que valores podemos extrair dessas experiências.

Logs para uma sessão

Através do menu PAM ➔ Controle de acesso ➔ Sessões remotas você tem acesso às sessões de proxy. Tanto as sessões que estão em execução como as sessões já concluídas.

Na sessão em andamento, você tem acesso às seguintes operações:

  • Live Stream: Acompanhamento ao vivo da sessão em andamento. Esta ação só está disponível se a configuração aplicada à sessão permitir a gravação;

  • Interromper sessão:Possibilidade de interromper imediatamente a sessão;

  • Lock / Release interactivity: Bloqueia ou libera interatividade do usuário na sessão. Este bloqueio pode ser realizado de dentro do Live Stream.

Nas sessões concluídas, você terá as seguintes operações:

  • Log das sessões: Detalhes de acesso e eventos logados. Nesta tela é possível realizar uma exportação em CSV dos detalhes;

  • Vídeo da sessão: Possibilidade de reproduzir a sessão através da gravação do protocolo. Esta ação só está disponível se a configuração aplicada à sessão permitir a gravação;

    Possibilidade de exportar o vídeo em formato MP4 para uma auditoria externa;

    Você pode visualizar uma série de informações de sessão, como usuário de sessão, IP de origem, credencial, protocolo, ID de sessão e inicio e término de sessão.

Para todos os registros, independentemente do estado, você tem as seguintes operações:

  • Impedir expurgo: Proibir a expurgo automática da sessão;

  • Configurar os auditores da sessão: Encaminhar uma mensagem de e-mail a um usuário da plataforma para que ele possa auditar a sessão. Esta sessão estará disponível no menu Controle de acesso ➔ Sessões para auditoria. Essa funcionalidade é melhor descrita na seção proxy-auditoria na página proxy-auditoria deste mesmo manual.

Logs de sessão

Para visualizar os logs de sessões remotas, a partir da lista de sessões remotas, clique em Logs da sessão da sessão. Nesta tela é possível visualizar uma série de informações da sessão, como usuário que realizou a sessão, IP de origem, credencial, protocolo, session ID e início, término e tempo da sessão.

Além disso, também fica registrado os usuários que acessaram os logs da sessão ou vizualizaram o vídeo da sessão como mostra a figura access-0007.

Tela de detalhes de log de sessão

Para exportar os logs da sessão, clique em Exportar dados.

Textos centralizados indexados

Todas as sessões que permitem a gravação de entrada e saída de texto serão processadas após o término da sessão. E então seus textos podem ser consultados no relatório Access control ➔ Session texts.

Neste relatório você pode procurar qualquer termo no campo Informação para obter um relatório de todas as sessões em que este termo foi digitado ou apresentado ao usuário, independentemente do protocolo.

É importante notar que às vezes o texto parece quebrado porque baseado no tempo em que foi exposto ou por causa de caracteres do sistema que podem interromper o texto.

info

As sessões RDP executadas utilizando senhasegura RDP Proxy são indexadas usando o OCR e os gliphs RDP nativos. Na etapa OCR, senhasegura RDP Proxy renderiza a tela inteira para conceder uma melhor captura de texto usando a tecnologia Google Tesseract. Todos os textos impressos na sessão do usuário serão considerados com até 90% de sucesso.

Diferentes tipos de texto podem ser digitalizados através de textos naturais do protocolo e via OCR:

  • Nomes de janelas;

  • Nomes de campos e seus valores;

  • Comandos e saídas de comandos em terminais;

  • Nomes de ícones no Desktop e em janelas;

  • Conteúdos de textos abertos;

  • Conteúdos de websites;

  • Inicialização de aplicativos;

Usuários bloqueados

Como explicamos na operação de proxies, um usuário pode ter sua interatividade bloqueada e permanecer bloqueado até que um administrador decida liberar o uso.

Este bloqueio impede que o usuário inicie novas sessões independentemente da tecnologia de credenciamento, dispositivo ou proxy.

Para listar os usuários bloqueados, e liberá-los se necessário, vá para o relatório Controle de acesso ➔ Usuários bloqueados.

Arquivos transferidos em sessão

Se a instalação tiver algum plugin de monitoramento de arquivos, estes arquivos estarão disponíveis no relatório Controle de acesso ➔ Arquivos trafegados.

Solicitações de workflow de acesso

Os detalhes de como funciona o workflow de acesso já foram explicados anteriormente.

As requisições estão presentes em três menus diferentes. Se você é o solicitante, verá seu pedido no relatório Controle de acesso ➔ Minhas solicitações.

Se você é um aprovador, você pode ver as aprovações pendentes no relatório Controle de acesso ➔ Minhas aprovações.

Para listar todas as aprovações registradas, vá para o relatório Controle de acesso ➔ Solicitações.

Dashboards

Através do menu Dashboard ➔ PAM ➔ Remote sessions, você verá o uso das tecnologias de proxy.

Dashboard de sessões remotas

O dashboard Saved exibe alguns números sobre como o consumo de disco está funcionando, com base nas sessões salvas. Além de quantas horas de sessão já foram auditadas.

Dashboard das sessões gravadas

O Dashboard Disk space exibe o consumo de disco em uma visualização gráfica. Estes números podem ser monitorados sob SNMP.

Dashboard do espaço em disco

Para obter uma visualização simultânea do consumo de recursos, consulte os painéis disponíveis no menu System consumption. O painel abaixo mostra o consumo simultâneo de sessões de proxy.

Dashboard de sessão simultânea

Solicitação de auditoria

As sessões apresentadas no menu PAM ➔ Access Control ➔ Remote Sessions podem ser bloqueadas para expurgo e encaminhadas para auditoria. Nesse cenário, os usuários auditores poderão ter acesso apenas as sessões do qual foram vinculados. Podem assistir o vídeo de sessão e interagir através de comentários as decisões tomadas.

  1. No relatório de sessão, clique em Prevent purge para abrir o formulário de justificativa. Essa ação já irá impedir que o senhasegura expurgue a sessão;

    Menus de ação no relatório de sessões
  2. Configure os auditores na ação Configure auditors. Estes usuários receberão um email informando que uma nova sessão foi encaminhada para auditoria;

    Registro de auditores
  3. Como auditor, através do menu PAM ➔ Access Control ➔ Session for Audit o auditor tem acesso as sessões que estão sob sua responsabilidade de auditoria;

    Relatório de sessões para auditar
  4. Através da ação Comment session você poderá adicionar observações que serão vinculadas a sessão;

    Registro motivador da solicitação de auditoria
    Registro de observação do auditor
  5. Através da ação Session audit o auditor determina um veredito ao seu trabalho;

    Veredito de auditores

Comandos auditados

caution

A funcionalidade do filtro de comando não está disponível para RDP Proxy por razões de segurança. Para usá-lo, confira nosso conteúdo sobre Filtragem de comando de RDP para PowerShell e CMD no manual senhasegura.go .

Nas sessões SSH é possível identificar comandos digitados pelo usuário que devem ser executados no dispositivo alvo.

Estes comandos podem ser avaliados usando padrões de expressão regulares definidos pelo próprio administrador, e se eles se ajustam ao padrão, uma ação pode ser tomada.

Desta forma, você pode criar vários tipos de configurações que permitem ou inibem a execução de certos comandos. Mas é necessário que a pessoa que configura os comandos tenha um bom conhecimento das expressões regulares para que os comandos possam ser avaliados corretamente.

Vamos entender que tipo de ações um comando pode desencadear, como as sessões são afetadas por essas ações e qual é a diferença de uma sessão com e sem comandos auditados.

Sessões SSH com e sem comandos auditados

As sessões que não tiverem comandos auditados começarão diretamente no dispositivo alvo da mesma forma que o usuário se conecta ao dispositivo sem usar senhasegura . Assim, o terminal configurado na conta do usuário alvo será alocado para uma sessão TTY, e todas as combinações de teclas digitadas serão imediatamente encaminhadas para o dispositivo alvo.

Quando os comandos auditados são configurados, devemos ter cuidado para que os comandos digitados no terminal sejam avaliados antes de permitir a execução. Isto seria muito mais complexo atuando diretamente sobre o terminal natural do dispositivo remoto. E seria muito mais intrusivo se houvesse a necessidade de instalar agentes em todos os dispositivos alvo.

Neste cenário, a senhasegura oferece um terminal intermediário que funciona internamente com tecnologias de proxy SSH. Este terminal intermediário avalia o comando em tempo de execução e determina com base nas regras ativas se ele pode ou não ser roteado para o dispositivo remoto.

Mas se o cliente tiver iniciado um binário no servidor de destino, este binário será então entregue ao controle do operador do usuário. E, neste caso, os comandos auditados não são mais avaliados. Isto permite que não haja conflito entre os comandos terminais e os textos e argumentos usados em outros binários.

Ações acionadas pela execução de comandos auditados

Quando uma regra de comando auditada é aplicável a uma linha de comando que o operador usuário deseja executar, o senhasegura registrará o tempo da sessão de proxy quando esta acontecer, e somará a pontuação do risco deste comando executado na sessão. Esta notificação também será enviada sob SIEM.

Além disso, serão aplicadas as regras definidas pelo administrador. Há quatro ações diretas e uma ação indireta que podem ser realizadas.

  • Permitir a execução: A execução será permitida;

  • Bloquear a execução: O usuário operador será impedido de executar o comando. Estes comandos são considerados uma lista de negação;

  • Interromper: O usuário operador será impedido de executar o comando e terá a sessão de proxy interrompida. Estes comandos são considerados uma lista de negação;

  • Obrigar: O usuário só poderá executar os comandos permitidos por estas regras. Estes comandos são considerados uma lista obrigatória;

As regras serão resumidas. Isto significa que o administrador pode registrar tantas regras quantas achar conveniente. Mas quando a sessão começar, o senhasegura validará inicialmente as regras consideradas obrigatórias, depois as regras da lista de negação e, finalmente, as regras de registro. Se o comando for aplicável em uma das regras avaliadas, a cadeia de verificação é encerrada.

As regras da lista obrigatória acabam se sobrepondo completamente às demais, uma vez que sempre se aplicarão.

As regras serão sempre avaliadas dentro de seus grupos. Se houver mais de uma regra da lista obrigatória aplicável à sessão, ambas serão avaliadas. Portanto, o comando pode não ser permitido por uma primeira regra, mas pode ser válido pela segunda regra. O comando só será negado se nenhuma regra da lista obrigatória permitir o comando.

Estas regras de lista de negação e de lista obrigatória são as ações diretas. Há também as ações indiretas que podem ser configuradas.

  • Bloquear conta do senhasegura: Se a regra for aplicável, independentemente do tipo, a conta de acesso do usuário pode ser bloqueada após uma série de repetições do comando;

  • Pontuação no User Behavior: O comando pode receber três tipos de pontuação que irão alimentar o usuário, dispositivo e estatísticas comportamentais credenciais;

Registro de novos comandos

Através do menu PAM ➔ Configurações ➔ Acesso ➔ Comandos auditados você tem acesso ao relatório onde todos os comandos aplicáveis estão relacionados.

Como outras configurações de sessão proxy, os comandos auditados permitem segregações no nível Global, Grupo de acesso, Dispositivo, e Credencial.

A diferença é que não haverá sobreposição de um comando baseado na cadeia de entidades segregadoras. É uma soma de regras.

Veja esta segregação como uma possibilidade de isolar comandos pertencentes a certas credenciais e dispositivos de um determinado fabricante.

Relatório de comandos auditados

Um comando pode ser alterado desde que não tenha sido vinculado a uma sessão proxy. Mas ele pode ser inativado.

Formulário de comando global
  • Dentro do formulário de edição você tem o campo Criticidade e Score para determinar a pontuação no User Behavior.

  • Os campos Ocorrências e Bloquear usuário? determinam se o usuário terá sua conta senhasegura bloqueada.

  • O campo Ação durante a sessão são as principais ações que serão tomadas.

  • O campoComando é a expressão regular que será aplicada ao comando a ser executado.

  • Se você precisar criar um comando semelhante a um comando já existente, incluindo entidades já ligadas (como dispositivo, credencial ou grupo de acesso), você utiliza a ação de rodapé Clone comando no formulário de edição de um comando existente.

Vejamos agora como um comando reage quando é enquadrado a uma regra.

O comando Global abaixo permite executar comandos que contêm alguns binários mapeados.

Exemplo de comando global

Note que, quando executados, os comandos são executados normalmente. Mas primeiro eles serão registrados no senhasegura .

Comandos globais executados em terminal

Agora veremos uma regra que nega a execução de comandos. A regra abaixo nega a execução de comandos que interferem com os serviços em alguns dispositivos.

Exemplo de comando de dispositivo

Note que quando executado em um dispositivo relacionado, o comando irá parar e a tentativa será registrada.

Comandos de dispositivos executados em terminal

Os comandos da allowlist branca comportam-se de forma semelhante, mas não há notificação se algo fora da whitelist for bloqueado.

Exemplo de comando credencial
Comandos de credenciais executados em terminal

Em casos de interrupção de sessão, há uma etapa adicional para o logout obrigatório da sessão.

Exemplo de interrupção de sessão
Interrupção da sessão no terminal

Registros e Execuções de Comando

Assim que os comandos são combinados com uma regra de comando auditada, tanto a sessão quanto a regra estão agora vinculadas.

Através do relatório de comandos auditados, você pode observar cada vez que a regra foi aplicada através da ação de registro Ver histórico de auditoria.

Relatório de registro de eventos

Os registros de sessão também exibem os detalhes desta execução, quais comandos auditados são combinados, sua pontuação aplicada e o momento da execução.

Os logs das sessões podem ser acessados no relatório PAM ➔ Controle de acesso ➔ Sessões remotas.

Detalhes de comando auditados

Comandos auditados e comportamento do usuário

O módulo User behavior ligará várias informações relacionadas ao uso de recursos no senhasegura . Mas para os comandos auditados, temos telas especiais que trazem uma visão de como os usuários estão operando os sistemas.

Isto ajuda o administrador a entender se os procedimentos precisam ser ajustados, se os usuários precisam de treinamento e se as credenciais e os dispositivos estão em risco.

Através do relatório Comportamento ➔ Ocorrências você terá acesso a relatórios que fornecem uma visão de quais Dispositivos, Credenciais e Usuários estão fora da curva de utilização programada.

Você pode obter uma visão gráfica das execuções de comando arriscadas envolvidas através do Dashboard Radar de ameaças. Acessível no menu Dashboard ➔ PAM ➔ Radar.

Radar de ameaças

Este radar exibe as sessões em execução e que têm algum comando auditado registrado. Se você clicar no botão Histórico, localizado no canto superior direito do painel, você terá acesso ao histórico de execução dos últimos quatro dias. Você pode mudar o período através do filtro superior do painel de instrumentos, mas vamos explicar o radar.

O radar mostra vários pontos coloridos. As cores quentes apresentam sessões que tiveram comandos de risco executados. E as cores frias não têm comandos de risco.

Ao clicar no ponto, você tem detalhes sobre as sessões que ocorreram naquele momento. E quando você clica na ação de registro da sessão, ela exibirá um cartão com os detalhes da sessão.

Os eixos deste radar sempre mostram o intervalo aplicado no filtro dividido em quatro quadrantes. A proximidade do epicentro, bandeira de que a sessão ocorreu perto da hora inteira, e a proximidade da área periférica, bandeira de que a sessão ocorreu nos últimos minutos da hora.

A colocação na bandeira da rosa do vento indica a data (ou hora) em que o comando ocorreu.

Observe a imagem de exemplo de que os comandos foram quase todos executados em sessões de 11 dias entre 0 e 4 horas.

Através do menu Dashboard ➔ PAM ➔ Comandos, você tem acesso a um painel de controle dedicado aos comandos.

Painel de análise de comando

Os comandos também serão apresentados em um ranking geral que permite mapear os acessos mais arriscados e quem são os usuários e dispositivos mais afetados.

Download em PDF das páginas de sessões HTTPS

Após cadastrar uma sessão VNCHTTP é possível fazer download em PDF de um print da página a qual se esta acessando através do navegador.

Para isso, acesse a página que deseja fazer o download e clique com o botão direito do mouse e escolha a opção Save as PDF.

Em seguida escolha o local onde o arquivo deverá ser salvo e o seu nome. Um banner de conclusão de download será exibido no canto inferior da tela.

info

Você poderá abrir o arquivo PDF através do link de atalho no banner ou acessando a pasta onde foi determinado que seja salvo.

Conclusão

Ao finalizar esse livro você terá adquirido conhecimento para realizar as atividades relacionadas proxies senhasegura .

Se deseja continuar aprendendo como utilizar o senhasegura da melhor forma possível solicite ao nosso time de suporte nossa documentação disponível de acordo com o seu perfil e necessidade.