セキュリティフレーム:承認 | 対応策

[アーティクル]
06/01/2023

製品/サービス	[アーティクル]
コンピューターの信頼の境界	デバイス上のデータへの未承認アクセスを制限する適切な ACL が構成されていることを確認するユーザー固有の機密アプリケーションコンテンツがユーザープロファイルディレクトリに保存されていることを確認するデプロイされたアプリケーションが最小権限で実行されていることを確認する
Web アプリケーション	ビジネスロジックのフローを連続した順序で実施する列挙を防ぐレート制限メカニズムを実装する適切な承認確認を設定して、最小権限の原則に従うビジネスロジックとリソースのアクセスの承認は、受信要求パラメーターに基づいて判断しないコンテンツとリソースが列挙不可能であること、または強制的ブラウズでアクセスできないことを確認する
[データベース]	最小権限のアカウントを使用して Database サーバーに接続していることを確認するテナントがお互いのデータにアクセスできないように行レベルセキュリティの RLS を実装する Sysadmin ロールには必要かつ有効なユーザーのみを割り当てる
IoT クラウドゲートウェイ	最小権限のトークンを使用してクラウドゲートウェイに接続する
Azure Event Hub	送信専用のアクセス許可 SAS キーを使用してデバイストークンを生成する Event Hub への直接アクセスを提供するアクセストークンは使用しない必要最小限のアクセス許可が付与されている SAS キーを使用して Event Hub に接続する
Azure Document DB	可能な限りリソーストークンを使用して Azure Cosmos DB に接続する
Azure の信頼の境界	Azure RBAC を使用して Azure サブスクリプションへのアクセスをきめ細かく管理する
Service Fabric の信頼の境界	Azure RBAC を使用してクラスター操作へのクライアントのアクセスを制限する
Dynamics CRM	必要に応じて、セキュリティのモデリングを実行し、フィールドレベルのセキュリティを使用する
Dynamics CRM ポータル	ポータルのセキュリティモデルとその他の CRM が異なることを念頭に置きながら、ポータルアカウントのセキュリティモデルを実行する
Azure ストレージ	Azure Table Storage のエンティティの範囲で詳細なアクセス許可を付与する Azure Resource Manager を使用して、Azure ストレージアカウントへの Azure のロールベースのアクセス制御 (Azure RBAC) を有効にする
モバイルクライアント	暗黙的な脱獄または root 化検出を実装する
WCF	WCF での脆弱なクラス参照 WCF - 承認コントロールを実装する
Web API	ASP.NET Web API で適切な承認メカニズムを実装する
IoT デバイス	さまざまなアクセス許可レベルを必要とする各種アクションをデバイスがサポートしている場合は、デバイスで承認チェックを実行する
IoT フィールドゲートウェイ	さまざまなアクセス許可レベルを必要とする各種アクションをデバイスがサポートしている場合は、フィールドゲートウェイで承認チェックを実行する

デバイス上のデータへの未承認アクセスを制限する適切な ACL が構成されていることを確認します

タイトル	詳細
コンポーネント	コンピューターの信頼の境界
SDL フェーズ	デプロイ
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
手順	デバイス上のデータへの未承認アクセスを制限する適切な ACL が構成されていることを確認します

ユーザー固有の機密アプリケーションコンテンツがユーザープロファイルディレクトリに保存されていることを確認する

タイトル	詳細
コンポーネント	コンピューターの信頼の境界
SDL フェーズ	デプロイ
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
手順	ユーザー固有の機密アプリケーションコンテンツが、ユーザープロファイルディレクトリに保存されていることを確認します。これによりコンピューター上の複数のユーザーがお互いのデータにアクセスできなくなります。

デプロイされたアプリケーションが最小権限で実行されていることを確認する

タイトル	詳細
コンポーネント	コンピューターの信頼の境界
SDL フェーズ	デプロイ
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
手順	デプロイされたアプリケーションが最小権限で実行されていることを確認します。

ビジネスロジックのフローを連続した順序で実施する

タイトル	詳細
コンポーネント	Web アプリケーション
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
手順	これが正規ユーザーによって実行されたことを確認するには、ビジネスロジックのフローが連続した順序でのみ実施されるようにアプリケーションを指定します。すべての手順が現実的な人間の活動時間に処理されている必要があり、処理順序がランダムだったり、手順が省略されていたり、他のユーザーが処理した手順があったり、トランザクション送信が早すぎたりしてはいけません。

