안전한 신원 확인을 위한 API 요청 제한

개발자로서, 강력하고 안전한 신원 확인 프로세스의 중요성을 잘 알고 있습니다. 그러나 종종 간과되는 중요한 측면은 API 요청 제한입니다. API 요청 제한 없이는 시스템이 악용, 서비스 거부 공격 및 예상치 못한 비용에 취약해질 수 있습니다. 이 가이드에서는 신원 확인의 맥락에서 API 요청 제한에 대한 심층적인 분석과 효과적인 구현 방법을 제공합니다. 또한 Didit이 이러한 문제를 어떻게 해결하는지 살펴봅니다.

핵심 내용 1 요청 제한은 악의적인 공격 및 과도한 사용으로부터 API 및 인프라를 보호합니다.

핵심 내용 2 효과적인 요청 제한은 예측 가능한 성능과 오류 처리를 제공하여 개발자 경험을 향상시킵니다.

핵심 내용 3 토큰 버킷, 고정 윈도우, 슬라이딩 윈도우와 같은 적절한 요청 제한 전략 선택은 특정 요구 사항 및 트래픽 패턴에 따라 달라집니다.

핵심 내용 4 명확한 개발자와의 소통을 위해 적절한 오류 응답(HTTP 429 너무 많은 요청)이 중요합니다.

신원 확인을 위한 API 요청 제한이 필수적인 이유

신원 확인 API는 민감한 데이터를 처리하며 악의적인 공격의 주요 대상입니다. 악의적인 행위자는 다음을 시도할 수 있습니다:

• 무차별 대입 공격: 다른 자격 증명을 사용하여 신원 확인을 반복적으로 시도합니다.
• 서비스 거부 (DoS): API에 과도한 요청을 보내 합법적인 사용자가 사용할 수 없도록 만듭니다.
• 자격 증명 스터핑: 도난당한 자격 증명을 사용하여 확인을 시도합니다.
• 데이터 스크래핑: API에서 대량의 데이터를 추출하려고 시도합니다.

API 요청 제한 없이는 이러한 공격으로 인해 시스템 성능, 보안이 손상되고 심지어 재정적 손실로 이어질 수 있습니다. 또한 마케팅 캠페인과 같은 합법적인 트래픽의 예상치 못한 급증은 적절하게 관리되지 않으면 리소스에 부담을 줄 수 있습니다.

요청 제한 전략: 개발자 개요

API 요청 제한을 위해 여러 전략을 사용할 수 있으며 각각 장단점이 있습니다:

1. 토큰 버킷

토큰을 담는 버킷을 상상해 보세요. 각 요청은 토큰을 소비합니다. 토큰은 고정된 속도로 보충됩니다. 버킷이 비면 토큰이 다시 채워질 때까지 요청이 거부됩니다. 이 알고리즘은 부드러운 요청 제한을 제공하고 트래픽 급증을 처리할 수 있습니다.

2. 고정 윈도우

시간을 고정된 크기의 윈도우(예: 1분)로 나눕니다. 각 요청은 윈도우 내의 카운터를 증가시킵니다. 카운터가 미리 정의된 제한에 도달하면 윈도우가 재설정될 때까지 요청이 거부됩니다. 구현하기 쉽지만 윈도우 경계에서 트래픽 급증으로 인해 문제가 발생할 수 있습니다.

3. 슬라이딩 윈도우

고정 윈도우보다 개선된 이 접근 방식은 슬라이딩 시간 윈도우에 대한 요청을 고려합니다. 더 정확한 요청 제한을 제공하지만 구현이 더 복잡합니다.

4. 누수 버킷

토큰 버킷과 유사하지만 요청은 도착에 관계없이 일정한 속도로 처리됩니다. 트래픽을 원활하게 하는 데 효과적이지만 대기 시간을 유발할 수 있습니다.

전략 선택은 특정 요구 사항에 따라 달라집니다. 신원 확인의 경우 토큰 버킷 알고리즘은 버스트를 희생하지 않고 처리할 수 있는 능력으로 인해 선호되는 경우가 많습니다.

요청 제한 구현: 주요 고려 사항

API 요청 제한을 구현할 때 다음 사항을 고려하십시오:

• 세분성: 사용자, IP 주소, API 키 또는 조합으로 요청을 제한합니다. 사용자별 요청 제한은 악용 방지에 중요합니다.
• 요청 제한 수준: 다른 API 엔드포인트에 대해 다른 요청 제한을 구현합니다. KYC 확인과 같이 더 민감한 엔드포인트에는 더 엄격한 제한이 있어야 합니다.
• 오류 응답: 요청 제한 및 재시도할 수 있는 시기에 대한 세부 정보를 포함하여 유익한 오류 메시지(HTTP 429 너무 많은 요청)를 반환합니다. Retry-After와 같은 헤더를 포함합니다.
• 모니터링 및 경고: 요청 제한 사용량을 추적하고 잠재적인 악용 또는 예상치 못한 트래픽 패턴에 대한 경고를 설정합니다.
• 동적 조정: 시스템 부하 및 트래픽 패턴에 따라 요청 제한을 동적으로 조정하는 것을 고려하십시오.

오류 응답 예시 (JSON):

{
  "error": "너무 많은 요청",
  "message": "요청 제한을 초과했습니다. 60초 후에 다시 시도하십시오.",
  "retry_after": 60
}

Didit의 API 요청 제한 처리 방식

Didit에서는 신원 확인 API의 보안과 안정성을 최우선으로 생각합니다. API 요청 제한에 대한 다계층 접근 방식을 사용합니다:

• 토큰 버킷 알고리즘: API 키 및 사용자를 기반으로 세분화된 요청 제한이 있는 토큰 버킷 알고리즘을 사용합니다.
• 엔드포인트별 제한: 다른 엔드포인트에는 다른 요청 제한이 있으며, AML 심사와 같이 더 민감한 작업에는 더 엄격한 제한이 있습니다.
• 동적 요청 제한: 시스템은 실시간 트래픽 패턴 및 시스템 부하를 기반으로 요청 제한을 동적으로 조정합니다.
• 강력한 오류 응답: Retry-After 헤더가 있는 명확하고 유익한 오류 메시지(HTTP 429)를 제공합니다.
• 모니터링 및 경고: 요청 제한 사용량을 지속적으로 모니터링하고 잠재적인 악용을 감지하고 대응하기 위한 자동 경고가 있습니다.

Didit의 기본 요청 제한 (예시):

| 엔드포인트 | 요청 제한 (분당 요청 수) | 사용자 레벨 | API 키 레벨 | |---|---|---|---| | /id/verify | 60 | 200 | 1000 | | /aml/screen | 30 | 100 | 500 | | /liveness/check | 120 | 400 | 2000 |

이러한 제한은 변경될 수 있으며 엔터프라이즈 고객을 위해 사용자 정의할 수 있습니다.

시작할 준비가 되셨습니까?

견고한 API 요청 제한으로 신원 확인 시스템을 보호하세요. Didit 플랫폼을 탐색하여 안전하고 안정적이며 확장 가능한 신원 솔루션을 경험해 보세요.

가격 보기 | 문서 읽기 | 데모 요청

FAQ

요청 제한을 초과하면 어떻게 되나요?

HTTP 429 Too Many Requests 오류 응답을 받게 됩니다. 응답에는 요청을 재시도하기 전에 대기해야 하는 시간을 나타내는 Retry-After 헤더가 포함됩니다.

더 높은 요청 제한을 요청할 수 있나요?

예, 엔터프라이즈 고객은 특정 요구 사항에 따라 더 높은 요청 제한을 요청할 수 있습니다. 요구 사항을 논의하려면 영업팀에 문의하십시오.

애플리케이션에서 요청 제한 오류를 처리하는 가장 좋은 방법은 무엇입니까?

지터를 사용하여 지수 백오프를 구현합니다. 이는 재시도하기 전에 시간이 점점 더 오래 걸린다는 의미이며, API에 과부하가 걸리지 않도록 무작위 요소가 추가됩니다.

Didit은 API 사용량을 모니터링하는 데 도움이 되는 도구를 제공합니까?

예, Didit 콘솔은 요청 제한 소비를 포함하여 API 사용량에 대한 자세한 분석을 제공합니다. 또한 잠재적인 문제를 알려주는 경고를 설정할 수도 있습니다.