Почтовый сервер и закон: логи, хранение, доступ

MAATRIX

Вы подняли свой почтовый сервер — свобода от чужих политик, контроль над данными, никакой блокировки аккаунта по решению чужой службы поддержки. И примерно тогда же приходит второй вопрос, который на старте обычно откладывают: а что с этим сервером связано юридически? Логи кто-то должен хранить или нет, что делать, если придёт официальный запрос, и вообще — то же самое ли это, что почта на Gmail, только под своим доменом, или другая история. Ниже — обзор категорий, о которых стоит подумать, без готовых ответов на все случаи: готовых ответов тут в принципе не бывает.

Это не юридическая консультация — и вот почему это важно понимать

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

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

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

Категория 1: хранение логов соединений и переписки

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

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

Что реально стоит сделать технически, пока ждёте консультацию юриста, — это навести порядок в том, что вы и так логируете, чтобы потом было проще подстроиться под любое решение:

# где обычно лежат логи почтового сервера на Linux
/var/log/mail.log        # Postfix / общий почтовый лог
/var/log/mail.err        # ошибки
/var/log/dovecot.log     # IMAP/POP3-сервер, если используется Dovecot

Настройте ротацию логов так, чтобы вы понимали, за какой период данные реально доступны на диске:

# /etc/logrotate.d/mail-custom
/var/log/mail.log {
    daily
    rotate 180
    compress
    delaycompress
    missingok
    notifempty
}

Здесь rotate 180 — это условный пример на 180 дней, а не рекомендуемый законом срок: конкретное число месяцев или лет нужно определить, отталкиваясь от требований вашей юрисдикции (если они применимы) и внутренних потребностей бизнеса, а не от того, что «180 звучит солидно». Важнее сам факт: у вас должно быть осознанное число, а не default-настройка дистрибутива, о которой никто не думал.

Категория 2: доступ к переписке по официальному запросу компетентных органов

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

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

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

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

Отдельно: если вы используете VPS у стороннего провайдера, стоит заранее понимать, кто физически первым получает такие запросы — вы как администратор почтового сервера, или хостинг-провайдер, у которого меньше информации о содержимом, но который отвечает за инфраструктуру. Эта граница ответственности обычно прописана в договоре с хостингом и в законодательстве о провайдерах инфраструктуры — тоже вопрос для юриста, а не для догадок.

Категория 3: защита персональных данных пользователей сервера

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

Применимое законодательство о защите персональных данных — будь то что-то в духе европейского регулирования, российского закона о персональных данных, или локальных норм другой страны — касается и информации, которая обрабатывается и хранится почтовым сервером, точно так же, как любой другой ИТ-системой с персональными данными внутри компании. С точки зрения права это часто тот же периметр вопросов, что и для персональных данных сотрудников на корпоративном сервере в принципе — просто применительно к почте это ещё и переписка, а не только кадровые данные в HR-системе.

Что стоит выяснить у юриста для конкретной ситуации:

• какой правовой режим применяется — по месту нахождения компании, по месту нахождения пользователей, или по обоим основаниям одновременно (это довольно частая история для международных команд);
• нужно ли какое-то согласие сотрудников или клиентов на обработку их переписки в принципе, и есть ли ограничения на мониторинг корпоративной почты работодателем;
• какие технические и организационные меры защиты от вас формально ожидаются (шифрование при передаче — TLS между серверами и на подключении клиентов, ограничение доступа к бэкапам, политика паролей);
• если сервер физически размещён не в той стране, где зарегистрирована компания или живут пользователи — есть ли требования к трансграничной передаче данных или локализации.

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

Категория 4: архивные обязательства для коммерческого использования

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

Это достаточно объёмная тема сама по себе — она пересекается и с бухгалтерским/налоговым законодательством (документооборот, подтверждающий сделки), и с отраслевыми регламентами, и с внутренними правилами компании о том, сколько лет хранить переписку после закрытия проекта или увольнения сотрудника. Здесь мы её только обозначаем как категорию вопросов, а не разбираем подробно — вынести полноценный архивный регламент за рамки одной статьи разумнее, чем сжать его до пары абзацев с риском упустить важное.

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

Как подготовиться заранее: внутренняя политика вместо импровизации

Вот практический совет, который применим почти всегда, если речь о коммерческом использовании собственного почтового сервера (а не о сугубо личном сервере одного человека): имеет смысл заранее, до того как случится что-то реальное, задокументировать внутреннюю политику по двум вещам — срокам хранения логов и переписки, и процедуре реагирования на официальные запросы доступа.

Такая политика не обязана быть толстым документом на пятьдесят страниц. Разумный минимум:

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

Если вы только разворачиваете почтовую инфраструктуру с нуля, имеет смысл сразу закладывать логирование и хранение с оглядкой на эти вопросы, а не пересматривать конфигурацию постфактум — базовые шаги описаны в статье про установку и настройку почтового сервера Postfix на VPS, а более прикладной разбор именно про логи и сроки их хранения — в материале что хранить в логах по закону и сколько времени.

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