Jump to content 日本-日本語

製品  >  ソフトウェア  >  HP- UX Developer Edge

「だれもがroot」を解消するSecurity Containment・前編

HP-UX/Integrityサーバー お問い合せ
コンテンツに進む
「だれもがroot」を解消するSecurity Containment・前編
rootユーザがすべての管理権限を掌握するUNIXでは、ちょっとした作業でもroot権限が必要となり、「だれもがrootのパスワードを知っている」という状況になりがちだ。しかし、こうした一枚岩なセキュリティ管理では、不正アクセスでrootを奪取されればシステム全体が失われてしまう。また操作ミスや個人情報の漏洩を考えると、用途ごとに1台のマシンを占有せざるを得ない。このような状況を解消するのが、HP-UXの新しいセキュリティ強化機能「Security Containment」だ。同機能では、あたかも潜水艦のようにOS内部を頑丈な区画で隔離し、たとえ“浸水”してもその影響を区画内に封じ込めることができる。
「だれもがroot」を解消するSecurity Containment・前編
「だれもがroot」のセキュリティ・ポリシー
ロールベースのアクセス権限管理
2005年7月
テクニカルライター  吉川和巳

「だれもがroot」のセキュリティ・ポリシー

ご存じのとおりUNIXでは、rootという1つのユーザ・アカウントがすべての管理権限を掌握しており、ちょっとしたインストール作業や設定でもroot権限が必要になる。その結果、そのシステムに関わる誰しもがrootのパスワードを知っているという状況になりがちだ。この事情はWindows XPやWindows 2000でも同様で、Administratorユーザだけで運用されているWindowsマシンも少なくない。

こうした一枚岩なセキュリティ管理には落とし穴がある。不正アクセスを受けたサーバがひとたびrootアカウントを奪取されれば、そのサーバ全体がクラッカーの手中に落ちてしまう。また、root権限で実行中のプロセスにバグや悪意のあるコードが含まれていると、同じOS上の他のプロセスやリソースにも影響する。

さらにこの問題は、TCO増加の原因にもなっている。ある特定のアプリケーションの運用担当者にroot権限を与えれば、その担当者からは他のアプリケーションのプロセスやファイルも丸見えである。よって個人情報の漏洩や操作ミスを考えると、アプリケーションや用途ごとに1台のマシンを占有させる「専用ホスティング」とせざるを得ず、ハードウェア・リソースの過剰な配分が避けられないのだ。

もともとUNIXは、肥大化したメインフレーム用マルチユーザOS「Multics」に対抗し、シンプルな小規模OSとして開発されたといういきさつがある。その単純さと軽さがIT分野を席巻する原動力となった。とはいえ、管理者のアクセス権限が用途ごとに細分化されているメインフレームでは、上述したようなセキュリティ・リスクが生じないのも事実だ。現在のUNIXは、多数のアプリケーションや大量の個人情報を収容し、不正アクセスやウィルスがはびこるインターネット環境にさらされるようになった。そこでUNIX本来の使いやすさとシンプルさを保ちつつ、メインフレーム・クラスの厳格かつ細やかな権限管理を実現する「インターネット世代の新しいセキュリティ基盤」が必要とされている。

こうしたニーズに応えるのが、2005年9月にリリースされたHP-UX向けセキュリティ強化機能「Security Containment」である。同機能はHPのWebサイトから無償でダウンロード可能で、HP-UX 11i v2が動作するHP IntegrityサーバおよびHP 9000サーバで利用できる。

Security Containmentとは、「セキュリティの封じ込め」という意味である。つまり、アプリケーションのトラブルや管理者による操作ミス、そして不正アクセスの影響を最小限に封じ込めることを目的とした機能だ。具体的には、以下の3つの機能から構成される。
  • コンパートメント
  • Role-based Access Control
  • Fine-grained privileges
  以下では、これら3つの機能について詳しく見ていきたい。

コンパートメント

第1の機能、コンパートメント(Compartment)とは、いわば潜水艦のような設計をOS内部に導入する機能である。HP-UX上で動作するプロセスやファイル、ネットワーク・インタフェースなどをアプリケーションや用途ごとに分割し、それぞれを「コンパートメント」と呼ばれる論理的な区画に封じ込める。万が一、いずれかのコンパートメントが“浸水”した(=不正アクセスやトラブルが発生した)としても、OS全体への影響を食い止める仕組みである(図1)。
 
図1:コンパートメントの効用
図1:コンパートメントの効用
  コンパートメントを利用するには、/etc/cmptディレクトリにて以下のような設定ファイル (fs_example.rules) を作成する。

  #define APP_DIR /var/tmp/my_app
#define ALL_PERM read,write,create,unlink
compartment FS_EXAMPLE {
    perm none /etc/passwd
    perm read APP_DIR
    perm read,create APP_DIR/logs
    perm ALL_PERM APP_DIR/tmp
}
 

この例では、コンパートメント内部のプロセスに対し、ファイルのアクセス権限を付与している。「perm read APP_DIR」という部分では、APP_DIRが示すアプリケーション用ディレクトリついてファイルの読み込み権限(read)を付与している。また次の行の「perm read,create APP_DIR/logs」では、logsディレクトリでファイルの読み込みと作成(read,create)の権限を与えている。

この設定ファイルに基づいたコンパートメントを利用するには、以下のコマンドを実行してシステムをリブートする。

  # cmpt_tune -e  

こうしてコンパートメントが有効化されると、コンパートメントに属するプロセスやその子プロセスは、指定されたディレクトリ以外のファイルにアクセスできなくなる。たとえroot権限で実行されたプロセスであっても例外ではない。またネットワーク・インタフェースについても、明示的に設定しない限りプロセスからアクセスできなくなる。このようにコンパートメントでは、通常のUNIXのパーミッションとは異なり、管理者が設定したポリシーが強制的に適用される仕組みだ。こうしたメカニズムは一般にMAC(Mandatory Access Control)と呼ばれ、ユーザが自由にパーミッションを設定できる従来のDAC(Discretionary Access Control)と区別される。

このようなコンパートメントをアプリケーションや用途ごとに設けることで、それぞれが個別のサーバで運用するのと同等のセキュリティが得られる。共用ホスティングでも安心してアプリケーションを運用できるはずだ。また、コンパートメントを隔てたファイル・アクセスやプロセス間通信も必要に応じて許可できるので、個別のサーバよりも柔軟性は高いと言える。

後半では、Security Containmentのもう一つの機能、Role-based Access Control(RBAC)について紹介しよう。
トップへ   次のページへ

本ページの内容は執筆時の情報に基づいており、異なる場合があります。

お問い合わせ

ご購入前のお問い合わせ


ご購入後のお問い合わせ

HPEサポートセンター
製品の標準保証でご利用いただける無償のサービスです。

ショールーム

ショールーム 導入をご検討のお客様へ
業務アプリケーションの継続・標準化・開発性とシステム担当者様、システム開発者様が抱える悩み・疑問に対する解決策実体験して頂けます。
印刷用画面へ
プライバシー ご利用条件・免責事項