IoTセキュリティの基礎（第5部）：IoTクラウドサービスへのセキュアな接続

編集者注：IoTデバイスはその急増にもかかわらず、セキュリティ面の懸念が払拭されておらず、産業用IoT（IIoT）やミッションクリティカルなアプリケーションでは、攻撃された場合に企業や個人のデータが被害を受ける可能性あり、セキュリティの課題がコネクテッドデバイス導入の障壁になる場合もあります。IoTアプリケーションのセキュリティ確保は難しいと考えられがちですが、実際には、IoTデバイスのセキュリティは、ハードウェアセキュリティデバイスによって支えられる、さほど複雑でない基本的な仕組みをいくつか組み合わせれば構築できます。すでに確立されたセキュリティ手法に従うことで、これらの懸念を払拭することができます。5回に分けてお届けするこのシリーズでは、開発者が最初からベストプラクティスを実践するのに役立つ実際的なガイダンスを提供します。第1部では、安全設計の基盤となる暗号アルゴリズムについて説明します。第2部では、セキュアIoT設計における秘密鍵の役割、鍵管理、およびセキュアストレージについて説明します。第3部では、IoTデバイスへの他の種類の脅威を軽減するためにセキュアプロセッサに組み込まれたメカニズムについて説明します。第4部では、高度なプロセッサでセキュリティメカニズムを適用して、IoTデバイスのランタイム環境に対する攻撃を軽減するのに必要な隔離を確保する方法を特定して紹介します。そしてこの第5部では、IoTデバイスから、そのデバイスをIoTクラウドリソースに接続するためのハイレベルなセキュリティ対策へと続くIoTセキュリティについて説明します。

モノのインターネット（IoT）のセキュリティは、IoTデバイスのハードウェア基盤からデバイスの実行環境にまで及ぶ、複数の保護レイヤに依存しています。しかし、あらゆるコネクテッドデバイスは脅威から逃れられず、クラウドコネクティビティに求められる標準的なIoTアプリケーション要件によって、IoTデバイスとクラウドサービスの両方が新たな攻撃に対して無防備にもなり得ます。このような脅威を軽減するため、IoTクラウドプロバイダは特定のセキュリティプロトコルとポリシーを使用しますが、それらを正しく運用しないとIoTアプリケーションが脆弱になりかねません。開発者は、構成済みの開発ボードを活用することで、主要なIoTクラウドサービスで利用されている接続の認証やIoTデバイス/クラウドリソース使用の承認などのセキュリティ手法に関するノウハウをすばやく獲得できます。

この記事では、2つの大手クラウドサービス、Amazon Web Services（AWS）とMicrosoft Azureの接続要件について説明し、開発者がさまざまなベンダーから提供される開発キットや付随するソフトウェアを使用してこれらのサービスにすばやく接続する方法を示します。

クラウドサービスにおけるIoTポータルの役割

IoTデバイスがクラウドサービスやリモートホストなどのリソースに接続すると、IoTデバイス自体、およびその延長としてIoTネットワーク全体が、正規のサービスやサーバーを装う脅威に晒されるおそれがあります。逆にクラウドサービス側でも同様に、IoTデバイスのトランザクションを真似てクラウド防御を突破しようとするハッカーからの攻撃という脅威に直面します。IoTデバイスとクラウドリソースの両方を確実に保護するため、クラウドサービスでは、サインイン時にID相互認証を行い、認証後に許可に基づいてサービスを利用できるように、特定のセキュリティプロトコルを使用する必要があります。一般的にこれらのプロトコルは、IoTデバイスとクラウドリソースの間でセキュアポータルを可能にする一連のサービスに含まれています。

現在提供されている他のIoTクラウドサービスプラットフォームと同様に、AWSとAzureにはそれぞれが提供する独自のエントリーポータルがあり、IoTデバイスはそのポータルを使って、それぞれのプロバイダが提供する仮想マシン（VM）やSaaS（サービスとしてのソフトウェア）などフルセットのクラウドリソースを対話的に利用する必要があります。Azure IoT HubとAWS IoTは、機能的に同様の各種メカニズム/機能を使用して、このポータルを各自のエンタープライズクラウドサービス用に提供しています。

これらを含むさまざまなIoTポータルでは、少なくとも、各プロバイダのソフトウェア開発キット（SDK）により実装された固有の認証プロトコルを利用することで、セキュアな接続を実現しています。AWSの場合、IoTデバイスは相互認証を使用してデバイスゲートウェイに接続します。デバイスゲートウェイは、AWSサービスへのアクセスの管理に必要な一意のデバイスID、セキュリティ認証情報、その他のメタデータを格納するデバイスレジストリに保持されている情報を使用して、IoTデバイスを他のIoTサポートサービスに接続します（図1）。Azureでは、IDレジストリに同様の機能があります。

