| Oracle® Fusion Middleware Oracle Security Developer Toolsリファレンス 11gリリース1 (11.1.1) B61386-02 |
|
 前 |
 次 |
| Oracle® Fusion Middleware Oracle Security Developer Toolsリファレンス 11gリリース1 (11.1.1) B61386-02 |
|
前 |
次 |
セキュリティ・ツールは、現在のアプリケーション開発プロジェクトにとって重要な構成要素です。市場のニーズや政府の規制により、重要なデータを機密保護し、改ざんや変更を防ぐことが求められます。
Oracleセキュリティ開発ツールによって、安全なメッセージングなどの基本タスクから、サービス指向アーキテクチャの安全な実装といった複雑なプロジェクトに及ぶ、堅牢なセキュリティ・アプリケーションの開発に必要な暗号ビルディング・ブロックが提供されます。これらのツールは、暗号化、公開鍵インフラストラクチャ、Webサービス・セキュリティおよびフェデレーテッド・アイデンティティ管理を基盤として構築されています。
様々なOracle製品がOracleセキュリティ開発ツールを利用します。たとえば、次のような製品です。
Oracle BPEL Process Manager、Oracle Collaboration Suiteなどのアプリケーション
システム・コンポーネントのSSL構成機能を含むOracle Platform Security Services、およびOracle Identity Management製品、Oracle Enterprise ManagerおよびOracle Databaseサーバーで使用されるOracle Wallet
Oracle Web Services Manager(OWSM)、Business Integration(B2B)、Oracle Portal、Oracle Identity Federationなどのシステム・コンポーネント
この章では、このような基礎を形成するセキュリティ・テクノロジについて詳しく説明し、Oracleセキュリティ開発ツールのコンポーネントを紹介します。ここでは、次のトピックについて説明します。
データは信頼できない通信チャネルを経由するため、暗号化により、侵入者による傍受(受動的攻撃)または変更(能動的攻撃)から送信されるメッセージを守ります。メッセージを保護するには、発信者が暗号化ツールを使用して、読取り可能なプレーン・メッセージ、すなわち平文を暗号化された暗号文に変換します。元のテキストは存在しますが、傍受されたとしても解読できない形式に変更されています。メッセージの受信者も暗号化ツールを使用し、暗号文を元の読取り可能な形式に復号化します。
暗号化では、次の機能が提供され、インターネットなどネットワークを介した通信が保護されます。
認証: 情報の発信元が信頼できることを受信者に保証します。通常、認証は、メッセージ認証コード(MAC)、デジタル署名およびデジタル証明書を使用して達成されます。
機密保護: 意図した受信者のみがメッセージを読み取ることを保証します。通常、機密保護は暗号化によって実現されます。
整合性: 受信したメッセージが元のメッセージから変更されていないことを保証します。通常、整合性は暗号化ハッシュ関数を使用して保証されます。
否認防止: 所定の送信者が特定のメッセージを実際に送信したことを証明する方法です。通常、否認防止はデジタル署名を使用して達成されます。
平文と暗号文をマップするために使用される数学的な演算は、暗号化アルゴリズム(または暗号)と呼ばれます。暗号化アルゴリズムでは、マップ対象のテキストの他に、少なくともマッピング・プロセスを制御する値が必要です。この値は、鍵と呼ばれます。
基本的には3つのタイプの暗号化アルゴリズムがあり、暗号化と復号化に使用される鍵の数と、適用方法や使用方法によって分類されます。基本タイプの暗号化アルゴリズムを次に示します。
各タイプは特定の用途に最適化されています。ハッシュ関数はデータの整合性の保証に適しています。対称暗号化はメッセージの暗号化に最適です。非対称暗号化は、鍵の安全な交換、認証および否認防止に使用されます。また、非対称暗号化はメッセージの暗号化にも使用できますが、頻繁ではありません。対称暗号化は非対称暗号化の約1000倍の速度で処理されるため、非対称暗号化よりも暗号化に適しています。
対称暗号化アルゴリズム(または秘密鍵暗号化)は、暗号化と復号化の両方で1つの鍵を使用します。送信者が鍵を使用して平文を暗号化し、暗号文を受信者に送信します。受信者は同じ鍵を使用してメッセージを復号化し、平文に戻します。送信者と受信者の両方が鍵を知っている必要があります。対称暗号化の最大の問題は、鍵を安全に配布することです。
一般的に、対称暗号化スキームはブロック暗号とストリーム暗号に分類されます。ブロック暗号では、固定サイズのデータ・ブロック(通常は64ビット)が一度に1つずつ暗号化され、各ブロックには同じ鍵が使用されます。現在使用されている一般的なブロック暗号には、Blowfish、AES、DESおよび3DESがあります。
ストリーム暗号は、一度に1ビットで処理され、特定の形式のフィードバック・メカニズムの実装によって、鍵が絶えず変更されます。RC4は、SSLプロトコルを使用した安全な通信のために使用されるストリーム暗号の一例です。
非対称暗号化アルゴリズム(または公開鍵暗号化)では、平文の暗号化と暗号文の復号化にそれぞれ別の鍵が使用されます。どちらの鍵を先に適用してもかまいませんが、暗号が機能するためには両方の鍵が必要です。
非対称暗号化では、1つの鍵が公開鍵として指定され、広く使用されます。もう1つの鍵は秘密鍵に指定され、第三者には公開しません。このスキームでメッセージを送信する場合、送信者は受信者の公開鍵を使用して情報を暗号化します。受信者は自身の秘密鍵を使用して暗号文を復号化します。この方法は、メッセージの送信者を証明する場合にも使用できます(否認防止)。送信者は自身の秘密鍵を使用して平文を暗号化でき、受信者は、送信者の公開鍵を使用してメッセージを復号化するため、メッセージがその送信者から実際に送信されたことがわかります。
現在使用されている一般的な非対称アルゴリズムには、RSA、DSAおよびDiffie-Hellmanがあります。
ハッシュ関数 (またはメッセージ・ダイジェスト)は、本質的に鍵を使用しない一方向暗号化アルゴリズムです。かわりに、平文に基づいて固定長のハッシュ値を計算しますが、この値から、平文の内容または長さを復元することはできません。通常、ハッシュ・アルゴリズムは、ファイルの内容のデジタル・フィンガープリントを提供するために使用され、ファイルが侵入者やウイルスによって変更されていないことを確認するためによく使用されます。また、ハッシュ関数は、一般に多くのオペレーティング・システムでパスワードの暗号化に利用されています。ハッシュ関数は、ファイルの整合性の保持にも有用です。一般的なハッシュ関数には、MD2、MD4、MD5およびSHAなどがあります。
公開鍵インフラストラクチャ(PKI)は、パブリック・ネットワークおよびプライベート・ネットワークでの安全な通信を実現するために設計されています。データの安全な送信と格納のみでなく、PKIによって、電子メールの安全性、デジタル署名およびデータの整合性が実現されます。
このような機能は公開鍵暗号化を介して提供されます。これは、関連する1組の暗号鍵を使用して、送信者のアイデンティティ確認(デジタル署名)や、メッセージのプライバシ確保(暗号化)を行う数学的な技術です。PKIの機能によって、インターネットなど安全性の低いネットワークでの安全な情報交換がサポートされます。
PKIの目的を達成するためには、次の要素が必要です。
通信を保護する暗号化アルゴリズムと鍵
公開鍵を所有者のアイデンティティに関連付けるデジタル証明書
暗号化を広く安全に使用できるようにする鍵の配布方法
鍵とその正当な所有者の関係を保証する、認証局(CA)と呼ばれる信頼できるエンティティ
CAに対する証明書リクエストの情報を確認する登録局(RA)
利用者は、CAが発行した証明書とそれに含まれる公開鍵を使用して、デジタル証明書を確認し、データを暗号化します。
暗号化技術では、送信者と受信者のみが知っている鍵と呼ばれるテキストまたは数値がよく使用されます。
両者が同じ鍵を使用する暗号化スキームは対称と呼ばれます。対称システムを利用する際の難点として、鍵を傍受されずに両者に渡すことや、1組の受信者と送信者ごとに個別の鍵が必要になるため、各ユーザーが多数の鍵(受信者ごとに1つずつ)を管理する必要があることがあげられます。
公開鍵暗号化では、数学的に関連する暗号鍵(公開鍵と秘密鍵)の鍵ペアが使用されます。鍵ペアの使用方法は、「非対称暗号化アルゴリズム」を参照してください。
表1-1に、公開鍵と秘密鍵の利用者と目的をまとめています。
認証局は、デジタル証明書を作成して、公開鍵と特定のエンティティとの関係を検証します。このデジタル証明書には、公開鍵、鍵所有者および署名する認証局の情報が含まれます。エンティティのアイデンティティを証明するためにPKI証明書を使用することは、運転免許証やパスポートで身分を証明することと似ています。
多数の規格やプロトコルで、PKI証明書の実装がサポートされています。
暗号メッセージ構文
暗号メッセージ構文(CMS)は、Internet Engineering Task Force (IETF)によって開発されたデータ保護の一般的な構文です。署名付きデータ、エンベロープ・データ、ダイジェスト、暗号化データなど、様々なコンテンツ・タイプがサポートされます。CMSでは複数のカプセル化が可能になるため、たとえば、事前に署名されているデータを、受け取った相手がエンベロープに入れることができます。
CMSで生成される値は、X.509基本エンコーディング規則(BER)を使用してエンコードされます。つまり、値は8ビット文字列として表されます。
Secure/Multipurpose Internet Mail Extension
Secure/Multipurpose Internet Mail Extension(S/MIME)は、デジタル署名と暗号化を使用することでMIMEデータを保護するInternet Engineering Task Force(IETF)の規格です。
S/MIMEでは、電子メッセージ・アプリケーションのために次の暗号化セキュリティ・サービスが提供されます。
認証
メッセージ整合性と発信元の否認防止(デジタル署名の使用)
プライバシとデータ・セキュリティ(暗号化の使用)
Lightweight Directory Access Protocol
Lightweight Directory Access Protocol (LDAP)は、一般的に使用されているディレクトリ・サーバーとの間で情報の取得とポストを行うためのオープン規格です。公開鍵インフラストラクチャ(PKI)システムでは、多くの場合、ユーザーのデジタル証明書はLDAPディレクトリに格納され、必要に応じて、リクエスト・アプリケーションやリクエスト・サービスによってアクセスされます。
タイムスタンプ・プロトコル
タイムスタンプ・プロトコル(TSP)システムでは、信頼できるサード・パーティのタイムスタンプ局(TSA)がデジタル・メッセージのタイムスタンプを発行します。タイムスタンプによって、メッセージが特定のエンティティから特定の時刻に送信されたことが証明され、オンライン・トランザクションに否認防止機能が提供されます。
タイムスタンプ・プロトコルでは、RFC 3161に指定されているように、デジタル・メッセージのタイムスタンプに関連するエンティティ、メッセージ書式および転送プロトコルが定義されます。
タイムスタンプ・システムが機能する方法を確認するために、Sallyが文書に署名し、タイムスタンプを必要とする場合について説明します。彼女が安全なハッシュ関数を使用して文書のメッセージ・ダイジェストを計算し、メッセージ・ダイジェスト(文書自体ではなく)をTSAに送信すると、メッセージ・ダイジェスト、それがTSAサーバーで受信された日時、およびTSAの署名で構成されるデジタル・タイムスタンプが、TSAから返されます。メッセージ・ダイジェストからは文書の内容に関する情報はわからないため、TSAがタイムスタンプの際に文書を傍受することはありません。その後、Sallyは文書とタイムスタンプを一緒に示して、文書の作成時刻を証明できます。ベリファイアは、文書のメッセージ・ダイジェストを計算し、タイムスタンプのダイジェストと一致することを確認して、タイムスタンプのTSAの署名を検証します。
Online Certificate Status Protocol
Online Certificate Status Protocol (OCSP)は、デジタル証明書の有効性をチェックする一般的な2つの方法のうちの1つです。もう1つの方式は証明書失効リスト(CRL)と呼ばれ、OCSPよりも古く、使用シナリオによってはOCSPに置き換えられています。
OCSPでは、クライアント側でリストを最新に保つために、更新分を頻繁にダウンロードする必要があるというCRLの大きな制限が解消されています。ユーザーがサーバーにアクセスしようとすると、OCSPによって証明書ステータス情報に対するリクエストが送信されます。サーバーは、レスポンス(有効、失効または不明)を返信します。このプロトコルによって、サーバー(証明書ステータスを格納する)とクライアント・アプリケーション(ステータスが通知される)の間の通信の構文が指定されます。
Certificate Management Protocol
Certificate Management Protocol(CMP)を使用すると、証明書の作成および管理に関連する処理のすべてを実行できます。CMPでは、公開鍵インフラストラクチャ(PKI)の構成要素(認証局(CA)、登録局(RA)、証明書発行先のエンド・エンティティなど)間の相互作用がサポートされます。
安全で信頼できるユーザーの認証
信頼できる認証は次の2つの要因に基づきます。1つは、公開鍵と秘密鍵のペアの秘密鍵部分の所有を証明することで、これは、公開鍵を使用する自動手順で確認されます。もう1つは、特定のアイデンティティへの公開鍵の所属が認証局によって検証されることです。PKIに基づくデジタル証明書では、鍵ペアに基づいてこのアイデンティティの接続が検証されます。
データ整合性
公開鍵と秘密鍵のペアの秘密鍵を使用してデジタル・トランザクションに署名すると、送信中にデータを変更することが困難になります。このようなデジタル署名は、送信者の秘密鍵で暗号化された元のメッセージのダイジェストがコード化されたものです。受信者は、送信者の対応する公開鍵を使用して、メッセージの送信者、およびメッセージが変更されていないことを確認できます。メッセージまたはダイジェストの変更があると、公開鍵を使用した検証が失敗するため、メッセージを信頼できないことが受信者に伝わります。
否認防止
PKIは、メッセージの送信者を証明する場合にも使用できます。送信者は自身の秘密鍵を使用して平文を暗号化してデジタル署名を作成し、受信者は、送信者の公開鍵を使用してメッセージを復号化するため、メッセージがその送信者から実際に送信されたことがわかり、メッセージの発信者がメッセージを否認することは困難になります。この機能は否認防止と呼ばれます。
送信または格納されている情報への未許可アクセスの防止
公開鍵から秘密鍵を導出するためにはかなりの時間と労力が必要になるため、鍵ペアの所有者以外がメッセージを復号化することは考えられません。
Webサービスによって、会社などの組織はWebベース・アプリケーションを統合する標準的な方法を得ます。これには、XML、SOAPおよびWSDLといったオープンな標準テクノロジが使用されます。
SOAPは、サービス指向環境で情報を交換するための軽量プロトコルです。このような環境では、アプリケーションは、他のアプリケーションで使用するように選択した機能(ビジネス・ロジックなど)を公開できます。SOAPは、アプリケーションがこれらのサービスを提供および消費するための手段を提供します。これは分散非集中管理Webサービス・アプリケーション環境でのメッセージ転送のためのXMLベースのプロトコルです。
コア仕様のSOAPによってXMLやWebサービスに関連する多くの問題が解決されますが、機密保護、整合性、メッセージ認証、否認防止など、メッセージ・セキュリティ要件に対処する手段は提供されません。SOAPを保護するニーズが高まったため、OASISは次のようなWebサービス・セキュリティの規格を提唱しています。
SOAPメッセージの署名と暗号化を可能にする拡張機能の指定
セキュリティ・トークンとメッセージを関連付ける汎用メソッドの指定
メッセージに組み込まれるトークンの特徴を指定するための、その他の手段の提供
Security Assertions Markup Language(SAML)は、インターネット上でセキュリティ情報を交換するためのXMLベースのフレームワークです。SAMLを使用すると、通常は相互運用できない様々なセキュリティ・サービス・システム間で、認証や認可の情報を交換できます。
SAML 1.0、1.1および2.0仕様は、それぞれ2002年、2003年および2005年にOrganization for the Advancement of Structured Information Standards(OASIS)に採用されました。OASISは、E-Business規格の開発、統合および採用を促進する国際的な非営利団体です。
SAML 2.0では、Liberty ID-FF、Shibboleth、SAML 1.0/1.1の各フェデレーション・プロトコルが統合されています。
SAMLは、アイデンティティ(電子メール・アドレスまたはディレクトリのリスト)をサブジェクト(ユーザーまたはシステム)に関連付けて、特定のドメインでのアクセス権を定義します。基本SAML文書はAssertionで、Subject(通常はユーザー)に関する事実の宣言が含まれます。SAMLでは、次の3種類の宣言(Statement)が提供されます。
AuthnStatement: ユーザーが特定の方法で特定の日時に認証されたことを表明します。
AttributeStatement: ユーザーが特定の属性や詳細情報(従業員番号や口座番号など)に関連付けられていることを表明します。
AuthzDecisionStatement: 特定のリソースに対する特定アクセスのユーザー・リクエストが許可または拒否されたことを表明します。
アサーションは、すでに発生したイベントに関して生成されるXML文書です。SAMLによって資格証明に関するアサーションが作成されますが、実際にユーザーの認証や許可が行われるわけではありません。例1-1に、SAMLPレスポンス・メッセージにラップされた典型的なSAMLの認証アサーションを示します。
例1-1 SAML 1.0認証アサーションを含むサンプルSAMLPレスポンス
<samlp:Response
MajorVersion="1" MinorVersion="0"
ResponseID="128.14.234.20.90123456"
InResponseTo="123.45.678.90.12345678"
IssueInstant="2005-12-14T10:00:23Z"
xmlns:saml="urn:oasis:names:tc:SAML:1.0:assertion"
xmlns:samlp="urn:oasis:names:tc:SAML:1.0:protocol">
<samlp:Status>
<samlp:StatusCode Value="samlp:Success" />
</samlp:Status>
<saml:Assertion
MajorVersion="1" MinorVersion="0"
AssertionID="123.45.678.90.12345678"
Issuer="IssuingAuthority.com"
IssueInstant="2005-12-14T10:00:23Z" >
<saml:Conditions
NotBefore="2005-12-14T10:00:30Z"
NotAfter="2005-12-14T10:15:00Z" />
</saml:Conditions
<saml:AuthenticationStatement
AuthenticationMethod="urn:oasis:names:tc:SAML:1.0:am:password"
AuthenticationInstant="2005-12-14T10:00:20Z">
<saml:Subject>
<saml:NameIdentifier NameQualifier="RelyingParty.com">
john.smith
</saml:NameIdentifier>
<saml:SubjectConfirmation>
<saml:ConfirmationMethod>
urn:oasis:names:tc:SAML:1.0:cm:artifact-01
</saml:ConfirmationMethod>
</saml:SubjectConfirmation>
</saml:Subject>
</saml:AuthenticationStatement>
</saml:Assertion>
</samlp:Response>
アサーションを発行する機関は、発行局またはアイデンティティ・プロバイダと呼ばれます。発行局は、サード・パーティのサービス・プロバイダまたは、民間の企業連合内で発行局の役割を果す企業です。発行局やアイデンティティ・プロバイダを信頼してサービスを利用するSAML準拠のアプリケーションおよびサービスは、利用者またはサービス・プロバイダと呼ばれます。
典型的なSAMLサイクルでは、特定のクライアント・リクエストの認証を必要とする利用者(サービス・プロバイダ)が、SAMLリクエストを発行局またはアイデンティティ・プロバイダに送信します。アイデンティティ・プロバイダは、リクエストされたセキュリティ情報を利用者(サービス・プロバイダ)に提供する、SAMLアサーションで応答します。
たとえば、あるユーザーが利用者またはアイデンティティ・プロバイダのSAML準拠サービスにサインオンすると、そのサービスによって認証アサーションのリクエストが発行局(アイデンティティ・プロバイダ)に送信されます。発行認証局は、そのユーザーが特定の方法で特定の時刻に認証されていることを記述した「認証アサーション」参照を返します。次に、サービスは、ユーザーの資格証明の検証用に、このアサーションの参照先を他の利用者またはアイデンティティ・プロバイダのサイトに渡すことができます。認証を必要とする別のSAML準拠サイトにユーザーがアクセスすると、そのサイトは参照先を使用して発行局やアイデンティティ・プロバイダに認証アサーションをリクエストし、これにより、ユーザーがすでに認証されていることが通知されます。
発行局では、アサーション・レイヤーが、通信や転送の様々なプロトコル(HTTP、SOAPなど)にバインドできるSAMLプロトコルを使用して、リクエストおよびレスポンス・メッセージを処理します。クライアントは常にアサーションを消費しますが、発行局やアイデンティティ・プロバイダは、アサーションの作成と検証の両方を行うため、プロデューサおよびコンシューマとして機能できることに注意してください。
このサイクルを図1-1に示します。
この図は、SAMLのリクエストとレスポンスのサイクルを表し、ユーザー、利用者の枠および発行局の枠を示します。ユーザーまたはクライアントのリクエストはまず利用者に送られ、利用者がSAMLリクエストを発行局に送ります。発行認証局はSAMLアサーションで回答し、リクエストされたセキュリティ情報をリライング・パーティに提供します。利用者(複数の利用者が可能)とのクライアントの通信が双方向矢印で示され、利用者と発行局の間のリクエストとレスポンスの通信も双方向矢印で示されます。
発行局を示す枠では、アサーション・レイヤー(SAML)とトランスポート・レイヤー(HTTP、SOAPなど)が分かれており、これらのレイヤー間の通信により発行局がアサーションを作成および検証できることを示します。
SAMLでは、アサーションのリクエストおよび取得のためのプロトコル(SAMLP)が定義されます。バインディングにより、SAMLメッセージと標準通信プロトコルのマッピングが提供され、SAMLのリクエスト・メッセージとレスポンス・メッセージが発行局(アイデンティティ・プロバイダ)と利用者(アイデンティティ・プロバイダ)の間で転送される標準的な方法が定義されます。たとえば、SAMLのリクエストおよびレスポンスのために定義された転送メカニズムとしては、HTTP上のSimple Object Access Protocol(SOAP)があります。これにより、複数のWebサービス間で標準的な方法でSAML情報を交換できるようになります。
プロファイルでは、特定の転送バインディングでSAMLアサーションとプロトコル・メッセージを組み合せて、特定のユースケースを達成する方法が指定されます。最も広く実装されているSAMLプロファイルの例としては、シングル・サインオンのためのWebブラウザのプロファイルや、SOAPペイロードを保護するSOAPプロファイルがあります。
国際的な企業は、供給業者や顧客にいっそう緊密な関係を求めるようになり、これまで以上に密接でしかも安全性の高い取引関係を形成するという課題に直面しています。
商取引を行う関係者は、取引先の個人または代理店のアイデンティティを確認する必要があります。また、取引をする企業のために行動する権限をその個人または代理店が持っていることも確認する必要があります。
従来、企業が提携して業務を行う場合は、提携企業のために行動するすべてのエンティティの名前、職責、その他の関連情報を収集していました。特に大企業においては役割や職責は変化するため、データの維持や管理のコストが急速にきわめて高くなり、ロジスティック上の問題を引き起こすことがあります。
複雑性の解消のみでなく、コストの管理、従業員と顧客のためにリソースへの安全なアクセスを実現すること、法規制の順守なども課題です。
このような要件が、フェデレーテッド・アイデンティティ管理への動きを促進しています。フェデレーテッド・アイデンティティ管理では、関係者の間に信頼関係が確立され、相手方が発行したセキュリティ・トークンを認識して利用できます。
フェデレーションの重要な概念は次のとおりです。
サービス・プロバイダ - プリンシパルまたはその他のエンティティにサービスを提供するエンティティ。たとえば、旅行代理店は、パートナの従業員(プリンシパル)に対してはサービス・プロバイダとして機能できます。
シングル・サインオン - あるシステム・エンティティ(アイデンティティ・プロバイダ)で認証し、他のエンティティ(サービス・プロバイダ)がその認証を認めるようにする、プリンシパルの機能。
Liberty Allianceは、フェデレーテッド・アイデンティティ管理のテクノロジとビジネスの規格を確立して、相互運用可能なアイデンティティ・サービスを促進するためのオープンな組織です。
詳細は、ホワイト・ペーパー『Federated Identity Management』を参照してください。Oracle Identity Federationのページ(http://www.oracle.com/technology/products/id_mgmt/osfs/index.html)で入手できます。
この項では、Oracleセキュリティ開発ツールを紹介します。これは、様々なセキュリティ・タスクやプロジェクトを実装するためのPure Javaツールです。
ツールキット内の各ツールを全体として考え、アプリケーションごとにツールの機能のサブセットを確認すると便利です。
アーキテクチャ全体
図1-2は、Oracleセキュリティ開発ツールのコンポーネントを示しています。通常、各ツールは、スタック内のすぐ下のツールで提供される機能を利用します。たとえば、Oracle SAMLツールは、Oracle XMLセキュリティ・ツールで提供される機能を利用します。
注意:
概念上、ツールは、下部のレイヤーに基本ビルディング・ブロックがあるレイヤーに配置されており、各追加レイヤーは、直下のレイヤーを利用してその上に構築され、特定のセキュリティ・アプリケーションのためのツールを提供していると考えられます。
この図は、階層やシーケンス図ではありません。コンポーネント間の関係、および、スタックの上昇に伴う、下位レベルのツールから特化されたアプリケーション固有のコンポーネントへの進行を表しています。
Oracle CryptoおよびOracle Security Engineは、このセットの基本的な暗号化ツールです。次のレイヤーには、Oracle CMS(メッセージ構文)、Oracle XML Security(署名の暗号化)、Oracle PKI SDK (Oracle PKI LDAP SDK、Oracle PKI TSP SDK、Oracle PKI OCSP SDKおよびOracle PKI CMP SDKで構成されるPKIツール・スイート)があります。Oracle S/MIMEは、Oracle CMSを利用して安全な電子メールのためのツールセットを提供します。次のレイヤーには、Oracle SAMLおよびOracle Liberty SDKがあり、構造化アサーション・マークアップとフェデレーテッド・アイデンティティ管理の機能が提供されます。最後に、Oracle Web Services Securityがあり、Webサービス・セキュリティが提供されます。
各ツールの説明は、次の項を参照してください。
XML、SAMLおよびWeb Services Securityアプリケーションのツール
Oracle XML Securityパッケージでは、XML文書のセキュリティに加えて、ツールキットの次のコンポーネントの基盤も提供されます。
Oracle Web Services Security
SAML 1.0および2.0準拠のJavaセキュリティ・サービスを開発するためのOracle SAML
シングル・サインオン(SSO)およびLiberty Alliance仕様に基づいたフェデレーテッド・アイデンティティ・アプリケーションのためのOracle Liberty SDK
この図は、Oracle SAML、Oracle Web Services SecurityおよびOracle LibertyのツールがOracle XML Security上に構築されている様子を示しています。
|
注意: この図は、わかりやすくする都合上、やむを得ず簡素化していますが、実際は、Oracleセキュリティ開発ツール間のjarの関係は複雑であり、実装の詳細に依存しています。たとえば、SAMLライブラリを使用する場合、実際は次のような複数のコンポーネントが必要になります。
依存関係の完全な図の詳細は、図1-2「Oracleセキュリティ開発ツール」を参照してください。各アプリケーションのタイプに適した環境を確認できるように、各ツールのクラスパスの設定に関する手順は、このガイドで後述するツールに関する章を参照してください。 |
公開鍵暗号化(PKI)アプリケーションのツール
Oracle PKIパッケージは、LDAPリポジトリ内のデジタル証明書を処理するためのツール、RFC 3161に準拠するタイプスタンプ・サービスを開発するためのツール、RFC 2560に準拠したOCSPメッセージングのためのツール、およびCertificate Management Protocol(CMP)仕様のためのツールで構成されています。Oracle PKIパッケージでは、デジタル署名処理のためのXMLトランザクションの開発を可能にするOracle XKMSの基盤も提供されます。
この図は、Oracle LDAP、Oracle TSP、Oracle OCSPおよびOracle CMPで構成されるOracle PKIツール上に、Oracle XKMSツールが構築されている様子を示しています。
電子メール・セキュリティ・アプリケーションのツール
Oracle CMSでは、CMSオブジェクトの読取りと書込みのためのツールが提供されるだけでなく、証明書の解析と検証、X.509証明書、秘密鍵の暗号化、および関連する機能を含む、電子メール・セキュリティのためのOracle S/MIMEツールの基盤も提供されます。
この図は、Oracle S/MIMEツールがOracle CMS上に構築されている様子を示しています。
低レベルの暗号化アプリケーションのツール
Oracle Cryptoでは、様々な暗号化アルゴリズム、メッセージ・ダイジェストおよびMACアルゴリズムだけでなく、X.509証明書とCRL拡張機能のためのOracle Security Engineの基礎も提供されます。
この図は、Oracle Security EngineがOracle Cryptoツール上に構築されている様子を示しています。
Oracleセキュリティ開発ツールでは、表1-2に示す規格およびプロトコルをサポートしています。
表1-2 サポートされる規格
| 機能/コンポーネント | 規格 |
|---|---|
|
SAML |
|
|
XMLセキュリティ変換 |
次の変換がサポートされています。
|
|
WS-Security |
WS-Security 1.1の内容は、次のとおりです。
|
|
注意: 説明として、SAML Token Profile 1.0はSAML 1.0およびSAML 1.1に適用され、SAML Token Profile 1.1はSAML 2.0に適用されます。 |
Oracle CMSでは、CMSオブジェクトの読取りと書込みのツールや、安全なメッセージ・エンベロープを開発するためのサポート・ツールなど、豊富なツールが提供されます。
Oracle CMSでは、RFC 2630に規定されているIETF暗号メッセージ構文が実装されます。Oracle CMSでは、RFC 2630のコンテンツ・タイプがすべて実装されます。
Oracle S/MIMEでは、次のSecure/Multipurpose Internet Mail Extension(S/MIME)の機能が提供されます。
Oracle PKI SDKには、LDAPディレクトリへのアクセス、デジタル・メッセージの日付スタンプ、証明書の検証および証明書の管理など、デジタル証明書を扱うための一連のツールが含まれます。次のツールキットがあります。
Oracle PKI LDAP SDKでは、LDAPディレクトリ内のデジタル証明書にアクセスする機能が提供されます。Oracle PKI LDAP SDKを使用して実行できるタスクの一部を次に示します。
LDAPディレクトリにあるユーザーの証明書の検証
LDAPディレクトリへの証明書の追加
LDAPディレクトリからの証明書の取出し
LDAPディレクトリからの証明書の削除
Oracle PKI TSP SDKの特徴と機能は次のとおりです。
Oracle PKI TSP SDKはRFC 3161に準拠し、このタイムスタンプ・プロトコル(TSP)仕様に準拠する他の製品と互換性があります。
Oracle PKI TSP SDKでは、TSAサーバーのサンプル実装が提供されます。これは、TSPリクエスト・メッセージをテストするため、または独自のタイムスタンプ・サービスを開発する基礎として使用できます。
Oracle PKI OCSP SDKの特徴と機能は次のとおりです。
Oracle PKI OCSP SDKは、RFC 2560に準拠し、この仕様に準拠する他の製品(Valicert社のValidation Authorityなど)と互換性があります。
Oracle PKI OCSP SDK APIでは、OCSPリクエスト・メッセージを構成するためのクラスとメソッドが提供されます。このメッセージは、HTTPを介してRFC 2560に準拠する任意の検証局に送信できます。
Oracle PKI OCSP SDKのAPIでは、OCSPリクエスト・メッセージのレスポンスを構成するためのクラスとメソッドが提供されます。また、発行した証明書の有効性をチェックするための独自のOCSPサーバーを開発する基礎として使用可能なOCSPサーバー実装が提供されます。
Certificate Management Protocol(CMP)メッセージでサポートされる一連の機能を次に示します。
エンティティの登録(証明書の発行よりも先に行われる)
初期化(鍵ペアの生成など)
認証(証明書の発行)
鍵ペアのリカバリ(なくした鍵の再発行)
鍵ペアの更新(証明書が失効し、新しい鍵ペアと証明書を発行する必要が生じた場合)
CAへの失効リクエスト(CRLへの証明書の組込み)
2つのCAでのクロス認証
Oracle PKI CMP SDKはRFC 2510に準拠し、Certificate Management Protocol(CMP)仕様に準拠する他の製品と互換性があります。また、RFC 2511にも準拠し、この証明書要求メッセージ・フォーマット(CRMF)仕様に準拠する他の製品と互換性があります。
XMLセキュリティとは、XML文書の共通データ・セキュリティ要件(機密保持、整合性、メッセージの認証、否認防止など)を意味します。
Oracle XML Securityは、次の機能を提供してこれらのニーズを満たします。
復号化変換規格案のサポート
XML正規化規格のサポート
排他的XML正規化規格のサポート
JAXP 1.1準拠の様々なXMLパーサーおよびXSLTエンジンとの互換性
Oracle SAMLのAPIでは、SAML準拠のJavaセキュリティ・サービスの開発を支援するツールやドキュメントが提供されます。Oracle SAMLを、アプレット、アプリケーション、EJB、サーブレット、JSPなどの既存のJavaソリューションに統合することができます。
Oracle SAMLでは次の機能が提供されます。
SAML 1.0/1.1および2.0仕様のサポート
SAMLベースのシングル・サインオン(SSO)、属性、メタデータ、拡張クライアント・プロキシ、およびフェデレーテッド・アイデンティティ・プロファイルのサポート
Oracle Web Services Securityでは、Organization for the Advancement of Structured Information Standards(OASIS仕様)に基づく認証と認可のフレームワークが提供されます。Oracle Web Services Securityでは次の機能が提供されます。
SOAPメッセージ・セキュリティ規格(SOAP 1.1、1.2)のサポート
ユーザー名トークン・プロファイル規格(UsernameToken Profile 1.1)のサポート
X.509証明書トークン・プロファイル規格のサポート
WSS SAMLトークン・プロファイル(バージョン1.0)のサポート
|
注意: WSS SAMLトークン・プロファイルのバージョンは、SAMLのバージョンとは異なります。 |
Java開発者は、Oracle Liberty SDKを使用することで、Liberty Alliance仕様に基づくシングル・サインオン(SSO)およびフェデレーテッド・アイデンティティ・ソリューションを設計および開発することができます。Oracle Liberty SDKリリース1.1および1.2は、Liberty Alliance 1.1および1.2の仕様に準拠するシステムの開発と統合のあらゆる面の統一、単純化および拡張を目的としています。
Oracle Liberty SDKでは次の機能が提供されます。
Liberty Allianceプロジェクト・バージョン1.1および1.2仕様のサポート
Libertyベースのシングル・サインオンとフェデレーテッド・アイデンティティのサポート
Oracle XKMS(XML Key Management Specification)を使用すると、開発者はデジタル署名の処理に関するXMLトランザクションを記述できるため、公開鍵のインフラストラクチャを簡単に処理できるようになります。Oracle XKMSにはW3C XKMS規格が実装されており、公開鍵インフラストラクチャに関連するコストや複雑性をある程度軽減することができます。
Oracle JWT (JSON Web Token)は、JSON Web Token規格のサポートを提供します。Oracle JWTを使用すると、コンパクトなトークン・フォーマットを使用する二者の間で転送されるクレームを表すJSONオブジェクトを構成および管理できます。
この章で説明した規格をサポートするドキュメントおよび仕様の詳細は、付録A「リファレンス」を参照してください。
Oracle Security Developer Toolsリリース10gの使用方法を示すサンプル・コードは、My Oracle Supportナレッジ・ベースのドキュメントID 1333968.1を参照してください。(注意: この記事は、参照用にのみ提供され、リリース10gのみに適用可能です。)
