Iris Today Archives: ノーツ/ドミノ セキュリティー・オーバービュー

実際の問題として、もし大半のネットワーク管理者が固有の方法を用いると、ネットワークはその管理者自身にしかアクセス権限のない、空洞化したものになってしまいます。その代わり、管理者は一意的な方法で Web ユーザーはもちろん、組織内ユーザーのために、サーバーやその中のデータへのアクセスを許可し管理しなくてはならないのです。

Susan Bryant, Application Developer, System Administrator, and Instructor, Lotus

スーザン・ブライアントについて
スーザンは、ロータス ノーツ認定アプリケーション開発者の第一人者であり、同時にシステム管理者、インストラクターでもあります。彼女は6年以上ロータス ノーツ/ドミノ関連の職に就いています。彼女にコンタクトするには smbryant@mediaone.net にメールしてください。



Christie Williams, Content Manager, Lotus

キャサリン・スパンバウアーについて
キャサリンは、メンテナンスに関しての製品マネージャーであり、主にノーツ/ドミノを専門としています。彼女の現在の業務は、顧客の要望の開発へのフィードバック、重大案件の優先順位の決定、ロータスと顧客との間に立って製品の特長を伝達する、などをしています。ロータスに 1992 年に加わってから、さまざまなテクニカル・サポート、プロフェッショナル・サービス、製品マネージメントにおいて重要な役割を担ってきました。キャサリンはウィスコンシン大学で、ビジネス管理の学位を取得しています。



2001年 9月 04日

データへのアクセスの提供、そしてそのアクセスの制御が、企業に向けられている最も大きな挑戦の一つであることは驚くべきことではありません。ネットワークがダウンした場合に発生する悲劇については、私達はよく耳にする話であり、無数の報告を目にしています。これによる結果は、少し厄介に思える程度のものもありますが、ひどいと深刻な痛手を被ることもあり、何百万ドル(あるいは円、フラン、ポンドなど)の損害とサービスの損失、そしてネットワーク保守に携わる人達の失業をもたらすのです。企業データを守る大きな責任をしばしば負わされるネットワーク管理者の挑戦、それは、この見かけ上二分されたアクセスの提供とその制御に釣り合いを持たせることなのです。

幸いにも、ドミノ・ネットワークは、あなたのサーバー、ノーツ・ワークステーション(クライアント)、および、そこに含まれるデータの保護で適用できる必要なセキュリティー機能を十分に提供します。この記事では、ノーツ/ドミノの環境で用意されているセキュリティー機能の概要と、どのようにしてアクセスするべきユーザーへ、シームレスなアクセスを可能にするか、そして、どのようにアクセスすべきでないユーザーに対して、アクセス拒否を可能とするかを見ていきましょう。

ドミノ サーバー:プロバイダーとプロテクター

ドミノ サーバー・ソフトウェアは、正にその名の通りの仕事をします。それは、データをノーツ・クライアント、Web クライアントのどちらか一方、あるいは両方に供給するものです。私達が管理者として正しく作業をする限り、サーバーは保有を許可されている人にのみデータ供給を行ないます。

ここで、まず最初に次のことに注意しなければなりません。

  • ドミノ サーバーが構築される場合、多くのセキュリティー機能のデフォルト設定では、サーバーやアプリケーションへのアクセスを広く開放しています。そのため、ノーツ/ドミノのセキュリティー側面のすべてに渡ってよく理解し、効果的なセキュリティー対策を練ることが重要です。
  • ドミノは、ノーツ・クライアントと Web クライアントとを別々の方法で確認、および認証します。サーバーがこの両者のクライアントにデータを提供するのなら、それぞれがどのように認証されるか、そしてそれぞれに適用できるセキュリティー機能は何かをよく知っておく必要があります。

防御の最前線:サーバー文書
真の防御の最前線は、オペレーティング・システムが安全であることを確実にすることです。この記事では、ドミノはほとんどのオペレーティング・システムのプラットホームでインストールできるため、あなたは既に個々のオペレーティング・システムを安全な状態にしているものとします。

クライアントがドミノ サーバーに要求する際、サーバーが行なう最初のチェックは、クライアントがサーバーへのアクセス権を持っているかどうかの確認です。個々のサーバーでは、次の図のドミノ・ディレクトリーのサーバー文書のセキュリティー・セクションで定義されているような、セキュリティー設定がされています。

The Server document
The Server document

これらの欄への入力(ワイルド・カード入力と同様にユーザー名、グループ名)は、サーバーの安全確保へと繋がるものです。これらの設定は、さまざまなセキュリティー機能と同様に、誰がサーバーへアクセスできるのか、誰がサーバーへのアクセスを拒否されるのか、クライアントがどのように認証されるか、そして誰がエージェントを実行できるか、などを制御します。これらの設定(多くはこの記事内で話題になりますが)は、まさにドミノ サーバーの防御の最前線となりますので、よく慣れ親しんでおくことが重要です。

認証
サーバー文書のフィールドは、クライアント認証の際に重要になります。ノーツ・クライアントとブラウザー・クライアントが異なる能力を持つために、それぞれへの認証の仕方もまた異なります。まず最初にノーツの認証を見てみましょう。

