Kann eine SOC-2-Nachweistabelle Agent-Aktionen belegen?

Agent-Aktivitäten schaffen ein Auditproblem, das gewöhnliche Anwendungsprotokolle nicht lösen. Das Protokoll eines Dienstkontos kann zeigen, dass ein Zugangsschlüssel einen Endpunkt aufgerufen hat. Meist zeigt es aber nicht, ob ein bestimmter Agent-Prozess zu diesem Zeitpunkt dazu berechtigt war, ob ein Mensch die Aktion genehmigt hatte, ob die Berechtigung später entzogen wurde oder ob der Datensatz, den Sie einem Auditor übergeben, tatsächlich dem ursprünglich erzeugten Datensatz entspricht.

Ein brauchbares SOC-2-Nachweispaket muss eine Entscheidung rekonstruieren, nicht lediglich eine Zeitleiste anzeigen. Für jede wichtige Aktion sollte ein Auditor vom Akteur und seiner Autorisierung über den Aufruf und das Ergebnis bis zur Integrität des gespeicherten Datensatzes gelangen können. Wenn eine dieser Verknüpfungen vom Gedächtnis eines Administrators oder einer manuell bearbeiteten Tabelle abhängt, ist die Kontrolle schwächer, als sie zunächst wirkt.

Sallyport basiert auf genau dieser Kette: Ein Agent erhält die Ergebnisse von Aktionen, während die Zugangsdaten im lokalen verschlüsselten Tresor bleiben und die Anwendung den Agent-Lauf sowie jeden einzelnen Aufruf protokolliert. Dieses Design hilft aber nur, wenn Sie die Datensätze in prüfbare Nachweise verwandeln, statt das Journal als bloße Compliance-Kulisse zu behandeln.

Eine Kontrolle braucht eine rekonstruierbare Entscheidung

Die Trust Services Criteria des AICPA aus dem Jahr 2017 sind Kriterien, keine Sammlung von Screenshots. Die allgemeinen Sicherheitskriterien verlangen, dass das Management Kontrollen einrichtet und betreibt, die logischen Zugriff beschränken, den Systembetrieb überwachen, auf erkannte Probleme reagieren und Änderungen steuern. Ein Auditor prüft die beschriebene Kontrolle, ihre Population und ihre Wirksamkeit während des Prüfungszeitraums.

Für Agent-Aktionen ist diese Unterscheidung wichtig. «Der Agent brauchte eine Genehmigung» beschreibt ein Produktverhalten. «Jeder neu gestartete Agent-Prozess benötigte eine zuordenbare Autorisierung, bevor er einen geschützten Aktionskanal verwenden konnte, und das Unternehmen bewahrte Datensätze auf, die diese Autorisierung mit den daraus resultierenden Aufrufen verknüpfen» ist eine prüfbare Kontrollaussage.

Formulieren Sie das Risiko, bevor Sie die Nachweisanforderung formulieren. Eine praktische Risikobeschreibung könnte so lauten:

Ein nicht genehmigter oder zuvor genehmigter Agent-Prozess könnte mit Unternehmenszugangsdaten eine externe API oder einen SSH-Befehl aufrufen und dadurch unbefugten Zugriff oder eine nicht autorisierte operative Änderung verursachen.

Die Kontrolle sollte dieses Risiko in klarer Sprache beantworten. Der Nachweis sollte fünf engere Fragen beantworten:

1. Welcher Prozess hat die Aktion versucht?
2. Welche Berechtigung hatte er zu diesem Zeitpunkt?
3. Wer hat diese Berechtigung erteilt, falls überhaupt jemand?
4. Welche konkrete externe Aktion folgte?
5. Kann jemand erkennen, dass versucht wurde, die Historie umzuschreiben?

Teams vermischen diese Fragen häufig. Sie bezeichnen eine Positivliste für Ziele als Genehmigungskontrolle, einen erfolgreichen API-Antwortwert als Autorisierungsnachweis oder einen Log-Export als unveränderlich, weil der Export schreibgeschützt ist. Jede dieser Aussagen beschreibt etwas anderes.

Eine Zielbeschränkung begrenzt, wo ein Prozess handeln darf. Autorisierungsdatensätze zeigen, wer einem Prozess das Handeln erlaubt hat. Aufrufdatensätze belegen, was der Prozess versucht hat und was dabei geschah. Eine Integritätsprüfung beantwortet die Frage, ob die gespeicherte Reihenfolge verändert wurde. Trennen Sie diese Aussagen in der Systembeschreibung und in der Nachweistabelle. Auditoren brauchen keine modische Sprache. Sie brauchen einen Kontrollverantwortlichen, der eine begrenzte Aussage treffen und den passenden Nachweis vorlegen kann.

Die prüfbare SOC-2-Nachweistabelle

Verwenden Sie eine Nachweistabelle als gemeinsame Arbeitsgrundlage für Entwicklung, Sicherheit und Auditor. Machen Sie daraus keine Liste von Produktfunktionen. Jede Zeile sollte das Risiko, die Kontrollaktivität, die Nachweispopulation, die wahrscheinliche Kriterienzuordnung, die Prüfmethode und das Fehlersignal nennen.

Die Kriterienverweise sind Ausgangspunkte, keine Zusage vollständiger Abdeckung. Ihre Systembeschreibung, Risikobewertung, Systemgrenzen und die Einschätzung des Auditors bestimmen die endgültige Zuordnung. Ordnen Sie insbesondere nicht jeden Agent-Datensatz CC8.1 zu. Die Beispiele und Leitlinien des AICPA behandeln das Änderungsmanagement als Kontrolle von Änderungen an Anwendungsprogrammen und der zugehörigen Technologie. Ein Aufruf, der ein Kundenkonto bearbeitet, eine Supportantwort sendet oder einen entfernten Prozess neu startet, ist eine operative Aktion. Erst wenn er Teil einer genehmigten und getesteten Änderung am System selbst ist, wird er zum Nachweis für das Änderungsmanagement.

Die Tabelle verhindert außerdem einen häufigen Fehler in der Auditwoche: einen perfekten Beleg von nur einem Tag zu sammeln. Bei einer Typ-2-Prüfung geht es darum, ob die beschriebenen Kontrollen während des gesamten Zeitraums wirksam betrieben wurden. Die Spalte «Population» ist keine Bürokratie. Sie zeigt, welche vollständige Grundgesamtheit Sie vorlegen können müssen, bevor jemand daraus Stichproben zieht.

Die Session-Genehmigung belegt Prozessberechtigung, nicht die Identitätsverwaltung

Eine Genehmigung pro Session belegt, dass ein bestimmter Agent-Lauf die Erlaubnis erhalten hat, das Aktions-Gateway zu verwenden. Sie belegt nicht, dass Ihr Unternehmen den Mitarbeiterzugriff korrekt verwaltet, ein Konto beim Identity Provider richtig eingerichtet oder eine Cloud-Administratorrolle überprüft hat. Dafür brauchen Sie eigene Kontrollen und Datensätze.

Die sinnvolle Aussage ist enger gefasst: Der erste geschützte Aufruf eines neuen Prozesses erhält eine Genehmigungsentscheidung, bevor die Session handeln darf. Der Datensatz sollte die Session-ID, die Prozessidentität, sofern verfügbar die Code-Signaturberechtigung, den Entscheidungszeitpunkt, die Identität des Genehmigers und den Beendigungsstatus enthalten. In Sallyport steht auf der Genehmigungskarte die Code-Signaturberechtigung des Prozesses im Vordergrund. So bezieht sich die menschliche Entscheidung auf die tatsächlich zugreifende ausführbare Datei und nicht auf eine beliebige Bezeichnung, die der Agent liefert.

Das ist ein wichtiger Unterschied. Ein Agent kann sich in einem Prompt, einem Terminaltitel oder einem Prozessargument nennen, wie er möchte. Eine Kontrolle, die einen selbst gemeldeten Namen genehmigt, lädt zu einer einfachen Umgehung ein. Eine Kontrolle, die die Code-Signaturberechtigung zeigt, gibt dem Prüfer ein stabiles Merkmal zur Bewertung. Sie beseitigt nicht die Notwendigkeit, der signierten Software zu vertrauen, macht die Vertrauensgrenze aber ehrlich sichtbar.

Für einen Test der Session-Genehmigung sollte der Auditor eine Stichprobe aus der Session-Population auswählen und jeden Datensatz in beide Richtungen verfolgen:

• Beginnen Sie mit der Session-Genehmigung und suchen Sie den ersten geschützten Aufruf, der darauf folgte.
• Beginnen Sie mit einem Aktivitätseintrag und suchen Sie die Session, die ihn autorisiert hat.
• Bestätigen Sie, dass der Zeitpunkt des Aufrufs nach der Genehmigung und vor dem Ende oder Widerruf der Session liegt.
• Bestätigen Sie, dass abgelehnte Sessions keine erfolgreichen geschützten Aufrufe haben.
• Bestätigen Sie, dass der Session-Datensatz den Prozess für die beschriebene Kontrolle ausreichend eindeutig identifiziert.

Verlassen Sie sich nicht auf einen Screenshot des Genehmigungsdialogs. Screenshots helfen bei der Dokumentation des Kontrolldesigns, sind aber kein Populationsnachweis. Ein Datensatz muss nach dem Schließen des Dialogs erhalten bleiben, sich anhand einer ID abfragen lassen und ohne menschliche Auswahl nach dem Prinzip «diese Zeile sieht richtig aus» mit dem Aktivitätsdatensatz verknüpft werden können.

Behaupten Sie außerdem nicht, dass eine Session-Genehmigung das Prinzip der geringsten Berechtigung erfüllt, wenn sie das nicht tut. Eine Session-Entscheidung kann steuern, ob ein Prozess überhaupt handeln darf. Die geringste Berechtigung hängt von Zugangsdaten, Zielumfang, Operationen und Berechtigungen ab, die nach der Genehmigung verfügbar sind. Wenn ein genehmigter Agent Zugangsdaten mit uneingeschränkten Produktionsrechten verwenden kann, ist die Genehmigung ein Zugangstor, keine Verringerung des Umfangs. Beschreiben Sie sie entsprechend.

Eine Genehmigung pro Aufruf gilt für Aktionen, die sich nicht sicher bündeln lassen

Eine Kontrolle mit Genehmigung pro Aufruf bietet eine andere Sicherheit als die Session-Genehmigung. Sie verlangt eine neue menschliche Entscheidung genau in dem Moment, in dem bestimmte Zugangsdaten verwendet werden sollen. Nutzen Sie sie für Aktionen, bei denen das Risiko im einzelnen Aufruf liegt und nicht nur darin, dass ein Agent-Prozess seine Arbeit beginnen darf.

Geeignet sind etwa Produktionszugangsdaten, mit denen Zugriffsrechte geändert, Daten gelöscht, Abrechnungsinformationen verändert, eine Bereitstellung veröffentlicht oder Befehle auf einem besonders sensiblen Host ausgeführt werden können. Ziel ist nicht, jede Agent-Aktion umständlich zu machen. Die Prüfung soll an der Transaktionsgrenze stattfinden, an der ein einzelner Missbrauch relevant wäre.

Der Nachweis muss die Genehmigung an eine einzelne Nutzung binden. Ein belastbarer Aktivitätsdatensatz enthält mindestens:

• Eine eindeutige Aufruf-ID und die zugehörige Session-ID.
• Die Referenz auf die geschützten Zugangsdaten, ohne deren geheimen Wert im Datensatz abzulegen.
• Kanal, Ziel, Operation und Zeitstempel.
• Entscheidungsstatus und Genehmiger bei einem genehmigungspflichtigen Aufruf.
• Das Ergebnis, einschließlich abgelehnter, fehlgeschlagener oder abgeschlossener Aufrufe.

