DevOps 文化におけるコンプライアンス

いつ使用するのか

測定対象のプロパティ数が少なく、リリース頻度が低く、レスポンスがシンプルな場合、このプロセスはシンプルで容易になります。小規模なコンプライアンスプロセスにこのプロセスを実装するには、多大なリソースや時間を投資する必要はありません。チームが記入して提出するGoogleフォームを作成するくらい簡単な場合もあります。通常、このタイプの導入には、レビュー会議に関連付けられた正式な承認として実装されることが多い手動レビュープロセスも含まれます。

組織がスケールアップするにつれて、このプロセスは非常に迅速に困難なものになる可能性があります。規模の拡大により、ワークロードと複雑性の増加を原因とする複数の側面に現れる課題が生じます。

組織の規模拡大に伴うワークロードの増加により、キャパシティの課題が生じます。組織が成長するにつれて、コンプライアンス承認の追加要求を処理するために、コンプライアンスプロセスの運用能力も比例して成長する必要があります。展開承認要求のランダムな性質により、中央コンプライアンスチームへのワークフローは非常に変動するため、迅速な対応のために中央チームの規模を決定することはコストがかかります。組織が成長するにつれて、この問題は拡大します。

組織がスケールアップするにつれて、複雑性の課題が生じ、新しくエキサイティングな障害モードが発生し、それがコンプライアンスプロセスの変更を促進します。コンプライアンスフォームはサイズと複雑さが増し、開発チームとコンプライアンスチームの両方にとってプロセスを完了するのにより多くの時間と労力を必要とします。

コンプライアンスプロセスが規模に対して非効率性を示し、開発チームがビジネス価値を迅速に提供できる速度を制限要因になり始めると、二次的な影響が現れる可能性があります。

チームは、リリースされる価値を開発するための作業が、それらの変更を本番環境に展開するために必要な総コストのかなりの部分を占めるような方法で、展開における変更をバッチ処理することにより、コスト効率に焦点を当てる場合があります。

コンプライアンスプロセスのリードタイムは、バッチサイズも決定します。コンプライアンス部門の作業能力の制限により、特定の期間に処理できる展開要求の数の上限が決まるからです。展開数が制限されている場合、顧客に提供される価値を増やす唯一の方法は、バッチサイズを増やすことです。

コンプライアンス部門が（何らかの理由で）過負荷になると、コンプライアンスの結果を待っているチームのキューが増加します。コンプライアンスプロセス自体が、価値提供を制限するボトルネックになります。多くの場合、デリバリーのプレッシャーがコンプライアンスプロセスを圧倒し、開発チームはコンプライアンスプロセスを積極的に悪用、迂回、または回避し、「シャドーIT」、妥協された設計とアーキテクチャの決定、さらにはコンプライアンスレスポンスの改ざんを引き起こします。

私たちは、商業および政府の両方の分野の組織内でこれらのすべての行動を見てきました。新しいサービスまたはシステムを本番環境に展開する前に、現実的に6〜9か月かかる手動コンプライアンスプロセスを見てきました。別のクライアントでは、彼らのプロセスが組織が提供できる速度と規模を制限するだけでなく、その適用と結果に非常に矛盾があることを示すことができました。

残念な現実として、私たちの経験では、手動コンプライアンスプロセスは、システムの安全性とセキュリティを大幅に向上させることなく、価値の提供を遅らせる「セキュリティシアター」の一種であることを示しています。また、これらのプロセスはデリバリープロセスをはるかに超えて不均衡な影響を与え、組織構造、アーキテクチャの決定、ドメイン境界、さらには人員配置と人材定着に影響を与えることも見てきました。

いつ使用するのか

明らかに、コンプライアンステストの自動化は、コンプライアンス部門とチームの開発者の両方にとって大きなメリットです。

コンプライアンス部門は、適切なコンプライアンス適合性関数が実行されていることを保証でき、パイプラインログは適合性関数の実行と結果を記録する監査証跡を提供できます。チームは、パイプラインに必要なことを確実に実行することにより、個々の変更をゲートキーピングするのではなく、ビジネス価値の提供に集中できます。

チームの開発者は、システムリリースがコンプライアンス要件を満たしているかどうか（少なくとも適合性関数として自動化されている要件については）に関して、はるかに迅速なフィードバックを得ることができます。パイプラインの失敗は、コンプライアンスを満たしていないことを示しているためです。

すべてのチームが同じスタックを使用し、ほぼ同じタイプのシステム（RESTサービスなど）を構築している同種の開発環境では、チームは標準パイプラインをコピーすることにより効率の向上を実現できます。少なくとも、同じコンプライアンス適合性関数を共有することで、同種の環境で規模の経済効果が得られます。

本番環境での失敗に対する一般的な組織の対応は、展開プロセスに手動検証手順を追加することです。「すべての作業が完了し、ロールバック計画が存在する」という適合性関数を定義し、チームマネージャーとセキュリティ担当者の両方によって手動で検証する必要がある場合があります。これは、システムに対して名目上責任を負っているが、実際には責任を負っていない（つまり、変更に精通していない）役割の作業キューが発生するため、理想的ではありません。[2] その結果、追加の遅延が発生しますが、システムのセキュリティや安定性は見事に改善されません。

もう1つの一般的な対応は、コンプライアンスを保証するためにパイプラインをロックダウンすることです。これは、本番環境で何らかの失敗が発生し、おそらくチーム固有の標準パイプラインからの逸脱にまでさかのぼることができる場合に発生する可能性があります。組織は、すべてのチームのシステムリリースを同じ「ゴールデン」パイプラインに送ることを意図して、パイプラインコンプライアンスプロセスの責任を1つの中央チームに移行します。

私たちの経験では、チームのパイプライン内の変更頻度が高いことから、パイプラインの中央管理は、開発プロセスの最大の摩擦源の1つです。この中央管理により、中央チームがチームのシステムを進化させる能力を制限するボトルネックになっているため、開発全体が遅くなります。

二次的な影響は、手動ソリューションと同様です。「シャドーIT」、妥協された設計とアーキテクチャの決定、または更新されたコンプライアンスパイプラインなしでの本番環境への展開です。

リリースを遅らせるという明確な目的で、このような中央「所有権」の決定が行われている事例を認識しています。公開されることはほとんどありませんが、組織は、より頻繁なリリースは、その開発プロセスの体系的な未熟さをしばしば明らかにすることを認識しています。中央制御への移行は、多くの場合、エンジニアリングおよび開発チームからコンプライアンス組織へのデリバリー品質の責任を移行しようとする試みです。

時間の経過とともに生じる摩擦のレベルは、軽視することはできません。パイプラインが存在する主な理由は、ソフトウェア開発プロセスの中央ツールを提供することです。それが横断的な目標のために乗っ取られ、制御されると、開発者の懸念事項は、パイプラインチーム（多くの場合、DevOpsチーム）のスタッフ、組織、インセンティブ、運用方法に基づいて、優先順位が低下する傾向があります。

いつ使用するのか

構築ブロックの機能範囲内で要件を満たすチームにとって、これは優れたソリューションです。「ゴールデンイメージ」は、チームが別途実装する必要のあるビジネスまたは技術機能を表し、これらのイメージは既にコンプライアンス要件を満たしています。例えば、ゴールデンPostgreSQLイメージに依存することで、チームはバックアップ/リストア、データベースチューニング、デプロイ、ロギング、運用上の考慮事項について考える必要がなくなります。それらすべてのアクティビティは、コンプライアンスに合格したPostgreSQL構築ブロックの一部として既に完了しています。

成熟した構築ブロックのコレクション、均質な開発環境、そしてばらつきの少ないビジネスニーズが与えられた場合、これは多くの開発チーム間での重複作業を回避することで、効率性の向上をもたらす可能性があります。

コンポーネント構成戦略に関連する摩擦は、これらの基本的な前提と制約が侵害された場合に発生します。既存の「ゴールデンイメージ」の範囲外の機能を必要とする製品開発では、開発チームがシステムのこれらの「非ゴールデン」コンポーネントについても、同じ煩雑なコンプライアンスプロセスを経る必要があります。そのため、一部のチームは相当なスケジュールリスクを認識し、システムのアーキテクチャと設計に不当な影響を与える可能性があります。

さらに、これは滑りやすい坂道です。その底では、組織は各チームが独自の特殊なソリューションのコンプライアンスを管理しているため、何ら改善されていません。コンプライアンスに合格したイメージをカスタマイズの基礎として使用することで、コンプライアンスの努力を漸進的な変更に限定できると主張する人もいるかもしれません。しかし、これらの共有された「ベースライン」イメージによるチーム間の結合は増加します。コンプライアンスの単位は依然としてイメージ全体であるため、時間の経過に伴うコンプライアンスの限界費用は、思っているよりも大きくなる可能性があります。

