Hush Security представляет доступ на основе политик

Как крупному или небольшому предприятию гарантировать, что все используемые им программное обеспечение и сервисы взаимодействуют друг с другом безопасно?

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

Теперь компания Hush Security считает, что у нее есть более качественное, безопасное и эффективное решение для аутентификации корпоративных устройств и приложений: использование нового «подхода на основе политик», который предоставляет устройствам и приложениям компании доступ к другим сервисам только тогда, когда это необходимо. Израильский стартап сегодня вышел из тени при поддержке 11 миллионов долларов начального финансирования во главе с Battery Ventures и YL Ventures.

Основанная в 2024 году командой, стоявшей за Meta Networks (приобретенной Proofpoint в 2019 году), компания Hush Security родилась из глубокого личного разочарования.

«Мы основали Hush Security год назад, потому что хотели решить проблему, которая давно нас беспокоила: то, как устроена межмашинная аутентификация в современном ПО,» — заявил генеральный директор и соучредитель Мика Раве (Micha Rave) на прошлой неделе в видеоинтервью изданию VentureBeat.

Суть проблемы с машинной аутентификацией

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

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

Этот подход стал распространенным в начале 2000-х годов, а к 2010-м превратился в стандартный по умолчанию. По мере того как компании внедряли облачные вычисления, API и платформы «программное обеспечение как услуга» (SaaS), такие как AWS и Google Cloud, эти сервисы предоставляли API-ключи для управления тем, кто и что может получить к ним доступ.

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

Но эта первоначальная простота обернулась долгосрочными издержками. Эти учетные данные обычно являются статическими, то есть они не меняются, если кто-то не обновит их вручную. Это также означает, что они не адаптируются к контексту (например, кто их использует, когда и откуда) и могут существовать бесконечно долго, если никто не вмешается.

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

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

• вход в панель управления внешнего провайдера (например, Stripe или AWS),

• создание нового ключа и его безопасное хранение — обычно в хранилище секретов или файле конфигурации,

• обновление каждого программного компонента, который использовал старый ключ,

• тестирование, чтобы убедиться, что ничего не сломалось, и

• координацию действий между несколькими командами.

Ситуация усугубляется тем, что внешний сервис (эмитент ключа) никак не проверяет, как именно ключ используется после его создания. Эмитент просто проверяет, был ли кто-то авторизован в момент создания ключа — обычно опираясь на имя пользователя, пароль и многофакторную аутентификацию.

Но как только этот ключ создан, любой, кто завладеет им, может использовать его без каких-либо встроенных проверок, подтверждающих, что им по-прежнему пользуется именно нужное ПО. Если компания не выстраивает собственные уровни безопасности — такие как белые списки IP-адресов или логирование — у нее нет возможности узнать, используется ли ключ реальной системой или злоумышленником.

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

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

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

Компания Hush Security была создана для решения именно этих проблем. Вместо того чтобы пытаться сделать управление ключами чуть лучше, она полностью исключает статические ключи. Ее платформа заменяет долгосрочные учетные данные доступом «точно в срок» (just-in-time) на основе политик, что означает: машинам предоставляются разрешения только тогда, когда это необходимо, на основе строгих политик, применяемых в режиме реального времени.

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

Разрыв с устаревшими подходами

Менеджеры секретов на базе хранилищ (vault-based secrets managers), долгое время бывшие стандартом управления учетными данными, все больше превращаются в фактор риска, а не в решение проблемы.

Hush ссылается на исследование Gartner, прогнозирующее, что к 2027 году 40% организаций перейдут на архитектуры без использования секретов (не полагающиеся на хранение ключей), чтобы избежать ограничений масштабирования и пробелов в безопасности хранилищ.

«Безопасность часто отходит на второй план, когда вы пытаетесь достичь бизнес-целей и выпускать функции, и именно поэтому существующие системы управления секретами не работают», — отметил Раве.

Недавние попытки рынка исправить ситуацию тоже не помогли. «Полтора года назад появилась волна компаний, занимающихся нечеловеческими идентификационными данными (non-human identities): они привлекли внимание, но не смогли предложить реальных решений — большинство этих инструментов сейчас заброшено», — заявил Раве в интервью VentureBeat.

В отличие от них, Hush Security не предлагает незначительные улучшения. «Вместо того чтобы латать сломанную систему, мы предлагаем принципиально иной подход: замену секретов машинным доступом на основе политик», — подчеркнул он.

