NetBackup ™ セキュリティおよび暗号化ガイド
- NetBackup での安全な通信 (最初にお読みください)
- 通信エラーのシナリオ
- NetBackup セキュリティの強化
- セキュリティの配置モデル
- NetBackup 操作の監査
- 第 I 部 個人情報とアクセスの管理
- 個人情報とアクセスの管理について
- AD ドメインと LDAP ドメイン
- アクセスキー
- API キー
- auth.conf ファイル
- 役割に基づくアクセス制御
- スマートカードまたはデジタル証明書
- シングルサインオン (SSO)
- 拡張監査
- NetBackup アクセス制御セキュリティ (NBAC)
- NetBackup アクセス制御 (NBAC) の構成
- マスターおよびメディアサーバーの[アクセス制御 (Access Control)]ホストプロパティの構成
- クライアントの[アクセス制御 (Access Control)]ホストプロパティダイアログボックス
- アクセス管理のトラブルシューティング
- NetBackup へアクセス可能なユーザーの決定について
- NetBackup ユーザーグループの特定のユーザー権限の表示
- 第 II 部 移動中のデータの暗号化
- NetBackup CA および NetBackup 証明書
- セキュリティ管理ユーティリティについて
- ホスト管理について
- 共有マッピングとクラスタマッピングの追加
- 証明書の自動再発行の許可または禁止
- グローバルセキュリティ設定について
- ホスト名ベースの証明書について
- ホスト ID ベースの証明書について
- 証明書管理ユーティリティを使ったホスト ID ベースの証明書の発行と配備
- NetBackup 証明書の配備のセキュリティレベルについて
- マスターサーバー (CA) との信頼の設定
- ホスト ID ベースの証明書の再発行について
- ホスト ID ベースの証明書のトークン管理について
- ホスト ID ベースの証明書失効リストについて
- ホスト ID ベースの証明書の無効化について
- クラスタ化されたセットアップでのホスト ID ベースの証明書配備
- クラスタ化された NetBackup ホストでのホスト ID ベースの証明書の配備について
- NetBackup CA の移行
- 移動中のデータの暗号化 (DTE) の構成
- 外部 CA と外部証明書
- NetBackup での外部 CA のサポートについて
- 外部 CA が署名した証明書の構成オプション
- NetBackup サーバーとクライアントの ECA_CERT_PATH
- 外部 CA の証明書失効リストについて
- 証明書の登録について
- NetBackup Web サーバーで外部証明書を使用するための構成
- クラスタマスターサーバー用の外部証明書の構成について
- キーと証明書の再生成
- NetBackup CA および NetBackup 証明書
- 第 III 部 格納データの暗号化
- 格納データの暗号化セキュリティ
- NetBackup クライアントの暗号化について
- クライアントでの標準暗号化の構成
- クライアントでのレガシー暗号化の構成
- NetBackup Key Management Service
- FIPS 対応 KMS について
- KMS のインストール
- KMS の構成
- キーグループとキーレコードについて
- キーレコードの状態の概要
- KMS と連携するための NetBackup の構成
- 暗号化への KMS の使用について
- KMS データベースの要素
- コマンドラインインターフェース (CLI) コマンド
- KMS のトラブルシューティング
- 外部のキーマネージメントサービス
- 格納データの暗号化セキュリティ
- NetBackup での FIPS 準拠
- NetBackup Web サービスアカウント
- 特権のないユーザー (サービスユーザー) アカウントでの NetBackup サービスの実行
- NetBackup でのデータの変更不可と削除不可
- バックアップの異常の検出
- マルウェアの検出
- マルウェアの検出について
すべてに NBAC を使用する複数のデータセンター
すべてに NBAC を使用する複数のデータセンターは、中規模から大規模な (50 を超える) ホストのグループとして定義されます。これらのホストは、地理的に 2 か所以上の地域にまたがり、WAN (ワイドエリアネットワーク) で接続することができます。この例では、データセンターの 1 つはロンドンにあり、もう 1 つは東京にあります。両方のデータセンターは、専用の WAN 接続を介して接続されています。
この環境は、マスターサーバーとメディアサーバーで NBAC を使用する複数のデータセンターに非常に類似しています。主な違いは、NetBackup 環境に参加するすべてのホストがクレデンシャルを使って確実に識別され、root 以外の管理者が構成可能なアクセスレベルに基づいて NetBackup クライアントを管理できることです。ユーザー識別情報は、Windows の Active Directory または UNIX の NIS などのグローバルリポジトリに存在する場合があります。また、識別情報は、認証ブローカーをサポートするホスト上のローカルのリポジトリ (UNIX のパスワード、Windows のローカルドメイン) に存在する場合もあります。
すべてに NBAC を使用する複数のデータセンターには、次の特徴があります。
NetBackup は WAN を介して地理的に 2 か所以上の地域にまたがる
マスターサーバーとメディアサーバーで NBAC を使用する複数のデータセンターの場合の特徴と類似している (クライアントの root ユーザーまたは管理者についての項目は除く)。この構成では、クライアントとサーバーの root 以外の管理者による管理が許可されています。
クライアントシステムでは、ローカルバックアップとリストアを行うために root 以外または管理者以外のユーザーが設定される場合がある (デフォルト設定)
この環境では、NetBackup に含まれるすべてのホストの信頼できる識別が容易である
すべてのホストは NetBackup バージョン 7.7 以降である必要がある
図: すべてに NBAC を使用する複数のデータセンター に、すべてに NBAC を使用する複数のデータセンターの例を示します。
次の表に、すべてに NBAC を実装した複数のデータセンターで使われる NetBackup の構成要素を示します。
表: すべてに NBAC を実装した複数のデータセンターにおける NetBackup の構成要素
構成要素 |
説明 |
---|---|
ロンドンのデータセンター |
ロンドンのデータセンターには、ルートブローカー、認証ブローカー 1、GUI 1、認可エンジン、マスターサーバー、メディアサーバー 1、クライアント 1、5 が含まれます。また、クライアント 1、5、10 の暗号化されていないデータテープが含まれます。ロンドンのデータセンターは、専用の WAN 接続を介して東京のデータセンターに接続されます。 |
東京のデータセンター |
東京のデータセンターには、認証ブローカー 2、GUI 2、メディアサーバー 2、クライアント 10、11 が含まれます。また、クライアント 10、11 の暗号化されていないデータテープが含まれます。東京のデータセンターは、専用の WAN 接続を介してロンドンのデータセンターに接続されます。 |
WAN (ワイドエリアネットワーク) |
東京のデータセンターにロンドンのデータセンターを接続する専用の WAN リンクです。WAN によって、ルートブローカー/認証ブローカー 1 と認証ブローカー 2 が接続されます。さらに、ルートブローカー/認証ブローカー 1 と GUI 2/メディアサーバー 2 も接続されます。また、WAN によって、認可エンジンはメディアサーバー 2 に接続されます。マスターサーバーは GUI 2、メディアサーバー 2、クライアント 10、11 に接続されます。メディアサーバー 1 はクライアント 10 に接続されます。 |
マスターサーバー |
マスターサーバーは、ロンドンのデータセンターにあり、ルートブローカー/認証ブローカー 1 と通信します。また、GUI 1、認可エンジン、メディアサーバー 1 とも通信します。マスターサーバーは、東京の GUI 2、メディアサーバー 2、クライアント 10、11 と通信します。 |
メディアサーバー |
この複数のデータセンターの例では、2 つのメディアサーバーがあります。メディアサーバー 1 はロンドンのデータセンターにあり、メディアサーバー 2 は東京のデータセンターにあります。ロンドンのメディアサーバー 1 は、マスターサーバー、ルートブローカー/認証ブローカー 1、認可エンジン、クライアント 1、5、10 と通信します。メディアサーバー 1 は、クライアント 1、5、10 の暗号化されていないデータをテープに書き込みます。 東京のメディアサーバー 2 は、WAN を介してロンドンのマスターサーバー、ルートブローカー/認証ブローカー 1 および認可エンジンと通信します。また、東京の GUI 2、クライアント 10、11 とも通信します。メディアサーバー 2 は、クライアント 10、11 の暗号化されていないデータをテープに書き込みます。 |
GUI |
この複数のデータセンターの例では、2 つの GUI があります。GUI 1 はロンドン、GUI 2 は東京にあります。これらのリモート管理コンソール GUI は、認証ブローカーからクレデンシャルを受信します。GUI は受け取ったクレデンシャルを使用して、メディアサーバーおよびマスターサーバーの機能へのアクセス権を取得します。ロンドンの GUI 1 は、認証ブローカー 1 からクレデンシャルを受信します。GUI 1 には、マスターサーバーおよびメディアサーバー 1、2 の機能へのアクセス権が付与されます。東京の GUI 2 は、認証ブローカー 2 からクレデンシャルを受信します。GUI 2 には、マスターサーバーおよびメディアサーバー 1、2 の機能へのアクセス権が付与されます。 |
ルートブローカー |
複数のデータセンターのインストールには、ルートブローカーが 1 つのみ必要です。ルートブローカーは、認証ブローカーと組み合わせて使用することもできます。この例では、ルートブローカーと認証ブローカーは同じコンポーネントとして示され、ロンドンのデータセンターに配置されています。ロンドンにあるルートブローカーは、ロンドンの認証ブローカー 1 と、東京の認証ブローカー 2 を認証します。ルートブローカーはクライアントを認証しません。 |
認証ブローカー |
データセンターのインストールでは、複数の認証ブローカーを配置できます。認証ブローカーをルートブローカーと組み合わせて使用することもできます。このデータセンターのインストールでは、2 つの認証ブローカーがあります。認証ブローカーは、マスターサーバー、メディアサーバー、GUI およびクライアントに対してそれぞれクレデンシャルを設定し、認証します。認証ブローカーは、コマンドプロンプトを使用するユーザーも認証します。ロンドンの認証ブローカー 1 は、マスターサーバー、メディアサーバー 1、GUI 1、クライアント 1、5 のクレデンシャルを認証します。東京とロンドンにあるすべての NetBackup サーバーとクライアントは、ロンドンの認証ブローカー 1 で認証が行われます。GUI 1 はロンドンの認証ブローカー 1 で認証が行われます。GUI 2 は東京の認証ブローカー 2 で認証が行われます。 |
認可エンジン |
データセンターのインストールには、認可エンジンが 1 つのみ必要です。認可エンジンは、マスターサーバーおよびメディアサーバーと通信して、認証されたユーザーの権限を決定します。これらの権限によって、ユーザーが利用できる機能が決まります。また、認可エンジンには、ユーザーグループおよび権限が格納されます。認可エンジンはロンドンに存在し、マスターサーバー、メディアサーバー 1 と通信します。また、認可エンジンは、WAN を介して通信を行い、東京のメディアサーバー 2 へのアクセス権を認可します。 メモ: 認可エンジンは、デーモンプロセスとしてマスターサーバーに存在します。この図では、例に示すために個別のイメージとして示しています。 |
テープ |
暗号化されていないデータテープは、ロンドンと東京の両方のデータセンターで作成されます。ロンドンでは、クライアント 1、5、10 用に、暗号化されていないテープが書き込まれ、ロンドンのデータセンターのオンサイトに格納されます。東京では、クライアント 10、11 用に、暗号化されていないテープが書き込まれ、東京のデータセンターのオンサイトに格納されます。クライアント 10 は東京に存在し、東京でバックアップされますが、ロンドンでもバックアップされることに注意してください。 |
クライアント |
クライアントは、ロンドンと東京の両方のデータセンターに配置されています。ロンドンの場合、クライアント 1 は標準的な NetBackup 形式です。クライアント 5 は、DMZ に配置されている Web サーバー形式です。いずれの形式のクライアントもマスターサーバーによって管理され、クライアントのデータはメディアサーバー 1 によってテープにバックアップされます。クライアント 5 は、NetBackup ポートのみを使用して内部ファイアウォールを通過し、NetBackup と通信します。また、クライアント 5 は HTTP ポートのみを使用して外部ファイアウォールも通過し、インターネットからの接続を受信します。 東京の場合、クライアント 10 は標準的な NetBackup 形式です。クライアント 11 は、DMZ に配置されている Web サーバー形式です。いずれの形式のクライアントもマスターサーバーによって管理され、クライアントのデータはメディアサーバー 2 によってテープにバックアップされます。クライアント 11 は、NetBackup ポートのみを使用して内部ファイアウォールを通過し、NetBackup と通信します。また、クライアント 11 は HTTP ポートのみを使用して外部ファイアウォールも通過し、インターネットからの接続を受信します。 |
内部ファイアウォール |
この複数のデータセンターの例では、2 つの内部ファイアウォールを設定できます。1 つはロンドン、もう 1 つは東京にあります。ロンドンの場合、NetBackup は、内部ファイアウォールを通過して DMZ 内の Web サーバークライアント 5 にアクセスできます。東京の場合、NetBackup は、内部ファイアウォールを通過して DMZ 内の Web サーバークライアント 11 にアクセスできます。選択された NetBackup ポートおよび他のアプリケーションポート (可能な場合) のみが、内部ファイアウォールを通過して DMZ とのデータ通信を行うことができます。外部ファイアウォールで開かれている HTTP ポートは、内部ファイアウォールを通過できません。 |
非武装地帯 (DMZ) |
この複数のデータセンターの例では、2 つの DMZ を設定できます。1 つはロンドン、もう 1 つは東京にあります。ロンドンでは、DMZ は、内部ファイアウォールと外部ファイアウォールとの間に存在する Web サーバークライアント 5 に対して、「安全な」操作領域を提供します。DMZ 内の Web サーバークライアント 5 は、指定の NetBackup ポートを使用して内部ファイアウォールを通過し、NetBackup と通信できます。また、Web サーバークライアント 5 は、HTTP ポートのみを使用して外部ファイアウォールも通過し、インターネットに接続することができます。 東京では、DMZ は、内部ファイアウォールと外部ファイアウォールとの間に存在する Web サーバークライアント 11 に対して、「安全な」操作領域を提供します。DMZ 内の Web サーバークライアント 11 は、指定の NetBackup ポートを使用して内部ファイアウォールを通過し、NetBackup と通信できます。また、Web サーバークライアント 11 は、HTTP ポートのみを使用して外部ファイアウォールも通過し、インターネットに接続することができます。 |
外部ファイアウォール |
この複数のデータセンターの例では、2 つの外部ファイアウォールを設定できます。1 つはロンドン、もう 1 つは東京にあります。ロンドンでは、外部ユーザーは、HTTP ポートを経由して外部ファイアウォールを通過し、インターネットから DMZ 内の Web サーバークライアント 5 にアクセスできます。NetBackup ポートは Web サーバークライアント 5 に対して開かれており、内部ファイアウォールを通過して NetBackup と通信できます。NetBackup ポートは、外部ファイアウォールを通過してインターネットに接続することはできません。Web サーバークライアント 5 の HTTP ポートのみが外部ファイアウォールを通過してインターネットに接続できます。 東京では、外部ユーザーは、HTTP ポートを経由して外部ファイアウォールを通過し、インターネットから DMZ 内の Web サーバークライアント 11 にアクセスできます。NetBackup ポートは Web サーバークライアント 11 に対して開かれており、内部ファイアウォールを通過して NetBackup と通信できます。NetBackup ポートは、外部ファイアウォールを通過してインターネットに接続することはできません。Web サーバークライアント 11 の HTTP ポートのみが外部ファイアウォールを通過してインターネットに接続できます。 |
インターネット |
インターネットは 1 つしかありませんが、この複数のデータセンターの例では 2 つのインターネット接続があります。1 つはロンドン、もう 1 つは東京にあります。インターネットは、相互に接続されたコンピュータネットワークの集まりで、銅線、ファイバー光ケーブル、および無線接続によってリンクされています。ロンドンでは、Web サーバークライアント 5 は、HTTP ポートを使用して外部ファイアウォールを通過し、インターネットでの通信を行うことができます。東京では、Web サーバークライアント 11 は、HTTP ポートを使用して外部ファイアウォールを通過し、インターネットでの通信を行うことができます。 |