「鍵」をリポジトリに入れた瞬間にゲームオーバー。GitLabの「Secret Detection」で未然に防ぐ最強の防御術
こんにちは。現場で数々の「ヒヤリハット」や「情報流出」の現場を見てきたエンジニアとして、今日は一つ、皆さんのエンジニアライフを劇的に守るための話をします。
「あ、間違えて本番環境のAWSアクセスキーをコミットしてしまった……」
これ、誰しも一度は冷や汗をかく瞬間ですよね。これに気づいた瞬間、あなたは「即座にキーを無効化し、ローテーションし、GitHub/GitLabの履歴を抹消し、関係各所に謝罪する」という、生産性ゼロの地獄の作業を強いられます。
今日解説するのは、「後始末」をする必要がない世界の作り方です。GitLabの「Secret Detection」をサーバーサイドで強制的に機能させ、機密情報の混入をプッシュ段階で完全にブロックする方法を伝授します。
—
1. なぜ「パイプライン」ではなく「プッシュ」なのか？
多くのエンジニアがCI/CDパイプライン上でスキャンを行いますが、これは「漏洩した後の検知」に過ぎません。すでに履歴に残ってしまえば、Gitの仕組み上、その痕跡を消すのは非常に骨が折れます。
私たちが目指すのは「そもそもリポジトリに入れない」こと。GitLabのサーバーサイドでプッシュを拒否すれば、機密情報は開発者のローカルPCから一歩も外に出ません。これこそが、コストゼロの最強の防御策です。
—
2. 準備：GitLabでSecret Detectionを有効化する
まずは基本のセットアップです。GitLabには標準で強力なスキャナーが備わっています。
1. プロジェクトの設定を開く:
GitLabプロジェクトのサイドバーから `Settings` > `Security & Compliance` > `Policies` を選択します。
2. スキャンポリシーの作成:
「Scan execution policy」を追加し、`Secret Detection` を有効にします。
これで、GitLabは自動的にコミットされたファイルの中身を監視し、AWSキー、秘密鍵、DBパスワードのような「怪しい文字列」を検知する準備を整えます。
—
3. 実践：プッシュを強制的に拒否する「Push Rules」
ここからが本題です。検知するだけではなく、「拒否」させます。
1. Push Rulesの設定:
`Settings` > `Repository` > `Push rules` に移動します。
2. 「Prevent secrets from being pushed」を有効化:
これにチェックを入れるだけで、GitLabが認識している機密情報パターンと合致するコードのプッシュを、サーバー側で即座に拒絶（Reject）します。
ここがプロのこだわり：カスタムパターンの追加
GitLab標準の検知だけでは不安な場合、`Custom regex patterns` を活用しましょう。例えば、社内独自のAPIキーの命名規則があるなら、以下のように正規表現を登録します。
例：社内APIキーの命名規則（ACME-で始まる32文字の英数字）
/ACME-[a-zA-Z0-9]{32}/
これを設定しておけば、開発者がうっかりキーを貼り付けて `git push` した瞬間、ターミナルに以下のようなエラーが返ってきます。
> Remote: [REJECTED] The push contains sensitive information. Please remove it and try again.
サーバー側で弾くため、リモートリポジトリの履歴は一切汚れません。これが「安心」の正体です。
—
4. Hello World的な動作確認：あえて「失敗」してみる
設定が正しく効いているか、必ず自分の手で確認してください。これが最も重要なプロセスです。
1. テストファイルを作成:
ローカルで `test-secret.txt` を作成し、わざとAWSのアクセスキーのような形式の文字列を書き込みます。
# わざと偽のAWSキーを書いてみる
AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
2. コミットしてプッシュ:
git add test-secret.txt
git commit -m “Test: secret detection”
git push origin main
3. 結果の確認:
GitLabが「拒否しました」と答えてくれれば成功です。これで、あなたのチームは「秘密鍵の流出」というリスクから完全に解放されました。
—
現場の知見：成功のためのアドバイス
最後に、これを導入する際の「先輩からのアドバイス」を一つ。
この設定をいきなり導入すると、既存の開発者は「プッシュできない！」とパニックになるかもしれません。まずは「警告モード」で運用を開始し、チームに周知してから「拒否モード」に切り替えるのが、円滑な組織運用の秘訣です。
「仕組みで防ぐ」ことは、個人の注意力に頼るよりも100倍効率的です。人間は必ずミスをします。でも、GitLabは決してミスをしません。
さあ、今すぐプロジェクトのPush Rulesを開いて、セキュリティの「要塞」を築いてしまいましょう。これだけで、毎日の開発が劇的にストレスフリーになりますよ。
—
何か設定で詰まったら、いつでも聞いてください。DevOpsの深淵はまだまだ奥が深いですよ。