"Заказчик просит доступ, это не технический запрос, а юридический вызов. Вопрос не в том, как дать доступ, а в том, стоит ли это делать. За заявкой на RDP скрываются нереализованные обязанности самого клиента и попытка переложить их на вас, рискуя вашей лицензией."
Почему запрос на доступ, это всегда плохой знак
В большинстве случаев заказчик просит доступ не для решения своей задачи, а для того, чтобы её избежать. Типичные предлоги — «нужно проверить настройки», «посмотреть логи», «установить свой сертификат» или «интегрировать внешний сервис». На деле это означает, что клиент не хочет или не может формализовать требования, собрать необходимые данные или выполнить свои обязанности по договору. Вместо чёткого техзадания вы получаете неограниченный доступ к своей инфраструктуре со стороны человека, чьи компетенции и намерения вам неизвестны.
Даже если заказчик действует из лучших побуждений, вы создаёте единую точку отказа. Любое его действие — ошибочное или злонамеренное — теперь ляжет на вашу ответственность. Система, которой управляют две независимые команды без жёсткого разграничения, неизбежно ломается.
Юридические и регуляторные риски, о которых не говорят
Предоставление доступа стороннему лицу к серверу, где хранятся персональные данные, автоматически превращает этого человека в неуполномоченное лицо с точки зрения 152-ФЗ. Если в системе обрабатываются данные, формально вы нарушаете требование о разграничении доступа. Для сертифицированных средств защиты (СЗИ) это прямое нарушение условий эксплуатации — ФСТЭК может аннулировать сертификат.
С точки зрения договора ГПХ или оказания услуг, вы стираете грань ответственности. При инциденте будет невозможно доказать, чьими действиями он вызван. Суд или проверяющий орган встанет на сторону заказчика, так как доступ был предоставлен вами, а значит, контроль над инфраструктурой оставался в вашей зоне ответственности.
Что скрывается за просьбой: декомпозируем реальные потребности
Запрос «дать доступ», это симптом. Ваша задача — выявить корень проблемы.
- «Нужно проверить настройки». Реальная потребность: заказчик не доверяет отчётам или не понимает их. Решение: автоматизировать сбор доказательств (чек-листы, скриншоты через secure snapshot, дампы конфигураций в защищённый архив).
- «Нужно посмотреть логи». Потребность: клиент хочет отслеживать определённые события. Решение: настроить безопасный канал экспорта логов (syslog over TLS, SIEM-интеграция) в его isolated storage.
- «Нужно установить свой софт/сертификат». Потребность: интеграция с внутренними системами заказчика. Решение: переход на модель Infrastructure as Code, где его изменения вносятся через merge request в ваш репозиторий, а развёртывание идёт через ваш CI/CD с вашим approval.
- «Хотим администрировать сами». Потребность: желание снизить зависимость от подрядчика или контроль над средой. Решение: выделить клиенту полностью изолированный стенд (VPC, отдельный кластер), документально зафиксировав передачу ответственности, и работать с ним только через API или управляющие контуры (control plane).
Протокол безопасного взаимодействия: альтернативы прямому доступу
Полностью исключить участие клиента нельзя, но можно сделать это взаимодействие управляемым и безопасным.
1. Сессия под наблюдением (Guided Session)
Вместо выдачи логина и пароля организуйте сессию через инструменты типа Teleconsole или с использованием временного JIT-доступа (Just-In-Time) в вашей PAM-системе. Вы остаётесь в системе, клиент получает возможность выполнить команды под вашим визуальным контролем. Весь сеанс записывается.
# Пример создания сессии Teleconsole (замените на актуальный инструмент)
teleconsole ssh --port 2222 user@server
# Ссылка с одноразовым доступом отправляется клиенту2. Выделенный аудиторский портал
Соберите все доказательства работоспособности системы в защищённый веб-интерфейс. Сюда могут входить:
- Дашборды Grafana (только для чтения) с ключевыми метриками.
- Архивы логов, отфильтрованные по pre-defined запросам.
- Снимки конфигураций (например, вывод
nginx -T,ss -tlnp). - Результаты последних тестов на проникновение (только вывод, без уязвимостей).
Портал аутентифицируется по отдельным учётным данным и не даёт возможности что-либо изменить.
3. Контур управления через API и GitOps
Перенесите точку взаимодействия на уровень декларативных конфигураций. Клиент вносит изменения в свой форк репозитория с инфраструктурным кодом (Terraform, Ansible, Helm-чарты). Ваша команда проверяет изменения и запускает pipeline. Сертификаты, ключи и секреты управляются через HashiCorp Vault или аналог, доступ клиента — только на выпуск сертификатов для его доменов.
# Пример структуры репозитория для клиента
infra/
├── client-changes/
│ ├── ingress-patch.yaml # Его изменения
│ └── certificate-request.yaml
├── pipelines/
│ └── validate-and-apply.yaml # Ваш pipeline
└── README.md # Инструкция по внесению измененийКак оформить отказ, если альтернативы не принимаются
Если клиент настаивает на прямом доступе и отказывается от безопасных каналов, ваш ответ должен быть письменным и юридически грамотным.
- Ссылка на договор и регуляторику. Укажите пункты договора о разграничении ответственности и положения 152-ФЗ, требующие обеспечения конфиденциальности ПДн.
- Фиксация рисков. Направьте официальное письмо, в котором перечислите возможные последствия: нарушение лицензионных соглашений ПО, аннулирование сертификатов ФСТЭК, риск инцидентов ИБ.
- Требование подписать допсоглашение. В нём должно быть чётко прописано:
- Перечень лиц со стороны заказчика, получающих доступ (с паспортными данными).
- Их точные права и запрещённые действия.
- Положение о том, что заказчик принимает на себя полную финансовую и юридическую ответственность за ущерб, вызванный действиями его сотрудников.
- Гарантии со стороны заказчика о наличии у его персонала необходимых допусков (если работа ведётся с гостайной).
Без подписанного допсоглашения доступ не предоставляется. Такой подход часто заставляет заказчика пересмотреть свои запросы.
План действий на случай, если доступ уже предоставили
Если ошибка уже совершена, действуйте немедленно.
| Действие | Цель | Инструменты/Методы |
|---|---|---|
| 1. Немедленный ротация всех учётных данных | Аннулировать выданный доступ | Смена паролей, отзыв SSH-ключей, инвалидация сессий в PAM. |
| 2. Аудит действий | Выяснить, что было сделано | Анализ логов bash history, auditd, journalctl за период доступа. |
| 3. Проверка целостности | Обнаружить бэкдоры и изменения | Сравнение с эталонными конфигурациями (AIDE, Tripwire), проверка cron, автозагрузки, сетевых служб. |
| 4. Документирование инцидента | Зафиксировать факт для отчётности | Составление акта с выводами аудита, обновление реестра инцидентов. |
| 5. Внесение изменений в процессы | Недопущение повторения | Внедрение PAM, JIT-доступа, обязательного письменного запроса на доступ. |
Итог: доступ, это не услуга, а уступка
Предоставление заказчику доступа к вашему серверу, это не техническая операция, а управленческое решение с высокими рисками. Современный подход заключается в проектировании взаимодействия так, чтобы необходимость в таком доступе просто не возникала. Используйте API, инфраструктуру как код, безопасные каналы передачи данных и чёткие процедуры. Ваша инфраструктура — ваш суверенитет. Передача ключей от него, даже временно, должна рассматриваться как крайняя мера, сопоставимая по последствиям с передачей ключей от сейфа.