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

ЭПД с 1 сентября: Минтранс говорит, что всё готово, бизнесу пора шевелиться

До обязательного перехода на электронные перевозочные документы (ЭПД) остаётся чуть больше двух месяцев, и государство уверяет: технически всё готово. А вот бизнесу ещё предстоит серьёзно перестроить свои процессы. Этот вопрос стал одной из главных тем форума «ЭДО. ЭПД», который прошёл в конце мая в Подмосковье.

Представители Минтранса, ФНС, операторов электронного документооборота и транспортных компаний обсудили, насколько рынок готов к цифровой революции, намеченной на 1 сентября 2026 года.

По данным Минтранса, государственная система ГИС ЭПД работает с 2022 года и уже обработала более 38 миллионов документов. Инфраструктура рассчитана на дальнейший рост нагрузки, а уровень её доступности заявлен на уровне 99,5%.

 

Один из главных страхов перевозчиков — потеря связи в дороге. Власти утверждают, что этот сценарий предусмотрен. Если интернет пропал, перевозчик сможет подтвердить это справкой от оператора связи и подписать документы позже. Кроме того, сейчас прорабатываются механизмы офлайн-подписания документов.

Но если с технологиями всё выглядит относительно неплохо, то с бизнес-процессами ситуация сложнее.

 

Участники рынка признают, что многие компании ещё не готовы к полноценному электронному документообороту. Нужно перестраивать внутренние регламенты, обучать сотрудников и подключать контрагентов.

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

Представители операторов ЭДО считают, что откладывать внедрение уже поздно. По их мнению, успех реформы будет зависеть не только от государства и технологий, но и от того, насколько быстро участники рынка смогут договориться между собой и отказаться от привычных бумажных схем.

На фоне подготовки к запуску ЭПД Минтранс также развивает платформу «ГосЛог», систему СПОТ для контроля поставок из стран ЕАЭС и отраслевой центр компетенций по кибербезопасности.

Государство считает, что цифровая инфраструктура уже почти готова. Теперь очередь за бизнесом, которому предстоит научиться жить без бумажек.

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