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

[xenon]

Для бэкапов с баз данных использовал age как раз чтобы параноидальную безопасность реализовать. Что мы получили (а самое главное - получили очень просто, на уровне одной шелл-команды в cron):

1. Все бэкапы зашифрованы публичным ключом
2. Для дешифровки нужен приватный ключ
3. Приватного ключа - нет ни на сервере, ни в облаке вообще. В моем случае - это мой личный SSH ключ ed25519, который есть только на нескольких моих компах.
4. Для дешифровки подойдет не только этот мой ключ, но и ключ еще нескольких человек. То есть, уходим от bus factor 1.

Но еще раз подчеркну самое важное и главное - это все ОЧЕНЬ просто и быстро делается, не сложнее создания zip-файла с паролем, а вот преимуществ - гораздо больше.

Описывал схему в статье про age:
https://habr.com/ru/articles/856222/

[zhogov1985]

Отличный кейс, и вы попали ровно в сердце того, о чём статья: ключа нет ни на сервере, ни в облаке. Это и есть та граница, за которой «данные зашифрованы» перестаёт быть маркетингом и становится реальной гарантией.

Отдельно спасибо, что подняли bus factor. Я в тексте честно оговорил обратную сторону E2E: потеряли ключ — и копии превратились в мешок байтов уже для вас самих. Несколько получателей у age этот компромисс и снимают: закрытый ключ только у вас, но «вас» — не один человек с единственным ноутбуком.

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

Разница в задачах, конечно, есть. У вас — дамп базы, который вы сами создаёте на своём сервере: тут age идеален. Когда копируешь чужое SaaS-облако (почта, Диск, календари), сверху навешивается расписание, версии, восстановление одного письма и ролевая модель — но принцип с ключом ровно тот же, и ваш пример это отлично показывает. За разбор age спасибо, забрал в закладки.

[Granulex]

Три вещи разложены точно. Добавлю четвёртую, которая обычно остаётся в тени: сам токен доступа к Яндекс 360. Он живёт на стороне сервиса и читает не копию, а живой ящик каждый день – даже при честном end-to-end и хранении в РФ это постоянный ключ от оригинала, а не от резерва. По опыту, регулярный отзыв и ротация этого токена защищают сильнее, чем спор о том, на чьих дисках лежат байты копии.

[zhogov1985]

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

Рычаг, который OAuth здесь всё-таки даёт, - грант отзывается на стороне Яндекс ID самим владельцем организации, без смены паролей. Так что ваша гигиена, регулярный отзыв и ротация, - это ровно то, чем этот вектор и закрывается; сам он не самоустранится.

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