大規模なIoTプロビジョニングの促進

新しいデバイスを設計する場合でも、既存のデバイスをIoTに後付けする場合でも、IoTデバイスをクラウドサービスにオンラインで提供するIoTプロビジョニングを検討する必要があります。 IoTプロビジョニングの設計では、デバイスがクラウドに安全に接続できるように、デジタルID、クラウドエンドポイント、およびネットワーク資格情報を構成するネットワークコミッショニングと資格情報プロビジョニングメカニズムの両方のユーザーエクスペリエンスとセキュリティに影響を与える決定を行う必要があります。

IoTプロビジョニングを大規模に実行するために、顧客は多くの場合、複数の問題のあるドメインにまたがるデバイスでサポートされているプロトコルを介して必要な資格情報をプッシュできるカスタムビルドのツールとソフトウェアアプリケーションを構築および保守します。 IoTプロビジョニングドメインには次のものが含まれます：

• ネットワークコミッショニング。顧客がコンテキスト固有のパラメータを定義するためのメカニズムを提供します。
• クレデンシャルプロビジョニング。クレデンシャルと構成を物理デバイスに割り当てます。および
• クラウドプロビジョニング。認証、承認、デバイス管理を可能にするクラウド側の構成データを設定します。

これら3つのプロビジョニングドメインはすべて、すばらしい顧客ユーザーエクスペリエンスのために調和して機能する必要があります。

たとえば、携帯電話事業者は、携帯電話ユーザーが初めて接続するときに、構成データとポリシー設定をプロビジョニングします。これはシンプルでよく理解されているプロセスであり、SIMカードがデバイスIDを表すモバイルデバイスユーザーにとってはそれほど時間はかかりません。状況は非常に異なり、顧客、特に何百万ものIoTデバイスをプロビジョニングしようとする相手先ブランド供給（OEM）にとっては困難になります。

この記事全体を通して、独自のIoT展開に関連するリスクを回避または軽減する方法を学び、簡単な例を通じて、Amazon Web Services（AWS）などのクラウドプラットフォームを通じて提供されるIoTサービスがどのように達成に役立つかを理解できます。 IoTプロビジョニングの目標。

必要が生じた場合のネットワークコミッショニングへのアプローチ

最終的に、IoTデバイスは、IoTソリューションのハブである中央サービスに接続して通信します。そのハブに到達するには、IoTデバイスがネットワークメディアに参加する必要があります。媒体は、イーサネットのようなハードワイヤー、またはWi-Fiのような無線伝送にすることができます。メディアによっては、ハブに到達するためにデバイスがどのメディアに参加する必要があるかをデバイスに伝える必要があります。たとえば、携帯電話では、SIMカードによって定義されているため、ネットワークに参加するようにデバイスに指示する必要はありません。一方、Wi-Fiネットワークに参加するには、Wi-Fiアクセスポイントの名前とパスワードを知っていて、デバイスにこれらの詳細を伝えることができる必要があります。ネットワークに参加するために構成が必要なデバイスに焦点を当てます。

顧客がIoTネットワークに参加するために使用しているいくつかの異なるメカニズムがあります。今日、ほとんどの人がスマートフォンを持っており、ほとんどすべてのスマートフォンがBluetoothを持っているため、Bluetoothを介した構成が普及しています。ただし、接続する手段はそれだけではありません。 IoTデバイスの一部のWi-Fiモジュールは、それ自体がアクセスポイントになるほどスマートであり、ユーザーがより大規模なネットワークの構成を入力できるシンプルなWebページを開発できます。非消費者向けデバイスの場合でも、シリアルまたはmicroSDを介して構成するのが一般的です。スマートフォンアプリケーションを使用したBluetooth構成が標準になっています。これらのスマートフォンアプリは、この記事の後半で説明するデバイスクラウドプロビジョニングを支援することもできます。

大規模なデバイスクレデンシャルプロビジョニングへのアプローチ

