Интервью с Tim Howes

Jon Griffin, 31 мая — 4 июня 2017 года

В настоящее время Tim Howes является главным техническим директором компании ClearStory Data, ведущего поставщика средств обработки данных с быстрым циклом. Кроме того, он входит в состав технического консультативного совета компании JumpCloud, а также выступает в качестве исполнительного председателя компании Know Yourself, помогающей детям в познании себя.

Tim Howes был на острие технической индустрии с тех пор как стал одним из изобретателей протокола LDAP в 1993 году. Он сыграл важную роль в формировании современных IT-технологий, от протокола Lightweight Directory Access Protocol, который мы используем до сих пор, до модели SaaS-and-IaaS, которая внедряется во всё большее число организаций. На протяжении многих лет Howes был на лидирующих ролях в Netscape, AOL, HP и Yahoo. Также он основал два успешных технологических стартапа: Opsware (в 2007 году куплен HP за 1,65 миллиарда долларов) и Rockmelt (куплен Yahoo в 2013 году).

Недавно мы встретились с Тимом, чтобы обсудить истоки LDAP, а также его видение будущего IT. В итоге получилась состоящая из четырёх частей серия его ответов на наши вопросы.

Часть 1: Истоки LDAP и Directory-as-a-Service®

Вопрос: Расскажите об изобретении LDAP.

Tim Howes: LDAP возник в конце 80-х — начале 90-х годов прошлого века, когда я на пару лет отвлёкся от работы над своей кандидатской диссертацией в области компьютерных наук в Мичиганском университете.

Я был тогда в группе молодых выскочек, которые пытались принести Unix и Интернет в университетский кампус. Интернет только что появился, и Международная организация по стандартизации (ISO) создавала стандарты для всего в Интернет, в том числе для сервисов электронной почты и каталогов. Итак, мы работали со стандартом X.500, который был ответом ISO в области служб каталогов.

В то время я также работал в подразделении информационных технологий университета. Работа университета тогда в основном строилась на доморощенной системе мэйнфреймов, обслуживающих электронную почту и службу каталогов по всему кампусу. В этом проекте мне поручили реализацию каталога X.500 для кампуса, и я осуществил эту работу. Вместе с тем, для меня стало понятно, что протокол для работы с каталогом X.500 слишком тяжёлый и слишком сложный для тех машин, которые стояли тогда на рабочих столах большинства людей.

Таким образом, LDAP возник из моего желания сделать что-то немного более легковесное и приспособленное для Mac и ПК, которые тогда были повсеместно распространены. Вместе с несколькими коллегами мы создали схожий протокол, который назвали DIXIE, и он понравился людям. Вскоре после этого ко мне обратились некоторые люди из сообщества IETF с предложением создать стандартизированную версию DIXIE, и, совместно с парой коллег, мы сделали это. Вот так и появился LDAP.

Вопрос: Какие общие черты Вы видите в создании LDAP и появлении Directory-as-a-Service?

Tim Howes: В основании и того, и другого лежит децентрализация.

Во времена, когда создавался LDAP, существовало множество различных сервисов. Была электронная почта, а затем появились веб-страницы, справочные и коммерческие сервисы, и многое другое. Приходилось создавать учётные записи пользователей в нескольких местах. Идея стандартизованной службы каталогов заключалась в следующем: "Давайте абстрагируем то место, где находятся учётные записи пользователей, происходит аутентификация, и где хранится информация профиля пользователя". И это место стало службой каталогов.

Посмотрите, что происходит сейчас. Мы столкнулись с той же самой проблемой, только она намного больше. Тогда всё это было в рамках предприятия и под одним административным контролем. Сейчас же это происходит в масштабах Интернет, и административное управление полностью децентрализовано. У каждого пользователя имеется, по меньшей мере, пара десятков сервисов, которые он использует через Интернет, и лишь малая часть из них управляется одними и теми же административными центрами. И у Вас (Вашего предприятия) нет практически никакого административного контроля над всеми этими различными каталогами. Таким образом, масштаб проблемы сегодня намного больше, и отсюда возникают гораздо более значительные вызовы.

Часть 2: Обеспечение безопасности децентрализованной IT-инфраструктуры

Вопрос: Теперь, когда Интернет и SaaS децентрализованы, какие ключевые факторы должны иметь в виду администраторы IT-инфраструктуры, чтобы обеспечить безопасность своей среды?

