コードとしてのポリシー（PaC）とは。

コンプライアンスの確認やセキュリティー・ルールの記憶を人間に頼るのではなく、これらのルールは実行可能なロジックとして存在し、開発者やシステムが変更や要求を提案するたびに実行されます。誰かが変更を送信すると、ポリシーエンジンはコード化されたルールに照らしてその変更を自動的に評価し、許可、拒否、またはフラグを立てます。

このプロセスにより、ポリシー管理の運用は、静的な文書から、Delivery Pipelineに組み込まれた、継続的に適用されるライブのコントロール・サーフェスへと移行します。

コードベースのルールは、繰り返し可能かつスケーラブルな方法で、同じポリシーをあらゆる場所に適用するのに役立ちます。ポリシー・エンジンは、ビルドまたはデプロイメント中に数秒で自動チェックを実行できるため、フィードバック・サイクルが短縮され、DevOpsチームは後半段階のセキュリティーやコンプライアンスの予期せぬ事態を回避できます。

PaCは、企業がサイバーセキュリティー体制全体を向上させ、業種・業務および規制基準への準拠を維持することを可能にします。さらに、ポリシーをコードのように扱うことは、より広範な「すべてをコードとして扱う」移行と整合しています。これにより、インフラストラクチャーへの要求などを、開発チームが共同作業できるレビュー可能なコード・ファイルに変換します。

DevOpsの用語では、ポリシーとは、ITインフラストラクチャーとアプリケーションをどのように構成、アクセス、または実行すべきかについての、明確で強制力のある規則のことです。より正確に言うと、ポリシーは、システムが理想的な状態で稼働し続けるように、どのようなアクションが許可、要求、または禁止されるかを規定します。

例えば、「すべてのストレージ・バケットは暗号化しなければならない」や「いかなる公共サービスもポート22を公開してはならない」は、システムの動作に対する具体的な制約を定めるポリシーです。

PaCでは、ポリシーが構造化プログラミング言語で書かれているため、ポリシー・エンジンやオートメーション・ツールがそれらを解析・評価することができます。このようにして、ポリシーは、人々が異なる解釈をする可能性のあるガイドラインではなく、システムとエンジニアが満たさなければならない実行可能な保護策となります。

コードとしてのポリシーを扱うツールを使用すると、開発者は実行可能なコードをランタイム環境や継続的統合／継続的デリバリー（CI/CD）パイプラインに書き込むことができ、すべての変更が自動的に準拠しているかどうかチェックされます。

技術的には、ほとんどのPaCセットアップは同じ主要な手順に従います。

• 開発者はコード・ファイルの形でポリシーを作成します。Python、YAML、JavaScript Object Notation（JSON）、オープンソースのポリシー・エンジンであるOpen Policy Agent（OPA）と併用されるRegoなど、高レベルの命令型および宣言型言語を多数使用できます。各ポリシー・ファイルは、考慮するインプット（「resource.kind」、「metadata.labels」、など）と条件（「述語」とも呼ばれます）と結果（許可/拒否、重大度、メッセージ）をエンコードします。

• コードはGitやGitHubなどのバージョン管理システムに送信され、プル・リクエスト、コード・レビュー、厳格な構文テストなど、アプリケーション・コードと同じワークフローを経ます。

• ポリシー・エンジンはコード・ファイルを読み込み、解析して、内部的に理解可能なデータ構造と命令に変換します。これらの構造と命令は、迅速に評価できるように、コンパクトな低レベル命令フォーマット（バイトコード）に変換されます。

• 呼び出し元（ポリシー・エンジンに決定を求めるコードの一部）は、インプットを正規化します。呼び出し側は、HashiCorp Configuration Language（HCL）ファイルや IaC ツールのJSONテンプレート、Kubernetesやクラウド・プラットフォームの YAMLマニフェスト、API 呼び出しによる HTTP 要求、ランタイム環境と本番環境からのアプリケーションデータおよびテレメトリー・データなど、さまざまなインプット形式を処理します。このプロセスでは、未加工のインプットがクリーンアップされ、1つの標準構造に再構築されるため、ポリシーは一貫した方法でインプットを読み取ることができます。

• 呼び出し元は正規化されたデータをポリシーエンジンに返し、エンジンはデータインプットに対してポリシーコードの実行を開始します。

• ポリシーエンジンはルールを順に進め、各ルールの述語を入力と照合してどの述語が適用されるかを確認します。「このルールはこのインプットについて何を意味するのか？」という問いとしてポリシーエンジンを考察することができます。

