Drive-Zugriffsprüfung für ISO 27001 und SOC 2

8apps-Team·

Was ein ISO-27001- oder SOC-2-Prüfer von einer Google Drive Zugriffsprüfung erwartet: Umfang, Prüfer, Feststellungen, Entscheidungen, nächster Termin – kein Screenshot.

Die Zeile auf der Nachweisliste

Die Anforderungsliste des Prüfers trifft ein, und eine Zeile lautet sinngemäß „Nachweis der regelmäßigen Prüfung von Zugriffen auf Dateifreigabe-Plattformen (Google Drive)". Sie haben ein Drive-Protokoll, eine vage Erinnerung, im März hineingeschaut zu haben, und nichts, das sagt, was Sie gefunden oder getan haben.

Das Beruhigende daran: Der Prüfer fragt nicht, ob Google zertifiziert ist oder ob irgendein von Ihnen genutztes Werkzeug es ist. Er fragt, ob Ihre Organisation hingesehen, entschieden hat und wieder hinsehen wird – und ob Sie das belegen können. Das ist ein Dokumentationsproblem mit einer wiederholbaren Antwort.

Drei Arbeitsdateien tragen diese Antwort: eine quartalsweise Checkliste, ein Bericht über externe Freigaben – eine Zeile je offen liegender Datei, mit einer Entscheidung und einem Namen dazu – und ein Nachweisprotokoll mit einer Zeile je Prüfung. In diesem Beitrag geht es um das Nachweisprotokoll.

Was eine Zugriffsprüfung zeigen muss

ISO/IEC 27001 ist die Norm für Informationssicherheits-Managementsysteme; sie definiert Anforderungen, die ein Managementsystem erfüllen muss. Ein SOC-2-Bericht ist eine Prüfung des AICPA zu den Kontrollen eines Dienstleisters in Bezug auf Sicherheit, Verfügbarkeit, Verarbeitungsintegrität, Vertraulichkeit oder Datenschutz. Keine von beiden schreibt ein Google-spezifisches Format für die Prüfung von Drive-Freigaben vor. Der Prüfer testet, ob die von Ihnen beschriebene Kontrolle – „wir prüfen externe Zugriffe auf Drive regelmäßig" – tatsächlich wirkt und ob die Nachweise das zeigen.

In der Praxis verlangen Prüfer von einer Zugriffsprüfung typischerweise fünf Dinge:

  1. Umfang – welche Systeme, Daten und welcher Zeitraum. „Alle außerhalb der Domain freigegebenen Google Drive Dateien, 1. April bis 30. Juni" ist ein Umfang. „Drive" nicht.
  2. Wer geprüft hat – eine benannte Person, dazu diejenige, die Entscheidungen freigegeben hat, falls das jemand anderes ist.
  3. Was gefunden wurde – Zahlen und eine Liste: öffentliche Links, externe Freigaben, Freigaben an Domains, mit denen Sie nicht mehr arbeiten.
  4. Was entschieden wurde – mit Begründung behalten, eingeschränkt oder übertragen, und durch wen.
  5. Wann es das nächste Mal stattfindet – ein Datum und ein Verantwortlicher.

Erzeugen Sie diese fünf für jedes Quartal des Prüfzeitraums, und Sie haben eine Prüfung. Erzeugen Sie nur den ersten und dritten Punkt, haben Sie einen Bericht. Erzeugen Sie keinen davon, haben Sie ein Protokoll.

Warum ein Screenshot des Drive-Protokolls keine Prüfung ist

Der erste Reflex ist, Menü → Berichte → Audit und Untersuchung → Drive-Protokollereignisse zu öffnen, auf das Attribut „Sichtbarkeitsänderung" zu filtern, das Ergebnis zu fotografieren und anzuhängen. Das ist ein Beleg dafür, dass etwas existiert, aber kein Nachweis einer Prüfung – aus vier Gründen.

Das Protokoll ist Aktivitätshistorie, keine Berechtigungskarte. Es zeigt, dass sich die Sichtbarkeit einer Datei im Zeitfenster geändert hat; eine Datei, die schon vorher öffentlich oder extern war, erzeugt kein Ereignis. Das Protokoll kann den aktuellen Offenlegungszustand also nicht beschreiben.

Das Protokoll ist zeitlich begrenzt. Die Standardansicht zeigt die letzten 7 Tage, und Drive-Protokollereignisse werden 6 Monate aufbewahrt. Einem Prüfer, der zwölf Monate betrachtet, können Sie im vierten Quartal das erste nicht mehr aus dem Protokoll zeigen – siehe den Beitrag zur Aufbewahrung.

