テクノロジー DEVOPS 非公開: Policy-as-Code: 2023 年にそれを理解して実装する方法

Policy-as-Code: 2023 年にそれを理解して実装する方法

Policy-as-Code (PaC) は、自動化、効率、コラボレーションなどの点で、それを実装するチームに多くの利点をもたらす最新のアプローチです。

組織のポリシーを作成し、データベースに保存している場合があります。

しかし、それらに加えられた変更をどのくらいの頻度で追跡し、それらが正しく適用されているかどうかを追跡していますか?

特にルールや規制の変更により、すべてを追跡するのは難しいことは理解しています。

ただし、ポリシーが正しく埋め込まれていない場合、セキュリティやコンプライアンスなどの観点から組織に損害を与える可能性があります。

これに対して、ポリシーを成文化してテキスト ファイルで提示すると、誰もがポリシーに従うことが容易になります。

これが、policy-as code が提供するものであり、それ以上のものです。また、ポリシーに加えられた変更とその実装方法を追跡することもでき、セキュリティとコンプライアンスの維持にも役立ちます。

それでは、コードとしてのポリシー、その利点、およびそれを組織に実装する方法を理解しましょう。

コードとしてのポリシーとは何ですか?

コードとしてのポリシーとは
コードとしてのポリシーとは

コードとしてのポリシーをよりよく理解するために、このコンテキストにおけるポリシーが何であるかを定義しましょう。

ポリシー : ポリシーは、IT プロセスまたは運用を管理するルール、指示、または条件です。プロセスが承認されるために常に満たさなければならない基準を定義します。

たとえば、特定のコードが IT セキュリティ ポリシーを通過して展開されるようにするには、該当するポリシーを満たしている必要があります。

ポリシーには、運用ポリシー、セキュリティ ポリシー、コンプライアンス ポリシーなど、さまざまな種類があります。

ポリシーとしてのコード: コードとしてのポリシー (PaC) は、コードを使用してポリシーを定義、共有、強制、および更新するポリシー管理アプローチです。チームは、使用中の PaC ツールに基づいて、Python、Java、YAML などの高水準プログラミング言語を使用してポリシーを作成する必要があります。

PaC を使用すると、組織は手動によるポリシー管理に依存するのではなく、コードベースの自動化を利用してプロセスを加速できます。また、さまざまなドメイン (IT セキュリティや開発など) の関係者がポリシーをよりよく理解できるようになります。

たとえば、開発者が何らかの更新を行いたい場合、現在のコードを変更し、必要に応じて他のユーザーと共有することもできます。これにより、自社のポリシーを確認し、そこから逸脱していないことを確認できるようになります。

コードとしてのポリシーとコードとしてのインフラストラクチャ

ポリシーascodevsインフラストラクチャascode
ポリシーascodevsインフラストラクチャascode

Policy-as-Code (PaC) は、概念としては Infrastructure-as-Code (IaC) に似ていますが、同じではありません。

現在、企業は開発から導入まで最新の技術、多くのツール、リソースを使用しています。これには、オンプレミス インフラストラクチャ、プライベート クラウドおよびパブリック クラウド、仮想マシン、Software as a Service (SaaS) モデルおよびツールなどが含まれる場合があります。

さまざまなリソース管理およびオーケストレーション ツールの使用とは別に、企業はプロビジョニングにおいてクラウド プロバイダーに大きく依存しています。これには、すべてのコンポーネントを統合して通信しやすくし、定期的なパッチを適用し、セキュリティ問題に対処するための高度な専門知識も必要です。

問題は、ベンダー、ソフトウェア、ハードウェアに費やす費用は言うまでもなく、インフラストラクチャへの変更の管理、レビュー、監査、承認に多大な時間とリソースがかかることでした。

これに対する良い解決策は IaC です。 IaC は、コードベースのファイルを利用して、プロビジョニングおよび構成プロセスを自動化します。これは、ほぼすべての IT 運用チームにとって一般的な慣行です。

一方、PaC は、DevOps と IaC の間のギャップを埋めることによって IaC を拡張します。 PaC は、すべての導入環境のデータ管理、コンプライアンス、セキュリティ運用の改善に役立ちます。さらに、そのユースケースは IaC よりも幅広いです。 PaC はソフトウェア開発ライフサイクル全体を通じて使用されます。

さらに、PaC ツールは複数の統合とプラットフォームをサポートし、許可されたユーザーのアクセス許可を制限し、最小限の権限でアクセスを許可できます。ポリシーでは、ブロックリストとホワイトリストを通じて境界を定義し、インフラストラクチャを監視して、インフラストラクチャのライフサイクルとクラウド全体にわたるコンプライアンスを確保することもできます。