Как работает Hush Security

В основе предложения Hush лежит архитектура с приоритетом среды выполнения (runtime-first), построенная на стандарте SPIFFE (Secure Production Identity Framework for Everyone).

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

«Мы автоматически сопоставляем каждое межмашинное взаимодействие — то есть каждый раз, когда одна машина подключается к другой, мы логируем это и понимаем, что происходит», — пояснил Раве.

«Одним кликом мы можем превратить эти взаимодействия в политики. Если компьютер подключается к Stripe, например, мы создаем политику, согласно которой только этому компьютеру разрешено это делать».

«Если какая-либо другая машина в вашей среде попытается получить доступ к Stripe, и она не подпадает под эту политику, мы заблокируем ее. Это точный, контролируемый доступ».

Такая точность обеспечивается за счет маршрутизации машинного доступа через платформу Hush. «Мы являемся организаторами доступа, поэтому все проходит через нашу систему. Это абсолютно прозрачно для ваших разработчиков и команд безопасности».

Что немаловажно, модель Hush не требует серьезных изменений существующей инфраструктуры. «Вам не нужно предпринимать масштабные изменения или проходить через многолетнюю трансформацию — просто подключите Hush Security, и ваша среда начнет функционировать иначе без дополнительной нагрузки на инженеров», — сказал Раве.

Решение проблемы масштабирования

«На каждую человеческую учетную запись в компании приходится от 50 до 100 машинных. И тем не менее, никто не применил к ним современные модели аутентификации», — указал Раве.

Для людей нормой стало использование единого входа (SSO) с помощью сервисов, предлагаемых технологическими гигантами, такими как Google, Apple и даже Discord. Hush фактически переносит эту модель на машины.

Платформа предоставляет три ключевые возможности:

• Видимость и обнаружение в реальном времени (Runtime Visibility & Discovery) – непрерывно обнаруживает и сопоставляет все рабочие нагрузки, сервисы и ИИ-агенты от кода до продакшена.

• Анализ состояния в реальном времени (Runtime Posture Analysis) – оценивает и ранжирует риски на основе поведения в среде выполнения и потенциальной зоны поражения, а не статических предположений.

• Предотвращение и управление (Prevention & Management) – принудительно применяет динамические политики доступа «точно в срок», заменяя статические секреты, снижая накладные расходы и устраняя угрозы на основе учетных данных в самом источнике.

Этот подход значительно снижает операционную сложность и одновременно повышает уровень безопасности. «Мы не привносим новый технический долг в погоне за секретами — мы заменяем секреты масштабируемым решением для машин в стиле SSO, не нарушая при этом бизнес-приоритетов», — заявил Раве.

Что ждет Hush Security в будущем?

Несмотря на работу в режиме стелс до сегодняшнего дня, Hush Security уже привлекла корпоративных клиентов, в том числе несколько компаний из списка Fortune 500. Финансирование от Battery и YL Ventures будет направлено на расширение инженерного штата и масштабирование усилий по выходу на глобальный рынок.

«Мы находимся в критической точке перелома», — заявил Барак Шостер (Barak Schoster), партнер Battery Ventures, в пресс-релизе о привлечении средств. «Статические секреты просто не успевают за современной инфраструктурой, быстрыми циклами разработки и требованиями рабочих нагрузок на базе искусственного интеллекта».

Йоав Лейтерсдорф (Yoav Leitersdorf), управляющий партнер YL Ventures, добавил: «Безопасность машинных идентификаторов вступает в новую эру, и мы видим, что Hush Security возглавляет переход к безопасному будущему на основе политик, особенно по мере распространения ИИ-агентов и языковых моделей (LLM)».

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

Он определяет, как эти учетные данные используются в коде, среде выполнения и при взаимодействии с ИИ. После этого клиенты могут перейти на корпоративную платформу Hush в один клик, полностью избавившись от разрастания учетных данных.

Видение Hush амбициозно и прагматично: заменить стандарт многолетней давности, не заставляя команды идти на деструктивные изменения. Как выразился Раве: «Мы мягко переводим вас на подход на основе политик и SSO, не нарушая никаких бизнес-приоритетов или инженерных процессов».

Нацеливаясь на корень проблемы, а не только на ее симптомы, Hush Security стремится по-новому определить то, как аутентифицируются машинные учетные данные в эпоху, доминируемую автоматизацией и искусственным интеллектом.