Étendre la propriété de la sécurité à l'ensemble de votre organisation

Clarke : (00:05)
Megan, merci beaucoup d'être ici aujourd'hui.

Megan : (00:07)
Avec plaisir.

Clarke : (00:08)
Pourriez-vous nous raconter un peu votre parcours et la façon dont vous êtes arrivée chez AWS ?

Megan : (00:13)
J'ai occupé différentes fonctions dans le domaine de la sécurité pendant plus de 15 ans, en commençant par celle de spécialiste de la sécurité des réseaux dans un hôpital. Ensuite, j'ai rejoint un détaillant mondial basé à Seattle et j'ai occupé différentes fonctions d'ingénierie et d'architecture de sécurité. Par la suite, nous sommes devenus clients d'AWS en 2014 et j'ai contribué à définir la stratégie de sécurité du cloud et à mettre en œuvre les contrôles de sécurité dans ce domaine. Plus tard, j'ai rejoint Slalom et j'ai fait partie de son équipe de développement et d'opérations de sécurité. J'ai aidé des clients de toute l'Amérique du Nord à faire la même chose : définir une stratégie de sécurité du cloud et déployer des contrôles de sécurité. Ensuite, j'ai rejoint AWS en qualité d'Architecte de solutions d'entreprise pour Pacific Northwest, puis l'équipe des spécialistes de la sécurité.

Clarke : (01:02)
C'est génial.

Megan : (01:03)
Je suis donc ici depuis environ quatre ans. Oui.

Clarke : (01:04)
Parfait.

Megan : (01:04)
Merci.

Clarke : (01:05)
Vous avez donc commencé, je crois, par une formation en informatique. Qu'est-ce qui vous a attirée dans la sécurité ?

Megan : (01:12)
En fait, c'était intéressant. Au départ, j'avais emprunté la voie de l'ingénierie mécanique et j'ai fait un stage chez Boeing pendant trois étés. J'ai donc pu travailler avec les ingénieurs de l'outillage de la ligne 767-400. Et je leur ai demandé ce qu'ils étudieraient s'ils reprenaient des études maintenant. Et ils m'ont répondu l'informatique. Je me suis donc dit « OK ». Et de manière catégorique, ils ont tous eu la même réponse. Alors j'ai répondu : « D'accord, je vais suivre un cours de sécurité informatique ou d'informatique ». Et j'ai adoré ça. C'était vraiment passionnant. C'était comme résoudre des énigmes.

Clarke : (01:47)
Oui.

Megan : (01:47)
Ensuite, la moitié de la classe a abandonné parce que ça ne leur convenait pas. Et j'ai continué. L'un des cours facultatifs portait sur la sécurité numérique, qui m'a semblé très intéressant. J'ai suivi ce cours et j'ai été passionnée. J'ai trouvé ça très intéressant. C’est juste encore des énigmes à résoudre, en constante évolution. Et donc, oui, j'ai créé IDS comme projet de fin d'études pour mon diplôme en informatique. J'ai créé un petit programme qui analysait les captures de paquets réseau et déterminait les comportements néfastes du réseau. J’aime vraiment ça.

Clarke : (02:21)
C'est génial. Cela vous a menée vers une grande carrière.

Megan : (02:23)
Oui.

Clarke : (02:24)
Donc, vous êtes Architecte principale de solutions de sécurité chez AWS. Qu'est-ce que cela signifie ? Et quelles sont les principales responsabilités liées à votre fonction ?

Megan : (02:33)
J'aide les clients pour tout ce qui touche à la sécurité d'AWS. Je leur donne des conseils sur la façon de poser les fondements, de mettre en place les barrières de protection, de mettre en œuvre les contrôles de sécurité, tout en les aidant à comprendre ce qu'est le modèle d'exploitation pour le cloud. À quoi cela ressemble-t-il ? Je participe également à l'information des clients lors d'événements, d'ateliers de construction, de séances destinées aux créateurs, ainsi que sur le terrain, en interne. Nous disposons de programmes internes où nous organisons des essais sur le terrain, pour les sensibiliser aux différents aspects de la sécurité. Nous les faisons donc passer d'un niveau de sécurité de 100 à 300, afin qu'ils puissent être plus efficaces au cours de leurs conversations avec les clients.

Clarke : (03:20)
Donc, Megan, chez AWS, nous avons une culture de la sécurité très forte et nous avons beaucoup de mécanismes pour veiller à ce qu'elle soit respectée. Avez-vous des mécanismes préférés en particulier ?

