토큰화 변환

토큰화 변환 (Tokenization transform)

Vault 토큰과 혼동하지 마세요. 토큰화(Tokenization)는 민감한 값을 *토큰(token)*이라는 관련 없는 값으로 교환해요. 원래 민감한 값은 토큰만으로는 복구할 수 없으며, 비가역적이에요. 대신 형식 보존 암호화와 달리 토큰화는 상태 저장(stateful)이에요. 원래 값을 디코딩하려면 토큰을 Vault에 제출해야 하며, Vault는 스토리지의 암호 매핑에서 값을 검색해요.

출처: 문서

본문

작업 (Operation)

인코드 시 Vault는 무작위 서명된 토큰을 생성하고, 그 토큰 버전의 매핑을 plaintext와 메타데이터의 암호화된 버전, 그리고 시스템에 plaintext가 존재하는지 조회할 수 있는 tokenized 엔드포인트를 돕는 원래 plaintext의 지문(fingerprint)으로 저장해요.

매핑 모드에 따라 plaintext는 배포된 토큰을 소유한 경우에만 디코딩되거나, export 작업에서 복구될 수 있어요. 자세한 내용은 보안 고려 사항을 참고하세요.

토큰화의 암호 시스템은 토큰 저장소 암호화에 AES256-GCM96을 사용하며, 키는 토큰과 토큰화 루트 키에서 파생돼요.

수렴 (Convergence)

기본적으로 토큰화는 모든 인코드 작업에 대해 고유한 토큰을 생성해요. 이렇게 하면 결과 토큰이 plaintext와 만료와 완전히 독립적이 돼요. 그러나 때로는 plaintext/만료 쌍의 토큰화가 일관되게 같은 값으로 토큰화되는 것이 유익할 수 있어요. 예를 들어 (토큰을 디코딩하지 않고) 토큰을 데이터베이스의 다른 필드와 연관해 통계적 분석을 하려거나, 서로 다른 두 시스템에서 토큰화하되 결과를 연관시킬 수 있어야 할 때요. 이 경우 수렴형(convergent) 토큰화 변환을 만들 수 있어요.

변환 생성 시 활성화하면, Vault는 계산을 수정해 plaintext와 만료를 인코딩할 때마다 같은 값으로 토큰화하고, 스토리지는 그 토큰의 단일 항목만 유지해요. exportable 매핑 모드처럼 수렴도 필요할 때만 활성화해야 해요. 수렴형 토큰화는 중복 항목을 피하고 수렴 인코딩 시 메타데이터를 갱신해야 하므로 외부 저장소에서 작은 성능 패널티, 내장 저장소에서 더 큰 패널티가 있어요. 수렴이 필요한 사용 사례와 그렇지 않은 사용 사례가 모두 있다면, 둘 중 하나에만 수렴을 활성화한 서로 다른 두 토큰화 변환을 만드는 것을 권장해요.

토큰 조회 (Token lookup)

일부 사용 사례는 plaintext를 보고 토큰의 값을 조회하고 싶을 수 있어요. 보통 이는 공격자가 토큰이 plaintext 값에 대응한다는 것(알려진 plaintext 공격)을 결정하는 것을 막고 싶은 토큰화의 본질에 반해요. 그러나 이를 요구하는 사용 사례를 위해 토큰 조회 작업이 지원되지만, 토큰화 변환의 일부 구성에서만 지원돼요. 토큰 조회는 수렴이 활성화되었거나, 매핑 모드가 exportable 이고 저장소 백엔드가 외부일 때 지원돼요.

성능 고려 사항 (Performance considerations)

내장 (내부) 저장소

토큰화는 상태 저장이므로 인코드 작업은 필연적으로 값을 스토리지에 써요. 기본적으로 그 스토리지는 Vault 백엔드 저장소 자체예요. 이는 일부 시크릿 엔진과 달리, 인코드와 디코드 작업이 작업당 스토리지 접근을 요구한다는 점에서 차이가 있어요. 다른 엔진은 구성을 위해 스토리지를 사용하지만 대체로 스토리지에 접근하지 않고도 작업을 처리할 수 있어요.

