Okta と従業員向け報奨基盤を安全に連携するには、ログイン成功だけを確認してはいけません。認証、アカウントのライフサイクル、グループと権限、報奨残高、監査証跡を別々の統制として設計します。シングルサインオンは訪問者の本人性を示し、プロビジョニングはアカウントを存在させるかを扱いますが、閲覧、送付、承認、管理の可否は報奨基盤側の承認済み方針で判断する必要があります。
接続設定より先に統制境界を定める
Okta はIDプロバイダー兼プロビジョニング用クライアント、報奨基盤はサービスプロバイダー兼SCIMサーバーとして動作できます。調達では一括して「連携」と呼ばれがちですが、各経路の役割は異なります。
| 経路 | 主な役割 | 単独では決めない事項 | 保存する証拠 |
| SAML 2.0 | 署名付きアサーションによるブラウザー連携認証 | 受領者の利用、承認、管理権限 | 設定、証明書、アサーション試験、サインイン記録 |
| OpenID Connect | IDトークンによるウェブまたはモバイル認証 | プロビジョニング状態や報奨の所有 | 発行者、クライアント、転送先、トークン検証試験 |
| SCIM 2.0 | 利用者の作成、検索、更新、無効化と任意のグループ管理 | 既存セッションの失効や残高の会計処理 | 要求、応答、相関ID、再試行、照合結果 |
| 報奨基盤の認可 | 承認済みグループ・役割方針を操作権限へ変換 | 本人性や在籍状態 | 役割表、承認記録、特権操作ログ |
SAML アサーションや OpenID Connect トークンが正しくても、それだけで管理者にしてはいけません。基盤は認証済み主体をテナント内の不変アカウントに結び、独自の認可方針を適用します。同様に、active=true はIDが有効であることを示すだけで、予算責任者、承認者、送付者、管理者であることを証明しません。
認証は「誰か」、プロビジョニングは「アカウントを置くか」、認可は「何ができるか」、報奨台帳は「価値が誰に属するか」を答えます。四つを明示し、別々に監査できるようにします。
属性対応の前に永続的な識別子を選ぶ
メールアドレスは便利ですが、主キーには不安定です。改姓、ドメイン変更、関連会社への異動、委託先から社員への変更があり、古い別名が再利用される場合もあります。可能なら人事の正本にある変更されない従業員識別子を業務キーとし、externalId または管理された企業拡張属性で渡します。userName は一意なサインインまたはディレクトリ識別子として扱い、残高や監査履歴の唯一の所有キーにはしません。
RFC 7643 のSCIMコアスキーマでは、id はサービスプロバイダーが発行する安定識別子、externalId はクライアントが相関のために設定する識別子です。したがって次の三層を採用します。
- 報奨基盤は内部
idを発行し、再割当てしない。 - Okta は権威ある従業員キーを
externalIdで送る。 - メール、表示名、部門は変更可能な属性とし、残高や履歴の主キーにしない。 設定前にデータの正本表を作り、各属性の所有システム、許可する方向、空値規則、変更時の影響を明記します。通常必要なのは、従業員キー、サインイン識別子、勤務先メール、表示名、言語、国または市場、組織単位、ライフサイクル状態です。生年月日、自宅住所、報酬、私用電話、完全な人事記録は、文書化された用途とプライバシー審査がない限り送らない方が安全です。
| 属性 | 正本 | 方向 | 統制上の注意 |
| 従業員キー | 人事システム | 人事から Okta、報奨基盤へ | 不変で再利用しない |
| 勤務先メール | 人事またはディレクトリ | 下流へ | 変更可能、残高キーにしない |
| 言語と国 | 人事、統制された修正を許可 | 下流へ | 体験と配送に使用、特権には使わない |
| 報奨の役割 | 承認済みアクセス方針 | グループまたは権限対応 | 役職名から推測しない |
| 報奨残高 | 報奨台帳 | SCIM では書き込まない | 独立した業務規則で扱う |
障害時に安全側へ収束するサインオンを作る
SAML では、本番テナントまたは分離環境ごとに専用のアプリケーション設定を用意します。設定済み証明書で署名を検証し、発行者、受信者、アサーション受信先を制限し、妥当な時刻ずれだけを許容し、再利用されたアサーションを拒否します。基盤が応答とアサーション両方の署名に対応するなら双方を検証します。NameID 形式を文書化し、プロビジョニングと同じアカウント解決規則に結びます。 OpenID Connect では、発行者、対象、署名、有効期限、nonce、許可済み転送先を検証します。公開クライアントには証明鍵付き認可コード方式を使います。正しいトークン用途を実装していない限り、アクセス用トークンを本人確認に流用しません。クライアント秘密情報は秘密情報管理基盤に保存し、平文の作業票ではなく、試験済み手順で交代します。 どちらの方式でも、初回ログイン時に特権アカウントを自動作成しません。必要な場合は、テナント所属と承認済みドメインまたはクレームを確認した低権限の受領者に限定します。管理権限は別の明示的な割当てとし、単独で審査できるようにします。 公開前に次を確認します。
- 割当て済み利用者が正しいテナントと役割に入る。
- 未割当て利用者を拒否し、影のアカウントを作らない。
- 不正な発行者、対象、署名、受信先、nonce、期限切れを拒否する。
- メール変更後も同じ不変アカウントへ解決する。
- 無効利用者は新規セッションを作れず、既存セッションも定めた時間内に失効する。
- 緊急用アカウントは分離、監視、期限設定され、通常運用に使われない。
SCIM を照合可能な状態機械として実装する
Okta のSCIM統合手順では、Okta がクライアントとしてサービスプロバイダーの端点を呼び出します。サーバーは契約で約束した操作を確実に実装し、規格に沿う状態コードとエラー本文を返します。グループ管理が明確な要件でなければ、まず利用者の作成、検索、更新、無効化を安定させます。 試験用の利用者内容は小さく保てます。
{
"schemas": ["urn:ietf:params:scim:schemas:core:2.0:User"],
"userName": "worker-00427",
"externalId": "hr-00427",
"active": true,
"name": {"givenName": "Asha", "familyName": "Patel"},
"emails": [{"value": "asha.patel@example.com", "type": "work", "primary": true}]
}
これは秘密情報も実在社員データも含まない例です。サーバーは自身の安定 id と資源メタデータを返します。後続の書込みでは文書化したフィルター、一般には userName または externalId で既存資源を探して更新します。重複作成は二つ目のアカウントを作らず、明確な競合応答にします。
無効化は履歴削除ではなく、通常 active を false にします。規格に沿った部分更新の形は次のとおりです。
{
"schemas": ["urn:ietf:params:scim:api:messages:2.0:PatchOp"],
"Operations": [{"op": "Replace", "path": "active", "value": false}]
}
同じ作成、更新、所属変更、無効化が再送されても同じ状態へ収束させます。テナント、操作、資源ID、結果、相関ID、所要時間を記録し、bearer トークンと不要な個人情報は除去します。サーバーが HTTP 429 を返す場合は合意した再試行規則に従い、有効な整数の Retry-After を尊重します。ただし再試行の枯渇や順序逆転に備え、定期照合が不可欠です。
組織図をそのまま権限表にしない
グループ送信は双方が意味を合意して初めて有効です。人事上の部門名はアプリケーション役割ではありません。「営業」グループを無制限送付権に変換したり、管理職名だけで予算承認を許したりしてはいけません。 用途を絞ったアプリケーション専用グループを作ります。
| Okta グループ | 基盤上の役割 | 許可操作 | 明示的な除外 |
| Rewards-Recipients | 受領者 | 本人向け報奨の閲覧と受取り | 送付、予算、出力、テナント設定なし |
| Rewards-Senders | 送付者 | 割当て計画と予算内の贈答作成 | 役割管理と全体出力なし |
| Rewards-Approvers | 承認者 | 定めた上限内の申請承認 | 秘密情報とID設定の管理なし |
| Rewards-Auditors | 読取り専用監査者 | 承認済み監査・財務報告の閲覧 | 運用変更なし |
| Rewards-Admins | テナント管理者 | 範囲限定の設定と割当て | 報奨所有と台帳修正なし |
複数グループに属する場合の優先規則を定め、基本は権限を加算しつつ、矛盾時は明示的な拒否または隔離状態へ送ります。一括出力、予算変更、ID設定、テナント所有権など高危険操作は、別承認と追加認証で守ります。特権グループは少なくとも四半期ごと、組織変更で範囲が広がる場合は都度審査します。 報奨台帳はIDプロビジョニングから切り離します。アクセス停止で獲得済み価値を消したり、上司へ移したり、管理者が使えるようにしてはいけません。会社負担の未使用枠を失効、返還、維持するか、個人報奨を退職後も受け取れるかは、方針責任者、財務、法務が決めます。基盤は承認済み判断を監査可能な取引で実行し、SCIM の副作用にしません。
退職、休職、再雇用を別の事象として設計する
退職は「ログインできない」だけでは完了しません。手順にはアカウント状態、既存セッション、特権、予約中の施策、未完承認、アプリケーション資格情報、データ保存、報奨価値を含めます。 時間順に責任を割り当てます。
- 人事の正本が不変の従業員キー付きで発効事象を公開する。
- Okta が方針に従いIDを一時停止または無効化し、下流変更を送る。
- 報奨基盤が新規セッションと特権操作を止め、既存セッションを失効または短縮し、アカウントを無効にする。
- 未完承認を取消しまたは再割当てし、施策管理権を外す。
- 別の業務規則で未使用予算と個人残高を処理し、台帳は残す。
- 監視が全システムの収束を確認し、目標超過なら事故記録を開く。 休職は一時停止、退職はアクセス除去と保存、再雇用は現在の権限再計算が必要です。従業員キーで本人の連続性を証明できる場合だけ元のアカウントを再有効化します。人事が新しい識別子を発行した場合は、氏名やメールの一致だけで自動統合せず、承認済みの関連付け判断を行います。
よくある例外をどう扱うか
**重複利用者：**新規割当てを隔離し、不変識別子を比較します。両方の監査履歴を守る承認手順だけで統合します。
**古いグループ所属：**派生役割を外し、変更前後を記録し、影響グループの全利用者を再照合します。
**再雇用：**本人の連続性が証明された場合だけ元アカウントを有効化し、旧特権を戻さず現行方針で役割を再計算します。
**SCIM 停止：**危険な権限拡大を拒否し、再実行可能な処理を待ち行列へ入れ、運用担当へ通知し、復旧後に照合します。成功したサインオンで古いプロビジョニング状態を迂回させません。
**退職停止の失敗：**基盤の緊急統制でアクセスを撤回し、証拠を保存し、接続不具合を直して事象を再実行します。
緑色の接続表示より試験証拠を重視する
本番準備審査では正常系と障害時の安全性を証明します。合成人物だけの非本番テナントで、作成、照合、更新、グループ追加・削除、無効化、再有効化、改名、重複、流量制限、時間切れ、不正トークン、順序逆転を試します。要求と応答の必要なメタデータを保存し、秘密情報は残しません。 運用可能な指標を測ります。
- プロビジョニング収束時間の中央値と高位値。
- 人事の退職事象から基盤でのアクセス停止までの時間。
- 重複率と未解決のID例外。
- 端点、状態コード、テナント別の失敗操作。
- 特権グループ人数と承認時間外の変更。
- Okta 割当てと基盤状態の差分。
- 有効な相関IDと監査証拠を持つ事象の割合。 ログから、誰が変更を始め、どの権威事象が原因で、接続機構が何を送り、基盤がどう認可を判断し、何が変わり、是正が完了したかを追えるようにします。文書化した期間だけ保管し、アクセスを制限し、監査前に出力試験を行います。集計画面だけで元の相関証拠へ戻れない状態は不十分です。 可用性だけでなく安全性を含む目標を置きます。例として「通常更新の99%を15分以内に収束、緊急退職は5分以内に新規アクセスを阻止、超過時はID運用責任者へ通知して追跡可能な事故記録を作る」と定められます。ただし実際の構成と人員で守れる値にします。
段階導入し、調達にも使える受入記録を残す
統合管理者、小規模な部門横断試行、一事業部、全体という順に広げます。試行中は一般利用者の手動作成を無効にし、予定した統制経路そのものを検証します。観察期間中は対応規則を固定し、その後一度に一変数だけ変更します。施策全体の統治には従業員表彰プラットフォーム導入ガイド、周辺システムの境界には法人ギフト連携アーキテクチャも利用できます。 受入記録には、構成図、データ流一覧、属性表、プロトコル設定、証明書と鍵の交代計画、グループ役割表、退職判断手順、試験項目、結果、未解決リスク、責任者、承認日を含めます。調達ではテナント分離、監査出力、事故対応、保存と削除、再委託先、地域別データ処理、管理者復旧も確認します。 公開前の最終確認です。
- 不変キーがメール、氏名、組織変更後も本人を結ぶ。
- サインオンとプロビジョニングが個別に安全側へ失敗する。
- SCIM 属性で残高変更や特権自己付与ができない。
- グループ削除が追加と同じ確実さで権限を下げる。
- 退職、休職、再雇用を別々に試験した。
- トークン、証明書、秘密情報に所有者と交代証拠がある。
- 片側だけ有効な利用者を照合で検出できる。
- 監査出力が人事事象、Okta 操作、基盤判断、是正を結ぶ。 良い結果は「Okta 接続済み」という表示ではありません。変更、障害、調査のときにも理解できるライフサイクルです。本人証明、アカウント状態、アプリケーション認可、報奨会計を分け、不変識別子と試験可能な証拠で収束させます。 選定した報奨基盤が必要なID統制を備える場合、Giftpack は、統制された従業員向け贈答と履行の実行層として利用できます。ID、セキュリティ、人事、法務、財務の各担当は、アクセス方針、雇用判断、データ利用、残高処理を引き続き所有し、Giftpack は承認済み判断を実装します。これらの専門判断を置き換えるものではありません。