Создание трейла для загрузки аудитных логов

1. Создайте лог-группу, в которую будут загружаться аудитные логи.

2. Создайте сервисный аккаунт для трейла.

3. Назначьте роли сервисному аккаунту, чтобы трейл мог собирать и загружать логи:

   • logging.writer на лог-группу.

   • audit-trails.viewer на один из ресурсов, который определяет нужную область сбора логов:

     • Организация — чтобы собирать логи в выбранных облаках организации.
     • Облако — чтобы собирать логи в выбранных каталогах облака.
     • Каталог — чтобы собирать логи в этом каталоге.

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

4. Убедитесь, что у вашего аккаунта есть необходимые роли для создания трейла:

   • audit-trails.editor на каталог, в котором будет находиться трейл.
   • iam.serviceAccounts.user на сервисный аккаунт для трейла.

1. Создайте поток данных, в который будут загружаться аудитные логи.

2. Создайте сервисный аккаунт для трейла.

3. Назначьте роли сервисному аккаунту, чтобы трейл мог собирать и загружать логи:

   • yds.writer на поток данных.

   • audit-trails.viewer на один из ресурсов, который определяет нужную область сбора логов:

     • Организация — чтобы собирать логи в выбранных облаках организации.
     • Облако — чтобы собирать логи в выбранных каталогах облака.
     • Каталог — чтобы собирать логи в этом каталоге.

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

4. Убедитесь, что у вашего аккаунта есть необходимые роли для создания трейла:

   • audit-trails.editor на каталог, в котором будет находиться трейл.
   • iam.serviceAccounts.user на сервисный аккаунт для трейла.

Если у вас еще нет интерфейса командной строки Yandex Cloud, установите и инициализируйте его.

По умолчанию используется каталог, указанный в профиле CLI. Вы можете указать другой каталог с помощью параметра --folder-name или --folder-id.

Трейл можно создать двумя способами:

• Создать YAML-файл, содержащий параметры трейла, и передать этот файл в команду для создания трейла.

  Такой подход упрощает работу с параметрами трейла и снижает вероятность ошибки.

• Передать параметры трейла в аргументах команды для создания трейла.

  Посмотрите описание команды CLI для создания трейла, чтобы получить подробную информацию о доступных аргументах:

  yc audit-trails trail create --help
  

  Совет

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

Чтобы создать трейл, используя YAML-файл:

