Renforcer la sécurité des données grâce au contrôle de l'intégrité des fichiers

Tirer parti de Watchdog pour la conformité et l'atténuation des risques

Les organisations restent conformes tant qu'elles sont en mesure, entre autres, de démontrer de manière cohérente qu'elles traitent correctement les informations personnelles identifiables (IPI) de leurs clients. L'un des aspects de cette stratégie consiste à gérer et à garantir l'intégrité des fichiers contenant des IPI au sein d'une application destinée aux utilisateurs.

La surveillance de l'intégrité des fichiers (FIM) est une stratégie mise en place pour permettre et définir des mécanismes d'alerte qui notifient aux équipes de sécurité que l'état des données des utilisateurs est menacé et qu'une cyberattaque est susceptible de se produire.

L'intégrité des fichiers sur Upsun

Upsun (et Platform.sh, d'ailleurs), est construit sur une forte séparation entre le code et les données. Notre plateforme est construite sur Git, et cela crée une relation pour votre organisation entre ce qui est engagé dans un référentiel et comment ce code se traduit dans l'infrastructure provisionnée, les environnements actifs, et ce qui est finalement servi à vos utilisateurs.

Nous lions les commits individuels - l'état de votre code et de votre configuration - à des images de compilation uniques. Ces images peuvent être déplacées d'un environnement à l'autre, ce qui se traduit par nos capacités de clonage de l'environnement central, mais elles ne peuvent en aucun cas être modifiées une fois qu'elles ont été déployées au moment de l'exécution.

Cette fonctionnalité est rendue possible grâce à une courte liste de règles imposées à vos projets :

• Les modifications apportées à l'infrastructure doivent être effectuées par le biais de commits
• L'accès, que ce soit aux projets, aux environnements, aux applications, aux services ou au monde extérieur, doit toujours être explicitement défini.
• Les données et le code sont différents. Le code, l'infrastructure et la configuration doivent être validés, alors que les données ne doivent jamais l'être.
• L'accès en lecture seule au système de fichiers est maintenu au moment de l'exécution, sauf définition explicite du contraire.
• Les données descendent vers les environnementsenfants

Tant que vos projets et les membres de votre équipe respectent ces principes, les éléments déposés sur Git (y compris l'infrastructure) devraient être protégés.

La surface d'attaque n'est cependant pas complètement éliminée si l'on considère l'application elle-même et les éléments que vous contrôlez. Il est nécessaire, par exemple, que vous assainissiez les champs destinés à l'utilisateur et que vous validiez les entrées dans votre application pour empêcher les injections SQL et d'autres méthodes qui permettraient à de mauvais acteurs d'exécuter un code arbitraire qui mettrait en danger les informations confidentielles.

Chien de garde

Cette protection ne représente qu'une partie du puzzle de la FIM, mais même les meilleures pratiques ne peuvent pas garantir que les IIP ne seront jamais exposées et/ou modifiées. Pour les choses auxquelles nous ne pouvons pas nous attendre, nous devons mettre en place un système de surveillance qui déclenche des notifications lorsque des modifications sont apportées aux fichiers conservés dans les montages.

Les notifications nous permettent non seulement de répondre aux attaques en cours, mais aussi de remplir certains rapports qui peuvent être exigés pour rester en conformité en cas de violation.

Bien qu'un tel système de notification n'existe pas sur Upsun, nous pouvons mettre en place quelque chose en utilisant des outils open-source qui surveillent les changements dans nos répertoires pour construire une telle stratégie de notification.

Watchdog est une bibliothèque Python open-source et un outil shell pour surveiller les événements du système de fichiers. Nous pouvons utiliser Watchdog en plus de nos meilleures pratiques de contrôle d'accès pour mettre en place un système de notification afin de surveiller les modifications du système de fichiers.

Voici une application simple, qui ne contient en fait aucun code, à l'exception de ce qui est nécessaire pour configurer l'infrastructure afin de mettre en place un travailleur Watchdog pour écouter les modifications du système de fichiers effectuées sur un seul montage.

mkdir notify && cd notify && git init upsun project:create ... touch .upsun/config.yaml

Mettre à jour la configuration Upsun pour le travailleur :

applications : notify : # Cet exemple utilise l'image Composable pour Python, mais je pense que `type:'python:3.12'` fonctionnerait tout aussi bien stack : - python@3.12 - python312Packages.pip hooks : build : | set -e pip install -r requirements.txt # Quelques bonnes pratiques pour l'accès de référence : ssh : admin web : commands : start : sleep infinity # Notre montage contenant des données sensibles. mounts : user_pii : source : storage

Cette configuration met en place un seul conteneur Python 3.12 avec un seul répertoire accessible en écriture contenant nos données utilisateur sensibles(user_pii). Ensuite, nous installons Watchdog dans un environnement virtuel

python3 -m venv env env/bin/activate (env) pip install watchdog requests (env) pip freeze > requirements.txt (env) deactivate echo "env" > .gitignore

Ensuite, nous produisons le script de notification qui sera exécuté à partir de notre conteneur de travail :

# https://github.com/gorakhargosh/watchdog # https://pypi.org/project/requests/ # https://philipkiely.com/code/python_watchdog.html import os import sys import time import datetime import requests import logging from watchdog.observers import Observer from watchdog.events import FileSystemEventHandler class Watcher : def __init__(self, directory=".", handler=FileSystemEventHandler()) : self.observer = Observer() self.handler = handler self.directory = directory def run(self) : self.observer.schedule( self.handler, self.directory, recursive=True) self.observer.start() print("\nWatcher Running in {}/\n".format(self.directory)) try : while True : time.sleep(1) except : self.observer.stop() self.observer.join() print("\NWatcher Terminated\N") class MyHandler(FileSystemEventHandler) : webhook_url = "https://webhook.site/3cbc9b0d-d2c1-4b95-8576-1e3070f704cd" if os.environ.get("WATCH_WEBHOOK_URL") is not None : webhook_url = os.environ["WATCH_WEBHOOK_URL"] logging.basicConfig(level=logging.INFO, format='%(asctime)s - %(message)s', datefmt='%Y-%m-%d %H:%M:%S') def on_any_event(self, event) : if not event.is_directory : event_data = { "src_path" : event.src_path, "dest_path" : event.dest_path, "event_type" : event.event_type, "is_directory" : event.is_directory, "is_synthetic" : event.is_synthetic, "timestamp" : datetime.datetime.now().strftime("%Y-%m-%d %H:%M:%S%z") } logging.info(f'{event.event_type.upper()!r} : {event_data!r}') resp = requests.post(self.webhook_url, json = event_data) alert_data = { "status_code" : resp.status_code, "url" : resp.url } logging.info(f'{"FORWARDED".upper()!r} : {alert_data!r}') if __name__=="__main__" : watchpath = sys.argv[1] if len(sys.argv) > 1 else '.' w = Watcher(watchpath, MyHandler()) w.run()

Dans le script ci-dessus, remarquez que :

• Une classe FileSystemEventHandler est utilisée pour définir MyHandler, qui est acheminé vers le Watcher principal lorsque le script est exécuté.
• L'observateur surveille les modifications du système de fichiers de manière récursive, une cible étant fournie en tant qu'argument de la ligne de commande(sys.argv).
• MyHandler écoute les modifications du système de fichiers on_an_event et transmet un objet JSON event_data soit à une URL webhook par défaut (dans ce cas, à une URL webhook temporaire sur Webhook.site), soit à une URL fournie par l'utilisateur via la variable d'environnement WEBHOOK_URL.

Une fois le script en place, nous pouvons l'exécuter en parallèle à l'application man via un Worker:

   workers : watchdog : commands : start : | python watch.py $PLATFORM_APP_DIR/user_pii

Avant de pousser, nous pouvons inclure quelques opérations d'exécution(réservées à l'administrateur !) pour tester nos changements :

   operations : init-secret : role : admin commands : start : | echo "Oceanic 815 SYD -> LAX, 13C ; Status : DEPARTED" > \N-PLATFORM_APP_DIR/user_pii/austen_kate.txt read-secret : role : admin commands : start : cat $PLATFORM_APP_DIR/user_pii/austen_kate.txt rewrite-secret : role : admin commands : start : > echo "Oceanic 815 SYD -> LAX, 13C ; Status : LOST" > \N- $PLATFORM_APP_DIR/user_pii/austen_kate.txt destroy-secret : role : admin commands : start : rm $PLATFORM_APP_DIR/user_pii/austen_kate.txt

Enfin, nous validons et poussons tous nos changements :

git add . && git commit -m "Créer une application de notification simple" git push upsun main

Une fois l'application déployée, nous pouvons exploiter nos opérations d'exécution pour nous assurer que les événements du système de fichiers qui modifient les données sensibles d'un montage donnent lieu à des notifications à l'URL webhook souhaitée.

1. Créer un fichier

upsun operation:run init-secret -y

En effet, l'opération (création du fichier austen_kate.txt) déclenche quatre notifications (ouvert, créé, modifié, fermé) :

2. Mise à jour du fichier

upsun operation:run rewrite-secret -y

Là encore, l'action (mise à jour du fichier austen_kate.txt) donne lieu à trois événements (ouverture, modification, fermeture) dont nous pouvons être alertés.

3. Lire un fichier

upsun operation:run read-secret -y

Nous pouvons également être alertés des deux événements (open, close_no_write) qui se produisent lors de la lecture d'un fichier contenant des données sensibles(cat austen_kate.txt),

4. Supprimer un fichier

upsun operation:run destroy-secret -y

Enfin, la suppression complète du fichier du système de fichiers peut déclencher sa propre notification pour l'événement de suppression unique du système de fichiers.

Voici un exemple très simple de la façon dont les outils open-source peuvent être utilisés pour construire un système de notification personnalisé pour FIM sur Upsun. Vous pourriez mettre à jour la variable d'environnement WEBHOOK_URL pour utiliser une URL de webhook Slack dans le canal de notifications de sécurité de votre organisation, mais en l'état, ce canal serait inondé de faux positifs.

Nous espérons cependant que vous pouvez voir comment ces outils de base pourraient être adaptés pour écouter :

• un sous-ensemble d'événements du système de fichiers
• uniquement les événements du système de fichiers exécutés par des agents autres que des administrateurs connus ou votre application elle-même
• les détails de ce qui a été modifié à inclure dans le message transmis
• des liens vers les sauvegardesles plus récentes afin de raccourcir le délai de récupération.

Modifiez cet exemple en fonction de vos besoins, et ne sous-estimez jamais ce qui peut être construit sur une plateforme d'application avec si peu de règles intégrées. Bonne chance !