블로그 · 2026년 8월 4일

블록리스트 전파: 확인된 악용 사례로 전체 네트워크를 차단하는 방법 (KO)

계정을 차단하는 것은 히드라의 머리 하나를 제거하는 것과 같습니다. 세션에서 블록리스트에 추가하면 얼굴, 문서, 전화, 이메일, IP, 장치 등 12가지 항목 유형에 걸쳐 연결된 모든 식별자가 자동으로 추출되므로 다음 계정은 즉시 차단됩니다.

작성자: Didit2026년 8월 4일업데이트됨 2026년 8월 4일

대부분의 악용 방지 프로그램에서 가치가 새는 특정 순간이 있습니다. 바로 승리한 직후입니다.

트래픽 레이어가 계정을 플래그합니다. 분석가가 조사합니다. 증거는 확실하고, 사례는 확인되었으며, 계정은 차단됩니다. 그리고 몇 시간 후, 동일한 운영자가 새 계정으로 다시 돌아옵니다. 왜냐하면 귀하의 제재는 사용자 테이블의 한 행에만 영향을 미쳤기 때문입니다.

Anthropic은 2026년 2월 증류 캠페인에 대한 보고서에서 이와 정확히 동일한 역학을 설명했습니다. 이 캠페인은 "20,000개 이상의 사기성 계정을 동시에 관리"하며 제거될 때마다 교체했습니다. 제거가 병목 현상이 아니었습니다. 재생성이 제거보다 저렴했습니다.

해결책은 계정 대신 식별자에 제재를 가하는 것입니다. Didit의 목록 API는 단일 호출로 이 작업을 수행하는 한 가지 메커니즘을 중심으로 구축되었습니다.

핵심 요약

reference_session_id를 사용하여 블록리스트에 추가하면 Didit이 세션에서 올바른 값(얼굴, 문서, 전화, 이메일, IP 또는 장치)을 자동으로 추출하고 기본 모델을 블록리스트에 추가된 것으로 표시하며 항목을 원본 세션에 다시 연결합니다.
12가지 항목 유형: face, document, phone, email, ip_address, device_fingerprint, wallet_address, bank_account, user, business, country, key.
블록리스트는 시스템에 의해 생성되며 항목 유형별로 하나씩 존재하고 변경 불가능합니다. 사용자가 생성할 수 없으므로 제재가 균일하게 적용됩니다.
항목은 확인 시 즉시 적용됩니다. 항목을 삭제하면 일치가 차단 해제됩니다.
ip_address는 CIDR 범위를 허용하므로 단일 주소 대신 인프라를 블록리스트에 추가할 수 있습니다.
동일한 12가지 유형에 걸친 허용리스트는 신뢰할 수 있는 개발자가 모든 에스컬레이션 경로에서 제외되도록 합니다.

중요한 두 가지 목록 유형

API에는 세 가지 목록 유형이 있으며, 이들 간의 구분은 의도적입니다.

블록리스트는 시스템에 의해 생성되며(항목 유형별로 하나씩) 변경 불가능합니다. 블록리스트를 생성하거나 이름을 바꾸거나 삭제할 수 없습니다. 항목을 추가하고 제거할 수 있습니다. 이러한 제약은 기능입니다. 즉, 조직 전체에서 "블록리스트에 추가됨"이 정확히 하나의 의미를 가지며, 서로 다른 서비스가 일관성 없이 확인하는 네 가지 경쟁적인 얼굴 블록리스트가 존재할 수 없다는 것을 의미합니다.

허용리스트는 사용자가 생성할 수 있습니다. 알려진 양호한 장치, 주소 범위, 사업체 및 사용자가 여기에 포함됩니다.

사용자 지정 목록은 그 외 모든 것(자체 분류, 감시 그룹, 검토 코호트)을 위한 것입니다.

# 얼굴 블록리스트 찾기
curl -X GET 'https://verification.didit.me/v3/lists/?list_type=blocklist&entry_type=face' \
  -H 'x-api-key: YOUR_API_KEY'

