この記事の要点
- 3つのクラウドとも、長く使えるアクセスキーより、自動で入れ替わる一時的な認証情報を使う設計を勧めています。
- クラウドの中で動く仕組みには役割（ロール）やマネージド ID を割り当て、外で動く仕組みは外部の認証との連携でキーを持たずに済ませます。
- キーが残る場合は、置き場所・使われ方の記録・定期的な見直しを決め、ソースコードの保管場所に紛れ込んでいないかを仕組みで確かめます。
アクセスキーの漏えいを防ぐ確かな方法は、長く使えるアクセスキーをそもそも作らない設計にすることです。クラウドの中で動く仕組みには役割を割り当て、人のログインは一時的な認証情報にし、どうしてもキーが残る場合だけ、置き場所と見直しの決まりを厳しくします。
アクセスキーは、なぜ危ないのですか
アクセスキーとは、プログラムなどがクラウドを操作するときに使う、IDと秘密の文字列の組です。パスワードと違ってログインの画面を通らないため、文字列を手に入れた人は、そのキーに許された操作をそのまま行えます。
Google Cloud は、サービスアカウントのキーについて、事前の認証なしに使えるため、キーを持っている人なら誰でも使えると説明しています。キーが漏れると、攻撃者はそのサービスアカウントと同じ権限を得ます。また、操作の記録にはサービスアカウントの名前が残るものの、誰がキーを使ったのかを確かに見分ける方法はないため、後から追うのも難しくなります。
出典：Best practices for using service accounts securely（Google Cloud）
AWS も、アクセスキーを作る前に、長く使えるキーの代わりになる方法を確かめるよう求めています。アプリケーションのファイルや、プロジェクトのフォルダにキーを置かないこと、権限のない人には、たとえ手伝いのためでもキーを渡さないことを挙げ、渡すと相手にずっと使える権限を与えるおそれがあるとしています。
出典：Manage access keys for IAM users（AWS）
キーを使わない設計
キーを使わない設計とは、動く場所に応じて、自動で発行され、時間がたつと使えなくなる一時的な認証情報を使う形にすることです。3つのクラウドとも、この形を勧めています。
- クラウドの中で動く仕組み：AWS では、Amazon EC2 や Lambda で動かす場合、AWS が IAM ロールの一時的な認証情報をその資源に渡すため、長く使えるキーを配る必要はないと説明しています。Microsoft Azure では、マネージド ID を使うと、開発者が認証情報を管理せずに済み、認証情報そのものに触れることもないとしています。Google Cloud では、資源にサービスアカウントを割り当てる方法を勧めています
- クラウドの外で動く仕組み：社内のサーバーや別のクラウドで動く仕組みは、外部の認証と連携して一時的な認証情報を受け取る方法があります。Google Cloud は Workload Identity Federation を挙げています。AWS も、AWS の外で動く仕組みが一時的な認証情報を使うことはできるものの、その渡し方を用意する必要があるとしています
- 人のログイン：AWS は、人が使うときも一時的な認証情報にし、会社の認証の仕組みと連携してロールを引き受ける形を勧め、まとめて管理するには AWS IAM Identity Center を勧めています
出典：Security best practices in IAM（AWS）
出典：What are managed identities for Azure resources?（Microsoft Learn）
出典：Best practices for using service accounts securely（Google Cloud）
さらに、キーを作れないように組織の決まりで止める方法もあります。Google Cloud は、サービスアカウントのキーの作成とアップロードを止める組織のポリシーを勧め、2024年5月3日以降に作られた組織では、初めからこの制約がかかっていると説明しています。どうしてもキーが要る場面では、例外をできるだけ狭く認めるよう案内しています。
権限の割り当て方そのものは、クラウドの権限管理（IAM）の基本。最小の権限とはで説明しています。
キーが残る場合の管理
古い仕組みとの連携などで、長く使えるキーがどうしても残る場合は、置き場所、使われ方の記録、見直しの時期を決めて管理します。
- 台帳をつくる：どのキーを、どの仕組みが、何のために使っているかを一覧にする。持ち主の分からないキーを残さない
- 権限を絞る：そのキーで行う操作だけを許す。管理者の権限を持つキーを作らない
- 置き場所を決める：ソースコードや設定のファイルに書かず、クラウドの秘密情報の保管の仕組みなどにまとめる
- 使われ方を見る：操作の記録で、いつ、どこから使われたかを確かめられるようにする
- 定期的に見直す：使われていないキーを消し、担当者が辞めたときなどに入れ替える
AWS は、AWS CloudTrail でアクセスキーの使われ方を見て不正なアクセスの試みに気づくこと、キーを定期的に見直して入れ替え・削除すること、最後に使われた日の情報を使って安全に入れ替え・削除することを勧めています。ルートユーザー（最上位の管理者）の認証情報でアクセスキーを作らないことも挙げています。
出典：Manage access keys for IAM users（AWS）
出典：Security best practices in IAM（AWS）
管理者のアカウントの守り方は、管理者アカウントの守り方。多要素認証と緊急用のアカウントにまとめています。
ソースコードに紛れ込ませない
キーの漏えいでよく起きるのは、開発の途中でソースコードや設定のファイルにキーを書き、そのまま保管場所に登録してしまう形です。人の注意だけに頼らず、仕組みで見つけるようにします。
例えば GitHub のシークレットスキャンは、リポジトリに書き込まれた API のキーやパスワード、トークンなどを自動で見つけ、すべてのブランチの履歴まで調べて、見つかると知らせます。公開のリポジトリでは無料で動き、組織の非公開のリポジトリでは有料の機能を使います。
出典：About secret scanning（GitHub Docs）
履歴に一度でも残ったキーは、後から消しても、取り出されている可能性があります。見つかったら、ファイルを直すだけで終わらせず、キーを無効にして新しいものに入れ替えます。
漏れたかもしれないときの動き方
キーが漏れたかもしれないと分かったら、使われたかどうかの調べを待たずに、まずキーを無効にします。そのうえで、操作の記録から、漏れた後に何が行われたかを確かめます。
- キーを無効にし、そのキーを使っている仕組みには、新しい認証情報を渡す
- 操作の記録で、見覚えのない資源の作成、権限の変更、データの持ち出しがないかを確かめる
- 見覚えのない資源や権限が見つかったら、消す前に記録を残し、影響の範囲を整理する
- 個人データが関わる場合は、法令にもとづく報告が要ることがあるため、個別の判断は弁護士などの専門家にご確認ください
初動の手順は、あらかじめ手順書にしておくと迷わずに動けます。手順書のつくり方は、セキュリティ事故に備える、初動の手順書のつくり方で説明しています。不正な利用に早く気づく仕組みは、クラウドの不正利用に気づく。脅威の検知の仕組みを参照してください。
当社のご支援
アメリア・テクノロジーのクラウドの構築と運用管理では、アクセスキーの棚卸し、役割（ロール）やマネージド ID への置き換え、キーを作らせない決まりの設定をお手伝いしています。いまの環境にどのくらいキーが残っているかを確かめるところから始めることもできます。当社の担当者による設定の点検は、クラウドのセキュリティ診断としてもお受けしています。当社が構築・運用している環境の診断は、自己点検として報告します。
- アクセスキー
- IAM
- クラウド
- 認証情報
この記事に出てくる用語
このコラムは一般的な情報の提供を目的としたもので、個別の状況への助言ではありません。製品・サービスの名前と内容は、記事の更新日の時点のものです。