Arkose Protect
GitLab.comではArkose Protectが使用されていますが、GitLabセルフマネージドインスタンスではサポートされていません。以下は、GitLab.comでArkose Protectを維持するための社内要件をドキュメント化したものです。この機能フラグは理論的にはGitLabセルフマネージドインスタンスで使用できますが、現時点では推奨されていません。
GitLabは、悪意のあるユーザーによるアカウント作成を防ぐために、Arkose Protectを統合しています。
どのように機能しますか?
Arkose Protectがユーザーを疑わしいと判断した場合、Sign inボタンの下にインタラクティブなチャレンジが表示されます。サインインを試みるには、チャレンジを完了する必要があります。Arkose Protectがユーザーを信頼している場合、チャレンジは透過モードで実行されます。つまり、ユーザーは追加の操作を行う必要がなく、通常どおりサインインできます。
%%{init: { "fontFamily": "GitLab Sans" }}%%
sequenceDiagram
accTitle: Sequence of an Arkose Protect challenge
accDescr: How GitLab sends data to Arkose Labs to determine whether to present a challenge during the sign-in attempt.
participant U as User
participant G as GitLab
participant A as Arkose Labs
U->>G: User loads signup form
G->>A: Sends device fingerprint and telemetry
A->>U: Returns Session token and decision on if to challenge
opt Requires Challenge
U->>U: User interacts with Challenge iframe
end
U->>G: Submits form with Arkose Labs token
G ->> A: Sends token to be verified
A ->> G: Returns verification response
Note over G: records `UserCustomAttribute::risk_band`
alt session_details.solved == true
G ->> U: Proceed
else session_details.solved == false
G ->> U: Do not proceed
end
悪意のあるサインアップの試みをどのように扱いますか?
受け取ったリスクスコアによっては、ユーザーはアカウントを登録するために、最大3つのステージの本人確認を実行する必要がある場合があります。
設定
Arkose Protectを有効にするには:
ArkoseLabsのライセンスを取得します。
ArkoseLabs PortalからパブリックAPIキーとプライベートAPIキーを取得します。
ArkoseLabsログインチャレンジを有効にします。
<your_public_api_key>と<your_private_api_key>を独自のAPIキーに置き換えて、Railsコンソールで次のコマンドを実行します。ApplicationSetting.current.update(arkose_labs_public_api_key: '<your_public_api_key>') ApplicationSetting.current.update(arkose_labs_private_api_key: '<your_private_api_key>')
Arkose Protectを無効にするには、Railsコンソールで次のコマンドを実行します。
ApplicationSetting.current.update(arkose_labs_enabled: false)Arkoseを無効にすると、電話番号とクレジットカードの認証も無効になります。新しいユーザーは、メールアドレスの確認のみを求められます。
Arkoseを無効にすると、電話番号とクレジットカードの認証も無効になることに注意してください。すべての新規ユーザーは、メールアドレスの確認のみを求められます。
ArkoseLabsのイシューのトリアージとデバッグ
ArkoseLabsによって提起されたイシューは、以下を使用してトリアージおよびデバッグできます:
- Slack上のArkoseLabsとGitLabのコラボレーションチャンネル: #ext-gitlab-arkose
- GitLab production logs。
- Arkose logging service
- Arkose Labs Portal(ユーザーはOktaポータルからアクセスをリクエストできます)
Arkose Labsダッシュボードの分析
- GitLabは定期的にセッションデータをArkoseチームに送信します。これは、悪意のあるユーザーがサインアップするのを防ぐために、カスタムのtelltaleを適用するために使用されます。
- 正常に機能している場合、ユーザーの10%未満が
highリスクとして分類され、セッションの90%以上が検証されるはずです。
highリスクのあるユーザーまたは検証済みのセッションの割合が予想される割合と大幅に異なる場合は、#ext-gitlab-arkose Slackチャンネルにお問い合わせください。
ユーザーセッションのArkoseLabs Verify API応答を表示
ユーザーのArkoseLabs Verify API応答を表示するには、次のKQLを使用してGitLab production logsをクエリします:
KQL: json.message:"Arkose challenge solved" AND json.username:replace_username_hereクエリが有効な場合、結果にはユーザーのセッションに関するデバッグ情報が含まれます:
| 応答 | 説明 |
|---|---|
json.response.session_details.suppressed | チャレンジがユーザーに表示されなかった場合、値はtrueです。ユーザーが許可リストに登録されている場合は常にtrueです。 |
json.arkose.risk_band | low、medium、highのいずれかです。サインイン時に無視されます。本人確認イシューのデバッグに使用します。 |
json.response.session_details.solved | ユーザーがチャレンジを解決したかどうかを示します。ユーザーが許可リストに登録されている場合は常にtrueです。 |
json.response.session_details.previously_verified | トークンが再利用されたかどうかを示します。デフォルトはfalseです。trueの場合、悪意のあるアクティビティーを示している可能性があります。 |
ユーザーがArkoseLabsチャレンジに失敗したかどうかを確認する
ArkoseLabsチャレンジが解決されなかったためにユーザーがサインインに失敗したかどうかを確認するには、次のKQLを使用してGitLab production logsをクエリします:
KQL: json.message:"Arkose*" AND json.username:replace_username_here| ログメッセージ | 説明 |
|---|---|
Arkose was unable to verify the token | ユーザーはチャレンジを解決しましたが、Arkoseはトークンを検証できませんでした。同じユーザーに対してこのエラーが繰り返し表示される場合は、Arkose側にエラーがある可能性があります。 |
Arkose challenge not solved | ユーザーはチャレンジを解決しませんでした。 |
Arkose challenge solved | ユーザーはチャレンジを正常に解決しました。 |
Arkose challenge skipped | Arkoseのステータスサービスがエラーを返したため、チャレンジはスキップされました。 |
許可リスト
エンドツーエンドの品質保証テストスイートがステージング環境と本番環境で合格できるように、許可リストにGITLAB_QA_USER_AGENTを登録しました。各品質保証ユーザーは、ALLOWLISTリスクカテゴリを受け取ります。
許可リストtelltaleの使用法は、Arkose::VerifyResponseクラスにあります。
フィードバックジョブ
Arkoseが保護サービスを改善できるように、私たちがブロックしたユーザーのリストを送信するために、毎日のバックグラウンドジョブを作成しました。このジョブは、Arkose::BlockedUsersReportWorkerクラスによって実行されます。
インテグレーションをテストする
ステージング環境および開発環境でのみ、チャレンジを抑制したり、強制的に表示したりできます。特定のリスクバンドを受信したい場合は、この機能フラグを使用できます。
チャレンジを強制的に実行するには、ブラウザのユーザーエージェント文字列を変更します。適切な文字列は1Passwordにあります。
または、特定の動作をリクエストするには、arkose_labs_signup_data_exchange機能フラグを有効にし、Data Exchangeペイロードを変更して、次のいずれかの値を持つinteractiveフィールドを含めます:
'true'-チャレンジを強制的に表示します。'false'-チャレンジを抑制します。チャレンジを抑制すると、ArkoseLabsはお客様のセッションを安全と見なします。
たとえば、次の差分は、チャレンジを抑制するためにペイロードを更新します:
diff --git a/ee/lib/arkose/data_exchange_payload.rb b/ee/lib/arkose/data_exchange_payload.rb
index 191ae0b5cf82..b2d888b98c95 100644
--- a/ee/lib/arkose/data_exchange_payload.rb
+++ b/ee/lib/arkose/data_exchange_payload.rb
@@ -35,6 +35,7 @@ def json_data
now = Time.current.to_i
data = {
+ interactive: 'false',
timestamp: now.to_s, # required to be a string
"HEADER_user-agent" => request.user_agent,
"HEADER_origin" => request.origin,
追加リソース
- GitLabチームメンバーのみ。本人確認
ArkoseLabsは、次のリソースも管理しています: