Technische Nachweise

Technische Nachweise direkt aus den Quellsystemen

Ein Audit fragt nicht nur, ob eine Richtlinie existiert, sondern ob die technische Kontrolle tatsächlich wirkt. Diese Seite erklärt, was ein technischer Nachweis ist, wie Akvera ihn erzeugt und wo die Grenzen der Automatisierung liegen.

Was ein technischer Nachweis ist

Ein technischer Nachweis ist eine Beobachtung aus dem System, in dem eine Kontrolle tatsächlich umgesetzt ist: ob für privilegierte Konten Multi-Faktor-Authentifizierung erzwungen wird, ob Backup-Jobs erfolgreich laufen oder ob Logquellen aktiv Ereignisse liefern.

Aussagekräftig wird diese Beobachtung durch ihre Herkunft. Quellsystem, Zeitpunkt der Erfassung und die Prüfung, mit der sie bewertet wurde, müssen sich nachvollziehen lassen.

Warum Screenshots und Exporte oft nicht genügen

Diese Verfahren haben gute Gründe, und Auditoren arbeiten mit dem, was ihnen vorgelegt wird. Als Beleg für technische Kontrollen haben sie aber Schwächen:

  • Sie zeigen nur einen Zeitpunkt und veralten kurz nach der Erfassung.
  • Sie lassen sich für Dritte schwer reproduzieren.
  • Sie belegen oft nur, dass jemand einen Screenshot gemacht hat, nicht, dass die Kontrolle dauerhaft wirkt.
  • Sie müssen in jedem Audit-Zyklus erneut von Hand erstellt werden.

Wie Akvera Nachweise erzeugt

Akvera verbindet sich lesend mit Ihren bestehenden Systemen, wertet definierte technische Kontrollen aus und bewahrt den Nachweis auf. Jedes Ergebnis lässt sich so Schritt für Schritt zurückverfolgen:

  1. Anforderung eines Regelwerks, zum Beispiel ein Eintrag aus Anhang A von ISO/IEC 27001:2022.
  2. Technische Kontrolle, die dieser Anforderung zugeordnet ist.
  3. Automatisierte Prüfung als versionierte Definition. Frühere Ergebnisse behalten die Definition, mit der sie entstanden sind.
  4. Beobachtung des Quellsystems, reduziert auf die Felder, die die Prüfung braucht.
  5. Nachweis mit Ergebnis, Begründung, Erfassungszeitpunkt und Ablauf, als ausschließlich fortgeschriebener Datensatz.
  6. SHA-256-Hash des Nachweises und des ursprünglichen Quellartefakts.

Ein Beispiel

Illustratives Beispiel: Die Kontrolle „Der Hauptbranch ist geschützt“ wird gegen GitLab geprüft. Erwartet wird ein geschützter Hauptbranch, beobachtet wird der aktivierte Branch-Schutz, das Ergebnis lautet PASS. Gespeichert werden Zeitstempel, Quelle, Prüfversion und Hash.

Wäre der Schutz nicht aktiv, lautete das Ergebnis FAIL. Könnte Akvera ihn wegen einer fehlenden Berechtigung nicht lesen, lautete es UNKNOWN.

Drei Ergebnisse: PASS, FAIL und UNKNOWN

Fehlender Nachweis wird nicht zu PASS, und teilweise Abdeckung wird nicht zu vollständiger Abdeckung.

  • PASS: Ausreichende, aktuelle Nachweise stützen die Kontrolle.
  • FAIL: Eine aktuelle, gültige Beobachtung verletzt die Kontrolle.
  • UNKNOWN: Akvera liegen nicht genügend Nachweise für eine belastbare Aussage vor, etwa wegen einer fehlenden Berechtigung, einer nicht unterstützten Edition oder eines fehlenden erwarteten Bestands. Akvera nennt die Ursache und den nächsten Schritt.

Was sich automatisieren lässt

  • Technische Kontrollen in angebundenen Systemen, deren Zustand sich über eine Schnittstelle lesen lässt: Identität, Cloud, Quellcodeverwaltung, Logging und Monitoring, Backup und Secrets-Management.
  • Wiederholte Prüfungen statt einmaliger Stichtagsaufnahmen.
  • Die Rückverfolgung jedes Ergebnisses bis zur Quelle.

Was Akvera nicht ersetzt

  • Richtlinien, Prozesse und organisatorische Maßnahmen. Akvera belegt technische Kontrollen, nicht, wie Menschen handeln.
  • Systeme, die nicht angebunden sind, und Daten, die ein System nicht herausgibt.
  • Die Bewertung durch Ihren Auditor und eine rechtliche Auslegung. Akvera stellt keine Zertifikate aus und macht eine Organisation weder ISO-27001- noch NIS2-konform.

Nachweispakete für Auditoren

Ein Nachweispaket ist ein exportierbares Archiv mit Zusammenfassungen, Nachweisdatensätzen, Rohdaten der Quelle und einem Manifest. Ein separates Skript prüft es offline, ohne das Produkt.

Die Hashes machen geänderte oder unvollständige Nachweise erkennbar. Es sind keine digitalen Signaturen. Deshalb sprechen wir von überprüfbarer Integrität und nicht von Manipulationssicherheit.

Welche Systeme angebunden werden

Für Pilote stehen neun Integrationen bereit: Microsoft Entra ID, Microsoft Azure, GitLab, GitHub, Veeam Backup & Replication, Proxmox Backup Server, Graylog, Wazuh und HashiCorp Vault. Tiefe und Umfang der Prüfungen unterscheiden sich je Integration. Die Einzelheiten stehen auf der Seite zu den unterstützten Prüfungen.

Erfahren Sie, was Akvera in Ihrer Umgebung belegen kann.

Sagen Sie uns, welche Systeme Sie einsetzen und was Sie heute noch von Hand nachweisen müssen.