Shin Yamasaki

一般社団法人日本ネットワークインフォメーションセンター勤務
インターネットの政策に関心を持つ。

[Shin Yamasaki @syjpn23]

ICANN86の報告記事を執筆しました。https://t.co/Xy5d1CdmlT

[情報ネットワーク法学会運営担当 @inlawjp]

「ネット社会法務研究会第12回研究会」が以下のとおり開催されますのでご案内いたします。皆様のご参加をお待ちしております。

【日時】2026年8月6日（木）18:30～
【場所】
関西大学梅田キャンパス701会議室　(〒530-0014 大阪府大阪市北区鶴野町1-5)
及びリモートのハイブリッド開催
（続く）

[Masayuki Hatta @mhatta]

日本インターネットガバナンスフォーラム（Japan IGF）という団体ができまして、定例で勉強会をやるのですが、来週金曜の初回は不肖わたくしがオンライン年齢認証とかについてお話することになりました。お気軽にご参加ください。

https://t.co/cXzqzwLwhI

[nekono_nanomotoni @nekono_naha]

国内メールサービス事業者への不正アクセスやメール基盤製品のゼロデイ攻撃が去年から多い印象だった改めて整理したら思ってたより連続してて流石に不穏すぎる。特定勢力が意思を持ってあちこち探ってる雰囲気もするので要点検/警戒かも。詳細は以下Webアプリでどうぞ
https://t.co/wDftKqAc2M

[Hiromitsu Takagi @HiromitsuTakagi]

実際、当時の旧法案は「居酒屋で与太話もできなくなる」法案でしたが、2002年末に廃案、問題の「基本原則」を削除して成立したのが現在の同法であり、懸念は払拭されていたのです。しかし、今国会で審議中の同法改正案で新設される「個人情報取得罪」はその懸念の再来です。
https://t.co/T8fA24lbDa

[IGF - Internet Governance Forum @intgovforum]

📢 Announcing the IGF Multistakeholder Advisory Group (MAG) for 2026

We’re pleased to share the newly appointed members 🌐
👉 Full list: https://t.co/HILmK0C3IA

🙏 Thanks to outgoing MAG members for strengthening the #IGF multistakeholder model

ℹ️ https://t.co/nkZhrsLoPk

[Nat Sakimura/崎村夏彦 @_nat]

なんか、欧米の「子供の保護」を看板にした法規制、変な方向に行っているな。年齢確認の為に政府発行の公的身分証明書をアップロードさせるなんて不必要だし有害だ。Section 230の廃止を求める動きもあるようだし、自由なインターネットは死につつあるのかもしれない。

以下、引用ポストからの一部翻訳

子どもを守るための法案が、大人の登録制度へと変貌する。大人の登録制度は、嗜好のデータベースとなる。嗜好のデータベースは、異議を唱える人々のリストとなる。その異議を唱える人々のリストこそが、国家が当初から構築しようとしていたものなのだ。

現在、25の州で、10年足らず前に最高裁が表現の自由として保護すると宣言したコンテンツにアクセスする際、身分証明書のアップロードを義務付ける法律が制定されている。同じ立法者たちが、同じ会期中に、そのインフラを拡張し、ソーシャルメディアのアカウント、AIチャットボット、検索エンジン、そしてカリフォルニア州では購入したデバイスのOSにまで適用しようとしている。

現在委員会で審議中のミズーリ州の次の法案は、14歳から16歳までの者がソーシャルメディアアカウントを開設する際に親の同意を義務付け、14歳未満のアカウント開設を全面的に禁止するものだ。その次の法案は別の対象を、そのまた次の法案はさらに別の対象を規制することになるだろう。

[APrIGF @aprigf_official]

📢 Announcing the overarching theme for #APrIGF2026: “Safeguarding a Resilient Internet in Times of Crisis.” 🛡️🌐

Join us in shaping a more resilient Asia Pacific.

More updates coming soon! 🌏💻 #InternetGovernance #APrIGF #TechPolicy #DigitalResilience #DigitalFuture #APAC

[UN Office for Digital and Emerging Technologies @ODET_UN]

One more week to be heard. Deadline extended.

The deadline for the AI Dialogue has moved to 7 May.

1,000+ submissions in — add your input before the window closes.

🔗 https://t.co/KVSAp3x2HM

#AIGovernance #AIDialogue #AIStakeholderConsultation

@ODET_UN @UNESCO @ITU

[野田隼人 Atty. NODA Hayato J.D. @nodahayato]

裁判所とあるけれど政府調達全体の話だけれど裁判所。

[IGF - Internet Governance Forum @intgovforum]

📢 IGF 2026 announced!

The 21st Internet Governance Forum will take place in Nairobi, Kenya 🇰🇪, 14–18 Dec 2026. 🌍 Stay tuned: https://t.co/CPGj6ViKgs

New to IGF? https://t.co/N3Ms5bYbG2

[ゆき @flano_yuki]

『Internet Protocol Version 8 (IPv8)』
https://t.co/edlj8PCvCF

お、なんかIPv8という提案仕様がIETFに提出されてる

[わいとん @ytnobody]

Adobe Creative Cloudがhostsファイルを無断で書き換えてることが判明。目的はWebからCC導入検出のため。
意図はともかく、管理者権限が必要なシステムファイルをユーザーの同意なく変更するのはマルウェアと同じ手口。企業環境でアラート発報の報告も。↓

[田中邦裕社長＠さくらインターネット @kunihirotanaka]

さくらインターネットは、本日正式に政府共通のクラウドサービスの利用環境である、「ガバメントクラウド」に正式認定されました。
これまで支えて下さった全ての方へ感謝すると共に、これからの信頼できるクラウドインフラの提供をお約束致します。 #ガバメントクラウド

https://t.co/UONkrTsfOA

[Yu F @fj_twt]

( ꒪⌓꒪)…これ、なんか「ブロッキングする前提」感が濃くないか?

違法有害情報のブロッキングにかかる立法措置の論理的なお膳立て（外堀埋め）になりやしないか?

[Daiyuu Nobori (登 大遊) @dnobori]

AWS や Azure・M365 のクラウド特権基盤領域に係る CSP 側管理の過失やサイバー攻撃発生時に CSP が責任の大半を負わないことに係る QA を自分のためにまとめてみました。誤りがあれば情報をいただければ幸いです。

★ Q1. AWS や Azure・M365 のクラウド特権基盤領域に係る CSP 側管理の過失やサイバー攻撃でデータ漏洩・改ざん (※ ユーザーによるミスではなく、CSP 側の過失またはクラウド基盤ソフトウェア脆弱性による) が発生してもその法的責任の大半を実は CSP が負わないことは、一般的日本組織において、組織的に当然のこととして浸透しているであろうから、今さら議論する価値がないのでは?

