- どのように動作しますか？
- 悪意のあるサインアップ試行に対する対処方法は？
- 悪意のあるサインインの試みはどのように扱われますか？
- 設定
- ArkoseLabsのイシューのトリアージとデバッグ
- Allowlists
- フィードバックジョブ
- インテグレーションをテスト
- 追加リソース
アルコセプロテクト
免責事項: Arkose ProtectはGitLab.comで使用され、自己管理のGitLabインスタンスではサポートされていません。以下はGitLab.comでArkose Protectをメンテナーするための内部要件を文書化したものです。この機能は理論的にはセルフマネージドインスタンスでも使用可能ですが、現時点では推奨されていません。
GitLabはArkose Protectをインテグレーションし、サインインフォームにおけるクレデンシャルスタッフィングやボットを防御します。GitLabはユーザーが以下のような場合にArkose Protectをトリガーします：
- 過去に一度もサインインしたことがない場合。
- 2回連続でサインインに失敗したことがあります。
- 過去3ヶ月間サインインしなかったことがある方。
どのように動作しますか？
Arkose Protect はユーザーが疑わしいと判断した場合、Sign in ボタンの下に対話型のチャレンジを表示します。サインインを続行するには、このチャレンジを完了する必要があります。Arkose Protect がユーザーを信頼している場合、チャレンジは透過モードで実行されます。つまり、ユーザーは追加のアクションを取る必要がなく、通常通りサインインできます。
悪意のあるサインアップ試行に対する対処方法は？
受け取ったリスクスコアに応じて、ユーザーはアカウント登録のために最大3段階の本人確認が必要になる場合があります。
悪意のあるサインインの試みはどのように扱われますか？
Arkose Protect が悪質と判断した場合、ユーザーのアクセスを拒否することはありません。しかし、ユーザーのリスクスコアは管理者コンソールで公開され、ユーザーを手動でブロックする際に、より多くの情報に基づいた判断ができるようになります。ユーザーをブロックする場合、リスク予測モデルを改善するために ArkoseLabs にフィードバックが送られます。
arkose_labs_prevent_login 機能フラグを有効にすると、High のリスクスコアを持つセッションはアクセスを拒否されます。これまでのところ、Arkose Protectの予測を評価し、正当なユーザーのサインインを妨げていないことを確認するため、この機能フラグは無効にしています。とはいえ、対話型チャレンジは悪意のあるサインインの試みを防ぐのに効果的であることが分かっています。
設定
Arkose Protect を有効にするには
- ArkoseLabsのライセンスを取得します。
- ArkoseLabsポータルからAPI公開鍵と秘密鍵を入手してください。
-
ArkoseLabs ログインチャレンジを有効にします。Rails コンソールで以下のコマンドを実行し、
<your_public_api_key>と<your_private_api_key>を自分の API キーに置き換えてください。Feature.enable(:arkose_labs_login_challenge) 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_labs_prevent_login機能フラグを有効にします。Railsコンソールで次のコマンドを実行します：Feature.enable(:arkose_labs_prevent_login)
ArkoseLabsのイシューのトリアージとデバッグ
ArkoseLabsで発生したイシューのトリアージとデバッグができます：
ユーザー セッションの ArkoseLabs Verify API レスポンスの表示
ユーザーの ArkoseLabs Verify API レスポンスを表示するには、GitLab のプロダクションログに以下の KQL をクエリします：
KQL: json.message:"Arkose verify response" AND json.username:replace_username_here
クエリが有効な場合、結果にはユーザーのセッションに関するデバッグ情報が含まれます：
| レスポンス | 説明 |
|---|---|
json.response.session_details.suppressed |
true チャレンジがユーザーに表示さ trueれなかった場合の値。ユーザーがallowlistedの場合はtrue 常に true。 |
json.arkose.risk_band |
low 、medium 、またはhigh を指定できます。 サインイン時には無視されます。ID 検証の問題をデバッグするために使用します。 |
json.response.session_details.solved | ユーザーがチャレンジを解決したかどうかを示します。ユーザーが許可リストに登録されている場合は、常にtrue を指定します。 |
json.response.session_details.previously_verified | トークンが再利用されたかどうかを示します。デフォルトはfalse です。true の場合、悪意のあるアクティビティを示す可能性があります。 |
ユーザーが ArkoseLabs チャレンジに失敗したかどうかをチェックします。
ArkoseLabs チャレンジが解決されなかったためにユーザーがサインインに失敗したかどうかを調べるには、GitLab のプロダクションログに以下のクエリを実行します：
KQL: json.message:"Challenge was not solved" AND json.username:replace_username_here`
Allowlists
エンドツーエンドの QA テストスイートがステージと本番でパスできるように、GITLAB_QA_USER_AGENTを許可リストにしました。各 QA ユーザーはALLOWLIST のリスクカテゴリを受け取ります。
allowlistの使い方は、Arkose::VerifyResponseクラスにあります。
フィードバックジョブ
Arkose の保護サービスを向上させるために、ブロックされたユーザーのリストを送信するバックグラウンドジョブを毎日作成しました。このジョブはArkose::BlockedUsersReportWorker クラスによって実行されます。
インテグレーションをテスト
ステージング環境と開発環境でのみ、チャレンジを抑制したり、強制的に表示させたりすることができます。この機能は特定のリスクバンドを受け取りたい場合に使用できます。
チャレンジを強制するには、ブラウザのユーザーエージェント文字列を変更します。適切な文字列は1Passwordで見つけることができます。
あるいは、特定の動作を要求するには、setConfig を変更して、data.id プロパティを含めます：
-
'ML_defence'- チャレンジを強制的に表示します。 -
'customer_request'- チャレンジを抑制します。チャレンジを抑止すると、ArkoseLabs はあなたのセッションを安全とみなします。
例えば、setConfig はチャレンジを抑制します：
arkoseObject.setConfig({
data: { id: 'customer_request' },
...
});
追加リソース
乱用防止チームは ArkoseLabs Protect 機能を所有しています。Slack の ArkoseLabs/GitLab コラボレーションチャンネルに参加できます：#ext-gitLab-arkose.
ArkoseLabs は以下のリソースもメンテナーしています：