Стандарт по защите и безопасному использованию Яндекс 360, версия 1.0.0

Статья создана

Обновлена 22 сентября 2025 г.

Введение
Аутентификация и управление доступом
Безопасность сессий и cookies
- Время жизни cookie ограничено в соответствии с политикой информационной безопасности вашей организации
Мониторинг и аудит
- В организации заблокированы пользователи, которые последний раз входили в нее более 30 дней назад
- Настроен мониторинг событий аудитного лога
Шифрование и защита данных
- У каждого доменного пользователя привязан номер телефона (secure phone)
- При наличии существующей DLP-системы настроить ее на сервисы Яндекс 360
Интеграции и сторонние сервисы

Введение

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

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

Стандарт описывает способы и средства проверки выполнения рекомендаций, в том числе с помощью:

интерфейса Яндекс 360;
API Яндекс 360.

Область применения

Рекомендации предназначены для администраторов, технических специалистов и специалистов по ИБ, которые отвечают за безопасность информационных систем, использующих сервисы Яндекс 360.

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

Структура стандарта

Стандарт описывает рекомендации для следующих задач обеспечения безопасности:

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

Требования и подготовка

Для проверок убедитесь, что:

у вас есть необходимые права доступа к API Яндекс 360;
вы знакомы с документацией по используемым API;
у вас есть доступ к аудитным логам и другим необходимым данным.

Вы можете автоматизировать аудит выполнения всех рекомендаций с помощью скриптов, использующих API Яндекс 360.

Ограничение ответственности

В Яндекс 360 используется концепция разделения ответственности (shared responsibility). Граница ответственности за безопасность определяется типом используемой платформы (модель SaaS), встроенными механизмами защиты и политиками, которые предоставляет провайдер.

Яндекс как поставщик услуг отвечает за физическую безопасность дата-центров, поддержку отказоустойчивой и целостной платформы, защиту сетевой инфраструктуры, мониторинг и анализ событий на уровне системы, а также за реализацию механизмов Security‑by‑Default: шифрование данных, анти‑спам и анти‑DDoS средства и другие встроенные уровни защиты.

Клиент — владелец «Организации 360» — несет ответственность за настройку и управление доступом: назначение ролей (Users, Managers, Admins), внедрение политик паролей, включение двухфакторной аутентификации, конфигурацию сетевых правил для сервисов (например, Яндекс Телемост), обработку и классификацию данных, резервное копирование и аудит собственных объектов внутри организации.

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

Термины и сокращения

В настоящем документе применяются термины и определения, используемые в документации Яндекс 360, а также общепринятые термины в области информационной безопасности.

Аутентификация и управление доступом

Минимальное количество администраторов организации

Y360-1

Организация 360 — логический контейнер в инфраструктуре Яндекс 360, объединяющий сотрудников, домены, группы и сервисы компании. Управление профилем организации, смена владельца, настройка доменов и работа с аудитными логами выполняются через кабинет администратора.

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

Проверка в консоли Яндекс 360

Проверка через API

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

Чтобы просмотреть список сотрудников, воспользуйтесь методом REST API UserService_List для ресурса UserService. Чтобы найти пользователей с правами администратора, отфильтруйте результат по параметру isAdmin: true.

Инструкции по выполнению:

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

Для доменных пользователей и пользователей Яндекс ID используется второй фактор

Y360-3

Для повышения безопасности доступа к корпоративным сервисам Яндекс 360 используйте двухфакторную аутентификацию (2FA) для всех доменных пользователей и пользователей с Яндекс ID. Это означает, что для входа в учетную запись потребуется не только обычный пароль, но и одноразовый код, полученный по телефону или через SMS. Такой подход существенно снижает риск несанкционированного доступа даже в случае компрометации пароля.

Проверка в консоли Яндекс 360

Проверка через API

