SAP HANA Analytic Privilegeの設定とトラブルシューティング

SAP HANAで、利用者ごとに参照できる会社コード、地域、部門などを制限するには、オブジェクトへのアクセスを許可するSQL権限だけでなく、データ行を絞り込むAnalytic Privilegeを設計します。特に計算ビューを業務アプリケーションから参照する環境では、権限付与とデータフィルタリングを分けて管理することが重要です。

この記事では、SAP HANA cockpitとSAP HANA database explorerを使った確認方法、設計時の考え方、割り当て後に期待どおりの行だけが返るかを検証する手順をまとめます。開発対象の全体像は、SAP HANA開発の全体像もあわせて確認できます。

01Analytic Privilegeの役割

Analytic Privilegeは、特定の分析オブジェクトに対して、利用者またはロールが参照できるデータ範囲を制御する仕組みです。たとえば、同じ売上データを参照する場合でも、担当者には自分の地域だけ、管理者には全地域を表示させる構成を作れます。

SQL権限は、テーブル、ビュー、プロシージャなどのデータベースオブジェクトに対するSELECTやEXECUTEなどの操作許可を扱います。一方、Analytic Privilegeは、対象の分析モデルに対するアクセス条件を持ち、許可されたオブジェクト内のデータ範囲を制御します。両方が必要な構成では、SQL権限でオブジェクトへのアクセスを許可し、Analytic Privilegeでデータ範囲を絞り込みます。

この分離により、開発者がモデルを変更しても、地域や組織単位のアクセスルールを個別の権限設計として管理できます。権限を付与しただけで全行が見える場合は、オブジェクト権限とAnalytic Privilegeのどちらが不足しているかを切り分けます。

02適用対象の設計

最初に、どの分析オブジェクトを保護するかを決めます。一般的には、ユーザーやアプリケーションが直接参照する計算ビューを対象にし、基礎テーブルや中間ビューへの直接アクセスは業務ロールから分離します。

計算ビューの作成方式や入力パラメータの扱いを整理する場合は、SAP HANA計算ビューの設計情報も役立ちます。Analytic Privilegeの条件列は、計算ビューの出力に存在し、利用者の組織情報と対応付けられるものを選びます。

設計時には、次の項目を表にしてから権限を作成すると、条件漏れを防ぎやすくなります。

デフォルトで全件許可になる設計は、検証環境では便利でも本番環境では危険です。対象範囲が確定していないユーザーには、業務上必要な最小範囲を割り当てる方針にします。

03Analytic Privilegeの作成と割り当て

SAP HANA cockpitでは、権限関連の管理画面から対象データベースのユーザー、ロール、アクセス権を確認できます。SAP HANA database explorerでは、SQLコンソールを使ってユーザーやロールの状態を確認し、開発環境で権限定義を検証できます。

実際の作業は、次の順序で進めます。

1. 保護対象の計算ビューと制限列を確定する。
2. Analytic Privilegeを作成し、対象オブジェクトと許可条件を定義する。
3. 必要なSQL権限を、対象ユーザーまたは業務ロールに付与する。
4. 作成したAnalytic Privilegeを業務ロールへ割り当てる。
5. 制限対象ユーザーと管理ユーザーで参照結果を比較する。
6. 期待した行だけが返ることを確認してから、本番ロールへ反映する。

SQLScriptのプロシージャやテーブル関数を経由してデータを提供する場合は、呼び出し元のSQL権限と、内部で参照するオブジェクトの権限も確認します。処理の分割や権限境界を検討するときは、SAP HANA SQLScriptプロシージャも参照してください。

ロールは、たとえば地域別の業務ロール、管理者ロール、監査用の参照ロールに分けます。ユーザーへ権限を個別付与するより、ロールを介して付与した方が、異動や組織変更の影響を追跡しやすくなります。

04行レベルセキュリティの検証

検証では、同じ計算ビューを複数のテストユーザーで参照し、結果の行数と代表的なキー値を比較します。対象ユーザーには1つの地域だけを許可し、管理者には複数地域を許可すると、条件が実際に適用されているかを確認しやすくなります。

次の確認を、ロール変更や計算ビュー変更のたびに実施します。

