Le chiffrement intégral du disque sur un serveur dans un centre de données sécurisé est-il inutile?
J'ai un débat avec plusieurs personnes sur la protection offerte par le chiffrement intégral du disque. dm-crypt est utilisé pour crypter les données dont mon entreprise a besoin pour être cryptées au repos. Les serveurs Linux hébergeant les données résident dans un centre de données sécurisé avec très peu de risques d'accès physique non autorisé, sans parler de quelqu'un qui vole le serveur.
Mon argument est que dans cette situation, tout en respectant la lettre de la loi, ils n'ont pratiquement rien fait pour réduire le risque associé aux données non chiffrées. En effet, d'un point de vue logique, ils sont exactement dans la même situation que si aucun chiffrement n'avait été implémenté. Je suis curieux de savoir si ce train de réflexion est correct, des pensées?
Pour adapter davantage la question à ma situation spécifique, en ce qui concerne la protection physique, les commandes qui l'entourent sont généralement très solides. Je ne dis pas que le risque est éliminé, mais il est considéré comme faible. De même avec l'élimination des disques, les contrôles de destruction fonctionnent assez efficacement et le risque est considéré comme faible. Du point de vue de l'accès logique, les serveurs sont pas face à Internet, sont derrière un pare-feu, l'accès logique est bien contrôlé (mais beaucoup ont accès), et ils ne sont pas virtualisés. De plus, les serveurs fonctionnent 24h/24 et 7j/7, la seule fois où ils sont redémarrés, c'est si cela est nécessaire après un changement ou lors de l'installation d'un nouveau.
Ma préoccupation est que dans le cas où un initié deviendrait un voyou ou qu'un utilisateur non autorisé exploiterait une faille de sécurité logique, le cryptage complet des données ne fait rien pour protéger les données par rapport à l'utilisation d'autres outils de cryptage au niveau du champ ou du fichier disponibles. Alors que les personnes dont je parle soutiennent que ce n'est pas le cas.
Deux choses génériques que vous avez apparemment manquées:
En cas de défaillance du disque, le fait de chiffrer les données au repos résout le problème d'avoir des données potentiellement sensibles sur un support auquel vous ne pouvez plus accéder. Cela rend l'élimination des disques défectueux plus facile et moins chère (et c'est un problème de moins)
Le chiffrement complet du disque rend également plus difficile pour un attaquant de récupérer des données de l'espace "vide" sur les disques (qui contient souvent la trace de données précédemment valides)
Et si vous utilisez des machines virtuelles:
- Le chiffrement de la partition vous rend moins dépendant de la sécurité de votre hyperviseur: si en quelque sorte le contenu brut de l'un de vos disques "fuit" vers un autre VM (ce qui pourrait arriver si l'espace disque est réaffecté à un autre VM et non remis à zéro), que VM sera moins susceptible d'avoir accès aux données réelles (il devra également obtenir la clé de déchiffrement) ).
Si la clé de déchiffrement est stockée en clair sur le même support que les données chiffrées, alors le chiffrement est inutile. Si vous avez un ensemble de règles, qui nécessitent le chiffrement des données, mais permettent de stocker la clé en clair sur le même support, les règles sont défectueuses. Si jamais vous faites face à un ensemble de règles aussi imparfaites, vous devez signaler la faille.
Si la clé n'est pas stockée sur le même support que les données. Le chiffrement sert alors un objectif. Cela soulève cependant la question de savoir d'où le serveur obtient la clé au démarrage. Il y a quelques options:
- Exiger la saisie d'un mot de passe lors du démarrage. Ce n'est pas très pratique pour un serveur.
- Récupérez la clé de déchiffrement à partir d'un serveur de clés. Cela peut empêcher les données d'être déchiffrées si le serveur a été volé, il suffit au serveur clé de répondre uniquement aux demandes provenant du centre de données.
- Secret partage la clé sur plusieurs disques. Ne fait rien pour le cas où le serveur est volé. Mais si vous avez un RAID où des disques simples sont parfois remplacés, cela garantit que toutes les données restantes sur les disques retournés sous garantie sont correctement cryptées. Lorsqu'un nouveau disque est ajouté au RAID, une implémentation de cette technique devrait procéder comme suit:
- Générez une clé de chiffrement pour ce disque individuel.
- Générez une nouvelle clé principale.
- Secret partage la nouvelle clé principale sur tous les disques.
- Sur chaque disque, écrivez la clé de chiffrement du disque chiffrée sous la nouvelle clé principale.
Les trois approches décrites ci-dessus peuvent être combinées. S'ils sont combinés, le serveur de clés pourrait être implémenté à l'aide de RSA en aveugle.
Il y a des attaques sur le firmware des disques durs. Googler pour hard drive firmware attack renverra des résultats sur ce que le NSA fait ou peut faire, ce qui n'est probablement pas très pertinent pour vous; mais même les amateurs peuvent modifier le micrologiciel des lecteurs. Ce type a même installé un noyau Linux sur son disque dur - non, ce n'était pas le PC qui exécutait Linux, le contrôleur de disque dur lui-même l'a fait.
Si quelqu'un accède au micrologiciel de vos disques (par exemple, que quelqu'un loue un serveur de votre centre de données pendant un mois, puis le renvoie; la société du centre de données efface les disques, puis vous attribue ce serveur), il se peut le micrologiciel du lecteur fait quelque chose comme "Chaque fois qu'un bloc qui est écrit sur le disque contient un modèle spécial, pour les 5 minutes suivantes, dans chaque bloc de lecture commençant par root:$1$, remplacez les premiers octets par (du hachage de mot de passe) ", vous avez une attaque presque indétectable. Votre /etc/shadow le fichier vous semblera normal sauf pendant la fenêtre de 5 minutes après que votre attaquant a demandé un fichier avec un nom contenant le modèle de déclenchement de votre serveur Web, qui l'a écrit dans son journal des erreurs.
Peu probable? Sûr. Impossible? Définitivement pas. Est-il paranoïaque de supposer que cela pourrait arriver? Probablement oui, selon l'intérêt de vos données. Mais, le cryptage de vos disques vous protégera de ce type d'attaque, et cela ne vous coûtera rien d'autre que quelques cycles de processeur. Et, s'il y a des lois ou des règlements à suivre, en cas d'atteinte à la sécurité, je ne veux certainement pas être en mesure d'expliquer pourquoi je pensais que cela n'aurait pas d'importance.
Réfléchissez à ce que vous entendez par centre de données "sécurisé".
En général, je ne considère rien de sûr contre un attaquant déterminé et doté de ressources suffisantes. Certes, le fait d'avoir 18 "de béton armé, des doubles pièges à homme et une sécurité armée offre une bonne quantité de protection, mais il est rare que cette protection soit juste pour vous. Dans la plupart des installations de co-implantation, la seule chose qui vous protège d'un personne avec 500 $ et suffisamment de connaissances pour louer un espace de rack dans le même établissement que vous est une cage métallique douteusement sécurisée avec un gobelet à trois broches.
Parfois, les catastrophes naturelles et d'origine humaine inonderont les choses, couperont le courant, empoisonneront l'approvisionnement en eau et feront toutes sortes de choses inhabituelles qui empêcheront les agents de sécurité et les techniciens de se présenter au travail ou de rentrer chez eux dans leur famille - ce que je dis est que les centres de données n'offrent qu'un niveau de sécurité qui n'est probablement pas autant que le pensent beaucoup de leurs clients.
Reconsidérez votre position sur le faible risque de perte de disques par votre sous-traitant.
Un certificat de destruction vous donne également le droit de rembourser les 20 $ que vous leur avez versés pour détruire un lecteur qui n'a pas été détruit?
Avez-vous visité votre installation d'élimination des disques? Vérifié leurs procédures d'embauche? Vu leurs garanties? Assurez-vous que vous êtes solide comme ça, car c'est l'une des vulnérabilités les plus évidentes - un changement de garde.
Donc, ce n'est pas du tout ce que vous avez demandé, qu'en est-il de la menace d'initié que vous avez réellement posée?
Ok, un initié aurait accès via votre FDE et verrait les fichiers non cryptés. Dans votre scénario FDE, cela ne fera rien pour empêcher ou ralentir l'initié d'obtenir les données.
Ce qu'il fera, c'est canaliser votre menace interne pour passer par votre FDE, ce qui vous permettrait de consigner, de surveiller et d'identifier un coupable, ou au moins un suspect. Être capable d'identifier votre attaquant est une couche de sécurité.
Mais, je suis presque sûr que l'entonnoir n'est pas principalement destiné à FDE. Même si vous disposez de FDE, vous pouvez toujours implémenter un autre niveau de fichier ou un autre chiffrement de données au-dessus de FDE. Vous pouvez également utiliser les contrôles d'accès du système d'exploitation.
FDE protège contre les initiés qui n'ont pas accès via le FDE. Il évite aux techniciens de serveur de remplacer les disques en prenant un et de les décoller avec des données. Il protège contre un employé de l'installation serveur qui en prend un dans un conteneur d'expédition dans votre installation en attendant le transport vers votre entrepreneur de destruction.
FDE vous permet également de mettre un terme aux menaces internes si vous séparez votre batterie de serveurs ou utilisez un accès granulaire - par exemple, vos initiés n'ont accès qu'à certains serveurs, etc. FDE les empêcherait de copier simplement des disques en gros qu'ils n'ont pas. accès via le FDE pour.
Autrement dit, FDE protège les données sur le lecteur contre l'accès physique au lecteur. Vous pouvez essayer de contrôler l'accès physique autant que vous le souhaitez, mais les disques se retrouveront toujours avec une certaine vulnérabilité (être volés par des initiés, être copiés par des initiés, transiter en détention là où les initiés le touchent, sans surveillance en raison d'une catastrophe, etc. ). Si des personnes touchent le lecteur, le FDE est une couche de défense contre celui-ci.
David
Pas surement. Cela dépend de ce que vous voulez vous défendre. Quelques exemples:
- Si vous vivez dans un pays, où le gouvernement peut confisquer votre serveur pour analyser son contenu et ensuite l'utiliser contre vous ou votre employeur.
- Si vous êtes le propriétaire du serveur, mais ne donnez pas la possibilité à vos employés/collègues d'y avoir un accès physique, ils ont volé/miroir son contenu. Ensuite, vous leur permettez de le réparer/démarrer, mais ne leur donnez pas les clés de chiffrement.
- La même chose pourrait servir de protection efficace si vous ne pouvez pas/ne ferez pas confiance à votre solution d'hébergement de serveur.
Cela dépend des circonstances. Ces circonstances, que j'ai montrées à titre d'exemple, sont au moins rares dans mon environnement, mais elles pourraient être possibles.
Si vous êtes dans un environnement commercial normal, ne le faites pas. Il a pris beaucoup d'heures de travail et a un temps de service prolongé. À mon avis, dans la plupart des cas, cela ne vaut pas son prix.
Citation: "..., Ils n'ont pratiquement rien fait pour réduire les risques associés aux données non chiffrées..."
Ok, ouais, je pense que tu as raison. La réponse simple est "c'est inutile", mais "ce n'est PAS non plus inutile". C'est pourquoi, et pardonnez-moi d'avoir dit cela, je pense que vous aboyez peut-être le mauvais arbre. Laisse-moi expliquer. Le chiffrement complet du disque (FDE) sert à quelque chose - même si ce n'est que pour un sous-ensemble d'exploits à faible probabilité. Il existe un certain nombre d'exploits possibles - et la probabilité FAIBLE n'est pas égale à la probabilité NON.
Alors, est-ce inutile? Pas entièrement. Mais pourquoi vous opposez-vous à cela? Souhaitez-vous accorder plus d'attention à la sécurité lorsque les serveurs fonctionnent et que les données ne sont pas chiffrées? Cela pénètre dans la région où les faits peuvent vous faire moins de bien, et un sens de la politique peut vous être utile.
Il se pourrait que votre objectif dans cet argument au travail soit d'établir votre expertise. Ou peut-être que vous pensez devoir faire quelque chose et que personne n'y prête attention. Tous les éléments ci-dessus sont valides et raisonnables et font partie de l'environnement de travail quotidien. Je pourrais mal interpréter votre question, mais il me semble que vous pourriez obtenir un meilleur résultat en plaidant pour l'action que vous pensez devoir être effectuée, plutôt que contre une action qui IS est en cours. Choisissez vos combats.
D'après votre description, je soupçonne que vous avez raison. En d'autres termes, le chiffrement complet du disque n'ajoute aucune protection réelle pour vos données sur un serveur en cours d'exécution si quelqu'un compromet ce serveur pour extraire les données. Ce n'est pas ce que le chiffrement complet du disque est conçu pour atteindre. Cependant, cela ne signifie pas qu'il n'y a pas de raison d'avoir un chiffrement complet du disque sur un serveur. Comme indiqué dans d'autres articles, il existe de bonnes raisons de disposer d'un chiffrement complet du disque sur un serveur, comme la protection contre le vol, le contrôle efficace de l'élimination des disques ou le renvoi de disques défectueux au fournisseur, etc. Cependant, si vous devez protéger les données sur le serveur lorsqu'il est en cours d'exécution, vous aurez généralement besoin d'un chiffrement de fichier, de table, etc. en plus du chiffrement du disque - ce n'est pas nécessairement une situation non plus.
L'autre chose à considérer est que la sécurité concerne les couches de protection. Le fait de suggérer que vous disposez de bons contrôles pour l'élimination des disques et que vous n'avez donc pas besoin d'un chiffrement complet du disque suppose que les contrôles utilisés pour l'élimination des disques n'échoueront jamais. Cependant, ces types de contrôles ont généralement un contenu procédural et humain élevé - il dépend fortement de l'administrateur qui suit correctement la procédure. D'après mon expérience, ce sont les types de contrôles qui sont plus susceptibles d'échouer. Ce pourrait être ce nouvel employé qui oublie ou qui n'est pas au courant de la procédure, il se peut qu'un administrateur système expérimenté face à une défaillance à haute pression où le patron lui fasse pression pour récupérer le service dès que possible, etc. Le cryptage complet du disque est simplement un autre contrôle de protection qui soulage une partie de la pression du personnel et réduit l'impact possible d'une simple erreur humaine.
Là où les choses tournent mal avec le chiffrement complet du disque, c'est quand les gens supposent qu'il résout plus de problèmes qu'il ne le fait réellement - cela semblerait être la force de votre argument/préoccupation. J'ai vu de nombreux fournisseurs et même des administrateurs convaincre la direction que les données sont en sécurité simplement parce qu'elles utilisent un chiffrement complet du disque. En conséquence, peu ou pas d’analyse des risques réels est effectuée concernant les risques lorsque le serveur est en cours d’exécution. J'ai récemment réalisé un grand projet de stockage de données pour un client qui impliquait des données potentiellement sensibles et/ou précieuses. Il était assez surprenant de voir le nombre de fournisseurs qui ne répondaient pas correctement aux questions de cryptage. Leur réponse courante était que "ça va, le système utilise le cryptage complet du disque". Une fois que j'ai exploré et donné des exemples et demandé comment leur cryptage complet du disque protégerait contre divers scénarios pour un serveur en cours d'exécution, leur réponse générale était "Oh, c'est un problème que l'application doit résoudre".
Pour moi, le plus gros problème que j'ai rencontré avec le chiffrement complet du disque et le chiffrement au niveau des fichiers/tables est le manque fréquent de toute considération réelle concernant la gestion des clés. Pour moi, la plupart des solutions semblent faibles dans leur prise en charge pour permettre une gestion des clés cohérente et fiable. Il y a eu de nombreuses fois où j'ai vu un système où l'on m'a parlé de toute la merveilleuse utilisation du cryptage pour protéger les données, seulement pour constater que les clés utilisées sont mal protégées - presque après coup. Pire encore, en raison du manque d'une approche bonne ou comprise, vous rencontrez des centres de données où la même clé est utilisée à plusieurs endroits ou à plusieurs niveaux juste pour que les administrateurs puissent les gérer efficacement et pouvoir récupérer si nécessaire.
Merci à tous pour vos commentaires. En résumé, la question du titre, est FDE pour un serveur dans un centre de données sécurisé inutile? La réponse n'est pas nécessairement car il pourrait y avoir des scénarios où l'on voudrait la protection supplémentaire sur les appareils physiques. Par exemple, la protection pendant la destruction, la protection du pays hôte ou la protection en cas de panne de disque entre autres situations.
Dans le texte, la question a été quelque peu modifiée par rapport à celle indiquée dans le titre. La préoccupation principale était que les données étaient compromises non pas par un accès physique au serveur mais par un accès logique aux données. Sur la base des réponses, il semble que FDE n'offre pas cette protection. La solution est transparente pour l'utilisateur où les données sont déchiffrées sur le serveur au démarrage. À ce stade, on dépend d'autres contrôles tels que les pare-feu, une bonne gestion des accès, une authentification forte et des correctifs.
Ma préférence est qu'en plus de ces contrôles pour le cryptage au niveau des fichiers ou des champs à utiliser avec un accès aux clés de cryptage restreint pour fournir une couche de sécurité supplémentaire.
Une chose que je n'ai pas vue mentionnée est que j'ai entendu dire que FDE peut également fournir une protection contre certains types de logiciels malveillants qui pourraient copier les informations par programme. Cependant, je n'ai pas pu confirmer cette affirmation par la recherche.
Voici 2 autres avantages (en supposant que vous utilisez de nouvelles clés de chiffrement à chaque réinstallation):
Si vous exécutez des outils de récupération de fichiers qui analysent le périphérique de bloc complet, par exemple PhotoRec, vous n'avez pas à vérifier des tonnes de vieux fichiers qui ne vous intéressent plus.
Si vous exécutez des outils de réparation de système de fichiers qui analysent le périphérique de bloc complet, vous ne courez pas le risque de confondre les structures et les métadonnées d'un ancien système de fichiers avec le système actuel.
JJ