Partie 5 : Genèse de Ledger Recover – Sécurité opérationnelle | registre

Jusqu'à présent, nous avons montré dans les parties 1 et 2 comment Ledger Recover divise votre graine en actions ainsi que envoie ces partages en toute sécurité à amis fournisseurs de sauvegarde de confiance. Dans la troisième partie, nous avons montré comment stocke (et restaure) en toute sécurité les parts de votre graine, protégé par cryptage matériel, lié à votre identité et diversifié. Dans la partie 4, nous avons exploré comment Ledger Recover parvient à donner accès à votre sauvegarde à vous et à vous uniquement.

Il est maintenant temps d’examiner de plus près la manière dont nous garantissons une sécurité maximale au niveau opérationnel. En un coup d’œil, la sécurité opérationnelle est assurée par :

• Renforcer l'infrastructure qui sous-tend Ledger Recover,
• Appliquer la séparation des tâches aux différents opérateurs de Ledger Recover,
• Surveillance des composants et des opérations critiques,
• Mise en œuvre d'une réponse aux incidents spécifique à la récupération.

Examinons en détail la signification de chacun de ces éléments.

Durcissement des infrastructures

Le renforcement des infrastructures prend de nombreuses formes. Il s'agit d'un exercice à 360° qui implique un large éventail d'activités motivées par une analyse approfondie des risques de sécurité. Cela commence généralement par la tenue d'un catalogue de scénarios d'attaque pouvant entraîner des problèmes de sécurité (tels que des fuites de données, l'usurpation d'identité de clients conduisant à la restauration non autorisée de partages, des systèmes non réactifs et une interruption de service). La prévention de ces problèmes au niveau opérationnel s'organise autour d'activités telles que l'isolation des ressources, la régulation de l'accès au système, le contrôle du trafic réseau, la gestion des vulnérabilités et bien d'autres encore.

Voici un aperçu de nos mesures clés pour renforcer l'infrastructure de Ledger Recover :

Disponibilité du service

L'infrastructure est conçue de manière à ce qu'il y ait aucun point de défaillance unique (NSPOF), ce qui signifie que le système est résilient à la défaillance de n'importe quel composant. Prenons l'exemple suivant : nos centres de données sont desservis par deux fournisseurs d'accès Internet (FAI) indépendants, situés à deux extrémités opposées du bâtiment. Si la fibre est endommagée en raison de travaux de construction en cours dans une partie du bâtiment, les données seront simplement acheminées via l'autre FAI. Une maintenance sans interruption constitue un autre avantage qui améliore la disponibilité. Étant donné qu'il existe au moins deux instances de tous les composants logiciels de Ledger Recover, nous pouvons reconfigurer le système pour utiliser uniquement l'instance A tout en remplaçant/mettant à niveau/corrigeant l'instance B.

Accès administrateur limité aux applications Ledger Recover

Seule une un nombre réduit d'utilisateurs bénéficient d'un accès administrateur aux ressources dédiées à Ledger Recover. Plus la liste des utilisateurs est courte, plus nous pouvons réduire le risque que des menaces internes obtiennent un accès administrateur.

Centres de données physiques sécurisés

Les HSM des fournisseurs de sauvegarde sont hébergés dans géographiquement redondant centres de données physiques, protégés des menaces physiques et virtuelles grâce à techniques et procédures de sécurité de niveau industriel. Le niveau de protection physique garantit qu’aucune personne non autorisée ne peut repartir par hasard avec un HSM. S'appuyer sur des centres de données répartis sur plusieurs sites signifie que si un site rencontre un problème, un autre site peut prendre le relais, offrant ainsi disponibilité ininterrompue du service. Enfin et surtout, la gestion de nos propres HSM nous donne contrôle sur qui a accès pour eux et quel code est déployé sur eux.

Isolement des ressources de récupération du grand livre

Toutes les ressources Ledger Recover sont isolées de toute autre ressource au sein des fournisseurs de services de Ledger Recover, y compris au sein de Coincover et Ledger. Cet isolement est nécessaire pour garantir que nous pouvons contenir les attaques potentielles d'une tranche du réseau visant à exploiter les ressources d'autres tranches du réseau.

Sécurité au niveau du code assurée via plusieurs piliers

• Nous utilisons scanners de codes pour nous aider à identifier et à corriger les vulnérabilités dès le début, en les empêchant de se frayer un chemin vers la production.
• Code is examiné et approuvé by une équipe indépendante de celui qui développe Ledger Recover. Cette séparation est une autre mesure visant à améliorer la qualité globale du code en détectant les failles logiques susceptibles de poser des problèmes de sécurité.
• Le code du modules critiques de Ledger Recover est signé à l'aide d'une signature cryptographique. La signature est en partie générée en fonction du contenu du code, empêchant le déploiement de code falsifié en comparant la signature à sa valeur attendue. Ce contrôle de sécurité est effectué avant l'exécution du code.

Contrôle du trafic réseau

Le trafic réseau est étroitement contrôlé via des politiques qui définissent des règles pour les flux de trafic pour les 3 fournisseurs de sauvegarde. Par définir des règles pour le trafic autorisé et refusé, nous limitons la surface d’attaque et réduisons le risque d’accès non autorisés. De plus, restreindre la communication entre les services individuels garantit que le le mouvement latéral de l'attaquant est limité, même si un composant est compromis. De plus, nous appliquons l'authentification mutuelle TLS (mTLS) pour empêcher les attaques Man-in-the-Middle (MiM). En vérifiant l'identité des deux parties avec des certificats, TLS mutuel garantit que seules les entités de confiance peuvent établir une connexion sécurisée.

Rotation des clés

Chiffrement clés (utilisés, par exemple, pour chiffrer des données ou des communications) sont changé régulièrement conformément aux meilleures pratiques de cryptographie. L'avantage est que si une clé est compromise, le les dégâts sont limités au temps entre les rotations et aux données cryptées avec l'ancienne clé.

Sécurité du trafic sortant

Le trafic sortant est limité aux domaines et adresses IP connus uniquement (fournisseurs de sauvegarde, fournisseurs de services). Limiter et surveiller le trafic sortant est un moyen de restez attentif aux fuites de données potentielles. Si le volume des flux de données sortants est plus élevé que prévu, un acteur malveillant pourrait extraire des données sensibles du système Ledger Recover à une échelle significative. 

Sécurité du trafic entrant

Le trafic entrant est protégé par une combinaison de techniques anti-DDoS, de filtrage d'applications Web (WAF) et de filtrage IP. Les attaques par déni de service distribué (DDoS) causent des dommages en submergeant leur système cible de requêtes. Limiter le nombre de demandes entrantes est une mesure bien connue contre de telles attaques. Or, toutes les attaques ne concernent pas la quantité, certaines d’entre elles concernent la qualité. C'est là que WAF entre en jeu. WAF examine les demandes entrantes et inspecte leur comportement prévu: si la requête vise à obtenir un accès non autorisé ou à manipuler des données, le filtre bloque la requête. Enfin, le filtrage IP utilise la double technique de a) liste blanche, c'est-à-dire permettre trafic uniquement à partir d’adresses IP spécifiques ou plages, et b) liste noire, c'est-à-dire bloquer trafic provenant d'adresses IP d'attaquants connues.       

Gestion des vulnérabilités

Les composants de l’infrastructure Ledger Recover sont continuellement et systématiquement numérisée pour les vulnérabilités connues et les erreurs de configuration, et des correctifs/mises à jour sont appliqués régulièrement. Cela permet de répondre aux nouveaux types de menaces à mesure qu’elles émergent et de maintenir les mesures de sécurité à jour et de classe mondiale.

Séparation des tâches

La séparation des tâches est au cœur de la stratégie de sécurité de Ledger Recover. 

La séparation des tâches entre les différents Fournisseurs de sauvegarde (partie 3) et Fournisseur IDVs (partie 4) a été décrit dans les articles précédents. Vous vous souviendrez peut-être qu'il existe :