コンプライアンスに合格したイメージを提供する責任を中央チームに移行することには、パイプラインが集中化されている場合と同様に、上記で述べたすべての特性があります。

コンポーネント構成ソリューションは、規模が大きくなると非効率性を示し始め、開発チームがビジネス価値を提供する速度を制限する要因になり始めます。二次的な影響は、手動およびパイプラインベースのソリューションと同様です。「シャドーIT」、妥協された設計およびアーキテクチャ上の決定、またはコンプライアンス要件に合格していないコンポーネントの運用環境へのデプロイなどです。

このパターンに従うシステムでは、組織の規模に応じて異なる動作が観察されています。小規模の場合、またはこのパターンの実装の初期段階では、同様のニーズを持つチームを見つけることが容易であり、コンプライアンスに合格した構築ブロックに依存することによる経済効果は明らかであり、チームの加速に役立ちます。しかし、ある規模を超えると、提供されるソリューションのニーズは分散し、チームがコンプライアンスに合格した構築ブロックに依存できない場合に、同様の摩擦源が発生します。

注記：コンプライアンスが、コンプライアンスに合格したコンテナイメージのセットに対して実際に構成に対して分配可能かどうかという問題については、故意に回避しています。それが真実であると仮定すると、それはカスタマイズがゼロの正確なコンテナイメージに対してのみ真実であり、それは結果としてソリューション空間を非常に制限し、実際には何の効用も提供しない可能性があります。ユースケースに関連して、構成可能なコンプライアンスの範囲内でどのような種類の構成可能性が達成可能かをよく検討することをお勧めします。

いつ使用するのか

このソリューションは、前に説明したソリューションに存在するボトルネックを最小限に抑えるのに役立ちます。上記で説明したソリューションと比較して本質的に複雑であるため、組織の規模がこの方法で解決できるタイプのボトルネックを作成する環境に限定される可能性があります。

コンプライアンスの懸念事項を分離することにより、中央で管理されるコンプライアンス方法論に関連する摩擦を回避するために必要な疎結合を実現できます。チームは、中央で提供される一連のパイプラインコントロールを採用しながら、チームが持つ可能性のある独自の要件を効率的に自己管理することもできます。

コンプライアンスの制約が頻繁に変更される場合、組織は既存のシステムへの影響を効率的に判断し、計画の努力を削減し、実装プロセスを簡素化できます。Policy-as-Codeの原則により、測定テストを適用することで証拠を収集するプロセスに変更がないため、チームに追加の作業が回避されます。

コンプライアンスプロセスのすべての入力はデータと構成に基づいているため、監査プロセスは大幅に簡素化されます。任意の時点で、証拠のセットと検証プロセスの結果は、SoRを照会することで取得できます。

上記のように、このソリューションは懸念事項の分離のためにやや複雑です。ただし、複雑さは組織全体のすべての開発チームに委任されるのではなく、コンプライアンスオフィス内に適切に存在します。

プロセスに対する信頼の問題は、SoRおよび関連する秘密鍵管理の一部として明示的に対処する必要があり、これはコンプライアンスオフィスによって管理する必要があります。新しい測定テストの承認プロセスには既知のボトルネックがありますが、個々の作業項目（つまり、測定テストの適合性に関する合意）が大幅に小さいため、これらのボトルネックの範囲はより限定的であり、チームの開発を大幅に妨げることはありません。

「シャドーIT」やコンプライアンス要件に合格していないコンポーネントの運用環境へのデプロイのリスクはまだあります。ただし、設計とアーキテクチャの決定が妥協されるリスクは大幅に軽減されます。

私たちは長年にわたって複数のクライアントでこのパターンを実装してきました。ある大企業組織では、デプロイメント要件、セキュリティ、および証明書への準拠を確保し、CVEスキャンされたコンテナを提供する信頼できるコンテナレジストリを使用し、適切なドキュメントの存在を確認（または作成）するカスタムアドミッションコントローラーを実装しました。別の組織では、デプロイメント前にKubernetes構成でCISベンチマークテストを実行するPolicy-as-Codeソリューションを統合することに加えて、同様の機能を実装しました。