1. Создайте YAML-файл с конфигурацией трейла:

   name: <имя_трейла>
   folder_id: <идентификатор_каталога>
   destination:
     # Должно быть указано только одно место назначения:
     # object_storage, cloud_logging, data_stream
     # Настройки для всех мест назначения приведены для иллюстрации
     object_storage:
       bucket_id: <имя_бакета>
       object_prefix: <префикс_для_объектов>
     cloud_logging:
       log_group_id: <идентификатор_лог_группы>
     data_stream:
       stream_name: <имя_потока_данных_YDS>
       database_id: <идентификатор_базы_данных_YDS>
   service_account_id: <идентификатор_сервисного_аккаунта>
   filtering_policy:
     management_events_filter:
       resource_scopes:
         - id: <идентификатор_организации_облака_или_каталога>
           type: <тип>
     data_events_filters:
       - service: <имя_сервиса>
         resource_scopes:
           - id: <идентификатор_организации_облака_или_каталога>
             type: <тип>
         # Допустимо указать либо included_events, либо excluded_events,
         # либо не указывать оба этих параметра, чтобы собирались все события сервиса
         # Оба параметра приведены для иллюстрации
         included_events:
           event_types:
             - <эти_события_будут_собираться>
         excluded_events:
           event_types:
             - <эти_события_не_будут_собираться>
   

   Где:

   • name — имя трейла. Оно должно быть уникальным в рамках каталога.

   • folder_id — идентификатор каталога, в котором будет размещен трейл.

   • destination — настройки выбранного места назначения, куда будут загружаться аудитные логи.

     Важно

     Настройки мест назначения — взаимоисключающие. Использование одних настроек делает невозможным использование других.

     • object_storage — загружать логи в бакет Object Storage:

       • bucket_id — имя созданного ранее бакета.

         Имя бакета можно запросить со списком бакетов в каталоге (используется каталог по умолчанию):

         yc storage bucket list
         

       • object_prefix — префикс, который будет присвоен объектам с аудитными логами в бакете. Необязательный параметр, участвует в полном имени файла аудитного лога.

         Примечание

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

     • cloud_logging — загружать логи в лог-группу Cloud Logging.

       В параметре log_group_id укажите идентификатор созданной ранее лог-группы. Идентификатор можно запросить со списком лог-групп в каталоге.

     • data_stream — загружать логи в поток данных Data Streams:

       • stream_name — имя созданного ранее потока данных. Имя можно запросить со списком потоков данных в каталоге.

       • database_id — идентификатор базы данных YDB, которая используется потоком данных Data Streams. Идентификатор можно запросить со списком баз данных YDB в каталоге.

   • service_account_id — идентификатор созданного ранее сервисного аккаунта.

   • filtering_policy — настройки политики фильтрации, которая определяет, какие события будут собираться и попадут в аудитные логи. Политика состоит из набора фильтров, которые относятся к разным уровням событий.

     Важно

     Для политики обязательно должен быть настроен хотя бы один фильтр, иначе не получится создать трейл.

     Доступные фильтры:

     • management_events_filter — фильтр событий уровня конфигурации.

       Укажите область сбора логов в параметре resource_scopes:

       • id — идентификатор организации, облака или каталога.

       • type — тип области согласно указанному идентификатору:

         • organization-manager.organization — организация;
         • resource-manager.cloud — облако;
         • resource-manager.folder — каталог.

       Можно комбинировать в одном параметре resource_scopes несколько областей, которые принадлежат одной организации. Например, собирать логи из одного облака целиком, а из другого — только из определенных каталогов:

       resource_scopes:
         # Сбор логов из облака 1 целиком
         - id: <идентификатор_облака_1>
           type: resource-manager.cloud
         # Сбор логов из каталога 1 облака 2
         - id: <идентификатор_каталога_1>
           type: resource-manager.folder
         # Сбор логов из каталога 2 облака 2
         - id: <идентификатор_каталога_2>
           type: resource-manager.folder
       

       Права сервисного аккаунта должны позволять сбор логов из указанных областей.

     • data_events_filters — фильтры событий уровня сервисов. Можно настроить несколько фильтров такого типа — по одному для каждого сервиса.

       Фильтр для одного сервиса имеет следующую структуру:

       • service — имя сервиса. Его можно получить в справочнике событий уровня сервисов.

       • resource_scopes — места, откуда собирать события уровня сервисов. Этот параметр настраивается аналогично фильтру событий уровня конфигурации.

       • *_events — фильтры событий уровня сервиса:

         • included_events.event_types — собирать только указанные события.
         • excluded_events.event_types — собирать все события, кроме указанных.

         Перечень событий можно получить в справочнике событий уровня сервисов.

         Важно

         Эти фильтры — взаимоисключающие:

         • либо настройте только included_events;
         • либо настройте только excluded_events.

         Если не настроить ни один фильтр, то будут собираться все события.

2. Выполните команду:

   yc audit-trails trail create --file <путь_к_файлу>
   

Terraform позволяет быстро создать облачную инфраструктуру в Yandex Cloud и управлять ею с помощью файлов конфигураций. В файлах конфигураций хранится описание инфраструктуры на языке HCL (HashiCorp Configuration Language). При изменении файлов конфигураций Terraform автоматически определяет, какая часть вашей конфигурации уже развернута, что следует добавить или удалить.

Terraform распространяется под лицензией Business Source License, а провайдер Yandex Cloud для Terraform — под лицензией MPL-2.0.

Подробную информацию о ресурсах провайдера смотрите в документации на сайте Terraform или в зеркале.

Если у вас еще нет Terraform, установите его и настройте провайдер Yandex Cloud.

