SAPユーザータイプの違いと選び方：ダイアログ・通信・サービスユーザーを設計する

SAPのユーザータイプは、ユーザー名の分類ではなく、ログオン方法と利用目的を制御する設計要素です。人がSAP GUIで作業するのか、RFCや外部連携が接続するのか、バックグラウンド処理が実行するのかによって、選ぶタイプが変わります。タイプを適切に設定すると、パスワード運用、ログオン制御、監査、障害対応を整理しやすくなります。

この記事では、SAP GUIとユーザー管理の運用で使う代表的なユーザータイプを、実際の割り当て方と確認手順に沿って説明します。権限そのものはロールで設計し、ユーザータイプはそのアカウントの利用形態に合わせて設定します。

01SAPユーザータイプの全体像

SAPのユーザータイプは、主に次の5種類で整理できます。

タイプは権限ロールの代わりにはなりません。たとえば、通信ユーザーにしただけでRFCの実行権限が付与されるわけではなく、接続先と呼び出す処理に対応したロールが必要です。ロールの分離や変更手順は、SAPロール設計の基本も合わせて確認してください。

02ダイアログユーザーを使う場面

ダイアログユーザーは、担当者がSAP GUIなどからログオンし、画面上で業務を実行するための基本的なタイプです。購買、経理、販売、生産、在庫管理など、個人が操作する業務アカウントに適しています。

個人ごとにダイアログユーザーを割り当てると、変更履歴や実行履歴を担当者単位で追跡できます。共有アカウントを避け、氏名、部署、メールアドレス、利用期間、承認者を管理項目として記録すると、異動や退職時の棚卸しも行いやすくなります。

ダイアログユーザーには、担当業務に必要なロールだけを付与します。FIの伝票入力、MMの購買処理、SDの受注処理などを一つの広いロールにまとめるのではなく、業務機能と職務分掌に合わせて分割します。トランザクションコードだけでなく、会社コード、プラント、購買組織などの組織レベルも確認します。

03システムユーザーと通信ユーザーの使い分け

システムユーザーは、バックグラウンドジョブやシステム内部の自動処理に向いています。人が画面から対話的に操作する前提ではないため、ジョブの所有者や内部処理の実行主体を明確にしたうえで、必要な権限だけを付与します。

通信ユーザーは、外部システムとの接続に使用します。RFC、ALE、IDoc、ミドルウェア連携など、SAPの外から認証して処理を呼び出す接続では、接続単位または連携アプリケーション単位で専用ユーザーを用意します。複数の連携を一つの通信ユーザーに集約すると、パスワード変更や障害時の影響範囲が広がるため、システム境界に合わせた分離が実務上有効です。

通信ユーザーの設計では、次の項目を記録します。

• 接続元システムと接続先クライアント
• RFC宛先または連携設定の名称
• 呼び出す関数、IDoc、サービス、プログラム
• 必要な認証方式とパスワード保管場所
• ロールの所有者、変更承認者、廃止条件
• 接続失敗時に確認するログと担当チーム

外部連携の接続先を確認する場合は、RFCの仕組みと接続単位を整理したリモートファンクションコールの基本が役立ちます。通信ユーザーにダイアログ用の広い権限を付けず、接続テストで実際に呼び出す処理だけを確認します。

04サービスユーザーの利用範囲

サービスユーザーは、複数の利用者が同じサービス経由で接続する構成など、限定されたサービス用途で使います。人の個人識別を目的としたアカウントには、ダイアログユーザーを割り当てます。

サービスユーザーを採用する場合は、共有される認証主体であることを運用設計に明記します。共有アカウントでは、SAP上のログオンユーザーだけから個人を特定できないため、サービス側の認証ログ、アプリケーションログ、リクエストIDなどを組み合わせて追跡できるようにします。

サービスユーザーには、公開するサービスに必要な権限だけを付与します。管理者権限や広範な業務ロールを流用せず、利用機能、接続元、許可する時間帯、パスワード変更手順をレビューします。用途が終了したサービスユーザーはロックまたは削除し、関連する接続設定も同時に確認します。

05参照ユーザーの設計上の注意

参照ユーザーは、他のユーザーに追加の権限を参照させる目的で使います。通常の個人ログオン用として直接利用するのではなく、どのユーザーにどの参照ロールを付与しているかを管理台帳に残します。

参照ユーザーを使う場合は、参照元となるロールの所有者と有効期間を明確にします。権限変更の影響が複数の利用者に及ぶため、変更前後の比較、承認、テストを一つの記録にまとめます。業務上の理由が薄い場合は、個人ユーザーへの直接ロール付与など、影響範囲を追跡しやすい方式を優先します。

06ユーザータイプの選び方

