TrueFoundryにおけるSCIM導入：Oktaによるユーザー・チーム管理の自動化

TrueFoundryが成長し、より多くのエンタープライズ顧客にサービスを提供するにつれて、ID管理はすぐに大きなボトルネックとなりました。ユーザーのオンボーディングとオフボーディングは手動で行われていたため、プロセスは遅く、エラーが発生しやすく、内部ワークフローと密接に結びついていました。顧客のIDプロバイダー（IdP）と当社のプラットフォームとの間でリアルタイム同期がないと、アクセス制御は実際の組織変更と同期しなくなりがちで、その結果、遅延、不整合、潜在的なセキュリティリスクが生じていました。

この問題を解決するため、当社は最初のサポート対象IdPとしてOktaから始め、Okta SCIM連携を導入しました。このブログでは、SCIMが不可欠になった理由、それが実現するユースケース、そして主要なトレードオフと本番環境での考慮事項を含め、その設計と実装にどのように取り組んだかについて詳しく説明します。

TrueFoundryでSCIMが必要とされた理由

SCIM導入前、当社のシステムには主に2つの制限がありました。

• 手動によるユーザーライフサイクル管理： ユーザーは手動で作成、アクティブ化、非アクティブ化、削除する必要がありました。これは運用コストが高く、間違いも起こりやすいものでした。

• IdPとプラットフォーム間のID同期なし： Oktaでの変更（ユーザーの追加、削除、グループ間の移動など）は、TrueFoundryに自動的に反映されませんでした。

エンタープライズ顧客にとって、これは致命的な問題です。現代のセキュリティ要件では、以下のことが前提とされています。

• ユーザーが参加した際にアクセスが自動的に付与されること
• ユーザーが退職した際にアクセスが直ちに失効されること
• グループベースのアクセスがチームやプロジェクトに明確にマッピングされること

SCIM（System for Cross-domain Identity Management）は、特にOkta SCIM連携を通じて、シームレスで自動化されたIDプロビジョニングと同期を可能にすることで、まさにこれらの課題を解決するために特別に設計されています。

合わせて読みたい： Claude Code Governance：ゼロからエンタープライズ向け利用ポリシーを構築する

カバーするユースケース

当社のSCIM実装は、最も影響の大きいエンタープライズワークフローに焦点を当てています。

ユーザープロビジョニング

OktaでTrueFoundryアプリケーションにユーザーが割り当てられると、そのアカウントはプラットフォーム上で自動的に作成されるか、既に存在する場合は再アクティブ化されます。これにより、手動でのオンボーディングが不要になり、ユーザーはすぐにアクセスできるようになります。

ユーザーのプロビジョニング解除

Oktaでユーザーの割り当てが解除されると、TrueFoundryでのアクセス権は直ちに失効します。重要な点として、これにより履歴データが削除されることはなく、監査証跡とコンプライアンス要件の維持に役立ちます。

グループ → チーム同期

OktaグループはTrueFoundry内のチームに直接マッピングされます。これにより、使い慣れたグループ構造を使用してアクセスを管理でき、組織の役割やプロジェクトに合わせて権限を簡単に調整できます。

エンタープライズSSO + SCIM自動化

SAMLベースのSSOが設定されると、それをOkta SCIM連携と組み合わせることで、ユーザーとチームの管理が完全に自動化されます。オンボーディングからオフボーディング、アクセス権の更新まで、すべてが手動介入なしで同期されます。

全体アーキテクチャ

概念レベルでは、マッピングはシンプルであり、これによりシステムは予測可能で理解しやすくなります。

• Oktaユーザー → TrueFoundryユーザー
• Oktaグループ → TrueFoundryチーム

このシンプルな1対1のマッピングにより、OktaからのIDデータがTrueFoundryにスムーズに流れ込み、信頼性の高いOkta SCIM連携の基盤を形成します。

これを可能にするため、Oktaの公式仕様に基づいたSCIM 2.0準拠のエンドポイントを実装しました。これらのエンドポイントはOktaと当社のプラットフォーム間の橋渡し役となり、プロビジョニング、更新、プロビジョニング解除などのリアルタイムのIDイベントを処理します。

