gorbunov.pro: Резервное копирование сертификатов. Часть 3

Multipathing

В производственной среде система хранения должна быть подключена к хосту несколькими независимыми путями множественного ввода-вывода. Как правило, в CentOS (и следовательно oVirt’е) проблем со сборкой множественных путей к устройству не возникает (find_multipaths yes). О дополнительных настройках для FCoE написано во

. Стоит обратить внимание на рекомендацию производителя СХД — многие рекомендуют использовать политику round-robin, по умолчанию же в Enterprise Linux 7 используется service-time.

Vlans

Подробнее о сетях стоит почитать в

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

Для подключения других подсетей их сперва следует описать в конфигурации: Network -> Networks -> New, здесь обязательным полем является только имя; чекбокс VM Network, разрешающий машинам использовать эту сеть, включен, а для подключения тега надо включить Enable VLAN tagging, прописать номер VLAN и нажать Ок.

Теперь нужно пройти в хосты Compute -> Hosts -> kvmNN -> Network Interfaces -> Setup Host Networks. Добавленную сеть из правой части Unassigned Logical Networks перетащить влево в Assigned Logical Networks:

Рис. 4 — перед добавлением сети.
Рис. 5 — после добавления сети.

Для массового подключения нескольких сетей к хосту удобно при создании сетей присваить им метку(и), и добавлять сети по меткам.

После создания сети хосты перейдут в состояние Non Operational, пока на закончится добавление сети на все узлы кластера. Такое поведение вызывается признаком Require All на вкладке Cluster при создании новой сети. В случае, когда сеть нужна не на всех узлах кластера, этот признак можно отключить, тогда сеть при добавлении хосту будет справа в секции Non Required и можно выбрать, подключать ли ее к конкретному хосту.

Рис. 6 — выбор признака требования сети.

Архитектура автоматического архивирования и восстановления

После того как было разрешено автоматическое архивирование ключей при каждом запросе архивирования секретного ключа, центр CA случайным образом генерирует симметричный ключ, соответствующий стандарту 3DES (Triple Data Encryption Standard), который используется для шифрования секретного ключа PKI клиента.

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

1. Клиент PKI запрашивает AD о центре сертификации CA. Клиент выполняет целевой поиск записей CA в контейнере Enrollment Services в контексте именования конфигурации. В результате AD возвращает клиенту имя и расположение центра CA.
2. Клиент PKI запрашивает у CA копию его сертификата CA Exchange. CA возвращает клиенту сертификат.
3. Клиент PKI проверяет подлинность сертификата и его формат, проверяет подпись, а также удостоверяется в том, что сертификат не аннулирован.
4. Клиент PKI шифрует клиентский секретный ключ, для чего используется открытый ключ сертификата CA Exchange. Используя протокол управления сертификатами с синтаксисом криптографических сообщений Certificate Management protocol with Cryptographic Message Syntax (CMC), клиент добавляет к данным шифрованный блок и направляет файл в формате CMC в центр CA.
5. Центр CA дешифрует секретный ключ клиента с помощью секретного ключа, ассоциированного с сертификатом CA Exchange, а затем шифрует секретный ключ сформированным случайным образом симметричным 3DES-ключом.
6. Центр CA проверяет, образуется ли криптографическая пара между секретным ключом в файле формата CMC и открытым ключом в запросе сертификата. При этом CA проверяет подлинность подписи в запросе, используя для этого открытый ключ, направленный вместе с запросом.
7. Центр CA шифрует симметричный ключ, для чего используется один или несколько (в зависимости от конфигурации CA) открытых ключей агентов KRA.
8. Центр CA сохраняет в своей базе данных шифрованный блок, содержащий шифрованный секретный ключ клиента и симметричный ключ шифрования.
9. Центр CA обрабатывает запрос сертификата, высылает сертификат пользователю и помещает сертификат в соответствующий каталог (если этот параметр был выбран в шаблоне сертификата).

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

Сертификат CA Exchange физически размещается в атрибутах объекта AD CN=-Xchg, DC=. Секретный ключ сертификата находится в защищенной части реестра сервера CA. Из соображений безопасности пара «сертификат CA Exchange — ключ» имеет непродолжительное время жизни, равное 7 дням.

