いまさらセキュリティ #03｜Red Hatコンサル環境のGitLab侵害事件から学ぶ：構成情報と認証情報を分離する重要性

Red Hatのコンサルティング部門で発生したGitLab侵害事件を題材に、同様の被害を防ぐための対策を解説します。

１．事件概要

2025年10月、Red Hatはコンサルティング部門が運用していた自己管理GitLabへの不正アクセスを発表。内部データがコピーされたことを確認しました。犯行側は大容量のデータ流出を主張していますが、製品や署名・配布基盤への影響は確認されていません。

本件の教訓

本件の焦点は、製品の脆弱性ではなく、共同作業で共有された情報（設計、接続先、運用記録、認証情報）が巻き込まれるリスクです。

Red Hatの発表

• Red Hat Consultingの自己管理GitLabが不正アクセスを受け、内部データがコピーされた。

• 製品や署名・配布基盤への影響はない。

• インスタンス隔離、権限見直し、関係当局・関係先への連絡を実施し、調査を継続中。

犯行側の主張（未確定情報を含む）

• 大容量データや顧客関連ドキュメントなどを持ち出したと主張。

• 掲示板などで件名や企業名、主張容量が列挙されているが、真偽や全量は未確認。

重要な注意点

２．原因となった攻撃手段

今回の個別原因は公表待ちですが、自己管理のGit/GitLabや共同作業環境で実際に多いパターンは以下の通りです。

初期侵入

• 漏えいトークン/PATの悪用: リポジトリ、CIログ、Issue、Wikiに消し忘れのトークンが残存し、API経由で悪用される。

• 認証情報の使い回し/フィッシング・リスト攻撃: SSO未導入でID/パスワード単体の運用だと、他サービスからの漏えい情報で突破されやすい。

• 未パッチのGitLab脆弱性/過剰公開: セルフホストの更新遅延や管理UI、Runner登録の外部公開が踏み台化される。

権限昇格・横展開

• Maintainer権限の奪取によるグループ横断: 1つのMaintainer権限を奪われると、他のプロジェクトのCI/CD、変数、Deploy Keyへ波及する。

• CI/CDの環境変数からの再侵入: CIに保存されたクラウド鍵、SSH鍵、DB接続情報が吸い上げられ、本番環境へ横展開される。

情報持ち出し・恐喝

• GitLab APIでの一括ダンプ: Issues、Wiki、Artifacts、Container Registryまで包括的に抜き取られる。

• 構成情報と認証情報の同居が致命的: 設計書、接続先一覧、運用記録（CERなど）と、APIキー、トークン、証明書などの認証情報が同一リポジトリや同一ファイルに共存していると、侵害時の横展開の確率と速度が跳ね上がる。

IPA「10大脅威」との関連

主に「サプライチェーンや委託先を狙った攻撃」（外部侵入が起点）に該当します。現時点では内部不正の示唆はありません。

３．対応策

1週間で出来ること

• 資格情報の強制ローテーション:

  • 対象：クラウドIAMキー、PAT・Deploy Key、VPN・踏み台、DB接続文字列

  • 原則：用途別、環境別、期限付きで再発行。使い回し疑いは全面無効化 → 新規発行。

• 監査ログの遡及調査（30〜90日）:

  • 確認：新規ユーザ作成、キー発行、権限付与、外向き転送、異常なCI実行

  • 発見時：即停止 → 影響範囲の切り分け（どの環境・どのデータまで）

• 公開面の棚卸しと遮断:

  • 外部公開プロジェクト、Container Registryの匿名Pull、Runner登録開放の有無を確認。

  • 管理UIが外部露出していればVPN/ZTNA（ゼロトラスト）で制限。

• SSO+MFAの全アカウント強制:

  • 例外ゼロ。ローカルアカウント廃止、招待・プロジェクト作成の制限、退職・委託終了時の即時失効を運用化。

• Secretsスキャンを"コミット前"に:

  • pre-commitフック+CIでgitleaks/trufflehogなどを常時実行。検出時は自動ローテーションまで連鎖（手作業の待ち時間を排除）。

3.2 数週間で固める（設計・契約・運用）

• 最小権限+JIT（Just-In-Time）:

  • 委託・MSPの恒久的な管理者を廃止。必要時のみ時間制で権限昇格、操作ログは顧客環境で保管。

• 環境分離と観察（ステージング隔離）:

  • 新しいスクリプト/コンテナ/Runnerは隔離環境で挙動観察（新規外部通信、プロセス生成、特権要求）。

• 鍵の寿命を定義（Key Rotation Policy）:

  • 例：本番用PAT禁止、マシンユーザのみ、有効期限 ≤ 30日、用途タグ必須、期限切れ自動失効。

• ドキュメント運用の見直し:

  • 設計書、接続先一覧、運用記録に認証情報を記載しない。構成＝ドキュメント、認証＝Secretストアで物理的・論理的に分離。参照は一時的なリンクを原則に。

• 契約条項の最低ライン（SOW/基本契約の別紙）:

  • 全アカウントMFA必須

  • JIT特権+顧客側で操作監査

  • 秘密情報の自動スキャンと漏えい時の即時ローテ

  • 検知後24h初報・72h暫定評価・7日恒久策の連絡SLA

４．まとめ――構成と認証は同じ場所に置かない

共同作業の場には設計、接続先、運用記録と、鍵、トークン、証明書が溜まりやすいものです。完全に漏えいを防ぐことは難しいですが、以下の4点を習慣化することで、被害を最小限に抑えることができます。

• 構成情報と認証情報を同居させない（分離保管）

• 鍵は短寿命で常時ローテーション

• 権限は必要な時だけ開く（JIT）

• 更新は信頼ではなく検証を通す

これらの対策を講じることで、万が一情報が漏えいした場合でも、横展開される前に対応することが可能になります。