Разграничение доступов в команде из трёх человек без лишней бюрократии

MAATRIX

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

Почему «у всех есть все пароли» — риск даже для команды из трёх

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

Ошибка любого из трёх задевает всё сразу. Если у каждого есть root на сервере, доступ к базе данных, ключи от хостинга и права владельца в панели домена, то опечатка в консоли или неудачный rm -rf может произойти у любого из трёх — и последствия будут одинаково катастрофическими независимо от того, в какой части системы человек на самом деле работает. Тот, кто занимается только фронтендом, физически не должен иметь возможности уронить продовую базу — но при общем доступе он её имеет, просто потому что пароль у него тоже есть.

Нет ясности «кто что менял», когда что-то ломается. С общими учётками при разборе инцидента вы получаете один и тот же ответ на вопрос «кто заходил на сервер вчера вечером» — «кто-то из нас». Логи авторизации показывают один и тот же аккаунт, история команд в шелле общая. Расследование превращается в опрос по памяти вместо чтения логов, а память работает избирательно, особенно когда вспоминать нужно про собственную ошибку.

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

Почему сложная ролевая модель тоже не подходит

Обратная крайность встречается реже, но не менее вредна — обычно после того, как кто-то из команды почитал про IAM-политики AWS, RBAC в Kubernetes или матрицы прав в духе ISO 27001 и решил применить это к инфраструктуре из двух серверов и одного продакшена.

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

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

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

Средний путь: разделение по зоне ответственности, а не по ролям

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

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

Про то, как технически организовать доступ к серверу без раздачи root каждому, есть отдельный пошаговый разбор — «Как раздать доступ команде без выдачи root»: именные пользователи, sudo с ограничением на конкретные команды, вход по личному SSH-ключу. Для команды из трёх это буквально три useradd и настройка /etc/sudoers.d/ под каждого — не больше десяти минут, а не отдельный проект.

Персональные учётки вместо общих

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

На практике это означает несколько конкретных вещей:

• На сервере — у каждого свой пользователь Linux, вход по личному SSH-ключу, а не по общему паролю. Работа от root — только через sudo, а не прямым логином под root.

sudo useradd -m -s /bin/bash ivan
sudo mkdir -p /home/ivan/.ssh
sudo cp ivan_id_ed25519.pub /home/ivan/.ssh/authorized_keys
sudo chown -R ivan:ivan /home/ivan/.ssh
sudo chmod 700 /home/ivan/.ssh && sudo chmod 600 /home/ivan/.ssh/authorized_keys
sudo usermod -aG sudo ivan

• В панели хостинга, у облачного провайдера, в Git-репозитории — отдельный аккаунт на каждого человека, а не один с общим паролем на троих. Большинство провайдеров поддерживают приглашение отдельных участников с собственным логином даже на минимальных тарифах — это базовая функция, а не корпоративная, ей стоит пользоваться с первого дня.
• В менеджере паролей — общие секреты, которые всё-таки нужны нескольким людям (например, единственный API-ключ платёжного провайдера), хранятся не в общем текстовом файле или чате, а в персональных хранилищах с отдельным сейфом для по-настоящему общих секретов. Даже минимальная настройка вроде самостоятельно поднятого Vaultwarden с персональными аккаунтами для троих закрывает большую часть риска — дальше вопрос дисциплины, а не технологии.

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

Простое журналирование — без сложной системы аудита

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

• Системные логи от персональных учёток. Раз каждый заходит под своим пользователем, last и история команд sudo уже показывают, кто и когда заходил на сервер и что выполнял. Этого достаточно, чтобы восстановить последовательность действий при разборе инцидента.

last -n 30                                   # кто и когда заходил
sudo grep sudo /var/log/auth.log | tail -50  # что выполнялось через sudo

• Журнал активности у облачного провайдера или хостинга. У большинства провайдеров есть встроенный лог действий в аккаунте (кто менял DNS-записи, перезапускал сервер, менял платёжные данные) — включить его обычно вопрос одной галочки в настройках.
• История коммитов. Git журналирует, кто и что менял в коде, если каждый коммитит под своим именем, а не под общим сервисным аккаунтом.
• Лог доступа к общим секретам в менеджере паролей. Vaultwarden или Bitwarden ведёт историю, кто и когда открывал запись в общем сейфе — полезно, если секрет утёк и нужно понять периметр.

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

Ревизия доступов: правило «сразу проверяем и обновляем»

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

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

Когда человек уходит: доступы отзываются в тот же день, а лучше в тот же час — SSH-ключ убирается из authorized_keys, аккаунт в панели хостинга деактивируется, участник удаляется из репозитория. По-настоящему общие секреты (например, единственный API-ключ платёжного провайдера, если он не был привязан к персональному аккаунту) меняются — но именно они, а не вообще все пароли от всего, как при общих учётках. Отдельно стоит проверить, не остался ли у ушедшего доступ куда-то по забывчивости — например, в облачном провайдере он мог быть добавлен как отдельный пользователь IAM, а не просто как участник команды.

Подробный чек-лист по порядку действий в первые минуты после ухода человека есть в статье «Доступы уволенного сотрудника: что отозвать в первые 30 минут» — для команды из трёх список получается короче: обычно не больше пяти-семи систем.

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

Что важнее полноты модели: простота и реальное соблюдение

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

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

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

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