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

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

Oracle ホワイト・ペーパー 2008 年 4 月

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

概要 ...................................................................................................................... 3 はじめに .............................................................................................................. 3 "ID"の外部化 ....................................................................................................... 4

アプリケーション開発の困難 ..................................................................... 4 アプリケーションのブラック･ボックス ................................................... 5 ユーザー・セントリック ID 管理............................................................... 6

ID サービスの導入 ............................................................................................. 6 認証サービス................................................................................................. 7 ID プロバイダ ............................................................................................... 8 ロール･プロバイダ....................................................................................... 8 認可サービス................................................................................................. 9 プロビジョニング･サービス ..................................................................... 10 制御サービスと監査サービス ................................................................... 10

サービス指向セキュリティ - アプリケーション・セントリックな観点か

らの ID 管理 ...................................................................................................... 11 設計/配置...................................................................................................... 11 パッケージ化............................................................................................... 12 配置............................................................................................................... 12 ランタイム･インフラストラクチャ ......................................................... 13 管理............................................................................................................... 13

ポリシー管理 ......................................................................................... 13 ユーザー/ロール管理 ............................................................................ 14 ガバナンス、リスクおよびコンプライアンス管理.......................... 14

ホット・プラグ可能................................................................................... 15 現行製品 ............................................................................................................ 15

開発およびパッケージ化 ........................................................................... 15 ランタイム................................................................................................... 16 管理............................................................................................................... 16

ロードマップ .................................................................................................... 17 Oracle Access Manager................................................................................. 17

次世代シングル･サインオン（SSO） ................................................ 17 ファイングレイン認可（FGA） ......................................................... 17

Oracle Identity Manager および Oracle Role Manager ............................... 17 標準............................................................................................................... 18 ガバナンス、リスク管理およびコンプライアンス（GRC） ............... 18

結論 .................................................................................................................... 19


2

Oracle Corporation 発行「Service-Oriented Security . An Application-Centric Look at Identity Management」の翻訳版です。

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

概要

サービス指向アーキテクチャ（SOA）は、サービスとしてのソフトウェアを効率

的に開発するフレームワークを提供し、共有や再利用、統合が容易なため、エン

タープライズ･ソフトウェアにおいて必要不可欠な要素になりました。ID 管理ほ

ど、この必要性が明らかな領域はほかにありません。今、サービス指向セキュリ

ティ（SOS）の時代を迎えています。

はじめに

今日のアプリケーションは、データ暗号化からデータ・アクセス、ポリシー管理

からユーザー･ライフ・サイクル、業界標準から政府規制にいたるまで、セキュリ

ティの多数の側面に対応しており、その数は増え続けています。アプリケーショ

ン･ベンダーや顧客は、これらの問題の多くを独自の方法で解決してきました。こ

のような解決方法は、アプリケーションがそれ自体のサイロに納まっている場合

は完璧に機能するかもしれません。しかし、エンタープライズ環境に統合される

と、そのような個々のサイロはすぐに分解されてしまいます。顧客は、重複し、

分散した機能に直面することになります。顧客の既存のインフラストラクチャと

の統合は困難になり、場合によっては不可能となる可能性があります。

オラクルは、これらのサイロの一部をまとめる努力をしてきました。たとえば、

システム管理ソフトウェアは現在、アプリケーション･ベンダーとそのソフトウェ

ア全体を管理するためのものです。LDAP ディレクトリは、LDAP 対応のアプリ

ケーションを使用して、企業内にいるすべての人員を把握するための一般的な要

素となりました。プロビジョニング・ソリューションは、一元化されたユーザー

管理によって、個々のアプリケーションで必要とされる異なるユーザー･ライフ・

サイクルを結びつける方法を提供します。これらの追加ソリューションは、ある

程度までは役に立ちますが、変化による影響を受けやすいものです。新しい標準、

新しい要件、そして新しいアプリケーションが常に出現する状況について行くの

は困難です。

全体的な視野から、セキュリティ問題のこのような側面が、実際にベンダーや顧

客に共通していることが明らかになってきました。標準、ガイドラインおよび必

要なインフラストラクチャを提供し、アプリケーション・ライフ・サイクル全体

をサポートするには、一連の標準ベースのセキュリティ･サービスを使用できるよ

うにする必要があります。さらに、そのプロセスにおいて、それらのアプリケー

ションおよびセキュリティ･インフラストラクチャの開発、統合、管理、監視およ

び維持におけるコスト全般を削減することが必要です。これが、サービス指向セ

キュリティの最終的な目的です。


3


"ID"の外部化 "ID 管理の観点からすれば、SOS への主

要なステップは、"ID"の外部化、つまり

ユーザーおよびセキュリティ･ポリシー･

データのアプリケーションからの外部化

です。"

ID 管理の観点からすれば、SOS への主要なステップは"ID"の外部化、つまりユー

ザーおよびセキュリティ･ポリシー･データのアプリケーションからの外部化です。

サービス指向セキュリティによって、ID 層の作成が可能になります。これにより

プラットフォームが提供され、すべての ID 対応のアプリケーションをそのプラッ

トフォーム上に構築します。外部化は、開発、配置および新たな動向に対応する

際に、現在のアプローチによって顧客とベンダーが直面している多数の根本的な

問題を解決するために必要です。

アプリケーション開発の困難

アプリケーション開発者について、そしてその開発者が ID 関連の問題に関して日

常的に対処すべき事項について考えてみましょう。

アプリケーション開発において、"ID"が単にユーザー名やパスワード、ユーザー

表やプロフィール管理画面の処理を行うこと意味していた時代は終わりました。

今日のアプリケーション開発者は、ID の異なる多くの側面に対処するために、無

数の課題に直面しています。

認証は、単なるユーザー名/パスワード・ベースのスキームではなくなっています。

それどころか、アプリケーションが、配置やセキュリティのニーズに応じて、単

純なものから特殊なものに渡り異なるタイプの認証メカニズムをサポートする必

要に迫られています。

認可スキームは、以前の単純なACLベースのモデルから、保護対象のデータに基

づく多機能で複雑な方法を使用したモデルへと展開しています。

ロールは、今やアプリケーション･セキュリティおよびアプリケーション機能の基

本部分であり、グループのような単純な構造から、コンテキストとリレーション

