메인 콘텐츠로 건너뛰기

VillageSQL is a drop-in replacement for MySQL with extensions.

All examples on this page work on VillageSQL. Install Now →
해시는 데이터가 어떤 모습인지 알려줍니다. HMAC은 그 데이터가 비밀 키를 아는 사람에게서 왔다는 것을 알려줍니다. 이 차이는 행이 변조되지 않았는지, 웹훅 페이로드가 진짜인지, 토큰이 위조된 것이 아니라 여러분의 시스템에서 생성된 것인지 검증할 때 중요합니다. MySQL에는 내장 HMAC 함수가 없습니다 — 표준 답은 애플리케이션 코드에서 계산하는 것입니다. VillageSQL의 hmac()을 사용하면 SQL에서 할 수 있습니다.

문제: 내장 HMAC 없음

MySQL에는 해싱을 위한 SHA2()와 MD5()가 있지만, 키를 받는 것은 없습니다. HMAC(해시 기반 메시지 인증 코드)은 공유 비밀을 사용하여 인증 코드를 생성합니다 — 키가 없는 사람은 재현할 수 없기 때문에 일반 해시와 근본적으로 다릅니다. 일반적인 접근 방식은 데이터베이스에 쓰기 전에 애플리케이션에서 HMAC을 계산하는 것입니다:
이 방법은 동작하지만, 모든 쓰기 경로 — 모든 언어, 서비스, 대량 로더 — 가 서명 로직을 복제해야 한다는 뜻입니다. 애플리케이션을 우회하는 마이그레이션 스크립트는 서명되지 않은 행을 쓰게 됩니다.

VillageSQL과 함께: SQL의 hmac()

VillageSQL의 vsql_crypto 확장은 hmac(data, key, algorithm)을 추가하며, 이 함수는 MySQL 안에서 완전히 계산된 VARBINARY 인증 코드를 반환합니다.

트리거에서 행 서명

어떤 애플리케이션 경로가 행을 만들었는지와 관계없이, 트리거를 사용하여 쓰기 시점에 모든 행에 서명합니다:

웹훅 페이로드 검증

애플리케이션이 들어오는 웹훅 페이로드를 저장한다면, 처리하기 전에 SQL에서 직접 서명을 검증할 수 있습니다:

지원되는 알고리즘

새 코드에는 HMAC-SHA256을 사용하세요. HMAC 구성은 기반 해시의 충돌 취약점을 물려받지 않으므로, HMAC-SHA1은 일반 SHA-1처럼 깨지지는 않았습니다 — 그러나 SHA-1은 사용 중단되었고 규제 기관은 이를 레거시로 취급합니다. 새 코드에는 사용하지 마세요.

HMAC과 일반 해시 비교

보호하려는 데이터가 공개된 것이라면, 일반 해시는 아무것도 증명하지 못합니다. 데이터가 비밀을 아는 사람에 의해 생성되었음을 증명해야 할 때 HMAC을 사용하세요. 키 없는 해싱에 대해서는 MySQL에서 데이터 해싱을 참조하세요.

자주 묻는 질문

HMAC 키를 트리거에 저장하는 것이 안전한가요?

아니요 — 트리거 정의에 하드코딩되어 있어 SHOW CREATE TRIGGER 권한이 있는 누구나 볼 수 있습니다. 프로덕션에서는 안전한 구성 경로에서 키를 가져오거나, 애플리케이션이 연결 시 설정하는 세션 변수로 전달하세요. 키를 자격 증명으로 취급하세요.

쿼리 결과가 전송 중에 변경되지 않았는지 HMAC으로 검증할 수 있나요?

HMAC은 무단 수정으로부터 보호하지, 도청으로부터 보호하지는 않습니다. 전송 중 보호에는 MySQL 연결에 TLS를 사용하세요. HMAC은 데이터가 데이터베이스에 도달한 뒤의 변조를 감지하는 데 유용합니다.

HMAC 키는 어떻게 교체하나요?

전환하기 전에 기존의 모든 행을 새 키로 다시 서명하세요:

hmac()은 같은 입력에 대해 같은 출력을 반환하나요?

예 — HMAC은 결정적입니다. 같은 데이터 + 같은 키 + 같은 알고리즘은 항상 같은 결과를 생성합니다. 이것이 검증이 동작하는 이유입니다.

문제 해결

참고