Q2. AWS や Azure・M365 が、クラウド特権基盤領域に係る CSP 側管理の過失やサイバー攻撃でデータ漏洩・改ざんが発生してもほとんど責任を負わないという点は理解したが、AWS や Microsoft 以外のパブリッククラウド事業者も同様の責任上限規定を設けているのではないだろうか。そうでないパブリッククラウド事業者はあれば是非とも教えてほしい

Q3. AWS や Azure を使う場合で、SaaS のストレージサービス (例: Blob) やマネージド DB などを利用する場合、CSP 側の機能として CSP による暗号化がされるから、企業ユーザーが独自に E2EE 暗号化を施す必要はないのでは？

Q4. AWS や Azure 等で、Blob をユーザー側で暗号化することは容易だが、マネージド DB の場合、行・列単位の暗号化を CSP 側に依存できないとしたら、暗号化後のデータをテーブルに INSERT, UPDATE しなければならず、クエリでの条件演算子に制約が出る (完全一致比較はできるが、部分一致比較が困難) のではないか?

Q5. AWS や Azure 等で、IaaS VM を用いて自ら DB を稼働させ、その自らの DB プログラム (MySQL や 市販の SQL Server 等でもよい) で行単位、DB 単位およびディスク単位の暗号化をしたとしても、結局、その各暗号鍵および仮想ディスクを攻撃者に奪取されたら、仮想ディスクごと復号化されてしまい、技術的に無意味では? SaaS 型の DB と同じリスクが生じるのではないか?

Q6. オンプレミスまたは自前クラウドで動作する各種 OS においても脆弱性やこれを突いたサイバー攻撃はあり得るのだから、AWS のような大規模パブリッククラウド固有の危険ではないのではないか？

===================================================================

■ Q1. AWS や Azure・M365 のクラウド特権基盤領域に係る CSP 側管理の過失やサイバー攻撃でデータ漏洩・改ざん (※ ユーザーによるミスではなく、CSP 側の過失またはクラウド基盤ソフトウェア脆弱性による) が発生してもその法的責任の大半を実は CSP が負わないことは、一般的日本組織において、組織的に当然のこととして浸透しているであろうから、今さら議論する価値がないのでは?

→ A1. いいえ。そのことは、一般的日本組織において、まったく当然のこととして認識されておらず、むしろ「CSP が責任を負ってくれるから CSP に任せれば良い」 (ユーザー側での E2EE 暗号化は不要) との誤解が一般的に浸透しています。

　(1) 日本において最も機微な情報のデジタル技術運用を代表する立場のはずの国の機関である「デジタル庁」ですら、上記の「当然」の理論を理解せず、逆の理論を普及させる文書を政府内に作成・配布してしまっています。たとえば、以下の URL の文書では、P.1 に、大半が AWS を用いる「ガバメントクラウド」において、AWS 等 CSP にセキュリティ部分が責任を負うので、CSP に任せれば「高水準のセキュリティ対策」を「実現することが可能となる」、クラウド利用組織側は「データの暗号化や認証など」の「設定を適切に行なうことがセキュリティ対策の中心となる」と記載してしまっています。

　(2) P.21 では、クラウド利用の政府システムでは、以前は利用者の責任ですべてのセキュリティ対策の考慮を必要としたが、現代のクラウドでは「責任共有モデル」により、「クラウドが提供するものは CSP が責任を負い、利用システムはその利用について『のみ』責任を負う。」と言い切ってしまっています。加えて、「利用システムの責任は、... クラウド利用における『設定』、アカウント等に『限定される。』) とも書いてしまっています。仮に、CSP の特権領域へのセキュリティ侵害時の賠償責任につき、CSP 側は責任を負ってくれないから、利用者側でも多重暗号化をしなければならないという「当然」の認識があれば、このような記載にはならないはずです。

　(3) P.12 では、CSP の立場からみてデータを判読不能とする「利用者自身の暗号鍵」による暗号化を行なう必要は、クラウドが「国外に設置されるクラウドに保管する場合または可能性がある場合」に限定される、と記載してしまっています。CSP 特権基盤部分に対するサイバー攻撃の危険性は、国内／国外とも均しいのに、多層暗号化を「国外の場合」に限って必要とするとの記載は、上記の「当然のこと」の認識を欠くことを示します。
https://t.co/IeRoWdec1u

　(4) これらのように、国民や国家の機微な情報のセキュリティ対策の最前線にあるはずのデジタル庁においてすら、AWS や Azure・M365 のクラウド特権基盤領域に係る CSP 側管理の過失やサイバー攻撃でデータ漏洩・改ざん (※ ユーザーによるミスではなく、CSP 側の過失またはクラウド基盤ソフトウェア脆弱性による) が発生してもその責任の大半を実は CSP が負わないので、ユーザー側でもクラウド上で自前で暗号化するなど、技術的保護が必要であるという認識は、組織的に当然のこととして浸透していないことが示されます。

→ ごく一部の方々は、約款を十分読んでいて、CSP の営業ドキュメントによる「クラウド基盤部分のセキュリティは CSP が責任負ってくれる」というような期待は誤りであることを見抜いていることは、確かなことです。しかし、それは、残念ながら、今のところ、システムの全貌とセキュリティの本質的知見とをもった希有なエンジニア視点におけるかなり少ない人数のみに閉じて共有されているに過ぎない考え方だと思います。
　一般的日本型組織では、一部の詳しい例外的な技術経営者または請負業者をのぞき、このことは、組織的に十分に浸透していません。組織の情報セキュリティや情報システムを担う一般的なシステム企画管理者、企業において業者に受託開発を依頼し仕様を策定する担当者、企業において何気なく「OneDrive」や「SharePoint」、「Teams」等の Web 型 SaaS で検索可能な形で機密データをアップロードしてしまう極めて多数の社員、などの企業内一般人にも、広く浸透する必要があります。

→ デジタル庁以外にも、多数の日本大企業の話を聞いてみると、次のことが分かります:

(1) 以前は、比較的セキュリティ意識の高い大企業たちは、漏洩・改ざんされると莫大な損害が発生する営業秘密・顧客情報・個人情報は、自前運用のファイルサーバ上で、ファイルサーバ側のセキュリティと透過暗号化だけでなく、E2EE 暗号化ソフトも入れて厳重に保護していました。

(2) ところが、おおむね 2020 年代以降、それらの機密ファイル群をそのまま「ファイルサーバーのクラウド移行」として、Microsoft 365 の「SharePoint」や「OneDrive」にアップロードし、Teams からも連携できるようにして、この際、①「Microsoft 365 では、クラウド側でデータ漏洩・改ざんに係るセキュリティの責任を取ってくれる」、②「E2EE 暗号化したままだとクラウドの便利な検索機能、AI 連携機能が使えない」という理由で、"E2EE 暗号化をあえて解除して" 移行している例が、名だたる複数の大企業に見られます。

