ロック・ブロック・BAN されたアカウント
このワークフローページでは、Locked、Blocked、および Banned アカウントへの対応方法を説明します。ユーザーは自分がブロックされていると思っていても、実際にはアカウントがロックされているだけというケースがあります。これを確認する方法はいくつかあります:
- この情報を確認する最良の方法は、Zendesk User Lookup app(GitLab Super App の一部) の
LockedおよびStateフィールドを使うことです。 - 管理ユーザー UI の
/admin/user/USERNAMEには、上部の名前の隣に(Locked)、(Blocked)、または(Banned)と表示されます。 - Users API を使って、管理ユーザーとしてログインしている状態でブラウザから URL
https://gitlab.com/api/v4/users/<user_id>を開くと、ユーザーのlockedおよびstateステータスも確認できます。
私たちが実装している Arkose Protect は、アカウントロックには影響を与え ません が、代わりにユーザーがチャレンジを解決せずにサインインするのを防ぐことができます。
ロックされたアカウント
ユーザーがロックされていることが判明した場合、Support::SaaS::Account Locked マクロ を使用してユーザーに状況を説明できます。ユーザーがロックされる条件は次のとおりです:
2FA が 無効 の場合:
- 2FA が有効になっておらず、24 時間以内に 3 回以上のログイン失敗があった。
- アカウントは自動的にはロック解除 されません。ログインに成功した 後、ユーザーは 6 桁のロック解除コードを記載したメールを受信します。次に検証ページにリダイレクトされ、コードを入力してアカウントのロックを解除できます。コードの有効期限は 60 分のみですが、検証ページのリンクをクリックすることで新しいコードをリクエストできます。
2FA が 有効 の場合:
- 10 分以内に 5 回以上のログイン失敗があった。
- アカウントは 10 分間の待機期間後に自動的にロック解除されます。
ユーザーが 6 桁のコードを含む検証メールを受信できない場合は、プライマリメールアドレスが無効か、アクセスできない可能性が高いです。ユーザーがプライマリメールアドレスにアクセスできない場合、アカウントのロック解除やパスワードリセットができません。ユーザーがプライマリメールにアクセスできない場合は、メールアドレスの入れ替え などの他のワークフローを検討してください。
ロック解除コードを含むすべての検証メールおよびパスワードリセットメールは、Mailgun のサプレッションをバイパスします。これらのメールの配信状況は Mailgun でも確認できます。
Kibana で json.message: Account Locked を検索することで、Account Locked の状態を確認できます。Kibana での見え方の例は次のとおりです:

