目次


IBM Lotus Domino Web サーバーをセキュアにする

Comments

現在、Web セキュリティーは、かつてないほどの大きな課題となっています。Lotus Domino の豊富なセキュリティー機能を利用することにより、企業の Web データをできる限り安全にそしてセキュアにすることができます。 多くの企業は、イントラネット・サイトおよびインターネット・サイトに Lotus Domino を使用しています。特にインターネットでは、データの完全性と Web サイトの可用性を高めるために、これらの環境で Domino Server をセキュアにすることが非常に重要です。

この記事では、Domino のセキュリティー機能を使用して、Web 環境のセキュリティーを維持する方法について解説します。まず、Domino セキュリティー・モデルの概要を簡単に説明することから始めます。次に、Web 認証、サーバー・セキュリティー、データ・セキュリティーを介して Web サーバーをセキュアにする方法を説明します。この記事は、Domino のシステム管理者としての経験がある方を対象に書かれています。

Domino セキュリティー・モデル

まず、マルチレイヤーの Domino セキュリティー・モデルの概要について簡単に説明します。(Notes/Domino セキュリティーの詳細については、『Overview of Notes/Domino security』など、以前の developerWorks: Lotus 記事で解説されています。しかし、Domino Web サーバー・セキュリティーなど、記事で取り上げる概念の理解を助けるために、概要を簡単に説明します。)

Lotus Domino には、ユーザーからデータまたはリソースへのアクセスを制限する複数のレイヤーがあります。各レイヤーでは、ユーザー認証が試みられます。たとえば、Domino データベースへアクセスするには、そのデータベースが保存されている Domino Server へのアクセスが認められなければなりません。これらのアクセスレイヤーは、次に示す 5 つのより一般的なグループに分類できます。

  • サーバー・アクセス
  • データベース・アクセス
  • ビュー・アクセス
  • 文書アクセス
  • フィールド・アクセス

それぞれのグループについて、次のセクションで詳しく見ていきます。

サーバー・アクセス

サーバー・アクセスには、次のものが含まれます。

  • ネットワーク・アクセス
    一般的に、ネットワーク・アクセスは、ファイアウォールまたはルーターによって制御されます。ファイアウォールまたはルーターはネットワーク・ポートをブロックすることにより、Domino Server へのアクセスを制限します。たとえば、ポート 1352 をブロックするファイアウォールは、Notes Client アクセスをブロックします。
  • ユーザー認証
    ユーザー認証は、ユーザー名とパスワードが正しいことを検証します。これは、Domino Server と Domino データベースで行われるユーザー権限の確認とは異なります。
  • Domino Server
    Domino サーバー・アクセスは、Domino ディレクトリのサーバー文書で定義されます。アクセス不可リストに指定されているユーザーまたはアクセス可能リストに指定されていないユーザーは、サーバーへのアクセスが認められません。Lotus Domino 5 では、サーバー文書のサーバー・アクセス設定は、Web ブラウザを使用してサーバーにアクセスするユーザーには適用されませんでした。しかし、Lotus Domino 6 では、サーバー・アクセスの設定が Web ユーザーにも実施されるようになりました (図 1 参照)。
図 1. Web ユーザーへのサーバー・アクセス設定の実施
Web ユーザーへのサーバー・アクセス設定の実施
Web ユーザーへのサーバー・アクセス設定の実施

データベース・アクセス

データベース・アクセスは、各データベースのアクセス制御リスト (ACL) によって制御されます。ACL は、ユーザーがデータベースにアクセスする権限を持っているかどうか、またどのレベルのアクセスを許可するのかを決定します。ユーザーおよびユーザー・グループにロールを割り当てることもできます。アプリケーションでは、これらのロールを使用して、より詳細なアクセス・レベルをユーザーに付与できます。たとえば、Domino ディレクトリへの [作成者] のアクセス権と [Group Creator] ロールをユーザーに割り当てることができます。このユーザーは、データベースに対して [編集者] のアクセス権を持たなくても、グループを作成できます (図 2 参照)。

図 2. Domino データベースのアクセス制御リスト
Domino データベースのアクセス制御リスト
Domino データベースのアクセス制御リスト

