Introduction – billet n.37.5

Il restait à tirer les leçons de cet événement pour hausser le niveau de sécurité.

Depuis le piratage de ce blog en 2012, lors d’une conférence sur la sécurité informatique où j’étais invité comme conférencier pour parler de mes activités d’expert judiciaire (lire le billet « pwned« ), je me suis intéressé de près aux questions de sécurité informatique. Mon premier réflexe a été de lire tout ce que je pouvais sur internet, et il y a une tonne de références.

Puis je me suis intéressé aux documents de l’ANSSI, référence en la matière, et en particulier à la méthode EBIOS. J’ai commencé par auditer mon périmètre personnel, mes pratiques un peu light et trop confiantes. J’ai ensuite modifié mes habitudes, et en particulier j’ai segmenté mes identités numériques : identité comme blogueur, identité comme professionnel, identité comme expert judiciaire, identité comme conseiller municipal, etc. La compromission d’une boite email de l’une de ces identités numériques ne doit pas impacter les autres. Enfin, j’espère.

Tout ce travail d’analyse a eu comme conséquence de mettre un peu d’ordre dans mes pratiques et hausser un peu mon niveau de sécurité : modification en profondeur de la politique de sécurité des systèmes d’information de mon entreprise, et étapes par étapes, amélioration des procédures et meilleure identification du périmètre de sécurisation. J’ai endossé, petit à petit, la fonction de RSSI, en plus de toutes les autres.

Ma politique en matière de sécurité informatique est assez simple : chaque compte informatique sera un jour piraté, chaque ordinateur sera un jour compromis et chaque utilisateur cliquera un jour sur un lien malicieux. Plutôt que de faire culpabiliser tout le monde sur ces sujets, j’essaye de mettre en place des outils pour anticiper l’intrusion, pour réparer la perte d’un poste de travail ou pour faciliter le redémarrage de l’activité en cas de compromission. Un mode « best effort » pragmatique mais organisé.

J’ai établi la liste des services rendus, à la mode ITIL, la liste des logiciels, la liste des risques, etc. Tout ce travail m’amenait vers une conclusion assez évidente : le logiciel informatisant notre cœur de métier, notre ERP, était agonisant. Il fallait d’urgence mener une opération de remplacement, une opération à cœur ouvert du système d’information.

Billet n.39

————–

Ce récit est basé sur des faits réels, les noms et certains lieux ont été changés.

La sécurité, un travail d’équipe (allégorie)

Introduction – billet n.37

Je ne pensais pas que vous seriez aussi nombreux à suivre cette série de billets « 25 ans dans une startup » et je vous en remercie.

Quand j’ai commencé la série, j’indiquais dans l’introduction que j’avais fait un point professionnel un peu éprouvant. Je n’ai pas encore abordé ce point dans la série, mais il se trouve que l’une de ses conséquences est en train de se dérouler actuellement, de manière plutôt surprenante pour moi, surtout quand je relis le billet « TeamVieux » (en même temps, je le cherchais un peu).

Comme la série s’approche de sa fin, et donc de l’instant présent, je suis obligé d’attendre que tout rentre dans l’ordre. C’est juste pour moi un mauvais moment à passer.

Je suspends donc la série pour quelques mois. Je vais en profiter pour finir le tome 7 des billets de ce blog et laisser passer l’orage jusque janvier, puis je finirai l’écriture de la série, avec quelques belles surprises à partager (et les explications de tous ces mystères). Enfin, cette série constituera l’essentiel du tome 8. Je rappelle que les tomes 1 à 6 sont disponibles gratuitement en téléchargement sur le blog (sans DRM) dans la rubrique Publications.

2019 sera pour moi une année de grands changements. Le blog va également changer
d’orientation. J’en parlerai dans l’épilogue de la série des « 25 ans dans une startup ». Merci pour votre patience.

Billet 38

Extrait de https://salemoment.tumblr.com/ avec l’aimable autorisation de l’auteur Olivier Ka

Introduction – billet n.36

Pendant la tempête Xynthia de 2010, le service informatique de mon département avait été sinistré. Par solidarité avec les agents concernés, et bien que travaillant dans une entreprise privée (hébergée dans des locaux appartenant au département), j’étais allé leur donner un coup de main, certes modeste en regard des dégâts. Plusieurs d’entre eux avaient apprécié le geste. C’est dans les moments difficiles qu’on a besoin de soutiens.

