Exigences de sécurité du programme de vérification cybernétique

Contact de sécurité. Le client doit fournir à Anthropic un contact de sécurité nommé qui peut recevoir les alertes de sécurité et d'abus et est capable d'agir en conséquence.

Signalement des incidents. Le client doit signaler à Anthropic les violations ou abus suspects impliquant la subvention dans les 72 heures, ou dans les 24 heures pour un incident de sécurité. Le signalement peut être effectué à [email protected] ou auprès de votre contact d'équipe de compte.

Coopération. Le client doit enquêter sur tout abus identifié par Anthropic dans les 48 heures, collaborer avec Anthropic pour le corriger et répondre aux demandes d'abus dans les sept (7) jours.

Accès personnel. Chaque utilisateur approuvé doit se connecter en tant que lui-même. Les connexions partagées, les sièges, les sessions, les identités de charge de travail, ainsi que les extensions de navigateur ou les outils proxy qui exposent une session à d'autres personnes qui ne sont pas explicitement un utilisateur approuvé répondant à toutes les exigences ci-dessous ne sont pas autorisés.

Attribution d'utilisation. Les profils utilisateur doivent rester activés sur l'espace de travail accordé afin que les demandes puissent être attribuées à un utilisateur nommé ou à une identité de charge de travail.

Avis de modifications. Le client doit notifier Anthropic dans les trente (30) jours d'un changement matériel à sa posture de sécurité, sa propriété, son siège social ou son contact de sécurité.

Examen continu. Anthropic peut demander au client de fournir une preuve de conformité avec ces exigences de sécurité du programme de vérification cybernétique.

Authentification multifacteur. Au moment de l'accès du client au CVP, tous les comptes qui peuvent se connecter à l'espace de travail accordé ou détenir des identifiants pour celui-ci doivent avoir l'authentification multifacteur activée. D'ici le 15 décembre 2026 (la « Date limite »), tous ces comptes doivent utiliser l'authentification multifacteur résistante au phishing telle que définie dans la fiche d'information du CISA « Implementing Phishing-Resistant MFA » et conformément à NIST SP 800-63B-4, ce qui signifie (i) une clé de sécurité FIDO2/WebAuthn, (ii) une clé d'accès, sur l'appareil ou dans un gestionnaire de mots de passe, ou (iii) une carte à puce/PIV, et la connexion par lien magique par e-mail doit être désactivée. Les SMS, les appels vocaux, les codes envoyés par e-mail, les codes d'application d'authentification et les approbations par notification ne sont pas acceptés.

Gestion des identifiants. D'ici la Date limite, les identifiants statiques téléchargés, exportés ou autrement de longue durée, y compris les clés API, ne doivent pas être utilisés pour accéder au modèle. Les exigences suivantes s'appliquent au client en fonction de la ou des plateformes de déploiement par lesquelles le client accède au modèle. Pour chaque plateforme applicable, tous les utilisateurs approuvés et toutes les charges de travail doivent s'authentifier à l'aide d'identifiants de courte durée émis et gérés par le service d'identité natif de cette plateforme.

Clés API provisoires. Jusqu'à la Date limite, les clés API sont autorisées dans le cadre d'une subvention d'accès à la défense uniquement si chaque clé est (i) stockée dans un gestionnaire de secrets ou un gestionnaire de mots de passe, (ii) attribuée à une seule personne ou charge de travail, (iii) conservée en dehors du code source, et (iv) remplacée au moins tous les 7 jours. Anthropic peut limiter la durée de vie des clés API dans le cadre d'une subvention d'accès à la défense à 7 jours et peut désactiver les clés API sur l'espace de travail accordé à partir de la Date limite.

Utilisateurs approuvés. Il n'y a pas de limite par défaut au nombre d'utilisateurs approuvés à ce niveau d'accès.

Les particuliers ne sont admissibles qu'à l'accès à la défense. Lorsque la subvention est détenue par un particulier, cette section s'applique.

Gestion des identifiants. Les exigences suivantes s'appliquent au client en fonction de la ou des plateformes de déploiement par lesquelles le client accède au modèle. Pour chaque plateforme applicable, tous les utilisateurs approuvés et toutes les charges de travail doivent s'authentifier à l'aide d'identifiants de courte durée émis et gérés par le service d'identité natif de cette plateforme.

Authentification multifacteur. Au moment de l'accès du client au CVP, l'authentification multifacteur résistante au phishing doit protéger (i) tous les comptes qui peuvent se connecter à l'espace de travail accordé ou détenir des identifiants pour celui-ci, (ii) les comptes des utilisateurs approuvés chez le fournisseur d'identité du client, (iii) les identités AWS, Google Cloud ou Azure qui peuvent appeler le modèle, (iv) l'accès administratif à tout ce qui émet ou stocke les identifiants du modèle, et (v) tout bureau virtuel ou enclave utilisé pour respecter ces exigences. L'authentification multifacteur résistante au phishing signifie (i) une clé de sécurité FIDO2/WebAuthn, (ii) une clé d'accès, sur l'appareil ou dans un gestionnaire de mots de passe, ou (iii) une carte à puce/PIV, conformément à la fiche d'information du CISA « Implementing Phishing-Resistant MFA » et à NIST SP 800-63B-4. Les SMS, les appels vocaux, les codes envoyés par e-mail, les codes d'application d'authentification et les approbations par notification ne sont pas acceptés, et la connexion par lien magique par e-mail doit être désactivée.

