Безопасность Виртуализации. Часть 2

Продолжение перевода статьи «Virtualization Security» за авторством Terry Komperda.

Часть 2.

7. РЕКОМЕНДАЦИИ И ОПТИМАЛЬНЫЕ МЕТОДЫ ПО БЕЗОПАСНОЙ ВИРТУАЛИЗАЦИИ

7.1 Доступ Администратора и Разделение Обязанностей

• Предоставьте администраторам серверов права на включение/выключение только своего сервера.
• Возможно вы захотите дать администраторам права на развертывание новых ВМ, а не на редактирование уже существующих виртуальных машин. Другие администраторы, в свою очередь, будут иметь права только на изменение уже существующих ВМ, а не на создание новых.
• Отдельная аутентификация должна присутствовать для каждой гостевой ОС, если только нет веских оснований, чтобы два или более гостей могли использовать одни и те же данные.
• Это может показаться противоречащим общей мысли, но чем больше среда, тем проще разделять права по функциям. Один администратор не может одновременно управлять и хранением, и доменами, и виртуализированной инфраструктурой и сетями.

7.2 Виртуализация настольных компьютеров и Безопасность
Следующие пять эффективных мер позволят убедиться, что в среде не существует несанкционированной и небезопасной виртуализации:

1. Обновляйте политику допустимого использования.
   Излагайте точные условия, при которых можно устанавливать программное обеспечение для виртуализации и определите какие для этого требуются подтверждения. Укажите какие программы можно запускать и каким образом они должны быть защищены. Четко определите последствия, с которыми столкнутся сотрудники, если не будут соблюдать правила.
2. Ограничьте использование виртуальных машин только для пользователей, которые нуждаются в них
   Большинству пользователей не требуется наличие ВМ на их компьютерах. Запретите установку свободно загружаемого ПО для корпоративных настольных компьютеров и ноутбуков. Ограничьте права небольшой группой разработчиков и тестировщиков виртуальных инструментов и ВМ, и помогите им понять, что они по-прежнему должны придерживаться корпоративной политики безопасности.
3. Всегда заботьтесь о том, чтобы ваше ПО виртуализации и антивирусное ПО были актуальными
   Убедитесь в том, что на всех ВМ есть такие же межсетевые экраны, антивирус и IDS/IPS, как и на настольных компьютерах и ноутбуках.
4. Выбирайте политику безопасности, которая поддерживает виртуализацию
   Убедитесь в том, что нет известных конфликтов политики безопасности с существующими платформами виртуализации.
5. Создайте и обновляйте библиотеку безопасных ВМ билдов
   Создайте репозиторий ВМ-билдов, содержащий все параметры конфигурации, ПО безопасности и патчи, которые могут быть скачаны пользователями для собственного использования.

7.3 Сетевая безопасность

• Отсоедините все неиспользуемые платы NIC, чтобы не было простого способа попасть в сеть.
• Убедитесь в том, что хост-платформа, которая подсоединяет гипервизор и гостей к физической сети, безопасна путем установки разрешений для файлов, управления пользователями и группами, и настроив логгирование и синхронизацию времени.
• Шифруйте весь трафик между клиентами и хостами, между системами управления и гипервизором, и между гипервизором и хостами с помощью протокола SSL.
• Обезопасьте IP-коммуникации между двумя хостами с помощью шифрования и проверки подлинности каждого IP-пакета.
• Не используйте самоподписанные сертификаты или сертификаты по-умолчанию — они уязвимы для атак типа «злоумышленник в середине».
• Помещайте виртуальные свичи в смешанный режим для целей мониторинга и включите фильтрацию MAC-адресов для предотвращения MAC-спуфинга.

7.4 Сети Хранения Данных

• iSCSI и NFS должны быть размещены на выделенных сетях хранения данных или сетях VLAN без маршрутизации.
• Используйте протокол IPSec для шифрования трафика iSCSI для предотвращения снупинга (отслеживания).
• iSCSI поддерживает протокол аутентификации по квитированию вызова (CHAP), и это должно использоваться в целях проверки подлинности до предоставления доступа.
• При использовании iSCSI или NFS, используйте физические свичи для обнаружения и запрета IP или MAC-адреса.
• NFS легко настроить, но это наименее безопасный выбор для хранения. Настройте NFS сервер, ограничив доступ к определенным IP-адресам, связанным с вашими гипервизорами, или используйте брандмауэр для ограничения трафика для конкретных хостов. Если NFS-сервер поддерживает IPSec, используйте его для обеспечения безопасности трафика между сервером NFS и гипервизором.
• Весь трафик на и от репозиториев должен быть изолирован от трафика системы хранения данных.
• Не отправляйте оптоволоконный трафик через Ethernet (FCOE), так как это объединяет трафик хранения данных с другими типами данных.
• Используйте зонирования для оптоволоконного канала, что фактически является контролем доступа на уровне свича и аналогично VLAN. Несмотря на многочисленные топологии, самой простой и безопасной формой является зонирование. Адаптер шины находится в своей собственной зоне с целевым устройством для предотвращения попыток инициаторов общаться друг с другом.

