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

Виртуальная сеть на базе 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 и подобные) Что касается открытых протоколов, – вероятность того, что они попадутся во время сбора пакетов проходящего мимо трафика в коммутируемой сети, достаточно мала. Однако, если такого трафика много, то в обследуемой сети явно наблюдаютс…

Инженер электросвязи майнил BitCoin на $ 9.000 в день

Исследователь безопасности Эдвард Сноуден, ранее работавший в компании Booz Allen Hamilton говорит, что он обнаружил ряд совершенных одним системным оператором Bell Canada неавторизованых транзакций Bitcoin.



Для генерации биткоинов инженер электросвязи скомпрометировал пулы. В свою очередь, участники пулов продолжали отдавать часть производительности своих компьютеров на поиск блока криптографического алгоритма Bitcoin, при этом все получаемые им доходы доставались системному инженеру Bell Canada. Техника перенаправления обманывала участников для того, чтобы продолжать искать блок криптографических алгоритмов Bitcoin, позволяя сетевому оператору сохранить доходы на свой счёт. На пике своей деятельности, согласно подсчетам Сноудена, инженер электросвязи из Bell Canada перехватывал поток биткоинов и других цифровых валют, включая dogecoin и worldcoin, и обналичивал их в сумме около $9 000 в день.

Сноуден считает, что сетевой инженер из Bell Canada применил стандартные команды управлени…