これくらいならユーザー認証なしでやってもいいかも? みたいな割り切りの話。
インターネット越しのマイクロサービスなWebAPIの真正性設計@wtnabeKanazawa.rb meetup #482016-08-20 (Sat) at IT Plaza MUSASHI
View Slide
お品書き真正性今回の⽬的メッセージ認証今回の設計
真正性
authenticityなりすましではないこと
インターネット越しの通信相⼿が誰か分からない内容が改竄されていないか分からない
対策技術ユーザー認証メッセージ認証
ユーザー認証独⾃実装既存の認証機構を利⽤SSL証明書を利⽤するID / password⽅式公開鍵⽅式
メッセージ認証MD5やSHA256などのダイジェスト関数デジタル署名MAC ( Message Authentication Code )
ユーザー認証が重い実装は重いパスワード管理は重い鍵ペア管理は重い
逆に⽳になったり独⾃実装がヘボい管理がヘボい
今回の⽬的
マイクロサービスなWebAPIアクセス
「ユーザー」は1⼈2⼈しかいないはず(やりとりの必要なサービスは当初せいぜい1つか2つ程度だろう)⼤げさなユーザー認証機構は必要か?⼤げさなユーザー認証機構は必要か?
もう⼀度 制約制約インターネット越しAWS VPCのようなゾーンはないあくまでアプリでVPN組むとかナシで
メッセージ認証
おおまかにMD5やSHA256などのダイジェスト関数デジタル署名MAC ( Message Authentication Code )
おおまかに内容の⼀致しか分からない鍵ペア管理が重い共通の秘密鍵しかないので管理しやすい
MACいいんじゃない?
MAC1. 共通の秘密鍵を持つ2. 送信側メッセージから鍵を⽤いてMACを⽣成メッセージ本⽂とMACを送信3. 受信側メッセージ本⽂と秘密鍵からMACを⽣成受信したMACを検証
メリット鍵が漏れていなければメッセージは改竄されていないと⾔える鍵そのものは送らないので暗号化不要
HMACHMAC: Keyed-Hashing for Message Authentication (RFC 2104)MACを⽣成するアルゴリズムにハッシュ関数を利⽤するハッシュ関数は反復利⽤される鍵もそのまま利⽤するわけではない
詳しくはおぐぐりください
利⽤例AWSREST リクエストの署名と認証 -Amazon Simple Storage Service基本的な認証のプロセス - AmazonSimple Queue ServiceSSH Protocol 2 integrity
今回の設計
マイクロサービスなWebAPI
割り切り秘密鍵を知っていることを以って相⼿を信⽤することでユーザー認証不要に⼆つのサービスの環境変数に同じ秘密鍵をセットするだけでOK公開してよい情報なら暗号化も不要
実装も楽枯れた⼿法 (1997年 RFC 2104)実装も普通にアリモノでOKOpenSSL::HMAC (Ruby)hash_hmac() (PHP)
事例もあるSSH, AWSはデカイ
インターネット越しでもHMACでお⼿軽マイクロサービス
参考HMAC: Keyed-Hashing for MessageAuthentication (RFC 2104 / IPA)