AWS IoT Core を用いた認可ポリシーのスケーリング

はじめに

IoTソリューションを構築するソリューションアーキテクト、開発者、およびシステム設計者は、ソリューション全体において、データとデータを操作する機能を適切に保護する必要があります。この投稿では、 AWS IoT Core を使用したマルチユーザーおよびマルチデバイスのユースケースに焦点を当て、認可ポリシーのスケーリングのためのいくつかの設計手法について説明します。デバイス、ユーザー間のカーディナリティやスケールのレベルに応じたパターンを紹介します。 AWS IoT サービス上にソリューションを構築する際のセキュリティ設計やアーキテクチャ検討時に活用頂ければと思います。

IoT デバイス、ネットワークパス、エンドユーザーデバイス、データベース、バックエンドシステムなど、データのやり取りが発生するあらゆるコンポーネントにおいてセキュリティ対策が必要です。IT セキュリティにおいて、セキュアなアーキテクチャを検討する際には、「AAA」と言われる3つのAを考慮する必要があります。それぞれ、 Authentication （認証）、 Autorization （認可）、 Accounting （アカウンティング）または Auditing （監査）です。 AAA は、セキュリティ要件を整理し、それらの要件とソリューションアーキテクチャを対応付ける方法です。この方法により、ソリューションの利害関係者、エンドユーザー、およびコンプライアンスの専門家は、関連する重要な要件を満たすために、どのようにソリューションが設計されているかを把握することができます。

IoT ソリューションは、固有の設計要素をもつ分散システムアーキテクチャを意味します。分散システムアーキテクチャでは、補完的な分散セキュリティソリューションが必要になります。多くのお客様は、クラウド内の分散システムや、クラウドとオンプレミスのエンタープライズシステムを統合するハイブリッドアーキテクチャの ID （認証）機能を実現するために、 ID フェデレーション（ ID 連携）を使用しています。この手法は IoT のデータと機能の保護にも利用できます。 AWS ID フェデレーションオプションの詳細については、 ID フェデレーションの記事をご覧ください。

ID の強固なソリューションを導入すれば、2番目の「A」である認可の要件への対応に集中できます。 IoT ソリューションの開発者が直面する一般的な認可のユースケースに焦点を当てます。一般的に、ユーザー、デバイス間の構成は 1:1 、もしくは 1:多となることが多いため、以降ではそれらのケースについて例をご紹介します。

単純なユースケース： 1 ユーザー 1 デバイス（1:1）

1 ユーザーが 1 つのデバイスを利用するケースは、最も理解しやすく、 IoT Core での設定も容易です。 1:1 のユースケースが利用可能なシナリオとしては、プロトタイプ開発や個人向けのデバイスがあります。多くのプロトタイプでは、 1:1 の構成をそのまま適用でき、開発時の迅速な修正や設定変更が可能です。もう一つのシナリオは、個人向けのデバイスを使用するエンドユーザーに向けたものです。エンドユーザーは、Webブラウザやスマホアプリなど複数のインターフェースを利用して、自分の持つ1つのデバイスとやり取りしたいと考えています。

本記事では、「個人向け」という言葉を、例えば歯ブラシのように、そのデバイスが 1 人の個人に使われるように設計されていることを明示する意味で使用しています。歯ブラシを他人とシェアするようなユースケースの場合は、記事後半の多ユーザー多デバイス（m:n）のユースケースをご覧ください。