• 3 partages de Secret Recovery Phrase gérés par 3 fournisseurs de sauvegarde indépendants (avec diversification de la base de données en plus pour éviter la collusion)
• 2 validateurs d'identité indépendants (fournisseurs IDV)

Au niveau des infrastructures, séparation des tâches est appliqué entre les différents rôles impliqués dans le développement et l’exploitation de Ledger Recover.

De plus, nous combinons la séparation des tâches avec la principe du « moindre privilège ». Le « moindre privilège » est le principe appliqué aux opérateurs et administrateurs système : ils ont le droit de faire uniquement ce dont ils ont besoin, en veillant à ce qu'ils reçoivent le niveau d'autorisation le plus bas requis pour exercer leurs fonctions. 

Donc quand le « moindre privilège » est combiné avec la « séparation des tâches », divers rôles d'administrateur sont attribués à différentes personnes afin qu'aucune personne ne puisse endommager/compromettre la confidentialité ou l'intégrité d'un composant du système. Par exemple, les développeurs du code Ledger Recover n'ont pas accès au système qui exécute le code qu'ils ont écrit.

Gouvernance : Quorums

Semblable aux mécanismes de consensus des Blockchains qui garantissent l'intégrité et la sécurité en demandant à plusieurs acteurs de vérifier les blocs, nous avons adopté un quorum au sein du système Ledger Recover pour améliorer notre sécurité opérationnelle.

Malgré nos vérifications rigoureuses des antécédents de nos employés, il n’en demeure pas moins que les humains peuvent être un maillon faible dans n’importe quel système, et la cryptosphère ne fait pas exception. Des incidents de sécurité très médiatisés, tels que Piratage du mont Gox de 2014, démontrent comment des individus peuvent être exploités ou conduire à des failles de sécurité. Les gens peuvent être influencés ou contraints par diverses motivations – argent, idéologie, coercition, ego (alias MICE(S)) – ce qui rend même les vérifications d’antécédents les plus strictes pas entièrement infaillibles.

Pour atténuer ces risques, nous utilisons un système basé sur la notion de quorum. Ce cadre nécessite le consensus d'au moins trois personnes autorisées provenant de différentes équipes ou départements au sein des fournisseurs de sauvegarde avant que toute décision importante ou action critique puisse être prise. 

Le nombre exact de personnes impliquées dans nos différents collèges reste confidentiel pour des raisons de sécurité. Pourtant, sa simple existence améliore considérablement notre sécurité opérationnelle en diluant l’influence potentielle de tout individu compromis.

Voici quelques-unes des activités pour lesquelles nous utilisons des quorums :

1. Génération des clés privées pour les HSM Ledger Recover: Cette opération critique est sécurisée par des quorums indépendants au sein de chaque entité – Coincover, EscrowTech et Ledger. Chaque membre de ces quorums distincts doit être présent pour générer des clés privées dans leurs HSM respectifs. Chaque membre du quorum a accès à une clé de sauvegarde, ce qui est crucial pour restaurer et régénérer ses secrets HSM si nécessaire. Cette structure protège non seulement contre le risque qu'une personne ait une influence indue sur l'un des trois HSM du fournisseur de sauvegarde, mais améliore également l'intégrité globale du système, car chaque quorum fonctionne indépendamment et ignore les spécificités de chacun.

2. Décider d'une libération exceptionnelle de la part d'un client: Des situations particulières, quoique rares, peuvent nécessiter une libération exceptionnelle de la part d'un client. Cela peut être dû à des échecs de vérification d’identité (changement de nom, défiguration physique, etc.) ou au fait que nos mesures de sécurité non divulguées bloquent incorrectement un appareil sur une liste noire. Lorsqu’une telle situation se présente, un quorum composé de plusieurs personnes issues des fournisseurs de sauvegarde se réunit. Cette procédure, qui nécessite un large consensus, garantit que les décisions ne sont pas prises dans la précipitation ou de manière unilatérale, renforçant ainsi la sécurité des clients. Chaque membre du quorum utilise son appareil Ledger Nano (avec son propre code PIN) pour approuver la publication, ajoutant ainsi une couche de sécurité supplémentaire contre d'éventuelles collusions ou erreurs individuelles.

