🛀🏽 🏂🏻 ♥️ IoTのセキュリティ：セキュリティアーキテクチャ 🌴 🐼 🌜

システムを設計するとき、このシステムがどのような脅威にさらされるかを理解し、そのアーキテクチャを設計および構築するときに適切なセキュリティ対策を開発することが重要です。製品を設計するとき、最初から安全要件を考慮することが特に重要です。攻撃者がシステムを侵害する方法を理解していれば、作業を開始する前に適切な対策を講じてリスクを軽減できます。

一連の記事「IoTのセキュリティ」

1. ゼロから始める人向けのAzure IoT Suite 。

2. 包括的な保護戦略。

3. セキュリティシステムアーキテクチャ。

4. Azure IoT展開のセキュリティ保護。

セキュリティの中心はリスクモデリングです。

リスクモデリングのタスクは、攻撃者がシステムを危険にさらす方法を正確に理解し、適切な手段を講じてリスクを軽減することです。リスクモデリングのおかげで、開発チームは、展開後ではなく、システム設計の段階でもリスクを軽減するための手段を想定できます。これは非常に重要です。社外の無数のデバイスでセキュリティシステムをアップグレードすることは技術的には不可能だからです。さらに、このアプローチにはエラーが多く、顧客をあらゆる種類のリスクから保護できません。

開発者は、システムの機能要件を特定および文書化するために積極的に取り組んでいます。これにより、ユーザーとの対話がさらに便利で効率的になります。ただし、攻撃者がシステムを危険にさらす可能性のある明白でない方法を特定することは、はるかに難しいタスクです。リスクモデリングにより、開発者は攻撃者が実行できるアクションと目的を正確に把握できます。この構造化されたプロセスでは、セキュリティシステムの設計上の決定と、実装段階でプロジェクトに加えられた変更が議論されます。これは、システムセキュリティに影響を与える可能性があります。リスクモデルは単なるドキュメントです。ただし、新しい専門家が新しい環境で即座にナビゲートできるようにするために、知識の継続的な転送を保証し、蓄積された経験を維持するための理想的な方法です。最後に、リスクモデリングのおかげで、セキュリティの他の側面も考慮することができます。たとえば、顧客に提供する準備ができているセキュリティのレベルを決定します。この文書化されたレベルは、リスクモデルと相まって、IoTソリューションのテストに必要なデータを提供します。

作成時間

リスクモデリングは、設計段階で直接実装された場合、多くの重大な利点を保証します。設計プロセス中に、脅威を排除するために変更を加えることができます。設計段階でのリスクの排除は、努力する必要がある結果です。これは、リスクを軽減し、その関連性を常に維持するための対策を導入してテストするよりもはるかに簡単で効果的です。製品の準備がほぼ完了した後の段階でリスクを排除することは、はるかに困難です。これには、より多くの作業が必要になり、特定の利点を犠牲にする必要があります。初期段階でリスクをモデリングすると、これを回避できます。

勉強するオブジェクト

ソリューション全体のリスクモデルを作成する必要があります。特に次の領域に注意してください。

セキュリティおよびプライバシーツール。
機能がセキュリティに依存する機能。
図の信頼の境界と接触している関数。

リスクをモデル化する方法

リスクモデリングは、他のプロセスと同じプロセスです。ソリューションの他のコンポーネントと同様に、リスクモデルを処理および検証することをお勧めします。開発者は、システムの機能要件の特定と文書化に積極的に取り組んでいます。これにより、ユーザーとの対話がさらに便利で効率的になります。ただし、攻撃者がシステムを危険にさらす可能性のある明白でない方法を特定することは、はるかに難しいタスクです。リスクモデリングにより、開発者は攻撃者が実行できるアクションと目的を正確に把握できます。

キーステージ

リスクモデリングプロセスは4つの段階で構成されます。

モデリングアプリケーション。
リスクの列挙。
リスク低減。
リスク低減策の検証。

モデリング手順

