Недавно один из наших клиентов провел аудит ИТ-сети в другой (сторонней) ИТ-аудиторской фирме. Результаты были в целом хорошими, хотя они указали, что мы использовали клиент 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 более подвержен программам-вымогателям, чем подключение через сетевой ресурс, однако я остаюсь непредвзятым.
решение1
Любой онлайн-диск, доступный для записи, может быть поврежден вредоносным программным обеспечением или пользователем. Недооценивать их, предполагая, что они не могут найти общий файл, — ошибка.
Последняя линия защиты важных данных всегдапроверено, холодные офлайн-резервные копии. И в этом случае важные данные могут включать в себя сами резервные копии! Подумайте о возможных способах сделать архивы резервных копий не подлежащими изменению. Съемные носители (лента), неизменяемое облачное хранилище с учетными данными, используемыми только для резервного копирования, выделите NAS для резервного копирования и не подключайте ничего другого, заблокируйте все, кроме портов программного обеспечения для резервного копирования, отключите общий доступ к файлам.
Другим элементом управления является список разрешенных программ, что существенно ограничивает запуск неизвестных программ.
Контекст, который вы предоставили, показывает, что вы думали об этом, объясняя, что ваше использование протокола является хорошим. Подумайте немного выше уровня этого вопроса и включите в ответ, какие средства защиты существуют в плане обеспечения непрерывности бизнеса.
- Когда проводился последний тест восстановления из резервной копии, соответствовал ли он целевым показателям точки восстановления и времени восстановления?
- Доказал ли кто-нибудь, что холодные резервные копии не находятся в сети и не уязвимы, например, с помощью учений «красной команды»?
- Когда в последний раз у вас возникали проблемы с программами-вымогателями, и что было сделано для улучшения технического или технологического контроля?
решение2
Оставляя в стороне вопрос об уязвимости 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.
решение3
Да, любой сетевой протокол доступа к данным на уровне файлов БЕЗОПАСНЕЕ по сравнению с блочным (iSCSI, FC, FCoE и т. д.) из-за невозможности повредить том с помощью "сетевого редиректора", что очень легко сделать с неправильно настроенной кластерной или любой локальной файловой системой (EXT3/4, ReFS, XFS и т. д.). Вся история хорошо освещена здесь:
https://forums.starwindsoftware.com/viewtopic.php?f=5&t=1392