Hideki EIRAKU

AWS 等クラウド利用時のセキュリティ確保理論につき、 【説 1.】 CSP 完全依存アプローチ (顧客はクラウド基盤の適切なセキュリティ設定をすればCSP領域に脆弱性があっても保護される。CSP が全部責任を負う)。 【説 2.】 CSP 約款で「実は CSP は責任を負わない」として 12 ヶ月分の払戻以外は全額免責されることからも、CSP のクラウド特権領域ソフトウェアの脆弱性・サイバー攻撃・運用過失に基づく結果責任は、顧客が負う (実は保護されない) から、結局顧客は普段から自ら暗号化レイヤを入れ自衛を要する (実は、顧客の責任である)、という考え方。 の 2 つの考え方があり、技術者でも、説 1 が正しいと無意識に信じて社内外で説明してきた人が多いように見えます。そのような場合は、説 1 は幻影で、現実は説 2 だということを知り、説 2 に応じた対策をしないといけないところです。 そうすると、問題を直視したくない、説 1 派だった人からは、「料金が 12 ヶ月分しか払い戻されないのは業界標準だから説 2 を唱えるのはおかしい」 (?) という変な説が出てくるのですが、「損害賠償が 12 ヶ月分の払い戻しに留まることが業界標準であるかどうか」は、問題である説 2 の対策の必要不要とその実施方法とは全く無関係です。むしろ単に業界の AWS 以外の他のクラウドやその他の IT サービスも、結局皆【説 2】の対策が必要だということを強調する結果になるに過ぎません。 lts.dnobori.jp/d/260321_002_0… なお、【説 2】に対して、「AWS 等のパブリッククラウドを使うなということか」「オンプレミスに戻れというのか」とさらに変な説が出てくることがあるようですが、【説 2】は、単に、パブリッククラウド特権領域の脆弱性を想定して、クラウドユーザーが CSP の提供する暗号化機能、バックアップ機能 "以外" の手段で自前で E2EE 暗号化 (自前 HYOK), 別のクラウドまたはオンプレへのバックアップをすれば良いだけであり、現在の AWS 等のパブリッククラウドはそのまま使い続けることができます。したがって、「AWS 等のパブリッククラウドを使うな」「オンプレミスに戻れ」ということにはならないと想います。 また、暗号化に係るコストはほとんどゼロだと思います。たとえばディスクの追加暗号化であれば、IaaS 上の OS が Windows であれば BitLocker (鍵は仮想 TPM ではなく、ブート後に入れる必要がある。仮想 TPM の中身は CSP を攻略した攻撃者から保護されない可能性が高いので)、Linux であれば LUKS 等の AES 暗号でたいてい足り、鍵を仮想ディスクに置かずにブート時に別クラウドまたはオンプレから HTTPS で取得すればたいてい足ります。これらの透過型ソフトウェアは追加コストなく利用でき、現代の CPU では処理時間はほとんどかかりません。DB の暗号化であれば、IaaS 上で動かしている RDBMS の暗号化可能を使い、その暗号鍵は同じくリモートから取得すればたいてい足ります。これらを施せば、アプリケーションは一切変更せず動作します。 これらの暗号化は、もともと【説 1】で CSP に依存して暗号化していた部分に重ね併せて行なわれるので、万一失敗しても (例: 鍵をディスク上に置いてしまっていた、CSP の IaaS 基盤に侵入した攻撃者からライブカーネルデバッグ等をされて侵入され鍵を奪取されたなど)、すくなくとも、今の CSP 任せの状態よりセキュリティが下がることはありません。