SAP権限オブジェクトとオーソリゼーションフィールドの設計・調査方法

SAPの画面やプログラムで処理を実行できるかどうかは、ユーザーに割り当てられたロールと、処理中に行われる権限チェックの組み合わせで決まります。単にトランザクションコードをロールへ追加するだけでは、会社コード、プラント、購買組織、活動などの業務範囲まで適切に制御できません。実務では、処理、対象データ、許可する活動を分けて確認します。

この記事では、SAP GUIを使う運用を前提に、権限オブジェクト、オーソリゼーションフィールド、権限値、ロールへの反映、失敗したチェックの調査手順を整理します。ユーザー管理の全体像はロール設計の基本も参照してください。

01権限チェックの基本構造

SAPの権限チェックは、アプリケーションが必要な権限オブジェクトとフィールド値を指定し、ユーザーの有効な権限と照合する流れで実行されます。代表的な判定要素は、権限オブジェクト、オーソリゼーションフィールド、フィールドごとの許可値、そして活動です。

例えば、購買伝票の変更を許可する場合、処理対象の組織範囲と変更活動を同時に制御します。ユーザーが対象トランザクションを起動できても、対象の会社コードや購買組織に対する値が権限に含まれていなければ、後続処理の権限チェックで停止します。

ABAPプログラムでは、AUTHORITY-CHECK 文によって権限オブジェクトとフィールド値を指定します。チェック結果は、指定された値がユーザーの有効な権限に合うかで決まり、画面上のメニュー表示やトランザクション起動可否だけでは判断できません。カスタム開発では、業務上必要なチェック位置と対象フィールドを開発仕様に明記します。

02権限オブジェクトとフィールドの関係

権限オブジェクトは、ひとまとまりの業務操作を判定する単位です。オブジェクトには複数のオーソリゼーションフィールドが含まれ、それぞれに許可する値を設定します。フィールドの組み合わせが一つの権限レコードとして評価されるため、各フィールドを独立した一覧として扱わないことが重要です。

典型的な構成は次のようになります。

• オブジェクト：業務処理を判定する権限オブジェクト
• フィールド：会社コード、プラント、活動などの判定項目
• 値：特定の会社コードや活動コードなど、許可する範囲
• 権限：オブジェクトのフィールドに値を組み合わせた単位
• ロール：複数の権限とメニューをまとめた割り当て単位

オブジェクトの定義やフィールド構成は、SU21で確認します。既存のオブジェクトを調べる際は、名称だけでなく、各フィールドが業務上どの値を表すかを確認してください。似た名称のオブジェクトでも、チェックされる処理やフィールド構成が異なる場合があります。

03オーソリゼーションフィールドの値を決める方法

フィールド値は、ユーザーの役職名だけで決めず、実際の業務範囲と組織構造から定義します。まず、ユーザーが実行する業務処理を列挙し、その処理で参照または更新する組織単位を特定します。その後、活動フィールドと組織フィールドを組み合わせ、必要最小限の値を設定します。

設計時には、次の観点を表にまとめると確認しやすくなります。

値を広く設定すると、業務上不要なデータの参照や更新につながります。一方で、細かく分割しすぎるとロールの保守負荷が上がり、異動や組織変更の際に修正漏れが起きやすくなります。まず職務単位の標準ロールを作り、組織値は必要な範囲で分離する方法が運用しやすい構成です。

04ロールへ権限を反映する手順

PFCGでは、ロールのメニューにトランザクションやレポートなどの入口を登録し、権限タブで生成対象の権限を整備します。組織レベルに該当する項目は、ロールの利用範囲に合わせて値を設定します。

基本的な作業順序は次のとおりです。

1. 対象業務と利用者の職務を確認する
2. 必要なトランザクションやアプリケーションをロールのメニューへ登録する
3. 権限タブで提案された権限オブジェクトを確認する
4. オーソリゼーションフィールドへ組織値と活動値を設定する
5. 権限プロファイルを生成する
6. ユーザー割り当て後に、ユーザー比較を実行する
7. 実際の業務シナリオで参照・登録・変更を検証する

権限生成後は、ロールの変更内容がユーザーの有効なユーザーバッファへ反映されているかを確認します。ロールへ値を追加しただけでは、対象ユーザーのセッションやユーザーマスタ側の状態に直ちに反映されないことがあります。

標準ロールを直接変更せず、業務単位や組織単位に合わせた派生ロールを使うと、変更履歴と担当範囲を管理しやすくなります。ロール設計の命名規則、所有者、申請経路も権限オブジェクトの値設計と同時に決めます。

05権限エラーを調査する手順

