00:03
いつも、Replay.fm をお聞きいただき、ありがとうございます。
今回、私、キリンの録音トラブル、機材トラブルにより、音源が途中で途切れております。
今回、7記事読んだんですけれども、6記事目の途中までは録音できているので、
そこまでは配信しますが、途中でふわっとフェードアウトするような形になってしまいます。
最後の記事、および6記事目に関しては、納書の方にも貼り付けているので、ご興味ある方はご参照ください。
次回からは、このようなことがないよう、配信環境の改善に努めていきますので、
今後とも何卒、Replay.fmをよろしくお願いいたします。
それでは、本編をお楽しみください。
ボルダリングと指のケア
こんばんは、Replay.fm第59回です。
こんばんは。
いやあ、お元気ですか。
まあ、ぼちぼちですね。
意外とお互い、風邪ひかずに来れてるね、季節の変わりみたいな。
そうだね。たまにちょっと喉怪しかったりするけどね。
ああ、わかる。
意外と耐えてる。
うん、確かにな。そろそろ、そろそろなあ、口がパリパリになって、
あの、指のささくれはめっちゃ出だしたわ。
マジで。もうね、指乾がない、今。
あなたそうでした。
そうなんですよ。
登る人だったね。
マジで、皮がない。ボロボロだよ、指先、マジで。
わかる人にはわかると思いますけど、ボルダリングぐらいの。
うーん。
ヤギ足くんなんで。
めっちゃ、なんかケアしとる。
うーん。あの、弟がさあ、弟も結構やってるみたいなんだけど。
やってたよね。超強かったよね、いつかもね。
ああ、たぶん。そう。
そう、一回ね、岩場で遭遇したことあって。
ああ、言ってたね。
そうそうそう。で、前職の人は一緒だったから、
ああ、似てね、似てね、似てね、つって。
ああ、似てね。
似てるでなあ。
肉芯か?つって。
聞いてみたら。
見すぎで低評があるね。
ああ、出た。
そう。いやあ、そう、あの、指、あなたたち指削るじゃないですか。
弟がやっててめっちゃ衝撃を受けたんだけど。
ああ、削るね。
ヤスリみたいなんで指削ってて。
何してんの?
なんか、もう自称こい。
実はミーティング中に削ってるよ。
ああ、そうなんだ。
あの、デスクの下でシャコシャコシャコシャコ。
ふける。
怠らずにね。
結構やってる。
暇、暇、暇ってわけじゃないんだけど、その、なんか別に。
あんまり物を考えずにやれる作業だから。結構。
あの、スタバでストローの袋いじるみたいな、そういう枠なのかなって。
ああ、そんな感じだね、うん。
ふける。シャコシャコシャコ。
シャコシャコ。
削りすぎないでください。
削りすぎると、そう、痛いから。
でも全然そんなね、大した荒さじゃないから大丈夫なんだけど。
なんか、ボルディングやってる人がギターやり始めたら、一番最初の壁の一つである指痛いもんで結構回避されるのかな。
いや、痛えよ。痛い痛い。
フレレとかちょっと触ったことあるけど痛いもん。
本当?
うまく変わんないよ。
そこは別なのかな。
なんか、なんか多分、別な気がするな。なんかわからんけど。
どうなんだろうね。逆は、逆は大丈夫なんじゃない?その。
ああ。
痛みに耐えられるわけじゃないんだよ。痛いは痛い。
ああ、そっかそっか。確かに。
そう。
厚い、分厚いだけで。
そうそうそうそう。
いや、でもギターもさ、やってくとその痛くなくなってくるし、その分厚くなるんだよ。
でも、あの、ボルディングほどじゃないけど多分。
ああ。
ちょっと弟の指と比べてみたら。
確かにね。
分厚かったら痛くないってわけじゃないっていう仮説があるね。
うん。痛いは痛い。
うん。
そりゃそうか。そりゃそうなんだよな。
痛いは痛いしさ、別に。ギターやっても皮は剥けなくない?剥けんな、あれ。
剥けないかな。相当、相当練習しないと。
そうだよね。
剥けんのかな。
剥けるし避けるのよ。
痛いな、それは。
そう。
剥けるし避けるから。
ギター。
うんうん。
なんか。
ギターで痛めるとしたら腱鞘炎とかの方が多いかな、多分。
腱鞘炎はあるね、それで。
うん。
すごい危険なスポーツと趣味を繰り広げてる我々って感じ。
いやでもギターはマジ危険じゃない。
ボルダリングの方が流石に危険かな。
危険?
まあ安全、ご安全にですね。
あ、そうですね。
うん。
クマの存在と備え
最近クマ、クマがすごくて、なんか。
クマ?
クマ。
その岩のさ、山の中だからさ。
ほうほう。
クマ、困るなあ。
クマ、クマ。
ああ、クマか。
はいはいはいはい。
ベアね。
そう、ベア。
いやー、なんか洒落にならん状況っぽいね、普通に。
そう、なんかまあいい季節だから、まあちょっとせっかくボルダリング再開したし、そろそろ行くかと思って、なんかクマスプレーを買いました。
いやー、マジで気をつけて。
うん。
あの、ツイッターでクマ出現マップのキャプチャー上げて、山全然出てないやん、山行こうって言ってる人がいて、それに対してあの。
人工密度ね。
そう。
あの、墜落した飛行機のさ、有名な画像あるじゃん。
ここ撃たれて死んでもあれの画像入ってくると、まさにそれやなと。
ちょっと面白かった。
違うんだよなあ。
いやー、面白い。
うん。
クマスプレー高いんだよなあ。有効期限があるから、処分するときどうしようって感じだし。
あー。自治体の指示に従ってください。
いやー、はい、そうします。以上です。
1個目、はい、じゃあ。
Firebaseの新機能
ファイアベース、ファイアベースフォンランバーベリフィケーションデベロッパープレビューっていう、なんだこれ、ファイアベースの記事だ。
これ実は読んでないんだけど、エイジさんがXで紹介してるのを読んだだけなんだけど、なんかあれなんだよね、電話の通信事業者からなんか取ってきて、なんかあれするっていうやつ。
読んだんで、ようやく書くの忘れたけど。
これ要はさ、ネットワークレベル、まあいいや、聞くわ。どっからSIMのデータ取ってきてるの。
その辺はね、書いてなくて分かんないけど、SMS、OTPの代替として、OTPを入力させる必要はないよって話で、なぜならその端末に入ってるSIMの情報をもとに通信事業者側の多分API的なものを叩いて、
で、その認証というか、番号の識別かをするからっていう話。
でもまあそれ以上のことそんな書いてないかな。
で、独立すべきはその通信事業者側と組んでる、やってる。だから別にこういう仕組みがあるわけじゃなくて、これやりたいからっていうので、
紹介はなんだっけ、名前忘れた。
テレコムセルト、テレコムと紹介枠、まずこの事業者に対応するよって話か。
で、この対応事業者をどんどん拡大していくよって話。で、まあ新しくAPI作ったって話っぽいですねって感じ。
一応ね、企画化されてるようなことを言ってた気がするが。
えっと、なんだっけ。
Firebase本ナンバービューケーション。これさ、Firebase以外もできるようになったりするのかな。
そうそうそうっていう話だったはず。
理屈的にはそうだよね。
今ね、探してる。探し、あ、そうそう、GSMAっていう、なんかGSMAが何なのか分かんないけど、
文章に貼ると。文章に貼りました。
W3C的なのにの業界があるのか。
一応なんかそれで定義されているプロトコルを使っているから、キャリアと契約を結べばどんなアグリゲーターでも参入できるっていう話らしい。
だからFirebaseじゃなくてもいけるし、実際Glideっていうサービスはすでに広く展開してるよっていう風に言ってるね。
なるほどね。これさ、フィッシング体制の話、確か記事にあった気がするんだけど、あるのかな。
ちょっとプロトコルの中身が分かんないけど、多分だけど、どうなんだろうな。
ニセサイトで。
分かるけど、フィッシング体制の話じゃないんじゃない?これって。
オンナンバーベリフィケーションが一発でできるよっていう話じゃないの?これ。
そうなんだけど、記事中にはSMSOTPだとフィッシングも含めていろいろリスクだよねっていう言い方をしてるから、
ちょっとミスリーディングなのかな。
そんな気がするね。
なんか関係ないよね。別にニセサイトでも通っちゃうもんね。
ただ、なんて言ったらいいんだろうな。フィッシング体制っていうプロトコルのようには仕様によるんだけど、
ネットワークレベルでその通信会社のネットワークからアクセスしてるよっていうのが、
要は担保されてるみたいな話であれば、フィッシング体制あると思うんだよね。
ネットワークレベルで。
でもさ、フィッシングでIDパス抜きましたです。
違うわ。
アクセス元がさ、アドバーサリー、インザミドルのアドバーサリーになるから。
確かにな。確かにプロトコル次第だね。
プロトコル次第なんだけど、逆に言うと、その電話じゃないと通せないはずだから、どうするんだろうね。
PCでアクセスしてて、SMS、OTP相当のことをやりたいってなったときに、
完全にその仕組みだけだと多分実現できないから、
ファスキーで言うとハイブリッドフローみたいなアプローチが必要になるはずで、
それをこのFirebaseのこれがサポートしてるのかちょっとわからんし、
ちょっとイメージがまだあんまり湧いてないかな。
そうだね。ドキュメント作り上手く書いたのかな。
確かに。
未来感もありつつ気になるところもありつつって感じだね。
ただ今どきアプリが多いよねっていう前提において、
会員登録時にSMS、OTPを通さなくてもいいよね。
かつ通信会社との連携で、その端末が実際にそのSIM使ってるかっていうのまでチェックできるから、
SMS代行みたいなのができなくなるわけじゃん。
より確実にそこに契約があることを確認できるよねみたいな話はあるかもね。
あとこの業界で生きてるとまあ必死がちだけど、
大半の人はそもそもPC持ってないから、
まあアプリでもWebでも動けば大半のユースケースがカバーできるとかもあったりするのかな。
人はわからんなあ。
なんか使ってみた記事を待ちたいね。
そうだね。
まあプレビューだし、
まああと日本ではまだたぶん。
ああそうだね。
実質。
まあもうちょっと先かなって感じだけど。
おもろいねこれ、知らんかった。
ありがとうございます。
おもろかったです。
じゃあ次いきますか。
はい、次。
MATRIX URIの脆弱性
Web開発で見落とされがちなMATRIX URIの解釈際の脆弱性、
TOMCATにおける認証開発やSSRFを実例とともに解説。
イエラーへのブログですね。
これ説明すんのか。
MATRIX URIっていうのがまずありますよっていう前提があって、
パス部分にセミコロンを使ってパラメータを記述する方式だよっていう。
セミコロンキーイコールバリューの形式でパラメータを埋め込めて、
この後がすごく特徴なんだけど、
パスのセグメントの中で扱うことができるよっていう。
これはブログの記事読んでもらったほうが早いんだけど。
例えばだけど、
プロダクトディティールみたいなパスがあったときに、
プロダクトセミコロンIDイコール123スラッシュディティールセミコロンラングイコールJAみたいな
そういうURLにすると、
裏の解釈とかどういう実装になるのかいまいち想像ついてない。
裏のコード、後ろのコードの実例見れば分かるんだろうけど。
分かるのかな。分かんないかもしれないけど。
どうなるか分からんけど。
この場合は多分プロダクトのIDが123で、
ディティールを日本語で表示してねみたいな多分解釈をするのかなきっとね。
そんな感じでパスの中にパラメータを埋め込める。
パスの途中にパラメータを埋め込めるっていう割とキモい仕様があって、
それの解釈がサーバーの実装とアプリケーションのURIのパーサーの実装の解釈がずれると壊れるよっていう話。
これ知ってたこの仕様。
知らない。
知らない。見たこと、いや分からん。見たことあるかもしれないけど。
少なくとも今思い出したか初めて知ったかどっちかな。
キモすぎるね、これ話ね。
これ普段使ってるフレームワークサポートしてるのかな。
分からんな。でもRFCあるんだもんね。
そうね。
next.jsとか。
Go、Matrix、URI。
お気に入りの言語で。
お気に入りの言語。
next.jsとかサポートしてなさそうな気がする。
一周経ってないかな。
Goにパススタイルマトリックスっていう定数がある。
ほんとかな。
一周検索しても出てこねぇもんな。
ジェミニで検索してみよう。
RFC3986で。
これ違うな。公式じゃねえのか。
公式じゃねえわ。多分ない気がするな。
RFCの。
RFCはいわゆる全般のやつだからあんま。
そうなんだ。
検索ワードとしては参考にならないか。
これでもよくよく考えるとなんでマトリックスURIなのかなって思ったけど、
確かにマトリックス組めるんだね。
このパソコンに組める。だからマトリックスなんだ。
おもろいな。
使えそうだけど誰も使わない系仕様。
おもろい。
使うとしてもAPIとかだよね。
UI回数の画面で使うイメージはまじで全くわかんない。
この場合はないな。
公式にはない。
ノー事実もパッとしちゃうって感じはなさそうだな。
こんな知らん仕様で脆弱性踏み抜いたらやってらんねえよって思ったけど、
対策としてはセミコロンを広げればいいよって書いてあって確かに。
どこでやるのっていう。
そこはアプリケーションの作り次第なんじゃないの。
でも確かにこの実装で見ると一番外側でやるのが悪いのかな。
しかも別にセミコロンが入ってても問題ないところもあるわけじゃん。
問題ないとかあるけど異常系として扱うしかないんじゃない?
普通にクエリパラメータにセミコロン入ってたらどうする?
それはもう…
それはそういう仕様が出たら考えるでいいんじゃない?
だって普通入んないでしょ。入るかなあ。
この記事で紹介されてるのは普通にアプリケーション側で
GetRequestUriを、要は何ていうか、
このMatrixUriを解釈しないやつで引っ張ってきて、
GetRequestUriで引っ張ってきて、
それの中にセミコロン入ってたら弾くってことをやってるね。
まあまあそれで別に十分だと思うんだけど、
なくても、
そいつがこのMatrixUriを解釈しないっていうのを検証するのとセットじゃん、これ。
そうだね。確かにね。
なんかめんどくせえなあ。
めんどくせえなあ。めんどくせえよ。
なんかどんぐらい刺さるんだろうなあ。
現代だとRain出てるような何層かで制御してるみたいなのってあんま、
モダンなスタックだとあんまりない気がするから、
実際に本当に刺さる場面で言うと限られてはいるんだろうなって気がするけどどうなんだろうね。
どうなんでしょうね。
どっかでアプリケーションサーバー立ち上がっててそこに直接行くと。
せいぜいLBとか。LBでいろいろ制御とか。
まあなくはないけど、そこで大事な認証を通すとかはないと思うし。
まあまあまあ。でもなんか面白かった。
知識としては。なるほどって感じでしたね。
はい。そんな感じですか。
そんな感じです。
いやあ、勉強になりました。
えー、3つ目。
どうしよう、向こう。
あー、これか。
ウェブ広告の変化
サードパーティークッキーアドベントカレンダー32日目。
プライバシーサンドボックスの後始末。
Jacksonのブログですね。
32日目。何日か明けての32日目ですけど、
まあ、シンプルにプライバシー。
まあ、ご存知の方はご存知でしょうが、
プライバシーサンドボックスのほとんどのAPIが廃止されますよっていうアナウンスが
Googleからされたという話ですね。
で、まあ、Jacksonのこのアドベントカレンダーでずっと追っていたわけなんですけれども、
まあ結局サードパーティークッキーの廃止の夢っていうのは、
まあ実質途絶えたっていうところ。
と、またその、まあなるほどなと思ったのは、
とにかく言ってサードパーティー…
Googleが広告市場下線しないためにサードパーティークッキーをやめなきゃいけないよっていうところの前提が
そもそもこの期間で変わっちゃったよねっていうところにも触れていて、
どの辺だったかな。
そうか。
ちょっと下の方だった気がするけどな。
プライバシーサンドボックスとは何だったのかな。
その市場の変化ってことじゃない?
ああ、そうだね。
えっと、ああ、そうだね。
GoogleがCMNに提出したリポートには市場変化を3つ挙げて、
プライバシー保護機能、新しいプライバシー保護機能とAIによる安全確保技術とグローバル規制の強化っていう感じで、
ただまああれか、なんかこれ自体は曖昧で、
ああ、そう、この威躍するとっていう部分がね、なるほどなって感じだったけど、
まあAIによってそもそもアドテックの形がどんどん変わっているっていうのと、
またそのウェブ広告の人気がめちゃくちゃ落ちてるっていうのがあって、
これはなんか知らなかったって感じだったけど、
逆にどこに足を伸ばしているかっていうと、
Netflixとかアマプラとかのコンテンツに差し込む形のCMの方がもはや主流になっていつつある。
ので、そもそもウェブ過剰状態じゃないじゃんっていう話が書いてあるって感じだね。
具体的なパーセントどっかに書いてある気がする。
ああ、そうだね。
AdWordsの広告主が購入したディスプレイ広告のインプレッションのうち、
オープンウェブディスプレイ向けはわずか11%だったっていうのが書いてある。
で、6年前の1月と比べると40%減ってるっていう状態。
だからそもそもウェブ広告っていうもの自体が下火になってるので、
まあまあまあ下線も何もねえよっていう話があるって感じですかね。
またもうページ見に来るのがAIばっかりになっちゃってとか、
クラウドフレアの部分でもトラフィックの6、7割ぐらいですか、
AIみたいな話もありましたけど、
っていう部分がまとめているって感じですね。
あとは確かにと思ったのは、
まあ31日目の記事にもっと決まったけど、
ディプリケーション、ディプリケーティングディプリケーション発表も、
前回の発表もそこまで大きな詐欺にならなかったので、
まあもう業界自体がどうでもいいっていうフェーズになってるのかもって書いてあって、
確かにっていう。
いや、悲しい。悲しい。
まあなんか、面白いね。一筋縄ではいかないっていうか。
なんかウェブでこういうこと起きるのちょっとおもろいよね、なんていうかさ。
なんだろう、ある意味ウェブらしくないというか、
なんか太陽でまごついてたら環境変わっちゃって、
得べき一種がなくなっちゃいましたというか。
なくなってはないんだろうけど。
縮小しちゃったというか。
AI中心ね。
コンテンツアド、ビデオ、メディア系などってなるともう、
あれだよな、サードパーティー、トラッキングとか。
まあでもトラッキング絡んではいるのか。
そこで見せる広告にトラッキングデータは使われてないのかな。
いやでも使われてなそうだよな。
クッキーは使われてないんだろうね。
ネットフリックスとかアマプラとかは使われてなそうな気がする。
直感的には。
YouTubeとかは使われてそう、普通にとか。
まあでもオープンウェブディスプレイ、
その辺オープンウェブディスプレイの定義とか調べてくれば。
なるほどって感じですね。
安定のギガ人も記事を出してるわ。
はい、一区切りついたということで。
プライバシーとその影響
副産物として残るAPIなんだっけな。
チップスと。
アトリビューション、プライベートステップとか。
まあこの辺は成長してもらったって感じですね。
こうやってみるとどんだけ要素が多かったんだよって感じ。
なんかだいぶいろんなもののセットでプライバシーサンドボックスって話だったし。
なんかそうだね。正直専用がわからんぐらい多かったイメージではあるね。
ジャックさんのアドベントカレンダーの記事も全部回数してたら日が暮れる的な感じ。
相当勉強しないと理解できないぐらい複雑みたいな話があったから。
まあまあ、なるほどなって感じです。
はい、ありがとうございます。
じゃあ次。
シスコ、AIにセキュアなコードを生成させるためのルールセット、
プロジェクトコードガードをオープンソースで公開という記事ですね。
何かっていうと、タイトルの通りであるんですけど、
プロジェクトコードガードっていうのをGitHubで紹介したような話で、
これ中身見に行くと何かっていうと、
前にWiZがAIエージェント向けのルールのテンプレみたいなのを公開したような話があったんですけど、
それのもう一歩踏み込んだ版って感じで、
AIエージェント向けのセキュリティ方面のナレッジとかをまとめてくれてるやつで、
かつこれが、これを見て初めて知ったんですけど、
クロードコードのプラグインで使えるようになっているので、
プラグインとして入れればすぐ使えるようになっているし、
あとはこのPythonのスクリプトがあって、
クローンしていろいろいじると自前でいい感じのルールを自動生成できそうな空気があって、
なので自分でカスタマイズっていうのもできそうな気がしているので、
割とちょっと一歩踏み込んだものが出たなっていう印象ですね。
あとプラグイン知らなかったのはちょっと恥ずかしながらって感じなんですけど、
早速この前クロードコードのスキル的なのが出て、
えーっと思いながら見てたんですけど、
その機能も使ったアセットとかが盛り込まれたりしてて、
なんでルール、えっとね、ディレクトリでいうと、
モーション貼り付けるか、スキルのルールみたいなのが全部マークダウンでバラバラになってるんですけど、
そういうとこ見ると、すごいいい感じのルートでこうしろっていうのがまとまってて、
うん、いい感じですねっていう。
ひでぇ話や。
なんだろうな、会社の人と話してたんだけど、
セキュリティプラクティスを全部食わせてコーディングさせるのは、
結構モデルのコンテキスト的に限界があるよねって話をしてて、
なるほどねってなってたけど、このスキル図とか使うと、
AIが事実的に必要なコンテキストを自分で取りにくるって挙動になるから、
たぶんこういう現状のAIモデル、
AIエージェントではこういう形でナレッジを整理していくことになると思うんだけど、
具体的にどうやんねんみたいな部分の一つの例としてはすごい助かるなっていう気がする感じですね。
知見の切り方とか、ランゲージとか、
記事読むっていうか、このリポジトリザーッと眺めて、
あわよくばプラグインで使ってみてっていうのがお勧めかなという気がしております。
まだ試したらいいんだよな。
でもこれに変なプロンプト入ってたらさとか思って、
一瞬、明日考えるかって言ってまだ入れてるんだけど。
あって入れるか。
うっす、いい話。
いいよな、こういうのベースにして。
そうだね、助かるね。
あとこういう形で社内に配るっていうのもできるんだなっていうのは普通に勉強になったな。
マークダンペライチとかでもいいんだけど。
その辺はちょっと要勉強かな。
じゃあ次。
ランサムウェアの傾向
これね。
Insider Threats Mobile Ransom Payment Rates Prompt。
CovWareっていうセキュリティベンダーのレポート記事ですかね、
CovWareっていうものかな、ちょっとわかんないですけど。
何かっていうと、ランサムウェアの2025年Q3なんで、
6月から9月か、今年のランサムウェアの傾向のレポートって感じですね。
最近ランサムウェアのレポートをちゃんと読んだりしてなかった中で、
ちょっと目についたんで読んでみて、
なるほどねって感じで、現状確認って感じで。
割とわかりやすかったんで、紹介できればなと思うんですけど。
詳細は読んでくださいって感じなんですけど、
超ざっくり言うと、一つはタイトルの記事にもあるんですけど、
ランサムのミノCキャンの支払い率が全体的には下がってるよって話があって、
なんでこれは良いニュース。
業界全体で支払い率下がっていけば攻撃する側も儲かる確率がどんどん減っていくんで、
これ自体は良い傾向だし、
また例えばダイキッドとかで滅多滅多にやられるケースがあったとしても、
あそこまでやられても払わないっていう事例もちらほらあるので、
攻撃者目線は結構骨折り損っていうパターンもおととしおちに出ているっていうところがありますと。
ただ支払いが渋り始める傾向に合わせて攻撃者もちょっと手を変えていて、
具体的にはまず大企業向けと中小企業向けで分けられてるんだけど、
大企業向けに関しては攻撃の成功確率を上げるために、
そもそも前提として10年前とかと比べるとみんなもう警戒してバックアップをちゃんと取るとか、
基本的にセキュリティ対策をするっていうのをやり始めてるんで、
内通者をいかに作るかみたいな攻撃手口がちょっとちらほら出て始めてますよっていうのが、
大企業側の傾向としてありそうというのが一つある。
ここでは紹介しなかったけど、BBCの記者があったんですよ。
身の背負う金の15%払うからあなたのアカウントのアクセス権くれないっていう、
テレグラムで来たっていう事件があって、
その来た人はその記者魂を燃やして、
分かったよってフリでずっとやり取りして、
上司とかに許可取った上で、会社に許可取った上でやり取りして、
そのやり取りの全貌を記事にするっていうのがあって、
結構それも面白かったんだけど、
そういう風に個人狙い撃ちでお金あげるよって感じで来たりとか、
また実際にもはや内通者系よりやられちゃったケースも、
多分ちらほらばあるはずなんで、
その方が攻撃者目線コスパもいいし、難易度もめちゃくちゃ下がるしっていう感じで、
そういう傾向がありそうだよっていうところと、
あと一方でそのデカいとこ狙うのがシンプルに難しいって話で、
中小企業をたくさん狙うっていう手法も傾向もちょっとあって、
ただこっちはなんでなんだろうな、
安い身の使用金で大量に数を打つっていうスタイルなんだけど、
こっちはなんかその数を打とうと思うと、
その攻撃…何サムマフィアとか呼ばれてるんですかね、
攻撃者グループだけでは数打てないから、
ランサメアーザーサービスみたいなのでツールキットを用意するから攻撃してね、
何パーセント渡し出してくださいねっていうモデルがずっとあったんだけど、
なんかその辺をやり出すとやっぱ普通のサービス運営みたいに、
ラースっていうんですけど、ラースの運営とかやり取りのコストとか、
それを運営するために人件費が発生してみたいな感じで、
結構攻撃して身の使用金を持ち逃げされるみたいな話とか、
攻撃者会のネットワーク内でごちゃついてるらしくて、
こっちがなんかちょっと不安定にはなってそうみたいな話があるっていう感じなんです。
なんでそれは僕ら目線はいい話なんだけど、
とはいえまだまだ中傷を狙う攻撃はぼちぼちありますよっていうところ。
ランサムウェアの歴史と影響
気を引き締めつつっていうところの話ですね。
具体的な数字で言うと全体ならして、あれかな、
身の使用金の支払い率は23パーセントになっていて、
これは6年前は85パーだったんだ。
そうだね、なんで、6年前と比べると劇的に違っているとか、
また暗号化しないけどデータ盗んで脅すパターンとかは19パーセントぐらいですよとか、
あとは初期攻撃ベクトルみたいなやつもあって、
えーっと思ったんで見たけど、今はリモートアクセスコンプロマイズ、
SaaSのアクセス権を盗むとか、VPNの脆弱性使うとか。
あとRDPも。
そうだね、そう。
そういうのがまだまだ健在になると、
フィッシングはグラフ見る限りぼちぼち減りつつ、
順位的には2っていう感じで、
ソフトウェアバナナベリティーは脆弱性ついてみたいなパターンも
ぼちぼちなのかな。
15パーぐらいなんですか、この数で言うと。
インターナルは内場派みたいなやつだけど、内場はまだ、
そんなグラフでわかりやすく上がっているとしてないけど、
このレポートの主張的には第9号向けに対してはちょっと狙われ始めるかもよっていう論調って感じですね。
はい、なんかスーパーざっくりこんな傾向でございますっていう話でした。
結構なんか、これ系のレポート読むのしんどいやつ多いんだけど、
このレポートはすごい読みやすくて、
ざっと現状のランサムコキーどんなんなんだっけっていうのを知るには
割といい理由かなという感じですね。
後半の方に行くと、
しかも前半の方に大事なことがあって、後半の方は詳細なデータが立ったりするから、
僕みたいな読み手にとってはすごいありがたい。
前半だけ読んで満足してみたいな感じですね。
そんな感じでございます。
はい、ありがとうございます。
まだまだ、まだまだですね。
10年、10年、10年経つんだなってすごいランサム出てから、
10年前僕がランサムランナーしましたよなって。
10年前が最初のランサムウェア被害なの?
なんかね、歴史の話では10年前っていうこと言ってるね。
確かに初めてのランサムコキーって言ってたんだろうね。
ランサムウェアの歴史。
でもそうだ、歴史そうだね。
1980年後半にはすでに犯罪者が暗号化されたファイルを引き続き父に取り、
被害者に現金を郵送するように要求するケースが発生していたらしい。
だから歴史言うと46年だと思う。
だいぶ前から毎日あるわ。
でも普及し始めたのがあれか2010年ぐらい。
ビットコインとかで出してからって話か。
お金の…なるほどね。
確かにね、足つきづらいもんね。
いやー、凍結感もできないし。
いやー、なんかセキュリティ会話の情報キャッチアップしてるとなんか、
ブロックチェーンが生み出した価値と、
なんかその負の側面に釣り合ってるのかって気持ちになっちゃうんだけどどうなんだろう。
なんかそれはさ、結構あるあるじゃない?
その、なんか暗号通信技術の発達によってこう、
あー、まあ確かに。
世の中でどんなやりとりがされてるかわからなくなったし。
MCPサーバー管理の新しいアプローチ
確かに。犯罪者ネットワークにつかれてるとか。
まあ確かに確かに、まあそう思うとそうだね。
トータルで見てどうなのっていうのは確かに難しいんだけど、
なんかシンプルに僕のブロックチェーンの回想度が低すぎて、
なんか勉強したいなと思いながら5年ぐらい経ってしまったわ。
誰か教えてほしい?
なるほど。
まあそうですね。
だから流行り始めたのは、
40年前ぐらいから事例はあったけど流行り始めたのは、
まあここ10年、15年の話っていう捉え方が良さそう。
またエコシステム化してきたのがここ数年とかなんじゃないかな、きっと。
そうだね。
それはなんかランサムウェアに限らず全部そうなんじゃない?
なんかリードスとか。
そうだね、そんな気がするね。
まあ興味ある方ぜひサラッと読んでみてください。
ありがとうございます。
じゃあ次は、まあサラッとでいいかなって感じなんですけど、
GitHubのブログかな、ブログで
How to find, install and manage MCP servers with GitHub MCP registry
っていう記事ですね。
どういう記事かっていうと、GitHub MCP registryっていうのがあって、
ちょっと前だよね、出たの。
紹介しなかったけど記事はここで、
これに流れてみたような気がする。
そうだね。
その時は出たばっかの時はあるでしょ、
MCPサーバーの一番有名なレジストリ、
名前忘れたけど。
何だっけ?
分かんない。
それ系統かなと思ったけど、
この記事で紹介してたのが、
GitHubのオーガニゼーションのメンバーがVS Codeとかで使うMCPサーバーっていうのを
招集権的に管理できるよって話をしているっていう感じですね。
あとはこのレジストリに登録されてるやつに関しては
全部オース認証統制になるから、
認証コード、認証トークンみんなが手元でハードコードする心配もないし、
ホワイトリストも読めるっていうのが書いてあって、
これが求めてたものですっていう気持ちで
さらっと紹介できればいいかなっていう感じですね。
クラウドフレアとかは多分単一のサーバーで
全部のMCPサーバーを並べて管理できるようにするみたいなアプローチだったと思うけど、
GitHubのほうは多分これに対しての課金とかなさそうに見えるから、
スモールに始めるならこれがいいんだろうなっていうところと、
デメリットとしてはおそらくこのGitHubのMCPレジストリって48個しかまだ登録されてないから、
これに入ってないものを使いたいって言われると、
どうするんだろうっていう部分はちょっと考えなきゃいけないかもっていう感じですね。
認証管理と今後の展望
ドライにやるんだったらこれに入ってるものしか使わないでくださいって話になっちゃうのかな。
うーん、そうだね。
なんかその辺は、なーとか、もしかもこれと、
これにあるやつはもう何も聞かずに入れていいよ、
でもこれに入ってないやつはレビュー通してねとか。
うーん、そうだね。
セレナとか入ってんじゃん。
なんかセレナとかどうなのかって言おうとしたけど。
うん。
あれ、これ自体はなんらかGitHubが保証してくれてるかで言うと、
確かね、ある程度は審査とかしてるはずかな。
でもパブリッシュは誰でもできるんだよね。
パブリッシュはできるね。
パブリッシュはできるけど、どうなんだろうね。
即反映されるのかどうなのかっていうのは分かんないね。
パブリッシュはね、そうだね、ワークロウとかも書いてあるね。
うん。
確かにな。
何でも持ってくるんだったらやっぱ。
あー、でもなんかリクエストをメールで送れって書いてあるな。
だから。
あー、ほんとだね。
そこでチェックが入るんだね。
うん。
まあそうだよね、48個しかないってことはそんな。
だからこれからなんかドット増えるんじゃないかと。
うんうん。
知らんけど。
そう思うと、なんかこれに別途するのは全然悪くない気がするね。
ザピアとかもあるんだ。
MCPとか。
でもさ、ここに入ってるものだったら使っていいよっつっても、つってもさ、あるよな、なんか普通に。
まあ、そうだね、あの、いやーどうしてんだろうね、各社。
ね。
使いたいものがなんか、どうだろう、どんぐらいばらけてくんだろう。
うん。
いや、しかもなんか別にさ、GitHubがどういう基準で何を見てやってるのかとかわからんしさ、その。
まあ、そうね。
なんか、これのMCPはまあ使ってもいいけど、みたいなのがなんかありそうだよな。
これはダメみたいなのが多分あると思うし。
でもなんか別にGitHubとしてはなんか別に、それは知らんわっていう。
さ、細かいところなんかは見ないんだろうね。
うん。
これをベースにその、アラウリストディナイリストみたいなのを作って、
管理者が運用できるんだったらワンチャンリストだよね。
うん、そうだね。
まあ、この記事自体はそういう話かなっていう気はするから。
いやー、でも無理、無理じゃねえ。だってGitHubのアカウントでは無理だもんな。
何が?
要はこのオーガニゼーションの端末ではこれ動かしちゃダメみたいなのできないじゃん、GitHubのアカウントって。
ああ、だからこの記事だとそれができるって話だね。
そういうこと?
VS Codeとかに関しては、そうそうそうそう。
でもそれさ、だってさ、個人のPCと会社のPCとどうやって関係するの?
あー、そこら辺はよく分かってないな。
