7장 남용 방지 및 위험 제어
파일 전송은 자동화된 남용(스팸, 스크래핑, 대역폭 고갈)의 흔한 표적입니다. 이 장에서는 사용 편의성과 이어서 전송하기 기능을 지키면서 남용을 제한하는 데 쓰이는 제어 방법을 설명합니다.
7.1 목표
- 정상 사용자에게 번거로운 절차를 요구하지 않으면서 자동화된 남용을 제한합니다.
- 플랫폼의 가용성과 비용 한계(대역폭, 스토리지, CPU)를 보호합니다.
- 이어서 전송하기 유지: 제어 조치가 사용자에게 대용량 전송을 처음부터 다시 시작하도록 강요해서는 안 됩니다(SHOULD).
7.2 설계 원칙(최소화, 설명 가능, 되돌릴 수 있음)
- 최소화: 꼭 필요한 신호만 수집하고, 가능하면 영구 식별자를 사용하지 않습니다.
- 설명 가능: 차단하거나 속도를 제한할 때 사용자가 취할 수 있는 조치와 함께 이유를 확인할 수 있어야 합니다(SHOULD).
- 되돌릴 수 있음: 트래픽 패턴이 바뀌면 완화 조치를 신속하게 조정할 수 있어야 합니다(SHOULD).
7.3 속도 제한 & 할당량
7.3.1 엣지 수준 속도 제한
- 정상적인 병렬 청크 전송은 허용하면서, 요청 폭주에는 IP/AS 기반 제한을 적용합니다.
- 오리진에 트래픽이 한꺼번에 몰리지 않도록 리키 버킷 방식의 제한을 선호합니다.
7.3.2 애플리케이션 할당량 및 상한
- 요금제별 한도(크기, 보관 기간, 다운로드 횟수)를 적용하고, UI에 명확한 안내 메시지를 표시합니다.
- 한도를 초과하면 권한 부여는 반드시 안전하게 거부(fail closed)하면서 다음에 할 수 있는 조치를 분명히 안내해야 합니다(MUST).
7.4 남용 신호 & 완화 조치
- 생성/업로드 시도가 잦거나, 의심스러운 사용자 에이전트가 있거나, 다운로드가 비정상적으로 퍼져 나가는 경우 추가 점검이 이루어질 수 있습니다(MAY).
- 완화 조치로는 제한 강화, 일시적 차단, 위험도가 높은 트래픽에 대한 추가 증명 요구 등이 있을 수 있습니다(MAY).
- 완화 조치는 기밀성을 해쳐서는 안 됩니다(MUST NOT). CEK나 프래그먼트를 서버로 보내도록 요구해서는 절대 안 됩니다.
7.5 관련 클레임 ID
- 공식 매핑은 부록: 클레임 ID를 참조하세요.