Il se trouve qu’à ce moment-là, simplement parce que j’étais présent dans les locaux du département, et connu du DSI, j’ai assisté en spectateur externe à plusieurs réunions de gestion de crise, en particulier des réunions liées aux problèmes de communications téléphoniques (tous les réseaux téléphoniques étaient en panne). De cette époque, j’ai gardé dans mon téléphone plusieurs numéros d’urgence, et en particulier les numéros du personnel d’astreinte… Je ne m’en étais jamais servi, et c’est en cherchant dans les contacts de mon téléphone que je suis tombé dessus.

J’en essaye un, puis un autre, et à un moment un agent territorial me répond. Je lui expose mon problème, un peu incrédule sur l’aide qu’il va pouvoir m’accorder. Et là, un petit miracle se produit :

Lui : « C’est l’astreinte technique au téléphone. Je vais faire le nécessaire. »

Moi : « Mais comment ça le nécessaire ? »

Lui : « Alors voilà : je vous fais livrer lundi par camion deux groupes électrogènes de forte puissance en container. Ils devraient être en service aussitôt. Ne vous inquiétez pas. L’expert technique du département passera aussitôt pour voir les dégâts et déclencher la remise en état. Bon week-end. »

Le lundi, deux énormes containers étaient installés sur le parking et raccordés au réseau électrique de la startup. L’électricité était pleinement rétablie le mardi et tout le monde pouvait travailler.

Je n’en revenais pas.

J’entends souvent dans mon entourage des critiques sur les fonctionnaires. Mes parents étaient tous les deux instituteurs et vivaient pleinement et avec passion leur métier. Je connais donc la valeur et l’implication des agents du service public.

Mais le vivre et le voir à l’œuvre concrètement, cela m’a fait chaud au cœur.

Quelques semaines plus tard, les armoires haute tension étaient remplacées, les assurances versaient les indemnités. Ce cauchemar devenait de l’histoire ancienne.

Il restait à tirer les leçons de cet événement pour hausser le niveau de sécurité.

Billet n.37.5

————–

Ce récit est basé sur des faits réels, les noms et certains lieux ont été changés.

Introduction – billet n.35

Samedi matin, une semaine de 15 août où la France est massivement en vacances, je reçois un coup de téléphone du gardien qui habite dans la startup.

Comme tous les salariés de la startup, je suis en vacances depuis
trois semaines et la réouverture des locaux est prévue lundi (dans deux
jours). Je suis en train de profiter des dernières heures de calme avant
le retour dans mon quotidien professionnel un peu agité. Le gardien est aussi en vacances, mais comme il habite dans la startup, il jette un œil aux locaux en complément de la télésurveillance.

« Zythom, de la fumée sort du local haute tension. J’ai appelé les pompiers qui arrivent. Le courant est coupé dans tout le quartier. Je fais quoi ? »

J’ai les cheveux qui se dressent sur la tête, exactement comme le CAPCOM Jack Lousma quand il fit répéter à l’astronaute Jack Swigert la phrase qui allait devenir célèbre : « Houston, we’ve had a problem« , pendant que sur tous les écrans de contrôle les indicateurs s’affolaient…

Après quelques secondes d’hésitation, je lui réponds :

« Tu gères les pompiers. Tu leur facilites l’accès. Tu fais attention au jus. Tu me tiens au courant. »

C’est toujours dans ces moments-là que je fais une mauvaise vanne…

Je raccroche un peu sonné. Je m’assoie. Pendant quelques minutes, je reste immobile. Je me demande quoi faire. Très vite, les réflexes « plan B, plan C, plan D » reprennent le dessus. Je décide d’appeler le propriétaire des bâtiments, c’est-à-dire le conseil départemental. Nous sommes samedi, un week-end qui suit le 15 août… Je sens poindre une difficulté. Surtout que je n’ai pas beaucoup d’éléments. Je décide d’attendre. J’attaque les ongles.