ユーザーが処理を実行できない場合は、まずエラーが発生した処理、ユーザー、日時、入力値、対象組織を記録します。次に、ユーザーがロールに割り当てられていること、ロールの権限が生成済みであること、ユーザー比較が完了していることを確認します。

画面上の権限エラー直後であれば、SU53で直前の失敗した権限チェックを確認できます。表示された権限オブジェクト名、フィールド、要求値を記録し、ロール側に設定された値と照合します。SU53だけで原因を特定できない場合は、処理を再現した時間帯を明確にして、STAUTHTRACEで対象ユーザーの権限チェックを追跡します。

調査では、次の順序で切り分けると効率的です。

1. 失敗したチェックの権限オブジェクトを特定する
2. 要求されたオーソリゼーションフィールドと値を記録する
3. ユーザーに割り当てられたロールを確認する
4. ロール内の権限値と要求値を比較する
5. 権限プロファイルの生成とユーザー比較の状態を確認する
6. 追加後に同じ業務シナリオを再実行する

ログオン直後や別のセッションで発生したエラーでは、SU53に直前のチェックが残らないことがあります。その場合は、再現条件と追跡対象をそろえてSTAUTHTRACEを利用します。広い範囲を長時間追跡するとログが増えるため、対象ユーザーと再現時間を絞って実施します。

ログオン失敗やユーザーのロックが入口の問題である場合は、ログオン試行回数超過の対応を確認します。認証経路と業務権限は別の観点で調査し、パスワードやSSOの問題を権限オブジェクトの不足として扱わないようにします。

06複合ロールと組織値の運用

複合ロールを利用する場合は、単一ロールと子ロールのどこで権限が付与されているかを確認します。同じ権限オブジェクトに異なる組織値が設定されている場合、ユーザーの有効権限は複数ロールの組み合わせで広がります。不要なロールを外すだけで解決するケースもあるため、追加付与だけで対応しないことが重要です。

組織変更では、会社コードやプラントの値を一括して見直し、旧組織の値が残っていないか確認します。期間限定の権限は、終了日、承認者、削除担当を記録します。緊急用ロールは通常ロールと分離し、利用記録と事後レビューを残します。

SSOを利用する環境では、認証方式とSAP側のロール割り当てを分けて確認します。SSOの構成やログオン経路はSAP SSOの基本概念で整理できます。SSOでログオンできても、業務処理の権限オブジェクトが自動的に付与されるわけではありません。

07権限設計のレビュー項目

権限設計を本番へ反映する前に、設計書と実際のロールを突き合わせます。レビューでは、入口となるトランザクション、実行される業務処理、参照・変更の区別、組織値、承認経路を確認します。

最低限、次の項目を記録します。

• ロール名と業務上の目的
• 対象ユーザーまたは職務
• 使用する権限オブジェクト
• 各オーソリゼーションフィールドの値
• 参照、登録、変更、削除などの活動
• 生成とユーザー比較の実施記録
• テストした業務シナリオと結果
• 所有者、承認者、見直し日

ユーザーの職務変更時には、追加ロールだけでなく不要になったロールの削除も確認します。定期レビューでは、実際の利用状況、組織変更、職務分離、緊急用権限の利用履歴を確認し、権限の累積を抑えます。

ユーザー種別ごとの管理方針を整理する場合は、SAPユーザータイプの整理も役立ちます。ダイアログユーザー、システム連携用ユーザー、サービス用途のユーザーでは、利用目的と運用監視の方法が異なります。

08実務で使う切り分けの要点

権限不足の調査では、トランザクションを起動できるか、画面を表示できるか、データを参照できるか、データを変更できるかを分けて確認します。それぞれの段階で異なる権限チェックが実行されるため、最初に表示されたメニューだけで判定しません。

また、要求値とロールに設定した値の表記を正確に比較します。活動値、組織値、ワイルドカード、空値の扱いを個別に確認し、意図しない広い値が混在していないかを見ます。標準処理とカスタム処理ではチェックされるオブジェクトが異なることがあるため、実際の失敗ログを根拠に修正します。

最終的には、権限オブジェクトを増やすことよりも、業務上必要な範囲を明確にすることが重要です。PFCGでの設定、SU53やSTAUTHTRACEでの調査、ユーザー比較、業務シナリオの再テストを一つの変更手順として記録すると、再発時の対応が安定します。

まとめ

SAPの権限チェックは、権限オブジェクト、オーソリゼーションフィールド、値、活動、ユーザーに割り当てられたロールの組み合わせで評価されます。SU21で定義を確認し、PFCGで業務範囲を設定し、SU53またはSTAUTHTRACEで実際の要求値を調査する流れが基本です。組織値と活動値を職務に合わせて管理し、生成・ユーザー比較・実業務テストまで完了させることで、安全性と運用性を両立できます。