サービス指向セキュリティ - 認可サービスによるアクセス制御の合理化

14
開発者と ID サービス -認可サービスによるアクセス制御の合理化 Oracle ホワイト・ペーパー 2008 11

Transcript of サービス指向セキュリティ - 認可サービスによるアクセス制御の合理化

Page 1: サービス指向セキュリティ - 認可サービスによるアクセス制御の合理化

開発者と IDサービス-認可サービスによるアクセス制御の合理化

Oracle ホワイト・ペーパー

2008 年 11 月

Page 2: サービス指向セキュリティ - 認可サービスによるアクセス制御の合理化

開発者と ID サービス -認可サービスによるアクセス制御の合理化

概要 ...................................................................................................................... 3 はじめに .............................................................................................................. 4 認可の問題 .......................................................................................................... 4

ビジネス・ロジックの保護 ......................................................................... 4 データ・セキュリティの強化 ..................................................................... 6 リスク対応の組込み..................................................................................... 6 管理................................................................................................................. 7 ポリシーの共有............................................................................................. 7 委任................................................................................................................. 7 監査................................................................................................................. 8

認可サービス – 最新のアプローチ................................................................. 8 外部化............................................................................................................. 8 PAP、PEP、PDP、および PIP..................................................................... 8 一元化された管理....................................................................................... 10 共有と再利用が可能なポリシー ............................................................... 10

Oracle Entitlements Server による外部化と一元化 ........................................ 10 リスクに対応した Oracle Adaptive Access Manager による認可サービスの

拡張 .................................................................................................................... 12 結論 .................................................................................................................... 13

開発者と ID サービス-認可サービスによるアクセス制御の合理化

2

Oracle Corporation 発行「Developers and Identity Services - Modernizing Access Control with Authorization Service」の翻訳版です。

Page 3: サービス指向セキュリティ - 認可サービスによるアクセス制御の合理化

開発者と ID サービス -認可サービスによるアクセス制御の合理化

概要 サービス指向セキュリティ(SOS)は、Oracle Fusion Middleware プラットフォー

ム全体に対応する総合的なアプリケーション・セントリック・アプローチと連携

して機能します。その目的は、開発者が扱いやすい包括的な標準ベースのプラッ

トフォームを提供することです。SOS では多くの一般的な ID サービスが活用およ

び共有されるので、開発者は、もっとも重要な作業、つまりアプリケーション・

ロジックそのものに集中できます。しかし、ID 管理に従来から使用されてきた縦

割り型手法から本当に脱却するには、ID 対応のアプリケーションを作成する開発

者が ID サービスの利点に目を向け、これらのサービスをアプリケーション設計で

いつどのように使用するかを理解する必要があります。

"ID 管理に従来から使用されてきた縦割

り型手法から本当に脱却するには、ID 対

応のアプリケーションを作成する開発者

が[ID サービス]の利点に目を向け、これら

のサービスをアプリケーション設計でい

つどのように使用するかを理解する必要

があります。"

これは、『開発者と ID サービス』ホワイト・ペーパー・シリーズの第 2 弾です。

各ホワイト・ペーパーでは、ID サービスの特定領域について開発者の観点から取

り上げます。各ホワイト・ペーパーの説明内容は、ホワイト・ペーパー『サービ

ス指向セキュリティ – アプリケーション・セントリックな観点からの ID 管理』

ですでに定義されている ID サービスと ID の外部化に基づいています。以下の

URL を参照してください。

http://www.oracle.com/technology/global/jp/products/id_mgmt/doc/serv_oriented_sec.pdf

このホワイト・ペーパー・シリーズの第 1 弾は、『開発者と ID サービス – ID ハ

ブによる ID データへの取り組み』です。

以下の URL を参照してください。

http://www.oracle.com/technology/global/jp/products/id_mgmt/pdf/tackling_identity_data_with_identity_hub1.pdf

ここでは、ID 対応アプリケーションの最初の大きな要素である ID データについ

て解説しています。アプリケーションのビジネス・ロジック開発を始めた開発者

が対処しなければならない次のセキュリティ課題は、データとトランザクション

からアプリケーション・アクセスまで、アプリケーションのさまざまな側面で適

切なアクセスを確保することです。このホワイト・ペーパーでは、認可に焦点を

当てて解説していきます。

開発者と ID サービス-認可サービスによるアクセス制御の合理化

3

Oracle Corporation 発行「Developers and Identity Services - Modernizing Access Control with Authorization Service」の翻訳版です。

