Как закрыть доступ и сохранить рабочую переписку

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

1. Согласуйте доступ и момент блокировки

Я начинаю не с клика в админке, а с короткой сверки с HR и руководителем: когда прекращается доступ, кому передают рабочие обязанности, какую переписку требуется сохранить и на каком основании к ней будут обращаться. Почтовый ящик редко содержит только деловые письма сотрудника: там бывают персональные данные контрагентов, обращения коллег и частные сообщения. Поэтому формула «домен наш — читаем всё» юридически не работает. Я фиксирую цель и границы просмотра, проверяю локальные документы и порядок уведомления сотрудника, а спорные случаи отдаю юристу или ответственному за персональные данные. Статья 88 ТК РФ относится к передаче персональных данных работника, а 152-ФЗ регулирует их обработку; ни одна из этих норм не превращает любой корпоративный ящик в безусловно открытый архив. Если нужен общий регламент работы с почтой, можно начать с настройки корпоративной почты, но основания доступа определяет организация, а не почтовый интерфейс.

В назначенный момент я запрещаю новые входы на используемых протоколах, меняю учетные данные и отдельно завершаю активные сеансы средствами конкретной платформы. Это три разных действия. В Microsoft 365, например, документация отдельно описывает сброс пароля, выход из сеансов и отключение входа; действие с токеном или открытой веб-страницей не всегда происходит мгновенно. В Exchange Online администратор может отдельно отключить Outlook, веб-почту, IMAP, POP3 и мобильный доступ. На другом сервере названия и последствия настроек будут другими, поэтому я не обещаю, что одна кнопка мгновенно обрывает каждое подключение. Проверяю старые сеансы, приложения и учетные данные интеграций, а затем пробую повторный вход с прежним паролем. Зеленая галочка в панели полезна, но проверка фактического доступа полезнее. Пароль — не машина времени.

До блокировки я составляю минимальный чек-лист объекта: основной адрес, алиасы, подключенные устройства и приложения, адреса переадресации, доступы делегатов и владелец будущих ответов. Уточняю, кто будет принимать письма сразу после увольнения, чтобы техническое действие не закрыло нужный канал для клиентов. С HR согласую точный момент и способ сообщить сотруднику, что доступ изменен. Если есть подозрение на компрометацию, инцидентный порядок может требовать немедленного ограничения доступа; в обычной передаче предварительное согласование снижает риск пропустить входящие обращения. Я заранее готовлю отдельную административную учетную запись для операции и тестовую учетную запись для проверки. Пароль не передаю в чате и не включаю в протокол. Не пересылаю общий пароль в чате и не включаю его в протокол; для операции использую утвержденный способ передачи учетных данных.

2. Сохраните ящик способом, который поддерживает платформа

После блокировки я не удаляю учетную запись и не передаю ее пароль преемнику. Сначала выбираю способ сохранения: штатный экспорт, резервную копию, архив или механизм удержания данных, если он есть в используемой системе и подходит по условиям хранения. MBOX и PST — форматы, применимость которых зависит от продукта и способа выгрузки; универсальной кнопки «полная копия любого ящика» нет. Экспорт может не включить восстановимые удаленные элементы, календарь, контакты, настройки правил или архивную часть. Поэтому я записываю, что именно вошло в копию, когда она сделана, кому доступна и чем ее можно открыть. В условном примере из карточки статьи — ООО «Вереск-Сервис» — я сначала сохраняю рабочую переписку и фиксирую ответственного за копию; это иллюстрация процесса, а не отчет о реальном инциденте. Проверка резервной копии почты должна завершаться восстановлением в отдельный тестовый ящик, а не обещанием, что файл когда-нибудь пригодится.

Если компания использует Яндекс 360 для бизнеса, в документации есть архив писем: он сохраняет копии отправленной и полученной почты ящиков на домене организации, когда архив подключен. Доступ к архиву по умолчанию выключен, а письма, удаленные владельцем до подключения, в него не попадут. Его подключение не вернет письма, удаленные раньше. В Exchange Online для удаленных элементов действует собственная логика Recoverable Items: срок хранения по умолчанию составляет 14 дней и может быть изменен администратором в пределах, описанных Microsoft. Это настройка конкретного продукта, а не общий срок для любой почты. Я проверяю правила хранения до экспорта и до удаления учетной записи; если срок прошел или элемент очищен окончательно, обещать восстановление нельзя. Сохраненную копию я открываю и выборочно проверяю папки, вложения и диапазон дат, а при критичной переписке — пробно восстанавливаю несколько сообщений.

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

• Зафиксировать способ и состав копии
• Ограничить доступ к архиву
• Проверить правила хранения
• Восстановить копию в тестовый ящик

3. Проверьте журнал действий и правила пересылки