Megan : (03:29)
Oui. Donc, l'un des processus dont nous disposons est le sev two. Qui que vous soyez dans l'entreprise, si vous soupçonnez un problème de sécurité, la procédure consiste à créer un dossier, que l'on appelle sev two. De l'autre côté, un ingénieur en sécurité va évaluer s'il s'agit d'un problème ou non, puis prendre le relais. Il n'y a pas de souci s'il ne s'agit pas d'un problème de sécurité. C'est idéal. Et c'est irréprochable. Donc, l'idée est que nous ne voulons pas que quelqu'un se sente inquiet ou intimidé en pensant qu'il existe un problème de sécurité. Nous souhaitons en être informés. Nous voulons y réagir d'une manière adéquate et positive. De plus, nous avons le soutien de la direction, ce qui est vraiment bien. Je pense que bien souvent, à l'occasion d'une formation à la sécurité et lorsque l'on parle avec ses propres dirigeants, on sent que tout le monde y pense de manière positive. Et je pense que cela engendre une culture de la transparence autour de la sécurité, mais aussi une ouverture que je n'ai jamais constatée nulle part auparavant. C'est très appréciable.

Clarke : (04:44)
Oui. Alors, quand vous vous adressez aux différents clients avec lesquels vous traitez à différents niveaux de l'organisation, y a-t-il des domaines particuliers sur lesquels vous les encouragez pour les aider à instaurer leur propre culture de la sécurité ? Encore une fois, le genre de culture de la sécurité irréprochable ?

Megan : (05:01)
Oui. C'est ce que je constate dans plusieurs domaines. J'ai tendance à encourager les clients à envisager le fonctionnement de leurs équipes de sécurité comme une aide à l'entreprise, une aide aux développeurs. Et s'ils contribuent à simplifier les choses, à prendre les mesures adéquates du point de vue de la sécurité et à fluidifier les opérations, s'ils évoluent dans le bon modèle et s'il y a de la transparence autour de ces exigences de sécurité, ils peuvent passer à la vitesse supérieure et tout simplement ne pas se heurter à de nombreux obstacles. Et je pense que cela crée un bel équilibre entre la sécurité et le développement où toutes les forces sont mises en commun. Et puis j'aime vraiment voir ce travail chez les clients. J'ai pu le constater dans quelques cas de clients. Je pense également que c'est un bon moyen d'opérer du côté de la sécurité et du côté du développement, en s'associant et en s'aidant mutuellement.

Clarke : (06:00)
Donc, la sécurité n'est pas le service du « non ». Il tente plutôt d'essayer de les aider et de réussir ?

Megan : (06:05)
Oui, absolument.

Clarke : (06:07)
Du point de vue du leadership client, que peut faire la haute direction d'une entreprise pour favoriser cette culture de la sécurité que nous essayons d'instaurer dans les relations avec les clients ?

Megan : (06:20)
Je pense que c'est très différent des journées traditionnelles, non ? L'équipe de sécurité n'est pas la seule responsable de la sécurité, ce n'est pas possible. Les développeurs doivent en assumer une grande partie. En fait, j'aime guider les clients en leur expliquant qu'il existe le modèle de responsabilité partagée entre AWS et le client, mais qu’on étend ce modèle de tous les différents contrôles de sécurité et aspects de la sécurité du cloud au reste de l’organisation et qu’on le rend transparent pour toute personne qui en assume une certaine responsabilité.

Clarke : (06:53)
Oui.

Megan : (06:53)
Et puis, il faut faire en sorte que ces choses soient faciles à faire et qu’elles soient faites de manière adéquate. Ainsi, l'extension du modèle de responsabilité partagée au sein de votre propre organisation, de manière à ce qu'il soit tangible pour tout le monde, peut s'avérer très efficace.

Clarke : (07:05)
C'est génial. Je suppose que bon nombre de vos clients ont beaucoup moins d'experts en sécurité qu'ils ne le souhaiteraient. Quelles sont les choses qui, selon vous, permettent aux équipes de sécurité d'élargir leur champ d'action et leur influence dans le reste de l'organisation cliente ?

