実際の問題として、もし大半のネットワーク管理者が固有の方法を用いると、ネットワークはその管理者自身にしかアクセス権限のない、空洞化したものになってしまいます。その代わり、管理者は一意的な方法で Web ユーザーはもちろん、組織内ユーザーのために、サーバーやその中のデータへのアクセスを許可し管理しなくてはならないのです。
ノーツ・クライアント認証
ノーツ・ユーザー ID ファイルは、ユーザーがドミノ サーバーに自分の身元を確認するために必要な全ての情報を含んでいます。それらはユーザー名、パスワード、そして組織の適切な証明書です。サーバーに接続する前に、ユーザーは正しくパスワードを入力しなくてはなりません（後述のノーツ・ユーザー ID とパスワードのセクションで、ユーザー ID とパスワードについての詳細をご覧ください）。そしてドミノ サーバーとの接続を成立させるために、ID に保存されたすべての証明書がサーバーに送られます。サーバーはこの証明書とドミノ・ディレクトリー内の対応する証明書とを対応させ、クライアントが有効であることを確認します。クライアントの有効性が認識されなければ、アクセスは拒否されます。
セッションがいったん確立すれば、セッション中のユーザーは ID がロックされない限り、再び身元確認を催促されることはありません。ID のロック（およびセッションの開放）は F5 キーを押すことで手動で行うことができます。または、ユーザー ID をユーザー・プリファレンス・ダイアログ・ボックスで設定して、一定時間のアイドル状態の後にロックする（およびセッションの開放）ようにすることも可能です。セッションを再開するには、パスワードを再入力する必要があります。ID をロックすることは、あなたがマシンを離れた時に他人にあなたの名義で利用されることを防ぎます。
匿名アクセス（Anonymous access）
前述の通り、認証過程ではノーツ ID の証明書とドミノ・ディレクトリーの証明書とを照合します。しかしながら、証明書を持たないあなたの組織以外のユーザーやサーバーに対しても、自分の所のサーバー上のデータベースへアクセスさせたい場合もあるでしょう。例えば、あなたの顧客用のディスカッション・データベースがあるとします。全ての顧客組織の全ユーザーに対し相互認証を行なうのはやり難いし、またデータベースの情報は秘密に扱うものではないですから、その必要性もないでしょう。サーバー文書内の「匿名でのノーツ接続を許可」欄を埋めることで、この非認証アクセスが可能になります（サーバーのさまざまなデータベースへのアクセス制限は、個々のデータベースの「アクセス制御リスト」で制御します。詳しくは後述の、データベース・アクセス制御リストをご覧ください）。認証されていないユーザーは、「匿名（Anonymous）」というアクセス・レベルにありますが、匿名アクセスを受け入れていない場合、デフォルト状態のアクセス権がこれらのユーザーに適用されます。
Web クライアント認証
Web クライアントはノーツ ID を持たないため、照合作業は異なった方法で行なわれます。ブラウザー・クライアントがサーバーに接続する際（ノーツ・クライアントも同様です）に、認証を行なう代わりに、ブラウザーが匿名でアクセスできないサーバー（サーバー文書内の [ポート] - [インターネット・ポート] タブ経由で）や、匿名アクセス、あるいはデフォルト・アクセスが、アクセス禁止に設定されたサーバーのデータベースへアクセスを試みる際に認証が発生します（もしデータベースのアクセス制御リストが匿名によるアクセスを許可するか、あるいは読者以上のデフォルト・アクセス・レベルを持つ場合には認証は行なわれず、誰でもデータベースにアクセスできます）。
この名前とパスワードは、パケット・ヘッダーに保存され、サーバーへ確認のために送られます。これらの情報は、明らかにスニッファー（sniffer）やトレース・ツールを持つ人によって傍受されます。またユーザー名、パスワードの情報は、ブラウザー上にキャッシュされます（これにより情報を何度も入力する必要がなくなります）。このキャッシングにより、セッション中にユーザーがマシンから離れ、無人のままにしておくと、誰にでもそのユーザー自身の身元が利用されてしまいます。ユーザーは、この危険性を十分に認識しておかなくてはなりません。共同利用や公共のマシンを利用する際には、確実にブラウザーを閉じてからセッションを終了してから、マシンから離れることが重要です。
したがって、極秘の情報を保護しながら Web 上にあなたのサーバーやアプリケーションを公開するには、どのようにすれば良いのでしょうか？ Web 標準、あるいはその方法を用いると良いでしょう。
ドミノ サーバーはパブリック・キー証明書としてインターネット X.509 規格をサポートしています。これらの証明物は SSL や S/MIME（後述の安全なメッセージング・セクションで説明します）での安全なインターネット配信に用いられています。加えて、インターネット・プロトコルにおけるノーツ・クライアント・サポートは、SSL 上の他の Web サーバーとのトランザクションを保証するために、X.509 証明書をあなたの ID ファイルに保存させることができます。また、S/MIME を利用するインターネット・メール・ユーザーのメールを署名し、暗号化させることも可能です。
サーバー管理を制御する
ドミノ サーバー上での管理業務は、リモート・サーバー・コンソールの利用によってより容易になりました。管理者は、Web ブラウザー、またはドミノ管理クライアントを使って、ほぼ全ての Windows NT マシンから設定を変更したり、状況を観察したり、あるいはドミノ サーバーを再起動したりすることができます。この責任は非常に重大なものとなり、この特権のセキュリティーは厳しく管理されなくてはなりません。ドミノは、ドミノ管理クライアントか、あるいは Web ブラウザーの一方からリモート管理することができる、サーバー文書での別々の設定を提供しています。
より効果的なのは（効率的とは言えませんが）、Collect と Event（Event Dispatcher）サーバー・タスクを使って、サーバーやデータベースへのアクセスを試みたが失敗したケースをモニターし、問題を知らせる方法です。あなたは別のデータベースに情報を収集して、管理者に知らせるようサーバーを設定したり、管理者にメールを送ったり（もちろん、適任の技術者を呼び出すよう設定することもできます）、あなたのネットワークに SNTP トラップを作ったり、UNIX システム・ログ、ないし NT イベント・ビューアーに記録したり、別のサーバーへ中継したりできます。
Open Server URL コマンドを無効化する
特別な URL、http://myserver/?OpenServer は、サーバー上の全てのデータベースへのアクティブ・リンクを持つページを作ります。この全てのデータベースへのリンクのリストは、Web サイトに従事する管理者およびアプリケーション開発者にとっては便利で使いやすいものですが、一般のユーザーに公開するのは不適当です。しかしながら、サーバー文書で Open Server URL コマンドを制御する設定である「HTTP クライアントからのデータベース参照を許可」は絶対的なものです。どのユーザーがデータベースを見られるか、どのデータベースがリスト上に現れるか、を制限する方法はないのです。
クライアントの安全を確保するのは、サーバーの安全を確保するのに負けず重要なことです。あなたはノーツ・クライアントと Web クライアントが、サーバーとの間でどのように認証を行なっているかを見てきました。それに加えて、さらにクライアント関連のセキュリティー機能があるのです。
ノーツ・ユーザー ID とパスワード
ノーツ・クライアントの安全を確保することの最前線は言うまでもなく、ユーザー ID とパスワードです。ノーツ・クライアントが登録されると、ユーザー名と組織の適合した証明書がノーツ・ユーザー ID ファイルに保存されます。個々のユーザーに対応する証明書もまたドミノ・ディレクトリーに保存されます。ID が登録中に作られると、パスワードに加えてその複雑さ、すなわちクオリティー（品質）を定義することができます。高いクオリティーのパスワードは、低いクオリティーのものよりも安全です（詳しくは Iris Today の記事、パスワード・クオリティーを理解するをご覧ください）。
パスワードを用いて ID を保護することは、パスワードなしでは ID を使ってドミノ サーバーにアクセスはできない、と言うことです。ノーツ・クライアントが起動されると、ユーザーはこの ID 用のパスワードを要求されます。これがなくては、ノーツ R5 をはじめとするノーツ・クライアントは起動できないのです。ノーツ・クライアントの全てのリリースにおいて、ID に対応したパスワードがなくてはクライアントはドミノ サーバーにアクセスできないのです。
JavaScript ECL オプションは、ノーツ・クライアント内で動作する JavaScript のセキュリティーを制御します。ここでのノーツ・クライアントは、ノーツ・ブラウザーで表現された Web ページ、ノーツ・フォームの両者を指します。JavaScript がノーツ・クライアントに組み込まれていても、これらのオプションは、他のブラウザー（Microsoft Internet Explorer など）が動かすJavaScript は制御しません。
ドミノ サーバーへのアクセス制御が解決したら、管理者はアプリケーション設計者と協力して、ユーザーがアクセスできるのは何のデータかを決める必要があります。ドミノは、アプリケーション内のデータに対して、非常に細かなセキュリティー制御をかけることができます。これは、データがノーツ/ドミノ・データベースに保存されたり、あるいは個々の HTML ファイル内に含まれたりしても変わりありません。
アクセス制御リストは、個々のドミノ・データベース・アプリケーションへのアクセスを制御します。クライアントのアクセス・レベルは、個々のアプリケーションによって異なる場合があります。あるいは、管理者はユーザーのグループを作ってそのグループにアクセスを指示することで、より包括的にアクセスを制御することもできます。適切にアクセス制御リストを設定して、アプリケーションへのアクセスの制御を行なうことについては、数多く述べられています。Iris Today 記事 The ABCs of using the ACL（US） と R5 システム管理ヘルプをご覧ください。
ファイル・システムへのアクセス制御
オペレーティング・システムの安全を確保した後、もしドミノ サーバーが Web 上で開いているならば、ノーツ・データベースではない、サーバー上の特定のファイルへのアクセス設定を必要とするかもしれません。これは、特にドミノ HTTP サーバーがディスク上の HTML ページを供給する場合に言えることです。ノーツ/ドミノ・データベースほど、ファイル・システム・ファイルへのアクセス制御は細かくではありませんが、ドミノは全般にわたる制御を行ないます。ドミノは、GET と POST メソッドの標準 HTTP セキュリティーをサポートします。
セキュリティー関連のデータベース・プロパティー ローカル・データベースの暗号化
空港であなたのノート・パソコンが盗まれたら、DVD プレーヤーが無くなったと憤慨するかもしれません。しかし、ノート・パソコンにおいて最も重要なものは、ハードウェアでもソフトウェアでもなく、データです。ローカルに保存されたノーツ・データベースは、初期設定において、簡単にアクセスして開くことができます。これはサーバーやその設定の保護下に無いからです。極秘扱いの情報を含むデータベースは、ユーザー ID によって暗号化できるので、その ID のパスワードを知る人だけアクセスできるようになります。
データベース・プロパティー・ボックスの暗号化設定を利用することで、どんなユーザーID またはサーバー ID ででも、ローカル・データベースを暗号化することができます。この機能は、主にワークステーションのために開発されました。ワークステーション、特にノート・パソコンの物理的なセキュリティーは、サーバーのそれよりもしっかり制御できないからです。しかし、あまり一般的ではないにせよ、サーバー上のデータベースもサーバー ID によってローカルで暗号化することができます。より効果的にするために、データベースを守るために使われた ID は、パスワードで保護されなくてはなりません。
フォーム上の署名可能なフィールドは、文書が保存、ないしメールで送信された時にデジタル署名を添付します。デジタル署名は、作成者自身が本人であるという主張と、文書内の情報が改ざんされていないことを証明します。ユーザー ID ファイルのプライベート・キーが署名を作成します。ユーザーが署名されたフィールドを含む文書を開くと、ノーツがドミノ・ディレクトリーにある作成者のパブリック・キーを比較して、ユーザーの署名を確認します。署名可能なフィールドがフォーム上のセクションにあると、文書が開かれた時に署名が確認可能ならば、署名がセクションの先頭に現れます。
再び文書の署名は、（ノーツ・ユーザー ID 内に保存されている）ユーザーのプライベート・キーを使って行なわれ、署名の証明はドミノ・ディレクトリーに保存されたユーザーのパブリック・キーとの比較で行われることがら、フィールドや文書の署名（ 電子メールを含む）は Web クライアントでは利用できません。
フィールドの暗号化
フィールドのデータは、暗号化キーを使って暗号化できます。このキーはユーザーによって作成され、電子メール（これもまた暗号化される必要があります）経由か、あるいは書き出し（exporting）、配布、そして呼び出し（inporting）の手順により配布されます。このキーは、ユーザー ID 内に保存されます。暗号化されたフィールドを含む文書が読み込みや編集のために開かれた時、ユーザー ID 内に必要なキーがあれば、文書内のそのフィールドは復号化され、データを閲覧することができます。この作業は、文書にアクセスするユーザーを困らせないように、完全にシームレスに行なわれます。
暗号化されたフィールドは、文章が開かれるまでは復号化されないため、ビューには表示されません。このデータはビュー内の文書プロパティーから閲覧する事ができず、非表示式とは違い、真のセキュリティーを提供しています。暗号化されたフィールドは Web クライアントでは読むことができません。というのは、必要とする暗号化と復号化のキーが Web クライアントで利用することの無いノーツ・ユーザー ID に保存されているからです。フィールド暗号化に関して、詳しくは Iris Today の記事、アプリケーションでのフィールド暗号化の利用をご覧ください。
