デジサートは、トラストエコシステムにおいて独自の立場にあります。当社はパブリックトラストを規定する標準の策定に関与するだけでなく、それらを自ら実践しています。

業界が 47 日間の TLS 証明書ライフサイクルへと移行する中で、この二重の役割には明確な責任が伴います。お客様に変革を提案するだけでは不十分であり、自社環境においてその有効性を実証する必要があります。

この取り組みのもとで開始されたのが「Customer Zero」です。これは、他社に導入を促す前に、DigiCert Trust Lifecycle Manager（TLM）を活用して自社インフラを近代化する社内プロジェクトです。

本 2 部構成のブログシリーズでは、デジタルトラストに対する高まる要求に対応するために当社のシステムをどのように強化したか、そしてお客様の近代化を加速させるために得られた教訓について紹介します。

既存環境の現実：自然成長はスケールしない

Customer Zero 以前、当社の証明書環境は、大規模かつ成長中の企業組織に共通する複雑性を反映しており、認証局（CA）にも見られる状態でした。

証明書管理は時間とともに複数のチームにまたがって進化しており、インベントリはツール、スクリプト、スプレッドシート、複数の CertCentral アカウントの組み合わせで管理されていました。所有者モデルは存在していたものの、可視性と一貫性はチームごとにばらつきがありました。

近代化の一環として、当社は環境全体に対する包括的なディスカバリーを実施しました。この結果、多くの大規模組織と同様に、複数のユースケース、チーム、システムにまたがる証明書管理は、一元的な可視化、明確な責任分担、自動化がなければ急速に難しくなることが確認されました。

この構造は成長の自然な結果です。しかし、証明書の有効期間が短縮され、運用負荷が増大する中で、分散管理は持続困難になります。スケーラビリティ、一貫性、レジリエンスを確保するためには、近代化が不可欠でした。

設計思想としての単一コントロールプレーン

最初のアーキテクチャ上の判断はシンプルでしたが、実行は容易ではありませんでした。それは、唯一の信頼できる記録システムを確立することです。

当社はすべての証明書関連活動を単一の TLM テナントに統合しました。同時に、俊敏性を維持するためにチームを個別のビジネスユニットとしてマッピングし、自律性を保ちながら中央集約的なポリシーとレポートを適用しました。設計指針は明確でした。

インベントリ → ポリシー → 自動化 → 可観測性

この順序を厳格に遵守しました。クリーンなインベントリがなければ自動化は機能せず、責任の所在が不明確なポリシーは摩擦を生むだけであるためです。まず基盤の整備が必要でした。

なぜインベントリ整備は自動化より難しいのか

ディスカバリーにより、環境内の「見えない問題」が明らかになりました。重複、失効済みでありながら発行済みとして残る証明書、所有者不明のままエンドポイントに残存する期限切れ証明書などです。

検知機能は効果的でしたが、時に過剰でもありました。同一の証明書が複数のシステムで検出され、矛盾する更新通知やエスカレーション疲れを引き起こしていました。

これを整理するには、CMDB レベルの厳格なタグ付けが必要でした。インベントリの品質が自動化の品質を決定することが明らかになりました。メタデータに問題があれば、自動化は誤った更新や誤配信、あるいはサイレント障害を引き起こします。責任の所在が明確になるまで、更新サイクルの高速化は実現できませんでした。

自動化：スケールと負荷を分ける分岐点

安定したインベントリを確立した後、当社はプロトコル優先の自動化戦略へ移行しました。主な対象は以下の通りです。

• ACME（Web サーバーおよび最新プラットフォーム向け）
• SCEP および EST（デバイス ID 向け）
• エージェントが導入できない環境向けのコネクタおよび API

結果は明確でした。約 50% のシステムが即座に ACME に対応し、さらに 40% が SCEP または EST に対応しました。これらについては、設定後は更新がバックグラウンド処理として自動化されました。

残りの 10% は主な課題となりました。レガシーベンダーに依存するこれらのシステムでは、カスタムスクリプトや手動対応が必要でした。1 年有効の証明書では問題にならなかった負荷も、47 日サイクルでは約 8 倍に増加します。ACME のような標準プロトコルに対応していない環境は、継続的な運用負荷の要因となります。

課題領域から得られた教訓

Customer Zero により、設計図では見えにくい「最後の一歩」の課題が明らかになりました。

• レート制限：398 日では問題なかった API 制限が、47 日ではボトルネックになります。
• サイレント停止：自動化ジョブが明確なエラーなく保留状態に入るケース
• 通知過多：大量のアラートにより重要な問題が埋もれる

センサー、コネクタ、エージェントといった自動化コンポーネントは「設定して放置」できるものではなく、本番インフラとして扱う必要があります。センサーの健全性や更新成功率を可視化する運用指標を整備しました。有効期間の短縮により、問題対応の猶予は大幅に減少します。1 年サイクルでは許容される遅延も、47 日では障害につながります。

属人的対応から組織的運用へ

最も大きな変化は文化面でした。従来の 1 年有効の証明書では、期限切れのリスクは経験豊富なエンジニアの「最後の対応」によって回避できました。

しかし、47 日サイクルではこの「属人的モデル」は成立しません。同じ対応を 8 倍の頻度で繰り返すことは不可能であり、疲弊やヒューマンエラー、重大障害につながります。そのため、以下のような組織的な運用へ移行しました。

• 強制的な標準化：例外を排除するため、すべてのパブリック証明書を 47 日に統一
• デフォルトでの近代化：すべてのエンドポイントで TLS 1.3 を必須化
• ポリシー駆動の発行：TLM を唯一の発行ゲートとして使用

証明書更新は緊急対応ではなく、日常的な運用プロセスとして扱うようになりました。

新たに確立された運用モデル

内部の証明書運用の再構築は、段階的改善ではなく構造的な変革を伴いました。更新は高リスクイベントから継続的なバックグラウンド処理へと変化しました。責任の所在は明確化され、ポリシーにより強制されます。自動化はプロトコルベースで標準化され、コネクタやエージェントは監視対象の本番インフラとして管理されます。

現在、デジサートの本番環境では、対象証明書の 99% 以上が自動化により更新されています。手動対応は稀であり、多くはサードパーティシステムの制約によるものです。更新頻度が増加しても結果の一貫性は維持されています。この一貫性こそが、47 日サイクルを安定して運用するための基盤です。

次回は、Customer Zero がもたらしたビジネス価値について解説します。ROI の向上、リスクの大幅低減、そして 47 日時代における自動化の真のコストに迫ります。