「コードに鍵を直書きしていませんか？」泥棒に入られないためのCI/CDセキュリティ入門
こんにちは。普段は企業の防御壁を固める仕事をしていますが、今日は皆さんと一緒に「開発現場の当たり前」を少しだけアップデートしていきましょう。
突然ですが、皆さんの家の鍵を「玄関の植木鉢の下」に隠したり、「家族全員が共有するメモ用紙」に書いて壁に貼ったりはしませんよね？実は、多くの開発現場で、これと全く同じことが起きています。それが、「ソースコードの中にAPIキーやパスワードを直接書き込んでしまう」という行為です。
今日は、GitHub Actionsなどの自動化パイプライン（CI/CD）を守るための、少しだけ進んだ「鍵の管理術」についてお話しします。
—
1. なぜ「ハードコード」は泥棒を喜ばせるのか？
ソースコードに認証情報を書いてしまうこと、これを専門用語で「ハードコード」と呼びます。
なぜこれが危険なのか。例えるなら、「家の合鍵をSNSにアップする」のと同じだからです。GitHubのリポジトリが公開設定になっていれば、世界中の泥棒（攻撃者）がその鍵を見つけ出します。たとえ非公開リポジトリであっても、もしあなたのPCがウイルスに感染したり、誤って誰かに共有してしまった瞬間に、あなたのクラウド環境への全権限が奪われてしまうのです。
攻撃者は、GitHubの「公開ログ」を24時間監視しています。あなたが鍵をコミットした瞬間に、数秒も経たずにその鍵を使ってサーバーに侵入し、仮想通貨のマイニングを始めたり、顧客データを盗み出したりします。彼らにとって、ハードコードされたAPIキーは「どうぞ自由に使ってください」という招待状なのです。
—
2. 「固定の鍵」から「使い捨ての通行証」へ
では、どうすればいいのでしょうか？ 答えは「鍵を渡さない」ことです。
これまでの管理方法は「ずっと使えるマスターキー（固定のAPIキー）」を環境変数に設定することでした。しかし、これだとその鍵が盗まれたら最後、ずっと使われ続けてしまいます。
最新のトレンドは、「OIDC（OpenID Connect）」という仕組みを使った「一時的な通行証」の発行です。
OIDCってなに？
難しい名前ですが、仕組みは簡単です。
1. GitHubが、「私は〇〇プロジェクトのビルドをしている正当なプログラムです」と証明書を発行する。
2. クラウド（AWSやGCPなど）が、「その証明書なら信頼できるね。じゃあ、たった1時間だけ使える通行証をあげるよ」と返す。
3. 1時間後、その通行証はゴミ箱行きになる。
つまり、万が一この通行証が漏れても、泥棒がやってきた時にはすでに期限切れになっているのです。これなら安心ですよね。
—
3. 実践：GitHub ActionsとAWSの連携
実際に、AWSでOIDCを使って認証する設定例を見てみましょう。GitHub Actionsのワークフローファイル（`.github/workflows/deploy.yml`）はこんなイメージになります。
jobs:
deploy:
runs-on: ubuntu-latest
# 1. AWSから一時的な権限をもらうための設定
permissions:
id-token: write # これが「一時的な通行証」を発行するために必須！
contents: read
steps:
- name: AWSに一時ログイン
uses: aws-actions/configure-aws-credentials@v4
with:
# ここにAWSで作成した「ロール」のARNを書く（鍵そのものではない！）
role-to-assume: arn:aws:iam::123456789012:role/my-github-actions-role
aws-region: ap-northeast-1
- name: デプロイ実行
run: aws s3 sync ./dist s3://my-website-bucket
ここで重要なのは、「APIキーを一行も書いていない」という点です。代わりに、AWS側で「GitHubのこのリポジトリからのアクセスなら許可する」というルール（IAMロール）を一つ作っておくだけで済みます。
—
4. 今日からできる「一歩」
いきなり全てをOIDCに変えるのは大変かもしれません。まずは、現場で今日からできる防犯対策をまとめました。
- git-secrets や TruffleHog を使う:
これらは「コードの中に鍵っぽい文字列がないか」をコミット前に自動でチェックしてくれるツールです。うっかりミスを物理的に止めてくれます。
- 環境変数（Secrets）を使う:
どうしてもOIDCが使えない場合は、GitHubの「Settings > Secrets and variables」に値を保存してください。コードに書くより100倍安全です。
- 定期的な鍵の棚卸し:
「昔作ったあの鍵、まだ生きてない？」と定期的に確認し、不要な権限は即座に削除（無効化）しましょう。
—
最後に：セキュリティは「完璧」を目指さない
「セキュリティを完璧にしよう」とすると、開発が止まってしまいます。一番大切なのは、「万が一、鍵を盗まれても被害を最小限にする」という考え方です。
今回紹介したOIDCへの移行は、少しだけ手間がかかります。でも、その手間で「夜中に電話で叩き起こされるインシデント」が一つ減ると思えば、安い投資だと思いませんか？
まずは、今書いているコードに「APIキー」が直書きされていないか、検索することから始めてみましょう。小さな一歩が、あなたとチームの資産を守る最強の壁になります。
また次の記事で、現場の知恵を共有しますね。安全な開発ライフを！
コメント