3. Signature de la mise à jour du code du micrologiciel HSM: Avant de déployer une nouvelle mise à jour du micrologiciel sur les HSM, notre équipe de sécurité des produits, le Ledger Donjon, mène un processus d'examen complet. Faisant partie du quorum du micrologiciel, le Ledger Donjon garantit qu'aucune porte dérobée ou code malveillant n'a été introduit par un interne malveillant ou un pipeline de développement compromis via une attaque de la chaîne d'approvisionnement. De cette façon, ils préservent l’intégrité et la sécurité de la mise à jour du firmware.

4. Mise à jour du code du micrologiciel des appareils Signing Ledger (Nano et Stax) : Tout comme le micrologiciel des HSM, les mises à jour du micrologiciel de notre appareil Ledger sont soumises à un processus d'examen strict et nécessitent l'approbation du quorum avant d'être proposées à nos utilisateurs via Ledger Live.

En conclusion, les quorums font partie intégrante de l'architecture de sécurité de Ledger Recover. Ils jouent un rôle important en renforçant les défenses contre les menaces internes malveillantes et la collusion lors d’opérations vitales. Tirant parti de la sécurité de premier ordre des appareils et services Ledger, les quorums contribuent à garantir la confiance et à protéger les actifs numériques des utilisateurs contre les initiés malveillants.

Surveillance des composants et des opérations critiques

Alors que nous approfondissons ce chapitre, il est important de noter que, pour des raisons de sécurité, nous ne divulguons qu'un sous-ensemble des activités de surveillance approfondies du service Ledger Recover. Tout en respectant notre engagement en faveur de la transparence, nous reconnaissons également l'importance de maintenir la discrétion sur les détails des contrôles internes et de la surveillance de la sécurité opérationnelle.

Chez Ledger, la sécurité est notre priorité. C'est au cœur de nos solutions, qui reposent sur des protocoles cryptographiques robustes, comme détaillé dans notre Livre blanc sur la récupération du grand livre. Mais notre travail se poursuit au-delà de la création de systèmes sécurisés. Nous surveillons et évaluons constamment nos opérations, à la recherche de toute activité suspecte. Cette vigilance continue renforce notre position en matière de sécurité, garantissant que nous sommes toujours prêts à réagir. 

Explorons quelques exemples de notre approche à plusieurs niveaux :

Activités de l'administrateur de surveillance : Nous appliquons un contrôle d'accès strict à nos administrateurs. Non seulement nous exigeons la 2FA (authentification à deux facteurs) pour toutes les connexions administratives à notre infrastructure, mais nous exigeons également une validation par plusieurs personnes pour l'accès de l'administrateur à l'infrastructure sur les parties critiques du système. De plus, nos systèmes enregistrent et suivent méticuleusement chaque activité administrative. Ces logs sont automatiquement croisés avec nos systèmes de ticketing internes pour détecter toute action imprévue. Cette corrélation prudente nous permet d'alerter rapidement nos équipes de sécurité de tout comportement inhabituel ou suspect, renforçant ainsi notre sécurité opérationnelle.

Contrôle croisé entre les fournisseurs de sauvegarde: La transparence et la responsabilité constituent la base des relations entre les fournisseurs de sauvegarde, Ledger, EscrowTech et Coincover. Nous avons établi un échange en temps réel de journaux utilisés pour la surveillance et la sécurité du système. Cela permet une vérification croisée des activités. Si une incohérence est détectée, le service est immédiatement verrouillé pour protéger les actifs des utilisateurs.

Supervision des activités de libération exceptionnelle: Les rares cas de libérations manuelles de partages sont méticuleusement contrôlés via un processus multi-quorum comme nous l'avons expliqué dans la section précédente. Après l'exécution de l'activité de libération exceptionnelle, les systèmes Ledger Recover procèdent à une surveillance complète, y compris une journalisation et une analyse détaillées des parties impliquées, de l'heure de fonctionnement et d'autres détails pertinents. Ce processus, impliquant à la fois l'exécution multi-quorum et le suivi post-action, garantit que la libération exceptionnelle d'actions est étroitement contrôlée à toutes les étapes du processus décisionnel.

