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

[アーティクル]
10/26/2023

製品/サービス	[アーティクル]
Web アプリケーション	標準の認証メカニズムを使用して Web アプリケーションに対する認証を行うことを検討する認証失敗のシナリオをアプリケーションが安全に処理するステップアップまたはアダプティブ認証を有効にする管理インターフェイスのロックが適切にロックダウンされていることを確認するパスワードの再設定機能を安全に実装するパスワードとアカウントポリシーが実装されていることを確認するユーザー名が列挙されないコントロールを実装する
[データベース]	可能であれば Windows 認証を使用して SQL Server に接続する可能であれば Microsoft Entra 認証を使用して SQL Database に接続する SQL 認証モードを使用する場合は、SQL サーバーでアカウントとパスワードポリシーが適用されていることを確認する包含データベースでは SQL 認証を使用しない
Azure Event Hub	SaS トークンを使用したデバイスごとの認証資格情報を使用する
Azure の信頼の境界	Azure 管理者に対して Microsoft Entra 多要素認証を有効にする
Service Fabric の信頼の境界	Service Fabric クラスターへの匿名アクセスを制限する Service Fabric のクライアントとノード間の証明書が、ノード間の証明書と異なることを確認する Microsoft Entra ID を使用して Service Fabric クラスターに対してクライアントを認証する承認された証明機関 (CA) から取得された Service fabric 証明書であることを確認する
Identity Server	Identity Server でサポートされる標準的な認証シナリオを使用する既定の Identity Server トークンキャッシュをスケーラブルな代替手段でオーバーライドする
コンピューターの信頼の境界	デプロイされたアプリケーションのバイナリがデジタル署名されていることを確認する
WCF	WCF で MSMQ キューに接続するときに認証を有効にする WCF - メッセージ clientCredentialType を none に設定しない WCF - トランスポート clientCredentialType を none に設定しない
Web API	標準的な認証手法によって Web API がセキュリティで保護されていることを確認する
Microsoft Entra ID	Microsoft Entra ID でサポートされている標準的な認証シナリオを使用する既定の MSAL トークンキャッシュを分散キャッシュでオーバーライドする受信認証トークンのリプレイを防ぐために TokenReplayCache が使用されていることを確認する MSAL ライブラリを使用して、OAuth2 クライアントから Microsoft Entra ID (またはオンプレミス AD) へのトークン要求を管理する
IoT フィールドゲートウェイ	フィールドゲートウェイに接続しているデバイスを認証する
IoT クラウドゲートウェイ	クラウドゲートウェイに接続しているデバイスが認証されていることを確認するデバイスごとの認証資格情報を使用する
Azure ストレージ	必要なコンテナーと BLOB のみに匿名読み取りアクセスが付与されていることを確認する SAS または SAP を使用して Azure Storage のオブジェクトへの制限付きアクセスを許可する

標準の認証メカニズムを使用して Web アプリケーションに対する認証を行うことを検討する

タイトル	詳細
コンポーネント	Web アプリケーション
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
詳細	認証は、エンティティがその ID を証明するプロセスで、通常はユーザー名、パスワードなどの資格情報を使用します。使用を検討できる認証プロトコルは複数あります。その一部を次に示します。 [クライアント証明書] Windows ベースフォームベースフェデレーション - ADFS フェデレーション - Microsoft Entra ID フェデレーション - Identity Server 標準の認証メカニズムを使用してソースプロセスを特定することを検討します

認証失敗のシナリオをアプリケーションが安全に処理する

タイトル	詳細
コンポーネント	Web アプリケーション
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
詳細	ユーザーを明示的に認証するアプリケーションでは、認証失敗シナリオを安全に処理する必要があります。認証メカニズムでは以下の処理が必要です。認証が失敗したときに特権リソースへのアクセスを拒否する認証が失敗し、アクセス拒否が発生した後に、一般的なエラーメッセージを表示する以下をテストします。ログイン失敗後に特権リソースが保護されていること認証失敗およびアクセス拒否イベントで一般的なエラーメッセージが表示されること失敗した試行数が多くなりすぎたときにアカウントが無効になること

ステップアップまたはアダプティブ認証を有効にする

タイトル	詳細
コンポーネント	Web アプリケーション
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
詳細	アプリケーションに追加の認可 (SMS や電子メールでの OTP 送信、再認証を求めるメッセージといった多要素認証を介したステップアップまたはアダプティブ認証など) があることにより、ユーザーが機密情報へのアクセス権を付与される前にチャレンジを受けることを確認します。このルールは、アカウントまたはアクションに対して重大な変更を加えるときにも適用されますつまり、状況依存の承認がアプリケーションによって正しく実施され、パラメーターの改ざんなどによる未承認の操作が許可されないように、認証を実装する必要があります

