階層型DBMSの論理データベースセキュリティ：物理セグメント継承の深層と実務設計
こんにちは。チーフアーキテクトの私だ。
今日のコードレビューで、また「論理データベースの権限設計を、単なるリレーショナルDBのビューのような感覚でフラットに定義した」コードを見かけた。
リレーショナルデータベース（RDB）に毒された頭脳では、階層型DBMS（IMS/DBやSymfoware、あるいは現代的なツリー構造型NoSQLのルーツ）が持つ「物理セグメントへのアクセス権限の継承ルール」の本質を見誤る。親セグメントの呪縛、そして論理子（Logical Child）が引き起こすセキュリティ境界の崩壊について、今日は徹底的に叩き込む。
甘い設計は、データ漏洩という名の致命傷をシステムにもたらす。実務で通用する堅牢なセキュリティモデルを構築するための知見を、ここに記す。
—
1. 階層型DBMSにおける「論理データベース」とセキュリティの基本思想
RDBが「テーブル（表）」という水平な世界であるのに対し、階層型DBMSは「ツリー（木構造）」という垂直の世界だ。
ここで言う「論理データベース（Logical Database）」とは、物理的に散らばっている、あるいは親子関係にあるセグメント群から、特定のアプリケーションが必要とするビューを切り出したものだ。
しかし、RDBのビュー権限（`GRANT SELECT ON VIEW…`）とはワケが違う。
階層型DBMSでは、「論理データベースへのアクセス権は、物理セグメントの階層構造をそのまま伝播（継承）する」という鉄則がある。
[物理セグメント階層]
ROOT (会社)
├── SEG_A (部門)
│ └── SEG_B (個人情報)
└── SEG_C (ログ)
この構造において、`SEG_B`（個人情報）にアクセスするためには、その祖先である`ROOT`および`SEG_A`の経由が物理的・論理的に必須となる。つまり、上位セグメントのアクセス権を持たないユーザーが、下位セグメントの論理データベースを構築・参照することは原則として許されない。この「物理的制約に裏打ちされたアクセス制御」こそが、階層型の最大の強みであり、設計を誤ると最大の弱点になる。
—
2. スキーマ定義言語（DDL）によるアクセス制御と継承ルール
論理データベースの定義（DBD/PSB定義に相当するDDL）において、セキュリティ境界をどこに引くか。具体的な定義例を見ていこう。
堅牢なスキーマ定義の例
— 物理データベース定義 (PDBD)
DATABASE CORP_DB IS
ROOT SEGMENT COMPANY (
COMP_ID CHAR(4),
COMP_NAME CHAR(30)
)
— 部門セグメント (親: COMPANY)
SEGMENT DEPARTMENT DEPENDENT ON COMPANY (
DEPT_ID CHAR(4),
DEPT_BUDGET NUMERIC(10,2)
)
— 機密個人情報セグメント (親: DEPARTMENT)
SEGMENT CONFIDENTIAL_EMP DEPENDENT ON DEPARTMENT (
EMP_ID CHAR(6),
SALARY NUMERIC(8,2) — セキュリティ上の機密データ
);
— 論理データベース定義 (LDBD) とアクセス権限 (PSB相当)
— ★設計レビューポイント: 一般マネージャー向けの論理DB
LOGICAL DATABASE MGR_VIEW FOR
ROOT COMPANY
GET, INSERT ON COMPANY
GET, INSERT, UPDATE ON DEPARTMENT
— CONFIDENTIAL_EMP は意図的に除外（隠蔽）
;
上記のDLD/DDLにおいて、`MGR_VIEW`という論理データベースを使用するアプリケーションプログラム（あるいはユーザーセッション）には、`CONFIDENTIAL_EMP`セグメントへのアクセス権が一切与えられていない。
ここで発生する「継承の罠」
もし、業務要件の変更で「マネージャーにも一部の従業員データを参照させたい」という理由で、論理関係（Logical Relationship）を安易に追加した場合、セキュリティの継承ルールが牙をむく。
— 危険な論理子セグメントの追加例
SEGMENT LOGICAL_EMP
SOURCE (CONFIDENTIAL_EMP FROM CORP_DB)
DEPENDENT ON DEPARTMENT;
物理的に異なるセグメント同士を論理ポインタで結合（Logical Parent / Logical Child）した場合、OSやDBMSのアクセス制御リスト（ACL）の評価順序によっては、親の権限チェックがバイパスされる脆弱性が生まれることがある。
チーフアーキテクトとしての警告だ。論理子を使うときは、「参照元の物理セグメントの機密レベル」が「論理継承先のセグメント」と同等か、それ以下であることを厳密に担保しなさい。逆向きの権限昇格（Privilege Escalation）が起きていないか、DBDのクロスチェックは必須だ。
—
3. 実務で直面するセキュリティ設計パターンとアンチパターン
現場でよく見る「やってはいけない設計」と、それをどう正すべきか。
アンチパターン：単一の巨大な論理データベースによる「全権委任」
すべてのアプリケーションに同じ論理データベース定義（全セグメントを含む）を割り当て、アプリケーション側のコード（SQLならぬDL/Iコールや独自API）でフィルタリングを行っているケース。
- なぜ悪手か: データベースのセグメントレベルでのアクセス制御（ACL）が機能せず、アプリ側のバグやSQLインジェクション類似の脆弱性（パラメータ改ざんによる別セグメントへのポインタ指定）で、機密セグメントが丸裸になる。
- 正しいアプローチ: アプリケーションのロール（役割）ごとに最小権限の原則（Principle of Least Privilege）に基づき、アクセス可能なセグメントツリーを切り詰めた複数の論理データベース（LDBD）を定義し、それぞれに個別の権限を付与する。
—
4. パフォーマンス上の注意点：セキュリティチェックのオーバーヘッド
セキュリティを厳格にすればするほど、物理I/Oやメモリ上のオーバーヘッドが増大するのはDBMSの宿命だ。特に階層型DBMSにおいては以下の点に留意せよ。
1. セグメントレベルのACL評価コスト
ツリーの深さ（Deep Hierarchy）が増すほど、ルートからターゲットセグメントに到達するまでの物理パス（ダイレクト・アドレス・ポインタやインデックス）を辿る過程で、各セグメント単位の権限チェックが走る。
対策: 頻繁にアクセスされる論理データベースでは、セキュリティ記述子（Security Descriptor）をメモリ上のキャッシュ（バッファプール内）に常駐させられるよう、DBDのセグメント配置をチューニングすること。
2. 論理子（Logical Child）走査時のI/Oバースト
物理的に離れたセグメントを論理ポインタで結ぶと、ポインタを辿るための追加のシークが発生し、キャッシュヒット率が低下する。セキュリティ監査ログを有効にしている場合、このポインタ走査ごとにログ出力が発生し、I/O性能が致命的に悪化するケースがある。
—
チーフアーキテクトからの最終提言
階層型DBMSにおける論理データベースのセキュリティは、単なる「見せる・見せない」のフラットな制御ではない。「物理的なツリー構造と、それに伴う権限の継承・伝播の数学的必然性」を理解して初めて設計できるものだ。
コードレビューで「とりあえず全セグメントが見える論理DBを渡しています」という甘ったれた申請が来たら、こう問い返しなさい。
> 「その論理DBのルートから末端までのパスにおいて、どのセグメントのどの権限が誰に継承されているか、物理アドレスのポインタレベルで説明できるか？」
答えられないうちは、本番環境へのデプロイは見送る。
妥協のないセキュアな設計こそが、プロフェッショナルエンジニアの誇りだ。手を動かせ。
コメント