Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
lightweight authenticity of microservices
Search
wtnabe
August 20, 2016
Programming
0
450
lightweight authenticity of microservices
これくらいならユーザー認証なしでやってもいいかも? みたいな割り切りの話。
wtnabe
August 20, 2016
Tweet
Share
More Decks by wtnabe
See All by wtnabe
Effective Jekyll
wtnabe
0
47
5 min Jekyll/Liquid Plugin cooking
wtnabe
0
22
Ruby de Wasm
wtnabe
0
46
Cloud Native Buildpacksって結局どうなの?
wtnabe
0
38
Decoupled System with Turbo Frame
wtnabe
1
120
join-kanazawarb-or-7years-passed-since-it-was-borned
wtnabe
0
780
let-me-edit-with-editor
wtnabe
0
330
google-photos-and-storage-and-rclone
wtnabe
0
440
one case of how to begin vuejs
wtnabe
2
460
Other Decks in Programming
See All in Programming
Cline指示通りに動かない? AI小説エージェントで学ぶ指示書の書き方と自動アップデートの仕組み
kamomeashizawa
1
590
NPOでのDevinの活用
codeforeveryone
0
460
設計やレビューに悩んでいるPHPerに贈る、クリーンなオブジェクト設計の指針たち
panda_program
6
1.7k
PHP 8.4の新機能「プロパティフック」から学ぶオブジェクト指向設計とリスコフの置換原則
kentaroutakeda
2
670
GoのGenericsによるslice操作との付き合い方
syumai
3
700
ニーリーにおけるプロダクトエンジニア
nealle
0
660
技術同人誌をMCP Serverにしてみた
74th
1
450
High-Level Programming Languages in AI Era -Human Thought and Mind-
hayat01sh1da
PRO
0
620
C++20 射影変換
faithandbrave
0
550
AWS CDKの推しポイント 〜CloudFormationと比較してみた〜
akihisaikeda
3
320
LT 2025-06-30: プロダクトエンジニアの役割
yamamotok
0
610
PipeCDのプラグイン化で目指すところ
warashi
1
220
Featured
See All Featured
Bash Introduction
62gerente
614
210k
Building Adaptive Systems
keathley
43
2.6k
CoffeeScript is Beautiful & I Never Want to Write Plain JavaScript Again
sstephenson
161
15k
Done Done
chrislema
184
16k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
667
120k
Practical Orchestrator
shlominoach
188
11k
The Psychology of Web Performance [Beyond Tellerrand 2023]
tammyeverts
48
2.9k
The Invisible Side of Design
smashingmag
300
51k
Art, The Web, and Tiny UX
lynnandtonic
299
21k
The Straight Up "How To Draw Better" Workshop
denniskardys
234
140k
Rails Girls Zürich Keynote
gr2m
94
14k
4 Signs Your Business is Dying
shpigford
184
22k
Transcript
インターネット越しの マイクロサービスな WebAPIの真正性設計 @wtnabe Kanazawa.rb meetup #48 2016-08-20 (Sat) at
IT Plaza MUSASHI
お品書き 真正性 今回の⽬的 メッセージ認証 今回の設計
真正性
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いいんじゃない?
MAC 1. 共通の秘密鍵を持つ 2. 送信側 メッセージから鍵を⽤いてMACを⽣成 メッセージ本⽂とMACを送信 3. 受信側 メッセージ本⽂と秘密鍵からMACを⽣成
受信したMACを検証
メリット 鍵が漏れていなければメッセージは改竄 されていないと⾔える 鍵そのものは送らないので暗号化不要
HMAC HMAC: Keyed-Hashing for Message Authentication (RFC 2104) MACを⽣成するアルゴリズムにハッシュ 関数を利⽤する
ハッシュ関数は反復利⽤される 鍵もそのまま利⽤するわけではない
詳しくはおぐぐりください
利⽤例 AWS REST リクエストの署名と認証 - Amazon Simple Storage Service 基本的な認証のプロセス
- Amazon Simple Queue Service SSH Protocol 2 integrity
今回の設計
マイクロサービスなWebAPI
割り切り 秘密鍵を知っていることを以って相⼿を 信⽤することでユーザー認証不要に ⼆つのサービスの環境変数に同じ秘密 鍵をセットするだけでOK 公開してよい情報なら暗号化も不要
実装も楽 枯れた⼿法 (1997年 RFC 2104) 実装も普通にアリモノでOK OpenSSL::HMAC (Ruby) hash_hmac() (PHP)
事例もある SSH, AWSはデカイ
インターネット越しでも HMACでお⼿軽 マイクロサービス
参考 HMAC: Keyed-Hashing for Message Authentication (RFC 2104 / IPA)