技術的には、 1:1 のユースケースは Amazon Cognito identitiy service を使用することで、AWS IoT Core 上で実現することが可能です。アプリケーションやその管理者は、 AWS IoT Core 上で、 Amazon Cognito principal として個々のユーザーに対して AWS IoT ポリシーをアタッチすることが可能です。この設定により、 Amazon Cognito principal が、 HTTPS や MQTT over WebSockets を用いて直接 AWS IoT Core のエンドポイントにアクセス可能になります。また、 AWS IoT Core のポリシーによって、 IoT デバイスと同様の権限が Amazon Cognito principal に付与されます。すなわち、 MQTT トピックのいかなるネームスペースを用いた通信も可能になります。例えば、デバイスシャドウやジョブのやり取りで使用される、 $aws で始まるトピックも使用できます。
1:1 のユースケースシナリオ実現のための Amazon Cognito や IoT Core の設定方法の詳細については、ブログ記事「Configuring Cognito User Pools to Communicate with AWS IoT Core」をご覧ください。

ユースケースの拡張：1 ユーザー多デバイス（1:m）

今度は、1 人のエンドユーザーに対して複数のデバイスが紐づくユースケースを見ていきます。ここでは仮に、エンドユーザー（名前をシェリルとします）が複数の IoT デバイスを保持するとしましょう。シェリルのもつ複数のデバイスは、同じブランドで、 1 つのアプリケーションから管理できることが特長です。アプリケーションやデバイスソフトウェアの開発者は、このソリューションにおける AAA の要件を、機能要件を定義する段階で必ず考慮する必要があります。

この場合、エンドユーザーのアプリケーションから、複数のデバイスと通信を行う必要があります。一見簡単そうに見えるかもしれません。 AWS IoT Core のポリシーを各デバイスごとに作成し、シェリルに紐づく Amazon Cognito principal にアタッチすることが可能です。そして、先ほどと同様の ID フェデレーションが利用できます。 Amazon Cognito ユーザープールのほか、Google 、 Facebook 、 Login with Amazon など他のIDプロバイダーも利用可能です。

しかし、このソリューションには注意点があります。このユースケースにおいて重要であり、特に次のような使用例では非常に重要になります。より詳しく見ていきます。

エンティティの数（例えば、ユーザー、プリンシパル、デバイス、インスタンスなど）は、一見無制限のようにみえますが、確認すべき上限値が存在します。多くの場合には、その上限は大きく、遠く離れた値ですが、ソリューションの将来的な展開を考慮し確認をすることは大切です。ただし一般的なユースケースでは、これらの上限値は設計上考慮する必要は多くありません。以降で説明するような特別なシチュエーションでは、いくつかの上限値について、評価を行う必要があります。

まず、シェリルが使用できるデバイスの数は多数であるため、その分のポリシーを追加しますが、そこで上限値があるかどうかを確認する必要があります。この要件を解決するため、デバイスごとに新しいポリシーを作成し、それをシェリルの Amazon Cognito ID プリンシパルにアタッチすることにしました。 AWS IoT サービス割り当てのドキュメントを調べて、考慮すべき上限があるかどうかを確認してみましょう。

次のような制限があることがわかります：
証明書または Amazon Cognito Identity にアタッチできるポリシーの最大数 – 10

ポリシードキュメントの最大サイズ– 2048 文字（空白を除く）

つまり、シェリルが保持できるデバイス数は、最大 10 台に制限されます。デバイスの種類によっては、これで十分な場合があります。シェリルがスマートフォンまたは Web アプリケーションを使用してサーモスタット、給湯器、照明コントローラー、および 1、2 台の家電製品を管理しているシナリオでは、制限は 10 の半分に過ぎません。一方で、家の各電球、庭の各スプリンクラーヘッド、壁のすべての電源コンセントが対象になる場合、ユーザーあたりのデバイス数の上限である 10 を簡単に超える可能性があります。

これの課題を解決する方法がいくつかあります。別のアプローチを考えてみましょう。

最小限のポリシードキュメントに複数デバイスのアクセス権限を集約

