Мы часто пишем заметки о безопасности виртуальной инфраструктуры VMware vSphere и других продуктов на данной платформе (их можно найти по тэгу Security). И вот на днях я натолкнулся на интересную статью "It’s a Unix system, I know this!", в которой есть одна умная мысль, касающаяся настройки безопасности, и которую я часто пытаюсь донести до заказчиков. А именно: некорректное планирование и исполнение процедур по обеспечению безопасности может привести к еще большим проблемам как с точки зрения конфигурации виртуальной среды, так и с точки зрения самой безопасности.
Итак, обратимся к статье. Есть такая организация в штатах Defense Information Systems Agency (DISA), которая выпускает документ Security Technical Implementation Guide (STIG), являющийся руководящим документом по обеспечению безопасности для правительственных организаций. Есть подозрение, что в части виртуальных машин он сделан на основе VMware vSphere Security Hardening, однако не из самой актуальной версии последнего.
Так вот в этом DISA STIG есть пункты, касающиеся виртуальных машин, например, пункт про отключение операций Copy/Paste с гостевой ОС виртуальной машины из ОС компьютера, где выполняется vSphere Client.
Посмотрим, как рекомендуется выполнить эту процедуру:
To edit a powered-down virtual machine’s .vmx file, first remove it from vCenter Server’s inventory. Manual additions to the .vmx file from ESXi will be overwritten by any registered entries stored in the vCenter Server database. Make a backup copy of the .vmx file. If the edit breaks the virtual machine, it can be rolled back to the original version of the file.
1. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Storage. Right-click on the appropriate datastore and click Browse Datastore. Navigate to the folder named after the virtual machine, and locate the <virtual machine>.vmx file. Right-click the .vmx file and click Remove from inventory.
2. Temporarily disable Lockdown Mode and enable the ESXi Shell via the vSphere Client.
3. Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials. If connecting to vCenter Server, click on the desired host. Click the Configuration tab. Click Software, Security Profile, Services, Properties, ESXi Shell, and Options, respectively. Start the ESXi Shell service, where/as required.
4. As root, log in to the ESXi host and locate the VM’s vmx file.
# find / | grep vmx
Add the following to the VM’s vmx file.
keyword = “keyval”
Open the vSphere/VMware Infrastructure (VI) Client and log in with appropriate credentials.
If connecting to vCenter Server, click on the desired host.
Click the Configuration tab.
Click Storage.
Right-click on the appropriate datastore and click Browse Datastore.
Navigate to the folder named after the virtual machine, and locate the <virtual machine>.vmx file.
Right-click the .vmx file and click Add to inventory. The Add to Inventory wizard opens.
Continue to follow the wizard to add the virtual machine.
Круто, да? Это все для того, чтобы просто отключить копирование из консоли ВМ (для одной машины), которое если уж кому-то очень сильно понадобится - он сделает все равно через принтскрин или еще как.
А теперь подумаем, к чему это все может привести:
В процессе такой настройки администратор может что-то испортить.
Сотни виртуальных машин обработать таким способом очень долго и нудно.
Такая процедура открывает больше дырок, чем закрывает (администратор снимает Lockdown хоста, делает операции в шеле и тыркается по вицентру).
Контролировать исполнение процесса очень сложно - все ли локдауны были закрыты, по всем машинам ли мы прошлись и т.п.
Конечно же, есть простой и элегантный способ сделать все это сразу для всех ВМ и с помощью PowerCLI через методы, описанные в пунктах vm.disable-console-copy и vm.disable-console-paste документа vSphere Hardening Guide.
Однако те из вас, у кого в компании есть отдел информационной безопасности, знают что такое формализм этих ребят, которые может в виртуализации и не разбираются, зато прекрасно понимают, что приведенный выше гайд несколько отличается от двух строчек на PowerShell.
И, хотя это в основном касается западных организаций, в отечественных крупных компаниях тоже возникают проблемы из-за подобных процедур.
Так вот какова мораль сей басни:
При разработке руководящих документов по обеспечению безопасности виртуальной инфраструктуры поймите, какие требования являются обязательными, а какие можно реализовать факультативно (то есть не реализовывать вовсе). Минимизируйте число обязательных требований и по мере необходимости расширяйте.
Используйте последние версии руководящих документов по ИБ от вендоров и всегда обновляйте свои собственные (хотя бы с выходом мажорной версии продукта).
Максимально применяйте автоматизацию при выполнении процедур по конфигурации безопасности. В VMware vSphere и других продуктах VMware можно автоматизировать практически все.
Если выполнение требования к ИБ виртуальной среды потенциально может открыть еще больше дырок, вызвать ошибки конфигурации и причинить еще беды, подумайте - а может стоит отказаться от этого требования или переформулировать его?
Ну а если кратко - с головой надо подходить, а формализм отставить. Больше интересных подробностей - в статье.
RSS
