SAP
SAP HANAユーザー権限の基礎と付与方法｜ユーザー作成・ロール・確認手順
SAP HANAのユーザー作成、権限とロールの違い、権限付与・確認・削除の方法を整理します。最小権限の考え方やhdbsql、SAP HANA cockpitでの確認ポイントも解説します。
SAP HANAでユーザーを作成しただけでは、データベース上のオブジェクトを操作できるとは限りません。ログイン認証と、テーブル・ビュー・プロシージャなどを操作する認可は別の仕組みで管理されます。運用担当者は、ユーザーの用途を明確にしたうえで、必要な権限だけを付与することが重要です。
この記事では、SAP HANAのユーザー、権限、ロールの関係を整理し、開発用・運用用・参照用ユーザーを準備する一般的な流れを説明します。本番環境では検証環境で確認してから変更し、組織の承認手順とバックアップ方針に従ってください。
SAP HANAのユーザー権限とは
SAP HANAのユーザー権限は、ユーザーがデータベース内で何を実行できるかを定義する認可情報です。たとえば、ログイン、スキーマ内のオブジェクト参照、データ変更、SQL実行、ユーザー管理などは、それぞれ異なる権限の対象になります。
権限設計では、次の3点を分けて考えると理解しやすくなります。
- 認証：ユーザー名やパスワードなどで本人を確認する
- 認可：確認されたユーザーに操作を許可する
- 監査：誰がいつ何を実行したかを追跡する
ユーザー作成は認証の準備であり、権限付与は認可の設定です。ユーザーを作成したのに「権限がありません」と表示される場合は、認証には成功しているものの、対象オブジェクトに必要な権限が不足している可能性があります。
権限とロールの違い
SAP HANAでは、権限をユーザーへ直接付与する方法と、権限をまとめたロールをユーザーへ付与する方法があります。単一ユーザーの一時的な確認では直接付与が役立つこともありますが、複数ユーザーを継続的に管理する場合はロールの利用が一般的です。
システム権限
システム権限は、データベース全体に関係する操作を制御します。ユーザー管理、監査設定、バックアップ操作、システム情報の参照などが代表例です。影響範囲が広いため、管理者権限を安易に一般ユーザーへ付与してはいけません。
オブジェクト権限
オブジェクト権限は、特定のスキーマやテーブル、ビュー、プロシージャなどに対する操作を制御します。代表的な操作には、SELECT、INSERT、UPDATE、DELETE、EXECUTEなどがあります。参照だけが必要なユーザーには、SELECTだけを付与する設計が適切です。
分析権限
分析権限は、分析ビューなどのデータを行レベルや属性値で制限するために使われます。オブジェクトを参照できるユーザーでも、分析権限の条件によって表示できるデータが限定される場合があります。
ロール
ロールは、複数の権限をまとめて管理する単位です。業務担当者、監視担当者、バックアップ担当者など、役割ごとにロールを設計すると、付与状況を確認しやすくなります。ロールに別のロールを含める構成も可能ですが、階層を深くしすぎると、実効権限の調査が難しくなります。
ユーザー作成前に決めること
ユーザーを作成する前に、用途、接続方式、必要なデータ範囲、パスワード管理者、変更期限を決めます。特にアプリケーション接続用ユーザーと、人が管理画面から利用するユーザーは分けて考える必要があります。
| 確認項目 | 検討内容 |
|---|---|
| 利用目的 | 参照、登録、バッチ、監視、管理のどれか |
| 接続元 | SAP HANA cockpit、hdbsql、アプリケーションなど |
| 対象範囲 | データベース、スキーマ、オブジェクト、行レベル |
| 認証方式 | パスワード、外部認証、証明書など |
| 有効期限 | 一時作業か、継続利用か |
| 所有者 | 申請者、承認者、運用責任者 |
不要な共有アカウントは避け、個人を識別できるユーザーを基本にします。どうしても技術的な共有ユーザーが必要な場合は、利用目的、保管場所、利用者、ローテーション方法、監査方法を文書化します。
SAP HANAユーザーを作成する基本手順
ユーザー作成は、SAP HANA cockpitなどの管理ツール、またはSQLクライアントから実施できます。画面名称や利用できる項目は、SAP HANAのバージョン、接続先、利用者の権限によって異なるため、実環境の表示を確認してください。
基本的な流れは次のとおりです。
- 作成するユーザーの用途と命名規則を確認する
- 適切なデータベースへ接続する
- ユーザー名と認証方式を設定する
- 初期パスワードや有効化状態を設定する
- 必要なロールまたは権限だけを付与する
- 対象ユーザーで接続テストを行う
- 操作できる範囲と監査記録を確認する
SQLで作成する場合の構文は、環境の認証要件やバージョンによって異なります。実行前に公式ドキュメントで構文を確認し、パスワードをコマンド履歴やチャットに残さないようにします。サンプルをそのまま本番環境へ適用するのではなく、組織のパスワードポリシーに合わせて調整してください。
ユーザー作成後に接続できないときは、まずユーザーが有効か、接続先のデータベースが正しいか、パスワードの初回変更が要求されていないかを確認します。認証エラーと権限エラーは原因が異なるため、エラーメッセージを分けて記録します。
権限を付与する方法
権限付与の基本は、必要な操作を洗い出し、それを満たす最小限の権限をロールとしてまとめることです。たとえば、レポート参照用ユーザーには対象ビューのSELECT、バッチ実行用ユーザーには必要なプロシージャのEXECUTEを付与します。
直接付与を検討できる場面は、短期間の調査や限定的な検証です。一方、定常運用ではロールを使うと、異動時や担当変更時に付与・取消を一貫して行えます。直接権限とロール経由の権限を混在させる場合は台帳で管理し、どの経路で権限が有効になっているかを追跡できるようにします。
権限付与では、次の順番で考えると過剰付与を防ぎやすくなります。
- 実行する業務操作を動詞で列挙する
- 操作対象のオブジェクトを特定する
- 読み取りと変更を分ける
- 必要なスキーマを限定する
- ロールへまとめて承認する
- 実際のユーザーで成功・失敗の両方をテストする
「とりあえず広い権限を付与して動作確認し、後で絞る」という進め方は、削除漏れを生みやすい方法です。最初から参照専用、更新可能、管理用などの用途別に分け、権限の追加理由を記録します。
ロール設計の実務ポイント
ロール名には、対象システム、用途、環境、権限レベルが分かる規則を採用すると便利です。たとえば、参照用と更新用を同じ接頭辞で整理し、開発・検証・本番で誤って流用しないようにします。
ロールを設計するときは、次の観点を確認します。
- そのロールの所有者は誰か
- 付与の承認者は誰か
- どのオブジェクトを対象にするか
- 変更権限を含むか
- 他のロールを含むか
- 退職・異動時にどう取り消すか
- 期限付き付与が必要か
管理者ロールを業務ユーザーへ付与するのは、原則として避けます。広範なシステム権限は、設定変更や情報参照だけでなく、障害時の復旧や監査にも影響するためです。作業者には作業に必要な一時権限を付与し、完了後に取り消す運用が望まれます。
付与した権限を確認する方法
権限確認では、付与済みの権限と、実際に有効な権限を分けて確認します。ユーザーへ直接付与された権限だけでなく、所属ロール、そのロールに含まれる権限、分析権限、システム制約などを確認しなければなりません。
確認の流れは次のとおりです。
- 対象ユーザーの所属ロールを確認する
- ロールに含まれるシステム権限を確認する
- 対象スキーマとオブジェクトの権限を確認する
- 必要に応じて分析権限を確認する
- 実際のユーザーで代表的なSQLを実行する
- 不要な権限がないか棚卸しする
管理ツールを利用する場合は、ユーザーやロールの詳細画面から割り当て状態を確認します。SQLクライアントを利用する場合は、システムビューの参照に必要な権限が別途必要になることがあります。管理者自身の権限で見えている情報と、対象ユーザーの実効権限は同じとは限りません。
権限確認のテストでは、成功する操作だけでなく、拒否されるべき操作も用意します。参照ユーザーが更新できないこと、対象外スキーマを参照できないことなどを確認すると、過剰付与を見つけやすくなります。
権限エラーの切り分け
権限エラーが発生したときは、最初に接続先とユーザーを確認します。開発用データベースへ接続したつもりが別のテナントへ接続している、または同名ユーザーを別データベースに作成しているケースがあります。
次に、エラー対象を分類します。
| 症状 | 主な確認箇所 |
|---|---|
| ログインできない | ユーザー状態、認証方式、パスワード、接続先 |
| テーブルを読めない | スキーマ、対象テーブル、SELECT権限 |
| ビューを読めない | ビューの依存オブジェクト、SELECT権限、分析権限 |
| プロシージャを実行できない | EXECUTE権限、実行時に参照するオブジェクト |
| 更新できない | INSERT、UPDATE、DELETE、トランザクション制御 |
| 管理画面で情報が見えない | 管理用のシステム情報参照権限 |
ビューやプロシージャは、対象オブジェクトそのものへの権限だけで解決しない場合があります。内部で参照するオブジェクトや、実行者の権限を使う設定も確認します。エラー発生時は、SQL全文、ユーザー、接続先、実行時刻、対象オブジェクトを記録すると再現性が高まります。
不要な権限を削除する方法
権限削除は、ユーザーの異動、プロジェクト終了、接続元変更、対象オブジェクト廃止などを契機に実施します。削除前に、その権限が別のロール経由で残っていないかを確認してください。直接付与を取り消しても、別ロールから同じ権限が有効になっている場合があります。
棚卸しでは、次の情報を記録すると運用しやすくなります。
- ユーザー名と用途
- 所属部署またはシステム所有者
- 直接付与された権限
- 所属ロール
- 最終利用日または最終確認日
- 付与承認日と有効期限
- 削除・変更の実施者
一時的な障害対応で付与した権限は、作業終了時に必ず見直します。チケット番号や申請番号と変更記録を関連付けると、後から承認経路を確認できます。監査ログの保管期間や個人情報の扱いは、社内規程に従ってください。
hdbsqlとSAP HANA cockpitの使い分け
SAP HANA cockpitは、ユーザー、ロール、監視情報を画面で確認しやすい点が利点です。初学者の確認作業や、対象を目視しながら変更する作業に向いています。ただし、画面に表示される情報は接続ユーザーの権限や製品バージョンに依存します。
hdbsqlは、SQLによる確認や定型作業を自動化しやすい点が利点です。複数環境の比較、定期的な棚卸し、変更前後の記録に活用できます。認証情報をスクリプトへ直接埋め込まず、OSの権限、秘密情報管理、実行ログの取り扱いを設計してください。
接続方法やコマンドラインの基本を確認したい場合は、hdbsqlの使い方と接続確認も参照してください。ユーザー権限の変更は、コマンドが成功しただけで完了とせず、対象ユーザーでの接続と操作テストまで行います。
運用で起きやすい失敗
よくある失敗の一つは、問題解決のために強い管理者権限を一時付与し、そのまま残してしまうことです。もう一つは、ユーザーへ直接権限を追加し続け、ロールと実効権限の関係が分からなくなることです。
次のような対策が有効です。
- 申請なしの権限変更を禁止する
- 付与理由と期限を必須項目にする
- 定期的に直接権限を棚卸しする
- 参照用と更新用のロールを分離する
- 本番と非本番のユーザーを分ける
- パスワードや接続情報を安全に保管する
- 変更後に拒否テストを実施する
バックアップや復旧作業に関係するユーザーは、通常の参照ユーザーとは別に設計します。バックアップ運用の全体像を確認する場合は、SAP HANAバックアップとリカバリの基礎を参照してください。
まとめ
SAP HANAのユーザー権限を安全に管理するには、ユーザー作成、ロール設計、権限付与、実効権限の確認、不要権限の削除を一つのライフサイクルとして扱います。ユーザーを作成しただけでは業務操作はできず、逆に広すぎる権限を付与するとセキュリティと監査のリスクが高まります。
まず利用目的を決め、参照・更新・管理を分離します。次に、必要な権限をロールへまとめ、承認と期限を記録します。最後に、対象ユーザーで許可される操作と拒否される操作をテストし、定期的に棚卸しします。最小権限と追跡可能な変更記録を軸にすれば、日常運用に役立つ管理基盤を作れます。
FAQ
実務では：ユーザーを作成すればすぐにテーブルを参照できますか
いいえ。ユーザー作成はログインできる主体を準備する操作です。対象スキーマやテーブルなどを参照するには、必要なオブジェクト権限やロールが必要です。
実務では：権限はユーザーへ直接付与すべきですか
短期間の検証では直接付与が便利な場合がありますが、継続運用では用途別ロールを利用する方が管理しやすくなります。直接付与する場合も、理由と期限を記録してください。
実務では：権限を付与したのに操作できないのはなぜですか
接続先のデータベース、対象スキーマ、オブジェクト名、ロールの有効状態、依存オブジェクト、分析権限などを確認します。管理者の画面で見える権限と、対象ユーザーの実効権限が異なることもあります。
実務では：強い管理者権限を一時的に付与してもよいですか
承認された障害対応など、必要性と期限が明確な場合に限定します。作業後は実効権限を確認し、不要になった権限を速やかに削除します。
権限の棚卸しはどの程度の頻度で行いますか
組織のリスク、ユーザー数、変更頻度、監査要件によって決めます。少なくとも異動、退職、プロジェクト終了、重大なシステム変更のタイミングでは確認するのが安全です。