ID の復旧
ID を復旧する場合は、ID ボールトを使用することを強くお勧めします。ただし、ここで説明する従来の ID 復旧機能も引き続き使用することができます。
このタスクについて
ID ボールトを使用せずに消失または破損した ID ファイルを復旧する場合、各ユーザーが自分の ID ファイルのバックアップコピーを安全な場所 (ディスクに保存して鍵のかかる場所に保管するなど) に保管する必要があります。ID ファイルの消失や破損、パスワード忘れは、深刻な結果をもたらします。ID がないと、ユーザーはサーバーにアクセスしたり、消失した ID を使用して暗号化したメールなどのデータを読むことはできません。ID ファイルの消失や破損が発生したり、パスワードを忘れたりした場合に問題が発生しないようにするには、ID ファイルを復旧できるように Domino® を設定しておく必要があります。
ID とパスワードを復旧する際にグループとして機能する一連の管理者を指定しておくのが理想的です。ID の復旧担当として 1 人の管理者を指定することもできますが、3 人以上の管理者が協力して ID ファイルの復旧にあたるようにすることを検討すべきです。管理者のグループを指定しておけば、すべての ID ファイルにアクセスできる 1 人の管理者によってセキュリティ侵害が発生することを防止できます。管理者のグループを指定する場合、実際の ID の復旧作業の際にそのグループの全員が揃わなくても作業が行えるように指定することもできます。たとえば、ID 復旧のために 5 人の管理者を指定する場合、ID ファイルのロック解除に必要な管理者を 3 人としておけば、5 人のうちいずれか 3 人の管理者だけで ID ファイルのロックを解除できます。管理者のグループを指定し、実際に必要な管理者をそのサブセットとしておけば、管理者の 1 人がアクセス不能な場合や退社した場合に問題が発生することを防止することもできます。
ID の復旧管理者は、Domino Administrator へのアクセス、バックアップ ID ファイルが保存されているデータベースへの明示的な「読者」アクセス権、認証者の ID ファイルまたはパスワードへのアクセス権が必要です。Domino 管理者である必要はありません。
ID ファイルを復旧する前に、認証者 ID ファイルにアクセスできる管理者は復旧情報を指定し、ID ファイル自体を復旧可能にしておく必要があります。これを行うには、以下の 2 つの方法があります。
- 登録時に、管理者が復旧情報を含む認証者 ID で ID ファイルを作成する。
- 管理者が認証者 ID ファイルから復旧情報をエクスポートし、ユーザーがそれを受け取るようにする。
- 管理者が Domino Administrator クライアントを使用して復旧情報を変更する。その後、ユーザーがホームサーバーに対して認証をしたときに、復旧情報は自動的にユーザーの Notes® ID に追加されます。
Domino では、ID 復旧情報は認証者 ID ファイルに保存されます。保存される情報には、ID の復旧が許可されている管理者の名前、ユーザーが各自の ID ファイルの暗号化されたバックアップコピーを送信する先のメールデータベースまたはメール受信データベースのアドレス、ID ファイルのロック解除に必要な管理者の人数などがあります。メールデータベースやメール受信データベース内の文書には、ID ファイルの暗号化されたバックアップコピーの添付ファイルが格納されます。それらのファイルは、ランダムキーを使用して暗号化されており、復旧されるまで Notes で使用できません。
消失または破損した ID ファイルを復旧するには、ID ファイルの暗号化されたバックアップコピーが必要です。パスワード忘れの ID ファイルを復旧するほうが、少し簡単です。元の ID ファイルに復旧情報が含まれている場合、管理者は、ID ファイルの暗号化されたバックアップコピーが存在しなくても、ID ファイルを復旧できます。
ユーザー ID の ID 復旧は、いつでも設定できます。ユーザーを登録する前にその設定を行うと、ユーザーが最初に各自のホームサーバーを使用して認証を行ったときに、ID 復旧情報がユーザー ID に自動的に追加されます。Notes ユーザーを登録した後で ID 復旧情報を設定すると、次回ユーザーが各自のホームサーバーを使用して認証を行ったときに、復旧情報がユーザー ID に自動的に追加されます。
ID の復旧処理
このタスクについて
どの管理者の場合も、ユーザーの ID ファイルには、その管理者のパブリックキーを使用してランダムに生成され暗号化された復旧パスワードが保存されます。そのパスワードは、管理者とユーザーごとに一意なパスワードです。たとえば、管理者 Randi Bowker はユーザー Alan Jones に対する一意な復旧パスワードを持ち、そのパスワードは Alan の ID ファイルに格納されます。同様に、管理者 Randi Bowker はユーザー Susan Salani に対する一意な復旧パスワードを持ち、そのパスワードは Susan の ID ファイルに格納されます。
復旧パスワードに対する文字数、つまりパスワードの長さを選択できます。これは、パスワードの強度や危険にさらされる可能性を判断することに役立ちます。16 文字より少ないパスワードの長さは、英数字と 16 進数の両方を使用して計算されます。16 文字の長さを持つパスワードは、16 進数だけを使用して生成されます。パスワードの長さは重要ですが、強いパスワードは危険性が少なくなるものの、利便性も低くなります。長くて複雑なパスワードは使用しにくい場合もあるため、管理者はパスワードの長さを短くすることもできます。
また、管理者はユーザーが ID を復旧するのを支援するためのカスタムメッセージを設定できます。
ID を復旧するには、ユーザーと管理者は、次の手順を実行します。
手順
- ユーザーは、担当の各管理者に連絡し、その管理者の復旧パスワードを取得します。
- 管理者は、自分のプライベートキーを使用し、該当ユーザーの ID ファイルに保存されている復旧パスワードの暗号を解除することによって、復旧パスワードを取得します。
- そして、ユーザーに復旧パスワードを知らせます。
- ユーザーは、ID ファイルのロック解除に必要な管理者の最少人数に到達するまで、手順 1 から手順 3 を繰り返して実行します。
- ファイルのロックを解除したら、ユーザーは新しいパスワードを入力し、ID ファイルを保護します。
タスクの結果
ユーザーが新しいパブリックキーの取得、名前の変更の受け入れ、文書暗号化キーの受け入れや作成を実行すると、Domino によって更新後の ID ファイルの暗号化されたバックアップコピーが中央管理のデータベースに自動的に送信されます。サーバーベースの認証機関の場合、復旧データベースはユーザーがサーバーに接続した時点で更新されます。ユーザー文書には既に更新済みのパブリックキーが含まれているため、復旧データベースに送る暗号化された ID ファイルのコピーがユーザーの再認証によって作成されることはありません。
ユーザーの以前の認証者の復旧情報よりも古い復旧情報を格納している異なる認証者が、ユーザーの名前を変更したり移動している場合は、この新しい認証者の復旧情報はユーザーの ID ファイルで受け入れられなくなります。新しい認証者を使用する前に、その復旧情報を更新して、以前の認証者の復旧情報よりも新しい内容にする必要があります。そのためには、管理者は新しい認証者の復旧情報を何らかの方法で変更し、保存する必要があります。これにより、認証者の復旧情報は新しいタイムスタンプで更新され、これ以降にその認証者により名前を変更または移動されたユーザーは確実に正しい復旧情報を自分のユーザー ID に反映させることができます。管理者はその後、必要に応じて変更を取り消すことができます。
権限のないユーザーが権限のあるユーザーの持っている情報なしに ID を復旧してしまうことを防止するには、ユーザーとサーバーでパスワードの照合を有効にしてください。パスワードの照合が有効になっている場合、権限のあるユーザーは正規の ID を使用してサーバーにアクセスできないため、変更があったことに気付きます。権限のないユーザーが ID ファイルを復旧したとき、強制的にパスワードを変更させられたのです。
また、念のため、ID を復旧した後は、復旧情報を再度受け取り、各自の ID ファイルのパブリックキーを変更するようユーザーに要請してください。復旧情報の再度の受け取りは、ユーザーがホームサーバー上のデータベースにアクセスしたときに自動的に行われます。それに応じて、ID ファイル内の復旧パスワード情報が変更されます。パブリックキーを変更すると、ID ファイルに保存されているパブリックキーとプライベートキーが変更されます。
ID 復旧を記録する
このタスクについて
クライアント ID の復旧アクティビティに関する重要情報は自動的にローカルの log.nsf ファイルに記録されるため、管理者はこの情報をトラブルシューティングの目的で使用できます。
次の ID の復旧情報は、ローカルのログに記録されます。
- 復旧情報が ID ファイルに受け入れられた日時。
- 復旧情報が ID ファイルに拒否されたか受け入れられることに失敗したときのインスタンス。
- ID の復旧データベースにメールで送信される、新しいバックアップを必要とするイベント。
- メールによる復旧 ID の復旧データベースへの送信 (成功と失敗)