В экосистеме SailPoint Identity Security Cloud (ISC) (ранее IdentityNow) управление кампаниями сертификации (certification campaigns) являеться ключевым процессом для обеспечения соответствия и управления доступом․ Долгое время администраторы сталкивались с существенным ограничением: интерфейс пользователя (UI) позволял применить поисковый запрос (search query) либо к идентичностям (identities), либо к доступу (access), но не к обоим одновременно․ Однако недокументированная возможность API открывает новый уровень гибкости автоматизации․

Проблема: Ограничения пользовательского интерфейса

Стандартный процесс создания кампании сертификации типа SEARCH через UI предполагает выбор одной цели для поискового запроса:

• Идентичности: Выбираются владельцы доступа, которые будут сертифицироваться․
• Доступ: Выбираются конкретные права доступа (роли, профили доступа, права приложений), которые будут проверяться․

Если требуется отфильтровать и тех, и других (например, сертифицировать только доступ к критическим системам и только для сотрудников определенного отдела), UI заставляет выбирать элементы вручную для второй категории․ Это делает процесс не пригодным для полной автоматизации, так как списки идентичностей и доступа регулярно меняются․

«Я давно расстраивался из-за ограничений кампаний сертификации в IdentityNow․ Главная проблема в том, что можно применить поисковый запрос либо для идентичностей, либо для доступа, но не для обоих сразу;․․ это не подходит для автоматизации, где списки регулярно меняются»․, Рамиро Фернандес, SailPoint Developer Community

Решение: Недокументированная возможность API Campaign Templates

Изучение API Campaign Templates (шаблонов кампаний) выявило несоответствие между документацией/UI и реальной моделью данных․ В спецификации API для создания шаблона кампании (create-campaign-template) присутствуют два ключевых объекта:

1. searchCampaignInfo — требует, чтобы тип кампании был SEARCH․ Содержит поисковый запрос․
2. filter, объект фильтра, который не имеет жесткой привязки к типу кампании в схеме API․ Документация гласит: «по умолчанию будет использоваться фильтр кампании по умолчанию, если это поле пустое»․ Фильтр по умолчанию включает всё․

Ключевое наблюдение: хотя UI не предоставляет поле для назначения фильтра (filter) для кампаний типа SEARCH, бэкенд (API) принимает и обрабатывает оба объекта одновременно․

Практическая реализация

Алгоритм действия для достижения двойной фильтрации:

1. Создать шаблон кампании (Campaign Template) через API (POST /beta/campaign-templates)․
2. В теле запроса указать type: "SEARCH"․
3. Заполнить searchCampaignInfo с запросом, ограничивающим доступ (например, access․type:ROLE AND access․name:Critical*)․
4. Добавить объект filter с критериями, ограничивающими идентичности (например, identity․attributes․department:IT)․
5. Запустить кампанию на основе этого шаблона․

Пример структуры JSON для API

{
 "name": "Automated Critical Access Campaign",
 "type": "SEARCH",
 "description": "Campaign filtering both identities (IT dept) and access (Critical roles)",
 "searchCampaignInfo": {
 "searchQuery": "access․type:ROLE AND access․name:Critical*"
 },
 "filter": {
 "identity": {
 "attributes": {
 "department": ["IT"]
 }
 }
 }
 // ․․․ другие обязательные поля: owner, deadline и т․д․
}

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

Риски и соображения надежности (Production Readiness)

Несмотря на работоспособность, данный подход несет серьезные риски, о которых предупреждал автор открытия и сообщество:

Отсутствие официальной поддержки

Функционал не задокументирован, не представлен в UI и, судя по реакции поддержки SailPoint («заведите идею на портале идей»), не является намеренным поведением․ Вероятно, это побочный эффект использования единой модели данных и бэкенд-сервиса для разных типов кампаний (Search и Filter-based)․

Риск ломающих изменений (Breaking Changes)

• SailPoint может убрать эту возможность в любом релизе (ежемесячные обновления ISC)․
• Валидация на уровне API может быть добавлена позже (например, ошибка 400 Bad Request при совмещении type: SEARCH и filter)․
• Миграция на новую версию API (например, с Beta на V3/V2024) может убрать эту «дыру»․

Отсутствие видимости в UI

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

Альтернативы и лучшие практики

Пока данная функциональность не легализована официально (идея GOV-I-1802 находится в статусе «Future Consideration»), рекомендуется использовать поддерживаемые паттерны:

• Кампании типа FILTER (Identity-based): Использовать фильтры идентичностей как основной механизм, а доступ ограничивать через настройку «Access to certify» в шаблоне (хотя гибкость ниже)․
• Программная генерация кампаний: Использовать API /beta/certifications для создания кампаний «на лету» с точным списком идентичностей и доступа, полученным через предварительные поисковые запросы (Search API)․ Это дает полный контроль и поддерживается официально․
• Разделение кампаний: Создавать отдельные кампании для разных сегментов бизнеса/доступа․

Открытая возможность комбинировать searchCampaignInfo и filter в API шаблонов кампаний SailPoint ISC — это мощный «хак», решающий давнюю боль автоматизации сертификации․ Он позволяет создавать динамические, точечные кампании без ручного труда․

Однако: использование этого в продакшн-среде без официальной поддержки вендора — это решение на свой страх и риск․ Архитектура «Identity Security Cloud» подразумевает частые обновления, и недокументированное поведение API может исчезнуть без предупреждения в заметках к релизу․ До выхода официальной функции (Feature Parity) безопаснее инвестировать в архитектуру на базе программного создания кампаний через Search API + Certification API․

Источник: Обсуждение в SailPoint Developer Community, автор Ramiro Fernandez (Nov 22, 2022)․ Тема: «Apply both search query and filter to a certification»․