Comments 7
Как все же использовать 508, что бы не заблокировать?
Документация расплывчата…
Документация расплывчата…
добавлю ещё что aws iot допускает «нецелевое» использование в веб-разработке. если в веб-приложении нужны пуши, а само приложение написано на лямбдах (или просто нет желания возиться с socket.io или настраивать centrifugo, или просто есть сомнения в части масштабирования) – нужен отдельный облачный websocket-сервер.
aws iot эту задачу решает полностью – вам в идеале понадобится авторизация через cognito, iam-роли для авторизованных и неавторизованных пользователей. для неавторизованных доступ к топикам iot определяется в iam-роли, для авторизованных права доступа должны быть как в iam-роли, так и в iot-политике, которая подключается к cognito identity с помощью iot.attachPrincipalPolicy. есть небольшая проблема в том что для приватных топиков в политике можно использовать идентификатор identity но нет переменной, которая бы содержала идентификатор пользователя из userpool, в то время как в jwt-токене есть только второй.
я выкрутился, добавив лямбду, которую фронтенд дёргает с id-токеном, она хранит в dynamodb мэппинг с userpool id на identity id, и если нужного мэппинга для нового юзера ещё нет, сразу делает и iot.attachPrincipalPolicy. имея такой мэппинг, можно всегда отправить приватный пуш когнито-юзеру с бэкенда по его userpool-идентификатору.
было бы конечно намного проще если бы в userpool был метод получения identity id, или чтобы можно было userpool id использовать как переменную в iam-политике. копаясь на амазоновском форуме я нашёл даже достаточно старые темы от людей, столкнувшихся с теми же трудностями. по видимому архитектура cognito делает решение этой задачи нетривиальным, раз они до сих пор не могут этого сделать…
aws iot эту задачу решает полностью – вам в идеале понадобится авторизация через cognito, iam-роли для авторизованных и неавторизованных пользователей. для неавторизованных доступ к топикам iot определяется в iam-роли, для авторизованных права доступа должны быть как в iam-роли, так и в iot-политике, которая подключается к cognito identity с помощью iot.attachPrincipalPolicy. есть небольшая проблема в том что для приватных топиков в политике можно использовать идентификатор identity но нет переменной, которая бы содержала идентификатор пользователя из userpool, в то время как в jwt-токене есть только второй.
я выкрутился, добавив лямбду, которую фронтенд дёргает с id-токеном, она хранит в dynamodb мэппинг с userpool id на identity id, и если нужного мэппинга для нового юзера ещё нет, сразу делает и iot.attachPrincipalPolicy. имея такой мэппинг, можно всегда отправить приватный пуш когнито-юзеру с бэкенда по его userpool-идентификатору.
было бы конечно намного проще если бы в userpool был метод получения identity id, или чтобы можно было userpool id использовать как переменную в iam-политике. копаясь на амазоновском форуме я нашёл даже достаточно старые темы от людей, столкнувшихся с теми же трудностями. по видимому архитектура cognito делает решение этой задачи нетривиальным, раз они до сих пор не могут этого сделать…
constb,
купите aws green glass и будут вам все плюшки в одном пакете под вашей крышей
купите aws green glass и будут вам все плюшки в одном пакете под вашей крышей
это вроде совсем из другой области штука. учитывая нашу специфику (веб- и мобильная разработка), мы скорее с интересом смотрим в сторону AWS AppSync и AWS Amplify, а также с нетерпением ждём релиза AWS Serverless Aurora конечно же…
green glass — это инстанс IoT, который вы развораиваете на вашем _чего то там железном_ с кусочком лямбда. И все ваши девайсины ходят не сазу в мир, а к ней. Цена — вполне смешная, что бы попробовать
(К примеру амазон рассказывает о проекте с карьерными грузовиками. Какой там может быть интернет?! а вот доступ к gg совсем не проблема.
(К примеру амазон рассказывает о проекте с карьерными грузовиками. Какой там может быть интернет?! а вот доступ к gg совсем не проблема.
Все это конечно классно — использование готовых облачных решений, но как мне кажется, ключевой момент в безопасности IoT — это использовать свои сервисы, контроль разработки и управления на предмет утечек секретных ключей от этих сервисов (случайные или преднамеренные), а так же наличие предусмотренной возможности смены всех данных для авторизации IoT устройств в случае компрометации ключей. Недавние раскрытые утечки ключей от AWS крупных клиентов тому доказательства.
«Недавние раскрытые утечки ключей от AWS крупных клиентов тому доказательства.»
Важно только уточнить, что утечка ключей была через github репозитории тех самых «крупных клиентов», а не непосредственно из AWS.
И сама эта утечка еще одно напоминание что в сфере обеспечения безопасности нет мелочей и нет людей, связанных с разработкой, которые не должны думать над ней постоянно…
Важно только уточнить, что утечка ключей была через github репозитории тех самых «крупных клиентов», а не непосредственно из AWS.
И сама эта утечка еще одно напоминание что в сфере обеспечения безопасности нет мелочей и нет людей, связанных с разработкой, которые не должны думать над ней постоянно…
Sign up to leave a comment.
AWS IoT и безопасность