Практика архитектуры Google Zero Trust

Предыстория

Автор этой статьи — Чэнь Чжицзе, которому посчастливилось участвовать в производственной среде Google с 2015 по 2020 год.Нулевое довериеТеория и практика (нулевого доверия к производственной среде). Система двоичной авторизации для Borg (BAB), разработанная в этом контексте, достигла полного охвата производственной среды Google: прежде чем кто-либо сможет запустить какой-либо пакет в качестве любой службы в производственной среде, необходимо установить достаточную авторизацию для целевой службы. политика. Программам, не соответствующим политикам безопасности BAB, не будет разрешено работать в качестве соответствующих служб.

В процессе внедрения и продвижения этой производственной среды с нулевым доверием команда BAB пошла по многим путям, но также приобрела большой опыт. Начиная с 2017 года команда BAB начала превращать этот практический опыт в теорию и последовательно выпустила серию официальных документов ( BeyondProd, Бинарная авторизация для Borg, SLSA: уровни цепочки поставок для программных артефактов), книги ( Создание безопасных и надежных систем) и отчеты ( Переходите к модели безопасности с нулевым доверием с помощью Anthos Security, Нулевой сенсорный продукт). В то же время эта концепция нулевого доверия также начала распространяться на большее количество сценариев применения, включая нулевое доверие к общедоступному облаку, нулевое доверие к собственной инфраструктуре публичного облака, а также нулевое доверие при разработке Android и Сами Chrome и их приложения.

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

Что такое нулевое доверие

Что такое нулевое доверие? Разные люди, скорее всего, дадут разные ответы. Некоторые говорят, что нулевое доверие — это микросегментация рабочей нагрузки; некоторые говорят, что нулевое доверие — это непрерывный мониторинг угроз; некоторые говорят, что нулевое доверие — это замена доверия в сети доверием на стороне узла (доверять конечным точкам, а не сети); другие говорят, что нулевое доверие — это двусторонняя аутентификация TLS (mTLS). Все это имеет смысл, но, очевидно, не является всеобъемлющим.

Здесь автор хотел бы позаимствовать шутку про машинное обучение: «Машинное обучение — это прославленная статистика». Аналогично, нулевое доверие — это прославление наименьшего авторитета. Это, очевидно, также неточно, поскольку и машинное обучение, и нулевое доверие уделяют больше внимания конкретным проблемам и сценариям приложений, чем статистике и минимальным привилегиям. Машинное обучение и нулевое доверие — это не одна дисциплина или теория, а инновационные практики в различных областях (таких как математика, компьютерная архитектура, распределенные системы, системы хранения данных, сети и т. д.), разработанные для решения практических задач.

Видно, что для нулевого доверия нам не нужно быть слишком жесткими в определениях и теориях, а следует сочетать это с практикой и начинать с конкретных задач и сценариев применения, которые необходимо решить. Поэтому мы временно объединяем проблемы и сценарии применения в этой статье, чтобы определить нулевое доверие как: начиная с данных и разрешений, подлежащих защите, комплексное снижение и реконструкция доверия в производстве в отношении защищенных данных и привилегий).

Более важный вопрос, чем определение нулевого доверия: почему вы хотите использовать нулевое доверие?

Зачем нам нужно нулевое доверие?

Зачем нам нужно нулевое доверие? Самая важная причина заключается в том, что у нас есть некоторые важные данные или разрешения, которые необходимо защитить, и существующая система безопасности больше не может обеспечить достаточную защиту в эпоху облачных технологий. Личные данные пользователей, данные о зарплате сотрудников, разрешения на смену паролей, разрешения на отключение ключевых систем и т. д. — все это защищенные объекты. Эти данные и разрешения изначально защищены контролем доступа к сети на основе безопасности периметра, например интрасети компании и VPN.Когда устройство подключается к интрасети компании, оно наследует возможность получения этих данных и разрешений. Позже люди начали вводить контроль доступа на основе IP или имени пользователя и пароля, а также более детальный контроль доступа на основе личности и роли (Идентификация и роль). Однако они больше не могут соответствовать требованиям защиты данных и разрешений в облачной среде, особенно в сложных корпоративных ИТ-системах, таких как Google.

Использование облачных технологий сопряжено со следующими проблемами. Во-первых, корпоративные ИТ-системы превратились из модели одного компьютерного зала в модель кросс-облачного гибрида (мульти- и гибридного облака), что привело к размытию границ и неэффективности безопасности, основанной на границах. защита; во-вторых, вычисления на основе контейнеров (контейнеров) приводят к неопределенности хоста. Одна и та же услуга может быть перенесена с одного физического хоста на другой физический хост в любое время, не находясь в автономном режиме. Это делает защиту безопасности на основе хоста более невозможной. Дальнейшая реализация глубокая защита на основе сервисной логики; в-третьих, микросервисы (Microservices) и детальные API увеличивают поверхность атаки. Идентичность и роль — это уже не просто личность и роль конечного пользователя, а более важные аспекты взаимодействия между микросервисами. Детализированная идентификация и контроль доступа.

Начиная с ситуации в Google на тот момент, примерно в 2015 году, мы внедрили внутри себя относительно зрелую систему управления правами, основанную на ключах и аутентификации личности, но наше внимание привлекли две угрозы безопасности: во-первых, пост-Сноуден. центр обработки данных, как установить взаимное доверие и как гарантировать, что скомпрометированный хост или скомпрометированная служба не повлияет на другие части производственной среды? Во-вторых, когда у нас есть хорошая система авторизации и аудита для одноразового доступа к данным и разрешениям, как бороться с крупномасштабной утечкой данных, вызванной пакетными (пакетными) данными и доступом с разрешениями, такими как машинное обучение?Скрытая опасность? Необходимо срочно создать систему управления и контроля инсайдерских рисков, основанную на нулевом доверии.

Конечно, все это основано на прочных традиционных основах безопасности: системах защиты сети и хоста, доверенной загрузке, системах управления ключами, системах аутентификации и управления идентификацией и т. д. Zero Trust — это надстройка, построенная на этом фундаменте безопасности.

Три элемента нулевого доверия: цепочка доверия, Identity 2.0 и постоянный контроль доступа.

Цепочка доверия, идентификация 2.0 и непрерывный контроль доступа — три основных элемента нулевого доверия.

цепочка доверия

Нулевое доверие означает не отсутствие доверия вообще, а четкий процесс восстановления цепочки доверия (Chain of Trust), начиная с нескольких базовых минимальных корней доверия (Root of Trust). Несколько типичных примеров включают в себя: Многофакторная аутентификация (MFA) — это корень доверия для идентификации человека; Доверенный платформенный модуль (TPM) и Доверенная загрузка (Trusted Boot) — это удостоверение машины. Корень доверия; исходный код и доверенная сборка ( Trusted Build) являются основой доверия к программному обеспечению. Доверие в огромной ИТ-системе начинается с этих самых основных корней доверия и создает полную цепочку доверия посредством ряда стандартизированных процессов (некоторые называют это Деревом доверия или Сетью доверия). Доверие).

Айдентика 2.0

Identity 2.0 — это стандартизация вышеупомянутой цепочки доверия, позволяющая использовать информацию, собранную в процессе установления доверия, в политиках безопасного доступа. В Identity 2.0 все объекты имеют идентификаторы, пользователи имеют идентификаторы пользователей, сотрудники имеют идентификаторы сотрудников, машины имеют идентификаторы компьютеров, а программное обеспечение также имеет идентификаторы программного обеспечения; в Identity 2.0 все виды доступа имеют несколько идентификаторов (также известный как контекст доступа), например , доступ к строке данных в базе данных будет иметь что-то вроде «Чтобы помочь пользователю решить техническую проблему, сотрудник A запросил доступ к машине D через программное обеспечение C с авторизацией пользователя B».

