テクノロジー・リーダーシップ

デジタル化の促進によるセキュリティー要件の変化とコンフィデンシャル・コンピューティング

2021年5月19日

記事をシェアする:

最近注目されているコンフィデンシャル・コンピューティング。これを活用しながらゼロトラストモデル上で、安心してDXを実現するための考慮点を解説します。

テレワークの普及と生産性向上のために、業務のデジタル化が進められています。今まで人手で行っていた企業間、企業内取引がクラウド上で自動的に実行されることで、既存業務の効率化や、今まで考えられなかった新しいビジネスが可能になると言われています。一方、セキュリティー・インシデントによる情報漏洩がマスコミなどで話題に上ることは、残念ながら珍しくありません。

日本で業務のデジタル化を制約している要素の一つに、ハンコを使う習慣があると言われています。ハンコは、契約書や伝票など業務書類に対する同意や確認を表現・記録するために使われます。これは、ハンコの所有者の意思により押印され、他者が偽造・改竄することが困難であるとみなされているからです。

デジタルの世界では、電子署名でハンコと同様なことをデジタルで行うことができます。デジタルデータは一般的に複製が容易なため、例えば、台帳などに「承認します」「確認しました」などの平文を記録することは誰でもできる可能性があります。契約書など押印の対象となる業務書類も、平文であれば容易に改竄できてしまう可能性があります。

電子署名を使う場合は、署名鍵がハンコに相当します。特定の署名鍵を持っていない人が行った署名、署名対象の業務書類の改竄は、署名を検証することで容易に検出できます。検出できないように電子署名や署名鍵を偽造したり、署名対象を改竄することは数学的に困難とされています。

図1：ハンコと電子署名。ハンコの場合は印影を登録されたものと比較して検証し、電子署名の場合は検証用の鍵、電子署名、署名対象の電子データから検証結果を計算します。

しかしながら、署名鍵自体が盗まれた場合、ハンコが盗まれたのと同様に、他者が本来の署名鍵の所有者になりすまして署名を行うことが可能になってしまいます。特に、クラウド上で業務処理を行う場合、署名鍵がクラウド上にあり、クラウド上で電子署名ができることが望ましいのですが、署名鍵が盗まれないようにすることが極めて重要になります。

署名鍵もデジタルデータの一種ですから、情報漏洩により盗まれる可能性があり、特に、ミッション・クリティカルな業務をクラウドへ移行するためには、クラウドのセキュリティー、特に署名鍵の扱いに注意する必要があります。

以下では、クラウドインフラと業務アプリケーションの両方の側面から、安心して署名鍵をクラウド上で扱う方法を考えたいと思います。

コンフィデンシャル・コンピューティング

情報漏洩を防ぐために、データを暗号化して保管、通信することは広く行われています。特に、署名鍵はセンシティブなデータであるため、ファイルに保管する場合は、通常暗号化した状態で保管します。

つまり、他者がファイルにアクセスできたり、ファイルを保存するディスク装置を盗むことができても、署名鍵を取り出して署名を行うことはできません。また、暗号鍵を送受信する通信を傍受できても、通信が暗号化されていれば、署名鍵を取り出すことはできません。これら、データの保管・通信に加え、データの使用時にも不正アクセスや改竄を防ぐ、コンフィデンシャル・コンピューティングが昨今注目されています。

署名鍵の場合、保管するときや通信するときに暗号化されていても、署名を行う時点では暗号を解く必要があります。復号化された署名鍵は一時的ではあるものの、コンピューターのメモリ上に保管されます。コンピューターに侵入者がいて、そのメモリをアクセスできると、侵入者は復号化された署名鍵を盗むことができ、それを使って本来の鍵の所有者になりすまして電子署名をすることが可能になってしまいます。どのような時に他者がメモリ上の署名鍵にアクセスできてしまうのでしょうか？

実は、コンピューターの管理者は通常、全てのメモリにアクセスすることができてしまいます。一般的には、コンピューターの管理者は様々なリソースを管理したり、問題発生時の原因特定のため全てのリソースにアクセスできる権限を持っています。例えば、管理者は業務アプリケーションのメモリのスナップショットをファイルに書き出すことができます。これは、業務アプリケーションやその実行環境にバグなど問題がある時、その解決方法としては大変有効な手段です。しかし、この権限が悪用されると、復号化された署名鍵を取り出すこともできてしまいます。

クラウド・コンピューティングの場合、管理者にはクラウド・インフラの管理者とその上で動く業務アプリケーションの管理者が含まれます。前者は、IBM CloudであればIBM Cloud管理者であり、後者はIBM Cloudを利用するテナント企業の管理者になります。当然ながら、これらの管理者がクラウド上の業務アプリケーションに侵入したり、署名鍵を取り出し悪用することは考えられません。と言うのも、管理者によるアクセスは記録が残るため、犯人は容易に特定されます。さらに、管理者は雇用契約や倫理規定で、管理者権限を悪用できないように通常定められているからです。

これは、クラウド・インフラや業務アプリケーションの運用によって安全性を確保しているので、オペレーショナル・アシュアランスと呼ばれます。更なる安全性を実現するために、管理者であっても、管理者権限の悪用を技術的に不可能にする、テクニカル・アシュアランスの必要性が高まってきています。

すなわち、管理者であっても、復号化した署名鍵を取り出すことが技術的にできないようにする必要があります。このためには、コンフィデンシャル・コンピューティングが有効です。コンフィデンシャル・コンピューティングを使えば、管理者であっても復号化した署名鍵にアクセスすることはできません。またコンフィデンシャル・コンピューティングはテクニカル・アシュアランスに必要な技術要素とも言えます。

