У Яндекса есть публичная страница с 18 техническими мерами защиты Яндекс 360, и у части пунктов рядом с текстом стоит вкладка, где написано, каким методом API и с каким правом доступа эту меру проверить. Я прошёл её построчно и посчитал: вкладка «Проверка через API» есть у 10 пунктов из 18, вкладка «Настройка через API» — у 5.
Александр Жогов, основатель и руководитель компании +Альянс. И справка, и референс API открыты: весь счёт повторяется поиском по двум строкам в машинной выгрузке страницы, методику показываю целиком.
Сначала про саму страницу, она того стоит
Адрес: https://yandex.ru/support/yandex-360/business/admin/ru/security/security-recommendations
Страница описывает себя так: «На этой странице мы собрали рекомендации по техническим мерам защиты в Яндекс 360. Они помогут повысить безопасность вашей организации. Рекомендации сопровождаются ссылками на API и решения по настройке». Адресат назван прямо: «Рекомендации предназначены для администраторов и специалистов по ИБ».
Слова «чек‑лист» на странице нет ни разу. По функции это он: отдельным разделом лежит PDF с просьбой «Скачайте и распечатайте его. По мере выполнения рекомендаций отмечайте пункты из этого списка» (https://doc-static.yandex.net/support/business/ru/files/security-recommendations.pdf).
Перед пунктами стоит блок требований к читателю: «у вас есть необходимые права доступа к API Яндекс 360; вы знакомы с документацией API; у вас есть доступ к аудит‑логам». И там же фраза, из которой выросла вся эта статья: «Вы можете автоматизировать аудит с помощью скриптов, использующих API».
Моя оценка, сразу и без обиняков: публичный список мер защиты, где у пункта стоит конкретное право доступа и конкретное имя метода вместо общих формулировок, — редкость, и открыть эту страницу администратору полезнее, чем прочитать мой разбор.
Все сверки — 1 сентября 2026 года. Даты последнего обновления и номера редакции страница не публикует, так что, если ваши числа не сойдутся с моими, скорее всего, страница успела измениться.
Как я считал и как пересчитать за мной
Считать вкладки по HTML — мучение. У раздела справки есть машинный экспорт: та же страница отдаётся в markdown по тому же адресу с расширением .md.
Считал я тремя способами:
Выгрузка раздела справки в markdown, снятая 31 августа 2026 года.
Живая страница, открытая 1 сентября 2026 года.
Поиск по дословным меткам в той же выгрузке: строки «Проверка через API», “Настройка через API” и заголовки блоков и пунктов.
Числа сошлись во всех трёх подходах. Заголовков пунктов внутри страницы 18, они разложены по 6 блокам. Метка «Проверка через API» встречается 10 раз, метка «Настройка через API» — 5 раз. Строка «резервное копирование» встречается один раз на всю страницу.
Карта всех 18 пунктов: чем какой из них проверяется
Названия пунктов — дословно со страницы. Третья колонка — метка способа. «API» стоит там, где у пункта есть вкладка «Проверка через API», “API, и настройка” — там, где есть и вторая вкладка, «Настройка через API». «Кабинет» значит вкладку проверки в кабинете организации, «Только инструкция» — что вкладок нет вовсе, есть только ссылка на инструкцию по настройке. «Способа нет» читается буквально: ни вкладки, ни ссылки, один текст.
№ | Пункт (дословно) | Как проверить |
|---|---|---|
Блок 1. Аутентификация и управление доступом | ||
1 | «Минимальное количество администраторов организации» | Кабинет |
2 | «Запрет на использование одного аккаунта администратора несколькими сотрудниками» | Способа нет |
3 | «Использование второго фактора для доменных пользователей и пользователей Яндекс ID» | API |
4 | «Включенная парольная политика организации» | API, и настройка |
5 | «Наличие средств восстановления для учетной записи владельца организации» | API, и настройка |
Блок 2. Безопасность сессий и cookies | ||
6 | «Ограничение времени жизни cookie» | API, и настройка |
Блок 3. Мониторинг и аудит | ||
7 | «Блокировка неактивных пользователей организации» | API |
8 | «Настройка мониторинга событий аудит‑лога» | Кабинет |
Блок 4. Шифрование и защита данных | ||
9 | «Привязка номера телефона для каждого доменного пользователя» | API |
10 | «Настройка существующей DLP‑системы» | API |
Блок 5. Защита корпоративной почты | ||
11 | «Настройка DKIM‑подписи» | Только инструкция |
12 | «Настройка SPF‑записи» | Только инструкция |
13 | «Ограничение на получение нежелательных писем» | Только инструкция |
Блок 6. Интеграции и сторонние сервисы | ||
14 | «Запрет на использование портальных учетных записей» | API |
15 | «Использование SSO» | Только инструкция |
16 | «Синхронизация пользователей из Active Directory» | Только инструкция |
17 | «Установка запрета на аутентификацию во внешних сервисах» | API, и настройка |
18 | «Установка запрета на подключение сервисных приложений» | API, и настройка |
Выходит 10 пунктов через API, 2 глазами в кабинете организации, 5 только со ссылкой на инструкцию по настройке и 1 вообще без способа подтвердить выполнение.
Что подставить в скрипт: право, запрос, поле в ответе
Вторая таблица собрана по тем десяти пунктам, где вкладка «Проверка через API» есть; нумерация та же, что в карте, поэтому в первой колонке пропуски. В колонке «Право» стоят все права пункта, включая право на запись, если настройка через API у него есть; у п. 3 право на запись требует сама справка — из‑за метода Domain2FAService_Disable. В колонке «Запрос» только чтение: методы записи с путями и телами запросов идут следующим разделом.
Хост у методов из раздела ref документации API360 один, https://api360.yandex.net, поэтому в ячейках оставлены только пути; страницы этих методов открываются по шаблону yandex.ru/dev/api360/doc/ru/ref/<Сервис>/<Метод>.
Сами пути в ячейках сокращены до хвоста, иначе таблица расползается по ширине. У методов сервисов Domain2FAService, DomainPasswordsService, DomainSessionsService, OauthAccessRestrictionsService и ServiceApplicationsService путь начинается с /security/v1/org/{orgId}/, у UserService — с /directory/v1/org/{orgId}/, у RoutingService — с /admin/v1/org/{orgId}/. То есть GET .../domain_2fa читается как GET /security/v1/org/{orgId}/domain_2fa, а GET .../users/{userId}/2fa как GET /directory/v1/org/{orgId}/users/{userId}/2fa.
Аудит‑лог выпадает из этих шаблонов трижды. Документация метода get-logs лежит по своему адресу: https://yandex.ru/dev/api360/doc/ru/audit-logs/get-logs. Путь у него тоже свой, целиком: /v1/auditlog/organizations/{org_id}/events. И хост другой — на 20 августа 2026 года на странице метода стоял cloud-api.yandex.net. Не склеивайте адрес из таблицы и общего хоста, берите его со страницы метода целиком.
№ | Право | Запрос | Ждём в ответе |
|---|---|---|---|
3 |
|
|
|
4 |
|
|
|
5 |
|
|
|
6 |
|
|
|
7 |
|
|
|
9 |
|
|
|
10 |
|
| Справка называет |
14 |
|
|
|
17 |
|
|
|
18 |
|
| Массив |
У пунктов 5 и 9 рядом с API‑вкладкой стоит ещё и кабинетная: у средств восстановления владельца это «Проверка в личном кабинете Яндекс ID», у привязки телефона — кабинет организации и страница id.yandex.ru/security/phones.
У пункта 3 в справке указан ещё один метод, Domain2FAService_Disable. Его я вынес в отдельный раздел ниже, вместе с двумя другими местами, где я лазил в референс.
Пять пунктов, которые скрипт может привести в норму сам
Из десяти API‑проверяемых вкладка «Настройка через API» есть у пяти: парольная политика, средства восстановления у владельца организации, время жизни cookie, запрет внешней аутентификации, запрет сервисных приложений. Что для них есть на запись:
П. 4,
DomainPasswordsService_Update, PUT на/security/v1/org/{orgId}/domain_passwords. В телеenabledиchangeFrequency, причём «в запросе необходимо указать хотя бы один параметр».П. 6,
DomainSessionsService_Update, POST на/security/v1/org/{orgId}/domain_sessions. Одно полеauthTTL— «время (в секундах), по истечении которого cookie сессии пользователей завершаются». Ноль снимает ограничение, и ноль же стоит по умолчанию: в референсе прямо написано, что cookie «не имеют ограничения срока действия». Чек‑лист просит поставить «не более 7 дней (604 800 секунд)».П. 5,
Domain2FAService_Enable, POST на/security/v1/org/{orgId}/domain_2fa. В теле три поля:duration(отсрочка в секундах),logoutUsers,validationMethodсо значениямиdefaultилиphone.П. 17,
OauthAccessRestrictionsService_Enable, POST на/security/v1/org/{orgId}/oauth_access_restriction. Тело запроса — пустой объект{}.П. 18, сервисные приложения, закрываются в два шага. Сначала
ServiceApplicationsService_Deactivate, POST на/security/v1/org/{orgId}/service_applications/deactivate: «Позволяет отключить функцию сервисных приложений. После деактивации остаётся возможность только очистить список приложений». ПотомServiceApplicationsService_Create, POST на/security/v1/org/{orgId}/service_applications, с укороченным списком.
Само по себе число вкладок о защищённости не говорит ничего. Зато оно определяет, как будет выглядеть регулярная работа. Эти пять мер замыкаются в одну задачу по расписанию: скрипт читает состояние, сравнивает с эталоном, сам возвращает как надо, в отчёт попадает только факт расхождения. Пять остальных API‑проверяемых пунктов — второй фактор, неактивные пользователи, телефоны, DLP‑правило, портальные аккаунты — скрипт умеет только измерить; исправление живёт в кабинете или по ссылке на инструкцию. Отсюда у меня и два расписания: одно правит само, второе заводит тикет человеку.
Остальное придётся смотреть руками
Без вкладки «Проверка через API» остались восемь пунктов. Колонка «Как проверить» разводит их на три группы.
Два смотрятся глазами в кабинете организации: список администраторов на admin.yandex.ru/users по пометке «Администратор» и раздел «Аудит‑логи», где признак включённого мониторинга — отсутствие кнопки «Подключить».
Пять сопровождены только ссылкой на инструкцию по настройке, без всякой вкладки проверки. Ведут они в разные места: у DKIM и SPF в раздел про DNS‑записи домена, у нежелательных писем в инструкцию про правила обработки почты, у SSO в инструкцию по настройке, у синхронизации с AD в схему SCIM. С DKIM и SPF это никого не остановит: обе записи публичны и проверяются тем же способом, которым вы смотрите любую запись своей зоны. С правилами обработки почты, SSO и синхронизацией из AD придётся идти в кабинет руками.
Один пункт не проверяется никак: организационный запрет на общий аккаунт администратора идёт текстом, без вкладки и без ссылки.
Отдельно для тех, у кого вход в организацию идёт через SSO и синхронизацию с AD: два пункта именно про это попали как раз в те пять, где сверяться нечем. Читаю я это так: остальные шестнадцать от способа входа не зависят вообще. Время жизни cookie‑сессий, парольная политика, привязка телефона, аудит‑лог, DLP‑правило в маршрутизации почты, оба запрета живут в организации независимо от того, где заводятся учётные записи. Фраза «у нас всё через SSO» список не сокращает.
Что нашлось, когда я открыл референс каждого метода
В чек‑листе упомянуто 16 методов API360. Я открыл страницу каждого. Все 16 существуют под теми же именами, что стоят в справке; права доступа тоже совпадают.
Три места стоит знать заранее.
Поле forward, которого нет в референсе. У пункта про DLP чек‑лист называет метод RoutingService_GetRules и параметр в ответе — forward. По формулировке справки он «есть в наличии и указывает на специально созданный DLP‑адрес». Референс метода (yandex.ru/dev/api360/doc/ru/ref/RoutingService/RoutingService_GetRules) описывает ответ иначе: массив rules, в каждом элементе terminal, condition и actions. Два последних поля задокументированы как непрозрачный JSON — “JSON‑описание условия” и «JSON‑описание [массив] действий». Имени forward на странице референса нет. Я проверил дважды, отдельными запросами, 1 сентября 2026 года.
Вывода не строю ни в одну сторону. Из того, что поле не поименовано в схеме, не следует, что его нет в ответе: структура actions в референсе не раскрыта целиком. Практическое следствие одно — структуру правила маршрутизации придётся смотреть на своём арендаторе, документация её не показывает.
С сервисными приложениями меня смутило имя метода. Чек‑лист на втором шаге настройки требует сократить список сервисных приложений, а метод под этим шагом стоит ServiceApplicationsService_Create — создание там, где надо убрать лишнее. Страница метода вопрос снимает: «Создает или заменяет список сервисных приложений в организации». Метод заменяет список целиком телом запроса, отдельного метода «удалить одно приложение» в документации нет. Сократить список — значит вызвать Create с массивом короче текущего. Имя честное: создание и замена здесь один и тот же вызов.
Правило, которое я после этой сверки записал себе: имя метода из чек‑листа — подсказка, а не описание действия. Открывайте страницу референса раньше, чем метод попадёт в скрипт, который вы запустите на живой организации.
Два дословных абзаца про второй фактор. Здесь я приведу обе цитаты и остановлюсь.
Справка, пункт 3: метод для запроса — Domain2FAService_Disable, “чтобы проверить, что у доменных пользователей отсутствует возможность отложить включение второго фактора”, право ya360_security:domain_2fa_write.
Референс этого метода — yandex.ru/dev/api360/doc/ru/ref/Domain2FAService/Domain2FAService_Disable. Страница называется «Выключить 2FA»: DELETE на /security/v1/org/{orgId}/domain_2fa, описание — «Выключает обязательную двухфакторную аутентификацию в организации для всех пользователей домена».
Обе формулировки дословные, обе на 1 сентября 2026 года. Своего толкования у меня нет.
Права: одной галочки на весь аудит не хватит
Если планируете скрипт, права придётся набирать поштучно. Единого «security‑права», которое закрыло бы все проверки, на странице «Доступ к API» (https://yandex.ru/dev/api360/doc/ru/access) нет. У префикса ya360_security: там перечислено минимум десять отдельных прав: domain_2fa_write, domain_sessions_read, domain_sessions_write, domain_passwords_read, domain_passwords_write, domain_settings_read, domain_settings_write, service_applications_read, service_applications_write, read_auditlog. Плюс audit_log_disk и audit_log_mail — эти два в чек‑листе безопасности не упомянуты, но на странице прав они есть.
Сверх них для проверок нужны directory:read_users (“для отправки запросов на просмотр информации о сотрудниках организации”) и ya360_admin:mail_read_routing_rules для DLP‑правила.
Сам порядок получения токена расписан на той же странице «Доступ к API»: регистрация OAuth‑приложения, отметка нужных прав, авторизация по ClientID. В запросах токен идёт заголовком Authorization: OAuth <токен>.
Тут легко запутаться на словах. «Сервисное приложение» из пункта 18 — это не то приложение, которое вы регистрируете под аудит. Сервисные приложения в терминологии платформы — сторонние интеграции с доступом к ресурсам сотрудников внутри организации; отдельной регистрации в этом качестве для проверок чек‑листа документация не требует, нужен обычный OAuth‑flow администратора или владельца организации.
Сколько запросов в секунду выдержит API360, я не скажу. Адрес https://yandex.ru/dev/api360/doc/ru/concepts/limits отдаёт 404, на странице «Доступ к API» о квотах тоже ничего. Такого числа Яндекс не публикует, а придумывать его я не буду.
Аудит‑лог здесь работает датчиком активности
Пункт про блокировку неактивных пользователей мне интереснее прочих. Признак неактивности чек‑лист предлагает брать из аудит‑лога, по полю occurred_at со значением «меньше или равно 30 дней».
В ответе метода, кроме occurred_at в формате ISO 8601, есть items, type, user_login, service, status и iteration_key для пагинации.
Как я это читаю: скрипт по этому пункту не получится из одного запроса. Журнал надо пролистать по iteration_key, сгруппировать события по user_login и посмотреть, у кого последнее событие старше тридцати дней. На этом API и заканчивается: блокировка и удаление пользователя в этом пункте идут по ссылкам на инструкции, вкладки «Настройка через API» у него нет.
Чего страница не говорит
Ограничения источника я собирал по ходу разбора. Список короткий, но планы менять способен.
Приоритетов у пунктов нет — кроме единственной оговорки у второго фактора, где он назван так: «минимальный стандарт безопасности» для организаций, «работающих с защищенной или критичной информацией». Остальные семнадцать не размечены никак, обязательное и опциональное лежат вперемешку. Периодичности повторной проверки тоже нет, кроме сервисных приложений: «проводите ревизию не реже раза в квартал» и «используйте короткоживущие токены». График сверки для остальных придумываете вы.
Полных путей запроса на странице нет, только имя метода и право, дальше по ссылке в референс. Примеров кода нет вообще, хотя автоматизировать аудит скриптами страница предлагает сама. Если вы ссылаетесь на этот список во внутренней политике безопасности, ставьте рядом дату своей сверки.
Ещё одна мелочь по структуре. Блок называется «Шифрование и защита данных», а два его пункта — про привязку телефона и про DLP‑правило в маршрутизации почты. Отдельной рекомендации про шифрование хранения или передачи данных я на странице не нашёл.
Ограничение ответственности: пять строк и семь
В конце страницы есть раздел, который стоит прочитать даже тем, кому не нужны ни мои таблицы, ни скрипты. Дословно: «В Яндекс 360 используется концепция разделения ответственности. Граница ответственности за безопасность определяется типом используемой платформы (модель SaaS), встроенными механизмами защиты и политиками, которые предоставляет провайдер».
Дальше два списка.
Яндекс как поставщик услуг отвечает за пять вещей: «физическую безопасность дата‑центров», «отказоустойчивость платформы», «защиту сетевой инфраструктуры», «мониторинг событий», «механизмы Security‑by‑Default».
Клиент отвечает за семь: «настройку и управление доступом», «внедрение политик паролей», «включение двухфакторной аутентификации», «конфигурацию сетевых правил», «обработку и классификацию данных», «резервное копирование», «аудит объектов внутри организации».
Теперь моё сопоставление клиентской семёрки с восемнадцатью рекомендациями; на странице такого сопоставления нет. Управление доступом я вижу в пунктах про администраторов, портальные аккаунты и SSO. Политики паролей — это пункт 4 с методом и полем, двухфакторная аутентификация — пункты 3 и 5; тут формулировки семёрки повторяются в названиях пунктов почти буквально. Обработку и классификацию данных я свожу к пункту про DLP, аудит объектов внутри организации — к аудит‑логу и неактивным пользователям, конфигурацию сетевых правил — к запретам на внешнюю аутентификацию и на сервисные приложения. Последние три сопоставления самые вольные, и спорить с ними легко.
Седьмая строка — «резервное копирование». Я поискал по странице «резервн», «копирован» и «бэкап»: одно вхождение на всю страницу, ровно здесь, в перечне зон ответственности клиента. Среди восемнадцати рекомендаций пункта про резервное копирование нет — ни формулировки, ни вкладки «Проверка через API», ни проверки в кабинете, ни ссылки на инструкцию.
Ни в одной таблице выше для этой строки не нашлось ни способа проверки, ни права, ни метода, ни поля в ответе. И взяться им было неоткуда: строка живёт в другом разделе той же страницы. Восемнадцать пунктов дают то, что дают, — право, метод, поле, ожидаемое значение. Против строки «резервное копирование» в клиентской зоне на этой странице не стоит ничего.
