🤔

え、HTTPSの転送なのにファイルも暗号化するんですか？？？

2021/03/20に公開

Security

idea

TL;DR

基本的には二重での暗号は不要
ただし、転送後も暗号化したまま使うなら、転送前から暗号化するのは良い
ルールXを無邪気に追加して不整合のあるセキュリティルールを作ってはいけない

はじめに

社内のセキュリティルールやスタンダードを決めるときに、HTTPSなのにVPN必須になってたりファイル暗号も必須になってたりするケースたまに見ます。今回は、それは実際に必要なことなのか？セキュリティ的に有効なのか？という点で考察をしていきたいと思います。

背景

二重三重に暗号化しても性能ペナルティが無いなら「なんとなく安全そうだから」でOKにしてしまいがちなのですが、これはよく考える必要があります。
というのも 「ルールXを追加することで既存のルールAと不整合が出る」 ってことは割とよくあるからです。具体的には「SCPのファイル転送は（SCPのセキュリティに不備があった時の）安全性のためにファイル暗号をすべし」というなんとなく「まあいっか」と言ってしまいそうなセキュリティルールが出来ます。しかしそれによってその横で動いている同等のセキュリティ強度の 「VPNの中を通している大量の平文」 や 「HTTPSの生ファイル転送」 が本来は全部NGになることです。もっと言うと「ユーザがHTTPS
HTTPS経由でWebサイトを通じて個人情報をやりとりする」自体がNG です。インターネットが信頼出来ないから経路暗号を使い経路暗号も信用できないからファイル暗号を重ねて使うというルール を作ると、一律NGにしないと同じ要件で違う運用がされてるダブスタになりますからね。

実際は「既存はそのまま」という謎の運用によりルールXと矛盾したダブスタ運用がされるわけです。別にVPNであってもファイル暗号を必須にしたり、「SCPのファイル転送」ではなく実は「大量の個人情報」とかセキュリティを強化したい明確な基準がありその基準に則って運用するのは全く問題無いのですが、そこら辺が曖昧だったり矛盾のまま突き進んだりすると困りもの。

ルールというのは一般的に「例外はあっても良い」のですが「不整合や矛盾」があると運用が面倒になります。基準が曖昧になるので。曖昧な基準は不必要な無限のコストや守らないことの常態化（オオカミ状態で大切なケースでも無視される）を招くため可能な限り避けなければいけません。

というわけで、前置きがとても長くなりましたが今回はそもそも経路暗号であるHTTPS/SCPとファイル暗号を組み合わせる必要はあるのかを考察していきます。

なぜ暗号化するのか？

さて、そもそもなぜ暗号化するのでしょうか？これは実は結構重要な確認です。もちろんデータを見せたく無かったり改ざん防止のために暗号化するのですが 「誰から守るか？」 ってのが大事になります。例えば、

インターネットなど信頼できない経路での通信の盗聴から守りたい
クラウド業者などデータを預けた先で自分たちのデータが彼らに閲覧させない
社員やステークホルダーであっても特定メンバー以外には見せたくない

それぞれの目的に応じて適切な方法は異なります。

暗号化のタイミング

暗号化はそのタイミングによって以下のように分けることもできます。

経路の暗号
ストレージの暗号
コンテンツ/ファイルの暗号

経路の暗号は通信を暗号化して盗聴に対する対策を行うための暗号化です。ストレージ暗号はファイルサーバやSSD/HDDそのものといったインフラ自体を暗号化して盗難やインフラオペレータからの不正アクセスを防止するために行われます。最後のコンテンツ/ファイルの暗号はDBの中のデータそのものやファイル自体の暗号化です。これは先程の2つと違い一般的には透過的な暗号ではなく利用者から見ても暗号化されているため明示的な復号作業が必要になります。

今回は主に経路暗号とコンテンツ/ファイルの暗号に関し話しをします。

VPNやHTTPSによる経路の暗号

