Identity and Access Management (IAM)

IoT デバイスは多くの場合、信頼された ID でプロビジョニングされ、戦略的な顧客やビジネスデータ (ファームウェア自体など) を保存またはアクセスでき、インターネット経由でリモートにアクセスでき、直接的な物理的改ざんを受けやすいため、ターゲットとなります。不正アクセスに対する保護を提供するには、常にデバイスレベルでセキュリティを実装することから始める必要があります。ハードウェアの観点からは、デバイス上の機密情報の改ざんの攻撃対象領域を減らすために実装できるメカニズムがいくつかあります。

デバイスハードウェアを保護するには、プライベートキーと機密性の高い ID が固有であり、安全なハードウェアの場所にあるデバイスにのみ保存されるソリューションを実装します。AWS IoT との通信に使用されるプライベートキーへのアクセスを安全に保存および管理するハードウェアまたはソフトウェアベースのモジュールを実装します。ハードウェアのセキュリティに加えて、IoT デバイスには有効な ID が与えられなければなりません。この ID は IoT アプリケーションでの認証と承認に使用されます。

デバイスの有効期間中は、証明書の更新と失効を管理できる必要があります。デバイス上の証明書情報の変更を処理するには、まずフィールドでデバイスを更新できる必要があります。ハードウェアでファームウェアの更新を実行する機能は、Well-Architected IoT アプリケーションにとって重要な基盤となります。OTA 更新により、認証機関を含め、有効期限が切れる前にデバイス証明書を安全にローテーションします。

例えば、AWS IoT では、まず X.509 証明書をプロビジョニングしてから、IoT への接続、メッセージのパブリッシュとサブスクライブ、および更新の受信のための IoT アクセス許可を個別に作成します。この ID とアクセス許可の分離により、デバイスのセキュリティを管理する柔軟性が得られます。アクセス許可の設定中に、各デバイスの MQTT アクションへのアクセスを制限する IoT ポリシーを作成することで、どのデバイスにも適切なレベルの ID と適切なレベルのアクセスコントロールがあることを確認できます。

AWS IoT で各デバイスに固有の X.509 証明書があり、デバイスが証明書を共有しないようにします (1 つのデバイスルールに 1 つの証明書)。デバイスごとに 1 つの証明書を使用することに加えて、AWS IoT を使用する場合、各デバイスには IoT レジストリに独自のモノが必要です。また、モノ名は MQTT 接続用の MQTT ClientID のベースとして使用されます。

1 つの証明書が AWS IoT Core で独自のモノとペアになっているこの関連付けを作成することで、侵害された証明書が誤って別のデバイスの ID を引き受けることを防ぐことができます。また、MQTT ClientID とモノの名前が一致すると、ClientID ログメッセージをその特定の通信部分に関連付けられているモノに関連付けることができるため、トラブルシューティングと修復が軽減されます。

デバイス ID の更新をサポートするには、OTA 通信とバイナリをデバイスに配信するためのマネージドプラットフォームである AWS IoT ジョブを使用します。AWS IoT ジョブは、AWS IoT に接続された 1 つ以上のデバイスに送信および実行される一連のリモート運用を定義するために使用されます。AWS IoT ジョブは、デフォルトで、相互認証と承認、更新の進行状況のデバイス追跡、特定の更新のフリート全体のメトリクスなど、いくつかのベストプラクティスを統合します。

AWS IoT Device Defender 監査を有効にして、デバイスの設定、デバイスポリシー、期限切れの証明書のチェックを自動化された方法で追跡します。例えば、Device Defender はスケジュールに基づいて監査を実行し、証明書の有効期限が切れる通知をトリガーできます。失効した証明書または失効保留中の証明書の通知を受信すると、証明書を事前に更新できる OTA を自動的にスケジュールできます。

多くのアプリケーションは IoT のモノの側面に重点を置いていますが、IoT のほぼすべての階層的な市場では、デバイスとの通信やデバイスからの通知の受信を必要とする人間のコンポーネントもあります。例えば、コンシューマー IoT では、通常、ユーザーがデバイスをオンラインアカウントに関連付けることでデバイスをオンボードする必要があります。インダストリアル IoT では、通常、ほぼリアルタイムでハードウェアテレメトリを分析する機能が必要です。いずれの場合も、アプリケーションが、特定のデバイスとのやり取りを必要とするユーザーを識別、認証、および承認する方法を決定することが不可欠です。

IoT アセットへのユーザーアクセスの制御は、ID から始まります。IoT アプリケーションには、ユーザーの ID と、その ID を使用してユーザーが認証する方法を追跡するストア (通常はデータベース) が必要です。ID ストアには、承認時に使用できる追加のユーザー属性 (ユーザーグループのメンバーシップなど) が含まれる場合があります。

IoT デバイスのテレメトリデータは、セキュリティ保護可能なアセットの一例です。このように処理することで、各ユーザーが持つアクセスを制御し、個々のユーザーのやり取りを監査できます。

AWS を使用して IoT アプリケーションユーザーを認証および承認する場合、ID ストアを実装するためのいくつかのオプションと、そのストアでユーザー属性を維持する方法があります。独自のアプリケーションでは、ID ストアに Amazon Cognito を使用します。Amazon Cognito は、承認の決定を行うためにアプリやその他の AWS のサービスによって直接使用される方法で、ID を表現し、ユーザーを認証する標準的なメカニズムを提供します。  AWS IoT を使用する場合、Amazon Cognito ID プール、AWS IoT ポリシー、AWS IoT カスタムオーソライザーなど、いくつかの ID および承認サービスから選択できます。

