При развертывании Zero Trust для быстрого устранения пробелов в безопасности и улучшения сегментации в существующей (brownfield) или новой (greenfield) среде, клиентам нужен предписывающий многоэтапный рабочий процесс сегментации, разработанный для постепенной защиты восточно-западного трафика в частном облаке VMware Cloud Foundation (VCF)...

В первой части статей этой серии мы рассмотрели некоторые предварительные требования для NVMe Memory Tiering, такие как оценка рабочих нагрузок, процент активности памяти, ограничения профилей виртуальных машин, предварительные требования и совместимость устройств NVMe.

Кроме того, мы подчеркнули важность внедрения платформы VMware Cloud Foundation (VCF) 9, которая может обеспечить значительное сокращение затрат на память, лучшее использование CPU и более высокую консолидацию виртуальных машин. Но прежде чем полностью развернуть это решение, важно спроектировать его с учётом безопасности, отказоустойчивости и масштабируемости — именно об этом и пойдёт речь в этой статье.

Безопасность

Безопасность памяти не является особенно популярной темой среди администраторов, и это объясняется тем, что память является энергонезависимой. Однако злоумышленники могут использовать память для хранения вредоносной информации на энергонезависимых носителях, чтобы избежать обнаружения — но это уже скорее тема криминалистики. Как только питание отключается, данные в DRAM (энергозависимой памяти) исчезают в течение нескольких минут. Таким образом, с NVMe Memory Tiering мы переносим страницы из энергозависимой памяти (DRAM) на энергонезависимую (NVMe).

Чтобы устранить любые проблемы безопасности, связанные с хранением страниц памяти на устройствах NVMe, VMware разработала несколько решений, которые клиенты могут легко реализовать после первоначальной настройки.

В этом первом выпуске функции Memory Tiering шифрование уже входит в комплект и готово к использованию «из коробки». Фактически, у вас есть возможность включить шифрование на уровне виртуальной машины (для каждой ВМ) или на уровне хоста (для всех ВМ на данном хосте). По умолчанию эта опция не активирована, но её легко добавить в конфигурацию через интерфейс vCenter.

Для шифрования в NVMe Memory Tiering нам не требуется система управления ключами (KMS) или встроенный поставщик ключей (NKP). Вместо этого ключ случайным образом генерируется на уровне ядра каждым хостом с использованием шифрования AES-XTS. Это избавляет от зависимости от внешних поставщиков ключей, поскольку данные, выгруженные в NVMe, актуальны только в течение времени жизни виртуальной машины.

Случайный 256-битный ключ создаётся при включении виртуальной машины, и данные шифруются в момент их выгрузки из DRAM в NVMe, а при обратной загрузке в DRAM для чтения — расшифровываются. Во время миграции виртуальной машины (vMotion) страницы памяти сначала расшифровываются, затем передаются по зашифрованному каналу vMotion на целевой хост, где генерируется новый ключ (целевым хостом) для последующих выгрузок памяти на NVMe.

Этот процесс одинаков как для «шифрования на уровне виртуальной машины», так и для «шифрования на уровне хоста» — единственное различие заключается в том, где именно применяется конфигурация.

Отказоустойчивость

Цель отказоустойчивости — повысить надёжность, сократить время простоя и, конечно, обеспечить спокойствие администратора. В контексте памяти существует несколько методов, некоторые из которых распространены больше других. В большинстве случаев для обеспечения избыточности памяти используют модули с коррекцией ошибок (ECC) и резервные модули памяти. Однако теперь, с появлением NVMe Memory Tiering, необходимо учитывать как DRAM, так и NVMe. Мы не будем подробно останавливаться на методах избыточности для DRAM, а сосредоточимся на NVMe в контексте памяти.

В VVF/VCF 9.0 функция NVMe Memory Tiering поддерживает аппаратную конфигурацию RAID, три-режимный (tri-mode) контроллер и технологию VROC (Virtual RAID on CPU) для обеспечения отказоустойчивости холодных или неактивных страниц памяти. Что касается RAID, мы не ограничиваемся какой-то одной конфигурацией: например, RAID-1 — это хорошее и поддерживаемое решение для обеспечения отказоустойчивости NVMe, но также поддерживаются RAID-5, RAID-10 и другие схемы. Однако такие конфигурации потребуют больше NVMe-устройств и, соответственно, увеличат стоимость.

Говоря о стоимости, стоит учитывать и наличие RAID-контроллеров, если вы планируете использовать RAID для отказоустойчивости. Обеспечение резервирования для холодных страниц — это архитектурное решение, которое должно приниматься с учётом баланса между затратами и операционными издержками. Что для вас важнее — надёжность, стоимость или простота эксплуатации? Также необходимо учитывать совместимость RAID-контроллера с vSAN: vSAN ESA не поддерживает RAID-контроллеры, в то время как vSAN OSA поддерживает, но они должны использоваться раздельно.

Преимущества RAID:

• Обеспечивает избыточность для NVMe как устройства памяти
• Повышает надёжность
• Возможное сокращение времени простоя

Недостатки RAID:

• Необходимость RAID-контроллера
• Дополнительные расходы
• Операционные издержки (настройка, обновление прошивок и драйверов)
• Усложнение инфраструктуры
• Появление новой точки отказа
• Возможные проблемы совместимости с vSAN, если все накопители подключены к одной общей плате (backplane)

Как видно, у аппаратной избыточности есть как плюсы, так и минусы. Следите за обновлениями — в будущем могут появиться новые поддерживаемые методы отказоустойчивости.

Теперь предположим, что вы решили не использовать RAID-контроллер. Что произойдёт, если у вас есть один выделенный накопитель NVMe для Memory Tiering, и он выйдет из строя?
Ранее мы обсуждали, что на NVMe переносятся только «холодные» страницы памяти виртуальных машин по мере необходимости. Это означает, что страницы памяти самого хоста не находятся на NVMe, а также что на накопителе может быть как много, так и мало холодных страниц — всё зависит от нагрузки на DRAM. VMware не выгружает страницы (даже холодные), если в этом нет нужды — зачем расходовать вычислительные ресурсы?

Таким образом, если часть холодных страниц была выгружена на NVMe и накопитель вышел из строя, виртуальные машины, чьи страницы находились там, могут попасть в ситуацию высокой доступности (HA). Мы говорим "могут", потому что это произойдёт только если и когда ВМ запросит эти холодные страницы обратно из NVMe, которые теперь недоступны. Если же ВМ никогда не обратится к этим страницам, она продолжит работать без сбоев.

Иными словами, сценарий отказа зависит от активности в момент сбоя NVMe:

• Если на NVMe нет холодных страниц — ничего не произойдёт.
• Если есть немного холодных страниц — возможно, несколько ВМ войдут в HA-событие и перейдут на другой хост;
• Если все холодные страницы хранились на NVMe — возможно, большинство ВМ окажутся в HA-режиме по мере запроса страниц.

Это не обязательно приведёт к полному отказу всех систем. Некоторые ВМ могут выйти из строя сразу, другие — позже, а третьи — вообще не пострадают. Всё зависит от их активности. Главное — хост ESX продолжит работу, а поведение виртуальных машин будет различаться в зависимости от текущих нагрузок.

Масштабируемость

Масштабируемость памяти — это, пожалуй, один из тех неожиданных факторов, который может обойтись очень дорого. Как известно, память составляет значительную часть (до 80%) общей стоимости нового сервера. В зависимости от подхода к закупке серверов, вы могли выбрать меньшие по объёму модули DIMM, установив их во все слоты — в этом случае у вас нет возможности увеличить объём памяти без полной замены всех модулей, а иногда даже самого сервера.

В также могли выбрать высокоплотные модули DIMM, оставив несколько слотов свободными для будущего роста — это позволяет масштабировать память, но тоже дорого, так как позже придётся докупать совместимые модули (если они ещё доступны). В обоих случаях масштабирование получается дорогим и медленным, особенно учитывая длительные процедуры утверждения бюджета и заказов в компаниях.

Именно здесь NVMe Memory Tiering показывает себя с лучшей стороны — снижая затраты и позволяя быстро увеличить объём памяти. В данном случае масштабирование памяти сводится к покупке хотя бы одного устройства NVMe и включению функции Memory Tiering — и вот у вас уже на 100% больше памяти для ваших хостов. Отличная выгода.
Можно даже «позаимствовать» накопитель из вашего хранилища vSAN, если есть возможность выделить его под Memory Tiering… но об этом чуть позже (делайте это с осторожностью).

В этой части важно понимать ограничения и возможности, чтобы обеспечить надёжность инвестиций в будущем. Мы уже говорили о требованиях к устройствам NVMe по показателям производительности и износостойкости, но что насчёт объёма NVMe-устройств? Об этом мы напишем в следующей части.

Вильям Лам описал способ развертывания виртуального модуля OVF/OVA напрямую с сервера с Basic Authentication.

Он делал эксперименты с использованием OVFTool и доработал свой скрипт deploy_data_services_manager.sh, чтобы он ссылался на URL, где был размещён Data Services Manager (DSM) в формате OVA. В этом случае базовую аутентификацию (имя пользователя и пароль) можно включить прямым текстом в URL. Хотя это не самый безопасный способ, он позволяет удобно использовать этот метод развертывания.

Можно просто вставить в скрипт следующую строчку:

DSM_OVA='http://vcf:vcf123!@192.168.30.29/PROD/COMP/DSM/dsm-va-9.0.1.0.24930659.ova'

vcf - это имя пользователя, а vcf123! - пароль.

Также эту строчку можно указать прямо в интерфейсе VMware vSphere Client в качестве URL:

И это будет работать с любым шаблоном. Нужно просто потом дальше принять сертификат от хранилища и продолжить развертывание шаблона из OVF или OVA:

Thomas Kopton написал интересный пост о получении паролей из VCF Fleet Manager на примере для прокси VMware VCF Operations Cloud.

Одно из преимуществ всеобъемлющего решения частного облака, такого как VMware Cloud Foundation (VCF), заключается в уровне автоматизации, который оно предоставляет. VCF стремится упростить ваши операции - от автоматической установки или обновления прокси-серверов VCF Operations Cloud до управления критически важными паролями, такими как пароль пользователя root в VCF Fleet Manager. Но что делать, если вам всё же нужен этот пароль root? Как его получить?

В этом посте рассказывается, как получить доступ к паролям, хранящимся в защищённом хранилище VCF Fleet Manager, на примере пользователя root для прокси-сервера VCF Operations Cloud.

Пароли VCF Fleet Manager

В VCF Fleet Manager раздел Fleet Management Passwords представляет собой решение VCF для автоматизированного и безопасного управления учётными данными. Он централизует, генерирует и управляет критически важными паролями (например, для прокси-серверов VCF Operations Cloud) в защищённом хранилище, снижая количество ручных операций и повышая безопасность в частном облаке.

Хотя Fleet Manager управляет паролями для критически важных компонентов в фоновом режиме, обычно вы не сможете напрямую «извлечь» существующие пароли в открытом виде через его интерфейс. Вместо этого функция Fleet Management Passwords предназначена для проактивного управления этими учётными данными. Это означает, что вы можете обновлять или восстанавливать пароли при необходимости. Если вам нужно восстановить доступ к системе, пароль которой управляется VCF, для этого используется определённый процесс на основе REST API — а не простое извлечение данных из хранилища.

Fleet Management API

За пределами ручных действий в пользовательском интерфейсе API управления флотом VCF предоставляет возможности для максимальной автоматизации. Он открывает функции Fleet Manager через набор программных эндпоинтов, позволяя создавать скрипты для сложных рабочих процессов и интегрировать управление VCF в существующие фреймворки автоматизации.

На следующем скриншоте показано, как получить доступ к интерфейсу Swagger UI для VCF Fleet Management.

В API Explorer мы можем выбрать между публичным и приватным API, как показано на следующем скриншоте:

Получение пароля

Процесс извлечения пароля, хранящегося в защищённом хранилище VCF (в данном примере пароля пользователя root для прокси VCF Operations Cloud) включает три этапа:

1. Авторизация
2. Получение vmid сохранённых учётных данных
3. Извлечение расшифрованного пароля

Авторизация

Авторизация в Swagger UI выполняется быстро. При нажатии соответствующей кнопки открывается диалоговое окно, ожидающее ввода строки Basic Auth, закодированной в Base64. Необходимо закодировать комбинацию User:Password и ввести её в виде строки "Basic xxxxxxx", как показано в примере ниже.

Важно: здесь мы работаем с private-internal-api.

admin@local:VMware123!
Basic YWRtaW5AbG9jYWw6Vk13YXJlMTIzIQ==

На следующем скриншоте показан процесс авторизации в интерфейсе Swagger UI:

Получение списка паролей

Далее нам нужно получить список доступных учётных данных и найти в нём наш Cloud Proxy, чтобы получить vmid. Этот идентификатор необходим для завершающего шага.

Для тестов в рамках этой статьи используется инфраструктура VCF 9.0.1. REST-запрос, который мы будем использовать, находится в разделе v3 контроллера Locker Password Controller. На следующем изображении показан вызов типа GET.

Разумеется, для этого мы можем использовать Postman или просто curl, как показано здесь:

curl -X GET "https://flt-fm01.rainpole.io/lcm/locker/api/v3/passwords?limit=10" -H "accept: application/json" -H "Authorization: Basic YWxxxIQ=="

Теперь нам нужно просмотреть тело ответа JSON, чтобы найти наш Cloud Proxy. Параметр vmid будет одним из ключей в соответствующей записи.

{
      "vmid": "b4b63007-6e32-4462-9b0f-b9330e307eaf",
      "alias": "VCF-sfo-opsc01.sfo.rainpole.io-rootUserPassword",
      "userName": "root",
      "passwordDescription": null,
      "type": "node",
      "status": "active",
      "createdOn": 1753204380982,
      "lastUpdatedOn": 1753204380982,
      "lastValidatedOn": null,
      "reference": {
        "envId": "b5dcc1a4-8d66-4e83-be24-ef4180b7dd27",
        "envName": "b5dcc1a4-8d66-4e83-be24-ef4180b7dd27",
        "productId": "vrops",
        "hostName": "sfo-opsc01.sfo.rainpole.io",
        "ip": "10.11.10.38",
        "nodeType": "cloudproxy",
        "referenceId": "be49027a-16c8-469a-9285-3ad93f2d62ce"
      }

Расшифровка пароля

Заключительный шаг — выполнить запрос к эндпоинту /lcm/locker/api/v2/passwords/{vmid}/decrypted. Это POST-запрос, в котором параметр vmid передаётся в URL, а в теле JSON указывается root-пароль Fleet Manager. На следующем скриншоте показан этот запрос в интерфейсе Swagger.

И вот команда curl:

curl -X POST "https://flt-fm01.rainpole.io/lcm/locker/api/v2/passwords/b4b63007-6e32-4462-9b0f-b9330e307eaf/decrypted" -H "accept: application/json" -H "Authorization: Basic YWRtaW5AbG9jYWw6Vk13QHJlMSFWTXdAcmUxIQ==" -H "Content-Type: application/json" -d "{ \"rootPassword\": \"mysecretpw\"}"

В итоге мы получим наш root-пароль для Cloud Proxy в теле ответа JSON:

{
"passwordVmid": "b4b63007-6e32-4462-9b0f-b9330e307eaf",
"password": "i#M7rq0qqw234W@hz76456&g5VEKf3p"
}

Введение

В современных ИТ-системах шифрование данных стало обязательным элементом защиты информации. Цель шифрования — гарантировать, что данные могут прочитать только системы, обладающие нужными криптографическими ключами. Любой, не имеющий ключей доступа, увидит лишь бессмысленный набор символов, поскольку информация надёжно зашифрована устойчивым алгоритмом AES-256. VMware vSAN поддерживает два уровня шифрования для повышения безопасности кластерного хранения данных: шифрование данных на носителях (Data-at-Rest Encryption) и шифрование данных при передаче (Data-in-Transit Encryption). Эти механизмы позволяют защитить данные как в состоянии покоя (на дисках), так и в движении (между узлами кластера). В результате vSAN помогает организациям соответствовать требованиям регуляторов и предотвращать несанкционированный доступ к данным, например, при краже носителей или перехвате сетевого трафика.

Сегодня мы расскажем о шифровании данных в платформе VMware vSAN, если вы хотите получить больше подробностей, то обратитесь к документу "vSAN Encryption Services: Understanding Encryption Offerings with vSAN using VMware Cloud Foundation 9.0".

Архитектура и компоненты vSAN Encryption Services

Компоненты решения

Архитектура шифрования vSAN включает несколько ключевых элементов: внешний или встроенный сервер управления ключами (KMS), сервер VMware vCenter, гипервизоры ESXi в составе vSAN-кластера и собственно криптографические модули в ядре гипервизора. Внешний KMS-сервер (совместимый с протоколом KMIP), либо встроенный поставщик ключей vSphere NKP, обеспечивает генерацию и хранение мастер-ключей шифрования. vCenter Server отвечает за интеграцию с KMS: именно vCenter устанавливает доверенные отношения (обмен сертификатами) с сервером ключей и координирует выдачу ключей хостам ESXi. Каждый узел ESXi, входящий в шифрованный кластер vSAN, содержит встроенный криптомодуль VMkernel (сертифицированный по требованиям FIPS), который выполняет операции шифрования и дешифрования данных на стороне гипервизора.

Распределение ключей

При включении шифрования vSAN на кластере vCenter запрашивает у KMS два ключа для данного кластера: ключ шифрования ключей (Key Encryption Key, KEK) и ключ хоста (Host Key). KEK играет роль мастер-ключа: с его помощью будут шифроваться все остальные ключи (например, ключи данных). Host Key предназначен для защиты дампов памяти (core dumps) и других служебных данных хоста. После получения этих ключей vCenter передаёт информацию о KMS и идентификаторы ключей (ID) всем хостам кластера. Каждый узел ESXi устанавливает прямое соединение с KMS (по протоколу KMIP) и получает актуальные копии KEK и Host Key, помещая их в защищённый кэш памяти.

Важно: сами ключи не сохраняются на диске хоста, они хранятся только в оперативной памяти или, при наличии, в аппаратном модуле TPM на узле. Это означает, что при перезагрузке хоста ключи стираются из памяти и в общем случае должны быть вновь запрошены у KMS, прежде чем хост сможет монтировать зашифрованное хранилище.

Ключи данных (DEK)

Помимо вышеупомянутых кластерных ключей, каждый диск или объект данных получает свой собственный ключ шифрования данных (Data Encryption Key, DEK). В оригинальной архитектуре хранения vSAN (OSA) гипервизор генерирует уникальный DEK (алгоритм XTS-AES-256) для каждого физического диска в дисковой группе. Эти ключи оборачиваются (wrap) с помощью кластерного KEK и сохраняются в метаданных, что позволяет безопасно хранить ключи на дисках: получить «сырой» DEK можно только расшифровав его при помощи KEK. В более новой архитектуре vSAN ESA подход несколько отличается: используется единый ключ шифрования кластера, но при этом для различных объектов данных применяются уникальные производные ключи. Благодаря этому данные каждой виртуальной машины шифруются своим ключом, даже если в основе лежит общий кластерный ключ. В обоих случаях vSAN обеспечивает надёжную защиту: компрометация одного ключа не даст злоумышленнику доступа ко всему массиву данных.

Роль гипервизора и производительность

Шифрование в vSAN реализовано на уровне ядра ESXi, то есть прозрачно для виртуальных машин. Гипервизор использует сертифицированный криптографический модуль VMkernel, прошедший все необходимые проверки по стандарту FIPS 140-2 (а в новых версиях — и FIPS 140-3). Все операции шифрования выполняются с использованием аппаратного ускорения AES-NI, что минимизирует влияние на производительность системы. Опыт показывает, что нагрузка на CPU и задержки ввода-вывода при включении шифрования vSAN обычно незначительны и хорошо масштабируются с ростом числа ядер и современных процессоров. В свежей архитектуре ESA эффективность ещё выше: благодаря более оптимальному расположению слоя шифрования в стеке vSAN, для той же нагрузки требуется меньше CPU-циклов и операций, чем в классической архитектуре OSA.

Управление доступом

Стоит упомянуть, что управление шифрованием в vSAN встроено в систему ролей и привилегий vCenter. Только пользователи с особыми правами (Cryptographic administrator) могут настраивать KMS и включать/отключать шифрование на кластере. Это добавляет дополнительный уровень безопасности: случайный администратор без соответствующих привилегий даже не увидит опцию включения шифрования в интерфейсе. Разграничение доступа гарантирует, что ключи шифрования и связанные операции контролируются ограниченным кругом доверенных администраторов.

Поддерживаемые типы шифрования

Шифрование данных на носителях (vSAN Data-at-Rest Encryption)

Этот тип шифрования обеспечивает защиту всех данных, хранящихся в vSAN-датасторе. Включение функции означает, что вся информация, записываемая на диски кластера, автоматически шифруется на последнем этапе ввода-вывода перед сохранением на устройство. При чтении данные расшифровываются гипервизором прозрачно для виртуальных машин – приложения и ОС внутри ВМ не осведомлены о том, что данные шифруются. Главное назначение Data-at-Rest Encryption – обезопасить данные на случай, если накопитель будет изъят из системы (например, при краже или некорректной утилизации дисков).

Без соответствующих ключей злоумышленник не сможет прочитать информацию с отключенного от кластера диска. Шифрование «на покое» не требует специальных самошифрующихся дисков – vSAN осуществляет его программно, используя собственные криптомодули, и совместимо как с гибридными, так и полностью флэш-конфигурациями хранилища.

Принцип работы: в оригинальной реализации OSA шифрование данных происходит после всех операций дедупликации и сжатия, то есть уже на «выходе» перед записью на носитель. Такой подход позволяет сохранить эффективность экономии места: данные сначала сжимаются и устраняются дубликаты, и лишь затем шифруются, благодаря чему коэффициенты дедупликации/сжатия не страдают. В архитектуре ESA шифрование интегрировано выше по стеку – на уровне кэша – но всё равно после выполнения компрессии данных.

То есть в ESA шифрование также не препятствует сжатию. Однако особенностью ESA является то, что все данные, покидающие узел, уже зашифрованы высокоуровневым ключом кластера (что частично перекрывает и трафик между узлами – см. ниже). Тем не менее для обеспечения максимальной криптостойкости vSAN ESA по-прежнему поддерживает отдельный механизм Data-in-Transit Encryption для уникального шифрования каждого сетевого пакета.

Включение и поддержка: шифрование данных на носителях включается на уровне всего кластера vSAN – достаточно установить флажок «Data-at-Rest Encryption» в настройках служб vSAN для выбранного кластера. Данная возможность доступна только при наличии лицензии vSAN Enterprise или выше.

В традиционной архитектуре OSA шифрование можно включать как при создании нового кластера, так и на уже работающем кластере. В последнем случае vSAN выполнит поочерёдное перевоспроизведение данных с каждого диска (evacuation) и форматирование дисковых групп в зашифрованном виде, что потребует определённых затрат ресурсов и времени. В архитектуре ESA, напротив, решение о шифровании принимается только на этапе создания кластера и не может быть изменено позднее без полной перестройки хранилища. Это связано с тем, что в ESA шифрование глубоко интегрировано в работу кластера, обеспечивая максимальную производительность, но и требуя фиксации режима на старте. В обоих случаях, после включения, сервис шифрования прозрачно работает со всеми остальными функциями vSAN (в том числе со снапшотами, клонированием, vMotion и т.д.) и практически не влияет на операционную деятельность кластера.

Шифрование данных при передаче (vSAN Data-in-Transit Encryption)

Второй компонент системы безопасности vSAN – это шифрование сетевого трафика между узлами хранения. Функция Data-in-Transit Encryption гарантирует, что все данные, пересылаемые по сети между хостами vSAN, будут зашифрованы средствами гипервизора.

Это особенно важно, если сеть хранения не полностью изолирована или если требуется соответствовать строгим стандартам по защите данных в транзите. Механизм шифрования трафика не требует KMS: при включении этой опции хосты vSAN самостоятельно генерируют и обмениваются симметричными ключами для установления защищённых каналов. Процесс полностью автоматизирован и не требует участия администратора – достаточно активировать настройку в параметрах кластера.

Data-in-Transit Encryption впервые появилась в vSAN 7 Update 1 и доступна для кластеров как с OSA, так и с ESA. В случае OSA администратор может независимо включить шифрование трафика (оно не зависит от шифрования на дисках, но для полноты защиты желательно задействовать оба механизма). В случае ESA отдельного переключателя может не потребоваться: при создании кластера с шифрованием данные «на лету» фактически уже будут выходить из узлов зашифрованными единым высокоуровневым ключом. Однако, чтобы каждый сетевой пакет имел уникальный криптографический отпечаток, ESA по-прежнему предусматривает опцию Data-in-Transit (она остаётся активной в интерфейсе и при включении обеспечит дополнительную уникализацию шифрования каждого пакета). Следует учесть, что на момент выпуска vSAN 9.0 в составе VCF 9.0 шифрование трафика поддерживается только для обычных (HCI) кластеров vSAN и недоступно для т. н. disaggregated (выделенных storage-only) кластеров.

С технической точки зрения, Data-in-Transit Encryption использует те же проверенные криптомодули, сертифицированные по FIPS 140-2/3, что и шифрование данных на дисках. При активации этой функции vSAN автоматически выполняет взаимную аутентификацию хостов и устанавливает между ними защищённые сессии с помощью динамически создаваемых ключей. Когда новый узел присоединяется к шифрованному кластеру, для него генерируются необходимые ключи и он аутентифицируется существующими участниками; при исключении узла его ключи отзываются, и трафик больше не шифруется для него. Всё это происходит «под капотом», не требуя ручной настройки. В результате даже при потенциальном перехвате пакетов vSAN-трафика на уровне сети, извлечь из них полезные данные не представляется возможным.

Интеграция с KMS

Требование наличия KMS

Для использования шифрования данных на vSAN необходим сервер управления ключами (Key Management Server, KMS), совместимый со стандартом KMIP 1.1+. Исключение составляет вариант применения встроенного поставщика ключей vSphere (Native Key Provider, NKP), который появился начиная с vSphere 7.0 U2. Внешний KMS может быть программным или аппаратным (множество сторонних решений сертифицировано для работы с vSAN), но в любом случае требуется лицензия не ниже vSAN Enterprise.

Перед включением шифрования администратор должен зарегистрировать KMS в настройках vCenter: добавить информацию о сервере и установить доверие между vCenter и KMS. Обычно настройка доверия реализуется через обмен сертификатами: vCenter либо получает от KMS корневой сертификат (Root CA) для проверки подлинности, либо отправляет на KMS сгенерированный им запрос на сертификат (CSR) для подписи. В результате KMS и vCenter обмениваются удостоверяющими сертификатами и устанавливают защищённый канал. После этого vCenter может выступать клиентом KMS и запрашивать ключи.

В конфигурации с Native Key Provider процесс ещё проще: NKP разворачивается непосредственно в vCenter, генерируя мастер-ключ локально, поэтому внешний сервер не нужен. Однако даже в этом случае рекомендуется экспортировать (зарезервировать) копию ключа NKP во внешнее безопасное место, чтобы избежать потери ключей в случае сбоя vCenter.

Запрос и кэширование ключей

Как только доверие (trust) между vCenter и KMS установлено, можно активировать шифрование vSAN на уровне кластера. При этом vCenter от имени кластера делает запрос в KMS на выдачу необходимых ключей (KEK и Host Key) и распределяет их идентификаторы хостам, как описано выше. Каждый ESXi узел соединяется с KMS напрямую для получения своих ключей. На период нормальной работы vSAN-хосты обмениваются ключами с KMS напрямую, без участия vCenter.

Это означает, что после первоначальной настройки для ежедневной работы кластера шифрования доступность vCenter не критична – даже если vCenter временно выключен, хосты будут продолжать шифровать/расшифровывать данные, используя ранее полученные ключи. Однако vCenter нужен для проведения операций управления ключами (например, генерации новых ключей, смены KMS и пр.). Полученные ключи хранятся на хостах в памяти, а при наличии TPM-модуля – ещё и в его защищённом хранилище, что позволяет пережить перезагрузку хоста без немедленного запроса к KMS.

VMware настоятельно рекомендует оснащать все узлы vSAN доверенными платформенными модулями TPM 2.0, чтобы обеспечить устойчивость к отказу KMS: если KMS временно недоступен, хосты с TPM смогут перезапускаться и монтировать зашифрованное хранилище, используя кешированные в TPM ключи.

Лучшие практики KMS

В контексте vSAN есть важное правило: не размещать сам KMS на том же зашифрованном vSAN-хранилище, которое он обслуживает. Иначе возникает круговая зависимость: при отключении кластера или перезагрузке узлов KMS сам окажется недоступен (ведь он работал как ВМ на этом хранилище), и хосты не смогут получить ключи для расшифровки датасторов.

Лучше всего развернуть кластер KMS вне шифруемого кластера (например, на отдельной инфраструктуре или как облачный сервис) либо воспользоваться внешним NKP от другого vCenter. Также желательно настроить кластер из нескольких узлов KMS (для отказоустойчивости) либо, в случае NKP, надёжно сохранить резервную копию ключа (через функцию экспорта в UI vCenter).

При интеграции с KMS крайне важна корректная сетевая настройка: все хосты vSAN-кластера должны иметь прямой доступ к серверу KMS (обычно по протоколу TLS на порт 5696). В связке с KMS задействуйте DNS-имя для обращения (вместо IP) – это упростит перенастройку в случае смены адресов KMS и снизит риск проблем с подключением.

vSphere Native Key Provider

Этот встроенный механизм управления ключами в vCenter заслуживает отдельного упоминания. NKP позволяет обойтись без развертывания отдельного KMS-сервера, что особенно привлекательно для небольших компаний или филиалов. VMware поддерживает использование NKP для шифрования vSAN начиная с версии 7.0 U2. По сути, NKP хранит мастер-ключ в базе данных vCenter (в зашифрованном виде) и обеспечивает необходимые функции выдачи ключей гипервизорам. При включении шифрования vSAN с NKP процесс выдачи ключей аналогичен: vCenter генерирует KEK и распределяет его на хосты. Разница в том, что здесь нет внешнего сервера – все операции выполняются средствами самого vCenter.

Несмотря на удобство, у NKP есть ограничения (например, отсутствие поддержки внешних интерфейсов KMIP для сторонних приложений), поэтому для крупных сред на долгосрочной основе часто выбирают полноценный внешний KMS. Тем не менее, NKP – это простой способ быстро задействовать шифрование без дополнительных затрат, и он идеально подходит для многих случаев использования.

Процесс шифрования и дешифрования

Запись данных (шифрование)

После того как кластер vSAN сконфигурирован для шифрования и получены необходимые ключи, каждая операция записи данных проходит через этап шифрования в гипервизоре. Рассмотрим упрощённо этот процесс на примере OSA (Original Storage Architecture):

• Получение блока данных. Виртуальная машина записывает данные на диск vSAN, которые через виртуальный контроллер поступают на слой vSAN внутри ESXi. Там данные сначала обрабатываются сервисами оптимизации – например, вычисляются хеши для дедупликации и выполняется сжатие (если эти функции включены на кластере).
• Шифрование блока. Когда очередь дошла до фактической записи блока на устройство, гипервизор обращается к ключу данных (DEK), связанному с целевым диском, и шифрует блок по алгоритму AES-256 (режим XTS) с помощью этого DEK. Как упоминалось, в OSA у каждого диска свой DEK, поэтому даже два диска одного узла шифруют данные разными ключами. Шифрование происходит на уровне VMkernel, используя AES-NI, и добавляет минимальную задержку.
• Запись на устройство. Зашифрованный блок записывается в кеш или напрямую на SSD в составе дисковой группы. На носитель попадают только зашифрованные данные; никакой незашифрованной копии информации на диске не сохраняется. Метаданные vSAN также могут быть зашифрованы или содержать ссылки на ключ (например, KEK_ID), но без владения самим ключом извлечь полезную информацию из зашифрованного блока невозможно.

В архитектуре ESA процесс схож, с тем отличием, что шифрование происходит сразу после сжатия, ещё на высокоуровневом слое ввода-вывода. Это означает, что данные выходят из узла уже шифрованными кластерным ключом. При наличии Data-in-Transit Encryption vSAN накладывает дополнительное пакетное шифрование: каждый сетевой пакет между хостами шифруется с использованием симметрических ключей сеанса, которые регулярно обновляются. Таким образом, данные остаются зашифрованы как при хранении, так и при передаче по сети, что создаёт многослойную защиту (end-to-end encryption).

Чтение данных (дешифрование)

Обратный процесс столь же прозрачен. Когда виртуальная машина запрашивает данные из vSAN, гипервизор на каждом затронутом хосте находит нужные зашифрованные блоки на дисках и считывает их. Прежде чем передать данные наверх VM, гипервизор с помощью соответствующего DEK выполняет расшифровку каждого блока в памяти. Расшифрованная информация проходит через механизмы пост-обработки (восстановление сжатых данных, сборка из дедуплицированных сегментов) и отправляется виртуальной машине. Для ВМ этот процесс невидим – она получает привычный для себя блок данных, не зная, что на физическом носителе он хранится в зашифрованном виде. Если задействовано шифрование трафика, то данные могут передаваться между узлами в зашифрованном виде и расшифровываются только на том хосте, который читает их для виртуальной машины-потребителя.

Устойчивость к сбоям

При нормальной работе все операции шифрования/дешифрования происходят мгновенно для пользователя. Но стоит рассмотреть ситуацию с потенциальным сбоем KMS или перезагрузкой узла. Как отмечалось ранее, хосты кэшируют полученные ключи (KEK, Host Key и необходимые DEK) в памяти или TPM, поэтому кратковременное отключение KMS не влияет на работающий кластер.

Виртуальные машины продолжат и читать, и записывать данные, пользуясь уже загруженными ключами. Проблемы могут возникнуть, если перезагрузить хост при недоступном KMS: после перезапуска узел не сможет получить свои ключи для монтирования дисковых групп, и его локальные компоненты хранилища останутся офлайн до восстановления связи с KMS. Именно поэтому, как уже упоминалось, рекомендуется иметь резервный KMS (или NKP) и TPM-модули на узлах, чтобы повысить отказоустойчивость системы шифрования.

Управление ключами и ротация

Замена ключей (Rekey)

Безопасность криптосистемы во многом зависит от регулярной смены ключей. VMware vSAN предоставляет администраторам возможность проводить плановую ротацию ключей шифрования без простоя и с минимальным влиянием на работу кластера. Поддерживаются два режима: «мелкая» ротация (Shallow Rekey) и «глубокая» ротация (Deep Rekey). При shallow rekey генерируется новый мастер-ключ KEK, после чего все ключи данных (DEK) перешифровываются этим новым KEK (старый KEK уничтожается). Важно, что сами DEK при этом не меняются, поэтому операция выполняется относительно быстро: vSAN просто обновляет ключи в памяти хостов и в метаданных, не перестраивая все данные на дисках. Shallow rekey обычно используют для регулярной смены ключей в целях комплаенса (например, раз в квартал или при смене ответственного администратора).

Deep rekey, напротив, предполагает полную замену всех ключей: генерируются новые DEK для каждого объекта/диска, и все данные кластера постепенно перераспределяются и шифруются уже под новыми ключами. Такая операция более ресурсоёмка, фактически аналогична повторному шифрованию всего объёма данных, и может занять продолжительное время на крупных массивах. Глубокую ротацию имеет смысл выполнять редко – например, при подозрении на компрометацию старых ключей или после аварийного восстановления системы, когда есть риск утечки ключевой информации. Оба типа рекея можно инициировать через интерфейс vCenter (в настройках кластера vSAN есть опция «Generate new encryption keys») или с помощью PowerCLI-скриптов. При этом для shallow rekey виртуальные машины могут продолжать работать без простоев, а deep rekey обычно тоже выполняется онлайн, хотя и создаёт повышенную нагрузку на подсистему хранения.

Смена KMS и экспорт ключей

Если возникает необходимость поменять используемый KMS (например, миграция на другого вендора или переход от внешнего KMS к встроенному NKP), vSAN упрощает эту процедуру. Администратор добавляет новый KMS в vCenter и обозначает его активным для данного кластера. vSAN автоматически выполнит shallow rekey: запросит новый KEK у уже доверенного нового KMS и переведёт кластер на использование этого ключа, перешифровав им все старые DEK. Благодаря этому переключение ключевого сервиса происходит прозрачно, без остановки работы хранилища. Тем не менее, после замены KMS настоятельно рекомендуется удостовериться, что старый KMS более недоступен хостам (во избежание путаницы) и сделать резервную копию конфигурации нового KMS/NKP.

При использовании vSphere Native Key Provider важно регулярно экспортировать зашифрованную копию ключа NKP (через интерфейс vCenter) и хранить её в безопасном месте. Это позволит восстановить доступ к зашифрованному vSAN, если vCenter выйдет из строя и потребуется его переустановка. В случае же аппаратного KMS, как правило, достаточно держать под рукой актуальные резервные копии самого сервера KMS (или использовать кластер KMS из нескольких узлов для отказоустойчивости).

Безопасное удаление данных

Одним из побочных преимуществ внедрения шифрования является упрощение процедуры безопасной утилизации носителей. vSAN предлагает опцию Secure Disk Wipe для случаев, когда необходимо вывести диск из эксплуатации или изъять узел из кластера. При включенной функции шифрования проще всего выполнить «очистку» диска путем сброса ключей: как только DEK данного носителя уничтожен (либо кластерный KEK перегенерирован), все данные на диске навсегда остаются в зашифрованном виде, то есть фактически считаются стёртыми (так называемая криптографическая санация).

Кроме того, начиная с vSAN 8.0, доступна встроенная функция стирания данных в соответствии со стандартами NIST (например, перезапись нулями или генерация случайных шаблонов). Администратор может запустить безопасное стирание при выведении диска из кластера – vSAN приведёт накопитель в состояние, удовлетворяющее требованиям безопасной утилизации, удалив все остаточные данные. Комбинация шифрования и корректного удаления обеспечивает максимальную степень защиты: даже физически завладев снятым накопителем, злоумышленник не сможет извлечь конфиденциальные данные.

Поддержка FIPS и совместимость

Соответствие стандартам (FIPS)

VMware vSAN Encryption Services были разработаны с учётом строгих требований отраслевых стандартов безопасности. Криптографический модуль VMkernel, на котором основано шифрование vSAN, прошёл валидацию FIPS 140-2 (Cryptographic Module Validation Program) ещё в 2017 году. Это означает, что реализация шифрования в гипервизоре проверена независимыми экспертами и отвечает критериям, предъявляемым правительственными организациями США и Канады.

Более того, в 2024 году VMware успешно завершила сертификацию модуля по новому стандарту FIPS 140-3, обеспечив преемственность соответствия более современным требованиям. Для заказчиков из сфер, где необходима сертификация (государственный сектор, финансы, медицина и т.д.), это даёт уверенность, что vSAN может использоваться для хранения чувствительных данных. Отдельно отметим, что vSAN включена в руководства по безопасности DISA STIG для Министерства обороны США, а также поддерживает механизмы двухфакторной аутентификации администраторов (RSA SecurID, CAC) при работе с vCenter — всё это подчёркивает серьёзное внимание VMware к безопасности решения.

Совместимость с функционалом vSAN

Шифрование в vSAN спроектировано так, чтобы быть максимально прозрачным для остальных возможностей хранения. Дедупликация и сжатие полностью совместимы с Data-at-Rest Encryption: благодаря порядку выполнения (сначала дедупликация/сжатие, потом шифрование) эффективность экономии места практически не снижается. Исключение составляет экспериментальная функция глобальной дедупликации в новой архитектуре ESA — на момент запуска vSAN 9.0 одновременное включение глобальной дедупликации и шифрования не поддерживается (ожидается снятие этого ограничения в будущих обновлениях).

Снапшоты и клоны виртуальных машин на зашифрованном vSAN работают штатно: все мгновенные копии хранятся в том же шифрованном виде, и при чтении/записи гипервизор так же прозрачно шифрует их содержимое. vMotion и другие механизмы миграции ВМ также поддерживаются – сама ВМ при миграции может передаваться с шифрованием (функция Encrypted vMotion, независимая от vSAN) или без него, но это не влияет на состояние ее дисков, которые на принимающей стороне всё равно будут записаны на vSAN уже в зашифрованном виде.

Резервное копирование и репликация

vSAN Encryption не накладывает ограничений на работу средств резервного копирования, использующих стандартные API vSphere (такие как VMware VADP) или репликации на уровне ВМ. Данные читаются гипервизором в расшифрованном виде выше уровня хранения, поэтому бэкап-приложения получают их так же, как и с обычного хранилища. При восстановлении или репликации на целевой кластер vSAN, естественно, данные будут записаны с повторным шифрованием под ключи того кластера. Таким образом, процессы защиты и восстановления данных (VDP, SRM, vSphere Replication и пр.) полностью совместимы с зашифрованными датасторами vSAN.

Ограничения и особенности

Поскольку vSAN реализует программное шифрование, аппаратные самошифрующиеся диски (SED) не требуются и официально не поддерживаются в роли средства шифрования на уровне vSAN. Если в серверы установлены SED-накопители, они могут использоваться, но без включения режимов аппаратного шифрования – vSAN в любом случае выполнит шифрование средствами гипервизора. Ещё один момент: при включении vSAN Encryption отключается возможность рентген-просмотра (в веб-клиенте vSAN) содержимого дисков, так как данные на них хранятся в зашифрованном виде. Однако на функциональность управления размещением объектов (Storage Policy) это не влияет. Наконец, стоит учитывать, что шифрование данных несколько повышает требования к процессорным ресурсам на хостах. Практика показывает, что современные CPU справляются с этим отлично, но при проектировании больших нагрузок (вроде VDI или баз данных на all-flash) закладывать небольшой запас по CPU будет не лишним.

Заключение

VMware vSAN Encryption Services предоставляют мощные средства защиты данных для гиперконвергентной инфраструктуры. Реализовав сквозное шифрование (от диска до сети) на уровне хранения, vSAN позволяет организациям выполнить требования по безопасности без сложных доработок приложений. Среди ключевых преимуществ решения можно отметить:

• Всесторонняя защита данных. Даже если злоумышленник получит физический доступ к носителям или перехватит трафик, конфиденциальная информация останется недоступной благодаря сильному шифрованию (AES-256) и раздельным ключам для разных объектов. Это особенно важно для соблюдения стандартов GDPR, PCI-DSS, HIPAA и других.
• Прозрачность и совместимость. Шифрование vSAN работает под управлением гипервизора и не требует изменений в виртуальных машинах. Все основные функции vSphere (кластеризация, миграция, бэкап) полностью поддерживаются. Решение не привязано к специфическому оборудованию, а опирается на открытые стандарты (KMIP, TLS), что облегчает интеграцию.
• Удобство централизованного управления. Администратор может включить шифрование для всего кластера несколькими кликами – без необходимости настраивать каждую ВМ по отдельности (в отличие от VMcrypt). vCenter предоставляет единый интерфейс для управления ключами, а встроенный NKP ещё больше упрощает старт. При этом разграничение прав доступа гарантирует, что только уполномоченные лица смогут внести изменения в политику шифрования.
• Минимальное влияние на производительность. Благодаря оптимизациям (использование AES-NI, эффективные алгоритмы) накладные расходы на шифрование невелики. Особенно в архитектуре ESA шифрование реализовано с учётом высокопроизводительных сценариев и практически не сказывается на IOPS и задержках. Отсутствуют и накладные расходы по ёмкости: включение шифрования не уменьшает полезный объём хранилища и не создаёт дублирования данных.
• Гибкость в выборе подхода. vSAN поддерживает как внешние KMS от разных поставщиков (для предприятий с уже выстроенными процессами управления ключами), так и встроенный vSphere Native Key Provider (для простоты и экономии). Администраторы могут ротировать ключи по своему графику, комбинировать или отключать сервисы при необходимости (например, включить только шифрование трафика для удалённого филиала с общим хранилищем).

При внедрении шифрования в vSAN следует учесть несколько моментов: обеспечить высокую доступность сервера KMS (или надёжно сохранить ключ NKP), активировать TPM на хостах для хранения ключей, а также не сочетать шифрование vSAN с шифрованием на уровне ВМ (VM Encryption) без крайней необходимости. Двойное шифрование не повышает безопасность, зато усложняет управление и снижает эффективность дедупликации и сжатия.

В целом же шифрование vSAN значительно повышает уровень безопасности инфраструктуры с минимальными усилиями. Оно даёт организациям уверенность, что данные всегда под надёжной защитой – будь то на дисках или в пути между узлами, сегодня и в будущем, благодаря следованию современным стандартам криптографии FIPS.

Одной из новых возможностей Fleet Management, представленных в VMware Cloud Foundation (VCF) 9.0, является полностью обновлённый опыт единого входа (SSO), обеспечивающий доступ администраторов ко всем основным интерфейсам управления, таким как: VCF Operations, vSphere Client, NSX Manager и другие. Новый компонент VCF Identity Broker (VIDB) поддерживает множество современных провайдеров идентификации, а также традиционные службы каталогов. В этой статье вы узнаете, как включить и настроить SSO в среде VCF 9.

Режимы развертывания – встроенный или внешний (appliance)

Первым шагом при включении VCF SSO является выбор режима развертывания брокера идентификации. Существует два варианта: встроенный или appliance.

• Встроенный вариант интегрирован с vCenter Server в домене управления и идеально подходит для небольших сред VCF, которым не требуется масштабирование до целого пула экземпляров VCF.
• Для большей масштабируемости можно выбрать вариант appliance, который работает на небольшом кластере из трёх узлов VIDB для обеспечения отказоустойчивости. Внешний вариант может предоставлять службы идентификации для всего пула экземпляров VCF и рекомендуется для инфраструктур до пяти экземпляров VCF.

Поддержка провайдеров идентификации

После выбора режима развертывания необходимо выбрать провайдера идентификации. В VCF 9 добавлена поддержка Ping Identity и универсальных провайдеров SAML 2.0 в дополнение к Okta, Entra ID, Active Directory, OpenLDAP и другим. В зависимости от выбранного провайдера будут доступны различные варианты определения групп, которым предоставляется доступ для входа в компоненты VCF. Для уточнения конкретных требований следует обратиться к документации продукта.

Ещё одним улучшением стали методы предоставления пользователей и групп: теперь, помимо SCIM с современными провайдерами идентификации, можно использовать JIT или AD/LDAP.

Конфигурация компонентов

После настройки провайдера идентификации остаётся всего один шаг, чтобы включить VCF SSO для каждого компонента в развертывании. Настройка основных инфраструктурных компонентов — vCenter Server и NSX Manager — сводится к простому выбору опции, при этом несколько сервисов можно активировать одновременно, и процесс занимает всего несколько минут.

Для компонентов управления процесс почти такой же простой, но каждый из них расположен в отдельном узле в дереве навигации, поэтому достаточно перейти туда и следовать инструкциям в интерфейсе, чтобы завершить настройку SSO.

Назначение ролей

После завершения настройки VCF SSO остаётся административная задача — назначить необходимые роли для каждого компонента. Эта одноразовая операция должна выполняться с использованием локальных учётных записей администратора (например, “admin” или “administrator@vsphere.local” в случае с vCenter Server). Необходимо предоставить доступ пользователям и группам, созданным через настроенного провайдера идентификации, и назначить им соответствующие права для управления компонентами.

Процесс может отличаться в зависимости от компонента. Например, вы можете назначить группе роль Enterprise Admin, чтобы она могла управлять NSX.

Чтобы увидеть весь процесс включения доступа в полном развертывании VCF 9, посмотрите демо ниже.

Пользовательский интерфейс SDDC Manager

Особое примечание о SDDC Manager в VCF 9: этот пользовательский интерфейс считается устаревшим, но остаётся доступным, а само backend-приложение по-прежнему необходимо для выполнения некоторых задач управления инфраструктурой. В связи с этим войти в интерфейс SDDC Manager с использованием учётных данных VCF SSO невозможно — продолжайте использовать локальную учётную запись администратора, обычно administrator@vsphere.local.

Однако у SDDC Manager всё же есть конфигурация SSO, и её следует настроить для удалённого доступа к API. Это связано с тем, что после входа в vCenter Server некоторые действия, инициированные в vSphere Client, фактически выполняются SDDC Manager в фоновом режиме, и для этого потребуется аутентификация. Поэтому назначьте группе SSO, которую вы используете в vCenter Server, права администратора в SDDC Manager, чтобы обеспечить плавный и бесшовный доступ.

Практическая демонстрация

Если вы хотите увидеть полный процесс настройки VCF SSO, ознакомьтесь с этим короткой практической лабораторной работой (HOL), которая пошагово проводит через весь процесс: https://labs.hol.vmware.com/HOL/catalog/lab/26724.

Итоги

Новый релиз VMware Cloud Foundation привносит значительные изменения в рабочие процессы администраторов, особенно за счёт объединения множества административных и управленческих задач в новый интерфейс VCF Operations. Однако по-прежнему существуют специализированные консоли управления, к которым администраторам необходимо получать доступ. Теперь, благодаря VCF SSO и VIDB, переход к выполнению определённых действий в NSX Manager или vSphere Client стал значительно проще. Настройка VCF SSO лёгкая, а безопасность при этом не страдает благодаря интеграции с проверенными и надёжными провайдерами идентификации.

Supervisor Control Plane — это управляющий уровень встроенного Kubernetes (Supervisor Cluster) в решении VMware vSphere with Tanzu (ранее vSphere with Kubernetes). Он развёрнут как три виртуальные машины (Supervisor Control Plane VMs), которые выполняют контроль над кластером Kubernetes, включая etcd, API-сервер, контроллеры и планировщик. Важнейшие функции этих виртуальных машин:

• Интеграция с инфраструктурой vSphere: Supervisor Control Plane взаимодействует с ресурсами ESX-хостов — CPU, память, сеть, хранилище — и позволяет запускать контейнеры напрямую на гипервизоре (vSphere Pods).
• API-доступ: администраторы управляют кластерами через интерфейс vSphere Client и API vSphere with Tanzu, а разработчики — через kubectl.
• Высокая доступность: обеспечивается трёхкомпонентной архитектурой. Если один узел выходит из строя, другие продолжают работу.

Полезный трюк — как получить SSH-пароль для Supervisor Control Plane VM

Есть простой способ получить доступ по SSH для виртуальных машин, входящих в состав Supervisor Control Plane:

1. Подключитесь по SSH к виртуальному модулю сервера vCenter под пользователем root.
2. Выполните скрипт:

Скрипт выведет IP-адрес (обычно FIP, то есть "floating IP") и автоматически сгенерированный пароль. После этого вы можете подключиться по SSH к Supervisor Control Plane VM как root@<FIP> с полученным паролем.

Важно! Доступ к этим ВМ следует использовать только для диагностики и устранения проблем — любые изменения в них (особенно без одобрения от поддержки VMware) могут привести к нарушению работоспособности Supervisor-кластера, и поддержка может потребовать его полного развертывания заново.

Полезные рекомендации и предосторожения

• Скрипт /usr/lib/vmware-wcp/decryptK8Pwd.py извлекает пароль из базы данных vCenter. Он удобен для быстрого доступа, особенно при отладке сетевых или других проблем с Supervisor VM.
• Убедитесь, что FIP действительно доступен и корректно маршрутизируется. При сбое etcd FIP не назначится, и придётся использовать реальный IP-адрес интерфейса (например, eth0). Также при смене FIP удалите старую запись из known_hosts — сертификаты могут изменяться при «плавании» IP.
• Используйте доступ только для анализа, чтения логов и выполнения команд kubectl logs/get/describe.

VMware Live Recovery (VLR) продолжает обеспечивать надёжную кибер- и информационную устойчивость для VMware Cloud Foundation 9 (VCF), предлагая унифицированную защиту и безопасное восстановление после инцидентов ИБ. Помимо возможностей кибервосстановления, VMware Live Recovery остаётся основой корпоративного оркестратора аварийного восстановления в различных топологиях на базе VCF и включает расширенную репликацию vSphere между сайтами с RPO до одной минуты для поддержки критически важных приложений. VMware Live Recovery также интегрирован с функциями защиты данных хранилища VMware vSAN ESA. Всё более глубокая интеграция между VLR и основными компонентами VCF, такими как vSAN, выделяет решение на фоне конкурентов и усиливает ценность единой платформы для клиентов.

С последним релизом VMware Cloud Foundation 9 в решение VMware Live Recovery были добавлены следующие ключевые улучшения:

• VLR Appliance – упрощённое развертывание и управление сервисами
• Интеграция с VMware Cloud Foundation – улучшенный доступ к данным защиты
• Улучшенная интеграция Protection Group и Recovery Plan с защитой данных vSAN
• Кибервосстановление – поддержка сценариев на стороне заказчика, повышение суверенитета данных

VLR Appliance – упрощённое развертывание и управление сервисами

Теперь клиенты могут управлять всеми операциями восстановления с помощью одного виртуального модуля VLR. Это обновление позволяет использовать единую, комбинированную, простую в установке и управлении виртуальную машину, упрощающую управление жизненным циклом решения для нескольких сервисов защиты.

В новом объединённом устройстве VLR консолидации подверглись следующие сервисы защиты и восстановления:

• Расширенная репликация между сайтами на базе vSphere
• Снапшоты на базе vSAN на заданных (исходном/целевом) сайтах vSAN ESA
• Автоматизация и оркестрация Site Recovery

Этот релиз VLR Appliance доступен всем клиентам с подпиской VLR, а также владельцам бессрочных лицензий SRM с действующей поддержкой SnS или временной подпиской. Новый модуль можно установить на сервер vCenter для объединения ранее установленных компонентов, как показано ниже:

Информация по развертыванию

Виртуальный модуль VLR Appliance поставляется в двух вариантах:

• Основной объединённый модуль.
• Дополнительный модуль службы восстановления для расширенных сценариев оркестрации аварийного восстановления, например, при использовании общих сайтов восстановления.

Для получения более подробной информации и системных требований см. документацию по VMware Live Recovery.

Важно отметить, что новый модуль VLR будет единственным вариантом, совместимым с VCF, но при этом сохраняет обратную совместимость с более старыми версиями ESX и vCenter (8.0 U3b+, 8.0 U2d+), чтобы обеспечить корректную межсайтовую работу и совместимость при переходе клиентов на новую платформу VCF. Как всегда, рекомендуется использовать инструмент совместимости продуктов VMware перед обновлениями — в данном случае, чтобы сравнить компоненты VMware Live Site Recovery и VMware Cloud Foundation.

Расширенная репликация vSphere теперь включена в унифицированную модель развертывания VLR и обеспечивает более масштабируемую и эффективную репликацию с возможностью RPO до одной минуты.

Важно: расширенная репликация vSphere теперь является конфигурацией по умолчанию и единственно поддерживаемой для репликации между сайтами. Для сайтов, использующих старые версии vSphere Replication, перед установкой нового модуля VLR потребуется обновление до Enhanced vSphere Replication. Подробности об обновлении см. в документации. Если используется репликация на уровне СХД (array-based replication), необходимо установить SRA и array-менеджеры на новое устройство VLR и настроить их отдельно. Для дополнительной информации о выпуске этого VLR Appliance см. документацию по VMware Live Recovery Appliance.

Интеграция с VMware Cloud Foundation – лучший доступ к данным защиты

Платформа VMware Cloud Foundation поддерживает одновременную работу как традиционных виртуальных машин, так и модернизированных рабочих нагрузок. Совместимость VMware Live Recovery была обновлена, особенно в части свойств виртуальных машин для поддержки переключения (failover) и возврата (failback). Подробности о поддержке защищённых, управляемых сервисами ВМ доступны в документации.

Теперь VLR интегрирован в консоль операций VCF, что позволяет клиентам отслеживать все развертывания защиты данных VCF из единого интерфейса. Эта интеграция охватывает кибервосстановление, аварийное восстановление, репликацию vSphere, репликацию vSAN и удалённые снапшоты (remote snapshots).

Панель Data Protection & Recovery в VCF Operations для VMware Live Recovery предоставляет критически важную информацию в одном месте. Пользователи могут быстро оценить:

• Сколько виртуальных машин защищено и подлежит восстановлению.
• Какие ВМ в данный момент не защищены.
• Ёмкость защищённого хранилища и возможности её масштабирования под нужды ИТ-инфраструктуры.

Для более глубокого анализа можно установить VLR и VR Management Packs, чтобы получить доступ к предустановленным дэшбордам. Пример дэшборда верхнего уровня:

Улучшенная интеграция групп защиты (Protection Groups) и планов восстановления (Recovery Plans) с защитой данных vSAN

Устройство VLR Appliance поддерживает службы Data Protection Snapshot Management Services для vSAN ESA и обеспечивает более глубокую интеграцию в оркестрационную платформу VMware Live Recovery. Для хранилищ на базе vSAN ESA благодаря интеграции с VLR теперь доступны три ключевые функции:

• Локальные снимки хранилища (local datastore snapshots)
• Удалённые снимки хранилища (remote datastore snapshots)
• Репликация между хранилищами vSAN ESA

Чтобы упростить защиту виртуальных машин, конфигурации групп защиты (Protection Groups) автоматически обнаруживаются и доступны как через интерфейс vSAN Data Protection UI, так и через VMware Live Site Recovery, что существенно упрощает администрирование защиты и восстановления в масштабах всей инфраструктуры предприятия.

Кибервосстановление – поддержка локальных сценариев и повышение суверенитета данных

С этим релизом VCF и новой версией VLR клиенты могут использовать утверждённую VMware архитектуру (VMware Validated Solution), реализованную как драфт для версии 9.0, для создания локальной зоны кибервосстановления (clean room). Эта архитектура использует:

• Домен рабочих нагрузок VCF как изолированную clean room.
• Кластер хранения vSAN ESA как защищённое кибер-хранилище (cyber data vault).
• vDefend для сетевой изоляции.
• VMware Live Recovery для оркестрации процессов восстановления.

Теперь организации, которым необходимо соблюдать требования к конфиденциальности данных или территориальной принадлежности (data residency), могут обеспечивать суверенитет данных, не передавая их в публичное облако, а размещая инфраструктуру восстановления в локальной среде VCF clean room.

Общая архитектура такого сценария показана на схеме ниже:

Последний релиз VMware Cloud Foundation (VCF) и обновления VMware Live Recovery (VLR) включают важные усовершенствования, направленные на удовлетворение современных требований ИТ-организаций к защите и восстановлению данных. Чтобы узнать больше о глубокой интеграции всех средств защиты, упрощённых методах развертывания и управления, а также расширенных возможностях сценариев восстановления — ознакомьтесь с материалами по следующим ссылкам: VMware Live Recovery и документация по VLR.

Недавно компания VMware обновила свой распределенный сетевой экран vDefend 9 в рамках релиза VMware Cloud Foundation 9.0. Новые усовершенствования включают поддержку lateral security с учетом среды VPC, самостоятельную микро-сегментацию, упрощённую миграцию vDefend в VCF и централизованное глобальное управление IDS/IPS-политиками для ускоренного реагирования на угрозы и их устранения.

Современные предприятия стремительно внедряют стратегию частного облака в своих инфраструктурах. Недавнее исследование, охватившее 1 800 руководителей высокого уровня, показало, что их организации отдают приоритет частным облакам для решения проблем, связанных со стоимостью, необходимостью предсказуемости, требованиями AI-нагрузок, lateral security и соблюдением нормативных требований.

Поскольку цифровые компании всё активнее делают ставку на частные облачные стратегии, ИТ- и службы безопасности сталкиваются с задачей максимально быстрого и эффективного обеспечения защиты рабочих нагрузок. Поскольку большинство атак программ-вымогателей включает боковое распространение угроз с целью поиска ценных активов, стратегии кибербезопасности эволюционируют в сторону защиты как критичных, так и некритичных нагрузок во всех частных облаках.

vDefend — это ведущая программно-определяемая, интегрированная с гипервизором система боковой безопасности (lateral security), созданная специально для комплексной защиты каждой рабочей нагрузки в среде VMware Cloud Foundation (VCF). vDefend внедряет надёжные встроенные средства сетевой безопасности непосредственно в архитектуру VCF. Решение позволяет быстро внедрять, управлять и масштабировать микро-сегментацию и защиту от угроз, ускоряя реализацию стратегий нулевого доверия в организации.

Новые возможности vDefend для VCF 9.0

• Боковая безопасность с поддержкой VPC (VPC-Aware Lateral Security): теперь пользователи могут применять vDefend на уровне виртуального частного облака (VPC), внедряя изолированные и управляемые политики боковой безопасности для каждого арендатора/потребителя. Это обеспечивает точный контроль и делегированное управление, упрощая многопользовательские среды.

• Самостоятельная микросегментация (Self-Service Micro-segmentation): команды инфраструктуры создают централизованные политики межсетевого экранирования для «огороженных» зон приложений. В версии vDefend 9.0 владельцам приложений можно делегировать создание детализированных политик внутри этих зон. Автоматизация возможна через API в рамках DevOps CI/CD-процессов.

• Интеграция импорта в VCF (VCF Import Integration): существующие развертывания vDefend вне VCF могут быть импортированы в среду VCF 9.0 с сохранением политик, что снижает усилия по миграции. Это упрощает и ускоряет переход на полнофункциональную платформу VCF.

• Глобальное управление IDS/IPS-политиками (Global Policy Management): централизованное управление политиками предотвращения и обнаружения вторжений на разных площадках обеспечивает единообразие политики и ускоренное реагирование на угрозы вне зависимости от местоположения рабочих нагрузок.

• Портал сигнатур IDS/IPS (Signature Portal): позволяет в реальном времени изучать изменения сигнатур без входа в консоль vDefend, что оптимизирует рабочие процессы, повышает осведомлённость об угрозах и ускоряет реагирование на инциденты.

• Фильтрация по геолокации (Geo-IP Filtering): межсетевой экран шлюза vDefend теперь может управлять трафиком с учётом географии, разрешая или блокируя подключения к определённым странам прямо на шлюзе уровня T0, обеспечивая точный контроль глобальных потоков.

Интеграция vDefend с VCF 9.0 делает передовые меры безопасности более доступными, учитывающими многопользовательскую среду и централизованно управляемыми, превращая безопасность из препятствия в встроенную возможность.

Боковая безопасность с поддержкой VPC

Многопользовательская архитектура — основа корпоративного ИТ, но достижение полной изоляции как на уровне данных, так и управления всегда было сложной задачей. Внедрение VPC значительно улучшило ситуацию, позволив разделять как каналы передачи данных, так и управляющие плоскости в сетевой и безопасной архитектуре, обеспечивая более детальную изоляцию на уровне приложений, часто под управлением DevOps-команд.

С выпуском VMware Cloud Foundation (VCF) 9.0, vDefend расширяет возможности боковой безопасности, предоставляя полноценную изоляцию сетей на уровне VPC с помощью микро-сегментации, пропуская только доверенный трафик между приложениями. Это улучшение позволяет делегировать управление: администратор каждого VPC может видеть и настраивать только собственную среду. Команды теперь могут работать параллельно, обладая полной самостоятельностью и изоляцией, делая безопасную многопользовательскую работу в частном облаке реальностью.

Self-service микросегментация

Межсетевой экран vDefend предоставляет возможности как администраторам инфраструктуры, так и владельцам VPC. Администраторы инфраструктуры могут создавать защищённые виртуальные частные облака (VPC), сводя к минимуму горизонтальный (east-west) трафик. Одновременно с этим владельцы VPC получают гибкость в настройке детализированных правил для своих приложений, обеспечивая их работоспособность без нарушения централизованных политик безопасности. Такой подход способствует внедрению модели «самообслуживания» в вопросах безопасности для конечных пользователей при сохранении общего уровня защищённости организации.

Бесшовная миграция с импортом в VCF

Существующие развертывания vDefend вне VMware Cloud Foundation (VCF) можно легко импортировать в среду VCF 9.0 с сохранением текущих политик межсетевого экрана vDefend. Это снижает затраты и усилия, связанные с таким переходом. Упрощённый процесс миграции позволяет клиентам эффективно перейти на полнофункциональную платформу VCF, без необходимости начинать всё с нуля.

Упрощённое и централизованное управление IDS/IPS-политиками в многокомпонентных VCF-средах с поддержкой изолированных (air-gapped) сред

Крупные, многокомпонентные (федеративные) среды VCF требуют единых, масштабируемых политик безопасности IDS/IPS и централизованного управления сигнатурами, при этом операции должны оставаться простыми и эффективными. Теперь клиенты могут внедрять глобальные политики IDS/IPS во всех распределённых развертываниях VCF с помощью централизованного управления, обеспечивая единообразие защиты на уровне всей организации.

Кроме того, возможность назначать несколько пакетов сигнатур IDS/IPS позволяет пользователям применять конкретные наборы сигнатур в нужных местах своих развертываний VCF. Для изолированных (air-gapped) сред поддерживается доставка пакетов сигнатур IDS/IPS на локальные управляющие узлы (Local Managers), даже при отсутствии подключения к интернету и наличии ограничений по соблюдению требований безопасности.

В совокупности эти возможности обеспечивают единообразное и централизованное управление политиками предотвращения угроз в многокомпонентных развертываниях VCF. Все события IDS/IPS отображаются в единой консоли управления.

Мониторинг в реальном времени с новым порталом сигнатур IDS/IPS

Поддержание актуальности защитных механизмов — критически важная задача; предприятия полагаются на частые обновления сигнатур, чтобы опережать новые угрозы. Хотя vDefend уже позволяет легко загружать и просматривать актуальные пакеты сигнатур IDS/IPS через свою консоль, аналитикам по безопасности зачастую требуется более глубокое понимание — например, определение новшеств в каждом пакете, отслеживание истории версий, поиск сигнатур по конкретным уязвимостям (CVE) или по определённым шаблонам атак, таким как каналы управления и контроля (Command and Control).

В новом портале сигнатур IDS/IPS VMware представила мощный инструмент, который позволяет операторам исследовать обновления сигнатур в реальном времени — без необходимости входа в консоль vDefend. Благодаря удобному веб-доступу портал позволяет командам изучать сигнатуры, искать покрытия по конкретным угрозам, сравнивать версии и экспортировать списки сигнатур. Эта возможность не только упрощает начальное планирование и развертывание, но и способствует более эффективному взаимодействию команд и ускоренному реагированию, повышая осведомлённость об угрозах и улучшая реагирование на инциденты в масштабе всей организации.

Точный контроль трафика с геозональной фильтрацией по странам

Администраторы инфраструктуры теперь могут разрешать или блокировать входящий и исходящий трафик на уровне межсетевого экрана шлюза vDefend в зависимости от конкретного географического расположения. Эта новая возможность обеспечивает точное, адресное управление трафиком, усиливает уровень безопасности и способствует соблюдению нормативных требований.

Более подробно о VMware vDefend 9 можно узнать на странице продукта. Release Notes доступны тут.

Дункан Эппинг рассказал о том, как можно убедиться, что ваши диски VMware vSAN зашифрованы.

Если у вас включена техника шифрования "vSAN Encryption – Data At Rest", то вы можете проверить, что действительно данные на этих дисках зашифрованы в разделе настроек vSAN в клиенте vSphere Client. Однако вы можете сделать это и на уровне хоста ESXi, выполнив команду:

esxcli vsan storage list

Как вы можете увидеть из вывода команды, для шифрования указан параметр Encryption: true.

Второй момент - вам надо убедиться, что служба управления ключами шифрования Key Management System доступна и работает как положено. Это вы можете увидеть в разделе vSAN Skyline Health клиента vSphere:

Дункан также обращает внимание, что если вы используете Native Key Server и получаете ошибку "not available on host", проверьте, опцию "Use key provider only with TPM". Если она включена, то вы должны иметь модуль TPM для корректной работы механизмов шифрования. Если у вас модуля такого нет - просто снимите эту галочку.

Интеграция VMware vCenter Server с Active Directory (AD) позволяет централизовать управление учетными записями и упростить администрирование доступа. Вместо локальной базы пользователей vCenter можно использовать доменную инфраструктуру AD или другой LDAP-сервис как единый источник аутентификации. Это означает, что администраторы vSphere смогут применять те же учетные записи и группы, что и для остальных ресурсов сети, для доступа к объектам vSphere.

VMware/Broadcom представили новую сертификацию — VMware Certified Professional – Private Cloud Security Administrator (VCP-PCS), которая подтверждает квалификацию специалистов по обеспечению безопасности в среде VMware Cloud Foundation (VCF) с использованием решений VMware vDefend. Это важный шаг в направлении усиления защиты частных облаков, особенно в условиях растущего спроса на модели Zero Trust и комплексные меры кибербезопасности.

Что представляет собой VCP-PCS?

Сертификация VCP-PCS предназначена для специалистов, отвечающих за безопасность VCF, включая:

• Архитекторов и инженеров облачной инфраструктуры
• Администраторов виртуальной инфраструктуры
• Системных администраторов
• Специалистов по поддержке и внедрению решений

VCP-PCS подтверждает способность кандидата:

• Настраивать и управлять распределёнными и шлюзовыми межсетевыми экранами
• Реализовывать защиту от продвинутых угроз
• Внедрять архитектуру Zero Trust с использованием VMware vDefend
• Использовать аналитические инструменты и средства безопасности для мониторинга и реагирования на инциденты

Подготовка и экзамен

Для получения сертификации необходимо:

• Курс: VMware vDefend Security for VCF 5.x Administrator
• Темы: архитектура vDefend, управление политиками безопасности, практическое применение в VCF

• Название: VMware vDefend Security for VCF 5.x Administrator (6V0-21.25)
• Формат: 75 вопросов (множественный выбор и множественные ответы)
• Продолжительность: 90 минут
• Проходной балл: 70%
• Язык: английский
• Стоимость: $250
• Регистрация: через портал сертификации VMware

Почему это важно?

Сертификация VCP-PCS демонстрирует вашу способность:

• Обеспечивать безопасность в современных частных облаках
• Внедрять и поддерживать архитектуру Zero Trust
• Использовать инструменты VMware vDefend для защиты инфраструктуры

Это особенно актуально для организаций, стремящихся усилить защиту своих облачных сред и соответствовать современным требованиям безопасности. Если вы стремитесь углубить свои знания в области безопасности частных облаков и повысить свою профессиональную ценность, сертификация VCP-PCS станет отличным выбором. Она подтверждает вашу экспертизу в одной из самых востребованных областей современной IT-инфраструктуры.

Виртуальные модули VMware NSX Edge Appliances играют ключевую роль в инфраструктуре VMware NSX, обеспечивая маршрутизацию север-юг, функции межсетевого экрана, балансировку нагрузки и VPN-сервисы. Потеря доступа к NSX Edge из-за забытого или истёкшего пароля может нарушить работу системы и ограничить возможности управления. В этой статье мы рассмотрим процедуру сброса пароля для устройства NSX Edge. Описанная ниже процедура подходит для сброса паролей на виртуальных модулях NSX Manager, Edge и Cloud Service Manager.

Чтобы сбросить пароль root, используйте следующую процедуру:

• Войдите в графический интерфейс NSX > System > Nodes > Edge Cluster > выберите узел Edge > кликните правой кнопкой мыши > выберите «Put into Maintenance Mode», чтобы перевести хост Edge в режим обслуживания.
• Войдите в vCenter, найдите виртуальную машину Edge и установите задержку загрузки (boot delay) на 9000.
• Подключитесь к консоли виртуального модуля Edge Appliance.
• Перезагрузите систему.
• Когда появится меню загрузчика GRUB, быстро нажмите левую клавишу SHIFT или ESC. Если вы не успеете, и процесс загрузки продолжится, необходимо будет перезагрузить систему снова.

• Нажмите e, чтобы отредактировать пункт меню. Выберите верхнюю строку с Ubuntu, затем введите имя пользователя root и пароль GRUB для пользователя root (он отличается от пароля пользователя root на самом устройстве). Пароль по умолчанию — NSX@VM!WaR10 (скорее всего, вы его не меняли).

Нажмите e, чтобы отредактировать выбранный пункт. Найдите строку, начинающуюся с linux, и добавьте в конец этой строки следующее:
systemd.wants=PasswordRecovery.service

• Нажмите Ctrl+X, чтобы продолжить загрузку. Когда появятся последние сообщения журнала, введите новый пароль для пользователя root.
  Введите пароль ещё раз. Загрузка продолжится.
• После перезагрузки вы можете убедиться в смене пароля, выполнив вход под пользователем root с новым паролем. С помощью входа под root вы также можете изменить пароли пользователей admin и audit, если потребуется.
• Заключительный шаг — вывести узел Edge из режима обслуживания.

Разбор сложного HTML — это, безусловно, непростая задача, даже с PowerShell. Вильям Лам недавно пытался использовать бесплатную версию ChatGPT и новую модель 4o, чтобы сделать функцию на PowerShell для парсинга HTML, но он постоянно сталкивался с системными ограничениями, а AI часто неправильно понимал, чего от него хотят.

По запросу одного из пользователей он пытался расширить свою статью в блоге за 2017 год об автоматизации глобальных прав vSphere и добавить поддержку их вывода через PowerCLI.

Оказалось, что получить список всех текущих глобальных прав окружения VMware vSphere через приватный API vSphere Global Permissions с помощью vSphere MOB крайне трудно из-за сложного HTML, который рендерит этот интерфейс. На самом деле, Вильяму понадобилось 25 итераций, прежде чем он нашёл рабочее решение с помощью модели ChatGPT 4o. В нескольких попытках прогресс даже откатывался назад — и это было довольно раздражающе.

В итоге, теперь есть файл GlobalPermissions.ps1, который содержит новую функцию Get-GlobalPermission. Эта функция извлекает все глобальные права vSphere, включая имя субъекта (principal), назначенную роль vSphere и то, где именно эта роль определена (глобальное право или право в рамках inventory сервера vCenter).

Ниже приведён пример использования новой функции — перед этим потребуется выполнить Connect-VIServer, чтобы можно было сопоставить ID роли vSphere, полученный из функции, с её реальным именем, которое возвращается встроенным командлетом PowerCLI.

$vc_server = "vc03.williamlam.local"
$vc_username = "*protected email*"
$vc_password = "VMware1!"

$server = Connect-VIServer -Server $vc_server -User $vc_username -Password $vc_password

Get-GlobalPermission -vc_server $vc_server -vc_username $vc_username -vc_password $vc_password

Disconnect-viserver $server -confirm:$false

Ниже приведен результат работы этой функции:

В видеоролике ниже рассматривается то, как включить Virtualization-Based Security (VBS) в гостевых операционных системах Windows, работающих в среде VMware Cloud Foundation и vSphere:

Что такое Virtualization-Based Security (VBS)?

VBS — это технология безопасности от Microsoft, использующая возможности аппаратной виртуализации и изоляции для создания защищённой области памяти. Она используется для защиты критически важных компонентов операционной системы, таких как Credential Guard и Device Guard.

Предварительные требования

Перед тем как включить VBS, необходимо убедиться в выполнении следующих условий:

1. Active Directory Domain Controller
   Необходим для настройки групповой политики. В демонстрации он уже создан, но пока выключен.

2. Загрузка через UEFI (EFI)
   Виртуальная машина должна использовать загрузку через UEFI, а не через BIOS (legacy mode).

3. Secure Boot
   Желательно включить Secure Boot — это обеспечивает дополнительную защиту от вредоносных программ на стадии загрузки.

4. Модуль TPM (Trusted Platform Module)
   Не обязателен, но настоятельно рекомендуется. Большинство руководств по безопасности требуют его наличия.

Настройка VBS в VMware

1. Перейдите к параметрам виртуальной машины в Edit Settings.

2. Убедитесь, что:

   • Используется UEFI и включен Secure Boot.
   • Включена опция "Virtualization-based security" в VM Options.
   • Виртуализация ввода-вывода (IO MMU) и аппаратная виртуализация будут активированы после перезагрузки.

Важно: Если переключаться с legacy BIOS на EFI, ОС может перестать загружаться — будьте осторожны.

Настройка VBS внутри Windows

После включения параметров на уровне гипервизора нужно активировать VBS в самой Windows:

1. Запустите gpedit.msc (Редактор локальной групповой политики).

2. Перейдите по пути:

   Administrative Templates > System > Device Guard 

3. Включите следующие параметры:
   • Turn on Virtualization Based Security – активировать.
   • Secure Boot and DMA Protection – да.
   • Virtualization-based protection of Code Integrity – включить с UEFI Lock.
   • Credential Guard – включить.
   • Secure Launch Configuration – включить.

Примечание: Если вы настраиваете контроллер домена, обратите внимание, что Credential Guard не защищает базу данных AD, но защищает остальную ОС.

4. Перезагрузите виртуальную машину.

Проверка работоспособности VBS

После перезагрузки:

1. Откройте System Information и убедитесь, что:

• Virtualization Based Security включена.
• MA Protection работает.
• redential Guard активен.

2. В Windows Security проверьте:

• Включена ли Memory Integrity.
• Активна ли защита от вмешательства (Tamper Protection).

Заключение

Теперь у вас есть полностью защищённая Windows-гостевая ОС с включённой Virtualization-Based Security, Credential Guard и другими функциями. Это отличный способ повысить уровень безопасности в вашей инфраструктуре VMware.

Для получения дополнительной информации смотрите ссылки под видео.

В начале 2025 года в индустрии информационной безопасности стали появляться заявления о том, что «эра программ-вымогателей подошла к концу». Такие утверждения подкреплялись новостями о задержаниях ключевых членов известных кибергруппировок и о значительном снижении общих объемов выкупов, выплаченных жертвами. Однако реальная картина куда сложнее. Несмотря на частичный успех правоохранительных органов, говорить о полном искоренении вымогателей пока рано.

Реальные успехи: что удалось сделать

Бесспорно, 2024 и начало 2025 года стали весьма продуктивными в борьбе с киберпреступностью:

• Задержания участников группировки Phobos. В феврале 2025 года Европол сообщил об аресте четырёх предполагаемых участников кибергруппировки Phobos. Эта группировка специализировалась на атаках на малые и средние бизнесы, используя шифровальщики с классическими методами социальной инженерии и RDP-брутфорс.

• Уничтожение 8Base. Одновременно с операцией против Phobos, ФБР и международные партнёры провели успешную операцию по деактивации группы 8Base — относительно молодой, но весьма агрессивной группировки, использовавшей методы двойного вымогательства: шифрование данных плюс угроза их публикации.

• Снижение объёмов выкупов. По данным Chainalysis, в 2024 году совокупная сумма выкупов, выплаченных киберпреступникам, снизилась на треть по сравнению с предыдущим годом. Это объясняется как ростом отказов платить со стороны компаний, так и усилившейся эффективностью мер реагирования.

Почему «победа» — преждевременное заявление

Несмотря на вышеуказанные достижения, эксперты в области кибербезопасности предупреждают: вымогатели никуда не исчезли. Вот ключевые факторы, свидетельствующие о продолжающейся угрозе:

Киберпреступники постоянно модернизируют свои подходы. Один из ярких примеров — активное внедрение искусственного интеллекта в арсенал злоумышленников. AI помогает:

• создавать правдоподобные фишинговые письма;
• автоматизировать выбор целей на основе уязвимостей;
• маскировать вредоносный код от систем обнаружения.

Это делает вымогателей менее заметными и более «эффективными» в смысле проникновения в защищённые сети.

Если раньше основными векторами были RDP и фишинг, то сегодня наблюдается рост атак через:

• Уязвимости в популярных продуктах (например, недавно эксплуатировались дыры в MOVEit, Ivanti и Confluence)
• Сторонние подрядчики и цепочки поставок
• Скомпрометированные обновления программного обеспечения

Таким образом, даже хорошо защищённые компании могут стать жертвами через своих партнёров.

3. Географическая миграция

После давления со стороны западных спецслужб часть группировок сменила географию своей активности. Наблюдается усиление атак на организации в Южной Америке, Азии и Африке, где уровень готовности к киберугрозам часто ниже, чем в США и ЕС.

Тенденции и прогнозы

На основе анализа текущей ситуации можно выделить несколько ключевых трендов:

• Рост Ransomware-as-a-Service (RaaS). Преступные группировки предоставляют шифровальщики и инфраструктуру «в аренду» менее опытным хакерам. Это способствует широкому распространению атак, даже со стороны непрофессиональных злоумышленников.

• Двойное и тройное вымогательство. Помимо шифрования и угроз публикации, злоумышленники стали использовать метод давления на клиентов атакуемых компаний — рассылая им угрозы или раскрывая утечку напрямую.

• Обход систем EDR/XDR. Новые версии вредоносных программ разрабатываются с учётом слабых мест современных средств обнаружения угроз, что требует от ИБ-команд постоянной адаптации.

Что делать специалистам по информационной безопасности?

Чтобы не стать жертвой программ-вымогателей, технические специалисты должны применять многоуровневый подход:

• Отключение неиспользуемых RDP-доступов
• Применение многофакторной аутентификации
• Ограничение доступа по принципу наименьших привилегий (PoLP)

• Регулярный скан уязвимостей (в том числе внутренних)
• Быстрое закрытие критических CVE (особенно в веб-интерфейсах и шлюзах)

• Использование сетевых сегментов
• Ограничение доступа между подразделениями
• Изоляция критичных серверов от общего доступа

• Наличие чётких процедур IRP (incident response plan)
• Регулярные учения с симуляцией атак (tabletop exercises)
• Проверка работоспособности бэкапов и времени восстановления
• Использование immutable (неизменяемых) резервных копий

Вывод

Несмотря на оптимистичные заявления, программа-вымогатели остаются значительной угрозой для организаций всех масштабов. Да, международные операции наносят удары по крупным группировкам. Да, суммы выкупов снижаются. Но сама модель кибервымогательства — децентрализованная, легко копируемая и всё ещё прибыльная — продолжает жить и развиваться.

Техническим специалистам и командам информационной безопасности нельзя терять бдительность. Актуальные знания, автоматизация защиты и постоянное совершенствование практик — ключевые условия выживания в условиях современных киберугроз.

Компания Veeam выпустила исправление для критической уязвимости удалённого выполнения кода (RCE) под идентификатором CVE-2025-23120, обнаруженной в программном обеспечении Veeam Backup & Replication. Уязвимость затрагивает развертывания, где сервер резервного копирования работает в составе домена AD.

Согласно техническому отчёту от компании watchTowr Labs, которая обнаружила данную ошибку, CVE-2025-23120 представляет собой уязвимость десериализации в .NET-классах Veeam.Backup.EsxManager.xmlFrameworkDs и Veeam.Backup.Core.BackupSummary.

Уязвимость десериализации возникает, когда приложение неправильно обрабатывает сериализованные данные, позволяя злоумышленникам внедрять вредоносные объекты («гаджеты»), способные запускать опасный код.

В прошлом году компания Veeam исправляла похожую уязвимость удалённого выполнения кода (RCE), обнаруженную исследователем Флорианом Хаузером. Чтобы устранить проблему, Veeam внедрила чёрный список известных классов или объектов, которые могли использоваться для атак.

Однако специалисты компании watchTowr смогли найти другую цепочку гаджетов, не включённую в чёрный список, что позволило им снова добиться удалённого выполнения кода.

«В общем, вы, наверное, уже догадались, к чему всё идёт — похоже, что Veeam, несмотря на то, что остаётся любимой игрушкой группировок, распространяющих программы-вымогатели, не усвоила урок после исследования, опубликованного Frycos. Как вы уже поняли — они вновь исправили проблемы десериализации, просто добавив новые записи в свой чёрный список десериализации.»

Хорошая новость в том, что эта уязвимость затрагивает только те установки Veeam Backup & Replication, которые присоединены к домену. Плохая — любой доменный пользователь способен эксплуатировать данную уязвимость, что делает её особенно опасной в таких конфигурациях.

К сожалению, многие компании всё ещё подключают свои серверы Veeam к доменам Windows, игнорируя давно рекомендованные разработчиком правила безопасности.

Представители группировок, использующих программы-вымогатели, ранее уже сообщали, что серверы Veeam Backup & Replication всегда являются их целью, так как обеспечивают удобный способ похищать данные и препятствовать восстановлению систем, удаляя резервные копии. Эта новая уязвимость ещё больше повышает привлекательность серверов Veeam для злоумышленных группировок, так как она значительно упрощает взлом таких серверов.

Несмотря на отсутствие на текущий момент сообщений о реальных случаях эксплуатации уязвимости, watchTowr уже раскрыла достаточное количество технических деталей, поэтому в ближайшее время вполне вероятно появление общедоступного эксплойта (PoC). Компании, использующие Veeam Backup & Replication, должны максимально оперативно обновиться до версии 12.3.1.

Также, учитывая пристальное внимание группировок-вымогателей к данному приложению, настоятельно рекомендуется пересмотреть лучшие практики безопасности Veeam Backup и отключить серверы от домена.

В современной динамично развивающейся сфере информационных технологий автоматизация уже не роскошь, а необходимость. Команды, отвечающие за безопасность, сталкиваются с растущей сложностью управления политиками сетевой безопасности, что требует эффективных и автоматизированных решений. Межсетевой экран vDefend, интегрированный с VMware NSX, предлагает мощные возможности автоматизации с использованием различных инструментов и языков сценариев. Выпущенное недавно руководство "Beginners Guide to Automation with vDefend Firewall" рассматривает стратегии автоматизации, доступные в vDefend, которые помогают ИТ-специалистам упростить рабочие процессы и повысить эффективность обеспечения безопасности.

Понимание операций CRUD в сетевой автоматизации

Операции CRUD (Create, Read, Update, Delete) являются основой рабочих процессов автоматизации. vDefend позволяет выполнять эти операции через RESTful API-методы:

• GET — получение информации о ресурсе.
• POST — создание нового ресурса.
• PUT/PATCH — обновление существующих ресурсов.
• DELETE — удаление ресурса.

Используя эти методы REST API, ИТ-команды могут автоматизировать политики межсетевого экрана, создавать группы безопасности и настраивать сетевые параметры без ручного вмешательства.

Стратегии автоматизации для межсетевого экрана vDefend

С vDefend можно использовать несколько инструментов автоматизации, каждый из которых предлагает уникальные преимущества:

1. Вызовы REST API через NSX Policy API - API политики NSX Manager позволяют напрямую выполнять действия CRUD с сетевыми ресурсами. Разработчики могут использовать языки программирования, такие как Python, GoLang и JavaScript, для написания сценариев взаимодействия с NSX Manager, обеспечивая бесшовную автоматизацию задач безопасности.

2. Terraform и OpenTofu - эти инструменты «инфраструктура-как-код» (IaC) помогают стандартизировать развертывание сетей и политик безопасности. Используя декларативные манифесты, организации могут определять балансировщики нагрузки, правила межсетевого экрана и политики безопасности, которые могут контролироваться версионно и развертываться через CI/CD-конвейеры.

3. Ansible - этот инструмент часто применяется для развертывания основных компонентов NSX, включая NSX Manager, Edge и транспортные узлы. ИТ-команды могут интегрировать Ansible с Terraform для полной автоматизации конфигурации сети.

4. PowerCLI — это модуль PowerShell для VMware, который позволяет администраторам эффективно автоматизировать конфигурации межсетевых экранов и политик сетевой безопасности.

5. Aria Automation Suite - платформа Aria обеспечивает оркестрацию задач сетевой безопасности корпоративного уровня. Она включает:

• Aria Assembler — разработка и развертывание облачных шаблонов для настройки безопасности.
• Aria Orchestrator — автоматизация сложных рабочих процессов для управления безопасностью NSX.
• Aria Service Broker — портал самообслуживания для автоматизации сетевых и защитных операций.

Ключевые основы работы с API

Для эффективного использования возможностей автоматизации vDefend важно понимать архитектуру его API:

• Иерархическая структура API: API NSX построен по древовидной структуре с ресурсами в отношениях родитель-потомок.
• Пагинация с курсорами: большие наборы данных разбиваются на страницы с использованием курсоров для повышения эффективности запросов.
• Порядковые номера: правила межсетевого экрана выполняются сверху вниз, приоритет отдается правилам с меньшими порядковыми номерами.
• Методы аутентификации: вызовы API требуют аутентификации через базовую авторизацию, сеансовые токены или ключи API.

Пример полномасштабной автоматизации

Реальный сценарий автоматизации с использованием vDefend включает:

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

Например, автоматизированное правило межсетевого экрана для разрешения HTTPS-трафика от группы веб-серверов к группе приложений будет выглядеть следующим образом в формате JSON:

{
  "action": "ALLOW",
  "source_groups": ["/infra/domains/default/groups/WebGroup"],
  "destination_groups": ["/infra/domains/default/groups/AppGroup"],
  "services": ["/infra/services/HTTPS"],
  "scope": ["/infra/domains/default/groups/WebGroup"]
}

VMware Validated Solutions – это проверенный портфель технически валидированных решений, разработанных для того, чтобы помочь клиентам создавать безопасную, высокопроизводительную, устойчивую и эффективную инфраструктуру для их приложений и рабочих нагрузок, развернутых в облаке VMware Cloud Foundation. Эти решения предлагают систематический подход к быстрому и эффективному развертыванию, охватывая планирование и подготовку, принятие проектных решений, реализацию, эксплуатационные рекомендации и совместимость решений. Кроме того, многие из таких решений могут автоматизировать значительную часть процесса развертывания. Примером такого решения служит VMware Private AI Ready Validated Solution.

Lateral Security for VMware Cloud Foundation with VMware vDefend – это хорошо продуманное, модульное решение, которое направляет процесс проектирования, внедрения и эксплуатации VMware vDefend для защиты компонентов управления и рабочих нагрузок VMware Cloud Foundation. О нем мы подробно писали вот тут.

Создание безопасной инфраструктуры является ключевым фактором в обеспечении защиты рабочих нагрузок частного облака клиентов с первого дня. Решение этой задачи может оказаться сложным для администраторов без специализированных знаний. Настройка и управление безопасными средами требуют глубокого понимания инфраструктуры и специфики сетевого взаимодействия приложений.

Использование проверенного решения Lateral Security for VMware Cloud Foundation with VMware vDefend позволяет организациям эффективно решать эти задачи и уверенно защищать свои частные облака и рабочие нагрузки с помощью проверенных конфигураций и индивидуальных рекомендаций.

Что входит в решение?

Решение основывается на лучших принципах проектирования Broadcom для использования продуктов и функций безопасности VMware vDefend в средах VMware Cloud Foundation.

Оно включает в себя проектные решения и автоматизированные шаги по защите компонентов домена управления VMware Cloud Foundation, а также упрощенные рекомендации по проектированию и внедрению макро- и микросегментации для защиты клиентских рабочих нагрузок в доменах рабочих нагрузок. Решение направляет эффективное развертывание NSX Application Platform, предоставляя важные рекомендации по выбору размеров и масштабированию для обеспечения оптимальной производительности.

Кроме того, оно предлагает руководство по использованию Security Intelligence для автоматизации и расширения возможностей защиты vDefend, обеспечивая повторяемые процессы, которые можно адаптировать для любых сред и рабочих нагрузок VMware Cloud Foundation.

Готовы углубиться и раскрыть полный потенциал продукта VMware vDefend? Вы можете получить доступ к готовому решению VMware Validated Solution по этой ссылке.

VMware vDefend – это передовая служба для VMware Cloud Foundation, обеспечивающая новейшие возможности для реализации принципов нулевого доверия (zero-trust) в области латеральной безопасности. Это единственное решение безопасности, которое предоставляет детализированную защиту компонентов управления VMware Cloud Foundation с использованием микросегментации.

Lateral Security for VMware Cloud Foundation – это корпоративное решение, позволяющее клиентам быстро и эффективно разрабатывать, планировать и развертывать защиту VMware vDefend для обеспечения безопасности инфраструктуры и рабочих нагрузок VMware Cloud Foundation.

VMware vCenter Server поставляется с рядом системных и пользовательских ролей, которые можно использовать, а также пользователи могут создавать собственные роли с необходимыми привилегиями. Если вам нужно понять, какие роли активно используются, следующий фрагмент кода PowerCLI, который сделал Дункан Эппинг, поможет получить информацию о назначенных ролях. Кроме того, скрипт также создаст файл, содержащий все привилегии, определенные для активно используемых ролей vCenter.

$roles = Get-VIRole
$permissions = Get-VIPermission

$results = @{}
foreach ($permission in $permissions) {
    $role = $permission.Role
    if($results.ContainsKey($role)) {
        $results[$role]+=1
    } else {
        $results[$role]=1
    }
}

Write-Host "`nTotal Roles: $($roles.count)"
Write-Host "Total Roles Used: $($results.count)"
Write-Host "Role Usage:"

$results.GetEnumerator() | Sort-Object -Property Value -Descending

$outfile = "used-roles.txt"
foreach ($key in $results.keys) {
    $role = Get-VIRole $key
    if(!$role.IsSystem) {
        $key | Out-File -Append -LiteralPath $outfile
        "=========================================================" | Out-File -Append -FilePath $outfile
        $role.ExtensionData.Privilege | Out-File -Append -LiteralPath $outfile
        "" | Out-File -Append -LiteralPath $outfile
    }
}

Вот пример выполнения сценария:

А вот пример вывода из файла used-roles.txt, который генерируется и содержит список привилегий для каждой используемой роли:

Недавно компания Broadcom представила защищенные адаптеры Emulex Secure Fibre Channel HBA, аппаратно шифрующие трафик между серверами и хранилищами с минимальным влиянием на производительность. Это экономичное и простое в управлении решение, которое шифрует все передаваемые данные (технология encryption data in-flight - EDIF), защищая их при перемещении между базами данных, приложениями, серверами и хранилищами...

Летом 2024 года Фрэнк Даннеман написал интересный аналитический документ «VMware Private AI Foundation – Privacy and Security Best Practices», который раскрывает основные концепции безопасности для инфраструктуры частного AI (в собственном датацентре и на базе самостоятельно развернутых моделей, которые работают в среде виртуализации).

Как многие из вас знают, мир искусственного интеллекта стремительно развивается, и с этим появляются новые вызовы, особенно в области конфиденциальности и безопасности. Этот документ не ограничивается теорией. Это практическое руководство, в котором представлены базовые концепции, структуры и модели, лежащие в основе безопасности приватного AI. В нем подробно рассматриваются ключевые аспекты конфиденциальности и безопасности в контексте ИИ, а также предоставляются инструменты, которые помогут вам внедрить эти принципы в своей работе. Вы узнаете о принципе совместной ответственности, моделировании угроз для приложений с генеративным AI, а также о триаде CIA — конфиденциальность, целостность и доступность, которая используется как основная модель информационной безопасности.

Основные моменты документа:

1. Преимущества Private AI в корпоративных датацентрах:

   • Контроль и безопасность: организации получают полный контроль над своими данными и моделями, что позволяет минимизировать риски, связанные с конфиденциальностью, и избегать зависимости от сторонних поставщиков.
   • Экономическая эффективность: Private AI позволяет управлять расходами на AI, избегая неожиданных затрат от сторонних сервисов и оптимизируя ИТ-бюджет.
   • Гибкость и инновации: быстрое тестирование и настройка AI-моделей на внутренних данных без задержек, связанных с внешними сервисами, что способствует повышению производительности и точности моделей.
2. Принцип совместной ответственности в Private AI:
   
   • Документ подчеркивает важность распределения обязанностей между поставщиком инфраструктуры и организацией для обеспечения безопасности и соответствия требованиям.
3. Моделирование угроз для Gen-AI приложений:
   • Рассматриваются потенциальные угрозы для генеративных AI-приложений и предлагаются стратегии их смягчения, включая анализ угроз и разработку соответствующих мер безопасности.
4. Модель CIA (Конфиденциальность, Целостность, Доступность):
   • Конфиденциальность: обсуждаются методы защиты данных, включая контроль доступа, шифрование и обеспечение конфиденциальности пользователей.
   • Целостность: рассматриваются механизмы обеспечения точности и согласованности данных и моделей, а также защита от несанкционированных изменений.
   • Доступность: подчеркивается необходимость обеспечения постоянного и надежного доступа к данным и моделям для авторизованных пользователей.
5. Защита Gen-AI приложений:
   • Предлагаются лучшие практики для обеспечения безопасности генеративных AI-приложений, включая разработку безопасной архитектуры, управление доступом и постоянный мониторинг.
6. Архитектура Retrieval-Augmented Generation (RAG):
   • Документ подробно описывает процесс индексирования, подготовки данных и обеспечения безопасности в архитектурах RAG, а также методы эффективного поиска и извлечения релевантной информации для улучшения работы AI-моделей.

В заключение, документ предоставляет всестороннее руководство по созданию и поддержке приватных AI-решений, акцентируя внимание на критически важных аспектах конфиденциальности и безопасности, что позволяет организациям уверенно внедрять AI-технологии в своих инфраструктурах.

И это еще не все. В ближайшем будущем VMware продолжает развивать эти концепции в другом аналитическом документе, посвященном настройкам VMware Cloud Foundation (VCF). Этот документ станет вашим основным ресурсом для получения подробных рекомендаций по конфигурации и оптимизации VCF, чтобы создать надежную и безопасную среду для Private AI.

В обеих версиях Microsoft Windows 10 и 11 безопасность на основе виртуализации (Virtualization Based Security, VBS) включена по умолчанию, и эта функция использует платформу Hyper-V, которая реализует технологию вложенной виртуализации (Nested Virtualization). Недавно Вильям Лам написал о том, что в связи с этим платформа VMware Workstation может выдавать ошибку.

Если вы попытаетесь запустить вложенную виртуальную машину с гипервизором ESXi в рамках Workstation под Windows, вы, скорее всего, увидите одно из следующих сообщений об ошибке в зависимости от производителя процессора:

• Virtualized Intel VT-x/EPT is not supported on this platform 
• Virtualized AMD-V/RVI is not supported on this platform 

Выглядит это так:

В то же время VMware Workstation была улучшена для совместной работы с Hyper-V благодаря новому режиму Host VBS Mode, представленному в VMware Workstation версии 17.x:

Workstation Pro uses a set of newly introduced Windows 10 features (Windows Hypervisor Platform) that permits the use of VT/AMD-V features, which enables Workstation Pro and Hyper-V to coexist. And because VBS is built on Hyper-V, Windows hosts with VBS enabled can now power on VM in Workstation Pro successfully

В документации VMware Workstation упоминаются несколько ограничений данной возможности. Тем не менее, если вам необходимо запустить вложенный ESXi под VMware Workstation, вам просто нужно отключить VBS в Windows, при условии, что у вас есть права администратора на вашем компьютере.

Шаг 1. Перейдите в раздел «Безопасность устройства» и в разделе «Основная изоляция» (Core isolation) отключите параметр «Целостность памяти» (Memory integrity), как показано на скриншоте ниже.

Шаг 2. Перезагрузите компьютер, чтобы изменения вступили в силу.

Шаг 3. Чтобы убедиться, что VBS действительно отключен, откройте Microsoft System Information (Системную информацию) и найдите запись «Безопасность на основе виртуализации» (Virtualization-based security). Убедитесь, что там указано «Не включено» (Not enabled). На устройствах, управляемых корпоративными системами, эта настройка может автоматически включаться снова. Таким образом, это поможет подтвердить, включена ли настройка или отключена.

Шаг 4. Как видно на скриншоте ниже, Вильяму удалось успешно запустить вложенный ESXi 6.0 Update 3 на последней версии VMware Workstation 17.6.2 под управлением Windows 11 22H2.

На конференции VMware Explore 2024 была представлена презентация "Hardening and Securing VMware Cloud Foundation" (#VCFT1616LV), в которой инженер по безопасности и комплаенсу Broadcom Боб Планкерс поделился ключевыми стратегиями и подходами к обеспечению безопасности VMware Cloud Foundation (VCF).

Презентация фокусируется на многоуровневом подходе к защите инфраструктуры VCF, охватывая такие ключевые аспекты, как:

• Основы информационной безопасности: реализация принципов конфиденциальности, целостности и доступности данных.
• Технические меры защиты: использование шифрования данных, проверка подлинности компонентов, функции Secure Boot и другие механизмы.
• Проектирование систем: ранняя интеграция функций безопасности, адаптация к уникальным требованиям каждой организации и применение компенсирующих средств контроля.
• Соответствие стандартам: использование DISA STIG, CIS Benchmarks и других гайдлайнов для минимизации уязвимостей и упрощения аудита.

Одним из главных акцентов стала концепция "Zero Trust", которая предполагает минимизацию доверия ко всем компонентам и пользователям системы. Также рассмотрены стратегии аутентификации и авторизации, включая федерацию идентификаций и внедрение многофакторной аутентификации (MFA).

Презентация содержит и практические рекомендации, такие как:

• Отключение неиспользуемых функций управления серверами (например, IPMI, SSH).
• Настройка безопасной загрузки (UEFI Secure Boot) и использования Trusted Platform Module (TPM).
• Оптимизация управления доступом через модели RBAC и изоляцию критических систем.

Термит — это оператор программ-вымогателей (шифрование, кража данных, вымогательство), который недавно заявил о нескольких жертвах во Франции, Канаде, Германии, Омане и США. Их атаки нацелены на такие секторы, как государственные учреждения, образование, нефтегазовая промышленность, водоочистка и автомобилестроение. Логотип группы представляет собой стилизованного синего термита с элементами, напоминающими электронные схемы.

Группа, по всей видимости, использует модифицированную версию печально известного вымогательского ПО Babuk. После запуска вируса на устройстве файлы шифруются, и к их названиям добавляется расширение .termite. Также оставляется записка с требованиями выкупа (How To Restore Your Files.txt) с кратким описанием действий. Преступники предоставляют ссылку на свой Onion-сайт, а также уникальный токен и адрес электронной почты для связи. На сайте жертвам предлагается форма для прямой коммуникации, в которой нужно указать название компании, описание ситуации, полное имя, адрес электронной почты и "токен поддержки".

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

Компания Symantec, входящая в группу Broadcom, защищает от этой угрозы следующими способами:

• На основе решения VMware Carbon Black

Связанные вредоносные индикаторы блокируются и обнаруживаются существующими политиками в продуктах VMware Carbon Black. Рекомендуется как минимум заблокировать запуск всех типов вредоносных программ (известных, подозрительных и PUP) и включить задержку выполнения для проверки в облаке, чтобы максимально использовать преимущества службы репутации VMware Carbon Black Cloud.

• На основе файлов

Здесь должен отработать модуль Ransom.Babuk,

• На основе машинного обучения

Тут работает модуль Heur.AdvML.B.

Более подробно об этом можно узнать тут.

VMware vDefend с инновационным помощником на основе GenAI ускоряет защиту от угроз программ-вымогателей (ransomware), предоставляя объяснения, ориентированные на контекст цепочки атаки, коррелированные сведения о кампаниях угроз и направленные рекомендации по их устранению.

Сегодня вокруг генеративного AI (GenAI) много энтузиазма, не только среди предприятий, но и среди злоумышленников, стремящихся расширить свои возможности для вымогательства. По мере развития этих технологий они будут глубже интегрироваться в рабочие процессы, помогая предприятиям превентивно ликвидировать новые угрозы.

VMware vDefend находится на переднем крае инноваций в области AI и ML, включая использование AI для рекомендаций по правилам микросегментации и применение ML к трафику и контекстам рабочих нагрузок для получения детализированных сведений. Сейчас VMware сделала логичный, но важный следующий шаг, используя GenAI и крупные языковые модели (LLM), чтобы ещё больше помочь клиентам защитить свои ценные активы.

За последний год команда VMware усердно работала над инициативой под названием Project Cypress. Результатом стал Intelligent Assist for vDefend, основанный на GenAI и LLM. Эта новая возможность упрощает работу команд виртуализации, сетевой безопасности и SOC, помогая им понять детальную, контекстуальную информацию об активных угрозах и их влиянии. Всего за несколько кликов команды могут инициировать устранение, упрощая процессы, которые раньше требовали сложных рабочих процессов с использованием нескольких продуктов. Улучшая реакцию на угрозы, Intelligent Assist for vDefend позволяет командам по безопасности и инфраструктуре работать более слаженно для защиты от атак вымогателей и вносить больший вклад в безопасность.

Детализация сложных угроз и предупреждений безопасности

До появления GenAI корреляция действий по кампаниям или исследование связей между угрозами и предупреждениями были трудоемким процессом. Попытки интегрировать несколько точечных решений зачастую добавляли сложности, увеличивая риск ошибок и появления «слепых зон».

Зачастую важный контекст события — например, что происходило до и после него — упускался из виду. Хотя существует множество систем для оценки серьезности или влияния уязвимостей, они не могут передавать эту информацию на естественном языке, что затрудняет оценку масштаба кампаний угроз. Обмен индикаторами компрометации (Indicators of Compromise, IoC) для обнаружения угроз также был исторически сложным по аналогичным причинам.

Генеративный AI ускоряет и упрощает операции по поддержанию безопасности. Инструменты на базе GenAI значительно увеличивают способность команд безопасности обрабатывать большие объемы предупреждений, которые иначе были бы перегружающими из-за их количества. GenAI может сэкономить часы — или даже дни — ручных усилий, интеллектуально приоритизируя и коррелируя эти предупреждения для надлежащего устранения. Это повышение скорости напрямую улучшает защиту от угроз.

Решение Intelligent Assist для vDefend

В основе Intelligent Assist лежит интерактивный чат-бот на базе большой языковой модели (LLM), интегрированный непосредственно в интерфейс vDefend. Этот чат-бот объясняет события обнаружения простым языком, помогая командам безопасности понять полный масштаб угроз, одновременно улучшая сотрудничество по всей организации. Это не только снижает частоту ложных срабатываний, но и ускоряет процесс устранения угроз. С помощью простого интерфейса на естественном языке аналитики могут задавать конкретные вопросы для получения более глубокого контекстного понимания, когда это необходимо.

Ключевые функции Intelligent Assist для vDefend включают объяснение угроз на простом языке, а также возможности автоматизированного реагирования и устранения. Платформа разработана на принципах простоты и интуитивности.

Давайте рассмотрим эти функции подробнее.

Объяснимость

Рассмотрим типичную ситуацию с программой-вымогателем, включающую эксфильтрацию данных с использованием таких инструментов, как dnscat, который создает зашифрованное управление и контроль (Command-and-Control, C&C) по протоколу DNS.

Благодаря обширному набору сигнатур IDS, vDefend обнаруживает эту вредоносную активность и генерирует событие высокого уровня важности. Intelligent Assist предоставляет дополнительный контекст для оператора SOC, указывая, что другие события предполагают, что исходным вектором атаки стал Darkside ransomware. Более того, он подтверждает, что влияние значительное, но в настоящее время ограничено определенной рабочей нагрузкой. Обладая этой информацией, команда SOC может уверенно сделать вывод, что событие является истинно положительным, и инициировать немедленные действия.

Способность Intelligent Assist объяснять угрозы и события на простом языке позволяет командам по безопасности, сетям и виртуализации мгновенно оценивать масштаб и влияние отдельных угроз. Автоматически выявляя связанные события и отображая индикаторы компрометации (IoC), он устраняет пробелы в видимости в рамках стека безопасности и значительно ускоряет получение информации по сравнению с тем, что было доступно ранее.

Автоматический ответ и устранение

После подтверждения события как истинно положительного, важно быстрое и эффективное устранение. Здесь снова приходит на помощь Intelligent Assist, принимая автоматические и немедленные меры по устранению, в то время как вы продолжаете собирать информацию и проводить экспертный анализ.

В зависимости от вашей терпимости к риску и потенциального влияния на легитимный трафик и производительность бизнеса, вы можете выбрать между целенаправленным или комплексным ответом:

• Целенаправленный ответ: этот подход направлен на узкие, конкретные меры по устранению для минимизации нарушения бизнес-процессов. Однако такая «точечная» стратегия несет риск неполного сдерживания атаки.
• Комплексный ответ: более широкий по охвату, этот подход «молотка» с большей вероятностью предотвращает боковое распространение угрозы, но также несет больший риск нарушения нормальной работы бизнеса.

Когда Intelligent Assist выявляет кампанию атаки, он рекомендует соответствующую стратегию реагирования. В приведенном ниже примере, касающемся продолжающейся атаки программ-вымогателей, Intelligent Assist рекомендовал политику комплексного устранения. Несмотря на автоматизацию создания политик, Intelligent Assist не предназначен для работы в полностью автономном режиме. Окончательное решение остается за командой безопасности — Intelligent Assist генерирует политику, но она не применяется, пока ее не проверит и не активирует эксперт по безопасности. В данном случае рекомендованная политика блокирует всю исходящую DNS-коммуникацию от затронутой рабочей нагрузки, чтобы предотвратить дальнейшее распространение угрозы.

Бесшовный и интуитивно понятный интерфейс

При разработке Intelligent Assist в VMware сосредоточились на том, чтобы сделать интерфейс максимально удобным и интуитивно понятным для конечного пользователя. Такие функции, как экспорт чата, позволяют пользователям легко сохранять и делиться важными инсайтами из диалогов с другими командами, а встроенные механизмы обратной связи обеспечивают улучшение ответов системы со временем. Intelligent Assist также предлагает рекомендации по запросам, помогая даже самым неопытным пользователям раскрыть весь его потенциал. Административная панель создана для упрощения управления пользователями, а поддержка многопользовательских сессий и инструменты управления рабочими процессами способствуют эффективному сотрудничеству между различными командами. Развертывание Intelligent Assist не требует усилий — решение использует безопасное расширение для браузера Chrome, обеспечивая прямой канал связи. Просто скачайте расширение, и все готово к работе.

Чтобы узнать больше о Intelligent Assist, посмотрите техническую сессию VMware Explore Las Vegas 2024, доступную здесь.

Вильям Лам написал наиполезнейшую статью о сбросе/восстановлении пароля консоли сервера VMware ESXi 8 и 7 в составе платформы виртуализации VMware vSphere.

Общее руководство и самый быстрый способ восстановления пароля root для хоста ESXi, если вы забыли или потеряли его, заключается в сбросе с помощью профилей хостов vSphere, если он управлялся сервером vCenter, или просто переустановке ESXi, что позволит сохранить существующие тома VMFS вместе с виртуальными машинами, которые могут на них находиться.

Ранее также было возможно сбросить пароль root ESXi, загрузив систему в Linux и вручную обновив файл /etc/shadow, что похоже на то, как можно сбросить пароль в системе на базе Linux. В сети можно найти множество статей в блогах, описывающих этот процесс. Однако с появлением ESXi Configuration Store данный метод больше не работает для современных версий ESXi, начиная с ESXi 7.0 Update 1 и выше.

Тем не менее, эта тема все еще часто поднимается, особенно в контексте администраторов, которые начинают работать в новой компании, где пароль root ESXi не был должным образом задокументирован, или когда администратору поручено поддерживать набор отдельных ESXi хостов без владельцев. Независимо от сценария, хотя переустановка является самым быстрым способом восстановления, конечно, было бы неплохо сохранить исходную конфигурацию, особенно если нет документации.

Хотя в сети было опубликовано множество фрагментов информации (здесь, здесь и здесь), включая информацию от самого Вильяма, было бы полезно выяснить по шагам актуальный процесс восстановления ESXi 7.x или 8.x хоста без необходимости его переустановки.

Предварительные требования:

• Доступ к физическому носителю, на который установлен ESXi (USB или HDD/SSD)
• Виртуальная машина Linux (Ubuntu или Photon OS)
• Виртуальная машина с вложенным ESXi

Для демонстрации описанного ниже процесса восстановления Вильям установил ESXi 8.0 Update 3c на USB-устройство с базовой конфигурацией (имя хоста, сеть, SSH MOTD), чтобы убедиться в возможности восстановления системы. Затем он изменил пароль root на что-то полностью случайное и удалил этот пароль, чтобы нельзя было войти в систему. Хост ESXi, на котором он "забыл" пароль, будет называться физическим хостом ESXi, а вложенная виртуальная машина с ESXi, которая будет помогать в восстановлении, будет называться вложенным хостом (Nested ESXi).

Шаг 1 — Разверните вложенную виртуальную машину с ESXi (скачать с сайта VMware Flings), версия которой должна соответствовать версии вашего физического хоста ESXi, который вы хотите восстановить.

Шаг 2 — Скопируйте файл state.tgz с физического хоста ESXi, который вы хотите восстановить. Обязательно сделайте резервную копию на случай, если допустите ошибку.

• Если ваш хост ESXi установлен на USB, отключите USB-устройство, подключите его к настольной системе и скопируйте файл с тома BOOTBANK1.
• Если ваш хост ESXi установлен на HDD/SSD, вам нужно будет загрузить физическую систему с помощью Linux LiveCD (Ubuntu или Knoppix) и смонтировать раздел 5 для доступа к файлу state.tgz.

Шаг 3 — Скопируйте файл state.tgz с вашего физического хоста ESXi на вложенный хост ESXi и поместите его в /tmp/state.tgz, затем выполните следующую команду для извлечения содержимого файла:

tar -zxvf state.tgz
rm -f state.tgz

Шаг 4 — Войдите на ваш вложенный хост ESXi и выполните следующие команды для извлечения его файла state.tgz, который будет помещен в каталог /tmp/a. Затем мы используем утилиту crypto-util для расшифровки файла local.tgz.ve вложенного хоста ESXi, чтобы получить файл local.tgz, и затем просто удаляем зашифрованный файл вместе с файлом encryption.info вложенного хоста ESXi. После этого мы заменим их файлом encryption.info с нашего физического хоста ESXi и создадим модифицированную версию state.tgz, которая будет загружаться в нашей вложенной виртуальной машине ESXi. Мы используем это для расшифровки исходного файла state.tgz с нашего физического хоста ESXi.

mkdir /tmp/a
cd /tmp/a
tar xzf /bootbank/state.tgz
crypto-util envelope extract --aad ESXConfiguration local.tgz.ve local.tgz
rm -f local.tgz.ve encryption.info
cp /tmp/encryption.info /tmp/a/encryption.info
tar -cvf /tmp/state-mod.tgz encryption.info local.tgz

После успешного выполнения последней команды, нам нужно скопировать файл /tmp/state-mod.tgz на ваш рабочий стол, а затем выключить вложенную виртуальную машину ESXi.

Шаг 5 — Смонтируйте первый VMDK диск из вашей вложенной виртуальной машины ESXi на вашу виртуальную машину с Linux. В данном случае Вильм использует Photon OS, который также управляет и DNS-инфраструктурой.

Шаг 6 — Убедитесь, что VMDK вашей вложенной виртуальной машины ESXi виден в вашей системе Linux, выполнив следующую команду. Мы должны увидеть два раздела bootbank (5 и 6), как показано на скриншоте ниже:

fdisk -l

Шаг 7 — Перенесите файл state-mod.tgz, созданный на Шаге 4, на вашу виртуальную машину с Linux, затем смонтируйте оба раздела bootbank и замените файл state.tgz на нашу модифицированную версию.

mount /dev/sdb5 /mnt
cp ~/state-mod.tgz /mnt/state.tgz -f
chmod 755 /mnt/state.tgz
umount /mnt

mount /dev/sdb6 /mnt
cp ~/state-mod.tgz /mnt/state.tgz -f
chmod 755 /mnt/state.tgz
umount /mnt

Примечание: Этот шаг необходим, потому что, если вы просто скопируете модифицированный файл state.tgz напрямую на USB-устройство физического хоста ESXi, вы обнаружите, что система восстановит оригинальный файл state.tgz, даже если на обоих разделах содержится модифицированная версия.

Шаг 8 — Сделайте remove (не удаляйте) VMDK файл вложенной виртуальной машины ESXi с виртуальной машины Linux, затем включите вложенную виртуальную машину ESXi.

После успешной загрузки вложенной виртуальной машины ESXi, она теперь работает с оригинальным файлом encryption.info с нашего физического хоста ESXi, что позволит нам восстановить исходный файл state.tgz.

Шаг 9 — Скопируйте исходный файл state.tgz, созданный на Шаге 2, во вложенную виртуальную машину ESXi, поместите его в каталог /tmp/state.tgz и выполните следующую команду, которая теперь позволит нам расшифровать файл state.tgz с физического хоста ESXi, как показано на скриншоте ниже!

cd /tmp
tar -zxvf state.tgz
rm -f state.tgz
crypto-util envelope extract --aad ESXConfiguration local.tgz.ve local.tgz
rm -f local.tgz.ve

Шаг 10 — После расшифровки исходного файла state.tgz у нас должен появиться файл local.tgz, который мы извлечем локально в каталоге /tmp, выполнив следующую команду:

Следующие три каталога: .ssh, etc/ и var/ будут размещены в /tmp, а /tmp/var/lib/vmware/configstore/backup/current-store-1 — это хранилище конфигурации ESXi для физического хоста ESXi, которое нам нужно обновить и заменить оригинальный хеш пароля root на желаемый, чтобы мы могли войти в систему.

Для непосредственного изменения хранилища конфигурации ESXi нам необходимо использовать утилиту sqlite3, так как файл хранится в виде базы данных sqlite3. Мы можем выполнить следующую команду на вложенной виртуальной машине ESXi, чтобы проверить текущий хеш пароля root:

/usr/lib/vmware/sqlite/bin/sqlite3 /tmp/var/lib/vmware/configstore/backup/current-store-1  "select * from config where Component='esx' and ConfigGroup = 'authentication' and Name = 'user_accounts' and Identifier = 'root'"

Шаг 11 — Вам потребуется новый хеш пароля в формате SHA512, где вы знаете сам пароль, после чего выполните следующую команду, заменив хеш.

/usr/lib/vmware/sqlite/bin/sqlite3 /tmp/var/lib/vmware/configstore/backup/current-store-1  "update config set UserValue='{\"name\":\"root\",\"password_hash\":\"\$6\$s6ic82Ik\$ER28x38x.1umtnQ99Hx9z0ZBOHBEuPYneedI1ekK2cwe/jIpjDcBNUHWHw0LwuRYJWhL3L2ORX3I5wFxKmyki1\",\"description\":\"Administrator\"}' where Component='esx' and ConfigGroup = 'authentication' and Name = 'user_accounts' and Identifier = 'root'"

Примечание: Вам нужно правильно экранировать любые специальные символы, например, как в приведенном выше примере, где хеш пароля содержит символ "$". Чтобы убедиться, что замена хеша выполнена правильно, вы можете выполнить вышеуказанную команду запроса, чтобы убедиться, что вывод соответствует желаемому хешу пароля, как показано на скриншоте ниже.

Шаг 12 — Теперь, когда мы обновили хранилище конфигурации ESXi с нашим желаемым паролем root, нам нужно заново создать файл state.tgz, который будет содержать наши изменения, выполнив следующие команды:

rm -f local.tgz 
tar -cvf /tmp/local.tgz .ssh/ etc/ var/ 
tar -cvf /tmp/state-recover.tgz encryption.info local.tgz

Скопируйте файл /tmp/state-recover.tgz с вложенной виртуальной машины ESXi на вашу виртуальную машину с Linux, которая затем будет использоваться для монтирования носителя физического хоста ESXi, чтобы заменить файл state.tgz на нашу восстановленную версию.

Шаг 13 — Смонтируйте носитель физического хоста ESXi на вашу виртуальную машину с Linux. Поскольку физический хост ESXi установлен на USB, можно просто подключить USB-устройство напрямую к виртуальной машине с Linux.

Снова мы можем убедиться, что виртуальная машина с Linux видит носитель с установленным физическим хостом ESXi, выполнив команду fdisk -l, и мы должны увидеть два раздела bootbank (5 и 6), как показано на скриншоте ниже.

Шаг 14 — Теперь нам просто нужно смонтировать раздел bootbank и заменить оригинальный файл state.tgz на нашу модифицированную версию (state-recover.tgz).

mount /dev/sdb5 /mnt 
cp ~/state-recover.tgz /mnt/state.tgz 
chmod 755 /mnt/state.tgz 
umount /mnt

Примечание: Поскольку физический хост ESXi был только что установлен, на втором разделе bootbank не было ничего для замены, но если вы найдете файл state.tgz, его также следует заменить, используя ту же команду, но указав другой номер раздела.

Шаг 15 — Последний шаг: размонтируйте носитель физического хоста ESXi с виртуальной машины Linux, затем включите ваш физический хост ESXi, и теперь вы сможете войти в систему, используя обновленный пароль root!

В этом демо-ролике, представленном компанией VMware, демонстрируется, как можно использовать VMware vDefend для блокировки небезопасных протоколов и защиты рабочих нагрузок в корпоративной инфраструктуре от потенциальных угроз.

Проблема небезопасных протоколов

Небезопасные протоколы, такие как SMB версии 1, могут быть уязвимы для атак. Например, уязвимость SMBv1 может позволить злоумышленнику получить доступ к виртуальной машине, если система не была своевременно обновлена. Проблема может усугубляться тем, что в некоторых случаях обновление системы невозможно из-за бизнес-ограничений.

Для демонстрации в видео используются две машины:

• Windows 7 с включенным SMBv1, которая не предназначена для предоставления файловых сервисов.
• Windows Server 2016, выступающий в роли файлового сервера, который хранит конфиденциальные данные компании.

Обе машины не обновлялись, что делает их уязвимыми для эксплоита EternalRomance. Эта уязвимость позволяет злоумышленнику получить доступ к системе, после чего он может похитить данные или перемещаться по сети, атакуя другие машины.

Как VMware vDefend защищает инфраструктуру

1. Ограничение доступа с использованием брандмауэра (DFW)

В первую очередь, демонстрируется, как злоумышленник использует уязвимость на машине с Windows 7, которая не является файловым сервером, но продолжает принимать SMB-трафик. После успешного взлома злоумышленник получает неограниченный доступ к системе.

Чтобы предотвратить подобные атаки, с помощью VMware vDefend создается правило, которое ограничивает доступ к сервисам SMB только для нужных диапазонов IP-адресов (RFC 1918 в этом примере). Все остальные подключения, использующие SMB, будут заблокированы. Таким образом, злоумышленник больше не может воспользоваться уязвимостью Windows 7, и попытка повторного взлома завершается неудачей.

2. Защита файлового сервера с использованием Intrusion Detection and Prevention (IDP)

Вторая часть видео фокусируется на защите Windows Server 2016. Поскольку файловый сервер должен продолжать предоставлять доступ к конфиденциальным данным, простое блокирование SMB не подходит. Для этого используется система обнаружения и предотвращения вторжений (IDP), которая контролирует трафик и блокирует вредоносные пакеты.

Для защиты сервера создается специальный профиль, который отслеживает все попытки проникновения через протокол SMB и, при обнаружении подозрительного трафика, блокирует его. В случае атаки трафик блокируется, и вредоносное ПО не может выполнить свои действия, предотвращая эксплуатацию системы.

Мониторинг событий и дальнейшие действия

После блокировки атаки администраторы могут использовать встроенные инструменты мониторинга для детального анализа инцидента. В VMware vDefend доступны такие данные, как IP-адреса источников, целевые машины, идентификаторы сигнатур атак и другие полезные сведения, которые можно передать в команду безопасности (SOC) для дальнейшего расследования.

Также можно экспортировать захваченные пакеты для их анализа в сторонних программах, таких как Wireshark, что позволяет точно выяснить, какие данные пытался отправить злоумышленник.

VMware vDefend предоставляет мощные инструменты для защиты рабочих нагрузок от небезопасных протоколов, предотвращая эксплуатацию уязвимостей, боковое перемещение злоумышленников в сети и утечку данных. В видео выше демонстрируется, как можно комбинировать функции брандмауэра и системы предотвращения вторжений для обеспечения всесторонней безопасности корпоративной инфраструктуры.

Недавно компания Veeam представила второй релиз бесплатного решения Veeam Hardened Repository ISO. Первая версия была выпущена еще в июне 2023 года, сейчас вышло ее обновление. Veeam Hardened ISO Repository (VHR) предназначен для облегчения создания защищённого Linux-репозитория для решения Veeam Backup and Replication, так как не каждый администратор имеет достаточный опыт работы с Linux для эффективной защиты операционной системы. Veeam предлагает инструмент, который позволяет сделать это быстро и легко. Скачивание доступно бесплатно, но поскольку это технологическое превью, этот инструмент пока не следует использовать в производственных средах. ISO позволит вам создать безопасный репозиторий с функцией неизменяемости данных (immutability).

Преимущества ISO

• Главное преимущество ISO заключается в том, что вам не нужно выполнять дополнительные настройки или запускать скрипты (система уже защищена благодаря специальному установщику).
• В системе нет пользователя root.
• Благодаря использованию Rocky Linux в качестве основы, вы получаете 10 лет поддержки для ОС.
• После выхода официальной версии вы также получите поддержку от Veeam.
  

Требования

• Оборудование, поддерживаемое RedHat (для развертывания в производственной рекомендуется физический сервер, для лабораторных условий возможна виртуальная машина), сам ISO основан на Rocky Linux.
• Те же требования к CPU и RAM, что и для Linux-репозиториев.
• 2 диска с объёмом не менее 100 ГБ каждый.
• Поддерживается только внутреннее хранилище или напрямую подключаемое хранилище с аппаратным RAID-контроллером и кэшем записи.
• UEFI должен быть активирован.
• Минимальная версия Veeam - V12.2.

Veeam Hardened ISO — это загрузочный ISO-образ, разработанный для упрощения настройки Veeam Hardened Repositories. Этот новый метод доставки устраняет необходимость в глубоком знании Linux, делая его доступным для более широкой аудитории. Развертывая защищённые репозитории через этот ISO, пользователи могут значительно снизить затраты на постоянное управление и повысить безопасность своей инфраструктуры резервного копирования.

Одной из ключевых особенностей Veeam Hardened ISO является возможность создания безопасного и неизменяемого репозитория для резервного копирования. Это означает, что после записи данных в репозиторий их нельзя изменить или удалить, что защищает их от атак программ-вымогателей и других вредоносных действий. Такой уровень безопасности крайне важен в современном мире, где утечки данных и кибератаки становятся всё более частыми.

Вам предоставляется преднастроенная операционная система с автоматически применённым профилем безопасности DISA STIG. Также доступен инструмент настройки защищённого репозитория (Hardened Repository Configurator Tool), который упрощает настройку сети и позволяет изменить такие параметры, как настройки HTTP-прокси, имя хоста, пароль для пользователя vhradmin, временное включение SSH, обновление ОС и компонентов Veeam, сброс защиты от смещения времени, а также выполнять простые действия, такие как вход в систему, перезагрузка или выключение.

Ключевые особенности Veeam Hardened ISO

• Упрощённое развертывание — Veeam Hardened ISO значительно упрощает процесс развертывания, позволяя пользователям настраивать защищённые репозитории без необходимости глубокого знания Linux. Эта простота в использовании гарантирует, что даже пользователи с ограниченными техническими навыками могут воспользоваться передовыми возможностями защиты данных от Veeam.
• Повышенная безопасность — неизменяемость Veeam Hardened Repository гарантирует, что данные резервного копирования остаются защищёнными и не могут быть изменены. Это особенно важно в условиях атак программ-вымогателей, где целостность данных резервного копирования играет ключевую роль.
• Экономическая эффективность — благодаря снижению потребности в постоянном управлении и обслуживании, Veeam Hardened ISO помогает организациям экономить на операционных расходах. Такая эффективность делает решение привлекательным для компаний любого размера.
• Обратная связь сообщества — поскольку Veeam Hardened ISO на данный момент находится в статусе Community Preview, пользователи могут предоставлять обратную связь и вносить свой вклад в его развитие. Такой совместный подход помогает создать продукт, который будет соответствовать потребностям и ожиданиям сообщества Veeam.

Скачать Veeam Hardened Repository ISO можно по этой ссылке. Дефолтный пароль - VHRISO.

Продолжаем рассказывать об анонсах новых продуктов и технологий, представленных на конференции VMware Explore 2024.

На мероприятии VMware представила последнюю версию своего пакета безопасности VMware vDefend 4.2, о котором мы рассказывали вот тут. Эта версия представляет собой значительный шаг вперёд и опирается на прочную основу, заложенную её предшественниками, предлагая улучшенную масштабируемость, более точное обнаружение угроз и упрощённое управление.

Улучшенная масштабируемость и производительность

Одним из наиболее заметных улучшений в vDefend 4.2 является значительное увеличение масштабируемости. Новая версия демонстрирует прирост производительности до 10 раз, что гарантирует защиту даже самых требовательных сред без ущерба для скорости или эффективности.

Функция распределённого брандмауэра в vDefend 4.2 теперь поддерживает защиту VLAN и распределённых порт-групп наряду с сегментами, поддерживаемыми NSX. Это дополнение дает администраторам большую гибкость в применении политик безопасности для различных сетевых сегментов, что упрощает защиту широкого спектра виртуализированных сред.

Продвинутая защита от угроз

В vDefend 4.2 появилось 14 детекторов сетевого трафика, использующих машинное обучение и AI для обнаружения аномалий. Эта возможность продвинутой защиты от угроз позволяет осуществлять проактивную защиту как от известных, так и от неизвестных угроз. Решение для обнаружения и реагирования на сетевые угрозы (NDR), управляемое AI, непрерывно мониторит сетевой трафик, изучая нормальные шаблоны, чтобы в реальном времени обнаруживать и реагировать на вредоносную активность.

Упрощённое управление и дополнительные функции

Управление обнаружением и предотвращением вредоносного ПО стало проще в vDefend 4.2 благодаря новой функции упрощённого управления жизненным циклом Malware SVM. Эта функция устраняет необходимость в ручной установке веб-серверов, позволяя развертывать служебные виртуальные машины (Service VM) напрямую через API-вызовы. Кроме того, vDefend 4.2 поддерживает файлы OneNote, расширяя возможности обнаружения вредоносного ПО. Решение также вводит настраиваемую пользователем функцию обхода избыточной переподписки, которую можно применить глобально или для отдельных правил, что обеспечивает эффективное управление конкуренцией ресурсов без ущерба для безопасности.

Централизованное управление политиками и мониторинг

vDefend 4.2 предлагает централизованное управление политиками как для виртуальных машин, так и для контейнеров. Новая панель управления операциями брандмауэра полностью настраивается, позволяя пользователям мгновенно просматривать основные правила, вычислительные ресурсы и группы. Эти улучшения предоставляют администраторам более глубокие сведения о состоянии безопасности и облегчают применение единых политик безопасности во всей инфраструктуре.

Интеллектуальная безопасность и интеграция

Интеллектуальная безопасность была ключевым аспектом в разработке vDefend 4.2. Решение теперь беспрепятственно интегрируется с инструментами сторонних разработчиков, такими как SPLUNK и vLog Insight, что позволяет осуществлять комплексное логирование и анализ событий безопасности. Эта интеграция поддерживает более быстрое реагирование на инциденты и более эффективное ограничение угроз.

Как работает система обнаружения и реагирования на сетевые угрозы (NDR)?

Системы Network Detection & Response (NDR) непрерывно мониторят и анализируют огромные объёмы сетевого трафика и событий безопасности по различным элементам и сегментам сети. Эти системы собирают данные как с периметра сети, охватывая трафик «north-south», так и с внутренних сетевых сенсоров, которые отслеживают трафик «east-west». Используя AI и машинное обучение, инструменты NDR устанавливают базовую линию нормальной сетевой активности. Эта базовая линия позволяет системе идентифицировать и отмечать любые отклонения, которые могут указывать на вредоносное поведение.

Инструменты NDR, основанные на AI, разработаны для того, чтобы эволюционировать вместе с новыми угрозами, постоянно обучаясь на новых данных для улучшения своих возможностей обнаружения. Когда атака идентифицирована, решения NDR могут предоставить всестороннюю криминалистическую информацию, описывая всю хронологию атаки — от начального проникновения до латеральных перемещений внутри сети. Кроме того, эти системы могут автоматически инициировать процессы предотвращения и смягчения последствий для локализации и нейтрализации угрозы.

Обновления продукта в будущем

В будущем VMware намерена развивать vDefend в рамках стратегических обновлений, которые соответствуют ключевым направлениям инноваций компании. План будущих разработок включает:

• Gen AI Intelligent Assist: VMware планирует интегрировать интеллектуальную помощь на базе GenAI для защиты от угроз, что улучшит сортировку оповещений и предоставит контекстные данные о кампаниях угроз. Эта функция также будет предлагать рекомендации по устранению проблем, что упростит управление и реагирование на инциденты безопасности.
• Продвинутая защита от угроз: ожидаются значительные улучшения производительности распределённых систем IDS/IPS, с увеличением производительности до 3 раз по сравнению с текущими уровнями. VMware также представит настраиваемые сигнатуры для IDS/IPS, возможности быстрой оценки угроз и улучшенные меры по предотвращению вредоносных программ для локальных сред. Кроме того, будут развернуты новые датчики NDR для защиты физических серверов, что расширит возможности обнаружения угроз vDefend.
• Упрощение операций: предстоящие обновления упростят операции безопасности за счёт интеграции рабочих процессов с нативной функциональностью VPC в VCF 9. VMware также планирует ввести поддержку федерации для политик IDS/IPS и улучшить анализ правил брандмауэра, что сделает управление политиками более эффективным.

Более подробно о продукте VMware vDefend можно почитать здесь.