Open Feed Network (Candor Network)의 설립자인 Ronny Cruz Alvarez 작성. 1인 창업자, 하나의 프로덕션 플랫폼, 그리고 당신에 대해 거의 아무것도 알지 않도록 의도적으로 설계된 등록 흐름(registration flow).

내가 스스로를 위해 만든 문제

Candor의 등록 과정은 이메일을 수집하지 않습니다. 전화번호도 없습니다. CAPTCHA 계정도, OAuth 신원(identity)도 없으며, 대조하여 검증할 대상이 없기 때문에 검증할 것도 없습니다. 앱을 설치하고, 사용자 이름(username)을 선택하고, PIN을 설정하면 브라우저가 사용자의 기기에서 ECDSA P-256 키 쌍(keypair)을 생성합니다. 서버는 정확히 두 가지, 즉 사용자 이름과 공개 키(public key)만을 받습니다. 12개의 시드 단어(seed words)와 복구 파일(recovery file)은 사용자에게 남습니다. 이것이 가입의 전부입니다.

나는 의도적으로 그렇게 만들었습니다. 제로-PII(Zero-PII) 등록은 유출될 이메일 데이터베이스도, 소환될 전화번호 목록도, 판매할 신원 그래프(identity graph)도 없음을 의미합니다. 당신의 목소리가 나를 신뢰하는 것에 의존해서는 안 된다는 것이 플랫폼의 전체 논제(thesis)인 만큼, 이는 올바른 설계입니다.

또한 스팸 방어 관점에서는 내가 스스로에게 안겨준 악몽이기도 합니다. 업계가 가입 심사를 위해 의존하는 모든 신호들 — 일회용 이메일 도메인, 이메일 평판(email reputation), 검증 왕복(verification round-trips) — 은 이메일이 존재한다는 것을 전제로 합니다. 내 방식에는 이메일이 없습니다. 그리고 이 흐름은 설계상 매우 빠르며, 이는 스크립트 또한 빠를 수 있음을 의미합니다. 지난 금요일, 한 AI 코드 리뷰는 이를 직설적으로 지적했습니다: 봇이 등록 엔드포인트(registration endpoint)를 루프 돌며 5만 개의 계정을 생성하고, 생성 비용이 거의 들지 않는 신원들로 피드(feed)를 도배하는 것을 막을 수 있는 것이 아무것도 없다고 말입니다.

그 리뷰는 옳았습니다. 아무것도 막지 못했습니다.

아이러니하게도 나는 해결책을 판매하고 있습니다

그 전주에, 나는 바로 이런 종류의 파도에 시달리는 Fediverse 인스턴스들을 위한 등록 심사 서비스인 Sentinel Signup을 출시했습니다. IP 및 도메인 평판, 서브넷 속도(subnet velocity), 타이밍 패턴, 콘텐츠 분석 등 6개의 계층으로 구성되어 있습니다. 가짜 승인 요청에 허덕이는 Mastodon 관리자들을 위해 만들어졌습니다.

정작 내 플랫폼은 그것을 사용하고 있지 않았습니다. 구두 수선공의 아이들이 늘 그렇듯, 맨발인 상태였습니다.

더 최악인 것은, 제 플랫폼이 그것을 _사용할 수 없었다_는 점입니다. 스크리닝 API (screening API)는 모든 요청에 이메일을 요구했는데, 이는 제가 상상한 모든 고객이 이메일을 가지고 있다고 가정했기 때문입니다. 제가 아는 가장 프라이버시를 보호하는 방식인 저의 가입 흐름 (registration flow)은 구조적으로 제 자신의 보안 제품으로부터 차단되었습니다. 그리고 엔진은 이메일 요구 그 이상을 수행했습니다. 이메일이 없으면 +30점의 "유효하지 않은 이메일 (invalid email)" 페널티를 부여했습니다. 저의 정직한 사용자들을 저의 필터에 통과시키면, 단 한 명도 빠짐없이 의심스러운 상태로 시작하게 됩니다. 프라이버시 기능이 사기 신호 (fraud signal)로 읽힌 것입니다.

이 점은 깊이 생각해 볼 가치가 있습니다. 왜냐하면 이것이 제 코드의 기이한 특성 때문이 아니기 때문입니다. 이는 남용 방지 시스템 (anti-abuse systems)이 프라이버시를 존중하는 플랫폼들이 의도적으로 수집하지 않는 신원 신호 (identity signals)를 가정할 때 업계 전반에서 발생하는 현상입니다. 스팸 방어의 기본 태도는 사용자에 대해 아는 것이 적을수록 그들을 더 의심스럽게 만드는 것입니다. 만약 우리가 프라이버시를 보호하는 플랫폼이 존재하기를 원한다면, 보안 도구 (security tooling)는 프라이버시를 지킨다는 이유로 그들을 처벌하는 것을 멈춰야 합니다.

