Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Поток Информационная безопасность доступен 24/7 благодаря поддержке друзей Хабра
Комментарии 23
Интересная идея!
В качестве средства изоляции можно добавить в скрипт резерного копирования включение портов коммутатора (или еще лучше - LACP интерфейса) и отключение после окончания процесса копирования. Мониторинг NAS в любом случае остается доступен через IPMI.
Спасибо за статью!
Если есть доступ по IPMI, значит есть полноценный доступ к данным (в большинстве систем).
Вы правы. Если злоумышленник получает доступ к IPMI - это все-равно, что физический доступ получить.
Статья задумывалась как обзорная. В детали специально не погружались. Может быть отдельно напишем про именно техническую реализацию.
Если у вас ipmi/idrac/ilo вообще доступен из общей сети - это уже очень плохо. Хорошая практика для менеджмент операций - отдельный vlan, отдельная подсеть, отсутствие маршрутизации между общим и менеджмент сегментами, ещё лучше - и отдельный комп для управления (вариант - использование Hop сервера или PAM с 2FA/MFA). И крайне желательно, при возможности, - ограничение подключений к серверам по ssh/rdp на уровне локальных файрволлов серверов. И да, ограничения на подключение в настройках ipmi etc. тоже совсем не лишни.
Это давно реализовано и прекрасно работает. Включение устройства через WOL и выключение после того как закончится репликация
буквально на днях...одно хранилище для бэкапов(отключается от сети самостоятельно дергая питание коммутора) подключилось во время работы ransomware и было им поедено, второй сборщик(этот переносной и тупо wifi включает/выключает) подключился сильно позже и успешно обновил устаревшие бэки новым уже мусором.
и как бы несколько копий и аир гап, но при определенном стечении обстоятельств этого мало
Что-то из текста я так и не понял, как "специализированные схд" (я так понимаю под ними подразумеваются DD и SO) позволяют обеспечить физическое разделение, у котором идёт речь выше!?
Ну, как минимум есть особенности.
Вам нужно достаточно дешевое хранение. Не на NVMe точно. И технологии оптимизации очень не помешают.
Изоляцию обеспечить не так уж и просто. Выше был комент про IPMI. Вам нужно придумать, как вы делаете резервные копии, и как вы их храните вне сети. Руками каждый раз разрывать связь - не вариант. Значит нужна автоматизация.
Угроза изменилась. Раньше бэкап был средством защиты от сбоя или аварии. Причем непреднамеренного сбоя или аварии. То есть достаточно было его хранить там, где его не затронет, например, пожар в DC. И не было проблем, если он был в сети - пожар по интернету не распространяется. А теперь нужно данные защищать уже от намеренного уничтожения. Зловред - не пожар. Ваши архивы для него тоже цель.
То есть да, СХД, как устройство, может быть общего назначения. А вот СИСТЕМА (в смысле информационная система хранения архивных данных в Вашей инфраструктуре) становится специализированной.
Вспоминая вид серверной, залитой ржавой водой из некорректно настроенной системы пожаротушения:
air gap должен быть действительно gap, а не галочкой в настройках гипервизора/схд
тома хранения могут создаваться с помощью... сегментации сети как разновидности виртуализации хранилища.
Что это значит?
Почему тома? Тома - термин из области блочных устройств.
А если хранение делается на уровне файлов, например в s3? Не подходит?
Правильнее бы звучало - репозитории.
Логическое разделение
такая изоляция наименее безопасна
Из чего это следует?
Если я делаю чисто логическое разделение, ставлю перед своим 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 в моей внутреней сети...
Это разумеется невероятно.
Гипотетические риски такой небезопасности просто меркнут на фоне практической гиганской кривизны и забагованости проприетарного, особенно местячкового (т.н. импортозамещерованного), ПО, которое подчастую используется для ЫнтырПрайс бекапа... и в том числе прямо следующей из перечисленного небезопасности.
Физическое разделение
Это вообще сомнительная история из мира идеалистов, у которых только крайности.
Причем им невероятно важны только те крайности которые они сами заметили. А то что на практике неразрывно с крайностями в одном вагоне едет еще и гора недостатков. Это идеалистам всеравно, это не тешит их воспаленное самолюбие (я сделал все идеально - "царь во дворца").
А недостатки совершенно понятны:
Бекапы на отделенном (отсоединенном) от сети хранилище нужно таким же "отсоединенным" образом (=руками) выполнять и тестировать.
метрики что бекапа, что тестирования бекапа нужно "отсоединенным" (=руками) образом доставлять в единую систему мониторинга.
И вот мы на практике получаем: мы разменяли гипотетическую (сугубо идеалистическу) безопасность отключеных бекапов, на человеческий фактор их (бекапов) выполнения...
Что тут еще сказать?
Занавес.
Что это значит?Почему тома? Тома - термин из области блочных устройств.А если хранение делается на уровне файлов, например в 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 как бы противопоставляется другим, логическим/виртуальным способам разделения. Называть виртуальную изоляцию или Cloud Sync разновидностью Air Gap только маркетолог может.
А если развернуть логику бекапов?
То есть не пользователь инициирует процедуру, а сервер подключается к пользовательскому компьютеру и выкачивает данные?
Теперь сервер можно переместить в отдельную подсеть с запретом входящих подключений.
Ну, скажем, вопросы сохранности резервных копий в некоторых случаях уже даже присутствует в регуляторной документации и требования обязательны к исполнению. В частности, для банков РК есть требование хранения, как минимум, одного полного комплекта резервных копий ключевых систем оффлайн, в ячейке другого банка.
То, что касается снижения риска повреждения резервных копий, хранящихся в самой организации - ну, тут тоже вопросы даже логического разделения имеют значение. Условно - есть система хранения на лентах, есть, скажем, CommVault, который сам "тащит" бэкапы из гипервизоров, доступ к консоли системы резервирования крайне ограничен (надеюсь, не надо напоминать, что консоли управления оборудованием должны быть выведены в отдельную менеджмент подсеть, доступ к которой из общих сегментов закрыт, и которая не имеет свободного выхода в интернет?). Уже в данном случае риск повреждения резервных копий снижается, и снижается прилично.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Воздушный зазор для бэкапов. Зачем нужен и как работает Air gap