Sicherheitsaudit und Zertifizierung

Vom ad-hoc-Security-Check zur zertifizierten Compliance

Die vorherigen Lektionen haben Ihnen die technischen Werkzeuge zur Absicherung eines KI-Systems vermittelt. Doch einmalige Sicherheitsprüfungen reichen nicht aus – und der Grund liegt nicht nur in Bürokratie. Was Sie einmal verifizieren, bleibt nicht verifiziert, sobald Sie die nächste Version veröffentlichen, und nichts weist auf diese Lücke hin. Kunden, Regulierungsbehörden und Partner fordern formale Nachweise: Beweise dafür, dass Ihre Kontrollmechanismen existieren, funktionieren und über die Zeit bestehen. Audit und Zertifizierung verwandeln Ihre Praktiken in ein überprüfbares, kontinuierliches Rahmenwerk.

Erkennen Sie das anwendbare Rahmenwerk

Fünf Rahmenwerke überschneiden sich im Bereich KI, jedes mit einem anderen Geltungsbereich. Unterscheiden Sie diese, bevor Sie sich für etwas entscheiden.

Der entscheidende Unterschied trennt das Verpflichtende vom Optionalen. Das EU-KI-Gesetz ist eine Verordnung: Wenn Ihr System in die Kategorie Hochrisiko fällt, können Sie nicht optieren. ISO-Standards und SOC 2 sind freiwillige Zertifizierungen, die in der Regel von Unternehmenskunden statt von Regulierungsbehörden gefordert werden. Die OWASP LLM Top 10 ist nicht zertifizierbar – es ist eine technische Referenz und der beste Ausgangspunkt für einen ersten internen Audit, da sie nur Zeit kostet.

Eine Checkliste, die fünf Domänen abdeckt

Ein ernsthafter Audit geht über Technik hinaus. Die nachfolgende Checkliste verteilt ihre Kontrollpunkte auf fünf Domänen, und diese Verteilung erzählt eine Geschichte: Governance und Compliance wiegen genauso schwer wie Sicherheit, denn ein technisch einwandfreies Setup, das niemand besitzt und nirgends dokumentiert ist, wird jeden externen Audit scheitern lassen.

Kritikalität trennt Verpflichtendes von Empfohlenem, eine Unterscheidung, die später eine binäre Entscheidung antreibt. Sandboxing erscheint als empfohlen statt als verpflichtend, und diese Rangfolge ist gerechtfertigt: Sie gilt nur für Systeme, die generierten Code ausführen, während Eingabe- und Ausgabe-Filterung jede Anwendung ohne Ausnahme betrifft. Eine gut kalibrierte Checkliste fragt einen FAQ-Chatbot nicht nach der Rechtfertigung für Container-Isolation.

from dataclasses import dataclass, field
from datetime import datetime

@dataclass
class ControlPoint:
    id: str
    category: str
    description: str
    criticality: str  # mandatory, recommended, optional
    compliant: bool | None = None
    evidence: str = ""
    comment: str = ""

