Comment dois-je configurer un accès d'urgence aux secrets essentiels à l'entreprise au cas où je serais "heurté par un bus"?
Je travaille en tant que développeur principal et administrateur informatique pour une petite entreprise. Je veux m'assurer que les affaires peuvent continuer même si je deviens soudainement indisponible pour une raison quelconque. Une grande partie de ce que je fais nécessite un accès à un certain nombre de serveurs (par le biais de ssh basés sur des clés), des services cloud et d'autres infrastructures sécurisées d'applications. Certains de ces services utilisent MFA, à l'aide d'applications MFA dédiées (comme Amazon) ou de SMS.
Comment puis-je m'assurer que mon plan et ma documentation "touché par un bus" sont complets et complets, mais que cette documentation n'est pas en soi un risque pour la sécurité?
La documentation sera hébergée sur un serveur de fichiers partagé derrière notre VPN, mais qui peut également être accessible en utilisant une interface Web tierce qui place une interface de type "DropBox" au-dessus du serveur de fichiers de base (c.-à-d. Authentification, synchronisation du bureau, fichier partage, etc.). Les fichiers se trouvent dans un emplacement où seuls moi et les autres administrateurs de serveur de fichiers peuvent les voir.
Comment dois-je gérer les "secrets" (mots de passe, clés privées, accès MFA) dans cette documentation pour garantir qu'elle reste complète sans compromettre la sécurité?
Mon conseil serait de retirer les secrets de la boîte de dépôt et de les stocker ailleurs. Vos instructions doivent être facilement lisibles par tout le monde, 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é 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? Il s'agit d'une question de logique commerciale, alors consultez votre direction. Tu pourrais:
- Avoir un mot de passe pour un fichier que tout le monde connaît
- Ayez un fichier configuré avec plusieurs mots de passe afin que chaque individu conserve sa propre copie.
- Faites verrouiller un fichier par un algorithme M-out-of-N (l'équivalent numérique d'exiger 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 de personnes déverrouille le fichier, et qu'un maître est physiquement conservé dans un coffre-fort inviolable que vous vérifiez de temps en temps.
Utilisez la créativité ici. Quoi que vous fassiez, le découplage des "instructions" avec des "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 de logique métier comprendront également des questions de disponibilité. Si quelque chose ne va pas dans votre vie, combien de temps un autre administrateur doit-il reprendre votre travail avant que votre entreprise ne soit affectée? Considérez à quel point vous souhaitez que ces instructions et 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'utilisais le propre wiki du serveur pour stocker ces informations pour un affichage facile, mais cela ne serait évidemment pas si utile dans un scénario de pépin, donc j'ai aussi avait une copie sur le dev VM de cette machine, sauvé des copies sur 3 PC distincts 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 plan du bus: la dégradation gracieuse. Tous les scénarios de hit-by-the-bus n'impliquent pas d'être touchés par un bus. Certains vous impliquent simplement d'être inaccessible à un moment malheureux. Certains vous impliquent de quitter l'entreprise, mais d'être disponible pour une question ou deux. D'autres ne le font pas. Pensez à superposer le plan. Les petits mésaventures peuvent être très bien protégées, tandis que les mésaventures plus importantes peuvent toujours entraîner des pertes commerciales 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 anéanti tous les ordinateurs d'un pâté de maisons, cela a quand même été 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 n'avait pas de plan hit-by-a-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 impromptu de détournement de bus était d'essuyer les machines (chacune d'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é de bouger. Nous avons juste stagné pendant environ deux jours et avons eu un tas de clients grincheux. Selon les mots de Frank Herbert Dune , "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 sur la tête, détruisant tous les enregistrements du plan hit-by-a-bus), affaires a-t-il un moyen de continuer à bouger ... mais j'approuve d'essayer de relever la barre un peu plus que cela!
Obtenez un périphérique USB. Mettez tous les secrets sur l'USB, de préférence dans un fichier KeePass. Dans la documentation, dites à la nouvelle personne où se trouve l'USB et comment le 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 la 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 réussi à convaincre la personne responsable du lieu de stockage qu'ils sont authentiques (et qu'il sera probablement accompagné par des employés de haut niveau pour même s'approcher de votre lieu de stockage).
- Si quelqu'un essaie de prendre le flashdrive avant vous, euh, de se faire heurter par le bus proverbial, que quelqu'un devrait probablement penser à lui-même, "Hmm, Andrew est toujours vivant. Pourquoi quelqu'un touche-t-il cela?"
- Si quelqu'un trouve votre documentation, le montant des dommages qu'il pourrait faire est limité (surtout s'il a réussi à s'introduire sur Internet - très peu de gens vont en voyage pour votre information).
Pour trouver les goodies, ils ont besoin 1) de votre documentation, 2) d'un accès physique, 3) de vous être en train de "désirer les fjords". L'USB est également un petit paquet soigné pour la prochaine personne - branchez et jouez! Ou paniquez, selon l'importance que vous accordez à l'entreprise.
Créer des comptes "à usage d'urgence uniquement"
Pour la plupart des systèmes, vous aurez une sorte de comptes privilégiés qui sont utilisés dans leur administration quotidienne, ceux-ci peuvent être personnalisés ou non en fonction de la politique de votre organisation.
En ce qui concerne les informations d'identification, vous pouvez y perdre l'accès pour diverses raisons - soit par la personne qui les connaît se faire heurter par un bus, soit en perdant le stockage sécurisé prévu de ces informations d'identification (par exemple, perdre un ordinateur dans un incendie) ou en gérant d'une manière ou d'une autre pour 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 ne sont pas destinés à un usage quotidien. Cela implique:
- Pour le moment, personne ne peut y accéder - personne ne connaît les mots de passe requis.
- Si quelqu'un y accède, tout le monde doit être informé (car cela n'est pas censé se produire dans des circonstances normales). Par exemple, des 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.
- Au besoin, les gens peuvent accéder à ces comptes - un moyen simple consiste à générer un mot de passe ou une clé longue, à l'imprimer, à la mettre dans une enveloppe scellée et signée et à la verrouiller dans un coffre-fort.
Mettez vos procédures de sauvegarde et vos informations d'identification là-bas
Lorsque vous gérez vos procédures, votre plan d'accès par bus 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 accessibles à partir du 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 soient perdues à jamais, rien de mauvais ne se produit.
Il est peut-être préférable de considérer le problème comme deux problèmes, authentification et autorisation.
L'authentification établit que vous êtes bien ce que vous prétendez être. Un système peut savoir qu'une demande est vraiment venue de vous parce que seule une personne avec vos informations d'identification aurait pu faire la demande, et seulement vous 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 quelque 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 pourrait faire.
Si le système est conçu de telle manière que n'importe qui puisse être littéralement heurté par un bus et tué, cela signifie également qu'il est possible de révoquer les informations d'identification d'une personne. Les anciens employés, en particulier ceux qui partent en mauvais termes, sont une responsabilité en matière de sécurité. Vous ne pouvez pas forcer un ancien employé à oublier un mot de passe, donc pour être sûr, vous devez changer tous vos mots de passe partagés chaque fois qu'un employé quitte. 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 de mots de passe préserve également 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 d'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 existe généralement une solution, même si elle n'est pas immédiatement évidente.
Avez-vous besoin de partager les 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.
Vous avez peut-être une application Web particulièrement mortelle que vous ne pouvez pas éviter? Vous ne pourrez peut-être pas résoudre ce problème, mais vous pouvez le couvrir: 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 changer et diffuser la connaissance du nouveau mot de passe. Changez le mot de passe au moins à chaque départ d'un employé, mais de préférence plus fréquemment.
La plupart des réponses ici concernent le traitement des informations d'identification, probablement en raison de cette question explicite dans le PO:
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 garantir qu'elle reste complète sans compromettre la sécurité?
Cependant, le titre pose une question différente, que je ne vois pas abordée:
Développer un hit sécurisé par un plan de bus
La réponse à la question ça est l'automatisation.
Dans devops, je trouve que la majeure partie du côté serveur de la position se divise en deux catégories:
Correction de l'infrastructure : Voici 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 VM, configurer Apache , activer l'accès dev aux ressources, etc. C'est l'endroit où 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 procède du point de vue que ces secrets sont vraiment critiques pour l'entreprise.
Essai.
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 sur votre serveur de production pendant les échanges de Noël, avec votre informaticien principal au secret sera difficile à obtenir si le conseil d'administration de votre usine de jouets. C'est le dilemme auquel est confronté le conseil d'administration. Si c'est important, vous devez le tester. Est-il cependant trop important de tester?
Des choses simples vous rattraperont. Quelqu'un a mentionné mettre des données dans des coffres-forts. Génial. Beaucoup de gens gardent leur coffre-fort dans le sous-sol où il est sécurisé et loin des gens. C'est aussi l'endroit qui se remplit initialement d'eau après un incendie mineur. Un autre; votre commis de paie douteux a fait des trucs vraiment douteux 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 les yeux - cela arrive.
La continuité des affaires est un art assez établi, alors faites 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. La carte doit en être informée, et vous et au moins une partie de votre kit doivent être redondants (dans le sens de la duplication).
En attendant, demandez à votre directeur des opérations de souscrire une assurance pour les personnes critiques et/ou une assurance de continuité des activités.
Je suis dans une situation très similaire en tant qu'administrateur informatique unique pour une entreprise de taille moyenne avec beaucoup de logiciels personnalisés dispersés et vaguement liés sur différentes plates-formes. Pire que cela, 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 à comprendre ou à avoir jamais même vu la source de ces choses. Au fur et à mesure de la croissance de l'entreprise, on m'a demandé plus d'une fois de ne pas être heurté par un bus. Je vais vous dire quelle a été notre solution.
Comprenez qu'il y aura des perturbations. Gérez vos 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 quiconque doit venir en cas d'urgence et essayez de remplir vos chaussures. Cela est vrai quelle que soit la qualité de votre documentation.
Assurez-vous que les factures de service vont à l'entreprise, pas à vous.
Continuité du document commercial. À un moment donné, on m'a demandé d'écrire un document qui énonce en anglais simple, que le PDG de la société peut lire, exactement quels serveurs nous avons, ce qui se trouve sur chaque serveur, ce que fait chaque logiciel et les mots de passe pour ceux-ci. comptes. Vous y trouverez des notes et des conseils pour tous ceux qui sont venus et qui devaient 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. Ce document contient donc l'essentiel, avec l'espoir qu'une fois que quelqu'un aura entré 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 la société 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'on peut en dire.
Et écoutez - s'ils ne vous laisseront même pas vous détendre après votre mort, il est temps de demander une augmentation.