まずはVPN(IPSec, SSL-VPN)やHTTPS、あるいはSSHによる経路の暗号について考えます。パフォーマンスや利便性、そもそもレイヤーなどいろんな違いはあるのですが、ことセキュリティ強度でいえば最新技術を適用してる限りはHTTPSでもSCPでもIPSecでもSSL-VPNでも大して変わりません。どの技術もRSA等利用した公開鍵暗号(非対称鍵暗号)やAESのような共通鍵(対称鍵暗号)を組合わせた「ハイブリッド暗号 ※1」が使われています。暗号アルゴリズムが同じであれば基本的には 「HTTPSよりVPNの方がセキュアとかではない」 というのが重要なポイントです。以下のサイトにIPSecとTLSの違いが載っています。

一方で、HTTPSを含めたTLSは通常はIPSecと違いサーバのみを認証するためクライアント側が何者であるかが分かりません。

ref: https://milestone-of-se.nesuke.com/nw-basic/tls/compare-with-ipsec-and-tls/

不特定多数からアクセスされるような公開Webサーバでは良いですが、特定の組織やシステムからのみアクセスを許可したい社内システムや企業間連携のときにはこれだと困ります。

そこでTLSでもmTLS (mutual-TLS)と呼ばれるクライアント認証の仕組みを使うことで双方向認証が可能です。また、アプリケーションそのものやIDaaS等なにかしらの認証基盤などで適切な認証が行われていればクライアントの認証はそれで良い、という考え方もできます。どこで認証するかの違いだけですね。

※1 共通鍵を公開鍵で暗号化して渡してるのだと誤解してましたが通常はお互いの共通鍵と自身の秘密鍵から共通の秘密情報を生成する鍵交換という手法が用いられるようです。下記が非常に参考になります。

ファイル/コンテンツの暗号

ちょっと前に話題になったみんな大好きパスワード付きZipもファイルの暗号ですね。DBの場合はカラム単位で暗号化して格納するようなケースもあると思います。

通常はファイルを暗号化するならば今なら共通鍵方式のAES256あたりが採用される事が多いかと思います。技術的にはRSAなどの公開鍵を使ったファイルの暗号化も可能ですが公開鍵では特性上大きなデータを暗号化できません。そのためファイルに使うことはあまり無いかと思います。なので、ファイル暗号に対して公開鍵のような非対称の性質を利用したい場合はハイブリッド暗号を用いる必要があります。

ファイル暗号は例えば経路が暗号化されてないネットワークを使わざる得ないときとか、イマイチ信用しきれないクラウドストレージを使う時とか、ファイルやデータ自体にはアクセス出来ても特定の人間にのみパスワードや認証基盤を使って公開したいときや、暗号化したまま運用したい時に利用します。

ZoomのE2E暗号云々がいっとき話題になりましたが、P2Pではないシステムで真のE2Eを実現する場合もHTTPS/TLSだけでは困難なのでコンテンツの暗号が必要になるかと思います。これもクラウド業者側を信用しなくて良くするための仕組みですね。

HTTPS/SCPによるファイル転送でもファイル暗号はするべきだろうか？

さて、ようやく本題です。経路暗号がされてる状態でもファイル暗号/コンテンツ暗号は必要でしょうか？
私の結論としては 「基本的には不要。ただしあった方が良い場合もある」 です。

TLSやSCPの暗号が解かれたらどうするの？

まず、暗号が解かれ単純にTLSやSSHが突破される場合を想定します。これに関しては可能性は0では無いかもしれないけど、正直考えても仕方がない、です。
HTTPSの暗号を復号する技術ができればたぶんファイル暗号だって解かれるでしょう。どうせAESとか同じようなアルゴリズムを選んでるでしょうし。

先日もRSA暗号を破壊するとの論文が発表されるも「ほぼ誤報」とみられるというニュースが流れTwitterでは当初から誤報扱いで大喜利祭りでした。RSA暗号が仮に解かれてもインターネットが壊れるレベルの被害ではないという説もありますが、甚大な影響を出しますしAES256とかならお祭りです。コンピュータ性能は年々上がっていますし、量子コンピュータが完成するとそれらも解かれるという説もあるので心配になる気持ちは分かります。

