SCIM を使用したユーザーのプロビジョニング解除と復帰

ユーザーのプロビジョニング解除または再有効化をEnterprise Managed Usersで行う方法の詳細を確認する。

この機能を使用できるユーザーについて

Enterprises that use Enterprise Managed Users, or GitHub Enterprise Server instances with SCIM enabled

この記事で

使用しているEnterprise Managed Usersで SCIM を有効にしている場合、SCIM を使用して次の操作を行います。

  • ユーザーとグループのプロビジョニングを解除して、アクセスできないようにします。
  • 以前にプロビジョニング解除されたユーザーを、再プロビジョニングします。

ユーザーのプロビジョニングを解除する前に、プロビジョニング解除の効果を理解することが重要です。これは、ID プロバイダーから受け取****GitHubによって異なります。

重要

以降を読む前に、ご自分の Enterprise で SCIM がどのように実装されているかを理解しておく必要があります。 GitHub では、認証とプロビジョニングの両方にサポートされている ID プロバイダー (IdP) を使用する場合は、"paved-path" アプリケーションが提供されます。 円滑パス アプリケーションをお使いでない場合は、REST API を使って SCIM の要求を行います。

Enterprise Managed Users について を参照してください。

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

ユーザーがプロビジョニング解除されると、 GitHub アカウントは 一時停止されます。つまり、ユーザーは企業にアクセスできません。 どのプロビジョニング解除の種類でも、プロビジョニング解除されたアカウントが Enterprise から削除されることはありません。

GitHub が ID プロバイダから受け取るデプロビジョニング呼び出しの種類によって、デプロビジョニングされたユーザーの停止解除（復元）が可能かどうかが左右されます。

  • 論理的なプロビジョニング解除: 特定のシナリオでは、SCIM 統合を通じてユーザーの一時停止を解除することができます。
  • 物理的なプロビジョニング解除: ユーザーの一時停止を解除することはできません。 ユーザーが再びアクセスする必要がある場合は、新しいアカウントをプロビジョニングする必要があります。

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

IdP または REST API を使用してユーザー アカウントのプロビジョニングを解除すると、 GitHub はユーザー アカウントに変更を加えます。

ソフト・プロビジョニング解除の影響

  • ユーザーは一時停止されて、Enterprise とプライベート リソースにアクセスできなくなります。
  • 一時停止されたユーザー アカウントは、Enterprise の設定の [People] セクションで、[Members] ページではなく [Suspended members] ページに表示されます。
  • ユーザーのユーザー名は、元のユーザー名をハッシュ化した値に置き換えられます。その後に_SHORTCODEが続きます（GitHub.com上の企業向け）。
  • Entra ID では、ユーザーのメール アドレスは同じままです。 それ以外のすべての場合、ユーザーのメール アドレスは難読化されます。
  • ユーザーの SCIM ID は、 GitHubのユーザー アカウントにリンクされたままです。 Entra ID では、格納されているリンクされた SCIM ID の active 属性の値が、True から False に更新されます。
  • ユーザーがプライベート リポジトリまたは内部リポジトリのフォークを持っている場合、フォークは 24 時間以内に削除されます。 ユーザーが 90 日以内に一時停止解除された場合、フォークは復元されます。
  • SCIM でプロビジョニングされた IdP グループのメンバーであるユーザーは、これらのグループから隠蔽され、これらのグループにマップされているチームから削除されます。 IdP 側ではユーザーがまだグループのメンバーである場合でもこのようになることに注意してください。
  • Organization のメンバーシップが IdP グループによって管理されている場合、それらの IdP グループから削除されたユーザー、または IdP グループにマップされている organization 内のすべてのチームから削除されたユーザーは、organization から削除されます。
  • Organization のメンバーシップが直接管理されている場合、ユーザーは、手動で削除されるまで、organization のアクセス権を持たない "一時停止されたメンバー" として残ります。

エンタープライズ所有者は、中断されたメンバーのプライベート リポジトリに一時的にアクセスできます (これには、ユーザー名前空間リポジトリと、まだ削除されていないフォークの両方が含まれます)。 「エンタープライズ内のユーザー所有のリポジトリにアクセスする」を参照してください。

