Web における Security, Safety, Trust の相対性

Intro

我々は、インターネット上において「信頼」できるサービスを、「安全」に使うことに、「安心」を求める。

プライバシーは守られ、不正な取引には加担せず、詐欺被害も受けたくない。

技術的に言えば、通信は暗号化し、個人は匿名化し、データは秘匿し、それによって Secure で Safety で Trustworthy な Web が手に入る。

それを突き詰めた先に、「自由」で理想的なインターネットがある。

本当だろうか?

Eve とは誰か

Alice と Bob の通信の間にいる Eve は、暗号化されていない通信を覗くことができる。

スノーデンによって告発された PRISM は、「Eve が一人の攻撃者とは限らず、国家そのものであり得る」ことを明るみにした。広域盗聴による監視活動は、国民の安全を守るためという大義のもと実施された。もしかしたら、それによって未然に防がれたテロなども、あったのかもしれない。

しかし、盗聴は盗聴だ。スノーデン以降「どんな通信技術を策定する際も、暗号化を前提に考える」という方針が IETF 全体のムードとなった。HTTPS Everywhere を経て、Web では HTTPS 化が急速に進み、TCP + TLS で二重のハンドシェイクをするオーバーヘッドを減らすため、UDP + TLS/1.3 を前提とした QUIC が策定された。QUIC は HTTP の枠を超え、デファクトの通信基盤としてあらゆるプロトコルを over QUIC に飲み込んでいく。Eve が、まるっと保存したパケットの暗号化キーの提出を法律を盾に迫ろうとも、量子コンピュータが実用化し既存のアルゴリズムが危殆化しようとも、将来にわたって暗号が破られないよう PFS や PQC の展開が急ピッチで進められている。

これで、Alice と Bob の間の通信は、Eve に漏れることはなくなる。Eve が国家であってもだ。国民の通信の秘密は守られ、安全で安心で信頼できる自由なインターネットが手に入った。

もし Alice と Bob が反社会勢力やテロリストだった場合も同様だ。闇バイトで募った人を海外に監禁してフィッシング詐欺に加担させようとも、ビットコインを大量に盗んでテロの資金源にしようとも、その行為が国家の安全保障の網をすり抜け、不安定な国際情勢の導火線に火をつけ、隣島の有事や第三次世界大戦を勃発させようとも。Eve が危機を未然に防ぐために、指名手配犯の通信を監視することは、技術上できない。

国防の観点からそれを野放しにできない政府は、デバイスに政府発行の CA 証明書のインストールを義務付けようと試みたり、政府だけが知るバックドアを設置させようと命令する、そんなニュースを頻繁に見るようになった。

これによって体制に提供されるのは、「治安維持の手段」なのか「言論統制の手段」なのかは、文字通り表裏一体だ。我々ユーザが切に願う「通信を覗かれたくはない、でも治安は守ってほしい」は、インターネットが深く社会インフラに入り込んだ現在、ダブルスタンダードとなってしまった。

「税金を払う代わりに警察に守ってもらう」のか「誰にも頼らない代わりに何があっても自衛する」の二択で前者が選べるのは、警察が信用に足る場合だけだ。一方、ファベーラや九龍城のような治外法権領域は、法律がない代わりに自警団による一定の自治もあった。時に陰惨な私刑や無秩序な混乱があることを外部からは非難されても、外から逃げ込んで内部に根付いている人たちにとっては、外の信頼できない警察や官僚に捕まるよりも、よっぽど安全だったという話もある。「嘘だと見抜けない」「危険だとわからない」「騙されていると気付けない」人に使うのは難しいで済んだこれまでのインターネットは、まさしくスラムのような場所だった。しかし、今日常生活をインターネットに依存しているユーザに「ここはスラムなんだから自分でなんとかしろ」と言い捨てていいのだろうか? ベッドの下にショットガンを隠して震えながら寝るのが、正しいサバイブの仕方なのだろうか?

オールグリーンのフィッシングサイト

オンラインのサービスを使う際に、それが「使っても大丈夫か」を判断するのは、Web を生業にして長い筆者のような人間であっても、決して容易ではない。まして、「誰が何からどう安全なのか」を、一般ユーザが判断するのは、本質的に無理だとすら思う。

