Безопасность кластера

Аутентификация на основе хостов с использованием ctcasd

Демон службы Cluster Technology Cluster Authentication Service (ctcasd) создает учетные данные на основе имени хоста и идентификационных данных клиента. Помните о том, что клиентом называется приложение, использующее клиентский API RMC.

Кроме того, ctcasd создает ключ сеанса, который может применяться в качестве симметричного ключа для обмена данными между узлами после аутентификации. Этот ключ сеанса необходим для шифрования и дешифрования данных в RSCT с использованием алгоритма симметричного ключа, который имеет более высокое быстродействие, чем алгоритмы открытого и закрытого ключа (public and private key algorithms, PPK).

Чтобы обеспечить конфиденциальность данных о секретном ключе сеанса и целостность учетных данных хоста, ctcasd использует пару открытый/закрытый ключ для шифрования и дешифрования этой информации. В текущей реализации эта пара ключей генерируется с использованием алгоритма RSA512. Это можно изменить, задав 1024-разрядный ключ, путем редактирования файла конфигурации ctcasd ( /usr/ sbin/rsct/cfg/ctcasd.cfg ).

Чтобы убедиться в том, что ctcasd использует корректный открытый ключ в процессе шифрования, открытые ключи в файле списка доверенных хостов (trusted host list, THL) связываются с именем хоста. Поэтому необходимо, чтобы все узлы в кластере HACMP выполняли разрешение имен идентичным образом.

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

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

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

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

Служба IDM (Identity Mapping Service)

Результат работы службы IDM (Identity Mapping Service) используется для авторизации. Служба IDM сопоставляет сетевые идентификационные данные с локальными идентификационными данными, если в файлах конфигурации (называемых сопоставлениями, maps) задано правило сопоставления.

Эти локальные идентификационные данные могут использоваться в RMC для извлечения разрешения из таблицы управления доступом RMC. Описание сбора подсистемой RMC разрешений доступа к ресурсам из таблиц управления доступом см. в разделе "Таблица управления доступом RMC".

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

Как описывается в разделе "Таблица управления доступом RMC", подсистема RMC осуществляет сбор разрешений доступа к ресурсам, используя сначала сетевые идентификационные данные клиента.

Например, если пользователь david должен существовать на всех узлах в кластере из четырех узлов и иметь доступ к ресурсам на определенном узле, файл ACL подсистемы RMC на этом узле должен содержать записи для всех сетевых идентификационных данных клиента. Пример 9.3 показывает выходные данные определенного ресурса в файле ACL RMC для четырех узлов.

IBM.FileSystem
david@node001 * rw # access for david from node 001
david@node002 * rw # access for david from node 002
david@node003 * rw # access for david from node 003
david@node004 * rw # access for david from node 004

Это основная цель, для которой была разработана служба IDM. Служба IDM просто сопоставляет сетевые идентификационные данные в управляющем кластере с локальными идентификационными данными, чтобы избежать записи сотен строк в файл ACL RMC.

Файл конфигурации сопоставлений, /var/ct/cfg/ctsec_map.global, содержит отношения сопоставления между локальными и сетевыми идентификационными данными. В нашем примере файл сопоставлений должен содержать только одну строку, чтобы сопоставить пользователя david на всех узлах кластера с локальными идентификационными данными mapped_david:

unix:david@<cluster>=mapped_david

Это обеспечивает сопоставление пользователя david с каждого узла в текущем активном кластере с локальными идентификационными данными mapped_david с использованием сопоставлений, инициируемых UNIX MPM. Эти локальные идентификационные данные не обязательно должны существовать в качестве реальногопользователя в операционной системе. Доступ к ресурсам осуществляется, даже если эти идентификационные данные не существуют локально (в /etc/passwd ).

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

IBM.FileSystem
mapped_david * rw # access for david from node 001

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

Изначально глобальный файл сопоставлений содержит эти записи, как показано в примере 9.5 (например, unix: определяет MPM, используемый для аутентификации, а =root определяет локальные идентификационные данные).

cat /var/ct/cfg/ctsec_map.global
unix:root@<cluster>=root
unix:root@<any_cluster>=any_root
unix:*@LOCALHOST=*

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

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

Таблица управления доступом RMC

RMC использует таблицу управления доступом (access control list, ACL) для разрешения или запрета доступа к ресурсам в одноранговом домене RSCT. Таблица управления доступом обновляется HACMP во время процедур администрирования кластера (например, при добавлении и удалении узлов).

После успешной аутентификации клиента в RMC, выполняется поиск разрешений по заданным критериям в ACL (рис. 9.7). Файл ACL RMC имеет расположение /usr/ sbin/rsct/cfg/ctrmc.acl.

Файл ACL состоит из разделов (stanzas), содержащих классы ресурсов и определенные разрешения пользователей и хостов в кластере. RMC применяет два типа идентификационных данных для извлечения разрешений, хранящихся в ACL. Эти типы идентификационных данных следующие:

• сетевые идентификационные данные клиента, представленные именем пользователя и именем хоста клиента, например root@node1.
• локально сопоставленные идентификационные данные, описанные в разделе "Служба IDM (Identity Mapping Service)".

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