Goal: описать систему управления доступами в CF

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

Какая предлагается структура:

- аккаунт холдер: это мастер аккаунт, в нем никто не работает.

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

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

Важно — доступ к этому аккаунту присутствует у ограниченного списка лиц.

Аккаунт холдеры оптимально регистрировать на групповые ящики, чтобы уведомления по ним получала группа лиц, а не один человек.

- аккаунт апи холдер

Нам нужно централизованно управлять токенами, для этого желательно иметь ОДИН аккаунт, в котором будут создаваться все токены. Так же токены должны иметь naming-convention. К примеру департамент-продукт-назначение.

cat-minebit-strapi - страпи токен для minebit

nc-platform-gitlab - НекстКод для управления кешами из CI

na-temporal-affilka - НодАрт темпорал интеграция с аффилкой (бакет)

Токены желательно привязывать к ip адресам (это самый надежный способ борьбы с утечками).

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

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

Система безопасности CF позволяет такому аккаунту быть супер админом любого количества аккаунтов и генерировать токены с доступом к ресурсам нескольких аккаунтов сразу (к примеру для NC сделать токен который будет сбрасывать кеш зеркал, находящихся сразу в нескольких аккаунтах, или для NA - токен который позволяет публиковать воркеры сразу в нескольких аккаунтах)

- аккаунт сотрудника

Аккаунт на рабочую почту с делегированным доступом. Желательно выдавать минимальный доступ. Сейчас так и есть, но есть еще одно дополнительное улучшение - UserGroups. Сейчас у CloudFlare уже появились переиспользуемые наборы правил, и к примеру для отдела ретеншена было бы хорош использовать usergroups, для поддержания доступов в единообразном виде. Таким образом, когда нам нужно изменить права доступа ретеншен отделу (к примеру появился новый функционал - DKIM мониторинг), мы не исчем список сотрудников и каждого правим отдельно, а меняем набор правил в группе.