Назад НОТА · Купол. Контейнеры

Единая точка управления безопасностью для DevOps-инженеров

Спроектировал с нуля отечественную систему защиты контейнерных сред. Фичи рождались не из ТЗ, а из задач инженеров: от интервью до 250+ экранов.

Роль: Ведущий продуктовый дизайнер
Команда: ~18 человек, Scrum, спринты по 2 недели
Домен: B2B, информационная безопасность
Платформы: Web + мобильная адаптация

Результаты

−25%

время обработки уязвимостей и рисков

+18%

завершённость сценария: пошаговая настройка политик против единой формы

250+

экранов, из них 120+ страниц десктопа с мобильной адаптацией

40+

сценариев с ролевыми доступами и связанными сущностями

«Купол. Контейнеры» защищает всё, из чего состоит контейнерная платформа: образы, реестры, оркестраторы, контейнеры и ОС хоста — на всём цикле разработки ПО.

Раньше такие решения делали в основном иностранные вендоры. Компании получали регуляторные риски (ФСТЭК, CIS), непрозрачность и невозможность что-то настроить под себя. Цель бизнеса — заменить зарубежные решения и дать инженерам одно место для контроля уязвимостей, политик и конфигураций.

DevOps-инженерВедёт несколько кластеров и проектов, ценит скорость и надёжность

Смежные ролиSecOps, аналитик, архитектор

СтандартыФСТЭК и CIS Benchmark прямо в интерфейсе

10 разделов продуктаот мониторинга до администрирования

01ДашбордыСводка по рискам в настраиваемых виджетах
02Карта сетиКластеры, узлы, контейнеры и связи между ними
03УязвимостиНайденные уязвимости в образах и контейнерах, с критичностью и ответственными
04КомплаенсПроверки на соответствие ФСТЭК и CIS Benchmark
05АудитЖурнал событий и действий пользователей
06Принятые рискиУязвимости, которые команда осознанно оставила, с обоснованием и сроком
07ПолитикиПравила безопасности: глобальные и локальные
08НастройкиПодключение кластеров, реестров и интеграций
09АдминистраторПользователи, роли и доступы
10База знанийСправка по проверкам и работе с продуктом

Я был ведущим дизайнером продукта. Моя задача была не рисовать интерфейс по ТЗ, а сформировать структуру будущих фич через логику пользователя.

Исследования. Проблемные интервью с DevOps, JTBD, бенчмаркинг, A/B-тесты, проверка гипотез
Архитектура. Информационная архитектура продукта, юзкейсы, CJM и флоу
Команда. Работал в связке с PO, аналитиками, фронтенд- и бэкенд-разработчиками, QA, DevOps и архитектором. Каждое утро синхронизировались на дейликах, задачи вели в Jira, требования и спецификации — в Confluence.
Дизайн-система. Работал на большой системе со спецификациями; мои локальные компоненты потом вошли в неё
Мобильная версия. Адаптация десктопа под телефон: таб-бар, горизонтальный скролл таблиц, полноэкранные панели

У DevOps-инженеров не было единого инструмента безопасности. Приходилось держать несколько программ и вручную проверять каждую систему.

Сложная область. Что-то среднее между DevOps, ИБ и администрированием: политики, кластеры, CI/CD
Нет опоры. Не редизайн и не старая система — флоу нужно было придумать с нуля
Масштаб. 40+ сценариев, роли, взаимосвязанные сущности, динамическая визуализация
Цена ошибки. Нельзя дать пользователю случайно отключить политику безопасности

Гипотеза

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

На старте были только предварительные требования бизнеса и гипотезы команды. Структуру продукта я собрал из поведения пользователей.

Глубинные интервью с DevOps. Как сейчас работают с безопасностью, где сложно, что фрустрирует
Job stories. Задачи, которые инженер решает в своём процессе
Декомпозиция в фичи и сценарии. Каждая фича отвечает на конкретную job story
CJM и флоу. Согласование с командой и итерации: алерты, политики, роли, уведомления, фильтры, дашборды

«Когда я замечаю критическую уязвимость, я хочу быстро понять, где она, и назначить ответственного, чтобы снизить риск для продакшена»