ハード・デプロビジョニングの影響

  • ユーザーは一時停止されて、Enterprise とプライベート リソースにアクセスできなくなります。
  • 一時停止されたユーザー アカウントは、Enterprise の設定の [People] セクションで、[Members] ページではなく [Suspended members] ページに表示されます。
  • ユーザーのユーザー名は、元のユーザー名をハッシュ化した値に難読化されます。GitHub.com上のエンタープライズでは、その後に_SHORTCODEが続きます。
  • ユーザーのメール アドレスは難読化されます。
  • ユーザーの表示名は空の文字列に設定されます。
  • ユーザーのリンクされた SCIM ID は、ユーザーのすべての SCIM 属性も含めて、削除されます。
  • ユーザーの personal access tokens、 fine-grained personal access tokens、SSH キー、GPG キー、アプリケーション承認が削除されます。 キーの削除は、コミットの検証に影響する可能性があります。 「コミット署名の検証について」を参照してください。
  • ユーザーが所有するリポジトリは削除されます。
  • ユーザーによって作成されたリソース (コメントなど) は、保持されます。
  • SCIM でプロビジョニングされた IdP グループのメンバーであるユーザーは、これらのグループから隠蔽され、これらのグループにマップされているチームから削除されます。 IdP 側ではユーザーがまだグループのメンバーである場合でもこのようになることに注意してください。
  • Organization のメンバーシップが IdP グループによって管理されている場合、それらの IdP グループから削除されたユーザー、または IdP グループにマップされている organization 内のすべてのチームから削除されたユーザーは、organization から削除されます。
  • Organization のメンバーシップが直接管理されている場合、ユーザーは、手動で削除されるまで、organization のアクセス権を持たない "一時停止されたメンバー" として残ります。

プロビジョニング解除をトリガーするアクション

論理的プロビジョニング解除と物理的プロビジョニング解除ではそれをトリガーするアクションが異なり、トリガーは SCIM 統合によって異なります。 一般に、「paved-path」IdP アプリケーションで実行するほとんどのアクションは、一部の例外を除き、ソフトディプロビジョニングのみをトリガーします。

ソフトデプロビジョニングのトリガー

SCIM 統合ソフトデプロビジョニングのトリガー
REST API
PUT または PATCH 要求が /scim/v2/enterprises/{enterprise}/Users/{scim_user_id} に送信されて、ユーザーの active フィールドが false に更新されます。
保守するユーザーが Entra ID で無効にされるか、アプリケーションから割り当てを解除されるか、割り当てられているすべてのグループから削除されるか、管理者によってテナントから論理的に削除されます。詳しくは、Microsoft のドキュメントの「論理的な削除」をご覧ください。
Oktaユーザーがアプリケーションから割り当てを解除されるか、割り当てられているすべてのグループから削除されるか、[Deactivate] ボタンで非アクティブ化されます。 [中断] ボタンは、 GitHubに要求を送信しないことに注意してください。 Okta では、ソフトデプロビジョニングの呼び出しのみが送信されます。
PingFederateユーザーが、プロビジョニング元によってターゲットにされているユーザー ストアから一時停止、無効化、または削除されます。

完全プロビジョニング解除のトリガー

SCIM 統合完全プロビジョニング解除のトリガー
REST API
DELETE 要求が /scim/v2/enterprises/{enterprise}/Users/{scim_user_id} に送信されます。
保守するMicrosoft のドキュメントの「物理的な削除」で説明されているような、Entra ID ユーザー アカウントの物理的な削除。 論理的に削除された Entra ID ユーザー (Entra ID 管理ポータルの [ユーザー] > [削除済みのユーザー] ページに表示されます) は、論理的に削除されてから 30 日後に Entra ID によって自動的に物理的に削除されます。
Okta該当なし。 Okta では、物理的プロビジョニング解除の呼び出しは送信されません。
PingFederate構成ミスの結果として [Remove User Action] の設定が [Disable] ではなく [Delete] に設定されている場合、このアクションでは物理的プロビジョニング解除の呼び出しが送信されます。
PingIdentity のドキュメントを参照してください。

仮のプロビジョニング解除されたユーザーアカウントの回復

同じ IdP ユーザー アカウントである場合に限り、ソフト デプロビジョニングされたユーザーのアカウントを再プロビジョニングして、そのユーザーのアクセスとアカウントの詳細を復元できます。 IdPユーザーアカウントは同じである必要があります。なぜなら、ソフトプロビジョニング解除されたユーザーアカウントは、SCIMのexternal ID（IdPユーザーオブジェクトID）とSCIMのUser IDに基づいて、この外部IDにまだリンクされているからです。 個別にソフトデプロビジョニングされたユーザー アカウントにリンクされている外部 ID（アイデンティティ）は変更できません。

再プロビジョニングの影響

  • ユーザーは一時停止を解除されて、Enterprise に再びアクセスできるようになります。
  • ユーザーのユーザー名とメール アドレスが復元されます。
  • Organization 内のチームにマップされている、SCIM によってプロビジョニングされた IdP グループのメンバーであるユーザーは、ユーザー アカウントが再プロビジョニングされた直後に organization に追加されます。 以前に organization のメンバーであったユーザーのメンバーシップは、削除されてから 90 日以内であれば復帰されます。 「組織の以前のメンバーの復帰」を参照してください。
  • ユーザーが組織内のチームにマップされている SCIM プロビジョニング IdP グループのメンバーでない場合、 GitHub 組織の所有者は、再プロビジョニング後にユーザー アカウントを手動で組織に追加する必要があります。
  • 削除されたフォークは、一時停止から 90 日以内にユーザーが一時停止解除された場合は復元されます。
  • 次のようなユーザーに関連付けられている項目は復元されます。
    • GitHub Apps、 OAuth apps、アプリの承認
    • Personal access tokens
    • SSH キー
    • トークンとキーの認可
    • ユーザー所有のリポジトリ

