Mon conseil serait de supprimer les secrets de la boîte de dépôt et de les stocker ailleurs. Vos instructions doivent être facilement lisibles par l'homme, mais elles peuvent inclure des instructions sur la façon d'accéder à la partie correctement sécurisée des données. Cela vous permet de séparer le côté accessibilité des choses du côté de la sécurité.

Une fois que vous pouvez penser à la sécurité par vous-même, vous pouvez commencer à vous poser la vraie question de combien avez-vous besoin pour protéger ces clés? C'est une question de logique métier, alors consultez votre direction. Vous pouvez:

• Avoir un mot de passe pour un fichier que tout le monde connaît
• Avoir un fichier configuré avec plusieurs mots de passe afin que chaque individu conserve sa propre copie.
• Avoir un fichier verrouillé par un algorithme M-sur-N (l'équivalent numérique de deux clés pour déverrouiller un coffre-fort).
• Avoir un algorithme M-sur-N avec un mot de passe «maître» requis quel que soit le groupe d'individus qui déverrouille le fichier, et ce maître est physiquement conservé dans un coffre-fort inviolable que vous vérifiez de temps en temps.

Faites preuve de créativité ici . Quoi que vous fassiez, le découplage des "instructions" avec les "informations sensibles" vous permet de protéger correctement les informations, puis de fournir des instructions sur la façon d'obtenir ces données plus tard.

Vos décisions en matière de logique métier incluront également des questions de disponibilité. Si quelque chose ne va pas dans votre vie, combien de temps un autre administrateur doit-il prendre en charge votre travail avant que l'entreprise ne soit affectée? Considérez dans quelle mesure vous souhaitez que ces instructions et ces informations sensibles soient répliquées en cas de problèmes de serveur. Lorsque j'administrais un serveur et que je devais stocker des instructions sur la façon de le restaurer à partir d'une sauvegarde, j'ai utilisé le propre wiki du serveur pour stocker ces informations pour une visualisation facile, mais évidemment cela ne serait pas si utile dans un scénario de pépin, alors j'ai aussi avait une copie sur la VM de développement de cette machine, sauvegardé des copies de celui-ci sur 3 PC séparés et une impression. Je ne pouvais pas garantir que l'impression resterait à jour, mais je me suis assuré que je pouvais faire de mon mieux.

Cela souligne également quelque chose qui ne fait pas toujours partie d'un succès du plan de bus: gracieux dégradation. Tous les scénarios frappés par le bus n'impliquent pas de se faire heurter par un bus. Certains impliquent que vous soyez simplement inaccessible à un moment malheureux. Certains impliquent que vous quittiez l'entreprise, mais que vous soyez disponible pour une ou deux questions. D'autres ne le font pas. Pensez à superposer le plan. Les petits accidents peuvent être très bien protégés, tandis que les accidents plus importants peuvent toujours entraîner une perte d'entreprise pendant que tout le monde se rassemble, mais rien de permanent. Pour utiliser mon plan de restauration de sauvegarde comme exemple, la version imprimée était presque garantie de ne pas être entièrement à jour. Mais si la foudre a détruit tous les ordinateurs d'un pâté de maisons, c'était encore plus utile que rien. D'un autre côté, si le serveur avait juste un disque dur et que je devais restaurer à partir d'une sauvegarde, la version que je gardais synchronisée sur la boîte de développement était presque certainement à jour.

Exemple de cet échec: j'étais un utilisateur sur un réseau géré par KERBEROS par un administrateur qui se méfiait des autres et qui n'avait pas de plan de bus. Quand il ... est parti, nous avons organisé une partie de piratage pour essayer de casser son serveur. En fin de compte, notre meilleur plan d'intervention impromptu était d'essuyer les machines (chacune d'entre elles) et de repartir de zéro. Notez que, même si ce n'était pas le meilleur plan (en fait, je pense que c'est le pire plan?), L'entreprise a continué à bouger. Nous venons de stagner pendant environ deux jours et avons eu un tas de clients grincheux. Pour reprendre les termes de Dune de Frank Herbert, «L'épice doit couler». Même dans le pire des cas (qui peut impliquer un incident curieux impliquant le disque dur de votre serveur jeté hors du bus et vous frappant à la tête, détruisant tous les enregistrements du plan d'intervention en bus), les affaires font ont un moyen de continuer à bouger ... mais j'approuve d'essayer de relever la barre un peu plus que ça!

Procurez-vous un périphérique USB. Mettez tous les secrets sur la clé USB, de préférence dans un fichier KeePass. Dans la documentation, indiquez à la nouvelle personne où se trouve la clé USB et comment la déverrouiller, mais placez l'appareil dans un endroit physique sécurisé comme le bureau du propriétaire, le coffre-fort de l'entreprise, un coffre-fort, etc. Quelque part hors de portée du public, et loin des regards indiscrets des autres employés.

Les avantages de ce plan sont:

• Ce n'est pas sur Internet ou sur le réseau interne
• Vous pouvez être assuré que le nouvel employé a au moins géré pour convaincre la personne en charge du lieu de stockage qu'ils sont authentiques (et seront probablement accompagnés d'employés de haut niveau pour même se rapprocher de votre lieu de stockage).
• Si quelqu'un essaie d'accéder au lecteur flash avant que vous, euh, soyez frappé par le bus proverbial, quelqu'un devrait probablement penser à lui-même: "Hmm, Andrew est toujours en vie. Pourquoi quelqu'un touche-t-il ça?"
• Si quelqu'un trouve votre documentation, le montant des dégâts qu'il pourrait causer est limité (surtout s'il réussit à s'introduire par effraction sur Internet - très peu de gens vont faire un road trip pour votre information).

Pour trouver les goodies, ils ont besoin 1) de votre documentation, 2) d'un accès physique, 3) de vous pour «avoir envie des fjords». L'USB est également un petit paquet sympa pour la personne suivante - plug and play! Ou paniquer, selon l'importance que vous accordez à l'entreprise.