ビュー・アクセス

ビュー・アクセスはビューのプロパティによって制御されます。ビューを見ることができるユーザーを定義できますが、ユーザーは同じ文書を表示する他のビューにアクセスできる可能性があります。このため、ビュー・アクセスは、主にユーザー・インターフェースの管理という観点から使用するものであり、真のデータ・セキュリティーではありません (図 3 参照)。

図 3. ビュー・アクセスの制御
ビュー・アクセスの制御
ビュー・アクセスの制御

文書アクセス

文書アクセスは、文書の編集または作成時に文書の一部として保存される 1 つ以上の [読者] フィールドによって制御されます。このフォームから作成された文書を読むことができるユーザーまたはグループの名前を明示的に指定することにより、許可された読者がこのフィールドにリストされます。文書への [読者] アクセス権を持たないユーザーは、ビューやデータベース内の文書を表示できません。

フィールド・アクセス

各フィールドは、フィールドのプロパティ (図 4 参照) を変更することにより、非表示にしたり、アクセスを制限できます。

図 4. フィールドの非表示プロパティ
フィールドの非表示プロパティ
フィールドの非表示プロパティ

フィールドの非表示プロパティを使用しても、別の方法でデータ・アイテムにアクセスできることを思い出してください。この場合、フィールドの非表示は、ユーザー・インターフェースの管理という観点で使用するもので、真のデータ・セキュリティーではありません。また、フィールドはプライベート・キーで暗号化できます。このキーを持たないユーザーは、暗号化されたデータにアクセスできません。インターフェースの管理用にフィールドを非表示にするよりも、この方法を用いた方がフィールドのセキュリティーが高まります (図 5 参照)。

図 5. フィールドのセキュリティー・オプション
フィールドのセキュリティー・オプション
フィールドのセキュリティー・オプション

Web セキュリティー

それでは、5 つのセキュリティー・レベルをすべて使用する Web ベースの例を見ていきましょう。インターネットからの注文を受け付ける販売会社を例に取ります。Domino Server を DMZ でセキュアにセットアップするために、次のことを行います。

  1. インターネットアクセスをポート 80 (HTTP) と 443 (HTTPS) に制限します。
  2. すべてのユーザーにサーバーとの認証を要求し、データベース・アクセスをチェックする前にサーバー・アクセスをチェックします。ユーザーは、正しく認証されない限り、サーバー上のどの Web ページも読むことができません。
  3. [HTTP クライアントからのデータベース参照を許可] を [いいえ] に設定することにより、サーバーの参照を無効にします。
  4. アプリケーション・データベースで ACL を変更し、[作成者] のアクセス権だけをユーザーに与えます。これによって、ユーザーは、新規注文を作成したり、過去の注文を表示することができます。
  5. ビュー・アクセスを制限します。データベースにはいくつかのビューがありますが、ユーザーがアクセスできるのは [Catalog] ビューと [Orders] ビューだけに制限されます。
  6. 注文したユーザーだけをリストする計算結果の [読者] フィールドを追加します。注文フォームには、販売会社が注文の管理に使用するいくつかのプライベート・フィールドが含まれます。これらのフィールドは、非表示式を使用することによって作成し、注文するユーザーからは見えないようにします。

これまでに、Domino セキュリティーの概要を見てきました。次に、このマルチレイヤー手法で考慮しなければならないセキュリティーの問題について説明します。インターネットからアクセスできる Web サーバーは、潜在的な脅威に対し無防備です。これらの脅威は、インターネット経由でアクセスできるサーバーに特有のものです。この結果、次の 3 つの大きなセキュリティー・トピックを解決しなければなりません。

  • Web 認証
  • サーバーのセキュリティー
  • データのセキュリティー

これらの 3 つのトピックと、関連する脅威、脅威を解消する方法について説明します。

Web 認証

