InfoGrab DocsInfoGrab Docs

Arkose Protect

요약

Arkose Protect는 GitLab.com에서 사용되며 GitLab Self-Managed 인스턴스는 지원하지 않습니다. GitLab은 악의적인 사용자의 계정 생성을 방지하기 위해 Arkose Protect를 통합합니다.

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

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 포털에서 공개 및 비공개 API 키를 발급받습니다.

  • 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를 비활성화하려면 Rails 콘솔에서 다음 명령을 실행합니다.

ApplicationSetting.current.update(arkose_labs_enabled: false)

Arkose를 비활성화하면 전화번호 및 신용카드 인증도 비활성화됩니다. 신규 사용자는 이메일 주소만 인증하면 됩니다.

Arkose를 비활성화하면 전화번호 및 신용카드 인증도 함께 비활성화된다는 점에 유의하는 것이 중요합니다. 모든 신규 사용자는 이메일 주소만 인증하면 됩니다.

ArkoseLabs 이슈 트리아지 및 디버그#

다음을 사용하여 ArkoseLabs에서 발생한 이슈를 트리아지하고 디버그할 수 있습니다:

Arkose Labs 대시보드 분석#

  • GitLab은 정기적으로 세션 데이터를 Arkose 팀에 전송하며, 이 데이터는 악의적인 사용자의 가입을 방지하기 위한 커스텀 텔테일 적용에 활용됩니다.

  • 정상적으로 작동하는 경우, 10% 미만의 사용자가 high 위험으로 분류되어야 하며 90% 이상의 세션이 인증되어야 합니다.

  • high 위험 사용자 또는 인증된 세션의 비율이 예상 비율과 크게 다를 경우, #ext-gitlab-arkose Slack 채널에 문의하세요.

사용자 세션에 대한 ArkoseLabs Verify API 응답 조회#

사용자의 ArkoseLabs Verify API 응답을 조회하려면, 다음 KQL을 사용하여 GitLab 프로덕션 로그를 쿼리합니다:

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 프로덕션 로그를 쿼리합니다:

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의 상태 서비스가 오류를 반환하여 챌린지를 건너뛰었습니다.

허용 목록#

스테이징 및 프로덕션에서 엔드투엔드 QA 테스트 스위트가 통과될 수 있도록, GITLAB_QA_USER_AGENT허용 목록에 등록했습니다. 각 QA 사용자는 ALLOWLIST 위험 카테고리를 받습니다.

허용 목록 텔테일의 사용 방법은 Arkose::VerifyResponse 클래스에서 확인할 수 있습니다.

피드백 Job#

Arkose의 보호 서비스 개선을 돕기 위해, 우리가 차단한 사용자 목록을 매일 전송하는 일일 백그라운드 job을 생성했습니다. 이 job은 Arkose::BlockedUsersReportWorker 클래스에 의해 수행됩니다.

통합 테스트#

히스토리
  • Data Exchange를 사용하여 특정 동작을 요청하는 기능이 GitLab 16.8에서 arkose_labs_signup_data_exchange라는 플래그와 함께 도입됨. 기본적으로 비활성화됨.

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

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

또는 특정 동작을 요청하려면 arkose_labs_signup_data_exchange 기능 플래그를 활성화하고 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에서도 다음 리소스를 제공합니다:

Arkose Protect

GitLab v19.1
원문 보기
요약

Arkose Protect는 GitLab.com에서 사용되며 GitLab Self-Managed 인스턴스는 지원하지 않습니다. GitLab은 악의적인 사용자의 계정 생성을 방지하기 위해 Arkose Protect를 통합합니다.

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

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 포털에서 공개 및 비공개 API 키를 발급받습니다.

  • 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를 비활성화하려면 Rails 콘솔에서 다음 명령을 실행합니다.

ApplicationSetting.current.update(arkose_labs_enabled: false)

Arkose를 비활성화하면 전화번호 및 신용카드 인증도 비활성화됩니다. 신규 사용자는 이메일 주소만 인증하면 됩니다.

Arkose를 비활성화하면 전화번호 및 신용카드 인증도 함께 비활성화된다는 점에 유의하는 것이 중요합니다. 모든 신규 사용자는 이메일 주소만 인증하면 됩니다.

ArkoseLabs 이슈 트리아지 및 디버그#

다음을 사용하여 ArkoseLabs에서 발생한 이슈를 트리아지하고 디버그할 수 있습니다:

Arkose Labs 대시보드 분석#

  • GitLab은 정기적으로 세션 데이터를 Arkose 팀에 전송하며, 이 데이터는 악의적인 사용자의 가입을 방지하기 위한 커스텀 텔테일 적용에 활용됩니다.

  • 정상적으로 작동하는 경우, 10% 미만의 사용자가 high 위험으로 분류되어야 하며 90% 이상의 세션이 인증되어야 합니다.

  • high 위험 사용자 또는 인증된 세션의 비율이 예상 비율과 크게 다를 경우, #ext-gitlab-arkose Slack 채널에 문의하세요.

사용자 세션에 대한 ArkoseLabs Verify API 응답 조회#

사용자의 ArkoseLabs Verify API 응답을 조회하려면, 다음 KQL을 사용하여 GitLab 프로덕션 로그를 쿼리합니다:

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 프로덕션 로그를 쿼리합니다:

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의 상태 서비스가 오류를 반환하여 챌린지를 건너뛰었습니다.

허용 목록#

스테이징 및 프로덕션에서 엔드투엔드 QA 테스트 스위트가 통과될 수 있도록, GITLAB_QA_USER_AGENT허용 목록에 등록했습니다. 각 QA 사용자는 ALLOWLIST 위험 카테고리를 받습니다.

허용 목록 텔테일의 사용 방법은 Arkose::VerifyResponse 클래스에서 확인할 수 있습니다.

피드백 Job#

Arkose의 보호 서비스 개선을 돕기 위해, 우리가 차단한 사용자 목록을 매일 전송하는 일일 백그라운드 job을 생성했습니다. 이 job은 Arkose::BlockedUsersReportWorker 클래스에 의해 수행됩니다.

통합 테스트#

히스토리
  • Data Exchange를 사용하여 특정 동작을 요청하는 기능이 GitLab 16.8에서 arkose_labs_signup_data_exchange라는 플래그와 함께 도입됨. 기본적으로 비활성화됨.

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

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

또는 특정 동작을 요청하려면 arkose_labs_signup_data_exchange 기능 플래그를 활성화하고 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에서도 다음 리소스를 제공합니다: