9.5 KiB
title, source_type, url, archive_url, status, confidence, related_branches, related_projects, tags, created, last_reviewed
| title | source_type | url | archive_url | status | confidence | related_branches | related_projects | tags | created | last_reviewed | |||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| AWS Signature Version 4 (SigV4) — HMAC request signing | official-doc | https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html | raw | high |
|
|
|
2026-05-22 | 2026-05-27 |
AWS SigV4 — HMAC-based request signing
Layer:
raw/official-docs/— AWS General Reference 공식 문서. ca-skeleton Security Operational Baseline (Group G-B) 의 대안 5 (API key + HMAC SigV4 패턴) 비교 근거.
Parent / 활용 branch (필수)
| Branch | 이 자료가 정당화하는 결정 |
|---|---|
| raw/branch-notes/feature-security-operational-baseline | JWT bearer baseline 채택 시 HMAC request signing 대안과의 비교 trade-off 근거 (secret in transit, replay window) |
컨텍스트 / 왜 저장했는지
ca-tmpl baseline 은 OAuth2 bearer JWT. 대안으로 "API key + HMAC signature" (AWS SigV4 패턴) 를 검토 후보로 둘 수 있음. machine-to-machine API 에서 secret 이 네트워크를 전혀 건너지 않는 모델로서, JWT bearer 의 탈취 위험 대비 보안 trade-off 비교 근거.
출처 / Source
- 원본 URL: https://docs.aws.amazon.com/general/latest/gr/signing_aws_api_requests.html
- 아카이브 URL: (미수집)
- 저자 / 조직: AWS (Amazon Web Services)
- 발행일: rolling docs (AWS General Reference)
- 마지막 확인일: 2026-05-27
- 관련: AWS SDK 각 언어별 SigV4 구현 (Java
BaseAws4Signer, Pythonbotocore.signers, Gosigv4)
핵심 인용 / Key quotes (verbatim)
[§Opening] "Authentication information that you send in a request must include a signature. AWS Signature Version 4 (SigV4) is the AWS signing protocol for adding authentication information to AWS API requests."
[§Opening] "You don't use your secret access key to sign API requests. Instead, you use the SigV4 signing process. Signing requests involves: 1. Creating a canonical request based on the request details. 2. Calculating a signature using your AWS credentials. 3. Adding this signature to the request as an Authorization header."
[§Why requests are signed — Protect data in transit] "To prevent tampering with a request while it's in transit, some of the request elements are used to calculate a hash (digest) of the request, and the resulting hash value is included as part of the request. When an AWS service receives the request, it uses the same information to calculate a hash and matches it against the hash value in your request. If the values don't match, AWS denies the request."
[§Why requests are signed — Protect against potential replay attacks] "In most cases, a request must reach AWS within five minutes of the time stamp in the request. Otherwise, AWS denies the request."
[§Opening] "Symmetric SigV4 requires you to derive a key that is scoped to a single AWS service, in a single AWS region, on a particular day. This makes the key and calculated signature different for each region, meaning you must know the region the signature is destined for."
Claims Extracted / 추출된 주장
| Claim ID | Claim (이 자료가 직접 말하는 것) | Evidence quote | Strength | Applies to | Does not prove |
|---|---|---|---|---|---|
| AWS-SIGV4-C1 | AWS API request 의 authentication 은 signature 를 포함해야 하며, SigV4 가 이를 위한 AWS signing protocol | [§Opening] "Authentication information that you send in a request must include a signature. AWS Signature Version 4 (SigV4) is the AWS signing protocol for adding authentication information to AWS API requests." | official-vendor-doc |
AWS API 호출 시 | 다른 cloud / 다른 API 에 SigV4 가 표준이라는 뜻 아님 — AWS 한정 |
| AWS-SIGV4-C2 | secret access key 자체는 request 에 직접 사용되지 않음. 대신 SigV4 process 가 (1) canonical request 생성, (2) credentials 로 signature 계산, (3) Authorization header 에 signature 추가 의 3단계로 작동 | [§Opening] "You don't use your secret access key to sign API requests. Instead, you use the SigV4 signing process. Signing requests involves: 1. Creating a canonical request based on the request details. 2. Calculating a signature using your AWS credentials. 3. Adding this signature to the request as an Authorization header." | official-vendor-doc |
HMAC 서명 모델의 "secret in transit zero" 속성 근거 | secret key 가 client 메모리에 안전하다는 뜻은 아님 — 보관 보안은 별도 |
| AWS-SIGV4-C3 | request element 의 hash (digest) 가 request 에 포함되며, AWS 가 동일 정보로 hash 재계산 후 mismatch 시 거절 — in-transit tamper 방어 | [§Why requests are signed] "To prevent tampering with a request while it's in transit, some of the request elements are used to calculate a hash (digest) of the request, and the resulting hash value is included as part of the request. When an AWS service receives the request, it uses the same information to calculate a hash and matches it against the hash value in your request. If the values don't match, AWS denies the request." | official-vendor-doc |
request body / header integrity 보호 | 어떤 element 가 hash 에 포함되는지의 정확한 목록 — 별도 reference_sigv-signing-elements 페이지 |
| AWS-SIGV4-C4 | In most cases, request 는 timestamp 로부터 5분 이내 에 AWS 에 도달해야 함 — 초과 시 거절 (replay attack 방어) | [§Why requests are signed] "In most cases, a request must reach AWS within five minutes of the time stamp in the request. Otherwise, AWS denies the request." | official-vendor-doc |
replay window 평가 | "5분" 이 모든 AWS service 에 일률 적용된다는 뜻은 아님 — "In most cases" 조건부 |
| AWS-SIGV4-C5 | Symmetric SigV4 는 single AWS service + single region + 특정 날짜로 scoped key 를 derive. region 별 key/signature 가 다르므로 destination region 을 알아야 함 | [§Opening] "Symmetric SigV4 requires you to derive a key that is scoped to a single AWS service, in a single AWS region, on a particular day. This makes the key and calculated signature different for each region, meaning you must know the region the signature is destined for." | official-vendor-doc |
key derivation 절차 / multi-region 비대응 | multi-region 신호용 SigV4a (asymmetric) 의 자세한 알고리즘 — 별도 섹션 |
Usage Boundaries / 적용 경계
- 이 자료가 직접 증명하는 것:
AWS-SIGV4-C1~C5: AWS SigV4 의 signing 단계, secret in transit zero, in-transit integrity, 5분 replay window, scoped key derivation.
- 이 자료가 증명하지 않는 것:
- SigV4 가 JWT bearer 보다 "항상 더 안전하다" 는 명제 — 운영 환경 (클라이언트 종류, secret 보관 능력) 에 따라 다름.
- GitHub Webhook / Slack webhook / Stripe webhook 의 signing 이 SigV4 와 동일한 spec 이라는 명제 — 각 vendor 별로 별도 (HMAC pattern 만 공유).
- 모바일/브라우저 환경에서 secret 보관이 불가능하다는 명제 — 별도 OWASP 권고 / 운영 관찰.
- Spring Security 가 SigV4 검증을 native 지원하는지 — Spring 벤더 doc 별도.
- "5분" 이 모든 service 에서 동일한지 — "In most cases" 조건부 명시.
- 내 프로젝트에 적용하려면 추가 확인이 필요한 것:
- ca-tmpl 의 server-to-server B2B endpoint 에 SigV4 패턴 적용 시 clock skew 운영 (NTP 동기화 SLA).
- canonical request 생성 시 어떤 header/query 가 포함되는지 정확한 목록 (
reference_sigv-signing-elements). - secret rotation 운영 절차 (AWS Secrets Manager 와 연계).
메모 / Notes (내 프로젝트 해석)
본 섹션은 자료 직접 인용 아님. ca-tmpl baseline 결정 해석.
- vs JWT bearer (ca-tmpl baseline):
- JWT bearer: 클라이언트가 token 을 그대로 헤더에 실어 보냄. 탈취 시 만료(
exp) 전까지 임의 사용 가능. - SigV4 HMAC: 클라이언트가 secret 으로 매 요청 서명. secret 자체는 네트워크를 안 건넘. 캡처된 서명은 timestamp 포함이라 replay window 가 작음 (대부분 5분).
- JWT bearer: 클라이언트가 token 을 그대로 헤더에 실어 보냄. 탈취 시 만료(
- 장점:
- secret in transit zero.
- request 무결성 (body hash 포함) 자체에 묶임 → MITM tamper 차단.
- replay window 짧음.
- 단점:
- 클라이언트 SDK 복잡도 (canonical request 만들기, signing key 파생).
- 시계 동기화 의존 (skew 5분). 모바일/IoT 환경 어려움.
- third-party / browser SPA 적용 난이도 (secret 을 브라우저에 두면 의미 없음).
- ca-tmpl 이 채택하지 않은 이유 (추정):
- skeleton 의 주된 클라이언트가 web/mobile public client → secret 보관 불가.
- JWT 가 OIDC 생태계와 호환 (Identity Provider 위임 가능), SigV4 는 closed-stack 에 가까움.
- 언제 SigV4-형 HMAC 이 baseline 이 되는가:
- server-to-server B2B API.
- secret 을 안전하게 보관 가능한 server-side client.
- GitHub Webhook, Slack webhook, Stripe webhook signing 등 webhook 검증 영역 (HMAC pattern 공유).
Related / 관련
- 같은 주제 다른 official-doc:
- raw/official-docs/security-jwt-rfc-7519-validation (JWT bearer baseline 비교 기준)
- raw/official-docs/security-mtls-rfc-8705 (또 다른 sender-constrained 메커니즘)
- raw/official-docs/secrets-aws-secrets-manager-rotation (HMAC secret rotation 운영)
- 인용하는 branch:
- 인용하는 wiki: (미작성)