Segurança da Informação

Pare os ataques SSH, eliminando as chaves SSH

Agora com mais de 20 anos, o SSH (Secure Shell) ainda é o método mais comum de acessar remotamente um servidor Linux, tornando seu uso um alvo comum para invasores que tentam se infiltrar em redes corporativas. Embora o protocolo em si tenha várias propriedades de segurança avançadas, ele permite erros humanos, abrindo as portas para acesso privilegiado não autorizado a recursos confidenciais da empresa.

Uma área comum de uso indevido é enviar uma chave privada para um repositório público de código fonte, ou em outro lugar, que pode ser facilmente obtida. Este é um conhecido vetor de ameaças há muito tempo, mas pesquisadores do Wordfence, um serviço de segurança do WordPress, notaram um recente aumento na atividade de varredura de SSH, descobrindo que os invasores estavam procurando por nomes de arquivos privados comuns como id_rsa com mais freqüência. Mesmo se a frase secreta for protegida, a obtenção de uma chave privada tornará bastante simples para alguém acessar máquinas com a chave pública associada.

Manter o controle de todas as credenciais válidas em uma empresa é algo com o qual os departamentos de TI lutam continuamente. As apostas são altas se caírem nas mãos erradas, essencialmente entregando as proverbiais ‘chaves do reino’, eu prefiro o termo chave mestra =). Outro ponto importante relata que um estudo recente da Dimensional Research descobriu que 90% dos entrevistados não têm um inventário completo e preciso de todas as chaves SSH, e 63% não ativam ativamente as chaves, mesmo quando um administrador deixa a empresa. Quantas vezes lemos sobre um ex-funcionário descontente que causou estragos em sistemas aos quais ainda tinha acesso? Eu te falo, mas em seguida tenho que te matar =) (Acho que já estou tomando muito café para escrever os artigos).

Gerenciar o acesso privilegiado aos servidores sempre foi um exercício rigoroso no gerenciamento de chaves. Há várias práticas recomendadas a serem seguidas para evitar as muitas armadilhas comuns, como armazenar chaves privadas em um serviço do cofre ou manter uma política rígida de rotação, mas elas não chegam ao ponto crucial – as credenciais são estáticas. Nós temos um pensamento (não tão) maluco – e se nos livramos completamente deles? Acreditamos que as credenciais estáticas são uma coisa do passado, representando o modelo de perímetro com falha da segurança corporativa.

Problemas com PKI hoje
A tradicional PKI (Infra-estrutura de Chave Pública) que apoia o SSH foi construída para um tempo diferente, em que uma troca de chaves significava o suficiente para garantir a confiança. O que funciona para Alice e Bob em teoria, nem sempre funciona na prática ou em escala, no entanto. O problema central está na falsa suposição de que a propriedade de uma chave privada equivale a um perfil de identidade. Embora possamos dizer “Chave privada de Alice”, não há um processo de autenticação associado que possa confirmar que foi Alice quem gerou o par de chaves, ou que Alice é a única pessoa que atualmente possui a chave privada.

Sem um processo de autenticação adequado, não há uma maneira clara de atribuir a uma pessoa, nem uma maneira viável de fornecer qualquer contexto histórico. À medida que essas chaves são emitidas e distribuídas em frotas de infraestrutura e serviços em nuvem, o desafio só se compõe. Cada chave pública acumula mais privilégios ao longo do tempo. Quanto mais tempo ela estiver ativa, maior a probabilidade de ela ser compartilhada com um recurso, o que dificulta muito o rastreamento e, posteriormente, a revogação. Com esse modelo, o tempo é um bug que não pode ser corrigido.

Autorizar uma solicitação específica também deve ir além da mera presença da chave pública no arquivo authorized_keys do servidor. Independentemente da autenticação, a autorização é sobre quem deve ou não acessar um servidor específico de um dispositivo conhecido e quais permissões eles têm na máquina. Você pode ter uma política que declara que apenas membros da equipe de engenharia podem acessar apenas um servidor de produção por meio de um bastion host. Aderir a essa política na prática, no entanto, é impossível sem um processo de autorização adequado.

Você tem processos atualizados ? Seja sincero! =)

