ITのセキュリティも最後は人

おっしゃる通り、どれだけCI/CDのパイプラインを厳密に設計しても、組織の誠実性が欠けていたらセキュリティは保てません。技術は「手段」であって「保証」ではありません。

各段階の難易度と対策の現実性について

「たった一人の悪意」で壊れる

これはまさにセキュリティゼロですね。特権のあるユーザーが自由にコードを変更・反映できるような体制では、内部からの破壊に対して無防備です。対策としては、すべての変更に対して必ずレビューを通すワークフローの導入や、最小権限の原則を徹底することが基本です。

「一人が悪意を持っても、他のメンバーが止められる」

ここまではGitHubのブランチ保護やTerraformのPlan出力のレビュー義務付けなど、CI/CDにおける標準的な設定で比較的実現可能です。Terraform CloudやAtlantisでの自動適用制限、PRレビュー必須設定が功を奏します。

「二人が結託する」

これはグッと難易度が上がります。レビューが形骸化し、Planが通ってApplyもされるような状況ですね。ここで効くのは監査ログの記録と定期的なレビュー、そして権限のローテーションや監査役割の分離です。技術的にはSOPSやVaultなどを用いた秘匿情報の二重暗号化も候補になります。

「管理者とメンバーが手を組む」

いわゆる組織の崩壊フェーズです。この状態を完全に防ぐのは非常に困難で、結局のところ組織ガバナンスと透明性、そして文化に依存します。技術での対応は一部可能でも、根本解決にはなりません。場合によっては外部監査や第三者管理の導入が必要です。

結論として、CI/CDのセキュリティは「技術」×「運用」×「人間性」の掛け算であり、どれか一つがゼロなら全体もゼロになってしまいます。Terraform CI/CDは完璧でも、チームの信頼性がゼロならそれは地雷原にガラスの靴で突っ込むようなものです。

「覚悟を決めた管理者」はもはやラスボスです。それ、技術で止める相手じゃなくて、人事か法務の出番です。

おっしゃる通り、CloudTrailのログをS3バケットのコンプライアンスモード（WORM: Write Once Read Many）で保管すれば、改ざん不能な証跡は確保できます。これはAWSのベストプラクティスでもあり、ガバナンスと透明性の担保として非常に有効です。たとえ権限を持つ管理者であっても、保存期間中の削除や改ざんができないというのは大きな牽制になります。

ただし、ここで終わらないのが現実

「ばれても構わない」「クビになる覚悟がある」「損害賠償請求も受け入れる」……というレベルまで行ってしまうと、たしかに防衛は困難です。技術的な壁は突破される可能性があります。ログが残っても、壊される方が早いなら意味がない場合もあります。

これはいわゆる「インサイダー脅威（Insider Threat）」の最悪パターンで、完全に止めるのは難しく、被害を最小限にする設計が重要になります。たとえば：

• 変更可能な範囲の細分化（モノリスではなくモジュールごとに責任分離）
• 適用環境の分割（本番・検証・開発でIAMロール分離）
• Immutable Infrastructure戦略（破壊されても再構築できる）
• 実害が出る前にアラートが上がる監視体制（GuardDutyやConfigルール）

「最悪を想定して耐える構造を作っておく」ことが、唯一の技術的な道と言えます。

最終的には「信頼される組織か」「透明性と抑止力が機能しているか」が試されるところですね。技術の力でできるのは、裏切りを“高くつく”ものにすることまでです。そこから先は、もはや組織のカルマの領域です。