Créez des comptes "à usage d'urgence uniquement"

Pour la plupart des systèmes, vous disposerez de certains types de comptes privilégiés qui sont utilisés dans leur administration quotidienne, ceux-ci peuvent ou non être personnalisés en fonction de la politique de votre organisation.

Comme pour toutes les informations d'identification, vous pouvez perdre l'accès à celles-ci pour diverses raisons - soit parce que la personne sachant qu'elle a été heurtée par un bus, soit en perdant le stockage sécurisé prévu de ces informations d'identification (par exemple, la perte d'un ordinateur dans un incendie) ou en réussissant d'une manière ou d'une autre à changer un mot de passe en quelque chose qu'ils ne connaissent pas, etc.

Ce qui peut être utile est de créer des comptes séparés pour les systèmes clés qui ont un accès complet, mais qui ne sont pas destinés à utilisation quotidienne. Cela implique:

1. Pour le moment, personne ne peut y accéder - personne ne connaît les mots de passe requis.
2. Si quelqu'un y accède, tout le monde doit être informé (car c'est pas censé se produire dans des circonstances normales). Par exemple, pour les scripts automatisés qui envoient un e-mail à plusieurs utilisateurs clés lors de la connexion, toutes les actions de ces comptes sont enregistrées et votre surveillance quotidienne s'allume si quelque chose est exécuté à partir de ces comptes.
3. Si nécessaire, les utilisateurs peuvent y accéder. à ces comptes - un moyen simple est de générer un mot de passe ou une clé long, de l'imprimer, de le mettre dans une enveloppe scellée et signée et de le verrouiller dans un coffre-fort.

Remettez-le en place -up des procédures et des informations d'identification là-bas

Lorsque vous gérez vos procédures, votre plan d'accès direct et vos listes d'informations d'identification secondaires de la manière qui vous convient - assurez-vous simplement que ces documents ou bases de données de mots de passe sont également accessible depuis le compte d'utilisation d'urgence.

Peut-être qu'une meilleure solution à votre situation est de concevoir le système de telle sorte que même si vous êtes heurté par un bus et que vos informations d'identification sont perdues à jamais, rien de grave ne se passe.

Il vaut peut-être mieux y penser le problème comme deux problèmes, authentification et autorisation.

L'authentification établit que vous êtes qui vous prétendez être. Certains systèmes peuvent savoir qu’une demande provient vraiment de vous, car seule une personne disposant de vos informations d’identification aurait pu effectuer la demande, et vous seul connaissez les informations d’identification.

