次の方法で共有


IoT ソリューションのセキュリティ アーキテクチャ

IoT ソリューションを設計および構築するときは、潜在的な脅威を把握し、適切な防御措置を講じることが重要となります。 攻撃者がシステムを侵害する可能性がある方法を理解することは、最初から適切な軽減策が実施されていることを確認するのに役立ちます。

脅威モデリング

Microsoft では、IoT ソリューション設計の一部として脅威モデリング プロセスを使用することをお勧めします。 脅威モデリングとセキュリティで保護された開発ライフサイクルに慣れていない場合は、次を参照してください。

IoT のセキュリティ

脅威モデリング演習の一環として、IoT アーキテクチャを複数のゾーンに分割すると便利です。

  • Device
  • フィールド ゲートウェイ
  • クラウド ゲートウェイ
  • サービス

それぞれのゾーンに、固有のデータや認証要件、認可要件が存在することも少なくありません。 被害を隔離したり、低い信頼ゾーンがそれより高い信頼ゾーンに及ぼす影響を限定したりする目的にもゾーンを使用できます。

各ゾーンは "信頼の境界" によって仕切られています。下の図に赤色の点線で示した箇所が信頼の境界です。 この図は、ソースからソースへのデータの遷移を表しています。 この遷移中に、データが次の脅威にさらされる可能性があります。

  • スプーフィング
  • 改ざん
  • 否認
  • 情報の漏えい
  • サービス拒否
  • 権限の昇格

詳細については、「STRIDE モデル」を参照してください。

一般的な IoT ソリューション アーキテクチャにおけるゾーンと信頼境界を示す図。

STRIDE を使用して、各ゾーン内の各コンポーネントに対する脅威をモデル化できます。 以下の各セクションで、それぞれの構成要素について詳しく説明すると共に、セキュリティ上の具体的な懸念事項と導入すべき解決策について取り上げます。

この記事の残りの部分では、これらのゾーンとコンポーネントの脅威と軽減策について詳しく説明します。

デバイス ゾーン

デバイス環境は、デバイスへの物理的なアクセスとローカル ネットワークのデジタル アクセスが可能なデバイスの周りの空間です。 ローカル ネットワークは、パブリック インターネットと明確に区別され、隔離されていると見なされます。ただし、パブリック インターネットとの橋渡し的な役割を果たすこともあります。 デバイス環境には、デバイスどうしのピア ツー ピア通信を可能にする狭い範囲の無線技術が含まれています。 このようなローカル ネットワークの錯覚を生み出すネットワーク仮想化テクノロジは含まれていません。 2 台のデバイスがピア ツー ピア通信の関係を結ぶうえでパブリック ネットワーク空間を介した通信が必要となるような公共通信事業者のネットワークは含まれていません。

フィールド ゲートウェイ ゾーン

フィールド ゲートウェイは、通信を可能にする要素として、また場合によってはデバイスの制御システムやデバイスのデータ処理の拠点としての役割を果たします。 フィールド ゲートウェイのゾーンには、フィールド ゲートウェイ自体とそこに接続されているすべてのデバイスが含まれます。 フィールド ゲートウェイは、専用のデータ処理機構の外で作動します。通常、特定の場所に固定され、物理的な侵入のリスクがあります。また、運用上の冗長性は限られています。 フィールド ゲートウェイは通常、攻撃者が物理的なアクセスを取得した場合に物理的に妨害する可能性のあるものです。

アクセスと情報の流れを管理することにおいて積極的役割を果たしてきたという点で、フィールド ゲートウェイはトラフィック ルーターとは異なります。 フィールド ゲートウェイには、2 種類の攻撃対象領域があります。 1 つは、フィールド ゲートウェイに接続されているデバイスと接する領域です。フィールド ゲートウェイ ゾーンの内側を表します。 もう 1 つは、外部からのあらゆる通信と接する領域で、フィールド ゲートウェイ ゾーンのエッジの部分となります。

クラウド ゲートウェイ ゾーン

