Linux で TPM を使用して大規模な IoT Edge デバイスを作成およびプロビジョニングする

適用対象: IoT Edge 1.1

この記事では、トラステッド プラットフォーム モジュール (TPM) を使用して Azure IoT Edge for Linux デバイスを自動プロビジョニングする手順について説明します。 IoT Edge デバイスは、Azure IoT Hub Device Provisioning Service を使用して自動プロビジョニングできます。 自動プロビジョニングの処理に慣れていない場合は、「プロビジョニングの概要」を読んでから先に進んでください。

この記事では、次の 2 つの手法の概要を説明します。 ソリューションのアーキテクチャに基づいて、使用する手法を選択してください。

• 物理 TPM ハードウェアを使用して Linux デバイスを自動プロビジョニングします。 例として、インフィニオンの OPTGA™ TPM SLB 9670があります。
• Hyper-V が有効な Windows 開発用コンピューターで実行されているシミュレートされた TPM を使用して、Linux 仮想マシン (VM) を自動プロビジョニングします。 この手法は、テスト シナリオとしてのみ使用することをお勧めします。 シミュレートされた TPM では、物理 TPM と同じセキュリティは提供されません。

手順は使用する手法によって異なるので、先に進む前に正しいタブが表示されていることをご確認ください。

前提条件

クラウド リソース

• アクティブな IoT ハブ
• 自分の IoT ハブにリンクされた、Azure 内の IoT Hub デバイス プロビジョニング サービスのインスタンス
  • デバイス プロビジョニング サービスのインスタンスをお持ちでない場合は、IoT Hub デバイス プロビジョニング サービス クイックスタートの「新しい IoT Hub デバイス プロビジョニング サービスの作成」および「IoT ハブとデバイス プロビジョニング サービスとをリンクさせる」の手順に従ってください。
  • Device Provisioning Service を実行した後、概要ページから [ID スコープ] の値をコピーします。 この値は、IoT Edge ランタイムを構成するときに使用します。

デバイスの要件

デバイスの設定

TPM のプロビジョニング情報を取得する

このセクションでは、TPM の登録 ID と保証キーを取得するために使用できるツールを構築します。

1. デバイスにサインインし、「Linux 開発環境 を設定して Azure IoT device SDK for C をインストールしてビルドする」の手順に従います。

2. 次のコマンドを実行して、TPM のデバイス プロビジョニング情報を取得する SDK ツールをビルドします。

   cd azure-iot-sdk-c/cmake
   cmake -Duse_prov_client:BOOL=ON ..
   cd provisioning_client/tools/tpm_device_provision
   make
   sudo ./tpm_device_provision
   

3. 出力ウィンドウには、デバイスの 登録 ID と 保証キーが表示されます。 後ほど Device Provisioning Service でデバイスの個別登録を作成するときに使用できるように、これらの値をコピーします。

登録 ID と保証キーを取得したら、次に進むことができます。

デバイスプロビジョニングサービス登録の作成

TPM のプロビジョニング情報を使用して、Device Provisioning Service で個別登録を作成します。

デバイスプロビジョニングサービスで登録を作成するときに、デバイス ツインの初期状態を宣言する機会があります。 デバイス ツインでは、ソリューションで使用される任意のメトリック (リージョン、環境、場所、デバイスの種類など) によってデバイスをグループ化するためのタグを設定できます。 これらのタグは、自動展開を作成するために使用されます。

1. Azure portal で、IoT Hub Device Provisioning Service のインスタンスに移動します。

2. [設定] の下の [登録の管理] を選択します。

3. [個別登録の追加] を選択し、登録を構成する次の手順を完了します。

   1. [メカニズム] で [TPM] を選択します。

   2. VM または物理デバイスからコピーした保証キーと登録 ID を指定します。

   3. 必要に応じて、デバイス ID を指定します。 デバイス ID を指定しなかった場合は、登録 ID が使用されます。

   4. [True] を選択し、VM または物理デバイスが IoT Edge デバイスであることを宣言します。

   5. デバイスの接続先になるリンクされた IoT ハブを選択するか、[Link to new IoT Hub]\(新しい IoT ハブへのリンク\) を選択します。 複数のハブを選択でき、デバイスは、選択した割り当てポリシーに従ってそれらのハブの 1 つに割り当てられます。

   6. 必要に応じて、[デバイス ツインの初期状態] にタグ値を追加します。 タグを使用して、デバイス グループをモジュール展開のターゲットにすることができます。 詳細については、大規模な IoT Edge モジュールの展開に関する記事を参照してください。

   7. [保存] を選択します。

これで、このデバイスの登録が存在しているので、IoT Edge ランタイムによってインストール時にデバイスを自動的にプロビジョニングできます。

IoT Edge をインストールする