手動ロック解除
ユーザーはまずすべてのセルフサーブ手段を試すべきです。
セルフサーブ手段が尽きており、有償サブスクリプションを持つグループのメンバーがそれでもアカウントにアクセスできない場合、必要に応じて手動ロック解除を検討できます。例えば、ユーザーが外部メールを受信できずコードを取得できない場合、手動ロック解除が必要になることがあります。SaaS では管理ユーザーのみがユーザーアカウントを変更できることに注意してください。
プロセス:
- 上記のロックされたアカウントワークフローに従い、ユーザーがすべてのセルフサーブ手段を尽くしていることを確認します。
- それ以外のケースでは、必要に応じて コメントするか Issue を作成 します。
- アカウント所有権の検証 を行います。
- 管理エリアからアカウントのロックを解除 します。
- admin note を追加 します。
グループオーナーがセルフサーブで対応できるようにする機能リクエストは anti-abuse#339 にあります。
Identity verification 例外リクエスト
クレジットカードや電話番号での検証に問題が発生しているアカウント
ユーザーがクレジットカードや電話番号の検証を完了できない場合。
サポートチームメンバーは、Internal Handbook に記載されている手順に従って例外を作成できます。
ブロックされたアカウント
このワークフローは、ブロックまたは BAN されたユーザーを復活できるかを判断するために使用します。すべてのブロックされたアカウントには、関連 Issue へのリンクを含む admin note が記載されているはずです。
なぜアカウントがブロックされたか?
アカウントがブロックされている場合、admin note を確認してブロックされた理由を調べてください。
- Zendesk の GitLab user lookup app は、ユーザーがアカウントに紐づくメールアドレスでサポートに問い合わせた場合に、そのユーザーの admin notes を表示します。あるいは、
- ChatOps へのアクセス権がある場合は、chatops が有効な任意の Slack チャンネルで以下のコマンドを使ってユーザーの admin notes を読むことができます。
> /chatops run user find <username or email>
ユーザー起点のセルフサーブ削除
Admin Note が User deleted own account on {timestamp} の場合、これはユーザーがセルフサーブ削除を起動したことを意味します。遅延アカウント削除のキャンセル を参照してください。
- Free ユーザー のアカウントは、削除リクエストの当日から 7 日間待ってから、同じメールアドレスやユーザー名で新しいアカウントを作成する必要があります。
Support::SaaS::Gitlab.com::Blocked Accounts::Blocked due to account deletionマクロを使ってください。 - サポートが強制削除を実行できる例外 - ユーザーが有償ネームスペースの一員ではないが有償ネームスペースに追加される必要がある場合(ユーザーまたはトップレベルグループオーナーがチケットを作成)、または有償ユーザーがトップレベルグループ配下に追加されてもなお 7 日間の遅延期間に従う場合(この Issue が修正されるまで該当): サポートは以下の手順で 7 日間の遅延をバイパスできます:
Support::SaaS::Gitlab.com::Blocked Accounts::Blocked due to account deletionマクロを使い、7 日間の待機期間をバイパスしてアカウントを削除する明示的な許可をユーザーに依頼します。- 確認が得られたら、SE(Admin アクセス権あり)がアカウントを削除します。
- SE は削除の結果でチケットを更新します。
- 有償ユーザー のアカウントで、トップレベル有償ネームスペースの直接メンバーである場合は削除遅延がなく、アカウントは即座に(1 時間以内に)削除されます。詳細は この MR を参照。
禁輸国
ブロックや苦情が禁輸国からのアクセスに関するものである場合、Support::SaaS::Gitlab.com::Abuse::TOS Section 10 (Embargoed Countries) マクロを使ってください。
- ユーザーが要求された情報を提供する場合は、Trust and Safety Operations トラッカーで Trust and Safety の Account Reinstatement Request テンプレートを完成させます。それ以外の場合は、ブロックは解除できないことを再度伝えます。
- Free および 有償 の両方のユーザーに対してこのアクションを実施します。
ビジネス上および規制上の義務(中国地域)
中国本土、香港、マカオでのビジネス上および規制上の義務を遵守するためにユーザーがブロックされる場合があります。これはユーザーアカウントの admin note に反映されます。
これらのアカウントの詳細情報とサポートワークフローについては、Internal Handbook を参照してください。
Professional Services マイグレーション
Professional Services マイグレーションも、プロセスの一環としてユーザーをブロックすることがあります。マイグレーション用の admin notes は 2022-08-19 から この Issue を通じて追加されています。それより前にマイグレーションされたアカウントには admin note がない場合があります。2024-09-18 時点では、Professional Services マイグレーションでブロックされたアカウントのブロック解除リクエストは自動的に処理されます(STM #6336 を参照)。
ブロック解除リクエストのチケットを受け取り、自動処理されるべきだったと考える場合は、次の対応をしてください:
- すべてのチケットフィールドが期待値どおりであることを確認する
- Support Operations に通知して調査してもらう
- 依頼者への迅速な解決を確保するため、以下のガイダンスを使ってチケットを手動で処理する
チケットが自動処理されなかった場合、サポートは次のケースでユーザーを手動でブロック解除できます:
- ブロックされたユーザーまたはトップレベルグループオーナーは、ブロック解除のためにサポートチケットを送信できます。顧客が 検証された 後、ユーザーをブロック解除できます。ユーザーに admin note を残し、ブロック解除されたこと、日付、チケット番号を記載します。
- Enterprise users の場合、ユーザーが所属するトップレベルネームスペースの
ownerがチケットを送信できます。アカウント検証 に従い、通常どおり admin note を追加してください。ユーザーまたはオーナーのどちらがリクエストしたかも含めます。 - 必要に応じて、#professional_services チャンネルで明確化や支援を求めることもできます。
- Free および 有償 の両方のユーザーに対してこのアクションを実施します。
admin note がなく、上記のいずれにも該当しない場合
PS マイグレーションの一部ではなく admin notes がない場合を含む、それ以外のすべてのケースでは、Trust and Safety Operations トラッカーで Account Reinstatement Request テンプレートを完成させます。チームのセキュリティメンバーが 24 時間以内にリクエストをレビューします。リクエストが緊急の場合は、#abuse Slack チャンネルに連絡してください。
- ユーザーへの初回応答には
Support::SaaS::Gitlab.com::Blocked Accounts::Escalated-TrustAndSafetyマクロを送信します。 - Trust and Safety によるブロックではないこと、または SM-to-SaaS マイグレーション(Professional Services の有無にかかわらず実施されたもの)の結果としてブロックされていることが確立し、かつそれらが 検証されている 場合:
- 有償アカウント はトップレベルネームスペースの Owner ロールを持つユーザーの承認でブロック解除できます。
- Free アカウント は例外的な状況の場合、かつリーダーシップの承認との組み合わせでのみブロック解除できます。
アカウントが正常にブロック解除された
アカウントがブロック解除された場合、Support::SaaS::Gitlab.com::Blocked Accounts::Account Reinstated- Success マクロを使って、アカウントがブロック解除されたことをユーザーに通知します。
アカウントをブロック状態のままにする(復活させない)
Trust and Safety からの最終決定が、ユーザーアカウントを復活しないことになった場合、Support::SaaS::Gitlab.com::Blocked Accounts::RemainBlocked マクロを適用します。これによりユーザーには標準的な文言が伝えられ、チケットは クローズされます。
このマクロを適用すると、既存のチケットを通じてユーザーが返答する機会は提供されません。これが意図したアクションであることを確認した上で、慎重に適用してください。
BAN されたアカウント
- 次の少なくとも 1 つのシナリオが成立する場合 のみ 次のステップに進んでください:
- ユーザーがリクエストを送るために使用したメールアドレスが、リクエストが対象とするアカウントに紐づくメールアドレスと一致する。この基準は Free ユーザーにもカスタマーにも適用できます。
- ユーザーアカウントが Enterprise user として分類されており、トップレベルグループのオーナーがチケットを起票している。
- Trust and Safety Operations トラッカーで
Trust and Safetyの Account Reinstatement Request テンプレートを完成させます。チームのセキュリティメンバーが 24 時間以内にリクエストをレビューします。リクエストが緊急の場合は #abuse Slack チャンネルに連絡してください。 - ユーザーへの初回応答には
Support::SaaS::Gitlab.com::Blocked Accounts::Escalated-TrustAndSafetyマクロを送信します。 - アカウントが復元された場合は、
Support::SaaS::Gitlab.com::Blocked Accounts::Account Reinstated- Successマクロを使って、アカウントが復元されたことをユーザーに通知します。それ以外の場合は、Reinstatement Request からの理由を提示し、なぜアカウントが BAN されたままになるかを説明します。
遅延アカウント削除のキャンセル
ユーザー自身による開始のアカウント削除は、7 日間の遅延期間内であればキャンセルすることが可能です。Unblocking the account will cancel the account deletion を参照してください。
アカウント削除のキャンセルリクエストは、有償 グループのメンバー、またはユーザーが Enterprise user の場合はトップレベルオーナーが行うことができます。Free ユーザーに対してはアカウント削除のキャンセルは行いません。
プロセス:
- 有償ユーザーまたはトップレベルオーナーは、アカウント検証 に合格する必要があります。
- ユーザーをブロック解除 し、ユーザーに admin note を残してブロック解除されたこと、日付、チケット番号を記載します。
ネームスペース管理者が claim 済みユーザーの削除キャンセルをリクエストする場合
ネームスペース管理者(トップレベルグループの Owner)は、7 日間の遅延期間内に claim された(Enterprise)ユーザー の保留中のアカウント削除のキャンセルをリクエストできます。これは、ユーザーがセルフサーブ削除を開始したが、ネームスペース管理者が業務継続性のためにアカウントを残しておく必要がある場合に該当します。
シナリオ例: acme-corp トップレベルグループ配下の Enterprise user である開発者(@dev-user)がセルフサーブのアカウント削除を開始しました。グループの Owner(@acme-admin)が保留中の削除に気づき、そのユーザーがまだ必要であるためキャンセルを依頼するサポートチケットを送信しました。
プロセス:
- リクエスター が、そのユーザーを claim しているトップレベルグループの Owner であることを確認します。Owner ロールを確認するには GitLab user lookup app または Members API を使います。
- 対象アカウントが、リクエスターのネームスペースが claim している Enterprise user であることを確認します。
- ネームスペース Owner は アカウント検証 に合格する必要があります。
- ユーザーをブロック解除 して保留中の削除をキャンセルします。
- ユーザーに admin note を残し、ネームスペース Owner のリクエストにより削除がキャンセルされたこと、日付、チケット番号を記載します。
- ネームスペース Owner に削除がキャンセルされたことを通知します。
注意: Enterprise users のアカウントはネームスペース管理者によって管理されているため、このアクションにユーザー本人の同意は必要ありません。ただし、ユーザーが後から削除を再開始する場合は、ネームスペース管理者がその根本原因についてユーザーと直接話す必要がある可能性があります。
NOTE: このページの残りの部分は 参考 のためだけのものであり、Security のワークフローを指すように更新する必要があります。
ポリシー参照
- アカウントの復活に関するすべての決定は最終的なものであり、不服申し立てのプロセスはありません。
- これらの基準は あくまで例として 取り扱うものであり、拘束力のある原則 ではありません。
- アカウントが 12 ヶ月以内に再び ToS に違反した場合は、永久 BAN になる可能性があります。
アカウントが復活できる場合
- ユーザーが要求された期間内に該当コンテンツを削除することに同意した場合。
- ユーザーが私たちの利用規約に違反した十分な理由を提供した場合。
- ユーザーが 24 時間以内に GitLab.com からコンテンツを削除またはエクスポートすることに同意した場合。
- DMCA/商標苦情が解決された場合。
アカウントを復活 できない 場合
- ユーザーがアカウントに対する是正措置を拒否する場合。
- ユーザーが私たちの ToS に違反し続ける場合。
- ユーザーが意図的に私たちの ToS に違反する場合。
- サポートエンジニアに対する罵詈雑言や敵対的な行為があった場合。
- アカウントが GitLab のビジネスやブランドに損害を与える場合。
bfd74782)