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 - Informações úteis que podem tornar o uso da solução mais dinâmico.
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.
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 .
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.
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.
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.
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
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.
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:
Parâmetros globais
Parâmetro segregado de grupos de acesso
Parâmetros segregados de dispositivos
Parâmetros segregados de credenciais
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.
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.
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.
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.
O exemplo da segregação de faixas manteve todos os outros parâmetros inalterados. Apenas o banner foi definido.
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.
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>.
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.
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
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.
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.
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.
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.
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.
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@valtServerAcessando a instância;ssh key keyValue@targetDeviceAcessando outro dispositivo;ssh key\keyValue@targetDeviceAcessando outro dispositivo ou quando uma chave e credencial possuírem o mesmo nome.
2FA token de acesso
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.
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.
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@valtServerCadeia de conexão padrão somente com o usuário e o servidor senhasegura .valtUser[targetUser@targetServer]@valtServerConexã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@valtServerConexão multihop contendo a ficha OTP.
Exemplo de conexão Multihop contendo a ficha OTP
Transferência de arquivos
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.
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.
A imagem proxy-terminal-220 utiliza uma versão de linha de comando do SFTP.
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@vaultServerUpload de um arquivo para a instância senhasegura .scp vaultUser@vaultServer:fileName fileDestinationDownload de um arquivo da instância senhasegura para máquina solicitante.
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.
Se a elevação de privilégios for inativada na sessão, a senha de credencial do dispositivo é solicitada.
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.
E, se o administrador sair obrigatoriamente da sessão, o usuário também é avisado.
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.
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.
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.
Finalmente, configure a credencial com a macro RemoteApp para usar, e se necessário, forneça a credencial de acesso ao dispositivo.
Quando você faz o login usando o Terminal Proxy senhasegura, o pedido será apresentado imediatamente.
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.
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
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.
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.
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íniovaltUser[targetUser@device]Conexão contendo o usuário e o dispositivovaltUser[domain\targetUser@device]tokenConexão contendo o usuário, dispositivo e token de acesso
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®.
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.
E se o administrador encerrar compulsoriamente a sessão, o usuário também é avisado.
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.
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
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.
Seu uso será aplicado nos processos de workflow de acesso e acesso de emergência, se necessário.
sectionsenhasegura Web Proxy
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.
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.
Na guia conectividade, preencha a conectividade correta para o site que está sendo acessado.
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.
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.
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.
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.
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.
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.
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.
Para downloads, a usabilidade é ainda melhor. Você será perguntado se deseja fazer o download do arquivo. Escolha a opção Salvar arquivo e confirme.
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.
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.
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.
2FA token access
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 .
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.
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.
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:
O administrador localizará a sessão de destino no relatório Remote Session;
Clique na ação Compartilhamento de sessão;
No formulário de Compartilhamento de sessão, selecione quais usuários receberão uma sessão dedicada conectada à sessão de destino;
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.
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.
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.
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.
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.
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.
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.
O Dashboard Disk space exibe o consumo de disco em uma visualização gráfica. Estes números podem ser monitorados sob SNMP.
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.
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.
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 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 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 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 Através da ação Session audit o auditor determina um veredito ao seu trabalho;
Veredito de auditores
Comandos auditados
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.
Um comando pode ser alterado desde que não tenha sido vinculado a uma sessão proxy. Mas ele pode ser inativado.
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.
Note que, quando executados, os comandos são executados normalmente. Mas primeiro eles serão registrados no senhasegura .
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.
Note que quando executado em um dispositivo relacionado, o comando irá parar e a tentativa será registrada.
Os comandos da allowlist branca comportam-se de forma semelhante, mas não há notificação se algo fora da whitelist for bloqueado.
Em casos de interrupção de sessão, há uma etapa adicional para o logout obrigatório da sessão.
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.
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.
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.
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.
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.
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.