図1：他のクラウドプロバイダと同様に、AWSは一連の専用サービスを開発者に提供しており、それらはIoTデバイスとエンタープライズクラウドサービスの間でトランザクションのセキュリティと実効性を強化するように設計されています。（画像提供：Amazon Web Services）

AWS IoTとAzure IoTのいずれも、物理IoTデバイスごとに関連付けられた仮想デバイスの状態情報を維持するサービスを提供します。AWS IoTでは、デバイスシャドウがこの機能を備えており、Azure IoTではデバイスツインが同様の機能を備えています。

このセキュリティポータルの概念は、AWS GreengrassやAzure IoT EdgeなどのIoTエッジサービスにまで及びます。これらのエッジサービスは、大規模な展開でエッジシステムが物理的にIoTデバイス/システムの近くに配置されているローカルネットワークに対し、クラウドサービスおよびクラウド機能をもたらします。開発者は、Azure IoT Edgeなどのサービスを使用して、アプリケーションビジネスロジックを実装したり、遅延の削減に必要な他の機能を提供したり、産業用オートメーションなどのサービスをローカルオペレータに提供したりできます（図2）。

図2：エッジコンピューティングをサポートするために、クラウドサービスプロバイダはMicrosoft Azure IoT Edgeなどの専用サービスを提供しています。Azure IoT Edgeの場合、一部のAzure IoTクラウドサービスとIoTアプリケーションに関連付けられた物理デバイスとの結びつきを強化します。（画像提供：Microsoft Azure）

IoTポータルのコネクティビティ要件への対応

プロバイダのIoTサービスへのエッジシステムを経由した接続でも直接的な接続でも、IoTデバイスでは一般的に、プロバイダのIoTポータルを経由して接続しプロバイダのクラウドサービスを使用するために、一連の要件を満たす必要があります。細かい点は異なるものの、IoTデバイスは少なくとも、秘密鍵、X.509証明書、または他のセキュリティトークンなどのアイテムを提供する必要があります。鍵、証明書、またはトークンにより、デバイス-クラウド間の接続シーケンスの認証段階で、IoTデバイスIDの証明または構成証明（attestation）がIoTポータルに提供されます。さらに、IoTクラウドサービスでは一般的に、IoTデバイスとクラウドサービス間での対話に必要なアクセス権の定義に使用されるポリシー仕様が必要になります。

他のエンタープライズコンピューティング要件と同様に、認証の構成証明（attestation）情報とアクセス管理の方針に関する情報は、AWS IoTやAzure IoTなどの主要IoTクラウドサービスで指定される特定の形式と手順で提供される必要があります。これらのクラウドサービスでは、少なくとも証明書ベースの認証がサポートされますが、他の構成証明形式の使用もサポートされます。たとえば開発者は、AWS IoTのJSON Web Token（JWT）またはAzure IoTのShared Access Signature (SAS)トークンに基づく、トークンベースの認証方法を使用できます。

前述のように、これらのクラウドサービスではレジストリの使用により各IoTデバイスのメタデータを保持します。このレジストリには、セキュリティなどの情報とともに、IoTデバイスの接続用に必ず定義されるアクセス権ポリシーが格納されます。これらの方針の定義は、各種のクラウドサービスに応じてさまざまな方法で指定されますが、異なる通信チャンネルおよびエンティティのアクセス権を規定します。たとえば、シンプルなAWS IoTアクセス権に関する方針では、JSON形式を使用することで、「AWS IoTデバイスレジストリ内に特定の「モノ」の名前が含まれているIoTデバイスは、関連する同じモノの名前を持つチャンネルでのみ接続を行いメッセージを公開できる」ことを示すこともできます（リスト1）。

コピー
{
    "Version": "2012-10-17",
    "Statement": [
      {
        "Effect": "Allow",
        "Action":["iot:Publish"],
        "Resource": ["arn:aws:iot:us-east-1:123456789012:topic/${iot:Connection.Thing.ThingName}"]
      },
      {
        "Effect": "Allow",
        "Action": ["iot:Connect"],
        "Resource": ["arn:aws:iot:us-east-1:123456789012:client/${iot:Connection.Thing.ThingName}"]
      }
    ]
}

リスト1：開発者はJSON形式を使用して、各自のIoTデバイス用にAWS IoTアクセス権ポリシーを記述できます。（コード提供：AWS）

クラウド対応の開発キット

