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

[xenon]

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

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

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

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

[Granulex]

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