[Документация Yandex Cloud](../../index.md) > [Безопасность в Yandex Cloud](../index.md) > Стандарт безопасности для внедрения и эксплуатации ИИ-систем в Yandex Cloud, версия 1.0.0 > IAM, сеть, шифрование, секреты и аудит

# IAM, сеть, шифрование, секреты и аудит

{#iam-network-crypto-secrets-audit}

В этом разделе субъектом может быть человек, сервисный аккаунт, агент, MCP-клиент или бэкенд инструмента. Модель доступа из `AI-IAM-LEASTPRIV1` связывает субъект, операцию, ресурс, роль или иную политику и уровень назначения. Права на облачный ресурс не заменяют прикладную авторизацию пользователя внутри ИИ-системы.

## Права и доступ {#rights-access}

### Межкомпонентные соединения ограничены фактической топологией {#intercomponent-connections-limited-by-topology}

{#ai-net2-id}

Идентификатор требования: `AI-NET2`

{#ai-net2-requirement}

**Требование**

Владелец системы должен определить разрешенные входящие, исходящие и межкомпонентные соединения между приложением, модельным API, RAG-хранилищем, агентом, инструментом и журналами. Для связи фиксируются назначение, владелец, источник, получатель и способ прикладной аутентификации. Там, где сервис поддерживает VPC и группы безопасности, правила должны разрешать только необходимые направления, протоколы, порты и источники.

{#ai-net2-implementation}

**Реализация**

[Группы безопасности VPC](../../vpc/concepts/security-groups.md) отслеживают состояние соединений. Они не выполняют документную авторизацию и не проверяют смысл модельного запроса.

Для бессерверных и управляемых сервисов необходимо отдельно проверить опубликованный способ сетевого подключения. Подключение сети [Serverless Containers](../../serverless-containers/index.md) и [Cloud Functions](../../functions/index.md) управляет исходящим доступом к пользовательской VPC, но не является закрытым входом к экземпляру. Управляемому API AI Studio не приписываются пользовательские подсети или частные эндпоинты, которых нет в документации. [Yandex Identity and Access Management](../../iam/index.md) не заменяет внутренний RBAC Kubernetes или OpenSearch уровня данных.

{#ai-net2-check}

**Проверка**

1. Сопоставьте правила с диаграммой потоков и выполните разрешенное и запрещенное соединение для каждой границы.
1. Особое внимание уделите правилам широкого доступа, общим сервисным аккаунтам и пути в обход шлюза.
1. Проверяйте фактическое соединение, маршрут и отказ приложения, а не только конфигурацию групп безопасности; при исправлении широкое правило не заменяется правилом `0.0.0.0/0`.

{#ai-net2-artifacts}

**Артефакт**

* Диаграмма потоков.
* Правила групп безопасности.
* Разрешенное и запрещенное соединение.
* Результаты соединений из разрешенного и запрещенного источников.

### Рабочие идентичности имеют минимальные эффективные права {#workload-identities-minimal-effective-rights}

{#ai-iam-leastpriv1-id}

Идентификатор требования: `AI-IAM-LEASTPRIV1`

{#ai-iam-leastpriv1-requirement}

**Требование**

Продуктивный компонент должен выполняться от отдельной рабочей идентичности, а не постоянно от персональной учетной записи разработчика. Для каждого субъекта владелец должен связать требуемую операцию с минимальной документированной ролью и наиболее узкой поддерживаемой областью назначения. Агент или модельный вывод не являются основанием авторизации: решение принимает IAM или бэкенд, располагающий проверенной идентичностью пользователя.

{#ai-iam-leastpriv1-implementation}

**Реализация**

При проверке учитываются прямые, групповые и унаследованные привязки. Принципы ресурсной и ролевой модели описаны в [документации IAM](../../iam/concepts/access-control/index.md).

Если организация использует [политики авторизации IAM](../../iam/concepts/access-control/access-policies.md), эта функция Preview доступна по запросу и дополняет роли явными запретами.

Модуль диагностики доступов CIEM (Cloud Infrastructure Entitlement Management) в составе [Yandex Security Deck](../../security-deck/index.md) целиком находится на стадии Preview и используется только после подтверждения доступности. Он показывает назначенные доступы, включая прямые и полученные через группы, но не определяет за организацию, какое право является избыточным.

Для просмотра требуется `organization-manager.viewer` на организацию или более широкая документированная роль. Подробнее в описании [CIEM](../../security-deck/concepts/ciem.md) и инструкции [Просмотреть список доступов субъекта](../../security-deck/operations/ciem/view-permissions.md). [Отзыв доступа](../../security-deck/operations/ciem/revoke-permissions.md) имеет дополнительные ограничения по ролям и типам групп и не считается доступным только потому, что доступен просмотр.

Сервисный аккаунт среды исполнения отделяется от идентичности развертывания и от администратора. Фактический минимум прав подтверждается контролируемым тестом, а не только сопоставлением с примерами документации.

{#ai-iam-leastpriv1-check}

**Проверка**

1. Для каждого продуктивного субъекта выгрузите эффективные прямые и унаследованные права на облаке, каталогах и целевых ресурсах.
1. Сопоставьте каждую роль с операцией.
1. Для Kubernetes дополнительно проверьте `RoleBinding` и `ClusterRoleBinding`.
1. Для ключевой рабочей идентичности выполните разрешенную операцию и соседнюю запрещенную операцию создания, удаления или чтения другого ресурса: последняя должна завершиться отказом.

Неиспользуемая, широкая или необоснованная роль должна быть удалена либо оформлена как исключение.

{#ai-iam-leastpriv1-artifacts}

**Артефакт**

* Эффективные прямые и унаследованные права.
* Сопоставление роли с операцией.
* Матрица `субъект → операция → ресурс → роль или область действия → уровень привязки`.
* Маскированные области действия ключей.

### Вызов AI Studio использует документированный способ аутентификации {#ai-studio-call-uses-documented-auth}

{#ai-iam4-id}

Идентификатор требования: `AI-IAM4`

{#ai-iam4-requirement}

**Требование**

Клиент AI Studio должен использовать IAM-токен или API-ключ сервисного аккаунта и роль, соответствующую выбранному API. Для генерации текста документирована роль `ai.languageModels.user`; для Responses API — `ai.assistants.editor` вместе с `ai.languageModels.user`; для Realtime API — `ai.models.user`. Эти роли нельзя переносить на другой API без проверки его документации. Заголовки и минимальные роли приведены в [описании аутентификации AI Studio](https://aistudio.yandex.ru/docs/ru/ai-studio/api-ref/authentication.html).

API-ключ должен иметь явно выбранные области действия и ограниченный срок либо утвержденный период пересмотра. Конкретную область следует выбирать по документации вызываемого API и текущему списку, а не закреплять одну область для всех моделей. Управление ключами и поведение областей действия описаны в [документации IAM](../../iam/operations/authentication/manage-api-keys.md).

Если API поддерживает IAM-токен, короткоживущий токен предпочтителен.

Для поиска Vector Store требуется область `yc.ai.foundationModels.execute`; ее нельзя заменять областью `yc.ai.languageModels.execute` или иной похожей.

{#ai-iam4-implementation}

**Реализация**

Области действия конкретного API-ключа проверяются через консоль управления или API с выводом метаданных ключа. Документированный способ просмотра областей уточняется в актуальной версии [CLI-справочника IAM](../../iam/operations/authentication/manage-api-keys.md) или интерфейса управления.

{#ai-iam4-check}

**Проверка**

```bash
yc iam api-key list --service-account-name <имя_сервисного_аккаунта>
```

1. Сопоставьте метаданные каждого ключа с владельцем, вызываемым API, выбранными областями и сроком.
1. Просмотрите актуальные области через консоль управления или API, при необходимости — командой `yc iam api-key get`.

Не выводите значение секрета в отчет проверки. Разрешенный вызов должен пройти, а вызов семейства API вне выбранных областей и вызов с просроченным или отозванным ключом должны завершиться отказом.

{#ai-iam4-artifacts}

**Артефакт**

* Метаданные ключа без значения.
* Сопоставление с владельцем и API.
* Привязки сервисного аккаунта.
* Жизненный цикл ключа в Audit Trails.
* Результаты разрешенного и запрещенного вызовов.

### Эффективные права пересматриваются по расписанию и после изменений {#effective-rights-reviewed-on-schedule-and-change}

{#ai-iam5-id}

Идентификатор требования: `AI-IAM5`

{#ai-iam5-requirement}

**Требование**

Для продуктивных идентичностей владелец доступа должен установить периодичность пересмотра в политике организации и проводить внеплановый пересмотр после существенного изменения архитектуры, обязанностей, состава групп, внешних интеграций или способа делегирования.

В область пересмотра входят прямые назначения, членство в группах и унаследованные права; проверка только списка прямых привязок неполна. В охват включаются привязки уровня организации, облака, каталога и ресурса, области действия API-ключей и внутренний RBAC выбранного хранилища или среды исполнения, например Kubernetes или Managed Service for OpenSearch.

Результат должен содержать дату, охваченных субъектов и ресурсы, проверяющего, решение по каждому избыточному или неподтвержденному праву и действующие исключения. Пересмотр должен выявлять примитивные или чрезмерно широкие роли, назначения выше необходимой ресурсной области и возможности, которые субъект фактически не использует для утвержденной операции. CIEM можно использовать для просмотра назначенных доступов в пределах его документации; решение о необходимости права остается политикой организации.

Недоступность CIEM является условием ветви, а не результатом `N/A` для контроля: в этом случае сохраняются выгрузки IAM и раскрытое членство в группах как ручные свидетельства.

{#ai-iam5-check}

**Проверка**

1. Выберите рабочую идентичность, пользователя с групповым доступом и субъект с унаследованной ролью.
1. Сопоставьте текущее эффективное состояние с последней датированной записью пересмотра и с изменениями после нее.

Просроченный пересмотр, неохваченная ветвь наследования или право без решения означает невыполнение. Неиспользуемое, бесхозное или общее право и чрезмерно широкая роль являются находками; удаление права подтверждается повторным отрицательным тестом.

{#ai-iam5-artifacts}

**Артефакт**

* Датированная запись пересмотра.
* Решения по избыточным правам.
* Происхождение прав.
* Срок исключения.
* Повторный отрицательный тест.

### Учетные записи привилегированных пользователей используют MFA {#privileged-users-use-mfa}

{#ai-iam-mfa1-id}

Идентификатор требования: `AI-IAM-MFA1`

{#ai-iam-mfa1-applicability}

**Применимость**

Требование применяется к пользователям, которые имеют административные права на ресурсы ИИ-системы в Yandex Cloud напрямую или через группу. В охват входят роли, позволяющие управлять доступом, секретами, AI Studio, DataSphere, средой исполнения, сетями, хранилищами, журналами и другими ресурсами, используемыми ИИ-системой.

{#ai-iam-mfa1-requirement}

**Требование**

Для каждого привилегированного пользователя должна быть включена многофакторная аутентификация (MFA). MFA должна действовать до назначения привилегированной роли и сохраняться в течение всего срока действия доступа.

Для локальных и федеративных пользователей Yandex Identity Hub MFA настраивается в Yandex Identity Hub. Для пользователей внешней федерации должно быть подтверждено, что MFA включена и применяется поставщиком идентичности к пользователю или группе, которым назначены роли в Yandex Cloud.

Сервисные аккаунты, API-ключи, статические ключи и другие технические учетные данные не заменяют MFA для человека, который управляет доступом или ресурсами ИИ-системы.

{#ai-iam-mfa1-implementation}

**Реализация**

Владелец доступа определяет привилегированные роли и группы, используемые в ИИ-системе, и сопоставляет их с пользователями. Проверяются назначения ролей на уровне организации, облака, каталога и ресурса, включая прямые назначения и назначения группам.

Минимально проверяются широкие роли `admin` и `editor`, а также административные роли IAM, Yandex Identity Hub, Lockbox, Audit Trails, AI Studio, DataSphere, Managed Service for Kubernetes, Serverless, Compute Cloud, VPC, Object Storage, Container Registry, YDB и OpenSearch — если соответствующие сервисы входят в архитектуру ИИ-системы.

Исключение допускается только для конкретного пользователя, роли и ресурса, должно иметь обоснование и срок действия. Исключение для группы или федерации целиком не допускается.

{#ai-iam-mfa1-check}

**Проверка**

1. Получите список привязок ролей на уровне организации, облаков, каталогов и критичных ресурсов ИИ-системы.
1. Раскройте группы до отдельных пользователей и определите пользователей с привилегированными ролями.
1. Для каждого такого пользователя проверьте состояние MFA в Yandex Identity Hub или в используемом внешнем поставщике идентичности.

Требование выполнено, если у каждого привилегированного пользователя включена MFA либо имеется действующее документированное исключение.

После исправления несоответствия повторно подтвердите включение MFA или отзыв привилегированной роли.

{#ai-iam-mfa1-artifacts}

**Артефакт**

* Перечень привилегированных ролей и групп.
* Выгрузка привязок ролей.
* Список пользователей, получающих права через группы.
* Подтверждение MFA в Yandex Identity Hub или внешнем поставщике идентичности (IdP).
* Реестр исключений с пользователем, ролью, ресурсом, основанием и сроком.
* Повторная выгрузка после исправления.

### Обходные административные каналы среды исполнения отключены по умолчанию {#runtime-administrative-bypass-channels-disabled}

{#ai-infra-console1-id}

Идентификатор требования: `AI-INFRA-CONSOLE1`

{#ai-infra-console1-applicability}

**Применимость**

Требование применяется к виртуальным машинам Yandex Compute Cloud, используемым в среде исполнения, загрузки, администрирования, RAG-хранилище, агентном бэкенде, MCP-инструментах, телеметрии или иных компонентах ИИ-системы.

{#ai-infra-console1-requirement}

**Требование**

Доступ к серийной консоли (`serial console`) для ВМ ИИ-системы должен быть отключен. Серийная консоль не должна использоваться как штатный способ администрирования продуктивных ВМ.

Штатный административный доступ должен выполняться через утвержденный способ, например OS Login по SSH. Доступ должен быть персонализированным, ограниченным ролями IAM и журналируемым.

Включение серийной консоли допускается только для устранения аварии или выполнения согласованных технических работ. Для каждого включения должны быть указаны ВМ, причина, ответственный, срок действия и согласование. После завершения работ серийная консоль должна быть отключена.

{#ai-infra-console1-implementation}

**Реализация**

Для каждой ВМ из состава ИИ-системы фиксируются:

* состояние опции доступа к серийной консоли;
* утвержденный способ административного доступа;
* пользователи или группы, имеющие права OS Login;
* источник журналов административных действий.

Для ВМ с Linux рекомендуется использовать OS Login с ролями `compute.osLogin` или `compute.osAdminLogin` вместо постоянных SSH-ключей на ВМ. Если OS Login технически не используется, должен быть документирован другой утвержденный способ персонализированного и журналируемого доступа.

Настройка OS Login, SSH-доступа, сервисного аккаунта ВМ и доступа к метаданным проверяется отдельно от настройки серийной консоли. Наличие минимальных ролей IAM не означает, что серийная консоль отключена.

{#ai-infra-console1-check}

**Проверка**

1. Проверьте для каждой ВМ из состава ИИ-системы, что доступ к серийной консоли выключен в настройках ВМ.
1. Если серийная консоль включена, проверьте наличие действующего исключения с указанием ВМ, причины, владельца, согласования и срока.
1. После завершения аварийных работ подтвердите отключение серийной консоли повторной проверкой конфигурации ВМ.

ВМ с включенной серийной консолью без действующего исключения считается несоответствием.

{#ai-infra-console1-artifacts}

**Артефакт**

* Выгрузка или скриншот конфигурации ВМ с состоянием доступа к серийной консоли.
* Перечень ВМ ИИ-системы.
* Утвержденный способ административного доступа.
* Перечень ролей OS Login или иной механизм доступа.
* Заявка на временное включение серийной консоли при наличии.
* Подтверждение ее отключения после завершения работ.

## Хранилища и криптографическая защита {#storage-crypto}

### Хранилища моделей и данных не имеют неучтенного публичного доступа {#model-data-stores-no-unaccounted-public-access}

{#ai-net5-id}

Идентификатор требования: `AI-NET5`

{#ai-net5-requirement}

**Требование**

Для каждого бакета, базы, индекса, диска и реестра владелец должен зафиксировать точный идентификатор, операции чтения и изменения, субъектов, сетевой путь, режим шифрования или ссылку на `AI-CRYPT1` и необходимость публичного доступа. По умолчанию модельные артефакты, обучающие данные, RAG-документы и журналы не должны быть общедоступными. Исключение для публикации должно описывать точный объект и назначение.

{#ai-net5-implementation}

**Реализация**

Для Object Storage необходимо проверить IAM, ACL и политику доступа в соответствии с [моделью доступа сервиса](../../storage/security/index.md).

Для [Managed Service for OpenSearch](../../managed-opensearch/index.md) и [YDB](../../ydb/index.md) роли на ресурс Yandex Cloud не следует считать авторизацией приложения; такая авторизация проектируется отдельно.

Для Vector Store проверяются роли AI Studio, область действия API-ключа и авторизация приложения; документированный способ отключения публичного сетевого пути [AI Search](https://aistudio.yandex.ru/docs/ru/ai-studio/concepts/search/) не заявляется, и несуществующий частный эндпоинт сервису не присваивается.

{#ai-net5-check}

**Проверка**

1. Проверьте эффективные привязки, ACL, политики и сетевую доступность каждого хранилища.
1. Выполните чтение от разрешенного и неразрешенного тестового субъекта.

Отрицательный результат должен относиться к фактическому пути приложения, а не только к консоли управления. В набор входят чтение без аутентификации и чтение субъектом другого арендатора; при обнаружении широкого доступа раскрытые учетные данные заменяются.

{#ai-net5-artifacts}

**Артефакт**

* Эффективные привязки.
* ACL.
* Тест чтения от разрешенного и неразрешенного субъекта.
* Конфигурация публичного доступа и сети.

### Шифрование выбирается по возможностям конкретного сервиса {#encryption-chosen-by-service-capabilities}

{#ai-crypt1-id}

Идентификатор требования: `AI-CRYPT1`

{#ai-crypt1-requirement}

**Требование**

Данные, модельные артефакты, индексы, диски и резервные копии должны использовать документированный для выбранного сервиса режим шифрования при хранении и защищенный протокол при передаче. Если организация требует собственный ключ Yandex Key Management Service, она должна подтвердить, что конкретный ресурс поддерживает такой режим, и проверить права на ключ, жизненный цикл и последствия блокирования или удаления.

{#ai-crypt1-implementation}

**Реализация**

Object Storage поддерживает документированные режимы [серверного шифрования](../../storage/concepts/encryption.md).

Для дисков, образов и снимков Compute Cloud KMS-шифрование выбирается при создании и имеет отдельные ограничения, описанные в [документации Compute Cloud](../../compute/concepts/encryption.md).

Эти свойства нельзя автоматически переносить на AI Search, OpenSearch, YDB или внешний сервис. Рекомендуется вести матрицу `актив → точный ресурс → поддерживаемый режим или ключ KMS → требуемый субъект и роль → проверка чтения`: для Object Storage — режим серверного шифрования и при необходимости пользовательский ключ KMS, для Compute Cloud — ключ диска, образа или снимка и право `kms.keys.user`, для Managed Service for OpenSearch — пользовательский ключ при документированных предусловиях; [Yandex Lockbox](../../lockbox/index.md) использует KMS внутри сервиса.

Для AI Search и Vector Store управление пользовательским ключом KMS не документировано и не заявляется. Шифрование не заменяет авторизацию и анонимизацию.

{#ai-crypt1-check}

**Проверка**

1. Для каждого хранилища зафиксируйте режим шифрования, ключ при его использовании, субъекты с правом использования ключа.
1. Выполните чтение разрешенного объекта штатной средой исполнения и отказ чтения для субъекта без нужного права на ключ или объект.

Тест с отключенным ключом выполняется только на изолированном непродуктивном ресурсе; последний пригодный ключ не отключается и не удаляется, а изменение ключей выполняется по плану восстановления.

{#ai-crypt1-artifacts}

**Артефакт**

* Конфигурация шифрования.
* Разрешенное чтение и отказ без права.
* Идентификатор и привязки ключа.
* Репетиция восстановления.

## Секреты {#secrets}

### Секрет имеет владельца и управляемый жизненный цикл {#secret-has-owner-managed-lifecycle}

{#ai-secret1-id}

Идентификатор требования: `AI-SECRET1`

{#ai-secret1-requirement}

**Требование**

API-ключи, токены внешних провайдеров, пароли и иные секреты должны храниться в специализированном хранилище и иметь владельца, идентификатор секрета и версии, назначение, разрешенных потребителей, точную роль и область доступа, способ доставки, срок или период пересмотра, порядок замены и отзыва. Значения не должны храниться в исходном коде, истории сборки, образе, датасете, системном промпте, открытой переменной конфигурации, журнале или свидетельстве проверки.

{#ai-secret1-implementation}

**Реализация**

Для поддерживаемых сред рекомендуется доставлять секрет из Lockbox рабочему сервисному аккаунту с ролью `lockbox.payloadViewer` на конкретный секрет. Для KMS-зашифрованного секрета дополнительно требуется документированное право на ключ. Способ зависит от среды:

* [Cloud Functions](../../functions/operations/function/lockbox-secret-transmit.md) получает ссылку на секрет в конфигурации функции; интеграция находится на стадии Preview;
* [Serverless Containers](../../lockbox/operations/serverless/containers.md) использует интеграцию на стадии Preview;
* [Managed Service for Kubernetes](../../managed-kubernetes/tutorials/kubernetes-lockbox-secrets.md) использует External Secrets Operator;
* в [Compute Cloud](../../compute/operations/vm-create/create-with-lockbox-secret.md) приложение получает секрет через API по идентификатору, а значение нельзя помещать в незашифрованный `user-data`.

Для DataSphere задание читает секрет через API с токеном сервисного агента по документированной инструкции; для Kubernetes вместо External Secrets Operator допустим путь с Workload Identity и обращением приложения по API. Lockbox не требуется безусловно, если политика выбрала иное утвержденное специализированное хранилище; при этом документируется точный путь доставки.

Для каждого секрета выбирается одна ветвь доставки: внедрение значения, чтение через API или материализация Kubernetes `Secret`.

{#ai-secret1-check}

**Проверка**

1. Сопоставьте каждый секрет и его активную версию с потребителями, способом доставки и правами.
1. Просмотрите код, историю сборки, образ, параметры развертывания, конфигурацию IaC, переменные ресурса, данные и выборку журналов на наличие значения или синтетического маркера секрета.
1. Отзовите тестовую версию и убедитесь, что доступ прекращается с учетом документированного кеширования среды; затем проверьте замену без раскрытия значения.

{#ai-secret1-artifacts}

**Артефакт**

* Сопоставление секрета с потребителем.
* Тест отзыва и замены.
* Привязки IAM и KMS.
* Событие получения значения в Audit Trails.
* Запись о ротации.

## Аудит и содержимое журналов {#audit-logs}

### Для каждой существенной операции указан источник события {#material-operation-has-event-source}

{#ai-audit1-id}

Идентификатор требования: `AI-AUDIT1`

{#ai-audit1-requirement}

**Требование**

Владелец системы должен перечислить существенные операции с моделями, ключами, секретами, хранилищами, индексами, MCP Gateway и средой исполнения и указать источник события для каждой операции. Для RAG отдельно сопоставляются создание, загрузка, обновление, удаление и поиск; для Lockbox — управление секретом и получение значения. Audit Trails используется только для событий, опубликованных конкретным сервисом. Операции, которых нет в каталоге облачных событий, должны фиксироваться приложением или самим хранилищем.

Сопоставление ведется в форме карты: `операция → сервис → уровень события (управление, данные, приложение) → точное событие → область и фильтр источника → назначение → поле корреляции`. Формулировка «все операции» не допускается; приложение отдельно добавляет события модельного запроса, поиска, инструмента и эффекта в целевой системе.

{#ai-audit1-implementation}

**Реализация**

При настройке трейла необходимо проверить область ресурсов, выбранные сервисы, события уровня управления и уровня данных, фильтры и назначение. Один трейл имеет одно назначение; подробности приведены в [описании trail](../../audit-trails/concepts/trail.md) и [каталоге событий](../../audit-trails/concepts/events.md). Предустановленный набор не следует считать полным — фактическую конфигурацию проверяют по [инструкции Audit Trails](../../audit-trails/quickstart.md).

Для доступа к значениям и управления секретами используются только события, перечисленные в [справочнике Audit Trails для Lockbox](../../lockbox/at-ref.md). Для AI Search и MCP используются только опубликованные [события AI Studio](https://aistudio.yandex.ru/docs/ru/ai-studio/at-ref.html); отсутствие документированного события поиска закрывается прикладной трассировкой. Наличие трейла без нужной области сервиса и фильтра не подтверждает аудит операции.

{#ai-audit1-check}

**Проверка**

1. Для каждой существенной операции выполните безопасное тестовое действие и найдите соответствующую запись.
1. Зафиксируйте ресурс, субъект, время, тип события и идентификатор корреляции, если он доступен.
1. Если облачное событие не документировано, покажите прикладную запись и ее доставку.
1. Отдельно выполните тест полноты: намеренно пропущенный сервис или фильтр события должен выявлять неполное покрытие, а не давать результат «выполнено».

Событие должно появиться в назначении за ожидаемое время доставки.

{#ai-audit1-artifacts}

**Артефакт**

* Конфигурация трейла.
* Безопасное тестовое действие и найденная запись.
* Карта событий.
* Спецификация трейла.
* Тест отсутствующего события.

### Журналы не собирают чувствительное содержимое без цели {#logs-no-sensitive-content-without-purpose}

{#ai-audit2-id}

Идентификатор требования: `AI-AUDIT2`

{#ai-audit2-requirement}

**Требование**

Схема журналирования должна удалять или преобразовывать секреты, персональные данные, полные промпты, ответы, документы и историю диалога до отправки записи в Yandex Cloud Logging или другое назначение. Хранение такого содержимого допускается только при зафиксированной цели, правовом основании, сроке, круге доступа и способе удаления.

Минимальная прикладная запись содержит идентификаторы запроса, субъекта и ресурса, версию модели и конфигурации, результат политики, вызванный инструмент и технический исход. Журналирование есть у каждой системы; результат `N/A` для этого требования не допускается.

Cloud Logging принимает прикладные записи. Официальная документация не устанавливает универсальное удаление секретов или персональных данных из произвольного содержимого приложения, поэтому схема и редактирование записи остаются частью приложения. Права чтения и записи должны соответствовать [модели доступа Cloud Logging](../../logging/security/index.md), а срок хранения — утвержденной политике и фактической [настройке срока хранения](../../logging/operations/retention-period.md).

{#ai-audit2-check}

**Проверка**

1. Просмотрите выборку успешных, ошибочных и запрещенных запросов.
1. Проверьте отсутствие API-ключей, значений Lockbox и неутвержденного содержимого.
1. Для разрешенного хранения диалогов подтвердите цель, срок, доступ, удаление и связь с правовым решением раздела [Соответствие требованиям и обработка персональных и регулируемых данных](compliance-pii.md).
1. Дополнительно отправьте синтетические маркеры секрета и персональных данных: события должны сохранять корреляцию, но не значения маркеров.
1. Проверьте также привязки читателей журналов.

{#ai-audit2-artifacts}

**Артефакт**

* Схема журналирования.
* Выборка записей.
* Подтверждение цели хранения.
* Тестовые события с синтетическими маркерами.
* Привязки читателей журналов.