LayerXならではの「ゼロトラスト」を実現するために
“サステナブルな運用”を目指した権限管理とポリシー管理

権限管理の調整

鈴木研吾氏：そんな中で今日は具体的に取り上げて持ってきたものが2点あります。1つが権限管理で、もう1つがポリシーの浸透と継続というところになります。

（スライドを示して）1つ目の権限管理がこのスライドです。

先ほどお見せしたとおり、今までだとアクセスしようとしている主体が属するオブジェクトを特定のグループに入れて、そのグループに所属していればOKみたいなかたちにしていました。

だけどそうすると、グループに対するメンテナンスが恒常的に発生します。恒常的に発生するということは、グループの数ごとに調整する必要があるということです。かつ、グループはほぼスタティックなものなので、やるとなると、人間がそこにスタティックな値であるユーザー名とかをポチポチ入れて、それを見ながらやらなきゃいけない。ちょっとスケールしにくい仕組みになっているかと思います。

（スライドを示して）これをより動的な方向に変えようとしているのがこの図のところですね。具体的に言うと、ユーザーとかのリソースに属性を定義して、その属性をポリシーが見て、ポリシーが次のアクションを決定するところに変えようとしています。

内容としては、もちろんそのグループに追加することもあるし、そもそもグループを経由しないでリソースへのアクセスを制御するような考え方もあります。

このあたりの属性を付与したアクセス制御は特段新しい話ではなくて、Attribute Based Access Control（ABAC）と呼ばれていたりします。もちろんこの場合、誰がどうポリシーを管理するのかとか、属性をどう定義するのかの話があるのでそこはまだ審議中、かつ恐らくこの1年ぐらいで徐々に整えていくことになるかと思います。

ポリシー管理の調整

もう1点は、2つ目のポリシー管理です。CNCF（Cloud Native Computing Foundation）的なところだと、OPA（Open Policy Agent ）とか、Terraform Cloudで提供されているようなSentinelみたいなポリシーがパッと思い付くと思いますが、どちらかというとお話したいポリシーは統制的なポリシーです。

内部統制的な話だと、基本的に一番上に法令や業界標準とかがあって、そこに基本ポリシーがあって、その下にスタンダードなガイドラインみたいなものができて、それを具体的に適用するプロシージャみたいなものがあります。

個人的に、OPAは基本的に実装とかログの内容から見て「正しい手順とか標準に従ってやっていますよね？」ということをチェックするようなものだと認識していますが、今回お話しするのはもうちょっと抽象的な基本ポリシーみたいなところになります。

なにかしらのグループに所属している場合、恐らくみなさんそういったポリシーがあると思います。ドキュメントとかPDFで特定のフォルダに置かれているようなものが想定されると思いますが、それが（思い浮かべるものとして）正しいです。そのポリシーですね。

基本的に伊達や酔狂でやっているものではないはずで、下位文書であるスタンダードやプロシージャに影響を与えて、一貫性を持って組織としてのガバナンスを保つための最上位文書という意味では非常に重要なものになっています。

ただ、現在のポリシーに関してはたくさん規制がありますし、それに伴って規制を組み合わせるとどうしても矛盾や管理の複雑さが出てきちゃいます。同時に、そういった規制は更新が必要になってきて、結果、ペーパーワークの工数増大によって「これは誰が何のためにやっているんだっけ？」みたいな状態になってしまうことがけっこう多いかと思います。

そういった意味で、LayerXもポリシーに従って物事を進めていく上で、これをサステナブルなものにするためにはちょっと捻って工夫をする必要があります。

「OSCAL」の実践と検討

その中の1つとして当社でデモ的に試してみたものが「OSCAL」というものです。Open Security Controls Assessment Languageというもので、情報システムのセキュリティ対策を定義して、それに基づいて評価するための評価フレームワークです。これについては、先ほど紹介したNISTというものが作っています。

具体的に言うと、このように複数のレイヤーがあります。（スライドを示して）一番上のAssessment Layerは評価するためのレイヤーで、どんなものをアーティファクトとして保存するかみたいなものが書いてあります。

Implementation Layerは対策、コントロールをどのようにシステムに定義するかが書いてあります。Control Layerというものも、世の中にある標準がカタログとして書かれて、それをプロファイルとして組み合わせるようなものです。

ちょっと文字が小さくて恐縮ですが、カタログはこのように世の中にあるものを定義するようなJSON形式になっていて、

プロファイルはそれを企業独自にカスタマイズしていくもの、

それをコンポーネントに落とし込むということですね。ここでは「MongoDB」と書いてあります。「MongoDBにおいてこういった情報資産はプロトコルで、こういうものがあるから、実装Implementationとしてはこのプロファイルを使いたいですよ」みたいなことがJSONとして書かれています。

それをセキュリティプランに落とし込むかたちになっています。これ自体を当社は試してみましたが、JSONがメチャクチャ大きくなってなかなか管理が難しいというところで、恐らく採用はしないと思います。

少なくとも、今誰が何のためにやっているのか、どういう経緯でそうなっているのかがわかり辛くなっている最上段にあるポリシーと、実際にシステムとして動いているもののギャップを埋めようとする努力の（わかる）ものが最近ではちょいちょいと出てきているような気がしています。

トップやボトムという言い方は好きではありませんが、これによって1回シフトレフト（する）だけではなくて、全体におけるガバナンス強化につながってきているということになっていると思います。

そういった意味で今後、当社としてはこうした実装の部分だけではなくて、ガバナンス、ポリシーのところから実装まで強固にやって、できるだけエビデンスが残るようなかたちでサステナブルに社内で提供していきたいと思っています。

ゼロトラストは適宜変えていく必要がある

まとめとして、ゼロトラストは考え方です。各組織はその考え方に基づいてセキュリティ対策をしていきます。LayerXでは早い段階から取り組んでいましたが、ゼロトラストは組織のかたちによっても変わりますし、環境によっても変わるので、適宜変えていかなければなりません。

そのための課題の1つに内部統制的なポリシーの継続的な運用があるんですが、今後そういったところへの取り組みも増えていくのではないかと思っています。

以上でLayerXのCTO室 鈴木研吾からの発表を終わります。みなさま、ご清聴ありがとうございました。