Anti-Abuse グループ
ビジョン
GitLab 自体だけでなく、アプリケーションに対するインサイダー脅威フィーチャーを提供することが目標です。悪意のある活動、偶発的なリスク、侵害されたユーザーアカウントやインフラコンポーネント、GitLab プラットフォームの異常な使用、および実行可能な修復手順が可能なさまざまな高リスク動作を積極的に特定するのに役立ちます。
方向性
プランニング
私たちの プランニング Issue は、現在取り組んでいること、および次に取り組むことの SSOT（信頼できる唯一の情報源）です。workflow の観点からこれらを確認するための Issue ボード もあります。Issue リストを維持するために、リーダーシップ（EM+PM）がリストのトリアージを管理します。
ワークフロー
私たちは Govern::Authorization の仲間と同じ ワークフローパターン に従います。
イテレーション
MVC の構成方法を計画する際には、MR を垂直・水平にスライスするトレードオフ を意識する必要があります。各イテレーションのスコープ削減を奨励します。
要件が変化したり、コードベースの困難な領域を発見したりすることで複雑さが増す可能性があるため、明確さのために Issue 要件を最新の状態に保つよう努めます。
エンジニアリング機能が定めた イテレーションプロセス に従います。
週次非同期 Issue 更新
私たちは Govern::Authorization の仲間と同じ 週次非同期 Issue テンプレート を使用します。
グループメンバー
Anti-abuse グループ は、GitLab で @gitlab-org/modelops/anti-abuse とメンションできます。
以下の方々がグループの永続的なメンバーです:
チームメンバー情報は 原文 (英語) を参照してください。
チームミーティング
私たちのグループは、非同期の議論に追加の明確さと整合性を得るために同期ミーティングを開催します。チームメンバーが複数のタイムゾーンに分散しており、定められた時間に参加できないことも多いため、すべてのミーティングを 録画 することを目指しています。
AMER フレンドリーと AMER/APAC フレンドリーの時間帯を交互に使用した週次チーム同期ミーティングがあります: 火曜日 18:30 UTC と水曜日 00:00 UTC（AMER、AMER/APAC）。
コラボレーション
安定したカウンターパート と必要に応じて密接に協力することを奨励します。
コラボレーションする可能性のある他のチーム（これに限定されません）:
- Govern:Authentication and Authorization
- Growth:Acquisition and Activation
- Fulfillment:Fulfillment Platform
カウンターパートと連携するタイミングの例:
- 登録フローに重要な変更を加える際の Govern:Authentication and Authorization レビューを求める
- Zuora が関わる変更を加える際の Fulfillment レビューを求める
- ユーザーのサインアップやログイン方法に影響する変更を加える際は
#f_signup_registration（Slack、GitLab 内部）で議論する
アビューズメンテナンス
Anti-abuse チームは Trust and Safety と密接に協力して、プラットフォームでの不正使用を軽減します。Trust and Safety が不正使用軽減の取り組みを支援するために私たちのチームに フィーチャーやメンテナンスをリクエスト することは珍しくありません。優先されたリクエストは アビューズメンテナンスエピック で整理されています。
Pipeline Validation Service の責任
PVS は Anti-abuse チームが所有する内部サービスです。ヒューリスティックベース（テキストマッチングなど）と動作ベースのルール（重複ビルドなど）の組み合わせです。Trust and Safety チーム がこのサービスを最も活用しており、フィーチャーリクエストの顧客として機能します。
ヒューリスティックルール
クリプトマイニング攻撃の性質上、ヒューリスティックは急速に変化し、迅速に実装される必要があります。したがって、T&S はヒューリスティックベースの MR を PVS に提出するよう招待されているか、または Anti-abuse チームに これらの変更をリクエスト します。
動作ルール
動作ルールは変化がより遅く、非常に広範なネットをキャストする可能性があります（非常に対象を絞ったヒューリスティックルールとは異なります）。動作ルールの変更は T&S から来ることが期待されており、Anti-abuse チームによって実装されます。
重大度と優先度
重大度 と優先度は、Anti-abuse がそれに応じて対応できるよう T&S が作成したすべての Issue/マージリクエストに追加されます。
優先度は、攻撃者が戻ってくる可能性の影響と可能性に基づきます。
イテレーション
Anti-abuse は PVS アラートの精度を定期的にレビューし、真のポジティブに影響を与えることなく偽陽性率を削減する機会を探します。Trust and Safety はこれを実施するために必要な情報を提供します。
リンクとリソース
- Slack チャンネル
- Govern:Authorization #g_govern_anti-abuse
