このドキュメントでは、Google Cloud でモノのインターネット（IoT）バックエンドを管理、実行するためのセキュリティのベスト プラクティスについて説明します。IoT ソリューションでは、IoT バックエンドがエッジデバイスを他のリソースに接続します。このドキュメントでは、IoT バックエンドとしての Message Queuing Telemetry Transport（MQTT）ブローカーと IoT プラットフォームについて説明します。
このドキュメントは、Google Cloud の IoT アーキテクチャと IoT Core からの移行についての情報を提供する一連のドキュメントの一部です。このシリーズには、この他に次のドキュメントが含まれています。
- Google Cloud のコネクテッド デバイス アーキテクチャの概要
- Google Cloud のスタンドアロン MQTT ブローカー アーキテクチャ
- Google Cloud の IoT プラットフォーム プロダクト アーキテクチャ
- Google Cloud で IoT バックエンドを実行するためのベスト プラクティス（このドキュメント）
- Pub/Sub アーキテクチャ上のデバイスから Google Cloud への接続
- エッジとベアメタルのシステムとサーバーを自動的にプロビジョニングして構成するためのベスト プラクティス
- IoT Core から環境を移行する
このドキュメントでは、デバイスの認証情報をプロビジョニングして管理し、エッジデバイスの認証とアクセス制御を行い、IoT エッジデバイスが Google Cloud リソースにアクセスできるようにするためのベスト プラクティスについて説明します。
IoT アーキテクチャ
IoT アーキテクチャには、デバイスの認証情報のプロビジョニングと管理、エッジデバイスの認証とアクセス制御、エッジデバイスから Google Cloud リソースへのアクセスを可能にするサービスが含まれています。このドキュメントでは、MQTT ブローカーを使用する IoT バックエンド アーキテクチャと IoT プラットフォームを使用する IoT バックエンド アーキテクチャの 2 つの IoT バックエンド アーキテクチャについて説明します。これらの 2 つのバックエンドの主なセキュリティの違いは、デバイス ID とデバイス管理です。IoT プラットフォームはシステムの一部としてこれらの機能を提供しますが、MQTT ブローカーではこれらの機能を提供する必要があります。
次の図は、IoT アーキテクチャを示しています。
このアーキテクチャは、次の 3 つのプロセスに必要なサービスを示しています。
証明書のプロビジョニング。これは、構成のためにエッジデバイスを準備するために完了する必要があるプロセスです。
認証と認可。これには、エッジデバイスと MQTT ブローカーまたは IoT プラットフォームが相互に認証するのに使用する認証スキームが含まれます。
エッジデバイスと Google Cloud サービス間の接続。これは、エッジデバイスがクラウド リソースに接続してデータをアップロードまたはダウンロードするために完了するタスクです。
このドキュメントでは、プロビジョニングと認証のセキュリティに関するベスト プラクティスについて主に焦点をあてます。
このアーキテクチャでは、次のサービスと機能を組み合わせて使用します。
- 環境のエッジにデプロイし、処理するデータに地理的に近いエッジデバイス（医療機器など）。エッジデバイスは IoT バックエンドと双方向に接続します。つまり、それらは IoT バックエンドとの間でメッセージを送受信できます。
- MQTT ブローカーまたは IoT プラットフォームでありうる IoT バックエンド。
- MQTT ブローカーは、MQTT プロトコルを使用して接続するための安全なインターフェースをエッジデバイスに提供します。MQTT ブローカーには、デバイス ID とデバイス管理の機能がなく、外部システムに依存してそれらを提供します。
- IoT プラットフォームは、エッジデバイスが接続して通信するクラウド アプリケーションです。IoT プラットフォームは、エッジデバイスが MQTT プロトコルを使用して接続するための安全なインターフェースを提供します。各 IoT プラットフォームには、それがエッジデバイスを認証、認可する方法と、デバイス ID を管理する方法を決定する独自のセキュリティ実装があります。
- すべてのエッジデバイス用の証明書をホストする中央の証明書ストア。
- エッジデバイスがアクセスする必要があるクラウド リソース。
エッジデバイスのプロビジョニング
Edge デバイスがバックエンド ワークロードに接続できるようにするには、エッジデバイスの証明書を事前にプロビジョニングする必要があります。証明書をプロビジョニングする方法を決定する主なシナリオは 2 つあります。
ソリューションが商用の汎用デバイスに基づいている場合は、デバイスの購入後に、プロビジョニング プロセスを完全に制御できます。
カスタムビルドされたデバイスを使用する場合、初期プロビジョニング プロセスはデバイスの製造中に行われるので、プロビジョニング プロセスをベンダーとメーカーと統合する必要があります。
いずれのシナリオでも、ルート認証局（CA）にリンクする信頼チェーンでデバイス証明書を作成する必要があります。これらの証明書は、デバイス ID を認証し、デバイスで行われる更新と変更が信頼できる操作者によることを確認するのに役立ちます。Certificate Authority Service などの CA を使用して、次のタスクを行います。
- 安全な方法でルート CA 証明書を生成して保存します。
- 必要に応じて、デバイス証明書に署名するための下位 CA 証明書を生成して保存します。
- デバイス証明書をリクエストします。
- 下位 CA に対する権限を構成してベンダーやメーカーに配布します。
- デバイス証明書がもう必要ではなくなった、またはデバイスの不正使用が疑われる場合は、デバイス証明書を取り消します。
デバイス証明書をプロビジョニングするには、次のタスクを実行する必要があります。
セキュア エレメント（SE）やハードウェア セキュア モジュール（HSM）などのデバイスによってサポートされているハードウェア ベースのセキュリティ ソリューションを使用して、公開鍵 / 秘密鍵ペアを作成します。設計上、SE または HSM は秘密鍵をローカルに保存し、秘密鍵は外部に公開されることは決してありません。公開鍵 / 秘密鍵ペアの生成にハードウェア ベースのセキュリティ ソリューションを使用していない場合は、代わりに CA を使用して鍵を生成します。詳細については、自動生成されたキーの使用をご覧ください。
署名してデバイス証明書を生成します。公開鍵 / 秘密鍵ペアを生成した後、公開鍵をダウンロードして、証明書署名リクエスト（CSR）を作成し、CSR を署名のために CA に送信します。CA は、ルート CA にリンクされたデバイス証明書を生成します。詳細については、CSR の使用をご覧ください。自動生成された鍵の使用の際は、デバイス証明書を CA から直接リクエストできます。
署名付きデバイス証明書をエッジデバイスにインストールし、その証明書を Secret Manager などの中央の証明書リポジトリに送信します。
詳細については、Google Cloud CA Service を使用して安全で信頼性の高い公開鍵基盤をデプロイする方法（PDF）をご覧ください。
その他のプロビジョニングのベスト プラクティスについては、エッジシステムとベアメタルのシステムとサーバーを自動的にプロビジョニングして構成するためのベスト プラクティスをご覧ください。
次の 3 種類の証明書が IoT ソリューションを保護するために使用されます。
ルート CA 証明書は、システム内の他のすべての証明書の信頼チェーンのルートを提供します。バックエンド ワークロードはルート証明書を使用してクライアント証明書を検証し、エッジデバイスはルート証明書を使用してサーバー証明書を検証します。ルート証明書を両方の IoT バックエンドとエッジデバイスに配布する必要があります。
サーバー証明書は、IoT バックエンドによって公開されるエンドポイントを保護するために使用されます。エンドポイントがサポートする必要がある異なる暗号化アルゴリズムのサーバー証明書があります。サーバー証明書はルート CA にリンクされます。Secret Manager は、サーバー証明書の非公開部分と公開部分の両方を管理し、保存します。IoT バックエンドをサーバー証明書で構成し、次に対応する秘密鍵で構成する必要があります。
クライアント証明書はエッジデバイスを特定するのに使用されます。各エッジデバイスには少なくとも 1 つのクライアント証明書があります。つまり、環境内のエッジデバイスの数とともに、保有する証明書の数が増加します。クライアント証明書はルート CA にリンクされます。クライアント証明書をエッジデバイスと IoT バックエンドに配布する必要があります。
HSM または SE を使用したデバイス証明書の生成のプロセス
次の図は、HSM または SE を使用する場合にデバイス証明書をプロビジョニングする方法を示しています。
この図では、次の手順が実行されます。
- エッジデバイスは、ハードウェア内で公開鍵ペアを生成します。
- 公開鍵をダウンロードして、その証明書署名リクエスト（CSR）を作成します。
- CSR を CA に送信して証明書をリクエストします。
- CA は次のアクションを完了します。
- 証明書に署名します。
- プロビジョナーにデバイス証明書を返します。
- プロビジョナーは次のアクションを完了します。
- エッジデバイスに証明書を送信します。
- 証明書を中央の証明書ストアに保存します。
- エッジデバイスが証明書を安全なロケーションに保存します。
CA を使用したデバイス証明書の生成のプロセス
次の図は、CA を使用する場合にデバイス証明書をプロビジョニングする方法を示しています。
この図では、次の手順が実行されます。
- CSR を生成し、それを CA に送信して証明書をリクエストします。
- CA は次のアクションを完了します。
- 公開鍵ペアを生成し、公開鍵に署名します。
- プロビジョナーにデバイス証明書と秘密鍵を返します。
- 次のアクションを完了してください。
- 証明書と秘密鍵をエッジデバイスに送信します。
- 証明書と秘密鍵を中央の証明書ストアに保存します。
- エッジデバイスが証明書を安全なロケーションに保存します。
デバイス ID についてのベスト プラクティス
このセクションでは、デバイス ID についてのベスト プラクティスについて説明します。
MQTT ブローカーと ID プロバイダを使用する
MQTT ブローカーは、プラグイン、データベース、ファイルが提供するデバイス認証情報を使用してエッジデバイスを認証します。デバイス ID を体系的かつスケーラブルな方法で管理するには、ID プロバイダ（IdP）を使用します。IdP はすべてのデバイスの ID と認証情報を管理し、デバイス ID についての主要な信頼できる情報源として機能します。
MQTT ブローカーでデバイス ID を更新された状態に保つには、システム固有の統合レイヤを実装します。デバイスの認証情報の管理の詳細については、エッジデバイスのプロビジョニングをご覧ください。
IoT プラットフォームのデジタル ID を信頼できる情報源として使用する
IoT プラットフォームには、デバイス ID とデバイス認証情報を管理し、プラットフォームにアクセスしようとするデバイスを認証、認可するセキュリティ機能があります。これらのセキュリティ機能により、認可されたデバイスのみが IoT プラットフォームにアクセスできるようになり、データの整合性が確保できるようになります。
IoT プラットフォームが管理するデバイス ID が、IoT プラットフォームが管理するすべてのデバイスの主要な信頼できる情報源を表していることを確認します。IoT ソリューションで、デバイスの ID 情報を必要とする他のコンポーネントは、IoT プラットフォームのセキュリティ システムに依存する必要があります。IoT プラットフォームはデバイスにアクセス権を付与し、セキュリティの変更を IoT ソリューション全体に伝播します。
ネットワーク接続についてのベスト プラクティス
ネットワーク接続の保護は、次の理由で重要です。
- 安全なネットワークによって、デバイスを適切なバックエンドに確実に接続できるようになります。たとえば、安全なネットワークによって、DNS なりすましを防止できます。これは、デバイスを転用して、攻撃者に制御される不正なバックエンドに接続しようとする攻撃です。
- 安全なネットワークによって、第三者がデータ トラフィックを絶対に読み取ることができないようにします。たとえば、安全なネットワークでは、攻撃者がデバイスとバックエンドの間のトラフィックを読み取る中間攻撃者の攻撃を防ぐことができます。
Transport Layer Security（TLS）を使用して、エッジデバイスとバックエンド ワークロード間のネットワーク通信を保護します。
mTLS で TLS を拡張して、両方の接続者が相互に ID を確立できるようにする相互認証スキームを実装します。
TLS の使用手順については、Google Cloud 上のスタンドアロン MQTT ブローカー アーキテクチャと Google Cloud 上の IoT プラットフォーム プロダクト アーキテクチャをご覧ください。
MQTT ブローカーの証明書管理についてのベスト プラクティス
このセクションでは、MQTT ブローカーの使用時に証明書を管理するためのベスト プラクティスについて説明します。
証明書を一元的に保存する
サーバー証明書とデバイス証明書を中央のロケーションに保存、管理します。具体的には、次のコントロールが確実に適正にあるようにします。
- すべてのデバイスとそれらの証明書、およびサーバー エンドポイントとそれらの証明書のインベントリ。
- 証明書の有効性など、証明書についての追加情報。
- デバイスに対して証明書の追加と削除を行い、新しい証明書を使用してデバイスが接続できるようにする能力。
- バックエンドの異なるロールが証明書でできることを制限する、中央の証明書ストアへのアクセス権。
Secret Manager や HashiCorp Vault などのシークレット ストレージと管理ソリューションを使用します。Secret Manager によって、デバイス認証情報のバージョニング、更新、無効化と、認証情報へのアクセス ポリシーの管理ができます。
IoT プラットフォームの場合は、Secret Manager API アクセスを使用して認証情報へのアクセスを実装します。
エッジデバイスの証明書を保護する
証明書と鍵をエッジデバイスに保存するには、ローカルの高信頼実行環境または証明書ストアを使用して、認証情報を保護し、未認証のアクセスをブロックします。シークレット マテリアルをデバイスに保存する必要がある場合は、フラッシュ暗号化などの手法を使用してそのマテリアルを暗号化し、それを改ざん防止要素に保存し、未認証のデータ抽出を防止します。
中央証明書ストアを MQTT ブローカー証明書ストアと同期する
MQTT ブローカーは証明書ベースの認証用のクライアント証明書にアクセスする必要があるため、MQTT ブローカーの証明書ストアを中央証明書ストアと同期させる必要があります。証明書の追加、更新、削除など、中央証明書ストアに関する変更が MQTT ブローカーの証明書ストアと同期していることを確認します。MQTT ブローカーは、MySQL、PostgresDB、Java キーストアなどの証明書ストアを使用します。MQTT ブローカーが使用するのがどの証明書ストアかに応じて、次のプロセスが存在することを確認してください。
- 中央の証明書ストアの変更をモニタリングし、同期プロセスを通知するプロセス。
- 中央証明書ストアで変更を行い、中央証明書ストアの変更を MQTT ブローカーが使用する証明書ストアと同期させるプロセス。
Secret Manager を証明書ストアとして使用する場合は、モニタリング プロセスとしてイベント通知を使用できます。同期プロセスは、イベント通知のリスナーとして実装できます。
エッジデバイスに証明書を安全に配布する
MQTT ブローカーの使用時は、ルート証明書とクライアント証明書をエッジデバイスに配布します。証明書を配布する際は、通信チャネルを保護してトラフィックが傍受されないようにする必要があります。
証明書の配布用の主な通信チャネルは次のとおりです。
- 既存の通信チャネル上の IoT バックエンドからエッジデバイスへの直接パス。
- エッジデバイスで証明書をリクエストしてダウンロードする間接パス。
証明書の配布中に、次のコンポーネントが必要です。
- 証明書を一元管理する証明書ストア。
- 配布コーディネーター。証明書を送信し、各エッジデバイスの配布プロセスを追跡します。
- 証明書を受信またはダウンロードしてから、それらをデバイスに保存するエッジデバイス上の更新ハンドラ。
エッジデバイスのプロビジョニング プロセス中、および証明書をローテーションする必要がある場合に、証明書を配布します。
プロビジョニング プロセス中に、プロビジョナーは、SSH などの暗号化されたチャネル上でエッジデバイスに直接アクセスでき、SCP などのツールを使用することを確認します。デバイスが稼働していないため、エッジデバイスに証明書を直接 push できます。
証明書のローテーション時は、MQTT ブローカーを配布コーディネーターとエッジデバイスの間の通信チャネルとして使用します。他のチャネルを使用して、デバイスに証明書をダウンロードします。動作中のエッジデバイスの中断を最小限にするには、間接的な証明書配布パスを使用します。プロセスは以下の論理ステップで構成されます。
- ディストリビューション コーディネーターは証明書ストアからアクセス認証情報を取得します。
- ディストリビューション コーディネーターは、ダウンロード URL などの追加情報とともに証明書アクセス認証情報をエッジデバイスに push します。
- デバイス上の更新ハンドラは、アクセス認証情報を受信して一時的に情報を保存し、受信の戻り応答を確認します。
- 更新ハンドラは、デバイスがアクティブでない場合に証明書のダウンロードを調整します。更新ハンドラは、アクセス認証情報を使用して、認証情報ストアから証明書をダウンロードします。
- 証明書をダウンロードした後、更新ハンドラは証明書のローテーション プロセスを続行します。これは、証明書のローテーションのセクションで説明されています。
Secret Manager を中央証明書ストアとして使用する際は、有効期間の短いアクセス トークンを生成して、証明書へのアクセス権を付与または制限できます。詳細については、アクセス トークンをデバイスに安全に配布するをご覧ください。
証明書が転送中に漏洩しないようにするには、エッジデバイスと MQTT ブローカーの間の接続を暗号化します。詳しくは、ネットワーク接続のためのベスト プラクティスをご覧ください。
証明書の自動ローテーション
漏洩した証明書に起因する可能性がある損害を限定するには、有限の有効期間の証明書を生成し、証明書が期限切れになる前にローテーションします。大規模な IoT デプロイの場合、証明書の自動ローテーション手順を実装して、古い証明書が期限切れになる前にデバイスを新しい証明書で一貫して更新します。有効な証明書なしでデバイスをデプロイするということは、デバイスが機能しなくなるため、修正にコストがかかり、IoT ソリューションの機能全体に悪影響が及ぶ可能性があるということです。
エッジデバイスが MQTT ブローカーと双方向で接続して、MQTT ブローカーにメッセージを送信し、MQTT ブローカーからメッセージを受信できるようにする必要があります。
証明書のローテーション中に、次のコンポーネントが必要です。
- モニタリング プロセス。証明書インベントリを繰り返しスキャンし、有効期限が近づいている証明書を探します。モニタリング プロセスによって、期限切れする証明書に対して証明書のローテーションがトリガーされます。
- 証明書のローテーションを初期化して監視するローテーション プロセス。
- MQTT ブローカーと通信し、デバイス上で証明書ローテーション手順を実行する、エッジデバイス上のデバイス認証ローテーション ハンドラ。
証明書をローテーションするには、IoT ソリューションで次の手順を完了します。
- ローテーション プロセスは、初期化メッセージをエッジデバイスに送信し、証明書のローテーションを開始します。
- デバイス証明書のローテーション ハンドラは、ローテーション ジョブに戻すレスポンスを送信することで、初期化メッセージを応答確認します。
- ローテーション プロセスが、CA からの新しい証明書をリクエストします。リクエストは、鍵と CSR が MQTT ブローカー メッセージとして送信されることを除き、証明書のプロビジョニング リクエストと似ています。
- CA からの新しい証明書の受信後、ローテーション ジョブは証明書を中央証明書ストアとエッジデバイスに配布します。また、証明書を MQTT ブローカーの証明書ストアに同期します。
- デバイス証明書のローテーション ハンドラは、新しい証明書を保存し、新しい証明書を使用して MQTT ブローカーとの新しい接続を初期化します。
- 新しい接続が確立された後で、デバイス証明書のローテーション ハンドラは、完了したメッセージを MQTT ブローカーに送信します。
- 完了したメッセージの受信後に、ローテーション プロセスは、中央の証明書ストア内の古い証明書を無効化します。
ローテーション プロセス中に送信される証明書を保護できるようにするには、証明書のローテーション専用の MQTT トピックを使用します。これらのトピックへのアクセスを、ローテーション ジョブとエッジデバイスのみに制限します。
証明書のローテーション プロセスをランタイム エラーから保護できるようにするには、変更と進行状況の永続性を有効にします。
Secret Manager を使用したシークレットのローテーションの詳細については、シークレットのローテーションをご覧ください。
IoT プラットフォームの証明書管理についてのベスト プラクティス
IoT プラットフォームを使用している場合は、プラットフォームが提供する証明書の更新と配布メカニズムを使用します。バックアップを目的として、認証情報を IoT プラットフォームから Secret Manager などのセカンダリ シークレット ストレージに定期的にエクスポートできます。
MQTT ブローカーを使用した認証についてのベスト プラクティス
相互認証プロセス中に、バックエンド ワークロードはエッジデバイスの ID を検証し、エッジデバイスはバックエンド ワークロードの ID を検証します。バックエンド ワークロードがエッジデバイスの ID を確認した後、バックエンド ワークロードはリソースへのデバイス アクセスを承認します。
以下のセクションでは、MQTT ブローカーの使用時の認証方法についてのベスト プラクティスについて説明します。
MQTT ブローカーに対する認証方法を選択する
異なる IoT バックエンドが異なる認証方法をサポートしています。一般的に使用される方法は次のとおりです。
- ユーザー名とパスワードの認証。ここで、エッジデバイスは、その ID の検証のためのユーザー名とパスワードを示します。
- トークンベースの認証。ここで、暗号化されたセキュリティ トークンを使用して Edge デバイスの ID を検証します。
- カスタマイズされた認証スキーム。ここで、エッジデバイスの ID を検証するカスタム メカニズムを実装します。
MQTT 標準の一部として、MQTT ブローカーは、MQTT CONNECT パケットのデフォルトとしてユーザー名とパスワード認証をサポートしています。
MQTT CONNECT パケットにはまた、MQTT ブローカーへのクライアントを一意に識別するために使用できる Client Identifier フィールドも含まれています。エッジデバイスは、接続を確立する際に MQTT CONNECT パケットを MQTT ブローカーに送信します。
MQTT
CONNECT パケットのユーザー名、パスワード、クライアント ID フィールド以外に、MQTT 5.0 では、チャレンジ / レスポンス認証フローの構築を可能にする強化された認証をサポートしています。MQTT 5.0 によって、エッジデバイスと MQTT ブローカーの間で複数の AUTH パケット交換ができます。
ユーザー名とパスワードの認証を使用するパスワード ストアを使用する
ユーザー名とパスワードの認証の場合は、パスワード ストアを使用するように MQTT ブローカーを構成します。パスワード ストアは、MQTT ブローカーに接続するすべてのエッジデバイスのパスワードを管理するための一元化ロケーションを提供します。デフォルトでは、ユーザー名、パスワード、クライアント識別子フィールドは MQTT 仕様では省略可能です。そのため、ユーザー名、パスワード、クライアント識別子フィールドが MQTT
CONNECT パケットに存在することを検証するように認証メカニズムを設計します。
次のように、保存時も転送時もパスワードが暗号化されるようにします。
保存時に、復元できない、パスワードの暗号化された強力なハッシュを保存します。ハッシュ化パスワードについて詳しくは、アカウント認証とパスワード管理のベスト プラクティスをご覧ください。
転送時に、エッジデバイスと MQTT ブローカーの間の接続を暗号化します。詳しくは、ネットワーク接続のためのベスト プラクティスをご覧ください。
トークンベースの認証を検討する
トークンベースの認証では、エッジデバイスは認証のためにトークンを MQTT ブローカーに送信します。デバイスは、トークンを自分で生成することも、他の認証サービスからトークンを取得することもできます。パスワードと比べて、トークンは有効期間が短いです。トークンは、明示的な有効期限がある期間のみ有効です。トークンの検証時は、有効期限を常に確認してください。
JSON Web Token（JWT）は、トークンベースの認証を実装する方法です。エッジデバイスは、JWT を生成し、MQTT ブローカーで認証できます。JWT は、パスワード フィールドとして MQTT CONNECT パケットに埋め込まれます。
JWT の利点は次のとおりです。
- JWT では、トークンの署名に使用される暗号化アルゴリズムを選択できます。JWT は制約のあるエッジデバイスで適切に機能します。ここで、トークンの署名に ECC などのあまりリソース集中的ではない暗号化アルゴリズムを使用できます。
- 公開鍵暗号を使用すると、秘密鍵はエッジデバイスでのみ使用され、第三者とは決して共有されません。秘密鍵を使用すると、この方法は、認証情報が接続上を送信され、データの暗号化が必要なユーザー名とパスワードの認証よりも安全になります。
カスタム認証スキームを検討する
一部の MQTT ブローカーは、異なる認証のメカニズムとプロトコルをサポートしています。たとえば、MQTT ブローカーがカスタマイズされた認証スキームをサポートしている場合は、次のものをサポートするようにそれを構成できます。
- 業界標準の認証プロトコル。OpenID Connect、Security Assertion Markup Language（SAML）、LDAP、Kerberos、Simple Authentication and Security Layer（SASL）、など。これらのプロトコルは、デバイスの認証を既存の ID プロバイダに委任します。一部の MQTT ブローカーは、新しいプロトコルと ID プロバイダをサポートするように MQTT ブローカーを拡張するために使用できる、強化認証と拡張認証のメカニズムをサポートしています。
- 証明書ベースの相互認証。一部の MQTT ブローカーは、mTLS ベースの認証などの相互認証スキームをサポートしています。
デバイスのアクセス制御と認可についてのベスト プラクティス
MQTT プロトコルのパブリッシャーとサブスクライバーの通信パターンにより、デバイスのアクセス制御は MQTT トピックを使用して定義されます。MQTT トピックは、デバイスが IoT バックエンドと通信できる方法を制御します。それぞれの IoT バックエンドのアクセス制御と承認についての実装は異なるため、MQTT トピックの設定方法のオプションについては、IoT バックエンドのドキュメントをご覧ください。
単一目的のサービス アカウントを使用して Google Cloud リソースにアクセスする
Google Cloud リソースへのアクセスは、リソース アクセスの加減を一連のプリンシパルにバインドする IAM 許可ポリシーによって管理されます。典型的なプリンシパルは、ユーザー アカウント、サービス アカウント、グループです。サービス アカウントは通常、アプリケーションまたはコンピューティング ワークロードによって、クラウド リソースに対する承認済みの API 呼び出しを行うために使用されます。サービス アカウントによって、IoT エッジデバイスがクラウド リソースにアクセスできるようになります。
デバイス ID は IoT バックエンドによって管理されるため、エッジデバイスが Google Cloud リソースにアクセスできるように、IoT バックエンドと IAM の間で ID をマッピングする必要があります。
大規模なデバイスの一群を管理している場合、各 Google Cloud プロジェクトのサービス アカウントの数の上限によって、デバイスとサービス アカウントの間の直接の 1 対 1 のマッピングは実現できなくなります。
代わりに、単一目的のサービス アカウントの作成の説明に従って、IoT ソリューションがアクセスする必要があるクラウド リソースにリンクされたサービス アカウントを作成します。たとえば、次のユースケースのそれぞれに対して一意のサービス アカウントを作成します。
- ソフトウェア更新パッケージのダウンロード
- サイズの大きいメディア ファイルのアップロード
- レイテンシ ストリームからのデータの取り込み
最小権限を実装するには、各サービス アカウントがユースケースをサポートするのに十分なアクセス権のみ持っているようにします。たとえば、ソフトウェア パッケージのダウンロードに使用されるサービス アカウントの場合は、Cloud Storage バケットへの読み取りアクセス権のみ付与します。
アクセス トークンをデバイスに安全に配布する
通常、エッジデバイスは MQTT を使用して IoT プラットフォームと通信します。ただし、特定のユースケースの場合、デバイスで Google Cloud リソースへの直接アクセスが必要になる場合があります。たとえば、次の点を考えます。
- コンテンツをダウンロードするには、エッジデバイスにダウンロード プロセスでのみ Cloud Storage バケットに対する読み取り専用アクセス権が必要です。
- Cloud Storage バケットにデータをアップロードするには、エッジデバイスにバケットへの書き込みアクセス権が必要です。
これらのユースケースの場合は、Workload Identity 連携を使用します。ここで、Google Cloud リソースへのアクセスは、アクセス トークンを介して付与されます。Workload Identity 連携によって、クラウド固有の認証情報をエッジデバイス上でプロビジョニングする必要がなくなり、アクセス権の配布がオンデマンドで動的に行われます。
クラウド リソース用のアクセス トークンをデバイスに配布するには、デバイス ID プロバイダと Google Cloud の間で Workload Identity 連携を構成します。Workload Identity 連携をサポートするには、IoT バックエンドが Workload Identity 連携の要件を満たし、ユースケースに一致するセキュリティのベスト プラクティスに従っていることを確認します。
Workload Identity 連携を使用して Google Cloud リソースにアクセスするには、エッジデバイスで次の手順を伴う OAuth 2.0 トークン交換ワークフローを実装する必要があります。
- デバイスがセキュリティ トークン サービスを呼び出し、独自のデバイス認証情報を提供します。
- Security Token Service は、エッジデバイスがデバイス ID プロバイダと提供した認証情報を検証して、エッジデバイスの ID を検証します。
- ID の検証に成功すると、Security Token Service は連携トークンをエッジデバイスに返します。
- エッジデバイスが連携トークンを使用して、単一目的のサービス アカウントの権限を借用し、有効期間の短い OAuth 2.0 アクセス トークンを取得します。
- デバイスは、有効期間の短い OAuth 2.0 アクセス トークンを使用して Google Cloud APIs で認証し、必要なクラウド リソースへのアクセス権を取得します。
有効期間の短いアクセス トークンによる Cloud Storage の特定のバケットとオブジェクトへのアクセスを制限するには、認証情報アクセス境界を使用します。認証情報アクセス境界によって、有効期間が短い認証情報のアクセスを制限し、アクセス トークンが不正使用された際に Cloud Storage バケットで漏洩するリソースの数を最小限にできます。
Workload Identity 連携は、クラウド アクセスをエッジデバイスに安全に配布するスケーラブルな方法です。認証の詳細については、Google での認証をご覧ください。
クラウド リソースへのアクセスをモニタリングして監査する
Cloud Audit Logs を有効にして、エッジデバイスが認証された API リクエストを通じてクラウド リソースにアクセスする際にログエントリを作成するようにします。Cloud Audit Logs によって、Google Cloud 上のエッジデバイスによって行われる重要なアクションをモニタリングできます。さらに、Cloud Audit Logs は、問題を調査する必要がある監査のトレースとログを作成します。詳しくは、Google Cloud にアクセスするサービス アカウントの権限の借用をご覧ください。
次のステップ
- モノのインターネットの技術的概要について学習する。
シリーズの残りのドキュメントを確認する。