しかしながら適切な暗号化アルゴリズムに常に追従していけばたとえ量子コンピュータが登場してもゼロデイ以外は問題ありません。でもゼロデイは防げないんでしょ？と言われるとそのとおりなのですが、たとえあなたが医療システムや金融システムを作っていたとしてもゼロデイで真っ先に狙われるでしょうか？たぶん、政府系、とくに軍事とかが狙われるんじゃないかと思います。繰り返しになりますがファイル暗号と経路暗号に使われる暗号アルゴリズムはだいたい一緒なので、アルゴリズム自体が解かれるリスクを考えるならば対策はオフラインや完全な専用ネットワークでの運用になります。二重暗号では不十分です。そこまでのコストをかけるべきリスクがあるなら、そこまでかけましょう。

あと、古くて弱い暗号使ってると普通に突破されるのでやめるべきです。

TLSやSCPの脆弱性が発見されることもあるよね？

アルゴリズムそのものではなく、実装や仕様の脆弱性の話ですね。これは想定が必要です。
基本的には適切にパッチを当てておけば問題無いと思いますし、運用の課題ですが、未来永劫問題が絶対でないとはとても言えない部分です。

この点に関してはリスク見合いでの判断です。大量の個人情報の流出のリスクがあるケースなどは考慮しても良いのかもしれません。ただ、この手の脆弱性が原因で通信を覗かれて大量流出てのは（あるかもしれないけど）私は聞いたこと無いので闇雲に行わず、秘密鍵のやり取りとかそういうかなり限定的な部分で十分なのでは？と思います。

中間者攻撃で盗み見られる場合もあるよね？

カフェのWiFiなどを利用した中間者攻撃にはHTTPSやVPNの利用が良く紹介されますね。通信情報を除き見られてもクライアントとサーバの間でE2Eに暗号化がされていれば問題無いというわけです。DNSが偽装されてもHTTPSのホスト認証で弾かれますしね。

中間者攻撃という呼び方はしない気がしますが、DC内や専用線であっても通信の暗号化が求められる理由もEndではない間の事業者やオペレータが見れてしまう可能性があるからですね。このように経路の暗号は中間者攻撃にとても有効です。

しかし、昨今はより巧妙な手口も出てきているようです。VPNサーバやHTTPSな相手サイト自体がクラックされてる場合はそもそも別ですが、巧妙なマルウェアはHTTPSであっても中間者攻撃を成立させる場合があるようです。
https://jp.globalsign.com/blog/articles/maninthemiddleattack.html
※ これは参照した記事の内容がやはり相当怪しそう。普通に証明書エラーになる気はするし、信頼できるルート証明書発行機関ならドメイン認証してるから他人のドメインを登録自体できないはず。 GlobalSign...

ようはProxyとして動作しProxy自体を正規のつなぎ先としてクライアントに返すわけですね。ネゴシエーションの時点から本人のフリをするので一見気づくことが出来ないでしょう。普通にやると下記の試された記事ように証明書の警告が出るはずですが、上記のGlobal Signの記事はEV証明書の組織の部分を使えと言ってるので正規の証明書を使えばそこら辺の警告が出ないという話かもしれないです。個人的にはEV証明書が現実的に役立つとも思えませんが、それはそれとして。

悪意があるルータやWiFiが本気を出せばDNSやIP含めてほぼすべての情報は偽装可能な気はしますす。それとオレオレじゃない正規の証明書を組み合わせた場合に中間者攻撃はどこまで成立するのかは、ちょっと自分の中でも消化しきれてないので今度考えときたいです。非対称鍵や共通の秘密を持ってないのでどこかで失敗しそうな気はするのですが。ゼロトラストの文脈に反してる気もするので問題あるなら話題になりそうだけど。誰か詳しい人いたら是非コメントください。