Web 認証とは、ユーザーが Web サーバーに対し自分自身を証明するためのプロセスです。通常は、ユーザー名とパスワードを入力するダイアログ・プロンプトを通して行われます。では、Web サイトをセットアップし、すべてのユーザーに認証を実施するケースを考えてみましょう。ハッカーは、ユーザー名を決めて連続的にサイトにアクセスし、さまざまなパスワードを試みます。パスワードが偶然一致し、サイトへのアクセスを得るまで繰り返します。これを辞書攻撃と呼びます。この種の攻撃を防止する最もよい方法は、パスワードを推測しにくくするポリシーを使用することです。パスワード・ポリシーには、パスワードの入力に失敗した後のアカウントのロックアウト、パスワードの最小文字数 (強度)、パスワードの期限、パスワードの履歴といったセキュリティー対策を含める必要があります。たとえば、次のようなパスワード・ポリシーを使用します。

  • パスワードの入力に 3 回失敗すると、15 分間アカウントをロックします。これによって、正しいパスワードが見つかるまで何百ものパスワードを短時間に試みるログイン・ルーチンの使用が難しくなります。
  • パスワードの最小文字数を 8 文字にします。
  • パスワードには、数字と記号を含める必要があります。
  • パスワードは 60 日ごとに変更しなければなりません。
  • 10 回前までのパスワードは使用できません。

Lotus Domino 7 には、一定の期間の後でインターネット・パスワードの変更を強制する機能はありますが、Lotus Domino には Web 認証用にすぐに使えるパスワード・ポリシー機能はありません。このパスワード変更の強制は、ログイン・フォームをカスタマイズすることによって、現在のバージョンの Lotus Domino でも使用できます。Lotus Domino 7 では、次回の認証時にユーザー・アカウントをロックして、パスワードを強制的に変更させることもできます。

より強度の高いインターネット・パスワード・ポリシーを実施するために、カスタムの認証 DSAPI フィルターを開発したり、LDAP ディレクトリーに対して認証を実施することができます。ほとんどの LDAP ディレクトリーには、適切なパスワード・ポリシーを実施する機能があります。

認証のタイプ

認証のタイプには 3 種類あり、それぞれが固有のセキュリティー上の弱点を抱えています。基本認証は、ユーザー名とパスワードによる単純な認証です。ユーザーは、ユーザー名とパスワードの入力を求められます。次に、フォーム・ベースまたはトークン・ベースのパスワードがあります。ユーザーは、ユーザー名とパスワードの入力を求められ、セッション Cookie またはセッション・ヘッダーを与えられます。この Cookie またはヘッダーは、システム (または、他のいくつかのシステム) に渡され、これ以降、ユーザーは認証を求められなくなります。セッション Cookie またはヘッダーには、タイムアウト値が設定されています。タイムアウト値を超過すると、ユーザーはユーザー名とパスワードの入力をもう一度要求されます。トークン生成メカニズムまたはヘッダー生成メカニズムが容易に偽造されてしまうと、この方法はセキュリティー問題の原因となります。ハッカーは正しいトークンまたはヘッダーを渡すだけでよく、これによって認証用のユーザー名とパスワードの入力を求められません。

認証メカニズムの 3 番目のタイプは証明書ベースです。これは、ユーザーが Web サイトに x.509 証明書を提供することによって行われます。この証明書はユーザー固有のものなので、ユーザーは認証用の名前とパスワードの入力を求められません。証明書を失う、あるいは盗まれると、ハッカーは認証用のユーザー名とパスワードを入力せずに、この情報にアクセスできます。x.509 証明書を使用してユーザー名を受け付け、さらにユーザーに PIN またはパスワードの入力を求めることも可能です。

Domino Server では、Web ユーザーはユーザー名のさまざまなバリエーションを使用して認証することができます。Domino Server のサーバー文書には、認証用としてユーザーの識別に使用できる情報を定義する設定項目があります。デフォルトの設定は [強いセキュリティで少ない名前のバリエーション] です。この設定では、ユーザーは、完全な階層名、共通名、ユーザー文書のユーザー名フィールドで指定されている任意の別名、インターネット・アドレス、uid のいずれかを使用して認証できます (図 6 参照)。

図 6. 少ない名前のバリエーションと強いセキュリティーによるインターネット認証
少ない名前のバリエーションと強いセキュリティーによるインターネット認証
少ない名前のバリエーションと強いセキュリティーによるインターネット認証

