インフラポリシーが邪魔をするとき：セキュリティを損なわずに例外を処理する方法

何週間もかけてインフラポリシーを練り上げてきたとしよう。すべてのリソースは命名規則に従い、承認済みのインスタンスタイプを使用し、特定のポートを公開してはならない。パイプラインはこれらのルールを自動的に強制する。すべてがクリーンで、制御され、安全だ。

そこに、あるチームが3つのポリシーを同時に破るリクエストを持ってくる。コスト面で通常は禁止されている大容量メモリインスタンスが必要だ。本番環境でしか再現しない問題のため、一時的にデバッグポートを開放したい。そして、移行中のレガシーシステムの都合で、命名規則に違反するリソース名を使わざるを得ない。

さて、どうする？

硬直したポリシーの問題

「ポリシーはポリシー、例外は認めない」という答えでは、失敗への道を歩んでいるようなものだ。チームは回避策を見つける。こっそりポリシーを変更したり、パイプラインの外でリソースを作成したり、単にルールを無視したりする。人々が硬直したルールと戦うよりも、システムを回避する方を好むようになれば、ポリシーは無意味になる。

目標はポリシーを排除することではない。人々が迂回せざるを得ないと感じない程度に、ポリシーを柔軟にすることだ。全員の説明責任を果たす、明確な例外メカニズムが必要である。

すべての例外に必要な3つの要素

適切に設計された例外システムには、譲れない3つの要素がある。ログ記録、承認、そして有効期限だ。

ログ記録

すべての例外は記録されなければならない。誰がリクエストしたか、どのポリシーが迂回されたか、影響を受けたリソースは何か、なぜ例外が必要だったか、誰が承認したか。この情報は決して消えてはならない。監査証跡、事後分析、そしてチームが通常のルールの外で運用しているという穏やかなリマインダーとして、複数の目的に役立つ。

ログ記録がなければ、例外は目に見えない技術的負債となる。いくつの例外が存在するのか、誰が許可したのか、まだ必要かどうかもわからない。

承認

例外をリクエストした本人が自分で承認することはできない。他の誰か、理想的にはポリシーが軽減しようとしているリスクを理解している人物が承認しなければならない。セキュリティに関わる例外ならセキュリティチームが、コストに影響するなら財務部門またはエンジニアリングマネージャーが承認する。

この承認は、パイプラインに直接ゲートとして統合できる。承認者が例外リクエストをレビューして承認するまで、パイプラインは一時停止する。承認がなければ、デプロイは行われない。

有効期限

例外は決して恒久的であってはならない。すべての例外には期限が必要で、通常は7日から30日が適切だ。期限が切れると、ポリシーが自動的に再適用される。違反しているリソースは修正されるか、削除されなければならない。それでも例外が必要な場合、チームは更新された理由とともに新しいリクエストを提出しなければならない。

このメカニズムは、例外が新たな標準になるのを防ぐ。チームに、根本的な問題を修正するか、ポリシーを変更する必要がある理由を正当化するよう強制する。

例外フローの設計

例外プロセスは、多少不便であるべきだ。罰するためではなく、チームが本当に例外を必要としていることを確実にするためだ。簡単すぎると、誰もがポリシーに従う代わりに例外を使うようになる。難しすぎると、人々は抜け穴を探す。適切なバランスはその中間にある。二度考えさせるほど面倒だが、正当な作業を妨げるほど苦痛ではない程度だ。

実際のフローは次のようになる。

次の図は例外リクエストプロセスを示している。

flowchart TD A[パイプラインがポリシー違反を検出] --> B{アクションを選択} B -->|キャンセル| C[変更をブロック] B -->|例外をリクエスト| D[例外リクエストを送信] D --> E[リクエスト詳細を記録] E --> F[承認者に通知] F --> G{承認されたか？} G -->|いいえ| H[変更をブロック] G -->|はい| I[パイプラインが例外ステータスで続行] I --> J[有効期限を設定] J --> K[期限前にリマインダーを送信] K --> L{期限切れか？} L -->|いいえ| M[リソースは例外状態] L -->|はい| N[ポリシーチェックを再実行] N --> O{準拠しているか？} O -->|はい| P[例外クローズ] O -->|いいえ| Q[ポリシーを強制/リソースを修正]
  1. パイプラインは、planまたはapplyの際にポリシーチェックを実行する。
  2. 違反が検出される。パイプラインは2つのオプションを提示する。変更をキャンセルするか、例外リクエストを送信するか。
  3. チームが例外を送信すると、パイプラインは承認者向けのチケットまたは通知を作成する。
  4. 承認されると、パイプラインは続行するが、リソースを例外ステータスとしてマークする。
  5. システムは例外の期限が切れる前にリマインダーを送信する。期限切れ後、自動的にポリシーチェックを再実行する。

やってはいけないこと

有効期限や承認なしに例外を作成してはならない。それはポリシーがまったくないのと同じだ。期限が切れない例外は、単に静かに書き換えられたポリシーに過ぎない。

また、例外をポリシー改善の言い訳にしてはいけない。同じタイプの例外が繰り返し発生する場合、ポリシーが厳しすぎる可能性がある。新しいリソースカテゴリが必要かもしれないし、元のルールがもはや意味をなさないかもしれない。頻繁な例外は、ポリシーに回避策ではなく評価が必要であるというシグナルだ。

例外処理の実践的チェックリスト

  • すべての例外は、リクエスタ、迂回されたポリシー、影響を受けるリソース、理由、承認者とともに記録される
  • 例外は、ポリシーのリスクを理解している人物からの承認を必要とする
  • すべての例外に明示的な有効期限がある（7〜30日を推奨）
  • パイプラインは例外が承認されるまでデプロイをブロックする
  • 例外の期限前に自動リマインダーが送信される
  • 期限切れの例外は自動ポリシー再チェックをトリガーする
  • 例外の頻度は四半期ごとにレビューされ、ポリシー改善点を特定する

まとめ

例外メカニズムのないポリシーは、シャドウシステムを生み出す。チームはそれを回避し、インフラで実際に何が実行されているかの可視性を失う。適切に設計された例外フローはポリシーを弱体化させない。人々が実際に従う現実的なものにすることで、ポリシーを強化する。鍵となるのはログ記録、承認、有効期限だ。この3つがすべて揃っていなければ、それは例外プロセスではない。すでに壊れたポリシーだ。