サッカー日本代表のワールドカップを振り返る
こんばんは、Replay.fm第94回です。 こんばんは。
7月2日の収録ですけれども、はい。 ブラジル編は見ましたか? 見てないっす。
そうです。いやー。 結果だけ、結果だけ知ってます。 結果だけ知ってる?いやー
一緒にリアルタイムで見てた人は、ぜひね、気持ちを分かち合いたい。
おつかれさまでした。 おつかれさまでしたね。 また来年。
また4年後っすね。 いやでも本当に楽しかった。楽しかった。
本当に次は下等になってきました。
ネタバレになるのかな?もう流石にニュースで見てる人。 ニュースで流れてくると思うから、興味ある人は。
しゃべっちゃうけど、リアルタイムで見てた気持ちとしては、
まあ、7-3で負けるかなみたいな。
勝率3割かなみたいな感じで、前半、なかなか緊張感のある中で、
1点劇的に取っちゃって、いけるの?いけるのだよみたいな気持ちで、
折り返して1点取られて、いやー日有り夜みたいな感じで、
最後のモロスタイムで、残り3分とかで、頼むに、もう延長で頑張ろうみたいなところで、
スポット入れられてしまって。 あーそんなとこでそうなんだ。
もう本当にね、本当に直前の直前。 残り3-4プレイしかできないみたいなタイミングで入れられちゃって。
で、本当にね、だからもう、まあ当人たちは当然のことだけども、
リアルタイムで見てた人はみんな頭抱えて、だから寝れなかったもんな、悔しい。
結構ね2日ぐらい引きつった、なんか。いやーあの負け方はちょっと。
いやー厳しいね。厳しい。
4年に1度の大舞台で勝てば間違いなく伝説で相手がブラジルで、
しかもなんか生地インターネットのね、同じ気持ちの人を探してる中で、
それなって思ったけど、今までだったらブラジルみたいなクソ強い国と当たった時に、
今負けた時の感想ってまあまあ負けるよねみたいな、お疲れ様ですみたいな感じだったけど、
なんか今回はなんか価値筋がないこともなかったというか、
悔しいと思えるのが成長だよねみたいな気持ちで。
なるほどね。
そうそう、まあそうしてお疲れ様でしたって感じですね。
いや人生あと何回、なんか。
そうだね。
マルトガップ完成できるんでしょうね。
34ですか、私たちも。
今年34の、今年度34の年ですけど。
いやでもなんか生きてるうちに優勝見れるかもなって気持ちにさせてくれたわ、なんか。
夢があった。
頑張ってほしいっす。
いい話ですね。
はい。
是非ね、まあサッカー興味ある人引き続きワールドカップは続いてる。
いやブラジル優勝してほしいんだよな、こうなったら。
なるほどね。
そう、優勝国に負けたっていう。
これで次あっさり、いやでもな、まあまあまあ、はい。
こんぐらいにしときますけど。
GitHub Actionsのキャッシュ機能変更とNPMのセキュリティ強化
まあセキュリティの世界は平和というか、
まあなんかFIFAの偽サイトの注意喚起ぐらいサッカー絡みだと思う。
そうなってた。
まあもう名物というか、オリンピックの時とかもありましたけど。
それぐらいですけど。
まあまあまあ、平和な中で読んでいきますか。
じゃあ一番最初お願いしようかな。
Read Only Actions Cached for Untrusted TriggersというGitHubブログ、チェンジログの記事ですね。
これ中身あんまり理解してないんだけど、ものすごく平たく言うと、
プルリクエストターゲットとイシューコメントと、
フォークのプルリクエストのワークフローラン、
でキャッシュがRead Onlyになるよっていう話という理解でいいのかな。
Actions Cachedのキャッシュ。
そうだね、トリガーはいくつかあるのと、
あとトリガーする人にも依存するかな。
って書いてあったっけ。
The trigger event untrusted, meaning someone doesnot respond to it correctly and can trigger theevent.
メンテナー以外がトリガーできるようなもの。
だからそれがこれっていう話か。
もうちょっと複雑なあれだった気がするけど。
でもそんなもんか。
なんかデフォルトブランチかどうかとか関係ないんだっけ。
デフォルトブランチのキャッシュに書き込みができんぞって話か。
ブランチキャッシュは別に好きにできるっていう話かな。
そうだね。
これはありがとうというか、
着々とできるところからGit of Actionsもやるべきみたいな話が進めてくるとか。
遅くねえ感は正直ちょっと思わんでもないけど、
でもやってくれるだけありがてえって話なんだけど。
これも多分普通にブレイキングチェンジというか、
ものによってはデフォルトブランチのパフォーマンスがワンチャ落ちるのかな。
今まではフィーチャーブランチでキャッシュされたものを
デフォルトブランチで恩恵を受けられたものが完全にもうアイソレーションされちゃうみたいな話だから。
まあでもそうね。
まあでもターゲットを考え、トリガーのイベントを考えたときにさ、
そんなでもなさそうじゃない?どうなの?
キャッシュの使い方によるとしか言いようがないんだけど。
そうね。それはそうだけど。
例えばキャッシュも50MBだっけ、上限があるから。
ケースバイケースだと全然影響ないパターンもあれば、
意外と影響あるパターンもあり得るって感じがするね。
あんまりないのかな。
ないことはないだろうけど、どうなんだろうね。
ターンスタックの例が確かキャッシュポイズニングだったと思うから、
まあいくつかのケースはこれで防げるかもねみたいな、
期待したいところですね。
これを紹介してるブログの方があった気がしてて、
それで触れてた気がするんだけど、
気のせいかな、別の記者あったっけな。
ちょっと忘れちゃったけど。
ありがとうございますって感じですね。
キャッシュなんでね。
これで壊れるようなワークフローは多分もともと壊れる運命にあったんで、
そんなに気にしなくていいかなという気持ちですけど。
そんなところですか。
そんなところですね。
いい話ですね。
実際にもサプライチェーン対策でGitHubのブログのやつですね。
NPMR's Preventive Account Protection for HighImpact Accountsっていうチェンジで、
何かっていうと、
これ具体的に基準書いてあったかちょっと思い出せるんですけど、
乗っ取られたときにやばいアカウントです。
めちゃくちゃ頭悪い表現すると、
乗っ取られたらやばいNPMのアカウントのパスワードが更新されたり、
2FAの再設定がされた場合、
72時間そのアカウントはリードオンリーに強制的になりますっていう変更が入りましたっていう話ですね。
いやーこれはまあね。
結構不便に倒しているというか、
本当にリードオンリーになるみたいなんで、
例えば自分の設定画面とか、
NPMって組織みたいな機能があるんですけど、
そういう組織の読み取りみたいな情報は全部見れるんだけど、
パッケージを動向するとかそういうものは全部できなくなりますっていう。
72時間以内に乗っ取られちゃったっていうのをNPMに報告すれば対応できるっていう部分なんで、
NPMアカウントの乗っ取りみたいなところに対する、
対応を入れてきたなっていうような感じですね。
72時間っていうのがデータを見て決めたのかどうかちょっと言及がなかったんだけど、
どういう塩梅なんだろうね。
最終的にはエイヤで決めてると思うんだけど、
まあでもいろいろ見てる気はするね、当然。
いやーしかしな。
しかしどうなんだろうね。
なかなか難しいというか。
なんか諸説あるかな。
まあでも基本的にはこっちの方が守れるものが多いんだろうな。
諸説的なトレードオフね。
うん、トレードオフね。
全然もうコードが枯れててほとんどメンテする必要ないですみたいなものの依存に、
たまたまデカめの脆弱性がツルに対応したいんだけどみたいな時とかさ、
なんか久々に入ろうとしたらパスワード忘れててみたいな。
なんかでもさすがにエッチケースかなと思うし正直。
そうね。
まあ難しいところだね。
あんまり、あれか、
Email変更か2FAのリカバリコードを使った場合か、
なんか結構エッチケースというか、
普通にメンテしてて頻繁に起きるような場面ではない気はするから、
不便で困る場面よりも乗ってられるのを防げる方が多そうな気はするけどね。
ちゃんとメンテしてる人は今時だったらみんなパスキーを設定しててほしいなという気はしているので、
なんかまあ、まあでもそうね、そのパスキー突っ込んでるやつ、
何かで積んじゃったみたいなときに2FAのリカバリコード使うとか、
まあなくはないと思うけど、
まあ致し方なしな感じはするな。
そうですね。
あとはなんかその乗っ取られてるアカウント傾向が、
もしなんかその放置されてるようなやつが乗っ取られてるんだとしたら、
その放置してるように72時間以内に気づけないっていうパターンもあると思うから、
その辺はちょっと今後の。
まあっていうのもあるけど、
これ乗っ取りだっていうのを、
なんていうか、
NPM側で監視してんじゃないかな、何かしら。
そのリードタイムを稼ぐための72時間っていう可能性もあるから、
必ずしも持ち主の対応を望んで72時間ってことはないかもしれないね、それで言うと。
なるほどね、確かに。それは確かに。
そっちのほうからね。
まあそんな感じなんで、
NPMアカウント、NPMパッケージをメンテナンスしてる皆さんはご留意ください。
さすがになんかメアド変更の手前とかでは警告出るかもね。
そういうふうなリカブリ行動のときはどうなのかちょっとわかんないですけど。
はい。
ChainGuardによる新しいCI/CD基盤とPACT仕様
じゃあ次も微妙にサプライチェーンの話ですけど、
チェーンガードのブログで、
素晴らしい。
これちょこちょこ出てたやつだよね。
そのチェーンガードを通して使うといいよみたいなやつだよね。
そうだね。
というかものとしてはチェーンガードが丸っとクローンなのか同期してるのかわかんないですけど、
有名なところみんながよく使うアクションズをチェーンガードがメンテしてそれを使っていいよっていう。
違うか。
ごめんなさい、完全に間違えました。
違う話ですか。
今のは違う話なんで忘れてください。
普通にあれだ、GitHub Actionsを作りましたって話だね、チェーンガードが。
なのでCACD基盤を作って、それをベータで提供しましたよっていう話ですね。
特徴はいろいろあって、LPぜひ興味のある方は見てくださいって感じなんですけど、
基本的には今のGitHub Actionsに対してサプライチェーンで刺さっている、
要因になっているような仕様をそもそも防ぐような機構が入ってる。
プレリクエストターゲットアビューズっていうものは完全にアクションズなさしたなと思うんですけど、
っていうのが入ってたりとか、ログをちゃんと出すとか、
あとディペンデンシーの部分で固定するのかなんのかとか、
あとタグハイジャックとかそういう部分を対策したランタイムが出ましたよっていう感じですね。
結構さらっとこういうものが出始めてますよっていう。
チェーンガードも思想強めな感じはするんで、
GitHub Actionsを世間使うっていうよりかは、
世界のものを作ってどんどん用意していくっていう風に動いてるなっていう感じはするんですけど。
良さそうという気持ちと、こういうのに課金していかなあかん時代なのかなみたいな。
いくらぐらいになるのかな?
プライシングは出てる?
プライシングは出てないね。ベータだから。
ベータはたくさん出してますよ。
別にGitHub Actionsも無料じゃないじゃん。
費用面で見て移行する価値があるんだったら全然いいかなとは思うし、
ただ完全にGitHub Actionsから出しましょうってなった時に、
これが一番の選択肢になるかというとどうなんだろうなとはちょっと思うな。
あんま話題に上がんないけど、サークルCIとかもう死にせのCIとかどうなんだろうね。
その同じ体制が、体制中か。
サークルCIとかもう何年も使ってなさすぎて思い出せないな、どんな感じで使ってたか。
YAMLを書いてGitHubアップを入れて連携するんだよ。
でも、Actionsよりは多分GitHubに対しての権限の自由度が明示的につけてないといけないと低いというか、
チェックアウトぐらいはできるけど、プリンクル立てるとかは多分できない。
当時はできなかった、僕はサンドじゃん。
パーミッションズライトつけたりできない。そんな感じではなかったから、どうなんでしょうねっていう。
その点、Argo CDとかはどうなんだろうな。
Argo CDはCICDの目的のものじゃないと認識できない。
デプロイなのか、基本的には。CI部分はないんだね。
自前でクラスター、Kubernetesクラスターに立ち上げて。
なるほどね。
じゃあそうすると厳しいね、サークルCIになっちゃうのか。
サークルCI以外は知らないな、それで言うと。
古いやつだと、Travis CIとか。
ナッツ、名前は知ってる、使ったことはない。
あと普通にJenkinsだわ。
Jenkinsも使ったことないな、それで言うと。
浅いな、歴が。
こうしてキーワードを聞くとめっちゃ実感するけど。
そうだね。
僕らの耳に入るレベルのやつはそんなところか。
OSAMU CIの。
見てみてるけど。
GitHub Actionsが強すぎてな、今は。
GitHub Actionsでいいじゃん、にしかならんと思うから。
サイダー、あったな。
あったなって言い方ちょっと失礼か。
でもやっぱOSSで費用かけずに言ってみると
GitHub Actionsが選択肢に入るところもこういうものが入ってきて
どうなんでしょうかって。
ファブリックなところだしね。
分かんないけど結構、ガバナンスの面でめちゃくちゃ
カリッとやらなきゃいけないところとかは払うんのかなとか思ったりするけどね。
でも何でもお金かかるのしんどいな。
別にただ安全に使いたいだけなのにさ、
何でもお金かかるの、安全に使うためにお金かかるの
普通に馬鹿らしくてやってらんないよね。
そうだね。
最初から安全になっとけよっていう気持ちになっちゃうんだよな、どうしても。
そういうセキュアバイデフォルトじゃないけど。
しかもセキュアバイデフォルトであるべきっていう概念自体はずっとあるけど
世の中はずっとそうなってないという難しさがあるね。
狙われてから初めてセキュアバイデフォルトになっていくというか。
ある種革新的なものに関しては一定そういうのも必要かなと思ってて
例えばコーディングエージェントの安全性というか
コーディングエージェントの作りを安全にしましょうみたいな
コーディングエージェントを出して使っていかないと
そもそも誰もわかんない世界だからそんな攻撃があるのねみたいな話とかもそうだし
やっていかなきゃいかないよねみたいなのは言ってあったと思ってて
GitHubにCIを埋め込んだらどうなりますか
正直未知数な部分はきっとあったと思うんだよね。
だからある程度しょうがない部分はあるかなと思うし
一応出しちゃうと買いにくいっていうのは多分あると思うし
でもアクションズはちょっと遅かった気がするな
もうちょいなんとかならなかったのっていうのはちょっと思わんでもないね確かに
しかもアクションズに対するこういうふうに使ったら危ないっていうのは
正直これが流行る前から出尽くしてたわけだから
そこに対して手を打たなかったのはビジネスだなって思っちゃうな
GitHub目線は別に金にならないというか
金にはならないけどこうしてチェーンガードとかが
別にチェーンガードも頑張ってほしいと思うし
いいプロダクトになっていくのかもしれないけど
ある種付け込む余地を生んでしまってる隙を生んでしまってるっていうのはあるわけだから
ビジネス観点で見てもどうなんだろうね
それでいうとこのチェーンガードアクションズ内視は
セキュリティ面でベターな互換性というかある程度互換性のあるものが出てきたときに
世の中がそれを選択するのかみたいなのを観察するのは面白いかもね
それで結局みんなが金払わなかったらやっぱ悪循環だと思うんだよね
素敵なもの作っても誰も金払わないんだったらじゃあ誰も作らんとなってやられ続けるのか
本当にボコボコにされてからやっと金を払い出すのか
実際はそんな01じゃなくてグラデーションになるんだろうなとは思うんだけど
まあね 難しいね
ギッタブアクションズ自体が事故ってるわけじゃないっていうのがまたむずいとこなんだよな
あくまで使い方が悪いみたいな話になっちゃうのか
まあ確かにね
でもさ実際さコードコブとかさもう誰も使わなくなったじゃん
そうだね
別にコードコブ自体はまだ残ってるけど
実際誰も使わなくなったじゃん
確かにね
そういうの見ると別に決して軽視できる
そうそう普通になんかもう完全にこうなんかその辺で見かけなくなるレベルまでさ
何か起きた時にシェアが下がるっていうのは普通に起こり得るわけだから
まあでも結果アクションズはなってないわけだからここまでなっても
だからなんか僕ら目線ではなんかその
なんて言ったらいいんだろうこう
もうちょっとなんとかならなかったなとかなって思わんでもないけど
まあ別に結果なってないんだから結果その別に
なんて言ったらいいんだろうなんか
それによってめっちゃこう誰も使わなくなるみたいなこと起きてないわけだから
なんかビジネス的にはもはやそれがある意味正解だったのかもしれないし
もしかしたらここからその例えばだけど今日のこの記事のチェーンガードのこれとかが
どんどんシェアを取っていってみたいなことも展開としてあるのかもしれないし
ある意味過渡期ではあるのかもね
そうだね確かに
コードコブとやっぱ違ってGitHubが圧倒的に強いのはもう全部GitHubで済むみたいな部分だと思うから
そこを剥がし切るほどのモチベーションがみんなに生まれるかどうかって感じだよな
いやー
まあでも全然起きるんだろうな
コパイロットがメインストリームじゃないっていう視点でなんていうか
全部GitHub入りだったらなんでもいいわけではやっぱないっていう
おもろいねなんか
その境界線は何なんだろうね
開発の中のどこかに境界線があるのか
あるいはその例えばだけどGitHubの上にクロードが乗っかってたら別にそれで良かったのかというと
クローズコードが乗っかってたらそれで良かったのかというとどうなんだろうね
なんかおもろいね
うーんそうだね
なんか
おもろいね
AIアジェント周りはちょっと特殊かもね
なんかCICDはめっちゃシンプルに
僕なんかサークルCIからの移行とか
仕事でもちょろっとかじったけど
こっちの方が圧倒的に使いやすいみたいな結構シンプルな理由だったから
だから物が良いは前提としてはやっぱり必要なんだよね
物が良く
まあそうね
同じぐらいの物が出てそっちの方がセキュアで
お値段これですってなった時にどうかって
まあ言うてベータなんでちょっと
まあ見守りつつって感じですかね
楽しみですね
はいじゃあ次
まあさらっとその後のお話って感じですけど
マネーファワードをGitHub防いアクセスの影響調査を完了っていう
まあインプレスの記事ですかね
ウォッチインプレスインプレスウォッチか
まあなんか一時ソースの
方もというか公式からもプレスから上がってて
最初報告って形で上がってたんでさらっと読んだんですけど
あんまり正直新しい手法はなくて
詳しい原因とかポストモテム的なものが今んとこは出てないんで
まあちょっと気になったなみたいな部分はありつつ
まあ最初報告を見る感じは基本的にはGitHubアカウントが
まあトークンなりと推測されてますが
トークンなり経由でアカウントが一つ侵害されて
GitHubのやつは全部抜かれたけど
まあそこから横展開はされずに済んだように見えるなという感じですね
結局何が漏れたのかよくわからなかったね
その一発目か危険が何だったのかよくわからなかったな
そうなんだよね
どっから何が漏れたかみたいな部分は完全に
なんかちょっと気になるのが特定できなかったから言えないのか
特定してるけど言ってないのかで結構話は違う気はしてて
いやーさすがに特定はできると思うけどな
そんなことあんのかな
なんかそのトークンこの人のトークンが漏れて
アカウントが漏れたのは確定で
でローカルから抜かれたのは確定だけど
そのなんだろうな
いやどうなんだろうな
そうね
何が動いて抜かれたのかがわからないみたいな
どこと通信したのか
ログが残ってないとかはあり得るかなみたいな
まあね確かにそれはあるかもね
マネーフォワードぐらいの規模で
さすがにないような気がするけどなそんな
まあそうね
どうなんだろうね
ないと思ったり
いろいろやってはいるだろうし
あとなんか最初報告で結構ちょっと勉強になるなと思ったのが
まあいわゆる多分その
システム上のアイデンティティ識別紙みたいなのも漏洩していて
それも法令上は個人情報に回答するんで
それも件数を記載してあるんですけど
一方で有識者の方はわかると思うんですけど
例えばよくあるのがユーザーIDみたいなものって
個人情報ですかみたいになった時に
そういう社内の人だったらユーザーIDを使って
SQL叩けば指名引っ張れるんだったら
それは個人情報ですっていうのが
法律上の決まりであり
それが漏れたら個人情報が漏れたっていう
表現しなきゃいけないって話あると思うんですけど
それが多分漏れているんで書いてあって
ただなんかその
で 件数が6万449件なんですけど
それはなんか6万449件
個人データ 個人情報が漏れちゃいましたって表現っていうよりかは
単体で個人を特定できない固有識別紙
6万449名分っていう表現をしていて
かつくなんかその説明も
当社グループがユーザーを区別するための
システム上の管理用番号ですっていうふうに書いてあって
本識別紙からのみでは
特定の個人を直接識別することはできませんが
個人情報保護法の原格に従い表現をしていて
なんか何も知らないエンドユーザーからしたら
この表現はちょっと
ちゃんと読んでくれればですけど
6万件漏れたぞって騒がずに
済むじゃないけど
的確な表現だなとってこういうふうに書くんだなって
ちょっと勉強になりましたっていう感じですね
あんまりなんか
ここの部分をメディアが取り上げることってほぼないから
そこは設置がないところだね
そういう意味でインプレスウォッチは
6万件っていうのを
乱しにはしてなくて
一応単体で個人を特定できないこういう識別ある
6万件って表現してくれる優しいメディアかもしれない
PV稼ぐなら書いちゃうかもね
6万件漏れ
だいたいそっちばっかり広まっていくからさ
確かに設置がないな
そう思うと件数は少ないに越したことはないというか
なるほどね
ほとぼりが冷めた頃にもしかしたら
技術方面の話が出てくるかもしれないし出てこないかもしれないですけど
ひとまずお疲れ様でしたという感じですね
お疲れ様でした
補填も超大変だったと思うし
多産の意思としましょう
大変だったよねこれは
大きい会社で扱っているものもまだし
ステコロダも多いだろうしね
やり取りする金融機関とかも
胃が痛くなりますね
あんまり体験したくないというか
できれば体験せずに一生を終えたいけど
どうなるかなって感じですね
じゃあ次
次はちょっとカロリー高いかもですけど
モジュラのブログで
パクト
という記事ですね
盛りまってますという感じですけど
パクトという仕様ですね
今提案中の仕様がありまして
その話という感じですね
結構頑張って読んだら
なるほどねって思ったので紹介なんですけど
前提条件から
前提のところから話すと
どういう課題をまず解きたいのかみたいな部分
基本超ざっくり言うと
誤作動をせずに
プライバシーの懸念も最上限にした上で
ウェブサイトへのアクセスに対して
適切にレートリミットを実装したいというのが
超ざっくり言うと解きたい課題かなという風に
レートリミットって何やねんというところで言うと
例えば僕がスマホで
ウェブサイトをアクセスしたときに
普通に回遊してたら1時間たり
100アクセス200アクセスぐらいで済むはずだけど
一方で手元のカールで自動化して
特定のサイトにバカスカバカスカ
アクセスするみたいな人もいろいろいるわけで
そういうところに対してきちんとアクセス元の
アイデンティティを正しく認識した上で
一個一個に正しいレートリミットをかけたいというのが
やりたいことですと これ別に
今各社やってないのかで言うと各社はもうすでにやってますよ
って話があるんだけどそこに課題あるよねって話で
具体的には例えばBot対策で
キャプチャーとかクラウドフレアとかの
画面挟まるとか体験したことある人いると思うんですけど
読むの挟むことでBotのアクセスを
ブロックするみたいなことをみんなやってるけど
あれが完璧かと言われるとそうではなくて
例えば変な話 普通に
パソコンでブラウザーを回遊していただけるに
画面が出るみたいなのはBotを防ぎたいのに
人間に対して不便を強いてるよねみたいな話とか
あとは書いてあってなるほどねといったのは
日常的にVPNのクライアントを使って人間がブラウジングしてる
ケースにおいて
VPNなんでその出口IPみたいなところで
引っかかっちゃって
いちいちキャプチャーが出るとか
そもそも事業者によってはVPNって時点でブロックしちゃう
みたいなことをしてる人がいて
そこも本当は人間が
普通のユースケースを閲覧したいだけなのに
Bot対策とかそっち側に
安全側に倒すためにトレードオフを飲んで
正常な人間のアクセスをブロックする
みたいなことがしなきゃいけないし起きてることだよね
みたいなのが前提の課題ですと
今までこの課題を解決する別のアプローチがあったのかで言うと
実はいくつかあったらしくて
僕はこの基準読んで初めて知ったんですけど
例えばの例でAppleのプライベートアクセストーク
っていうのが紹介されていて
これは何かっていうと
IOSですよね
MacOSも入るのかな
Appleが作る端末の中に
その端末からのアクセスだよ
っていうのが認識できるようなトークンを
使い捨てのトークンを吐き出すような仕組みを
ハードウェアレベルで実装して
ウェブサイト側はそれを検証することで
どっかのBotとかどっかのクラウド上で動いてるやつから
アクセスが来てるんじゃなくて
人間が操作してるIOSの端末からのアクセスである
っていうのが保証できるっていう仕組みが実際にあって
そういうのもありますって話なんだけど
これは確かに課題解決になるんだけど
一方で懸念としてはこれがまかれ通っちゃうと
どの端末でどういう場面だったら
ウェブサイトにアクセスできていいかっていうのを
1ベンダーが握れちゃうよねっていう状態になるっていう部分に
モジュラは懸念を抱いていて
今 例としてAppleの話を挙げたけど
似たような仕組みをGoogleとかも
実際に作ったのか作ることを検討したのかなんですけど
そういうものがあって そういうパワーのある
ハードウェアを握ってるところが
誰がどういうふうにウェブにアクセスできるかを
コントロールできるっていうのは望ましくないので
もっと中立的な仕組みがあったほうがいいっていうのが
課題感としてありましたと
ここまでの前提で その上でパクトっていうものを
提案してますっていう話で
これが何かっていうと ちょっと頑張って説明しますが
登場人物が4つかな 4人いますと
どうやって説明しようかなって感じなんですけど
例えば 僕がAndroidを使って
クラウドフレアのCDの音をしてるウェブサイトに
アクセスするときにどういう流れになるかっていう形で
話をすると
まず 一番最初に
Androidの端末を使うっていう部分で
このAndroidがAnchorっていう役割を担いますと
このAnchorっていうのは何を担うかっていうと
さっきのAppleのプライベートアクセストークみたいに
そのハードウェアレベルで事前に組み込まれた
この端末のこの場面のこのアクセスは
例えばGoogleのAndroidのアクセスですよっていうのを
保証するっていうのがAnchorの役割になりますと
これをやるのはGoogleでもいいし IOSでもいいし
通信機械かもしれないし そういうものが想定されていますと
このAnchorがウェブサイトアクセスするときに
エンドロースメントっていうのを
まずクライアントに付与しますよっていうのが1ステップ目
次に このエンドロースメントが付いた状態で
僕がウェブサイトにアクセスしたときに
モデレーターっていうものがいますと
分かりやすくするために例として
クラウドフレアを挙げますけど
例えばクラウドフレアでホスティングされているサイトだったら
クラウドフレアがモデレーターの役割になりますと
モデレーターは何をするかっていうと
エンドロースメントを付いたリクエストが来た場合に
このエンドロースメントをもとに
エンドロースメントかな 多分
エンドロースメント 失礼しました
このエンドロースメントをもとに
使い捨てのトークンっていうのを発行して
クライアントに渡してあげるんですよね
このトークンっていうのは今使い捨てなんで
このトークンを使って
正規のウェブサイトにアクセスしてねっていうものになりますと
クラウドフレア前段 エンドロースメント渡しました
トークンもらいました
正規のウェブサイトにたどり着いたときに
最後 ウェブサイトは
アクセスしてきたこいつがボットかどうか判定したい
もしくは人間なのか判定したいってときには
そのトークンっていうのを
発行されたトークンを検証して
正しければ
これは人間のアクセスっていうのを判定して
レートリミットっていうのは適切に設定して
設定しなくていいんだ
レートリミットはややこしいですね
モデレーターのレイヤーでやるんですけど
そのトークンを検証するだけでいいよっていうような
仕組みになってますと
いくつかミソがあって
これが何が この仕組みが何で
こんな感じで役割分担してるかっていうと
一つはプライバシーみたいな
プライバシーの懸念を解決するっていうのがあって
さっきのAppleのプライベートアクセストークンとかと
登場人物が
クライアント
iOSの端末とウェブサイトの2者だけ
だったんだけど
この場合は何が起きるかというと
ウェブサイト側はアクセスしてきたときに
Appleのプライベートアクセストークンが渡ってきたら
こいつはiOSの端末からアクセスしてきたんだなっていう
一つの識別心になっちゃうよねって話があって
なんでAppleに依存しない形を作ったとしても
どういう形で発行されたのかっていうのが分かっちゃうから
そこを分かんなくするたびに
モデレーターを1枚挟んで
エンドロスメントを直接ウェブサイトに渡さずに
済むようにしてるっていう部分が
一つあるので
ウェブサイト側は受け取ったトークン
使い捨てのトークンを受け取ったときに
そのトークンがAndroid由来のものなのか
PC由来のものなのか
特典通信キャリアのものなのか
っていうのが分かんないようになってるっていう部分で
ひとくせいが保たれますと
かつモデレーターもエンドロスメントを受け取っても
それが何から発行されたのか分かんないけど
それが正しいってことを証明できるようになってる
この辺は暗号周りの
ゼロ知識証明が使われてるらしくて
ちょっと詳しくは分かってないんですけど
まあまあ人間のイメージだなっていう感じですね
あとは
MISO
そうだレートリミットか
レートリミットをどこで設定するのかみたいな
部分で言うと
モデレーターのレイヤーなんで
さっき話した例で言うと
クラウドフレイヤーのレイヤーで
ウェブサイトを運営してる人が
人間からのアクセスは
毎時200まで抑えるみたいな設定をすると
モデレーター側で
エンドロスメントを受け取ります
そのエンドロスメントに対して
トークンを吐き出した回数みたいな
内部的に持っていて
それがレートリミットを超えたら
次からもトークンを吐き出さないっていう挙動をする
っていうので担保できると
あとは
じゃあこれ空でアクセスしたらどんなのかっていうと
空は空用のレートリミットを設定したったら
それに引っかかりますよっていう感じ
だからイメージ的には
今ちょっと画面触ったことないですけど
クラウドフレイヤーの画面とかで
ボットからアクセスきたときに
どういうふうな挙動をしますかっていう
設定画面があって
ブロックしますってなったら
今だとキャプチャーが出るし
このパクトを使ってる場合でも
設定画面は多分変わんない
ボットだったらブロックするってやったら
パクトの挙動としては
エンドスメントをもらったときに
トークンを渡さないので
ウェブサイトにアクセスできないっていう形になる
だからそもそも多分突破もできないのかな
基本的には
エンドスメントを偽装できない限りは
突破できないっていう感じになる
っていう感じですね
ざっくりこんな感じのはず
難しい
そう結構ね
結構AIの力を買いながら
いろんな記事を読みながら
頑張って読んだんですけど
でもおおむね
僕の理解が間違ってなければ
嬉しい話には見えるなっていう気はしていて
やっぱボットを正しくブロックするのって
めちゃくちゃ大変じゃないですか
基本的にはセキュリティクライアント予想って
アクセスしてきて
イタチコッコになりがちだしっていう部分に対して
これ入れれば
エンドスメントっていうか
仕様のどっかに穴があったり
エンドスメントを
何かしらの方法で偽装できない限りは
きちんとブロックできるよねと言える気はしてて
まあね
でもクライアントが人間であることを保証する
そのアンカーがどう保証するのかって
今ここまでの話で出てきたとき
そうだね
なんかその辺は多分煮詰めるっていう部分と
あとそもそも誰がアンカーになれるの
違うアンカーを
話しやすいんですけど
アンカーとモデレーター誰がやるのって話があって
アンカーは誰がやれんのかで言うと
多分誰でもやれるんだけど
そのモデレーター側で
信頼できるアンカーを設定できるっぽいのかな
だからその誰も彼もが
その人間を名乗って
アンカーをやることができる
まあできちゃったら
悪意のある人がやっちゃうわけだから
基本的にはそのお手弁大にかけられるでしょう
っていう部分と
あとモデレーターの決め方みたいなのも
基本的にはその
超ざっくり言うと
みんなで決めようみたいな話で今話してるっぽくて
特定のとこがパワー持って決めちゃうと
結局その一番最初に話した
特定のベンダー依存
特定のベンダーが
まあいろいろ握っちゃうって話になるから
まあその辺はどうしましょうかっていう部分が
絶賛議論中みたいなのはちょっと見たって感じだね
その仕様書見れば
そのアンカーがどういう形でエンドスメントを作るかとかも
もしかしたら言及があるかもしんない
なんかこれ
サイトの自社サービスを守るって考えたときに
構成次第で使えるか使えないか
変わりそうだなって気はしていて
ウェブサイトしかホスティングしてなければ
もうCDの入れたおしまいでいい気はするんだけど
ウェブサイトと同じドメインでAPIも
まあでもAPI
ブラウザからの通信も全部弾けるのかな
違うクライアントだ
だからスマホアプリだ
スマホアプリとウェブサイトのAPIのエンドポイント
共通にしてますだと
どうなるんだろう
何を思ったかっていうと
このエンドスメントを渡して
トークンを受け取ってトークンを投げるっていう部分は
実装が全部ブラウザ内に閉じるんですよ
これがモバイルアプリから通信になった時にどうなるかの言及はなくて
もしブラウザ限定の橋だとしたら
モバイルアプリから投げるときは
トークンが投げられないってことになるから
モバイルアプリとウェブで共通のAPI使ってる場合は
そのAPIに対してはパクトの仕組み入れられないような
結局みたいな話にはなるよね
そこはBot対策を持ち上げてやらなきゃいけないみたいな
例えばメディア系のウェブサイトを運営しててとかだったら
そのウェブサイトに一括でバンって入れて
今だとAI Botのクロールとか苦しんでる人とかいると思うから
そこはすごい嬉しいかも
でもこれ誰の方を向いてる仕様なのって
考えた時にあくまでユーザーの方を向いてる仕様だと思うから
だから別にアプリの人はそもそも
シークレットウィンドウとか使わないから
そこは知らんよっていう感じなんじゃない
もしかしたらね
あるいはネイティブレベルで似たようなことができるようなAPIが
提供されるのかもしれないし 最終的にね
それは分かんないけど
未来ももしかしたらあるかもね
どっちかというとこれは人間ですよっていうのが確実に担保される
っていうのが多分大事で
そうだね
結構よく考えられてるなと思いながら
なんかすごい難しいなと思いながら
結構記事も長くて
あってると思う間違ってたら誰か教えてほしい
結構頑張って読み取る
登場人物とトークンやらエンドスメントやら色々あって
レートリミッターどこでかけるんだっけとか結構疑問が次々と
難しいよね
まだ面白かった
番号ゼロ知識正面とかちょっと差し投げちゃった 理解は
できるらしい
すげえというか
概念自体は知ってるんでそれで十分かなと思ってますけど
大変だよねプライバシーとか本当に
面白いけどねなかなかこの辺の技術って結構
よく頭いいねってやってるよね
興味ある方ぜひ読んでみてくださいだいぶ骨がある
まあその仕様の段階としてはまだまだ多分
練ってますっていう感じだと思うから
固まってきたらもっと話題になるかなと思うんですけど
よくするね
いいね
じゃあ最後サラッとサラッとなんですけど
チェーンガード2項目のチェーンガードで
メンテナーをブラストリゾートっていう記事ですね
Money Forwardのインシデント調査とOSSのメンテナンス問題
何かというと
メンテナー不在で放置されたOSSいっぱいあって困るよねみたいな話がありますよねと
放置されると何が困るかっていうと
パッチ当てて欲しいのにパッチが当たらないCVEが
発行されっぱなしですとか
また何かそれ自体にCVEがなくても
そいつの依存パッケージで
ディペンダントアラートが解消されないとか
誰しも経験があるかなと思うんですけど
そういうものに対してどう解決していこうかみたいなところの回答として
みんなで中立的な組織お金出し合って作って
それで全部まるっと巻き取るっていう提案をしてるブログって感じですね
なんで相変わらず結構デカいことを言ってるなっていう感じなんですけど
本当そういう話
例としてLet's Encryptとかを上げていて
前回の収録でもちらっと話した気がするんだけど
前のも別に特定のベンダーが利益のためにやってるっていう
それからはいろんなウェブ
この世界に貢献してる企業がお金を出し合って運営して
広くウェブに価値を還元してるみたいな形を取ってるけど
それと同じ形をこれも取ればいいじゃないかみたいなとこ行っていて
具体的にどうすんねんみたいな部分は
結構僕ら動き始めるよみたいな
ふわっと書いてあって
なんで今後具体的な話が出てくるのかトンザするのかちょっと分かんないですけど
記事の話はそういう話ですね
結構どうだろうな
思ったのはこういう回答もあるよねっていう理解はできるが
実現できんのかなみたいな話と
またなんかちょっとOSS一周回りつつある感もちょっと感じているというか
ギッタブ文化どんぐらいなんですかね
僕が大学生の時はギッタブ普通にあったから
10年15年とかなのかなOSS文化
内緒はOSSを作って再利用可能な形でパッケージングして
ガンガンお互い使うよみたいなのになってから10年とかは経ってるのかなと思ったけど
10年経って放置されてるパッケージング増えてきて
セキュリティというか脆弱性を見つけるみたいな概念
ずっとあったと思うけど
そこのエコシステムが整ってCVEが積み重なって
AIでとうとう手がつけられなくなったみたいな部分に対して
今のままでいいんだっけみたいな問いかけはある気はしてて
そこに対する回答と思うと
僕の立場に何もできないけど
これをやるべきという気持ちを共感はできるかなっていう風に思いつつ
ただSSL証明書とはちょっと違うよねとは思うから
いろんな結構難しい部分もある気はしてて
インフラレベル化っていうのがちょっと違うなと思う
仮に資金が集まってもお金も時間も有限だから
何を巻き取ってあげるかって選ばなきゃいけないと思ってて
選ぶ基準がどこに寄り添うのかみたいなめちゃくちゃ
結構透明性高くシビアにやらないと
パワーバランスとか生まれちゃいそうだなとかちょっと思ったりするんで
その辺は難しいだろうなとちょっと思うんですよね
難しいね
広く使われてるかどうかとかでいって
納得感のあるフィルタリングはできそうな気もするし
どうなんすかね
そういうふうに多分するしかないよね
そうなんだよな
NPMとかあったらインストール数とか分かりやすいけど
そういうのがないようなパッケージとかOSSとかローレイヤーのやつとか
その評価をする仕組みを作るだけでも結構骨が折れそうだなというか
その後にNVDのCV全部評価するのやめますわ結構
アメリカの機関だからこそ結構分かりやすいとか
アメリカの政府が使って大事なやつだけにするよっていうのは
そりゃそうだよねっていうか
別に世界の中立じゃないからこそスパッと決められたと思うんだけど
でも本当にガチで動き出すんだったら応援したいなという気持ちで
ちょろっと紹介という感じでした
OSSですな
どうなっていくんでしょう本当に
面白いな
Fortinet機器への大規模攻撃キャンペーン「FortiBleed」
意外と生きてる間にいろいろ動くなって気持ちにちょっとじんわりなりますね
10年後ぐらいには
いやーGitHubで全部公開されてる事例があったらしいよみたいな
それを使っててみたいな
正気じゃねえなみたいな会話をしてるかもしれない
怖すぎると思ってるね
全然あり得ないとは全然言えない
別に作ればすぐなのにねーってなんか
いやーありそうそっちの線のほうがありそうだね
本当になんか再発明するにはちょっと苦思いとか
信頼性が求められるものだけ生き残っていくとかあるかもね
ありがとうございます
記事はこれで全部なんだけど
前回40ブリードを調べてきますって言ってきて
調べてきたのを一番最初に喋るの忘れたんで
さらっとそれだけ喋っておしまいしようかな
あとお便りはなかったんでお便りを募集してます
さらっとなんですけど
締まらないな
40ブリードねちゃんと喋ってきたんですよ
素晴らしい
もう俺覚えてないわ
そうだよね
記憶の彼方だったわ
前回の収録ではあれかな
40ネットのVPN機器エッジデバイスの
管理者パスワードのハッシュがめちゃくちゃたくさん漏れて
解析されちゃってみたいな結構適当なことを喋っちゃったんですけど
割とちょっとこみてて
さらっと紹介というか
喋り訂正させていただく感じなんですけど
攻撃の流れですね
40ブリードっていうキャンペーンがありましたっていうのは
ありましたと
この攻撃キャンペーンの流れを話すと
まず一つ目は
パブリックのインターネットで露出してる
MS SQLサーバー
多分データベースサーバーですね
とかあと40ネットの端末に対して
シンプルにブルートフォースアタックとかを仕掛けて
コツコツアカウント情報を収集してるっていうのが
まず一つ目
二つ目がそれを使って初期侵入しましたと
ただちょっとなんかややこしい
先週喋りながら混乱した部分でもあるんだけど
この初期侵入に使ったアカウントは
一のステップで奪ったものだけじゃなくて
40ネットの古いデバイスの
シンプルに脆弱性を狙ったものとか
あとデフォルトパスワードと
デフォルトアカウントで
パスワード固定みたいなものとかを狙ったものとか
あと過去に漏洩した
全然別のIDパスワードのペアとかを使って
それで再利用したみたいなものとか
そういういろんなものを組み合わせて
初期侵入してる
なのでブルートフォースだけじゃなくて
いろんなものでかけ詰めて初期侵入したっていうのが
2ステップ
3ステップ目が
ここで初めて柱化されたパスワードの話が出るんだけど
40ネットにログインした後に
設定ファイルをダンプするっていうのをやられたらしくて
これダンプってのは何やねんって感じなんだけど
いろいろ記事を見ると
ダンプする権限があれば
そもそもダンプすりゃいいって話なんだけど
ダンプする権限がなくても
特定のCVEを悪用すると
権限なくても
設定ファイルをダンプできちゃうみたいな
パターンがあるらしくて
そういうものも悪用して
ダンプしたらしいと
このダンプしたファイルの中に
柱化されたカニシアンパスワードが入っていたらしくて
かつこの柱化されたものが
特定の年代 特定のバージョン以前のものだと
柱方式が弱いものになっていて
脆弱なパターンになっていましたと
ここが別の人が話してて
なるほどなと思ったんだけど
このなんかハッシュが古いってやつは
CVE振られてて
ファーメイヤーのアップデートも来てるんだけど
ファーメイヤーアップデートしただけじゃ
実はこのハッシュ方式が新しくなんないっていう
罠があったらしくて
なんで管理者としては
ファーメイヤーアップデートした後に
管理者としてログインし直さないと
このハッシュが直んないっていうのがあって
なんでこの辺で結構パッチ当ててんのに
脆弱なハッシュがいっぱい漏れちゃったんじゃないか
みたいな話がちょっとあったらしいですね
ここで攻撃者 管理者パスワードのハッシュを
バーって手元に集めて
ここでGPUがん詰みして
オフライン攻撃で管理者パスワードを複合しますと
管理者パスワード複合できたら
普通に管理者として侵入して
横展開していって
その中で先週ちらっと話してた
そのFortinetの端末の機能である
いろんなトラフィックを収集して
傍受して解析するとか
またそのFortinetの純正のアナライザーみたいなのを使って
通信を収集して それを複合して
またどんどん横
複合というか解析して
どんどんどんどんまた横展開していくっていうので
イモゾル式でいろんな被害が出ましたよっていうのが
攻撃の全体像って感じです
なのでハッシュを複合したっていうのは結構
ステップのうちの一部っていう感じで
ちょっとそこに僕は目が引かれてしまったんですけど
全体像を見ると結構
いろんな方面かいろんなことで
結果として大規模に侵害できてるっていう
攻撃キャンペーンなんで
割と話題になっていたって感じですね
これが何で発覚したかみたいな部分は
っていうと
あるセキュリティ研究者が
大量のFortinetの認証情報を獲得したDBを
パブリックインターネット上に見つけて
多分攻撃者がデータベースの設定ミスって
パブリックに露出しちゃったみたいな感じで
攻撃アクター 脅威アクター運用してたものを
たまたま見つけたと
それをなんだこれはっていって
解析してみたら
結局7万台とかなのかな
7万台っていう数字が正しかったら
パブリックに露出してるFortinetの端末のうち
半分の量に当たるものが
そのデータベースの中にあって
これヤバいぞっていうので報告して
ここまでいろいろ騒ぎに乗ったり
全体像が明らかになったっていうような感じです
なんでこれ発見したときに
多分もうやられてるとか
もうやられちゃってたみたいな感じで
たぶん事後報告的に
必死に調査したいとこもあれば
これからやられるかもしれないっていう部分もあって
なんでJPサービスとか
注意喚起が出てるんですけど
そもそもパブリックに管理画面
パブリックから管理画面入れるようにするんだよとか
さっきのファームウェアアップデートしたらOKみたいな
部分はそうじゃないよっていう
コマゴマ罠とかがあったりする
っていうような感じでした
訂正終わり
訂正というか
結構調べたら
なるほどねって感じだったんですけど
ありがとうございます
ファームウェアアップデートしてOKじゃないみたいなのは結構
でもパスワードだから
そりゃそうだなって感じなんだけど
そうなんだよね
仮だけどファームウェアをアップデートしましょうみたいな
形でだけ運用してると踏み抜くかもね
アップデート内容を
踏み抜くけど
ファームウェアアップデートのときにお知らせとして出してたのかな
そこって一緒
分かんないなどうなんだろうね
それがまず分からんなと思うと
あとはアップデートのときに
分からんけどダブルハッシュにするとか
できなかったのかなってちょっと思うんだけどね
確かにねどうなんだろうね
ダブルハッシュにしておけば別に漏れても
まあまあまあっていうレベルにはできたかもしれなくて
だから強い方で二重にかけちゃうってことだよね
そうそうそうそう
でログイン
もう一回ログインしたときに改めて
ダブルハッシュじゃなくて普通のハッシュに
また置き換えてあげるっていうのも
してあげれば
やったんじゃないのと思うんだけどね
むずいねなんかその
二世代管理しなきゃいけなくなるよね
実装目線は
そうだね
ダブルハッシュのやつは多分マーク付けとかないと復元できないから
それを嫌う気持ちもまあ分かるけど
まあでもどうなんだろうな
なんかEdgeデバイス仕事で使うようなレベルのものを
運用したことないか分かんないけど
なんか家のルーターとかだと
なんかねアプリからポチッと押したら
おしまいというか
そういう場面で気の利いたものを出してくれるかというと
ちょっと分からんよね
まあじゃあちょっと運用してみてください
買ってくれ
頼むポケットマネーで俺に買ってくれ
運用するもの
はいそんな感じでした
でまあそうして
まとめと今後の展望
特に大きなインシデントは
まあ絶賛なんかいろいろ
まあでも本当は今週はそんな
名のあるパッケージで侵害されなかった気がするんで
最近静かだねめっちゃ静か
まあでも言うて先々週マストラやられたし
月1ペースで最低月1ペースはやられてる気がするけど
あとなんかまあまあそうね
まあまあツイッターを探すようなものはないという意味では
平和だね
あとあれかフェーブルがね
昨日ですか
戻ってきましたね
帰ってきたんで
その辺は来週分に入れたんで
読み込んで紹介しますって感じですけど
引き続きご安全に頑張りましょうって感じですね
ブラジル応援しましょう
ブラジル応援するの?
もうワールドカップ終わったんじゃないの
日本は終わったけど
ブラジルはもうちょっと行けるとこまで行ってもらって
ブラジルに2-1まで
2-1でギリギリまで追い込んだ
日本は強くなってなると
いいじゃん知らんけど
まあまあでもいいんですよ
もう終わったことはいいんですよ
来週にはね
引き続けていけんな
来週はもうサッカーの話しないと思うんで
2話かなんでしょうがない
来週はサッカーの話しないでおもろいな
結局さだって
3週連続くらいやっちゃったんで
楽しかったな
そんな感じで皆さん次回もお楽しみにしててください
おやすみなさい
おやすみなさーい