Page 4: サービス指向セキュリティ - 認可サービスによるアクセス制御の合理化

はじめに アプリケーションの認可は、アプリケーション開発者によって解決されるアプリ

ケーション固有の問題であるかのように最初は見えます。しかし結局は、保護さ

れる必要があるのはアプリケーションとそのリソースです。従来のアプリケー

ションでは、独自のメカニズムによってのみ実施および管理できる独自のポリ

シーを定義することがよくあります。開発者は、特定のビジネス・ロジックへの

アクセスを制限することが必要になる場合があります。また、ビジネス・オブジェ

クトも、ユーザーに実行を許可する操作の種類(表示や変更などの操作)を制限

する対象になることがあります。さらに下位のレベルでは、リポジトリからアプ

リケーションまたは ID データへのアクセスについても、慎重に検討する必要があ

ります。

ベンダーからのパッケージ・アプリケーションまたは企業内のカスタム・アプリ

ケーションのどちらであっても、アプリケーションがいったん本番環境に配置さ

れると、認可モデルに対して新しい要件の追加、カスタマイズ、または修正をお

こなうには、開発者によるコード変更が必要になる可能性があります。

アプリケーションが企業内に散在している状況では、これらのアプリケーション

がもつ独自の認可ポリシーを管理するのは非常に困難です。多くの場合、たとえ

ば一連の財務アプリケーションのようなよく似たアプリケーションを管理するポ

リシーは、類似している可能性があります。管理者は、これらのアプリケーショ

ンのすべてにおいて、特色が異なる類似のポリシーを定義して維持しなければな

りません。さらに、コンプライアンスについて言えば、このようなまとまりがな

いアプリケーション全体のユーザー・エンタイトルメントを監査してレポートを

作成することは非常に困難であり、ほぼ不可能です。こういった状況から、ユー

ザー・エンタイトルメント(アプリケーション・ユーザーが何を実行できるかを

管理する一連の権限)のエンタープライズ・レベルでの可視性と制御が実現され

ていない全体的な問題が浮き彫りになります。

"これらの制限によって、ユーザー・エン

タイトルメント(アプリケーション・ユー

ザーが何を実行できるかを管理する一連

の権限)のエンタープライズ・レベルで

の可視性と制御が実現されていない全体

的な問題が浮き彫りになります。"

認可の問題 アプリケーションのセキュリティ要件は、今日のエンタープライズ・アプリケー

ションのビジネス要件と同じくらい重要です。実際に、より厳格な企業ポリシー

と政府規制の実施により、認可はビジネス要件の不可欠な要素になっています。

現在、開発者に要求されていることは、ユーザー・エンタイトルメントの実施と

管理の両方で、細かい設定なしに高度なセキュリティを提供できるアプリケー

ションの実現です。

ビジネス・ロジックの保護

アプリケーションのビジネス・ロジックを保護することは、実際には、アプリケー

ション・ソフトウェア・コンポーネントとアプリケーション・ビジネス・オブジェ

クトを保護することになります。ランタイム・ロジックでは、特定の機能または

特定のデータへのアクセスを許可するかどうかを決める必要があります。開発者

の観点から見ると、認可決定に必要なすべての情報がアプリケーション・データ

に含まれている場合は、アプリケーション・データ自体にセキュリティを実装で

きます。これは、認可決定に必要な情報の種類から決定ロジックまで、認可モデ

ル全体の制御を完全に開発者に任せる従来型のアプローチです。このアプローチ

開発者と ID サービス-認可サービスによるアクセス制御の合理化

4

Oracle Corporation 発行「Developers and Identity Services - Modernizing Access Control with Authorization Service」の翻訳版です。

Page 5: サービス指向セキュリティ - 認可サービスによるアクセス制御の合理化

では、認可ロジックが完全にアプリケーション内部に組み込まれる、より厳格な

モデルが作成されます。これによって開発者は開発中に認可モデルを自由に制御

できますが、開発が完了してアプリケーションを配置したあとは、カスタマイズ

または拡張がほとんどできません。認可ロジックの変更が必要になった場合は、

コードを変更しなければならない可能性もあります。また、ほかのアプリケーショ

ンやリポジトリからの既存の情報は、使用するためにアプリケーション・メタデー

タに取り込む必要があり、リポジトリのデータ同期についても開発者の責任にな

ります。たとえば、管理職には、直属の部下の給与情報にアクセスすることが許