リスクモデルを作成する際には、次の3つの手順を踏む必要があります。

参照アーキテクチャに基づいてスキーマを作成します。
ワイド検索を開始します。結果を表示し、これまで詳細に進むことなく、システム全体を評価してみてください。したがって、詳細な分析に適した方向を選択できます。
プロセスを制御しますが、プロセスに制御させないでください。ただし、モデリング段階で問題を見つけてそれを調べたい場合は、それを実行してください。すべての推奨事項をきちんと守らないでください。

主な脅威

リスクモデルの4つの重要な要素：

プロセス（Webサービス、Win32サービス、* nix制御プログラムなど）。一部の複雑なオブジェクト（フィールドゲートウェイやセンサーなど）は、これらの領域を詳細に分析することが技術的に不可能な場合、プロセスとして抽象的に認識することができることに注意してください。
データストレージ（構成ファイルやデータベースなど、データが格納される場所）。
データフロー（アプリケーションの他の要素間のデータ移動ルート）。
外部オブジェクト（システムと対話しますが、ユーザーや衛星チャンネルなど、アプリケーションによって制御されないすべてのオブジェクト）。

アーキテクチャ図のすべての要素は、多かれ少なかれさまざまな脅威にさらされています。ニーモニックルールSTRIDEを使用します。

アプリケーション図のさまざまな要素は、さまざまなSTRIDE脅威の影響を受けます。

プロセスはSTRIDEの脅威にさらされます。
データストリームはTIDの脅威にさらされます。
データウェアハウスはTIDの脅威にさらされ、ログファイルの場合はRの脅威にさらされることもあります。
外部オブジェクトはSRDの脅威にさらされます。

IoTセキュリティ

接続された特殊なデバイスには、これらのデバイスへのデジタルアクセスを保護するための適切なシステムを開発する際に考慮しなければならない潜在的な相互作用の多くのポイントが含まれています。「デジタルアクセス」という用語は、物理的なアクセス制御によってセキュリティが確保されている場合、デバイスとの直接的な対話によって実行されるすべての操作を指します。たとえば、ロック可能な部屋にデバイスを配置できます。物理的なアクセスはソフトウェアとハードウェアによって拒否することはできませんが、物理的なアクセスがシステムに入るのを防ぐために特定の手段を講じることができます。

さまざまな相互作用メカニズムを研究するとき、デバイス管理とデバイス上のデータにも同様に注意を払う必要があります。デバイス管理は、デバイスの状態または環境の状態を変更するような方法でデバイスの動作に影響を与えるために、データ交換の参加者がデバイスに提供する情報として理解できます。デバイス上のデータは、デバイス自体が作成し、データ交換の別の参加者に提供する情報です。これは、デバイスのステータスとその環境の登録状態に関する情報です。

より高いレベルのセキュリティを提供するには、このリスクモデリングの一環として、標準IoTアーキテクチャをいくつかのコンポーネント（ゾーン）に分割することをお勧めします。これらには以下が含まれます。

装置
フィールドゲートウェイ。
クラウドゲートウェイ。
サービス。

ゾーニングは、ソリューションをセグメント化する普遍的な方法です。多くの場合、各ゾーンには独自のデータが含まれており、個別の認証要件と承認要件もあります。ゾーン分離を使用して、損傷の位置を特定し、信頼度の低いゾーンが信頼度の高いゾーンに及ぼす影響を制限できます。

各ゾーンは、下の図の赤い点線で示されている信頼境界線で区切られています。 1つのソースから別のソースへのデータ（情報）の遷移を表します。このような移行中に、データ（情報）は改ざん（S-なりすまし）、違法な変更（T-改ざん）、意味の歪み（R-否認）、情報漏えい（I-情報開示）、サービス拒否（D-拒否）の対象になる可能性がありますサービス）および特権の昇格（E-特権の昇格）。一緒に、これらすべての脅威を英語の単語の最初の文字を略語「STRIDE」と呼びます。

各境界内で指定されたコンポーネントもSTRIDEの脅威にさらされているため、特定のソリューションのリスクを詳細に完全にシミュレートできます。以下のセクションでは、これらの各コンポーネントと特定のセキュリティ問題、および推奨されるソリューションについて説明します。

デバイスゾーン

デバイス環境は、デバイスを直接取り囲む物理的な空間です。デバイス環境では、ローカルネットワークを介したデバイスへの物理アクセスおよび（または）ピアツーピアデジタルアクセスが提供されます。ローカルエリアネットワーク-パブリックインターネットから分離および分離されたネットワーク（ただし、ブリッジ接続を介して接続できる機能を備えています）。このようなネットワークには、デバイス間でピアツーピア接続が確立される短距離無線ネットワークが含まれます。このようなネットワークには、ローカルネットワークの錯覚を作り出す仮想化ネットワーク、または2つのデバイスがピアツーピア接続を確立するためにパブリックネットワーク空間でデータを交換すると想定されるフレームワーク内のオペレーターのパブリックネットワークは含まれません。

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

フィールドゲートウェイは、データ交換を実装する手段として機能するデバイス、ソフトウェア、または汎用サーバーソフトウェアであり、可能な限り、デバイス管理システムとデバイスから受信したデータセンターです。フィールドゲートウェイ自体には、フィールドゲートウェイ自体と、それに接続されているすべてのデバイスが含まれます。名前が示すように、フィールドゲートウェイは専用のデータセンターの外で動作します。通常、それらは場所によって制限され、物理的な侵入の対象になり、動作電力の供給が制限されます。したがって、フィールドゲートウェイは、実行する機能がわかっている場合に物理的に無効にできるデバイスです。

単純なトラフィックルーターとは異なり、フィールドゲートウェイはアクセス制御と情報ストリーミングで重要な役割を果たします。つまり、これは、アプリケーション、ネットワーク接続、またはセッション端末によってアクセスされるオブジェクトです。対照的に、NATデバイスとファイアウォールはフィールドゲートウェイではありません。これら自体は接続またはセッション端末として機能せず、ルート（ブロック）の接続またはルートであるためです。フィールドゲートウェイには、2つの個別の連絡先ゾーンが含まれています。それらの1つは接続されたデバイス（内部部分）と対話し、2番目はデータ交換の外部参加者と対話します。これは、本質的にゾーンの移行を表します。

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

クラウドゲートウェイは、さまざまなデバイスとフィールドゲートウェイ間でデータをリモートで交換するためのシステムです。原則として、データは、クラウドベースのデータ分析および制御システムのパブリックネットワーク上のさまざまなサイトから取得されます。これは、そのようなシステムのフェデレーションです。場合によっては、クラウドゲートウェイは、タブレットや電話などの端末から特殊なデバイスへの直接アクセスを提供できます。この記事では、「クラウド」という用語は、接続されたデバイスまたはフィールドゲートウェイと同じサイトに結び付けられていない特殊なデータ処理システムを指します。クラウドゾーンでは、意図的な物理的アクセスを防ぐための運用上の対策を講じることもできます。このゾーンは、パブリッククラウドインフラストラクチャの一部として提供されない場合があります。

クラウドゲートウェイを仮想化オーバーレイと照合して、クラウドゲートウェイと、それに接続されているすべてのデバイスまたはフィールドゲートウェイをネットワークトラフィックから分離できます。クラウドゲートウェイ自体は、デバイス管理システムでもデバイスのデータ処理システムでもストレージシステムでもありませんが、ゲートウェイはこれらすべてのシステムと相互作用します。クラウドゲートウェイゾーンには、クラウドゲートウェイ自体と、直接または間接的に接続されているすべてのフィールドゲートウェイとデバイスが含まれます。ゾーン移行は、データ交換のすべての外部参加者とのやり取りが実行される、明確に定義された連絡先ゾーンです。

サービスゾーン

