Logs système & événements de sécurité

Les logs applicatifs vont sur stdout/stderr et atterrissent dans le journal systemd ; les événements à fort signal sont en plus émis comme JSON d'une ligne pour ingestion machine. Optionnellement, les événements les plus pertinents pour la sécurité peuvent aussi être reflétés vers un fichier append-only hors de la base de données. Cette page couvre les deux couches plus les considérations de rétention/PII.

Lire le journal

journalctl -u chinaski@<N> -f                         # tail the live stream
journalctl -u chinaski@<N> -o json --since '1 hour ago' | grep -F '"event"'

Les lignes en texte brut [chinaski] … et les lignes JSON structurées partagent le flux : le filtre grep isole l'ensemble structuré.

Les événements structurés (JSON)

Événements documentés et leurs niveaux/champs :

Événement	Niveau	Champs
login_success	info	user, role, ip
login_failure	warn	user, ip, reason
login_lockout	warn	ip, wait_seconds
setup_completed	info	user
build_started	info	triggered_by
build_finished	info/error	status, files_written, error_count
webhook_fired	info	url_host, status_code

En outre, un ensemble plus large d'événements de sécurité est reflété vers le log externe quand configuré (voir ci-dessous).

PII et rétention

Les champs ip contiennent l'adresse IP du client demandeur, nécessaire pour la forensique de sécurité (corrélation des tentatives de connexion, verrouillages) mais données personnelles sous GDPR/CCPA. Le README fourni un exemple de politique de rétention pour journald :

[Journal]
SystemMaxUse=2G          # cap disk use
MaxRetentionSec=30day    # auto-prune after N days

Rechargez le journal avec systemctl restart systemd-journald. Si les logs partent vers un SIEM externe, appliquez une rétention correspondante là-bas.

Journal de sécurité externe

Définir security log destination (Settings → Security) vers un chemin de fichier active un second canal : les événements de sécurité à fort signal listés (succès/échec de connexion, verrouillage et compte suspendu, connexion SSO, vidages de sessions périmées, sondes honeypot, limitation de débit d'inscription) sont ajoutés comme lignes JSON à ce fichier (créé en mode 0600). Le but est la durabilité forensique : le journal survit à une compromission de la base de données SQLite.