Sicherheitsanforderungen des Cyber Verification Program

Sicherheitskontakt. Der Kunde muss Anthropic einen benannten Sicherheitskontakt zur Verfügung stellen, der Sicherheits- und Missbrauchswarnungen erhalten kann und in der Lage ist, darauf zu reagieren.

Vorfallmeldung. Der Kunde muss vermutete Sicherheitsverletzungen oder Missbrauch im Zusammenhang mit der Gewährung Anthropic innerhalb von 72 Stunden oder innerhalb von 24 Stunden bei einem Sicherheitsvorfall melden. Die Meldung kann unter [email protected] oder über Ihren Account-Team-Kontakt erfolgen.

Zusammenarbeit. Der Kunde muss jeden von Anthropic identifizierten Missbrauch innerhalb von 48 Stunden untersuchen, mit Anthropic zusammenarbeiten, um ihn zu beheben, und auf Missbrauchsanfragen innerhalb von sieben (7) Tagen antworten.

Persönlicher Zugriff. Jeder genehmigte Benutzer muss sich selbst anmelden. Gemeinsame Anmeldungen, Plätze, Sitzungen und Workload-Identitäten sowie Browser-Erweiterungen oder Proxy-Tools, die eine Sitzung für andere Personen freigeben, die nicht explizit ein genehmigter Benutzer sind, der alle nachstehenden Anforderungen erfüllt, sind nicht zulässig.

Nutzungszuordnung. Benutzerprofile müssen im gewährten Arbeitsbereich aktiviert bleiben, damit Anfragen einem benannten Benutzer oder einer Workload-Identität zugeordnet werden können.

Mitteilung von Änderungen. Der Kunde muss Anthropic innerhalb von dreißig (30) Tagen nach einer wesentlichen Änderung seiner Sicherheitslage, seines Eigentums, seines Hauptsitzes oder seines Sicherheitskontakts benachrichtigen.

Laufende Überprüfung. Anthropic kann anfordern, dass der Kunde Nachweise für die Einhaltung dieser Cyber Verification Program-Sicherheitsanforderungen erbringt.

Multi-Faktor-Authentifizierung. Zum Zeitpunkt des Zugriffs des Kunden auf das CVP müssen alle Konten, die sich beim gewährten Arbeitsbereich anmelden können oder Anmeldedaten dafür enthalten, Multi-Faktor-Authentifizierung aktiviert haben. Bis zum 15. Dezember 2026 (das "Stichtag") müssen alle solchen Konten phishing-resistente Multi-Faktor-Authentifizierung verwenden, wie im CISA-Merkblatt "Implementing Phishing-Resistant MFA" und in NIST SP 800-63B-4 definiert, d. h. (i) einen FIDO2/WebAuthn-Sicherheitsschlüssel, (ii) einen Passkey auf dem Gerät oder in einem Passwort-Manager oder (iii) eine Smartcard/PIV, und die E-Mail-Magic-Link-Anmeldung muss deaktiviert sein. SMS, Sprache, per E-Mail versendete Codes, Authenticator-App-Codes und Push-Genehmigungen sind nicht zulässig.

Anmeldedatenverwaltung. Bis zum Stichtag dürfen heruntergeladene, exportierte oder anderweitig langlebige statische Anmeldedaten, einschließlich API-Schlüssel, nicht für den Zugriff auf das Modell verwendet werden. Die folgenden Anforderungen gelten für den Kunden basierend auf der/den Bereitstellungsplattform(en), über die der Kunde auf das Modell zugreift. Für jede anwendbare Plattform müssen sich alle genehmigten Benutzer und alle Workloads mit kurzlebigen Anmeldedaten authentifizieren, die vom nativen Identitätsdienst dieser Plattform ausgegeben und verwaltet werden.

Zwischenzeitliche API-Schlüssel. Bis zum Stichtag sind API-Schlüssel unter einer Defense Access-Gewährung nur zulässig, wenn jeder Schlüssel (i) in einem Secrets Manager oder Passwort-Manager gespeichert ist, (ii) einer einzelnen Person oder Workload zugewiesen ist, (iii) aus dem Quellcode herausgehalten wird und (iv) mindestens alle 7 Tage ersetzt wird. Anthropic kann die Lebensdauer von API-Schlüsseln unter einer Defense Access-Gewährung auf 7 Tage begrenzen und kann API-Schlüssel im gewährten Arbeitsbereich ab dem Stichtag deaktivieren.

