セキュアなモデリングの最良事例
ThingWorx でセキュアなモデルを設定することは、モデル開発における最も重要な手順の 1 つで、ユーザーがモデル内の資産に対して正しいアクセス権を持ち、すべての手順でセキュリティへの影響が考慮されるようにします。Edge セキュリティの管理は、このプロセスの重要な要素です。ThingWorx では、次の操作によって Remote Thing に詳細なアクセス許可を設定する必要があります。
• Remote Thing を表す一意のユーザーを作成する
• ユーザーを正しい組織に割り当てる
• 一意のユーザーコンテキストで一意のアプリケーションキーを作成する
 |
アプリケーションでファイルアップロード機能を使用している場合、適切なアクセス権を持つユーザーは、あらゆるタイプのファイルコンテンツをシステムにアップロードできることに注意してください。PTC は、アップロードされたファイルが安全で、信頼されたユーザーからの入力であることを保証しません。
|
このトピックの情報は、モデル内にセキュリティを設定する際にやってはならないことと、モデルをできるかぎりセキュアに設定するための最良事例についてのヒントを提供するものです。
Edge セキュリティの管理
Edge セキュリティの管理は、モデルの構築から始まりセキュアな展開へと続くモデルのセキュリティ保護における重要な要素です。Edge とは、ThingWorx (Composer) 内のモデリング環境と外部データソースの間のバリアのことです。ThingWorx で Edge のセキュリティを管理する方法は多数あり、その 1 つに Edge とプラットフォームの間での通信に TLS/SSL 通信を使用する方法があります。TLS/SSL を使用すると、次の結果が得られます。
◦ Remote Thing は証明書によってサーバーを検証します。
◦ トラフィックは TLS を使用して暗号化されます。
◦ アプリケーションキーはプラットフォームに対して Remote Thing を認証し、アプリケーションキーに関連付けられたユーザーコンテキストによってプラットフォーム内のアクセスが制限されます。
避けるべき事例
Edge をできるだけセキュアな状態にするために実行できる手順がある一方、システム全体のセキュリティを低下させる事例もあります。これらの事例は、以下のとおりです。
• SSL をオフにすること。これは推奨されません。携帯電話であっても、特定のネットワークにはそのセキュリティアーキテクチャに既知の欠陥が存在します。
• 既知の脆弱性のあるハッシュを含む証明書を使用すること。
◦ MD5、SHA1 などは使用しないでください。推奨される NIST のいずれかを使用してください。
◦ 開発以外で、自己署名の証明書を使用しないでください。
• 複数のデバイスに同じアプリケーションキーを使用すること。接続はアプリケーションキーを使用して認証されます。アプリケーションキーがデバイス全体において一意でない場合、接続全体で、偽装されたまたは悪意のある接続を監査することが困難になります。
• アクセス許可の範囲が広いアプリケーションキーを使用すること。付与してはならない人に、資産へのアクセス権が付与されてしまう可能性があります。
使用事例
• 信頼された証明機関を使用します。
• クライアント認証 (Mutual TLS) を使用します。
|
|
このテクノロジの実装はシステムインテグレータが担当します。実装の詳細については、C SDK Users Guide を参照してください。
|
• アプリケーションキーを使用します。アプリケーションキーと ThingWorx ユーザーを設定する場合には、常に最小限の権限を付与するようにします。管理者グループのメンバーをアプリケーションキーに割り当てることは最良事例ではありません。
モデルの設定
アプリケーションのセキュリティを十分に確保するには、次の原則を使用するセキュリティ保護が常に最良事例となります。
• 最小限の権限を付与すること
• 深層的な防御
• セキュアなデフォルト値
1. 組織を設定する
エッジデバイスのセキュアなモデル構築の最初の手順は、組織を使用して、エンティティに適切な表示を設定することです。組織により、アプリケーションへの適切なアクセス権持つユーザーに対して、システム全体の表示を設定できます。
2. ユーザーグループを設定する
ユーザー役割に基づくアクセス制御を作成するために、ユーザーグループを設定します。
|
|
ThingWorx では、複数の定義済みのユーザーグループを使用できます。詳細については、ユーザーグループを参照してください。
|
3. ユーザーを設定する
ユーザーにより、データへのアクセスを細分化できます。組織およびユーザーグループの設定後、プラットフォームで一意に許容されるエンティティごとに 1 人のユーザーを作成する必要があります。Edge の観点から言えば、プラットフォームに接続するエッジデバイスごとに 1 人のユーザーを作成することになります。
4. アプリケーションキーを設定する
アプリケーションキーはプラットフォームによりセキュアにアクセスするために使用され、アクセス許可を決定するユーザーコンテキストにリンクされます。接続するエッジデバイスごとに 1 つのアプリケーションキーを作成します。アプリケーションキーとユーザー/デバイスの比率は 1:1 にする必要があります。
5. Remote Thing を設定する: 表示、デザインタイムおよびランタイムのアクセス許可
Remote Thing の作成後、最初に設定するセキュリティコンテキストは表示です。表示は組織および組織単位に影響します。
次に、デザインタイムのアクセス許可を設定します。デザインタイムのアクセス許可は、アプリケーション内の動作およびモデルの修正を担当する信頼できるユーザーのみに付与する必要があります。つまり、通常は、ユーザー/デバイスにはデザインタイムのアクセス許可が与えられないことになります。デバイスがそれ自体の動作を修正できるようにしてはならないからです。
最後に、デバイスを表すユーザーにランタイムのアクセス許可を設定して、デバイスがアプリケーションに機能的に貢献できるようにします。細分化にはランタイムのアクセス許可が重要です。少なくとも、特定のユーザーが特定の Thing のみにアクセスできるように、ランタイムのアクセス許可を設定します。必要に応じて、さらなる細分化をプロパティで設定できます。
モデルの設定のための追加のヒント
• 最良事例として、ビジネスクリティカルなアプリケーションで不具合が発生しないように、本番環境ではランタイムのアクセス許可をすべて除去することをお勧めします。アプリケーションの検証が正常に行われた後にのみ、すべての設計がサンドボックス内で実装および検証され、本番環境に展開されなければなりません。
• ユーザー、アプリケーションキー、Remote Thing はプログラムで作成できますが、この機能を実装するために作成されるサービスはすべて、アプリケーションのセキュリティモデル内で厳密に制御され、前のセクションで説明されているガイダンスを厳守している必要があります。
• 同じ EMS または SDK を介して接続している 2 つの Edge Thing がある場合、1 つのアプリケーションキーを各 Edge Thing に割り当てることはできません。これらのデバイスのアクセス許可モデルを分離しなければならない場合は、接続のエンドポイントごとに別々のセキュリティコンテキストを設定するために、別々の SDK を介して接続された状態にすることをお勧めします。
• Remote Thing ごとに複数のデータソースを必要とするアプリケーションがある場合、または複数のユーザーがマッシュアップから同じ Thing の異なるデータソースにアクセスしている場合、ランタイムアクセス許可を個々のプロパティおよびサービスで設定できます。
• データストレージタイプのエンティティ (Wiki、ブログ、データテーブル、ストリーム、値ストリーム) を操作している場合、プラットフォームサブシステムの GetDefaultDataPersistenceProviderName サービスに対するサービス実行のアクセス許可を付与することをお勧めします。データストレージタイプの新規 Thing を作成するには、システム内で 1 つ以上の永続化プロバイダの表示権限を持っていなければなりません。
|
|
表示アクセス許可のチェックは、RemoteThing インスタンスで有効にできます。これは、エッジデバイスをバインドするために使用されるアプリケーションキーユーザーに Remote Thing に対する表示アクセス許可が付与されているかどうかをチェックします。詳細については、RemoteThing の表示アクセス許可の設定を参照してください。
|