ポリシー・アズ・コードとは何ですか?オープンポリシーエージェントの紹介

クラウドネイティブ時代においては、「セキュリティがなければ何もない」という言葉をよく耳にしますが、これはセキュリティが何よりも重要であることを意味します。

最新のインフラストラクチャとソリューションは私たちに大きなメリットをもたらしましたが、同時に、アプリケーション サービスが増えるにつれて、インフラストラクチャへのアクセスをどのように制御するかなど、心配する点も増えています。サービス間のアクセスを制御するにはどうすればいいですか?各人のアクセス権等

答えなければならない多くの質問の中には、安全に関する規則、基準、条件など政策に関する質問もあります。例えば：

このリソースにアクセスできるのは誰ですか?

どのサブネットからの出力トラフィックが許可されますか?

ワークロードをどのクラスターにデプロイする必要がありますか?

インターネットからアクセスされるサーバーではどのプロトコルが許可されませんか?

どのレジストリからバイナリをダウンロードできますか?

コンテナはどのオペレーティング システムを使用して機能を実行できますか?

システムにアクセスできる時間帯はいつですか?

すべての組織には戦略があり、それは法的要件の遵守、技術的制約内での作業、間違いの繰り返しの回避に関する重要な知識を明確に表現しているからです。

なぜポリシーをコードとして使うのか?

戦略は、組織の文化に浸透している明文化されたルールまたは暗黙のルールに基づいています。たとえば、私たちの組織に次のような明文化された規則があるとします。

インターネット上のパブリックサブネットからアクセスされるサーバーの場合、安全でない「HTTP」プロトコルを使用してポートを公開することはお勧めできません。

それで、どのように実装すればよいのでしょうか?

インフラストラクチャを手動で作成する場合は、「4 つの目原則」が役立つ可能性があります。しかし、重要なことを行うときは常に 2 人目の人が同行することが前提です。

インフラストラクチャをコードとして使用し、Terraform などのツールを使用してインフラストラクチャの作成を自動化する場合は、コードレビューが役立つ場合があります。

しかし、従来の政策実施プロセスにはいくつかの重大な欠点があります。

このポリシーが決して破られないという保証はありません。人間が常にすべてのポリシーを把握できるとは限らず、ポリシーのリストを手動でチェックするのは現実的ではありません。コードレビューに関しては、上級エンジニアであっても、毎回すべての潜在的な問題を見つけることは困難です。

現代の組織は俊敏性が高く、従業員、サービス、チームが絶えず成長しているため、セキュリティ チームが従来のテクノロジーを使用してすべての資産を保護することは不可能です。

遅かれ早かれ、人為的なミスによりポリシー違反が発生します。それは「もし」という問題ではなく、「いつ」という問題です。これが、ほとんどの組織がメジャーリリースの前に定期的なセキュリティ チェックとコンプライアンス レビューを実行する理由です。最初にポリシー違反を検出し、その後事後修正を作成します。

これはあまり科学的ではありません。では、戦略を管理し実行する正しい方法は何でしょうか?

ポリシー・アズ・コード (PaC) とは何ですか?

ビジネスとチームが成熟するにつれて、ポリシーを手動で定義するのではなく、エンタープライズ レベルでより管理しやすく繰り返し可能なポリシーに移行したいと考えています。

これをどうやって行うのでしょうか?まず、大規模な管理システムにおける成功した実験から学ぶことができます。

Infrastructure as Code (IaC): 環境とインフラストラクチャを定義するものをソース コードとして扱います。

DevOps: 人、プロセス、自動化を組み合わせて、エンドユーザーに継続的に価値を提供する「継続的なすべて」を実現します。

これらのアイデアから、Policy as Code (PaC) が生まれました。

ポリシー・アズ・コードは、コードを使用して、ルールと条件であるポリシーを定義および管理します。コードを操作し、ソース コード管理 (SCM) ツールを活用するためのポリシーを定義、更新、共有、および適用します。ポリシー定義をソース管理に保存しておくことで、変更を加えるたびにポリシー定義をテストし、検証してから適用することができます。 PaC の目的は、ポリシー違反を検出することではなく、違反の発生を防ぐことです。これにより、手動プロセスに依存するのではなく、DevOps の自動化機能が活用され、チームはより迅速に行動できるようになり、人為的エラーによるエラーの可能性が軽減されます。

ポリシー・アズ・コード vs. インフラストラクチャ・アズ・コード

「as code」運動は新しいものではなく、その目標は「すべてを継続すること」です。 PaC の概念は Infrastructure as Code (IaC) に似ているように聞こえるかもしれませんが、IaC がインフラストラクチャとプロビジョニングに重点を置いているのに対し、PaC はセキュリティ操作、コンプライアンス管理、データ管理などを改善します。

PaC を IaC と統合して、インフラストラクチャ ポリシーを自動的に適用できます。

PaC と IaC のどちらが良いかという疑問に答えたところで、次は PaC を実装するためのツールについて見ていきましょう。

オープン ポリシー エージェント (OPA) の概要

Open Policy Agent (OPA、「オーパ」と発音) は、Cloud Native Computing Foundation のインキュベーション プロジェクトです。これは、あらゆるドメインにポリシーをコードとして適用するための一般的なフレームワークを提供することを目的とした、オープンソースの汎用ポリシー エンジンです。

OPA は、ポリシーをコードとして指定できる高レベルの宣言型言語 (Rego、「レイゴー」と発音され、ポリシー専用に構築された) を提供します。そのため、マイクロサービス、Kubernetes、CI/CD、API ゲートウェイなどにわたってポリシーを定義、実装、適用できます。

つまり、OPA は意思決定とポリシーの施行を切り離して機能します。ポリシー決定を行う必要がある場合、構造化データ (JSON など) を入力として使用して OPA がクエリされ、OPA は決定を返します。

前提条件

開始するには、GitHub リリースからプラットフォーム用の OPA バイナリをダウンロードします。

macOS (64 ビット) の場合:

M1 Mac でもテスト済みで、動作します。

仕様

簡単な例から始めて、架空の給与計算マイクロサービスにアクセスベースのアクセス制御 (ABAC) を実装してみましょう。

ルールは簡単です。自分の給与情報または部下の給与情報にのみアクセスでき、他の人の給与情報にはアクセスできません。それがあなた自身のもの、またはあなたが働いている誰かのものであれば、次のものにアクセスできます: bob john

• /getSalary/ボブ
• /給与を取得/ジョン

ただし、ユーザーとしてアクセスすることはできません: /getSalary/alicebob

入力データとRegoファイル

構造化された入力データ（ファイル）があると仮定します：input.json

Rego ファイルを作成しましょう。ここで、コメントを読むと、このコードが何を行うのかがよくわかります。

ファイル: example.rego

走る

次の値は次のように評価される必要があります: true

input.json ファイル内のパスを "path": ["getSalary", "john"] に変更します。2 番目のルールにより、マネージャーは部下の給与を表示できるため、値は引き続き "true" になります。

ただし、入力 .json ファイルのパスを "path": ["getSalary", "alice"] に変更すると、結果は false になります。

ポリシー・アズ・コード統合

上記の例は非常に単純であり、OPA の仕組みの基本を理解するためにのみ役立ちます。しかし、OPA は強力であり、次のような今日の主流のツールやプラットフォームの多くと統合できます。

クベネフィット

特使

AWS クラウドフォーメーション

ドッカー

テラフォーム

カフカ

セフ

等

OPA の機能を簡単に説明するために、AWS 上の自動スケーリング グループとサーバーを定義する Terraform コードの例を次に示します。

この Rego コードを使用すると、Terraform プランに基づいてスコアを計算し、ポリシーに基づいて決定を返すことができます。プロセスを自動化するのは非常に簡単です。

terraform plan -out tfplan を実行して Terraform プランを作成します。

terraform show -json tfplan | jq > tfplan.json プランをJSON形式に変換する

結果を取得するには、opa exec --decision terraform/analysis/authz --bundle policy/ tfplan.json を実行します。