Microsoft Entra ID で FedRAMP High Impact レベルを満たすように識別と認証の制御を構成する
識別と認証は、Federal Risk and Authorization Management Program (FedRAMP) の High Impact レベルを実現するための手段です。
識別と認証 (IA) ファミリの制御と制御の強化に関する次の一覧は、Microsoft Entra テナントでの構成が必要になる場合があります。
| 制御ファミリ | 説明 |
|---|---|
| IA-2 | 識別と認証 (組織のユーザー) |
| IA-3 | デバイスの識別と認証 |
| IA-4 | 識別子の管理 |
| IA-5 | 認証システムの管理 |
| IA-6 | 認証システムのフィードバック |
| IA-7 | 暗号化モジュールの認証 |
| IA-8 | 識別と認証 (組織外のユーザー) |
次の表の各行に、制御または制御の強化のための共同責任に対する組織の対応を構築するために役立つ規範的なガイダンスを示します。
構成
| FedRAMP コントロール ID と説明 | Microsoft Entra のガイダンスとレコメンデーション |
|---|---|
| IA-2 ユーザーの識別と認証 情報システムでは、組織のユーザー (または、組織のユーザーに代わって行動する行為) を一意に識別し、認証する。 |
ユーザーまたはユーザーのために動作するプロセスを一意に識別して認証します。 Microsoft Entra ID では、ユーザーとサービス プリンシパルのオブジェクトが直接一意に識別されます。 Microsoft Entra ID には複数の認証方法が用意されており、米国国立標準技術研究所 (NIST) の認証保証レベル (AAL) 3 に準拠する方法を構成できます。 識別子 認証と多要素認証 |
| IA-2(1) 情報システムでは、特権のあるアカウントへのネットワーク アクセスのための多要素認証を実装する。 IA-2(3) 情報システムでは、特権のあるアカウントへのローカル アクセスのための多要素認証を実装する。 |
特権アカウントへのすべてのアクセスに対する多要素認証。 特権アカウントへのすべてのアクセスに多要素認証が必要になるように、完全なソリューションとして次の要素を構成します。 すべてのユーザーに多要素認証を要求する条件付きアクセス ポリシーを構成します。 Privileged Identity Management のアクティブ化の要件がある場合、ネットワーク アクセスがないと特権アカウントのアクティブ化を行うことができないため、ローカル アクセスでは特権を持つことができません。 多要素認証と Privileged Identity Management |
| IA-2(2) 情報システムでは、特権のないアカウントへのネットワーク アクセスのための多要素認証を実装する。 IA-2(4) 情報システムでは、特権のないアカウントへのローカル アクセスのための多要素認証を実装する。 |
非特権アカウントへのすべてのアクセスに対して多要素認証を実装する 非特権アカウントへのすべてのアクセスに MFA が必須になるように、全体的なソリューションとして次の要素を構成します。 すべてのユーザーに MFA を必須にするように、条件付きアクセス ポリシーを構成します。 Microsoft では、多要素暗号化ハードウェア認証システム (FIDO2 セキュリティ キー、Windows Hello for Business (ハードウェア TPM を搭載)、スマート カードなど) を使って AAL3 を達成することをお勧めします。 組織がクラウドベースの場合は、FIDO2 セキュリティ キーまたは Windows Hello for Business を使うことをお勧めします。 Windows Hello for Business は、必要な FIPS 140 セキュリティ レベルで検証済みではないため、連邦政府のお客様は、AAL3 としてそれを受け入れる前にリスク評価と評価を行う必要があります。 Windows Hello for Business の FIPS 140 検証の詳細については、Microsoft NIST AAL に関するページを参照してください。 MDM ポリシーに関する次のガイダンスを参照してください。認証方法によって若干異なります。 スマート カード/Windows Hello for Business ハイブリッドのみ スマートカードのみ FIDO2 セキュリティ キー 認証方法 その他の情報 |
| IA-2(5) 組織は、グループ認証子が使用されている場合、個人に個々の認証子で認証を受けることを要求する。 |
複数のユーザーが共有またはグループ アカウントのパスワードにアクセスできる場合に、最初に各ユーザーに個々の認証システムを使用して認証するように要求します。 ユーザーごとに個別のアカウントを使用します。 共有アカウントが必要な場合、Microsoft Entra ID では、各ユーザーが個別の認証システムを持つように、複数の認証システムを 1 つのアカウントにバインドすることが許可されます。 リソース |
| IA-2(8) 情報システムでは、特権のあるアカウントへのネットワーク アクセスのための、リプレイに対する抵抗力のある認証メカニズムを実装する。 |
特権アカウントへのネットワーク アクセスのために、リプレイ耐性のある認証メカニズムを実装します。 すべてのユーザーに多要素認証を要求する条件付きアクセス ポリシーを構成します。 認証保証レベル 2 および 3 のすべての Microsoft Entra 認証方法では、nonce またはチャレンジのいずれかが使用され、リプレイ攻撃に対する耐性があります。 References |
| IA-2(11) 組織は、アクセスするシステムから切り離されたデバイスによって要素のいずれかが提供され、そのデバイスが ["FedRAMP 割り当て: FIPS 140-2、NIAP" 認定、または NSA 承認*] を満たすといった、特権ありおよび特権なしのアカウントへのリモート アクセスのための多要素認証を実装する。 *National Information Assurance Partnership (NIAP) 追加の FedRAMP 要件とガイダンス: ガイダンス: PIV = 別個のデバイス。 NIST SP 800-157 派生した個人の本人確認 (PIV) の資格情報に関するガイダンスを参照してください。 FIPS 140-2 は、暗号化モジュール検証プログラム (CMVP) によって検証されることを意味します。 |
アクセス権を取得するシステムとは別のデバイスが FIPS 140-2、NIAP 認定、または NSA 承認を満たしている場合に、そのデバイスによって要素のいずれかが提供されるように、お客様がデプロイしたリソースにリモートでアクセスするために、Microsoft Entra 多要素認証を実装します。 IA-02(1-4) のガイダンスを参照してください。 AAL3 で検討すべき個別のデバイス要件を満たす Microsoft Entra 認証方法は、次のとおりです。 FIDO2 セキュリティ キー リファレンス |
| **IA-2(12)* 情報システムでは、個人の本人確認 (PIV) の資格情報を受け入れ、電子的に検証する。 IA-2 (12) 追加の FedRAMP 要件とガイダンス: ガイダンス: Common Access Card (CAC) (つまり、PIV/FIPS 201/HSPD-12 の DoD 技術的な実装) が含まれています。 |
本人確認 (PIV) 資格情報を受け入れて検証します。 お客様が PIV 資格情報をデプロイしない場合、この制御は適用されません。 PIV (証明書認証) をプライマリおよび多要素認証の方法の両方として受け入れ、PIV が使用されるときに多要素認証 (MultipleAuthN) 要求を発行するように、Active Directory フェデレーション サービス (AD FS) を使用することにより、フェデレーション認証を構成します。 Microsoft Entra ID で発信される多要素認証要求を Active Directory フェデレーション サービス (AD FS) に送信するには、federatedIdpMfaBehavior を リソース |
| IA-3 デバイスの識別と認証 情報システムでは、["選択項目 (1 つ以上): ローカル; リモート; ネットワーク] 接続を確立する前に、[割り当て: 組織が定義した特定/種類のデバイス"] を一意に識別し、認証する。 |
接続を確立する前に、デバイスの識別と認証を実装します。 Microsoft Entra ID を構成して、Microsoft Entra 登録済み、Microsoft Entra 参加済み、Microsoft Entra ハイブリッド参加済みデバイスを識別して認証します。 リソース |
| IA-04 識別子の管理 組織は、ユーザーとデバイスの情報システム識別子を次の方法で管理する。 (a.) 個人、グループ、役割、またはデバイス識別子を割り当てるための ["FedRAMP 割り当て: ISSO (または組織内の同様の役割) 以上] から認可を受ける。 (b.) 個人、グループ、役割、またはデバイスを識別する識別子を選択する。 (c.) 目的の個人、グループ、役割、またはデバイスに識別子を割り当てる。 (d.) ["FedRAMP 割り当て: 少なくとも 2 年間"]、識別子の再利用を禁止する。 (e.) ["FedRAMP 割り当て: 35 日 (要件とガイダンスを参照)"] 後に識別子を無効にする IA-4e 追加の FedRAMP 要件とガイダンス: 要件: サービス プロバイダーは、デバイス識別子の非アクティブ期間を定義する。 ガイダンス: DoD クラウドの場合は、FedRAMP に加えて特定の DoD の要件について DoD クラウドの Web サイトを参照してください。 IA-4(4) 組織は、各個人を ["FedRAMP 割り当て: 請負業者; 外国人"] として一意に識別することで、個々の識別子を管理する。 |
非アクティブな状態が 35 日間続いた後でアカウント識別子を無効にして、2 年間再利用できないようにします。 各個人を一意に識別することで個々の識別子を管理します (請負業者、外国人など)。 AC-02 で定義されている既存の組織ポリシーに従って、Microsoft Entra ID で個々のアカウント識別子と状態を割り当てて管理します。 AC-02(3) に従って、非アクティブな状態が 35 日間続いた後で、ユーザーとデバイスのアカウントを自動的に無効にします。 組織のポリシーにより、少なくとも 2 年間は無効状態のままですべてのアカウントが維持されるようにします。 この時間が経過したら、削除することができます。 非アクティブ状態を判断する |
| IA-5 認証子の管理 組織は、次の方法で情報システム認証子を管理する。 (a.) 初期認証子の配布の一環として、認証子を受け取る個人、グループ、役割、またはデバイスの ID を検証する。 (b.) 組織によって定義された認証子の初期認証子の内容を設定する。 (c.) 認証子が意図した使用に対して十分なメカニズムの強度を持つようにする。 (d.) 初期認証子の配布、認証子の紛失/セキュリティ侵害または破損、認証子の失効の場合の管理手順を確立し、実装する。 (e.) 情報システムをインストールする前に認証子の既定の内容を変更する。 (f.) 認証子の最小および最大の有効期間の制限と再利用条件を設定する。 (g.) ["割り当て: 組織が定義した認証子の種類別の期間"] 認証子を変更/更新する。 (h.) 認可されていない開示および変更から認証子の内容を保護する。 (i.) 認証子を保護するための具体的なセキュリティ対策を取ることを個人に要求し、デバイスで実装する。 (j.) これらのアカウントに対するメンバーシップが変更されたときに、グループ/役割のアカウントの認証子を変更する。 IA-5 追加の FedRAMP 要件とガイダンス: 要件: 認証子は、NIST SP 800-63-3 デジタル ID ガイドライン IAL、AAL、FAL レベル 3 に準拠している必要がある。 リンク https://pages.nist.gov/800-63-3 |
情報システムの認証システムを構成および管理します。 Microsoft Entra ID では、さまざまな認証方法がサポートされています。 既存の組織のポリシーを使用して管理することができます。 IA-02(1-4) での認証システムの選択に関するガイダンスを参照してください。 SSPR と Microsoft Entra 多要素認証の統合された登録でユーザーを有効にし、自己修復を容易にするために、少なくとも 2 つの使用可能な多要素認証方法を登録するようにユーザーに要求します。 認証方法 API を使用して、ユーザーが構成した認証システムをいつでも取り消すことができます。 認証システムの強度/認証システムの内容の保護 認証方法と統合された登録 認証システムの取り消し |
| IA-5(1) 情報システムでは、パスワード ベースの認証の場合、次のようにする。 (a.) ["割り当て: 組織が定義した、タイプごとの最小要件を含む大文字小文字の区別、文字数、大文字、小文字、数字、特殊文字の混在の要件"] の最小限のパスワードの複雑さを適用する。 (b.) 新しいパスワードの作成時に、少なくとも次の変更された文字数を適用する。["FedRAMP 割り当て: 少なくとも 50%"]。 (c.) 暗号で保護されたパスワードのみを格納して送信する。 (d.) ["割り当て: 組織が定義した有効期間の最小、有効期間の最大の数"] のパスワードの最小および最大有効期間の制限を適用する。 (e.)** ["FedRAMP 割り当て: 24"] の生成回数についてパスワードの再利用を禁止する。 (f.) システム ログオン時、常用パスワードに即時変更することで一時的なパスワードの使用を許可する。 IA-5 (1) a および d 追加の FedRAMP 要件とガイダンス: ガイダンス: パスワード ポリシーが NIST SP 800-63B 記憶シークレット (セクション 5.1.1) のガイダンスに準拠している場合、コントロールは準拠と見なされることがある。 |
パスワードベースの認証要件を実装します。 NIST SP 800-63B セクション 5.1.1 に準拠: 一般的に使用されたり、予想されたり、または侵害されたりするパスワードの一覧を保持します。 Microsoft Entra パスワード保護では、既定のグローバル禁止パスワード リストが Microsoft Entra テナント内のすべてのユーザーに自動的に適用されます。 ビジネス ニーズやセキュリティ ニーズに対応するため、カスタムの禁止パスワード リストにエントリを定義できます。 ユーザーがパスワードを変更またはリセットすると、これらの禁止パスワード リストがチェックされ、強力なパスワードの使用が強制されます。 パスワードレスの戦略を強くお勧めします。 この制御はパスワード認証システムにのみ適用されるため、使用可能な認証システムとしてパスワードを削除すると、この制御は適用されません。 NIST のリファレンス ドキュメント リソース |
| IA-5(2) 情報システムでは、PKI ベースの認証の場合、次のようにする。 (a.) 証明書の状態情報の検査を含め、受け入れ済みのトラスト アンカーへの証明書パスを構築し、検証することによって、証明書を検証する。 (b.) 対応する秘密キーへの認可済みのアクセス権を適用する。 (c.) 認証された ID を個人またはグループのアカウントにマップする。 (d.) ネットワーク経由で失効情報にアクセスできない間のパスの検出と検証をサポートするために、失効データのローカル キャッシュを実装する。 |
PKI ベースの認証要件を実装します。 AD FS 経由で Microsoft Entra ID をフェデレーションして、PKI ベースの認証を実装します。 既定では、AD FS によって証明書が検証され、ローカルで失効データがキャッシュされ、ユーザーが Active Directory の認証済み ID にマップされます。 リソース |
| IA-5(4) 組織は、パスワード認証子が ["FedRAMP 割り当て: IA-5 (1) 制御の強化 (H) パート A で識別された複雑さ"] を満たすのに十分な強度であるかどうかを判別するための自動化されたツールを採用する。 IA-5(4) 追加の FedRAMP 要件とガイダンス: ガイダンス: 作成時にパスワード認証子の強度を適用する自動化されたメカニズムを使わない場合は、作成されたパスワード認証子の強度を監査するために自動化されたメカニズムを使う必要があります。 |
自動ツールを使用してパスワードの強度要件を検証します。 Microsoft Entra ID では、作成時にパスワード認証システムの強度を適用する自動化されたメカニズムが実装されます。 この自動化されたメカニズムを拡張して、オンプレミスの Active Directory のパスワード認証システムの強度を適用することもできます。 NIST 800-53 のリビジョン 5 では、IA-04(4) を廃止し、要件を IA-5(1) に組み込みました。 リソース |
| IA-5(6) 組織は、認証子を使用することでアクセスが許可される情報のセキュリティ カテゴリに応じて、認証子を保護する。 |
FedRAMP High Impact レベルで定義されている認証システムを保護します。 Microsoft Entra ID が認証子を保護する方法の詳細については、Microsoft Entra データ セキュリティに関する考慮事項に関するページを参照してください。 |
| IA-05(7) 組織は、暗号化されていない静的認証子がアプリケーションやアクセス スクリプトに埋め込まれたりファンクション キーに格納されたりしないようにする。 |
暗号化されていない静的認証システム (パスワードなど) が、アプリケーションやアクセス スクリプトに埋め込まれたり、ファンクション キーに格納されたりしないようにします。 マネージド ID またはサービス プリンシパルのオブジェクト (証明書のみで構成済み) を実装します。 リソース |
| IA-5(8) 組織は、["FedRAMP 割り当て: 異なるシステム上の異なる認証子"] を実装して、個人が複数の情報システムのアカウントを持つことによる侵害のリスクを管理する。 |
個人が複数の情報システムにアカウントを持っている場合のセキュリティ保護を実装します。 複数の情報システムで個別のアカウントを持つのではなく、すべてのアプリケーションを Microsoft Entra ID に接続することで、シングル サインオンを実装します。 |
| IA-5(11) 情報システムでは、ハードウェア トークン ベースの認証の場合、["割り当て: 組織が定義したトークン品質の要件"] を満たすメカニズムを採用する。 |
FedRAMP High Impact レベルで必要とされるハードウェア トークンの品質要件を必須にします。 AAL3 を満たすハードウェア トークンの使用を必須にします。 |
| IA-5(13) 情報システムでは、["割り当て: 組織が定義した期間"] 後のキャッシュされた認証子の使用を禁止する。 |
キャッシュされた認証システムの有効期限を適用します。 ネットワークが利用できないときは、キャッシュされた認証システムが、ローカル マシンに対して認証を行うために使用されます。 キャッシュされた認証システムの使用を制限するには、Windows デバイスの使用を無効にするように構成します。 このアクションが不可能か実用的でない場合は、次の補完的な制御を使用します。 Office アプリケーションに適用される制限を使うことにより、条件付きアクセス セッション制御を構成します。 リソース |
| IA-6 認証子のフィードバック 情報システムでは、悪用や認可されていない個人による使用の可能性から情報を保護するために、認証プロセス中は認証情報のフィードバックを隠す。 |
認証プロセス中に認証フィードバック情報を不明瞭にします。 既定では、Microsoft Entra ID ですべての認証子フィードバックが隠されます。 |
| IA-7 暗号化モジュールの認証 情報システムでは、該当の連邦法、行政命令、命令、ポリシー、規制、標準、このような認証のガイダンスの要件に対する暗号化モジュールの認証メカニズムを実装する。 |
適用可能な連邦法を満たす暗号化モジュールへの認証のためのメカニズムを実装します。 FedRAMP High Impact レベルでは、AAL3 認証システムが必要となります。 AAL3 の Microsoft Entra ID でサポートされているすべての認証システムは、必要に応じて、モジュールへのオペレーター アクセスを認証するためのメカニズムを提供します。 たとえば、ハードウェア TPM を搭載した Windows Hello for Business のデプロイでは、TPM 所有者の承認レベルを構成します。 リソース |
| IA-8 識別と認証 (組織外のユーザー) 情報システムは、組織外のユーザー (または、組織外のユーザーに代わって行動する行為) を一意に識別し、認証します。 |
情報システムでは、組織外のユーザー (または、組織外のユーザーのために動作するプロセス) が一意に識別され、認証されます。 Microsoft Entra ID では、組織のテナント、または FICAM (Federal Identity, Credential, and Access Management) 承認済みプロトコルを使用する外部ディレクトリに所属する組織以外のユーザーを、一意に識別して認証します。 リソース |
| IA-8(1) 情報システムでは、他の連邦機関の個人の本人確認 (PIV) の資格情報を受け入れ、電子的に検証する。 IA-8(4) 情報システムは、FICAM 発行のプロファイルに準拠する。 |
他の政府機関によって発行された PIV 資格情報を受け入れて検証します。 FICAM によって発行されたプロファイルに従います。 フェデレーション (OIDC、SAML) 経由で、または統合 Windows 認証経由でローカルに PIV 資格情報を受け入れるように Microsoft Entra ID を構成します。 リソース |
| IA-8(2) 情報システムでは、FICAM で承認されたサード パーティの資格情報のみを受け入れる。 |
FICAM で承認された資格情報のみを受け入れます。 Microsoft Entra ID では、NIST AAL 1、2、3 の認証システムがサポートされています。 アクセスするシステムのセキュリティ カテゴリに応じて、認証システムの使用を制限します。 Microsoft Entra ID では、さまざまな認証方法がサポートされています。 リソース |