Обычно компании предпочитают хранить в тайне особенности своей инфраструктуры безопасности, которая стоит на защите дата-центров, полагая, что раскрытие подобной информации может дать атакующим преимущество. Однако представители Google смотрят на этот вопрос иначе. На то есть две причины. Во-первых, публикация таких отчетов позволяет потенциальным пользователям Google Cloud Platform (GCP) оценить безопасность служб компании. Во-вторых, специалисты Google уверены в своих системах безопасности.
На днях компания обнародовала документ Infrastructure Security Design Overview («Обзор модели инфраструктуры безопасности»), в котором Google достаточно подробно описала свои защитные механизмы. Инфраструктура разделена на шесть слоев, начиная от аппаратных решений (в том числе физических средств защиты), и заканчивая развертыванием служб и идентификацией пользователей.
Первый слой защиты – это физические системы безопасности, которые просто не позволяют посторонним попасть в дата-центры. Эта часть отчета похожа на отрывок из сценария фильма «Миссия невыполнима»: «Мы используем несколько слоев физической безопасности, чтобы защитить наши дата-центры. Мы применяем такие технологии, как системы биометрической идентификации, детекторы метала, камеры, барьеры, перекрывающие проезд транспортных средств, а также лазерные системы обнаружения проникновений».
Следующий уровень защиты – железо. Согласно документу, Google категорически не допускает использования устаревшего оборудования в своих дата-центрах. Более того, компания применяет кастомное оборудование от производителей, которые предварительно проходят тщательный аудит и валидацию. Также Google создает собственные средства аппаратной защиты: «Также мы создаем кастомные чипы, в том числе, чипы, являющиеся аппаратными средствами безопасности, которые в настоящий момент используются нашими серверами и периферийным оборудованием. Эти чипы позволяют нам производить аутентификацию и идентифицировать легитимные устройства Google на аппаратном уровне».
Третий уровень защиты — криптография, системы аутентификации и авторизации, которые обеспечивают надежную защиту коммуникаций между различными службами Google (и не важно, в одном дата-центре они расположены или нет, шифруется весь трафик, как внутренний, так и внешний). «Серверные машины Google используют различные технологии, чтобы удостовериться, что они работают с корректным программным стеком. Мы применяем криптографические подписи для таких низкоуровневых компонентов, как BIOS, бутлоадер, ядро и базовый образ ОС. Данные подписи проходят валидацию во время каждой загрузки или обновления. Все компоненты созданы и полностью контролируются Google».
Также Google уделяет особое внимание защите накопителей и имеет системы, призванные максимально осложнить «жизнь» потенциальной вредоносной прошивке и не позволить ей получить доступ к данным. «Мы применяем аппаратное шифрование для наших жестких дисков и SSD, и тщательно отслеживаем жизненный цикл каждого накопителя. Прежде чем зашифрованное устройство хранения будет списано и физически выйдет из-под нашего надзора, оно пройдет многоступенчатый процесс очистки, который включает две независимые проверки. Не прошедшие данную процедуру очистки устройства уничтожаются физически (измельчаются), это происходит локально».
Кроме того, документ описывает меры безопасности, которые Google применяет для защиты своих исходных кодов и поиска багов в них. Так, проверки кода разделены на проверки, осуществляющиеся вручную, и автоматические. Вручную код проверяет «команда, в которой присутствуют эксперты в областях веб-безопасности, криптографии и безопасности операционных систем». Зачастую в результате таких анализов на свет появляются новые фаззеры и библиотеки безопасности, которые затем используются в других продуктах.
Что касается исходных кодов, к их защите тоже подходят с большой ответственностью: «Исходные коды Google хранятся в центральном репозитории, где можно провести аудит как текущих, так и прошлых версий сервисов. Дополнительно инфраструктура может быть сконфигурирована таким образом, чтобы запрашивать бинарники сервиса из конкретного, проверенного и протестированного исходного кода. Такие проверки кода должны быть рассмотрены и одобрены по крайней мере еще одним инженером, помимо автора кода. Кроме того, система требует, чтобы модификации кода любых систем были одобрены владельцем данной системы. Эти требования ограничивают возможности инсайдера или нарушителя, не позволяя внести вредоносные изменения в исходные коды, а также создают криминалистический след, который можно отследить от сервиса к его источнику».
В документе можно найти еще много интересного. К примеру, оказалось, что виртуальные машины в облаках Google работают с кастомной версией гипервизора KVM. Разработчики Google даже похвастались и сообщили, что сотрудники Google обнаружили больше всех CVE и багов в Linux KVM гипервизоре.
На днях компания обнародовала документ Infrastructure Security Design Overview («Обзор модели инфраструктуры безопасности»), в котором Google достаточно подробно описала свои защитные механизмы. Инфраструктура разделена на шесть слоев, начиная от аппаратных решений (в том числе физических средств защиты), и заканчивая развертыванием служб и идентификацией пользователей.
Первый слой защиты – это физические системы безопасности, которые просто не позволяют посторонним попасть в дата-центры. Эта часть отчета похожа на отрывок из сценария фильма «Миссия невыполнима»: «Мы используем несколько слоев физической безопасности, чтобы защитить наши дата-центры. Мы применяем такие технологии, как системы биометрической идентификации, детекторы метала, камеры, барьеры, перекрывающие проезд транспортных средств, а также лазерные системы обнаружения проникновений».
Следующий уровень защиты – железо. Согласно документу, Google категорически не допускает использования устаревшего оборудования в своих дата-центрах. Более того, компания применяет кастомное оборудование от производителей, которые предварительно проходят тщательный аудит и валидацию. Также Google создает собственные средства аппаратной защиты: «Также мы создаем кастомные чипы, в том числе, чипы, являющиеся аппаратными средствами безопасности, которые в настоящий момент используются нашими серверами и периферийным оборудованием. Эти чипы позволяют нам производить аутентификацию и идентифицировать легитимные устройства Google на аппаратном уровне».
Третий уровень защиты — криптография, системы аутентификации и авторизации, которые обеспечивают надежную защиту коммуникаций между различными службами Google (и не важно, в одном дата-центре они расположены или нет, шифруется весь трафик, как внутренний, так и внешний). «Серверные машины Google используют различные технологии, чтобы удостовериться, что они работают с корректным программным стеком. Мы применяем криптографические подписи для таких низкоуровневых компонентов, как BIOS, бутлоадер, ядро и базовый образ ОС. Данные подписи проходят валидацию во время каждой загрузки или обновления. Все компоненты созданы и полностью контролируются Google».
 |
