Единая карта мультиоблачной инфраструктуры и рисков.
Партнёрская модель

Agent‑less, read‑only анализ мультиоблачной и гибридной инфраструктуры: единая карта, реальная связность и приоритетные риски - как часть вашего продукта.

Для кого эта модель

Облачные провайдеры IaaS‑провайдеры VPS‑провайдеры

Встраивание анализа инфраструктуры и рисков в облачную линейку и сервисный портфель.

Хостеры ЦОД Managed services

Услуга контроля конфигураций, связности и дрейфа для клиентов, размещающих инфраструктуру.

MSSP-компании Интеграторы

MSSP-компании, консалтинг и интеграционные компании: использование движка Oasis Defender для анализа инфраструктуры и рисков в рамках собственных сервисов.

Что вы сможете продавать клиентам на базе Oasis

Примеры упаковываемых услуг/опций, которые провайдер может включать в продуктовую линейку

Анализ инфраструктуры и связности

Карта ресурсов и фактических путей доступа между сегментами, аккаунтами и средами.

Контроль изменений и дрейфа

Отслеживание изменений конфигураций и связности с выделением изменений, повышающих риск.

Приоритизация исправлений

Список «что чинить первым» на основе фактической эксплуатируемости и путей доступа.

Отчётность и выгрузки

Материалы для ИТ/ИБ и данные для инженерных задач: инвентарь, правила, находки, изменения.

Подготовка к проверкам и аудитам

Фактическая картина инфраструктуры и рисков без ручной инвентаризации и сборов по командам.

Embedded / White‑label

Oasis Defender работает как часть вашего продукта. Вы владеете отношениями с клиентом; мы обеспечиваем движок анализа и поддержку

Как это выглядит для клиента

Варианты: white‑label, co‑branding или «powered by» (по договорённости). Доступ и отчётность интегрируются в ваш контур.

Границы ответственности

Партнёр: контракт, продажа, коммуникация, (опционально) первая линия. Oasis: движок анализа, обновления, методология, вторая линия/эскалации.

Развёртывание

Варианты зависят от вашей модели: выделенный инстанс / контур провайдера / другие варианты - фиксируются на этапе интеграции.

Подключение клиента

Read‑only доступы к облачным аккаунтам/средам и сетевым компонентам, доступным через API. Список платформ и объём доступа уточняется под сценарий.

Что получает провайдер в эксплуатации

Модель рассчитана на регулярный контроль, а не на разовый отчёт. Ниже - базовые элементы операционного контура

Снимки состояния

Регулярные снимки инфраструктуры и связности для сравнения и контроля изменений.

Дифф изменений

Список изменений с фокусом на рост риска: новые публичные сетевые точки входа (порты/эндпоинты), расширение правил (CIDR/SG), новые маршруты и сегменты связности.

Уведомления о риск-изменениях

При появлении опасных изменений в связности и сетевых правилах (новые публичные точки входа, расширение доступа, новые маршруты) формируется уведомление назначенным ответственным со стороны партнёра или клиента.

Отчёты и выгрузки

Материалы для ИТ/ИБ и данные для внутренних регламентов провайдера и задач клиента.

Объяснимые приоритеты

Аргументация «почему критично» на основе фактических путей доступа и эксплуатируемости.

Коммерческая модель

Фиксируем принципы и варианты расчёта. Конкретные условия зависят от модели и масштаба

Формат расчёта

Варианты: wholesale/скидка провайдеру или revenue share - в зависимости от white‑label/co‑branding и ответственности.

Единица тарификации

Чаще всего: per tenant / per account / per environment. Выбор - под продуктовую упаковку провайдера.

Выставление счёта

Как правило, счёт клиенту выставляет провайдер; Oasis работает как встроенный компонент.

Границы публичности

Цифры и конкретика - в разговоре. На странице остаётся только модель и принципы.

Поддержка и регламент взаимодействия

Цель - предсказуемая эксплуатация и понятные эскалации в партнёрском контуре

Каналы и эскалации

Единый канал партнёрской поддержки + правила эскалации. Состав участников и регламент согласуются на старте.

Согласованный SLA

Уровни реакции и окна сопровождения зависят от формата развёртывания и ответственности провайдера.

Совместимость коннекторов

Обновления и матрица совместимости ведутся централизованно; критичные изменения согласуются с партнёром.

Операционные изменения

Изменения в партнёрском контуре оформляются как регламент (кто инициирует, кто подтверждает, кто исполняет).

Co‑delivery для MSSP/интеграторов

Партнёр ведёт проект и коммуникацию; Oasis обеспечивает движок анализа и методическую поддержку

Роли

Партнёр: delivery и итоговые материалы. Oasis: построение модели/анализа и поддержка по вопросам данных и интерпретации.

Результаты

Карта, риски, изменения и выгрузки используются в отчётах партнёра и в процессе улучшений у клиента.

Эскалации

Партнёр - первая линия для клиента, Oasis - вторая линия по платформам, коннекторам и модели.

Границы ответственности

Oasis Defender отвечает за построение единой модели инфраструктуры, анализ связности, выявление реально эксплуатируемых рисков и контроль изменений. MSSP-компания или интегратор использует эти данные в рамках собственных процессов: консалтинг, реагирование, SOC-операции, пентесты и другие услуги в своей зоне ответственности. Oasis Defender не заменяет SOC/MSSP/SIEM и является источником фактических данных для принятия решений.

FAQ для партнёров

Только вопросы, которые обычно блокируют решение о партнёрстве

Где размещается решение и где хранятся данные?

Зависит от модели развёртывания и требований партнёра. Конкретный вариант фиксируется на этапе интеграции.

Какие доступы требуются для подключения клиента?

Read‑only доступы к облачным платформам/средам и сетевым компонентам, доступным через API. Детализация - в чеклисте подключения.

Как часто обновляются данные и как настраивается периодичность анализа?

Периодичность определяется конфигурацией и зависит от подключённых платформ, масштаба инфраструктуры и лимитов API. Oasis Defender поддерживает регулярный пересбор модели и отслеживание drift между состояниями; параметры обновления согласуются при внедрении.

Как обеспечивается изоляция между клиентами?

Механизм изоляции зависит от формата развёртывания. В embedded‑модели это часть архитектуры партнёрского контура.

Как выглядит white‑label/co‑branding на практике?

Варианты брендинга и глубина интеграции согласуются в рамках embedded‑модели.

Что входит в поддержку?

Поддержка коннекторов, обновления, эскалации по анализу и совместимости. SLA и регламент зависят от модели.

Поддерживаемые платформы

Мультиоблачные и гибридные архитектуры в единой модели

VMware
Apache CloudStack
OpenStack
Yandex Cloud
AWS
Microsoft Azure
DigitalOcean
Huawei