Akzeptieren Sie keinen Genehmigungsdatensatz, der lediglich zeitlich in der Nähe einer späteren Aktion erscheint. Zeitliche Nähe ist keine Verknüpfung. Wenn ein Prüfer Aufruf A genehmigt und der Agent anschließend Aufruf B mit denselben Zugangsdaten ausführt, muss der Nachweis zeigen, ob B unabhängig eine Genehmigung benötigte und erhalten hat.

Hier reagieren Teams oft über. Sie setzen einen Menschen vor routinemäßige Leseaktionen, worauf Prüfer eine Reihe nahezu identischer Karten genehmigen, ohne hinzusehen. Die Kontrolle erzeugt zwar weiterhin Datensätze, aber die Prüfung ist zeremoniell geworden. Beschränken Sie die Genehmigung pro Aufruf auf die kleine Gruppe von Zugangsdaten oder Aktionen, die sie wirklich verdient. Verwenden Sie für die normale Arbeit die Session-Genehmigung und reduzieren Sie den Umfang der Zugangsdaten separat.

Ein Prüfer braucht ausreichend Kontext für eine Entscheidung. Bei einer HTTP-Aktion gehören dazu meistens Methode, Ziel, Identität der Zugangsdaten und eine sichere Beschreibung der Wirkung des Requests. Bei SSH gehören die Host-Identität und der Befehl oder eine begrenzte Befehlsbeschreibung dazu. Legen Sie niemals das Geheimnis selbst in die Genehmigungsdaten, nur um den Nachweis ausführlicher zu machen. Ein Geheimnis, das über eine Genehmigungskarte an einen Prüfer gelangt, ist weiterhin offengelegt.

Ein Widerruf muss eine nachweisbare Ablehnung erzeugen

Ein Widerrufsnachweis ist wertlos, wenn er nur ein Ereignis in der Benutzeroberfläche festhält. Die Kontrolle funktioniert dann, wenn die Berechtigung endet und ein späterer Versuch aus genau diesem Grund scheitert.

Führen Sie diesen Test durch, bevor ein Audit ihn verlangt. Starten Sie eine Session, die eine Testaktion in einer Nichtproduktionsumgebung ausführen darf. Bestätigen Sie einen erfolgreichen Aufruf. Widerrufen Sie die Session, während der Prozess weiterläuft. Lassen Sie denselben Prozess anschließend einen zweiten Aufruf versuchen. Bewahren Sie die vier verknüpften Datensätze auf: den ersten erfolgreichen Aufruf, das Widerrufsereignis, den zweiten abgelehnten Aufruf und den Session-Status.

Ihr Testformular kann so schlicht aussehen:

Test-ID: AGT-REV-01
Session-ID: ____________________
ID und Ergebnis des ersten Aufrufs: ____________________
Zeitpunkt und Akteur des Widerrufs: ____________________
ID und Ablehnungsergebnis des zweiten Aufrufs: ____________________
Angezeigter Ablehnungsgrund: ____________________
Prüfer und Datum: ____________________

Die Reihenfolge ist der Kern der Kontrolle. Auf einen Widerruf um 14:03 Uhr folgt um 14:07 Uhr ein erfolgreicher Aufruf. Das ist entweder ein Fehler, ein Zeitproblem oder ein Hinweis darauf, dass die Session-ID nicht die Bedeutung hat, die Sie ihr zugeschrieben haben. Keine dieser Erklärungen darf einfach beiseitegeschoben werden.

Behandeln Sie ein normales Session-Ende und einen ausdrücklichen Widerruf unterschiedlich. Das Ende beendet einen Prozess, weil er nicht mehr läuft. Der Widerruf beendet eine Berechtigung, weil ein Prüfer sie entziehen wollte. Beide sollten spätere Aufrufe blockieren, aber nur der Widerruf zeigt, dass ein Mensch einen laufenden Prozess als Reaktion auf einen Verdacht beenden kann. Führen Sie die Ereignistypen in der Nachweistabelle getrennt.