def create_audit_checklist() -> list[ControlPoint]:
    """Creates a comprehensive AI security audit checklist."""
    return [
        # Governance
        ControlPoint("GOV-01", "Governance",
            "Dokumentierte und genehmigte KI-Sicherheitsrichtlinie", "mandatory"),
        ControlPoint("GOV-02", "Governance",
            "Benannter KI-Sicherheitsverantwortlicher (CISO/DPO)", "mandatory"),
        ControlPoint("GOV-03", "Governance",
            "Aktualisierter Register der KI-Verarbeitungsaktivitäten", "mandatory"),

        # Data
        ControlPoint("DAT-01", "Data",
            "Inventar der an LLM-APIs gesendeten Daten", "mandatory"),
        ControlPoint("DAT-02", "Data",
            "Anonymisierung/Pseudonymisierung personenbezogener Daten", "mandatory"),
        ControlPoint("DAT-03", "Data",
            "Mit jeder KI-API-Anbieter unterzeichnete DPA", "mandatory"),
        ControlPoint("DAT-04", "Data",
            "Definierte Aufbewahrungsrichtlinie für Gespräche", "mandatory"),

        # Technical security
        ControlPoint("SEC-01", "Security",
            "Prompt-Injection: Defense-in-Depth implementiert", "mandatory"),
        ControlPoint("SEC-02", "Security",
            "Inhaltsfilterung (Eingaben und Ausgaben)", "mandatory"),
        ControlPoint("SEC-03", "Security",
            "Rate Limiting und Missbrauchserkennung", "mandatory"),
        ControlPoint("SEC-04", "Security",
            "API-Schlüssel in einem Vault gespeichert (nicht hartkodiert)", "mandatory"),
        ControlPoint("SEC-05", "Security",
            "Sandboxing für die Ausführung generierten Codes", "recommended"),
        ControlPoint("SEC-06", "Security",
            "Überwachung und Alarmierung bei Anomalien", "recommended"),

        # Red teaming
        ControlPoint("RED-01", "Red teaming",
            "Sicherheitstests vor jeder Produktionsfreigabe", "mandatory"),
        ControlPoint("RED-02", "Red teaming",
            "Regelmäßiges Red Teaming (mindestens vierteljährlich)", "recommended"),
        ControlPoint("RED-03", "Red teaming",
            "Red-Team-Bericht mit Nachverfolgung von Behebungen", "mandatory"),

        # Compliance
        ControlPoint("CONF-01", "Compliance",
            "DPIA für KI-Verarbeitungsaktivitäten abgeschlossen", "mandatory"),
        ControlPoint("CONF-02", "Compliance",
            "Rechte der betroffenen Personen implementiert (Zugriff, Löschung)", "mandatory"),
        ControlPoint("CONF-03", "Compliance",
            "Transparente Benachrichtigung der Nutzer über KI-Nutzung", "mandatory"),
        ControlPoint("CONF-04", "Compliance",
            "Risikoklassifizierung gemäß EU-KI-Gesetz", "recommended"),
    ]

Audit bedeutet, Beweise einzufordern

Das Feld, das die Audit-Ausführung alles ändert, ist evidence. Das Ankreuzen von „compliant” ohne Dokumentenreferenz bedeutet für einen externen Prüfer nichts, der systematisch fragen wird, was die Behauptung stützt. Das Nutzungsexemplar zeigt dies deutlich: Die Compliance von GOV-01 beruht auf einem benannten, datierten Dokument, nicht auf einer Absichtserklärung.

Der dritte Aufruf illustriert den lehrreichsten Fall – eine Nicht-Compliance gepaart mit einem Behebungsplan. Ein API-Schlüssel in einer Umgebungsdatei ist kein Skandal; es ist eine gängige Praxis. Er erfüllt dennoch nicht den Kontrollpunkt, und der Kommentar legt den Weg zur Compliance dar. Ein Audit, das keine Nicht-Compliances aufdeckt, sollte Misstrauen erregen: Es signalisiert in der Regel eine nachsichtige Checkliste, kein perfektes System.

Die endgültige Entscheidung ist binär und ungewichtet: Eine einzige verpflichtende Nicht-Compliance kippt das Urteil. Die Compliance-Rate, die daneben berechnet wird, misst den Fortschritt zwischen Audits – sie verhandelt das Urteil selbst nie.

class AISecurityAudit:
    """Executes and documents an AI security audit."""

    def __init__(self, system_name: str, auditor: str):
        self.system_name = system_name
        self.auditor = auditor
        self.date = datetime.now().strftime("%Y-%m-%d")
        self.checklist = create_audit_checklist()

    def evaluate(self, point_id: str, compliant: bool, evidence: str, comment: str = ""):
        """Evaluates a control point."""
        for point in self.checklist:
            if point.id == point_id:
                point.compliant = compliant
                point.evidence = evidence
                point.comment = comment
                return
        raise ValueError(f"Unknown control point: {point_id}")

    def report(self) -> dict:
        """Generates the audit report."""
        evaluated = [p for p in self.checklist if p.compliant is not None]
        compliant = [p for p in evaluated if p.compliant]
        non_compliant = [p for p in evaluated if not p.compliant]
        not_evaluated = [p for p in self.checklist if p.compliant is None]

        # Mandatory non-compliances are blockers
        blockers = [
            p for p in non_compliant if p.criticality == "mandatory"
        ]

        return {
            "system": self.system_name,
            "auditor": self.auditor,
            "date": self.date,
            "total_controls": len(self.checklist),
            "evaluated": len(evaluated),
            "compliant": len(compliant),
            "non_compliant": len(non_compliant),
            "not_evaluated": len(not_evaluated),
            "blockers": len(blockers),
            "compliance_rate": f"{len(compliant) / max(len(evaluated), 1) * 100:.0f}%",
            "decision": "NON-COMPLIANT" if blockers else "COMPLIANT",
            "blocking_non_compliances": [
                {"id": p.id, "description": p.description, "comment": p.comment}
                for p in blockers
            ],
        }