管理インターフェイスのロックが適切にロックダウンされていることを確認する

タイトル	詳細
コンポーネント	Web アプリケーション
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
詳細	最初は特定のソース IP 範囲から管理インターフェイスへのアクセスのみを許可します。このソリューションで対処できない場合、管理インターフェイスにログインするときは必ずステップアップまたはアダプティブ認証を実施することをお勧めします

パスワードの再設定機能を安全に実装する

タイトル	詳細
コンポーネント	Web アプリケーション
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
詳細	まず、パスワード再設定およびその他の復旧パスが送信するリンクに、パスワード自体ではなく、期限付きのライセンス認証トークンが含まれることを確認します。リンクの送信前に、ソフトトークン (SMS トークン、ネイティブのモバイルアプリケーションなど) に基づく追加認証を要求することもできます。また、新しいパスワードの取得プロセスの進行中は、ユーザーアカウントをロックアウトしないでください。攻撃者が自動攻撃によってユーザーを意図的にロックアウトしようとした場合、これがサービス拒否攻撃につながる可能性があります。 3 番目に気を付けるのは、新しいパスワードの設定が進行中のときに表示するメッセージは、ユーザー名が列挙されないように一般化する、という点です。 4 番目として、以前のパスワードは使用できないようにします。また、強力なパスワードポリシーを実装してください。

パスワードとアカウントポリシーが実装されていることを確認する

タイトル	詳細
コンポーネント	Web アプリケーション
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
詳細	組織のポリシーとベストプラクティスに準拠しているパスワードおよびアカウントポリシーを実装する必要があります。ブルートフォース攻撃や辞書ベース推測を防ぐには、ユーザーが必ず複雑なパスワード (例: 12 文字以上、英数字と特殊文字) を設定するように、強力なパスワードポリシーを実装します。アカウントロックアウトポリシーは次のように実装されます: ソフトロックアウト: ブルートフォース攻撃からのユーザー保護に適したオプションです。たとえば、ユーザーが間違ったパスワードを 3 回入力するたびに、アプリケーションによりアカウントが 1 分間ロックダウンされます。これにより、パスワードのブルートフォース攻撃速度が低下し、攻撃を続行するメリットが少なくなります。これに対してハードロックアウト対策を実装しようとすると、アカウントを完全にロックして "DoS" を行うことになります。または、アプリケーションで OTP (ワンタイムパスワード) を生成し、帯域外 (電子メール、SMS などを介して) でユーザーに送信することもできます。もう 1 つの方法は、失敗した試行回数のしきい値に達した後に CAPTCHA を実装することです。ハードロックアウト: アプリケーションを攻撃しているユーザーを検出し、そのアカウントを、対応チームがフォレンジクス調査を行う時間を確保できるまで完全にロックアウトすることで対抗する場合は、必ずこの種類のロックアウトを適用します。このプロセスの後に、ユーザーのアカウントを元に戻すか、そのユーザーに対して法的手段を取るかを決めることができます。この方法では、攻撃者が、それ以上アプリケーションとインフラストラクチャに侵入できません。既定および予測可能なアカウントへの攻撃を防ぐには、すべてのキーやパスワードが変更可能で、インストール後に生成または変更されたことを確認します。アプリケーションがパスワードを自動生成する必要がある場合は、自動生成されたパスワードがランダムで、エントロピーが高いことを確認します。

ユーザー名が列挙されないコントロールを実装する

タイトル	詳細
コンポーネント	Web アプリケーション
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
手順	ユーザー名が列挙されないようにすべてのエラーメッセージを一般化します。また、登録ページなどの機能では情報漏えいが避けられない場合もあります。このような場合は CAPTCHA などのレート制限方法を使用して、攻撃者による自動攻撃を防ぐ必要があります。

可能であれば Windows 認証を使用して SQL Server に接続する

タイトル	詳細
コンポーネント	データベース
SDL フェーズ	Build
適用できるテクノロジ	設置型
属性	SQL バージョン - すべて
参照	SQL Server - 認証モードの選択
手順	Windows 認証では、Kerberos セキュリティプロトコルを利用し、強力なパスワードに対して複雑な検証を行うという点に関して、パスワードポリシーが強化されています。また、アカウントロックアウトの機能を提供し、パスワード有効期限にも対応しています。

可能であれば Microsoft Entra 認証を使用して SQL Database に接続する

件名	詳細
コンポーネント	データベース
SDL フェーズ	Build
適用できるテクノロジ	SQL Azure
属性	SQL バージョン - V12
参照	Microsoft Entra 認証を使用した SQL Database への接続
手順	最小バージョン: Azure SQL Database で Microsoft Directory に対する Microsoft Entra 認証を使用するには Azure SQL Database V12 が必要です

