Проект может остановиться не из-за сложности 1С, а из-за простого вопроса: у кого попросить доступ, какие права нужны и кто отвечает за безопасность. Разбираем, как подготовить доступы подрядчику без хаоса и лишних рисков.
Краткий вывод
- Доступы надо готовить до старта работ, а не после первого созвона с разработчиком.
- Для проекта по 1С обычно нужны не только права в базе, но и VPN/RDP, сервер, SQL, файловые каталоги, регламентные задания, обмены и внешние кабинеты.
- Безопасная модель — временные персональные учётные записи, минимальные права, журнал действий и понятный порядок отзыва.
- Главная управленческая задача — найти владельцев доступов: кто выдаёт, кто согласует, кто контролирует и кто отключает после завершения.
Почему проекты тормозят на доступах
На старте проекта часто кажется, что достаточно «дать доступ к 1С». Но уже в первые дни выясняется, что для диагностики нужны права администратора 1С, доступ к серверу, SQL или PostgreSQL, каталоги обменов, сертификаты, личный кабинет провайдера, VPN, тестовая база и контакт человека, который может подтвердить действия.
Если эти вопросы не разобраны заранее, проект теряет дни: подрядчик ждёт доступ, ИТ-специалист ищет пароль, бухгалтерия не понимает, что можно показывать, служба безопасности блокирует заявку, а руководитель видит только одно — работа стоит.
Практический вывод: доступы — это часть проектирования, а не техническая мелочь. Их нужно описать так же явно, как сроки, задачи и результат проекта.
Где возникают риски
Общие логины
Когда несколько людей работают под одной учётной записью, невозможно понять, кто изменил настройку, удалил файл, запустил обработку или подключился к серверу. Это удобно на старте, но опасно при любом инциденте.
Лишние права
Администраторские права «на всякий случай» ускоряют старт, но повышают риск случайных изменений в рабочей базе, конфигурации, регламентных заданиях и инфраструктуре.
Нет отзыва доступа
Проект закончился, подрядчик ушёл, а VPN, RDP или учётная запись в 1С продолжают работать месяцами. Это типовой риск для компаний, где нет реестра внешних доступов.
Работа в боевой базе без тестового контура
Если доработки, диагностика или загрузки выполняются сразу в рабочей базе, ошибка может затронуть документы, обмены, права пользователей и отчётность.
Нет владельца со стороны бизнеса
Технический доступ может выдать администратор, но только бизнес-владелец понимает, какие данные можно показывать, какие операции допустимы и где нельзя рисковать.
Что проверить перед стартом
- Кто владелец проекта со стороны бизнеса и кто может согласовывать доступы.
- Какая база 1С используется для работ: рабочая, копия, тестовый контур или отдельная песочница.
- Нужны ли права администратора 1С, доступ к конфигуратору, расширениям, внешним обработкам и журналу регистрации.
- Нужен ли доступ к серверу 1С, SQL/PostgreSQL, файловым каталогам, резервным копиям и регламентным заданиям.
- Есть ли VPN/RDP или другой защищённый способ подключения с персональной учётной записью.
- Какие внешние сервисы участвуют: банк, ЭДО, маркетплейс, сайт, B2B-портал, API-провайдер, кассы, маркировка.
- Кто и когда отключит доступ после завершения работ или паузы в проекте.
- Есть ли резервная копия перед изменениями и кто проверял возможность восстановления.
- Где фиксируются действия подрядчика: заявка, журнал, тикет, описание выполненных работ.
Как выдать доступы по шагам
1. Описать зоны доступа
Разделите доступы на 1С, сервер, база данных, сеть, внешние кабинеты, API, файлы и документация. Это помогает не выдавать лишние права и не искать владельца в последний момент.
2. Назначить владельцев
По каждой зоне должен быть человек, который выдаёт доступ, подтверждает права и отвечает за отзыв. Например: 1С — владелец системы или главный бухгалтер, VPN — ИТ-администратор, API банка — ответственный за личный кабинет.
3. Выдать временные персональные учётные записи
Лучше не передавать существующие логины сотрудников. Для проекта создаются отдельные учётные записи с понятным сроком действия и минимально достаточными правами.
4. Зафиксировать правила работы
До начала работ нужно согласовать, можно ли менять настройки в рабочей базе, когда допустимы перезапуски служб, кто подтверждает операции и куда писать при ошибке.
5. Проверить резервную копию
Перед доработками, обменами, обновлениями и массовыми обработками важно не просто «иметь бэкап», а понимать, когда он сделан и можно ли из него восстановиться.
6. Отозвать доступы после проекта
После завершения работ нужно отключить временные учётные записи, забрать API-ключи, закрыть VPN/RDP и сохранить описание сделанных изменений.
Как может помочь WeProf
WeProf может подготовить карту доступов для проекта: определить, какие права нужны в 1С, на сервере, в базе данных, VPN, внешних сервисах и API; согласовать безопасный способ подключения; настроить временные учётные записи и порядок отзыва.
Мы закрываем 1С, инфраструктуру, серверы и сопровождение в одном контуре, поэтому можем не только запросить доступы, но и проверить, где есть риск: общие логины, лишние права, отсутствие резервной копии, работа в боевой базе без тестового контура.
Для проектов по 1С, интеграциям и серверной инфраструктуре WeProf работает удалённо по РФ. Для ИТ-аутсорсинга, рабочих мест, локальной сети и выездной поддержки — в Санкт-Петербурге и Ленинградской области.
Итог
Доступы к 1С и инфраструктуре — это управляемый процесс, а не обмен паролями в мессенджере. Если заранее определить зоны, владельцев, права, сроки и порядок отзыва, проект стартует быстрее и безопаснее.
По теме статьи
Нужно безопасно подготовить доступы к 1С и инфраструктуре?
WeProf поможет определить нужные права, настроить безопасный доступ, проверить риски и подготовить проектный контур без хаоса с паролями.