クラウド ゲートウェイは、複数のサイトに展開されているデバイスまたはフィールド ゲートウェイとの間のリモート通信を可能にするシステムです。 通常、クラウド ゲートウェイでは、クラウドベースの制御およびデータ分析システム、またはそのようなシステムのフェデレーションが可能になります。 場合によっては、タブレットやスマートフォンなどの端末から特殊用途のデバイスへのアクセスをクラウド ゲートウェイが直接つかさどるケースもあります。 クラウド ゲートウェイ ゾーンでは、運用上の対策によって標的への物理的なアクセスができないようになっており、必ずしもパブリック クラウド インフラストラクチャには公開されていません。

クラウド ゲートウェイとそこに接続されているすべてのデバイス (またはフィールド ゲートウェイ) を他のネットワーク トラフィックから隔離するために、クラウド ゲートウェイはネットワーク仮想化オーバーレイにマッピングすることも考えられます。 クラウド ゲートウェイそのものは、デバイス制御システムではなく、デバイス データの処理や保存を行う機構でもありません。そうした機構とのインターフェイスとなります。 クラウド ゲートウェイ ゾーンには、クラウド ゲートウェイ自体のほか、そこに直接または間接的に接続されているすべてのフィールド ゲートウェイとデバイスが含まれます。 このゾーンのエッジは、外部からのあらゆる通信が経由する明確な攻撃対象領域となっています。

サービス ゾーン

ここでいうサービスとは、フィールド ゲートウェイまたはクラウド ゲートウェイを介してデバイスと連動するソフトウェア コンポーネントまたはモジュールのことです。 サービスは、デバイスからデータを収集し、それらのデバイスをコマンドで制御できます。 サービスは、ゲートウェイやその他のサブシステムに対して ID の下で次の処理を行うメディエーターです。

  • データを保存して分析する
  • データ分析情報またはスケジュールに基づいてデバイスにコマンドを発行する
  • 認可されたエンド ユーザーに情報と制御機能を公開する

IoT デバイス

IoT デバイスは、多くの場合特殊用途のデバイスであり、単純な温度センサーから、無数のコンポーネントから成る複雑な工場製造ラインまでさまざまです。 IoT デバイスの機能の例を次に示します。

  • 環境条件を測定して報告する
  • バルブを回転する
  • サーボを制御する
  • アラームを鳴らす
  • ライトのオンとオフを切り替える

これらのデバイスの目的によって、技術的な設計や、製造に認められる予算、稼働予定年数が決まります。 許容される消費電力コスト、物理的な据付面積、利用できる記憶域、計算能力、セキュリティ機能は、これらの要因の制約を受けることとなります。

オートメーション化された IoT デバイスやリモート制御の IoT デバイスで問題が発生する可能性がある点は次のとおりです。

  • 物理的な不良
  • 制御ロジックの欠陥
  • 意図的な侵害行為や不正な操作。

これらの故障の結果は、製造ロットの破壊、建物の焼失、けがや死亡など、深刻なものになる可能性があります。 そのため、モノを動かすデバイスや、モノを動かすコマンドに直結するセンサー データを報告するデバイスには、高いセキュリティ水準が求められます。

デバイス制御とデバイス データの対話

特殊な用途をもって接続されるデバイスには、膨大な数の対話領域と対話パターンがあり、デバイスへのデジタル アクセスのセキュリティを確保するうえでは、そのすべてを、基本的な枠組みを形成するものとして捉える必要があります。 "デジタル アクセス" とは、デバイスへの直接の物理的アクセスではなく、ソフトウェアとハードウェアを介して実行される操作を指します。 たとえば、施錠された部屋にデバイスを設置することで、物理的なアクセスを制御できます。 物理的アクセスをソフトウェアやハードウェアによって防止することはできませんが、物理的なアクセスがシステム障害に発展するのを防ぐための対策を講じることはできます。

対話パターンを調査するときに注目するのは、デバイスの制御デバイスのデータ です。その両者に同程度の注意を払う必要があります。 デバイス制御とは、デバイスの動作を変更する目的でデバイスに提供されるすべての情報を指します。 デバイスのデータは、デバイスがその状態やその環境に関して観察された状態について、他者に出力する情報を指します。

Azure IoT 参照アーキテクチャの脅威モデリング

