Принцип наименьших привилегий для небольших команд в GitHub, GitLab и облаке

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

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

Так происходит потому, что небольшие команды работают на доверии и по памяти. Люди помнят, кому доверяют, но не всегда помнят, какие права они выдали во время релиза, найма или инцидента. Доступ растёт по одному быстрому фикс‑у за раз.

Старые аккаунты добавляют ещё один уровень риска. Подрядчики заканчивают проект. Сотрудники переходят на другую роль. Никто не убирает старые права, потому что ничего не выглядит срочным. Эти аккаунты сидят в системе до ошибки, утерянного ноутбука или повторного использования пароля — и тогда из них вырастает реальная проблема.

Совместные аккаунты владельцев ещё хуже. Один логин с широкими правами может обойти те контрольные механизмы, которые вы думаете, что настроили в GitHub, GitLab или облачной консоли. Если несколько человек знают пароль, ваша история аудита уже нарушена. Когда что‑то меняется, вы не сможете с уверенностью сказать, кто это сделал.

Большинство команд также думают, что проблема сложнее, чем есть на самом деле. Обычно несколько широких групп создают большую часть риска. Люди, которые могут менять настройки репозитория, удалять проекты, поворачивать секреты, управлять биллингом или открывать продакшен‑системы, имеют гораздо большее значение, чем все, у кого обычный ежедневный доступ.

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

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

Начните с аккаунтов, которые могут навредить быстро

Первый проход должен фокусироваться на уроне, а не на идеальной модели ролей. В GitHub, GitLab и облачных консолях небольшое число аккаунтов может удалить код, заблокировать команду, раскрыть секреты или накопить огромный счёт за один плохой день.

Сделайте один короткий список и перечислите каждый аккаунт с широким контролем. Это обычно владельцы организации, владельцы групп, админы по выставлению счетов, корневые облачные пользователи и любые аварийные или break‑glass аккаунты. Если вы сделаете хорошо только этот шаг, вы уже сократите много риска.

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

Команды часто забывают про деньги. Аккаунту не нужны полные админ‑права, чтобы причинить боль, если он может создавать дорогие инстансы, повышать лимиты сервиса или менять настройки биллинга. Обращайтесь с такими аккаунтами так же серьёзно, как с тем, кто может выключить продакшен.

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

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

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

Наметьте реальные группы и инструменты

Большинство небольших команд не управляют доступом в одном месте. У них есть GitHub‑команды, GitLab‑группы, облачные IAM‑группы, несколько прямых админ‑грантов и старые исключения, оставшиеся после завершённого проекта. Если вы полагаетесь на память, вы пропустите доступ, который создаёт наибольшую проблему.

Начните с одного простого листа. Запишите каждую группу, роль и прямой грант, даже если имена запутаны. Сейчас вы не исправляете названия — вы пытаетесь увидеть, кто что может делать прямо сейчас.

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

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

Этот лист быстро показывает пересечения. Один человек может быть в GitHub‑админской команде, в GitLab‑maintainer‑группе и в облачной группе с доступом к продакшену. Разные имена могут давать почти одинаковые полномочия. Когда вы выстраиваете их рядом, дублирующий доступ перестаёт выглядеть нормально.

Не застревайте на ярлыках. Если одна группа называется "eng-core", а другая — "platform‑admin‑old", оставьте чистку на потом. Запишите, что каждая из них реально делает. Реальный доступ важнее аккуратных названий.

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

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

План чистки на 3 недели

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

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

На 1‑й неделе заморозьте новые админ‑гранты, если только менеджер их не одобрит. Затем удалите доступ у тех, кто больше не должен быть в системе: бывших сотрудников, подрядчиков, которые закончили несколько месяцев назад, и бот‑аккаунтов, которых никто не может объяснить. Эта часть обычно идёт быстро, потому что плохие случаи легко заметить.

На 2‑й неделе замените широкие права простыми группами по работе. Посмотрите, что люди реально делают каждый день, и переведите их в группы вроде engineering, deployers, finance или support. Разработчику редко нужны права владельца в GitHub или GitLab, и большинству людей не нужен полный доступ к облачной консоли. Если человек совмещает роли, дайте ему две узкие группы вместо одной огромной админ‑роли.

На 3‑й неделе протестируйте реальную работу и зафиксируйте результаты. Попросите несколько человек выполнить обычные задачи: смерджить код, посмотреть логи, перезапустить сервис, проверить биллинг или обновить секреты, если это часть их работы. Исправляйте поломки в тот же день. Когда группы выдерживают в реальной эксплуатации, задокументируйте окончательный список, кто утверждает изменения и какие роли остаются редкими.

Держите список групп коротким. Если в конце 3‑й недели у вас осталось пятнадцать слегка разных ролей для десяти человек — вы, вероятно, восстановили тот же беспорядок под красивыми названиями.

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

Роли GitHub и GitLab, которые стоит урезать в первую очередь

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

Начните с владения. В GitHub оставьте Organization Owner у двух‑трёх человек, которые занимаются биллингом, восстановлением аккаунта, SSO и настройками безопасности. В GitLab сделайте то же самое с Group Owner. Если шесть человек могут восстановить аккаунт, шесть человек могут и заблокировать всех остальных.

Затем посмотрите на админов репозиториев и проектов. Многие разработчики просят админские права просто чтобы убрать трения, а не потому что они ежедневно ими пользуются. Чаще всего им достаточно write‑прав для пуша кода, открытия PR/MR, мержа и работы с issue. Оставляйте GitHub Admin или GitLab Maintainer людям, которые реально управляют защитой веток, раннерами, интеграциями и настройками проекта.

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

