Время перемен: ALD Pro 3.0 меняет правила игры
Мир IT-инфраструктуры не стоит на месте. Новое обновление ALD Pro демонстрирует, как современные технологии могут сделать управление бизнесом проще и эффективнее.
Вышла новая версия ALD Pro 3.0, давайте посмотрим на изменения, которые появились с версии ALD Pro 2.2.1, которую мы изучали на этом канале. Все видео и статьи по ALD Pro можно найти в подборке.
=====================================================
Дизайн
В версии 3.0 команда ALD Pro начала работать над дизайном портала управления. На данный момент он обновлен еще не полностью, но можно заметить появление новых ниспадающих меню и частичное обновление основного меню.
Идет работа в направлении перехода на дизайн заточенный под массовые операции. Например в "Пользователи и компьютеры - Пользователи", теперь можно выбрать всех пользователей и заблокировать их или совершить другие массовые операции.
С версии ALD Pro 2.4 была добавлена светлая тема.
======================================================
Отказ от схемы работы с salt-master
В релизе ALD Pro 2.4 полностью отказались от salt-master в схеме работы, за счет чего стало возможным "выкинуть" многие ненужные компоненты информационной системы контроллера домена, что привело к очень сильному упрощению системы.
В чем же был минус использования схемы с salt-master?! Salt-master это управляющая часть SaltStack (его сервер), а salt-minion - его клиенты. Задача salt-master была - сформировать для salt-minion задания на исполнение, затем передать эти задания на salt-minion, чтобы они их выполнили, забрать обратную связь - инвентаризацию и отобразить ее.
Эта схема с salt-master показала себя очень ресурсозатратной. Если на один контроллер домена приходилось 5000 клиентов, то salt-master приходится обрабатывать 5000 salt-minion и это для него было очень большой нагрузкой (10-15 Гб ОЗУ и нагрузка на CPU). Если посмотреть на работу этой схемы в рамках групповых политик, то, так как задания для salt-minion формирует salt-master, то и суммирование политик для каждого пользователя/хоста выполнялось на salt-master. Т.е. для 5000 клиентов salt-master (контроллер домена) должен был выполнить суммирование политик, сформировать задания и передать их salt-minion. В этом случае мы противопоставляем ресурсы одного контроллера домена пяти тысячам рабочих станций.
С версии ALD Pro 2.4 вся та работа, что делал salt-master перенесена на клиенты. Контроллер домена теперь не выполняет операции по суммированию политик, формированию заданий и передачи их salt-minion, он просто хранит в каталоге параметры, которые клиенты вычитывают самостоятельно. Клиенты подключаются к контроллеру домена, считывают параметры и сами формируют задания, тем самым снимая нагрузку с контроллера домена.
Сам SaltStack по прежнему остается на контроллерах домена, т.к. это очень удобный инструмент. Теперь групповые политики после их назначения просто хранятся в LDAP каталоге на контроллерах домена. И standalon salt-minion самостоятельно, через определенные промежутки времени, подключаются к LDAP каталогу на контроллере домена, читают какие параметры групповой политики им назначены, выкачивают их и сами собирают у себя pillar (настройки результирующей политики) и затем локально применяют эти настройки.
И такая схема работы перенесена на все механизмы, которые использовали SaltStack, а это:
- групповые политики
- задания автоматизации
- политики ПО
- развертывание подсистем (ролей)
Еще одним плюсом, который дало избавление от salt-master - стала возможна беспроблемная работа в любых конфигурациях домена с любыми сайтами и любой IP-связностью (географически распределенные домены). Например, если у вас сеть состоит из сайтов в Москве - Екатеринбург - Владивосток и между сайтами Москвы и Владивостока нет прямой связности, то администратор Москвы на своем портале управления может назначить политики, задания автоматизации или др. на Владивосток, и они успешно "доедут" через систему репликации до Владивостока. Больше нет зависимости от прямой связности, главное чтобы работала репликация между сайтами и контроллерами домена.
Но такой подход снизил обратную связь и инвентаризацию и ей пришлось пожертвовать. Если раньше salt-master после назначения политики получал отчет от salt-minion что политика выполнена, то теперь он ничего не получает. Писать в LDAP каталог эти отчеты признано нецелесообразным, поэтому разработчики пришли к модели MS AD, где хост после применения политики не отчитывается перед контроллером домена, что он эту политику выполнил или нет. Теперь контролировать применение политик нужно локально на хосте. Разработчики дописали несколько утилит, именно для локального управления этим механизмом:
- aldpro-gpupdate (пример: sudo aldpro-gpupdate --gp - принудительно обновляет и применяет параметры групповых политик на целевом хосте, sudo aldpro-gpupdate --pm - обновляет менеджер политик)
- aldpro-roles - применяет роли подсистем. Сначала на портале управления подсистема назначается серверу, а затем командой aldpro-roles --iud применяете конфигурацию локально.
======================================================
Менеджер политик
Еще одно важное изменение - разработчики разделили код менеджера политик и код самих групповых политик. Менеджер политик содержит набор всех политик - это универсальные скрипты, которые работают по разному в зависимости от назначенных параметров политик. Набор скриптов одинаков для каждого клиента. Если раньше менеджер политик поставлялся отдельным пакетом, вместе с клиентом aldpro, то теперь он хранится в LDAP каталоге.
Теперь, при установки новой версии контроллера ALD Pro, вместе с ним идет новая версия менеджера политик, который сохраняется в LDAP каталог. Клиенты во время своей работы скачивают эту новую версию менеджера политик и обновляют свою старую локальную версию на новую.
Такое изменение дало следующий эффект - теперь, если нужно обновить контроллеры домена, то обновляются контроллеры домена и подсистемы до новой версии, а обновлять клиенты стало необязательным, они сами обновятся скачав с контроллеров новую версию скриптов salt (менеджера политик).
======================================================
Доверительные отношения
С версии ALD Pro 2.4 были добавлены доверительные отношения между доменами ALD Pro. Раньше доверительные отношения можно было строить только с доменами MS AD. На данный момент между доменами ALD Pro можно строить доверительные отношения без транзитивных отношений, леса доменов пока что строить нельзя. Работает это через плагин 389-ds плюс патченный sssd:
- Когда пользователь пытается войти в доверенный домен, клиент запрашивает авторизационную информацию о пользователе из доверенного домена. Эта информация отправляется в sssd клиентской машины.
- sssd видит, что это пользователь из доверенного домена и выполняет расширенный LDAP-запрос к своему контроллеру домена, через плагин.
- sssd контроллера домена запрашивает авторизационную информацию из доверенного домена и дальше по цепочке возвращает ее пользователю.
======================================================
Мультивендорность
В рамках релиза ALD Pro 3.0 официально стали доступны клиентские части для полноценного управления отечественными операционными системами ALT Linux 10.4, РЕД ОС 7.3 и РЕД ОС 8 через механизм групповых политик ALD Pro на базе Salt-скриптов. Это снимает ограничения и создает комфортные условия для управления мультивендорной инфраструктурой, расширяя горизонты использования отечественного ПО в корпоративных сетях. Так же для этих ОС были добавлены групповые политики.
======================================================
Политика паролей
В политику паролей добавили словарь запрещенных паролей. Проверка паролей по словарю выполняется автоматически на стороне контроллеров домена и позволяет значительно усложнить их взлом методом перебора. В словарь можно добавлять запрещенные к использованию пароли и пользователи не смогут себе их назначать. Размер базы не более 100 МБ.
Алгоритм хеширования паролей в каталоге переведён на PBKDF2-SHA256 (реализация на Rust), что даёт существенный прирост производительности LDAP-аутентификации при сохранении желаемой криптостойкости.
======================================================
Мандатное Разграничение Доступом
В портал управления было добавлено централизованное управление МРД/МКЦ. В ALD Pro 3.0 был добавлен весь тот функционал (в плане МРД/МКЦ), что есть в FreeIPA и, пока что, дополнительно схему каталога не расширяли. Массовые операции с МРД целенаправленно закрыты. Можно добавлять/удалять уровни/категории конфиденциальности (редактировать нельзя). Раздел "Привилегии Parsec" содержит преднастроенный справочник, расширенный по сравнению с FreeIPA (данные во FreeIPA соответствуют Astra Linux 1.6, а Parsec за это время уже развился).
На уровне МКЦ теперь есть возможность дополнительного разделение доступа в домене: например, контроллерам домена назначается 255-й уровень целостности, на сервера с подсистемами ALD Pro назначается 127-й уровень целостности, а рядовым хостам в домене назначается 63-й уровень целостности (у администратора домена максимальный уровень МКЦ - 255). В итоге доменный админ будет высокоцелостным пользователем и на контроллерах домена и на всех остальных хостах, а администратор с 63-м уровнем целостности будет высокоцелостным только на рядовых хостах, на контроллерах и серверах подсистем - нет. Подробнее покажу в видео.
На портале управления администратор может теперь регистрировать учтённые USB-накопители с указанием желаемых дискреционных и мандатных прав доступа; правила монтирования распространяются в домене через механизм LDAP-репликации и доставляются на рабочие станции по запросу службы SSSD в момент входа пользователя в систему.
Как пользователь получает в домене метки конфиденциальности
Файл конфигурации Parsec, который указывает какие базы данных нужно читать и откуда брать информацию по МРД при входе пользователя в домен - /etc/parsec/mswitch.conf
Есть 3 варианта:
- sssd - читать из sssd (из домена Free IPA)
- files - читать из локальных файлов
- ald - наследие старого ald домена, от которого отказались еще в Astra Linux 1.6
И, когда клиент вводится в домен ALD Pro, в этом файле везде проставляется источником базы sssd (доменный клиент), за счет чего все метки конфиденциальности будут получаться в первую очередь именно из домена, а не из локальных настроек, и только потом из локального файла.
Ниже представлен дефолтный файл, который создается после установки ОС (до ввода хоста в домен). В нем можно видеть, что источником стоит files. После ввода клиента в домен, files будет заменен на sssd.
cat /etc/parsec/beforeipa_mswitch.conf
При входе доменного пользователя sssd вернет ему метки конфиденциальности из домена. Если в систему войдет локальный пользователь, то sssd ему ничего не вернет - будут использованы локальные файлы.
======================================================
Модуль синхронизации
Был полностью переработан алгоритм синхронизации, вследствие чего существенно увеличилась скорость работы и исчезли ошибки синхронизации. Сопоставление объектов выполняется по уникальным идентификаторам objectGUID и nsUniqueId, синхронизация паролей вынесена в отдельный поток, а журнал событий разделён на сервисный, операционный и поток синхронизации данных — это существенно повышает скорость синхронизации критичных изменений и упрощает отладку. В интерфейсе изменений нет, они все под капотом.
======================================================
Состояние системы
Появилась новая вкладка "Состав системы", где в одном списке представлены все подсистемы (их версии и состояние). В каждую подсистему можно "провалиться" и попасть в ее карточку где можно посмотреть роли и соглашения.
======================================================
Роль PKI Proxy
Эта роль появилась с версии 2.4. Это специальная служба на контроллере домена, которая нужна для выпуска сертификатов в домене. В качестве центра сертификации выступает OpenSSL. Когда клиенту нужно получить сертификат, он себе в LDAP каталог в определенный атрибут пишет запрос на выпуск сертификата (после того как он у себя сгенерировал закрытый ключ и csr запрос, этот запрос он пишет себе в карточку в LDAP). Этот запрос передается по домену через репликацию, а сервер с ролью PKI Proxy находит в домене этот запрос, вычитывает его и выпускает по этому запросу сертификат подписав его корневым сертификатом домена (корневой сертификат домена должен храниться на сервере с ролью PKI Proxy, на других серверах домена корневой сертификат домена больше не хранится) и кладет этот сертификат в LDAP в карточку пользователя/хоста. Затем этот сертификат реплицируется по домену и пользователь, подключившись к домену его себе выкачивает.
В планах - подключить уже написанные плагины, чтобы PKI Proxy мог выступать шлюзом интеграции с другими внешними центрами сертификации.
======================================================
Графические утилиты
Эти утилиты пока что не идут в составе продукта, они находятся в личном кабинете как deb пакеты.
aldpro-join - графическая утилита для ввода хоста в домен. Позволяет не только подключить хост к домену ALD Pro, но и после проверить доверие домена с клиента и перевыпустить keytab файл (обновить пароль хоста). Так же, с помощью этой утилиты можно вывести хост из домена.
aldpro-dcpromo - графическая утилита для продвижения сервера до контроллера домена. Особенность ее в том, что она проводит проверку предварительных настроек (/etc/hosts, ip address) для возможности установки контроллера на конкретном хосте, позволяет выбрать/отказаться от установки глобального каталога и синкера.
======================================================
LAPS, Local Administrator Password Solution
Дополнительной функцией релиза, направленной на повышения безопасности, стала возможность управления паролями локальных администраторов (не доменных) (LAPS, Local Administrator Password Solution). Дает возможность не менять вручную пароли локальных админов на всех хостах домена, это будет делать по расписанию политика. Эта возможность пока что не появилась в интерфейсе.
Принцип работы следующий. В карточку хоста были добавлены дополнительные атрибуты и сделали дополнительную политику. Политика назначается на компьютеры, в ней прописаны учетки локальных администраторов и в определенное время (время настраиваемое, по умолчанию 90 дней) она генерирует для них случайный очень длинный пароль и применяет его, затем записывает его в карточку хоста в отдельный атрибут. После чего, доменный администратор с помощью графической утилиты aldpro-laps подключается к каталогу, выбирает из списка конкретный хост и утилита отображает ему пароль, который можно скопировать и использовать для входа под локальным администратором. Причем, если злоумышленник получит доступ к каталогу и поменяет пароль в этом атрибуте, то под ним доступ к хостам получить будет нельзя, смена пароля работает только в направлении от хоста к контроллеру, но не наоборот.
======================================================
ALD Pro 3.0 Free (бесплатная редакция)
В дополнение, начиная с релиза ALD Pro 3.0 стала доступна бесплатная редакция Free, которой можно воспользоваться для ознакомления с базовыми возможностями продукта или централизованного управления инфраструктурой в небольших организациях. Редакция позволяет установить один контроллер домена и создать доверительные отношения с одним лесом доменов Active Directory. В домене можно создать до 25 пользователей и до 25 компьютеров. Доступны групповые политики и удаленный доступ к рабочему столу пользователя для оказания технической поддержки. В редакции нет ограничений на возможность установки обновлений. При превышении ограничений у администратора будет всплывать окно сообщающее об этом.
======================================================
Модуль инвентаризации ACM в составе ALD Pro
Модуль создан на базе ACM 1.3.0. Представляет возможность программной и аппаратной инвентаризации. В составе ALD Pro поставляется бесплатно. Устанавливается как отдельный продукт на доменный хост.
---------------------------------------------------------------------------------------------
На этом с основными изменениями в ALD Pro - всё, напишите в комментариях, какие изменения Вы хотели бы увидеть в продукте в будущем.