AWS CloudHSMを用いたコードサイニング証明書の保持と署名への利用

ツール導入前の課題

USBトークンが物理的に存在しているために発生した課題
証明書という厳重な管理を求められるものであるため社内での保管となり、利用予定の調整とメンバーの調整が課題となっていました。
当社では在宅日と出社日が存在するため、署名を行う際はWindowsエージェントのビルドを出社の日になるように調整する必要があります。
また、ビルドに問題などが起きた場合、出社の切り替え等が発生することがあり、メンバーの調整やスケジュールの調整が大変な部分がありました。

上記に加えて、当時は社内で唯一のUSBトークンだったので社内の他プロダクトで署名を行う際は、Windowsエージェントのビルド時期やビルドに問題が起こった場合を加味してバッティングしないようにする必要もありました。

ビルド中の署名エラー監視に関する課題
Windowsエージェントビルド監視のためだけにメンバーの工数が数時間かかってしまう課題もありました。

Windowsエージェントのビルドスクリプトの実装上、数十回の署名が行われますが、署名エラーでUSBトークンがロックされる事例がありました。
ロック自体は当社の情報システム部門に解除してもらったものの、以下2点の問題が発生する可能性がありました。

1. 情報システム部門の時間を奪ってしまうこと
2. ロック中は他プロダクトでも利用ができなくなり、リリース作業のブロッカーになってしまうこと

上記の問題への対策のため、ビルド中は異変を確認できるように２人体制でエラーが出ていないかチェックしながらのビルドを行う運用をする必要がありました。

どのような状態を目指していたか

• OPTiM BizのWindowsエージェントのビルド環境との親和性が良いこと
  Windowsエージェントのビルド環境がAWSのサービスで構築されていたため、AWSのサービスのみで完結できることを目指していました。

コードサイニング証明書の利用に場所の制約と利用調整が要らないこと

以下の課題を解決できるような状態を目指していました。

• USBトークンが物理的に存在しているために発生した課題
• ビルド中の署名エラー監視に関する課題

• DigiCert コードサイニング証明書(USBハードウェアトークン)
• DigiCert KeyLocker
• AWS CloudHSM

• 利用するサービスのセキュリティ要件が、利用するDigiCertのコードサイニング証明書の要件を満たしているか
  • コードサイニング証明書はFIPS 140 レベル2、Common Criteria EAL 4+、または同等の認定を受けたハードウェアに格納する必要があります。そのため、証明書の格納先が上記セキュリティ要件を満たすことは必須事項でした
• ビルド環境と結合がしやすいか

社内で利用しているビルド環境がAWSのサービスを利用して構築されていたため、
サービス間の結合のしやすさからAWSサービスであったCloudHSMを利用することにしました。

改善したかった課題はどれくらい解決されたか

ほぼすべて解決されました。

どのような成果が得られたか

USBトークンは完全に不要になった

物理トークンが無くなったため、署名が必要であった場合でも、出社などの対応が不要になりました。
これにより、出社するかどうかの考慮も入れた利用時期の調整の煩わしさが無くなりました。

社内でのコードサイニング証明書利用スケジュール調整の不要化

他プロダクトの予定調整が不要で、コードサイニング証明書が利用可能になったため、コードサイニング証明書を利用する際のスケジュール調整等が不要となり、調整にかかる工数の削減ができました。

ビルドにおける署名スクリプトのロジック変更による監視作業運用からの卒業

AWS CloudHSMを利用することで、実質的にUSBトークンの利用が不要になりました。 これにより、発生する可能性のあった署名時のエラーについて、USBトークンのロックを気にする必要が無くなり、エラー監視の人員の工数が削減できました。

AWSのドキュメントに記載されていない点が多い

AWSのドキュメントには簡単なGetting Startedくらいしかなく、エラーが発生した際は１つ１つ独自にトラブルシューティングをしていく必要があり大変でした。

AWS CloudHSMに関する知見や事例が世の中にほとんど存在しない

AWS CloudHSMを利用した記事が少なく、トラブルシューティングなどを自分たちの手探りでやる必要がありました。
AWSのドキュメントにも書いていないうえ、他社のテックブログや技術記事も少ないこともあり、トラブルが発生しても参考となるものがなくて大変でした。

HSMを起動したままだと、高額な料金が発生すること

AWS CloudHSMにおいては、クラスターといったものが存在し、その中にHSMを作成するような仕組みになっています。
このクラスター内にHSMが存在する間、利用していなくても料金が発生します。
当社の利用方法では、リリースタイミングのみ利用できればよかったため、いかにAWS CloudHSMの料金を抑え、コードサイニング証明書の利用を自動化するかについて、多くの時間を費やしました。

コードサイニング証明書の利用目的でこちらのサービスを利用する際は、当社で利用しているように、利用するタイミングでHSMの作成を行い、しばらく利用しない場合は削除するといった運用で、コストを大幅に削減することが可能になります。

現在はOPTiM BizのWindowsエージェントの署名を主な用途としていますが、今後は他プロダクトのアプリケーションへの署名にも活用する予定です。そのため、AWSの別VPCへの接続が可能なアーキテクチャの検討を進めています。
また、今回のアーキテクチャはAWS上で閉じていますが、AWS CloudHSMはオンプレの環境との接続も可能なため、今後はオンプレのビルド環境からコードサイニング証明書のみをAWS CloudHSMに接続する構成も検討しています。