Недавно один из наших клиентов прошел аудит ИТ-сети у другой (сторонней) ИТ-аудиторской фирмы. Результаты в целом были хорошими, хотя они указали, что мы использовали клиент iSCSI на Windows Server в качестве средства подключения к NAS, вместо создания общего ресурса SMB на NAS. Они предположили, что это плохая идея:
«Существует [также] угроза безопасности при атаках iSCSI и программ-вымогателей, когда незаконное шифрование может быть выполнено на диске iSCSI, оставляя данные нечитаемыми. С точки зрения безопасности рекомендуется отказаться от этого метода совместного использования данных и принять подход совместного использования».
Что они имеют в виду? Имеется в виду, что iSCSI работает на более низком уровне OSI (сеансе), чем SMB (приложение), а диск iSCSI представляет на уровне приложения так же, как локально подключенный диск, поэтому его легче скомпрометировать?
Если да, то это правильно?
Я не эксперт по вопросам безопасности, хотя наша работа часто носит криминалистический характер. Насколько я понимаю, программа-вымогатель с такой же вероятностью атакует данные на общем SMB-ресурсе, доступном для данной машины Win, как и диск iSCSI.
Я правильно понимаю, или я что-то упустил?
Дополнительный контекст к вопросу
Пароль CHAP установлен на сервере iSCSI, поэтому я предполагаю, что их мнение связано с компрометацией сервера Win, на котором установлен клиент iSCSI.
Когда-либо подключается только один клиент iSCSI, и приняты очень строгие правила "кибергигиены", чтобы гарантировать, что этот пароль никогда не вводится на какой-либо другой сервер или машину в сети или за ее пределами.
Как правило, мы предпочитаем использовать iSCSI для предоставления доступа к дискам NAS для Windows Server. Мы обнаружили, что когда Windows заботится о файловой системе, у нас нет проблем с записями расширенного управления доступом (ACE) в DACL. Например, реализация QNAP в прошлом содержала ошибки в отношении упорядочивания ACE, что может быть проблематичным. Мы также обнаружили ошибку с установкой CONTAINER_INHERIT_ACE для дочерних объектов (сообщена QNAP, но до сих пор не устранена). Этот момент не имеет прямого отношения к этому вопросу, но дает некоторый контекст того, почему мы предпочитаем iSCSI.
Вопреки моему вышесказанному, в случае с этим конкретным клиентом рассматриваемый подключенный диск iSCSI отформатирован с помощью ReFS, поскольку он используется в качестве хранилища резервных копий Veeam. Хотя технически это и не требуется, Veeam рекомендует использовать ReFS вместо NTFS из соображений производительности, поэтому мы предпочитаем этот вариант. (Вот хорошая статья объяснение ReFS и NTFS для резервного копирования.) Эти преимущества возможны только при использовании iSCSI, а не при перемещении NAS на SMB.
Я уже немного ознакомился с этой темой и не смог найти никаких подтверждающих доказательств того, что iSCSI более подвержен воздействию программ-вымогателей, чем подключение через общий сетевой ресурс, однако я остаюсь открытым.
Любой записываемый онлайн-диск может быть поврежден вредоносным ПО или пользователем. Недооценивать их, полагая, что они не могут найти общий доступ к файлам, является ошибкой.
Последняя линия защиты важных данных всегда проверено, холодное автономное резервное копирование. И в этом случае важные данные могут включать сами резервные копии! Подумайте о возможных способах сделать архивы резервных копий невозможными для изменения. Съемный носитель (лента), неизменяемое облачное хранилище с учетными данными, используемыми только для резервного копирования, выделите NAS для резервного копирования и больше ничего не подключайте, брандмауэр все, кроме портов программного обеспечения резервного копирования, отключите общий доступ к файлам.
Другой элемент управления - разрешить перечисление программного обеспечения, значительно ограничивающее запуск неизвестных вещей.
Предоставленный вами контекст указывает на то, что вы подумали об этом, объясняя, что вы используете протокол, это хорошо. Подумайте немного выше, чем этот вопрос, и укажите в ответе, какие меры защиты существуют в плане обеспечения непрерывности бизнеса.
Оставляя в стороне вопрос об уязвимости iSCSI при использовании его без кластерной файловой системы, но с несколькими инициаторами, я не могу найти какой-либо четкой причины, по которой протокол обмена файлами был бы более безопасным с точки зрения программ-вымогателей по сравнению с iSCSI. Вы получаете CHAP для усиления аутентификации и IPSec для защиты передачи данных по сети. Вот хорошее общее прочтение того, почему iSCSI: https://www.starwindsoftware.com/blog/complete-an-infrastructure-project-for-your-organization-with-iscsi-san
В противном случае это скорее вопрос общей безопасности резервного сервера, например, его отделение от вашей основной производственной среды, вне домена и с отдельной учетной записью (не администратором домена) и так далее. В любом случае, если вам удастся загрузить программу-вымогатель на сервер резервного копирования, не имеет большого значения, используете ли вы, например, общий ресурс SMB в качестве хранилища резервных копий (https://helpcenter.veeam.com/docs/backup/vsphere/smb_share.html?ver=100) или хранилище iSCSI.
Да, любой протокол доступа к сетевым данным на уровне файлов БЕЗОПАСЕН по сравнению с блочным протоколом (iSCSI, FC, FCoE и т. Д.) Из-за невозможности повредить том с помощью «сетевого перенаправителя», что очень легко сделать с неправильно настроенным кластеризованным или любая локальная файловая система (EXT3 / 4, ReFS, XFS и т. д.). Здесь хорошо освещена вся история:
https://forums.starwindsoftware.com/viewtopic.php?f=5&t=1392