Job story в интерфейсе: из списка уязвимостей инженер открывает карточку — уровень опасности, принятые риски, затронутые образы и факторы риска — и переходит к подробному описанию из БДУ ФСТЭК и NVD.

Разобрал зарубежные CI/CD- и Kubernetes-инструменты, к которым инженеры уже привыкли: навигацию, подачу данных, алерты, настройку политик.

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

Решение: взял паттерны, к которым привыкли инженеры, но упростил язык и навигацию. Так снизился порог входа и сократился онбординг.

Мои пометки на интерфейсах конкурентов: зелёным — что забрал, красным — чего избегал.

Карта сети: топология кластера по пространствам имён, клик по поду открывает его детали — статус, ноду, контейнеры и порты. Термины Kubernetes оставлены на английском.

Комплаенс: стандарты CIS, лучшие практики Docker, PCI DSS и NIST во вкладках — как в привычных инженерам зарубежных инструментах.

На интерактивных прототипах прогонял ключевые сценарии: настройку политик, назначение ролей, реакцию на угрозы.

Люди не понимали последствий удаления и редактирования политик — добавил подтверждения и статусы
Назначение ролей было непрозрачным — добавил карточки ролей и превью доступов
Лишние шаги и сложные формулировки — переработал последовательность и упростил терминологию

В A/B-тесте сравнил два способа настроить политику безопасности:

Единая форма

базовый уровень

Пошаговая

+18% завершённость

Сетевые политики: из списка — в конструктор, где правила собираются полями и селекторами, и одним переходом — в редактор кода для тех, кому привычнее YAML. Валидация показывает ошибку до применения.

Администратор: роль открывается карточкой с превью доступов — видно, к каким разделам у роли есть доступ, ещё до сохранения.

Гипотезы: по одной, с проверкой

Каждую доработку я оформлял гипотезой: проблема, вариант реализации, макет «сейчас / гипотеза», прототип и ссылки на исследования. Гипотезы вели в общей базе со статусами, так команда видела, что уже проверено, а что в работе.

Слева текущий вариант, справа гипотеза с поиском. Данные образов скрыты.

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

Путали глобальные и локальные политики — развёл их визуально и вынес в табы
Хотели гибкий дашборд — добавил настройку виджетов, пресеты и собственные страницы
Часть сценариев была избыточной — упростил логику и убрал шаги

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

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

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

Что изменилось	Как добились	Эффект
Обработка уязвимостей	Новая логика алертов и навигации	−25% времени
Настройка политик	Пошаговый сценарий по итогам A/B	+18% завершённость
Ошибки в политиках и ролях	Подтверждения, валидация, статусы, превью	Меньше ошибок конфигурации
Поддержка	Подсказки и понятные флоу	Реже вопросы про доступы и политики
Миграция с зарубежных решений	Знакомая структура, адаптированные термины	Комфортный переход для команд

На пилоте пользователи говорили, что «работать стало проще и спокойнее».

Мобильная версия

Я спроектировал и мобильную адаптацию: 120+ страниц десктопа адаптированы под телефон. Навигация переехала в нижний таб-бар с кнопкой «Ещё», таблицы стали скроллиться по горизонтали с закреплённым первым столбцом, боковые панели — полноэкранными.

Политики Kyverno — Экраны мобильной версии, 375 px. Нажмите, чтобы рассмотреть целиком.

Отчёты Kyverno — Экраны мобильной версии, 375 px. Нажмите, чтобы рассмотреть целиком.

Дашборды — Часть из 250+ экранов продукта. Нажмите, чтобы рассмотреть. Данные в макетах тестовые.

Карта сети — Часть из 250+ экранов продукта. Нажмите, чтобы рассмотреть. Данные в макетах тестовые.

JTBD — это не методика ради методики. Он дал продукту приоритеты: что делать, зачем и как этим будут пользоваться
В безопасности упрощать нужно осторожно. Удобство не должно открывать дорогу опасному действию
Привычное важнее нового. Знакомые паттерны снимают страх перехода на отечественный продукт

Смотрите также