【AWS】IAMユーザーのセキュリティ強化

2022年10月6日Amazon Web Services,IAM,セキュリティ

こんにちは。プラットフォーム技術部の越地です。

IAMを設計する際、AWSのベストプラクティスを参照して設定することが多いかと思います。
が、いざ運用すると
「利用者がMFA認証を設定してくれない」
「いくつもあるIAMユーザーを棚卸しするのが大変」
なんていうこと、ありませんか？

また、外部のサービスからAWSのリソースにアクセスするために、IAMユーザーのクレデンシャルキーを利用せざるを得ない場合もあるかと思います。そのクレデンシャルキーを初回構築時のまま、ローテーションせずに放置していないでしょうか？

ということで今回は、上記のような実際に運用するうえでのIAMのセキュリティ問題への対策について、いくつか紹介したいと思います。

IAMユーザーの情報取得

対策するにもまずは状況の確認から、ということで、まずはIAMユーザーの情報取得方法を見ていきます。IAMユーザーの情報は、IAMのサービス画面でも確認できますが、例えば数十個単位でIAMユーザーが作成されている場合、これをひとつずつ確認するのはなかなかの重労働です。

そんなときに便利なのがIAMの認証情報レポートです。レポートをダウンロードすると、最終ログイン日、MFAの有効化の有無、クレデンシャルキーの利用状況などの情報を取得できます。（取得できる情報についてはこちらを参照）地味な機能に見えますが、CSV形式で出力されるためツールやスクリプトで利用しやすく、取得した情報をもとに問題のあるユーザーへ自動的に通知するといった使い方もしやすいかと思います。

ただし、レポートの取得＋督促通知でも一定の効果は見込めるものの、設定を強制するものではなく、最終的には利用者の善意に任せることになってしまいます。ひとりでも脆弱な設定になってしまっているとリスクは高いままなので、できれば一定の設定は強制したいところです。そこで次の項目では、特に設定を嫌厭されがちなMFA設定を強制するように設定する方法を紹介します。

MFA利用の強制

AWSのベストプラクティスでも推奨されているMFA（多要素認証）ですが、入力する項目が増えることから、設定しないで利用してしまう利用者も多いかと思います。IAMのパスワード設定などで強制できれば良いのですが、2022年9月現在時点では、残念ながら設定できません。

そこで、IAMユーザー、もしくはIAMユーザーを所属させるグループでMFA利用を強制するIAMポリシーを適用してみようと思います。このポリシーを設定すると、他のポリシーで許可されている操作でも、MFAを有効化していないと操作ができなくなります。

さっそく実際に検証してみます。

今回適用するポリシーは以下のとおりです。MFAの有効化にかかわるアクションの許可設定と、「BlockMostAccessUnlessSignedInWithMFA」の部分で、MFAを利用した状態でないと操作できないように設定しています。

policy-force-mfa
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AllowListActions",
            "Effect": "Allow",
            "Action": [
                "iam:ListUsers",
                "iam:ListVirtualMFADevices"
            ],
            "Resource": "*"
        },
        {
            "Sid": "AllowIndividualUserToListOnlyTheirOwnMFA",
            "Effect": "Allow",
            "Action": [
                "iam:ListMFADevices"
            ],
            "Resource": [
                "arn:aws:iam::*:mfa/*",
                "arn:aws:iam::*:user/${aws:username}"
            ]
        },
        {
            "Sid": "AllowIndividualUserToManageTheirOwnMFA",
            "Effect": "Allow",
            "Action": [
                "iam:CreateVirtualMFADevice",
                "iam:DeleteVirtualMFADevice",
                "iam:EnableMFADevice",
                "iam:ResyncMFADevice"
            ],
            "Resource": [
                "arn:aws:iam::*:mfa/${aws:username}",
                "arn:aws:iam::*:user/${aws:username}"
            ]
        },
        {
            "Sid": "AllowIndividualUserToDeactivateOnlyTheirOwnMFAOnlyWhenUsingMFA",
            "Effect": "Allow",
            "Action": [
                "iam:DeactivateMFADevice"
            ],
            "Resource": [
                "arn:aws:iam::*:mfa/${aws:username}",
                "arn:aws:iam::*:user/${aws:username}"
            ],
            "Condition": {
                "Bool": {
                    "aws:MultiFactorAuthPresent": "true"
                }
            }
        },
        {
            "Sid": "BlockMostAccessUnlessSignedInWithMFA",
            "Effect": "Deny",
            "NotAction": [
                "iam:CreateVirtualMFADevice",
                "iam:EnableMFADevice",
                "iam:ListMFADevices",
                "iam:ListUsers",
                "iam:ListVirtualMFADevices",
                "iam:ResyncMFADevice"
            ],
            "Resource": "*",
            "Condition": {
                "BoolIfExists": {
                    "aws:MultiFactorAuthPresent": "false"
                }
            }
        }
    ]
}

