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
460
lightweight authenticity of microservices
これくらいならユーザー認証なしでやってもいいかも? みたいな割り切りの話。
wtnabe
August 20, 2016
Tweet
Share
More Decks by wtnabe
See All by wtnabe
Effective Jekyll
wtnabe
0
51
5 min Jekyll/Liquid Plugin cooking
wtnabe
0
24
Ruby de Wasm
wtnabe
0
49
Cloud Native Buildpacksって結局どうなの?
wtnabe
0
41
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
450
one case of how to begin vuejs
wtnabe
2
460
Other Decks in Programming
See All in Programming
はじめてのWeb API体験 ー 飲食店検索アプリを作ろうー
akinko_0915
0
160
脱Riverpod?fqueryで考える、TanStack Queryライクなアーキテクチャの可能性
ostk0069
0
560
階層化自動テストで開発に機動力を
ickx
1
410
SQLアンチパターン第2版 データベースプログラミングで陥りがちな失敗とその対策 / Intro to SQL Antipatterns 2nd
twada
PRO
26
8k
コーディングエージェント概観(2025/07)
itsuki_t88
0
120
なぜあなたのオブザーバビリティ導入は頓挫するのか
ryota_hnk
0
350
状態遷移図を書こう / Sequence Chart vs State Diagram
orgachem
PRO
2
250
PHPカンファレンス関西2025 基調講演
sugimotokei
5
920
Android 16KBページサイズ対応をはじめからていねいに
mine2424
0
640
20250704_教育事業におけるアジャイルなデータ基盤構築
hanon52_
5
1.2k
Porting a visionOS App to Android XR
akkeylab
0
910
The Modern View Layer Rails Deserves: A Vision For 2025 And Beyond @ RailsConf 2025, Philadelphia, PA
marcoroth
2
780
Featured
See All Featured
Balancing Empowerment & Direction
lara
1
490
Thoughts on Productivity
jonyablonski
69
4.7k
Chrome DevTools: State of the Union 2024 - Debugging React & Beyond
addyosmani
7
760
CSS Pre-Processors: Stylus, Less & Sass
bermonpainter
357
30k
Building Better People: How to give real-time feedback that sticks.
wjessup
367
19k
Embracing the Ebb and Flow
colly
86
4.8k
For a Future-Friendly Web
brad_frost
179
9.8k
Fireside Chat
paigeccino
37
3.5k
"I'm Feeling Lucky" - Building Great Search Experiences for Today's Users (#IAC19)
danielanewman
229
22k
JavaScript: Past, Present, and Future - NDC Porto 2020
reverentgeek
50
5.5k
GitHub's CSS Performance
jonrohan
1031
460k
Docker and Python
trallard
45
3.5k
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)