再プロビジョニングをトリガーするアクション

ユーザーを再プロビジョニングする方法は、SCIM 統合と、ソフト・デプロビジョニングをトリガーしたアクションによって異なります。

SCIM の実装ユーザーを再プロビジョニングするためのアクション
保守する無効にされたアカウントを再び有効にするか、ユーザーを直接または割り当てられたグループを介してアプリケーションに再度割り当てます。 変更が処理されるまで 40 分待つか、[Provision on Demand] ボタンを使ってすぐに処理します。
Oktaアカウントを再びアクティブにするか、ユーザーを直接またはグループを介してアプリケーションに再度割り当てます。
PingFederateユーザー ストアでユーザーを一時停止解除または再有効化するか、プロビジョニング元によってターゲットにされているデータストア グループまたはフィルターにユーザーを追加し直します。
REST API
PUT または PATCH 要求を /scim/v2/enterprises/{enterprise}/Users/{scim_user_id} に送信して、ユーザーの active フィールドを true に更新します。

ハード プロビジョニング解除されたユーザー アカウントの回復

SCIM 経由でハードプロビジョニング解除された**** ユーザー アカウントを復元GitHub。 代わりに、ユーザーの新しい GitHub アカウントをプロビジョニングする必要があります。

新しいアカウントをプロビジョニングするときは、物理的にプロビジョニング解除されたユーザーのユーザー名を再利用できます。 ただし、ハードプロビジョニング解除されたユーザー アカウントを、 GitHubの新しいユーザー アカウントとマージすることはできません。

  • ハードプロビジョニング解除されたユーザーのメール アドレスと新しいユーザーが一致する場合、 GitHub は、メール アドレスに関連付けられている既存の Git コミットを新しいユーザーに属性付けします。
  • 元のユーザーによって作成された既存のリソースとコメントが、新しいユーザーに関連付けられることはありません。

監査ログイベント

エンタープライズの監査ログには、エンタープライズでのアクティビティに関する詳細が表示されます。 監査ログを使用して、SCIM の構成をサポートできます。 詳しくは、「企業の監査ログ」をご覧ください。

重要

Enterprise 所有者には、監査ログ ストリーミング、ソース IP 開示、API 要求をストリーミングするオプションなどの Enterprise 監査ログ機能を有効にすることを強くお勧めします。 これらのイベントをストリーミングすると、管理者は、ビジネスのニーズに合ったログ アイテム保持ポリシーを設定し、好みのツールを使ってこれらのログのクエリを実行できます。

緩やかなプロビジョニング解除に関するイベント

ユーザーをソフト解除すると、external_identity.update イベントは監査ログに表示されません。 次のイベントは監査ログに表示されます。

  • user.suspend
  • user.remove_email
  • user.rename
  • external_identity.deprovision
  • この要求が成功した場合、external_identity.scim_api_success
  • 要求が失敗した場合、external_identity.scim_api_failure
  • team.remove_member: ユーザーがチームにマップされている IdP グループのメンバーである場合
  • org.remove_member: Organization でのユーザーのメンバーシップが IdP によって管理されていて、organization 内の IdP グループにマップされているすべてのチームから削除された場合

ハード ディプロビジョニングに関するイベント

  • external_identity.deprovision
  • user.remove_email
  • この要求が成功した場合、external_identity.scim_api_success
  • 要求が失敗した場合、external_identity.scim_api_failure
  • team.remove_member: ユーザーがチームにマップされている IdP グループのメンバーである場合
  • org.remove_member: Organization でのユーザーのメンバーシップが IdP によって管理されていて、organization 内の IdP グループにマップされているすべてのチームから削除された場合

再プロビジョニングに関するイベント

ユーザーを再度有効にすると、external_identity.update イベントは監査ログに表示されません。 次のイベントは監査ログに表示されます。

  • user.unsuspend
  • user.remove_email
  • user.rename
  • external_identity.provision
  • この要求が成功した場合、external_identity.scim_api_success
  • 要求が失敗した場合、external_identity.scim_api_failure
  • org.add_member: ユーザーが SCIM によってプロビジョニングされた IdP グループのメンバーであり、このグループが organization 内のチームにマップされている場合

参考資料