はじめに

以前からAWS CLIなどで設定していたアクセスキーに懸念がありました。今回、その使用をやめてIAM Identity CenterによるSSO認証に変更してみました。また、有効なアクセスキーが残っているかをチェックして、メールで通知する仕組みを導入してみました。利用されているAWSアカウントのセキュリティ対策の参考にして頂けると幸いです。

きっかけ

マネジメントコンソールのIAM User設定画面で、アクセスキーを追加しようとしていた時でした。推奨される代替案として、IAM Identity Centerのユーザーによる認証を使用することが表示されていることに気づき、調べたのがきっかけです。

コンソールに表示されているメッセージは、重要なことや役立つ情報であるかもしれないので、気づけばチェックしよう。

アクセスキーをやめたかった理由

とにかく漏洩することが怖いです。2要素認証などの仕組みがないため、キーが漏洩してしまうと簡単に利用されてしまいます。ベストプラクティスでは、90日に1回のローテーションが推奨されています。特に個人で使用しているようなAWSアカウントでは、キーを作成したまま放置ということが起こりがちなため、なるべく使用を避けたいと思っていました。

↓の記事にアクセスキーについて詳しく解説されていました。

設定

ここからSSO認証のための設定について説明していきます。

IAM Identity Center

IAM Identity Centerのユーザーで、AWSマネジメントコンソールへのログインやリソースへのアクセスをさせる場合、マルチアカウントのアクセス許可機能を利用します。IAM Identity Centerは「組織のインスタンス」である必要があります。
Organizationsを利用し複数のアカウントを管理している場合、マスターアカウントで設定することになります。

許可セット

IAM Identity Centerのユーザーと、AWSアカウントへのアクセス権の割当を紐付けします。私の場合は、AWS CLIを利用するユーザーはPowerUserの操作に加え、IAMの操作も行いたかったので、以下のようにしました。

IAM Identity Center > 許可セット > AWSPowerUserAccess > ポリシーをアタッチ
マネージドポリシーから、「IAMFullAccess」を追加しました。

IAM Role を確認すると、許可セットに対応するロールが自動的に作成されています。「AWSPowerUserAccess」に対応するロール「AWSReservedSSO_AWSPowerUserAccess_〜」へアタッチされたポリシーを確認します。

許可セットの設定画面で割り当てたポリシーが、IAM Roleにアタッチされていることが確認できます。
※カスタマー管理ポリシーもアタッチ可能です。カスタマー管理ポリシーの場合は、同名のポリシーを各AWSアカウントに作成しておく必要があります。

グループとユーザーの設定

IAM Identity Centerのグループと許可セットを割当します。
私の場合は、グループ「Developer」と許可セット「AWSPowerUserAccess」を割当ました。

AWS CLIで利用するユーザーをグループ「Developer」に所属させました。

AWS CLI

続いてAWS CLIの設定を行います。以下のサイトに記載のとおり、aws configure ssoコマンドで、IAM Identity Center用のプロファイルを作成します。

mhukmtd@mhukmtd-virtualbox:~$ aws configure sso
SSO session name (Recommended):
WARNING: Configuring using legacy format (e.g. without an SSO session).
Consider re-running "configure sso" command and providing a session name.
SSO start URL [None]: https://d-xxxxxxxxxxxxx.awsapps.com/start
SSO region [None]: ap-northeast-1

上記の「SSO start URL」は、IAM Identity Centerのダッシュボードで確認できる、「AWS access portal URL」を入力します。

ブラウザーが起動し、ログインページが表示されます。

IAM Identity CenterでMFAを設定していると、MFA Codeの入力も求められます。設定することをお勧めします。

ターミナル上に表示されているCodeとブラウザの画面に表示されているCodeが一致するかを確認し、「Confirm and continue」をクリックします。

このブラウザで認証されたセッションを、AWS CLIで利用することを許可するための確認メッセージが表示されます。「Allow」をクリックします。

許可が完了したので、このブラウザーの画面は閉じてOKです。

ターミナルには以下のように続きのメッセージとプロンプトが表示されますので、適宜応答します。

The only AWS account available to you is: 123456789012
Using the account ID 123456789012
The only role available to you is: AWSPowerUserAccess
Using the role name "AWSPowerUserAccess"
CLI default client Region [None]: ap-northeast-1
CLI default output format [None]:
CLI profile name [AWSPowerUserAccess-123456789012]:

To use this profile, specify the profile name using --profile, as shown:

aws s3 ls --profile AWSPowerUserAccess-123456789012

ホームフォルダ.aws\configファイルを確認すると、IAM Identity Center用のプロファイルが作成されていることが確認できました。

ためしに、ターミナルでs3バケットのリストを表示するコマンドを入力すると、バケットのリストが正しく表示されました。SSO認証でAWS CLIが使用可能となりました。

ログイン通知

以前に設定したログイン通知機能を、IAM Identity Centerユーザーにも適用してみます。SSO認証した時のイベントも検知するようにして、メール送信させます。

SSO認証時のCloudTrailのイベント記録内容

IAM Identity Center ユーザーでSSO認証した時間帯のCloudTrail ログを確認しました。以下のログイベントが該当すると見当をつけました。

