API 보안 및 요청 필터링
1) 왜 필요한가
API - 외부 및 내부 플랫폼 경계. 요청의 인증, 인증, 검증 또는 정규화 오류는 취약점 (BOLA/IDOR, 주입, SSRF, 대규모 열거, 자원 소진) 의 악용으로 바뀝니다. 목적: 측정 가능한 SLO 및 위험 제어를 통해 경계에서 비즈니스 규칙까지 심층적 인 방어를 만듭니다.
2) API 인벤토리 및 분류
API 디렉토리: 모든 서비스/엔드 포인트, 소유자, 버전, 클라이언트 유형 (웹, 모바일, 파트너), 모드 (공개/파트너/내부), PII/재무 데이터 등록.
비판: 높음 (금융 거래/승인), 중간 (프로필 읽기), 낮음 (공개 디렉토리).
공격 표면: REST, GraphQL, gRPC, WebSocket, 웹 후크.
상태: 제안/준비/실험, 정책 해제, 토큰/키 수명.
그림자/폐기 된 API: 디렉토리와 비교하여 가장 많은 로그, eBPF/서비스 메시 원격 측정을 통한 탐지.
3) 위협 모델 (브리핑)
식별: 토큰 하이재킹, 세션 커밋, MitM, 재생.
승인: BOLA/IDOR, 수평/수직 에스컬레이션.
입력: 주입 (SQL/NoSQL/TP), 템플릿/직렬화, 경로 순회, 헤더.
교통: DDoS/L7 홍수, 느린 요청, 팬텀 배상.
통합: 안전하지 않은 웹 후크, IM 매개 변수를 통한 SSRF, 파일/스캔 다운로드.
논리: 보너스 남용, 경주, 불일치 불일치.
4) 기본 안전 표준 (최소)
1. TLS 1. 어디에서나 2 +; HSTS; 약한 암호는 비활성화됩니다.
2. 인증: 클라이언트, mSL/또는 HMAC 용 OAuth2/OIDC-서비스 간 서비스.
3. 승인: 중앙 집중식 PDP (RBAC/ABAC), 객체 수준 검사 (BOLA).
4. 유효성 검사: 엄격한 체계 (OpenAPI/JSON Schema/Protoguy), 추가 필드가없는 고장.
5. 한계: 요율/할당량 + 버스트, 클라이언트 당/IP 당/토큰 당.
6. 쓰기 작업, 반복/레이스에 대한 보호에 대한 이데올로기.
7. WAF/게이트웨이 필터링: 경로/헤더 정규화, 거부 목록, 페이로드 방지 패턴 블록.
8. 비밀: KMS/Vault, 키/인증서 회전, 누출 제어.
9. 관찰 가능성: 추적, 보안 감사 로그 (누가/무엇을/언제/결과), 경고.
10. 절차: 플레이 북 사건, 테스트 사례 및 정기적 인 펜 테스트/DAST.
5) 인증 및 토큰 관리
OAuth2/OIDC: 단기 액세스 토큰, OIDC에 따라 엄격하게 새로 고침; 잠재 고객/발급자/exp는 게이트웨이에서 확인됩니다.
JWT: RS256/ES256; 최소 조개 세트; 'nbf/exp/aud' 가 필요합니다. PII 스토리지 금지. JWKS를 통한 주요 회전.
DPoP/PoP: 재생/하이재킹 위험을 줄이기 위해 클라이언트 키에 바인드 토큰.
내부 시스템 및 신뢰할 수있는 파트너를위한 mTLS (CN/SAN 자격, CRL/OCSP).
HMAC (서명): 결정 론적 정식 화 (방법 + 경로 + 타임 스탬프 + nonce + body-hash); 유효한 시간 창 (λ30).
브라우저 세션: SameSite = 엄격한/lax, HttpOnly, Secure; CSRF 보호 (이중 제출/상태 토큰).
클라이언트 스토리지: 모바일-보안 스토리지 (Keychain/Keystore), 디버그 보호, 고정 인증서.
6) 승인 (BOLA 우선)
객체 수준: 각 작업은 특정 리소스 (리소스 소유자/범위/속성) 에 대한 권리를 확인합니다.
RBAC/ABAC: 역할 + 속성 (국가, 세그먼트, 위험 제한, KYC 수준)
정책: 기본적으로 거부; 명시 적 허용; 부정적인 경우에 대한 정책 버전 테스트.
의사 결정 캐시: 변화하는 역할/세그먼트에서 적응 형 TTL + 장애.
7) 요청 필터링 및 정규화 (게이트웨이/WAF)
정규화: 반복 슬래시 압축, 금지 '../', 한 번 디코딩, 공간 트리밍/제로 바이트.
헤더: 허용 목록 ('호스트', '컨텐츠 유형', '수락', '승인', '날짜', 'Idempotency-Key', 필요한 추적 헤더).
방법: 신체가없는 'GET/HEAD'; 'POST/PUT/PATCH' -유형 '응용 프로그램/json' 또는 엄격하게 허용됩니다.
차원: 최대 본체, 최대 헤더, 최대 경로; 조기 거부 413/431.
파일: 파일 유효성 검사기, 바이러스 백신/샌드 박스, 활성 콘텐츠 금지, 이미지 재활용/위생.
GPS 리디렉션/fetchi: SSRF 블록 (개인 범위/메타 데이터 IP, 스키마 만 'https', 허용 목록 도메인 거부).
SQL/NoSQL 패턴: WAF 규칙 세트를 통한 주입 서명 + 쿼리의 서버 매개 변수화.
헤더 정책 (의사 형식)
deny_headers: ["X-Forwarded-Proto","X-Original-URL","Proxy-Connection","Destination"]
require_headers: ["Authorization" (для protected), "Content-Type" (для write)]
strip_duplicates: true max_header_count: 32 max_header_size: 16KB8) 한계, 할당량 및 안티 봇 보호
속도 제한: 토큰 버킷/누출 버킷; 레벨 - IP 당, API 키 당, 사용자 당, org당.
인용문: 매일/매월, 쓰기/광범위한 방법으로 분리됩니다.
적응성: 이상 현상 (갑작스런 버스트/자격 증명 스터핑) 에서 동적 조임.
Slow-loris/slow-POST: 읽기/유지 타임 아웃, 동시 연결 제한.
안티 봇: 장치 지문, 행동 증명, 위험 증가를위한 작업 증명/캡차, 원환 체/프록시 네트워크 목록.
IP 제어: 지오/ASN 필터, "더러운" 서브넷 목록 거부, 파트너/관리 패널 목록 허용
9) 입력 데이터 및 회로의 검증
실패: 계획에 실패한 모든 것은 400입니다. 여분의 필드-거부하십시오
유형/범위: 숫자, 날짜 (UTC/ISO-8601), enum 값, 선 길이, 리셉스.
JSON 품질: 최대 중첩, 큰 배열/키 금지, 표준 순서 (선택 사항).
비즈니스 검증: 'Idempotency-Key' 에 따른 demotency; 사기 방지 규칙 (작동 빈도 제한, 금액 한도).
GraphQL: 깊이/복잡성 제한, 허용 목록 쿼리, 필드 당 권한 부여.
gRPC: 엄격한 프로토 타입 체계, 필수 필드, 메시지 크기 제한.
10) 웹 후크 및 외부 통화
서명: 타임 스탬프/노스가있는 HMAC; 처리 전 검증; 창 +/- 5 분
배송: 지수 일시 정지 및 지터가있는 Retrai; 최대 시도; 이벤트 ID 중복 제거
공급 업체 IP는 별도의 하위 도메인/경로를 허용합니다. 최소 호스팅 스택.
답변: 성공적인 내부 기록 후에 만 2xx; 그렇지 않으면 명확한 코드를 가진 4xx/5xx.
발신 SSRF 제어: 콜백 IM-허용 목록 인 경우 개인 주소를 거부하십시오.
11) 암호화 및 비밀 관리
채널에서: TLS 1. 2+/1. 3, 고정, 엄격한 암호 정책.
혼자: DB/객체 스토리지 암호화, PII/재무 데이터를위한 별도의 키.
KMS/Vault: 중앙 집중식 비밀 저장, 짧은 TTL, 자동 회전.
키 및 인증서: 환경에 따라 분리됩니다. 문제 감사; 로그에 대한 출력 금지.
토큰 내성: 오프라인 취소 목록, 짧은 'exp'.
12) 관찰 가능성, 감사 및 응답
보안 로그: 인증 시도/성공, 인증 실패, 요율 제한 이벤트, 역할/제한 변경.
추적: 상관 ID 엔드-투-엔드; 외부 통화 추적.
지표: RPS, P95/P99 대기 시간, 코드 별 오류율, 401/403/429의 공유, 적중률 제한, 이상.
경고: 401/403/429 스파이크, 5xx 성장, 빈번한 dempotency 충돌, QL- 복잡도 그래프의 급격한 편차.
플레이 북: 키/토큰을 차단하고 규칙을 빠르게 롤백하며 거부 목록을 예열하여 서비스 소유자에게 알립니다.
법의학: 논란의 여지가있는 페이로드 보존 (안전한 PII 편집 포함), 격리 된 스탠드에서 재생.
13) 클라이언트에 대한 오류 및 답변
균일 한 오류 형식 (코드, 메시지, 추적 ID, 범주).
누출 없음: SQL, 테이블 이름, 내부 idies를 공개하지 마십시오. "왜 안돼" 대신 403입니다.
코드: 400 (유효성 검사), 401 (인증 없음), 403 (권한 없음), 404 (마스크 존재), 405/406, 413/429, 500/503.
리셉션-힌트: 계정 429- '리셉션-애프터'; dempotency-동일한 키로 반복에 대한 조언.
14) 건축 패턴
제로 트러스트: mSL, 모든 서비스 간의 명시 적 승인, 최소한의 권한.
게이트웨이 API + WAF + 서비스 메쉬: 업무 분리 - 경계, L7 정책, 내부 인증.
Canary/Blue-Green: 감독과 함께 단계적으로 새로운 여과 규칙을 시행하십시오.
실패: 중요한 쓰기의 경우 잘못된 작동을 허용하는 것보다 안전하게 거부하는 것이 좋습니다.
역압: 대기열/버퍼, 회로 차단기, 타임 아웃/예산.
15) 실제 규칙의 예 (의사 설정)
15. 1 제한 경로 및 방법
/api/v1/payments:
allow_methods: [POST, GET]
auth: oauth2_required body:
content_type: application/json max_size: 256KB15. 2 이념성
require_header: Idempotency-Key (UUIDv4)
store: redis:ttl=24h on_duplicate: return_previous_result15. 3 요청 서명 (HMAC)
signature:
scheme: "HMAC-SHA256"
required_headers: ["X-Signature","X-Timestamp","X-Nonce"]
allowed_drift: 300s string_to_sign: METHOD + "\n" + PATH + "\n" + SHA256(body) + "\n" + X-Timestamp + "\n" + X-Nonce15. 4 SSRF 보호
outbound_http:
allowlist_domains: ["kyc. partner. com","psp. example. net"]
block_private_ip: true require_https: true15. 5 그래프 QL 한계
graphql:
max_depth: 8 max_complexity: 500 allowlisted_operations_only: true16) iGaming/Finance의 세부 사항
세그먼트 제한: CCM/국가/위험 프로파일에 따라 다릅니다.
시간 창: 예금/인출 주파수 규칙, 트랜잭션 간 "냉각".
보너스 남용 방지: 계정/장치/IP/결제 도구의 일관된 잠금 장치.
규제 요구 사항의 감사: 조치 및 결정 로그 저장 (KYC/AML), 보존 기간, 변경되지 않은 로그.
17) 준비된 점검표
- 전체 API 디렉토리 및 데이터 흐름 맵 (PII/재무 태그).
- CI에서의 OpenAPI/프로토 스키마, 검증 테스트 및 계약.
- mSL/HMAC/OAuth2 구성; 짧은 TTL 토큰; 키 회전.
- BOLA 테스트 및 부정적인 승인 사례; 중앙 집중식 PDP.
- Limits/quotas/anti-bot, 느린 loris에 대한 보호; IP 필터.
- WAF/게이트웨이 정규화 규칙, 주입 방지 서명.
- 쓰기 작업의 이념성; 재생에 대한 보호.
- 웹훅 서명 및 허용 목록; 고립 된 끝점.
- KMS/Vault의 비밀; 암호화 된 스토리지; 이상에 대한 경고.
- 대시 보드, 경고, 감사 로그; 일한 플레이 북 사건.
- 정기적 인 펜트/DAST/SAST, 취약성 트랙 및 패치 다운로드.
18) 안티 패턴 (불가능한)
주변에 단단한 TLS없이 'X-Forwarded' 를 신뢰하십시오.
임의의 '콘텐츠 유형' 및 '소프트' JSON 체계를 수락하십시오.
리콜/로테이션없이 수명이 긴 JWT.
중앙 집중식 정책없이 코드에서 역할 및 비즈니스 규칙을 혼합하십시오.
비밀/PII가있는 로그; 바깥쪽으로 자세한 500- 메시지.
"임시" 오픈 엔드 포인트 제한 및 승인없이.
19) Versioning and Deprekate
경로/헤더의 버전; 지원 정책 (예: N-2).
발표: 폐기 마감일, 이전 버전의 사용 모니터링, 제어 된 종료.
호환성: 고객/파트너 계약 및 테스트 매트릭스.
20) 안전 테스트
체계/정책의 계약 테스트, 퍼지 입력, 음수
제한/할당량, 보호 테스트 (혼돈 트래픽) 가있는 성능 프로파일.
레드 팀/버그 현상금: BOLA 스크립트, SSRF, 서명/재생, GraphQL 복잡성.
TL; DR
1. API 디렉토리 + 엄격한 체계.
2. 클라이언트를위한 OAuth2/OIDC, 내부의 mSL/HMAC.
3. 리소스 당 BOLA 주변 (ABAC/RBAC).
4. 필터링: 경로/헤더 정규화, 제한, WAF 규칙.
5. 이데올로기, 서명, 재생/SSRF 보호.
6. KMS/Vault 및 비밀 교체.
7. 관찰 가능성, 경고, 플레이 북.