ScalarDL 3.8をリリースしました

先日、ScalarDLの新しいマイナーバージョンであるScalarDL 3.8をリリースしました。3.8においては、マイナーバージョンのリリースではありますが、新たに認証方法としてHMACが加わわる等の後方互換性がある機能追加や多くの改善が行われています。このエントリにおいては、その中のいくつかの重要な機能や改善について共有したいと思います。ScalarDLの設計や実装に関しては、過去のブログ（英語版はこちら）

Hash-based message authentication codes (HMAC)による認証が選択可能になりました

ScalarDL 3.7以前はクライアント認証（LedgerまたはAuditorによるクライアントの認証）、Ledger認証（AuditorによるLedgerの認証）、Auditor認（LedgerによるAuditorの認証）における認証方法はデジタル署名のみが使われていました。デジタル署名は非対称の鍵ペア（秘密鍵と公開鍵）を使用し、送信者は自分の秘密鍵を用いてメッセージ¹の署名を作成し、受信者はその秘密鍵に対応する公開鍵を用いてメッセージを検証します。デジタル署名は、メッセージに対して真正性の保証、認証、否認防止性の保証²が可能ですが、処理速度が遅いという問題がありました。

そのため、ScalarDL 3.8からはデジタル署名の他に新たにHMACを選択することが可能になりました。HMACはメッセージの送信者と受信者が共通の鍵を用いてメッセージの送信および検証をおこなうことで、そのメッセージの真正性の保証および認証を実現します。共通鍵を用いるため理論上は受信者がメッセージを改ざんすることが可能であるため、HMACは否認防止性を保証することは出来ません³が、デジタル署名に比べ高速に動作します。

なお、デジタル署名とHMACのどちらを使用してもScalarDLのビザンチン故障検知の能力に影響を与えることはありません。

もしScalarDLを利用するアプリケーションが否認防止性を必要とする場合⁴は、デジタル署名を使用してください。もしScalarDLを利用するアプリケーションが否認防止性を必要としないのであれば、性能上の観点からHMACの利用をおすすめします。

ScalarDLにおける認証方法に関するさらなる情報についてはドキュメントをご参照ください。

[1]: ここでのメッセージとは、ScalarDLにおけるクライアントのリクエスト、アセットレコード、アセットプルーフのことを指しています。
[2]: ここでは、真正性とはメッセージが改ざんされていないということ、認証とはメッセージの作成者を識別すること、否認防止性とは受信されたメッセージが本当に送信者によって作成されたものであるということを第三者に証明出来ること、という意味で使用しています。
[3]: デジタル署名は秘密鍵の所有者しかその署名を作成出来ないという性質があるため否認防止性を保証できます。
[4]: 否認防止性は、例えばアプリケーションがScalarDLからデータを読み出した後にそのデータが改ざんされていないことを保証したい場合、等で必要となります。

メータリング機能の追加によりScalarDLコンテナをAWS MarketplaceのPay-as-you-goで利用可能になりました

ScalarDL 3.7以前はAWS MarketplaceにおけるLedgerおよびAuditorのコンテナイメージはBring Your Own License(BYOL)で提供されていたため、利用する際は別途弊社とのライセンス契約が必要でした。

ScalarDL 3.8からは、AWS Marketplace Metering Service APIに対応したことにより、コンテナの使用量に応じて自動的に料金が請求されるため、AWS Marketplaceからコンテナイメージを利用する際に弊社との直接のライセンス契約は不要となりました。これにより簡単な手続きでScalarDLの機能をご利用いただけるようになりました。

使用料金は1コンテナにつき1時間単位で計算されます。また、これらのコンテナイメージを動作させるインスタンスは、現状では最大2vCPUおよび4GBメモリのインスタンスで動作します。

AWS MarketplaceにおけるScalarDLコンテナに関するさらなる情報についてはScalarのAWS Marketplaceをご参照ください。

環境変数を利用してClient SDK, Ledger, Auditorの設定が可能になりました

ScalarDL 3.7以前はClient SDK、Ledger、Auditorの設定ではパスワードや秘密鍵等の機密情報もプロパティファイルに直接記述しなければならず、機密情報が記載されたプロパティファイルをScalarDLが動作するノードのディスク装置に書き込む必要があったため、第三者に機密情報が漏洩してしまう危険性がありました。

ScalarDL 3.8からはこれらの設定値を環境変数から設定することが可能になり、より高いセキュリティでScalarDLの運用が実現出来るようになりました。

ScalarDL 3.8では、従来のようにプロパティファイルに<項目名>=<値>のように直接値を記述することに加え、<項目名>=${env:<環境変数名>}のようにプレースホルダーを記述することで当該環境変数に設定した値を反映させることが出来るようになりました。より詳細な情報についてはConfigUtilのJavaDocをご参照ください。

また、弊社が提供するDockerのコンテナイメージを使用する場合、コンテナの構成ファイル（docker-compose.yml等）に環境変数を設定することでClient SDK、Ledger、Auditorの設定値をセットすることが可能となります。これにより、ScalarDLを利用する際にプロパティファイルを新しく作成し別途メンテナンスする必要がなくなり、よりセキュアで簡単に運用管理が可能となります。

弊社が提供するDockerのコンテナイメージを使用する際に利用可能な環境変数の情報に関しては以下の情報をご参照ください。
- ClientConfigのフィールド値
- AuditorConfigのフィールド値
- LedgerConfigのフィールド値

まとめ

多くの新機能や改良点が盛り込まれているScalar DLの新しいバージョン3.8をリリースしました。Scalar DLについては過去のブログやドキュメントをご参照ください。その他、ScalarDLに関するご質問、ご要望等についてはこちらまでお問い合わせください。