Cloudflareの障害とセキュリティの議論
こんばんは、Replay.fm第62回です。
こんばんは。
こんばんは。
いやー、喉ぼちぼち。
ぼちぼちです。
喋れると思います。
はい。
おめでとうございます。
うん、なんとか。でも、世間はインフルがめちゃくちゃ流行ってるらしいですね。
あー、イエスね。
昨年の10倍らしいよ。
10倍?なんで?
なんでなんだろうね。原因とかは調べてないけど、なんかその10倍もそのパーソナルジムのトレーナーが言ってたから、ちょっと間に受けてたけど。
インフルエンザ、流行、なぜ。
なんかそもそも流行が来てるのが早いらしいね。いつもより。
あー、なんか。
確かにね。11月だもんね、まだ。
うーん、なんだろう。
今年の流行傾向は1ヶ月ほど早く。
集団生活。
香港A型。
A型にもなんか種類があるんや。なんかAかBかが流行ってて、流行ってない方もインバウンドからちょっと流行ってるみたいなの聞いたな。
でもよくわからんって感じ。
うーん。
皆さんも気をつけてください。
気をつけてください。
インフルマジなー、マジでしんどいからなー。
あ、ほんと。
言うても俺もあんまかかってない。
当分かかってないか。
記憶ないもんなー。
うん。
でもなんかインフルの辛さってその喉元通れば系じゃないというかなんか全然こう、
ほんとにしんどかったなって記憶は強いから、
ほんとにしんどかったんだろうなって気がする。
結構なんか薬出ちゃえば割とスーッと楽になる気がするけどね。
大人は、いやー覚えてねー、なんかその、
去年子がインフルにかかったんだけどさ、
子供はその熱出てから24時間以内に飲まないって意味がないみたいな感じらしくて。
うんうんうん。
大人どうなったっけなーって全然思い出せない。
大人もみたいなもんじゃない?48時間とかだった気がするけど。
あー。
どうだった?
それー、あそこだよなー。
検査キットとか手元に買う、買ったほうがいいのかもしんない。
早ければ早いほうがいいっていう感じではあると思う。
その高い薬。
あー確かにね。
サーブ。
まぁちょっと医者じゃないので、わからん。
体調が悪かったら病院。
そうですね、はい。
間違いない。専門、専門家の指示は置いてください。
じゃあそんな感じで、今週ももう嵐の前の静けさなのか知らんけど、少ないんで、
シュッシュッと、シュッシュッシュッとやっていきましょう。
いやー、ヤプシーとコードブルーの色々が出てくんのか。
そうだねー。
ヤプシー、まぁでもちょっと取りに行かないとなー、フィードを。
取りに行かないとな感じですよね。フィードに乗ってくるもの乗ってこないもの。
スピーカーデックの個人個人のスライドをちょっとフィードに継ぎ足していきたいな。この機会に。
じゃあ1個目から、セキュリティを普通にやっていく技術・体制・文化の追求。
ヤプシー不幸感2025のジーモンペッパーの方の発表ですね。
あー、この収録時間がちょうどバレるんですけど、ただいま絶賛クラウドフレアの障害にて、
スライドの中身が見れないのと、僕が読んだんですけど、
これなんかまとめるっていうよりかは読みながらここで喋りたいなと思ったんで、
サマリをまとめてなくて、僕の記憶をたどりながらご紹介という感じですね。
ありがとうございます。ちょっと僕読めなかったんですよね。読もう。クラウドフレアらしいんで。
なんか読めない。珍しいね、クラウドフレアこんなに。
あー、そうだね。それは確かに。
多分クラウドフレアからの記事、僕はフィード見てるんで、面白そうだったら来週は引っ張るかもしれない。
来週だね。どうせとか絶対ブログ出してくれると思うんで。
このスライドはJumoPepaboのセキュリティチーム、いわゆるセキュリティチームが
変遷みたいなところと、変遷を経て今何を、どういうところをどういう体制でやってるのかっていう部分を順々に紹介してくれてるって感じですね。
変遷みたいなところは、割と早めからセキュリティに対する体制というかチームみたいなのはあったっぽいんだけど、
2017、18年ぐらいにセキュリティインシデントがあったみたいで、それきっかけでちゃんと体制の見直しをして、
そこから現在5名体制なのかなっていう形っぽいです。
もともとはいわゆるシーサートみたいな色が強いインシデントレスポンスにお向きを置いたチームだったんだけど、
そこからいろいろと手を伸ばして、今時点はセキュリティチームっていうよりかはサイバーハイジーン、
僕あんま詳しくないんで勉強しなきゃと思いつつ言うんですけど、
サイバーハイジーンにお向きを置いたチームとして活動してるっていうところがあるみたいですね。
プロダクトセキュリティもやるし、インシデントレスポンスみたいなところも見るし、
コープレットセキュリティ、コープレットアイテムみたいなところも割と見てるっぽいっていう形です。
個々の施策はさすがにちょっと思い出せないんで、思い出せる範囲、ある意味僕の印象に残ったものをいくつか話すと、
例えばインシデントレスポンスだと、僕が今の会社で丸パクリしたやつがあるんですけど、
インシデント対応を支援するためのボットを内製してそれを運用してるみたいな話とか、
またセキュリティ系の施策具体は書いてあったか書いてなかったか思い出せないですけど、
例えばよくあるのは認可システム、認証システムリプレイするとかそういう開発なんだけど、
セキュリティ色の強いものとかはリードとして1名アサインして開発チームと一緒にやっていくみたいな部分をやったりとか、
あとはエンドポイントの話とか、エンドポイントセキュリティ周りはこういうところをやってますよみたいな話とか、
結構、何だろうな、本当に一通りきちんとやっているっていう感じで、
ただいいなと思ったのはその一通りのそれぞれの中で全部100点、100点って言い方おかしいな、
ペパボってどのくらいの規模なんだろうな、規模感ちょっと分かんないですけど、
エンプラみたいにガチガチにこれ一通り入れてますみたいな話っていうよりかは、
ここはこういうの入れてるけどこういうのを挟んでてとか、
あとは最近っぽいトピックだとクロードコードじゃないか、
AIを組み込んだBotにレビューをさせるみたいなところの紹介をしてあったりとか、
そういう部分がいろいろ書いてあって興味深いなっていう感じでしたね。
一応、公開されてる情報だと従業員数が402名。
なるほど、そう思うと分かんないけど、402名の割にというか、
でも一通り本当にやれてる感じがするなって。
セキュリティ対策室自体は何人ぐらいの体制なんだろう?
5人だね、CTO含めて5人。
どうだったかな、兼務かどうかの言及はなかったけど、CTOとかは多分兼務だと思うし、
それ以外の4名とかはやってる幅の広さ的には割とそれなりに時間を割いてやってるんじゃないかなって気はするね。
あと、コーポーITセキュリティのほうはコーポーIT事業が別にいるから、
そこと連携してるみたいな話もあったな。
コーポーITセキュリティは全部やってるわけじゃないって話もある気がするね。
ぜひ読んでほしいって感じだな。
その一つの形というか、400名のウェブ系事業会社でセキュリティをそれなりにきちんと、
それなりにという表現はちょっと失礼ですね。
きちんと幅広く押さえてやっていくみたいな部分に対する一つの分かりやすい回答かなっていう気がします。
こんだけ喋ったけど、Cloudflareはまだ死んでると。
しょうがないですね。
配信終わる頃にもう一回見てみようか。
そんな回ですね。
GitHub Actionsの新機能
次。
New GitHub Actions OIDC Token Claims。
GitHubのチェンジ録の記事ですね。
中身的にはGitHubのActionsのOIDCのトークンのクレームに新しいのが増えましたよっていう話で、
チェックランIDっていうのが増えたよっていう話です。
実行したジョブのID、ユニークIDがチェックランIDに入ってくるっていう話らしくて、
遠いで監査とかで役立つよっていう話なのかな。
パッと見すごいって思ったんだけど、
意外と使いどころがあるのかないのかどうなのかっていうのが分からないっていう感じではあって、どうなのか。
基本的には記事にも書いてあるけど、監査のログとして使えるって話な気がするよね。
だからこのチェックランIDを元にIoTフェデレーションの認証条件に使うっていうのは多分できないから、
きちんとログ残しておいて、Google Cloudで連携するんだったらGoogle Cloudにアクセスしたときに、
このチェックランIDをGoogle Cloud側がきちんと残してくれれば後から何かあったぞ、おかしいぞってときに、
どのGitHub上のアクションズの実行履歴およびそのジョブと、
Google Cloud側の監査ログの突合がめっちゃ簡単になるっていうのは普通に嬉しいっていう感じ。
だし逆に言うと今は突合できないから、タイムスタンプとかで長尻合わせで頑張ってやるしかない感じかな。
普通に嬉しいけど、
僕ら目線は僕らがこれ使って、
自前でOACC連携なんか作ってるんだったら多分組み込もうってなるけど、
例えばGoogle Cloud AWSで使ってる話だったら、
そっち側の対応に期待して待つっていう感じなんじゃないかなって気がする。
どうなんだろうな。
トークンのIDについての考察
なんかいまいち、今多分RunIDとRunAttemptっていうのがあるのかな。
記事の中で触れられてる。
RunID、RunAttempt。
うん。
と、RunAttemptか。
あ、RunAttemptは多分実行回数なんだよな。
で、RunIDが。
そうだね。
RunIDってこれ何入ってるの?
昔一回試したけど。
実物見ないとわかんないな。
実物見たいね。
ここの、なんていうか、
もうちょっと親切にやってくんねえかな。
ドキュメンテーションのほう。
IDはね、ちょうど手元に今、
GitHub ActionsのOIDCのトークンのサンプルがあるから見てるんだけど、
何入ってるんだろうな。
なんか数値が入ってるんだよね。
ジョブID。
ブログでジョブIDっていうか、
用語がわかんないけど、
そのActionsの実行のIDなのかもね。
そのActionsってさ、
ワークフローランか。
ワークフローランIDだもんね。
ワークフローなんじゃないかな。
ワークフローが実行されましたっていうIDはあるけど、
そのワークフローの中で複数ジョブがあるときに、
そのジョブを特定する方法は今ないって感じなんじゃないかな。
あー。
で、なんかシンプルなやつだっていいけど、
その複雑なやつだとそのジョブの数が、
それこそその、マトリックストーカーと30、40みたいなのって普通になくはないってなったときに、
その30個あるうちのどれなのみたいな。
しかも多分並列で実行されてたりすると、
タイムスタンプを突っ込むの多分しんどいから、
そう思うと普通に、
結構普通に嬉しいなって気がする。
いやー。
RANナンバーは何なんだ?
RANナンバーとRANIDの違いは?
わからないね。
RANナンバーはわからん。
あー、でも多分、
いやでも多分合ってるな。
ワークフローの、そうだね。
多分ワークフローの実行単位のIDだな。
で、確かにジョブごとのIDが付きますよっていうのは確かに。
ほんとか?なんか怪しいな。
実物みてぇな。
うん、実物見たほうがいいかもね。
うん。
いや確かに、なんかその、
Cloudflareの障害
なんて言ってるんだろうな。
リポジトリのアクション図から、
なんか適当なそのワークフローの実行履歴をクリックしたときの詳細画面があるじゃん。
うんうんうん。
で言うと、リポジトリの配下のスラーアクション図、
RAN図、数値。
多分この数値がRANIDなんだろうね。
あー、なるほどね。
そこそこのワークフローの履歴を取るAPIとか見れば、
普通に書いたりするのかな。
うんうんうん。
ヒントを増やしてくれたアザースって感じなんだろうね。
基本的に。
何が入ってんのかよくわからない。
なんかあったとき以外にあんま使わない気がするんだよな。
基本的には。
通常運用の監視で使うことあんのかな。
わかんない。
あんまないよな。
うんうんうん。
ちょっとこう動きたいということで。
うん。
基本的には何かいいアップデートではあるはず。
うん。
はい。
あっちゅーまの3つ目ですか。
クロームの新機能
クロームの新しいセキュリティ機能コネクションアラウリストについて、
明日の風ブログの記事ですね。
えーと、まあ短い記事なんだけど、
コネクションアラウリストヘッダーっていうのが、
なんかクロームのカナリーに入ってるっていう話で、
これはなんだ、なんか、
使用エクスプレイナーはGitHubで公開されてますっていうのが
記事中で言及されてるんだけど、
えーと仕組みとしては、
そのページから、
なんて言ったらいいんだろうな、
コネクションを張れる、
オリジンなのかなきっとね。
オリジンのリストをURLって書いてある内容記事の中では。
URLの許可リストをレスポンスヘッダーで指定できるようにするよっていう話らしくて、
それ以外の指定されたURL以外のリソース読み込もうとすると、
全部ブロックされるっていう話らしい。
CSPよりも単純な構文で、
外部サイトの通信を制限できるようにするっていう話で、
はい、なので結構なんかお手軽感はあっていいなと思って。
なんか正規表現とかも書けるっぽいね、プロポーザー見ると。
一応なんかオリジン、レスポンスオリジンっていうフィールド名であるから、
オリジンかもね、指定するの。
うん、良さそう。
なんかCSPと何が、
CSPあるのになんでこれが必要なんだろうっていうのの答えを自分で回答できないなと思ったけど、
そのプロポーザーの方を見たら、
いくつか書いてあって、
CSP自体が複雑すぎるっていう話とか、
あとは、CSPだと対応できないユースケースがあるみたいな、
あんまちょっと浅い理解ではあるな。
あとあれか、適用範囲か。
適用範囲でフェッチを経由するhttpxtはカバーしてるが、
フェッチ以外の接続方法を全部に対して適用されるわけじゃないよっていう部分。
DNS PrefetchとかWebRTCとかは例えば対象外みたいなことを書いて、
これはなるほどねっていう感じ。
逆にコネクションローリストの方がスコープが広いかというとそういうわけじゃないから、
多分CSPじゃないとできないこともあるし、
コネクションローリストじゃないとできないこともある。
だからどっちも実現したい場合はどっちも指定してねっていうこともプロポーザーに書いてあって、
なるほどっていう感じですね。
でもどっちも併用すると多分ちょっと運用が難しくて、
OR条件じゃなくてAND条件になるから、
例に書いてあるんだけど、
CSPで許可してるソースをコネクションローリストで指定し合わせると恥かいちゃうよっていうとかが書いてあって。
OR条件じゃなくてAND条件じゃなくてANDじゃなくてORだよね。
いや、ANDじゃないかな。
どっちも適用されないとアクセスが弾かれるから。
まあ捉え方次第か。
まあいいや。
そうですね。
トゥールホースが反転してる。
どっちのポリシーも通過しなきゃいけないっていう意味でのANDだね。
なるほどねって感じ。
でもいいよね。普通に使いやすそう。
あとリダイレクトの話もちょっと書いてあって、
その辺は議論中っていう話っぽいのかな。
でも仕様的にはどうなってるんだろう。
まあリダイレクト先もホワイトリストに入れろっていうのが現時点の仕様だけど、
まあ議論の余地があるかもみたいな感じ。
いやー、ダメじゃない。
オープンリダイレクトあったら結局意味なくなっちゃうからさ。
そうだね。
リダイレクト先もホワイトリストに入れろが多分正しいアプローチの気もするけど、
そもそも仕様上オープンリダイレクターチックなものみたいなものとかはあるかな。
でもそんななんか別にクッションページに載っければいいやん。
まあそうね。
一応このoriginはリダイレクトを許可するとか、
そういう構文を提案してもいいかもぐらいの研究があるってね。
いやしんどいって。しんどいよ。
まあまだかなりに入ったわけだし、ここからどうなるかって感じだろうね。
いやーでもいいっすね。
逆になんでこれが先にデザインにCSPが出たんだろう?
なんか全然なんも分からずに思ってるけど。
うーん。
その辺の歴史みたいなの普通に気になるな。
なんでだろうな。
うーん。
まあそうだね。
でも結局データの持ち出し、origin外の持ち出しっていうところには効果がある。
任意のスクリプト実行みたいなところに対しては全然効果がないから。
ああなるほどね。
ああ確かに。
それはそうだね。
守りたいものが全然違うっていう話は多分あるよ。
うんうんうん。
うん。
確かに。
確かに。
これがどっちかっていうと持ち出しにも効くし、
クロスタイトリークスとかにも多分効いてくるような気がするから。
ああそうだね。
うん。
確かにね。
かなり手足を縛れる仕組みというか。
うん。
うん。
確かにね。
かなりか。
まあちょっと実際に入るかどうかはわからんけどな。
ああ。
ここからどうなるかですね。
いやなんかしんどい。
疲れるか疲れるか。
いやー。
うーん。
なんかでも、いやーどうなんだろうな。
何らかにCSPに統合してきた流れみたいなのもある中で、
これをあえて作り出したまま維持するのかみたいなのがちょっと気になるし。
うーん。
うーん。
確かにね。
しかもCSPのヘッダーがさ、もうえぐいことになってるから。
うんうんうん。
そうね。
その辺は今日の話が書いてあったね。
あれをどうするんだろうね。
でも結局その、なんて言ってるんだろうな。
そのレスポンス単位でポリシーを柔軟に変えたいみたいなのをやろうとすると、
やっぱりHTTPレスポンスヘッダーでやるしかないんだろうなとは思うんだよね。
うーん。
だからウェルノーンなパスにポリシーを置いといて。
うーん。
まあでも別にポリシーのフォーマット次第か。
なんかパスを指定してこのパスではこのポリシーが適用されますよっていうのをやる。
ああ、こう。
フレームワーク内の支援がないと実装する側はしんどそうだね。
うーん。
テストもなあ、結構きついしなあ。
うーん。
レビューとか。
なんか、なんかでもそもそもそれだと絶対ダメっていう理由がなんかありそうな気がするが、
まあいいや、ちょっとパッと思いつかないからいいや。
広報期待ですね。
ありがとうございます。
おやー、終わっちゃった。
早いね。
そういえばハッシュタグでいつも楽しみに聞いてますって言ってくれてる人がいて、
初のお手紙、あざすとか。
すみません、クラウドフレアのせいで今ちょっと確認できない。
あー、ツイッターも死んでる?まだ。
うん、死んでるね。
あー、死んでるわ。
いやー、クラウドフレアちょっと。
珍しいなあ。
うーん、SLA大丈夫?
やばそうだね。
やばそうだよね。
結構いろんなところが落ちてるから。
うーん、冷や汗だよね。しかも長いしね。
ステータスペーシャルなんて言ってた?
UTCの11?
グローバルネットワークスペーシャル?
うーん。
UTCの11、48枚ぐらいから。
長いね、ほんとに。
いや、でも明日仕事できないかもしれない。
明日仕事できなかったらもうやばいな、世界が。
まあ原因は未だに気になるね。AWSもこの前派手に落ちたしな。
どうせ最後まで残ってた手動運用だよ。知らんけど。
どうせDNA線設定ミスとかするな。知らんけど。
はい。
まあそんな感じで、たぶん再来週ぐらいから来るアドベントカレンダー並みに備えつつ、
粛々とやっていきましょう。
はい。
じゃあ、
言い残したことないですか?
うん、特にないです。
はい。
はい、みなさん。
いや、ほんとに。ほんとに。
じゃあ、来週もお楽しみにしててください。
おやすみなさーい。
おやすみなさーい。
