Ответы на технические и организационные вопросы

Подключаем облачные среды и частные виртуализации по read-only API, нормализуем данные в единую модель, строим граф связности и показываем приоритетные риски с объяснением «почему критично» и «что закрыть в первую очередь».

Обоим. ИТ получает наглядную карту своей инфраструктуры через несколько облаков и сред, ИБ — приоритетные риски и контроль изменений. Руководство видит агрегированную картину для отчётности и принятия решений.

Фокус на реальной связности, а не на статических чек-листах конфигурации. Мы собираем данные из разных облаков и частных сред в единую модель и показываем достижимость и последствия. Это работает в мультиоблачном и гибридном контуре, в том числе с российскими провайдерами и частными виртуализациями.

• Не вносим изменения в инфраструктуру автоматически
• Не подменяем firewall, WAF, EDR или IAM
• Не ищем CVE и уязвимости в коде приложений
• Не анализируем локальные настройки ОС и сервисов

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

AWS, Microsoft Azure, Yandex Cloud, DigitalOcean, Huawei Cloud, OpenStack, VMware, Apache CloudStack. Поддерживаются мультиоблачные и гибридные конфигурации в одной модели. Список расширяется по запросам пилотов.

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

Типично — от нескольких часов до 1–2 дней на один контур. Основное время уходит на согласование и выпуск read-only сервисных аккаунтов на стороне заказчика; сама интеграция технически быстрая.

Только чтение инвентаря и сетевых политик: ресурсы, сети/подсети, security groups / firewall rules, маршруты, балансировщики, NAT/шлюзы, публичные адреса. Минимально достаточный набор согласовывается под конкретного провайдера.

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

На этапе пилота и типичного внедрения Oasis Defender разворачивается в контуре заказчика. Данные не покидают вашу инфраструктуру. SaaS-режим в дорожной карте — с изоляцией данных по организациям и проектам.

Метаданные конфигурации: ресурсы, сетевые политики, маршруты, теги, владельцы. Никаких пользовательских данных, трафика и содержимого приложений мы не трогаем — это вне модели продукта.

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

Нет. Все права — только на чтение. Никаких автоматических изменений, скриптов или агентов в инфраструктуре. Все рекомендации реализуются инженерами заказчика осознанно и под контролем.

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

По четырём осям:

• Достижимость — есть ли реальный разрешённый путь
• Последствия — масштаб и влияние на критичные сервисы
• Исправляемость — узкий фикс vs большой рефакторинг
• Ответственность — кому адресовать действие

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

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

Да. Готовим материалы для ИТ/ИБ и руководства, плюс табличные выгрузки для аудита и инженерных задач — инвентарь, правила, находки. Форматы согласовываются под процесс заказчика.

Да. Граф связности учитывает peering, VPN и туннели между облаками и частными средами там, где они применимы. Это даёт цельную картину, а не «зоопарк» из отдельных консолей.

Разворачивается в контуре заказчика — физический сервер, ВМ или управляемый Kubernetes. Минимальные требования по ресурсам обсуждаются под объём инфраструктуры, обычно это нескольких CPU и несколько ГБ RAM на старте.

Зависит от того, какие облака подключаются. Для облачных провайдеров нужен исходящий доступ к их API. Для частных виртуализаций (OpenStack, VMware, CloudStack) достаточно сетевого доступа внутри контура.

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

Стоимость зависит от объёма инфраструктуры, числа подключаемых сред и модели использования (внутренний инструмент vs сервисная модель). Пилот в ограниченном контуре — по договорённости. Напишите — подберём вариант.

Команда инженеров с опытом облачной инфраструктуры и информационной безопасности. Юридически — ООО «Система», ИНН 6234190118.

На время пилота с вашей стороны выделяется ИТ/ИБ-контакт. С нашей — инженер сопровождения и продуктовый куратор. Подключение, настройка коннекторов и разбор находок проходят совместно, в удобном канале.

Да. Multi-tenant архитектура и разграничение по организациям — направление, которое мы развиваем для интеграторов и холдингов с несколькими контурами и заказчиками.

Telegram: @OasisDefenderBot
E-mail: info@oasisdefender.ru

Или нажмите кнопку ниже — мы ответим в течение рабочего дня.