もう 1 つの設定は [弱いセキュリティと複数の名前のバリエーション] です。この設定では、ユーザーは、姓のみ、名のみ、短縮名、共通名、完全な階層名、ユーザー名フィールドで指定されている任意の別名、インターネット・アドレス、uid のいずれかを使用して認証できます。

Web サーバーへのユーザー認証として使用できる方法の数は、セキュリティーに直接影響を与えます。許可される名前のバリエーションが多いほど、辞書攻撃に対して Web サイトが無防備であることを意味します。たとえば、ユーザー名として姓が有効になっていると、大きな企業では「Smith」または「Adams」といったユーザー名は簡単に見つかるでしょう。ハッカーは、一般的な姓を使用して、何度でもサイトへのアクセスを試みることができます。

許可するユーザー名をより厳しく制限することができます。サーバーの Notes.ini ファイルに NABWebLookupView パラメーターを追加すると、ユーザーの識別に使用するビューを制限できます。たとえば、フルネームでソートした ($web) という名前のカスタム・ビューを Domino ディレクトリに作成します。次に、「NABWebLookupView=($web)」というパラメーターを Notes.ini に設定し、HTTP タスクを再起動します。タスクが起動すると、Web サイトへはフルネームでしかアクセスできません。許可する LDAP フィールド名だけをリストするよう認証フィルターを変更することにより、同様の機能を LDAP サーバーに持たせることができます。デフォルトの LDAP 認証フィルターは、「(|(cn=%*)(|(&(sn=%a)(givenname=%z))(&(sn=%z)(givenname=%a))))」です。一般的に、このフィルターによってフルネームによる認証 (例: John Doe) が行われます。

Web サーバーのセキュリティー

セキュリティーの重要な観点として、サーバーの物理的な場所があります。サーバーは安全な部屋に保管する必要があります。この部屋は、電子錠で制御することにより、入退室を制限しなければなりません。電子錠は、実際にドアをロック/ロック解除することと、入退室の記録 (人、日時) を残すことの 2 つの目的を持ちます。権限のないユーザーが物理的にサーバーにアクセスできると、セキュアなデータを入手されたり、サーバーに深刻なダメージを与えられる可能性があります。ISO 17799 (または BS 7799) は詳細なセキュリティー基準です。これは 10 の主要なセクションに分類され、そのうちの 1 つが物理的なセキュリティーのセクションです。

サーバーは、ネットワーク・アクセスに対してもセキュアにする必要があります。これは、物理的なアクセスと同じように重要です。サーバーは、ポートをブロックできるファイアウォールまたはルーターよりも後方に配置しなければなりません。インターネットからサーバーへのアクセスは、ポート 80 と 443 だけをアクセス可能にします。内部ユーザーは、ポート 80 HTTP、443 HTTPS、および 1352 NRPC でのみサーバーにアクセスします。SSH 用に Unix ベースのシステムではポート 22 を、Windows ターミナルサーバーではポート 3389 を開くことが必要なケースもあります。しかし、これらのポートを開くことはお勧めしません。代わりに、サーバー上で直接システム管理タスクを実行してください。どちらのプロトコルも暗号化され、オペレーティング・システムでの認証を使用します。これによって、オペレーティング・システムで直接発生する可能性のあるほとんどの攻撃を防止できます。ポート・アクセスを制限することにより、他のすべてのサービス (ファイル共有など) と FTP への攻撃を防止できます。

ここまでは、サーバーをセキュアにする方法について説明してきました。次に、サーバーをネットワーク・トポロジーのどこに配置すべきかを考慮します。外部 Web サーバーは、エクストラネットまたは DMZ に配置できます。データの複製またはユーザー認証のために、サーバーが内部サーバーにアクセスする必要があるかどうかに応じて、サーバーを配置する場所が異なります。セキュリティーを最大限に高めるには、サーバーをエクストラネットにのみ配置してください。ハッカーがサーバーへのアクセスを得ても、内部サーバーにはまったくアクセスできません。サーバーが内部データにアクセスする必要があり、インターネットからのアクセスも可能にするには、サーバーを内部ネットワークに配置し、リバース・プロキシーを使用することをお勧めします。リバース・プロキシー・サーバーはインターネットからアクセスできる唯一のサーバーなので、リバース・プロキシーを使用すると、ウィルス攻撃とほとんどのハッキング行為からサーバーを防御できます。また、リバース・プロキシーを使用することで、スケーラブルで耐障害性の強いソリューションを得られます。