シップに基づく複雑なビジネス･オブジェクトへと展開しています。

"実際には、独自性が高いソリューション

を構築するのか、要件のすべてを満たさ

ずに構築をするのか、リスクを抱える開

発者にとってはバランスを取ることが困

難です。"

LDAP は、開発者が基盤とするユーザーおよびグループを外部化する手段を提供

しました。LDAP の現状を打破しながら、開発者の多くは LDAP の専門家となり、

複雑なユーザー･スキーマを使って大規模なディレクトリを利用し、アプリケー

ション要件に対処しています。

これが開発者に難題をもたらします。開発者はこのような問題に対処する必要が

ある一方で、開発者には顧客インフラストラクチャに関して非常に限られた知識

しかありません。アプリケーション開発者が柔軟性を持って要件すべてを満たし、

顧客のインフラストラクチャを統合して利用できることが理想的なソリューショ

ンですが、実際には、独自性が高いソリューションを構築するのか、要件のすべ

てを満たさずに構築をするのか、リスクを抱える開発者にとってはバランスを取

ることが困難です。


4


この欠点は、アプリケーション開発にまで及びます。今日、アプリケーションは

アプリケーション管理者の手にゆだねられています。アプリケーション管理者は、

自社の既存のインフラストラクチャとの統合によって、対象となるすべての要件

をアプリケーションが確実に満たすようにする必要があります、この結果、アプ

リケーション管理者にとって、アプリケーション･ベンダーが意図するものすべて

を完全にとらえることが困難になる可能性があります。さらに、アプリケーショ

ン･ベンダーには未知の、自社に特有の制限や追加要件への対処が必要になるかも

しれません。これらの顧客の問題は、開発者やアプリケーション･ベンダーが対処

すべき課題になってきています。

今日の開発者には、ID 管理製品の進化や、新しく出現するテクノロジ、標準、企

業ポリシーおよび政府規制に対処しなければならないことで、アプリケーション

開発者としてビジネス要件を満たすという責任を上回る過度の負担がかかってい

ます。

アプリケーションのブラック･ボックス

多くの場合、アプリケーションはサイロ方式で開発されてきました。アプリケー

ションは、エンタープライズ環境に配置されると、サイロ方式では機能しなくな

ります。企業は、特に ID ライフ・サイクルからポリシー管理にいたる ID 管理の

分野においては、ますます管理を一元化する方向に向いています。多くの場合、

これは個々のアプリケーションやベンダーの独自のポリシーやフレームワークに

よって実現にいたりません。

さらに、監査やコンプライアンスの必要性が生じているために、アプリケーショ

ンはブラック･ボックス･モードでは実行できなくなっています。監査者がアプリ

ケーション内部の内容を理解することが不可欠になったため、監査者は、アプリ

ケーションの制御およびポリシーの実施（またはその欠如）を把握できます。

また、これらのポリシーの管理や構成も IT 専門家の責任ではなくなり、ビジネス

管理者の領域となりました。ポリシーは、適切なビジネスレベルのコンテキスト

で表示されることが求められています。

"このような情報に対して一元化の観点

が欠けていると、管理者に影響するだけ

でなく、監査者やセキュリティ担当者に

さらに大きな困難がもたらされることに

なります。"

これにより、以前はアプリケーション･コードに埋め込まれていたポリシー論理を

コードから取り出し、管理および監査のために論理コンテナに置く必要があります。

これらのアプリケーションのブラック･ボックスやサイロにより、企業は ID 管理

に関して追加のアプローチを実行する必要が出てきました。異機種の環境では、

既存の顧客インフラストラクチャとアプリケーションが常に容易に統合されると

は限りません。多くの場合、各アプリケーション･サイロに同様の機能が存在する

ことにより、管理機能の冗長性が発生します。異なるアプリケーションや ID 管理

製品間の統合も困難であり、ID 情報やセキュリティ情報が企業内で重複したり、

分散したりすることも少なくありません。このような情報に対して一元化の観点

が欠けていると、管理者に影響するだけでなく、監査者やセキュリティ担当者に

さらに大きな困難がもたらされることになります。最後には、現在の状況に合わ

せただけの複雑で柔軟性のないソリューションが残されることになります。


5


ユーザー・セントリック ID 管理 "アプリケーション側では、ID ベースのア

プリケーションを扱うことによって増加

する厳密な監査やプライバシ要件に対応

するために生じる困難をできるだけ回避

することが望まれます。"

ID 管理の最近の傾向の 1 つに、ユーザー・セントリック ID があります。これは

ユーザーを ID 関連のトランザクションの中心に置き、トランザクションとユー

ザー自身のプライバシの管理を強化しようという概念です。この方式は、テクノ

ロジとビジネス･プロセスの組合せに基づいており、関係者間の ID データの交換

に必ずユーザーが関与するようにします。

広範囲のインターネット･インフラストラクチャの一部として構築され、それと相

互作用するアプリケーションが増加するにつれ、ユーザー・セントリック ID をサ

ポートする必要性がこのようなアプリケーションにとって重要な要件となりつつ

あります。アプリケーション側では、ID ベースのアプリケーションを扱うことに

よって増加する厳密な監査やプライバシ要件に対応するために生じる困難をでき

るだけ回避することが望まれます。これは、アプリケーションが専用のリポジト

リ内の ID に制限されずに、外部ソースに由来する ID を用いて機能することが望

まれることも意味します。つまり、アプリケーションにおいては、新しいテクノ

ロジをビジネス･プロセスに採用できることが必要といえます。

ID サービスの導入 "ID サービスは、アプリケーションで使用

される ID 管理ソリューションのあらゆ

る機能を採用し、それらの機能すべてを

SOA のサービスとして使用できるよう

にします。"

ID サービスの概念は、SOA の基本原理に基づいており、サービス指向セキュリ

ティの要素を形成しています。ID サービスは、アプリケーションで使用される ID

管理ソリューションのあらゆる機能を採用し、それらの機能すべてを SOA のサー

ビスとして使用できるようにします。SOA のガイドラインに従うアプリケーショ

ンは、このようなサービスの提供方法について気にすることなくサービスを利用

できます。これにより、企業は、ID 管理の 4 つの A - Authentication（認証）、

Authorization（認可）、Administration（管理）および Auditing（監査）において一

貫性を維持しながら、アプリケーションの透過的かつユビキタスな部分を ID 確認

に利用できます。


6


図 1 SOA を利用した ID サービス

ID サービスの重要ポイントは、ID インフラストラクチャ内で論理的な一連のサー

ビスを提供する、十分に定義された一連の ID 管理プロバイダにあります。

認証サービス

認証サービスの目的は、やり取りを行っているユーザーの ID に関して、アプリ

ケーションに適切なレベルの確実性を提供することです。認証サービスは、多数

のシングル･サインオン･ソリューション、フェデレーション・ソリューションお

よび開発フレームワークで使用可能な標準化されたセキュリティ API（J2EE にお

ける JAAS など)が普及しているため、今日でもっとも一般的な外部化されている

ID サービスです。アプリケーションは、連携ドメイン内でアクセスされることが

多くなっています。Security Assertion Markup Language（SAML）や WS-Trust など

の標準を使用することで、認証サービスは、イントラネット境界を越えて配置さ

れたアプリケーションを保護できます。

"今日の認証サービスは、依然として認証

をバイナリ･スキームとして捉えていま

す。アプリケーションに関する限りでは、

ユーザーは認証されるか認証されないか

のいずれかです。"

ただし、今日の認証サービスは、依然として認証をバイナリ･スキームとして捉え

ています。アプリケーションに関する限りでは、ユーザーは認証されるか認証さ

れないかのいずれかです。実際のところ、現在のアプリケーションのニーズは、

この基本的な機能をすでに上回っています。

たとえば、今日のアプリケーションには、複数レベルでリスク･ベースの認証を実

行できることが求められています。ユーザーは、パスワード･ベースの認証によっ

て、単にデータの参照やプロファイルの管理のためにアプリケーションにログイ

ンする場合があります。しかし、ユーザーがより高度なトランザクション（ある

一定の事前定義された制限を超過する請求書の承認など）を開始しようとする場

合は、アプリケーションは認証サービスに、バイオメトリック・トークンなどの

より強力なトークンでユーザーを認証するように要求することもあります。

また、認証サービスは、Microsoft CardSpace や OpenID などのユーザー・セントリッ

クな新たなテクノロジに対応する必要があります。

状況に応じた認証は重要ですが、常に悪意のある攻撃が発生している状況では十

分ではない場合があります。認証サービスは、認証という枠を越え、追加レベル

の認証を実行し、必要な場合は適切にアラートを発することにより、不正の可能

性を検知してそれに対応する機能を提供する必要があります。


7


ID プロバイダ

ID プロバイダの目的は、アプリケーション自体から ID データを外部化できるよ

うにすることです。ID データは、その性質上、一元化されていません。従業員デー

タは HR システムに、顧客データは CRM システムに存在する場合や、無数のデー

タベース、LDAP システム、スプレッドシートなどに、契約先、ベンダー、パー

トナなどの特定の ID 集団に関する情報を保持する場合もあります。ID データを

信頼できる単一のソースがない場合、アプリケーションはユーザー表を構築およ

び維持し、同一の ID データを保持する必要があります。さらに、アプリケーショ

ンの多くは、ユーザー作成機能などの ID ライフ・サイクルに対処するために独自

の方法を構築することになるため、膨大な管理オーバーヘッドが生じます。

"ID データを信頼できる単一のソースが

ない場合、アプリケーションはユーザー

表を構築および維持し、同一の ID データ

を保持する必要があります。さらに、ア

プリケーションの多くは、ユーザー作成

機能などの ID ライフ・サイクルに対処す

るために独自の方法を構築することにな

るため、膨大な管理オーバーヘッドが生

じます。"

メタディレクトリ内の ID の一元化およびプロビジョニングは、現在多くの企業が

使用している一般的な 2 つのアプローチです。データの相違とメタディレクトリ･

ソリューションにおける同期コストは膨大です。プロビジョニング･ソリューショ

ンでのすべてのターゲット･システムへのコネクタの構築コストと維持コストも、

同様に莫大です。どのようなソリューションにおいても、データ･レプリケーショ

ン戦略に固有のコンプライアンスとプライバシに関連する問題に取り組むための

十分なサポートは提供されません。

ID プロバイダは、対象の ID に関する ID データを取得したい場合にアプリケー

ションが使用する ID の領域に、秩序、セキュリティおよびコンプライアンスを提

供します。

データの仮想化により、データの保存場所に関係なく、合理化され、統一された

最新のユーザー・プロファイルが、使用中のアプリケーションに表示されます。

これは、基礎となる信頼できるソースからデータを仮想化し、複雑な同期化の必

要性をなくすことによって実現されます。また、プロバイダは、機能と制御を組

み合わせて最小知識の原則を満たすことにより、ID データの開示を最小限にしま

す。この特徴によって、コンシューマが必要な際に ID データを使用できるように

設定した結果として生じる、セキュリティおよびプライバシの必要性に応じるこ

とが可能になります。ID プロバイダは、ID データをポリシーベースで制御する機

能を持つ必要があります。

ロール･プロバイダ

ロール・プロバイダの目的は、アプリケーションからロールを外部化できるよう

にすることです。ロールは、認可モデルの一部から、異なるワークフローやタス

ク･フローで使用されるビジネス単位にいたるまで、あらゆるアプリケーションの

アーキテクチャにおいて不可欠な要素になっています。多くの場合、ロールはビ

ジネス･オブジェクトを適用できるユーザーの抽象コンテナとして使用され、ユー

ザーはある特定のアプリケーション･ロジックまたは決定フローの一部となりま

す（承認ワークフローへの接続または特定の権限の割当てなど）。

今日では、通常 LDAP グループがエンタープライズ･ロール･システムとして使用

されています。このモデルは、依然として有益である一方で、より高度なロール

要件をサポートするには単純すぎることが分かっています。


8


ロール･プロバイダは、エンタープライズ･ロールとアプリケーション･ロールをサ

ポートする一元化されたシステムです。ロール管理は、エンタープライズ･ロール･

レベルで行われ、より単純で理解しやすいロール構造をしています。これらのエ

ンタープライズ･ロールは、エンタープライズ･ロールとアプリケーション･ロール

間の関係によって、アプリケーション設計で意図したとおりに非常に細分化され

た特殊な方法でアプリケーションに影響します。アプリケーション･ロールは他の

アプリケーションとも共有できるため、企業内のアプリケーション間における簡

単な統合および機能の継続性が可能になります。

"ロール･プロバイダは、LDAP グループが

単純に対処できないような、より特殊な

概念もサポートできます。"

ロール･プロバイダは、LDAP グループが単純に対処できないような、より特殊な

概念もサポートできます。たとえば、ロール･メンバーシップがビジネス･エンティ

ティとの関係に基づいているリレーションシップ・ベースのロール、または、ファ

イアウォール内のユーザーや特定の時間にシステムにアクセスしているユーザー

など、ロール･メンバーシップがユーザー･セッションのコンテキストに基づいて

いるセッション･ロールです。

一元化されたロール･プロバイダのおもな目的は、職務分離（Segregation of Duty,

SoD）ルールをアプリケーション内だけでなく関連するアプリケーション全体に

実施し、企業が正しい管理を行ってシステムの整合性を保証できるようにするこ

とです。これにより、機密性の高い権限に関連するロール割当てに対する承認の

制御も可能になります。結果として、コンプライアンス全般が向上します。

認可サービス

認可サービスの目的は、認可チェックおよび決定をアプリケーションから一元化

されたフレームワークへ外部化できるようにすることです。中核となるアプリ

ケーション･ロジックから認可を切り離すことができると、アプリケーション開発

者は自身のアプリケーション･ロジックに集中でき、認可に変更が必要になるたび

にアプリケーションを書き直す必要がなくなります。アプリケーション開発者は、

対象の許可チェックまたはエンタイトルメントを定義し、それらのエンタイトル

メントを外部サービスにパブリッシュするだけで済みます。アプリケーションが

適切な許可チェックを要求するだけで、認可ポリシーを外部サービスに配置でき

るようになります。システムは、ポリシー機能に関してアプリケーション開発者

が何をサポートできるかに制約されることはなくなります。認可サービスには

個々のアプリケーションよりもはるかに多くの機能があるため、認可ポリシーを

必要に応じてより詳細にすることが可能になります。

"システムは、ポリシー機能に関してアプ

リケーション開発者が何をサポートでき

るかに制約されることはなくなります。

認可サービスには個々のアプリケーショ

ンよりもはるかに多くの機能があるため、

認可ポリシーを必要に応じてより詳細に

することが可能になります。"

この外部化された認可サービスは、エンタイトルメント・モデリングとファイン

グレイン認可をサポートします。eXtensible Access Control Markup Language（XACML）

標準の出現により、アプリケーション･タームでエンタイトルメントを簡単に定義

でき、ID とアプリケーション･データに基づく複雑なポリシー基準を定義できま

す。これらのポリシー定義は、さらに他の ID サービスのコンポーネント、特にロー

ル･プロバイダに基づくことも可能です。ロールは、認可ポリシー定義の主要な部

分です。ロール･プロバイダ･サービスにおける強力なロール概念へアクセスでき

るということは、認可決定をより詳細に行えるということであり、ますます複雑

化するビジネス要件を満たすことができることを意味します。


9


認可決定の一元化により、SoD チェック、監査およびポリシーの実施に統一され

た方法で対処できるアプリケーション環境にコントロール・ポイントが提供され、

コンプライアンスの向上が可能になります。

プロビジョニング･サービス

プロビジョニング・サービスの目的は、アプリケーションを単なる ID データの消

費者でなく、ID プロセスにおける協力者にすることです。プロビジョニング･サー

ビスによって、アプリケーションを IAM コンテキストの管理にも関与させること

ができるさまざまなサービスが提供されます。 "プロビジョニング･サービスは、他の IDサービス（ID およびロール作成、ロール･

メンバーシップ･リクエストなど）の管理

上の必要性を組み合わせ、それらを一元

化された承認、監査および認証環境で実

行します。"

他のサービスがデータ･フローの必要性を排除する一方で、ID サービス層のプロ

ビジョニング･サービスは同一の業務管理を維持します。このサービスは、委任管

理および承認ベースの管理を可能にすることによって、一元化された管理フレー

ムワークを提供します。プロビジョニング･サービスは、他の ID サービス（ID お

よびロール作成、ロール･メンバーシップ･リクエストなど）の管理上のニーズを

組み合わせ、それらを一元化された承認、監査および認証環境で実行します。こ

れによって、SoD チェック、監査および規制ポリシーをすべて実施しながら、他

のサービスが、それらに必要なすべてのデータを使用できるようにします。した

がって、

• アプリケーションのユーザーは、特定のロールまたはエンタイトルメン

トを要求できます

• アプリケーションは、ID をエンタープライズ環境へ追加する自動登録機

能を提供できます

• 監査者は、ある人物による企業全体のアクセスを表示および認証できます。

ある意味では、プロビジョニング･サービスは、接続された ID ライフ・サイクル･

プロセスのバスとして機能すると言えます

制御サービスと監査サービス

制御サービスと監査サービスの目的は、その名前が示すとおり 2 つあります。職

務分離は、前に説明したサービスで何度も出てきました。規制要件および企業セ

キュリティに重点が置かれるようになり、内部制御は企業における主要な課題と

なりました。制御サービスにより、内部制御および他のコンプライアンス関連の

活動を中央で管理および実施する機能が提供されます。制御サービスは、他の ID

サービスと統合されると、実施するサポート（たとえばセキュリティ･ポリシーの

SoD ルール）を提供し、アプリケーションや他の機密データへのアクセスを保護

します。

"制御サービスは、他の ID サービスと統

合されると、実施するサポート（たとえ

ばセキュリティ･ポリシーのSoDルール）

を提供し、アプリケーションや他の機密

データへのアクセスを保護します。"

内部統制の重大性は、このような制御の管理を注意深く監視しなければならない

ところにあります。包括的な監査サービスにより、アプリケーション内で発生し

ているイベントを監査するための共通のサービスが提供される必要があります。

そのサービスは、（配置時に）必要に応じて一元化または分散された監査リポジ

トリに関連付けることができます。監査サービスは、監査データを非標準化して

