シークレット管理とは？APIキー・トークン・認証情報の漏洩を防ぐ安全な管理方法をわかりやすく解説

「APIキーをうっかりGitHubに上げてしまった」「環境変数で管理しているつもりだったが、本番サーバーに平文で書いてあった」――こんな経験や不安を持つエンジニアは少なくありません。

シークレット（Secret）と呼ばれるAPIキー・パスワード・アクセストークン・証明書などの機密情報は、一度漏洩すると数分以内に悪用されるケースが報告されています。正しく管理できているかどうかは、企業のセキュリティの土台に関わる問題です。

この記事では、シークレット管理の基本概念から、よくある管理ミスの落とし穴、今日から実践できる対策手順まで、現場で使えるレベルで解説します。

シークレット管理とは？なぜ今すぐ取り組むべきか

シークレット管理（Secret Management）とは、システムが必要とする機密情報を安全に保管・配布・ローテーション・廃棄するための仕組みと運用を指します。

「シークレット」に該当する情報は多岐にわたります。

・APIキー: 外部サービス（決済・メール送信・地図など）への認証に使う文字列
・データベースパスワード: アプリケーションがDBに接続するための認証情報
・アクセストークン: クラウドサービスやOAuth連携で使う一時認証情報
・秘密鍵（Private Key）: TLS証明書・SSH・コード署名などに使う暗号鍵
・サービスアカウント認証情報: AWS IAMキー・GCPサービスアカウントJSONなど
・Webhookシークレット: GitHub・Slackなどのイベント通知の真正性を確認するトークン

これらのシークレットが漏洩すると、攻撃者はシステムへの不正アクセス、データ窃取、クラウドリソースの不正利用（費用の発生）、さらには取引先サービスへの影響まで引き起こすことがあります。

なぜ「今すぐ」取り組む必要があるのか。理由の一つは、パブリックなコードリポジトリを自動的にスキャンし、コミットされたシークレットを数秒以内に検出して悪用するボットが実際に動いているからです。GitHubなどのサービス自体も「シークレットスキャン」機能を提供していますが、それに頼るだけでは不十分です。根本的な管理方法を整えることが先決です。

よくある「シークレットの管理ミス」4パターン

現場でよく見られる管理ミスを整理しておきましょう。

【注意】パターン1: ソースコードへのハードコード

最も多く、かつ最も危険なミスがコード内への直書きです。

# NG例: Pythonコードに直書き
API_KEY = "sk-xxxxxxxxxxxxxxxxxxxxxxxx"
DB_PASSWORD = "MySecretPass123"
aws_access_key = "AKIAIOSFODNN7EXAMPLE"

開発中の「とりあえず動かす」コードがそのままコミットされ、GitHubの公開リポジトリに漏洩するパターンが後を絶ちません。プライベートリポジトリであっても、リポジトリの設定ミスや権限の広すぎるトークンを通じて流出することがあります。

【注意】パターン2: 設定ファイルの.gitignore漏れ

# NG例: .env ファイルを .gitignore に追加し忘れる
$ git add .
$ git commit -m "初期設定"
# → .env（DBパスワード含む）がコミットに含まれてしまう

`.env`ファイルや`config.yml`などに認証情報を書いて、`.gitignore`への追加を忘れるケースです。一度コミット履歴に入ってしまうと、ファイルを削除した後も`git log`や`git show`で履歴を辿れば取り出せてしまいます。

【注意】パターン3: ログへの出力

デバッグのためにシークレットをログ出力する処理が本番コードに残ってしまうパターンです。アプリログがSIEMやログ管理ツールに転送される場合、アクセス権限のある社員全員が見られる状態になることもあります。

【注意】パターン4: 環境変数の誤った使い方

環境変数はハードコードより安全ですが、使い方を間違えるとリスクが残ります。シェルスクリプト内で`env`コマンドを使って全環境変数をログ出力したり、エラーメッセージに`$DATABASE_URL`の内容が含まれたりするケースが典型的です。

シークレット漏洩が引き起こすリスク

シークレットが漏洩した場合に起きうる被害の範囲をまとめておきます。

クラウドサービスのAPIキーは特に危険で、漏洩から悪用までの時間が非常に短く、数分で数十万円規模の不正利用が発生した事例も一般的に知られています。

具体的な防御手順

1. ハードコードを今すぐ撲滅する

まずソースコードの中にシークレットが直書きされていないか確認します。既存のコードベースを検索するには、`git grep`や専用ツールが有効です。

# パスワード・APIキーらしい文字列を検索する例
$ git grep -i "password\|api_key\|secret\|token\|private_key" -- "*.py" "*.js" "*.php"

# truffleHogでコミット履歴全体をスキャン（インストール後）
$ trufflehog filesystem --directory=. --json

発見したハードコードは即座に削除し、該当のシークレットは新しい値に再発行してください。コードから削除しても、コミット履歴に残り続けることを忘れないようにしましょう。

2. 環境変数・シークレット管理ツールを活用する

シークレットはコードの外に分離するのが基本です。段階に応じた選択肢を示します。

開発環境向け: .envファイル＋dotenvライブラリ

# .env ファイル（リポジトリに含めない）
DATABASE_URL=postgresql://user:pass@localhost/mydb
STRIPE_API_KEY=sk_test_xxxxxxxxxxxxxxxx

# .gitignore に必ず追加
echo ".env" >> .gitignore

# Python での読み込み例
from dotenv import load_dotenv
import os
load_dotenv()
db_url = os.environ["DATABASE_URL"]