サービスは、この記事のコンテキストでは、フィールドまたはクラウドゲートウェイを介してデバイスと対話し、データを収集および分析し、コマンドを監視および送信するソフトウェアコンポーネントまたはモジュールとして定義されます。サービスはメディエーターとして機能します。サービスは独自のIDを使用して、ゲートウェイや他のサブシステムと対話し、データを保存および分析し、運用データまたはスケジュールに基づいて自律的にデバイスにコマンドを送信します。また、許可されたエンドユーザーに必要な情報および制御ツールを提供します。

情報と専用デバイスの比較

コンピューター、電話、タブレットPCは、主にインタラクティブな情報デバイスに関連しています。電話とタブレットは、バッテリー寿命を最大化するために最適化されています。そのようなデバイスでは、ユーザーがデバイスを使用して音楽やGPSナビゲーションなどを再生するまでの期間、機能を部分的に無効にすることができます。システムの観点から、このような情報デバイスはユーザーと対話するときにプロキシとして機能します。これは、アクションに関しては「ユーザードライブ」であり、入力データの収集について話している場合は「ユーザーセンサー」です。

特殊な機器には、通常の温度センサーから数千の異なるコンポーネントで構成される複雑な工場生産ラインまで、さまざまなデバイスが含まれます。これらのデバイスは、より広範なアプリケーションを対象としています。また、ユーザーインターフェイスが提供されている場合でも、物理的な世界のリソースとの対話または統合の幅広い機能を実行します。環境の状態を分析し、関連するレポートを作成し、バルブをオンおよびオフにし、サーボモーターを制御し、サウンドアラートをアクティブにし、ライトをオンおよびオフにし、さらに多くのタスクを実行します。それらは、情報デバイスのタスクの範囲が普遍的すぎる、またはそのようなデバイスが高すぎる、大きすぎる、または十分に強くない仕事をするのに役立ちます。デバイスの技術設計は、特定のタスク、および生産に割り当てられる手頃な予算と計画寿命によって直接決定されます。これら2つの要因の組み合わせにより、運用中のエネルギー供給に割り当てられる予算が制限されます。物理的な影響と利用可能なストレージ、コンピューティング、およびセキュリティリソースも制限されています。

物理的な故障や制御ロジックの誤動作など、自動化されたデバイスまたはリモート制御されたデバイスに何かが発生した場合、意図的な不正侵入や詐欺行為につながる可能性があります。生産バッチが破壊されたり、建物が奪われたり、地面に焼けたり、人々が苦しんだり、死ぬことさえあります。もちろん、これは完全に異なるカテゴリーの損害であり、盗まれたクレジットカードの平凡な破壊とは大きく異なります。モノやオブジェクトを駆動するデバイス、およびセンサーデータは、さまざまなモノやオブジェクトを動作させるコマンドに変換されるため、商業システムや銀行システムよりも高いセキュリティ要件を満たす必要があります。

デバイス管理とデバイス上のデータとの相互作用

Azure IoTリファレンスアーキテクチャ：リスクモデリング

Microsoftは、上記の概念を使用して、Azure IoTのリスクをモデル化します。次のセクションでは、IoT環境でのリスクモデリングの原理を示し、検出された脅威を排除するために、Azure IoTリファレンスアーキテクチャの具体例を示します。この場合、4つの主要な領域を区別します。

デバイスとデータソース。
データ転送。
デバイスとイベント処理。
提出。

次の図は、Microsoft IoTリファレンスアーキテクチャを簡略化したものです。デモンストレーションには、Microsoftのリスクモデリングツールでも使用されるデータフロー図モデルを使用します。

デバイスとゲートウェイの機能はアーキテクチャ内で異なることを理解することが重要です。したがって、ユーザーはより信頼性が高く安全なゲートウェイを効果的に使用できます。ゲートウェイは、安全なプロトコルを介したクラウドゲートウェイとのデータ交換をサポートします。これには通常、独自のデバイス（サーモスタットなど）が提供できるよりも多くのオーバーヘッド処理が必要です。 Azureサービスゾーンでは、Azure IoT Hubサービスがクラウドゲートウェイとして機能すると想定されています。

