9 バックアップ・ネットワークのセキュリティ管理

この章では、バックアップ・ネットワークの保護を強化する方法について説明します。Oracle Secure Backupは、管理ドメインにおけるネットワーク・セキュリティに関して自動的に構成されますが、その基本レベルのセキュリティをいくつかの方法で強化できます。管理ドメインのノード間でのセキュアな通信は、ホスト間のネットワーク・トラフィックの暗号化と関係があります。セキュアな通信は、Oracle Secure Backupユーザーおよびロールによるセキュリティへの配慮、テープへのバックアップの暗号化によるセキュリティへの取組みとは区別されます。

関連項目:

ユーザーとロールの管理およびバックアップの暗号化の詳細は、『Oracle Secure Backup管理者ガイド』を参照してください

この章の内容は次のとおりです。

9.1 バックアップ・ネットワーク・セキュリティの概要

Oracle Secure Backupの管理ドメインは、ホストのネットワークです。このようなネットワークには、悪意ある攻撃に対して脆弱性があります。セキュリティ管理者の作業は、可能性のある攻撃の種類と、それらの攻撃からの防御手段について学ぶことです。実用的でセキュアなバックアップ・ネットワークは、次の要件を満たす必要があります。

ソフトウェア・コンポーネントにより、そのコンポーネントが稼働しているホストが攻撃にさらされないこと。

たとえば、デーモンでは、既知のポートでのリスニングや、任意に権限を与えられた操作の実行を防ぐ必要があります。
バックアップ・ソフトウェアで管理されるデータを、未認可のユーザーが表示、消去または変更できないこと。
バックアップ・ソフトウェアでは、認可されたユーザーにこれらの作業の実行を許可する必要があります。

Oracle Secure Backupでは、これらの要件をデフォルトの構成で満たしています。デフォルトでは、Oracle Secure Backupを実行するすべてのホストは、アイデンティティが確認されないと管理ドメインに追加できません。ドメイン内のホストは、ホスト認証に X.509証明書を使用します。Secure Sockets Layer(SSL)接続がホスト間で確立した後、制御メッセージとデータ・メッセージは暗号化されて、ネットワーク上を転送されます。SSLは管理ドメインを盗聴、メッセージの改ざんまたは偽造、およびリプレイ攻撃から保護します。

Oracle Secure Backupなどのネットワーク・バックアップ・ソフトウェアは、セキュアなバックアップ・ネットワークの唯一のコンポーネントです。Oracle Secure Backupは、管理者が提供する物理的なネットワーク・セキュリティに代わるものではありませんが、補完することはできます。

9.2 管理ドメインのセキュリティの計画

使用している環境でセキュリティが最大の関心事である場合、次の段階でネットワーク・セキュリティを計画すると役立ちます。

これらの段階を完了すると、「管理ドメインのセキュリティの構成」で説明している実装フェーズに進むことができます。

9.2.1 資産およびプリンシパルの特定

管理ドメインのセキュリティの計画における最初の手順は、ドメインに関連付けられた資産およびプリンシパルを決定することです。ドメインの資産には次のものがあります。

バックアップを必要とするデータベースおよびファイルシステム・データ
データベースおよびファイルシステム・データに関するメタデータ
パスワード
アイデンティティ
ホストおよびストレージ・デバイス

プリンシパルとは、管理ドメインに関連付けられた資産、またはドメインを含むより大きなネットワークに対するアクセス権限を持つユーザーです。プリンシパルには、次のユーザーが含まれます。

バックアップ管理者

このOracle Secure Backupユーザーには、ドメインの管理権限、バックアップ・データを保存するテープへのアクセス、バックアップおよびリストア操作を実行するために必要な権限があります。
データベース管理者

各データベース管理者は、所有するデータベースに対して完全なアクセス権限を持っています。
ホスト所有者

各ホスト所有者は、そのホストのファイル・システムに対して完全なアクセス権限を持っています。
システム管理者

このユーザーは、企業ネットワーク、および管理ドメイン内のホストに対してアクセス権限を持っています(ただし、必ずしもルートのアクセス権限とはかぎりません)。
参照者

このユーザーは、前述のプリンシパルのカテゴリには該当しませんが、Oracle Secure Backupのドメインを含むより大きなネットワークにアクセスできます。参照者は、ドメイン外にホストを所有できます。

資産とプリンシパルとの関係により、Oracle Secure Backupの管理ドメインにおけるセキュリティのレベルがある程度決定します。

最高レベルのセキュリティでは、資産へのアクセス権限を持つプリンシパルのみが所有者です。たとえば、クライアント・ホストの所有者のみが、このホストでデータの読取りまたは変更を行うことができます。
中レベルのセキュリティでは、資産所有者とドメイン管理者の両方が、資産にアクセスできます。
最低レベルのセキュリティでは、プリンシパルはドメイン内のどの資産にもアクセスできます。

9.2.2 バックアップ環境タイプの特定

管理ドメインに含まれる資産およびプリンシパルを確認すると、ドメインをデプロイする環境のタイプが明らかになります。環境のタイプにより、使用するセキュリティ・モデルがある程度決定します。

次の基準により、ネットワーク環境のタイプはある程度区別されます。

規模

ドメインに関連付けられた資産およびプリンシパルの数は、ドメイン・セキュリティで重要な役割を果します。1000ホストおよび2000ユーザーで構成されるネットワークには、5ホストおよび2ユーザーで構成されるネットワークより、攻撃者にとって多くのエントリ・ポイントがあります。
データの機密性

データの機密性は、データが悪意のあるユーザーよってアクセスされる危険度によって判定されます。たとえば、一般企業の従業員のホスト上にあるホーム・ディレクトリは、クレジット会社の加入者のデータよりも機密性は低いと考えられます。
通信メディアの分離

ネットワークのセキュリティは、ドメイン内のホストおよびデバイス間のネットワーク通信のアクセス可能性によって左右されます。非公開の企業データ・センターは、その意味では企業ネットワーク全体よりも分離された状態にあります。

次の各項では、Oracle Secure Backupの管理ドメインが、通常デプロイされるネットワーク環境のタイプについて説明します。また、各環境の標準的なセキュリティ・モデルについても説明します。

9.2.2.1 単一システム

最も基本的な管理ドメインを図9-1に示します。1つのホスト上の管理サーバー、メディア・サーバーおよびクライアントで構成されます。

図9-1 ホストが1つの管理ドメイン

「図9-1 1つのホストで構成される管理ドメイン」の説明

このタイプの環境は、規模が小さく、より広域のネットワークから分離されています。このネットワーク・タイプのデータは、機密性の範囲の低レベルにあると考えられます。たとえば、ドメインは、企業ネットワーク内の個人Webサイトのホストとして使用される1つのサーバーで構成される場合があります。

資産は、1つのホストと1つのテープ・デバイスのみです。ユーザーは、バックアップ管理者およびシステム管理者のみで、同一人物であると考えられます。バックアップ管理者は、Oracle Secure Backupドメインの管理ユーザーで、ドメイン上のバックアップの責任者です。システム管理者は、ドメインで使用されるホスト、デバイスおよびネットワークを管理します。