1. Опишите в конфигурационном файле параметры трейла, который будет собирать аудитные логи:

   resource "yandex_audit_trails_trail" "basic_trail" {
     name = "<имя_трейла>"
     folder_id   = "<идентификатор_каталога>"
     description = "<описание_трейла>"
     
     labels = {
       key = "value"
     }
     
     service_account_id = "<идентификатор_сервисного_аккаунта>"
     
     logging_destination {
       log_group_id = "<идентификатор_лог-группы>"
     }
     
     filter {
       path_filter {
         some_filter {
           resource_id   = "<идентификатор_организации>"
           resource_type = "<тип_родительского_ресурса>"
           any_filters {
               resource_id   = "<идентификатор_облака_1>"
               resource_type = "<тип_дочернего_ресурса>"
           }
           any_filters {
               resource_id   = "<идентификатор_облака_2>"
               resource_type = "<тип_дочернего_ресурса>"
           }
         }
       }
       event_filters {
         service = "<идентификатор_сервиса_1>"
         categories {
           plane = "DATA_PLANE"
           type  = "<тип_действия>"
         }
         path_filter {
           any_filter {
             resource_id = "<идентификатор_организации>"
             resource_type = "<тип_ресурса>"
           }
         }
       }
       event_filters {
         service = "<идентификатор_сервиса_2>"
         categories {
           plane = "DATA_PLANE"
           type  = "<тип_действия>"
         }
         path_filter {
           any_filter {
             resource_id = "<идентификатор_организации>"
             resource_type = "<тип_ресурса>"
           }
         }
       }
     }
   }
   

   Где:

   • name — имя создаваемого трейла. Требования к формату имени:

     • длина — от 2 до 63 символов;
     • может содержать строчные буквы латинского алфавита, цифры и дефисы;
     • первый символ — буква, последний — не дефис.

   • folder_id — идентификатор каталога, в котором создается трейл.

   • description — описание трейла, которое позволит отличать его от других трейлов. Например My very first trail. Необязательный параметр.

   • labels — список меток в формате ключ=значение. Необязательный параметр.

   • service_account_id — идентификатор сервисного аккаунта, от имени которого трейл будет загружать файлы аудитного лога в бакет.

     В зависимости от области сбора аудитных логов, сервисному аккаунту должна быть назначена роль audit-trails.viewer на организацию, облако или каталог, в которых трейл будет собирать аудитные логи.

   • log_group_id — идентификатор лог-группы, в которую трейл будет сохранять аудитные логи.
   • filter — структура, описывающая обработку событий трейлом. Содержит объекты path_filter и event_filters.

     • path_filter — структура, описывающая обработку трейлом событий уровня конфигурации (Control Plane). Может содержать один объект some_filter или один объект any_filter. Если в конфигурации отсутствует объект path_filter, трейл не будет обрабатывать события Control Plane.

       • some_filter — структура, описывающая ресурсы, для которых будут собираться аудитные логи. В зависимости от области сбора аудитных логов позволяет настроить обработку событий в отдельных облаках организации или каталогах облака, к которым относится трейл.

         • resource_id — идентификатор родительского ресурса, которому принадлежит создаваемый трейл и для ресурсов которого будут собираться аудитные логи. В зависимости от области сбора аудитных логов укажите в этом параметре идентификатор организации или идентификатор облака, к которому относится трейл.

         • resource_type — тип родительского ресурса Yandex Cloud, в котором создается трейл. В зависимости от области сбора аудитных логов укажите в этом параметре значение organization-manager.organization или resource-manager.cloud.

         • any_filters — структура, описывающая один дочерний ресурс, в котором будут собираться аудитные логи. Чтобы указать несколько дочерних ресурсов, задайте параметр any_filters необходимое количество раз. В зависимости от области сбора аудитных логов, указывайте в этом параметре информацию об облаках или каталогах, в которых трейл будет обрабатывать события:

           • resource_id — идентификатор дочернего ресурса. В зависимости от области сбора аудитных логов укажите идентификатор облака или каталога, в котором трейл будет собирать аудитные логи.
           • resource_type — тип дочернего ресурса. В зависимости от области сбора аудитных логов укажите в этом параметре значение resource-manager.cloud или resource-manager.folder.

         Чтобы задать текущий каталог в качестве области сбора аудитных логов, вместо параметра some_filter используйте параметр any_filter.

         Использование параметра some_filter исключает использование параметра any_filter.

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

         • resource_id — идентификатор ресурса, которому принадлежит создаваемый трейл и для ресурсов которого будут собираться аудитные логи. В зависимости от области сбора аудитных логов укажите в этом параметре идентификатор организации, облака или каталога.
         • resource_type — тип ресурса Yandex Cloud. В зависимости от области сбора аудитных логов задайте значение organization-manager.organization, resource-manager.cloud или resource-manager.folder.

     • event_filters — структура, описывающая обработку трейлом событий уровня сервисов (Data Plane). Если в конфигурации отсутствует объект event_filters, трейл не будет обрабатывать события Data Plane. В одном блоке event_filters настраивается обработка аудитных логов Data Plane для одного сервиса Yandex Cloud. Чтобы настроить обработку трейлом событий Data Plane для нескольких сервисов, укажите в конфигурации параметр event_filters необходимое количество раз.

       • service — идентификатор сервиса, в котором трейл будет обрабатывать события.
         Возможные значения:

         • dns;
         • kms;
         • lockbox;
         • mdb.mongodb;
         • mdb.mysql;
         • mdb.postgresql;
         • storage.

       • categories — структура, описывающая тип собираемых событий.

         • plane — уровень событий. Для событий уровня сервисов указывайте значение DATA_PLANE.
         • type — тип действия события в ресурсе. Возможные значения: READ и WRITE.

       • path_filter — структура, описывающая обработку трейлом событий уровня сервисов (Data Plane). Может содержать один объект some_filter или один объект any_filter.

         • some_filter — структура, описывающая ресурсы, для которых будут собираться аудитные логи. В зависимости от области сбора аудитных логов позволяет настроить обработку событий в отдельных облаках организации или каталогах облака, к которым относится трейл.

           • resource_id — идентификатор родительского ресурса, которому принадлежит создаваемый трейл и для ресурсов которого будут собираться аудитные логи. В зависимости от области сбора аудитных логов укажите в этом параметре идентификатор организации или идентификатор облака, к которому относится трейл.

           • resource_type — тип родительского ресурса Yandex Cloud, в котором создается трейл. В зависимости от области сбора аудитных логов укажите в этом параметре значение organization-manager.organization или resource-manager.cloud.

           • any_filters — структура, описывающая один дочерний ресурс, в котором будут собираться аудитные логи. Чтобы указать несколько дочерних ресурсов, задайте параметр any_filters необходимое количество раз. В зависимости от области сбора аудитных логов, указывайте в этом параметре информацию об облаках или каталогах, в которых трейл будет обрабатывать события:

             • resource_id — идентификатор дочернего ресурса. В зависимости от области сбора аудитных логов укажите идентификатор облака или каталога, в котором трейл будет собирать аудитные логи.
             • resource_type — тип дочернего ресурса. В зависимости от области сбора аудитных логов укажите в этом параметре значение resource-manager.cloud или resource-manager.folder.

           Чтобы задать текущий каталог в качестве области сбора аудитных логов, вместо параметра some_filter используйте параметр any_filter.

           Использование параметра some_filter исключает использование параметра any_filter.

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

           • resource_id — идентификатор ресурса, которому принадлежит создаваемый трейл и для ресурсов которого будут собираться аудитные логи. В зависимости от области сбора аудитных логов укажите в этом параметре идентификатор организации, облака или каталога.
           • resource_type — тип ресурса Yandex Cloud. В зависимости от области сбора аудитных логов задайте значение organization-manager.organization, resource-manager.cloud или resource-manager.folder.

   Более подробную информацию о параметрах ресурса yandex_audit_trails_trail в Terraform см. в документации провайдера.

2. Создайте ресурсы:

   1. В терминале перейдите в папку, где вы отредактировали конфигурационный файл.

   2. Проверьте корректность конфигурационного файла с помощью команды:

      terraform validate
      

      Если конфигурация является корректной, появится сообщение:

      Success! The configuration is valid.
      

   3. Выполните команду:

      terraform plan
      

      В терминале будет выведен список ресурсов с параметрами. На этом этапе изменения не будут внесены. Если в конфигурации есть ошибки, Terraform на них укажет.

   4. Примените изменения конфигурации:

      terraform apply
      

   5. Подтвердите изменения: введите в терминале слово yes и нажмите Enter.

   Terraform создаст все требуемые ресурсы. Проверить появление ресурсов и их настройки можно в консоли управления или с помощью команды CLI:

   yc audit-trails trail get <имя_трейла>
   

Воспользуйтесь методом REST API create для ресурса Trail или вызовом gRPC API TrailService/Create.