Requisiti di sicurezza del programma di verifica informatica

Contatto di sicurezza. Il cliente deve fornire ad Anthropic un contatto di sicurezza designato che possa ricevere avvisi di sicurezza e abuso e sia in grado di agire su di essi.

Segnalazione di incidenti. Il cliente deve segnalare ad Anthropic i sospetti di violazione o abuso che coinvolgono la concessione entro 72 ore, o entro 24 ore per un incidente di sicurezza. La segnalazione può essere effettuata presso [email protected] o il contatto del team dell'account.

Cooperazione. Il cliente deve indagare su qualsiasi abuso identificato da Anthropic entro 48 ore, collaborare con Anthropic per rimediare e rispondere alle richieste di abuso entro sette (7) giorni.

Accesso personale. Ogni utente approvato deve accedere come se stesso. Gli accessi condivisi, i posti, le sessioni e le identità di carico di lavoro, nonché le estensioni del browser o gli strumenti proxy che espongono una sessione ad altre persone che non sono esplicitamente un utente approvato che soddisfa tutti i requisiti di seguito, non sono consentiti.

Attribuzione dell'utilizzo. I profili utente devono rimanere abilitati nello spazio di lavoro concesso in modo che le richieste possano essere attribuite a un utente denominato o a un'identità di carico di lavoro.

Notifica di modifiche. Il cliente deve notificare Anthropic entro trenta (30) giorni da un cambiamento materiale della sua postura di sicurezza, proprietà, sede centrale o contatto di sicurezza.

Revisione continua. Anthropic può richiedere che il cliente fornisca prove di conformità a questi requisiti di sicurezza del programma di verifica informatica.

Autenticazione a più fattori. Al momento dell'accesso del cliente al CVP, tutti gli account che possono accedere allo spazio di lavoro concesso o detengono credenziali per esso devono avere l'autenticazione a più fattori abilitata. Entro il 15 dicembre 2026 (la "Data limite"), tutti questi account devono utilizzare l'autenticazione a più fattori resistente al phishing come definito nel foglio informativo CISA "Implementing Phishing-Resistant MFA" e con NIST SP 800-63B-4, il che significa (i) una chiave di sicurezza FIDO2/WebAuthn, (ii) una passkey, sul dispositivo o in un gestore di password, o (iii) una smartcard/PIV, e l'accesso tramite collegamento magico via email deve essere disabilitato. SMS, voce, codici inviati via email, codici dell'app di autenticazione e approvazioni push non si qualificano.

Gestione delle credenziali. Entro la data limite, le credenziali statiche scaricate, esportate o altrimenti di lunga durata, incluse le chiavi API, non devono essere utilizzate per accedere al modello. I seguenti requisiti si applicano al cliente in base alle piattaforme di distribuzione attraverso le quali il cliente accede al modello. Per ogni piattaforma applicabile, tutti gli utenti approvati e tutti i carichi di lavoro devono autenticarsi utilizzando credenziali di breve durata emesse e gestite dal servizio di identità nativo di quella piattaforma.

Chiavi API interim. Fino alla data limite, le chiavi API sono consentite in una concessione di accesso alla difesa solo se ogni chiave è (i) archiviata in un gestore di segreti o gestore di password, (ii) assegnata a una singola persona o carico di lavoro, (iii) mantenuta fuori dal codice sorgente, e (iv) sostituita almeno ogni 7 giorni. Anthropic può limitare la durata delle chiavi API in una concessione di accesso alla difesa a 7 giorni e può disabilitare le chiavi API nello spazio di lavoro concesso dalla data limite.

Utenti approvati. Non esiste un limite predefinito al numero di utenti approvati a questo livello di accesso.

I singoli sono idonei solo per l'accesso alla difesa. Quando la concessione è detenuta da un individuo, questa sezione si applica

Gestione delle credenziali. I seguenti requisiti si applicano al cliente in base alle piattaforme di distribuzione attraverso le quali il cliente accede al modello. Per ogni piattaforma applicabile, tutti gli utenti approvati e tutti i carichi di lavoro devono autenticarsi utilizzando credenziali di breve durata emesse e gestite dal servizio di identità nativo di quella piattaforma.

