Als je compliance als iets ziet dat in code leeft, volgt er een vraag: welke wijzigingen breken daadwerkelijk een controle? Niet in theorie, maar in de diff. We hebben nog geen productietelemetrie om dat te beantwoorden, dus dit is geen overzicht van wat we in de praktijk hebben gezien. Het is de taxonomie die we hebben gebruikt om heygrc te bouwen: vijf pull-requestpatronen die, door hun opzet, een controle het meest direct breken.
Wat ze verenigt, is ongemakkelijk. Geen van alle ziet eruit als een compliance-wijziging. Elk is een redelijke bewerking: een opschoning, een ontblokkering, een gemak, die toevallig het ding verwijdert waar een framework op vertrouwde. Hier zijn ze.
1. Een geheim in de configuratie
De snelste manier om een integratie werkend te krijgen, is door de sleutel te plaatsen waar de code deze direct kan lezen. Het werkt bij de eerste poging, maar schrijft een live referentie naar de repository, de geschiedenis ervan en elke clone en CI-cache die deze ooit ophaalt. Een gecommit geheim is een blootgesteld geheim, en de enige veilige reactie is om het te roteren.
- const key = process.env.PAYMENTS_SECRET_KEY+ const key = "<the live key, pasted inline>"const client = new Payments(key)De referentie staat nu in versiebeheer voor iedereen met toegang tot de repo, nu of later. Lees deze uit een beheerde geheimenopslag en roteer degene die is gecommit.
2. Verruimde autorisatie
Een autorisatiecontrole staat een wijziging in de weg, dus deze wordt verwijderd of verruimd naar een wildcard om een aanroeper te ontblokkeren. De functionaliteit werkt daarna voor iedereen, inclusief degenen die door de controle juist werden uitgesloten.
export async function getReport(user, id) {- if (!user.can("reports:read")) return forbidden() return reports.find(id)}Door de controle te verwijderen, kan elke geauthenticeerde aanroeper elk rapport lezen, niet alleen de rapporten waartoe ze bevoegd zijn. Herstel de autorisatiecontrole in plaats van deze te omzeilen.
3. Uitgeschakelde logging
Een logregel is storend, dus deze wordt verwijderd tijdens een opschoning. Het systeem werkt nog steeds, maar het stopt met het registreren van de beveiligingsgebeurtenis die een auditor later zal controleren en die je na een incident zou willen hebben.
async function onLogin(userId, ip) {- await audit.log("auth.login", { userId, ip }) return startSession(userId)}De login-gebeurtenis wordt niet meer geregistreerd, dus deze kan niet meer worden gemonitord of achteraf gereconstrueerd. Houd de log bij; als deze te storend is, verander dan het niveau of de bestemming in plaats van deze te verwijderen.
4. Verruimde netwerkregels
Een service kan geen verbinding maken met een database, dus een beveiligingsgroepregel wordt verruimd om de verbinding mogelijk te maken. Het werkt, en dat geldt nu ook voor elke andere verbinding binnen het bereik, inclusief die vanaf het open internet.
ingress { from_port = 5432- cidr_blocks = ["10.0.0.0/16"]+ cidr_blocks = ["0.0.0.0/0"]}Door de regel te openen naar 0.0.0.0/0, wordt de databasepoort blootgesteld aan het hele internet, niet alleen aan de service die deze nodig had. Beperk de regel tot de bron die toegang vereist.
5. Verwijderde versleuteling
Versleuteling mislukt in de staging-omgeving, dus de snelste oplossing is om de verificatie ervan stop te zetten, en de wijziging wordt doorgevoerd. Gegevens die versleuteld en geverifieerd zouden moeten worden, reizen nu op een manier die kan worden gelezen of gemanipuleerd tijdens het transport.
const agent = new https.Agent({+ rejectUnauthorized: false,})Het uitschakelen van certificaatverificatie betekent dat de verbinding niet meer geverifieerd is, waardoor deze kan worden onderschept door een man-in-the-middle-aanval. Houd de verificatie aan en los het certificaatprobleem in staging op.
Waarom deze vijf
Het patroon in alle vijf gevallen is hetzelfde: een wijziging die één ding verbetert, een werkende integratie, een ontblokkerde aanroeper, schonere uitvoer, een bereikbare database, een groene staging-run, verwijdert stilletjes een beveiliging waar een framework van afhankelijk is. De schade aan de compliance is een bijwerking van een redelijk doel, en dat is precies de reden waarom noch de auteur noch een gewone review dit opmerkt. Niemand had de bedoeling om een controle te verzwakken.
Dat is de reden om de diff te controleren tegen de controles, op het moment dat de wijziging wordt doorgevoerd. We zijn met deze vijf begonnen omdat ze het meest direct zijn: elk past naadloos bij een clausule, en elk is zichtbaar in de wijziging zelf. We zullen de daadwerkelijke verdeling leren zodra heygrc draait op echte pull requests. Tot die tijd is dit de kaart, niet het terrein, en we geven dat liever toe.