Описание продукта

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

Техническое описание: как Oasis Defender собирает данные из разных облаков и частных сред, строит модель связности и получает приоритетные риски и отчёты.

Сбор через API без агентов и без изменений в инфраструктуре, единая модель мультиоблачной и гибридной связности, приоритизация реально эксплуатируемых рисков и контроль изменений.

ДоступRead-only API
АгентыНе требуются
РазвёртываниеВ контуре заказчика
РезультатКарта · Риски · Отчёты · Drift
01 · Пайплайн
5 ШАГОВ

Пайплайн анализа

От подключения до контроля изменений — единый процесс, в котором каждый шаг детерминирован и объяснимым образом приводит к результату.

01

Сбор

Инвентаря и политик из облачных API и сред виртуализации

02

Нормализация

Приведение сущностей разных платформ к единой модели

03

Граф связности

Реальные пути доступа и зоны достижимости между средами

04

Риск-модель

Приоритеты с объяснением «почему критично» и «что чинить»

05

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

Дрейф инфраструктуры и уведомления о значимых изменениях

02 · Результат
DELIVERABLES · SPEC

Что вы получаете

Мультиоблачная инфраструктура — в одной модели. Результат можно использовать как для инженерной работы, так и для контроля со стороны ИБ и руководства.

01
Карта инфраструктуры
Наглядная топология ресурсов и связей, включая видимость из внешней сети и ключевые переходы между сегментами
02
Топ-риски
Приоритетные риски с объяснением «почему критично» и «что закрыть в первую очередь»
03
Отчёты и выгрузки
Материалы для ИТ/ИБ и руководства + табличные данные для аудита и инженерных задач (инвентарь, правила, находки)
04
Контроль изменений и дрейфа
Сохраняем снимки состояния и отслеживаем изменения ресурсов, правил доступа и связности; выделяем изменения, которые повышают риск (новые публичные входы, расширенные правила, новые пути доступа)
05
Уведомления и контроль
Уведомляем о значимых изменениях, чтобы реагировать на риск до инцидента или аудита, а не постфактум
cloud-map / overviewКарта
Карта инфраструктуры
Топология ресурсов и связей в едином окне
security-analysis / findingsРиски
Приоритизация рисков
Группировка и приоритизация находок
03 · Приоритизация
КРИТЕРИИ · ОБЪЯСНИМОСТЬ

Как приоритизируется риск

Цель — не «нашли много проблем», а «что нужно чинить в первую очередь и почему».

Критерии

  • Достижимость: существует ли реальный разрешённый путь до цели (а не просто «подозрительное правило»)
  • Последствия: масштаб последствий (зона влияния) и влияние на критичные сервисы/данные
  • Исправляемость: насколько быстро и безопасно закрывается (узкий фикс vs. большой рефакторинг)
  • Ответственность: кому адресовать действие (команда/владелец/подрядчик) — чтобы риск не «повисал»

Объяснимость

Каждая находка должна быть «рассказуемой» через модель связности: источник пути, промежуточные узлы, правила и границы сегментов. Это снижает споры между ИТ и ИБ и ускоряет фиксы.

Фокус: только практическая эксплуатируемость и последствия. Нерелевантный шум отсекается.
04 · Архитектура
4 МОДУЛЯ

Архитектура и модули

Четыре уровня архитектуры: объяснимая логика и переносимость между провайдерами.

Layer 01

Коннекторы (read-only)

Подключаем облако/среду и забираем инвентарь и политики безопасности через API. Сбор строится так, чтобы не требовать агентов и не менять конфигурации

Layer 02

Нормализация

Приводим сущности разных платформ к общей семантике: ресурсы, сети, правила, маршруты, публичность/приватность, зоны/сегменты

Layer 03

Граф инфраструктуры

Строим единую модель связности (ресурсы + связи). На ней считаются реальные пути доступа и зоны достижимости, включая межоблачные переходы

Layer 04

Риски и отчёты

Из графа и политик получаем находки, группируем и приоритизируем. Выдаём карту, топ-риски и отчёты/выгрузки для ИТ, ИБ и руководства, включая контроль изменений и дрейфа

