IAM Identity CenterのMFA、外部IdPではAWS側に設定しない

|著者: QUASA編集チーム|2 分で読めます| 1
IAM Identity CenterのMFA、外部IdPではAWS側に設定しない

AWSのMFA設定条件では、IAM Identity Center側でMFAを設定できるIDソースをIdentity CenterのIDストア、AWS Managed Microsoft AD、AD Connectorとし、外部IdPを対象外としている。外部IdPを使う組織は、MFAの要求条件と認証器の登録をそのIdP側で管理する。設定画面を探す前に、利用中のIDソースを確かめることが作業の出発点だ。

Identity Center側で設定できる構成なら、次にAWSアクセスポータルへのサインインでMFAを求める頻度と、利用を許可する認証方式を決める。主な認証器を失った際にアクセスが止まらないよう、予備認証器と管理者への連絡経路も、利用者へ展開する前に用意しておく。

IDソースで設定先を分ける

IAM Identity Centerのコンソールで「Settings」を開き、「Identity source」に表示される設定を確認する。ここで判定するのは、AWSアカウントで利用者に割り当てた権限ではなく、AWSアクセスポータルへのサインインに使うIDソースだ。IAMユーザーやルートユーザーのMFAとも設定対象が異なる。

  • Identity CenterのIDストアなら、IAM Identity Center側のMFA設定へ進む。
  • AWS Managed Microsoft ADまたはAD Connectorなら、ディレクトリ側で既に使っているMFAも確認してから、ポータルで使う方式を決める。
  • 外部IdPなら、MFAポリシー、認証器の登録、紛失時の復旧を外部IdPの管理手順で扱う。

外部IdPを利用している場合、IAM Identity Centerの「Multi-factor authentication」設定欄は表示されない。AWSアクセスポータルでアカウントやアプリケーションへのアクセスを管理していても、外部IdPによる本人確認の設定先までIdentity Centerに移るわけではない。設定欄が見つからないときは、まずIDソースと実際のサインイン経路を照合する。

ポータルでMFAを求める頻度を決める

Identity Center側で設定する場合は、コンソールの「Settings」から「Authentication」を開き、「Multi-factor authentication」の「Configure」に進む。AWSの要求頻度の手順には、サインインのたびに求める設定、サインイン状況が変わったときに求める設定、Identity Center側のMFAを無効にする設定が示されている。外部IdPの利用者については、この画面ではなくIdP側で要求頻度を管理する。

「Every time they sign in」は、AWSアクセスポータルにサインインするたびに、登録済みの認証器による確認を求める。「Only when their sign-in context changes」では、利用者が端末を信頼済みにした後、端末、ブラウザ、場所などの状況に応じて次回以降の確認を判断する。同じ環境からの再サインインでも毎回MFAが必要という要件なら、前者を選ぶ。

「Never」はIdentity Center側のMFAを無効にする選択だ。Directory Serviceで設定したRADIUS MFAをAWSアクセスポータルでも使い続ける構成では、この選択が必要になる場合がある。無効にする前に、追加認証をどこで実施する構成なのかを確認する。

FIDO2、認証アプリ、RADIUSから方式を選ぶ

AWSの対応方式一覧には、FIDO2認証器、仮想認証アプリ、AWS Managed Microsoft AD経由のRADIUS MFAが記載されている。利用者が登録できるMFAデバイスは最大8台で、内訳は仮想認証アプリが最大2つ、FIDO認証器が最大6つだ。この上限は予備を追加できる余地であり、全種類を登録する必要があるという意味ではない。

FIDO2には端末内蔵の認証器と外付けのセキュリティキーがある。認証先ごとに固有の資格情報を使うため、フィッシングへの耐性を重視する場合に適している。組織で採用するなら、利用者が実際に使う端末やブラウザで登録とサインインができるかを展開前に確かめる。

仮想認証アプリは、スマートフォンなどのアプリが生成するワンタイムコードを入力する方式だ。利用者が使える端末を活用できる一方、主な認証器と予備を同じ端末だけに置けば、その端末の紛失や故障に同時に影響される。予備の置き場所まで含めて方式を選ぶ。

Active DirectoryでRADIUS MFAを運用している場合、AWSアクセスポータルではRADIUS MFAとIdentity Center側のMFAを同時に適用する構成にはならない。Identity Center側のMFAを有効にすると、ポータルへのサインインでは既存のRADIUS MFAよりそちらが優先される。Directory Serviceに対応する他のアプリケーションではRADIUS MFAが引き続き使われるため、ポータルと他のアプリへの影響を分けて確認する。

利用者への展開は予備の登録まで含める

要求頻度と方式を保存したら、利用者が登録を完了できるかを確認する。初回サインイン時の登録を利用者に任せる運用なら、許可した方式に対応する端末を用意できることと、予備を追加する方法を案内しておくことが必要だ。登録済み一覧に認証器が表示されるだけで終えず、AWSアクセスポータルへのサインインでも確認する。

  1. IDソースを記録し、外部IdPの利用者についてはIdP側のMFA担当者と設定手順を確認する。
  2. Identity Center側で設定する構成について、ポータルでの要求頻度と利用を許可する認証方式を決める。
  3. 利用者に主な認証器を登録してもらい、別の端末や保管場所にある予備認証器も登録する。
  4. 主な認証器でポータルにサインインできることを確認し、続けて予備も使えることを確かめる。
  5. 両方を使えなくなった場合の連絡先と、再登録を担当する管理者を利用者に伝える。

例えば主な方式がノートPC内蔵の認証器なら、予備をそのPCだけに依存させない。外付けのセキュリティキーや別の端末の認証アプリを選ぶ場合も、実際の利用環境で予備によるサインインを確認しておく。予備が機能すれば、主な端末を使えなくなっても復旧までの選択肢が残る。

認証器を失った場合の復旧経路

すべての認証器を使えなくなった場合に備え、管理者への連絡方法、本人確認の担当者、失われた認証器の登録を見直す手順、再登録後のサインイン確認を運用手順に入れる。利用者がポータルへ入れない状態でも連絡できる経路を用意する。外部IdPの利用者については、認証器の復旧窓口もそのIdP側の手順に合わせる。

メールで届く確認コードを運用に含める場合は、そのメールを読むためにAWSアクセスポータルへのサインインが必要かを調べる。ポータルに入れなければメールも読めない構成では、コードを受け取る手段として機能しない。予備認証器に加え、ポータルに依存しない連絡経路を確保しておく。

復旧手順は、主な認証器を使えない状況を想定して確認する。予備でサインインできるか、予備も使えないときに担当者へ連絡できるか、再登録後にポータルへ戻れるかを順に確かめれば、登録作業と紛失時の対応が同じIDソースの判定に沿ってつながる。

関連記事：

共有:

関連記事

ニュースレターを購読

Web3、AI、暗号資産の最新ニュースを受信箱にお届けします。

0