コードとしてのポリシーはどのように機能しますか?

政策ワークス
政策ワークス

Policy-as-Code は、実際には、何かを行う方法について概説されたすべての契約条件を含む、読み取り可能なスクリプト化されたファイルです。たとえば、アプリケーションまたはその作成、展開、保守のテスト ポリシーの概要を説明できます。

ポリシーは、組織内で使用されるさまざまなツールと互換性のある、Java、Python などの高レベル プログラミング言語を使用して作成されます。

コードとして記述されたポリシーは、クエリによってシステム (ポリシー エンジン) に入力されます。ポリシー コードを入力として受け取った後、ポリシー エンジンはコードを処理し、クエリの結果を出力します。

次に、その結​​果に基づいて、現在のポリシーに沿った決定が作成されます。これは、ソフトウェア セキュリティ テストの適切な種類と、テスト チームがいつ、どの領域でテストを実行する必要があるかを決定するのに役立ちます。

また、ポリシーは CI パイプラインに対して行われる API 呼び出しを通じて実装されるため、コードを中断することなくセキュリティ テストを簡単に実行できます。コードとしてのポリシーを作成するときは、次の点を考慮してください。

  • 依存関係を確認し、テストによってデプロイメントやビルドが中断される可能性があるかどうかを確認してください。問題を特定し、問題追跡ツールに入力します。
  • 最後の変更がいつ行われたか、およびその規模はどれくらいだったかを検査します。また、追加のテストやコード レビューが必要かどうかも判断します。
  • ソフトウェアに機密データが含まれているかどうか、攻撃対象領域がどのようなものであるか、発生する可能性のあるダウンタイムのリスクを調べます。

コードとしてのポリシーは、次の 3 つの要素を利用して機能します。

  • ポリシー: PaC は、意思決定を容易にするために、内部のコードを含む特定のポリシー自体を使用します。
  • データ : PaC は、特定のソフトウェア アプリケーション、環境、またはサービスに関するデータを使用します。
  • クエリ : クエリは、利用可能なデータとポリシー エンジンに入力されたポリシーに基づいて意思決定のプロセスをトリガーします。

なぜポリシー・アズ・コードが必要なのでしょうか?

コードとしてのポリシーが必要な理由
コードとしてのポリシーが必要な理由

従来のポリシー適用プロセスは半自動または手動で行われていました。ここでは、ソフトウェア開発チームがアプリケーションにポリシー適用コードを埋め込みます。

定義されたフレームワークがないため、彼らは自分たちの希望に従ってコードを実装します。その結果、このコードを監査することが困難になり、プロセスを拡張することも困難になります。

従来のポリシー適用に関するもう 1 つの問題は、状況の変化に応じてポリシーが頻繁に更新されるため、チームが追跡して実装することが困難であることです。また、フレームワークが定義されていない場合、チームごとにポリシーの解釈と実装が異なる可能性があります。

さらに、現代のビジネスは、手動で、またはビジネス ロジック全体の一部として施行される PCI DSS、SOC2 などの規制に準拠する必要があります。これらのコードはさまざまな言語で書かれ、さまざまな開発チームによって管理され、コード リポジトリに保存されます。そのため、何かを変更すると、実装に数週間から数か月という大幅な時間がかかる場合があります。

これらはすべて、混乱、エラー、リソースの浪費、そして面倒で時間の浪費を引き起こす可能性があります。しかし、コードとしてのポリシーを実装すると、ポリシーの定義、テスト ケースの作成と検証、そして最終的にそれらの適用を自動化することができます。

ここでは、コードとしてのポリシーを使用する利点と、それを実装する必要がある理由を詳しく説明します。

オートメーション

ポリシーの自動化コード
ポリシーの自動化コード

コードとしてのポリシーは、さまざまなツールを利用して自動化を促進します。このようなツールを使用すると、ユーザーはポリシーの作成、定義、管理、更新など、繰り返し行われる面倒なタスクを自動化できます。さらに、CI/CD ツールを使用してポリシーのテスト プロセスを自動化し、展開前にすべてが正常であることを確認することもできます。

テストと検証

ポリシーはコードであり、いくつかの自動ツールを使用してポリシーの動作と構文を簡単に検証できます。これにより、CI/CD システムによる自動テストも容易になります。これは、ポリシー違反や脆弱性を検出し、展開前にポリシーが実装されているかどうかを判断するのに役立ちます。

さらに、バージョン管理システム(VCS)と組み合わせれば、統合前にシステムの動作が期待どおりかどうかを検証できます。グラフィカル ユーザー インターフェイス (GUI) を介してポリシーを設定し、プル リクエストを通じてポリシーをテストできます。

サンドボックス化

PaC は、ソフトウェア ソリューションを相互に分離するためにサンドボックス セキュリティを提供します。これはセキュリティ リスクの防止に役立ちます。サンドボックスには高度な自動化が含まれるため、それらの自動化システムが危険なアクティビティを実行しないようにする必要があります。このため、手動による検証は現実的ではありません。したがって、サンドボックスを安全に実装したい場合は、PaC を適用することが不可欠になります。

スピードと正確さ

スピードと正確さ
スピードと正確さ

ポリシー適用プロセスを自動化すると、手動の方法と比較して操作が高速化されます。時間を大幅に節約でき、繰り返しの日常的なタスクを実行する代わりに、他の重要なタスクに充てることができます。さらに、タスクを自動化するとエラーやミスがほとんど、またはまったく発生しないため、タスクと製品の精度が向上します。

成文化と可視化

ポリシー条項をコードとして表すことにより、ポリシーを口頭で学習する代わりに、ポリシーのデータとロジックをコードで直接概説し、コメントを通じて強化することができます。これにより、関係者はコードを簡単にレビューして変更を提案できるため、特定のポリシーに関するロジックやその他の情報を理解しやすくなります。

したがって、この可視性の向上により、他のメンバーに何度も連絡する必要がなくなり、ワークフローが高速化されます。

バージョン管理

ポリシーをテキスト ファイルとして保存すると、ポリシーのバージョンの追跡、管理、制御が簡単になります。ポリシーを更新する必要がある場合は、現在のコードを変更するだけです。ただし、何か問題がある場合は、以前のバージョンに戻すことができます。

さらに、チームメンバーは、どのポリシーがいつ変更されたかを検出することもできます。これは、履歴、プル リクエスト、差分などのバージョン管理システム (VCS) の機能の恩恵を受けることを意味します。

コラボレーション

定義された方法に従ってポリシーを作成し、ポリシーを管理することで、外部チームと内部チーム内のコラボレーションが促進されます。 Policy-as-Code では、開発、テスト、バージョン管理、セキュリティなど、さまざまなチームや部門が集まります。

コラボレーション
コラボレーション

たとえば、テスト チームと開発チームが協力して、必要なテストに合格し、デプロイメントの準備が整った最高品質のコードを確実に作成することができます。

さらに、チームはコラボレーション ツール、バージョン管理、その他の自動化ツールを活用して共同作業することもできます。コードを表示し、提案をし、コードを改善するためのコメントを入力し、フィードバックに取り組み、コードのセキュリティを監視するなど、さまざまなことができます。これらすべてがリリースの加速に役立ちます。

Policy-as-Code の使用例

コードとしてのポリシーのユースケース
コードとしてのポリシーのユースケース

コードとしてのポリシーのさまざまな使用例は次のとおりです。

#1. インフラストラクチャのプロビジョニング

コードとしてのポリシーは、運用、コンプライアンス、セキュリティのためにインフラストラクチャ リソース (サービス、データベースなど) をプロビジョニングするプロセスを自動化できます。リソースのプロビジョニングとは別に、ネットワーク設定、ファイアウォール、その他のリソースのタグ付けを含めることができます。

ユニットまたはチームごとにリソースにタグを付けると、リソースを効率的に管理するのに役立ちます。さらに、PaC を使用して、許可されたすべての IP アドレスのリストを作成し、外部 IP アドレスからアプリケーションまたはページにアクセスできるようにそれを付与することができます。

さらに、PaC は、開発、サンドボックス、実稼働、ステージングなどのさまざまな環境にさまざまなタイプのリソースをプロビジョニングするのに役立ちます。このようにして、これらすべての環境に適したマシンを構成できます。

#2. Kubernetes コントロール

kubernetes-コントロール
kubernetes-コントロール

プロセスで Kubernetes を使用する場合は、ポリシーを PaC として構成することをお勧めします。ノード、名前空間、ポッドなどの Kubernetes リソースを効果的に管理するためのポリシーを作成できます。

さらに、コンテナの作成とリクエストの実行に対する CPU とメモリの制限を設定できます。これは、メモリ不足 (OOM) 状態やリソースの占有を防ぐのに役立ちます。

したがって、アプリケーションは常に利用可能であり、最適に実行されます。過剰なリソースの消費や不足を引き起こすことなく要求に簡単に応えるために、レプリカの最大数と最小数のポリシーを設定することをお勧めします。

#3. アクセスと認可の制御

サービスにアクセスするための認可ルールを概説したポリシーを作成すると、本質的にそのセキュリティが強化されます。ユーザーがどのリソースにアクセスできるかに関する条項が含まれます。侵害が発生しないように、許可されたアクセス方法を強調表示することもできます。

