Comment Atlassian applique les meilleures pratiques dans son infrastructure cloud

Presque tous nos comptes AWS sont analysés toutes les heures et les résultats sont communiqués à l'équipe de sécurité. Pour permettre à nos développeurs d’agir rapidement et de supprimer la sécurité en tant que contrôleur d’accès, nous ne nous sommes pas arrêtés là. Au lieu de cela, nous avons intégré Cloud One - Conformity à notre pipeline de vulnérabilités qui classe les tickets Jira pour toutes les découvertes que nous découvrons grâce à ces analyses. Nos développeurs vivent et respirent Jira jour après jour. Il est donc beaucoup plus naturel pour eux de faire apparaître ces informations ici que d'avoir à rechercher ces résultats dans un outil tiers ou d'avoir besoin de sécurité en tant qu'intermédiaire.

Quiconque a déjà essayé de déployer un scanner de sécurité au sein d'une organisation sait qu'il n'est jamais défini et oublié. Au lieu de cela, ils nécessitent un réglage précis pour s’assurer qu’ils ne produisent que des résultats significatifs. Chaque environnement d’entreprise est différent et, en particulier à grande échelle, il existe des cas Edge que les scanners ne prévoiraient pas. Par exemple, notre PaaS interne applique un ensemble de bonnes pratiques qui ont été développées en collaboration avec l’équipe de sécurité. Certaines des configurations qui en découlent sont sécurisées dans ce contexte, mais le scanner continuera à en rendre compte, car elles ne le seraient généralement pas. Par conséquent, nous avons passé du temps à affiner l’ensemble de règles qui nous intéressent.

Dans notre première itération, nous avons décidé de nous concentrer sur nos comptes AWS les plus graves. Ces comptes contiennent les données de nos clients ou gèrent notre infrastructure, par exemple notre CI/CD. En outre, nous avons limité l’ensemble initial de règles à celles que nous considérons comme étant de haute gravité. Nous avons ensuite passé du temps à travailler en étroite collaboration avec les équipes qui possèdent ces comptes AWS importants pour nous assurer que toutes les conclusions fournissent un avantage significatif en matière de sécurité. Sur la base de ces commentaires, nous avons ajusté la configuration de nos règles pour qu’elles s’intègrent parfaitement à notre organisation. Ce n'est que pour ce sous-ensemble de comptes et de règles que nous créons des tickets Jira, car nous avons vérifié la qualité de ces résultats.

La prochaine itération a déjà commencé et étend la portée des comptes ayant des tickets Jira créés, ainsi que d'autres règles en cours d'examen. Finalement, tous nos comptes AWS seront soumis à notre SLA de sécurité et chaque vérification aura été examinée et configurée selon les spécificités de notre environnement.

Nous continuons également à travailler en étroite collaboration avec l’équipe Conformité, qui répond à nos commentaires et corrige rapidement les bugs que nous découvrons dans leur produit. Ils sont excellents pour inclure nos demandes de fonctionnalités dans leur feuille de route et nous tiennent toujours informés lorsque le travail commence sur tout ce qui nous intéresse. De cette manière, nous continuons à augmenter la valeur que leur service nous apporte, ce qui se traduit directement par une posture de sécurité toujours croissante.

Lorsque le chercheur en sécurité a récemment « plan de travail » présenté lors de la conférence DEF CON 27, la communauté a appris à quel point les volumes EBS publics vulnérables peuvent quitter une entreprise, rappelant à tout le monde que non seulement les compartiments S3 peuvent être rendus publics et contiennent des informations sensibles. Naturellement, nous avons étudié notre propre environnement pour de tels volumes publics. Étant donné que Conformity scannait déjà activement tous nos comptes, nous avons pu mener une enquête rapide qui a donné une image complète de tous les volumes publics et nous avons pu rapidement confirmer qu’aucun d’entre eux ne contenait d’informations sensibles. En outre, nous serons avertis de tous les volumes futurs rendus publics et pourrons nous assurer que nous n’exposons aucune information sensible par leur intermédiaire.

En tant qu’effet secondaire utile, ces analyses fournissent une fonction forçant les équipes à se rendre dans leurs propres environnements et à nettoyer toutes les ressources obsolètes restantes des expériences de développement. Atlassian permet à nos développeurs d'itérer rapidement, d'essayer de nouvelles fonctionnalités et d'innover sur nos services. En tant qu’équipe de sécurité, nous sommes responsables de nous assurer que ces expériences se déroulent dans un environnement approprié et d’une manière qui ne met pas en danger les données des clients. Une partie de cette responsabilité consiste à s’assurer que les ressources inutilisées sont nettoyées et que Conformity nous aide à y parvenir. Nous informons les développeurs des ressources dont les configurations ne sont pas sécurisées et, parfois, les développeurs réalisent qu’ils n’ont plus besoin de ces ressources et les supprimons.