Партнёрская модель встраивания анализа инфраструктуры
Карта мультиоблачной и гибридной инфраструктуры, реальная связность и приоритетные риски — как часть вашего продукта или сервиса.
Для кого эта модель
Три типа партнёров с разными контурами ответственности и разными способами упаковать продукт под своих клиентов.
Встраивание анализа инфраструктуры и рисков в облачную линейку и сервисный портфель.
Услуга контроля конфигураций, связности и дрейфа для клиентов, размещающих инфраструктуру.
Использование движка Oasis Defender для анализа инфраструктуры и рисков в рамках собственных сервисов.
Что вы сможете продавать клиентам на базе Oasis
Примеры упаковываемых услуг и опций, которые провайдер может включать в линейку или добавлять как отдельный сервис.
Карта ресурсов и фактических путей доступа между сегментами, аккаунтами и средами.
Отслеживание изменений конфигураций и связности с выделением изменений, повышающих риск.
Список «что чинить первым» на основе фактической эксплуатируемости и путей доступа.
Материалы для ИТ/ИБ и данные для инженерных задач: инвентарь, правила, находки, изменения.
Фактическая картина инфраструктуры и рисков без ручной инвентаризации и сборов по командам.
Embedded / White-label
Oasis Defender работает как часть вашего продукта. Вы владеете отношениями с клиентом; мы обеспечиваем движок анализа и поддержку.
Как это выглядит для клиента
Варианты: white-label, co-branding или «powered by» (по договорённости). Доступ и отчётность интегрируются в ваш контур.
Границы ответственности
Партнёр: контракт, продажа, коммуникация, (опционально) первая линия. Oasis: движок анализа, обновления, методология, вторая линия и эскалации.
Развёртывание
Варианты зависят от вашей модели: выделенный инстанс, контур провайдера или другие варианты — фиксируются на этапе интеграции.
Подключение клиента
Read-only доступы к облачным аккаунтам, средам и сетевым компонентам, доступным через API. Список платформ и объём доступа уточняется под сценарий.
Что получает провайдер в эксплуатации
Базовые элементы операционного контура: снимки, диффы, уведомления о риск-изменениях и объяснимые приоритеты.
Снимки состояния
Регулярные снимки инфраструктуры и связности для сравнения и контроля изменений.
Дифф изменений
Список изменений с фокусом на рост риска: новые публичные точки входа, расширение правил, новые маршруты и сегменты.
Уведомления о риск-изменениях
При появлении опасных изменений в связности и сетевых правилах формируется уведомление назначенным ответственным — партнёра или клиента.
Отчёты и выгрузки
Материалы для ИТ/ИБ и данные для внутренних регламентов провайдера и задач клиента.
Объяснимые приоритеты
Аргументация «почему критично» на основе фактических путей доступа и эксплуатируемости. Каждая находка раскладывается через граф связности — без «чёрного ящика».
Коммерческая модель
Фиксируем принципы и варианты расчёта. Конкретные условия зависят от модели и масштаба — проговариваются в разговоре.
Wholesale / revenue share
Скидка провайдеру либо revenue share — в зависимости от white-label / co-branding и распределения ответственности.
Per tenant / account / environment
Чаще всего — на тенанта, аккаунт или среду. Выбор — под продуктовую упаковку провайдера.
Счёт идёт от провайдера
Как правило, счёт клиенту выставляет провайдер; Oasis работает как встроенный компонент.
Цифры — в разговоре
На странице остаётся только модель и принципы. Конкретика — под вашу модель и объём.
Поддержка и регламент взаимодействия
Цель — понятные эскалации в партнёрском контуре и стабильная работа коннекторов.
Каналы и эскалации
Единый канал партнёрской поддержки + правила эскалации. Состав участников и регламент согласуются на старте.
Согласованный SLA
Уровни реакции и окна сопровождения зависят от формата развёртывания и ответственности провайдера.
Совместимость коннекторов
Обновления и матрица совместимости ведутся централизованно; критичные изменения согласуются с партнёром.
Операционные изменения
Изменения в партнёрском контуре оформляются как регламент: кто инициирует, кто подтверждает, кто исполняет.
Co-delivery для MSSP и интеграторов
Партнёр ведёт проект и коммуникацию; Oasis обеспечивает движок анализа и методическую поддержку.
Delivery и итоговые материалы
Контракт, проект, коммуникация с клиентом, отчёты по своему методическому контуру. Первая линия поддержки клиента.
- Консалтинг и реагирование
- SOC-операции, пентесты
- Сводные отчёты для клиента
Движок анализа
Построение модели инфраструктуры, анализ связности, выявление эксплуатируемых рисков, контроль изменений. Вторая линия по платформам и коннекторам.
- Карта, риски, изменения, выгрузки
- Поддержка по данным и интерпретации
- Эскалации по модели
Oasis Defender отвечает за построение единой модели инфраструктуры, анализ связности, выявление реально эксплуатируемых рисков и контроль изменений. MSSP-компания или интегратор использует эти данные в рамках собственных процессов — консалтинг, реагирование, SOC-операции, пентесты и другие услуги в своей зоне ответственности. Oasis Defender не заменяет SOC / MSSP / SIEM и является источником фактических данных для принятия решений.
FAQ для партнёров
Шесть пунктов, которые обычно нужно закрыть перед тем, как двигаться к пилоту.
P.01 Где размещается решение и где хранятся данные?
Зависит от модели развёртывания и требований партнёра. Конкретный вариант — выделенный инстанс, контур провайдера или иной — фиксируется на этапе интеграции.
P.02 Какие доступы требуются для подключения клиента?
Read-only доступы к облачным платформам, средам и сетевым компонентам, доступным через API. Детализация — в чеклисте подключения, под конкретный набор облаков.
P.03 Как часто обновляются данные и как настраивается периодичность анализа?
Периодичность определяется конфигурацией и зависит от подключённых платформ, масштаба инфраструктуры и лимитов API. Поддерживается регулярный пересбор модели и отслеживание drift между состояниями; параметры обновления согласуются при внедрении.
P.04 Как обеспечивается изоляция между клиентами?
Механизм изоляции зависит от формата развёртывания. В embedded-модели это часть архитектуры партнёрского контура и согласуется до запуска.
P.05 Как выглядит white-label / co-branding на практике?
Варианты брендинга и глубина интеграции согласуются в рамках embedded-модели. От «powered by» до полного white-label — в зависимости от продукта и контракта.
P.06 Что входит в поддержку?
Поддержка коннекторов, обновления, эскалации по анализу и совместимости. SLA и регламент зависят от модели развёртывания и ответственности провайдера.
Поддерживаемые платформы
Мультиоблачные и гибридные архитектуры в единой модели.
Готовы обсудить партнёрство?
Расскажите о своём продукте и контуре — вернёмся с конкретной моделью встраивания, форматом развёртывания и границами поддержки.