たとえば、HTTPS 接続のみを許可するポリシーを作成できます。これはセキュリティ体制の向上に役立ちます。別の例としては、信頼できないと思われる特定の種類のサービスを拒否するポリシーを設定することが考えられます。

#4. 監査とコンプライアンス

コンプライアンス
コンプライアンス

今日の組織は、適用される政府および業界の標準に準拠する必要があります。これには、HIPAA、GDPR、PCI DSS などの規制が含まれる場合があります。これらの標準では、データ ストレージ、コンピューティング、ネットワーキングに関する規則に従うことが求められます。

さて、問題は、これらのルールがいつでも状況に応じて変更される可能性があり、それらを追跡するのが難しくて面倒になる可能性があることです。

コードとしてのポリシーを通じて、これらのルールを成文化し、ソフトウェア開発プロセスに簡単に組み込むことができます。すべてのポリシー、入力、変更、クエリ結果が確実にログに記録されるため、監査が容易になります。これにより、コンプライアンス規制をより適切に満たし、罰則を回避することができます。

#5. 経費管理

経費の制御と管理は、インフラストラクチャを管理する上で重要な部分です。このために、リソースのラベル付け、アノテーション、マシンタイプの配布などにコードとしてのポリシーを実装できます。

  • チームまたは部門ごとにリソースにラベルを付けると、経費を示すレポートを生成できます。
  • 特定のタイプのマシンを割り当ててコードを最適化することで、レポートを作成し、インフラストラクチャのリソース消費を最適化する最適な方法を関係者に決定させることができます。
  • 運用、開発、サンドボックス、ステージングなどのインフラストラクチャ環境の各プロジェクトのコストを制限するポリシーを設定できます。

コードとしてのポリシーを実装する方法

ポリシーをコードとして実装する方法
ポリシーをコードとして実装する方法

コードとしてのポリシーが組織にとって有益であることがわかり、それを実装する方法を疑問に思っている場合は、読み続けてください。

コードとしてのポリシーを最も簡単な方法で活用するには、この概念が必要な領域 (セキュリティ、コンプライアンス、プロビジョニングなど) でコードとしてのポリシーをネイティブにサポートする高品質ツールを採用できます。ただし、いずれかを選択する前に、ユースケースと組織戦略、ツールの拡張性、サポートモデル、統合、その他の機能を考慮してください。

最良のコードとしてのポリシー ツールには、次のようなものがあります。

#1. オープンポリシーエージェント

Open Policy Agent は、 ポリシー適用全体を統合できる汎用のオープンソース ポリシー エンジンです。コードとしてのポリシー実装の共通フレームワークを提供することで、あらゆるドメインで機能します。 Kubernetes、Terraform、AWS、Docker、Envoy、GKE などのサービスをサポートしています。

#2. プリズマクラウド

Prisma Cloud はセキュリティを目的としており、コードを介してすべてのセキュリティ ポリシーを定義できます。実際にコードを展開する前に、ポリシー ファイルを自動的にスキャンして監査し、脆弱性や構成ミスを見つけることができます。その他のセキュリティ用のコードとしてのポリシー ツールには、Checkov、Bridgecrew などがあります。

#3. セキュリティRAT

SecurityRAT は、計画段階で役立つ OWASP のオープンソース ツールです。 IT セキュリティのニーズをコードとして作成し、プロジェクトに統合するのに役立ちます。これにより、監査も容易になります。したがって、コンプライアンス要件を満たすのに役立ちます。

#4. センチネル

Sentinel は埋め込み可能なコードとしてのポリシー フレームワークで、ロジック ベースの詳細なポリシー決定を可能にし、情報に基づいた意思決定を行うために外部ソース情報に拡張できます。これは、開発およびテスト段階で役立ちます。

その他の優れたツールには、TruffleHog、Git-Secrets、Gitty Leaks、InSpec、Terraform などがあります。

結論

コードとしてのポリシーは、リソースの提供、アクセス制御、コスト管理、監査とコンプライアンス、セキュリティなど、さまざまな方法でビジネスに役立ちます。

この記事が、コードとしてのポリシーと、それを組織に実装する必要がある理由とその方法を理解するのに役立つことを願っています。

コードの品質を監査および管理するための興味深いツールをいくつか探索することもできます。

「 Policy-as-Code: 2023 年にそれを理解して実装する方法」についてわかりやすく解説!絶対に観るべきベスト2動画

Japanese Google Policy Office Hours(Google ポリシー オフィスアワー 2023 年 02 月 09 日)
Japanese Google Policy Office Hours(Google ポリシー オフィスアワー 2023 年 01 月 26 日)