• /scim/v2/:tenantName/:ssoId/Users
  ユーザーの作成、更新、アクティベーション、非アクティベーションなど、ユーザーの完全なライフサイクルを処理します。
• /scim/v2/:tenantName/:ssoId/Groups
  グループの作成、更新、メンバーシップの変更を管理し、チームが組織構造と同期していることを保証します。

このアーキテクチャにより、Oktaで行われたすべてのID変更がTrueFoundryに自動的に反映され、スケーラブルで本番環境に対応したID管理システムが実現します。

関連記事： 企業向けAIコンプライアンス：AI Gatewayが責任あるAIを自動化する方法

SCIM APIはプラットフォームとどのように連携しますか？

SCIMプロビジョニングはプッシュベースのモデルを採用しており、Oktaが唯一の信頼できる情報源となります。ユーザーの追加、削除、再割り当てなどの変更があるたびに、OktaはSCIM APIを介して当社のプラットフォームに積極的に更新情報を送信します。これが信頼性の高いOkta SCIM連携の中核であり、すべてが自動的に同期されることを保証します。

ライフサイクルの仕組み

1. 管理者がOktaでユーザーやグループを割り当てたり、割り当てを解除したりします
2. OktaはTrueFoundryにSCIM APIリクエストを送信します
3. 当社のSCIMサービスは、安全なベアラートークンを使用して各リクエストを認証します
4. ユーザー、チーム、およびメンバーシップは、プラットフォーム内で作成、更新、または非アクティブ化されます

べき等性による信頼性の確保

私たちが採用した主要な設計原則の1つはべき等性であり、繰り返しのリクエストによって不整合が生じないようにしています。

Oktaは、すべてのユーザーとグループに対して一意のexternalIdを保持しています。当社ではこれをシステム内の正規識別子として保存しており、このアプローチにより以下が保証されます。

• Oktaからの再試行によって、重複するユーザーやチームが作成されることはありません
• 更新は、障害発生時でも一貫して適用されます
• 高頻度の同期操作下でも、システムは安定した状態を保ちます

プッシュベースのモデルとべき等な設計を組み合わせることで、連携は堅牢で予測可能、かつ本番環境に対応したものとなります。

TrueFoundryでのSCIM設定

SCIMのセットアップは、特にOkta SCIM連携を介してOktaと統合する場合、シンプルかつ迅速に行えるように設計されています。開始方法は以下の通りです。

ステップ1：SAMLセットアップ中にSCIMを有効にする

TrueFoundryで新しいSAML v2 SSO設定を作成する際に：

• SCIMチェックボックスを有効にします
• 設定を保存します

これにより、SSO設定と合わせてSCIMプロビジョニングが有効になります。

ステップ2：SCIM認証情報の生成

SCIMを有効にすると：

• SSO設定からSCIMトークンを生成します
• 設定詳細からSCIMベースURLをコピーします

これらの認証情報は、OktaとTrueFoundryを安全に接続するために必要になります。

ステップ3：Oktaの設定

OktaのSCIMプロビジョニング設定で：

• ベースURLをTrueFoundryのSCIMエンドポイントに設定します
• ベアラートークン認証を選択します
• 生成されたSCIMトークンをベアラー値として貼り付けます

この設定が完了すると、Oktaがユーザーとチームを管理するための中央制御プレーンとなり、すべての変更はTrueFoundryに自動的に同期されます。

ユーザープロビジョニングの動作（重要事項）

実稼働環境に対応したOkta SCIM連携において、セキュリティと監査可能性の両方を維持するためには、ユーザープロビジョニングの動作を理解することが非常に重要です。実際の動作は以下のとおりです。

アプリ割り当て

Oktaでユーザーがアプリケーションに割り当てられると：

• ユーザーが存在しない場合、active = true の状態で新しいユーザーが作成されます
• ユーザーがすでに存在する場合、そのステータスは active = true に更新されます

