응답 래핑

응답 래핑 (Response wrapping)

참고: 이 정보 중 일부는 Vault 0.8에서 도입된 응답 래핑 토큰 기능에 의존하며, 이전 릴리스에서는 사용하지 못할 수 있습니다.

Vault의 응답 래핑(Response Wrapping) 은 Vault가 HTTP 클라이언트에 보내려던 응답을 일회용 토큰의 cubbyhole 에 넣고, 그 일회용 토큰을 대신 반환하는 기능입니다. 이를 통해 비밀값이 네트워크를 통과하는 여러 중계 구간에서 평문으로 노출될 위험을 줄일 수 있습니다.

출처: 문서

본문

개요 (Overview)

많은 Vault 배포에서 클라이언트는 Vault에 직접 접근해 반환된 시크릿을 소비합니다. 어떤 상황에서는 하나의 신뢰된 주체가 대부분의 Vault API와 상호작용하고 시크릿을 최종 소비자에게 전달하도록 권한을 분리하는 것이 바람직할 수 있습니다.

하지만 시크릿이 거치는 중계(relay)가 많을수록, 특히 시크릿이 평문으로 전송된다면 우발적 노출 가능성이 커집니다. 예를 들어 콜드 부팅된 머신에 TLS 개인 키를 전달하고 싶은데, 복호화 키를 영구 저장소에 두고 싶지 않아 전송 중에 키를 암호화할 수 없는 경우가 있습니다.

이 문제를 해결하기 위해 Vault는 응답 래핑 기능을 제공합니다. 요청하면 Vault는 HTTP 클라이언트에 보내려던 응답을 대신 일회용 토큰의 cubbyhole 에 넣고 그 일회용 토큰을 반환합니다. 논리적으로 응답이 토큰에 의해 래핑된 것이며, 그 값을 얻으려면 이 토큰에 대해 언래핑(unwrap) 연산을 해야 합니다. 기능적으로 토큰은 Vault 키링의 암호화 키를 사용해 데이터를 복호화할 권한을 부여합니다.

응답 래핑은 세 가지 임무를 수행합니다.

은폐(cover) 제공 — 전송되는 값이 실제 시크릿이 아니라 그 시크릿을 가리키는 참조(응답 래핑 토큰)임을 보장합니다. 로그에 기록되거나 중간에 캡처된 정보는 민감 정보를 직접 보지 못합니다.
부정 행위 탐지(malfeasance detection) — 오직 한 당사자만 토큰을 언래핑해 그 안을 볼 수 있음을 보장합니다. 언래핑할 수 없는 토큰을 받은 클라이언트는 즉시 보안 사고를 트리거할 수 있습니다. 또한 클라이언트는 언래핑 전에 토큰을 검사해 그 출처가 Vault의 예상 위치에서 왔는지 확인할 수 있습니다.
노출 수명 제한(lifetime limit) — 응답 래핑 토큰은 래핑된 시크릿과 별개의 수명을 가지며(종종 훨씬 짧음), 클라이언트가 제때 언래핑하지 못하면 토큰이 빠르게 만료될 수 있습니다.

응답 래핑 토큰

응답이 래핑되면 Vault의 정상 API 응답은 원래 시크릿 대신 응답 래핑 토큰과 관련된 정보를 담습니다.

TTL — 응답 래핑 토큰 자체의 TTL
Token — 실제 토큰 값
Creation Time — 응답 래핑 토큰이 생성된 시간
Creation Path — 원래 요청에서 호출된 API 경로
Wrapped Accessor — 래핑된 응답이 Vault 토큰을 포함한 인증 응답일 때, 래핑된 토큰의 accessor 값. 이는 숫자를 가진 오케스트레이션 시스템(예: Nomad)이 응답 래핑 토큰을 실제로 언래핑하거나 내부 토큰 ID를 알지 않고도 잡(job) 생명주기 지식에 기반해 시크릿 수명을 제어하는 데 유용합니다.

Vault는 현재 서명된 응답 래핑 토큰을 제공하지 않습니다. 이는 추가 보호가 거의 없기 때문입니다. 올바른 Vault 서버를 가리키고 있다면 토큰 검증은 서버와의 상호작용으로 수행되고, 토큰은 데이터가 아니라 접근 메커니즘일 뿐이므로 서버는 검증 없이 데이터를 내주지 않습니다. 또한 잘못된 Vault 서버로 공격받고 있다면 같은 공격자가 잘못된 서명 공개 키를 줄 수도 있습니다. 따라서 Vault는 토큰 자체가 권위 있는 데이터를 담지 않는다는 점에 의존하며 서명하지 않습니다.