Policy-as-Code (PaC) は、自動化、効率、コラボレーションなどの点で、それを実装するチームに多くの利点をもたらす最新のアプローチです。

組織のポリシーを作成し、データベースに保存している場合があります。

しかし、それらに加えられた変更をどのくらいの頻度で追跡し、それらが正しく適用されているかどうかを追跡していますか?

特にルールや規制の変更により、すべてを追跡するのは難しいことは理解しています。

ただし、ポリシーが正しく埋め込まれていない場合、セキュリティやコンプライアンスなどの観点から組織に損害を与える可能性があります。

これに対して、ポリシーを成文化してテキスト ファイルで提示すると、誰もがポリシーに従うことが容易になります。

これが、policy-as code が提供するものであり、それ以上のものです。また、ポリシーに加えられた変更とその実装方法を追跡することもでき、セキュリティとコンプライアンスの維持にも役立ちます。

それでは、コードとしてのポリシー、その利点、およびそれを組織に実装する方法を理解しましょう。

コードとしてのポリシーとは何ですか?

コードとしてのポリシーとは
コードとしてのポリシーとは

コードとしてのポリシーをよりよく理解するために、このコンテキストにおけるポリシーが何であるかを定義しましょう。

ポリシー : ポリシーは、IT プロセスまたは運用を管理するルール、指示、または条件です。プロセスが承認されるために常に満たさなければならない基準を定義します。

たとえば、特定のコードが IT セキュリティ ポリシーを通過して展開されるようにするには、該当するポリシーを満たしている必要があります。

ポリシーには、運用ポリシー、セキュリティ ポリシー、コンプライアンス ポリシーなど、さまざまな種類があります。

ポリシーとしてのコード: コードとしてのポリシー (PaC) は、コードを使用してポリシーを定義、共有、強制、および更新するポリシー管理アプローチです。チームは、使用中の PaC ツールに基づいて、Python、Java、YAML などの高水準プログラミング言語を使用してポリシーを作成する必要があります。

PaC を使用すると、組織は手動によるポリシー管理に依存するのではなく、コードベースの自動化を利用してプロセスを加速できます。また、さまざまなドメイン (IT セキュリティや開発など) の関係者がポリシーをよりよく理解できるようになります。

たとえば、開発者が何らかの更新を行いたい場合、現在のコードを変更し、必要に応じて他のユーザーと共有することもできます。これにより、自社のポリシーを確認し、そこから逸脱していないことを確認できるようになります。

コードとしてのポリシーとコードとしてのインフラストラクチャ

ポリシーascodevsインフラストラクチャascode
ポリシーascodevsインフラストラクチャascode

Policy-as-Code (PaC) は、概念としては Infrastructure-as-Code (IaC) に似ていますが、同じではありません。

現在、企業は開発から導入まで最新の技術、多くのツール、リソースを使用しています。これには、オンプレミス インフラストラクチャ、プライベート クラウドおよびパブリック クラウド、仮想マシン、Software as a Service (SaaS) モデルおよびツールなどが含まれる場合があります。

さまざまなリソース管理およびオーケストレーション ツールの使用とは別に、企業はプロビジョニングにおいてクラウド プロバイダーに大きく依存しています。これには、すべてのコンポーネントを統合して通信しやすくし、定期的なパッチを適用し、セキュリティ問題に対処するための高度な専門知識も必要です。

問題は、ベンダー、ソフトウェア、ハードウェアに費やす費用は言うまでもなく、インフラストラクチャへの変更の管理、レビュー、監査、承認に多大な時間とリソースがかかることでした。

これに対する良い解決策は IaC です。 IaC は、コードベースのファイルを利用して、プロビジョニングおよび構成プロセスを自動化します。これは、ほぼすべての IT 運用チームにとって一般的な慣行です。

一方、PaC は、DevOps と IaC の間のギャップを埋めることによって IaC を拡張します。 PaC は、すべての導入環境のデータ管理、コンプライアンス、セキュリティ運用の改善に役立ちます。さらに、そのユースケースは IaC よりも幅広いです。 PaC はソフトウェア開発ライフサイクル全体を通じて使用されます。

さらに、PaC ツールは複数の統合とプラットフォームをサポートし、許可されたユーザーのアクセス許可を制限し、最小限の権限でアクセスを許可できます。ポリシーでは、ブロックリストとホワイトリストを通じて境界を定義し、インフラストラクチャを監視して、インフラストラクチャのライフサイクルとクラウド全体にわたるコンプライアンスを確保することもできます。

コードとしてのポリシーはどのように機能しますか?