중요한 메커니즘

다음은 무언가를 블록리스트에 추가하는 일반적인 방법이며, 거의 모든 실제 상황에서 잘못된 방법입니다.

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "value": "203.0.113.44" }'

이것은 하나의 주소를 블록리스트에 추가합니다. 한편, 조사 중인 세션에는 얼굴, 문서 번호, 전화, 이메일 및 장치 지문도 포함되어 있었습니다. 이 모든 것은 운영자가 다시 돌아오기 전에 교체해야 하는 식별자입니다.

더 나은 호출:

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "reference_session_id": "a7f3...c19" }'

reference_session_id를 전달하면 Didit이 세션에서 해당 목록의 항목 유형에 맞는 올바른 값을 자동으로 추출하고 기본 모델을 블록리스트에 추가된 것으로 표시하며 항목을 세션에 다시 연결하여 콘솔에서 출처를 확인할 수 있도록 합니다.

이로 인해 세 가지가 발생하며, 이 세 가지 모두 운영상 중요합니다.

수동 추출 없음. 분석가는 화면에서 장치 지문을 읽고 다시 입력하지 않습니다. 제재 데이터의 전사 오류는 조용한 실패입니다. 차단이 단순히 작동하지 않고 아무도 알지 못합니다.

출처가 보존됩니다. 모든 항목은 이를 정당화한 세션에 다시 연결됩니다. 4개월 후에 누군가가 이 장치가 왜 차단되었는지 물으면, 그 답은 한 번의 클릭으로 얻을 수 있으며 고고학적 조사 프로젝트가 아닙니다.

제재는 반복 가능합니다. 각 항목 유형 블록리스트에 대해 동일한 호출을 하면 세션의 전체 식별자 표면을 커버합니다.

세션에 동일한 유형의 여러 인스턴스가 포함된 경우, 모호성을 해소하기 위해 value와 함께 reference_session_id를 전달합니다.

확인 세션 외부에서도 제재를 가할 수 있습니다. reference_object_uuid와 metadata.reference_type(transaction, vendor_user 또는 vendor_business)을 함께 사용하면 거래 또는 공급업체 사용자 또는 비즈니스에서 블록리스트에 추가하고 원본에 대한 동일한 링크를 유지합니다.

12가지 항목 유형

항목 유형	차단 대상	비고
`face`	개인	얼굴 업로드를 통해 직접 로드 가능
`document`	자격 증명
`phone`	전화번호	E.164로 자동 정규화
`email`	이메일 주소
`ip_address`	주소 또는 범위	CIDR 허용, 예: `10.0.0.0/8`
`device_fingerprint`	장치	최소 8자 영숫자
`wallet_address`	온체인 주소
`bank_account`	계좌
`user`	사용자 기록
`business`	사업체
`country`	관할 지역
`key`	사용자 지정 키

이 문제에 대해 두 가지를 언급할 가치가 있습니다.

ip_address는 CIDR 범위를 허용합니다. 203.0.113.0/24를 블록리스트에 추가하면 단일 주소가 아닌 인프라가 차단됩니다. 렌트된 서브넷에서 파밍 작업이 실행될 때, 이것은 확장 가능한 제재와 두더지 잡기식 제재의 차이입니다. 신중하게 사용하십시오. 범위는 실제 사용자도 포함하며, 너무 광범위한 범위는 국가의 이동통신사를 조용히 차단하는 방법입니다.

face는 직접 업로드를 지원합니다. 이미지는 있지만 세션이 없는 경우 직접 로드합니다.

curl -X POST 'https://verification.didit.me/v3/lists/{list_uuid}/entries/face-upload/' \
  -H 'x-api-key: YOUR_API_KEY' \
  -H 'Content-Type: application/json' \
  -d '{ "image": "<base64-encoded image>" }'

Didit은 생체 인식을 추출합니다. 그 후부터 해당 얼굴은 모든 확인 시점에 스크리닝됩니다.

항목이 등록된 후 발생하는 일