選定は、アカウントを作成する前に「誰が」「何から」「どの頻度で」「どの処理を」実行するかを確認すると進めやすくなります。

判断が曖昧な場合は、接続元と実行主体を先に分離します。人の操作と自動連携が同じユーザーに混在すると、パスワード変更、ロック解除、監査ログの分析が難しくなります。

ロール設計では、ユーザータイプ、職務、組織レベル、接続方式を一緒にレビューします。ユーザータイプだけを変更しても、既存ロールの内容やログオン制御は自動的に適正化されません。権限オブジェクトを業務処理に対応させる方法は、SAP権限オブジェクトの確認方法で整理できます。

07SU01で確認する項目

ユーザー管理では、SU01で対象ユーザーを開き、次の情報を確認します。

• ユーザータイプ
• ユーザーの有効期間
• ロック状態
• パスワード関連の状態
• 割り当てられたロール
• プロファイルやパラメータ
• 所属部署や連絡先などの管理情報

変更前に、対象ユーザーがどの接続設定、ジョブ、RFC宛先、外部アプリケーションから利用されているかを調べます。特に通信ユーザーとサービスユーザーでは、変更後に連携が停止する可能性があります。変更は承認済みの作業時間に実施し、接続テストとログ確認まで完了させます。

ユーザーのロックやログオン失敗を扱うときは、発生時刻、接続元、クライアント、ユーザータイプ、直前の変更を記録します。ログオン失敗が続く場合の確認順序は、SAPログオン失敗が多すぎる場合の切り分けに沿って整理できます。

08通信ユーザーの障害切り分け

外部連携が失敗した場合は、最初にユーザータイプだけで原因を決めず、認証、接続、権限、業務データの順に切り分けます。

1. 接続先のシステム、クライアント、RFC宛先を確認する。
2. ユーザーがロックされていないか、有効期間内かを確認する。
3. パスワードや認証情報が接続側と一致しているかを確認する。
4. 通信ユーザーに必要なロールと権限オブジェクトがあるかを確認する。
5. 呼び出した関数、IDoc、サービス、プログラムの入力値を確認する。
6. SAP側と接続側の時刻、相関ID、エラーメッセージを突き合わせる。

パスワード変更を行う場合は、SAP側だけでなく、RFC宛先、ミドルウェア、ジョブ定義、秘密情報管理基盤などの参照先を同じ作業計画に含めます。通信ユーザーをダイアログユーザーへ変更して動作を試す方法は、監査と運用の前提を変えるため、恒久対策として扱いません。

09定期レビューの実務チェックリスト

ユーザータイプの棚卸しは、アカウント数だけでなく、実際の利用経路と権限の組み合わせを確認します。

• ダイアログユーザーに個人の責任範囲と有効期間が設定されている
• 退職者、異動者、休止中の利用者がロックまたは適切に廃止されている
• 通信ユーザーが接続先と連携用途ごとに分離されている
• システムユーザーのジョブ所有者と実行権限が記録されている
• サービスユーザーの共有範囲と監査ログの対応関係が確認できる
• 参照ユーザーの付与先、所有者、期限が管理されている
• 高権限ロールの付与に承認記録がある
• パスワードや秘密情報の保管場所と変更手順が最新である
• ユーザータイプと実際の接続方法が一致している

レビューで不明なアカウントが見つかった場合は、すぐに削除せず、接続ログ、ジョブ、RFC宛先、担当チームを確認します。利用実態を確認したうえで、ロック、権限縮小、タイプ変更、廃止の順に影響を評価します。

10設計を安定させる運用ルール

ユーザータイプの選択を安定させるには、作成申請に利用目的、接続元、所有者、必要ロール、有効期間、廃止条件を必須項目として設定します。個人用、連携用、サービス用を同じ申請フォームで扱いながら、承認経路とレビュー周期を分けると管理しやすくなります。

本番環境では、緊急変更を除き、申請、承認、変更、テスト、記録の順序を守ります。開発環境で通信ユーザーを使って接続テストを行う場合も、本番と同じユーザータイプと権限境界を再現すると、移送後の差異を減らせます。

SSOを導入している環境では、認証方式とSAPユーザータイプを別々の設計項目として扱います。SSOはログオン認証の流れを変えますが、ユーザーに付与するロール、利用期間、監査責任、外部IDとの対応付けは引き続き管理が必要です。認証方式を含む全体像は、SAP SSOの基本概念で確認できます。

ユーザータイプは、アカウント作成時に一度決めて終わる項目ではありません。利用形態、連携方式、担当組織、監査要件が変わったときに、タイプ、ロール、接続設定、ログ監視をまとめて再評価することで、不要な権限と予期しない接続停止を減らせます。