第 4 章 アクセスとセキュリティーの管理

この章では、アクセスとセキュリティーの管理方法について説明します。この章は、次の節で構成されます。

• 「Sun Cluster Geographic Edition ソフトウェアと RBAC」

• 「セキュリティー証明書によるセキュリティー保護されたクラスタ通信の構成」

• 「IPsec によるセキュリティー保護されたクラスタ通信の構成」

Sun Cluster Geographic Edition ソフトウェアと RBAC

この節では、Sun Cluster Geographic Edition ソフトウェアにおける役割に基づくアクセス制御 (RBAC) について説明します。ここでは、次の内容を説明します。

• RBAC の設定と使用

• RBAC 権利プロファイル

• ユーザーの RBAC プロパティーの変更

RBAC の設定と使用

Sun Cluster Geographic Edition ソフトウェアの RBAC プロファイルは、Sun Cluster ソフトウェアで使用される RBAC 権利プロファイルに基づいています。Sun Cluster での RBAC の設定および使用に関する一般的な情報は、『Sun Cluster のシステム管理 (Solaris OS 版)』の第 2 章「Sun Cluster と RBAC」を参照してください。

Sun Cluster Geographic Edition ソフトウェアは、/etc/security ディレクトリ内の適切なファイルに、次に示す新しい RBAC エンティティーを追加します。

• RBAC 認証名、auth_attr

• RBAC 実行プロファイル、prof_attr

• RBAC 実行属性、exec_attr

auth_attr および prof_attr データベースのデフォルトの検索順序は、/etc/nsswitch.conf ファイル内の files nis で定義されています。使用している環境で検索順序をカスタマイズしている場合は、検索リスト内に files が指定されていることを確認してください。システムは、files を使用して、Sun Cluster Geographic Edition によって定義された RBAC エンティティーを検索します。

RBAC 権利プロファイル

Sun Cluster Geographic Edition の CLI および GUI では、RBAC 権利を使用して、各種操作へのエンドユーザーアクセスを制御します。これらの権利の一般的な規定については、次の表を参照してください。

ユーザーの RBAC プロパティーの変更

ユーザーの RBAC 権利を変更するには、root ユーザーとしてログインするか、Primary Administrator 権利プロファイルを割り当てられた役割を引き受ける必要があります。

たとえば、ユーザー admin に Geo Management RBAC プロファイルを割り当てるには、次のようにします。

# usermod -P "Geo Management" admin
# profiles admin
Geo Management
Basic Solaris User
#

ユーザーの RBAC プロパティーを変更する方法については、『Sun Cluster のシステム管理 (Solaris OS 版)』の第 2 章「Sun Cluster と RBAC」を参照してください。

セキュリティー証明書によるセキュリティー保護されたクラスタ通信の構成

パートナークラスタとの間でセキュリティー保護された通信を行うには、Sun Cluster Geographic Edition ソフトウェアを構成する必要があります。この構成は、相互に行う必要があります。つまり、クラスタ cluster-paris はそのパートナークラスタ cluster-newyork を信頼し、クラスタ cluster-newyork はそのパートナークラスタ cluster-paris を信頼するように構成する必要があります。

GUI を使用して Sun Cluster Geographic Edition ソフトウェアの管理を行う場合は、両方のパートナークラスタのすべてのノードで、同じルート (root) パスワードを使用する必要があります。

パートナークラスタのセキュリティー証明書の設定方法については、『Sun Cluster Geographic Edition のインストール』の「セキュリティーの構成」を参照してください。

クラスタ構成例については、図 2–1 を参照してください。

IPsec によるセキュリティー保護されたクラスタ通信の構成

IP Security Architecture (IPsec) を使用して、パートナークラスタ間にセキュリティー保護された通信を構成できます。IPsec では、IP を使用して通信しているマシン間で、セキュリティー保護されたデータグラム認証、実際のデータ暗号化、またはこの両方を許可または要求するポリシーを設定できます。次のようなクラスタ通信では、IPsec を使用することを検討してください。

• セキュリティー保護された Sun StorEdge Availability Suite 3.2.1 通信 (Sun StorEdge Availability Suite 3.2.1 を使用してデータ複製を行う場合)

• セキュリティー保護された TCP/UDP ハートビート通信

Sun Cluster ソフトウェアと Sun Cluster Geographic Edition ソフトウェアは、手動鍵だけを使用して IPsec をサポートします。鍵は、サーバーとクライアント IP アドレスの組み合わせごとに、クラスタノード上に手動で格納する必要があります。鍵は、各クライアント上にも手動で格納する必要があります。

IPsec 構成パラメタの詳細は、『Solaris のシステム管理 (IP サービス)』を参照してください。

