Безопасное управление ключами загрузки в Windows и Linux

При использовании функции Secure Boot в системах Windows и Linux управление ключами перестаёт быть необязательным.Это влияет на возможность загрузки системы, возможность обновления прошивки с помощью fwupd или инструментов производителя, а также, в будущем, на то, будут ли ваши компьютеры по-прежнему принимать загрузчики, подписанные старыми сертификатами Microsoft.

Цель этой статьи — спокойно, но обстоятельно объяснить, как работает вся экосистема ключей и сертификатов Secure Boot на современных платформах UEFI.Какова роль ключей PK, KEK, db и dbx? Как это соотносится с Windows, дистрибутивами Linux, использующими вспомогательные технологии, и с OEM-оборудованием? И какие существуют реальные решения для генерации, защиты и обновления этих ключей без создания хаоса на заводах или в профессиональных средах?

Что такое Secure Boot и как она интегрирована в UEFI, Windows и Linux?

Функция безопасной загрузки (Secure Boot) — это функция безопасности, определенная в стандарте UEFI, а не изобретение, присущее исключительно Microsoft.Она появилась как эволюция старого BIOS, в результате чего появился стандартный механизм, позволяющий прошивке проверять криптографические подписи компонентов, загружаемых при загрузке: ПЗУ опций, драйверы UEFI, приложения UEFI и, прежде всего, загрузчики операционных систем.

Секрет в том, что прошивка выполняет только те исполняемые файлы, подпись которых она может проверить с помощью хранящихся внутри неё доверенных ключей.Это уменьшает поверхность атаки для вредоносных программ, внедряемых при загрузке системы (буткитов, руткитов) до того, как операционная система и антивирусное программное обеспечение смогут получить контроль. Windows 8 представила эту модель как часть своей архитектуры безопасной загрузки, и с тех пор она стала обязательным требованием на современных клиентских компьютерах под управлением Windows и Windows Server.

В мире Linux технология Secure Boot была встречена более противоречиво. Поскольку многие дистрибутивы не были готовы должным образом подписывать GRUB и ядро, и поскольку большая часть экосистемы полагается на ключевую инфраструктуру Microsoft для загрузки на потребительском оборудовании, возник shim: небольшой загрузчик, подписанный Microsoft, который, в свою очередь, проверяет GRUB и ядро ​​с помощью ключей самого дистрибутива и управляется с помощью таких инструментов, как Менеджер МОК.

Хотя Microsoft выступает в качестве одного из соответствующих органов по сертификации Secure Boot, полный контроль над этим стандартом остается за владельцем компьютера.Практически на всех материнских платах x86 можно управлять базой данных ключей, добавлять собственные ключи, удалять ключи Microsoft или даже загружаться с полностью пользовательским первичным ключом. Споры возникают скорее из-за конфигурации по умолчанию и требований к сертификации Windows, чем из-за самой технологии.

Применение криптографии с открытым ключом и PKI для обеспечения безопасной загрузки

Безопасная загрузка полностью основана на инфраструктуре открытых ключей (PKI).Это включает в себя работу с асимметричными парами ключей (открытым и закрытым), сертификатами X.509 и цепочками сертификатов, которые устанавливают корень доверия от центра сертификации (CA) к исполняемым файлам, запускаемым при загрузке.

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

Рекомендуемые алгоритмы для безопасной загрузки — это RSA с битами не менее 2048 и подписи с использованием SHA-256.Стандарт UEFI определяет типы подписей, такие как EFI_CERT_X509_GUID (полные сертификаты X.509) или EFI_CERT_RSA2048_GUID (сырой открытый ключ или хэш ключа, для экономии места в микропрограмме), и Windows приводит свои требования в соответствие с этим уровнем безопасности.

Типичный цифровой сертификат содержит уникальное имя, открытый ключ и подпись выдавшего его центра сертификации.В корневых сертификатах подпись является самоподписанной (центр сертификации подписывает себя сам), тогда как в промежуточных или конечных сертификатах подпись исходит от центра сертификации более высокого уровня. Secure Boot использует эти цепочки сертификатов, чтобы позволить доверенному корневому центру сертификации аутентифицировать множество промежуточных ключей, не загромождая прошивку сертификатами.