列挙を防ぐレート制限メカニズムを実装する

タイトル	詳細
コンポーネント	Web アプリケーション
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
手順	重要な識別子は必ずランダムにします。匿名ページに CAPTCHA コントロールを実装してください。エラーと例外によって特定のデータが表示されないようにします

適切な承認確認を設定して、最小権限の原則に従う

タイトル	詳細
コンポーネント	Web アプリケーション
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
手順	最小権限の原則とは、ユーザーアカウントに対して、そのユーザーにとって必要な権限のみを付与することです。たとえば、バックアップユーザーはソフトウェアをインストールする必要がありません。このため、バックアップアプリケーションとバックアップ関連のアプリケーションを実行する権限のみが付与されます。それ以外の権限 (新しいソフトウェアをインストールする権限など) は付与されません。この原則は、通常のユーザーアカウントで作業している個人のコンピューターユーザーにも当てはまり、絶対に必要な状況でのみ、パスワードで保護された管理者アカウント (つまりスーパーユーザーアカウント) が割り当てられます。この原則は、Web アプリケーションにも適用できます。つまり、セッションを使用するロールベースの認証方法だけを使用するのではなく、データベース認証システムによって権限をユーザーに割り当てます。ユーザーが適切にログインしているかどうかの確認には引き続きセッションを使用しますが、ユーザーに特定のロールを割り当てるのではなく、システムで実行できるアクションを確認するための権限を割り当てます。また、この方法の大きなメリットは、ユーザーに低い権限を割り当てる必要がある場合、割り当てがセッションに依存していないため、セッションが期限切れになるのを待つ必要がなく、変更が直ちに適用される点です。

ビジネスロジックとリソースのアクセスの承認は、受信要求パラメーターに基づいて判断しない

タイトル	詳細
コンポーネント	Web アプリケーション
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
手順	ユーザーがデータの確認しか行えないように制限されているかどうかをチェックするときは必ず、サーバー側でアクセス制限を処理する必要があります。 userID は、ログイン時にセッション変数内に保存し、データベースからユーザーデータを取得するときに使用します

例

SELECT data 
FROM personaldata 
WHERE userID=:id < - session var

これでデータを取得するための識別子がサーバー側で処理されるようになり、攻撃者がアプリケーションの操作を改ざんおよび変更できなくなりました。

コンテンツとリソースが列挙不可能であること、または強制的ブラウズでアクセスできないことを確認する

タイトル	詳細
コンポーネント	Web アプリケーション
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
手順	機密性の高い静的な構成ファイルは Web ルートに保持しないでください。公開する必要のないコンテンツについては、適切なアクセス制御を適用するか、コンテンツ自体を削除します。また、強制的ブラウズとブルートフォース手法は通常組み合わせて使用され、サーバー上のディレクトリとファイルを列挙するために、できるだけ多くの URL へのアクセスを試み、情報を収集します。攻撃者は、一般的なファイルすべてのバリエーションを調べることができます。たとえば、パスワードファイルの検索については、psswd.txt、password.htm、password.dat などのファイルのバリエーションが対象となります。これを防ぐには、ブルートフォース試行を検出する機能を追加します。

最小権限のアカウントを使用して Database サーバーに接続していることを確認する

タイトル	詳細
コンポーネント	データベース
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	SQL 権限の階層、SQL セキュリティ保護可能なリソース
手順	最小権限のアカウントを使用してデータベースに接続します。アプリケーションのログインはデータベース内に制限し、選択したストアドプロシージャのみを実行します。アプリケーションのログインには、直接テーブルアクセスは含まれません。

テナントがお互いのデータにアクセスできないように行レベルセキュリティの RLS を実装する