Megan : (07:22)
Je peux en citer quelques-unes. Je pense, tout d'abord, que nous ne trouvons pas toujours le professionnel adéquat pour le poste. Et donc, parfois, cela signifie élargir un peu l'horizon et se dire « Bon, si des membres de l'équipe de la sécurité ne connaissent pas forcément le cloud, mais qu'ils sont intéressés, faites-leur emprunter cette voie ». Et si certains de vos développeurs ou de vos collaborateurs DevOps s'intéressent à la sécurité, sans disposer nécessairement des connaissances nécessaires, faites-leur emprunter cette voie. Assurez-leur une partie de cette formation. Et je pense qu'il existe de nombreux outils pour cela. L'une de mes méthodes favorites consiste à regarder les vidéos re:Invent, re:Inforce précédentes et d'organiser une séance de 30 ou 45 minutes sur les bonnes pratiques fondamentales en matière de sécurité. Il existe de nombreuses vidéos avec des clients qui illustrent parfaitement ce que font les clients, qui nous font sortir des sentiers battus et qui, selon moi, peuvent vraiment nous aider. Par ailleurs, le certificat d'Architecte de solutions AWS associé ou professionnel est un très bon moyen d'acquérir ces concepts fondamentaux. Et puis, bien sûr, la certification de spécialiste en sécurité est excellente.

Clarke : (08:39)
Les 18 derniers mois environ ont été une épreuve pour tout le monde. Nous avons eu la pandémie et plus de personnes travaillant à domicile. La pandémie a-t-elle entraîné une augmentation ou une diminution de l'adoption du cloud ? Que constatez-vous chez les clients ?

Megan : (08:54)
Oui. J'ai vu plusieurs clients importants contraints d’augmenter leur adoption du cloud pour faire face à l'évolution de la situation. Le secteur de la vente en ligne a explosé, parce que les magasins ont dû fermer leurs portes. Et je pense que nous avons vu naître quelques modèles intéressants. Nous en avons tiré des leçons pour d'autres clients, en fonction de la manière dont ils ont mis en place leur sécurité initiale et leur stratégie multicomptes. S'ils étaient en mesure de tirer parti de l'automatisation pour cette situation, ils s'en sont très bien sortis, car ils pouvaient simplement créer plus de comptes et mettre en œuvre l'automatisation. Ils disposaient déjà de l'automatisation nécessaire à l'établissement de ces bases de la sécurité et leurs contrôles étaient à portée de main. En l'absence d'automatisation, nous pouvions bien entendu les aider à en créer et à en mettre en place le plus rapidement possible. Mais si cette opération doit se faire manuellement, c'est un processus lent et fastidieux. Et donc, je pense qu'il convient de s'assurer que tout est… Toutes ces barrières de protection, ainsi que l'automatisation de votre stratégie multicomptes, vont être très importantes. Cela a permis de montrer ce qu'impose le monde réel. Je sais que lorsque j'ai commencé en tant que client d'AWS, nous avions deux équipes de développement qui ne faisaient rien de sérieux. Six mois plus tard, nous comptions 20 équipes de développement, des systèmes étaient en production et tout le monde souhaitait rejoindre la plateforme. J'ai donc appris cette leçon très tôt et je pense que beaucoup de clients ont également dû passer par là.

Clarke : (10:31)
Parce qu'il fallait alors retravailler pour atteindre le niveau de sécurité souhaité.

Megan : (10:35)
Exactement.

Clarke : (10:37)
Donc, un peu sur la même tangente : des équipes de sécurité, des équipes de sécurité au sein des comptes clients. Ce type de sécurité peut-il ouvrir la voie du cloud aux clients ?

Megan : (10:50)
Je pense avoir vu cela chez des clients pour qui la sécurité venait en dernier lieu. Mais ils ne doivent pas forcément adopter cette approche. Je pense que s'ils peuvent implémenter le cadre de sécurité qu'ils ont adopté sur site, prendre des contrôles et les mettre à jour pour le cloud, faire un peu de mappage et mettre en place ces barrières de protection à l'avance, ce sera beaucoup plus simple. Ils vont se préparer au déploiement de personnes. Et si personne ne vous pousse, c'est parfait. Vous pouvez définir une sorte de métrique. Vous pouvez faire en sorte que l'automatisation soit mise en place sans que quelqu'un vienne frapper à la porte pour vous dire « Allez, on y va ». Et je pense aussi que cela nous donne l'occasion, en tant qu'équipe de sécurité, d'être transparents sur les exigences de sécurité, d'aider les développeurs à comprendre la manière dont ils doivent créer et quelles sont les spécifications attendues par l'équipe de sécurité. Et je pense qu'une fois encore, cela revient à rebondir sur la relation entre les développeurs et la sécurité et simplement… Il s'agit d'une relation plus efficace et plus productive qui va permettre de mettre en œuvre les fonctionnalités métier que souhaitent les développeurs.