オペレーティング・システムは、継続的に更新する必要があります。システム管理者は、リリースされるセキュリティー・パッチをチェックし、自社のシステムに適用されるものかどうかを判断しなければなりません。また、セキュリティー・パッチの重要な側面として、オペレーティング・システムによっては、ダウンタイムの計画が必要になることもあります。セキュリティー・パッチを適用するためのダウンタイムを毎週設けることをお勧めします。Windows サーバーではこのメンテナンス時間は必須ですが、Unix ベースのほとんどのオペレーティング・システムでは、Domino Server の稼働中でもパッチを適用できます。ただし、カーネルまたは TCP/IP スタックを更新するパッチだけは、サーバーの稼働中に適用できません。これらのパッチには Unix オペレーティング・システムの再起動が必要です。

サーバーには、オペレーティング・システムと Domino のウィルス・スキャンを行う機能が必要です。この機能によって、送受信するメールにウィルスが含まれなくなります。サーバーに保存するファイルや Domino データベースに保存する添付ファイルには、ウィルスが含まれないようにしなければなりません。ウィルスは、データ破壊、サーバーの可用性の低下、機密漏洩などの原因となるので、これは重要なことです。

データのセキュリティー

オペレーティング・システムとサーバーをセキュアにしたので、ここからは Domino Server 上のデータベースをセキュアにする方法について説明します。データベースの ACL で適切なアクセスを設定することが重要です。システム管理者には [管理者] のアクセス権を割り当て、すべてのユーザーには [編集者] 以下のアクセス権を割り当てる必要があります。データベースへのアクセス権には次のものがあります。

アクセス権ユーザーができること
[管理者]データベースの ACL を変更する。
データベースを暗号化する。
複製設定を変更する。
データベースを削除する。
これ以下のアクセス権で許可されているすべてのタスクを実行する。
[設計者]データベースのすべての設計プロパティを変更する。
全文索引を作成する。
これ以下のアクセス権で許可されているすべてのタスクを実行する。
[編集者]文書を作成する。
すべての文書を編集する (他のユーザーによって作成された文書を含む)。
フォームに [読者] フィールドがない限り、すべての文書を読み込む。ACL で
[編集者] の権限を持っていても、[読者] フィールドで指定されていない場合は、その文書の読み込みと編集はできない。
[作成者]ユーザーまたはサーバーが [文書の作成] 権限も持っている場合は、文書を作成する。ユーザーまたはサーバーに [作成者] のアクセス権を割り当てる場合は、[文書の作成] 権限も与える必要がある。
文書内に [作成者] フィールドがあり、ユーザーがこのフィールドで指定されている場合は、文書を編集する。
フォームに [読者] フィールドがない限り、すべての文書を読み込む。
[読者]文書内に [読者] フィールドがあり、ユーザーがこのフィールドで指定されている場合は、文書を読み込む。
[投稿者]文書を作成する。ただし、パブリック文書の読み込み権限およびパブリック文書の作成権限を持たない限り、アクセス権はない。これらの権限は、設計者が選択して付与できる。
[なし]パブリック文書の読み込み権限およびパブリック文書の作成権限を持つ場合を除き、アクセス権はない。これらの権限は、設計者が選択して付与できる。

システム・データベースへのアクセスを制限することもできます。データベースプロパティの [URL 参照を許可しない] を有効にします (図 7 参照)。これによって、データベースが Web から開かれるのを防止できます。これは、Lotus Domino 6 で導入された機能です。Domino ディレクトリでこのプロパティを有効にしても、ユーザー認証を行うことができます。この機能は、サーバー上の登録済みユーザーを、サーバーの他のユーザーに対して匿名のままにしておく場合に役立ちます。

図 7. [URL参照を許可しない] データベースプロパティ
[URL参照を許可しない] データベースプロパティ
[URL参照を許可しない] データベースプロパティ

