lightweight authenticity of microservices

Slide 1

Slide 1 text

インターネット越しのマイクロサービスな WebAPIの真正性設計 @wtnabe Kanazawa.rb meetup #48 2016-08-20 (Sat) at IT Plaza MUSASHI

Slide 2

Slide 2 text

お品書き真正性今回の⽬的メッセージ認証今回の設計

Slide 3

Slide 3 text

真正性

Slide 4

Slide 4 text

authenticity なりすましではないこと

Slide 5

Slide 5 text

インターネット越しの通信相⼿が誰か分からない内容が改竄されていないか分からない

Slide 6

Slide 6 text

対策技術ユーザー認証メッセージ認証

Slide 7

Slide 7 text

ユーザー認証独⾃実装既存の認証機構を利⽤ SSL証明書を利⽤する ID / password⽅式公開鍵⽅式

Slide 8

Slide 8 text

メッセージ認証 MD5やSHA256などのダイジェスト関数デジタル署名 MAC ( Message Authentication Code )

Slide 9

Slide 9 text

ユーザー認証が重い実装は重いパスワード管理は重い鍵ペア管理は重い

Slide 10

Slide 10 text

逆に⽳になったり独⾃実装がヘボい管理がヘボい

Slide 11

Slide 11 text

今回の⽬的

Slide 12

Slide 12 text

マイクロサービスな WebAPIアクセス

Slide 13

Slide 13 text

「ユーザー」は1⼈2⼈しかいないはず（やりとりの必要なサービスは当初せいぜい1つか2つ程度だろう）⼤げさなユーザー認証機構は必要か？⼤げさなユーザー認証機構は必要か？

Slide 14

Slide 14 text

もう⼀度制約制約インターネット越し AWS VPCのようなゾーンはないあくまでアプリで VPN組むとかナシで

Slide 15

Slide 15 text

メッセージ認証

Slide 16

Slide 16 text

おおまかに MD5やSHA256などのダイジェスト関数デジタル署名 MAC ( Message Authentication Code )

Slide 17

Slide 17 text

おおまかに内容の⼀致しか分からない鍵ペア管理が重い共通の秘密鍵しかないので管理しやすい

Slide 18

Slide 18 text

MACいいんじゃない？

Slide 19

Slide 19 text

MAC 1. 共通の秘密鍵を持つ 2. 送信側メッセージから鍵を⽤いてMACを⽣成メッセージ本⽂とMACを送信 3. 受信側メッセージ本⽂と秘密鍵からMACを⽣成受信したMACを検証

Slide 20

Slide 20 text

メリット鍵が漏れていなければメッセージは改竄されていないと⾔える鍵そのものは送らないので暗号化不要

Slide 21

Slide 21 text

HMAC HMAC: Keyed-Hashing for Message Authentication (RFC 2104) MACを⽣成するアルゴリズムにハッシュ関数を利⽤するハッシュ関数は反復利⽤される鍵もそのまま利⽤するわけではない

Slide 22

Slide 22 text

詳しくはおぐぐりください

Slide 23

Slide 23 text

利⽤例 AWS REST リクエストの署名と認証 - Amazon Simple Storage Service 基本的な認証のプロセス - Amazon Simple Queue Service SSH Protocol 2 integrity

Slide 24

Slide 24 text

今回の設計

Slide 25

Slide 25 text

マイクロサービスなWebAPI

Slide 26

Slide 26 text

割り切り秘密鍵を知っていることを以って相⼿を信⽤することでユーザー認証不要に⼆つのサービスの環境変数に同じ秘密鍵をセットするだけでOK 公開してよい情報なら暗号化も不要

Slide 27

Slide 27 text

実装も楽枯れた⼿法 (1997年 RFC 2104) 実装も普通にアリモノでOK OpenSSL::HMAC (Ruby) hash_hmac() (PHP)