このセクションでは、IoT Edge 用に Linux VM または物理デバイスを準備します。 次に、IoT Edge をインストールします。

次のコマンドを実行してパッケージ リポジトリを追加し、信頼できるキーの一覧に Microsoft パッケージ署名キーを追加します。

コンテナー エンジンをインストールする

Azure IoT Edgeは、OCI と互換性のあるコンテナー ランタイムに依存しています。 運用環境のシナリオでは、Moby エンジンを使用することをお勧めします。 Moby エンジンは、IoT Edge で正式にサポートされている唯一のコンテナー エンジンです。 Docker CE/EE コンテナー イメージは、Moby ランタイムと互換性があります。

sudo apt-get update; \
  sudo apt-get install moby-engine

sudo apt-get update; \
  sudo apt-get install moby-engine

sudo yum install moby-engine moby-cli

Moby エンジンが正常にインストールされたら、ログ記録メカニズムとして local ログ ドライバー を使用するように構成します。 ログ構成の詳細については、「運用環境デプロイのチェックリスト」を参照してください。

• /etc/docker/daemon.jsonで Docker デーモンの構成ファイルを作成または開きます。

• 次の例に示すように、既定のログ ドライバーを local ログ ドライバーに設定します。

     {
        "log-driver": "local"
     }
  

• コンテナー エンジンを再起動して、変更を有効にします。

  sudo systemctl restart docker
  

  ヒント

  Moby コンテナー エンジンをインストールするときにエラーが発生する場合は、Linux カーネルに Moby との互換性があることを確認します。 埋め込みデバイスの一部の製造元からは、コンテナー エンジンとの互換性のために必要な機能を備えていないカスタム Linux カーネルを含むデバイス イメージが提供されています。 Moby から提供されている check-config スクリプトを使用する次のコマンドを実行して、カーネルの構成を確認します。

  curl -ssl https://raw.githubusercontent.com/moby/moby/master/contrib/check-config.sh -o check-config.sh
  chmod +x check-config.sh
  ./check-config.sh
  

  スクリプトの出力で、Generally Necessary と Network Drivers の下のすべての項目が有効になっていることを確認します。 機能が欠けている場合は、カーネルをソースから再構築し、カーネルの適切な .config に含める関連モジュールを選択することで、それらを有効にします。同様に、defconfig や menuconfig などのカーネル構成ジェネレーターを使用している場合は、それぞれの機能を見つけて有効にし、ご自分のカーネルを適宜再構築します。 新たに変更されたカーネルを展開したら、check-config スクリプトをもう一度実行して、必要なすべての機能が正常に有効になっていることを確認します。

IoT Edge ランタイムをインストールする

IoT Edge セキュリティ デーモンは、IoT Edge デバイスのセキュリティ標準を提供し、維持します。 デーモンは、すべてのブートで起動し、残りの IoT Edge ランタイムを起動してデバイスをブートストラップします。

このセクションの手順は、インターネットに接続されているデバイスに最新バージョンをインストールする一般的なプロセスを表します。 プレリリース バージョンなどの特定のバージョンをインストールする必要がある場合、またはオフラインの間にインストールする必要がある場合は、この記事で後述する「オフラインまたは特定のバージョンのインストール」の手順に従ってください。

libiothsm-std パッケージと共に IoT Edge バージョン 1.1.* をインストールします。

sudo apt-get update; \
  sudo apt-get install iotedge

sudo apt-get update; \
  sudo apt-get install iotedge

クラウド ID を使用してデバイスをプロビジョニングする

ランタイムがデバイスにインストールされたら、Device Provisioning Service と IoT Hub に接続するために使用される情報でデバイスを構成します。

1. 前に集めた Device Provisioning Service の ID スコープとデバイスの登録 ID を把握しておきます。

2. IoT Edge デバイスで構成ファイルを開きます。

   sudo nano /etc/iotedge/config.yaml
   

3. ファイルのプロビジョニング構成セクションを見つけます。 TPM プロビジョニング行のコメントを解除し、他のプロビジョニング行がコメントアウトされていることを確認してください。

   provisioning: 行の前に空白文字を含めず、入れ子になった項目は 2 つのスペースでインデントする必要があります。

   # DPS TPM provisioning configuration
   provisioning:
     source: "dps"
     global_endpoint: "https://global.azure-devices-provisioning.net"
     scope_id: "SCOPE_ID_HERE"
     attestation:
       method: "tpm"
       registration_id: "REGISTRATION_ID_HERE"
   
   # always_reprovision_on_startup: true
   # dynamic_reprovisioning: false
   

4. scope_id と registration_id の値を、Device Provisioning Service とデバイス情報で更新します。 scope_id の値は、Device Provisioning Service のインスタンスの概要ページにある ID スコープです。

