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
380
lightweight authenticity of microservices
これくらいならユーザー認証なしでやってもいいかも? みたいな割り切りの話。
wtnabe
August 20, 2016
Tweet
Share
More Decks by wtnabe
See All by wtnabe
Decoupled System with Turbo Frame
wtnabe
1
49
join-kanazawarb-or-7years-passed-since-it-was-borned
wtnabe
0
680
let-me-edit-with-editor
wtnabe
0
250
google-photos-and-storage-and-rclone
wtnabe
0
330
one case of how to begin vuejs
wtnabe
2
380
Kanazawa.rb meetup #56 Coderetreat Intro
wtnabe
0
360
Automate WordPress deployment with WordMove
wtnabe
1
420
CircleCI Hands-on for Beginners
wtnabe
0
390
Introducing Todays CI Services
wtnabe
0
290
Other Decks in Programming
See All in Programming
【Go言語】golangci-lintの使い方
tomo1227
0
270
DMMプラットフォームにおけるTiDBの導入から運用まで
pospome
7
3k
Ruby メモリ管理 プログラミング
megmogmog1965
0
130
Mastering Developer Experience: A Roadmap for Success 【開発生産性Conference 2024】
findyinc
1
380
GraphQL はいいぞ! ~Laravel で学ぶ GraphQL 入門~
azuki
1
160
「2024年版 Kotlin サーバーサイドプログラミング実践開発」の補講 〜O/Rマッパー編〜
n_takehata
2
260
Findy - エンジニア向け会社紹介 / Findy Letter for Engineers
findyinc
2
81k
Android開発者のための Kotlin Multiplatform入門
ntaro
0
190
はしめてのプログラミングとロボット制御
watawatavoltage
0
290
The rollercoaster of releasing an Android, iOS, and macOS app with Kotlin Multiplatform | droidcon Berlin
prof18
0
110
SDCon2024: Enabling DevOps and Team Topologies thru architecture: architecting for fast flow
cer
PRO
0
780
CSC307 Lecture 13
javiergs
PRO
0
150
Featured
See All Featured
Building Adaptive Systems
keathley
34
2k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
224
21k
Refactoring Trust on Your Teams (GOTO; Chicago 2020)
rmw
29
2.5k
What the flash - Photography Introduction
edds
65
11k
Atom: Resistance is Futile
akmur
261
25k
ReactJS: Keep Simple. Everything can be a component!
pedronauck
662
120k
The Language of Interfaces
destraynor
151
23k
Why You Should Never Use an ORM
jnunemaker
PRO
51
8.9k
The Art of Programming - Codeland 2020
erikaheidi
48
13k
Teambox: Starting and Learning
jrom
130
8.6k
Designing the Hi-DPI Web
ddemaree
276
34k
What’s in a name? Adding method to the madness
productmarketing
PRO
21
2.9k
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)