L’autorisation établit que vous êtes autorisé à faire une certaine chose. Une demande peut être authentique mais non autorisée.

Si au moins deux personnes sont autorisées à faire une chose, alors peu importe si l'une d'elles est heurtée par un bus. Alice peut être tuée par un bus et la connaissance de ses informations d'identification perdue à jamais. Mais Bob connaît ses propres informations d'identification et il est autorisé à faire tout ce qu'Alice peut faire.

Si le système est conçu de telle manière que n'importe qui puisse être littéralement frappé par un bus et tué, cela signifie aussi que c'est possible pour révoquer les informations d'identification d'une personne. Les anciens employés, en particulier ceux qui partent en mauvais termes, constituent un passif de sécurité. Vous ne pouvez pas forcer un ancien employé à oublier un mot de passe. Par conséquent, pour être sûr, vous devez changer tous vos mots de passe partagés chaque fois qu'un employé part. En pratique, c'est trop pénible et ce n'est pas fait. Ne pas partager les mots de passe en premier lieu résout le problème.

Ne jamais partager les mots de passe préserve également la responsabilité . Vous ne pouvez pas gérer une entreprise sans administrateurs, mais vous aimeriez avoir la possibilité de savoir si un administrateur particulier abuse de ses pouvoirs. En fin de compte, la menace de résiliation ou de litige dissuade tout administrateur de tout abus. Si les mots de passe sont partagés, "doit avoir été l'un des autres administrateurs avec le mot de passe" est une défense plausible.

Parfois, vous rencontrez des situations où il semble impossible d'éviter de partager un mot de passe. Mais il y a généralement une solution, même si ce n'est pas immédiatement évident.

Avez-vous besoin de partager des mots de passe root? Non, vous ne pouvez pas du tout avoir de mot de passe root et utilisez plutôt sudo.

Qu'en est-il des informations d'identification racine AWS? Vous pouvez utiliser IAM à la place.

Peut-être avez-vous une application Web particulièrement insensée que vous ne pouvez pas éviter? Vous ne pourrez peut-être pas résoudre celui-ci, mais vous pouvez le dissimuler: utilisez un gestionnaire de mots de passe qui permet de partager les informations d'identification entre plusieurs utilisateurs. (Je sais que LastPass peut le faire). Pendant que vous partagez toujours le mot de passe, vous disposez au moins d'un moyen automatisé pour le modifier et diffuser la connaissance du nouveau mot de passe. Changez le mot de passe au moins chaque fois qu'un employé quitte, mais de préférence plus fréquemment.

La plupart des réponses ici concernent la gestion des identifiants, probablement en raison de cette question explicite dans l'OP:

Quelle est la meilleure façon de gérer les "secrets" (mots de passe, clés privées , Accès MFA) dans cette documentation pour s'assurer qu'elle reste complète sans compromettre la sécurité?

Cependant, le titre pose une question différente, que je ne vois pas traitée:

Développer un coup sûr par un plan de bus

La réponse à la question est l'automatisation.

Dans les devops, je trouve que la majeure partie du côté serveur de la position se divise en deux catégories:

• Réparer l'infrastructure : il n'y a généralement rien à automatiser: chaque problème est différent. Dans ces cas, la connaissance de l'infrastructure (serveurs, réseau, comment les développeurs interagissent avec les dépôts Git) est essentielle.

• Maintenir l'infrastructure : Créer de nouvelles instances de VM, configurez Apache, activez l'accès des développeurs aux ressources, etc. C'est ici que l'automatisation est la plus visible.

Si le rôle de l'automatisation dans le second est évident, la clé pour résoudre avec succès les problèmes dans le premier est l'automatisation dans le second . Les scripts automatisés Python et Bash servent de documentation vivante de ce qui est attendu des serveurs et du réseau: lorsque le workflow change, ce sont les scripts qui changent. Git enregistre les modifications qui peuvent être applicables aux serveurs plus anciens, et les messages de validation git sont explicites.

Ce n'est pas une autre idée sur la façon de le faire en soi, mais plutôt un point pour signaler quelque chose qui n'a pas encore été discuté mais qui est très important. Je pars du point de vue que ces secrets sont vraiment critiques pour l'entreprise.

Test.

