PCI DSS vs VMware part 4-2

- Запрет контроля устройств ESXi-сервера со стороны виртуальных машин. В общем, чтобы пользователи не отсоединяли\присоединяли CD-ROM, сетевые адаптеры и не меняли их параметры (включить\выключить) это надо запретить. Запрещается на уровне vm. Т.к. в моей тестовой инфраструктуре только две vm, буду делать вручную, не заморачиваясь на автоматизации. Можно править вручную *.vmx, а можно через vSphere Client:

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

- Настройка безопасности для виртуальных коммутаторов. К сожалению, полноценно выполнить все требования данного пункта в моей тестовой среде я не могу. Флаг "Соответствует" я не получу :(. А суть требования заключается в:
- изоляции трафика: управления, vMotion, IP трафика файловых хранилищ.
- контроль за доступом к сети управления.
- запрет смешанного режима работы для виртуального коммутатора.
- запрет на смену MAC адресов.
- запрет существования неиспользуемых портов в группах портов виртуальных коммутаторов
- запрет на установку у групп портов значений VLAN в native VLAN.
- запрет на использование 4095 VLAN
- запрет на использование в виртуальном коммутаторе VLAN зарезервированных физическими коммутаторами
- Документирование всех VLAN и их назначения и т.п..
Большая часть этих параметров описана в бестпрактисах по настройка сети в виртуальной инфраструктуре и предварительно учитываются при построении "идейно правильных" архитектур.

- Отключение Direct Conlole User Interface. Выполнить это требование не сложно, но стоит ли ? Может пора прибегнуть к пункту "оценить риски и выработать компенсационные меры" в виде строго контроля за доступом к группе "localadmin", члены которой могут получать доступ к DCUI. А отключение делается так:
>chkconfig DCUI off
- Запрет подключения съемных устройств на ESXi-сервере. Этот пункт обсуждался, когда разговор шел про USB. Делаем так:

floppyX.present = "false"
serialX.present = "false"
parallelX.present = "false"
usb.present = "false"
ideX:Y.present = "false"


- Отключение Tech Support Mode. Насколько я понимаю в ESXi 5 это равносильно отключению ESXi Shell (эта KB как бы намекает на это). Поэтому просто останавливаем ESXi Shell:

- Запрет операций с буфером обмена. Действуем по старой схеме:

isolations.tools.copy.disable = "TRUE"
isolation.tools.paste.disable = "TRUE"
isolation.tools.dnd.disable= "TRUE"
isolation.tools.setGUIOptions.enable= "FALSE"

Установка и поддержка целостности файловой системы. Честно говоря я не придумал доступного решения этой задачи без кастомизации ESXi. Буду просто проверять SHA1 суммы перед установкой ESXi и обновлений.

- Синхронизация времени.  Настраиваем синхронизацию с DC или какой-нибудь Cisco, где поднят NTP сервер.


Я попробовал выполнить все требования для "Соответствия" PCI DSS описанные в vGate Compliance Checker. В следующий раз рассмотрим чем соответствие PCI DSS у vGate Compliance Checker отличается от требований VMware Compliance Checker for vSphere. 


PCI DSS vs VMware part 4

Ниже я опишу как получить "чистый" скан в vGate Compliance Checker и VMware Compliance Checker for vSphere  для инфраструктуры установленной по принципу next->next->next. Не совсем типичный случай, но наиболее полно отражающий несоответствие стандарту PCI DSS.


Исследуемая  инфраструктура: ESXi  5.0.0, vCenter server установлен вместе с  MS SQL Server 2k8 R2 на MS Windows 2k3 st. R2 x64. Предварительно настроена только доменная авторизация. 

Результат скана vGate Compliance Checker:
Добавляем сервер ESXi, вводим имя учетной записи, пароль, запускаем скан:




vGate Compliance Checker for VMware ESX/ESXi Отчет о проверке
























vGate Compliance Checker for VMware ESX/ESXi Отчет о проверке
vGate Compliance Checker
Отчет о проверке
Информация о соответствии настроек Ваших ESX/ESXi-серверов политикам безопасности PCI DSS, CIS Vmware ESX Server Benchmark и VMware Security Hardening Guide
Статистика
Проверено серверов:1
Соответствуют политикам:0
Не соответствуют политикам:1
С ошибками:0

[+] Сервер 192.168.10.128



Результаты политик для VMware 4.1 и CIS for ESX 4 нам пока не интересны.


PCI DSS наш сервер, естественно не соответствует. Для устранения уязвимостей буду использовать ESXi Shell (предварительно придется в services запустить ESXi Shell и SSH server) и PowerCLI.

- Запрет использования Managed Object Browser. Устранение этой уязвимости оставим напоследок, после ее устранения vGate Compliance Checker "ломается" (перестает получать данные от ESXi хоста)
 >vim-cmd proxysvc/remove_service "/mob" "httpsWithRedirect"

- Настройка логирования виртуальных машин на ESXi сервере. 
Я внес изменения в каждый *.vmx
logging = "true"
log.rotateSize = "100000"
log.keepOld = "10"

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

log.fileName = "/vmfs/volumes/datalog01/logvm/vmname.log"

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

- Отсылка событий сервера виртуализации на syslog-сервер. Тут все совсем просто: перенаправляете логи ESXi на VMware Syslog Collector или любой другой централизованный сервер сбора логов, используемый в Вашей инфраструктуре.



- Запрет подключения USB-носителей к ESX/ESXi-серверу. Требование совершенно непонятно. Очень часто сервера используют всякие Token и прочие key. Вероятно авторы требования считают что ключи будут использоваться с помощью всяких USB over TCP/IP подключаясь через Cisco ASA. 
Я трактую этот пункт как: исключите возможность подключения различных не авторизованных устройств: USB, CD-ROM, floppy. Например:
floppy.present = "false"
Для остальных проводите проверку и инвентаризацию с помощью PowerCLI:

Get-VM | Get-USBDevice
Если такой вариант не устраивает, то отключите USB в BIOS, на BIOS поставьте пароль, состоящий из двух частей записанных на четыре листика, спрятанных в сейфы. 
По остальным пунктам продолжу в следующей части.

PCI DSS vs VMware part 3

В прошлой части удалось собрать документы, которых достаточно для формирования понимания требований стандарта безопасности PSI DSS. Взяв требования из Information supplement PCI DSS Virtualization Guidelist и найдя способ их реализации в VMware vSphere 5 Security Hardening Guide вполне можно построить инфраструктуру соответствующую требованиям стандарта PCI DSS. 


Теперь пара слов про способы проверки. Самый лучший и достоверный - это аудит компаниями уполномоченными на проверку соответствия требованиям PCI DSS - не очень дешево, да и хочется проверить все предварительно самому. Внутренняя проверка сотрудниками отдела безопасности - как показывает практика, знания безопасников в области виртуализации оставляют желать лучшего. Нужно что-то бесплатное, автоматическое и от тех, кто в этом что-то понимает:

- vGate Compliance Checker - бесплатное приложение, позволяющее проверить соответствие виртуальной инфраструктуры требованиям PCI DSS и не только. vGate Complience Cheker бесплатный продукт от компании Код Безопасности. На сайте компании можно найти массу полезного материала для подготовки инфраструктуры к PCI DSS и продукт vGate R2, который за денежку сделает все сам за вас (кофе не варит).

- VMware Compliance Checker for vSphere - тоже бесплатно, но от VMware.


Теперь у нас есть все для практической части: требования, техническая реализация, инструменты для проверки. 

PCI DSS vs VMware part 2

В прошлый раз я попробовал описать свой взгляд и понимание стандарта безопасности PCI DSS. Сейчас постараюсь взглянуть на стандарт сквозь призму виртуализации.

Открываем стандарт, запускаем поиск, вбиваем virtualization  и получаем:


The PCI DSS security requirements apply to all system components. In the context of PCI DSS, ―system components are defined as any network component, server, or application that is included in or connected to the cardholder data environment. ―System components also include any virtualization components such as virtual machines, virtual switches/routers, virtual appliances, virtual applications/desktops, and hypervisors.

Where virtualization technologies are in use, implement only one primary function per virtual system component.
Это ровно два раза и совсем малоинформативно.


Вероятно, Payment Card Industry Security Standart Council понимая отставание требований описанных в стандарте от ситуации в IT примерно год назад дополнила требования PCI DSS выпустив замечательный документ - Information supplement: PCI DSS Virtualization Guidelines. Запускать поиск по этому документу бесполезно - весь документ о виртуализации. С документом разберемся позже, а теперь посмотрим, что есть по поводу безопасности у VMware:


В первую очередь это: VMware vSphere 5 Security Hardening Guide и vSphere Hardening Guide: 4.1 and 5.0 comparison., а также vSphere Security, который доступен кроме pdf в форматах mobi и epub.

У CIS тоже есть свое задокументированное мнение по этому поводу CIS VMware ESX Server 4 Benchmark v1.1.0, немного опаздывают с версией, но это все таки "другой" взгляд на безопасность.


PCI DSS part 1

Лето у меня проходит под знаком PCI DSS vs Virtualization. Информация накапливается, постараюсь агрегировать ее в парочке другой постов "про это". А ввиду того, что осенью предстоит готовить виртуальную инфраструктуру к аудиту на соответствие требованиям стандарта, будет написано и о непосредственно реализации требований стандарта.

PCI DSS - стандарт, который описывает требования к защите данных держателей карт. В общем, если организация хранит данные держателей карт, то ее инфраструктура, где все это хранится и обрабатывается должна соответствовать PCI DSS. Хотя условие не обязательное, не хотите - не соответствуйте, придется платить штрафы, например, Visa (e).

Текст стандарта можно скачать тут 

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

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

- документирование всего: паспорта на все системы, сервера, оборудование. Причем реальные настройки всего должны полностью соответствовать описанным в документации. В процессе внесения изменений в конфигурации сначала инициируется описание этих изменений, потом сами изменения. Дело очень даже полезное, зачастую изменения в IT инфраструктуре происходят стихийно и бесконтрольно, что впоследствии усложняет процедуру администрирования. А ситуация "..... какая .... поменяла настройки этого сервера" знакома почти каждому администратору.

- ролевой доступ. Администратор ОС не может администрировать прикладное ПО, администратор windows не админит Linux или сетевое оборудование и т.д..

- логирование всего, что только можно логировать. А все "налогированное" хранить централизованно и анализировать.

- все остальное это вполне нормальные требования к firewall, портам, беспроводным сетям, DMZ, сервисам, протоколам, крипто механизмам, ключам, шифрованию, паролям, тестированию ПО, учетным записям, аудиту и т.п.

... а вокруг всего этого процедуры, процедуры, процедуры.

Совершенно обычные требования обычных безопасников к обычным айтишникам. Безопасности много не бывает, даже если она мешает администраторам выполнять свои непосредственные задачи.

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

Документ полезен для ознакомления, даже если сам PCI DSS не актуален для Вашей организации. В Интернете есть масса комментариев, пояснений, разъяснений  к стандарту. Очень много полезной информации на сайте русского сообщества профессионалов PCI DSS.

PowerCLI and Annotations vm

Если у вас что-то есть, то это надо учитывать и инвентаризировать, даже если это что-то виртуальное.

Обычно для таких целей в ИТ используют КЕ-manager, который интегрирован с service manager и всякими другими менеджерами. Очень полезная штука для описание имеющегося оборудования, систем и т.п., КЕ-manager позволяет описывать различные свойства конфигурационной единицы: серийные номера, гарантия, ТТХ, владельцы. В общем, КЕ-manager это как экселевский файлик только круче =)

