La violation de données de Capital One sera considérée comme un échec pour le Cloud public. En fait, c’est tout sauf.
Les nouvelles de la dernière violation de données majeure affectant les clients de Capital One sont dans tous les médias, et étant donné que Capital One a été un utilisateur pionnier d’AWS pour ses applications de production, il peut y avoir une hypothèse naturelle que le cloud public a rendu cette violation possible. Cependant, si vous regardez plus attentivement les détails publiés de cette violation, il s’avère que le Cloud public n’était pas du tout un contributeur. Cela semble être une violation qui aurait été possible quel que soit l’endroit où les applications s’exécutaient et où les données étaient stockées.
Deux facteurs se sont réunis pour rendre cette atteinte à la protection des données possible ; l’intention criminelle et l’exposition au contenu. Alors que le premier est impossible à éradiquer complètement dans une organisation, le second peut être minimisé par l’ingénierie et les opérations, Cloud ou non. Il a été rapporté qu’un employé d’une entreprise de technologie de Seattle a été arrêté et accusé de fraude et d’abus informatiques. Nous devrions supposer que dans toute grande organisation, il y a quelqu’un qui réfléchit à la façon de profiter personnellement de sa position. Autrement dit, il est dangereux de supposer une intention positive de la part de tous les membres d’un grand groupe.
C’est une triste vérité que les initiés sont une proportion importante des coupables dans toutes les industries, donc tous les processus devraient être conçus dans cet esprit et nous devrions utiliser les principes de conception du moindre privilège et de la séparation des tâches pour rendre l’exécution des mauvaises choses plus difficile. L’objectif de conception devrait être que toutes les données critiques soient chiffrées pendant le transfert et au repos, et que les clés de chiffrement soient conservées en toute sécurité par un petit nombre de personnes de confiance. L’application qui permet aux gens d’accéder aux données pour exécuter leurs tâches, serait capable de décrypter ces données aux fins du travail – mais pas plus. Ce n’est pas toujours bien fait, ni toujours bien vérifié.
L’accès au contenu semble avoir été effectué en compromettant un serveur. Cela permettait d’accéder aux informations d’identification IAM, qui pouvaient ensuite être utilisées pour accéder aux données – via des appels d’API se faisant passer pour une application valide. Tout cela est possible quel que soit l’endroit où le serveur était hébergé et où se trouvaient les périphériques de données, qu’il s’agisse d’un Cloud public ou d’un centre de données interne.
Une conception correcte est importante, quels que soient les services utilisés ou l’endroit où ces services sont exécutés. Il est possible de construire de mauvaises choses avec de bons outils, autant qu’il est possible de construire de mauvaises choses avec de mauvais outils. Dans ce cas, nous ne devrions pas blâmer les outils.
À certains égards, le fait que l’environnement ait été pris en charge sur AWS signifiait qu’il était plus facile de diagnostiquer les problèmes – comme la journalisation ne peut pas être désactivée, les preuves de l’attaque sont restées là, et une fois que la détection et la correction se produisaient ont été rapides.
Dans l’ensemble, cela devrait être considéré comme positif pour le Cloud public, mais je soupçonne qu’il faudra un certain temps avant que ce soit l’impression générale.