例えば、かつてはこうした盗聴に対策した HTTPS 経由での通信は、平文 HTTP 通信に対して「安全」とみなされた。それをシグナルするために、URL バーは緑色の鍵マークが付き、「これがついていれば安全だ」というリテラシ教育が行われていた。

しかし、安全なのは「通信」だけだ。接続した先がフィッシングサイトだとしたら、「自分とフィッシングサイトの通信が盗聴されていない」ことが担保されるだけだ。鍵マークは「通信が安全に行われている」ことを表明するが、「アクセスしたコンテンツが信頼に足るものか」を示すものではなかった。それでもユーザは「緑だったから大丈夫だと思った」と勘違いすることになる。

なんなら、HTTPS が普及しきる前は、本物の銀行サイトはまだ HTTPS 化できていないのに、それに偽装したフィッシングサイトは Let's Encrypt で HTTPS 化されているという皮肉な例もあった。今では「HTTPS は通信の基本なので、緑にはせずニュートラルに扱う。代わりに HTTPS になっていないサイトを赤くすることで警告する」という方針に変わった。(ここでも「赤い」ことは「通信」の危険を示すが、「コンテンツの危険」を示すわけではない。)

EV 証明書で表示された組織名も、アメリカでは別の州で同じ名前の会社を作れるため、偽装が可能なことが発覚した。わざわざ組織の存在を確認する追加の手続きとコストを経ても、わかるのはその組織が確実に存在することだけだ。その組織が反社会的勢力の隠れ蓑で、そのドメインでホストされるのがフィッシングサイトでも、「この組織は存在する」というお墨付きは得られる。結果アドレスバーの組織名は表示されなくなっていき、EV 証明書を発行するアドバンテージは、少なくとも Web ではほぼなくなってしまった。かつて「安全なサイトかどうかを見極めるためのシグナル」とされていたものの成れの果てだ。通信の安全とコンテンツの信頼は別モノなことを、まざまざと表している。

特に金融系サービスでのフィッシング詐欺は、連日のニュース報道が止まらない。偽サイトにパスワードを入れてしまう問題の解決方法として、「必ず URL を確認しろ」は現実的にワークしなかった。モバイル端末で長い URL の後ろが途切れることを利用し、巧妙に偽装したサブドメインなどを用いれば、ちゃんと確認している人ですら騙すことが可能だ。結果モバイルブラウザは eTLD+1 しか表示しなくなったが、依然として 0 と O といった似た文字で偽装するという古典的な方法は実際ある程度ワークしてしまう。

「SMS で送られた URL は信用せず、ログインする場合は必ず一回ググる」がワークする場合は多いが、検索結果が信用に足るとは言い切れない事例も出てきた。SMS による 2FA を導入しても、両方を本家サイトに Proxy され、Session Cookie を盗まれれば終わりだ。もう頼れるものはパスワードマネージャくらいしかない。Lastpass もインシデントがあり、1Password をどこまで信じるか、Apple/Google/MS のマネージャが政府に売り渡されないかといった懸念だってゼロではないが、今自分の目の前にある日常的な脅威と比べれば、確率論的に入れた方が良いのは確実だろう。問題は、パスワードマネージャがあくまで自衛手段であり、サービスからユーザにパスワードマネージャの利用を強制する手段はなかったことだ。

Authenticator を運用してもらえれば WebAuthn が使え、サイトはログインをダイヤルキーからシリンダー錠に変えることができるため、フィッシング対策にはなる。ビッグテックはモバイル端末に所有を担わせ、サポートと普及を目指そうとしたが、端末にへばりついた鍵は、移行や紛失でのリカバリ難易度がネックとなり、今ひとつ広がりきらなかった。ならば、「秘密鍵を抜き出してクラウド同期してしまえば良い」というのが Apple が最初に出した Passkey の発想だ。これにより Passkey に移行する敷居はかなり下がり、シリンダー錠をスマートロックに変えることができた。しかし、Passkey の本当の効能は「ユーザにパスワードマネージャの利用を強制する」合法的な手段が、フィッシング対策を盾に手に入ったことなのだ。

FIDO とベンダが揉めた結果「共有しなくても Passkey と呼べるはずだ」などというポジションの奪い合いはあったが、そんなことはどうでもいい。同期するからこそ、ユーザを安心して移行させられるからこそ、Passkey には意味があるのだと筆者は感じる。