タイトル	詳細
コンポーネント	データベース
SDL フェーズ	Build
適用できるテクノロジ	SQL Azure、OnPrem
属性	SQL バージョン - V12、SQL バージョン - MsSQL2016
参照	SQL Server の行レベルのセキュリティ (RLS)
手順	行レベルのセキュリティを使用すると、クエリを実行しているユーザーの特性 (たとえば、グループメンバーシップや実行コンテキストなど) に基づいて、データベーステーブル内の行へのアクセスを制御できます。 Row-Level Security (RLS) は、アプリケーションでセキュリティの設計やコーディングを簡略化します。 RLS を使用すると、データ行のアクセスに対して制限を実装できます。たとえば、ワーカーが自分の部署に関連するデータ行にのみアクセスできるようにしたり、顧客のデータアクセスをその顧客の会社のデータにのみ制限したりできます。アクセスの制限のロジックは、別のアプリケーション層のデータから離れてではなく、データベース層にあります。任意の層からデータへのアクセスが試行されるたびに、データベースシステムにはアクセス制限が適用されます。これによりセキュリティシステムの侵入口が減り、そのシステムの信頼性と堅牢性が向上します。

そのまま使用できるデータベース機能としての RLS は、SQL Server 2016 以降、Azure SQL Database、および SQL Managed Instance にのみ適用できます。そのまま使用できる RLS 機能が実装されていない場合、データアクセスはビューとプロシージャの使用に制限されます

Sysadmin ロールには必要かつ有効なユーザーのみを割り当てる

タイトル	詳細
コンポーネント	データベース
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	SQL 権限の階層、SQL セキュリティ保護可能なリソース
手順	SysAdmin 固定サーバーロールには限られたメンバーのみを割り当て、アプリケーションで使用されるアカウントは追加しないようにします。ロールのユーザーの一覧を確認し、不要なアカウントはすべて削除してください

最小権限のトークンを使用してクラウドゲートウェイに接続する

タイトル	詳細
コンポーネント	IoT クラウドゲートウェイ
SDL フェーズ	デプロイ
適用できるテクノロジ	ジェネリック
属性	ゲートウェイの選択 - Azure IoT Hub
参照	IoT Hub Access Control
手順	クラウドゲートウェイ (IoT Hub) に接続するさまざまなへのコンポーネントに、最小権限のアクセス許可を付与します。代表的な例として、デバイスの管理/プロビジョニングコンポーネントでは registryread/write が、イベントプロセッサ (ASA) では Service Connect が使用されています。個別のデバイスは、デバイスの資格情報を使用してを接続されます

送信専用のアクセス許可 SAS キーを使用してデバイストークンを生成する

タイトル	詳細
コンポーネント	Azure Event Hub
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	Event Hubs の認証とセキュリティモデルの概要
手順	SAS キーは、個別のデバイストークンを生成するときに使用します。特定の発行元に対してデバイストークンを生成中は、送信専用のアクセス許可 SAS キーを使用してください

Event Hub への直接アクセスを提供するアクセストークンは使用しない

タイトル	詳細
コンポーネント	Azure Event Hub
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	Event Hubs の認証とセキュリティモデルの概要
手順	イベントハブへの直接アクセスを許可するトークンはデバイスに付与しないでください。発行元へのアクセスのみを提供する最小特権のトークンをデバイスに対して使用すると、そのデバイスを特定し、それが悪意のあるデバイスまたは侵害されたデバイスであることがわかったときに禁止できます。

必要最小限のアクセス許可が付与されている SAS キーを使用して Event Hub に接続する

タイトル	詳細
コンポーネント	Azure Event Hub
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	Event Hubs の認証とセキュリティモデルの概要
手順	Event Hub に接続するさまざまなバックエンドアプリケーションに、最小権限のアクセス許可を付与します。バックエンドアプリケーションごとに個別の SAS キーを生成し、必要なアクセス許可 (送信、受信、または管理) のみをそのキーに提供してください。

可能な限りリソーストークンを使用して Azure Cosmos DB に接続する

タイトル	詳細
コンポーネント	Azure Document DB
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
手順	リソーストークンは、Azure Cosmos DB アクセス許可のリソースに関連付けられていて、データベースのユーザーと、ユーザーが持つ特定の Azure Cosmos DB アプリケーションのリソース (コレクション、ドキュメントなど) へのアクセス許可の間のリレーションシップをキャプチャします。クライアントにマスターキーや読み取り専用キーを知らせたくない場合、たとえば、クライアントがモバイルクライアント、デスクトップクライアントなどのエンドユーザーアプリケーションの場合は、常にリソーストークンを使用して Azure Cosmos DB にアクセスします。マスターキーや読み取り専用キーは、こうしたキーを安全に格納できるバックエンドアプリケーションから使用してください。

