Créer un portfolio FortiGate au Maroc : un projet pratique à présenter

Choisir un projet adapté à son niveau

Un bon projet de portfolio FortiGate est assez petit pour être terminé, mais assez représentatif pour montrer votre raisonnement. Plutôt que de chercher à reproduire une infrastructure complexe, choisissez un scénario comportant quelques zones réseau, des besoins d’accès distincts et des contrôles que vous pouvez expliquer. Pour un projet débutant, une séparation entre un réseau interne, un réseau de services et un réseau invité suffit à faire apparaître des décisions concrètes.

Le périmètre doit rester maîtrisable. Définissez le nombre de zones, les services nécessaires, les règles attendues et les preuves que vous pourrez produire. Un projet limité, testé de bout en bout et documenté est plus convaincant qu’une configuration volumineuse dont vous ne pouvez pas expliquer chaque élément.

Adaptez l’exercice à vos connaissances. Si vous découvrez FortiGate, concentrez-vous sur les interfaces, les politiques de sécurité, les objets réseau et la lecture des journaux. Si vous êtes plus avancé, vous pouvez ajouter un VPN de laboratoire, une politique de journalisation plus détaillée ou une procédure de diagnostic. N’ajoutez pas ces extensions si elles rendent le résultat difficile à tester.

Avant de commencer, vérifiez que vous disposez d’un environnement d’essai et d’une méthode de retour arrière. Une machine virtuelle, du matériel de laboratoire ou un environnement mis à disposition dans le cadre d’une formation peuvent convenir selon les autorisations et les ressources disponibles. Les fonctions disponibles et les conditions d’utilisation dépendent de l’environnement choisi : consignez-les au lieu de supposer qu’elles sont identiques partout.

• Projet débutant : trois zones logiques, quelques flux autorisés et une règle de refus par défaut.
• Projet intermédiaire : ajoutez un accès distant de laboratoire ou une analyse plus poussée des journaux.
• Dans tous les cas : fixez une limite de temps et un résultat vérifiable avant de configurer l’équipement.

Partir d’un besoin concret

Pour rendre l’exercice pratique FortiGate crédible, partez d’un besoin compréhensible par une entreprise. Exemple : une petite structure souhaite séparer ses postes de travail, un serveur interne et l’accès Wi-Fi invité. Les visiteurs doivent pouvoir accéder à Internet, mais pas aux postes ni aux services internes. Les utilisateurs autorisés doivent, eux, pouvoir joindre seulement les ressources nécessaires à leur activité.

Ce scénario permet de répondre à une question centrale : quels flux doivent être autorisés, entre quelles zones et pour quelle raison ? Il oblige à traduire un besoin métier en règles lisibles. Il permet aussi de démontrer que la sécurité ne consiste pas seulement à bloquer le trafic : les accès utiles doivent continuer de fonctionner.

Écrivez un brief avant d’ouvrir l’interface d’administration. Énoncez les utilisateurs concernés, les ressources à protéger, les accès nécessaires et les exclusions. Distinguez les exigences confirmées des hypothèses de laboratoire. Par exemple, indiquez que les adresses IP sont fictives et que les noms de services servent uniquement à l’exercice.

Évitez de présenter le laboratoire comme une solution prête à déployer en production. Il s’agit d’une démonstration de compétences, pas d’un audit ni d’une recommandation complète pour une organisation réelle. La conception d’un réseau réel demande de recueillir les besoins, de connaître l’infrastructure et de suivre les procédures de l’organisation.

• Question métier : comment offrir un accès invité sans exposer le réseau interne ?
• Objectif technique : segmenter les zones et n’autoriser que les communications nécessaires.
• Résultat attendu : une configuration de laboratoire accompagnée d’une matrice des flux, de tests et d’une documentation compréhensible.

Préparer les données, fichiers ou ressources

Préparez une fiche de conception courte avant la configuration. Elle peut contenir un schéma logique, les noms des zones, les plages d’adresses fictives, les services utilisés pour les tests et les flux attendus. Une matrice de communication est particulièrement utile : pour chaque flux, notez la source, la destination, le service, la décision souhaitée et la raison métier.

