Pour la première fois depuis 2019, le « plus grand salon mondial des développeurs et de l’ingénierie » était de retour en personne, cette fois à Oakland en février : DeveloperWeek 2023 ! Environ 2000 participants, conférenciers et exposants se sont réunis face à face pour se rencontrer et parler de l’état de l’industrie du logiciel. Les gens sont venus du monde entier pour participer à cet événement de plus de 15 pistes qui couvrait tout, de la conception d’applications et d’API aux principes fondamentaux du déploiement de Kubernetes et Terraform, et essentiellement tout le reste. J’ai également pu donner une conférence sur l’état des environnements de développement cloud, dont j’ai déjà parlé ici.
Il y avait un fil conducteur autour de la cybersécurité dans toutes les pistes. Alors que la sécurité devient de plus en plus une priorité pour l’entreprise, il n’est pas surprenant de voir tant de discussions sur la sécurisation de vos données et de vos applications. Voici quelques faits saillants de certaines des sessions centrées sur la sécurité de DeveloperWeek 2023.
Sécuriser vos applications et API
Sécurisez vos API
Il y a beaucoup de choses que vous pourriez couvrir sur la sécurité des applications, mais un sujet particulier est apparu dans plusieurs discussions, la sécurité des API. Il y a eu deux discussions sur cette question à partir de perspectives légèrement différentes, et je pense que les deux approches valent la peine d’être examinées, donc je les mets en évidence ici.
La première session était une approche holistique de Farshad Abasi, fondateur et PDG de Sécurité avancée, dans son exposé « Designing Secure API and Microservices-Based Applications ». Il a expliqué l’histoire de l’architecture orientée services. Nous pensons aux « API Web » lorsque nous pensons aux interfaces de programmation d’applications, mais les API existent depuis très longtemps. Il a parlé de la transformation chez IBM, qui est passée de milliers d’applications indépendantes, réinventant toutes la roue pour reconnaître qu’il y avait de multiples services qui se chevauchaient sous-jacents à chaque application et commencer à déployer des services adressables.
Farshad a partagé qu’à cette époque, les solutions lourdes comme SAML et SOAP fonctionnaient bien derrière les pare-feu, mais bientôt, l’essor des applications Web et des réseaux ouverts a fait de HTTP et JSON les nouvelles normes. Avec ce changement, nous avons perdu le bénéfice de l’entrée unique dans la « zone de confiance » où les applications monolithiques et l’architecture orientée services, les déploiements SOA s’exécutaient. L’exécution de microservices sécurisés signifie que nous ne pouvons faire confiance à personne et que nous devons nous authentifier tout au long de chaque demande.
Au cœur de sa session, il a expliqué comment les passerelles API doivent agir comme un point d’entrée unique dans votre application, vous offrant un service isolé pour gérer à la fois l’authentification et l’autorisation. Ces deux emplois sont liés, mais il a passé du temps à expliquer la différence.
Autorisation vs authentification
Pour faciliter la conceptualisation, il a suggéré de penser à l’exemple réel d’un videur dans une boîte de nuit chic. Lorsque vous arrivez pour la première fois, le videur vous demande votre pièce d’identité, normalement un document délivré par le gouvernement, comme un permis de conduire ou un passeport. À ce stade, l’authenticité de la pièce d’identité est examinée pour s’assurer qu’elle est légitime et qu’il ne s’agit pas d’un faux document. Le contenu est également normalement confirmé, parfois par le videur qui vous pose des questions et vérifie les réponses. Il s’agit du processus d’authentification, souvent abrégé en AuthN.
Une fois que le videur a confirmé que vous êtes bien celui que vous prétendez être, il s’assure que vous êtes censé être là en consultant la liste des invités. Si votre nom est sur la liste, alors vous êtes autorisé à entrer. C’est le processus d’autorisation, abrégé en AuthZ.
Les passerelles API peuvent aider à la fois avec AuthN et AuthZ en examinant les demandes d’authenticité et en vérifiant les signatures ou les certificats corrects, puis en consultant les contrôles d’accès pour s’assurer que seules les bonnes demandes passent. Ce n’est pas parce que vous avez un ID valide que vous avez un accès complet à toutes les bases de données et serveurs.
Cette approche suppose que vous commencez avec Zero Trust à l’esprit, en accordant le moins de privilèges possible pour permettre l’exécution du travail. Farshad a conclu son discours en parlant de l’importance de l’exploitation forestière, y compris la surveillance et l’examen constants. Plus tôt vous prendrez en compte la façon dont vous allez gérer AuthN, AuthZ, les autorisations et la journalisation, plus votre application sera sécurisée lorsque vous la déplacerez vers la production.
Sécurité des API et OWASP
Penser à la sécurité des API dès le début du processus de conception est une excellente idée, mais il peut être difficile de savoir par où commencer lorsqu’il s’agit d’un système existant ou hérité où vous souhaitez mettre à jour la sécurité. C’est là que l’approche de Colin Domoney, Chief Technology Evangelist chez 42Crunch, prend tout son sens. Dans sa session « Tout ce que vous devez savoir sur la sécurité des API », il nous a présenté le Top 10 des API OWASP. Bien qu’il y ait quelques croisements avec le projet de sensibilisation à la norme OWASP Top 10, le Top 10 des API se concentre sur les vulnérabilités et les risques de sécurité uniques. que l’API apporte.
Colin nous a présenté la liste, et les vulnérabilités en jeu ont ensuite partagé des histoires d’horreur de l’industrie qui ont mis en évidence ce qui peut mal tourner. Dans l’une des histoires les plus amusantes, une microbrasserie a oublié de verrouiller les identifiants de test qui permettent aux utilisateurs d’obtenir des jetons de bière illimités. Dans un autre exemple, plus répandu, un plugin WordPress a donné des droits d’administrateur complets du site à tout utilisateur qui savait comment accéder au panneau de contrôle du plugin via la manipulation d’URL – un bon rappel pour ne toujours accorder que les moindres privilèges par défaut.
Mise à l’échelle en toute sécurité, même lorsque vos applications sont attaquées
Dans son discours « Your Apps Are Under Attack », Cory Gideon Manager Consultant chez Sogeti USA, n’a pas perdu de temps pour arriver au point que la sécurité est difficile et demande du travail. Bien qu’il puisse être tentant de penser que vous ne pouvez acheter qu’un seul produit pour vous rendre inviolable, la réalité est qu’aucun fournisseur ne peut tenir une telle promesse. Cela est dû en partie au rythme de l’évolution des menaces combiné à la complexité et à la taille de nos applications. Il a également partagé quelques statistiques qui donnent à réfléchir :
- 36 % des développeurs interrogés ont attribué la priorité au respect des délais pour expliquer pourquoi le code contient encore des vulnérabilités
- 33 % ont admis ne pas savoir ce qui rend leur code vulnérable
- 30 % ont déclaré que leur formation interne à la sécurité pourrait être améliorée avec des exemples concrets et concrets.
- 30 % ont déclaré que leur plus grande préoccupation concernant la mise en œuvre d’un codage sécurisé concernait les vulnérabilités introduites par leurs collègues.
Quand quelque chose ne va pas, de nombreuses équipes déclenchent simplement ce lanceur de blâme.
Heureusement, Cory a partagé de nombreuses bonnes pratiques simples et des outils open source qui peuvent nous aider à travailler de manière plus sécurisée tout en respectant nos délais. Cela commence par la sécurisation de nos politiques de mot de passe. Il a partagé un projet appelé changeme qui peut détecter les informations d’identification par défaut et de porte dérobée dans n’importe quel système. Il a également exhorté les équipes à revoir leurs piles pour les protocoles et les stratégies de cryptage obsolètes, car ils deviennent obsolètes pour une raison.
En se concentrant sur les points d’accès, il a déclaré qu’il était important de comprendre que les attaquants avaient deux tâches essentielles, 1) entrer et 2) sortir. Si vous pouvez perturber l’un ou l’autre, vous pouvez gagner du temps pour agir. C’est là que les jetons de miel seraient également utiles.
Il y a fondamentalement trop de bonnes suggestions à énumérer ici, mais heureusement, Cory a partagé que l’OWASP a déjà expliqué tout cela dans sa série CheatSheet, que vous devriez consulter.
Les derniers points qu’il a soulevés concernaient ChatGPT et certaines des façons potentielles dont il modifie déjà la sécurité. Cory pense que les attaquants demandent déjà à ChatGPT de les aider et nous devrions l’être aussi si nous voulons continuer dans le combat. Vers la fin, il a partagé l’une de mes citations préférées de tout l’événement :
ChatGPT ne prendra pas votre travail. Un développeur qui sait utiliser ChatGPT le fera.
Au-delà de la simple sécurisation de l’architecture de votre application, les développeurs doivent également se soucier des problèmes lorsque vous déployez, puis essayez de faire évoluer votre application. C’était le sujet même que Kerim Satirli, défenseur principal des développeurs chez HashiCorp, a abordé dans son discours « Scaling Security when Deploying Globally ». Au cœur de son discours, Kerim nous a dit que « la sécurité est un sport d’équipe » qui nous oblige tous à automatiser autant que possible et à éduquer tout le monde sur les meilleures pratiques.
Il a partagé que 10% des entreprises disent toujours utiliser l’accès root pour des choses quotidiennes. Bien que la plupart d’entre nous sachent que nous ne devrions pas faire cela, c’est à nous tous de nous assurer que tout le monde le sait. Une autre chose que nous devons améliorer est Zero Trust. Kerim nous encourage à considérer la politique d’accès par défaut comme « refuser », donc « en cas de coupure de courant, toutes les portes restent verrouillées ».
Un autre sujet qu’il a abordé était le verrouillage de régions inutiles. Par exemple, si vous avez toute votre infrastructure dans la zone AWS us-east-2, il n’y a aucune raison de la laisser ouverte aux demandes de ap-east-1 ou eu-central-2pour n’en choisir qu’un couple au hasard.
Il a également passé du temps à énumérer les avantages des secrets dynamiques de courte durée. Les meilleurs secrets sont ceux qui ne sont jamais partagés ; de cette façon, ils ne peuvent jamais être codés en dur, ce que nous, ici chez GitGuardian, souhaitons moins qu’il ne se produise.
Sécuriser vos données
Bien que la sécurisation du code et de vos environnements soit certainement un élément important d’une posture de sécurité mature, si vous faites preuve de négligence avec vos données, vous êtes tout aussi vulnérable à la catastrophe.
Dans leur session « Don’t DIY PII. Five Data Privacy Challenges and How to Solve Them », l’équipe de Skyflow, Sean Falconer, responsable des relations avec les développeurs, et Manish Ahluwalia, responsable de la technologie, ont partagé que l’une des principales raisons pour lesquelles une grande les entreprises ont vu tant de violations, c’est parce qu’elles détiennent tant d’informations d’identification personnelle des clients, PII. Ceci est extrêmement précieux pour les mauvais acteurs. Une fois qu’un attaquant a suffisamment de points de données, il peut lancer des attaques de harponnage ou, pire, voler l’identité du client.
Ils ont résumé 5 défis en matière de confidentialité des données que vous devez prendre en compte lorsque vous traitez avec des PII :
1. Stockage sécurisé : Savoir où se trouvent vos PII a le bon cryptage.
2. Contrôles d’accès : Savoir qui a accès…