Клиент должен соответствовать и поддерживать следующие требования безопасности для каждого уровня доступа программы Cyber Verification Program, который он имеет ("Уровень доступа"). Эти требования применяются к Одобренным пользователям и к Предоставленным рабочим пространствам.
1. Все уровни доступа.
Контактное лицо по безопасности. Клиент должен предоставить Anthropic назначенного контактного лица по безопасности, который может получать оповещения о безопасности и злоупотреблениях и может действовать в соответствии с ними.
Отчетность об инцидентах. Клиент должен сообщить об предполагаемых нарушениях или злоупотреблениях, связанных с предоставлением доступа, в Anthropic в течение 72 часов или в течение 24 часов для инцидента безопасности. Отчет можно отправить на адрес [email protected] или контактному лицу вашей команды аккаунта.
Сотрудничество. Клиент должен расследовать любые злоупотребления, выявленные Anthropic, в течение 48 часов, работать с Anthropic для их устранения и отвечать на запросы о злоупотреблениях в течение семи (7) дней.
Личный доступ. Каждый Одобренный пользователь должен входить под своим именем. Общие входы, места, сеансы и удостоверения рабочей нагрузки, а также расширения браузера или инструменты прокси, которые предоставляют доступ к сеансу другим лицам, не являющимся явно Одобренным пользователем, соответствующим всем требованиям ниже, не допускаются.
Атрибуция использования. Профили пользователей должны оставаться включенными в Предоставленном рабочем пространстве, чтобы запросы можно было отнести к названному пользователю или удостоверению рабочей нагрузки.
Уведомление об изменениях. Клиент должен уведомить Anthropic в течение тридцати (30) дней о существенном изменении его позиции безопасности, собственности, штаб-квартиры или контактного лица по безопасности.
Постоянный контроль. Anthropic может запросить, чтобы Клиент предоставил доказательства соответствия этим требованиям безопасности программы Cyber Verification Program.
2. Доступ Defense.
Многофакторная аутентификация. На момент доступа Клиента к CVP все учетные записи, которые могут входить в Предоставленное рабочее пространство или содержать учетные данные для него, должны иметь включенную многофакторную аутентификацию. К 15 декабря 2026 г. ("Дата отсечки") все такие учетные записи должны использовать фишинг-устойчивую многофакторную аутентификацию, как определено в информационном листе CISA "Implementing Phishing-Resistant MFA" и в соответствии с NIST SP 800-63B-4, что означает (i) ключ безопасности FIDO2/WebAuthn, (ii) пароль на устройстве или в менеджере паролей, или (iii) смарт-карту/PIV, и вход по ссылке электронной почты должен быть отключен. SMS, голос, коды по электронной почте, коды приложения аутентификатора и push-уведомления не подходят.
Управление учетными данными. К Дате отсечки загруженные, экспортированные или иные долгоживущие статические учетные данные, включая ключи API, не должны использоваться для доступа к модели. Следующие требования применяются к Клиенту в зависимости от платформ развертывания, через которые Клиент получает доступ к модели. Для каждой применимой платформы все Одобренные пользователи и все рабочие нагрузки должны аутентифицироваться с использованием краткосрочных учетных данных, выданных и управляемых встроенной службой идентификации этой платформы.
Anthropic (первичный API и консоль). Статические или долгоживущие ключи API не допускаются, включая интерактивный доступ к Claude Console, Claude for Enterprise, Claude Code и другим поверхностям приложений Anthropic.
Google Vertex. Загруженные файлы JSON ключей учетной записи службы не допускаются.
Amazon Web Services (Amazon Bedrock). Пары ключей доступа пользователя IAM (ID ключа доступа и секретный ключ доступа) не допускаются, за исключением краткосрочных ключей API Bedrock, которые истекают в течение 12 часов или длительности сеанса Bedrock, в зависимости от того, что короче.
Microsoft Azure (Azure AI Foundry). Ключи API и экспортированные секреты клиента субъекта-службы или сертификаты не допускаются.
Временные ключи API. До Даты отсечки ключи API допускаются в соответствии с грантом Defense Access только если каждый ключ (i) хранится в менеджере секретов или менеджере паролей, (ii) назначен одному человеку или рабочей нагрузке, (iii) хранится вне исходного кода и (iv) заменяется по крайней мере каждые 7 дней. Anthropic может ограничить время жизни ключей API в соответствии с грантом Defense Access до 7 дней и может отключить ключи API в Предоставленном рабочем пространстве с Даты отсечки.
Одобренные пользователи. На этом уровне доступа нет ограничения по умолчанию на количество Одобренных пользователей.
3. Доступ Defense для физических лиц.
Физические лица имеют право только на доступ Defense. Если грант принадлежит физическому лицу, применяется этот раздел.
Многофакторная аутентификация. Физическое лицо должно входить в учетную запись Anthropic, которая содержит грант, только через Google или эквивалентного поставщика идентификации. С момента предоставления доступа эта учетная запись должна иметь включенную многофакторную аутентификацию. К 15 декабря 2026 г. ("Дата отсечки") эта учетная запись должна использовать фишинг-устойчивую многофакторную аутентификацию, что означает ключ безопасности, пароль или смарт-карту/PIV, и физическое лицо не должно использовать вход по ссылке электронной почты. SMS, голос, коды по электронной почте, коды приложения аутентификатора и push-уведомления не подходят.
Управление учетными данными. К Дате отсечки статические или долгоживущие учетные данные, включая ключи API, не должны использоваться для доступа к модели. Claude Code, Claude Console и claude.ai аутентифицируются через OAuth. Программный доступ для рабочих нагрузок, если предлагается, должен использовать Workload Identity Federation. До Даты отсечки один ключ API допускается только если он (i) хранится в менеджере паролей или локальном хранилище секретов, (ii) никогда не передается и не помещается в исходный код, и (iii) заменяется по крайней мере каждые 7 дней. Anthropic может ограничить время жизни ключей API в соответствии с грантом до 7 дней и может отключить ключи API с Даты отсечки.
Личный доступ. Только это физическое лицо может использовать доступ. Общие входы или сеансы, а также расширения браузера или инструменты прокси, которые предоставляют доступ к сеансу другим лицам, не допускаются.
Мониторинг. Весь трафик в соответствии с грантом сохраняется и контролируется. Нулевое сохранение данных недоступно.
Из требований всех уровней доступа к физическому лицу применяются отчетность об инцидентах, сотрудничество и постоянный контроль.
4. Доступ Red Team.
Управление учетными данными. Следующие требования применяются к Клиенту в зависимости от платформ развертывания, через которые Клиент получает доступ к модели. Для каждой применимой платформы все Одобренные пользователи и все рабочие нагрузки должны аутентифицироваться с использованием краткосрочных учетных данных, выданных и управляемых встроенной службой идентификации этой платформы.
Anthropic (первичный API и консоль). Статические или долгоживущие ключи API не допускаются, включая интерактивный доступ к Claude Console, Claude for Enterprise, Claude Code и другим поверхностям приложений Anthropic.
Google Vertex. Загруженные файлы JSON ключей учетной записи службы не допускаются.
Amazon Web Services (Amazon Bedrock). Пары ключей доступа пользователя IAM (ID ключа доступа и секретный ключ доступа) не допускаются, за исключением краткосрочных ключей API Bedrock, которые истекают в течение 12 часов или длительности сеанса Bedrock, в зависимости от того, что короче.
Microsoft Azure (Azure AI Foundry). Ключи API и экспортированные секреты клиента субъекта-службы или сертификаты не допускаются.
Многофакторная аутентификация. На момент доступа Клиента к CVP фишинг-устойчивая многофакторная аутентификация должна защищать (i) все учетные записи, которые могут входить в Предоставленное рабочее пространство или содержать учетные данные для него, (ii) учетные записи Одобренных пользователей у поставщика идентификации Клиента, (iii) удостоверения AWS, Google Cloud или Azure, которые могут вызывать модель, (iv) административный доступ ко всему, что выдает или хранит учетные данные модели, и (v) любой виртуальный рабочий стол или анклав, используемый для соответствия этим требованиям. Фишинг-устойчивая многофакторная аутентификация означает (i) ключ безопасности FIDO2/WebAuthn, (ii) пароль на устройстве или в менеджере паролей, или (iii) смарт-карту/PIV, в соответствии с информационным листом CISA "Implementing Phishing-Resistant MFA" и NIST SP 800-63B-4. SMS, голос, коды по электронной почте, коды приложения аутентификатора и push-уведомления не подходят, и вход по ссылке электронной почты должен быть отключен.
Учетные записи организации. Одобренные пользователи должны входить с учетными записями в домене Клиента. Личные и веб-почтовые учетные записи не допускаются.
Одобренные пользователи. Предоставленное рабочее пространство ограничено семьюдесятью пятью (75) Одобренными пользователями, которые лично выполняют или непосредственно контролируют работу, для которой был одобрен грант. Удостоверения рабочей нагрузки не учитываются в этом числе. Клиент может запросить дополнительные места Одобренных пользователей в письменной форме (достаточно электронной почты). Только названные администраторы могут добавлять членов, изменять роли или создавать удостоверения рабочей нагрузки или учетные данные в Предоставленном рабочем пространстве.
Шлюзы. Если Клиент управляет шлюзом или прокси перед моделью, он должен допускать только Одобренных пользователей или их удостоверения рабочей нагрузки, использовать краткосрочные учетные данные собственного шлюза и хранить свои журналы и стенограммы в ограниченном доступе для Одобренных пользователей и команд безопасности, IT-администрирования или доверия и безопасности Клиента.
Системы учетных данных, управляемые Клиентом. Учетные данные, выданные собственными системами Клиента, должны истекать в течение 12 часов, должны выдаваться только после фишинг-устойчивой многофакторной аутентификации (для людей) или проверенного удостоверения рабочей нагрузки (для служб) и не должны оставлять статические учетные данные на конечных точках, в исходном коде или в общих хранилищах. Ключи и секреты, которые могут выдавать учетные данные модели, должны храниться в менеджере секретов или сервисе управления ключами с логированием доступа.
Отзыв. Клиент должен иметь возможность отозвать любые скомпрометированные учетные данные или удостоверение в течение 24 часов.
Offboarding. Клиент должен удалить уволенных или переведенных Одобренных пользователей и их удостоверения рабочей нагрузки из Предоставленного рабочего пространства в течение трех (3) рабочих дней.
Исходящий сетевой трафик. Везде, где модель выполняет наступательную или агентивную работу, исходящий трафик должен быть ограничен списком разрешений, применяемым вне хоста, и должен быть залогирован. Рабочие станции, используемые только для интерактивного запроса, могут использовать список разрешений на хосте, если сама агентивная работа выполняется в изолированной среде, которая не может изменить этот список.
Управляемые устройства. Одобренные пользователи должны получать доступ к Предоставленному рабочему пространству только с устройств, которыми управляет Клиент и которые получают автоматические или регулярно запланированные обновления операционной системы, а не с личных устройств.
Проверка биографических данных. Каждый Одобренный пользователь, включая подрядчиков, должен пройти проверку личности и, где это разрешено законом, проверку уголовного прошлого. Если местное законодательство ограничивает проверку уголовного прошлого, принимается проверка личности, права на работу или трудоустройства. Государственная проверка или допуск удовлетворяет этому требованию.
Процедура инцидента. Клиент должен поддерживать документированную процедуру для предполагаемого компрометирования или злоупотребления грантом, которая охватывает отзыв учетных данных и приостановку места.
Государственные учреждения. FISMA Authority to Operate с ежегодной независимой оценкой Инспектора Генерального прокурора в соответствии с NIST SP 800-53 или эквивалентная национальная схема удовлетворяет требованиям управляемых устройств, проверки биографических данных и процедуры инцидента. Все остальные требования продолжают применяться.
5. Специализированный доступ.
Многофакторная аутентификация. На момент доступа Клиента к CVP фишинг-устойчивая многофакторная аутентификация должна защищать (i) все учетные записи, которые могут входить в Предоставленное рабочее пространство или содержать учетные данные для него, (ii) учетные записи Одобренных пользователей у поставщика идентификации Клиента, (iii) удостоверения AWS, Google Cloud или Azure, которые могут вызывать модель, (iv) административный доступ ко всему, что выдает или хранит учетные данные модели, и (v) любой виртуальный рабочий стол или анклав, используемый для соответствия этим требованиям. Фишинг-устойчивая многофакторная аутентификация означает (i) ключ безопасности FIDO2/WebAuthn, (ii) пароль на устройстве или в менеджере паролей, или (iii) смарт-карту/PIV, в соответствии с информационным листом CISA "Implementing Phishing-Resistant MFA" и NIST SP 800-63B-4. SMS, голос, коды по электронной почте, коды приложения аутентификатора и push-уведомления не подходят, и вход по ссылке электронной почты должен быть отключен.
Управление учетными данными. Следующие требования применяются к Клиенту в зависимости от платформ развертывания, через которые Клиент получает доступ к модели. Для каждой применимой платформы все Одобренные пользователи и все рабочие нагрузки должны аутентифицироваться с использованием краткосрочных учетных данных, выданных и управляемых встроенной службой идентификации этой платформы.
Anthropic (первичный API и консоль). Статические или долгоживущие ключи API не допускаются, включая интерактивный доступ к Claude Console, Claude for Enterprise, Claude Code и другим поверхностям приложений Anthropic.
Google Vertex. Загруженные файлы JSON ключей учетной записи службы не допускаются.
Amazon Web Services (Amazon Bedrock). Пары ключей доступа пользователя IAM (ID ключа доступа и секретный ключ доступа) не допускаются, за исключением краткосрочных ключей API Bedrock, которые истекают в течение 12 часов или длительности сеанса Bedrock, в зависимости от того, что короче.
Microsoft Azure (Azure AI Foundry). Ключи API и экспортированные секреты клиента субъекта-службы или сертификаты не допускаются.
Единый вход и учетные записи организации. Одобренные пользователи должны входить с учетными записями в собственном домене Клиента. Одобренные пользователи должны входить с удостоверениями домена организации, объединенными через единый вход Клиента. Личные, веб-почтовые и необъединенные учетные записи не допускаются.
Одобренные пользователи. Предоставленное рабочее пространство ограничено 25 Одобренными пользователями, которые лично выполняют или непосредственно контролируют работу, для которой был одобрен грант. Удостоверения рабочей нагрузки не учитываются в этом числе. Клиент может запросить дополнительные места Одобренных пользователей в письменной форме (достаточно электронной почты). Только названные администраторы могут добавлять членов, изменять роли или создавать удостоверения рабочей нагрузки или учетные данные в Предоставленном рабочем пространстве.
Шлюзы. Если Клиент управляет шлюзом или прокси перед моделью, он должен допускать только Одобренных пользователей или их удостоверения рабочей нагрузки, использовать краткосрочные учетные данные собственного шлюза и хранить свои журналы и стенограммы в ограниченном доступе для Одобренных пользователей и команд безопасности, IT-администрирования или доверия и безопасности Клиента.
Системы учетных данных, управляемые Клиентом. Учетные данные, выданные собственными системами Клиента, должны истекать в течение 12 часов, должны выдаваться только после фишинг-устойчивой многофакторной аутентификации (для людей) или проверенного удостоверения рабочей нагрузки (для служб) и не должны оставлять статические учетные данные на конечных точках, в исходном коде или в общих хранилищах. Ключи и секреты, которые могут выдавать учетные данные модели, должны храниться в менеджере секретов или сервисе управления ключами с логированием доступа.
Отзыв. Клиент должен иметь возможность отозвать любые скомпрометированные учетные данные или удостоверение в течение 24 часов.
Offboarding. Клиент должен удалить уволенных или переведенных Одобренных пользователей и их удостоверения рабочей нагрузки из Предоставленного рабочего пространства в течение 3 рабочих дней.
Исходящий сетевой трафик. Везде, где модель выполняет наступательную или агентивную работу, исходящий трафик должен быть ограничен списком разрешений, применяемым вне хоста, и должен быть залогирован. Рабочие станции, используемые только для интерактивного запроса, могут использовать список разрешений на хосте, если сама агентивная работа выполняется в изолированной среде, которая не может изменить этот список.
Управляемые устройства и защита от вредоносного ПО. Одобренные пользователи должны получать доступ к Предоставленному рабочему пространству только с устройств, которыми управляет Клиент, а не с личных устройств, и которые получают автоматические или регулярно запланированные обновления операционной системы. Каждое устройство, которое Одобренный пользователь использует для доступа к Предоставленному рабочему пространству, должно управляться Клиентом и должно запускать список разрешений приложений или список запретов в режиме принудительного применения, или агент обнаружения и реагирования на конечных точках в режиме блокировки или предотвращения. Управляемый виртуальный рабочий стол или анклав, соответствующий этому стандарту, также подходит.
Проверка биографических данных. Каждый Одобренный пользователь, включая подрядчиков, должен пройти проверку личности и, где это разрешено законом, проверку уголовного прошлого. Если местное законодательство ограничивает проверку уголовного прошлого, принимается проверка личности, права на работу или трудоустройства. Государственная проверка или допуск удовлетворяет этому требованию.
Процедура инцидента. Клиент должен поддерживать документированную процедуру для предполагаемого компрометирования или злоупотребления грантом, которая охватывает отзыв учетных данных, приостановку места и уведомление Anthropic.
Государственные учреждения. FISMA Authority to Operate с ежегодной независимой оценкой Инспектора Генерального прокурора в соответствии с NIST SP 800-53 или эквивалентная национальная схема удовлетворяет требованиям управляемых устройств и защиты от вредоносного ПО, проверки биографических данных и процедуры инцидента. Все остальные требования продолжают применяться.