Stephen Schmidt (Amazon Web Services) "Nous bloquons automatiquement certaines attaques informatiques"

Prévention et gestion des pannes d'AWS, test d'intrusion, recommandations faites aux clients... Le responsable de la sécurité d'Amazon Web Services détaille sa stratégie dans un entretien exclusif.

JDN. Du point de vue des DSI, le cloud public peut sembler peu sécurisé, dans la mesure où les équipes informatiques ne maîtrisent pas l'ensemble de la pile technique. Que répondez-vous à cette remarque ?

Stephen Schmidt. Mon travail chez Amazon consiste à créer de nouveaux moyens pour apporter à nos offres de cloud le même niveau de sécurité que l'on pouvait avoir dans le monde informatique avant le cloud.

Quand nous évoquons la question que vous posez avec les DSI, nous en revenons toujours à la même conclusion : pour sécuriser un système, il faut normalement connaître précisément son architecture, où il est installé, qui y accède, etc. Pour atteindre cet objectif sur un système interne (on-premise), vous devez réaliser un inventaire de vos actifs IT. Ce qui se révèle en général impossible à réaliser, les utilisateurs installant souvent eux-même des logiciels "sous le bureau".

Dans le cloud, au contraire, dans la mesure où tout est automatisé, il ne peut y avoir de briques dissimulées ou non-identifiées. Vous devez nous indiquer exactement l'ensemble de vos opérations, via un appel d'API : l'ajout d'une machine virtuelle, le changement d'un lien réseau... Tous ces éléments sont donc visibles en permanence via notre console pour les équipes de sécurité du client. C'est donc un pouvoir plus important pour la DSI en matière de sécurité. 
 

Quels dispositifs mettez-vous en place pour isoler les machines virtuelles entre elles ?

L'isolation des machines virtuelles est gérée par le biais d'une version modifiée de l'hyperviseur Xen. Nous l'avons adapté avec un objectif principal : la minimisation du logiciel. L'idée étant que l'hyperviseur ne contienne pas de fonctionnalités dépassant sa vocation première. D'abord pour des raisons de performance d'exécution et de consommation de ressources. Mais aussi de sécurité. Pourquoi en effet implémenter des éléments qui ne sont pas utiles, et qui peuvent potentiellement engendrer un risque, en matière de faille par exemple ? 

"L'isolation des machines virtuelles est gérée via une version modifiée de l'hyperviseur Xen"

Les clients sont aussi sensibles à la possibilité de venir contrôler nos infrastructures pour vérifier le niveau d'isolation de nos machines virtuelles. Nous mandatons des tiers pour cela. Et pour les clients les plus sensibles à cet enjeu, nous proposons des instances dédiées. Via un appel d'API, ils ont la possibilité de porter leurs machines virtuelles sur un matériel informatique qu'ils seront les seuls à utiliser. Une direction des systèmes d'information pourra par exemple indiquer qu'elle souhaite 20 machines virtuelles, et qu'elle veut les installer sur un certain nombre de serveurs physiques dédiés.

Que proposez-vous en termes de gestion des accès et des identités ?

Nous proposons un service dans ce domaine, mais nos clients peuvent aussi utiliser leur propre système d'AIM [Identity and Access Management NDLR] pour définir quel utilisateur a quel droit. Si vous disposez d'Active Directory en interne, vous avez la possibilité de faire le lien avec nos infrastructures, sans avoir à redéfinir un référentiel de gestion d'identités pour vos salariés. Quand vos salariés accèdent à notre console d'administration, par exemple pour stocker ou lancer des machines virtuelles, la console pourra utiliser votre Active Directory pour gérer les autorisations et la gestion des identités.

Etes-vous capable de prévenir certaines attaques ?

Nous sommes capables de bloquer certaines attaques de manière automatique. La liste de ces dispositifs n'est pas publique, pour réduire les risques de sécurité. Mais prenez les attaques par force brute pour SSH [utilisées pour déchiffrer un mot de passe ou une clé de cryptage NDLR] permettant de s'introduire sur un serveur. Amazon EC2 est capable de détecter et bloquer ce type d'activité. Mais, il y aurait beaucoup d'autres exemples de tentative d'intrusion que nous pouvons bloquer automatiquement. Pour cela, nous analysons le trafic pour repérer les comportements suspects. Nous indiquons ensuite aux clients les raisons pour lesquelles nous avons bloqué un flux.

Mais nous devons faire extrêmement attention, car nos clients mettent parfois en œuvre des tests d'intrusion. Il est important alors qu'ils nous avertissent à l'avance pour que nous n'appliquions pas ces mesures à l'environnement en question pendant le temps de l'opération, et ainsi ne pas bloquer leur trafic.

Comment pouvez-vous assurer que vos équipes n'accèdent pas aux machines virtuelles de vos clients ?

Nous avons une politique interne très stricte sur les autorisations d'accès à nos centres de données. Chaque équipe technique est allouée à un domaine, Amazon EC2, Amazon S3... Ses membres n'ont le droit d'accéder qu'aux ressources sous-jacentes. Le responsable de chacun de nos salariés devra revalider les droits d'accès de celui-ci en fonction de son domaine précis d'intervention, tous les 30 à 90 jours en fonction de la position hiérarchique. En cas de changement de poste, les droits sont systématiquement révoqués par les responsables.

"Pour plus de sécurité, nous conseillons à nos clients de chiffrer leurs données"