Постоянный контроль доступа

Благодаря обширной исходной информации об идентификации и доступе, предоставляемой Identity 2.0, мы можем создать на ее основе систему непрерывного контроля доступа (Continous Access Control). Непрерывный контроль доступа постоянно контролирует доступ во всех аспектах разработки и эксплуатации программного обеспечения. Несколько типичных примеров включают: требование многофакторной аутентификации при входе сотрудников в систему; требование, чтобы программное обеспечение было создано из доверенной библиотеки исходного кода в безопасной среде и проходило проверку кода (Code Review) при развертывании программного обеспечения; при установлении соединения между микросервисами оба стороны обязаны предоставить сертификаты целостности хоста; когда микросервис получает определенные пользовательские данные, требуется токен авторизации пользователя (токен авторизации).

Пример развертывания с нулевым доверием

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

Пользователи получают доступ к своим данным

Когда пользователь получает доступ к своим данным через службы Google, запрос сначала достигает GFE через зашифрованное соединение (TLS) между пользователем и интерфейсом Google (GFE). GFE переключается на более эффективные и безопасные протоколы и структуры данных для распределения пользовательских запросов на различные серверные службы для совместного выполнения пользовательских запросов. Например, TLS будет заменен наTLS прикладного уровня (ATLS). Пароли, доступные пользователю, преобразуются в более безопасные билеты контекста конечного пользователя (EUC). Эти перестановки предназначены для уменьшения разрешений внутренних подключений и токенов на основе фактического запроса, чтобы определенные ATLS и EUC могли получать доступ только к данным и разрешениям, ограниченным этим запросом.

Ниже приведеныBeyondProdИсходное изображение. Разработчик на изображении на самом деле должен быть Пользователем:

Разработчики меняют поведение программного обеспечения при доступе к данным

Когда разработчик хочет изменить поведение службы при доступе к данным и разрешениям путем изменения кода службы (разработчик не может получить какие-либо разрешения на выполнение команд на рабочем хосте, например SSH), модификация кода будет проходить через ряд процессов, чтобы влияют на процесс разработки.Доверие автора и его команды трансформируется в доверие к новому сервису: весь задействованный в процессе персонал устанавливает свою личность посредством многофакторной аутентификации, а модификации кода будут оцениваться с одобрением одним или несколькими людьми. Полномочия. Получены только при наличии достаточной авторизации. Только после этого код будет объединен с центральной базой кода. Код в центральной базе кода будет централизованно создан, протестирован и подписан доверенной службой сборки, которая также защищена BAB. программное обеспечение пройдет сертификацию политики BAB целевой службы во время процесса развертывания (например, служба GMail может запускать только код, который был полностью оценен и протестирован в определенном месте базы кода). также будут изолированы в соответствии с соответствующей политикой безопасности BAB: службы, регулируемые различными политиками обслуживания BAB, будут запускаться в разных карантинных зонах.

Ниже приведеныBeyondProdОригинальное изображение, подробности смотрите в исходном тексте:

Практический опыт и уроки

Ставьте людей на первое место и укрепляйте доверие в процессе

При использовании BeyondCorp для реализации нулевого доверия в среде разработки (Corp Environment) мы ставим людей на первое место и проводим управление идентификацией и многофакторную аутентификацию для сотрудников. При этом мы наладили процесс управления устройствами компании, и каждое устройство компании оснащено модулями TPM и проверкой целостности операционной системы. Эти два усилия гарантируют, что нужный человек, использующий правильное устройство, предоставит достоверную информацию для аутентификации. Наконец, мы используем эту информацию аутентификации для постоянного контроля доступа сотрудников к среде разработки.