このネットワーク・タイプでは、少数の信頼できるユーザーのみがアクセスする分離されたホストが1つしかないため、ドメインはかなりセキュアです。ドメインの管理者にとってセキュリティ管理が主要な問題とはならず、バックアップ管理者は、Oracle Secure Backupドメインにおけるセキュリティのメンテナンスおよび管理に対するオーバーヘッドはほとんどないと予想できます。

9.2.2.2 データ・センター

図9-2の管理ドメインは、中規模サイズで、データ・センターなどのセキュアな環境にデプロイされます。

図9-2 複数のホストを含む管理ドメイン

「図9-2 複数のホストを含む管理ドメイン」の説明

管理ドメイン内のホスト、デバイスおよびユーザーの数は、単一システム・ネットワーク・タイプより大規模ですが、全体としてはネットワークの小規模なサブセットです。このネットワーク・タイプのデータは、機密性の範囲の最高レベルにあると考えられます。たとえば、極秘の従業員データの格納に使用されるホストのネットワークがあげられます。ネットワークのバックアップは、別のセキュアな専用ネットワーク上で行われます。

資産は、専用ネットワーク内の物理的にセキュアなコンピュータです。管理ドメインには、数百のデータベースおよびファイル・システムのバックアップを処理する数十のメディア・サーバー・ホストが含まれていることがあります。

プリンシパルには、次のユーザーが含まれます。

バックアップ管理者は、Oracle Secure Backup管理ユーザーとしてドメインにアクセスします。
システム管理者は、コンピュータ、デバイスおよびネットワークを管理します。
データベース管理者は、所有するデータベースにアクセスでき、場合によってはデータベース・コンピュータに物理的にアクセスできます。
ホスト管理者は、ファイル・システムにアクセスでき、場合によってはコンピュータに物理的にアクセスできます。

単一システム・ネットワーク・タイプと同様に、管理ドメインは、セキュアなネットワーク環境内に存在します。管理者は、外的手段によって各ホスト、テープ・デバイスおよびテープを保護します。ハッカーによるアクティブな攻撃は、ほぼありません。管理者は、ドメインに対するセキュリティのメンテナンスおよび管理にはオーバーヘッドをほとんど必要ないと想定します。バックアップ管理者およびシステム管理者の関心は、主にOracle Secure Backupがホスト間で効率的にデータ移動を行っているかどうかにあります。

9.2.2.3 企業ネットワーク

この環境では、複数の管理ドメイン、複数のメディア・サーバー・ホスト、および多数のクライアント・ホストが、企業ネットワーク内に存在します。

管理ドメイン内のホスト、デバイスおよびユーザーの数は、非常に大規模です。バックアップされるデータには、人事情報などの非常に機密性の高いデータ、および下位の従業員のホーム・ディレクトリなどの機密性の低いデータが含まれます。バックアップは通常、電子メール、インターネット・アクセスなどに使用されるのと同じ企業ネットワーク上で行われます。企業ネットワークは、ファイアウォールによって広域インターネットから保護されます。

資産には、基本的に企業内のすべてのデータおよびすべてのコンピュータが含まれます。各管理ドメインには、複数のユーザーが存在する可能性があります。一部のホスト所有者はOracle Secure Backupアカウントを持っていて、ホストのファイル・システムまたはデータベースのリストアを開始させることができます。

このバックアップ環境のセキュリティ要件は、単一システムやデータ・センターの例とは異なります。ネットワークの範囲や配置を考えると、クライアント・ホストの安全性が損われる可能性は非常に高くなります。たとえば、出張で使用されたラップトップを誰かに盗まれる可能性があります。悪意のある従業員が、コンピュータに不正にログインしたり、tcpdumpなどのユーティリティを実行して、ネットワーク・トラフィックをリスニングしたりする可能性もあります。

クライアント・ホストの安全性が損われることで、管理ドメイン全体の安全性が損われることがないようにする必要があります。安全性の損われたコンピュータで、悪意のあるユーザーが、他のホスト上で他のユーザーがバックアップしたデータにアクセスできないようにする必要があります。このようなユーザーが、管理ドメイン内の他のホストの通常操作に影響を与えることができないようにする必要もあります。

セキュリティ管理およびパフォーマンスのオーバーヘッドが予想されます。機密性の高い資産の所有者は、バックアップを暗号化して、バックアップ・メディアへの物理的アクセスによってバックアップのコンテンツが漏洩しないようにする必要があります。機密データが暗号化されていない形式でホストから流出しないように、クライアント・ホスト自体で暗号化および復号化を実行する必要があります。

注意:

Oracle Secure Backupでは、テープに格納されたデータが絶対に盗み見されないようする、非常に柔軟な構成が可能なバックアップ暗号化メカニズムをオプションで提供しています。バックアップ暗号化は、Oracle Secure Backupに完全に統合化されており、Oracle Secure Backupをインストールすればすぐに使用可能になります。バックアップ暗号化は、ファイルシステム・データとRecovery Manager(RMAN)で生成されたバックアップのどちらにも適用されます。

9.2.3 管理サーバーおよびメディア・サーバー用のセキュアなホストの選択

ドメインのセキュリティを構成する際の主な作業は、ホストに物理的なセキュリティおよびネットワーク・セキュリティを提供し、管理サーバーおよびメディア・サーバーのロールを実行するホストを決定することです。

管理サーバーおよびメディア・サーバーを選択する際、ホストが管理サーバーまたはメディア・サーバーになるのは、物理的なセキュリティとネットワーク・セキュリティの両方によって保護される場合にかぎることを忘れないでください。たとえば、データ・センターのホストは、少数の信頼できる管理者がアクセスできる非公開の保護されたネットワークに属すると考えられるため、管理サーバーの候補にすることができます。

Oracle Secure Backup自体は、物理的なセキュリティまたはネットワーク・セキュリティをホストに対して提供できず、そのようなセキュリティが存在するかどうかを検証することもできません。たとえば、Oracle Secure Backupは、悪意のあるユーザーが次のような不正行為を行うことを阻止できません。

ホストを物理的に危険にさらすこと

ホストに物理的にアクセスできる攻撃者は、プライマリ・ストレージまたはセカンダリ・ストレージを盗んだり破壊したりできます。たとえば、泥棒がオフィスに押し入り、サーバーやテープを盗む可能性があります。暗号化により、データに対する脅威をいくらか軽減できますが、完全ではありません。管理サーバーに物理的にアクセスできる攻撃者は、管理ドメイン全体を危険にさらします。
ホストのオペレーティング・システムへのアクセス

クライアント・ホストの所有者がパスワードを入力するのを観察して、参照者がパスワードを盗んだとします。この悪意のあるユーザーは、そのホストにTelnetでアクセスし、プライマリ・ストレージのデータを削除、置換またはコピーできます。世界で最もセキュアなバックアップ・システムでも、攻撃者が元の場所にあるデータにアクセスできる場合は、データを保護できません。
ネットワークへの潜入または盗聴

バックアップ・ソフトウェアは、場合によっては、保護されていないネットワークで安全に通信できますが、常にそうできるわけではありません。ネットワーク・セキュリティは、特にネットワーク・データ管理プロトコル(NDMP)に基づく通信の場合、バックアップ・システムの重要な部分です。
Oracle Secure Backupのアイデンティティの意図的な悪用

