Это иллюстративный сценарий, а не история клиента. Он не использует ни реальной организации, ни реальных людей, ни заявленных результатов. Его цель — показать, как исполняемый пак Vendor Security от Threada провёл бы рутинную проверку безопасности от запроса до зафиксированного решения. Каждая описанная ниже поверхность — это реальная возможность продукта; ситуация придумана для иллюстрации.
Команды безопасности тратят удивительно большую часть своей недели на проверки, которые в основном рутинны и порой серьёзны. Новому SaaS-инструменту нужно одобрение. Поставщик хочет обрабатывать данные клиентов. Запрашивается исключение из действующей политики. Большинство из них следует знакомой форме; некоторые требуют настоящего разбора. Сложность редко в анализе — она в том, чтобы сохранять каждую проверку последовательной, обоснованной доказательствами и зафиксированной.
Вот как эта работа проходила бы через пак Vendor Security от Threada.
Форма работы
Vendor Security — это пак workspace с архетипом case и тремя определёнными intent:
- Проверка поставщика — оценить нового или продлеваемого поставщика по политике.
- Проверка обработки данных — оценить, может ли поставщик обрабатывать определённые данные.
- Исключение по безопасности — обработать запрос на отклонение от действующего контроля.
Проверяющему не нужно решать, какую форму открыть. Он заявляет intent, и среда выполнения превращает его в структурированный WorkItem в очереди безопасности.
Разбор
Представьте, что приходит запрос: команда хочет внедрить нового поставщика аналитики, который будет получать данные об использовании продукта. В этом сценарии он поступает через настроенный канал приёма и становится WorkItem.
Intent. Проверяющий (или запрашивающий, через канал) описывает нужный ему результат — «проверить этого поставщика аналитики на одобрение обработки данных». Среда выполнения извлекает поставщика, задействованные категории данных и первоначальный флаг риска и заносит это в очередь Vendor Security.
Canvas. WorkItem открывается на адаптивном canvas. Вместо пустой формы workspace собирает поля, которые нужны для такого рода проверки: категории данных, место обработки, субобработчики, соответствующий профиль политики. Там, где информации не хватает, он запрашивает именно её, а не предъявляет недифференцированную анкету.
Доказательства. Ящик доказательств содержит то, на что опирается оценка, — поданную поставщиком документацию, прежние проверки того же поставщика и ссылки на применимую политику. Если система не может обосновать конкретное утверждение, она фиксирует причину запасного варианта, а не заявляет уверенность, которой у неё нет. Проверяющий может с одного взгляда увидеть, насколько свеж каждый источник.
Контроли. Именно здесь проверка становится решением. Одобрение обработки данных для нового поставщика — это действие с последствиями, поэтому оно проходит через поверхность управляемых контролей: предложение, а затем явное одобрение по отношению к активной версии политики. Если политика требует второго утверждающего для этой категории данных, шлюз обеспечивает это. Ничего не выполняется молча.
Журнал выполнения. Каждый шаг накапливается в журнале выполнения — приём, запросы недостающей информации, изученные доказательства, одобрение и кто его дал, и итоговый зафиксированный результат. Поскольку действия ИИ-участников отображаются как отдельные события actor, журнал ясно показывает, какие шаги обработала система, а какие решил человек.
Что остаётся у команды
В итоге у команды безопасности есть три вещи, которые иначе ей пришлось бы собирать вручную:
- Последовательная проверка. Один и тот же intent всегда порождает одну и ту же форму workspace, поэтому проверки не дрейфуют в строгости между загруженной и спокойной неделей.
- Обоснованное решение. Одобрение привязано к конкретным доказательствам и поименованной версии политики, а не к воспоминанию проверяющего.
- Квитанция. Вся проверка зафиксирована — защитима перед аудитором и читаема для следующего проверяющего, который берётся за похожий случай.
Рутинные проверки движутся быстро, потому что workspace выполняет сборку. Серьёзные получают полный человеческий разбор, потому что поверхность контролей на этом настаивает. Это разделение — автоматизировать рутину, направлять по-настоящему сложные случаи людям — и есть весь смысл.
Почему мы публикуем это как сценарий
Мы могли бы приукрасить это как историю успеха клиента с впечатляющим процентом в придачу. Мы не будем. Пока реальный, давший согласие клиент не поделится реальными результатами, всё, что мы здесь печатаем, — это иллюстрация, и мы предпочитаем честно её обозначить, чем намекать на доказательство, которого у нас нет.
Что реально, так это пак. Vendor Security — это устанавливаемый рабочий процесс на той же управляемой среде выполнения, что и любой другой пак Threada, с intent и пятью поверхностями, описанными выше. Если вы хотите увидеть исполняемую версию, а не разбор, каталог паков — это место, с которого стоит начать.