시스템 블록리스트에 추가하면 다음 일치가 확인 시 즉시 차단됩니다. 전파 지연이나 배치 작업이 없습니다.

다음 확인 시 제재는 경고로 표시됩니다.

FACE_IN_BLOCKLIST — 확정적 일치, 확인 거부. POSSIBLE_FACE_IN_BLOCKLIST는 하드 임계값 미만의 경계 일치이며, 거부 대신 검토로 라우팅되어야 합니다.
IP_ADDRESS_IN_BLOCKLIST / DEVICE_FINGERPRINT_IN_BLOCKLIST — 네트워크 및 장치 히트.

얼굴 검색에서 블록리스트 일치는 status를 "Declined"로 설정하는 유일한 요소입니다. 응답의 모든 일치에는 is_blocklisted도 포함되어 있으므로 조사를 통해 클러스터의 어떤 부분이 이미 제재를 받고 있고 어떤 부분이 아직 활성 상태인지 즉시 알 수 있습니다.

제거는 대칭적입니다. 항목을 삭제하면 일치하는 엔터티가 차단 해제됩니다. 제재는 의도적으로 되돌릴 수 있습니다. 이는 과도한 제재가 실제 위험이며 깨끗한 복귀 경로가 필요하기 때문에 중요합니다.

curl -X DELETE 'https://verification.didit.me/v3/lists/{list_uuid}/entries/{entry_uuid}/' \
  -H 'x-api-key: YOUR_API_KEY'

허용리스트: 원하는 개발자 보호

에스컬레이션만 하는 제재는 결국 제품을 질식시킵니다. 동일한 12가지 항목 유형은 허용리스트를 지원하며, 이는 압력 밸브입니다.

디자인 파트너의 사무실 IP 범위를 허용리스트에 추가합니다. 기업 고객 엔지니어링 팀의 장치를 허용리스트에 추가합니다. 확인된 사업체를 허용리스트에 추가하여 사용자가 에스컬레이션 경로에 도달하지 않도록 합니다. IP_ADDRESS_IN_ALLOWLIST 및 DEVICE_FINGERPRINT_IN_ALLOWLIST는 일치가 발생할 때 실행되므로 면제가 적용되었는지 가정하는 대신 확인할 수 있습니다.

이것이 공격적인 제재를 견딜 수 있게 하는 메커니즘입니다. 알려진 양호한 인구가 명시적으로 제외되어 있기 때문에 알 수 없는 인프라에 대한 엄격한 정책을 감당할 수 있습니다.

처리할 가치가 있는 오류

400 — 값이 항목 유형의 유효성 검사기를 통과하지 못했거나, 작업에 대해 list_type이 잘못되었거나(예: 얼굴이 아닌 목록에 대한 얼굴 업로드), reference_session_id에 요청된 유형의 데이터가 없습니다. 마지막 경우는 일반적이고 양호합니다. 모든 세션이 모든 식별자를 캡처하는 것은 아닙니다.
403 — {"detail": "이 작업을 수행할 권한이 없습니다."}

"세션에 해당 유형의 데이터가 없음"으로 인한 400 오류는 모든 항목 유형 블록리스트에 걸쳐 세션을 반복할 때 예상되는 것입니다. 이를 실패가 아닌 건너뛰기로 처리하십시오.

실제 제재 흐름

분석가가 계정 acct_8842에 대한 악용을 확인했습니다.

먼저 클러스터를 해결합니다. 세션의 얼굴에 대한 얼굴 검색은 12개의 계정을 반환하고, 장치 및 IP 상관 관계는 추가로 12개를 가져옵니다. 해결 전의 제재는 하나의 계정을 차단하고 운영자에게 경고합니다.
확인된 세션에서 블록리스트에 추가 — 얼굴, 장치, IP, 이메일, 전화 및 문서 블록리스트에 대해 reference_session_id를 사용합니다. 6번의 호출, 수동 추출 없음, 전체 출처.
범위를 고려합니다. 네트워크 증거가 렌트된 인프라를 가리킨다면, CIDR 항목이 서브넷을 커버합니다. 먼저 그곳에 무엇이 있는지 확인하십시오.
자체 정책에 따라 클러스터에 조치 — 이미 식별한 계정은 스스로 차단 해제되지 않습니다.
제재를 확인합니다. 얼굴 검색을 다시 실행합니다. 이제 일치 항목에 is_blocklisted: true가 표시되어야 합니다.
재생성 시도를 기다립니다. 해당 얼굴, 장치 또는 서브넷에서 생성된 다음 계정은 3주 후에 트래픽에 나타나는 대신 확인 시 거부됩니다.