Azure RBAC を使用して Azure サブスクリプションへのアクセスをきめ細かく管理する

タイトル	詳細
コンポーネント	Azure の信頼の境界
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	Azure サブスクリプションリソースへのアクセスを管理するための Azure ロールの割り当て
手順	Azure のロールベースのアクセス制御 (Azure RBAC) を使用すると、Azure のきめ細かなアクセス管理が可能になります。 Azure RBAC を使用すると、職務に必要な範囲のアクセス権だけをユーザーに付与することができます。

Service Fabric RBAC を使用してクラスター操作へのクライアントのアクセスを制限する

タイトル	詳細
コンポーネント	Service Fabric の信頼の境界
SDL フェーズ	デプロイ
適用できるテクノロジ	ジェネリック
属性	環境 - Azure
参照	Service Fabric のロールベースのアクセス制御 (Service Fabric クライアント用)
手順	Azure Service Fabric では、Service Fabric クラスターに接続されるクライアントのために、管理者用とユーザー用の 2 つの異なるアクセスコントロールの種類がサポートされています。アクセス制御を使用すると、クラスター管理者は、ユーザーのグループごとに特定のクラスター操作へのアクセスを制限して、クラスターのセキュリティを強化できます。管理者には、管理機能へのフルアクセス権 (読み取り/書き込み機能など) があります。ユーザーには、既定で管理機能 (クエリ機能など) と、アプリケーションとサービスを解決する機能への読み取りアクセス権のみがあります。クラスターの作成時に、2 つのクライアントロール (管理者とクライアント) を指定し、それぞれに個別の証明書を設定します。

必要に応じて、セキュリティのモデリングを実行し、フィールドレベルのセキュリティを使用します

タイトル	詳細
コンポーネント	Dynamics CRM
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
手順	必要に応じて、セキュリティのモデリングを実行し、フィールドレベルのセキュリティを使用します

ポータルのセキュリティモデルとその他の CRM が異なることを念頭に置きながら、ポータルアカウントのセキュリティモデルを実行します

タイトル	詳細
コンポーネント	Dynamics CRM ポータル
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
手順	ポータルのセキュリティモデルとその他の CRM が異なることを念頭に置きながら、ポータルアカウントのセキュリティモデルを実行します

Azure Table Storage のエンティティの範囲で詳細なアクセス許可を付与する

タイトル	詳細
コンポーネント	Azure Storage
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	StorageType - テーブル
参照	SAS を使用して Azure ストレージアカウントのオブジェクトへのアクセスを委任する方法
手順	ビジネスシナリオによっては、さまざまな関係者に対応した機密データ (さまざまな国/地域に関連する機密データなど) を、Azure Table Storage に格納しなければならないことがあります。このような場合は、パーティションと行キー範囲を指定することで SAS 署名を構成し、ユーザーが、国/地域固有のデータにアクセスできるようにします。

Azure Resource Manager を使用して、Azure ストレージアカウントへの Azure のロールベースのアクセス制御 (Azure RBAC) を有効にする

タイトル	詳細
コンポーネント	Azure Storage
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	Azure ロールベースのアクセス制御 (Azure RBAC) を使用して、ストレージアカウントをセキュリティで保護する方法
手順	新しいストレージアカウントを作成するときに、クラシックまたは Azure Resource Manager のデプロイモデルを選択します。 Azure にリソースを作成するクラシックモデルでは、サブスクリプション (つまりストレージアカウント) に対するオールオアナッシング形式のアクセス権のみを許可します。 Azure Resource Manager モデルでは、Microsoft Entra ID を使用して、リソースグループにストレージアカウントを追加し、特定のストレージアカウントの管理プレーンに対するアクセス権を制御します。たとえば、ストレージアカウントキーへのアクセス権を特定のユーザーに付与し、他のユーザーはそのストレージアカウントに関する情報を読み取ることはできても、ストレージアカウントキーにはアクセスでないようにすることができます。

暗黙的な脱獄または root 化検出を実装する