Authenticator は秘密鍵を内部に生成し、決して取り出せないから「安全」だったのではないのか。無理やり取り出そうとしたら壊れるのが「耐タンパ性」だったのではないのか。そのたった 1 つのモノを「所有」している事実が認証要素だったのではないのか。Passkey は二要素と言えるのか。

サービスが顧客を守るために必要としていたのは、漏洩しない秘密鍵でも、パスワードを無くすことでも、多段の確認で確度を上げることでもなく、「そのサイトが本物かどうかをユーザに代わって調べてくれる誰か」だったのだろう。淡いの合わせ方が違ったのだ。少なくとも今、金融各社からの「FIDO 移行のお願い」メールが鳴り止まない、大フィッシング時代においては。

3rd Party Cookie という冤罪被害者

3rd Party Cookie の廃止が進む背景は、3rd Party Cookie そのものが悪かったのではない。それを用いて行われる Single Sign-On などのポジティブなユースケースは、全く非難されるものではなかった。問題は、「トラッキング」というユースケース側の問題で、これを法的な規制によって防ぐことに限界が生じたことが、大元を辿って「方法としての 3rd Party Cookie Deprecation」に至った。作ったシステムが悪用され、とりあえず逮捕されたエンジニアのような構図だ。

30 年近く前から、定期的に発覚するプライバシーインシデントの累積があるのでやむを得ない。代表例としては、ケンブリッジ・アナリティカによる Facebook データを用いた、米大統領選挙や Brexit へのプロパガンダ操作がある。大量のデータを集計すれば、「投票意思を保留している」人が割り出され、そのアカウントのタイムラインに対して意図的なメディア操作を行うといった投票の誘導、いや民意の操作が行われていたとされている。

対して、最も強固で代表的な規制は EU の GDPR だろう。ヨーロッパがプライバシーの問題に対して敏感なのは、ナチス時代、大規模な国民監視や個人データの悪用を目の当たりにし、それが大量の痛ましい結果にも繋がった歴史を色濃く表しているためとされている。ヨーロッパの人々にとってプライバシーの保護は、基本的な人権の中でもプライオリティが高いように思う。そこで生まれた正義の価値観が世界に乱反射し、生態系に大きく影響する。

日本人のように同等の権利を有しながら、当事者意識の低い国民には、過激なものとして捉えられがちだ。日本が策定する個人情報保護法や、電気通信事業者法などは、欧米のものを後追いでコピーし、少し薄めて施行している印象を個人的には受けている。日本の Cookie バナーは、許可の取得が強制ではなく、単なる通知で良い。知らされたところで何をするかは、個人が自衛するしかない。つまり、多くの人は何もしない。

戦時中の大日本帝国が、ナチス統治下とどのくらい異なったのかはわからないが、こんなにも意識の差があることは非常に興味深い。自治が成り立つ国における「やましいことが無いのなら、隠す必要が無いだろう」という、昭和平成の空気の残り香が、今でも感じられなくない。

もしこの記事を読んでいる貴方が、下にある Gmail の URL を踏んだら、ユーザであれば自分の InBox が開くだろう。

• https://gmail.com

この blog.jxck.io と gmail.com は eTLD+1 が異なる。つまり Cross-Site だ。それでもログイン済みとして遷移されるのは、GET に Gmail の認証 Cookie、つまり 3rd Party Cookie が送られているからだ。それ無しでは、毎回ログインを促されることになるだろう。こうしたセッションの維持や、SSO による認証の連携を例外としながら、3rd Party Cookie は「やましいこと」をすべて肩代わりさせられ、追放されようとしている。

追放したところで、「トラッキング」というユースケースを根絶やしにできたわけではない。業者が結託してメールアドレスで名寄せを行えば、そのエントロピーは多額で売買されうる名簿となりうる。

真っ当な「技術」だったはずの 3rd Party Cookie は、いつの間にか「必要悪」扱いされ、「悪の代表」とみなされ、今まさに消されようとしている。我々の「安心」のために。

Onion Proxy の箱庭

企業の不正は、そのほとんどが内部告発によって明るみになっている。告発者が不利に扱われないよう、匿名でそれが行える体制が、企業そのものに設置されるようになったのも大きい。過剰なほどにコンプライアンス重視な現在に繋がる、社会の改革だった。対象が政府機関や軍隊の場合、告発者のリスクは特に大きく、社会的な地位や命までもが危険にさらされる歴史があった。そこで、多段の Proxy を経由し、完全に発信元を隠匿した告発が、安全に行えるようにしたネットワークが作られた。それが Onion Proxy だ。