Além de suas próprias políticas corporativas, os controles de conformidade, como os do PCI-DSS e ISO 27001, são rigorosos quanto aos controles de acesso e registros de auditoria. O que as empresas são obrigadas a fazer é implementar diretrizes rígidas sobre como gerar, proteger e usar chaves, ser extremamente diligente para não permitir que funcionários usem chaves compartilhadas, manter o arquivo authorized_keys em todos os servidores através de software de gerenciamento de configuração e manter uma lista de revogação potencialmente grande … e assim por diante. Existem ferramentas e produtos para ajudar nisso, mas novamente – tudo é construído com base no gerenciamento de credenciais estáticas.

Confie em um mundo de confiança zero
Chegamos a um consenso em toda a indústria de que o perímetro da rede está se desintegrando na era moderna da nuvem. Até mesmo os revendedores tradicionais de produtos de perímetro começam a aparecer, falando sobre a Zero Trust em seus materiais de marketing. É hora de dar mais um passo e concordar com um novo modelo de atestado de confiança a ser correspondido, em que as decisões são removidas da camada de rede e tratadas corretamente na camada do aplicativo. Invertendo o modelo desta forma significa começar com zero privilégios por padrão, e somente concedendo acesso a um recurso uma vez que uma requisição tenha sido totalmente autenticada e autorizada. Verifique, depois confie – o mantra de Zero Trust.

O BeyondCorp, do Google, é o exemplo perfeito do Zero Trust, uma iniciativa interna que visa proteger melhor como os funcionários acessam os recursos corporativos. O resultado final é um sistema distribuído cuidadosamente elaborado que toma decisões de confiança em tempo real com base no que é conhecido sobre um usuário e seu dispositivo, permitindo que milhares de Googlers em todo o mundo trabalhem com segurança em qualquer local sem o uso de uma VPN. A BeyondCorp é apenas um exemplo, e vimos mais e mais empresas começarem a adotar uma abordagem semelhante.

É importante entender algumas coisas sobre o Zero Trust para torná-lo uma realidade como o Google fez.

Primeiro, a autenticação e a autorização são dois processos claramente distintos, um fato comumente confundido. Nos termos mais simples, a autenticação é sobre quem você é e a autorização é sobre o que você pode fazer. Observe que a autorização depende da autenticação, mas toma uma decisão com base em fatores adicionais. Segundo, um atestado de confiança significativo refere-se à adesão a uma política que declara que uma pessoa (ou serviço) de um dispositivo conhecido pode acessar um recurso específico em um determinado momento. Não é necessariamente sobre a credencial em si, é sobre o contexto em torno da solicitação. Mesmo assim, ainda precisamos representar corretamente a identidade e as permissões associadas ao atestado que foi feito.

Certificados de cliente efêmero
Recursos efêmeros de computação tornaram-se a norma para ambientes nativos da nuvem – instâncias, contêineres e funções são acionados sob demanda, executados e, em seguida, interrompidos quando concluídos ou não são mais necessários. Apesar da automação que alimenta o ambiente, ainda é necessário que os administradores de sistemas recebam acesso privilegiado – em casos de emergência ou manutenção regular. É natural que as credenciais estáticas sejam um mecanismo deficiente para fazer o backup dos controles de acesso desses recursos dinâmicos.

O pensamento por trás das credenciais efêmeras é que uma solicitação aciona os processos de autenticação, em que um atestado de confiança é feito contra as políticas do recurso. Se válido, uma credencial de uso único é emitida, usada para iniciar uma sessão segura com o recurso. Essa credencial é rigidamente definida para a solicitação específica, inutilizada em qualquer outro cenário.

Os fundamentos desse fluxo de trabalho podem ser obtidos por meio de uma arquitetura de PKI baseada em certificado de cliente. Os certificados de cliente tornaram-se um recurso suportado do OpenSSH em 2011 com a introdução da versão 5.4. Ao contrário das chaves SSH padrão, que não carregam metadados, os certificados são objetos de metadados criptograficamente verificáveis ​​que podem injetar coisas como nomes de usuários, funções e muito mais. O tempo agora se torna um recurso porque o escopo da credencial realmente representa um atestado dinâmico de confiança.

Os controles de acesso refinados inerentes a uma arquitetura PKI baseada em certificado de cliente resolvem os problemas com chaves SSH porque a credencial pode ser vinculada a um usuário real. O vetor de ameaças de credenciais perdidas, roubadas ou mal utilizadas também é eliminado, economizando os gerentes das inúmeras dores de cabeça associadas ao gerenciamento de chaves SSH.