Как защитить от удаления контейнера BLOB-объектов? - PullRequest
Новая
       55

Как защитить от удаления контейнера BLOB-объектов?

0 голосов
/ 03 сентября 2018

Легко создавать и удалять данные BLOB-объектов. Есть способы защиты от случайной потери данных, например:

  • Блокировка ресурсов для защиты от случайного удаления учетной записи хранения
  • Azure RBAC для ограничения доступа к учетной записи / ключам.
  • Мягкое удаление для восстановления после случайного удаления BLOB-объектов.

Это уже хороший пакет, но такое слабое звено. AFAIK, контейнеру блобов не хватает такой безопасности, как для аккаунтов / блобов.

Учитывая, что контейнеры - это хорошая единица для работы с нумерацией BLOB-объектов и пакетным удалением, это плохо.

Как защититься от случайного / злонамеренного удаления контейнера и снизить риск потери данных?

То, что я рассмотрел ..

Идея 1: Синхронизация копирования всех данных в другую учетную запись хранения - но это приводит к сложности синхронизации (инкрементное копирование?) И значительному увеличению затрат.

Идея 2: Заблокируйте ключи и заставьте всех работать над тщательно продуманными ключами SAS, но это очень хлопотно с десятками токенов SAS и их обновлениями + иногда удаление контейнера действительно требуется и авторизован. Чувствует себя достаточно сложным, чтобы сломаться. Я бы предпочел безопасность в любом случае.

Идея 3: Отменить удаление как-нибудь? Согласно документации Delete Container данные контейнера не удаляются сразу:

Операция «Удалить контейнер» помечает указанный контейнер для удаления. Контейнер и все содержащиеся в нем большие двоичные объекты позже удаляются во время сборки мусора.

Однако нет информации о том, когда и как работает сборщик мусора для учетной записи хранения, и если / как / в течение какого времени можно восстановить данные контейнера.

Есть ли лучшие варианты, которые я пропустил?

1 Ответ

0 голосов
/ 04 сентября 2018

Существует альтернативный вариант, который вы должны рассмотреть, используя Политики доступа , предлагаемые для контейнеров. Вы можете использовать SAS для доступа и добавить дополнительный уровень с помощью политик доступа, который предоставляет вам политики уровня контейнера. Там вы можете предоставить доступ, который не включает опцию удаления:

enter image description here Это больше для профилактической стороны

Rbac также будет хорошим способом обеспечить доступ к контейнерам.

Когда дело доходит до восстановления данных, это официальные предложения:

Блочные объекты. Создание моментального снимка каждого блочного объекта на определенный момент времени . Для получения дополнительной информации см. Создание снимка большого двоичного объекта. За каждый моментальный снимок взимается плата только за хранилище, необходимое для хранения различий внутри большого двоичного объекта с момента последнего состояния моментального снимка. Снимки зависят от существования исходного большого двоичного объекта, на котором они основаны, поэтому рекомендуется операция копирования в другой большой двоичный объект или даже в другую учетную запись хранения. Это гарантирует, что данные резервной копии должным образом защищены от случайного удаления. Вы можете использовать AzCopy или Azure PowerShell для копирования больших двоичных объектов в другую учетную запись хранения.

Файлы. Используйте общие снимки или используйте AzCopy или PowerShell для копирования файлов в другую учетную запись хранения.

Таблицы. Используйте AzCopy для экспорта данных таблицы в другую учетную запись хранения в другом регионе. Больше можно найти здесь

...