【ITニュース解説】License Revocation: Making a Key Stop Working, Online and Offline

システム開発において、ソフトウェアのライセンス管理は非常に重要な要素だ。ソフトウェアが顧客に届けられるとき、通常は「キーの発行」というプロセスを経て、利用に必要なキーが生成され、署名され、顧客に渡される。しかし、ライセンス管理のもう半分、そして「本当のエンジニアリング」が求められるのが、そのキーの機能を停止させる「ライセンスの取り消し」というプロセスだ。顧客が返金を要求した場合、不正にキーがインターネット上で共有された場合、クレジットカードのチャージバックが発生した場合、あるいは会社を退職した従業員が会社のライセンスキーを保持している場合など、さまざまな状況で、すでに顧客のPCに存在するキーの機能を停止させる必要が生じる。この停止させる仕組みがライセンスの取り消しであり、これはオンライン環境とオフライン環境で大きく動作が異なる。

ライセンスの取り消しとは、ソフトウェアの販売元が「このキーKはもう有効ではない」と署名付きで宣言することに他ならない。これは顧客のPCから何かを削除するような動作ではない。そうではなく、アプリケーションが次にそのキーを評価する際に、「無効」と判断するように振る舞いを変更するのだ。つまり、この問題は「アプリケーションが次にキーを再評価するのはいつか、そしてその時に取り消しの情報を十分に早く受け取れるか」という一点に集約される。この認識は非常に重要で、正直な期待を設定することになる。ライセンスの取り消しは、決してすべての場所で瞬時に適用されるわけではない。開発者が制御できるのは、取り消しが宣言されてから、そのキーが特定のPC上で無効になるまでの「露出ウィンドウ」をどれだけ短くできるかという点だ。このウィンドウをリスクに対して十分に小さくすることが開発者の役割であり、その期間がゼロだと偽るべきではない。

最も一般的なケースは、インターネットに接続されているアプリケーションでの取り消しだ。この場合、開発者はサーバー側でキーを「取り消し済み」とマークする。そして、クライアントアプリケーションが次にサービスと通信する際、例えばライセンスの再検証、再アクティベーション、あるいは定期的な死活監視（ハートビート）といったタイミングで、サービスは「このキーは取り消し済みだ」と応答する。これを受けてクライアントアプリケーションはライセンスなしの状態に移行し、機能を停止する（これを「フェイルクローズ」と呼ぶ）。

このオンラインでの取り消しにおける「露出ウィンドウ」は、アプリケーションがライセンスを「再チェックする間隔」によって決まる。一般的に、アプリケーションは毎回サーバーに問い合わせることを避けるため、ライセンスの有効性を一定期間キャッシュする。これを「ノードロックリース」と呼び、例えば24時間の有効期限を持つリースであれば、その期間中はオフラインでもアプリケーションが動作する。しかし、この便利なキャッシュ機能が、取り消しを遅らせる原因にもなる。もしリースの有効期限が24時間であれば、取り消されたキーは最大24時間、そのPC上で機能し続けてしまう可能性がある。この露出ウィンドウを短くするには、リースの有効期限を短縮すれば良い。しかし、その代償として、アプリケーションはより頻繁にインターネット接続を要求することになり、ユーザー体験に影響を与える可能性もある。このリースの有効期限をどれくらいにするかは、漏洩したキーや返金されたキーがもたらすリスクを考慮して決定すべき設計上のトレードオフだ。一つ注意すべき点は、アプリケーションがライセンスの取り消しを検出した際には、必ずキャッシュされているリース情報をクリアすることだ。これを怠ると、取り消しが宣言された直後にアプリケーションがオフラインになってしまった場合、期限切れになるまで古いキャッシュされたリース情報を使ってライセンスが有効であると判断し続けてしまう可能性がある。

一方、完全にオフラインで動作する、あるいは外部ネットワークから完全に遮断された（エアギャップ）環境のクライアントアプリケーションは、サーバーとの通信を行わないため、「次にチェックインした時に取り消し」というオンラインの方法は適用できない。この問題に対する解決策は、ネットワークなしでもクライアントが信頼できるデータとして、取り消し情報をクライアントに届けることだ。その手段が「署名付き取り消しリスト」（一般にはCRL、Certificate Revocation Listの概念）である。ベンダーは取り消されたキーのIDを一覧にしたリストを作成し、そのリストに、ライセンス自体を署名する際に使用したのと同じ秘密鍵でデジタル署名を行う。この署名付きリストは、ソフトウェアアップデートに同梱されたり、管理ツールを通じてプッシュされたり、あるいは完全に隔離されたシステムのためにファイルとして持ち運ばれたりして、クライアントに配布される。

