Лучшие практики по работе с учетными записями
Кратко:
- Привилегированные пользователи имеют больше полномочий, чем обычные пользователи.
- Рекомендуется назначать роль resource-manager.clouds.owner одному или нескольким сотрудникам.
- Для аккаунта Яндекс ID, под которым создано облако, нужно назначить сложный пароль.
- Роли admin на облака, каталоги и платежные аккаунты рекомендуется назначать только федеративным учетным записям.
- Для аккаунта с ролью billing.accounts.owner следует уделять повышенное внимание безопасности.
- Рекомендуется использовать двухфакторную аутентификацию для аккаунта с ролью billing.accounts.owner.
- При разработке модели доступа для инфраструктуры рекомендуется использовать подход, основанный на ресурсах.
- При использовании сервисных аккаунтов рекомендуется следовать принципу минимальных привилегий.
Лучшие практики по работе с учетными записями
В последних уроках этой и следующих тем мы будем рассказывать о лучших практиках обеспечения безопасности. Возможно, не все из них будут применимы для вашего проекта, но это полезные практические приемы, и о них в любом случае стоит знать.
Управление привилегированными пользователями
К привилегированным пользователям относятся учетные записи со следующими ролями:
resource-manager.clouds.owner;billing.accounts.owner;- роль
admin, назначенная всему облаку; - роль
admin, назначенная каталогу; - роль
admin, назначенная платежному аккаунту.
Привилегированными они называются потому, что могут делать в облаке гораздо больше, чем обычный пользователь. Поэтому и результат их действий может оказаться крайне неприятным.
Пользователь, который создает облако, автоматически получает роль
resource-manager.clouds.owner. Она позволяет выполнять любые операции с облаком и ресурсами в нем, а также выдавать доступ другим пользователям путем назначения и отзыва ролей.Если ваша компания использует федерацию удостоверений, то рекомендуется назначить эту роль одному или нескольким сотрудникам. Их федеративные аккаунты должны быть надёжно защищены с помощью:
- двухфакторной аутентификации;
- запрета на аутентификацию с посторонних устройств;
- мониторинга попыток входа и заданных порогов предупреждений.
Для аккаунта Яндекс ID, под которым создано облако, нужно назначить сложный пароль, а использовать его — только в случае крайней необходимости (например, если федерация сломалась).
Роли
admin на облака, каталоги и платежные аккаунты рекомендуется назначать только федеративным учетным записям. При этом число таких учетных записей должно быть минимально необходимым, а потребность пользователей в такой роли следует регулярно перепроверять.Еще одна важная роль — это
billing.accounts.owner, которая автоматически выдается при создании платёжного аккаунта и не может быть переназначена другому пользователю. Она позволяет выполнять любые действия с платёжным аккаунтом. Роль billing.accounts.owner может быть назначена только аккаунту Яндекс ID. Аккаунт с этой ролью используется при настройке способов оплаты и подключении облаков.Безопасности такого аккаунта следует уделять повышенное внимание, поскольку он обладает значительными полномочиями и не может быть подключен к федерации корпоративных аккаунтов.
Наиболее правильным подходом можно считать отказ от регулярного использования аккаунта с этой ролью, то есть его нужно использовать только при первоначальной настройке и при внесении изменений. На время активного использования этого аккаунта включите двухфакторную аутентификацию (2FA) в Яндекс ID. Затем, если вы не используете способ оплаты банковской картой (доступный только для данной роли), назначьте этому аккаунту сложный пароль, сгенерированный с помощью специализированного ПО, отключите 2FA и не используйте этот аккаунт без необходимости.
После каждого использования генерируйте новый пароль. Отключение 2FA для этого аккаунта важно в ситуации, если аккаунт не закреплён за конкретным сотрудником. Это позволяет избежать привязки критически важного аккаунта к личному устройству.
Использование ресурсной модели
Если система должна соответствовать требованиям PCI DSS, то при разработке модели доступа для создаваемой инфраструктуры рекомендуется использовать следующий подход:
- все ресурсы, которые входят в область соответствия PCI DSS, нужно поместить в отдельное облако;
- группы ресурсов, которые требуют разного административного доступа, помещают в разные каталоги (например, DMZ, security, backoffice и т.д.);
- общие ресурсы (например, сеть и группы безопасности) помещают в отдельный каталог для разделяемых ресурсов.
Последние два пункта стоит иметь в виду при построении любой сложной инфраструктуры в облаке, даже если требования PCI DSS вас пока не беспокоят.
Использование сервисных аккаунтов
При использовании сервисных аккаунтов рекомендуется:
- для назначения сервисного аккаунта на виртуальную машину и получения токена использовать сервис метаданных;
- настроить на виртуальной машине локальный файрвол;
- обеспечить безопасное хранение и управление ключами сервисного аккаунта;
- следовать принципу минимальных привилегий и назначать сервисному аккаунту только те роли, которые необходимы для работы приложения;
- следовать принципу минимальных привилегий и в отношении доступа к самому сервисному аккаунту, то есть выдавать роли на него минимальному кругу пользователей и только при необходимости.