Современные облачные среды строятся вокруг сервисов, но определяющий их контекст — то, что они включают, кто ими владеет и как они должны управляться — часто рассредоточен по облачным платформам, тегам, порталам разработчиков и CMDB. Wiz Service Catalog объединяет этот контекст, упрощая реагирование на инциденты безопасности за счет связывания облачных ресурсов и рисков с сервисами, командами и владельцами, которые за них отвечают.
С момента выпуска Service Catalog для общего доступа (GA) мы продолжаем инвестировать в помощь организациям по объединению рабочих процессов разработчиков и специалистов по безопасности с помощью единой сервисно-ориентированной видимости. Теперь мы делаем еще один шаг вперед в развитии Service Catalog, предлагая множество новых и планируемых возможностей обнаружения, интеграций, элементов управления состоянием безопасности, дашбордов и шаблонов рабочих процессов, которые помогают командам переходить от фрагментированных метаданных к общей и практической операционной модели безопасности облаков и ИИ.
Создавайте свой каталог быстрее
Первая задача заключается в том, чтобы превратить уже имеющиеся у организации метаданные в живую модель ее сервисов. Для этого требуется задействовать существующие порталы разработчиков, CMDB, соглашения о тегировании и граф связей без необходимости для команд воссоздавать их вручную.
Для команд, управляющих определениями сервисов на порталах разработчиков, функция синхронизации каталога программного обеспечения Backstage Software Catalog Sync переносит описания сервисов, этапы жизненного цикла, теги и привязку владельцев в Wiz, сохраняя при этом иерархию, к которой привыкли разработчики. Предстоящая интеграция с ServiceNow CMDB предоставит аналогичный путь для организаций, использующих ServiceNow в качестве системы учета, помогая поддерживать синхронизацию информации о сервисах между специалистами по безопасности и ИТ-операциям.
Для облачно-нативных рабочих нагрузок создание полного каталога не должно зависеть от созданных вручную статических правил или 100% соответствия требованиям тегирования. Динамические правила обнаружения (релиз в Q4) будут анализировать реальные шаблоны тегирования в среде, извлекать доминирующие ключи идентификации сервисов (такие как app, service или компонент) и динамически формировать границы приложений. Это избавляет от необходимости обслуживать правила, позволяет на лету адаптироваться к несоответствиям в именовании и дает командам приложений возможность самостоятельно контролировать свой уровень безопасности с первого дня.
Тем не менее, не в каждой среде ресурсы тегируются последовательно. Сетевые правила включения автоматически устраняют разрыв между статическими облачными активами и реальным поведением во время выполнения. Они используют сетевой трафик в реальном времени и телеметрию облачных событий для идентификации каждой базы данных, хранилища и службы обмена сообщениями, с которыми фактически взаимодействует приложение, динамически сопоставляя их в качестве связанных ресурсов (Related Resources) в Service Catalog. Это означает, что команды безопасности и владельцы сервисов получают точную картину реального радиуса поражения своего приложения в реальном времени, не требуя от разработчиков обновления тегов и не полагаясь на устаревшие схемы архитектуры.
Наконец, позднее в этом году мы также расширим возможности обнаружения и обслуживания сервисов, включая возможность создания сервисов из невычислительных ресурсов, таких как бакеты, базы данных, управляемые/ИИ-сервисы, CDN и многое другое. В совокупности эти возможности не только помогают командам создавать более полный каталог с меньшими затратами на ручное сопоставление, но и поддерживают его соответствие облаку по мере его эволюции.
Оптимизация работы сервисов с помощью новых политик безопасности
Маппинг сервисов — это только начало. Составы владельцев меняются, развертываются новые ресурсы, а приложения эволюционируют. Без постоянного контроля производственный сервис может остаться без владельца, новое приложение может быть запущено без привязки к проекту, а информация о сервисе может незаметно устареть.
Политики состояния сервисов (Service Posture Policies) предоставляют командам возможность определять и применять стандарты конфигурации и владения сервисами. Например, организация может потребовать, чтобы у каждого производственного сервиса был владелец или чтобы каждый сервис был назначен на проект Wiz.
Wiz автоматически создает и закрывает проблемы соответствия (Posture Issues), когда сервисы переходят в состояние соответствия требованиям или нарушают их. Это превращает гигиену сервисов из периодической уборки в непрерывный проверяемый процесс и помогает командам выявлять пробелы по мере их появления.
Благодаря четким стандартам и непрерывной оценке организации могут поддерживать свои каталоги сервисов точными, актуальными и соответствующими тому, как функционируют их облачные среды сегодня.
Понимайте каждый сервис в контексте
Точное определение владельцев создает надежный фундамент. Следующий шаг — объединение контекста безопасности, комплаенса и операционной деятельности, необходимого командам для понимания каждого сервиса как единого целого:
- Service Threats: Connect complex, multi-resource detection chains to the affected Service. When Wiz detects activities like lateral movement, privilege escalation, or data exfiltration, SOC analysts immediately see which business service and team are impacted, accelerating triage and incident routing.
Угрозы сервисам (Service Threats): связывайте сложные цепочки обнаружения, охватывающие множество ресурсов, с затронутым сервисом. Когда Wiz обнаруживает такие действия, как латеральное перемещение (lateral movement), эскалация привилегий или эксфильтрация данных, аналитики SOC немедленно видят, какой бизнес-сервис и какая команда затронуты, что ускоряет триаж и маршрутизацию инцидентов.
- Service-Level Identity Security: Bring full identity entitlements and non-human identity (NHI) analysis to the service level. Teams can map IAM roles, service accounts, and API keys directly to the services they power, making it easy to identify excessive permissions, toxic combinations, and credential exposure across service boundaries.
Безопасность идентификационных данных на уровне сервисов (Service-Level Identity Security): перенесите полный анализ прав доступа и нечеловеческих учетных записей (NHI) на уровень сервисов. Команды могут сопоставлять роли IAM, сервисные аккаунты и ключи API непосредственно с поддерживаемыми ими сервисами, что упрощает выявление избыточных разрешений, токсичных комбинаций и утечки учетных данных через границы сервисов.
- Secure Architecture Opportunities with WizOS: Surface container image migration opportunities directly to service owners, giving development teams a clear, prioritized path to harden their services from the build up.
Возможности безопасной архитектуры с WizOS (Secure Architecture Opportunities with WizOS): сообщайте владельцам сервисов о возможностях миграции образов контейнеров напрямую, предоставляя командам разработки четкий и приоритетный путь для укрепления безопасности своих сервисов, начиная с этапа сборки.
- Service Compliance: Deliver real-time compliance posture scores for frameworks such as CIS, SOC 2, and PCI DSS, scoped specifically to the assigned resources within each Service.
Комплаенс сервисов (Service Compliance): предоставляйте показатели соответствия требованиям в реальном времени для таких стандартов, как CIS, SOC 2 и PCI DSS, с областью действия, ограниченной конкретно назначенными ресурсами в рамках каждого сервиса.
- Wiz Cloud Cost: Bring financial context alongside security risk by breaking down cloud spend and optimization opportunities at the service level, enabling SecOps, Platform, and FinOps teams to work from a single pane of glass.
Облачные затраты Wiz (Wiz Cloud Cost): объединяйте финансовый контекст с рисками безопасности, детализируя расходы на облако и возможности оптимизации на уровне сервисов, что позволяет командам SecOps, Platform и FinOps работать в рамках единого интерфейса.
Кроме того, мы продолжаем углублять видимость ИИ во всех сервисах. Например, по мере того как команды развертывают генеративный ИИ и автономных агентов, Wiz автоматически идентифицирует и каталогизирует компоненты ИИ, включая ИИ-агентов PaaS (AWS Bedrock, Azure OpenAI), базовые модели, серверы MCP и наборы данных ИИ. Команды безопасности могут мгновенно отфильтровывать сервисы на базе ИИ, проводить аудиты идентификационных данных агентов и управлять потоками конфиденциальных данных в рабочих нагрузках ИИ.
Вместо того чтобы исследовать ресурсы изолированно, команды могут получить полное представление о сервисе: что он в себя включает, кто им владеет, как он соответствует организационным стандартам, где он подвержен рискам и чему следует уделить внимание.
Превратите владение в действие
Вся эта контекстная информация сходится в новой панели Services Board, предоставляя командам общеорганизационное представление о тенденциях обнаружения, пробелах в владении, привязках проектов и общих рисках.
Панель Services Board дает организациям наглядное представление об обнаружении сервисов, пробелах в владении, привязках проектов и рисках. Она помогает командам перейти от отдельных находок к более широкому пониманию того, где покрытие сервисов надежно, а где требует улучшения.
Для руководителей она также предоставляет показатели эффективности в отношении полноты обнаружения, покрытия владением, соответствия требованиям, подверженности угрозам и распределения затрат. Это упрощает отслеживание прогресса с течением времени и определение областей, где эффективное владение сервисами может принести наибольшую пользу.
Эти представления помогают ответить на такие вопросы, как в каких сервисах отсутствуют владельцы, где увеличиваются пробелы в обнаружении или привязке проектов и какие сервисы несут наибольший риск для безопасности или соответствия требованиям. Что еще более важно, они обеспечивают контекст, необходимый для перенаправления этих проблем нужным командам.
Новые шаблоны в каталоге Wiz Workflows Catalog помогают еще больше превратить эту видимость в повторяемые действия. Команды могут автоматически выявлять сервисы без владельцев и направлять запросы на владение, уведомлять заинтересованных лиц через Slack, Jira или ServiceNow при нарушении сервисом политики состояния (Service Posture Policy), а также позволять разработчикам устранять проблемы с помощью инженерных инструментов, которые они уже используют.
Объединяя Service Catalog и Workflows, вы можете автоматизировать жизненный цикл и процессы реагирования с помощью многоэтапных автоматизаций на основе событий:
- При создании сервиса: автоматизируйте запрос владельца, проверку тегов или запуск процессов утверждения в Slack/Jira в момент обнаружения или синхронизации нового сервиса.
При создании сервиса: автоматизируйте запрос владельца, проверку тегов или запуск процессов утверждения в Slack/Jira в момент обнаружения или синхронизации нового сервиса.
- При создании проблемы в сервисе: направляйте консолидированные выводы на уровне сервиса непосредственно в бэклог ответственной команды разработчиков или в канал оповещений с приложенным полным контекстом сервиса и кода.
При создании проблемы в сервисе: направляйте консолидированные выводы на уровне сервиса непосредственно в бэклог ответственной команды разработчиков или в канал оповещений с приложенным полным контекстом сервиса и кода.
Результатом является более четкий путь не только от выявления риска к его назначению, но и от назначения к устранению.
Общая операционная модель для облака
Wiz Service Catalog — это больше, чем инвентаризация активов: это единый операционный ракурс для всего, за что отвечает команда, включая состояние безопасности, угрозы, соответствие требованиям, затраты и зрелость владения.
Если вы уже используете Wiz Service Catalog, изучите новые панели и политики состояния сервисов (Service Posture Policies). Если вы только начинаете, правила динамического обнаружения (Dynamic Discovery Rules) помогут быстрее превратить ваши существующие соглашения о тегах в рабочий каталог уже сегодня.
.png)
