次の方法で共有

Microsoft Entra ID と PCI-DSS の要件 8

  • [アーティクル]

要件 8: ユーザーを識別し、システム コンポーネントへのアクセスを認証する
定義されたアプローチの要件

8.1 ユーザーを識別し、システム コンポーネントへのアクセスを認証するためのプロセスとメカニズムが定義され、理解されている。

PCI-DSS で定義されたアプローチの要件 Microsoft Entra のガイダンスとレコメンデーション
8.1.1 要件 8 で特定されるすべてのセキュリティ ポリシーと運用手順は次のとおり:
文書化されている
最新の状態に維持されている
使用中
すべての関係者に通知されている		 ここで示しているガイダンスとリンクを使用してドキュメントを作成し、お使いの環境の構成に基づいた要件を満たします。
8.1.2 要件 8 のアクティビティを実行するための役割と責任が文書化され、割り当てられ、理解されている。 ここで示しているガイダンスとリンクを使用してドキュメントを作成し、お使いの環境の構成に基づいた要件を満たします。
PCI-DSS で定義されたアプローチの要件 Microsoft Entra のガイダンスとレコメンデーション
8.2.1 システム コンポーネントまたはカード所有者データへのアクセスが許可される前に、すべてのユーザーに一意の ID が割り当てられる。 Microsoft Entra ID に依存する CDE アプリケーションの場合、一意のユーザー ID はユーザー プリンシパル名 (UPN) 属性です。 Microsoft Entra UserPrincipalName の作成
8.2.2 グループ アカウント、共有アカウント、または汎用アカウント、あるいはその他の共有される認証資格情報は、例外的に必要な場合にのみ使用され、次のように管理される:
例外的な状況で必要な場合を除き、アカウントの使用は禁止される。
例外的な状況で必要な時間に限定して使用される。
使用に関する業務上の正当な理由が文書化されている。
使用は管理者によって明示的に承認される
アカウントへのアクセスが許可される前に個々のユーザー ID が確認される。
実行されるすべてのアクションは、個々のユーザーに起因します。		 アプリケーション アクセスに Microsoft Entra ID を使用する CDE に、共有アカウントを防止するプロセスがあることを確認します。 共有アカウントは、承認が必要な例外として作成します。
Azure にデプロイされる CDE リソースの場合、共有サービス アカウントを作成する代わりに、Azure リソースのマネージド ID を使用してワークロード ID を表します。 Azure リソースのマネージド ID とは
マネージド ID が使用できず、アクセスされるリソースが OAuth プロトコルを使用している場合は、サービス プリンシパルを使用してワークロード ID を表します。 OAuth スコープを使用して最小特権アクセスを ID に付与します。 管理者は、共有アカウントを作成するためのアクセスを制限したり、そのための承認ワークフローを定義したりできます。 ワークロード ID とは
8.2.3 サービス プロバイダー限定の追加要件: 顧客施設にリモートからアクセスするサービス プロバイダーは、顧客施設ごとに固有の認証要素を使用する。 Microsoft Entra ID には、ハイブリッド機能を有効にするオンプレミス コネクタがあります。 コネクタは識別可能であり、一意に生成された資格情報を使用します。 Microsoft Entra Connect 同期: 同期を理解してカスタマイズする
クラウド同期の詳細情報
Microsoft Entra オンプレミス アプリケーション プロビジョニングのアーキテクチャ
Microsoft Entra ユーザー プロビジョニングのためのクラウド HR アプリケーションの計画
Microsoft Entra Connect Health エージェントをインストールする
8.2.4 ユーザー ID、認証要素、その他の ID オブジェクトの追加、削除、変更が次のように管理される:
適切な承認を得て認可される。
文書化された承認で指定された特権のみを使用して実装される。		 Microsoft Entra ID では、人事システムからのユーザー アカウント プロビジョニングが自動化されています。 この機能を使用して、ライフサイクルを作成します。 人事主導のプロビジョニングとは
Microsoft Entra ID のライフサイクル ワークフローを使用して、就職者、異動者、退職者の各プロセス向けにロジックをカスタマイズできます。 ライフサイクル ワークフローとは
Microsoft Entra ID には、Microsoft Graph を使用して認証方法を管理するためのプログラム インターフェイスがあります。 Windows Hello for Business キーや FIDO2 キーのような一部の認証方法では、登録するためにユーザーの介入が必要です。 Graph の認証方法 API の概要
一時アクセス パスの資格情報は、Graph API を使用して管理者または自動化によって生成されます。 パスワードレスのオンボードには、この資格情報を使用します。 パスワードレスの認証方法を登録するように Microsoft Entra ID で一時アクセス パスを構成する
8.2.5 解雇されたユーザーのアクセスはただちに取り消される。 アカウントへのアクセスを取り消すには、Microsoft Entra ID から同期されたハイブリッド アカウントのオンプレミス アカウントを無効にし、Microsoft Entra ID でアカウントを無効にして、トークンを取り消します。 Microsoft Entra ID でユーザー アクセスを取り消す
互換性のあるアプリケーションに対して継続的アクセス評価 (CAE) を使用して、Microsoft Entra ID と双方向のメッセージ交換を行います。 アプリは、アカウントの終了やトークンの拒否などのイベントの通知を受けることができます。 継続的アクセス評価
8.2.6 アクティブでないユーザー アカウントは、アクティブでなくなってから 90 日以内に削除または無効化される。 ハイブリッド アカウントの場合、管理者は Active Directory と Microsoft Entra のアクティビティを 90 日ごとにチェックします。 Microsoft Entra ID の場合、Microsoft Graph を使用して最後のサインイン日を特定します。 Microsoft Entra ID で非アクティブなユーザー アカウントを管理する方法
8.2.7 リモート アクセスによるシステム コンポーネントへのアクセスや、そのサポートまたは保守のためにサード パーティが使用するアカウントが次のように管理される:
必要な期間中のみ有効化され、未使用時は無効化される。
予期しないアクティビティがないか使用状況が監視される。		 Microsoft Entra ID には、外部 ID 管理機能があります。
エンタイトルメント管理によって統制されたゲスト ライフサイクルを使用します。 外部ユーザーは、アプリ、リソース、アクセス パッケージのコンテキストでオンボードされます。これらは、期間限定で許可し、定期的なアクセス レビューを義務付けることができます。 レビューの結果、アカウントが削除または無効化される可能性があります。 エンタイトルメント管理で外部ユーザーのアクセスを管理する
Microsoft Entra ID では、ユーザーとセッションのレベルでリスク イベントが生成されます。 予期しないアクティビティを保護、検出して対応する方法について確認してください。 リスクとは
8.2.8 ユーザー セッションが 15 分を越えてアイドル状態になった場合、ユーザーは再認証を行って端末またはセッションを再アクティブ化するように要求される。 Intune と Microsoft エンドポイント マネージャーでエンドポイント管理ポリシーを使用します。 次に、条件付きアクセスを使用して、準拠しているデバイスからのアクセスを許可します。 コンプライアンス ポリシーを使用して、Intune で管理するデバイスのルールを設定する
CDE 環境がグループ ポリシー オブジェクト (GPO) に依存している場合は、アイドル タイムアウトを設定するように GPO を構成します。 Microsoft Entra ハイブリッド参加済みデバイスからのアクセスを許可するように Microsoft Entra ID を構成します。 Microsoft Entra ハイブリッド参加済み

