Будущее служб каталогов — без доменов

Фундаментальные подходы к безопасности, управлению устройствами и контролю доступа меняются.

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

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

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

Переосмысление служб каталогов и концепции домена

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

Многие ИТ-специалисты воспринимают эту область как должное и предполагают, что следующим логическим шагом будет ее адаптация и расширение для эры облачных вычислений путем добавления поставщиков услуг единого входа (SSO) веб-приложений и других мостов идентификации. Но более практичный подход может состоять в том, чтобы оглянуться назад на основные проблемы, для решения которых изначально была разработана предметная область, решить, какие из этих проблем все еще актуальны сегодня, и изучить новые способы их решения с использованием современных инноваций.

С середины 1990-х до середины 2000-х офисная обстановка была совершенно иной. Рабочие входили в обычные заведения, используя ключ-карты или настоящие ключи. Они подошли к своим столам и сели перед стационарными компьютерами. Эти компьютеры были подключены через кабель Ethernet к какому-то внутреннему центру обработки данных или серверному шкафу внутри физического офиса. Изнутри этого центрального расположения контроллер домена предоставил доступ к ИТ-ресурсам в локальной сети. Эта физическая сеть, в свою очередь, была защищена от внешних атак брандмауэром и самим зданием для физического доступа.

В то время эта установка была по существу безопасной и простой в управлении, и она предлагала настолько удобный пользовательский интерфейс, что пользователям не приходилось управлять несколькими паролями или думать о процессах авторизации и аутентификации, происходящих за кулисами. Среды были однородными: на каждой рабочей станции стояла настольная башня с Windows и программами Microsoft. Active Directory (AD) настолько хорошо подходила для этого типа среды, что могла предоставить пользователям то, что, возможно, было первым опытом единого входа (SSO): единый набор учетных данных для доступа к своим ИТ-ресурсам на базе Windows через единый вход в систему.

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

Но в мире, где так много работы выполняется за пределами домена, ИТ-отделы вынуждены переоценивать проблемы, с которыми Active Directory когда-то справлялась самостоятельно.

Современные недостатки модели предметной области

Active Directory с трудом адаптируется и интегрируется с современными облачными ресурсами и операционными системами, отличными от Windows, а модель защиты периметра, для которой она была разработана, недостаточна для защиты удаленных сотрудников.

Таким образом, возникает вопрос, как перевести централизованный административный рабочий процесс и простой и безопасный пользовательский интерфейс, когда-то обеспечиваемый AD, в современную среду, включающую системы Mac и Linux, веб-приложения, облачные серверы и удаленные сети, которые могут или не могут все еще быть активными. -Prem инфраструктуры, а также. Пользователи должны подключаться к своим ИТ-ресурсам с минимальными трудностями, независимо от того, где они работают, а ИТ-администраторы должны быть уверены, что удостоверения пользователей и конфиденциальные данные защищены от атак.

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

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

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

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

Когда дело доходит до систем, системы MacBook и Linux стали обычным явлением. Когда-то опытные администраторы Microsoft сопротивлялись внедрению систем Mac на рабочих местах, теперь это стандартная практика — приспосабливаться к этим системам. В традиционном домене Active Directory управление системами Mac и Linux не было бы таким простым и безопасным без добавления других точечных решений помимо AD, таких как инструмент управления системой или даже MDM.

Среды доменов, построенные на основе OpenLDAP, работают ненамного лучше: домены и серверы LDAP в основном управляют идентификацией, паролями, группами и организационными подразделениями, но им часто не хватает системного управления, применения политик безопасности и возможностей интеграции с облачными приложениями. ИТ-ресурсы перешли от простого использования LDAP в качестве предпочтительного протокола аутентификации к использованию современных стандартов, таких как SAML, SCIM, OAuth, OIDC и других. Устаревшие среды LDAP также требуют высокой квалификации для настройки и обслуживания.

Логичный способ восполнить указанные выше пробелы в надзоре за ИТ — реализовать современную бездоменную архитектуру.

Что на самом деле означает отсутствие домена на практике?

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

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

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