Войдите в аккаунт администратора организации.
Выберите в меню Безопасность → Подтверждение входа.
Задайте необходимые настройки:
- Кому включить — укажите Всем сотрудникам, если включаете подтверждение сразу на всю организацию, или Выбранным сотрудникам, если хотите настроить его персонально;
- Срок предупреждения — время, которое отводится пользователям для настройки подтверждения входа. Когда этот период закончится, сотрудники больше не смогут отложить настройку.
Примечание

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

Чтобы получить статус настройки 2FA для организации, воспользуйтесь методом REST API Domain2FAService_Get для ресурса Domain2FAService. Убедитесь, что опция 2FA активна для всех доменных пользователей либо для выбранных сотрудников согласно политике.
Чтобы получить статус настройки 2FA для каждого доменного пользователя, воспользуйтесь методом REST API UserService_Get2fa для ресурса UserService. Убедитесь, что в теле ответа параметр twofaEnabled имеет значение true.
Чтобы проверить, что у доменных пользователей отсутствует возможность отложить включение второго фактора, воспользуйтесь методом REST API Domain2FAService_Disable для ресурса Domain2FAService. Убедитесь, что нет пользователей с активной отсрочкой включения 2FA.

Примечание

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

Инструкции по выполнению:

Настройте двухфакторную аутентификацию для всех сотрудников, использующих Яндекс ID или доменные учетные записи Яндекс 360. Это минимальный стандарт безопасности, который необходимо внедрять во всех организациях, работающих с защищенной или критичной информацией.

В организации включена парольная политика

Y360-6

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

Проверка через API

Чтобы получить параметры парольной политики, воспользуйтесь методом REST API DomainPasswordsService_Get для ресурса DomainPasswordsService. Убедитесь, что в теле ответа параметр enabled имеет значение true, а значение параметра changeFrequency составляет не более 180 дней.

Пример ответа:

{"changeFrequency":180,"enabled":true}

Если enabled: false или changeFrequency > 180, политика не соответствует проверке Y360-6.

Инструкции по выполнению:

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

Учетная запись владельца организации имеет средства восстановления

Y360-9

Учетная запись владельца организации должна иметь механизмы восстановления доступа:

Привязанный номер телефона (secure phone) — для восстановления через SMS или звонок.
Двухфакторная аутентификация (2FA) — обязательный дополнительный фактор.

Особенности:
- для доменных пользователей проверка выполняется через API;
- для аккаунтов на Яндексе (@yandex.ru) требуется ручная проверка (API недоступен).

Проверка в консоли Яндекс 360

Проверка через API

Войдите в аккаунт администратора организации.
Проверьте вручную в настройках безопасности:
- наличие привязанного телефона;
- активированную 2FA.

Чтобы проверить, что учетная запись владельца организации имеет механизмы восстановления доступа, воспользуйтесь методом REST API UserService_Get для ресурса UserService. Убедитесь, что в теле ответа параметры has_security_phone и 2fa_enabled установлены в true.
Чтобы проверить глобальные настройки 2FA в организации, воспользуйтесь методом REST API Domain2FAService_Get для ресурса Domain2FAService. Убедитесь, что в теле ответа параметр enabled имеет значение true 2FA.

Инструкции по выполнению:

Консоль Яндекс 360

API

Войдите в аккаунт администратора организации.
Выберите в меню Безопасность → Подтверждение входа.
Задайте необходимые настройки:
- Кому включить — укажите Всем сотрудникам.
Нажмите кнопку Включить.

Для аккаунтов на Яндексе передайте владение организацией доменному пользователю.

Чтобы включить 2FA для доменного аккаунта, воспользуйтесь методом REST API Domain2FAService_Enable для ресурса Domain2FAService.

Безопасность сессий и cookies

Время жизни cookie ограничено в соответствии с политикой информационной безопасности вашей организации

Y360-2

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

Проверка через API