8.3 ユーザーと管理者の強力な認証が確立され、管理されている。

PCI 要件を満たす Microsoft Entra 認証方法の詳細については、多要素認証に関する補足情報のページを参照してください。

PCI-DSS で定義されたアプローチの要件 Microsoft Entra のガイダンスとレコメンデーション
8.3.1 ユーザーおよび管理者のシステム コンポーネントへのすべてのユーザー アクセスは、次の認証要素のうち少なくとも 1 つを使用して認証される。
既知の情報 (パスワードやパスフレーズなど)。
所有物 (トークン デバイスやスマート カード)。
ユーザー自身 (生体認証要素など)。		 Microsoft Entra ID では、PCI 要件を満たすためにパスワードレスの方法が必要
包括的なパスワードレス デプロイに関するページを参照してください。 Microsoft Entra ID でのパスワードレス認証のデプロイを計画する
8.3.2 すべてのシステム コンポーネントで、転送中と保存中にすべての認証要素を読み取り不可能にするために、強力な暗号化が使用されている。 Microsoft Entra ID で使用される暗号は、強力な暗号の PCI 定義に準拠します。 Microsoft Entra データ保護に関する考慮事項
8.3.3 認証要素を変更する前に、ユーザー ID が検証される。 Microsoft Entra ID では、mysecurityinfo ポータルやセルフサービス パスワード リセット (SSPR) ポータルなどのセルフサービスを使用して自分の認証方法を更新するために、ユーザーが認証を行う必要があります。 サインイン ページからセキュリティ情報を設定する
一般的な条件付きアクセス ポリシー: セキュリティ情報登録のセキュリティ保護
Microsoft Entra のセルフサービス パスワード リセット
特権ロールを持つ管理者は、認証要素 (グローバル、パスワード、ユーザー、認証、特権認証) を変更できます。 Microsoft Entra ID のタスク別の最小特権ロール。 Microsoft では、Microsoft Entra Privileged Identity Management を使用した特権アクセスに対して JIT アクセスとガバナンスを有効にすることを推奨しています
8.3.4 次の基準で無効な認証試行が制限されている:
10 回以内の試行後にユーザー ID をロックアウトする。
ロックアウト期間を 30 分以上または "ユーザーの ID が確認されるまで" に設定する。		 ハードウェア トラステッド プラットフォーム モジュール (TPM) 2.0 以降をサポートする Windows デバイス向けの Windows Hello for Business をデプロイします。
Windows Hello for Business の場合、ロックアウトはデバイスに関連します。 ジェスチャ、PIN、または生体認証によって、ローカル TPM へのアクセスがロック解除されます。 管理者は、GPO または Intune ポリシーを使用してロックアウト動作を構成します。 TPM のグループ ポリシー設定
デバイスを Intune に登録した時点でデバイスの Windows Hello for Business を管理する
TPM の基礎
Windows Hello for Business は、Active Directory に対するオンプレミス認証と、Microsoft Entra ID 上のクラウド リソースに対して機能します。
FIDO2 セキュリティ キーの場合、ブルートフォース保護はキーに関連しています。 ジェスチャ、PIN、または生体認証によって、ローカル キー ストレージへのアクセスがロック解除されます。 管理者は、PCI 要件に適合する製造元からの FIDO2 セキュリティ キーの登録を許可するように Microsoft Entra ID を構成します。 パスワードなしのセキュリティ キー サインインを有効にする