• ポリシー・エンジンは、すべてのルールの結果を取得し、それらを単一のポリシー決定に統合します（このプロセスは決定集約と呼ばれます）。そして、メッセージのリストを作成します。メッセージは、失敗したコードに関する詳細（どのルールに違反したか、どのオブジェクトに違反したか）を提供し、場合によってはそれを修正プログラムする方法を提案することもあります。

• 関連するメッセージ、タグ、重要度情報を含む決定結果をポリシー・エンジンは、返します。決定が「拒否」の場合、ポリシー・エンジンはすべてのプル・リクエストとコードのマージをブロックし、開発者がポリシー違反を修正するまでデプロイメントを停止します。決定が「許可」の場合、エンジンはビルド・アーティファクト（コンパイル、パッケージ化、テストされたコード・ファイル）を作成し、コードをデプロイします。警告がある場合、コードはパスされますが、エンジンはログ・ファイルまたはコメントに警告を含めます。

ポリシーチェックは、コード統合から本番環境、監視まで、ソフトウェア開発ライフサイクル（SDLC）の任意の段階で実施可能です。

ポリシーはコードであるため、他のソフトウェア成果物と同様に扱うこともできます。

開発チームは、サンプル・インプットをポリシーにフィードする自動テストを作成し、ポリシー変更時のフィードバック・サイクルを加速するために返される決定を検証できます。

ポリシーがエンコードされると、開発者は共通のロジックを再利用可能なモジュールや関数に取り出すことができます。複数の上位レベルのポリシーは、あらゆる場所で条件を重複させるのではなく、共有ポリシーを呼び出すことができます。

開発者は、大規模なアプリの機能を小さなポリシーにリファクタリングするのと同じように、動作を変えずに大規模なポリシーの名前を変更したり、再構築したり、小さなポリシーに分割したりすることもできます。

これらの機能により、チームは既存のソフトウェア・エンジニアリングの運用をガバナンス ロジックに適用でき、ITアーキテクチャーのスケールと進化に伴いセキュリティーとコンプライアンス要件を維持するのに役立ちます。

例えば、X社が、すべてのWebサービスでプレーンなHTTPではなくHTTPSを使用しなければならないという「HTTPSのみ」のポリシーの導入を進めているとします。ポリシーを体系化するために、プラットフォーム・エンジニアは次のようなシンプルなルールを作成します。

• サービスのプロトコルがHTTPの場合、変更は拒否されます。
• サービスのプロトコルがHTTPSの場合、変更は可能です。

エンジニアは、このポリシー・ファイルをアプリケーションと同じコード・リポジトリー内の「ポリシー」フォルダーに配置し、プル・リクエストを開いて、ポリシーを追加します。このプル要求により、ポリシー・ファイルの自動構文チェックと、別のエンジニアによるコード・レビューがトリガーされます。ポリシーが必要なテストに合格した後のみ、メイン・ブランチにマージされます。

継続的統合（CI）パイプラインでは、すべてのポリシー・ファイルは「policies」フォルダからポリシー・エンジンに読み込みます。ポリシー・エンジンはポリシーを読み取り、それを内部表現に変換し、コンパクトな低レベルの形式にコンパイルします。このコンパクトな形式により、エンジンは「許可か拒否か」という質問に素早く答えることができます。パイプラインがチェックするすべてのサービスに対して。

ファイルの形式に関係なく、CIジョブは既存の構成ファイルを取得し、重要なフィールド（名前、プロトコル、ポート）を抽出し、各サービスの簡単なJSON記述を構築します。

呼び出し元は、標準化されたサービス説明をインプットとして送信し、「HTTPS のみ」のポリシー・パッケージを適用する必要があることを示すことで、ポリシー・エンジンに決定を要求します。

次に、ポリシーエンジンはインプットをルールに照らして評価します。サービスのプロトコル・フィールドをチェックします。プロトコルがHTTPの場合、インプットがポリシーの「拒否」条件に一致することを意味します。このエンジンは変更を拒否する必要があることを示し、サービスはHTTPではなくHTTPSを使用する必要があることを開発者に伝えるメッセージを作成します。サービスがHTTPSを使用している場合、どの拒否条件も満たされず、エンジンは変更が許可されていることを示します。

次に、ポリシーエンジンはルールの評価を、サービスの単一の意思決定オブジェクトに要約します。意思決定オブジェクトでは通常、全体的な意思決定が「許可」か「拒否」か、および問題の重大度（高、中、低）を指定します。また、インプットが拒否された理由を説明するメッセージのリストや、エンジンが評価プロセスで見つかった警告も含まれています。すべてがコンプライアンスに準拠している場合、意思決定オブジェクトは変更が許可され、情報メモのみ（またはまったくメッセージが付属しない）を示します。

