История активности и роли команды: кто что изменил и кто мог

Вопрос, на который общий логин не может ответить

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

Эта брешь обходится дороже, чем просто неловкость. Без записи вы не отличите ошибку от вторжения. Вы не можете уверенно откатить изменение, потому что не знаете прежнего значения. И вы не можете улучшить процесс, потому что «будьте внимательнее» — единственный урок, который остаётся, когда никто не знает, что произошло на самом деле.

Есть и взгляд со стороны. Проверяемый след административных действий и осмысленный контроль доступа — стандартное ожидание в анкетах безопасности и в таких стандартах, как ISO 27001, а режимы защиты данных вроде KVKK и GDPR ожидают, что вы сможете показать, у кого был доступ к чему. Сертифицируете вы что-то или нет, это требование описывает то, что вам нужно и ради себя самих.

Что записывается

История активности охватывает изменения, которые могут повлиять на то, что видят посетители: очистки кэша, изменения DNS-записей, изменения правил доставки, изменения пресетов безопасности — включая HSTS и блок-листы по стране и ASN, — действия с сертификатами и изменения хостов.

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

Именно последнее поле превращает журнал из отчёта в инструмент. «Изменено правило доставки» подсказывает, куда смотреть. «Cache TTL 3600 → 60» говорит, что в тот же момент произошло с трафиком на ваш источник.

Как читать его, когда что-то сломалось

Откройте боковую панель аккаунта, затем Monitoring → Activity history — /management/cdn/activities.

Во время инцидента работает такая последовательность: сузьте окно до интересующего вас периода, смотрите на весь аккаунт, а не только на то изменение, которое вы уже подозреваете, и читайте значения «до/после», а не заголовки записей. Изменение, сломавшее сайт, часто оказывается не тем, о котором вы думали, а выдаёт его обычно порядок событий — две записи от разных людей с разницей в пять минут обычно и есть вся история.

Фильтр по типу действия — вот что делает загруженный аккаунт читаемым. Сайт с автоматической очисткой кэша при каждой публикации генерирует множество записей, которые вам не нужны; отфильтруйте их, и оставшаяся горстка изменений конфигурации будет достаточно короткой, чтобы прочитать её целиком.

Вне инцидента та же страница отвечает на более спокойный вопрос: не меняется ли что-то, о чём никто не упомянул? На это стоит потратить пять минут в месяц.

Доступ через API

История также доступна через API — это то, что нужно, если вы её архивируете, пересылаете в собственную систему логирования или просто храните больше, чем готовы пролистывать вручную. action_type принимает те же категории, что и фильтр в панели, а эндпоинт всегда показывает только те аккаунты, которые разрешены вашему токену.

Последние 25 очисток кэша на одном аккаунте

curl -s -H "Authorization: Bearer $TOKEN" \
  "https://cdn.com.tr/api/accounts/<account-uuid>/activities?per_page=25&action_type=purge_cache"

Три роли и для чего каждая из них

Журнал говорит, что произошло. Роли сокращают то, что вообще может произойти. Саб-пользователь на cdn.com.tr получает одну из трёх ролей.

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

Editor выполняет операционную работу: очищает кэш, редактирует правила доставки, управляет DNS-записями, сертификатами и хостами. Чего editor не может — это менять форму самого аккаунта: ни создавать или удалять саб-пользователей, ни трогать биллинг, ни удалять аккаунт. Это роль для тех, кто ведёт сайт изо дня в день.

Owner делает всё это, включая три вещи, от которых editor намеренно отстранён. Это владелец аккаунта, и список таких людей должен оставаться очень коротким.

Стоит знать две детали. Если саб-пользователь создан без выбора роли, он становится viewer — безопасный край шкалы, так что забытое поле никогда не выдаст больше прав, чем вы имели в виду. И роли применяются к API-токенам точно так же, как в панели: токен viewer'а может читать и не может писать, поэтому скрипт, запущенный тем, кому нельзя менять DNS, DNS изменить не может.

Добавление человека с нужным ему доступом

Перейдите в Authorization — /management/authorization — и выберите New user. Заполните данные и выберите роль перед сохранением; именно это поле решает всё остальное в том, что может делать этот человек.

На практике работают две привычки. Давайте каждому свой логин, а не делитесь одним: история активности полезна ровно настолько, насколько полезны имена в ней, а «очищено с общего аккаунта» — тот же тупик, с которого вы начали. И когда кто-то присоединяется ради конкретной работы — миграции, работы агентства, подрядчика, — выдавайте роль, которая нужна именно для этой работы, и убирайте доступ, когда она закончится. Забытый доступ, за который никто не отвечает, — самая частая находка в любой проверке доступа, и её проще всего избежать.

Минимальные привилегии без раздражения

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

По умолчанию всем — viewer, повышайте по запросу. Это стоит одного сообщения в первый раз, когда кому-то понадобится очистить кэш, и означает, что никто не носит с собой доступ, о котором не просил.

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

Оставляйте owner тем, кто отвечает за аккаунт, и реагируйте на изменения в тот же день, когда они происходят. Журнал записывает, что было сделано, а не то, кто всё ещё должен иметь на это право, — это остаётся за вами.

Две функции — это один механизм контроля

Соблазнительно считать журнал функцией безопасности, а роли — администрированием. На деле всё наоборот.

Роли — это предотвращение. Они решают, что вообще возможно, а это единственное, что останавливает случайность до того, как её увидят ваши посетители. Журнал — это обнаружение и подотчётность: он говорит, что было сделано, кем и каким было значение раньше.

По отдельности ни то, ни другое не стоит многого. Роли без записи означают, что вы доверяете границе, которую никогда не можете проверить. Запись без ролей означает, что вы можете идеально описать каждый инцидент и не предотвратить ни одного. Вместе они отвечают на вопрос, который на самом деле звучит после сбоя, — никогда не «что такое CDN», а всегда «кто это изменил и почему у него была такая возможность?»