ノーツ・クライアント認証
ノーツ・ユーザー ID ファイルは、ユーザーがドミノ サーバーに自分の身元を確認するために必要な全ての情報を含んでいます。それらはユーザー名、パスワード、そして組織の適切な証明書です。サーバーに接続する前に、ユーザーは正しくパスワードを入力しなくてはなりません(後述のノーツ・ユーザー ID とパスワードのセクションで、ユーザー ID とパスワードについての詳細をご覧ください)。そしてドミノ サーバーとの接続を成立させるために、ID に保存されたすべての証明書がサーバーに送られます。サーバーはこの証明書とドミノ・ディレクトリー内の対応する証明書とを対応させ、クライアントが有効であることを確認します。クライアントの有効性が認識されなければ、アクセスは拒否されます。

クライアントが確認されると(つまり、証明書が信用されると)、認証過程はワークステーション(クライアント)とサーバー間でチャレンジ/レスポンス・ダイアログを成立させることでユーザーの正当性を証明します。同様の確認/認証作業は、2つのサーバー間で、複製やメール経路指定のために接続が試みられる場合にも行なわれます。簡単に言えば、サーバーとワークステーション(あるいは2サーバー)間では、暗号化された乱数の交換が行なわれ、ID やドミノ・ディレクトリーに保存されたパブリック・キー(公開鍵)を使ってそれらが復号化され、送り返されるという作業が行なわれているのです。

ユーザー名はユーザー文書、グループ文書、サーバー文書のアクセス・フィールドで照合されます。そしてユーザー名がこれらのテストを合格しなければ、サーバーへのアクセスは拒否されます。もし全てがうまくいけば、クライアントは有効と確認され、かつサーバー文書におけるさまざまなフィールドの事項においてもアクセスを拒否されなければ、クライアントは晴れてアクセスできるのです。

セッションがいったん確立すれば、セッション中のユーザーは ID がロックされない限り、再び身元確認を催促されることはありません。ID のロック(およびセッションの開放)は F5 キーを押すことで手動で行うことができます。または、ユーザー ID をユーザー・プリファレンス・ダイアログ・ボックスで設定して、一定時間のアイドル状態の後にロックする(およびセッションの開放)ようにすることも可能です。セッションを再開するには、パスワードを再入力する必要があります。ID をロックすることは、あなたがマシンを離れた時に他人にあなたの名義で利用されることを防ぎます。

特別なノーツ・クライアント認証シナリオ
ノーツ・クライアント認証の過程は、サーバー文書のフィールドの設定によって変化を持たせることができます。

  • 匿名アクセス(Anonymous access) 前述の通り、認証過程ではノーツ ID の証明書とドミノ・ディレクトリーの証明書とを照合します。しかしながら、証明書を持たないあなたの組織以外のユーザーやサーバーに対しても、自分の所のサーバー上のデータベースへアクセスさせたい場合もあるでしょう。例えば、あなたの顧客用のディスカッション・データベースがあるとします。全ての顧客組織の全ユーザーに対し相互認証を行なうのはやり難いし、またデータベースの情報は秘密に扱うものではないですから、その必要性もないでしょう。サーバー文書内の「匿名でのノーツ接続を許可」欄を埋めることで、この非認証アクセスが可能になります(サーバーのさまざまなデータベースへのアクセス制限は、個々のデータベースの「アクセス制御リスト」で制御します。詳しくは後述の、データベース・アクセス制御リストをご覧ください)。認証されていないユーザーは、「匿名(Anonymous)」というアクセス・レベルにありますが、匿名アクセスを受け入れていない場合、デフォルト状態のアクセス権がこれらのユーザーに適用されます。
  • パスワード・チェック(Password Checking) ユーザーが正規の基準でパスワードを変更しているか確かめるために、サーバー文書内の「パスワード・チェック」欄を使ってチェックを行うことができます。この場合、ユーザーは決められた期間内にパスワードを変更しなくてはならず、でなければ、認証過程においてサーバーからアクセスを拒否されるようになり、管理者に頼んで復旧手続きを取ってもらわなくてはなりません。パスワード・チェックの管理について、詳しくは Iris Today の記事、パスワード・チェックをご覧ください。

Web クライアント認証
Web クライアントはノーツ ID を持たないため、照合作業は異なった方法で行なわれます。ブラウザー・クライアントがサーバーに接続する際(ノーツ・クライアントも同様です)に、認証を行なう代わりに、ブラウザーが匿名でアクセスできないサーバー(サーバー文書内の [ポート] - [インターネット・ポート] タブ経由で)や、匿名アクセス、あるいはデフォルト・アクセスが、アクセス禁止に設定されたサーバーのデータベースへアクセスを試みる際に認証が発生します(もしデータベースのアクセス制御リストが匿名によるアクセスを許可するか、あるいは読者以上のデフォルト・アクセス・レベルを持つ場合には認証は行なわれず、誰でもデータベースにアクセスできます)。