話題になった人物は匿名ではなかったが、Wikileaks 事件やスノーデン事件が有名だ。非営利団体の ProPublica は、告発だけでなく「誰にも記事を読んだ事実がバレないように」という、読者のためにも Onion 上にメディアを持っている。検閲下にある人間にとっては、情報にアクセスした事実だけでも不利な立場に立たされることがあるということだ。

足がつかずに安全にアクセスができるということは、そこでの犯罪も追跡が難しいことを意味する。Onion Proxy の中が「ダークネット」と呼ばれる所以だ。

ダークネットには、ドラッグや偽装パスポート、児童ポルノやマルウェアソフト、最近では DDoS の代行や仮想通貨での資金洗浄まで、さまざまな犯罪が「取引」されている。我々がニュースなどで見るサイバーインシデントの裏には、ダークネットを背景とするものが目立ってきた。

匿名性を担保されたからこそできた体制側の不都合な事実の告発と、ダークネットがなければ起こらなかったかもしれない犯罪について、どう天秤は傾くだろうか?

Proxy を経由すれば通信元を秘匿できるという手法は、Web の世界でも OHTTP として標準化されている。元となる技術は、Apple がリリースした Private Relay だ。Cloudflare か Fastly の Proxy を経由して、どこからアクセスしたかはわからなくなる。IP を隠すということは、Fingerprint ベクタの中でもっともエントロピーが大きい要素をなくすということだ。接続したサービスから Fingerprint でトラッキングされる心配はほぼなくなるだろう。

ところで、この機能を用いた誰かから、SNS で自分に対する誹謗中傷を投稿されたとしよう。IP 開示請求をし、その IP から犯人を辿ることができると思うかもしれない。

ユーザーのウェブ閲覧リクエストでプライベートリレーが使用されている場合

Apple がプライベートリレーの IP アドレスから

ユーザーのクライアント IP アドレスや対応するユーザーアカウントを特定することはできません。

プライベートリレーの IP アドレスに関連付けられた Apple ID について、Apple が提供できる情報はありません。

— https://www.apple.com/legal/privacy/law-enforcement-guidelines-outside-us-jp.pdf

そういう機能が、匿名 Proxy や VPN などを自分で設定する必要もなく、iPhone の設定画面をタップして月 150 円課金するだけで有効にできる時代になった。

安全になったのは、誰なのだろうか?

誰と誰の E2E ?

WebRTC は DTLS を用いて End-To-End で暗号化できる。ところが、N 人の話者が nC2 の接続を張れば、デバイスもネットワークも負荷が上がり続ける。そこで多人数会話のためには、SFU/MCU のようなサーバを介し通信を最適化するのが一般的だった。DTLS を話す相手はサーバで、そこからクオリティ調整や画像合成を経て、DTLS で相手に配信されるのだ。

「通信は(DTLS を用いて)E2E で暗号化されているから、安全に会話できる」と Zoom は宣伝した。しかし、顧客は E2E を Alice と Bob の間での暗号化だと解釈し、そうなっていない Zoom の構成を「Zoom は顧客に嘘の説明をし盗聴している」と騒ぎ出すことになる。

確かにまあ、ユーザの気持ちはわからなくはない。通話内容がサービスの人間に見える状態と想像したら、そこに気持ち悪さはあるだろう。「アイツらは嘘をついている。E2E とは嘘ばかり。危険だ。使わないほうがいい。」と喧伝することで、有識者ぶるセキュリティ専門家仕草も、まあいいだろう。このニュースを見た多くの通話サービス開発者は、「いや、E2E プロトコルとしての DTLS を使ってサーバまでを暗号化しているという意味だったのに、そう解釈されるのか、、」と気づき、急いで説明の文言を修正したサービスも見かけた。

一方、多対多通話の動画構成では、ユーザの置かれた環境(画面、カメラ、ネットワーク品質 etc)は様々で、サーバにはそれらを調整する役目(SFU etc)となる必要がある。サーバ側で解像度を調整したり、画面を合成したりと、様々な「最適化」を提供してきた。ユーザ間 E2E では、それぞれが自分以外全員とハンドシェイクして通信するため、サーバは通信の中身が一切見えない。N 人対話なら N-1 本の転送するだけ、サーバによる最適化の余地は全くない。人数が増えれば、クライアントの負荷も、ネットワークの負荷も、ただ増えるしかない。業界が長年積み上げてきた、動画転送最適化技術のほとんどを適用できる余地もほぼなく、頑張れるのはクライアントだけだ。

