Перейти до контенту
whitead

Виправлення: надмірний доступ Адміністраторів у Google Ads-акаунті

знахідка google ads оновлено 2026.05.20 9 хв читання
// зміст · 7 розділів
  1. Чому це важливо
  2. Як перевірити проблему
  3. Як виправити
  4. Як підтвердити, що виправлення спрацювало
  5. Чек-лист підтвердження — пройди всі п'ять одразу після ревізії
  6. Пов'язані правила та концепції
  7. Джерела

Google Ads-акаунт, у якому п'ять або більше користувачів мають роль Адміністратора, розширює радіус ураження у разі компрометації облікових даних, випадкової мисконфігурації або забутого офбордингу фрилансера. Виправ це до наступного аудит-циклу — це нічого не коштує і прибирає клас інцидентів, які жодне налаштування ставок (bids) уже не відіграє.

Чому це важливо

Google Ads має п'ять рівнів доступу — Адміністратор, Standard, Read only, Email only та Billing — і лише Адміністратор може додавати або видаляти інших користувачів, змінювати налаштування рівня акаунту, з'єднувати/від'єднувати MCC, а також підтверджувати чутливі операції на кшталт завантаження списків Customer Match або зміни конверсійних дій. Принцип найменших привілеїв вимагає видавати рівно ту роль, яка потрібна оператору для роботи, і не більше.

Правило Whitead спрацьовує зі статусом LOW, коли в акаунті є п'ять або більше записів з роллю Адміністратора, бо саме за цим порогом агентські акаунти майже завжди містять щонайменше одне з: фрилансер, якого ніхто не офбордив; стейкхолдер з боку клієнта, якому насправді достатньо Read only; сервісний обліковий запис вендорського інструмента з Адміністратор-доступом «для зручності»; або дубльований логін власника. Жодне з цих не є операційною надзвичайною ситуацією — але кожне з них є відчиненими дверима, і правило виносить їх як один потік гігієни замість розкиданих одноразових задач.

Ця знахідка не змінює CPA, ROAS чи частку показів. Вона змінює ймовірність того, що звіт про інциденти наступного кварталу згадає твій акаунт.

Як перевірити проблему

  1. Відкрий Адміністрування → Доступ і безпека → вкладка Користувачі. Google Ads показує кожного користувача з призначеним рівнем доступу. Порахуй рядки, де у стовпці «Рівень доступу» стоїть Адміністратор.
  2. Для кожного Адміністратора зафіксуй домен email-адреси. Звір зі списком активних співробітників агенції та номінованих стейкхолдерів клієнта. Будь-хто, кого немає у жодному з двох списків, — кандидат на видалення.
  3. Клікни на запис кожного Адміністратора → Редагувати. Google Ads показує мітку часу останньої активності, де вона доступна. Користувачів, неактивних понад 90 днів, треба понизити або видалити незалежно від ролі.
  4. Перевір вкладку Менеджери на тому ж екрані. З'єднаний акаунт-менеджер (MCC) зазвичай надає контроль, еквівалентний Адміністратор-доступу, кільком операторам агенції через ієрархію менеджерів — ці оператори не з'являються на вкладці «Користувачі». Підтверди, що зв'язок з менеджером актуальний, а список користувачів вищого MCC сам по собі чистий.