タイトル	詳細
コンポーネント	モバイルクライアント
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
手順	携帯電話が root 化または脱獄された場合に備えて、アプリケーションは独自の構成およびユーザーデータを保護する必要があります。 root 化/脱獄は未承認のアクセスを意味し、通常のユーザーが自身の携帯電話で行うことはありません。したがって、アプリケーションには、アプリケーション起動時に携帯電話が root 化されたかどうかを検出する暗黙的な検出ロジックが必要です。この検出ロジックは、通常は root ユーザーのみがアクセスできる次のようなファイルに、アクセスできるだけです。 /system/app/Superuser.apk /sbin/su /system/bin/su /system/xbin/su /data/local/xbin/su /data/local/bin/su /system/sd/xbin/su /system/bin/failsafe/su /data/local/su このファイルのいずれかにアプリケーションがアクセスできる場合、そのアプリケーションは root ユーザーとして実行されています。

WCF での脆弱なクラス参照

タイトル	詳細
コンポーネント	WCF
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック、NET Framework 3
属性	該当なし
参照	MSDN、Fortify Kingdom
手順	脆弱なクラス参照が使用されているため、攻撃者が未承認コードを実行できる可能性があります。プログラムが参照するのは、一意に識別されていないユーザー定義のクラスです。この厳密に識別されていないクラスが .NET によって読み込まれると、CLR 型ローダーは、指定した順序で次の場所にあるクラスを検索します。アセンブリの種類がわかっている場合、ローダーは構成ファイルのリダイレクト場所、GAC、構成ファイルを使用している現在のアセンブリ、およびアプリケーションベースディレクトリを検索しますアセンブリがわからない場合、ローダーは現在のアセンブリ、mscorlib、および TypeResolve イベントハンドラーによって返される場所を検索しますこの CLR 検索順序は、Type Forwarding メカニズム、AppDomain.TypeResolve イベントなどのフックで変更できます攻撃者が、同じ名前のクラスを別に作成して、CLR が最初に読み込む代替場所に配置することにより CLR 検索順序を悪用すると、攻撃者によって提供されたコードが CLR によって意図せずに実行されます

例

以下の WCF 構成ファイルの <behaviorExtensions/> 要素は、カスタム動作クラスを、特定の WCF 拡張機能に追加するよう WCF に指示します。

<system.serviceModel>
    <extensions>
        <behaviorExtensions>
            <add name=""myBehavior"" type=""MyBehavior"" />
        </behaviorExtensions>
    </extensions>
</system.serviceModel>

完全修飾名 (厳密な名前) を使用することで型が一意に識別され、システムのセキュリティが強化されます。 machine.config ファイルと app.config ファイルに型を登録するときに、完全修飾アセンブリ名を使用します。

例

以下の WCF 構成ファイルの <behaviorExtensions/> 要素は、厳密に参照されるカスタム動作クラスを、特定の WCF 拡張機能に追加するよう WCF に指示します。

<system.serviceModel>
    <extensions>
        <behaviorExtensions>
            <add name=""myBehavior"" type=""Microsoft.ServiceModel.Samples.MyBehaviorSection, MyBehavior,
            Version=1.0.0.0, Culture=neutral, PublicKeyToken=null"" />
        </behaviorExtensions>
    </extensions>
</system.serviceModel>

WCF - 承認コントロールを実装する

タイトル	詳細
コンポーネント	WCF
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック、NET Framework 3
属性	該当なし
参照	MSDN、Fortify Kingdom
手順	このサービスでは、承認コントロールが使用されません。クライアントが特定の WCF サービスを呼び出すと、WCF は、呼び出し元に、サーバーでサービスメソッドを実行する権限が付与されていることを確認するさまざまな承認スキームを提供します。承認コントロールが WCF サービスに対して有効でない場合は、認証されたユーザーが、権限の昇格を実行できます。

例

次の構成では、サービスを実行するときに、クライアントの認証レベルを確認しないよう WCF に指示します。

<behaviors>
    <serviceBehaviors>
        <behavior>
            ...
            <serviceAuthorization principalPermissionMode=""None"" />
        </behavior>
    </serviceBehaviors>
</behaviors>

そして、サービスの承認スキームを使用して、サービスメソッドの呼び出し元によるこの操作の実行が許可されていることを確認します。 WCF には 2 つのモードが用意されています。この WCF により、カスタム承認スキームの定義が許可されます。 UseWindowsGroups モードでは Windows のロールとユーザーを、UseAspNetRoles モードでは、SQL Server などの ASP.NET ロールプロバイダーを使用して、認証を行います。