クラウドプロバイダはこれらの形式と手順について詳細な仕様を規定していますが、プロバイダのサポートフォーラムには、細かい部分で認証やアクセス管理を妨げる重大な問題があることに悩む開発者から多くの質問が寄せられているのが実情です。おそらく、セキュリティの面でさらに深刻なのは、構成証明（attestation）の意図的でない誤用や、アクセスポリシーの不完全な定義により、IoTデバイス、ネットワーク、アプリケーションが攻撃に対して無防備なままになることです。開発者は、すぐに使える開発ボードおよび同梱のソフトウェアパッケージを利用することで、ベンダーが提供するサンプルを使用して所定の接続手順をすばやく実行し、IoTクラウドにすぐに接続できます。たとえば、Espressif SystemsのESP32-Azure IoTキットまたはSeeed TechnologyのAZ3166 IoT開発キットには、Microsoftのクラウドに簡単に接続できるAzure認定のボードが含まれています。

Microsoftは、サポート対象の開発キット向けに、認証やアクセス認証情報を含む完全なステップバイステップのデモを提供しています。たとえば、AZ3166ボードの場合、開発者はボードのボタンを押してローカルのWi-Fiネットワークとの接続を開始します。接続すると、MicrosoftのVisual Studio Code用Azure IoT Tools拡張パックに含まれているAzure IoT Device Workbenchを使用して、Azure IoT Hubの開発、デバッグ、対話的な操作を実行できます。このツールセットおよびサンプルコードパッケージを使用することで、開発者はAzure IoT HubでIoTデバイスのオブジェクトを作成し、付属のファイルを使用して、Azure IoT HubにIoTボードを接続する際に必要な認証情報および他のメタデータを、関連付けされたIDレジストリにプロビジョニングします（図3）。

図3：Microsoft Azure IoT Device Workbenchに入力されているサンプルコードおよび認証情報により、開発者はSeeed Technology AZ3166 IoT開発者キットをAzure IoT Hubに接続するためのプロビジョニングを実行できます。（画像提供：Microsoft Azure）

Azure IoT Device Workbenchに含まれるその他のサポートソフトウェアおよびメタデータにより、開発者はAZ3166ボードにサンプルコードをすばやくロードして、ボードの温湿度センサからAzure IoT Hubに測定値を送信できます。

IoTクラウドでの物理IoTデバイスの表現を作成する手順、および関連付けられたレジストリのプロビジョニングを行う手順は、単にデバイスをIoTクラウドに接続するために必要になります。しかしクラウドサービスを利用するには、Azure IoT Hubにアクセス権ポリシーが必要です。AZ3166のセンサから送信されるデバイスからクラウドへのメッセージを監視するために、開発者は、Azure共有アクセスポリシー画面を使用するだけで、構成済みのポリシーを選択して必要なアクセス権をすばやく有効にできます（図4）。

図4：開発者は構成済みのポリシーを使用して、AzureクラウドサービスをSeeed TechnologyのAZ3166 IoT開発キットから送られるセンサデータとともに使用することを容易に認証できます。（画像提供：Microsoft Azure）

AWS IoTを使用する場合、開発者はMicrochip TechnologyのAT88CKECC-AWS-XSTK-B Zero Touch Provisioningキットおよび付属ソフトウェアなどの開発キットを利用して、クラウドのコネクティビティをすばやく評価できます。以前のMicrochip Zero Touch Provisioningキットからの更新バージョンには、認証情報がプリロードされています。キットに付属するその他のスクリプトを使用することで、開発者は、秘密鍵と証明書を扱うことなく、ボードをAWS IoTにすぐに接続できます（「ゼロタッチアプローチを使用してIoTデバイスを安全にロックダウンする」を参照）。

たとえばRenesasのRTK5RX65N0S01000BE RX65NクラウドキットやInfineon TechnologiesのKITXMC48IOTAWSWIFITOBO1 AWS IoTキットなどの開発キットには、Amazon FreeRTOSに基づく迅速なアプリケーション開発のサポートにより、AWS IoTコネクティビティのサポートを拡張しているものもあります。AWSでは、ボードの登録、認証情報の作成、およびAWS IoTへの接続やAWSサービスの使用に必要な付属のJSONポリシーのロードに関して、詳細な指示が規定されています。

大規模なIoT展開におけるプロビジョニングの簡素化

上記のような開発キットは、IoTアプリケーションのラピッドプロトタイピングおよびIoTクラウドサービス接続要件の調査のどちらにも、効果的なプラットフォームとして有用です。しかし実際には、現実のアプリケーションにおいてIoTデバイスのプロビジョニングを簡素化するように考案された、より高度なアプローチに頼る必要があるのが一般的です。Azure IoTとAWS IoTのいずれも、個別デバイスのプロビジョニングまたは大規模な展開における多数のIoTデバイスのプロビジョニングの自動化を促進する、さまざまな方法をサポートしています。

たとえばAWS IoTでは、開発者は証明書のプロビジョニングにブートストラップ方式を使用できます。この場合、スマート製品の出荷時には、新たな証明書を請求してアクセスするために必要な最小限のアクセス権に関連付けられた、ブートストラップ証明書が付属します（図5）。

