Si votre nouveau stagiaire en informatique suggère d’installer un serveur Web public sur le serveur de fichiers central, peut-être devriez-vous envisager de le mettre à la porte.
Si, à la place, il décide de déposer sur votre serveur Web les rapports issus de vos jobs d’entrepôt de données critiques, alors n’hésitez plus, virez-le.
Dans le Cloud, tout ne va pas toujours pour le mieux dans le meilleur des mondes, car des services tels qu’Amazon Simple Storage Service (S3) assument souvent plusieurs rôles qui se chevauchent dans une pile d’applications, et ils sont toujours à un clic d’exposer vos fichiers sensibles en ligne.
Aujourd’hui, les services de stockage dans le cloud sont plus qu’un simple « endroit pour conserver un fichier », ils servent souvent d’entrées et sorties à des chaînes de processus plus élaborées. La conséquence de tout ceci est la recrudescence récente de fuites de données de grande ampleur émanant de compartiments S3.
Présentation du compartiment S3
S3 est un des services clés d’AWS. Au niveau du concept, ce service est comme un serveur de fichiers de capacité infinie situé sur un site distant ou sur un serveur FTP auquel vous vous connectez par Internet.
Toutefois, S3 présente plusieurs différences fondamentales qu’il est important de comprendre : si vous ne maîtrisez pas le sujet, vous commettrez des erreurs qui conduiront à des configurations non sécurisées.
S3 est organisé autour de concepts de compartiments et d’objets et non de serveurs contenant des fichiers.
Les compartiments constituent la ressource S3 la plus élevée de l’organisation et ont toujours un nom DNS adressable. Exemple : http://MyCompanyBucket.s3.amazonaws.com
Ceci pourrait vous induire en erreur et vous amener à penser qu’un compartiment est comme un serveur, dans lequel vous pouvez créer plusieurs hiérarchies dans un dossier partagé pour chacun des groupes de votre organisation devant disposer d’un accès.
Laissez-moi vous expliquer :
- le coût est le même que vous créiez un compartiment ou que vous en créiez une douzaine
- Par défaut, vous êtes limité à 100 compartiments mais il suffit d’envoyer une demande d’assistance pour en obtenir davantage.
- Au niveau performances, il n’y a pas de différence entre accéder à 100 fichiers dans un compartiment ou à 1 fichier dans 100 compartiments différents.
En gardant ces éléments en tête, nous allons voler un concept aux professeurs d’informatique : le Principe de responsabilité unique.
Sur un réseau, un serveur de fichiers est une ressource générale couramment utilisée par de nombreux services de l’entreprise pour effectuer tous types de tâches.
S3 vous permet de dédier un compartiment à chaque application, groupe ou même utilisateur individuel. Pour des raisons de sécurité (et pour protéger votre santé mentale en tant qu’administrateur système), vous devez faire en sorte que l’utilisation de ce compartiment soit alignée le plus près possible sur une tâche unique, et lui soit dédiée.
Un nombre élevé d’incidents non-intentionnels d’exposition de données sur S3 semblent avoir été causés par des compartiments S3 publiquement accessibles (sites Web) qui étaient également utilisés (probablement par accident) pour le stockage d’informations sensibles.
Barre latérale : un signe d’avertissement figure souvent dans la dénomination du compartiment. Si vous choisissez des noms génériques comme « mycompany » ou « data-store », c’est que vous cherchez les problèmes. Dans l’idéal, vous devez mettre en place une convention de dénomination telle que : companyname-production/staging/development-applicationname
Stratégies de compartiment
Les stratégies sont les structures de droit de niveau supérieur des compartiments. Elles définissent :
- Qui peut accéder à un compartiment (quels utilisateurs/principaux)
- Comment ils peuvent y accéder (http uniquement, à l’aide de MFA)
- D’où ils peuvent y accéder (cloud privé virtuel, IP spécifique)
Les stratégies sont définies en blocs de JSON que vous pouvez soit écrire à la main soit avec le Générateur de stratégies AWS – https://awspolicygen.s3.amazonaws.com/policygen.html.
Avantage n°1 de l’organisation des compartiments en rôles étroitement définis : vos stratégies de compartiment seront considérablement plus simples puisque vous n’aurez pas à tenter d’élucider les conflits de déclarations de stratégie, ni même à lire du JSON (jusqu’à 20 ko !) pour essayer d’identifier les implications d’une modification.
Exemple de stratégie de compartiment
{
"Version": "2012-10-17",
"Id": "S3PolicyId1",
"Statement": [
{
"Sid": "IPAllow",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::examplebucket/*",
"Condition": {
"IpAddress": {"aws:SourceIp": "54.240.143.0/24"},
"NotIpAddress": {"aws:SourceIp": "54.240.143.188/32"}
}
}
]
}
Des compartiments étroits sont synonymes de stratégies plus simples, qui limitent quant à elles le risque d’attribuer accidentellement des droits trop importants aux utilisateurs – et de créer une fuite de données involontaire.
Considérez les stratégies de compartiment comme des règles définissant la façon dont les données doivent être traitées.
Stratégies IAM dans S3
Les stratégies IAM d’identité et d’accès, pour leur part, déterminent les droits d’un utilisateur/groupe pour une ressource dans AWS (et pas seulement dans S3).
Vous pouvez appliquer des stratégies IAM et de compartiment simultanément : les tentatives d’accès calculeront le moindre privilège issu de la combinaison des deux stratégies et agiront en conséquence.
Pour en savoir plus : IAM Policies and Bucket Policies and ACLs! Oh, My!
Points de terminaison d’un VPC dans S3
Un outil puissant mais souvent insuffisamment utilisé pour protéger les services AWS permet de diviser les applications en différents groupes séparés au niveau logique dans un cloud privé virtuel (VPC).
Au lieu de se contenter d’affecter un compartiment à un usage particulier, un VPC est un ensemble d’Amazon Web Services (S3 compris) séparés au niveau logique qui peuvent être ceinturés pour plus de sécurité.
La plupart des fuites de données importantes qui ont impliqué des groupes utilisant S3 n’étaient PAS liées à un site Web. Les organisations utilisent différents outils AWS comme RedShift et Quicksite pour procéder à l’analyse de quantités massives de données (potentiellement) sensibles : analyses, rapports et données brutes ne devant pas être placées sur un réseau public.
L’outil adéquat pour opérer cette séparation est le cloud privé virtuel (VPC) d’AWS. Avec VPC, vous pouvez définir un ensemble de services qui n’auront pas la possibilité de se connecter à l’Internet général et seront uniquement accessibles via une connexion VPN (IPSEC) au VPC.
Considérez le VPC connecté au VPN comme une portion séparée de votre réseau interne – et des ressources du VPC telles que S3 ne sont pas adressables publiquement :
- un robot qui analyserait les compartiments ouverts ne pourra pas les voir.
- Votre nouveau spécialiste des données ne peut pas laisser un compartiment accessible au public par accident en essayant de télécharger un rapport.
- Les personnes qui utilisent les services au quotidien n’ont pas à se demander si leurs actions entraîneront le chaos et la destruction.
Activer la journalisation de S3
Par défaut, S3 ne gère pas de journaux d’accès pour les objets (fichiers) d’un compartiment. Au niveau de chaque compartiment, vous pouvez autoriser les journaux d’accès à écrire dans un autre compartiment S3.
http://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html
Le passage en revue régulier des accès peut vous apporter de précieuses informations sur les accès éventuels à vos données depuis un emplacement inconnu ou, dans le cas d’une fuite de données, sur la façon et le moment où l’exfiltration s’est produite.
S3 conserve des journaux bruts dans le compartiment de journalisation où vous pouvez procéder à leur analyse syntaxique au moyen de différents outils sources tels que :
Plus récemment, AWS Athena a été lancé. Il s’agit d’un nouveau service qui vous permet d’exécuter directement des requêtes SQL sur des sources de données structurées de type JSON, CSV et sur des fichiers journaux conservés dans S3.
Conclusion
AWS S3 est un service puissant et particulièrement utile qui renforce les capacités des services informatiques et groupes d’applications. Correctement administré, il peut constituer un outil sûr et efficace pour stocker les données et servir de base à des applications plus complexes.
Étapes à suivre pour que vos données restent protégées sur AWS S3 :
- Déterminez lesquels de vos compartiments S3 sont ouverts à l’Internet public
- Divisez vos compartiments S3 en en affectant un par application ou module
- Séparez les problèmes avec des points de terminaison VPC S3
- Journalisez tout
Comment mieux structurer la sécurité d’AWS S3
Contents
Si votre nouveau stagiaire en informatique suggère d’installer un serveur Web public sur le serveur de fichiers central, peut-être devriez-vous envisager de le mettre à la porte.
Si, à la place, il décide de déposer sur votre serveur Web les rapports issus de vos jobs d’entrepôt de données critiques, alors n’hésitez plus, virez-le.
Dans le Cloud, tout ne va pas toujours pour le mieux dans le meilleur des mondes, car des services tels qu’Amazon Simple Storage Service (S3) assument souvent plusieurs rôles qui se chevauchent dans une pile d’applications, et ils sont toujours à un clic d’exposer vos fichiers sensibles en ligne.
Aujourd’hui, les services de stockage dans le cloud sont plus qu’un simple « endroit pour conserver un fichier », ils servent souvent d’entrées et sorties à des chaînes de processus plus élaborées. La conséquence de tout ceci est la recrudescence récente de fuites de données de grande ampleur émanant de compartiments S3.
Présentation du compartiment S3
S3 est un des services clés d’AWS. Au niveau du concept, ce service est comme un serveur de fichiers de capacité infinie situé sur un site distant ou sur un serveur FTP auquel vous vous connectez par Internet.
Toutefois, S3 présente plusieurs différences fondamentales qu’il est important de comprendre : si vous ne maîtrisez pas le sujet, vous commettrez des erreurs qui conduiront à des configurations non sécurisées.
S3 est organisé autour de concepts de compartiments et d’objets et non de serveurs contenant des fichiers.
Les compartiments constituent la ressource S3 la plus élevée de l’organisation et ont toujours un nom DNS adressable. Exemple : http://MyCompanyBucket.s3.amazonaws.com
Ceci pourrait vous induire en erreur et vous amener à penser qu’un compartiment est comme un serveur, dans lequel vous pouvez créer plusieurs hiérarchies dans un dossier partagé pour chacun des groupes de votre organisation devant disposer d’un accès.
Laissez-moi vous expliquer :
En gardant ces éléments en tête, nous allons voler un concept aux professeurs d’informatique : le Principe de responsabilité unique.
Sur un réseau, un serveur de fichiers est une ressource générale couramment utilisée par de nombreux services de l’entreprise pour effectuer tous types de tâches.
S3 vous permet de dédier un compartiment à chaque application, groupe ou même utilisateur individuel. Pour des raisons de sécurité (et pour protéger votre santé mentale en tant qu’administrateur système), vous devez faire en sorte que l’utilisation de ce compartiment soit alignée le plus près possible sur une tâche unique, et lui soit dédiée.
Un nombre élevé d’incidents non-intentionnels d’exposition de données sur S3 semblent avoir été causés par des compartiments S3 publiquement accessibles (sites Web) qui étaient également utilisés (probablement par accident) pour le stockage d’informations sensibles.
Barre latérale : un signe d’avertissement figure souvent dans la dénomination du compartiment. Si vous choisissez des noms génériques comme « mycompany » ou « data-store », c’est que vous cherchez les problèmes. Dans l’idéal, vous devez mettre en place une convention de dénomination telle que :
companyname-production/staging/development-applicationnameStratégies de compartiment
Les stratégies sont les structures de droit de niveau supérieur des compartiments. Elles définissent :
Les stratégies sont définies en blocs de JSON que vous pouvez soit écrire à la main soit avec le Générateur de stratégies AWS – https://awspolicygen.s3.amazonaws.com/policygen.html.
Avantage n°1 de l’organisation des compartiments en rôles étroitement définis : vos stratégies de compartiment seront considérablement plus simples puisque vous n’aurez pas à tenter d’élucider les conflits de déclarations de stratégie, ni même à lire du JSON (jusqu’à 20 ko !) pour essayer d’identifier les implications d’une modification.
Exemple de stratégie de compartiment
{"Version": "2012-10-17",
"Id": "S3PolicyId1",
"Statement": [
{
"Sid": "IPAllow",
"Effect": "Allow",
"Principal": "*",
"Action": "s3:*",
"Resource": "arn:aws:s3:::examplebucket/*",
"Condition": {
"IpAddress": {"aws:SourceIp": "54.240.143.0/24"},
"NotIpAddress": {"aws:SourceIp": "54.240.143.188/32"}
}
}
]
}
Des compartiments étroits sont synonymes de stratégies plus simples, qui limitent quant à elles le risque d’attribuer accidentellement des droits trop importants aux utilisateurs – et de créer une fuite de données involontaire.
Considérez les stratégies de compartiment comme des règles définissant la façon dont les données doivent être traitées.
Stratégies IAM dans S3
Les stratégies IAM d’identité et d’accès, pour leur part, déterminent les droits d’un utilisateur/groupe pour une ressource dans AWS (et pas seulement dans S3).
Vous pouvez appliquer des stratégies IAM et de compartiment simultanément : les tentatives d’accès calculeront le moindre privilège issu de la combinaison des deux stratégies et agiront en conséquence.
Pour en savoir plus : IAM Policies and Bucket Policies and ACLs! Oh, My!
Points de terminaison d’un VPC dans S3
Un outil puissant mais souvent insuffisamment utilisé pour protéger les services AWS permet de diviser les applications en différents groupes séparés au niveau logique dans un cloud privé virtuel (VPC).
Au lieu de se contenter d’affecter un compartiment à un usage particulier, un VPC est un ensemble d’Amazon Web Services (S3 compris) séparés au niveau logique qui peuvent être ceinturés pour plus de sécurité.
La plupart des fuites de données importantes qui ont impliqué des groupes utilisant S3 n’étaient PAS liées à un site Web. Les organisations utilisent différents outils AWS comme RedShift et Quicksite pour procéder à l’analyse de quantités massives de données (potentiellement) sensibles : analyses, rapports et données brutes ne devant pas être placées sur un réseau public.
L’outil adéquat pour opérer cette séparation est le cloud privé virtuel (VPC) d’AWS. Avec VPC, vous pouvez définir un ensemble de services qui n’auront pas la possibilité de se connecter à l’Internet général et seront uniquement accessibles via une connexion VPN (IPSEC) au VPC.
Considérez le VPC connecté au VPN comme une portion séparée de votre réseau interne – et des ressources du VPC telles que S3 ne sont pas adressables publiquement :
Activer la journalisation de S3
Par défaut, S3 ne gère pas de journaux d’accès pour les objets (fichiers) d’un compartiment. Au niveau de chaque compartiment, vous pouvez autoriser les journaux d’accès à écrire dans un autre compartiment S3.
http://docs.aws.amazon.com/AmazonS3/latest/dev/ServerLogs.html
Le passage en revue régulier des accès peut vous apporter de précieuses informations sur les accès éventuels à vos données depuis un emplacement inconnu ou, dans le cas d’une fuite de données, sur la façon et le moment où l’exfiltration s’est produite.
S3 conserve des journaux bruts dans le compartiment de journalisation où vous pouvez procéder à leur analyse syntaxique au moyen de différents outils sources tels que :
Plus récemment, AWS Athena a été lancé. Il s’agit d’un nouveau service qui vous permet d’exécuter directement des requêtes SQL sur des sources de données structurées de type JSON, CSV et sur des fichiers journaux conservés dans S3.
Conclusion
AWS S3 est un service puissant et particulièrement utile qui renforce les capacités des services informatiques et groupes d’applications. Correctement administré, il peut constituer un outil sûr et efficace pour stocker les données et servir de base à des applications plus complexes.
Étapes à suivre pour que vos données restent protégées sur AWS S3 :
Que dois-je faire maintenant ?
Vous trouverez ci-dessous trois solutions pour poursuivre vos efforts visant à réduire les risques liés aux données dans votre entreprise:
Planifiez une démonstration avec nous pour voir Varonis en action. Nous personnaliserons la session en fonction des besoins de votre organisation en matière de sécurité des données et répondrons à vos questions.
Consultez un exemple de notre évaluation des risques liés aux données et découvrez les risques qui pourraient subsister dans votre environnement. Cette évaluation est gratuite et vous montre clairement comment procéder à une remédiation automatisée.
Suivez-nous sur LinkedIn, YouTube et X (Twitter) for pour obtenir des informations sur tous les aspects de la sécurité des données, y compris la DSPM, la détection des menaces, la sécurité de l’IA et plus encore.
Essayez Varonis gratuitement.
Se déploie en quelques minutes.
Keep reading
Varonis tackles hundreds of use cases, making it the ultimate platform to stop data breaches and ensure compliance.