Чтобы проверить текущее значение времени жизни cookie-сессий, воспользуйтесь методом REST API DomainSessionsService_Get для ресурса DomainSessionsService. Параметр authTTL в теле ответа указывает время в секундах, через которое сессии истекают. Если значение authTTL равно 0, срок жизни не ограничен.

Инструкции и решения по выполнению:

Установите значение параметра времени жизни cookie не более 7 дней (604 800 секунд). Это снизит риски, связанные с возможной компрометацией сессий и несанкционированным доступом.

API

Чтобы изменить значение времени жизни cookie-сессий, воспользуйтесь методом REST API DomainSessionsService_Update для ресурса DomainSessionsService.

Пример ответа:

{
"authTTL": 604800
}

Где authTTL — время в секундах (в данном примере установлено на 7 дней).

Мониторинг и аудит

В организации заблокированы пользователи, которые последний раз входили в нее более 30 дней назад

Y360-5

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

Перед внедрением этого контроля убедитесь, что в организации установлено ограничение времени жизни cookie-сессии согласно стандарту Y360-2. Это необходимо для точной оценки реальной активности пользователей.

Проверка через API

Чтобы получить список событий в аудитном логе организации, воспользуйтесь методом REST API get-logs для ресурса audit-logs. Убедитесь, что в теле ответа значение параметра occurred_at составляет не более 30 дней.

Инструкции по выполнению:

Для повышения безопасности рекомендуется блокировать или удалять учетные записи пользователей, которые не проявляли активности более 30 дней, при условии соблюдения стандарта Y360-2 для cookie-сессий.

Как заблокировать или разблокировать сотрудника.

Как удалить аккаунт сотрудника.

Настроен мониторинг событий аудитного лога

Y360-11

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

С помощью аудитных логов администраторы и менеджеры могут изучить:

События в сервисах:
- Как сотрудники входят в аккаунт. Например, можно увидеть, когда и с какого устройства подключился сотрудник.
- Что сотрудники организации делают с письмами и файлами в Почте и Диске. Например, вы можете узнать, кто переместил письмо или файл.
События в кабинете организации:
- Какие изменения вносились в кабинете организации. Например, можно узнать, что изменилось в данных пользователя и кто внес эти изменения.
- Что другие администраторы ищут в архиве писем и как настраивают правила для писем.

Проверка в консоли Яндекс 360

Войдите в аккаунт администратора организации.
В меню слева выберите Аудит-логи.

Если есть кнопка Подключить, это означает, что настройка не соответствует проверке Y360-11.

Инструкции по выполнению:

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

Шифрование и защита данных

У каждого доменного пользователя привязан номер телефона (secure phone)

Y360-4

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

Проверка в консоли Яндекс 360

Проверка через API

Перейдите на страницу Телефоны.

На странице будет указано несколько номеров, если в другом сервисе Яндекса был указан номер, который отличается от основного.

Чтобы получить статус настройки 2FA для каждого доменного пользователя, воспользуйтесь методом REST API UserService_Get2fa для ресурса UserService. В ответе проверьте, что значение поля hasSecurityPhone выставлено в true.

Примечание

Для пользователей с аккаунтом Яндекс ID проверка механизма будет реализована позже.

Инструкции по выполнению:

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

При наличии существующей DLP-системы настроить ее на сервисы Яндекс 360

Y360-14

Для защиты корпоративной информации и минимизации риска несанкционированных утечек данных рекомендуется настроить DLP-систему (Data Loss Prevention) в сервисах Яндекс 360. DLP позволяет автоматически выявлять и предотвращать передачу конфиденциальной информации (пароли, токены, секретные ключи, личные данные и т. д.) неавторизованным получателям.

Проверка через API

Чтобы проверить наличие правила пересылки исходящей и входящей почты на DLP-адрес, воспользуйтесь методом REST API RoutingService_GetRules для ресурса RoutingService. Убедитесь, что одно из правил (первое или обязательно активное) имеет действие forward и адресовано на специально созданный DLP-адрес (dlp@domain.ru или аналогичный).

