API キーとシークレットの安全な管理方法
この記事は約 3 分で読めます
API キーやシークレットは、サービスやデータへのプログラム的なアクセスを許可する認証情報です。GitHub の公開リポジトリに誤ってコミットされた AWS のアクセスキーが数分以内にボットに検出され、数百万円の不正利用が発生した事例は珍しくありません。本記事では、API キー漏洩のリスクと、環境変数やシークレットマネージャーを活用した安全な管理手法を、開発者の視点から実践的に解説します。
API キー漏洩が危険な理由
パスワードが個人のアカウントを保護するのに対し、API キーはサービス全体、データベース、クラウドインフラへの広範なアクセス権を付与することがあります。1 つの API キーが漏洩するだけで、システム全体が侵害される可能性があるのです。
自動化されたボットが公開リポジトリを常時スキャンし、露出した認証情報を探しています。GitGuardian の 2024 年レポートによると、GitHub 上で 1 年間に検出されたシークレットの数は 1,280 万件を超えました。キーが発見されると、攻撃者は数分以内に暗号通貨のマイニング、データの窃取、他システムへの攻撃に悪用します。クラウドサービスの従量課金モデルでは、不正利用による請求額が短時間で膨大になるリスクもあります。
API キーが漏洩する主な原因
ソースコードへのハードコード
API キーをソースコード内に直接記述するのは、漏洩の最も一般的な原因です。リポジトリがプライベートであっても、コードの共有、スクリーンショット、リポジトリのアクセス権変更などを通じてキーが露出する可能性があります。一度 Git の履歴にコミットされたキーは、コードから削除しても履歴に残り続けるため、完全な除去には `git filter-branch` や BFG Repo-Cleaner による履歴の書き換えが必要になります。
.env ファイルのコミット
.gitignore の設定漏れにより、シークレットを含む .env ファイルがリポジトリにコミットされるケースも頻発しています。プロジェクト初期に .gitignore を正しく設定し、.env、.env.local、.env.production などのファイルが確実に除外されていることを確認してください。
安全な開発環境の構築には、API セキュリティと認証情報管理の実践書 (Amazon)が参考になります。
クライアントサイドでの露出
フロントエンドの JavaScript に埋め込まれた API キーは、ページのソースコードを確認するだけで誰でも閲覧できます。書き込み権限や機密データへのアクセス権を持つキーは、絶対にクライアントサイドのコードで使用してはなりません。必要な場合は、バックエンドの API を経由してリクエストを中継する設計にしてください。なお、フロントエンドで使用する公開 API キー (Google Maps API キーなど) であっても、HTTP リファラー制限や API キーの使用量上限を設定し、不正利用を防止することが重要です。
API キーの安全な管理手法
環境変数による管理
API キーはソースコードではなく環境変数に格納するのが基本です。ローカル開発では .env ファイルを使用し、本番環境ではデプロイプラットフォームの環境変数設定機能を利用します。.env ファイルは必ず .gitignore に追加し、.env.example のようなテンプレートファイル (値を含まないキー名のみ) をリポジトリに含めることで、チームメンバーが必要な環境変数を把握できるようにします。
シークレットマネージャーの活用
本番環境では、AWS Secrets Manager、HashiCorp Vault、Google Secret Manager などの専用シークレット管理サービスの利用を推奨します。これらのサービスは、保存時の暗号化、きめ細かなアクセス制御、自動ローテーション機能を提供します。特に自動ローテーションは、キーの有効期間を制限することで、万が一の漏洩時の影響範囲を最小化する効果があります。AWS Secrets Manager の場合、シークレット 1 件あたり月額 0.40 ドル程度のコストで、手動管理のリスクと運用負荷を大幅に削減できます。
キーの定期的なローテーション
API キーを定期的にローテーション (更新) することで、漏洩が発生した場合の影響期間を限定できます。ローテーションの頻度はキーの重要度に応じて設定し、本番環境の重要なキーは 90 日以内、開発環境のキーは 180 日以内を目安にします。手動でのローテーションはヒューマンエラーの原因になるため、可能な限り自動化してください。注意点として、ローテーション時に旧キーを即座に無効化すると、デプロイのタイミングによっては一時的にサービスが停止する可能性があります。新旧キーの並行運用期間を設け、全システムが新キーに切り替わったことを確認してから旧キーを無効化する手順が安全です。
最小権限の原則
API キーには、その用途に必要な最小限の権限のみを付与してください。管理者レベルの認証情報をアプリケーションコードで使用することは避け、読み取り専用のキー、特定のリソースに限定されたキーなど、用途に応じた権限設定を行います。AWS の IAM ポリシーや Google Cloud の IAM ロールを活用し、きめ細かなアクセス制御を実装することが重要です。
権限設計やアクセス制御の実装パターンを深く学ぶには、IAM とアクセス制御設計の解説書 (Amazon)が役立ちます。
パスつく.com で強固な API キーを生成する
独自の API キーやシークレットを生成する必要がある場合、パスつく.com が役立ちます。Web Crypto API を使った暗号学的に安全な乱数で文字列を生成するため、予測不可能なキーを得られます。API キーの生成には、文字数を 32 文字以上に設定し、英大文字・英小文字・数字を有効にしてください。記号はサービスによって受け付けない場合があるため、対象サービスの仕様を確認したうえで設定します。強度メーターで 120 ビット以上のエントロピーが表示されていれば、API キーとして十分な強度です。
複数のキーを一度に生成する場合は、パスつく.com の一括生成機能を活用してください。サービスごと、環境ごとに異なるキーを効率的に作成できます。生成したキーはブラウザ内で処理が完結し、ネットワークを通じて外部に送信されることはないため、安心して利用できます。
漏洩の検知と対応
git-secrets、truffleHog、GitHub のシークレットスキャニング機能などのツールを活用し、誤ってコミットされた認証情報を検出してください。pre-commit フックを設定すれば、シークレットがコミットされる前に自動的にブロックできます。万が一キーが漏洩した場合は、即座にキーを無効化し、新しいキーを発行してください。漏洩したキーで不正なアクセスが行われていないか、アクセスログを確認することも重要です。