(3) このことについて、危ないなと考えて警戒し、会社の将来の損害予防のために、自らの管理する機密ファイルだけは E2EE 暗号化した上で Microsoft 365 を利用するという技術的理解度の高い優れた社員は、ごく一部に限られます。「CSP が実は責任を負わないのは、約款をよく読めば、当然のことだ」と考える技術経営者的人材は稀少であり、例外的です。組織的にみると、① の誤った理解が多数を占めているので、機密情報の大半は、E2EE 暗号化なしで、保護の責任の担保として 1 年分の料金払戻請求権しか負わないクラウド事業者に預け入れられています。

　このように、AWS や Azure・M365 のクラウド特権基盤領域に係る CSP 側管理の過失やサイバー攻撃でデータ漏洩・改ざん (※ ユーザーによるミスではなく、CSP 側の過失またはクラウド基盤ソフトウェア脆弱性による) が発生してもその賠償責任の大半を実は CSP が負わないという前提は、一般的日本企業において組織的に当然のこととして浸透しているという点は、誤りであると思います。

　そこで、日本企業社会において、このことの組織的浸透を目指すとともに、AWS や Azure・M365 のクラウドを利用する際において最低限必要な対策を一般化することを検討することには、大きな現代的価値があります。

===================================================================

■ Q2. AWS や Azure・M365 が、クラウド特権基盤領域に係る CSP 側管理の過失やサイバー攻撃でデータ漏洩・改ざんが発生してもほとんど責任を負わないという点は理解したが、AWS や Microsoft 以外のパブリッククラウド事業者も同様の責任上限規定を設けているのではないだろうか。そうでないパブリッククラウド事業者はあれば是非とも教えてほしい

→ A2. 今、とるべきアクションは、「責任上限規定がない高額なクラウドまたは VM 運用業者を探すこと」ではないと思います。そうではなく、どのようにして、比較的安価であるがそのままでは危険な AWS や Azure・M365 等を、安価なまま、企業ユーザー側が、低コストの対策を行なって安全に使うか、という点にあると思います。

→ 米国系の著名なクラウドを安価に利用する場合であっても、CSP が法的責任を負わないとしている、12 ヶ月分の料金払い戻しを超えた部分の責任 (要するに、ほとんど 99% の部分の責任) にかかる安全策を、顧客自身が CSP に依存せず、安全に自ら担保できるようにするためには、以下の 3 手順が有益と思います。

　(1) まず、CSP 約款が、実は「CSP 自身の過失やクラウド特権領域の脆弱性で全データが漏洩・改ざんされても、ほとんど責任を負わない」という重要な点を認識しておらず、「責任を万全に負ってくれている」と組織的に誤信している多数の日本企業やそのメンバー (前述のとおり) が、その点を認識できるよう支援することです。この認識が一般的に理解されてはじめて、(2), (3) の対策の検討に移れます。

　(2) 次に、パブリッククラウドを利用しつつも、クラウドにアップロードする機密データを E2EE 暗号化 (クラウド側の BYOK, HYOK あるいは SaaS 領域のクラウド側処理による暗号化は、前述のとおり、過失・脆弱性があっても責任を負ってくれないので、それよりも前の段階、すなわちクラウドにアップロードする前に暗号化をする) した上でクラウドに保管するルールを確実化し、組織的に浸透することです。

　(3) そして、単一のクラウド事業者にデータ本体もバックアップもあると、当該クラウド事業者に対する特権基盤部分に対するサイバー攻撃でデータ本体もバックアップも改ざん、ランサムウェア暗号化あるいは消去されるリスクが高いので、定期的なバックアップ先は異なるクラウド事業者、あるいはオンプレミスのストレージや NAS 等に取るというルールを確実化し、組織的に浸透することです。

===================================================================

■ Q3. AWS や Azure を使う場合で、SaaS のストレージサービス (例: Blob) やマネージド DB などを利用する場合、CSP 側の機能として CSP による暗号化がされるから、企業ユーザーが独自に E2EE 暗号化を施す必要はないのでは？

→ A3. 今回の技術的問題は、クラウド特権基盤領域に係る CSP 側管理の過失やサイバー攻撃でデータ漏洩・改ざんが発生した場合に、CSP はほとんど責任を負ってくれないから、代わりにユーザー自ら暗号化で対策をしなければならない、という点です。

→ たとえ SaaS のストレージサービス (例: Blob) やマネージド DB などを利用する場合で CSP 側の機能として CSP による暗号化がなされているとしても、その部分のサービスコードに係る脆弱性を攻撃者が突いた場合は、その暗号化は攻撃者によって可読となってしまいます。加えて、IaaS の EBS のようなストレージの場合 (個別のユーザーが個別具体的にファイルシステムや透過型暗号化、アプリケーション上の暗号化を行なうことができる) と比較して、機密情報として価値がありかつ単一の操作で平文展開ができることが確定している SaaS データは、1 の攻撃コストで、全テナントの全データが奪取可能で、攻撃の費用対効果が全然異なります。

→ したがって、CSP の暗号化機能とは別に、企業ユーザーが自ら独自に暗号化する必要があります。

===================================================================

■ Q4. AWS や Azure 等で、Blob をユーザー側で暗号化することは容易だが、マネージド DB の場合、行・列単位の暗号化を CSP 側に依存できないとしたら、暗号化後のデータをテーブルに INSERT, UPDATE しなければならず、クエリでの条件演算子に制約が出る (完全一致比較はできるが、部分一致比較が困難) のではないか?

→ A4. はい。それは SaaS のマネージド DB を用いる場合の制約事項 (仕様上の制約、トレードオフ) だと思います。そのため、SaaS のマネージド DB は、サイバー攻撃により漏洩しても差し支えがなく、「12 ヶ月分の料金の払い戻し」のみで被害回復が可能な、機微性の低いバルク的データを保管するためのものであり、機微性の高い個人情報等を保管するための場所ではないと思います。

===================================================================

■ Q5. AWS や Azure 等で、IaaS VM を用いて自ら DB を稼働させ、その自らの DB プログラム (MySQL や 市販の SQL Server 等でもよい) で行単位、DB 単位およびディスク単位の暗号化をしたとしても、結局、その各暗号鍵および仮想ディスクを攻撃者に奪取されたら、仮想ディスクごと復号化されてしまい、技術的に無意味では? SaaS 型の DB と同じリスクが生じるのではないか?

→ Q5. その「技術的に無意味」という考え方は、魅力的な一極集中型パブリッククラウドに対する攻撃者に課せられる個別具体の IaaS VM を攻略分析するための時間プレッシャーと費用対効果の観点を無視しています。これらの時間および費用対効果の要素を加味すると、IaaS VM における自前の暗号化の追加は、SaaS の DB の CSP 側での暗号化 (たとえ鍵はユーザが管理していても同じ) と比較すると、桁違いに大きな予防効果を発揮します。したがって、技術的に大きな意味があることになると思います。