# Usage example
audit = AISecurityAudit("Customer Support Chatbot v2.3", "security_analyst")
audit.evaluate("GOV-01", True, "Document POL-SEC-AI-2026 approved on 2026-01-15")
audit.evaluate("SEC-01", True, "Multi-layer guardrails implemented (see architecture)")
audit.evaluate("SEC-04", False, "OpenAI API key in .env environment variable",
              "Migrate to a vault (HashiCorp Vault or AWS Secrets Manager)")

result = audit.report()
print(f"Decision: {result['decision']}")
print(f"Compliance rate: {result['compliance_rate']}")

Ein letzter Gegenwert – die Anzahl der unevaluierten Punkte – spielt eine stille, aber entscheidende Rolle. Er verhindert, dass Sie „compliant” mit „nicht geprüft” verwechseln, eine Verwechslung, die auftritt, wenn ein Audit über Wochen dauert und niemand mehr erinnert, wo es aufgehört hat.

Automatisieren Sie, was möglich ist

Ein jährlicher Audit erfasst einen Schnappschuss. Zwischen den Schnappschüssen kann ein API-Schlüssel hartkodiert werden, ein Rate Limit deaktiviert werden, um einen gehetzten Kunden freizuschalten, oder die Moderation für einen schnellen Test umgangen werden. Automatisierte Prüfungen füllen diese Lücke, indem sie in jedem Continuous-Integration-Zyklus ausgeführt werden.

Nicht alles eignet sich zur Automatisierung, und Sie sollten das offen sagen. Das Suchen nach hartkodierten Schlüsseln ist mechanisierbar, da es Code inspiziert. Die anderen beiden Prüfungen im Beispiel geben hartkodierte Werte zurück, was nur als Ausgangspunkt Sinn ergibt: In der Produktion müssen sie den Dienst tatsächlich üben – die API 21-mal aufrufen, um ein 429 zu bestätigen, oder Testinhalte zur Moderation einreichen, um zu bestätigen, dass diese antwortet. Eine Prüfung, die immer wahr zurückgibt, ist schlimmer als keine Prüfung, da sie Vertrauen herstellt, ohne etwas zu messen.

class ContinuousAudit:
    """Automatically verifies security controls on an ongoing basis."""

    def __init__(self):
        self.checks = {}

    def add_check(self, name: str, check_function):
        """Adds an automated check."""
        self.checks[name] = check_function

    def run(self) -> dict:
        """Runs all checks."""
        results = {}
        for name, check in self.checks.items():
            try:
                ok, detail = check()
                results[name] = {"status": "PASS" if ok else "FAIL", "detail": detail}
            except Exception as e:
                results[name] = {"status": "ERROR", "detail": str(e)}
        return results

# Automated checks
continuous_audit = ContinuousAudit()

def check_api_keys():
    """Verifies that no API keys are hardcoded in the codebase."""
    import subprocess
    result = subprocess.run(
        ["grep", "-r", "sk-", "src/", "--include=*.py", "-l"],
        capture_output=True, text=True,
    )
    files = result.stdout.strip().split("\n") if result.stdout.strip() else []
    return len(files) == 0, f"{len(files)} file(s) with hardcoded key"

def check_rate_limiting():
    """Verifies that rate limiting is active."""
    return True, "Rate limiting active (429 after 20 req/min)"

def check_moderation():
    """Verifies that moderation is active on the pipeline."""
    return True, "Moderation API called on inputs and outputs"

continuous_audit.add_check("api_keys_secured", check_api_keys)
continuous_audit.add_check("rate_limiting_active", check_rate_limiting)
continuous_audit.add_check("moderation_active", check_moderation)

