raki

公正取引委員会のマイクロソフト社に関する通報窓口メールアドレス、裁判所メール等が、マイクロソフト社のメールサーバになっている件に関するサイバーセキュリティ視点 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] learn.microsoft.com/en-us/azure/se… この [1] は、「うっかりと顧客データを (顧客の承諾なしに) 見てしまう」ことの注意です。「うっかり」の際もバイパスがあり得るのであれば、公取に、自社の独禁法違反被疑事件に関して届く通報メールの内容や送り主を見る意図を持ってアクセスする際にも「カスタマーロックボックス」は当然パイパスすることとなります。 (2) 【脅威 2】 (外国政府により要求された日本国民の情報に対するアクセス: 裁判所や日本国民において想定される脅威) について → マイクロソフト社は、事前承認確認機能をバイパスすると明言しています。 上記 [1] で、"外部機関からの法的な要求 (による顧客データへのアクセス) の際、カスタマーロックボックスは、トリガーされません。" と明記しています。 → したがって、今回の脅威に関しては、「カスタマーロックボックス」(マイクロソフトが顧客のデータを見る際の事前承認確認機能) は無意味です。 ■ Q4. マイクロソフト社が Exchange Online 上のメールに米国政府によるデータ抽出要求 (米国 CLOUD Act) によりアクセスするとしても、顧客には事前に通知されるから、顧客である日本の裁判所やデジタル庁は、それに対して異議申立てができるのではないかな? → A4. そもそも、異議申立てをする (事前に知らされる) 機会がありません。 通常、米国 CLOUD Act では、マイクロソフト社に事前通知禁止命令が発付されるので、マイクロソフト社はその命令に従うしかありません。マイクロソフト社の代表者は、これを無視すると、提出命令の目的が刑事捜査である場合は司法妨害罪 (第 18 編第 73 章第 1512 条 (c) ) に問われ、最大 20 年の拘禁刑に処せられるおそれがあり、また、裁判所の令状または命令に違反すると、裁判所侮辱罪 (第 18 編第 21 章第 401 条) に問われ、最大 6 ヶ月の拘禁刑に処せられるおそれがあるとされていると思います。 そのために、マイクロソフト社は、[2] において、法執行機関による強制命令の場合、マイクロソフトは顧客に通知をした上で要求されたデータをコピーするものの、"法によって通知が禁じられる場合は、通知をしません。" と宣言しています。 　[2] learn.microsoft.com/en-us/microsof… したがって、日本の裁判所やデジタル庁は、マイクロソフト社に対しても、米国政府に対しても、異議申立てをする機会が与えられません (原理的に不可能です)。なお、2022 年ごろの説で、「米国外国主権免除法」を援用すれば米国政府の開示要求に対抗できるというものがありましたが、2023 年 4 月の米国最高裁決定の判例で、「米国外国主権免除法」は米国 CLOUD Act のような刑事手続きには利用できないことが確定してしまったので、もはやこの理論は使えません。 　[3] supremecourt.gov/opinions/22pdf… ■ 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] seijo.repo.nii.ac.jp/record/2000079… 　[5] forbesjapan.com/articles/detai… 　[6] forbesjapan.com/articles/detai… ■ 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] learn.microsoft.com/en-us/purview/… ■ 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 は後続投稿されます。

愛媛県新居浜市が、総務省ガイドラインの諸モデルの長所を統合した独自の「四層分離モデル」の構築に、フォーティネットの自治体向けSD-WANソリューションを活用　写真1枚　国際ニュース：AFPBB News share.google/jWBckaLDMHg0Dr… お、出ました4層分離 渋谷区とかも似た感じだったかな

Nunchi x Based Today, we're introducing a new financial primitive on @basedOneX, Yield Perpetuals (Yield Perps), exclusively integrated for the Based community through Hyperliquid's HIP-3. This collaboration aims to unlock what we call DeFi's "biggest untapped market" - the ability to actively trade the "velocity" or "time value" of money (yield), rather than just passively earning it.