Назад | Перейти на главную страницу

Как защитить дамп базы данных, взятый из сценария ежедневного запуска

На одном из моих подчиненных серверов mysql я написал сценарий ежедневного запуска, который 1) останавливает подчиненное устройство, 2) принимает дамп db, 3) снова запускает подчиненный сервер, 4) шифрует его, 5) копирует его в мое ведро s3.

Я использую aws-cli для копирования дампа в s3-bucket. Проблема здесь в том, что в случае, если кто-то получит доступ к серверу, он также может удалить дампы из корзины, потому что aws-cli предоставляет доступ на обновление / удаление для корзины.

Как мне скопировать дамп в какое-то место (желательно s3), откуда, если кто-то получит доступ к серверу db, он не сможет удалить дамп.

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

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

В Принцип наименьших привилегий предполагает, что первое, что вы должны сделать, это удалить все ненужные привилегии у пользователя IAM, который делает резервные копии.

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

Включение управление версиями объекта - еще одна часть головоломки, поскольку управление версиями не позволяет пользователю s3:PutObject но без s3:DeleteObject разрешение на окончательное удаление объекта путем его перезаписи. Пользователь с s3:DeleteObjectVersion разрешение все еще может удалять объекты с версией.

Последний шаг, который может быть желательным, - это включение MFA удалить на ведре. Эта конфигурация, которая также требует, чтобы в сегменте было включено управление версиями, требуется многофакторная аутентификация для удаления любой версии любого объекта в сегменте.