05 · Модель
DATA · QUERIES

Единая модель

Используемые типы данных для достоверных ответов на вопросы «кто куда может дойти» и «что критичнее чинить».

Данные

  • Инвентарь ресурсов: VM/инстансы, сети/подсети, балансировщики, NAT/шлюзы, публичные адреса
  • Сетевые политики: security groups / firewall rules / ACL, вход/выход, Any-Any, опасные порты, исключения
  • Топология и маршруты: attachments, route tables, peering/VPN/tunnels (где применимо)
  • Контекст: теги/проекты, окружения, владельцы/команды, критичность сервисов

Вопросы, на которые отвечаем

  • Внешняя поверхность: что реально доступно из интернета и почему
  • Пути внутри: возможны ли латеральные перемещения между сегментами/сервисами
  • Межоблачная связность: как связаны ресурсы в разных облаках/средах в одной картине
  • Изменения: какие новые входы/пути появились после изменений
policy-map / segmentsГраф
Граф связности и пути доступа
Реальные пути доступа между сегментами и средами
06 · Доступ
SECURITY MODEL

Модель доступа и безопасность

Принципы доступа и работы с данными: минимальные права, изоляция и прозрачная ответственность.

Принцип

Read-only

Сбор выполняется через API с правами чтения. Продукт не требует агентов и не вмешивается в прод-нагрузку

Принцип

Изоляция

Данные разных организаций/проектов должны быть логически и технически изолированы (это ключевой шаг на пути к multi-tenant)

Принцип

Роли и кабинет

Разделение доступа: ИТ, ИБ, руководство, подрядчики. Видимость ограничивается по проектам/аккаунтам и типам данных

Принцип

Аудитный след

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

07 · Границы
SCOPE · ASSUMPTIONS

Ограничения и допущения

Осознанные архитектурные границы продукта. Это не «недоделки», а фокус.

×

Мы не выполняем изменения автоматически

Oasis Defender не вносит изменения в инфраструктуру. Все рекомендации реализуются инженерами заказчика осознанно и под контролем

×

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

Продукт не заменяет firewall, WAF, EDR или IAM. Он дополняет их, показывая реальную связность и приоритеты рисков

×

Мы не анализируем уязвимости ПО

Фокус — конфигурация, сети и пути доступа. Поиск CVE и уязвимостей приложений находится за пределами текущей модели

×

Мы не анализируем локальные настройки серверов

Мы не анализируем локальные настройки виртуальных и физических серверов (ОС, сервисы, конфигурации приложений). Анализ строится исключительно на данных, доступных через API облачной платформы или среды виртуализации

Больше ответов на вопросы в нашем FAQ
08 · Roadmap
FUTURE

Целевое развитие продукта

Целевое развитие Oasis Defender на основе текущей архитектуры и запросов рынка. Эти возможности находятся в разной стадии проработки.

  • Платформа

    Мульти-тенант архитектура

    Развитие в сторону изоляции данных по организациям, проектам и средам. Это позволит использовать продукт как сервис для MSSP, интеграторов и холдингов с несколькими контурами и заказчиками

  • UX

    Роли и представления

    Разграничение доступа и интерфейсов для ИТ, ИБ, руководства и подрядчиков: технические детали для инженеров, приоритеты и статус — для ИБ, агрегированная картина — для управленческого уровня

  • Workflow

    Жизненный цикл риска

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

  • Integrations

    Интеграции с экосистемой

    Интеграции с CMDB, системами управления задачами и средствами ИБ для встраивания анализа связности и рисков в существующие процессы заказчика

  • Analytics

    Расширенная аналитика

    Развитие аналитики поверх графа связности: моделирование сценариев атак, оценка масштаба последствий и анализ влияния изменений до их внедрения

09 · Платформы
CONNECTORS

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

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

AWS
Microsoft Azure
Yandex Cloud
DigitalOcean
Huawei Cloud
OpenStack
VMware
Apache CloudStack

Проверить на своей инфраструктуре

Пилот в ограниченном контуре: подключим read-only доступы, построим карту связности и покажем приоритетные риски для вашей среды.