На практике несколько соответствующих центров сертификации сходятся в процессе безопасного запуска.С одной стороны — OEM-производитель (или его представители, такие как IBV или ODM), а с другой — Microsoft, имеющая разные сертификаты для KEK, для центра сертификации UEFI, подписывающего загрузчик Windows, и для центра сертификации UEFI, используемого для подписи сторонних драйверов UEFI и загрузчиков других операционных систем, таких как Fedora или Ubuntu.

Корень доверия UEFI: PK, KEK, db и dbx

В основе принципа доверия Secure Boot в UEFI лежат четыре ключевых элемента.Ключ платформы (PK), ключ обмена ключами (KEK), разрешенная база данных подписей (db) и запрещенная или отозванная база данных подписей (dbx) хранятся в виде аутентифицированных переменных UEFI.

Ключ платформы (PK) определяет, кто является владельцем платформы, для целей безопасной загрузки.Это сертификат, обычно X.509 RSA-2048 с подписью SHA-256, открытая часть которого (PKpub) записывается в микропрограмму во время производства, выводя систему из режима конфигурации в пользовательский режим.

Приватная часть ПК (PKpriv) всегда должна оставаться вне устройства, с соблюдением строжайшей безопасности.Это используется для подписи любых операций, изменяющих KEK, db или dbx в пользовательском режиме, а также для замены самого первичного ключа. Microsoft предлагает производителям оборудования возможность использовать управляемый ими первичный ключ, хранящийся в HSM, что упрощает управление для производителей, которые не хотят внедрять полноценную инфраструктуру открытых ключей (PKI).

Ключ обмена ключами (KEK) выступает в качестве доверенного связующего звена между микропрограммой и операционными системами или приложениями, управляющими базами данных (db) и dbx.Каждая система (Windows, Linux, OEM-производитель, сторонний разработчик) может зарегистрировать свой открытый ключ KEKpub в переменной KEK, так что любое обновление базы данных или DBX, подписанное этим ключом, будет считаться легитимным.

В современных системах Windows 11 обязательно необходимо включить в переменную KEK как минимум центр сертификации «Microsoft Corporation KEK 2K 2023».Этот сертификат позволяет Microsoft распространять обновления dbx (отзыв уязвимых бинарных файлов или скомпрометированных сертификатов) и, при необходимости, корректировать содержимое базы данных для поддержки новых подписантов.

База данных (_IMAGE_SECURITY_DATABASE) собирает подписи, которые считаются действительными для запуска.Здесь вставляются корневые сертификаты, такие как «Windows UEFI CA 2023», «Microsoft UEFI CA 2023», «Microsoft Corporation UEFI CA 2011» или «Microsoft UEFI Option ROM CA 2023», а также возможные OEM-сертификаты центров сертификации или хеши конкретных бинарных файлов.

dbx (EFI_IMAGE_SIGNATURE_DATABASE1) делает прямо противоположное: он хранит явно отозванные сертификаты, ключи или хеши.Любое совпадение в файле dbx блокирует выполнение исполняемого файла, даже если его сигнатура совпадает с чем-либо в базе данных. Windows требует, чтобы файл dbx всегда существовал, и регулярно распространяет пакеты обновлений с новыми отзывами, особенно когда обнаруживаются уязвимости в загрузчиках или драйверах UEFI.

Требования к настройке безопасной загрузки на компьютерах под управлением Windows 11 и в системах Linux.

Для современных устройств под управлением Windows 11, особенно версии 25H2, Microsoft устанавливает минимальные требования к конфигурации безопасной загрузки UEFI.Производители оборудования должны предварительно установить PK (собственный или от Microsoft), "Microsoft Corporation KEK 2K 2023", "Windows UEFI CA 2023" в dbx и последний пакет dbx в dbx.

В системах, предназначенных для запуска Linux или других сторонних приложений UEFI, содержимое базы данных расширяется.В дополнение к Windows UEFI CA 2023 рекомендуется включить Microsoft UEFI CA 2023, Microsoft Corporation UEFI CA 2011 и Microsoft UEFI Option ROM CA 2023, чтобы опциональные ПЗУ, внешние драйверы UEFI и загрузчики с других платформ загружались без необходимости пользователю вносить изменения в прошивку.

Производители оборудования могут при необходимости включать собственные средства аутентификации UEFI в дБ.Например, для подписи внутренних драйверов UEFI или специализированных загрузчиков. Аналогично, переменные dbDefault, dbxDefault и KEKDefault позволяют определить наборы ключей и подписей по умолчанию, которые микропрограмма может восстановить до заводских значений.

В мире Linux вступает в игру еще один фактор: истечение срока действия сертификатов Microsoft.Срок действия старых ключей в конечном итоге полностью истечет (особенно актуален крайний срок в сентябре 2025 года), а это значит, что загрузчики, подписанные этими сертификатами, могут перестать загружаться, или что обновления прошивки через fwupd могут завершиться неудачей, если не будут установлены новые ключи Microsoft KEK и CA.

Дистрибутивы, такие как Ubuntu, Fedora и openSUSE, а также их коммерческие варианты (RHEL, SLE), обычно опережают другие по совместимости с функцией Secure Boot.Они хорошо интегрируются с fwupd, GNOME Software или Discover, позволяя применять ключевые обновления всего за пару кликов и перезагрузку, в то время как другие дистрибутивы по-прежнему рекомендуют напрямую отключать Secure Boot, поскольку они некорректно подписывают GRUB или ядро.

Типичные сценарии использования и распространенные проблемы с функцией Secure Boot.

На домашнем или игровом ПК функция Secure Boot защищает от вредоносных загрузчиков, но может конфликтовать со старым оборудованием или неподписанным программным обеспечением.Довольно часто приходится отключать эту функцию, чтобы загрузить с загрузочного USB-накопителя инструменты, какой-нибудь экзотический дистрибутив или старые видеокарты, которые не поддерживают подписанные UEFI ROM-файлы.

В профессиональной или корпоративной среде активная и правильно настроенная функция Secure Boot практически обязательна.Во многих системах этот уровень используется для снижения риска компрометации на низком уровне, а также в сочетании с TPM 2.0 и полным шифрованием диска (BitLocker в Windows, LUKS в Linux), что обеспечивает защиту ключей расшифровки для целостности загрузки.

Windows 11 еще больше ужесточила требования, одновременно потребовав наличия TPM 2.0 и Secure Boot в качестве официальных условий.Хотя существуют модифицированные установщики, которые обходят эти проверки, любой, кто хочет пойти «поддерживаемым путем», должен убедиться, что прошивка находится в чистом режиме UEFI, с доступной и, по возможности, включенной функцией Secure Boot.

Видеоигры также косвенно подхватили концепцию безопасной загрузки (Secure Boot). в сочетании с античитерской защитой на уровне ядра. В таких играх, как Valorant, League of Legends, Battlefield 6 и Call of Duty: Black Ops 7, для работы античитерской системы даже требовалась Windows с функцией Secure Boot, за исключением старых компьютеров без UEFI или TPM.

В среде Linux функция Secure Boot имеет решающее значение в сценариях двойной загрузки с шифрованием.Если на одном компьютере используются Windows и Linux, а раздел Linux зашифрован, всегда найдутся незашифрованные файлы (initramfs, загрузчик, shim/GRUB), которые могут привлечь внимание злоумышленника, желающего скомпрометировать Windows. Правильно настроенная функция Secure Boot предотвратит замену вашего initramfs на файл, содержащий пароль, поскольку прошивка отклонит неподписанный бинарный файл с доверенным ключом.

Как безопасно включить или отключить безопасную загрузку (Secure Boot)

Включение или отключение функции Secure Boot всегда осуществляется через встроенную прошивку UEFI устройства, а не через саму операционную систему.Однако Windows предлагает ярлыки для перезагрузки непосредственно в меню прошивки.

Начиная с Windows 10 или 11, самый простой способ — через расширенное меню восстановления.Перейдите в «Настройки» > «Обновление и безопасность» > «Восстановление» > «Дополнительные параметры запуска», нажмите «Перезагрузить сейчас», а после перезагрузки выберите «Устранение неполадок» > «Дополнительные параметры» > «Параметры прошивки UEFI». После этого компьютер перезагрузится, но сразу перейдет в интерфейс BIOS/UEFI.

В рамках UEFI каждый производитель размещает опцию Secure Boot в несколько ином месте.Обычно это находится на вкладке «Загрузка» или «Безопасность». Возможно, сначала потребуется установить пароль администратора, чтобы изменить этот параметр, после чего вы сможете переключаться между состояниями «Включено/Выключено» или удалять ключи, чтобы вернуться в режим настройки.

Стоит помнить, что отключение Secure Boot оказывает реальное влияние на поверхность атаки.Вы откроете доступ для запуска загрузчиков, ядер или диагностических инструментов без проверенной подписи, что, если компьютер подвергнется воздействию сложного вредоносного ПО, увеличивает риск появления буткитов, которые очень трудно обнаружить и удалить.

На компьютерах, приобретенных с предустановленной Windows, некоторые производители настраивают функцию Secure Boot довольно ограничительным образом.На некоторых «закрытых» настольных и портативных компьютерах пользователю приходится отключать эту функцию, если он хочет загрузить многие дистрибутивы Linux, которые еще не полностью поддерживают модель подписи Microsoft или не предлагают подписанные заглушки.

Управление ключами безопасной загрузки в производственных и OEM-средах

Когда речь заходит об OEM-производителях, ODM-производителях или интеграторах, выпускающих оборудование в больших масштабах, управление ключами перестает быть технической деталью и превращается в полноценный проект PKI.Недостаточно просто «сгенерировать сертификат»: необходимо определить, сколько различных первичных ключей будет, где будет храниться каждый закрытый ключ и в течение скольких лет можно выпускать обновления прошивки или изменять KEK/db/dbx.

Типичные варианты использования ключа платформы (PK) варьируются от одного ключа на устройство до одного ключа на производителя оборудования (OEM).Использование одного блока защиты на устройство обеспечивает максимальную изоляцию (если один из них будет скомпрометирован, это повлияет только на одну машину), но это создает серьезные логистические и складские проблемы. Обычно разумным балансом является использование одного блока защиты на модель или линейку продуктов, особенно для потребительских настольных компьютеров и ноутбуков.

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

Все эти операции отражены в рабочем процессе Windows по обновлению прошивки через UEFI Capsule.Windows собирает обновления из хранилища драйверов, вызывает функцию UpdateCapsule() перед ExitBootServices(), после чего микропрограмма проверяет подпись, сверяет ключ с сохраненным хешем и, если все совпадает, прошивает новую микропрограмму.

Ключ обновления прошивки ни в коем случае не должен совпадать с ключом обновления прошивки (PK).Если бы PKpriv был скомпрометирован и использовался для подписи прошивки, злоумышленник мог бы отключить Secure Boot и заменить легитимную прошивку модифицированной, даже заблокировав возможность восстановления платформы с новым PK.

Основные решения для управления: HSM, TPM, программное обеспечение и другие.

Для корректного управления ключами Secure Boot обычно используются аппаратные модули безопасности (HSM).Это сертифицированные устройства (во многих случаях соответствующие стандарту FIPS 140-2 уровня 2 или 3), предназначенные для генерации, хранения и использования закрытых ключей без раскрытия их в открытом виде за пределами оборудования.

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

Автономные HSM (USB, PCIe, PCMCIA) хорошо подходят для небольших лабораторий или для использования в лабораторных условиях.Они могут быть интегрированы с криптографическими API Microsoft (CAPI, CNG) или другими, а некоторые модели также предлагают механизмы резервного копирования и репликации, хотя и не всегда на уровне сетевого HSM.

