Google раскрыл подробности обеспечения безопасности своей инфраструктуры

Google раскрыл подробности обеспечения безопасности своей инфраструктуры

Google раскрыл подробности обеспечения безопасности своей инфраструктуры

Компания Google опубликовала обзор мер, предпринимаемых для обеспечения безопасности серверной инфраструктуры. Рассмотрены меры по обеспечению безопасности серверов, сетевой инфраструктуры, использование аутентификации.  

Некоторые интересные особенности:

  • Во всех серверах используются собственные материнские платы и сетевые компоненты, разработанные инженерами Google и произведённые под контролем представителей компании. Оборудование, включая периферийные устройства, оснащены специальным чипом, отвечающим за безопасную идентификацию и аутентификацию устройства на аппаратном уровне. Программные компоненты, включая прошивки, загрузчики, ядро и базовые образы систем проверяются по цифровой подписи. Таким образом в инфраструктуре могут применяться только проверенные аппаратные и программные элементы, содержащие корректную цифровую подпись.
  • В ситуациях, когда серверное оборудование приходится размещать в чужих датацентрах, оборудование Google отгораживается в собственный периметр физической безопасности, в котором для доступа применяются независимые биометрические датчики, камеры наблюдения и металлодетекторы.
  • Данные записываются на жесткие диски и SSD-накопители только в зашифрованном виде, что позволяет защитить их от несанкционированного доступа и возможных вредоносных действий, инициируемых со стороны прошивок, используемых в накопителях. Шифрование реализуется на аппаратном уровне. Жизненный цикл каждого накопителя скрупулезно отслеживается - если накопитель выходит из под контроля Google, он проходит многоэтапный процесс очистки с двумя независимыми проверками качества исполнения операции. Если устройство не может быть очищено, например, в результате сбоя накопителя, оно подвергается физическому уничтожению в измельчителе, передает opennet.ru.
  • Для выполнения виртуальных машин в облачной инфраструктуре Google применяется модифицированная версия гипервизора KVM, исправления всех проблем в котором возвращаются в upstream. Для ограничения отдельных сервисов в виртуальных машинах может применяться более высокий уровень изоляции на основе контейнеров и sandbox-технологий.
  • Весь создаваемый сотрудниками код проходит несколько стадий проверки, включая fuzzing-тестирование, статический анализ, автоматическое и ручное рецензирование. Ручное рецензирование проводится специальной группой, в которую входят эксперты в области безопасности, криптографии и защиты операционных систем. Код также должен быть одобрен как минимум одним сторонним инженером, не входящем в число авторов проверяемого проекта. С другой стороны, все вносимые в код правки обязательно должны быть подтверждены сопровождающим, ответственным за этот код.
  • Весь развиваемый в Google исходный код хранится в одном централизованном репозитории, в котором для аудита доступны все текущие и прошлые версии сервисов. Серверная инфраструктура может быть настроена на выполнение бинарных файлов сервиса, собранных только из определённой ревизии исходных текстов, прошедшей тестирование и рецензирование.
  • Разделения сети на сегменты и применение пакетных фильтров не относится к числу первичных систем обеспечения безопасности, внутренняя сетевая безопасность основывается на разделении полномочий на уровне доступа к отдельным сервисам и приложениям. Сотрудник получает доступ к ограниченному числу внутренних приложений, которые принимают запросы от работника только в контексте обращения с корректно обслуживаемой клиентской системы, из разрешённой подсети и ожидаемого физического местоположения (например, персонал, отвечающий за Gmail имеет доступ только к сервисам, связанным с данной системой).
  • Обмен данными между сервисами осуществляется с применением шифрования и криптографических методов аутентификации и авторизации. Каждый сервис выполняется в общей инфраструктуре, имеет свой криптографический идентификатор, который используется для идентификации сервиса при приёме запросов или обращении к другим сервисам. Криптографические идентификаторы также используется клиентами, чтобы удостовериться, что они обратились к требуемому серверу, и серверами для ограничения доступа клиентов к данным и методам.

 

 

  • При необходимости обработки сервисами запросов из глобальной сети применяется специальная прослойка - Google Front End (GFE), которая проверяет корректность сертификатов для TLS-соединений, выполняет балансировку нагрузки и осуществляет защиту от DoS-атак. Полученный запрос перенаправляется к сервису с использованием защищённого внутреннего RPC-протокола.
  • Для персонала применяется двухфакторная аутентификация. Применяемые сотрудниками клиентские системы проверяются на предмет применения всех имеющихся обновлений и установки только разрешённых приложений. Пользовательские приложения, загрузки файлов, браузерные расширения и просматриваемый web-контент проходит проверку на предмет допустимости использования на корпоративных клиентских устройствах.
  • Все действия сотрудников, требующие расширенных привилегий, по возможности автоматизированы. При необходимости проведения ручной работы по администрированию инфраструктуры или привилегированного доступа к системам требуется получения разрешения от двух ответственных лиц и по возможности открывается доступ к ограниченному отладочному API, позволяющему произвести отладку не касаясь конфиденциальной информации. Весь доступ сотрудников к пользовательской информации отслеживается и журналируется через систему низкоуровневых обработчиков. Работники службы безопасности и автоматизированные системы выполняют мониторинг активности сотрудников и выявляют нетипичную активность.
Anti-Malware Яндекс ДзенПодписывайтесь на канал "Anti-Malware" в Telegram, чтобы первыми узнавать о новостях и наших эксклюзивных материалах по информационной безопасности.

Обновление WinAppSDK сломало механизм деинсталляции в Windows 10

C 12 ноября ряд пользователей Windows 10 столкнулись с проблемой обновления и деинсталляции пакетных приложений вроде Microsoft Teams. Microsoft подтвердила наличие бага и отозвала обновление WinAppSDK.

Судя по всему, проблема вызвана пакетом WinAppSDK версии 1.6.2, которая автоматом установилась в системы пользователей после инсталляции приложения, разработанного с использованием Win App SDK.

На затронутых устройствах, работающих под управлением Windows 10 22H2, выводилась ошибка «Something happened on our end» в разделе «Загрузки» Microsoft Store.

«Если вы системный администратор и пытаетесь управлять приложениями через PowerShell с помощью команды “Get-AppxPackage“, система может выдать вам ошибку “Deployment failed with HRESULT: 0x80073CFA“», — объясняет Microsoft.

«Вы также можете столкнуться с проблемами обновления или переустановки Microsoft Teams и других сторонних приложений».

Корпорация пока отозвала проблемную версию WinAppSDK 1.6.2. Один из разработчиков Майк Кридер уточнил, что фикс стоит ждать с выходом WinAppSDK 1.6.3.

Anti-Malware Яндекс ДзенПодписывайтесь на канал "Anti-Malware" в Telegram, чтобы первыми узнавать о новостях и наших эксклюзивных материалах по информационной безопасности.

RSS: Новости на портале Anti-Malware.ru