Являетесь ли вы экспертом в области шифрования или новичком, добро пожаловать! Эта серия статей для вас! Она предполагает, что вы ничего не знаете, и расскажет вам от корки до корки о том, как создать систему доверия с целью создания модели безопасности Zero Trust. Процесс и мышление, описанные в этой серии, являются прямым результатом разработки аналогичной системы для проекта с открытым исходным кодом Ziti. Ziti можно найти на странице проекта OpenZiti на GitHub. Серия начинается с основ и переходит в систему регистрации Ziti.

Части цикла следующие.

• Часть 1: Шифрование повсюду
• Часть 2: Основы криптографии с открытым ключом
• Часть 3: Сертификаты
• Часть 4: Центры сертификации и цепочки доверия
• Часть 5: Повышение доверия

Нулевое доверие

Вся эта серия статей предполагает некоторое знакомство с Zero Trust. Если у вас нет сильных знаний в этой области, это не страшно. Этот раздел должен дать читателю достаточно контекста, чтобы использовать всю серию. Если вы хотите получить более глубокое понимание, пожалуйста, прочтите Zero Trust Networks: Построение безопасных систем в недоверенных сетях» Эвана Гилмана.

Zero Trust — это модель безопасности, которая требует строгой аутентификации личности и проверки доступа при каждом соединении в любое время. Она задает тон безопасности системы, говоря: «Эта система никогда не должна предполагать идентичность или доступ любого соединения». До появления моделей безопасности Zero Trust ИТ-инфраструктуры создавались как ряд периметров безопасности. Представьте себе замок со стенами и рвами. У замка было определенное количество точек входа с охраной. Пройдя мимо охранников и оказавшись внутри замка, любой посетитель получал доверие и доступ в замок. В реальном мире проход через охрану аналогичен аутентификации на машине или, на худой конец, подключению к офисной сети через WiFi или кабель Ethernet.

Zero Trust отменяет концепцию центрального замка, который предполагает, что все, кто в нем находится, пользуются доверием. Он предполагает, что замок уже взломан. Иными словами, мы ожидаем, что злоумышленники уже находятся внутри сети и что она представляет собой враждебную среду. Любые ресурсы внутри сети должны рассматриваться как общедоступные в Интернете и должны быть защищены. Для обеспечения такой защиты определена серия столпов нулевого доверия:

• Никогда не доверяй, проверяй — добродетель соединения не должна предоставлять доступ.
• Аутентификация до подключения — аутентификация должна происходить до подключения к ресурсам.
• Наименее привилегированный доступ — доступ должен предоставлять возможность подключения только к минимальному количеству ресурсов.

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

Ziti и Zero Trust

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

1. Аутентификация
2. Запрос доступа к ресурсу
3. Подключиться к запрашиваемому ресурсу

Этот процесс не является типичным порядком соединений в сети. Большинство соединений в сети выполняются в обратном порядке. Сначала это может показаться неинтуитивным. Чтобы немного прояснить нулевое доверие и бутстраппинг доверия, необходимо иметь конкретную систему для примера. Так получилось, что программная система Ziti является отличным примером!

В Ziti все описанные выше шаги требуют взаимодействия с контроллером Ziti. Контроллер Ziti управляет оверлейной сетью Ziti, поддерживая список известных сетевых служб, клиентов SDK, маршрутизаторов, регистраций, политик и многого другого! Все эти элементы работают вместе, создавая сеть Ziti. Сеть Ziti является оверлейной сетью — это означает, что она создает виртуальную сеть поверх конкретной сети. Конкретной сетью может быть Интернет, университетская сеть или ваша собственная домашняя сеть. Независимо от этого, она называется подложкой сети.

В сети Ziti все сетевые ресурсы моделируются как службы в контроллере Ziti. Все службы в сети Ziti Network должны быть доступны только через сеть Ziti Network для достижения максимального эффекта. Сетевые службы могут быть доступны через сеть Ziti Network различными способами. Предпочтительным методом является встраивание Ziti SDK внутрь приложений и серверов, поскольку это обеспечивает наивысшую степень безопасности Zero Trust. Однако также можно настроить различные соединения оверлей-андерлей с существующими сетевыми службами через «окончание маршрутизатора» или определенный тип приложения с внедренным в него Ziti SDK, который специально занимается переводами оверлей-андерлей (т.е. Ziti Desktop Edge/Mobile Edge).

Контроллер Ziti также знает об одном или нескольких маршрутизаторах Ziti, которые образуют ячеистую сеть, способную создавать динамические цепи между собой. Маршрутизаторы используют схемы для перемещения данных по сети Ziti. Маршрутизаторы можно настроить так, чтобы данные могли входить и выходить из сети. Наиболее распространенными точками входа/выхода являются Ziti SDK, выступающие в качестве клиентов или серверов.

Клиенты сети, желающие подключиться к сети, используют Ziti SDK для первой аутентификации с контроллером Ziti. Во время аутентификации клиент Ziti SDK и Ziti Controller проверяют друг друга. После успешной аутентификации Ziti Controller может предоставить список доступных сервисов для соединения (connect) или привязки (host) для аутентифицированного SDK-клиента. Затем клиент может запросить соединение или привязку услуги. Если запрос выполнен, с клиентом и услугой ассоциируется сессия. Эта новая сессия передается на необходимые маршрутизаторы Ziti Routers, и создаются необходимые цепи. Клиенту возвращается список маршрутизаторов Ziti, к которым можно подключиться, чтобы завершить последнюю милю связи между оверлейной сетью Ziti и клиентом SDK.

Этот набор шагов охватывает все столпы модели Zero Trust! Контроллер Ziti и клиенты SDK проверяют друг друга. Клиент не может подключиться к сетевым ресурсам или сервисам, пока не пройдет аутентификацию. После аутентификации клиент получает доступ с наименьшими привилегиями: ему сообщают только о назначенных аутентифицированной личности сервисах и он может только набирать/подключаться к ним. Это оверлейная сеть с нулевым доверием!

Как появилась эта система? Как клиент Ziti SDK и контроллер Ziti проверяют друг друга? Как маршрутизаторы и контроллер проверяют друг друга? Как это управляется в масштабе с сотнями маршрутизаторов Ziti и тысячами клиентов Ziti SDK? Похоже, что это рекурсивная проблема. Чтобы положить конец рекурсии, мы должны начать нашу систему с четко определенного и тщательно контролируемого зерна доверия.

Доверие

В программных системах, требующих подключения к сети, есть как минимум две стороны. Как правило, их больше, а в случае сети Ziti их могут быть тысячи. Между двумя сторонами каждый раз, когда устанавливается соединение, принимается решение о доверии. Следует ли разрешить это соединение? Чтобы ответить на этот вопрос, необходимо создать механизмы для проверки личности соединяющейся стороны.

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

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

Это решение можно усовершенствовать. Секреты могут генерироваться для каждого программного компонента. Контроллер, каждый маршрутизатор и каждый клиент SDK могли бы иметь уникальный секрет. Этот секрет будет индивидуально идентифицировать каждый компонент! Это значительное улучшение, но как каждый компонент проверяет соединения? Они запрашивают секрет входящего соединения и сравнивают его со списком? Это означает, что пара систем, которым нужно соединиться, должны иметь секреты друг друга. Обмен секретами не подходит! Мы не можем копировать секреты между всеми машинами. Одна скомпрометированная машина будет означать, что многие секреты раскрыты!

