Lorsque vous traitez la conformité comme quelque chose qui réside dans le code, une question se pose : quels changements brisent réellement un contrôle ? Pas en théorie, mais dans le diff. Nous n'avons pas encore de télémétrie de production pour y répondre, donc ce n'est pas un graphique de ce que nous avons observé en pratique. Il s'agit plutôt de la taxonomie que nous avons conçue pour heygrc : cinq motifs de pull request qui, par construction, brisent un contrôle de la manière la plus directe.
Ce qui les unit est inconfortable. Aucun ne ressemble à un changement de conformité. Chacun est une modification raisonnable, un nettoyage, un débloquage, une commodité, qui a pour effet de supprimer l'élément sur lequel un cadre de conformité s'appuyait. Les voici.
1. Un secret dans la configuration
La manière la plus rapide de faire fonctionner une intégration est de placer la clé là où le code peut la lire directement. Cela fonctionne dès le premier essai, mais cela écrit une information d'identification active dans le dépôt, son historique, et chaque clone et cache CI qui la récupère. Un secret validé est un secret exposé, et la seule réponse sûre est de le faire tourner.
- const key = process.env.PAYMENTS_SECRET_KEY+ const key = "<the live key, pasted inline>"const client = new Payments(key)L'information d'identification réside désormais dans le contrôle de version, accessible à toute personne ayant accès au dépôt, maintenant ou plus tard. Lisez-la depuis un magasin de secrets géré, et faites tourner celle qui a été validée.
2. Authentification assouplie
Une vérification d'autorisation bloque un changement, elle est donc supprimée ou élargie à un joker pour débloquer un appelant. La fonctionnalité fonctionne ensuite pour tout le monde, y compris les personnes que la vérification était censée exclure.
export async function getReport(user, id) {- if (!user.can("reports:read")) return forbidden() return reports.find(id)}La suppression de la vérification permet à tout appelant authentifié de lire n'importe quel rapport, et pas seulement ceux auxquels il a droit. Restaurez la vérification d'autorisation plutôt que de la contourner.
3. Journalisation désactivée
Une ligne de journalisation est bruyante, elle est donc supprimée lors d'un nettoyage. Le système fonctionne toujours, mais il cesse d'enregistrer l'événement de sécurité qu'un auditeur échantillonnera plus tard, et que vous voudriez avoir après un incident.
async function onLogin(userId, ip) {- await audit.log("auth.login", { userId, ip }) return startSession(userId)}L'événement de connexion n'est plus enregistré, il ne peut donc plus être surveillé ou reconstitué ultérieurement. Conservez le journal ; s'il est trop bruyant, modifiez son niveau ou sa destination plutôt que de le supprimer.
4. Règles réseau élargies
Un service ne peut pas accéder à une base de données, une règle de groupe de sécurité est donc ouverte pour établir la connexion. Cela fonctionne, et toutes les autres connexions désormais à portée le font aussi, y compris celles provenant d'Internet ouvert.
ingress { from_port = 5432- cidr_blocks = ["10.0.0.0/16"]+ cidr_blocks = ["0.0.0.0/0"]}L'ouverture de la règle à 0.0.0.0/0 expose le port de la base de données à l'ensemble d'Internet, et pas seulement au service qui en a besoin. Limitez la règle à la source qui nécessite l'accès.
5. Chiffrement abandonné
Le chiffrement échoue en environnement de pré-production, la solution la plus rapide est donc d'arrêter de le vérifier, et le changement est déployé. Les données qui devraient voyager de manière authentifiée et chiffrée voyagent désormais de manière lisible ou modifiable en transit.
const agent = new https.Agent({+ rejectUnauthorized: false,})Désactiver la vérification du certificat signifie que la connexion n'est plus authentifiée, elle peut donc être interceptée par un attaquant en position d'homme du milieu. Gardez la vérification activée et corrigez plutôt le certificat de pré-production.
Pourquoi ces cinq motifs
Le schéma commun à ces cinq motifs est le même : un changement qui améliore une chose, une intégration fonctionnelle, un appelant débloqué, une sortie plus propre, une base de données accessible, une exécution réussie en pré-production, supprime discrètement une mesure de sécurité sur laquelle un cadre de conformité repose. Le dommage en matière de conformité est un effet secondaire d'un objectif raisonnable, ce qui explique précisément pourquoi ni l'auteur ni une révision ordinaire ne le détecte. Personne n'a cherché à affaiblir un contrôle.
C'est pourquoi il est nécessaire de revoir le diff par rapport aux contrôles, au moment où le changement est effectué. Nous avons commencé par ces cinq motifs car ils sont les plus directs : chacun correspond clairement à une clause, et chacun est visible dans le changement lui-même. Nous découvrirons la distribution réelle une fois que heygrc fonctionnera sur de vraies pull requests. En attendant, il s'agit de la carte, et non du territoire, et nous préférons le dire ainsi.