目次
▽ご挨拶
はじめましての方ははじめまして、皆様御機嫌よう、らいむ(ぱちもん)でございます。
さて、早速ですが本日は「MFA認証とIAMポリシー」についてご紹介したいと思います。
皆様、AWSを利用していて「特定のユーザにMFA認証のデバイス登録が許可されていない」
といった事象にお困りになったことはありますでしょうか?
私は最近、新しく作成したIAMユーザでMFA認証のデバイス登録をしようとしたところ、
「あなたの権限では許可されていないよ」とAWSからもんk...警告をいただきました。
なんやかんや調べて試してを繰り返して解決したので皆さんにお伝えしたいと思います!
それでは何をどうしたか紹介していきます!
▽前菜-MFA認証とは
...と本編に行く前にちょっとした前置きです。
そもそもMFAとはなんなのか、軽く触れてみます。
もし、ご存じだったら飛ばして行きましょ!
■MFA認証とは
正規式名称は、Multi-Factor Authentication
漢字で書くと、多要素認証
ログイン時に認証するにあたって「知識情報」「所持情報」「生体情報」の3要素から
2つ以上の異なる要素を用いて認証する方法のことを指します。
▽詳しくは以下の通り
「知識情報」⇒その人が持ってる情報 ID/パスワード/秘密の質問...など
「所持情報」⇒その人が所持しているものに付属する情報 携帯電話などを用いたSMS認証/所持しているデバイスを通じて生成されるワンタイムパスワード...など
「生体情報」⇒その人の身体的な情報 指紋/声紋/虹彩/静脈/位置情報...など
AWSでユーザIDとパスワードを入力した後に遷移したページで数字入力を求められるアレですね。
見覚えある人はあると思います。これは「知識情報」のID/パスワードを認証した後に「所持情報」のコードを求められるといった感じでしょう。
▽やってみた
■現象再現
-前準備-
それでは早速ですが、なにもしていない産まれたてほやほやのIAMユーザちゃんにMFAデバイスを追加してみましょう。
...といいつつも「閲覧可能になるポリシー」がアタッチされてないと以下の画像のように自分のユーザの状態すら閲覧できない状態になってとても悲しいので、もしここで詰まったら以下のポリシーを追加してあげましょう。
(アタッチ方法はこのページの後半でも紹介しています!)
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
対象ポリシー
ポリシー名 :ReadOnlyAccess
タイプ :AWS管理-ジョブ機能
アタッチ方法:直接
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
-状態確認-
それでは仕切りなおして、閲覧権限だけ付与されたIAMユーザでMFA認証のデバイスを登録してみましょう。
IAMユーザのダッシュボードからログインしているアカウント(登録したいアカウント)の詳細ページに遷移し、
「セキュリティ認証情報」タブの「多要素認証(MFA)」のフィールド内にある「MFAデバイスの割り当て」をクリックしましょう。
そうすると、MFAデバイスの登録画面に進むので任意のデバイス名とデバイスの種類を入力し、「次へ」をクリックします。
2023-09-13 15:51:30 Wednesday
すると下記のような警告が出てMFAの追加に至りません。
ここまででMFAの許可ができない状態は再現できました。
次に、解消するために原因を探っていきましょう!
■原因
それでは、お楽しみの原因を読み解きましょう!
改めてエラー文を確認すると以下の内容が記載されていました。
▽エラー文
許可が必要です この操作を実行するために必要な許可がありません。許可を追加するように管理者に依頼してください。
User: arn:aws:iam::012345678910:user/Lime-test is not authorized to perform: iam:CreateVirtualMFADevice on resource: arn:aws:iam::012345678910:mfa/AAAATEST because no identity-based policy allows the iam:CreateVirtualMFADevice action
▽エラー文を翻訳
対象のユーザ(Lime-test)に対してCreateVirtualMFADeviceの権限がない為、MFAデバイス(AAAATEST)の登録ができませんでした。
このエラー文を読んでみると「解決するためには関連する権限を付けてあげればいいんだな」と繋がっていくと思います。
では、出来そうなことを見つけたので解決するために進んでみましょう!
■解読
今回は「MFAの設定をするポリシーをアタッチする」という方法で解決していきましょう!
「それじゃあCreateVirtualMFADeviceの許可を対象のIAMユーザに付与してあげれば良いんだ!」
...と思うじゃないですか。
もし、IAMユーザにCreateVirtualMFADeviceだけを許可してMFAデバイスの登録を試みると以下のようになります。
なんと、エラーが出てしまいましたね。
中身を確かめてみましょう!
▽エラー文
許可が必要です この操作を実行するために必要な許可がありません。許可を追加するように管理者に依頼してください。
User: arn:aws:iam::012345678910:user/Lime-test is not authorized to perform: iam:EnableMFADevice on resource: user Lime-test because no identity-based policy allows the iam:EnableMFADevice action
▽エラー文を翻訳
対象のユーザ(Lime-test)に対してEnableMFADeviceの権限がない為、 MFAデバイスの登録ができませんでした。
あれれ?先程と違うポリシーを求められてしまった!
そう、CreateVirtualMFADeviceをリクエストする許可をもらっても
「EnableMFADeviceをリクエストする許可を貰えてないので続きができませーん」
といった調子で芋づる式に必要なエラーや関連するポリシーが掘り出されて躓いてしまいます。
ではでは、次にそこら辺を整理して作成したポリシーを紹介したいと思います。
▽実装したポリシー
※「012345678910」の数字をご自身のAWSのアカウントIDに置き換えてください。
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:ListUsers"
],
"Resource": [
"arn:aws:iam::012345678910:user/"
]
},
{
"Effect": "Allow",
"Action": [
"iam:ListVirtualMFADevices"
],
"Resource": [
"arn:aws:iam::012345678910:mfa/"
]
},
{
"Effect": "Allow",
"Action": [
"iam:EnableMFADevice",
"iam:DeactivateMFADevice",
"iam:ResyncMFADevice"
],
"Resource": [
"arn:aws:iam::012345678910:user/${aws:username}"
]
},
{
"Effect": "Allow",
"Action": [
"iam:DeleteVirtualMFADevice",
"iam:CreateVirtualMFADevice",
"iam:ListMFADevices"
],
"Resource": [
"arn:aws:iam::012345678910:mfa/*",
"arn:aws:iam::012345678910:user/${aws:username}"
]
}
]
}
上記のポリシーを特定ユーザーにアタッチすることで、そのユーザがMFA認証様のデバイスを登録することができるようになります。
このJSONの文章の作りは、「どの"リソース"を対象に、どんな"アクション"を"許可/拒否"するか」といった要素を様々なパターン毎に記述しています。
一部分を切り取り解釈していくと以下の通りになります。
{
"Effect": "Allow", ⇒許可する
"Action": [
"iam:ListUsers" ⇒"iam"サービスの"ListUsers"APIのアクション
],
"Resource": [
"arn:aws:iam::012345678910:user/" ⇒指定のAWSアカウント上のすべてのユーザが対象
]
}
このポリシーがアタッチされたユーザアカウントは、
「"指定のAWSアカウント上のすべてのユーザ"を対象に、"iam"サービスの"ListUsers"APIのアクションの実施を"許可"される」
といったルールに則って制御されます。
ではでは、ポリシーの設定内容を解説する前にそれぞれの要素について簡単にまとめてみましょう。(今回登場する分だけ)
■ポリシー紹介
Effect
対象の"Resource"において、指定の"Action"をどうするかを指定する。OKかNGかの二択を指定する。
効果 | 意味 |
---|---|
Allow | 許可する |
Deny | 拒否する |
Action
サービス:APIアクションの形式で指定され、利用したいAPIをリクエストすることができます。
NotActionを使えば除外設定など可能。(今回は割愛)
以下のAPIの解説はすこしざっくりめにする(役割だけ解説) ⇒API名でググったらAWS公式のページで解説が読めます。
API名 | 意味 |
---|---|
ListUsers | ユーザプール内のユーザと詳細情報のリストを表示する。 |
ListVirtualMFADevices | AWSアカウントに定義されている仮想MFAデバイスのリストを表示する。 |
EnableMFADevice | 指定されたMFAデバイスを有効にし、指定されたIAMユーザーに関連付ける。 |
DeactivateMFADevice | 指定したMFAデバイスを非アクティブにし、元々有効になっていたユーザー名との関連付けから削除する。 |
ResyncMFADevice | 指定したMFAデバイスを、AWSサーバー上のIAMリソースオブジェクトと同期する |
DeleteVirtualMFADevice | 仮想MFAデバイスを削除する。 |
CreateVirtualMFADevice | 仮想MFAデバイスを作成する。仮想MFA を作成したら、EnableMFADeviceを使用してMFAデバイスをIAMユーザーにアタッチする。 |
ListMFADevices | IAMユーザーのMFAデバイスを一覧表示する。 |
Resource
対象のリソースをarnで指定する。リソースの種類や指定方法はサービスごとに異なるので注意が必要です。
また、ワイルドカード(*)を用いることも可能です。
NotResourceの指定も可能。(今回は割愛)
ARN | 対象 |
---|---|
arn:aws:iam::012345678910:user/ | 指定のAWSアカウント上のすべてのIAMユーザが対象 |
arn:aws:iam::012345678910:mfa/ | 指定のAWSアカウント上のすべてのMFAが対象 |
arn:aws:iam::012345678910:user/${aws:username} | 指定のAWSアカウント上においてログインしているIAMユーザが対象 {aws:username}はIAMユーザ名を参照する変数えであるため |
arn:aws:iam::012345678910:mfa/${aws:username} | 指定のAWSアカウント上においてログインしているIAMユーザと同じ名称のMFAが対象となる。 過去「MFAの名称はIAMユーザの名前と同一である」という仕様だった時期があった為。今ではMFAの名称がユーザ名と異なるケースが多いので注意が必要。 |
上記の様々な情報を踏まえて作成したIAMポリシーを要約すると以下の通りになります。
▽ざっくり説明
API | 対象 |
---|---|
API:ListUsers | arn:aws:iam::012345678910:user/ |
⇒すべてのユーザを対象にユーザ情報を参照できる
API | 対象 |
---|---|
ListVirtualMFADevices | arn:aws:iam::012345678910:mfa/ |
⇒すべてのMFAを対象に仮想MFAデバイスのリストを参照できる
API | 対象 |
---|---|
EnableMFADevice | arn:aws:iam::012345678910:user/${aws:username} |
DeactivateMFADevice | arn:aws:iam::012345678910:user/${aws:username} |
ResyncMFADevice | arn:aws:iam::012345678910:user/${aws:username} |
⇒ログインしているユーザのものに限っては、
MFAの関連付けや再同期ができる
API | 対象 |
---|---|
DeleteVirtualMFADevice | arn:aws:iam::012345678910:mfa/* とarn:aws:iam::012345678910:user/${aws:username} |
CreateVirtualMFADevice | arn:aws:iam::012345678910:mfa/* とarn:aws:iam::012345678910:user/${aws:username} |
ListMFADevices | arn:aws:iam::012345678910:mfa/* とarn:aws:iam::012345678910:user/${aws:username} |
⇒ログインしているユーザのものに限っては(どんなMFAの名前でも)、
MFAの作成や削除、MFAデバイスの一覧を参照できる。
ここのポリシーによって、本人以外のMFAに手を加えられなくなっています。
以上のポリシーを作成してアタッチしてあげると、アタッチされたIAMユーザは、MFA認証もできるし他のユーザのMFA認証を勝手に作成/削除ができない状態になります。
それでは、さっくりポリシーの作成とアタッチをしていきましょう
■ポリシーの作成
このポリシーの作成方法は以下の通りです。
↓ポリシーの画面へ遷移して「ポリシーを作成」をクリックします。
(左カラムのメニューにあります)
↓ポリシーエディタで「JSON」を選択し、テキストエリアに貼り付けます。
特に構文エラー等が無ければ「次へ」をクリックします。
↓ポリシー名や説明に任意の名称を入力します。
↓画面をスクロールするとタグの追加等ができるので必要な設定をし、「ポリシーの作成」をクリックします。
ポリシー一覧画面へ遷移するので検索窓等から先程作成したポリシー名を入力して、作成されていることが確認ができます。
実際に柵瀬↓ポリシーをアタッチしてみて動作を確認してみましょう!
▽確認してみる
■ポリシーのアタッチ
↓まずはIAMユーザの詳細ページの「許可」タブの「許可ポリシー」フィールドの右上にある「許可を追加」をクリックします。
↓次に、「ポリシーを直接アタッチする」を選択して先程作成した許可ポリシーをチェックし、「次へ」ボタンをクリックします。
検索して対象のポリシーを絞ると楽です。
↓確認画面に移るので対象のユーザや許可が間違えていないか確認したら「許可を追加」ボタンをクリックしましょう。
そしたらポリシーの追加は完了です。
それではお待ちかねの動作確認のお時間です!
■MFAデバイスを追加してみる
IAMユーザの詳細ページの「セキュリティ認証情報」タブの「多要素認証(MFA)」のフィールド内にある「MFAデバイスの割り当て」をクリックしましょう。
そうすると、MFAデバイスの登録画面に進むので任意のデバイス名とデバイスの種類を入力し、「次へ」をクリックします。
↓作成が成功すると操作していたIAMユーザの詳細ページへ遷移します。
「セキュリティ認証情報」タブの「多要素認証(MFA)」のフィールドにてデバイスを登録できたことを確認できます!
また、別のアカウントにMFAデバイスを勝手に作成・削除できないかも確認しましょう。
今度はLime-testでログインしたままPachimon-testにMFAデバイスの追加を試みましょう!
▽エラー文
許可が必要です この操作を実行するために必要な許可がありません。許可を追加するように管理者に依頼してください。
User: arn:aws:iam::012345678910:user/Lime-test is not authorized to perform: iam:EnableMFADevice on resource: user Pachimon-test because no identity-based policy allows the iam:EnableMFADevice action
▽エラー文を翻訳
対象のユーザ(Lime-test)に対してEnableMFADeviceの権限がない為、 Pachimon-testのMFAデバイスの登録ができませんでした。
しっかり他のIAMユーザのMFAデバイスの登録を阻止出来ましたね!
ついでに他人のMFA認証を削除してみましょう!
↓削除はIAMユーザの詳細ページの「セキュリティ認証情報」タブの「多要素認証(MFA)」のフィールド内にある
対象のMFAデバイスを選択して「削除ボタン」をクリックすればできます。
それではレッツトライ!
↓...すると次の画像のようなエラーが出ます。
▽エラー文
許可が必要です User: arn:aws:iam::012345678910:user/Lime-test is not authorized to perform: iam:DeactivateMFADevice on resource: user Pachimon-test because no identity-based policy allows the iam:DeactivateMFADevice action
▽エラー文を翻訳
対象のユーザ(Lime-test)に対してDeactivateMFADeviceの権限がない為、 Pachimon-testのMFAデバイスの削除ができませんでした。
ちゃんと他のIAMユーザのMFAデバイスの削除を阻止出来ましたね!
▽感想
ポリシーはいろんなところで公表されていますが、ものによっては自分の求めてる機能が備わってない可能性があります。
(今回の場合は、他人のMFAデバイスの設定を勝手にいじれてしまう...とか)
ところが、いちからポリシー設定を改造できると、このように「うっかり他の人の設定をいじらないようにしたいなぁ~」といった調整もできるので結構楽しいですよ!
あと注意ポイントではありますが、AWS側で仕様が変わってしまって「参考にしてたサイトのやり方じゃ解決できないよ~」と嘆きたくなることもあります。
今回は、過去にあった「MFAの名前はIAMユーザの名前固定!」の仕様時代のポリシーを参考にしていたので、
「対象のIAMユーザでいじっているのに作成も削除もできなくて涙が止まらない」といった沼に沈みかけました。
なので、あまりにもうまくいかないときは現在の仕様が参考にしていた時代から変わっているか確認してみるのもおすすめです!
ではでは、みなさんも素晴らしきAWSライフを!!
ほんまもんのらいむ(ぱちもん)です。
バーチャル概念初心者ですのでよしなに
Lv.1のエンジニアの卵