Microsoft Authenticator アプリ
Microsoft Authenticator アプリのパスワードレス サインインを使用したブルートフォース攻撃を軽減するには、数値の一致と追加のコンテキストを有効にします。
Microsoft Entra ID は、認証フローで乱数を生成します。 ユーザーが認証アプリでそれを入力します。 モバイル アプリの認証プロンプトに、場所、要求の IP アドレス、要求アプリケーションが表示されます。 MFA 通知で数値の一致を使用する方法
Microsoft Authenticator 通知で追加のコンテキストを使用する方法
8.3.5 要件 8.3.1 を満たすためにパスワード/パスフレーズを認証要素として使用する場合、それらは次のようにユーザーごとに設定およびリセットされる:
初回使用時とリセット時に一意の値に設定される。
初回使用の直後に変更を強制される。		 Microsoft Entra ID には適用されません。
8.3.6 要件 8.3.1 を満たすためにパスワード/パスフレーズを認証要素として使用する場合、次の最小レベルの複雑さを満たしている:
最小長は 12 文字 (または、システムで 12 文字がサポートされていない場合、最小長は 8 文字)。
数字と英文字の両方が含まれている。		 Microsoft Entra ID には適用されません。
8.3.7 ユーザーは、最近使用した 4 つのパスワード/パスフレーズのいずれかと同じである新しいパスワード/パスフレーズの送信を許可されない。 Microsoft Entra ID には適用されません。
8.3.8 以下を含む認証のポリシーと手順が文書化され、すべてのユーザーに通知される:
強力な認証要素の選択に関するガイダンス。
ユーザーが自分の認証要素を保護する方法に関するガイダンス。
前に使用したことがあるパスワード/パスフレーズを再利用しないことの指示。
パスワード/パスフレーズが侵害された疑いがあるか侵害が確認された場合に、パスワード/パスフレーズを変更する手順と、インシデントを報告する方法。		 この要件に従ってポリシーと手順を文書化し、ユーザーに通知します。 Microsoft から、カスタマイズ可能なテンプレートがダウンロード センターで提供されています。
8.3.9 パスワード/パスフレーズがユーザー アクセスの唯一の認証要素として (つまり、単一要素認証の実装で) 使用される場合、次のいずれかの条件を満たしている: パスワード/パスフレーズが少なくとも 90 日に 1 回変更される
または
アカウントのセキュリティ体制が動的に分析され、それに応じてリソースへのリアルタイム アクセスが自動的に決定される。		 Microsoft Entra ID には適用されません。
8.3.10 サービス プロバイダー限定の追加要件: パスワード/パスフレーズが、顧客ユーザーがカード所有者データにアクセスするための唯一の認証要素として (つまり、単一要素認証の実装で) 使用される場合、以下を含むガイダンスが顧客ユーザーに提供される:
ユーザーのパスワード/パスフレーズを定期的に変更するよう顧客に求めるガイダンス。
パスワード/パスフレーズを変更するタイミングと状況に関するガイダンス。		 Microsoft Entra ID には適用されません。
8.3.10.1 サービス プロバイダー限定の追加要件: パスワード/パスフレーズが顧客ユーザーのアクセスの唯一の認証要素として (つまり、単一要素認証の実装で) 使用される場合、次のいずれかの条件を満たしている:
パスワード/パスフレーズが少なくとも 90 日に 1 回変更される
または
アカウントのセキュリティ体制が動的に分析され、それに応じてリソースへのリアルタイム アクセスが自動的に決定される。		 Microsoft Entra ID には適用されません。
8.3.11 物理また論理セキュリティ トークン、スマート カード、証明書などの認証要素が使用される場合:
要素は個々のユーザーに割り当てられ、複数のユーザー間で共有されない。
物理/論理コントロールにより、意図したユーザーのみがその要素を使用してアクセスできることが保証される。		 Windows Hello for Business、FIDO2 セキュリティ キー、携帯電話を使用したサインインのための Microsoft Authenticator アプリなど、パスワードレスの認証方法を使用します。 ユーザーに関連付けられた公開または秘密キーペアに基づくスマート カードを使用して再利用を防ぎます。

