Хотели как лучше — потеряли интернет. У SentinelOne эпичный выстрел в ногу
NewsMakerВы чините проводку и случайно вырываете весь щиток.
Крупнейший сбой в инфраструктуре компании SentinelOne, который произошёл 29 мая и продлился около 7 часов, затронул множество клиентских сервисов и вызвал глобальное отключение части ключевых функций. При этом, как заверили в компании, рабочие станции клиентов продолжали оставаться под защитой, несмотря на то, что доступ к аналитике и управлению системой оказался недоступен.
Согласно заявлению SentinelOne, опубликованному сразу после сбоя, речь не шла о кибератаке или утечке данных. Первоначальные признаки указывали на сбой внутри самой системы управления инфраструктурой. Впоследствии, в ходе более детального анализа, компания подтвердила: проблема была вызвана ошибкой в устаревающем компоненте облачной архитектуры . Этот компонент, отвечающий за контроль сетевых конфигураций, ошибочно определил, что конфигурация маршрутов в облаке требует «обновления», и восстановил пустую резервную копию таблицы маршрутов AWS Transit Gateway.
Причиной такого поведения стал сбой в функции сравнения конфигураций, которая неверно интерпретировала расхождения между активной и эталонной конфигурацией. Поскольку устаревающая система управления уже не являлась основным источником правды для сетевых настроек, она приняла некорректное решение и удалила важные маршруты и правила DNS-резолвинга. Это привело к отказу практически всех сервисов во всех регионах, включая Unified Asset Management, Inventory и Identity-сервисы.
Дополнительно были затронуты функции программного доступа к сервисам компании, а также интеграции с внешними источниками данных. Управляемый мониторинг (MDR) также лишился возможности уведомлять о происходящих инцидентах. В SentinelOne подчеркнули, что данные о вредоносной активности не были утеряны, а лишь временно перестали отображаться в интерфейсе — и что защита конечных устройств продолжала функционировать штатно.
Сбой произошёл в момент создания новой учётной записи, что и стало триггером для старой контрольной системы. При этом сама SentinelOne уже находится в процессе перехода на новую архитектуру, основанную на принципах Infrastructure-as-Code (IaC). Именно в контексте этого перехода задействованный устаревший модуль с ошибкой и активировал цепочку изменений, приведших к отключению инфраструктуры.
Компания пообещала в ближайшее время завершить переход на новую систему управления и исключить возможность повторения подобной ситуации. Отдельно отмечается, что в течение всего времени инцидента системы защиты работали корректно, несмотря на отсутствие доступа к интерфейсу управления и аналитике.
Крупнейший сбой в инфраструктуре компании SentinelOne, который произошёл 29 мая и продлился около 7 часов, затронул множество клиентских сервисов и вызвал глобальное отключение части ключевых функций. При этом, как заверили в компании, рабочие станции клиентов продолжали оставаться под защитой, несмотря на то, что доступ к аналитике и управлению системой оказался недоступен.
Согласно заявлению SentinelOne, опубликованному сразу после сбоя, речь не шла о кибератаке или утечке данных. Первоначальные признаки указывали на сбой внутри самой системы управления инфраструктурой. Впоследствии, в ходе более детального анализа, компания подтвердила: проблема была вызвана ошибкой в устаревающем компоненте облачной архитектуры . Этот компонент, отвечающий за контроль сетевых конфигураций, ошибочно определил, что конфигурация маршрутов в облаке требует «обновления», и восстановил пустую резервную копию таблицы маршрутов AWS Transit Gateway.
Причиной такого поведения стал сбой в функции сравнения конфигураций, которая неверно интерпретировала расхождения между активной и эталонной конфигурацией. Поскольку устаревающая система управления уже не являлась основным источником правды для сетевых настроек, она приняла некорректное решение и удалила важные маршруты и правила DNS-резолвинга. Это привело к отказу практически всех сервисов во всех регионах, включая Unified Asset Management, Inventory и Identity-сервисы.
Дополнительно были затронуты функции программного доступа к сервисам компании, а также интеграции с внешними источниками данных. Управляемый мониторинг (MDR) также лишился возможности уведомлять о происходящих инцидентах. В SentinelOne подчеркнули, что данные о вредоносной активности не были утеряны, а лишь временно перестали отображаться в интерфейсе — и что защита конечных устройств продолжала функционировать штатно.
Сбой произошёл в момент создания новой учётной записи, что и стало триггером для старой контрольной системы. При этом сама SentinelOne уже находится в процессе перехода на новую архитектуру, основанную на принципах Infrastructure-as-Code (IaC). Именно в контексте этого перехода задействованный устаревший модуль с ошибкой и активировал цепочку изменений, приведших к отключению инфраструктуры.
Компания пообещала в ближайшее время завершить переход на новую систему управления и исключить возможность повторения подобной ситуации. Отдельно отмечается, что в течение всего времени инцидента системы защиты работали корректно, несмотря на отсутствие доступа к интерфейсу управления и аналитике.