最後に、CIツールが決定を強制します。決定が「拒否」の場合、変更はメイン・コード・ブランチにマージされません。エンジニアに、サービスはHTTPSを使用し、特定の変更を行う必要があるというエラー・メッセージが表示されます。決定が「許可」の場合、アーティファクトはパッケージ化されてデプロイされ、CIパイプラインは通常どおり処理されます。

コードとしてのポリシーは、最新のDevOpsおよびクラウド・エンジニアリングにおける、より広範な「すべてをコードとして扱う」動きから生まれました。

当初、コードとしてのインフラストラクチャー（IaC）が大きな転換点でした。システム管理者がユーザー・インターフェースをクリックしたり、ランブックを進めたりする代わりに、チームはサーバー、ネットワーク、その他の参考情報を宣言型のコード・ファイルで記述しました。これらのファイルはバージョン管理システムに保管され、自動化されたパイプラインを通じて適用されます。

企業がメリットを実感するにつれ、このアプローチはITアーキテクチャーの他のコンポーネントにも広がりました。アプリケーション構成は、コードベースのアプローチへと移行しました。CI/CDパイプラインは、コード・リポジトリーに存在するスクリプトになりました。監視とアラートのルールもコードに記述され始めました。これらのプラクティスは合わせて、「Everything as code（すべてをコード化）」として知られるようになりました。

「すべてをコードとして扱う」の中心的な考え方は、システムの一部を説明できる場合、それはコードとして記述され、ソフトウェア・アプリケーションと同じ方法で管理されるべきであるというものです。

PaCは基本的に、その哲学をルール、ガバナンス、コンプライアンスにアプリケーションするものです。従来、ポリシーはPDFやWikiに保存されるか、委員会によって決定され、人間によって施行されていました。このプロセスは、リリース・サイクルが遅く、インフラストラクチャーが比較的静的だったときに機能しました。

クラウドネイティブやマイクロサービスのアーキテクチャーが主流となり、チームが1日に何度もコードをデプロイし始めると、手作業のプロセスは追いつきれなくなりました。PaCは、機械で読み取り可能な形式でポリシーを表現することで、この課題に対処しました。これにより、ポリシーをGitでバージョン管理し、コード・ファイルのようにレビューし、CIでテストし、パイプラインまたはランタイムに自動的に適用できるようになりました。

コードとしてのポリシーとは、ソフトウェア・コードのようにITポリシーを管理するための運用手法です。コードとしてのインフラストラクチャー（IaC）も同様ですが、焦点が異なります。エンジニアリングチームはアプリケーション・コードを用いてITインフラストラクチャーを定義・管理することを可能にします。

仮想マシン（VM）やロード・バランサーなどのネットワーク資産を手動で作成して設定する代わりに、IaCを使用すれば、開発者はこれらのリソースの望ましい状態を記述するコードを記述できます。IaCツールは、そのコードを取得し、指定された参考情報を作成または変更します。

IaCにより、インフラストラクチャーのスケーリングとオートメーションがはるかに簡単になります。チームに複数のサーバーが必要な場合は、コード内の数値を変更するだけで済みます（例えば、6つのインスタンスを9つのインスタンスに変えるなど）。オートメーション・ツールは、これらの参考情報のプロビジョニングに関する詳細な処理を行います。

大まかに言うと、IaCはどのインフラストラクチャーが存在すべきか、どのように構成すべきかを規定しますが、PaCはインフラストラクチャーが従うべきルールと制約に焦点を当てます。IaCコードは参考情報を作成・構成し、PaCコードはそれらの参考情報（およびその使用方法）が定義されたセキュリティー要件、コンプライアンス標準、運用上の保護策に従うようにします。

多くの最新のITアーキテクチャーやCI/CDセットアップでは、IaCとPaCは補完的なメリットをもたらします。IaCはプロビジョニングを自動化し、PaCはその上に自動化されたガバナンスを追加します。

開発者がIaCファイルを変更すると、PaCエンジンは新しいプランや構成を検査できます。すべてが確立されたポリシーに準拠していれば、変更を進めることができ、インフラストラクチャーが更新されます。何かがルールに違反すると、パイプラインは失敗し、問題が解決されるまで何もデプロイされません。

DevSecOpsは、セキュリティーとコンプライアンスをDevOpsライフサイクルに埋め込み、最後に付け加えるのではなく、これは、ソフトウェア開発ライフサイクルの各段階でセキュリティー・プロセスに優先順位を付けて実行する開発アプローチです。

