【入門編】 IAMユーザーのアクセスキー管理とローテーション自動化 – インフラ・ネットワーク & クラウドセキュリティ防御ガイド

皆さん、こんにちは！日々のインフラ運用や開発、本当にお疲れ様です。

新しいサービスやインフラをクラウド上に構築するときって、ワクワクしますよね。「よし、動いた！」という瞬間はエンジニアにとって最高の喜びの一つです。でも、その裏でずっと私たちを見張っている「悪い奴ら」がいることも忘れてはいけません。

今回は、クラウドのセキュリティにおいて最も狙われやすく、そして被害が大きくなりやすい「アクセスキーの管理と自動ローテーション」について、一緒に優しく紐解いていきたいと思います。

難しい専門用語も出てきますが、身近な「家の鍵」に例えながら一歩ずつ解説していくので、安心してついてきてくださいね！

—

1. なぜ「アクセスキー」は狙われるのか？（家の鍵に例えてみる）

クラウド（AWSなど）を操作するとき、IDとパスワードのほかに、プログラムからAPIを叩くための Access Key ID と Secret Access Key という文字列のコンビネーションを使いますよね。これが、いわゆる「クラウド上の合鍵」です。

想像してみてください。あなたは自分の家の合鍵を、あろうことか近所の公園のベンチに置きっぱなしにしてしまいました。どうなると思いますか？ そう、誰でも簡単にその鍵を拾って、あなたの家に自由に出入りできてしまいますよね。

クラウドの世界でも全く同じことが起きています。

• うっかり公開リポジトリ（GitHubなど）に Secret Access Key を載せたままでプッシュしてしまった。
• ソースコードの中にハードコーディング（直接書き込み）したままにしていた。

攻撃者（ボット）は、インターネット上の公開コードを24時間体制で自動巡回し、この「落ちている合鍵」を血眼になって探しています。キーが漏洩した瞬間、ものの数分で仮想通貨のマイニングサーバーを勝手に何台も立ち上げられ、翌月に「数百万円の請求書」が届く……というのは、現場で本当によくある悪夢なんです。

—

2. 攻撃者はどうやって侵入し、何を企むのか？

もし攻撃者があなたのアクセスキーを手に入れたら、彼らは一体どう動くでしょうか？

彼らはまず、盗んだキーを使ってクラウド環境へこっそり侵入します。そして、セキュリティ担当者に見つからないように、自分たち専用の「裏口（バックドア）」を作ります。具体的には、権限の強い新しいIAMユーザーを追加したり、既存の管理者権限を書き換えたりするんです。

ここで、「じゃあ、一度発行したキーはずっと同じままでいいや」と放置していると、攻撃者はいつまでもその合鍵を使い続けることができます。

だからこそ必要なのが、「定期的に鍵を新しくする（ローテーションする）」という防犯対策になります。でも、人間の手で「3ヶ月ごとに手動でキーを作り直して、設定ファイルを書き換えて……」とやるのは、忘れてしまうリスクもあるし、何より面倒ですよね。

だからこそ、これを自動化する必要があるのです。

—

3. 自動ローテーションの実装：一歩ずつ仕組みを作ろう

それでは、実際にアクセスキーのローテーションを自動化する仕組みを考えていきましょう。今回は、インフラ・ネットワークの現場でよく使われる Python（Boto3） を使ったスクリプトのイメージを見ていきます。

自動化の大まかな流れはこうです。
1. 現在使っているキーの「年齢（作成されてからの日数）」をチェックする。
2. 一定期間（例: 90日）を超えていたら、新しいキーを新しく発行する。
3. システム側で新しいキーが問題なく使えていることを確認し、古いキーを「無効化（あるいは削除）」する。

実際のサンプルコードを見てみましょう。実務でそのまま参考にできるよう、日本語のコメントを丁寧に書き込んでいます。

import boto3
from datetime import datetime, timezone

# IAMクライアントの初期化
iam_client = boto3.client('iam')