このセクションでは、IoT に対する脅威モデリングの考え方とそれによって特定された脅威の解決方法を、Azure IoT 参照アーキテクチャを用いて説明します。

Azure IoT の参照アーキテクチャを示す図。

次の図は、データ フロー ダイアグラム モデルを使って参照アーキテクチャを単純化したものです。

Azure IoT の参照アーキテクチャから派生したデータ フロー図。

このアーキテクチャでは、デバイスの機能とフィールド ゲートウェイの機能が切り離されています。 この方法では、より安全性の高いフィールド ゲートウェイ デバイスを使用できます。 フィールド ゲートウェイ デバイスは、安全なプロトコルを使ってクラウド ゲートウェイと通信できます。一般に、安全なプロトコルの使用には、単純なデバイス (サーモスタットなど) に備わっている以上の処理能力が必要です。 図の Azure サービス ゾーンでは、Azure IoT Hub サービスがクラウド ゲートウェイです。

前に説明したアーキテクチャに基づいて、次のセクションでは、脅威モデリングの例をいくつか示します。 この例では、脅威モデルの核となる要素に焦点を絞って説明しています。

  • プロセス
  • 通信
  • 記憶域

プロセス

このプロセス カテゴリの脅威の例をいくつか紹介します。 脅威は STRIDE モデルに基づいて分類されます。

スプーフィング: 攻撃者が、ソフトウェア レベルまたはハードウェア レベルでデバイスから暗号化キーを抽出します。 攻撃を受けたユーザーは、これらのキーを使用して、元のデバイスの ID を使用し、別の物理デバイスまたは仮想デバイスからシステムにアクセスします。

サービス拒否: 妨害電波やケーブルの切断によって、デバイスの機能が停止したり、通信できない状態になったりする可能性があります。 たとえば、電源やネットワーク接続が意図的に切断された防犯カメラは、データをまったく報告することができなくなります。

改ざん: 攻撃者がデバイス上のソフトウェアの一部または全部を交換します。 攻撃者のコードがデバイスの暗号化キーを使用できる場合は、デバイスの ID を使用できます。

改ざん: たとえば、だれもいない廊下の写真を防犯カメラにかざすことによって、そのような廊下の可視スペクトル画像が表示されることが考えられます。 発煙センサーや火災感知器の下で何者かがライターを点火したことによって、警報が鳴ることも考えられます。 いずれの場合も、デバイスのシステムとしては、技術的に信頼性が確保されているかもしれませんが、報告される情報は改変されています。

改ざん: 攻撃者が、抽出した暗号化キーを使用して、デバイスから送信されるデータを傍受、遮断し、偽のデータに置き換えて、盗んだキーで認証をパスすることが考えられます。

情報漏えい: デバイス上で実行されるソフトウェアが改変されていた場合、その改変されたソフトウェアから、許可していない相手にデータが漏えいするおそれがあります。

情報漏えい: 攻撃者が、抽出した暗号化キーを使用し、デバイスとフィールド ゲートウェイまたはクラウド ゲートウェイとの間の通信経路にコードを注入して情報を吸い上げるおそれがあります。

サービス拒否: さまざまな産業用機械で意図的にデバイスの電源が切られたり、通信ができないモードに設定されたりするおそれがあります。

改ざん: 制御システムにとって未知の状態 (既知のキャリブレーション パラメーターの範囲外) で動作するようにデバイスの構成が変更され、間違った解釈につながりうるデータがデバイスから出力される可能性があります。

特権の昇格: 特定の機能を実行するデバイスが、他の目的に利用される可能性があります。 たとえば半開状態となるようにプログラムされているバルブが、意図的に全開にされる可能性があります。

スプーフィング/改ざん/否認: 民生用のリモコンでまれにあることですが、セキュリティが確保されていない場合、攻撃者がデバイスの状態を匿名で操作することができます。 たとえばテレビをオフにするリモコンが使われる可能性があります。

次の表に、これらの脅威に対する軽減策の例を示します。 「脅威」列の値は以下の省略形です。

  • スプーフィング (S)
  • 改ざん (T)
  • 否認 (R)
  • 情報漏えい (I)
  • サービス拒否 (D)
  • 特権の昇格 (E)
