セキュリティ

非公式翻訳 (Unofficial translation). これはデータパッケージスタンダードの有志による日本語訳です。正典は英語原典 datapackage.org 。未訳の箇所は英語の原文を参照してください。

Authors	Johannes Jander, Data Package Working Group

データパッケージおよびデータリソースをめぐるセキュリティ上の考慮事項。

言語

本書におけるキーワード MUST、MUST NOT、REQUIRED、SHALL、SHALL NOT、SHOULD、SHOULD NOT、RECOMMENDED、MAY、OPTIONAL は、RFC 2119 に記述されたとおりに解釈されるものとする。

利用者の視点

データパッケージは、作成者がペイロードデータ(リソース)を JSON オブジェクト/配列として、あるいはポインタを介して指定できるコンテナ形式である。ポインタには 2 つの形式がある。

ローカルファイルシステム参照。これらは POSIX の命名規則に従い、パッケージディスクリプタ(descriptor)ファイル(「datapackage.json」)からの相対パスでなければならない。絶対パスは、データ持ち出し(exfiltration)攻撃の入口となるため許可されない。また、ユーザーのコンピュータのファイルシステム構成を通常は知り得ないことを考えると、絶対パスが役立つことはまれである
リモートリソースへのポインタとしての URL。これらは、統計局のようなサイトからデータセットを読み込んでデータパッケージの基礎とすることを意図している。許可されるのは HTTP/HTTPS の URL のみであり、ライブラリの保守者は file-URL のようなそれ以外のものを除外しなければならない

どちらの形式も、ユーザーのコンピュータやネットワークを攻撃するために利用され得るセキュリティホールの入口となり得る。したがって、第三者のソースからデータパッケージを受け入れる場合は、自身のマシンで許可するリソースポインタの種類を制限することが強く推奨される (STRONGLY recommended)。

あらゆる種類のリソースポインタを許可することが推奨されるのは、信頼された環境(例:データパッケージ開発中の自分自身のコンピュータ)に限られる。それ以外のすべての環境では、さまざまな攻撃シナリオを念頭に置き、危険となり得るリソースポインタの種類を除外しなければならない (MUST)

危険なディスクリプタ/リソースポインタの組み合わせ

表の読み方:「datapackage.json」ファイルが左側のいずれかのソースに由来する場合、上部の形式のリソースを次のように扱うべきである。

赤:許可しない
黄:危険となり得る
緑:安全に使用できる

Security Matrix

ディスクリプタのソースが URL の場合

ディスクリプタが URL を介して読み込まれ、その URL が指すサーバーが完全には信頼されていない場合、次のリソースポインタを含むデータパッケージを許可すべきでない (SHOULD NOT)。

URL。issue #650 で説明されているとおり、データパッケージの作成者が細工した URL は、あなたのネットワーク構成を探る「鍵穴(keyhole)」攻撃に利用され得る。
絶対ファイルシステム参照。絶対パスは、システムファイル(例:Unix 系システムの /etc/passwd)を持ち出すために利用され得る。相対パスはディスクリプタの URL を基準とする URL に変換されるため、ローカルファイルシステムからデータを読み込むことはなく、したがって安全である。

URL ベースのリソースポインタはさらに、ユーザーのシステムやリソースデータをホストするサービスに対するサービス妨害(DoS)攻撃にも利用され得る。比較的小さなデータパッケージであっても、それぞれがどこかにホストされた非常に大きな CSV ファイルを指し得る数千ものリソース URL を保持できる。データパッケージ処理ライブラリはそれらの CSV ファイルをすべて読み込むため、ユーザーのコンピュータが過負荷に陥る可能性がある。攻撃者がこのような悪意あるデータパッケージを拡散できれば、ホスティングサービスのリソースを枯渇させ得る。

ディスクリプタのソースがローカル相対パスの場合

ディスクリプタがローカル相対パスを介して読み込まれ、データパッケージのソースが完全には信頼されていない場合、次のリソースポインタを含むデータパッケージを許可すべきでない (SHOULD NOT)。

URL。issue #650 で説明されているとおり、データパッケージの作成者が細工した URL は、あなたのネットワーク構成を探る「鍵穴(keyhole)」攻撃に利用され得る。
絶対ファイルシステム参照。絶対パスは、システムファイル(例:Unix 系システムの /etc/passwd)を持ち出すために利用され得る。相対パスはディスクリプタのファイルシステム参照を基準とするパスに変換されるため、無害とみなされる。

データパッケージの作成者がそれを解析するコンピュータ/サーバーと同じローカルネットワーク上にいる限り、URL を介してリソースを参照することは安全とみなされる。作成者は悪意あるデータパッケージを細工するのと同様に、自分自身のワークステーションからネットワークをマッピングすることもできるからである。上記の表では、このケースは黄でコード化されている。

データパッケージの解析が、同一 LAN 上の他サブネットのコンピュータに、あるいはインターネットに対してまで開かれたサービスの一部である場合、URL ベースのリソースポインタを含むデータパッケージを受け入れることが安全であることは決してない。