Tirer parti de la gestion des informations et des événements de sécurité (SIEM): La solution SIEM constitue un élément crucial de la stratégie de surveillance du Ledger Recover. Ce SIEM dédié améliore la capacité à identifier et à répondre aux problèmes de sécurité potentiels en temps réel. Il est optimisé pour identifier une variété d'indicateurs de compromission (IoC) basés sur les journaux d'application du cluster et du Ledger Recover, grâce à des règles de détection spécifiques spécifiquement développées pour le service Ledger Recover. Si un IoC personnalisé est détecté, une réponse est automatique et immédiate : l'ensemble du cluster est verrouillé jusqu'à ce qu'une analyse approfondie soit effectuée. Dans le service Ledger Recover, la confidentialité est prioritaire sur la disponibilité du service pour garantir la plus grande protection des actifs des utilisateurs.

Dans le paysage dynamique de la cybersécurité, nous avons élaboré des stratégies et nous sommes préparés à divers scénarios. Notre modèle de menace prend en compte la situation peu probable dans laquelle plusieurs administrateurs d'infrastructure de différents fournisseurs de sauvegarde pourraient être compromis. Avec des mesures de protection rigoureuses et des réponses automatiques en place, le service Ledger Recover vise à garantir la sécurité continue des actifs des utilisateurs, même dans des circonstances aussi extraordinaires. Dans la section suivante, nous présenterons les mesures de réponse globales conçues pour faire face à de telles situations hypothétiques.

Réponse aux incidents spécifiques à la récupération du grand livre

Avec le service Ledger Recover, une stratégie de réponse aux incidents a été construite, conçue en collaboration avec les trois fournisseurs de sauvegarde. Un élément central de cette stratégie réside dans les protections automatiques qui verrouillent immédiatement l’ensemble du système dès qu’une activité suspecte est détectée dans n’importe quelle partie de l’infrastructure. 

Essentiellement, un protocole « toujours sécurisé, jamais désolé » a été intégré au service Ledger Recover. La sécurité est la priorité numéro un et c'est un engagement qui ne sera jamais compromis. 

Alors que nous nous efforçons continuellement de fournir une expérience utilisateur transparente pour intégrer les 100 prochains millions de personnes dans le Web3, nous n'hésiterons jamais à activer ces mesures de protection, verrouille efficacement l'ensemble du service Ledger Recover, si une menace potentielle survient. Dans notre mission de protection, le choix entre exécuter un service potentiellement compromis et assurer une sécurité ultime est clair : nous choisissons la sécurité.

Conclusion

Nous voilà à la fin de la partie Sécurité Opérationnelle de cette série. Dans cette partie, nous avons essayé de répondre à toutes vos préoccupations concernant la manière dont l'imprenabilité des mesures de sécurité du système Ledger Recover est assurée. Nous avons parlé de l'infrastructure, de la séparation des tâches, de la gouvernance et du suivi, et enfin de la stratégie de réponse aux incidents. 

Merci encore d'avoir lu jusqu'ici ! Vous devriez maintenant avoir une compréhension complète de la sécurité opérationnelle de Ledger Recover. La dernière partie de cette série d'articles de blog portera sur nos derniers soucis de sécurité que nous avons eu, et plus précisément : comment avons-nous géré nos audits de sécurité internes et externes afin de garantir le niveau de sécurité maximum à nos utilisateurs ? Restez à l'écoute! 

• Contenu propulsé par le référencement et distribution de relations publiques. Soyez amplifié aujourd'hui.
• PlatoData.Network Ai générative verticale. Autonomisez-vous. Accéder ici.
• PlatoAiStream. Intelligence Web3. Connaissance Amplifiée. Accéder ici.
• PlatonESG. Carbone, Technologie propre, Énergie, Environnement, Solaire, La gestion des déchets. Accéder ici.
• PlatoHealth. Veille biotechnologique et essais cliniques. Accéder ici.
• La source: https://www.ledger.com/blog/part-5-genesis-of-ledger-recover-operational-security