8.4 カード所有者データ環境 (CDE) へのアクセスをセキュリティで保護するために、多要素認証 (MFA) が実装されている

PCI-DSS で定義されたアプローチの要件 Microsoft Entra のガイダンスとレコメンデーション
8.4.1 管理アクセス権を持つ担当者がコンソール以外から CDE にアクセスする場合に、すべてのアクセスに対して MFA が実装されている。 条件付きアクセスを使用して、CDE リソースへのアクセスに強力な認証を要求します。 管理ロール、またはアプリケーションへの管理アクセスを表すセキュリティ グループを対象とするポリシーを定義します。
管理アクセスの場合は、Microsoft Entra Privileged Identity Management (PIM) を使用して、特権ロールの Just-In-Time (JIT) アクティブ化を有効にします。 条件付きアクセスとは
条件付きアクセス テンプレート
PIM の使用を開始する
8.4.2 CDE へのすべてのアクセスに対して MFA が実装されている。 強力な認証をサポートしていないレガシ プロトコルへのアクセスをブロックします。 条件付きアクセスを使用して Microsoft Entra ID へのレガシ認証をブロックする
8.4.3 エンティティのネットワークの外部から発信され、CDE にアクセスするか、CDE に影響を与える可能性がある、次のようなリモート ネットワーク アクセスのすべてに対して MFA が実装されている:
エンティティのネットワークの外部から発信される、すべての担当者 (ユーザーと管理者の両方) によるすべてのリモート アクセス。
サード パーティとベンダーによるすべてのリモート アクセス。		 認証と認可のために、仮想プライベート ネットワーク (VPN)、リモート デスクトップ、ネットワーク アクセス ポイントなどのアクセス テクノロジを Microsoft Entra ID と統合します。 条件付きアクセスを使用して、リモート アクセス アプリケーションへのアクセスに強力な認証を要求します。 条件付きアクセス テンプレート

