Подключение нового сотрудника к инфраструктуре: регламент на один день

MAATRIX

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

Почему «дать всё, потом разберёмся» — это не экономия времени, а долг

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

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

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

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

Роль вместо человека: готовим чек-лист доступов заранее

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

Для типовой инфраструктуры компании, арендующей серверы под продакшен, стейджинг и внутренние сервисы, роли обычно выглядят так:

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

Чек-лист под роль оформляется как обычный документ или issue-темплейт в трекере — с конкретными пунктами, которые можно отмечать:

Чек-лист: подключение Backend-разработчика
[ ] Личная учётная запись в SSO / центральной директории (LDAP, Keycloak и т.п.)
[ ] SSH-ключ сотрудника добавлен в группу deploy на staging-хостах
[ ] Доступ к staging PostgreSQL: роль app_readwrite, БД project_staging
[ ] VPN-профиль (WireGuard) в сегмент staging, ACL по группе backend
[ ] Приглашение в приватный репозиторий инфраструктурных конфигов (read-only)
[ ] Аккаунт в системе логирования / мониторинга: staging-дашборды
[ ] Обзорный документ по инфраструктуре — ссылка отправлена, подтверждено прочтение
[ ] Проверка: сотрудник подключился по SSH под своим ключом и выполнил тестовую команду

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

Персональная учётная запись, а не общий пароль

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

На Linux-сервере это выглядит буднично:

# создаём пользователя без пароля, вход только по ключу
sudo adduser --disabled-password --gecos "" ivan.petrov
sudo usermod -aG deploy ivan.petrov

# кладём публичный ключ сотрудника (не пароль, не приватный ключ из общего чата)
sudo mkdir -p /home/ivan.petrov/.ssh
sudo tee /home/ivan.petrov/.ssh/authorized_keys < ivan_petrov.pub
sudo chown -R ivan.petrov:ivan.petrov /home/ivan.petrov/.ssh
sudo chmod 700 /home/ivan.petrov/.ssh
sudo chmod 600 /home/ivan.petrov/.ssh/authorized_keys

Если серверов больше пяти-семи, вручную заводить пользователя на каждом — уже неудобно и склонно к ошибкам: где-то забыли, где-то ключ устарел. С этого масштаба обычно переходят на централизованное управление — LDAP/FreeIPA с SSSD на хостах или связку SSO (Keycloak, Authentik) плюс sshd с проверкой через AuthorizedKeysCommand, чтобы ключи подтягивались из одного источника, а не копировались на каждый сервер отдельно. Если нужно освежить механику самого входа по ключу — это отдельная тема, не специфичная для найма, и она не входит в чек-лист подключения как таковой.

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

CREATE ROLE ivan_petrov LOGIN PASSWORD 'сгенерированный-пароль' VALID UNTIL '2026-12-01';
GRANT app_readwrite TO ivan_petrov;

Дата истечения (VALID UNTIL) — не обязательный, но полезный элемент: она заставляет либо продлить доступ осознанно, либо он сам перестанет работать, вместо того чтобы висеть годами без пересмотра.

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

Обзорный документ: что нужно знать за 20 минут, а не за неделю

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

Разумный минимум для такого документа:

• Схема окружений: чем отличается staging от production — адреса, домены, как понять, в каком окружении находишься прямо сейчас (самая частая причина случайных инцидентов — спутать окружение).
• Карта серверов: короткая таблица «имя хоста — роль — что на нём крутится — кто отвечает», без детального разбора конфигурации каждого.
• Как подключаться: команда для SSH через бастион или VPN-профиль, куда идти за ключом, если что-то не работает.
• Где смотреть логи и метрики: ссылки на дашборды, а не описание архитектуры системы логирования.
• Кто есть кто: к кому идти с вопросом по базе данных, а к кому — по сети, чтобы не писать в общий чат и не ждать ответа несколько часов.
• Ссылка на регламенты: что можно менять самостоятельно, а что требует подтверждения (деплой в продакшен, изменения в firewall, доступ к секретам).

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

Пошаговый план на первый рабочий день

Собранный чек-лист и готовый обзорный документ превращают подключение в последовательность конкретных шагов, а не в импровизацию:

1. За день до выхода. HR или нанимающий менеджер сообщает роль нового сотрудника ответственному за инфраструктуру. Ответственный поднимает шаблон чек-листа под эту роль — без ожидания, что человек уже вышел.
2. Утро первого дня. Заводится персональная учётная запись в центральной директории или вручную на нужных хостах. Генерируется или принимается SSH-ключ сотрудника (публичный — от него, приватный не передаётся никому).
3. Выдача доступов по чек-листу. Каждый пункт роли выполняется и отмечается: SSH-группа, роль в базе, VPN-профиль, доступ к репозиторию, аккаунт в мониторинге. Ничего сверх списка не добавляется «про запас».
4. Отправка обзорного документа. Ссылка на карту инфраструктуры уходит вместе с данными для первого входа, а не после того, как человек уже запутался и начал спрашивать в чате.
5. Проверка подключения. Сотрудник (в идеале вместе с ответственным на коротком созвоне) выполняет тестовое подключение — SSH на стейджинг, коннект к VPN, запрос к тестовой базе. Это ловит опечатки в ключах и неправильные ACL сразу, а не через три дня.
6. Фиксация в реестре доступов. Кто, когда, к чему и по какой роли получил доступ — записывается в общий реестр, чтобы при следующей ревизии не восстанавливать историю по памяти. Такая ревизия обычно проводится по регулярному циклу — например, по схеме из материала про ревизию доступов раз в квартал, и запись о выдаче доступа в день найма — источник данных, с которым ревизия потом сверяется.

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

Почему это должно быть регламентом, а не разовым усилием

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

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

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

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

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