通信料も、不安定な会話も、熱々のデバイスも、全て「サービスを使って通信をしたい。でもサービスには何も見られたくない」という安心への対価として、ユーザにのしかかる。

実際、Line の Letter Sealing など「ユーザにとっての E2E」を提供しているサービスもあるので、メッセージングで E2E といえば、メッセージを送るユーザと受け取るユーザだと思うのも、一般的になってきているのかもしれない。テキストの場合も、サーバは素通りするだけで、トークをバックアップすることもできない。ユーザが端末移行をミスって過去のトークが読めなくなっても、もちろんサービス側ができるサポートは何もない。

ところで、それは本当に安全だろうか? E2E で転送され、復号されクライアント上に可読テキストとして表示されたメッセージを、クライアントが絶対に盗めないという保証はどこかにあるだろうか? 動画だろうと音声だろうと同じだ。「その気になれば」の話だが、それを言い出すなら、得ているのは「安心感」だけで、「安全」である確証はないことになる。サービスを使っていながら、そのサービスに見られたくないというのは、そもそもかなり矛盾した話だ。

どうしてもというのであれば、WhatsApp や Signal はそれを可能にしている。徹底して E2E が行われ、サービス自体どころか、政府にも警察にも見られずに通信できる。この特性を利用して、内部告発者はもとより、闇バイトからテロリストまで、安全で安心な連絡手段として重宝されている。一方、米・英・豪政府は暗号化へのアクセスを強制するように求め、議論中だ。先日仏のみが否決したが、他がどうなるかはわからない。

安全か不自由か

Chrome の拡張が Manifest v2 だったころは、ブラウザ上で考えうることは、おおよそなんでもできた。ブラウザで発生するすべてのリクエストをフックして、処理を挟んだりレスポンスを置き換えたり、ブロックすることもできた。だからこそ、Ad Block のようなユースケースが実現した。「これは Tracker だ」というリストさえあれば、すべてのリクエスト先をチェックして、フィルターすることができる。

これはつまり、ブラウザで行われるすべてのリクエストを監視し、そのリストを盗み出すことも可能であることを意味する。ブラウザの履歴が盗まれているのと同じだ。うまくいけば認証情報まで盗める。外部から動的に取得したリソースが動的実行できるため、審査をすり抜けた拡張がインストール後に猛威を振るうのは容易い。自衛手段は「信用できる拡張しか入れない」ことだった。では、信用できる拡張かどうかなんて、どうやって確証できるだろうか?

そんな曖昧な検証でマルウェアが蔓延する事態を防ぐために、Manifest v3 では、外部リソースを実行することも、すべてのリクエストをフックすることもできなくなった。これにより、従来の実装方法での Ad Block はできなくなったのだ。

これを「広告が表示されるよりも、もっと最悪の事態からユーザを守るため」と解釈するのか、それともそれは建前で「Google は自分たちの広告が表示されなくなると都合が悪いから Extension を改悪した」と解釈するのかの判断は、個々が行えばよいだろう。後者の論調の方が強いため、v3 への風当たりは強い。

人は、「安全になる」ことよりも「選択肢を失う」ことの方に、より敏感に反応する。「ウイルスに感染したくなければ外に出るな」と言われると、「外出の自由」が主張されるが、自由な外出を許しパンデミックが起きれば「警告を怠った」と非難される。広義のプラットフォームは、何を変えようと、どういうモチベーションだろうと、だいたい非難されるものなのだ。できることは、デフォルトを安全側に倒し、エスケープハッチとして Opt-In での回避策を提供することで、「Opt-In したという自己責任」にすることくらいだ。

「安全」側に倒す施策は、必ずしも受け入れられるとは限らない。人が求めるのは、常に自分にとって都合の良い安全なのだ。少なくとも「技術的」に見れば。

Walled Garden の対価

社用スマホとして iPhone SE が配られている企業は多いだろう。世界では Android の方がシェアが高いが、特に日本のビジネス用途では iPhone のシェアが高い。Android デバイスの方が安価でも、iPhone を配りたいのはセキュリティ管理のニーズからと言われている。