5. 必要に応じて、always_reprovision_on_startup または dynamic_reprovisioning 行を使用して、デバイスの再プロビジョニング動作を構成します。 デバイスが起動時に再プロビジョニングするように設定されている場合、デバイスは常に最初に DPS を使用してプロビジョニングを試行し、失敗した場合はプロビジョニング バックアップにフォールバックします。 デバイスが自身を動的に再プロビジョニングするように設定されている場合、デバイスが 1 つの IoT Hub から別の IoT Hub に移動された場合など、再プロビジョニング イベントが検出されると、IoT Edge (およびすべてのモジュール) が再起動して再プロビジョニングされます。 具体的には、IoT Edge は SDK からの bad_credential または device_disabled エラーをチェックして、再プロビジョニング イベントを検出します。 このイベントを手動でトリガーするには、IoT Hub でデバイスを無効にします。 詳細については、「IoT Hub デバイスの再プロビジョニングの概念」を参照してください。

6. ファイルを保存して閉じます。

IoT Edge に TPM へのアクセス権を付与する

IoT Edge ランタイムは、デバイスを自動的にプロビジョニングするために TPM にアクセスする必要があります。

iotedge サービスにルート特権が付与されるように、systemd 設定をオーバーライドすることで、TPM に IoT Edge ランタイムへのアクセス権を付与できます。 サービス権限を昇格したくない場合は、次の手順を使用して、TPM へのアクセス権を手動で付与することもできます。

1. IoT Edge ランタイムに tpm0 と tpmrm0へのアクセスを許可する新しい規則を作成します。

   sudo touch /etc/udev/rules.d/tpmaccess.rules
   

2. 規則ファイルを開きます。

   sudo nano /etc/udev/rules.d/tpmaccess.rules
   

3. 次のアクセス情報を規則ファイルにコピーします。 4.12 より前のカーネルを使用するデバイスには、tpmrm0 が存在しない場合があります。 tpmrm0 が存在しないデバイスでは、そのルールは安全に無視されます。

   # allow iotedge access to tpm0
   KERNEL=="tpm0", SUBSYSTEM=="tpm", OWNER="iotedge", MODE="0600"
   KERNEL=="tpmrm0", SUBSYSTEM=="tpmrm", OWNER="iotedge", MODE="0600"
   

4. ファイルを保存して終了します。

5. udev システムをトリガーして、新しい規則を評価します。

   /bin/udevadm trigger --subsystem-match=tpm --subsystem-match=tpmrm
   

6. 規則が正常に適用されたことを確認します。

   ls -l /dev/tpm*
   

   成功した場合の出力は、次のようになります。

   crw------- 1 iotedge root 10, 224 Jul 20 16:27 /dev/tpm0
   crw------- 1 iotedge root 10, 224 Jul 20 16:27 /dev/tpmrm0
   

   正しいアクセス許可が適用されていない場合は、コンピューターを再起動して udev更新してみてください。

7. IoT Edge ランタイムを再起動して、デバイスで行ったすべての構成変更を適用します。

   sudo systemctl restart iotedge
   

インストールの成功を確認する

もしまだ行っていない場合は、デバイスで行ったすべての構成変更が反映されるように、IoT Edge ランタイムを再起動してください。

sudo systemctl restart iotedge

IoT Edge ランタイムが実行されていることを確認します。

sudo systemctl status iotedge

デーモンのログを調べます。

journalctl -u iotedge --no-pager --no-full

プロビジョニング エラーが発生した場合は、構成の変更がまだ有効になっていない可能性があります。 IoT Edge デーモンをもう一度再起動してみてください。

sudo systemctl daemon-reload

または、変更が新たな開始時に有効になる場合は、VM の再起動を試してください。

ランタイムが正常に起動した場合は、お使いの IoT ハブに移動して、新しいデバイスが自動的にプロビジョニングされたことを確認できます。 これで、デバイスで IoT Edge モジュールを実行する準備ができました。

実行中のモジュールを一覧表示します。

iotedge list

Device Provisioning Service で作成した個々の登録が使用されたことを確認できます。 Azure portal で Device Provisioning Service インスタンスに移動します。 作成した個々の登録の詳細を開きます。 登録ステータスが割り当て済みであり、デバイス ID がリストされています。

次のステップ

デバイス プロビジョニング サービスの登録プロセスでは、新しいデバイスをプロビジョニングするときに、デバイス ID とデバイス ツイン タグを同時に設定できます。 これらの値を使うことにより、自動デバイス管理を通じて個々のデバイスやデバイスグループをターゲットにすることができます。

Azure portal を使用して大規模な IoT Edge モジュールの展開と監視を行う方法または Azure CLI を使用する方法を理解します。