• 許可された組織の行が返る
• 許可されていない組織の行が返らない
• 直接参照とアプリケーション経由の結果が一致する
• NULLや空文字の組織値が意図した扱いになる
• 管理者ロールの範囲が業務要件どおりである
• 権限変更後に既存セッションでも期待した結果になる

アプリケーション経由の確認では、接続ユーザー、接続先データベース、ロールの有効化状態を記録します。開発ツールで管理者接続を使うと制限が見えないため、実際の業務ロールを持つテストユーザーで再現することが重要です。

05SQL権限との切り分け

「ビューを開けない」問題と「ビューは開けるが行が少ない」問題は、調査の入口が異なります。前者はSQL権限、ロール、オブジェクトの有効状態を確認し、後者はAnalytic Privilegeの対象オブジェクト、条件式、割り当て先を確認します。

典型的な切り分けは次のとおりです。

SQLScriptやテーブル関数の内部処理がデータを別のビューに渡す構成では、最終出力だけでなく、呼び出し経路全体の権限設計を確認します。Analytic Privilegeが計算ビューに適用されていても、別経路で基礎テーブルを直接参照できるロールがあれば、設計した境界を迂回できます。

06トラブルシューティング

権限を付与した直後に結果が変わらない場合は、まず対象ユーザーが本当に想定したロールを持っているかをSAP HANA cockpitで確認します。次に、SAP HANA database explorerで対象ビューを同じユーザーとして実行し、接続先と実行対象を記録します。

条件値をユーザー属性から取得する設計では、属性の表記ゆれを確認します。大文字と小文字、前後の空白、コード体系、ゼロ埋めの有無が一致しないと、正しいユーザーでも0行になることがあります。条件列がNULLになるデータについても、許可するか除外するかを明示します。

計算ビューを変更した後に権限が効かなくなった場合は、出力列の変更、ビューの再デプロイ、依存オブジェクトの状態、Analytic Privilegeの対象参照を順に調べます。開発環境で修正した定義を本番へ移送する場合は、権限定義、ロール、割り当て、テスト結果を同じ変更単位で管理します。

エラーの内容を確認するときは、ユーザー名だけでなく、発生時刻、接続元アプリケーション、対象ビュー、実行した操作を記録します。監査や障害調査では、権限変更履歴とユーザーのロール変更履歴を突き合わせると、原因を追跡しやすくなります。

07運用時の管理ポイント

本番運用では、Analytic Privilegeを業務ロールと一緒に管理し、ユーザーへの直接付与を例外扱いにします。組織変更の前には、旧組織と新組織の両方を想定したテストユーザーを用意し、異動日に参照範囲が切り替わることを確認します。

権限の最小化を維持するには、定期的に未使用ロール、広すぎる管理者ロール、直接付与された権限を棚卸しします。計算ビューを追加したときは、SQL権限だけでなく、行レベルの制御が必要かを設計レビューに含めます。

アプリケーション開発では、権限エラーを単純な空データとして扱わないようにします。アクセス拒否と、条件により0行になった状態を区別できるログを設計すると、利用者からの問い合わせに対応しやすくなります。

実施前チェックリスト

• 対象ビューと制限列が確定している
• SQL権限とAnalytic Privilegeの責任範囲が分かれている
• 業務ロールを介して権限を付与している
• 制限ユーザーと管理ユーザーのテスト結果がある
• NULL、空値、組織変更時の動作を確認している
• 直接参照できる迂回経路がない
• 本番反映後のロールと監査記録を確認できる

08まとめ

SAP HANAのAnalytic Privilegeは、オブジェクトへのアクセスを許可するSQL権限と組み合わせて、利用者ごとのデータ範囲を管理します。設計では保護対象の計算ビュー、制限列、利用者属性、業務ロールを先に整理し、SAP HANA cockpitとSAP HANA database explorerで割り当てと実行結果を確認します。

問題が起きたときは、オブジェクトを開けないのか、開けるが行が絞られるのかを起点に切り分けます。開発、テスト、本番の各段階で同じ業務ロールを使って検証し、ロール変更と計算ビュー変更を記録することで、行レベルセキュリティを安定して運用できます。