データに付与されたラベルで行レベルのアクセスを制御する Oracle Label Security【#11 Oracle Databaseセキュリティ入門】

前回は、Oracle Data Redaction を使って、問い合わせ結果の一部を動的にマスキングする方法を確認しました。

今回扱う Oracle Label Security は、データの行に付けたセキュリティ・ラベルとユーザー側の認可情報を比較し、その行を参照、更新、挿入、削除できるかを制御する機能です。

たとえば、社内の資料を「公開」「社内限定」「機密」「役員限定」のように分類し、利用者の立場や職務によって見られる範囲を変えることがあります。これと同じ考え方をデータベースの行にラベルとして適用し、データそのものに「この行はどの分類か」という情報を持たせるのが、Oracle Label Security の基本的な考え方です。

1. Oracle Label Security とは

Oracle Label Security は、表の各行に付与されたラベルをもとに、ユーザーがその行へアクセスできるかを制御する機能です。アクセス可否の判定はデータベース側で行われ、条件に合わない行は問い合わせ結果に返りません。

たとえば、次のようなデータがあるとします。

このとき、一般社員は「公開」「社内限定」まで見られるが、「機密」は見られない、というルールをデータベースに適用することができます。認可されていないラベルの行は結果に含まれません。

一般のアクセス制御方法における「表」単位に加え、資料管理で「この人は公開資料と社内資料まで」「この人は機密資料まで」「この部署は自部署の機密資料だけ」のような分類による制御と同じ発想で、より細かい「行に付いたラベル」でも判定させることによりより細かいアクセス制御を実現します。

2. ラベルについて

Oracle Label Security の中心となるのは、行に付与する「データ・ラベル」と、ユーザーに設定する「ラベル認可」です。

※ 厳密には、行アクセスの判定には、接続時にユーザーの認可範囲をもとに設定される「セッション・ラベル」が使われます。本記事では概念を簡潔に説明するため、以降はユーザー側の認可情報として説明します。

このうち、データ・ラベルは、主に次の要素で構成されます。

レベルは、「公開」より「社内限定」、「社内限定」より「機密」といったように、上下関係を持つ分類です。ユーザーの認可レベルが行のレベル以上であれば、その点ではアクセス可能と判断できます。

区分（compartment）は、機密度とは別の「知る必要がある領域」を表すために使います。たとえば、同じ「機密」でも、個人情報、財務情報、その他機密情報を含む資料では、見られるべき人が異なります。このような分類に PII、FINANCE、M_AND_A などのような区分を設定できます。

グループは、組織や地域に応じた範囲を表すために使います。たとえば、営業部のデータ、法務部のデータ、APAC 地域のデータといった組織階層や地域階層に応じた制御に向いています。

ラベルは、これらを「:」を用いた以下のような組み合わせで表現します。

ただ、実際の設計では、最初から複雑なラベル体系を作るよりも、レベルだけで足りるのか、区分やグループまで必要なのかを分けて考えることが重要になります。

一方、ユーザーには、アクセスを認めるレベル、区分、グループをラベル認可として設定します。レベルだけで考えると、「機密」まで認可されたユーザーは、「公開」「社内限定」「機密」の行にアクセスできる可能性があります。ただし、区分やグループを使用する場合は、それらの条件も満たす必要があります。

3. 制御ポリシーの仕組み

Oracle Label Security では、上記のラベルを使ったアクセス制御を「ポリシー」として定義します。
この設定における主な要素は次のとおりです。

単なる SQL 条件追加ではなく、”データ行に分類ラベルを持たせる”ことを前提にしている点が重要です。そのため、既存の業務データに適用する場合は、どの行をどの分類にするのか、誰がその分類を決定し維持するのかも設計する必要があります。

また、上記の表にあるとおり、Oracle Label Security では、主に読み取りと書き込みの両方をラベルで制御することが可能です。
アプリケーションからデータの登録・更新を制御したい場合、どのユーザーがどのラベルの行を作成できるのか、既存行のラベルを変更できるのか、更新後にラベル範囲を超えないか、といった設計が必要になる場合があることに気をつけます。