クライアントアプリケーションは、この署名付き取り消しリストをロードし、内部に埋め込まれている公開鍵を使って、そのリストのデジタル署名を検証する。署名が正しく検証されれば、そのリストの内容がベンダーによって発行されたものであり、改ざんされていないことを信頼できる。その後、アプリケーションは現在使われているライセンスキーのIDが、このリストに含まれているかどうかを確認する。もしリストに含まれていれば、そのキーは既知の不正なキーとして判断され、ネットワークに接続していなくてもライセンスなしのモードに移行する。このデジタル署名が非常に重要だ。クライアントはオフラインでリストを受け入れる必要があるため、リスト自体がライセンスと同様に、その信頼性を証明する仕組みを持たなければならない。もし攻撃者が偽造されたり、自分自身のキーの取り消し情報が削除されたりしたリストをアプリケーションに提供できたとしたら、この仕組みは簡単に破られてしまうだろう。しかし、署名されているため、改ざんされたり一部が削除されたりしたリストは署名検証に失敗し、アプリケーションによって無視されることになる。このオフラインでの取り消しにおける遅延は、取り消しリストがクライアントに配布される「配布間隔」に依存する。オンラインでの取り消しよりも遅くなる傾向があるが、これにより隔離された環境のインストールであっても、返金されたり漏洩したりしたキーに対して永久に無防備になることが防がれる。

全てのライセンスの取り消しが、悪意のある状況で発生するわけではない。顧客が誤ってチャージバックを申請してしまったり、顧客に何の落ち度もないにもかかわらずキーが漏洩してしまったりすることもある。そうした正当な理由を持つ顧客には、依然としてソフトウェアを利用する権利が与えられるべきだ。そのため、ライセンスの取り消しは、新しいライセンスの「クリーンな再発行」と組み合わせて考える必要がある。古い、あるいは侵害されたキーを取り消しリストに登録して無効にし、顧客には新しく有効なキーを改めて発行して、それをアクティベーションしてもらうのだ。古いキーは取り消しリストに載っているため、どこに伝播しても無効になるが、新しいキーはリストに載っていないため正しく機能する。このようにして、漏洩したキーと新しいキーが正しく共存できる。一度取り消されたキーを「取り消し解除（un-revoke）」するという誘惑に駆られるかもしれないが、それは避けるべきだ。取り消されたキーは永久に取り消されたままにすべきであり、顧客は新しい資格情報へと移行してもらうのが正しい運用方法だ。

ライセンスの取り消しは、開発者に対して「取り消されたキーが、各マシン上でどれくらいの期間動作し続けることを許容するのか」という明確な決定を強制する。オンライン環境では、これはライセンスのリース期間や再チェックの間隔によって決まる。オフライン環境では、ソフトウェアアップデートの配布間隔と取り消しリストの更新頻度の組み合わせによって決まる。これらの期間は、安易な慣習ではなく、実際に発生しうる「リスク」に基づいて設定すべきだ。例えば、再販された場合に大きな損害が生じる可能性のある高価値な企業向けライセンスであれば、短いリース期間を設定し、取り消しリストを頻繁に更新することが正当化されるだろう。一方で、安価なシングルユーザー向けツールであれば、一日程度の遅延は許容できるかもしれない。しかし、最も避けなければならない間違いは、この期間を暗黙のうちに、つまり無意識に決めてしまうことだ。例えば、30日間のキャッシュリースを何の考えもなく採用してしまい、後になって返金されたはずのキーが4週間も動き続けていることに驚くような事態だ。ライセンスの発行は、ソフトウェアの利用権を世に送り出す行為だ。それに対して、ライセンスの取り消しは、一度発行された利用権に対して、その後も管理者が権限を維持するための重要な手段である。発行のみが可能で取り消しができないライセンスシステムは、一見完成しているように見えても、実際には不完全なシステムと言えるだろう。