Наименьшие привилегии на практике

Что это такое

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

Почему это важно

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

Ключевые идеи

Начинайте с отказа и добавляйте наблюдаемое

Надёжный метод — не давать ничего, смотреть, что рабочая нагрузка действительно вызывает, и выдать это. Начать с широкой готовой политики и намереваться сузить её позже не работает, потому что «позже» не наступает. Там, где пробный период правда требует широты, разрешение должно нести срок и тикет, чтобы оно убрало себя само, если продолжение забыли.

наблюдайте вызовы -> выдайте ровно их -> наблюдайте снова -> уберите то, что перестало использоваться

Подстановочные знаки — там, где теряются привилегии

Подстановочный знак в действиях на подстановочном знаке в ресурсах — самое широкое разрешение из возможных; даже узкое действие, разрешённое на всех ресурсах, может быть обширным, когда действие разрушительное. Читая политику, полезно спросить, какие в ней действия и какие ресурсы и нет ли подстановочного знака в каждом из них. Там, где подстановочный знак действительно нужен, ограничивать обычно стоит сторону ресурсов.

Условия сужают разрешение сильнее списка действий

Политика может требовать, чтобы запрос пришёл по зашифрованному соединению, из определённой сети, с многофакторной аутентификацией или с определённой меткой. Условия выражают намерение, которое список действий выразить не может: «это можно читать, но только изнутри нашей сети» — одно условие, а не новая роль. Это часто самый дешёвый способ сузить существующее разрешение.

Неиспользуемые разрешения безопаснее всего убирать

Каждый сервис и каждое разрешение — кандидат. Сравнение выданных разрешений с теми, что реально использовались за долгий период, даёт список удалений почти без риска. Периодическая проверка идентичностей, которыми никогда не пользовались, — то же упражнение на уровне субъектов.

Дрейф — то, что отменяет работу

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

Слой приложения — отдельный фронт

Ничто из этого не покрывает сервис, доверяющий любому аутентифицированному вызывающему, эндпоинт, возвращающий чужую запись, или запрос, собранный конкатенацией строк. Управление идентификацией и доступом управляет API; собственная авторизация приложения управляет его данными. Нужны оба, и эта запись останавливается на первом.

Практика

Уберите неиспользуемое разрешение

Возьмите идентичность с широким разрешением, перечислите действия, которые она реально использовала за период, и составьте суженную политику, исключающую остальное.

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

Заметьте дрейф в одном наборе политик

Возьмите набор политик и их задуманное определение и напишите сравнение, которое вы запускали бы по расписанию, чтобы находить различия.

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

Частые ошибки

• Выдать широко, чтобы разблокировать развёртывание, и не сузить — разрешение переживает проблему; исправить: прикрепите срок и продолжение.
• Использовать подстановочные знаки в действиях и ресурсах по умолчанию — действующее разрешение — весь сервис; исправить: сузьте действия и ресурсы и проверяйте подстановочные знаки на ревью.
• Игнорировать условия — принимается незашифрованный запрос или запрос извне сети; исправить: выразите ограничение условием, а не новой ролью.
• Никогда не проверять неиспользуемые идентичности и разрешения — хозяйство тихо ширится; исправить: сравнивайте выданное с использованным по расписанию.
• Полагаться на IAM для авторизации приложения — один сервис может прочитать данные другого пользователя; исправить: сохраните собственную авторизацию приложения и считайте это отдельным слоем.

Что читать дальше

• Идентичности и роли (06-cloud-devops/12-cloud-security-iam/01-identities-and-roles) — субъекты и доверительные отношения, к которым привязаны эти разрешения.
• Безопасность в облаке и IAM (06-cloud-devops/12-cloud-security-iam) — дисциплина, половиной которой по поддержанию является этот дочерний урок.
• Веб-безопасность (OWASP Top 10) (07-security/01-web-security-owasp-top-10) — слой приложения, где вместо этого живёт нарушенный контроль доступа.