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 гипервизоре.

Comments

Popular posts from this blog

Порно, которое лопнуло

В августе 2010 года студия Paramount Pictures выпустила в прокат фильм Middle Men («Меж двух огней»). Действие этой трагикомедии происходит в середине 90х годов: главный герой, Джек Харрис, создает первую в мире электронную платежную систему, специализирующуюся на обслуживании порносайтов. Харрис попадает в одну неприятную ситуацию за другой: его преследуют агенты ФБР, русские бандиты и международные террористы, но в итоге он выходит сухим из воды. Фильм провалился в прокате: при бюджете в $22 млн собрал за три недели всего $733 000, зато стал одним из самых обсуждаемых в сети релизов 2010 года.

Продюсер картины — Кристофер Маллик, а сам фильм основан на истории его собственной жизни. Маллик стал известен как владелец системы ePassporte, крупнейшего платежного сервиса сайтов для взрослых. Через месяц после выхода фильма у ePassporte начались проблемы: VISA отказалась обслуживать платежи. В начале октября система закрылась. Не только мировая порноиндустрия понесла тяжелую утрату — бизне…

Чем рискуют дропы и нальщики принимая заливы на свои карты

Зам.начальника управления Следственного департамента МВД Павел Сычев рассказал о криминальном бизнесе «нальщиков»
- Глава Банка России Эльвира Набиуллина заявила о снижении объемов теневого оборота в конце 2013 года. Что показывает ваша статистика по выявлению незаконных операций?

- В последние годы объем денежных средств, выведенных в теневой сектор, увеличивался, и криминогенная обстановка ухудшалась. Проблема находится в поле зрения президента -  в декабрьском послании Федеральному Собранию, он призвал избавить нашу финансовую систему от разного рода «отмывочных контор» и так называемых «прачечных». Оперативники уже получили ориентировку на более активное выявление этих преступлений.

По уголовным делам, расследованным МВД только в первом полугодии 2013 года, проходит 145 млрд рублей, обналиченных и незаконно выведенных заграницу. Это неуплаченные налоги, незаконный бизнес, хищения, взятки. Финансовый доход посредников от этих операций составил 8 млрд рублей. Расследовано 89 таких дел …

Кому нужны дропы?

в этом видео хорошо показана жизнь одного современного человека,
который начал налить белый пластик

полезно посмотреть начинающим дропам - как вести себя со своим дроповодом, и что нужно рассказывать в полиции, в случае если вы туда попали



Залив на карту без предоплаты по SWIFT или SEPA

В последнее время наблюдается такая ситуация, что нальщиков и дропов на рынке много, а адекватных заливщиков, можно сказать, совсем нет.


Например, один мой хороший знакомый, имеющий свой собственный офшор, работает с заливщиками на условиях партнерства, предоставляя им трафик и взамен получая 20% от поведенных транзакций на свой счет в офшорном банке. Мне он рассказал по большому секрету, как такое ему удается, а начинал он как и все с малого - продажи дебетовых карт и игре на рынке FOREX.

Просто так искать Заливщиков на различных форумах, посвящённых обналу и отмыванию денег - достаточно муторное и нудное занятие, потому как после общения с десятым по счету заливщиком, начинаешь понимать, что просто так на карты и счета никто лить не будет.

Однако моему другу попался один довольно интересный вариант - Заливщик предложил сделать перевод в размере 375 000 EUR по SEPA в день предоставления готового к работе счета и активной системы Multihomed AS.



Остальные предложения были более мутные …

Black Hat SEO или бот для скликивания контекстной рекламы

На днях мне стало интересно, а каким образом с точки зрения «черных» методов SEO могут быть использованы хакерские программы – например, путем генерации трафика для заинтересованных ресурсов или скликивания контекстной рекламы AdWords или Яндекс.Директ
Понятно, что увеличение числа посетителей на сайте интернет-магазина или компании, занимающейся недвижимостью, вероятнее всего положительно скажется на их доходах. Поэтому разработка подобного типа программ — вполне себе обыденное дело, и появились такие программы уже давно. По большей части таких ботов можно разделить на два класса — это различного рода Adware, которое распространяется вместе с популярными программами, или трояны, которые осуществляют более серьезную модификацию системы.  Win32/Patched.P Давай для начала рассмотрим достаточно экзотический, но от этого не менее интересный способ подмены результатов поиска в популярных поисковых сервисах Яндекс и Google, который был реализован в троянской программе Win32/Patched.P (ESET)…

М9 - точка обмена трафиком • Московский INTERNET EXCHANGE • MSK-XI

Вот так всё начиналось
Изначально был всего один провайдер - Релком. Не было конкурентов - не было проблем. Рунет еще делал свои первые шаги, и все русскоязычные ресурсы были сосредоточены в одном месте. Позже Релком развалился на Релком и Демос, стали появляться другие провайдеры. Рунет тем временем подрос и... распался на множество отдельных сетей-сегментов, контролируемых разными провайдерами. Разумеется, конечные пользователи имели доступ ко всем ресурсам рунета, но прямого взаимодействия между провайдерами не было. Поэтому трафик шел с сервера одного провайдера по огромной петле через Америку, потом Германию, и только потом возвращался на сервер другого провайдера. Имела место неоправданная потеря и в скорости, и в деньгах. Пока трафик был незначительным, это мало кого волновало, но интернет бурно развивался, трафик по рунету стремительно увеличивался, и в один прекрасный день крупные провайдеры Москвы (по сути, Демос и Релком) сели друг напротив друга и решили, что им надо налаж…