응답 래핑 토큰 연산

sys/wrapping 경로를 통해 여러 래핑 연산을 실행할 수 있습니다.

Lookup (sys/wrapping/lookup) — 래핑 토큰의 생성 시간, 생성 경로, TTL을 조회합니다. 이 경로는 인증이 필요 없으며 응답 래핑 토큰 자체에도 허용됩니다. 즉 응답 래핑 토큰 보유자는 항상 토큰 속성을 조회할 수 있습니다.
Unwrap (sys/wrapping/unwrap) — 토큰을 언래핑해 내부 응답을 반환합니다. 반환되는 응답은 원래 wire 형식이며 API 클라이언트에서 바로 사용할 수 있습니다.
Rewrap (sys/wrapping/rewrap) — 래핑된 데이터를 새 응답 래핑 토큰으로 옮깁니다. 오래 사는 시크릿에 유용합니다. 예를 들어 조직이 pki 백엔드 루트 CA 키를 장수명 응답 래핑 토큰으로 받아, 아무도 그 키를 보지 못했다는 것을 확인하면서도 CRL 서명에 사용할 수 있게 할 수 있습니다.
Wrap (sys/wrapping/wrap) — 보낸 데이터를 응답 래핑 토큰으로 다시 반향(echo)하는 보조 엔드포인트입니다. 이 엔드포인트에 대한 접근을 막아도 임의 데이터 래핑 기능이 사라지지는 않습니다(다른 곳에서도 가능).

응답 래핑 토큰 생성

응답 래핑은 요청별로, 클라이언트가 해당 요청에 대해 원하는 응답 래핑 토큰 TTL을 제공하면 트리거됩니다. X-Vault-Wrap-TTL 헤더로 설정하며, 정수 초 또는 문자열 기간(초 15s, 분 20m, 시간 25h)이 될 수 있습니다. Vault CLI에서는 -wrap-ttl 파라미터로 설정합니다. Go API에서는 연산과 경로를 원하는 TTL에 매핑하는 헬퍼 함수를 설정해 래핑을 트리거합니다.

클라이언트가 래핑을 요청하면:

원래 HTTP 응답이 직렬화됩니다.
클라이언트가 제공한 TTL로 새 일회용 토큰이 생성됩니다.
내부적으로 직렬화된 응답이 일회용 토큰의 cubbyhole에 저장됩니다.
토큰 ID, TTL, 경로를 새 응답의 wrap 정보 객체에 담아 새 응답이 생성됩니다.
새 응답이 호출자에게 반환됩니다.

정책이 최소/최대 래핑 TTL을 제어할 수 있습니다.

응답 래핑 토큰 검증

적절한 래핑 토큰 검증은 부정 행위 감지를 위해 필수적입니다. 권장 검증 단계는 다음과 같습니다.

응답 래핑 토큰을 기대했는데 도착하지 않으면, 공격자가 토큰을 가로채 더 이상 진행되지 못하게 했을 수 있으므로 즉시 조사해야 합니다.
래핑 토큰을 조회(lookup)합니다. 이미 언래핑됐거나 만료(또는 폐기)됐는지 바로 알 수 있습니다. 토큰이 무효라는 것은 데이터가 차단됐다는 뜻은 아닐 수 있지만(예: 클라이언트 시작이 늦어 TTL 만료), 즉시 조사 알림을 트리거해야 합니다.
토큰 정보를 확인한 뒤 생성 경로(creation path)가 기대와 일치하는지 검증합니다. TLS 키/인증서를 기대한다면 경로는 pki/issue/...여야 할 것입니다. 특히 cubbyhole이나 sys/wrapping/wrap으로 시작하는 경로는 데이터가 읽혀 새 래핑 토큰에 담겼을 가능성이 있습니다. kv 시크릿 엔진은 정확한 일치가 가장 좋습니다(예: secret/foo를 기대하는데 secret/bar 토큰이 오면 secret/ 접두어만 검사해서는 부족).
경로 검증 후 토큰을 언래핑합니다. 언래핑 실패 시 초기 조회 실패와 비슷하게 즉시 조사를 트리거합니다.

이 단계를 따르면 래핑 토큰 안의 데이터가 의도한 클라이언트 외에는 누구에게도 노출된 적이 없다는 강력한 확신을 얻고, 모든 가로채기·변조가 보안 알림으로 이어지도록 할 수 있습니다.