Certains scénarios de reprise après sinistre ont été proposés. Certains sont simples, certains sont plus complexes. Plus la complexité est grande, plus il y a de raisons de tester. Ce problème vient de la façon dont vous testez quelqu'un qui est «retiré» de la scène dans un environnement critique pour l'entreprise? Faire passer un rond de 20 mm à travers votre serveur de production pendant les échanges de Noël, avec votre informaticien principal au secret, sera difficile à obtenir à travers le tableau de votre usine de jouets. C'est le dilemme auquel est confronté le conseil. Si c'est important, vous devez le tester. Est-ce trop important de tester?

Des choses simples vous surprendront. Quelqu'un a mentionné mettre des données dans des coffres-forts. Génial. Beaucoup de gens gardent leur coffre-fort au sous-sol où il est en sécurité et loin des gens. C'est aussi l'endroit qui se remplit initialement d'eau suite à un léger incendie. Un autre; votre commis à la paie douteux a fait des choses vraiment douteuses avec votre paie. La police entre et confisque tous vos serveurs pour l'enquête qui s'ensuit. Il faut un an pour les récupérer. Ne roulez pas des yeux - cela arrive.

La continuité des affaires est un art bien établi, alors faites simplement ce que font la NASA, Google, Barclays, l'armée et les centrales nucléaires. Faites de la redondance. Je suis désolé de le dire Andrew, mais vous êtes le principal risque pour l'entreprise dans ce scénario. Le conseil doit en être conscient, et vous et au moins une partie de votre kit devez être redondants (dans le sens de la duplication).

En attendant, demandez à votre directeur des opérations d'obtenir des informations critiques assurance de personne et / ou assurance de continuité des activités.

Je suis dans une situation très similaire en tant qu'administrateur informatique unique d'une entreprise de taille moyenne avec de nombreux logiciels personnalisés dispersés et vaguement liés sur différentes plates-formes. Pire encore, j'ai écrit tous les logiciels de l'entreprise au cours des dix dernières années, de leur système de point de vente aux réservations en ligne, un CMS homebrew, un logiciel de formation des employés, etc. À ce stade, je suis la seule personne qui comprend ou a jamais même vu la source de ces choses. Au fur et à mesure que l'entreprise grandissait, on m'a demandé plus d'une fois de ne pas être renversé par un bus. Je vais vous dire quelle a été notre solution à ce problème.

1. Comprenez qu'il y aura des perturbations. Gérez les attentes. Si l'entreprise ne veut pas embaucher une personne licenciée, vraisemblablement bien rémunérée, pour apprendre tout ce que vous savez, alors elle doit s'attendre à ce qu'il y ait une courbe d'apprentissage très abrupte pour toute personne qui doit intervenir en cas d'urgence et essayez de remplir vos chaussures. Cela est vrai quelle que soit la qualité de votre documentation.

2. Assurez-vous que les factures de service vont à l'entreprise, pas à vous.

3. Continuité du document commercial. À un moment donné, on m'a demandé d'écrire un document rédigé en anglais simple, que le PDG de l'entreprise peut lire, exactement quels serveurs nous avons, ce qu'il y a sur chaque serveur, ce que fait chaque logiciel et les mots de passe pour ceux-ci. comptes. Il contient des notes et des conseils pour tous ceux qui sont venus et qui ont besoin de le faire fonctionner. Cependant, selon (1), il est entendu qu'il faudrait un livre pour expliquer en détail les fonctions, les problèmes et limitations connus, et la structure de tous les logiciels. Donc, ce document contient l'essentiel, avec l'espoir qu'une fois que quelqu'un est entré dans le code, il commencera à regarder les tâches cron et à lire les commentaires et à comprendre comment cela fonctionne.

Je mets à jour le document de continuité si nécessaire, PGP le crypte pour qu'il ne puisse être ouvert que par le PDG de l'entreprise et moi-même, et le télécharge sur leur serveur Web à une adresse qu'il connaît. Le PDG est responsable de la sécurité de sa clé PGP. C'est tout ce qu'il y a à faire.

Et écoutez - s'ils ne vous laisseront même pas vous détendre après votre mort, il est temps de demander une augmentation.

