Аннотация
В статье исследуется процесс автоматизированной централизованной установки средств электронной подписи в доменной инфраструктуре с использованием платформы ALD Pro версии 3.0.0. Проанализированы и реализованы на практике различные сценарии развертывания программных продуктов КриптоАРМ ГОСТ, КриптоПро CSP и КриптоАРМ посредством групповых политик и встроенных механизмов политик установки ПО. Исследование охватывает архитектурные и функциональные аспекты реализации, процедуры распространения и активации лицензий. Отмечены ограничения существующих подходов к централизованному распределению индивидуальных лицензий и предложены направления совершенствования процедур и архитектуры для повышения надежности, управляемости и предсказуемости эксплуатации в IT‑инфраструктурах.
Содержание
Публикация в частном репозитории ALD Pro установочного deb-пакета КриптоАРМ
Создание групповой политики дополнения списка APT-совместимых репозиториев на хостах
Настройка распространения ПО КриптоАРМ на клиентские рабочие места
Проблемы с публикацией в репозитории ПО КриптоАРМ ГОСТ: что предпринять?
Создание групповых политик распространения лицензий на устанавливаемое ПО
Введение
В условиях развитой IT‑инфраструктуры ключевым фактором эффективного управления программным обеспечением является способность централизованно контролировать процесс установки ПО на клиентские рабочие станции. В крупных корпоративных сетях с разветвленной доменной структурой традиционные методы развертывания ПО сталкиваются с рядом существенных проблем: множественность аппаратных конфигураций, разнообразие версий операционных систем и прикладных программ, требования по соблюдению норм безопасности и аудиторской отчетности, а также ограниченные возможности оперативного мониторинга и устранения неисправностей в распределенной среде.
Современные подходы к централизованному развертыванию ПО должны обеспечивать непрерывность бизнес‑процессов, минимизировать длительные простои рабочих мест и снижать нагрузку на подразделения IT‑поддержки. Ключевыми задачами в этом контексте являются: формулирование единой политики управления ПО, автоматическая проверка совместимости компонентов, централизованная публикация и распределение обновлений, а также мониторинг установок в режиме реального времени и аудит изменений. Для повышения эффективности внедрения решений применяются принципы цифровой трансформации IT‑инфраструктуры, в том числе организация управления через единый пакетный репозиторий и использование групповых политик.
Политики установки программного обеспечения (Software Deployment Policies) позволяют автоматизировать процессы развертывания, обновления и удаления ПО, снижая административную нагрузку, минимизируя риски несовместимостей и ошибок конфигурации, а также ускоряя ввод в эксплуатацию новых рабочих мест. В условиях курса на импортозамещение и обеспечение цифрового суверенитета российские организации обязаны переходить на отечественные программные решения. ALD Pro, разработанная компанией «Группа Астра», является импортонезависимой службой каталога, что делает её одним из ключевых кандидатов на замену Microsoft Active Directory в доменных инфраструктурах. При выборе данной платформы мы опирались на следующие ключевые возможности этого продукта:
Безопасность и комплаенс: решение сертифицировано ФСТЭК и соответствует российским нормативам по криптографии.
Совместимость: полная интеграция с отечественными СЗИ (СКЗИ, токены).
Технологический стек: поддержка LDAP и Kerberos, наличие механизмов репликации и резервирования.
Удобство администрирования: единый центр управления пользователями, группами, политиками и аудитом.
Легкий переход: встроенные инструменты для миграции из AD и Samba.
В настоящей работе рассматривается подход ALD Pro к управлению установками ПО посредством политик: их функциональные возможности, архитектурные решения и этапы внедрения.
Служба каталога ALD Pro — это импортонезависимый аналог Active Directory, который сертифицирован ФСТЭК по второму уровню доверия и позволяет централизованно управлять рабочими станциями, группами пользователей, применять политики безопасности и автоматизировать большую часть рутинных задач администрирования. В основе продукта лежит служба каталога FreeIPA, обеспечивающая полную поддержку нативных механизмов безопасности Linux, а система групповых политик реализована за счет интеграции с одной из ведущих платформ управления конфигурациями — SaltStack.
Именно это сочетание — зрелая служба каталога, промышленная система управления конфигурациями и встроенные механизмы политик установки ПО — делает ALD Pro релевантной площадкой для апробации методик автоматизированного развертывания средств электронной подписи, описанных далее.
ALD Pro предлагает централизованный механизм определения наборов приложений, условий их развёртывания и правил обновления, применяемых к клиентским машинам в зависимости от роли устройства, группы безопасности, версии ОС и иных параметров. Такой подход обеспечивает единообразие конфигураций, упрощает проведение аудита и соблюдение регуляторных требований, а также позволяет оперативно масштабировать развёртывания в динамично меняющейся IT‑среде.
Программный продукт ALD Pro включает несколько инструментов распространения ПО: задачи автоматизации, политики установки и интеграцию с групповыми политиками. В исследовании используются механизмы применения групповых политик в pull‑модели (когда агент периодически опрашивает сервер и применяет полученные изменения) и собственного механизма политик установки ПО. Анализ затрагивает следующие аспекты:
базовые принципы работы политик установки ПО в ALD Pro;
архитектура решения с использованием сервера репозиториев;
процессы разработки, тестирования и распространения политик;
типовые сценарии применения: пакетное развёртывание, распределённая активация лицензий и др.
Цель статьи — предоставить читателю четкое методологическое руководство по проектированию и внедрению политик установки ПО в среде ALD Pro с целью обеспечения надежной, устойчивой и управляемой платформы клиентских рабочих станций.
Архитектура решения
На рисунке 1 представлена архитектура домена в виде набора стендов виртуальных машин, где производились настройка отдельных компонентов системы и проверка различных сценариев работы. В представленной архитектуре имеется контроллер домена dc-1.ald.company.lan, репозиторий repo-1.ald.company.lan и несколько клиентских машин, введенных в домен. В данной статье мы не будем заострять внимание на вопросах развертывания компон��нт данной архитектуры, так как эти вопросы подробно освещены в материалах разработчиков продукта ALD Pro, а также в материалах статьи «Установка КриптоАРМ через групповые политики ALD Pro».
Пойдем немного дальше и рассмотрим различные проблемы, с которыми могут столкнуться администраторы домена при распространении ПО. Так как наша компания «Цифровые технологии» в основном занимается созданием средств подписи и шифрования и разрабатывает сервисы и программное обеспечение для этого сегмента, рассмотрим на практике пример распространения средств подписи на клиентские рабочие места. В качестве средств подписи будем рассматривать программные продукты:
КриптоАРМ (deb-пакет доступен для скачивания из репозитория https://ftp.digt.ru/web/PublicReleases/CryptoARM_6/v6.2.24/cryptoarm-6.2.24-linux64-x86.deb)
КриптоАРМ ГОСТ (deb-пакет доступен для скачивания из репозитория https://ftp.digt.ru/web/PublicReleases/CryptoARM_GOST/v3.7.37/cryptoarm-gost-3.7.37-linux64-x86.deb)
КриптоПро CSP (дистрибутив СКЗИ доступен только после регистрации на сайте https://cryptopro.ru/sites/default/files/private/csp/50/13003/linux-amd64_deb.tgz)
Все приведенные продукты имеют начальную пробную лицензию, поэтому после установки они работают в полнофункциональном режиме. Но проблемы установки лицензий для этих продуктов мы тоже затронем, чтобы картина была максимально полной.
Публикация в частном репозитории ALD Pro установочного deb-пакета КриптоАРМ
Создание частного репозитория для распространения ПО через политики установки — наиболее простой способ, не требующий разработки и отладки скриптов групповых политик. В ALD Pro это реализовано в административной панели и обеспечивает полный цикл управления ПО: установка, обновление и удаление с использованием единого набора инструментов.
Первый шаг, с которого можно начать рассмотрение этого сценария, – создать репозиторий Debian на основе установочного deb-пакета ПО «КриптоАРМ». Для этого запустим одновременно две виртуальные машины dc-1.ald.company.lan (контроллер домена) и repo-1.ald.company.lan (сервер репозиториев). Проверим прохождение запросов между сетевыми хостами. Откроем административную панель ALD Pro и выберем раздел «Установка и обновление ПО» и зайдем в пункт меню «Репозитории ПО». На вкладке «Серверы репозиториев ПО» у нас уже имеется ранее созданный сервер (можно проверить его доступность).
Приступим к созданию непосредственно самого репозитория ПО. Оставаясь в разделе «Установка и обновление ПО», откроем первую вкладку «Репозитории ПО». Изначально эта страница является пустой (рис. 3).
По кнопке «Новый репозиторий» откроем мастер создания репозитория, где нужно ввести название репозитория, например, «cryptoarm» (рис. 4). Здесь же формируем небольшое текстовое описание и относительный путь к репозиторию «/cryptoarm». Тип репозитория deb – установлено по умолчанию. Обязательно нужно нажать на кнопку «Сохранить».
В итоге должна появиться запись о нашем репозитории (рис. 5). Но на этом его создание не заканчивается.
Теперь нужно подгрузить непосредственно сам установочный пакет ПО. Входим в созданный репозиторий (просто щелкнув на любой элемент строки) и на вкладке «Версия» создаем новую версию. При этом будет открыт мастер, где нам будет предложено заполнить обязательные поля (рис. 6).
Следует учесть, что в ALD Pro нет возможности разместить в одном репозитории несколько версий продуктов или пакетов различных архитектур, поэтому некоторые из параметров являются номинальными. И при планировании распространения ПО следует ориентироваться на формулу: один программный продукт – один репозиторий. В нашем случае мы выбрали тип источника – пакеты, так как будем использовать готовый установочный deb-пакет распространяемого ПО. Добавляем источник, метку, версию и сохраняем изменения. Теперь нам доступна загрузка пакетов на вкладке «Текущее содержимое». Скачиваем свежую версию КриптоАРМ с помощью команд:
wget https://ftp.digt.ru/web/PublicReleases/CryptoARM_6/v6.2.24/cryptoarm-6.2.24-linux64-x86.deb
mv cryptoarm-6.2.24-linux64-x86.deb "cryptoarm-$(dpkg -f cryptoarm-6.2.24-linux64-x86.deb Version).deb".
И с помощью кнопки «Загрузить пакет» выбираем скачанный deb-пакет в диалоге (рис. 7).
После загрузки дистрибутив ПО отобразится на странице (рис. 8). Причем название пакета и его версия извлекаются автоматически при распаковке deb-пакета.
Для того чтобы репозиторий стал доступен пользователям, его нужно опубликовать, нажав кнопку «Опубликовать». После публикации дистрибутива на вкладке «Основное» появится абсолютный путь к данному репозиторию ПО, который ранее отсутствовал (рис. 9).
Если перейти по ссылке абсолютного пути, то нам отобразится структура репозитория, показанная на рисунке 10.
Для каждого репозитория создается каталог «/opt/rbta/aldpro/repo/storage/<repository_id>», внутри которого размещаются подкаталоги conf, db, distr, pool. В подкаталог pool загружается установочный deb-пакет (можно проверить его наличие через браузер).
Создав этот репозиторий, можно считать, что задача публикации нашего первого репозитория ПО завершена. Но для распространения ПО необходимо выполнить еще несколько шагов: создать групповую политику, которая будет автоматически добавлять этот репозиторий в качестве дополнительного на клиентских машинах (клиентская машина, введенная в доменную структуру, ничего не знает о нашем частном репозитории). Далее потребуется применить политики установки ПО для установки приложения из созданного репозитория.
Создание групповой политики дополнения списка APT-совместимых репозиториев на хостах
Создадим дополнительный параметр групповых политик для добавления на клиентских машинах нового репозитория. Перейдем в раздел «Управление доменом» и войдем в пункт меню «Доп. параметры групповых политик». Откроется вкладка с каталогом дополнительных параметров (рис. 11).
Нажмем на кнопку «Новый параметр» и в мастере заполним дополнительные поля. Название параметра может быть любым, и оно необходимо только для выбора параметра в интерфейсе управления политиками, поэтому введем название: Репозиторий установки КриптоАРМ. Уникальный идентификатор будет использоваться для формирования полного идентификатора, поэтому зададим значение: cryptoarm_repo_list. На его основе формируется полный идентификатор вида rbta_ldap_custom_gp_host_cryptoarm_repo_list, который мы позднее задействуем в скриптах. Тип каталога присваивается по умолчанию – Параметр компьютерной групповой политики. Тип параметра выберем из предлагаемого списка в виде составного параметра. Папку параметра оставим по умолчанию – Дополнительные параметры. В поле Назначение параметра можно ввести краткое описание. Результат показан на рисунке 12.
Обязательно сохраняем изменения, и параметр успешно создается. Теперь нам доступны для заполнения вкладки «Атрибуты параметра» и «Конфигурация скрипта». На вкладке «Атрибуты параметра» добавляются переменные, которые можно заполнять при использовании групповой политики (востребовано в том случае, когда одна и та же политики применяется для выполнения различных действий, например, установка/удаление или когда требуется указывать различные пути к репозиториям). На вкладке «Конфигурация скрипта» задается Salt-скрипт, в котором используются атрибуты, и он составляет основу групповой политики. Добавим новый атрибут параметра с именем «Источник» и идентификатором cryptoarm_repo_item (рис. 13).
На вкладке «Конфигурация скрипта» в окно редактора добавим скрипт Salt следующего вида:
{% set id = 'rbta_ldap_custom_gp_host_cryptoarm_repo_list' %} {% set node = salt['grains.get']('nodename') %} {% set gpo = salt['pillar.get']('aldpro-hosts:' + node + ':' + id) %} {% set filename = '/etc/apt/sources.list.d/cryptoarm_repo.list' %} {% set lines = [] %} {% if gpo %} {%- for item in gpo %} {%- if item.cryptoarm_repo_item.lower() != 'none' %} {%- do lines.append(item.cryptoarm_repo_item) %} {%- endif %} {%- endfor %} {% endif %} {{ id }}: {%- if lines|length == 0 %} file.absent: - name: {{ filename }} {%- else %} file.managed: - name: {{ filename }} - user: root - group: root - mode: 644 - contents: {%- for line in lines %} - {{ line }} {%- endfor %} {%- endif %}
Данный скрипт будет создавать файл /etc/apt/sources.list.d/cryptoarm_repo.list, настраивать права и добавлять в файл указанные в виде параметра источники (опубликованные репозитории) для загрузки пакетов устанавливаемого ПО. Если скрипт реализован без ошибок и представлен в формате Unicode без BOM, то редактор его воспримет без сообщений об ошибках (рис. 14). В противном случае потребуется его отладка.
На рисунке 15 представлен вид отображения настроек дополнительных параметров компьютера. Так как мы не стали создавать отдельные каталоги, параметры политики вошли по умолчанию в каталог «Дополнительные параметры».
Теперь нам нужно создать и настроить групповую политику на основе дополнительного параметра. Для этого открываем раздел «Групповые политики» и переходим в одноименный пункт меню. Создаем новую групповую политику «Добавление репозитория» (рис. 16). Можно добавить некоторое текстовое описание и обязательно сохранить политику.
После сохранения становятся доступны следующие вкладки. Нас интересует вкладка «Параметры компьютеров», так как политика будет применяться не для пользователя, а для клиентских рабочих станций. Выберем ранее созданный дополнительный параметр и установим для атрибута «Источник» строку в формате репозитория, которая будет добавлена в файл cryptoarm_repo.list:
deb [trusted=yes] http://repo-1.ald.company.lan/repos/cryptoarm/ cryptoarm main
Также необходимо переключить состояние на Включено (это можно сделать вручную, если в выпадающем списке не будет такого значения) и обязательно применить внесенные изменения.
Затем нужно перейти на вкладку «Подразделения» и добавить новое подразделение, в которое можно включить доступные клиентские машины, введенные в домен (рис. 18).
К выбранным машинам будет применяться созданная групповая политика. Чтобы не дожидаться ее применения, можно использовать команду для формированного применения политик на клиенте:
sudo aldpro-gpupdate --gp
После успешного применения политик просматриваем на клиенте каталог /etc/apt/sources.list.d и убеждаемся в наличии файла с записью о репозитории, который мы создали и опубликовали на repo-1.ald.company.lan (рис. 19).
Переходим к созданию групповой политики установки КриптоАРМ из репозитория на рабочее место.
Настройка распространения ПО КриптоАРМ на клиентские рабочие места
Для создания групповой политики установки КриптоАРМ на клиентские рабочие места перейдем в раздел «Установка и обновление ПО» и откроем вкладку «Каталог ПО», добавим новое программное обеспечение (рис. 20).
Сохраним изменения и откроем созданное ПО «КриптоАРМ 6» на редактирование. На вкладке «Пакеты» добавляем новый пакет (выбираем из списка, так как deb-пакет уже загружен и размещен в репозитории), также не забываем выбрать версию пакета (рис. 21).
Переходим в раздел «Политики ПО». Создаем новую политику «Установка КриптоАРМ 6» (рис. 22, 23). Не забываем сохранить изменения.
Добавляем подразделение для применения политики (рис. 24).
Используем команды для форсированного применения политик на клиенте
sudo apt-cache policy cryptoarm6
sudo aldpro-gpupdate –swp
Получаем результат в виде установленного программного пакета cryptoarm6 на клиентской машине (рис. 25).
Проблемы с публикацией в репозитории ПО КриптоАРМ ГОСТ: что предпринять?
Иногда при автоматизации работы с ПО можно встретить установочные пакеты, которые отличаются от стандартов, ввиду особенностей сборки, требований совместимости и т.д. Пакеты подобного рода проблематично загрузить в репозиторий стандартными средствами. Рассмотрим подобную ситуацию на примере установочного пакета КриптоАРМ ГОСТ. Следуя инструкциям предыдущего раздела, попробуем сформировать репозиторий для данного продукта (рисунок 26).
Сделаем загрузку deb-пакета и опубликуем его (рисунок 27). Загрузка и публикация пакета проходит без каких-либо предупреждений и ошибок.
Посмотрим содержимое опубликованного пакета в репозитории по пути https://repo-1.ald.company.lan:443/repos/cryptoarmgost/. На странице увидим следующее:
По сравнению с репозиторием, который создавался в предыдущем разделе, здесь отсутствует каталог /pool в котором, собственно, и должен находиться установочный deb-пакет (рис. 28). При его отсутствии попытка установки через политики установки ПО ALD Pro приведет к ошибке.
Если по какой-либо причине репозиторий для загруженного пакета сформировался некорректно, то можно рассмотреть альтернативный вариант – установку через групповые политики, выполнив загрузку установочного пакета из внешнего доверенного репозитория.
Групповые политики распространения ПО в домене ALD Pro
Перейдем в раздел «Управление доменом», выберем из меню пункт «Доп.параметры групповых политик» и создадим новый параметр «Установка КриптоАРМ ГОСТ 3» (рис. 29).
Сохраним изменения. На следующей вкладке создадим следующий набор атрибутов (рис. 30).
Здесь используется следующий набор атрибутов:
pkg_state – управление действием по установке/удалению ПО из системы;
pkg_src – путь к опубликованному установочному deb-пакету внешнего доверенного репозитория;
pkg_name_install – наименование пакета для установки ПО;
pkg_name_remove – наименование пакета для удаления ПО (используется из-за несовпадения имен установочного пакета и установленного в системе).
Salt-скрипт для применения:
{% set id = 'rbta_ldap_custom_gp_host_cryptoarmgost' %} {% set node = salt['grains.get']('nodename') %} {% set gpo = salt['pillar.get']('aldpro-hosts:'+node+':'+id) %} {% if gpo %} {% for item in gpo %} {% if item.pkg_src is defined and item.pkg_src %} {% set raw_src = item.pkg_src.strip() %} {% set file_name = raw_src.split('/')[-1] %} {% set tmp_file = '/tmp/' ~ file_name %} {% set pkg_install_name = item.pkg_name_install | default('deb_package') %} {% set pkg_remove_name = item.pkg_name_remove | default('deb_package') %} {% if (item.pkg_state | default('install')).lower() == 'install' %} # Скачиваем и размещаем deb-файл download_package_{{ loop.index }}: file.managed: - name: {{ tmp_file }} - source: {{ raw_src }} - mode: '0644' - skip_verify: True - makedirs: True # Установка пакета из временного deb-файла install_package_{{ loop.index }}: pkg.installed: - name: {{ pkg_install_name }} - sources: - {{ pkg_install_name }}: {{ tmp_file }} - skip_verify: True - require: - file: download_package_{{ loop.index }} # Очистка временного файла после установки cleanup_package_{{ loop.index }}: file.absent: - name: {{ tmp_file }} - require: - file: download_package_{{ loop.index }} {% else %} # Удаление пакета remove_package_{{ loop.index }}: pkg.removed: - name: {{ pkg_remove_name }} {% endif %} {% endif %} {% endfor %} {% else %} # Политика не назначена или пустое значение cryptoarmgost_not_assigned: test.nop: - name: Политика cryptoarmgost не назначена или имеет пустое значение {% endif %}
Далее переходим в раздел «Групповые политики» и создаем новую групповую политику «Установка КриптоАРМ ГОСТ из внешнего репозитория». На вкладке «Параметры компьютеров» выбираем созданный ранее дополнительный параметр «Установка КриптоАРМ ГОСТ 3» и заполняем обязательные атрибуты (рис. 31).
Не забываем добавить подразделения или компьютеры, для которых применяется политика. Корректность ее исполнения можно проверить на каком-либо хосте с помощью форсированного применения командой
sudo aldpro-gpupdate --gp
На рисунке 32 проиллюстрирован запуск приложения КриптоАРМ ГОСТ на клиентской машине. Для удаления установленного ПО из системы достаточно в параметрах групповой политики поменять install на remove.
Групповые политики распространения ПО КриптоПро CSP
Довольно часто с различными средствами подписи используется СКЗИ КриптоПро CSP. Он может быть включен в состав дистрибутива и тогда установка производится по одному из рассмотренных ранее сценариев. Но СКЗИ может устанавливаться и отдельно. Рассмотрим, каким образом можно автоматизировать эту установку, используя групповые политики ALD Pro.
Если скачать и посмотреть содержимое дистрибутива КриптоПро CSP, для linux систем он предоставляется в виде архива, например, linux-amd64_deb.tgz, то мы увидим множество deb-пакетов различных модулей и сам установочный Bash-скрипт install.sh. В данном случае предпочтительным будет вариант создания на основе содержимого архива некоторого ISO-образа, который можно развернуть как репозиторий стандартными средствами ALD Pro. Конечно, это будет не полноценный ISO-образ для создания Debian-совместимого репозитория, но такой шаг позволит обойти необходимость развертывания файлового сервера.
Создание ISO-образа КриптоПро CSP осуществляется при помощи команды (с предварительной распаковкой содержимого архива в каталог /iso_files):
genisoimage -o cryptopro.iso -R -J ./iso_files
При выполнении команды в консоли мы видим, что все установочные пакеты и скрипты добавляются в образ (рис. 32).
Попробуем загрузить созданный ISO-образ в репозиторий. Перейдем в раздел «Установка и обновление ПО», выберем пункт «Репозитории ПО» и создадим новый репозиторий под названием «cryptoprocsp» (рис. 33).
После сохранения изменений создадим новую версию репозитория и загрузим ISO-образ (рис. 34).
В отличие от deb-пакетов iso образ не нужно публиковать. После загрузки он публикуется автоматически. Перейдя по ссылке на опубликованный репозиторий, видим доступный набор пакетов модулей и установочные скрипты (рис. 35).
Следующим этапом создаем дополнительный параметр групповой политики с необходимыми атрибутами (нам понадобится атрибут для указания действия – install/remove и адреса репозитория в качестве источника данных) и формируем необходимый Salt-скрипт:
{% set id = 'rbta_ldap_custom_gp_host_cryptoprocsp' %} {% set node = salt['grains.get']('nodename') %} {% set gpo = salt['pillar.get']('aldpro-hosts:'+node+':'+id) %} {% if gpo %} {% for item in gpo %} {% if item.repo_src is defined and item.repo_src %} {% set work_dir = '/tmp/cryptopro' %} {% set dest_dir = '/opt/cprocsp' %} # Создание временного каталога create_tmp_directory_{{ loop.index }}: file.directory: - name: {{ work_dir }} - mode: '0755' # Скачиваем все пакеты в каталог download_cryptopro_{{ loop.index }}: cmd.run: - name: "cd {{ work_dir }} && wget -r -np -nH --cut-dirs=3 -R '*.html*' {{ item.repo_src }}" - shell: /bin/sh - require: - file: create_tmp_directory_{{ loop.index }} {% if (item.pkg_state | default('install')).lower() == 'install' %} - unless: test -f {{ dest_dir }}/bin/amd64/csptestf {% else %} - onlyif: test -f {{ dest_dir }}/bin/amd64/csptestf {% endif %} {% if (item.pkg_state | default('install')).lower() == 'install' %} # Установка КриптоПро CSP install_cryptopro_{{ loop.index }}: cmd.run: - name: "bash {{ work_dir }}/install.sh" - cwd: {{ work_dir }} - shell: /bin/bash - unless: test -f {{ dest_dir }}/bin/amd64/csptestf - require: - cmd: download_cryptopro_{{ loop.index }} {% else %} # Удаление КриптоПро CSP remove_cryptopro_{{ loop.index }}: cmd.run: - name: "bash {{ work_dir }}/uninstall.sh" - cwd: {{ work_dir }} - shell: /bin/bash - onlyif: test -f {{ dest_dir }}/bin/amd64/csptestf - require: - cmd: download_cryptopro_{{ loop.index }} {% endif %} # Очистка временного каталога cleanup_cryptopro_{{ loop.index }}: file.absent: - name: {{ work_dir }} - force: True - require: {% if (item.pkg_state | default('install')).lower() == 'install' %} - cmd: install_cryptopro_{{ loop.index }} {% else %} - cmd: remove_cryptopro_{{ loop.index }} {% endif %} {% else %} # Обработка случая, когда переменная repo_src не определена или пуста cryptoprocsp_invalid_config_{{ loop.index }}: test.fail_without_changes: - name: "Ошибка в политике №{{ loop.index }} переменная 'repo_src' не определена." {% endif %} {% endfor %} {% else %} # Политика не назначена или пустое значение cryptoarmgost_not_assigned: test.nop: - name: Политика cryptoprocsp не назначена или имеет пустое значение {% endif %}
Далее переходим к формированию самой групповой политики в разделе «Групповые политики» (рис. 36). Не забываем включить групповую политику и правильно указать настройки атрибутов. На вкладке «Подразделения» выбираем отдел с клиентскими машинами для применения политики.
На клиентской машине вводим команду форсированного применения групповой политики и смотрим результат. На рисунке 37 показано, что ПО КриптоПро CSP успешно установлено на клиентскую машину.
Мы рассмотрели основные сценарии автоматической установки средств подписи через политики установки ПО и групповые политики ALD Pro. Отдельно следует обратить внимание на то, что помимо установки ПО, требуется и установка лицензий на используемое программное обеспечение. Обычно установка лицензий осуществляется также на клиентских рабочих местах и это тоже является объектом автоматизации. Смоделируем несколько подходов к решению подобных задач.
Создание групповых политик распространения лицензий на устанавливаемое ПО
Рассмотрим самый простой сценарий распространения лицензии – ее передачу на клиентское рабочее место в виде текстового блока, закодированного в формате BASE64, с последующим сохранением в файловую систему. Для этого создадим дополнительные параметры групповых политик - перейдем в категорию «Управление доменом» и из меню выберем пункт «Дополнительные параметры групповых политик» (рис. 38). Создаем новый параметр на вкладке «Параметры компьютеров».
Не забываем сохранить изменения. На следующей вкладке формируем два атрибута (рис. 39, рис. 40).
Формируем Salt-скрипт. Здесь возможно несколько вариантов исполнения скрипта. В том случае, когда у нас Тип параметра обозначен как простой параметр, мы можем использовать такой вариант:
{% set id = 'rbta_ldap_custom_gp_host_copy_license_file' %} {% set node = salt['grains.get']('nodename') %} {% set gpo = salt['pillar.get']('aldpro-hosts:' + node + ':' + id) %} {% if gpo %} {% set source_file = gpo.get('source_file', '') %} {% set dest_file = gpo.get('dest_file', '') %} {% if source_file.startswith('data:text/plain;base64,') %} write_base64_source_file: cmd.run: - name: "echo '{{ source_file[23:] }}' | base64 -d > \"{{ dest_file }}\"" - unless: 'test -f "{{ dest_file }}"' - shell: /bin/bash {% else %} {% do salt.log.warning('source_file не является строкой Base64 для элемента: ' + gpo | tojson) %} {% endif %} verify_file_creation: cmd.run: - name: 'test -f "{{ dest_file }}"' - shell: /bin/bash {% endif %}
В том случае, если мы будем использовать Тип параметра: составной, перебор атрибутов осуществляется в цикле (конструкция «for item in gpo») и скрипт должен иметь вид:
{% set id = 'rbta_ldap_custom_gp_host_copy_license_file' %} {% set node = salt['grains.get']('nodename') %} {% set gpo = salt['pillar.get']('aldpro-hosts:' + node + ':' + id) %} {% if gpo %} {% for item in gpo %} {% if item.source_file.startswith('data:text/plain;base64,') %} write_base64_source_file_{{ loop.index }}: cmd.run: - name: "echo '{{ item.source_file }}' | base64 -d > {{ item.dest_file }}" - unless: 'test -f {{ item.dest_file }}' - shell: /bin/bash {% else %} {% do salt.log.warning('source_file не является строкой Base64 для элемента: ' + item | tojson) %} {% endif %} verify_file_creation_{{ loop.index }}: cmd.run: - name: 'test -f "{{ item.dest_file }}"' - shell: /bin/bash {% endfor %} {% endif %}
Абсолютно так же, как и в других сценариях, создается групповая политика, заполняются атрибуты, политика активируется. Результатом ее работы является передача лицензионного ключа в формате BASE64 на клиентское рабочее место, его декодирование и размещение в виде файла в указанную директорию. Данный сценарий распространения применим, когда имеется потребность передачи одной и той же лицензии на множество рабочих мест. Но что делать, если на каждом рабочем месте ПО требует индивидуальной лицензии? В таком случае нам нужно иметь некоторый пул лицензий и распределять их на разные рабочие места. Попробуем смоделировать такой вариант распределения лицензий через групповые политики.
Ранее мы уже создавали дополнительные параметры групповых политик, пройдем по тому же пути. Открываем раздел «Управление доменов» и входим в меню «Доп. параметры групповых политик» (рис. 41). Создаем новый параметр под названием «Лицензии КриптоАРМ 6» также с размещением в каталоге «Дополнительные параметры».
Обязательно сохраняем изменения, и нам становятся доступны для редактирования следующие вкладки. Вкладку «Атрибуты параметра» пропускаем – никаких дополнительных параметров, которые будут использоваться в скрипте, нам не потребуется. На вкладке «Конфигурация скрипта» вводится сам Salt-скрипт (рис. 42).
Вид Salt-скрипта по созданию файла license.lic и добавления в него лицензии на КриптоАРМ:
{% set node = salt['grains.get']('nodename') %} {% set hostname = node.split('.')[0] %} {% set licenses = {"client-1": "CC6VP-APVTA-DJFKF-PCXFW-TQWFW-XRFVX-JAKFM", "client-2": "CC6XH-KHLWK-XCWKA-PCSFQ-RCKMV-XTKJT-HJXTA"} %} {% set directory_path = '/etc/opt/Trusted/CryptoARM 6/' %} {% set license_file_path = '/etc/opt/Trusted/CryptoARM 6/license.lic' %} {% set license_entry = licenses.get(hostname) %} {{ directory_path }}: file.directory: - user: root - group: root - mode: 755 {{ license_file_path }}: file.managed: - user: root - group: root - mode: 644 - contents: > {% if license_entry %} {{ license_entry | trim }} {% else %} # Лицензия для хоста {{ hostname }} не найдена. {% endif %}
Кратко разберем структуру скрипта. В переменную node мы получаем доменное имя хоста, к которому применяется групповая политика, например, client-1.ald.company.lan. В переменную hostname мы выделяем имя client-1 и в соответствии с этим именем из словаря licenses получаем лицензионный ключ в переменную license_entry. Далее проверяется наличие директории размещения ключа '/etc/opt/Trusted/CryptoARM 6/', если ее нет, то она создается. В директории формируется файл license.lic, куда помещается лицензионный ключ. Приложение КриптоАРМ автоматически считывает лицензионный ключ при запуске из данной директории.
Чтобы применить этот скрипт, переходим в раздел «Групповые политики» и выбираем одноименное меню. Назовем групповую политику «Распространение лицензий» (рис. 43).
Сохраняем изменения и переходим на вкладку «Параметры компьютеров», где уже отображается созданный ранее дополнительный параметр, остается изменить его состояние – на «Включено» (рис. 44).
Для проверки работы групповой политики на клиентской машине инициируем ее форсированное применение с помощью команды:
sudo aldpro-gpupdate --gp
После успешного выполнения смотрим наличие и содержимое файла license.lic (рис. 45).
Убеждаемся, что ключ лежит по определенному пути. Запуск КриптоАРМ на клиентской машине приводит к загрузке данного лицензионного ключа (рис. 46).
Заключение
По результатам практической реализации и анализа множества сценариев развертывания ПО, можно сделать вывод, что механизмы автоматизированной установки приложений с использованием политик ALD Pro обеспечивают стабильную, предсказуемую и масштабируемую доставку программных компонентов на клиентские рабочие станции и не вызывают существенных затруднений при эксплуатации в доменной инфраструктуре.
В то же время вопросы централизованного и полностью автоматизированного управления лицензиями выходят за рамки задач, решаемых средствами доменных политик и систем доставки ПО. В отсутствие специализированного серверного механизма лицензирования возможности автоматизации ограничиваются этапами первоначального распространения и активации лицензий без обеспечения полного жизненного цикла лицензии, включая учет использования, повторное распределение и контроль состояния в динамически изменяющейся среде.
Проведенный анализ показывает, что дальнейшее повышение эффективности автоматизированного лицензирования требует развития функциональности на уровне разработки и интеграции собственных продуктов. Возможные направления деятельности по совершенствованию процессов автоматического лицензирования охватывают:
Введение централизованного сервера лицензий: целесообразно рассмотреть развёртывание отдельного сервера лицензий, выполняющего функции пула лицензий, централизованного учета и корректной синхронизации между клиентами и сервером.
Усовершенствование протоколов взаимодействия: разработка и внедрение протоколов, обеспечивающих безопасный обмен метаданными о лицензионной выдаче, статусах, тайм-аутах аренды и повторных попытках активации, с поддержкой журналирования на уровне сервера.
Расширяемая архитектура профилей: создание профил��й конфигурации, включающих детализированные параметры распределения, лимиты одновременного использования, правила перераспределения и условную логику перераспределения лицензий при изменении нагрузки.
Поддержка гибридных моделей лицензирования: исследование возможностей внедрения процессных (конкурентных) лицензий, которые освобождаются по завершении задачи или закрытии сеанса, что требует дополнительных механизмов детектора завершения работы и коррекции пула.
В последующих статьях по этой тематике планируется представить рабочий вариант подобной системы распространения и управления лицензиями на примере программного обеспечения средств подписи и сравнить эффективность различных решений автоматизированной установки ПО в доменной структуре.
Если вы только приступаете к развертыванию или планируете сложную архитектуру домена, не стоит изобретать велосипед. Вот три проверенных источника информации:
Обучающие курсы. Официальные материалы — это не просто сухая теория. Многие разделы (проверено на личном опыте) незаменимы при практической настройке доменной структуры.
Групповые политики через SaltStack. Важный момент для тех, кто ценит автоматизацию: под капотом политик в ALD Pro лежит SaltStack. Это дает огромный плюс — базы знаний по Salt огромны, а современные ИИ-ассистенты отлично справляются с анализом и генерацией Salt-скриптов. Если нужно кастомное решение, «докрутить» его с помощью ИИ будет несложно.
Сообщество «ALD Proфессионалы». В Telegram-чате проекта уже более 2000 участников: от системных администраторов до крупных интеграторов. Это живая база кейсов и архитектурных решений. Бонус: в группе присутствуют разработчики ALD Pro и представители ГК «Астра», поэтому на сложный вопрос можно получить ответ напрямую от первоисточника.