Nous sommes très prudents quant aux droits d'accès que nous donnons à des systèmes contenant des données de clients. Par exemple EC2 dispose d'une infrastructure de syndication. Une part infime de nos salariés ont accès à ce type à de plate-forme, c'est-à-dire seuls ceux qui ont vraiment besoin d'y accéder. Dans la même logique, nous auditons très régulièrement les activités de nos salariés qui, potentiellement, ont la possibilité d'accéder à ces informations. J'ai un vision précise de ce qu'ils ont opéré, et de quand ils se sont logués, dans n'importe quel système contenant des informations de clients. Ces données de traçabilité sont enregistrées et archivées.

Pour renforcer encore l'assurance sur la sécurité des données privées, notamment pour les clients les plus exigeants, nous recommandons de chiffrer les informations. C'est d'ailleurs un service que nous intégrons à notre console AWS, et qui est très facile à mettre en œuvre. Nous proposons d'ailleurs y compris cette possibilité pour les clés de chiffrement, via notre la technologie SafeNet que nous intégrons.

Vous avez récemment indiqué que vous alliez jusqu'à injecter des "armes à feu virtuelles" pour tester la robustesse d'Amazon Web Service. En quoi consiste cette méthode ?

Nous mettons en place des opérations pour tester nos procédures, et s'assurer qu'elles fonctionnent correctement. Nous avons défini un exercice appelé "Game Days" [NDLR journée de jeu]. Dans le domaine de la sécurité, il se traduit par l'injection d'événements dans les journaux de logs, susceptibles d'engendrer des conséquences sérieuses. Il s'agit par exemple de simuler une connexion non-autorisée à un système critique, et d'observer si les actions nécessaires sont bien prises et que les personnes qui doivent réagir le font dans le temps imparti. Pour certains types d'alarme, nous devons répondre en moins de 5 minutes. Il s'agit là de simulations d'événement. Nous ne réalisons pas ces tests sur des systèmes en production.

L'un de vos clients a récemment indiqué avoir observé qu'il vous arrivait régulièrement de mettre hors service des machines virtuelles au bout d'un certain temps (en moyenne au bout de 200 jours)....

Vous évoquez là un cas très particulier. La procédure normale lorsque nous avons un problème sur un matériel supportant les machines virtuelles d'un client, est de l'alerter par mail. Nous lui indiquons qu'il doit abandonner les VM en question dans un certain délai, d'au moins plusieurs jours. Ce nombre de jours varie en fonction de la gravité du problème. Nous faisons notre maximum pour envoyer ce message suffisamment rapidement pour que nos clients puissent s'organiser. La vaste majorité d'entre eux n'ont pas de souci avec cette procédure. Et beaucoup d'autres clients vous dirons que la durée de vie de leurs VM est beaucoup plus longue.
 

"Pour les applications critiques, le mieux est d'opter pour une architecture actif-actif sur deux zones"

Nous avons observé plusieurs pannes de service importantes d'AWS l'année dernière. Comment prévenez-vous ce type d'incident ?

D'abord, prévenir ces pannes de service pour nos clients passe par la manière dont ils conçoivent leur architecture. L'enseignement que nous tirons de ces événements est que nous devons mieux les accompagner, notamment en les aidant à comprendre comment utiliser les options que nous proposons sur la disponibilité.

L'important est notamment de les sensibiliser à notre offre proposant de répartir les systèmes sur plusieurs de nos Availability Zones. Ces zones sont isolées les unes des autres. Pour les systèmes ou sites web critiques qui doivent rester accessibles en permanence, l'idée est d'offrir la possibilité de répliquer sur une autre zone pour gérer la reprise d'activité en cas d'incident, ou mieux encore, de répliquer en mode actif-actif. Ce qui permet, en cas d'indisponibilité sur l'une ou l'autre zone, d'assurer la continuité du service immédiatement.

Les pannes que nous avons pu avoir l'année dernière, comme avec cas avec le répartiteur de charge EC2 Elastic Load Balancer, ont toutes été limitées à une de nos installations, et donc un service particulier sur une zone de disponibilité spécifique. L'incident que nous avons essuyé autour d'Elastic Load Balancer était d'ailleurs dû à une erreur humaine, de l'un de nos ingénieurs. Il a affecté la région AWS des Etats-Unis de l'Est, mais aucune autre n'a été touchée.

Vous disposez pour l'instant d'une région unique en Europe, avec plusieurs zones de disponibilité et datacenters, à Dublin. Avez-vous l'intention d'en ouvrir une autre sur ce continent ?

Nous sommes à l'écoute de nos clients nous demandant d'étendre nos infrastructures. Nous développons de nouvelles régions et zones AWS régulièrement. Nous venons par exemple d'en inaugurer une en Australie, à Sydney. L'Europe est naturellement un marché très important pour nous. Nous interrogeons nos clients pour savoir où il souhaiteraient que nous nous étendions. Mais, n'oublions pas que c'est un chantier important : il faut que l'endroit choisi offre une connectivité Internet de qualité, des infrastructures électriques robustes, avec des prix raisonnables. Il est important, enfin, de trouver un endroit où vous puissiez bâtir des installations écologiques, qui ne détruisent pas l'environnement avec des dispositifs de Green cooling efficaces. Cela contribue aussi à réduire nos coûts.

Biographie professionnelle : Stephen Schmidt est Chief Information Security Officer pour Amazon Web Services. A ce titre, il est en charge de la sécurité des centres de données qui supportent les offres de cloud Amazon Web Services, depuis la couche d'hyperviseur jusqu'aux niveaux les plus bas du datacenter. Stephen Schmidt a précédemment travaillé pour les systèmes d'information des Etats-Unis, ainsi que pour le FBI - où il a notamment été responsable des analyses liées à la détection d'intrusion informatique. Il a aussi travaillé sur les problématiques de revers engineering, virus et malware.