政策ワークス
政策ワークス

Policy-as-Code は、実際には、何かを行う方法について概説されたすべての契約条件を含む、読み取り可能なスクリプト化されたファイルです。たとえば、アプリケーションまたはその作成、展開、保守のテスト ポリシーの概要を説明できます。

ポリシーは、組織内で使用されるさまざまなツールと互換性のある、Java、Python などの高レベル プログラミング言語を使用して作成されます。

コードとして記述されたポリシーは、クエリによってシステム (ポリシー エンジン) に入力されます。ポリシー コードを入力として受け取った後、ポリシー エンジンはコードを処理し、クエリの結果を出力します。

次に、その結​​果に基づいて、現在のポリシーに沿った決定が作成されます。これは、ソフトウェア セキュリティ テストの適切な種類と、テスト チームがいつ、どの領域でテストを実行する必要があるかを決定するのに役立ちます。

また、ポリシーは CI パイプラインに対して行われる API 呼び出しを通じて実装されるため、コードを中断することなくセキュリティ テストを簡単に実行できます。コードとしてのポリシーを作成するときは、次の点を考慮してください。

  • 依存関係を確認し、テストによってデプロイメントやビルドが中断される可能性があるかどうかを確認してください。問題を特定し、問題追跡ツールに入力します。
  • 最後の変更がいつ行われたか、およびその規模はどれくらいだったかを検査します。また、追加のテストやコード レビューが必要かどうかも判断します。
  • ソフトウェアに機密データが含まれているかどうか、攻撃対象領域がどのようなものであるか、発生する可能性のあるダウンタイムのリスクを調べます。

コードとしてのポリシーは、次の 3 つの要素を利用して機能します。

  • ポリシー: PaC は、意思決定を容易にするために、内部のコードを含む特定のポリシー自体を使用します。
  • データ : PaC は、特定のソフトウェア アプリケーション、環境、またはサービスに関するデータを使用します。
  • クエリ : クエリは、利用可能なデータとポリシー エンジンに入力されたポリシーに基づいて意思決定のプロセスをトリガーします。

なぜポリシー・アズ・コードが必要なのでしょうか?

コードとしてのポリシーが必要な理由
コードとしてのポリシーが必要な理由

従来のポリシー適用プロセスは半自動または手動で行われていました。ここでは、ソフトウェア開発チームがアプリケーションにポリシー適用コードを埋め込みます。

定義されたフレームワークがないため、彼らは自分たちの希望に従ってコードを実装します。その結果、このコードを監査することが困難になり、プロセスを拡張することも困難になります。

従来のポリシー適用に関するもう 1 つの問題は、状況の変化に応じてポリシーが頻繁に更新されるため、チームが追跡して実装することが困難であることです。また、フレームワークが定義されていない場合、チームごとにポリシーの解釈と実装が異なる可能性があります。

さらに、現代のビジネスは、手動で、またはビジネス ロジック全体の一部として施行される PCI DSS、SOC2 などの規制に準拠する必要があります。これらのコードはさまざまな言語で書かれ、さまざまな開発チームによって管理され、コード リポジトリに保存されます。そのため、何かを変更すると、実装に数週間から数か月という大幅な時間がかかる場合があります。

これらはすべて、混乱、エラー、リソースの浪費、そして面倒で時間の浪費を引き起こす可能性があります。しかし、コードとしてのポリシーを実装すると、ポリシーの定義、テスト ケースの作成と検証、そして最終的にそれらの適用を自動化することができます。

ここでは、コードとしてのポリシーを使用する利点と、それを実装する必要がある理由を詳しく説明します。

オートメーション

ポリシーの自動化コード
ポリシーの自動化コード

コードとしてのポリシーは、さまざまなツールを利用して自動化を促進します。このようなツールを使用すると、ユーザーはポリシーの作成、定義、管理、更新など、繰り返し行われる面倒なタスクを自動化できます。さらに、CI/CD ツールを使用してポリシーのテスト プロセスを自動化し、展開前にすべてが正常であることを確認することもできます。

テストと検証

ポリシーはコードであり、いくつかの自動ツールを使用してポリシーの動作と構文を簡単に検証できます。これにより、CI/CD システムによる自動テストも容易になります。これは、ポリシー違反や脆弱性を検出し、展開前にポリシーが実装されているかどうかを判断するのに役立ちます。

さらに、バージョン管理システム(VCS)と組み合わせれば、統合前にシステムの動作が期待どおりかどうかを検証できます。グラフィカル ユーザー インターフェイス (GUI) を介してポリシーを設定し、プル リクエストを通じてポリシーをテストできます。

サンドボックス化