ディスクリプタのソースがローカル相対パスの場合

リソースに絶対ファイルパスを受け入れることが安全であることは決してないが、ディスクリプタファイルに絶対ファイルパスを受け入れることは全く問題なく安全である。ディスクリプタがローカル絶対パスを介して読み込まれ、データパッケージのソースが完全には信頼されていない場合、次のリソースポインタを含むデータパッケージを許可すべきでない (SHOULD NOT)。

URL。issue #650 で説明されているとおり、データパッケージの作成者が細工した URL は、あなたのネットワーク構成を探る「鍵穴(keyhole)」攻撃に利用され得る。
絶対ファイルシステム参照。絶対パスは、システムファイル(例:Unix 系システムの /etc/passwd)を持ち出すために利用され得る。相対パスはディスクリプタのファイルシステム参照を基準とするパスに変換されるため、無害とみなされる。

ディスクリプタのソースが JSON オブジェクトの場合

ディスクリプタがファイルから読み込まれるのではなくメモリ内で作成され、データパッケージのソースが完全には信頼されていない場合、次のリソースポインタを含むデータパッケージを許可すべきでない (SHOULD NOT)。

URL。issue #650 で説明されているとおり、データパッケージの作成者が細工した URL は、あなたのネットワーク構成を探る「鍵穴(keyhole)」攻撃に利用され得る。
ファイルシステム参照(相対・絶対を問わず)。絶対パスは、システムファイル(例:Unix 系システムの /etc/passwd)を持ち出すために利用され得る。相対パスは解析ソフトウェアの作業ディレクトリを基準として構築されるため、設定ファイルを推測して持ち出すために利用され得る。一方で、データパッケージの作成時に、相対パスがサブディレクトリ内に限定されているのであれば、相対パスを使用することは安全である。

ディスクリプタのソースが自作の JSON オブジェクトの場合

ディスクリプタがファイルから読み込まれるのでも第三者のアプリケーションを介して作成されるのでもなく、あなた自身のソフトウェアによって作成される場合、一般にあなたは自分の行っていることを理解しているとみなされ、したがって URL やファイルからリソースを読み込むことは安全とみなされる。それでも、念のため絶対パスを使用すべきでなく (SHOULD NOT)、実装ライブラリはそれらを除外すべきである。

実装者の視点

2 種類のリソースポインタは、完全に安全であることを保証することが決してできない。

絶対ファイルシステム参照。絶対パスは、システムファイル(例:Unix 系システムの /etc/passwd)を持ち出すために利用され得る。実装においては、絶対ローカルパスに遭遇した場合にエラーを発生させるか、ディスクリプタのパスを基準とする相対パスへ変換すべきである (SHOULD)。
URL。issue #650 で説明されているとおり、データパッケージの作成者が細工した URL は、ユーザーのネットワーク構成を探る「鍵穴(keyhole)」攻撃に利用され得る。この攻撃をユーザーが緩和できる手段を用意するかどうかは、ライブラリの作成者に委ねられる。

URL はデータパッケージの根幹をなすものであるため、その使用を完全に禁止することは賢明でない。しかし、実装が URL ベースのリソースを読み込むのを停止させるセキュリティ設定を用意すべきである。これは次のように実現できる。

設定スイッチ(insecure/default)を介して、ライブラリ実装の利用者が絶対ファイルパスおよび URL ベースのリソースポインタを許可または不許可にできるようにする
いかなるポインタベースのリソースを読み込む 前にも インターセプタとして適用される、差し替え可能(pluggable)なセキュリティフィルタを介する。このような方式を採用する場合は、URL ベースのリソースを不許可にするフィルタと、すべてのリソースの読み込みを許可するセキュアでないフィルタのデフォルト実装を提供すべきである (SHOULD)。

セキュリティフィルタ

すべての URL ベースのリソースを不許可にするのが過度に厳しく、すべてを許可するのがセキュアでなさすぎる場合は、よりきめ細かなフィルタを実装すべきである。こうしたきめ細かなセキュリティフィルタは、ブラックリストフィルタまたはホワイトリストフィルタのいずれかとして実装できる。ブラックリストフィルタは原則としてすべての URL を許可し一部を制限するのに対し、ホワイトリストフィルタはデフォルトですべてを拒否し、許可された URL の限定的なリストを持つ。

ブラックリストフィルタは、最も基本的な実装では、192.168.x.x の範囲や 10.100.x.x の範囲のような非ルーティング IP アドレスをすべて不許可にする必要がある。これによりユーザーの内部ネットワークに対するマッピング攻撃を鈍らせることができるが、一つの見落としでもネットワークセキュリティを危険にさらし得るため、十分に練り上げる必要がある

ホワイトリストフィルタは、指定された一覧のドメインからのみリソースの読み込みを許可するため、はるかにセキュアであるが、用途によっては制限が強すぎることもある。