コンポーネント 脅威 軽減策 リスク 実装
Device S デバイスに ID を割り当てて本物であることを確認します。 デバイスまたはその一部が他のデバイスに差し替えられます。 意図したデバイスと通信しているという確信はどうすれば得られるでしょうか。 トランスポート層セキュリティ (TLS) または IPSec を使ってデバイスを認証します。 完全な非対称暗号を扱うことのできないデバイスでは、インフラストラクチャが事前共有キー (PSK) の使用をサポートしている必要があります。 Microsoft Entra ID、OAuth を使用します。
TRID たとえば、デバイスからキーや他の暗号化マテリアルを抽出できないようにすることで、改ざん防止メカニズムをデバイスに適用します。 何者かによってデバイスが改ざんされた場合にリスクが発生します (物理的干渉)。 誰もそのデバイスを改ざんしていないことを確認するにはどうすればよいですか。 最も効果的な軽減策は、トラステッド プラットフォーム モジュール (TPM) です。 TPM にはキーが格納されますが、それを読み取ることはできません。 ただし、TPM 自体は暗号操作にキーを使用できます。 デバイスのメモリの暗号化、 デバイスのキー管理、 コード署名を行います。
E デバイスのアクセス制御を行います。 承認スキームを設けます。 外部ソース (または侵害されたセンサー) からのコマンドによってデバイスの操作を別途実行できた場合、本来であれば利用できない操作を攻撃者に許すことになります。 デバイスに認可スキームを適用します。
フィールド ゲートウェイ S クラウド ゲートウェイに対してフィールド ゲートウェイが本物であることを証明します (証明書、PSK、要求など)。 何者かがフィールド ゲートウェイになりすました場合、任意のデバイスに見せかけることができます。 TLS RSA/PSK、IPSec、RFC 4279。 キーの保存と認証に関してはデバイスの場合とまったく同じです。TPM を使用することが最善の方法となります。 IPSec の 6LowPAN 拡張によってワイヤレス センサー ネットワーク (WSN) をサポートします。
TRID 改ざんされないようにフィールド ゲートウェイを保護します (TPM を使用するなど)。 なりすましによる攻撃。一見フィールド ゲートウェイと通信しているかのようにクラウド ゲートウェイに見せかけて情報を漏えいさせたり、データを改ざんしたりします。 メモリの暗号化、TPM、認証。
E フィールド ゲートウェイにアクセス制御機構を導入します。

通信

この通信カテゴリの脅威の例をいくつか紹介します。 脅威は STRIDE モデルに基づいて分類されます。

サービス拒否: 一般に、制約の厳しいデバイスは、受信接続や一方的に送りつけられるデータグラムをネットワーク上で常時待機する形で DoS の脅威にさらされます。 攻撃者は、多数の接続を同時に開き、何も処理を行わないか、処理に時間をかけることがあります。また、一方的なトラフィックでデバイスの処理能力をパンクさせる場合もあります。 どちらの場合もデバイスは事実上、ネットワークで機能不全の状態となります。

スプーフィング、情報漏えい: 制約の厳しいデバイスや特殊用途のデバイスには、パスワードや PIN による保護など、万能型のセキュリティ機構が採用されているケースが少なくありません。 場合によっては、完全にネットワークを信頼し、同じネットワーク上にある任意のデバイスに情報へのアクセスを許可します。 ネットワークが漏えいした共有キーによって保護されている場合、攻撃者がデバイスを制御したり、送信されるデータを観察したりする可能性があります。

スプーフィング: 攻撃者は放送を傍受するか、部分的にオーバーライドして、発信元になりすます場合があります。

改ざん: 攻撃者は放送を傍受するか、部分的にオーバーライドして、偽の情報を送信する場合があります。

情報漏えい: 攻撃者は放送を傍受して、認可なく情報を入手する場合があります。

サービス拒否: 攻撃者は、放送信号を妨害して情報を配信できないようにする場合があります。

次の表に、これらの脅威に対する軽減策の例を示します。