Diese Kontrolle gehört auch in die Praxis der Incident Response. Wenn ein Prüfer eine verdächtige Folge von Aufrufen sieht, sollte er wissen, wer den Lauf widerrufen kann, wie schnell die Ablehnung wirksam wird und wo das Ereignis im Journal erscheint. Eine schriftliche Anweisung, die lediglich «Agent deaktivieren» sagt, reicht nicht aus, wenn der Agent bereits Arbeit ausführt.

Die Offline-Prüfung testet die Historie, wenn die Anwendung nicht mehr beteiligt ist

Ein Aktivitätsjournal schafft Verantwortlichkeit. Eine unabhängig prüfbare Hashkette bietet eine Möglichkeit festzustellen, ob die gespeicherte Sequenz weiterhin zusammenpasst. Beides hängt zusammen, ist aber nicht austauschbar.

Sallyport erstellt Session- und Aktivitätsansichten aus einem verschlüsselten, schreibgeschützten Audit-Log. Der Offline-Befehl sp audit verify prüft die Kette über dem Chiffretext und benötigt keinen Tresorzugriff. Das ist ein nützlicher Nachweis, weil der Prüfer die gespeicherte Historie testen kann, ohne das System, das den Bericht erzeugt hat, zur Entschlüsselung von Zugangsdaten oder zur Freigabe seines Tresors aufzufordern.

Übertreiben Sie nicht, was dadurch bewiesen wird. Die Prüfung einer Hashkette kann je nach Aufbau der Kette und den gespeicherten Unterlagen einen fehlenden, vertauschten oder veränderten Datensatz innerhalb des geprüften Umfangs erkennen. Sie beweist nicht, dass die Anwendung jedes Ereignis ausgegeben hat, das hätte existieren müssen. Sie beweist auch nicht, dass die Zeitquelle korrekt war, der Genehmiger eine gute Entscheidung getroffen hat oder die externe API tatsächlich das ausgeführt hat, was sie gemeldet hat. Das sind andere Kontrollfragen.

Bewahren Sie einen Prüfnachweis für einen klar definierten gespeicherten Bereich auf. Dieses Arbeitsblatt reicht für viele Teams aus:

{
  "verification_id": "audit-2026-07-15-01",
  "period_start": "2026-07-01T00:00:00Z",
  "period_end": "2026-07-14T23:59:59Z",
  "command": "sp audit verify",
  "verifier_version": "record the installed version",
  "source_archive": "encrypted audit export identifier",
  "result": "pass or fail",
  "performed_by": "reviewer identity",
  "exceptions": []
}

Erfinden Sie kein fehlerfreies Ergebnis nach einer fehlgeschlagenen Prüfung. Protokollieren Sie den Fehler, bewahren Sie die Unterlagen auf, ermitteln Sie, ob die Ursache beim Export, bei der Aufbewahrung, in einem Softwarefehler oder bei einer vermuteten Manipulation lag, und leiten Sie den Fall durch den Incident-Prozess. Eine fehlgeschlagene Integritätsprüfung ist nicht automatisch ein Sicherheitsvorfall. Sie ist ein Ereignis, das untersucht werden muss, weil Ihre Nachweiskette nicht mehr vertrauenswürdig ist.

Führen Sie die Prüfung nach einem Zeitplan durch, der zum Umfang und Risiko Ihrer Agent-Aktivitäten passt, und zusätzlich vor der Zusammenstellung der Nachweise. Für eine kleine Umgebung kann eine monatliche Prüfung ausreichen. Ein Team, das Agents den ganzen Tag Produktionssysteme bedienen lässt, sollte nicht bis zum Quartalsende warten, um ein Integritätsproblem zu entdecken. Der konkrete Zeitplan ist weniger wichtig als der Nachweis, dass die Prüfung regelmäßig stattfand und jemand auf Fehler reagierte.

Operative Aktionen und Systemänderungen brauchen getrennte Nachweise

Hier verschwimmen die Grenzen am häufigsten. Eine Agent-Aktion kann etwas verändern. Dadurch wird sie noch nicht zu einer kontrollierten Systemänderung nach CC8.1.

