AWSの鍵管理ベストエフォート（よくある運用例つき）

はじめに

AWS で EC2 や Kubernetes を運用していると、避けて通れないのが鍵と認証情報の管理です。

理想論だけであれば、SSH 鍵を配らず、個人を IAM で識別し、操作は監査ログに残す、で終わります。
ただし実務では、Bastion 前提の構成、共有フォルダでの鍵配布、手作業の本番操作が残っていることも珍しくありません。

この記事では、次の内容を整理します。

• AWS における鍵管理の基本方針
• 現場でよくある運用の何が危ないのか
• 理想に一気に行けない場合のベストエフォートな改善順

ここで扱う運用例は、特定の会社の実例をそのまま書いたものではありません。
複数の現場で見られやすいパターンを一般化して整理しています。

対象読者は次のような人です。

• AWS 上の運用を引き継いだ人
• EC2 や Bastion のアクセス管理に不安がある人
• 共有鍵や共有パスワード運用を少しずつ改善したい人

結論

AWS の鍵管理は、次の順で改善すると失敗しにくくなります。

1. 共有鍵と共有パスワードをやめる
2. 個人単位で認証できる状態にする
3. 人が秘密情報をコピーして使う運用を減らす
4. 操作記録を申告ベースではなくログベースに寄せる
5. 最終的に SSM Session Manager や IAM ベースのアクセスへ寄せる

要するに、認証情報を安全に保管することより先に、配らない構造へ寄せることが重要です。

AWS での理想形

AWS で管理しやすいのは、個人を IAM 系の仕組みで認証し、EC2 へのアクセスは SSM Session Manager を使う形です。

考え方は次のとおりです。

• 人は IAM Identity Center などで個人認証する
• EC2 には SSH 鍵を配らず、Session Manager で入る
• AWS API 操作は CloudTrail で追跡する
• アプリケーションの秘密情報は Secrets Manager や Parameter Store で管理する

この構成の利点は次のとおりです。

• 個人識別しやすい
• 長期利用される SSH 鍵の配布を減らせる
• 監査ログを AWS 側に集めやすい
• 退職や異動時の権限剥奪がやりやすい

現場でよくある構成

よくある運用例として、次のような流れがあります。

作業者PC
  ↓
本番作業時に秘密鍵を登録
  ↓
踏み台サーバへ接続
  ↓
各種本番リソースを手作業で操作
  ↓
作業終了後に秘密鍵を削除

さらに、次のような運用が重なりがちです。

• 秘密鍵を本番作業時に登録し、終了後に削除する
• 管理者パスワードをファイルで共有する
• 作業履歴をチャットや表計算ファイルで管理する
• QA と本番で似た運用を続ける

この構成は、現場では回っているように見えても、技術的な裏付けが弱くなりやすいです。

何が問題なのか

個人識別が弱い

共有鍵や共有パスワードを使うと、誰が実際に操作したかを技術的に証明しにくくなります。

現場によっては、次のように手動で証跡を残そうとすることもあります。

• 表計算ファイルで、誰がいつ作業したかを記録する
• チケットに、実行した SQL やコマンド、実行ログを添付する

この運用には意味があります。
少なくとも、何も残っていない状態よりは調査しやすく、作業内容の追跡もしやすくなります。

ただし、次の限界があります。

• 申告ベースであり、実際の操作ログと自動では結びつかない
• 共有鍵や共有パスワードでは技術的な本人証明が弱い
• 記録漏れや添付漏れが起きうる

そのため、証跡に近づける工夫ではあっても、完全な監査ログにはなりません。

秘密情報が平文で配布される

秘密鍵や管理者パスワードをファイルで配る運用は、それ自体が漏えい面を増やします。

本番作業のたびに鍵を登録し、終了後に削除する運用は、常設鍵よりはましです。
使い終わった鍵を残し続けないようにしている、という点では評価できます。

特に危ないのは次のような状態です。

• ローカル端末に秘密鍵が残る
• クリップボード履歴にパスワードが残る
• 誤って別環境へ貼り付ける
• 古いファイルが消えずに残る

ただし、それでも登録から削除確認までを人手で回している構造そのものは残ります。
運用として丁寧ではありますが、自動的に担保される仕組みではありません。

ローテーションしにくい

共有認証情報は、変更のたびに全員へ再配布が必要です。

そのため、次の状態になりやすくなります。

• 面倒なので鍵やパスワードを変えない
• 古い認証情報が複数端末に残る
• 退職者や異動者の経路を完全に止めにくい

権限が広すぎる

踏み台サーバに入れる人が、そのまま Kubernetes や本番 DB などまで触れる構成は珍しくありません。

この状態では、最小権限の原則が崩れやすくなります。
本来は次を分けて考えるべきです。

• サーバへ接続できる権限
• デプロイできる権限
• Kubernetes を操作できる権限
• データを更新できる権限

AWS 側の監査に乗りにくい

共有 SSH 鍵や共有パスワードによる操作は、AWS 側の個人識別とつながりにくくなります。

CloudTrail は AWS API の記録には強いですが、共有認証情報で踏み台サーバに入り、その上で手作業した内容までは、そのままではきれいに追えません。
SSH ログイン後の操作、DB 操作、kubectl 操作などは、別途ログ設計が必要です。

なぜ AWS は「配らない」方向なのか

AWS のベストプラクティスは、長期的な認証情報の配布を減らし、できるだけ一時的な認証と集中管理へ寄せることです。

理由は次のとおりです。