Для описания виртуальных машин я использую следующие параметры:
owner - имя сервера
service - сервис предоставляемый сервером
created - дата создания сервера
inprod - дата передачи сервера подразделению-владельцу сервиса
EOL - дата истечения срока эксплуатации. Весьма полезный параметр для тестовых машин.
lastreview - дата последней инвентаризации
nextreviewдата следующей инвентаризации
maintenance - период времени когда сервер можно перегружать\выключать не уведомляя   владельца сервиса
backupdepth - глубина резервного копирования

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

Достаточно часто возникает необходимость в получении этих данных. Owner и service так вообще незаменимая информация. Только вот каждый раз лазить в KE-manager за такой информацией не очень удобно. Хочется все наглядно и автоматически из VSphere Client.

наглядно: для каждой VM в VSphere Client есть целое поле "Annotaion", которое и предназначено для такой информации. В нем можно создавать Attribute, давая им имена и присваивая значения. И такой возможностью не стоит пренебрегать.
автоматически: есть KE-manager (экселевкий файлик), где данные параметры уже заполнены  заполняются давно и на регулярной основе. Необходимо перенести все это в поле "Annotaion".

Выгружаем данные из KE-manager в *.csv и скармливаем полученный файлик скрипту:

# import vm data
$allvm = Import-Csv d:\vm.csv
# update attributes
foreach($vm in $allvm)
{Get-VM $vm.server | Set-Annotation -CustomAttribute OWNER -Value $vm.OWNER
Get-VM $vm.server | Set-Annotation -CustomAttribute SERVICE -Value $vm.SERVICE
Get-VM $vm.server | Set-Annotation -CustomAttribute CREATED -Value $vm.CREATED
Get-VM $vm.server | Set-Annotation -CustomAttribute INPROD -Value $vm.INPROD
Get-VM $vm.server | Set-Annotation -CustomAttribute LASTREVIEW -Value $vm.LASTREVIEW
Get-VM $vm.server | Set-Annotation -CustomAttribute NEXTREVIEW -Value $vm.NEXTREVIEW
Get-VM $vm.server | Set-Annotation -CustomAttribute MAINTENANCE -Value $vm.MAINTENANCE
Get-VM $vm.server | Set-Annotation -CustomAttribute BACKUPDEPTH -Value $vm.BACKUPDEPTH}



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


И пара организационных моментов:
 - ручное изменение параметров идет только в KE-manager
 - заполнение "Annotations" только при помощи скрипта. Все что редактируется в "Annotations" будет перезаписано при следующем запуске скрипта.
 - если вместо KE-manager используется экселевский файл, то он должен существовать в единственном экземпляре где-нибудь на сетевом ресурсе. Данная мера необходима при наличии нескольких администраторов.