Во всех этих случаях надежная аутентификация является краеугольным камнем.Многие аппаратные модули безопасности (HSM) допускают схемы токенов типа «k из m»: например, генерируется пять криптографических карт, и для разблокировки доступа к определенным ключам требуется одновременное наличие трех из них. Это распределяет ответственность между несколькими ролями (безопасность, операционная деятельность, управление) и снижает риск злоупотребления со стороны отдельных лиц.

Существуют менее мощные альтернативы, ориентированные на собственное оборудование ПК, такие как TPM или смарт-карты.Модуль TPM может генерировать и защищать ключи для шифрования дисков и других функций, но ему, как правило, не хватает вычислительной мощности, емкости хранилища и сертификатов, необходимых для управления тысячами ключей PK или ключей прошивки на заводе.

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

Наконец, существуют чисто программные подходы к генерации и хранению ключей, которые не рекомендуются для OEM-среды.Такие инструменты, как makecert или стандартные криптографические API, позволяют создавать сертификаты и хранить их на зашифрованных дисках или изолированных машинах, но вектор атаки значительно шире, и, если не использовать строгие физические меры контроля, риск утечки ключей становится неприемлемо высоким.

Генерация, хранение и извлечение закрытых ключей.

Объем памяти, занимаемый ключом RSA-2048, невелик в абсолютном выражении (2048 бит), но его ценность заключается в символическом значении и долговременном управлении.Ключ обновления прошивки или IP-адрес может нуждаться в безопасном доступе в течение десяти лет и более для устранения неполадок или создания новых версий прошивки.

Общая рекомендация — всегда хранить закрытые ключи на выделенном оборудовании.Будь то аппаратный модуль безопасности (HSM) в центре обработки данных или, в гораздо более скромных сценариях, хранящийся криптографический токен, резервные копии следует хранить в отдельных физических местах, даже в разных географических регионах, чтобы минимизировать последствия катастроф.

Ключевые процессы восстановления должны быть определены так же четко, как и процессы генерации ключей.Вам может потребоваться повторно сгенерировать первичный ключ (PK), если клиент с высоким уровнем безопасности захочет зарегистрировать свой собственный, если будет обнаружена потенциальная утечка данных или просто потому, что внутренняя политика предписывает периодическую ротацию (например, каждые X лет в соответствии с рекомендациями Федерального центра сертификации).

В случае ключей KEK и ключей обновления прошивки восстановление имеет еще более важное значение.Ключ KEKpriv используется для подписи новых версий db и dbx, а закрытый ключ прошивки подписывает обновления, распространяемые на миллионы устройств. Потеря одного из этих ключей без резервной копии может лишить вас возможности отозвать скомпрометированные сертификаты или распространить исправления безопасности.

Высокоуровневая аутентификация (FIPS 140-2 уровень 3) добавляет дополнительный уровень защиты ко всему этому процессу.Это требует индивидуальной идентификации каждого оператора, получающего доступ к модулю, регистрации его действий и применения физических средств контроля (пломбы, датчики вскрытия, надежное удаление данных при попытках несанкционированного доступа), что значительно снижает риск скрытой кражи ключей.

Безопасная загрузка, подписание сторонними программами и совместимость с Linux.

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

Типичные критические замечания, изображающие его как инструмент Microsoft для блокировки альтернативных систем, не выдерживают критики при более детальном изучении спецификации UEFI.Пользователь или администратор может зарегистрировать собственные ключи, удалить ключи Microsoft, изменить первичный ключ или выбрать вариант, при котором доверять будут только исполняемые файлы, подписанные его организацией, что четко указано в документации Debian и других дистрибутивов.

Несомненно одно: на практике многие дистрибутивы Linux предпочли использовать ключевую инфраструктуру Microsoft, чтобы упростить жизнь пользователям с ограниченными техническими навыками.При использовании модулей, подписанных Microsoft UEFI CA 2011 или 2023, прошивка немедленно распознает загрузчик дистрибутива без необходимости ручного изменения пользователем параметров PK, KEK или db.

