マイクロサービスなアーキテクチャで権限制御を考えている
最近業務で権限制御を設計しているので調べたり考えたりしているのでメモ
前提
- 現存してるアプリケーションについて
- これから作るアプリケーションについて
調べたこと（基礎編）
まず自分自身が権限制御について詳しくないので設計パターンを調べたり考えたりした
Computer security model(Wikipedia)
Computer security model - Wikipedia
典型的な権限制御パターンが列挙されている。
全部読もうかと思ったけど英語なので時間かかる・Webアプリケーションとして利用できるパターンはこの中の一部っぽい雰囲気だったので深追いはしてない
アクセス制御（Wikipedia）
アクセス制御に関する基本的な概念がまとまっている
機密性・完全性・可用性という情報へのアクセス制御の基本的な要件や、認証・認可・監査というアクセス制御を実現するためのステップ、トークンに基づいたアクセス制御など一通りのアクセス制御に関する情報がまとまっている
個人的には↓の内容は知らなかったのでなるほどになった
- アクセス制御において主体と対象をそれぞれsubject/objectと称すること
- 「機密性・完全性・可用性」という概念
- 認証・認可だけでなく監査もアクセス制御として考えるべきものであること
オペレーティングシステムのアクセスコントロール機能におけるセキュリティポリシーモデル
https://www.ipa.go.jp/files/000002266.pdf
IPAの資料
「OSの」という題目だけど、アクセス制御についての要件が書かれていて一般論として参考になる
セキュアOSでアクセスコントロールを実現するためにはリファレンスモニタ・セキュリティポリシーモデルという概念が明確に定義・実装されている必要があるという内容があり、これは考え方としては一般的なWebアプリケーションにも流用できそうだなとか思った
リファレンスモニタというのはコンピュータ上の全てのobjectへのアクセスをコントロールするもので、subjectのobjectへの操作は全てこのリファレンスモニタを通さなければならない、というもの
Webアプリケーションで実装する場合全てのリソースへの操作を集約するというのは簡単ではないのでそのまま流用は難しいが応用したいなとは思う
例えば典型的なライブラリだと実装者が明示的に「このリソースへのアクセスが許可されているか？」を判定するコードを各所に記述するパターンが多い （ cancancan、casl、casbinなど）し、実際のところ単機能のライブラリとして提供できる範囲だとこれが落とし所だろうから、それを踏まえてアプリケーションの実装レベルのアーキテクチャを考えるときにリファレンスモニタの考え方を参考にする、になるのかな
セキュリティポリシーモデルは、「どの主体が、どの対象物を、どのように操作できるのか」を定義し、この定義されたセキュリティポリシーは数学的に検証可能であることが要求される（必ずしも実現可能ではないが）、というもの
資料内でセキュリティポリシーモデルの典型例を紹介してくれており、Bell-LaPadulaのような歴史のあるモデルからRale Base Access Control(RBAC)のようなWebアプリケーションでもよく利用されるパターンまであるので大変ためになる
（各モデルが数学的に検証可能かどうかについて言及がないので自分は結局「セキュリティポリシーモデルが数学的に検証可能であること」についてどういうことなのかピンとは来ていない）
Webアプリケーションでは殆どのケースでRBACあるいはその発展型のAttribute Base Access Control(ABAC)で賄えるので各セキュリティポリシーモデルを理解するのは直接的に役に立つわけではない感じもする
ただ、仮に良いライブラリがなくて自分でRBAC、ABAC相当の実装を記述しようと思ったときにこの 「どの主体が、どの対象物を、どのように操作できるのか」を定義し、この定義されたセキュリティポリシーは数学的に検証可能であることが要求される という点を前提にしてコードを書くと品質を高められそうだなとは思う
それらの実装に対してユニットテストを書く際もProperty based testingや形式手法を用いることによって「数学的に検証可能」という点を意識しながら書けるのかも？とかとか
調べたこと（権限のアプリケーションレベルでの設計）
実装レベルの設計を考えたいのでその観点で調べたこと
業務システムにおけるロールベースアクセス制御
RBACの解説とDB設計・Javaによる実装例が書かれている
実装例よりもその手前のRBACを実際に実装に当てはめるときに気をつけるポイントが参考になった
ロールとパーミッションは別物であることを意識するべき・組織とロールを結合させてはいけないなどの考え方は意識してないと漏れそう
アプリケーションにおける権限設計の課題
基礎のおさらいから実装面でどうすれば？という点まで言及されている
実装を考える場合に権限を「管理」「判断を下すサポート」「判断を下す」「適用」というパーツがあり、これらの責務を明確にしながら実装すると良いという話をコードやモノリシック・マイクロサービスアプリ上での責務分離の例を交えながら解説してくれている
IAMとは（AWSドキュメント）
アプリケーションにおける権限設計の課題 の記事でも言及されていたが、IAMは大抵のWebアプリケーションにおいて要件の最大値として考えておけばいいと思う
調べ始める前にもIAMをベースに考えればいいかなとか思ってはいた
実際のアプリではパーミッション（IAMで言えばポリシーステートメント）はハードコードで十分だと思うのでそこは要件から落とす、などすればよいのかなと考えている
マイクロサービスで管理画面が乱立する問題と対策
タイトル的に関係なさそうに見えるけど中では認証・認可の話題が殆どだったのでめっちゃ参考になった
マイクロサービスアーキテクチャにおいて権限管理をどういう方針で実施し、どんな課題を解決（しようと）したかが書いてある
今回検討してる内容とまさにピンポイントで合致する話題だったので大変ありがたかった
権限を中央に集約するか各アプリケーションで持つかはこの記事を書いてる今も悩んでいることなのでまだまだ考えたいところだがこの事例は思考の起点にさせてもらっている
余談だけど社内で利用言語・FWが統一されてると一個ライブラリ作れば簡単に横転できていいな〜とは思ったりした
調べたこと（ライブラリ編）
Node.jsで利用できる権限制御ライブラリを探した
casbin
ロゴがGopher君だけどGo言語以外にも展開されている
Supported Models を見るとABACに対応してるので検討しても良かったがDSLによって権限を記述するのがちょっと嫌だった・可能ならフロントエンドでも使いたかったがcasbin.js がかなり怪しげだったので見送り
role-acl
メソッドチェインで権限を記述できてTypeScriptフレンドリーな感じのAPIで良さげ
ただ、 Role, Attribute and conditions based Access Control for Node.js とあるようにNode.js向けっぽいので惜しい
casl
Features に書いてある Isomorphic TypeSafe Tree shakable Declarative の時点で気に入ってしまったし、 Versatile の項目にある通りABACやれまっせとのことなので要件としても満たされる
実際に書いて試してみているところだが、やりたいことを実現するには必要十分でSPA向けのコンポーネントまで提供されてて至れり尽くせり
今の所本命
とりあえず現時点で調べたことをガーッと並べただけなのでオチとかはない
前提の欄を設けてみたけどいらなかったかも、と最後まで書いて思ったけどまあ供養ってことで残しておく
caslの使い方とかAuth0の使い方とかそのうち気が向いたら書きたい気もする