해결책: 부재는 형식이 잘못된 것이 아니다

변경 사항은 작았지만 철학적으로 중요했습니다. 엔진은 이전에는 혼동했던 두 가지를 이제 구분합니다:

• 이메일이 제공되었으나 형식이 잘못된 경우 (Email provided but malformed) — 여전히 페널티를 부여합니다. 누군가 이메일 필드에 쓰레기 데이터를 보냈다면, 그것은 실제 신호입니다.
• 이메일이 전혀 제공되지 않은 경우 (Email not provided at all) — 중립적인 사실로 기록되며, 가중치는 0입니다. 개인정보(PII)가 없는 플랫폼은 보낼 데이터가 없으며, 그 사실에 대해 정직하게 구는 것은 사용자에게 아무런 비용을 발생시키지 않습니다.

이메일이 존재할 때 실행되는 모든 검사(일회용 도메인 목록, 일회용 패턴 매칭 등)는 이전과 정확히 동일하게 실행됩니다. 테스트 스위트 (test suite)는 두 방향 모두를 증명합니다: 부재에 대한 페널티는 없으며, 쓰레기 데이터에 대한 완화도 없습니다.

이를 통해 저의 가입 프로세스는 마침내 실제로 존재하는 것들—사용자 이름, 실제 클라이언트 IP (CDN의 전달된 헤더로부터 가져온 것 — 서비스 자체는 원시 연결을 절대 보지 않음), 사용자 에이전트 (user agent), 그리고 시간—만을 사용하여 제 제품에 의해 스크리닝될 수 있게 되었습니다. 이메일도 없고, 분석을 오염시키는 합성 플레이스홀더 (synthetic placeholder)도 없습니다. 실제하는 것은 분석되고, 존재하지 않는 것은 조작되지 않습니다.

장애가 발생하기 전까지는 아무도 묻지 않는 태도의 문제

화면을 가입 처리기 (registration handler)에 연결하면서, 대부분의 통합 과정에서 건너뛰는 결정적인 문제에 직면했습니다. 바로 스크리닝 (screening) 자체가 실패할 경우 어떻게 할 것인가 하는 문제입니다.

저의 Mastodon-admin 고객들에게 그 답은 '큐로 실패 처리 (fail-to-queue)'입니다. 즉, 스크리닝 오류가 발생하면 신청자를 관리자의 승인 대기 큐 (approval queue)로 보내고, 그곳에서 관리자가 결정하도록 하는 것입니다. 조용히 승인하거나 조용히 거절하는 일은 결코 없습니다.

하지만 저의 가입 흐름에는 큐가 없습니다. 설계상 인간과 계정 사이에는 관리자가 존재하지 않습니다. 따라서 여기서 '큐로 실패 처리'는 의미가 없으며, 교과서적인 두 가지 옵션은 모두 잘못되었습니다. '실패 시 차단 (fail-closed)' 방식은 단 2초간의 스크리닝 오류만으로도 실제 사용자가 플랫폼에 가입하는 것을 막아버리게 됩니다. 반면, 침묵 속에서 '실패 시 허용 (fail-open)'하는 방식은 봇들이 쏟아져 들어와도 아무도 모르게 됩니다.

제가 배포한 태도는 다음과 같습니다: 확정적인 차단 판정 (hard block verdict)이 내려졌을 때만 차단하고, 플래그 (flag)가 지정되거나 어떤 오류가 발생하더라도 — 소란스럽게 — 허용하십시오. 모든 플래그가 지정된 가입과 모든 스크리닝 실패는 그 이유와 함께 로그 (logs)에 기록됩니다. 장애 발생 중에 빠져나간 급증 사례도 몇 분 내에 가시화되고 원인을 파악할 수 있습니다. 반면 의존성 오류 (dependency failure)로 인해 가입이 막힌 인간 사용자는 영원히 보이지 않을 것이며, 그들은 그냥 떠나버릴 것입니다. 이 두 가지 실패 비용을 비교했을 때, 선택의 여지는 명확합니다.

이 게이트 (gate)가 봇 시나리오에 미친 영향

배포 후, 저는 제 실제 운영 서버를 대상으로 공격을 실행했습니다. 먼저, 하나의 정상적인 가입을 시도했습니다. 깨끗하게 통과되었고, 토큰 (token)이 발행되었으며, 이전과 구별할 수 없었습니다. 그다음, 5만 계정 시나리오의 축소 버전을 실행했습니다. 단일 IP에서 매번 새로운 키 쌍 (keypair)을 사용하여 빠르게 가입을 시도하는 방식입니다.

