Arkose Protect

DISCLAIMER: Arkose Protect은 GitLab.com에서 사용되며, 자체 호스팅된 GitLab에서는 지원되지 않습니다. 아래는 GitLab.com에서 Arkose Protect를 유지하는 데 필요한 내부 요구 사항을 문서화한 것입니다. 이 기능은 이론상으로는 자체 호스팅된 인스턴스에서 사용할 수 있지만 현재 권장되지 않습니다.

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

작동 방식

Arkose Protect가 사용자를 의심스러운 것으로 판단하면 로그인 버튼 아래에 상호 작용하는 도전을 제시합니다. 이 도전은 로그인 시 진행되어야 합니다. Arkose Protect가 사용자를 신뢰한다면 도전은 투명한 모드로 작동하여 사용자가 추가 조치를 취할 필요 없이 일반적으로 로그인할 수 있습니다.

sequenceDiagram 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>')
    

ArkoseLabs 문제 현황 및 디버깅

ArkoseLabs에서 발생한 문제를 확인 및 디버그하는 방법은 다음과 같습니다.

사용자 세션을 위한 ArkoseLabs Verify API 응답 보기

사용자에 대한 ArkoseLabs Verify API 응답을 보려면 다음 KQL을 사용하여 GitLab 프로덕션 로그를 쿼리합니다.

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에게 보내는 백그라운드 작업을 매일 생성했습니다. 이 작업은 Arkose::BlockedUsersReportWorker 클래스에 의해 수행됩니다.

통합 테스트

  • GitLab 16.8에서 소개된 Data Exchange를 통해 특정 동작을 요청하려면 arkose_labs_signup_data_exchange라는 플래그로 활성화하세요. 기본적으로 비활성화됩니다.

스테이징 및 개발 환경에서만 도전을 억제하거나 도전을 강요할 수 있습니다. 특정 리스크 범주를 받기를 원한다면 이 기능을 사용할 수 있습니다.

도전을 강요하려면 브라우저 사용자 에이전트 문자열을 변경하십시오. 적절한 문자열은 1Password에서 찾을 수 있습니다.

또는 특정 동작을 요청하려면 arkose_labs_signup_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,

추가 자원

Anti-abuse team은 ArkoseLabs Protect 기능을 소유하고 있습니다. 슬랙에서 ArkoseLabs/GitLab 협업 채널인 #ext-gitlab-arkose에 참여할 수 있습니다.

ArkoseLabs은 다음 자원도 유지 관리합니다: