Поделиться через

Рекомендации по обеспечению безопасности для изготовителей устройств Интернета вещей Azure

  • Статья

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

  • Выбор способа проверки подлинности устройства
  • Установка сертификатов на устройствах Интернета вещей
  • Интеграция доверенного платформенного модуля (TPM) в процесс производства

Выбор способа проверки подлинности устройства

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

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

Сертификат X.509

Сертификаты X.509 — это тип цифрового удостоверения, который можно использовать для проверки подлинности. Стандарт сертификата X.509 описан в документе IETF RFC 5280. Интернет вещей Azure предоставляет два способа проверки подлинности сертификатов.

  • Отпечаток. Алгоритм отпечатка выполняется на сертификате для создания шестнадцатеричной строки. Созданная строка является уникальным идентификатором сертификата.
  • Проверка подлинности центра сертификации на основе полной цепочки. Цепочка сертификатов — это иерархический список всех сертификатов, необходимых для проверки подлинности сертификата конечного субъекта (EE). Чтобы проверить подлинность сертификата EE, необходимо выполнить проверку подлинности для каждого сертификата в цепочке, включая доверенный корневой центр сертификации.

Преимущества X.509:

  • X.509 — это наиболее безопасный тип проверки подлинности, поддерживаемый Интернетом вещей Azure;
  • X.509 обеспечивает высокий уровень контроля для управления сертификатами;
  • многие поставщики предлагают решения для проверки подлинности на основе X.509.

Недостатки X.509:

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

Доверенный платформенный модуль (TPM)

TPM, также известный как ISO/IEC 11889, является стандартом для безопасного создания и хранения криптографических ключей. Этот тип относится к виртуальному или физическому устройству ввода-вывода, которое взаимодействует с модулями, реализующими этот стандарт. Устройство доверенного платформенного модуля может существовать как дискретные аппаратные средства, интегрированные аппаратные средства, модуль на основе встроенного ПО или модуль ПО.

Между доверенными платформенными модулями и симметричными ключами существует два основных различия:

  • Микросхемы доверенного платформенного модуля также могут хранить сертификаты X.509.
  • Аттестация доверенного платформенного модуля в DPS использует ключ подтверждения доверенного платформенного модуля, который является формой асимметричной проверки подлинности. При использовании асимметричной проверки подлинности для шифрования применяется открытый ключ, а для расшифровки используется отдельный закрытый ключ. Симметричные ключи, напротив, используют симметричную проверку подлинности, где закрытый ключ применяется как для шифрования, так и для расшифровки.

Преимущества доверенного платформенного модуля:

  • доверенные платформенные модули входят в стандартную комплектацию многих устройств под управлением Windows и имеют встроенную поддержку операционной системы;
  • аттестация доверенного платформенного модуля проще в защите, чем аттестация симметричного ключа на основе маркеров подписанного URL-адреса (SAS);
  • можно легко завершить раньше времени, продлить или зарегистрировать учетные данные устройства. Служба DPS автоматически вводит учетные данные Центра Интернета вещей всякий раз, когда требуется повторная подготовка устройства доверенного платформенного модуля.

Недостатки доверенного платформенного модуля:

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

Симметричный ключ

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

Преимущества симметричного ключа:

  • использование симметричных ключей — самый простой и экономичный способ приступить к проверке подлинности;
  • использование симметричных ключей упрощает процесс, поскольку не нужно создавать ничего лишнего.

Недостатки симметричного ключа:

  • Симметричные ключи требуют значительных усилий для обеспечения защиты ключей. Один и тот же ключ используется совместно между устройством и облаком. Это означает, что ключ должен быть защищен в двух местах. В отличие от этого проблема с доверенным платформенным модулем и сертификатами X.509 состоит в том, чтобы доказать владение открытым ключом, не раскрывая при этом владение закрытым ключом.
  • Симметричные ключи упрощают соблюдение практических рекомендаций по обеспечению безопасности. Распространенной тенденцией при использовании симметричных ключей является жесткое кодирование незашифрованных ключей на устройствах. Хотя такой подход удобен, ключи при этом остаются уязвимыми. Некоторые риски можно снизить, надежно сохранив симметричный ключ на устройстве. Однако если вашим приоритетом является безопасность, а не удобство, то для проверки подлинности следует использовать сертификаты X.509 или TPM.

Общий симметричный ключ

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

Преимущество общего симметричного ключа:

  • Просто реализовать и недорого производить в больших масштабах.

