【入門編】 IaCにおける機密情報（シークレット）のハードコード防止 – 暗号理論・認証基盤 & エンドポイントセキュリティ防御ガイド

こんにちは！インフラ構築やアプリ開発の現場で、日々コードを書いたりサーバーを触ったりしている皆さん、本当にお疲れ様です。

システムを作る時、私たちはたくさんの「設定」や「パスワード（シークレット）」を使いますよね。データベースに接続するためのパスワードや、クラウドサービスを動かすための重要な鍵など、これらは絶対に他人に知られてはいけない秘密の情報です。

でも、「うっかりパスワードをソースコードに直接書き込んでしまい、それをそのままインターネット上の公開リポジトリにアップロードしてしまった！」というインシデント、実はプロの現場でも後を絶ちません。

今回は、家の鍵の管理に例えながら、「なぜシークレットのハードコードが危険なのか」、そして「それをどうやって防ぐのか」を、一歩ずつ優しく紐解いていきましょう！

—

1. 家の鍵を「玄関のドアマットの下」に置いて出かけるようなもの？

まずは身近な例えから入りますね。

皆さんが旅行に出かける時、家の鍵をどうしますか？まさか「玄関のドアマットの下」や「郵便受けの中」に隠して出かけたりしませんよね。もしそんなことをしたら、泥棒がやってきた時に一発で見つかって、家の中を荒らされてしまいます。

実は、ソースコードの中にパスワードやAPIキーを直接書き込んでしまう（これをハードコードと言います）のは、まさに「家の鍵をドアマットの下に置いて、しかも『ここに鍵があります』と大書きした看板を立てている状態」なんです。

攻撃者はどうやって鍵を探すのか？

悪い人たち（攻撃者）は、一日中休むことなく、世界中のGitHubなどのソースコード置き場を自動プログラムで巡回しています。そして、以下のような文字列がコードの中に書かれていないかを常に探しています。

api_key = "AIzaSy..."
password = "secret1234"

もし、うっかりこれらを書き込んだままコードを保存してしまうと、わずか数秒のうちにボットに発見され、あなたのクラウド環境が乗っ取られてしまいます。暗号理論（AESやRSA）がどれほど強力で素晴らしいものだったとしても、その「入り口の鍵」を自分から道端に落としていては、セキュリティの強さも意味がなくなってしまうのです。

—

2. コミット前に泥棒の侵入を防ぐ！「git-secrets」と「TruffleHog」

「じゃあ、うっかり書いてしまわないようにどうすればいいの？」と思いますよね。
人間は誰しもミスをする生き物です。だからこそ、「人間のうっかりミスを、道具の力で強制的にストップする仕組み」を導入しましょう。

ここで登場するのが、コミット前（変更を記録する前）にシークレットを検知してくれるツールです。

git-secretsで「鍵の持ち出し」を水際でブロック

git-secretsは、Amazon Web Services（AWS）などが提供している、うっかり機密情報をGitに記録（コミット）しようとした時に、「ちょっと待った！」と強制終了させてくれる番犬のようなツールです。

例えば、手元のパソコンで以下のように設定しておきます。

# git-secretsをインストールして、自分のプロジェクトに組み込みます
git secrets --install

# AWSのアクセスキーのようなパターンを検知するように登録します
git secrets --register-aws

これをしておくと、もしあなたが間違えてコード内に本番用のAWSキーを書いてしまい、それを保存しようと git commit を実行した時、以下のようにエラーが出てブロックしてくれます。

> error: Instructions: … Prohibited pattern detected
> 「おいおい！そこに書いてある文字列、秘密の鍵っぽいですけど本当にコミットして大丈夫ですか？」

これで、リモートのサーバーに危険なコードが送信されるのを未然に防ぐことができます。

TruffleHogで過去の履歴まで徹底的にチェック

もう一つの強力なツールが TruffleHog です。これは、すでに書き込まれてしまったコードや、過去の変更履歴（コミットログ）の隅々まで探し回って、隠されたシークレットを見つけ出す探偵のようなツールです。

# TruffleHogを使って、現在のディレクトリの履歴をスキャンする
trufflehog filesystem --no-update .

「昔のバージョンに、テスト用のパスワードが残っていた！」なんていう見落としも、これを使えば根こそぎ発見してクリーンにすることができます。

—

3. コードに書かない！「AWS Secrets Manager」による動的シークレット管理

さて、コードの中にパスワードを書かないとなると、次は「じゃあ、プログラムはどこからパスワードを持ってきたらいいの？」という疑問が湧きますよね。

ここで登場するのが、「動的シークレット管理（AWS Secrets Managerなど）」というアプローチです。

これは例えるなら、「自分の財布の中に常に大金（パスワード）を入れて持ち歩くのではなく、必要な時に信頼できる銀行の金庫から、一時的な引き換え券を発行してもらう仕組み」です。

IaC（Infrastructure as Code）でのスマートな実現方法

私たちが普段使っているTerraformなどのIaCツールを使うと、インフラの構築と同時に、安全なシークレットの管理もコード化して自動で行うことができます。

実際のTerraformの設定例を見てみましょう。小難しいように見えるかもしれませんが、日本語のコメントを読めば「何をやっているのか」がスーッと理解できるはずです。

# 1. AWS Secrets Managerの中に、安全に保管する「秘密の箱」を作ります
resource "aws_secretsmanager_secret" "db_password" {
  name         = "production/database/password"
  description = "本番データベースの管理者パスワード（絶対にコードに直書きしない！）"
}

# 2. その箱の中に、実際のパスワードの値を格納します
resource "aws_secretsmanager_secret_version" "db_password_val" {
  secret_id     = aws_secretsmanager_secret.db_password.id
  secret_string = "SuperSecretPassword123!" # ここは後からマネジメント画面で非公開にすることも可能です
}

# 3. アプリケーション（LambdaやECSなど）には、「パスワードそのもの」ではなく、
#    「あの箱からパスワードを取り出す権限」だけを渡します。

アプリケーション側は、起動した時にこの AWS Secrets Manager にこっそりアクセスし、「今のパスワードを教えて！」と尋ねて、メモリ上に一時的に保持します。これなら、万が一ソースコードが外部に漏れてしまっても、肝心のパスワード自体はコードのどこにも書かれていないため安全です。

さらに、定期的にパスワードを自動で変更（ローテーション）する設定も組み合わせれば、仮にどこかで漏洩したとしても、被害を最小限に食い止めることができます。

—

まとめ：一歩ずつ、安全な開発の習慣を作ろうい

今回は、IaCにおけるシークレットのハードコードを防ぐ方法について、身近な例えを交えながら解説しました。

1. ソースコードへのハードコードは、家の鍵をドアマットの下に置くようなもの！絶対にやめよう。
2. git-secrets や TruffleHog などのツールを導入して、うっかりミスを水際でブロックしよう。
3. パスワードはコードに書かず、AWS Secrets Manager などの安全な金庫に預けて動的に取得しよう。

セキュリティ対策の基本は、「人を信じすぎず、仕組みでカバーする」ことです。最初は覚えることが多くて大変に感じるかもしれませんが、一つずつ自分の環境に取り入れていくことで、あなたの作るシステムは劇的に強固なものになります。

焦らず、一歩ずつ安全な開発の習慣を身につけていきましょうね！応援しています！