しかしながら、もしサーバーやデータベースが安全に守られている場合、クライアントはデータにアクセスする際に、名前とパスワードを入力することを求められます。この情報は、与えられた名前とパスワードをドミノ・ディレクトリーのユーザー文書、そしてその文書中のインターネット・パスワードと照合することで確認されます。もしも名前とパスワードがユーザー文書内のものと一致しないと、アクセスは拒否されます。

この名前とパスワードは、パケット・ヘッダーに保存され、サーバーへ確認のために送られます。これらの情報は、明らかにスニッファー(sniffer)やトレース・ツールを持つ人によって傍受されます。またユーザー名、パスワードの情報は、ブラウザー上にキャッシュされます(これにより情報を何度も入力する必要がなくなります)。このキャッシングにより、セッション中にユーザーがマシンから離れ、無人のままにしておくと、誰にでもそのユーザー自身の身元が利用されてしまいます。ユーザーは、この危険性を十分に認識しておかなくてはなりません。共同利用や公共のマシンを利用する際には、確実にブラウザーを閉じてからセッションを終了してから、マシンから離れることが重要です。 したがって、極秘の情報を保護しながら Web 上にあなたのサーバーやアプリケーションを公開するには、どのようにすれば良いのでしょうか? Web 標準、あるいはその方法を用いると良いでしょう。

ドミノ サーバーはパブリック・キー証明書としてインターネット X.509 規格をサポートしています。これらの証明物は SSL や S/MIME(後述の安全なメッセージング・セクションで説明します)での安全なインターネット配信に用いられています。加えて、インターネット・プロトコルにおけるノーツ・クライアント・サポートは、SSL 上の他の Web サーバーとのトランザクションを保証するために、X.509 証明書をあなたの ID ファイルに保存させることができます。また、S/MIME を利用するインターネット・メール・ユーザーのメールを署名し、暗号化させることも可能です。

サーバー・アクセスの制御
ノーツ・クライアント認証の過程で、ドミノはサーバー文書内の「サーバーへのアクセス可」フィールドをチェックし、ユーザー(あるいはサーバー)にアクセス権があるかどうかを確かめます。例えば、「このディレクトリーに登録されているユーザーのみにサーバー・アクセスを許可」を「はい」に設定すると、そのドミノ・ディレクトリーに登録されているユーザー、グループ、サーバーのみにアクセスを限定します。これを「いいえ」に設定すれば、他のドミノ・ディレクトリーに登録されているユーザー、グループ、サーバーにアクセスさせることができます。「サーバーへのアクセス可」フィールドにより、サーバーにアクセスできるユーザー、グループ、サーバーを特定したり、新しいデータベースやそのレプリカを作ったりすることができます。(これらの設定は、インターネット・プロトコル経由でアクセスするクライアントには適用されません。インターネット・ユーザーを認証するためには、ドミノ、ないし LDAP ディクトリー内にある、ディレクトリー・アシスタンス経由で設定されたユーザー文書が必要となります。)

Server Access fields
Server Access fields

サーバー文書には、パススルー・サーバー用に、これと似たアクセス可/不可の設定があります。

セキュアーなサーバー・ポート
ユーザーがサーバーへのアクセスのために利用するネットワーク・ポートの全ては、さまざまなセキュリティー規格を用いて安全を確保することができます。加えて、ノーツ・クライアントは、個々のポートのネットワーク・トラフィックを暗号化することができます(後述のクライアント・ポートの暗号化のセクションをご覧ください)。

先に概説した全般的なサーバー・アクセスに加えて、ドミノ サーバーにおける個々の LAN ポートは、ノーツ・プロトコル上のネットワーク・トラフィックを暗号化するよう設定できます。これはドミノ管理クライアントの[サーバー]タブにある [ツール] - [サーバー] - [ポートの設定] を用いることで可能です。

Web 上を往来するデータは傍受され得るために、機密トランザクションないしデータの安全を確保することがしばしば必要になります。ドミノ サーバーは Web から送られてくる要求をよりよく保護するために、全てのインターネット・ポートへの SSL ポート暗号化をサポートします。SSL(Secure Sockets Layer)は、インターネットのトラフィックにおいてプライバシーと認証を提供するセキュリティー・プロトコルです。これらの SSL 設定はサーバー文書において定義することも可能です。

Securing Internet ports
Securing Internet ports

SSL 認証は、ノーツ認証とよく似ています。SSL クライアントは、ドミノ サーバーに証明書を提示します。すると、サーバーはこれを使ってクライアントを認証します(逆の操作も同様に行なわれます)。ノーツやドミノと違い、SSL はサーバーとクライアントが相互に認証を行なうことを要求しません。SSL が有効であれば、ドミノはクライアントがサーバーを認証することを要求します。しかしながら、サーバーにクライアントを認証させることは任意となります。SSL は、X.509 形式でのインターネット証明書を利用しています。この形式は、ドミノを含むほとんどのアプリケーションがサポートする工業規格形式です。ドミノ サーバーは、公共の、あるいは外部の認証機関(Verisign、GTE、Thawte、など)の署名を持つサーバー証明書を用いることもできますし、ドミノ サーバー自身が認証機関となることもできます。

ドミノ サーバーは、Web 仮想ホスト、または仮想サーバーとして稼働することができます。ドミノ R5 における仮想サーバーは、それぞれが独自の SSL 設定を行うことができます。またドミノ サーバーは、さまざまな規格を持つメール・クライアントにメールを送ったり、ネットワーク・ニュース・サーバーや LDAP サーバーとして稼働することができます。これらのタスクを実行するためのポートの一つ一つを、安全に守ることができます。

Port options for mail
Port options for mail

他のサーバー・セキュリティー検討事項
サーバー・セキュリティーに関して幾つか他に検討する事項があります。

サーバー管理を制御する
ドミノ サーバー上での管理業務は、リモート・サーバー・コンソールの利用によってより容易になりました。管理者は、Web ブラウザー、またはドミノ管理クライアントを使って、ほぼ全ての Windows NT マシンから設定を変更したり、状況を観察したり、あるいはドミノ サーバーを再起動したりすることができます。この責任は非常に重大なものとなり、この特権のセキュリティーは厳しく管理されなくてはなりません。ドミノは、ドミノ管理クライアントか、あるいは Web ブラウザーの一方からリモート管理することができる、サーバー文書での別々の設定を提供しています。

攻撃に備えサーバーをモニターする
ドミノ サーバー・ログ(log.nsf)は、サーバーで何が起こっているかの実況報告をします。このデータベースのクイック探索をすれば、セキュリティーか、あるいはアクセス面で懸念があった場合に教えてくれます。サーバー・コンソールもまた、サーバーでの出来事をリアルタイムで報告しますが、サーバー・コンソール上の出力をひたすら眺めているような暇は管理者にはありません(それが仕事になれば、話が変わりますが....それでもなお退屈なものです)。

より効果的なのは(効率的とは言えませんが)、Collect と Event(Event Dispatcher)サーバー・タスクを使って、サーバーやデータベースへのアクセスを試みたが失敗したケースをモニターし、問題を知らせる方法です。あなたは別のデータベースに情報を収集して、管理者に知らせるようサーバーを設定したり、管理者にメールを送ったり(もちろん、適任の技術者を呼び出すよう設定することもできます)、あなたのネットワークに SNTP トラップを作ったり、UNIX システム・ログ、ないし NT イベント・ビューアーに記録したり、別のサーバーへ中継したりできます。

Open Server URL コマンドを無効化する
特別な URL、http://myserver/?OpenServer は、サーバー上の全てのデータベースへのアクティブ・リンクを持つページを作ります。この全てのデータベースへのリンクのリストは、Web サイトに従事する管理者およびアプリケーション開発者にとっては便利で使いやすいものですが、一般のユーザーに公開するのは不適当です。しかしながら、サーバー文書で Open Server URL コマンドを制御する設定である「HTTP クライアントからのデータベース参照を許可」は絶対的なものです。どのユーザーがデータベースを見られるか、どのデータベースがリスト上に現れるか、を制限する方法はないのです。

サイトのセキュリティーを確かなものにするために、「HTTP クライアントからのデータベース参照を許可」欄を「いいえ」にして OpenServer URL コマンドを完全に無効化することができます(Iris Today の記事 OpenServer URL コマンドに代わるエージェント・スクリプトでは、サーバー上のデータベース・リストにアクセス可能なユーザーを指定できるエージェントについて説明しています)。


クライアントの安全

クライアントの安全を確保するのは、サーバーの安全を確保するのに負けず重要なことです。あなたはノーツ・クライアントと Web クライアントが、サーバーとの間でどのように認証を行なっているかを見てきました。それに加えて、さらにクライアント関連のセキュリティー機能があるのです。

ノーツ・ユーザー ID とパスワード
ノーツ・クライアントの安全を確保することの最前線は言うまでもなく、ユーザー ID とパスワードです。ノーツ・クライアントが登録されると、ユーザー名と組織の適合した証明書がノーツ・ユーザー ID ファイルに保存されます。個々のユーザーに対応する証明書もまたドミノ・ディレクトリーに保存されます。ID が登録中に作られると、パスワードに加えてその複雑さ、すなわちクオリティー(品質)を定義することができます。高いクオリティーのパスワードは、低いクオリティーのものよりも安全です(詳しくは Iris Today の記事、パスワード・クオリティーを理解するをご覧ください)。

パスワードを用いて ID を保護することは、パスワードなしでは ID を使ってドミノ サーバーにアクセスはできない、と言うことです。ノーツ・クライアントが起動されると、ユーザーはこの ID 用のパスワードを要求されます。これがなくては、ノーツ R5 をはじめとするノーツ・クライアントは起動できないのです。ノーツ・クライアントの全てのリリースにおいて、ID に対応したパスワードがなくてはクライアントはドミノ サーバーにアクセスできないのです。

安全なメッセージング
ノーツは電子メール・メッセージに署名し、暗号化することができます。これは S/MIME プロトコル、X.509v3 証明書を使った他のインターネット・メール・ユーザー宛のものと同様に、ノーツ・プロトコルと証明書を使って、他のノーツ・ユーザー宛に送ることもできます。この両方の方法は RSA 社が開発したパブリック・キー・テクノロジーに基づいています。

もしあなたが、あなたの保守するネットワークやイントラネット内で電子メールを送るならば、その署名と暗号化は必ずしも必要ではありません。しかし、あなたのメッセージがインターネット上を通るのであれば、経路上の各ホップ(hop)で常に必要なセキュリティー警戒が取られる保証はありません。したがって、あなたのメッセージの機密性、認証、整合性を確かに保証する方法は、メールを確実に暗号化し、署名することです。

電子メール・メッセージを送る時、メール・ファイルの送信オプションでメールへの署名、暗号化を行なうかを選択できます。他のノーツ・ユーザーへメールを送る場合、ノーツ固有の署名と暗号形式が使われます。一方、インターネット・ユーザーに送る場合、S/MIME が使われます。また、ユーザー・プリファレンス・ダイアログ・ボックスにおけるデフォルト設定により、全ての送信済メッセージと暗号化して保存されたメッセ?ジに、署名または暗号化することができます。加えて、ユーザー文書内のフィールドを使って、新たに入ってくるメッセージを暗号化できます。ルーターがメールをあなたのサーバーに配信する時に、あなたのノーツ・パブリック・キーを使ってメッセージが暗号化されるのです。

暗号化したメッセージを送信する際、あなたは受信者側のパブリック・キーを入手して、そのキーでメッセージを暗号化する必要があります。多くの場合、これらのキーはドミノ・ディレクトリー、あるいは LDAP ディレクトリーに保存され、そこから取り出します。しかしながら、外部の組織にメールを送る際、パブリック・キーを持つディレクトリーへのアクセスができない場合もあります。この場合、簡単な方法としては、ユーザー同士で S/MIME で署名されたメールを送受信し、送信者のキーを個人アドレス帳にコピーする方法([ツール] - [送信者をアドレス帳に追加] を選択)があります。ドメイン外のユーザーとノーツ・パブリック・キーを交換するには、ユーザー ID ダイアログ・ボックスにある、[オプション] パネルの [パブリック・キーの送信] ボタンを使います([ファイル] - [ツール] - [ユーザー ID] と選択)。ノーツは、まずあなたのアドレス帳で証明書をチェックし、ホーム・サーバーのドミノ・ディレクトリー、そして最後にディレクトリー・アシスタントにより構成されたディレクトリーを調べます。受信者がメッセージを開く時、彼らのプライベート・キーで復号化されます。ノーツは、プライベート・キーをユーザー ID ファイルに保存しています。

ノーツではまた、デジタル署名を使ったメッセージへの署名ができます。メッセージは送信者のプライベート・キーによって署名されます。署名されたメッセージは、その送信者のパブリック・キーの信頼性を保証する証明書を添えて送信されます。証明書が信頼できる認証機関から発行されている限り、受信者は送信者のパブリック・キーの添付された署名を確認できます。

S/MIME を使って署名、あるいは暗号化されたメールを送信するには、あなたがノーツ・クライアント、あるいは S/MIME 準拠のメール・クライアントのどちらを使用していても、信頼できる認証機関から X.509 証明書を入手しておく必要があります。

操作制御リスト
操作制御リスト(ECL)は、JavaScript や Java といった外部のプログラムやノーツ式にセキュリティー規制を課しています。データベース管理者とシステム管理者は、ユーザーの個々のワークステーション(クライアント)に ECL を作り、テンプレートやデータベースに署名することで、それらを不正アクセスから保護することができます。ECL は、プロシージャー(procedure)を署名した者によって、データベースに組み込まれたプロシージャーがデータベース内やクライアント上で行なえるタスクを決定します。例えば、あなたは、ドミノ・システム管理者へは限られた実行アクセス権を与えますが、未署名のスクリプトや式へは実行アクセス権を許可しない、ということが可能です。

個々のユーザーは、彼らの ECL を編集して、彼らのセキュリティーのニーズを充たすことができます(管理者がその機能を無効化しない限り)。ユーザーの ECL オプションは、ワークステーション・セキュリティーにあります。操作制御リスト(ECL)ダイアログ・ボックスは、ユーザー・プリファレンス・ダイアログ・ボックスの [基本] パネルからアクセス可能です。

Workstation Security: ECL dialog box
Workstation Security: ECL dialog box

付け加えると、管理者は管理 ECL を作ることができます(もとい、作るべき)。これはドミノ・ディレクトリーに保存され、システム管理者が新しいユーザーを登録する際にユーザーのワークステーションにコピーされます。この機能は、企業内を通してのワークステーション・セキュリティーの標準化を促進します。

ノーツ・ワークステーション ECL は、次の項目を制限できます。

  • ファイルへのアクセス
  • カレント・データベースへのアクセス
  • 環境変数へのアクセス
  • ノーツ以外のデータベースへアクセス
  • 外部コードへのアクセス
  • 外部プログラムへのアクセス
  • メールの送信
  • 他のデータベースの読み込み
  • 他のデータベースの修正
  • データの書き出し
  • ECL へのアクセス

