개발자 도구 · UUID 생성기
이름 기반 UUID(v3 및 v5): 네임스페이스의 결정적 ID
· 배경
uuid 암호화 브라우저 API
동일한 외부 레코드가 항상 동일한 식별자를 얻어야 하는 경우 임의의 UUID는 그렇지 않습니다. 버전 3 및 5 UUID는 네임스페이스와 이름을 안정적인 ID로 해시합니다. 이 게시물에서는 이를 사용하는 방법과 시기를 설명합니다.
동일한 고객을 두 번 다시 가져오기 — 결정적 ID가 해결하는 중복 문제
데이터 가져오기 파이프라인은 해당 시스템 내에서 안정적인 외부 ID를 사용하여 외부 시스템으로부터 고객 기록을 수신합니다. 각 가져오기 실행에 대해 새로운 무작위 UUID을 생성하는 경우 동일한 고객을 두 번 가져오면 두 개의 서로 다른 식별자와 중복 레코드가 생성됩니다. 이러한 중복은 보고, 청구 및 지원 시스템으로 다운스트림으로 흘러갑니다. 고객의 외부 ID와 가져오기 소스를 나타내는 안정적인 네임스페이스에서 UUID을 파생시키는 경우 모든 가져오기는 동일한 고객에 대해 동일한 UUID를 생성하므로 기존 레코드를 식별하고 업데이트할 수 있습니다. 이 결정성은 v3 및 v5 UUID의 정의 특성입니다. UUID는 독립적으로 생성되지 않고 입력에서 파생되며 동일한 입력은 항상 동일한 UUID을 생성합니다.
네임스페이스와 이름 — 입력이 연결되고 해시되는 방식과 네임스페이스가 서로 다른 소스 간의 충돌을 방지하는 이유
v3 또는 v5 UUID는 네임스페이스 UUID(일반적으로 사전 정의됨), 이름(모든 바이트 문자열) 및 해시 알고리즘(v3의 경우 MD5, v5의 경우 SHA-1)의 세 가지 구성 요소에서 파생됩니다. UUID 네임스페이스의 16 바이트를 이름의 UTF-8 바이트와 연결하고, 연결을 해시하고, 해시 출력의 첫 번째 16 바이트를 가져와 해당 바이트를 버전 니블이 3로 설정된 UUID로 해석합니다. 5. 네임스페이스는 ID 공간을 분할합니다. DNS 네임스페이스의 v5 UUID는 URL 네임스페이스의 v5 UUID와 충돌하지 않습니다. RFC 9562은 DNS 이름, URL, OID, X.500 고유 이름 등 4가지 사전 정의된 네임스페이스를 정의합니다. 조직은 v4 UUID를 생성하여 자체 네임스페이스를 만들 수 있습니다.
MD5 및 v5의 SHA-1 — ID가 보안 제어가 아니기 때문에 여기에서 약한 해시가 허용되는 이유
버전 3은 MD5를 사용하고 버전 5은 SHA-1를 사용하며, 사양 날짜 및 사용 가능한 구현에 따라 선택됩니다. 이름 기반 UUID의 경우 해시 함수가 보안 경계나 암호화 제어가 아니기 때문에 이러한 구별은 중요하지 않습니다. UUID은 신뢰성이나 무결성을 입증하지 않습니다. 이는 단순히 가변 길이 문자열을 고정된 128비트 값으로 변환하는 것입니다. UUID는 증거나 보안 제어가 아닌 불투명한 값으로 저장되고 비교되므로 공격 모델은 관련이 없습니다. 새로운 구현에서는 v3(MD5) 대신 v5(SHA-1)를 사용해야 합니다. 이는 강력한 보안상의 이유가 아니라 v5가 최신 표준이고 널리 사용 가능하기 때문입니다.
사전 정의된 네임스페이스 — DNS, URL, OID 및 X.500 및 자체 생성 시기
RFC 9562는 특정 바이트 표현을 사용하여 정확히 4개의 사전 정의된 네임스페이스 UUID를 지정합니다. DNS의 경우 6ba7b810-9dad-11d1-80b4-00c04fd430c8, URL의 경우 6ba7b811-9dad-11d1-80b4-00c04fd430c8, OID의 경우 6ba7b812-9dad-11d1-80b4-00c04fd430c8이고 X.500 고유 이름의 경우 6ba7b814-9dad-11d1-80b4-00c04fd430c8입니다. DNS 네임스페이스와 www.example.com 이름에서 파생된 v5 UUID는 항상 동일하며 URL 네임스페이스의 v5 UUID과 충돌하지 않습니다. 사전 정의된 네임스페이스를 사용하면 상호 운용성이 보장됩니다. 여러 팀이 독립적으로 DNS 네임스페이스와 함께 v5를 사용하는 경우 동일한 DNS 이름에 대해 동일한 UUID를 생성합니다. 네임스페이스를 선택하거나 생성하는 것은 스키마 디자인의 일부입니다.
작업 예 — 개념적으로 URL 네임스페이스와 레코드 URL에서 v5 UUID 파생(단계별)
개념적으로 URL 네임스페이스 및 이름 https://example.com/api/users/42.에서 v5 UUID 파생 16 바이트인 네임스페이스 UUID는 6b a7 b8 11 9d ad 11 d1 80 b4입니다. 00 c0 4f d4 30 c8. 이름은 30 바이트인 UTF-8 문자열 https://example.com/api/users/42,입니다. 네임스페이스 바이트(16)와 이름 바이트(30)를 연결하여 총 46바이트를 얻습니다. SHA-1 해시를 계산하여 20바이트 해시를 생성합니다. 첫 번째 16 바이트를 가져와 이를 버전 니블이 5로 설정되고 변형 비트가 RFC 표준으로 설정된 UUID로 해석합니다. 동일한 입력으로 다시 계산하면 동일한 결과가 생성됩니다. 대부분의 개발자는 언어 UUID 라이브러리를 사용하여 v5를 계산합니다.
패턴이 깨지는 경우 — 이름이 변경될 때, 팀 간에 네임스페이스가 일관되지 않을 때, 입력이 비밀일 때
이름 기반 UUID는 이름이 시스템 및 가져오기 실행 전체에서 안정적이고 일관적이라고 가정합니다. 동일한 외부 기록이 서로 다른 시스템에서 서로 다른 이름을 갖는 경우 각 이름에서 v5를 생성하면 서로 다른 UUID가 생성되어 동일한 사람을 식별할 수 없습니다. 팀 간에 네임스페이스가 합의되지 않으면(각 팀이 실제로 동일한 소스에 대해 자체 네임스페이스를 생성함) 서로 다른 UUID가 생성되고 레코드 일치에 실패합니다. 입력이 민감한 데이터인 경우 v5 UUID을 생성한다는 것은 UUID이 입력을 알고 있는 경우 누구나 조회할 수 있는 공개적이고 결정적인 값임을 의미합니다. 입력이 변경되거나 네임스페이스 정의가 일관되지 않으면 결정성이 깨집니다.
여기서 다루지 않는 내용 — ToolAcre 생성기는 CSPRNG에서 가져오므로 이름 기반 ID에는 언어의 UUID 라이브러리가 필요합니다.
ToolAcre는 독립을 위해 브라우저 암호화 보안 생성기에서 가져온 v4 UUID만 생성합니다. 이름 기반 UUID 파생에는 언어 UUID 라이브러리 또는 SHA-1를 계산하고 결과 형식을 올바르게 지정하는 구현이 필요합니다. 이 게시물에서는 개념과 사용 사례를 설명합니다. 표준 암호화 라이브러리에 액세스할 수 있는 모든 언어에서 v5 생성을 구현하는 것은 간단합니다. v5 파생의 메커니즘은 간단합니다. 문제는 이를 네임스페이스가 안정적이고 이름이 일관되며 접근 방식이 팀을 위해 잘 문서화되어 있는 시스템 스키마에 통합하는 것입니다. 개발팀은 네임스페이스 선택을 문서화해야 합니다.
요점: 필요할 때는 결정적이며, 그렇지 않으면 무작위입니다. 안정적인 매핑을 위해서는 v5를 사용하고 추측할 수 없는 모든 것에 대해서는 ToolAcre 생성기를 사용하세요.
외부 식별자와 내부 기록 간의 안정적인 매핑을 위해 v5를 사용하세요. 결정론은 중복 가져오기를 방지하고 시스템 전체에서 일치하는 레코드를 간단하고 안정적으로 만듭니다. 추측할 수 없어야 하는 식별자나 강력한 기밀성과 비밀이 필요한 시나리오에는 이름 기반 UUID를 사용하지 마세요. ToolAcre는 예측 가능성 없이 독립적이고 고유해야 하는 식별자에 대해 임의의 v4 UUID를 생성합니다. 시스템에 입력을 고정 식별자에 매핑하는 결정적 ID가 필요한 경우 언어 UUID 라이브러리가 이를 계산할 수 있습니다. 결정성은 입력을 제어할 때 강력한 기능입니다.