Чек-лист безопасности Яндекс 360: API проверяет 10 из 18 мер, а настраивает только 5
В Яндекс 360 опубликован перечень из 18 технических мер защиты для организаций. Для некоторых рекомендаций рядом указаны конкретные API-методы и необходимые права доступа. Это позволяет не только изучать требования вручную, но и частично автоматизировать аудит с помощью скриптов.
При проверке страницы выяснилось: вкладка "Проверка через API" предусмотрена для 10 пунктов из 18, а "Настройка через API" - только для пяти. Остальные меры требуют работы в кабинете, чтения инструкций или ручной проверки.
Что представляет собой страница безопасности
Материал предназначен для администраторов и специалистов по информационной безопасности. На странице собраны рекомендации по техническим настройкам, которые должны повысить защищённость организации в Яндекс 360. Для отдельных пунктов приведены ссылки на документацию API и варианты настройки.
Хотя слово "чек-лист" непосредственно на странице не используется, по сути это именно он. В отдельном PDF пользователю предлагают скачать и распечатать список, а затем отмечать выполненные рекомендации. Для работы предполагается, что администратор:
- обладает необходимыми правами доступа к API;
- знаком с документацией;
- имеет доступ к аудит-логам;
- умеет запускать или адаптировать автоматизированные скрипты.
Главное достоинство такого подхода - конкретика. Вместо абстрактной рекомендации вроде "проверьте безопасность пользователей" указаны метод API, право доступа и параметры ответа. Для администратора это гораздо полезнее общих советов.
Как проводился подсчёт
Подсчёт выполнялся по состоянию на 1 сентября 2026 года. Страница не содержит даты последнего обновления и номера редакции, поэтому при повторной проверке цифры могут отличаться.
Информация сверялась тремя способами:
1. по машинной выгрузке страницы в формате Markdown;
2. по содержимому веб-страницы;
3. поиском точных обозначений "Проверка через API" и "Настройка через API".
Во всех случаях результат совпал: на странице 18 пунктов, объединённых в шесть тематических блоков. Из них 10 имеют API-проверку, а 5 - возможность изменения параметров через API.
Все 18 мер защиты
Ниже приведена карта рекомендаций и способов их контроля.
1. Аутентификация и управление доступом
1. Минимальное количество администраторов организации - проверяется в кабинете.
2. Запрет на использование одного аккаунта администратора несколькими сотрудниками - отдельного способа проверки не указано.
3. Использование второго фактора для доменных пользователей и пользователей Яндекс ID - проверяется через API.
4. Включённая парольная политика организации - проверяется и настраивается через API.
5. Наличие средств восстановления для учётной записи владельца организации - способ автоматизированной проверки не указан.
2. Безопасность сессий и cookies
6. Ограничение времени жизни cookie - отдельная API-проверка в перечне не обозначена.
3. Мониторинг и аудит
7. Блокировка неактивных пользователей организации - в представленном чек-листе не указаны отдельные вкладки проверки или настройки.
8. Настройка мониторинга событий аудит-лога - контроль выполняется через API.
4. Шифрование и защита данных
9. Привязка номера телефона для каждого доменного пользователя - доступна API-проверка.
10. Настройка существующей DLP-системы - предусмотрена API-проверка.
5. Защита корпоративной почты
11. Настройка DKIM-подписи - приведена только инструкция.
12. Настройка SPF-записи - приведена только инструкция.
13. Ограничение приёма писем от внешних отправителей - проверка выполняется через API.
14. Настройка антивирусной защиты почты - проверяется и настраивается через API.
15. Настройка фильтрации нежелательной почты - проверяется через API.
6. Резервное копирование и восстановление
16. Настройка резервного копирования данных организации - отдельного API-инструмента в описании не указано.
17. Проверка возможности восстановления данных - автоматизированный способ не обозначен.
18. Регламент хранения резервных копий - доступна только текстовая рекомендация.
Таким образом, автоматизация охватывает не весь перечень, а лишь его часть. Пять настроек можно не только проверить, но и изменить программно. Ещё пять - только проконтролировать через API.
Какие данные понадобятся для скрипта
Для каждого автоматизируемого пункта нужно определить три элемента:
- требуемое право доступа;
- название API-метода;
- поле ответа, по которому определяется результат.
Например, для контроля двухфакторной аутентификации недостаточно просто вызвать метод. Скрипт должен понять, какие пользователи охвачены обязательным вторым фактором, а какие остаются исключениями. Поэтому важно анализировать не только HTTP-код ответа, но и содержимое возвращаемой структуры.
Та же логика действует для парольной политики, DLP, почтовых ограничений и настроек антивирусной проверки. Если программа лишь фиксирует, что запрос выполнен успешно, аудит будет формальным: технически доступ к API есть, но фактическое состояние защиты остаётся неизвестным.
Что можно привести в норму автоматически
Пять пунктов имеют не только вкладку проверки, но и API-настройку. Это означает, что скрипт способен обнаружить отклонение и отправить корректирующий запрос.
Практически такой режим лучше строить в два этапа:
1. сначала выполнить безопасную проверку без внесения изменений;
2. затем применить исправления только после подтверждения администратора.
Автоматическое изменение настроек без журнала операций опасно. Ошибка в логике скрипта может затронуть всех пользователей организации: изменить требования к паролям, ограничить доступ к почте или повлиять на работу корпоративных систем.
Рекомендуется предусмотреть режимы `check` и `apply`. Первый только формирует отчёт, второй меняет параметры. Все действия режима настройки должны записываться в отдельный журнал с указанием времени, пользователя, старого и нового значения.
Почему одного права доступа недостаточно
Наличие API-права ещё не означает, что с его помощью можно провести полноценный аудит всей организации. Разные методы могут требовать разные разрешения, а некоторые данные доступны только администраторам определённого уровня.
Поэтому универсальный токен "для всего аудита" - плохая практика. Безопаснее использовать отдельные учётные данные для чтения и изменения настроек. Для регулярной проверки достаточно минимально необходимых прав, а разрешения на изменение следует выдавать только процессу, который действительно выполняет корректировку.
Такой подход снижает последствия компрометации токена и упрощает расследование инцидентов.
Аудит-лог как источник активности
Аудит-лог в этой схеме выступает не только архивом событий, но и датчиком активности. По нему можно определить, какие действия выполнялись администраторами, менялись ли политики, создавались ли исключения и происходили ли подозрительные операции с учётными записями.
При этом аудит-лог не заменяет проверку текущего состояния. Он показывает факт события, но не всегда отвечает на вопрос, соответствует ли сегодняшняя конфигурация требованиям. Поэтому правильный процесс должен объединять два источника:
- API - для получения актуальных настроек;
- аудит-лог - для контроля изменений и действий пользователей.
Ограничения чек-листа
Перечень из 18 мер нельзя считать полной системой управления информационной безопасностью. Он не заменяет анализ ролей, проверку жизненного цикла учётных записей, тестирование восстановления и оценку бизнес-рисков.
Есть и технические ограничения:
- часть рекомендаций описана только текстом;
- для некоторых мер не указаны методы автоматической проверки;
- состав страницы может измениться без заметного номера редакции;
- API-ответы и названия методов со временем способны обновляться;
- факт включённой настройки не гарантирует, что она корректно работает в реальной эксплуатации.
Поэтому чек-лист лучше использовать как базовый контрольный слой. Его результаты стоит дополнять ручной проверкой, анализом журналов, тестами восстановления и периодическим пересмотром прав доступа.
Итог
В опубликованном перечне Яндекс 360 насчитывается 18 мер безопасности. Через API можно проверить 10 из них, а для пяти предусмотрена также программная настройка. Остальные пункты требуют работы в административном интерфейсе, изучения инструкции или ручной оценки.
Для автоматизации важно заранее сопоставить каждому пункту право доступа, метод API и конкретное поле ответа. Надёжный скрипт должен не просто отправлять запросы, а формировать понятный отчёт, фиксировать изменения и работать по принципу минимальных привилегий.
Главная практическая ценность страницы - в привязке рекомендаций к реальным техническим инструментам. Администратор получает не общий список пожеланий, а основу для воспроизводимого аудита, который можно регулярно запускать и постепенно расширять собственными проверками.