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
430
lightweight authenticity of microservices
これくらいならユーザー認証なしでやってもいいかも? みたいな割り切りの話。
wtnabe
August 20, 2016
Tweet
Share
More Decks by wtnabe
See All by wtnabe
Effective Jekyll
wtnabe
0
13
5 min Jekyll/Liquid Plugin cooking
wtnabe
0
4
Ruby de Wasm
wtnabe
0
28
Cloud Native Buildpacksって結局どうなの?
wtnabe
0
22
Decoupled System with Turbo Frame
wtnabe
1
82
join-kanazawarb-or-7years-passed-since-it-was-borned
wtnabe
0
740
let-me-edit-with-editor
wtnabe
0
300
google-photos-and-storage-and-rclone
wtnabe
0
400
one case of how to begin vuejs
wtnabe
2
430
Other Decks in Programming
See All in Programming
各クラウドサービスにおける.NETの対応と見解
ymd65536
0
250
functionalなアプローチで動的要素を排除する
ryopeko
1
190
令和7年版 あなたが使ってよいフロントエンド機能とは
mugi_uno
10
5.1k
chibiccをCILに移植した結果 (NGK2025S版)
kekyo
PRO
0
130
Simple組み合わせ村から大都会Railsにやってきた俺は / Coming to Rails from the Simple
moznion
3
2.1k
はてなにおけるfujiwara-wareの活用やecspressoのCI/CD構成 / Fujiwara Tech Conference 2025
cohalz
2
2.7k
非ブラウザランタイムとWeb標準 / Non-Browser Runtimes and Web Standards
petamoriken
0
430
Azure AI Foundryのご紹介
qt_luigi
1
180
いりゃあせ、PHPカンファレンス名古屋2025 / Welcome to PHP Conference Nagoya 2025
ttskch
1
170
asdf-ecspresso作って 友達が増えた話 / Fujiwara Tech Conference 2025
koluku
0
1.4k
PSR-15 はあなたのための ものではない? - phpcon2024
myamagishi
0
400
Итераторы в Go 1.23: зачем они нужны, как использовать, и насколько они быстрые?
lamodatech
0
1.4k
Featured
See All Featured
Rails Girls Zürich Keynote
gr2m
94
13k
Speed Design
sergeychernyshev
25
730
Principles of Awesome APIs and How to Build Them.
keavy
126
17k
It's Worth the Effort
3n
183
28k
Automating Front-end Workflow
addyosmani
1366
200k
Java REST API Framework Comparison - PWX 2021
mraible
28
8.3k
Design and Strategy: How to Deal with People Who Don’t "Get" Design
morganepeng
127
18k
Mobile First: as difficult as doing things right
swwweet
222
9k
Docker and Python
trallard
43
3.2k
GraphQLとの向き合い方2022年版
quramy
44
13k
BBQ
matthewcrist
85
9.4k
We Have a Design System, Now What?
morganepeng
51
7.3k
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)