この問題自体は成立するならばある程度警戒する必要がありますが、あくまで信頼できないNW機器を利用してる場合なので原則サーバ間通信の時には考慮不要 だと思います。同じDC内や別のDCあるいは別の会社のDCへのファイル転送とかではこのリスクを気にする必要はあまりないと思うので、するとしてもWFH向けの運用のときに考慮ですね。

クラウド業者は信用出来ないよね？

これもありますね。これは経路の懸念ではなく通信先のシステムが信用しきれない場合です。

荒唐無稽に思うかもしれませんが、監査を受けるような業界のシステムだと結構大事な観点。特に、法律が異なる国外の業者を利用する時は気になります。（個人情報守ってます！といっても「個人情報の定義はなに？」とかね）

これはそもそも通信の暗号に関わる部分ではないので、HTTPSで暗号化済みのファイルを転送するという事に意味があります。ファイル暗号を積極的に活用したいケースの一つです。ただし、転送直前に暗号化して転送直後に復号するような運用だと全く意味がありませんので、転送後も暗号化したままにしておく運用が基本になります。

とはいえクラウドだからと過剰に心配する必要も無いかと思います。
特に、3大クラウドはHIPPAとかPCI-DSSとかメジャーな第三者認証を取得しており、信用に足る運用がされていると言うことは出来るでしょう。注意点としてはAWSなどPCI-DSSやHIPPAに認定されたインフラを使うからと言って、その上で動くファイル共有サービスなどのSaaSが必ずしもPCI-DSSやHIPPAに準拠してるとは言えないことです。ちゃんとSaaS側も確認して自分たちの取れるリスクなのかを確認しましょう。

自分のDCや社員だからって信用できないよね？

クラウドのケースとほぼ同じですが自分たちのインフラや社員だからって信用できないですよね。
これも転送中の経路ではなく転送後の運用が信用できないと言ってるので暗号化する意味があります。

ここでもクラウドの時と同様に転送のタイミングだけ二重暗号化するなら意味がありません。あくまで、転送の前後のオペレーションで暗号化したまま取り扱いたいから暗号化して運用するということです。

余談ですがファイル転送ではなくAPIとかだと結構これが大事になってきます。というのも、エラー処理などでログに通信内容を吐く場合があるからです。当然これはトレースやデバッグの観点で重要な行為なのですが、個人情報等を含む場合はセキュリティ的にはまずいので暗号化ないしは匿名化/仮名化をしておきましょう。

結局いるの？　いらないの？

基本的にはいらないと考えます。ただし、リスクや運用目的に応じて特定のデータは通信経路に関わらずファイル暗号をかけます。

正直 「転送」 という極めて短いタイムラインでピンポイントにゼロデイ攻撃を受けるリスクを想定して過剰だったり複雑になる運用は避けるべきだと思います。専用線やDCなどかつては信頼出来るとさえれたNWの上でも暗号化するのが現在のスタンダードですが、あれは内部の中間運用者(及びそれらを利用したマルウェア)による盗聴を懸念してるので、経路の暗号化をしていれば十分に果たせるはずです。経路暗号だけで内部の人でもエンドではない中間では盗聴出来ません。仮に適用するにしても 「大量の個人情報」 とか 「Root証明書」 とか極めて高いリスクのデータと認定されたものだけで十分かと。

そうではなく、転送前後の運用に注目してファイル暗号を考えるべきです。基本的には暗号化したまま保管したり取り扱うデータに関しては HTTPSの転送なのにファイルも暗号化する意味があります。例えばACLをある程度緩めざる得ないIT管理者に対して、うっかり大量の個人情報を見てしまうのを防ぐとか。そのような観点でセキュリティルールを作るのが良いと思います。暗号化したままの運用を求められるものは通常はリスクが高いデータなので結果的に上記の極めて高いリスクのデータのファイル転送をHTTPS等のゼロデイから守ることにも繋がるでしょうし。

以上が表題の問に関する私の見解になります。ただ、これはあくまで今の私の見解ってだけなので 「〇〇の考慮が抜けておるわ、マヌケめ！」 とかがあればコメント求む、です。

それではHappy Hacking!