注意：自分でもちゃんと理解していないことを書いているので、以下の情報を鵜呑みにしないでください
初回掲載：2025/01/18
一般的な話の前に用語について。以下では「両方（ないしすべて）が揃ってはじめて認証に成功する」タイプのものを「and認証」、「どちらか（ないしどれかひとつ）があれば認証に成功する」タイプのものを「or認証」と呼んで、いちいち断らない。A or (B and C)の形（たとえば、普段は使わないマスターパスワードor指紋認証とPINコードのように）とか、(A and B) or (B and C) or (C and A)の形（3条件のうち2つ満たせばよい）など、より複雑な組み合わせもあり得る（というか実際上は組み合わせるのが普通）が、とりあえず上記だけ区別しておいて欲しい。
VPNにしろSSHにしろ、エンドツーエンドでセキュリティを確保しようとする以上「両エンド」自体（リモート先ホストが陥落したら試合終了なので、実質的にはリモート元ホスト）を守り切らなければ話が始まらない。たとえば、リモートログインを検出してトロイの木馬を送り込むようなボットに感染した端末からリモートログインをしてしまうと、どんなに丈夫なトンネルを使っていようと強力なワンタイムパスワードを使っていようと無力である。リモート先ホストにFWがあればアウトバウンド通信を検出できる望みがわずかにあるとはいえ、たとえば普段使っているブラウザにプラグイン（なり拡張機能なり）として組み込まれたらお手上げだろうし、rootログインを許してしまったらFW自体を無効化なり改変なりすることも可能になる（ハードウェアFWならまだ首の皮一枚残る期待があるけど）。ようするに、リモートからのログインに使う端末の信頼度が、リモートログインシステム全体の信頼度を決定的に左右する（だから筆者は、スマートフォンを極力dumbな状態に保って、複雑な処理はリモート先で行うようにしたい：すでに触れたように、リモート先の端末にバックドアを置かれたら負けなのはいかんともしがたく、リモートからのrootログインだけでも避けておくより他にないのではあるが）。
出先から自宅のホストにリモートするようなケースでは、必ず自分しか手を触れられない端末（現実的にはスマートフォンorタブレット）からログインして、他の端末を使わないことが必須といえる。リモート先のホストも、仮想環境上に構築して安全な状態でスナップショットを撮り、使い終わったらロールバックするような運用が理想だろうが、利用可能な資源を制限しすぎると使い勝手が悪化するためバランスが難しい。自宅から出先のホストにリモートログインする場合はさらに悩ましく、普段使っている環境やリソース（たとえばやりかけの仕事とか）にアクセスできなくてはリモートの意味がないため、事前に必要なファイルだけリードオンリーの外向けファイル箱に入れておいて、書き込みはサンドボックスの中でやり、後で砂箱の更新ファイルを拾い出すやり方が用心深い運用といえるだろう（利便性が落ちるのは間違いないが、権限の切り分けをやらずにセキュリティを保つのは不可能に近い）。もしくは、リモート元のホストを厳格に制限して、そのホストを厳重に守るのが次善だろうか（おそらくだが、中小企業を相手にするシステム屋さんの多くはこのポリシーで運用しているのだろう：rootでリモートログインできるようにしているトコが圧倒的多数だと思う）。
こういったことを考えても、単機能の中継サーバだけをWANから到達可能な所に置いて両エンドを隠しておくのは、一定のセキュリティ効果があると思う。サーバ用に1台マシンを確保できハードウェアキーを使わないなら、SSHよりはVPNかなぁという気がする。たとえ中継サーバが陥落したとしても、LANのセグメントがむき出しになるだけの被害に（設定が適切であれば）留められるはずだし、リモート元のホスト（仮想端末さえ飛ばせればいいわけだから、リモートログインクライアントとVPNの仮想ハブ、GUIログインが前提ならXに準ずるシステムは要るだろうが、それ以外の余計なモノはインストールを避けられる：VPNクライアントから中継サーバが見えてさえいればLAN内の他の端末とやり取りできる必要もなく、中継サーバが固定のグローバルIPを持っているならルーターでそれ以外の通信を全遮断してしまってよいしDNSに頼る必要もない）をdumbに保つうえでも有用だろう。本当に気合を入れるなら（筆者自身が試してみる気はないが）、中継サーバになるホストはシステム丸ごとロールバックできるようにセットアップしておき、システムアップデートの際はいったん外部と切り離してから、ロールバック＞アップデート＞追記のみ許可モードでスナップショット保存＞各種パスワードを更新＞運用再開という手順を踏むのが理想なのだろう（2系統以上用意しないとダウンタイム生じるけど、そこまではねぇ：仮想マシン使って複製すれば実現はできるだろうけど、今度は仮想環境のホストも守らないといけないし、性能上のオーバーヘッドもある）。こういった運用を考えるなら、市販のVPSサービスを（公開サーバ用に）使うのはけっこう効果的に思える。
もっとカジュアルな用途で、少ない労力と出費で高めのセキュリティを望むなら、まずはリモート元になる端末を限定して余計なモノを入れないこと、リモート先は制限アカウントにして余計なモノが見えない権限にすること、中継サーバはインバウンド通信だけ受け付けて（LAN内に対しても）アウトバウンド通信を制限しておくことが望ましいだろう（まーリモートログインを受け付ける時点で「全開放」に近い状態ではあるんだけど）。悩ましいのは、出先で物理的に大きなリモート元端末（ようするに出先のパソコン）を使いたい場合で、こればっかりはトレードオフを呑む以外になさそう（筆者としては、画面の小ささなりモバイル端末のデカさなりをガマンして、自分の管理下にない端末からのリモートログインは避けるのが賢明だと思う：もしどうしてもやるのなら、リモート先はサンドボックスの中にしておくべき）。VPNサーバは陥落もあり得る前提で運用し、LAN内の資源（というかVNCとsamba）へのアクセス情報は置かないようにする（少なくとも2回の突破が必要になるので、侵入の難度が大きく上がる：これを補佐する意味でも、モバイル端末で生体認証and/or自前パスフレーズを使うようにしておくと「ワンチャンスで侵入」できる経路を塞ぐことにつながる）。
二段階認証（ないし多段階認証）という括りは、セキュリティ上はほとんど意味を持たない。たとえば単純なパスワード認証を何度も繰り返すもの（同じパスワードで複数回認証する場合さえも含む）だって「多段階」ではある。問題はそこではなく、認証を行う要素（一般的には、知識＝Knowledge、所有とか所持とか＝Possession、生体とか固有とか＝BiometricとかinherenceとかUniqueとか、の3分類）と経路がどれだけ独立しているかという点である。ほかに、状況＝Contextによる制限（ログイン元アドレスを絞るのが代表例）や行動＝behaviorによるもの（ログイン失敗回数でロックするのが代表例）があるが、こちらは認証要素に用いるというよりは認証の試みを制限しておく手段になると考えた方が近いだろう（たとえば、いわゆるwell-knownパスワードを手当たり次第に送ってきたホストはしばらくの間デコイに対応させるとか、凝った対応もいろいろ可能なんだろうとは思うが、それをやって現実的なメリットがどれだけあるのかは不明：コストとしてDos攻撃への耐性が下がるケースもありそう）。
二経路認証（ないし多経路認証）の意義について確認しておきたい。たとえばパスフレーズ（知識）and秘密鍵ファイル（所有・所持）and指紋（生体）で3要素認証をしていたとしよう。これをもし1台のタブレット内だけでやっているとしたら、モバイル端末のrootを取られたときに（どうやっての部分は棚上げして可能性だけ考えると）3要素すべてを突破されてしまう（所有要素が「丸ごとコピー可能」であることも弱い）。いっぽうもし、パスフレーズの入力はタブレットで行い、指紋認証つきのハードウェアキーを併用するなら、もしタブレットのrootを奪われてもパスワード以外は盗まれないし、タブレットとハードウェアキーをセットで（物理的に）盗まれてもパスフレーズがバレるまでは耐えられる（生体要素としての指紋は（静電容量式で読み取るならダントツで手軽だが）非常に弱い部類で、タブレットに素手で触っているだけで偽造される可能性が高く、場合によっては指の写真からも偽物を作れるそうな）。
生体情報については同要素内で重複させる効果が一定程度はあろう（たとえば虹彩パターンと静脈パターンの両方を盗むのは、どちらか片方だけ盗むのより難度が高そうに思える：本人丸ごと誘拐するという強硬手段はあるが、そこまでやられたら複数人のand認証にするand/orあらかじめデコイのログイン先を用意しておくくらいしか対処がなく、カジュアル用途前提であれば現実的でない）が、所有情報については、どうせログインの際は全部の鍵が揃わなければならないので、特殊な場合（それこそ複数人によるand認証で、Aさんしか開けられない金庫とBさんしか開けられない金庫から別々のハードウェアキーを持ってくるとか：想像でしかないけど、おそらく核ミサイルの発射管理とかこんな感じなんじゃない？）にしか重複させる意味がない。
パスワード（やPINコードやパスフレーズ）は自分の頭で覚える限り知識情報に属するが、たとえば、長いランダムパスワードを紙に印刷して金庫に保管するような場合は所有情報（パスワードの紙とハードウェアキーが役割上同一）になるいっぽう、その金庫を開ける手段が暗証番号なりパスワードなりであれば根元のところでは知識情報だし、物理的な鍵と錠前を使うなら所有情報とみなせる。ワンタイムパスワードを特定の端末なりアカウントなりに送る方法も、結局は出口（SMS認証ならモバイル端末という所有要素、確認メールならメールログインに使っている要素）の認証要素に帰着する。またパスワードは「倍加」が可能な認証要素で、パスワードマネージャはその手段になってくれる（人間が覚えられる程度のパスフレーズから、実用上無制限長のランダムなパスワードを引き出せる）。
制限事項も確認しておきたい。生体認証はハードウェアのコスト（金銭的にも持ち運びの労力的にも）が高いのでモバイル機器のネイティブ機能を活用したいところなのだが、2025年1月現在、たいていの実装は本体の認証機能を流用するもので、端末ロックの認証（多くの場合、指紋orパターンorPINのうちひとつでも抜ければ突破できてしまう：とくにPIN漏れが危険）さえ通れば指紋情報の新規登録もできてしまう可能性が高く、本当に生体要素を組み込めているとは見なせないものが多い。ハードウェアキーについて、OpenSSHは8.2からFIDOに対応しているので、Yubikey（最大手であるスウェーデンYubico社）やSoloKey（オープンソースかつオープンハード）などの製品を利用できる（はず：筆者は試したことないけど）。
サーバサイドで生成するワンタイムパスワード（FreeBSDならoath-toolkitのportsがあるし、もちろんLinuxでも使えるが、Winホストだとどうやるのか筆者は知らない：Microsoft AuthenticatorとかGoogle Authenticatorとか、その辺を使うんだろうとは思う）については、紐付け先がSIMなら（物理的に盗むことはできるがコピーは困難なので）一定の効果はあるものの、劇的な違いはなさそうに思われる。2025年1月現在のモバイル機器は単体だと、カジュアルなコストで偽装のリスクなくデジタルコピーされない方法で「たしかにその端末である」ことを証明するのが難しいため、ここを何とかしたいならハードウェアキーを利用するのは妥当だろう（もちろんSIMはID情報を持っている（だから電話の発着信ができる）わけだし、いわゆるおサイフケータイ対応の機種ならFeliCaのチップも入っているはずだが、それらの資源を他の用途に流用するための手段に乏しい：SIMやFeliCaチップを除いたガワは単なるハコであることに注意）。
すでに触れたように、認証で求める要素数を増やすと何かの拍子に「所有者本人がログインできなくなる」リスクが高くなる（上で触れた生体要素だけでなく、長いパスフレーズを設定したものの忘れるとか、ハードウェアキーを紛失するとか破損させるとか、可能性としてはいくらでもある：金庫保管が優れている点として、最悪の場合金庫自体を破壊すれば中身は取り出せるという特徴があり、もちろん丸ごと盗まれて破壊されるリスクと表裏一体なのだが、ハードウェアなので大掛かりな準備がなければ破壊できない点が評価できる）。鍵が開けられない事態を回避するにはマスターパスワードのようなものを設定しておく（or認証にする）ことが必要で、マスターパスワードは（利便性を犠牲にして）厳重に管理する必要がある（十分長くランダムなパスワードによる認証は、鍵変更の周期など運用上の注意点はあるものの適切に扱えばパスワード自体が漏れない限り安全、というところを信頼できないならごくごく特殊な構成にせざるを得ないわけで、ここでは考慮しない）。念を入れるなら、動作原理が異なる複数のパスワード管理ソフトを入れて、パスワードを分割して保管しておくのがより安全だろう（もし片方に脆弱性があっても、パスワードの一部しか漏れない）。
2025年1月現在、これは大変難しい。いわゆるスマートフォンの類は、PINコード（ないし解除パターン）が漏れた状態で物理アクセスを許すと何でもやりたい放題にされてしまう（Yubikeyなどの製品もログインのところでは使えない：基本的には「ポータブルコンピューター未満」の機器なんだよねぇ、現状のスマートフォン）。またすでに触れたように、KeepassDXの指紋認証機能のようにスマートフォン本体の機能を使っている場合、指紋データを上書きされるとパスワードマネージャまで一気に攻略されてしまう。ここの弱さは十分認識しておくべきだが、端末の認証データベースに触れるということはrootキットでもゾンビbotでもトロイワームでも仕込み放題だということなので、本当に守るべきはもっと手前のライン（ログインorロック解除のところ）である。
タブレットなら、長いパスフレーズ（これは普通にできる）を使ったり、ハードウェアキー（Linuxならlibpam-u2fとか、WinだとYubico Login for Windowsで2要素ログインを実現できる模様）を必須にしたり、ディスク丸ごとの暗号化（Linuxだとdm-cryptとかLUKSとかeCryptfsとか、WinではBitLockerとか）を施したりと、手段がずっと豊富である。どちらが安全かといえばそりゃあタブレットに違いないのだが、やはりスマートフォンに比べればデカいのと、電話機としての使い勝手が絶望的に悪い。小型のスマートフォンを音声端末兼テザリング親として持ち、ポータブルコンピュータとしてはタブレットを使うというのがワークアラウンドのひとつなのだろうが、もうちょっとなんとかならんもんなのかという思いが拭えない。
FreeBSDでハードウェア認証するやり方は情報が乏しかったが、yubico-piv-tool pam_pkcs11 ccid pcsc-liteを入れて設定、/etc/pam.d/systemの記述を変更すればいいみたい（https://gist.github.com/daemonhorn/bdd77a7bc0ff5842e5a31d999b96e1f1：u2f-devdとかpam_u2fとかlibfido2とかlibu2f-hostとか）。ディスク暗号化もFreeBSDにはGELI(8)という非常に強力なフレームワークがあるのだが、使い方の情報があまり豊富でない（https://qiita.com/nanorkyo/items/a818af9f9bc0447c369c：https://man.freebsd.org/cgi/man.cgi?query=geli&sektion=8&n=1）。またRAIDを応用すると複数のストレージ（本体ディスク＋USBメモリとか）が揃わないとアクセスできないファイル（ないしボリューム）を作成できる。まああんまりモバイル向けなシステムではないし、強力なだけに扱いが手ごわい傾向も強く出るので、Windowsが嫌ならLunuxを何か見繕った方が手軽かなという気はする（サーバはFreeBSDで建てたいけど、モバイル用には）。
ともあれ、タブレット（やノートパソコン）を持ち歩きたくないのならスマートフォンでなんとかせざるを得ないわけで、ここは物理で守る（他人に触れさせない）ことと、長いPINコードを短い周期で更新するくらいしかやりようがない。しかしスマートフォンというのはカジュアルに使う機会の方が圧倒的に多いわけで、そちらを犠牲にするくらいならタブレットの方が（端末としてのハードウェア性能、というか画面のデカさと入力デバイスの豊富さで優位性があるわけだから）いいんじゃないのとも思える（結局は個人の選択なんだけど）。んー、やっすい中古のWinタブ買ってきてLinuxでも入れるのがいいのかなぁ（電池が元気なのを見極める方法が思いつかないけど：さらにモバイルバッテリーをプラスじゃやってられんよねぇ）。
自宅にパソコン（FreeBSDに限定せずWindowsなりLinuxなりでも：以下ホストと称する）、出先にスマートフォンかタブレット（以下モバイルと称する）で、出先から自宅にリモートアクセスする状況を考えてみたい。ログイン自体を提供するのはVNCかRDP（なぜか知らないが、2025年1月にざっと調べてみた限り、GnomeユーザーはVNC、KDEユーザーはRDPの利用報告が多かった）で、トンネル通信を提供するのがVPNかSSH、というのが無難な組み合わせだろう。VNC vs RDPだとVNCの方がモバイルでの処理が軽くログイン処理も手軽、RDPは設計上（実装が追い付いているかどうかはともかく）高性能でWindowsホストでもデーモンのアップデートをシステム任せにできる。VPN vs SSHだと、VPNは軽くて拡張性が高く、SSHは公開鍵やハードウェアキーを利用する敷居が低い。用途や状況によって、どの組み合わせもあり得るところだろう。
2レイヤでの暗号化にはそれなりの意義があるように思える。たとえば2014年にOpenSSLのハートブリード脆弱性（Heartbleed：エンバグは2011年）が指摘されたように、またたとえば2006年に修正されたregreSSHionが2020年に再発し2024年まで潜伏していたように、どんなシステムにも穴ができる瞬間は必ずある。またサーバ丸ごとの乗っ取りに備えるには、たとえば、SSHマスター＞VPNサーバ＞SSHスレーブのような形で、レイヤーごとのエンドを揃えないことも有効。この場合、もしVPNサーバが陥落してrootまで取られたとしても、VPNサーバ～SSHスレーブ間の設定さえ適切なら、SSH通信の安全までは直ちに脅かされない。またもしSSHにゼロデイ脆弱性があったとしても、VPNが守ってくれる。パフォーマンス上の問題さえないなら、常に少なくとも2レイヤ確保しておきたい（筆者は、VNCやRDPの認証をSSHやSSLほどは信頼していないので、ないよりマシで0.5カウントくらいに考えている：ただ、ないよりは確実にマシなので、1レイヤで済ませるよりは1.5レイヤの方がずっとよい）。しかしこれも、結局はリモート元のホストに全部の鍵を揃えないとアクセスできないわけだから、3レイヤとか4レイヤにするメリットがあるのかと考えると、カジュアルユースではほぼないだろうと思う。なお2025年2月現在、SSH・IPsec（オプション：RFC2412）・TLS（v1.3）は、前方秘匿性＝Perfect Forward Secrecy＝PFS（公開鍵認証と同時に、通信する2者間で一時的な（通常はワンタイムの）鍵交換を行い、たとえ秘密鍵が漏れたとしても個々の一時鍵で粘れるようにした仕組み：安全な鍵交換のために、ディフィー・ヘルマン鍵共有＝Diffie–Hellman key exchange＝DHとか楕円曲線ディフィー・ヘルマン鍵共有＝Elliptic curve Diffie–Hellman key exchange＝ECDHといった実装がある）に対応している。
知識＋所有＋生体で三要素認証にしようとすると、まず生体認証のところはモバイルのネイティブ機能に頼ることになろう（声紋認証や通常カメラを使った静脈認証なんかも研究されてはいるが、2025年1月現在は十分普及していない：どうなんだろねぇ、偽造にも弱そうだけど）。実用上はここがとても弱く、正直なところ、現状のスマートフォン・タブレットの生体認証機能は取って付けただけのお飾りに近い。では所有要素でなんとかならないかというのは自然な考えだが、上で触れたように、スマートフォンの場合本体に触られただけで相当に弱い。知らないところで他人に触られていてもひとまず大丈夫というレベルを望むなら、タブレットを使ってそれなりの対策を講じておく必要がある。ただこの場合、リモート元を「本当にdumbな状態」に保てる（リモートデスクトップを飛ばす以外の用途に対応する必要性をなくせる）のと、デカい画面を使える（操作対象がパソコンの画面なら、これはけっこう嬉しい）という副作用があるので、不便なことばかりではない。最後に知識要素。これは雑談メモでいつか触れたように、パスワード管理アプリで入力する長いランダムパスワードの前and/or途中and/or後に手打ちのパスフレーズを追加してやるのが手軽。万が一（複数使っている場合すべての）パスワードデータベースを盗まれてかつ読解されたとしても、時間は稼げるはず（たとえばモバイル機器を物理で奪われたときに被害の拡大を防げる可能性がある：知らない間に触ってログインして戻されたら無力だけど）。
結局のところ、生体要素はハードウェアの都合からモバイル機器のネイティブ機能を使わざるを得ず、知識要素は普通に自前で覚えるパスフレーズとなると、あとは所有要素をハードウェアキーにするのかファイルの所有（など）で代用してお茶を濁すのか、リモート元のモバイルをスマートフォンにするのかタブレットorノートPCにするのか、という選択に落ち着きそうである。ハードウェアキーは複製の困難さで一定のメリットがあるものの、利便性で劣るのは間違いないし、モバイル機器とセットで盗まれると一気に穴が広がる（スマートフォンであればモバイル機器本体と一体で考えて、その端末である証明に使う方がスジがよさそう）。スマートフォンvsタブレットは本当に悩ましいが・・・突き詰めたらやはりタブレットの方が安全度は高そう。いっぽう指紋認証はそれ自体が低強度なので、モバイル端末を盗まれたときの最後の砦は自前で覚えるパスフレーズの長さと複雑さにかかっている（結局ここで踏ん張るしかないんじゃないかというのが、2025年1月現在の筆者の結論）。繰り返しになるが、リモート元が陥落したらホストにトロイの木馬を仕込まれるのを（実際上どれだけ困難かは別にして仕組み上は）防げないため、モバイルにバックドアを仕込まれてしまった状況は想定する意義が小さく、またそれが可能な状況に置いてしまった時点でリモートシステム全体を破棄して再構築する必要がある（まあ自宅に泥棒が入ってパソコン丸ごと持って行かれるリスクと同程度まで守ればいいわけだから、極限まで頑張ることもないわけだけど）。
もどる / 自滅への道トップページへ