PaCは、次の方法でDevSecOpsの運用をサポートします。

PaCは、問題がユーザーに影響を与える可能性があるデプロイメント後にチェックを実行するのを待つのではなく、セキュリティー・チェックを開発プロセスの初期段階に移すことで、チームがセキュリティーをレフトにシフトできるようにします。開発者がリスクの高い構成や安全でないパターンを導入した場合、自動化されたポリシーは問題を検知し、ビルドを失敗させる可能性があります。

PaCツールは、セキュリティー・ルールをCI/CDパイプラインやランタイム・システムに直接埋め込むことで適用を自動化し、コードやインフラストラクチャーが変更されるたびに自動的にチェックが行われます。すべてのセキュリティー基準を記憶し、すべての変更を手動でレビューすることを人間に頼るのではなく、システムは一貫して変更を評価し、誤ってステップが省略されないようにします。

PaCは、開発者が一貫性と安全性を犠牲にすることなく、デプロイメント速度を維持するのに役立ちます。開発、テスト、ステージング、本番などのすべての環境とすべての段階で、同じポリシー定義を実行します。この機能により、チームは同じルールセットがどこにでも適用されていることを信頼できるため、頻繁にリリースできます。また、異なる環境がばらばらになったり、ルールの解釈が少しずつ異なっていたりするような状況を回避するのにも役立ちます。

PaCは、アプリケーション・セキュリティー・ポリシーをバージョン管理システムに存在する他のコードアーティファクトと同様に扱います。開発、オペレーション、セキュリティーの各チームは、使い慣れたワークフロー（コード・レビュー、分岐ストラテジー）を通じてポリシーをレビュー、議論、更新できるため、ポリシーに関する議論の透明性が高まり、日常の開発作業に統合されやすくなります。

コードとしてのポリシーには、エンタープライズITアーキテクチャー向けの幅広いアプリケーションがあります。

開発者やセキュリティー専門家は、AIやエージェント型ワークフローのライフサイクル全体を網羅する階層化されたガードレール・モデルを作成する方法として、コードとしてのポリシーを模索しています。運用はまだ始まったばかりですが、初期の調査により、AIワークフローにおけるPaCのアプリケーションが数多く明らかになっています。

PaCは、AIの推論と、実際に実行が許可されるアクションを決定するシステムとの間に明確な分離を確立するのに役立ちます。AIツールはアクションや計画を提案することができますが、ポリシー・エンジンは、基盤となるシステムに影響を与える前に、それらの提案を成文化されたルールに照らして評価します。

インプット段階で、PaCはユーザー・プロンプトのフィルタリングまたは変換、機密データの編集、テナント分離の強制、既知の攻撃パターンのブロックに役立ちます。計画段階において、PaCはAIエージェントに対し、構造化された計画を作成し、実行が許可される前に、各ステップを許可されたツール、アクション、およびリスク条件に照らして検証することを要求できます。

実行時に、すべてのツール呼び出しまたはAPI呼び出しをポリシー適用層でチェックできます。彼らは、アクションを許可、拒否、変更するか、人間にエスカレーションするかを決定します。実行後、ポリシーによってモデル・アウトプットのロギング、監査証跡、保持ルール、およびポストフィルターが駆動され、応答が必要な要件に準拠していることを確認するのに役立ちます。

• 一貫性。PaCでは、同じコードがどこで実行されるため、ポリシーはすべての環境に同じ方法で適用されます。この一貫性により、1回限りの「スノーフレーク」構成が減り、チームは環境ごとに微妙に異なる手動プロセスを覚えておく必要がなくなります。

• 効率性。ポリシーが成文化されると、CI/CDパイプラインまたはデプロイメント時に自動的に適用できるため、手動でのチェックや承認が不要になります。

• オートメーション。PaCは自動検証とポリシーテストを可能にし、チームが人的ミスの影響を最小限に抑え、設定ミスを発見し、本番環境に入る前にセキュリティーの脆弱性に対処するのに役立ちます。

• 可視性。コードで記述され、保管されたポリシーにより、利害関係者は、散在した文書や人々の記憶に頼るのではなく、どのようなルールが適用されているかを正確に確認できます。

• 拡張性。ポリシー評価は自動化されているため、組織は人員を比例的に増やさずに、多くのサービス、クラスター、またはアカウントにわたってポリシーを大規模に適用できます。

• コラボレーション。PaCは、ポリシー・コードに関するコラボレーションを合理化します。これらの共有ワークフローはサイロを打破し、セキュリティーとガバナンスをDevOpsの運用方法に合わせて調整し、ポリシーに関する議論をより具体的かつテストしやすいものにします。