これにより、重複レコードや手動介入なしにシームレスなオンボーディングが保証されます。

アプリ割り当て解除

ユーザーがアプリケーションから割り当て解除された場合：

• ユーザーレコードはデータベースに保持されます
• そのステータスは active = false に更新されます
• すべてのプラットフォームアクセスは即座に無効化されます

このアプローチは、セキュリティと監査性の適切なバランスを取ります。アクセスを即座に削除しつつ、コンプライアンス、追跡、および必要に応じた将来の再アクティブ化のために履歴データを保持します。

グループベースのアクセス管理

グループ同期はSCIMが最も価値を発揮する部分ですが、そこは少し複雑になる可能性もあります。Okta SCIM連携では、グループの動作は、グループがどのように設定され、プラットフォームにプッシュされるかによって異なります。

ケース1：グループがプッシュされない場合（チームは作成されない）

このシナリオでは、グループはチームエンティティを作成せずに、純粋にアクセス制御のために使用されます：

• グループを割り当てると、そのすべてのユーザーにアクセス権が付与されます
• グループを削除すると、アクセス権は即座に無効化されます
• グループ内のユーザーを追加または削除すると、アクセス権が自動的に更新されます
• プラットフォーム内にチームは作成されません

このアプローチはシンプルで、チームを明示的に管理することなくアクセス制御のみが必要な場合にうまく機能します。

ケース2：グループがプッシュされる場合（チームが存在する）

Oktaからグループがプッシュされると、プラットフォーム内でチームになります：

• グループをプッシュするとチームが作成されますが、最初はメンバーがいません
• アプリを割り当てると、グループメンバーがチームに同期されます
• Oktaで追加された新しいユーザーは、自動的にチームに反映されます
• 削除されたユーザーはアクセス権を失いますが、一貫性や履歴のためにチームに引き続き表示される場合があります。
• アプリの割り当てを解除するとアクセスは取り消されますが、チーム自体は存続します。

この設定は、組織グループに合わせた構造的なチーム管理を行いたい場合に最適です。

重要事項：グループの割り当てを解除した後、Oktaからグループを再度プッシュする必要があります。そうしないと、古くなったメンバーがチームに表示され続け、IdPとプラットフォーム間で不整合が生じる可能性があります。

合わせて読みたい： 2026年版 エンタープライズ向けAIコードセキュリティツール ベストセレクション：レビューと比較

主要な設計上の決定とトレードオフ

信頼性の高いSCIMシステムを構築するには、シンプルさ、スケーラビリティ、正確性のバランスを取るために実用的なトレードオフを行う必要があります。Okta SCIM統合を実装する際に私たちが下した主要な決定事項をいくつかご紹介します。

• ステートレスSCIM API： 各SCIMリクエストはセッションや共有状態に依存することなく独立して処理されるため、システムはよりスケーラブルでフォールトトレラントになり、本番環境でのデバッグも容易になります。
• 外部IDによる冪等性： OktaのexternalIdを主要な識別子として使用することで、操作の冪等性を確保し、ユーザーやチームの重複を防ぎ、障害やネットワークの問題発生時に安全な再試行を可能にしています。
• 既知のエッジケース： Oktaは時折、一貫性のないグループメンバーシップデータを送信する場合があります。そのため、私たちは検証および調整チェックを実装していますが、実際の運用環境では依然として注意深い監視が必要です。

Okta SCIM統合の利点とは？

SCIMがプラットフォームに完全に統合されることで、ID管理はシームレスで信頼性の高いものになります。この実装によって得られる主な利点は以下の通りです。

• セキュリティ体制の強化： Okta SCIM統合により、ユーザーが削除されたりグループが変更されたりした瞬間にアクセスが自動的に取り消されます。これにより、遅延が解消され、手動での介入なしに不正アクセスのリスクが軽減されます。
• エンタープライズ対応： SCIMのサポートは、多くのエンタープライズ顧客にとって重要な要件です。これを有効にすることで、大規模組織向けのシームレスなオンボーディングが可能になり、最新のIDおよびコンプライアンス基準に準拠します。
• 運用オーバーヘッドの削減： ユーザープロビジョニング、デプロビジョニング、アクセス制御が完全に自動化されることで、手作業が大幅に削減され、エラーが最小限に抑えられ、チームはより価値の高いタスクに集中できるようになります。 

