Где в облачном бэкапе теряется контроль над данными — и как его вернуть

У меня финансовое образование, и любой сервис я сначала раскладываю на две стопки: что я отдаю наружу и что оставляю себе. С резервным копированием облака вопрос звучит грубовато, но по делу: кому вы отдаёте ключи от собственных данных, когда заказываете бэкап?

Возьму для разбора резервное копирование Яндекс 360 — удобный случай, потому что копировать приходится почту, Диск, календари, контакты, задачи. Ровно те места, где живут персональные данные сотрудников и клиентов, коммерческая переписка и всё, что нельзя терять и нельзя показывать наружу. И вот эту чувствительную гору кто-то регулярно вычитывает и складывает куда-то ещё. Где именно в такой схеме вы перестаёте контролировать свои данные — вот что я хочу разобрать по-инженерному.

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

Три точки, где контроль утекает

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

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

Второе — ключи шифрования. Копии где-то лежат, как правило в зашифрованном виде. Весь вопрос, у кого ключ. Если ключ у провайдера, то фраза “данные зашифрованы” защищает вас от постороннего, но не от самого провайдера и не от того, кто дотянется до его инфраструктуры.

Третье — физическое место хранения. Байты копии лежат на конкретных дисках в конкретной стране. Кому принадлежат эти диски и где они стоят — отдельный вопрос, и всплывает он ровно в тот момент, когда приходит проверка.

Эти три вещи часто сваливают в одну: “отдали бэкап на аутсорс”. А контроль теряется в каждой по-своему. Дальше по пунктам — как каждую забрать себе.

Ключ должен быть только у вас

Начну с ключей, потому что это сердце всей истории.

Модель, которую я считаю единственно честной для бэкапа чужого облака, — end-to-end шифрование с управлением ключами на стороне клиента: закрытый ключ хранится только у клиента. Разница с привычным “всё зашифровано” тонкая, но принципиальная. Провайдер может добросовестно шифровать ваши копии собственным ключом — тогда расшифровать их способен и он сам, и любой, кто дотянется до его инфраструктуры. E2E переворачивает расклад: у оператора ключа нет ни в каком виде, поэтому прочитать копии он не может в принципе, при всём желании.

Что это меняет на практике. Данные шифруются на стороне клиента, в хранилище уезжает уже шифротекст. Взломали хранилище — злоумышленник получил мешок байтов, бесполезный без вашего закрытого ключа. Увели учётку S3, доступ к бакету, да хоть саму управляющую часть бэкапа — расшифровать всё равно нечем. Ключа там физически нет.

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

Кто имеет право выпустить и отозвать ключ

Само по себе E2E не отвечает на вопрос, кто внутри компании управляет ключами и доступами. Тут работает ролевая модель, и важно, чтобы самые опасные операции были заперты на верх.

Критичные действия — выпуск пользовательских сертификатов и мастер-ключа — у зрелых решений этого класса заперты на роль owner, и только на неё. Это сознательное сужение. Выдать новый сертификат или перевыпустить мастер-ключ — это по сути раздать или отозвать возможность расшифровки. Такому не место в руках у рядового администратора, который зашёл восстановить одно письмо.

Остальные права разложены на градации: полный доступ, только чтение, только восстановление, только скачивание — и те же роли, но ограниченные собственными данными пользователя. По именам логика читается сразу: full, full_read, full_restore, full_download и self-версии для “только своё”. Человеку, который восстанавливает свои файлы, чужие ящики не нужны, и доступа к ним он не получит.

И отдельно про отзыв. Сертификаты можно не только выпускать, но и отзывать. Ушёл сотрудник, у которого была роль с доступом, — отзыв его сертификата закрывает вход, не ломая ключи остальным.

Куда ложатся копии — и почему это ваш выбор

Второй способ вернуть контроль — хранить копии у себя, а не в облаке вендора бэкапа.

Правильно устроенный инструмент умеет писать бэкапы:

• в локальный сервер, NAS или СХД в вашей собственной инфраструктуре;

• в любое S3-совместимое хранилище.

Ключевое слово — любое. Не “наше облако, куда мы вас пустим”, а ваш бакет в том хранилище, которое выбрали вы. Хотите держать всё внутри периметра — NAS или СХД в серверной. Хотите в облаке, но на территории РФ — подойдут российские S3-совместимые площадки, из знакомых это Яндекс.Облако, Selectel, VK Cloud.

Внутри одной организации можно завести сразу несколько S3-подключений, а под одной подпиской держать несколько организаций. Для тех, кто обслуживает не один тенант Яндекс 360, это не мелочь: у каждого свои копии в своём хранилище, ничего не смешивается.

Что для этого нужно от инфраструктуры

Теперь конкретика, без которой не взлетит. Минимальный набор такой.

S3-совместимое хранилище. На вход такому инструменту нужны endpoint, bucket, access key и secret key — стандартная четвёрка для любого S3 API. Говорит ваше хранилище по S3 — значит, подойдёт.

Защищённый транспорт. Соединение только по HTTPS/TLS: и до Яндекс 360, откуда данные вычитываются, и до хранилища, куда они пишутся.

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

Подключение к самому Яндекс 360 идёт через OAuth 2.0 и Яндекс ID, без передачи паролей на сторону. Сервис получает токен доступа, а не ваши учётные данные — ещё одна точка, где вы не отдаёте лишнего.

Где здесь ФЗ-152

Соберём всё в юридическую плоскость, потому что для многих российских компаний она и есть первопричина.

В почте, контактах и календарях Яндекс 360 лежат персональные данные — сотрудников, клиентов, контрагентов. Как только вы снимаете резервную копию, копия тоже содержит персональные данные, и на неё распространяются те же требования, включая локализацию обработки на территории РФ.

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

Чек-лист, если выбираете или собираете такое сами

Логика выше не про один конкретный продукт, это набор требований к классу инструментов. Будете выбирать бэкап для облака или собирать свой — я бы прогонял кандидата по этим вопросам:

• Где физически хранится закрытый ключ и видит ли его оператор сервиса. Видит — это не E2E, как бы это ни называли в описании.

• Можно ли писать копии в своё хранилище, а не только в облако вендора.

• Кто внутри имеет право выпускать и отзывать доступ к расшифровке, и заперта ли эта операция на отдельную роль.

• Есть ли журнал операций с указанием инициатора и можно ли выгрузить его для аудита.

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

А если у вас бэкап облака уже сделан по-своему — напишите в комментариях, где держите ключ и хранилище. Интересно свериться, кто как решил ту же задачу.