発行時認証

再構成は構造的に脆弱です

多くのシステムでは、証明は事後的に組み立て直されています。

• ログを照会する。
• 記録をエクスポートする。
• システムが引き続き利用可能であることを前提にする。

このやり方は時間がたつほど脆弱になります。システムは変わり、データは利用できなくなるかもしれず、アクセスも常に保証できるわけではありません。

発行時点での認証

CERTCRYPT は別のモデルを導入します。認証は発行時に行われます。

後から証明を組み立て直すのではなく、関連するイベントが起きた時点で、システムが認証アーティファクトを生成します。

その結果、後から公開ルールのもとで独立に再現できる検証に対応した証明書が生成されます。

この転換は、検証の仕組みそのものを変えるものではありません。

変わるのは、認証がいつ行われ、どのような条件のもとで行われるかです。

発行条件が重要になるシステムでは、認証はシステムそのものの一部でなければなりません。

イベントから検証へ

認証の流れは、シンプルな順序で進みます。

• 関連するデジタルイベントが起きる
• 発行時に認証アーティファクトが生成される
• 証明書が生成される
• 後から独立に検証を再現できる

運用上の影響

既存のシステムは、現在と同じように動き続けます。

違いは、関連するイベントが発行時に証明書を生成できるようになる点にあります。証明を後から組み立て直す必要がなくなります。

これにより、内部記録だけに証明の源を依存させる必要がなくなります。

認証はイベントパイプラインの一部になります

システムが動作するにつれて、異なる形の証明が生み出されます。

認証は、システムの内部にある運用レイヤーになります。

関連する各イベントは、その実行の一部として証明書を生成できます。

これにより、実際のシステム活動に沿った、発行時の測定可能な認証レイヤーが導入されます。

発行時認証が必要になります

このモデルが関係してくるのは、次のような場合です。

• イベントが後から争われたり見直されたりする可能性がある
• システムが長期にわたって利用可能であり続けるとは限らない
• 独立検証が前提ではなく要件になっている

再構成なしの証明

発行時認証は、証明の生成方法を変えます。

再構成に頼る代わりに、イベントが起きた時点でシステムが検証可能な証明書を生成できます。

検証は、元のシステムが動き続けていることに依存しなくなります。

認証がイベントの流れの一部になると、システムはもはや再構成に依存しません。

依存するのは発行です。

その時点で、問われるのは、後から証明を生成できるかどうかではなくなります。

問われるのは、イベントが起きた時点で証明が正しく生成されるかどうかです。

ユースケースに基づくアクセス

アクセスが認められる前に、ユースケースは構造的な関連性、現行のアクセス基準への適合性、必要になり得る条件の有無という観点から評価されます。

• ユースケースの関連性を確認する
• 現行のアクセス基準に照らしてユースケースを審査する
• アクセスが適切かどうかを判断する
• 必要な条件を明確にする

アクセスを申請

認証機能へのアクセスは現在、選定された組織に限定されています。

ご利用の環境で発行時認証と継続的な独立検証が必要であれば、アクセスを申請してください。

アクセスを申請する →