Comptes organisationnels. Les utilisateurs approuvés doivent se connecter avec des comptes sur le domaine du client. Les comptes personnels et de messagerie Web ne sont pas autorisés.

Utilisateurs approuvés. L'espace de travail accordé est limité à soixante-quinze (75) utilisateurs approuvés qui exécutent personnellement ou supervisent directement le travail pour lequel la subvention a été approuvée. Les identités de charge de travail ne comptent pas vers ce nombre. Le client peut demander des sièges d'utilisateurs approuvés supplémentaires par écrit (un e-mail suffisant). Seuls les administrateurs nommés peuvent ajouter des membres, modifier les rôles ou créer des identités de charge de travail ou des identifiants sur l'espace de travail accordé.

Passerelles. Si le client exploite une passerelle ou un proxy devant le modèle, il doit admettre uniquement les utilisateurs approuvés ou leurs identités de charge de travail, utiliser un identifiant de courte durée qui lui est propre et garder ses journaux et transcriptions limités aux utilisateurs approuvés et aux équipes de sécurité, d'administration informatique ou de confiance et de sécurité du client.

Systèmes d'identifiants exploités par le client. Les identifiants émis par les propres systèmes du client doivent expirer dans les 12 heures, doivent être émis uniquement après l'authentification multifacteur résistante au phishing (pour les personnes) ou une identité de charge de travail vérifiée (pour les services), et ne doivent laisser aucun identifiant statique sur les points de terminaison, dans le code source ou dans les magasins partagés. Les clés et secrets qui peuvent émettre des identifiants de modèle doivent être conservés dans un gestionnaire de secrets ou un service de gestion des clés avec journalisation d'accès.

Révocation. Le client doit être capable de révoquer tout identifiant ou identité compromis dans les 24 heures.

Départ. Le client doit supprimer les utilisateurs approuvés partis ou réaffectés, ainsi que leurs identités de charge de travail, de l'espace de travail accordé dans les trois (3) jours ouvrables.

Sortie réseau. Partout où le modèle effectue un travail offensif ou agentif, le trafic sortant doit être limité à une liste d'autorisation appliquée en dehors de l'hôte et doit être enregistré. Les postes de travail utilisés uniquement pour les invites interactives peuvent utiliser une liste d'autorisation sur l'hôte si le travail agentif lui-même s'exécute dans un bac à sable qui ne peut pas modifier cette liste.

Appareils gérés. Les utilisateurs approuvés doivent accéder à l'espace de travail accordé uniquement à partir d'appareils que le client contrôle et qui reçoivent des mises à jour automatiques ou régulièrement planifiées du système d'exploitation, et non à partir d'appareils personnels.

Vérifications des antécédents. Chaque utilisateur approuvé, y compris les entrepreneurs, doit avoir réussi une vérification d'identité et, le cas échéant, une vérification des antécédents criminels. Lorsque la loi locale restreint les vérifications criminelles, la vérification d'identité, du droit de travailler ou de l'emploi est acceptée. L'examen gouvernemental ou une habilitation satisfait à cette exigence.

Procédure d'incident. Le client doit maintenir une procédure documentée pour la compromission ou l'abus suspect de la subvention qui couvre la révocation des identifiants et la suspension des sièges.

Entités gouvernementales. Une autorisation FISMA d'exploitation avec une évaluation annuelle indépendante de l'inspecteur général par rapport à NIST SP 800-53, ou un régime national équivalent, satisfait aux exigences relatives aux appareils gérés, aux vérifications des antécédents et à la procédure d'incident. Toutes les autres exigences continuent de s'appliquer.

Authentification multifacteur. Au moment de l'accès du client au CVP, l'authentification multifacteur résistante au phishing doit protéger (i) tous les comptes qui peuvent se connecter à l'espace de travail accordé ou détenir des identifiants pour celui-ci, (ii) les comptes des utilisateurs approuvés chez le fournisseur d'identité du client, (iii) les identités AWS, Google Cloud ou Azure qui peuvent appeler le modèle, (iv) l'accès administratif à tout ce qui émet ou stocke les identifiants du modèle, et (v) tout bureau virtuel ou enclave utilisé pour respecter ces exigences. L'authentification multifacteur résistante au phishing signifie (i) une clé de sécurité FIDO2/WebAuthn, (ii) une clé d'accès, sur l'appareil ou dans un gestionnaire de mots de passe, ou (iii) une carte à puce/PIV, conformément à la fiche d'information du CISA « Implementing Phishing-Resistant MFA » et à NIST SP 800-63B-4. Les SMS, les appels vocaux, les codes envoyés par e-mail, les codes d'application d'authentification et les approbations par notification ne sont pas acceptés, et la connexion par lien magique par e-mail doit être désactivée.

