メインコンテンツへスキップ

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

All examples on this page work on VillageSQL. Install Now →
ハッシュはデータがどのようなものかを教えてくれます。HMAC は、そのデータが秘密鍵を知っている誰かから来たことを教えてくれます。この違いは、行が改ざんされていないこと、Webhook のペイロードが本物であること、またはトークンが偽造ではなく自分のシステムで生成されたことを検証するときに重要です。MySQL には組み込みの HMAC 関数がなく、標準的な答えはアプリケーションコードで計算することです。VillageSQL の hmac() を使うと、SQL の中でそれができます。

問題: 組み込みの HMAC がない

MySQL にはハッシュ化のための SHA2() と MD5() がありますが、鍵を受け取るものはありません。HMAC(ハッシュベースのメッセージ認証コード)は、共有の秘密を使って認証コードを生成します。鍵を持たない人には再現できないため、ただのハッシュとは根本的に異なります。 典型的な手法は、データベースに書き込む前にアプリケーションで HMAC を計算することです。
これは動作しますが、すべての書き込み経路、つまりすべての言語、サービス、および一括ローダーが署名ロジックを複製しなければならないことを意味します。アプリケーションを迂回するマイグレーションスクリプトは、署名のない行を書き込みます。

VillageSQL の場合: SQL での hmac()

VillageSQL の vsql_crypto 拡張機能は hmac(data, key, algorithm) を追加します。この関数は、完全に MySQL の中で計算された VARBINARY の認証コードを返します。

トリガーで行に署名する

どのアプリケーション経路が行を作成したかにかかわらず、書き込み時にすべての行に署名するには、トリガーを使います。

Webhook ペイロードの検証

アプリケーションが受信した Webhook ペイロードを保存する場合、処理の前に 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 は決定的です。同じデータ、同じ鍵、同じアルゴリズムは常に同じ結果を生成します。これが検証を成り立たせています。

トラブルシューティング

関連項目