eDirectoryは、Amazon VPC内のプライベートサブネットにのみデプロイされる必要があります。図 4-1は、後続のセクションで説明されているデプロイメントのサンプルを示しています。
図 5-1 AWS EC2上でのeDirectoryのデプロイメント
メモ:
SSHプロキシは、管理者がSSHを使用して接続し、SSHエージェント転送を使用してプライベートサブネット内の他のインスタンスに接続する、パブリックサブネット内の要塞ホストです。
eDirectoryにアクセスする必要があるアプリケーションは、プライベートサブネットにデプロイする必要があります。これらのアプリケーションにインターネットからアクセスする必要がある場合は、パブリックサブネット内にAWS EC2ロードバランサーを設定して、アクセスを可能にします。詳細については、「Application Load Balancerの作成」を参照してください。
デプロイメント手順は、次のステップで構成されます。
このセクションでは、eDirectoryで使用するためにAWS VPCを設定する一般的な手順について概説します。詳細については、「Amazon Elastic Compute Cloudドキュメント」を参照してください。
次の手順を実行し、AWS VPCサービスを作成します。
AWS管理コンソールにログインします。
次のサービスを作成します。
|
サービス |
説明 |
|---|---|
|
VPC |
Amazon VPCコンソールを使用して、VPCを作成することができます。VPCの作成方法の詳細については、「VPCの作成」を参照してください。 VPCの概要に関する詳細については、「Amazon Virtual Private Cloud ドキュメント」を参照してください。 |
|
重要:[VPCウィザードの起動]を使用してVPCを作成すると、VPC用に2つのサブネット、インターネットゲートウェイ、およびルートテーブルとNATゲートウェイが作成されます。これらの項目を表示または編集するには、次の手順に従います。 |
|
|
サブネット |
VPC作成の一環として、2つのサブネットが作成されます。パブリックおよびプライベートサブネットです。eDirectoryは、プライベートサブネットにデプロイする必要があります。図 4-1に示したとおり、eDirectoryにアクセスするすべてのアプリケーションは、同じプライベートサブネットにデプロイする必要があります。プライベートサブネット内のインスタンスへのSSHアクセスは、パブリックサブネット内のSSHプロキシを経由して行う必要があります。詳細については、「VPCとサブネット」を参照してください。 |
|
インターネットゲートウェイ |
インターネットゲートウェイは、図 4-1に示したとおり、SSHプロキシへのSSH接続を可能にするために必要です。VPCを使用してインターネットゲートウェイを作成および接続する方法の詳細については、「インターネットゲートウェイ」を参照してください。 |
|
ルートテーブル |
ルートテーブルを作成する方法の詳細については、「ルートテーブル」を参照してください。 |
|
NATゲートウェイ |
オペレーティングシステムの更新をダウンロードするためのプライベートサブネット内のインスタンスには、NATゲートウェイが必要です。NATゲートウェイの作成に関する詳細については、「NATゲートウェイ」を参照してください。 |
|
Elastic IPアドレス |
Elastic IPアドレスは、SSHプロキシおよびNATゲートウェイを実行するインスタンスに割り当てる必要のあるパブリックなスタティックIPアドレスです。Elastic IPアドレスを作成する方法の詳細については、「Elastic IPアドレスの操作」を参照してください。 |
ネットワークアクセス制御リスト(ACL)は、1つまたは複数のサブネットに対するトラフィックを制御するファイアウォールとして機能する、VPC用のセキュリティのオプション層です。詳細については、「ネットワークACL」を参照してください。
このセクションでは、プライベートサブネットにネットワークACLを作成するためのルールについて概説します。プライベートサブネットのネットワークACLに対して、次のルールを設定してください。
インバウンドルール:
表 5-1
|
ルール |
タイプ |
ポート範囲 |
ソース |
アクション |
説明 |
|---|---|---|---|---|---|
|
10 |
SSH |
TCP 22 |
<SSH Proxy IP Address>/32 |
許可 |
パブリックサブネット内のSSHプロキシのIPアドレスからのインバウンドSSHトラフィックを許可します |
|
15 |
HTTPS |
TCP 8443 |
<SSH Proxy IP Address>/32 |
許可 |
パブリックサブネット内のSSHプロキシのIPアドレスからのインバウンドHTTPSトラフィックを許可します |
|
20 |
カスタムTCPルール |
TCP 32768-65535 |
0.0.0.0/0 |
許可 |
サブネットからの要求に対するインターネット上のホストからのインバウンド返信トラフィックを許可します |
|
* |
All Traffic |
すべて(All) |
0.0.0.0/0 |
拒否 |
前のルールによってまだ処理されていないすべてのインバウンドIPv4トラフィックを拒否します(変更不可能) |
アウトバウンドルール:
表 5-2
|
ルール |
タイプ |
ポート範囲 |
宛先 |
アクション |
説明 |
|---|---|---|---|---|---|
|
10 |
カスタムTCPルール |
TCP 32768-65535 |
<SSH Proxy IP Address>/32 |
許可 |
プライベートサブネットからパブリックサブネット内のSSHプロキシに対するアウトバウンドSSHトラフィックを許可します |
|
12 |
カスタムTCPルール |
TCP 32768-65535 |
<SSH Proxy IP Address>/32 |
許可 |
パブリックサブネットからiManagerにアクセスするためのアウトバウンドトラフィックを許可します |
|
15 |
HTTPS |
TCP 443 |
0.0.0.0/0 |
許可 |
プライベートサブネットからインターネットへのアウトバウンドHTTPSトラフィックを許可します |
|
20 |
HTTP |
TCP 80 |
0.0.0.0/0 |
許可 |
プライベートサブネットからインターネットへのアウトバウンドHTTPトラフィックを許可します |
|
25 |
HTTPS |
監査サーバがリスンしているポート番号 |
<IP Address of the audit server> |
許可 |
eDirectoryイベントの監査を許可します。 メモ:このルールは、監査サーバがプライベートサブネットの外部にある場合にのみ適用されます。 |
|
* |
All Traffic |
すべて(All) |
0.0.0.0/0 |
拒否 |
前のルールによってまだ処理されていないすべてのアウトバウンドIPv4トラフィックを拒否します(変更不可能) |
セキュリティグループは、VPC内の1つまたは複数のインスタンスに割り当てることができる仮想ファイアウォールルールのセットです。
デフォルトでは、新しいセキュリティグループではポート22の着信トラフィックのみが許可されるので、インスタンスにはSSHを使用してのみ接続できます。
詳細については、「LinuxインスタンスのAmazon EC2セキュリティグループ」を参照してください。
AWSにeDirectoryをデプロイするには、3つのセキュリティグループを作成します。たとえば、Security Group 1、Security Group 2、Security Group 3のようにします。次のポートルールを使用して、これらのセキュリティグループを作成します。
Security Group 1 (eDirectory用):
|
ポート |
ソース |
説明 |
|---|---|---|
|
TCP 22 |
パブリックサブネット |
パブリックサブネットからのSSHトラフィックを許可します |
|
TCP 636 |
プライベートサブネット |
プライベートサブネット内でLDAPSトラフィックを許可します |
|
TCP 524 |
プライベートサブネット |
プライベートサブネット内でeDirectoryのNCPトラフィックを許可します |
|
UDP 427 |
プライベートサブネット |
プライベートサブネット内のSLPトラフィックを許可します |
メモ:eDirectoryに割り当てられているセキュリティグループでは、LDAPポート389を有効にしないでください。HTTPポートは、ツリーCAをホストするeDirectoryサーバに割り当てられているセキュリティグループでのみ有効にする必要があります。
Security Group 2 (eDirectory用):
|
ポート |
ソース |
説明 |
|---|---|---|
|
TCP 8028 |
VPC |
ツリーCAによって発行された証明書を使用して設定されているVPCにサービスが存在する場合に、VPCからeDirectoryツリーのCRLにアクセスするために必要です。このセキュリティグループは、ツリーCAをホストしているeDirectoryサーバに割り当てます。 |
Security Group 3 (iManager用):
|
ポート |
ソース |
説明 |
|---|---|---|
|
TCP 22 |
パブリックサブネット |
パブリックサブネットからのSSHトラフィックを許可します |
|
TCP 8443 |
パブリックサブネット |
パブリックサブネットからiManagerにアクセスするためのHTTPSトラフィックを許可します |
Amazon EC2インスタンスを設定する前に、SSHキーペアを作成する必要があります。キーペアを作成するには、次の手順を実行します。
次のコマンドを使用して、クライアント上で4096ビットのRSA SSHキーペアを作成します。
ssh-keygen -t rsa -b 4096
ssh-keygenにより、新しく作成された公開鍵が~/.ssh/id_rsa.pubに置かれます。
ご使用のAmazon EC2アカウントにSSH公開鍵をインポートします。詳細については、「独自の公開鍵をAmazon EC2にインポートする」を参照してください。
重要:SSH秘密鍵を使用してのみ、インスタンスに接続して管理できます。そのため、SSH秘密鍵を紛失しないようにしてください。
サポートされているプラットフォームのいずれかにEC2インスタンスを作成して起動します。インスタンスを作成して起動する方法の詳細については、「EC2リソースを作成しEC2インスタンスを起動する」を参照してください。インスタンスを作成および起動する際には、次の手順も実行する必要があります。
最初のeDirectoryサーバを設定するインスタンスにSecurity Group 1を関連付け、その他のすべてのeDirectoryサーバを設定するインスタンスにSecurity Group 2を関連付け、iManagerを設定するインスタンスにSecurity Group 3を関連付けます。セキュリティグループの詳細については、仮想マシン用のネットワークセキュリティグループの設定を参照してください。
SSHキーペアを作成するセクションで作成した公開鍵をインスタンスに関連付けます。
EC2インスタンスのクラッシュが発生した場合にeDirectoryのデータと設定が失われるのを防ぐには、EBSボリュームを設定する必要があります。eDirectoryのデータと設定を復元する方法の詳細については、障害復旧を参照してください。EC2インスタンスを作成した後、次の手順を実行して、eDirectoryデプロイできるようにインスタンスを準備します。
EBSボリュームを作成するために、「Amazon EBSボリュームの作成」にある手順を実行します。
EC2インスタンスにEBSボリュームを関連付けます。詳細については、「インスタンスへのAmazon EBSボリュームのアタッチ」を参照してください
インスタンスにログインし、EBSボリュームをext4ファイルシステムでフォーマットし、EBSボリュームをマウントします。EBSボリュームをフォーマットしてマウントする方法の詳細については、「LinuxでAmazon EBSボリュームを使用できるようにする」を参照してください。
ディレクトリをEBSボリュームからeDirectoryデータおよびNICIデータディレクトリにバインドマウントします。ルートユーザとして次の手順を実行して、バインドマウントします。
次のコマンドを使用して、eDirectoryデータディレクトリを作成します。
mkdir <mount_point>/eDirectory_data
次のコマンドを使用して、NICIデータディレクトリを作成します。
mkdir <mount_point>/nici_data
次のコマンドを使用して、NICIおよびeDirectoryの環境設定ディレクトリを作成します。
mkdir <mount_point>/eDirectory_nici_conf
次のコマンドを使用して、eDirectoryに必要なディレクトリを作成します。
mkdir –-parents /var/opt/novell/eDirectory mkdir –-parents /var/opt/novell/nici mkdir –-parents /etc/opt/novell/eDirectory
ディレクトリをバインドマウントするために、次の内容を/etc/fstabに追加します。
<mount_point>/eDirectory_data /var/opt/novell/eDirectory none defaults,bind 0 0
<mount_point>/nici_data /var/opt/novell/nici none defaults,bind 0 0
<mount_point>/eDirectory_nici_conf /etc/opt/novell/eDirectory none defaults,bind 0 0
メモ:インスタンス内でのすべての操作は、ルートユーザとして実行する必要があります。
「システム要件」に記載されている要件を満たしていることを確認します。
仮想マシン用のネットワークセキュリティグループの設定で説明されているように、セキュリティグループを作成します。
SSHプロキシインスタンスは、強化され、セキュリティ保護されたサーバである必要があります。このインスタンスについてはSSHポート22のみを開き、適切なパフォーマンスとメモリを持つAWSインスタンスタイプを選択します。プライベートサブネット内のインスタンスとSSHプロキシが実行されているインスタンスへのアクセスに必要なSSH秘密鍵は、VPC内には保存しないようにしてください。クライアント上にのみ保存してください。SSHプロキシサーバにはElastic IPアドレスを関連付けて、スタティックなIPアドレスを設定します。
SSHプロキシインスタンス内にVNCサーバを設定します。VNCサーバは、強力なパスワードを使用して強化する必要があります。セキュリティ保護された通信のみを可能にするために、SSHトンネルを使用してVNCサーバに接続します。VNCサーバは、localhostからの接続についてのみリスンするように設定する必要があります。セッションのロックアウトを防止するために、画面ロックを無効にします。VNCサーバを使用した後、セッションを終了する必要があります。
eDirectory/iManagerを設定するプライベートサブネット内のインスタンスには、SSHプロキシを使用して接続します。
ssh -i edir_key.pem -A -J ec2-user@<ssh_proxy_ip> ec2-user@<instance_private_ip>
メモ:
上記のサンプルコマンドで、edir_key.pemは、サーバキーを含むサンプルファイル名です。
SSH-Addコマンドを使用してエージェント内に識別情報ファイルを追加すれば、ログインするたびに識別情報ファイルを使用しないで済みます。
インスタンスのプライベートIPアドレスを表示するには、[インスタンス]>[インスタンス]>[説明]をクリックします。
バックエンドサブネット内のVMにSLPディレクトリエージェント(DA)サーバを設定します。SLP DAがデプロイされているVMに対して、NSGのインバウンドルールでポート427を開きます。slp.confファイルを編集して、DA操作を有効にします。詳細については、『NetIQ eDirectory管理ガイド』の「OpenSLP for eDirectoryの設定」を参照してください。
このセクションでは、AWS EC2環境にeDirectoryとiManagerをインストールして設定する手順について説明します。eDirectoryをインストールした後、次の条件を満たしていることを確認する必要があります。
EBAが有効になっている
SNMPが無効になっている
eDirectoryがポート389でリスンしていない
LDAPおよびHTTPサービスは、ECDSA証明書のみを使用するように設定されている
使用されていない場合は、AWS EC2プライベートインスタンスのSSHポートへのアクセスを無効にする必要があります。
iMonitor、eMBox、およびDHostモジュールを無効にして、セキュリティを強化する。これらのモジュールを無効にした後、これらのモジュールに関係するすべてのアクティビティは、NDSユーティリティのみを使用して実行する必要があります。
eDirectoryを設定するプライベートサブネット内のインスタンスに、セキュアコピー(scp)を使用してeDirectory_<version>_Linux_x86_64.tar.gzファイルをコピーします(SSHプロキシを使用します)。
scp -i <keyname> -o ProxyJump=ec2-user@<ssh_proxy_ip> eDirectory_<version>_Linux_x86_64.tar.gz ec2-user@<instance_ip>:/<directory>eDirectoryをインストールします。詳細については、「nds-installユーティリティを使用してeDirectoryコンポーネントをインストールする」を参照してください。
eDirectoryを設定します。詳細については、「ndsconfigユーティリティを使用してeDirectoryレプリカサーバを追加または削除する」を参照してください。たとえば、eDirectoryをインストールして設定するためのコマンドのサンプルを次に示します。
ndsconfig new [-t <tree_name>] [-n <server context>] -a <admin FDN> [-w <admin password>] -P ldaps://<instance_ip> --configure-eba-now yesopenslp-serverをインストールして、SLPDサービスを始動します。
iManager管理コンソールを使用すると、AWS環境上でeDirectoryの操作を管理できます。iManagerは、eDirectoryをインストールした後で、AWSインスタンスにインストールする必要があります。
iManagerを設定するプライベートサブネット内のインスタンスに、セキュアコピー(scp)を使用してiMan_<version>_linux_x86_64.tgzファイルをコピーします(SSHプロキシを使用します)。
scp -i <keyname> -o ProxyJump=ec2-user@<ssh_proxy_ip> iMan_<version>_linux_x86_64.tgz ec2-user@<instance_ip>:/<directory>iManagerをインストールして設定します。詳細については、「LinuxでのiManagerサーバのインストール」を参照してください。iManagerをインストールする前に、『iManagerインストールガイド』の「システム要件」セクションに記載されているシステム要件を参照してください。
iManagerが実行されているインスタンスに、EBA CA証明書をダウンロードします。詳細については『NetIQ eDirectory管理ガイド』の「iManagerを使用したEBA CAの管理」を参照してください。
iManagerを実行しているVMの自己署名証明書を、セキュアCA署名証明書で置き換えます。詳細については、「iManager用の一時的な自己署名証明書の置き換え」を参照してください。
メモ:iManager サーバは、ECDSA証明書のみを使用するように設定してください。iManagerをインストールした後、権限を持ったユーザと、このユーザが管理する適切なeDirectoryツリー名を指定します。
次の手順を実行して、iManagerを起動します。
SSHトンネルを使用して、SSHプロキシのlocalhost上で実行されているVNCサーバに接続します。
同じインスタンスにブラウザをインストールして起動します。
iManagerを起動し、IPアドレスまたはツリー名を使用してeDirectoryツリーに接続します。
EBAが有効になっているかどうかを確認するため、『NetIQ eDirectory管理ガイド』「EBAに関する情報の表示」を参照してください。
証明書サーバでSuite Bを有効にします。詳細については、『NetIQ eDirectory管理ガイド』の「証明書サーバでのSuite Bの有効化」を参照してください。
1番目のeDirectoryサーバに対してAES 256ビットツリーキーを設定します。詳細については、『NICI Administration Guide (NICI管理ガイド)』の「Creating an AES 256-Bit Tree Key (AES 256ビットツリーキーを作成する)」を参照してください。
1番目のeDirectoryサーバにあるCRL配布ポイントを削除します。ポート389でのセキュリティ保護されていないLDAPアクセスはすべてのeDirectoryサーバで無効化されているため、ツリーCAのCRLはHTTPのみでダウンロードできるようにする必要があります。次の手順を実行して、CRL配布ポイントを削除します。
管理者としてiManagerにログインします。
[役割およびタスク]>[NetIQ証明書サーバ]>[認証局の環境設定]に移動します。
[CRL]をクリックします。
[One]をクリックします。HTTP CRL配布ポイント(http://<instance_ip>:8028/crl/one.crl)以外のすべての[CRL配布ポイント]を選択して削除します。
[適用]をクリックし、[閉じる]をクリックします。
[OneEC]をクリックします。HTTP CRL配布ポイント(http://<instance_ip>:8028/crl/oneec.crl)以外のすべての[CRL配布ポイント]を選択して削除します。
[適用]をクリックし、[OK]をクリックします。
iManager証明書サーバプラグインを使用して、サーバのデフォルト証明書を修復します。デフォルト証明書を修復するには、次の手順を実行します。
管理者としてiManagerにログインします。
[役割およびタスク]>[NetIQ証明書サーバ]>[デフォルト証明書の修復]に移動します。
証明書を所有するサーバを選択して、[次へ]をクリックします。
[デフォルト証明書はすべて上書きされます]を選択し、[次へ]をクリックします。
実行するタスクを確認し、[完了]を選択します。
ECDSA証明書とSuite B暗号化を使用するようにLDAPサービスとHTTPサービスを設定します。詳細については『NetIQ eDirectory管理ガイド』の「ECDSA証明書とSuite B Cipherを使用するためのLDAPサービスとHTTPサービスの設定」を参照してください。完了したら、eDirectory を再起動します。
SNMPサブエージェントがアンロードされているかどうかを確認する方法について、『NetIQ eDirectory管理ガイド』の「SNMPサーバモジュールのロードとアンロード」を参照します。
eDirectoryがポート389でリスンしていないことを確認します。
iMonitor、eMBox、DHost、およびHTTPスタックを無効にします。
次の手順を実行して、ツリーCAをホストしているeDirectoryサーバのiMonitor、eMBox、およびDHostを無効にします。
ndsmodules.confファイルを編集して、hconserv、imon、およびemboxをコメント化します。
eDirectoryを再起動します。
次の手順を実行して、eDirectoryレプリカサーバのHTTPスタックを無効にします。
ndsmodules.confファイルを編集して、httpstk、hconserv、imon、およびemboxをコメント化します。
eDirectoryを再起動します。
メモ:httpstkは、コメント化の前に、ndsmodules.confファイル内でndsより上に配置されている必要があります。これにより、ndsモジュールはHTTPスタックを有効にしなくなります。
アドバタイジング方式としてユニキャストを使用することをeDirectoryに強制するように、SLPを設定します。バックエンドサブネット内のDAサーバのIPアドレスを提供するように、slp.confファイルを編集します。詳細については、『NetIQ eDirectory管理ガイド』の「環境設定パラメータ」を参照してください。
メモ:すべてのeDirectoryインスタンスとiManagerの設定が完了したら、SSHポートへのアクセスを拒否し、必要な場合にのみ許可するように、AWSプライベートサブネットのネットワークACLを設定してください。
AWS EC2にCommon Event Format (CEF)監査サービスをデプロイして、さまざまなeDirectoryイベントを監査することができます。CEF監査サービスをデプロイするには、次の手順を実行します。
VPCに監査サーバをインストールします。
ポート上でリスンするように監査サーバを設定します
メモ:監査サーバとしてはSentinelを使用することをお勧めします。
次の設定を使用して新しいセキュリティグループを作成し、監査サーバが実行されているインスタンスに関連付けます。
|
ポート |
ソース |
説明 |
|---|---|---|
|
TCP (監査サーバポート) |
プライベートサブネット |
eDirectoryサーバからのイベントの受信を許可します |
すべてのeDirectoryインスタンスで、次のように/etc/opt/novell/eDirectory/conf/auditlogconfig.propertiesファイルを更新します。
log4j.appender.S.Host=<Auditing server ip> log4j.appender.S.Port=<auditing server port>
iManagerから、対応するCEFイベントを有効にします。詳細については、「監査するCEFイベントの設定」を参照してください。有効にされたイベントは、監査サーバに転送されます。
障害復旧は、eDirectoryが実行されているインスタンスでクラッシュが発生した場合に実行します。障害復旧を行うには、次の手順を実行します。
クラッシュしたインスタンスを停止し、EBSボリュームとの関連付けを解除します。詳細については、「インスタンスからのAmazon EBSボリュームのデタッチ」を参照してください。
クラッシュしたインスタンスと同じオペレーティングシステムを使用して、新しいEC2インスタンスを設定します。
新しいEC2インスタンスに同じバージョンのeDirectoryをインストールします。
新しいインスタンスにEBSボリュームをアタッチし、ファイルシステムをマウントします。詳細については、「インスタンスへのAmazon EBSボリュームのアタッチ」を参照してください。
ディレクトリをバインドマウントします。
ディレクトリをバインドマウントするには、/etc/fstabを次のように更新します。
<mount_point>/eDirectory_data /var/opt/novell/eDirectory none defaults,bind 0 0
<mount_point>/nici_data /var/opt/novell/nici none defaults,bind 0 0
<mount_point>/eDirectory_nici_conf /etc/opt/novell/eDirectory none defaults,bind 0 0
/etc/opt/novell/eDirectory/conf/nds.conf内のIPアドレスを、現在のインスタンスのIPアドレスに変更します。
eDirectoryをアップグレードしてヘルスチェックをスキップします。詳細については、『NetIQ eDirectoryインストールガイド』の「eDirectoryをアップグレードする」を参照してください。
ndsrepairユーティリティを使用して、ネットワークアドレスを修復します。詳細については、『NetIQ eDirectory管理ガイド』の「DSRepairオプション」を参照してください。
ツリーCAのIPアドレスが変更された場合は、CRL配布ポイントのIPアドレスを変更します。IPアドレスの変更方法の詳細については、『NetIQ eDirectory管理ガイド』の「CRL環境設定オブジェクトのプロパティの表示と変更」を参照してください。
iManager証明書サーバプラグインを使用して、サーバのデフォルト証明書を修復します。デフォルト証明書を修復するには、次の手順を実行します。
管理者としてiManagerにログインします。
[役割およびタスク]>[NetIQ証明書サーバ]>[デフォルト証明書の修復]に移動します。
証明書を所有するサーバを選択して、[次へ]をクリックします。
[デフォルト証明書はすべて上書きされます]を選択し、[次へ]をクリックします。
実行するタスクを確認し、[完了]を選択します。
新しいECDSA証明書を使用するようにLDAPおよびHTTPサービスを設定します。