Skip to main content

Google Infrastructure Security Design Overview

Обычно компании предпочитают хранить в тайне особенности своей инфраструктуры безопасности, которая стоит на защите дата-центров, полагая, что раскрытие подобной информации может дать атакующим преимущество. Однако представители Google смотрят на этот вопрос иначе. На то есть две причины. Во-первых, публикация таких отчетов позволяет потенциальным пользователям Google Cloud Platform (GCP) оценить безопасность служб компании. Во-вторых, специалисты Google уверены в своих системах безопасности.

На днях компания обнародовала документ Infrastructure Security Design Overview («Обзор модели инфраструктуры безопасности»), в котором Google достаточно подробно описала свои защитные механизмы. Инфраструктура разделена на шесть слоев, начиная от аппаратных решений (в том числе физических средств защиты), и заканчивая развертыванием служб и идентификацией пользователей.

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

Следующий уровень защиты – железо. Согласно документу, Google категорически не допускает использования устаревшего оборудования в своих дата-центрах. Более того, компания применяет кастомное оборудование от производителей, которые предварительно проходят тщательный аудит и валидацию. Также Google создает собственные средства аппаратной защиты: «Также мы создаем кастомные чипы, в том числе, чипы, являющиеся аппаратными средствами безопасности, которые в настоящий момент используются нашими серверами и периферийным оборудованием. Эти чипы позволяют нам производить аутентификацию и идентифицировать легитимные устройства Google на аппаратном уровне».

Третий уровень защиты — криптография, системы аутентификации и авторизации, которые обеспечивают надежную защиту коммуникаций между различными службами Google (и не важно, в одном дата-центре они расположены или нет, шифруется весь трафик, как внутренний, так и внешний). «Серверные машины Google используют различные технологии, чтобы удостовериться, что они работают с корректным программным стеком. Мы применяем криптографические подписи для таких низкоуровневых компонентов, как BIOS, бутлоадер, ядро и базовый образ ОС. Данные подписи проходят валидацию во время каждой загрузки или обновления. Все компоненты созданы и полностью контролируются Google».

Работа внутренних систем service identity и access management
Работа внутренних систем service identity и access management



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

Кроме того, документ описывает меры безопасности, которые Google применяет для защиты своих исходных кодов и поиска багов в них. Так, проверки кода разделены на проверки, осуществляющиеся вручную, и автоматические. Вручную код проверяет «команда, в которой присутствуют эксперты в областях веб-безопасности, криптографии и безопасности операционных систем». Зачастую в результате таких анализов на свет появляются новые фаззеры и библиотеки безопасности, которые затем используются в других продуктах.

Что касается исходных кодов, к их защите тоже подходят с большой ответственностью: «Исходные коды Google хранятся в центральном репозитории, где можно провести аудит как текущих, так и прошлых версий сервисов. Дополнительно инфраструктура может быть сконфигурирована таким образом, чтобы запрашивать бинарники сервиса из конкретного, проверенного и протестированного исходного кода. Такие проверки кода должны быть рассмотрены и одобрены по крайней мере еще одним инженером, помимо автора кода. Кроме того, система требует, чтобы модификации кода любых систем были одобрены владельцем данной системы. Эти требования ограничивают возможности инсайдера или нарушителя, не позволяя внести вредоносные изменения в исходные коды, а также создают криминалистический след, который можно отследить от сервиса к его источнику».

В документе можно найти еще много интересного. К примеру, оказалось, что виртуальные машины в облаках Google работают с кастомной версией гипервизора KVM. Разработчики Google даже похвастались  и сообщили, что сотрудники Google обнаружили больше всех CVE и багов в Linux KVM гипервизоре.

Popular posts from this blog

Attacking BGP routers for BitCoin hijacking

A few days ago researchers at Dell SecureWorks published the details of an attacker repeatedly hijacking BGP prefixes for numerous large providers such as Amazon, OVH, Digital Ocean, LeaseWeb, Alibaba and more. The goal of the operation was to intercept data between Bitcoin miners and Bitcoin mining pools. They estimated that $83,000 was made with this attack in just four months. Let's take a closer look at  the BGP details of this specific attack.

BGP Attack details Our friends at Dell SecureWorks decided not to name the network from which the hijacks originated. As a result we won’t name the exact Autonomous System either, instead we will suffice by saying that the originator of this hijack is a network operating in Eastern Canada.



Initial experiment
BGPmon detected the first BGP attack by this Canadian Autonomous System on October 8th 2013. For about 14 minutes a more specific /24 IP prefix for a Palestinian network was hijacked. Looking at geographical scope of the announcements a…

Виртуальная сеть на базе Cisco CSR 1000V

Во время обучения, для того чтобы лучше разобраться как работает та или иная технология я пользовался и программой моделирования сетей DYNAGEN, и удаленным доступом к стенду с реальным оборудованием, любезно предоставленным нам организаторами обучения. Это, конечно же очень помогало, но меня все время не оставляла мысль найти какой-то вариант, который позволил бы иметь ощущение реальности при работе с устройством и в тоже время чтобы я мог его крутить так как мне захочется и в любое время, когда мне захочется. Я пробовал и GNS3, и IOU, при этом продолжая поиски. Так я узнал о таком продукте от CISCO как CSR 1000V Cloud Services Routerhttp://www.cisco.com/c/en/us/products/routers/cloud-services-router-1000v-series/index.html , скачать который можно в нашей подборке Cisco IOS. Небольшие выдержки из документации:
«Развернутый на виртуальной машине Cisco CSR 1000V с IOS XE обеспечивает точно такую же функциональность, как если бы IOS XE работала на традиционной аппаратной платформе Cis…

Проникновение в сеть оператора связи

Перво наперво стоит провести анализ идущего мимо сетевого трафика с помощью любого сетевого анализатора в "неразборчивом" режиме работы сетевой карты (promiscuous mode). В качестве сетевого анализатора для подобных целей замечательно подходит Wireshark или CommView. Чтобы выполнить этот этап, хватит и пары часов работы сетевого анализатора. По прошествии этого времени накопится достаточно данных для проведения анализа перехваченного трафика. И в первую очередь при его анализе следует обратить внимание на следующие протоколы: протоколы коммутации (STP, PVST+, CDP, DTP, VTP, и им подобные)протоколы маршрутизации (RIP, BGP, EIGRP, OSPF, IS-IS и другие)протоколы динамической конфигурации узла (DHCP, BOOTP)открытые протоколы (telnet, rlogin и подобные) Что касается открытых протоколов, – вероятность того, что они попадутся во время сбора пакетов проходящего мимо трафика в коммутируемой сети, достаточно мала. Однако, если такого трафика много, то в обследуемой сети явно наблюдаютс…