iPhone は Jailbreak でもしなければ、単一の Store からしかアプリを落とせない。提供元不明の APK ファイルを、どこかから拾ってきてインストールできる Android と比べれば、この制約は「やらかす奴を減らす」ことにも繋がる。そして、やらかす奴はどこにでもいるし、絶対にいなくならない。拾ったアプリがマルウェアで、再三の警告を全部無視してインストールし、機密情報をごっそり抜かれ、やっとやらかした端末を特定して話を聞いても「そんな覚えはない」と平気で言うようなリテラシの社員はどこにも一定数はいる。iPhone SE という、性能も価格も中途半端に見えるモデルは、超高性能カメラもハイスペックな CPU もいらないから、もっと安く調達して配りたいという、ビジネスユースを見据えたラインナップとして、国内企業から支持された。

CM で大々的に喧伝しているように、実際 Apple 製品はプライバシーやセキュリティに対して強固だ。唯一許されたブラウザエンジンで ITP で 3rd Party Cookie を独自にブロックし、標準化もされていなかった Privacy Relay をサービスインして通信を秘匿し、秘密鍵を端末から抜き出し共有するご法度を犯してまで Passkey を普及してパスワードをなくしフィッシング詐欺を防ごうとしている。姿勢自体には一貫性を感じる。

ここで Apple の Store に払う手数料は、こうした安全を維持するための必要経費か、不当に搾取される既得権益なのかは、立場によって変わるだろう。今それは競争のフェアネスの観点で問題視され、「他のストアにも門戸を開く」ために撤廃するように要求されている。緩和したストアやブラウザエンジンにも制限は課されるとしても、これまでの強固なプライバシー/セキュリティの鉄壁がほころんでいくことは避けられないだろう。それを Apple がどう力説しても、アプリを出して手数料を取られているベンダは「それはお前らが収入を守るための詭弁だ」と反論する。

普及した物理端末、モバイル/デスクトップ OS、ブラウザエンジン、ストア/プラットフォーム、すべてを持っているベンダはそんなにない。だからこそ Apple にしかできないことは多い。その統一された世界を維持する労力も、エンジニアならわかるだろう。しかし、そのプラットフォームに乗るための手数料を取るのは、「汗をかいてない PayPay」問題と同じ構図で批判されている。(ちなみに、批判の先頭に立っていた Spotify は、手数料すら払ってなかったと Apple は主張しているが。)

このサイドローディングへの圧力も EU 圏からのものだが、こちらはプライバシー観点より、経済活動のフェアネスでの文脈が強い。EU の求める「自由な市場活動」と「個人のプライバシー尊重」だけを天秤にかけて俯瞰で見たら、それすらもダブルスタンダードに見えなくもない。そして、最近ではイギリス政府が Apple に対して、iCloud にバックドアを設置するよう求めているという話もある。

プラットフォームが大きければこその軋轢は、避けては通れない。時には不当な搾取や圧力といった、腐敗に行き着くこともある。しかし、技術的に見れば「大きいプラットフォームだからこそ担保できる安全」は、否定しがたい。小さく瓦解していった先に、求める安全や安心や信頼があるかは、誰も保証していない。まるっと身を委ねられる大きな存在がない場合は、自力で細かなピースをつなぎ合わせながら、自衛していくしかない。これを読んでいるようなあなたはできるかもしれないが、あなたの家族や友人も、本当にそれができるだろうか?

坊主代わりのウイルス対策ソフト

どんなに堅牢に作ったシステムを自負していても、ターゲットとしてロックオンされ、執拗に狙われれば、基本的に陥落は時間の問題だ。大抵のシステムは、それを完璧に守りきるためにかけるコストが、収益に対して見合わないため、それは必然的に起こる。

こうした攻撃は、だいたいは「人間の脆さ」に起因する突破口から、侵食が始まることが多い。機械を騙すよりも人間を騙す方が圧倒的に楽だからだ。働いている人間が一人でもいれば、それはもう脆弱性だ。通り一遍の対策をこなしたあとは、標的にならないことを祈るくらいしか、できることはなかったりする。あるいは、その人間をシステムから締め出し、仕事をさせなければ安全にはなるだろう。

