背景
年末にgoogleのサジェストで以下の記事を読みまして。
https://atmarkit.itmedia.co.jp/ait/articles/2412/11/news007.html
共感とともに、共感しちゃあかんだろという自制心が駆け巡るというなんとも感慨深い経験をしまして。
せっかくなので、脳内を整理してみようと思います。
先に結論
特に裏付けのデータなどは示せませんので、SIERのポエムにしかなりませんね。。
自分としては共感と反感の根っこが明確になったので、良しとしようと思います。
まとめとしてはこんな。
- PPAPは悪。
- クラウドストレージ式は、だいたいの場合PPAPよりは安全になるが、同等レベルかそれ以下まで落ちる大穴がありそう。
- 考えないといけないことはまだまだ多く、「これすればOK」といえるものはなさげ。
脳内の整理方針
以下のような順番で頭の整理していってみようと思います。
イコール、本記事の目次です。
- なんでメールするんだっけ？
- なんでメールに添付ファイルつけるんだっけ？
- 添付ファイルって、なんで圧縮（暗号化）するんだっけか？
- なんでPPAPはだめなんだっけか？
- PPAPがだめなら、何すりゃいいの？
- なんで組織ごとに使うクラウドサービスが変わるん？
本文
1. なんでメールするんだっけ？
「自分が、相手に対して、なんらかの情報を伝えたい」からですね。
伝えたい情報を伝える手段としてメール（e-mail）を使います。
当たり前だろって？
まぁそうなんですけど、後々のことを考えるともうちょっと踏み込んで考える意義があります。
暗黙になっている要件を言葉にするとしたら、こんな感じでしょうか。
- 「自分が伝えたい」情報であることを示したい⇒「自分を語る第三者が伝える情報」ではないことを示したい
- 送信者の性確認を要する
- 伝えたい相手にだけ伝えたい⇒想定外の相手には伝えたくない
- 送信先確認を要する
- 自分が情報を送信したことの証跡を残したい
- 相手が情報を受信したことの証跡を残したい
- 相手から「その情報もらってないよ？どうしてくれんの？」といわれた際に、「送ったじゃないか！」といえるように
- 伝えた情報自体を後日確認したい
- 情報流出インシデントなどのシーンで、「漏れたとしたら何の情報」というような、被害規模の特定の際に使う、など。
逆に情報を受け取る側の視点から考えると、以下を１つ追加でしょうか。
- 不要な情報は受け取りたくない
- 情報の送信者を制限したい
スパムチックな広告を放り投げるときは上記に当てはまらない訳ですけど、ビジネスを想定すると、上記のケースが主になるかなと。
「メールじゃ実現できてねぇだろ」って？
、、はい、全く同感なんですけど、「何をしたかったのか」を明確にすることは重要なので。
後述で改めて拾います。
2. なんでメールに添付ファイルをつけるんだっけ？
「短いString（メール本文）では表現できない情報を相手に伝えたいから」ですね。
短いStringで表現できる情報は、メールの本文に書けばいいわけです。
本文に書くには長すぎる情報だったり、平文だと見た目てきに可読性が悪い情報だったり、バイナリデータだったりは、専用のフォーマットのデータとして送りたい。
と、いうことで、添付データが必要になります。
これも「当たり前だろ」って？
そりゃそうなんですけどね。
ただし、この先の脳内整理を進めるの当たり、メールは「メール本文」と「添付ファイル」という2つの情報を送るもの、という点を意識しておく必要があります。
ちなみに、宛先、CC、Mail Fromや転送サーバの経路などのヘッダとしてついてくる情報もかなり重要な情報ですが、、今回の脳内整理ではメインにはなりませんので、そこは踏み込みません。
3. 添付ファイルって、なんで圧縮（暗号化）するんだっけか？
２段階に分けて考えます。
3.1. 添付ファイルって、なんで圧縮するんだっけか？
これは「でかい／多いファイルを小さく／少なくしたいから」ですね。
最近の画像ファイルや、それを取り込むpptxファイルって最初からかなり圧縮されているので、サイズを小さくする効果はないんですが、、、昔を振り返れば、zipするとサイズの桁がいくつか下がる、ということがありました。
あるいは、個別ファイル数百をメールに添付してたら送る側も受ける側も●んじゃいますから、１つのzipファイルにまとめられるというのは、非常にありがたい。
そりゃそうだって？そうなんですけどね。
暗号化の話との対比として、一旦圧縮に限定して整理しておく必要があったので。
3.2. 添付ファイルって、なんで暗号化するんだっけか？
端的に言うと、「メールは簡単に盗聴される（と思われている）から」だと思ってます。
ただし。そのまえに。
「圧縮」と「暗号化」を意図的にセットで書いているんですが、なんでセットで書いているかというと。
そもそも両者は全然別の概念ですし、圧縮関係なしに暗号化する仕組みとかも全然あるんですが、、、ピュアな暗号化用途のアプリはあまり普及してない気がします。
一方、圧縮アプリは「パスワードを付与する（暗号化も一緒にする）」という仕組みを一緒に持っているものが多く、そもそも圧縮アプリ自体も広く普及しています。
ということで、自然に、「暗号化のためだけの方法を設ける」ではなくて「圧縮のついでに暗号化する」という発想になってしまうんですね。。。
圧縮ソフトが標準で採用しているアルゴリズムが弱い（弱かった）という話もあるのですけれど、実質的にファイルを暗号化したいというときに一番手軽に使える方法が圧縮ソフトのパスワード付与機能を使うことなので、「圧縮」と「暗号化」が一緒に議論されてしまうのは仕方ないのかなと。
ということで、意図的に混ぜて書きました。
脱線しましたが、なんで暗号化するかの話に戻りましょうか。
暗号化のモチベは、メールが盗聴されるとメール本文の内容は筒抜けになりますが、添付ファイルが暗号化されていれば、添付ファイルの情報は盗聴からまぬがれられる、ということですね。
メール本文は筒抜けでいいのか？という話は当然あり、教科書的には「機密情報は本文に書かずに暗号化して添付ファイルにする」という運用とセットで語られてきたかと思います。
ただし、「（と思われている）」というのがポイントで。
本当に簡単に盗聴されるのかというと、表現が難しく。
ふるきゆかしきメールのプロトコルは平文送受ですが、httpにとってのhttpsのように、暗号化して送受する仕組みは昔からあります。
一方、「盗聴させない仕組みは普及しにくかった」「運用ミスで簡単に漏れるケースがどうしても多発する（誤送信）」の２つの背景があり、「簡単に盗聴される」と扱わざるを得ないと思ってます。
ちょっと深堀します。
【脱線1】メールって簡単に盗聴されるの？
表現が難しいのですが、簡単に盗聴されると「認識されている」のは事実だと思ってます。
なんでそうなったのかというと、思うところは２つあります。
脱線1-1. メールを盗聴させない仕組みは普及しにくかった
これはかなりちゃんと調べてから情報発信すべきだとは思うのですが、、要出展ということで。。
メールの暗号化や送受の身元確認の仕組みは古くからあるんですが、、普及にはだいぶ時間がかかっていたように思ってます。
httpからhttpsの移行と対比すると非常に興味深いのですが、http側はかなり素早く移行したような感覚があります。
これは、そもそも「ブラウジングが一時的にできなくなっても、致命的なトラブルにはならない」という前提があるのでアグレッシブな方法をとりやすく、かつ、「ブラウザ各社がかなり積極的にhttps強制を推進した（http接続の際にアラート画面を出す）」という条件がきれいに決まった、というのが重要だったと思います。
一方、メールについてですが、こちらはスムーズにはいかなかったように思ってます。
身の回りを思い返してみても、セキュリティ強化をしようとするたびに「それで届かないメールが出たら、致命的なトラブルになるからやめてくれ」という声が強く。
また、ブラウザに相当するものはというと、gmailやoutlookあたりはその立場にいたような気はするんですけど、httpsのように積極的な切断を進めるということはしてきてなかったかと思います。
とはいえ淡々と強化は進み、胡散臭いメールサーバからのメールを受け付けないように静かにシフトしてきている感はあるのですけれど、総じて、「メールは盗聴される」という認識はいまだ根強く残っている気がします。
脱線1-2. 運用ミスで簡単に盗聴されるケースがどうしても多発する（誤送信）
これは本当にどうしようもなく、これまでもこれからも多発すると思ってます。
タイポした、オートコンプリートが暴走した、そもそも聞いてたメールアドレスが間違っていた、etc,etc,,,,
技術論をぶち抜く運用ミスです。
事例や注意喚起を聞いたことがある／自分でやったことがある方も多数いるのではないかと思います。
pgpのように事前に相手を認証する仕組みがあれば防げるっちゃふせげますが、それは暗号化よりもさらにハードルが高く。
メールを使う以上、どうしようもなく付きまとうリスクだと思います。
4. なんでPPAPはだめなんだっけか？
4.1. 暗号化の意味をなさなくなるから
「メールは盗聴される（ことが多い）」
⇒「重要情報は添付ファイルとして切り出して、暗号化しよう」
⇒「ＰＰＡＰすると、暗号化したファイルのパスワードをメールで送るから、パスワードが盗聴／誤送信される」
⇒「せっかく暗号化した重要情報が簡単に復号されて、結局、第三者に中身見られちゃう」
ということですね。
ここで重要なのは、「添付ファイルの暗号化＝ＰＰＡＰ」ではない、ということ。
ＰＰＡＰは、あくまで「添付ファイルの暗号化」の運用実装の１つです。
ＴＯＢＥを語ると、「添付ファイルのパスワードはメール以外の方法（電話とか）で伝える」とか、「そもそもＰＪ開始時のキックオフミーティングで決めておく」とか。教科書系の文書に登場する運用実装もあります。
ＰＰＡＰについては、上記の通り、暗号化の意味が簡単になくなる（ことが多い）からＮＧと。
一方、ＴＯＢＥ型の実装なら安全なのか？
これも表現が非常に難しいのですが、、、２つの観点から、万全に安全とは言いにくいかなと思ってます。
脱線しましょうか。
結論としては、ある程度のリスクは残るので、総じて、どのような運用実装をとっても「添付ファイルの暗号化は暗号化の意味をなさなくなる」の可能性は否定できない気がします。
【脱線2】 PPAP以外の「添付ファイル暗号化」の運用実装って危険なの？
体感で恐縮ですが、現時点ではアウトとはいいがたいのですが、理想的とも言いにくいように感じてます。
ポイントは以下。
脱線2-1. 添付ファイルの暗号化方式が脆弱
「その暗号化はやっても意味がない」みたいな話はよく聞きますよね。
暗号化って、復号できない物では断じてなく、「復号できるけど、パスワードなどを知らない人がトライすると、天文学的な時間がかかる」というもの。
計算機自体の能力が上がったり、復号を効率的に実施する方法が見つかったりすると、この天文学的な時間が数日や数分まで短縮されてしまうと。
そうなると、その暗号化のアルゴリズムは「危殆化した」とされて、使うなー、意味ないぞー、といわれるわけですね。
「zipの暗号化は意味がない」というような話も聞いたことが結構ある気がします。
いい記事は、、ざっくりしか見てないですが、ここらへんでしょうか。。
https://www.hitachi-systems-es.co.jp/service/column/mail/article02.html
そもそも、暗号のアルゴリズムが選択できて、強力なものも選べる、標準で強力なものを選ぶように順次変えていく、という動きをしていきます。
しかしながら、ソフトをアップデートせずに使っていれば古いアルゴリズムが使われ続けるわけですから、、
そういう意味では暗号化方式が脆弱（な場合がある）といいうのは現実的なサイズのリスクになる気がします。
ということで、ＰＰＡＰよりは全然安全だと思ってますが、「理想的！」というにはちょっとなぁ、、という感じ。
脱線2-2. パスワード方式自体が脆弱
皆が簡単に思いつくものを使っている、複数のサイトで使いまわしている、などですね。
"password"をもじったものは多数よく知られていて、ブルートフォースのツールの標準リストにがっつり網羅されており。
後者については、年中様々なサービスが不正侵入されて、うっかり平文で保存してたパスワードが漏れて、、としているわけですので、ほっとくと遠からず別サービスから漏れてしまう、と。
（今のところ）リモートワークが主流となっているわけですし、「付箋でPCにはっとく」のリスクはだいぶ下がっている気はしますけれど、そもそも「パスワード」という方式自体が、どうやっても現実的なサイズのリスクになるかと思います。
4.2. そもそも、暗号化をしてくれるな！
これは本質的にPPAPとは関係ない話のはずなんですけど、PPAPの議論をする際によく混ざってきます。
サンドボックス型のセキュリティアプライアンスのように、「メールの添付ファイルがマルウェアじゃないか確認する仕組みが機能しなくなるから」という話ですね。
言っていることはわからないでもないんですが、、、
「じゃあ盗聴されたくないデータどうやって送付するんだよ」「添付ファイル暗号化していてもPC上で復号するわけで、EDRで捕まえられるのでは、、？」などなど思ところがあり。
そもそもPPAPの話でないこともありますし。
後述の議論をし尽くしたとしてもメールは消えないでしょうし、重要な話だとは思いますが、PPAPの議論とは別に考えた方がいいかなと思ってます。
5. PPAPがだめなら、何すりゃいいの？
【脱線3】 メール本文はどーすんだ？
PPAPにフォーカスすると、メール本文の話を忘れそうになりますが、、
「メールは盗聴される（気がする）」⇒「重要情報は暗号化して添付ファイルに」というロジックが理想ですが、、そうきれいにいくわけもなく。
「数行だからいいかー」と関係者の住所（個人情報）を本文に書いてしまったり、そもそも送信先のアドレス自体が結構重要な情報だったり、というケースは結構思いつくわけで。
メール本文についても、ノーガードでいいというわけでもないです。
メールアルゴリズム自体の強化が進んだとしても、運用ミス（誤送信）リスクは残ります。
そうなると、「もうメール自体やめてしまおう、、、」みたいな発想も脳内をよぎります。
詳細は後述しますが、うっかりメール本文を置き去りにしないように、という点は常に意識しないといけないと思ってます。
5.1. そもそも、情報伝達に求められる要件ってなんだったけっか？
PPAPがあかん！というのは共通認識だと思うのですが、これは言い方を変えると、「メール＋添付ファイルに対して期待していた、「情報が盗聴されない」という要件が達成できなくなくなった」という事象なのかなと思います。
じゃぁ、その要件が達成できる方法を考えよう、、、となるのですが、ちょっと一息。
メールには、「情報が盗聴されない」以外の要件も多数あったはずなわけです。
新しい方法を考えたとして、それが「盗聴されない」以外の要件を満たせないとしたら、本末転倒。
ということで、そもそも情報伝達に求められる要件って何だったんだっけか、、？というのを整理してみたいと思います。
上記に記載した内容を拾いなおしてみると、こんなでしょうか。
- a. 送信者の特定／制限ができること（送信者のなりすましを防げること）
- b. 受信者の特定／制限ができること （誤送信／相手のなりすましを防げること）
- c. 送信者が、情報を送信したことの証跡を残せること
- d. 受信者が、情報を受信したことの証跡を残せること
- e. 送付した情報自体を後日確認できること
- f. 情報効率的に送受できること(圧縮の一般化）
- g. 送付した情報が盗聴/改ざんされないようにできること(暗号化)
5.2. そもそもメール送受型（Not PPAP）で達成できる要件、できない要件
前述のとおり、PPAPだとgは（一般的には）ＮＧになります。（PGPがっつり運用してりゃ違うんでしょうけど。。多分。）
では、PPAP以外のTOBEの運用実装をできてたとして、他の要件は達成できてたんだっけか、、、？ということで、ちょっと整理してみたいと思います。
- a. 送信者の特定／制限ができること（送信者のなりすましを防げること）
- △
- 会社のセキュリティ訓練で、メールヘッダが改ざんされた事例が出てくることは多数あります。誰が送った情報化は送信元アドレス情報で確認できますが、偽装も現実的に可能ということで、、△かなと。
- 制限については、スパムチェック機能などが明らかに怪しいメールははじいてくれますけれど、完全ではないです。
- b. 受信者の特定／制限ができること （誤送信／相手のなりすましを防げること）
- △
- （非現実的な）ダブル／トリプルチェックしたって、 誤送信リスクがどうやっても消えません。
- メリスの中に異動した人が潜んでた、多数のＣＣの中にいつの間にか部外者が、、とか、あるあるですね。
- c. 送信者が、情報を送信したことの証跡を残せること
- △
- 送信者側にログ残りますけど、受信者からすれば「改ざんしてそのログ作ったでしょ？」といえなくもないので、、、
- d. 受信者が、情報を受信したことの証跡を残せること
- △
- 開封確認の仕組みはありますが、有効に機能しているのはあまり見たことがない気が。
- e. 送付した情報自体を後日確認できること
- △
- 同、c
- f. 情報効率的に送受できること(圧縮の一般化）
- △
- 明確にこれがだめ、、という気はしないんですが、ほかにやりようはあるような、、という気はします。
- g. 送付した情報が盗聴/改ざんされないようにできること(暗号化)
- 〇、、？
- 前述のとおり「理想的」とはいいがたいのですが、、、ちゃんとルール通りリテラシ高くやれてれば〇かな、、
ということで、×ではないけど〇でもないのかな、ということろです。
5.3. クラウドストレージ型に置き換えれば安全なんだっけか？
IPAは何て言ってるのかな、、
https://www.ipa.go.jp/security/seminar/ssf7ph00000081a1-att/20230922_25th_paneller_slides.pdf
ドンピシャなガイドラインとかはまだ出てない、、かな。。？
ポストPPAPというと、実装は多数ありますが、ざっくりいうと「クラウドストレージ」を使う方法が主流なのかなと思います。
「クラウドストレージ」といってますが、MSのTeamsと連動して動くsharepointを使う場合や、チャット型サービスと独立しているBoxのようなサービスを使う方法、これまで通りメールにファイルと添付すると勝手に切り離してしてクラウドストレージにアップして、ダウンロードURLをメールで飛ばす実装などいろいろあります。
また、それぞれのサービスも設定で機能のon/offが様々できるわけで、、
悩ましいのですが、重要なポイントになるであろう、「アカウントの要否」の観点に着目して整理してみようと思います。
結論としては、だいたいの場合でメール型（PPAP/TOBE運用の添付ファイル方式）より安全になるけど、PPAP同等かそれ以下になりうるケースがある、という感じです。
5.3.1. データのアップロード（送信）、ダウンロード（受信）の両方にアカウント登録を必須にする場合
もうちょっと細かく言うと、送信側でも受信側でもいいのですが、責任をもって管理できる人間が申請者を審査してアカウントを作成し、それらのアカウントがアクセスできる領域を設定する場合です。
アカウント自体は、MFA/IDaaSなどでがっつり守る、と。
このケースでは結論としては、以下でしょうか。
- メール送信型よりは安全になる
- ただし、アップするファイルの暗号化は依然したほうがよさそう。
- もし実装がだめだめなクラウドを選んでしまったら、メールよりデグレ
詳細は以下。
要件a,bについては、確実に担保できて、メールより安全になります。
c,d,eはサービスの仕様次第ですが、大手のサービスはどの機能も持っているように思いますから、メールよりGood。
fの送受の効率性については、、、データの送受だけにクラウドストレージを使うなら、別にメールと比べてそこまで便利にはならないように思います。
一方、「プロジェクトで使うデータを一元管理するストレージ」としてがっつりと定めてしまうなら、運用はかなり効率的になるかと思います。
現時点では、全社の「送受手段置き換え」として議論されるケースが多い気がしますので、その前提なら、別に楽にはならんかなと。
ただし、、メールで送受できない大容量ファイルの送受もできるわけですから、、
総じて、メールよりはGoodなのかな。
eの盗聴防止については、ちょっと悩ましい。
a,bと同等の観点で、送信者／受信者の制限は事前にできていることになりますから、誤送信リスクはかなり抑え込めるかと思います。
盗聴リスクについては、通信の暗号化は普通https必須。
。。ではあるのですけれど、SSL Heart Bleedのように脆弱性が出ることは全然あります。
また、クラウドストレージ自体が不正侵入されてデータを全部引っこ抜かれるのもぜんぜんありえます。
そう考えると、メールと比べて劇的に安全になるとはいいがたいかな。。
また、後述しますが、クラウドサービスの運用方法によっては大穴が空くケースがあります。
ということで、クラウドストレージを使う場合においても、アップするファイルはメール自体同様に暗号化しておいた方が無難な気がします。
ちなみにアップするファイルを暗号化するとして、その際のパスワードの送受方法についてですが。。
メール時代のTOBEであった「電話／ＰＪキックオフでパスワードを決める」は、現実的に運用できるなら、当然〇。
ではＰＰＡＰを踏襲した、「ファイルはクラウドサービス、パスワードはメール」の場合はどうか？
メールの場合と違って、「メールとクラウドサービスの両方で盗聴される」が成立しないとデータ流出しないわけですから、、、メールだけが盗聴された破綻するＰＰＡＰよりは安全、、、なのかなぁ。
5.3.2. データのアップロード（送信）は代替え策、ダウンロード（受信）はアカウント登録を必須にする場合
アカウントはだいたい自分のメアドになるわけですが、「自組織の方針で所定以外のクラウドサービスにアカウントを作るのはNG」「シングルサインオンの仕様で自組織のテナントと干渉し、想定外の権限を持っちゃうので組織のアカウントを使ってくれるな」などなど、うまくもいかないケースが出てくるように思います。
該当クラウドサービスを指定した側の組織は当然アカウント持ってますが、それに合わせた相手組織はアカウントを作れない、という状態になるわけです。
そのような場合は、指定の短期間しかアップロード／ダウンロードできないようにする、パスワードを併用する、URLをワンタイムの長めの乱数になる（実質パスワードと同じような効果）などの方法で代用することになります。
こちらは、受信（ダウンロード）側がクラウドサービスを指定したケースですね。
双方アカウントを作れる場合と比較してどうなるかというと。総じてこんな感じ。
- 双方アカウントよりはリスクは増えるが、メール送信型よりは安全になる
- アップするファイルの暗号化は依然したほうがよさそう。
- もし実装がだめだめなクラウドを選んでしまったら、メールよりデグレ
詳細は以下。
要件aは、確実な特定はできなくなります。
アプロードの方法を何らかの方法で相手に伝えるので、「それを知っているはずの相手しかアップできないはずだけど、、」としか言えなくなる、と。
また、制限についてですが、サービス自体が連続接続に対してレートリミットかける仕様などを持っていて、ランダムURL長やパスワードの複雑さとダウンロード有効期限を比較して、攻撃者が十分な回数の施行ができない条件を整えているなら可能といってもいいかもなのですが、このいずれかが欠けていると、ブルートフォースでアップロードURLがばれて、というシナリオが成立してしまいます。
また、アップロード方法の通知ですが、ワンタイムURLを電話で伝えるというわけにもいかないでしょうし、事前にＵＲＬを決めてしまうとブルートフォースリスクも出てきますから、、メールで伝えるしかなくなる気がします。
そしてそのメールが盗聴されていたら不正ファイルを上げ放題になる、と。
もそもとメールは、宛先アドレスさえわかってしまえばメール送り放題（明らかなスパムは除く）なわけですから、それと比較してより危ないというわけでもないのでしょうけれど双方アカウント型と比べれば強度はおちますね。
また、誤送信のリスクも再燃します。
データを送りたいＡさんのURLと、関係ないBさんのURLを取り違えるシナリオです。
メアドと違ってちょっとしたタイポやドメイン間違いですり替わることはないですから、発生リスクはだいぶ下がると思いますが、URLをメールで送る際にメール自体を誤送信すると、あり得るっちゃあり得るのかもしれません。
（一般的な、「案件進捗アップしてくれ」とか、「年末年始の緊急時の連絡先教えてくれ」とか）
まぁ、メールよりデグレする、というものではないですかね。
b,c,d,e,fについては双方アカウントと同じ。
ただし、この方法の場合は、fの「プロジェクトデータの一元ストレージ」として使うケースはなかなか成立しないでしょうね。。
さておき、メールよりはGood。
gについてですが、aで記載した通りクラウドストレージの実装によっては、第三者が変なファイルをアップしてくるとリスクが出てきます。
盗聴リスクは増えません。
改ざんリスクはというと、ファイルが上書きされないという制限はさすがにクラウドストレージの一般的な仕様でやってくれると思うので、これも大丈夫かと思います。
ただし、多数のファイルに紛れて、マルウェア入りのファイルがポンと置かれる、、というリスクは出てくるのですが。
5.3.3. データのアップロード（送信）はアカウント登録必須、ダウンロード（受信）は代替え策も場合
送信（アップロードロード）側がクラウドサービスを指定したケースですね。
双方アカウントを作れる場合と比較してどうなるかというと。総じてこんな感じ。
- アップするファイルを暗号化していれば、メール送信型よりはちょっと安全
- アップするファイルを暗号化していない／暗号化してもPPAPライクの方法をとっていると、メールよりデグレ
- もし実装がだめだめなクラウドを選んでしまっても、メールよりデグレ
詳細は以下。
a,c,d,e,fについては双方アカウントと同じ。
総じてメールよりはちょっといい。
要件bとgは、5.3.2と同様。
ただし、URL通知のメールが盗聴された場合や、ダウンロードURLを誤送信した場合のダメージがかなり大きくなります。
こちらはデータが盗難（盗聴）できることになってしまうので。。
アップしているファイルを暗号化していればメール方式とトントンの強度で踏みとどまりますが、もし平文でアップしていたら、大デグレ。
また、暗号化していても、PPAP踏襲の復号パスワードをメールで送る方式をとってしまう場合もアウト。
【脱線4】再掲 メール本文どーすんの？
機密情報は添付ファイル／クラウドストレージに!!が達成しきれた未来が来たなら、メール本文の役割は、クラウドストレージのURLの通知するなど、主たるデータの送受手段のサポート、になるのでしょうね。
そもそも、それらのやり取り自体も丸ごと、teamsやslackに寄せてしまうのでもいいかもしれません。
うっかり機密情報が本文に染み出すリスクを考えるなら、メールをやめて、アカウント管理ががっつり聞く前提のチャットに寄せる方が安全なんでしょうね。
新規の組織とプロジェクトを始める際などにはちょっと面倒になりますが、現実的に耐えられるレベルで収まる気がします。
アカウント作るための最初の案内だけはメールでのやり取りとして残る、ですかね。
あるいは、盗聴／改ざんされてもさして問題がないような、広告やイベント案内の通知用。
こっちは本当に必要なの？という気はしますが、現実的に送信者指定なしのpush型通知ってメールくらいしかないでしょうし。
こういう未来が来たら、、、数年くらいは安全なのかな。
遠からずクラウドストレージやチャットにも運用上の脆弱性が出てきて、またバタバタするんでしょうけど。
5.4. メールの暗号化／認証認可を強化するんじゃダメなん？
運用しきれるなら、この議論の発端にある「メールは盗聴される」の条件を覆せるわけで、当然ベストな選択なわけですが。
。。。これまでできてないものがこれからできるの、、、、？というのが素直な感想。
通信経路の暗号化まではすでにかなり浸透している気がしますが、誤送信つぶしのキーになる送受者の認証まで踏み込んだ場合にきつい気がしてます。不勉強で時代遅れなだけだったら大変お恥ずかしいのですが。
6. なんで組織ごとに使うクラウドサービスが変わるん？
6.1. 組織は使ていいサービスをどう決める？
どの組織も、既存のPPAP/TOBEのメール添付暗号化よりも安全にしよう！と、各組織で基準を考えて、それを満たせるクラウドストレージを探していくわけですが。
その際、世の中のすべてのクラウドサービスをチェックしてOK/NGのお墨付きをつけるなんてできるわけもなく、めぼし付けたサービスからチェックしていくアローリスト型の運用になるわけです。
で、自組織が主要で使う数件のチェックで力尽きる、と。
各組織が自分のチェック終わっているサービスを使おうとするので、最初の記事のように、相手によって使うサービスを調整する、、というなんだかなぁ、、、な状態になる、と。
この際、自社でチェック終わっているサービスの利用を押し通せたり、相手が使いたがっているサービスを都度自社の基準で審査できればメール時代より安全になるんでしょうね。
それができず、相手が使いたがっているサービスをうのみにする運用になり、相手がちゃんと審査できてない組織だったりすると、、、メール時代よりむしろ危ないことになる、と。
こうなると、権威ある団体に基準つくっていただいて、PCI DSSのような審査してもらいたくなるのですが、、
やったとしても基準がリリースされる頃には世の中の情勢変わっちゃってるでしょうね。。
なんとも。
6.2. 自分と相手、どっちのルールを優先するん？
委託側と受託側などの要素が頭をよぎりますが、結局のところ、契約などの権威ある条件を紐解いて「その方法で事故ったときにどっちが責任をとるのか」で決めるしかないんだと思います。
契約書の解釈上どうなるのか、契約はさておき相手はその認識でいるのか、などなど面倒な条件が多数絡んでくるのですが。
そもそもPPAPが定着してしまったのも、「なぜ添付ファイルを暗号化しないといけないのか／どう運用すればその目的を果たせるのか」が現場に浸透せず、「なんか知らんが添付ファイルはパスワードzipにしろと言われている」という低解像度の情報に化けちゃったことにあるんだと思ってます。
そんな中、「法的な責任の所在」なんて話を現場に落とせるかというと、、無理でしょうね。。
「受け取りは自分のサービスで」「送信は相手のサービスで」とか？
アカウント実装を考えるとこれが安全な気がしますが、組織の情報管理の脳内を想像すると、受け取る情報よりも渡す情報の方が怖い（情報流出になるから）ということで、むしろ逆のほうがいい、となる気もします。
で、許可済みのクラウドストレージ以外へのアクセスを全部プロキシで切る、と。
厄介な話だなぁ。。
まとめ
頭の中の違和感を吐き出してみました。
はじめは「よっぽど変なサービス使わない限り、どうあれクラウドストレージの方が安全」という気がしてたのですが、、
脳内整理していくうちに、運用間違えるとPPAPとトントンまでデグレしうる危ないものという認識に変わりました。
おそらくまだまだ考慮すべきシナリオが足りてない気もしつつ。
きれいにまとめられませんが、都度都度頭の整理してかんとなぁ、、
ちなみにここら辺の話をファイル単位で実装するのがMSのAIPなわけで、あれが普及してくれると嬉しいなーとい気はしつつ、あっちもアカウントの制約がきついんですよね。。
アカウントをどううまく使うか／分離するか、が重要になっていく気がします。