Drei Beispiele: Ein Agent ändert über eine API den Abonnementstatus eines Kunden. Das ist ein Geschäftsvorgang und braucht Autorisierung, Nachvollziehbarkeit und möglicherweise eine Prüfung. Ein Agent bearbeitet eine Infrastrukturdatei in einem Quellcode-Repository, der Pull Request wird geprüft, Tests bestehen und eine Bereitstellungspipeline übernimmt die Änderung. Das ist eine Systemänderung. Ein Agent führt einen SSH-Befehl aus, der eine Produktionskonfigurationsdatei direkt bearbeitet. Das ist eine operative Aktion mit erhöhtem Risiko und wahrscheinlich ein Verstoß gegen den Änderungsprozess, wenn Ihre Richtlinie geprüfte Bereitstellungen verlangt.

Das Nachweispaket sollte diese Wege sichtbar machen, statt den Prüfer sie aus dem Fließtext erschließen zu lassen. Ergänzen Sie den Aktivitätsdatensatz oder die Nachweisanalyse um eine Aktionsklassifizierung:

CC8.1 verlangt, dass das Management Änderungen an Infrastruktur, Daten, Software und Verfahren autorisiert, entwirft oder konfiguriert, dokumentiert, testet, genehmigt und implementiert. Ein Agent-Journal kann diese Geschichte ergänzen, indem es zeigt, dass ein Agent einen Pull Request geöffnet oder eine bereitstellungsbezogene Aktion ausgelöst hat. Es ersetzt jedoch weder Prüfung noch Testnachweis noch Bereitstellungsdatensatz.

Das ist unpopulär, weil ein einziges Audit-Log scheinbar jede Frage beantworten sollte. Das kann es nicht. Behalten Sie die Agent-Aktivitätsspur als Nachweis delegierter Aktionen. Bewahren Sie Ihre technischen Änderungsdatensätze als Beleg dafür auf, dass Systemänderungen den vorgeschriebenen Weg durchlaufen haben. Verknüpfen Sie beide nur dann, wenn der Agent an diesem Weg beteiligt war.

Erstellen Sie das Nachweispaket aus einer Population, nicht aus einem Screenshot-Ordner

Erstellen Sie für jeden Prüfungszeitraum ein einheitliches Paket. Definieren Sie zunächst die Population. Für Agent-Aktivitäten umfasst sie gewöhnlich alle Sessions, alle geschützten Aufrufe, alle abgelehnten Aufrufe, alle Widerrufe und alle Log-Prüfungen während des Zeitraums. Wenn Sie keine Zählungen oder keinen vollständigen Export vorlegen können, können Sie nicht glaubwürdig behaupten, dass der Auditor aus der vollständigen Population ausgewählt hat.

Erstellen Sie anschließend ein kleines Nachweisverzeichnis, das auf unveränderliche oder aufbewahrte Quelldatensätze verweist. Laden Sie nicht einfach einen Stapel Dateien mit Namen wie «final-final-audit» hoch. Verwenden Sie stabile IDs, Quelle, Zeitraum, Verantwortlichen und eine Notiz, die erklärt, was der Datensatz beweist.

Ein Prüfer kann so vorgehen:

1. Die Session- und Aktivitätspopulation des Zeitraums sowie die Integritätsprüfungen beschaffen.
2. Die Anzahl der in Aktivitätseinträgen referenzierten Session-IDs mit der Session-Population abgleichen und nicht zuordenbare Datensätze untersuchen.
3. Stichproben aus genehmigten Sessions, abgelehnten Versuchen, sensiblen Aufrufen, Widerrufen und verschiedenen Zeiträumen auswählen.
4. Jeden ausgewählten Aufruf zurück bis zu seiner Autorisierung und weiter bis zu seinem Ergebnis verfolgen. Anschließend den Log-Prüfdatensatz für den gespeicherten Bereich dieses Aufrufs prüfen.
5. Bei Änderungen am Gateway oder an zugehörigen Produktionskontrollen den relevanten Pull Request, Test, die Genehmigung und den Bereitstellungsdatensatz separat verfolgen.