Oracle Secure Backupの管理者権限を持つユーザーが悪意のあるユーザーになると、管理ドメインに大損害を与えかねません。たとえば、ドメイン内のすべてのホスト上のファイル・システムを上書きできます。バックアップ・ソフトウェアでは、所属する組織の利益を最優先に考えて行動するようユーザーに強制できません。

9.2.4 ホスト・アイデンティティ証明書の配布方法の決定

バックアップ環境を分析して保護方法を検討した後、ドメイン内の各ホストのアイデンティティ証明書の取得方法を決定できます。Oracle Secure Backupでは、Secure Sockets Layer(SSL)を使用してセキュアで信頼できる通信チャネルをドメイン・ホスト間に確立します。各ホストは、ドメイン内でこのホストを一意に識別する認証局(CA)が署名したアイデンティティ証明書を持っています。アイデンティティ証明書は認証されたSSL接続に必要です。

関連項目:

「ホストの認証と通信」
「認証局」

管理ドメインの管理サーバーは、ドメインのCAです。管理サーバーの構成が終わると、各メディア・サーバーおよびクライアントを次のいずれかのモードでドメイン内に作成できます。

自動証明書プロビジョニング・モード

この場合、手動の管理は不要です。ホストを構成する際、CAはネットワーク上でホストにアイデンティティ証明書を発行します。
手動証明書プロビジョニング・モード

この場合、ホストごとにアイデンティティ証明書を手動でウォレットにインポートする必要があります。

自動モードの方が使用は簡単ですが、ドメイン参加の直前で攻撃者がホストの名前を盗む、きわめてまれな中間者攻撃を受けやすくなります。この攻撃者は、盗んだホスト・アイデンティティを使用してドメインに不正に参加します。手動モードの方が自動モードより使用は難しくなりますが、同種の攻撃は受けにくくなります。

手動モードでは、管理サーバーはアイデンティティ証明書のレスポンスをホストに送信しません。かわりに、署名付きアイデンティティ証明書のコピーを物理メディアでホストに移動し、obcmユーティリティを使用して新しいホストのウォレットにインポートする必要があります。obcmユーティリティは、ウォレット内の証明書リクエストが、署名付きアイデンティティ証明書と一致するかどうかを検証します。検証が失敗した場合、不正なホストがそのホストのふりをしようとした可能性が高いことを示します。mkhostコマンドは、不正なホストがネットワークから削除された後に再発行できます。

関連項目:

「obcmによる証明書の管理」
obcmユーティリティの詳細は、『Oracle Secure Backupリファレンス』を参照してください。

手動証明書プロビジョニング・モードを検討する場合、提供される特別な保護が、管理オーバーヘッドに値するかどうかを判断する必要があります。単一システムおよびデータ・センターの環境では、ネットワーク通信は通常分離されているため、自動モードが安全です。

自動モードは、企業ネットワークの大部分でも安全です。企業ネットワークは、攻撃者が管理サーバーと追加されるホストの間のネットワークに侵入できる場合のみ、中間者攻撃に対して脆弱です。これは、攻撃者がネットワーク・トラフィックを傍受し、中間者として行動できる唯一の場所です。これは不正を働く従業員の介助がなければ困難です。

追加されるホストが企業ネットワークの外にある場合、オフサイトのホストとの通信では傍受や妨害の機会が増えるため、手動証明書プロビジョニング・モードの使用をお薦めします。

9.3 信頼できるホスト

Oracle Secure Backupリリース10.3以降、管理ドメイン内の一部のホストのセキュリティ・レベルが強化され、絶対的レベルの信頼性を持つホストとして扱われます。これらのホストは、管理サーバーと各メディア・サーバーです。これらのホストは、Oracle Secure Backupによって信頼できるホストとして分類されます。クライアント・ロールのみを使用して構成されているホストは、信頼できないホストとして分類されます。

関連項目:

「管理サーバーおよびメディア・サーバー用のセキュアなホストの選択」

多くのOracle Secure Backup操作は、トラステッド・ホストによる使用のために予約されており、信頼できないホストによって実行された場合は失敗します。これらの操作には、次のものがあります。

obtarコマンドの使用
物理デバイスおよびライブラリへの直接アクセス
暗号化キーへのアクセス

このポリシーにより、安全性が損われたクライアント・システムから生じた可能性のある攻撃に対する特別レベルのセキュリティが実現します。たとえば、管理サーバーとしてadminホスト、メディア・サーバーとしてmediaホスト、クライアントとしてclientホストを持つOracle Secure Backup管理ドメインについて考えてみます。あるクラスに属し、manage devicesクラス権限を持つOracle Secure Backupユーザーが、obtoolでlsvol -L library_nameを実行しようとします。クライアントに対して試行すると、非トラステッド・ホストからの不正リクエスト(illegal request from non-trusted host)というエラーで失敗します。同じコマンドをadminまたはmediaに対して試行した場合は成功します。

Oracle Secure Backupセキュリティ・ポリシーtrustedhostsをoffに設定することで、これらの信頼チェックを無効にできます。これにより、信頼できないホストに設定された制約が無効になります。

注意:

Oracle Secure Backup Webツールからのコマンドは、常に処理のために管理サーバーに転送されるため、trustedhostsポリシーの影響は受けません。

9.4 ホストの認証と通信

デフォルトでは、Oracle Secure BackupはSecure Sockets Layer(SSL)プロトコルを使用して、管理ドメインのホスト間のセキュアな通信チャネルを確立します。各ホストには、アイデンティティ証明書として知られるX.509証明書があります。このアイデンティティ証明書は、認証局(CA)によって署名され、管理ドメイン内のこのホストを一意に識別します。アイデンティティ証明書は認証されたSSL接続に必要です。

注意:

現在、ネットワーク・データ管理プロトコル(NDMP)は、ファイラに対するSSL接続をサポートしていません。

obtool –authenticateコマンドを使用して、ドメインの認証性を検証できます。このコマンドはobtoolを起動し、コマンドを実行する前にドメイン資格証明をリクエストします。

この項の内容は次のとおりです。

9.4.1 アイデンティティ証明書と公開鍵の暗号化

アイデンティティ証明書には、本体とデジタル署名があります。証明書の内容は次のとおりです。

公開鍵
ホストのアイデンティティ
ホストでの実行が許可されていること

管理サーバーを含むドメイン内のすべてのホストには、ホストのアイデンティティ証明書とともに保存されているホストにしか知られていない秘密鍵があります。この秘密鍵は、管理ドメイン内の他のホストで使用できる公開鍵に対応しています。

ドメイン内のホストは、公開鍵を使用して暗号化メッセージを別のホストに送信できます。しかし、対応する秘密鍵を持つホストのみが、そのメッセージを復号化できます。ホストはその秘密鍵を使用して、デジタル署名をメッセージに添付できます。ホストは、メッセージを入力として暗号化ハッシュ関数に送信し、出力ハッシュを秘密鍵で暗号化することで、デジタル署名を作成します。

受信側ホストは、デジタル署名を送信側ホストの公開鍵で復号化することにより認証します。その後、受信側ホストは秘密鍵で暗号化メッセージを復号化し、署名の作成に使用したのと同じハッシュ関数に復号化したメッセージを入力し、復号化した署名と出力ハッシュを比較します。2つのハッシュが一致すれば、このメッセージは改ざんされていません。

