Update とは何かそして何であるべきか #cloudnativejp / Cloud Native Meetup Tokyo 2nd

by y_taka_23

Slide 1

Slide 1 text

Update とは何かそして何であるべきかチェシャ猫 (@y_taka_23) Cloud Native Meetup Tokyo #2 (2018/06/01) #cloudnativejp

Slide 2

Slide 2 text

gem update docker-api #cloudnativejp

Slide 3

Slide 3 text

pip update docker-py #cloudnativejp

Slide 4

Slide 4 text

docker pull nginx:1.14 #cloudnativejp

Slide 5

Slide 5 text

ソフトウェア更新の仕組み ● 抽象化すると単純 ○ 新しいバージョンの有無を検知 ○ もしあれば新バージョンをダウンロード ○ ローカルマシンへのインストール ● 通信路は TLS で保護できる ○ 通信相手の認証・暗号化・改ざん検出 ○ そもそも Chrome では HTTPS がデフォルトに #cloudnativejp

Slide 6

Slide 6 text

ご清聴ありがとうございました Presented by チェシャ猫 (@y_taka_23) #cloudnativejp

Slide 7

Slide 7 text

んな訳ない #cloudnativejp

Slide 8

Slide 8 text

通信路以外にも危険が ● 更新時系列の詐称 ○ 古い脆弱なバージョンをダウンロードさせる ○ 更新があるのにないかのように見せかける ● 鍵危殆化、例えば秘密鍵の流出 ○ サーバやファイルの正当性が信用できなくなる ● 悪意あるサーバの挙動 ○ 無限ストリームデータを送ってくるなど #cloudnativejp

Slide 9

Slide 9 text

考えるべきことは結構多い #cloudnativejp

Slide 10

Slide 10 text

The Update Framework https://theupdateframework.github.io #cloudnativejp

Slide 11

Slide 11 text

TUF プロジェクトの概要 ● ソフトウェア更新のフレームワーク ○ 安全な更新を実現する ○ 何を配布するかに依存しない汎用的な仕様 ○ 公式の（参照）実装は Python ● 更新の検知とダウンロードをサポート ● 実はプロジェクトとしては割と古い ○ 元になった論文は 2010 年 #cloudnativejp

Slide 12

Slide 12 text

#cloudnativejp

Slide 13

Slide 13 text

TUF の利用事例 ● 既に導入されている事例 ○ Docker Hub (Notary) ○ DigitalOcean ● 現在、対応が計画されている事例 ○ RubyGem ○ PyPI ○ Hackage (Haskell ライブラリ) #cloudnativejp

Slide 14

Slide 14 text

TUF レポジトリの構造 #cloudnativejp

Slide 15

Slide 15 text

TUF レポジトリの構造 #cloudnativejp

Slide 16

Slide 16 text

TUF レポジトリのメタデータ ● それぞれ別の Role として署名する ○ root : 他のメタデータ用の信頼済み鍵リスト ○ targets : 配布ファイルのサイズとハッシュ値 ○ snapshot : 他のメタデータのサイズとハッシュ値 ○ timestamp : snapshot のサイズとハッシュ値 ● 全体として整合している必要がある ○ クライアントは timestamp で更新の有無を判断 #cloudnativejp

Slide 17

Slide 17 text

TUF レポジトリの構造 #cloudnativejp

Slide 18

Slide 18 text

TUF レポジトリのターゲット ● 実際に配布するファイルを格納 ○ サイズとハッシュ値の一覧を targets.json に記録 ○ デフォルトで targets.json 用の Role で署名 ● 信頼の委譲 (delegation) ○ ディレクトリ構造の一部を他の Role として署名 ○ ライブラリ用のレポジトリなどが典型例 ○ Role の信頼関係のチェーンをメタデータに記録 #cloudnativejp

Slide 19

Slide 19 text

信頼の「閾値」の設定 ● Role に対して署名鍵を複数登録 ○ 署名には必ずしも全鍵を使用しなくてもよい ● 信頼に必要な鍵の最低個数を設定 ○ 登録された内、その個数以上が使われていないと正当なファイルであるとみなされない ○ 一度に複数の鍵が危殆化しない限り安全 ● 閾値は Role ごとに設定できる #cloudnativejp

Slide 20

Slide 20 text

Role の階層構造 Library-1 ● file-1-1.txt ● file-1-2.txt Library-2 ● file-2-1.txt Targets ● target.json Root ● root.json Snapshot ● snapshot.json Timestamp ● timestamp.json #cloudnativejp

Slide 21

Slide 21 text

Role による責任の分離 Library-1 ● file-1-1.txt ● file-1-2.txt Library-2 ● file-2-1.txt Targets ● target.json Root ● root.json Snapshot ● snapshot.json Timestamp ● timestamp.json #cloudnativejp

Slide 22

Slide 22 text

閾値による鍵危殆化耐性 Library-1 ● file-1-1.txt ● file-1-2.txt Library-2 ● file-2-1.txt Targets ● target.json Root ● root.json Snapshot ● snapshot.json Timestamp ● timestamp.json 1 < root.threshold = 2 #cloudnativejp

Slide 23

Slide 23 text

まとめ ● ソフトウェアの更新は落とし穴が多い ○ 真面目に個別に考えようとすると大変 ● TUF は安全な更新機構を提供 ○ 何を配布するかに依存しない汎用フレームワーク ● 安全性を実現する二つの柱 ○ 署名されたメタデータによる最新性の保証 ○ 権限の分割と閾値設定による危殆化への耐性 #cloudnativejp

Slide 24

Slide 24 text

Update Your Knowledge! Presented by チェシャ猫 (@y_taka_23) #cloudnativejp