Wenn man Compliance als etwas behandelt, das im Code lebt, stellt sich eine Frage: Welche Änderungen brechen tatsächlich eine Kontrolle? Nicht in der Theorie, sondern im Diff. Wir haben noch keine Produktions-Telemetrie, um das zu beantworten, also ist dies keine Statistik dessen, was wir in der Praxis gesehen haben. Es ist die Taxonomie, für die wir heygrc entwickelt haben: fünf Pull-Request-Muster, die nach Konstruktion eine Kontrolle am direktesten brechen.
Was sie vereint, ist unangenehm. Keines sieht wie eine Compliance-Änderung aus. Jedes ist eine sinnvolle Bearbeitung, eine Bereinigung, eine Entsperrung, eine Vereinfachung, die zufällig die Sache entfernt, auf die ein Framework angewiesen war. Hier sind sie.
1. Ein Geheimnis in der Konfiguration
Der schnellste Weg, eine Integration zum Laufen zu bringen, besteht darin, den Schlüssel dort abzulegen, wo der Code ihn direkt lesen kann. Es funktioniert beim ersten Versuch und schreibt eine aktive Anmeldedaten in das Repository, dessen Verlauf und in jeden Clone und CI-Cache, der sie jemals abruft. Ein committetes Geheimnis ist ein freigelegtes Geheimnis, und die einzige sichere Reaktion ist, es zu rotieren.
- const key = process.env.PAYMENTS_SECRET_KEY+ const key = "<the live key, pasted inline>"const client = new Payments(key)Die Anmeldedaten liegen nun in der Versionskontrolle und sind für jeden mit Repo-Zugriff, jetzt oder später, zugänglich. Lesen Sie sie aus einem verwalteten Geheimnis-Speicher und rotieren Sie das committete Geheimnis.
2. Gelockerte Authentifizierung
Eine Autorisierungsprüfung blockiert eine Änderung, also wird sie entfernt oder auf einen Platzhalter erweitert, um einen Aufrufer zu entsperren. Das Feature funktioniert danach für alle, einschließlich der Personen, die durch die Prüfung ausgeschlossen werden sollten.
export async function getReport(user, id) {- if (!user.can("reports:read")) return forbidden() return reports.find(id)}Durch das Entfernen der Prüfung kann jeder authentifizierte Aufrufer jeden Bericht lesen, nicht nur die, auf die er berechtigt ist. Stellen Sie die Autorisierungsprüfung wieder her, anstatt sie zu umgehen.
3. Deaktivierte Protokollierung
Eine Protokollzeile ist zu laut, also wird sie bei einer Bereinigung entfernt. Das System funktioniert weiterhin, es hört nur auf, das Sicherheitsereignis aufzuzeichnen, das ein Prüfer später stichprobenartig überprüfen würde und das man nach einem Vorfall benötigen würde.
async function onLogin(userId, ip) {- await audit.log("auth.login", { userId, ip }) return startSession(userId)}Das Login-Ereignis wird nicht mehr aufgezeichnet, sodass es später nicht überwacht oder rekonstruiert werden kann. Behalten Sie die Protokollierung bei. Falls sie zu laut ist, ändern Sie stattdessen ihre Ebene oder das Ziel, anstatt sie zu löschen.
4. Erweiterte Netzwerkregeln
Ein Dienst kann nicht auf eine Datenbank zugreifen, also wird eine Sicherheitsgruppenregel geöffnet, um die Verbindung herzustellen. Sie funktioniert, und das gilt nun auch für alle anderen Verbindungen im Bereich, einschließlich solcher aus dem offenen Internet.
ingress { from_port = 5432- cidr_blocks = ["10.0.0.0/16"]+ cidr_blocks = ["0.0.0.0/0"]}Durch das Öffnen der Regel für 0.0.0.0/0 wird der Datenbankport dem gesamten Internet ausgesetzt, nicht nur dem Dienst, der ihn benötigt. Beschränken Sie die Regel auf die Quelle, die Zugriff erfordert.
5. Deaktivierte Verschlüsselung
Die Verschlüsselung schlägt in der Staging-Umgebung fehl, also ist die schnellste Lösung, die Überprüfung zu deaktivieren, und die Änderung wird ausgeliefert. Daten, die authentifiziert und verschlüsselt übertragen werden sollten, werden nun auf eine Weise übertragen, die im Transit gelesen oder manipuliert werden kann.
const agent = new https.Agent({+ rejectUnauthorized: false,})Durch das Deaktivieren der Zertifikatsüberprüfung ist die Verbindung nicht mehr authentifiziert und kann durch einen Man-in-the-Middle-Angriff abgefangen werden. Behalten Sie die Überprüfung bei und beheben Sie stattdessen das Staging-Zertifikat.
Warum diese fünf
Das Muster bei allen fünf ist dasselbe: Eine Änderung, die eine Sache verbessert - eine funktionierende Integration, ein entsperrter Aufrufer, eine saubere Ausgabe, eine erreichbare Datenbank, ein erfolgreicher Staging-Lauf - entfernt leise eine Schutzmaßnahme, von der ein Framework abhängt. Der Compliance-Schaden ist ein Nebeneffekt eines vernünftigen Ziels, und genau das ist der Grund, warum weder der Autor noch eine normale Überprüfung ihn erkennt. Niemand hat beabsichtigt, eine Kontrolle zu schwächen.
Das ist der Grund, warum der Diff gegen die Kontrollen überprüft werden sollte, im Moment, in dem die Änderung vorgenommen wird. Wir haben mit diesen fünf begonnen, weil sie am direktesten sind: Jedes lässt sich klar einer Klausel zuordnen, und jedes ist im Diff selbst sichtbar. Wir werden die tatsächliche Verteilung kennenlernen, sobald heygrc auf echten Pull Requests läuft. Bis dahin ist dies die Karte, nicht das Gebiet, und wir würden das lieber so sagen.