ユーザーのテレメトリの疎結合化ビューを実装するには、AWS AppSync や Amazon API Gateway などのモバイルサービスを使用します。これらの AWS のサービスでは、IoT データストリームをユーザーのデバイスデータ通知ストリームから疎結合化する抽象化レイヤーを作成できます。例えば、中間データストアで外部ユーザー用にデータの個別のビューを作成することによって可能です。Amazon DynamoDB または Amazon ElasticSearch Service では、AWS AppSync を使用して、中間ストアで許可されているデータのみに基づいてユーザー固有の通知を受信できます。AWS AppSync で外部データストアを使用することに加えて、IoT データの特定のビューを外部ユーザーにプッシュするために使用できるユーザー固有の通知トピックを定義できます。

外部ユーザーが AWS IoT エンドポイントに直接通信する必要がある場合は、そのユーザー ID が、承認された Amazon Cognito ロールおよびきめ細かい IoT ポリシーに関連付けられ承認された Amazon Cognito フェデレーティッド ID であることを確認するか、AWS IoT カスタムオーソライザーを使用して承認が独自の承認サービスによって管理されることを確認します。どちらの方法でも、MQTT 通信に関して、ユーザーによる接続、パブリッシュ、サブスクライブ、およびメッセージ受信を制限する、きめ細かなポリシーを各ユーザーに関連付けます。

デバイスを登録してその ID を確立した後、モニタリング、メトリクス、テレメトリー、またはコマンドと制御に必要な追加のデバイス情報をシードする必要がある場合があります。各リソースには、アクセスコントロールルールの独自の割り当てが必要です。デバイスまたはユーザーがアプリケーションに対して実行できるアクションを減らし、各リソースを個別に保護することで、1 つの ID またはリソースが誤って使用された場合に発生する可能性のある影響を制限できます。

AWS IoT では、IoT レジストリの一貫した命名規則を使用して、きめ細かなアクセス許可を作成します。最初の規則では、MQTT ClientID および AWS IoT モノの名前と同じ一意の識別子を使用します。これらのすべての場所で同じ一意の識別子を使用することで、AWS IoT Thing Policy 変数を使用してすべてのデバイスに適用できる IoT アクセス許可の初期セットを簡単に作成できます。2 番目の命名規則は、デバイスの一意の識別子をデバイス証明書に埋め込むことです。このアプローチを続行して、証明書のサブジェクト名に CommonName として一意の識別子を保存し、証明書ポリシー変数を使用して IoT アクセス許可を各一意のデバイス認証情報にバインドします。

ポリシー変数を使用することで、最小限の権限を維持しながら、すべてのデバイス証明書に適用できるいくつかの IoT ポリシーを作成できます。例えば、以下の IoT ポリシーでは、デバイスの一意の識別子 (共通名で保存) を MQTT ClientID として使用し、証明書がデバイスにアタッチされている場合のみ、すべてのデバイスが接続するように制限されます。また、このポリシーは、個々のシャドウでのみパブリッシュするようにデバイスを制限します。

{
"Version": "2012-10-17",
"Statement": [{
"Effect": "Allow",
"Action": ["iot:Connect"],
"Resource": ["arn:aws:iot:us-east-1:123456789012:client/${iot:Certificate.Subject.CommonName}"],
"Condition":{
"Bool":{
"iot:Connection.Thing.IsAttached":["true"]
}
}
},
{
"Effect":"Allow",
"Action":["iot:Publish"],
"Resource":["arn:aws:iot:us-east-1:123456789012:topic/$aws/things/${iot:Connection.Thing.ThingName}/shadow/update"]
}
]
}

AttachThingPrincipal を使用して、デバイス ID (証明書または Amazon Cognito フェデレーティッド ID) を AWS IoT レジストリのモノにアタッチします。

これらのシナリオは、独自のトピックおよび Device Shadow のセットと通信する 1 つのデバイスに適用されますが、1 つのデバイスが他のデバイスの状態またはトピックに基づいて動作する必要があるシナリオもあります。例えば、業界設定でエッジアプライアンスを運用する、ホームゲートウェイを作成してホームで調整オートメーションを管理する、またはユーザーが特定のロールに基づいて異なるデバイスセットにアクセスできるようにするなどです。このようなユースケースでは、グループ識別子やエッジゲートウェイの ID などの既知のエンティティを、ゲートウェイと通信するすべてのデバイスのプレフィックスとして活用します。すべてのエンドポイントデバイスに同じプレフィックスを使用させることで、IoT ポリシーでワイルドカード「*」を使用できます。このアプローチでは、MQTT トピックのセキュリティと管理可能性のバランスを取ります。

{
"Version": "2012-10-17",
"Statement": [
{
"Effect":"Allow",
"Action":["iot:Publish"],
"Resource":["arn:aws:iot:us-east-1:123456789012:topic/$aws/things/edgegateway123-*/shadow/update"]
}
]
}

前の例では、IoT 演算子は、識別子 edgegateway123 を持つエッジゲートウェイにポリシーを関連付けます。このポリシーのアクセス許可により、エッジアプライアンスは、エッジゲートウェイによって管理される他の Device Shadow にパブリッシュできるようになります。これは、ゲートウェイに接続されたすべてのデバイスに、ゲートウェイの識別子がプレフィックスとして付けられたモノの名前があることを強制することによって実現されます。例えば、ダウンストリームモーションセンサーは edgegateway123-motionsensor1 という識別子を持つため、アクセス許可を制限しながらエッジゲートウェイで管理できるようになりました。