4. ユースケース

Oracle Label Security は制御の特徴上、データごとに分類ラベルを持たせ、ユーザーの認可情報と比較してアクセスを制御したい場合、たとえば、次のような要件で活用できます。

• 文書、案件、顧客、研究データなどに「公開」「社内限定」「機密」といった分類を付けたい
• 部門や地域をまたぐ同じ表の中で、所属部門や担当地域に応じて見える行を変えたい
• 個人情報、財務情報、法務情報など、取り扱い区分ごとに閲覧可能なユーザーを分けたい
• データの機密区分をアプリケーション側だけでなく、データベース側でも強制したい
• 同じアプリケーションやレポートを複数部門で使いながら、行ごとのアクセス範囲を分けたい

特に、データに分類が明示的に存在し、その分類を複数のアプリケーションやレポートで一貫して使いたい場合に有効です。

一方、単に「自分の部門の行だけ見せたい」「担当顧客だけ見せたい」「契約状態に応じて見せたい」という要件では、分類ラベルを導入するとかえって設計が複雑になる場合があります。そのため、分類ラベルを軸にしたアクセス制御が本当に必要かは見極める必要がある点に注意してください。
より汎用的なアクセス制御機能として、この後の連載では Virtual Private Database、Deep Data Security も扱っていきます。こちらの機能も選択肢として検討してください。

5. セキュリティおよび設計上の注意点

当然ですが、Oracle Label Security は、ラベルを定義するだけで安全になるわけではありません。分類基準、ユーザーの認可、ラベルの付与や変更について、責任者と運用方法を決める必要があります。

この設計における考慮点としては以下が挙げられます。

• ラベル体系は、業務上説明できる最小構成から始めます。分類基準や管理責任者が曖昧なまま要素を増やすと、例外管理が複雑になります。
• Oracle Label Security は行単位のアクセス制御です。1行に公開情報と機密情報が混在する場合は、表やビューの設計も含めて検討します。
• ポリシーを表に適用すると、行のラベルを格納する列が追加されます。列を非表示にすることもできますが、既存のSQLやバッチ処理、データ登録・更新処理など処理への影響を確認します。共通のDBユーザーや接続プールを使う場合は、アプリケーションの実利用者ごとの認可をデータベース側の判定へどう反映するかも設計します。

6. ライセンスについて

Oracle Label Security を利用する場合は、Oracle Label Security オプションが必要です。

OCI なども含めると、Oracle Label Security が利用できる環境は以下のとおりです。

• Oracle AI Database FREE
• Enterprise Edition （Oracle Label Security オプションが必要）
• Oracle Base Database Service Enterprise Edition – High Performance
• Oracle Base Database Service Enterprise Edition – Extreme Performance
• Exadata Database Service
  https://oracleapex.com/ords/features/r/dbfeatures/licenses?license_id=94

Oracle AI Database FREE でも利用できるため、機能検証や簡単な動作確認は無償環境で始めることができます。
一方で、バージョンによって利用可能な機能に違いがありますので、必要に応じて確認しておきましょう。
https://oracleapex.com/ords/r/features/dbfeatures/home

7. まとめ

Oracle Label Security は、行に付与したラベルとユーザーの認可情報を比較し、その行を参照、挿入、更新、削除できるかを制御する機能です。

Oracle Label Security は、ラベルベースの分類管理が業務として存在する場合に特に有効です。しかし一方で、アプリケーションとの依存関係が強いため、データ構造や登録・更新フローの見直し、アプリケーションの改修が必要になることがある点に注意してください。

次回は、簡単なラベル体系を作成し、ユーザーによって見える行が変わることをハンズオンで確認します。その次は、Oracle Label Security の基盤となる行レベル・アクセス制御技術である Virtual Private Database（VPD）を取り上げます。