Control-Map · Trust Services Criteria (2017)
SOC 2
Code-Nachweis für Zugriffs-, Abgrenzungs- und Vertraulichkeitskriterien bei jedem Pull Request und Prozessnachweis für Änderungsfreigaben aus jedem Merge.
Code-Nachweis
6Kriterien, bei jedem Pull Request geprüftLive (Prozess)
1aus Merges, Freigaben, Regeländerungen sowie von GitHub erfassten Deployments und ReleasesGeplant
8lässt sich aus Code oder GitHub belegen; noch nicht gebautKriterien auf Organisationsebene
Richtlinien, Personal, Lieferanten, physische Sicherheit und Ähnliches, unten aufgelistet.Von den Abläufen Ihrer Organisation verantwortetEin SOC-2-Type-II-Bericht prüft, ob Controls über einen Zeitraum hinweg gewirkt haben. Bei Änderungsfreigaben verbringen Engineering-Teams im Audit meist die meiste Zeit: Sie sammeln Tickets und Screenshots für eine Stichprobe von Änderungen.
Der SOC-2-Blueprint liefert bei jedem Pull Request Code-Nachweise für die Zugriffs-, Abgrenzungs- und Vertraulichkeitskriterien. Jeder in den Standard-Branch gemergte Pull Request wird als Änderungseintrag mit Freigaben, Checks und Signaturen versiegelt: Nachweis für CC8.1. Die vollständige Map steht unten, die Kriterien auf Organisationsebene danach.
Toevan liefert Nachweise für Controls; es zertifiziert sie nie und behauptet nie, ein Framework sei abgedeckt. Ob die Nachweise genügen, beurteilt Ihr Auditor. Controls stehen mit ihrer ID und Toevans eigenen Kurznamen; die offiziellen Titel und der Anforderungstext gehören dem Herausgeber des Frameworks.
Code-Nachweis6
Bei jedem Pull Request versiegelt. Immer nur teilweise: Das Control verlangt auch Dinge außerhalb des Codes. Regeln im Blueprint SOC 2 prüfen bei jedem Pull Request einen Teil davon.
CC6.1Gestaltung von ZugriffsgrenzenCC6 ZugriffsschutzCC6.3Änderung von RollenrechtenCC6 ZugriffsschutzCC6.6Schutz vor externen BedrohungenCC6 ZugriffsschutzCC6.7Grenzen der DatenbewegungCC6 ZugriffsschutzC1.1Kennzeichnung vertraulicher DatenC1 Vertrauliche DatenC1.2Entsorgung vertraulicher DatenC1 Vertrauliche Daten
Live (Prozess)1
Gemergte Pull Requests, Freigaben, Pflicht-Checks, Branch-Schutz, Rulesets und Umgehungen sowie von GitHub erfasste Deployments und Releases, jeweils versiegelt.
CC8.1ÄnderungsfreigabenCC8 ÄnderungsabwicklungProzessnachweis: Jeder in den Standard-Branch gemergte Pull Request wird als Änderungseintrag versiegelt, mit seinen Freigaben auf dem finalen Commit, den Pflicht-Checks beim Merge, der mergenden Person, seinen Signaturen und den mitgeführten Code-Urteilen.
Änderungseintrag rec_5b81d4e
BeispieldatenGeplant8
Lässt sich aus Code oder GitHub belegen. Noch keine Regel prüft diese; jedes ist geplant, und keines zählt heute als Nachweis.
CC6.2Vergabe von ZugangsdatenCC6 ZugriffsschutzCC7.1Überwachung von Schwachstellen-DriftCC7 SicherheitsbetriebCC7.2Überwachung von AnomalienCC7 SicherheitsbetriebA1.2Schutz von BackupsA1 Kapazität und BackupPI1.2Vollständige, korrekte EingabenPI1 VerarbeitungsgenauigkeitPI1.3Verlustfehler in der VerarbeitungPI1 VerarbeitungsgenauigkeitP4.2Aufbewahrung personenbezogener DatenP4 Nutzung und AufbewahrungP4.3Löschung personenbezogener DatenP4 Nutzung und Aufbewahrung
Kriterien auf Organisationsebene
Controls auf Organisationsebene (Richtlinien, Personal, Lieferanten, physische Sicherheit und Ähnliches) bleiben beim eigenen Prozess Ihrer Organisation; Toevan übernimmt sie nicht.
Liste anzeigen
CC1 Verhalten der Leitung
CC2 Informationsaustausch
CC3 Risikoprüfung
CC4 Control-Überwachung
CC5 Control-Auswahl
CC6 Zugriffsschutz
CC7 Sicherheitsbetrieb
CC9 Lieferantenrisiko
A1 Kapazität und Backup
PI1 Verarbeitungsgenauigkeit
P1 Hinweispflichten
P2 Wahlpflichten
P3 Erhebungspflichten
P4 Nutzung und Aufbewahrung
P5 Anfragen Einzelner
P6 Weitergabepflichten
P7 Datenqualität
P8 Umgang mit Beschwerden
Im Audit verwenden
- Grundgesamtheit aus den Änderungseinträgen entnehmen
Jeder in den Standard-Branch gemergte Pull Request und jeder Push auf einen geschützten Branch, den kein gemergter Pull Request erklärt, im Zeitraum, beim Eintreten aus GitHub erfasst, ist ein versiegelter Eintrag, den Sie für die Stichprobe exportieren können. Die Grundgesamtheit des Standard-Branches können Sie aus der Git-Historie nachvollziehen; festgelegte Produktions-Branches sind geplant.
- Code-Nachweise des Zeitraums lesen
Jeder Pull Request trägt versiegelte Code-Ergebnisse zu den Regeln des Blueprints, festgemacht am Commit und an der geltenden Regelsatz-Version.
- Stichprobe testen
Prüfen Sie für jeden gezogenen Eintrag zuerst die Ergebnisse und dann offline gegen den veröffentlichten Schlüssel mit openssl und der Shell: Nachweis holen, Schlüssel bestätigen, Eintrag prüfen. Um die ganze Kette nachzuvollziehen, stellt Toevan den toevan-Befehl auf Anfrage bereit; er ist noch nicht öffentlich.
- Neu berechnet
- Toevan hat es selbst aus Code oder Git-Historie berechnet.
- Gemeldet + versiegelt
- GitHub hat es gemeldet; Toevan hat es beim Ereignis erfasst und signiert.
- Erklärt + versiegelt
- Die Organisation hat es erklärt, etwa eine Änderung dessen, was geprüft wird; Toevan hat die Erklärung und ihre Historie signiert.
- Toevan-Eintrag, nicht versiegelt
- In der Datenbank von Toevan gespeichert, aber nicht im Ledger versiegelt, etwa eine Ausnahmegenehmigung heute. Keine Signatur schützt ihn.
- Übernommen
- Aus den Deployment- und Release-Einträgen von GitHub übernommen und per Commit oder Digest verknüpft.
- Nicht erfasst
- Es gab keine verlässliche Quelle. Toevan schließt nichts daraus.
Neu berechnet aus der Git-Historie aufgelistet und mit den versiegelten Einträgen abgeglichen
Testen Sie die Zuordnung an einem echten Audit.
Bringen Sie ein Repository und ein anstehendes Audit mit. Wir richten den Blueprint ein und führen Ihren Prüfer durch die Verifikation.
- Ein Repository, ein Framework
- Nachweise ab dem ersten Pull Request
- Prüfbar ohne Toevan-Konto