Открытое письмо Мэтью Шулика

Неофициальный перевод. Не является дословным переводом оригинала. Оригинал доступен по адресу:
http://www.press.redhat.com/2007/12/20/a-message-from-matthew/

«Я ценю только безумных людей. Людей, что живут ярко, говорят ярко и не боятся сгореть. Людей, что хотят всего и сразу. Людей, что никогда не зевают от скуки и не говорят банальностей, а вместо этого — горят, горят, горят как сказочные римские свечи, разбрасывая среди звезд огни, вспышки и звук разрывов — и в воздухе висит многоголосое «урааааа!!!».» - Джек Керуак (Jack Kerouac).

После почти десяти лет в роли главы Red Hat я решил оставить свои посты CEO и президента по личным причинам, которые я уже объяснял. Я продолжу служить этой великой компании в качестве председателя совета директоров. Red Hat будет в руках великолепной команды менеджеров мирового уровня, возглавляемой Джимом Вайтхёрстом как президентом и CEO.

Когда я только начинал работать в Red Hat, мы сидели в маленьком офисе в Дюрхеме, причем я сидел напротив автомата, продавшего газировку. Люди подходили и тыкали в кнопки, выбирая Mountain Dew или колу. Моей главной задачей на тот момент было привлечь крупных инвесторов в open source. И во время телефонного разговора, посреди моих рассуждений и аргументов, представители Dell, IBM, HP и других корпораций подобного масштаба слышали постоянный стук падающих банок газировки. Они спрашивали, в чем дело, и не дерется ли кто-то неподалеку. В итоге через некоторое время я стал говорить предполагаемым инвесторам, что ДА, действительно идет драка. Причем эти драки идут часто. Именно так в Red Hat разбираются с проблемами, такими как старые баги и неработающие новые фичи. Да, Red Hat — жесткое компания. Dell, HP и IBM стали инвесторами, потому что им понравился позитивно-агрессивный дух Red Hat.

Больше девяти лет — долгий срок. Антимонопольные иски к Microsoft. Гарри Поттер. Клинтон, Буш, Буш. «Дот-комы». 2000 год. 11 сентября. Вступление Китая в ВТО. Ирак. Цунами. ENRON. Sarbanes Oxley. BRIC (Brasil, Russia, India, China). Дарфур. Италия и кубки мира. Boston Red Sox. iPod. Взрывы в Испании. Глобальное потепление. Обама и Хиллари.

Руководя людьми, ты ищешь некое единое начало, чтобы объединить и вдохновить многонациональное разнородное сообщество по имени Red Hat. Ты пытаешься создать культуру открытости и уважения к разнообразию. Ты ищешь тех, кто верит, что свободный и неограниченный доступ к информации — необходимое условия развития.

Много лет я всматриваюсь в ветровое стекло, пытаясь разглядеть будущее. Учась и приспосабливаясь к возникающему сообществу Red Hat, его культуре и месту на рынке. Прошлые и нынешние сторонники Red Hat, члены сообщества open source, наши заказчики и партнеры — все они добавили свои штрихи и краски к тому образу, который носит имя Red Hat. Я чувствую гордость, когда представители различных компаний говорят мне, что люди Red Hat «особенные». Не такие, как те, кто ставит целью захватить индустрию. Своей работой сообщество open source и Red Hat в частности создают новую модель взаимоотношений разработчика и заказчика. Совместная работа. Открытость и ориентированность на задачи заказчика. Наши заказчики и рынок в целом это понимают, что подтверждает наш потенциал. То, что в 1998 году считалось несерьезным, теперь изменилось. Сегодня государственные и индустриальные компании разделяют ценности и подходы open source, доказательством этому — их поддержка OLPC и инициатив open source сообщества в области образования в Индии, Южной Америке и Африке (и в России! - прим. переводчика).

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

/MJS

Неофициальный перевод. Не является дословным переводом оригинала. Оригинал доступен по адресу:
http://www.press.redhat.com/2007/12/20/a-message-from-matthew/

Новым CEO Red Hat стал Джим Вайтхёрст

20 декабря 2007 года компания Red Hat объявила, что совет директоров принял кандидатуру Джима Вайтхёрста (Jim Whitehurst) в качестве нового президента и CEO компании, а также нового члена совета директоров. Решение вступает в силу с 1 января 2008 года. Вайтхёрст сменит на посту президента и CEO Мэтью Шулика (Matthew J. Szulik). Шулик продолжит работу в компании в качестве председателя совета директоров.

Со стороны совета директоров Red Hat Вильям Кайзер (William S. Kaiser) заявил: «Уже около десяти лет благодаря проницательности и лидерским качествам Мэтью Шулика бизнес-модель, основанная на open source, показывает свою эффективность и инновационность. Шулик превратил Red Hat из маленькой частной компании в бренд мирового масштаба, а подход компании к развитию технологий и предоставлению сервисов клиентам во многом изменил индустрию программного обеспечения.»

Также Кайзер добавил: «Совет директоров рад приветствовать Джима Вайтхёрста в качестве нового CEO. Мы уверены, что он привнесет в компанию сочетание стратегического видения и эффективного управления, необходимое, чтобы продолжать рост компании и при этом и в дальнейшем предоставлять заказчикам самый высокий уровень сервиса в индустрии. Его опыт работы в больших международных компаниях будет крайне ценен на этапе, когда Red Hat приближается к выручке в миллиард долларов и продолжает расти.»