def rotate_access_keys(user_name):
    """
    指定したIAMユーザーのアクセスキーをチェックし、
    古いものを無効化して新しいものを発行する関数です。
    """
    print(f"[*] ユーザー '{user_name}' のアクセスキーを確認中...")
    
    # 1. ユーザーに紐づいているアクセスキーの一覧を取得
    response = iam_client.list_access_keys(UserName=user_name)
    access_keys = response.get('AccessKeyMetadata', [])
    
    # 現在の時刻（UTC）を取得
    now = datetime.now(timezone.utc)
    
    for key in access_keys:
        key_id = key['AccessKeyId']
        status = key['Status']
        created_date = key['CreateDate']
        
        # キーが作られてからの経過日数を計算
        age_in_days = (now - created_date).days
        print(f" - キーID: {key_id} (状態: {status}, 経過日数: {age_in_days}日)")
        
        # 例として、90日以上経過していて、かつ「Active（有効）」なキーを対象にする
        if age_in_days > 90 and status == 'Active':
            print(f" [!] 警告: キー {key_id} は90日を超えています。ローテーションを開始します。")
            
            # 2. 新しいアクセスキーを作成
            new_key_response = iam_client.create_access_key(UserName=user_name)
            new_key = new_key_response['AccessKey']
            print(新しいキーが作成されました。KeyId: {new_key['AccessKeyId']})
            
            # 【注意】本来はここで新しいキーの値を安全なストレージ（Secrets Managerなど）に
            # 自動保存する処理を挟みます。画面に平文で出力してはいけません！
            
            # 3. 古いキーを無効化する（いきなり削除せず、まずはInactiveにするのが安全です）
            iam_client.update_access_key(
                UserName=user_name,
                AccessKeyId=key_id,
                Status='Inactive'
            )
            print(f" [OK] 古いキー {key_id} を無効化（Inactive）しました。")

# 実行例（実際の運用ではLambdaなどのサーバーレス環境で定期実行します）
if __name__ == "__main__":
    target_user = "app-deployment-user"
    rotate_access_keys(target_user)

このスクリプトのポイントは、古いキーをいきなり「削除 (delete_access_key)」するのではなく、一端「無効化 (Inactive)」にしている点です。もし無効化したことで「あ、連携していた別のアプリが動かなくなった！」というトラブルが起きても、一時的ならすぐに Active に戻して復旧できるからです。この「段階を踏む泥臭さ」が、現場を守るセキュリティではとても大切なんです。

—

4. 未使用キーの無効化ポリシーと運用のコツ

自動ローテーションスクリプトと合わせて導入したいのが、「未使用キーの撲滅ポリシー」です。

長期間使われていないアクセキー（例えば、過去180日間一度もAPIを叩いていないキーなど）は、存在していること自体がリスクになります。担当者が退職したあとに放置された「ゾンビキー」などがこれに該当します。

現場で意識すべきポリシーのポイントをいくつか挙げておきますね。

• 「作ったら終わり」にしないライフサイクル管理

アクセスキーを発行するときは、必ず「何の目的で、いつまで使うものか」を用途タグや台帳に残す癖をつけましょう。

• AWS ConfigやSecurity Hubの活用

自前でスクリプトを書かなくても、クラウドベンダーが提供する標準のセキュリティツール（「90日以上ローテーションされていないアクセスキーを検知する」など）を有効化するだけで、ダッシュボードでお知らせしてくれます。まずはここから始めるのも大正解です。

• そもそもアクセスキーを作らない選択肢（IAMロールの活用）

EC2インスタンスやLambdaなどのサーバー上で動くアプリケーションからAWSを操作する場合、アクセスキーをコードや環境変数に埋め込む必要はありません。「IAMロール」という仕組みを使えば、クラウドが自動的に一時的な権限をやり取りしてくれるため、鍵の漏洩リスクを根本からゼロにできます。「どうしても人間や外部の別システムからアクセスする必要がある場合のみキーを発行する」という原則をチームで共有しましょう。

—

さいごに

セキュリティの対策と聞くと、「なんだかルールが厳しくなって面倒だな」「開発のスピードが落ちそうだな」と感じてしまうかもしれません。

でも、セキュリティの本質は、開発者や企業のビジネスの足かせになることではなく、「安心してアクセルを踏み続けられるためのブレーキとシートベルト」を用意することです。

最初は難しく感じるかもしれませんが、小さな自動化やポリシーの積み重ねが、将来の大規模なインシデントを防ぐ強力な盾になります。ぜひ、ご自身のプロジェクトや環境でも「うちの鍵、最後にいつ変えたっけ？」と見直すところから始めてみてくださいね。

一歩ずつ、セキュアで快適なインフラ環境を作っていきましょう！応援しています！