Cibles d’audit

Les cibles d’audit RustFS envoient des enregistrements d’activité au niveau de la requête vers des systèmes externes, pour la supervision de sécurité, la conformité et l’investigation d’incidents. Ce guide configure une cible webhook et vérifie la livraison d’audit avec une requête S3.

Vue d’ensembleCopy Anchor Link

Les cibles d’audit et les notifications d’événements ont des rôles distincts :

RustFS prend en charge les familles de cibles d’audit webhook, Kafka, MQTT, MySQL, PostgreSQL, NATS, Redis, AMQP et Pulsar. Chaque cible activée reçoit le flux d’audit de façon indépendante.

Les enregistrements d’audit peuvent contenir les chemins de requête, les paramètres de requête, certains en-têtes, les claims d’identité, les identifiants de clé d’accès, les hôtes distants, les agents utilisateur, le statut de réponse et les erreurs. Protégez la destination et restreignez l’accès selon vos exigences de conservation et de conformité.

ConfigurationCopy Anchor Link

La livraison d’audit est désactivée par défaut. Les variables d’environnement suivantes activent le module et créent une cible webhook nommée primary :

export RUSTFS_AUDIT_ENABLE="true"
export RUSTFS_AUDIT_WEBHOOK_ENABLE_PRIMARY="on"
export RUSTFS_AUDIT_WEBHOOK_ENDPOINT_PRIMARY="https://audit.example.com/rustfs"
export RUSTFS_AUDIT_WEBHOOK_AUTH_TOKEN_PRIMARY="<your-webhook-token>"
export RUSTFS_AUDIT_WEBHOOK_QUEUE_DIR_PRIMARY="/var/lib/rustfs/audit-primary"
export RUSTFS_OUTBOUND_ALLOW_ORIGINS="https://audit.example.com"

Redémarrez RustFS après avoir modifié des cibles gérées par l’environnement. Le nom de la cible est la forme en minuscules du suffixe de la variable d’environnement : _PRIMARY crée donc primary.

RustFS envoie un contrôle d’intégrité HEAD vers le chemin racine de l’origine du point de terminaison, par exemple https://audit.example.com/, et envoie des requêtes POST JSON vers le point de terminaison configuré complet. L’origine doit répondre à HEAD, tandis que les requêtes de livraison doivent renvoyer un statut HTTP de succès. Autorisez le compte de service RustFS à écrire dans le répertoire de file d’attente.

Réglages du webhookCopy Anchor Link

Utilisez le même suffixe _PRIMARY pour tous les réglages de cette cible :

Pour toutes les familles de cibles et les clés propres à chaque cible, consultez les variables d’environnement.

Plusieurs ciblesCopy Anchor Link

Ajoutez un suffixe distinct en majuscules pour définir une autre instance. Par exemple, utilisez RUSTFS_AUDIT_WEBHOOK_ENABLE_ARCHIVE et les réglages _ARCHIVE correspondants pour créer un webhook archive à côté de primary.

RustFS diffuse chaque enregistrement d’audit vers toutes les cibles activées. L’échec d’une cible n’empêche pas les tentatives de livraison vers les autres.

UtilisationCopy Anchor Link

Vérifier le récepteurCopy Anchor Link

Avant de générer du trafic, vérifiez que le collecteur est accessible depuis l’hôte RustFS et qu’il accepte le jeton Bearer configuré :

curl --fail --head \
	https://audit.example.com/

Le contrôle d’intégrité mesure l’accessibilité de l’origine et n’inclut pas le jeton d’autorisation du webhook. Confirmez séparément que le chemin de livraison /rustfs configuré accepte Authorization: Bearer <your-webhook-token> sur les requêtes POST.

Si la cible reste hors ligne, vérifiez le DNS, la politique de pare-feu, RUSTFS_OUTBOUND_ALLOW_ORIGINS, la confiance accordée aux certificats et la réponse de l’origine à HEAD /.

Générer un enregistrement d’auditCopy Anchor Link

Effectuez une opération S3 authentifiée sur RustFS :

printf 'hello from RustFS\n' > hello.txt

aws --endpoint-url http://localhost:9000 \
	--region us-east-1 \
	s3 cp hello.txt s3://my-bucket/hello.txt

Le webhook reçoit une entrée d’audit JSON. Les champs varient selon l’opération et les champs facultatifs vides peuvent être omis. Un sous-ensemble représentatif est le suivant :

{
	"version": "1",
	"time": 1719331200000,
	"event": "s3:ObjectCreated:Put",
	"trigger": "s3",
	"api": {
		"name": "PutObject",
		"bucket": "my-bucket",
		"object": "hello.txt",
		"status": "OK",
		"statusCode": 200
	},
	"remotehost": "192.0.2.10",
	"requestID": "<request-id>",
	"userAgent": "aws-cli",
	"requestPath": "/my-bucket/hello.txt",
	"accessKey": "<your-access-key>"
}

Considérez le schéma de la charge utile comme additif. Analysez les champs dont vous avez besoin et tolérez les champs inconnus ou absents, afin que les collecteurs restent compatibles avec les versions ultérieures de RustFS.

Comportement de livraisonCopy Anchor Link

Lorsque RUSTFS_AUDIT_WEBHOOK_QUEUE_DIR_PRIMARY est configuré, RustFS stocke les enregistrements en attente sur disque et les rejoue après des échecs de livraison transitoires. Dimensionnez le répertoire de file d’attente et RUSTFS_AUDIT_WEBHOOK_QUEUE_LIMIT_PRIMARY pour la fenêtre d’indisponibilité attendue, puis surveillez à la fois l’utilisation du disque et l’état de la cible.

La livraison webhook est au moins une fois. Un délai d’expiration peut survenir après que le récepteur a traité une requête, mais avant que RustFS n’observe la réponse : utilisez requestID et d’autres champs stables pour dédupliquer les enregistrements lorsque c’est nécessaire.

Le récepteur ne devrait accuser réception d’un enregistrement qu’après l’avoir accepté de façon durable. Renvoyer un statut autre que le succès maintient les échecs visibles pour le chemin de livraison ; un enregistrement accepté puis ignoré en silence ne peut pas être récupéré par RustFS.

Étapes suivantesCopy Anchor Link

Configurez les notifications d’événements pour les flux applicatifs limités à un compartiment. Consultez l’observabilité pour surveiller l’état du service et les identifiants pour limiter l’accès administratif.