Microsoft также предлагает специальный центр сертификации для подписи сторонних драйверов и приложений UEFI.Любой производитель или разработчик оборудования, которому необходимо, чтобы его опциональное ПЗУ или драйвер UEFI загружались на оборудовании с поддержкой Secure Boot, может отправить свои бинарные файлы на эту процедуру подписи и распространять их, зная, что они будут работать на компьютерах, в базе данных которых есть центр сертификации Microsoft.

Наименее привлекательным аспектом этой схемы является то, что ключи истекают и отзываются.Когда срок действия старого корневого сертификата подходит к концу, его необходимо заменить новым, и нужно убедиться, что все устройства получили соответствующие обновления через KEK/db/dbx, иначе существует риск того, что такие вещи, как fwupd, некоторые загрузчики или UEFI ROM, перестанут поддерживаться прошивкой.

Если вы используете двойную загрузку с Windows и Linux или развертываете Linux с включенной функцией Secure Boot, вам следует периодически проверять наличие ключевых обновлений, публикуемых Microsoft и вашим дистрибутивом.Во многих дистрибутивах достаточно просто принять пакеты обновления прошивки из магазина программного обеспечения или менеджера пакетов, перезагрузить систему и позволить прошивке применить изменения; в других же вам придётся использовать командную строку и специальные утилиты.

Двойная загрузка Windows и Linux, разделы EFI и порядок загрузки.

Для настройки чистой двойной загрузки между Windows и Linux необходимо немного разобраться во взаимодействии UEFI, раздела EFI и загрузчика GRUB.При использовании функции Secure Boot еще важнее не импровизировать, и рекомендуется провести проверку. процесс загрузки в системах UEFI.

Если у вас уже установлена ​​Windows в режиме UEFI с разметкой GPT, первое, что нужно сделать, это уменьшить размер раздела Windows и зарезервировать нераспределенное пространство для Linux.Перед изменением размера отключите такие функции, как быстрая загрузка и BitLocker, чтобы избежать неожиданностей. Крайне важно убедиться в наличии раздела EFI (FAT32, несколько сотен МБ), который будет использоваться обеими системами.

При установке Linux рекомендуется использовать ручное разметку диска и учитывать существующий раздел EFI.Вместо создания нового раздела, он монтируется как /boot/efi. После этого создаются необходимые разделы для /, /home и swap, а также устанавливается GRUB в качестве менеджера загрузки UEFI, также указывающий на раздел EFI.

Если дистрибутив поддерживает Secure Boot, будут установлены подписанный заглушечный модуль и GRUB, которые прошивка примет без дальнейших проблем.В противном случае, для завершения установки может потребоваться временно отключить Secure Boot или вручную зарегистрировать дополнительные сертификаты в базе данных, чтобы прошивка доверяла загрузчику Linux; это распространенная практика в случае проблем с совместимостью. Добавьте параметры загрузки в GRUB..

После установки система может загрузиться непосредственно в Windows, поскольку загрузочная запись GRUB не имеет приоритета.В этом случае вам нужно получить доступ к UEFI и изменить порядок загрузки, или, в Linux, использовать efibootmgr для изменения порядка записей. В Windows вы также можете поэкспериментировать с этим. bcdedit, bootrec и reagentcНо проще позволить UEFI управлять приоритетами.

При правильной настройке всех параметров и управлении ключами можно поддерживать надежную двойную загрузку с зашифрованными дисками и активной функцией Secure Boot., без необходимости включать и отключать параметры каждый раз при смене системы или отказываться от преимуществ безопасности, обеспечиваемых современной архитектурой UEFI-Secure Boot-TPM.

В конечном итоге, понимание управления ключами Secure Boot в Windows и Linux — от PK и KEK до db/dbx, HSM, TPM и двойной загрузки — это то, что отличает капризную систему, которая перестает загружаться при истечении срока действия сертификата, от надежной платформы, готовой к обновлениям прошивки, новым дистрибутивам и все более строгим требованиям безопасности без потери контроля над собственными машинами.