Zenn
🎄

まとめ：情報セキュリティのDX

2021/12/25に公開
Rego
OPA
idea

メリークリスマス！ この記事はOPA/Regoアドベントカレンダーの最終日、25日目です。というわけでこのアドベントカレンダーもついに最終回を迎えました。今回は最後ということもあり、個別の技術の話ではなくメタな視点から改めてOPA/Regoについて振り返りつつ、Policy as Codeの発展の話などをしたいと思います。

OPA/Regoが活用できる領域

このアドベントカレンダーを始めるにあたって過去に執筆されたOPA/Regoの記事や発表、連携しているツールなどを調べましたが、 クラウドリソースのmiss configurationやポリシー違反を防ぐ という目的の内容が多く見られました。例えばKubernetesにデプロイされるリソースに関するポリシーを記述して、ポリシーに違反したリソースのデプロイを止めるためのGatekeeperや、terraformなどの設定情報を検査するConftestなどが挙げられます[1]。これはOPAがCloud Native Computing Foundationのプロジェクトとして成長してきたことにも強く関連していると思います。OPAの仕組みから考えても、近代的なクラウドの監視やInfrastructure as Codeの検査はたしかに相性がよい分野と言えるかと思います。

この他にも本アドベントカレンダーではいくつかのユースケースを紹介してきました。

このようにOPA/Regoが活用できる領域は狭くありません。現状では対応しているアプリケーション、システム、サービスはまだまだ少ないですが、今後様々な連携が各所で実装されていってほしいと考えています。一般的なプログラミング言語でももちろん同等のことは実現できるのですが、 ポリシーを書くことに専念できる という観点からOPA/Regoは Policy as Code を普及させていく一つの最適解なのではないかと考えています。

Policy as Code で得られること

Policy as Codeについてや具体的なメリットについては過去の記事でも紹介しましたが、もう一段上の視点からどのような効果が得られるのかを考えたいと思います。

セキュリティ関連業務の効率化

まず大きな効果として、繰り返し発生する手作業[2]を削減できます。リソース変更のレビューや監査的なチェック、セキュリティアラートの対応などで決まりきったものに人間が対応する必要がなくなります。1つの対応の数分、あるいは数十秒しかかからなかったとしてもこれは件数が増えると線形にコストが嵩んでいきます。特に組織やサービスがスケールした際に増えていくような作業だと、事業の拡大にともなって対応する人の時間を割くようになってしまい、最終的にその作業が組織全体のボトルネックになってしまいます。Policy as Code 化によって判断や対応が自動的に実施できるようになることで、例外的に対応しなければならないような事象に集中できます。

また、デプロイが自動化されることで作業のミスなどが減少するというのも業務の効率化に寄与しています。人手でやるデプロイ作業は事故が起こりやすく、根本的にミスを無くすのは困難です。さらに、事故が起きた場合に改善策としてダブルチェックで作業するように体制を変えたりすると、あまり効果がない[3]に上にさらに人手が必要になるという悪循環が発生します。これを避けて根本的にミスを無くすためにも、自動化による業務効率化の恩恵は大きいと言えます。

監査性の向上

やや副次的な効果ではありますが、Policy as Codeの運用にすることで監査に必要な情報も自ずと収集できるようになります。OPAサーバでもそうですが、どのような問い合わせがありどのような結果を返したか？ということはログとして記録できるため、判断に関する証跡を残すのが容易になります。また、ポリシー自体もいつどのような状態で、誰がいつどのような変更を加えたのか？ということもGitなどのバージョン管理ツールを使うことで記録できます。

このような監査に関する情報を人間が証跡を残すようにすると記録の漏れや勘違いがあったり、証跡を残すという手順そのものに負荷がかかってしまいます。監査自体をやりやすくし、かつ作業をするメンバーの負担も軽減することができ、結果としてこの特性も業務の効率化に寄与することになります。

積極的なポリシーの追加・変更

最後は過去の記事でも紹介しましたが、自動テストを用意して変更のたびにテストを実施することで、積極的にポリシーを変更しやすくなります。ポリシーは規模が大きくなっていくに連れ、相互干渉している部分がわかりづらくなり、変更した際にサイドエフェクトが発生しないか常に確認する必要があります。これを人手でやるとなると変更に伴うコストが規模に応じて増加し、徐々に変更を拒む力学が働くようになってしまいます。

「ポリシーは一度決めたらあまり変更しない」というのは幻想で、特に事業の状況を激しく変化させたいのであればポリシーもそれに伴って変化していかなければなりません。それができないと古いポリシーをいつまでも引きずることになったり、実態との乖離がでることでポリシーによって守られるものが守れなくなったり、ということが起こります。事業側の動きに適切に追従し、ポリシーを更新していける体制にすることで、セキュリティ関連のシステムや仕組みによる安全性の恩恵を受けつつ、ユーザビリティも損なわないような運用ができるようになります。

情報セキュリティDXの時代

このような Policy as Code によって得られる効果を一言で表現するなら「情報セキュリティのDX」なのではないか、と考えました[4]。DX（デジタルトランスフォーメーション）の定義は未だに混沌としており定まっていないと感じますが、個人的にはレガシーな領域が以下のようなステップによって変革することと捉えています。

  • デジタルネイティブ化によって、
  • ソフトウェアに労働力を移譲し、
  • 素早い変化と新しい挑戦ができるようになる

もともとのDXはレガシーな組織がデジタルネイティブ化するという意味かと考えていますが、情報セキュリティの領域として考えたときにレガシーな、つまり人手に頼ったものを システム化して人間の労働力を減らし、かつ変化し続けられる ものにしていくのはDXではなか、という発想です。また、事業の変化に対して積極的にポリシーを変えていける体制になることは、本来の事業側のDXにも大きく貢献するものであり、その観点からもDXと呼んで差し支えないのではと思います。

情報セキュリティの領域は当然ながら情報技術と密接な関わりがありますが、ソフトウェア・エンジニアリング、すなわちソフトウェアの力によって業務を効率化していくという文化から遠いものも多くあります。例えばセキュリティ監視やその分析、プロダクトや利用しているソフトウェアの脆弱性管理、監査によるログの検査やリソースの状況、権限のチェックなど、これらの多くは人間がぬくもりのある手作業で実施してきました。もちろん一定導入されたシステムなどは使いますが融通が効かなかったり柔軟な変更ができないものを無理やり使うというようなことになり、不便を強いられる場面も決して少なくなかったと思います。このようなことに時間をとられ、人々が消耗するということが度々あったのではと思います。

しかしこれは最近になってようやく転機が訪れたように感じています。セキュリティの問題をソフトウェアの力で解決し、セキュリティを専門とする人が本当に人間にしかできない、新しいチャレンジや未知の出来事の解決といったことに取り組めるようにしていける機運が各所で起こっています。OPA/Regoはその中の一つであり、これだけでレガシーな情報セキュリティの問題がすべて解決するわけではありません。ただ、本来であればソフトウェア開発で自分たちに必要な、組織ごとに異なるものを一式揃えないと問題が解決しなかったのに対し、ポリシーの部分だけを高い表現力でカスタマイズできるようになる、というのは一つの要素として重要なのではないか、と個人的に考えています。近い将来、セキュリティエンジニアの多くはソフトウェア開発のスキルを持つ、あるいはRegoに限らずですがポリシー記述言語を使って、様々な業務の問題を解決するような存在になっているのではないか、と想像しています。

ソフトウェアの力を使って機動性高く、かつ安全にスケールしていくようなセキュリティを実現するためには、ソフトウェアの要素だけではなく組織、文化、制度、世の中の潮流や社会全体などで超えなければいけない壁がいくつもあり、たどり着くのは容易ではないと考えています。しかしそこへ向かっていくチャレンジに意味はあり、このアドベントカレンダーでまとめた知識や情報がその一助になれば幸いです。

脚注

  1. ちなみにGatekeeperやConftestなどのポリシーチェックに関する話は先人の資料が多くあったこともあり、あえて今回のアドベントカレンダーでは触れず、汎用的な使い方や他のユースケースを実践してみた、という背景があります ↩︎

  2. Site Reliability Engineering の文脈ではトイル（Toil）と呼ばれるものです ↩︎

  3. https://www.igaku-shoin.co.jp/paper/archive/y2021/3433_01 によると効果がないどころか2人の方がエラー率が高くなるケースすらあるようです ↩︎

  4. 「情報セキュリティ自身のDX」であって「DXの情報セキュリティ」ではありません。念のため ↩︎

Discussion