7.5 Восстановление после аварий

• Держите межсетевой экран, средства обеспечения безопасности и IPS/IDS на вашем узле аварийного восстановления. Если брандмауэр отключен на узле аварийного восстановления, проверяйте его регулярно до тех пор, пока не произойдет чрезвычайная ситуация или правила данного брандмауэра не будут отличаться от основных.
• Осуществляйте надлежащий контроль изменений, чтобы резервная копия и основной узел были настолько идентичны, насколько это возможно.
• Логгирование и мониторинг на узле аварийного восстановления следует рассматривать так же, как если бы эти действия выполнялись на основном узле.
• Проводите аудит и испытания на преодоление вашего узла аварийного восстановления отдельно от основного, но с такой же частотой и придавая процессам такое же значение.
• Любое точное повторения вашего узла резервного копирования должно быть зашифровано.
• Поместите копию вашего плана аварийного восстановления на удаленном местоположении.
• Перемещайте свои средства резервного копирования и храните их в автономном месте.

7.6 Аудит и логгирование

• Используйте централизованное логгирование чтобы определить, перешли ли гости в режим оффлайн. Эти гости могут десинхронизироваться из-за патчей и обновлений. Логируйте события на ВМ (такие как включение, выключение, приостановление, возобновление), изменения в конфигурации аппаратного обеспечения или любой вход в систему, связанный с повышенными привилегиями. Следует отслеживать и логгировать все виртуальные машины, которые были скопированы, перемещены или удалены.
• Файлы проверки должны быть доступны только для чтения и должны быть прочитаны только сотрудниками, занимающимися аудитом в целях сохранения целостности информации. Несанкционированные попытки получения доступа к файлам аудита и к другим виртуальным ресурсам должны тоже логгироваться.
• Проводите регулярные проверки среды, включая виртуальные сети, системы хранения данных, гипервизор, ВМ и системы управления.
• Отправляйте файлы логов на удаленный сервер.

7.7 Безопасность виртуальной машины

• Виртуальные машины не должны быть размещены в системах хранения данных, резервного копирования и управления сетями, которые подключены к гипервизору.
• Скринсейверы абсолютно не нужны на виртуальных машинах. Кроме того, не используйте на физических серверах заставки, сильно задействующие процессор, так как они могут перегрузить ресурсы процессора, необходимые для ВМ.
• ВМ не должны иметь доступ или просматривать ресурсы, используемые ядром или хостом. Эти ресурсы включают в себя сети хранения данных и сети, ответственные за перемещение виртуальных машин.
• Не создавайте больше виртуальных машин, чем требуется. Отслеживайте все свои запущенные ВМ для отслеживания потенциальных точек проникновения для атак. Ограничивайте использование ВМ только кругом критичных сотрудников.
• Отключайте все неиспользуемые ВМ.
• Неиспользуемые физические порты, например, USB на ВМ, следует отключать.
• Используйте IPSec или другие формы шифрования между хостом и ВМ.
• Подготовьте все необходимое дл планирования, развертывания, исправления и резервного копирования своих виртуальных машин.
• Физические устройства, такие как CD-ROM и флоппи-дисководы, могут управляться косвенно ВМ или напрямую хостом. Настройте эту функцию отдельно на каждой ВМ и на всех виртуальных машинах отключите подключение к хосту по-умолчанию. Если этого не сделать, то ВМ может запросить доступ к хосту в ходе загрузки и другие виртуальные машины могут быть заблокированы, задерживая тем самым процесса загрузки.
• Возможно вы захотите рассмотреть возможность использования VLAN на одном виртуальном свиче для сегментации трафика.
• Когда ВМ перемещаются, активная память и состояние передаются по сети на новый хост в виде нешифрованного текста. Изолируйте это движение трафика из сети организации на изолированной сегмент, который не доступен и настраивается с помощью отдельного коммутатора vswitch или сети VLAN.
• Любые приостановленные ВМ должны быть запущены в тестовой или лабораторной среде, чтобы любые изменения конфигурации были протестированы для предотвращения взломов в производственной среде.
• ВМ не должна иметь прямой доступ к хранилищу данных виртуальных машин или к репозиторию.
• Рассмотрите виртуальные модули для обеспечения антивирусной защиты ваших ВМ. Такие модели обеспечивают подход без участия агента. Производительность улучшится, так как обработка не лежит на отдельной виртуальной машине. Недостаток некоторых из этих моделей заключается в том, что они обеспечивают защиту от вирусов, а не дополнительный контроль модулей, IDS/IPS, межсетевых экранов и веб-фильтрации, которые присутствуют в более традиционных модулях.
• Рассмотрите вопрос о помещении виртуального модуля на хост, подключив к ВМ небольшой драйвер, который снимет процессы обновления с отдельных виртуальных машин. Центральная база сигнатур позволяет убедиться, что защита всегда актуальная, даже если ВМ ранее находилась оффлайн. Безопасность также следует за рабочей нагрузкой, так как перемещается с хоста на хост. Такой подход может также применить защиту к определенным группам ВМ или выполнить глубокое сканирование на некоторых выбранных машинах.
• Политика безопасности может использоваться в целях убедиться в том, что новой ВМ не разрешено присоединиться к группе виртуальных машин или кластеру, если у нее нет конкретных настроек или не установлены определенные обновления.
• Не устанавливайте рабочие нагрузки с различными уровнями доверия на одном и том же домене безопасности или на том же физическом сервере. Есть вероятность смешения уровней доверия, когда пользователи могут создавать и развертывать свои собственные ВМ.
• Некоторые организации ограничивают число виртуальных машин на одном физическом сервере, или назначают физические сетевые адаптеры для каждой ВМ в целях изоляции. Другие компании не позволяют ВМ перемещаться на другие хосты. Хотя безопасность и важна, убедитесь, что вы не убиваете все преимущества виртуализации такими стратегиями.
• Будьте осторожны в принятии одной ВМ или небольшой группы виртуальных машин и затем при их назначении в сеть VLAN для разделения и изоляции. Это может привести к росту сети VLAN и к дополнительным сложностям, создавая дополнительные задачи для администратора.
• Ограничивайте доступ к бездействующим виртуальным машинам.
• Любые ВМ, помещенные в DMZ, открыты для доступа через Интернет и открыты для атаки. Не допускайте ВМ в DMZ иметь доступ к системе хранения или сетям.
• Когда две или более виртуальных машин находятся на одном и том же VLAN и виртуальном свиче, трафик между ВМ не защищен. Рассмотрите вопрос о включении виртуальных межсетевых экранов на этих виртуальных машинах в целях безопасности.
• Установите ограничение на процессор любых виртуальных машин, которые могут получить доступ в Интернет. Таким образом, если ВМ взломаны, атака не будет запущена на других хостах.
• Если пользователям разрешено создавать виртуальные машины, рассмотрите вопрос о том, чтобы разрешить им создавать ВМ по авторизованному шаблону.
• Рассмотрите вопрос о развертывании ВМ безопасности, чтобы ликвидировать агента на каждой виртуальной машине. Это может устранить антивирусные бури и другие затруднения, которые возможны если все хосты и виртуальные машины начнут одновременно выполнять сканирование на наличие вредоносных программ.
• Проверьте ОС на ВМ с помощью сценария и логина пользователя для того, чтобы убедиться, что виртуальные машины были обновлены. Если виртуальная машина не совместима с обновлениями, сценарий может отсоединить пользователя и оповестить службу поддержки. Или, не отвечающие требованиям ВМ могут храниться в DMZ или среде тестирования, и не иметь доступ к сети, пока не будут обновлены надлежащим образом.
• Отключите любую функциональность копирования и вставки в целях защиты конфиденциальности данных и целостности гипервизора и виртуальных машин.
• Виртуальный межсетевой экран, подсоединенный к ВМ, всегда перемещается вместе с ней, чтобы убедиться, что политика в области безопасности обеспечивается до, во время и после любых перемещений.
• Шлюз безопасности (firewall и IDS/IPS) может использоваться для проверки трафика между виртуальными машинами.
• Убедитесь, что любые ВМ, которые обрабатывают защищенную информацию, изолированы от других виртуальных машин с той целью, чтобы данные не сочетались с другими данными или были доступны с других виртуальных машин.

