こんにちは！インフラやクラウドのセキュリティの世界へようこそ。
初めてサーバーやクラウドを触る時って、覚えることがたくさんあってワクワクする半面、「自分の設定で本当に大丈夫かな…」とちょっと不安になりますよね。
今回は、セキュリティのプロが口を酸っぱくして言う「長期的なアクセスキーの廃止と、一時的な認証情報（STS）の活用」について、身近な「家の鍵」に例えながら、一歩ずつ優しく紐解いていきたいと思います。
難しい言葉が出てきても大丈夫。一緒に紐解いていきましょう！
—
1. なぜ「ずっと使えるパスワード」は危険なの？（身近な例え話）
みなさん、ご自宅の玄関の鍵を想像してみてください。
毎日使っているお馴染みの鍵ですが、もしその鍵を「合鍵にして、友達全員に配る」としたらどうでしょう？ しかも、その合鍵は一生交換不要で、どんな状況でも開き続けるマスターキーです。
…想像しただけで、ちょっとゾッとしますよね。
- 友達がその鍵をうっかりカフェのテーブルに置き忘れたら？
- 友達が引っ越す時に、鍵を返却し忘れたら？
- もし友達のバッグが盗まれて、その中に合鍵が入っていたら？
クラウドやサーバーの世界でも、これとまったく同じことが起きています。
ずっと有効期限が切れない「アクセスキー（パスワードのようなもの）」をプログラムにハードコーディングしたり、GitHubなどの公開リポジトリにうっかりアップロードしてしまうミスは、まさに「一生モノのマスターキーを街中に落とし続けること」なんです。
攻撃者は、この「落とし物のマスターキー」を24時間体制で自動ツールを使って探し回っています。だからこそ私たちは、「使い捨ての鍵」に切り替える必要があるのです。
—
2. 攻撃者はどうやって「長期キー」を狙うのか？
攻撃者（泥棒）の視点に立ってみましょう。彼らが一番欲しいのは、サーバーの奥深くへ侵入できる強力な権限です。
もし、開発用の設定ファイルや環境変数（.envファイルなど）の中に、有効期限のないAWSやクラウドのアクセスキーがそのまま書かれていたとします。攻撃者がWebアプリの脆弱性を突いてサーバーのファイルを少しでも覗き見ることができたら……そこにあったアクセスキーをごっそり盗み出します。
一度この長期キーが渡ってしまうと、攻撃者は「正当な持ち主」になりすまして、あなたの大切なサーバーやデータベースを自由に操り、勝手に仮想通貨のマイニングを始めたり、機密データを外部へ持ち出したりしてしまいます。
ここで有効なのが、「STS (Security Token Service)」という仕組みです。
—
3. 「一時的な認証情報（STS）」ってなに？
STSとは、一言で言うと「数分〜数時間だけ有効な、使い捨てのデジタル合鍵」を発行してくれる仕組みのことです。
ホテルに泊まった時にもらう「ルームキー（カードキー）」を思い出してみてください。そのカードキーにはチェックアウトの日時が書き込まれていて、期限を過ぎるとただのプラスチックの板に戻って使えなくなりますよね。STSもまったく同じです。
STSのメリット
1. 自動で失効する： 万が一、鍵が盗まれても、数時間後には勝手に「無効な鍵」になるため、被害を最小限に食い止められます。
2. 権限を絞れる： 「この作業をするためだけに、このファイルを見る権限だけをください」といった、必要最小限の権限（最小権限の原則）を持った一時的な鍵を発行できます。
—
4. 【実践】AWS環境でのSTS活用とセッション設定のコード例
それでは、実際にコードや設定ファイルを通じて、一時的な認証情報をどのように扱うのか見ていきましょう。今回は、Node.js（JavaScript）を使ったAWS SDKのサンプルで解説します。
まずは、ずっと使える固定のアクセスキーをコード内に書くのをやめ、STSを使って一時的なクレデンシャル（認証情報）を取得するコードの書き方です。
// 必要なAWS SDKのモジュールをインポートします
const { STSClient, AssumeRoleCommand } = require("@aws-sdk/client-sts");
// STSクライアントを初期化します（リージョンを指定）
const stsClient = new STSClient({ region: "ap-northeast-1" });
async function getTemporaryCredentials() {
try {
// 役割（ロール）を引き受けるためのパラメータを設定します
const params = {
// 割り当てる権限を持つIAMロールのARN（住所のようなもの）
RoleArn: "arn:aws:iam::123456789012:role/MyTemporaryWorkerRole",
// ログなどに記録されるセッション名（任意の文字列）
RoleSessionName: "DeveloperSession-Today",
// 有効期間を秒単位で指定します（例: 3600秒 = 1時間）
// ※長すぎず短すぎない、業務に最適な長さに設定するのがコツです！
DurationSeconds: 3600,
};
// STSに対して一時的な認証情報の発行をリクエストします
const command = new AssumeRoleCommand(params);
const response = await stsClient.send(command);
console.log("一時的な認証情報の取得に成功しました！");
// 取得した一時的なキー情報を返却します
return {
accessKeyId: response.Credentials.AccessKeyId,
secretAccessKey: response.Credentials.SecretAccessKey,
sessionToken: response.Credentials.SessionToken, // ←一時キーにはこのトークンが必須です！
expiration: response.Credentials.Expiration,
};
} catch (error) {
console.error("一時認証情報の取得に失敗しました...", error);
throw error;
}
}ポイント：SessionTokenの存在を忘れないで！
通常の固定アクセスキーを使う時は AccessKeyId と SecretAccessKey の2つがあれば動きますが、STSで作った一時キーを使う場合は、必ず SessionToken（セッショントークン） もセットで渡す必要があります。これが揃ってはじめて、「私は許可された一時的な訪問者です」とクラウドに証明できるんです。
—
5. セッション有効期限の最適化：長ければ良いってものではない？
「有効期限が短いと、何度も鍵を作り直さなきゃいけなくて面倒くさそう…」と思われるかもしれませんが、それはセキュリティと利便性のトレードオフ（バランス）の工夫しどころです。
- 開発者の手元での作業：
- 一般的には
3600秒（1時間）〜43200秒（12時間）程度に設定し、朝出社した時や作業開始時に一度だけ認証（MFAなどと組み合わせる）を行うのが安全かつ快適です。 - バックグラウンドで動く自動化スクリプト：
- 必要最小限の短い時間（数分〜1時間など）でこまめに再取得するか、IAMロールの仕組み（EC2のインスタンスプロファイルやECSタスクロールなど）を使い、人間がアクセスキーを一切管理しなくてよい仕組みに昇華させましょう。
「鍵の貸し出し時間は必要最小限にする」これが防犯の基本中の基本です。
—
6. まとめ：今日からできる一歩
いかがでしたでしょうか？
「長期的なアクセスキーを廃止し、STSによる一時的な認証情報に切り替える」というのは、難しそうな言葉に聞こえますが、要するに「合配りしたマスターキー生活をやめて、毎回使い捨てのデジタルキーを発行してもらう生活に変えましょう」というお話です。
新人のIT担当者や開発者のみなさんが、最初からこの安全な習慣（セキュア・マインドセット）を身につけておくと、将来チームの大きな信頼を得られること間違いなしです。
まずはご自身の開発環境やプロジェクトで、ハードコーディングされた古い鍵がないか確認することから、一歩ずつ進めていきましょう！
コメント