Миграция почты без доступа подрядчика к содержимому писем

Кратко

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

На практике миграцию можно провести так, что интегратор настраивает сервис миграции Yandex 360, DNS и политики, но не имеет доступа к содержимому писем: используются технические учётные записи с правами репликации, журналирование действий, разделение ролей и договорные обязательства. SmartProektSystems — партнёр Yandex 360 — работаем по модели, согласованной с ИБ заказчика: подрядчик управляет процессом, не читая переписку.

Риски ручного переноса и экспорта PST/IMAP

Именно «ручные» схемы чаще всего нарушают конфиденциальность:

• админ выгружает PST всех директоров на внешний диск «для заливки»;
• подрядчик получает пароли от ящиков CEO и юридического отдела;
• экспорт через Outlook на ноутбук интегратора — полная копия переписки вне контроля заказчика;
• общий FTP/S3 с архивами без шифрования и срока хранения;
• скриншоты и ручная проверка «есть ли письмо от клиента X» — прямой просмотр содержимого.

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

Компромисс — автоматизированный перенос через официальный сервис миграции с минимальными привилегиями и без передачи содержимого подрядчику.

Как устроен перенос без чтения переписки

Подрядчик видит: «ivanov@ — синхронизировано 12 450 сообщений, 3 ошибки вложения». Не видит: темы, текст, вложения, если не получил явного доступа к ящику — которого в модели «без доступа к содержимому» нет.

Техническая учётная запись: права и границы

Для Exchange / Microsoft 365 типовой набор:

• роль ApplicationImpersonation или scoped admin для миграции — без доступа к админ консоли всей организации, если политика запрещает;
• отдельный service account migration-svc@ с аудитом входов;
• запрет интерактивного входа (sign-in disabled для людей, только app/service);
• MFA и IP-restriction по согласованию.

Для Google Workspace — domain-wide delegation только для объём работ миграции почты, не Drive/Calendar при необходимости разделить.

Учётную запись создаёт IT или ИБ заказчика. Подрядчик получает инструкцию, куда ввести учётные данные в консоли миграции Yandex 360 — или заказчик вводит сам под контролем на созвоне без передачи пароля в чат.

Модели взаимодействия с подрядчиком

1. Co-managed. Подрядчик настраивает миграцию и регламент; учётные данные только у заказчика; переключение совместно.
2. Консультации + руки заказчика. СмартПроектСистемс даёт архитектуру и чеклисты; синхронизацию запускает штатный админ.
3. Под ключ с NDA и регламентом ИБ. Доступ к метаданным и админ ролям Yandex 360 без ящиков пользователей; проверку содержимого делают назначенные сотрудники заказчика.

Модель выбирают на старте с ИБ — не после первого экспорта PST.

Договор, NDA и 152 ФЗ

Юридический контур не менее важен технического:

• NDA и договор подряда с явным перечнем: подрядчик не запрашивает и не хранит содержимое почтовых сообщений;
• описание ПДн: миграция как обработка по поручению оператора-(заказчика);-Yandex 360 — отдельный оператор/процессор по их договору;
• журнал действий администраторов Yandex 360 и-source-системы;
• срок хранения логов миграции и уничтожение временных артефактов-(если пилот на тестовых ящиках);
• план реагирования: что делать, если подрядчик запросил доступ к ящику «для проверки одного письма» — эскалация в ИБ, не-ad-hoc-пароль.

SmartProektSystems-работает с юрлицами и ИП в РФ; типовой пакет документов согласуем с вашими юристами до старта работ.

Проверка миграции без доступа подрядчика к письмам

Как убедиться, что перенос качественный, не читая чужую переписку:

Пилот на 5–10 ящиках включает «чувствительные» роли — но проверку содержимого делают их владельцы по чеклисту: «есть ли планёрка от 15.03», «на месте ли папка Контракты 2024».

Что говорить службе безопасности

Короткие тезисы для согласования проекта:

• данные идут напрямую из-source-в Yandex 360 через сервис миграции, не через ноутбук подрядчика;
• у подрядчика нет паролей от пользовательских ящиков и нет роли «открыть любое письмо»;
• доступ к админке Yandex 360 — по принципу-least-privilege, аудит включён;
• проверка качества — агрегированная и выборочная силами заказчика;
• платформа Yandex 360 — данные в ЦОД РФ, договор с оператором.

Если ИБ требует «только штат» — передаём регламент и сопровождаем co-managed: ваш админ нажимает кнопки, мы ведём по процессу на созвонах без доступа к содержимому.

Типовые возражения и ответы

«Любой-admin-Exchange видит всё». Да — поэтому миграционная учётка не должна быть личной учёткой подрядчика, а выделенным-service-account-с аудитом и сроком жизни проекта.

«Облако-=-все письма у Yandex». Модель такая же, как у-on-prem-у хостера: договор, локализация, разграничение доступа. Подрядчик-≠-Yandex-≠-ваши пользователи.