Недостатки общего симметричного ключа:

  • Высокая уязвимость к атакам. Риск значительно перевешивает преимущество простой реализации.
  • При получении общего ключа любой пользователь может олицетворять ваши устройства.
  • Если вы полагаетесь на общий симметричный ключ, который становится скомпрометированным, вы, скорее всего, потеряете управление устройствами.

Выбор правильного решения для устройств

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

Установка сертификатов на устройствах Интернета вещей

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

Если вы привыкли использовать пароли, вы можете спросить, почему вы не можете использовать один и тот же сертификат на всех своих устройствах, точно так же, как вы можете использовать один и тот же пароль на всех своих устройствах. Во-первых, использовать везде один и тот же пароль опасно. Эта практика подвергала компании серьезным DDoS-атакам, в том числе той, которая несколько лет назад обрушилась на DNS на восточном побережье США. Никогда не используйте везде один и тот же пароль, даже с личными учетными записями. Во-вторых, сертификат не является паролем, он является уникальным удостоверением. Пароль похож на секретный код, который каждый может использовать, чтобы открыть дверь в охраняемом здании. Это данные, известные только вам одним, и вы можете предоставить пароль кому угодно, чтобы он смог войти. Сертификат же можно сравнить с водительским удостоверением с вашей фотографией и другими данными, которое вы можете предъявить охраннику, чтобы попасть в охраняемое здание. Оно подтверждает вашу личность. При условии, что охранник может точно сопоставить человека с фотографией на водительском удостоверении, только вы один можете использовать свое водительское удостоверение (водительские права), чтобы попасть в здание.

Переменные, используемые в процессе принятия решений о сертификатах

Рассмотрим следующие переменные и то, как каждая из них влияет на общий производственный процесс.

Откуда берется корень доверия сертификата

Управление инфраструктурой открытых ключей (PKI) может быть дорогостоящим и сложным. Особенно если у вашей компании отсутствует опыт управления инфраструктурой открытых ключей. Можно выполнить следующие действия:

  • Использование инфраструктуры открытых ключей стороннего производителя. Промежуточные сертификаты для подписи можно приобрести у стороннего поставщика сертификатов. Можно также использовать частный центр сертификации.
  • Используйте самоуправляемую инфраструктуру открытых ключей. Можно поддерживать собственную систему инфраструктуры открытых ключей и создавать собственные сертификаты.
  • Использование службы безопасности Azure Sphere Этот вариант применим только к устройствам с поддержкой Azure Sphere.

Где хранить сертификаты

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

  • В аппаратном модуле безопасности (HSM). Настоятельно рекомендуется использовать HSM. Убедитесь, что на панели управления устройства уже установлен HSM. Если вы уверены, что у вас нет аппаратного модуля безопасности, обратитесь к производителю аппаратного обеспечения, чтобы найти аппаратный модуль безопасности, соответствующий вашим потребностям.
  • В безопасном месте на диске, например в доверенной среде выполнения (TEE).
  • В локальной файловой системе или хранилище сертификатов. Например, в хранилище сертификатов Windows.

Возможность подключения на производстве

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

  • Возможность подключения. Наличие возможности подключения является оптимальным вариантом. Это упрощает процесс создания сертификатов локально.
  • Подключение отсутствует. В этом случае используется подписанный сертификат из центра сертификации для создания сертификатов устройств локально и в автономном режиме.
  • Подключение отсутствует. В этом случае можно получить сертификаты, созданные заранее. Можно также использовать автономную инфраструктуру открытых ключей для создания сертификатов локально.

Требования к аудиту

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

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

Срок действия сертификата

Как и водительские удостоверения, сертификаты имеют дату окончания срока действия, которая задается при их создании. Ниже приведены варианты срока действия сертификата:

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

Создание сертификатов

Возможности подключения к Интернету на вашем предприятии повлияют на процесс создания сертификатов. Существует несколько вариантов создания сертификатов.

  • Предварительно загруженные сертификаты. Некоторые поставщики HSM предлагают дополнительную услугу, при которой поставщик HSM устанавливает сертификаты для клиента. Сначала клиенты предоставляют поставщику HSM доступ к сертификату для подписи. Затем поставщик HSM устанавливает сертификаты, подписанные с помощью этого сертификата для подписи, на каждый HSM, который покупает клиент. Все, что требуется от клиента, — это установить HSM на устройство. Хотя эта услуга требует дополнительных затрат, она помогает упростить производственный процесс. Кроме того, она снимает вопрос о том, когда устанавливать сертификаты.
  • Сертификаты, созданные устройством. Если устройства создают сертификаты автоматически, необходимо извлечь общедоступный сертификат X.509 с устройства, чтобы зарегистрировать его в DPS.
  • Подключенное производство Если на предприятии есть возможность подключения, можно создавать сертификаты устройств тогда, когда они требуются.
  • Автономное производство с собственной инфраструктурой открытых ключей. Если на предприятии отсутствует возможность подключения и вы используете собственную инфраструктуру открытых ключей с поддержкой автономного режима, можно будет создавать сертификаты по мере необходимости.
  • Автономное производство со сторонней инфраструктурой открытых ключей. Если на предприятии отсутствует возможность подключения и вы используете стороннюю инфраструктуру открытых ключей, сертификаты должны быть созданы заранее. Необходимо будет также создать сертификаты из места, где есть возможность подключения.