Пример ответа:

{
  "terminal": false,
  "condition": {},
  "actions": [
    {
      "data": {"email": "dlp@domain.ru"},
      "action": "forward"
    }
  ],
  "scope": {"direction": "outbound"}
}

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

Инструкции по выполнению:

Рассмотрите возможность настройки пересылки исходящей (и, при необходимости, входящей) почты на специальный «DLP-ящик» для автоматического анализа:
- проверьте наличие правила пересылки с помощью API-запроса GET https://api360.yandex.net/admin/v1/org/{ОРГАНИЗАЦИЯ}/mail/routing/rules;
- убедитесь, что одно из правил имеет действие forward и адресовано специально созданному DLP-адресу (например, dlp@domain.ru).
Убедитесь, что DLP-ящик доступен для обработки внешней системой:
- для интеграции DLP-платформы с почтовым ящиком создайте специального пользователя;
- настройте пароль приложения или OAuth-доступ для этого пользователя.
Проверьте, включена ли проверка писем на наличие:
- паролей и сбросов паролей;
- токенов доступа;
- частных ключей SSH, PKI, VPN;
- персональных или конфиденциальных данных (если политика включает такой контроль).

Интеграции и сторонние сервисы

В организации не используются портальные учетные записи

Y360-7

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

Проверка через API

Чтобы получить список сотрудников, воспользуйтесь методом REST API UserService_List для ресурса UserService. Убедитесь, что в теле ответа параметр email не оканчивается на @yandex.ru. Личные учетные записи не соответствуют проверке Y360-7.

Инструкции и решения по выполнению:

Рекомендуется исключить использование личных портальных учетных записей с адресом @yandex.ru в корпоративной среде. Вместо этого следует передавать владение организацией доменным пользователям, чтобы обеспечить централизованное управление политиками безопасности и контроль доступа к корпоративным ресурсам.

В организации используется SSO на базе SAML-совместимого IDP

Y360-8

Доступ к организации реализован через единый вход (SSO) с использованием внешнего SAML-совместимого поставщика удостоверений (IdP). Доменные пользователи не должны существовать параллельно с SSO-аккаунтами. Если у вас нет своего IdP, можно использовать Yandex Identity Hub. Для этого создайте SAML-приложение в Identity Hub и настройте его как на стороне Identity Hub, так и на стороне поставщика услуг.

Подробнее см. в Создать SAML-приложение в Yandex Identity Hub.

Инструкции по выполнению:

Для обеспечения централизованного управления доступом и повышения уровня безопасности рекомендуется использовать единый вход (SSO) на базе SAML-совместимого IdP. Это позволит упростить процесс аутентификации для пользователей и обеспечит более эффективное управление доступом к ресурсам организации.

Проверка выписанных OAuth-токенов и их разрешений на использование сервиса, которые доступны при настройке приложения

Y360-10

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

соответствия принципу минимальных привилегий;
отсутствия токенов с избыточными правами (например, mail:full_access, cloud:admin).

Проверка в консоли Яндекс 360

Проверка через API

Чтобы проверить список подключенных приложений:

Войдите в аккаунт администратора организации.
Перейдите в Безопасность → Сервисные приложения.
Просмотрите список всех зарегистрированных приложений.
Сопоставьте каждое приложение с внутренним реестром доверенных интеграций, проверьте несоответствия и подозрительные интеграции.

Чтобы проверить разрешения (scopes):

Для каждого приложения скопируйте его Client ID.
Перейдите по ссылке https://oauth.yandex.com/client/<client_id>/info, где client_id — идентификатор приложения.
На странице проверьте:
- разрешения (scopes), которые запрашивает приложение;
- имеет ли приложение доступ к чувствительным данным (почта, календарь, контакты и т.д.).
Сравните запрашиваемые права с реальными потребностями приложения, проверьте избыточные или подозрительные разрешения.

Чтобы проверить аутентификацию:

