PKIソリューションベンダーの選択

Question

（X.509-）PKIソリューションで何を探しますか。また、次の制約がある場合、なぜそれを探すのでしょうか。

利用可能なプログラミング/ sw-engineeringは、どのように制限されているかを知っています（つまり、「少数のPerlスクリプトを使用したOpenSSL」は実行可能なアプローチではありません）。
プロセスが合理的によく理解されている（証明書のライフサイクルなど）
一部の（ルート/中間）証明書は金銭的価値が高く、それに応じて保護する必要があります（HSM？）
委任された管理者権限を持つ複数の組織にまたがる「2、3の」アイデンティティを処理する
ハードウェアベースのソリューション（スマートカードなど）は、すぐに要件として浮上するでしょう。
オンプレミスの自己ホスト型ソリューション

私は「通常の容疑者」からいくつかの候補者を特定しましたが、いくつかの疑問があります（過去数年間、市場はほとんど成熟していないように見えますか？）。したがって、候補者には名前を付けませんが、公平な意見を求めます。

Dave Mulligan · Answer

完全な開示：私は電圧セキュリティで働いています。そのことを前もって述べたほうが、販売意欲をかき立てて「誤って」私たちのWebサイトに案内するよりも、ましだと思います。これは会社が後援する対応ではありませんが、私の見解が公平であることは自由に認めます。私はこの回答への漏れを最小限に抑えるよう努めますが、適切な程度の懐疑論を持って読んでください。

非対称暗号化スキームの基本的な問題は、暗号化ではなく、鍵の管理です。したがって、PKIシステムを区別するのは暗号化のセキュリティではありません。これは同一ですが、ユーザーのプロビジョニング、削除、および一般的なシステム管理の容易さです。

したがって、非対称暗号化のベンダーに私が尋ねる質問は次のとおりです。

暗号化されたデータの新しい受信者をシステムに取り込むプロセスは何ですか？
秘密鍵はどのように保存、保護、バックアップされますか？
資格情報はどのように管理されますか？
名前の変更はどのように処理されますか（たとえば、誰かが結婚して名前とシステムログオンを変更した場合、影響はありますか？）
暗号化されたデータをデータ損失防止デバイスでスキャンして、インサイダーがデータを社外に持ち出す方法として暗号化機能を使用していないことを確認するにはどうすればよいですか？

[〜＃〜]編集[〜＃〜]

（これは私が最初に省いたものです、それはあまりにも売上高を感じたからです）

上記の質問をする理由：

ほとんどのPKIシステムでは、受信者がデータを送信する前に、公開鍵と秘密鍵のペアを作成する必要があります。これは、システムがアドホックに使用されることを禁止します。このシステムでは、受信者のために暗号化できます。
秘密鍵が失われると、対応する公開鍵で暗号化されたデータは失われます。物語の終わり。深刻なPKIシステムには、失われた秘密鍵を取得するための何らかのメカニズムがあります。これがキーのデータベースである場合、これがどのように保護されるかを考え、それが頻繁にバックアップされるようにする必要があります。高可用性のためにソリューションを複数のデータセンターに配置する必要がある場合は、レプリケーションも検討してください。
これは簡単です。ユーザーは、秘密鍵にアクセスするために何らかの認証資格情報を提供する必要があります。これを既存の認証方法に統合する方法を尋ねます。
メアリージョーンズが結婚（または離婚）し、メアリースミスになると想像してください。「Mary Smith」の資格情報を使用して、彼女は「Mary Jones」用に以前に暗号化されたデータにアクセスできる必要があります。 PKIシステムはこのケースを適切に処理する必要があります。代わりに、「Mary Jones」用に暗号化されたすべてのデータを見つけ、それを復号化してから、「Mary Smith」用に再暗号化します。ああ。
基本的に、DLPデバイスは暗号化されたデータのプレーンテキストにアクセスできる必要があります。これをどのように達成できるかを尋ねます。

Thomas Pornin · Answer

PKIは5％の技術、95％の手順です。X.509証明書の基本的な部分は非常に単純です。これは単なる signatures です。。そのための最初の使用可能なアルゴリズムは1970年代後半に説明されており、詳細はほとんど1990年代初頭に解決されました（これは過去20年間の暗号研究を軽視するものではありませんが、実際にはPKCS＃1 v1.5署名は十分です）。

手順は、できれば「キーストロークレベル」で何が起こるかを正確に説明します。中間CA証明書の更新などの機密性の高い操作は、少なくとも手順で明示的に指定されていない限り、キーが押されていないこと、ボタンがクリックされていないことを確認します。スコープは広いです。 CAを含む部屋の物理的な保護、監視ビデオカメラの位置も含まれます...

製品に手順の包括的なマニュアル、または少なくともローカル環境に合わせて調整する手順テンプレートが付属していますか？これらの手順の作成それらを適用することは、PKIで最もコストがかかるものです。これには、「内部」で何が起こるかを知る必要があります。「方法」のプログラミングの問題ではなく、秘密鍵とは何か、それが何をすることができるかについての明確で明確な概念を持っています。この種の知識が社内になく、PKI製品にもそのテーマに関する十分な情報が含まれていない場合は、コンサルタントを雇う必要があり、それは安くはありません（知っておく必要があります）。

