Registro SSH e gerenciamento de sessões usando o AWS SSM

Configurar ferramentas ou scripts personalizados para manter um log SSH no Linux pode ser tedioso e propenso a erros.

Os engenheiros podem usar rootsh , screen ou outro utilitário para registrar a atividade do usuário, mas se as permissões do usuário não estiverem definidas corretamente, um usuário qualificado poderá apagar os logs de auditoria para cobrir seus rastros. Outra opção seria configurar o log no nível do kernel, mas a experiência necessária para isso não é tão comum.

Felizmente, existe uma maneira de registrar a atividade do usuário sem escrever um único comando Linux! Vamos precisar destes serviços:

• EC2
• IAM (Gerenciamento de Identidade e Acesso)
• KMS (Serviço de Gerenciamento de Chaves)
• Logs do CloudWatch (e/ou S3)
• AWS Systems Manager (anteriormente conhecido como SSM)

Vamos ver como configurar cada um deles.

EC2 e IAM

A execução de uma instância do EC2 normalmente é bastante fácil, mas há uma tarefa importante que deve ser feita durante a execução: precisamos anexar uma função do IAM à nossa instância, caso contrário não conseguiremos obter os resultados esperados detalhados no final deste artigo.

A função do IAM que associamos à nossa instância do EC2 deve ter a política integrada AmazonSSMManagedInstanceCore , além desta política (anexada como inline ou gerenciada pelo cliente):

 { "Version": "2012-10-17", "Statement": [ { "Action": [ "logs:CreateLogStream", "logs:DescribeLogStreams", "logs:DescribeLogGroups", "logs:PutLogEvents" ], "Effect": "Allow", "Resource": "*" } ] }

Além da função do IAM, geralmente usamos esta configuração de instância do EC2:

• O sistema operacional é o Amazon Linux 2 porque, por padrão, ele vem com o AWS Systems Manager Agent (SSM Agent) instalado. (Assim como as distribuições do Ubuntu, que também são uma opção.)
• O tipo de instância é t3.micro (mas qualquer tipo serve).
• O grupo de segurança padrão que a AWS atribui à VPC funcionará, pois não precisamos de uma porta SSH aberta para este exercício.

Podemos começar a configurar o KMS sem esperar que a instância do EC2 seja inicializada.

KMS

Precisamos de uma chave KMS se quisermos que todos os logs de sessão entregues ao CloudWatch sejam armazenados criptografados. Vamos para o serviço KMS e criar uma chave.

Recomendamos atribuir um administrador para que a chave possa ser gerenciada por usuários que não sejam o usuário raiz da conta da AWS, mas se outros não precisarem de acesso, podemos pular a Etapa 3.

Aqui escolhemos o usuário do IAM “admin” como administrador de chave, mas somos livres para escolher qualquer usuário ou função. Também podemos optar por desabilitar a permissão de exclusão de chave para o administrador.

Não atribuiremos nenhum usuário a essa chave porque queremos que ela seja usada apenas pelo serviço CloudWatch Logs para operações de criptografia e descriptografia de log SSH.

