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

製品/サービス	[アーティクル]
コンピューターの信頼の境界	デバイス上のデータへの未承認アクセスを制限する適切な 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 にはさまざまなアクセス許可があり、それを使用して、自身に接続されているフィールド ゲートウェイやデバイスを構成します。