ノーツ内で Java アプレットが実行されると、そのアプレットに一定のセキュリティー制限が課せられます。このセキュリティー・モデルは、アプレットが行なえる動作、アクセスできるシステム・リソースを見極めることで、悪質なコードに対抗します。これらの制限は、署名をひとつひとつ行なってカスタマイズできます。Java ECL は、次の項目を制限できます。

  • ファイルへのアクセス
  • ノーツ Java クラスへのアクセス
  • ネットワーク・アドレスへのアクセス
  • 印刷
  • システム・プロパティーへのアクセス
  • ダイアログ、クリップボード・アクセス
  • プロセス・レベル・アクセス

JavaScript ECL オプションは、ノーツ・クライアント内で動作する JavaScript のセキュリティーを制御します。ここでのノーツ・クライアントは、ノーツ・ブラウザーで表現された Web ページ、ノーツ・フォームの両者を指します。JavaScript がノーツ・クライアントに組み込まれていても、これらのオプションは、他のブラウザー(Microsoft Internet Explorer など)が動かすJavaScript は制御しません。

Window オブジェクトの3つのクラスの読み書きオプションのセキュリティーを、互いに独立して制御することができます。

  • ソース window (Source window)
  • 同一ホストからの window (Other window from same host)
  • 異なるホストからの window (Other window from different host)

ECL には、さらに2つのオプションがあります。ノーツ・クライアントで実行される JavaScript が Web ページ、ノーツ文書のどちらを新たに開くことができるかについてです。

ECL について詳しくは、Iris Today の記事 R5.0.2 のECL 仕様変更によるセキュリティー強化をご覧ください。

クライアント・ポートの暗号化
ユーザーは、ユーザー・プリファレンス・ダイアログ・ボックスの [ポート] パネルを操作して、ネットワーク・データを暗号化することができます。これはクライアント、サーバー間転送におけるデータを保護し、そしてサーバーがポート暗号化を無効化しているときに便利です。この設定は、片側の全てのトランザクションを暗号化するだけで可能です。ポート暗号化については、前述のセキュアーなサーバー・ポートのセクションをご覧ください。


アプリケーションの安全

ドミノ サーバーへのアクセス制御が解決したら、管理者はアプリケーション設計者と協力して、ユーザーがアクセスできるのは何のデータかを決める必要があります。ドミノは、アプリケーション内のデータに対して、非常に細かなセキュリティー制御をかけることができます。これは、データがノーツ/ドミノ・データベースに保存されたり、あるいは個々の HTML ファイル内に含まれたりしても変わりありません。

データベース・アクセス制御リスト
アクセスがサーバーに許可されれば、サーバーはデータそのものへのアクセスをチェックします。もし要求されたデータがノーツ/ドミノ・データベースに含まれていれば、そのデータベースへの最初のアクセス・ポイントはアクセス制御リスト(ACL)です。

The Access Control List
The Access Control List

アクセス制御リストは、個々のドミノ・データベース・アプリケーションへのアクセスを制御します。クライアントのアクセス・レベルは、個々のアプリケーションによって異なる場合があります。あるいは、管理者はユーザーのグループを作ってそのグループにアクセスを指示することで、より包括的にアクセスを制御することもできます。適切にアクセス制御リストを設定して、アプリケーションへのアクセスの制御を行なうことについては、数多く述べられています。Iris Today 記事 The ABCs of using the ACL(US) と R5 システム管理ヘルプをご覧ください。

アクセス制御リストの利用法について、完全に理解しておくことは重要です。というのは、それはノーツ/ドミノ・データベースへの最初のアクセス・ポイントとなるからです。

ファイル・システムへのアクセス制御
オペレーティング・システムの安全を確保した後、もしドミノ サーバーが Web 上で開いているならば、ノーツ・データベースではない、サーバー上の特定のファイルへのアクセス設定を必要とするかもしれません。これは、特にドミノ HTTP サーバーがディスク上の HTML ページを供給する場合に言えることです。ノーツ/ドミノ・データベースほど、ファイル・システム・ファイルへのアクセス制御は細かくではありませんが、ドミノは全般にわたる制御を行ないます。ドミノは、GET と POST メソッドの標準 HTTP セキュリティーをサポートします。

R5 では、ドミノ・ディレクトリーのサーバー文書においてこの制御の設定をします。それは、[Web] アクション・ボタンをクリックし、[ファイル保護の作成] を選んでそのサーバーのファイル保護文書を作成します。この文書の [アクセス制御] タブでは、サーバー上のファイルのアクセス制御リストの設定、または変更ができます。

Access control list for files on server
Access control list for files on server