セキュリティー保護されたクラスタ通信用に IPsec を構成する方法

Sun Cluster Geographic Edition インフラストラクチャーでは、論理ホストのホスト名はクラスタ名に同じです。論理ホスト名は、特殊な高可用性 (HA) リソースです。クラスタ構成によっては、Sun Cluster のさまざまなコンポーネントに多数の IP アドレスを設定する必要があります。

各パートナークラスタ上で、物理ノードと論理ホスト名アドレス間のインバウンドパケットとアウトバウンドパケットを交換するための暗号化と承認の設定を行う必要があります。これらのアドレス上の IPsec 構成パラメタの値は、パートナークラスタ間で一致しなければいけません。

IPsec は次の 2 つの構成ファイルを使用します。

• IPsec ポリシーファイル /etc/inet/ipsecinit.conf。ハートビートの認証と暗号化をサポートする指示規則を含みます。このファイルの内容は、パートナー関係にある 2 つのクラスタ間で異なります。

• IPsec 鍵ファイル /etc/init/secret/ipseckeys。特定の認証および暗号化アルゴリズムのための鍵ファイルを含みます。このファイルの内容は、パートナー関係にある 2 つのクラスタ間で一致します。

次の手順では、クラスタ例 cluster-newyork との間で IPsecによるセキュリティー保護された通信が行われるようにクラスタ例 cluster-paris を構成します。両クラスタとも Solaris OS 9 リリースを使用していると想定します。この手順では、cluster-paris 上のローカルの論理ホスト名を lh-paris-1、リモートの論理ホスト名を lh-newyork-1 と想定しています。インバウンドメッセージは lh-paris-1、アウトバウンドメッセージは lh-newyork-1 に送信されます。

cluster-paris の各ノードで、次の手順を実行します。

手順

1. 主クラスタ phys-paris-1 の最初のノードに、スーパーユーザーとしてログインします。

   どのノードが phys-paris-1 であるかについては、「Sun Cluster Geographic Edition クラスタ構成の例」を参照してください。

2. IPsec ポリシーファイル内に、ローカルアドレスとリモートアドレスのエントリを設定します。

   ポリシーファイルは /etc/inet/ipsecinit.conf にあります。このファイルのアクセス権は 644 にするべきです。このファイルについては、ipsecconf(1M) のマニュアルページを参照してください。

   Sun Cluster Geographic Edition ソフトウェアでサポートされる名前と値については、付録 B 「Sun Cluster Geographic Edition エンティティーに使用できる名前と値」を参照してください。

   1. 通信ポリシーを構成します。

      tcp_udp プラグインのデフォルトポートは 2084 です。これは /etc/opt/SUNWcacao/modules/com.sun.cluster.agent.geocontrol.xml ファイルに指定されています。

      特定の承認または暗号化アルゴリズムを優先する必要がない場合は、次のコマンドを使用してポリシーを構成します。

      # {raddr lh-newyork-1 rport 2084} ipsec {auth_algs any encr_algs any \ sa shared} {laddr lh-paris-1 lport 2084} ipsec {auth_algs any encr_algs \ any sa shared}

      二次クラスタ cluster-newyork 上で通信ポリシーを構成するときは、ポリシーの設定を逆にする必要があります。

      # {laddr lh-newyork-1 lport 2084} ipsec {auth_algs any encr_algs \ any sa shared} {raddr lh-paris-1 rport 2084} ipsec {auth_algs any encr_algs \ any sa shared}

   2. ノードを再起動するか、次のコマンドを実行して、ポリシーを追加します。

      # ipsecconf -a /etc/inet/ipsecinit.conf

3. インバウンド通信とアウトバウンド通信用に、暗号化鍵と認証鍵を設定します。

   通信ファイルは /etc/init/secret/ipseckeys にあります。このファイルのアクセス権は 600 にするべきです。

   次のコマンドを実行して、鍵を追加します。

   # ipseckey -f /etc/init/secret/ipseckeys

   鍵は、一般に次のような形式で入力します。

   # inbound to cluster-paris add esp spi <paris-encr-spi> dst lh-paris-1 encr_alg <paris-encr-algorithm> \ encrkey <paris-encrkey-value> add ah spi <newyork-auth-spi> dst lh-paris-1 auth_alg <paris-auth-algorith> \ authkey <paris-authkey-value> # outbound to cluster-newyork add esp spi <newyork-encr-spi> dst lh-newyork-1 encr_alg \ <newyork-encr-algorithm> encrkey <newyork-encrkey-value> add ah spi <newyork-auth-spi> dst lh-newyork-1 auth_alg \ <newyork-auth-algorithm> authkey <newyork-authkey-value>

   通信ファイルについては、ipsecconf(1M) のマニュアルページを参照してください。