→ 通常、そのような安全構成を組み立てるとき、暗号鍵は IaaS VM 上の仮想ディスクには置かず、オンプレミスあるいは別のクラウド事業者の IaaS VM 等に置き、これを動的にネットワーク経由で取得して一定時間メモリ上に暗号鍵をキャッシュし、暗号化／復号化する、という仕組みにより、安全性を担保すると思います。これは HYOK と呼ばれますが、CSP の提供する仮想ディスク暗号化等と密接に関連するお仕着せの HYOK 暗号化 (CSP のハイパバイザの特権領域のメモリ上に鍵が保持される) と異なり、攻撃者は、VM 内部のメモリをのぞき込んで、どこに鍵があるのか干し草の山から髪の毛を拾うように丹念に探し出す必要があり、相当攻撃コストを引き上げることができます。HYOK による暗号化は自前で実装する必要があり、CSP の HYOK 機能だけに頼ることは危険です (なお、CSP の HYOK 機能にも頼り、かつ、自前暗号化にも頼ることは、デメリットはわずかな遅延増大意外にはないので、これはとても良い戦略です。一度暗号化したものを再度別に暗号化しても、暗号強度が低下することはないためです)。

→ IaaS VM 上で自ら DB 稼働させ、その上でいくつかのレベルで暗号化するとき、そして鍵は常にその IaaS VM のメモリ上にのみあり、仮想ディスク上にはないのであれば、CSP の IaaS ハイパバイザ特権領域が侵害され、ゲスト VM メモリにアクセスされても、その暗号化の構造や暗号鍵は、個々に異なります。攻撃者はテナント企業のシステムのメモリ上の内奥を 1 個ずつ点検しなければ、有意な情報を復元できません。攻撃者が仮想ディスクへのアクセスに成功しても、メモリを分析しなければデータを復号化できません。そして、ライブ状態のゲスト VM に、ゲスト VM の OS の整合性を壊さずに入ることは、カーネルデバッガを用いた個別かつ高度なデバッグ手法を必要とし、自動化スクリプトでは不能で、1 件あたり人手による時間を要します。AI による攻撃を行なう場合でも 1 件あたり数時間を要し、かつ、少しでも書き込みを間違うとライブ状態のゲスト VM の OS でメモリポインタの不整合が発生しすぐに panic または BSoD が発生しゲスト VM が再起動してしまいます。ゲスト VM が再起動すると、メモリ上の鍵が失われてしまいます。ライブデバッグでは、ハリウッド映画において爆弾処理班が登場する際において、その係員警官が、赤のワイヤを切るか、青のワイヤを切るか二択を迫られ、間違えると爆発して不可逆であるという状態に近い状況に攻撃者は追いやられます。そしてこの二分分岐が何十回もあり、すべて成功しなければ、ライブ動作しているカーネルへの外科的介入ができません。

→ これらのことから、IaaS VM 上で自前で多層暗号化する手法は、攻撃者のコストを著しく増大させ、攻撃者にリアルタイムで VM 1 件 1 件あたり長時間の作業を強いるので、仮にごく一部の VM への機密性侵害に成功し得たとしても、数万もの多数のテナント企業がありかつそれぞれに多数の VM があるとき、自らの 1 つの重要な IaaS VM が侵害されるリスクは極めて低い (その間に、攻撃者は締め出される) と思います。

→ 他方、CSP による DynamoDB や SaaS の MySQL 等の場合、攻撃者は 1 の共通的手法で、同型のすべての SaaS のすべての顧客のすべてのデータを同時に復号化して読み出すことが可能で、攻撃者が締め出されるよりも前にこれに成功する可能性は、前記の IaaS VM による独自の暗号化保護の場合と比較して桁違いに高いと思います。

→ これらのことから、リスクは全然異なり、IaaS VM 内における独自の暗号化保護には大きな価値があると思います。

Q6 は次ページに続く

[Daiyuu Nobori (登 大遊) @dnobori]

Telnet 公告社団が PPPoE ISP 固定 IPv4 アドレスサービスを本格開始

[ktgohan @ktgohan]

歴史的経緯を話すと、かつてデータセンターはほんとにだいたい「事務所」としての機能もだいたい兼ね備えていたわけです。人が働く場所でもあった。需要者が自分で建てるのが当たり前の施設だった。ところが…

ここ何年かは話がかわってきて、不動産デベがメガクラウドを誘致する見込みで建ててSPCに転売するのが前提という物件が激増した。転売前提なんすよ。いま騒ぎ起こしてる物件のほとんどは。だからやべえのよ。転売する側は地元知ったこっちゃないかんね。

[Daiyuu Nobori (登 大遊) @dnobori]

公正取引委員会のマイクロソフト社に関する通報窓口メールアドレス、裁判所メール等が、マイクロソフト社のメールサーバになっている件に関するサイバーセキュリティ視点 Q&A を自分のために書いています (Q10 ～ Q15)↓

Q1. Exchange Online の受信メールは、マイクロソフトのクラウド上で暗号化して保存されるとドキュメントに書いてある。マイクロソフトは、平文で公取や裁判所宛の受信メールに接触し、平文でこれを処理している訳ではないのではないかな?

Q2. Exchange Online のメールデータに平文で接触処理・平文透過でディスクに保管しているのは、SMTP サーバー (MTA) や Exchange Online のサービスプログラム等 (以下「プログラム A」) であって、マイクロソフト社ではないのではないかな?

Q3. Exchange Online / Microsoft 365 Enterprise では、マイクロソフト社員が顧客のデータにアクセスする際には「カスタマーロックボックス」(マイクロソフトが顧客のデータを見る際の事前承認確認機能) Web 画面による事前承認が必要な仕組みになっているから、無断でメールが見られることはないのではないかな?

Q4. マイクロソフト社が Exchange Online 上のメールに米国政府によるデータ抽出要求 (米国 CLOUD Act) によりアクセスするとしても、顧客には事前に通知されるから、顧客である日本の裁判所やデジタル庁は、それに対して異議申立てができるのではないかな?

Q5. デジタル庁とマイクロソフト社との Microsoft 365 Enterprise の契約は、日本法に準拠し、かつ日本の裁判所を専属的合意管轄裁判所としているので、米国政府にによる米国法に基づくデータ取得要求 (米国 CLOUD Act) によりアクセスされる心配はないのではないかな?

Q6. デジタル庁とマイクロソフト社との Microsoft 365 Enterprise の契約で、「米国政府からの開示要請 (非通知命令付き) があっても、これを無視するか、事前に日本政府と協議すること」という契約条項 ・・・ ① があるだろうから、マイクロソフト社は契約上、米国からの開示請求に応じることはできないのではないかな?