セキュリティー関連のデータベース・プロパティー
ローカル・データベースの暗号化
空港であなたのノート・パソコンが盗まれたら、DVD プレーヤーが無くなったと憤慨するかもしれません。しかし、ノート・パソコンにおいて最も重要なものは、ハードウェアでもソフトウェアでもなく、データです。ローカルに保存されたノーツ・データベースは、初期設定において、簡単にアクセスして開くことができます。これはサーバーやその設定の保護下に無いからです。極秘扱いの情報を含むデータベースは、ユーザー ID によって暗号化できるので、その ID のパスワードを知る人だけアクセスできるようになります。

データベース・プロパティー・ボックスの暗号化設定を利用することで、どんなユーザーID またはサーバー ID ででも、ローカル・データベースを暗号化することができます。この機能は、主にワークステーションのために開発されました。ワークステーション、特にノート・パソコンの物理的なセキュリティーは、サーバーのそれよりもしっかり制御できないからです。しかし、あまり一般的ではないにせよ、サーバー上のデータベースもサーバー ID によってローカルで暗号化することができます。より効果的にするために、データベースを守るために使われた ID は、パスワードで保護されなくてはなりません。

SSL 接続の要求
どのようなデータベースでも、Web アクセスの SSL 接続を要求して、特定のデータベースに SSL の利用を強く求めることができます。サーバーは、どのようなデータベースに対しても SSL セキュリティーの利用を認めるので、例えば極秘扱いのデータを持つデータベースなど、一部のデータベースに SSL を適用すれば効果的です。

設計要素を使ってデータへのアクセスを制御する
ドミノはデータベース内のデータを守るために、豊富なセキュリティー要素のパレットを持っています。さまざまな設計要素、フォーム、ビュー、エージェント、フィールドなどを使い、ノーツ/ドミノ・データベースにおいてデータは加工されたり、追加されたり、アクセスされたりしています。多くの設計要素はセキュリティー機能を備えているため、管理者またはデータベース設計者が、設計要素や設計要素によって作られたデータへのアクセスを制御できるようになっています。これらのデザイン要素については R5 デザイナー・ヘルプをご覧ください。

ビュー・プロパティー
ビュー・プロパティー・ボックスのセキュリティー・オプションにおいて、管理者ないし設計者は、誰(個々のユーザー、グループ、あるいはあるロール(role))がビューへアクセスできるかを定義することができます。しかし、ノーツ・クライアント・ユーザーは、ビュー・アクセス・リストを回避するために、個人ビューを作ることができます。さらに読者名フィールドのように、文書へのアクセスを制御するようにするべきです。

フォーム・プロパティー
文書を読む、作成する、あるいは編集するユーザーを、特定のフォームに基づいて制御することができます。それは、そのフォームの設計で、アクセスを必要とするユーザー、グループ、ロールのリストを指定することでできます。もし、リストにそのユーザーの名前が無い場合、それが個人にしろ、グループやロール・リストのメンバーにしろ、文書の作成や編集はおろか、作成メニューにリストアップされたフォームを見ることすらできません。(このやり方により、面倒なアクセス拒否メッセージを受信することがなくなります。)

フィールド・プロパティー
加えて、設計者は、少なくとも ACL(アクセス制御リスト)で編集者レベルのデータベースへのアクセス権限を持つユーザーだけに、フィールドを編集する能力を制限することができます。これは、フィールド・プロパティー・ボックスの [詳細] タブで設定できる、編集可能フィールドのセキュリティー・オプションの一つです。

作成者と読者フィールド
文書の作成者フィールドは、ユーザーが ACL で作成者レベルでしかデータベースにアクセスできない場合に、一度作成された文書を編集できるユーザーを制御します。設計者は、このタイプのフィールドへの入力値をハードコードし、このフィールドに何の入力値が入れられるかを決定する式を作成し、あるいはフィールドを編集可能にし、そしてアプリケーション・ユーザーに文書を編集できるユーザーのリストを決めさせることができます。このうち後者は、個々のプロジェクトや文書に独自の編集者グループが必要であり、そして、そのグループが文章作成後に決定されるような共同作業の環境で、アプリケーションを利用する場合には便利です。

読者タイプのデータ・フィールドは、一度作成された文書を読み込むことのできるユーザーを決める際に使われます。読者フィールドは、ACL における設定を洗練し、また覆すこともできます。例えば、ACL において管理者レベルでデータベースにアクセスできる人でも、文書の読者フィールドにその人の名前が無ければ、その管理者は文書を読み込むことができないのです。ユーザー名が読者フィールドに無い場合(そしてそのフィールドに少なくとも一人以上の入力値があれば)、文書はいかなるビューでも見ることすらできません。これは大変強力な文書のセキュリティー能力です。たとえユーザーがしっかりと ACL へアクセスをしてデータベースを開いて読んだとしても、その中の全ての文書にアクセスし閲覧することはできないこともあるのです。

アクセス制限されたセクション
文書上のデータの一部分を、アクセス制限付きセクションとして「囲う」ことができます。このセクション内でデータを編集できるユーザーをリスト化することは、このセクションの内容の変更を他の人から防ぐことができます。同じ文書内の他の部分を編集できるユーザーでさえ、編集することはできません。彼らはこの範囲の閲覧は可能でも、編集はできないのです。セクションは、ユーザーの現在のモード(読み込み、編集、など)、ユーザーの持つクライアントの種類(Web ブラウザー、あるいはノーツ)によって非表示にされたり、展開されたり、あるいは省略されたりします。アクセス制限付きセクションへのアクセス・リストは、ハードコード、もしくはプログラムにしたがって制御することができます。