Le gardien me rappelle, et me donne les informations suivantes : « Zythom, c’est bon. Les pompiers sont sur place. L’incendie est maîtrisé. Il s’est éteint tout seul dans le local haute tension. C’est bon. C’est bon. Par contre, les armoires électriques haute tension sont hors d’usage. Les pompiers me disent qu’il y a peu de chance qu’on puisse remettre l’électricité. Je fais quoi ? »

Je lui réponds : « Tu appelles l’astreinte ENGIE avec qui on a un contrat d’intervention sur la haute tension. Tu as le numéro dans ton téléphone, sinon il est affiché dans l’atelier technique, ou dans mon bureau sur la porte de l’armoire. Tu leur dis de rappliquer fissa, et de remettre tout en état : on rouvre lundi. Tiens moi au courant (bis repetita placent). »

Il me rappelle une heure plus tard, alors que j’attaquais avec les dents mes phalanges distales.

« Zythom, c’est bon, les techniciens d’ENGIE sont là. Ils ont remis le courant dans le quartier. Mais pour nous, c’est mort : ce sont nos disjoncteurs haute tension qui ont brûlé. Ils doivent faire un devis et passer commande. Avec ce type d’armoire, il y en a pour des semaines… Je fais quoi ? »

« Tu leur dis de faire un état des lieux complets, et d’activer au plus vite leur chef pour un devis et une commande rapide. Tu vérifies bien la fermeture de l’accès au local haute tension derrière eux, et tu rentres chez toi. Et n’ouvre pas ton congélateur et tu vides ton réfrigérateur en faisant un bon repas ce soir. J’essaye de trouver une solution à distance. Bravo pour ton intervention. Je prends le relais. J’accélère mon retour de vacances, je viens te voir demain dimanche sur place. Je t’appelle avant de venir. »

Une fois le téléphone raccroché (même s’il n’y a pas vraiment de crochet), je fais mentalement le point : nous sommes samedi 17 août, il est 16h, la startup n’a plus d’électricité pour les semaines à venir, en dehors de la salle serveurs. Il faut que j’arrive à joindre un décideur du conseil départemental. Lundi nous serons 20 personnes présentes dans les locaux à rembaucher, 100 la semaine suivante et 900 dans quinze jours…

Le temps s’est arrêté. Putain, mais je fais quoi, moi ?

Billet n.37

————–

Ce récit est basé sur des faits réels, les noms et certains lieux ont été changés.

Quand le temps s’arrête, il est temps de faire une pause (haha). Hum.

Introduction – billet n.34

La climatisation avait été oubliée. Elle était restée branchée sur le courant normal.

« C’est qu’on ne met pas
aussi facilement une clim sur un onduleur« , me dit l’installateur. C’est bien la peine d’avoir une salle serveurs qui tourne à plein régime, si c’est pour cramer les composants des machines en montant à 60°…

Après
moultes devis tout aussi élevés les uns que les autres, j’ai fini par
choisir de mettre deux climatisations : l’une directement branchée sur le groupe électrogène,
et capable de redémarrer toute seule en cas de coupure (il faut 3s pour que le
groupe électrogène atteigne sa puissance électrique nominale), et
l’autre sur le courant standard.

Chaque clim est
capable de maintenir la salle serveurs à une température acceptable. Et
pour éviter qu’elles ne fonctionnent en même temps (pour économiser
l’énergie et faire durer plus longtemps chaque clim), elles sont réglées
sur une température qui diffère d’un degré. Et à chaque contrôle de
maintenance des clims, on inverse la différence. Une seule clim
fonctionne, et si elle s’arrête (panne mécanique par exemple), l’autre
prendra le relais après une élévation de température d’un degré.

Si une panne générale électrique survient, les deux clims s’arrêtent, et celle branchée sur le groupe électrogène redémarrera.

Comme bien sur, en tant que responsable de tous les ennuis techniques et informatiques possibles et imaginables, je suis d’astreinte 24/7 toute l’année, j’ai mis en place un serveur Nagios (maintenant remplacé par un serveur
Centreon), et je reçois un email associé à un SMS (envoyé gratuitement par Google via un script
GMail) en cas d’alerte.