Q7. 仮に米国政府がマイクロソフト社に日本の裁判所のメールボックス内のメールデータの抽出を命じるとしても、膨大な数のメールの中から、特定のキーワード条件 (例: 特定の個人名文字列を含む) 等に一致するメールのみを抽出するという命令はできないのでは? そうすると全件取得せよというしかできないが、これは明らかに利益均衡上オーバーとなり違法だからやらないのではないかな?

Q8. たしかに Exchange Online におけるクラウド上宛のメールはマイクロソフト社からみて平文で処理され保存されることは分かったが、「Microsoft Purview Message Encryption」や「Double Key Encryption」、「S/MIME」、「PGP」等の IRM 技術 / E2EE (End-to-End Encryption) 技術 (クライアント PC 上の Outlook やその他のメーラー等のアプリケーションで暗号化するもの等) でメールを暗号化し、かつ、その暗号鍵をクライアント (オンプレミス) 側に置いておけばアクセスできなくなるのではないかな?

Q9. それでは、マイクロソフト等の安定したパブリッククラウドを用いて、安全にメールサーバーを運用するには、一体どうすれば良いかいな?

Q10. 【脅威 1】(マイクロソフト社自身の利益のためのアクセス: 公取や公取通報者において想定される脅威) は顧客のメールにマイクロソフト社が平文アクセスした結果を目的外で利用する行為に関するものだ。だが、マイクロソフト社は信用できる企業だから、「クラウド事業者としての強大な影響力を背景に、公益を犠牲にし自らの利益を得ようとする公法違反をするような企業 (コンプライアンスを遵守しない企業)」・・・ ② ではないのではないか? だから、マイクロソフト社は、クラウド事業者としての強大な影響力を背景に、受信した公取のメールアドレス宛のメールを見て、これを目的外で利用することはないはずだ。

Q11. インターネットに詳しく、公取のメールサーバーをマイクロソフト社が運営していることに気付き、かつ、Q1 ～ Q7 のような事柄を理解できる人は、一般人には少なく、インターネットのプロの事業者くらいのものであろうから、Q10 の萎縮効果は、通常の通報者には影響はないのでは?

Q12. あえてここまで時間を費やしてマイクロソフト社を非難する必要性は何かな?

Q13. 日本政府における少数の原因関係者たちは、2020 年頃に米国 CLOUD Act について十分検討し、対処策を考えた上で現在の仕組みを企画したのだから、これは、すでに検討されていた事態である。それから状況は変化していないのではないから、新しい研究問題ではないのではないかな?

Q14. ところで、技術と関係ないが、政府のメールサーバーのこの問題の原因関係者を「犯人」と表現することは、仮に不適切行為に過ぎず、犯罪ではないとすれば、日本語の誤用ではないかな?

Q15. 日本政府のこれまでの外国クラウド偏重方針について、公共の場面で異議を唱えると、色々な点で、不利益な扱いをうけるリスクはあるだろうか?

前提となる脅威は、以下の 2 点です:

【脅威 1】 マイクロソフト社自身を公益に反して違法行為をし得る者 (公取の被疑である独禁法違反はそれです) として信用できないと考える立場に立って同社が公取のメールボックスに平文アクセスできるのではないか?

【脅威 2】 マイクロソフト社は信用できるとしても、マイクロソフト社に外国政府 (米国政府、米国裁判所、米国の 50 州の政府機関等) が当該外国の法令に基づき行政調査や司法令状 (顧客への通知を禁止) を発付したときに、マイクロソフト社が顧客 (日本の裁判所) のメールボックスに平文アクセスできるのではないか?

これらについて、以下のように研究をしました。

誤り指摘の情報提供をいただければ幸いです。

■ Q1. Exchange Online の受信メールは、マイクロソフトのクラウド上で暗号化して保存されるとドキュメントに書いてある。マイクロソフトは、平文で公取や裁判所宛の受信メールに接触し、平文でこれを処理している訳ではないのではないかな?

→ A1. 公取・裁判所が、「GSS」と呼ばれる (要するに Microsoft 365 の) うちの Exchange Online を利用している前提で述べると、マイクロソフト社は、平文で日本の公取や裁判所のメールを処理し、平文透過で保管・保持しています。

1. マイクロソフトは常に平文でメール全文に接触 (アクセス) する
(1) マイクロソフトが Exchange Online の受信メールに接触して処理する際は、(クライアント PC で、後に述べる E2EE を施した場合をのぞき) 受信メール (本文・添付ファイル) は常に平文で接触され処理されます。そうしなければ、メールの一覧表示・本文表示・検索・機械学習 (AI) に基づく SPAM 判定・フィッシング詐欺判定等の機能ができず、Exchange Online の機能が提供できないためです。
そして、通常は、平文からは、メッセージ本文や添付ファイル内容が読み取れます (送信者が PGP 暗号化・ZIP 暗号化添付等していない限り)。

(2) 例外として、S/MIME や PGP 等の E2EE (End-to-End Encryption) で予めメールが暗号化された状態で届いた場合は、その E2EE として暗号化されたメールそのものは平文であっても、中身は読めません。ZIP 暗号化付き添付ファイルなどです。また、Windows の Outlook クライアントアプリサイドで Microsoft Purview Message Encryption や DKE を用いて暗号化したメールも同様です。しかし、後述するように、今回の公取や裁判所宛のメール受信ボックスにおける機密性の問題は、外部から届くメールに関するものであり、S/MIME や PGP の鍵等も公開していない (そもそも S/MIME や PGP 等は使っていない) ため、これらの E2EE の仕組みでは保護されません。

(3) よく誤解される点として、SMTP の TLS 経路暗号化がなされている場合が多く、インターネット経由では、メールが届く瞬間までは SMTP の TCP 通信のレベルで暗号化がされています。このことで、メールが暗号化されているに違いないと考えてしまうことがあります。しかし、SMTP サーバーは、必ず、この TLS 暗号化を、SMTP のプロトコルにおいて、透過的に復号化して、平文メールを取り出します。そうしないとそもそもエンベロープ宛先 (RCPT TO:) すら不明であるためです。このように、TLS 経路暗号化の終端点およびその先において、マイクロソフトはメールの平文にアクセスします。

(4) マイクロソフトの社内では、代表受信 SMTP サーバーの背後に複数の SMTP サーバーまたは独自プロトコルのリレーがあり、その間の通信は、一時的に暗号化されることがあります。これは、データセンタ間で光ファイバ等の伝送路を盗聴する者がありえるので、それに対する予防としてそうしています。しかし、これはマイクロソフトからみると透過的な暗号化 (暗号通信の両端はマイクロソフト自身) なので、マイクロソフトに対する機密性の観点からは、その暗号トンネルの中身は、平文と同義です。

