Migration vers le cloud effectuée — que nous reste-t-il à faire côté sécurité ?

La règle est limpide avec la responsabilité partagée : la sécurité *du* cloud incombe au fournisseur, la sécurité *dans* le cloud vous appartient. Vérifiez immédiatement vos security groups : ne laissez jamais les ports 22 (SSH) et 3389 (RDP) ouverts sur 0.0.0.0/0. Autorisez uniquement l'IP fixe de votre entreprise et rendez l'accès à la console impossible sans passer par un VPN.

Deux mois après notre migration, un collègue s'est fait avoir par un phishing sur sa boîte pro. Comme la double authentification n'était pas activée, le hacker est rentré direct dans la console cloud et a effacé les sauvegardes de la base. Le fournisseur nous a répondu à juste titre : "la connexion s'est faite avec des identifiants valides". Résultat : 80 mille TL de rançon payés...

Vouloir couper le budget sécurité, c'est courir tout droit à la catastrophe. C'est exactement comme louer un appart dans une résidence ultra sécurisée avec porte blindée et laisser la porte grande ouverte. Si un voleur rentre, vous n'allez pas engueuler le gardien de l'immeuble.

Deux trucs à faire dès demain matin : 1) Allez sur la console et forcez l'authentification à deux facteurs via appli (évitez le SMS) pour tous les comptes. 2) Supprimez tous les vieux comptes de test et les clés d'API laissées par d'anciens prestataires.

Le fournisseur cloud protège l'intégrité de vos données contre les pannes matérielles, mais si quelqu'un en interne supprime la table clients (par erreur ou malveillance), le cloud verra ça comme un ordre normal, pas une attaque. Il faut absolument une politique de backup immuable stockée sur un compte totalement isolé.

checkez direct vos buckets de stockage c'est là que tout le monde se plante mais les devs laissent l'accès public pour faire des tests et après t'as toute la base clients indexée sur google...

Avec une activité de vente en gros et de distribution, vous gardez pleinement votre statut de responsable de traitement selon la KVKK. Le fait que les données soient dans le cloud n'annule en rien vos obligations légales. Vous devez impérativement conserver les logs d'accès horodatés et inaltérables sur une durée minimale de deux ans.

Vous avez raison.

Il est rare de trouver un texte qui explique les choses aussi clairement.

J'aimerais poser une question. Essayer de faire cela seul est la voie la plus coûteuse.

J'espère que cela vous sera utile.

beau travail. lors de la prise de décision, écrivez aussi le pire scénario, pas seulement le meilleur.

à vtre place, j'irais par cette voie.

Il y a un point qui m'interpelle. Tout point non écrit est un point que les deux parties se rappelleront différemment plus tard.

C'est confirmé par l'expérience.

J'ai vécu la même chose.

Ce qui est écrit correspond exactement à ce que nous avons vécu. Plus il est difficile de revenir sur une décision plus il faut la prendre lentement.

Si vous avez des questions, écrivez-moi, je répondrai au mieux.

Exact. Si le chemin de notification est long, la notification n'arrive pas ; une notification manquante signifie un événement détecté tardivement.

C'est mon avis, je ne l'écris pas comme une vérité absolue.

Cette approche a un coût, dont on ne parle pas. La plupart des pertes de temps s'accumulent sur les tâches en attente de validation.

Si vous avez des questions, écrivez-moi, je répondrai au mieux.

Je suis d'accord. bref ce qui nous faisait perdre le plus de temps c'était l'absence de clarté sur qui prenait les décisions.

La plupart des incidents ne viennent pas d'une faille, mais d'un mot de passe divulgué. Corrigez-moi si je me trompe.

Beau travail. Si vous obtenez trois réponses différentes sur un sujet la question est mal posée.