デバイスポリシーのドキュメントは、 AWS IoT Core とデバイス間のやり取りにおける基本機能を保護します。基本的に、 AWS IoT Core とのインターフェイスは MQTT トピックです。デバイスを保護するということは、本質的には、不必要な通信からトピックを保護することを意味します。デフォルトでは AWS IoT Core のトピックはすべて拒否されています。デバイスゲートウェイのエンドポイントに接続するためのアクセス許可も明示的に付与する必要があります。複数デバイスのトピックに関連付けられたアクションとリソースへのアクセス許可を 1 つのポリシーにまとめることを自体は容易ですが、唯一の制約は、空白（印刷できない文字）を除いたポリシードキュメントの合計サイズが 2048 文字未満にしなければならないことです。

設計においては、そのポリシーが最大サイズに近づき始めるまでは、単一のポリシーにデバイス権限を追加できるということです。次に、新しいポリシーを作成して、追加の権限を追加します。

次のようなアプローチを検討してみましょう。

初期状態：シェリルの Amazon Cognito ID が存在し、1つのポリシーがアタッチされています。

望ましい操作：「cheryl-kitchen-light-01」という名前をつけたシェリルの IoT キッチンライトについて、シャドウのトピックを操作する機能を追加します。

まず、シェリルのキッチンライトデバイスの権限を追加するために必要な JSON を作成する必要があります。接続、パブリッシュ、サブスクライブ、および受信をすでに許可しているポリシーに対して、シャドウトピックを追加するためのリソース文字列は以下のようになります。

