2011年12月28日水曜日

コンピュータシステムのアクセス制御における、2つの文脈


システムのアクセス制御といったとき、大きく2つの文脈に分けられます。オペレーティングシステムの分野における伝統的なアクセス制御と、企業内の情報システムにおけるアクセス制御の2つです。

後者は前者からの派生でありもちろん両者には関係性があるのですが、前者は悪意を持った攻撃者への対策という観点が主である一方、後者は複雑な組織内での適切な権限割当てという観点が大きくなっています。

オペレーティングシステムにおけるアクセス制御
タネンバウムの「モダンオペレーティングシステム」では、オペレーティングシステムのファイル保護機構は以下の3つが紹介されています。
  • 保護ドメイン
  • アクセス制御リスト
  • ケーパビリティ
保護ドメインは任意アクセス制御(Discretionary Access Control; DAC)、アクセス制御リストは強制アクセス制御(Mandatory Access Control; MAC)ともいわれます。

DACとMAC
従来のオペレーティングシステムにおけるアクセス制御として、DACとMACがあります。

DACはもともと、ユーザをお互いから守るように設計されていました。ファイルのようなオブジェクトの所有者が、そのオブジェクトへのパーミッションを指定できるという仕組みです。パーミッションは、そのオブジェクトがアクセスされるときに、OSによってチェックされます。

ところが、DACには脆弱性があります。root権限のような特権がアクセス制御を迂回できてしまうため、システムをクラックされて特権を取得されると重要なファイルを書き換えられてしまう可能性があるのです。これは、リソースの所有者とそのリソースへのアクセス権限設定者が分離されていないことによる問題です。

MACは、そういったDACの弱点を補い、システムのセキュリティポリシーを強化するよう設計されました。システム管理者がポリシーを決め、そのポリシーがOSのカーネルのあちこちに埋め込まれたフックによってチェックされます。

ケーパビリティ
DACやMACは、リソースに対してセキュリティレベルを設定するという考え方に基づく仕組みです。一方、プロセスに対して最小限のアクセス権限を与えることでシステムの安全性を高めるという考え方があります。それがケーパビリティです。

たとえば、UNIXにおけるプロセスには、一般ユーザ権限で動くものと特権で動くものがあります。もし、特権で動いているプロセスに脆弱性があった場合、不正な操作によりプロセスが持っている権限を取得されてしまう可能性があるのです。

この問題を解決する方法がケーパビリティです。特権をさらに細分化したケーパビリティと呼ばれる単位で取り扱えるようにし、プロセスに最小限のケーパビリティのみを与えて必要な処理のみを行わせるというものです。

この仕組みにより、もしプロセスに脆弱性がありそれが悪用されたとしても、そのプロセスが必要とする最小限のケーパビリティしか奪われないため、被害の範囲を狭めることが可能になります。プロセスが自らジェイルに入るようなものです。

ケーパビリティはこれまで、一部のセキュアOSでのみ使われていましが、最近の動きとして、Capsicumというケーパビリティ機構がFreeBSD 9に搭載されます。あらゆるシステムがインターネットに繋がれるようになる中、予期せぬ脆弱性からシステムを守るため、ケーパビリティのような保護機構の必要性が高まっているといえます。

企業内の情報システムにおけるアクセス制御
1990年ごろまで、軍事システムでMACが利用される一方、企業や行政組織ではMACではなくDACが適しているとされていました。しかし、DACには上述の脆弱性が存在します。企業や行政組織でITシステムが広く使われるようになるにつれ、それらの組織でも情報セキュリティがより重要となりました。

そんな中、DACの脆弱性を補いつつも、企業や行政組織でも運用が可能なアクセス制御の仕組みとして、ロールベースアクセス制御(Role-based Access Control; RBAC)が考えだされました。

DACやMACでは、アクセス制御の主体は個々のユーザやグループ、対象はファイルのような具体的なリソースでした。一方、RBACでは、パーミッションはユーザやグループではなく「役割(ロール)」について付与され、ユーザやグループはそれらの「役割」に紐づけられます。また、対象も具体的なリソースではなくそれらのリソースに対して一連の操作を行う「オペレーション」となります。

このように、「役割」や「オペレーション」といった、一段抽象度を上げた概念に対してアクセス制御を行うことで、RBACでは、企業および行政組織のポリシーや構造に合わせた柔軟な、しかし集中的なコントロールを可能としています。企業や行政組織での実運用が重視されているのがポイントです。


--

3 件のコメント:

ほへほへ2 さんのコメント...

面白いです。役割やオペレーションは具体的にはどのようなものになるでしょう?例えばユーザーコントロール(役割)に対してユーザーの追加(オペレーション)があるといった具合でしょうか?

kamonama さんのコメント...

> ほへほへ2さん
そうですね。ソフトウェアの設計上は「ユーザコントール」や「ユーザの追加」という形に落ちると思います。

ただ、Role-based Access Controlが論点としているのは、組織内での権限管理なので、もっと広い概念になります。

たとえば、医療システムを考えた場合、「役割」として定義されるのは「医者」や「看護士」といった役職に対応づいたものになります。医者なら閲覧をしても良い情報でも、看護士にはその権限は与えられていなかったりします。その場合、「オペレーション」にあたるものは、たとえば「ある患者Aのカルテの閲覧」だったりします。

その他、たとえば内科が管理している情報を外科医が自由に見られないようにするとか、医者でもインターンには権限を制限するとか、そういった「役割」も定義されうると思います。(私は医療関係の専門家ではないので「たとえば」の話になりますが)

以下のペーパーにまとまっているので、ご覧ください。
http://csrc.nist.gov/rbac/ferraiolo-kuhn-92.pdf

ほへほへ2 さんのコメント...

そういう意味のロールですか、ありがとうございます。