Sections du handbook▾
Fondations
Comprendre les menaces qui pèsent sur un hôte LinuxPourquoi on durcitLes principes de défense derrière chaque règleConfiguration effective : la vérité qu'aucun fichier ne contientLes normes que Pavois cartographieModèle d'identifiant de contrôle SOCLEPreuves & exportsComment la note A-E est calculéeCe qu'un PASS prouve : le verdict qualifiéModèle de confiance du bundle de preuveSOCLE, n'est-ce pas votre propre norme ? (gouvernance & la question de la circularité)Ce que Pavois couvre, et ce qu'il ne couvre pasDomaines
Durcir SSHDurcir PAMContrôle d'accès obligatoire (SELinux / AppArmor)Durcir le pare-feu localDurcir sudoPermissions et propriété des fichiersDurcir les montages et le système de fichiersDurcir les modules noyauDurcir le noyau et le réseau avec sysctlJournalisation d'audit avec auditdDurcir la journalisation avec journald et rsyslogDurcir les services systemdHygiène des paquetsDurcir le chargeur d'amorçage (GRUB)Synchroniser l'heureBannières de connexion et MOTDContrôler l'accès à cron et atDurcir le bureau GNOME (dconf)Outillage
Annuler un durcissement : les points de restaurationExploiter Pavois : privilèges, air-gap, durée, dérogationsLancer Pavois en CI (GitHub Actions)État des fonctionnalités : livré, partiel, roadmapGouvernance : licence, versionnement, provenance, sécuritéModèle de confiance du bundle de preuve
Revu le
Un bundle est inviolable en soi ; il ne devient une preuve opposable qu'une fois signé sous une politique de confiance que votre organisation accepte. Qui signe, avec quelle identité, comment les clés tournent, et comment vérifier hors ligne.
Deux états, un bundle
pavois bundle produit un répertoire dont le manifest.json enregistre le SHA-256 de chaque artefact, les versions de l'outil et du jeu de règles, l'empreinte du binaire pavois, la cible et le delta de note. L'empreinte du manifeste lui-même est l'unique valeur que vous signez. Un bundle a donc deux états distincts, et c'est là tout l'enjeu :
- Inviolable (non signé).
pavois bundle verify <dir>recalcule chaque checksum et l'empreinte du manifeste. Tout octet modifié après l'empaquetage est détecté. Cela prouve la cohérence interne : personne n'a édité un rapport après coup. Cela ne prouve pas qui l'a produit : un attaquant qui régénère tout le bundle régénère aussi un manifeste cohérent. - Preuve d'audit signée. Vous signez l'empreinte du manifeste avec une identité, et
pavois bundle verify <dir> --require-signatureéchoue sauf si une signature valide est présente. Le bundle est alors lié à un signataire que votre auditeur peut nommer. C'est cela, et seulement cela, que nous appelons opposable.
pavois ne détient jamais de clé de signature. Il calcule et vérifie ; l'ancre de confiance est votre identité, volontairement, pour que la preuve soit la vôtre, pas celle de l'outil.
Choisir comment signer
| Méthode | Ancre de confiance | À utiliser quand |
|---|---|---|
| Hash seul (pas de signature) | aucune, intégrité seule | itération interne, artefacts CI non publiés |
| Signature GPG détachée | une clé publique que vous distribuez | vous avez déjà un workflow GPG/PKI |
| cosign avec clé | une clé dans un fichier ou un KMS (AWS/GCP/Azure) | une clé d'organisation, tournée et contrôlée |
| cosign keyless (OIDC) | un certificat court lié à une identité OIDC, journalisé dans Rekor | signature CI sans clé longue durée |
Pour une release construite en CI, le keyless OIDC (le mécanisme qu'utilise la chaîne de release pour sa propre attestation de provenance SLSA) demande le moins de maintenance : aucune clé à fuiter, et le journal de transparence enregistre quand et par qui chaque signature a été faite. Pour une personne signant un paquet d'audit trimestriel, une clé KMS d'organisation ou GPG est souvent plus simple à expliquer à un auditeur.
Identité, rotation, révocation
Une signature ne vaut que par la politique qui dit quelle identité est acceptable. Décidez et consignez :
- Identité acceptée. L'ARN exact de la clé KMS, l'empreinte GPG, ou l'identité OIDC + l'émetteur (
--certificate-identity,--certificate-oidc-issueravec cosign) que votre auditeur vérifiera. Une signature d'une autre identité doit échouer à votre politique, pas seulement passerverify. - Rotation. Les clés tournent selon un calendrier (voir NIST SP 800-57). Consignez la fenêtre de validité par clé pour qu'un ancien bundle reste vérifiable contre la clé courante au moment de sa signature.
- Révocation. Si une clé est compromise, publiez la révocation et re-signez les bundles encore valides. Le keyless contourne la révocation des clés longue durée car les certificats sont courts par conception.
Vérifier hors ligne
La vérification doit fonctionner sans appel réseau, car un auditeur l'exécute souvent dans un environnement isolé :
pavois bundle verify evidence/ --require-signature
# re-vérifie chaque SHA-256 d'artefact, l'empreinte du manifeste et la signatureLes checksums et le manifeste sont autoportés. Pour une signature GPG, importez la clé publique une fois ; pour cosign avec clé, fournissez la clé publique ; pour cosign keyless, le certificat et la preuve d'inclusion Rekor voyagent avec le bundle pour vérifier la chaîne contre une racine épinglée plutôt qu'un service en ligne. Conservez le matériel de vérification public (clé publique, certificat, racine) avec votre copie de rétention.
Rétention
Un paquet d'audit n'est utile que s'il survit à la fenêtre d'audit. Stockez le bundle, sa signature et le matériel de vérification public ensemble, de façon immuable (object-lock ou stockage WORM), au moins pendant votre durée de rétention réglementaire. L'empreinte du binaire pavois dans le manifeste permet de prouver plus tard quelle build exacte a produit la preuve, même après que l'outil a évolué.