次世代 Web カンファレンスに行ってきた
Web の今とこれからについて、スライドによる発表ではなくて、複数の登壇者による議論をするという体裁のイベントです。本当にその場でリアルタイムに喋ってる、筋書きどこまで作ってるかはセッションにもよる気がしますが資料というものは存在しません。録画は公開されるみたいです。カンファレンスの中でパネルディスカッションが数セッション用意されることは珍しくないですが、朝から夜まで全部議論という場は初めてでとても刺激的でした。どんな話が出てくるかわからないし、登壇されてるのは一線で活躍されている方々なので、多くの情報も様々な思いもお持ちでいろんな話がどんどん飛び出してくる。ハッシュタグはセッション別に用意されているので、 Twitter でも並行して様々な話が進んでだいぶインプット過多な感じで最後のほうはちょっとぽわっとしてました。
SRE、Security、Microservices、HTTPS、HTTP/3の5セッション聴きましたが、特に日常業務に近い SRE と HTTPS で実入りが大きかったように感じます。
SRE は SRE book を軸として、各社実際にどういった形で運営、運用しているのかという話が聴けたのがよかった。 Error Budget は今回参加された方々の社ではいずれも適用してないとか、プロアクティブな運用（いわゆる改善とか運用のための基盤づくりとか）とリアクティブな運用（≒Toil）をいかに 50:50 で維持するかの話とか。SRE は個々の技芸によるものではなくて、組織運用の話であり、マイクロサービス化に従って個々のサービスオーナーチームにセルフサービスなオペレーションをどんどん渡せるようにしていくべき、みたいな話にはとても同意しましたし、だからこそ SRE をよく言われる「ソフトウェアエンジニアリングを導入したインフラエンジニア」としてだけ捉えてしまうと立ち行かなくなるんだよな、みたいなことは思いました。どちらかと言えばシステムの基盤や、 Toil の発生を如何にマネージするかが肝になるので、単に実装技術があるだけじゃダメで、もっとマクロな視点で動けないとあかんのですよね。自分はこれが弱い。
HTTPS の話は言うまでもなく昨今 Symatenc やら Google やらの界隈がとても元気で、私も去年は実務上多くの影響を受けたりもしたのですが、とても動きが激しい過渡期にあるので未来を見渡すのが面白いし、それがまた必須にもなってくるよね、という感想です。ただ証明書の話にせよ、 Signed HTTP Exchange の話にせよ、常に Google の影がチラついていて、基本的にはコンテンツホルダーである企業がウェブの実装やら仕様やらの話にまで極めて大きい力を持っている現状はどうなんだろうな、ということは強く思います。悪い方向になっている、と言い切るわけではないし改善がもちろん進んではいるんだけど、それを駆動しているのが Google って形は正しいのかなとか。あとこのセッションで出た話だと、 TLS 1.4 以降はどうなるという話の中で、Post-quantum cryptography 、要は量子コンピュータ実用化後における暗号の危殆化の話に言及があったのが「めっちゃ次世代やん」って感じで知的好奇心をくすぐられました。
今回のイベントでは15セッションが設けられていて、一応 Web の末端で働いている自分にとっても埒外なフロントエンドの話とかそういうのもあって、一口に Web と言っても切り口は無数にあるし、学ぶことまだまだ多いなと感じた1日でした。SRE 方面に自分も向かうことになる気がするので、そちらの技術力高めるのと、あんまり仕様とか読んでないので HTTP/3 や TLS 1.3 について少し掘ってみよう、などと思っています。
以下、当日のメモを特に編集せず貼りますカオスです。
10:00 SRE
ソフトウェアエンジニア的なことしてる比率
プロアクティブ : リアクティブ = 50:50 が目標（Mercari）
タスクのラベルで管理
Site Reliability Engineering 記載の「Toil 50%」
https://twitter.com/tagomoris/status/1084256565446627328
直ちに割合調整するというより、クォーター末の時点で振り返り、次期クォーターのコントロールに活かす
タスク量（Toil）の可視化
本来やりたいこと（ロードマップ）が進んでいるか否か
ベロシティが落ちたら割り込みとみなす
オンコール、インシデント対応、ポストモーテム
週次でオンコールの振り返り、大きいインシデントについてはポストモーテム（Cookpad）
平日毎日振り返り、ポストモーテムは全エンジニア書く、SLO侵害以外でも重大なバグなども（はてな）
モノリス時代と Microservices 時代で異なる（Mercari）
モノリスは SRE が受ける、インシデントレポートをコール受けた人が書く、slack でインシデント共有
長期的な問題管理は「リアクティブ」？
長らく解決されてない問題はロードマップに組み込む = プロアクティブ扱い（はてな）
Error Budget
Microservices ではサービスごとに SLI, SLO マストにしている（Mercari）
現状だとエンジニアが決めててよくない（本来はCTOとかプロダクトオーナーが持たないと妥当性が持てない）
モノによっては 99% とかでもいいと思っていて、それを決められる議論の場がなければいけない
SLO 向上とタスク数のトレードオフの意識、特にビジネス側への理解を進めるが大事
Error Budget ははてな、Mercariともに使ってない
アラートの設定は？
開発者がしている、Datadog + slack or PagerDuty（Mercari）
Microservices はオンコールも開発者宛
Zabbix → Prometheus （Cookpad）
オペレーションのセルフサービス化
マージまで開発者ができる、DBのスキーマ変更まで含めて （Cookpad）
AWSを勧めてセルフ化させたりしていた、それだけじゃないので一方で開発も（はてな）
Microservices 化が進むと中央集権的なデプロイチームはボトルネックになるので、開発からデプロイ、運用全部各チームに渡してる（Mercari）
GCP（マネージド） + Terraform を使ってインフラが作れる、 kubectl も渡してる
SRE （プラットフォームチーム）はデプロイのための基盤を提供する役割
セルフサービス化が進むと SRE は集中的なものではなくなる？
開発者にできること増えて「溶け込んで」いく
99.9% 以上は開発者だけだと厳しい、専門としての SRE は要るかなと言う感覚（Mercari）
運用→SRE ≒ 技芸（ウェブオペレーション）→科学（計測可能）
生存戦略
システムを理解したソフトウェアエンジニア、科学的なアプローチにトライできる人（Cookpad）
ソフトウェア書けるのは当たり前として、マネージドサービスとの勝負（仕事が奪われる）中でどれだけ創造性が発揮できるか（はてな）
SRE、SLOというのは技芸ではなく組織の話として広がるといい（mercari）
11:10 Security
最近のセキュリティインシデント事例
CDN のおもらしの話（Mercari, LINE）
CDNでキャッシュをしない設定にしていたけど0秒間キャッシュがされていて、同時にリクエストすると他人のレスポンスが表示される
Wordpress
EC-CUBE
簡単につかえてしまうが故に、「ちゃんと使ってなくて」という事例が多い
Wordpress はプラグインを「完全に信頼」しているのでそこに脆弱性が入り込む
パッケージバージョン管理
バージョン固定すれば変なのが入り込まない、固定しちゃうとアプデがめんどい
CVE 全部読む（バグの傾向が掴めたりとかある）
ブラウザの脆弱性
ブラウザ側が気にするべき問題なのにアプリで気にするのは嫌
「脆弱性のあるブラウザを使ってるやつが悪い」
cookie は未来永劫カチッとしない
サードパーティ Cookie の問題
Double Submit Cookie
X-FRAME-OPTIONS によるクリックジャッキング対策( https://www.jpcert.or.jp/tips/2010/wr103601.html )
脆弱性対策でこういうヘッダが増えてきた
意味がわからなくて付けてると外されたり
DNS の TXT レコードも似た感じで便利に使われてる
こういうヘッダ、対策全部入りみたいなのほしい
CSP
コンテンツセキュリティポリシー (CSP) | MDN( https://developer.mozilla.org/ja/docs/Web/HTTP/CSP )
開発、実装時に面倒、不便
CSP レポートに拡張機能のものなどノイズが出る問題
GDPR
Opera には勝手に同意する機能があるらしい
Machine Readable にして、ブラウザに許可／不許可を設定しとくと勝手にやってくれたりしたらいい
Coinhive の件も header でマイニング許可／不許可宣言してみたいなすれば解決するんでは
JavaScript の実行に同意を求める世界も（あの判決によっては）来るんでは
「一般ユーザーに認知されてる」ってどの範囲の話？
AdTech
広告関連のカンファレンスでセキュリティとプライバシーの話があんまりない
例
ターゲティング広告が JSONP で配信されていて個人の情報が無関係なサイトに配信されてる
プライバシーについては被害の金銭的な計量がしづらい
どうすれば意識高められる？
被害の定量性がないので放置されがち
QUIC とか新しいプロトコル、あるいは独自のプロトコルになるとキャプチャしづらく検証もしづらくなっている
難読化する自由 vs エンドユーザーが検証、確認できる自由
13:30 Microservices
分散トレーシング
全部トレースしてるとレコード1回の write が単純倍になったりする
リクエスト時に統一のIDを付けて、各サービスのログにID吐いておくことで必要時は grep
各サービスでのログの粒度がまちまちになる問題
Chaos Engineering
「お客さんにバレなければいい」
Netflix がやっているのはクリティカルじゃない部分だったり
ビッグプレイヤーがやっているからって猿真似すればいいわけではない（前提条件が違ったり）
Service Mesh
Kubernetes とかで入れるの面倒じゃなくなっていくなら入れるの当たり前になったらいいんでは
gRPC
言語選択
使いたいプロトコルへのライブラリの対応
対抗側の言語が読めない場合の問題
レガシーな言語やマイナーな言語をやっていると人が採れない問題
人数が増えると Microservices 化するのが自然では？
1つの大きなチーム、となるとマネージが大変、分かれざるを得ない
ピザ2枚ルール
14:40 HTTPS
PKI, CA 周り
Symantec の話
当時シェア3割あったらしい、が、それでも distrust できてしまうという前例になった
CA Browser Forum に違反した証明書を発行してしまっていた
それに対してなかなか対応できていなかった
Chrome による BAN
日本の GPKI
適切な証明書運用ができていなかったことの Mozilla からの指摘
Certificate Transparency によって衆人環視ができるようになってしまったために、魔女狩り的に CA が受難していないか
CA の責務が重すぎる？選択肢が減ってしまう？
(chroju) ブラウザ側の実装（ていうか chrome ）がインターネット全体を振り回している感はある
ルート認証局は増えてるが、DV でいいなら EV の必要性ってなくなるのか？みたいな話とか、需要は減ってる？
増えてはいるが、増え方が歪、ブラウザベンダー（ Google ）がルートCAに参入している、という掟破り
TLS の認証と信頼は別
HTTPS for Everywhere の浸透によって
証明書は FQDN を「認証」しているだけ
EV が信頼されなくなってきた
EV証明書を使用して既知の企業になりすませる可能性が指摘される | スラド セキュリティ( https://security.srad.jp/story/17/12/15/2110233/ )
Identity Verified という証明書、イギリス？ iOS で悪用するケース？
Stripe と同じ名前の証明書を別の州で取られる事例があった
TLS 周り
TLS 1.3 正式化
後方互換性配慮が大きいために、そこまでドラスティックじゃないように思える
Qualys SSL Labs - SSL Pulse( https://www.ssllabs.com/ssl-pulse/ )
SSL Pulse Trends( https://kjur.github.io/www/sslpulsetrend/index.html )
TLS 1.0, 1.1 の廃止は大変
ブラウザはいいとして、 wget やらライブラリやらが結構ハマる
TLS 1.2 は残って TLS 1.3 が 4,5 に上がっていける
変なミドルボックスにも1個1個対応するようなアップデートの実績が採れたので、今後はそれを続ければいい
なので取りあえず1.2, 1.3 に上げてもらう
1.4 以降
Post Quantum の暗号危殆化への対応が必要になるはず
RSA 、素因数分解に依存しているやつがマズい
SHA とかは bit 数上げれば大丈夫なはず
HTTPS
HTTPS を守るための機能があまりうまくいってないんではないか（ Strict HTTPS, Public Key Pinning, HSTS ）
セキュリティによろしくなくなった場合の Alternative が必要では
土管のセキュリティに特化しすぎた、土管が崩れるとすべての通信が崩れる
HTTPS 対応したフィッシングサイト
Signed Exchange
WebPackaging の Signed HTTP Exchanges | blog.jxck.io( https://blog.jxck.io/entries/2018-12-01/signed-http-exchanges.html )
amp で Google の URL 出すんじゃなくてコンテンツに署名されてればオリジンの URL 出せる
土管ではなく土管の中の信頼性の担保
URL で信頼性を保つことの限界
コンテンツの信頼性が担保されるのであれば、それが amp, CDN で来たのかオリジンからなのかは意識する必要がなくなる
自分でデプロイするのは難しく、 CDN が全部やってくれるとかになるんじゃないか
16:10 HTTP/3
Transport Protocol TCP → QUIC
HTTP なのに TCP じゃないんだ？？？
アッパーの部分、セマンティクスは変わらず下のほうが変わっているって点では 1.1 → 2 と変わらんのでは
HTTP over QUIC じゃないんだ？？？
Google と IETF それぞれに QUIC の実装があって区別ができない（後者は QUIC2 と呼ぶことにはしたが）
HTTP のバージョンを上げないと HTTP over QUIC と HTTP2 をログ上識別できない
TCP の限界 → UDP
平文なので外部からの攻撃に弱い
レイテンシー上のボトルネックになりつつあった
TCP → QUIC (UDP) になって実際に通信が可能か
ミドルボックスの対応の問題
TCP の特定のパケットを見ているやつがいたりするので暗号化したりして見られないようにしたり
NAT のタイムアウト値
UDP 443 通るのか
コネクションID
コネクションの確立にはコネクションIDが使われる
ロードバランシングでもコネクションIDを見て振り分けを行う
HTTP/3 の恩恵
回線品質が高い日本でも恩恵はある？
モバイルについてはパケロスが多く、輻輳制御が効いてくる可能性
QUIC が向かない例
データセンター内の通信
アプリケーションレイヤーのプロトコルなので、End-to-End が近すぎると kernel - アプリケーション間の通信ボトルネックの割合が大きくなってしまう
パケロスも少ないので恩恵が薄い
標準化にもっとみんな関わってみよう