Arkose Protect

Arkose Protect는 GitLab.com에서 사용되며, 자가 관리 GitLab 인스턴스에 대해서는 지원되지 않습니다. 다음 문서는 GitLab.com에서 Arkose Protect를 유지하기 위한 내부 요구 사항을 문서화합니다. 이 기능은 이론적으로 자가 관리 인스턴스에서도 사용 가능하지만, 현재로서는 권장되지 않습니다.

GitLab은 Arkose Protect를 통합하여 악의적인 사용자가 계정을 생성하는 것을 방지합니다.

이것은 어떻게 작동하나요?

Arkose Protect가 사용자가 의심스러운 것으로 판단하면, 로그인 버튼 아래에 인터랙티브 챌린지를 제시합니다. 챌린지를 완료해야 로그인 시도가 진행될 수 있습니다. Arkose Protect가 사용자를 신뢰하면, 챌린지는 투명 모드로 실행되어 사용자가 추가 조치를 취할 필요 없이 평소처럼 로그인할 수 있습니다.

%%{init: { "fontFamily": "GitLab Sans" }}%% sequenceDiagram accTitle: Arkose Protect 챌린지의 시퀀스 accDescr: GitLab이 로그인 시도 중 챌린지를 제시할지 여부를 결정하기 위해 Arkose Labs에 데이터를 전송하는 방법. participant U as User participant G as GitLab participant A as Arkose Labs U->>G: 사용자가 가입 양식을 로드합니다. G->>A: 기기 지문 및 텔레메트리 전송 A->>U: 세션 토큰 및 챌린지 여부에 대한 결정을 반환 opt 챌린지 필요 U->>U: 사용자가 챌린지 iframe과 상호작용 end U->>G: Arkose Labs 토큰으로 양식 제출 G ->> A: 검증할 토큰 전송 A ->> G: 검증 응답 반환 Note over G: `UserCustomAttribute::risk_band` 기록 alt session_details.solved == true G ->> U: 진행 else session_details.solved == false G ->> U: 진행하지 않음 end

우리는 악의적인 가입 시도를 어떻게 처리하나요?

받은 위험 점수에 따라 사용자는 계정을 등록하기 위해 최대 세 단계의 신원 확인을 수행해야 할 수 있습니다.

구성

Arkose Protect를 활성화하려면:

  1. ArkoseLabs 라이센스
  2. ArkoseLabs Portal에서 공개 및 비공개 API 키를 가져옵니다.

  3. ArkoseLabs 로그인 챌린지를 활성화합니다. 다음 명령어를 Rails 콘솔에서 실행하고 <your_public_api_key>와 <your_private_api_key>를 자신의 API 키로 바꿉니다.

    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를 비활성화하려면:

ArkoseLabs 통합을 비활성화하려면 Rails 콘솔에서 다음 명령어를 실행합니다.

   Feature.disable(:arkose_labs)

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입니다.
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 프로덕션 로그를 쿼리하세요:

KQL: json.message:"Challenge was not solved" AND json.username:replace_username_here

허용 목록

종단 간 QA 테스트 스위트가 스테이징 및 프로덕션에서 통과할 수 있도록, 우리는 허용 목록에 GITLAB_QA_USER_AGENT을 포함시켰습니다. 각 QA 사용자는 ALLOWLIST 위험 범주를 받습니다.

허용 목록의 사용을 우리의 Arkose::VerifyResponse 클래스에서 확인할 수 있습니다.

피드백 작업

Arkose가 그들의 보호 서비스를 개선하는 데 도움을 주기 위해, 우리는 차단된 사용자 목록을 그들에게 보내는 매일 백그라운드 작업을 생성했습니다. 이 작업은 Arkose::BlockedUsersReportWorker 클래스에 의해 수행됩니다.

통합 테스트

  • GitLab 16.8에서 소개된 특정 동작을 요청하는 데이터 교환과 관련하여 arkose_labs_signup_data_exchange라는 플래그를 사용합니다. 기본적으로 비활성화되어 있습니다.

스테이징 및 개발 환경에서만 챌린지를 억제하거나 챌린지를 강제로 표시할 수 있습니다. 특정 위험 범위를 받기 위해 이 기능을 사용할 수 있습니다.

챌린지를 강제로 표시하려면 브라우저 사용자 에이전트 문자열을 변경하세요. 적절한 문자열은 1Password에서 찾을 수 있습니다.

또는 특정 동작을 요청하려면, arkose_labs_signup_data_exchange 기능 플래그를 활성화하고 데이터 교환 페이로드에 interactive 필드를 포함시켜 다음 값 중 하나를 사용할 수 있습니다:

  • 'true' - 챌린지를 강제로 표시합니다.
  • 'false' - 챌린지를 억제합니다. 챌린지를 억제하는 경우, ArkoseLabs는 귀하의 세션을 안전하다고 간주합니다.

예를 들어, 다음 diff는 챌린지를 억제하도록 페이로드를 업데이트합니다:

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,

추가 리소스

안티-남용 팀은 ArkoseLabs Protect 기능을 소유하고 있습니다. Slack에서 ArkoseLabs/GitLab 협업 채널에 참여할 수 있습니다: #ext-gitlab-arkose.

ArkoseLabs는 또한 다음 리소스를 유지 관리합니다: