「丸い穴に四角いくぎは入らない(不向き)」という表现はよく知られています。コードサイニングで、一时期この问题がありました。お客様から丸い穴と四角い穴の课题を解决するよう求められ、提供できたものは丸いくぎだけでした。何を意味するかと言うと、一时期 逗阴馆? Secure Software Manager では標準の鍵ペア構成(秘密鍵と対応する公開鍵)しかサポートできず、丸いくぎしか提供できなかったということです。標準鍵ペアモデル(当社の丸いくぎ)は、標準コードサイニングのユースケース(丸い穴)をお持ちのお客様にぴったりです。しかし、GPG 署名のユースケースと Keyring モデル構成への GnuPG エコシステムのサポートはどうでしょう。これは当社から見ると四角い穴の課題でした。今まで選択肢がほとんどなく、この四角い穴の課題に対し丸いくぎによる標準鍵ペアソリューションを提供してきました。
くぎと穴について聞かされるのは、もううんざりですか。では、比喩で説明しましょう。GPG Keyring と標準鍵ペアに関連する署名のユースケースに焦点を当てます。当社が行ったことと、なぜそれが重要かについてです。
まず、SSM (Secure Software Manager)で GPG Keyring を 直接サポートしました。GPG キーにはマスターキーと関連するサブキーが含まれる点で、GPG キーは標準鍵ペアとは異なります。そのため、GPG Keyring は、鍵が証明書の階層構造に依存するのではなく、独自の階層構造を持つことができます。マスターキーとサブキーとの間に技術的な差異はない一方で、これらの鍵の責任は別々のままにして、セキュリティが強化されます。
サブキーの作成にはマスターキーのみを使用し、サブキーを署名に使用することをお勧めします。サブキーが危殆化した場合、影響を受けたサブキーを無効にして置換できるようになり、マスターキーと危殆化してないサブキーのセキュリティは維持されます。鍵 ID はマスターキーと関連付けられているため、マスターキーが危殆化された場合、マスターキーとすべての関連付けられたサブキーを無効にして置換する必要があります。
SSM のような署名ソリューションを使用する場合、鍵の危殆化のリスクレベルは低リスクから実在しないリスクまであります。しかし、署名ソリューションが提供できるリモートで保管された鍵で署名することには、ロールや職務の分離(誰がマスターキーを管理するか、署名のためにサブキーにアクセスする権限をどのユーザーに委譲するか)のような他のメリットがあります。これは、GPG、RPM、Debian、Redhat、Docker、その他の Linux の署名タイプを用いて、現在および将来の署名ユースケース向けの GPG Keyring モデルの活用を検討している人にとって大きなメリットです。マスターキーとサブキーへのアクセスを保護、制限することは、関係するユーザーにとっての課題でした。そのため、セキュリティと自動化のバランスを取るという長年の問題を、開発者チームと情報セキュリティ組織が何度も議論してきました。
解決した次の問題は、エンドユーザーがコンパイルする必要があり、使用できるところが限られ、機能制限のあるオープンソースライブラリへの依存性をなくすことでした。今まで、SSM はオープンソースの SCD (スマートカードデーモン)を活用していました。これは GnuPG-pkcs11-scd と呼ばれ、ユーザーが SSM-PKCS11 ライブラリを用いて署名キーで保護された SSM に戻るパスを渡すために、ソースコードからコンパイルする必要がありました。GnuPG-pkcs11-scd への依存性によって、Linux OS に GPG 署名から提供できることは限られていました。また、ECDSA や EdDSA キータイプをサポートしないオープンソースライブラリであるため、RSA に対する鍵アルゴリズムにも制約がありました。
この問題を解決するために、オープンソース SCD への依存性をなくし、独自の SSM-SCD を構築することにしました。こうして、GPG 署名を安全に行いたいお客様向けに、セットアップを容易にし、機能セットを改善することができました。以下の例があります。
つまり、この新機能は、Linux の署名要件を持つ SSM ユーザーに対して GnuPG エコシステムと GPG Keyring モデルへのネイティブサポート機能を提供します。一方で、Git Commits への GPG、RPM、Debian、新規にサポートする GPG Keyring の署名サポート(ソースコードへ署名すると GitHub と他のコードリポジトリでコミットすること)、また RedHat の Podman を使って現在サポートしている OCI (Open Container Interface)標準に対して最適化した方法での Linux 署名業務に関係するすべての監査ログと署名ログのキャプチャ、セキュリティ制御、鍵保護および管理、ハッシュ署名ワークフローの恩恵を受けています。
結局、完全自動化機能を維持しつつ、今まで GPG 署名を実装してきた方法に変化はありません。また、GPG Keyring の SSM へのインポートをサポートする予定です。これにより、現在 GPG マスターキーとサブキーを保護する方法の安全性についてセキュリティ上の懸念があるお客様は、これらのフローを SSM に移行して同じ自動化署名を実施でき、処理が一層安全で堅牢性だという確証を持てます。
将来にわたる署名の课题、问题の种类に関わらず、四角い穴の问题と丸い穴の问题に必要なくぎを当社は提供できます。
GPG 機能について詳しくは /肠辞苍迟别苍迟/诲补尘/诲颈驳颈肠别谤迟/辫诲蹿蝉/诲补迟补蝉丑别别迟/蝉蝉尘-驳辫驳-诲补迟补蝉丑别别迟-别苍.辫诲蹿(英语) を、Secure Software Manager については /jp/signing/secure-software-manager をご覧ください。
逗阴馆 ONE? の 逗阴馆? Secure Software Manager は、ポータブルで柔軟な実装モデルと安全な鍵管理によって、CI/CD (継続的インテグレーション/継続的デリバリー)パイプライン全体でセキュリティを自動化することでコードサイニングを管理する最新のツールです。Secure Software Manager は、秘密署名、オンデマンドキー、ローテーションキーへの署名ごとに一意の键と証明书などのコードサイニングのベストプラクティスをサポートしています。Docker、Microsoft、Java、 Android などの主要なプラットフォーム、ライブラリと互換性があります。Secure Software Manager を使うと、コードを製品開発プロセスに簡単に統合できる一方、暗号操作や署名の業務および管理を制御された監査可能な方法で委譲できます。逗阴馆 ONE の一部として、Secure Software Manager は大量の証明書の数分以内での高速展開を実現し、オンプレミス、国別、クラウドに柔軟に展開できます。