Réunissez les ressources nécessaires à votre laboratoire : accès autorisé à FortiGate ou à un environnement de formation, machines de test, paramètres réseau et emplacement sécurisé pour les sauvegardes. Vérifiez les conditions d’utilisation de l’environnement et les prérequis techniques avant de le mettre en place. Ne supposez pas qu’un fichier de configuration conçu pour une version ou un appareil donné sera interchangeable avec un autre.

Pour éviter toute fuite, ne reprenez pas la configuration d’un client, les noms de ses équipements, ses adresses publiques, ses identifiants, ses journaux ou des captures d’écran issues d’un réseau professionnel. Utilisez des données fictives et des noms génériques. Si vous vous appuyez sur du matériel appartenant à votre employeur ou à un client, obtenez une autorisation explicite et respectez ses règles de confidentialité.

Préparez aussi une convention de nommage simple. Des objets et politiques nommés selon leur rôle sont plus faciles à relire que des entrées génériques. Le portfolio doit toutefois rester prudent : même une capture recadrée peut révéler un nom d’organisation, une adresse ou un détail d’architecture. Examinez chaque livrable avant de le publier.

• À préparer : brief, schéma, matrice des flux, plan d’adressage fictif et liste des tests.
• À protéger : identifiants, certificats, clés, configurations réelles, journaux et informations permettant d’identifier une entreprise.
• À conserver de façon sécurisée : sauvegarde du laboratoire, notes de configuration et résultats nécessaires à la reproduction.

Réaliser le projet par étapes

Avancez dans un ordre qui facilite le diagnostic. Commencez par représenter les zones et les flux avant d’appliquer les règles. Vérifiez ensuite que chaque interface et chaque machine de laboratoire se trouve dans la zone prévue. Si le réseau de base ne fonctionne pas, les tests de sécurité risquent de produire des conclusions trompeuses.

Créez ensuite les objets utiles et les politiques nécessaires. Pour chaque politique, notez son objectif et les flux qu’elle doit autoriser ou refuser. Appliquez le principe de moindre privilège à l’échelle de l’exercice : n’autorisez pas un accès plus large que celui défini dans le brief. Gardez les noms lisibles et retirez les règles temporaires de diagnostic avant de finaliser le projet.

Activez une journalisation adaptée aux vérifications prévues, dans la limite des capacités de l’environnement de laboratoire. Les journaux peuvent aider à comprendre si une tentative a été autorisée, refusée ou dirigée vers une mauvaise règle. Ils servent ici de preuves techniques, mais ne doivent pas être publiés s’ils contiennent des données sensibles.

Si vous ajoutez un VPN, traitez-le comme une extension indépendante : décrivez les deux extrémités fictives, les réseaux concernés et les accès attendus, puis testez séparément le tunnel et les flux qui le traversent. Ne présentez pas une connexion établie comme une preuve suffisante de sécurité : il faut également confirmer que seules les ressources prévues sont accessibles.

• Compétences illustrées : segmentation, lecture d’un besoin, création de politiques, contrôle des accès et interprétation des journaux.
• Extension possible : VPN de laboratoire, seulement si le scénario et les tests sont clairement délimités.
• À chaque changement : notez la raison, le résultat attendu et la manière de revenir en arrière.

Tester, corriger et documenter

Construisez une checklist à partir de la matrice des flux. Chaque ligne doit associer une origine, une destination, un service, un résultat attendu et un résultat observé. Testez les accès positifs — ceux qui doivent fonctionner — autant que les accès négatifs — ceux qui doivent être bloqués. Un refus inattendu peut révéler une erreur de configuration, tout comme un accès interdit qui fonctionne.

Quand un test échoue, vérifiez d’abord les éléments de base : connectivité, interface et zone, paramètres des machines de laboratoire, règle correspondante, ordre logique des contrôles et journaux disponibles. Changez un élément à la fois et répétez les tests concernés. Cette démarche rend le diagnostic plus lisible et vous permet d’expliquer comment vous avez isolé le problème.

La documentation doit permettre à une autre personne de comprendre le projet sans accès à votre équipement. Présentez le besoin, le périmètre, le schéma logique, les principales décisions, les tests et leurs résultats. Expliquez les limites : environnement de laboratoire, hypothèses, fonctions non testées et différences possibles avec une infrastructure réelle.