Клиентские секретные ключи и симметричные ключи хранятся в шифрованном виде в базе данных центра сертификации Windows 2003 CA. Клиентские секретные ключи отображаются в столбце RawArchivedKey, а симметричные ключи — в столбце KeyRecoveryHashes базы данных CA. Чтобы просмотреть эти столбцы и всю структуру схемы базы данных CA, нужно набрать в командной строке:

certutil -schema

Для того чтобы определить, имеются ли в базе данных CA секретные ключи сертификатов, можно воспользоваться оснасткой Certification Authority, как показано на экране 3. Для этого в контейнере CA Issue Certificates нужно добавить для отображения столбец Archived Key.

Восстановление данных и восстановление ключей

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

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

Но можно проводить восстановление данных и независимо от восстановления секретных ключей. Хорошим примером применения восстановления данных независимо от восстановления секретных ключей пользователя может служить шифрующая файловая система (EFS) в Windows 2003 и Windows 2000.

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

Если при планировании развертывания инфраструктуры PKI необходимо обеспечить восстановление данных, то при выработке решения нужно учитывать следующее.

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

Добавление дополнительных dns имен

Это потребуется, когда к менеджеру необходимо подключиться по альтернативному имени (CNAME, псевдоним или просто короткое имя без доменного суффикса). Из соображений безопасности менеджер допускает подключение только по разрешенному списку имен.

Создаем файл конфигурации:

$ sudo vim /etc/ovirt-engine/engine.conf.d/99-custom-sso-setup.conf

следующего содержания:

Документация

Дополнительные настройки менеджера

Для удобства работы поставим дополнительные пакеты:

$ sudo yum install bash-completion vim

Для включения автодополнения команд bash-completion следует перевойти в bash.

Менеджмент-интерфейс хостов

— современный административный интерфейс для Linux систем. В данном случае выполняет роль, близкую web-интерфейсу ESXi.

Рис. 3 — внешний вид панели.

Устанавливается очень просто, нужны пакеты cockpit и плагин cockpit-ovirt-dashboard:

$ sudo yum install cockpit cockpit-ovirt-dashboard -y

Включение Cockpit:

$ sudo systemctl enable --now cockpit.socket

Настройка брандмауэра:

sudo firewall-cmd --add-service=cockpit
sudo firewall-cmd --add-service=cockpit --permanent

Миграция базы данных kms exchange

Служба KMS (Key Management Service) не входит в комплект поставки Microsoft Exchange Server 2003, поэтому если имеется работающая KMS в среде Exchange 2000 Server и планируется миграция на Exchange 2003, базу данных архивированных ключей KMS потребуется перенести в базу данных архивированных ключей центра сертификации Windows 2003 Server.

Затем необходимо настроить Windows 2003 CA для архивирования ключей, как описано в основной статье. Для выполнения переноса базы необходимо также удостовериться, что сертификат Export Signing доступен. Сертификат Export Signing представляет собой копию сертификата сервера CA Machine Authentication, а секретный ключ, ассоциированный с этим сертификатом, потребуется для обеспечения защиты данных базы KMS в процессе ее экспорта и передачи в структуру Windows 2003 CA.

Данный сертификат должен быть доступен на той системе KMS, с которой будет производиться миграция данных. Если сервер CA не имеет сертификата Machine Authentication, то его необходимо получить до запуска процесса миграции. Сертификат Machine Authentication размещается в локальном хранилище сертификатов компьютеров сервера CA.

Для того чтобы скопировать данный сертификат на компьютер KMS, следует экспортировать его с сервера CA в формате Public-key Cryptography Standards (PKCS) #12 (данная процедура описана в основной статье), после чего сохранить файл в системном каталоге на компьютере KMS.

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

certutil setreg caKRAFlags  KRAF_ENABLEFOREIGN

Настройка ssl

Полная официальная инструкция — в

, Appendix D: oVirt and SSL — Replacing the oVirt Engine SSL/TLS Certificate.

Сертификат может быть как нашего корпоративного ЦС, так и от внешнего коммерческого центра сертификации.

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

Требования:

Настройка аутентификации через ad

oVirt имеет встроенную базу пользователей, но также поддерживаются внешние LDAP провайдеры, в т.ч. AD.

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