По большей части это связано с тем, что сама идея службы каталогов неразрывно связана с Active Directory — существующий инструмент заменяет отдельные проблемы, которые он когда-то решал. И аспект безопасности домена более интуитивно понятен: брандмауэры и дверные замки знакомы, и они дают нам ощущение контроля. Кажется логичным, что отказ от домена будет означать повышенную подверженность атакам и снижение контроля над безопасностью.

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

Основные функции облачной службы каталогов

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

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

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

Это различие важно при сравнении настоящей облачной службы каталогов с платформой SSO веб-приложений, которая предоставляет пользователям одну идентификацию для доступа к своим приложениям SaaS, но может не иметь возможности управлять доступом к устройствам, базовыми уровнями безопасности или аутентифицировать пользователей в устаревшей или локальной среде. ресурсов, используя предпочитаемые ими протоколы аутентификации. В этом смысле SSO на основе SAML — это всего лишь один из компонентов облачной службы каталогов; термины не взаимозаменяемы.

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

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

• Единая защищенная идентификация пользователя для доступа к устройствам, приложениям, WiFi/VPN, серверам и инфраструктуре разработки как локально, так и в облаке и независимо от поставщика.
• Возможность интеграции и консолидации удостоверений пользователей из других сервисов, включая G Suite, Office 365, AWS, AD/Azure и системы управления персоналом и расчета заработной платы.
• Возможность автоматической инициализации и деинициализации пользователей
• Удаленное управление системой с помощью политик, подобных GPO, для систем Mac, Windows и Linux и подробные отчеты о состоянии и атрибутах системы.
• Многофакторная аутентификация (MFA) при входе в систему Mac, Windows и Linux и для доступа практически ко всем другим ИТ-ресурсам, а также возможность управления ключами SSH.
• Гибкое и автоматизированное администрирование с помощью сценариев, API или PowerShell.
• Подробные данные и регистрация событий для поддержки аудита и соответствия требованиям

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

Ключи к отказу от домена: доверие к устройствам и многофакторная аутентификация

Хотя многие облачные решения IAM полностью основаны на браузерах, в них отсутствует ключ к современной бесдоменной безопасности: устройство. Пользователям по-прежнему нужен физический шлюз для работы, будь то ноутбук, планшет или смартфон. Большая часть постоянной проверки, необходимой для защиты бездоменной среды, должна выполняться устройством с использованием структуры, которую мы можем назвать доверием устройств .

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

Пользовательский опыт похож на SSO при входе в настольный компьютер в домене AD конца 1990-х — начала середины 2000-х годов, но то, что происходит за кулисами, гораздо сложнее, а широта ИТ-ресурсов, доступных для доступа, ограничена. гораздо больше.

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

• Правильный пользователь получает доступ к устройству, и этот пользователь является тем, за кого себя выдает.
• Правильное устройство запрашивает доступ
• Доступ запрашивается из нужного места
• Применяются правильные разрешения для пользователя/устройства в данном ресурсе.

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

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

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

Безопасность с нулевым доверием на практике

Безопасность с нулевым доверием означает, что служба каталогов, на которую возложена проверка подлинности, никогда не воспринимает легитимность пользователя, устройства, приложения или другого ИТ-ресурса как нечто само собой разумеющееся. Это достигается за счет защиты следующих четырех областей: сотрудников, систем, приложений и сети.

Сотрудники

Существует система для проверки того, что они действительно являются теми, за кого себя выдают, путем подтверждения своего пароля (что-то, что они знают) и своего токена MFA (что-то, что у них есть) в базе данных каталога, которая служит авторитетным источником правды.

Системы

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

Приложения

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

Сеть

Независимо от того, в какой сети находится пользователь, она должна быть максимально безопасной, но даже если она не является полностью безопасной, пользователь может создать безопасный анклав в этой сети с помощью VPN. Кроме того, сети можно защитить с помощью дополнительных средств, таких как MFA и даже сегментация VLAN.

Первые шаги к реализации бездоменной архитектуры

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

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

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

Если вы хотите узнать больше, изучите информацию об облачных службах каталогов на G2.