2. マイクロソフトは常に平文透過で Exchange Online のメールボックスファイルを扱う
機密性を保護対象とするとき、ある主体にとって、たとえ一見その保存先データは物理ディスク上的は暗号化されていても、その主体にとって鍵が利用可能で、透過的に平文の読み書きができるのであれば、その主体にとって「平文」で保存されているのと完全に同義です。わかりやすい例として、Windows の BitLocker で暗号化したディスクがあるとします。ここに「a.txt」というファイルを置き、中に「Hello」と書きます。たしかに「Hello」という文字は AES-256 等で暗号化され物理ディスクに保管されます。しかし、管理者またはユーザーにとってはそのファイルは透過的に復号化して読み出しできます。このとき、管理者・ユーザーにとっては、セキュリティの観点では、「Hello」は平文と全く同義です。

確かにマイクロソフトのクラウド上のディスクに Exchange Online がデータファイルを物理的に保存する際は、暗号化がなされて保存されます。読み出されるときは、ディスクから読み出して復号化されます。しかし、その暗号化・復号化そのものは、マイクロソフトが行ないます。次にみるように、これはマイクロソフトにとって平文透過です。

具体的には、 2 階層の AES 暗号化／復号化で行なわれます。
以下で暗号化の階層を整理します。復号化はこれと逆順階層です。

(1) まず、マイクロソフトは、AES-256 というアルゴリズムで、32 バイトの乱数鍵 (Exchange Online のテナント内のメールボックスデータベースファイルごとに 1 個の鍵がある。「メールボックス暗号鍵」) を用いて、平文を暗号化します。「メールボックス暗号鍵」は、マイクロソフト自身が支配管理していて、Exchange Online がデータベースファイルを読み書きするために、平文で常に保持しています (HSM の外に出ているという意味です)。

Azure の中がどのようになっているのか知りたいと考える技術愛好者のために少し補足しますと、「メールボックス暗号鍵」は、オフライン時は、マイクロソフト社のデータセンタ内の Azure Key Vault という HSM の中に不揮発的に保管されています。ここで、「HSM」というと、普通は公開鍵暗号の秘密鍵を安全に封じ込めるとか、HSM の中で暗号化・復号化を行なうという耐タンパ性の機能を連想します。しかし、今回の Exchange Online の場合は、想定される脅威に対して、残念ながら HSM を利用している意味がありません。「メールボックス暗号鍵」は AES-256 の鍵ですが、これは、Exchange Online のサービスプロセス (デーモン) が Azure Key Vault に対して鍵の平文そのものを取得する要求をし、Azure Key Vault はこれに応じて鍵の平文そのものを出力します (Azure Key Vault における "unwrap" という動作が許可されていることを意味します)。マイクロソフト社は、鍵の平文を取り出して (この時点でマイクロソフト社は鍵の平文を把握しています)、自身が自作し起動させている Exchange Online のサービスプロセスのメモリ上 (これは普通のプログラムの普通のユーザーメモリ) に保持されます。また、Exchange Online のサービスプロセスは、プロセスが再起動したり、キャッシュ期限が切れたりして鍵をメモリから失った後も、いつでも、Azure Key Vault に鍵を要求でき、鍵は直ちに戻されます。(より厳密に言うと、Azure Key Vault の中には「メールボックス暗号鍵」が暗号化されて入っていて、それとは別に DEP キーというマスターキーも入っています。DEP が「メールボックス暗号鍵」を暗号化しています。DEP には 3 個のコピーがあり、3 個の別々の鍵で並列に暗号化されています。カスタマーキー 1、カスタマーキー 2、Available Key という合鍵の 3 個です。Available Key はマイクロソフトが保持しています。ユーザーがメールボックスデータをエクスポートしたい場合は、カスタマーキー 1、カスタマーキー 2 のいずれか 1 つが利用されます。Available Key という合鍵は、マイクロソフトが利用します。いずれの鍵を用いても、Azure Key Vault から、「メールボックス暗号鍵」を得ることができます。)

(2) 次に、マイクロソフトは、AES-256 以上のアルゴリズムで、別の乱数鍵を用いて BitLocker で上記ファイルを保存するファイルシステムのパーティションを暗号化します。(1) のファイルは、この BitLocker の層で二重に暗号化されます。ただ、Exchange Online では 1 個の物理マシン / VM 上に多数のテナントが共存しています。この BitLocker の暗号化は、物理的にデータセンタからマシンが盗まれた場合の盗難対策以上のセキュリティ上の意味はありません。当然マイクロソフトは鍵を把握しているからです。

この (1), (2) の暗号化の二重の鍵は、マイクロソフトが把握し、マイクロソフトの視点で透過的な暗号化・復号化のために利用できますし、同社は、常にそうしています。したがって、Exchange Online のテナント内メールボックスのデータファイルは、マイクロソフトの視点でみて平文透過です。

3. 結論として、マイクロソフトは、メールアドレスに届くメールに平文で接触し、処理し、平文透過で保管しています。

■ Q2. Exchange Online のメールデータに平文で接触処理・平文透過でディスクに保管しているのは、SMTP サーバー (MTA) や Exchange Online のサービスプログラム等 (以下「プログラム A」) であって、マイクロソフト社ではないのではないかな?

→ A2. いいえ。主体は、マイクロソフト社です。

プログラム A は、単にマイクロソフトが自作し自ら使っている道具であって、行為主体はマイクロソフト社です。

プログラムは、人ではなく、人がその意図通りに自分の機械を機械的に動作させる指令書であり、現在は、プログラム自らが行為主体にはなり得ません。マイクロソフトが自らの意思と支配管理で実行するマイクロソフトの自作プログラム A は、法人としてのマイクロソフト社の一部です。マイクロソフトの自作プログラム A の行為は、法人としてのマイクロソフト社の行為です。

こういった形式論をさておき、実質的にみても、今回の問題 (脅威) は、
【脅威 1】 マイクロソフト社自身を公益に反して違法行為をし得る者 (公取の被疑である独禁法違反はそれです) として信用できないと考える立場に立って同社が公取のメールボックスに平文アクセスできるのではないか?
あるいは、
【脅威 2】 マイクロソフト社は信用できるとしても、マイクロソフト社に外国政府 (米国政府、米国裁判所、米国の 50 州の政府機関等) が当該外国の法令に基づき行政調査や司法令状 (顧客への通知を禁止) を発付したときに、マイクロソフト社が顧客 (日本の裁判所) のメールボックスに平文アクセスできるのではないか?
という 2 パターンの機密性の問題です。

法人としてのマイクロソフト社は、自らの意思に基づき、また、政府からの開示要求に応じる目的で、A のコードを設計し、自作し、これをひんぱんにアップデートしています。そして、Q1 で述べたとおり、A は常にメールデータに平文で接触・処理し、平文透過で保管します。機密性について考えると、マイクロソフト社は A をしていつでも平文データにアクセスできます。