При использовании BeyondProd для реализации нулевого доверия в производственной среде (Prod Environment) мы также стараемся использовать людей и процессы в качестве основы доверия. Проблема, с которой сталкивается BeyondProd, заключается в том, что производственная среда не имеет прямого взаимодействия с людьми, поэтому мы установили набор программного обеспечения для отслеживания в производственной среде разработчиков этого программного обеспечения (Software Provenance), начиная с сертификации и разработки разработчиков. процесс начинает гарантировать, что ни один человек не сможет изменить поведение программного обеспечения в производственной среде (без односторонних изменений).

уровень правил безопасности

Рим не был построен за один день, и продвижение нулевого доверия также является постепенным процессом. Для количественной оценки и стимулирования улучшений безопасности мы используем рейтинги правил безопасности, чтобы определить, является ли одно правило безопасности «безопаснее» другого. Например, в системе двоичной авторизации для Borg мы ввели следующие уровни безопасности:

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

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

Уровень безопасности 2: Доверенный код. Помимо обеспечения уровня безопасности 1, этот уровень правил безопасности также гарантирует, что программное обеспечение, используемое соответствующей службой, создано на основе кода, который был проверен и протестирован в определенной базе кода (например, собственной базе кода Gmail). По состоянию на февраль 2020 года этот уровень является уровнем защиты по умолчанию для всех сервисов Google.

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

Сигнализация и система авторизации

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

Будьте в безопасности и стабильны

Сложность нулевого доверия определяет, что он также столкнется с новыми проблемами в поддержании стабильности системы (надежности). В процессе практики нулевого доверия мы предоставляем механизм аварийного разбивания стекла (Break-glass Mechanism) для большинства сценариев. Это гарантирует, что в чрезвычайной ситуации операторы смогут преодолеть ограничения системы нулевого доверия и выполнить некоторые сложные экстренные операции. Чтобы обеспечить постоянную безопасность, как только будет вызван механизм аварийного взлома, группа безопасности немедленно получит сигнал тревоги, и все операции в рамках механизма взлома также будут подробно записаны в журнале безопасности. Эти журналы безопасности тщательно проверяются на предмет необходимости взлома. Эти журналы безопасности также помогут разработать новые функции нулевого доверия, чтобы избежать повторного вызова механизмов аварийного взлома в аналогичных ситуациях.

Обратите внимание на эндогенные риски

С точки зрения защиты, эндогенные риски представляют собой надмножество экзогенных рисков: когда злоумышленник компрометирует устройство любого инсайдера (законного пользователя или сотрудника), злоумышленник становится инсайдером, независимо от того, является ли это внешним злоумышленником. нарушителей, они в конечном итоге станут эндогенными рисками. С этой точки зрения нулевое доверие предполагает, что любой хост может быть скомпрометирован.

Инфраструктура безопасности

Реализация нулевого доверия опирается на прочную базовую архитектуру безопасности. Без фундамента не будет надстройки. Google Zero Trust использует следующую инфраструктуру для обеспечения базовой безопасности:

1. Шифрование данных и управление ключами (Encryption and Key Management)
2. Управление идентификацией и доступом
3. Цифровые человеческие ресурсы
4. Управление цифровыми устройствами
5. Безопасность дата-центра
6. информационная безопасность(Сетевая безопасность)
7. Безопасность хоста
8. Изоляция контейнера (gVisor)
9. Доверенная загрузка
10. Поддающаяся проверке сборка
11. Проверка целостности программного обеспечения
12. Взаимный TLS (mTLS)
13. Политика доступа к услугам
14. Токены контекста конечного пользователя
15. Конфигурация как код
16. Стандартная разработка и развертывание

другой

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

в заключение

Чтобы добиться нулевого доверия, 20% полагается на теорию, а 80% — на практику. Практическое решение проблемы нулевого доверия не является уникальным. Автор надеется, что, поделившись приведенным выше примером практики нулевого доверия, он может послужить отправной точкой. Приветствуем критику и исправления каждого!