Clé publique : c'est la partie la plus simple, elle peut être presque n'importe où (URL connue, un type de magasin de fichiers comme S3 / GCS / ..., même contrôle de source). Le seul souci est de s'assurer qu'elle n'est pas modifiée, mais qu'elle peut être lue par n'importe qui.

Clé privée : c'est là que ça devient délicat. La clé privée doit être comme sûr que possible avec un accès aussi limité que possible.Si quelqu'un lit votre clé privée, il peut prétendre être votre service. Vous avez raison de dire qu'elle ne doit pas être dans le contrôle de code source.

Vous voudrez vous assurer que la clé privée est toujours chiffrée. Le problème est maintenant de savoir comment donner à votre service la phrase de passe pour décoder la clé. Le fichier chiffré lui-même peut se trouver dans un système de stockage cloud (S3, GCS, etc.). Certains contrôles d'accès sur le fichier chiffré sont toujours une bonne idée.

Quelques moyens d'accéder à la phrase de passe (certainement pas exhaustifs). Chacun a des avantages et des inconvénients. Lequel utiliser dépend beaucoup de votre environnement et de l'équilibre entre l'automatisation et la sécurité.

• variable d'environnement : de nombreux systèmes de déploiement vous permettent de spécifier des variables d'environnement d'une manière ce n'est pas facile à lire par quiconque sauf par les administrateurs du système. Cela peut ne pas être sûr selon l'environnement de production et qui a accès à la VM / au système d'orchestration.

• gérer le vôtre : utilisez votre propre infrastructure pour diffuser des secrets. Des éléments tels que keywhiz et Vault peuvent être très puissants, mais ce ne sont pas des systèmes simples à déployer et à gérer.

• cloud KMS : utilisez le système de gestion de clés spécifique au cloud (par exemple: Google / AWS KMS, Azure Vault, etc.). Ils ne peuvent généralement pas stocker un fichier, mais ils peuvent stocker une clé avec laquelle crypter un fichier. Les autorisations sur l'utilisation des clés doivent être très limitées, cela peut généralement être fait par compte de rôle et attribué uniquement à votre service.

• interaction humaine requise : exigez que quelqu'un se connecte manuellement au système et décrypte la clé privée à utiliser par le backend. L'inconvénient évident est qu'il n'y a pas d'automatisation, si votre VM tombe en panne, elle ne peut pas être redémarrée automatiquement.

Une option à ajouter à la réponse de Marc serait un module de sécurité matérielle (HSM). Ceux-ci sont chers et pas toujours pratiques (les fournisseurs de cloud peuvent proposer un stockage de clés basé sur HSM, mais vous ne pouvez pas simplement connecter votre propre HSM). Cependant, ils peuvent être plus sécurisés qu'un fichier clé. Le HSM n'a jamais besoin de divulguer la clé; au lieu de cela, lorsqu'un programme (votre serveur) souhaite utiliser la clé, il s'authentifie auprès du HSM (ce qui signifie que vous devrez peut-être encore fournir des informations d'identification au programme), puis transmet certaines données (telles que le corps JWT) au HSM et dit "Signez ceci, s'il vous plaît". Évidemment, tout autre programme fonctionnant sur le même matériel et pouvant usurper l'authentification de votre programme pourrait également signer des JWT (ou d'autres données) falsifiés, mais ils ne pouvaient pas s'enfuir avec la clé elle-même. Le HSM peut être physiquement supprimé, mais la sécurité physique est généralement plus facile que la sécurité logicielle.

Une option plus simple, disponible avec certains systèmes d'exploitation et / ou matériel, consiste à utiliser un module de sécurité logiciel hautement sécurisé (qui peut être soutenu par des fonctionnalités matérielles). Il existe divers exemples de telles choses, des implémentations purement logicielles (Windows en a une accessible via son API de cryptage par défaut, où votre clé est stockée dans un processus hautement privilégié auquel d'autres processus ne peuvent accéder que via des canaux authentifiés) aux options basées sur le matériel utilisant une «enclave sécurisée» ou similaire où un programme hautement fiable peut exécuter et stocker des données de telle sorte que même un système d'exploitation entièrement compromis ne peut pas, en théorie, en extraire des secrets.