Cyberattaques alimentées par l'IA : Comment détecter, prévenir et se défendre contre les menaces intelligentes

Lire la suite
Nous utilisons l'intelligence artificielle pour les traductions de sites et, bien que nous nous efforcions d'être précis, il se peut que les traductions ne soient pas toujours exactes à 100 %. Nous vous remercions de votre compréhension.

Meilleure pratique de configuration AWS S3 : Activer le versionnage des buckets pour la récupération des données

par OPSWAT
Partager cet article

Nous avons déjà expliqué comment l'utilisation de listes de contrôle permet d'éviter les erreurs de configuration du stockage en nuage, une pratique utile pour améliorer la protection des données. Lorsque vous pensez à la protection des données, vous pensez probablement à la prévention de l'accès et de l'exposition non autorisés, mais la protection des données comprend également la prévention et la récupération de la suppression et de l'écrasement accidentels des données.

L'une des principales erreurs de configuration d'AWS S3 consiste à ne pas activer le " bucket versioning ", sans quoi les entreprises risquent de ne pas pouvoir récupérer les objets et les données supprimés accidentellement. AWS S3 est conçu pour assurer une disponibilité et une durabilité des objets supérieures à 99 % dans plusieurs zones de disponibilité, de sorte que les stratégies de récupération des données devraient se concentrer davantage sur la suppression accidentelle.

Le "Bucket versioning " est une méthode de stockage de plusieurs versions d'un objet dans le même "bucket", permettant aux organisations de sauvegarder et de restaurer n'importe quelle version de n'importe quel objet stocké dans ses "buckets". Une fois que le versionnage du panier est activé, Amazon stocke toutes les versions d'un objet avec un identifiant unique, même s'il reçoit plusieurs demandes d'écriture simultanément. Si une organisation supprime un objet, Amazon insère un marqueur de suppression, au lieu de supprimer définitivement l'objet. Si une organisation écrase un objet, ce nouvel objet devient la nouvelle version. Dans les deux cas, une organisation peut facilement revenir à une version antérieure de ces objets supprimés et écrasés.

Par défaut, les buckets ne sont pas versionnés. Une fois que le versionnage est activé, il ne peut pas revenir à l'état non versionné, mais il peut être suspendu. Une fois activé, le versionnage s'applique à tous les objets du panier, et une fois suspendu, il continue à stocker les objets précédemment versionnés, mais n'ajoute pas de nouvelles versions.

La configuration d'un seau non versionné nécessite la modification de la sous-ressource de version par défaut, qui stocke une configuration de version vide, qui se présente comme suit :

<VersioningConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
</VersioningConfiguration>


L'activation du versionnage des seaux nécessite la mise à jour de la configuration du versionnage, comme suit :

<VersioningConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
 <Status>Enabled</Status>
</VersioningConfiguration>


Pour suspendre le versionnage des seaux, il faut modifier la configuration du versionnage, comme suit :

<VersioningConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
 <Status>Suspended</Status>
</VersioningConfiguration>


Il est également possible de configurer le versionnage d'un godet via la console AWS S3 en modifiant les propriétés d'un godet.

Une fois que le versionnage des seaux est activé, les organisations peuvent ajouter une couche de sécurité supplémentaire en exigeant une authentification multifactorielle (MFA) avant qu'un objet puisse être supprimé. Les entreprises peuvent également utiliser un verrou d'objet pour empêcher l'écrasement des objets, dans le cas où les données doivent être conservées indéfiniment. La seule raison pour laquelle une organisation peut vouloir s'interroger sur l'opportunité d'activer le versionnage des seaux est qu'il y a des coûts de stockage associés à chaque objet stocké, mais les organisations peuvent gérer ces coûts en gérant le cycle de vie de leur stockage.

Éviter les erreurs de configuration courantes avec OPSWAT

Lorsqu'il s'agit d'erreurs de configuration courantes, telles que l'activation du versionnage des bucket, les organisations devraient utiliser des listes de contrôle pour s'assurer qu'elles mettent en œuvre les meilleures pratiques. L'automatisation de ce processus à l'aide de la technologie permet d'éviter les erreurs manuelles coûteuses en temps et en argent.

MetaDefender Storage Security améliore sa solution de sécurité pour le stockage en nuage avec une liste de contrôle de sécurité intégrée, afin que les professionnels de la cybersécurité puissent s'assurer que le stockage en nuage de leur organisation n'est pas mal configuré lorsqu'il est approvisionné, ce qui inclut les étapes de développement et de production du stockage en nuage.

L'activation du versionnage des seaux est un élément important de la liste de contrôle de MetaDefender Storage Security , mais ce n'est pas le seul. Dans les prochains blogs, nous explorerons d'autres erreurs de configuration majeures pour la protection des données au repos, notamment le chiffrement côté serveur et la journalisation des accès aux seaux.

Contactez un expert en cybersécurité à l'adresse OPSWAT pour en savoir plus.

Lire le blog précédent de cette série :

Restez à jour avec OPSWAT!

Inscrivez-vous dès aujourd'hui pour recevoir les dernières mises à jour de l'entreprise, de l'entreprise, des histoires, des informations sur les événements, et plus encore.