Das Protokoll hat bauartbedingt blinde Flecken: Externe Nutzer erscheinen als anonym, sofern das Element nicht einzeln oder über eine bestimmte Gruppe mit ihnen geteilt wurde.

Und ein Screenshot enthält keine Entscheidungen. Kein Name steht darauf; nichts sagt „behalten, der Kunde braucht es" oder „eingeschränkt am 3. Juli". Fehlende Entscheidungen sind das Erste, was einem Prüfer auffällt.

Die drei Artefakte, die eine Prüfung nachvollziehbar machen

Nachvollziehbar heißt: Eine zweite Person käme mit denselben Eingaben zu denselben Feststellungen und könnte dieselben Entscheidungen überprüfen. Drei Dateien leisten das.

Das Nachweisprotokoll ist das Register. Eine Zeile je Prüfung: Prüfdatum, Zeitfenster, Verantwortlicher, Edition, geprüfte Dateien, gefundene öffentliche, externe und Alt-Zugriffe, eingeschränkt, begründet, Vorfälle, nächstes Prüfdatum, nächster Verantwortlicher. Vier Zeilen decken ein Jahr ab; reichen Sie es zuerst ein.

Der Berichtsexport enthält die Feststellungen und Entscheidungen hinter jeder Zeile: jede offen liegende Datei, ihr Eigentümer, ihr Ort, die Art der Offenlegung, mit wem sie geteilt ist, die Entscheidung, wer entschieden hat und wann es umgesetzt wurde. Der Beitrag zur Berichtsvorlage geht die Spalten durch. Exportieren Sie ihn am Tag der Prüfung, datiert, und bewahren Sie ihn beim Protokoll auf.

Ein Zustandsartefakt zu einem Stichtag ist das, was das Protokoll nicht liefern kann: was am Tag der Prüfung offen lag, unabhängig davon, wann es offen wurde. Woher es kommt, hängt von Ihrer Edition ab. In Enterprise Standard und Plus, Education Standard und Plus, Frontline Plus, Enterprise Essentials Plus und Cloud Identity Premium schreibt der Drive-Inventarexport Dateimetadaten einschließlich der Angabe, mit wem jede Datei geteilt ist, nach BigQuery – jeder Export überschreibt den vorherigen, legen Sie also eine datierte Kopie an. In Business Editionen sind die nativen Wege die Mitgliederlisten aus „Geteilte Ablagen verwalten" plus Suchen pro Nutzer mit sharedwith:external owner:me, die der Administrator für andere nicht ausführen kann. Ein organisationsweiter Scan-Export – die „Meine Ablage" jedes Nutzers und jede geteilte Ablage, datiert – füllt diese Lücke für Administratoren von Business Editionen und ist das, worauf der Wert „Gefunden durch" = scan in der Berichtsvorlage verweist.

Die quartalsweise Checkliste bringt die drei Artefakte in eine Reihenfolge; der Leitfaden zur organisationsweiten Prüfung von Drive-Zugriffen ist die Langfassung.

Rhythmus, Verantwortung und die Regel für Ausscheidende

Prüfer fragen typischerweise, wie oft – und ob das eingehalten wurde. Standardmäßig quartalsweise; monatlich, wenn Sie reguliert sind oder ein Kundenvertrag es verlangt; immer nach einem Weggang, denn die Sperrung rührt die von dieser Person erzeugten Freigaben nicht an – Mitarbeitende, denen Zugriff auf freigegebene Dokumente gewährt wurde, behalten ihn. Gesperrt ist nicht gelöscht erklärt diese Lücke.

Schreiben Sie den Rhythmus neben das Nachweisprotokoll, damit Prüfer und Zeitplan ein Dokument sind. Der Name in „nächster Verantwortlicher" ist die wirksame Kontrolle; eine leere Zelle ist die nicht wirksame Kontrolle.

Was Sie übergeben

Ein Ordner je Quartal: die Zeile aus dem Nachweisprotokoll, der datierte Berichtsexport, das datierte Zustandsartefakt und ein Screenshot, der berechtigterweise Zustand statt Historie zeigt – die Freigabeeinstellungen unter Menü → Apps → Google Workspace → Drive und Docs, mit dem Domain-Standard und etwaigen Abweichungen je Organisationseinheit. Dieser Ordner ist die Prüfung. Nichts darin braucht die Zertifizierung irgendeines Werkzeugs; es braucht Ihren Namen, Ihr Datum und Ihre Entscheidungen.

Quellen