Liste de contrôle de durcissement

Le durcissement consiste à réduire les privilèges évitables et à rendre la reprise prévisible avant un incident. Le responsable de la sécurité approuve les exceptions, le responsable de la plateforme met en œuvre les contrôles des hôtes et du réseau, et les responsables des services prouvent que des contrôles plus stricts ne cassent pas les processus nécessaires. Priorisez les contrôles selon l’impact client et la portée des identifiants plutôt que selon le nombre d’éléments de la liste.

Commencez par les frontières qui peuvent compromettre l’ensemble de l’installation : l’accès à l’hôte Opfield, les identités d’administrateurs, les clés de chiffrement et de PKI, PostgreSQL, Redis, l’identité de Relay et le stockage des sauvegardes. Durcissez ensuite les rôles des nœuds gérés, les charges de travail, les fournisseurs et l’automatisation.

Maintenez à jour les hôtes d’Opfield et des démons, et dédiez-les à leurs rôles lorsque c’est possible.
Restreignez PostgreSQL et Redis au réseau applicatif privé.
N’exposez que les ports HTTPS et Relay requis par le déploiement.
Exigez la MFA pour les administrateurs et réduisez au minimum l’appartenance au groupe d’administrateurs.
Stockez les clés maîtresses et les sauvegardes hors de l’hôte Opfield.
Utilisez des identifiants de service limités aux ressources et des intervalles de rotation courts.
Préférez les empreintes d’images immuables et des Build Workers dédiés.
Refusez les montages de répertoires de l’hôte et l’accès privilégié ou aux périphériques, sauf si un processus pris en charge explicite l’exige.
Gardez les bases de données managées privées et utilisez des identités de liaison.
Gardez la vérification des certificats TLS activée pour les connexions aux bases de données externes, et activez-la pour les connexions qui affichent TLS certificate is not verified après une mise à niveau vers 2.11.
Surveillez le renouvellement automatique des certificats d’Opfield, de Relay et des démons, et préservez la PKI système utilisée pour le transport interne ; voir Nœuds : renouvellement des certificats.
Envoyez les événements d’audit vers un SIEM contrôlé de manière indépendante lorsque c’est requis.
Examinez régulièrement les intégrations de sources, les identifiants de registres, les clients OAuth, les jetons et les sessions actives.
Traitez les jetons d’API et les autorisations OAuth qui détiennent des scopes d’administration, comme admin:system, admin:users, settings:opfield:edit ou nodes:manage, comme des identifiants d’administrateur : depuis 2.11, l’accès programmatique peut les porter. Donnez à chacun un responsable, une expiration et le périmètre de ressources le plus restreint.
Retirez la maintenance temporaire, l’exposition de débogage et les modifications manuelles des hôtes après les incidents.

Ne publiez pas de captures d’écran, de paquets de support ou de journaux avant d’en avoir masqué les secrets, les adresses internes, les noms de clients et les URL de dépôts.

Plan de contrôle

Exécutez Opfield sur une VM ou un hôte dédiés et restreignez l’accès direct au shell et à Docker.
Gardez PostgreSQL, Redis, le gRPC interne et le cœur d’inférence sur des réseaux privés.
Protégez .env, les clés de chiffrement, les clés PKI, les artefacts téléversés et l’identité de Relay par des droits de propriété restrictifs et des sauvegardes.
Utilisez HTTPS sur l’URL publique canonique et vérifiez le comportement des cookies, des WebSockets, d’OAuth et du proxy.
Désactivez les méthodes d’authentification et les intégrations inutilisées.

Nœuds gérés

Utilisez une identité d’enrôlement par rôle d’hôte et ne copiez jamais de certificats de démon entre hôtes.
Restreignez les destinations sortantes à Opfield/Relay et aux fournisseurs nécessaires lorsque c’est possible.
Protégez les unités systemd, la configuration, les ancres de confiance des mises à jour, les sockets d’exécution et le stockage local.
Isolez les rôles Ingress, Build Worker, Storage et Relay selon leur niveau de risque.
Déclenchez des alertes sur une heure de dernière activité périmée, la dégradation des capacités, la pression sur le disque et l’incompatibilité des mises à jour.

Charges de travail et builds

Préférez des images épinglées par empreinte et examinez les sources, les journaux de build, la politique de vulnérabilités et les frontières de provenance.
N’exécutez les builds Git que sur des Build Workers dédiés.
Utilisez des volumes managés au lieu de montages de répertoires de l’hôte.
N’accordez ni mode privilégié, ni périphériques arbitraires, ni réseau de l’hôte, ni accès au système de fichiers de l’hôte sans exigence pris en charge explicite.
Stockez les secrets d’exécution et les Build Secrets via leurs chemins chiffrés distincts.

Données et connectivité privée

Gardez par défaut les bases de données managées non publiées.
Utilisez une identité de liaison par relation applicative et vérifiez que les identifiants de propriétaire n’entrent jamais dans la configuration des charges de travail.
Protégez les réseaux de liens appartenant à Opfield et le connecteur secure-link contre les actions de cycle de vie des utilisateurs.
Sauvegardez les données applicatives via des procédures natives du moteur et testez la restauration indépendamment de la reprise d’Opfield.
Gardez le TLS direct des bases de données activé, sauf si une exception délibérée pour un réseau privé est documentée.

Assurance opérationnelle

Examinez selon un calendrier fixe l’appartenance au groupe d’administrateurs, les scopes des groupes, les jetons, les clients OAuth, les intégrations de sources, les connecteurs DNS, les identifiants SMTP, les destinations SIEM et les sessions actives. Testez les chemins de refus avec des identités non administratrices.

Effectuez des exercices d’incident, de restauration, de mise à jour, de basculement de Relay, de redémarrage de nœud, de recréation de charge de travail et de reprise de liaison de base de données. Retirez les accès de débogage temporaires et documentez toute exception acceptée avec un responsable et une expiration.

Gestion des exceptions

Certaines charges de travail peuvent nécessiter un contrôle que la politique par défaut évite, comme la publication directe d’une base de données, le réseau de l’hôte, un périphérique ou un accès plus large chez un fournisseur. Traitez-le comme une exception revue, et non comme un interrupteur caché. Consignez l’exigence métier, les ressources concernées, la menace introduite, les contrôles compensatoires, le responsable qui approuve, la date de revue et le déclencheur de retrait.

N’affaiblissez pas tout un nœud ou toute une installation pour satisfaire une seule charge de travail lorsqu’un nœud dédié, un segment réseau ou un service externe peut isoler l’exception. Revalidez les exceptions après tout changement d’application, d’environnement d’exécution, de rôle de nœud ou de fournisseur.

Vérification et reprise

Pour chaque contrôle de durcissement, prouvez à la fois l’opération prévue et le refus attendu. Vérifiez la récupération des administrateurs après la désactivation de l’authentification inutilisée, la reprise des charges de travail après le retrait de l’accès à l’hôte, le comportement des builds sous restrictions de trafic sortant, le renouvellement des certificats avec des identifiants DNS restreints, et l’accès aux bases de données via les identités de liaison après le redémarrage du nœud et de la charge de travail.

Conservez une méthode de reprise qui ne dépend pas du composant en cours de réparation. Les clés de sauvegarde doivent être accessibles lorsque l’hôte Opfield est perdu ; la récupération des administrateurs doit fonctionner lorsqu’OIDC ou l’e-mail sont indisponibles ; les sauvegardes natives des moteurs doivent pouvoir être restaurées lorsque le plan de contrôle est indisponible. Conservez les éléments de preuve et examinez-les selon un calendrier fixe.