- ブラウザURL入力
- DNS名前→IP
- ルータ経路選択
- ロードバランサ振り分け
- Nginx受け口今ここ
- アプリ処理今ここ
- DB保存
第13週でアプリとカーネルの境界を、第27週でブラウザからアプリまでの段を見ました。今回は、それらの線のどちら側を信じるかという観点で引き直します。
まず結論
「信頼境界」という語は現場で広く使われますが、本教材で確認した範囲では、NIST の用語集にも RFC 4949 にも見出し語として見つかりませんでした。**語が広く使われていることと、一次ソースの定義があることは別です。**
代わりに立てられる確かな足場は RFC 3552 (BCP 72) §3 の脅威モデルです。**自分の端末の内側は信頼するが、通信路は信頼しない**という線引きが明文で置かれています。この線から外を「他人の入力」として扱います。
RFC 3552 §3 が置いている前提は、攻撃者と通信路の関係についてどれに近いでしょうか。
当てることが目的ではありません。外した予測ほど記憶に残るので、直感で選んでください。
まず、足場がどこにあるかを確かめる
この回の主題は「どこから先が他人の入力か」です。現場ではこれを信頼境界と呼びます。
ところが、この語の定義を一次ソースで裏づけようとして、見つけられませんでした。NIST の用語集は個別URLがいずれも404、T索引にも現れず、RFC 4949(Internet Security Glossary)の全文検索でもヒットは0件でした。
ここで大事なのは、結論を急がないことです。言えるのは次の一点だけです。
確認できなかった。それは「誤りだ」とも「存在しない」とも違う。
信頼境界という考え方は現場で有効に働いており、否定する理由はありません。ただ本教材では、一次ソースの定義としては引かないという扱いにします。これは第3期の limit_req と同じ形です。nginx 公式が "leaky bucket" と自称しているところまでは書けても、nginx がそれを実装していると裏づける一次ソースまでは辿り着けませんでした(語そのものは RFC 3290 付録Aなどに記述があります)。
RFC 3552 §3 は、通信の相手となる端末(end-system)そのものについてはどう仮定していますか。
確かな足場 — RFC 3552 §3 の脅威モデル
定義の代わりに、線の引き方そのものを明文で置いている文書があります。RFC 3552 (BCP 72) の §3 です。
まず、脅威モデルとは何かが定義されています。
A THREAT MODEL describes the capabilities that an attacker is assumed to be able to deploy against a resource.
そのうえで、信じる側と信じない側が別々に宣言されます。端末については——
In general, we assume that the end-systems engaging in a protocol exchange have not themselves been compromised.
通信路については——
By contrast, we assume that the attacker has nearly complete control of the communications channel over which the end-systems communicate.
対象 扱い 根拠となる記述端末(end-system) 信頼する have not themselves been compromised通信路 信頼しない nearly complete control of the channel
**線は対称ではありません。**片側を信頼し、もう片側を信頼しない、と明示的に決めています。この非対称さこそが「境界」の実体です。
信頼しない、とはどこまでを含むのか
「通信路を信頼しない」を読まれるかもしれないとだけ理解すると、この文書が置いている前提より弱く見積もることになります。同じ段落は能力をこう並べています。
This means that the attacker can read any PDU (Protocol Data Unit) on the network and undetectably remove, change, or inject forged packets onto the wire. This includes being able to generate packets that appear to be from a trusted machine.
読むだけでなく、検知されずに消す・変える・偽物を混ぜる、さらに信頼された機器から来たように見せるところまで含まれます。
だから結論はこうなります。
Thus, even if the end-system with which you wish to communicate is itself secure, the Internet environment provides no assurance that packets which claim to be from that system in fact are.
相手が安全であることと、届いた入力が本当にその相手から来たことは別の話です。前者を確かめても、後者は保証されません。
「相手のサーバが安全なら、そのサーバから来たと書いてあるパケットは信用してよい」。RFC 3552 §3 の記述に照らすとどう評価できますか。
システムコールの特権境界(第13週)
CPUの特権レベルで、アプリはユーザーモードという制限された状態で動きます。ハードウェアへの直接アクセスや他プロセスのメモリ参照は禁止され、必要ならカーネルに依頼します。依頼の形にすることで、カーネル側に正当性を確認する余地が生まれます。信頼する側(カーネル)と、検査される側(アプリからの依頼)が分かれています。
内側 カーネル(全権限を持つ)外側 アプリ(ユーザーモードで制限される)越える手段 システムコール = 検査の置き場所
インターネットの脅威モデル(RFC 3552 §3)
端末そのものは侵害されていないと仮定する一方、通信路については攻撃者がほぼ完全に制御しうると仮定します。したがって通信路から届いた値は、そのまま信じる対象ではなく、検査の対象になります。ここでも信頼する側と検査される側が分かれています。
内側 端末(compromised でないと仮定)外側 通信路(攻撃者がほぼ完全に制御しうる)越える箇所 受け取った入力 = 検査の置き場所
CPUの特権レベルと、インターネットの脅威モデル。層もまったく違いますが、共通している構造は何でしょうか。
どちらも「何を守るか」より先に決めていることがあります。
この章のまとめ
- 「信頼境界」の一次ソース定義は、本教材では確認できなかった。 概念の否定ではなく、定義としては引かないという扱いにする。
- 近い語(boundary)の定義で埋めない。別語の定義の流用は誤帰属の作られ方そのもの。
- 確かな足場は RFC 3552 (BCP 72) §3。端末は侵害されていないと仮定し、通信路は攻撃者がほぼ完全に制御しうると仮定する。
- 「信頼しない」には、読む・検知されずに消す/変える/偽造を注入する・信頼された機器を騙るまでが含まれる。
- 相手が安全でも、そう名乗るパケットが本当にそこから来た保証は無い。
- 第13週の特権境界と同じく、先に線を引くことで検査の置き場所が決まる。
自分の現場で確かめる
読んだだけでは身につきません。手元の環境で実際に見てみてください。
理解度チェック
読んだ直後は「分かった」と感じやすいものです。実際に解いて確かめてください。
「信頼境界(trust boundary)は NIST が定義した標準用語である」という説明の評価として、本教材の調査結果に最も忠実なものはどれですか。
用語集(3語)
- 脅威モデル (threat model)
- RFC 3552 §3 の定義は “A THREAT MODEL describes the capabilities that an attacker is assumed to be able to deploy against a resource.”。**攻撃者に何ができると仮定するか**を先に決めた記述であって、実際に起きた事件の一覧ではない。
- インターネットの脅威モデルにおける前提
- 端末そのものは侵害されていないと仮定し、通信路については攻撃者がほぼ完全に制御しうると仮定する。読み取り、検知されない削除・改変、偽造パケットの注入、信頼された機器を騙るパケットの生成までを含む(RFC 3552 §3)。
- 「他人の入力」
- 本教材では、上記の線の外側から来た値を指す語として使う。規格用語ではない。どこに線を引いたかが決まって初めて、何が「他人の入力」かが決まる。