Sécurité et DevOps

Je réouvre mon blog par nécessité. En effet, j'ai plein de choses à dire, mais pas vraiment le courage de le faire. Néanmoins, quand je peux joindre l'utile à l'agréable, pourquoi ne pas en profiter ?

Mon copain Nicolas Ledez travaille chez MyCozyCloud. Faisant parti des projets libres que je connais et que je trouve intéressant, travaillant dans le monde moderne, je lui ai posé la question suivante :

About security in devops, how do u manage it? s.t. about automation & tests & high skills? (À propos de la sécurité dans le DevOps, comment gérez-vous cela ? Est-ce quelque chose autour de l'automatisation, des tests et des compétences ?).

Nicolas a répondu sur son blog. Ne voulant pas perdre une occasion de donner un peu d'oxygène à ce blog, voici mon commentaire...

Il n'y a pas d'opposition entre le DevOps et la sécurité, bien au contraire. S'il y a une convergence possible entre un développeur et un opérationnel, il n'y a rien qui empêche une convergence entre la sécurité et un DevOps (DevOpSec) ou directement de l'OpSec.

Petit rappel sur le DevOps :

DevOps est un mouvement culturel et professionel

Adam Jacob (opscode), fondateur de Chef...

Compétences

Fini les cv surgonflés et le développeur spécialisé en php qui sort d'école d'ingénieur. Test technique obligatoire en entrée avec la maîtrise minimum d'un langage et de linux. Le développeur n'est plus juste présent pour te proposer de pisser de la ligne de code mais rentre en pleine et complète action du début de la création, que nous appelions autrefois analyse, jusqu'à l'implémentation de l'ihm, tout en testant et maîtrisant l'intégralité de sa production. Il sait donc par conséquent gérer la mémoire de son application, ce qu'est une pile tcp/ip, que tu ne codes pas tes variables en dur, etc.

Tests

Fini la production où tu ne testes rien et tu livres sans savoir réellement ce que les choses vont donner. La journée tu codes, la nuit tu testes et tu sais réellement si ton code va passer la charge. Tous les frameworks actuels dignes de ce nom sont livrés avec des bibliothèques de test, il faut les implémenter. Si je fais court, même si ça ne résume pas tout, tu as les tests unitaires, tests de non régression, tests de charge, tests de vulnérabilité... Bien sûr, le développeur peut lancer le test à n'importe quel moment pour s'assurer que son code tient la route. Comme cela peut prendre parfois plusieurs heures, il peut être intéressant de lancer cela en parallèle d'autre chose.

Supervision

C'est là où les SOCs prennent tout leur sens. Je ne te parle pas ici de logger des événéments de sécurité qui sont inclus par défaut dans tous les systèmes d'exploitation, mais bien d'intégrer ses logs à ton application de façon intelligente. Par exemple, tu mesures le temps moyen de l'intégralité de tes requêtes sql et tu fais un curseur par type de requête. Si le temps d'exécution est plus long que celui habituel, c'est très probablement que tu as une tentative d'injection sql. Voici d'autres éléments que tu peux regarder : erreur 500, core dump, csrf failure, xss attempts, login failures, password resets... Bien sûr, la liste est loin d'être exhaustive, il faut travailler au plus près de l'application pour savoir ce qui est normal et ce qui ne l'est pas, mais ça te donne une bonne idée de ce que l'on peut faire.

D'ailleurs, dans cet ordre d'idée, tu n'as plus que deux types de patch vs bug : réparer immédiatement ou réparer avant la fin de la semaine.

Automatisation

Tu ne peux bien sûr pas attendre 2 semaines qu'on te monte une ligne, qu'on te prépare une machine virtuelle, qu'on te configure un vhost. C'est le principe de l'immédiateté, non pas en terme de consommation, mais en terme de mise à disposition. Cela signifie qu'un travail préalable d'automatisation de l'infrastructure est indispensable. Tu passes par un portail et 120 secondes plus tard, tu as la vm que tu attendais, avec 45 secondes supplémentaires d'attente ton apache et mysql de configurés dans les dernières versions de patch. L'ensemble de tes environnements sont identiques, tu n'as pas une plate-forme de devéloppement qui ne correspond pas à ta production pour une question de budget, tu peux reproduire absolument ce que tu veux au moindre coût pour t'assurer que ta production tournera comme c'est le cas en développement. C'est aussi pour cela que la virtualisation du réseau et des matériels de sécurité a le vent en poupe, car elle permet(tra) une automatisation complète et une quasi abstraction de la couche d'attente liée à l'infra. Pour cela, il est indispensable que les produits choisis proposent également une cli (command line interface) et pas uniquement une gui (graphical user interface).

La sécurité est donc un service mis à disposition du business.

Si on rentre dans la question de comment doivent gérer les devs/admins :

  • scrum/kanban
  • contrôle de versions
  • build automatisé
  • bugtracking
  • intégration continue
  • tests intégrés
  • déploiement automatisé

Sans oublier, bien sûr, une standardisation des process.

Maintenant, si j'en reviens à un schéma classique d'intégration de la sécurité d'un cycle de vie en 8 étapes que je résume ici :

  1. évaluation de périmètre
  2. analyse de risque
  3. architecture
  4. code
  5. test
  6. infrastructure
  7. run + veille + supervision
  8. décomissionnement

L'étape 1/ et 2/ doit être intégrée dans une phase d'analyse pré-projet qui ne peut être portée par les devops car cela inclus la responsabilité des métiers.

Nous rentrons donc dans le vif (qui peut éventuellement boucler) du sujet qui renvoie aux compétences suscitées : 3 => compétences
4 => compétences + tests
5 => tests
6 => automatisation + tests
7 => supervision

Et pour le 8, un petit coup d'automatisation ne devrait pas faire de mal...

Quelques liens : DevOps the future is here its just not evenly distributed yet
Les types de tests