🌨️ Nouveau service de stockage à froid chez OVH Cloud | Actus DevOps Mai 2023

cchaudier · Mai 25, 2023, 7:08

Quelles sont les dernières nouveautés dans le monde du cloud et du DevOps en ce mois de Mai ?

Comme à notre habitude nous voilà de retour avec l’Actus DevOps mensuel, pour t’aider dans ta veille.

Aujourd’hui, je suis avec @René et on parle de :
Un vague de froid dans le stockage OVH
De nouvelles puces
Paris sous l’eau
Fuite de données

#RadioDevOps est le podcast dédié à notre mouvement issu de la communauté des #CompagnonsDuDevOps. Radio DevOps est disponible dans toutes les applications de podcast.

N’hésites pas à réagir à ces nouvelles et à donner ton point de vue en commentaire.

Article de blog : https://lydra.fr/nouveau-service-de-stockage-a-froid-chez-ovh-cloud-actus-devops-mai-2023

Découvre les podcasteurs :
https://lydra.fr/ea-3-le-podcasteur-christophe/
https://lydra.fr/ea-6-le-podcasteur-rene/

Lydra · Mai 25, 2023, 7:09

CDuv · Septembre 24, 2023, 12:33

Concernant la fuite de données volontaire pour “sauvegarder la base de données” évoquée dans ce podcast (à 42min41s) et le fait de prévenir l’éditeur/développeur du service de la présence d’une faille.

Je comprends qu’un chercheur a besoin de pouvoir prouver à l’éditeur/développeur qu’il a accès aux données (si c’est ce que permet la faille qu’il clame avoir découvert) : une des façons est donc de faire un petit export et de l’envoyer aux développeurs. Mais ce faisant il commet un délit (crime ?).

Je propose de laisser dans vos bases de données un jeu de données dédié uniquement à pouvoir prouver qu’une fuite est possible, par exemple : un utilisateur bidon, désactivé et ayant une chaîne de texte aléatoire dans un champ non visible publiquement (adresse e-mail, nom réel de la personne, notes, etc.).

L’attaquant qui veut prouver qu’il a réussit à accéder la base de données a juste à fournir cette chaîne, sans exfiltrer de vraies informations.

cchaudier · Septembre 24, 2023, 6:51

Je ne pense pas que l’on est besoin d’exfiltrer les données pour prouver que l’on est tombé sur une fail de securité.

Le simple fait de décrire comment on à fait est plus important.
Non seulement le Dev peut tester le processus, mais en plus il peu le corrigé.

Pour le moment je ne vois pas de raison valable d’exfiltrer les données.

En fait tant que la faille n’est pas connu publiquement et que la BDD n’est pas exfiltré elle peut encore être considéré comme sûr.
Par contre si la BDD est exfiltré cela veux dire que l’éditeur n’a plus la main sur la copie et elle peut fuiter, être vendu etc. Donc elle n’est plus sûr.