特に、電子署名や暗号化など、暗号技術を使う計算においてコンフィデンシャル・コンピューティングを実現する方法として、ハードウェア・セキュリティー・モジュール（以下HSM）という専用のハードウェアがよく使われます。HSMが署名鍵を生成するとき、通常、HSMは署名鍵を暗号化してから業務アプリケーションに渡します。このため、HSMの外ではこの暗号化された署名鍵を使うことはできません。

業務アプリケーションで署名を行うときは、必ずHSMにこの署名鍵と署名対象のデータを渡し、HSMは内部で署名鍵の暗号を復号化して署名を行います。いかなる管理者であってもHSMの内部にはアクセスできず、復号化された署名鍵が漏洩することを防いでいます。HSMが侵入を防ぐ防御能力は、その実装に応じて大きな幅があり、米国政府機関NISTがセキュリティ要件を4段階で定義しています。

IBM CloudはHyper Protect Crypto Servicesという電子署名・暗号化を行うサービスを提供していますが、このサービスが使用するHSMはNIST標準で最高レベルの認定^※を受けていて、一般的なクラウド・サービスが使用するHSMの中でも最高のセキュリティー要件を満たしています。

※ National Institute of Standards and Technology (アメリカ国立標準技術研究所）の定める、FIPS 140-2 Security Requirements for Cryptographic Modulesというセキュリティー要件標準規格の内、Level4という最も高いセキュリティー要件を満たすことが認定されています。

HSMは電子署名・暗号化においてコンフィデンシャル・コンピューティングを提供しますが、汎用の業務アプリケーション全体を実行することはできません。このため、IBMでは2018年からHyper Protect Virtual Serversという汎用の計算についてコンフィデンシャル・コンピューティングを行うプラットフォームをIBM Cloudで提供しています。すなわち、業務アプリケーションをHyper Protect Virtual Serversで実行する場合、IBM Cloud管理者であっても、復号化した署名鍵など使用中のデータにアクセスすることはできません。

テクニカル・アシュアランスの実現に向けて

では、コンフィデンシャル・コンピューティングを提供するプラットフォームで業務アプリケーションを動かせば必ず完全なテクニカル・アシュアランスが実現できるのでしょうか？残念ながら答えはノーになります。ここでは、2つの課題を考えます。

まず、コンフィデンシャル・コンピューティングが期待した効果をもたらすには、業務アプリケーション自体が信頼できる必要があります。例えば、アプリケーション開発者がいわゆるバックドアを仕組んだり、他者がアプリケーション・コードを改竄してしまうと、プラットフォームがコンフィデンシャル・コンピューティングを提供していても、アプリケーション自体から署名鍵やその他の機密情報が漏洩する可能性が存在します。この可能性を排除するには、業務アプリケーションが監査可能で、万が一改竄が発生した場合、検出可能である必要があります。

IBM CloudではSecure Build Serverというアプリケーションのビルド環境を提供していますが、これはアプリケーションのビルド自体をコンフィデンシャル・コンピューティング環境で行うものです。ここでは、生成されたアプリケーション・バイナリを署名することで、バイナリに対する改竄を署名検証により検出可能にしています。さらに、コンフィデンシャル・コンピューティングにより署名鍵が保護されるため、他者が署名鍵を悪用することを防いでいます。さらに、使用したアプリケーションのソースコードにも署名を行って保管するため、ソースコードに対する監査を可能にしています。

もう一つの課題は、署名鍵の使用に対する管理です。先ほども述べましたが、HSMで署名鍵を暗号化する場合、その鍵はHSMの外では事実上使うことはできません。このため、外部からの侵入者が暗号化された署名鍵を盗むことがあっても、セキュリティー・リスクは極めて小さいと言えます。ここで、暗号化された署名鍵がデータベースに保管されているとしましょう。業務アプリケーションの管理者であれば、HSMやデータベースへのアクセス権限を持っていることは少なくありません。この場合、管理者はデータベースから暗号化された署名鍵を取り出し、その鍵をHSMに送信することで、暗号化されている署名鍵で署名ができてしまいます。このような事故を防ぐためには、管理者であってもデータベースにアクセスできないように設定し、管理者の知らない暗号鍵を使って署名鍵をさらに暗号化する多重の暗号化などの対策が考えられます。

図2：テクニカル・アシュアランスを実現する署名サービスの例。コンフィデンシャル・コンピューティング環境で動く署名サービスは内部生成したパスワードでデータベースを作成し、HSMで生成・暗号化された署名鍵をさらに内部生成された暗号鍵で暗号化してからデータベースに保存します。署名サービスで生成したパスワードや暗号鍵は管理者であっても取り出せないため、管理者であっても、データベースに保存された署名鍵を使って署名はできません。

ミッション・クリティカルな業務アプリケーションをクラウド上で実現するにはセキュリティーは最も重要な要素と言えます。その中でも、安心してクラウドを使うには、テクニカル・アシュアランスは重要な特性と言えます。コンフィデンシャル・コンピューティングは、データの使用時にその漏洩を防ぐ重要な技術であり、テクニカル・アシュアランスの実現には必要な技術でありますが、それだけでは必ずしも十分とは言えません。ゼロトラストを想定する場合は、開発者や管理者が事故を引き起こすことも想定し、業務アプリケーション自体を検証・監査する仕組みや、管理者による署名鍵の使用をコントロール可能にする業務アプリケーションの設計などが必要になってきます。