可されます。人事管理システム(HRMS)または LDAP ディレクトリに存在して

いる可能性がある管理職と直属の部下の関係は、アプリケーション・メタデータ

と同期させる必要があります。

"一元管理されたユーザーおよびグルー

プ・リポジトリとしての LDAP ディレク

トリ・サービスが出現したことで、アプ

リケーション開発者は、認証プロセスと

認可プロセスの両方でこの情報を利用で

きるようになりました。"

一元管理されたユーザーおよびグループ・リポジトリとしての LDAP ディレクト

リ・サービスが出現したことで、アプリケーション開発者は、認証プロセスと認

可プロセスの両方でこの情報を利用できるようになりました。一部のアプリケー

ションは、ディレクトリへの直接接続によって LDAP と直接統合されます。J2EE

環境では、JAAS(Java Authentication and Authorization Service)と JACC(Java

Authorization Contract for Containers)によって抽象化されたコンテナ・レイヤーが

提供されるので、開発者は基盤となる認可プロバイダとその実装に関連する作業

から解放されます。JAAS と JACC で提供されるフレームワークでは、開発者はア

プリケーション・レベルの許可と権限を定義し、それが一連のセキュリティ・ロー

ルにマッピングされることで宣言型セキュリティを実装します。これらのロール

は、基盤となるプロバイダから個別のユーザーまたはグループに順番に割り当て

られます。ロールのマッピングとともに、許可と権限はアプリケーションの外側

にある各デプロイメント・ディスクリプタで定義され、これらのディスクリプタ

の修正は、アプリケーションの変更なしでおこなうことができます。さらに、プ

ロバイダ(たとえば、LDAP プロバイダ)内でユーザー、グループ、およびグルー

プ・メンバーシップに変更を加えれば、開発者が介在しなくてもアプリケーショ

ンのセキュリティを変えることができます。ただし、新しい許可クラスの追加ま

たはディスクリプタの修正など、特定の変更では、引き続きアプリケーション内

での修正やアプリケーションの再配置が必要になることがあります。

完全に分離されているわけではありせんが、この程度に認可が外部化されていれ

ば、開発者とアプリケーション管理者には、アプリケーションのセキュリティを

カスタマイズおよび拡張する際にいくらかの柔軟性が与えられます。しかし、ロー

ルベースのセキュリティには制限があります。たとえば、財務アプリケーション

で、顧客サービス担当者が顧客データを表示できる時間帯を午前 9 時~午後 5 時

に制限するポリシーを実施したと仮定します。この場合、認可条件の一部として

現在時刻が使用されます。さらに、顧客サービス担当者は社会保障番号の画面表

示だけが可能で、印刷は許可しないポリシーが実施されています。アカウント・

マネージャーは、レポートを印刷するときに社会保障番号を印刷できます。この

例では、出力タイプ(画面と印刷)が同一の対象(社会保障番号)における認可

条件の一部になっています。この種の認可決定には、評価に必要なすべての情報

を提供するより豊富なコンテキストが要求されます。選択肢として常に、再び決

開発者と ID サービス-認可サービスによるアクセス制御の合理化

5

Oracle Corporation 発行「Developers and Identity Services - Modernizing Access Control with Authorization Service」の翻訳版です。

Page 6: サービス指向セキュリティ - 認可サービスによるアクセス制御の合理化

定ロジックをコードに組み込んでプログラム的なセキュリティを使用する方法も

ありますが、開発者は最初のジレンマに戻ってしまいます。ロジックが確定して

しまうと、配置後にそれをカスタマイズするのは困難になります。

データ・セキュリティの強化

たとえば、財務アプリケーションで、地域担当のアカウント・マネージャーに対

してその地域の顧客口座だけの表示を許可するポリシーを定義したと仮定します。

開発者の観点から見た場合、このポリシーは、データベースの検索中に的確なフィ

ルタをプログラム的に生成すること、つまり、SELECT 文で適切な WHERE 句を

使用することで実施できます。これはアプリケーション内から実行できますが、

認可決定はアプリケーションの外部に属していることが理想です。任意のデータ

ベース・クライアントまたはアプリケーションによるアクセスは、同じロジック

によって完璧に保護される必要があります。たとえば、レポート・ユーティリティ

は同じポリシーによって管理される必要があり、条件生成ロジックを繰り返し再

実装するのは望ましくありません。

"何よりも重要なことは、データ・セキュ

