保護


Notes と Domino の検証と認証
Notes クライアントまたは Domino Server が、複製、メール配信、データベースアクセスなどのために別の Domino サーバーと通信しようとすると、クライアントまたはサーバーの ID 情報を使用した 2 つのセキュリティ処理によりクライアントまたはサーバーの正当性が検証されます。検証では、クライアントのパブリックキーの信頼度を判定します。検証に成功すると、認証が開始されます。認証では、ユーザー ID が照合され、チャレンジとレスポンスのやり取りでクライアントとサーバーの両方のパブリックキーとプライベートキーが使用されます。

パブリックキーの信頼度を判定するルール

検証では、次の 3 つのルールに従ってパブリックキーの信頼度を判定します。Domino では、サーバーにアクセスしようとしているクライアントと、クライアントがアクセスしようとしているサーバーの両方が検証されます。

1. そのサーバーかクライアントの階層名のツリーで、上位にある名前のパブリックキーは信頼できます。これは、上位にある名前のパブリックキーが、そのサーバーかクライアントの ID ファイルに保存されているためです。

2. そのサーバーかクライアントの階層名のツリーで、上位にある名前によって発行された有効な証明書から取得したパブリックキーは信頼できます。

3. 信頼できる認証者が認証したパブリックキーと、その認証者の下位の名前に属するパブリックキーは信頼できます。

検証と認証の仕組み

ここでは、システムのセキュリティを確保するために、検証と認証が一体となって機能する仕組みを説明します。この例では、ユーザー Randi Bowker/Marketing/East/Renovations (クライアント) が Mail-E/East/Renovations (サーバー) にアクセスします。

1. Mail-E は、Mail-E の ID ファイルから Renovations パブリックキーを読み込みます。上記の 1 番目のルールに従って、Renovations に割り当てられたパブリックキーを信頼します。

2. Randi は、自分のユーザー ID で Mail-E の情報を送信します。Mail-E は、Randi のユーザー ID を読み込んで、Renovations から East に発行された証明書を探します。次に、信頼できると判定された Renovations パブリックキーを使用して、East の証明書が有効であるかどうかを照合します。証明書が有効なら、上記の 2 番目のルールに従って、East に割り当てられたパブリックキーを信頼します。

3. Mail-E は、Randi のユーザー ID を読み込んで、East/Renovations から Marketing に発行された証明書を探します。次に、East/Renovations パブリックキーを使用して、Marketing/East/Renovations の証明書が有効であるかどうかを照合します。ここでも、2 番目のルールに従って、Marketing/East/Renovations に割り当てられたパブリックキーを信頼します。

4. Mail-E は Randi のユーザー ID を読み込んで、Marketing/East/Renovations から Randi に発行された証明書を探します。次に、信頼できると判定された Marketing/East/Renovations パブリックキーを使用して、Randi の証明書が有効であるかどうかを照合します。証明書が有効なら、上記の 3 番目のルールに従って、Randi に割り当てられたパブリックキーを信頼します。

5. Mail-E が Randi のパブリックキーの信頼を確立すると、認証プロセスが開始されます。

6. Mail-E が、チャレンジと呼ばれる乱数を Randi に送信します。

7. Randi のクライアントは Randi のプライベートキーでチャレンジを暗号化し、その結果の暗号化数値を Mail-E に送り返します。

8. Mail-E は、Randi のパブリックキーを使用してそのレスポンスの暗号化を解除します。その結果、元のチャレンジが生成されたら、Randi が本人であると分かります。

9. 次に、逆のプロセスが実行されます。Randi のクライアントが Mail-E の証明書を処理して、Mail-E のパブリックキーを検証します。その後、前述のチャレンジとレスポンスを使用してサーバーの身元を認証します。

関連概念
Notes ユーザー、インターネットユーザー、Domino サーバーのサーバーへのアクセス