要約

  • RFC 1457は、セキュリティラベルをデータの属性として捉え、書式だけでなくデータとの結合、意味体系、変換、ローカルポリシーまで成立して初めて処理に使えると整理した。
  • ラベルの配置層は制御可能な範囲を決めた。ルーティング情報はルータが読める層に、プロセス配送を制御する情報は配送前に、アプリケーション固有情報は他のアプリを巻き込まない層に必要だった。
  • ラベルの認識は暗号化、認証、認可、配送結果を証明しない。それぞれ別の主体と記録を要する後続事実である。

置き場所は権限の設計だった

Russell HousleyによるRFC 1457は1993年5月にInformational文書として公開された。インターネット全体で使う一つの分類制度を定めたのではない。プロトコル設計者に対し、そもそもラベルが必要か、必要ならどの判断に使うか、その判断をする装置がどの層まで見られるかを問う枠組みだった。

物理層には明示ラベルを書き込むプロトコル制御領域がない。ただし、特定の物理ポートを通るデータすべてに一つの属性を暗黙に与えることはできる。データリンク層のラベルならブリッジが中継判断に使える。ネットワーク層のIPオプションならルータが経路選択や破棄に使え、実装によってはユーザープロセスへの配送前にも参照できる。

上へ行くと表現力は増える。トランスポート接続に豊かな属性を結びつけることも、アプリケーションだけが必要とする処理条件をメッセージに含めることもできる。しかし、中間システムは通常そこまで処理しない。アプリケーションがラベルを読んだ時点で、システムからそのアプリへの配送がすでに終わっていれば、ラベルはその境界をさかのぼって守れない。

だから答えは「低いほど安全」ではない。低すぎれば、全ルータやブリッジが複雑な意味を解析し、限られたヘッダ領域を消費し、関係のない政策情報まで見る。高すぎれば、必要な制御点を通過した後にしか届かない。判断する主体に、判断の直前、必要な部分だけを渡すことが設計原則だった。

ラベルは本文ではなく属性である

RFC 1457はラベルをデータ本文から区別した。ラベルは、収集、処理、転送、保存、検索、配布などの取扱条件を示すデータ属性である。データが移動すれば属性も同行しなければならない。中間システムがラベルを変更するなら、それ自体が権限を要する取扱行為になる。

ここで必要なのは単なる同時存在ではない。ラベルがそのデータに結びついているという証拠である。文書は一般的な手段として完全性保護を挙げ、それを提供するプロトコルがなければ別の仕組みで結合を維持するよう求めた。正しいラベルと別の内容が並んで届けば、形式検査は通っても指示は虚偽になる。

カプセル化、断片化、ゲートウェイ変換、再組立てはすべて結合点を増やす。監査者は終点のフィールドだけでなく、それぞれの境界で属性がどの内容に付いていたかを追わなければならない。ビットが保存されたというハッシュと、意味の対象が保存されたという証拠は同じではない。

完全性と機密性は一列に並ばない

文書は完全性ラベルと機密性を扱う感度ラベルも分けた。完全性ラベルは、データをどこまで信頼できるか、改変や破壊からどの程度守るべきかを示す。感度ラベルは、開示による損害と、それを防ぐための取扱条件を示す。

ネットワーク上の取扱いによってデータへの信頼が下がることはある。一方、転送されたからといって開示損害が小さくなるわけではない。別の情報と組み合わされれば損害が大きくなることもある。高い完全性は公開可能性を意味せず、低い完全性も開示自由を意味しない。

暗号も別記録である。暗号方式や完全性機構は転送中の内容とラベルの結合を助けうるが、ラベルの意味体系や復号後の受領者を定義しない。ラベル、暗号状態、主体認証、アクセス許可、観測結果を一つの「セキュア」に畳むと、どこで主張が切れたか分からなくなる。

同じ形でも同じ意味とは限らない

終端のオペレーティングシステムやデータ管理系は、通信プロトコルとは異なるローカル形式でラベルを保持できる。受信側はネットワーク表現をローカル表現へ、意味を失わず変換しなければならない。その後で初めて、信頼された計算基盤が対象プロセスの権限を判定できる。

解析、変換、認可、配送は別々の段階である。解析成功は形を理解しただけだ。変換成功は対応するローカル項目が得られたことを示すにすぎない。認可はその解釈の下で特定主体への配送を許す。実行は実際に配送または拒否する。

