Безопасность кластера
Безопасность RSCT
В этой лекции описывается терминология и понятия, используемые в безопасности RSCT. Также описывается архитектура безопасности RSCT и механизмы, используемые в HACMP. Предполагается, что у вас есть знание RSCT и его базовых компонентов (таких, как RMC, диспетчеры ресурсов и т. д.). Важно понимать, что основная часть компонентов и механизмов, описанных в этой главе, не нуждается в конфигурировании; уровень безопасности RSCT работает сразу же. Кроме того, конфигурирование некоторых функций и файлов выполняется только после настройки аутентификации и шифрования сообщений HACMP (см. раздел 9.2, "Использование зашифрованных межузловых коммуникаций"). Некоторые из описанных функций не применяются в HACMP, но являются неотъемлемой частью безопасности RSCT.
RSCT и HACMP
HACMP использует RSCT в качестве уровня базовой инфраструктуры. Узлы HACMP связываются с одноранговыми узлами через компоненты RSCT, проверяя их состояние или запрашивая доступ к их ресурсам. Службы топологии (Topology Services) и службы групп (Group Services) реализуют мониторинг пульса HACMP через одноранговый домен RSCT. Подсистема RMC применяется для следующего:
- для настраиваемых событий;
- мониторинга приложений;
- динамического приоритета узлов;
- экспорта состояния сети для использования в Oracle RAC.
На рис. 9.6 показана связь между компонентами HACMP и RSCT.
Каждый раз, когда компонент HACMP (например, диспетчер кластера) одного сервера отправляет функциональный запрос к ресурсу RMC (локальному или уда
ленному), вызывается подсистема RSCT и запросы отправляются на узел, на котором находится ресурс. (рис. 9.7).
Так как удаленные подключения представляют собой подключения сокетов TCP/ IP, их необходимо защищать, чтобы обеспечить подлинность запрашивающего узла и серверного узла в кластере. Здесь в действие вступают службы безопасности кластера (Cluster Security Services, CtSec).
Между узлами кластера осуществляется связь типа "клиент-сервер". В следующих разделах под клиентом подразумевается приложение, например локальный диспетчер ресурсов или функция HACMP, использующая клиентский API RMC.
Эти клиентские приложения подключены к общим библиотекам RMC и CtSec. Если эти клиенты запрашивают доступ к ресурсам на удаленном узле, демон RMC на этом удаленном узле будет сервером для этих запросов.
Обзор служб безопасности кластера (CtSec)
Службы безопасности кластера (Cluster Security Services, CtSec) интегрированы в подсистему RSCT и используются в RMC для определения подлинности клиента с узла. Этот процесс аутентификации создает контекст безопасности, применяемый RMC для связи между участвующими узлами в целях выполнения клиентских запросов.
При создании этого контекста безопасности CtSec используют учетные данные для аутентификации. Эти учетные данные применяются для определения подлинности узла и клиентского приложения. Для доступа к ресурсам на удаленном узле, в процессе аутентификации оба узла отправляют и сравнивают учетные данные.
Этот процесс позволяет достичь следующих целей:
- клиент может представить о себе информацию, которую другие не смогут подделать;
- сервер может четко идентифицировать клиента по предоставленным учетным данным;
- клиент может быть уверен в том, что он получает данные с требуемого сервера.
Аутентификация на основе учетных данных использует другие компоненты для создания и идентификации учетных данных. Такая архитектура на основе компонентов, представленная на рис. 9.8, позволяет в будущем выполнять расширение уровня безопасности в RSCT.
В RMC службы CtSec отвечают только за аутентификацию. Вообще RMC отвечает за авторизацию с использованием таблицы управления доступом (access control list, ACL), разрешая или запрещая доступ к ресурсам в кластере.
Компоненты служб безопасности кластера (CtSec)
Библиотека CtSec содержит несколько компонентов, необходимых для обеспечения существующих и будущих функций безопасности.
Контекст безопасности, создаваемый CtSec, содержит учетные данные клиента и сервера, состояние аутентификации (выполнена или не выполнена) и информацию о сеансе (например, ключ сеанса или время завершения действия). Контекст безопасности создается компонентами CtSec и отправляется в RMC как результат аутентификации CtSec.
Абстрактный уровень механизма (MAL)
CtSec экспортирует интерфейс в приложения, требующие реализации безопасности кластера. Этот интерфейс называется абстрактным уровнем механизма (mechanism abstract layer, MAL). MAL обеспечивает общий, независимый от механизма интерфейс для базовых механизмов безопасности и отправляет эти общие инструкции на сконфигурированные модули безопасности.
Такие подключаемые модули механизма безопасности называются подключаемыми модулями механизма (mechanism pluggable module, MPM). Результатом работы MAL и сконфигурированного MPM является контекст безопасности, содержащий учетные данные и ключ сеанса, используемые обеими сторонами, участвующими в процессе связи.
Если клиент отключает аутентификацию, установив значение переменной окружения CTSEC_CC_MECH=none, MAL не применяет MPM для аутентификации, а возвращает контекст безопасности без аутентификации как результат процесса аутентификации. Конфигурирование MPM выполняется в файле /var/ct/cfg/ctcec.cfg. Этот файл содержит все MPM, которые службы CtSec должны использовать в процессе аутентификации. В будущих версиях компания IBM собирается разработать другие модули безопасности. Применение модулей основывается на предопределенных приоритетах.
Если клиент запрашивает доступ к ресурсам, MAL используется для инициирования контекста безопасности. В случае успешного выполнения процесса этот контекст кешируется уровнем MAL для последующих запросов и сохраняется в памяти до удаления приложением.
Подключаемый модуль механизма (MPM)
Каждый подключаемый модуль механизма (mechanism pluggable module, MPM) преобразует общие задачи, получаемые с уровня MAL, в необходимые задачи, используемые механизмом безопасности для выполнения запросов MAL. MPM осуществляет сбор всех учетных данных, необходимых для выполнения процесса аутентификации каждым отдельным механизмом безопасности. MPM также осуществляет сопоставление сетевых идентификационных данных с локальными идентификационными данными [см. раздел "Служба IDM (Identity Mapping Service) "].
В настоящее время поддерживается только UNIX MPM. Модуль UNIX MPM был создан для работы как в 32-, так и в 64-разрядных средах, в зависимости от ядра операционной системы. Благодаря модульной архитектуре MAL и MPM в последующих версиях могут быть добавлены другие механизмы безопасности. MPM представляют собой объектные модули, загружаемые MAL во время выполнения.
MPM расположены в каталоге /usr/sbin/rsct/lib. Каждый MPM должен иметь ссылку в каталоге /usr/lib/, указывающую на соответствующий файл в каталоге ( пример 9.2 ).
ls -al /usr/sbin/rsct/lib/*.mpm* -r--r--r-- 1 bin bin 192120 Sep 06 13:26 /usr/sbin/rsct/lib/unix.mpm -r--r--r-- 1 bin bin 199952 Sep 24 11:27 /usr/sbin/rsct/lib/unix.mpm64 ls -al /usr/lib/*.mpm* lrwxrwxrwx 1 root system 27 Oct 11 10:22 /usr/lib/unix.mpm -> /usr/sbin/rsct/lib/unix.mpm lrwxrwxrwx 1 root system 29 Oct 11 10:22 /usr/lib/unix.mpm64 -> /usr/sbin/rsct/lib/unix.mpm64Пример 9.2. Расположение MPM
Подключаемый модуль UNIX MPM
Ядром модуля UNIX MPM является клиентский API ctcasd (см. раздел "Аутентификация на основе хостов с использованием ctcasd"), который создает учетные данные аутентификации на основе хостов (host-based authentication, HBA).
Компонент ctcasd вызывается только при использовании сокетов TCP/IP для удаленных подключений. Если запрос предназначен для локального хоста, UNIX MPM применяет сокеты домена UNIX в ядре. Безопасность ядра является доверенной, и не требует использования дополнительных функций безопасности.