Votre solution, pour être globale, doit être une combinaison de contrôles procéduraux et techniques. La meilleure façon de le comprendre est de voir les contrôles technologiques comme fournissant la capacité d'améliorer votre sécurité procédurale. Ils rendent certains contrôles possibles et d'autres plus faciles à exécuter.

Dans cet esprit, cela dépendra en grande partie de la façon dont vous utilisez votre PKI. Si vous êtes dans une organisation plus petite, les contraintes budgétaires peuvent limiter ce que vous pouvez faire, mais si possible, je recommanderais un module de sécurité matérielle (HSM) pour protéger vos clés privées - à tout le moins, les clés privées de votre CA interne, si vous en avez une. Les fournisseurs de cet espace incluent Thales et SafeNet.

En ce qui concerne les mots de passe, il existe un certain nombre de solutions de gestion des mots de passe conçues pour les organisations de service. La chose la plus importante à rechercher est l'une des deux choses suivantes: Une solution qui offre la possibilité de donner à un utilisateur les privilèges d'accès nécessaires pour faire son travail dans une fenêtre de temps prédéfinie sans avoir à donner à cet utilisateur le mot de passe réel pour le système / l'application, ET / OU un système conçu pour prendre en charge la connaissance du secret partagé (où personne ne possède le mot de passe complet).

Certains fournisseurs de sécurité offrent un moyen de créer une séparation des rôles supplémentaire dans ce qu'un AD L'administrateur du domaine ou l'administrateur de la base de données peuvent le faire (par exemple, ils peuvent être en mesure d'ajouter des utilisateurs à des groupes, mais ne pas activer la possibilité d'ouvrir / modifier les fichiers auxquels l'appartenance à ce groupe leur donne normalement le droit - cette capacité serait gérée par un autre administrateur qui ne peut pas non plus ajouter / supprimer des utilisateurs à des groupes). L'un de ces fournisseurs est Vormetric - ils le font avec leur produit de chiffrement des données au repos.

Bien que le support exécutif soit important pour le succès de la stratégie de sécurité de toute organisation, il devient particulièrement vital en l'absence d'une solution de fournisseur qui offre ces capacités - car cela signifie que vous devrez probablement intensifier vos programmes de sensibilisation à la sécurité pour favoriser le type de changement de culture qui prendra en charge les contrôles procéduraux nécessaires auxquels la plupart des utilisateurs informatiques ne sont pas habitués - où les privilèges d'administrateur de domaine et d'entreprise sont strictement contrôlés et ne sont autorisés qu'après l'approbation de la gestion du changement, et uniquement pendant une fenêtre de temps spécifique . Les administrateurs informatiques doivent intégrer un mot de passe multi-personne + des contrôles physiques.

Les exemples incluent l'utilisation de 2 à 4 personnes pour générer les moitiés d'un mot de passe à 12 caractères. Une paire de membres du personnel génère le mot de passe et le saisit dans le champ «Nouveau mot de passe». La deuxième paire réentre les composants de mot de passe créés par la première paire (pour vous assurer que l'une des premières paires ne saisit pas malicieusement ou involontairement le mot de passe à chaque fois, rendant le compte inaccessible une fois que le mot de passe est modifié). L'utilisation d'une deuxième paire de membres du personnel garantit également que les mots de passe sont lisibles tels qu'ils ont été écrits. Une fois le mot de passe modifié, les fragments de mot de passe sont ensuite stockés dans des enveloppes opaques séparées, scellés, étiquetés et déposés dans des sacs inviolables. Les sacs peuvent ensuite être déposés dans un coffre-fort physique. Répliquez le processus pour le stockage de sauvegarde hors site, mais incorporez des processus pour garantir que les mises à jour des mots de passe sont répliquées à chaque fois pour chaque site. Si le stockage inviolable ne suffit pas, recherchez un coffre-fort à double combinaison approuvé par GSA (X-10 Kaba Mas, par exemple) et incorporez la même procédure de partage des connaissances. Pour une protection supplémentaire, stockez le coffre-fort dans un endroit avec un système de caméra CCTV surveillant la zone, et ajoutez un avertissement à tous les employés que toute personne trouvée dans la zone sans autorisation écrite préalable d'entrer peut faire l'objet d'une résiliation - encore une fois, cela devrait venir du haut.

Cela dépend vraiment de votre modèle de menace et de l'appétit de votre organisation pour la sécurité.