AWS CLI を使うのに、アクセスキーを発行していませんか？
私も昔はそうでした。便利なんですよね、アクセスキー。
一度 aws configure で設定すれば、あとはずっと使えます。
でも、この便利さの裏に、ちょっとこわい話があります。
漏らせば高額な請求、情報流出、失う信頼。しかも一度漏らしたら取り返せません。
この記事では、アクセスキーとの付き合い方と、どうやってやめていくか、そして漏らさない工夫をまとめます。
アクセスキーとは
アクセスキーについて簡単におさらいします。
アクセスキーは、IAM ユーザーに紐づく認証情報で、アクセスキー ID とシークレットアクセスキーのペアです。
AWS CLI や SDK から AWS を操作するときに使います。
メリット
- どこでも使えて、仕組みが単純
- 導入が簡単
デメリット
- 有効期限なし
- ローテーションが手動
- 漏洩すると、そのまま不正利用に直結
そして、いざ漏れたときに待っているのは、こんな現実です。
- 漏洩したアクセスキーで暗号資産のマイニングや大量のリソースを立ち上げられ、高額な請求
- 権限しだいでは S3 や DB の中身を根こそぎ抜かれ、個人情報が流出
- 情報漏洩が報道され、謝罪に追われ、積み上げてきた信頼が一気に崩れる
- 一度ネットに出た情報や漏洩したアクセスキーは、完全には回収できない
実際に起きたこと
これは大げさな話ではなく、実際に起きています。
大手 IT 企業の担当者が個人の public リポジトリにアクセスキーを含むコードを上げてしまい、4日間で 244 台の VM を起動され、$64,000 の請求が発生した事例です。
公開されていた時間は24時間未満でしたが、大半の VM はその24時間以内に立ち上がっていました。
「気づいてすぐ消せば大丈夫」が通用しないのは、悪用までが速すぎるからです。
権限を一切付けていないアクセスキーを public リポジトリに置いて計測した検証では、git push から13分で外部からの利用が始まっています。
AWS 自身も、2025年11月から続くクリプトマイニングキャンペーンについて、侵害された IAM 認証情報を使い、初期アクセスから10分以内にマイナーが稼働していたと報告しています。
しかも、請求データの更新は少なくとも24時間に1回。
コスト異常に気づいた頃には、とっくに終わっています。
「たかがアクセスキーひとつ」が、ここまで大ごとになり得ます。
これが"こわい"と言っている理由です。
使うシーンと代替案
では、アクセスキーをやめたいとして、代わりに何を使えばいいのか。
シーンごとに"代替案"が用意されています。
| シーン | アクセスキー | 代替案 |
|---|---|---|
| 開発者 |
aws configure で設定 |
aws login / aws sso login
|
| AWS リソース（EC2/Lambda/ECS） | リソースに埋め込み | IAM ロール |
| CI/CD（GitHub Actions 等） | Secrets に登録 | OIDC |
| オンプレ・外部サーバー | サーバーに配布 | IAM Roles Anywhere |
順番に見ていきます。
開発者は aws login
私たち開発者が使うケースです。
使うのは aws login です。
ブラウザで認証すると、一時クレデンシャルを自動で設定してくれるコマンドです。
IAM Identity Center を入れている環境で使う aws sso login と同じ使用感で使えます。
「IAM Identity Center を入れるほどじゃない」という環境に向いています。
これで、アクセスキーを使わない運用が簡単に実現できます。
AWS リソースは IAM ロール
EC2 や Lambda、ECS のような AWS リソースで使うケースです。
アクセスキーを埋め込む代わりに、IAM ロールを使います。
ロールをアタッチすると、一時的な認証情報が自動で渡される仕組みで、アクセスキーを持たずに済みます。
CI/CD は OIDC
GitHub Actions のような CI/CD で使うケースです。
Secrets にアクセスキーを登録する代わりに、OIDC を使います。
GitHub と IAM ロールを結び付けて、一時的にアクセス権を発行する仕組みで、アクセスキー不要で AWS にアクセスできます。
オンプレ・外部サーバーは IAM Roles Anywhere
オンプレや AWS の外にあるサーバーから操作するケースです。
アクセスキーを配布する代わりに、IAM Roles Anywhere を使います。
X.509 証明書で信頼関係を結び、一時的な認証情報を取得できる仕組みで、AWS 外のサーバーにもアクセスキーを配らずに済みます。
共通する考え方
こうやって並べてみると、共通している考え方に気付きます。
アクセスキーのような有効期限がない長期クレデンシャルとは違い、どれも有効期限付きの一時クレデンシャルを使用していることです。
このように一時クレデンシャルに切り替えていくことが大事です。
それでも使うなら
「じゃあ、アクセスキーを使うシーンなんて、もう残ってないんじゃない？」と思いますよね。
残っているとすれば、"移行できないもの"くらいです。
例えば、
- ロールや OIDC に非対応でアクセスキーしか受け付けない古いツール
- 証明書運用ができず、IAM Roles Anywhere が組めない環境
- 改修できないレガシーアプリ
- その場限りの使い捨て検証
こういう「どうしても」の場面ですね。やめることができないなら、守りを固めましょう。
漏らさない工夫
この「漏らさない工夫」は、アクセスキーを使い続ける人だけの話じゃありません。
シークレットは、アクセスキーだけではないです。
DB のパスワードも、API トークンも、同じように漏れます。
たとえアクセスキーをやめても、「漏らさない工夫」は一生ついてまわります。
シークレットはこうして漏れる
そもそも、シークレットって、どうやって漏れると思いますか？
GitGuardian の調査では、public な GitHub コミットから2025年だけで2900万件のシークレットが検出されました。
漏洩インシデントの約28%は、コードリポジトリの外、チャットなどのコラボレーションツールで起きているそうです。
漏れ口はコードだけではない、ということですね。
大きく3つにまとめてみます。
共有・受け渡し系
- Git にコミットして push
- Slack やチャット、メールに貼って共有
- 登壇資料やブログ、スクショに映り込む
-
.envや credentials を、そのままファイル共有・アップロード
配布物に埋め込み系
- フロントの JS やモバイルアプリに埋め込み
- Docker イメージのレイヤーに残ったまま配布
- 配布用のビルド成果物やインストーラーに混入
環境・運用系
- CI/CD のビルドログに出力
- ローカル PC がマルウェアに感染して抜かれる
- 退職者が持ち出し
守りは3段構え
漏れ方はさまざまですが、件数で見ると圧倒的に多いのは"コードへの混入"です。
そしてその多くは、悪意ではなく"うっかり"です。
その"うっかり"を仕組みで止めましょう。
具体的には、予防・防御・検知の3段構えです。
なお以下は、いちばん多い"コードへの混入（Git）"を例に説明します。
考え方は、ほかの漏れ方にも応用できます。
予防
漏らす前に、入口で止めます。止めどころは、クライアントとサーバーの2箇所です。
クライアントでは gitleaks。
pre-commit hook を入れておけば、コミットしようとした瞬間にシークレットを弾いてくれます。
サーバーでは GitHub の Push Protection。
push した時点で、シークレットを含む変更をブロックしてくれます。
防御
万が一漏れても、被害を最小化します。
最小権限ポリシーで、そのアクセスキーでできることを絞ります。
IAM ポリシーの Condition（aws:SourceIp など）で、アクセス元を限定します。
定期的にローテーションして、古い認証情報を残さないようにします。
検知
漏れても、すばやく気づきます。見るべき視点は2つです。
ひとつは、コードに混入していないか。
CI に gitleaks を組み込み、push のたびに走らせることで、混入があれば即検知できます。
もうひとつは、漏れたアクセスキーが使われていないか。
GuardDuty が CloudTrail などを分析し、AWS 外からの利用といった異常なクレデンシャル利用を検知してくれます。
漏れてしまったら
万一漏れてしまったら、初動が肝心です。
シークレットが漏れたら、コミットを消すより先に即無効化。
Git は履歴に残るので、コミットを消しても意味がありません。
無効化さえすれば、履歴に残った値はもう使えません。
まとめ
- アクセスキーをやめるための代替案がある
- やめることができない事情もある
- 漏らさないために3段構えで守る
セキュリティはビジネスの基盤です。
とはいえ気負わず、まずは手元の aws login から始めてみてください。