이 작업들이 스토리지 쓰기를 포함하므로 프라이머리 노드에서 수행되어야 하기 때문에, 인코드 작업의 확장성은 프라이머리의 스토리지 성능에 의해 제한돼요.

또한 내부 스토리지를 사용하면 쓰기가 프라이머리 노드에서 수행되어야 하므로 인코드 작업의 확장성은 프라이머리와 그 스토리지 하위 시스템의 성능에 의해 제한돼요. 다른 모든 작업은 세컨더리에서 수행할 수 있어요.

마지막으로 복제 때문에 프라이머리에 대한 쓰기가 세컨더리에 도달하는 데 시간이 걸릴 수 있으므로, 디코드나 메타데이터 같은 다른 읽기 작업은 그때까지 세컨더리에서 성공하지 못할 수 있어요. 즉 토큰화는 최종 일관성(eventually consistent)이에요.

외부 저장소 (External storage)

모든 노드(DR 제외)가 외부 스토리지를 사용한 모든 작업에 참여할 수 있지만, 경험하는 트래픽 수준에 맞게 외부 스토리지를 모니터링하고 확장하는 데 주의해야 해요. 스토리지 스키마는 단순하며 잘 알려진 접근 방식도 효과적이어야 해요.

보안 고려 사항 (Security considerations)

토큰화의 목표는 최종 사용자의 디바이스가 민감한 값(예: 신용카드 번호) 대신 토큰을 저장하게 하고, 토큰이 민감한 값의 대리인 역할을 하는 트랜잭션에 여전히 참여하게 하는 것이에요. 이런 이유로 Vault가 생성하는 토큰은 민감한 값과 완전히 무관(예: 비가역적)해요.

또한 토큰화 변환은 인코드 중 생성된 값에 대한 여러 공격에 저항하도록 설계됐어요. 특히 공격자가 Vault 자체에서 토큰화 값을 훔쳐도 plaintext를 복구할 수 없도록 설계됐어요. 기본 매핑 모드에서는 기본 변환 키를 훔쳐도 인코드된 토큰도 소유하지 않으면 plaintext를 복구할 수 없어요. 공격자는 구조의 모든 값에 접근해야 해요.

그러나 exportable 매핑 모드에서는 plaintext 값이 Vault 안에서 복호화될 수 있는 방식으로 암호화돼요. 공격자가 변환 키와 토큰화 매핑 값을 소유하면 plaintext를 복구할 수 있어요. 이 모드는 운영자가 export-decoded 작업을 통해 긴급 상황에서 모든 plaintext 값을 내보낼 수 있는 능력을 우선시하는 경우를 위해 이용 가능해요.

메타데이터 (Metadata)

토큰화는 형식 보존이 아니고 스토리지를 요구하므로 임의 메타데이터를 토큰과 연결할 수 있어요. 메타데이터는 원래 plaintext 값보다 덜 민감한 것으로 간주돼요. 자체 검색 엔드포인트가 있으므로 운영자는 토큰의 메타데이터에는 접근을 허용하지만 디코드된 값에는 허용하지 않는 정책을 구성할 수 있어, 메타데이터만으로 작동하는 워크플로를 가능하게 해요.

TTL과 정리 (TTLs and tidying)

기본적으로 토큰은 오래 살며 그 스토리지는 무한정 유지돼요. time-to-live 개념이 있는 곳에서는 TTL로 토큰을 생성하는 것을 강력히 권장해요. 예를 들어 신용카드에 만료 날짜가 있으므로, 신용카드 PAN(기본 계정 번호)을 토큰화할 때는 PAN이 유효하지 않은 이후의 시간에 해당하는 TTL로 하는 것이 좋아요.