デバイスとデータソース/データトランスポート

このセクションでは、リスクモデリングのコンテキストで上記のアーキテクチャを説明し、さまざまな関連問題の解決策を示します。リスクモデルのいくつかの重要な要素を詳細に検討します。

プロセス（ユーザー駆動型および外部要素）。
データ交換（いわゆるデータストリーム）。
ストレージ（いわゆるデータストレージ）。

プロセス

Azure IoTアーキテクチャで強調表示されている各カテゴリでは、データ（情報）の存在のさまざまな段階（プロセス、データ交換、ストレージ）でさまざまなリスクを軽減しようとしています。以下は、プロセスカテゴリの最も一般的なリスクの概要です。次に、これらのリスクを軽減する方法について説明します。

偽物（なりすまし） 攻撃者は、デバイスから暗号化キーマテリアルを（ソフトウェアまたはハードウェアレベルで）抽出し、このマテリアルが抽出されたデバイスのIDを使用して、別の物理デバイスまたは仮想デバイスからシステムにアクセスできます。最も顕著な例は、任意のテレビの電源を入れることができるリモートコントロールです。実際のジョークのファンがよく使用します。

サービス妨害 無線干渉または単にワイヤを切断することにより、デバイスが無効になるか、データ転送プロセスから除外される場合があります。たとえば、意図的に電源とネットワークから切断されたビデオ監視カメラは、データを送信しません。

違法な変更（改ざん） 。攻撃者は、デバイスで実行されているソフトウェアを完全または部分的に置き換えることができます。この場合、元のソフトウェアの代わりにインストールされたソフトウェアは、キーマテリアルまたはキーマテリアルを含む暗号化データへのアクセスがある場合、本物のデバイスIDを使用できます。たとえば、攻撃者は抽出されたキーマテリアルを使用して、通信パスを介してデバイスから送信されるデータをインターセプトおよびブロックし、盗まれたキーマテリアルを使用して認証される偽のデータに置き換えることができます。

情報開示 不正なソフトウェアがデバイスにインストールされている場合、これによりデータが漏洩し、権限のないユーザーに送信される可能性があります。たとえば、攻撃者は取得したキーマテリアルを使用して、デバイスとコントローラーまたはフィールド/クラウドゲートウェイ間の通信パスに侵入し、データ出力を開始できます。

特権の昇格 特定の機能を実行するデバイスは、他のアクションを強制的に実行できます。たとえば、180度開くようにプログラムされたバルブは、完全に開くように不正に構成できます。

成分	脅威	リスク低減	リスク	実装
装置	なりすまし	ID割り当てとデバイス認証	デバイスを別のデバイスと完全または部分的に交換するデバイスの正当性を判断する方法は？	TLSまたはIPSecを使用したデバイス認証。インフラストラクチャは、非対称暗号化処理がサポートされていないデバイスでの共有キーの使用をサポートする必要があります。 Azure AD、 OAuthを使用する
	TRID	デバイスを使用して違法な変更から保護し、キーやその他の暗号化資料を入手することを困難にするか、完全に不可能にすることができます	ただし、デバイスが物理的に違法に変更される危険があります。違法な変更からデバイスを保護するにはどうすればよいですか？	このような脅威のリスクを軽減する最も効果的な方法は、特別な組み込みチップにキーを保存できる信頼できるプラットフォームモジュールを使用することです。このようなスキームのデータは読み取ることができませんが、キーを公開せずに使用する暗号化操作に使用できます。デバイスメモリの暗号化。デバイスのキー管理。コード署名
	特権の昇格	デバイスへのアクセスを制御する。認可スキーム	デバイスが外部ソースまたは侵害されたセンサーから受信したコマンドに従って特定のアクションを実行することを許可されている場合、攻撃者はそれがなければ利用できない操作を実行できます	デバイスの認証スキームの取得