Хороший первый проход прост: держите роли владельцев в маленькой команде восстановления, понижайте разработчиков до write или developer, если они не управляют настройками, давайте подрядчикам доступ к одному проекту за раз и удаляйте неактивных пользователей до обсуждения крайних случаев.

После каждой смены роли проверьте учётные данные, которые сидят вне списка ролей. Команды часто пропускают реальный риск здесь. Человек может потерять админ‑права, но при этом оставить персональный access token с широкими скоупами, старый deploy‑ключ или CI‑переменные, которые он создал месяцами ранее.

Проверьте персональные access tokens и их скоупы, deploy‑ключи и машинных пользователей, связанные со старыми репозиториями, CI‑переменные, содержащие продакшен‑секреты, и любые интеграции приложений, вебхуки или раннеры, добавленные бывшими админами.

Защищённые ветки и пути деплоя важны больше, чем думают многие. Если кто‑то может менять правила веток, редактировать release‑воркфлоу или подменять секрет в CI, он всё ещё может причинить реальный вред без полного права владельца. Настройки и секреты важны не меньше, чем список участников.

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

Какие облачные права урезать в первую очередь

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

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

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

Доступ к продакшену должен иметь меньшая группа, чем часто думают команды. Если человек не находится на дежурстве и не занимается живыми инцидентами, ему, вероятно, не нужен доступ на запись к продакшен‑ресурсам.

Доступ разработчика должен фокусироваться на сервисах, которые они строят и тестируют. Давайте им права в dev или staging‑проекте, а в продакшен добавляйте лишь ограниченный доступ, если их ежедневная работа действительно этого требует.

Несколько сокращений обычно важны в первую очередь. Уберите полные админ‑роли у общих групп. Отнимите биллинг‑админство у инженерных групп. Замените права записи к логам и метрикам на доступ только для чтения. Ограничьте управление секретами и IAM очень небольшой группой людей. Держите права на удаление продакшена у минимально практической группы.

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

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

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

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

Простой пример для команды из 10 человек

Команде из 10 человек не нужна идеальная модель доступа. Ей нужна здравомыслящая.

Основатель сохраняет права владельца в GitHub, GitLab и основном облачном аккаунте. Это широко, но один человек должен держать контроль над биллингом, правами собственности, аварийным восстановлением и изменениями аккаунта. Реальная ошибка — давать те же права трём‑четырём другим, просто потому что так удобнее.

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

Фриланс‑инфраструктурный подрядчик получает доступ к продакшену на месяц во время миграции. Команда записывает дату окончания в первый же день, ограничивает доступ системами, задействованными в проекте, и удаляет доступ по завершении работы. Временный доступ работает только если кто‑то отвечает за очистку.

Все остальные переходят в узкие группы. Разработчики получают доступ только к тем репозиториям, в которых они работают. QA может смотреть пайплайны и тестовые окружения, но не менять настройки организации. Support может читать логи и дашборды, но не деплоить. Дизайнеры и продуктовая команда остаются вне облачной консоли.

Такой набор обычно достаточно быстро снижает риск, не замедляя команду.

Ошибки, которые замедляют чистку

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

Ещё одна распространённая ошибка — копирование корпоративной IAM‑модели в очень маленькую команду. Шести сотрудникам не нужно пятьдесят ролей, три уровня одобрения и схема нейминга, которую никто не помнит. Люди перестают пользоваться моделью и снова просят широкие права, потому что простой путь исчез.

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

Сервисные аккаунты тоже создают проблемы, когда их никто не документирует. Бот‑токен, созданный год назад, может всё ещё иметь права владельца в GitHub, GitLab или облаке, и никто не знает, от чего это зависит. Так команды думают, что убрали админ‑права, в то время как скрытая лазейка всё ещё существует.

Пара привычек помогает двигаться вперёд. Уменьшайте широкий доступ маленькими шагами, а не одной гигантской перестройкой. Записывайте каждый сервисный аккаунт, что он делает и кто его владеет. Держите роли простыми, чтобы команда могла объяснить их вслух. Тестируйте одно изменение и подтверждайте, что сборки, деплои и алерты работают.

Самый быстрый способ потерять поддержку — отрезать доступ без плана отката. Если деплой упадёт и никто не сможет его восстановить, люди сразу попросят вернуть старые админ‑права. Держите короткий план отката: кто может дать временный доступ, на какой срок и как его убрать после задачи.

Этот подход менее изящен, чем полная перестройка IAM. Зато он быстрее выводит рискованные права из системы — а в этом суть.

15‑минутный еженедельный чеклист

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

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

Делайте одну и ту же последовательность каждую неделю. Откройте админ‑страницы GitHub, GitLab и вашей облачной консоли. Посмотрите, у кого есть права владельца, админа, биллинга или уровня аккаунта. Уберите доступ у тех, кто ушёл, приостановлен или завершил контракт. Просканируйте персональные access tokens, app‑токены и SSH‑ключи на предмет старых дат или неизвестных имён. И задайте один простой вопрос для каждого человека с широким доступом: нужен ли ему этот доступ прямо сейчас?

Старые аккаунты подрядчиков — часто самое лёгкое достижение. Дизайнер, который помогал две недели, может всё ещё сидеть в org GitHub. Фриланс‑инженер может иметь рабочий GitLab‑токен. Кто‑то из финансов может всё ещё держать облачный биллинг‑доступ после разовой задачи. Это небольшие промахи, но они накапливаются.

Установите простое правило для устаревших учётных данных. Если токен или SSH‑ключ не проверялся последние 30–60 дней — посмотрите на него. Если никто не может объяснить, зачем он нужен — удалите и наблюдайте за поломками. Чаще всего ничего не происходит.

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

Небольшие регулярные сокращения работают лучше, чем большая чистка, которая так и не назначается.