Appliance Operating System

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

В качестве ответа на это Red Hat предлагает Appliance Operating System (AOS), основанную на Red Hat Enterprise Linux. В рамках этого проекта Red Hat предлагает разработчикам программного обеспечения Virtual Appliance Development Kit (vADK) – набор средств для создания образов системы, пригодных для развертывания на разнообразных платформах. На данный момент проект находится в состоянии закрытой беты, релиз намечен на первую половину 2008 года.

Использование AOS позволит разработчикам упростить внедрение своих приложений – необходимые настройки уже сделаны, конфигурация протестирована, приложение развернуто и запаковано в образ, который устанавливается простым копированием.

В итоге разработчики получают ряд преимуществ. Упрощается процесс поддержки, ведь заведомо известно, как развернуто приложение. Клиенты остаются более довольными, так как они получают желаемое решение вида «нужно только включить одной кнопкой». А так как AOS позволяет развертывание на разных платформах, устраняются проблемы, связанные с необходимостью портировать приложения.

Образы, создаваемые vADK, могут быть развернуты на следующих платформах:

• Red Hat Enterprise Linux 5

• VMware ESX 3

• Amazon EC2

• Microsoft Viridian (после официального релиза)

• Sun xVM

Amazon EC2. Все новое – это хорошо забытое старое.

Когда-то всем пользователям ЭВМ было хорошо знакомо понятие «машинное время». Именно его они получали в свое распоряжение – некоторое время работы на некоторой машине. Потом, когда компьютеры стали персональными, «машинное время» забылось, речь шла уже о получении нужного количества компьютеров, а не часов. И вот «машинное время» возвращается, но уже в новом качестве.

Amazon запустил новый веб-сервис – Elastic Computing Cloud или сокращенно EC2. Подробный анонс можно найти по адресу http://www.amazon.com/ec2.

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

Ориентировочная стоимость сервиса – 10 центов за один час аренды сервера вида 1.7 Gb RAM, 1.7 GHz Xeon, 160 Gb места на диске. При этом клиент может выбирать конфигурацию необходимого ему оборудования и оплачивает его почасовую аренду, трафик оплачивается отдельно.

В примерном пересчете получается, что если арендованный сервер работает 24х7, то он обходится в $72/месяц плюс стоимость трафика. Это сопоставимо со стоимостью выделенного сервера у крупных хостинговых компаний. И это значительно больше, чем стоимость VPS. Поэтому у многих возник вопрос, так что же нового предлагает Amazon?

Ответ прост – гибкость. Предложение Amazon рассчитано в первую очередь отнюдь не на размещение небольших сайтов. Amazon EC2 позволяет клиентам развернуть свой личный датацентр любого размера не вставая со стула и за считанные минуты. Более того, Amazon предоставляет API для работы с EC2. То есть, приложение может автоматически выделять для себя необходимую вычислительную мощность.

Еще один простой пример. Допустим, перед компанией время от времени встает необходимость решать задачи, требующие 100 часов машинного времени. Неважно, что это за задачи – численное моделирование, сложный анализ данных, рендеринг или что-либо еще. Компания может приобрести свой кластер из, скажем, 20 машин, что позволит решать такие задачи за 1 рабочий день. Обойдется такой кластер примерно в $25000, кроме того, его придется где-то разместить и в дальнейшем обслуживать. Или же можно воспользоваться Amazon EC2, не вставая со своего рабочего места выделить 100 серверов, решить задачу за час и заплатить за все это $10.

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

«Электронная Россия» и открытые форматы

Мы уже неоднократно писали о важности открытых форматов как таковых и о разработанном консорциумом OASIS формате Open Document Format (ODF) в частности.

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

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

Однако, при том, что необходимость использования открытых форматов документов очевидна, конкретных шагов в этом направлении в России до последнего времени сделано не было. Но ситуация начинает меняться. В ноябре были подведены итоги конкурса «Электронной России» по теме «Исследование механизмов, направленных на создание в государственных учреждениях Российской Федерации условий для использования международного стандарта электронного документа ISO/IEC 26300:2006». (Напомним, что стандарт ISO/IEC 26300:2006 – это формат ODF.)