Правило спрацьовує на простому підрахунку ≥5 Адміністраторів, але ≥5 саме по собі — це м'який сигнал: агентські акаунти середнього сегмента часто легітимно мають керівника з боку агенції + власника з боку клієнта + 2 операторів + 1 вендора = 5 законних Адміністраторів. Розглядай знахідку як таку, що вимагає дії, коли ≥5 Адміністраторів поєднується щонайменше з одним фактором ризику:

  • (a) щонайменше один Адміністратор неактивний понад 90 днів (крок 3), або
  • (b) щонайменше один Адміністратор перебуває поза основним доменом агенції і поза списком номінованих стейкхолдерів клієнта (крок 2), або
  • (c) акаунт має єдиного власника без спільної агентської ієрархії (немає MCC-зв'язку на кроці 4), тобто один скомпрометований Адміністратор = повне захоплення без можливості відновлення «другою парою очей».

Коли ескалувати: ≥5 Адміністраторів + будь-який з (a)/(b)/(c) → запускай виправлення цього тижня. ≥5 Адміністраторів без жодного з (a)/(b)/(c) і чистий склад, який ти впізнаєш → зафіксуй, заплануй документацію політики доступу (крок 5 виправлення), повернись на наступному квартальному ревью.

Як виправити

Заплануй одну робочу сесію на 15 хвилин на акаунт. Якщо видалення стосується користувачів з боку клієнта — зроби це під час короткого дзвінка з основним контактом клієнта, бо несподіване відкликання доступу шкодить довірі навіть тоді, коли воно правильне.

  1. Понизь рутинних редакторів до Standard. Будь-хто, хто будує кампанії, редагує оголошення, керує ключовими словами чи коригує ставки (bids), потребує Standard, а не Адміністратор. У Адміністрування → Доступ і безпека → Користувачі клікни на користувача → Редагувати рівень доступу → обери Standard → Зберегти. Standard зберігає всі щоденні операційні дозволи, але прибирає можливість додавати/видаляти користувачів і змінювати налаштування безпеки рівня акаунту.

  2. Понизь споживачів звітності до Read only. Стейкхолдери, які лише відкривають дашборди або витягують звіти, потребують Read only. Той самий шлях UI; обери Read only. Вони все ще можуть переглядати всі дані й експортувати звіти, але не можуть нічого змінювати.

  3. Видали неактивних користувачів повністю. Для облікових записів, які не входили в систему понад 90 днів, клікни на користувача → Видалити доступ. Якщо доступ знадобиться пізніше — запроси повторно на правильному (нижчому) рівні. Не лишай Адміністратор-роль «про всяк випадок».

  4. Перевір нелюдські записи Адміністраторів. Сервісні облікові записи вендорів інструментів (керування ставками, звітність, атрибуція) майже ніколи не потребують Адміністратора — Standard достатньо для read+write API-операцій, і документація вендора зазвичай це підтверджує. Напиши вендору на підтвердження перед пониженням.

    # Цільовий кінцевий склад для типового агентського акаунту:
- 1× керівник з боку агенції → Адміністратор
- 1× власник з боку клієнта  → Адміністратор (опціонально, часто Standard достатньо)
- 2-4× оператори агенції     → Standard
- 2-5× стейкхолдери          → Read only
- 0× неактивних (>90 днів) будь-якої ролі

  5. Задокументуй політику доступу. Напиши один абзац у runbook акаунту: хто отримує яку роль, хто погоджує нових користувачів, періодичність ревізій доступу (квартальна — типова). Без письмової політики той самий дрейф повториться за 6 місяців.

"Use the access level that gives users only the permissions they need to do their job. Account admins can add, remove, or change access for other users."
— Google Ads Help, About access levels in your Google Ads account (доступ 2026-05-20)

Для ієрархій менеджер-акаунтів еквівалентні рекомендації лежать у About user access levels for your manager account — та сама логіка найменших привілеїв застосовується на рівні MCC.

Як підтвердити, що виправлення спрацювало

Чек-лист підтвердження — пройди всі п'ять одразу після ревізії

Пригадай складений критерій: YAML-правило спрацьовує на ≥5 Адміністраторів, але реальний fail-стан — це ≥5 Адміністраторів І щонайменше один фактор ризику (неактивний >90 днів, Адміністратор поза доменом, або єдиний власник без MCC). Чек-лист нижче закриває і підрахунок, і фактори ризику.

  • Кількість Адміністраторів ≤4 на вкладці Користувачі (поріг правила — ≥5; залишатися на 4 чи нижче знімає YAML-флаг із запасом до наступного дрейфу). Якщо тобі легітимно потрібно ≥5 Адміністраторів — саме пункти 2-5 нижче роблять це безпечним.
  • Email кожного решти Адміністратора належить до активного домену агенції або клієнта — жодних особистих Gmail невідомого походження, жодних сервісних облікових записів вендорів. (Закриває фактор ризику (b).)
  • Жодного користувача, неактивного >90 днів, на будь-якому рівні ролі (Адміністратор, Standard чи Read only). (Закриває фактор ризику (a).)
  • Зв'язок з менеджер-акаунтом у Адміністрування → Доступ і безпека → Менеджери вказує на твій поточний MCC, а не на застарілий. Застарілі лінки MCC — тихий спосіб для сторонніх зберегти контроль; актуальний MCC також закриває фактор ризику (c), бо акаунт перестає бути по факту single-owner.
  • Письмова політика доступу додана до runbook акаунту з названим власником і періодичністю ревізій.

Якщо всі п'ять проходять, перезапусти аудит — правило excessive_admin_access переходить зі стану warning у passed (коли кількість ≤4), або лишається у warning, але його безпечно закрити як known-good конфігурацію (коли кількість залишається ≥5 з нульовими факторами ризику і задокументованою політикою).

Methodology note. Правило excessive_admin_access у Whitead — це single-flag count-чек, який обчислюється на рівні акаунту поверх джерела account.users. Деталь реалізації (за audit_skills/core/rules/excessive_admin_access.yaml): фільтр перед агрегацією access_role: ADMIN обмежує популяцію лише записами Адміністраторів, потім aggregation: count порівнює результат із порогом (статус warning при >=5, passed при <5). Без фільтра підрахунок включав би записи Standard та Read only, і правило би спрацьовувало на нешкідливих мульти-стейкхолдерних конфігураціях. min_data_points перевизначено на 1 (дефолт 5), щоб маленькі команди з 1-4 Адміністраторами розв'язувалися в passed замість insufficient_data. Правило глобальне (applicable_geo: [global]), виконується на всіх типах кампаній, не потребує історії (requires_history_days: 0) і застосовується лише до стандартних акаунтів (applicable_account_kind: [standard]) — менеджер-акаунти мають власну модель доступу й оцінюються окремо. Severity low за дизайном: це гігієна безпеки, а не ризик доставки оголошень, і Whitead подає її як інформаційне попередження, а не блокер ремедіації.

Пов'язані правила та концепції

  • Customer Match — найчутливіша операція, яку можуть виконати користувачі з роллю Адміністратора; жорсткий контроль Адміністраторів — це upstream-захист для governance списків першої сторони.
  • Conversion tracking — Адміністратори можуть редагувати конверсійні дії, тому надмірна кількість Адміністраторів також розширює поверхню для випадкового дрейфу конфігурації конверсій.
  • Серверний GTM для Google Ads — коли вимірювання переїжджає на серверну сторону, інвентар «хто може змінити кінцеву точку конверсій» виходить за межі самого Google Ads, і політика доступу має слідувати за ним.
  • Виправлення: відсутнє відстеження конверсій — суміжна governance-знахідка, коли дрейф доступу корелює з мисконфігурованим відстеженням.

Джерела

// чи було корисно?
// анонімно · не зберігаємо персональні дані
← Назад до Wiki