| Oracle Secure Backup管理者ガイド リリース10.1 B28439-01 |
|
 戻る |
 次へ |
この章では、Oracle Secure Backupのドメインにおけるセキュリティとその構成方法について詳しく説明します。この章の内容は次のとおりです。
使用している環境でセキュリティが主要な問題である場合、次の段階でセキュリティの実装を計画すると役立つことがあります。
これらの段階を完了すると、「管理ドメインのセキュリティの構成」で説明している実装フェーズに進むことができます。
管理ドメインのセキュリティの計画における最初の手順は、ドメインに関連付けられた資産およびプリンシパルを確認することです。
ドメインの資産には次のものがあります。
バックアップを必要とするデータベースおよびファイル・システム・データ
データベースおよびファイル・システム・データに関するメタデータ
パスワード
ID
ホストおよびストレージ・デバイス
プリンシパルとは、管理ドメインに関連付けられた資産またはドメインのスーパーセットを形成するネットワークのいずれかにアクセスできるユーザーです。プリンシパルには次のユーザーがいます。
バックアップ管理者
これらのOracle Secure Backupユーザーは、ドメイン内の管理権限、バックアップ・データが含まれるテープへのアクセス権、バックアップおよびリストア操作を実行するのに必要な権限を保持します。
データベース管理者
各データベース管理者は、所有するデータベースへのすべてのアクセス権を保持します。
ホスト所有者
各ホスト所有者は、そのホストのファイル・システムへのすべてのアクセス権を保持します。
システム管理者
これらのユーザーは、企業ネットワークおよび管理ドメイン内のホストへのアクセス権を保持できます（ただし、必ずしもルート・アクセスではありません）。
傍観者
これらのユーザーは、前述のプリンシパルのカテゴリには該当しませんが、Oracle Secure Backupのドメインのスーパーセットを形成するネットワークにアクセスできます。傍観者は、ドメインの外にホストを所有することがあります。
プリンシパルは、資産と様々な関係にあります。これらの関係により、Oracle Secure Backupの管理ドメインにおけるセキュリティ・レベルはある程度決まります。
ドメインのセキュリティ・レベルを示す1つの方法は、所有していない資産へのアクセス権をどのプリンシパルが保持するかという観点から見ることです。最高レベルのセキュリティでは、資産へのアクセス権を保持するプリンシパルのみが所有者です。たとえば、クライアント・ホストの所有者のみが、そのホストのデータの読取りまたは変更を行うことができます。中レベルのセキュリティでは、資産所有者とドメインの管理者の両方がその資産へのアクセス権を保持します。最低レベルのセキュリティでは、どのプリンシパルもドメイン内のあらゆる資産にアクセスできます。
管理ドメインに関連する資産およびプリンシパルを特定すると、ドメインを配置している環境のタイプを特徴付けることができます。環境のタイプにより、使用するセキュリティ・モデルはある程度決まります。
次の基準により、ネットワーク環境のタイプはある程度区別されます。
規模
ドメインに関連付けられたプリンシパルおよび資産の数は、ドメイン・セキュリティで重要な役割を果たします。1000ホストおよび2000ユーザーで構成されるネットワークには、5ホストおよび2ユーザーで構成されるネットワークより、攻撃者に対する入口が多く存在します。
データの機密性
データの機密性は、悪質なユーザーがデータにアクセスする危険度から割り出されます。たとえば、一般企業の従業員のホスト上にあるホーム・ディレクトリは、クレジット会社の加入者データよりも機密性は低いと考えられます。
通信媒体の分離
ネットワークのセキュリティは、ドメイン内のホストおよびデバイス間におけるネットワーク通信のアクセス可能性によって左右されます。非公開の企業データ・センターは、その意味では、企業ネットワーク全体よりも分離されています。
次の各項では、Oracle Secure Backupの管理ドメインの配置が典型的なネットワーク環境のタイプについて説明します。また、各環境の標準的なセキュリティ・モデルについても説明します。
管理サーバー、メディア・サーバーおよびクライアントで構成される最も基本的な管理ドメインです。図1-3「1つのホストを持つ管理ドメイン」に示すように、1つのホストが3つのロールすべてを担います。
このタイプの環境には、次の特徴があります。
規模
管理ドメイン内のホスト、デバイスおよびユーザーの数は小規模です。
データの機密性
この例でのデータは、機密性の範囲の最低であると考えられます。たとえば、ドメインは、企業ネットワーク内の個人Webサイトの管理に使用される2つのサーバーで構成されます。
通信媒体の分離
このタイプのネットワークは、より広域のネットワークから分離されています。
この管理ドメインは、中規模サイズで、データ・センターなどのセキュアな環境に配置されます。
このタイプの環境には、次の特徴があります。
規模
管理ドメイン内のホスト、デバイスおよびユーザーの数は、単一システムの例の場合より大規模ですが、全体としてはネットワークの小さな一部です。
データの機密性
この例でのデータは、機密性の範囲の最高であると考えられます。たとえば、極秘の従業員データの格納に使用されるホストのネットワークがあげられます。
通信媒体の分離
ネットワークのバックアップは、別個のセキュアな専用ネットワーク上で行われます。
資産は、専用ネットワーク内の物理的にセキュアなマシンです。管理ドメインには、数百のデータベースおよびファイル・システムのバックアップを処理する十余りのメディア・サーバーが含まれることがあります。
プリンシパルには次のユーザーがいます。
バックアップ管理者: Oracle Secure Backupの管理ユーザーとしてドメインにアクセスします。
システム管理者: マシン、デバイスおよびネットワークを管理します。
データベース管理者: 所有するデータベースにアクセスでき、データベース・マシンに物理的にアクセスできることもあります。
ホスト管理者: ファイル・システムにアクセスでき、マシンに物理的にアクセスできることもあります。
この環境では、1つ以上の管理ドメイン、複数のメディア・サーバーおよび多数のクライアント・ホストが企業ネットワーク内に存在します。
このタイプの環境には、次の特徴があります。
規模
管理ドメイン内のホスト、デバイスおよびユーザーの数は非常に大規模です。
データの機密性
バックアップされるデータには、人事情報などの非常に機密性の高いデータの他に、下級従業員のホーム・ディレクトリなどの機密性のより低いデータも含まれます。
通信媒体の分離
バックアップは通常、電子メール、インターネット・アクセスなどに使用されるのと同じ企業ネットワーク上で行われ、ファイアウォールによって広域インターネットから保護されます。
資産には、基本的に企業内のすべてのデータおよびすべてのコンピュータが含まれます。各管理ドメイン（複数存在する場合あり）には複数のユーザーが存在することがあります。一部のホスト所有者は、所有するOracle Secure Backupアカウントにホストのファイル・システムまたはデータベースのリストアを開始させることがあります。
このバックアップ環境のセキュリティ要件は、単一システムおよびデータ・センターの例とは異なります。製品の範囲および配置から判断すると、クライアント・ホストの安全性が損われる可能性は非常に高いです。たとえば、出張で使用されたラップトップを誰かが盗む可能性があります。悪意のある従業員がコンピュータに不正にログインしたり、tcpdumpや同様のユーティリティを実行してネットワーク・トラフィックをリスニングする可能性もあります。
クライアント・ホストの安全性が損われることで、管理ドメイン全体が不能になったり安全性が損われたりすることを招かないようにします。安全性が損われたマシンで、悪質なユーザーが、他のホスト上で他のユーザーがバックアップしたデータにアクセスできないようにする必要があります。また、このようなユーザーが、管理ドメイン内の他のホストの通常操作に影響を与えることができないようにする必要もあります。
セキュリティ管理およびパフォーマンスのオーバーヘッドが予測されます。機密性の高い資産の所有者は、バックアップ・メディアへの物理的なアクセスによってバックアップのコンテンツが漏洩しないように、バックアップを暗号化する必要があります。このようなユーザーは、機密データが暗号化されていない形式でホストから流出しないように、クライアント・ホスト自体で暗号化および復号化を実行する必要があります。
|
注意: RMANのバックアップ暗号化機能を使用すると、ディスクまたはテープ上のデータベースのバックアップを暗号化できます。Oracle Secure Backupでは、テープに格納されたファイル・システムのバックアップ・データは暗号化されません。 |
ドメインのセキュリティを構成する際の主要なタスクは、ホストに物理的なセキュリティおよびネットワーク・セキュリティを提供し、管理サーバーおよびメディア・サーバーとなるホストを決定することです。
管理サーバーおよびメディア・サーバーを選択する際、物理的なセキュリティとネットワーク・セキュリティの両方によって保護される場合のみ、ホストを管理サーバーまたはメディア・サーバーとなることに留意してください。たとえば、データ・センターのホストは、少数の信頼できる管理者がアクセスできる非公開の保護されたネットワークに属すると考えられるため、管理サーバーの候補になりえます。
Oracle Secure Backup自体は、物理的なセキュリティまたはネットワーク・セキュリティをホストに提供できません。また、このようなセキュリティが存在するかどうかを検証することもできません。たとえば、Oracle Secure Backupは、悪質なユーザーが次のような不正な行為をすることを阻止できません。
ホストを物理的な危険にさらすこと
ホストに物理的にアクセスできる攻撃者は、1次ストレージまたは2次ストレージを盗んだり破壊したりできます。たとえば、泥棒がオフィスに侵入し、サーバーやテープを盗む可能性があります。暗号化により、データへの一部の脅威は低減できますが、全部ではありません。管理サーバーに物理的にアクセスできる攻撃者により、管理ドメイン全体の安全性が損われることに注意してください。
ホストのオペレーティング・システムへのアクセス
クライアント・ホストの所有者がパスワードを入力するときに、傍観者がその指の動きを見てパスワードを盗んだとします。この悪質なユーザーは、そのホストにTelnetでアクセスし、1次ストレージのデータを削除、置換またはコピーできます。世界で最もセキュアなバックアップ・システムでも、攻撃者が元の場所にあるデータにアクセスできる場合は、データを保護できません。
ネットワーク上の潜入または盗聴
バックアップ・ソフトウェアは、ある場合に、保護されていないネットワークを介して安全に通信できますが、常にそうできるわけではありません。ネットワーク・セキュリティは、特にNDMPベースの通信の場合、バックアップ・システムの重要な部分です。
Oracle Secure BackupのIDの故意の誤用
Oracle Secure Backupの管理者権限を持つユーザーが悪質なユーザーになると、管理ドメインに大損害を与えることができます。たとえば、ドメイン内のすべてのホスト上のファイル・システムを上書きできます。バックアップ・ソフトウェアは、モラルのある行動をするようにユーザーに強制できません。
バックアップ環境を分析して保護方法を検討した後に、ドメイン内のホストでID証明書を取得する方法を決定できます。「ホストの認証と通信」で説明しているように、Oracle Secure BackupはSSLを使用してセキュアで信頼できる通信チャネルをドメイン・ホスト間に確立します。各ホストは、ドメイン内のそのホストを一意に識別する、認証局（CA）が署名したID証明書を保持します。ID証明書は認証されたSSL接続に必要です。
「認証局」で説明しているように、ドメインの管理サーバーは管理ドメインのCAです。管理サーバーの構成が終わると、メディア・サーバーおよびクライアントをドメイン内に作成できます。メディア・サーバーおよびクライアントは、次のモードのいずれかで作成できます。
この場合、手動の管理は不要です。ホストを構成する際、CAはID証明書を新しいホストにネットワークを介して発行します。
この場合、ホストごとにID証明書を手動でウォレットにインポートする必要があります。
自動モードは、より簡単に使用できますが、まれな中間者攻撃に対して脆弱です。中間者攻撃では、新しいホストにドメインへの参加を求める直前に、攻撃者がそのホストの名前を盗みます。この攻撃者は、盗んだホストIDを使用してドメインに不正に参加できます。手動モードは、自動モードより使用が難しいですが、同様の攻撃に対して脆弱ではありません。
手動モードでは、管理サーバーは証明書レスポンスを新しいホストに送信しません。かわりに、署名されたID証明書のコピーを物理媒体で新しいホストに運び、obcmユーティリティを使用して新しいホストのウォレットに証明書をインポートする必要があります。obcmユーティリティは、ウォレット内の証明書リクエストが署名されたID証明書と合致するかどうかを検証します。検証の失敗は、不正なホストが新しいホストのふりをしようとした可能性が高いことを示します。mkhostコマンドは、不正なホストがネットワークから排除された後に再発行できます。
証明書プロビジョニング・モードを手動か自動のどちらかに決定するとき、「手動証明書プロビジョニング・モードによって提供される特別な保護が、管理のオーバーヘッドに値するか」という問いを検討してください。単一システムおよびデータ・センターの環境には、分離されたネットワーク通信があるため、通常、自動モードがより適切な選択となります。企業ネットワークは、中間者攻撃に対してはるかに脆弱であるため、手動モードがより妥当な選択となります。それでも、ほとんどの場合、ドメイン内のホストの数は非常に大規模であるため、管理のオーバーヘッドはかなり大きいものです。
この項では、管理ドメインのセキュリティを構成する方法について説明します。この項の内容は次のとおりです。
ドメインの構成には、次のタスクが含まれます。
Oracle Secure Backupをホストにインストールして管理サーバーとして指定すると、そのサーバーはCAとなります。Oracle Secure Backupは、標準インストールの一環として、ホストを自動的にCAとして構成します。そのサーバーに署名証明書を提供するために追加の手順をとる必要はありません。
Oracle Secure Backupは、次の動作を自動的に実行します。
管理サーバーに対応するホスト・オブジェクトを管理サーバー上のオブジェクト・リポジトリに作成します。
管理サーバーの証明書を格納するウォレットを作成します。このウォレットは、Oracle Secure Backupホームのディレクトリ・ツリーに存在します。Oracle Secure Backupは、ホストIDをウォレットのパスワードとして使用します。
署名証明書についてのリクエストをウォレットに作成します。
そのリクエストに呼応して署名された証明書を作成し、ウォレットに格納します。
ID証明書についてのリクエストをウォレットに作成します。
そのリクエストに呼応して署名された証明書を作成し、ウォレットに格納します。
不明瞭化ウォレットをローカルのウォレット・ディレクトリに作成します。
これで、管理サーバーは署名証明書およびID証明書を保持します。署名証明書は他のホストのID証明書に署名するために、ID証明書はドメイン内の他のホストとの認証されたSSL接続を確立するために必要です。
Webツールを使用するか、obtoolでmkhostコマンドを実行してホストを構成すると、新しいホストに対するセキュリティ資格証明が作成されます。「ホストのID証明書の配布方法の決定」で説明しているように、その手順は、ホストを追加するときの証明書プロビジョニング・モードが自動か手動かによって異なります。
新しいホストを自動モードで作成する場合は、追加の手順を実行する必要はありません。標準ホスト構成の一環として、ウォレット、鍵および証明書がホストに対して自動的に作成されます。
mkhostコマンドを実行すると、セキュアな（ただし認証されていない）SSL接続を介して次の手順が自動的に実行されます。
新しいホストに対応するホスト・オブジェクトが管理サーバーのオブジェクト・リポジトリに作成されます。
「ホストIDを設定」メッセージが新しいホストのobservicedに送信されます。
新しいホストのobservicedは、「ホストIDを設定」メッセージを処理する際に次の動作を実行します。
ホストの証明書を格納するウォレットを作成します。このウォレットは、Oracle Secure Backupホームのディレクトリ・ツリーに存在します。Oracle Secure Backupは、ホストIDをウォレットのパスワードとして使用します。
ID証明書についてのリクエストをウォレットに作成します。
操作の成功または失敗を示すステータス・メッセージを戻します。
新しいホストのobservicedは、証明書リクエスト・メッセージを管理サーバー上で稼働しているobservicedに送信します。リクエストには、CAによって署名される新しいホストのID証明書が含まれています。
管理サーバーでは、observicedが新しいホストのID証明書に署名し、証明書リクエスト・メッセージに呼応して、署名された証明書および信頼できる証明書を新しいホストに戻します。
新しいホストのobservicedは、証明書レスポンス・メッセージの処理の一環として、次の動作を実行します。
署名されたID証明書をCAの信頼できる証明書とともにウォレットに格納します。
不明瞭化ウォレットをOracle Secure Backupホームのファイル・システムに作成します。
操作の成功または失敗を示すステータス・メッセージを戻します。
これで、新しいホストは鍵のペア、ID証明書および信頼できる証明書を所有します。管理ドメイン内の他のホストとのセキュアな双方向の認証されたSSL接続を確立するのに必要なものがすべてホストにはあります。
新しいホストを手動モードで追加する場合は、新しいホストごとに次の手順を実行する必要があります。
mkhostコマンドを発行してホストを構成します。
mkhostコマンドに呼応して、自動モードで実行されるのと同じ手順が、手順5の前まで実行されます。手動モードでは、管理サーバー上で稼働しているobservicedはネットワークを介して新しいホストに証明書を送信しません。
obcmユーティリティを使用して、新しいホストに対する署名された証明書を管理サーバーからエクスポートします。このタスクは、「署名された証明書のエクスポート」で説明します。
署名されたID証明書をある種の物理媒体にコピーし、その媒体を新しいホストに物理的に移送します。
obcmユーティリティを使用して、署名された証明書を新しいホストのウォレットにインポートします。このタスクは、「署名された証明書のインポート」で説明します。
obcmユーティリティは、新しいホストに対する証明書に関連付けられた公開鍵が証明書リクエストとともにウォレットに格納されている秘密鍵と対応するかどうかをチェックします。鍵が合致する場合、新しいホストはそのドメインのメンバーです。鍵が合致しない場合、攻撃者が mkhostコマンドの処理時に新しいホストとして自分のホストを受け取らせようとした可能性が高いです。mkhostコマンドは、不正なホストがネットワークから排除された後に再度実行できます。
原則として、公開鍵および秘密鍵のサイズが大きければ大きいほど、セキュリティは向上します。一方で、鍵のサイズが小さければ小さいほど、パフォーマンスは向上します。ドメイン内のすべてのホストに対するデフォルトの鍵のサイズは1024ビットです。このデフォルトを受け入れる場合は、追加の構成を実行する必要はありません。
Oracle Secure Backupを使用すると、鍵は次のビット値のいずれかに設定できます。これらの値は、セキュリティの高いものから順に示されています。
4096（非常にセキュア）
3072（非常にセキュア）
2048（セキュア）
1024（セキュア）
768（セキュアではない）
512（セキュアではない）
鍵のサイズは次のように設定できます。
obparametersファイルは、デフォルトの鍵のサイズをセキュリティ・ポリシーに指定します。ドメイン内のすべてのホストに対する鍵のサイズは、デフォルトでこの値に設定されます。
certkeysizeセキュリティ・ポリシーでの鍵のサイズの設定
セキュリティ・ポリシーのデフォルトの鍵のサイズは、いつでも変更できます。変更後に構成されたホストは、デフォルトで新しい鍵のサイズに設定されます。
個々のホストに対するデフォルトの鍵のサイズを上書きできます。したがって、ドメイン内のホストごとに異なる鍵のサイズを設定できます。
鍵のサイズは、Oracle Secure Backupを管理サーバーにインストールする際に、 obparametersファイルに設定できます。Oracle Secure Backupを対話形式でインストールすると、インストール・スクリプトによってobparametersを変更する機会が与えられます。
対話形式でインストールする際に鍵のサイズをobparametersに設定するには、次のようにします。
管理サーバーでインストール・スクリプトを実行する前に、あるいはインストール・スクリプトからobparametersの変更を要求されたら、テキスト・エディタでファイルを開きます。
certificate key sizeという文字列を検索します。鍵のサイズを希望するデフォルト値に設定します。例11-1では、デフォルトの鍵のサイズを2048ビットに設定しています。
obparametersに他の変更を加えた後、ファイルを保存して閉じます。
インストールを続行します。
Oracle Secure Backupは、obparametersの鍵のサイズを使用してcertkeysizeセキュリティ・ポリシーの初期値を設定します。このセキュリティ・ポリシーは、ドメイン内のホストに対するセキュリティの鍵のデフォルト・サイズを設定します。このデフォルトは、個々のホストを構成する際に変更または上書きできます。
|
関連資料: obparametersファイルの構成方法は、『Oracle Secure Backupインストレーション・ガイド』を参照してください。 |
obtoolまたはWebツールを使用して、鍵のサイズをcertkeysizeセキュリティ・ポリシーに設定できます。次に新しいホストを構成する際に、変更後の鍵のサイズが使用されます。certkeysize値はいつでも変更できますが、変更は次のmkhostコマンドにのみ適用されます。
certkeysizeセキュリティ・ポリシーを設定するには、次のようにします。
管理ドメインの構成の変更（modify administrative domain's configuration）権限を持つユーザーとして、obtoolにログインします。
certkeysizeポリシーを希望するデフォルト値に設定します。例11-2に、obtoolを使用して鍵のサイズを3072ビットに設定する方法を示します。
mkhost コマンドまたはWebツールを使用して新しいホストを構成する際に、鍵のサイズを設定できます。mkhostコマンドに--certkeysizeオプションを指定すると、その値がセキュリティ・ポリシーにおける証明書の鍵のデフォルト・サイズに優先されます。この鍵のサイズは、新たに構成されるホストにのみ適用され、他の既存のホストおよびその後作成されるホストの鍵のサイズには影響を及ぼしません。
鍵のサイズが大きいほど、より小さい鍵のサイズに比べて鍵のペアを生成するための計算時間がより多く必要になるため、鍵のサイズの設定は、mkhostコマンドの処理時間に影響を与える可能性があります。mkhostコマンドの実行中に、obtoolからステータス・メッセージが5秒ごとに表示されます。処理が完了すると、コマンド・プロンプトが表示されます（例11-3を参照）。
mkhostコマンドで鍵のサイズを設定するには、次のようにします。
管理ドメインの構成の変更（modify administrative domain's configuration）権限を持つユーザーとして、obtoolにログインします。
mkhostコマンドを発行して、新しいホストに対する鍵のサイズを設定します。例11-3に、新しいクライアントstadf56を構成する際に鍵のサイズを4096に設定する方法を示します。この設定は、ホストstadf56に対してのみ適用されます。
例11-3 mkhostでの鍵のサイズの設定
ob> mkhost --inservice --role client --certkeysize 4096 stadf56 Info: waiting for host to update certification status... Info: waiting for host to update certification status... Info: waiting for host to update certification status... Info: waiting for host to update certification status... ob> lshost stadf56 stadf56 client (via OB) in service
|
関連資料: mkhostコマンドの使用方法は、『Oracle Secure Backupリファレンス』を参照してください。 |
「データの暗号化」で説明しているように、デフォルトでは、管理ドメイン内で転送される間、バックアップ・データは暗号化されます。たとえば、バックアップ・ジョブがクライアントC上のルート・ディレクトリをメディア・サーバーMにバックアップする場合、CからMに送信される間、ファイル・システムのバックアップ・データは暗号化されます。
移送中のバックアップ・データの暗号化は、encryptdataintransitセキュリティ・ポリシーをnoに設定すると無効にできます。
encryptdataintransitセキュリティ・ポリシーでバックアップの暗号化を無効にするには、次のようにします。
管理ドメインの構成の変更（modify administrative domain's configuration）権限を持つユーザーとして、obtoolにログインします。
setpコマンドを使用して、encryptdataintransitポリシーをnoに切り替えます。例11-4に、このタスクの実行方法を示します。
「ホストの認証と通信」で説明しているように、デフォルトでは、すべての内部ホスト制御メッセージのトラフィックには、認証済の暗号化されたSSL接続が使用されます。
SSL暗号化は、securecommsセキュリティ・ポリシーをoffに設定すると無効にできます。SSLを無効にするとパフォーマンスが向上する効果はありますが、この操作に固有のセキュリティ・リスクに留意してください。
securecommsセキュリティ・ポリシーを設定するには、次のようにします。
管理ドメインの構成の変更（modify administrative domain's configuration）権限を持つユーザーとして、obtoolにログインします。
setpコマンドを使用して、securecommsポリシーをoffに切り替えます。例11-5に、このタスクの実行方法を示します。
この項では、obcmユーティリティの使用方法について説明します。このユーティリティを使用すると、証明書のインポートおよびエクスポート、証明書リクエストのエクスポートができます。
obcmは、自動証明書プロビジョニング・モードではなく、手動モードで新しいホストをドメインに追加する際に使用する必要があります。その場合、CAは署名された証明書を新しいホストにネットワークを介して発行しないため、署名された証明書を管理サーバーからエクスポートして、その証明書を新たに構成されるホストに手動で移送して、ホストのウォレットにインポートする必要があります。
ID証明書とウォレットはいずれもファイルとしてオペレーティング・システムに存在します。obcmを実行するオペレーティング・システム・ユーザーには、ウォレット・ディレクトリでの書込み権限が必要です。デフォルトでは、Oracle Secure Backupで使用されるウォレットは次の場所にあります。
/usr/etc/ob/wallet（UNIXおよびLinux）
C:\Program Files\Oracle\Backup\db\wallet（Windows）
obcmは常に、これらの場所にあるウォレットにアクセスします。デフォルトの場所を上書きすることはできません。
obcmを管理サーバーで使用して、新たに構成されるホストに対する署名された証明書をエクスポートします。
署名されたID証明書をエクスポートするには、次のようにします。
管理サーバーにログオンします。
PATH変数が正しく設定されていることを前提に、オペレーティング・システムのコマンドラインにobcmと入力し、ユーティリティを起動します。obcmを実行するオペレーティング・システム・ユーザーには、ウォレット・ディレクトリでの書込み権限が必要です。
次のコマンドを入力します。ここでhostnameは証明書をリクエストするホストの名前、certificate_fileはエクスポートされるリクエストのファイル名です。
export --certificate --file certificate_file --host hostname
たとえば、次のコマンドは、ホストbrhost2に対する署名された証明書を、/tmp/brhost2_cert.fファイルにエクスポートします。
export --certificate --file /tmp/brhost2_cert.f --host brhost2
obcmを新しいホストで使用して、署名された証明書をホストのウォレットにインポートします。
署名された証明書を新しいホストのウォレットにインポートするには、次のようにします。
証明書を格納するウォレットがあるホストにログオンします。
PATH変数が正しく設定されていることを前提に、オペレーティング・システムのコマンドラインにobcmと入力し、ユーティリティを起動します。obcmを実行するオペレーティング・システム・ユーザーには、ウォレット・ディレクトリでの書込み権限が必要です。
署名されたID証明書をファイル・システム上の一時的な場所にコピーします。
次のコマンドをobcmプロンプトに入力します。ここでsigned_certificate_fileは、証明書のファイル名です。
import --file signed_certificate_file
Oracle Secure Backupのウォレットはホストに1つしか存在しないため、--hostオプションを指定する必要はありません。たとえば、次の例では、/tmp/brhost2_cert.fから証明書をインポートしています。
import --file /tmp/brhost2_cert.f
インポートされる証明書がウォレット内の証明書リクエストに対応していない場合は、obcmからエラー・メッセージが発行されます。
証明書ファイルをオペレーティング・システム上の一時的な場所から削除します。次に例を示します。
rm /tmp/brhost2_cert.f
