![dnobori's tweet photo. 公正取引委員会のマイクロソフト社に関する通報窓口メールアドレス、裁判所メール等が、マイクロソフト社のメールサーバになっている件に関するサイバーセキュリティ視点 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 は後続投稿されます。](https://pbs.twimg.com/media/HCvYq3PaUAMugrV.jpg)
![dnobori's tweet photo. 公正取引委員会のマイクロソフト社に関する通報窓口メールアドレス、裁判所メール等が、マイクロソフト社のメールサーバになっている件に関するサイバーセキュリティ視点 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 は後続投稿されます。](https://pbs.twimg.com/media/HCvYqTzb0AAQ2jp.jpg)
![dnobori's tweet photo. 公正取引委員会のマイクロソフト社に関する通報窓口メールアドレス、裁判所メール等が、マイクロソフト社のメールサーバになっている件に関するサイバーセキュリティ視点 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 は後続投稿されます。](https://pbs.twimg.com/media/HCvYo60aUAU-DGN.jpg)
Olivia
Online
T.H is ぺんぐぃん
@thisprogrammer
C/C++/C#/PHP Server side Engineer😀 自宅サーバー部 部長
Tokyo
Joined May 2017
339 Following
134 Followers
4.1K Posts
「人の意志に、期待しない」
代わりに、"やれば自然とそうなる"仕組みをつくる。
たとえば、営業の「ニーズカード」
・客先で聞いた困りごとを、必ず記録する
・出さなければ、評価に響く
・良い情報を持ち帰れば、報奨金が出る
根性で情報を集めさせるんじゃない。
「集めた方が得」な仕組みに変える。
目標の決め方も、同じ。
・上から、押し付けない
・自分で「やる目標」を、選ばせる
人は、与えられた目標には本気になれない。
でも、自分で決めたことには、本気になれる。
その"弱さ"を、逆に利用している。
これが、キーエンスの強さの正体。
「人は怠ける」を責めるんじゃなく、
「怠けても回る」仕組みにする。
性善説は、人を信じすぎる。
性悪説は、人を縛りすぎる。
性弱説は、人を、ちゃんと分かっている。
「人は弱い」から始めるほうが、
実は、一番やさしくて、一番強い。
東京大学などの研究者らが、シナリオを漫画に変換するフレームワーク「MangaFlow」を開発。
ステップは次の通り。
①入力したシナリオを、ページ・コマ・「ストーリーセクション（ひと続きの場面のまとまり）」に分解
②セクションごとに登場人物・背景・ 重要な小物の設定と参照画像をひも付けて記憶し、同じセクション内のコマで使い回す
③ページのコマ割りを明示的に作る。自動生成のほか、既存漫画から抽出した配置の再利用や、ユーザーが指定した配置も使えます。作った配置はコマ数・重なり・はみ出し・余白を機械的にチェックして補正
④各コマに対応する参照（人物・背景・小物）をまとめて渡し、画像生成モデルでコマ単位に描く
⑤描いたコマをレイアウト通りに配置してページを組み立てる
⑥セリフやナレーションの吹き出しを、キャラの顔を隠さない位置に配置する
Gemini（nano-banana）やChatGPTの画像生成などで漫画を作る場合との違いは、ページを丸ごと一発で描かせるか、工程を分けるか、という点にあります。
一発生成だとコマ割り・キャラ・セリフが1枚の絵の中で混ざるため、指定したコマ数や配置を守れない、コマの境界がつぶれる、ページをまたぐとキャラの見た目が変わる、セリフが読めなかったり抜けたりする、といったことが起きやすくなります。
世界最強のAI音声「Miso One」が完全無料で公開
・10秒の自分の声だけで完璧クローン
・喜怒哀楽・ニュアンスまで人間らしい感情表現
・遅延わずか0.11秒
・YouTube・教育動画・ポッドキャストが一瞬でプロ級に
初心者でも無料で試せる。
リプ欄でマネタイズ含めて解説↓
いや、マジでClaude × Higgsfield MCPやばすぎるんだけど、、😳
Claudeに動画リファレンスを貼るだけで、構成分析から素材生成まで行けるの神すぎる。
https://t.co/wE55rBbPxm
最初に動画見た瞬間、「マジで本格的に映像制作の司令塔までClaudeに来ちゃったんだけど」ってなった、、
操作感がマジで異次元すぎる👇
・動画のstructure / shots / pacingを分析
・同じチャット内で素材生成まで進める
・Higgsfield Supercomputer SkillがClaudeの中で動く
つまり「動画生成AIに別画面で投げる」じゃないんだよね。Claudeの会話そのものが制作スタジオ化してる。
これまでのAIは「プロンプトを書く」で止まってた。
Claude + Higgsfieldはそこが違うんだよね。"映像の構造を読んで、次の素材まで作る"レベルまで来てるの普通に神。
しかもさらにすごいのが、特殊な編集ソフト前提じゃなくてMCP接続だけでこの流れに入れること。
映像制作が変わった？って話じゃないんだよね。
「リファレンスを見せて、同じ文脈で作る」という体験の前提が変わり始めてる。
やっぱり、これからはMCP + Skillsなんだよね。
Claudeに外部ツールを持たせる感覚は、MCP30選の記事でかなり掴みやすい。
この下の記事を読むと理解が一気に深まる。マジでおすすめ👇😻
Claude CodeやCursorの「使いすぎてすぐ上限」がツラい人へ👀
9router、★約1.4万。
何ができるかというと👇
・Claude Code/Cursor/Codex/Copilot等を40以上の提供元につなぐ
・無料・格安モデルへ自動で切り替え(フォールバック)
・独自の仕組みでトークンを20〜40%節約
・「上限に当たって止まる」を回避
ツールはそのまま、裏側のモデルを賢く使い回すイメージ。
日本語READMEもあります。
https://t.co/DX9fxmd219
4GB显存跑70B大模型？这事儿真成了！
AirLLM玩了个骚操作——分层推理，不一次性把模型怼进显存，而是一层层加载、算完就扔，硬生生把巨无霸塞进小破卡。
最骚的是：100%开源，白嫖警告⚠️
🔗 https://t.co/gpiHYFwt69
C++で満足しちゃってない？
はてなブログに投稿しました
AI時代、人間は非完全情報ゲームを担う - Nothing ventured, nothing gained. https://t.co/sXNW5GA4oB
使うほど賢くなる人気AIエージェントのアプリ版「Hermes Desktop」登場 https://t.co/XG496Z7OxQ
【衝撃】
AIコーディングの土台そのものを最適化するシステムが、★約19万まで伸びてます🔥
affaan-m/ECC。
何が入ってるかというと👇
・skills・直感(instincts)・記憶・セキュリティを統合
・「まず調べてから作る」開発スタイルを仕込む
・Claude Code/Codex/Opencode/Cursor等に対応
・日本語含む多言語対応
単発のskillsじゃなく「AIの動き方の総合チューニング」。
人気が桁違いです。
https://t.co/6VLFS9ma5H
【速報】
Codex使ってる人、これ一回そのまま投げた方がいいプロンプト出てた、、😳
これ日本語でどうゆうプロンプトかと言うと👇
「最近30日のCodexセッション、Memory、Chronicleを見て。
繰り返している手作業を探して。
既存のSkillsやagentsを再利用しながら、
必要最小限のSkill / subagent / automationだけ作って」
というプロンプト。
これ、地味に見えてAI運用の本質すぎるんだよね。
多くの人はCodexに
「これ直して」
「これ調べて」
「これいい感じにして」
で終わる。
でも本当に強い使い方はここなんだよね。
AIに作業させるだけじゃなく、
AIとの作業履歴から
「自分が何度もやってる仕事」を見つけて型にする。
つまり、コードだけじゃなく
「自分専用の仕事の手順」まで残す。
これをやると何が起きるかというと、
・繰り返し作業をSkillにできる
・調査役が必要なものをsubagentにできる
・時間で回すものをautomationにできる
・既存Skillsの重複作成を避けられる
・作業ログがそのまま改善材料になる
要するに、AIにその場で頼む時代から、
AIとの履歴を資産化する時代に入ってる。
Codex / Claude Codeを毎日使ってる人は、
この一文を入れるだけでマジで運用品質変わるんだよね。
「作業して」だけじゃなく、
「何度もやってる作業をSkill化して」までがAIコーディングなんだよね。
CodexとClaude Codeの役割分担まで見ると、この使い方の意味がかなりつながる。
この下の記事を読むと理解が一気に深まる。マジでおすすめ👇😻
ガチでヤバイ。
OpenAIが約18万円分のAI開発環境を、オープンソース開発者に無料で配っています。
GitHubに公開リポジトリが1つでもあれば申請OK。「Codex for OSS」というプログラムです。
申請して通れば、こんな特典が全部タダ。
・ChatGPT Pro 6ヶ月（月$200×6ヶ月＝計$1,200、約18万円相当）
・Codexアクセス（AIがコードを書いてくれるツール）
・API使用クレジット（PR自動レビューや自動化に使える）
・Codex Security（コードの脆弱性チェック機能）
全部0円。申請する手順を詳しく解説します👇
オープンソース界、ガチで革命起きた。Hermes Desktopが頭おかしい。
ChatGPT・GPT-5.5・Codex・Claude Code Skills全部繋がる、Mac/Windows/Linux対応のネイティブAIエージェントが、本日6/2パブリックプレビュー開始。
Jensen Huang CEOがGTC基調講演でデモした実物。MIT、無料、全部OSS。
これ知らない人は2026年負け確定の話を全部解説する↓
Micorosoftが先ほど発表した独自モデルのMAIは、蒸留なし、合成データなしという、徹底したアプローチで作られており、それでいてClaudeやGPTに迫るレベルになっているので、この論文は実質的に今一番オープンな最先端AIの作り方かも。
https://t.co/u8MdhbNVzh
フロンティアモデルはともかく、オープンモデルですら蒸留、合成データ含め何をやっているかわからない時代なので、この辺の知見はとても貴重。
ゲームのAI(機械学習とかではない)を学びたい人の教材というのにGame AI Proの無料公開資料は大変ありがたい中で、各章AIを手助けに日本語化したり、NotebookLMで理解手助けしたり、Webで動く可視化したデモみたいなもの実装させたりで学びを進められるんだけどこう言った発想の差が出る時代にはなった
https://t.co/sOsLX5aVuU
Haskell の遅延評価の仕組み、特にコード中で2回使われる変数が1回しか評価されない理由について低レイヤーでの挙動を元に解説した記事✍️
STGでは \u という updatable（更新可能）なサンクで表現され一度評価されたら上書きされ2度目の再計算がされない（そして C-- へ…）
https://t.co/E1AxGKXvdH
Windowsエクスプローラー上でEdge3形式をサムネイル表示する拡張機能もご用意しております！
https://t.co/OIMsy8NWZy
公正取引委員会のマイクロソフト社に関する通報窓口メールアドレス、裁判所メール等が、マイクロソフト社のメールサーバになっている件に関するサイバーセキュリティ視点 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 は後続投稿されます。
![dnobori's tweet photo. 公正取引委員会のマイクロソフト社に関する通報窓口メールアドレス、裁判所メール等が、マイクロソフト社のメールサーバになっている件に関するサイバーセキュリティ視点 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 は後続投稿されます。](https://pbs.twimg.com/media/HCvY2hObYAAxGpk.jpg)
でも、これ自前で管理更新し続けないといけないんだよね。そのために専属で管理に責任を持つ労働者を割り当てる必要がある。
さもないと数年後にCIサーバーが古くて不安定だが管理人不在で誰もよくわかっていないという状態になる。
https://t.co/fLIm4rlzco
Last Seen Users on Sotwe
Trends for you
Most Popular Users
Elon Musk 
@elonmusk
240.1M followers
Barack Obama
@barackobama
119.3M followers
Donald J. Trump
@realdonaldtrump
111.6M followers
Cristiano Ronaldo
@cristiano
108.8M followers
Narendra Modi
@narendramodi
106.9M followers
Rihanna
@rihanna
97.2M followers
NASA
@nasa
92.1M followers
Justin Bieber
@justinbieber
90.5M followers
KATY PERRY
@katyperry
86.7M followers
Taylor Swift
@taylorswift13
80.5M followers
Lady Gaga
@ladygaga
72.1M followers
Kim Kardashian
@kimkardashian
69.3M followers
YouTube
@youtube
68.6M followers
Virat Kohli
@imvkohli
68.4M followers
Bill Gates
@billgates
63.4M followers
The Ellen Show
@theellenshow
62.5M followers
CNN
@cnn
61.9M followers
Neymar Jr
@neymarjr
60.9M followers
X
@x
60.9M followers
CNN Breaking News
@cnnbrk
59.9M followers