図9-3は、ホストBがホストAに対するメッセージを暗号化して署名し、それに対してホストAがメッセージを復号化して署名を検証するプロセスを示しています。

図9-3 公開鍵と秘密鍵を使用したメッセージの暗号化と署名

「図9-3 公開鍵と秘密鍵を使用したメッセージの暗号化と署名」の説明

9.4.2 認証済SSL接続

ホストがドメイン内で制御メッセージやバックアップ・データを安全に交換するには、最初に相互認証を行う必要があります。ホスト接続は常に双方向で認証されますが、ホストへの最初のドメイン参加案内やネットワーク・データ管理プロトコル(NDMP)サーバーとの通信は例外です。

双方向認証では、使用する暗号スイートを双方で取り決めるハンドシェイク・プロセスに参加するホストは、アイデンティティ証明書を交換し、互いのアイデンティティ証明書が信頼できる認証局(CA)によって発行されたことを検証します。このプロセスの最後に、データ交換用のセキュアで信頼できる通信チャネルが確立されます。

アイデンティティ証明書とSecure Sockets Layer(SSL)の使用によって、外部の攻撃者が管理ドメインのクライアントになりすましたり、バックアップ・データにアクセスしたりするのを防ぎます。たとえば、外部の攻撃者がドメイン外のホストでアプリケーションを実行して、メッセージをドメイン内のホストから送信されたものとしてドメイン・ホストに送信することはできません。

9.4.3 認証局

管理サーバー上のサービス・デーモン(observiced)は、管理ドメインのルート認証局(CA)です。CAの主なタスクは、管理ドメイン内の各ホストにアイデンティティ証明書を発行して署名することです。CAが自身に対して発行し署名したCAの署名証明書により、ドメインのホストに対するアイデンティティ証明書に署名する権限がCAに与えられます。この信頼関係では、管理ドメインのすべてのホストがCAによって発行された証明書を信頼できることが必要です。

各ホストには、ホスト独自のアイデンティティ証明書と、CAまでの信頼チェーンを確立する信頼できる証明書(証明書のセット)が保存されています。ドメインの他のホストと同様に、CAにもそのアイデンティティ証明書が保存されています。CAには、ドメインの他のホストに対するアイデンティティ証明書への署名権限をCAに付与する署名証明書も保存されています。

CAの管理の詳細は、「obcmによる証明書の管理」を参照してください。

9.4.3.1 自動および手動証明書プロビジョニング・モード

Oracle Secure Backupでは、ドメインに参加するクライアント・ホストに対するセキュリティ資格証明の初期設定で、自動と手動のモードが用意されています。自動モードは簡単に使用できますが、潜在的なセキュリティ面での脆弱性があります。手動モードは使いにくい面はありますが、改ざんに対する脆弱性は低くなります。

デフォルトの自動証明書プロビジョニング・モードでは、ドメインへのホストの追加は透過的に行われます。ホストは、公開鍵と秘密鍵のペアを生成し、公開鍵が含まれる証明書リクエストを認証局(CA)に送信します。CAはホストにアイデンティティ証明書を発行し、CAまでの信頼チェーンの確立に必要な証明書とともにホストに送信します。

2つのホストの間の通信は、セキュアで非認証のSecure Sockets Layer (SSL)接続上で行われます。CAとホストの間のネットワークに不正なホストが割り込み、正当なホストになりすまして不正にドメインに参加する可能性があります。

手動証明書プロビジョニング・モードでは、CAはホストに証明書レスポンスを自動的に送信しません。

証明書を転送する手順:

obcmユーティリティを使用して、CAから署名付き証明書をエクスポートします。
フロッピー・ディスクやUSBキー・チェーン・ドライブなどのセキュアなメカニズムを使用して、CAからの署名付きアイデンティティ証明書のコピーをホストに移します。
ホストでobcmを使用して、移された証明書をホストのウォレットにインポートします。obcmユーティリティは、ウォレット内の証明書リクエストが、署名付きアイデンティティ証明書と一致するかどうかを検証します。

ユーザーは、セキュリティと操作性のバランスを考慮して、管理ドメインに適した証明書プロビジョニング・モードを決定する必要があります。

9.4.4 Oracleウォレット

Oracle Secure Backupでは、Oracleウォレットにすべての証明書が格納されます。ウォレットは、オペレーティング・システムにおいてパスワードで保護された暗号化ファイルとして表されます。管理ドメインの各ホストにはそれぞれのウォレットがあり、ホストのアイデンティティ証明書、秘密鍵、および1つ以上の信頼できる証明書が保存されています。Oracle Secure Backupは、ウォレットを他のOracle製品と共有しません。

パスワードで保護されたウォレット以外に、ドメインの各ホストには不明瞭化ウォレットも保存されています。この種類のウォレットにはパスワードは不要です。不明瞭化ウォレットは、スクランブル化されていますが暗号化されていないため、Oracle Secure Backupソフトウェアをシステム起動時にパスワードを必要とせずに実行できます。

注意:

不明瞭化ウォレットへの未認可アクセスによるリスクを減らすため、Oracle Secure Backupではこれらのウォレットをバックアップしません。不明瞭化ウォレットは、cwallet.ssoというファイルです。デフォルトでは、ウォレットはLinuxおよびUNIXでは/usr/etc/ob/walletに、WindowsではC:\Program Files\Oracle\Backup\db\walletにあります。

パスワードで保護されたウォレットのパスワードは、Oracle Secure Backupによって保護され、ユーザーは使用できません。Oracle Secure Backupデーモンは不明瞭化ウォレットを使用するため、ホストに対するセキュリティ資格証明の確立後は、パスワードで保護されたウォレットは通常使用されません。

図9-4は、ドメインにおける認証局と他のホスト間の関係を示しています。

図9-4 Oracleウォレット

「図9-4 Oracleウォレット」の説明

9.4.4.1 Oracle Secure Backup暗号化ウォレット

管理サーバーには2番目のウォレットがあり、ネットワーク・データ管理プロトコル(NDMP)・サーバーのパスワードや、バックアップ暗号化キー・ストアなどの、セキュアなデータを暗号化するマスター鍵の格納に使用されます。このウォレットは、ホスト・アイデンティティ証明書に使用されるウォレットとは別です。キー・ウォレットはewallet.p12という名前が付けられ、OSB_HOME/admin/encryption/walletにあります。

ベスト・プラクティスとして、ウォレットのバックアップには、Oracle Secure Backupのカタログ・リカバリを使用します。

ウォレットのバックアップにOracle Secure Backupカタログを使用しない場合は、ewallet.p12暗号化ウォレットを、暗号化されたデータと同じメディア上にバックアップしないことをお薦めします。暗号化ウォレットは、バックアップ操作から自動的に除外されません。バックアップ時に除外するファイルを指定するには、excludeデータセット文を使用する必要があります。

exclude name *.p12

9.4.5 Webサーバーの認証

管理ドメインのApache Webサーバーは、obhttpdデーモンとして管理サーバーで稼働します。Oracle Secure Backup Webツールからコマンドを発行すると、obhttpdはそれらをobtoolコマンドとして再パッケージして、管理サーバーで実行中のobtoolのインスタンスに渡します。