■ Q3. Exchange Online / Microsoft 365 Enterprise では、マイクロソフト社員が顧客のデータにアクセスする際には「カスタマーロックボックス」(マイクロソフトが顧客のデータを見る際の事前承認確認機能) Web 画面による事前承認が必要な仕組みになっているから、無断でメールが見られることはないのではないかな?

→ A3. マイクロソフト社は、「カスタマーロックボックス」(マイクロソフトが Azure や M365 等の顧客のデータを見る際の事前承認確認機能) を、任意にバイパス可能です。顧客に気付かれずに、承認も得ず、メールの読み出しが可能です。

(1) 【脅威 1】(マイクロソフト社自身の利益のためのアクセス: 公取や公取通報者において想定される脅威) について

→ マイクロソフト社は、事前承認確認機能を容易にバイパス可能です。

マイクロソフト自身が、内部的なトラブルシューティングのために特権アクセスをする際には、「カスタマーロックボックス」はパイパスすると明記しています。"マイクロソフトの技術者は、トラブルシューティングの一環として Azure の基盤領域にアクセスし、うっかりと顧客データを (顧客の承諾なしに) 見てしまうことはあります。", ただし、"その際、重要な意義を有する程度の分量の顧客データに接触することは稀にしかありません。" と認めています [1]。
　[1] https://t.co/WYTlvcoRnU

この [1] は、「うっかりと顧客データを (顧客の承諾なしに) 見てしまう」ことの注意です。「うっかり」の際もバイパスがあり得るのであれば、公取に、自社の独禁法違反被疑事件に関して届く通報メールの内容や送り主を見る意図を持ってアクセスする際にも「カスタマーロックボックス」は当然パイパスすることとなります。

(2) 【脅威 2】 (外国政府により要求された日本国民の情報に対するアクセス: 裁判所や日本国民において想定される脅威) について

→ マイクロソフト社は、事前承認確認機能をバイパスすると明言しています。

上記 [1] で、"外部機関からの法的な要求 (による顧客データへのアクセス) の際、カスタマーロックボックスは、トリガーされません。" と明記しています。

→ したがって、今回の脅威に関しては、「カスタマーロックボックス」(マイクロソフトが顧客のデータを見る際の事前承認確認機能) は無意味です。

■ Q4. マイクロソフト社が Exchange Online 上のメールに米国政府によるデータ抽出要求 (米国 CLOUD Act) によりアクセスするとしても、顧客には事前に通知されるから、顧客である日本の裁判所やデジタル庁は、それに対して異議申立てができるのではないかな?

→ A4. そもそも、異議申立てをする (事前に知らされる) 機会がありません。

通常、米国 CLOUD Act では、マイクロソフト社に事前通知禁止命令が発付されるので、マイクロソフト社はその命令に従うしかありません。マイクロソフト社の代表者は、これを無視すると、提出命令の目的が刑事捜査である場合は司法妨害罪 (第 18 編第 73 章第 1512 条 (c) ) に問われ、最大 20 年の拘禁刑に処せられるおそれがあり、また、裁判所の令状または命令に違反すると、裁判所侮辱罪 (第 18 編第 21 章第 401 条) に問われ、最大 6 ヶ月の拘禁刑に処せられるおそれがあるとされていると思います。

そのために、マイクロソフト社は、[2] において、法執行機関による強制命令の場合、マイクロソフトは顧客に通知をした上で要求されたデータをコピーするものの、"法によって通知が禁じられる場合は、通知をしません。" と宣言しています。

　[2] https://t.co/coIMlhPyE3

したがって、日本の裁判所やデジタル庁は、マイクロソフト社に対しても、米国政府に対しても、異議申立てをする機会が与えられません (原理的に不可能です)。なお、2022 年ごろの説で、「米国外国主権免除法」を援用すれば米国政府の開示要求に対抗できるというものがありましたが、2023 年 4 月の米国最高裁決定の判例で、「米国外国主権免除法」は米国 CLOUD Act のような刑事手続きには利用できないことが確定してしまったので、もはやこの理論は使えません。

　[3] https://t.co/55Sy6ajF2q

■ Q5. デジタル庁とマイクロソフト社との Microsoft 365 Enterprise の契約は、日本法に準拠し、かつ日本の裁判所を専属的合意管轄裁判所としているので、米国政府にによる米国法に基づくデータ取得要求 (米国 CLOUD Act) によりアクセスされる心配はないのではないかな?

→ A5. 準拠法や管轄裁判所の指定は、デジタル庁とマイクロソフト社との間の関係に関するものであり、マイクロソフト社と米国政府との間の関係とは無関係です。

→ 米国のマイクロソフト社の代表者は、米国政府 (中央政府、米国裁判所、米国の 50 州の政府機関等) による米国 CLOUD Act に基づく行政調査または司法令状を断わることができません。また、通知禁止命令も無視することができません。無視すると、提出命令の目的が刑事捜査である場合は司法妨害罪 (第 18 編第 73 章第 1512 条 (c) ) に問われ、最大 20 年の拘禁刑に処せられるおそれがあり、また、裁判所の令状または命令に違反すると、裁判所侮辱罪 (第 18 編第 21 章第 401 条) に問われ、最大 6 ヶ月の拘禁刑に処せられるおそれがあるとされていると思います。

■ Q6. デジタル庁とマイクロソフト社との Microsoft 365 Enterprise の契約で、「米国政府からの開示要請 (非通知命令付き) があっても、これを無視するか、事前に日本政府と協議すること」という契約条項 ・・・ ① があるだろうから、マイクロソフト社は契約上、米国からの開示請求に応じることはできないのではないかな?

→ A6. 米 Microsoft Corporation の代表者は、米国に居住しており、米国の公法である米国 CLOUD Act 等に従わないと間接強制 (刑罰等) で強制的に従わさせられます。日本でデジタル庁とどのような契約を締結していても、予防には無意味です。

→ 仮に ① の契約条項があっても、それは「米国法に違反せよ」という無理を強いる契約条項であり、無効 (日本民法第 90 条: 公序良俗違反) となると思います。

■ Q7. 仮に米国政府がマイクロソフト社に日本の裁判所のメールボックス内のメールデータの抽出を命じるとしても、膨大な数のメールの中から、特定のキーワード条件 (例: 特定の個人名文字列を含む) 等に一致するメールのみを抽出するという命令はできないのでは? そうすると全件取得せよというしかできないが、これは明らかに利益均衡上オーバーとなり違法だからやらないのではないかな?

→ A7. 米国では、Google Maps の多数の膨大な位置記録データの中から、「この日に、この緯度・経度付近にいた人の全部のデータを検索して提出せよ」といういわゆる「ジオフェンス令状」でクラウド事業者がデータを抽出させられる事例があります [4][5][6]。この前例から、大量のメールデータの中から、特定の個人名文字列を含むメールを検索し提出せよという要求が出ることは自然で、米国で違法とはされないように思います。
これについて、米国人や米国内居住者を対象とした場合、これらが違憲であるという説があり、一部で違憲判決も出ているようです。ところが、それは米国人や米国内居住者の基本的人権を保護するためのもので、外国人かつ外国居住者である、日本国民に関する、裁判所のあるメールデータを取得しても米国において違憲となることは難しいと思います。