Clarke : (12:10)
Oui. J'imagine qu'il y a un certain niveau de confiance qui s'établit une fois que vous voyez l'équipe de sécurité s'intéresser au cloud avant vous et qu'en qualité de développeur ou de propriétaire de produit, vous devez vous dire : « Bon, je n'ai vraiment plus d'excuse si l'équipe de sécurité le fait ».

Megan : (12:25)
Exactement. Et je pense que l'une des choses que j'ai vues très bien fonctionner avec les clients, c'est qu'ils expriment leurs exigences de sécurité et qu'ils donnent des exemples, comme un côté Wiki interne de « À quoi ressemble une stratégie d'accès et d'identité sécurisée ? », « Qu'est-ce qu'un groupe de sécurité sécurisé par rapport à un mauvais ? », mais aussi des exemples tangibles. Cela va vraiment très loin. Et voici exactement ce dont il est question. Pas d'étoile d'action par rapport à étoile de ressource pour vos stratégies d'accès, ce genre de choses. L'autre élément est le moment où les équipes de sécurité se rendent disponibles… donc si une équipe de développement devait être bloquée, pour quelque raison que ce soit... Par exemple, si un client éprouve des difficultés avec une exigence de sécurité spécifique, si l'équipe de sécurité s'est rendue disponible aux heures de bureau une fois par semaine, ou d'un canal Slack, cela peut vraiment faciliter tout le processus pour les développeurs. Ils disposent d’une équipe de choix. Bien souvent, ils nouent des liens d'amitié avec ces personnes, ce qui leur évite d'être bloqués pendant 24 heures ou quelque chose de ce genre. Ils peuvent simplement créer une boucle de rétroaction rapide. Et il y aura peut-être aussi un commentaire du genre, « Hé, notre documentation est trop compliquée », ou « Nous devons spécifier quelque chose », ou si nous demandons aux gens de démarrer un agent de sécurité sur un hôte, pourquoi ne pas simplement écrire un script pour eux et le mettre à disposition dans un référentiel de code ?

Clarke : (14:02)
Donc, avec tout ce que vous venez de partager ici, j'entends aussi des compétences dont votre équipe de sécurité moyenne ne dispose peut-être pas. Ainsi, si l'on considère les équipes de sécurité traditionnelles, elles géraient les IDS et les différents services réseau, les systèmes de correctifs, etc., mais vous me dites, et corrigez-moi si je me trompe, que les équipes de sécurité doivent désormais comprendre le fonctionnement des cycles de développement et peut-être même coder elles-mêmes ?

Megan : (14:33)
Oui. Je pense que nous n'avons pas… Selon les antécédents du professionnel de la sécurité, il se peut que vous n'ayez pas de formation de développeur ou de diplôme en informatique, ce qui n'est pas nécessaire, mais je pense qu'un peu de programmation Python n'a jamais fait de mal à personne et que la formation cloud est assez facile à assimiler. Ansible, c'est simplement un fichier de configuration YAML. Et je pense vraiment que le fait de fonctionner comme une équipe de développement, en utilisant les pratiques agiles avec un backlog, un propriétaire de produit qui gère une priorité du point de vue de la sécurité, ne peut être que bénéfique. Tout d'abord, comprendre comment travaillent les développeurs, ce qui est aussi une façon très efficace de travailler. Quand j'étais praticienne, c'était notre façon de procéder, parce que, surtout du point de vue de la sécurité, les choses évoluent tellement vite, tout comme les exigences métier. Tout d'un coup, vous devez augmenter les capacités et changer votre façon de fonctionner. Cela vous aide donc à redéfinir efficacement les priorités à une cadence régulière.

Clarke : (15:39)
Donc presque exécuter la sécurité en tant que service au sein d'une organisation ?

Megan : (15:44)
Effectivement.

Clarke : (15:46)
Parfait. Changeons donc un peu de sujet et concentrons-nous sur certains sujets d'actualité récents. Parlons des rançongiciels. Il ne faut pas chercher bien loin et vous entendrez parler de nombreuses histoires de rançongiciels. Que constatez-vous chez les clients et quels conseils leur donnez-vous en matière de techniques d'atténuation des rançongiciels ?

