heygrc
SOC 2 CC6.1 in code

Minimale rechten, afgedwongen op de diff.

CC6.1 is een van de Trust Services Criteria die een gewone pull request stilletjes kan verzwakken, omdat het gaat over logische toegang, en logische toegang bevindt zich vaak in code en configuratie. Het criterium vereist dat toegang tot uw systemen en gegevens beperkt blijft tot de gebruikers en processen die daarvoor geautoriseerd zijn. In de praktijk betekent dit minimale rechten: een rol kan alleen bereiken wat nodig is voor de taak, en niet meer.

How it shows up in a diff

The shapes the same control failure takes.

CC6.1 gaat zelden kapot door een regel die zegt 'geef iedereen admin'. Het gaat kapot door gewone, redelijk ogende wijzigingen. Dit zijn de terugkerende patronen.

  • Een toegangbeleid wordt verruimd

    Een IAM-rol, beveiligingsgroep of toegangsmachtiging krijgt bredere acties of een wildcard, zodat een component nu meer kan doen dan nodig is voor de taak.

  • Een autorisatiecontrole wordt verwijderd

    Een route verliest zijn rol- of eigenaarschapscontrole, of een autorisatiemiddleware wordt niet meer toegepast op een nieuw eindpunt, zodat een verzoek dat afgewezen had moeten worden nu wel slaagt.

  • Een gegevensmachtiging wordt verruimd

    Een databaserol krijgt toegang tot tabellen of rijen die het eerder niet had, rij-niveaubeveiliging wordt versoepeld, of een serviceaccount wordt gekoppeld aan een database waar het geen reden voor had om toegang tot te hebben.

  • Een standaardinstelling verandert in toestaan

    Toegang verandert van standaard-weigeren naar standaard-toestaan: een nieuwe bron wordt wereldwijd leesbaar, of een machtigingscontrole is standaard waar voor een onbekend geval.

  • Een pad voor privilege-escalatie opent

    Een actor met lagere rechten krijgt een manier om op te treden als een actor met hogere rechten: een interne vlag die de rolcontrole omzeilt, of een token dat wordt gegenereerd met meer scope dan de oproeper bezit.

Worked example

Een refactor die een autorisatiecontrole verwijdert.

Een route wordt opgeschoond. De rolcontrole in het midden lijkt redundant naast de auth-middleware, dus die wordt verwijderd. Het eindpunt vereist nog steeds een ingelogde gebruiker, maar niet langer de juiste: nu kan elke geauthenticeerde gebruiker elk project verwijderen.

routes/projects.ts+1 -2
- router.delete("/projects/:id", requireRole("admin"),-   loadProject, deleteProject)+ router.delete("/projects/:id", loadProject, deleteProject)
heygrcSOC 2 CC6.1

Dit verwijdert de rolcontrole van een destructief eindpunt. De auth-middleware bevestigt dat de oproeper is ingelogd, maar CC6.1 gaat over of ze geautoriseerd zijn voor deze actie, en het verwijderen van elk project is niet iets wat elke gebruiker zou moeten kunnen doen. Herstel de autorisatiecontrole (een rol- of eigenaarschapscontrole op het project) voor de handler.

What an auditor does with this

CC6.1 wordt steekproefsgewijs gecontroleerd, niet alleen gesteld.

Bij een SOC 2-onderzoek is CC6.1 niet voldaan door een beleidsdocument dat stelt dat u minimale rechten toepast. De auditor controleert daadwerkelijke toegang: wie en wat toegang heeft tot een bepaald systeem, of die toegangsmachtigingen overeenkomen met gedocumenteerde rollen, en of iets breder is dan de bedoeling. Een wildcard-rol, een eindpunt zonder autorisatiecontrole of een serviceaccount met permanente toegang die nooit wordt gebruikt, is precies het soort uitzondering dat een bevinding wordt, en die is meestal via een enkele pull request maanden eerder in het systeem gekomen. Het opvangen van de wijziging bij de diff helpt om die toegangsuitzonderingen buiten de steekproef te houden.

What this is, and is not

Een review, geen attestatie.

heygrc markeert wijzigingen die CC6.1 raken en verwijst naar het criterium, zodat de correctie in de pull request plaatsvindt. Het voert geen audit uit of geeft geen oordeel. Het vangt de toegangswijziging vroeg op, zodat het onderzoek minder uitzonderingen hoeft uit te leggen.