フィールドゲートウェイ	スプーフィング	クラウドゲートウェイと対話するときのフィールドゲートウェイ認証（証明書、共有キー、承認などに基づく）	攻撃者がフィールドゲートウェイを違法に変更した場合、任意のデバイスになりすますことができます。	TLS RSA /共有キー、IPSe、 RFC 4279 キーストレージと認証のガイドラインは同じままです。ワイヤレスセンサーネットワーク（WSN）をサポートするには、TPM拡張の使用をお勧めします。 IPSec用の6LowPAN
	TRID	違法な変更からフィールドゲートウェイを保護します（信頼できるプラットフォームモジュール）？	データ詐欺攻撃。その結果、クラウドゲートウェイは、フィールドゲートウェイとデータを交換していると誤って判断し、情報漏えいや違法なデータ変更につながります。	メモリ暗号化、トラステッドプラットフォームモジュール、認証
	特権の昇格	フィールドゲートウェイアクセス制御メカニズム

このカテゴリの脅威の例を以下に示します。

偽物攻撃者は、デバイスから暗号化キーマテリアルを（ソフトウェアまたはハードウェアレベルで）抽出し、このマテリアルが抽出されたデバイスのIDを使用して、別の物理デバイスまたは仮想デバイスからシステムにアクセスできます。

サービス妨害 。無線干渉または単にワイヤを切断することにより、デバイスが無効になるか、データ転送プロセスから除外される場合があります。たとえば、意図的に電源とネットワークから切断されたビデオ監視カメラは、データを送信しません。

違法な変更 。攻撃者は、デバイスで実行されているソフトウェアを完全または部分的に置き換えることができます。この場合、元のソフトウェアの代わりにインストールされたソフトウェアは、キーマテリアルまたはキーマテリアルを含む暗号化データへのアクセスがある場合、本物のデバイスIDを使用できます。

違法な変更 。空のロビーの画像を可視スペクトルで放送する監視カメラは、実際にこのロビーの静止写真だけを表示できます。煙探知機または火災探知機は、誰かがそれに照らされたマッチを持ってくるだけで機能します。いずれにせよ、デバイスは物理的に完全に信頼できますが、同時に詐欺師によって送信された誤った情報をシステムに通知します。

違法な変更 。たとえば、攻撃者は抽出されたキーマテリアルを使用して、通信パスを介してデバイスから送信されるデータをインターセプトおよびブロックし、盗まれたキーマテリアルを使用して認証される偽のデータに置き換えることができます。

違法な変更 。攻撃者は、デバイスで実行されているソフトウェアを完全または部分的に置き換えることができます。この場合、元のソフトウェアの代わりにインストールされたソフトウェアは、キーマテリアルまたはキーマテリアルを含む暗号化データへのアクセスがある場合、本物のデバイスIDを使用できます。

情報の開示 。不正なソフトウェアがデバイスにインストールされている場合、これによりデータが漏洩し、権限のないユーザーに送信される可能性があります。

情報の開示 。たとえば、攻撃者は抽出されたキーマテリアルを使用して、デバイスとコントローラーまたはフィールド/クラウドゲートウェイ間の通信パスに侵入し、データ出力を開始できます。

サービス妨害 。デバイスをオフにするか、データ交換が不可能なモードにすることができます（これは特に多くの生産工場で行われます）。

違法な変更 。デバイス構成を変更して、制御システムに未知の状態を割り当てることができます（既知のキャリブレーションパラメーターの範囲外）。したがって、誤って解釈されるデータをデバイスから受信できます。

特権昇格 。特定の機能を実行するデバイスは、他のアクションを強制的に実行できます。たとえば、180度開くようにプログラムされたバルブは、完全に開くように不正に構成できます。

サービス妨害 。デバイスをデータ交換が不可能な状態にすることができます。