Пока копия формируется, я проверяю события аудита, если платформа их сохраняла и у администратора есть нужные права. В Exchange Online для поиска операций с письмами применяют Search-UnifiedAuditLog и фильтры Move, MoveToDeletedItems, Create, SoftDelete и HardDelete; временной диапазон в Microsoft Purview задают по UTC. В журнале смотрю дату, учетную запись, тип операции и сам объект, затем сверяю запись с настройками хранения и доступом делегатов. В документации Microsoft SoftDelete описывает действие с удалением письма, а HardDelete — окончательное удаление; событие само по себе не сообщает мотив. Перемещение письма в корзину не доказывает саботаж, а массовая операция требует контекста: мог работать фильтр, мобильный клиент или другой пользователь с делегированным доступом. Я сохраняю исходную выгрузку и отдельно записываю, кто и когда ее получил. Аудит почтовой инфраструктуры полезен как отдельная процедура; здесь же важно не подменить техническую запись обвинением.

Затем я проверяю правила входящих писем, переадресацию на внешние адреса, алиасы и изменения настроек ящика. В Exchange Online создание и изменение правил можно искать в журнале аудита; набор доступных событий и срок их хранения зависят от конфигурации и лицензии. Сначала фиксирую правило: условие, адрес назначения, дату изменения и то, остается ли копия в исходном ящике. Потом согласую с владельцем процесса, оставить ли правило, отключить его или заменить внутренним маршрутом. Если журнал не был включен или срок его хранения истек, точную картину действий из пустоты не извлечь; проверяю другие доступные следы и честно отмечаю пробел. Отсутствие записи не доказывает, что действия не было. И наоборот, запись о пересылке не доказывает, что человек унес базу: нужны адресат, содержание, рабочий контекст и правовая оценка. Журнал без времени и учетной записи — сувенир, не расследование.

При расследовании я не смешиваю разные часы. Microsoft Purview задает диапазон поиска по UTC, а локальный сервер или приложение могут показывать время в иной зоне; перед сравнением преобразую отметки к одной шкале и указываю ее в записи. Сохраняю исходный результат поиска до сортировки и фильтрации, фиксирую учетную запись администратора, критерии и период. Если ожидаемых событий нет, проверяю доступные права, включение аудита и срок хранения записей. Отдельно могу сопоставить журнал входов, изменения правил и действия администратора, если система их ведет. Такое сопоставление помогает увидеть последовательность, но не заменяет проверку содержимого и контекста. Я не добавляю в отчет лишний текст писем, если для поставленного вопроса достаточно операции, времени и учетной записи.

4. Передайте рабочий адрес через отдельные права

Когда сохранение и проверка завершены, я решаю, что нужно бизнесу дальше: сохранить адрес для входящих писем, дать преемнику доступ к истории или передать только отдельные папки. Для этого использую делегирование либо общий ящик, если конкретная платформа его поддерживает. Делегированный ящик устроен через права доступа коллег, а не через передачу старого пароля. Я выдаю их на именованную учетную запись, выбираю минимальный достаточный уровень и фиксирую владельца, цель и дату пересмотра. Я выдаю только доступ к нужным папкам или право отвечать от общего адреса; полный доступ включаю, только когда этого требует задача. Проверяю также отправленные письма: у нового владельца должно быть понятно, от чьего имени ушел ответ и где сохранится его копия. Отдельно назначаю ответственного за архив и за снятие делегирования, когда временная помощь больше не нужна.

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

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

5. Проверьте результат и закройте передачу документом

Финальную проверку я делаю под учетными записями обеих сторон. Проверяю, что бывший сотрудник больше не входит доступными способами, а новый ответственный видит только согласованные папки и может выполнить нужные рабочие действия. Отправляю контрольное письмо на внутренний адрес и отвечаю на него, проверяю входящие, исходящие, вложения и отображение архива. Если доступ к ящику делегирован, смотрю отдельно чтение, отправку и сохранение ответа; эти права не всегда совпадают. Затем проверяю правила пересылки и подключенные приложения еще раз, чтобы временная настройка не осталась навсегда. Для контроля миграции или смены почтовой системы есть отдельный чек-лист приемки переноса, но при увольнении я добавляю к нему проверку старых полномочий. Не трогаю DNS-аутентификацию писем только потому, что сменился владелец ящика: если одновременно менялась почтовая платформа или доменные записи, это отдельная задача с отдельной проверкой.

Передачу закрываю коротким протоколом: время блокировки, способ сохранения, место копии, результаты выборочного восстановления, проверенные каналы входа, выданные права, ответственный и дата повторной проверки. Если нашел удаленные сообщения, фиксирую факт и технические данные нейтрально, не называя это кражей или уничтожением до внутренней проверки. В этот же документ вношу исключения: недоступный архив, отсутствующий журнал или неработающую интеграцию. Так руководитель понимает, что сохранено, а что требует отдельного решения; администратор может повторить шаги, не полагаясь на память; HR видит, кому и на каком основании предоставили доступ. Я не обещаю «полную сохранность» одним щелчком: результат зависит от платформы, настроек хранения и того, что было удалено до начала процедуры. Эти оговорки помогают принять решение до того, как учетную запись удалили.

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

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