7.8 Системы Управления

• Обезопасьте связи между системами управления и хостами для предотвращения потери данных, подслушивания и любого шанса для атаки типа «злоумышленник в середине». Включите один или несколько доступных SSH, IPSec и SSL протоколов для этой цели.
• Используйте единую систему управления и политику безопасности для покрытия и физических, и виртуальных сред. Если не применить этот подход — Вам нужно будет удвоить работу по созданию отчетов и проведению анализа каких-либо проблем.
• Не допускайте чтобы административный сервер был доступен со всех рабочих станций. Взлом этого сервера может оказать влияние на виртуальные машины и хранилища данных. Чтобы не допустить этого, установите сервер управления на отдельный от подсети пользовательских компьютеров VLAN и затем поместите его за брандмауэром. Это две полностью разные зоны безопасности. Определите контрольные списки доступа к свичам сети и установите соответствующие правила брандмауэра. Измените разрешения по умолчанию на этих серверах, чтоба у администратора не было доступа к целой среде.
• Отделяйте административные серверы от серверов баз данных.

7.9 Безопасность Гипервизора

• Установите исправления и обновления от производителя гипервизора сразу же, как только они станут доступны. Поддержите это исправным процессом управления патчами для уменьшения риска уязвимостей гипервизора. Установите последнюю версию service pack на гостевых компьютерах и на хосте, а также удалите любые приложения с историей уязвимостей.
• Отключайте любое неиспользуемое виртуальное железо, которое подключается к гипервизору.
• Отключайте ненужные сервисы, такие как буфер обмена или совместное использование файлов.
• Регулярно проверяйте гипервизор на предмет наличия любых потенциальных признаков взлома. Постоянно отслеживайте и анализируйте логи гипервизора.
• Не выставляйте интерфейс управления для гипервизора в вашей локальной сети.
• Отключите все локальное управление гипервизором и требуйте использования приложения централизованного управления.
• Введите двухфакторную аутентификацию для любых действий администратора на гипервизоре.

7.10 Снимки и изображения

• Никакие гостевые изображения ОС не дожны иметь прав на запись.
• Защищайте виртуальные машины при помощи функциональности мгновенных снимков гипервизора, так как скриншоты могут запечатлеть текущее состояние ВМ. На скриншоте сохраняется ОС, параметры конфигурации, состояние данных и приложений, содержащихся на ВМ в определенный момент времени.

7.1 Синхронизация времени

• Временный Сетевой Протокол (NTP) должен быть включен и настроен для синхронизации с сервером единого времени рядом с вашей сетью и NTP должен работать на хосте. Гостевые виртуальные машины следует использовать либо на том же сервере, где находится хост, либо использовать сам хост в качестве NTP-сервера. Если слой ВМ позволяет гостевой ОС синхронизировать время непосредственно с сервера, то это следует использовать, так как это наиболее простой в реализации способ.
• Механизм хэширования ключей аутентификация должен использоваться между NTP-пирами для предотвращения несанкционированного доступа.

7.12 Удаленный доступ

• Некоторые фирмы используют удаленное администрирование (VNC) как кроссплатформенную функцию удаленного рабочего стола. Сообщения не всегда шифруются при использовании. Шифрование может поставляться в настройках поставщика или через сторонние плагины. Не давайте этим VNC-подключениям подключиться к Интернету, независимо от того, зашифрованы они или нет. Контролируйте эти соединения через VPN или SSH тунеллирование.
• Управление удаленным доступом должно быть ограничено небольшим набором системных IP-адресов, имеющим доступ к этим функциям.
• Любой удаленный доступ должен спрашивать имя пользователя и пароль, дополнительно применяя политику сложных паролей. Для надежной защиты среды используйте двухэтапную аутентификацию или одноразовые пароли.
• Удаленная связь с любыми инструментами управления должна быть зашифрована и подлежать проверке подлинности.
• При использовании SSH отключайте протокол версии 1, отключите admin или root вход SSH и требуйте от пользователей использовать контроль доступа на основе ролей или пользоваться своими отдельными учетными записями. Используйте команду типа Sudo, так как она позволит записать все действия в лог (в котором будет указано что было сделано, когда и кем).
• Не допускайте любого удаленного доступа к серверу или гипервизору.

7.13 Резервное копирование

• Шифруйте любые потоки данных резервного копирования в случае если серверный образ будет украден. Хранимые данные должны иметь контрольные списки доступа для контролирования действий по копированию или монтированию образов.
• Защита уровней сети, например, VLAN, а также контрольные списки доступа должны обязательно присутствовать для защиты данных бекапа (хранимых или передаваемых).
• Не допускайте использования root-учетных записей для резервного копирования.
• Любые бекапы, которые отправляются на узел аварийного восстановления по сети должны быть надежно зашифрованы.
• Регулярно выполняйте резервное копирование ОС и данных, а также делайте полный бекап раз в неделю. Дополните резервное копирование решениями удаленного хранения и внешнего хранения резервных носителей.
• При использовании виртуализации резервное копирование дисков так же важно, как и в традиционных средах. Бекапы виртуальных хранилищ также должны быть включены в вашу политику резервного копирования.

7.14 Настройка и Управление Изменениями

• Убедитесь, что любые физические или виртуальные серверы защищены, прежде чем начать их развертывание. Следите за любыми изменениями конфигурации для обнаружения несанкционированных изменений или отклонений от соответствий в связи с установкой обновлений или патчей.
• Защищайте физические и виртуальные свичи, а также виртуальное железо и шлюзы перед их развертыванием.
• Не позволяйте вносить изменения в инфраструктуру без документации и тестирования в лабораторной среде, которая максимально идентична рабочей среде. Ответьте на эти вопросы, прежде чем вносить какие-либо изменения:
• Каковы последствия изменений?
• Кто и что окажется под влиянием?
• Насколько велик потенциальный риск от изменения?
• Можно ли откатить изменения, если это необходимо?
• Сколько времени потребуется на откат изменений?
• Отслеживайте конфигурации ВМ и предупреждения о том, что требуется внести изменения в требуемую конфигурацию.
• Убедитесь, что существующие продукты управления патчами поддерживают работу в виртуальной среде и платформах.

7.15 Серверные пулы и Предложения виртуального обслуживания

• Сегментируйте серверные пулы, в случае если они содержат различные уровни серверов, такие как общедоступные веб-серверы и сервера базы данных, которые содержат информацию личного порядка. Обязательно используйте средства защиты, чтобы сервера были защищены от доступа из Интернета и с самих себя. Отказ от применения сегментации в серверных пулах может означать, что при взломе одного сервера будет оказано негативное влияние на весь пул серверов.
• Для предложений виртуальных служб (VSO), выполняйте резервное копирование любых данных пользователя, данных организации, документов, баз данных, информации о состоянии на виртуальные сервера, а также любые данные службы Active Directory, используя стандартную стратегию и политику резервного копирования.
• Отделяйте серверные пулы от VSO с точки зрения безопасности. Пользователи, взаимодействующие с VSO, не должны иметь доступ к физическим серверам, которые подконтрольны администраторам.
• Вышеуказанные практические советы и рекомендациии будут эффективными, если их использовать вместе с уже существующими традиционными мерами безопасности, а не являются заменой уже развернутых средств безопасности. Тем не менее, виртуализация достаточно отличается в том плане, что если не применить эти рекомендации — Вы не получите полностью защищенную гибридную (физическую и виртуальную) среду.

8. ДОПОЛНИТЕЛЬНЫЕ ВОПРОСЫ, РЕКОМЕНДАЦИИ И СОВЕТЫ ДЛЯ ВИРТУАЛИЗИРОВАННОГО ОБЛАКА
Многие из вышеупомянутых рекомендаций и советов являются эффективными для центра обработки данных, корпоративных и облачных сред, но само Облако отличается от двух вышеупомянутых сред и ему требуются и другие средства защиты из-за масштаба, мультитенантности и того факта, что ВМ не всегда остается в рамках уютного физического периметра, вокруг которого можно создать систему безопасности. Ниже приводятся некоторые из важных пунктов, которые необходимо принять к сведению:

• Безопасность гипервизора является еще более важной в Облаке из-за масштабов потенциального взлома.
• ВМ необходимо отслеживать их владельцам на протяжении всего жизненного цикла виртуальных машин. Они должны быть размещены на серверах, удовлетворяющих требованиям collocation других виртуальных машин, и должны использовать тегирование ВМ для целей отслеживания.
• Для изоляции трафика одной пользовательской ВМ от другой пользовательской ВМ нужно использовать VLAN. Это требуется расширение VLAN за пределы основной инфраструктуры свича. Возможна проблема с масштабированием возможностей VLAN для поддержки облаков очень большого размера.
• Автоматизация необходима для безопасности в облаке из-за его масштаба. Безопасность в облаке должна быть лучше спланирована и лучше управляться.
• Утилизация IP адресов и ID может быть проблемой, если пользователь может получить доступ к данным другого клиента. Должен быть надежный процесс, позволяющий применить назначение и переназначение ВМ.
• Центральное хранилище является привлекательным объектом в облаке. Защита данных и шифрование должны быть надлежащим образом применены везде, где данные хранятся, передаются или обрабатываются.
• Необходимо иметь стандарты, если планируется осуществить перемещения на другой Провайдер Облачного Сервиса (Cloud Service Providers (CSP)). Это касается данных, брандмауэров, виртуальных машин и настроек сети.
• Пользователям облака важно, чтобы их данные хранились отдельно от данных других пользователей в едином облачном хранилище.
• Нужно использовать автоматизированные инструменты управления жизненным циклом для отслеживания новых развертываний. CSP также должны сообщать клиентам, чтобы они ограничивали число пользователей, которые могут вводить в эксплуатацию ВМ.
• Следует использовать стандартные образы ВМ для поддержания целостности окружающей среды.
• Виртуальную машину для выделенного сканирования нельзя использовать в облаке для защиты других ВМ, так как они не контролируют гипервизор. В многопользовательской среде следует использовать подход на основе агентов.
• Ключи шифрования для дата-центров должны быть защищенными. Когда ключи защищены должным образом, неподконтрольные ВМ попавшие в дата-центры становятся немонтируемыми и нечитаемыми.
• Политика безопасности, привязанная к физическим атрибутам, таким как физический сервер, IP адрес или разграничение физического хоста (используется для изоляции или MAC-адресов), не имеют смысла в облаке. Политику безопасности следует привязать к логическим атрибутам, а не к физическим. Становятся важными идентификация, группа или роль пользователей приложения, а также чувствительность нагрузки. Политика должна быть контекстно-зависимой и адаптивной.
• Стандарты нужны для соединения воедино всей безопасности в облаке. Клиенты и CSP должны разграничить между собой обязательства по безопасности.
• В такой инфраструктуре как сервисная среда клиент несет ответственность за поддержание версий исправлений любых назначенных ВМ, а также отвечает за правильную настройку VPN после первоначальной установки.
• Старая модель контроля доступа основана на машинах и сфокусирована на IP. Модель в облаке должна быть основана на пользователе. Контроль Сетевого Доступа (Network Access Control (NAC)) определяет кто вы и к чему у вас есть доступ. Контроль доступа должен быть динамичным, так как пользователи приходят откуда угодно, в любое время, с любого устройства, а также могут запрашивать доступ одновременно с нескольких устройств.
• Предотвращение Потери Данных (DLP) становится чрезвычайно важным процессом и нужно использовать отпечатки пальцев, чтобы инструменты слежения за DLP могли распознавать данные. Когда происходит нарушение политики, необходимо ввести карантин и ответные меры.
• Защита и сканирование приостановленных ВМ остается CSP.
• Полное сканирование системы в облаке не следует использовать, так как это ухудшает производительность.
• Если это предлагается CSP, пользователи должны использовать выделенные ресурсы, так как они более безопасные.
• Облако расширяет сферу задач по безопасности для обеспечения защиты ресурсов и данных пользователей. Поверхность для атаки гораздо больше из-за своих масштабов и любое нарушение может оказать влияние на различных клиентов и все данные, хранение которых они доверили провайдеру облачного сервиса.

9. ЗАКЛЮЧЕНИЕ
Виртуализация привносит новые проблемы в области безопасности для фирм. Виртуальные компоненты и среду нельзя защитить только при помощи существующих механизмов и процессов безопасности. Виртуализация создает другую сеть, которая является гибридом между созданной физически центрированной сетью и новой виртуальной или логической средой. Чтобы убедиться, что безопасность находится на должном уровне, следует рассматривать множество факторов и дополнительных степеней защиты наряду с дополнительным планирование и подготовкой, а также обучением персонала. Безопасность виртуализации не должна быть тем, о чем Вы подумаете уже после того, как создана новая виртуальная инфраструктура и все компоненты находятся на месте. Безопасность в этой области будет улучшаться вместе с развитием технологии виртуализации. В этой сфере необходимо применять стандарты, чтобы у фирм были правила, которым нужно следовать в новой среде.

Автор: chemtech

Источник