Это неделя Интернета вещей в SitePoint! Всю неделю мы публикуем статьи, ориентированные на пересечение интернета и физического мира, поэтому следите за последними обновлениями в теге IoT .
Безопасность IoT — актуальная проблема в современном мире: подключенных к Интернету устройств больше, чем людей, а объем передаваемых данных за последние несколько лет резко возрос. Тем не менее, обеспечение безопасности этих данных становится проблемой столь же быстро, особенно с появлением чувствительных к здоровью устройств и устройств, которые могут быть опасными при компрометации, таких как транспортные средства!
Я не могу утверждать, что у меня есть все ответы, но у меня есть одна хитрость, которая должна помочь вам в ваших поисках безопасности — Web-токены JSON, которые я также буду называть JWT. Эти небольшие портативные, проверяемые токены помогают убедиться, что сообщения, которые вы отправляете и получаете с ваших устройств и серверов, поступают из надежного источника. Они также делают великого носителя и жетонов доступа.
Что такое веб-токен JSON?
Для тех, кто не сталкивался с этим раньше, веб-токены JSON — это токены на основе JSON, используемые для отправки проверенной информации через Интернет. Они перед отправкой кодируются в base64, поэтому они выглядят так:
Отладчик jwt.io, показывающий веб-токен JSON
Вы видите выше отладчик JWT на JWT.io , сайте, на котором вы можете узнать гораздо больше о JWT, чем у нас будет возможность перейти в этой статье. Слева находится закодированный JWT. Это включает:
- Заголовок, закодированный в base64, объединенный с «.»
- Полезная нагрузка, закодированная в base64, с другим ‘.’
- Подписанный ключ
Справа — декодированный заголовок и полезная нагрузка. Они состоят из утверждений (это просто причудливое имя для пар ключ-значение JSON) . Некоторые требования объявляются стандартом — "alg" — для алгоритма подписи для ключа, а "sub" для подписчика. Другие претензии вы делаете сами, например, "admin" .
Ключ состоит из подписанного хеша заголовка, объединенного с "." , затем полезная нагрузка, все base64 в кодировке. Он подписан секретом, который должен храниться обеими сторонами, и может быть симметричным (строка) или асимметричным (пара открытых / закрытых ключей RSA).
Эти утверждения объединяются для описания самого токена и всего, что вы хотели бы сохранить, например, информации о пользователе и соответствующих данных сеанса. Просто убедитесь, что эти данные ограничены — одно из больших преимуществ JWT в том, что они очень малы, если вы не набиваете их слишком сильно!
Вы отправляете JWT, помещая их в HTTP-заголовок авторизации в формате:
Authorization: bearer <token>
Если вы не можете изменить заголовки HTTP, многие службы также примут JWT в качестве параметра тела или даже параметра запроса. Эти методы не рекомендуются, если вы можете использовать заголовки HTTP.
Каковы преимущества JWT?
Мир IoT — это мир небольших устройств, и разработчики стремятся сделать HTTP-вызовы, которые эти устройства делают, как можно меньше. JWT помогают с этим, имея очень мало накладных расходов. Для этого они используют минималистичную схему JSON и кодировку base64. Просто убедитесь, что вы не добавляете слишком много собственных претензий, иначе вы не сможете воспользоваться преимуществами размера! Сведите требования к минимуму, чтобы ваше приложение работало.
Почему не печенье? Это также учитывает необходимость HTTP-запроса. Вместо того, чтобы ваш сервер использовал cookie для поиска другой информации о сеансе пользователя, он находится внутри JWT с самого начала. Это означает, что не нужно делать никаких дополнительных вызовов базы данных или внешних сервисов. Опять же, это зависит от того, как вы их используете, поэтому тщательно продумайте, какие претензии вам нужны, а какие нет.
Еще одним преимуществом JWT является то, что они универсальны — парсеры JSON существуют практически для каждой платформы, и возможность доступа к кодированию / декодированию base64 наряду с подписью и проверкой hsa256 становится все более и более очевидной. Кроме того, JWT поддерживаются веб-стандартом, поэтому вы можете быть уверены, что используете технологию, которая может легко интегрироваться с другими службами, совместимыми с веб-стандартами, включая многих поставщиков OAuth2 и всех поставщиков стандарта OpenID Connect.
Даже если ваше устройство IoT не может декодировать токен, его можно передать на устройство в качестве токена доступа для ваших серверов и служб. Пока ваше устройство может хранить заданную ему строку, JWT могут использоваться в качестве сохраненных учетных данных вашими устройствами IoT. Просто будьте уверены, что эти жетоны надежно закреплены и пристально следите за ними, так как жетоны на предъявителя могут быть опасны, если их утечка!
Одной из многих проблем современной веб-архитектуры является проверка себя по услугам, разбросанным по нескольким доменам — даже у одного любителя или компании могут быть службы, работающие на разных провайдерах PaaS! JWT упрощают согласование между доменами — если все стороны используют один и тот же секрет для проверки ключа, JWT не заботится о домене, поддомене, порте и т. Д.
Как насчет шифрования?
Одна из первых вещей, которые я слышу, когда объясняю JWT, — «данные закодированы, но мне нужно, чтобы они были зашифрованы, иначе мои данные будут доступны для всеобщего обозрения!» Не беспокойтесь — есть JSON Web Encryption, обработанный RFC 7517, это позволяет вам шифровать свои веб-токены JSON и при этом участвовать в соответствии стандартам! Есть даже много библиотек, которые поддерживают это. Я также видел, что это идет под названием JOSE (Подписание и шифрование объектов Javascript).
Использование JWT в архитектуре IoT
Теперь мы переходим к хорошей части — как. Мы рассмотрим это с точки зрения вашего IoT-устройства, а затем и ваших IoT-серверов.
Использование JWT на устройствах IoT
Если вы просто хотите получить JWT в качестве токена-носителя и не использовать содержащуюся информацию, все, что вам нужно сделать, это сохранить JWT, полученный вами от вашего сервера, на устройстве и отправлять его с каждым аутентифицированным запросом.
Если вы хотите использовать полезную нагрузку или если ваше устройство выпускает JWT самостоятельно, ваше устройство должно быть способно:
- Разбор / строковая обработка JSON
- кодирование / декодирование base64
- Проверка подписи HS256
Также необходимо будет хранить общий секрет, который сервер будет использовать для подписи / проверки JWT.
Получив токен, вы выполните следующие действия:
- Проверьте подпись ключа с секретом, хранящимся на устройстве.
- Если подпись действительна, используйте декодирование base64 для получения строковой полезной нагрузки JSON.
- Разобрать полезную нагрузку в объект.
И вот оно! Для поклонников Arduino есть несколько библиотек для кодирования / декодирования base64, проверки HS256 и обработки объектов JSON. Для таких платформ, как Raspberry Pi, в которых работает Linux, вы можете использовать множество различных языков сценариев (Python, Ruby, Node.js) для обработки JWT, а на веб-сайте JWT.io представлено несколько SDK, доступных для вашего использования.
Использование JWT на IoT-серверах
Как я уже упоминал в разделе устройств, вы можете использовать SDK, упомянутые на веб-сайте JWT.io, чтобы контролировать, как вы обрабатываете проверку JWT на вашем сервере.
Например, если вы используете Node.js и Express, будет express-jwt промежуточное программное обеспечение express-jwt которое будет препятствовать доступу пользователей или устройств к маршрутам без проверенного JWT.
Теперь, когда мы рассмотрели использование JWT на практике, давайте поговорим о некоторых практических правилах, которые следует учитывать при использовании JWT в вашей архитектуре IoT.
Некоторые общие советы с JWT
Это кусочки обучения, которые я изучил в течение своего времени с помощью JWT, и некоторые из них — немного здравого смысла. Но о них стоит помнить при реализации JWT в вашей архитектуре.
Всегда проверяйте подпись
Когда ваш сервер получает запрос с токеном, всегда проверяйте эту подпись, иначе вы потеряете основную ценность использования JWT — зная, что отправитель — это то, кем они себя называют!
Используйте (и применяйте) поле Expiry
В стандартах поле iat соответствует времени выдачи токена, а поле exp — метке времени истечения токена. Настоятельно рекомендуется использовать и применять эти два поля, особенно если у вас есть конфиденциальная информация. Таким образом, в конце концов, если токен выйдет, он истечет.
Как поле id может быть очень удобным
Ожидание истечения срока действия скомпрометированного токена — это одно, но возможность активно отозвать токен также полезно. В этом может помочь утверждение JTI (идентификатор токена JSON) — вы можете отменить доступ к определенным идентификаторам вместо того, чтобы изменить секрет и отозвать все токены одновременно! Просто убедитесь, что ваши JTI очень устойчивы к коллизиям, как и любой GUID.
Вывод
Спасибо, что поддержали меня и узнали о том, как вы можете защитить свои устройства IoT с помощью JSON Web Tokens!