鍵を「隠す」な、「託せ」。ハードコーディング撲滅とKMS運用のリアル
現場でインシデント対応をしていると、笑えない現実に何度も直面する。攻撃者が侵入した際、彼らがまず最初に行うのは、ソースコードの grep や設定ファイル内の文字列検索だ。API_KEY, SECRET, PASSWORD といった文字列が、Gitのコミット履歴や本番環境の環境変数ファイルからいとも簡単に出てくる。
「開発環境だから」「急いでいたから」という言い訳は、フォレンジック調査の場では何の免罪符にもならない。今日は、君たちが今日から実践すべき「鍵のライフサイクル管理」の真髄を叩き込む。
—
1. なぜ「ハードコーディング」が即死フラグなのか
ハードコーディングされたキーは、一度流出すれば終わりだ。Gitの履歴から消すには git filter-branch や BFG Repo-Cleaner を使う必要があるし、漏洩した瞬間にそのキーは「公知の事実」となり、世界中のボットが数秒でそのキーをテストし始める。
攻撃者は、GitHub上の公開リポジトリを常時監視しているボットを走らせている。君がうっかり public リポジトリにプッシュした瞬間、AWSのIAMクレデンシャルが悪用され、数分後にはマイニングサーバーが立ち上がり、数百万の請求が君の会社に届くことになる。これが現実だ。
—
2. 脱・ハードコーディング：KMSとIAMの活用
鍵をソースコードに書くのではなく、実行環境の外（クラウドのKMSやSecrets Manager）に「託す」のが正解だ。アプリケーションは起動時にその権限（IAMロール）を使って鍵を取得し、メモリ上でのみ利用する。
実践：AWS Secrets Manager + Pythonでの実装
環境変数に直接キーを置くのも避けたい（ps コマンドでプロセス一覧を見ると漏洩するため）。AWS SDKを使って、実行時に動的に取得するのがベストプラクティスだ。
import boto3
import json
from botocore.exceptions import ClientError
def get_secret(secret_name, region_name="ap-northeast-1"):
"""
KMSで暗号化されたSecrets Managerからキーを取得する
IAMロールが割り当てられていれば、別途クレデンシャルは不要
"""
session = boto3.session.Session()
client = session.client(service_name='secretsmanager', region_name=region_name)
try:
get_secret_value_response = client.get_secret_value(SecretId=secret_name)
except ClientError as e:
# 本番環境では詳細なログを出しすぎないように注意
raise e
# シークレットはJSON形式で保存されていると想定
secret = json.loads(get_secret_value_response['SecretString'])
return secret['API_KEY']
# メモリ上で利用する（ファイルには書き出さない！）
api_key = get_secret("my-app/production/api-key")—
3. なぜ「KMS」を使うのか？
ただの環境変数とKMSがどう違うのか。それは「監査」と「権限分離」だ。
- 監査ログ: 誰が、いつ、そのキーを使ったのかが
CloudTrailにすべて残る。 - 自動ローテーション: 30日ごとにキーを自動更新する設定を入れれば、万が一漏洩しても被害を最小限に抑えられる。
- 最小権限の原則: アプリケーションサーバーにのみ「Read権限」を与え、開発者の手元には「Decrypt権限」だけを渡すといった制御が可能だ。
—
4. 運用ルールの鉄則
技術的な対策と併せて、以下の運用ルールをチーム全体で徹底してほしい。
1. .env ファイルは絶対にGit管理しない: .gitignore に必ず追加すること。
2. コミット前の自動スキャン: git-secrets や trufflehog を使い、コミットする前にキーの混入がないかチェックするフックを仕込む。
- これを入れるだけで、ヒューマンエラーによる漏洩の9割は防げる。
3. 環境ごとにKMSキーを分ける: 本番用の鍵とステージング用の鍵は、必ず暗号化キー（CMK）を別々に作成し、互いにアクセスできないようにする。
—
5. 最後に：セキュリティは「性悪説」で設計する
「誰も悪意を持っていない」という前提でシステムを組むのは、鍵をかけずに家を出るのと同じだ。僕たちエンジニアの仕事は、「誰かがキーを盗もうとしたときに、即座にアラートが上がり、かつ被害を最小化できる土台を作ること」にある。
明日から、君たちのリポジトリから grep をかけてみてくれ。「あ、これまずいかも」というファイルが一つでも見つかったら、それが君の最初の修正タスクだ。
セキュリティとは、終わりのない泥臭い作業の積み重ねだ。だが、その一歩が会社と、何より君自身を守ることになる。現場からは以上だ。また何かあればいつでも聞きに来てくれ。
コメント