SQL 認証モードを使用する場合は、SQL サーバーでアカウントとパスワードポリシーが適用されていることを確認する

タイトル	詳細
コンポーネント	データベース
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	SQL Server のパスワードポリシー
手順	SQL Server 認証を使用する場合は、Windows ユーザーアカウントに基づいていない SQL Server でログインが作成されます。ユーザー名とパスワードの両方が SQL Server を使用して作成され、SQL Server に格納されます。 SQL Server は Windows のパスワードポリシーメカニズムに対応しています。また、SQL Server 内部で使用されるパスワードに、Windows で使用されているものと同じ複雑性ポリシーおよび有効期限ポリシーを適用できます。

包含データベースでは SQL 認証を使用しない

タイトル	詳細
コンポーネント	データベース
SDL フェーズ	Build
適用できるテクノロジ	オンプレミス、SQL Azure
属性	SQL バージョン - MSSQL2012、SQL バージョン - V12
参照	包含データベースでのセキュリティのベストプラクティス
手順	パスワードポリシーが適用されていないと、包含データベースで脆弱な資格情報が確立される可能性が高くなる場合があります。 Windows 認証を使用してください。

SaS トークンを使用したデバイスごとの認証資格情報を使用する

タイトル	詳細
コンポーネント	Azure Event Hubs
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	Event Hubs の認証とセキュリティモデルの概要
手順	Event Hubs のセキュリティモデルは、Shared Access Signature (SAS) トークンとイベントパブリッシャーの組み合わせに基づいています。パブリッシャー名は、トークンを受け取る DeviceID を表します。これは、生成されたトークンと各デバイスを関連付けるうえで役に立ちます。すべてのメッセージが、サービス側の発信元でタグ付けされており、ペイロード内配信元なりすまし試行を検出できます。デバイスを認証するときに、一意のパブリッシャーを対象とした SAS トークンをデバイスごとに生成します。

Azure 管理者に対して Microsoft Entra 多要素認証を有効にする

件名	詳細
コンポーネント	Azure の信頼の境界
SDL フェーズ	デプロイ
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	Microsoft Entra 多要素認証とは
手順	多要素認証 (MFA) は、複数の確認方法を要求し、ユーザーのサインインとトランザクションにさらなる重要なセキュリティレイヤーを追加する認証方法です。これらは、次の確認方法のうち 2 つ以上を要求することで機能します。ユーザーが知っている情報 (一般にパスワード) ユーザーの所持品 (電話など、容易には複製できない、信頼済みのデバイス) ユーザー自身 (生体認証)

Service Fabric クラスターへの匿名アクセスを制限する

タイトル	詳細
コンポーネント	Service Fabric の信頼の境界
SDL フェーズ	デプロイ
適用できるテクノロジ	ジェネリック
属性	環境 - Azure
参照	Service Fabric クラスターのセキュリティに関するシナリオ
手順	クラスターは、特に運用ワークロードが実行されている場合などに、許可なくユーザーがクラスターに接続するのを防ぐために常にセキュリティで保護する必要があります。 Service Fabric クラスターを作成することはできますが、セキュリティモードは "セキュリティ保護" に設定し、必要な X.509 証明書を構成する必要があります。 "セキュリティ保護されていない" クラスターを作成すると、パブリックインターネットへの管理エンドポイントを公開している場合、すべての匿名ユーザーがそのクラスターに接続できるようになります。

Service Fabric のクライアントとノード間の証明書が、ノード間の証明書と異なることを確認する

タイトル	詳細
コンポーネント	Service Fabric の信頼の境界
SDL フェーズ	デプロイ
適用できるテクノロジ	ジェネリック
属性	環境 - Azure、環境、 - スタンドアロン
参照	Service Fabric クライアントとノードの間の証明書セキュリティ、クライアント証明書を使用したセキュリティ保護されたクラスターへの接続
手順	クライアントとノードの間の証明書セキュリティを構成するには、Azure Portal、Resource Manager テンプレート、またはスタンドアロン JSON テンプレートでクラスターを作成するときに、管理用クライアント証明書やユーザークライアント証明書を指定します。指定する管理用クライアント証明書とユーザークライアント証明書は、ノード間のセキュリティに指定するプライマリ証明書とセカンダリ証明書とは異なります。

Microsoft Entra ID を使用して Service Fabric クラスターに対してクライアントを認証する

件名	詳細
コンポーネント	Service Fabric の信頼の境界
SDL フェーズ	デプロイ
適用できるテクノロジ	ジェネリック
属性	環境 - Azure
参照	クラスターのセキュリティシナリオ - セキュリティに関する推奨事項
手順	Azure で実行されているクラスターは、クライアント証明書とは別に、Microsoft Entra ID を使用して、管理エンドポイントへのアクセスをセキュリティで保護することもできます。 Azure クラスターについては、クライアントの認証に Microsoft Entra セキュリティを使用し、ノード間のセキュリティを確保するために証明書を使用することをお勧めします。

