PAM Open Source na prática com JumpServer Community
Montei uma camada dedicada para intermediar acessos SSH e RDP, separar administração de operação, reduzir conexões diretas e registrar evidências das sessões privilegiadas.
Da segmentação de rede ao acesso SSH e RDP auditável em um portal único.
O problema que um PAM resolve
Controlar acesso administrativo não deveria depender de senhas compartilhadas, conexões SSH ou RDP abertas para qualquer origem e contas privilegiadas usadas sem histórico claro. Um PAM cria uma camada entre o usuário e o ativo: define quem pode entrar, qual conta pode ser utilizada, em qual servidor e por quanto tempo.
Neste laboratório, usei o JumpServer Community Edition para construir esse fluxo em uma estrutura pequena, mas realista. O objetivo não foi entregar uma arquitetura corporativa completa ou altamente disponível. Foi provar, na prática, o ciclo de segmentar, autorizar, acessar e auditar.
Conta certa
O usuário operacional não recebe a senha do ativo. Ele usa uma autorização criada dentro do PAM.
Caminho controlado
SSH e RDP passam pela plataforma, em vez de depender de uma conexão administrativa direta e dispersa.
Sessão rastreável
Usuário, ativo, conta, horário, gravação e comandos ficam disponíveis para auditoria.
Arquitetura do laboratório
Separei o ambiente em duas redes. A PAM-NET recebeu o servidor do JumpServer. A ASSETS-NET concentrou os ativos protegidos. O pfSense fez a segmentação entre essas redes e controlou o tráfego necessário para o laboratório.
| Componente | Função | Endereço |
|---|---|---|
| Host administrativo | Estação de administração do laboratório | 10.77.10.1 |
| pam-01 | Oracle Linux dedicado ao JumpServer | 10.77.10.10 |
| linux-01 | Ativo Linux protegido por SSH | 10.77.20.20 |
| win-01 | Ativo Windows protegido por RDP | 10.77.20.3 |
| pfSense | Gateway e segmentação entre as redes | 10.77.10.254 / 10.77.20.254 |
Preparando o servidor PAM
Preparei uma VM minimalista com Oracle Linux, sem interface gráfica e com o hostname pam-01. A máquina ficou dedicada à camada de acesso privilegiado, separada dos servidores que seriam protegidos.
Primeiro nó da camada administrativa.
Segmento dedicado ao JumpServer.
Endereço estável para regras e inventário.
Mantidos ativos desde a preparação.
Defini o endereço de rede manualmente para evitar alterações após reinicializações e simplificar as regras de firewall, o cadastro do ativo e a documentação do ambiente. Também mantive o SELinux em modo Enforcing e o firewalld ativo.
Registrando a linha de base do servidor
Antes de instalar qualquer componente, registrei hostname, endereçamento, DNS, recursos disponíveis e o estado das camadas básicas de proteção.
printf 'n== HOSTNAME ==n'; hostnamectl --static
printf 'n== REDE ==n'; ip -br addr; ip route
printf 'n== DNS ==n'; cat /etc/resolv.conf
printf 'n== RECURSOS ==n'; nproc; free -h; df -h /
printf 'n== SEGURANÇA ==n'; getenforce; systemctl is-active firewalldInstalação verificável do JumpServer
Em vez de executar um comando remoto sem revisar seu conteúdo, baixei o bootstrap oficial, restringi suas permissões e registrei um hash local. O objetivo foi ter visibilidade sobre o arquivo utilizado naquele momento no laboratório.
Baixando e revisando o bootstrap
mkdir -p /opt/jumpserver-install &&
cd /opt/jumpserver-install &&
curl -fL --proto '=https' --tlsv1.2
-o quick_start.sh
https://github.com/jumpserver/jumpserver/releases/latest/download/quick_start.sh &&
chmod 700 quick_start.sh &&
sha256sum quick_start.sh &&
nl -ba quick_start.shO script analisado funciona como bootstrap: verifica dependências, baixa um segundo pacote, extrai o instalador e chama o utilitário jmsctl.sh. Por isso, revisar apenas esse primeiro arquivo não descreve toda a cadeia de instalação.
Baixando o instalador principal e registrando o hash
Como eu optei por não executar o bootstrap diretamente, baixei o pacote principal de forma manual, registrei o SHA-256 e listei o conteúdo antes de extrair qualquer arquivo.
cd /opt &&
curl -fL --proto '=https' --tlsv1.2
-o jumpserver-installer-v4.10.16.tar.gz
https://github.com/jumpserver/installer/releases/download/v4.10.16/jumpserver-installer-v4.10.16.tar.gz &&
sha256sum jumpserver-installer-v4.10.16.tar.gz &&
tar -tzf jumpserver-installer-v4.10.16.tar.gz | sed -n '1,80p'f55e32c07f9e9139481d0511394bbe73160a5bfaa055efab40683c454e57c4d8b
O hash não substitui uma assinatura oficial publicada pelo fabricante. Ele registra exatamente qual arquivo foi usado no laboratório e ajuda a manter o procedimento reproduzível.
Extraindo e iniciando a implantação
Depois da revisão, extraí o instalador em /opt. A estrutura resultante inclui o jmsctl.sh, scripts de gerenciamento, arquivos de configuração e manifestos utilizados pelos containers.
cd /opt &&
tar -xzf jumpserver-installer-v4.10.16.tar.gz &&
cd /opt/jumpserver-installer-v4.10.16 &&
ls -lah
# Como o bootstrap não foi executado neste fluxo manual:
dnf -y install wget
./jmsctl.sh installDurante o assistente, mantive diretório persistente padrão em /data/jumpserver, PostgreSQL e Redis internos, portas padrão, idioma em inglês e fuso America/Sao_Paulo. Para este laboratório, essa escolha reduziu complexidade e foi suficiente para poucas conexões simultâneas.
cd /opt/jumpserver-installer-v4.10.16 && ./jmsctl.sh startSeparando administração e operação
Depois de concluir a instalação, mantive a conta administrativa apenas para configurar a plataforma: cadastrar ativos, armazenar contas de acesso e criar regras. Em paralelo, criei a conta operacional llucio sem privilégios administrativos.
A intenção foi simples: o administrador define a política; o usuário operacional utiliza somente os recursos já autorizados. O fato de uma conta conseguir entrar no JumpServer não deve significar que ela pode cadastrar um servidor, alterar uma regra ou navegar livremente pelos ativos.
Protegendo o acesso SSH ao Linux
Antes de cadastrar uma credencial no JumpServer, criei no linux-01 uma conta administrativa exclusiva para o PAM. Em vez de utilizar root como credencial operacional, usei pam-linux-admin e concedi privilégio administrativo pelo grupo wheel.
Criando uma conta administrativa nomeada
id pam-linux-admin >/dev/null 2>&1 || useradd -m -s /bin/bash pam-linux-admin
usermod -aG wheel pam-linux-admin
passwd pam-linux-admin
printf 'n== USUÁRIO ==n'
id pam-linux-admin
printf 'n== GRUPO WHEEL ==n'
getent group wheel
printf 'n== PRIVILÉGIOS SUDO ==n'
sudo -l -U pam-linux-adminEssa abordagem cria uma conta administrativa rastreável no servidor. O JumpServer passa a usar uma credencial nomeada, e não uma conta genérica de uso cotidiano.
Restringindo SSH para o caminho autorizado
Depois de validar a conexão inicial do pam-01 para o linux-01, removi a liberação genérica de SSH e mantive uma regra específica aceitando a porta 22 apenas a partir do IP do servidor PAM.
sudo firewall-cmd --permanent --zone=public
--add-rich-rule='rule family="ipv4" source address="10.77.10.10/32" service name="ssh" accept'
sudo firewall-cmd --permanent --zone=public --remove-service=ssh &&
sudo firewall-cmd --reload &&
sudo firewall-cmd --zone=public --list-all10.77.20.20:22 falhou por conta da segmentação entre redes.
firewalld do Linux.
Cadastro, autorização e acesso ao Linux
Com o ativo linux-01 e a conta pam-linux-admin cadastrados, testei a conexão SSH pela própria interface do JumpServer. A sessão foi aberta no navegador sem solicitar que o usuário digitasse a senha do servidor.
Validando identidade do ativo e da conta
hostnamectl --static
whoamiO resultado confirmou linux-01 e pam-linux-admin. A sessão também exibiu o ativo, a conta usada, o horário e a marca d’água associada ao usuário conectado.
Depois, criei uma regra de autorização específica para o usuário operacional llucio. A autorização vinculou um usuário, um ativo, uma conta e um protocolo:
lluciolinux-01 · 10.77.20.20pam-linux-adminPara respeitar o menor privilégio, deixei desabilitadas as funções de transferência de arquivos, clipboard e compartilhamento de sessão. A regra liberou apenas a conexão SSH necessária para o objetivo do laboratório.
Auditoria: sessões, reprodução e comandos
O acesso via PAM não termina quando a aba do navegador é fechada. O JumpServer registrou a sessão do usuário operacional com dados como usuário, ativo, conta, protocolo, horário de início e opções para reprodução e download.
Quem entrou?
Usuário, ativo, conta, protocolo, data e hora ficam associados à conexão realizada.
O que aconteceu?
A gravação ajuda a revisar o que ocorreu em uma sessão privilegiada sem depender apenas de memória ou relato.
Qual ação foi executada?
A trilha de comandos vincula ação, usuário, conta, ativo, sessão e horário.
Protegendo o acesso RDP ao Windows Server
Para complementar o cenário Linux, adicionei o win-01 ao laboratório. O ativo recebeu o endereço 10.77.20.3 e foi cadastrado no JumpServer utilizando a plataforma Windows-TLS.
No laboratório, esse perfil permitiu abrir a sessão RDP pelo navegador. A escolha não deve ser tratada como uma regra universal: em produção, o perfil precisa ser validado contra a configuração RDP, a política TLS e os requisitos do Windows que será gerenciado.
O fluxo foi o mesmo aplicado ao Linux: o usuário operacional recebeu uma autorização específica, visualizou somente o ativo liberado e abriu a sessão intermediada pelo JumpServer. O acesso RDP não foi tratado como exceção ao modelo de controle.
O que o laboratório validou — e o que ainda falta em produção
Ao final, o laboratório validou um caminho completo de acesso privilegiado com o JumpServer Community Edition:
sudo.pam-01.linux-01.win-01.O JumpServer complementa a arquitetura de segurança; ele não substitui os demais controles. Em produção, eu consideraria obrigatórios:
MFA e diretório corporativo
Integração com Active Directory, LDAP ou SSO; MFA obrigatório para usuários administrativos e operacionais.
Backups e monitoramento
Backup testado dos dados persistentes, envio de logs ao SIEM e revisão periódica de contas e permissões.
Acesso externo planejado
Quando necessário, publicar por uma arquitetura própria de VPN ou ZTNA, com identidade, MFA e regras restritivas. Não expor o portal administrativo diretamente na Internet.
Conclusão
O principal resultado deste laboratório não foi simplesmente abrir um SSH ou uma sessão RDP pelo navegador.
Foi transformar acessos privilegiados em atividades controladas, identificadas e auditáveis. O usuário operacional passou a ver apenas o que foi autorizado; a conta administrativa usada no servidor deixou de precisar ser revelada; e a plataforma passou a registrar evidências de como cada acesso aconteceu.
O PAM funciona melhor quando se torna parte do processo, não um atalho opcional.
Comece com poucos ativos críticos, contas nomeadas e regras simples. Depois evolua para MFA, aprovação, expiração de acesso, integração corporativa, rotação de credenciais e monitoramento contínuo.