Gestion des identifiants. Les exigences suivantes s'appliquent au client en fonction de la ou des plateformes de déploiement par lesquelles le client accède au modèle. Pour chaque plateforme applicable, tous les utilisateurs approuvés et toutes les charges de travail doivent s'authentifier à l'aide d'identifiants de courte durée émis et gérés par le service d'identité natif de cette plateforme.

Authentification unique et comptes organisationnels. Les utilisateurs approuvés doivent se connecter avec des comptes sur le propre domaine du client. Les utilisateurs approuvés doivent se connecter avec des identités de domaine organisationnel fédérées via l'authentification unique du client. Les comptes personnels, de messagerie Web et non fédérés ne sont pas autorisés.

Utilisateurs approuvés. L'espace de travail accordé est limité à 25 utilisateurs approuvés qui exécutent personnellement ou supervisent directement le travail pour lequel la subvention a été approuvée. Les identités de charge de travail ne comptent pas vers ce nombre. Le client peut demander des sièges d'utilisateurs approuvés supplémentaires par écrit (un e-mail suffisant). Seuls les administrateurs nommés peuvent ajouter des membres, modifier les rôles ou créer des identités de charge de travail ou des identifiants sur l'espace de travail accordé.

Passerelles. Si le client exploite une passerelle ou un proxy devant le modèle, il doit admettre uniquement les utilisateurs approuvés ou leurs identités de charge de travail, utiliser un identifiant de courte durée qui lui est propre et garder ses journaux et transcriptions limités aux utilisateurs approuvés et aux équipes de sécurité, d'administration informatique ou de confiance et de sécurité du client.

Systèmes d'identifiants exploités par le client. Les identifiants émis par les propres systèmes du client doivent expirer dans les 12 heures, doivent être émis uniquement après l'authentification multifacteur résistante au phishing (pour les personnes) ou une identité de charge de travail vérifiée (pour les services), et ne doivent laisser aucun identifiant statique sur les points de terminaison, dans le code source ou dans les magasins partagés. Les clés et secrets qui peuvent émettre des identifiants de modèle doivent être conservés dans un gestionnaire de secrets ou un service de gestion des clés avec journalisation d'accès.

Révocation. Le client doit être capable de révoquer tout identifiant ou identité compromis dans les 24 heures.

Départ. Le client doit supprimer les utilisateurs approuvés partis ou réaffectés, ainsi que leurs identités de charge de travail, de l'espace de travail accordé dans les 3 jours ouvrables.

Sortie réseau. Partout où le modèle effectue un travail offensif ou agentif, le trafic sortant doit être limité à une liste d'autorisation appliquée en dehors de l'hôte et doit être enregistré. Les postes de travail utilisés uniquement pour les invites interactives peuvent utiliser une liste d'autorisation sur l'hôte si le travail agentif lui-même s'exécute dans un bac à sable qui ne peut pas modifier cette liste.

Appareils gérés et protection contre les logiciels malveillants. Les utilisateurs approuvés doivent accéder à l'espace de travail accordé uniquement à partir d'appareils que le client contrôle, et non à partir d'appareils personnels, et qui reçoivent des mises à jour automatiques ou régulièrement planifiées du système d'exploitation. Chaque appareil qu'un utilisateur approuvé utilise pour accéder à l'espace de travail accordé doit être géré par le client et doit exécuter une liste d'autorisation ou de refus d'application en mode d'application, ou un agent de détection et de réponse aux points de terminaison en mode de blocage ou de prévention. Un bureau virtuel géré ou un enclave qui respecte cette norme est également admissible.

Vérifications des antécédents. Chaque utilisateur approuvé, y compris les entrepreneurs, doit avoir réussi une vérification d'identité et, le cas échéant, une vérification des antécédents criminels. Lorsque la loi locale restreint les vérifications criminelles, la vérification d'identité, du droit de travailler ou de l'emploi est acceptée. L'examen gouvernemental ou une habilitation satisfait à cette exigence.

Procédure d'incident. Le client doit maintenir une procédure documentée pour la compromission ou l'abus suspect de la subvention qui couvre la révocation des identifiants, la suspension des sièges et la notification d'Anthropic.

Entités gouvernementales. Une autorisation FISMA d'exploitation avec une évaluation annuelle indépendante de l'inspecteur général par rapport à NIST SP 800-53, ou un régime national équivalent, satisfait aux exigences relatives aux appareils gérés et à la protection contre les logiciels malveillants, aux vérifications des antécédents et à la procédure d'incident. Toutes les autres exigences continuent de s'appliquer.