8.5 多要素認証 (MFA) システムが誤用を防止するように構成されている。

PCI-DSS で定義されたアプローチの要件 Microsoft Entra のガイダンスとレコメンデーション
8.5.1 MFA システムが次のように実装されている:
MFA システムはリプレイ攻撃の影響を受けない。
MFA システムは、具体的に文書化され、管理者によって例外ベースかつ期間限定で認可されている場合を除き、管理ユーザーを含むどのユーザーによってもバイパスできない。
少なくとも 2 種類の認証要素が使用されている。
アクセスが許可される前に、すべての認証要素の成功が必要である。		 推奨の Azure AD 認証方法では、nonce またはチャレンジを使用します。 これらの方法は、再生された認証トランザクションを Microsoft Entra ID が検出できるため、再生攻撃に対する耐性があります。
Windows Hello for Business、FIDO2、パスワードレスの携帯電話サインイン用の Microsoft Authenticator アプリでは、nonce を使用して要求を特定し、リプレイ試行を検出します。 CDE でパスワードレスの資格情報をユーザーに使用します。
証明書ベースの認証では、チャレンジを使用してリプレイ試行を検出します。
Microsoft Entra ID を持つ NIST 認証システム保証レベル 2
Microsoft Entra ID を使用した NIST 認証システム保証レベル 3

8.6 アプリケーション アカウントとシステム アカウント、および関連する認証要素の使用が厳密に管理されている。