Войдите в аккаунт администратора организации.
Перейдите в Безопасность → Устройства и активность.
Просмотрите список активных сессий пользователей и найдите:
- сотрудников с подключенными сторонними приложениями;
- неиспользуемые или подозрительные сеансы.
(Опционально) При необходимости:
- завершите лишние или устаревшие сессии;
- уведомите пользователей о необходимости ревизии доступов.

Чтобы отключить ненужные приложения:

Войдите в аккаунт администратора организации.
Перейдите в Безопасность → Сервисные приложения.
Деактивируйте или удалите каждое неподтвержденное, устаревшее или ненужное приложение.
Убедитесь, что оставлены только те приложения, которые:
- официально одобрены;
- соответствуют политике минимальных привилегий;
- не имеют избыточных разрешений.

Чтобы получить список сервисных приложений и их права доступа (scope), воспользуйтесь методом REST API ServiceApplicationsService_Get для ресурса ServiceApplicationsService.
Чтобы сократить список сервисных приложений, воспользуйтесь методом REST API ServiceApplicationsService_Create для ресурса ServiceApplicationsService.
Чтобы проверить реальный доступ с помощью короткоживущего токена:

Выпустите временный токен для конкретного пользователя и проверьте, что операции срабатывают только в рамках разрешенных прав:
```
curl --location \
--request POST 'https://oauth.yandex.ru/token' \
--header 'Content-Type: application/x-www-form-urlencoded' \
--data-urlencode 'grant_type=urn:ietf:params:oauth:grant-type:token-exchange' \
--data-urlencode 'client_id=<OAuth_service_app_client_id>' \
--data-urlencode 'client_secret=<OAuth_service_app_client_secret>' \
--data-urlencode 'subject_token=<user_id>' \
--data-urlencode 'subject_token_type=urn:yandex:params:oauth:token-type:uid'
```
Где:
- OAuth_service_app_client_id — client ID сервисного приложения;
- OAuth_service_app_client_secret — client secret сервисного приложения;
- user_id — идентификатор пользователя, для которого необходимо получить токен;
- user_email — электронный адрес пользователя вида username@domain.ru, для которого необходимо получить токен.
Ответ будет содержать токен, который надо использовать в запросах к API сервисов Яндекс 360.

Инструкции по выполнению:

Применяйте принцип минимальных привилегий к каждому сервисному приложению, ведите реестр (владелец, назначение, минимальный набор scopes), проводите ревизию не реже раза в квартал, используйте краткоживущие токены для разовых задач и оперативно отзывайте лишние токены. Для Диска по возможности используйте узкие права (cloud_api:disk.app_folder, cloud_api:disk.read).

Установлен запрет на аутентификацию во внешних OAuth-сервисах

Y360-12

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

Проверка через API

Чтобы получить статус запрета, воспользуйтесь методом REST API OauthAccessRestrictionsService_Get для ресурса OauthAccessRestrictionsService.

Проанализируйте ответ:

"restricted": true — сотрудники не могут аутентифицироваться в сторонних сервисах через Яндекс 360;
"restricted": false — требуется установить запрет.

Чтобы включить запрет на аутентификацию во внешних OAuth-сервисах, воспользуйтесь методом REST API OauthAccessRestrictionsService_Enable для ресурса OauthAccessRestrictionsService.

Инструкции по выполнению:

Установите запрет (restricted = true) для всех сотрудников, чьи аккаунты находятся на корпоративном домене.
Регулярно перепроверяйте статус этой политики, особенно после изменений в структуре управления организацией или при массовых подключениях внешних приложений.

Установлен запрет на подключение сервисных приложений, либо в списке сервисных приложений находятся только доверенные приложения

Y360-13

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

либо полностью запрещено (по умолчанию);
либо из списка подключенных приложений должны быть исключены все неутвержденные/неизвестные/подозрительные приложения, а остаться только доверенные, одобренные службой безопасности или ИТ-отделом.