Autenticazione a più fattori. Al momento dell'accesso del cliente al CVP, l'autenticazione a più fattori resistente al phishing deve proteggere (i) tutti gli account che possono accedere allo spazio di lavoro concesso o detengono credenziali per esso, (ii) gli account degli utenti approvati presso il provider di identità del cliente, (iii) le identità AWS, Google Cloud o Azure che possono chiamare il modello, (iv) l'accesso amministrativo a qualsiasi cosa che emetta o memorizzi credenziali del modello, e (v) qualsiasi desktop virtuale o enclave utilizzato per soddisfare questi requisiti. L'autenticazione a più fattori resistente al phishing significa (i) una chiave di sicurezza FIDO2/WebAuthn, (ii) una passkey, sul dispositivo o in un gestore di password, o (iii) una smartcard/PIV, coerente con il foglio informativo CISA "Implementing Phishing-Resistant MFA" e NIST SP 800-63B-4. SMS, voce, codici inviati via email, codici dell'app di autenticazione e approvazioni push non si qualificano, e l'accesso tramite collegamento magico via email deve essere disabilitato.

Account organizzativi. Gli utenti approvati devono accedere con account nel dominio del cliente. Gli account personali e webmail non sono consentiti.

Utenti approvati. Lo spazio di lavoro concesso è limitato a settantacinque (75) utenti approvati che eseguono personalmente o supervisionano direttamente il lavoro per il quale la concessione è stata approvata. Le identità di carico di lavoro non contano verso quel numero. Il cliente può richiedere posti di utenti approvati aggiuntivi per iscritto (l'email è sufficiente). Solo gli amministratori designati possono aggiungere membri, modificare ruoli o creare identità di carico di lavoro o credenziali nello spazio di lavoro concesso.

Gateway. Se il cliente gestisce un gateway o proxy davanti al modello, deve ammettere solo utenti approvati o le loro identità di carico di lavoro, utilizzare una credenziale di breve durata propria e mantenere i suoi registri e trascritti limitati agli utenti approvati e ai team di sicurezza, amministrazione IT o fiducia e sicurezza del cliente.

Sistemi di credenziali gestiti dal cliente. Le credenziali emesse dai sistemi del cliente devono scadere entro 12 ore, devono essere emesse solo dopo l'autenticazione a più fattori resistente al phishing (per le persone) o un'identità di carico di lavoro verificata (per i servizi), e non devono lasciare alcuna credenziale statica su endpoint, nel codice sorgente o negli archivi condivisi. Le chiavi e i segreti che possono emettere credenziali del modello devono essere conservati in un gestore di segreti o servizio di gestione delle chiavi con registrazione dell'accesso.

Revoca. Il cliente deve essere in grado di revocare qualsiasi credenziale o identità compromessa entro 24 ore.

Offboarding. Il cliente deve rimuovere gli utenti approvati partiti o riassegnati e le loro identità di carico di lavoro dallo spazio di lavoro concesso entro tre (3) giorni lavorativi.

Uscita di rete. Ovunque il modello esegua lavori offensivi o agentivi, il traffico in uscita deve essere limitato a un elenco di autorizzazioni applicato fuori dall'host e deve essere registrato. Le workstation utilizzate solo per la richiesta interattiva possono utilizzare un elenco di autorizzazioni su host se il lavoro agentivo stesso viene eseguito in una sandbox che non può modificare tale elenco.

Dispositivi gestiti. Gli utenti approvati devono accedere allo spazio di lavoro concesso solo da dispositivi controllati dal cliente che ricevono aggiornamenti del sistema operativo automatici o regolarmente programmati, non da dispositivi personali.

Controlli dei precedenti. Ogni utente approvato, inclusi i contraenti, deve aver superato un controllo di identità e, dove legale, un controllo della storia criminale. Dove la legge locale limita i controlli criminali, la verifica dell'identità, del diritto al lavoro o dell'occupazione è accettata. Il controllo governativo o una clearance soddisfa questo requisito.

Procedura di incidente. Il cliente deve mantenere una procedura documentata per il sospetto di compromissione o abuso della concessione che copra la revoca delle credenziali e la sospensione del posto.

Enti governativi. Un'autorità FISMA per operare con una valutazione annuale indipendente dell'ispettore generale rispetto a NIST SP 800-53, o uno schema nazionale equivalente, soddisfa i requisiti di dispositivi gestiti, controlli dei precedenti e procedura di incidente. Tutti gli altri requisiti continuano ad applicarsi.

Autenticazione a più fattori. Al momento dell'accesso del cliente al CVP, l'autenticazione a più fattori resistente al phishing deve proteggere (i) tutti gli account che possono accedere allo spazio di lavoro concesso o detengono credenziali per esso, (ii) gli account degli utenti approvati presso il provider di identità del cliente, (iii) le identità AWS, Google Cloud o Azure che possono chiamare il modello, (iv) l'accesso amministrativo a qualsiasi cosa che emetta o memorizzi credenziali del modello, e (v) qualsiasi desktop virtuale o enclave utilizzato per soddisfare questi requisiti. L'autenticazione a più fattori resistente al phishing significa (i) una chiave di sicurezza FIDO2/WebAuthn, (ii) una passkey, sul dispositivo o in un gestore di password, o (iii) una smartcard/PIV, coerente con il foglio informativo CISA "Implementing Phishing-Resistant MFA" e NIST SP 800-63B-4. SMS, voce, codici inviati via email, codici dell'app di autenticazione e approvazioni push non si qualificano, e l'accesso tramite collegamento magico via email deve essere disabilitato.

Gestione delle credenziali. I seguenti requisiti si applicano al cliente in base alle piattaforme di distribuzione attraverso le quali il cliente accede al modello. Per ogni piattaforma applicabile, tutti gli utenti approvati e tutti i carichi di lavoro devono autenticarsi utilizzando credenziali di breve durata emesse e gestite dal servizio di identità nativo di quella piattaforma.

Single Sign-On e account organizzativi. Gli utenti approvati devono accedere con account nel dominio del cliente. Gli utenti approvati devono accedere con identità del dominio dell'organizzazione federate tramite il single sign-on del cliente. Gli account personali, webmail e non federati non sono consentiti.

Utenti approvati. Lo spazio di lavoro concesso è limitato a 25 utenti approvati che eseguono personalmente o supervisionano direttamente il lavoro per il quale la concessione è stata approvata. Le identità di carico di lavoro non contano verso quel numero. Il cliente può richiedere posti di utenti approvati aggiuntivi per iscritto (l'email è sufficiente). Solo gli amministratori designati possono aggiungere membri, modificare ruoli o creare identità di carico di lavoro o credenziali nello spazio di lavoro concesso.

Gateway. Se il cliente gestisce un gateway o proxy davanti al modello, deve ammettere solo utenti approvati o le loro identità di carico di lavoro, utilizzare una credenziale di breve durata propria e mantenere i suoi registri e trascritti limitati agli utenti approvati e ai team di sicurezza, amministrazione IT o fiducia e sicurezza del cliente.

Sistemi di credenziali gestiti dal cliente. Le credenziali emesse dai sistemi del cliente devono scadere entro 12 ore, devono essere emesse solo dopo l'autenticazione a più fattori resistente al phishing (per le persone) o un'identità di carico di lavoro verificata (per i servizi), e non devono lasciare alcuna credenziale statica su endpoint, nel codice sorgente o negli archivi condivisi. Le chiavi e i segreti che possono emettere credenziali del modello devono essere conservati in un gestore di segreti o servizio di gestione delle chiavi con registrazione dell'accesso.

Revoca. Il cliente deve essere in grado di revocare qualsiasi credenziale o identità compromessa entro 24 ore.

Offboarding. Il cliente deve rimuovere gli utenti approvati partiti o riassegnati e le loro identità di carico di lavoro dallo spazio di lavoro concesso entro 3 giorni lavorativi.

Uscita di rete. Ovunque il modello esegua lavori offensivi o agentivi, il traffico in uscita deve essere limitato a un elenco di autorizzazioni applicato fuori dall'host e deve essere registrato. Le workstation utilizzate solo per la richiesta interattiva possono utilizzare un elenco di autorizzazioni su host se il lavoro agentivo stesso viene eseguito in una sandbox che non può modificare tale elenco.

Dispositivi gestiti e protezione da malware. Gli utenti approvati devono accedere allo spazio di lavoro concesso solo da dispositivi controllati dal cliente, non da dispositivi personali, e che ricevono aggiornamenti del sistema operativo automatici o regolarmente programmati. Ogni dispositivo che un utente approvato utilizza per accedere allo spazio di lavoro concesso deve essere gestito dal cliente e deve eseguire l'elenco di autorizzazioni o il rifiuto dell'applicazione in modalità di applicazione, o un agente di rilevamento e risposta dell'endpoint in modalità di blocco o prevenzione. Un desktop virtuale gestito o un enclave che soddisfa questo standard si qualifica anche.

Controlli dei precedenti. Ogni utente approvato, inclusi i contraenti, deve aver superato un controllo di identità e, dove legale, un controllo della storia criminale. Dove la legge locale limita i controlli criminali, la verifica dell'identità, del diritto al lavoro o dell'occupazione è accettata. Il controllo governativo o una clearance soddisfa questo requisito.

Procedura di incidente. Il cliente deve mantenere una procedura documentata per il sospetto di compromissione o abuso della concessione che copra la revoca delle credenziali, la sospensione del posto e la notifica ad Anthropic.

Enti governativi. Un'autorità FISMA per operare con una valutazione annuale indipendente dell'ispettore generale rispetto a NIST SP 800-53, o uno schema nazionale equivalente, soddisfa i requisiti di dispositivi gestiti e protezione da malware, controlli dei precedenti e procedura di incidente. Tutti gli altri requisiti continuano ad applicarsi.