PCI-DSS で定義されたアプローチの要件 Microsoft Entra のガイダンスとレコメンデーション
8.6.1 システムまたはアプリケーションで使用されるアカウントを対話型ログインに使用できる場合、アカウントが次のように管理されている:
例外的な状況で必要な場合を除き、対話型の使用は防止される。
対話型の使用は、例外的な状況で必要な時間に限定されている。
対話型の使用について、業務上の正当な理由が文書化されている。
対話型の使用は管理者によって明示的に承認される。
アカウントへのアクセスが許可される前に、個々のユーザー ID が確認される。
実行されるすべてのアクションは、個々のユーザーに起因します。		 先進認証を使用する CDE アプリケーションと、Azure にデプロイされ先進認証を使用する CDE リソースの場合、Microsoft Entra ID には、マネージド ID とサービス プリンシパルという 2 種類のサービス アカウントがあります。
Microsoft Entra サービス アカウントのガバナンス (計画、プロビジョニング、ライフサイクル、監視、アクセス レビューなど) について確認します。Microsoft Entra サービス アカウントの管理
Microsoft Entra サービス アカウントをセキュリティで保護します。 Microsoft Entra ID のマネージド ID のセキュリティ保護
Microsoft Entra ID でのサービス プリンシパルのセキュリティ保護
アクセスが必要なリソースが Azure の外部にある CDE の場合は、シークレットや対話型サインインを管理せずに、ワークロードの ID フェデレーションを構成します。 ワークロード ID フェデレーション
要件を満たすために承認と追跡のプロセスを有効にするには、IT サービスマネジメント (ITSM) と構成管理データベース (CMDB) を使用してワークフローを調整します。これらのツールは、MS Graph API を使用して Microsoft Entra ID と対話し、サービス アカウントを管理します。
オンプレミスの Active Directory と互換性のあるサービス アカウントが必要な CDE の場合は、グループ管理サービス アカウント (GMSA) と、スタンドアロン マネージド サービス アカウント (sMSA)、コンピューター アカウント、またはユーザー アカウントを使用します。 オンプレミスのサービス アカウントのセキュリティ保護
8.6.2 対話型ログインに使用できるアプリケーションおよびシステム アカウントのパスワード/パスフレーズが、スクリプト、構成/プロパティ ファイル、または、特注およびカスタムのソース コードにハードコーディングされていない。 Azure マネージド ID やサービス プリンシパルなど、パスワードを必要としない最新のサービス アカウントを使用します。
Microsoft Entra マネージド ID の資格情報はプロビジョニングされ、クラウドでローテーションされます。これにより、パスワードやパスフレーズなどの共有シークレットの使用を防ぎます。 システム割り当てマネージド ID を使用する場合、ライフサイクルは基になる Azure リソースのライフサイクルに関連付けられます。
サービス プリンシパルを使用して証明書を資格情報として使用します。これにより、パスワードやパスフレーズなどの共有シークレットの使用を防ぎます。 証明書が使用できない場合は、Azure Key Vault を使用してサービス プリンシパルのクライアント シークレットを格納します。 Azure Key Vault を使用するためのベスト プラクティス
アクセスが必要なリソースが Azure の外部にある CDE の場合は、シークレットや対話型サインインを管理せずに、ワークロードの ID フェデレーションを構成します。 ワークロード ID フェデレーション
ワークロード ID の条件付きアクセスをデプロイし、場所やリスク レベルに基づいて認可を制御します。 ワークロード ID 用の条件付きアクセス
前のガイダンスに加えて、コード分析ツールを使用して、コードと構成ファイル内のハードコーディングされたシークレットを検出します。 コード内で公開されているシークレットを検出する
セキュリティ規則
8.6.3 アプリケーションおよびシステム アカウントのパスワード/パスフレーズが、次のように誤用や悪用から保護されている:
パスワード/パスフレーズが定期的に (要件 12.3.1 で指定されたすべての要素に従って実行される、エンティティの対象指定リスク分析で定義された頻度で) 変更される。
パスワード/パスフレーズは、エンティティがパスワード/パスフレーズを変更する頻度に適した十分な複雑さで構築されている。		 Azure マネージド ID やサービス プリンシパルなど、パスワードを必要としない最新のサービス アカウントを使用します。
シークレットを含むサービス プリンシパルを必要とする例外の場合は、サービス プリンシパルにランダムなパスワードを設定し、パスワードを定期的にローテーションし、リスク イベントに対応するワークフローと自動化を使用して、シークレット ライフサイクルを抽象化します。
セキュリティ運用チームは、危険なワークロード ID など、Microsoft Entra によって生成されたレポートを確認して修復できます。 Identity Protection でワークロード ID のセキュリティ保護。

次のステップ

PCI-DSS 要件 3、4、9、12 は Microsoft Entra ID には適用されないため、対応する記事はありません。 すべての要件を確認するには、PCI Security Standards Council 公式サイト (pcisecuritystandards.org) にアクセスしてください。

PCI-DSS に準拠するように Microsoft Entra ID を構成するには、次の記事をご覧ください。