docs: add log applicatifs (#516)

* docs: add log applicatifs * Update kubernetes.md * remove /metrics and update limits/requests recommandations * Update kubernetes.md --------- Co-authored-by: Julien Bouquillon <[email protected]> Co-authored-by: Adrien Chauve <[email protected]>
SocialGouv · Jan 8, 2024 · 340aadb · 340aadb
1 parent b77f7ce
commit 340aadb
Show file tree

Hide file tree

Showing 2 changed files with 38 additions and 16 deletions.
diff --git a/docs/standards/kubernetes.md b/docs/standards/kubernetes.md
@@ -37,6 +37,8 @@ _Long story short_ :
 - tous les logs doivent être envoyés sur `STDOUT` ou `STDERR`
 - Dès que c'est possible, utiliser le format de format de sortie `JSON` pour vos logs, et en `single-line`. Ils seront plus facilement indexables dans _Elasticsearch_, et donc plus faciles à exploiter.
 
+Voir également [les recommandations de sécu au sujet des logs](/docs/standards/securite#logging)
+
 ### Exposer les métriques de mon application
 
 Pour faire du profiling comme pour faire de l'analyse sur des données métier, vous pouver exposer un endpoint `/metrics` (ou avec un autre path mais c'est une convention) qui sera scrappé par _Prometheus_, la brique de collecte du cluster K8s.
@@ -182,13 +184,13 @@ Deux cas possibles :
 - **Développement** : le secret est déchiffrable cluster-wide
 - **Production** : le secret est déchiffrable uniquement pour un `namespace` donné.
 
-Pour la _production_ pensez à bien à vérifier le `namespace` et le `secret name` spécifié. Le `secret name` est le nom du secret lié à l'application, par exemple `app`, `api` ou  `app-sealed-secret` ; on peut trouver ce nom dans le champ `metadata.name` du fichier de secret. Ce nom peut-être indiqué dans les déploiements (par exemple dans le fichier `.kube-workflow/values.yaml`, dans la partie `envFrom.secretRef`  pour inclure les secrets déchiffrés dans l'environnement d'un container).
+Pour la _production_ pensez à bien à vérifier le `namespace` et le `secret name` spécifié. Le `secret name` est le nom du secret lié à l'application, par exemple `app`, `api` ou `app-sealed-secret` ; on peut trouver ce nom dans le champ `metadata.name` du fichier de secret. Ce nom peut-être indiqué dans les déploiements (par exemple dans le fichier `.kube-workflow/values.yaml`, dans la partie `envFrom.secretRef` pour inclure les secrets déchiffrés dans l'environnement d'un container).
 
 Copiez-collez ensuite le secret chiffré dans votre fichier de sealed-secrets pour le mettre à jour.
 
 L'équipe SRE est à votre disposition pour vous aider dans cette démarche
 
-## Tester la validité d'un sealed-secret 
+## Tester la validité d'un sealed-secret
 
 Avant d'envoyer un sealed-secret sur le cluster, il est utile de vérifier qu'il soit bien chiffré.
 
@@ -202,12 +204,11 @@ Ensuite, vérifier dans rancher ou k9s qu'un `Secret` avec les bonnes valeurs a
 
 ## Synthèse des attentes
 
-|   Niveau    | Recommandation                                                          |
-|:------------|:------------------------------------------------------------------------|
-| Obligation  | Les logs sont envoyés vers les sorties standard `STDOUT` ou `STDERR`    |
-| Obligation  | Les logs sont envoyés au format `JSON` et `single-line`                 |
-| Obligation  | Les métriques applicatives sont exposés sur un endpoint `/metrics`                   |
-| Obligation  | Les valeurs de CPU `requests` et `limits` doivent être renseignées      |
-| Obligation  | Les valeurs de RAM `requests` et `limits` doivent être renseignées      |
-| Obligation  | Le HPA doit être activé et paramétré avec des valeurs `min=1`, `max=10` |
-| Obligation  | Au moins une route de healthcheck doit être implémentée (ex: /healthz) |
+| Niveau     | Recommandation                                                          |
+| :--------- | :---------------------------------------------------------------------- |
+| Obligation | Les logs sont envoyés vers les sorties standard `STDOUT` ou `STDERR`    |
+| Obligation | Les logs sont envoyés au format `JSON` et `single-line`                 |
+| Obligation | Les valeurs de CPU `requests` doivent être renseignées.       |
+| Obligation | Les valeurs de RAM `requests` et `limits` doivent être renseignées, avec un facteur `limits <= 2*requests` en dev et `limits = requests` en prod.    |
+| Obligation | Le HPA doit être activé et paramétré avec des valeurs `min=1`, `max=10` |
+| Obligation | Au moins une route de healthcheck doit être implémentée (ex: /healthz)  |
diff --git a/docs/standards/securite.md b/docs/standards/securite.md
@@ -260,16 +260,37 @@ asynchrone disponible.
 
 ### Logging
 
+#### Exceptions
+
 Journaliser explicitement les erreurs issues de la logique de l'application, qui
-sont inconnues du runtime. par exemple à l'aide de sentry. La remontée
-d'exceptions dans sentry doit veiller à ne pas remonter de données sensibles
+sont inconnues du runtime. par exemple à l'aide de [sentry](https://sentry.fabrique.social.gouv.fr). La remontée
+d'exceptions dans sentry doit veiller à ne pas remonter de données sensibles ou personnelles
 (ex: cookies).
 
-L'application doit logger en JSON (cf
-[12 factors apps](/standards/kubernetes.md))
+#### Logs applicatifs
+
+- L'application doit logger en JSON (cf [12 factors apps](/standards/kubernetes.md))
+- L'application ne doit logger **QUE** les données nécessaires au bon fonctionnement du service
+- Les utilisateurs de l'application doivent être informés de cette journalisation
+- Ces données techniques ne doivent **PAS** contenir de données permettant d'identifier un individu
+- Les logs peuvent être conservés jusqu'à 12 mois si nécessaire
+
+##### Position de la CNIL
+
+> “De ce point de vue, l’enregistrement de ces données de journalisation ne rend pas le traitement plus intrusif, sous réserve que leur existence ne mène pas à un dépassement de la durée de conservation des données. De plus, cette mesure peut apporter des garanties importantes pour la sécurité de ces données.”
+
+##### Actions à logger
+
+Certains actions peuvent être utiles à logger pour de l'audit de sécurité
+
+- actions destructives (suppression de données/fichiers)
+- auth: tentatives de login, logout, changement/reset de pwd
+- auth: erreurs 401/403
+- upload/download Téléchargement de document
+- exports de données
 
 Côté base de données, un audit log peut être nécessaire. Ex:
-<https://github.com/hasura/audit-trigger>
+<https://github.com/hasura/audit-trigger> ou [pgaudit](https://www.pgaudit.org)
 
 ### Upload de fichiers