로그에서 확인한 단계적 에스컬레이션 (escalation ladder)은 다음과 같습니다:

• 가입 1~2번: 통과.
• 가입 3번: 플래그 지정 (flagged) — 하나의 IP에서 다수의 계정 생성, 높은 서브넷 속도 (high subnet velocity) — 허용되었으며 로그에 기록됨.
• 가입 4번: 차단 (blocked) — 속도 임계값 (velocity threshold) 초과.
• 가입 5번부터 15번까지: 즉시 차단 (blocked instantly) — "이전에 차단된 IP". 게이트가 기억하고 있었습니다. 이후의 모든 시도는 재점수화 (re-scored)조차 되지 않은 채 종료되었습니다.

5만 개의 계정을 원했던 봇은 4개만을 얻었습니다. 그리고 가장 먼저 가입한 인간 사용자는 아무 일도 일어나지 않았다는 사실을 전혀 눈치채지 못했습니다.

정직한 한계점

• 제 테스트는 단일 IP로 진행되었습니다. 실제 적대자는 주거용 프록시(residential proxies)를 순환하며 사용하므로, 동일 IP 속도(same-IP velocity)로는 이를 약화시키기 어렵습니다. 서브넷 속도(Subnet velocity)는 게으른 버전에게는 효과적이지만, 잘 분산된 봇넷(botnet)은 더 어려운 문제입니다. 제가 이것으로 모든 것이 해결된다고 주장하는 것은 아닙니다. 네트워크당 키 쌍 발행 제한(Rate-limiting keypair minting per network)은 하한선일 뿐, 상한선이 아닙니다.
• 남아있는 신호들은 설계상 희박합니다. 사용자 이름(Username), IP, 사용자 에이전트(user agent), 타이밍(timing) — 이것이 바로 신원 정보 수집을 거부할 때의 전체 특징 집합(feature set)입니다. 저는 이 교환(trade) 가치가 충분하다고 생각하지만, 그것은 거래이며, 이 네 가지 필드로 이메일 평판(email reputation)을 완전히 대체할 수 있다고 말하는 사람은 무언가를 팔고 있는 것입니다.
• 임계값은 비공개로 유지됩니다. 저는 거부 메시지가 공격자들에게 무엇이 그들을 막았는지 절대 가르쳐서는 안 된다는 점에 대해 이전에 글을 쓴 적이 있습니다. 동일한 규칙이 여기에 적용됩니다. 차단된 가입 시에는 어느 계층(layer)에서 작동했는지, 또는 몇 번째 카운트에서 문제가 발생했는지 알려주는 것이 아니라 '일시적으로 이용할 수 없음'이라고만 표시합니다. 이것은 의도적인 것이며, 이 글은 방어의 모양을 알려줄 뿐 그 숫자를 알려주지는 않는다는 의미입니다.
• 이것은 운영된 지 며칠 된 단일 플랫폼입니다. 증거는 저 자신의 서버에서 날짜가 찍힌 로그(logs)이며, 플릿 규모의 연구(fleet-scale study)가 아닙니다.

왜 자체 사용(dogfooding)이 핵심이었나

Sentinel Signup이 Mastodon 관리자들에게 제시한 주장은 '우리 자신을 위해 구축되었고, 여러분에게도 이용 가능하다'는 것이었습니다. 즉, 모듈들은 플랫폼 자체의 방어 시스템에서 추출된 것입니다. 이번 주 기준으로 이는 가장 완전한 의미로 사실입니다. 고객이 얻게 되는 동일한 심사 엔진(screening engine), 동일한 API, 동일한 테넌트 시스템(tenant system)이 저 자신의 가입 엔드포인트와 다음 발행 실행 사이에 존재합니다. 고객 제로는 바로 저 자신입니다. 이것이 고장 날 때, 가장 먼저 고장 나는 것도 저이기 때문에 — 이것이야말로 안전 제품을 정직하게 유지하는 정확한 방식입니다.

만약 여러분이 가입 프로세스 (registration flow)를 운영하고 있다면 — 특히 업계에서 요구하는 수준보다 적은 정보를 수집하는 플랫폼이라면 — Sentinel Signup은 signup.candortheopenfeednetwork.com에서 베타 기간 동안 무료로 제공됩니다. 또한, 여기서 설명한 개인 식별 정보(PII) 제로 지원은 모든 테넌트 (tenant)에 대해 활성화되어 있습니다. 만약 저의 실패 포스처 (failure posture)가 잘못되었다고 생각하신다면, 특히 그 의견을 듣고 싶습니다: tips@candortheopenfeednetwork.com. 모든 질문에는 제가 직접 답변합니다.