リティの強化をコード内のロジックに埋

め込むのではなく、セキュリティ・ポリ

シーとして実現する機能です。"

何よりも重要なことは、データ・セキュリティの強化をコード内のロジックに埋

め込むのではなく、セキュリティ・ポリシーとして実現する機能です。前述と同

じ例を使用した場合、管理職が直属の部下の給与情報にアクセスするのを許可す

るポリシーは、データ・レベルで実施される必要があります。

リスク対応の組込み

誰が何にアクセスするかはユーザー・エンタイトルメントによって定義されます

が、企業は、エンタープライズ環境を保護するためによりコンテキストを意識し

た認可メカニズムを探し始めています。たとえば、所有している口座への企業資

金の送金をユーザーに許可するべきかを決める場合、財務アプリケーションでは、

トランザクションのコンテキストで特定の条件に基づいて計算したリスクがそれ

ほど高くなければ、その送金は認可されます。この例では、ユーザーが企業ネッ

トワークの外部から接続しており、強力な認証を使用していない場合は、リスク

が高いと見なされることがあります。また、ユーザーが過去 24 時間以内に 4 回を

超える送金をすでにおこなっている場合も、リスクが高いと見なされます。

とくにこのようなリスクベースのポリシーは、顧客を中心に考えられているため

きわめて頻繁に変更される可能性があり、開発者がアプリケーションの開発サイ

クルの間にそれらの要件を満たすのは困難です。

開発者と ID サービス-認可サービスによるアクセス制御の合理化

6

Oracle Corporation 発行「Developers and Identity Services - Modernizing Access Control with Authorization Service」の翻訳版です。

Page 7: サービス指向セキュリティ - 認可サービスによるアクセス制御の合理化

管理

単一のアプリケーションを管理する場合、ポリシー管理を独自の方法で実施する

のは難しいことではありません。しかし、多数のアプリケーションが配置されて

いる一般的な企業について考えると、一貫性のある管理を実現することが重要と

なってきます。何らかの基準がなければ、認可ポリシーの定義および管理におい

て、各開発者は異なるアプローチを取ることになります。JACC/JAAS モデルでは

LDAPと J2EEセキュリティの使用方法に関してある程度の一貫性が提供されます

が、開発者は、XML ファイルおよび LDAP ユーザーとグループを扱うようにビジ

ネス・ユーザーに強制することよりも、ビジネス・ユーザーにとってより扱いや

すいインタフェースの開発を要求されることが多くなります。ほとんどの場合、

ユーザー・エンタイトルメントを維持および管理するのは、IT 管理者ではなくビ

ジネス・ユーザーです。ユーザー・エンタイトルメントをどのように表現するか

は、重要な考慮事項です。

"ほとんどの場合、ユーザー・エンタイト

ルメントを維持および管理するのは、IT管理者ではなくビジネス・ユーザーです。

ユーザー・エンタイトルメントがどのよ

うに表されるかは、重要な考慮事項です。"

また、ユーザー・エンタイトルメントをどこに格納するかも、管理上の難題です。

たとえば、ユーザーの LDAP グループ・メンバーシップでは、そのユーザーのエ

ンタイトルメントが JAAS 対応の J2EE アプリケーションで決定され、さらに何ら

かのERPシステムでの職責がERP独自の認可モデルの中で定義されることがあり

ます。認可メカニズムが企業内に散在している場合、ユーザー・エンタイトルメ

ントの全体像を把握することは、複数のシステムにアクセスする必要があるので

簡単な作業ではありません。

ポリシーの共有

複数のアプリケーションがある場合、認可ポリシーの共有または再使用ができて

いないことは明らかです。前述のポリシーの 1 つを例に考えると、地域担当のア

カウント・マネージャーは、地域内の顧客だけを表示および管理するように制限

が加えられています。複数の財務アプリケーションが配置されている場合、各ア

プリケーションで類似のポリシーを作成することが要求される可能性があります。

その結果として、各アプリケーションでよく似たポリシーが保持され、ほとんど

同じ処理をおこなう独自の認可決定ロジックが実装されます。管理者にとっては

異なるポリシー・モデルを理解するのが大変なだけではなく、企業全体で完全性

を維持することが悩みの種となります。

"各アプリケーションでよく似たポリ

シーが保持され、ほとんど同じ処理をお

こなう独自の認可決定ロジックが実装さ

れます。"

委任

アクセス制御の委任は一般的ですが、開発者にとっては難しい問題です。財務ア

プリケーションでは、口座の所有者が送金の権限などの特定機能をほかのアカウ

ント・ユーザーに委任する場合があります。たとえば、休暇を取るアカウント・

マネージャーが、取引先へのアクセスを上司に委任することがあります。これは

開発者にとって、アカウント・マネージャーに適切なアクセスを割り当てるよう

に簡単な問題ではありません。休暇中に、取引先の 1 つが別の管理チェーンのも

とでほかのアカウント・マネージャーに移行したと仮定します。その時点で、顧

客はそれまでの管理チェーンにはもう属してはいないので、最初の委任は無効に

なります。しかし、このような状況に適した委任モデルは複雑でカスタマイズ可

能なことが多いので、認可の完全性をアプリケーション・ロジックの内部で確保

するのは困難です。

開発者と ID サービス-認可サービスによるアクセス制御の合理化

7

Oracle Corporation 発行「Developers and Identity Services - Modernizing Access Control with Authorization Service」の翻訳版です。

Page 8: サービス指向セキュリティ - 認可サービスによるアクセス制御の合理化

監査

サーベンス・オクスリー法のような政府規制では、企業全体のユーザー・エンタ

イトルメントをレポートおよび検査する機能を確保することが企業に義務づけら

れています。ポリシー管理の落とし穴は、ユーザー・エンタイトルメントを効率

的に監査する機能において、ポリシー共有と委任が誇張されていることです。ポ

リシーは、正確なユーザー・エンタイトルメントが簡単にわかる方法で定義され

ていないかもしれません。各アプリケーションでは独自の方法でポリシーが定義

されるので、監査者と認証者はユーザー・エンタイトルメントの全体像を確認す

るために、さまざまな特色をもつ複数のアプリケーションにまたがる一貫性のな

い形式のエンタイトルメントに対処する必要があります。管理の問題と同じよう

に、ユーザー・エンタイトルメントのエンタープライズ・レベルでの可視性が確

保されていなことが、監査とコンプライアンスの分野で見られる問題と非効率性

の大きな原因になっています。

"管理の問題と同じように、ユーザー・エ

ンタイトルメントのエンタープライズ・

レベルでの可視性が確保されていなこと

が、監査とコンプライアンスの分野で見

られる問題と非効率性の大きな原因に

なっています。"

認可サービス – 最新のアプローチ

すでに説明したように、開発者およびアプリケーション所有者の両方の認可要件

を満たすために必要なサポートを提供する、一元化された認可サービスを定義す

ることが強く求められています。

外部化

認可サービスの重要な概念は、エンタイトルメントの外部化への対応です。

JACC/JAAS モデルは、この面で非常に進んでいます。エンタイトルメントの外部

化では、アプリケーション内のビジネス・ロジックから認可ロジックが分離され

ます。アプリケーションは、認可チェックの実行を管理する役目を果たします。

たとえば、顧客の社会保障番号が取得される場合は常に、アプリケーションにア

クセスしている人物がそのデータにアクセス可能かどうかを確認するために、認

可チェックをトリガーします。ただし、認可チェックは、完全にアプリケーショ

ンの外部で実行されます。この決定は認可サービスによっておこなわれ、また認

可サービス内で定義されたポリシーに基づいています。アプリケーション・ロジッ

クでは、ポリシーによって営業時間中にだけデータの取得が許可されているかど

うか、またはアプリケーションへの VPN 経由のアクセスが禁止されているかどう

かは関係ありません。この区別と分離によって、認可ポリシーを変更してもアプ

リケーション・ロジックは影響を受けなくなります。つまり、アプリケーション・

コードを変更することなく、自由に認可ポリシーをカスタマイズできるようにな

ります。

"この区別と分離によって、認可ポリシー

を変更してもアプリケーション・ロジッ

クは影響を受けなくなります。つまり、

アプリケーション・コードを変更するこ

となく、自由に認可ポリシーをカスタマ

イズできるようになります。"

PAP、PEP、PDP、および PIP

エンタイトルメントの外部化を効率的にサポートするには、機能を提供するため

に必要な次のサービスが認可サービスの一部として存在している必要があります。

• ポリシー管理ポイント(PAP)では、管理者がアプリケーション固有の

ポリシーを作成および変更できます。

• ポリシー実施ポイント(PEP)は、ポリシーによるエンタイトルメントの

決定をアプリケーション内でトリガーする役割を果たします。

• ポリシー決定ポイント(PDP)では、PEP に代わって、ポリシーによる

エンタイトルメントの決定が実際におこなわれます。

開発者と ID サービス-認可サービスによるアクセス制御の合理化

8

Oracle Corporation 発行「Developers and Identity Services - Modernizing Access Control with Authorization Service」の翻訳版です。

Page 9: サービス指向セキュリティ - 認可サービスによるアクセス制御の合理化

• 1 つまたは複数のポリシー情報ポイント(PIP)で、ポリシーによる正確

な決定を実現するのに役立つデータと情報が PDP に提供されます。

図 1 認可サービスのアーキテクチャ

このアーキテクチャの中心的存在が PDP です。PDP には、アプリケーション固有

のポリシーが含まれている必要があります。また、"このユーザーはこのリソース

に対する権限をもっていますか。"といった PEP からのリクエストに対応できる必

要があります。PDP ではそのポリシーが調べられ、許可または拒否レスポンスの

いずれかが、ユーザーにアクセスが許可される前かあとに満たされる必要がある

追加条件または義務とともにアプリケーションの PEP に返されます。

"PIP に働きかけることによって PDP は、

Joe の現在の ID(Joe が連携しているグ

ループ、属性、またはロールを含む)お

よび Joe が保持している属性(州など)

を確認し、さらにこの IDと属性を、リソー

ス 'SSN'に対して現在定義されているポ

リシーと比較します。"

たとえば、前出の財務アプリケーション(PEP)から PDP に対して、"ユーザー'Joe'はリソース'SSN'の'表示'権限をもつことができますか。"という確認が実行された

と仮定します。PIP に働きかけることによって PDP は、Joe の現在の ID(Joe が連

携しているグループ、属性、またはロールを含む)および Joe が保持している属

性(州など)を確認し、さらにこの ID と属性をリソース'SSN'に対して現在定義

されているポリシーと比較します。偶然にも、Joe がユーザー・レコードにアクセ

スする顧客サービス担当者だったとします。しかし、Joe は、金曜日の夜の営業時

間後にデータにアクセスしようとしています。そのため、PDP からは拒否のレス

ポンスが返されます。週明け月曜日の営業時間中に、Joe がユーザー・レコードへ

のアクセスを再び試みたとします。今度は、PDP から許可のレスポンスが返され

ます。また、このレスポンスと一緒に、Joe による SSN へのアクセスをログに記

録することを財務アプリケーション(PEP)にリクエストする義務も返されます。

開発者と ID サービス-認可サービスによるアクセス制御の合理化

9

Oracle Corporation 発行「Developers and Identity Services - Modernizing Access Control with Authorization Service」の翻訳版です。

Page 10: サービス指向セキュリティ - 認可サービスによるアクセス制御の合理化

一元化された管理

一元化された管理は、ポリシー管理サーバー(PAP)を通して提供されます。定

義した認可ポリシーは、すべてのアプリケーションに対応する単一のポリシー・

ストアに格納され、一元管理されます。PAP では、ポリシー管理における一貫性

のあるユーザー・エクスペリエンスが提供されます。また、PAP によって、認可

ポリシーを表現する際の形式の一貫性が確保されます。コンプライアンスの観点

から見ると、監査や認証などの機能については、どちらもユーザー・エンタイト

ルメント定義の一元化による利点を活用できます。現在の PAP では、認可サービ

スと統合されているすべてのアプリケーションにまたがるユーザー・エンタイト

ルメントのエンタープライズ・ビューと制御が実現されています。

"現在の PAP では、認可サービスと統合

されているすべてのアプリケーションに

またがるユーザー・エンタイトルメント

のエンタープライズ・ビューと制御が実

現されています。"

共有と再利用が可能なポリシー

特定の業種内では、各アプリケーションが類似していることがよくあります。こ

れらのアプリケーションのすべてで、よく似たユーザー・エンタイトルメントが

定義される可能性は十分にあります。認可サービスでは PAP でポリシーが一元管

理されるため、共有サービスとして機能して、類似したアプリケーションのすべ

てで一貫性のあるアクセスおよびロール・マッピングの決定を実施できます。ま

た、ポリシー決定の一元化と外部化によって、各アプリケーションで認可決定の

同一または類似のセットを作成する必要がなくなります。

認可サービスでは、開発者と管理者が強く求めている外部化と一貫性を提供する

必要があります。これによって、認可に関する実際の意志決定をおこなう作業か