Конкурс выиграл альянс, в который вошли ЭОС, «Инфра-Ресурс», «ПроСофт-М» и ассоциация ЕВРААС. Именно они теперь займутся исследованием вопросов перехода государственных учреждений на ODF. Кроме того, что очень важно, будет разработана русифицированная версия стандарта ISO/IEC 26300:2006, которую в дальнейшем предполагается принять как национальный стандарт.

На сегодняшний день уже многие государственный структуры разных стран мира объявили о начале работ по переходу на ODF. Теперь к ним присоединилась и Россия.

Централизованное управление аутентификацией и информацией о пользователях.

Экскурс в историю

С тех пор, как компьютерные сети получили широкое распространение, использовать файлы, такие как /etc/hosts, /etc/networks, /etc/group, /etc/gpasswd, /etc/passwd, /etc/shadow и им подобные для хранения соответственно информации о хостах, сетях, группах, паролях групп, пользовательской информации, паролей пользователей и прочей подобной информации, которая должна быть целостной на всех узлах сети стало неэффективно. Неэффективно в первую очередь из-за проблем синхронизации. Встал ребром вопрос о разработке технологий централицозанного управления и хранения информации из вышеуказаных файлов. И если для читабельных имен узлов и сетей выбор пал (сейчас уже практически эксклюзивно) на DNS (отщепенцы с NIS и им подобные не рассматриваются), то с пользовательской информацией и механизмами аутентификации не все так просто как кажется. В данной статье мы постараемся описать различные методы вместе с их преимуществами и недостатками.

Итак, поехали.

Для начала важно понимать принципиальное различие трех следующих ключевых терминов:

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


• Аутентификация - процесс удостоверения подлинности пользователя. Иначе говоря успешная аутентификация говорит только о том, что "Ты дейстительно тот, за кого себя выдаешь". Этот процесс может осуществляться огромным количеством способов.


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

Итак, немного прояснив ситуацию с терминологией определимся, о чем мы сегодня поговорим. Мы постараемся осветить первые 2 пункта. Третий пункт стоит особняком и не является темой сегодняшнего разговора. Начнем с предметного "разноса" устаревшим технологиям. Заметим, что мы рассматриваем все технологии в первую очередь как средство выполнения описанных выше задач, побочные их возможности при этом рассматривать не будем.

NIS

NIS является классическим RPC сервисом, придуманным компание SUN Microsystems
довольно давно. Суть - предоставление сервиса "хранения" пользовательской
информации на центральном сервере домена. Опционально там же хранятся хэши
пользовательских паролей. Как сервис аутентификации NIS крайне несовременен, в
силу того, что в герерогенной среде часто приходится "возвращаться" к
DES-алгоритму шифрования паролей, который был признан небезопасным. Как
хранилище пользовательской информации все еще ограниченно пригоден, а иногда
это вынужденный вариант, так как многие старые Solaris (в частности) системы
не умеют получать пользовательскую информацию с LDAP-сервера.

Принципиально NIS не предоставляет никаких механизмов аутентификации. Для
получения пользовательской информации достаточно знать IP-адрес сервера домена
и название домена. Обычно это легко выясняется с помощью nmap, rpcinfo или
паяльника ( :) ). После этого "неправильная" машина может получить дамп
локальной информации (о боже, в некоторых конфигурациях с паролями шифроваными
DES) для оффлайн-исследования. Резюмируем.

Плюсы:

• Просто и быстро развертывается.


• Простая система миграции информации из файлов /etc/passwd и /etc/shadow

Минусы:

• По умолчанию размещается на динамических RPC портах (плохо файлволлится)


• Не поддерживает шифрование


• Не предоставляет механизмов аутентичикации клиентских машин