承認された証明機関 (CA) から取得された Service Fabric 証明書であることを確認する

タイトル	詳細
コンポーネント	Service Fabric の信頼の境界
SDL フェーズ	デプロイ
適用できるテクノロジ	ジェネリック
属性	環境 - Azure
参照	X.509 証明書と Service Fabric
手順	Service Fabric では、ノードとクライアントの認証に X.509 サーバー証明書が使用されます。 Service Fabric で証明書を使用するうえでの重要な考慮事項をいくつか次に示します。運用環境のワークロードを実行しているクラスターに使用する証明書は、正しく構成された Windows Server 証明書サービスを使用して作成するか、認定済みの証明機関 (CA) から取得する必要があります。 CA として利用できるのは、承認済みの外部 CA、または適切に管理された内部公開キー基盤 (PKI) です運用環境では、MakeCert.exe などのツールで作成した一時証明書またはテスト証明書を使用しないでください自己署名入りの証明書は使用できますが、運用環境のクラスターではなく、テスト環境のクラスターにのみ使用してください

Identity Server でサポートされる標準的な認証シナリオを使用する

タイトル	詳細
コンポーネント	Identity Server
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	IdentityServer3 - 概要
手順	Identity Server でサポートされている標準的なやり取りを次に示します。ブラウザーが Web アプリケーションと通信する Web アプリケーションが (自身で、またはユーザーの代わりに) Web API と通信するブラウザーベースのアプリケーションが Web API と通信するネイティブアプリケーションが Web API と通信するサーバーベースのアプリケーションが Web API と通信する Web API が (自身で、またはユーザーの代わりに) Web API と通信する

既定の Identity Server トークンキャッシュをスケーラブルな代替手段でオーバーライドする

タイトル	詳細
コンポーネント	Identity Server
SDL フェーズ	デプロイ
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	Identity Server のデプロイ - キャッシュ
手順	Identity Server にはシンプルなメモリ内キャッシュが組み込まれています。これは小規模なネイティブアプリには適していますが、次の理由により、中間層およびバックエンドアプリケーション用に拡張されません。こうしたアプリケーションには、一度に多数のユーザーがアクセスします。大きな規模で動作しているときに、すべてのアクセストークンを同じストアに保存すると分離の問題が発生し、課題が生じます。ユーザーが多数存在するほか、それぞれのユーザーに、そのユーザーのアプリがアクセスするリソースと同数のトークンがあります。つまり、その数は膨大で、参照操作にコストがかかるということですこうしたアプリケーションは、通常、分散トポロジにデプロイされます。このトポロジでは、複数のノードが同じキャッシュにアクセスしなければなりませんプロセスがリサイクルおよび非アクティブ化されても、キャッシュされたトークンを保持する必要があります上記のすべての理由により、Web アプリの実装中、既定の Identity Server のトークンキャッシュを、Azure Cache for Redis などのスケーラブルな代替手段でオーバーライドすることをお勧めします

デプロイされたアプリケーションのバイナリがデジタル署名されていることを確認する

タイトル	詳細
コンポーネント	コンピューターの信頼の境界
SDL フェーズ	デプロイ
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
手順	バイナリの整合性を検証できるように、デプロイされたアプリケーションのバイナリがデジタル署名されていることを確認します

WCF で MSMQ キューに接続するときに認証を有効にする

タイトル	詳細
コンポーネント	WCF
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック、NET Framework 3
属性	該当なし
参照	MSDN
手順	MSMQ キューに接続するときに認証を有効にできないと、攻撃者が、処理を実行するためのメッセージを匿名でキューに送信できます。別のプログラムにメッセージを配信するときに使用する MSMQ キューに、認証を使用しないで接続すると、攻撃者が、悪意のある匿名メッセージを送信する可能性があります。

例

以下の WCF 構成ファイルの <netMsmqBinding/> 要素は、メッセージ配信のために MSMQ キューに接続するときに認証を無効にします。

<bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""None"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

すべての受信または送信メッセージに対して、常に Windows ドメインまたは証明書認証を要求するように MSMQ を構成します。

例

以下の WCF 構成ファイルの <netMsmqBinding/> 要素は、MSMQ キューに接続するときに証明書認証を有効にします。クライアントは、X.509 証明書を使用して認証されます。クライアント証明書が、サーバーの証明書ストアに存在する必要があります。

<bindings>
    <netMsmqBinding>
        <binding>
            <security>
                <transport msmqAuthenticationMode=""Certificate"" />
            </security>
        </binding>
    </netMsmqBinding>