Tim Howes: Многие из ключевых вопросов, с которыми сталкиваются администраторы сегодня, те же, с которыми они всегда сталкивались, но только теперь всё вокруг изменилось.

Мы находимся в гибридном мире, где по-прежнему много локальных сервисов (необходимость получения доступа к принтерам, машинам, файловым серверам и т.п. никто не отменял), но теперь нужно сочетать это со всем тем, что переместилось в облако, от Google и Microsoft, до любых других веб-сайтов. Итак, всё действительно намного сложнее, чем было когда-либо.

Возьмём, для примера, приём на работу и увольнение сотрудников. Когда кто-то приходит в организацию, как мне убедиться, что у него есть доступ ко всему тому, что ему необходимо для выполнения его работы, и только к этим ресурсам? С другой стороны, когда кто-то покидает организацию, как мне убедиться, что у него не сохранилось никакого доступа к ресурсам организации?

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

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

Часть 3: Microsoft, LDAP и каталоги

Вопрос: В какой степени Microsoft решает эту проблему с помощью Azure® и Active Directory®?

Tim Howes: Самая большая сила Microsoft заключается в огромной базе установленного программного обеспечения их производства. Но в этом также кроется их самая большая слабость.

У них миллионы клиентов, использующих Active Directory и весь набор продуктов Microsoft и поэтому, вместо того, чтобы заниматься проектированием с учётом новых перспектив, принимая во внимание сотни сервисов, находящихся вне пределов контроля Microsoft и их облака, они проектируют "глядя вовнутрь", то есть ориентируясь на свои существующие продукты. Иными словами, они смотрят назад.

Именно это происходит с Azure Active Directory. Они осознали, что организации смещаются в облако, и потому они разработали Azure чтобы облегчить этот переход. Но поскольку они заинтересованы в сохранении места Active Directory на рынке, одной ногой они всё ещё продолжают прочно стоять на решениях на базе внутренних ресурсов предприятия.

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

Это напоминает мне ситуацию, когда Microsoft вынудили к использованию LDAP. Существовало Интернет-сообщество, которое было сосредоточено на установлении открытых стандартов. Оно оказало давление на Microsoft, чтобы те приняли LDAP, и в конечном итоге они встроили LDAP в Active Directory, чтобы удовлетворить этому требованию. Но если Вы внимательно посмотрите на то, каким способом LDAP был интегрирован с Active Directory, то ничего стандартного Вы там не найдёте, это, скорее, очень специфичный Microsoft-путь.

Часть 4: Будущие тенденции в управлении идентификацией и доступом (Identity & Access Management, IAM)

Вопрос: Как, на Ваш взгляд, развивается пространство IAM?

Tim Howes: Есть бизнес-роли и есть личные роли. Кто-то скажет, что Facebook или Google — это источники аутентификации для моей частной жизни, а, к примеру, Salesforce или LinkedIn — это источники аутентификации для моей профессиональной жизни. Но сегодня эти роли слишком часто мешаются друг с другом.

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

Как мне кажется, это должно быть более формализовано. Хотелось бы увидеть немного больше кооперации между разными большими системами аутентификации, сложившимися в последнее время. Цель состоит в том, чтобы дать Вам возможность легко сегментировать различные имеющиеся у Вас учётные записи, которые Вы используете в течение дня.

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

Некоторые IT-организации реагируют на эти изменения с позиции упреждения. Они признают, что это и есть направление, в котором движется мир, и им нужно взаимодействовать с этим изменяющимся миром, используя новые административные решения. Другие организации всё ещё держатся за прошлое, пытаясь более жёстко контролировать то, что Вы можете и чего не можете сделать. Но эта битва проиграна. Более того, она уже закончена. Вам нужно принять нынешнее положение вещей и двигаться вперёд.

Вопрос: Какой совет Вы могли бы дать администраторам IT-инфраструктуры или лицам, принимающим бизнес-решения, о том, в каком направлении двигаться вперёд в плане управления идентификацией?

Tim Howes: Совет, который я бы дал клиентам: просто смотрите вперёд.

Вы должны думать не только о своих сегодняшних, но и о своих будущих потребностях. Нарастающее движение в облако, — уход от запуска локальных сервисов, локальных серверов, уход от сопровождения всего того, что Вам требуется, — уже напоминает цунами. Миграция происходит. Гораздо выгоднее попытаться быть в авангарде этого процесса, чем плестись в хвосте, пытаясь не отстать.

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

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