• Home
  • About
    • Ahmed DAMMAK photo

      Ahmed DAMMAK

      Full Stack Developer

    • Learn More
    • Twitter
    • LinkedIn
    • Github
  • All Posts
  • All Tags
  • Projects

DevoxxFR 2019 - Comment déployer un produit sur un cloud sécurisé ?

19 Apr 2019

Reading time ~3 minutes

Talk de Nicolas Cothereau et Guillaume Attal de Thales Factory.

Abstract

Quand on parle de Thales, on pense surveillance maritime, automatisation de lignes de métro, satellites …, mais rarement agilité ou DevOps. Pionnier de l’innovation technologique dans de nombreux domaines, Thales a créé la Digital Factory afin d’accélérer la transformation digitale du groupe et tester de nouvelles méthodes de travail. Nous y réalisons ces mêmes projets industriels et explorons de nouveaux marchés (gestion de flottes de drone, smart cities, …), dans une logique d’équipes auto-organisées et autonomes, responsables de l’ensemble du Delivery. Au travers de l’exemple d’un de nos projets, nous allons partager avec vous comment nous travaillons au sein de Thales Digital Factory : • déployer de façon continue des apps sur un cloud public qui répondent aux besoins de véritables users tout en respectant les contraintes de sécurité d’un grand groupe industriel, • mettre en place des pratiques de dev de nos différentes squads afin que performance et qualité soient au rendez-vous en production

Notes

La sécurisation des applications est un enjeux.

Organisé par 15 équipes autonomes : - PO - DEV - UI / UX - Devons Sécurité partner ==> rattaché à la sécurité

Pourquoi cloud public ? - Simplicité / rapidité pour créer des resources qui correspondent aux besoin (OPS) - Passage à l’échelle - Couverture géographique

Contraintes : - Exposé sur Internet - Sécurisation - Confiance envers le fournisseur

Cloud + agile ==> Les développeurs qui ont le pouvoirs

Les Datas sont les informations les plus importantes

46% des applications contiennent des failles critiques

OWASP :communauté qui liste des failles critiques

Plateforme sécurité : - Web Application firewall - VNP - Multi Facteur authentication - Traffic monitoring

Analyse des risques : les 4 piliers - Disponibilité - Intégrité - Confidentialité - Traçabilité ==> tous les stackholders + dev sont présents dans ce meeting.

On évalues les risques sur 2 axes : - la probabilité d’occurence - L’impact ==> On transforme ces risques en US ==> Rajouter les risques dans le backlog ==> Le PO est responsable sur la sécurité comme les IT

4 environnements : - Local - DEV - QA - PROD

Peer review entre équipe - DAST / SAST : outils automatiques - Test de pénétrations

SAST : - Static application security testing - Analyse du code source - Feedback rapide sur les erreurs reliées à la sécurité - Performant - Couteux pour la mise en place / configuration des rules - Permet de valider les différentes surfaces d’attaques - Entrée des users - WS API - 90% des API ont du code mort - Système de fichier - BDD - Vérifie des dépendances

DAST : Dynamic aplication Security Testing - trouver les vulnérabilités sur un code qui tourne (le role du hacker) - Tester la config du serveur

Il faut avoir les 2 outils : DAST & SAST

Misconfiguration - Dans le cas d’une mauvaise configuration - Utilisation des comptes par défaut - Port ouverts - Patch de sécurité non appliqué - Reverse proxy

XSS : Cross type scripting - attaque le navigateur des users

=> La sécurité ne se limite pas aux outils

Les tests de pénétrations - Red team & Blue team - Bleu : - sécurise l’application - Monitore l’application - Red Team - Attaquant qui essaie de casser l’application - Broken Authentication - Use Multi factor authentification - Ban - Bug bounty - On paye un entreprise extérieure qui est payé à chaque vulnérabilité trouvée - Extérieur pour avoir un oeil externe sur ce qui est fait

La sécurité s’adapte à l’agilité - création de la valeur - Adapter la sécurité au besoins - Sécurité outillée - La sécurité tout au long du projet - responsabilisation des équipes - Test & learn



DevoxxFRmeet-upconferencescloudsecurityjava