3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 1 year has passed since last update.

IAMユーザのセキュリティ確保 MFA必須化とロールの利用

Posted at

はじめに

AWSを利用している場合、複数の開発者や運用者がIAMユーザを保持し、アクセスすることが多々あります。
その際、権限管理をどうするべきか、MFAは設定してほしいけど・・・などお悩みがあるかと思います。
今回は、IAMグループやロールをどのように設計すべきか、MFAの設定はどうするべきかを語ります。

一般的な構成

スクリーンショット 2023-04-29 18.37.18.png
一般的な構成を図示ししています。
IAMグループを役割ごとに分け、適切なポリシーを適用、ユーザを所属させるという構成です。

問題点

この構成の問題点はどこにあるのでしょうか。
まず、考えられるのは、ユーザは毎回グループに割り当てられた権限を利用したいというわけではないということです。どういうことかというと、例えば、Administrator権限を必要とする変更作業をすることもあるし、ただ設定値の確認をしたいときもある、そんなときに、この人は変更作業をすることがあるから、Adminグループに所属させようだと、過剰な権限を常にもっているため、誤操作のリスクが高くなります。
そのため、必要な権限を必要なときに行使できるような環境が望ましいということです。
また、複数アカウントがある際も、IAMユーザを複数管理する必要がでてくるため、ログイン操作が手間となります。

解決策

スクリーンショット 2023-04-29 18.51.04.png
解決策を図示しています。
IAMユーザが所属するグループには原則スイッチロールする権限のみ付与します。
※スイッチロールする権限以外にMFAの登録やPWの変更、アクセスキーの発行など、IAMユーザで最低限必要な権限は必要に応じて付与する必要があります。
スイッチロール先のアカウントでは、IAMロールを作成、管理者や、CloudFormationテンプレート実行者、サーバ管理者など役割に応じてロールを分離して、最低限必要な権限を付与します。
こうすることで、ユーザは作業内容に応じて適切なロールを使い分けることができ、強すぎる権限を利用する必要がなくなります。

MFAについて

パブリッククラウドにおいて、MFAの設定は必須だと考えています。
パスワードが流出したり、なんらかの理由で破られたとしても、MFAがあれば助かったという事例が結構あります。
そのため、MFAは設定すべきがベストプラクティスですが、運用者側でもこの設定をユーザ側で実施しているのか監査を行う必要があり手間がかかるということがあります。

解決策

スクリーンショット 2023-04-29 19.02.40.png
解決策を図示しています。
ポイントは2つです。
まず、IAMユーザグループ側で、MFAが設定されていない限り、原則すべての操作を拒否するポリシーを付与します。なお、MFAの設定やPW更新などは必要なので、例外として許可します。
また、MFAが設定されているか設定を確認するために、Configルールを付与します。
mfa-enabled-for-iam-console-accessというルールを有効化することでチェックが可能です。
EventBridgeルールで通知を設定しておきましょう。

参考ポリシー

スイッチロール権限

{
  "Version": "2012-10-17",
  "Statement": {
    "Effect": "Allow",
    "Action": "sts:AssumeRole",
    "Resource": "arn:aws:iam::account-id:role/Test"
  }
}

MFA必須化

アクセスキーを利用している場合、MFAってどうするの?スイッチロールは?

アクセスキーを利用している場合、MFAを必須化すると、そのままでは利用できなくなります。
そのため、以下の方法が必要です。
・通常通り、アクセスキーの登録をします。
・以下のコマンドを実行し、アクセスキー類を取得します。
※arn-of-the-mfa-deviceはMFAデバイス名を、code-from-tokenはMFAデバイスに表示された数字を入力します。

$ aws sts get-session-token --serial-number arn-of-the-mfa-device --token-code code-from-token

・以下のようなレスポンスがあるはずです。

{
    "Credentials": {
        "SecretAccessKey": "secret-access-key",
        "SessionToken": "temporary-session-token",
        "Expiration": "expiration-date-time",
        "AccessKeyId": "access-key-id"
    }
}

・以下のコマンドを実行し取得したキーを登録します。

set AWS_ACCESS_KEY_ID=出力された値をコピペ
set AWS_SECRET_ACCESS_KEY=出力された値をコピペ
set AWS_SESSION_TOKEN=出力された値をコピペ

これで、MFA認証が通った状態となります。
スイッチロールが必要であれば更に以下手順を実行します。

・IAMロールからアクセスキー類を取得します。

aws sts assume-role --role-arn arn:aws:iam::123456789012:role/role-name --role-session-name "RoleSession1"

・以下のようなレスポンスがあるはずです。

{
    "Credentials": {
        "SecretAccessKey": "secret-access-key",
        "SessionToken": "temporary-session-token",
        "Expiration": "expiration-date-time",
        "AccessKeyId": "access-key-id"
    }
}

・以下のコマンドを実行し取得したキーを登録します。

set AWS_ACCESS_KEY_ID=出力された値をコピペ
set AWS_SECRET_ACCESS_KEY=出力された値をコピペ
set AWS_SESSION_TOKEN=出力された値をコピペ

これでようやく、MFA認証かつ、スイッチロールできた状態となります。
ちょっと手間ですが、セキュアに利用するにはしょうがないですね。

まとめ

IAMユーザの管理はセキュリテイ上非常に重要な部分です。
ロールの分離、グループの分離など、検討要素が多いため、日々の運用中で見直していくことをおすすめします。

3
1
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
3
1

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?