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

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

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

Запросить демо Вернуться к главной
Результат
Карта Топ‑риски Отчёты Уведомления изменений
Доступ и агенты
Read-only Не требуются
Пайплайн анализа
  • Сбор инвентаря и политик
  • Нормализация в единую модель
  • Граф связности и пути доступа
  • Риск‑модель и отчёты
  • Контроль изменений и дрейфа инфраструктуры

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

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

Карта инфраструктуры
Наглядная топология ресурсов и связей, включая видимость из внешней сети и ключевые переходы между сегментами
Топ‑риски
Приоритетные риски с объяснением «почему критично» и «что закрыть в первую очередь»
Отчёты и выгрузки
Материалы для ИТ/ИБ и руководства + табличные данные для аудита и инженерных задач (инвентарь, правила, находки)
Контроль изменений и дрейфа
Сохраняем снимки состояния и отслеживаем изменения ресурсов, правил доступа и связности; выделяем изменения, которые повышают риск (новые публичные входы, расширенные правила, новые пути доступа)
Уведомления и контроль
Уведомляем о значимых изменениях, чтобы реагировать на риск до инцидента или аудита, а не постфактум

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

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

Запросить демо

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

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

Критерии

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

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

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

Фокус: только практическая эксплуатируемость и последствия. Нерелевантный шум отсекается

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

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

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

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

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

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

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

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

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

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

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

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

Данные

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

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

  • Внешняя поверхность: что реально доступно из интернета и почему
  • Пути внутри: возможны ли латеральные перемещения между сегментами/сервисами
  • Межоблачная связность: как связаны ресурсы в разных облаках/средах в одной картине
  • Изменения: какие новые входы/пути появились после изменений

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

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

Read‑only

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

Изоляция

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

VMware
Apache CloudStack
OpenStack
Yandex Cloud
AWS
Microsoft Azure
DigitalOcean
Huawei