Une sonde Centreon surveille la température de la salle, et si elle monte trop haut (panne des deux clims par exemple) un processus d’arrêt en douceur des 70 serveurs virtuels, et des machines physiques hôtes, se déclenche. Je peux partir en vacances l’esprit tranquille.

Jusqu’au jour où je reçois un coup de téléphone affolé du gardien. Un truc imprévu nous tombait sur la tête. Et cette fois, c’est grave. Très grave.

Billet n.36

————–

Ce récit est basé sur des faits réels, les noms et certains lieux ont été changés.

Un truc imprévu (allégorie) Cliquez pour agrandir l’image Source : Golem

Introduction – billet n.33

On ne plaisante pas avec l’électricité. Toute la salle serveurs est alimentée en courant secouru, c’est-à-dire issu d’onduleurs. Le problème est que de temps en temps, en fait à chaque intervention de maintenance sur les onduleurs, tout saute, et on se retrouve sans aucun serveur, alors que le courant « normal » continue de fonctionner sur tous les postes de la startup.

Évidemment, c’est sur le service informatique que tout le mécontentement se déverse…

Je réfléchis donc à essayer d’améliorer la situation, et me plonge dans les différents types d’onduleurs, les capacités des batteries, les différents contrats de maintenance, etc. Puis, je me souviens qu’il y a une sorte de groupe électrogène vaguement utilisé dans un coin de la startup. Je mène ma petite enquête et je comprends que ce groupe sert uniquement en cas d’incendie : il alimente les moteurs des trappes d’évacuation des fumées. Comme il ne sert jamais, il a un peu été oublié dans son coin.

J’étudie la documentation, et les textes réglementaires. Rien ne s’oppose à ce que j’exploite un peu plus les capacités de cet énorme groupe électrogène. D’abord, je le fais réparer (il doit être chauffé en permanence par une résistance électrique pour le maintenir en température, et éviter une rupture en cas de démarrage et d’exploitation immédiate à pleine charge), puis je trouve une entreprise capable d’en assurer la maintenance. Ensuite, avec une entreprise électrique qualifiée, je fais mettre en place une dérivation pour alimenter tous les onduleurs de la startup. Enfin, je fais valider tout cela par la commission de sécurité qui passe tous les trois ans.

J’ai donc un groupe électrogène qui démarre en cas de coupure de courant, et met environ 3 secondes à fournir un courant de charge pour les onduleurs. Ceux-ci auront immédiatement pris le relais de la coupure, sans micro-coupure, et continueront de tenir leur rôle tant qu’il y aura du carburant dans le groupe électrogène. Au pire, si un jour la demande de courant est trop importante, la capacité des onduleurs de faire fonctionner la salle serveurs aura été passée d’un quart d’heure à plusieurs jours.

Bien sur, j’ai vérifié que les serveurs, les systèmes de stockage et les commutateurs avaient tous au moins deux alimentations, l’une sur le secouru et l’autre sur le courant standard.

A la première panne électrique de secteur, je suis allé voir si tout allait bien en salle serveurs. Tout fonctionnait parfaitement… sauf un détail. Un petit détail qui risquait de ruiner la salle serveurs.

Billet n.35

————–

Ce récit est basé sur des faits réels, les noms et certains lieux ont été changés.

Introduction – billet n.32

Cette même année 2009, je commence à jouer avec un logiciel quasi magique pour moi : ESXi de VMware. Il s’agit d’un hyperviseur, c’est-à-dire d’une plate-forme de virtualisation qui permet à plusieurs systèmes d’exploitation de fonctionner sur une même machine physique en même temps. 

Lors d’un salon informatique, j’ai assisté à une démonstration VMware où le technico-commercial a montré la migration à chaud d’une machine virtuelle en fonctionnement, d’un serveur à un autre, tout en « pingant » la machine, sans perte d’un seul paquet. Cela me paraissait incroyable.

A cette époque, ESXi était devenu gratuit (c’est une version simplifiée de
la version ESX commerciale, dépouillée de sa console graphique qui posait beaucoup de problèmes de sécurité). Pour tester le concept et ne pas mourir idiot, j’ai installé ESXi sur un vieux serveur. Je découvre alors, émerveillé, les concepts de machines virtuelles, de switchs virtuels, de cohabitation de plusieurs serveurs virtuels sur une seule machine physique.

