Le service de stockage S3 d'Amazon propose un chiffrement des objets côté serveur, géré automatiquement pour l'utilisateur ( Amazon's Documentation ). Il est facile de l'activer, je pense donc "pourquoi pas?", Mais quel type de sécurité cela offre-t-il vraiment?
Je suppose que cela empêche quelqu'un de se promener dans le centre de données AWS et de récupérer un disque dur, mais cela semble très improbable, et sans doute toute personne ayant un accès comme celui-ci pourrait également obtenir les clés AES, où qu'elles soient stockées.
Il ne semble pas protéger les données une fois qu'elles sont hors des lecteurs, car à ce stade, elles sont décryptées, et toute personne qui a vos informations d'identification ou qui peut intercepter le trafic verra les données en clair. Alors à quoi ça sert vraiment? Juste pour dire que les données sont "cryptées"?
La réponse courte est la suivante: nous n'en avons aucune idée, probablement aucune.
Il pourrait protéger contre les sauvegardes volées. Mais cela suppose qu'Amazon effectue même des sauvegardes. Cela semble très peu probable. S'ils l'ont fait, pourquoi n'ont-ils pas pu récupérer les données de leur dernière perte de données S3? Il est beaucoup moins cher et plus efficace d'utiliser simplement plusieurs copies en direct.
En outre, Amazon aurait besoin des clés à chaque accès. Il semble donc très peu probable qu'ils stockent les clés ailleurs qu'à peu près aux mêmes endroits où ils stockent les données. Donc, si vous imaginez un vol d'appareils de données en direct, il est tout aussi probable qu'ils obtiennent également les clés.
Mais nous ne savons pas comment Amazon stocke, réplique et/ou sauvegarde les données. Nous ne savons pas non plus où ils stockent les clés ni comment ils les distribuent. Cependant, je n'ai pas encore entendu d'argument plausible selon lequel il existe une menace réaliste contre laquelle ils se protègent. La théorie des "sauvegardes volées" semble être basée sur la fausse prémisse qu'Amazon utilise des sauvegardes lorsque toutes les preuves suggèrent qu'elles utilisent plusieurs copies en direct avec les clés assez proches.
Le cryptage de Dropbox, cependant, protège contre un modèle de menace réel, bien que très peu probable. Dropbox stocke ses propres clés et vous les envoie, de sorte qu'il vous protège contre un employé Amazon voyou. En échange, vous êtes vulnérable à un employé voyou Dropbox ou à un bogue de sécurité Dropbox.
Mon opinion personnelle est qu'Amazon a ajouté cette fonctionnalité juste pour pouvoir dire que les données pouvaient être stockées cryptées. Certaines personnes compareront inconsciemment les cases à cocher sur les listes de fonctionnalités et Amazon voulait une case à cocher sur la ligne "sécurisé/crypté". Quoi qu'il en soit, le lien le plus faible est probablement le réseau interne d'Amazon et la sécurité humaine et la validité de la mise en œuvre du code qui décide d'autoriser ou non les accès.
Je suppose que cela empêche quelqu'un de se promener dans le centre de données AWS et de récupérer un disque dur, mais cela semble très improbable, et sans doute toute personne ayant un accès comme celui-ci pourrait également obtenir les clés AES, où qu'elles soient stockées.
Le commentaire de Gilles répond effectivement à votre question, vraiment, mais j'irai moi-même avec une réponse plus longue parce que je suis gentil. Le chiffrement du disque vous protège contre la perte de données lorsqu'un disque est volé et que la clé n'est pas volée avec. De tels exemples peuvent être, comme le dit Gilles, des sauvegardes volées, mais peuvent également se trouver dans des ordinateurs portables en déplacement ou être éliminés des disques durs pour empêcher des tentatives significatives de récupération des données de vos disques mis hors service.
Le chiffrement du disque ne fait pas grand-chose pour vous aider lorsque vous assemblez la clé et le disque, car la sécurité repose sur la clé et si la clé peut être interceptée, les données peuvent être déchiffrées. La clé et le disque sont toujours à proximité par nécessité lorsque le système d'exploitation est allumé et utilise le disque (chaque lecture nécessite cette clé), donc toute personne à proximité qui peut raisonnablement intercepter la clé devrait pouvoir lire les données. Bien sûr, vous devez être en mesure de récupérer la clé pour effectuer tout type d'attaque, il est donc légèrement plus difficile que de simplement copier un disque dur (mais pas beaucoup). Donc, fondamentalement, oui, vous avez raison.
Cependant, c'est toujours une bonne idée de protéger vos disques pour minimiser la perte potentielle de données par des choses comme le vol et l'élimination des disques. Vous ne savez pas quoi ni comment Amazon fait pour détruire ces disques, donc si vous avez des informations précieuses de quelque sorte que ce soit, les faire chiffrer est une excellente idée.
Alors à quoi ça sert vraiment? Juste pour dire que les données sont "cryptées"?
C'est en fait un facteur possible. Comme je l'ai dit, il y a des avantages tangibles à crypter des données qui ne sont pas tout à fait ceux que vous attendez, mais qui existent toujours. Cela dit, j'ai eu des exigences des clients que les données soient chiffrées sur le serveur dans un scénario similaire à un point de marketing (nous chiffrons vos données). Je pense qu'il y a là un défi éducatif pour les agents de sécurité.
Quelques points à retenir:
Ne négligez pas le problème de la fuite de vos données, délibérément ou non, par des tiers, même des gros comme Amazon.
Lorsque vous utilisez S3 SSE toute personne disposant des informations d'identification IAM appropriées peut lire et/ou écrire vos objets S3, tout comme si vous n'utilisiez pas SSE. À première vue, cela ressemble au seul avantage supplémentaire est que les données sont protégées contre les situations où quelqu'un a accès à S3 de manière hors ligne, comme les lecteurs de disque ou les sauvegardes (ce que je doute qu'AWS fait, il est beaucoup plus probable qu'ils dépendent uniquement de la réplication). Cependant, je pense que vous avez besoin pour le comparer à l'alternative pour obtenir les vrais avantages:
Deux composants sont nécessaires pour le chiffrement côté client avec S3: une clé de chiffrement et des informations d'identification IAM pour l'authentification et l'autorisation. Lorsque vous utilisez le chiffrement côté serveur, vous n'avez besoin que des informations d'identification IAM.
Lorsque vous utilisez le chiffrement côté client, vous devez distribuer la clé de chiffrement à toutes les machines qui ont un accès en lecture et/ou en écriture aux données chiffrées sur S3. Dans les deux cas, vous devez également distribuer les informations d'identification IAM.
Si vos machines sont compromises, votre clé de chiffrement est compromise. Vous pouvez invalider les informations d'identification IAM dès que vous avez connaissance de l'effraction, et si vous utilisez des rôles IAM ou des informations d'identification IAM temporaires, l'attaquant n'a accès à vos données que tant qu'il contrôle la machine (ce qui est déjà assez mauvais, mais peut-être pas la fin du monde, vous devez également penser à ce qui se passera ensuite). Avec le chiffrement côté client, l'attaquant aura votre clé de chiffrement et toutes les données chiffrées avec la clé de chiffrement compromise doivent être rechiffrées. Avec le chiffrement côté serveur, vous n'aurez pas à rechiffrer vos données, car ni vous ni l'attaquant n'aura la clé de chiffrement.
Même si vous n'avez pas d'interruption, il y a des situations où votre clé de chiffrement peut être compromise, si un ordinateur portable est perdu ou volé, si quelqu'un qui ne sait pas mieux l'envoie par courrier électronique à quelqu'un, ou si quelqu'un quitte et vous ne peut pas être entièrement sûr qu'ils n'ont pas pris les choses avec eux. À ce stade, votre clé de chiffrement est compromise et vous devriez probablement rechiffrer toutes vos données. Cela peut représenter beaucoup de travail. Avec le chiffrement côté serveur, tout ce que vous avez à faire est d'invalider les informations d'identification IAM et d'en émettre de nouvelles.
Il existe probablement des moyens d'atténuer les problèmes de chiffrement côté client que j'ai mentionnés ci-dessus, mais pour moi, cela ressemble à utiliser SSE avec S3 a moins d'inconvénients que de le gérer vous-même.
Enfin, il y a la question de la sécurité de laisser AWS gérer vos clés de chiffrement:
Selon AWS, le système gérant les clés de chiffrement est distinct de S3, avec l'intention que si quelqu'un s'introduit dans S3 de l'extérieur, il n'obtiendra pas vos données car il n'aura pas les clés de chiffrement. S'ils pénètrent uniquement dans le système de gestion des clés (qui n'est probablement pas directement accessible de l'extérieur de toute façon), ils n'auront pas vos données car ils n'y ont pas accès sur S3. Ils doivent pénétrer dans les deux S3 et le système de gestion des clés pour accéder à vos données.
S'ils pénètrent à la place dans le centre de données physique, ils peuvent avoir accès à la fois au système de gestion des clés et à S3 en même temps, mais la question est de savoir si cela facilite ou non les choses. Je pense que tout d'abord, nous devons faire confiance à AWS pour mettre en place des mesures de sécurité appropriées pour empêcher les gens d'entrer dans leurs centres de données, et deuxièmement, pour obtenir les clés du système de gestion des clés, vous devez faire plus que tirez simplement sur certains lecteurs de disque. Pour autant que je sache, AWS ne publie pas exactement comment le système de gestion des clés est protégé, plus que de dire qu'il est protégé par plusieurs couches de sécurité. C'est de la spéculation, mais le chiffrement du disque en fait probablement partie.
Comme beaucoup d'entre vous l'ont mentionné, cela vous donne en effet un niveau de sécurité supplémentaire (vous vous souvenez des couches?) Si les disques sont perdus ou accessibles d'une manière ou d'une autre. Mais je trouve incroyable que personne n'ait encore mentionné de certifications de conformité à la sécurité.
Je connais. Certains d'entre vous lisant ceci pourraient déjà penser "Les certifications sont des conneries". Eh bien ... ils peuvent l'être. Mais quand ils sont faits correctement, ils peuvent assurer certaines fonctionnalités importantes et ils sont vraiment très importants dans le monde de l'entreprise. Surtout pour les fournisseurs d'IaaS où leurs employés doivent avoir un faible niveau d'accès à toutes vos données et code pour fournir le service.
Ainsi, la menace ici n'est pas qu'AWS ait accès aux données (ils l'ont) mais un employé AWS particulier ayant accès aux données.
Je ne connais pas tous les programmes répertoriés ici pour sûr. Mais je suis sûr que certains d'entre eux nécessitent la séparation des fonctions . Cela signifierait qu'AWS devait convaincre un auditeur externe qu'il implémentait correctement la séparation des tâches lorsque les fonctionnalités de sécurité l'exigeaient. Dans ce cas particulier, cela signifierait que les gars AWS qui ont accès aux données chiffrées n'ont jamais accès aux clés de chiffrement, et les gars qui peuvent avoir accès aux clés de chiffrement, n'ont jamais accès aux données .
Alors oui, vous devez déjà faire confiance à AWS avec les clés et les données, mais ces certifications sont censées vous assurer qu'elles contrôlent qui (à l'intérieur de l'entreprise) a accès à quoi. Un niveau de confiance supplémentaire qui est également une grande partie de la sécurité.
D'autre part, les clients AWS qui souhaitent également être certifiés en auront également besoin pour se conformer au cryptage des données au repos . Cela ne peut être valable que s'ils fournissent également l'assurance que les clés sont correctement stockées et gérées. Avec cette fonctionnalité et les certifications AWS, ils peuvent déléguer cela à AWS.
Vous pouvez également être protégé contre une intrusion dans les disques de S3 - dites (avec humour) que le disque sur lequel les données S3 ont été stockées est également un lecteur de démarrage pour une fenêtre fonctionnelle XP box, et quelqu'un s'introduit dans la machine XP (pas physiquement - via un hack). Ils ont alors tous les fichiers sur la machine, mais les vôtres sont cryptés avec des clés stockées sur une autre boîte, donc tous les voleurs get est des déchets numériques.
Peut-être que la probabilité que quelqu'un pénètre dans un réseau S3 soit faible, mais je suis du côté des autres affiches et je parie que les clés sont derrière un autre mur. De plus, ils utilisent probablement des clés différentes pour chaque compte.
Donc, même si ce n'est pas une tonne de sécurité, il est là. Dropbox a une carte géo-dupliquée pour son magasin, donc je ne vois pas comment ils pourraient chiffrer avec des clés différentes pour chaque compte.
Comme d'autres réponses impliquent en grande partie que la fonctionnalité est presque inutile, vous devez regarder la vue d'ensemble des meilleures pratiques et réglementations en matière de sécurité de l'information pour comprendre pourquoi elle existe.
Les interprétations actuelles des lois américaines sur la confidentialité (par exemple HIPAA, PCI) exigent que toutes les données client soient cryptées au repos. Si vous pensez que les données stockées sur Amazon devraient être exemptées de cette exigence, essayez d'expliquer votre raisonnement à votre conseiller juridique d'entreprise. Bonne chance avec ça. Les règles sont universelles et s'appliquent aussi bien à un disque dur dans un ordinateur portable qu'à une grappe de disques dans un centre de données "sécurisé".
Bien que le vol des employés d'Amazon puisse être une source de préoccupation pour certains, le principal argument de vente de la fonctionnalité est de protéger les entreprises contre le non-respect des meilleures pratiques et réglementations applicables qui peuvent nécessiter le chiffrement des données au repos.