La plupart des entreprises disposent d’une sécurité externe solide, par exemple en bloquant tout accès aux actifs de production à l’aide d’un pare-feu et en exigeant un VPN pour obtenir un accès « interne » aux environnements de production. Cependant, une fois connecté au VPN, les systèmes internes sont généralement très mal protégés et il y a peu ou pas d’authentification et d’autorisation pour les outils et services internes.
Deux menaces courantes pour la sécurité interne sont les ordinateurs portables des employés compromis et attaques de la chaîne d’approvisionnement. Dans ces scénarios, l’attaquant opère derrière le pare-feu, souvent avec un accès réseau illimité.
Les services dotés d’une interface utilisateur Web peuvent être sécurisés à l’aide d’un équilibreur de charge d’application, par exemple un AWS ALB avec OIDC, mais comment protégez-vous l’accès aux outils basés sur l’interface de ligne de commande (CLI) ? Exiger un nom d’utilisateur et un mot de passe pour chaque appel CLI rend difficile l’utilisation et le stockage des informations d’identification sur le système les laisse grandes ouvertes au cas où l’ordinateur sur lequel ils résident serait compromis.
La ligne de commande
La plupart des outils internes disposent d’une CLI pour gérer les services utilisés au sein de l’entreprise et beaucoup sont mal protégés. Quelle est la meilleure façon d’autoriser les CLI ? Et comment pouvez-vous lier l’autorisation au SSO de l’entreprise ?
Une option consiste à déployer Hashicorp Vault, mais cela demande beaucoup de configuration et de maintenance, donc à moins que vous n’ayez une équipe pour l’exploiter, Vault pourrait ne pas être une bonne solution.
Une autre option est l’octroi d’autorisation de périphérique OAuth2 (RFC8628), c’est ce que cet article de blog vous montrera comment utiliser.
L’octroi d’autorisation d’appareil OAuth 2.0 est conçu pour les appareils connectés à Internet qui ne disposent pas d’un navigateur pour effectuer une autorisation basée sur un agent utilisateur ou dont la saisie est limitée dans la mesure où il est nécessaire de demander à l’utilisateur de saisir du texte afin de s’authentifier pendant le flux d’autorisation. pas pratique. Il permet aux clients OAuth sur de tels appareils (tels que les téléviseurs intelligents, les consoles multimédias, les cadres photo numériques et les imprimantes) d’obtenir l’autorisation de l’utilisateur pour accéder aux ressources protégées en utilisant un agent utilisateur sur un appareil distinct.
Si vous avez déjà utilisé l’AWS CLI avec Single SignOn, voici ce qu’elle fait.
Flux de périphérique OAuth2
Le flux d’autorisation de périphérique contient deux chemins différents : l’un se produit sur l’appareil demandant l’autorisation (la CLI) et l’autre se produit dans un navigateur. Le chemin de flux de navigateur, dans lequel un code de dispositif est lié à la session dans le navigateur, apparaît comme une partie de chemin parallèle dans le chemin de flux de dispositif.
Implémentation du flux de périphériques OAuth
Nous allons maintenant voir à quoi ressemble le diagramme de séquence ci-dessus lorsqu’il est implémenté.
L’outil CLI interne de Rockset s’appelle rsctl et est écrit en go. La première étape consiste à lancer le flux de périphérique pour obtenir un jeton d’accès JWT.
$ rsctl login
Attempting to automatically open the SSO authorization page in your default browser.
If the browser does not open or you wish to use a different device to authorize this request, open the following URL:
https://rockset.auth0.com/activate?user_code=BBLF-JCWB
Then enter the code:
BBLF-JCWB
Successfully logged in!
Si vous utilisez la CLI après vous être connecté à un autre ordinateur, par exemple en ssh:ing sur un serveur Linux, et que vous utilisez macOS, vous pouvez configurer iTerm pour ouvrir automatiquement le lien à l’aide d’un « Exécuter la commande » déclenchement.
La page vers laquelle le lien vous amène ressemble à ceci :
Une fois que vous avez confirmé que le « code utilisateur » est correct (correspond à ce que montre la CLI) et que vous cliquez sur « Confirmer », cela vous mènera à travers la procédure de connexion OAuth2 normale (qui dans notre cas nécessite un nom d’utilisateur, un mot de passe et un matériel). jeton).
Une fois l’authentification terminée, vous serez redirigé et présenté avec une boîte de dialogue comme celle ci-dessous, et vous pourrez fermer la fenêtre du navigateur.
La CLI a maintenant reçu un jeton d’accès jwt qui est valable plusieurs heures et permet de s’authentifier via les services internes. Le jeton peut être mis en cache sur le disque et réutilisé entre les invocations CLI pendant toute sa durée de vie.
Lorsque vous émettez un nouveau rsctl commande, il lira le jeton d’accès mis en cache à partir du disque et l’utilisera pour s’authentifier auprès des API internes.
Sous la capuche
Nous avons implémenté et open source un module go pour effectuer le flux d’autorisation des appareils (github.com/rockset/device-authorization). Il prend en charge Auth0 et Okta en tant que fournisseurs OAuth.
Exemple de code
Le code suivant est disponible dans le exemple de répertoire dans le dépôt git.
Contenu intégré : https://gist.github.com/pmenglund/5ed2708cdb88b6a6982258aed59a0899
Nous disposons désormais d’un jeton JWT, qui peut être utilisé pour authentifier les appels REST en définissant l’en-tête Authorization sur Bearer: <jwt access token>
Contenu intégré : https://gist.github.com/pmenglund/b2ac7bb15ce25755a69573f5a063cb14
C’est maintenant au destinataire de valider le jeton du porteur, ce qui peut être fait à l’aide d’un AWS ALB avec authentification OIDC ou un API spécifique au fournisseur depuis le serveur API.
Validation hors ligne
Une autre option pour la validation des jetons d’accès est la « validation hors ligne ». Lors de la validation hors ligne, le serveur API obtient la clé publique utilisée pour signer le jeton JWT auprès du fournisseur (et met en cache la clé publique) et effectue la validation dans le serveur API, au lieu de faire une demande de validation au fournisseur.
Risque résiduel
Une chose contre laquelle cela ne protège pas est un attaquant ayant un pied sur l’ordinateur qui exécute la CLI. Ils peuvent simplement attendre que l’utilisateur ait terminé l’authentification, et ils pourront alors agir en tant qu’utilisateur pendant la durée du jeton d’accès.
Pour atténuer ce risque, vous pouvez exiger un mot de passe à usage unique (OTP), par exemple une Yubikey, chaque fois que l’utilisateur effectue une action privilégiée.
$ rsctl delete resource foobar
please enter yubikey OTP: ccccccvfbbcddjtuehgnfrbtublkuufbgeebklrubkhf
resource foobar deleted
Pensées finales
Dans ce blog, nous avons montré comment nous avons construit et open source un module go pour sécuriser l’interface de ligne de commande (CLI) à l’aide d’un flux d’autorisation de périphérique OAuth2 qui prend en charge les fournisseurs Auth0 et Okta SSO. Vous pouvez ajouter ce module go à vos outils internes et réduire les menaces de sécurité internes.
