ナビゲーションリンクをスキップ | |
印刷ビューの終了 | |
Trusted Extensions 構成と管理 Oracle Solaris 11.1 Information Library (日本語) |
パート I Trusted Extensions の初期構成
1. Trusted Extensions のセキュリティー計画
2. Trusted Extensions の構成ロードマップ
3. Oracle Solaris への Trusted Extensions 機能の追加 (タスク)
4. Trusted Extensions の構成 (タスク)
5. Trusted Extensions のための LDAP の構成 (タスク)
8. Trusted Extensions システムのセキュリティー要件 (概要)
9. Trusted Extensions での一般的なタスクの実行
10. Trusted Extensions でのユーザー、権利、および役割 (概要)
11. Trusted Extensions でのユーザー、権利、役割の管理 (タスク)
12. Trusted Extensions でのリモート管理 (タスク)
Trusted Extensions でのリモートシステムの管理方式
Trusted Extensions でのリモートシステムの構成および管理 (タスクマップ)
リモート Trusted Extensions システムのリモート管理を有効にする
13. Trusted Extensions でのゾーンの管理
14. Trusted Extensions でのファイルの管理とマウント
16. Trusted Extensions でのネットワークの管理 (タスク)
17. Trusted Extensions と LDAP (概要)
18. Trusted Extensions でのマルチレベルメール (概要)
20. Trusted Extensions のデバイス (概要)
21. Trusted Extensions でのデバイス管理 (タスク)
22. Trusted Extensions での監査 (概要)
23. Trusted Extensions のソフトウェア管理
サイトのセキュリティーポリシーと Trusted Extensions
B. Trusted Extensions の構成チェックリスト
Trusted Extensions を構成するためのチェックリスト
Trusted Extensions による Oracle Solaris インタフェースの拡張
Trusted Extensions の厳密なセキュリティーデフォルト
Trusted Extensions で制限されるオプション
D. Trusted Extensions マニュアルページのリスト
Trusted Extensions マニュアルページ (アルファベット順)
リモート管理を有効にしたあと、リモートシステムをリブートして Trusted Extensions を有効にする前に、仮想ネットワークコンピューティング (VNC) または ssh プロトコルを使用してシステムを構成できます。
|
注 - セキュリティーポリシーを確認して、サイトで許可されているリモート管理の方法を判定します。
この手順では、ある Oracle Solaris リモートシステム上でホストベースの認証を有効にしたあと、そのシステムに Trusted Extensions 機能を追加します。リモートシステムは Secure Shell サーバーです。
始める前に
リモートシステムに Oracle Solaris がインストールされており、そのシステムにアクセスできます。root 役割になっている必要があります。
手順については、『Oracle Solaris 11.1 の管理: セキュリティーサービス』の「ホストに基づく認証を Secure Shell に設定する方法」を参照してください。
注 - cat コマンドは使用しないでください。Secure Shell 接続経由で公開鍵をコピー&ペーストします。Secure Shell クライアントが Oracle Solaris システムでない場合は、プラットフォームの手順に従って、ホストベースの認証で Secure Shell クライアントを構成します。
この手順が完了すると、root 役割になれるユーザーアカウントが両方のシステム上に存在しています。これらのアカウントには同じ UID、GID、および役割割り当てが割り当てられています。また、生成された公開/非公開鍵ペアと共有公開鍵も存在しています。
# pfedit /etc/ssh/sshd_config ## Permit remote login by root PermitRootLogin yes
あとの手順で、root ログインを特定のシステムとユーザーに制限します。
注 - 管理者は root 役割になるので、リモート root ログインを禁止するログインポリシーを引き下げる必要はありません。
# svcadm restart ssh
# cd # pfedit .shosts client-host username
この .shosts ファイルは、公開/非公開鍵が共有されている状態で、client-host システム上の username がサーバー上の root 役割になれるようにします。
# cp /etc/pam.d/other /etc/pam.d/other.orig
# pfedit /etc/pam.d/other ... # Default definition for Account management # Used when service name is not explicitly mentioned for account management # ... #account requisite pam_roles.so.1 # Enable remote role assumption account requisite pam_roles.so.1 allow_remote ...
このポリシーは、client-host システム上の username がサーバー上で役割になれるようにします。
# pfedit /etc/pam.d/other # Default definition for Account management # Used when service name is not explicitly mentioned for account management # ... #account requisite pam_roles.so.1 # Enable remote role assumption account requisite pam_roles.so.1 allow_remote # account required pam_unix_account.so.1 #account required pam_tsol_account.so.1 # Enable unlabeled access to TX system account required pam_tsol_account.so.1 allow_unlabeled
% ssh -l root remote-system
# svcadm enable -s labeld # /usr/sbin/reboot
例 12-1 リモート管理のための CIPSO ホストタイプの割り当て
この例では、管理者は Trusted Extensions システムを使用してリモート Trusted Extensions ホストを構成します。管理者はそのために、各システム上で tncfg コマンドを使用して、ピアシステムのホストタイプを定義します。
remote-system # tncfg -t cipso add host=192.168.1.12 Client-host
client-host # tncfg -t cipso add host=192.168.1.22 Remote system
ラベルなしシステムもリモート Trusted Extensions ホストを構成できるので、管理者はリモートホストの pam.d/other ファイル内に allow_unlabeled オプションを残します。
仮想ネットワークコンピューティング (Virtual Network Computing、VNC) テクノロジは、クライアントをリモートサーバーに接続し、クライアントのウィンドウにリモートサーバーのデスクトップを表示します。Xvnc は UNIX バージョンの VNC であり、標準 X サーバーをベースにしています。Trusted Extensions では、どのプラットフォーム上のクライアントでも、Trusted Extensions が実行されている Xvnc サーバーに接続して、Xvnc サーバーにログインし、マルチレベルデスクトップ上で表示して作業できます。
詳細は、Xvnc(1) および vncconfig(1) のマニュアルページを参照してください。
始める前に
Xvnc サーバーとして使用されるこのシステム上で、Trusted Extensions のインストールと構成が完了しています。このシステムの大域ゾーンは固定 IP アドレスを持ちます。つまりこのゾーンでは、netcfg(1M) のマニュアルページで説明されている自動ネットワーク構成プロファイルは使用されていません。
このシステムは、VNC クライアントをホスト名か IP アドレスで認識します。具体的には、admin_low セキュリティーテンプレート内で、このサーバーの VNC クライアントになれるシステムが、明示的に特定されるかワイルドカードを使用して特定されます。接続を安全に構成する方法の詳細については、「トラステッドネットワーク上で接続できるホストを制限する」を参照してください。
現在、将来の Trusted Extensions Xvnc サーバーのコンソールの GNOME セッションで実行している場合は、デスクトップ共有を有効にする必要はありません。
将来の Trusted Extensions Xvnc サーバーの大域ゾーンで root 役割になっています。
# packagemanager &
パッケージマネージャー GUI で「vnc」を検索し、使用可能なサーバーから選択します。オプションの 1 つとして、TigerVNC X11/VNC サーバーソフトウェアがあります。
GUI を開くことができない場合は、ローカルの root アカウントを X サーバーのアクセス制御リストに追加します。X サーバーにログインしたユーザーでこのコマンドを実行します。
% xhost +si:localuser:root
詳細は、xhost(1) および Xsecurity (5) のマニュアルページを参照してください。
GNOME ディスプレイマネージャー (gdm) のカスタム構成ファイルを変更します。/etc/gdm/custom.conf ファイルの [xdmcp] 見出しの下に、Enable=true と入力します。
[xdmcp] Enable=true
ヒント - Xsession ファイルの変更を行う前に元のコピーを保存します。
DISPLAY=unix:$(echo $DISPLAY|sed -e s/::ffff://|cut -d: -f2)
手順 2 および手順 3 のファイルには、パッケージ属性 preserve=true が付いています。パッケージのアップグレードおよびパッケージの修正の際に、変更したファイルがこの属性によって受ける影響については、pkg(5) のマニュアルページを参照してください。
# svcadm enable xvnc-inetd
# svcadm restart gdm
デスクトップマネージャーが再起動するまで約 1 分間待ちます。これで、VNC クライアントが接続可能となります。
# svcs | grep vnc
クライアントシステムでは、ソフトウェアを選択できます。Oracle Solaris リポジトリの VNC ソフトウェアを使用できます。
システム別およびユーザー別の監査イベントの事前選択については、『Oracle Solaris 11.1 の管理: セキュリティーサービス』の「監査サービスの構成 (タスク)」を参照してください。
% /usr/bin/vncviewer Xvnc-server-hostname
コマンドのオプションについては、vncviewer(1) のマニュアルページを参照してください。
ログイン手順に進みます。残りの手順については、『Trusted Extensions ユーザーズガイド』の「Trusted Extensions へのログイン」を参照してください。
例 12-2 テスト環境で Vino を使用してデスクトップを共有する
この例では、2 人の開発者が GNOME Vino サービスを使用して「起動」→「システム」→「設定」→「デスクトップの共有」メニューからディスプレイを共有しています。前述の手順に加えて、XTEST 拡張を有効することによって Trusted Extensions ポリシーを引き下げます。
# pfedit /usr/X11/lib/X11/xserver/TrustedExtensionsPolicy ## /usr/X11/lib/X11/xserver/TrustedExtensionsPolicy file ... #extension XTEST extension XTEST ...
この手順を実行すると、コマンド行と txzonemgr GUI を使用してリモート Trusted Extensions システムを管理できます。
始める前に
「リモート Trusted Extensions システムのリモート管理を有効にする」の説明に従って、ローカルシステム上とリモートシステム上でユーザー、役割、および役割割り当てがまったく同様に定義されています。
desktop $ xhost + remote-sys
ssh コマンドを使用してログインします。
desktop $ ssh -X -l identical-username remote-sys Password: Type the user's password remote-sys $
-X オプションは GUI の表示を可能にします。
たとえば、root の役割になります。
remote-sys $ su - root Password: Type the root password
大域ゾーンにいます。これで、この端末ウィンドウを使用してコマンド行からリモートシステムを管理できるようになりました。画面上に GUI が表示されます。例については、例 12-3 を参照してください。
例 12-3 リモートシステムでのラベル付きゾーンの構成
この例では、管理者が txzonemgr GUI を使用して、ラベル付きデスクトップシステムからラベル付きリモートシステム上のラベル付きゾーンを構成します。Oracle Solaris と同様に、管理者は ssh コマンドに -X オプションを使用して、デスクトップシステムへの X サーバーのアクセスを許可します。ユーザー jandoe は両方のシステムで同じように定義されているので、役割 remoterole になることができます。
TXdesk1 $ xhost + TXnohead4
TXdesk1 $ ssh -X -l jandoe TXnohead4 Password: Ins1PwD1 TXnohead4 $
管理者は大域ゾーンに到達するために、jandoe アカウントを使用して役割 remoterole になります。この役割は、両方のシステムで同じように定義されています。
TXnohead4 # su - remoterole Password: abcd1EFG
同じ端末で、管理者は remoterole 役割として txzonemgr GUI を起動します。
TXnohead4 $ /usr/sbin/txzonemgr &
Labeled Zone Manager はリモートシステム上で実行され、ローカルシステム上に表示されます。
例 12-4 リモートラベル付きゾーンへのログイン
管理者は、リモートシステム上の PUBLIC ラベルの構成ファイルを変更する必要があります。
管理者には 2 つの選択肢が用意されています。
大域ゾーンにリモートログインしてリモート大域ゾーンのワークスペースを表示したあと、ワークスペースを PUBLIC ラベルに切り替え、端末ウィンドウを開き、ファイルを編集します
PUBLIC 端末ウィンドウから ssh コマンドを使用して PUBLIC ゾーンにリモートログインしたあと、ファイルを編集します。
リモートシステムですべてのゾーンに対して 1 つのネームサービスデーモン (nscd) が実行されていて、なおかつそのリモートシステムでファイルネームサービスが使用されている場合、リモート PUBLIC ゾーンのパスワードは、そのゾーンが最後にブートされたときに有効だったパスワードになります。リモート PUBLIC ゾーンのパスワードを変更しても、変更後にそのゾーンをブートしなければ、元のパスワードでアクセスが許可されます。
注意事項
-X オプションが機能しない場合は、パッケージをインストールしなければいけない可能性があります。xauth バイナリがインストールされていないと、X11 転送が無効になります。このバイナリを読み込むコマンドを次に示します: pkg install pkg:/x11/session/xauth