デバイスクレデンシャルのプロビジョニングプロセスは、業界全体で非常に細分化され続けており、すぐに収束する見通しはありません。ほとんどのIoT集中型システムは、暗号化されたトランスポート用のトランスポート層セキュリティ（TLS）1.2接続を強く推奨または要求します。これは、最近では、おそらく雄弁に、転送中の暗号化として知られています。現在、ほとんどのIoTデプロイメントは公開鍵インフラストラクチャ（PKI）を使用しているため、この記事の残りの部分ではPKIの使用を前提としています。いずれの場合も、各デバイスが独自の識別秘密鍵と証明書を所有していることが不可欠です。

クラウド（またはサービスエンドポイント）とのセッションを作成するには、TLS 1.2には秘密鍵とx.509証明書（または資格情報）が必要です。 注：Java Web Token（JWT）などの一部の手法にも同様の課題がありますが、ここでは説明しません。 DNAのような秘密鍵は、個々のデバイスだけが知っている必要があります。つまり、他のデバイスと共有してはなりません。運転免許証のようなx.509証明書は、検証可能な認証局（CA）によって、証明書署名要求（CSR）を提供することによって発行されます。 CSRを提供することは、パスポートを発行するエンティティに、パスポートを受け取るための証拠として指紋と他の合格したテストの証拠を含む出生証明書を渡すこととそれほど変わりません。この記事では、デバイスに一意の秘密鍵があることを前提として、x.509証明書を資格情報と呼びます。

TLS 1.2の詳細はこの記事の範囲を超えていますが、デバイスが秘密鍵を保護することが不可欠である理由を理解できるように、少し情報を提供するのに十分な情報を提供します。 TLS 1.2接続プロセス中に、デバイスがそのIDである秘密鍵の所有者であることを証明するために一連の交換が行われます。デバイスは、認証に使用しようとしているx.509証明書の実際の所有者であることを証明する必要があります。デバイスが接続するときにIoTサービスがデバイスのクレデンシャルを信頼するには、その秘密鍵を手元に用意する必要があります。これで、悪意のある攻撃者がそのキーを入手した場合、セキュリティモデルが崩壊することがわかります。とにかく、IoTキャッスルの鍵を守ってください！

IoTを展開しているほとんどの人と同様に、これらのクレデンシャルを大規模にプロビジョニングする方法について決定を下す必要があります。簡単に確認するには、各デバイスに次のものが必要です。

• デバイスを表す一意の不変の秘密鍵。理想的には、サイドバイサイド攻撃やその他の高度な攻撃から保護するために、秘密鍵は物理的に保護され、メインプログラムメモリにロードできないようにする必要があります。
• アプリケーションまたはIoTサービスに関連するクレデンシャル。

ロジスティクスは、秘密鍵とクレデンシャルプロビジョニングの選択肢によって異なります。クラウドプロビジョニングとは別のものもあれば、クラウドプロビジョニングに依存するものもあります。

• 集積回路セキュリティモジュール（通常は暗号化機能を備えています）、スタンドアロン、またはSystem-In-Package（SiP）、System-On-Module（SoM）、またはSystem-On-Chip（SoC）設計に参加しています。次のいずれかの動作をしている：

• • 手動でプロビジョニングされた、または自己生成された秘密鍵、または信頼のルートを持つセキュリティモジュール。
  • 前の項目に加えて、セキュリティモジュールは事前にプロビジョニングされたx.509証明書の形式で資格情報を提供します。

• サブスクライバーIDモジュール（SIM）、組み込みSIM（eSIM）、および統合SIM（iSIM）テクノロジーは、設計者がセルラーネットワークと通信するためのセルラーIDとして使用するハードウェアを提供します。クレデンシャルのプロビジョニングは通常、モバイルネットワークオペレーター（MNO）プロバイダー、モバイル仮想ネットワークプロバイダー（MVNO）、またはサードパーティに依存します。通信にセルラーモジュールを使用している場合は、これが選択です。
• デバイスフラッシュセグメントへのカスタマイズされた自動化されたデバイスクレデンシャルプロビジョニング。製造時にハードウェアセキュリティモジュール（HSM）と組み合わせて、特別なセキュアフラッシュを使用できます。
• 特別なセキュアセキュアフラッシュ（または非セキュアフラッシュ、通常はプロトタイピング中ですが、フリートプロビジョニングには推奨されません）への秘密鍵とクレデンシャルの手動プロビジョニング。

