Découvrez avec notre expert Thomas SCHAAL, comment les bastions informatiques agissent comme des forteresses modernes pour protéger les réseaux contre les cyberattaques !
Aujourd’hui, nous allons aborder la solution de sécurité essentielle : le bastion. Bien que sa définition et sa fonction puissent parfois sembler floues, elle reste néanmoins fondamentale.
Pendant cette présentation, nous prendrons le temps de clarifier ces points et de comprendre en quoi le bastion constitue un élément clé de notre stratégie de cybersécurité. Nous verrons également comment cet outil et ce processus contribuent à renforcer la sécurité de nos infrastructures.
Avant d’aborder la définition du bastion et son rôle dans une stratégie de gestion des accès à privilège, il me semble important de revenir brièvement sur nos problématiques actuelles et la manière dont nous les traitons habituellement.
On constate de plus en plus de convergence des équipements et solutions vers nos systèmes d'information. Dans cette présentation, je les désignerai comme des assets ou des ressources. Ainsi, d'une part, nous avons un grand nombre d'assets, et d'autre part, une multitude de personnes, d'opérateurs et d'administrateurs capables d'intervenir sur nos systèmes d'information et leurs équipements.
Donc, d’un côté, une multitude d’assets, de l’autre, une multitude d’opérateurs. Cela génère forcément une augmentation significative des risques et des failles de sécurité.
La véritable problématique, au-delà de la création de failles, est que les pirates sont parfaitement conscients de ces vulnérabilités et n’hésitent pas à les exploiter. Ils ciblent la ressource négligée, l’opérateur vulnérable, et utilisent des techniques telles que l’ingénierie sociale ou la fraude au président pour tirer parti de ces faiblesses conceptuelles et renforcer leur approche de piratage.
Face à l’augmentation des assets et des opérateurs, vous avez déjà mis en place un certain nombre de protections sur ces thématiques. Nous identifions trois étapes clés pour protéger nos systèmes et infrastructures. Deux d’entre elles vous sont probablement déjà bien familières. Je vais prendre le temps de détailler ces étapes, mais elles sont les suivantes : le cloisonnement, tant au niveau réseau qu’autour des comptes d’administration, la gestion des comptes à privilège, et la gestion des accès à privilège. C’est à ce niveau que le bastion joue un rôle crucial, en nous permettant de rationaliser la manière dont ces nombreux assets sont gérés par ces nombreux opérateurs. Toutefois, avant d’aborder cette question, il me semble important de préciser que le bastion n’est pas une solution magique qui nous dispense de traiter le cloisonnement réseau et le renforcement des comptes à privilège. Revenons rapidement sur ces deux premiers éléments.
Quel est l’objectif de ce cloisonnement ?
Il est essentiel de donner de l'importance à la notion d'environnement réseau distinct. L'objectif est d'isoler nos équipements qui pourraient représenter un risque pour nos infrastructures, voire devenir un relais ou un vecteur d'attaque au sein de celles-ci.
Pour illustrer cela par un exemple : selon vous, faut-il que le contrôleur de mes panneaux solaires connectés ou le terminal de paiement intégré à la machine à café du hall d’accueil soit sur le même réseau que nos contrôleurs Active Directory ? La réponse est évidente : bien sûr que non. Toutefois, au-delà du cloisonnement, il est essentiel d’assurer une véritable isolation. Par exemple, même si nos IoT ou nos réseaux de caméras sont sur un VLAN dédié, il doit y avoir une action de firewalling pour empêcher l’accès entre les VLANs, sauf si cela est nécessaire au bon fonctionnement de l’entreprise. En aucun cas, le terminal de paiement de la machine à café ne devrait avoir accès à notre Active Directory.
Le cloisonnement réseau est donc essentiel, ainsi que le firewalling associé, voire même l’isolation physique de deux ou plusieurs réseaux totalement distincts. Cela nous permet de protéger nos assets contre des menaces ou des vecteurs d’attaque susceptibles d’exploiter certaines vulnérabilités. C’est un fait : l’enjeu est de réduire la porosité entre les différentes strates de nos réseaux informatiques. Cette première étape est absolument cruciale et vous conviendrez qu’elle est indispensable : c’est véritablement la notion de cloisonnement.
La gestion des comptes à privilège
La deuxième étape concerne la gestion des comptes à privilège. C’est un point crucial, car nous souhaitons éviter toute confusion entre le rôle du bastion, qui prend en compte cette problématique, et la gestion des comptes à privilège en tant que bonne pratique d’administration de nos infrastructures. Que nous mettions en place un processus de bastion ou un Privileged Access Manager, la gestion des comptes à privilège reste une étape clé. Lorsqu’on parle de ces comptes, je vous renvoie à la précédente webconférence, il y a environ deux semaines, où nous avons abordé cette notion. Il s’agit de tous les comptes permettant d’administrer des éléments critiques du système d’information, et pas uniquement ceux utilisés par des humains. Je pense notamment aux comptes de service, qui permettent de démarrer des éléments applicatifs, ou encore à ceux qui gèrent nos bases de données ERP, qui permettent de les interroger et de les administrer.
Ces comptes n’ont pas nécessairement à être gérés par la plateforme du bastion, qui sert à mettre en relation les ressources et les opérateurs, car ils sont essentiels au bon fonctionnement de l’infrastructure. Toutefois, il est crucial de ne pas les négliger dans notre démarche de sécurisation du système d’information. Pour tous ces comptes, qui permettent d’administrer des éléments critiques du système, nous appliquerons trois principes importants : l’unicité (un compte pour un usage), la robustesse de la stratégie de mots de passe (notamment autour de leur rotation et de leur complexité), et enfin, une notion de segmentation.
Faut-il qu’un compte d’administration, destiné à un administrateur ou un opérateur, puisse administrer aussi bien les postes de travail, les serveurs membres que les contrôleurs de domaine ? Aujourd’hui, la réponse est non. Nous suggérons donc de mettre en place une segmentation par niveaux (tiering) dans l’utilisation des comptes à privilège, que ce soit ou non au sein d’un processus de gestion des accès à privilège. C’est un aspect extrêmement important. D’autant plus, je vous le rappelle, lors de la dernière campagne de pentest que j’ai pilotée pour un de mes clients, sur 27 vulnérabilités identifiées, 8 concernaient des comptes à privilège.
Cela montre bien qu’il s’agit d’une question cruciale, qu’il ne faut pas négliger. En cas d’attaque, l’un des premiers objectifs du pirate est d’obtenir un haut niveau de droits sur le système d’information. Il va donc cibler les comptes à privilège, qui disposent déjà de ces droits.
Nous avons abordé la segmentation réseau et la gestion des comptes à privilège. Ces processus seront renforcés par la mise en œuvre d’une démarche de PAM (Privileged Access Management), c’est-à-dire la gestion des accès à privilège. En d’autres termes, il s’agit de la manière dont nous allons mettre en relation nos assets, nos ressources et nos opérateurs, qu’ils proviennent de n’importe où et pour la durée nécessaire à leurs travaux d’administration. Et qui dit PAM, dit bastion.
Qu'est-ce que c'est que le bastion aujourd’hui ?
C'est cette forteresse qui va véritablement renforcer la gestion des accès à privilège de l'entreprise. Pourquoi ? Parce qu'elle constitue un point de passage obligatoire, reliant l’opérateur à la plateforme à laquelle il souhaite accéder.
Pourquoi allons-nous mettre en place un bastion aujourd’hui ? Eh bien, cela va répondre à trois grands objectifs.
🔓 1. La protection de notre système d'information
La protection de notre système d’information, contre les attaques conscientes comme inconscientes, est essentielle. L’objectif est de garantir que tous les opérateurs qui se connectent aux éléments d’administration de notre infrastructure soient légitimes dans leur démarche de connexion, mais aussi dans leurs actions d’administration. C’est là que le bastion intervient, en nous permettant de superviser ce que font les différents opérateurs.
🔑 2. Contrôler les accès
Nous voulons nous assurer que notre infogérant, ainsi que les opérateurs de support chez celui-ci, n’interviennent qu’à bon escient sur notre infrastructure.
Aujourd’hui, sans ce processus de bastion, il est extrêmement difficile de confirmer : ‘Oui, Monsieur X de la société Y s’est connecté à notre infrastructure de telle heure à telle heure.’ Cela reste possible dans une certaine mesure, car la plupart de nos infogérants et partenaires applicatifs utilisent leur propre identifiant nominatif, souvent sécurisé par de l’authentification multi-facteur. C’est une excellente pratique.
Nous pouvons enregistrer ces accès et donc affirmer qu’un opérateur s’est bien connecté à telle heure, mais il est bien plus compliqué de savoir avec précision ce qu’il a fait au sein de l’infrastructure, quels rebonds il a effectués de machine en machine, et quelles actions spécifiques il a menées.
Le bastion répond à cet objectif, en offrant un mécanisme de contrôle, à la fois manuel et automatique, basé sur un certain nombre de critères. Par exemple, on peut définir qu’un opérateur a le droit de se connecter en bureau à distance sur un serveur, mais n’a pas l’autorisation de s’en échapper.
Nous allons définir un certain nombre de cas et de barrières, et l’opérateur ne pourra pas rebondir vers un autre serveur via cette connexion. Ces actions peuvent être identifiées et déclencher des mesures automatiques ou manuelles, telles que la déconnexion brutale de l’opérateur ou des alertes à l’équipe d’administration. En plus de ces processus d’analyse, nous pourrons également rejouer l’intégralité de l’opération. En effet, toutes les actions d’administration sont enregistrées par le bastion, ce qui permet, a posteriori, en cas de doute, de revoir les événements, notamment lorsqu’une manœuvre anormale est détectée.
Il est possible qu’un opérateur ait vu son compte usurpé par un pirate à un moment donné. Grâce au bastion, nous serons en mesure de le détecter, ou du moins de réaliser une analyse forensique a posteriori pour comprendre ce qui s’est passé pendant la session d’administration.
Ces deux premiers grands objectifs sont ceux auxquels répond le bastion : protéger notre système d’information contre les attaques, notamment celles venant de l’extérieur, et contrôler les accès.
🔍 3 - La conformité
Au-delà de cela, cette méthodologie de contrôle, d’audit et de log va également nous permettre de renforcer notre conformité et de répondre aux exigences réglementaires grâce à la traçabilité. Lorsqu’on peut justifier des actions d’un opérateur et prouver notre capacité à cloisonner les différentes manœuvres d’administration, cela devient un atout, notamment lorsqu’on s’engage dans une démarche d’assurabilité. Ces éléments seront en effet bénéfiques dans nos échanges avec l’assureur. Ainsi, les trois grands objectifs du bastion sont : la protection, le contrôle et la conformité.
Comment fonctionne le bastion ?
Quels sont donc les principaux composants que le bastion met en place pour atteindre ces trois objectifs ? Le premier est assez simple à comprendre : il s’agit d’un gestionnaire d’accès, que l’on peut qualifier de broker des connexions. L’opérateur s’y connecte et, grâce à ce gestionnaire, il pourra accéder à une session RDS, à une session Shell, ou encore à une interface web, par exemple.
L’un des avantages de cette approche, notamment lorsqu’on se connecte à des interfaces d’administration qui ne gèrent pas ou gèrent mal la notion de multi-utilisateur, est que le bastion intègre un coffre-fort de mots de passe. Ce coffre-fort va établir le lien, sans que l’opérateur en ait connaissance, entre son nom d’utilisateur et les identifiants de la plateforme d’administration. Une fois que l’opérateur s’est authentifié avec ses propres identifiants, le bastion se charge de le connecter à la plateforme d’administration en toute transparence. L’opérateur n’aura donc pas accès au mot de passe utilisé.
Vous pouvez imaginer à quel point cela est précieux, surtout lorsqu’il s’agit de gérer la rotation des opérateurs. Si nous devons révoquer les droits d’accès d’un opérateur, nous n’avons pas à modifier tous les mots de passe, car l’opérateur n’a jamais eu connaissance de ces informations.
Le troisième composant du bastion est la gestion des sessions, à travers un gestionnaire de sessions qui permettra à l’équipe d’administration et aux RSSI de rejouer le film ou de suivre en temps réel les actions d’administration. En fonction de déclencheurs manuels ou automatiques, ils pourront prendre des décisions si une action malveillante est détectée.
Vous allez me dire que tout cela reste théorique, et je ne pourrais pas vous en vouloir. Ce que je vous propose, c’est d’illustrer l’usage du bastion à travers un cas concret.
Pour ce faire, avec Manon et Julie du marketing, nous avons créé un schéma, et je tiens à les remercier car il est beaucoup plus clair et compréhensible que celui que j’avais griffonné à la main. Pour cela, bravo à elles, car je n’imagine pas que ça ait été facile.
Globalement, nous avons sous les yeux une bulle centrale représentant l’infrastructure IT d’une entreprise, contenant tous les éléments que nous avons l’habitude de gérer : le RP, l’administration de nos équipements réseaux et infrastructurels, nos postes de travail, nos solutions applicatives, notre ERP, nos solutions de production connectées (comme le découpe laser, la soudeuse automatique, le tapis roulant ou encore le magasin automatique de pièces pour la préparation des commandes).
Tout cet écosystème est, à un moment donné, connecté à notre infrastructure IT et, pour son bon fonctionnement, dépend d’un certain nombre d’opérateurs humains, souvent des prestataires, des sous-traitants, ou des infogérants, qui doivent pouvoir y accéder.
Alors, qui sont-ils ? Nous avons affiché ici un petit panel représentatif, en commençant par la droite et en suivant le sens inverse des aiguilles d’une montre :
Les opérateurs de support, qui peuvent être, par exemple, chez notre infogérant. Ils doivent pouvoir se connecter à quasiment tout l’écosystème infrastructurel pour dépanner nos utilisateurs sur leurs postes de travail, résoudre des problématiques liées à Active Directory, aux applications, aux bases de données, et autres, sur l’ensemble des serveurs de l’entreprise.
Les administrateurs, qui peuvent être aussi bien internes à l’entreprise qu’externes. Leur rôle nécessite un très haut niveau d’accès au sein de l’infrastructure, quasiment à tout ce qui est administrable.
Nous avons aussi illustré l’exemple des commissaires aux comptes, qui réalisent un audit des infrastructures une ou deux fois par an. Là, on ajoute la notion de temporalité.
Les prestataires de production : j’ai mentionné précédemment les magasins automatiques, les plieuses, les soudeuses automatiques, qui sont de plus en plus connectés au réseau pour récupérer des plans, des métriques, etc. Les prestataires, ou les salariés de ces prestataires, doivent pouvoir s’y connecter pour en assurer le bon fonctionnement ou effectuer des opérations de maintenance courante. Ici, on est dans des processus plus métier que IT, où la gestion fine des comptes à privilège est souvent difficile à mettre en place, avec un nom d’utilisateur et un mot de passe pour accéder à toute la plateforme. Vous comprenez qu’une telle approche peut entraîner une perte de ces identifiants, compliquant la gestion. Là encore, le bastion répond parfaitement à cette problématique.
Enfin, j’ai mentionné l’ERP. De plus en plus, les ERP consomment des ressources humaines. Nos intégrateurs de solutions ERP emploient de nombreux opérateurs qui doivent se connecter pour des tâches de support, d’administration de base de données ou de modification du fonctionnement applicatif. Cela représente un certain nombre de personnes qui, elles aussi, doivent pouvoir intervenir sur des éléments constitutifs de notre infrastructure IT, bien qu’elles soient potentiellement cloisonnées à l’environnement de l’ERP.
Donc, face à ce dessin représentant notre infrastructure et la manière dont les prestataires doivent s’y connecter, quels sont les objectifs de la DSI par rapport à ce constat ? Ils sont multiples mais bien compréhensibles. Tout d’abord, l’objectif principal est de restreindre la surface d’exposition. L’idée est de maintenir un haut niveau de sécurité, malgré le grand nombre d’opérateurs qui doivent parfois se connecter à nos infrastructures. Nous ne voulons pas non plus partager les mots de passe des interfaces d’administration, qui peuvent parfois être uniques. Je reprends l’exemple de ma plieuse ou de mon robot de préparation des commandes. Nous faisons parfois face à des demandes d’accès temporaires, comme c’est le cas pour mes commissaires aux comptes. En parallèle de ces contraintes de sécurisation, nous souhaitons entamer des démarches de certification. À minima, nous voulons garantir que les personnes qui se connectent aux systèmes d’information n’exécutent pas d’actions qui pourraient être nuisibles.
Donc, nous voulons pouvoir avoir un historique des connexions, nous assurer et garantir qu’un opérateur, quel qu’il soit, ne puisse pas compromettre l’intégrité de notre système d’information, qui est souvent critique, voire essentiel au bon fonctionnement de nos infrastructures. Pour illustrer cela, je vous propose une petite démonstration. J’ai réalisé quelques enregistrements, mais avant cela, je voudrais juste repositionner le bastion comme étant le broker des connexions.
Donc, sur ce schéma, on voit bien notre opérateur, qu’il provienne de l’écosystème externe à l’entreprise ou interne (les administrateurs de la DSI peuvent aussi utiliser le bastion). L’opérateur se connecte au bastion avec son propre mot de passe, unique et individuel, potentiellement sécurisé par une authentification multi-facteur, une restriction d’adresse IP, ou via une connexion VPN préalable. Tous ces mécanismes peuvent être mis en place. Ensuite, c’est le bastion qui, en traversant le firewall, va rediriger la connexion vers les différentes cibles identifiées et vers les assets nécessaires.
Mise en pratique
Alors, comment cela se passe-t-il quand on est l’utilisateur, l’opérateur de cette solution ? Je vais vous montrer une démonstration avec le produit WALLIX. Vous pouvez voir que nous sommes sur une interface web, une plateforme à laquelle je m’authentifie avec un mot de passe robuste, comme vous pouvez le constater, car c’est une étape importante. Ce sont mes identifiants personnels qui sont utilisés ici, j’ai un compte sur la plateforme et je me connecte à la plateforme d’administration.
De là, vous pouvez voir que mes autorisations, celles du groupe OCI, me permettent d’accéder à un contrôleur de domaine, une plateforme Docker, un serveur RDS, et un switch. Quand je clique sur l’icône à côté du serveur RDS, la connexion démarre. Et vous pouvez voir en haut que ce n’est plus mon propre nom d’utilisateur qui est utilisé, mais celui du coffre-fort de mots de passe, dont je n’ai aucune connaissance. Je n’ai pas eu à saisir ce mot de passe, car il s’agit d’un compte d’administrateur du domaine et je n’en ai aucune visibilité.
Nous avons mis en place un mécanisme de sécurité sur ce serveur qui détecte les actions malveillantes. Par exemple, nous avons défini que l’ouverture de Notepad serait considérée comme une action malveillante. Et là, vous voyez, lorsque je lance Notepad, la connexion est immédiatement interrompue, empêchant l’exécution du programme.
Voici donc l’utilisation sur un environnement RDS. Je suis en train de faire exactement la même chose sur une connexion shell. Je lance la connexion à mon shell de gestionnaire de conteneurs, où je peux passer des commandes. Vous pouvez aussi constater que je suis connecté en tant que docker@local, ce qui signifie que je ne suis pas connecté avec mes identifiants personnels. Les identifiants ont été transmis par le coffre-fort de mots de passe.
Côté expérience de l’opérateur, vous conviendrez que c’est plutôt simple à mettre en œuvre. Nous sommes sur une interface web, multi-client et multi-device, accessible partout si nécessaire. C’est vraiment une plateforme user-friendly.
Maintenant, qu’en est-il pour l’administrateur ? Qu’est-ce que je vois en tant qu’administrateur de la solution, par rapport aux opérateurs ? J’ai préparé une petite vidéo pour vous montrer cela. Nous restons sur l’interface web, et cette fois-ci, je me connecte avec des identifiants différents. Les identifiants d’administration sont aussi sécurisés par un mot de passe fort, comme vous pouvez le voir.
Cette fois, l’interface est un peu plus dense, et nous allons commencer par regarder l’historique des sessions d’administration. À l’instant T, il n’y a pas de session active. Par contre, dans mon historique, je vois que Thomas Schaal (moi-même) a administré notre serveur RDS et notre serveur SSH. En cliquant sur la petite loupe, je peux rejouer la session d’administration, avec un résumé des moments clés en bas. Par exemple, on voit exactement le moment où j’ai lancé notepad.exe, et que l’exécutable a été immédiatement stoppé. J’aurais aussi pu être averti par email ou via une notification spécifique si un opérateur avait tenté une action interdite.
Je peux revoir toute la session d’administration, et si besoin, faire une levée de doute a posteriori. Vous pouvez voir exactement tout ce que j’ai fait, c’est très transparent. J’ai également toutes les métadonnées d’administration : tous les clics, toutes les saisies au clavier, toutes les fenêtres ouvertes en mode texte, et tout cela est ordonné chronologiquement.
Ensuite, je vais vous montrer comment nous gérons les assets. Vous voyez ici la liste des assets disponibles, ou cibles, présentées au bastion. D’ailleurs, toutes ne me sont pas accessibles. Je n’ai accès qu’à l’AD, au RDS et au Docker. Dans les comptes globaux, on peut voir le lien avec le coffre-fort de mots de passe. Ici, j’ai déclaré un compte administrateur associé à la ressource RDP rd01 et à la ressource Active Directory 01. En tant qu’utilisateur, je n’ai pas connaissance de ce mot de passe.
Une fois que nous avons défini nos assets et leur lien avec le coffre-fort de mots de passe, il ne nous reste plus qu’à créer les opérateurs.
Une fois que nous avons défini nos assets et établi leur lien avec le coffre-fort de mots de passe, il nous reste à créer les opérateurs. Ce sont les comptes des différents opérateurs, qui font partie d’un groupe, ici le groupe OCI. Ce groupe sera utilisé dans nos différents devices et assets. Par exemple, comme vous pouvez le voir, je vais cliquer sur le groupe où j’ai spécifié que la ressource RDS est accessible au nom du membre OCI.
Cela me permet, de manière très précise et avec la notion de temporalité, de lier la ressource que je dois administrer (l’asset) à l’opérateur qui va en assurer l’administration. Tout cela est rendu possible grâce au coffre-fort de mots de passe, qui m’évite, en tant que propriétaire de l’infrastructure, de diffuser des informations hautement sensibles et critiques.
Ainsi, en résumé, l’administration du bastion permet de gérer de manière sécurisée et transparente les accès aux différentes ressources, tout en garantissant la traçabilité des actions des opérateurs.
Comment est-ce qu'on va mettre en œuvre ce bastion ?
Il s’agit d’un outil technologique que l’on va placer dans une DMZ. Par nature, le bastion trouve sa place dans cette zone, derrière un firewall, ce qui permet de renforcer la segmentation réseau entre le bastion et les ressources auxquelles il donne accès. Comme pour tout logiciel, nous commencerons par une analyse, suivie du déploiement et du paramétrage. Cependant, ce qui m’intéresse ici, c’est d’aborder également la notion d’habilitation.
L’idée est de préparer l’analyse en établissant le lien entre les différentes ressources et les opérateurs qui y auront accès. Pour cela, nous créerons un tableau répertoriant les ressources, les opérateurs et les accès correspondants, en cochant les bonnes cases pour chaque utilisateur. Ce document sera régulièrement mis à jour, suivi et nous permettra de définir qui a accès à quoi, dans une démarche de moindre privilège. Une fois la mise en production réalisée, nous gérerons la traçabilité et accompagnerons le déploiement. En somme, c’est une démarche simplifiée, bien que certains processus et considérations techniques soient à prendre en compte. Nous sommes habitués à vous accompagner sur ces sujets, n’hésitez pas à faire appel à nous.
En résumé
Avant de conclure cette intervention, je souhaite répondre à une question fréquente : le bastion est-il réservé aux grandes entreprises ? Aujourd’hui, la réponse est non. En effet, les ETI et les PME sont de plus en plus ciblées par la cybercriminalité et les cyberattaques. La solution de bastion devient donc essentielle, tant du point de vue technologique qu’organisationnel. Elle s’inscrit dans une démarche stratégique qui nous oblige à repenser la façon dont nous accordons l’accès aux ressources de l’entreprise à des tiers. Le bastion est ainsi un outil utile, même pour les entreprises qui ne sont pas des multinationales.
Le bastion est vraiment un outil essentiel aujourd’hui pour renforcer notre stratégie de gouvernance vis-à-vis des parties externes, et cela me paraît fondamental. J’ai terminé cette introduction sur le rôle du bastion dans les entreprises. N’oubliez pas que vous pouvez me suivre sur LinkedIn pour échanger davantage sur ces thématiques liées à la cybersécurité. Place maintenant aux questions, j’espère qu’elles seront nombreuses et intéressantes.
FAQ
La réponse est indubitablement oui. Il y a trois éléments principaux qui nous permettent d’atteindre cet objectif. Tout d’abord, l’ensemble des sessions est historisé et filmé. Comme vous l’avez vu, nous réalisons un audit complet de ce que fait l’opérateur. En plus d’être filmées, ces sessions sont également retranscrites à travers les métadonnées que j’ai affichées précédemment. En d’autres termes, toutes les actions sont historisées, ce qui nous donne une traçabilité complète.
Concernant la traçabilité simplifiée, elle est rendue possible grâce à l’intelligence artificielle, qui alerte sur les actions suspectes. Nous pouvons ainsi être avertis d’une éventuelle déviation dans l’administration ou d’une action que l’on pourrait interpréter comme malveillante. Ces éléments sont facilement accessibles si nécessaire, et des alertes sont générées par les mécanismes de surveillance en cas de détection.
J’espère que cela répond à la question. En résumé, oui, toutes les actions bénéficient d’une traçabilité complète.
Je vais revenir sur la notion d’utilisateur pour clarifier certains points. Le bastion s’inscrit dans la démarche de PAM, ou Privileged Access Management, c’est-à-dire la gestion des accès à privilège. Tous les utilisateurs de l’entreprise n’ont pas besoin d’un accès à privilège. Au contraire, l’objectif est de limiter les droits des utilisateurs au strict nécessaire pour leur travail. Ainsi, les utilisateurs classiques n’ont pas besoin d’utiliser un bastion.
En revanche, les administrateurs – qu’ils soient internes ou externes à l’entreprise – qui gèrent l’administration du système d’information, doivent impérativement passer par le bastion. Ce dernier sert de hub unique pour distribuer les connexions aux interfaces d’administration.
Cela dit, il peut arriver que des utilisateurs ordinaires du système d’information aient besoin de se connecter temporairement avec des privilèges plus élevés pour des actions précises, comme récupérer des données manquantes d’une pointeuse ou télécharger un extrait vidéo de la vidéosurveillance. Dans ce cas, ils passeront également par le bastion pour effectuer ces tâches administratives.
Ainsi, la gestion des accès à privilège concerne principalement les administrateurs, qu’ils soient internes ou externes, mais certains utilisateurs peuvent y avoir recours dans des situations exceptionnelles.
Concernant la question des ressources nécessaires, il est vrai que les sessions sont filmées et historisées, avec un niveau de compression vidéo élevé. Vous n’avez pas vu cela dans ma démonstration, mais lorsqu’on veut rejouer une session d’administration, la vidéo doit être générée à partir des données brutes. Ces données sont stockées dans un format très compressé, puis décompressées pour créer un extrait vidéo à la demande. Bien sûr, cela nécessite de l’espace de stockage, mais le bastion ne consomme pas des ressources de manière exponentielle.
De plus, pour cet usage, il n’est pas nécessaire d’avoir du stockage flash. En effet, vous comprenez qu’il n’est pas indispensable d’avoir des performances très élevées pour stocker des vidéos qui, par nature, ne seront pas souvent lues, à moins qu’un incident ne survienne. Nous attribuerons également des mécanismes d’historisation et d’archivage avec des délais définis. Après un certain temps, les enregistrements peuvent être nettoyés, ce qui permettra de libérer de l’espace.
Je ne sais pas si cela répond totalement à la question de la personne, mais j’ai couvert les deux principaux points soulevés.
Non, l’objectif n’est pas forcément d’avoir une vitesse de stockage élevée ni une génération de vidéos très rapide. En fait, on n’est même pas obligé de filmer systématiquement. On peut mettre en place des stratégies adaptées et choisir de filmer certaines démarches d’administration sur des plateformes spécifiques, en fonction de leur criticité. Par exemple, certaines plateformes, jugées plus critiques, peuvent être systématiquement filmées, tandis que d’autres, considérées moins sensibles, ne nécessitent pas de filmer les sessions. De plus, le stockage requis ne doit pas forcément être de haute vélocité, ce qui le rend souvent moins coûteux qu’un stockage entièrement flash.
Bien sûr, la réponse est oui. Ce serait un outil de sécurité bien inefficace s’il ne proposait pas des éléments d’authentification forts. Mais on peut aller encore plus loin. Comme vous l’avez vu, nous avons autant de comptes utilisateurs que d’opérateurs. Il n’est pas nécessaire de s’appuyer uniquement sur l’Active Directory de l’entreprise, bien que cela soit possible. On peut utiliser d’autres annuaires et renforcer l’authentification avec de l’authentification multifactorielle. Aujourd’hui, il est courant que de nombreux infogérants aient déjà leur propre solution d’authentification multifactorielle. Dans le groupe OCI, par exemple, nous utilisons la solution AuthPoint. Si un de mes clients me donne accès à son bastion, il serait souhaitable que je puisse me connecter via mon propre AuthPoint.
En outre, il est possible de limiter la surface d’exposition du bastion en restreignant son accès, par exemple en exigeant une connexion VPN préalable ou en limitant l’accès à certaines adresses IP publiques. De manière générale, le bastion doit être placé dans une DMZ, avec des accès contrôlés. Les connexions vers l’infrastructure doivent impérativement passer par un pare-feu pour bénéficier des capacités de filtrage des équipements actifs déjà présents dans l’entreprise.