　[4] https://t.co/xD4OzvExcK
　[5] https://t.co/m5bgizkMRI
　[6] https://t.co/mbBrP6ZLzW

■ Q8. たしかに Exchange Online におけるクラウド上宛のメールはマイクロソフト社からみて平文で処理され保存されることは分かったが、「Microsoft Purview Message Encryption」や「Double Key Encryption」、「S/MIME」、「PGP」等の IRM 技術 / E2EE (End-to-End Encryption) 技術 (クライアント PC 上の Outlook やその他のメーラー等のアプリケーションで暗号化するもの等) でメールを暗号化し、かつ、その暗号鍵をクライアント (オンプレミス) 側に置いておけばアクセスできなくなるのではないかな?

→ A8. インターネット (組織外部) から、SMTP で、いったん Exchange Online のあるユーザーのあるメールボックスに届いた段階で、平文のメールについて、個別に、あるいは一括処理で、E2EE / IRM 技術で暗号化することは可能です。その暗号化されたメールを再度 Exchange Online のボックスに書き込めば、マイクロソフト社はこれを復号できないケースがあります。

→ ところが、現在問題になっているのは、SMTP で届いた、組織外部からのメールについての話です。その状態では平文データで保存されるので、その後で個別または一括で暗号化しても、それまでは平文で置かれていたことになり、マイクロソフト社は平文でアクセスしています。

→ SMTP を用いて、外部からたとえ TLS 経路暗号化で暗号化していても TLS の中は平文メールが届く限り (Q1)、いかなる E2EE / IRM 技術を用いてメールクライアント PC 側のみが解読できるようにしても、マイクロソフトによる平文アクセスは原理的に防止できません (その SMTP サーバーはマイクロソフト社が運営しているため)。

→ なお、本質的には脅威はなくなりませんが、若干安心を得る妙案として、SMTP で受信したメールを Exchange Online のメールボックスに注入するときに自動的に「Microsoft Purview Message Encryption」で暗号化するフロールールを書けば解決するのではないか！と思い付きましたが、マイクロソフトのドキュメント [7] によると、"Exchange Online の組織外部の送信者から届くメールは暗号化されません。仮に組織外部からのメールを暗号化するようにメールフロールールを設定しても、受信メールは、暗号化されることなく配送されます。" と書いてあり、残念ながら、この手法も用いることができないようです。

　[7] https://t.co/Z7UUXztb2r

■ Q9. それでは、マイクロソフト等の安定したパブリッククラウドを用いて、安全にメールサーバーを運用するには、一体どうすれば良いかいな?

→ A9. 原理的には TEE (Trusted Execution Environment) 技術に対応したクラウドを用いて、機密コンピューティングに対応したシステムを用いればよいのですが、TEE は発展途上であり、ソフトウェアやアーキテクチャの問題で、TEE 内部で処理できることが限定的で、現時点でなかなか難しいのではないかと思います。すくなくとも、マイクロソフト社の現在の Exchange Online にも、メールボックスに際して、上記で問題となっているような暗号鍵・平文の扱いを TEE 内部で処理する機能はないと思います。

→ かなり現実的な折衷案としては、Microsoft Azure の VM 上に Linux を立てて、ここに、信頼できる OSS ソフトウェアあるいはさまざまな企業が OSS ベースで提供しているメールサーバー製品のうち 1 つを入れて運用するという方法があります。この VM がシールドされた仮想マシンとして動作して UEFI セキュアブートして仮想 TPM で動作している状態にします。これは原理的にはセキュリティ上本質的に意味はないのですが (マイクロソフト社は Azure の VM の特権領域のコードを支配管理していて UEFI セキュアブートは見かけ上のものです。仮想 TPM もソフトウェアベースのもので、その裏奥が実際に HSM を利用しているとしてもこれを確認することができません)、【脅威 1】または【脅威 2】のモデルに対して、データ抽出コストを極めて高くすることができます。マイクロソフトがデータを抽出するには、一種のフォレンジックのような追加タスクが必要となるためです。

→ これに加えて、本質的にセキュリティが向上するさらなるアイデアとしては、マルチクラウドを活用し、ストレージは米国系パブリック・クラウド A に、プログラムは米国系パブリック・クラウド B に分けて稼働させる、という方法があります。より具体的には、AWS の VM #1 上で iSCSI (または CIFS 上の vhdx) の仮想ディスクを作り、Azure の VM #2 でその iSCSI をマウントして BitLocker で保護するという方法があります。これはなかなか強力で、AWS と Azure の両方を同時に侵害したり、あるいは、稼働中の VM #2 への侵入 (またはそのメモリスナップショットを盗んだものの利用) に成功したのちに VM #1 の iSCSI または vhdx が動いている間に VM #1 からデータを奪取する必要があります。この方法は【脅威 1】または【脅威 2】の両方モデルを多くの点で予防できます (マイクロソフト社が Azure VM 上でライブで動作しているプロセスにアタッチしたり、メモリフォレンジックを仕掛けたりしない限りは、安全です)。ただ、この方法ではマルチクラウド間の通信遅延と帯域幅が問題になります。また、可用性が低下するリスクがあります。さらに、iSCSI または CIFS の経路の暗号化が手間です。しかし、東京リージョンで試したところ、AWS と Azure 間で 1 ～ 3 ms 程度で、帯域幅も十分なので、少量のディスクキャッシュ等を活用すれば (キャッシュ中のデータの機密性は侵害される可能性があるが) かなり安定して動作するのではないかと思います。

→ そもそも、日本企業 (米国に重要な事業所・従業員がない) の Saas クラウド型のメールサーバーを利用すれば、【脅威 1】、【脅威 2】のいずれも発生しません (【脅威 1】は、その企業が、公取の独禁法被疑事件で調査対象とでもならない限り)。あるいは、メールサーバー (下位レイヤが Ceph 等の安定定評のある分散ストレージになっていると組織内で数十万人単位まで拡大可能) と認証ディレクトリサービスを、OSS を活用して自前で構築運用するインターネットに関する基本的・基礎的知識を、日本の優秀な公務員が身に付けるのはとても簡単なことであり、それを用いて日本のパブリック・クラウドの IaaS 上で冗長性のあるメールサーバーを構築すれば足ります。明らかに公取や裁判所の専門知識よりも簡単な作業です。

Q10 ～ Q15 は後続投稿されます。

[Yu F @fj_twt]

千葉NT中央駅前に計画中のColtのデータセンター(inzai5)
まもなく着工というタイミングになって、やっと反対運動が始まった模様…