本番環境向け: クラウドのシークレットマネージャー

クラウドを使っている場合は、提供されているシークレット管理サービスが便利です。

・AWS Secrets Manager: シークレットの自動ローテーション機能あり
・Azure Key Vault: Azure環境でのシークレット・証明書管理
・Google Cloud Secret Manager: GCP環境でのシークレット管理
・HashiCorp Vault: クラウド非依存のオープンソース製品

これらのツールはシークレットへのアクセスをAPIを通じて行い、誰がいつアクセスしたかの監査ログを残せます。シークレットそのものをサーバーの設定ファイルに置く必要がなくなります。

3. Gitへの混入を防ぐ（.gitignoreとpre-commitフック）

シークレットがコミットされる前に検知するには、pre-commitフックが有効です。

# detect-secretsのインストール
$ pip install detect-secrets

# ベースラインファイル作成（既知の疑似シークレットをホワイトリスト化）
$ detect-secrets scan > .secrets.baseline

# pre-commitフックとして設定（.pre-commit-config.yaml）
repos:
- repo: https://github.com/Yelp/detect-secrets
  rev: v1.4.0
  hooks:
  - id: detect-secrets
    args: ['--baseline', '.secrets.baseline']

このようなフックを設定することで、コミット時にシークレットの疑いがある文字列を検出し、コミットを止める仕組みを作れます。

また、`.gitignore`のテンプレートとして[github.com/github/gitignore](https://github.com/github/gitignore)から言語・フレームワーク別のテンプレートを活用するのが確実です。

4. シークレットのローテーションを定期的に実施する

シークレットは「一度設定したら変えない」ではなく、定期的に更新することが重要です。

・APIキー: 90日を目安にローテーション。クラウドサービスは自動ローテーション機能を活用する
・DBパスワード: 退職者が出た際や四半期ごとに変更する
・TLS証明書: 有効期限前に自動更新（Let’s EncryptはACME対応で自動化が標準）
・SSHキー: 担当者の異動・退職時に旧キーを削除し、新しいキーを発行する

漏洩が疑われたシークレットは、疑いが生じた時点で即座に無効化・再発行します。「まず調査してから」という判断は誤りです。先に無効化してから調査する順序が基本です。

5. 最小権限でシークレットのスコープを絞る

シークレットに付与する権限は、そのサービス・処理に必要な最小限にとどめます。

想定例として：あるバッチ処理がS3バケットからファイルを読むだけの用途なら、そのAPIキーには読み取り専用権限のみを与えます。万が一そのキーが漏洩しても、書き込みや削除はできないため被害を限定できます。

また、マイクロサービスや複数アプリケーションで同じシークレットを使い回すのも避けるべきです。サービスごとに専用のシークレットを発行し、影響範囲を分離します。

中小企業でも今日からできること

「Vaultのような本格ツールを入れるのは難しい」という場合でも、最低限の対策として以下から着手できます。

・まずGit履歴を確認: `git log –all -S “password” –source`などでシークレットの混入履歴を確認する
・.envファイルを.gitignoreに追加: 既存のすべてのリポジトリで確認・修正する
・クラウドサービスのルートアカウントキーを削除: AWSであればルートアカウントのアクセスキーを使わず、IAMユーザーで最小権限を付与する
・使われていないAPIキーを棚卸しして削除: 未使用のシークレットは攻撃者に悪用されても気づきにくい
・GitHubのシークレットスキャン機能を有効化: GitHubプランによって無料で使える機能があり、コミット時に既知のシークレットパターンを検知してアラートを送ってくれる

システム担当者が1人しかいない環境であっても、これらの対策は1日あれば着手できます。「大きなインシデントが起きてから対応する」ではなく、仕組みを整えることが先です。

情報漏洩の概要・原因・経路については、情報漏洩とは？原因・経路・事例・対策をわかりやすく解説もあわせてご覧ください。

よくある誤解と注意点

【注意】「プライベートリポジトリだから安全」は誤り

プライベートリポジトリに置いてあるシークレットも、外部に漏洩するリスクがあります。リポジトリへのアクセス権を持つメンバーが増えるほどリスクは高まりますし、リポジトリのアクセストークン自体が漏洩するケースもあります。プライベートリポジトリへのコミットも「コードとシークレットを混在させない」原則は同じです。

【注意】「暗号化すれば安全」とは限らない

シークレットを暗号化してコードに含める方法（いわゆる「暗号化された設定ファイル」）は、復号に使うキーをどこで管理するかという問題が残ります。復号キーも同じリポジトリに置いてしまっては意味がありません。暗号化と鍵管理のセキュリティを両立するには、前述のシークレット管理ツールを使う方が確実です。

【注意】コミット後に「ファイル削除」では履歴から消えない

シークレットを含むファイルをコミット後に削除しても、`git log`で過去のコミットを辿れば取り出せます。完全に履歴から除去するには`git filter-repo`などのツールが必要ですが、それよりも漏洩したシークレットを即座に無効化・再発行する方が迅速で確実な対応です。

Webアプリケーション全体の安全な設計については、姉妹サイトDXMaster.JPでも開発・システム運用のセキュリティ観点を解説しています。

本記事のまとめ

シークレット管理は、エンジニアが毎日扱うAPIキーやパスワードを「正しく管理する」ための基盤です。

「シークレットをコードから分離する」という基本原則を徹底するだけで、多くの漏洩リスクを排除できます。まずは自社のリポジトリとサーバーのシークレット管理状況を棚卸しするところから始めましょう。