ビジネスとITの融合は日進月歩の速度で進んでいるが、昨今日本企業でも、サイバー攻撃の被害によるシステム障害で多大な損失を被った事例は増加の一途をたどっている。一方で、あらゆるステークホルダーが安全性を確保しながら、スムーズに自社システムにアクセスできる関係性構築は、ビジネスを成長させるためには不可欠なものとなっている。このようなアクセス制御の安全性と利便性は対立するようにも思えるが、現在のアクセス制御はどのような潮流を見せているのだろうか。
今回は、先日開催された「Developer eXperience Day 2024」のDay2で実施された、Okta Japan株式会社の池原大然氏のセッションをレポートする。
池原 大然氏
Okta Japan株式会社 プリンシパルデベロッパーアドボケイト
.NETエンジニアとしてキャリアをスタートさせた後、UIコンポーネントベンダーやクラウドコミュニケーションプラットフォームベンダーにおいてさまざまなロールを歴任。2023年3月よりOktaに参画し、日本市場における開発者リレーションを担当。趣味はゲームと長距離散歩。X (Twitter): @neri78
目次
ビジネスの成長と「アクセス制御」のあり方
生成AIの台頭をはじめ、テクノロジーの発展を遂げる現代はビジネスのあり方を大きく変えている。一方で、ビジネスとITが融合するにつれて、コアとなる自社システムへのアクセス制御の重要性が高まっている。このような現状に鑑みて、池原氏は現代を「“人”がビジネス成功に重要な要素になっている」と説明する。
「ここでいう“人”というのは、たとえば従業員や顧客、あるいはビジネスパートナーを指します。そういった方々が社会の中でさまざまな活動を行っていくうえで、ビジネスが成長していきます。従業員にとっては、一般的に毎日行われている、社内システムに入るためのアクセス権限を付与されることです。顧客にとっても、サービスを利用するための本人認証があります。これらはもはや日常の動作になっていると思います。ビジネスパートナーについても、たとえば自社の事業を手伝ってもらうためにシステムを解放するための認証があります。
このように、私たちは日々ビジネスを行ううえで、普段から認証や認可をユーザーとして日常的に使っています。この部分で、単純な本人確認だけではなく、ビジネスを成長させるためにさまざまな観点で気をつけなければならない状況が起きています」
ただ単にセキュリティ面だけを配慮するだけでなく、顧客体験を向上させるうえでの「アイデンティティ（認証と認可）」が必要だという。池原氏が所属するOktaでは「人のちからをビジネスのちからへ」を掲げ、それぞれの用途に合わせた安全なアイデンティティ管理を専業としたソリューションを提供している。
このような前提を踏まえ、池原氏は「認可とアクセス制御」をテーマに、認可と認証の違い、これまでの認可とアクセス制御の仕組みについて解説した。
「認可とアクセス制御」仕組みの現在地
まず、池原氏は認可と認証の違いについて以下のように説明する。
「認証はこれからサービスを利用しようとする人に対して、本人であると確認すること。認可はユーザーやクライアントに対して、リソースのアクセス権限を与えてよいかを判断する処理を指します。今回お話ししていく『アクセスコントロール』は、どちらかといえば認可についての話となります。実際にフォルダーやドキュメントにアクセスする、あるいはサービスを利用する。そういった権限にまつわるアクセス制御をする際に、認可の仕組みが使われています」
その一例として、池原氏はロール（役割）を元にしたロールベースアクセス制御（RBAC）の仕組みについて説明。これはグループやロールを組み合わせることによって、ユーザーが特定の処理をできるかを判断するものだ。
「たとえば、経費精算の処理において『上司は部下の経費精算を許可できる』といった権限を与えるとすると、上司のロールが経費精算を承認できる権限を持ちます。そうしたことから、実際のアプリケーションコードの中でも、現在ログインしているユーザーが持っているロールは何か、そのロールに合わせて処理の許可の可否を適用するようになっています」
一方で、このような状態ではapproval（承認）の権限を持っているユーザーはすべての経費精算の承認が可能になってしまう。そのため、より現実的な解としては、属性をさらに付与する方法が取られている。それが「属性ベースアクセス制御（ABAC）」だ。このように、日常的に使うアプリケーションは、追加のビジネス要件を付加したものが実装されている。
しかし、個々にロジックをちりばめるのは煩雑になる。そこで、現在は外部に「ポリシーエンジン」を実装し、アプリケーションがエンジンを呼び出すことで判断する手法が取られることが多いという。
「ただし、対象となるデータはデータベースから直接取り出す必要があります。ロジックの集約自体は可能になるものの、実際のデータはデータベースから取得するコードを記述する必要があります。ここで言いたいのは、それぞれの良し悪しの話ではなく、認可とアクセス制御にはさまざまな特徴があるという話です」
認可ロジックの課題とReBACの提案
池原氏は認可とアクセス制御の現状を踏まえたうえで、「現状の認可ロジックは、えてしてアプリケーションの中にハードコード、つまりデータや設定値がプログラムのコード内に直接書き込まれ、実行時には変更できないものが多い」と語る。
「実際に今開発しているアプリケーションの中でも、こういったアクセス制御を行いたい。ロールベースのアクセス制御を使っているけれど、さらに追加の属性でアクセス制御を行いたいという場合には、こういったハードコードされているパターンが多いと思います。私たちは、このようにハードコードされた認可ロジックに課題があると考えています。
たとえば、コードを追わないとどのように認可がされているのかがわからない。または実装者によってどこでコーディングがされているのかがわからない、あるいはちゃんと認可したことを確かめる監査ログをとることも難しくなるといった事態があげられます。結果として、新機能を追加する際に、そこでの認可ロジックや他への影響も考える必要が生じます。さまざまな面において、認可ロジックそのものをハードコーディングすることには課題があると考えています」
このように、ハードコードされた認可ロジックは技術的負債となり、新規機能の追加を遅らせるなど、プロダクトの成長を阻害することにもつながる。では、このような課題をどのようにクリアすべきか。それが本講演の主題である「関係性を用いたアクセス制御（Relationship-Based Access Control＝ReBAC）」だという。
「これはよりきめ細やかなアクセス制御や認可ロジック、認可のためのデータ集約を目的に開発されたものです。具体的には、さきほどのRBACやABACは、アクセス制御を判断する根拠としています。この関係性は、直接関係があるかやオブジェクトに関連するグループの一員であるか、または共有されているかによって判断されます。このように、関係性を持つデータを集約しておいて、質問に答えるようなかたちをとっています。
ReBACの場合は、現実で実装されているシステムでいえば、たとえばGoogleで提供されているGoogle DriveやYouTubeなどがあります。そういったところで共有や閲覧にオプションが付加されているのを見た経験はあると思います。その中で実装されている認可エンジン『Zanzibar』で、ReBACが実現されています」
ここで、池原氏はOktaがZanzibarについて解説したサイト「Zanzibar Academy」を参照しつつ、ReBACの特性について紹介。ReBACは、あらかじめどのような関係性を持つかを定義したうえで、オペレーションやトランザクションごとに記録し、その組み合わせによってアクセス制御を行っていく考え方だ。
一方で、ReBACのモデル定義は十分考慮する必要がある。たとえば、オーナーとエディター、ビューワーが独立した存在となっているモデルを参照した場合、ドキュメントのオーナーであっても編集ができないという場合になりかねない仕組みになってしまう。モデルを作成する際には、関係性をしっかりと定義する必要がある。
「たとえば、『オーナーはエディターでもあるし、エディターはビューワーでもある』という関係性を線でつなげる必要があります。しかし、このようなことをRBACでやろうとすると、それぞれのそれぞれの階層ごとにロールを付け加えなければなりません。しっかりとモデルにおける関係性を定義すれば、より複雑なアクセス制御が求められるものであればあるほど、ReBACを実装することが適しているといえます」
池原氏は「Zanzibar Academy」での例を示した後、それぞれのアクセス制御方式の比較を示しながら「重ねがさね、どの形式が劣っているかではなく、どのよな用途を求めていくかで実装を判断していただきたい」と強調した。
開発者体験の向上にも配慮した「OpenFGA」のデモを実演
池原氏はこれまで認可のアクセスの現状について解説した。では、実際のアプリケーションではどのようにシステムが組み込まれているのだろうか。今回、池原氏はReBACを実装するオープンソースの認可システム「OpenFGA」を取り上げ、具体的な使い方を説明した。
「OpenFGAを導入してReBACによる認可チェックを実現する場合、まずは2つのモデルを定義します。1つめは『Authorization Model』と呼ばれる1つ以上の関係性の組み合わせを定義、2つめは『Relationship Tuple』という、動的に変わりえる関係性を表すものです。OpenFGAはこの2つの定義された関係性をサーバーにリクエストすることで、認可ロジックと認可の元となるデータをソリューションの中で完結することが可能です」
ここで、池原氏は「関係性モデリング入門」と題して、Authorization ModelとRelationship Tupleの定義について、実際のOpenFGAのデモを使用しながら実演した。
そのうえで、OpenFGAを導入することによって開発者体験がどのように向上するのかについて、池原氏は以下のように説明する。
「これまでお話ししたように、OpenFGAはReBACを適用したきめ細やかな認可が可能な認可エンジンです。加えて、モデルを構築したり、モデルを呼び出すプロセスにおいて、開発者体験を向上させるいくつもの仕組みを提供しています。
たとえば、DockerやKubernatesの環境にどのようにデプロイできるかのガイドが用意されているほか、ローカルでのセットアップも可能です。そして、今回デモでもお見せしたように、最初はモデリングの仕組みの理解や実際にクエリを投げてみるといった構築の段階では、少し時間がかかったり作法を学ぶ必要があります。それをサポートするために、OpenFGAでは視覚的なPlaygroundを用意しています。これによってモデリングやテストの結果を可視化させています。
そして、モデリングをサポートするための専用言語として、Domain Specific Language（DSL）を定義しています。実際にAPIを呼び出す場合にはJSON形式をとりますが、そのままではコードが非常に長くなってしまうので、専用のモデリング言語を使うことによって開発者の負担を軽減しています」
さらに、OpenFGAは設定と認証をサポートするコマンドライン・インタフェース（CLI）やVS Codeエクステンションを用意することで、実際の肝となるモデリングの部分でシステムからサポートを受けられる仕組みになっているという。池原氏はそのような利便性を講演中に実演しつつ、ReBAC適用に関しての注意点を説明し、講演を締め括った。
取材後記
認証やアクセス制御の重要性は高まっているものの、ガバナンスとしての側面が偏重される向きがある。池原氏の講演は、ビジネスの成長と安全性、さらには開発者体験にも考慮された最新潮流を紹介するものだった。池原氏が述べる通り、方式の適用は自社サービスの状況に鑑みて選定する必要はあるものの、現状実装しているアクセス制御の方式を棚卸しする契機となるものであった。
（取材／文：川島大雅）
