Deux choses génériques que vous avez apparemment manquées:

• En cas de panne de 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 que vous pouvez ' t accéder plus. 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 les données de l'espace "vide" sur les disques (qui contiennent souvent des traces de données précédemment valides)

Et si vous utilisez des VM:

• Crypter la partition vous oblige à moins dépendant de la sécurité de votre hyperviseur: si d'une manière ou d'une autre le contenu brut de l'un de vos disques «fuit» vers une autre VM (ce qui peut arriver si l'espace disque est réalloué à une autre VM et non remis à zéro), cette VM sera moins probable pour avoir accès aux données réelles (il faudrait é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 exigent que les données soient cryptées, mais permettent de stocker la clé en clair sur le même support, alors les règles sont imparfaites. Si jamais vous êtes confronté à un ensemble de règles aussi imparfait, vous devriez le signaler.

Si la clé n'est pas stockée sur le même support que les données. Ensuite, le cryptage a un but. Cela soulève cependant la question de savoir d'où le serveur obtient la clé au démarrage. Il existe quelques options:

• Exiger un mot de passe à saisir lors du démarrage. Ce n'est pas très pratique pour un serveur.
• Récupérez la clé de déchiffrement d'un serveur de clés. Cela peut empêcher le déchiffrement des données si le serveur a été volé, il suffit que le serveur de clés ne réponde qu'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 uniques sont parfois remplacés, cela garantit que toutes les données laissées 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 effectuer les opérations suivantes:
  • Générer une clé de chiffrement pour ce disque individuel.
  • Générer une nouvelle clé principale.
  • Secret partage la nouvelle clé principale sur tous les disques.
  • Sur chaque disque, écrivez la clé de chiffrement de 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é en utilisant RSA aveugle.

Il y a des attaques sur le firmware des disques durs. Google pour l'attaque du micrologiciel du disque dur renverra des résultats sur ce que la NSA fait ou peut faire, ce qui n'est probablement pas très pertinent pour vous; mais même les amateurs sont capables de modifier le firmware des lecteurs. Ce type a même installé un noyau Linux sur son disque dur - non, ce n’est pas le PC qui exécutait Linux, le contrôleur de disque dur lui-même le faisait.

Si quelqu'un y 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 essuie les disques, puis vous attribue ce serveur), il se peut que le micrologiciel du disque le fasse quelque chose comme "Chaque fois qu'un bloc écrit sur le disque contient un modèle spécial, pendant les 5 minutes suivantes, dans chaque bloc de lecture commençant par root: $ 1 $ , remplacez les premiers octets par (un hachage de mot de passe) ", vous avez une attaque presque indétectable. Votre fichier / etc / shadow vous semblera normal sauf pendant la fenêtre de temps 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 d'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 de faille de sécurité, je ne veux certainement pas être en mesure d'expliquer pourquoi je pensais que cela n'aurait pas d'importance.

Considérez 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 disposant de ressources suffisantes. Certes, disposer de 18 pouces de béton armé, de doubles pièges à homme et d'une sécurité armée offre une bonne protection, mais il est rare que cette protection soit juste pour vous. Dans la plupart des installations de colocation, 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, des catastrophes naturelles et causées par l'homme inonderont les choses, couperont le courant, empoisonner les approvisionnements en eau et faire toutes sortes de choses inhabituelles qui empêchent les agents de sécurité et les techniciens de se présenter au travail ou de simplement rentrer chez eux dans leurs familles - ce que je dis, c'est que les centres de données n'offrent qu'un niveau de sécurité qui n'est probablement pas aussi autant que beaucoup de leurs clients le pensent.

Reconsidérez votre position sur le faible risque que votre entrepreneur de mise au rebut perde des disques.

Un certificat de destruction vous donne également droit ..... les 20 $ que vous leur avez payés pour détruire un lecteur qui n'a pas été détruit?

Avez-vous visité votre installation d'élimination des disques durs? Vérifié leurs procédures d'embauche? Vu leurs garanties? Assurez-vous d'être solide à ce sujet, 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 interne vous avez en fait posé la question.

Ok, un initié aurait accès via votre FDE et verrait les fichiers non chiffrés. Dans votre scénario FDE, cela ne fera rien pour empêcher ou ralentir l'initié d'accéder aux données.

Ce qu'il fera, c'est canaliser votre menace d'initié pour passer par votre FDE, ce qui vous permettrait de vous connecter , surveiller et identifier un coupable, ou du moins un suspect. Être capable d'identifier votre attaquant est une couche de sécurité.

Mais, je suis à peu près sûr que l'entonnoir n'est pas principalement à quoi sert FDE. Même si vous avez FDE, vous pouvez toujours implémenter un autre cryptage au niveau du fichier ou un autre cryptage de données en plus de FDE. Vous pouvez aussi toujours 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 empêche les techniciens de serveur de remplacer les disques en prenant un et de s'en aller avec des données. Il protège contre un employé de l'installation de serveur qui en prend un dans un conteneur d'expédition à votre installation en attente de transport à votre entrepreneur de destruction.

FDE vous permet un autre niveau pour arrêter les menaces internes également, si vous séparez votre ferme ou utilisez un accès granulaire - disons que vos initiés n'ont accès qu'à certains serveurs, etc. FDE les empêcherait de simplement copier en gros des disques auxquels ils n'ont pas accès via le FDE.

En termes simples , FDE protège les données du disque contre l'accès physique au disque. Vous pouvez essayer de contrôler l'accès physique autant que vous le souhaitez, mais les lecteurs se retrouveront toujours avec une certaine vulnérabilité (volés par des initiés, copiés par des initiés, transit de garde là où des initiés les touchent, non surveillés en raison d'une catastrophe, etc. ). Si les gens touchent le lecteur, FDE est une couche de défense contre lui.

David

Pas sûrement. 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, puis 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, qu'ils volent / reflètent 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 voulez pas faire 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 professionnel normal, ne le faites pas. Il a pris beaucoup d'heures de travail et a une durée de service prolongée. À mon avis, dans la plupart des cas, cela ne vaut pas son prix.

Citation: "... ils ont peu ou rien fait pour réduire les risques associés aux données non chiffrées..."

Ok, oui, je pense que vous avez raison. La réponse simple est «c'est inutile», mais «ce n'est PAS non plus inutile». C'est pourquoi, et pardonnez-moi de dire cela, je pense que vous aboyez peut-être dans le mauvais arbre. Laissez-moi expliquer. Le chiffrement complet du disque (FDE) a un certain objectif - même si ce n'est que pour un sous-ensemble d'exploits de faible probabilité. Il existe un certain nombre d'exploits possibles - et une probabilité FAIBLE n'équivaut pas à une 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 sont en cours d'exécution et que les données ne sont pas chiffrées? Cela entre 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 peut que votre objectif dans cet argument au travail soit d'établir votre expertise. Ou peut-être qu'il y a quelque chose que vous pensez devoir faire et que personne n'y prête attention. Tout ce qui précède est valide et raisonnable et fait 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 faite, plutôt que contre une action qui EST en cours. Choisissez vos combats.

D'après votre description, je suppose que vous avez raison. Autrement dit, 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 compromettait ce serveur pour extraire les données. Ce n'est pas l'objectif du chiffrement intégral du disque. Cependant, cela ne signifie pas qu'il n'y a aucun cas pour avoir un cryptage complet du disque sur un serveur. Comme indiqué dans d'autres articles, il existe de bonnes raisons d'avoir un cryptage complet du disque sur un serveur, comme une protection contre le vol, un contrôle efficace de l'élimination du disque ou le renvoi des 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 cryptage de fichier, de table, etc. en plus du cryptage du disque - ce n'est pas nécessairement une situation soit / ou.

L'autre chose à considérer est que la sécurité concerne les couches de protection. Suggérer que vous avez mis en place 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é - ils dépendent fortement du fait que l'administrateur suit correctement la procédure. D'après mon expérience, ce sont les types de contrôles les plus susceptibles d'échouer. Il se peut que le nouvel employé oublie ou ne soit pas au courant de la procédure, ce pourrait être cet administrateur système expérimenté qui fait face à une panne de haute pression où le patron fait pression sur lui pour qu'il récupère le service dès que possible, etc. 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 semble être le sens de votre argument / préoccupation. J'ai vu de nombreux fournisseurs et même des administrateurs convaincre la direction que les données sont sûres simplement parce qu'elles utilisent un cryptage 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 impliquant 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 chiffrement. Leur réponse de base était que "c'est ok, le système utilise un cryptage complet du disque". Une fois que j'ai approfondi 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, eh bien c'est un problème que l'application doit résoudre".

Pour moi, le plus gros problème que j'ai rencontré à la fois avec le cryptage complet du disque et le cryptage au niveau des fichiers / tables est le manque fréquent de réelle considération concernant la gestion des clés. Pour moi, la plupart des solutions semblent faibles dans leur soutien pour permettre une gestion des clés cohérente et fiable. J'ai vu plusieurs fois un système dans lequel on m'a parlé de toute la merveilleuse utilisation du cryptage pour protéger les données uniquement pour constater que les clés utilisées sont mal protégées - presque après réflexion. Pire encore, en raison du manque d'approche bonne ou comprise, vous rencontrez des centres de données où la même clé est utilisée à plusieurs endroits ou à plusieurs niveaux simplement pour que les administrateurs puissent les gérer efficacement et être en mesure de récupérer si nécessaire.

Merci à tous pour vos commentaires. En résumé, la question du titre, est-ce que FDE pour un serveur dans un centre de données sécurisé est inutile? La réponse n'est pas nécessairement car il pourrait y avoir des scénarios où l'on voudrait une 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 était quelque peu différente de celle indiquée dans le titre. Le problème dans la question 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écryptées sur le serveur lors du 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 du fichier ou du champ à utiliser avec l'accès aux clés de cryptage étant limité pour fournir une couche supplémentaire de sécurité.

Une chose que je n'ai pas vu 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 programmation. Cependant, je n'ai pas été en mesure de confirmer cette affirmation par la recherche.

Voici 2 autres avantages (en supposant que vous utilisez de nouvelles clés de chiffrement chaque fois que vous réinstallez):

• 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 d’anciens fichiers qui n’ont plus d’intérêt.

• Si vous exécutez des outils de réparation du système de fichiers qui analysent le périphérique bloc complet, vous n’exécutez pas le risque de confondre les structures et méta-données d'un ancien système de fichiers avec le système actuel.

JJ