Сервисные приложения могут запрашивать различные права доступа (scopes) и использовать корпоративные ресурсы. Неконтролируемое подключение сервисных приложений значительно повышает риски кражи данных, несанкционированного доступа, внедрения вредоносного кода и обхода внешних политик безопасности.

Проверка через API

Чтобы получить актуальный список сервисных приложений, воспользуйтесь методом REST API ServiceApplicationsService_Get для ресурса ServiceApplicationsService. В теле ответа найдите массив applications с объектами вида:

{
  "id": "some_id",
  "scopes": [
    "scope1",
    "scope2"
  ]
}

Проанализируйте ответ:

проверьте, соответствуют ли приложения внутреннему списку доверенных/разрешенных сервисных приложений вашей организации;
убедитесь, что среди сервисных приложений нет неизвестных, неиспользуемых или подозрительных приложений;
обратите внимание на выданные scopes (допуски) — минимизируйте избыточные права.

Если не допускается никаких сервисных приложений — список должен быть пустым.

Инструкции и решения по выполнению:

Запрещайте по умолчанию подключение любых сервисных приложений (поддержка только «белого списка») и регулярно проверяйте состав подключенных сервисных приложений и их права доступа.
Согласовывайте новые подключения с ИБИТ-отделом и ужесточайте условия доступа.
Немедленно удаляйте неизвестные или подозрительные приложения.

Стандарт по защите и безопасному использованию Яндекс 360, версия 1.0.0

ВведениеВведение

Область примененияОбласть применения

Структура стандартаСтруктура стандарта

Требования и подготовкаТребования и подготовка

Ограничение ответственностиОграничение ответственности

Термины и сокращенияТермины и сокращения

Аутентификация и управление доступомАутентификация и управление доступом

Минимальное количество администраторов организацииМинимальное количество администраторов организации

Для доменных пользователей и пользователей Яндекс ID используется второй факторДля доменных пользователей и пользователей Яндекс ID используется второй фактор

В организации включена парольная политикаВ организации включена парольная политика

Учетная запись владельца организации имеет средства восстановленияУчетная запись владельца организации имеет средства восстановления

Безопасность сессий и cookiesБезопасность сессий и cookies

Мониторинг и аудитМониторинг и аудит

Настроен мониторинг событий аудитного логаНастроен мониторинг событий аудитного лога

Шифрование и защита данныхШифрование и защита данных

У каждого доменного пользователя привязан номер телефона (secure phone)У каждого доменного пользователя привязан номер телефона (secure phone)

При наличии существующей DLP-системы настроить ее на сервисы Яндекс 360При наличии существующей DLP-системы настроить ее на сервисы Яндекс 360

Интеграции и сторонние сервисыИнтеграции и сторонние сервисы

В организации не используются портальные учетные записиВ организации не используются портальные учетные записи

В организации используется SSO на базе SAML-совместимого IDPВ организации используется SSO на базе SAML-совместимого IDP

Установлен запрет на аутентификацию во внешних OAuth-сервисахУстановлен запрет на аутентификацию во внешних OAuth-сервисах

Была ли статья полезна?

Введение

Область применения

Структура стандарта

Требования и подготовка

Ограничение ответственности

Термины и сокращения

Аутентификация и управление доступом

Минимальное количество администраторов организации

Для доменных пользователей и пользователей Яндекс ID используется второй фактор

В организации включена парольная политика

Учетная запись владельца организации имеет средства восстановления

Безопасность сессий и cookies

Мониторинг и аудит

Настроен мониторинг событий аудитного лога

Шифрование и защита данных

У каждого доменного пользователя привязан номер телефона (secure phone)

При наличии существующей DLP-системы настроить ее на сервисы Яндекс 360

Интеграции и сторонние сервисы

В организации не используются портальные учетные записи

В организации используется SSO на базе SAML-совместимого IDP

Установлен запрет на аутентификацию во внешних OAuth-сервисах