CloudTrailログイベントの一部

    "eventVersion": "1.09",
    "userIdentity": {
        "type": "Unknown",
        "principalId": "123456789012",
        "arn": "",
        "accountId": "123456789012",
        "accessKeyId": "",
        "userName": "IAM Identity Centerのユーザ名",
        "onBehalfOf": {
            "userId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx",
            "identityStoreArn": "arn:aws:identitystore::123456789012:identitystore/d-xxxxxxxxxx"
        },
        "credentialId": "xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxx"
    },
    "eventTime": "2025-02-11T07:14:10Z",
    "eventSource": "signin.amazonaws.com",
    "eventName": "UserAuthentication",
    "awsRegion": "ap-northeast-1",```

eventNameは「UserAuthentication」で、userIdentity.typeは「Unknown」であることがわかりました。

SSO認証のイベントをフィルタに追加

CloudTrail用に設定しているCloudWatch logs ロググループのサブスクリプションフィルターを修正します。

サブスクリプションフィルターパターン

{ ($.eventName = "ConsoleLogin") || ($.eventName = "UserAuthentication") }

以前のサブスクリプションフィルターは削除します。

これで、SSO認証したときのログ情報も、メール通知用のLambdaへ連携されるようになりました。

SSO認証時のユーザー名取得

通知用のLambda「ConsoleLoginNotificationLambda」を修正し、SSO認証時もユーザー名をメール本文に出力できるようにコードを修正します。userIdentity.typeが「Unknown」の場合の処理を追加します。

index.pyの一部抜粋

    match event['userIdentity']['type']:
        case 'IAMUser':
            inputData['userName'] = event['userIdentity']['userName']
        case 'Root':
            inputData['userName'] = 'Root'
        case 'Unknown':      # 追加
            inputData['userName'] = event['userIdentity']['userName']   # 追加

Lambda関数を更新します

SSO認証のテスト

SSO認証もメール通知できるようになりました。

アクセスキーの存在をチェックする

最後に、アクセスキーを残さないための仕組みを構築します。SSO認証に切り替えたので、アクセスキーを使用しなくてもよい環境となりました。誤って有効なアクセスキーが残っていたらメールでお知らせする機能になります。

チェック用LambdaのPythonコード

ほぼ、生成系AIに作ってもらったコードです。

accesskeys_check.py

import boto3
import os

def lambda_handler(event, context):
    """
    IAM Userに作成されているすべてのAccesskeyをチェックし、
    有効なものが存在した場合、そのIAM User名をSNSで通知する。
    """

    iam = boto3.client('iam')
    sns = boto3.client('sns')

    sns_topic_arn = os.environ['SNS_TOPIC_ARN']  # 環境変数からSNS Topic ARNを取得

    try:
        # すべてのIAMユーザーを取得
        users = iam.list_users()['Users']

        for user in users:
            user_name = user['UserName']
            access_keys = iam.list_access_keys(UserName=user_name)['AccessKeyMetadata']

            # 有効なアクセスキーが存在するかチェック
            for key in access_keys:
                if key['Status'] == 'Active':
                    # SNSに通知
                    message = f"IAM User '{user_name}' has an active Access Key. KeyId: {key['AccessKeyId']}"
                    print(message)  # Lambdaのログにも出力

                    sns.publish(
                        TopicArn=sns_topic_arn,
                        Message=message,
                        Subject='Active IAM Access Key Found'
                    )
                    break  # ユーザーごとに一度だけ通知

    except Exception as e:
        print(f"Error: {e}")
        raise  # エラーを再スローして、Lambdaの実行を失敗させる

    return {
        'statusCode': 200,
        'body': 'IAM Access Key Check completed.'
    }

メール通知先SNSトピックの設定

環境変数に、メール通知用のSNSトピックを設定します。

アクセスキーの取得処理には少し時間がかかるようなので、タイムアウトの時間をデフォルトから30秒へ拡張しておきます。

Lambdaの権限設定

このLambda関数に設定するIAM Roleに必要な権限は以下の通りです。

iam:ListUsers
iam:ListAccessKeys
sns:Publish

検知テスト

テスト用のIAM Userを作成し、アクセスキーを有効にしておきます。

テスト実行します。有効化されているアクセスキーを発見し、メールで通知してくれました。

スケジュール登録

作成した検知処理が定期的に実行されるようにするため、EventBridge Schedulerを登録します。

毎日02:00時にスケジュールしました。

チェック用のLambdaがターゲットになるように設定します。ペイロードは不要です。

その他は、デフォルトでスケジュールを作成します。

以上で設定完了です。

まとめ

アクセスキーの使用をやめてIAM Identity CenterによるSSO認証を利用し、AWS CLIでアクセスできるように環境設定できました。また、IAM Identity CenterによるSSO認証のイベントをメール通知させることと、不要となったアクセスキーが残っていないかを自動的にチェックする仕組みを導入することができ、アクセスキーに関しては安心できる状態になりました。
今回作成した仕組みは複数人で利用している環境でも利用できますが、アクセスキーのチェック部分は、AWS Configを利用するほうがより安全と思います。機会があれば調べてみようと思います。