相互に関連付けることができ、イベント相関、改ざん防止監査証跡、アクティビ

ティ監視および不正検出などのおもな機能を企業に提供します。


10


サービス指向セキュリティ - アプリケーション・セントリック

な観点からの ID 管理

SOS の主要な概念として、これらの ID サービスはアプリケーション・セントリッ

クな ID 管理というビジョンにつながります。開発から配置を経てエンド･ユー

ザーのアクセス、管理およびメンテナンスまで、アプリケーション･ライフ・サイ

クルによってサービスの異なる側面が多数実行されます。アプリケーションを中

心とした観点からすると、ID サービスの成功は、ID サービスがアプリケーション･

ライフ・サイクルの各段階での要件に対処できるかどうかにかかっています。

図 2 アプリケーション･ライフ・サイクル

設計/配置

アプリケーション設計者の役割は、アプリケーションが提供するビジネス機能を

まとめ、インタフェースを提供および概念化することです。インタフェースには

これらの機能が実装され、アプリケーションを使用する異なるタイプのユーザー

に提供されます。これらのインタフェースには、UI、ページフロー、タブ、ボタ

ン、API、Web サービスなどが含まれます。セキュリティの観点からすると、設

計者はセキュリティ･モデルを作り、一般的な認可フレームワークによってこれら

のインタフェースを保護する必要があります。

"ID サービスは、設計段階および開発段階

だけでなく、それ以降のアプリケーショ

ン･ライフ・サイクルでも使用される認可

モデルを取得するために、標準形式を定

義する必要があります。"

開発者は、統合開発環境（IDE）を使用することが求められます。開発者の役割は、

設計段階で定義される認可ポリシーを実際のコードに組み込むことです。また、

開発者は、既存のポリシーに改良を加える必要もあります。アプリケーションは、

実環境での使用をシミュレートして、IDE 環境でテストする必要があります。


11


ID サービスは、設計段階および開発段階だけでなく、それ以降のアプリケーショ

ン･ライフ・サイクルでも使用される認可モデルを取得するために、標準形式を定

義する必要があります。適切なツールおよび IDE との統合により、セキュリティ･

ポリシーおよび実際のコードとの関連を明確に示し、適切なインポート/エクス

ポート機能によって、認可ポリシーを共有するためのツールが設計者および開発

者に提供される必要があります。最終的には、IDE によって、ID サービスと併せ

て、アプリケーションがパッケージ化される前にこれらのセキュリティ･ポリシー

をアプリケーションでテストする機能が提供される必要があります。

パッケージ化

一般的な IDE では、配置の目的でアプリケーションをパッケージ化する機能が用

意されています。J2EE 領域では、アプリケーションを異なるタイプのアーカイブ

（JAR、WAR、EAR など）としてパッケージ化できます。この時点では、このパッ

ケージ化されたアプリケーションにはコード･アーチファクトだけでなく、セキュ

リティ･アーチファクトのすべてのフットプリントおよび開発者によって実装さ

れたコード･アーチファクトとの関連が含まれます。

ID サービスでは、標準形式を定義してから、セキュリティ･アーチファクトをア

プリケーション･アーカイブにパッケージ化します。定義された標準形式は、設計

段階および開発段階時に、すべてのセキュリティ要件を取得している必要があり

ます。さらに、アプリケーションが最終的に配置される際にセキュリティ･アーチ

ファクトをランタイム環境へ移すため、このような標準形式は配置メカニズムに

よって認識されなければなりません。この標準を使用することで、IDE は配置時

に認識可能な形式で、セキュリティ･アーチファクトをアプリケーション･アーカ

イブへパッケージ化できます。セキュリティ･アーチファクトのセットは、基本的

にアプリケーションが最初に配置される際の標準のセキュリティ･シード･データ

になります。

配置

アプリケーションは、パッケージ化されると複数の方法で配置されます。リリー

ス製品は、インストーラによって配置されます。顧客アプリケーションは、ミド

ルウェア･フレームワークによって配置されます。セキュリティを意識したあらゆ

るアプリケーションにとって、配置は実行以上の意味を持ちます。IDサービスは、

ランタイム環境にセキュリティ･アーチファクトが正確に配置され、接続されるよ

うにします。 "さらに、ID サービスによって、サード･

パーティのシングル･サインオン製品な

どの外部コンポーネント、XACML エンジ

ンなどの外部ポリシー･エンジンや外部

SoD エンジンと統合するためのメカニズ

ムが提供されます。"

ID サービスは、配置メカニズムによって認識される標準形式を定義してから、ア

プリケーションの配置時にセキュリティ･アーチファクトを配置します。このよう

な形式は、セキュリティ･アーチファクトを設計段階および開発段階からランタイ

ム環境へ移動させるブリッジの役割を果たします。標準は、両側でセキュリティ･

アーチファクトを適切に取得するのによく知られた形式を使用して、IDE と異な

るランタイム･コンテナ･ベンダーとの間のハンドシェイクを実行します。

ランタイム環境は、顧客の開発環境、ステージング環境、QA 環境または実際の本

番環境である場合があります。配置されたアプリケーションが完全に機能する前

に、そのアプリケーションが使用可能な ID サービスを利用するように構成する必

要があります。ID サービスは、配置を構成し、このランタイム ID インフラスト


12


ラクチャの接続を設定するためのツールを提供します。さらに、サード･パーティ

のシングル･サインオン製品などの外部コンポーネント、XACML エンジンなどの

外部ポリシー･エンジンや外部 SoD エンジンと統合するためのメカニズムを提供

します。

ID サービスは、セキュリティ･アーチファクトに正確にパッチが適用され、配置

後のすべての拡張機能やカスタマイゼーションを保存できるようにし、パッチ、

アップグレード、移行などの他のアプリケーション･ライフ・サイクル･アクティ

ビティにも対応する必要があります。

ランタイム･インフラストラクチャ

アプリケーションのランタイム･インフラストラクチャは、エンド･ユーザーに提

供されるインタフェースからデータベース層にまで広がっています。ID サービス

は、サービスそのものだけでなく、プロバイダに依存しない方法でアプリケーショ

ンをそれらのサービスに統合するフレームワークを提供します。

サービス･プロバイダが信頼できるソース（信頼性の高い ID リポジトリやロール･

リポジトリなど）として機能する場合は、API や Web サービスなどを使用したセ

キュアな方法で他のアプリケーションによるランタイム消費に関するデータを提

供するために、ID サービスは、サービスが標準メカニズムを使用できるようにし

ます。

このようなサービス･プロバイダは、バックエンド･ストレージとこのデータにア

クセスするためのサービスの両方に対して、スケーラビリティ、パフォーマンス、

高可用性、バックアップおよびリカバリ・メカニズムにも焦点を当てる必要があ

ります。

管理 "エンタープライズ･アプリケーションは、

多数の異なるタイプのユーザーによって

管理されます。（中略）このような管理

用のプラットフォームを提供することが、

ID サービスのおもな目的です。"

エンタープライズ･アプリケーションは、多数の異なるタイプのユーザーによって

管理されます。たとえば、セキュリティ管理者は、アプリケーションの動作を改

正するために土台となるセキュリティ･アーチファクトを変更することがありま

す。委任管理者は、ある従業員のロールを変更することによって、その従業員に

対してアプリケーションの特定領域へのアクセスを取り消す場合があります。エ

ンド･ユーザーは、セルフサービスでパスワードをリセットするかもしれません。

監査者は、企業内の機密データを保護する特定のポリシー実施の証拠を確認する

場合もあります。このような管理用のプラットフォームを提供することが、IDサー

ビスのおもな目的です。

ポリシー管理

ポリシー管理では、認可ポリシーそのものを扱います。アプリケーションの配置

直後に、アプリケーションとパッケージ化されて提供されたセキュリティ･アーチ

ファクトがポリシー･リポジトリで使用できるようになります。これらのポリシー

が実際のエンド・ユーザーと関連付けられるまでは、これらの認可ポリシーに基

づくアプリケーションは正しく機能しません。

ID サービスは、ランタイム環境でセキュリティ･ポリシーを表示するための標準

形式を定義する必要があります。この標準形式によって、ポリシーおよびポリシー

がランタイム時にエンド･ユーザーに関連付けられる方法が取得されます。たとえ

ば、アプリケーション内のロールは、エンタープライズ･ロール管理システムのビ

ジネス･ロールまたは LDAP グループにマッピングされます。


13


認可サービスにより、ポリシー管理用に、一元化されたフレームワークと一緒に

中央ポリシー･リポジトリが提供されるため、管理者は新規のセキュリティ･ポリ

シーを表示、変更および作成できます。認可サービスは、必要に応じて SoD サポー

トなどの監査およびコンプライアンスのサポートも提供します。ロールおよび

ロール階層の定義では、ユーザーと権限との関係が変更される際にこのサポート

が必要となります。

ユーザー/ロール管理

アプリケーション・セントリックな見方をすると、ユーザー管理ではおもに ID の

ライフ・サイクルが扱われます。ID プロバイダは、ID データ上に中央の許可レベ

ルを提供します。複数のユーザー･リポジトリが必要な場合は、ID プロバイダは

所要な仮想化を提供し、使用しているアプリケーションから詳細を抽象化します。

ID サービスは、ID 情報を表示し、ID 情報にアクセスするために標準形式を定義

する必要があります。標準形式によって、アプリケーションがアプリケーション

自体の ID 要件を特定でき、また、標準形式は、適切な ID データを提供するため

に ID プロバイダによって認識される必要があります。

"ID サービスは、ID 情報を表示し、ID 情

報にアクセスするために標準形式を定義

する必要があります。" "標準形式によっ

て、アプリケーションがアプリケーショ

ン自体の ID 要件を特定でき、また、標準

形式は、適切な ID データを提供するため

に ID プロバイダによって認識される必

要があります。"

また、ID サービスは、SoD サポートや Restricted Party Screening などのコンプライ

アンス向けの必要なサポートや、この分野での徹底的な監査およびレポート機能

とともに、ユーザー作成、自動登録、セルフサービス、委任管理、プロキシ･ユー

ザー･サポートなどの、基礎になるサポートを提供します。プロビジョニングが必

要な場合、プロビジョニング･プロバイダがさまざまなターゲット間のやりとりを

サポートします。

ID プロバイダと同様に、ロール･プロバイダは、ロール管理、ロール･リクエスト、

ロール割当て、ロール･カタログなどのための中央ロール･リポジトリおよびフ

レームワークを提供します。ロールは認可フレームワークの必要不可欠なパーツ

であるため、ロール･プロバイダの高度な機能によって、管理者の柔軟性と制御が

向上します。ユーザー管理と同様に重要なのは、ロール･プロバイダは、ロール割

当てやロール変更の際の監査およびレポート作成機能とともに、ロール割当ての

リクエスト、承認および自動プロビジョニング中に SoD サポートなどのコンプラ

イアンス向けサポートを提供する必要があります。

ガバナンス、リスクおよびコンプライアンス管理

SoD の必要性は、IT ガバナンス、リスクおよびコンプライアンスの広範な領域へ

の踏み石にすぎません。アプリケーション内でセキュリティ･ポリシーを実行する

機能の方が明らかに重要です。ただし、さらに重要なのは、ID サービスは、これ

らのセキュリティ･ポリシーや、個々のアクセスを変更する場合がある他のアク

ティビティのライフ・サイクルを正しく管理し監査する機能を提供する必要があ

るということです。制御サービスおよび監査サービスは、組み込むアプリケーショ

ンや ID サービスの基礎となるインフラストラクチャだけでなく、ポリシーおよび

制御を管理する管理フレームワークも提供します。これによって管理者は、ポリ

シーおよび制御に関する重要な変更の制御および追跡、SoD などの重要なポリ

シー実行の管理および監視、疑わしい活動やポリシー違反の検知および警告の受

信などが可能になります。このようなレポートおよび警告機能によって、監査者

やセキュリティ担当者などに必要な入力が提供されます。

"ただし、さらに重要なのは、ID サービス

は、これらのセキュリティ･ポリシーや、

個々のアクセスを変更する場合がある他

のアクティビティのライフ・サイクルを

正しく管理し監査する機能を提供する必

要があるということです。"


14


ホット・プラグ可能

ID サービスの目的の 1 つは、ID インフラストラクチャの可動部分の数を単純化お