Na página Revisão, precisaremos alterar a política de chave gerada pelo KMS porque ela não inclui permissões para o CloudWatch Logs usar a chave. Vamos substituí-la por esta política:

 { "Version": "2012-10-17", "Statement": [ { "Sid": "Enable IAM User Permissions", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT_ID:root" }, "Action": "kms:*", "Resource": "*" }, { "Sid": "Allow access for Key Administrators", "Effect": "Allow", "Principal": { "AWS": "arn:aws:iam::ACCOUNT_ID:user/USERNAME" }, "Action": [ "kms:Create*", "kms:Describe*", "kms:Enable*", "kms:List*", "kms:Put*", "kms:Update*", "kms:Revoke*", "kms:Disable*", "kms:Get*", "kms:Delete*", "kms:TagResource", "kms:UntagResource", "kms:ScheduleKeyDeletion", "kms:CancelKeyDeletion" ], "Resource": "*" }, { "Sid": "Allow access to CloudWatch Log", "Effect": "Allow", "Principal": { "Service": "logs.REGION.amazonaws.com" }, "Action": [ "kms:Encrypt", "kms:Decrypt", "kms:ReEncrypt*", "kms:GenerateDataKey*", "kms:DescribeKey" ], "Resource": "*", "Condition": { "ArnLike": { "kms:EncryptionContext:aws:logs:arn": "arn:aws:logs:REGION:ACCOUNT_ID:*" } } } ] }

Certifique-se de substituir todos os espaços reservados:

• ACCOUNT_ID se torna nosso ID de conta da AWS.
• USERNAME torna-se o nome de usuário do administrador selecionado na Etapa 3. Se optamos por não participar dessa etapa, removemos aqui o segundo bloco de instrução (aquele com "Sid": "Allow access for Key Administrators" ).
• REGION se torna o código identificador regional para o qual estamos implantando serviços (por exemplo, us-west-1 ).

Com isso, o KMS está pronto para ser usado.

Grupo de logs do CloudWatch

Em seguida, precisamos de um grupo do CloudWatch Log (e/ou um bucket do S3 — veja abaixo) onde o Agente SSM pode enviar logs de sessão SSH. Vamos criá-lo.

Observe o campo ARN da chave KMS: a AWS nos fornece o valor necessário aqui depois que a chave é criada na Etapa 5 da seção KMS.

(Se não associamos a política correta à nossa chave KMS anteriormente, permitindo que o serviço CloudWatch Logs use a chave, receberemos um erro relacionado à chave KMS neste momento.)

 { "Version": "2012-10-17", "Statement": [ { "Effect": "Allow", "Action": [ "s3:PutObject" ], "Resource": "arn:aws:s3:::BUCKET_NAME/*" }, { "Effect": "Allow", "Action": [ "s3:GetEncryptionConfiguration" ], "Resource": "*" }, { "Effect": "Allow", "Action": "kms:GenerateDataKey", "Resource": "*" } ] }

Agora que configuramos um lugar para armazenar os logs — CloudWatch Logs, um bucket do S3 ou ambos — estamos prontos para acessar as sessões SSH.

Gerenciador de sessões do AWS Systems Manager

Esta é a etapa chave final, onde configuramos o acesso seguro à nossa máquina Linux para monitoramento e registro de sessão SSH. Começaremos no painel do Session Manager.

No painel, clique no botão branco “Configurar preferências” no canto superior direito da caixa “Iniciar uma sessão” para habilitar o registro de sessão.

Na página Preferências, encontraremos várias seções que podemos explorar, mas nosso foco será o streaming de logs de sessão SSH para CloudWatch ou S3 para nos permitir ver rapidamente o que está acontecendo em nossa máquina Linux.

Logo após a seção “CloudWatch logging”, há uma seção “S3 logging” onde podemos selecionar o bucket.

Uma vez que o log SSH é configurado, podemos SSH em nossa máquina Linux e executar alguns comandos para ver se a atividade está sendo capturada ou não.

Então, vamos começar uma sessão. Na mesma página, encontraremos uma guia “Sessões” onde podemos iniciar uma sessão. Clicar no botão “Iniciar sessão” nos dará uma lista de máquinas EC2 nas quais podemos iniciar uma sessão:

Se não virmos nossa instância Linux do EC2 na lista, devemos verificar se ela está em um estado de execução e tem as permissões do IAM associadas a ela que descrevemos anteriormente.

Lidando com um erro de agente do SSM “não oferece suporte a logs de streaming”

Caso recebamos um erro informando que a versão do SSM Agent instalada em nossa máquina EC2 não é compatível com streaming de logs do CloudWatch, não se preocupe. Há uma maneira indolor de corrigir isso.

Para atualizar o SSM Agent, precisamos navegar até Run Command no painel esquerdo do serviço AWS Systems Manager .

Uma vez lá, podemos clicar no botão laranja “Executar um comando”, levando a uma nova página onde podemos preencher alguns parâmetros.

Começaremos selecionando AWS-UpdateSSMAgent na lista.

Uma vez selecionado, rolaremos para baixo até vermos a seção “Destinos”. Lá, precisamos selecionar a instância do EC2 na qual queremos atualizar o SSM Agent e, em seguida, clicar no botão "Executar" no final. Isso nos enviará para uma página onde podemos monitorar o progresso da atualização.

A atualização do agente não deve demorar mais de cinco minutos. Feito isso, devemos ser capazes de criar uma sessão de volta no Session Manager.

Neste ponto, devemos ter uma sessão SSH iniciada.

Depois de executar alguns comandos, vamos navegar até o grupo de logs do CloudWatch Logs (ou nosso bucket do S3, não mostrado) e confirmar se a atividade está sendo gravada.

Agora temos uma configuração, com criptografia em repouso habilitada, gravando todos os comandos disparados em nossa máquina Linux.

Na verdade, cada comando pode ser mais do que queremos: quaisquer segredos fornecidos ou gerados durante a sessão serão registrados no CloudWatch ou S3 e poderão ser vistos por qualquer pessoa que tenha as permissões necessárias. Para evitar isso, podemos usar stty -echo; read passwd; stty echo; stty -echo; read passwd; stty echo; para cada segredo que precisamos fornecer durante a sessão.

Uma ótima solução de log da AWS SSM/SSH com pequenas ressalvas

Session Manager é uma ferramenta útil para obter acesso remoto às nossas máquinas virtuais na AWS sem ter que abrir a porta 22. Na verdade, não podemos gerar logs SSH dessa forma se usarmos o encaminhamento de porta ou uma conexão SSH direta, como o Session Manager notas de documentação.

No entanto, combinar o Session Manager com o log de sessão é uma solução robusta para controlar e monitorar a atividade nas VMs. Além disso, não somos cobrados pelo uso do serviço Session Manager. Pagamos apenas por nossa instância do EC2 e CloudWatch Logs ou um bucket do S3 para armazenar logs.

Para os leitores que preferem tutoriais em vídeo, abordei um procedimento muito semelhante um pouco mais detalhadamente no YouTube.

Leitura adicional no Blog da Toptal Engineering:

• Estudo de caso: Por que uso a infraestrutura da Nuvem AWS para meus produtos