Webサーバーでは、クライアントWebブラウザとのSecure Sockets Layer(SSL)接続を確立するため、署名付きのX.509証明書と、関連付けられた公開鍵/秘密鍵のペアを要求します。Webサーバーに対するX.509証明書は、管理サーバーにOracle Secure Backupをインストールする際に自己署名されます。図9-5は、Webサーバーとクライアント間のやり取りを示しています。

図9-5 Webサーバーの認証

「図9-5 Webサーバーの認証」の説明

WebサーバーのX.509証明書および鍵は、Oracle Secure Backup管理ドメインのホスト認証に使用されるウォレットには保存されませんが、Oracle Secure Backupホームの/apache/confサブディレクトリのファイルに保存されます。1つのパスワードが、証明書と鍵を保護します。このパスワードは、暗号化された形式で/admin/config/defaultにあるdaemonsファイルに保存されます。Webサーバーが起動すると、Webサーバー構成ファイルで指定されたメカニズムを使用して、パスワードが取得されます。このパスワードは、ネットワークでは決して送信されません。

9.4.6 ホスト・アイデンティティ証明書の取消し

ホスト・アイデンティティ証明書の取消しは、Oracle Secure Backupの管理ドメインにおけるコンピュータのセキュリティが、なんらかの方法で侵害されたことをバックアップ管理者が確認した場合にのみ実行される非常手段です。

ホスト・アイデンティティ証明書は、obtoolのrevhostコマンドで取り消すことができます。

関連項目:

revhostの構文およびセマンティックスは、『Oracle Secure Backupリファレンス』を参照してください。

ホスト・アイデンティティ証明書を取り消すと、Oracle Secure Backupサービス・デーモンはそのホストからの接続を受け入れません。取消しは元には戻せません。ホスト・アイデンティティ証明書を取り消してから気が変わった場合、影響を受けるホストにOracle Secure Backupソフトウェアを再インストールする必要があります。

9.5 転送中のデータの暗号化

図1-2は、管理ドメイン内の制御フローとデータ・フローを示しています。管理ドメインのホストで交換される制御メッセージは、Secure Sockets Layer(SSL)によって暗号化されます。

ドメイン内のデータ・フローにはファイルシステムとデータベース・バックアップ・データの両方が含まれます。バックアップの暗号化によるデータへの影響を理解するには、停止中データ(ディスクやテープなどのメディア上のバックアップ・データ)と転送中のデータ(ネットワークを転送中のバックアップ・データ)とを区別することが重要です。

テープでのファイルシステム・バックアップおよび暗号化されていないRMANバックアップ(停止中データ)は、Oracle Secure Backupで暗号化できます。Oracle Secure BackupのSBTインタフェースで作成されたRMAN暗号化バックアップはサポートされますが、バックアップがSBTインタフェースに提供される前に、暗号化がRMANによって提供されます。Oracle Secure BackupのSBTインタフェースは、暗号化されたRMANバックアップをテープに直接行うためにサポートされる唯一のインタフェースです。

関連項目:

Oracle Secure Backupの暗号化の詳細は、『Oracle Secure Backup管理者ガイド』を参照してください。

RMANまたはOracle Secure Backupの暗号化を選択すると、Oracle Secure Backupでは管理ドメイン内の転送中データに追加の暗号化は適用されません。RMANの暗号化またはOracle Secure Backupの暗号化のいずれも選択しなかった場合、転送中のバックアップ・データは、ファイルシステムとデータベースのどちらのデータも、デフォルトではSSLによって暗号化されません。セキュリティ強化のため、encryptdataintransitセキュリティ・ポリシーを使用して、管理ドメイン内の転送中データの暗号化を有効にできます。

encryptdataintransmitセキュリティ・ポリシーのバックアップの暗号化を有効にする手順:

管理ドメインの構成の変更(modify administrative domain's configuration)権限を持つユーザーとしてobtoolにログインします。
setpコマンドを使用して、次の例のようにencryptdataintransitポリシーをnoに切り替えます。
```
ob> cdp security
ob> setp encryptdataintransit yes
```

関連項目:

encryptdataintransitセキュリティ・ポリシーの詳細は、『Oracle Secure Backupリファレンス』を参照してください。

クライアント・ホストclient_host上のデータをメディア・サーバーmedia_serverに接続されたテープ・ドライブにバックアップするとします。データの暗号化は、次の例に示すように、選択する暗号化オプションとバックアップの対象によって異なります。

client_host上のデータベースの暗号化RMANバックアップ

RMANは、バックアップをclient_hostでSBTインタフェースに提供する前に暗号化します。Oracle Secure Backupは、RMANによって暗号化されたデータをネットワークでmedia_serverに送信します。Oracle Secure Backupでは、データをネットワークで送信する際には、追加の暗号化を適用しません。Oracle Secure Backupがデータをテープに書き込むと、データは暗号化された形式でテープに保存されます。
client_host上のデータベースの非暗号化RMANバックアップ

Oracle Secure Backupでは、データをネットワークでmedia_serverに送信する前に暗号化しません。Oracle Secure Backupがデータをテープに書き込むと、データは暗号化されていない形式でテープに保存されます。
encryptdataintransitがyesに設定されているclient_host上のデータベースの非暗号化RMANバックアップ

Oracle Secure Backupでは、データをネットワークでmedia_serverに送信する前に暗号化します。暗号化データは、media_serverで復号化されます。Oracle Secure Backupがデータをテープに書き込むと、データは暗号化されていない形式でテープに保存されます。
client_host上のファイル・システムの暗号化Oracle Secure Backupバックアップ

Oracle Secure Backupは、暗号化バックアップ・データをネットワークでmedia_serverに送信します。Oracle Secure Backupでは、データをネットワークで送信する際には、追加の暗号化を適用しません。Oracle Secure Backupがデータをテープに書き込むと、ファイルシステムのデータは暗号化された形式でテープに保存されます。
client_host上のファイル・システムの非暗号化Oracle Secure Backupバックアップ

Oracle Secure Backupでは、データをネットワークでmedia_serverに送信する前に暗号化しません。Oracle Secure Backupがデータをテープに書き込むと、データは暗号化されていない形式でテープに保存されます。
encryptdataintransitをyesに設定したclient_host上のファイル・システムの非暗号化Oracle Secure Backupバックアップ

Oracle Secure Backupでは、データをネットワークでmedia_serverに送信する前に暗号化します。暗号化データは、media_serverで復号化されます。Oracle Secure Backupがデータをテープに書き込むと、データは暗号化されていない形式でテープに保存されます。

関連項目:

RMANバックアップの暗号化の詳細は、『Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイド』を参照してください。

9.6 デフォルトのセキュリティ構成

Oracle Secure Backupを管理サーバーにインストールする際、インストール・プログラムは管理サーバーを認証局(CA)として自動的に構成します。デフォルトでは、管理ドメインのセキュリティは、次のように構成されます。

Secure Sockets Layer(SSL)は、ホスト認証とメッセージ整合性に使用されます。
CAは、自動証明書プロビジョニング・モードで、各ドメインのホストに対するアイデンティティ証明書に署名して発行します。
ドメインのすべてのホストに対する公開鍵と秘密鍵のサイズは3072ビットです。
ドメイン内のホスト通信は、SSLで暗号化されます。

管理ドメインにホストを追加する場合、obtoolまたはOracle Secure Backup Webツールでホストを作成すると、各ホストのウォレット、鍵および証明書がOracle Secure Backupによって作成されます。その他の調整や構成は不要です。

次のいずれかの方法で、デフォルト構成を変更することもできます。

securecommsセキュリティ・ポリシーの設定による、ホスト間の認証および通信に対するSSLの無効化
手動証明書プロビジョニング・モードでのアイデンティティ証明書の転送
ホストの鍵サイズに対する、デフォルトの3072ビットを上回るまたは下回る値の設定
encryptdataintransitセキュリティ・ポリシーの設定による、転送中のバックアップ・データに対する暗号化の有効化

9.7 管理ドメインのセキュリティの構成

この項では、管理ドメインのセキュリティを構成する方法について説明します。

この項の内容は次のとおりです。

9.7.1 管理ドメイン内のホストへの証明書の提供

Oracle Secure Backupの管理ドメイン内の各ホストに証明書を提供するには、まず管理サーバーを構成し、次に各メディア・サーバーとクライアントを構成する必要があります。

9.7.1.1 管理サーバーの構成

Oracle Secure Backupをホストにインストールし、このホストを管理サーバーとして指定すると、このサーバーはOracle Secure Backup管理ドメインの認証局(CA)となります。Oracle Secure Backupは、標準インストールの一環として、自動的にホストをCAとして構成します。このサーバーに署名証明書を提供するために追加の手順は必要ありません。

Oracle Secure Backupでは、自動的に次のアイテムを作成します。

管理ドメイン・サーバー上のオブジェクト・リポジトリ内の管理サーバーに対応するホスト・オブジェクト。
管理サーバーの証明書を保存するウォレット。ウォレットは、Oracle Secure Backupホームのディレクトリ・ツリーに存在します。Oracle Secure Backupでは、ウォレットのパスワードとしてホストIDを使用します。
ウォレット内の署名証明書に対するリクエスト。
リクエストに応じて署名付き証明書を作成し、ウォレットに保存。
ウォレット内のアイデンティティ証明書に対するリクエスト。
リクエストに応じて署名付き証明書を作成し、ウォレットに保存。
ローカル・ウォレット・ディレクトリ内に不明瞭化ウォレットを作成。

これで管理サーバーに、他のホストのアイデンティティ証明書に署名するために必要な署名証明書と、ドメイン内の他のホストとの認証済Secure Sockets Layer(SSL)接続の確立に必要なアイデンティティ証明書が揃いました。

9.7.1.2 メディア・サーバーおよびクライアントの構成

Oracle Secure Backup Webツールの使用またはobtoolでのmkhostコマンドの実行によりホストを構成すると、Oracle Secure Backupではホストに対するセキュリティ資格証明が作成されます。その手順は、ホストを自動または手動証明書プロビジョニング・モードのいずれで追加するかによって異なります。

関連項目:

「ホスト・アイデンティティ証明書の配布方法の決定」

自動証明書プロビジョニング・モード

ホストを自動証明書プロビジョニング・モードで作成する場合、追加の手順を実行する必要はありません。標準ホスト構成の一環として、ウォレット、鍵および証明書がホストに対して自動的に作成されます。

手動証明書プロビジョニング・モード

ホストを自動証明書プロビジョニング・モードではなく手動でドメインに追加する場合は、obcmユーティリティを使用する必要があります。この場合、認証局はネットワーク上で署名付き証明書をホストに発行しないため、署名付き証明を管理サーバーからエクスポートし、手動で証明書を新たに構成されたホストに移し、ホストのウォレットに証明書をインポートする必要があります。

アイデンティティ証明書とウォレットの両方が、ファイルとしてオペレーティング・システム上に存在します。obcmを実行するオペレーティング・システム・ユーザーには、ウォレット・ディレクトリでの書込み権限が必要です。デフォルトでは、Oracle Secure Backupで使用されるウォレットは、次の場所にあります。

/usr/etc/ob/wallet(UNIXおよびLinux)
C:\Program Files\Oracle\Backup\db\wallet(Windows)

obcmユーティリティは、常に前述の場所にあるウォレットにアクセスします。デフォルトの場所を無効にすることはできません。

手動証明書プロビジョニング・モードでホストを追加する場合、ホストごとに次の手順を実行する必要があります。

管理サーバーにrootとしてログインします。
PATH変数が正しく設定されている場合、オペレーティング・システムのコマンドラインでobcmと入力し、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
```
署名付きアイデンティティ証明書を物理メディアにコピーし、そのメディアをホストに物理的に移します。
ウォレットに証明書が含まれているホストにログオンします。
PATH変数が正しく設定されている場合、オペレーティング・システムのコマンドラインでobcmと入力し、obcmユーティリティを起動します。obcmを実行するオペレーティング・システム・ユーザーには、ウォレット・ディレクトリでの書込み権限が必要です。
署名付きアイデンティティ証明書を、ファイル・システム上の一時的な場所にコピーします。
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
```

obcmユーティリティは、ホストの証明書に関連付けられた公開鍵が、証明書リクエストとともにウォレットに保存された秘密鍵と対応するかどうかをチェックします。鍵が一致した場合、ホストはそのドメインのメンバーです。鍵が一致しない場合、攻撃者がmkhostコマンドの処理中にホストになりすまそうとした可能性があります。mkhostコマンドは、不正なホストがネットワークから削除された後に再実行できます。

9.7.2 公開鍵および秘密鍵のサイズの設定

原則として、公開鍵および秘密鍵のサイズが大きいほど、セキュリティは向上します。一方、鍵のサイズが小さいほど、パフォーマンスは向上します。ドメイン内のすべてのホストに対するデフォルトの鍵のサイズは3072ビットです。このデフォルトを受け入れれば、追加の構成を実行する必要はありません。

Oracle Secure Backupを使用すると、鍵は次のビット値のいずれかに設定できます。これらの値は、セキュリティの高いものから順に示されています。

4096
3072
2048
1024
768
512

この項の内容は次のとおりです。

9.7.2.1 インストール時の鍵のサイズの設定

セキュリティ・ポリシーの鍵サイズは、管理サーバーへのOracle Secure Backupのインストール時に設定できます。インストール時に指定した鍵のサイズは、the certkeysizeセキュリティ・ポリシーの初期値の設定に使用されます。このセキュリティ・ポリシーは、ドメイン内のホストに対するセキュリティ鍵のデフォルト・サイズを指定します。このデフォルト値は、個々のホストを構成する際に変更または無効化できます。

The Oracle Secure Backupインストーラでは、デフォルトの鍵サイズ値が使用されます。このデフォルト値を変更するには、インストール時に、インストールの詳細設定を構成する必要があります。

関連項目:

9.7.2.2 certkeysizeセキュリティ・ポリシーでの鍵のサイズの設定

デフォルトの証明書鍵サイズのセキュリティ・ポリシーは、いつでも変更できます。この変更は、既存のホストには影響しません。ドメインに追加された新しいホストにのみ影響します。

certkeysizeセキュリティ・ポリシーの鍵のサイズは、obtoolまたはOracle Secure Backup Webツールを使用して設定できます。Oracle Secure Backupでは、次にホストを構成する際、変更後の鍵のサイズが使用されます。certkeysize値はいつでも変更できますが、変更は次のmkhostコマンドにのみ適用されます。

certkeysizeセキュリティ・ポリシーを設定するには、次のようにします。

管理ドメインの構成の変更(modify administrative domain's configuration)権限を持つユーザーとしてobtoolにログインします。
certkeysizeポリシーを必要なデフォルト値に設定します。次の例は、obtoolを使用して鍵のサイズを3072ビットに設定する方法を示しています。
```
ob> cdp security
ob> setp certkeysize 3072
```

関連項目:

ポリシーの設定方法は、『Oracle Secure Backup管理者ガイド』を参照してください。

9.7.2.3 mkhostでの鍵のサイズの設定

個々のホストには、デフォルトの鍵のサイズを無効にして別の値を優先させることができます。ドメイン内の異なるホストには、異なる鍵のサイズを指定できます。

鍵のサイズは、mkhostコマンドまたはOracle Secure Backup Webツールを使用してホストを構成する際に設定できます。mkhostコマンドに--certkeysizeオプションを指定すると、その値がセキュリティ・ポリシーで設定された証明書の鍵のデフォルト・サイズに優先されます。この鍵のサイズは、新たに構成されるホストにのみ適用され、他の現行ホストや今後作成されるホストの鍵のサイズには影響を及ぼしません。

サイズの大きい鍵は、サイズの小さい鍵より鍵のペアの生成に時間がかかるため、鍵のサイズの設定は、mkhostコマンドの処理時間に影響を及ぼします。mkhostコマンドの実行中、obtoolから5秒間隔でステータス・メッセージが表示されます。処理が完了すると、obtoolはコマンド・プロンプトを表示します。

mkhostコマンドで鍵のサイズを設定するには、次のようにします。

管理ドメインの構成の変更(modify administrative domain's configuration)権限を持つユーザーとしてobtoolにログインします。

mkhostコマンドを発行して、ホストの鍵のサイズを設定します。次の例では、クライアントstadf56を構成する際に、鍵のサイズを4096ビットに設定しています。この設定は、ホストstadf56に対してのみ適用されます。

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リファレンス』を参照してください。

9.7.3 ホストの認証および通信に対するSSLの有効化および無効化

デフォルトでは、ホスト間のすべての制御メッセージのトラフィックに、認証済の暗号化されたSecure Sockets Layer(SSL)接続が使用されます。

securecommsセキュリティ・ポリシーをoffに設定して、SSL暗号化を無効にすることができます。SSLを無効にするとパフォーマンスが向上しますが、この操作固有のセキュリティ・リスクがあることに注意してください。

関連項目:

「ホストの認証と通信」

securecommsセキュリティ・ポリシーを設定するには、次のようにします。

管理ドメインの構成の変更(modify administrative domain's configuration)権限を持つユーザーとしてobtoolにログインします。
setpコマンドを使用して、次の例のようにsecurecommsポリシーをoffに切り替えます。
```
ob> cdp security
ob> setp securecomms off
```

関連項目:

ポリシーの設定方法は、『Oracle Secure Backup管理者ガイド』を参照してください。

9.8 obcmによる証明書の管理

この項では、obcmユーティリティの使用方法について説明します。このユーティリティを使用すると、いずれかの証明書モードでの証明書の更新、証明書チェーンのインポート、証明書チェーンのエクスポート、および証明書リクエストのエクスポートを実行できます。

ホストを自動証明書プロビジョニング・モードではなく手動でドメインに追加する場合は、obcmを使用する必要があります。この場合、認証局(CA)はネットワーク上で署名付き証明書チェーンをホストに発行しないため、署名付き証明書チェーンを管理サーバーからエクスポートし、その証明書チェーンを新たに構成されるホストに移し、ホストのウォレットにインポートする必要があります。

/usr/etc/ob/wallet(UNIXおよびLinux)
C:\Program Files\Oracle\Backup\db\wallet(Windows)

obcmユーティリティは、常に前述の場所にあるウォレットにアクセスします。デフォルトの場所を無効にすることはできません。

エラーが発生した場合、obcm verifycommコマンドを使用してドメイン内の接続の問題を診断し、obcmログ・ファイルの場所が記述されていることを確認してください。

この項の内容は次のとおりです。

9.8.1 自動証明書プロビジョニング・モードでの証明書の更新

この項では、自動証明書プロビジョニング・モードでドメインの認証局を更新する手順を示します。

Oracle Secure Backup 12.1.0.2以降は、obcmを使用して自動証明書プロビジョニング・モードでドメイン内の証明書を更新できます。

Oracle Secure Backup 12.1.0.1および10.4バージョンにおいて自動証明書プロビジョニング・モードで証明書を更新する方法の詳細は、「Oracle Secure Backupの旧バージョンでの、自動証明書プロビジョニング・モードでの証明書の更新」を参照してください

自動証明書プロビジョニング・モードでドメインの認証局を更新するには、管理ホストで次の手順を実行します。

次のコマンドを入力して、バックアップ・ドメインを一時的に無効にします。
```
obtool ctldameon --command suspend
```
次のコマンドを入力して、ドメイン内のすべてのアクティブ・ジョブをリストします。
```
obtool lsjobs --active
```
すべてのアクティブ・ジョブが完了したら、次のコマンドを入力して署名付き証明書を再生成します。
```
obcm recertifydomain
```
次のコマンドを入力して、既存の未認証ホストを識別します。
```
obtool lshost --unauthenticated
```
「ホストの手動認証」にリストされている手順を実行して、未認証ホストを手動で更新します。
手順4を繰り返して、ドメイン内のすべてのホストが認証されていることを確認します。
次のコマンドを入力して、ドメイン内のすべてのホストに正常にアクセスできることを確認します。
```
obtool --pinghost all
```
すべてのバックアップ操作を再開します。
```
obtool ctldaemon --command resume
```

9.8.2 手動証明書プロビジョニング・モードでの証明書の更新

この項では、OSB 12.1.0.2以降で、手動証明書プロビジョニング・モードで証明書を更新する手順を示します。

Oracle Secure Backup 12.1.0.2以降では、obcmを使用して手動証明書プロビジョニング・モードでドメイン内の証明書を更新できます

Oracle Secure Backup 12.1.0.1および10.4バージョンにおいて手動証明書プロビジョニング・モードで認証局を更新する方法の詳細は、「Oracle Secure Backupの旧バージョンでの、手動証明書プロビジョニング・モードでの証明書の更新」を参照してください

手動証明書プロビジョニング・モードでドメインの認証局を更新するには、管理ホストで次の手順を実行します。

次のコマンドを入力して、ドメインを一時的に無効にします。
```
obtool ctldaemon --command suspend
```
次のコマンドを入力して、ドメイン内のすべてのアクティブ・ジョブをリストします。
```
obtool lsjobs --active
```
すべてのアクティブ・ジョブが完了したら、次のコマンドを入力して署名付き証明書を再生成します。
```
obcm recertifydomain
```
次のコマンドを入力して、各非管理ホストの署名付き証明書をエクスポートします。
```
obcm export --certificate --file non-admistrative hostname.cert --host non-administrative hostname
```
non-administrative host.certファイルに非管理ホストがアクセスできるようにします。その後、次のコマンドを使用して、各未認証ホストで署名付き証明書をインポートします。
```
obtool import --file non-administrative host.cert
```
更新された証明書を選択するように、非管理ホストを再起動します。
次のコマンドを実行して、ドメイン内のすべてのホストが認証されたことを確認します。
```
obtool lshost --unauthenticated
```
ドメイン内のすべてのホストにアクセスできることを確認します。
```
obtool pinghost --all
```
次のコマンドを入力して、すべてのバックアップ操作を再開します。
```
obtool ctldaemon --command resume
```

9.8.3 Oracle Secure Backupの旧バージョンでの、自動証明書プロビジョニング・モードでの証明書の更新

この項では、OSB 10.4.xおよび12.1.0.1で、自動証明書プロビジョニング・モードで証明書を更新する手順を示します。

この項では、Oracle Secure Backup 12.1.0.1および10.4バージョンで自動証明書プロビジョニング・モードで認証局を更新する手順を示します。

自動証明書プロビジョニング・モードでドメインの署名付き証明書を再生成するには、次の手順を実行します。

最新バージョンのobcmをダウンロードします。
obcmの詳細は、『Oracle Secure Backupリファレンス』を参照してください
次のコマンドを実行して、ドメインを一時的に無効にします。
```
obtool ctldaemon --command suspend
```
次のコマンドを実行して、ドメイン内のすべてのアクティブ・ジョブをリストします。
```
obtool lsjobs --active
```
すべてのアクティブ・ジョブが完了したら、各非管理ホストで期限切れの署名付き証明書を削除します。
```
obcm decertify
```
管理ホストで、rootユーザーとしてログインします。
次のコマンドを入力して、署名付き証明書を再生成します。
```
obcm recertifydomain --nocomm --expire months
```
observicedデーモンを停止してから再起動します。
関連項目:
observicedスクリプトの詳細は、『Oracle Secure Backupリファレンス』を参照してください
次のコマンドを実行して、各非管理ホストの署名付き証明書を再生成します。
```
obtool updatehost --recertify non-administrative hostname
```
各非管理ホストで手順7を繰り返します。
すべてのホスト操作を再開します。
```
obtool ctldaemon --command resume
```
すべてのホストにアクセスできることを確認します。
```
obtool pinghost --all
```

9.8.4 Oracle Secure Backupの旧バージョンでの手動プロビジョニング・モードでの証明書の更新

この項では、Oracle Secure Backup 12.1.0.1および10.4バージョンで、手動プロビジョニング・モードで認証局を更新する手順を示します。

この項では、Oracle Secure Backup 12.1.0.1および10.4バージョンで手動証明書プロビジョニング・モードで認証局を更新する手順を示します。

手動証明書プロビジョニング・モードでドメインの署名付き証明書を再生成するには、次の手順を実行します。

最新バージョンのobcmをダウンロードします。
obcmの詳細は、『Oracle Secure Backupリファレンス』を参照してください
次のコマンドを実行して、ドメインを一時的に無効にします。
```
obtool ctldaemon --command suspend
```
次のコマンドを実行して、ドメイン内のすべてのアクティブ・ジョブをリストします。
```
obtool lsjobs --active
```
すべてのアクティブ・ジョブが完了したら、各非管理ホストで期限切れの署名付き証明書を削除します。
```
obcm recertify
```
各非管理ホストで次のスクリプトを実行して、observicedデーモンを停止してから起動します。
```
/etc/init.d/obcerviced stop
/etc/init.d/observiced start
```
管理ホストで、rootユーザーとしてログインします。
次のコマンドを入力して、署名付き証明書を再生成します。
```
obcm recertifydomain --nocomm --expire months
```
observicedデーモンを停止してから再起動します。
関連項目:
observicedスクリプトの詳細は、『Oracle Secure Backupリファレンス』を参照してください
次のコマンドを実行して、各非管理ホストの署名付き証明書を再生成します。
```
obtool updatehost --recertify non-administrative hostname
```
obcm exportおよびobcm importコマンドを使用して証明書を割り当てます。
証明書のエクスポートおよびインポートの詳細はそれぞれ、「署名付き証明書のエクスポート」および「署名付き証明書のインポート」を参照してください。
すべてのホスト操作を再開します。
```
obtool ctldaemon --command resume
```
すべてのホストにアクセスできることを確認します。
```
obtool pinghost --all
```

9.8.5 証明書の更新後のホストの手動認証

この項では、未認証の非管理ホストを認証する方法について説明します。

obcm recertifydomainコマンドを実行して、ホストの証明書が更新されていることを確認します。

未認証の非管理ホストを手動で認証するには、次の手順を実行します。

未認証ホストで、次のコマンドを使用して期限切れのすべての署名付き証明書を削除します。
```
obcm decertify
```
管理ホストで、次のコマンドを使用して署名付き証明書を再生成します。
```
obtool updatehost --recertify uncertified hostname
```
obcm exportおよびobcm importコマンドを使用して証明書を割り当てます。
obcmを使用した証明書のエクスポートおよびインポートの詳細はそれぞれ、「署名付き証明書のエクスポート」および「署名付き証明書のインポート」を参照してください。

9.8.6 署名付き証明書のエクスポート

管理サーバーでobcmを使用して、新たに構成されたホストの署名付き証明書チェーンをエクスポートできます。

署名付き証明書をエクスポートする手順:

管理サーバーにrootとしてログインします。
次のコマンドを入力します。hostnameは、証明書をリクエストしているホストの名前、certificate_fileは、エクスポートされたリクエストのファイル名です。
```
obcm export --certificate --file certificate_file --host hostname
```
たとえば、次のコマンドでは、ホストbrhost2に対する署名付き証明書チェーンが/tmp/brhost2_cert.fファイルにエクスポートされます。
```
obcm export --certificate --file /tmp/brhost2_cert.f --host brhost2
```

9.8.7 署名付き証明書チェーンのインポート

ホストでobcmを使用して、ホストのウォレットに署名付き証明書チェーンをインポートできます。

ホストのウォレットに署名付き証明書チェーンをインポートする手順:

ウォレットに証明書が含まれているホストにログインします。
署名付き証明書チェーンを、ファイル・システム上の一時的な場所にコピーします。
次のコマンドを入力します(signed_certificate_fileは証明書のファイル名)。
```
obcm import --file signed_certificate_file
```
ホストにはOracle Secure Backupウォレットが1つしか存在しないため、--hostオプションを指定する必要はありません。たとえば、次の例では、/tmp/brhost2_cert.fから証明書がインポートされます。
```
obcm import --file /tmp/brhost2_cert.f
```
obcmユーティリティでは、インポートされる証明書チェーンがウォレットの証明書リクエストに対応しない場合、エラー・メッセージを発行します。
オペレーティング・システム上の一時的な場所から証明書ファイルを削除します。たとえば、次のようになります。
```
rm /tmp/brhost2_cert.f
```