コンポーネント 脅威 軽減策 リスク 実装
デバイス対 IoT Hub TID (D)TLS (PSK/RSA) によってトラフィックを暗号化します。 デバイスとゲートウェイとの間の通信を傍受または妨害します。 プロトコル レベルでセキュリティを確保します。 カスタム プロトコルの場合は、その保護方法を把握する必要があります。 ほとんどの場合、通信は、デバイスと IoT Hub との間で行われます (デバイス側から接続が開始されます)。
デバイス対デバイス TID (D)TLS (PSK/RSA) によってトラフィックを暗号化します。 デバイス間で転送されているデータが読み取られます。 データが改ざんされます。 デバイスに対する新規接続が過剰に繰り返されます。 プロトコル レベルでセキュリティを確保します (MQTT/AMQP/HTTP/CoAP)。 カスタム プロトコルの場合は、その保護方法を把握する必要があります。 DoS の脅威を軽減するには、クラウド ゲートウェイまたはフィールド ゲートウェイを介してデバイスをピアリングし、それらのデバイスがネットワークに対するクライアントとしてのみ動作するように徹底します。 ゲートウェイがピアリングを仲介した後、ピア間に直接接続が存在する可能性があります。
外部エンティティ対デバイス TID 外部エンティティをデバイスに対して強力にペアリングします。 デバイスへの接続が傍受されます。 デバイスとの通信が妨害されます。 外部エンティティをデバイスの NFC/Bluetooth LE に対して確実にペアリングします。 デバイス (物理) の操作パネルを制御します。
フィールド ゲートウェイ対クラウド ゲートウェイ TID TLS (PSK/RSA) によってトラフィックを暗号化します。 デバイスとゲートウェイとの間の通信を傍受または妨害します。 プロトコル レベルでセキュリティを確保します (MQTT/AMQP/HTTP/CoAP)。 カスタム プロトコルの場合は、その保護方法を把握する必要があります。
デバイス対クラウド ゲートウェイ TID TLS (PSK/RSA) によってトラフィックを暗号化します。 デバイスとゲートウェイとの間の通信を傍受または妨害します。 プロトコル レベルでセキュリティを確保します (MQTT/AMQP/HTTP/CoAP)。 カスタム プロトコルの場合は、その保護方法を把握する必要があります。

記憶域

次の表に、ストレージの脅威に対する軽減策の例を示します。

コンポーネント 脅威 軽減策 リスク 実装
デバイスの記憶域 TRID 記憶域を暗号化し、ログに署名します。 記憶域からデータが読み取られたり、テレメトリ データが改ざんされたりします。 キューやキャッシュに格納されたコマンド制御データが改ざんされます。 構成の更新パッケージやファームウェアの更新パッケージが、ローカルにキャッシュされるかローカルのキューに格納されている間に改ざんされた場合、OS やシステム コンポーネントのセキュリティ侵害につながる可能性があります 暗号化、メッセージ認証コード (MAC)、またはデジタル署名を導入します。 可能であれば、アクセス許可またはリソース アクセス制御リスト (ACL) を使った強力なアクセス制御を導入します。
デバイスの OS イメージ TRID OS が改ざんされたり、OS コンポーネントが差し替えられたりします。 OS パーティションの読み取り専用化、OS イメージの署名、暗号化を行います。
フィールド ゲートウェイの記憶域 (データのキューイング) TRID 記憶域を暗号化し、ログに署名します。 記憶域からデータが読み取られたり、テレメトリ データが改ざんされたりします。キューやキャッシュに格納されたコマンド制御データが改ざんされることもあります。 (デバイスまたはフィールド ゲートウェイに対する) 構成の更新パッケージやファームウェアの更新パッケージが、ローカルにキャッシュされるかローカルのキューに格納されている間に改ざんされた場合、OS やシステム コンポーネントのセキュリティ侵害につながる可能性があります BitLocker
フィールド ゲートウェイの OS イメージ TRID OS が改ざんされたり、OS コンポーネントが差し替えられたりします。 OS パーティションの読み取り専用化、OS イメージの署名、暗号化を行います。

次のステップ

IoT セキュリティの詳細については、次をご覧ください。