Ne publiez pas de sauvegarde de configuration brute par défaut. Si un livrable technique est nécessaire, retirez les secrets et les informations identifiantes, vérifiez le résultat et ne partagez que ce que vous êtes autorisé à diffuser. Les captures d’écran doivent être anonymisées ; une légende doit préciser ce qu’elles démontrent, sans laisser entendre que le projet a été déployé en production.

• La configuration correspond-elle aux besoins écrits dans le brief ?
• Les flux attendus fonctionnent-ils et les flux interdits sont-ils bloqués ?
• Les journaux et captures montrent-ils des preuves compréhensibles sans exposer de données sensibles ?
• Une personne extérieure peut-elle distinguer les faits, les hypothèses et les limites du laboratoire ?

Présenter son travail dans un portfolio

Organisez la page du projet comme une courte étude de cas : besoin, périmètre, schéma, choix de sécurité, réalisation, tests, résultats et limites. Commencez par une synthèse en quelques lignes, puis ajoutez les détails utiles. Un recruteur ou un client doit pouvoir repérer rapidement le problème traité et les compétences mobilisées.

Choisissez peu de preuves, mais expliquez-les. Un schéma lisible, une matrice anonymisée et une ou deux captures expurgées peuvent être plus parlants qu’une série d’images sans contexte. Ajoutez une note sur l’environnement et les données fictives afin que le lecteur comprenne ce qui a réellement été fait.

Soyez précis sur votre contribution. Distinguez ce que vous avez configuré, ce que vous avez testé, ce que vous avez seulement étudié et ce qui reste à faire. Ne revendiquez pas une expérience de production si le projet est un laboratoire. Cette précision n’affaiblit pas le portfolio : elle aide à évaluer votre niveau réel et votre capacité à raisonner.

Enfin, préparez une démonstration courte : présentez le besoin, montrez le schéma, expliquez une règle représentative et illustrez un test autorisé puis un accès bloqué. En entretien, soyez prêt à discuter d’un choix et d’une limite. Le projet devient ainsi un support de conversation technique, et pas seulement une liste d’outils.

• À inclure : brief, schéma anonymisé, matrice des flux, décisions expliquées, tests, résultats et limites.
• À exclure : identifiants, clés, adresses ou noms réels, journaux sensibles et configuration client non autorisée.
• À préparer à l’oral : une démonstration reproductible et une explication des choix.

Le parcours, étape par étape

1. 11. Définir le besoin — Choisissez un scénario limité, par exemple la séparation d’un réseau interne et d’un réseau invité. Écrivez l’objectif, les utilisateurs concernés et les accès qui doivent fonctionner ou être refusés.
2. 22. Concevoir le laboratoire — Dessinez les zones, attribuez des adresses fictives et remplissez une matrice des flux. Vérifiez que l’environnement choisi est autorisé et adapté à votre niveau.
3. 33. Configurer le socle — Mettez en place les interfaces et objets nécessaires, puis créez des politiques cohérentes avec le besoin. N’ajoutez pas de règle temporaire sans prévoir son retrait.
4. 44. Contrôler les journaux — Activez les traces nécessaires aux tests du laboratoire et apprenez à les utiliser pour comprendre le traitement d’un flux. Gardez les journaux privés s’ils peuvent révéler des informations sensibles.
5. 55. Tester les accès — Exécutez les tests autorisés et interdits prévus dans la matrice. Notez les résultats observés, corrigez les écarts et rejouez les tests après chaque changement pertinent.
6. 66. Finaliser et présenter — Nettoyez les règles temporaires, vérifiez les livrables, anonymisez les captures et rédigez une étude de cas qui distingue clairement laboratoire, hypothèses et résultats.

Formations et programmes au Maroc

Compétences clés

Questions fréquentes

Sources

1. FormaGroup — Sécurité des pare-feu Fortinet et VPN formagroup.ma
2. OFPPT — Formation intra-entreprise ofppt.ma
3. JobInTech jobintech.academy
4. Fortinet Training Institute training.fortinet.com