| Работа внутренних систем service identity и access management |
Также Google уделяет особое внимание защите накопителей и имеет системы, призванные максимально осложнить «жизнь» потенциальной вредоносной прошивке и не позволить ей получить доступ к данным. «Мы применяем аппаратное шифрование для наших жестких дисков и SSD, и тщательно отслеживаем жизненный цикл каждого накопителя. Прежде чем зашифрованное устройство хранения будет списано и физически выйдет из-под нашего надзора, оно пройдет многоступенчатый процесс очистки, который включает две независимые проверки. Не прошедшие данную процедуру очистки устройства уничтожаются физически (измельчаются), это происходит локально».
Кроме того, документ описывает меры безопасности, которые Google применяет для защиты своих исходных кодов и поиска багов в них. Так, проверки кода разделены на проверки, осуществляющиеся вручную, и автоматические. Вручную код проверяет «команда, в которой присутствуют эксперты в областях веб-безопасности, криптографии и безопасности операционных систем». Зачастую в результате таких анализов на свет появляются новые фаззеры и библиотеки безопасности, которые затем используются в других продуктах.
Что касается исходных кодов, к их защите тоже подходят с большой ответственностью: «Исходные коды Google хранятся в центральном репозитории, где можно провести аудит как текущих, так и прошлых версий сервисов. Дополнительно инфраструктура может быть сконфигурирована таким образом, чтобы запрашивать бинарники сервиса из конкретного, проверенного и протестированного исходного кода. Такие проверки кода должны быть рассмотрены и одобрены по крайней мере еще одним инженером, помимо автора кода. Кроме того, система требует, чтобы модификации кода любых систем были одобрены владельцем данной системы. Эти требования ограничивают возможности инсайдера или нарушителя, не позволяя внести вредоносные изменения в исходные коды, а также создают криминалистический след, который можно отследить от сервиса к его источнику».
В документе можно найти еще много интересного. К примеру, оказалось, что виртуальные машины в облаках Google работают с кастомной версией гипервизора KVM. Разработчики Google даже похвастались и сообщили, что сотрудники Google обнаружили больше всех CVE и багов в Linux KVM гипервизоре.
Comments