$ sudo yum install ovirt-engine-extension-aaa-ldap-setup
$ sudo ovirt-engine-extension-aaa-ldap-setup
$ sudo systemctl restart ovirt-engine

Мастер создает файлы

Настройка управления питанием

Позволяет выполнить, например, аппаратный сброс машины, если Engine не сможет продолжительное время получить ответ от Host’а. Реализуется через Fence Agent (агент ограждения).

Compute -> Hosts -> HOST — Edit -> Power Management, далее включить «Enable Power Management» и добавить агента — «Add Fence Agent» -> .

Указываем тип (напр., для iLO5 надо указать ilo4), имя/адрес ipmi интерфейса, а также имя/пароль пользователя. Пользователя рекомендуется создать отдельного (напр., oVirt-PM) и, в случае с iLO выдать ему привилегии:

Не спрашивайте почему именно так, подобрано опытным путем. Консольный fencing agent требует меньшего набора прав.

При настройке списков контроля доступа следует иметь ввиду, что агент запускается не на engine, а на «соседнем» хосте (так называем Power Management Proxy), т.е., если в кластере окажется только один узел, управление питанием работать не будет.

Ручное архивирование и обновление ключей

У пользователей инфраструктуры открытых ключей PKI среды Windows есть несколько возможностей резервного копирования своих секретных ключей шифрования вручную. Обычно для этих целей используют файлы формата Public-Key Cryptography Standards (PKCS) #12 (.PFX).

• Открыть с помощью оснастки Certificates консоли MMC соответствующее персональное хранилище сертификатов; щелкнуть правой кнопкой мыши на том сертификате или секретном ключе, для которого будет выполняться резервное копирование, затем выбрать из контекстного меню All Tasks, Export. При этом запускается мастер Certificate Export Wizard. Затем нужно установить флажки Yes, export the private key и Enable strong protection (requires IE 5.0 NT 4.0 SP4 and above). Если установлен второй флажок, тогда мастер попросит пользователя ввести пароль для защиты содержимого файла .PFX. Флажок Delete private key if export is successful устанавливать не следует.
• Запустить Microsoft Internet Explorer (IE) 6.0 и выбрать из меню Tools пункт Internet Options. В диалоговом окне Internet Options следует выбрать вкладку Content, затем открыть диалоговое окно Certificates, для чего требуется нажать Certificates. Выберите сертификат секретного ключа, который пользователю необходимо экспортировать, затем нажмите Export (при этом запустится Cerftificate Export Wizard). Установите те же самые флажки, которые описаны выше.

Пользователи также могут архивировать свои секретные ключи шифрования через Microsoft Outlook. Программа Outlook не сохраняет ключи в файле .PFX, здесь используется специальный файл экспорта Outlook, который имеет расширение .EPF. Данное расширение исторически унаследовано из технологии защищенной почты:

аббревиатура EPF означает Entrust Profile. Одна из причин, по которой Outlook до сих пор использует этот формат, заключается в том, что он поддерживает сертификаты X.509 версии 1, которые применялись в предыдущей реализации инфраструктуры Exchange Key Management Service (KMS). Как и для файлов .PFX, здесь можно использовать пароль для защиты содержимого файла .EPF.

Чтобы экспортировать секретные ключи шифрования из Outlook, нужно выбрать Tools, Options из меню Outlook и перейти на вкладку Security. Нажмите кнопку ImportExport в нижней части окна Security, чтобы открыть диалоговое окно ImportExport Digital ID. В этом окне следует выбрать Export your Digital ID to a file, после чего требуется выбрать Digital ID секретного ключа пользователя, который необходимо экспортировать, и ввести имя файла и пароль. Флажок Delete Digital ID from System устанавливать не следует.

Статьи

1. Введение
2. Установка менеджера (ovirt-engine) и гипервизоров (hosts)
3. Дополнительные настройки — Мы здесь
4. Базовые операции

Установка сертификатов

Копируем файлы и обновляем списки доверия:

Широкие возможности

Инфраструктура Windows 2003 PKI предоставляет пользователям новые гибкие возможности централизованного автоматического управления процессами архивирования и восстановления ключей. Новая служба архивирования и восстановления ключей в Windows 2003 PKI является намного более зрелой по сравнению с предыдущими реализациями инфраструктуры PKI.

Шифрование файлов windows