Upgrade to Pro — share decks privately, control downloads, hide ads and more …

lightweight authenticity of microservices

088b1b43ff5dd64aa0f000da9e9da777?s=47 wtnabe
August 20, 2016

lightweight authenticity of microservices

これくらいならユーザー認証なしでやってもいいかも? みたいな割り切りの話。

088b1b43ff5dd64aa0f000da9e9da777?s=128

wtnabe

August 20, 2016
Tweet

Transcript

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

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

  3. 真正性

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

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

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

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

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

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

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

  11. 今回の⽬的

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

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

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

  15. メッセージ認証

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

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

  18. MACいいんじゃない?

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

    受信したMACを検証
  20. メリット 鍵が漏れていなければメッセージは改竄 されていないと⾔える 鍵そのものは送らないので暗号化不要

  21. HMAC HMAC: Keyed-Hashing for Message Authentication (RFC 2104) MACを⽣成するアルゴリズムにハッシュ 関数を利⽤する

    ハッシュ関数は反復利⽤される 鍵もそのまま利⽤するわけではない
  22. 詳しくはおぐぐりください

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

    - Amazon Simple Queue Service SSH Protocol 2 integrity
  24. 今回の設計

  25. マイクロサービスなWebAPI

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

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

  28. 事例もある SSH, AWSはデカイ

  29. インターネット越しでも HMACでお⼿軽 マイクロサービス

  30. 参考 HMAC: Keyed-Hashing for Message Authentication (RFC 2104 / IPA)