VMware представила Identity Manager как часть Enterprise Mobility Management

VMware представила облачное решение IDM

Производитель продуктов для построения виртуальных и облачных решений компания VMware представила собственный облачный сервис управления идентификацией пользователей класса IDM. Сервис рассчитан на управление учётными записями не только внутри компаний, но и во внешних сервисах. В частности, он хорошо интегрирован с системой идентификации Google, хотя может подключить практически любую систему федеративной идентификации, поддерживающую формат SAML.

Идентификация пользователей является ключевым компонентом так называемой третей платформы, идею которой компания VMware продвигает уже несколько лет. Если в терминальных системах (первой платформе) пользователь ассоциировался с терминалом, в клиент-серверной архитектуре (второй платформе) - с персональным компьютером, который обычно выступал в роли клиента, то в облачной системе (третьей платформе) уже не совсем понятно, что такое пользователь как человек. Компания утверждает, что с помощью облачных услуг пользоваться можно любыми приложениями, из любого места и с помощью любого устройства, то есть в третьей платформе привязать аутентификацию к устройству уже не получается.

Хотя в России Минсвязи признаёт аутентификацию по номеру мобильного телефона за надёжную, тем менее не менее у человека может быть несколько мобильных устройств. К тому же с распространением интеллектуальных устройств, таких как телевизоры, автомобили, холодильники, связь их с конкретным человеком усложняется, поскольку это устройства коллективного пользования. Поэтому в третьей платформе есть потребность в использовании специального виртуального идентификатора, то есть универсальной учётной записи от всех сервисов. Сейчас уже есть несколько подобных центров идентификации, таких как сервисы Google, Facebook, Twitter, с помощью которых можно аутентифицироваться в сторонних веб-сервисах. Однако пока пользоваться этими сервисами на уровне корпоративных приложений достаточно сложно.

Именно поэтому компания VMware разработала облачный сервис управления учётными записями VMware Identity Manager, который может быть тесно интегрирован с AirWatch Enterprise Mobility Management - системой управления мобильными устройствами. В результате, с помощью одной учётной записи корпоративный пользователь сможет получить доступ к веб, мобильным и настольным приложениям. Сервис можно получить из облака или развернуть локально в корпоративной сети. Впрочем, облачный сервис пока в России не доступен, что связано с требованиями российского закона о персональных данных. Собственного ЦОДа не территории России у VMware нет, а договорённость с российскими партнёрами компания пока не заключила. У VMware на территории России есть около пятидесяти партнёров, часть их которых может со временем развернуть в своих ЦОДах Identity Manager, и тогда россияне смогут арендовать этот продукт из облака. Впрочем, локальную версию Identity Manager можно приобрести и развернуть уже сейчас.

Баги в ядре Linux скрываются в среднем 2 года, а иногда и 20 лет

История с первой CVE для Rust-кода в ядре Linux, которая недавно привела к падениям системы, выглядела почти как повод для оптимизма. В тот же день для кода на C зарегистрировали ещё 159 CVE — контраст показательный. Но новое исследование напоминает: проблема не только в языках программирования.

Гораздо тревожнее первой Linux-дыры в коде на Rust тот факт, что многие ошибки в ядре Linux могут годами, а иногда и десятилетиями оставаться незамеченными.

Исследовательница Дженни Гуанни Ку из компании Pebblebed проанализировала 125 183 бага за почти 20 лет развития ядра Linux — и результаты оказались, мягко говоря, неожиданными.

 

По данным исследования, средний баг в ядре Linux обнаруживают через 2,1 года после его появления. Но это ещё не предел. Самый «долгоиграющий» дефект — переполнение буфера в сетевом коде — прожил в ядре 20,7 года, прежде чем на него обратили внимание.

Важно уточнить: речь идёт о багах в целом, а не только об уязвимостях. Лишь 158 ошибок из всей выборки получили CVE, остальные могли приводить к сбоям, нестабильности или неопределённому поведению, но не обязательно к эксплуатации.

Исследование опирается на тег Fixes:, который используется в разработке ядра Linux. Когда разработчик исправляет ошибку, он указывает коммит, в котором баг был добавлен. Дженни написала инструмент, который прошёлся по git-истории ядра с 2005 года, сопоставил такие пары коммитов и вычислил, сколько времени баг оставался незамеченным.

В датасет вошли данные до версии Linux 6.19-rc3, охватывающие период с апреля 2005 по январь 2026 года. Всего — почти 120 тысяч уникальных исправлений от более чем 9 тысяч разработчиков.

Оказалось, что скорость обнаружения ошибок сильно зависит от подсистемы ядра:

  • CAN-драйверы — в среднем 4,2 года до обнаружения бага;
  • SCTP-стек — около 4 лет;
  • GPU-код — 1,4 года;
  • BPF — всего 1,1 года.

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

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

Такие ситуации особенно опасны: создаётся ощущение, что проблема решена, хотя на самом деле она просто сменила форму.

RSS: Новости на портале Anti-Malware.ru