認証、Identity Management、およびAuthorizationは同じものではありません。一般にPKIについて話すとき、多くの場合、3つに関連するいくつかの要件を念頭に置いています。明確な活動：

ID管理：ユーザー、その名前、従業員ID、最終変更日などを追跡します。この部分は常に必要ですが、「暗黙的」にすることも、ユーザーが24人しかいない場合はExcelスプレッドシートのように単純にすることもできます。 2万人のユーザーには、さらに進化したものが必要になります。
認証：ユーザーであると主張する誰か[〜＃〜] u [〜＃〜]が実際にユーザー[〜＃〜] u [〜＃〜]。
Authorization：特定のユーザー[〜＃〜] u [〜＃〜]が許可されている操作を把握して追跡するトリガー、それが読み書きできるデータ。

これらの活動は異なります。一部の製品はそれらの一部またはすべてを統合し、これは不快な制限を意味する可能性があります。たとえば、 Active Directory を検討してください。LDAPサーバーとして、ID管理に使用できますが、Kerberosコンポーネントは認証を処理します。このため、非パスワードベースの認証をActive Directoryと統合するのはかなり面倒です。

3種類のアクティビティはブリッジする必要がありますが、それでも別々にしておく必要があります。 X.509証明書はほとんどが認証ですが、証明書の発行は、証明書に何を入れるかを知るためにID管理にフィードする必要があります（証明書は公開鍵をIDにバインドします）。 PKIに関する非常に重要な教訓は、証明書は承認に適さないことです。ほとんどの人がPKIに関して最初に犯す間違いの1つは、証明書にアクセス権を埋め込もうとすることですが、失敗し、彼らはそれをすべきではなかったことを理解します（正確な理由は突き止めるのは難しいが、固有の非同期に関連しています）証明書発行の）。

したがって、これはベンダーに尋ねる2番目の質問をもたらします：製品はID管理、証明書管理および許可の分離を可能にし、それらの間でどのブリッジがサポートされますか？

例として-製品の推奨ではなく-検討してください Microsoft Forefront Identity Manager 、いくつかの製品を含むスイート：ID管理用のFIMサービス/ポータル、証明書用のFIM CM（CAのラッパー、スマートカードも処理します）、ADサーバーとID管理をつなぐためのFIM同期、つまりFIM CM、...

PKIに深刻な値がある場合（そうでない場合は、なぜ気になるのですか？）、CA秘密キーをハードウェアセキュリティモジュールで保護する必要があります。オフラインCAをネットワークからハッキングできないことに基づいて、ルートCAをオフラインにしてください。すべてのクライアントシステムでルートCA公開鍵を配布することは大きなコストであり、2回はしたくないので、本当に本当にルートを見たくないCAが危険にさらされたか、失われたか、またはその両方です。

発行する証明書がまだたくさんあるので、おそらくオンライン中間CAが必要になります。すべてのクライアントシステムで新しいルートCAキーを再配布する必要なく、そのCAの損失または妥協から回復できます（これは、中間CAからルートを分離するポイントです）が、これはhappy中間CA秘密鍵が盗まれたのを確認します。そのため、そのキーのHSMもすばらしいでしょう。

したがって、PKIベンダーに次のことを依頼してください。HSMはサポートされていますか？

スマートカードは小さなHSMに似ていますが、クライアント側にあります。スマートカードのサポートには、初期化が必要です。ある時点で、一部のデスクトップシステムでスマートカード固有のコードが実行されます。繰り返しになりますが、PKI製品にはそのサポートが含まれる場合と含まれない場合があります。スマートカードベンダーも役立ちます。

証明書がencryption用である場合、署名と認証ではなく、いくつかの key escrow が必要になります。実際、一部のデータが秘密鍵で暗号化されているときに秘密鍵が失われると、データは失われます。したがって、どこかにバックアップが必要です。これは通常暗号化された電子メールの場合です。このようなキーのバックアップは非常に機密性が高いため（攻撃者にとって非常に魅力的なターゲットです）、それらを即興で使用することはできません。

したがって：PKIソリューションにはキーエスクローシステムが含まれていますか？

一方、署名に使用されるキーをエスクローしたくないのは確かです。これにより、これらの署名に付加される可能性のある法的価値が損なわれる可能性があります（詳細はコンテキストや管轄によって異なりますが、一般的なルールとしては、エスクロー署名キー）。これは、暗号化および署名を行うユーザーが2つの鍵、つまり2つの証明書を必要とすることを意味します。したがって、別の質問：PKIソリューションはマルチ証明書ユーザーをサポートしていますか？

上記のすべては、X.509のPKIに関するものです。 IDベースの暗号化（@Daveによってリンクされている「電圧」とは）のような代替ソリューション、または OpenPGP Web of Trust のような分散システムが存在する場合があります。 必要な最初のステップは、要件を書き留めることです。あなたには制約があります。それは良い。しかし、次の質問にも答える必要があります。PKI、はい、しかし何をするのですか？