2026年8月27日、米国国立標準技術研究所（NIST）が内部報告書 NIST IR 8611「m-NGAC: Transcending Traditional Database Security Models」をFinal版として公開しました。アプリケーション側で実装してきた細かな認可を、データベースの内部に埋め込んだNGAC（Next Generation Access Control）で強制する、という提案です。本記事では原文の内容をもとに、その仕組み、従来方式との違い、実務で考えたい論点を整理します。
1. NIST IR 8611の位置づけ
著者はNISTのGopi Katwala氏です。まず押さえておきたいのは、この文書の性格です。
- IR（Internal Report）であり、SP（Special Publication）のようなガイドラインや標準ではない
- 冒頭の注記によると、この発明は米国特許商標庁（USPTO）で特許が承認済みで、複数のDBベンダー向けにPoC実装が作られている
- したがって「NIST推奨の実装方式」ではなく、「NIST発の特許技術を紹介する論文」と捉えるのが正確
2. 従来のDBアクセス制御の何が問題か
企業データへの入口は、いまや「アプリケーション → DB」だけではありません。BIツール、SQLクライアント、自動化サービスなど、複数の経路からDBに直接アクセスされます。論文は、従来方式の限界を次のように整理しています。
- 粒度が粗い：GRANT/REVOKE（DAC/RBAC）は基本的にテーブル・列単位で、行単位や、列の中の個別フィールド単位の制御が弱い。ベンダー機能（行レベルセキュリティなど）でもフィールド単位が欠けがち
- 制御が分散する：細かい制御をアプリ側で実装すると、アプリごとに認可ロジックが乱立し、不整合やセキュリティホールの原因になる
- 迂回される：SQLエディタやCLIでDBに直接接続すれば、アプリ側の認可をすり抜けられる
- 汎用解がない：ベンダー独自機能はあっても、DB製品を問わず使える汎用的な方式がない
アプリ側だけで認可を実装している場合、別経路からDBに到達されるとポリシーが効かなくなります。これが「アプリケーションレベルの認可だけでは不足する」理由の核心です。
3. NGACとは
NGACは、NISTが開発したANSI/INCITS標準の属性ベースアクセス制御（ABAC）です。ユーザー、リソース、属性、ポリシーを有向非巡回グラフ（DAG）で表現するのが特徴です。RBACのような複数のポリシー方式を「ポリシークラス」として同じグラフ上に共存させ、認可の評価時にまとめて考慮できます。ポリシー管理は集中し、強制は分散して行えるため、アプリケーション層から強制を切り離せる点が利点とされています。
4. m-NGACのアーキテクチャ
m-NGACは、NGACのアルゴリズム（API）をSQLで実装し、DBの内部に組み込みます。構成要素は3つです。
| 構成要素 | 役割 |
|---|---|
| Source | クエリを発行する側（アプリ、分析ツール、管理ツール、自動化サービスなど）。DBから見ると通常のSQLクライアント |
| Mediator | 保護対象データと同じスキーマ内に置かれるビューやトリガーなどのDB内オブジェクト。全アクセスを横取りし、誰がどのテーブル・フィールドにアクセスするかを抽出する |
| Adjudicator | NGACポリシーの保管と評価を担い、許可・拒否を返す。別のポリシースキーマに置き、同一DB内でも外部のポリシーストアでも構わない |
Mediatorは、DBエンジン本体を改造するのではなく、スキーマ内のオブジェクトで実現します。Adjudicatorは、ポリシーグラフを毎回たどる代わりに、グラフから生成したACLを引いて高速に判定します。ただしACLはポリシー状態の実体化ビューなので、ポリシー変更時などには再生成が必要です。
5. クエリ処理の流れ
- Sourceがクエリを送ると、テーブルに届く前にMediatorが横取りする
- Mediatorがユーザー、テーブル、フィールドを抽出し、Adjudicatorに問い合わせる
- AdjudicatorがNGACポリシーを評価し、許可・拒否を返す
- SELECTでは、拒否されたフィールドをエラーにせず「PROTECTED」などの設定可能なマスク値に置き換えて返す。元のWHERE句は変更しない
- INSERT/UPDATE/DELETEでは、トリガーで事前に権限を確認する。SELECTと違って部分的な許可は認めず、全体が許可されなければトランザクション全体を拒否する
なお、INSERTやDELETEが許可・実行された場合は、NGACのポリシー側のオブジェクト属性や関係も自動的に更新され、データとポリシーの対応が保たれます。
6. ポリシー構築と複数DBの集中管理
ポリシーの構築は、次の4ステップで行います。
- 保護が必要なスキーマのデータを、NGAC側にオブジェクト属性として取り込む
- アプリユーザーに対応するDBユーザーを作り、基本権限はネイティブのGRANTで付与する
- NGAC側で、ユーザーと属性の階層を作る
- アソシエーション（許可）とプロヒビション（禁止）で最終的なポリシーを定義する
さらに、Adjudicatorと各種ポリシーを専用DBに集約すれば、複数のリソースDBが同じ判定エンジンに問い合わせる構成にできます。ポリシーの更新は一箇所で全DBに反映され、DBの追加も接続するだけで済みます。大規模な企業環境で、複数DBの整合性を保ちたい場合に効果的な設計です。
7. 既存方式との比較
論文は、ベンダー内蔵のきめ細かなアクセス制御と、先行方式であるNDAC（Next Generation Database Access Control）とm-NGACを比較しています。
| 観点 | ベンダー内蔵の細粒度制御 | NDAC | m-NGAC |
|---|---|---|---|
| 強制の場所 | DBエンジン内 | アプリとDBの間 | DBのスキーマ内 |
| SQLの扱い | セキュリティ述語を自動付加 | SQLを解析してWHERE句を書き換え | ビューでマスクし、WHERE句は変更しない |
| 直接接続での迂回 | エンジン内で強制されるため起きにくい | 迂回されうる | 迂回されない（論文の主張） |
| 汎用性 | ベンダー固有で移植性に乏しい | 汎用を目指す | DB製品を問わず、最小限の調整で適用可能（論文の主張） |
論文がNDACの弱点として挙げているのは、WHERE句の書き換えに伴う次の問題です。
- 方言、サブクエリ、CTE、ウィンドウ関数などの解析ミスが、そのまま穴になる
- AND/ORの優先順位が崩れ、クエリの意味が変わるおそれがある
- 行数やページネーションが変わり、アプリの挙動に影響する
- オプティマイザの実行計画やインデックスの利用に悪影響が出る
- 実行されたSQLがアプリの発行したSQLと異なるため、監査やフォレンジックが難しくなる
8. 実務で考えたい論点（筆者の考察）
ここからは論文の記述ではなく、導入を検討する際の論点として筆者が整理したものです。
- 性能の裏付けがない：論文にはアーキテクチャの説明が中心で、性能評価や実測データは含まれていません。ビューやトリガー経由のオーバーヘッドは、導入前の検証が必要です
- 特権管理が新たな要になる：Mediatorがスキーマ内のオブジェクトである以上、ビュー、トリガー、ポリシースキーマを変更できる権限の管理と分離が重要です。「rootユーザーにも耐える」という論文の主張は、この権限分離の設計次第だと考えられます
- ACL再生成の運用：ポリシー変更やユーザー・属性の変更のたびにACLへ反映する運用設計が必要です
- マスク値によるアプリへの影響：拒否された項目が「PROTECTED」のような値で返るため、その値を想定していないアプリやレポートで表示や集計に影響しないか確認が必要です
- 成熟度：現時点ではPoC段階であり、すぐに本番導入できる製品ではありません。まずは既存の行・列レベルセキュリティとの違いを整理する材料として使うのが現実的です
9. AIエージェント時代への含意（筆者の考察）
論文自体はAIエージェントを扱っていません。ただ、Sourceの例には「自動化サービス」が含まれており、考え方は自然に延長できます。AIエージェントにDBへの広いアクセス権をまとめて与えるのではなく、エージェントごとのIDに対し、誰が・何の操作を・どのデータに対して行えるかをデータ側のポリシーで判定する、というゼロトラスト的な認可モデルです。エージェントの実装やプロンプトの挙動に依存せず、データの手前で強制できる点が、この考え方の魅力です。あくまで筆者の解釈であり、NISTの主張ではない点にご注意ください。
まとめ
- NIST IR 8611は、NGACをDB内部に埋め込み、行・列・フィールド単位の認可を集中管理する「m-NGAC」を紹介する内部報告書
- Mediator、Adjudicator、ACLの3点で、アプリ、BI、SQLエディタなど全経路に同じポリシーを適用する
- SQLの書き換えを行わず、拒否した項目はマスク値で返す点が、NDACとの大きな違い
- 特許取得済みでPoC段階。性能や特権管理などは、導入前に検証すべき論点として残る
「認可の強制点をデータ側に寄せる」という考え方は、アクセス経路が増え続ける現在の環境で、検討する価値のある方向性です。
関連記事：CIS Benchmarks 2026年8月更新を読み解く（DBの設定の堅牢化と、m-NGACによる認可の役割分担）、CIS MCP Server Benchmark v1.0.0を読み解く（AIエージェントとデータをつなぐMCPサーバーの設定基準）、SpyCloud 2026 Identity Threat Report解説（AIエージェントを含む非人間IDの管理）。