Genehmigte Benutzer. Es gibt keine Standardbegrenzung für die Anzahl der genehmigten Benutzer auf dieser Zugriffsstufe.

Einzelpersonen sind nur für Defense Access berechtigt. Wenn die Gewährung von einer Einzelperson gehalten wird, gilt dieser Abschnitt

Anmeldedatenverwaltung. Die folgenden Anforderungen gelten für den Kunden basierend auf der/den Bereitstellungsplattform(en), über die der Kunde auf das Modell zugreift. Für jede anwendbare Plattform müssen sich alle genehmigten Benutzer und alle Workloads mit kurzlebigen Anmeldedaten authentifizieren, die vom nativen Identitätsdienst dieser Plattform ausgegeben und verwaltet werden.

Multi-Faktor-Authentifizierung. Zum Zeitpunkt des Zugriffs des Kunden auf das CVP muss phishing-resistente Multi-Faktor-Authentifizierung (i) alle Konten schützen, die sich beim gewährten Arbeitsbereich anmelden können oder Anmeldedaten dafür enthalten, (ii) Konten genehmigter Benutzer beim Identitätsanbieter des Kunden, (iii) AWS-, Google Cloud- oder Azure-Identitäten, die das Modell aufrufen können, (iv) administrativen Zugriff auf alles, das Modellberechtigungen ausstellt oder speichert, und (v) jeden virtuellen Desktop oder Enclave, der zur Erfüllung dieser Anforderungen verwendet wird. Phishing-resistente Multi-Faktor-Authentifizierung bedeutet (i) einen FIDO2/WebAuthn-Sicherheitsschlüssel, (ii) einen Passkey auf dem Gerät oder in einem Passwort-Manager oder (iii) eine Smartcard/PIV, konsistent mit dem CISA-Merkblatt "Implementing Phishing-Resistant MFA" und NIST SP 800-63B-4. SMS, Sprache, per E-Mail versendete Codes, Authenticator-App-Codes und Push-Genehmigungen sind nicht zulässig, und die E-Mail-Magic-Link-Anmeldung muss deaktiviert sein.

Organisationskonten. Genehmigte Benutzer müssen sich mit Konten in der Domäne des Kunden anmelden. Persönliche und Webmail-Konten sind nicht zulässig.

Genehmigte Benutzer. Der gewährte Arbeitsbereich ist auf fünfundsiebzig (75) genehmigte Benutzer beschränkt, die die Arbeit, für die die Gewährung genehmigt wurde, persönlich ausführen oder direkt beaufsichtigen. Workload-Identitäten zählen nicht zu dieser Anzahl. Der Kunde kann schriftlich (E-Mail genügt) zusätzliche Plätze für genehmigte Benutzer anfordern. Nur benannte Administratoren dürfen Mitglieder hinzufügen, Rollen ändern oder Workload-Identitäten oder Anmeldedaten im gewährten Arbeitsbereich erstellen.

Gateways. Wenn der Kunde ein Gateway oder einen Proxy vor dem Modell betreibt, muss es nur genehmigte Benutzer oder deren Workload-Identitäten zulassen, ein kurzlebiges Anmeldedatum verwenden und seine Protokolle und Transkripte auf genehmigte Benutzer und die Sicherheits-, IT-Verwaltungs- oder Trust-and-Safety-Teams des Kunden beschränken.

Vom Kunden betriebene Anmeldedatensysteme. Von den eigenen Systemen des Kunden ausgegebene Anmeldedaten müssen innerhalb von 12 Stunden ablaufen, dürfen nur nach phishing-resistenter Multi-Faktor-Authentifizierung (für Personen) oder einer verifizierten Workload-Identität (für Dienste) ausgegeben werden und dürfen keine statischen Anmeldedaten auf Endpunkten, im Quellcode oder in gemeinsamen Speichern hinterlassen. Die Schlüssel und Geheimnisse, die Modellberechtigungen ausstellen können, müssen in einem Secrets Manager oder Key Management Service mit Zugriffsprotokolierung aufbewahrt werden.

Widerruf. Der Kunde muss in der Lage sein, alle kompromittierten Anmeldedaten oder Identitäten innerhalb von 24 Stunden zu widerrufen.

Offboarding. Der Kunde muss ausgeschiedene oder neu zugewiesene genehmigte Benutzer und deren Workload-Identitäten innerhalb von drei (3) Geschäftstagen aus dem gewährten Arbeitsbereich entfernen.

