SAP Concurのセキュリティ対策では、SSO（シングルサインオン）でログインを一元管理し、権限管理でユーザーごとに利用できる機能や承認範囲を制限することが基本です。SSOだけでは「ログイン後に何ができるか」までは制御できないため、ID管理とSAP Concur内の権限設定を組み合わせて運用します。
SAP ConcurにおけるSSOとは
SSOとは、一度の認証で、連携している複数のサービスへログインできる仕組みです。SAP Concurの利用者は、自社で使っているID管理基盤や認証サービスを経由してログインする形にできます。
通常の運用では、会社側の認証基盤を「IdP（アイデンティティープロバイダー）」、SAP Concurを認証を受けるサービスとして連携します。連携方式や利用できる機能は、契約しているSAP Concur製品、テナントの設定、会社側の認証基盤によって異なります。
SSOでできるセキュリティ対策
- 社内のアカウント管理ルールをSAP Concurのログインにも適用しやすくする
- 退職・異動時に、会社のアカウント停止とあわせてログインを止めやすくする
- パスワードをサービスごとに個別管理する負担を減らす
- 会社側の多要素認証などを利用できる場合がある
- ログインに関する監査や調査を、認証基盤側も含めて行いやすくする
ただし、SSOを導入しただけでSAP Concur内のすべての操作が安全に制限されるわけではありません。認証に成功した後、どのデータを見られるか、申請や承認を行えるかは、別途権限や組織設定で管理します。
SAP Concurの権限管理とは
権限管理とは、ユーザーの役割や所属に応じて、利用できる機能、参照できる情報、実行できる操作を決めることです。SAP Concurでは、一般の申請者、承認者、経理担当者、管理者など、担当業務に応じて必要な権限を分けて設計します。
具体的な権限の名称や設定項目は、利用しているSAP Concurのサービスや契約内容によって異なります。そのため、権限を設定するときは、実際の管理画面に表示される項目と、自社テナントの仕様を確認する必要があります。
権限を分ける主な項目
| 管理項目 | 設定する内容の例 | 確認するポイント |
|---|---|---|
| 機能 | 経費申請、出張申請、請求書処理、管理機能などの利用可否 | 業務に不要な機能まで付与していないか |
| 操作 | 申請、編集、承認、差し戻し、設定変更などの可否 | 申請者と承認者の操作範囲が分かれているか |
| データ範囲 | 自分の申請、部門内の申請、全社データなどの参照範囲 | 役割に対して広すぎる閲覧範囲になっていないか |
| 承認範囲 | 所属部門、金額、申請種別などに応じた承認経路 | 本人が自分の申請を承認できる設定になっていないか |
| 管理者権限 | ユーザー、ワークフロー、ポリシーなどの管理 | 管理者を必要最小限にしているか |
SSOと権限管理の違い
SSOは「本人であることを確認する仕組み」、権限管理は「ログイン後に何を許可するかを決める仕組み」です。役割が異なるため、どちらか一方だけでは十分なアクセス管理になりません。
| 比較項目 | SSO | 権限管理 |
|---|---|---|
| 主な目的 | ログイン認証を一元化する | 利用できる機能や情報を制限する |
| 主に管理するもの | アカウント、認証、ログイン方法 | 役割、操作、データ範囲、承認範囲 |
| 設定場所 | 会社側の認証基盤とSAP Concurの連携設定 | SAP Concurのユーザー・ロール・組織・ワークフローなど |
| 防げるリスク | 退職者アカウントの放置、パスワード管理の分散など | 不要なデータ閲覧、過剰な操作権限、不適切な承認など |
SSOと権限管理を組み合わせるときの考え方
安全に運用するには、会社側のユーザー情報とSAP Concur内の権限情報を、できるだけ同じ考え方で管理します。たとえば、部署、役職、職務、雇用状況などを基準に、ログイン可否とSAP Concurの役割を見直します。
1. ユーザーのライフサイクルをそろえる
入社、異動、休職、退職などのタイミングで、会社側のアカウントとSAP Concurの利用状態を確認します。会社側でログインを止めても、SAP Concur側にユーザー情報や権限が残る場合があるため、連携方法と停止手順を事前に決めておくことが重要です。
2. 最小権限で役割を設計する
最小権限とは、業務に必要な範囲だけ権限を与える考え方です。通常の申請者に管理者権限を付ける、経理担当者全員に全社設定の変更権限を付けるといった設計は避け、必要な機能とデータ範囲を分けて設定します。
3. 承認者と管理者を分ける
承認業務ができることと、ユーザーやシステム設定を変更できることは別の権限です。承認者に管理者権限まで付与せず、設定変更が必要な担当者だけに管理権限を付与すると、誤操作や不正変更の範囲を抑えやすくなります。
4. 権限変更を記録する
誰が、いつ、どの理由で権限を変更したのかを記録します。異動や組織変更に伴う変更なのか、臨時対応なのかを残しておくと、後から権限が適切だったかを確認しやすくなります。
導入・見直し時に確認する項目
SSOと権限管理を設定する際は、次の順番で整理すると、設定漏れを見つけやすくなります。
- 利用するSAP Concurのサービスと、対象ユーザーの範囲を確認する。
- 会社側の認証基盤が対応するSSO方式、認証強度、多要素認証の有無を確認する。
- 入社、異動、退職時に、アカウント作成・変更・停止を誰が行うか決める。
- 申請者、承認者、経理担当者、管理者などの役割を洗い出す。
- 役割ごとに、使える機能、操作、閲覧できるデータ範囲を一覧にする。
- 自分の申請を自分で承認できないか、不要な全社データを閲覧できないかをテストする。
- 異動者や退職者を想定し、SSO側とSAP Concur側の利用停止が適切に反映されるか確認する。
- 定期的な権限レビューの担当者、頻度、記録方法を決める。
設定時に注意したい点
SSOの導入範囲や利用できる認証方式、ユーザー情報の連携方法は、SAP Concurの製品構成や契約、会社側の認証環境によって変わります。一般的なSSOの仕組みだけを前提にせず、導入前に対象サービスの仕様と自社環境の対応状況を確認してください。
また、権限を細かく分けすぎると、異動時の変更漏れや管理の複雑化につながります。役割を増やす前に、標準的な役割で運用できるか、組織変更時に誰が更新するかを検討することが大切です。
臨時に強い権限を付与する場合は、対象者、目的、付与期間、解除担当者を記録します。作業終了後に権限を戻す手順まで決めておくと、不要な権限が残るリスクを抑えられます。
まとめ
SAP Concurのセキュリティ対策では、SSOで認証を一元管理し、権限管理で機能・操作・データ・承認範囲を必要最小限に制限します。SSOはログインの管理、権限管理はログイン後のアクセス制御であり、両方を組み合わせることが重要です。
まずは利用者の役割を洗い出し、役割ごとの必要な操作とデータ範囲を一覧化してください。そのうえで、入社・異動・退職時のアカウント停止や、定期的な権限レビューまで含めて運用を設計します。