</bindings>

WCF - メッセージ clientCredentialType を none に設定しない

タイトル	詳細
コンポーネント	WCF
SDL フェーズ	Build
適用できるテクノロジ	.NET Framework 3
属性	クライアント資格情報の種類 - なし
参照	MSDN、Fortify
手順	認証が存在しないということは、すべてのユーザーがこのサービスにアクセスできるということです。クライアントを認証しないサービスでは、すべてのユーザーへのアクセスが許可されます。アプリケーションは、クライアントの資格情報に対して認証を行うように構成してください。これを行うには、メッセージ clientCredentialType を Windows または証明書に設定します。

例

<message clientCredentialType=""Certificate""/>

WCF - トランスポート clientCredentialType を none に設定しない

タイトル	詳細
コンポーネント	WCF
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック、NET Framework 3
属性	クライアント資格情報の種類 - なし
参照	MSDN、Fortify
手順	認証が存在しないということは、すべてのユーザーがこのサービスにアクセスできるということです。クライアントを認証しないサービスでは、すべてのユーザーがその機能にアクセスできます。アプリケーションは、クライアントの資格情報に対して認証を行うように構成してください。これを行うには、トランスポート clientCredentialType を Windows または証明書に設定します。

例

<transport clientCredentialType=""Certificate""/>

標準的な認証手法によって Web API がセキュリティで保護されていることを確認する

