LMi-MAG22 juin - Flipbook - Page 59
Les données d’événements sont collectées et un moteur
de règles est utilisé pour identifier les problèmes de
sécurité. Il est possible de créer ses propres règles ou
de travailler avec des règles développées par la communauté. Les règles de Falco sont équivalentes à des
politiques. Comme le dit Loris Degioanni, « on peut utiliser le langage de politique de Falco pour définir une
politique, comme on le ferait pour démarrer un shell
interactif dans un des conteneurs Redis ». Quand une
politique correspond, un événement est généré et transmis à un service de surveillance central, qui l’utilise pour
fournir la réponse appropriée. Pour cela, Falco s’appuie
en particulier sur des capteurs eBPF. Ces scripts en bac à
sable qui s’exécutent à l’intérieur du noyau Linux, offrent
une surveillance directe et rapide des appels de service.
Outre une identification rapide des intrusions, ils permettent d’automatiser les réponses à l’aide d’applications externes, par exemple en lançant un événement
cloud et en déclenchant des actions sans serveur qui
protègent les données.
Sécuriser Kubernetes à partir du noyau Linux
Falco peut fonctionner dans n’importe quel cluster
Kubernetes, y compris Azure Kubernetes Service, et
fournir des événements à ses outils de sécurité existants.
Grâce à cette approche, il est possible d’inclure les résultats de Falco dans Azure Sentinel et de travailler avec
des agents d’intelligence artificielle pour identifier les
problèmes qui ne seraient pas couverts par les propres
règles de Falco. Parce que Falco travaille à un bas niveau
et suit l’évolution des services, il s’apparente davantage
à un outil d’observabilité qu’à un moniteur de sécurité
traditionnel. Selon M. Degioanni, Falco répond à la problématique de sécurisation d’un environnement très
dynamique en perpétuel changement.
Travailler avec Kubernetes en tant qu’orchestrateur
de microservices ajoute également de la complexité.
Selon M. Degioanni, le défi est le suivant : « Si l’on prend
l’exemple d’utilisateurs qui ont 500 conteneurs à gérer
dans une seule machine à 96 cœurs, s’ils doivent mettre
quelque chose à l’intérieur de tous ces conteneurs et
que leur charge monte et descende, c’est absolument
irréalisable. Le capteur Falco se situant dans le noyau
du système d’exploitation, quel que soit le nombre de
conteneurs présents dans cette machine à 96 cœurs, il
n’y a qu’une seule instrumentation. Si bien que, quand
un conteneur monte et descend en charge, il n’est pas
nécessaire d’attendre que l’instrumentation soit active
dans ce conteneur, car elle est déjà active dans le noyau
sous-jacent.
La manière la plus simple d’installer un logiciel dans Azure
Kubernetes Service est d’utiliser Helm. La communauté
Falco maintient un diagramme Helm qui installe Falco
en tant que DaemonSet à partir du dépôt Falco GitHub.
Cette approche permet d’automatiser le déploiement en
utilisant Azure DevOps ou GitHub Actions. Il est inutile
de penser à des déploiements manuels, car Falco sera
utilisé dans le cadre d’une infrastructure idempotente,
où chaque nouveau déploiement remplace le précédent.
L’installation du chart Falco Helm est assez simple. Il
suffit d’exécuter le chart à partir de son référentiel, de
créer un espace de noms Falco dans son cluster, et de
configurer des instances dans ses nœuds. Si l’on exécute
Falco en tant que DaemonSet, il doit y avoir un pod Falco
par nœud, en utilisant son runtime de conteneur actuel.
Exécuter Falco dans les hôtes Kubernetes
Si, au lieu d’utiliser Azure Kubernetes Service, on met en
place son propre environnement Kubernetes sur Azure,
on peut installer Falco dans le système hôte, en l’isolant
de l’instance Kubernetes qu’il surveille. Les alertes sont
toujours gérées à l’intérieur de Kubernetes, mais une
installation sur le système hôte apporte une solution
de repli en cas de compromission grave. L’équipe Falco
fournit des instructions d’installation pour différentes
versions de Linux, tant pour les distributions basées sur
Debian, comme Ubuntu, que pour celles basées sur Red
Hat. Les versions ARM et x64 sont prises en charge, ce
qui permet de profiter des serveurs Azure à haute densité
basés sur ARM de Microsoft. [Lire l’intégralité de l’article
sur lemondeinformatique.fr]
APPROFONDIR
ÉCOUTER EN LIGNE
Podcast
tinyurl.com/podcast-Falco
LIRE EN LIGNE
Article
tinyurl.com/article-Falco
59