Установка сертификатов

После создания сертификатов для устройств Интернета вещей их можно установить на устройства.

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

Если вы не используете предварительно загруженный сертификат, необходимо установить сертификат в рамках производственного процесса. Самый простой подход — установить сертификат в HSM одновременно с установлением начального образа встроенного ПО. Этот процесс должен добавить шаг для установки образа на каждом устройстве. После выполнения этого шага можно выполнить окончательные проверки качества и другие действия, прежде чем приступать к упаковке и поставке устройства.

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

После установки сертификатов на устройствах следует узнать, как зарегистрировать устройства с помощью DPS.

Интеграция доверенного платформенного модуля в производственный процесс

В этом разделе содержатся рекомендации по использованию доверенного платформенного модуля для проверки подлинности устройств Интернета вещей. В руководстве описаны широко используемые устройства TPM 2.0, которые имеют поддержку ключа кода проверки подлинности сообщений с помощью хэш-функций (HMAC). Спецификация TPM для микросхем TPM — это стандарт ISO, поддерживаемый организацией TCG. Дополнительные сведения о доверенном платформенном модуле см. в спецификациях для TPM 2.0 и ISO или IEC 11889.

Получение права владения доверенным платформенным модулем

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

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

Важно!

В следующем руководстве предполагается, что используется дискретный, микропрограммный или интегрированный модуль TPM. Там, где это применимо, в руководстве добавляются примечания по использованию недискретного или программного модуля TPM. Если вы используете программный модуль TPM, могут потребоваться дополнительные шаги, которые не включены в данное руководство. Программные модули TPM имеют множество вариантов реализации, которые выходят за рамки этой статьи. Как правило, программный модуль TPM можно интегрировать в следующую общую временную шкалу производства. Хотя программно-эмулированный модуль TPM подходит для создания прототипов и тестирования, он не может обеспечить такой же уровень безопасности, как дискретный, микропрограммный или интегрированный модуль TPM. Как правило, рекомендуется избегать использования программного модуля TPM в рабочей среде.

Общая временная шкала производства

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

Шаг 1. Производство доверенного платформенного модуля

  • Если вы покупаете доверенные платформенные модули у производителя для использования в своих устройствах, узнайте, сможет ли он извлечь для вас открытые ключи подтверждения (EK_pubs). Это будет полезно, если изготовитель предоставляет список EK_pubs с поставляемыми устройствами.

    Примечание.

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

  • Если вы производите доверенные платформенные модули для продажи производителям устройств, рассмотрите возможность предоставления вашим клиентам списка EK_pub вместе с их физическими доверенными платформенными модулями. Предоставление клиентам EK_pubs позволяет им сэкономить время в процессе.

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

Шаг 2. Доверенный платформенный модуль устанавливается на устройство

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

  • Если вы еще не извлекли EK_pub, сейчас самое время это сделать.
  • В зависимости от процесса установки доверенного платформенного модуля во время этого шага также можно получить права владения доверенным платформенным модулем.

Шаг 3. На устройстве установлено встроенное ПО и программное обеспечение

На этом этапе процесса установите клиент DPS вместе с областью идентификатора и глобальным URL-адресом для подготовки.

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

    Примечание.

    Если вы используете программный доверенный платформенный модуль, сейчас самое время его установить. Одновременно с этим извлеките EK_pub.

Шаг 4. Устройство упаковывается и отправляется на склад

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

Шаг 5. Устройство установлено в расположение

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

Дополнительные сведения см. в разделе о подготовке и в статье Аттестация доверенного платформенного модуля.

Ресурсы

В дополнение к рекомендациям по обеспечению безопасности, приведенным в этой статье, Интернет вещей Azure предоставляет ресурсы, которые помогут выбрать безопасное аппаратное обеспечение и создать безопасные развертывания Интернета вещей: