Аудит безопасности, который не нашёл ни одного общего пароля

Опросник пришёл вложением-таблицей с сорока двумя строками, и одна из них холодно остановила аккаунт-директора: «Опишите, как контролируется доступ к нашим рекламным аккаунтам, включая управление учётными данными и процесс выдачи и отзыва доступа». Для большинства агентств, с которыми этот клиент когда-либо работал, именно этот единственный вопрос был местом, где разговор становился неловким. Это история о другом исходе. В этом agency security audit shared ad account passwords были ровно тем, что проверяющие пошли искать, чтобы изучить, — и их не было. Агентство прошло не за счёт силы своих политик, а за счёт формы своей архитектуры.

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

Опросник: закупки спрашивают, кто может трогать аккаунт

Агентство только что выиграло клиента крупнее обычного — профинансированный потребительский бренд с настоящей функцией безопасности. Прежде чем контракт мог быть подписан, закупки прислали опросник по безопасности поставщика — документ, который раньше предназначался для поставщиков ПО, а теперь падает на любое агентство, трогающее аккаунты и данные регулируемого бренда. В нём были зарыты вопросы, решающие, выглядит ли рекламное агентство профессиональным партнёром или уязвимостью: Кто в вашей команде может получить доступ к нашим рекламным аккаунтам? Как этот доступ выдаётся? Как он отзывается, когда кто-то уходит? Есть ли общие учётные данные? Есть ли запись того, что ваша команда меняла?

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

Почему большинство агентств проваливаются на политике, а не архитектуре

Вот ловушка. Стандартный ответ агентства на «как контролируется доступ» — это набор политик, наслоённых поверх общих учётных данных. Агентство держит логин Meta клиента в менеджере паролей, документирует сид двухфакторной аутентификации, чтобы более одного человека могли пройти запрос 2FA, держит правило, что учётные данные не вставляются в чат, и поддерживает чек-лист увольнения, чтобы при уходе байера кто-то вспомнил ротировать пароль.

Каждый из них — обещание, и каждое обещание — место для провала. Менеджер паролей безопасен лишь настолько, насколько безопасны люди с доступом к записи. Задокументированный сид 2FA сводит на нет весь смысл 2FA в момент, когда покидает аутентификатор. Чек-лист увольнения работает до той одной занятой недели, когда его пропускают. Мы уже писали о том, как общие логины тихо убивают агентство операционно; обзор безопасности — это место, где те же общие логины убивают агентство коммерчески, перед клиентом, на бумаге.

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

Архитектурный ответ: токен System-User, общих логинов для аудита нет

Агентство ответило на вопрос о контроле доступа одним абзацем, и абзац описывал архитектуру вместо политики. Агентство не держит и не передаёт логин Meta клиента. Оно подключает бизнес клиента один раз через токен System-User — учётные данные сервер-сервер, — и из этого токена операционный слой автоматически обнаруживает подключённые рекламные аккаунты по бизнес-идентификатору. Медиабайеры никогда не получают пароль клиента, потому что нет момента, в который байер входит в аккаунт клиента с личными или общими учётными данными. Они работают через собственный внутренний слой доступа агентства.

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

Внутренний RBAC: доступ выдаётся по роли, отзываем, ограничен, залогирован

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

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

Журнал аудита как доказательство: кто что менял, когда

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

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

Прохождение обзора без переписывания ни одной политики доступа

Самой поразительной частью исхода было то, чего агентству не пришлось делать. Оно не писало новую политику контроля доступа под эту работу. Оно не поднимало особый процесс под этого одного клиента, озабоченного безопасностью. Оно не обещало ротировать учётные данные чаще или ограничить, кто держит запись хранилища. Оно ответило на опросник, описав то, как уже работало, — подключение System-User, ролевые места, атрибутированный журнал изменений, — и описание было соответствием.

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

Что «безопасность по архитектуре» выигрывает помимо опросника

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

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

Урок: сильнейший ответ по безопасности — не иметь рискованного, в чём сознаваться

Спрошенный потом, что сделало разницу, операционный лид сказала прямо: агентство прошло обзор безопасности не тем, что было лучше в управлении рискованными вещами. Оно прошло тем, что не имело рискованных вещей для управления. Не было общего пароля для защиты, сида 2FA для контроля, учётных данных для ротации, потому что способ, которым байеры дотягивались до клиентских аккаунтов, никогда не вовлекал ни одного из них.

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