Okta SCIM連携におけるよくある課題

Okta SCIM連携は強力な自動化をもたらしますが、実装時や拡張時にいくつかの現実的な課題に直面するでしょう。これらの課題を早期に理解することで、より回復力のあるシステムを設計するのに役立ちます。

• 同期遅延: SCIMはほぼリアルタイムですが、Oktaでの変更とプラットフォームでの更新の間にわずかな遅延が発生する場合があります。これにより、一時的にアクセス制御の不一致が生じる可能性があります。
  対処法: 短い遅延を許容するシステムを構築し、即時の一貫性を前提としないようにしてください。
• ユーザーまたはチームの重複: 適切な識別子がない場合、再試行や誤ったマッピングにより、重複するレコードが作成される可能性があります。
  対処法: 常にexternalIdのような安定した識別子に依存し、べき等な操作を強制してください。
• グループメンバーシップの不整合: 部分的なペイロードやエッジケースが原因で、Oktaからのグループ更新が、期待される状態を完全に反映しない場合があります。
  対処法: 調整ロジックを実装し、定期的な同期チェックを行って一貫性を確保してください。
• 順序が異なるリクエスト: SCIMリクエストが予期しない順序で到着する場合があります（例: ユーザー作成前のグループ更新）。
  対処法: 依存する操作をキューに入れるか再試行することで、そのようなケースを適切に処理できるようにシステムを設計してください。
• デバッグの複雑さ: 何か問題が発生した際、その原因がOktaにあるのか、ネットワーク遅延によるものなのか、あるいはバックエンドにあるのかを特定するのは困難な場合があります。
  対処法： 詳細なログを保持し、リクエストの追跡を行うことで、デバッグを容易にしましょう。 

SCIM実装のベストプラクティス

堅牢で本番環境に対応したSCIMシステムを構築するには、ベストプラクティスに従うことが不可欠です。これにより、よくある落とし穴を避け、スムーズな統合と拡張性を確保できます。

• 冪等性の設計： 繰り返し行われるリクエストが常に同じ結果を生成するようにしてください。重複を防ぎ、一貫性を保つために、externalIdのような一意の識別子を使用しましょう。
• 堅牢なロギングの実装： すべてのSCIMリクエストとレスポンスを、十分なコンテキスト（ユーザーID、グループID、アクションタイプなど）とともにログに記録してください。これにより、デバッグと監査がはるかに容易になります。
• リトライの適切な処理： ネットワーク障害やリトライは頻繁に発生します。システムは、不整合やデータの重複を生じさせることなく、繰り返されるリクエストを安全に処理できる必要があります。
• 入力データの検証： SCIMペイロードが常に正しいと仮定してはいけません。処理を行う前に、必須フィールドとデータ整合性をチェックするための検証レイヤーを追加してください。
• 継続的な監視： プロビジョニングの失敗、同期の遅延、異常なアクティビティを監視するために、アラートとダッシュボードを設定してください。これにより、問題を早期に発見できます。
• 調整の計画： 定期的にシステムの現在の状態をOktaと比較し、ユーザーやグループメンバーシップのずれを修正してください。
• エンドポイントの保護： ベアラートークン認証を使用し、HTTPSを強制し、レート制限を検討して、SCIM APIの悪用から保護してください。

まとめ

Okta SCIM連携を導入したことで、TrueFoundryのID管理方法は一変しました。かつては手作業でエラーが発生しやすく、拡張が困難だったものが、今では完全に自動化され、信頼性が高く、企業の期待に応えるものとなっています。

SCIMを導入することで、ユーザーアクセスは組織変更とリアルタイムで同期され、セキュリティの向上、運用負担の軽減、そして企業顧客のスムーズなオンボーディングを実現します。