署名された文書とフィールド
デジタル署名は、文章全体、または文章内の特定のフィールドに書き添えることができます。デジタル署名は、手書きの署名を電子化したものに相当します。これは、あなたの身元を証明する独自のテキストであり、メッセージに添加されます。またこれは、送信者の身元とメッセージの身元を確認するのに利用できます。このテキストは、パブリック・キーとプライベート・キーを使って暗号化と復号化が実施されます。

フォーム上の署名可能なフィールドは、文書が保存、ないしメールで送信された時にデジタル署名を添付します。デジタル署名は、作成者自身が本人であるという主張と、文書内の情報が改ざんされていないことを証明します。ユーザー ID ファイルのプライベート・キーが署名を作成します。ユーザーが署名されたフィールドを含む文書を開くと、ノーツがドミノ・ディレクトリーにある作成者のパブリック・キーを比較して、ユーザーの署名を確認します。署名可能なフィールドがフォーム上のセクションにあると、文書が開かれた時に署名が確認可能ならば、署名がセクションの先頭に現れます。

再び文書の署名は、(ノーツ・ユーザー ID 内に保存されている)ユーザーのプライベート・キーを使って行なわれ、署名の証明はドミノ・ディレクトリーに保存されたユーザーのパブリック・キーとの比較で行われることがら、フィールドや文書の署名( 電子メールを含む)は Web クライアントでは利用できません。

フィールドの暗号化
フィールドのデータは、暗号化キーを使って暗号化できます。このキーはユーザーによって作成され、電子メール(これもまた暗号化される必要があります)経由か、あるいは書き出し(exporting)、配布、そして呼び出し(inporting)の手順により配布されます。このキーは、ユーザー ID 内に保存されます。暗号化されたフィールドを含む文書が読み込みや編集のために開かれた時、ユーザー ID 内に必要なキーがあれば、文書内のそのフィールドは復号化され、データを閲覧することができます。この作業は、文書にアクセスするユーザーを困らせないように、完全にシームレスに行なわれます。

暗号化されたフィールドは、文章が開かれるまでは復号化されないため、ビューには表示されません。このデータはビュー内の文書プロパティーから閲覧する事ができず、非表示式とは違い、真のセキュリティーを提供しています。暗号化されたフィールドは Web クライアントでは読むことができません。というのは、必要とする暗号化と復号化のキーが Web クライアントで利用することの無いノーツ・ユーザー ID に保存されているからです。フィールド暗号化に関して、詳しくは Iris Today の記事、アプリケーションでのフィールド暗号化の利用をご覧ください。

非表示を使う
非表示式を使うことで、特定のユーザーに文書中のテキスト/データ・フィールドの一部分を見えないようにすることができます。非表示はセキュリティー要素には分類されないものの、"不明瞭さによるセキュリティー" ということで機能することも可能です。これは安全ではありますが、確実ではありません。非表示式によって隠されたデータは、ノーツ・クライアントの文書プロパティーにアクセスすることで文書やビューから見られます。したがって、ユーザがこの能力を知らないだけ "安全" なのです。フィールドやデータを隠すことは、エージェント、アクション、他のプログラム的アクセスによるデータ改ざんを防ぐことにはなりません。しかしながら、式に定義される状態に応じて、設計者に選択的にデータを表示(または非表示)させられる意味ではいい機能です。Iris Today の記事、非表示(Hide-when)の隠れた秘密を明かすに、非表示式についてより詳しく述べています。

編集モードを防ぐ
文書は、プログラミング的に編集モードにすることを防げることができます。これは、ユーザーが例え適切な ACL と文章へのアクセス権を持っていても、クライアント内で開かれるために、別のセキュリティー・レベルを設けることで可能になるからです。編集モードのプログラムによる制御は、エージェントやアクションによるデータ改ざんは防げませんが、しかし設計者に別の方法で文書とそのデータの操作を制御できます。


ノーツとドミノ:豊富なセキュリティー・オプション

ノーツ/ドミノは、ネットワーク管理者に完全なセキュリティー・オプションを与えます。これにより、インターネット上を往来するデータと同様に、管理者が守るサーバーとデータがアクセスされるべきユーザーに公開され、その必要の無いユーザーからは守られるように安全を確保するのです。これらのオプションのほとんどは、あなたの独自のネットワーク上で設定可能です。ノーツ・クライアントもローカル・アクセスの安全を守り、また、あらゆるデータベース内の全て、または一部のデータへのアクセスの制御には数限りなく方法があります。まとめると、これらの機能はセキュリティー・オプションの富を与え、あなたの立場に対し上手く適したものを選ぶことができるのです。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Lotus
ArticleID=334730
ArticleTitle=Iris Today Archives: ノーツ/ドミノ セキュリティー・オーバービュー
publish-date=09042001