実機で確認してみます。EC2のReadOnly権限を付与したIAMユーザーに、このポリシーを割り当てます。

MFAを設定しない状態で、EC2のサービス画面にアクセスしてみると…？

エラー表示になり、参照できません。

IAMの画面上でMFAの設定はできるため、設定を追加・MFA利用した状態で再度EC2の画面を見てみます。

今度は無事表示されました！

今回は検証用に直接IAMユーザーに適用しましたが、もちろんIAMグループに適用しても大丈夫です。

ただし、アクセスキーやAWS CodeCommitのSSHキー・HTTPS Git認証情報を利用するIAMユーザーへ適用する場合は注意が必要です。AWSの仕様上MFA経由で利用できない機能のため、先ほどのポリシーのまま適用すると、キーを利用したときに権限不足としてアクセス拒否されてしまいます。

この場合は、キー利用ユーザーとしてIAMユーザーを別に持つ（システムユーザーとしてコンソールログインを無効化する）、もしくはMFA強制ポリシーの「BlockMostAccessUnlessSignedInWithMFA」のアクションに、キー利用時の実行アクションを追加する必要があります。

IAM情報の外部連携

最後に、外部サービスなどを利用する場合の、IAM情報の連携方式についても考えてみたいと思います。外部サービスなどからAWSを操作する場合に、IAMロールを利用できるサービスであれば、IAMロールの信頼関係などで接続元を制限したり、外部IDを設定しておくことで、ある程度予期せぬ利用を防げます。

しかし、接続先の仕様上、どうしてもIAMユーザーから生成したアクセスキー・シークレットキー（以下アクセスキー）を利用しなければならない場合、こうした対策がとれません。また、キーも永続的に利用できてしまうため、気づかぬうちにアクセスキーが漏洩していて何回も不正に利用されていた、という事態になる危険性があります。

その場合、最低限のリソース・アクションのみ許可する、アクセスキーの保管場所・形式に留意するといった基本的な対応のほかに、定期運用、もしくは自動的にアクセスキーを更新する定期実行タスクとして、キーローテーションについても具体的に実施方式を決定してしまっておくことをおすすめします。（アクセスキーの更新方法はこちらを参照）

また、GuardDutyやIAM Access Analyzerを利用することで、アクセス元が通常利用と異なる場合など、通常利用とは異なったふるまいを検知できる可能性があります。アクセスキーが不正に利用されてしまったあとの検知となるため、被害を完全に防ぐものではありませんが、2回目以降の被害を防ぐ初動対応の起点としては利用できるかと思います。

最近新たにGAされたIAM Role Anywhereを代わりに利用するのもありですが、利用には独自のCAの証明書バンドル、またはIAM Roles Anywhereと同じAWSリージョン内のアクティブなACM PCAのCAがいるため、費用面の考慮が必要です。

アクセスキーを利用する場合は特に漏洩してしまったときに相応のリスクが伴うため、AWS内外問わず、まずはアクセスキーを利用しない方式で実装できないか検討することをおすすめします。AWS内であれば、アクセスキーを利用せずに設計できることがほとんどですが、AWS外のサービスなどの場合は仕様上どうしてもということもあるかと思います。その場合は、AWSのベストプラクティスや、早期発見・被害範囲をすくなくする対策を検討する必要があります。

まとめ

今回はIAM、特にIAMユーザーにかかわる部分について、セキュリティ統制が効きづらい設定への対応について紹介しました。実際に多くの利用者が触れるサービスだからこそ、設計・構築段階では見えづらい課題もあるかと思います。実際の運用にのせたあとにも設計思想どおりに安全な環境として提供できる、一助になれば幸いです。

AWSが企業の重要なサービスや基幹業務システム基盤として選ばれ活用が急速に進んでいる昨今ですが、まだまだその重要性に応じたセキュリティ対策が十分に取られていないケースも多いかと思います。「リスクが分からない」「どういった対策ができるのか？すべきなのかよく分からない」といった課題をお抱えの皆さま、金融のお客様をはじめ高度なセキュリティ要求への対応実績を持つ弊社にぜひ一度お声掛けください。

お問い合わせはこちらから。