이렇게 하면 만료 후 그러한 값을 *정리(tidy)*하고 스토리지에서 제거할 수 있어요. 토큰 자체가 만료 시간을 인코딩하므로 디코드 및 다른 작업은 만료된 토큰이 제시되면 즉시 거부할 수 있어요.

저장소 (Storage)

외부 SQL 저장소 (External SQL stores)

현재 PostgreSQL, MySQL, MSSQL 관계형 데이터베이스가 토큰화의 외부 스토리지 백엔드로 지원돼요. 스키마 엔드포인트를 사용해 필요한 데이터베이스 테이블을 초기화하고 업그레이드할 수 있어요. Vault는 스키마 버전 관리 테이블을 사용해 해당 엔드포인트를 사용할 때 테이블을 만들어야 하는지 수정해야 하는지 결정해요. 테이블을 직접 변경하면 자동 스키마 관리가 동기화되지 않고 미래에 실패할 수 있어요.

외부 저장소는 특히 배치 작업과 함께 사용할 때 훨씬 더 높은 성능 규모를 달성할 수 있어서 종종 선호돼요.

스냅샷/복원 (Snapshot/Restore)

스냅샷은 백업이나 마이그레이션을 위해 토큰화 상태를 반복적으로 검색할 수 있게 해요. 결과 데이터는 같거나 다른 토큰화 저장소의 복원 엔드포인트에 공급될 수 있어요. 상태는 생성한 토큰화 변환에서만 사용할 수 있는데, 상태가 구성된 변환의 키로 암호화되기 때문이에요.

디코드된 값 내보내기 (Export decoded)

exportable 매핑 모드로 구성된 저장소의 경우 export decoded 엔드포인트는 운영자가 토큰과 그 디코드된 민감한 값을 포함한 토큰화 상태의 디코드된 내용을 검색할 수 있게 해요. exportable 모드는 이 사용 사례가 필요할 때만 권장돼요. 기본값은 공격자가 Vault 스토리지와 키에 접근해도 디코딩할 수 없기 때문이에요.

마이그레이션 (Migration)

토큰화 저장소는 토큰화 변환과 별도로 구성되며, 변환은 여러 저장소를 가리킬 수 있어요. 이 일대다 관계의 주요 사용 사례는 두 토큰화 저장소 간 마이그레이션을 용이하게 하는 것이에요.

여러 저장소가 구성되면 Vault는 모든 구성된 저장소에 새 토큰화 상태를 쓰고, 구성된 순서대로 각 저장소에서 읽어요. 따라서 여러 구성된 저장소를 스냅샷/복원 기능과 함께 사용해 새 저장소로 무중단(zero-downtime) 마이그레이션을 수행할 수 있어요.

  1. API에서 새 토큰화 저장소를 구성해요.
  2. 기존 토큰화 변환을 수정해 기존 및 새 저장소를 모두 사용하게 해요.
  3. 옛 저장소를 스냅샷해요.
  4. 스냅샷을 새 저장소로 복원해요.
  5. 원하는 검증을 수행해요.
  6. 토큰화 변환을 수정해 새 저장소만 사용하게 해요.

키 관리 (Key management)

토큰화는 키 회전을 지원해요. 키는 변환에 연결되므로 키 이름은 해당 토큰화 변환의 이름과 같아요. 키는 디코딩에 백워드 호환성과 함께 새 버전으로 회전할 수 있어요. 인코딩은 항상 최신 키 버전으로 수행돼요. 키 버전도 정리할 수 있어요. 키는 키 구성의 auto_rotate_field에 지정된 사용자 정의 시간 간격으로 자동 회전할 수도 있어요. 자세한 내용은 transform API 문서를 참고하세요.

튜토리얼 (Tutorial)

Transform 시크릿 엔진으로 데이터 토큰화하기를 참고하면 단계별 튜토리얼을 볼 수 있어요.

더 알아보기 (Learn more)