«Проще самим ночами копировать». Риск потери данных и неконтролируемого хранения-PST-на рабочих станциях выше, чем у сертифицированного-pipelines-миграции.

FAQ

Может ли подрядчик видеть темы писем в логах? Стандартные отчёты миграции — объёмы и ошибки. Если темы попадают в-debug-лог-source — отключаем-verbose, согласуем с ИБ.

Нужен ли доступ к ящику директора? Нет для настройки-sync. Проверку после миграции делает директор или его ассистент.

Как быть с eDiscovery и архивом требования регуляторов? Отдельная политика хранения в Yandex 360; миграция не заменяет архивирование — настраивается параллельно.

Можно ли полностью исключить подрядчика из админки Yandex 360? Да — формат консультаций: мы документируем шаги, заказчик выполняет.

Что передать подрядчику минимально? Схема сети, домены, число ящиков, объёмы, тип-source, контакт IT; не-PST-и не пароли пользователей.

Чеклист для ИБ и IT-директора

• согласована модель:-service-account, без-PST-на стороне подрядчика;
• NDA и поручение на обработку ПДн подписаны до старта;
• учётная запись миграции создана заказчиком, пароль не в мессенджере;
• роли в Yandex 360: подрядчик без доступа к содержимому ящиков;
• план проверки: метрики-+-выборочная верификация владельцами;
• после проекта: отзыв учётные данные-migration-svc, смена паролей при необходимости.

Частые вопросы от службы безопасности

Видит ли Yandex содержимое при миграции? Данные обрабатываются по договору оператора связи/облачного сервиса; миграция — техническая репликация в ваш-tenant, не «ручной просмотр».

Можем ли мы сами вводить пароль-migration-svc? Да — подрядчик на созвоне говорит «сейчас поле учётные данные в консоли», заказчик вводит, пароль не передаётся в чат.

Нужен ли доступ подрядчика к AD/LDAP? Только если синхронизация пользователей; для чистой миграции почты — учётные записи создаются в Yandex 360 по списку CSV от HR/IT.

Как доказать, что подрядчик не читал письма? Журнал админ действий, отсутствие-login-as-user, отчёт-sync-без-body; при необходимости — акт о модели доступа и закрывающий отчёт проекта.

Что делать дальше

Требование «подрядчик не видит письма» — разумное и выполнимое. Оно не означает «миграцию делать только своими силами без опыта». Сервис миграции Yandex 360, техническая учётная запись и чёткий регламент позволяют перенести Exchange или Google Workspace под контролем ИБ.

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

Сравнение подходов с точки зрения ИБ

Документы для согласования с юристами

Чтобы проект не завис на «согласуйте ещё раз», готовим пакет:

1. описание процесса миграции — схема потоков данных без содержимого писем;
2. перечень ролей и доступов подрядчика (метаданные, DNS, настройка sync);
3. NDA и поручение на обработку ПДн;
4. регламент проверки качества силами заказчика;
5. план отзыва учётных записей migration-svc после переключения + 14 дней.

На первой встрече с ИБ проходим по таблице «кто что видит» — это снимает 80% возражений до старта технических работ.

Частные случаи: юридический отдел и топ менеджмент

Ящики legal@ и личные ящики C-level — самые чувствительные. Для них:

• отдельная волна синхронизации без участия подрядчика в приёмке — только владелец ящика;
• опционально: миграция в последнюю очередь, когда конвейеры выкладки отработан на остальных;
• запрет тестового входа подрядчика «просто проверить» — только автоматический отчёт sync 100%.

Такая сегментация не замедляет проект, если заложена в план с первого дня, а не добавляется после эскалации от юристов.

Типовой сценарий согласования с ИБ

Неделя 1: встреча СмартПроектСистемс + IT + ИБ — таблица «кто что видит», согласование модели service account. Неделя 2: юристы проверяют NDA и поручение на обработку ПДн. Неделя 3: заказчик создаёт migration-svc, подрядчик настраивает sync на тестовых ящиках без доступа к боевой контур переписке дирекции. Неделя 4+: пилот и массовая миграция с приёмкой владельцами чувствительных ящиков.

Такой ритм укладывается в 3–4 недели согласований — быстрее, чем бесконечный цикл «сначала всё сами, потом снова ИБ».

152 ФЗ и аудит следов миграции

После завершения проекта ИБ часто спрашивает: «где остались копии переписки». При корректной модели:

• временные PST и экспорты на рабочих станциях — уничтожены по акту;
• логи миграции хранятся ограниченный срок без body писем;
• учётная запись migration-svc отключена или удалена;
• доступ подрядчика к админке Yandex 360 отозван или переведён на read-only отчёты.

Фиксируем это в закрывающем отчёте проекта — для внутреннего аудита и проверок по 152 ФЗ.