Это решение можно развивать и совершенствовать, но мы не должны делать эту тяжелую работу! Если бы мы это сделали, мы бы в конечном итоге воссоздали существующую технологию. Эта технология — (криптография с открытым ключом)[https://en.wikipedia.org/wiki/Public-key_cryptography], и она обеспечивает все, что нам нужно.

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

Настройка

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

Рассмотрим следующую схему «ячеистой» распределенной системы. Эта сетка может быть системой любого типа, например, сеткой маршрутизаторов Ziti Routers, или это может быть система датчиков на самолете. То, что они делают, не имеет значения. Важно то, что в этой системе есть несколько частей программного обеспечения, соединяющихся между собой. Рассмотрим, что значит достичь этого с помощью криптографии с открытым ключом.

На приведенной выше схеме каждая система нуждается:

• пара ключей для клиентских и серверных соединений
• иметь открытые ключи каждой системы, к которой она подключается.

Итак, что нам нужно сделать? Зайти в CLI и начать генерировать ключи на каждой машине. Сделайте это с помощью следующих команд:

openssl ecparam -name secp256k1-genkey -param_enc explicit -out private-key.pem

openssl req -new -x509 -key private-key.pem -out server.pem -days 360

Вуаля — теперь у вас есть самоподписанный сертификат! Что такое самоподписанный сертификат? Пока что давайте поймем, что это означает, что ни одна другая система не выразила доверия вашему публичному сертификату. В части 4: Центры сертификации и цепочки доверия мы рассмотрим их более подробно.

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

Затем необходимо скопировать каждый открытый сертификат на все остальные машины и настроить программное обеспечение таким образом, чтобы оно доверяло этим сертификатам. Этот процесс нужно будет повторять каждый раз, когда в систему будет добавляться программное обеспечение. Если машина скомпрометирована, аналогичный публичный сертификат должен быть недоверенным на каждом узле в ячейке. Добавление или удаление доверия к публичному сертификату предполагает настройку программного обеспечения или операционных систем. Существует множество способов ее реализации, включая конфигурационные файлы, файлы, хранящиеся в определенных каталогах, и даже с помощью инструментов настройки, таких как оснастка Windows Certificate Manager.

Это журнал тщательной работы для обеспечения работы простой системы. Подумайте, что это означает при добавлении или удалении большого количества узлов? Посещать каждую машину и каждый раз заново настраивать их — это довольно накладно. Существует решение этих проблем. Хотя само по себе оно элегантно, оно добавляет сложности. Давайте посмотрим, как могут помочь центры сертификации (ЦС)! В следующем разделе мы рассмотрим основные моменты, связанные с центрами сертификации. Для получения более подробной информации обратитесь к части 4: «Центры сертификации и цепочки доверия».

ЦС и добавление сложности

ЦС позволяет перенести доверие с нескольких отдельных сертификатов на один сертификат, что означает, что вместо того, чтобы доверять каждому сертификату, каждая часть программного обеспечения будет доверять ЦС. ЦС будет использоваться для подписи всех публичных сертификатов, которые должны использовать наши части программного обеспечения. Как работает «подписание»? Мы расскажем об этом в третьей части и о том, почему это важно, в четвертой. Пока же мы расскажем об основных принципах.

Вот основные шаги по использованию ЦС:

1. создать конфигурацию ЦС с помощью файлов OpenSSL CNF
2. создать ЦС
3. использовать открытый ключ ЦС для подписи всех публичных сертификатов
4. распространить сертификат ЦС на каждую машину
5. настроить хранилище сертификатов на машинах или настроить программное обеспечение.

Для первого и второго пунктов процесс может быть немного мистическим. Существует множество опций, связанных с управлением ЦС. Чтобы выполнить пункт три, вам нужно будет пройти процедуру создания запросов на подписание сертификатов (CSR, более подробно см. часть три) от имени программного обеспечения, и кто-то или что-то должно будет играть роль центра сертификации и разрешать CSR. Последние два шага будут зависеть от используемой операционной системы и программного обеспечения.

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

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

Дальнейшие заботы

После настройки необходимо учесть и другие проблемы. Рассмотрим следующий список событий, которые могут произойти с ЦС и его сертификатами:

• Что происходит, когда срок действия сертификата истекает?
• Как система узнает, что сертификату больше нельзя доверять?
• Что происходит, когда закрытые ключи необходимо регенерировать?

ЦС не обрабатывают автоматически распространение этих типов событий. ЦС — это файлы на устройстве хранения данных или HSM. Выдача или отзыв сертификатов не генерирует никаких событий без дополнительного программного обеспечения. Существует также проблема истечения срока действия сертификатов. Это «-days 360», использованное в примере выше, устанавливает срок службы каждого сертификата. Срок действия может быть продлен далеко в будущее, но это плохая практика. Ограничение срока действия сертификата уменьшает окна атак и может быть использовано в качестве триггера для внедрения надежного шифрования.

Даже если мы проигнорируем все эти опасения, кому мы доверяли, чтобы настроить эту систему? Какое зерно доверия было использовано для создания основы доверия? До сих пор вы могли представить, что всю эту работу выполняет человек. В этом случае человеку-оператору доверяют правильную настройку всех систем, доверяя ему доступ ко всем закрытым ключам. Семя доверия находится в этом человеке. Если эти действия выполняет программная система, это означает, что ей нужно доверять и, скорее всего, она имеет доступ к каждой другой системе, входящей в сеть. Это вполне выполнимо, но что произойдет, когда ваша система может иметь внешние системы, запрашивающие добавление в сеть? Как это может быть обработано? Как вы вообще доверяете этой системе? Использование секретного пароля создает единственное слабое место, которое можно использовать. Можно использовать криптографию с открытым ключом, но тогда мы попадаем в сценарий «курица с яйцом». Мы вводим криптографию с открытым ключом, чтобы автоматизировать криптографию с открытым ключом.

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