«После активного поиска Red Hat выбрал талантливого директора, который успешно возглавлял международную технически-ориентированную организацию во время его работы в Delta», - добавил Шулик, - «Джим — человек с активный позицией, и ему очень близка культура, существующая в Red Hat».

«Red Hat изменил отношение людей к технологии. Это выдающаяся компания, и я рад присоединиться к ней», - сказал Вайтхёрст, - «У нас великолепные перспективы — высококлассные технологии, великолепные люди, четкое управление и бренд мирового масштаба. Red Hat — ведущий поставщик программного обеспечения, больше всех оправдывающий ожидания заказчиков. Я ряд, что у меня есть возможность вести эту компанию в будущее».

Вайтхёрст занимал различные должности в Delta Airlines с 2002 года, большей частью работал в качестве COO, отвечая за управление, продажи, предоставление сервисов клиентам, координацию партнеров и продаж, маркетинг и стратегию компании.

До Delta Вайтхёрст занимал должность вице-президента и директора в Boston Consulting Group (BCG) и различные руководящие посты в офисах компании в Чикаго, Гонконге, Шанхае и Атланте.

Оригинальный пресс-релиз на английском доступен по адресу: http://investors.redhat.com/phoenix.zhtml?c=67156&p=irol-newsArticle&ID=1089406

Ноутбуки с Linux. Экзотика или тенденция?

Ни для кого не секрет, что рынок ноутбуков сейчас растет гораздо быстрее рынка десктопов. Прогноз, что в 2007 году ноутбуки принесут производителям оборудования больше прибыли, чем стационарные десктопы (http://www.eweek.com/article2/0,1895,2074541,00.asp), похоже, сбывается. А для некоторых компаний, например, для Hewlett-Packard (http://www.eweek.com/article2/0,1895,2219669,00.asp), это уже очевидный факт.

При этом рост обеспечивается большей частью за счет бюджетных моделей (менее $1000). Это выглядит вполне логичным, так как число людей, готовых покупать дорогие престижные модели, изменяется мало. В то же время все более распространенным становится wi-fi и все большую популярность обретает идея «мобильного офиса». В итоге, когда цена ноутбука падает ниже психологического барьера в $1000, все большее количество покупателей, в том числе корпоративных, переходят со стационарных десктопов на ноутбуки.

Но на этом этапе возникает одна проблема. Имя этой проблеме – Vista. Ну не приспособлены ноутбуки с 1 Gb оперативной памяти и встроенным видео для полноценной работы с Vista! Кроме того, стоимость Vista для этого ноутбуков этого ценового диапазона составляет заметную часть итоговой цены.

В итоге у компаний-сборщиков остается три пути. Первый путь – наращивать мощность ноутбуков и тем самым уйти из притягательного ценового диапазона. Второй путь – использовать версию Vista Home Basic, которую ненавидят даже самые ярые сторонники Vista. Третий путь – отказаться от Vista.

Первый путь рассматривать просто неинтересно. Те компании, которые его выбирают, автоматически отказываются от борьбы за большую нишу рынка. Второй путь выглядит вполне реальным и некоторые компании поставляют ноутбуки с Vista Home Basic. Но здесь возникает одно «но» – с точки зрения пользователя Vista Home Basic ничем не лучше XP. Можно долго рассуждать о ее технических нововведениях, но попробуйте объяснить их обычному пользователю. Для него она останется системой с множеством минусов относительно XP (непривычность, отсутствие многих нужных программ, медленность работы) и при этом без единого плюса. Наверняка Вы и сами неоднократно слышали подобные мнения.

В итоге, как показывает практика, ноутбуков с Vista Home Basic в продаже все меньше. И все большее количество сборщиков выбирают третий путь – отказ от Vista. Многие из них сейчас продолжают предлагать XP как вариант предустановленной системы. Но этот путь ведет в никуда – срок жизни XP на исходе, тем более в ситуации, когда Microsoft активно продвигает Vista.

Поэтому не удивительно, что многие компании смотрят на Linux как на наиболее перспективную альтернативу Vista. На сегодняшний день ноутбуки с тем или иным Linux уже предлагают Dell, HP, Lenovo, Asus. Их мотивы вполне понятны – используя Linux они получают возможность предложить работоспособный ноутбук для любых задач, используя при этом недорогие процессоры, всего 512 Mb оперативной памяти и встроенное видео. В конечном итоге это дает большую гибкость – можно снижать цены и захватывать рынок, а можно не менять цены и увеличивать свою прибыль с одного ноутбука.

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

При подготовке обзора использован материал Steven J. Vaughan-Nichols (http://www.eweek.com/category2/0,2662,1586243,00.asp).

Итоги опроса CIO Insight за 2007 год

Подведены итоги очередного исследования CIO Insight. Red Hat в очередной раз был назван лучшим поставщиком решений для корпоративного сектора и возглавил итоговый общий рейтинг. Так как хвастаться нехорошо, не будем распространяться дальше о деталях. Те, кому они интересны, могут прочитать полное исследование на http://www.cioinsight.com/article2/0,1540,2217106,00.asp.

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

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. В случаях, когда закон жизни не диктует обратное, именно такие решения стоит реализовывать. А какнибудь попозже мы расскажем как.