C’est un choc !

(on ne se moque pas, c’est aujourd’hui banal, ça ne l’était pas pour moi en 2009)

Je monte un POC en salle serveurs, avec trois vieilles machines gonflées pour l’occasion (mémoires, disques durs, cartes réseaux), pour étudier la faisabilité de cette idée un peu folle de remplacer 15 serveurs physiques par des machines virtuelles regroupées sur 4 serveurs physiques.

Après quelques mois de tests en salle serveurs, je contacte les principaux constructeurs de matériels informatiques (à l’époque : NEC, HP, Dell et EMC), pour étudier une configuration de production adaptée à mes besoins. Je me fais prêter une config sur laquelle je mesure les I/O des disques et nous basculons tous nos serveurs vers un cluster de 4 hôtes Dell reliés à deux SAN md3000i remplis de disques durs. Je découvre vMotion, la réplique de machines virtuelles, le partage des ressources matérielles, la baisse de la consommation électrique de la salle serveurs.

De 15 serveurs physiques, nous passons à 4 sur lesquels nous installons 15 machines virtuelles, puis 20, puis 30, puis 50 et aujourd’hui 70… Tout est administré à travers une appliance vCenter. L’administration informatique prend chez nous une dimension industrielle. Nous sommes pourtant toujours 3 dans le service informatique… La pression des utilisateurs continue d’augmenter (leur nombre aussi).

Mais le géant nouvellement installé dans la salle serveurs garde un talon d’Achille : l’alimentation électrique.

Billet n.34

————–

Ce récit est basé sur des faits réels, les noms et certains lieux ont été changés.

Administration de machines virtuelles (allégorie)

Introduction – billet n.31

Quelques DSI d’écoles de commerces ou d’écoles d’ingénieurs (privées) commençaient à envisager l’externalisation de leurs outils de travail de groupe (on parlait beaucoup de « groupware » à l’époque), dont leurs messageries. Les offres étaient peu nombreuses, mais existaient et toutes avec des fonctionnalités et des coûts différents. Aucun n’avait encore fait le saut.

Je cherchais une solution qui puisse proposer un espace de stockage en phase avec les besoins toujours croissants des utilisateurs, et facile à installer sur tous les types d’appareils que les utilisateurs amenaient sur place : téléphones de toutes marques, de toutes versions de système d’exploitation, tablettes, ordinateurs portables, ordinateurs fixes, etc. Les modes d’emploi d’installation et de configuration devaient être toujours à jour, surtout lors de la sortie d’un nouveau type d’équipement. Les import/export des contacts devaient être simples et pratiques.

J’ai donc contacté les entreprises qui proposaient des offres
en phase avec mon cahier des charges. A l’époque, deux sociétés
sortaient du lot : Microsoft et son offre BPOS naissante bientôt renommée en Live@Edu (aujourd’hui Office 365), et Google avec son offre Google Apps for Education (aujourd’hui G Suite). Google est alors une société dynamique en pleine ascension, mais
jeune (à peine 11 ans) et le choix est risqué. Microsoft est en train d’opérer son virage vers Internet et peine à convaincre malgré sa base installée.

Les deux offres sont gratuites pour les établissements d’enseignement supérieur, ce qui était très très intéressant, sans que cela n’éveille chez moi la méfiance que j’aurais du ressentir… Je mène une enquête  (sur le principe d’externalisation vers les outils Google ou Microsoft) auprès d’un panel d’utilisateurs internes et leur retour est enthousiaste, avec une nette préférence pour les outils Google.

En étudiant bien les fonctionnalités proposées, y compris les paramétrages possibles dans les outils d’administration, et avec la bonne
réputation que Google avait à l’époque, j’ai choisi de migrer mes 2000
comptes de messagerie vers GMail et son quota de 5 Go par personne
(énorme pour l’époque). Les utilisateurs sont ravis, la bande passante aussi. La lutte contre le SPAM est externalisée et répartie sur les utilisateurs du monde entier. Pour les utilisateurs concernés, le chiffrement des emails est assuré par GPG et Thunderbird.

C’est la décision dont je suis le moins fier aujourd’hui : la pression économique, le manque de clairvoyance, l’envie de satisfaire au mieux les besoins des utilisateurs, m’ont fait franchir le Rubicon.