• 秘密情報を配るほど漏えい経路が増える
• 個人単位の認証と権限剥奪が難しくなる
• 手作業の証跡管理が運用依存になりやすい
• 長期鍵の棚卸しとローテーションが重くなる

つまり、鍵を厳重に保管するより、そもそも人に配らない構造の方が管理しやすいということです。

ベストエフォートで改善するなら何からやるか

理想構成へ一気に移行できない場合は、次の順が現実的です。

1. まず共有鍵と共有パスワードをやめる

最初の改善はここです。

• 作業者ごとに個別アカウントを発行する
• 共有の管理者パスワードを廃止する
• 退職者や異動者を個別に止められる状態にする

この段階でも、運用の危険度はかなり下がります。
本番作業時だけ鍵を登録し、終了後に削除する運用は、この前段としては比較的丁寧です。
ただし、理想は登録と削除の手作業自体を減らすことです。

2. 秘密情報のコピペ運用をやめる

次に、人が秘密情報をファイルから拾って貼り付ける運用を減らします。

人が使う認証情報は、少なくとも次のように改善したいです。

• 共有フォルダ配布をやめる
• パスワードはテキストファイルで置かない
• 可能ならパスワードマネージャや一時発行へ寄せる

アプリケーションや自動化が使う秘密情報は、Secrets Manager や Systems Manager Parameter Store へ寄せる方が安全です。

3. Bastion 上の権限を分ける

Bastion 自体が直ちに悪いわけではありません。
VPN や private subnet と組み合わせた構成は、今でも広く使われています。
ただし、Bastion に依存しすぎると権限が集中しやすいため、すぐ消せない場合でも権限は絞れます。

例えば次のように分離します。

• 本番用と QA 用の接続経路を分ける
• Kubernetes の操作権限を namespace 単位で分ける
• DB 更新系の権限を限定する
• 参照専用と更新可能を分ける

重要なのは、Bastion に入れたら全部できる状態を崩すことです。

4. 記録を申告から証跡へ寄せる

表計算ファイルやチケット運用自体を全否定する必要はありません。
ただし、それだけでは弱いです。

例えば、次のような運用はそのまま活かす価値があります。

• 表計算ファイルで利用履歴を管理する
• チケットに実行した SQL やコマンド、実行ログを残す

少なくとも次を残せるようにします。

• 誰が実行したか
• どの環境で実行したか
• 何の作業をしたか
• 実行コマンドや変更内容
• 結果がどうだったか

さらに、次まで揃うとかなり強くなります。

• 実行した SQL の全文
• 実行ログ
• 実行前の確認結果
• 実行後の結果や件数
• 実行日時

手書きの申告だけではなく、ログや履歴と対応づけられる状態へ近づけることが大切です。
人間の記録を残す段階から、再現可能なログへ寄せていくイメージです。

5. 一部から SSM Session Manager へ移す

最後は、Bastion 依存を減らしていきます。

全部を一度に変えなくても構いません。
例えば次の進め方があります。

• 新規に作る EC2 だけ Session Manager 対応にする
• 運用者の一部から先に移す
• SSH 必須の用途だけを切り分ける
• 踏み台サーバ経由でしかできない作業を棚卸しする

段階的でも、運用の重心が SSH 鍵配布から離れていけば効果があります。
一方で、SSH 前提のツールや legacy 環境が残る場合は、Session Manager だけで完全に置き換えられないこともあります。
その場合でも、適用できる範囲から移していく進め方が現実的です。

Kubernetes 運用で特に気をつける点

EKS や self-managed Kubernetes では、Bastion 経由で kubectl を叩く文化が残りやすいです。

ここで危ないのは、接続経路の問題だけではありません。
次の 2 つが同時に起きやすいことです。

• クラスタ操作権限が広い
• 操作が人手と口頭運用に寄る

そのため、鍵管理だけを直しても不十分です。
少なくとも次はセットで見直す必要があります。

• kubectl 実行者の個人識別
• RBAC による権限分離
• 本番操作を CI/CD に寄せられないか
• 手作業前提の運用を減らせないか

ベストエフォートでも避けたい運用

すぐには全部直せなくても、次の状態は長く残さない方がよいです。

• 共有フォルダに秘密鍵を置く
• パスワードをテキストで配る
• 誰でも同じ管理者アカウントを使う
• 作業記録がチャットと口頭だけ
• 退職者の経路を個別に止められない

これらは、忙しい現場ほど後回しにされやすいですが、事故時の説明責任が一気に重くなります。

まとめ

AWS の鍵管理で重要なのは、鍵を上手に配ることではありません。
人に長期認証情報を配る前提を減らすことです。

実務では次の順で改善すると進めやすくなります。

1. 共有鍵と共有パスワードをやめる
2. 個人単位で認証と権限管理を行う
3. コピペ前提の運用を減らす
4. ログベースで追えるようにする
5. SSM Session Manager や IAM ベースへ寄せる

理想に一気に届かなくても構いません。
重要なのは、共有鍵と手作業運用を当然としないことです。
それだけでも、現場の安全性と運用性はかなり変わります。

参考資料

• AWS Systems Manager Session Manager: https://docs.aws.amazon.com/systems-manager/latest/userguide/session-manager.html
• AWS IAM Identity Center: https://docs.aws.amazon.com/singlesignon/latest/userguide/what-is.html
• AWS Secrets Manager best practices: https://docs.aws.amazon.com/secretsmanager/latest/userguide/best-practices.html