二つの組織が同じ数値を異なる義務に使うことも、同じ義務を異なる分類で表すこともある。送り側の細かい区画が受け側に存在しなければ、変換は複数の制限を一つへ潰すかもしれない。出力は文法的に正しくても、受領可能な範囲が静かに広がる。

RFC 1457は、共通の明示書式と登録された意味を用い、可能なら変換を避ける方向を示した。解析器を共通化しながら複数の政策を区別できる。ただし、登録は世界共通の命令権ではない。どの意味体系を参照するかを明らかにするだけで、組織間の同意や受信側のローカル判断を代行しない。

ゲートウェイは翻訳者であり制御者でもある

書式を統一できない場合、アプリケーションゲートウェイが変換を担いうる。インターネットやOSIの中間層には、あらゆる終端ラベルを自動的に変換する一般機能がなかった。そこでゲートウェイは、原義を読み、対応を選び、新しい属性を発行する。

この装置は単なる転送点ではない。どの制限を同等とみなすか、何を表現不能とするかを決める権限点である。ほかの部分では互換性のあるプロトコルでも、この変換のために運用が複雑になる。RFC 1457が共通形式を望んだ理由には、性能だけでなく、中央翻訳者への依存を減らすことも含まれていた。

変換表には方向と版がある。AからBへ安全に写せても、BからAへ元の区別を復元できるとは限らない。一方だけが更新されれば同じ入力が異なる出力になる。したがって「ラベル変換済み」という記録だけでは不十分で、どの定義と版を使ったかが必要になる。

明示か暗黙か、パケットごとか接続ごとか

RFC 1457は二つの軸を交差させた。第一は明示と暗黙である。明示ラベルはプロトコル制御情報のビットとして現れる。暗黙ラベルは物理ポート、送信元インターフェース、接続、暗号鍵など別の属性から推定される。

暗黙方式はヘッダ領域を節約する。単一レベルの閉域では、あるポートから入るすべてのデータに一つの属性を与える設計が自然な場合もある。しかし証拠はパケット外へ移る。後から判断を再現するには、その時点の配線、ポート設定、鍵対応、接続状態が必要になる。

第二はコネクションレスとコネクション指向である。前者は各プロトコルデータ単位にラベルを置き、パケットごとの判断を可能にする代わりに制御領域を繰り返し消費する。後者は接続確立時に属性を定め、後続データに継承させる。効率は上がるが、状態の正しさへの依存も増す。

異なる感度の処理を同じ接続へ多重化する、政策変更後も古い接続を残す、確立時の記録を失う、といった障害ではパケット自体に異常がない。文法検査だけでは継承の誤りを検出できない。フィールドがないことも、アーキテクチャが帯域外に属性を置いたなら、ラベルがない証拠にはならない。

RFC 1108が示したローカル設定

RFC 1108は、米国国防総省の文脈でIPv4の具体的な基本・拡張セキュリティオプションを定義した。基本オプションは分類レベルと保護機関のフラグを持つ。RFC 1457から見れば、ネットワーク層の明示的なコネクションレスラベルの例である。

それでも、パケットのビットだけでは処理は決まらなかった。ポートごとの設定が、送受信で明示オプションを要求するか、ラベルのないデータグラムを受け入れるか、受信ポートに基づきどの暗黙ラベルを与えるかを決めた。書式とローカル政策が合わさって初めて動作になる。

RFC 1457はこの事例を一般化したが、特定組織の分類体系をインターネット全体のものにはしなかった。またRFC 1455とも役割が違う。観測されにくい物理経路への希望はデータ分類ではなく、分類は経路、暗号化、配送許可の証明ではない。

後続文書が明示した意味の住所

2009年のRFC 5570はCALIPSOにおいて、解釈ドメインを明示した。単独の「SECRET」というレベルには実行可能な意味がない。どの組織のレベルと区画の体系かを知る必要がある。ドメイン識別子は政策へのポインタであり、政策そのものでも自動執行でもない。

RFC 5570は適用範囲も限定した。信頼された閉域の多段階セキュリティ環境向けで、世界の公開インターネットには不適切だとした。歴史的な比較から一般導入を推奨することはできない。

RFC 4301のIPsecは別の対比を与える。パケットのセレクタとローカルポリシーが照合され、保護、通過、破棄が選ばれる。セキュリティアソシエーションが具体的な暗号処理状態を持つ。ラベルは入力になりうるが、アソシエーションの存在、暗号の実行、相手の認証、受信許可を証明しない。

メタデータは必要な取扱いを表す。存在するだけでは取扱いを実行しない。これがRFC 1457から残る最も厳密な境界である。