例

次の構成では、追加サービスを実行する前に、クライアントが Administrators グループに含まれていることを確認するよう WCF に指示します。

<behaviors>
    <serviceBehaviors>
        <behavior>
            ...
            <serviceAuthorization principalPermissionMode=""UseWindowsGroups"" />
        </behavior>
    </serviceBehaviors>
</behaviors>

その後、サービスは次のように宣言されます。

[PrincipalPermission(SecurityAction.Demand,
Role = ""Builtin\\Administrators"")]
public double Add(double n1, double n2)
{
double result = n1 + n2;
return result;
}

ASP.NET Web API で適切な承認メカニズムを実装する

タイトル	詳細
コンポーネント	Web API
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック、MVC5
属性	該当なし、ID プロバイダー - ADFS、ID プロバイダー - Microsoft Entra ID
参照	ASP.NET Web API の認証と承認
手順	アプリケーションが Microsoft Entra ID または ADFS 要求を ID プロバイダーとして使用している場合、アプリケーションユーザーのロール情報は、その Microsoft Entra ID または ADFS 要求から派生していることがあります。また、アプリケーション自体がその情報を提供している場合もあります。いずれの場合も、カスタム承認の実装によって、ユーザーロール情報を検証する必要があります。アプリケーションが Microsoft Entra ID または ADFS 要求を ID プロバイダーとして使用している場合、アプリケーションユーザーのロール情報は、その Microsoft Entra ID または ADFS 要求から派生していることがあります。また、アプリケーション自体がその情報を提供している場合もあります。いずれの場合も、カスタム承認の実装によって、ユーザーロール情報を検証する必要があります。

例

[AttributeUsage(AttributeTargets.Class | AttributeTargets.Method, Inherited = true, AllowMultiple = true)]
public class ApiAuthorizeAttribute : System.Web.Http.AuthorizeAttribute
{
        public async override Task OnAuthorizationAsync(HttpActionContext actionContext, CancellationToken cancellationToken)
        {
            if (actionContext == null)
            {
                throw new Exception();
            }

            if (!string.IsNullOrEmpty(base.Roles))
            {
                bool isAuthorized = ValidateRoles(actionContext);
                if (!isAuthorized)
                {
                    HandleUnauthorizedRequest(actionContext);
                }
            }

            base.OnAuthorization(actionContext);
        }

public bool ValidateRoles(actionContext)
{
   //Authorization logic here; returns true or false
}

}

保護する必要があるすべてのコントローラーおよびアクションメソッドは、上記の属性で修飾する必要があります。

[ApiAuthorize]
public class CustomController : ApiController
{
     //Application code goes here
}

さまざまなアクセス許可レベルを必要とする各種アクションをデバイスがサポートしている場合は、デバイスで承認チェックを実行する

タイトル	詳細
コンポーネント	IoT デバイス
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
手順	デバイスは呼び出し元を承認して、要求された操作の実行に必要なアクセス許可が呼び出し元に付与されているかどうかを確認する必要があります。たとえば、デバイスがスマートドアロックで、クラウドから監視できるとします。これには、リモートドアロックのような機能も用意されています。スマートドアロックは、カードを持っている人が物理的にドアの近くにきた場合にのみ、ロック解除機能を提供します。この場合、クラウドゲートウェイには、ドアのロック解除コマンドを送信する権限が付与されていないため、ドアのロック解除機能が提供されないように、リモートコマンドとコントロールを実装する必要があります。

さまざまなアクセス許可レベルを必要とする各種アクションをデバイスがサポートしている場合は、フィールドゲートウェイで承認チェックを実行する

タイトル	詳細
コンポーネント	IoT フィールドゲートウェイ
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
手順	フィールドゲートウェイは呼び出し元を承認して、要求された操作の実行に必要なアクセス許可が呼び出し元に付与されているかどうかを確認する必要があります。たとえば、管理ユーザーインターフェイス/API にはさまざまなアクセス許可があり、それを使用して、自身に接続されているフィールドゲートウェイやデバイスを構成します。

セキュリティ フレーム:承認 | 対応策

デバイス上のデータへの未承認アクセスを制限する適切な ACL が構成されていることを確認します

ユーザー固有の機密アプリケーション コンテンツがユーザー プロファイル ディレクトリに保存されていることを確認する