最近多くのエンジニアが Azure IoT Hub Device Provisioning Service を使用し始め、X.509 証明書ベースの認証への移行が進みつつあります。これは非常に素晴らしいことです。これに伴い、ベスト プラクティスや大規模環境で使用する場合についてさまざまなご質問をいただくようになりました。しかし、証明書の発行元やインストール方法、各ステージでの所有者は個々のプロセスやビジネス上の関係性などによって異なるため、その答えはさまざまです。この記事では、運用レベルの大きな規模で行う場合の証明書の生成プロセスと IoT デバイスへのインストール プロセスについて説明します。
この記事は、既に証明書を IoT デバイスに問題なくインストールし、システムを使用できている方には該当しないため、よろしければこちらのコンテンツをご覧ください。この記事は、IoT デバイスに証明書を使用する方法に移行しようとしていて、ベストな方法を模索中の方向けの内容となっています。
深刻なセキュリティ問題
パスワードを使った手っ取り早い方法を採用されてきた方は、1 つの証明書をすべてのデバイスで使うことができないことを疑問に思われているかもしれません。パスワードの場合、同じものをすべてのデバイスで使用することが可能だったからです。そもそも 1 つのパスワードを使い回すのは非常に危険な行為です。過去には何度も大規模な DDoS 攻撃の原因となりました。数年前には米国東海岸で DNS がダウンしたこともあります。そのため、たとえ個人アカウントであっても、パスワードの使い回しは避けるべきです。また、パスワードとは違い、証明書は完全な ID です。パスワードは、クラブハウスに出入りするための暗号のようなものである一方、証明書は、入場者に身分証の提示を求める警備員のようなものです。たとえば、私が自分のパスポートを何枚もコピーし、その 1 つをあなたに渡したとします。しかし、あなたが私のふりをして (私の ID になりすまして) 私の名前と私のパスポートを申告した場合、あるいは、あなたの名前と私のパスポートを申告した場合、あなたの名前と ID が一致しないとして、入国管理官から入国を拒否されることになります。
証明書の決定に関するオプション
IoT デバイスで証明書を使用する場合、さまざまな判断を行う必要があります。ここではその際の重要なオプションをご紹介します。
信頼できる証明書のルート。これは、かけられるコストや耐久性がどの程度必要かによって判断します。公開キー基盤 (PKI) の管理は、経験のない企業の場合は特に簡単なことではありません。次のオプションが考えられます。
- サードパーティの PKI。サードパーティの証明書ベンダーから、中間署名証明書 (プライベート CA) を購入します。
- 自社管理 PKI。自社が所有する PKI システムを維持し、独自の証明書を生成します。
- Azure Sphere のセキュリティ サービス (Azure Sphere デバイスの場合のみ)。
証明書の保存場所。これは、構築するデバイスの種類、デバイスにどのくらいのスペースを設けられるか (安全なストレージを使用する余裕があるか)、デバイスの性能、デバイスに備わっているセキュリティ テクノロジなどを見て判断します。次のオプションが考えられます。
- ハードウェア セキュリティ モジュール (HSM) (推奨)。まず、デバイスの制御基板に HSM が搭載済みでないかを確認してください。これは、デバイスに HSM が搭載されていたのにまったく気づかず、使用していなかったというお客様がいたためです。HSM が搭載されていなかった場合は、ハードウェア メーカーと協力して、ニーズに合った HSM を選んでください。
- ディスク上の安全な場所 (Trusted Execution Environment (TEE) など)
- ローカル ファイル システム、または Windows 証明書ストアなどの証明書ストア
- その他
工場での接続。これは、デバイスにインストールする証明書を取得する方法とタイミングによって判断します。次のオプションが考えられます。
- 接続あり (証明書をローカルで生成できる)
- 接続なし (工場が署名済みの CA 証明書を所有していて、それをデバイスの証明書をローカルでオフライン生成する際に使用する)
- 接続なし (証明書を事前に生成する必要がある、または、オフライン PKI で生成する)
監査要件。製造するデバイスの種類によっては、デバイス ID がどのようにデバイスにインストールされたかについて、監査証跡を残すことが規定されています。これは製造コストに大きく影響するため、必要な場合にのみ実装するようにします。このケースに該当するかどうか不明な場合は、自社の法務部に問い合わせてください。次のオプションが考えられます。
- 規制が厳格ではない業界。監査は不要です。
- 規制が厳格な業界。証明書に関する各種要件に従って安全な場所に証明書をインストールする必要があります。証明書のインストール先として安全な場所が必要な場合は、おそらく、証明書をデバイスにインストールする方法とその場所がシステムに用意されていることを既にご存知なはずです。その場合は、この記事は読まなくて問題がないと思われます。
証明書の有効期限。運転免許証のように、証明書には作成時に有効期限が設定されています。次のオプションが考えられます。
- 更新が不要なほど長い有効期限を設定。これは非常に危険です。HSM などの安全のきわめて高いストレージを使用すればリスクは軽減できますが、それでも有効期限を長く設定することはお勧めしません。
- デバイスが寿命を迎える前に更新が必要となる程度の有効期限を設定。これはコンテキストに依存するため、証明書の更新方法、証明書の取得元、デバイスで使用可能な通信機能の種類などについて戦略を立てる必要があります。
証明書を生成するタイミング
前のセクションで触れましたが、デバイスの証明書を生成するタイミングを決めるにあたって、工場での接続は大きく影響します。ここではその点を説明します。
一部の HSM ベンダーは、顧客に代わって HSM に証明書をインストールするサービスを有料で提供しています。顧客は HSM ベンダーに署名証明書へのアクセスを許可し、HSM ベンダーがその署名証明書で署名された証明書を、顧客が購入した HSM にインストールします。このため顧客は、デバイスに HSM を搭載するだけで済みます。このプロセスを採用したお客様は、非常にスムーズだったと評価していました。"HSM へのプリロード" というプロセスを選択すれば、証明書を生成するタイミングに悩む必要はなくなります。助かりますね。
デバイスの内部で証明書を生成する場合は、その後、登録のために公開 X.509 証明書をデバイスから抽出する必要があります。
工場で接続が可能な場合は、必要なときにいつでも証明書を生成できます。
工場での接続が不可の場合でも、オフラインに対応した自社 PKI を使用できる場合は、必要なときにいつでも証明書を生成できます。
工場での接続が不可で、サードパーティの PKI を使用する場合は、インターネット接続が可能な場所で事前に証明書を生成する必要があります。
証明書をインストールするタイミング
IoT デバイス用の証明書を生成したら (または生成するタイミングがわかったら)、次はデバイスに証明書をインストールします。
「HSM へのプリロード」を選択すれば、より簡単に行うことができます。HSM をデバイスにインストールし、デバイス コードからアクセスできるようにします。次に HSM の API を使用して、HSM に格納されている証明書にアクセスします。これは最も簡単な方法ではありますが、コストは少し高くなります。
それ以外の方法の場合は、製造工程のどこかで証明書をインストールする必要があります。既存の工程に組み込む最も簡単な方法は、ファームウェアの初期イメージに証明書をインストールすることです。各デバイスは、パッケージに収められ出荷される前に、イメージをインストールし最終の品質チェックなどを行う工程で、少なくとも 1 回は工場内を通過します。通常、インストールとテストを 1 つの工程で実施するツールがあるため、そのツールに変更を加えて、証明書のインストールが必要なときにいつでも証明書を生成する、あるいは、事前生成されたストアから証明書を取得してインストールできるようにすることができます。このツールを使うことで、運用環境レベルで必要とされる規模に対応できます。
IoT デバイスの証明書についてさらに細かいサポートが必要な場合は、セキュリティ監査プログラムの担当者までお問い合わせください。デバイスでの証明書のセットアップが完了したら、Device Provisioning Service の証明書の使用と登録の方法についてもご確認ください。
最後に、まとめとして 5 行詩をお届けします。
デバイスへの証明書のインストールを大規模に行う作業には
大きな労力がかかり、失敗のリスクも伴いますが、
お客様ご自身で行うことができます。
計画を綿密に立てたうえで実施してください
この記事が皆様のお役立てば幸いです。