パブリッシュ、および受信のアクション（85文字）：
arn:aws:iot:us-east-1:123456789012:topic/$aws/things/cheryl-kitchen-light-01/shadow/*

サブスクライブアクション（91文字）：
arn:aws:iot:us-east-1:123456789012:topicfilter/$aws/things/cheryl-kitchen-light-01/shadow/*

あわせて 176 文字を IoT ポリシーに追加する必要があります。

これを行うには、アプリケーションコードで次のアクションを実行します。

ListPrincipalPolicies を使用して、シェリルの Amazon Cognito プリンシパルにアタッチされているポリシーを確認します。

各ポリシーについて、以下を実行します。

GetPolicy を使用してポリシードキュメントを取得します。（このサービスクォータに注意してください。現在、 GetPolicy などの特定のコントロールプレーンコールには 10 トランザクション/秒（TPS）の制限があります。）

1.ポリシードキュメントから空白を取り除き、サイズを確認します。

2.ポリシーのサイズに空きがある場合（現在のサイズ+ 176 が 2048 未満）

リソースをポリシーに追加します。

3.ポリシーのサイズに空きがない場合

次のポリシーに進みます。

サイズに空きのあるポリシーが見つからない場合、ポリシーの最大数である 10 に達していなければ、新しいポリシーを作成可能です。 10 個のポリシーがアタッチされ、さらにそれらがすべて最大サイズに近い場合、エラーとして処理を行うか、他の方法を考える必要があります。

モノの名前を工夫することによるスケーリング：多ユーザー多デバイス（m:n）

オブジェクトの命名方法については、コンピューティングにおける長い歴史があります。コンピュータプログラムの変数と同様に、オブジェクトの名前付けは、システムの包括性と使いやすさに大きな影響を与える可能性があります。オブジェクトの命名規則を適切に決めておくことで、様々な用途において、よりエレガントな設定が可能になります。

AWS IoT Core には、様々な種類のエンティティがあります。まず、ポリシー、証明書、モノがあります。それに加えて、モノのタイプ、属性、モノのグループもあり、これらによってよりリッチなデバイス管理のが可能となります。このスケーリングのユースケースでは、 IoT ポリシーの名前付けとワイルドカード機能を使用します。

まず、プレフィックスを使った命名による抽象化について考えてみましょう。 Amazon Simple Storage Service（S3）をよく使われる方は、名前空間がどのように機能するか知っているかもしれません。名前空間はフラットですが、命名にプレフィックスと区切り記号を使用することで、階層的な機能を利用することが可能です。この概念を使用して、モノの名前空間に階層管理を追加し、モノのグループ化を可能にします。

このシナリオでは「モノのグループ」と呼ばれる AWS IoT Device Management の機能を使用していません。モノのグループ機能は、デバイスの編成と管理に多くの有用な目的を果たしますが、今回のような特別なユースケースを目的としたものではありません。

シェリルとその家族、そして接続されたデバイスでいっぱいのスマートホームに戻りましょう。

シェリルが最初のスマートデバイスを購入するところから始めましょう：スマートホームハブ、複数のスマート電球、ガレージのドア開閉装置、そしてスマートバードフィーダーがあるとしましょう。

シェリルは、関連付けられた Web サイトにスマートハブを登録することにより、セットアップを開始します。彼女はアカウントを作成し、デバイスを自分のアカウントに追加します。この時点で、アプリケーションがシェリルのアカウントに一意のプレフィックスを生成するとします。このプレフィックスを「 xyz123 」と呼びます。

シェリルの最初のデバイスが彼女のアカウントで登録されると、 AWS IoT Core のモノの名前がプレフィックス xyz123 で作成されます。したがって、シェリルのスマートハブのモノの名前は xyz123-home-hub-00 のようになります。次に、シェリルは次のような名前で他のデバイスをアカウントに追加します。

ガレージのドア開閉装置： xyz123-garage-door-00

スマートバードフィーダー： xyz123-bird-feeder-00

シェリルは、自分のすべてのデバイスを自分のアカウントに追加して、合計で 12 台のデバイスを追加します。これは、ポリシーの上限は 10 であるため、シェリルの Amazon Cognito プリンシパルに 12 のポリシーをアタッチすることはできません。さらに、シェリルは、彼女のデバイスへのアクセスを、 4 人の追加の家族の残りのメンバーに許可する予定です。

プレフィックスの命名スキームを使用して、以下のようなポリシーを作成できます。これにより、ポリシーがアタッチされているプリンシパルに、デバイスシャドウのような特別なトピックにアクセスするためのアクセス許可が付与されます。


{
    "Version" : "2012-10-17",
    "Statement": [
            {
                "Effect" : "Allow",
                "Action" : [
                    "iot:Publish",
                    "iot:Receive"
                ],
                "Resource": "arn:aws:iot:us-east-1:1234567890:topic/$aws/things/xyz123*/shadow/*"
            },
            {
                "Effect" : "Allow",
                "Action" : [
                    "iot:Subscribe"
                ],
                "Resource" : "arn:aws:iot:us-east-1:1234567890:topicfilter/$aws/things/xyz123*/shadow/*"
            }
        ]
}

このポリシーは、 xyz123-policy-00 のような名前を付けて 1 回作成し、シェリルの Amazon Cognito プリンシパルだけでなく、家族の各メンバーに関連付けられた各 Amazon Cognito プリンシパルにもアタッチできます。このポリシーは、プレフィックスが xyz123 で始まる名前のすべてのモノについて、シャドウサービスのトピックについて認可を提供します。

名前付けプレフィックスを使用することで、サイズとカウントなどを駆使したポリシー管理を行う必要がなくなり、エンドユーザーごとにグループ化された、名前付きのコレクションを提供できます。このソリューションはシンプルなうえに、ポリシーのサイズやアタッチできるポリシーの数のサービス上限内で適切に機能します。

まとめ

ここでは、シンプルな ID フェデレーションの使い方から、認可ポリシーのスケールアウトのためのプレフィックス付きの命名方法まで、多くのことを取り上げました。どのユースケースにおいても最も重要なのは、信頼できる ID のみが、 IoT ソリューションに限らずデジタルシステム全体の機能やデータにアクセスできるインターフェースを用意することです。 AWS IoT Core が提供する様々な手法を柔軟に組み合わせることで、システムをスケーラブルで、弾力性があり、安全に設計することが可能となります。

原文はこちら。翻訳はソリューションアーキテクト飯田が担当しました。

Amazon Web Services ブログ