ら開発者は解放されます。また、アプリケーション・ロジックから認可ロジック

が分離されるので、開発者はアプリケーション・ロジックの開発に集中できるよ

うになります。複雑さの一部分を認可サービスに移すことで、アプリケーション

全体で柔軟かつ機能的に認可要件の変化に対処できます。

"認可サービスでは、開発者と管理者が強

く求めている外部化と一貫性を提供する

必要があります。"

Oracle Entitlements Server による外部化と一元化

従来型のアプリケーションでは、セキュリティ上の決定がアプリケーション・ロ

ジックに組み込まれていることがよくあります。Oracle Access Management Suite

に新しく追加された Oracle Entitlements Server では、アプリケーション内にある

認可ポリシーとエンタイトルメントの外部化を支援する一元化された認可サービ

スが提供されます。提供される一連のセキュリティ・モジュールは、ポリシー決

定ポイント(PDP)として機能します。これらのセキュリティ・モジュールでは、

アプリケーションまたはサービスに代わって、エンタイトルメント・ポリシーの

評価が実行されます。そのあと、アプリケーションとサービスはポリシー実施ポ

イント(PEP)として機能し、特定のリソース上でユーザーがアクションを実行

できるかどうかの確認が、セキュリティ・モジュールに対しておこなわれます。

したがって、セキュリティ・ポリシーがアプリケーション・ロジックとしてアプ

リケーションに組み込まれることがなくなるので、アプリケーション・コードが

簡略化されます。

また、Oracle Entitlments Server では、Oracle Database、アプリケーション・サーバー、

および Microsoft Office SharePoint Server のような特定の構造化されたランタイム

用に、事前組込み PEP が提供されています。Oracle Data Service Integrator および

開発者と ID サービス-認可サービスによるアクセス制御の合理化

10

Oracle Corporation 発行「Developers and Identity Services - Modernizing Access Control with Authorization Service」の翻訳版です。

Page 11: サービス指向セキュリティ - 認可サービスによるアクセス制御の合理化

Oracle Virtual Private Database と統合した場合は、Oracle Entitlements Server で定義

されたポリシーに基づいたデータ・セキュリティの実行を可能にする中間層を

データベース・クライアントとデータベース間に提供することによって、データ・

レベルのセキュリティを定義して実行できるようになります。

"Oracle Entitlements Server では、高度な

データ駆動型エンタイトルメント・ソ

リューションのポリシーで既存の企業

データ(RDBMS、LDAP、Web サービス、

顧客の情報源など)を簡単に活用できる

機能が提供されます。"

図 2 Oracle Entitlements Server

Oracle Entitlements Server では、高度なデータ駆動型エンタイトルメント・ソリュー

ションのポリシーで既存の企業データ(RDBMS、LDAP、Web サービス、顧客の

情報源など)を簡単に活用できる機能が提供されます。エンタイトルメント・ポ

リシーでは、必要であれば、これらのデータソースからの属性を活用して属性ベー

スのアクセス制御(ABAC)システムを実装できます。さらに、カスタム属性の

取得機能や評価機能などの拡張機能を実装して、顧客独自の要件に対応すること

もできます。

図 3 Oracle Entitlements Server のポリシー

開発者と ID サービス-認可サービスによるアクセス制御の合理化

11

Oracle Corporation 発行「Developers and Identity Services - Modernizing Access Control with Authorization Service」の翻訳版です。

Page 12: サービス指向セキュリティ - 認可サービスによるアクセス制御の合理化

すべての認可ポリシーの管理は、Oracle Entitlements Server 内で一元化されます。

管理者が詳細なエンタイトルメント・ポリシーを定義すると、それらのポリシー

はセキュリティ・モジュールに渡されます。この配信は、セキュリティ・モジュー

ルを使用するアプリケーションを中断することなく実行できます。このように、

エンタイトルメント・ポリシーは、保護するアプリケーションから切り離して変

更できます。また、Oracle Entitlements Server では、独自の管理アプリケーション

を実装するための管理 API も提供されています。 "アプリケーションでは、XACML リクエ

スト/レスポンス・プロトコルを使用して、

Oracle Entitlements Server のセキュリ

ティ・モジュールから認可決定が取得で

きます。相互運用性を確保するために、

Oracle Entitlements Server のポリシー

は標準の XACML 形式でインポートまた

はエクスポートできるようになってい

ます。"