Diese Reihenfolge macht Lücken schnell sichtbar. Hat ein Aufruf keine Session, ist die Autorisierungsverknüpfung fehlgeschlagen. Hat eine Session keine Prozessidentität, können Sie die Aussage über den Prozess nicht prüfen. Gibt es zu einem Widerruf keinen späteren Ablehnungstest, wissen Sie nur, dass jemand einen Button gedrückt hat. Decken die Prüfnachweise ein Archiv ab, das sich nicht reproduzieren lässt, ist die Integritätsaussage dünn.

Bewahren Sie die Notizen des Prüfers zusammen mit der Stichprobe auf. Eine kurze Notiz wie «Aufruf-ID 54b stimmt mit Session-ID 12a überein; Session von Mitarbeiter A genehmigt; Genehmigung pro Aufruf erforderlich und vorhanden; Aktivität abgeschlossen; Prüfung des Audit-Bereichs bestanden» ist hilfreicher als zehn Screenshots. Sie zeigt dem nächsten Prüfer, was getestet wurde, und hinterlässt eine Spur, wenn sich die Kontrolle ändert.

Nachweise scheitern, wenn Verantwortliche Ausnahmen nicht erklären können

Selbst die beste Nachweistabelle scheitert, wenn niemand für den Umgang mit Ausnahmen zuständig ist. Agent-Aktionen werden abgelehnt. Genehmigungsanfragen laufen ab. Aufrufe schlagen am entfernten Endpunkt fehl. Sessions werden widerrufen. Eine Prüfung kann ein Problem melden. Diese Ergebnisse sollten in der Population erscheinen, und das Team sollte wissen, welche davon eine Reaktion erfordern.

Definieren Sie eine überschaubare Zahl von Ausnahmekategorien: unbefugter Versuch, abgelehnte Genehmigung, Fehler der entfernten Aktion, Versuch nach Widerruf, fehlende Datensatzverknüpfung und Prüfungsfehler. Weisen Sie jeder Kategorie einen Verantwortlichen, einen Prüfturnus und den erwarteten Nachweis zu. Machen Sie nicht aus jeder abgelehnten API-Anfrage einen Sicherheitsvorfall. Wiederholte Ablehnungen durch einen unerwarteten signierten Prozess verdienen wahrscheinlich mehr Aufmerksamkeit als ein Entwickler, der seinen eigenen experimentellen Befehl ablehnt.

Die entscheidende Frage ist, ob jemand eine ausgewählte Ausnahme erklären kann, ohne aus Chatnachrichten eine Geschichte zusammensetzen zu müssen. Der Aktivitätsdatensatz sollte den unmittelbaren Grund nennen. Der Session-Datensatz sollte den Lauf identifizieren. Die Nachbearbeitung sollte zeigen, ob das Team das Ergebnis akzeptiert, die Konfiguration korrigiert, den Zugriff widerrufen oder einen Incident-Prozess eröffnet hat.

Auch Änderungen an den Kontrollen brauchen hier Disziplin. Wenn Sie das Genehmigungsverhalten, Merkmale von Zugangsdaten, Protokollfelder oder das Verfahren zur Prüfung gespeicherter Logs ändern, behandeln Sie das als Änderung der Kontrollumgebung. Aktualisieren Sie die Kontrollerläuterung, testen Sie das neue Verhalten und dokumentieren Sie die Bereitstellung über Ihren bestehenden Entwicklungsprozess. Andernfalls beschreibt Ihre Nachweistabelle das System des letzten Quartals, während die Agents dieses Quartals etwas anderes verwenden.

Warten Sie nicht, bis der Auditor Ihnen sagt, ob die Nachweise zusammenpassen. Wählen Sie diese Woche eine echte Session aus, verfolgen Sie sie von der Autorisierung bis zum Ergebnis des Aufrufs zurück, widerrufen Sie sie in einer sicheren Umgebung und prüfen Sie den gespeicherten Audit-Bereich offline. Wenn Ihr Team diese Übung nicht mit bereits verfügbaren Datensätzen abschließen kann, verbessern Sie den Nachweispfad, bevor Sie über die Formulierung der Kontrolle diskutieren.