Megan : (16:11)
Au cours des deux derniers mois, j'ai probablement eu plus de 20 conversations directes avec des clients au sujet de rançongiciels. J'adore avoir ces conversations parce qu'ils vous disent : « Dites, nous souhaitons comprendre ce qu'est la messagerie d'AWS ». Cela me dit simplement qu'ils nous considèrent comme un partenaire, ce qui est formidable. En général, j'établis un top 10 des bonnes pratiques, car il n'existe pas de solution miracle contre les rançongiciels. Vous devez vraiment disposer d'un programme de sécurité solide, de contrôles de sécurité éprouvés, et vous assurer qu'ils sont efficaces. Cependant, il y a incontestablement des domaines clés à couvrir, et nous abordons donc la stratégie multicomptes et, l'accès au moindre privilège. Le seul point sur lequel j'insiste vraiment est le suivant : avez-vous des informations d'identification statiques et durables en matière de gestion de l'information ? Si tel est le cas, il est temps de les examiner à la loupe et de déterminer, en premier lieu, si elles ont encore besoin d'exister. Pouvons-nous procéder à une réorganisation ? Et si elles sont vraiment nécessaires, parce que dans certains cas, pour l'accès hybride, elles sont nécessaires, réduisons au minimum l'accès lié à ces informations d'identification afin qu'elles ne puissent faire que très peu de choses dans l'environnement, puis surveillons quand elles sont utilisées et considérons-les comme un risque. Mettez-les dans le registre des risques. Gardez un œil dessus. Et s'il y a une possibilité de s'en débarrasser à l'avenir, débarrassez-vous-en. C'est généralement l'un des principaux risques que nous constatons et nous voulons nous assurer que nous sommes proactifs pour aider les clients à éviter les mauvaises surprises, pour ainsi dire.

Clarke : (17:44)
Et, d'après ce que j'ai compris, l'atténuation des rançongiciels consiste simplement à assurer assidûment la sécurité de base. Cette évaluation est-elle juste ?

Megan : (17:52)
Tout à fait. L'application de correctifs n'est pas un concept nouveau. Et vous pouvez effectuer cette opération dans AWS de plusieurs façons différentes. Vous pouvez effectuer un remplacement avec un groupe Auto Scaling et relancer vos systèmes à partir de votre pipeline CICD. Vous pouvez utiliser Systems Manager. Systems Manager est un outil mi-opérations, mi-sécurité à ce stade. C'est incroyable ce que l'on peut faire avec. Donc, oui. Il existe beaucoup d'options. Et nous en parlons aussi. Je pense que l'autre question que les clients m'ont posée, et je pense que c'est une bonne conversation à avoir, c'est : « Dites, nous avions l'habitude de faire des sauvegardes Air Gap sur site. On avait littéralement des sauvegardes sur bande que l'on mettait dans un camion Iron Mountain pour que personne ne puisse y toucher. Comment faisons-nous cela chez AWS ? » En fait, tout est une API, donc c'est connecté, mais il y a des manières de procéder. Si vous regardez la sécurité, la limite de sécurité comme le compte AWS, vous pouvez créer un compte séparé et envoyer vos sauvegardes à ce compte. Vous pouvez procéder à l'automatisation avec des mécanismes de type push pull afin de disposer d'un compte de destination pour les sauvegardes. Et puis, un compte séparé où vous effectuez une extraction d'une bonne source connue et où vous pouvez utiliser des éléments comme le bloc d'objets S3, qui fonctionne sur le principe WORM (Write Once Read Many) sur ce compartiment S3, et une sécurité et des contrôles très performants, pour permettre un accès minimisé, même à un nombre réduit d'administrateurs du compte. Et puis avec AWS Backup ou AWS Backup Vault Lock, qui vient d'être annoncé, je pense il y a deux semaines, ou plus récemment, vous pouvez effectuer de la même manière l'opération WORM, appliquée à ce coffre. Et donc, fondamentalement, cela vous empêche d'apporter des modifications à ces sauvegardes après son intervention. Donc, vous ne pouvez rien supprimer. Ainsi, grâce à AWS Backup Vault Lock, vous pouvez définir une stratégie, une stratégie et empêcher toute personne d'y apporter des modifications. Il est donc essentiellement semblable au bloc d'objets S3 dans la mesure où les données y sont stockées et où elles sont inaccessibles pendant un certain temps.

Clarke : (20:05)
D'accord. En plus de certains des outils et des bonnes pratiques que vous avez mentionnés, je n'ai pas entendu parler de la préparation de la réponse aux incidents. Quelle est son importance et que doivent faire les clients dans ce domaine ?

