Если ваша организация управляет сотнями или тысячами (а может сотнями тысяч) серверов, как убедиться, что они не взломаны? Вы можете использовать традиционную программную систему обнаружения вторжений (Intrusion Detection System, IDS), но она по-прежнему уязвима для сложных программных атак. Что вам действительно нужно, так это создать аппаратный корень доверия, который можно использовать для проверки самых первых шагов процесса загрузки и распространения этого доверия вверх на каждый уровень вашей системы. Аппаратный модуль Trusted Platform Module (TPM) обеспечивает такую опору для настоящего решения удаленной аттестации.
Keylime, проект песочницы Cloud Native Computing Foundation, предоставляет масштабируемое решение для аттестации измеряемой загрузки, используя TPM и Linux архитектуру измерения целостности (Integrity Measurement Architecture, IMA), чтобы предоставить платформу удаленной аттестации, безопасную доставку полезной нагрузки и структуру отзыва, и дать вам полный контроль над политикой аттестации и устранением атак.
Keylime начинался как внутренний проект, финансируемый Технологическим отделом Lincoln Laboratory в 2015 году. Команда Keylime начала сотрудничать с RedHat, одной из крупнейших в мире компаний-разработчиков программного обеспечения с открытым исходным кодом. С помощью RedHat в 2019 году Keylime была преобразована в Cloud Native Computing Foundation, в которой участвуют более 30 разработчиков со всего мира.
Keylime позволяет правительственным и отраслевым пользователям с конфиденциальными данными повысить безопасность своих облачных устройств и IoT. Эта бесплатная программная архитектура с открытым исходным кодом с нулевым доверием на основе Linux позволяет клиентам облачных вычислений безопасно загружать криптографические ключи, пароли и сертификаты в облако, не раскрывая их своему облачному провайдеру.
Keylime развёртывается в облаке IBM для предоставления гарантий подлинности для UEFI и компонентов операционной системы, работающих на облачном оборудовании IBM. Keylime достигает этого, используя криптографическую идентификацию, предоставляемую устройствами TPM, а также функциями безопасной и контролируемой загрузки современного UEFI/BIOS.
Аттестация Keylime осуществляется на постоянной основе. Любое оборудование должно пройти аттестацию, прежде чем будет разрешено выполнение каких-либо клиентских рабочих нагрузок. Кроме того, нормальная работа связана с проблемами аттестации; узлы, не прошедшие аттестацию, исключаются из пула.
Одной из основных особенностей облачной архитектуры Keylime, построенной на основе программного стека Linux TPM2, является мониторинг целостности. Keylime обеспечивает облачную безопасность за счет использования аппаратного обеспечения, называемого TPM, стандартного недорогого аппаратного чипа безопасности, широко устанавливаемый на ноутбуки, устройства IoT и другие цифровые технологии. В рамках своей обычной работы микросхемы TPM передают на устройство хэш или короткую строку данных. Если данные будут подделаны даже незначительно, хэш значительно изменится, что является сигналом тревоги безопасности, который Keylime может обнаружить и отреагировать менее чем за секунду.
Архитектура с нулевым доверием
До Keylime TPM были несовместимы с облачными технологиями, что замедляло работу систем и вынуждало инженеров менять программное обеспечение, чтобы приспособить модуль. Keylime решает эти проблемы, выступая в качестве промежуточного программного обеспечения, которое позволяет пользователям использовать преимущества безопасности TPM без необходимости делать свое программное обеспечение совместимым с ним.
Уникальная удаленная проверка загрузки или аттестация архитектуры позволяет пользователям контролировать большое количество удаленных узлов, используя аппаратный криптографический корень доверия (Root-of-Trust, RoT), который обеспечивает проверку не только для устройств Интернета вещей (IoT), но и для вычислений на периферии и облачные операции. У разработчиков возникла идея внедрить такую архитектуру с нулевым доверием, чтобы выйти за рамки процессов TPM.
Сегодня многие организации используют форму облачных вычислений, называемую «инфраструктура как услуга» (IaaS), при которой они арендуют вычислительные ресурсы у поставщика облачных услуг, который отвечает за безопасность базовых систем. Для сравнения, облачные провайдеры хранят конфиденциальные данные пользователей по типу большого банка, над которым пользователи не имеют прямого контроля. Современное состояние облачных технологий по сей день заключается в том, что пользователь просто полностью доверяет поставщику облачных услуг. Проект Keylime пытается доказать, что можно иметь возможность использовать облако, имея прямой контроль над ним. Он был разработан для того, чтобы организации могли сами убедиться, что серверы, хранящие и обрабатывающие их данные, настолько безопасны, как заявляют поставщики облачных услуг.
Исследователи из Лаборатории Линкольна Массачусетского технологического института призывают людей изменить свое мышление на менталитет нулевого доверия. «Начните с предположения, что нельзя никогда ничему доверять, даже своей собственной среде, и что всегда должны всё проверять».
В 2020 году команда лаборатории Линкольна, разработавшая Keylime, была удостоена награды R&D 100 Award, признав это программное обеспечение одним из 100 самых инновационных новых технологий года, доступных для продажи или лицензирования.
Современное программное обеспечение состоит из множества слоёв. Большинство из нас на самом деле работают только в одном или двух из этих слоёв, но мы полагаемся на остальные нижние, чтобы продолжать работать. Мы полагаемся не только на их производительность и функциональность, но и на их безопасность. Если мы разрабатываем систему или приложение, как мы можем быть уверены, что один из многих нижних уровней не был скомпрометирован? Как бы то ни было, программное обеспечение в конечном итоге заканчивается аппаратным обеспечением. Если бы доверие можно было установить на самом низком аппаратном уровне, можно ли было бы расширить это доверие и проверить его на всём пути вверх?
Схема TPM
Цель TPM — установить аппаратный корень доверия, который можно использовать для измерения и расширения этого «доверия» вверх по стеку до программного обеспечения на уровне пользователя. Спецификация TPM — это международный стандарт, не зависящий от операционной системы (от Trusted Computing Group и International Standards Organization). Спецификация предназначена для предоставления защищенного аппаратного криптопроцессора, специального чипа, предназначенного для защиты оборудования с использованием криптографических ключей и операций. Эти чипы предоставляют несколько функций:
Каждый чип TPM имеет секретный ключ подтверждения (EK), который встраивается в него во время производства. TPM спроектированы таким образом, что этот секретный ключ запечатан внутри чипа и его нельзя получить, не разрушив сам чип. Из этого ключа получаются другие ключи, используемые доверенным платформенным модулем, в том числе:
Другой важной частью TPM является PCR (Platform Configuration Register). Подобно регистрам центральных процессоров (ЦП), это слоты, они содержат данные, которые можно прочитать. Но, в отличие от регистров ЦП, они не могут быть записаны напрямую.
При включении TPM эти PCR сбрасываются. И каждая операция, которая хочет добавить значение к этим PCR, не устанавливает их, а скорее «расширяет» их, что по сути означает создание нового хэша на основе текущего значения плюс новое значение:
new_hash = old_hash|measurement
Это означает, что значение в PCR — это не просто отдельное измерение, а результат всех предыдущих измерений. Подобно корневому узлу дерева Меркла, он опирается на каждое предыдущее значение, предназначенное для предотвращения его подделки.
TPM ноутбука Asus
TPM становятся всё более распространенными практически во всех вычислительных устройствах, включая ноутбуки, смартфоны, серверы, ПК, маршрутизаторы, периферийные устройства и даже доступны для небольших устройств, таких как RaspberryPi. Они даже предусмотрены в некоторых организациях, таких как Министерство обороны США, для всех новых компьютерных активов. Существует множество различных типов TPM, некоторые из которых считаются более безопасными, чем другие, но все они имеют своё место и связанные с ними компромиссы безопасности.
Чего не может TPM?
Во всех этих разговорах о том, как TPM может помочь защитить вашу систему от вредоносного программного обеспечения, полезно помнить о том, что TPM не может сделать. Он не может контролировать, какое программное обеспечение работает на оборудовании. Всё, что он может сделать, это измерить и подтвердить эти измерения. Пользователь, его организация и их политика должны решить, что делать с этими измерениями. Если во время загрузки ваш компьютер не соответствует выбранной политике загрузки, вы можете решить, что хотите, чтобы машина немедленно прекратила загрузку, чтобы ничто не могло быть скомпрометировано.
Или вы можете разрешить ему загружаться, но не подключаться к сети, чтобы можно было провести экспертизу. Если удалённый пограничный узел не проходит аттестацию, вы можете создать систему, которая блокирует его доступ к другим устройствам в сети. Но сам TPM этого не делает.
TPM, как и всё остальное, имеют уязвимости. Могут быть обнаружены новые атаки, которые удаляют некоторые из их средств защиты, или может быть обнаружена ошибка в реализации спецификации TPM конкретного поставщика. А поскольку программное обеспечение сложное, его можно использовать неправильно, что приведёт к аннулированию некоторых из его средств защиты. Но безопасность осуществляется на уровнях, начиная с аппаратного обеспечения и расширяясь выше, что даёт гораздо больше шансов не допустить действий злоумышленников.
Дизайн Keylime позволяет проводить удаленную аттестацию и мониторинг IMA тысяч узлов благодаря своей высокопроизводительной архитектуре. Благодаря разработке предложения виртуального TPM (vTPM) Keylime также может масштабироваться для использования даже тысяч виртуальных машин, работающих на одном хосте, при этом снижая потери производительности из-за прямого вызова аппаратного TPM облачного узла для криптографической подписи.
Три основных компонента системы Keylime — это Агент, Регистратор и Верификатор. Все три компонента изначально были разработаны на Python. Компоненты, требующие большей производительности и безопасности, такие как Агент, переносятся на язык Rust из-за его высокой производительности как низкоуровневого системного языка и строгой модели безопасности, реализуемой компилятором.
Архитектура компонентов Keylime
Агент Keylime должен быть установлен на каждом узле в инфраструктуре, где требуется аттестация. Агент отвечает за взаимодействие с TPM системой, в которой он находится. Таким образом, Агент отвечает за запрос криптографических котировок. Затем Агент отвечает за передачу собранной информации другим компонентам системы, чтобы обеспечить обработку цепочки доверия.
Верификатор, также известный как Cloud Verifier, — это компонент, отвечающий за загрузку нового узла в системе и непрерывный запрос от каждого Агента в системе. Затем Верификатор выполняет аттестацию возвращённых запросов, чтобы определить, были ли какие-либо несанкционированные изменения в удалённых системах.
Завершает набор компонентов — Регистратор. Регистратор несёт ответственность за поддержание набора известных безопасных (открытых) значений ключей, используемых во время обработки аттестации. Агент на каждом узле регистрируется в Регистраторе при загрузке, фиксируя начальное состояние узла для последующего сравнения. Набор безопасных ключей Регистратора также включает открытые ключи производителя оборудования для каждого узла в системе. Эти ключи производителя используются для проверки того, что аппаратный TPM действителен и может использоваться в качестве RoT для соответствующего узла.
В инструментарий Keylime также включена CLI утилита keylime_tenant. Данная утилита использует интерфейсы RESTful системы Keylime для связи с компонентами Keylime. Пользователь может либо использовать keylime_tenant, веб-интерфейс Keylime, либо интегрировать систему управления с Keylime путем прямой интеграции с REST API Keylime.
Keylime также включает в себя простой центр сертификации (CA), которым можно управлять с помощью keylime_tenant или специальной утилиты keylime_ca. Центр сертификации является неотъемлемой частью первоначального установления доверия на этапе начальной загрузки узла и последующего обеспечения доверительных отношений. Центр сертификации первоначально отвечает за подписание всех загрузочных ключей, отправляемых на инициализируемые узлы, устанавливая первоначальное доверие, на которое опирается система. Если Верификатор обнаруживает нарушение установленного доверия из-за неверных аттестаций, CA уведомляется и, как ожидается, аннулирует доверие, сделав недействительными ключи, связанные со скомпрометированным узлом.
Чтобы использовать Keylime, системы, в которых он запущен, должны быть доверенными вычислительными ресурсами, чтобы BIOS систем, включающих TPM, поддерживал измерение встроенного ПО и загрузчиков. Существуют также загрузчики TPM, которые затем могут измерять гипервизоры и операционные системы. Кроме того, ОС систем может поддерживать измерения запущенных приложений, что может быть выполнено с помощью архитектуры измерения целостности Linux IMA. Red Hat Enterprise Linux, CentOS Linux и Fedora Linux являются примерами операционных систем, поддерживающих IMA и, более того, они включают его по умолчанию.
Для поддержки рабочего процесса Keylime отдельные компоненты необходимо запускать в системе в определённом порядке. Сначала keylime_tenant должен запустить Регистратор. Регистратор может находиться в собственной инфраструктуре или может быть развернут как физическая система в инфраструктуре облачного провайдера. keylime_tenant подтверждает состояние целостности Регистратора, чтобы начать ему доверять. После запуска Регистратора он начинает принимать запросы на регистрацию от Агентов для хранения их AIK TPM.
Одна из двух основных услуг Keylime — поддержка рабочего процесса Trusted Boot. Это означает, что Keylime можно использовать для проверки доверенного ожидаемого состояния системы с помощью рабочего процесса подготовки, поэтому можно быть уверенным, что система не была подделана, прежде чем запускать на ней рабочие нагрузки. При начальной загрузке системы используются все компоненты системы Keylime.
Что дальше для Keylime?
В настоящее время осуществляются усовершенствования вышеуказанной системы. Также продолжается работа по поддержке vTPM в средах KVM и runC. Также ожидаются появления обновлений для сценариев мультитенантности и распределённой высокой доступности для компонентов Верификатор и Регистратор.
С момента появления технологии Keylime за ней сплотилось небольшое, но целеустремлённое сообщество открытого исходного кода. Сообщество Keylime в настоящее время работает над упаковкой проекта для разных платформ и укреплением системы путем переноса подсистем с Python на Rust, одновременно устраняя ошибки, о которых сообщают сообществу пользователи.
habr.com
Keylime, проект песочницы Cloud Native Computing Foundation, предоставляет масштабируемое решение для аттестации измеряемой загрузки, используя TPM и Linux архитектуру измерения целостности (Integrity Measurement Architecture, IMA), чтобы предоставить платформу удаленной аттестации, безопасную доставку полезной нагрузки и структуру отзыва, и дать вам полный контроль над политикой аттестации и устранением атак.
Доверяй да проверяй
Keylime начинался как внутренний проект, финансируемый Технологическим отделом Lincoln Laboratory в 2015 году. Команда Keylime начала сотрудничать с RedHat, одной из крупнейших в мире компаний-разработчиков программного обеспечения с открытым исходным кодом. С помощью RedHat в 2019 году Keylime была преобразована в Cloud Native Computing Foundation, в которой участвуют более 30 разработчиков со всего мира.
Keylime позволяет правительственным и отраслевым пользователям с конфиденциальными данными повысить безопасность своих облачных устройств и IoT. Эта бесплатная программная архитектура с открытым исходным кодом с нулевым доверием на основе Linux позволяет клиентам облачных вычислений безопасно загружать криптографические ключи, пароли и сертификаты в облако, не раскрывая их своему облачному провайдеру.
Keylime развёртывается в облаке IBM для предоставления гарантий подлинности для UEFI и компонентов операционной системы, работающих на облачном оборудовании IBM. Keylime достигает этого, используя криптографическую идентификацию, предоставляемую устройствами TPM, а также функциями безопасной и контролируемой загрузки современного UEFI/BIOS.
Аттестация Keylime осуществляется на постоянной основе. Любое оборудование должно пройти аттестацию, прежде чем будет разрешено выполнение каких-либо клиентских рабочих нагрузок. Кроме того, нормальная работа связана с проблемами аттестации; узлы, не прошедшие аттестацию, исключаются из пула.
Одной из основных особенностей облачной архитектуры Keylime, построенной на основе программного стека Linux TPM2, является мониторинг целостности. Keylime обеспечивает облачную безопасность за счет использования аппаратного обеспечения, называемого TPM, стандартного недорогого аппаратного чипа безопасности, широко устанавливаемый на ноутбуки, устройства IoT и другие цифровые технологии. В рамках своей обычной работы микросхемы TPM передают на устройство хэш или короткую строку данных. Если данные будут подделаны даже незначительно, хэш значительно изменится, что является сигналом тревоги безопасности, который Keylime может обнаружить и отреагировать менее чем за секунду.
Архитектура с нулевым доверием
До Keylime TPM были несовместимы с облачными технологиями, что замедляло работу систем и вынуждало инженеров менять программное обеспечение, чтобы приспособить модуль. Keylime решает эти проблемы, выступая в качестве промежуточного программного обеспечения, которое позволяет пользователям использовать преимущества безопасности TPM без необходимости делать свое программное обеспечение совместимым с ним.
Уникальная удаленная проверка загрузки или аттестация архитектуры позволяет пользователям контролировать большое количество удаленных узлов, используя аппаратный криптографический корень доверия (Root-of-Trust, RoT), который обеспечивает проверку не только для устройств Интернета вещей (IoT), но и для вычислений на периферии и облачные операции. У разработчиков возникла идея внедрить такую архитектуру с нулевым доверием, чтобы выйти за рамки процессов TPM.
Сегодня многие организации используют форму облачных вычислений, называемую «инфраструктура как услуга» (IaaS), при которой они арендуют вычислительные ресурсы у поставщика облачных услуг, который отвечает за безопасность базовых систем. Для сравнения, облачные провайдеры хранят конфиденциальные данные пользователей по типу большого банка, над которым пользователи не имеют прямого контроля. Современное состояние облачных технологий по сей день заключается в том, что пользователь просто полностью доверяет поставщику облачных услуг. Проект Keylime пытается доказать, что можно иметь возможность использовать облако, имея прямой контроль над ним. Он был разработан для того, чтобы организации могли сами убедиться, что серверы, хранящие и обрабатывающие их данные, настолько безопасны, как заявляют поставщики облачных услуг.
Исследователи из Лаборатории Линкольна Массачусетского технологического института призывают людей изменить свое мышление на менталитет нулевого доверия. «Начните с предположения, что нельзя никогда ничему доверять, даже своей собственной среде, и что всегда должны всё проверять».
В 2020 году команда лаборатории Линкольна, разработавшая Keylime, была удостоена награды R&D 100 Award, признав это программное обеспечение одним из 100 самых инновационных новых технологий года, доступных для продажи или лицензирования.
TPM
Современное программное обеспечение состоит из множества слоёв. Большинство из нас на самом деле работают только в одном или двух из этих слоёв, но мы полагаемся на остальные нижние, чтобы продолжать работать. Мы полагаемся не только на их производительность и функциональность, но и на их безопасность. Если мы разрабатываем систему или приложение, как мы можем быть уверены, что один из многих нижних уровней не был скомпрометирован? Как бы то ни было, программное обеспечение в конечном итоге заканчивается аппаратным обеспечением. Если бы доверие можно было установить на самом низком аппаратном уровне, можно ли было бы расширить это доверие и проверить его на всём пути вверх?
Схема TPM
Цель TPM — установить аппаратный корень доверия, который можно использовать для измерения и расширения этого «доверия» вверх по стеку до программного обеспечения на уровне пользователя. Спецификация TPM — это международный стандарт, не зависящий от операционной системы (от Trusted Computing Group и International Standards Organization). Спецификация предназначена для предоставления защищенного аппаратного криптопроцессора, специального чипа, предназначенного для защиты оборудования с использованием криптографических ключей и операций. Эти чипы предоставляют несколько функций:
- Аппаратный генератор случайных чисел (ГСЧ);
- Криптографические хэш-функции;
- Шифрование данных – симметричное и асимметричное;
- Безопасная генерация и хранение криптографических ключей;
- «Запечатывание» данных: шифрование, которое можно разблокировать только в том случае, если доверенный платформенный модуль находится в указанном состоянии.
Каждый чип TPM имеет секретный ключ подтверждения (EK), который встраивается в него во время производства. TPM спроектированы таким образом, что этот секретный ключ запечатан внутри чипа и его нельзя получить, не разрушив сам чип. Из этого ключа получаются другие ключи, используемые доверенным платформенным модулем, в том числе:
- Корневой ключ хранилища (SRK), основанный на EK и пароле владельца;
- Ключ аттестации (AK), который можно использовать для хеширования критических измерений, чтобы доказать, что они поступили от TPM. EK может доказать, что AK поступил от определенного TPM, но для защиты конфиденциальности конструкция не позволяет отследить AK до его EK/TPM.
Другой важной частью TPM является PCR (Platform Configuration Register). Подобно регистрам центральных процессоров (ЦП), это слоты, они содержат данные, которые можно прочитать. Но, в отличие от регистров ЦП, они не могут быть записаны напрямую.
При включении TPM эти PCR сбрасываются. И каждая операция, которая хочет добавить значение к этим PCR, не устанавливает их, а скорее «расширяет» их, что по сути означает создание нового хэша на основе текущего значения плюс новое значение:
new_hash = old_hash|measurement
Это означает, что значение в PCR — это не просто отдельное измерение, а результат всех предыдущих измерений. Подобно корневому узлу дерева Меркла, он опирается на каждое предыдущее значение, предназначенное для предотвращения его подделки.
TPM ноутбука Asus
TPM становятся всё более распространенными практически во всех вычислительных устройствах, включая ноутбуки, смартфоны, серверы, ПК, маршрутизаторы, периферийные устройства и даже доступны для небольших устройств, таких как RaspberryPi. Они даже предусмотрены в некоторых организациях, таких как Министерство обороны США, для всех новых компьютерных активов. Существует множество различных типов TPM, некоторые из которых считаются более безопасными, чем другие, но все они имеют своё место и связанные с ними компромиссы безопасности.
Чего не может TPM?
Во всех этих разговорах о том, как TPM может помочь защитить вашу систему от вредоносного программного обеспечения, полезно помнить о том, что TPM не может сделать. Он не может контролировать, какое программное обеспечение работает на оборудовании. Всё, что он может сделать, это измерить и подтвердить эти измерения. Пользователь, его организация и их политика должны решить, что делать с этими измерениями. Если во время загрузки ваш компьютер не соответствует выбранной политике загрузки, вы можете решить, что хотите, чтобы машина немедленно прекратила загрузку, чтобы ничто не могло быть скомпрометировано.
Или вы можете разрешить ему загружаться, но не подключаться к сети, чтобы можно было провести экспертизу. Если удалённый пограничный узел не проходит аттестацию, вы можете создать систему, которая блокирует его доступ к другим устройствам в сети. Но сам TPM этого не делает.
TPM, как и всё остальное, имеют уязвимости. Могут быть обнаружены новые атаки, которые удаляют некоторые из их средств защиты, или может быть обнаружена ошибка в реализации спецификации TPM конкретного поставщика. А поскольку программное обеспечение сложное, его можно использовать неправильно, что приведёт к аннулированию некоторых из его средств защиты. Но безопасность осуществляется на уровнях, начиная с аппаратного обеспечения и расширяясь выше, что даёт гораздо больше шансов не допустить действий злоумышленников.
Компоненты Keylime
Дизайн Keylime позволяет проводить удаленную аттестацию и мониторинг IMA тысяч узлов благодаря своей высокопроизводительной архитектуре. Благодаря разработке предложения виртуального TPM (vTPM) Keylime также может масштабироваться для использования даже тысяч виртуальных машин, работающих на одном хосте, при этом снижая потери производительности из-за прямого вызова аппаратного TPM облачного узла для криптографической подписи.
Три основных компонента системы Keylime — это Агент, Регистратор и Верификатор. Все три компонента изначально были разработаны на Python. Компоненты, требующие большей производительности и безопасности, такие как Агент, переносятся на язык Rust из-за его высокой производительности как низкоуровневого системного языка и строгой модели безопасности, реализуемой компилятором.
Архитектура компонентов Keylime
Агент Keylime должен быть установлен на каждом узле в инфраструктуре, где требуется аттестация. Агент отвечает за взаимодействие с TPM системой, в которой он находится. Таким образом, Агент отвечает за запрос криптографических котировок. Затем Агент отвечает за передачу собранной информации другим компонентам системы, чтобы обеспечить обработку цепочки доверия.
Верификатор, также известный как Cloud Verifier, — это компонент, отвечающий за загрузку нового узла в системе и непрерывный запрос от каждого Агента в системе. Затем Верификатор выполняет аттестацию возвращённых запросов, чтобы определить, были ли какие-либо несанкционированные изменения в удалённых системах.
Завершает набор компонентов — Регистратор. Регистратор несёт ответственность за поддержание набора известных безопасных (открытых) значений ключей, используемых во время обработки аттестации. Агент на каждом узле регистрируется в Регистраторе при загрузке, фиксируя начальное состояние узла для последующего сравнения. Набор безопасных ключей Регистратора также включает открытые ключи производителя оборудования для каждого узла в системе. Эти ключи производителя используются для проверки того, что аппаратный TPM действителен и может использоваться в качестве RoT для соответствующего узла.
В инструментарий Keylime также включена CLI утилита keylime_tenant. Данная утилита использует интерфейсы RESTful системы Keylime для связи с компонентами Keylime. Пользователь может либо использовать keylime_tenant, веб-интерфейс Keylime, либо интегрировать систему управления с Keylime путем прямой интеграции с REST API Keylime.
Keylime также включает в себя простой центр сертификации (CA), которым можно управлять с помощью keylime_tenant или специальной утилиты keylime_ca. Центр сертификации является неотъемлемой частью первоначального установления доверия на этапе начальной загрузки узла и последующего обеспечения доверительных отношений. Центр сертификации первоначально отвечает за подписание всех загрузочных ключей, отправляемых на инициализируемые узлы, устанавливая первоначальное доверие, на которое опирается система. Если Верификатор обнаруживает нарушение установленного доверия из-за неверных аттестаций, CA уведомляется и, как ожидается, аннулирует доверие, сделав недействительными ключи, связанные со скомпрометированным узлом.
Чтобы использовать Keylime, системы, в которых он запущен, должны быть доверенными вычислительными ресурсами, чтобы BIOS систем, включающих TPM, поддерживал измерение встроенного ПО и загрузчиков. Существуют также загрузчики TPM, которые затем могут измерять гипервизоры и операционные системы. Кроме того, ОС систем может поддерживать измерения запущенных приложений, что может быть выполнено с помощью архитектуры измерения целостности Linux IMA. Red Hat Enterprise Linux, CentOS Linux и Fedora Linux являются примерами операционных систем, поддерживающих IMA и, более того, они включают его по умолчанию.
Для поддержки рабочего процесса Keylime отдельные компоненты необходимо запускать в системе в определённом порядке. Сначала keylime_tenant должен запустить Регистратор. Регистратор может находиться в собственной инфраструктуре или может быть развернут как физическая система в инфраструктуре облачного провайдера. keylime_tenant подтверждает состояние целостности Регистратора, чтобы начать ему доверять. После запуска Регистратора он начинает принимать запросы на регистрацию от Агентов для хранения их AIK TPM.
Одна из двух основных услуг Keylime — поддержка рабочего процесса Trusted Boot. Это означает, что Keylime можно использовать для проверки доверенного ожидаемого состояния системы с помощью рабочего процесса подготовки, поэтому можно быть уверенным, что система не была подделана, прежде чем запускать на ней рабочие нагрузки. При начальной загрузке системы используются все компоненты системы Keylime.
Что дальше для Keylime?
В настоящее время осуществляются усовершенствования вышеуказанной системы. Также продолжается работа по поддержке vTPM в средах KVM и runC. Также ожидаются появления обновлений для сценариев мультитенантности и распределённой высокой доступности для компонентов Верификатор и Регистратор.
С момента появления технологии Keylime за ней сплотилось небольшое, но целеустремлённое сообщество открытого исходного кода. Сообщество Keylime в настоящее время работает над упаковкой проекта для разных платформ и укреплением системы путем переноса подсистем с Python на Rust, одновременно устраняя ошибки, о которых сообщают сообществу пользователи.
Keylime — ключ от облака
Если ваша организация управляет сотнями или тысячами (а может сотнями тысяч) серверов, как убедиться, что они не взломаны? Вы можете использовать традиционную программную систему обнаружения вторжений...
habr.com