よび削減することです。ID インフラストラクチャの複雑な性質により、困難な問

題をもたらすためです。異機種を使用する今日のエンタープライズ配置では、ID

サービスの成功のために、ホット・プラグ可能なフレームワークがアプリケーショ

ン･ライフ・サイクルのすべての段階において必要不可欠となります。

"異機種を使用する今日のエンタープラ

イズ配置では、ID サービスの成功のため

に、ホット・プラグ可能なフレームワー

クがアプリケーション･ライフ・サイクル

のすべての段階において必要不可欠とな

ります。"

開発者は、選択した IDE を使用できる必要があります。ID サービスで定義された

開発フレームワークは、すべての共通 IDE に移植できる必要があります。

ID サービスは、アプリケーションのために特定のランタイム環境を前提としてい

ません。J2EE 環境においては、どのようなベンダーのコンテナでも実行できると

いうことを意味します。

異機種環境では、ID サービスが、サービス自体が必要としているプロバイダの機

能を満たしている場合は、ID サービスによって、顧客は、顧客が選択した ID 管

理コンポーネントを必要に応じて柔軟に使用できる必要があります。

現行製品

オラクルの現行製品は、弊社のサービス指向セキュリティに関するビジョンに

そって提供されています。Oracle Fusion Middlewareは、Oracle Application Server、

Oracle SOA suiteおよびOracle Identity Management Suiteを通じて包括的な製品

群を提供し、このドキュメントで言及しているほとんどの分野に対応しています。

開発およびパッケージ化

Oracle SOA Suiteの一部であるOracle JDeveloperは、J2EEアプリケーションの開発

の際にIDEを提供します。ID管理の観点からすると、これによって設計者や開発

者は、オラクルのJava Authentication and Authorization Service（JAAS）の実装によ

り、認可ポリシーのさまざまな側面を定義できます。Oracle JDeveloperにも、開発

者によるIDE内のアプリケーションや認可ポリシーのテストを可能にする組込み

アプリケーション･コンテナが含まれます。

また、Oracle JDeveloper 10g Release 3 では、豊富なセキュリティ･サポートを含む

Oracle Application Development Framework（Oracle ADF）が導入されており、こ

れによって開発者は、ビジネス･サービスによって公開されるイテレータ、属性お

よびメソッドへのファイングレイン・アクセス制御を定義できます。Oracle

JDeveloperには、開発者による開発段階中のセキュリティ･ポリシーの作成を援助

するOracle ADF Security Wizardsなど、多数のOracle ADFセキュリティ機能が実装

されています。


15


パッケージ化の見地からすると、Oracle JDeveloper は、すべてのセキュリティ･アー

チファクトをアプリケーション・アーカイブの一部としてパッケージ化し、ラン

タイム配置環境へ移動させます。

ランタイム

Oracle Application Serverは、J2EEランタイム環境を提供します。開発中に定義さ

れる認可ポリシーは、配置中にランタイム･コンテナのOracle Container 4 Java

（OC4J）で使用可能になります。ポリシー･データは直接LDAPに配置または移行

できるため、企業ディレクトリのパフォーマンス、スケーラビリティおよび高可

用性の利点を得られます。

また、OC4Jは、他の多くのID管理インフラストラクチャ･コンポーネントも利用

できます。シングル･サインオンに関しては、OC4JはOracle Access Managerと同

様に他のサード･パーティのシングル･サインオン･ソリューションを使用するよう

に構成できます。Oracle Internet DirectoryやOracle Virtual DirectoryやMicrosoft

Active Directoryなどの他のサード･パーティのLDAPを含め、エンタープライズ

LDAPの形式でのエンタープライズIDストアは、認証および認可のためのIDスト

アとして使用できます。これらのエンタープライズIDストアは、OC4JによるLDAP

ベースのポリシー･ストアとしても使用できます。

認証の面では、Oracle Enterprise Single Sign-Onは、デスクトップ･シングル･サイ

ンオンのサポートを提供します。Oracle Identity Federationは、ドメイン間のシン

グル･サインオンに、包括的な複数プロトコル・フェデレーション･ソリューショ

ンを提供します。Oracle Adaptive Access Managerでは、強力な複数ファクタおよ

び相互認証機能が使用できます。さらに、リアルタイムにデータを分析し、不正

の可能性を検知するリスク管理機能を提供します。

管理

ユーザー管理の面では、Oracle Identity Managerによって、自動登録、セルフサー

ビス、委任管理など、ID管理およびエンタープライズ・プロビジョニング機能が

十分に定義されたセットが提供されます。Oracle Identity Managerは、RDBMS、

LDAPサーバー、オペレーティング･システムなどのさまざまなバックエンド･ター

ゲットや、SAP、PeopleSoft、Oracle EBusiness Suite Release 11/Release 12 などのア

プリケーションをプロビジョニングする機能を提供します。カスタム･コネクタを、

カスタム･アプリケーションの他のプロビジョニングのニーズに対応するように

構築することもできます。

Oracle Role Managerによって、ビジネス･ユーザー、組織およびエンタイトルメ

ントの間の関係に関する認可ソースとして機能できるエンタープライズ･ロール･

ライフ・サイクル管理ソリューションが提供されるため、ITインフラストラクチャ

内のロール･ベースのプロビジョニングおよびアクセス制御の自動化が可能にな

ります。Oracle Role ManagerとOracle Identity Managerの間の統合によって、ロール

管理とプロビジョニング･ソリューションが結合し、エンタープライズ環境でアプ

リケーションの自動化とコンプライアンスのニーズを促進する、強力な組合せが

作成されます。

Oracle 10g Release 3 では、JAASセキュリティ･ポリシーは、ポリシー･ストアを直


16


接変更せずに JAASポリシーを管理する手段を提供する、Oracle Enterprise

Managerを使用して管理できます。ポリシー･ストアには、本番環境の多くでは

LDAPを使用しています。

さらに、Oracle Enterprise Managerは、システム管理者およびアプリケーション管

理者全体に、システム管理およびパフォーマンス監視機能を提供します。Oracle

Management Pack for Identity Managementは、Oracle Identity Managementの管理お

よび監視を効率化することにより、サービス･レベルを向上させ、高可用性を保証

します。オラクルやオラクル以外のシステムのシステム・スパニング・ディレク

