Главное — сократить количество потенциальных объектов атаки, обеспечить целостность кода и выявить уязвимости.
Google часто рекламировала различные функции управления и защиты своих облачных сервисов в рамках продолжающейся кампании, имеющей целью убедить бизнес в готовности своих хостовых продуктов к обслуживанию предприятий.
Продолжая в том же духе, корпорация сообщила некоторые новые подробности о множестве принимаемых ею мер для защиты гипервизора KVM (Kernel-based Virtual Machine) с открытым исходным кодом в ядре своих сервисов Compute Engine и Container Engine.
Ведущий технический менеджер Google Энди Хониг и старший менеджер по продуктам Нелли Портер обрисовали в блоге семь высокоуровневых инструментов, которые Google использует для защиты KVM. Они включают процессы для сокращения потенциальных объектов атаки гипервизора, средства проверки происхождения кода для обеспечения целостности запущенного в KVM кода, контролируемые релизы и обновления ПО, а также систематические процессы для обнаружения и устранения уязвимостей ПО.
С целью сокращения потенциальных объектов атаки KVM, например, Google ограничила поддерживаемый гипервизором набор эмулируемых инструкций и удалила из него многие неиспользуемые компоненты, включая определенные средства управления и унаследованные драйверы.
Сходным образом для установления происхождения кода Google проверяет целостность своего кода на всем пути от используемых клиентами гостевых виртуальных машин до гипервизора и далее до системного загрузчика, используя собственную систему проверки двоичного кода и конфигурации.
Процессы, которые Google применяет для подержания целостности своего кода, гарантируют, что после загрузки машины всегда находятся в надлежащем уже знакомом и предварительно проверенном состоянии, утверждают инженеры Google.
Важное средство, которое Google применяет для смягчения связанных с KVM рисков, это разработка и использование в пространстве пользователей собственного монитора виртуальных машин и эмулятора оборудования вместо Quick Emulator (QEMU) с открытым исходным кодом.
Около двух лет назад ошибка в контроллере виртуальных дискет QEMU привела к появлению критической уязвимости, получившей название VENOM. Она позволила атакующим получать полный административный контроль над базовой операционной системой, под управлением которой в виртуальной среде работают гостевые машины.
Разработанный Google собственный эмулятор гораздо менее сложен, он проще, чем QEMU, поскольку предназначен только для одной архитектуры и сравнительно небольшого числа устройств, пишут Хониг и Портер.
Созданный в корпорации эмулятор не поддерживает большого числа хостовых и гостевых систем, как QEMU, или конфигурации для хостовых и гостевых систем различных архитектур. Это упрощает тестирование и защиту эмулятора Google, пишут инженеры: «В послужном списке QEMU значится множество ошибок в системе защиты, таких как VENOM, и не ясно, какие еще уязвимости могут скрывать в его коде».
В дополнение к этим мерам Google создала обширный набор инструментов нагрузочного тестирования для поиска уязвимостей в KVM каждый раз, когда в него добавляются новые функции и возможности. Google использует также процесс формального просмотра кода каждый раз, когда приступает к использованию новой версии или функции KVM. По словам Хонига и Партер, за последние три года принятые меры позволили Google выявить и устранить целый ряд уязвимостей KVM.
За тот же период сообщество разработчиков открытого кода не обнаружило в гипервизоре уязвимостей, затрагивающих облачную платформу Google Cloud, добавляют они.
