Ça y est, l’aventure commence vraiment. Après avoir présenté la genèse de PandaCyberLab dans l’article précédent, il est temps de définir une première ligne directrice afin de ne pas s’égarer dès les premiers pas.
Sommaire
Afficher le sommaire
Introduction
Impossible de se lancer dans un tel projet sans se fixer une direction et des objectifs clairs. Deux environnements distincts sont à construire :
- Un environnement de homelab, dédié à l’expérimentation : installer des solutions, les tester, les pousser dans leurs retranchements, et parfois les casser. C’est mon terrain de jeu.
- Un environnement de production, qui lui doit être stable et disponible quand mes utilisateurs en ont besoin. C’est ici que seront déployées les solutions validées en homelab, dans le respect des bonnes pratiques de sécurité (pas question d’exposer ce qui ne doit pas l’être, qu’il s’agisse des accès ou des données). Les principes DevOps guideront les méthodes de déploiement.
Partir sans plan, c’est tomber dans le piège du “je verrai au fur et à mesure” : risquer de ne jamais concrétiser ce que j’aurai appris, me retrouver avec une architecture impossible à faire évoluer, ou devoir tout recommencer de zéro quelques mois plus tard.
La sécurité, elle, ne s’improvise pas après coup. Elle doit être intégrée dès la conception (segmentation réseau, gestion des accès, chiffrement). C’est ce qu’on appelle le principe du Security by Design. Mal pensée dès le départ, elle contraint à revoir l’ensemble de ce qui a déjà été construit, avec le risque de tout déstabiliser. 😰
L’architecture cible que je vais définir servira de boussole pour la suite du projet. Elle n’a pas vocation à être figée, le monde de l’IT évolue trop vite pour ça, mais elle va me donner une direction cohérente pour chaque décision technique, aujourd’hui comme demain.
Mon homelab doit jouer le rôle d’accélérateur d’apprentissage : comprendre pourquoi une solution fonctionne, dans quelles conditions elle devient instable, comment la faire tenir dans le temps. L’objectif ici est d’adopter une vraie démarche d’architecture : comprendre les choix, pas seulement les appliquer.
Enfin, tout cela ne vaudra rien sans documentation. Consigner mes choix et mes décisions, c’est m’assurer que dans quelques mois, quand viendra le moment de faire évoluer un service ou de reconstruire une brique, je saurai pourquoi j’avais fait un choix plutôt qu’un autre (et vous le saurez aussi grâce à PandaCyberLab.dev 🐼).
Utiliser des références
Pour ne pas faire n’importe quoi, je compte m’appuyer sur des références qui sont aujourd’hui appliquées partout dans le monde telles que l’OSA et le SRE.
L’OSA (Open Security Architecture)
L’OSA (Open Security Architecture) propose des modèles de sécurité (Security Patterns) qui répondent aux défis de sécurité courants. Chaque modèle présente un scénario spécifique : Zero Trust, gestion des identités, sécurité API, cloud, réponse à incident (il en existe plus de 50 à l’heure où j’écris cet article.). Pour chacun, on y trouve notamment :
- un diagramme d’architecture
- les principales zones de contrôle
- des conseils de mise en œuvre (quand l’utiliser et quand ne pas l’utiliser)
- les défis typiques et la résistance aux menaces
- des contrôles NIST 800-53 (une norme qui fournit un catalogue complet de contrôles de sécurité et de confidentialité pour les systèmes d’information).
L’OSA établit également des correspondances avec les principaux cadres de conformité et de gouvernance internationaux (Security Frameworks) : ISO 27001, NIST CSF 2.0, Contrôles CIS, PCI-DSS, SOC 2, DORA, NIS2, etc. Des référentiels que l’on retrouve également dans les recommandations de l’ANSSI (avec son guide d’hygiène numérique, le Référentiel Général de Sécurité (RGS), et SecNumCloud pour la qualification des fournisseurs cloud de confiance).
Il s’agit d’une ressource communautaire open source qui me promet de longues heures de lecture et de recherche. 😅
Le SRE (Site Reliability Engineering)
Le SRE (Site Reliability Engineering) est une discipline née chez Google en 2003, fondée par Ben Treynor Sloss. Elle intègre des pratiques d’ingénierie logicielle aux problématiques d’infrastructure et d’exploitation, avec un objectif central : rendre les systèmes distribués aussi fiables, évolutifs et performants que possible.
Google a documenté cette approche dans une série de livres disponibles librement, les Google SRE Books, qui constituent aujourd’hui une référence incontournable dans le domaine.
Le SRE est souvent présenté comme une implémentation concrète de nombreux principes du DevOps : là où le DevOps pose une culture et des objectifs, le SRE apporte des pratiques opérationnelles mesurables.
Parmi les concepts clés du SRE, je souhaite appliquer les concepts suivants à mon projet :
- Définir des SLO (Service Level Objectives) : des objectifs de disponibilité et de performance que mes services devront respecter pour mes utilisateurs
- Mesurer ces objectifs via des SLI (Service Level Indicator) : des indicateurs concrets qui permettent de savoir si un service respecte ses SLO
- Appliquer une politique de budget d’erreur (Error Budget) : pour prioriser la fiabilité plutôt que d’empiler de nouvelles fonctionnalités sans garantir leur bon fonctionnement
- Automatiser les tâches manuelles et répétitives, (ce que le SRE appelle le Toil) : tout ce qui ne produit pas de valeur durable doit être automatisé
- Mettre en œuvre de l’IaC (Infrastructure as Code) et du CaC (Configuration as Code) : pour pouvoir tout reconstruire rapidement et de manière reproductible
- Déployer de la télémétrie et de l’observabilité : afin d’avoir des données fiables sur l’état de mes services et détecter les anomalies avant qu’elles deviennent des incidents
- Anticiper la mise à l’échelle de mes services pour qu’elle soit automatique et non subie
- Adopter une approche de résilience et d’anti-fragilité : pour être prêt à gérer des pannes imprévues, m’y préparer via le chaos engineering, et en sortir plus solide
Et pour finir, l’un des principes les plus rassurants du SRE : l’erreur est une opportunité d’apprentissage. Chaque incident, chaque panne, chaque raté devient une occasion de progresser.
Ces 2 références vont me guider pour structurer mon architecture cible, je vais bien entendu les adapter aux contraintes d’un homelab et les limites d’une infrastructure à domicile.
Architecture actuelle
Pour vous proposer un contenu le plus didactique possible, je fais le choix de construire une infrastructure propre à partir zéro. Le point de départ : une installation domestique basique, constituée d’une box internet à laquelle sont connectés en Ethernet ou en Wi-Fi tous les appareils de la maison.
Mon matériel de départ :
- La box Internet et le décodeur TV
- Mon PC portable, qui tourne sous Linux 🐧 depuis plus d’un an, ce qui lui a offert une seconde vie
- Les PC de la famille et mon PC professionnel (ce dernier n’intégrera bien sûr pas mon homelab 😅)
- Des vieux PC, un Raspberry Pi 3
- Des appareils mobiles (smartphones et tablettes)
- Des consoles de jeux vidéo
- Mon imprimante
- Des appareils IoT : montres connectées, aspirateur robot, alarme, caméras, etc.
A suivre
Dans la deuxième partie de cette série, nous quitterons l’existant pour concevoir pas à pas mon architecture cible.