6단계가 핵심입니다. 운영자가 돌아오는 데 드는 비용은 더 이상 "새 이메일 주소 만들기"가 아닙니다. "새 하드웨어, 새 네트워크, 그리고 새 사람을 확보하기"입니다.

사용 사례

AI API 플랫폼은 확인된 증류 또는 악용 사례를 운영자가 연결한 모든 식별자에 대한 제재로 전환합니다.

시험 및 신용 악용은 동일한 장치와 얼굴이 새로운 무료 할당을 위해 계속 돌아오는 경우입니다.

마켓플레이스는 제거된 판매자가 새로운 비즈니스 이름으로 재등록하는 것을 차단합니다.

iGaming은 자체 배제를 시행합니다. 돌아온 배제된 플레이어는 규제 실패이며, 얼굴 수준의 제재만이 유일한 신뢰할 수 있는 통제입니다.

자주 묻는 질문

나만의 블록리스트를 만들 수 있나요?

아니요. 블록리스트는 시스템에 의해 생성되며 항목 유형별로 하나씩 존재하고 변경 불가능합니다. 항목을 추가하고 제거할 수 있습니다. 허용리스트 및 사용자 지정 목록은 자유롭게 만들 수 있습니다. 이러한 제약은 "블록리스트에 추가됨"이 모든 곳에서 하나의 의미를 가지도록 합니다.

항목이 적용되는 데 얼마나 걸리나요?

다음 확인 시 즉시 적용됩니다.

실수로 블록리스트에 추가하면 어떻게 되나요?

항목을 삭제하면 엔터티가 차단 해제됩니다. 이것이 출처가 중요한 이유입니다. 세션에서 생성된 모든 항목은 세션에 다시 연결되므로 항목을 제거하기 전에 어떤 목적으로 사용되었는지 감사할 수 있습니다.

IP 범위 블록리스트가 해당 범위의 합법적인 사용자에게 영향을 미치나요?

예, 그것이 위험입니다. CIDR 항목은 그 안에 있는 모든 것을 차단합니다. 증거가 전용 인프라를 가리킬 때는 범위를 사용하고, 그렇지 않으면 단일 주소를 사용하며, 알려진 양호한 범위를 먼저 허용리스트에 추가하십시오.

확인 세션이 아닌 다른 것에서 블록리스트에 추가할 수 있나요?

예. reference_object_uuid와 metadata.reference_type(transaction, vendor_user 또는 vendor_business)을 함께 사용하면 거래 및 공급업체 사용자 또는 비즈니스를 커버합니다.

이것이 모델 추출을 막나요?

아니요. 특정 알려진 행위자가 제재를 가한 식별자를 통해 다시 진입하는 것을 막고, 재생성 비용을 높입니다. 추출을 처음부터 감지하는 것은 트래픽 레이어의 역할이며, 추출이 산출하는 것을 제한하는 것은 모델 레이어의 역할입니다. 이것은 3계층 방어의 제재 팔이지, 다른 두 계층을 대체하는 것이 아닙니다.

시작할 준비가 되셨나요?

목록 API는 모든 Didit 계정에서 사용할 수 있습니다.

문서 읽기 — 목록 API 개요 및 IP 및 장치 경고 카탈로그.
제품 보기 — 사용자 확인.
가격 확인 — 공개 가격, 성공당 지불, 최소 금액 없음.
무료 시작 — business.didit.me, 한 달에 500건의 KYC 확인 무료.

계속 읽기