webadmin.ntf テンプレートと webadmin.nsf データベースの削除も必要です。これによって、権限のない Web サーバー管理アクセスのリスクを取り除くことができます。The View の 2000年7月/8月版として発行された記事『Building Secure Domino Web Applications: How to Avoid 8 Development Pitfalls That Leave Your Application Wide Open』(著者: Carl Kriger) には、セキュアな Domino Web アプリケーションのためのデータベース開発のベスト・プラクティスが詳しく解説されています。

SSL (Secure Socket Layer)

データへのアクセスをセキュアにしましたが、ユーザーがデータにアクセスできるとき、インターネットを送信されるデータ・パケットがハッカーによってアクセスされるとどうなるのでしょうか。この可能性を排除するために、すべての通信を SSL (Secure Socket Layer) で行うことが重要です。SSL は、エンド・ユーザーと Web サーバー間のネットワーク通信を暗号化するプロトコルです。SSL を使用すると、ユーザーとサーバー間で送信されるすべてのデータが暗号化されます。これによって、暗号化されたセキュアな Web ブラウズが可能になり、転送中のデータにハッカーがアクセスすることを防止できます。

Lotus Domino では、ユーザーは独自の SSL 証明書を作成できます。また、サードパーティから証明書を購入することもできます。サードパーティ製のほとんどの証明書はキーが破壊されないことを保証し、もし破壊された場合はペナルティを支払うことになっています。SSL を使用すると、サーバーとの間で送受信する各データを復号する必要があるため、パフォーマンスに何らかの影響を与えます。大規模な Web サイトでは、SSL アクセラレーター・カードまたは装置を使用する必要があります。

セキュリティーに関するその他の問題

サーバーでは、ハッキングの試みを監視する必要があります。イベントモニターを有効にして、データベースの ACL が変更された際に警告を発生するように設定します。変更が行われると通知されるので、権限のあるユーザーによる変更または計画された変更であるかどうかを判断する必要があります。また、Domino Web サーバーログも有効にしてください。このログを有効にすると、サーバーへの各 GET 要求と POST 要求が記録されます。受信 IP 、要求された URL、および参照元 URL もログに記録されます。サーバーでは、CPU とメモリの過度の使用率も監視する必要があります。これは、DoS 攻撃 (サービス妨害攻撃) や Web サーバーの過負荷の前兆を示すことがあります。

DoS 攻撃は、セキュリティーと安定性の両方への脅威となります。DoS 攻撃は、大量のトラフィックによってサーバーをクラッシュさせることがあるので、Web サーバーのパフォーマンスに直接影響します。Domino Web サーバーへの DoS 攻撃を防止するサードパーティ製の製品があります。これらの製品は、サーバーにアクセスする各 IP を記録します。もし、特定の IP がログインの失敗を繰り返すと、サーバーはこの IP に対して HTTP 要求の処理を停止します。これらのほとんどの製品は、一定の時間が経過すると、サーバーへの IP アクセスを許可します。特定の IP に対する HTTP 要求の処理を停止することにより、ブルートフォース・パスワード攻撃を防止できます。ある IP がアカウントへのアクセスを試み、これが連続してログインに失敗すると、このユーザー IP はサーバーでブロックされます。これは、パスワード・セキュリティーを保護する効果的な方法です。

脆弱性スキャンは、オペレーティング・システムと Lotus Domino の設定の両面で、潜在的なセキュリティー・ホールを見つけるために役立ちます。サーバーの CPU またはメモリの使用率が過度に高い場合は、Domino Web ログをチェックし、DoS 攻撃を受けていないか確認します。

まとめ

この記事では、Domino セキュリティー・モデルの概要を紹介し、単一サーバー環境で Domino Web サーバーをよりセキュアにするための設定方法をいくつか解説しました。これらのヒントは、Domino を用いて運営している Web サイトで、高いパフォーマンス、信頼性、使いやすさをユーザーに提供するとともに、セキュリティーを最大限に高めるために役立ちます。


ダウンロード可能なリソース


関連トピック


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus
ArticleID=340607
ArticleTitle=IBM Lotus Domino Web サーバーをセキュアにする
publish-date=07192005