Карта доступов: кто и куда в вашей компании может зайти прямо сейчас

MAATRIX

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

Почему «мы примерно знаем, у кого какой доступ» — это не знание

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

Доступы накапливаются медленно и незаметно, потому что выдать их — дело одной минуты, а вспомнить про их отзыв — нет. За год-два в компании из десяти человек типично происходит вот что: подрядчик, который делал редизайн сайта три месяца, получил доступ в панель хостинга, потому что «так проще, чем пересылать файлы» — проект закрылся, доступ остался. Сотрудник сменил роль с разработки на продажи, но его аккаунт в репозитории с правом push в прод так и не тронули. Стажёр, который тестировал фичу два месяца назад, до сих пор состоит в организации на GitHub с правами, выданными на время задачи. Каждый случай в отдельности — мелочь. Все вместе они означают, что реальное число людей с доступом к критичной системе почти всегда больше, чем список тех, кто, по общему мнению, «должен там быть».

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

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

Две проекции одной карты: по системам и по людям

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

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

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

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

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

Как собрать первую версию карты: проверять, а не вспоминать

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

1. Составьте список критичных систем. Не всё подряд, а то, потеря контроля над чем реально бьёт по бизнесу: продакшен-сервер(ы), база данных, панель хостинга и DNS-регистратора, платёжные аккаунты, репозиторий кода, CRM, почта компании, VPN. Пяти-десяти строк обычно достаточно для небольшой команды — список из пятидесяти систем на старте только тормозит и никогда не будет доведён до конца.
2. По каждой системе зайдите в раздел «Пользователи» или «Команда» и выпишите список руками, а не по памяти. Почти в каждой панели хостинга, CRM, репозитории и платёжном сервисе такой раздел есть — задача не в том, чтобы найти способ узнать список, а в том, чтобы реально туда зайти вместо того, чтобы полагаться на предположение «там же только мы трое».

# GitHub: список участников организации
gh api orgs/YOUR_ORG/members --paginate | jq -r '.[].login'

# Сервер: пользователи с sudo и ключи в authorized_keys
getent group sudo
for u in $(cut -d: -f1 /etc/passwd); do
  home=$(getent passwd "$u" | cut -d: -f6)
  [ -s "$home/.ssh/authorized_keys" ] && echo "$u: $(wc -l < "$home/.ssh/authorized_keys") ключ(ей)"
done

Для панелей без API или CLI — глазами, через интерфейс. Это не быстрее, но результат так же надёжен: список из интерфейса — факт, список по памяти — гипотеза.

1. Для каждого имени отметьте, актуален ли этот человек сейчас — работает ли ещё в компании, действует ли договор подряда, продолжается ли задача, ради которой выдавался доступ. Здесь обычно всплывают первые несоответствия.
2. Соберите обратную проекцию — по каждому человеку из списка сотрудников и подрядчиков пройдитесь по всем системам и отметьте, где у него есть доступ. Медленнее первого шага, зато становится видно, у кого прав заметно больше, чем нужно для его роли.
3. Зафиксируйте обе таблицы с датой проверки. Без даты через полгода никто не сможет отличить свежую карту от той, что была верна год назад и с тех пор ни разу не сверялась с реальностью.

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

Формат: простая таблица лучше сложной системы, которую никто не ведёт

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

Работает обратное: простая таблица — Google Sheets, Excel, CSV в приватном репозитории, даже страница в Notion — с двумя листами или двумя блоками (по системам и по людям), которую реально открывают и правят при каждом изменении. Минимальный набор столбцов для проекции по системам:

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

Карта не заменяет разграничение прав, а показывает его текущее состояние

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

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

Регулярность: обновлять сразу, а не откладывать до большого аудита

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

Работающее правило простое по формулировке: карта обновляется в момент события, а не откладывается до следующей проверки. События, при которых строка в карте меняется сразу, а не «когда будет время»:

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

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

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

Частые вопросы