Netzwerk-Egress. Überall dort, wo das Modell offensive oder agentengesteuerte Arbeiten ausführt, muss der ausgehende Datenverkehr auf eine Zulassungsliste beschränkt sein, die außerhalb des Hosts erzwungen wird, und muss protokolliert werden. Arbeitsstationen, die nur für interaktive Eingabeaufforderungen verwendet werden, können eine On-Host-Zulassungsliste verwenden, wenn die agentengesteuerte Arbeit selbst in einer Sandbox ausgeführt wird, die diese Liste nicht ändern kann.

Verwaltete Geräte. Genehmigte Benutzer dürfen den gewährten Arbeitsbereich nur von Geräten aus erreichen, die der Kunde kontrolliert und die automatische oder regelmäßig geplante Betriebssystem-Updates erhalten, nicht von persönlichen Geräten.

Hintergrundüberprüfungen. Jeder genehmigte Benutzer, einschließlich Auftragnehmer, muss eine Identitätsprüfung und, soweit rechtlich zulässig, eine Überprüfung der Strafverfolgungsgeschichte bestanden haben. Wenn das lokale Recht Strafverfolgungsprüfungen einschränkt, werden Identitäts-, Arbeitserlaubnis- oder Beschäftigungsüberprüfungen akzeptiert. Staatliche Überprüfung oder eine Sicherheitsfreigabe erfüllt diese Anforderung.

Vorfallverfahren. Der Kunde muss ein dokumentiertes Verfahren für vermutete Kompromittierung oder Missbrauch der Gewährung führen, das Anmeldedatenwiderruf und Sitzsuspendierung abdeckt.

Regierungsbehörden. Eine FISMA Authority to Operate mit einer jährlichen unabhängigen Inspector General-Bewertung gegen NIST SP 800-53 oder ein gleichwertiges nationales Schema erfüllt die Anforderungen für verwaltete Geräte, Hintergrundüberprüfungen und Vorfallverfahren. Alle anderen Anforderungen gelten weiterhin.

Multi-Faktor-Authentifizierung. Zum Zeitpunkt des Zugriffs des Kunden auf das CVP muss phishing-resistente Multi-Faktor-Authentifizierung (i) alle Konten schützen, die sich beim gewährten Arbeitsbereich anmelden können oder Anmeldedaten dafür enthalten, (ii) Konten genehmigter Benutzer beim Identitätsanbieter des Kunden, (iii) AWS-, Google Cloud- oder Azure-Identitäten, die das Modell aufrufen können, (iv) administrativen Zugriff auf alles, das Modellberechtigungen ausstellt oder speichert, und (v) jeden virtuellen Desktop oder Enclave, der zur Erfüllung dieser Anforderungen verwendet wird. Phishing-resistente Multi-Faktor-Authentifizierung bedeutet (i) einen FIDO2/WebAuthn-Sicherheitsschlüssel, (ii) einen Passkey auf dem Gerät oder in einem Passwort-Manager oder (iii) eine Smartcard/PIV, konsistent mit dem CISA-Merkblatt "Implementing Phishing-Resistant MFA" und NIST SP 800-63B-4. SMS, Sprache, per E-Mail versendete Codes, Authenticator-App-Codes und Push-Genehmigungen sind nicht zulässig, und die E-Mail-Magic-Link-Anmeldung muss deaktiviert sein.

Anmeldedatenverwaltung. Die folgenden Anforderungen gelten für den Kunden basierend auf der/den Bereitstellungsplattform(en), über die der Kunde auf das Modell zugreift. Für jede anwendbare Plattform müssen sich alle genehmigten Benutzer und alle Workloads mit kurzlebigen Anmeldedaten authentifizieren, die vom nativen Identitätsdienst dieser Plattform ausgegeben und verwaltet werden.

Single Sign-On und Organisationskonten. Genehmigte Benutzer müssen sich mit Konten in der eigenen Domäne des Kunden anmelden. Genehmigte Benutzer müssen sich mit Organisationsdomänen-Identitäten anmelden, die über das Single Sign-On des Kunden verbunden sind. Persönliche, Webmail- und nicht verbundene Konten sind nicht zulässig.

