Большинство облачных бэкапов держат ключ шифрования у себя — а значит, читать ваши письма технически может их администратор. В «Бэкап Яндекс 360» наоборот: копии уезжают в ваше хранилище на территории РФ, а закрытый ключ остаётся только у вас. Разбираем, как это устроено — по слоям и с реальными скриншотами.
Когда делаешь резервную копию корпоративной почты и диска, есть два неудобных вопроса, которые почему-то задают в последнюю очередь. Где физически лежит копия. И кто, кроме вас, может её прочитать.
По второму вопросу у большинства облачных бэкап-сервисов ответ примерно один: копия у нас, зашифрована нашими средствами, ключи тоже у нас — доверяйте. Ответ честный, но он означает простую вещь: администратор на стороне сервиса технически способен открыть ваши письма. Нас это не устраивало, когда мы собирали «Бэкап Яндекс 360». Поэтому логику построили наоборот.
Дальше — по слоям, без маркетинга: куда уезжает копия, чем она зашифрована, кто вправе выпустить ключ и что нужно, чтобы всё это развернуть.
Где лежит копия — в вашем хранилище, а не в нашем
Начну с того, что для многих оказывается сюрпризом. «Бэкап Яндекс 360» не складывает ваши данные на свои серверы. Целевое хранилище — ваше.
Вариантов, куда писать копии, три:
- локальный сервер, NAS или СХД внутри вашей инфраструктуры;
- любое S3-совместимое облачное хранилище;
- российские облачные площадки — +Альянс, Яндекс.Облако, Selectel, VK Cloud.
Общий знаменатель — территория РФ. Это не косметика: именно от того, где физически лежат персональные данные, зависит разговор про ФЗ-152, к которому вернёмся ниже.
Для технически подкованного читателя пара деталей. Хранилищ можно подключить не одно: в рамках одной организации поддерживаются множественные S3-подключения. Есть мультитенантность — несколько организаций Яндекс 360 живут под одной подпиской, каждая со своей конфигурацией. А метаданные (что, когда и куда бэкапилось, история запусков, индексы для гранулярного восстановления) хранятся локально в MongoDB. То есть сами копии уезжают в ваш S3 или на вашу СХД, а служебный слой, который делает восстановление отдельного письма быстрым, лежит рядом, в вашей MongoDB.
Раздел «Хранилища S3»: копии пишутся в ваши бакеты. Видно несколько подключённых хранилищ, их заполнение и приоритет — когда место в текущем заканчивается, данные идут в следующее.
Шифрование: закрытый ключ есть только у вас
Теперь самое интересное. Шифрование здесь end-to-end, а управление ключами вынесено на сторону клиента. Закрытый ключ хранится только у вас.
Расшифрую, что из этого следует на практике. Данные шифруются до того, как лягут в хранилище, и ключа расшифровки на нашей стороне нет. Это не «мы обещаем не смотреть» — это «мы технически не можем посмотреть». Если завтра кто-то получит доступ к вашему S3-бакету с копиями, он получит шифртекст, а не переписку.
Обратная сторона медали, о которой честно предупреждаю: раз закрытый ключ только у вас, значит, и ответственность за него на вас. Потеряли ключ — потеряли возможность расшифровать копии, и восстановить его за вас никто не сможет. Это осознанный размен: контроль в обмен на ответственность. Для сценариев, ради которых бэкап и заводят — комплаенс, защита от компрометации, — размен правильный.
Раздел «Шифрование и ключи». Прямо на экране: мастер-ключ хранится только у администратора, без него расшифровка данных невозможна. Модель — двухуровневая (KEK + DEK), ключ на копию AES-256-GCM, пользовательский сертификат X.509.
Ролевая модель: кто вправе выпустить ключ
Раз ключи и сертификаты — вещь чувствительная, доступ к ним не может быть плоским. В «Бэкап Яндекс 360» критичные криптооперации отделены от рутины.
Выпуск и отзыв пользовательских сертификатов, а также выпуск мастер-ключа — прерогатива роли owner. Это не тот администратор, что настраивает расписание бэкапов; это отдельный уровень, которому доверено управление доверием. Логика простая: человек, который каждый день ведёт политики копирования, не должен попутно иметь возможность выпустить себе сертификат на чужие данные.
Всё остальное распределяется семью ролями доступа: full, full_read, full_restore, full_download, self_read, self_restore, self_download. По именам видно две оси разграничения. Префикс full — работа в масштабе всей организации, self — только со своими данными. Суффикс задаёт разрешённое действие: смотреть (read), восстанавливать (restore), скачивать (download). Роль full без суффикса — полный доступ. Так, self_restore — это сотрудник, который может восстановить только собственный ящик и ничего чужого, а full_download — тот, кому позволено выгружать данные по всей организации.
Матрица прав доступа: те же две оси наглядно — чтение / восстановление / скачивание, по своим данным или по всей организации, плюс отдельный столбец «Полные права».
И чтобы эта модель не была теорией: каждая операция пишется в детальный журнал с указанием инициатора. Логи выгружаются в .csv — есть что положить на стол аудитору или службе ИБ, когда нужно ответить на вопрос «кто и когда это трогал».
История операций: тип, статус, объём и время (столбец «Когда») каждой операции, а в карточке справа — инициатор.
Подключение: пароли наружу не уходят
Ещё одна точка, где обычно прячется риск, — как сервис вообще получает доступ к вашему Яндекс 360.
Здесь используется OAuth 2.0 через Яндекс ID. Пароли пользователей за пределы Яндекс 360 не передаются — сервис работает по выданному токену, а не по логину и паролю. Дальше в ход идут штатные интерфейсы: API Яндекс 360 для чтения данных, S3 API для записи копий в хранилище, поддержка IMAP-фильтрации для работы с почтой. Соединение — по HTTPS/TLS.
В веб-интерфейсе (в версии 1.7.0 его переработали) аутентификация построена на httpOnly-cookie — то есть сессионная кука недоступна из JavaScript, что закрывает целый класс атак на кражу сессии через XSS. Мелочь, но показательная: такие вещи обычно видны только тем, кто лезет в потроха.
ФЗ-152 и честный разговор про реестр
Соберём про соответствие требованиям. При размещении данных на территории РФ «Бэкап Яндекс 360» соответствует ФЗ-152 — и это прямое следствие всего, что выше: копии лежат в вашем контуре внутри страны, ключ у вас, доступ разграничен и логируется.
Теперь то, о чём принято молчать, а я скажу прямо. В реестр российского ПО «Бэкап Яндекс 360» пока не внесён — регистрация в процессе. Поэтому писать «продукт из реестра» было бы неправдой, и я так писать не буду. Российским его на сегодня делают две вещи: разработчик — российская компания (на рынке с 2008 года, технологический партнёр Яндекса), и данные хранятся внутри страны. Запись в реестре появится тогда, когда появится; на архитектуру защиты, описанную выше, это не влияет.
Что нужно, чтобы это развернуть
Минимальный набор требований к инфраструктуре короткий:
- S3-совместимое хранилище — понадобятся endpoint, bucket, access key и secret key;
- защищённое соединение HTTPS/TLS;
- MongoDB под локальное хранение метаданных.
Дальше настраиваются политики копирования (расписание, инкрементальные прогоны — передаются только изменения), и копии начинают уезжать в ваше хранилище зашифрованными.
Коротко, зачем всё это
- копии лежат в вашем хранилище на территории РФ, а не на серверах сервиса;
- шифрование end-to-end, закрытый ключ только у вас — обратная сторона в том, что и беречь его вам;
- критичные криптооперации (сертификаты, мастер-ключ) отделены в роль owner, остальное — семь ролей по осям «вся организация / свои данные» и «смотреть / восстановить / скачать»;
- доступ к Яндекс 360 — по OAuth, без передачи паролей; каждая операция в журнале с инициатором;
- соответствие ФЗ-152 — при размещении в РФ; в реестр продукт пока не внесён, регистрация идёт.
Хотите проверить логику не на словах, а на своих данных — первые 30 дней доступна вся функциональность: карту привязывать не нужно, число пользователей ничем не ограничено. А если удобнее, чтобы мы вместе прошли развёртывание и разложили ролевую модель под вашу структуру — напишите, разберём под ваш Яндекс 360.