Was ein Zertifizierer erwartet

Das Anstreben einer Zertifizierung wie ISO 42001 oder SOC 2 verschiebt den Aufwand, und Sie sollten das wissen, bevor Sie sich entscheiden. Dokumentation kommt zuerst: aktuelle Richtlinien, Verfahren und Register – die Arbeit, die Engineering-Teams am ehesten verschieben. Beweise folgen – Logs, Testberichte, Screenshots – und sind viel einfacher zu sammeln, wenn Sie sie archivieren, während Sie arbeiten, statt drei Wochen vor dem Audit. Geschichte ist die schwierigste Anforderung, die nachzuholen ist: Ein SOC 2 Typ II untersucht, wie Kontrollmechanismen über mehrere Monate funktioniert haben, etwas, das kein letzter-minute-Schub nachbauen kann. Ausbildung kommt als Nächstes, und Sie müssen beweisen, dass sie stattgefunden hat, was bedeutet, datierte Anwesenheitslisten und Materialien. Schließlich erfordert kontinuierliche Verbesserung, dass Befunde behoben und erneut getestet werden – genau der Validierungszyklus aus dem vorherigen Kapitel, dessen Wert Sie nun sehen: Er erzeugt die Beweise, die der Zertifizierer verlangen wird.

Der Zyklus Audit, beheben, erneut testen, zertifizieren hat kein Ende. Jede neue Funktion öffnet Kontrollpunkte erneut, und das ist die eigentliche Bedeutung von „kontinuierlich” in „kontinuierliche Verbesserung”.

Kernaussagen

• Audit verwandelt Sicherheits-Best Practices in überprüfbare Beweise
• Die Checkliste deckt Governance, Daten, technische Sicherheit, Red Teaming und Compliance ab
• Verpflichtende Nicht-Compliances sind Blocker – sie müssen vor der Bereitstellung behoben werden
• Kontinuierliches Audit automatisiert repetitive Prüfungen (API-Schlüssel, Rate Limiting, Moderation)
• Zertifizierung (ISO 42001, SOC 2) erfordert Dokumentation, Beweise und Geschichte: Der Zyklus Audit, beheben, erneut testen ist kontinuierlich, nicht einmalig

Testen Sie Ihr Wissen

Offensive und defensive Sicherheit: die letzte Kontrolle vor dem Audit.

1. Was ist ein Prompt-Injection-Angriff?

Antwort: Böswillige Anweisungen, die in die Daten geschleust werden, die das Modell verarbeitet (Webseite, Dokument, Nachricht), um sein Verhalten zu übernehmen – Abwehr: Anweisungen von Daten isolieren, Ausgaben validieren, exponierte Fähigkeiten begrenzen.

2. Jailbreaking vs. Prompt-Injection: Was ist der Unterschied?

Antwort: Jailbreaking versucht, das Modell dazu zu bringen, seine Regeln durch direkte Konversation zu umgehen; Injection funktioniert über Drittanbieter-Inhalte, die es verarbeitet. Beide werden unterschiedlich getestet – und bekämpft.

3. Warum mehrschichtige Filterung?

Antwort: Weil keine einzelne Schicht perfekt ist: Eingabe-Moderation, Anwendungsguardrails, Ausgabe-Kontrollen und Rate Limiting ergänzen sich – Defense in Depth angewendet auf KI.

4. Was beinhaltet eine KI-Red-Teaming-Kampagne?

Antwort: Methodisches Angreifen Ihres eigenen Systems (Injection-Szenarien, Jailbreaks, Exfiltration) mit einer Risikotaxonomie, Dokumentation von Bruchstellen, Priorisierung von Behebungen – dann erneut testen.

5. Was deckt der GDPR-Winkel in einer OpenAI-Bereitstellung ab?

Antwort: Die Rechtsgrundlage für die Verarbeitung, Datenminimierung für gesendete Daten, Rechte der betroffenen Personen und vertragliche Schutzmaßnahmen – Compliance wird mit der Architektur entworfen, nicht danach.

Ein sicheres KI-System ist bewiesen: Taxonomie, offensive Tests, mehrschichtige Abwehr, Audit – der Zyklus, den dieser Kurs Sie üben ließ.