Genehmigte Benutzer. Der gewährte Arbeitsbereich ist auf 25 genehmigte Benutzer beschränkt, die die Arbeit, für die die Gewährung genehmigt wurde, persönlich ausführen oder direkt beaufsichtigen. Workload-Identitäten zählen nicht zu dieser Anzahl. Der Kunde kann schriftlich (E-Mail genügt) zusätzliche Plätze für genehmigte Benutzer anfordern. Nur benannte Administratoren dürfen Mitglieder hinzufügen, Rollen ändern oder Workload-Identitäten oder Anmeldedaten im gewährten Arbeitsbereich erstellen.

Gateways. Wenn der Kunde ein Gateway oder einen Proxy vor dem Modell betreibt, muss es nur genehmigte Benutzer oder deren Workload-Identitäten zulassen, ein kurzlebiges Anmeldedatum verwenden und seine Protokolle und Transkripte auf genehmigte Benutzer und die Sicherheits-, IT-Verwaltungs- oder Trust-and-Safety-Teams des Kunden beschränken.

Vom Kunden betriebene Anmeldedatensysteme. Von den eigenen Systemen des Kunden ausgegebene Anmeldedaten müssen innerhalb von 12 Stunden ablaufen, dürfen nur nach phishing-resistenter Multi-Faktor-Authentifizierung (für Personen) oder einer verifizierten Workload-Identität (für Dienste) ausgegeben werden und dürfen keine statischen Anmeldedaten auf Endpunkten, im Quellcode oder in gemeinsamen Speichern hinterlassen. Die Schlüssel und Geheimnisse, die Modellberechtigungen ausstellen können, müssen in einem Secrets Manager oder Key Management Service mit Zugriffsprotokolierung aufbewahrt werden.

Widerruf. Der Kunde muss in der Lage sein, alle kompromittierten Anmeldedaten oder Identitäten innerhalb von 24 Stunden zu widerrufen.

Offboarding. Der Kunde muss ausgeschiedene oder neu zugewiesene genehmigte Benutzer und deren Workload-Identitäten innerhalb von 3 Geschäftstagen aus dem gewährten Arbeitsbereich entfernen.

Netzwerk-Egress. Überall dort, wo das Modell offensive oder agentengesteuerte Arbeiten ausführt, muss der ausgehende Datenverkehr auf eine Zulassungsliste beschränkt sein, die außerhalb des Hosts erzwungen wird, und muss protokolliert werden. Arbeitsstationen, die nur für interaktive Eingabeaufforderungen verwendet werden, können eine On-Host-Zulassungsliste verwenden, wenn die agentengesteuerte Arbeit selbst in einer Sandbox ausgeführt wird, die diese Liste nicht ändern kann.

Verwaltete Geräte und Malware-Schutz. Genehmigte Benutzer dürfen den gewährten Arbeitsbereich nur von Geräten aus erreichen, die der Kunde kontrolliert, nicht von persönlichen Geräten, und die automatische oder regelmäßig geplante Betriebssystem-Updates erhalten. Jedes Gerät, das ein genehmigter Benutzer für den Zugriff auf den gewährten Arbeitsbereich verwendet, muss vom Kunden verwaltet werden und muss Anwendungszulassungs- oder Ablehnungslisten im Erzwingungsmodus oder einen Endpoint Detection and Response-Agent im Block- oder Prevent-Modus ausführen. Ein verwalteter virtueller Desktop oder Enclave, der diesen Standard erfüllt, ist ebenfalls zulässig.

Hintergrundüberprüfungen. Jeder genehmigte Benutzer, einschließlich Auftragnehmer, muss eine Identitätsprüfung und, soweit rechtlich zulässig, eine Überprüfung der Strafverfolgungsgeschichte bestanden haben. Wenn das lokale Recht Strafverfolgungsprüfungen einschränkt, werden Identitäts-, Arbeitserlaubnis- oder Beschäftigungsüberprüfungen akzeptiert. Staatliche Überprüfung oder eine Sicherheitsfreigabe erfüllt diese Anforderung.

Vorfallverfahren. Der Kunde muss ein dokumentiertes Verfahren für vermutete Kompromittierung oder Missbrauch der Gewährung führen, das Anmeldedatenwiderruf, Sitzsuspendierung und Benachrichtigung von Anthropic abdeckt.

Regierungsbehörden. Eine FISMA Authority to Operate mit einer jährlichen unabhängigen Inspector General-Bewertung gegen NIST SP 800-53 oder ein gleichwertiges nationales Schema erfüllt die Anforderungen für verwaltete Geräte und Malware-Schutz, Hintergrundüberprüfungen und Vorfallverfahren. Alle anderen Anforderungen gelten weiterhin.