Mais j’ai l’habitude d’essayer de prendre mes décisions de manière réfléchie, en analysant au mieux les cartes que j’ai en main au moment où je dois prendre la décision. Quand je regarde en arrière, et que je me rends compte que j’ai pris une mauvaise décision, je ne jette pas la pierre à mon moi d’avant. Nous sommes quatre ans avant le lancement d’alerte d’Edward Snowden. Depuis, de nouvelles cartes sont apparues, entraînant une vision différente. Il m’arrive comme tout le monde de prendre de mauvaises décisions, de le reconnaître et d’essayer de les corriger ensuite. Mais dans ce cas, une fois la décision prise et les gigaoctets transférés, ces derniers sont devenus des téraoctets et aujourd’hui des centaines de téraoctets (G Suite for Education propose un quota illimité pour chaque utilisateur, gratuitement). Je n’ai jamais pu revenir en arrière. Les serveurs de stockage ont retrouvé des espaces libres, vite remplis par les utilisateurs qui, c’est bien connus, ont horreur du vide…

La seule consolation que j’ai aujourd’hui, c’est de voir que presque tous les DSI des écoles de commerce et des écoles d’ingénieurs privées ont fait le même choix d’externalisation dans le Cloud. Sauf que la plupart sont chez Microsoft avec son offre gratuite Office 365. Le diable sait tout faire, afin que le DSI devienne sa proie.

L’œil était dans la tombe, et regardait Zythom…

Malgré cette charge en moins, ma salle serveurs vieillissait et son remplacement commençait à devenir d’actualité. C’est à cette époque qu’un logiciel quasi magique est apparu sur mes radars de veille.

Billet n.33

————–

Ce récit est basé sur des faits réels, les noms et certains lieux ont été changés.

La Conscience, Maison de Victor Hugo [Public domain], via Wikimedia Commons

Introduction – billet n.30

En 2009, la téléphonie mobile commence à bien s’implanter dans les usages. De plus en plus de personnes disposent d’un téléphone portable et celui-ci évolue rapidement d’un simple appareil proposant uniquement la fonction téléphonique à un téléphone intelligent ressemblant de plus en plus à un ordinateur.

En quelques années, notre système de messagerie électronique basé sur un serveur web Apache et un magnifique SquirrelMail développé en PHP allait devenir un point de crispation des utilisateurs… Le nombre de messages, le volume des pièces jointes, le besoin de partage des contacts et l’accès facile via les smartphones allaient avoir raison de la solution que nous avions mis en place.

Parallèlement à cela, notre accès internet commençait à être saturé de messages, de SPAM, de transferts de fichiers… Les utilisateurs souhaitaient pouvoir stocker de plus en plus de données, et celles-ci devenaient de plus en plus volumineuses. Ils souhaitaient pouvoir les partager facilement et travailler de manière collaborative dessus.

Tout le monde voulait une solution simple et pouvoir l’utiliser depuis un ordinateur portable, une tablette ou son téléphone.

Depuis quelques années, nous avions abandonné notre fidèle sendmail pour lui préférer le plus simple Postfix. Nous déployions des trésors d’ingéniosité pour protéger nos utilisateurs contre les SPAM, avec du greylisting (PostGrey), du filtrage de contenu avec SpamAssassin, du filtrage bayésien, du filtrage par mots clefs, du filtrage heuristique… Nous blacklistions les serveurs via des bases de données RBL, nous surveillions les envois de nos serveurs pour ne pas être nous mêmes blacklistés…

Le système informatique que j’avais mis en place vieillissait, et il
m’apparaissait comme de plus en plus évident que j’arriverais difficilement à pouvoir proposer le service réclamé par
mes utilisateurs, avec
les moyens à ma disposition. Entre les utilisateurs mécontents et le service rendu de mauvaise qualité, cela craquait de toutes parts, il fallait trouver une solution, et vite…

Vous n’allez pas aimer la solution que j’ai choisie…

Billet n.32

————–

Ce récit est basé sur des faits réels, les noms et certains lieux ont été changés.

Par Sam Johnston [CC BY-SA 3.0], via Wikimedia Commons