1 Oracle Security Developer Toolsの概要
セキュリティ・ツールは、アプリケーション開発プロジェクトにとって重要な構成要素です。市場のニーズや政府の規制により、重要なデータを機密保護し、改ざんや変更を防ぐことが求められます。
次のような、様々なOracle製品がOracle Security Developer Toolsを利用します。
-
Oracle JDeveloper統合サービス環境
-
システム・コンポーネントのSSL構成機能を含むOracle Platform Security Services、およびOracle Databaseなどの複数のコンポーネントで利用されるOracle Wallet
-
Oracle Web Services Manager (OWSM)、Business Integration (B2B)、Oracle SOA Suiteなどのシステム・コンポーネント
この章では、この基礎を形成するセキュリティ・テクノロジについて詳しく説明し、Oracle Security Developer Toolsのコンポーネントを紹介します。内容は次のとおりです。
1.1 暗号化について
暗号化により、通信チャネルで送信されるメッセージを侵入者による傍受(受動的攻撃)または変更(能動的攻撃)から守ります。メッセージを保護するには、発信者が暗号化ツールを使用して、読取り可能なプレーン・メッセージ、すなわち平文を暗号化された暗号文に変換します。メッセージの受信者も暗号化ツールを使用し、暗号文を元の読取り可能な形式に復号化します。
暗号化では、次の機能が提供され、インターネットなどネットワークを介した通信が保護されます。
-
認証: 情報の受信者に、その情報が信頼できるソースからのものであることを保証します。通常、認証は、メッセージ認証コード(MAC)、デジタル署名およびデジタル証明書を使用して達成されます。
-
機密保護: 意図した受信者のみがメッセージを読み取ることを保証します。通常、機密保護は暗号化によって実現されます。
-
整合性: 受信したメッセージが元のメッセージから変更されていないことを保証します。通常、整合性は暗号化ハッシュ関数を使用して保証されます。
-
否認防止: 所定の送信者が特定のメッセージを実際に送信したことを証明する方法です。通常、否拒否はデジタル署名を使用して実行されます。
暗号化に関するその他の暗号化リソースについては、リファレンスを参照してください。
1.1.1 暗号化アルゴリズムのタイプ
暗号化アルゴリズム(または暗号)では、キーを使用して平文と暗号文を相互に変換します。基本的には3つのタイプの暗号化アルゴリズムがあり、暗号化と復号化に使用されるキーの数と、適用方法や使用方法によって分類されます。これらは、対称暗号化アルゴリズム、非対称暗号化アルゴリズムおよびハッシュ関数です。
各タイプは特定の用途に最適化されています。ハッシュ関数はデータの整合性の保証に適しています。対称暗号化はメッセージの暗号化に最適です。非対称暗号化は、キーの安全な交換、認証および否認防止に使用されます。また、非対称暗号化はメッセージの暗号化にも使用できますが、頻繁ではありません。対称暗号化は非対称暗号化の約1000倍の速度で処理されるため、非対称暗号化よりも暗号化に適しています。
暗号化アルゴリズム・タイプを次に示します。
1.1.1.1 対称暗号化アルゴリズムについて
対称暗号化アルゴリズム(または秘密キー暗号化)は、暗号化と復号化の両方で1つのキーを使用します。送信者がキーを使用して平文を暗号化し、暗号文を受信者に送信します。受信者は同じキーを使用してメッセージを復号化し、平文に戻します。送信者と受信者の両方がキーを知っている必要があります。対称暗号化の最大の問題は、キーを安全に配布することです。
一般的に、対称暗号化スキームはブロック暗号とストリーム暗号に分類されます。ブロック暗号では、固定サイズのデータ・ブロック(通常は64ビット)が一度に1つずつ暗号化され、各ブロックには同じキーが使用されます。現在使用されている一般的なブロック暗号には、Blowfish、AES、DESおよび3DESがあります。
ストリーム暗号は、一度に1ビットで処理され、特定の形式のフィードバック・メカニズムの実装によって、キーが絶えず変更されます。RC4は、SSLプロトコルを使用した安全な通信のために使用されるストリーム暗号の一例です。
1.1.1.2 非対称暗号化アルゴリズムについて
非対称暗号化アルゴリズム(または公開キー暗号化)では、平文の暗号化と暗号文の復号化にそれぞれ別のキーが使用されます。どちらのキーを先に適用してもかまいませんが、暗号が機能するためには両方のキーが必要です。
非対称暗号化では、1つのキーが公開キーとして指定され、広く使用されます。もう1つのキーは秘密キーに指定され、第三者には公開しません。このスキームでメッセージを送信する場合、送信者は受信者の公開キーを使用して情報を暗号化します。受信者は自身の秘密キーを使用して暗号文を復号化します。この方法は、メッセージの送信者を証明する場合にも使用できます(否認防止)。送信者は自身の秘密キーを使用して平文を暗号化でき、受信者は、送信者の公開キーを使用してメッセージを復号化するため、メッセージがその送信者から実際に送信されたことがわかります。
現在使用されている一般的な非対称アルゴリズムには、RSA、DSAおよびDiffie-Hellmanがあります。
1.1.1.3 ハッシュ関数の理解
ハッシュ関数(またはメッセージ・ダイジェスト)は、本質的にキーを使用しない一方向暗号化アルゴリズムです。かわりに、平文に基づいて固定長のハッシュ値を計算しますが、この値から、平文の内容または長さを復元することはできません。通常、ハッシュ・アルゴリズムは、ファイルの内容のデジタル・フィンガープリントを提供するために使用され、ファイルが侵入者やウイルスによって変更されていないことを確認するためによく使用されます。また、ハッシュ関数は、一般に多くのオペレーティング・システムでパスワードの暗号化に利用されています。ハッシュ関数は、ファイルの整合性の保持にも有用です。一般的なハッシュ関数には、MD2、MD4、MD5、SHAなどがあります。
1.2 公開キー・インフラストラクチャ(PKI)について
公開キー・インフラストラクチャ(PKI)は、パブリック・ネットワークおよびプライベート・ネットワークでの安全な通信を実現するために設計されています。データの安全な送信と格納のみでなく、PKIによって、電子メールの安全性、デジタル署名およびデータの整合性も実現されます。PKIでは公開キー暗号化が使用されます。これは、関連する1組の暗号キーを使用して、送信者のアイデンティティ確認(デジタル署名)や、メッセージのプライバシ確保(暗号化)を行う数学的な技術です。PKIの機能によって、インターネットでの情報交換が保護されます。
PKIの目的を達成するためには、次の要素が必要です。
-
通信を保護する暗号化アルゴリズムとキー
-
公開キーを所有者のIDに関連付けるデジタル証明書
-
暗号化を広く安全に使用できるようにするキーの配布方法
-
キーとその正当な所有者の関係を保証する、認証局(CA)と呼ばれる信頼できるエンティティ
-
CAに対する証明書リクエストの情報を確認する登録局(RA)
利用者は、CAが発行した証明書とそれに含まれる公開キーを使用して、デジタル証明書を確認し、データを暗号化します。
1.2.1 キー・ペアの理解
暗号化技術では、送信者と受信者のみが知っているキーがよく使用されます。公開キー暗号化では、数学的に関連する暗号キー(公開キーと秘密キー)のキー・ペアが使用されます。
両者が同じキーを使用する暗号化スキームは対称と呼ばれます。対称システムを利用する際の難点として、キーを傍受されずに両者に渡すことや、1組の受信者と送信者ごとに個別のキーが必要になるため、各ユーザーが多数のキー(受信者ごとに1つずつ)を管理する必要があることがあげられます。
キー・ペアの使用方法は、「非対称暗号化アルゴリズムについて」を参照してください。
表1-1に、公開キーと秘密キーの利用者と目的をまとめています。
表1-1 公開キーと秘密キーの使用方法のサマリー
| 機能 | キーのタイプ | キーの所有者 |
|---|---|---|
|
受信者のためにデータを暗号化 |
公開キー |
受信者 |
|
データの署名 |
秘密キー |
送信者 |
|
受信データの復号化 |
秘密キー |
受信者 |
|
署名の検証 |
公開キー |
送信者 |
1.2.3 デジタル証明書とは
認証局は、デジタル証明書を作成して、公開キーと特定のエンティティとの関係を検証します。このデジタル証明書には、公開キー、キー所有者および署名する認証局の情報が含まれます。
エンティティのアイデンティティを証明するためにPKI証明書を使用することは、運転免許証やパスポートで身分を証明することと似ています。
1.2.4 関連するPKIの規格
多数の規格やプロトコルで、PKI証明書の実装がサポートされています。これらは、暗号メッセージ構文(CMS)、Secure/Multipurpose Internet Mail Extension (S/MIME)、Lightweight Directory Access Protocol (LDAP)、タイムスタンプ・プロトコル(TSP)、オンライン証明書ステータス・プロトコル(OCSP)およびCertificate Management Protocol (CMP)です。
暗号メッセージ構文
暗号メッセージ構文(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 (OCSP)は、デジタル証明書の有効性確認において、広く使用されている2つの方式のうちの1つ。もう1つの方式は証明書失効リスト(CRL)と呼ばれ、OCSPよりも古く、使用シナリオによってはOCSPに置き換えられています。
OCSPでは、クライアント側でリストを最新に保つために、更新分を頻繁にダウンロードする必要があるというCRLの大きな制限が解消されています。ユーザーがサーバーにアクセスしようとすると、OCSPは証明書ステータス情報のリクエストを送信します。サーバーは、レスポンス(有効、失効または不明)を返信します。このプロトコルによって、サーバー(証明書ステータスを格納する)とクライアント・アプリケーション(ステータスが通知される)の間の通信の構文が指定されます。
Certificate Management Protocol
Certificate Management Protocol (CMP)を使用すると、証明書の作成および管理に関連する処理のすべてを実行できます。CMPでは、公開キー・インフラストラクチャ(PKI)の構成要素(認証局(CA)、登録局(RA)、証明書発行先のエンド・エンティティなど)間の相互作用がサポートされます。
1.2.5 PKIの利点
PKIは、安全で信頼できる認証を提供します。データ整合性と否認防止を実現し、送信または格納されている情報への未許可アクセスを防止します。
PKIを使用した場合のユーザーの利点は次のとおりです。
-
安全で信頼できるユーザーの認証
信頼できる認証は次の2つの要因に基づきます。1つは、公開キーと秘密キーのペアの秘密キー部分の所有を証明することで、これは、公開キーを使用する自動手順で確認されます。もう1つは、特定のアイデンティティへの公開キーの所属が認証局によって検証されることです。PKIに基づくデジタル証明書では、キー・ペアに基づいてこのアイデンティティの接続が検証されます。
-
データ整合性
公開キーと秘密キーのペアの秘密キーを使用してデジタル・トランザクションに署名すると、送信中にデータを変更することが困難になります。このようなデジタル署名は、送信者の秘密キーで暗号化された元のメッセージのダイジェストがコード化されたものです。受信者は、送信者の対応する公開キーを使用して、メッセージの送信者、およびメッセージが変更されていないことを確認できます。メッセージまたはダイジェストの変更があると、公開キーを使用した検証が失敗するため、メッセージを信頼できないことが受信者に伝わります。
-
否認防止
PKIは、メッセージの送信者を証明する場合にも使用できます。送信者は自身の秘密キーを使用して平文を暗号化してデジタル署名を作成し、受信者は、送信者の公開キーを使用してメッセージを復号化するため、メッセージがその送信者から実際に送信されたことがわかり、メッセージの発信者がメッセージを否認することは困難になります。この機能は否認防止と呼ばれます。
-
送信または格納されている情報への未許可アクセスの防止
公開キーから秘密キーを導出するためにはかなりの時間と労力が必要になるため、キー・ペアの所有者以外がメッセージを復号化することは考えられません。
1.3 Webサービスのセキュリティについて
Webサービスでは、組織がXML、SOAP、WSDLなどの標準のオープン・テクノロジを使用してWebベース・アプリケーションを統合するための標準的な方法を提供しています。コア仕様のSOAPによってXMLやWebサービスに関連する多くの問題が解決されますが、機密保護、整合性、メッセージ認証、否認防止など、メッセージ・セキュリティ要件に対処する手段は提供されません。
SOAPは、サービス指向環境で情報を交換するための軽量プロトコルです。このような環境では、アプリケーションは、他のアプリケーションで使用するように選択した機能(ビジネス・ロジックなど)を公開できます。SOAPは、アプリケーションがこれらのサービスを提供および消費するための手段を提供します。これは分散非集中管理Webサービス・アプリケーション環境でのメッセージ転送のためのXMLベースのプロトコルです。
SOAPを保護するニーズが高まったため、OASISは次のようなWebサービス・セキュリティの規格を提唱しています。
-
SOAPメッセージの署名と暗号化を可能にする拡張機能の指定。
-
セキュリティ・トークンとメッセージを関連付ける汎用メソッドの指定。
-
メッセージに組み込まれるトークンの特徴を指定するための、その他の手段の提供。
1.4 SAMLについて
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の各フェデレーション・プロトコルが統合されています。
1.4.1 SAMLアサーションの理解
SAMLは、電子メール・アドレスやディレクトリのリストなどのIDをユーザーやシステムなどのサブジェクトに関連付けて、特定のドメインでのアクセス権を定義します。基本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>
1.4.2 SAMLリクエストおよびレスポンスの理解
あるユーザーがSAML準拠サービスにサインオンすると、そのサービスによって認証アサーションのリクエストが発行局(アイデンティティ・プロバイダ)に送信されます。発行認証局は、そのユーザーが特定の方法で特定の時刻に認証されていることを記述した「認証アサーション」参照を返します。
アサーションを発行する機関は、発行局またはIDプロバイダと呼ばれます。発行局は、サード・パーティのサービス・プロバイダまたは、民間の企業連合内で発行局の役割を果す企業です。発行局やIDプロバイダを信頼してサービスを利用するSAML準拠のアプリケーションおよびサービスは、利用者またはサービス・プロバイダと呼ばれます。
1.4.2.1 SAMLのリクエストおよびレスポンスのサイクルについて
典型的なSAMLサイクルでは、特定のクライアント・リクエストの認証を必要とする利用者(サービス・プロバイダ)が、SAMLリクエストを発行局またはIDプロバイダに送信します。アイデンティティ・プロバイダは、リクエストされたセキュリティ情報を利用者(サービス・プロバイダ)に提供する、SAMLアサーションで応答します。
たとえば、あるユーザーが利用者またはアイデンティティ・プロバイダのSAML準拠サービスにサインオンすると、そのサービスによって認証アサーションのリクエストが発行局(アイデンティティ・プロバイダ)に送信されます。発行認証局は、そのユーザーが特定の方法で特定の時刻に認証されていることを記述した「認証アサーション」参照を返します。次に、サービスは、ユーザーの資格証明の検証用に、このアサーションの参照先を他の利用者またはアイデンティティ・プロバイダのサイトに渡すことができます。認証を必要とする別のSAML準拠サイトにユーザーがアクセスすると、そのサイトは参照先を使用して発行局やアイデンティティ・プロバイダに認証アサーションをリクエストし、これにより、ユーザーがすでに認証されていることが通知されます。
発行局では、アサーション・レイヤーが、通信や転送の様々なプロトコル(HTTP、SOAPなど)にバインドできるSAMLプロトコルを使用して、リクエストおよびレスポンス・メッセージを処理します。クライアントは常にアサーションを消費しますが、発行局やアイデンティティ・プロバイダは、アサーションの作成と検証の両方を行うため、プロデューサおよびコンシューマとして機能できることに注意してください。
このサイクルを図1-1に示します。
図1-1 SAMLのリクエストとレスポンスのサイクル
この図は、SAMLのリクエストとレスポンスのサイクルを表し、ユーザー、利用者の枠および発行局の枠を示します。ユーザーまたはクライアントのリクエストはまず利用者に送られ、利用者がSAMLリクエストを発行局に送ります。発行認証局はSAMLアサーションで回答し、リクエストされたセキュリティ情報をリライング・パーティに提供します。利用者(複数の利用者が可能)とのクライアントの通信が双方向矢印で示され、利用者と発行局の間のリクエストとレスポンスの通信も双方向矢印で示されます。
発行局を示す枠では、アサーション・レイヤー(SAML)とトランスポート・レイヤー(HTTP、SOAPなど)が分かれており、これらのレイヤー間の通信により発行局がアサーションを作成および検証できることを示します。
1.4.2.2 SAMLのプロトコル・バインディングとプロファイルについて
SAMLでは、アサーションのリクエストおよび取得のためのプロトコル(SAMLP)が定義されます。バインディングにより、SAMLメッセージと標準通信プロトコルのマッピングが提供され、SAMLのリクエスト・メッセージとレスポンス・メッセージが発行局(アイデンティティ・プロバイダ)と利用者(アイデンティティ・プロバイダ)の間で転送される標準的な方法が定義されます。たとえば、SAMLのリクエストおよびレスポンスのために定義された転送メカニズムとしては、HTTP上のSimple Object Access Protocol (SOAP)があります。これにより、複数のWebサービス間で標準的な方法でSAML情報を交換できるようになります。
プロファイルでは、特定の転送バインディングでSAMLアサーションとプロトコル・メッセージを組み合せて、特定のユースケースを達成する方法が指定されます。最も広く実装されているSAMLプロファイルの例としては、シングル・サインオンのためのWebブラウザのプロファイルや、SOAPペイロードを保護するSOAPプロファイルがあります。
1.4.2.3 SAMLとXMLセキュリティの統合方法
また、SAMLは、XML文書に暗号化したデータまたはデジタル署名を埋め込むためのWorld Wide Web Consortiumの規格であるXML署名およびXML暗号化と統合するように設計されています。XML署名をサポートすることで、SAMLは認証のみでなく、メッセージ整合性や送信者の否認防止も処理できるようになります。Oracle XML Securityの詳細は、Oracle XML Securityを参照してください。
1.5 Identity Federationについて
国際的な企業は、供給業者や顧客にいっそう緊密な関係を求めるようになり、これまで以上に密接でしかも安全性の高い商取引を形成するという課題に直面しています。商取引を行う関係者は、取引先の個人または代理店のアイデンティティを確認する必要があります。また、取引をする企業のために行動する権限をその個人または代理店が持っていることも確認する必要があります。フェデレーテッド・アイデンティティ管理では、関係者の間に信頼関係が確立され、相手方が発行したセキュリティ・トークンを認識して利用できます。Identity Federationにより、複雑性、コストの管理、従業員と顧客のためにリソースへの安全なアクセスを実現すること、法規制の順守などの課題が解消されます。
従来、企業が提携して業務を行う場合は、提携企業のために行動するすべてのエンティティの名前、職責、その他の関連情報を収集していました。特に大企業においては役割や職責は変化するため、データの維持や管理のコストが急速にきわめて高くなり、ロジスティック上の問題を引き起こすことがあります。
フェデレーションの重要な概念は次のとおりです。
-
プリンシパル - フェデレーテッド環境の重要なアクター。許可されたビジネス・タスクを実行するエンティティです。
-
IDプロバイダ - プリンシパルのIDを認証するサービス。
-
サービス・プロバイダ - プリンシパルまたはその他のエンティティにサービスを提供するエンティティ。たとえば、旅行代理店は、パートナの従業員(プリンシパル)に対してはサービス・プロバイダとして機能できます。
-
シングル・サインオン - あるシステム・エンティティ(IDプロバイダ)で認証し、他のエンティティ(サービス・プロバイダ)がその認証を認めるようにする、プリンシパルの機能。
注意:
ここで説明した規格の詳細は、「リファレンス」を参照してください。
1.6 Oracle Security Developer Toolsについて
Oracle Security Developer Toolsは、暗号化の規格とプロトコルを使用して多様なセキュリティ・タスクとプロジェクトの実装を可能にするJavaツールです。
この項には次のトピックが含まれます。
1.6.1 ツールキットのアーキテクチャの理解
Oracle Security Developer Toolsは、様々な設定レイヤーに配置されるXML、SAMLおよびWeb Services Securityアプリケーションのツール、公開キー暗号化(PKI)アプリケーションのツール、電子メール・セキュリティ・アプリケーションのツール、低レベルの暗号化アプリケーションのツール、およびWeb Tokenのためのツールで構成されます。
ツールキット内の各ツールを全体として考え、アプリケーションごとにツールの機能のサブセットを確認すると便利です。
図1-2 Oracle Security Developer Tools
図1-2は、Oracle Security Developer Toolsのコンポーネントを示しています。通常、各ツールは、スタック内のすぐ下のツールで提供される機能を利用します。たとえば、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サービスとの安全な対話を促進します。
1.6.2 XML、SAMLおよびWeb Services Securityアプリケーションのツール
Oracle XML Securityパッケージでは、XMLドキュメントのセキュリティが提供されます。Oracle Web Services Security、Oracle SAMLおよびOracle Liberty SDKの基盤が提供されます。
Oracle XML Securityパッケージでは、ツールキットの次のコンポーネントの基盤が提供されます。
-
Oracle Web Services Security
-
SAML 1.0および2.0準拠のJavaセキュリティ・サービスを開発するためのOracle SAML
-
シングル・サインオン(SSO)およびLiberty Alliance仕様に基づいたフェデレーテッド・アイデンティティ・アプリケーションのためのOracle Liberty SDK
図1-3 XML、SAMLおよびWS Securityのツール
この図は、Oracle SAML、Oracle Web Services SecurityおよびOracle LibertyのツールがOracle XML Security上に構築されている様子を示しています。
注意:
この図は、わかりやすくする都合上、やむを得ず簡素化していますが、実際は、Oracle Security Developer Tools間のjarの関係は複雑であり、実装の詳細に依存しています。たとえば、SAMLライブラリを使用する場合、実際は次のような複数のコンポーネントが必要になります。
-
SAMLでは署名が必要なため、Oracle XML Securityライブラリが必要です。
-
Oracle Security Engineでは、証明書とCRL管理機能が提供されます
依存関係の全体像については、図1-2を参照してください。各アプリケーションのタイプに適した環境を確認できるように、各ツールのクラスパスの設定に関する手順は、このガイドで後述するツールに関する章を参照してください。
1.6.2.1 Oracle XML Securityについて
XMLセキュリティとは、XML文書の共通データ・セキュリティ要件(機密保持、整合性、メッセージの認証、否認防止など)を意味します。
Oracle XML Securityは、次の機能を提供してこれらのニーズを満たします。
-
復号化変換規格案のサポート
-
XML正規化規格のサポート
-
排他的XML正規化規格のサポート
-
JAXP 1.1準拠の様々なXMLパーサーおよびXSLTエンジンとの互換性
1.6.2.2 Oracle SAMLについて
Oracle SAML APIは、SAML準拠のJavaセキュリティ・サービスの開発者を支援するツールとマニュアルを提供します。Oracle SAMLは、アプレット、アプリケーション、EJB、サーブレット、JSPなどの既存のJavaソリューションに統合できます。
Oracle SAMLでは次の機能が提供されます。
-
SAML 1.0/1.1および2.0仕様のサポート
-
SAMLベースのシングル・サインオン(SSO)、属性、メタデータ、拡張クライアント・プロキシ、およびフェデレーテッド・アイデンティティ・プロファイルのサポート
1.6.2.3 Oracle Web Services Securityについて
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のバージョンとは異なります。
1.6.2.4 Oracle Liberty SDKについて
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ベースのシングル・サインオンとフェデレーテッド・アイデンティティのサポート
注意:
この章で説明した規格と仕様の詳細は、「リファレンス」を参照してください。
1.6.3 公開キー暗号化(PKI)アプリケーションのツール
Oracle PKIパッケージは、LDAPリポジトリ内のデジタル証明書を処理するためのツール、RFC 3161に準拠するタイプスタンプ・サービスを開発するためのツール、RFC 2560に準拠したOCSPメッセージングのためのツール、およびCertificate Management Protocol (CMP)仕様のためのツールで構成されています。Oracle PKIパッケージでは、デジタル署名処理のためのXMLトランザクションの開発を可能にするOracle XKMSの基盤も提供されます。
図1-4 PKIツール
この図は、Oracle LDAP、Oracle TSP、Oracle OCSPおよびOracle CMPで構成されるOracle PKIツール上に、Oracle XKMSツールが構築されている様子を示しています。
1.6.3.1 Oracle PKI LDAP SDKについて
Oracle PKI LDAP SDKでは、LDAPディレクトリ内のデジタル証明書にアクセスする機能が提供されます。Oracle PKI LDAP SDKを使用して実行できるタスクの一部を次に示します。
-
LDAPディレクトリにあるユーザーの証明書の検証
-
LDAPディレクトリへの証明書の追加
-
LDAPディレクトリからの証明書の取出し
-
LDAPディレクトリからの証明書の削除
1.6.3.2 Oracle PKI TSP SDKについて
Oracle PKI TSP SDKの特徴と機能は次のとおりです。
-
Oracle PKI TSP SDKはRFC 3161に準拠し、このタイムスタンプ・プロトコル(TSP)仕様に準拠する他の製品と互換性があります。
-
Oracle PKI TSP SDKでは、TSAサーバーのサンプル実装が提供されます。これは、TSPリクエスト・メッセージをテストするため、または独自のタイムスタンプ・サービスを開発する基礎として使用できます。
1.6.3.3 Oracle PKI OCSP SDKについて
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サーバー実装が提供されます。
1.6.3.4 Oracle PKI CMP SDKについて
Certificate Management Protocol (CMP)メッセージでは、次の機能セットがサポートされます。
-
エンティティの登録(証明書の発行よりも先に行われる)
-
初期化(キー・ペアの生成など)
-
認証(証明書の発行)
-
キー・ペアのリカバリ(なくしたキーの再発行)
-
キー・ペアの更新(証明書が失効し、新しいキー・ペアと証明書を発行する必要が生じた場合)
-
CAへの失効リクエスト(CRLへの証明書の組込み)
-
2つのCAでのクロス認証
Oracle PKI CMP SDKはRFC 2510に準拠し、Certificate Management Protocol仕様に準拠する他の製品と互換性があります。また、RFC 2511にも準拠し、この証明書要求メッセージ・フォーマット(CRMF)仕様に準拠する他の製品と互換性があります。
1.6.4 電子メール・セキュリティ・アプリケーションのツール
Oracle CMSでは、CMSオブジェクトの読取りと書込みのためのツールが提供されるだけでなく、証明書の解析と検証、X.509証明書、秘密キーの暗号化、および関連する機能を含む、電子メール・セキュリティのためのOracle S/MIMEツールの基盤も提供されます。
図1-5 CMSおよびS/MIMEツール
この図は、Oracle S/MIMEツールがOracle CMS上に構築されている様子を示しています。
1.6.4.1 Oracle CMSについて
Oracle CMSでは、CMSオブジェクトの読取りと書込みのツールや、安全なメッセージ・エンベロープを開発するためのサポート・ツールなど、豊富なツールが提供されます。
Oracle CMSでは、RFC 2630に規定されているIETF暗号メッセージ構文が実装されます。Oracle CMSでは、RFC 2630のコンテンツ・タイプがすべて実装されます。
1.6.5 低レベルの暗号化アプリケーションのツール
Oracle Cryptoでは、様々な暗号化アルゴリズム、メッセージ・ダイジェストおよびMACアルゴリズムだけでなく、X.509証明書とCRL拡張機能のためのOracle Security Engineの基礎も提供されます。
図1-6 暗号化ツール
この図は、Oracle Security EngineがOracle Cryptoツール上に構築されている様子を示しています。
1.6.5.1 Oracle Cryptoについて
Oracle Cryptoのツールキットでは、次の機能が提供されます。
-
公開キー暗号化。RSAなど。
-
デジタル署名アルゴリズム。Digital Signature Algorithm (DSA)、RSAなど。
-
キー交換アルゴリズム。Diffie-Hellmanなど。
-
対称暗号化アルゴリズム。Blowfish、AES、DES、3DES、RC2、RC4など。
-
メッセージ・ダイジェスト・アルゴリズム。MD2、MD4、MD5、SHA-1、SHA-256、SHA-384、SHA-512など。
-
MACアルゴリズム。HMAC-MD5、HMAC-SHA-1など。
-
ASN.1オブジェクトの構築および解析のためのメソッド。
1.7 サポートされる規格について
Oracle Security Developer Toolsは、SAML、XMLセキュリティ変換およびWS-Securityの複数の標準をサポートします。
次の表に、サポートされている規格とプロトコルを示します。
表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に適用されます。
1.8 CLASSPATH環境変数の設定
OSDTツールキットの各ツールには固有のCLASSPATH要件があります。CLASSPATH環境変数を設定する必要があります。CLASSPATH環境変数には、必要なjarファイルおよびclassファイルすべてのフルパスとファイル名を指定してください。
特定のOSDTツールにどのjarが必要かを決定するには、そのツールについて説明する章の環境設定に関する項を参照してください。
1.8.1 WindowsでのCLASSPATHの設定
Windowsでは、Windowsのコントロール パネルを使用して、必要なすべてのjarファイルのフルパスとファイル名を含むようにCLASSPATH環境変数を設定します。
WindowsでCLASSPATHを設定する手順を次に示します。
1.8.2 UNIXでのCLASSPATHの設定
UNIXでは、必要なjarファイルおよびclassファイルすべてのフルパスとファイル名を含むようにCLASSPATH環境変数を設定します。
次に例を示します。
setenv CLASSPATH $CLASSPATH:$ORACLE_HOME/modules/oracle.osdt_11.1.1/osdt_core.jar: $ORACLE_HOME/modules/oracle.osdt_11.1.1/osdt_cert.jar: $ORACLE_HOME/modules/oracle.osdt_11.1.1/osdt_xmlsec.jar: $ORACLE_HOME/modules/oracle.osdt_11.1.1/osdt_saml.jar: $ORACLE_HOME/modules/oracle.osdt_11.1.1/osdt_saml2.jar: $ORACLE_HOME/modules/org.jaxen_1.1.1.jar