PaC は、ソフトウェア ソリューションを相互に分離するためにサンドボックス セキュリティを提供します。これはセキュリティ リスクの防止に役立ちます。サンドボックスには高度な自動化が含まれるため、それらの自動化システムが危険なアクティビティを実行しないようにする必要があります。このため、手動による検証は現実的ではありません。したがって、サンドボックスを安全に実装したい場合は、PaC を適用することが不可欠になります。

スピードと正確さ

スピードと正確さ
スピードと正確さ

ポリシー適用プロセスを自動化すると、手動の方法と比較して操作が高速化されます。時間を大幅に節約でき、繰り返しの日常的なタスクを実行する代わりに、他の重要なタスクに充てることができます。さらに、タスクを自動化するとエラーやミスがほとんど、またはまったく発生しないため、タスクと製品の精度が向上します。

成文化と可視化

ポリシー条項をコードとして表すことにより、ポリシーを口頭で学習する代わりに、ポリシーのデータとロジックをコードで直接概説し、コメントを通じて強化することができます。これにより、関係者はコードを簡単にレビューして変更を提案できるため、特定のポリシーに関するロジックやその他の情報を理解しやすくなります。

したがって、この可視性の向上により、他のメンバーに何度も連絡する必要がなくなり、ワークフローが高速化されます。

バージョン管理

ポリシーをテキスト ファイルとして保存すると、ポリシーのバージョンの追跡、管理、制御が簡単になります。ポリシーを更新する必要がある場合は、現在のコードを変更するだけです。ただし、何か問題がある場合は、以前のバージョンに戻すことができます。

さらに、チームメンバーは、どのポリシーがいつ変更されたかを検出することもできます。これは、履歴、プル リクエスト、差分などのバージョン管理システム (VCS) の機能の恩恵を受けることを意味します。

コラボレーション

定義された方法に従ってポリシーを作成し、ポリシーを管理することで、外部チームと内部チーム内のコラボレーションが促進されます。 Policy-as-Code では、開発、テスト、バージョン管理、セキュリティなど、さまざまなチームや部門が集まります。

コラボレーション
コラボレーション

たとえば、テスト チームと開発チームが協力して、必要なテストに合格し、デプロイメントの準備が整った最高品質のコードを確実に作成することができます。

さらに、チームはコラボレーション ツール、バージョン管理、その他の自動化ツールを活用して共同作業することもできます。コードを表示し、提案をし、コードを改善するためのコメントを入力し、フィードバックに取り組み、コードのセキュリティを監視するなど、さまざまなことができます。これらすべてがリリースの加速に役立ちます。

Policy-as-Code の使用例

コードとしてのポリシーのユースケース
コードとしてのポリシーのユースケース

コードとしてのポリシーのさまざまな使用例は次のとおりです。

#1. インフラストラクチャのプロビジョニング

コードとしてのポリシーは、運用、コンプライアンス、セキュリティのためにインフラストラクチャ リソース (サービス、データベースなど) をプロビジョニングするプロセスを自動化できます。リソースのプロビジョニングとは別に、ネットワーク設定、ファイアウォール、その他のリソースのタグ付けを含めることができます。

ユニットまたはチームごとにリソースにタグを付けると、リソースを効率的に管理するのに役立ちます。さらに、PaC を使用して、許可されたすべての IP アドレスのリストを作成し、外部 IP アドレスからアプリケーションまたはページにアクセスできるようにそれを付与することができます。

さらに、PaC は、開発、サンドボックス、実稼働、ステージングなどのさまざまな環境にさまざまなタイプのリソースをプロビジョニングするのに役立ちます。このようにして、これらすべての環境に適したマシンを構成できます。

#2. Kubernetes コントロール

kubernetes-コントロール
kubernetes-コントロール

プロセスで Kubernetes を使用する場合は、ポリシーを PaC として構成することをお勧めします。ノード、名前空間、ポッドなどの Kubernetes リソースを効果的に管理するためのポリシーを作成できます。

さらに、コンテナの作成とリクエストの実行に対する CPU とメモリの制限を設定できます。これは、メモリ不足 (OOM) 状態やリソースの占有を防ぐのに役立ちます。

したがって、アプリケーションは常に利用可能であり、最適に実行されます。過剰なリソースの消費や不足を引き起こすことなく要求に簡単に応えるために、レプリカの最大数と最小数のポリシーを設定することをお勧めします。

#3. アクセスと認可の制御

サービスにアクセスするための認可ルールを概説したポリシーを作成すると、本質的にそのセキュリティが強化されます。ユーザーがどのリソースにアクセスできるかに関する条項が含まれます。侵害が発生しないように、許可されたアクセス方法を強調表示することもできます。

