A maioria das empresas possui uma forte segurança externa, por exemplo, bloqueando todo o acesso aos ativos de produção usando um firewall e exigindo uma VPN para obter acesso “interno” aos ambientes de produção. No entanto, uma vez conectado à VPN, os sistemas internos geralmente ficam muito mal protegidos e há pouca ou nenhuma autenticação e autorização para ferramentas e serviços internos.
Duas ameaças comuns à segurança interna são laptops de funcionários comprometidos e ataques à cadeia de abastecimento. Nestes cenários, o invasor opera atrás do firewall, muitas vezes com acesso irrestrito à rede.
Os serviços com uma interface net podem ser protegidos usando um balanceador de carga de aplicativo, por exemplo, um AWS ALB com OIDCmas como você protege o acesso a ferramentas baseadas em interface de linha de comando (CLI)? Exigir um nome de usuário e senha para cada invocação da CLI torna o uso difícil e o armazenamento das credenciais no sistema as deixa abertas caso o computador em que residem seja comprometido.
A linha de comando
A maioria das ferramentas internas possui uma CLI para gerenciar os serviços utilizados na empresa e muitas estão mal protegidas. Qual é a melhor maneira de autorizar CLIs? E como você pode vincular a autorização ao SSO da empresa?
Uma opção é implantar o Hashicorp Vault, mas isso exige muita configuração e manutenção; portanto, a menos que você tenha uma equipe para operá-lo, o Vault pode não ser uma boa opção.
Outra opção é a concessão de autorização de dispositivo OAuth2 (RFC8628), que é o que esta postagem do weblog mostrará como usar.
A concessão de autorização de dispositivo OAuth 2.0 foi projetada para dispositivos conectados à Web que não possuem um navegador para executar uma autorização baseada em agente do usuário ou que têm entrada restrita a ponto de exigir que o usuário insira texto para se autenticar durante o fluxo de autorização. impraticável. Ele permite que clientes OAuth em tais dispositivos (como sensible TVs, consoles de mídia, porta-retratos digitais e impressoras) obtenham autorização do usuário para acessar recursos protegidos usando um agente de usuário em um dispositivo separado.
Se você já usou o AWS CLI com Single SignOn, é isso que ele faz.
Fluxo do dispositivo OAuth2
O fluxo de autorização de dispositivos contém dois caminhos diferentes; um ocorre no dispositivo que solicita autorização (CLI) e o outro ocorre em um navegador. O caminho de fluxo do navegador, em que um código de dispositivo está vinculado à sessão no navegador, ocorre como uma parte do caminho paralelo no caminho de fluxo do dispositivo.
Implementando o fluxo de dispositivo OAuth
Agora veremos como fica o diagrama de sequência acima quando implementado.
A ferramenta CLI interna da Rockset é chamada rsctl e está escrito em go. A primeira etapa é iniciar o fluxo do dispositivo para obter um token de acesso JWT.
$ rsctl login
Making an attempt to robotically open the SSO authorization web page in your default browser.
If the browser doesn't open otherwise you want to use a distinct gadget to authorize this request, open the next URL:
https://rockset.auth0.com/activate?user_code=BBLF-JCWB
Then enter the code:
BBLF-JCWB
Efficiently logged in!
Se você estiver usando a CLI depois de fazer login em outro computador, por exemplo, ssh:ing em um servidor Linux, e usar o macOS, poderá configurar Termo para abrir automaticamente o hyperlink usando um “comando Executar” acionar.
A página para a qual o hyperlink leva você é semelhante a esta:
Depois de confirmar que o “código de usuário” está correto (corresponde ao que a CLI mostra) e clicar em “Confirmar”, você será conduzido pelo procedimento regular de login do OAuth2 (que no nosso caso requer um nome de usuário, senha e {hardware} ficha).
Assim que a autenticação for concluída, você será redirecionado e verá uma caixa de diálogo como a abaixo, e poderá fechar a janela do navegador.
A CLI recebeu agora um token de acesso jwt que é válido por várias horas e é usado para autenticação por meio de serviços internos. O token pode ser armazenado em cache no disco e reutilizado entre invocações CLI durante sua vida útil.
Quando você emite um novo rsctl comando, ele lerá o token de acesso armazenado em cache do disco e o usará para autenticar com as APIs internas.
Sob o capô
Implementamos e abrimos o código-fonte de um módulo go para realizar o fluxo de autorização do dispositivo (github.com/rockset/device-authorization). Ele oferece suporte a Auth0 e Okta como provedores OAuth.
Código de amostra
O seguinte código está disponível no diretório de exemplo no repositório git.
Conteúdo incorporado: https://gist.github.com/pmenglund/5ed2708cdb88b6a6982258aed59a0899
Agora temos um token JWT, que pode ser usado para autenticar chamadas REST definindo o cabeçalho Authorization como Bearer:
Conteúdo incorporado: https://gist.github.com/pmenglund/b2ac7bb15ce25755a69573f5a063cb14
Cabe agora ao receptor validar o token ao portador, o que pode ser feito usando um AWS ALB com autenticação OIDC ou um API específica do provedor do servidor API.
Validação off-line
Outra opção para validação de token de acesso é a “validação offline”. Na validação offline, o servidor API obtém a chave pública usada para assinar o token JWT do provedor (e armazena em cache a chave pública) e realiza a validação no servidor API, em vez de fazer uma solicitação de validação ao provedor.
Risco Residual
Uma coisa contra a qual isso não protege é um invasor com posição segura no computador que executa a CLI. Eles podem apenas esperar até que o usuário conclua a autenticação e então poderão atuar como usuário durante o token de acesso.
Para mitigar esse risco, você pode exigir uma senha de uso único (OTP), por exemplo, um Yubikey, sempre que o usuário executar uma ação privilegiada.
$ rsctl delete useful resource foobar
please enter yubikey OTP: ccccccvfbbcddjtuehgnfrbtublkuufbgeebklrubkhf
useful resource foobar deleted
Considerações finais
Neste weblog, mostramos como construímos e abrimos o código-fonte de um módulo go para proteger a interface de linha de comando (CLI) usando um fluxo de autorização de dispositivo OAuth2 que suporta provedores de SSO Auth0 e Okta. Você pode adicionar este módulo go às suas ferramentas internas e reduzir as ameaças à segurança interna.