Безопасность логических разделов в системах на базе процессора POWER5

Безопасность логических разделов
в системах на базе процессора POWER5
13 марта 2006 г.
Принципы разработки и внедрения,
обеспечивающие безопасность разделов
Билл Армстронг (Bill Armstrong)
Стивен Бэйд (Steven Bade)
Дэвид Бутчер (David Boutcher)
Кристофер ДеРобертис (Christopher DeRobertis)
Том Мэтьюс (Tom Mathews)
Энди МакЛоглин (Andy McLaughlin)
Содержание
Введение.................................................................................................................................................................................. 3
Принципы разбиения на логические разделы (LPAR)................................................................................................. 4
Общий доступ к ресурсам............................................................................................................................................... 4
Аппаратная защита логических разделов.................................................................................................................. 5
Физическая память......................................................................................................................................................................................................6
Виртуальная память....................................................................................................................................................................................................6
Ресурсы устройств ввода-вывода.............................................................................................................................................................................6
Настройка LPAR................................................................................................................................................................. 8
Доступ к HMC . ................................................................................................................................................................ 8
Пользовательские интерфейсы HMC......................................................................................................................... 9
Сетевые интерфейсы HMC......................................................................................................................................... 10
Сервисный процессор........................................................................................................................................................ 11
Возможности подключения сервисного процессора............................................................................................. 11
Доступ к сервисному процессору................................................................................................................................ 11
Проверка сервисного процессора.............................................................................................................................. 11
Виртуализация устройств ввода-вывода................................................................................................................... 12
Реализация VIOS............................................................................................................................................................ 12
Административные средства защиты VIOS . .....................................................................................................................................................12
Виртуальный SCSI....................................................................................................................................................................................................13
Защита виртуальных локальных сетей Ethernet.................................................................................................... 14
Виртуальный коммутатор IEEE сети VLAN......................................................................................................................................................14
Виртуальный адаптер Ethernet..............................................................................................................................................................................14
Общий Ethernet-адаптер.........................................................................................................................................................................................15
Динамические логические разделы (LPAR)................................................................................................................. 16
Связь динамических логических разделов................................................................................................................17
Подсистема RMC .....................................................................................................................................................................................................17
Аутентификация и авторизация.............................................................................................................................................................................18
Ключи RSCT..............................................................................................................................................................................................................19
Порт 657 RMC ..........................................................................................................................................................................................................19
Диспетчеры ресурсов, используемые в динамических логических разделах................................................... 19
Потоки команд Dynamic LPAR/RMC........................................................................................................................ 20
Описание потоков.....................................................................................................................................................................................................21
Заключение.......................................................................................................................................................................... 22
Используемая литература.............................................................................................................................................. 23
Стр. Введение
Идея консолидации множества разрозненных систем в одном физическом аппаратном компоненте и управление ими как отдельными системными образами существовала уже давно. Она была реализована
еще в мэйнфреймах IBM System z™, сегодня же такая методика используется в серверах семейств IBM
System p™ и System i™, начиная с серверов на базе процессоров POWER4™. Сегодня серверы IBM на базе
процессоров POWER™ дают возможность консолидировать аппаратное обеспечение, сохраняя такой же
уровень разделения, который предлагают физически отдельные системы (часто такое разделение обозначается как «воздушный зазор»). Как семейство System z, так и системы на базе процессоров POWER
используют концепцию hypervisor, обеспечивающую изоляцию разделов с «виртуальным воздушным зазором». Эти механизмы разрабатывались вместе с некоторыми возможностями аппаратного обеспечения
для достижения следующих целей обеспечения безопасности1:
1. Программа или операционная система, работающая в одном разделе, не будет оказывать воздействия на другой раздел, и сбой в одном из них не повлияет на работу другого. Загрузка процессора
одним разделом не скажется на производительности другого раздела.
2. Физические области памяти, используемые различными приложениями, изолированы друг от друга.
Один раздел не сможет прочитать или изменить данных, хранящихся в области памяти, используемой другим разделом.
3. Один раздел не может получить доступ или изменить физические устройства ввода-вывода, назначенные другому разделу. Нельзя запретить прямой доступ устройства ввода-вывода к памяти, находящейся в реальном адресном пространстве другого раздела.
Изоляция и целостность логических разделов IBM eServer® System i™, Дэйв Бутчер (Dave Boutcher), IBM Corporation,
[email protected]. Июнь 2002 года.
1
Стр. Основы разбиения на логические разделы (LPAR)
Можно сказать, что ПО управления и аппаратные средства разрабатывались, реализовывались и испытывались для обеспечения выполнения политики безопасности наименьшего уровня привилегий, в которой
отдельные разделы могут обращаться только к тем ресурсам, которые назначены им в явном виде, а большинство системных ресурсов не может использоваться совместно. На рис. 1 показан обычный сервер
с разделами, распределением ресурсов ввода-вывода, устройствами управления и возможностями виртуального ввода-вывода, в этом документе будет описана семантика безопасности всех этих компонентов.
Политика безопасности наименьшего уровня привилегий реализуется посредством
1. Проверенного микропрограммного обеспечения – hypervisor.
2. Аппаратных возможностей процессора.
3. Жёсткого механизма обеспечения доступа к ресурсам различных разделов, оказывающим влияние
на определение разделов.
4. Передовых методик разработки архитектуры, конструирования и проведения испытаний, обеспечивающих возможность достижения основных целей защиты данных.
Исторически ПО и аппаратные функции систем System p на базе POWER4 строились в соответствии с этими
принципами и оценивались в соответствии с критериями EAL4 (Evaluated Assurance Level). Процессоры
IBM POWER5™, а также их планируемые последователи, построены на том же наборе возможностей.
Внешняя сеть
Другая сеть
Реальный
Ethernet
Реальный
адаптер FCA
Реальный
адаптер FCA
HMC
Сеть управления
Мост
Реальный
Ethernet
FSP
Логический раздел
Реальный
Ethernet
Виртуальный
сервер SCSI
Виртуальный
Ethernet
Виртуальный сервер ввода-вывода
Виртуальный
клиент SCSI
Виртуальный
Ethernet
Виртуальный
Ethernet
Виртуальный
коммутатор
Hypervisor
Рисунок 1
Общий доступ к ресурсам
При консолидации распределенных систем в разделы встаёт проблема организации общего доступа
к ресурсам. Используемые совместно ресурсы на уровне логических разделов на самом деле очень ограни-
2
Сертификат оценки логических разделов POWER4 http://www.bsi.bund.de/zertifiz/zert/reporte/0225a.pdf
Стр. чены, а те ресурсы, которые могут использоваться совместно, могут полностью управляться конфигурацией разделов. Разделы можно настроить таким образом, что совместное использование будет полностью
исключено: определённые процессоры, как и устройства ввода-вывода, будут выделены соответствующим
разделам. Совместное использование реального адресного пространства памяти строжайше запрещено;
нельзя настроить разделы с пересечением используемых областей реальной памяти (кэш процессора также является памятью, и, следовательно, в нём реализована такая же защита). В случаях, когда необходим
общий доступ к устройствам ввода-вывода, создаются «устройства» или служебные разделы, владеющие
физическими ресурсами ввода-вывода (т.е., устройствами, адаптерами и разъёмами ввода-вывода). На
служебные разделы накладываются те же ограничения, что и на другие разделы, а обмен данными между
ними происходит под управлением специального ПО. В случае, если настраивается совместное использование процессоров разделами, ПО управления поддерживает «виртуальный процессор» (все переменные
состояния для определённого раздела) и обеспечивает переключение контекста таким образом, что заменяются все переменные состояния, в том числе такие элементы как регистры таблицы страниц, таблицы
устройств ввода-вывода и регистры процессора. Все ресурсы общего пользования с точки зрения виртуального процессора устанавливаются в определённое для каждого логического раздела состояние, обеспечивая тем самым отсутствие канала совместного использования данных между разделами.
Аппаратная защита логических разделов
В механизмах реализации логических разделов (как аппаратных, так и программных) заложены очень
простые возможности контроля над обеспечением безопасности. В аппаратных средствах на базе POWER
был представлен специальный набор регистров, доступных только hypervisor – компоненту микропрограммного обеспечения. Процессор POWER создаёт ещё один уровень операций с более высокими
привилегиями, на котором работает hypervisor. Так же, как и в классической кольцевой архитектуре
процессора, кольцо 0 управляется ядром операционной системы с управляемыми механизмами перехода
в непривилегированное состояние (syscalls), в системах на базе hypervisor существует «кольцо -1» (т.е.,
находящееся ниже кольца ядра ОС).
Таблицы страниц,
управляемые hypervisor’ом
Физическая память
Таблицы TCE для DM,
управляемые hypervisor
Раздел 1
Процессор
Процессор
Процессор
Раздел 1
Разъём ввода-вывода
N
N
Виртуальный
адрес
Загрузка/хранение
ввода-вывода
Разъём ввода-вывода
Адреса
шины
Разъём ввода-вывода
Разъём ввода-вывода
N
Разъём ввода-вывода
Реальный
адрес
Адрес N
Раздел 2
Раздел 2
Процессор
N
Процессор
N
Процессор
N
Загрузка/хранение
ввода-вывода
Разъём ввода-вывода
Разъём ввода-вывода
Виртуальный
адрес
Адреса
шины
Разъём ввода-вывода
Разъём ввода-вывода
Разъём ввода-вывода
Адрес O
Рисунок 2
Переход к привилегированному состоянию hypervisor выполняется с помощью механизма hcall, которым
могут воспользоваться только привилегированные приложения уровня 0. Эти механизмы и аппаратные
возможности предназначены для создания «виртуального воздушного зазора» или «виртуального футляра»
для раздела. Аппаратные механизмы ориентируются в основном на обработку и наложение адресов памяти,
так как основным вопросом является предотвращение возможности одного раздела видеть память другого.
Стр. Физическая память
Как показано на рисунке 2, каждому разделу выделены определённые части физической памяти, таким
образом, кэш процессора и физическая память не являются ресурсами общего пользования системы логических разделов. Реальная (физическая) память важна, потому что абсолютно для всех операций ввода-вывода и действий операционной системы необходима связь с физической областью памяти. Это называется
режимом реальной адресации, в среде без разделов реальная память начинается с адреса 0, и используется
обычно операционной системой для хранения стационарных структур данных, векторов прерываний и
кода инициализации. Поскольку в среде логических разделов общий доступ разделов к физической памяти
невозможен, каждому из них должен быть выделен собственный диапазон реальной адресации, начало которого для раздела должно «выглядеть» адресом 0. Это выполняется при запуске раздела, когда hypervisor
назначает разделу уникальное смещение режима реальной адресации диапазона (в соответствии с определениями конфигурации раздела), после чего устанавливает эти значения управляемым hypervisor регистрам каждого процессора, используемого этим разделом. С помощью этих значений аппаратное обеспечение незаметно перенаправляет указатель памяти логических разделов в физическое пространство памяти,
добавляя к указанному адресу смещение. Доступ к реальной памяти за пределами назначенного диапазона
приведёт к возникновению ошибки адресации с включением стандартного процесса обработки ошибок
операционной системы. Аппаратная логика предотвращает изменение регистров, управляющих перенаправлением, любым кодом, работающим на любом уровне, отличном от привилегированного уровня
hypervisor.
Виртуальная память
Все современные операционные системы используют виртуальную память, что позволяет оперировать
большим объёмом памяти, чем есть на самом деле. Это называется виртуальной адресацией и выполняется ОС, под управлением которой работает система или раздел, путём сбрасывания реальной памяти
на диск и её восстановления с диска по мере необходимости. Приложения, работающие в такой операционной системе, используют виртуальный режим адресации, а преобразованием занимается ядро ОС. Для
выполнения этого преобразования механизм управления памятью ядра ОС использует таблицы перевода
страниц. Эти таблицы хранятся в системной памяти и должны быть уникальны для каждого раздела. Виртуальная адресация и таблицы страниц используются в архитектурах операционных систем достаточно
долгое время. Однако в среде логических разделов таблицами перевода памяти следует управлять иначе.
В среде, где логические разделы отсутствуют, операционная система создаёт и поддерживает таблицы
страниц, используя реальный режим адресации и набор регистров процессора, непосредственно указывающих на эту таблицу. Существование такой ситуации в среде логических разделов будет означать возможность одного раздела получать доступ к адресному пространству другого. Поэтому в среде логических
разделов таблицы перевода памяти хранятся в реальной памяти, доступ к которой имеет только hypervisor.
На регистры, управляющие установками таблицы памяти, аппаратно накладывается ограничение на
использование только в режиме доступа hypervisor. Когда операционной системе, работающей в разделе, необходимо управлять таблицами памяти, она подаёт hypervisor служебный запрос (включает режим
hypervisor), и он выполняет необходимые действия. Записи таблицы памяти относятся только к определенным физическим областям, известным как области логической памяти. Эти области распределены
по отдельным блокам для каждого раздела и не могут быть использованы другим разделом ни при каких
обстоятельствах. Области логической адресации представляют собой физическую память, которая поддерживает виртуальное адресное пространство разделов, что позволяет представлять его как непрерывное
реальное адресное пространство, плюс некоторое количество логических областей памяти, назначаемых
в любом порядке из любой части физической памяти. Hypervisor строго следит за тем, чтобы разделы не
смогли получить совместный доступ к какой-либо части физической памяти.
Ресурсы устройств ввода-вывода
Теперь, когда мы убедились в том, что в архитектуре IBM Power Architecture™ ни один раздел не может
получить доступа к области памяти, используемой каким-либо другим разделом, рассмотрим следующие
компоненты – пространство ввода-вывода и прямой доступ к памяти (DMA). Как было отмечено ранее,
hypervisor обеспечивает доступ раздела только к тем ресурсам, которые были назначены специально для
него. Системы с архитектурой Power для доступа к устройствам PCI используют операции доступа к памяти, а устройства относятся к пространству ввода-вывода системы.
Стр. Как и с физической памятью, соответствие пространства ввода-вывода устройств PCI таблице памяти
обеспечивается посредством hypervisor. В среде логических разделов устройство PCI должно быть назначено определенному разделу до того, как hypervisor разрешит создание записей в таблице памяти. В этом
случае поддерживается принцип наименьшего уровня привилегий.
После того, как устройство ввода-вывода отнесено к адресному пространству раздела, с ним можно выполнять простейшие действия. Однако редкие устройства используют работу с памятью для передачи
значительных объёмов данных. Для записи данных в реальную память устройства используют прямую
адресацию памяти (DMA). DMA работает с механизмом изменения адресов, схожим с тем, который
применяется в таблицах адресации виртуальной памяти. Аппаратные средства подсистемы PCI переводят
адреса, созданные устройством, в адреса физической памяти. Это преобразование выполняется с помощью
таблицы записей, управляющих преобразованием (Translation Control Entry, TCE), расположенной в физической памяти. Причем таблица хранится в области памяти, которой владеет hypervisor, и недоступной
разделам. В отличие от таблиц страниц, таблицы TCE не связаны напрямую с какими-либо разделами, они
связаны с определёнными разъёмами ввода-вывода и косвенно – с разделами, владеющими устройством,
подключённым к этому разъёму. Для создания, изменения или удаления записей TCE раздел использует
функции hypervisor, при этом он проверяет, есть ли у раздела права на разъём PCI, связанный с TCE. Если
такие права есть, то адрес, указанный разделом для TCE, обновляется с учётом смещения физического
адреса. Таким образом, когда мост PCI преобразует адрес DMA в физический, он попадет в физическое
пространство памяти раздела. Это обеспечивает невозможность обмена данными между разделами.
Стр. Настройка LPAR
Основным компонентом системы обеспечения безопасности любой системы является настройка и управление этой настройкой. Как было сказано ранее, hypervisor реализует политику наименьшего уровня привилегий, обеспечивая исключительный доступ разделов только к ресурсам, явно указанным во время настройки. Разделы управляются консолью управления аппаратными средствами IBM Hardware Management
Console (HMC). Консоль HMC подключается к сервисному процессору сервера на базе POWER и управляет таблицами настройки, хранящимися в энергонезависимой памяти (NVRAM) сервисного процессора
(обозначается как SP или универсальный сервисный процессор, FSP). Эти таблицы используют hypervisor,
чтобы определить, к каким ресурсам следует применять политику безопасности. Доступ к этой области памяти NVRAM имеют только консоль управления оборудованием (HMC) и hypervisor. У HMC нет прямого
доступа к системной памяти или любому другому устройству системы. Доступ производится под строгим
контролем сервисного процессора и hypervisor.
AIX
Linux
I5OS
Свободные ресурсы
Виртуальные консоли
ответа и запроса состояния
Раздел 1
Раздел 2
Раздел 3
Загрузочное ПО /RTAS/Hypervisor
HMC
Энергонезависимое ОЗУ
Процессоры
Сервисный процессор
Области памяти
Разъёмы ввода-вывода
Таблица распределения
логических разделов
Рисунок 3
Доступ HMC
Консоль HMC реализована как набор программ, работающих на Linux®, сконфигурированной соответствующим образом – так, чтобы был обеспечен вид «устройства». Она поставляется и работает на
специальном оборудовании IBM. Доступ к HMC защищен комбинацией имени пользователя и пароля,
установленной администратором HMC. Администратор может открывать доступ другим пользователям
и наделять их правами на выполнение определённых операций. Для управления ограничениями консоль
HMC использует сочетание правил доступа Linux-пользователя и прикладных средств. На рисунке 3 показано, как HMC взаимодействует при настройке с сервисным процессором и hypervisor. По умолчанию
новому пользователю HMC присваивается роль Service Provider, которая ограничивает права на управление HMC (например, инженеры компаний-заказчиков IBM). В дополнение к этой роли по умолчанию
клиент может создавать собственные более ограниченные профили для контроля доступа пользователя.
В консоли HMC также реализован метод PE Access, обеспечивающий более широкий доступ к HMC. Администратор HMC-клиента использует имя пользователя hmcpe и соответствующий пароль. При работе
под этим именем можно расширить права доступа с помощью программы PE Challenge password, которая
после аутентификации пользователя позволяет получить неограниченный доступ к командной оболочке,
Стр. откуда, после ввода пароля к корневому каталогу (который также управляется клиентом) можно получить администраторский доступ. Доступ и аутентификация остальных пользователей HMC осуществляется с использованием предварительно полученных имени пользователя и пароля, управляемых клиентом.
Подразделением IBM Managed Security Services была произведена независимая оценка HMC. «В результате оценки никаких значительных уязвимостей обнаружено не было. В ходе анализа было проведено
множество испытаний по преодолению защиты тестируемой среды, как выполняемых вручную, так и
автоматических. Система обеспечения безопасности рассматриваемого приложения показала хорошую
степень управляемости и правильность конструкции». Тестирование выполнялось на системах с архитектурой Power и разделами LPAR в вычислительной среде, управляемой средствами IBM. Компания IBM
не может разглашать подробности этого ассесмента, поскольку по соглашению между IBM Managed
Security Services и организацией, заказавшей данное тестирование, они являются конфиденциальными.
Пользовательские интерфейсы HMC
Пользователь взаимодействует с HMC следующим образом:
• Авторизуясь в консоли, локально подключенной к HMC, со своими именем пользователя и паролем.
• Удалённо через клиент WebSM (реализован для AIX 5L™, Linux и Windows®). Соединение WebSM
можно настроить через SSL с сертификатами RC4 128 бит и RSA 1024 бита, а ключи могут генерироваться и импортироваться из выбранной клиентом PKI.
• Подключается к HMC через Web-браузер. Через интерфейс обычного браузера поддерживается
выполнение следующих операций:
– Доступ к странице, позволяющей загрузить клиент WebSM для Windows или Linux (в AIX 5L клиент WebSM встроен).
– Доступ к содержимому InfoCenter (документация) консоли HMC.
– Доступ к Web-интерфейсам, предоставляемым FSP при подключении его к HMC по частной сети.
Для доступа к этой службе необходимы аутентификация и авторизация в HMC. Соединение между браузером и HMC защищено посредством SSL web-сервера HMC.
• Выполняет операции с командной строкой по сети, используя защищенную оболочку Secure Shell
(SSH). Операции командной строки выполняются в защищенной среде, доступны только операции,
необходимые для управления или обслуживания основной системы, а также для настройки и управления HMC. Управление работой HMC осуществляется с помощью тщательно проработанного
набора приложений, выполняющихся на HMC, и являющихся единственным средством изменения
HMC или разделов. Эти приложения обеспечивают соблюдение ролей, назначенных пользователям
в HMC, гарантируя, что отдельный пользователь сможет выполнять только те действия, которые
ей разрешит администратор HMC при определении роли.
Используя HMC, администратор может настроить широкий набор правил сетевой фильтрации, ещё больше ограничивая доступ систем к сетевым сервисам HMC. По умолчанию для большинства механизмов сетевых интерфейсов устанавливается правило фильтрации DENY ALL (запрещать всё), и для разрешения
соединения требуются определённые действия администратора. Интерфейс администратора HMC предусматривает возможность полного отключения всех сетевых соединений. Информацию о настройке сетевой
фильтрации HMC можно найти по адресу
http://publib.boulder.ibm.com/infocenter/eserver/v1r3s/topic/iphai/lanfirewall.htm.
Консоль HMC записывает информацию о всех подключениях пользователей, а также о всех операциях,
изменяющих состояние системы, в журнал событий консоли Console Event Log. В дополнение к журналу
событий консоли HMC, существуют также средства Linux для ведения журнала, администраторы могут
получить доступ к этим журналам (только в режиме чтения) или настроить их автоматическую передачу
другой системе.
Стр. Сетевые интерфейсы HMC
Как было отмечено ранее, сетевые подключения HMC защищаются с помощью протокола SSL для
web‑браузеров, соединений WebSM и команд SSH для командной строки.
Физически HMC может подключаться к центральному электронному комплексу (Central Electronics
Complex, CEC – определение, используемое IBM для обозначения вычислительной среды основной системы) через FSP по каналу сети Ethernet. Более ранние системы на базе процессоров POWER4 поддерживали последовательное подключение HMC, эта возможность отсутствует в системах на базе POWER5.
В сетевом подключении HMC к сервисному процессору используется протокол TCP/IP. По умолчанию
протокол FSP использует сервер DHCP для получения IP-адреса; в частных сетях в качестве сервера
DHCP для служебной сети можно настроить HMC. Организация частной сети настоятельно рекомендуется для изоляции соединения FSP от остальных клиентов. Кроме того, сервисному процессору может быть
выделен собственный IP-адрес. Для всех HMC и сервисных процессоров поставляется и используется общий набор сертификатов X.509, с помощью которого также устанавливается безопасное соединение SSL
между устройствами. Сертификаты не меняются ни в одной точке пути передачи данных. При соединении SSL для защиты канала устанавливается симметричный ключ длиной 40 бит, поэтому рекомендуется
обеспечить управление физическим доступом к сети управления. Доступ к сервисному процессору производится с помощью имени пользователя SP и его пароля, о которых будет рассказано ниже. Для установки
соединения между HMC и FSP необходимо пройти два уровня идентификации (авторизации), сначала – авторизация администратора HMC, затем вход в FSP с одним из трёх профилей пользователя (HMC, admin
или general). Если данные о входе в FSP не переданы, для установки соединения пользователь должен
будет их ввести. Также FSP можно настроить на работу только с определёнными IP-дресами для более
жесткого ограничения точек доступа к системе. После ввода правильного имени пользователя и пароля
FSP они кэшируются на HMC, избавляя успешно вошедшего на HMC пользователя от дополнительного
шага аутентификации.
Администратор HMC имеет возможность ограничить видимость сетевых сервисов HMC для отдельных
физических сетевых интерфейсов, а также установить фильтр для систем, которым разрешён доступ к определённым сервисам. По умолчанию в консоли HMC устанавливается политика «запретить всё» (Deny All), а
также ограничивается открытие портов для администрирования определённого набора сервисов.
Стр. 10
Сервисный процессор
Возможности подключения сервисного процессора
Как было отмечено выше, сервисный процессор может подключаться к HMC либо последовательно
(возможность последовательного соединения в системах на базе процессоров POWER5 была отключена),
либо через интерфейс Ethernet. Для подключения сервисных процессоров через сеть организован защищённый канал SSL, использующий фиксированные сертификаты. IBM рекомендует размещать сеть сервисного процессора в отдельной физической сети центра данных, а также изменить пароли, назначенные
трём пользователям FSP по умолчанию, даже в том случае, если система не управляется HMC.
Доступ к сервисному процессору
После установки соединения с сервисным процессором все операции, выполняемые HMC, должны быть
аутентифицированы. Для выполнения операций с сервисным процессором предусматривается три учетные
записи. По умолчанию для них установлены следующие имена пользователей и пароли:
• HMC с пустым паролем (нулевой длины).
• general с паролем general.
• admin с паролем admin.
В SP входят два дополнительных имени пользователя «по умолчанию», используемых для обслуживания
системы. Один уровень доступа – это пользователь «Системный инженер заказчика» (Customer Engineer,
CE). Информация для удостоверения подлинности этого пользователя обновляется ежедневно на основе
изменений в системных данных. Инженер получает доступ к сервисному процессору через HMC после
авторизации, что обеспечивает два уровня контроля. У пользователя CE есть права на выполнение операций, необходимых для обслуживания системы персоналом IBM (или авторизованного партнера IBM).
Второй пользователь носит имя developer. Он используется в исключительно редких случаях, когда разработчики IBM должны выезжать на место для выявления и устранения чрезвычайных проблем (до сих пор
нам не приходилось им пользоваться). Информация авторизации для этого пользователя также меняется
ежедневно на основе системной информации, доступ к ней осуществляется после авторизации. Оба имени
пользователя блокируются на 5 минут в случае трёх неудачных попыток входа, IBM работает над расширением возможностей пользователя по управлению этими учётными записями.
Сервисный процессор управляется из расширенного системного меню (Advanced Systems Menu, ASM),
доступ к которому можно получить через прокси-сервер HMC с помощью https при использовании FSP
в частной сети. Изначально требуется аутентификация и авторизация в HMC, после чего необходима
аутентификация для работы с сервисным процессором. Брандмауэр сервисного процессора настроен на
разрешение доступа только по портам 443 (HTTPS), 30000 (командный интерфейс HMC) и 30001 (потоковый интерфейс для поддержки виртуального терминала Virtual TTY). Кроме того, для тех сред, где вы
хотите ещё сильнее ограничить служебный доступ, FSP продолжает поддерживать доступ к ASM с помощью последовательных устройств.
Проверка сервисного процессора
В силу небольших возможностей памяти для сервисного процессора, аудит ограничивается отслеживанием
последних успешного и неудавшегося входов каждого пользователя сервисного процессора (в том числе
пользователей CE и developer). Существуют команды HMC для извлечения этой информации из сервисного процессора, но механизмов, позволяющих атакующему очистить журнал, не существует. Сюда не входит
предотвращение перезаписи журнала путём повторяющихся попыток авторизации с неверными данными.
Стр. 11
Виртуализация устройств ввода-вывода
Системы на базе процессоров POWER5 впервые предоставили возможность виртуализации ввода-вывода
на серверной платформе. Организация совместного доступа к устройствам ввода-вывода на аппаратном
уровне реализуется с помощью механизма виртуализации, называемого сервером виртуального ввода-вывода (VIOS), работающего на базе логических разделов. Сервер VIOS выполняет только одну функцию
и не может выполнять приложения пользователя. Виртуализация ввода-вывода доступна только в случае
прямого разрешения при конфигурировании, также существуют настройки, исключающие возможность
самопроизвольного включения. Организация совместного доступа к аппаратным адаптерам осуществляется с помощью сервера виртуального ввода-вывода IBM (VIOS), представляющего собой логический
раздел, созданный системным администратором. Этому логическому разделу выделяются физические
устройства, что позволяет использовать существующие возможности управления доступом к аппаратному
обеспечению и hypervisor. VIOS организует виртуализацию устройств хранения, а также устанавливает
соединение типа «мост» между внутренним коммутатором Ethernet и внешней сетью. В виртуальном
SCSI-адаптере используется клиент-серверная модель, тогда как в виртуальных адаптерах Ethernet и SEA
Ethernet – одноранговая модель взаимодействия. Как в клиентских разделах, так и в разделе VIOS создаются виртуальные адаптеры, устанавливающие связь между разделами посредством hypervisor. Серверная
сторона виртуальных адаптеров обеспечивает маршрутизацию запросов и откликов, связанных с реальными физическими устройствами. Дополнительную информацию о возможностях виртуализации, в том числе о настройках, можно найти по адресу http://www.software.ibm.com/webapp/set2/sas/f/vios/documentation/
home.html.
Реализация VIOS
VIOS реализован таким образом, что информация о физическом оборудовании хранится в отдельном
от hypervisor разделе сервера. В результате этого устройства ввода-вывода по-прежнему не относятся
к hypervisor, что поддерживает его размер и сложность на низком уровне. Реализация VIOS зависит от
версии операционной системы AIX 5L и поставляется на установочном диске. Физические устройства
в VIOS используют существующие драйверы для AIX 5L, полагаясь на устойчивость и стабильность
платформы AIX 5L. Соединение между разделами клиента и сервера управления информацией производится с помощью надёжного инструмента передачи команд и ответных сообщений hypervisor. Передача
данных между клиентом и сервером осуществляется с помощью логической удалённой прямой адресации
памяти (LRDMA). Hypervisor продолжает выполнять свою функцию разделения ресурсов, отнесенных
к разделам, в случае с VIOS разделяя потоки данных между реальными устройствами и виртуальными
устройствами конкретных разделов. Для обеспечения общего доступа к ресурсам ввода-вывода разделов
со специфическими требованиями защиты данных и отделения этих ресурсов от других разделов, можно
использовать несколько экземпляров VIOS. Рассмотрим в качестве примера систему, в которой серверы
бухгалтерии и проектного отдела консолидированы в среде логических разделов. В такой среде может
работать два сервера ввода-вывода, один из которых будет обеспечивать общий доступ к ресурсам (а также организацию моста между сетями) для бухгалтерских систем, а второй – для проектных. В этом случае
администрирование VIOS можно поручить разным людям. У VIOS есть полный доступ ко всем ресурсам и
данным, содержащимся в нём, а через адаптер Ethernet общего пользования виден весь проходящий через
него трафик.
Системы на базе процессоров POWER5 поддерживают с помощью VIOS виртуальные устройства для
SCSI, адаптеры Ethernet общего пользования – Shared Ethernat Adapter (VIOS необходим), логические
коммутаторы VLAN и виртуальные адаптеры Ethernet, подключенные к коммутатору VLAN, а также
виртуальные консоли посредством виртуальных устройств, подключаемых последовательно через VIOS,
виртуальные терминалы HMC через сервисный процессор или устройства, подключенные к последовательному порту сервисного процессора системы.
Административные средства защиты VIOS
Сервер VIOS реализован как устройство логического раздела с чрезвычайно ограниченным набором
интерфейсов командной строки для определённых задач администрирования, которые нужно выполнять
в отдельной административной сети, как это рекомендовано для HMC и сервисного процессора. IBM рекомендует подключать IP-канал VIOS с помощью выделенного физического адаптера Ethernet, а не общего
адаптера. Если подключение отдельной сети невозможно, сеть IP сервера VIOS следует устанавливать в
сети VLAN, отличной от имеющей возможности мостового подключения Ethernet общего пользования.
Стр. 12
Сервер VIOS управляется с помощью набора утилит командной строки, доступ к которым осуществляется пользователем с именем padmin. Этот пользователь работает в командной оболочке с ограниченными
правами rksh, а утилиты реализуются как двоичные файлы или сценарии командного процессора. По
необходимости запуска операций или команд с привилегиями root, они выполняются в программе setuid,
которая называется ioscli. Она предназначена для выполнения только определённых команд. Эти программа и командная оболочка используются для ограничения возможностей администраторов сервера виртуального ввода-вывода.
Виртуальный SCSI
Виртуальный SCSI позволяет разделам получать доступ к блочным устройствам хранения, не принадлежащим к числу физических ресурсов этого раздела. Виртуальный SCSI построен на отношениях типа клиентсервер. Сервер виртуального ввода-вывода владеет ресурсами, а логические разделы, в качестве клиента,
обращаются к виртуальным адаптерам SCSI этого сервера. К разделу сервера физически подключаются
устройства ввода-вывода, а сервер предоставляет одно или несколько таких устройств другим разделам.
В древовидном списке устройств клиентских разделов имеется узел виртуального клиентского адаптера,
а доступом к одному или нескольким устройствам с блочным интерфейсом управляет серверный раздел.
На рис. 4 показан пример доступа раздела к виртуальным устройствам SCSI. Виртуальные LUN для клиентских разделов реализуются как логические тома AIX 5L внутри раздела VIOS или как непосредственно
связанные с физическими томами, подключенными к контроллеру.
Раздел 2
Раздел 1
Физический
адаптер Fibre
Channel
Физический
адаптер SCSI
Виртуальный
адаптер сервера
SCSI
Виртуальный
адаптер клиента
SCSI
Виртуальный
адаптер сервера
SCSI
Раздел 3
Виртуальный
адаптер клиента
SCSI
POWER Hypervisor
Физический диск
Физический диск
Виртуальный диск
(LPAR3)
Виртуальный диск
(LPAR2)
F. и F.
Виртуальный диск
(LPAR3)
Виртуальный диск
(LPAR3)
Рисунок 4
В среде виртуального SCSI сервер виртуального ввода-вывода действует как контейнер, предоставляющий
доступ к носителям. Вместо SCSI или кабеля Fiber соединение выполняет POWER Hypervisor. В работе
виртуального SCSI используются две системные функции, реализованные в POWER Hypervisor:
1. Функция организации очереди сообщений, обеспечивающая их прохождение между разделами
с меха­низмом прерывания для подтверждения получения сообщения.
2. Функция прямой адресации памяти (DMA) между разделами, которая предоставляет структуры управления безопасной передачей данных между областями памяти, выделенными логическим разделам.
Стр. 13
Сервер VIOS, драйвера устройств виртуального SCSI и POWER Hypervisor разработаны таким образом,
чтобы обеспечить доступ к данным только тому разделу, который ими владеет. Управляющая информация
проходит через сервер ввода-вывода, если разделу VIOS разрешено проводить операции DMA для перемещения данных в пространство памяти клиентского раздела и из него. Hypervisor строго контролирует,
к каким областям памяти может обращаться VIOS, а поскольку права ресурса на сервер VIOS в этом случае расширяются, он может работать только с теми областями памяти, разрешение на доступ к которым
явным образом дал hypervisor.
Защита виртуальных локальных сетей Ethernet
В контексте виртуального соединения Ethernet следует рассматривать те же требования по безопасности,
как и в случае физического соединения. Использование виртуального Ethernet повышает защиту LAN
и обеспечивает большую гибкость в установке сети по сравнению с обычными сетевыми устройствами.
Виртуальный Ethernet обеспечивает дополнительную защиту, позволяя администраторам блокировать
пакеты, которые идут в домен от различных доменов через один и тот же коммутатор, что предоставляет
более широкие возможности управления трафиком на определённых портах коммутатора Ethernet.
При использовании виртуального Ethernet связь между различными разделами организует POWER
Hypervisor. Hypervisor предоставляет реализацию коммутатора Ethernet. Соединение с внешней сетью
выполняется посредством функции общего адаптера Ethernet сервера виртуального ввода-вывода. Эта
часть сервера ввода-вывода действует как мост второго уровня для физических адаптеров. Реализация
виртуального Ethernet соответствует стандарту IEEE 802.1q который описывает систему идентификации виртуальной локальной сети. Метка VLAN ID размещается в каждом фрейме Ethernet. Коммутатор
Ethernet ограничивает фреймы, поступающие на порт, который уполномочен получать фреймы только
с определённым VLAN ID. Каждый порт коммутатора Ethernet может входить в несколько виртуальных
локальных сетей.
Виртуальный коммутатор IEEE сети VLAN
В hypervisor POWER5 реализован логический коммутатор виртуальной локальной сети стандарта
IEEE 802.1q, который позволяет операционной системе, работающей в разделе, связываться по стандартным сетевым протоколам. Этот коммутатор реализует все возможности физических коммутаторов, позволяя настроить несколько виртуальных сетей как механизм разделения связи между разделами.
Виртуальный адаптер Ethernet
В разделе может использоваться несколько виртуальных адаптеров Ethernet. Каждому адаптеру виртуальной локальной сети назначается уникальный MAC-адрес, созданный на основе серийного номера системы,
идентификатора логического раздела и идентификатора адаптера. Каждый виртуальный адаптер Ethernet
подключается к виртуальной локальной сети hypervisor, hypervisor вызывается для обработки каждого
пакета, выполняя функции диспетчера ресурсов и копируя данные напрямую между областями памяти
разделов. Сочетание коммутатора виртуальной локальной сети и виртуальных адаптеров Ethernet предоставляют эффективное средство взаимодействия между разделами. Для организации между разделами
виртуальной локальной сети не требуется настройки VIOS.
Стр. 14
Раздел 1
Раздел 2
Раздел 3
Раздел 3
Физический
адаптер
Ethernet
Функция моста
Виртуальный
адаптер
Ethernet
Виртуальный
адаптер
Ethernet
Виртуальный
адаптер
Ethernet
Виртуальный
адаптер
магистрали
Ethernet
Сеть Ethernet
Виртуальный
адаптер
магистрали
Ethernet
VLAN4
VLAN6
VLAN12
POWER Hypervisor
Рисунок 5
Адаптер Ethernet общего пользования
Для того чтобы позволить разделам, имеющим только виртуальные адаптеры Ethernet, связываться
с внешними системами, в VIOS реализована возможность использования физических адаптеров в качестве
адаптеров Ethernet общего пользования (SEA)3. Сочетание SEA и виртуальных адаптеров Ethernet, для
которых в VIOS включена опция trunk, позволяет создать мост второго уровня, и даёт коммутатору VLAN
возможность подключиться к физической сети без использования набора программно-аппаратных средств
для организации сети и маршрутизаторов. Примеры и инструкции по настройке SEA можно найти по
адресу http://www.ibm.com/servers/aix/whitepapers/aix_vn.pdf. Несмотря на то, что существует возможность
использования SEA как локальный интерфейс TCP/ IP для доступа к VIOS, последний представляет собой
часть домена ввода-вывода и поэтому IBM настоятельно рекомендует выполнять удалённое соединение
для управления VIOS через отдельный физический адаптер Ethernet и сеть. Это поможет обеспечить исключение VIOS из сети обмена данными и его принадлежность ограниченной сети управления. На рисунке 5 показано, как можно подключить виртуальные адаптеры Ethernet и адаптеры общего пользования,
чтобы создать виртуальную сеть с виртуальным коммутатором на базе hypervisor и обеспечить возможность связи с физической сетью.
3 Организация виртуальных сетей в AIX 5L, Винит Джейн, IBM Corporation. http:/ /www.ibm.com/ servers/ aix/whitepapers/ aix_vn.pdf
Стр. 15
Динамические логические разделы
Динамическое логическое разбиение (Dynamic LPAR) предоставляет возможность динамически добавлять или удалять ресурсы из раздела, а также передавать их другим разделам4. Более полное описание
динамического логического разбиения и инструкции по его использованию приведены на странице:
http://www.ibm.com/servers/eserver/pseries/hardware/whitepapers/dlpar.html.
В процессе динамического логического разбиения участвуют три компонента системы, в каждом из которых есть средства обеспечения безопасности. Этими компонентами являются:
• Микропрограммное обеспечение системы, в том числе hypervisor. Отвечает за добавление и удаление ресурсов из работающих разделов.
• Операционная система раздела. В поддерживаемых операционных системах существуют команды
и сервисы ядра, динамически получающие и освобождающие ресурсы.
• Консоль HMC, предоставляющая интерфейс управления перемещением ресурсов. Для этого ей необходимо сетевое соединение TCP/ IP с разделами. RMC обеспечивает возможность использования
UDP для связи с динамическими логическими разделами.
Использование динамического логического разбиения не является обязательным, при желании эту функцию следует включить в интерфейсе HMC. Динамическое логическое разбиение развивает модель выделения ресурсов от статического времени настройки до динамического. Таким образом, он представляет
возможность динамического изменения контроля доступа к ресурсам, управляемым hypervisor. Перераспределение ресурсов начинается с запроса HMC разделу на освобождение определённых мощностей. После
того, как ресурс освобождается, hypervisor берёт управление им на себя, ограничивая какой бы то ни было
доступ к этому ресурсу для всех разделов системы. После выполнения запроса на освобождение ресурса,
HMC подаёт запрос hypervisor привязать ресурс другому разделу. Теперь hypervisor будет использовать
обычный механизм контроля, обеспечивая использование этого ресурса только назначенным разделом.
Затем HMC уведомляет раздел-получатель о выделении нового ресурса, после чего ОС запрашивает необходимые ей данные об этом ресурсе у hypervisor. При отключении таких ресурсов, как физические адаптеры, производится их аппаратный сброс. Перераспределённая память вычищается hypervisor в соответствии с основными принципами обеспечения безопасности при повторном использовании объекта.
Стр. 16
Соединение с FSP
HMC
Сеть
Раздел A
Раздел B
Hypervisor/Диспетчер разделов
Рисунок 6
Связь динамических логических разделов
Связь между HMC и операционными системами динамических разделов основана на надёжной расширяемой технологии кластеризации IBM (RSCT), набора программных компонентов, которые, работая совместно, предоставляют комплексную среду кластеризации для AIX 5L и Linux. Описываемый здесь поток
RMC – это механизм, организующий динамическое логическое разбиение в AIX 5L и Linux. В системах
I5/OS динамическое логическое разбиение реализуется с помощью механизмов связи hypervisor и HMC
через сервисный процессор.
Ключевую роль в командах Dynamic LPAR играют три компонента RSCT: подсистема мониторинга и контроля ресурсов (RMC), диспетчеры ресурсов (RM) и службы обеспечения безопасности кластера (CtSec).
Подсистема RMC
В подсистему RMC входят клиенты RMC (например, команды), RMC-демон (rmcd), а также программный
интерфейс приложения (RMC API).
Ресурсы – это фундаментальное понятие архитектуры RMC; это физическая или логическая сущности,
обслуживающие другие компоненты системы. Набор ресурсов, обладающих похожими характеристиками
(в понятиях оказываемых услуг, параметров настройки и т.п.) называется классом ресурсов. Ресурсы и абстракные классы ресурсов определяются и управляются диспетчером ресурсов.
Диспетчер ресурсов это процесс, который устанавливает соответствие между абстракциями ресурсов
и классов ресурсов и действительными вызовами и командами для одного или нескольких определённых
типов ресурсов.
Диспетчер ресурсов работает как автономный демон, и содержит в себе определение всех поддерживаемых им классов ресурсов. В состав этих компонентов входит описание всех атрибутов, действий и других
характеристик класса ресурсов. Список управления доступом RMC (ACL) определяет права доступа, данные пользователю для управления и группировкой класса ресурсов.
Стр. 17
В RSCT реализован базовый набор RM (описание приводится в руководстве администратора RSCT), с другими программными продуктами поставляются специальные RM, в том числе RM для HMC и динамического логического разбиения (смотри раздел «Диспетчеры ресурсов, используемые для динамического
логического разбиения»).
Отношения между подсистемой RMC и диспетчерами ресурсов RM определяются следующим образом:
• В контексте кластеризации (в нашем случае HMC–к-LPAR) RMC-демон образуют распределённую подсистему, которая управляет передачей команд диспетчерам ресурсов, отправленных через
RMC API.
• RMC-демон управляют ответами, отправляемыми и получаемыми RM.
• RM посылает RMC-демону запрос на передачу команды RMC-демону удалённого ресурса.
• RMC-демон управляет аутентификацией и авторизацией RSCT, используя компонент службы обеспечения безопасности кластера (CtSec) RSCT.
Аутентификация и авторизация
Список управления доступом RMC (ACL) определяет права доступа, данные пользователю для управления и группировки класса ресурсов. Список ACL для доступа к HMC заполняется диспетчерами ресурсов,
работающими в разделе. При запуске он просматривает платформы, управляемые HMC, запрашивая
данные от hypervisor. В RSCT реализован базовый набор RM (описание приводится в руководстве администратора RSCT), с другими программными продуктами поставляются специальные RM, в том числе RM
для HMC и динамического логического разбиения.
CtSec предоставляет инфраструктуру обеспечения безопасности, которая позволяет компонентам RSCT
производить аутентификацию и авторизацию других сторон. Защита RMC выполняется на уровне приложений, в основном в самом протоколе RMC, посредством CtSec.
Аутентификация — это процесс, с помощью которого компоненты кластерного программного обеспечения, используя функции обеспечения безопасности, идентифицируют один из узлов, клиентов или подкомпонентов RSCT. Это определение производится таким образом, чтобы могли быть чётко определены
действительные компоненты кластерного программного обеспечения, а не фальсифицированные другими
сторонами, пытающимися получить несанкционированный доступ к системе.
В CtSec используется аутентификация на базе сертификатов. Эта аутентификация основывается на использовании доверенной третьей стороны, выполняющей аутентификацию отношений клиент-сервер.
По умолчанию в RSCT используется механизм аутентификации на базе хоста (Host-Based Authentication –
HBA) и доверенную третью сторону в виде операционной системы UNIX® или Linux.
Подробное описание CtSec и HBA приведено в главе 7, «Понимание и администрирование служб обеспечения безопасности кластера», руководства администратора RSCT.
Авторизация – это процесс, в ходе которого компоненты программного обеспечения кластеризации выделяют или отклоняют права на доступ к ресурсам на основе определённых критериев. В RSCT авторизация
выполняется компонентом RMC, который для управления доступом пользователей к классам ресурсов
и соответствующих им экземплярам использует файл списка контроля доступа (ACL).
Файл ACL списка управления доступом в RSCT используется для определения полномочий, которыми
обладает пользователь для доступа к классам ресурсов и соответствующим им экземплярам. Файл ACL
на узле RMC называется ctrmc.acls.
В файле ACL используется формат строфы, начинающейся с имени строфы, за которым следует 0 или
более строк. Строфа начинается со строки с именем, являющимся именем класса ресурса. В строфу также
входит идентификатор пользователя, тип объекта и права доступа.
Для любой команды, поданной для класса ресурса или его экземпляра, подсистема RMC изучает строки
строфы в порядке, указанном в файле ACL. Первая строка с идентификатором, соответствующим команде
пользователя и типу объекта, который соответствует указанному командой, является строкой, определяющей права доступа.
Стр. 18
Подробное описание процесса авторизации RMC, в том числе формата строф файла ACL RMC, приведено в главе 4, «Управление и мониторинг ресурсов с помощью RMC и диспетчеров ресурсов» Руководства
администратора RSCT и в главе 6, «Файлы конфигурации» Справочника RSCT.
Ключи RSCT
Аутентификация обмена данными RMC производится с помощью механизма аутентификации на базе
хоста HBA CtSec и использует как ассиметричные, так и симметричные ключи.
По умолчанию CtSec создаёт на каждый узел одну пару ключей RSA длиной 512 бит. Эти ключи используются в HBA. Ключи RSCT, или HBA, создаются в процессе установки или демоном ctcasd, входящим
в CtSec, при первом запуске после установки.
По умолчанию они хранятся в следующих местах:
• /var/ct/cfg/ct_has.qkf (секретный ключ) – Устанавливаются права доступа «только чтение» для владельца, пользователя root (400).
• /var/ct/cfg/ct_has.pkf (открытый ключ) – Устанавливаются права доступа «только чтение» для владельца, группы и других пользователей (444).
Ключи HBA не являются частью PKI, не являются цифровыми сертификатами X.509 и не связаны с централизованной службой управления ключами.
После того, как соединение RMC между HMC и LPAR аутентифицировано, сообщения протокола RMC
удостоверяются сессионным ключом. Сессионный ключ (симметричный ключ AES длиной 256 бит) уникален для каждого сеанса связи RMC.
RMC-демон (rmcd), работающий на HMC, создаёт сессионный ключ на соединение RMC и безопасно
передаёт его от HMC логическому разделу LPAR, шифруя сессионный ключ сначала секретным ключом
HMC (для обеспечения целостности), а потом – открытым ключом целевого раздела (для обеспечения
безопасности).
RMC-демон, работающий на логическом разделе, расшифровывает сессионный ключ, используя собственный секретный ключ и открытый ключ HMC. После расшифровки сообщения протокола RMC для этого
соединения, с целью обеспечения целостности данных, подписываются симметричным ключом.
Примечание: Сессионный ключ используется только на протяжении одного сеанса связи RMC. Сессионные ключи не подлежат повторному использованию или совместному использованию несколькими клиентскими соединениями.
Порт 657 RMC
RMC-демон прослушивает порт 657 протокола TCP, для связи клиент-сервер и порт 657 протокола UDP
для одноранговой связи демонов RMC. Порт RMC зарегистрирован Уполномоченной организацией по
распределению нумерации в сети Интернет (Internet Assigned Numbers Authority, IANA) и занесён в соответствующий каталог http://www.iana.org/assignments/port-numbers.
Диспетчеры ресурсов, используемые в динамических логических разделах
В разделах устанавливаются два диспетчера ресурсов (RM), упрощающих работу динамического логического раздела. Первый – это DynamicRM (DRM), который позволяет HMC добавлять и удалять разъёмы
ввода-вывода из раздела, обновлять системное программное обеспечение и выполнять определённые
действия по отключению раздела.5
5
http://publib.boulder.ibm.com/infocenter/eserver/v1r3s/index.jsp?topic=/iphaz/iphazinstallrpmsRH.htm.
Стр. 19
Второй – это ServiceRM, который создаёт обслуживаемые события на основании результатов анализа
утилиты Error Log Analysis Tool (diagela). После этого ServiceRM отправляет эти события на центральный
узел обслуживания HMC.6
На консоли HMC установлены соответствующие RM, которые обеспечивают связь HMC и динамических
логических разделов. Кроме того, HMC взаимодействует с hypervisor по сетевому интерфейсу FSP, обеспечивая правильное распределение ресурсов во время перевода ресурсов между разделами.
Отношения и соединения между подсистемой RMC и RM в среде динамических логических разделов
проил­люстрированы на рисунке 7.
HMC
RM
RM
Dynamic RM
Service RM
ен
ти
фи
че соед кац
и
ре
з п ине я за
ро ния щи
то
ко RM щен
но
лT C
го
CP
/IP
RMCD
Ау
т
Соединение с FSP
RMCD
RM
RM
Dynamic RM
Service RM
Раздел A
Раздел B
Hypervisor/диспетчер разделов
Рисунок 7
DRM представляет собой мост между пользователем HMC и программным обеспечением раздела. В общем случае он используется для выполнения команд ОС от имени пользователя HMC. Список вызываемых команд ограничен заранее определённым набором. Компонент DRM перед отправкой команд
в раздел просматривает строку команды и проверяет её допустимость. Таким образом, пользователь HMC
может вызывать команды, необходимые для освобождения ресурсов из-под контроля раздела, так чтобы
их можно было перенести. DRM работает в разделе с правами Root. Во всех этих операциях используются
механизмы RMC и функции защиты данных RSCT
Потоки команд Dynamic LPAR/RMC
На рис. 8 представлена базовая последовательность команд для Dynamic LPAR, реализованная с помощью
функций RSCT.
6
Ibid
Стр. 20
Описание потоков
HMC
(1) è (2) Пользователь HMC подаёт команду
динамическому логическому разделу. Диспетчер
доступа HMC определяет, имеет ли пользователь
права на выполнение команды. Если пользователь
авторизован, CIMOM, работающий с правами
root, использует интерфейс RMC API для вызова
действия. Действия запускаются CIMOM при подтверждении подлинности пользователя от имени
авторизованного пользователя HMC.
Графический
интерфейс
Диспетчер доступа CIMOM/HMC
(2) è (3) RMC-демон, работающий с правами root,
аутентифицирует и авторизует CIMOM от имени
LparCmdRM (межпроцессное соединение).
Rmcd
(3) è (4) Для соединения RMC-демона
и LparCmdRM, работающего с правами root,
исполь­зуется протокол RM.
LparCmdRM
Логический раздел
(4) è (5) LparCmdRM, становится клиентом
RMC-демон и подаёт ему запрос на перенаправление команды в целевой логический раздел. Теперь
клиент LparCmdRM аутентифицируется RMC-демоном (межпроцессное соединение).
rmcd
(5) è (6) RMC-демон на HMC связывается
с RMC-демоном в логическом разделе, используя
протокол RMC (UDP) и аутентификацию сообщений демонов (с целью обеспечения аутентичности
и целостности).
(6) è (7) Для соединения между RMC-демоном
и DRM, работающим с правами root, используется
протокол RM.
Интерфейс
командной
строки
DRM
<команда>
Рисунок 8
(8) DRM выполняет команду как пользователь root.
Стр. 21
Заключение
Защита системы – это компромисс между гибкостью и безопасностью. Основные функции систем IBM
POWER5 обеспечивают устойчивую платформу с жёстким управлением изоляцией разделов друг от друга
со стороны hypervisor. Опциональные компоненты систем POWER5 предоставляют дополнительные возможности и гибкость по виртуализации устройств и динамического перемещения ресурсов. Каждая из этих
функций действует на состояние защиты системы. Эти возможности были разработаны для надёжной
защиты друг от друга разделов и их данных, что позволяет системным администраторам устанавливать баланс между гибкостью и безопасностью. Так как IBM расширяет возможности систем на базе процессоров
POWER, каждое улучшение рассматривается с точки зрения его воздействия на защиту системы, обеспечивая тем самым предоставление администраторам функций безопасности, обеспечивающих достаточную
гибкость для соответствия требованиям среды.
Стр. 22
Используемая литература
Динамическое логическое разбиение в IBM eServer pSeries
http://www.ibm.com/servers/eserver/pseries/hardware/whitepapers/dlpar.html
Виртуальные локальные сети в AIX 5L, Винит Джейн (Vinit Jain), IBM Corporation
http://www.ibm.com/servers/aix/whitepapers/aix_vn.pdf
Безопасность логического разбиения в IBM eServer pSeries 690
http://www.ibm.com/servers/eserver/pseries/hardware/whitepapers/lpar_security.html
Расширенные технологии виртуализации систем POWER5, Журнал исследователей и разработчиков IBM
том 49 № 4/ 5 июль/сентябрь 2005. В.Дж. Армстронг и др.
Технология надёжной расширяемой кластеризации IBM, руководство администратора (десятое издание,
ноябрь 2005 года)
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.help.rsct.doc/rsct_books/rsct_admin_guide/
bl5adm09.html
Технология надёжной расширяемой кластеризации IBM, техническое руководство (одиннадцатое издание,
ноябрь 2005 года)
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.help.rsct.doc/rsct_books/rsct_aix_tech_ref/
bl5tra10.html
Технология надёжной расширяемой кластеризации IBM, справочник руководство по программированию
(первое издание, ноябрь 2005 года)
http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.help.rsct.doc/rsct_books/rsct_rmc_prog_
guide/bl5rmc00.html
System p5, eServer p5 и i5 и OpenPower, Разбиение на разделы AIX с помощью HMC (восьмое издание,
октябрь 2005 года)
http://publib.boulder.ibm.com/infocenter/eserver/v1r3s/ topic/iphbk/ iphbkaixkickoff.htm
Безопасность консоли управления оборудованием IBM pSeries, официальное издание
http://www.ibm.com/servers/eserver/pseries/hardware/whitepapers/hmc_security.pdf
Стр. 23
© IBM Восточная Европа/Азия 2006
123317, Москва,
Краснопресненская наб., 18
Тел.: +7 (495) 775-8800, +7 (495) 940-2000
Факс: +7 (495) 940-2070,
ibm.com/ru
Все права защищены.
Главная страница Web-сайта IBM находится по адресу ibm.com
Главная страница Web-сайта IBM System p находится по адресу:
ibm.com/systems/p.
Информация, изложенная в настоящем документе, относится к продуктам
и услугам, предлагаемым на территории США. Корпорация IBM может не
предлагать продукты, функциональные возможности или услуги, описанные
в настоящем документе, в других странах.
Информация может быть изменена в любое время без уведомления.
Информацию о продуктах и услугах, доступных в настоящее время в вашем
регионе, можно получить в местном представительстве IBM.
Все утверждения относительно направлений работы и перспективных планов корпорации IBM характеризуют исключительно цели и задачи компании
и могут быть изменены или отозваны без уведомления.
IBM, логотип IBM, eServer, AIX 5L, POWER, Power Architecture, POWER4,
POWER5, pSeries, System i, System p, System p5, System z являются товарными знаками или зарегистрированными товарными знаками International
Business Machines Corporation в США и (или) других странах. Полный перечень товарных знаков компании IBM можно найти на Web-сайте по адресу
http://www.ibm.com/legal/copytrade.shtml.
UNIX является зарегистрированным товарным знаком The Open Group
в США и/или других странах.
Linux является товарным знаком, принадлежащим Линусу Торвальдсу, в США
и/или других странах.
Windows является зарегистрированным товарным знаком
Microsoft Corporation.
Другие названия компаний, продукции и услуг могут являться товарными
знаками или знаками обслуживания соответствующих компаний.
Аппаратные продукты IBM производятся из новых компонентов или из новых
и бывших в употреблении компонентов. В некоторых случаях аппаратные
средства могут быть не новыми и бывшими в эксплуатации. Это обстоятельство не влияет на условия гарантии.
Копирование и загрузка через Интернет графических изображений, содержащихся в настоящем документе, без письменного разрешения IBM запрещается. Предлагаемое оборудование подпадает под действие нормативов
Федеральной комиссии связи США (FCC). Перед окончательной поставкой
оборудования заказчику будет обеспечено его соответствие требованиям
FCC.
Информация о продуктах, выпускаемых другими фирмами, получена от поставщиков этих продуктов или открытых источников. Вопросы относительно
подобных продуктов следует направлять их поставщикам.
При указании ёмкости устройств хранения 1 ТБ приравнивается к общей
сумме, представленной в ГБ и делённой на 1000; доступная ёмкость может
быть меньше.
Многие функции, описанные в настоящем документе, зависят от операционной системы и могут оказаться недоступными при работе под управлением
ОС Linux on POWER. Более подробная информация по этому вопросу:
http://www.ibm.com/systems/p/software/whitepapers/linux_overview.html.
Стр. 24