フィールドレベル・センシティビティの極意：階層型DBMSにおける「見せるべきデータ」の厳格な制御
こんにちは。チーフアーキテクトの私だ。
今日のコードレビュー、あるいは基本設計レビューで、また「とりあえずセグメント全体をアプリケーションに渡す設計」を見かけた。そろそろ目を覚まそうか。
現代のリレーショナルデータベース（RDB）やNoSQLの感覚で階層型DBMS（IBM IMSなど）を触ると、痛い目を見ることになる。RDBの「列レベルのセキュリティ（Column-Level Security）」や「ビュー（View）」に相当する機能として、階層型DBMSには「フィールドレベル・センシティビティ（Field-Level Sensitivity）」という強力な武器が用意されている。
今日のテーマはこれだ。単なる機能紹介ではない。実務の現場で「なぜこれが必要なのか」「どう設計し、どうパフォーマンスを最適化すべきか」を、私の経験則を交えてロジカルかつシャープに伝授しよう。
—
1. 階層型DBMSにおけるセキュリティのパラダイムシフト
RDBであれば、`GRANT SELECT (col1, col2) ON table TO user` と書けば済む話だ。しかし、ポインタチェーンと物理的親子関係でガチガチに固められた階層型DBMSの世界では、データ構造の隠蔽は「ストレージアクセス層とアプリケーションのインターフェース設計」そのものに直結する。
なぜフィールドレベル・センシティビティが必要なのか？
1. 極限のデータ最小化原則（Need-to-Know）
例えば、顧客セグメント（`CUSTOMER`）の中に、氏名、住所、連絡先といった基本情報と並び、「信用格付けスコア」や「内部機密ランク」といった、一般のカスタマーセンター担当者に見せてはならないフィールドが同居しているケースを想像してほしい。
セグメントごとアクセス権を削ると、アプリ側が成り立たなくなる。かといってセグメントを物理分割すると、ポインタのオーバヘッドとI/Oコストが跳ね上がる。ここでフィールドレベル・センシティビティの出番だ。
2. PCB（Program Communication Block）による関心の分離
階層型DBMSでは、アプリケーションはPCBを介してデータにアクセスする。このPCBの定義（SSB: Sensitive Segments Block）を調整することで、同一の物理セグメントでありながら、プログラムごとに「見えるフィールド」と「見えないフィールド」を完全に動的に切り替えることができるのだ。
—
2. スキーマ定義とセンシティビティの設定（実務コード例）
百聞は一見に如かずだ。DBD（Database Description）とPSB（Program Specification Block）の定義を見てみよう。ここでは、IMS DBを念頭に置いた実務的な構成を示す。
① DBD定義（物理構造）
まず、物理的なセグメント構造を定義する。`CUSTOMER`セグメントの中に、公開用フィールドと機密フィールドが混在している状態だ。
- DBD Definition: 顧客マスター物理構造
DBD NAME=CUSTDBD,ACCESS=HDAM,RMNAME=(DFSHDC40,100,500)
SEGM NAME=CUSTOMER,PARENT=0,BYTES=250
FIELD NAME=(CUSTID,SEQ,U),START=1,BYTES=10,TYPE=C
FIELD NAME=CUSTNAME,START=11,BYTES=30,TYPE=C 公開
FIELD NAME=CUSTADDR,START=41,BYTES=100,TYPE=C 公開
FIELD NAME=CREDITLV,START=141,BYTES=5,TYPE=Z 【機密】信用ランク
FIELD NAME=INTERNALMK,START=146,BYTES=105,TYPE=C 【機密】内部メモ
FINISH
END
② PSB定義（フィールドレベル・センシティビティの適用）
次に、一般参照用のアプリケーションに向けたPSBを定義する。ここで `SENFLD`（Sensitive Field）マクロを使い、アプリケーションに見せるフィールドを明示的に指定、または隠蔽する。
- PSB Definition: 一般照会アプリケーション用 (機密フィールドを隠す)
PSBGEN LANG=COBOL,CMPILER=YES,PSBNAME=CUSTINQ
PCB TYPE=DB,DBDNAME=CUSTDBD,PROCOPT=G
SENSEG NAME=CUSTOMER,PARENT=0
- 必要なフィールドのみをマッピング（順番の入れ替えやオフセット調整も可能）
SENFLD NAME=CUSTID,START=1,REPL=YES
SENFLD NAME=CUSTNAME,START=11,REPL=YES
SENFLD NAME=CUSTADDR,START=41,REPL=YES
- ※ CREDITLV と INTERNALMK は定義されていないため、
- アプリケーションのワーキングストレージには一切ロードされない。
PSBGEN FINISH
END
> architect’s Note:
> 見てお分かりの通り、`CREDITLV` と `INTERNALMK` はこのPSBを使うアプリケーションからは「存在しないもの」として扱われる。バッファプール上からアプリケーションの領域にデータを転送する際、DBMSのランタイムが自動的にマスキング（というか、切り捨て・パディング）を行う。アプリケーションのメモリダンプを取られても、機密データが露出するリスクをゼロにできるのだ。
—
3. 堅牢な設計パターン：どう使い分けるべきか
設計レビューで私が必ずチェックするポイントを共有しよう。フィールドレベル・センシティビティを導入する際のアンチパターンとベストプラクティスだ。
❌ アンチパターン：「とりあえず全部見せて、アプリ側で制御する」
「DB側での設定が面倒だから、全フィールドを返してアプリの画面側でマスキングしよう」――これはセキュリティインシデントへの片道切符だ。
バッチ処理のログ出力、デバッグ用のスワップダンプ、あるいは脆弱なAPI実装によって、機密フィールドが平文でログや別システムに流出する。セキュリティは「最も信頼性の低いレイヤー（この場合はアプリケーション層）」を前提にしてはならない。DB層で物理的にシャットアウトするのが鉄則だ。
⭕ ベストプラクティス：「役割（Role）に応じたPSBの細粒度分離」
アプリケーションの目的ごとにPSBを厳密に分割せよ。
- `CUSTINQ`（一般照会用）：機密フィールドを `SENFLD` から除外。
- `CUSTAUDIT`（監査・審査用）：すべてのフィールドへのアクセスを許可する専用のPSBを定義し、アクセス権を持つ特権ロールのみに実行を許可。
この設計により、万が一アプリケーションが乗っ取られたとしても、そのPSBが許可された範囲のデータしか詐取できない（最小権限の原則の徹底）。
—
4. パフォーマンス上の注意点（ここがプロの腕の見せ所だ）
アーキテクトとして、セキュリティとトレードオフになるパフォーマンスへの影響を語らないわけにはいかない。
1. CPUオーバヘッドの発生
`SENFLD` を使用する場合、DBMSはセグメント全体を物理読み込みした後、アプリケーションに渡すサブセットを組み立てる（あるいは不要な部分をマスクする）ための編集処理（Mapping Overhead）をCPUで行う。
極端に高頻度で呼ばれるオンライン・トランザクションにおいて、不必要に細かすぎるフィールド単位のセンシティビティを大量に設定すると、CPU使用率をじわじわと押し上げる原因になる。
2. レコード長と可変長（Var-Length）セグメントの罠
もしセグメントが可変長であり、その中にセンシティビティ対象のフィールドが含まれている場合、オフセットの計算コストが発生する。
高スループットが求められる基幹系システムでは、「頻繁に隠す必要がある機密フィールド」と「高頻度でアクセスされる基本フィールド」は、そもそもセグメントを垂直分割（別セグメント化）すべきかどうかのアーキテクチャ判断を下すべきだ。センシティビティ機能は万能薬ではなく、物理設計の妥協点を埋めるための精緻なメスであると心得よ。
—
5. まとめ
階層型DBMSにおけるフィールドレベル・センシティビティは、レガシーな機能ではない。「データをどこまで隠し、どこまで安全に流通させるか」という、モダナイゼーションにおいても最も本質的なセキュリティ要件をハードウェア・ミドルウェアに近いレイヤーで担保する至高の機能だ。
次の設計レビューでは、ただ動くだけのスキーマを持ち込むな。「このPSBの定義において、どのフィールドが隠蔽され、なぜその粒度でなければならないのか」を論理的に説明できるようにしておきたまえ。
以上だ。各自、設計書のブラッシュアップに取り掛かれ。
コメント