図5：AWS IoTは、IoTデバイスでブートストラップ証明書によるプロビジョニング方式をサポートします。（画像提供：DigiKey、Amazon Web Servicesによる）

ブートストラップ証明書を使用する場合、デバイスはクラウドに接続し（図5の「1」）、新たな証明書を要求し（「2」）、AWSサーバーレスLambda関数で生成された証明書のURLを受信し（「3」）、AWS Simple Storage Services（S3）バケットからその証明書を取得します（「4」）。その新しい証明書を使用して、デバイスはAWS IoTに再度ログインし（「5」）、通常の操作を続行します。

AWSが提供する他のクラウドサービスでは、AWS Lambda関数などの実行リソースを使用した認証トークンの動的プロビジョニングがサポートされます。たとえば車載用アプリケーションでは、トークンを使用することがより実用的で安全でもある、一時的な一連の接続に依存する場合があります。その場合、IoT認証および承認用のAWSモジュールがトークンの要求を認証すると、AWS Security Token Service（STS）が車両システムへの配信用のトークンを生成します。これらのシステムはそのトークンを使用して、AWS Identity and Access Management（IAM）サービスによる検証の対象となるAWSサービスにアクセスできます（図6）。

図6：主要クラウドサービスプロバイダは認証用の証明として他の形式もサポートしており、たとえばこのプロセスではAWS Security Token Service（STS）によりセキュリティトークンを動的に生成します。（画像提供：Amazon Web Services）

AWSには、アクセス権を動的に割り当てる同様の機能があります。この場合、他のAWS Lambda関数が、有効なトークンに関連付けられた一連のポリシーを割り当てます（図7）。

図7：開発者はクラウドサービスを使用して、アクセス権の動的割り当てを実装できます。これは一時的な接続または短期的な運用を行うアプリケーションで特に有用です。（画像提供：Amazon Web Services）

他のIoTクラウドサービスでは、開発者は大規模な展開でのプロビジョニングをさらに効率的に処理できます。たとえば、AWS IoTにはフリートプロビジョニング機能があり、前述のようなブートストラップ方式の大規模な展開のサポートなどが含まれます。Azure IoTのDevice Provisioning Serviceが提供するグループ登録機能では、同じX.509証明書またはSASトークンを共有する多数のIoTデバイスのプロビジョニングがサポートされます。

セキュリティに対する責任の共有

IoTクラウドプロバイダは、IoTアプリケーションでエンドツーエンドのセキュリティを強化するために、多くの効果的な方法を提供しています。それにもかかわらず、IoT開発者は、それらの手法が各自のIoTアプリケーションのセキュリティ要件を全面的に支えるとは期待できないのが実情です。実際に、クラウドサービスプロバイダは、AWSの共有責任モデル（図8）のような特定のモデルによって、IoTアプリケーションのセキュリティについて特定の役割と責任を注意深く規定しています。

図8：他の主要クラウドプロバイダと同様に、AWSはクラウドユーザーと共有する責任について規定しており、一方がクラウドインフラを保護して他方がカスタマーアプリケーションを保護する責任を負います。（画像提供：Amazon Web Services）

AWSとMicrosoft Azureは各自の共有責任に関するドキュメントを提供しており、リソース、データ、およびアプリケーションのセキュリティ保護に対するプロバイダの役割とカスタマーの役割に関する規定が説明されています。マイクロソフトはそのドキュメントで、共有セキュリティとコンプライアンス要件の関係についての概要も述べています。まとめると、クラウドプロバイダはクラウドのセキュリティ面で責任を持ち、カスタマーはクラウドで使用されるアプリケーション、データ、およびリソースに対して責任を負うのです。

まとめ

IoTアプリケーションは複数のセキュリティレイヤに依存しており、それらは暗号化および安全な鍵ストレージを可能にするハードウェアベースのメカニズムによって構成されます。あらゆるコネクテッド製品と同様に、クラウドサービスに接続されたIoTデバイスには、セキュリティへの脅威があらゆる攻撃方法によって波及するおそれがあります。IoTクラウドプロバイダは自身とカスタマーを保護するために、認証とアクセス権管理を行うための特定の要件を規定しています。プロバイダはこれらの要件および関連する仕様の細目を規定したドキュメントを提供していますが、開発者は、セキュアなコネクティビティの実装に努めるとかえってリソースが無防備になったり、リソースがアクセス不能になったりすることに気付く場合もあります。開発ボードおよび連携するソフトウェアを使用することで、開発者はクラウドサービスにすばやく接続し、エンドツーエンドのセキュリティを維持しながらIoTアプリケーションのラピッドプロトタイピングを実施できるのです。