タイトル	詳細
コンポーネント	Web API
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	ASP.NET Web API での認証と権限承認、ASP.NET Web API (C#) の外部認証サービス
手順	認証は、エンティティがその ID を証明するプロセスで、通常はユーザー名、パスワードなどの資格情報を使用します。使用を検討できる認証プロトコルは複数あります。その一部を次に示します。 [クライアント証明書] Windows ベースフォームベースフェデレーション - ADFS フェデレーション - Microsoft Entra ID フェデレーション - Identity Server 「参照」セクションのリンクは、認証スキームを実装して Web API をセキュリティで保護する方法について、細かなレベルの詳細情報をスキームごとに提供します。

Microsoft Entra ID でサポートされている標準的な認証シナリオを使用する

件名	詳細
コンポーネント	Microsoft Entra ID
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	Microsoft Entra ID の認証シナリオ、Microsoft Entra のコードサンプル、Microsoft Entra 開発者ガイド
手順	Microsoft Entra ID を使用すると、OAuth 2.0 や OpenID Connect などの業界標準プロトコルをサポートする、サービスとしての ID が提供され、開発者の認証が簡素化されます。 Microsoft Entra ID でサポートされている 5 つの主要なアプリケーションシナリオは、次のとおりです。 Web ブラウザーから Web アプリケーション: ユーザーは、Microsoft Entra ID によって保護された Web アプリケーションにサインインする必要がありますシングルページアプリケーション (SPA): ユーザーは、Microsoft Entra ID によって保護されたシングルページアプリケーションにサインインする必要がありますネイティブアプリケーションから Web API: スマートフォン、タブレット、または PC で実行されるネイティブアプリケーションは、Microsoft Entra ID によって保護された Web API からリソースを取得するために、ユーザーを認証する必要があります Web アプリケーションから Web API: Web アプリケーションは、Microsoft Entra ID によって保護された Web API からリソースを取得する必要がありますデーモンまたはサーバーアプリケーションから Web API: Web ユーザーインターフェイスを備えていないデーモンアプリケーションまたはサーバーアプリケーションは、Microsoft Entra ID によって保護された Web API からリソースを取得する必要があります細かなレベルの実装の詳細については、「参照」セクションのリンクを参照してください

既定の MSAL トークンキャッシュを分散キャッシュでオーバーライドする

タイトル	詳細
コンポーネント	Microsoft Entra ID
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	MSAL.NET でのトークンキャッシュのシリアル化
手順	MSAL (Microsoft Authentication ライブラリ) が使う既定のキャッシュはインメモリキャッシュであり、スケーラブルです。ただし、分散トークンキャッシュなど、代わりに使用できるさまざまなオプションがあります。これらには L1/L2 メカニズムがあります。L1 はメモリ内にあり、L2 は分散キャッシュの実装です。必要に応じてこれらを構成して、L1 メモリを制限したり、削除ポリシーを暗号化または設定したりすることができます。他の選択肢としては、Redis、SQL Server、Azure Comsos DB キャッシュなどがあります。分散トークンキャッシュの実装については、ASP.NET Core MVC の概要に関するチュートリアルを参照してください。

MSAL 認証トークンのリプレイを防ぐために TokenReplayCache が使用されていることを確認する

タイトル	詳細
コンポーネント	Microsoft Entra ID
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	Web アプリケーション向けの Microsoft Entra ID による最新の認証
手順	TokenReplayCache プロパティを使用すると、開発者がトークンリプレイキャッシュ (複数回使用できるトークンが存在しないことを確認する目的でのトークン保存に使用できるストア) を定義できます。これは、一般的な攻撃、つまり、サインイン時に送信されたトークンを攻撃者が傍受し、そのトークンをアプリに再送信 ("リプレイ") して新しいセッションを確立しようとする、トークンリプレイ攻撃への対抗手段です。たとえば、OIDC コード付与フローでは、ユーザー認証に成功した後、証明書利用者の "/signin oidc" エンドポイントへの要求が、"id_token"、"code"、および "state" パラメーターを使用して行われます。証明書利用者はこの要求を検証し、新しいセッションを確立します。敵がこの要求をキャプチャし、リプレイすると、セッションを確立し、ユーザーになりすますことができます。 OpenID Connect に nonce が存在すると、攻撃された環境を制限できますが、完全には排除できません。アプリケーションを保護するために、開発者は ITokenReplayCache を実装し、インスタンスを TokenReplayCache に割り当てることができます。

例

// ITokenReplayCache defined in MSAL
public interface ITokenReplayCache
{
bool TryAdd(string securityToken, DateTime expiresOn);
bool TryFind(string securityToken);
}

例

ITokenReplayCache インターフェイスの実装例を次に示します (カスタマイズして、プロジェクト固有のキャッシュフレームワークを実装してください)

public class TokenReplayCache : ITokenReplayCache
{
    private readonly ICacheProvider cache; // Your project-specific cache provider
    public TokenReplayCache(ICacheProvider cache)
    {
        this.cache = cache;
    }
    public bool TryAdd(string securityToken, DateTime expiresOn)
    {
        if (this.cache.Get<string>(securityToken) == null)
        {
            this.cache.Set(securityToken, securityToken);
            return true;
        }
        return false;
    }
    public bool TryFind(string securityToken)
    {
        return this.cache.Get<string>(securityToken) != null;
    }
}

実装されたキャッシュは、次のように "TokenValidationParameters" プロパティを使用して、OIDC オプションで参照する必要があります。

OpenIdConnectOptions openIdConnectOptions = new OpenIdConnectOptions
{
    AutomaticAuthenticate = true,
    ... // other configuration properties follow..
    TokenValidationParameters = new TokenValidationParameters
    {
        TokenReplayCache = new TokenReplayCache(/*Inject your cache provider*/);
    }
}

この構成の有効性をテストするには、ローカル OIDC で保護されたアプリケーションにサインインし、fiddler で "/signin-oidc" エンドポイントへの要求をキャプチャします。保護されていない場合は、fiddler でこの要求をリプレイすると、新しいセッション cookie が設定されます。 TokenReplayCache 保護が追加された後、要求がリプレイされると、次のように例外がスローされます。SecurityTokenReplayDetectedException: IDX10228: The securityToken has previously been validated, securityToken: 'eyJ0eXAiOiJKV1QiLCJhbGciOiJSUzI1NiIsIng1dCI6Ik1uQ19WWmNBVGZNNXBPWWlKSE1iYTlnb0VLWSIsImtpZCI6Ik1uQ1......

MSAL ライブラリを使用して、OAuth2 クライアントから Microsoft Entra ID (またはオンプレミス AD) へのトークン要求を管理する

件名	詳細
コンポーネント	Microsoft Entra ID
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	MSAL
手順	Microsoft Authentication Library (MSAL) を使用すると、ユーザーを認証し、セキュリティで保護された Web API にアクセスするため、開発者は Microsoft ID プラットフォームからセキュリティトークンを取得できます。これは、Microsoft Graph、その他の Microsoft API、サードパーティの Web API、または、独自の Web API へのセキュリティで保護されたアクセスを提供するために使用できます。 MSAL は、.NET、JavaScript、Java、Python、Android、iOS などの、さまざまなアプリケーションアーキテクチャとプラットフォームをサポートします。

MSAL では、多くのプラットフォームで API に一貫性があり、さまざまな方法でトークンを取得できます。アプリケーション内でプロトコルに対して OAuth ライブラリまたはコードを直接使う必要はありません。ユーザーまたはアプリケーションに代わってトークンを取得できます (プラットフォームに該当する場合)。

MSAL を使うと、トークンキャッシュを保持し、有効期限が近づくとユーザーの代わりにトークンを更新することができます。また、MSAL を使うと、アプリケーションでサインインを許可する対象者を指定すること、構成ファイルからアプリケーションを設定すること、アプリをトラブルシューティングすることもできます。

フィールドゲートウェイに接続しているデバイスを認証する

タイトル	詳細
コンポーネント	IoT フィールドゲートウェイ
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	該当なし
手順	各デバイスがフィールドゲートウェイによって認証されていることを確認したうえで、そのデバイスからデータを受け入れて、クラウドゲートウェイとのアップストリーム通信を容易にします。また、個別のデバイスを一意に識別できるように、デバイスごとの資格情報でデバイスが接続されていることを確認します。

クラウドゲートウェイに接続しているデバイスが認証されていることを確認する

タイトル	詳細
コンポーネント	IoT クラウドゲートウェイ
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック、C#、Node.JS、
属性	該当なし、ゲートウェイの選択 - Azure IoT Hub
参照	該当なし、.NET での Azure IoT Hub、IoT Hub と Node.JS の概要、SAS と証明書による IoT のセキュリティ保護、Git リポジトリ
手順	ジェネリック: トランスポート層セキュリティ (TLS) または IPSec を使ってデバイスを認証します。完全な非対称暗号を扱うことのできないデバイスでは、インフラストラクチャが事前共有キー (PSK) の使用をサポートしている必要があります。 Microsoft Entra ID、Oauth を活用します。 C#: DeviceClient インスタンスを作成するとき、既定では、Create メソッドは、IoT Hub と通信するために AMQP プロトコルを使用する DeviceClient インスタンスを作成します。 HTTPS プロトコルを使用するには、プロトコルを引数として受け取る、Create メソッドのオーバーライドを使用します。 HTTPS プロトコルを使用する場合は、`Microsoft.AspNet.WebApi.Client` NuGet パッケージをプロジェクトに追加して、`System.Net.Http.Formatting` 名前空間を含める必要もあります。

例

static DeviceClient deviceClient;

static string deviceKey = "{device key}";
static string iotHubUri = "{iot hub hostname}";

var messageString = "{message in string format}";
var message = new Message(Encoding.ASCII.GetBytes(messageString));

deviceClient = DeviceClient.Create(iotHubUri, new DeviceAuthenticationWithRegistrySymmetricKey("myFirstDevice", deviceKey));

await deviceClient.SendEventAsync(message);

例

Node.JS: 認証

対称キー

Azure で IoT ハブを作成します

デバイスの ID レジストリにエントリを作成します

var device = new iothub.Device(null);
device.deviceId = <DeviceId >
registry.create(device, function(err, deviceInfo, res) {})

シミュレート対象デバイスを作成します

var clientFromConnectionString = require('azure-iot-device-amqp').clientFromConnectionString;
var Message = require('azure-iot-device').Message;
var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>SharedAccessKey=<SharedAccessKey>';
var client = clientFromConnectionString(connectionString);

SAS トークン

対称キーを使用しているときに内部的に生成されますが、明示的に生成して使用することもできます
プロトコルを定義します: var Http = require('azure-iot-device-http').Http;

SAS トークンを作成します:

resourceUri = encodeURIComponent(resourceUri.toLowerCase()).toLowerCase();
var deviceName = "<deviceName >";
var expires = (Date.now() / 1000) + expiresInMins * 60;
var toSign = resourceUri + '\n' + expires;
// using crypto
var decodedPassword = new Buffer(signingKey, 'base64').toString('binary');
const hmac = crypto.createHmac('sha256', decodedPassword);
hmac.update(toSign);
var base64signature = hmac.digest('base64');
var base64UriEncoded = encodeURIComponent(base64signature);
// construct authorization string
var token = "SharedAccessSignature sr=" + resourceUri + "%2fdevices%2f"+deviceName+"&sig="
+ base64UriEncoded + "&se=" + expires;
if (policyName) token += "&skn="+policyName;
return token;

SAS トークンを使用して接続します:
```
Client.fromSharedAccessSignature(sas, Http);
```
証明書
OpenSSL などのツールを使用して自己署名 X509 証明書を生成し、証明書を格納する .cert ファイルと、キーを格納する .key ファイルを生成します

証明書を使用してセキュリティで保護された接続を受け入れるデバイスをプロビジョニングします。

var connectionString = '<connectionString>';
var registry = iothub.Registry.fromConnectionString(connectionString);
var deviceJSON = {deviceId:"<deviceId>",
authentication: {
    x509Thumbprint: {
    primaryThumbprint: "<PrimaryThumbprint>",
    secondaryThumbprint: "<SecondaryThumbprint>"
    }
}}
var device = deviceJSON;
registry.create(device, function (err) {});

証明書を使用してデバイスを接続します

var Protocol = require('azure-iot-device-http').Http;
var Client = require('azure-iot-device').Client;
var connectionString = 'HostName=<HostName>DeviceId=<DeviceId>x509=true';
var client = Client.fromConnectionString(connectionString, Protocol);
var options = {
    key: fs.readFileSync('./key.pem', 'utf8'),
    cert: fs.readFileSync('./server.crt', 'utf8')
};
// Calling setOptions with the x509 certificate and key (and optionally, passphrase) will configure the client //transport to use x509 when connecting to IoT Hub
client.setOptions(options);
//call fn to execute after the connection is set up
client.open(fn);

デバイスごとの認証資格情報を使用する

タイトル	詳細
コンポーネント	IoT クラウドゲートウェイ
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	ゲートウェイの選択 - Azure IoT Hub
参照	Azure IoT Hub セキュリティトークン
手順	IoT Hub レベルの共有アクセスポリシーではなく、デバイスキーまたはクライアント証明書に基づく SaS トークンを使用したデバイスごとの認証資格情報を使用します。これにより、デバイスまたはフィールドゲートウェイ認証トークンを、別のデバイスやフィールドゲートウェイが再利用できなくなります

必要なコンテナーと BLOB のみに匿名読み取りアクセスが付与されていることを確認する

タイトル	詳細
コンポーネント	Azure Storage
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	StorageType - BLOB
参照	コンテナーと BLOB への匿名読み取りアクセスを管理する、Shared Access Signatures、第 1 部: SAS モデルについて
手順	既定では、コンテナーとその中のすべての BLOB には、ストレージアカウントの所有者のみがアクセスできます。コンテナーとその BLOB に対する読み取りアクセス許可を匿名ユーザーに付与する場合は、コンテナーのアクセス許可を設定し、パブリックアクセスを許可できます。パブリックアクセスが許可されたコンテナー内の BLOB は、匿名ユーザーが読み取ることができ、その際に要求の認証は不要です。コンテナーへのアクセスは次のように管理できます。パブリック読み取りフルアクセス: コンテナーと BLOB のデータを匿名要求で読み取ることができます。クライアントは匿名要求でコンテナー内の BLOB を列挙できますが、ストレージアカウント内のコンテナーを列挙することはできません。 BLOB に限定したパブリック読み取りアクセス: 該当するコンテナー内の BLOB データは匿名要求で読み取り可能ですが、コンテナーデータは参照できません。クライアントはコンテナー内の BLOB を匿名要求で列挙することはできませんパブリック読み取りアクセスなし: コンテナーと BLOB のデータはアカウント所有者に限り読み取ることができます匿名アクセスは、匿名読み取りアクセスで特定の BLOB を常に使用する必要があるシナリオに最適です。詳細な制御では、さまざまなアクセス許可を使用し、指定された期間において、制限付きアクセスを委任するための Shared Access Signature を作成できます。機密性の高いデータが含まれる可能性があるコンテナーと BLOB に誤って匿名アクセスが付与されないようにする

SAS または SAP を使用して Azure Storage のオブジェクトへの制限付きアクセスを許可する

タイトル	詳細
コンポーネント	Azure Storage
SDL フェーズ	Build
適用できるテクノロジ	ジェネリック
属性	該当なし
参照	Shared Access Signature、第 1 部: SAS モデルについて、Shared Access Signature、第 2 部: Blob Storage での SAS の作成と使用、Shared Access Signature と Stored Access Policy を使用してアカウントのオブジェクトに対するアクセス権を委任する方法
手順	Shared Access Signature (SAS) の使用は、アカウントアクセスキーを知らせずに、自分のストレージアカウントのオブジェクトへの制限付きアクセスを他のクライアントに許可するための優れた方法です。 SAS とは、ストレージリソースへの認証アクセスに必要なすべての情報をクエリパラメーター内に含む URI です。クライアントは、SAS 内で適切なコンストラクターまたはメソッドに渡すだけで、SAS でストレージリソースにアクセスできます。 SAS は、自分のアカウントキーを知らせたくないクライアントに、自分のストレージアカウント内のリソースへのアクセスを許可する場合に使用できます。ストレージアカウントキーには、プライマリキーとセカンダリキーの両方が含まれており、これらによって、アカウントとそのすべてのリソースへの管理アクセスが付与されます。これらのアカウントキーのいずれかを知らせると、悪意で、または誤ってアカウントが使用される可能性が生じます。 Shared Access Signature は、アカウントキーが不要で安全な代替方法です。この方法で、他のクライアントは、付与されたアクセス許可に従ってストレージアカウント内のデータの読み取り、書き込み、削除を実行できます。毎回の論理パラメーターセットが類似している場合は、Stored Access Policy (SAP) を使用することをお勧めします。 Stored Access Policy から派生した SAS を使用すると、その SAS を即時に無効にすることができるので、可能な限り常に Stored Access Policy を使用するベストプラクティスが推奨されます。

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