En quoi enquêter sur un incident dans un environnement cloud diffère-t-il du sur site ?

Le plan de contrôle devient la scène de crime principale. Au lieu du disque et de la mémoire d'un hôte fixe, votre meilleure preuve est le journal d'audit des API : quelle identité a appelé quoi, depuis où, avec quels identifiants. Les instances sont éphémères, donc faites un instantané avant de terminer. L'identité est le périmètre, donc tracez les rôles, les identifiants temporaires et les chemins d'élévation de privilèges plutôt que la position réseau, et attendez-vous à ce que la responsabilité partagée limite une partie de la télémétrie.

Le plus gros changement, c'est que l'incident se passe en réalité dans le plan de contrôle. Sur site, j'irais chercher la mémoire et le disque d'un hôte. Dans le cloud, ma première extraction c'est le journal d'audit des API, parce qu'il me dit quelle identité a appelé quelle action depuis quelle adresse source, et si elle a utilisé une clé à longue durée de vie ou un rôle assumé avec des identifiants temporaires. L'éphémérité est la deuxième différence : une instance peut avoir disparu avant que je l'atteigne, donc ma première action de confinement est de prendre un instantané du volume et de capturer la mémoire si l'outillage le permet, puis d'isoler avec un security group restrictif plutôt que de terminer, parce que terminer détruit mes preuves. Troisièmement, les chemins d'élévation sont différents. Je poursuis des politiques de confiance de rôles, des politiques d'identité trop permissives et l'accès aux métadonnées d'instance plutôt qu'un administrateur de domaine. Et je reste honnête sur la frontière : sous l'hyperviseur je n'ai aucune télémétrie, donc s'il m'en faut je dois la demander par une procédure formelle auprès du fournisseur, ce qui est lent, et je planifie en conséquence.