ユーザー権限を Graph Database で管理する

17447 ワード
oracle Database graph oracle テキストリンク

はじめに

この投稿は英語ブログの記事 Case Study: Manage User Privileges Using a Graph の日本語版です。

柔軟なアクセス・コントロールとセキュリティを両⽴する必要性から、グラフ・データベースの活⽤の可能性が注⽬されています。ユーザーの属する権限グループを多段階に構成した場合でも、グラフを使うことで、あるユーザーの上の階層の権限グループを全て辿って確認するといったことが簡単にできます。

⼀例として、AMENIDY の Cybele Safe Mail というサービスは、⾼度な暗号技術とデータの受け渡し情報を管理するデータベースを⽤いて、メールの添付ファイルを⾃動的に暗号化するソリューションです。このシステムでは、グラフに対する宣⾔的クエリといったグラフ・データベース機能、数⼗億エッジのグラフに対する安定したスケーラビリティ、加えてデータベースの確⽴されたセキュリティ機能が必要であることから、Oracle Database の Property Graph 機能 が活⽤されています。

この記事では、メールの送受信という関係性をグラフ・データベースを⽤いて管理する際の、基本的なアイディアを説明します。ユーザーへのインタビューを元に書き起こしたものであるため、実際のシステムの動作や、データモデル、クエリの内容はここに⽰されているものとは異なりますので、ご了承ください。実際のシステムではより多くの関係性や条件を考慮する必要があるため、グラフを使った直感的なモデルやクエリが更に活躍すると推測されます。

グラフの構成

ここで仮定するグラフでは、ユーザーとそのユーザーが属するグループ、ユーザーが送ったメールとそこに添付されたファイルがそれぞれノードとして扱われます。

さらに、メールからはひとりの送信者と複数の受信者（ユーザーの場合もあればグループの場合もあります）にエッジが張られることで、そのメールの送受信の情報が格納されます。

グラフにノードやエッジを追加する

まず、メールが送信されたときの動作を考えてみます。あるユーザーが3つの添付ファイルを持つ1通のメールを送ったときには、以下の2つの PGQL クエリが発⾏されると想定できます。PGQL クエリの記法については https://pgql-lang.org/ を参照してください。
はじめの PGQL クエリは、ユーザー user_01 に1つのメール・ノードを追加しています。このノードはラベルを mail とすることで、それがメール・ノードであることを⽰しており、さらに名前が mail_01 であるというプロパティを加えています。エッジのラベルは sent_by となっています。

INSERT VERTEX v LABELS (mail) PROPERTIES (v.name = 'mail_01'), 
       EDGE e BETWEEN v AND u LABELS (sent_by) 
FROM MATCH (u:user) WHERE u.email = '[email protected]'

次の PGQL クエリは、先ほど追加されたメール・ノードに添付ファイル・ノードを3つ追加しています。

INSERT VERTEX v1 LABELS (attachment) PROPERTIES (v1.name = 'attachment_01'), 
       VERTEX v2 LABELS (attachment) PROPERTIES (v2.name = 'attachment_02'), 
       VERTEX v3 LABELS (attachment) PROPERTIES (v3.name = 'attachment_03'), 
       EDGE e1 BETWEEN v1 AND m LABELS (attached_on), 
       EDGE e2 BETWEEN v2 AND m LABELS (attached_on),        
       EDGE e3 BETWEEN v3 AND m LABELS (attached_on) 
FROM MATCH (m:mail) 
WHERE m.name = 'mail_01';

この時点で作成されたグラフは次のように可視化することができます。

さらに、このメールがどのユーザーに対して送信されたかを格納します。送信先ユーザーがこのデータベースに含まれていない場合には先に追加しておく必要があります。次の2つの PGQL クエリでは、ある送信先のユーザー・ノードがあるグループに追加され、そのユーザーとメールにエッジを追加しています。送信先のユーザー・ノードを作成し、グループ・ノードに belongs_to エッジで接続します。

INSERT VERTEX v LABELS (user) PROPERTIES (v.name = '[email protected]'), 
       EDGE e BETWEEN v AND g LABELS (belongs_to) 
FROM MATCH (g:group) 
WHERE g.email = '[email protected]'

メールノードから、新たに追加されたユーザーノードに sent_to エッジを追加しています。

INSERT EDGE e BETWEEN m AND u LABELS (sent_to) 
FROM MATCH (m:mail), MATCH (u:user) 
WHERE m.name = 'mail_01' AND u.email = '[email protected]'

グラフ上のつながりを確認する

メールの受信者は添付ファイルの開封時にサーバーから鍵を取得します。そうすることで、ユーザーは暗号化されたデータとその鍵を別々の経路を使って安全に⼊⼿することができます。
このときサーバー側では、次のようなクエリを⽤いてこのユーザーにメールが送信されたかどうかを確認します。

SELECT m.name FROM MATCH (a)-[:attached_on]->(m)-[:sent_to]->(u) 
WHERE a.name = 'attachment_01' 
  AND u.email = '[email protected]'"

JShell 上で出⼒される結果：

+---------+ 
| NAME    | 
+---------+ 
| mail_01 | 
+---------+

レコードが返されればパスが存在していることを意味します

もしもメールがユーザではなく所属グループに送信されたものであれば、グループ・ノードを辿ることでそれが確認できるはずです。このメールの送信先を変更してみましょう。
まずは、sent_to エッジを削除します。

DELETE e 
FROM MATCH (m:mail)-[e:sent_to]->(u:user) 
WHERE m.name = 'mail_01' AND u.email = '[email protected]'

グループ・ノードに向けて、再度新たな sent_to エッジを作成します。

INSERT EDGE e BETWEEN m AND g LABELS (sent_to) 
FROM MATCH (m:mail), MATCH (g:group) 
WHERE m.name = 'mail_01' AND g.email = '[email protected]'

MATCH 句のパターンにグループ・ノードを含めて検索すると正しく結果が返されます。

SELECT m.name 
FROM MATCH (a)-[:attached_on]->(m)-[:sent_to]->(g)<-[:belongs_to]-(u) 
WHERE a.name = 'attachment_01' 
  AND u.email = '[email protected]'

JShell 上で出⼒される結果：

+---------+ 
| NAME    | 
+---------+ 
| mail_01 | 
+---------+

レコードが返されたのでパスが存在しています

グループノードが不特定数の階層を持っていた場合でも到達可能性を確認できます。例えば、次のクエリでは5階層までを遡り、これらのグループノードがメールノードにつながっているかどうかも確認することができます。

SELECT m.name 
FROM MATCH (a)-[:attached_on]->(m)-[:sent_to]->(g)<-/:belongs_to{1,5}/-(u) 
WHERE a.name = 'attachment_01' 
  AND u.email = '[email protected]'

まとめ

この記事では、メールの送受信というユーザー・アクティビティを Oracle Database の Property Graph 機能を使って管理する例を紹介しました。グラフにより多くの関係性や条件を持たせることによって、メール以外のユーザー間のアクティビティを格納することもできますし、添付ファイルの開封期限をノードやエッジのプロパティに持たせて制御する、といった拡張も容易です。様々なサービスにおいて、柔軟なアクセス・コントロールがより迅速に導⼊できるようになることが期待されます。

リンク