• Совместимая со старыми системами версия позволяет использовать только слабые алгоритмы шифрования паролей


• Позволяет любому человеку, знающему ip сервера и имя домена быстро получить копию базы для оффлайн-расшифровки

Применимость:

Аутентификация: rрайне слабое средство. Применять рекомендуется только после вывода о неприменимости других систем.

Пользовательская информация: Ограниченное применение в физически изолированных сетях, обычно вызванное необходимостью совместимости со старыми Solaris

Некоторые недостатки первоначальной NIS были исправлены в NISPLUS (http://en.wikipedia.org/wiki/Nisplus). Тем не менее, бытует мнение, что NISPLUS - это ugly hack и его использовать (особенно в новых системах) не рекомендуется.

DBMS

Многие люди почему-то любят хранить информацию о пользователях в реляционных базах данных. Это решение не имеет на наш вгляд плюсов и является неверным с точки зрения безопасности и скорости. Причина кроется в том, что задачи получения пользовательской информации сводятся обычно к чтению одной-единственной (ну нескольких) записей. Задача аутентификации требует чтения одной записи. При этом, используя реляционные СУБД, мы вынуждены "оборачивать" простой запрос на чтение в сложную и громоздкую обертку, иногда даже транзакционную. Подобные решения особенно плохо себя показывают при лавинообразном росте числа клиентов. Кроме того доступ к СУБД должен быть открыт по сети для любого хоста, желающего получить доступ к пользовательской информации и информации для аутентификации. Отметим также, что описываемая нами информация редко изменяется. То есть наиболее частой операцией являет операция одиночного чтения, для которой транзакционная нагрузка просто излишня

Помимо прочего большинство широко используемых СУБД не позволяют достаточно гранулированно управлять правами (например невозможно запретить пользователю СУБД читать колонку с чужими паролями). Иначе говоря, как и в случае с NIS, злоумышленник часто может просто получить копию базы данных пользователей (а то и паролей).

Плюсы:

• На первый взгляд дотаточно просто

Минусы:

• Нестандартное решение, требующее внешних средств для работы


• Плохая гранулированность аутентификации пользователей в СУБД


• Низкая производительность и плохая масштабируемость

Применимость:

Аутентификация: крайне слабое средство. Don't use that.

Пользовательская информация: ограниченно применимо, если вы сможете ввиду вышеуказанных аргументов ответить на вопрос "А зачем?"

LDAP

История развития LDAP терниста и неоднозначна. В 1988 году коммитеты по стандартам ITU-T (консорциум телекоммуникационных компаний) и ISO сформулировали стандарт для хранения древовидной информации, известный как X.500 или DAP. Вспомните модель OSI, которой все учат, но мало где используют. Стандарт получился "мертворожденным" и получил крайне ограниченное распространение. Из минусов исходного стандарта можно отметить переусложенность, наличие непонятной в мире Internet иерархии, основанной на географических терминах.

Тем не менее ряд остроймных людей отпрофилировал систему, реализующую DAP и, переложив "понятия" телекоммуникационных компаний на интернет, а также разбавив изначальную спецификацию здравым смыслом, разработали протокол LDAP (Lightweight Directory Access Protocol). Кстати говоря "облегченный" этот протокол как раз в сравнении с оригинальным DAP.

В настоящее время существует несколько инкарнаций LDAP, такие как OpenLDAP, Red Hat Directory Server ( в девичестве Netscape Directory Server ) а также другие (например M$ Active Directory). В настоящее время LDAP является сдандартом де-факто для хранения пользовательской информации. При этом, правда, некоторые ошибочно воспринимают LDAP как "святой грааль", коим он не является. LDAP - не более чем концепт специальной нетранзакционной древовидной БД для хранения различных данных, грамотное использование которого возможно только при правильной "проекции" этого концепта на конкретную ситуацию.

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

Плюсы:

• Стандарт


• Высокая производительнось операций чтения (особенно одиночных)


• Достаточно хорошая масштабируемость, низкие "накладные расходы"


• Достаточно четкий и гранулированный механизм разграничения доступа к данным, хранящимся в директории


• Поддержка SSL/TLS - шифрования


• Наличие механизмов аутентификации клиентских машин при получении пользовательской информации

Минусы:

• Сложность в освоении в силу "непохожести" на другие технологии

Применимость:

Аутентификация: применимо. Отсутсвует фукнциональность Single Sign on. (как впрочем и в предыдущих решениях)

Пользовательская информация: о, да!

Принципиальные различия между OpenLDAP и, например, Red Hat Directory Server лежат в границах применимости и доп. возможностях. Например OpenLDAP вполне неплохо подходит для хранения небольшой директории (до 5000 записей). Начиная примерно с этого объема RHDS масштабируется заметно лучше. Помимо этого RHDS имеет следующие основные и принципиальные преимущества:

• Multi-master репликация. До четырех мастеров могут обслуживать одно дерево.


• Поддержка двунаправленной репликации с Active Directory.

Kerberos.

Kerberos был создан в стенах небезызвестного MIT и является на сегодняшний день стандартом технологии аутентификации. Хотя Kerberos и использует шифрование симметричными ключами, ключи никогда не передаются по сети. При этом достаточно сложная система аутентификации позволяет строить домены аутентификации "Authentication Realm", внутри которых действует Single Sign On, тоесть пользователю достаточно аутентифицироваться на KDC, чтобы аутентифицироваться в дальнейшем на любом из сервисов домена без необходимости ввода пароля.
Именно Kerberos для аутентификации и LDAP для хранения пользовательской информации в настоящее время считаются "референсным" решением. Подобная схема (хоть и совершенно несоответствующая общепринятым тандартам) используется в так называемых Windows-доменах.

Kerberos - исключительно механизм аутентификации. Основные действующие лица:

• KDC, он же Центр Дистрибьюции Билетиков (Ticket), он же Key Distribution Cetner. Знает секретные ключи всех остальных участников, поэтому его надо ревностно охранять.


• Client Principal, он же клиент - биологический объект, желающий аутентифицироваться


• Service Principal, он же сервис - небиологический объект (сервис), который поддерживает аутентификацию Kerberos.


• Client-Service Ticket - кратковременное "разрешение на временную аутентификацию"


• TGT, он же Ticket Granting Ticket - долговременное разрешение получать Ticket'ы

Механизм аутентификации следующий:

Сценарий 1. Клинет аутентифицируется на KDC.

1. Клиент изъявляет желание аутентифицироваться и сообщает об этом серверу. Сервер в ответ отправляет 2 ообщения:
   
   
   
   1. Ключ сессии зашифрованный секретным ключем пользователя
      
   2. TGT, зашифрованный секретным ключем KDC
      
   
   
2. Получив оба сообщения и расшифровав первое клиент обладает достаточной информацией для аутентификации на KDC
   
3. TGT (второе сообщение) не может быть расшифрован клиентом. Он кэшируется и доступен для использования всему поддереву дочерних процессов,
   

Сценарий 2. Клиент хочет получить доступ к сервису.

1. Клиент отправляет запрос на сервер аутентификации, содержащий следующие данные:
   
   
   
   1. Составное сообщение, состоящее из ID сервиса и зашифрованного секретным ключем KDC TGT из предыдущего сценария.
      
   2. Аутентификатор, сотоящий из ID клиента метки времени (timestamp), зашифрованный ключем сессии.
      
   
   
2. Расшифровав эти сообщения, сервер может принять решение о "разрешении"доступа клиента к сервису. Это есть элемент авторизации. В случае положительного решения KDC отвечает клиенту также двумя сообщениями:
   
   
   
   1. Client-Service Ticket, зашифрованный секретным ключем Service Principal'а. Client-Service Ticket включает ключ сессии клиент-сервис, а также прочую информацию. Клиент не может его расшифровать.
      
   2. Ключ сессии клиент-сервис, зашифрованный ключем сессии клиент-KDC.
      
   
   
3. Довольный клиент имеет теперь достаточно информации для аутентификации "на сервисе".
   

Сценарий 3. Аутентификация клиента с сервисом.

1. Клиент пересылает сервису следующие сообщения:
   
   
   
   1. Client-Service Ticket, зашифрованный секретным ключем Service Principal'а из предыдущего сценария.
      
   2. Аутентификатор, содержащий ID клиента и метку времени, зашифрованные ключем сессии клиент-сервис.
      
   
   
2. Сервис расшифровывает первое сообщение. Из него он получает ключ сесии клиент-сервис. Расшифровывает полученным ключем второе сообщение и аутентифицирует клиента, если метка времени находится в доверительном интервале. Отправляет клиенту подтверждение, содержащее
   
   
   
   1. Метку времени, зашифрованную ключем сессии клиент-сервис.
      
   
   
3. Клиент расшифровывает сообщение и проверяет корректность метки времени. В случае если метка обновлена корректно аутентификация прошла успешно, клиент и сервис начинают "общаться".
   

Преимущества:

• Секретные ключи не пересылаются по сети
  
• Single Sign On.
  
• Простой механизм борьбы с перехваченными ключами сессии: они истекают раньше, чем их удается расшифовать.
  

Недостатки

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

Применимость:

Аутентификация: о, да! Помимо прочего архитектурно является механизмом авторизации.

Пользовательская информация: Нет в силу другого предназначения.

Вот и все на сегодня. Мы определили, что оптимальный на сегодняшний день решением для аутентификации является Kerberos, а средством для хранения пользовательской информации служит LDAP. В случаях, когда закон жизни не диктует обратное, именно такие решения стоит реализовывать. А какнибудь попозже мы расскажем как.

Oracle и BEA. Несостоявшаяся сделка.

Хроника событий:

1. 12 октября 2007

Oracle заявляет о том, что 9 октября 2007 сделал предложение совету директоров BEA, в котором предлагает приобрести компанию по цене $17.00 за акцию при рыночной цене акций $13.62. По заявлениям руководства Oracle, предлагаемое поглощение будет исключительно дружественным. Oracle обязуется обеспечить поддержку существующих на сегодняшний день внедрений BEA, точно так как же, как ранее в случае с PeopleSoft и Siebel.

2. 25 октября 2007

Совет директоров BEA заявляет, что предложение Oracle явно занижено. BEA после консультаций с независимыми аналитиками пришла к мнению, что объективная стоимость компании составляет $21.00 за акцию. Письмо, излагающее позицию BEA, направлено в Oracle.

3. 25 октября 2007

Буквально через несколько часов Oracle заявляет, что $21.00 за акцию неприемлемо высокая цена и для Oracle, и для любых других претендентов. Поэтому компания остается при своем первоначальном мнении и предлагает $17.00 за акцию. Кроме того, Oracle устанавливает срок действия своего предложения до 28 октября.

4. 28 октября 2007

Oracle заявляет, что срок действия его предложения истек. По заявлению компании, «если держатели акций BEA недовольны решением совета директоров, то это их задача – предпринять соответственные действия, никак не задача Oracle».

Итого, сделка не состоялась.

Oracle сделал очередную попытку приобрести разработчика middleware, но сделка опять не удалась. Напомним, что до этого Oracle пытался приобрести JBoss, но JBoss предпочел объединиться с Red Hat вместо того, чтобы быть купленным Oracle.

Собственно говоря, ничего удивительного в том, что разработчики middleware не торопятся продать свои компании, нет. Направление SOA сейчас популярно, и нет никакого резона продавать свой бизнес в этой области. Гораздо более интересны мотивы Oracle. Ведь у компании есть свое направление middleware, в котором активно ведутся разработки. С чем связаны такие активные попытки приобрести его аналоги? Это способ устранить конкурентов или компания не удовлетворена темпом и качеством своих разработок и хочет сменить платформу?

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