Megan : (20:19)
Lors de ces discussions sur les rançongiciels, je pose toujours cette question aux clients : « Avez-vous fait un exercice de simulation d'un événement de sécurité lié à un rançongiciel ? ». En effet, les exercices sur table sont essentiels. Si vous n'avez jamais travaillé dans le domaine de la réponse aux incidents, cela peut être une situation stressante. L'exercice sur table vous donne l'occasion de travailler sur un grand nombre de problèmes que vous n'avez pas besoin de traiter au cours d'un événement réel lors duquel vous voulez juste être concentré et mener vos enquêtes sans ennui. Avec l'exercice sur table, vous allez passer par cette pratique qui consiste à savoir comment l'événement s'est produit. Avons-nous accès à tous nos comptes AWS pour effectuer les recherches dont nous avons besoin ? Où verrions-nous l'événement ? Est-ce qu'il passerait par notre centre d'opérations de sécurité ? Disposons-nous d'un manuel décrivant toutes les activités que ces personnes doivent mener pour pouvoir apporter une réponse cohérente et des données nécessaires pour prendre ces décisions ? Et puis, faisons-nous appel aux bonnes parties prenantes ? Parce que si nous sommes confrontés à un événement de sécurité, nous devons savoir comment communiquer avec nos clients, avec leurs clients. Cela permet de régler beaucoup de problèmes et notre équipe de professionnels du service peut intervenir et aider les clients à faire de même. Nous l'avons fait à plusieurs reprises et rien ne vaut la pratique, n'est-ce pas ? Et selon moi, dès que nous avons peur d'un certain scénario, on se dit, « Ah oui, la pratique ». Par la suite, ça ne sera plus aussi effrayant. C'est aussi simple que de s'entraîner et de s'améliorer dans un domaine.

Clarke : (21:55)
Vous avez mentionné d'autres parties prenantes. Il ne s'agit donc pas seulement d'un exercice de l'équipe de sécurité ?

Megan : (22:00)
Non, pas du tout.

Clarke : (22:01)
Quelles sont les autres parties prenantes qui devraient prendre part à ces exercices de simulation ?

Megan : (22:06)
Oui. Il est certain que le service juridique est généralement impliqué, ainsi qu'une équipe responsable de la protection de la confidentialité, la direction de la sécurité et, selon le type d'exercice ou d'incident, le service d'assistance, les équipes chargées des applications et du développement, qui nous aideront à savoir si nous devons prendre des mesures d'atténuation, par exemple. Quels en seraient les impacts en aval ?

Clarke : (22:36)
En d'autres termes, tous les niveaux de la hiérarchie d'un client sont-ils impliqués ? Je veux dire, est-ce que le PDG participerait à l'un de ces exercices de simulation ? Ou quels niveaux ? Où cela s'arrête-t-il ?

Megan : (22:50)
Oui. Je pense que c'est également le cas de ceux qui veulent s'impliquer et comprendre le processus, car lorsque vous passez par un événement de sécurité, c'est généralement confidentiel. Vous devez vous assurer que seules les personnes qui doivent l'être sont au courant, afin que la communication se fasse de manière réfléchie. Mais dans le cas d'un exercice, il n'y a aucune raison de ne pas impliquer les personnes qui veulent l'être. Et, si le PDG est intéressé, il faut absolument le faire participer.

Clarke : (23:21)
Génial.

Megan : (23:22)
Tout le monde peut y apprendre quelque chose.

Clarke : (23:24)
Un autre grand sujet d'actualité, sur lequel les clients s'interrogent en permanence, est le concept de confiance zéro. Que signifie pour vous la confiance zéro ?

Megan : (23:34)
Oui. Traditionnellement, pour les contrôles d'accès et de sécurité dans notre environnement, nous nous basions fortement sur le périmètre réseau. Alors qu'aujourd'hui, ce que nous souhaitons, c'est authentifier et autoriser les appels au niveau de la couche d'API. Et donc, ce que cela signifie, c'est que s'il s'agit d'un utilisateur qui accède à notre environnement, ou d'un appel d'API à API, nous souhaitons nous assurer qu'il est authentifié et autorisé à chaque étape pour cette communication réseau.

Clarke : (24:10)
Megan, merci d'avoir été ici aujourd'hui.

Megan : (24:12)
Oui. Merci. C'était avec plaisir.