Что это значит?Почему тома? Тома - термин из области блочных устройств.А если хранение делается на уровне файлов, например в s3? Не подходит?Правильнее бы звучало - репозитории.
Русское слово "Том" является прямым переводом английского слова Volume. И это никакого отношения не имеет к тому, какое у вас устройство - блочное, файловое или объектное, типа S3.
Похоже, что термин "репозиторий" применительно к S3 ввели в Amazon. Но я достаточно стар, чтобы помнить времена, когда Amazon был магазином книжек и делал только робкие попытки продавать ихз через Интернет. И вот тогда репозитории уже вполне себе существовали. Например Linux репозитории - это то место, откуда мы пакеты берем. И никакого отношения к СХД они не имели.
Последнее время люди вообщще очень вольно к терминам относятся... /немного песка посыпал ))/
Из чего это следует? Если я делаю чисто логическое разделение, ставлю перед своим storage backend простой (а значит ожидаемо надежный и безопасный), опенсорсный, массово используемый (оттестированный) сервис, который все что только и делает - обеспечивает безопасность: разрешает пользователю user_1 ходить в storage_backend_1, а user_2 в соотвественно _2 и т.д. Например:
Использую на источниках данных в качестве утилиты бекапа restic.
А на сервере хранилище:
rest-server (его storage через rest api) отдельный инстанс для каждого клиента, с настройками append only, смотрящий в свой единственный бекенд репозиторий.
и nginx перед всеми инстансами для acl, т.е. разрешения юзерам обращаться только к своему rest-server -> своему storage backend.
Тогда я сделал что-то сильно небезопасно? Но ведь чтобы утверждать такое, нужно сначала признать что такое жутко обкатаное ПО как nginx небезопасно. И злоумышленик вместо того чтобы начать ломать банки через этот небезопасный nginx, вклиниваясь в их трафик (т.е. с очень понятной и маштабируемой моделью монетизации), решил ломать какой-то богом забытый nginx в моей внутреней сети...
Это разумеется невероятно. Гипотетические риски такой небезопасности просто меркнут на фоне практической гиганской кривизны и забагованости проприетарного, особенно местячкового (т.н. импортозамещерованного), ПО, которое подчастую используется для ЫнтырПрайс бекапа... и в том числе прямо следующей из перечисленного небезопасности.
Ухх... Opensource - это значит, что за код вообще никто не несет ответственности, и какие там дыры - вы просто не знаете. Поэтому да, вы сделали что-то сильно небезопасное.
Но, опять таки, все решает ваша толерантность к риску. Если ваши данные легко восстановимы или просто не очень дорогие, то Opensource - отличный выбор! Он может быть отличным выбором даже если у вас очень важные данные. Но только если это НЕ все, на что вы полагаетесь при их защите.
А недостатки совершенно понятны:
Бекапы на отделенном (отсоединенном) от сети хранилище нужно таким же "отсоединенным" образом (=руками) выполнять и тестировать.
метрики что бекапа, что тестирования бекапа нужно "отсоединенным" (=руками) образом доставлять в единую систему мониторинга.
И вот мы на практике получаем: мы разменяли гипотетическую (сугубо идеалистическу) безопасность отключеных бекапов, на человеческий фактор их (бекапов) выполнения... Что тут еще сказать? Занавес.
Не все так печально. Можно и автоматически ))
Ну и не отменяет это необходимости в online бэкапе. Я ж специально в конце написал - это не замена, а дополнение к политике резервного копирования и DR.
Air gap - это довольно радикальный метод. И нет ничего удивительного, что люди ищут такие реализации, которые и риски снизят, и хоть какую-то гибкость дадут. Самый надежный сервер, как известно - тот, который выключен в сейфе.
Все решает модель угроз компании и ее толерантность к риску.
От пожара вам поможет просто репликация в другое место. Не нужно усложнять себе жизнь, если ваша угроза - пожар или наводнение. Air gap backup - это от другой угрозы.
Вам нужно достаточно дешевое хранение. Не на NVMe точно. И технологии оптимизации очень не помешают.
Изоляцию обеспечить не так уж и просто. Выше был комент про IPMI. Вам нужно придумать, как вы делаете резервные копии, и как вы их храните вне сети. Руками каждый раз разрывать связь - не вариант. Значит нужна автоматизация.
Угроза изменилась. Раньше бэкап был средством защиты от сбоя или аварии. Причем непреднамеренного сбоя или аварии. То есть достаточно было его хранить там, где его не затронет, например, пожар в DC. И не было проблем, если он был в сети - пожар по интернету не распространяется. А теперь нужно данные защищать уже от намеренного уничтожения. Зловред - не пожар. Ваши архивы для него тоже цель.
То есть да, СХД, как устройство, может быть общего назначения. А вот СИСТЕМА (в смысле информационная система хранения архивных данных в Вашей инфраструктуре) становится специализированной.
Нет конечно! Но Air gap - не замена того бэкапа, который у вас уже есть. Это дополнение.
А что это меняет? Заберет сервер с пользовательского компьютера вирус. Тот зашифрует все, что есть на сервере...
Русское слово "Том" является прямым переводом английского слова Volume. И это никакого отношения не имеет к тому, какое у вас устройство - блочное, файловое или объектное, типа S3.
Похоже, что термин "репозиторий" применительно к S3 ввели в Amazon. Но я достаточно стар, чтобы помнить времена, когда Amazon был магазином книжек и делал только робкие попытки продавать ихз через Интернет. И вот тогда репозитории уже вполне себе существовали. Например Linux репозитории - это то место, откуда мы пакеты берем. И никакого отношения к СХД они не имели.
Последнее время люди вообщще очень вольно к терминам относятся... /немного песка посыпал ))/
Ухх... Opensource - это значит, что за код вообще никто не несет ответственности, и какие там дыры - вы просто не знаете. Поэтому да, вы сделали что-то сильно небезопасное.
Но, опять таки, все решает ваша толерантность к риску. Если ваши данные легко восстановимы или просто не очень дорогие, то Opensource - отличный выбор! Он может быть отличным выбором даже если у вас очень важные данные. Но только если это НЕ все, на что вы полагаетесь при их защите.
Не все так печально. Можно и автоматически ))
Ну и не отменяет это необходимости в online бэкапе. Я ж специально в конце написал - это не замена, а дополнение к политике резервного копирования и DR.
Air gap - это довольно радикальный метод. И нет ничего удивительного, что люди ищут такие реализации, которые и риски снизят, и хоть какую-то гибкость дадут. Самый надежный сервер, как известно - тот, который выключен в сейфе.
Все решает модель угроз компании и ее толерантность к риску.
От пожара вам поможет просто репликация в другое место. Не нужно усложнять себе жизнь, если ваша угроза - пожар или наводнение. Air gap backup - это от другой угрозы.
Ну, как минимум есть особенности.
Вам нужно достаточно дешевое хранение. Не на NVMe точно. И технологии оптимизации очень не помешают.
Изоляцию обеспечить не так уж и просто. Выше был комент про IPMI. Вам нужно придумать, как вы делаете резервные копии, и как вы их храните вне сети. Руками каждый раз разрывать связь - не вариант. Значит нужна автоматизация.
Угроза изменилась. Раньше бэкап был средством защиты от сбоя или аварии. Причем непреднамеренного сбоя или аварии. То есть достаточно было его хранить там, где его не затронет, например, пожар в DC. И не было проблем, если он был в сети - пожар по интернету не распространяется. А теперь нужно данные защищать уже от намеренного уничтожения. Зловред - не пожар. Ваши архивы для него тоже цель.
То есть да, СХД, как устройство, может быть общего назначения. А вот СИСТЕМА (в смысле информационная система хранения архивных данных в Вашей инфраструктуре) становится специализированной.
Вы правы. Если злоумышленник получает доступ к IPMI - это все-равно, что физический доступ получить.
Статья задумывалась как обзорная. В детали специально не погружались. Может быть отдельно напишем про именно техническую реализацию.