Права доступа для бухгалтера, маркетолога и стажёра: кому что открывать

MAATRIX

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

Бухгалтер: биллинг и платежи, а не инфраструктура

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

• Личный аккаунт в панели биллинга хостинга или облачного провайдера с ролью «только финансы» — большинство провайдеров умеют выдавать отдельного пользователя, который видит счета, историю платежей и закрывающие документы, но не видит серверы, домены или настройки инфраструктуры.
• Доступ к платёжному аккаунту (эквайринг, платёжный шлюз, кабинет банка для бизнеса) — персональная учётка с ограниченной ролью «просмотр и выгрузка», а не общий логин от корпоративного счёта на нескольких человек.
• Доступ к учётной системе (1С, облачная бухгалтерия, ЭДО) — основной рабочий инструмент бухгалтера, и туда доступ обычно и так организован отдельно от инфраструктуры компании.
• Read-only доступ к первичной документации, если она хранится на общем сервере, — папка со сканами договоров, актов и накладных, куда бухгалтеру нужно право читать и класть файлы, но не право менять права доступа или удалять чужие документы.

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

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

Маркетолог: аналитика и рекламные кабинеты, а не сервер

Маркетологу для работы нужны данные о трафике, конверсиях и эффективности кампаний — и доступ к инструментам, которые эти данные показывают. Инфраструктура, на которой всё это крутится, ему в 99% случаев не нужна вообще.

Рабочий набор для маркетолога:

• Доступ к аналитическим дашбордам (Яндекс.Метрика, Google Analytics, self-hosted Matomo) — с ролью, которая позволяет смотреть отчёты и настраивать цели, но не даёт прав администратора счётчика.
• Доступ к рекламным кабинетам (Яндекс Директ, кабинеты соцсетей) — персональный логин с правами на кампании, но без доступа к платёжным данным аккаунта, если оплатой занимается бухгалтерия.
• Read-only доступ к контенту сайта через CMS, если нужно смотреть или редактировать посадочные страницы, — на уровне CMS-панели (WordPress, Tilda, самописная админка), а не файловой системы сервера через SFTP или SSH.
• Доступ к трекеру и UTM-разметке — если в компании стоит собственный трекер кампаний (например, поднятый на своём сервере вместе с аналитикой), маркетологу нужен логин в само приложение трекера, а не сетевой доступ к серверу, на котором оно работает.

Чего маркетологу почти никогда не нужно: SSH-доступ к серверу, на котором крутится сайт или аналитика, права на изменение DNS-записей домена, доступ к продакшн-базе данных напрямую (для сложных выгрузок обычно хватает read-only представлений или экспорта из самой аналитической системы, а не прямого SQL-запроса к боевой базе), права администратора хостинг-аккаунта.

Частая ошибка — выдавать маркетологу доступ к серверу «чтобы сам поставил пиксель или скрипт трекинга». Решается иначе: через менеджер тегов (Google Tag Manager, Яндекс Менеджер Тегов), где маркетолог сам добавляет и меняет скрипты через собственный интерфейс без доступа к коду сайта, либо через тикет разработчику на добавление конкретного фрагмента кода — без выдачи доступа к серверу, который потом придётся отзывать и о котором придётся помнить при аудите.

Стажёр: ограниченный доступ на тестовом контуре

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

Минимальный доступ для стажёра:

• Отдельный именной аккаунт на staging-сервере, физически изолированном от продакшена, — не тот же сервер с ограничением прав, а отдельная среда, куда стажёр не может дотянуться до реальных пользовательских данных, даже если ошибётся в правах или командах.
• Доступ к репозиторию с ограничением на ветки — право пушить в свои feature-ветки и открывать pull request, но без прав на прямой push в основную ветку и без прав администратора репозитория (управление вебхуками, secrets, настройками CI/CD).
• Ограниченный sudo на staging, если стажёр действительно работает с сервером, а не только с кодом:

# /etc/sudoers.d/intern-staging
ivan_intern ALL=(root) NOPASSWD: /usr/bin/systemctl restart myapp-staging
ivan_intern ALL=(root) NOPASSWD: /usr/bin/journalctl -u myapp-staging --since "1 hour ago"

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

Отдельно стоит зафиксировать срок действия доступа сразу при выдаче, а не полагаться на то, что кто-то вспомнит его закрыть в последний день стажировки:

# аккаунт автоматически блокируется через 90 дней, если не продлить явно
sudo useradd -m -s /bin/bash -e $(date -d "+90 days" +%Y-%m-%d) ivan_intern

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

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

Три роли рядом: что дать, а что нет

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

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

Как технически ограничить доступ, если сервер всё же нужен

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

Read-only роль в базе данных, если маркетологу или аналитику нужны сырые данные, а не только готовые отчёты из дашборда:

CREATE ROLE marketing_ro WITH LOGIN PASSWORD 'сгенерированный-пароль';
GRANT CONNECT ON DATABASE analytics TO marketing_ro;
GRANT USAGE ON SCHEMA public TO marketing_ro;
GRANT SELECT ON ALL TABLES IN SCHEMA public TO marketing_ro;
REVOKE CREATE, INSERT, UPDATE, DELETE ON ALL TABLES IN SCHEMA public FROM marketing_ro;

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

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

Группы файловой системы вместо персональных прав на каждый файл, если нужно дать доступ к конкретной папке (например, бухгалтеру — к папке со сканами документов):

groupadd finance-docs
usermod -aG finance-docs anna_buh
chown -R root:finance-docs /srv/documents/finance
chmod -R 2750 /srv/documents/finance

Бит 2 в правах (setgid) гарантирует, что новые файлы в папке наследуют группу finance-docs, а не создаются с группой того, кто их положил, — иначе через месяц в папке окажутся файлы вперемешку с разными владельцами и правами.

Оффбординг: что отозвать у бухгалтера, маркетолога и стажёра

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

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

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

При уходе стажёра: удаляется аккаунт на staging (или ждать истечения срока, если он был выставлен заранее через -e), отзываются права в репозитории, закрываются открытые pull request или явно передаются другому разработчику. Если стажёр параллельно был добавлен в общие рабочие чаты и календари, это тоже стоит закрыть — не доступ к инфраструктуре, но тот же принцип «доступ закрывается день в день, а не когда вспомнят».

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

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