公開鍵インフラストラクチャを文書化するにはどうすればよいですか？
3層のPKI（複数の第2レベルのポリシーCAを含む）を文書化する準備をしており、PKI以外の専門家にとってはあまりにも圧倒的ではなく、有用で技術的な文書を作成したいと考えています。
聴衆は以下の役割に分けられると思います
- 証明書を要求する人
- 証明書を承認する管理者
- 将来私を置き換える技術PKI管理者
もっと多くの役割があるかもしれませんが、私は自分のために不要な仕事を作りたくありません。誰もこの情報自体を求めているわけではありませんが、私が集めたこの知識はどこかに保存する必要があることを知っています。
質問
- PKI管理者がドキュメントを生成する対象となる対象者は何ですか？
- それぞれのドキュメントにはどのような技術的事実があるべきですか？
- 各ドキュメントの範囲外（詳細すぎる、または単純すぎる）は何ですか？
この種の質問は、1998年にMicrosoftがWindowsのさまざまな側面のテンプレートドキュメントとチェックリストを持っていたMCSEであると考えてから来ています。他のベンダー（Entrustなど）に、私の考え方を体系化するのに役立つ関連サンプルドキュメントがある場合。
あなたは少なくとも必要です：
証明書のライフサイクルに関連するプロセスを説明するドキュメント：
*新しい証明書のリクエスト
*証明書の失効
*証明書の更新
管理者とユーザーの両方（おそらく、プロセスごとに2つの異なるドキュメント）
- cAレベルとその目的を説明する一般的なアーキテクチャドキュメント
それは私の意見では最低限です。証明書の管理者とその専門知識レベルに応じて、スクリーンショットなどを含むさまざまなチュートリアルドキュメントが役立つ場合があります。
PKI管理者は実際には明確に定義された役割ではないため、彼のドキュメントの範囲はここではあいまいです。
私は最高情報セキュリティ責任者として、次の文書が存在することを確認します。
- 技術者向けのシステム管理ドキュメント-サーバーとクライアントをセットアップする必要があるsysadmin（構成、アーキテクチャなど）。いくつかの興味深い点は、セキュリティや法的な問題を提起することなく、sysadminによって変更できるものと変更できないものを修正することにもなります。
- ユーザードキュメント-これを行う場合に何をすべきかについての簡単な「ガイドに従う」ドキュメント（スタートアップガイド、日常の使用、更新や取り消しなどの特定のタスク）
- 法的/適合文書-義務の尊重を確実にするために行われた措置、またはリスク分析からリスクを低減するために行われた措置に関する明確な説明。短いアイデア：監査人のための文書。
特定のケースでは、認証局のリーダー向けに調整された特定の文書（CSRを検証し、証明書を要求する人を認証する方法、CSRに署名する方法など）と、あなたが何を述べている認証局ポリシー文書があるかもしれませんCAとしての保証。