2024.12.03
セキュリティ製品を入れても検出されず…被害事例から見る最新の攻撃トレンド 不正侵入・悪用を回避するポイント
リンクをコピー
記事をブックマーク
鈴木研吾氏:そんな中で今日は具体的に取り上げて持ってきたものが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もポリシーに従って物事を進めていく上で、これをサステナブルなものにするためにはちょっと捻って工夫をする必要があります。
その中の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室 鈴木研吾からの発表を終わります。みなさま、ご清聴ありがとうございました。
関連タグ:
2024.11.29
「明日までにお願いできますか?」ちょっとカチンとくる一言 頭がいい人に見える上品な言い方に変えるコツ
2024.11.28
管理職の「疲弊感」がメンバーに伝わるリスク 部下の「働きがい」を育む6つのポイント
2024.11.27
何もせず月収1,000万円超…オンラインゲームにハマって起こした事業 大学中退し4社立ち上げ・2社売却した起業家人生
2024.11.27
部下に残業させられず、自分の負担ばかり増える管理職 組織成長のカギを握る「ミドル層」が抱える課題
2024.11.26
タスクの伝え方が部下のモチベーションを左右する マッキンゼー流、メンバーが動き出す仕事の振り方
2024.11.25
仕事はできるのに、なぜか尊敬されない人が使いがちな言葉5選 老害化を防ぐために大切な心構えとは
2024.12.03
職場の同僚にイライラ…ストレスを最小限に抑える秘訣 「いい人でいなきゃ」と自分を追い込むタイプへの処方箋
2024.11.28
“新規事業が生まれない組織”に足りていないもの 「PoC貧乏」に陥らず、アイデアを形にするためのヒント
2024.11.29
やたらと多い自慢話、批判や噂好き…「自己重要感」が低い社員の特徴 管理職が知っておきたい「一生働きたい職場」の作り方
2024.12.02
給料や人間関係が良いだけでは部下は満足しない メンバーの「働きがい」を育む5つのステップ