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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Внимание

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

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

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

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

  • Если вы покупаете TPM от производителя для использования на ваших устройствах, проверьте, извлекаются ли они ключи открытого подтверждения (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 предоставляет ресурсы, которые помогут выбрать безопасное аппаратное обеспечение и создать безопасные развертывания Интернета вещей: