S3
Stockez les alertes de sécurité cside dans des buckets AWS S3 pour l'archivage, la conformité et l'intégration avec les systèmes SIEM.
Stocker les notifications dans S3
Utilisez un bucket AWS S3 comme destination de notification pour archiver les alertes sous forme de fichiers CSV. Ceci est utile pour le stockage à long terme, les exigences de conformité et l’intégration avec les systèmes SIEM ou d’agrégation de logs.
cside envoie un CSV par heure, nommé alerts-team-<team_id>-<from>-<to>.csv, sous le préfixe de chemin que vous configurez. Une heure sans alerte ne produit aucun fichier.
Configurer une destination S3
- Ouvrez le tableau de bord et naviguez vers Team Settings > Notifications
- Créez une nouvelle notification config ou modifiez-en une existante
- Sous Send To, cliquez sur Add destination et sélectionnez S3
- Dans le panneau Configuration, saisissez les détails de votre bucket S3 :
- S3 Bucket Name : le nom de votre bucket AWS S3
- Region : la région AWS où se trouve votre bucket
- Path (optionnel) : un préfixe de chemin dans le bucket pour organiser les fichiers
- Cliquez sur Save ou Save & Test
Politique du bucket S3
Vous devez accorder à cside la permission d’écrire dans votre bucket S3. Appliquez la politique de bucket suivante dans les paramètres de votre bucket S3 :
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "AllowCsideNotificationExport",
"Effect": "Allow",
"Action": ["s3:PutObject"],
"Resource": "arn:aws:s3:::<your-bucket>/*",
"Principal": {
"AWS": ["arn:aws:iam::590183952644:role/prod-cside-notifications-engine-sa-role"]
}
}
]
}
Remplacez <your-bucket> par le nom de votre propre bucket. L’autorisation est en écriture seule : s3:PutObject permet à cside d’ajouter des objets et rien d’autre, donc cside ne peut ni lister, ni lire, ni supprimer quoi que ce soit dans votre bucket.
Il s’agit du même rôle IAM et de la même autorisation que ceux utilisés par l’export S3 Device Intelligence, donc une seule instruction couvre les deux. Ce sont deux destinations distinctes, avec chacune son bucket, sa région et son préfixe, et leurs fichiers n’entrent jamais en conflit : les alertes arrivent sous la forme alerts-team-<team_id>-<from>-<to>.csv, les évaluations sous la forme cside-fingerprints/team=<team_id>/dt=<YYYY-MM-DD>/.
Format des alertes
Chaque fichier est un CSV avec une ligne d’en-tête et une ligne par alerte, sur ces 17 colonnes :
| Colonne | Description |
|---|---|
domain_id | ID cside du domaine sur lequel l’alerte s’est déclenchée. |
timestamp | Moment du déclenchement de l’alerte. |
trigger_type | Le déclencheur à l’origine de l’alerte. |
domain | Le domaine sur lequel l’alerte s’est déclenchée. |
target_type | Ce que contient target, soit URL, soit HASH. |
target | L’objet de l’alerte : une URL de script ou un hash de script. |
action | L’action enregistrée pour l’alerte. |
ruleset_id | ID du ruleset qui a correspondu. |
ruleset_name | Nom du ruleset qui a correspondu. |
script_url_1, script_url_2, script_url_3 | Les trois premières URL de scripts déclencheurs. Une quatrième URL ou au-delà n’est pas exportée. |
vuln_cve_id | ID CVE, pour les alertes de vulnérabilité. |
vuln_package | Paquet affecté. |
vuln_version | Version affectée. |
vuln_severity | Gravité signalée. |
vuln_reference_url | URL de référence de la vulnérabilité. |
Les fichiers d’alertes ne contiennent que des métadonnées : aucune donnée d’empreinte ou de Device Intelligence, et aucun corps de script brut.
Save & Test écrit une petite sonde de connectivité JSON nommée test-alert-<destination_id>-<timestamp>.json, pas un CSV. Elle confirme que cside peut écrire dans votre bucket ; ce n’est pas une alerte, et les vraies alertes n’utilisent jamais cette forme.
Thanks for your feedback!