たとえば、HTTPS 接続のみを許可するポリシーを作成できます。これはセキュリティ体制の向上に役立ちます。別の例としては、信頼できないと思われる特定の種類のサービスを拒否するポリシーを設定することが考えられます。

#4. 監査とコンプライアンス

コンプライアンス
コンプライアンス

今日の組織は、適用される政府および業界の標準に準拠する必要があります。これには、HIPAA、GDPR、PCI DSS などの規制が含まれる場合があります。これらの標準では、データ ストレージ、コンピューティング、ネットワーキングに関する規則に従うことが求められます。

さて、問題は、これらのルールがいつでも状況に応じて変更される可能性があり、それらを追跡するのが難しくて面倒になる可能性があることです。

コードとしてのポリシーを通じて、これらのルールを成文化し、ソフトウェア開発プロセスに簡単に組み込むことができます。すべてのポリシー、入力、変更、クエリ結果が確実にログに記録されるため、監査が容易になります。これにより、コンプライアンス規制をより適切に満たし、罰則を回避することができます。

#5. 経費管理

経費の制御と管理は、インフラストラクチャを管理する上で重要な部分です。このために、リソースのラベル付け、アノテーション、マシンタイプの配布などにコードとしてのポリシーを実装できます。

  • チームまたは部門ごとにリソースにラベルを付けると、経費を示すレポートを生成できます。
  • 特定のタイプのマシンを割り当ててコードを最適化することで、レポートを作成し、インフラストラクチャのリソース消費を最適化する最適な方法を関係者に決定させることができます。
  • 運用、開発、サンドボックス、ステージングなどのインフラストラクチャ環境の各プロジェクトのコストを制限するポリシーを設定できます。

コードとしてのポリシーを実装する方法

ポリシーをコードとして実装する方法
ポリシーをコードとして実装する方法

コードとしてのポリシーが組織にとって有益であることがわかり、それを実装する方法を疑問に思っている場合は、読み続けてください。

コードとしてのポリシーを最も簡単な方法で活用するには、この概念が必要な領域 (セキュリティ、コンプライアンス、プロビジョニングなど) でコードとしてのポリシーをネイティブにサポートする高品質ツールを採用できます。ただし、いずれかを選択する前に、ユースケースと組織戦略、ツールの拡張性、サポートモデル、統合、その他の機能を考慮してください。

最良のコードとしてのポリシー ツールには、次のようなものがあります。

#1. オープンポリシーエージェント

Open Policy Agent は、 ポリシー適用全体を統合できる汎用のオープンソース ポリシー エンジンです。コードとしてのポリシー実装の共通フレームワークを提供することで、あらゆるドメインで機能します。 Kubernetes、Terraform、AWS、Docker、Envoy、GKE などのサービスをサポートしています。

#2. プリズマクラウド

Prisma Cloud はセキュリティを目的としており、コードを介してすべてのセキュリティ ポリシーを定義できます。実際にコードを展開する前に、ポリシー ファイルを自動的にスキャンして監査し、脆弱性や構成ミスを見つけることができます。その他のセキュリティ用のコードとしてのポリシー ツールには、Checkov、Bridgecrew などがあります。

#3. セキュリティRAT

SecurityRAT は、計画段階で役立つ OWASP のオープンソース ツールです。 IT セキュリティのニーズをコードとして作成し、プロジェクトに統合するのに役立ちます。これにより、監査も容易になります。したがって、コンプライアンス要件を満たすのに役立ちます。

#4. センチネル

Sentinel は埋め込み可能なコードとしてのポリシー フレームワークで、ロジック ベースの詳細なポリシー決定を可能にし、情報に基づいた意思決定を行うために外部ソース情報に拡張できます。これは、開発およびテスト段階で役立ちます。

その他の優れたツールには、TruffleHog、Git-Secrets、Gitty Leaks、InSpec、Terraform などがあります。

結論

コードとしてのポリシーは、リソースの提供、アクセス制御、コスト管理、監査とコンプライアンス、セキュリティなど、さまざまな方法でビジネスに役立ちます。

この記事が、コードとしてのポリシーと、それを組織に実装する必要がある理由とその方法を理解するのに役立つことを願っています。

コードの品質を監査および管理するための興味深いツールをいくつか探索することもできます。

「 Policy-as-Code: 2023 年にそれを理解して実装する方法」についてわかりやすく解説!絶対に観るべきベスト2動画

Japanese Google Policy Office Hours(Google ポリシー オフィスアワー 2023 年 02 月 09 日)
Japanese Google Policy Office Hours(Google ポリシー オフィスアワー 2023 年 01 月 26 日)