TLS 1.2の実行は、暗号化要件のために計算集約型のアクティビティであり、特に設計にマイクロコントローラーを使用している場合は、計算コンポーネントの選択に影響を与えます。特殊なICには通常、暗号化ルーチンが含まれています。暗号化ルーチンは、秘密鍵がメインメモリにロードされないようにしながら、ホストプロセッサがTLS1.2操作にサイクルを適用するのを防ぎます。

ハードウェアに対して採用するアプローチは、ハードウェアの設計によって異なります。ハードウェア設計に洗練されたソリューションを選択すると、大規模なプロビジョニングが確実に簡素化されますが、コンピューティング、暗号化モジュール、数学コプロセッシング、およびフラッシュの他のコンポーネント設計の選択に影響を与えるため、ハードウェア設計ライフサイクルの早い段階でコンポーネントを選択する必要があります。確かに、大規模なデバイスの場合、手動でプロビジョニングする必要はありません。トレンドでは、事前にプロビジョニングされたデバイスは、製造、運用、およびカスタマーエクスペリエンスの観点から摩擦が最小であることが示唆されています。

IoTデバイスのプロビジョニングにはクラウドとデバイスのオーケストレーションが必要です

IoTデバイスのプロビジョニングを成功させるには、クラウドとデバイスのプロビジョニングのオーケストレーションが必要です。これは、ハードウェアとソフトウェアの設計、およびデバイスのライフサイクル全体でデバイスを管理する方法に影響を与えます。

IoTサービスの観点からは、関連する構成オブジェクトを作成するために、クレデンシャルプロビジョニングの選択に合わせたプロセスが必要になります。デバイスがIoTサービスに接続するとき、IoTサービスはデバイスを認識し（認証）、特定のデバイスアクションを有効にし（承認）、特定のコンテキストでデバイスを操作および管理できる（デバイス管理）必要があります。

認証のために、IoTサービスはクレデンシャルのフィンガープリントを持っている必要があります。これにより、デバイスが接続してクレデンシャルをIoTサービスに送信するときに、IoTサービスは物理接続を構成オブジェクトに関連付けることができます。 AWS IoTの場合、IoTサービスが着信接続を認識できるようにするクレデンシャルを登録します。 TLSハンドシェイクは、デバイスが秘密鍵にアクセスできることを要求します（IoTサービスはアクセスできません）。これにより、クレデンシャルがデバイスから秘密鍵を使用して送信されていることが保証されます。これが、デバイスの秘密鍵を保護することが非常に重要である理由です。

承認のために、IoTサービスは、最小限のIoTサービスアクセスを許可する接続にルールを適用する必要があります。最小のIoTサービスアクセスとは、デバイスが運用上の義務を果たすために必要なリソースのみを使用するようにデバイスを制限することを意味します。たとえば、AWSのお客様は、クレデンシャルの設定オブジェクトに関連するIoTポリシーを作成します。

デバイス管理の場合、構成オブジェクトにメタデータを適用して、デバイスまたはフリートのグループまたは集合体を明確に指定する必要があります。 IoTでは、数千、数万、数百万のデバイスを管理する必要があります。各デバイスを個別に管理することは実用的ではありません。改造やリファクタリングは面倒な場合があるため、事前にメタデータをデバイス構成に適用するように計画してください。 AWS IoTの場合、IoTデバイス管理プラクティスを推進するThingTypeおよびThingGroup構成オブジェクトを作成します。

大規模なデバイスクラウドプロビジョニングへのアプローチ

すべてとは言えません デバイスのプロビジョニングに関してはIoTの展開は異なりますが、ハードウェアベンダー、IoTアプリケーション、運用コンテキストの間で十分な差別化が行われ、適切なメカニズムの決定に影響を与える一連の堅牢なメカニズムを推進できます。一般的に、一括登録、オンデマンド登録、レイジー登録の3つのアプローチがあります。以下のすべての方法は、すべてのIoTデバイスが独自の秘密鍵と証明書のペアを持っているか、持っていることを前提としています。

一括登録

一括登録では、IoTサービスに登録する資格情報のセットは、デバイスをフィールドに展開する前に認識されます。資格情報のリストを取得したら、資格情報を一括登録プロセスに転送します。一括登録プロセスでは、クレデンシャルが登録され、IoTフリートの管理に使用するIoTサービス内の関連する管理オブジェクトとクレデンシャルが調整されます。一括登録にはカスタマイズが必要な場合がありますが、IoTサービスプロバイダーは通常、一括登録プロセスを顧客に提供します。たとえば、AWSは、AWS IoTCoreサービスの一部としてAWSIoT一括登録プロセスと、AWSSDKを使用したカスタム処理を提供します。 ThingPressという名前のオープンソースプロジェクトは、特定のインポートのユースケースを処理します。

オンデマンド登録

オンデマンドデバイス登録では、デバイスをフィールドに展開する前に、クレデンシャルがペアになっている物理デバイスのセットがわかりません。デバイスが現場に配備されたら、デバイスの電源を入れます。オンデマンドでは、接続サブルーチンは、クレデンシャルの発行者への参照がIoTサービスに登録されているかどうかを判断します。 IoTサービスに、あなたが実際に発行者の所有者であることを確認するための堅牢なメカニズムがある限り、つまり、発行者ID（PKIでは発行者の秘密鍵）が手元にある限り、発行者が提供したので安心できます。クレデンシャル。次に、サブルーチンは自動的にクレデンシャルを登録し、関連する管理オブジェクトを作成します。たとえば、AWSには、プロビジョニングテンプレートを使用するJust-In-Time-Provisioning（JITP）と完全にカスタマイズ可能なメカニズムを提供するJust-In-Time-Registration（JITR）という2つのオンデマンドデバイス登録メカニズムがあります。

レイジー登録

遅延登録では、フィールドに展開する前に、物理デバイスのセットもペアのクレデンシャルも認識されません。この場合、デバイスには既知の不変のID（通常は保護された秘密鍵）があり、IoTサービスはデバイスを超えてプライベートIDを転送せずに確認できます。

現在、遅延登録には3つのメカニズムがあります。クレーム、許可されたモバイルデバイス、および許可されたIDのリストです。最初のケースでは、デバイスはクレデンシャル発行者にクレームを送信し、発行者はトークンで応答し、デバイスはトークンを使用して直接WebサービスAPI呼び出しを行い、証明書を発行します。 2番目のケースでは、デバイスは携帯電話と連携して動作します。携帯電話はユーザー名やパスワードなどのモバイルクレデンシャルを使用し、発行者はトークンで応答し、携帯電話はトークンをデバイスに送信し、デバイスは直接API呼び出しを行うためのトークン。 3番目のケースでは、公開鍵のリストである可能性のある承認済みリストと、デバイスがCSRを使用してIoTサービスへの直接API呼び出しを行います。次に、CSRから導出された公開鍵が許可リストと比較され、一致するものが存在する場合はデバイスに証明書がプロビジョニングされます。たとえば、AWS Fleetプロビジョニングはクレームとスマートフォンベースのプロビジョニングメカニズムを提供し、オープンソースプロジェクトのIoT Provisioning Secret-Freeはクレームを使用した遅延登録メカニズムを提供し、AWSパートナー1nceはAWSマーケットプレイスを通じて合理化されたセルラープロビジョニングエクスペリエンスを提供します。

適切なデバイスプロビジョニングの選択

適切なデバイスプロビジョニングを選択するということは、ハードウェア設計、ソフトウェア設計、製造、およびデバイスライフサイクルの運用に合ったデバイスクレデンシャルとデバイスクラウドプロビジョニングの実践を見つけることを意味します。ハードウェア設計は、個々のデバイスIDおよびクレデンシャルファイルを定義および保存する方法を定義します。ソフトウェアの設計は、デバイスの認証に影響を与えます。製造は、シークレットが作成および保存または識別される条件に影響を与え、認証フィンガープリントがIoTサービスにどのように反映されるかに影響を与えます。

物理ハードウェアへのクレデンシャルプロビジョニングをどのように決定するかは、通常、製品設計を行うときにはるかに前もって決定されるハードウェア設計を反映しており、特定のタイプのクラウドプロビジョニングプロセスへの基本的なピボットを作成します。さらに、独自の製造を行っていない場合は、製品の製造に契約製造業者を使用することになります。コントラクトマニュファクチャリングには多くの利点がありますが、製造ラインでの秘密鍵や証明書などのデバイスシークレットの作成など、製造プロセスの多くの側面を制御することはできません。過剰生産、クローン作成、その他の攻撃経路などのリスクは、雇用されている契約製造業者に直接関係している可能性があります。つまり、夜に安らかに眠るには、多くの信頼が必要です。

