ITガバナンスのコード化　〜ONUG Spring 2023 レポート〜

前編では 、ONUG 2023 Spring にて語られた企業ITネットワークの遍歴とクラウドシフトによって求められる「企業ITのテクノロジー消費モデルへの移行」について紹介しました。

本記事では、 ONUG 2023 Spring で語られたもう一つのトピックである「Policy as Code」と関連してネットワンがどのような取り組みをしているかをご紹介します。

Policy as Code　とは

企業がテクノロジー消費モデルに移行するに伴い、広範囲のシステム・サービスを管理しガバナンスを効かせる必要が出てきますが、これらのサービス群一つ一つを制御しようとすると運用が煩雑になるとともにビジネスアジリティは鈍化してしまいます。

近年ではそのようなITガバナンスをポリシーとして対象に適用しコードとして管理するための 「Policy as Code」 という考え方が浸透してきています。

ONUG ではそのようなガバナンス制御を実現するための 「Policy as Code WG」 が存在しており、カンファレンス内でもディスカッション等を通じ議論がされていました。

Policy as Code WGの2023年活動ロードマップ

「Policy as Code」 というキーワードが企業にとって浸透してきたのは近年のことであり、まだバズワードの域は超えていません。そのため用語の定義やベストプラクティスなどに関しても人によってバラバラであり、ワーキンググループ（以下、WG）としてはそれらの整理に注力するとのことです。
具体的に以下のようなアクションを想定しています。

• Policy as Code に関連する用語の整理
• ニーズに合わせたクイックスタートガイドの開発
• 機能参照アーキテクチャの開発

また、WG としてもテクノロジー消費モデルへの移行を強く意識しており、その際にどのようなユースケースが考えられるか、Policy as Code 適用のためのベストプラクティスはどのようなアプローチが考えられるかという点にフォーカスしていくようです。

WGとしてはこれらの Policy as Code を推進するためのガイドを整理した後、リファレンスアーキテクチャの開発や 3rd Party ツールの選定ガイドなど、よりユーザーの実際の利用シーンを想定した情報の公開を目指しています。

Policy as Code はビジネスをどうドライブするのか？

では、実際の海外のベンダーやユーザーは Policy as Code というアプローチをどれだけ実ビジネスに適用している、または期待しているのでしょうか?

世界的な医療サービスを提供する Cigna 社は、過去のクラウド移行においてセキュリティチームとクラウドチームの綿密な連携の重要性に気づきました。反面、互いの利用しているフレームワークやポリシーにはギャップがあり、Policy as Code というアプローチでこれらのフレームワークやポリシーを統一できるのではないかと期待を寄せています。

ネットワークベンダーである Cisco 社は、このような組織間の連携は重要だとしながらも DevOps としての観点では都度連携を取っていてはアジリティの課題に直面するとし、セキュリティポリシーなどを CI/CD に組み込むことで開発者のスピードを損なうことなくガバナンスを効かせられる「ガードレールアプローチ」として好意的なコメントがされていました。

Citi Bank では実際にオープンソースのソリューションである Open Policy Agent(OPA) を利用し PoC を進めており、ポリシーによるガバナンス制御、コンプライアンスレポートの自動生成などを実現しています。

Policy as Codeの課題について

このように一部のユーザーにより実際のビジネスにも適用されている Policy as Code ですが、適用していく中で様々な課題が見えてきました。

・適用対象が多い

実際のインフラストラクチャにおいては、クラウド、コンテナ、デバイスなど様々な管理対象が存在し、どれも Policy as Code の適用対象となり得ます。そのため、システム全体像を把握するにはポリシーの集約をする必要がありますが、その場合 Policy as Code を実現するシステムが複雑化する懸念があります。

・スケーラビリティの課題

Policy as Code では中央集権型でポリシーを定義しますが、実際にポリシーの適用・制御する箇所は複数におよぶためスケーラビリティも懸念点として挙げられています。

・従来の組織文化が適用できない

Citi Bank では実際にポリシーを検討するセキュリティチームとコードを書くエンジニアリングチームが別で存在しており、セキュリティチームがコードを書くか、エンジニアリングチームにポリシー設計をする権限を与えるかの選択に迫られました。そのため、このような組織上の課題を解決するために十分なトレーニングや組織文化の変容が企業において Policy as Code を推し進めるのに必要であるとコメントしています。

ネットワンの取り組み

これまで ONUG での Policy as Code の取り組みを紹介しました。

ネットワンシステムズでは、マルチクラウドの利用が進み、企業のテクノロジー消費モデルに移行するにあたりセキュリティはもちろんのこと消費コストに関してもコントロールする必要があると考え、クラウドにおけるコスト・リソースガバナンスを目的とし Open Policy Agent(OPA) と CI パイプラインで実現し、実際のインフラ開発プロセスに適用してみました。

今回は、 IaC として Terraform にて AWS リソースを定義し、内部では VPC, EC2, ELB, S3 といった様々なリソースをコードとして管理しています。

これに対して OPA のポリシーでは許容するインスタンスタイプやボリュームタイプ、リソース構築後のコスト分析を目的とした必須タグ等のチェックルールが定義されており、ポリシーに違反していないかをチェックしてみます。

OPA によるポリシーチェックは手動で行うことも可能ですが　CI/CD のパイプラインに組み込むことでポリシーによるチェック機構を開発のプロセス内に適用することができ、IaC の変更とポリシー違反を容易に結びつけることができます。

また、チェックするポリシー毎にパイプラインのタスクを分割することで、並列で各ポリシーチェックを実施しかつどのポリシーに違反しているかの視認性を高めることができます。

実際のデモの様子は動画がありますので合わせてご確認ください。

まとめ

本記事では、ONUG における Policy as Code に対する取り組みや実際のユースケースから見えてきたメリットや課題、そしてネットワンとしての取り組みをご紹介させていただきました。

Policy as Code は「企業がテクノロジー消費モデルにシフトする中でガバナンスを保ちながらビジネスアジリティを高めるアプローチ」と言えますが、まだまだ課題も残ります。

ネットワンシステムズとしても、今回デモでご紹介したようなコスト・リソースガバナンスに関してのコード化を推進し、その中でインフラ管理者の負荷軽減を実現するための手法を検討していきたいと思います。

※本記事の内容は執筆者個人の見解であり、所属する組織の見解を代表するものではありません。