トリ、ファイアウォール、アプリケーション･サーバー、ビジネス･アプリケーショ

ンを管理する単一のコンソールを提供し、自動構成管理、障害分離および診断、

およびシステムの 1 段階での検出を行います。

ロードマップ

オラクルのコンポーネントは進化し続けています。そのため、オラクルのビジョ

ンへ近づくために改良を重ねています。ただし、サービス指向セキュリティをサ

ポートするコンポーネントすべてにメッセージが十分に理解され、浸透する必要

があります。すでにオラクルのコンポーネントの多くは、十分に統合されパッケー

ジ化された標準ベースのアプリケーション・セントリックな ID 管理へと移行する

ための次の段階へと進んでいます。次に、重要な点をいくつか説明します。

Oracle Access Manager

次世代シングル･サインオン（SSO）

次世代 SSO 製品は、オラクルの現行のシングル･サインオン製品が提供する既存

の認証メカニズムを統合し強化します。SOS の観点からすると、次世代の製品で

は、オラクルや他のサード･パーティのソリューションまたはカスタマイズされた

ソリューションの他の認証メカニズムと統合するために、標準ベースのソリュー

ションやプラッガブルなアーキテクチャを提供するように計画されています。

ファイングレイン認可（FGA）

FGA は、Oracle Fusion Middleware 内の既存の認可エンジンを拡張することを目的

としています。これにより、セキュリティ･モデルは、RBAC モデルから Attribute

Base Access Control（ABAC）などの他のセキュリティ原理へ拡張され、ファイン

グレインなポリシーを定義する際に追加の機能が提供されます。これにより、一

時性（開始日/終了日など）に基づくアクセス制御や IP ベースのアクセス制御は、

ポリシーの管理やストレージが一元化された、単一の認可モデルに一元化できる

ようになります。

Oracle Identity Manager および Oracle Role Manager

このドキュメントからわかるように、ユーザーおよびロール管理の側面は、アプ

リケーション・セントリックな ID 管理において重要です。Oracle Identity Manager

およびOracle Role Managerの IDサービスの要件は、エンタープライズ・プロビジョ

ニング･システムやロール管理システムの要件と同様です。SOS のビジョンでは、

Oracle Identity Manager および Oracle Role Manager が、ID、プロビジョニングおよ


17


びロール･プロバイダとしての要件を満たすためには、よりアプリケーション・セ

ントリックな管理を行うことが求められます。また、この 2 つの製品は、ユーザー

およびロール管理、承認ワークフロー、通知などの領域で同様の機能を共有して

います。目的の 1 つは、このような共有サービスを Oracle Identity Manager および

Oracle Role Manager だけでなく、Oracle の ID 管理全体に渡って一元化し、統合お

よび管理を向上させることです。

標準

アプリケーション･ライフ・サイクルのおもな側面の 1 つは、セキュリティ情報を

1 つの段階から別の段階へと円滑に移動させる機能です。セキュリティの問題は、

コンポーネント固有のものでも、ベンダー固有のものでもありません。標準が定

義されるべき領域の多くでは、標準ベースの形式が欠けています。

認可の面では、eXtensible Access Control Markup Language（XACML）が認可モデ

ルを取得する際の出発点になります。これによって、アクセス制御を定義するポ

リシー言語が提供されます。開発中および配置中に XACML ポリシーを表示する

方法、ランタイム中に XACML ポリシーへのアクセスを効率的に提供する方法な

ど、XACML をアプリケーション･ライフ・サイクルの他の領域へ拡張する方法を

確立するために、大量の作業が行われています。

IDの面では、標準を定義する際はオラクルのIdentity Governance Frameworkが対

処しています。

アプリケーションの面では、Client Attribute Requirements Markup Language（CARML）

によって、アプリケーション･ユーザー属性のマッピングに対処する重要なオプ

ションが提供されます。これによって、設計者および開発者が"ID要件"を配置管

理者へ伝達する宣言的な方法が提供され、ID仮想化への道が開かれます。さらに、

CARMLの 2 番目の目的は、"IDデータ"のプライバシ制約の表現をサポートするこ

とです。

IDプロバイダの面では、Attribute Authority Policy Markup Language（AAPML）

によって、IDソースは、アプリケーションが情報を使用できる方法に対する制約

を指定できます。

2 つの標準は、同時に使用されることでアプリケーションと ID プロバイダ間のハ

ンドシェイクを定義し、ユーザー･データおよび ID 情報のフローを管理し保護す

る方法を提供します。

ガバナンス、リスク管理およびコンプライアンス（GRC）

GRCは、許可/権限およびロール階層/継承を修正できる認可ポリシー管理全般だけ

でなく、ユーザー/ロール・プロビジョニングにおいても重要な部分です。短期的

なロードマップには、Oracle Governance, Risk, and Compliance Suiteの一部の

Oracle Application Access Control Governorとの統合が含まれ、Oracle Identity

ManagerやOracle Role Managerなどの製品において実施および監査のための職務分

離サポートを提供します。


18


結論

サービス指向セキュリティは、ID 管理領域の多数の側面に対し、一連の固有の課

題を示します。ID サービスの導入により、今日のソリューションの多数の欠点に

対処する際に真の価値がもたらされます。アプリケーション・セントリックな観

点からすると、究極の目的は、ID 管理のあらゆるニーズに対処する標準ベースの

アプリケーション･ライフ・サイクルに到達することです。これは、開発、配置お

よびランタイム･サポートのフレームワーク、異種混交性や他の既存または新しい

業界標準を柔軟にサポートするモデル、オラクルだけでなく他のソフトウェア･

ベンダーによって採用されるモデル、そしてさらに重要なこととしてアプリケー

ション・セントリックな ID 管理環境においてアプリケーションの開発を希望する

顧客に採用されるモデルを提供することによって実現されます。

オラクルのセキュリティ･テクノロジについて

詳しくはを参照してください。 http://www.oracle.com/security


19


http://www.oracle.com/security

サービス指向セキュリティ - アプリケーション・セントリックな観点からの

ID 管理 2008 年 4 月著者：Stephen Lee 共著者：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 およびその子会社、関連会

社の登録商標です。その他の名称はそれぞれの会社の商標です。

Technology

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