「通り一遍の対策」とはいっても、やることは地味なものが多い。教科書に書いてあるような「基本的な対策」ができていれば、OS を最新にし、ミドルウェアを最新にし、ライブラリを最新にするだけで、ほとんどの対策は完結するくらい、エコシステムは習熟を見せている。大抵のサービスは、その「基本的な対策」ができていないことが問題なのだが。

日頃からこうした対策に気を配り、慎重な調査で技術を選定し、各種アップデートや検証を怠らず、社内への啓蒙に力を入れ、脆弱性報奨プログラムを運用していても、やられるときはやられる。残酷なほどにそれは起こる。

起こってしまったら最後、そこに対する責任は負わないといけない。早急な原因究明、情報開示、再発防止策、謝罪と保証が求められる。それまで行っていた対策は「不足していた」と評価され、何かを追加で施策し、それをもって「今まで以上に安全になった」という態度を示さないと、ステークホルダは満足してくれない。

結果、ウイルス対策ソフトや WAF などの導入を第三者委員会や、監査に入ったセキュリティベンダに言われるがままに、入れさせられることになる。

名前が非常にずるい。

具体的に何をしているのかはブラックボックスなことがほとんどでありながら、入れたら確実によくなるかのような顔をして売り込まれる。では、それを入れていたら、今回起こったようなインシデントは本当に防げていたのだろうか?これから起こるインシデントを塞ぎ切れるんだろうか?そもそも、世界有数のセキュリティリサーチを展開し、それを早急にパッチとして配布している大手 OS ベンダではカバーできないことを、そのソフトはどのくらいカバーできているのだろうか?入れたウイルス対策ソフトが余計な動作をし、それ自身が問題を引き起こすことが無いと、誰が保証してくれるんだろうか? WAF が SPoF になって、サービス全体が落ちることはないと、どれだけの SLA があれば信用できるだろうか?

人は、「追加で実施した方が絶対に安全だ」と言い切れるものが、どこかにはあると信じる傾向にある。「そんなものがあるなら、なぜデフォルトでそうなってないのか」を考えることはしない。強く責め立てられるセキュリティ担当者は、「それを入れて気持ちを収めてもらえるなら」と思い、経営者は「その導入コストで事態の鎮静が買えるなら」と思うことで、しれっと導入されるセキュリティアプライアンスを数多く見てきた。

目の前で売買される多額のそれは、そこまで苦労して運用されてきたセキュリティ対策を、すべて否定することで生まれる「安心」そのものだった。

「正しさ」の相対性

技術の「正しさ」は絶対値だと思われがちだ。確かに、理系学問として扱われるため、傍目だけでなく、学んだ本人も、そう思ってしまう認知のズレは生じやすい。

実際には、こうした技術のユースケースのベクトルを「社会」に向けると、そこに「人間の都合」という変数が必ず関わってくる。残念ながら、技術の「正しさ」は「人間の都合」に対して常に可変で相対的なのだ。値ではなく座標の方が変わっているため、過去のある時点で触れた値の絶対性を信じ続けていると、ズレが生じ軋轢が生まれる。

自由を追い求めて自己責任で片付けることもできない、多数決で決めて弱者を踏みにじることもできない、かといってどれがあるべき姿かを誰かが決めようとしても、対立が起こるだけだろう。そしてそれは起こっている。どちらが正しいかを機械的に決めるには、正しさの判断基準を提示する必要があるのにもかかわらず、その判断基準が人間によって揺らいでいるのだから、それを何かに付託することもままならない。

個々の持つ認知の歪み、経済合理性、世界情勢、主義主張。個人では把握できないほどの状態の均衡を、その時点での正しさのスナップショットとして、かろうじて運用している。ここはきっとそういう業界だ。「自分には答えがわかりきっている」と思い込んで結論を断言する無責任な人たちに惑わされず、どこかの哲学教授が言うように、わがままで都合の良い我々人間こそが「議論し続けていく」しかないんだろうと思う。

筆者とて、税金は安いに越したことはないが、警察はすぐ駆けつけて欲しい。プライバシーを侵害されたくはないが、テロは未然に防がれて欲しい。自分が見えている範囲で、騒ぎはなるべく何も起こってほしくない、傷つく人は出てほしくない。が、そうやって逃げ切れるほど甘くもない。できることがあるとすれば、せめてそこに議論があるという事実を、わがままで都合の良い人間の一人として、自戒の意を込めて書き残すことくらいだ。