IoTフリートのプライベートCAを管理していない場合は、事前にプロビジョニングされたクレデンシャルが適している可能性があります。事前にプロビジョニングされたクレデンシャルは、事前に少し余分なコストがかかる場合がありますが、運用コストが大幅に削減されることがわかりました。独自のプライベートCAを管理する必要がある場合、一部のハードウェア会社は、テープアウトで構成が行われる事前プロビジョニングされた資格情報を提供します。これは、契約製造業者がデバイスの秘密について何も知らないことを意味します。それ以外の場合は、デバイスに不変の秘密鍵または再現可能な自己生成秘密鍵があり、IoTサービスに参加して、ある程度の認証後に資格情報を展開できる、レイジースタイルのプロビジョニングに傾倒することをお勧めします。デバイスに不変の秘密鍵がないという不幸な状況に置かれた場合でも、秘密鍵とクレデンシャルを直接フラッシュにプロビジョニングできますが、これはあまりお勧めできません。

ハードウェア設計とは対照的に、ソフトウェア設計はより柔軟であり、デバイス開発全体、さらにはライフサイクル全体で変更される可能性があります（無線ファームウェアアップデートを考えてください）。デバイスの新しいバッチを顧客に出荷するときはいつでも、デバイスクラウドのプロビジョニングプロセスに頼る必要があります。ソフトウェア設計と同様に、プロビジョニング設計では、進化するソフトウェア要件に基づいて柔軟性が必要になる場合があります。必要な構成とカスタマイズの幅は、新規または追加のデバイスフリートを展開するときに使用するデバイスクラウドプロビジョニングプロセスを推進します。

デバイスのライフサイクル運用要件は、デバイスクラウドのプロビジョニングに必要となる柔軟性のレベルを高めます。具体的には、AWS IoTデバイスクラウドプロビジョニングのほとんどのプロセスでThingTypesやThingGroupsなどの管理オブジェクトの自動作成が可能ですが、プロセスで登録時にカスタムの相互運用性も必要な場合は、Just-In-Time-を検討することをお勧めします。より深いカスタマイズを可能にするプロビジョニング。

最後に、デバイスのライフサイクルを検討するときは、デバイスの有用性を通じて人間の所有者を変更する機会を検討してください。秘密鍵に関するデバイスIDは変更されない可能性がありますが、デバイスを「工場出荷時の状態」に移行するために、前の所有者の証明書を廃止する機会があります。新しい人間の所有者がデバイスを新しいネットワークに委託し、おそらくモバイルアプリケーションを使用してプロビジョニングする場合、その時点で新しい証明書をプロビジョニングする必要がある場合があります。その場合、ライフサイクルメカニズムはこれらの要件に対応する必要があります。

結論

この記事全体を通して、今日目にする可能性のあるIoTプロビジョニングの状況について説明しました。同様に、あなたはあなたが達成しようとしていることとあなたがあなたの顧客に楽しんでもらいたい結果に応じて多くの選択肢があることを目撃しました。すべての場合と同様に、セキュリティはプロビジョニングをサポートします。プロビジョニングは、すべてのデバイスが独自の識別可能な秘密鍵と証明書のペアを持つことから始まります。選択したクレデンシャルプロビジョニングアプローチは、デバイスクラウドプロビジョニングの選択のためのピボットポイントを作成します。新しい設計を行う場合は、安全な要素や安全なエンクレーブなどの強化されたハードウェアセキュリティソリューションをよく検討する必要があります。これにより、デバイスクラウドのプロビジョニングが簡素化されます。既存の設計を進化させたり作り直したりしている場合、選択肢ははるかに限られているように見えるかもしれませんが、IoT容量でデバイスを接続するためのオプションはまだあります。最後に、例と逸話を通して、AWSIoTがシリコンパートナーソリューションとうまく組み合わせるデバイスクラウドプロビジョニングソリューションを提供していることを確認できました。今度は、安全に試運転およびプロビジョニングされたIoTデバイスを構築するときです！