違法な変更 。デバイス構成を変更して、制御システムに未知の状態を割り当てることができます（既知のキャリブレーションパラメーターの範囲外）。したがって、誤って解釈されるデータをデバイスから受信できます。

偽物/不法な変更/意味のゆがみ 。デバイスが保護されていない場合（たとえば、リモートコントロールに保護がほとんど使用されない場合など）、攻撃者は匿名でデバイスの状態を変更できます。最も顕著な例はリモートコントロールで、これを使用して任意のテレビの電源を入れることができます。これは実際のジョークのファンによってよく使用されます。

データ交換

異なるデバイス間、デバイスとフィールドゲートウェイ間、およびデバイスとクラウドゲートウェイ間のデータ転送の通信パスに関連する脅威。次の表に、デバイス/ VPNでオープンソケットを設定するためのガイドラインを示します。

成分	脅威	リスク低減	リスク	実装
デバイス上のIoT Hubサービス	ティッド	（D）トラフィック暗号化用のTLS（共有キー/ RSA）	デバイスとゲートウェイ間の通信をリッスンまたは妨害する	プロトコルレベルでのセキュリティ。カスタムプロトコルを使用する場合は、それらを保護する最適な方法を構成する必要があります。ほとんどの場合、データはデバイスからIoT Hubサービスに交換されます（接続はデバイスによって開始されます）
デバイス//デバイス	ティッド	（D）トラフィック暗号化用のTLS（共有キー/ RSA）	デバイス間の転送中のデータの読み取り。不正なデータ変更。新しい接続でデバイスをオーバーロードする	プロトコルレベルのセキュリティ（HTTP（S）/ AMQP / MQTT / CoAP）。カスタムプロトコルを使用する場合は、それらを保護する最適な方法を構成する必要があります。 DOS攻撃のリスクを減らすために、ネットワーク上のクライアントとしてのみ設定されているクラウドまたはフィールドゲートウェイを使用して、デバイスのピアツーピア通信を設定できます。この場合、ゲートウェイが仲介者として機能した後、ピアデバイス間で直接通信を確立できます。
デバイス//外部オブジェクト	ティッド	デバイスへの外部オブジェクトの安定したバインディング	デバイスとの接続を聞いています。デバイスの通信を妨げる	外部オブジェクトをNFC / Bluetooth LEデバイスに安全に関連付けます。デバイスダッシュボードコントロール（物理）
フィールドゲートウェイ//クラウドゲートウェイ	ティッド	トラフィック暗号化用のTLS（共有キー/ RSA）	デバイスとゲートウェイ間の通信をリッスンまたは妨害する	プロトコルレベルのセキュリティ（HTTP（S）/ AMQP / MQTT / CoAP）。カスタムプロトコルを使用している場合は、それらに最適な保護方法を構成する必要があります。
デバイス//クラウドゲートウェイ	ティッド	トラフィック暗号化用のTLS（共有キー/ RSA）	デバイスとゲートウェイ間の通信をリッスンまたは妨害する	プロトコルレベルのセキュリティ（HTTP（S）/ AMQP / MQTT / CoAP）。カスタムプロトコルを使用している場合は、それらに最適な保護方法を構成する必要があります。

このカテゴリの脅威の例を以下に示します。

サービス妨害 。 , , DOS- : , . . .

, . (, PIN-) ( , , ). , , .

. , ().

. , .

. .

. .

保管

( , ).

成分				実装
	TRID	,	( PII), . , . ()	, (MAC) . (ACL)
	TRID		/	« », ,
(	TRID	,	( PII), , , . ( ) ()	BitLocker
	TRID		/	« », ,

/

. , , , . , . , «» , , , . . , . , , . , , .

, , (, , ). , . SDL .

() — , , , () , . — , , . , , , , , .

, . , , , , , . . Cloud Security Alliance (CSA).

便利な資料

1. .

2. Azure IoT Suite: .

3. GitHub .

翻訳に誤りがある場合は、プライベートメッセージで報告してください。

IoTのセキュリティ：セキュリティアーキテクチャ