午前I問題
バージョン管理システムGitの特性に関する記述のうち、最も適切なものはどれか。
ア）コミット履歴から特定のファイルをgit rmで削除しコミットすれば、そのファイルの過去の内容は履歴から完全に消去される。
イ）Gitはスナップショットベースでコミットを管理しており、一度コミットされた内容は、後から履歴を書き換えない限りリポジトリのオブジェクトとして残り続ける。
ウ）ブランチを削除すると、そのブランチに含まれていたコミットオブジェクトは即座にリポジトリから完全に削除される。
エ）非公開（プライベート）リポジトリにコミットされた情報は、外部のCI/CDサービスと連携しても外部に送信されることはない。
午前I の解答・解説を見る
正解： イ）
解説：
- ア）不正解。
git rmでファイルを削除してコミットしても、それは新しいコミットが作られるだけであり、過去のコミット履歴（オブジェクト）には元のファイル内容がそのまま残る。完全に消去するにはgit filter-repo等による履歴の書き換えとリモートへの強制反映、既存クローンの破棄などが必要。 - イ）正解。Gitはファイルの差分ではなくスナップショット単位でコミットを管理する。一度コミットされたオブジェクトはGitの内部データベースに保持され、履歴の書き換え（rebase・filter-repoなど）と参照の削除、ガベージコレクションを経なければ残存し続ける。
- ウ）不正解。ブランチを削除してもコミットオブジェクト自体はreflogなどから一定期間参照可能であり、即座に完全削除されるわけではない。実際に不要オブジェクトが削除されるのはgcが実行された後である。
- エ）不正解。プライベートリポジトリであっても、CI/CDサービスとの連携やWebhook、サードパーティ製ツールとの統合によりコードやコミット内容が外部システムに送信されるケースがあり、機密情報の混入はリスクとなる。
午前II問題
GitOpsを用いたインフラ・アプリケーションのデプロイ運用において、シークレット（APIキー・パスワード・証明書等）の管理方法として最も適切なものはどれか。
ア）シークレットをKubernetesのマニフェストファイルにBase64エンコードした状態で記述し、そのままGitリポジトリにコミットして管理する。
イ）Sealed SecretsやExternal Secrets Operatorなどの仕組みを用い、暗号化されたシークレットまたはシークレット管理サービスへの参照のみをGitリポジトリで管理する。
ウ）シークレットはリポジトリの.gitignoreに対象ファイルを指定するだけで十分に保護されるため、追加の暗号化やアクセス制御は不要である。
エ）シークレットの漏洩を防ぐため、リポジトリを非公開にし、CIツールのシークレットスキャン機能は運用が煩雑になるので無効化しておく。
午前II の解答・解説を見る
正解： イ）
解説：
- ア）不正解。Base64はエンコード方式であり暗号化ではないため、誰でも容易にデコードして元の値を復元できる。平文同然の状態でGit履歴に永続的に残ることになり、重大なリスクとなる。
- イ）正解。Sealed Secretsは公開鍵でシークレットを暗号化しリポジトリにコミット可能な状態にし、クラスタ内のコントローラのみが秘密鍵で復号する仕組み。External Secrets Operatorは外部のシークレット管理サービス（Vault・AWS Secrets Manager等）からシークレットを取得し、Git上には参照情報のみを置く。いずれもGitリポジトリに平文シークレットを残さないGitOpsのベストプラクティスである。
- ウ）不正解。
.gitignoreは今後の追跡対象からファイルを除外する設定にすぎず、すでに履歴にコミットされたファイルには効果がない。また誤ってコミットされることを技術的に防ぐものでもなく、追加の暗号化やスキャンによる補完が必要である。 - エ）不正解。非公開リポジトリであっても内部者や連携先からの漏洩リスクは残る。シークレットスキャン（例：git-secrets, TruffleHog, GitHub Secret Scanning）はコミット前・プッシュ後に機密情報の混入を自動検知する重要な多層防御であり、運用の煩雑さを理由に無効化すべきではない。
午後問題
金融系システムを開発するD社では、GitOpsを用いてKubernetesクラスタへのデプロイを行っている。ある日、開発者がデータベース接続用のパスワードを含むYAMLファイルを誤ってパブリックリポジトリにプッシュしてしまうインシデントが発生した。プッシュから発覚までに約40分が経過しており、その間に第三者によるクローンが疑われる状況であった。
調査の結果、次の状況が判明した。
- 当該パスワードは本番データベースの管理者アカウントのものであり、ローテーションされていなかった
- リポジトリにはCIのシークレットスキャン機能が設定されていたが、検知ルールが古い正規表現パターンのままで、当該パスワード形式を検知できなかった
- インシデント対応手順書は存在したが、「Gitリポジトリへのシークレット混入」というケースは想定されておらず、対応が後手に回った
設問1
このインシデントに対して、発覚後直ちに実施すべき初動対応を2つ挙げよ。
設問1の解答・解説を見る
正解例：
- 漏洩した本番データベース管理者アカウントのパスワードを直ちに無効化し、新しいパスワードにローテーションする（あわせて不正アクセスの形跡がないかログを確認する）。
- リポジトリを一時的に非公開化する、またはプッシュされたコミットを削除・履歴書き換え（
git filter-repo等）し、既にクローンされたキャッシュの影響を最小化する対応を行う（GitHub等のサポートへ削除依頼を出すことも含む）。
解説・採点基準（計15点）：
| 採点項目 | キーワード | 配点 |
|---|---|---|
| 漏洩した認証情報の無効化・ローテーションに言及 | パスワード変更・失効 | 5点 |
| 不正アクセスの有無をログ等で確認する点に言及 | アクセスログ調査 | 3点 |
| リポジトリの非公開化・履歴削除等の封じ込めに言及 | 履歴書き換え・非公開化 | 5点 |
| 対応の優先順位（まず認証情報の無効化）が適切であることに言及 | 初動優先度 | 2点 |
「Git履歴の削除だけ行い、パスワードのローテーションを行わない」という回答は、既に第三者に取得された可能性があるパスワードそのものが有効なままである点で不十分とし、減点する。
設問2
再発防止のため、CIのシークレットスキャンの仕組みとインシデント対応手順の両面から改善すべき点をそれぞれ述べよ。
設問2の解答・解説を見る
正解例：
- シークレットスキャン：検知ルール（正規表現パターン）を定期的に最新のものへ更新する、または高精度なシークレット検知を継続的にメンテナンスしているOSS・商用ツール（例：TruffleHog, GitHub Advanced Security）に切り替える。さらにコミット前のローカルフック（pre-commit）でもスキャンを行い、プッシュ前の段階で検知できる多層防御にする。
- インシデント対応手順：「Gitリポジトリへの機密情報混入」を明示的なインシデント類型として手順書に追加し、認証情報のローテーション・リポジトリの封じ込め・影響範囲調査・関係者への連絡までの初動フローとエスカレーション先を定義しておく。
解説・採点基準（計15点）：
| 採点項目 | キーワード | 配点 |
|---|---|---|
| 検知ルールの継続的な更新・ツール見直しに言及 | パターン更新・ツール刷新 | 4点 |
| プッシュ前（pre-commit等）での多層的な検知に言及 | ローカルフック・多層防御 | 4点 |
| インシデント類型としての手順書明文化に言及 | 手順書への追加 | 4点 |
| 初動フロー・エスカレーション体制の整備に言及 | 対応フロー・連絡体制 | 3点 |
重要キーワード
| 用語 | 説明 |
|---|---|
| GitOps | Gitリポジトリを単一の信頼できる情報源（Single Source of Truth）とし、インフラ・アプリケーションの状態をGit経由で宣言的に管理・デプロイする運用手法 |
| シークレットスキャン | ソースコードやコミット履歴からAPIキー・パスワード等の機密情報を自動検出する仕組み。pre-commitフックやCIパイプラインに組み込まれる |
| Sealed Secrets | Kubernetes上で公開鍵暗号を用いてシークレットを暗号化し、コントローラのみが復号できる状態でGit管理を可能にする仕組み |
| External Secrets Operator | 外部のシークレット管理サービスからシークレットを取得し、Kubernetesリソースとして同期する仕組み。Git上には参照情報のみを保持する |
| Git履歴の書き換え | git filter-repo等を用いてコミット履歴から機密情報を除去する操作。関係者全員への周知と強制プッシュ・再クローンが必要 |
| シークレットローテーション | 漏洩の有無にかかわらず認証情報を定期的または即時に更新する運用。漏洩時の被害を時間的に限定する効果がある（鍵管理も参照） |
まとめ
- 午前I視点： Gitはスナップショットベースで履歴を保持する仕組みであり、単純な削除コミットでは過去の機密情報は消えないという特性の理解が基礎になる。
- 午前II視点： GitOpsにおけるシークレット管理はBase64のような可逆エンコードでは不十分であり、Sealed SecretsやExternal Secrets Operatorのような暗号化・外部参照方式が適切という点が頻出。
- 午後視点： シークレット混入インシデントは「認証情報の即時無効化・ローテーション」を最優先とし、Git履歴の封じ込めと合わせて対応する。検知ルールの陳腐化と手順書の未整備という組織的な弱点への言及が実務対応力を示す鍵となる。