Amazon Web Services ブログ
AWS IoT Deep Dive #1 2020 上半期 AWS IoT アップデート 資料と録画、Q&Aを公開
こんにちは、IoTソリューションアーキテクトの飯塚です。本ブログ記事では、AWS IoT Deep Diveセミナーシリーズの第1回目の開催内容と資料、当日いただいたご質問とその回答をまとめていきたいと思います。
AWS IoT Deep Diveセミナーとは
本セミナーシリーズは、このタイトル通り、お客様がIoT製品やサービスを設計・開発する際のよくある課題や考慮すべき事項を共有し、AWSによるソリューションをより深く・詳細にお伝えするセミナーです。本セミナーイベントの詳細については、以下のブログ記事にて説明していますので、是非ご覧ください。
AWS IoT Deep Dive – 新しいAWS IoTセミナーシリーズを開始します
#1 2020 上半期 AWS IoTアップデート
本セミナーシリーズ初めての開催となった#1は、9/2にオンラインにて開催されました。今回は「2020 上半期 AWS IoTアップデート」をテーマに、2つの技術トピックについてお話しさせていただきました。2020 年前半にあったサービスや機能アップデートと、IoT 製品の開発の際に課題となる認証情報のプロビジョニングについて、AWS IoT が用意している様々な手段について解説しました。
本セミナーの録画を以下に用意しておりますので、当日参加できなかった方は是非ご覧ください。
ここで両セッションの内容を簡単にまとめていきたいと思います。
AWS IoT サービスアップデートのご紹介
本セッションはAWSのIoTソリューションアーキテクトの三平より紹介させていただきました。本セッションでは、
- AWSのIoTサービスの2020年1月から8月にあったアップデートの内容
- これらの新機能の使い方
- これらの実ユースケースでの活用方法
について説明しました。
AWS IoTにおけるデバイスへの認証情報のプロビジョニング
本セッションはAWSのIoTソリューションアーキテクトの飯塚より紹介させていただきました。本セッションでは、
- IoTデバイスにおける認証のベストプラクティス
- AWS IoTにおける証明書の発行とデバイス登録の方式
について解説しました。
AWS IoTにおけるデバイスへの認証情報のプロビジョニング
Q&A
セミナー当日に参加者の皆様からいただいたご質問とその回答を記載します。
Q. AWS IoT Greengrass Coreのアップグレードがaptで行えるようになりましたが、Greengrass CoreをOTAで更新した場合にaptとの整合性はどのようになるのでしょうか？
Greengrass Core を apt でインストールした場合、無線通信 (OTA) による更新はサポートされていません。詳細は下記ドキュメントをご確認ください。
https://docs.thinkwithwp.com/ja_jp/greengrass/latest/developerguide/install-ggc.html#ggc-package-manager
Q. マルチアカウント対応のCAをなしで登録した場合、ありと比べると セキュリティレベルなどは下がってしまうのでしょうか？
マルチアカウント登録によって登録されたクライアント証明書を利用した場合に、クライアント証明書を用いたクライアント認証や、データ転送時のTLSによる通信の暗号化自体のセキュリティレベルが低くなることはございません。マルチアカウント登録に限った話ではございませんが、証明書の登録に際して信頼された作業者や方法によって証明書が登録されるようにする必要があります。AWS IoT Device Defender を利用すると、複数のクライアントからの同一の証明書の利用を検知することなどができますので、セキュリティ対策の強化方法の1つとしてご検討ください。
また、AWS IoT におけるセキュリティに関しては下記ドキュメントもご参照ください。
https://docs.thinkwithwp.com/ja_jp/iot/latest/developerguide/iot-security.html
Q. 名前付きシャドウの具体的な利用用途はClassic Shadowと比較して、どのようなケースがありますでしょうか？ また、専用のWeb画面などから複数のモノのシャドウ情報を一括で変更したいのですがモノ１個ずつに変更のAPI発行するのではなく、今回の名前つきシャドウを使って１回のAPIで複数のモノの一括変更が可能になるなど、可能になる手法はありますでしょうか？
今まで Classic Shadow にデバイスの全ての状態を集約していた場合、名前付きシャドウを用いることで、用途や更新タイミングの異なる状態をそれぞれ別のシャドウとして管理することができるようになります。例えば、デバイスへのオン・オフの制御と、デバイスの設定、デバイスのファームウェアのバージョンなどをそれぞれ異なる名前付きシャドウとして管理するといった使い方が考えられます。
また、複数のモノのシャドウの情報を一括で変更するAPIの提供はございません。複数のデバイスに対して一括で制御コマンドを送りたい場合には、MQTTのトピック設計として Broadcast パターンを使う方法などが考えられます。
参考リンク: https://thinkwithwp.com/jp/blogs/news/about_designing_mqtt_topics_for_aws_iot_core/
Q. AWS IoT Device Defenderのアップデートは、クラウド側の機能のみと考えて良いでしょうか？
はい、今回のセッションでご紹介したディメンション機能および監査結果抑制機能はクラウド側の機能のアップデートとなります。なお、デバイス側のエージェントのサンプル実装は下記Githubのリポジトリからご確認いただけます。
https://github.com/aws-samples/aws-iot-device-defender-agent-sdk-python
Q. mp4のクリップ出力は、webRTC版ではなくて、旧来版での話という理解で良いですか？
はい、Amazon Kinesis Video Streams の WebRTC の方式ではなく、従来から提供しているクラウドへ動画を取り込み、保存する方式の機能として、MP4 形式でのクリップ出力機能を提供しております。API の仕様については下記ドキュメントをご参照ください。
https://docs.thinkwithwp.com/ja_jp/kinesisvideostreams/latest/dg/API_reader_GetClip.html
Q. FreeRTOS/AWS IoT Device SDKのハンズオンはないでしょうか？
FreeRTOS に関する日本語のハンズオンは現在提供しておりません。英語版のFreeRTOSハンズオン(M5Stick/ESP32)で公開されているものがございます。
https://teuteuguy.github.io/amazon-freertos-workshop-docs/labs/
また、AWS IoT Device SDK のみを対象としたハンズオンの提供はありませんが、AWS IoT Events ハンズオン内で、AWS IoT Device SDK Python v2 を利用したクライアントを動かす手順がございますので、サンプル実装としてご参照ください。また、各種 Device SDK ではサンプルプログラムを提供しておりますので、そちらもあわせてご参照ください。
https://aws-iot-events-for-beginners.workshop.aws/chapter2/step3.html
Q. 注釈にありましたが、マルチアカウントCAでは、credential provider機能は使えないということでしょうか？回避策等はありますか？
下記ドキュメントに掲載がある通り、マルチアカウント登録に使用される証明書を使用して認証情報プロバイダーから一時認証情報を取得することはできません。ワークアラウンドとしては、AWS IoT Core発行の証明書もしくはAWS IoT Coreに登録済みのCAが発行したクライアント証明書をご利用いただくか、一時認証情報を取得する機能を AWS Lambda などで実装し、MQTT メッセージなどを介して認証情報をデバイスへ受け渡すことをご検討ください。
https://docs.thinkwithwp.com/ja_jp/iot/latest/developerguide/x509-client-certs.html#multiple-account-cert
Q. 以前、バルクプロビジョニングというのがあったと思いますが、フリートプロビジョニングはこれとは別の新機能という理解で良いでしょうか？
はい、AWS IoT Device Management のバルクプロビジョニングとフリートプロビジョニングは別の機能です。バルクプロビジョニングは、大量のデバイスの証明書やモノ、ポリシーを事前にまとめて発行する機能です。一方で、フリートプロビジョニングは、デバイスの初回接続時などに1デバイスに対応する証明書などを発行することができます。どちらも、プロビジョニングテンプレートというJSON形式のテンプレートで、生成するリソースを定義する点が共通しておりますが、証明書の発行や登録を行うタイミングが異なります。
https://docs.thinkwithwp.com/ja_jp/iot/latest/developerguide/bulk-provisioning.html
https://docs.thinkwithwp.com/ja_jp/iot/latest/developerguide/provision-wo-cert.html
https://docs.thinkwithwp.com/ja_jp/iot/latest/developerguide/provision-template.html
Q. マルチアカウントは「同一リージョン」でしか実現できないのでしょうか？
いえ、AWS IoT Coreへマルチアカウント登録するクライアント証明書は、同一の証明書を同一アカウントの複数リージョンへ登録ことが可能です。また、複数アカウントの同一リージョンへ同一のクライアント証明書を登録することもできます。一方で、お持ちのCA証明書を登録する場合には、同一のクライアント証明書を同一リージョンの複数アカウントに登録することはできません。CA証明書は、リージョン内の1つのアカウントでのみ登録できます。
https://docs.thinkwithwp.com/ja_jp/iot/latest/developerguide/device-certs-your-own.html
https://docs.thinkwithwp.com/ja_jp/iot/latest/developerguide/register-CA-cert.html
Q. CA登録なしの証明書登録の場合、同一の証明書を複数のリージョンに登録はできないのでしょうか？CAなしだとマルチリージョン展開は難しいということですか？
いえ、可能です。上記に質問に回答を記載しました。
Q. 自社でなく、EMSに生産を頼む場合、どの方式を使うことが多いでしょうか？
EMSに依頼した場合にどの方式が多いというような情報はございません。EMSに依頼する際は、自社やプロダクトのセキュリティポリシーと、EMS側の対応可能なセキュリティレベルおよびコストを勘案して登録方式を決めて頂くことになります。
EMSに依頼する際の登録方式の1つの判断材料として、鍵情報を自社で管理すべきかEMSに渡しても問題ないか、という観点があるかと思います。EMSに一切鍵情報を渡したくないのではあれば、製造時に鍵情報を埋め込むのではなく、デバイスの初回接続時に鍵を配布する方式を選んでいただくことになります。もしくはセキュアチップを利用するかです。一方で渡しても良いのではれば、登録方式の選択肢は広がります。
Q. 秘密鍵がネットワークを通ることに対しては、どれほどのリスクがあるかコメント頂くこと可能でしょうか？（現実的なリスクなのかどうか)
AWS IoT Coreから証明書や秘密鍵をダウンロードする場合も、その通信経路はTLSによって暗号化されます。したがってその暗号化通信の共通鍵を知り得ない限りは通信において秘密鍵が漏洩することはありません。また、発行された秘密鍵は発行時のみAWS IoT Coreからダウンロード可能です。したがって、攻撃者が後から秘密鍵をダウンロードすることはできません。
Q. AWS側にて自動で生成された証明書を効率的に管理するサービス等は存在するのでしょうか？
証明書はAWS IoT Core側で保存されており、DescribeCertificate APIでいつでも取得することが可能です。秘密鍵に関しては、同じものを再発行できないため、お客様の方で管理する必要がございます。また、クライアント証明書及びCA証明書の有効期限を監視するために、AWS IoT Device Defenderを使用いただけます。
Q. Amazonの証明書は2045年に固定とお聞きしました。デバイス内の証明書を2045年以降のものにアップデート出来ますか？
Amazonが管理するCAで発行されるクライアント証明書の有効期限は2049年末、正確には「2049 年 12 月 31 日の午前 0 時 (UTC) (2049-12-31T23:59:59Z)」となります。
https://docs.thinkwithwp.com/ja_jp/iot/latest/developerguide/x509-client-certs.html#x509-client-cert-basics
この有効期限は固定で、皆様の方で変更や設定することができません。
現在のところ、この有効期限が変更される予定はありません。しかしデバイス内に証明書更新の仕組みを入れておくことで、今後証明書を入れ替えることが可能です。
Q. マルチアカウント登録の場合、Jobの利用ができない制限があると思いますが、その要因を教えていただけませんでしょうか？
マルチアカウント登録したクライアント証明書を利用するデバイスがJob機能（データプレーンに対する操作）を利用することはできます。
一方で、マルチアカウント登録したクライアント証明書は、iot:Jobs または iot:CredentialProvider エンドポイントを使用できません。
https://docs.thinkwithwp.com/ja_jp/iot/latest/developerguide/x509-client-certs.html#multiple-account-cert
iot:Jobのエンドポイントタイプは、Jobの管理や制御をするためのコントロールプレーンのHTTPS APIエンドポイントです。
https://docs.thinkwithwp.com/ja_jp/iot/latest/developerguide/jobs-api.html
したがって、Jobを受け取る、状態を報告するなどのデバイス側で利用されるデータプレーンに対する操作は、マルチアカウント登録したクライアント証明書で実行することが可能です。
Q. CAという用語がたくさん出てきましたが、AWS IoTのCA、独自CA、セキュアチップベンダCAのうち、それぞれどれが有効なのかよく分かりませんでした。
AWS IoTでは、お客様の様々なご要件に対応するため、様々な選択肢をご用意しています。今回お話しさせていただいた、証明書の発行やデバイスの登録方式に関しても同様で、要件に合わせて選択できるよう、いくつかの方式をご用意しております。そのためセッション中にご説明した通り、それぞれの方式でできること/できないことがありますので、お客様の要件に合わせて最適なものをお選びいただければと思います。
例えば、認証情報に関して高いセキュリティレベルを求める場合にはチップベンダが発行したクライアント証明書を、CA証明書登録なしでAWS IoTへ登録したり、クライアント証明書の有効期限をご自身で設定されたい場合には、独自CAをAWS IoTに登録したり、CAを運用することなくデバイスの初回接続時に認証情報をデバイスに安全に配布したい場合には、Fleet Provisioningを用いてAmazonが管理するCAを利用することになります。このように、要件や実現したいことに合わせて登録方式を選んでいくことになります。
Q. 御社に確認するのも恐縮ですが、鍵管理はセキュアチップでの管理が標準になりつつあるのでしょうか？
標準というわけではありません。求めるセキュリティレベルとコストに合わせ、セキュアチップを利用するかどうかご判断いただければと思います。
AWS IoTの最新アップデートとイベント情報
IoTに関するサービスやコンテンツ、セミナーやイベントの最新情報をこちらの記事にまとめています。あわせてご覧ください。
最後に
本ブログ記事では、AWS IoT Deep Diveセミナーシリーズの第1回目の開催内容と資料、当日いただいたご質問とその回答をまとめました。本セミナーイベントは今後も実施していく予定ですので、今後もぜひご参加ください。
著者について
IoTソリューションアーキテクト
飯塚 将太