標準化について言えば、Oracle Entitlements Server では eXtensible Access Control Markup Language(XACML)がサポートされています。アプリケーションでは、

XACML リクエスト/レスポンス・プロトコルを使用して、Oracle Entitlements Serverのセキュリティ・モジュールから認可決定が取得できます。相互運用性を確保す

るために、Oracle Entitlements Server のポリシーは標準の XACML 形式でインポー

トまたはエクスポートできるようになっています。

リスクに対応した Oracle Adaptive Access Manager による認可

サービスの拡張 Oracle Access Management Suiteの一部であるOracle Adaptive Access Managerでは、

Oracle Adaptive Risk Manager(Oracle ARM)コンポーネントを使用して、詐欺行為

を阻止する目的で、コンテキストを意識したリスク分析がリアルタイムで提供さ

れます。Oracle ARM では、ユーザー・プロファイル、デバイスの特徴、トランザ

クション・データ、IP アドレス、地理的位置、およびサード・パーティ情報など、

さまざまなソースから取得したコンテキスト・データを分析することでリスクが

評価されます。認可サービスでは、Oracle Entitlements Server が利用できる別のポ

リシー情報ポイント(PIP)が Oracle ARM によって提供されます。Oracle Entitlements Server のポリシーでは、特定のリソースへのアクセスを許可する条件

として、リスク・スコアが一定のしきい値以下であることが要求される場合があ

ります。Oracle ARM では、リアルタイムでさまざまな危険因子を調べて、トラン

ザクションのコンテキストに基づいてリスク・スコアを生成できます。

"認可サービスでは、Oracle EntitlementsServer が利用できる別のポリシー情報ポ

イント(PIP)が Oracle ARM によって提

供されます。"

開発者と ID サービス-認可サービスによるアクセス制御の合理化

12

Oracle Corporation 発行「Developers and Identity Services - Modernizing Access Control with Authorization Service」の翻訳版です。

Page 13: サービス指向セキュリティ - 認可サービスによるアクセス制御の合理化

結論 認可サービスによって認可を外部化すれば、開発者はアプリケーションの開発中

でも、一元化された一貫した方法で認可要件を実装できます。強く求められてい

るエンタープライズ・レベルでの可視性およびユーザー・エンタイトルメントの

制御が提供される認可ポリシーの一元化は、数百もの異なるアプリケーションに

対応する必要がある企業にとっては非常に重要です。この一元化によって、管理

者だけでなく、IT ユーザーとビジネス・ユーザーの作業環境も大幅に改善されま

す。また、企業は、レポートの作成、監査の実行、およびアクセスの認証に関す

る分野のコンプライアンス要件と規制要件を簡単に達成できるようになります。

認可サービスが提供する最新のアプローチによって、開発者、ベンダー、および

企業は、常に変化する認可要件に効果的に対処する態勢が整いました。

オラクルのセキュリティ・テクノロジーの詳細は、

http://www.oracle.com/lang/jp/security/security-solutions.htmlを参照してください。

開発者と ID サービス-認可サービスによるアクセス制御の合理化

13

Oracle Corporation 発行「Developers and Identity Services - Modernizing Access Control with Authorization Service」の翻訳版です。

Page 14: サービス指向セキュリティ - 認可サービスによるアクセス制御の合理化

開発者と ID サービス – 認可サービスによるアクセス制御の合理化 2008 年 11 月 著者:Stephen Lee 共著者:William Dettelback、Nishant Kaushik Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問い合わせ窓口: 電話:+1.650.506.7000 ファクシミリ:+1.650.506.7200 www.oracle.com Copyright © 2008, Oracle Corporation and/or its affiliates.All rights reserved. 本文書は情報提供のみを目的として提供されており、ここに記載される内容

は予告なく変更されることがあります。 本文書は、その内容に誤りがないことを保証するものではなく、また、口頭

による明示的保証や法律による黙示的保証を含め、商品性ないし特定目的適

合性に関する黙示的保証および条件などのいかなる保証および条件も提供す

るものではありません。 オラクルは本文書に関するいかなる法的責任も明確に否認し、本文書によっ

て直接的または間接的に確立される契約義務はないものとします。本文書は

オラクル社の書面による許可を前もって得ることなく、いかなる目的のため

にも、電子または印刷を含むいかなる形式や手段によっても再作成または送

信することはできません。 Oracle は米国 Oracle Corporation およびその子会社、関連会社の登録商標で

す。そのほかの名称はそれぞれの会社の商標です。