GitHub Advisory Databaseの探求
こんばんは、Replay.fm第42回です。 こんばんは。
どうした? 暑い。暑い、暑いね。
暑いよ。さっき雨降ったんだよな、でも。 あ、本当? うん。
こっちは、今日は降ってないかな。 なんか昨日か一昨日に、
その昼休憩の時に、気晴らしに、なんか家が、 うん。
まあ、山かな、山。 山としましょう。山の上のマンションに住んでるんですよ。
山の上のポニョ。
ポニョかどうかは、ちょっとさておきなんですけど、
要するに、坂があって登って、公園通って、公園がそのまま山、山がそのまま公園みたいになってるんですけど、
山って言うほどではないんだけど、歩いて、
まあ、10分弱ぐらい坂を登り続けてマンションにたどり着くみたいな。
なるほど。 その山のふもとにコンビニがあって、
で、なんか、下界に降りて、 そう、下界に。 買い物をするわけですか。
そうそうそう。 昨日だっけ、一昨日か。
一昨日、一応なんで、昨日休憩があったら行ったんだけど、もう、
帰り、気づいたら、その、歩いてるだけなのにもう汗びしょになって、なんか、ぜいぜい、
あの、全力疾走した後みたいな、息づかいの。 全力盛り上げて。 上下全部、全力、上下全部着替えてみたいな。
コンビニ一応服しただけで、すごいダメージを負って、
くたくたになって午後のミーティングに出るっていう。 ああ、いい運動じゃないですか。
いい、まあね、いい、でもなんか、いい運動なのかな。
一回知られたんだけど、なんか汗の量ってそんな別に消費カロリーに繋がんねえらしい。 まあね。
疲れたーと思いながら、みんな倒れないでください。
複雑だな。Aやんて何が。
歩くだけで、コンビニに行くだけで鍛えられる環境。
そういう環境に身を置くことで、なんかめちゃくちゃ強いセキュリティエンジニアになれる。
まあ勉強もいいね。ここ数回の中で一番雑でいる。
まあなんかね、普通に今日ね、ちょっと疲れてるわ、なんか。
気を失う前にやっていこう。 あんまなんかだって、昼間吐きなかったと思うんだよな。
あんま頭回ってなかったよね、多分。 まあそうかもしれない。
夕方ぐらいになってちょっとずつ復活してきた感じがする。
今日はもういいよ、セルフィーなんだよ。 首しちゃったし、俺も今。
じゃあ1個目。
えー、そう今日はね、私ほぼ実は読んでなくて、なんか、お願いします。
はい、GitHub Advisory Database by the Numbers. Known Security Vulnerabilities and What You Can Do About Them
っていうGitHubブログですね。アップデートとかじゃなくて普通にブログかな。
はい、ブログっすね。 で、まあどういう記事かっていうと、
GitHub Advisory Databaseっていうのがまずあってですね、ご存知の方も、
セキュリティやってる人だったら知ってんのかな。
なんか物は見たことあるんだろうけど、なんかあんまりあれだな。
何だか分かってないな。
そうだよね。まさにそれを解説してくれてる記事で、僕もふわっと使ってたんで、
なるほどってなった部分があって紹介したいなって思ったんですけど、
これ自体何ぞやっていうと、GitHubが独自で提供している脆弱性のデータベースですね。
で、脆弱性のデータベース結構いろいろあって、僕もそんな詳しくわけじゃないんですけど、
それこそ記事で引用されているところのNPMの脆弱性情報を集めたようなデータベースもあるし、
各パッケージマネージャーですね。パッケージマネージャーのものもあれば、
KEVとかもある種のデータベースだろうし、CV、NASDAの本家の方のやつもデータベースと言えるでしょうっていう感じなんですけど、
このGitHub独自でじゃあわざわざなんで提供しているかみたいなところで言うと、
今やったようなCVはもちろんですけど、他に2つ大きなソース元があるよっていうのがあって、
どっかに書いてあったんですけど、ここ忘れちゃったな。ああ、これだ。
まずは、マルウェアの報告情報みたいなのをデータベースとして取り込んでるよっていうのと、
GitHubがレビューした脆弱性情報が入ってる。
これは記事中ではその報告へのリポジトリがあって、そこに上がってきたやつを全部GitHubがひたすらレビューしてやってるっていうところと、
あとはCVですね、NVDの方から引っ張ってくるものがありますっていう感じ。
そもそもでもGitHubが、正しい話は忘れてたな、記事中のどっかに出てたんですけど、
CVの発行ってNSTが主導してるんだけど、あの数多の脆弱性を全部取り扱いするっていうのは不可能なんで、
いくつかの著名な企業がCVを裁判する企業として認定みたいなのをされてて、そのうちの1社がGitHub。
だからGitHub自体がまずCVにネットしてるっていう部分があって、それもあってこのレビューもするし、
記事中ではGitHub Reviewed AdvisoriesっていうGitHubがレビューしたの。
なんでこれは多分CVも発行されるんじゃないかっていうものと、Unreviewed Advisoriesっていうのが書いてあって、
これはなんかGitHubはレビューしてないんだけど、他の企業がレビューしてCVが発行されたものをNVDから取り込んでるっていうので、
Unreviewedっていう表現をしてるだけで、実際にはどっかの企業がちゃんとレビューしたCVのデータベースが入ってくるっていうような構成になってる。
なのでこの主に3種のデータをガッチャンコしていい感じ見れるようにしてるし、
あとは記事ではないけどAPIとかでも取れるんですよね、一応。
取れるようにしてくれてるのがこのGitHub Advisory Databaseっていう話ですね。
MCPのアップデート
そうですね。っていうのが外観なんだけど、個人的になるほどなと思った部分は、
そのデータベース、集めてきたデータベースの特徴みたいな話とかをしてくれていて、
GitHub独自のセビリティを4段階振ってるんですよね。
クリティカル、ハイ、ミドル、ローかな、多分振ってるんですけど、
この辺振った時にその割合みたいな話を言うと、クリティカルとハイが半分を占めるっていう割合なんで、
記事中の表現では半分に絞れてるよっていう、だからとりあえずの動力半分になるよって表現してるけど、
なんか僕は半分しか減らないのかって気持ちになりつつ、
でも下げるより2分の1になるならいいのかなとか思ったりとか、
またなんかエコシステムごとのデータの傾向みたいなのも貼り付けてくれてて、
なんか表みたいなのがあるんですけど、どこだっけな、結構下の方かな?
そうだね。逆じゃん、上じゃん。
上か。NPMで、これだ。
ピッポーイねー。
言語ごとの、なんだろう、あれかな、脆弱性のトロクスみたいなやつですけど、そうですね、ピッポーイですね。
これ多分ね、GitHubの方が多いのかな?GitHubの方が多くなってて、レジストリ側でフラグが付いてるのはそれより少ないから、
GitHubの方がカバレー帳が大きいんだけど、ピッポーイですねとか、
名分もめっちゃ多いね。
なんか結構、コミュニティの大きさが反映されてる感がともろくて、
ラストとかになってくると850件とかになってきて、
アーランとか3Gとかしかない?
アーランより少ないパブ、すげーなってちょっと思ったわ。
パブ10件。
あとなんか結構個人的にびっくりしたのは、GitHub Actions21件しかなくて、
確かに僕なんかサブスクライブしてたんですよ、GitHub Actionsだけの脆弱性が流れてくるやつ。
サブスクライブしてたんだけど、1回も見たことなくて、
なんかへーと思ったというか、考えてみたらその脆弱性…
なんだろうな、脆弱性として判定しづらいのかな?みたいな、
本質的になんていうか、
ゆるいイコール脆弱性にはなんないけど、やっぱ丸い足込まれたら脆弱性だけど、
今は発生してないというのに少ないのかな?とかちょっといろいろ思いを馳せてたんですけど、
そんな傾向が見れたりとか、
あとはなんか自分はやってなかったけど、
この膨大な量からいろいろフィルターするためにいろんな指標を提供しているよって話も別の記事でもなんか紹介した気がするけど書いてあって、
CFSS、DPSSあたりを提供したりとか、
CWEも全部振ってるから、それで例えば、
サービス拒否攻撃のやつは省いて、
SQLインジェクションの方を見るとかもできるよみたいなことがあって、
これはちょっと仕事でやったこと実はなかったから、やってもいいかもなと思ったりしたって感じかな。
他の言語わかんないけど、Node.jsはマジでなんかリドスの…
あれ、なんでなんだろうね?
なんであんなにリドスばっかり出てくるのかちょっとわかんないんだけど。
エコシステム的にパッケージがめちゃくちゃ細分化されてるから、
文字処理のユーティリティみたいなパッケージがめっちゃ多いのと、
それを使って、それでたぶん一個めっちゃこれっていうのが決まると、
おびただしい数の有名なパッケージがそれを使うみたいな状態になって、
それで一個発火しちゃうと、いもずるでめちゃくちゃ出ちゃう。
原因かなっていう気はしてる。
本当に有名どころとかが、孫の孫ぐらいに実はそれを使ってる。
言語性質あんのかな?なんかはないんだろうけど、
見てる感じ別に他の言語でも起きるようなって感じのものが多いから、
そこはなんともって感じですね。
語だとあんま起きないかもな。
そうなんだ。
あれかあんま依存の依存の依存みたいなのってあんまり気にせんでない。
そうだね、確かに。
いい気がする、語に関しては。
他はちょっとわからんけど。
NPMの良さであり、良くも悪くもって感じが個人的にはするな。
細分化されてると責務はちっちゃく済むよねって話と、
こういう時にやっぱずるずるといったりもするから。
これって結論ここだけ見てれば、
NVDで出してるものとかも全部カバーできてるっていう状態ではあるんだよね?
うん、その辺りですね。
なんかちょっと意識して使ってみようかな。
これけんデータベースね、あんま調べたことないけどいくつかあるんですよね。
スニークとかも多分データベースになってる気がするし。
フィードリーとかも実はあるんですよね。
あー、なんかあったかも。
使ったことないけど。
バリナリティダッシュボードか。
あれか、フィードリーは多分関連する記事をいい感じに引っ張るみたいな。
で、有料版か。それってインテリジェンス的な意味合いが強いんだね。
そんな感じの記事です。
いいね。
じゃあ、次行きますか。
タイトルだけ読むけど、モデルコンテキストプロトコルスペックアップデート from June 2025
オースゼロの記事なんですが、元ネタはモデルコンテキストプロトコルの公式のキーチェンジ、リリースノートから引っ張ってきてる話ですね。
割と大きい話で、MCPのサーバーがオースのリソースサーバーとして分類されるよみたいな話。
オースゼロの記事中に図はあるんだけど、例えばオースライゼーションサーバーからトークン取ってきて、
トークンをMCPサーバーに投げると、割とオーディエンスだねみたいなのをチェックしてくれるよみたいなフローが書いてあるんだけど、
そもそもこれローカルでも動くのかな、成立するのかなとか。
成立するんじゃない?あくまでローカルで動いててもサーバーはサーバーだから、リモートにあるかローカルにあるかの違いだけしかない。
でもリライブエンドポイントがあれか。
そうなんだよね。
そもそも多分MCPの仕組み的にそういう感じにならないんじゃないかな。
全部JSONで渡す感じになってるから。
URLのパラメーターとか解釈しないと思うんだよ。でもクライアントは解釈するから関係ないのか。
ごめん、なんでもないわ。
今なんか紛らわしいのはクライアントとサーバーが同じデスクトップアプリ内に同居したりしてるからややこしいんだけど。
多分イメージしてるのってAuthorization Code Flowだと思うんだけど、この図だとそこまでは分かんないよな、それを実装できるのか。
あとなんか個人的に結構気になったのはこの下の方というか、
プレゼントストーリー、マイシャースワークとプレゼントストーリー、MCPサーバーB。
これよく分かんない。図だけ見ると、例えばMCPサーバーAのトークンを正規のAuthorization Flowで取ってきたら、
MCPサーバーA側では使えるけど、それを盗んで別のMCPサーバーBで使おうとすると、
MCPサーバーAではないから弾くよみたいなのを実装しなきゃいけない、みたいな仕様が入ったみたいなことがあって。
これがなんかどういうことなんだろうっていうのが。
それがね、多分、プロテクテッドリソースメタデータとかその辺が関わってくるんじゃないかなと思っていて。
いやー、OS勉強し直してきますって気持ちになったんだよ。
そうなんだよ、めっちゃ同じこと思ってて。
急にここで話すかすごい迷ったんだけど。
いやー、むずいよ。難しい。ちょっとなんかもう1回勉強し直すかな、これ。
そもそもこのプロテクテッドリソースメタデータってちょっと新しい仕様だから、
オースインアクションとかに載ってないはずなんだよね、これ。載ってないんじゃないかな。
載ってなかったような気がするんだよな。ちょっと覚えてないけど。
あとさ、個人的に気になってるのはこれちゃんとみんな実装するかな、NCPサーバー。
分かんない。分からない。
どれとは言えないけどめちゃくちゃ有名でオフィシャルインテグレーションになってるやつでも、
APIトークン認証でハードコードでみたいなやつを起こしてるから。
追いついて欲しいなって気持ちはありつつ。
まあでもいいね。それ言ってもしょうがないわ。
これを使ってるやつを、これを準拠してるやつを使っていくっていうのが取るべきことだな。
でもトークンのそのハードコードみたいなのってさ、なんか別に解決しないんじゃない?
だってNCPサーバーがリソースサーバー、リソースサーバーとして振る舞う形になるから、
クライアントがNCPサーバーにアクセスすることを許容するって話でしょ?
そうだね。それでどうなるんだろう?
だからGitHubのリモートNCPみたいな感じで、
ローカルのクライアントに対してGitHubのNCPサーバーにアクセスすることを認可しますか?
みたいなのをリモート同士でやるっていうのは普通にあるシナリオかなと思うんだけど。
その辺どうなってるんだろうな。わかんないな。
こうあればいいなって思ってるのは、NCPサーバー設定書きますで、そこの時にトークンを書かずにアクセスします。
紹介アクセスしては、未認証状態だからこっちで認可してこいっていうのをクライアントに返して、
クライアント側でそれを解釈して、何でもいいです。画面立ち上がってポチポチって認証って押したら、
NCPサーバーに返ってきて、トークンを書き出して、今後はそれでやる人ですみたいな。
正解性になればハードコートの概念もないし、認可もされるしみたいな感じなのかなと思いつつ。
この記事読んで思ったけど、一回ちょっと実装していきますわ。実装しました記事を書きますわ。
実装しないといけない記事。
オースありのNCPサーバー実装してきた。
オースありのNCPサーバー。
オースなしのNCPはやった?
やってない。
やったほうがいいよ。
やったんか。
週末にちょろっと触ったけど、特に触ってみた結果作りたいものが今はないなと思って、
サンプル作って終わったんだけど、
なるほどね。
サンズ触ってる人からしたら何を当たり前のことって言ってるかもしれないんだけど、言われるかもしれないんだけど、
ローカルだとそもそも実行ファイルのパスを指定して、その実行ファイルに対して標準入力でJSONを渡すんですよ。
そうするとレスポンスが返ってくるっていう。その1回1回に繰り返しなのにあれって。
多分ちょっとイメージしてるサーバーっていうのと違う気がする。
特にローカルの動きにおいては。
ローカル限らないのか。
なるほどね。
HTTPじゃないんだよな。
そうだよね。
JSON RPCっていう仕様になっていて、結局STDIOで渡せればいいだけだから、
HTTPのリクエストとレスポンスのボディーがJSON RPCになってればいいっていう話であるから。
JSON RPCはあなたと混ぜ込んで。
トンネルが何なのかは別に何でもいい。
そうだね。なるほどね。
ただ一方でHTTPのレイヤーからこのレイヤーに踏み込むっていうのはできないはずなので、
だからさっき言った通りURLのパラメーターとかで何かを渡すっていうのはこれ単体だとできなくて。
なのでJSON RPCのパラメーターとして渡さないといけないはず。
なるほどね。
なんかGitHubのリモテムCPのサーバーのやつとかちょっと調べつけよう。
やっぱ初回アクセス者認可みたいなのが走るから、何か仕組みがあるんだろうな。
でも多分URL開いて、このURL開いてみたいなのは多分JSON RPCでできるはずなんで、URL渡せばいいだけだから。
うんうん。確かにね。
あーだからそこは結構僕に、いやーちょっと作ろうか。
しかしJSON RPCこのタイミングでまた見ることになるとはなー。
何で見たの?
いや見たというか、俺が新卒の頃に結構これが次のHTTPの、違うこれが次のRESTだみたいな感じで。
なんかちょび盛り上がりしてて。
へー。
そうなんかなーって思いながら見た。そんなに流行ってなかった。
いやおもろいな。
まあこういうケースは確かにマッチするな。
いやー。
まあでも、いいニュースですね。
仕様にとっては小さな一歩、責任にとっては大きな一歩。日本が書いてある。間違いない。
ありがとうございます。
はい。
じゃあ次行くかー。
そうですねー。
レジデンシャルプロキシーの理解
えーっと、サイバー犯罪を支えるレジディネーシャルプロキシーのタイトル。トレンドマイクロさんのブログですね。
まあこれは、読んだんで話すと。
レジディネーシャルプロキシーとはって話をしてます。詰まるところ。
で、多分このPodcastでレジディネーシャルプロキシーとはっていう話をしたり、そういう記事を紹介したことはなくて。
なんかちらっと話を、言葉を出したことはなかったけど。
なかったんで、自分の復習がてら読んでみて、割とよくまとまってるなと思ったんで紹介しようかなって感じなんですけど。
まあまあレジディネーシャルプロキシーとはなんぞやっていうのを説明してるのと、なんか対比としてボーダンホスティングとの比較っていうのをしていて。
まあそれはちょっと個人的には、あの、モテてなかった視点なのかなと思ったんですけど。
まずボーダンホスティングとはなんぞやって話からすると、ボーダンホスティングってのは詰まるところ、なんでしょうね。
犯罪者向けの桜VPSみたいな感じだと思ってくれればいいんじゃないかなと思ってて。
その犯罪に利用するプロセスとか、C2サーバーとか、レアのダウンロード元とか、なんかいろんなものを悪さするときに使うためのサーバーっていうのが当然必要になるんだけど、
それを貸し出していく。
まあ表向きはそうじゃないことの方が多分多いんだけど、実態としては犯罪者向けに貸し出しているようなサーバーサービス、ホスティングサービスのことで。
特徴としては、例えばユーロポールの操作が及ばないような国でサーバーセンターを建ててるとか、
サーバーの所在をおいずらくするためにプロ機種でランプホップもしてホスティングできるようにするみたいなものがあって、
なんで犯罪者側は利用しやすい、足がつきづらい、捕まりづらい、止まりづらいみたいなところで使われているものなんだけど、
弱点としては、言うても固定された実態はマシンサーバーなんで、
例えばユーザーIPみたいな形で防がれて、そこで立ちごっこをしなきゃいけないとか、
そういうところまで基地のボーダンホスティングプロバイダーとかだったら、
ブラックリストに入れられては即完了があるみたいに立ちごっこをしていかなきゃいけないというのが、
彼ら目線の弱点としてあるというのが元々ボーダンホスティングがあるんですけど、
そこに対してレジデンシャルプロキシーは何か対処してきたって言ってるのが何かというと、
単的に言うと全世界の家庭で動くいろんなIoTデバイスとか、
多分ほぼ大半はインターネットルーターとかで動くプロキシーサーバーを通して、
いろんな場所へアクセスできるというサービスがレジデンシャルプロキシーサービスになっていて、
特徴としては今言ったように全世界の一般の家庭で動くような、
もしくは一般のいろんな場所で動くようなデバイスからのアクセスになってるんで、
数多なIPアドレスが使えるし、そのIP自体はさっき言ったボーダンホスティングとは違って、
普段は一般のアクセスしか来ないので、かなり見分けがつきづらいし、
IPのブラックリストを作るみたいな観点に立った時に、
キリがない、数も多いし日々増えたり増え続けてるっていうのもあって、
なかなか守る目線はきついし、悪用する目線は便利なものになっていて、
これが対等してくれるよっていう話ですね。
細かい要素は他にもいろいろありつつなんですけど、
他に言うと、これに対してどうすりゃええねんみたいなところの話もしてくれていて、
これ僕知らなかったんですけど、例えばJ4プラスっていうオープンソースがあって、
これを使うとある程度検出できますよみたいな証拠がされていて、
これどういう、フィンガープリントか、フィンガープリントを見るっていうアプローチがあるみたいで、
その辺はめっちゃ詳しく記事に書いてるんで、興味ある人は見てみてくださいって感じで、
僕はちょっとそんなにネットワークが詳しくないですけど。
検出方法の探求
何をしてくれるん?
チェックオンの例書いたらパケット帳とか、
TCP帳兵、おもろ。
これで分かるの面白いね。
でも何か一定のマルウェアとかを押し込んでやってるからっていう感じなのかな、その一定のパターンが。
そうだね、何なんだろう、その辺がちょっと知識が浅くてあまり分からんかったんやけど、
これも何か当然完璧じゃないんだけど、60%ぐらいの精度では使えるらしいトレンドマイクロがこのブログで検証した感じ。
向こう側もレジンシャプロキシー側がそんなにめっちゃ工夫してないとかであるのかな。
そうだね、IPアドレスのこととか。
結構フィンガープリントの話。
この辺になってくると真面目に読むのがはっきり見える部分なんだけど。
地理の話とか、かなりいろんな取れるもの全部取ってるっていう感じでやってるっぽいね。
あとはこういう防ぎ方あるよって話はありつつ、今言った通りちょっと検証してみても60%の精度しか出ないっていう見方もあるんで、
ちゃんと防ごうと思うと結構複数の指標を組み合わせないと厳しいっていうのも書いてあって、
防御の課題
例えば従来の何でしょうね。
同一IPがそのIPがアビューズでもなくてこのJ4プラスにも引っかかんないんだけど、
ログイン回数が異常に至高してるとかは怪しい判定をした方がいいよねとか、
あとJ4プラスで擬応性の可能性もあるんで、
それだけでブロックするっていうよりかはそれとアクセスなり挙動振る舞いみたいなのを見て、
ブロックするのか警告を止めるのかみたいな部分を丁寧にやっていかないと結構厳しいよねって話が書いてある。
あとは知らなかった情報としては、
今あるものは本当にプロキシーサーバーをあらゆる感染させて、
もしくは暗黙にユーザーの同意を勝手にやってるみたいなのが大半なんですけど、
単純にプロキシーサーバーをタッチする、使えるっていう風にしてるだけなんだけど、
モジュール型って呼ばれる方式が流行るかもって話が書いてあって、
これ自体は何かっていうと、
レジェンダー化したプロキシーって結構いろんなおそらく用途があって、
DDoS攻撃もそうだし、マルウェア配るとかもそうだし、
あとはクローリングとかにも多分使われてるんだけど、
そういうユースケースに特化したものをプロキシーサーバーじゃなくて、
この記事ではモジュールって呼ぶんだけど、特化したサフトウェアを巻いておいて、
それ用のサービスを提供するみたいなのが流行りそうっていう話もちょっと書いてあったって感じかな。
レジェンダー社プロキシーの問題
実際にそういうのをやってるレジェンダー社プロキシーがあるらしくて、
どうなんでしょうっていうところですね。
こいつらも進化を続けつつみたいな感じかな。
はい、そんな感じ。
あとは、記事中で触れられてて、なるほどなと思ったのは、
プロキシーを巻いて配ってそれを運用してる人と、
プロキシーを実際に売ってる人が別であるっていうのが示唆されるような表現がどっかにあって、
そのプロキシーのインフラを複数の代理店っぽい、
レジェンダー社プロキシーの入り口のサービスは3個ぐらいあるんだけど、
裏側は全部一緒みたいなパターンとか結構あるらしくて、
その辺はちょっと分業が進んでたり、もしくは別のやつで見かけたのは、
ブランドロンダリングというか、表向きは普通の正規サービスっぽい、
いや、これ面白くて、なんか某じゃないかな、なんて名前だっけ、
ペンテストのホライディー本、すごい良い本があるんですけど、
それで読んだ時に、具体的にこういうレジェンダー社プロキシーがあるっていうのを
サービス名に書いてあって、アクセスしてみたんだけど、
アクセスするとマジで面白くて、
その従業員の顔とかも出てるし、社長の顔とかも出てるし、
でも本当、何だろう、もう表向きは健全なサースとして売ってるんですよ。
なので、堂々と、もう頬には、頬の網はかいくぐれちゃってるというか、
で、証拠も多分、一説によると、
表向きとしては、家庭ルーターのリソースを貸してくれたら、
月100円運営上げるよっていうので、IPを集めて、それを貸し出します。
表向きはそうなってるんだけど、実態としては結構、
NORAのソフトウェア、フリーウェア入れたら、利用規約の隅っこに、
しれっと同意しますっていうのが書いてあって、勝手にインストールされるとか、
マリアが実はそいつをプロキシーを配ってるとか、結構グレーな部分があるらしくて、
でもサイト見るとすごい堂々と書いてあって、
いやー、なんていうか、闇深いなっていうのと、
あとその、僕が読んだ本にも書いてあったんですけど、
やっぱりその、すぐに捜査機関とかからは目をつけられたりするんで、
ブランドロンダリングというか、会社畳んで別の、全く別会社を立てて、
で、サービス名も変わってってなってるんだけど、実態はメンバーも同じだし、やってることも一緒だし、
でも本人たちは別の会社だって主張してサービスを続けるとか、
あと利用規約がめちゃくちゃグレーというか厳禁がないとか、
その、利用責任はもう全部ユーザーに押し付ける形によく読むとなってるとか、
まあ結構、うん、闇が深いんですけど、うん。
個人的にはちょっと、いやー、まあ面白いって言ったら不謹慎なのかな、
でもなんかすごい、現実でこういうことあるんやなーって、不思議な気持ち。
なんか、深掘りしてる人たちがいるのも納得できるなと思うんだよな。
その、なんか、裏にどういうエコシステムがあって、
その、どういう経済圏があって、みたいな。
そうだねー、確かにねー。
もう、どっかでね、尻尾押さえないと、っていう部分もあるし。
うんうん。
なかなかね、そうだねー。
いや、ヨシマコメントしてくれてるけど、そうねー。
IPベースで何かを判定するは、きついだろうね。
本気でこれ使ってやられちゃうと多分、結構きついよなー。
うん。
まあ一方で多分こういうの使ってや、DDoS、7.4テラバイ…
4テラギガビ…ん?もう忘れちゃった。
うんうん。
先週読んだクラウドフレアとかはこれに頑張って対抗してると思うと、
頭が上がらんなという気持ちになりつつ。
うん。
まあでもこのレジェニシャブロキシって言葉知らない人とかは是非、
これ読めばまあ一旦、なんか理解した状態になるんで、
おすすめの、いい理由とのまとめ記事だなと思ったって感じですね。
はい、面白かった。
うん。
じゃあ次行きますか。
行きましょう。
AI機能とプライバシーの懸念
うーん、プライバシー系の記事かな。
Facebook's new AI tool asks to upload your photos for story ideas sparking privacy concerns.
ハッカーニュースの記事ですね。
何かっていうと、Facebookの新機能かな、
AI機能みたいなのが実装されたのかされるのかちょっと分からないですけど、
まあされたんだろうな。
されたときに、えっと、何でしょうね。
端的に言うと、写真をアップロードするときに、
AIが解析してこういうストーリーを上げませんかみたいなのをレコメンドしてくれるっていうのを、
AIを使って実装してるんだけど、
この記事で触れられてる内緒はちょっと問題になってるのは、
このレコメンドするときの学習データとして何を使ってるかっていう部分で、
何を使ってるかで言うと、
アップロードしてない端末上にある写真を全部見た上でレコメンドしてるっていう挙動をしてるっぽい。
なので、Facebookにアップロード済みの写真を見て、
新しいときはこういうストーリー作ればどうですかじゃなくて、
多分アプリの権限でデバイスの写真を読むっていう許可があると思うんですけど、
あれを許可求めて許可すると、それを見て提案するっていうふうな挙動をしてるっていうのが懸念されてるらしい。
メタは当然このストーリーの提案にしか使わないよっていう部分を明言はしてるんだけど、
データがどれぐらい保持されるかとか、
アクセス権がどう制御されるかみたいな部分は、
透明性があまりないかもっていう部分があるったりとか、
あとこれはもうデフォルトで入ってるんで、
オプターアウトしないと基本的には知らずに有効になってるって部分とかがあって、
結構どうなんでしょうみたいな話をする記事ですね。
なんかもはや信用できないよね。
そう、記事中でもあったけど、
AIの学習っていうところで言うとかなりブラックオークスというか、
メタほどの企業がやると言いたいわけじゃないけど、
どう使われててももう、
いくらでも言い訳できるっていうか。
そうそうそうそう。
オプターアウトしないとこの巨大になるのかなとか、
あとはやっぱその、ほんと、まあそうね。
結構メタ大…まあそうですね。
一方でいくらでも言い訳のできるレベルぐらいで済むんだったら、
もはやある程度使われてても特命性は担保されてんじゃないのっていう、
考え方も成立し得るのかな、どうなんだろうね。
なんかあとはそれ、改めて今サマリー読んでて思ったけど、
これが当たり前になってくる世界線もあり得るのかなっていうか。
メタはでかいから結構こうやって刺されてるだけで、
似たようなことやってるサービス絶対あると思ってて。
そうだね。
これがなんか、まあもう、
そのサービス使うってことはそのサービスに、
AIに全部食わせてるってことだよねっていうのが当たり前だって。
まあ別になんか食わせたからといって、
自分の顔写真が他の人の画面に出るわけじゃないから、
大丈夫でしょうみたいな価値観に行くのか、
まあいやいやダメでしょってなるのか。
まあ現状の世界のプライバシーに対する敏感さで言うとダメなんだろうけど、
なんか問い止められる並みなのかみたいな部分もあるし。
なんかここでは取り上げてなくて、
ただここに3週間ちょこちょこ記事が出てるの。
WhatsAppもこのAI機能周りで、
ローカルでしか動かない学習みたいなのを動かしてやるよみたいな。
でも通信はいついいんだよみたいな。
のでちょっと燃えてて、
アメリカ政府はそれで利用禁止を出すみたいな話とかだって結構、
サービスに対する目は厳しいなと思いつつ、
なんか今思うとこういうのがどんどん入っていく世界になるのが順当な気もしてきたな。
プライバシーを普段から意識している人はすぐにこれをなんて思うのかもしれないけど、
一般のユーザーがどこまで気にしてるかで言うとな。
うーん、まあ、いやまあそうね、
まあでも国とかにもよるしな正直なんか。
なんかTwitter、まあXか、Xとかはさ、
利用規約知るって変わって学習に使うみたいになったんじゃなかったっけ。
なんかあったね、なんかそんな話があったよね。
気がするな。
あれも一つの一種だよな。
あ、そうだね、設定変更で拒否できるけど、
デフォルトでオンになってることが多いから、
そうだよな、なんかまあみんな気づいてないけどどんどん溶け込んでるな。
ね。
Twitterめちゃくちゃ過ぎてなんかどうでもいいっていうか、あれですけど。
いやー。
はい、そんな記述でした。
はい、ありがとうございます。
話してて思ったけどなんかメタだけじゃないな。
まあね。
そういう気持ちになった。
うん。
はい。
次。
はい。
イエーラーSCTF2025公式ライトアップのウェブ編ですね。
まあちょっとなんか紹介にとどめるんだけど、
うん。
割となんか全体的にその問題が面白いなって思ったので持ってきてます。
面白かった。
面白かった。
なんかギリギリありそうというか。
そうだね、そうだね、わかる。
OIDC先生おじさんとか普通におっさんには吉の問題だったっぽくてなんか。
へー。
うん。
なるほどねって話で面白かった。
うん。
あとなんか最初の問題のなんかエスケープ関数の話とかはこうもはや自分でエスケープ関数書くとかもうないからさ、
なんか逆に新鮮で面白いなって思って。
なんか世の中が一周回った感をちょっと感じて面白かった。
あー、確かにね。
うん。
いやーでも現実あるんだろうなー。
コークPHPとかちょっと。
名前がね、いいよね。
うん。
わかる。
コークPHP。
コークPHPはさ、でもさ、なんか名前はオシャレだけど全然中身はなんかエグかったよね普通に確か。
中身は結構諦めちゃった。
これやばいよねマジで。
うん。
うん。
PHPって感じ。
うん。
古き、古き悪きPHPって感じ。
うんうん。
面白かったっす。
うん。
という記事でした。
ちょっと自分でもね、ちゃんと全部読めてないんだけどまだ。
うんうん。
なんかこうやって公式できちんとまとまってライトアップ出てくるのって、
なんか珍しいのかなとか思ったんだけど。
あーどうなんだろうね。
なんか最近は結構あるような気もするなー。
あーそうなんだ。
うん。
なんか。
たまーに気まぐれでセクコンCTF予選だけ。
まあ予選だけというか本生産ができないから勝ち進めないだけなんですけど。
そんな感じで思うんだけど。
こうライトアップ出たり出なかったりで悶々とするときがあるからね。
うんうん。
あとその公式が各出題者のブログで出されてるからあんままとまってない。
あー確かにね。まとめて出してくれるの確かにいいかもね。
うん。
うん。
助かるなーと。
確かに。
うん。
なんかそんな甘えずに自分で残業しろよってことなのかなって思いながら。
あはっ。
モンモンとしてたからいつも。
うん。
解けなくてすみませんって思って。
いいね。
なんかまあでも公式でまとめてくれるのはありがたいなって普通に思うし。
うんうん。
この。
そうですね。
うーん。
作文者がね、作者が公式ライトアップを書くとか普通によくあるけど確かに散らばってるっていう視点はなかったな。
うん。
なんかそう言われてみればそうだね。
うん。
そう。
まあ言うてそのちょっと頑張ってググったりすればまあいいんだけど。
うん。
いいんだけどまあね、ちょっとの差で。
うんうん。
いいな、いいなって気持ちになりましたって感じです。
ありがとうございます。
ぜひウィブ好きな人読んでほしい。
じゃあ次は、ハッカニストの記事か。
Entra IDの機能とリスク
えー、Be aware of the hidden risks in your internal environment っていう記事ですね。
これねー。
編集中になってる。
まあおもろかったんでちょっとおもろトピックとして紹介なんですけど、
マイクロソフトエントラのゲストユーザーって機能があるらしいんですけど、
このゲストユーザー機能に起因するセキュリティリスクの話をしてるって感じですね。
でこれだいぶ複雑なんですけど、
順応って説明するかつ、結構ざっくり説明するんで、
細かいところで間違ってる部分があったら申し訳ないんだけど、
まずその、Azureの世界において、
IAM的な概念当然あるじゃないですか、
このリソースでこの権限を持ってるとか、
プロジェクト前提でこの権限を持ってるっていうのがあるんですけど、
それと課金をする権限、課金者としての権限っていうのが、
どうやら別の概念として設計されてるっぽいっていう話がありますと。
で、なんでこの設計っていう前提もあるし、
かつ、こうなってるがゆえに、
例えばそのIAMを全部くまなくチェックして、
点検するみたいな方法とかだと、
その課金側の権限がどうなってるかっていうのは実は見落としやすいみたいな、
罠が一個あるよって話が前提としてあり、
で、次にAzure、これテナントじゃないっすね、
リソース、リソース、リソースであってると思うんだけど、
この分点に立ったときに、
Azure上に存在する特定のリソースないしはテナントに対して、
課金する権限、課金をできるかどうかの権限ですね。
なんか表現が難しいんだけど、
ビディング、プリーで、
めっちゃシンキングフェイスになってる。
表現が難しいな、でも多分そういうことだと思うんだけど、
その無料枠で使ってるものに対して、
クレカ登録して、
有料枠を使えるようにするみたいな手続きをするっていうのがステップがあると思うんだけど、
これをできるかどうかっていうのは、
そのリソースが所属するテナントのIAMで決まるんじゃなくて、
その操作をするアカウントが課金の権限を持ってるかどうかで決まるんですよ。
で、っていうところまでが全…。
で、かつ、
このアカウント自身が課金の権限を持ってるかどうかっていうのは何故かっていうと、
課金の権限はどのテナントでもいいんだけど、
自分が課金できるようなロールになってれば、
この権限を持ってることになる。
だからテナントいくつか同じアカウントに所属してても、
テナントとあるテナント、もしくは自分が作成した無料のテナントで、
例えば自分が管理者権限とか持ってたら当然課金するっていうのができるんで、
そこで課金者権限を持ってるよねってなると、
そのテナント以外でも課金権限を持ってるっていう状態になるっていう仕様があるらしい。
今日の頭だと無理かもしんない。
今日の頭だと無理かもしんないなぁ。
どう説明…でもこうとしか説明できないんで、
具体例を出すとよくて、
詰まるところの話に…
かつもう一個だけ前提、理解してない状態で申し訳ないけど、
一個だけ最後に話すと、
実際にこのリソース無料枠の状態だよねっていうところに対して、
これから登録して課金をすると、
その課金した対象に対して
IAM上で所有者ロールに昇格されるっていう仕様があるんですよ。
なんでこれが今言った前提全部組み合わせると、
実は穴があるよって話で、
詰まるところで言うと、
ステップバイステップで読むと、
まず一つは無料でグーグルクラウドとかAWSみたいに
そのテナントを作るっていうのは無料でできるじゃないですか。
無料枠の範囲で使う分には全然OKなんで、
無料でAzureテナント作ります。
そこで自分が当然そのテナントのオーナーになるんで、
課金を設定する権限を持ってるって状態になって、
ここで課金できますってアカウントを作る。
これをこのアカウントをゲストとして、
全然別のテナントに対して招待してもらう。
そうすると、
招待された側のテナント上では、
そのアカウントはゲストアカウントなんで、
本来は弱い権限しかないし、
自分を収容者にするみたいなこともできないんだけど、
でも別のテナントでは、
課金権限を持っていることになるんで、
その招待されたテナント上のリソースに対して、
課金を設定するっていうことができちゃう。
AzureのIAMと課金権限
なぜなら別のテナントで課金権を持っていることになってて、
それを利用すると、
招待された自分がゲストの状態のテナントで、
厳密に言うと任意じゃないんでしょうけど、
課金ができるようなリソースとかに対しては、
勝手に課金をして、
それによって自分を所有者ロールに昇格させるっていうのが、
できますっていう穴がありますっていう話が、
この記事に載ってる。
何が起こるかは分かった。
何が起こるかは分かったけど、
なぜそうなるかは全く分からなかった。
これはね、なんか。
え、待って待って。
ゲストアカウントとして招待してもらうと、
なんで自分のアカウントが、
課金の権限が設定されるアカウントになるの?
課金、ゲストアカウントとして招待される前から、
課金権限を持ってるかどうかは、
自分が所属する全てのテナントにおいて、
一つでも課金する権限を持ってるテナントがあったら、
もうそのアカウントは課金できることになっちゃう。
なるほどね。
で、課金できるアカウントイコール、
オーナー権限の所有者ロールになるっていう話になる?
課金を走らせると自分が所有者に昇格される。
元の所有者はどうなるの?
元の所有者は、まあ、
所有者一人とかじゃない。
Googleクラウドで言って、
このロールズオーナーのアカウントに、
自分が昇格されるっていう、
ただそれだけだよね。
そういうイメージだろう。
乗っ取れちゃうとかじゃなくて。
そうだね。
既存のやつを上書きするわけではないと。
うんうん。
そう、なんで、
実際の脅威で言うと、
まずゲストアカウントとして招待されないといけないから、
狙ったテナントでこれをやるっていうのは多分できないんだけど、
記事で振られてるのは、
ゲストだから安心っていう感じで、
運用したらあかんよねって話と、
あとはゲストアカウントが課金するのを防ぐっていうポリシーがあるらしいから、
これをちゃんと有効化すれば、
原理上防げますよって話があって、
なんでこれをやればいいだけではあるんだけど、
とはいえこれちょっと、
さすがに罠すぎないかと思ってるね。
この仕様は。
なんか笑っちゃったなっていう。
いやーこれすごいね。
なんかどういう、
なんかどういう考え方に基づいて。
うーん、そう。
なんか、
まあその、
作る側の立場になったらすごい、
まあパブリッククラブの権限設計なんて死ぬほどむずいんだろうなって思うけど、
思うけど、
とはいえちょっと、
難しいなあ。
知らんすぎるなあって思って。
びっくりしたっすね。
これはやばいね。
そうすると。
いやー、
なんか、
でもいい?
なんか、
Googleクラウドにもさ、
こういうわけわからなかったりするのかな。
確かにね。
知らないだけであんのかな。
うーん。
でもゲストアカウントって概念がさ、
ないね。
うーん、ないというか。
でもそれで言うと別になんか、
特定のオーガニゼーションに属してない、
その、
特定のGoogleワークスペースに属してない、
あの、アカウントに、
あの、
IAMロールフルとかできるじゃないね。
できるね。
でもなんか正義、
その、
あーでもIAM自分の正義としてはさ、
その、
あれじゃんね、
Googleワークスペースと切り離された世界線にはなってるから、
そうだね。
うーん。
だからゲストって概念っていうよりかは、
あかん権限を、
まあそれでもGoogleクラウドに課金の権限があるかどうかは、
よくわからないかな。
確かに。
でもさ、ビリーングビューは確かにあると思うんだよな。
うーん。
でも課金の権限というのがなんか、
何なのか結局よくわかってないわ、
それで言うと。
いやそれは、
どうもね、
その、
もときちをなんか必死に読んで、
うん。
なんかその課金の権限って表現したんだけど、
うん。
その、
なんて表現するのが正しいんだろうな。
その、
あ、
エントラディレクトリーロールか。
マイクロソフトの課金権限っていうのが、
うん。
あ、違うな。
Entra IDの基本理解
エントラディレクトリー。
そうだからね、
エントラの概念がすごい出てきてわかんないんだよな。
うーん。
多分、
ちゃんと理解しようと思ったら触るべきなんだけど。
いやー。
エントラ1個を契約する?
ははは。
いや全然ありな気がする。
これエントラだけなんだよね、
Azureじゃないの?
あ、
え、
Azureっていうのは、
Azureの話なの?
エントラの話なの?
あのー、
あ、でもエントラID、
エントラIDの話か。
Azureは関係ないか。
でもね、
Azure Rバックロールっていう表現は出てくるんだよね。
あー。
エントラID。
うーん。
エントラIDもさ、
微妙にAzureに組み込まれてたりしない?
そんなことない?
わかんない、
わかんないかな。
わからんけど、
でもエントラとしか書いてないから、
このエントラIDですらなくって、
その、
エントラファミリーだからさ。
あー、なるほどね。
そうそうそう。
エントラ…
エントラ3ってことがあるんだよ。
エントラ?
うん。
はいはいはい。
エントラディレクトリでなんか…
おい、だめだ。
何もわかんねえ。
何もわかんねえ。
誰か、誰か、
解説してくれ。
エントラ博士を呼びたいな。
ちょっと説明間違ってたら申し訳ないけど、
まあでも、
うーん、
何にせよ、
ちょっとワンパイ気がする。
なんか、
そうだね、
ラジオルテナントの話は出てきてるから、
うん。
だからその辺のインテグレーションに罠があるのかな、
もしかしたら。
うん。
だから、
あれなんじゃないかな、
なんかGoogleワークスペースとGoogleクラウドで、
Googleワークスペース側で課金権限を持ってると、
Googleクラウド側で課金ができちゃうみたいな、
そういう話なのかな。
だからなんかそれで言うと、
なんかGoogleも知らないだけあんのかな。
なんか、
細かいところで言うとさ、
GoogleグループとかってGoogleクラウドからも、
Googleワークスペースからもいじれるんですよ。
いじれる項目が違ったりするんだけど。
へー。
実は。
知らん。
それは罠で、
SRチームがトラフォーム化で一回ちょっと苦しんでたんだけど、
そう。
そういう部分のギャップみたいなのはもしかしたらあるのかもな。
あるかもしれない。
確かにね、
なんか、
あー確かにね、
ありそうだな、
なんか、
あー。
あー、
ホームテナントかフェデレーション系ユデッキテナントにアクセスします。
うん。
確かになんか、
ガス周りとか怪しそうな気がしてきたな、
それで言うと。
ガス怪しいなー。
ガス、
にょきっと入るもんね。
うーん、
超怪しい気がしてきた。
あれ、
観察陸上であんな見え方すんの、
なんか、
知らなかったわ、
普通に。
あー、
そうね。
Googleクラウドもしれっと入るからね。
うん。
みなさんがガスをね、
ボコボコ立ち上げる。
そうそうそう。
ゴミストロジェクトが無限に立ち上がる。
あー、
あれびっくりした。
CSPMがわけわからんことになる。
そういうなんか、
それで言うとAWSはなんか、
次になるやつがないかなーし、
そういうギャッパないのかな。
わからん。
わからんけど。
Amazonのアカウントが死ぬとか。
絶対ない。
めっちゃおもろいね。
うん。
Amazonなんかあったら死ぬくらいになる。
信頼された子は死ぬくらいになる。
うん。
Kindle、
Kindleとか消えるのちょっと勘弁してほしいけどね。
そうだね。
さすがに勘弁してほしいね、
Kindle。
うん。
まあちょっと、
すごい申し訳ないことに、
自分がAzureを仕事で使ってないし、
プライベートも使ってないから、
ちょっと他人事みたいな感じで、
面白がって読んじゃったけど、
その、
当事者の方がいたら、
ぜひ、
検証してみてください、
これは。
うん。
まあポリシー有効にするだけだから、
まあ、
対策はシンプルであると思う。
うんうんうん。
はい。
そんな感じの記事でした。
はい。
アテステーションチェックの概念
じゃあ、
次は、
リタブの記事で、
おっ。
これと、
チェンジログブログかな。
Enforced Admission Policies with Artifacts Attestations in
Quarantine Tests Using OPA Gatekeeper
これ、
オーパーなのか、
OPAなのか、
結局わからなかった。
ちょっと、
読み方。
今、
聞こうと思った。
Open Policy Agent
あ、
オーパー。
オーパーだよね。
ああ、
やっぱりね、
そう。
どうしてもレゴをさ、
リゴって読んじゃうんだけど、
なんか、
怖いんだよなあ。
確かにレゴって読んだ。
うーん、
はい。
そう、これ、
めっちゃ短いなこれ。
記事だよね。
そう、チェンジログだからすごい短いんですけど、
あのね、
その、
これの実装のプロバイダーのリードミーが
分かりやすくて、
画像をパッと引っ張ったんだけど、
つまりこれその、
まずなんかギタバアテステーションズとか
何かって話をすると、
はい。
多分この、
ここでも紹介したことあるんで復習なんですけど、
多分ギタバアクションズとかで、
その何か成果物をビルドするときに
署名できるって話。
で、
その署名の中の情報で、
あったね。
例えばその、
このリポジトリのこのブランチで、
このワークフロー、
この名前のワークフローで、
このタイミングでビルドしたみたいな、
メタ情報がめっちゃつけられる。
で、それを、
例えばGHコマンドで解くときに
検証できるっていう仕組み。
だからなんかその、
うーん、
いろんな保証が、
そのアテステーションで担保されるみたいな、
うーん、
話なんですけど、
えっとこれは、
えっとその、
アテステーションチェックを、
えっと、
うーん、
クマエンテスの、
これなあ、
ちょっとクマエンテス力が低くて、
表現間違ったら申し訳ないですけど、
うーん、
まあでもオーパーゲートキーパーってやつがあるのかな、
うーん、
そいつから検証できるように、
うーん、
うーん、
するプロバイダーをリリースしたって話ですね。
なるほどね。
なんで詰まるところ何ができるかっていうと、
えっとクマエンテスの世界で、
えっとレゴで書いたポリシーで、
アテステーションチェック、
うーん、
で、
アテステーションチェックを、
できるって感じのイメージだと思う。
うーん、
なんで?
はいー。
なんか、
いいね。
うーん、
こういうことできるんじゃないかなと思ってんのはさ、
このPodで使うイメージが、
このリポジトリのこのブランチで、
作られたものっていうのを、
そのレゴで書いておいて、
それがプロバイダーで保証されるみたいなのが、
できるんじゃないかな。
うーん、
なんだろうな、
うーん、
うん、
うん、
うん、
うん、
うん、
うん、
うん、
うん、
うん、
うん、
うん、
うん、
うん、
ううん、
うん、
ううん。
どっかのタイミングで、
イメージが改ざんされるのを防ぐとかはできる気がしてて。
うーん、
なるほどねー、
さ、
この辺の仕組みさ、
ちょっと勉強せんとなぁと思ってて、
ウフフ、
なんか、
クラウドランってこの辺のサポートどうなんだろうね?
何の話かというと、
なんか、
ああー、
まあほぼ仕事の話になっちゃうんだけど、
おっとSTSのさ。
あはは、
いいよ?
あのー、
イメージを、
Github Actionsで開発して、
アーティファクトリジス タブリジス っていうのをやるときに イメージ
に署名はつけたいんだけど 何か 署名検証の仕組みとかどうなって
るのかなって ちょっと気になってて
おだしょー どうなるんだろうね
ちなみに本家の チェーンガード の本家だと コサイン COサインっていう
あれを使って署名してるんだよね くばね鉄の話は結構上がってくん
だけど クラウドランの話かな そもそも何か
おだしょー くばね鉄とクラウドラン では必要性が違う気がしてて
クラウドランの場合は デプロイ するタイミングでもデプロイする
ものが担保されるじゃん 何が言いたい かっていうと 例えば クラウドラン
デプロイをgcloudコマンドで叩く ときに その直前にデプロイしよう
としてるイメージを検証すれば やりたいことできるじゃないですか
そうね
おだしょー うん で その間で何か起きること
というか 余裕のことじゃないか 何か大丈夫か それで保証されるん
だけど くばね鉄の場合は 実際 にプルするイメージを
なるほどね
おだしょー プッシュして 例えば アーティファクト
レジストに置いてあるやつを引っ張 ってくるっていうフローになってる
やつで そうなると プッシュする タイミングで改ざんされてない
ものをプッシュしたっていうのは 保証されるんだけど アーティファクト
レジストが侵害されたとかっていう もしくはプルする先が書き換わ
っちゃったときに これがある と防げるっていう話は差分として
ありそうな気がする
なるほどね
おだしょー なんかライフサイクル が違うというか ライフサイクル
ではないのか
そうするとクラウドラン の そう だから割と賢った状況
でクラウドランっていうのを全然 使ってないから趣味でしか使って
ないんですよ 今まで 正しいデプロイ の仕方みたいな よう分からんの
よね
おだしょー 確かにね
クラウドビルドとデプロイメントの実践
なんかいつもクラウド ビルドとかで趣味だと 趣味のコード
だとクラウドビルドでポンポンポン ってやっちゃうんだけど 今回の
Octane Stasisだと アプリは普通に チェーンガードが提供してるリポジトリ
をチェックアウトしてきて それを ビルドして パブリッシュしてっていう
のはできるんだけど アーティファクト レジストに置いてるんだよね 1回
なので 流れとしては クラウドラン の GitHub Actionsのクラウドランの
ワークフローを使って イメージ のパスを指定してあげてっていう
形になる
おだしょー なるほどね 確かに 今 クラウドランデプロイの公式
アクション見てるけど フックの 処理を書くみたいな仕組みはなさ
そう
そうなんだよ どうするん だろうなと思って これ 署名つける
のはいいけど どうするんだろう なって思いながら見てたんだけど
おだしょー そうだね だから イメージ はもうでもそうかして
Require source metadata unless preventing メタデータはsource ソースはfast
source to deploy メタデータは yammer-service-execution-for-cloud-data-and-service
確かに 自前で手前でチェックする 以外ないかもね
そうすると極端な話 その 手前でチェックしたタイミング
と実際にデプロイするタイミング の間にはラグが存在するわけじゃん
おだしょー そうだね 間違いない なるほどね デプロイフロムソース
コードとかだと多分不便なもんな その場でビルド走るとってなっちゃ
うし
デプロイフロムソース コードはでもいいっちゃいいけど
おだしょー 一応オプションとして はないですよね
やってやれんことはない な どうすんのか言ったらな
おだしょー アーマートバッドレジストリー とかってイミュータブルなことが
保証できるような仕組みってあん のかな
確かにね
おだしょー イミュータブルでバージョン ちゃんと指定して署名してプッシュ
すれば手前で引っ張ってきて署名 検証します イミュータブルだから
もう上書きされてない前提でそれを 公式テーブルに加わすみたいな
ことはできそうな気がする イミュータブルタグズっていうの
がアーティファクトレジストの場合 はあるね そうこれ最近リリース
された気がする 最近じゃない 2年前だ 最近の感覚がジジイだな
こういうの組み合わせてリスク 低減はできそうな気がするな
これイミュータブルこれやんない 理由ないんだようちやってんの
かなっていうことで Google App Engine とかだとデプロイ前のコマンド
みたいなのを書けるからあれは 別にイメージじゃないしちょっと
違うか 確かにでも面白いよそういう その辺のプラクティスクラウド
欄の部分って書いてあったりしない のかな
わからんなんかそこまで 細かく掘り切れてないんだけど
まあどうせ社内に詳しい人いる から後で聞きゃいいや
そうなんか一回社内の 輪読会でそのKubernetesのGKEのドキュメント
を読むっていうGKEのドキュメント のうちセキュリティプラクティス
みたいなセクションがあってそれ 読むっていうのやったんだけど
ねすごいよかったですよくっそ しんどかったけどでもクラウド
欄バージョンのそれがあるんだ ったらなんか今言ったようなこと
が書いてあるんじゃないかなって 期待できる気はするな
アーティファクトレジストリの運用方法
いやそう大体からして なんかそのレイテストタグを使わず
に吉野にこういい感じにやるの とかもなんかようわからんなー
と思いながらまだ調べてないんだ けど
まあレイテストはその上書き リクチャーからシンプルにリスク
を見たら知るんじゃないかな
そうするとさじゃあどの タグ指定すりゃええねんみたいな
なんかそのどこでどこで指定し とけばいいのかもなんか悩ましい
し
その辺はクラウド欄の 場合はどうか分かんないけどGKE
とかはKubernetesは結構いろいろプラクティス があると思うんですけど
そうそうKubernetesの場合 はさなんかいろいろあるよなと思
っててそのなんか実際にそのメルカリ とかで体験してたやり方とかも
あるわけで
そうだね
なんかマニフェスタ 側のあたりさなんかおはい
サイドカーコンテナを使用した
サービスのデプロイってやつかな ね
なんだそれおもろいな
なんだろうね
うん
うん
ああそっかサイドカー 最近になった
気がするな
そうだねサイドカー自体は
そうなんだね
うん
いやどうなんだろう
まあ分かんないっすね
うん
まあでも実際その直前に チェックすれば対何か95%ぐらいの
脅威は低減できるからそんなに みんな困ってないとかなのかな
ちょっと妄想で喋ってるんですけど
ね
うん
まあそうなの
すげえ全然関係ない話になった
上に普通に仕事の話を言ってた
いやでも面白かった
いい仕組み
確かに
そうそう
これ系おもろいよな何かその全然
関係ないんだけどあのコロナ コロナ禍末輝ちゃんの時に見た
手洗いのジョーク動画みたいなやつがあって
関係ないと思ってるかもしんないけど
言いたいことは伝わると信じて話すと
最初普通に手洗うじゃん
蛇口で手で蛇口をじゃってやって
水濡らして
手がサニタイズ
そっから手、石鹸で洗ってサニタイズされました
水で流します
蛇口また触っちゃった
蛇口また触っちゃった
蛇口次洗いますっていうのを繰り返していって
ひたすら全部洗うっていうのをやってて
どこまでいけばやれんねんみたいなのを表現した動画で
それをすごいふと思い出した
このイメージはどこまでいったら正しいと思った
そう考えると
下下手術のプロシーチャーみたいなのって
すげーなって思う
確かにね
無菌である
無菌、無菌?
無菌だよね基本的に
確かにね
あれが多分正解ではない
それで言うと
調べたことないんですけど後で調べる
確かにね
あとはなんかあの半導体工場のあるとかも
入室とかもそうなんですよね
確かに
服、なんか服の上にたぶん入ってきて
いくつか部屋通るみたいな
あとそれ系で言うとデータクリーンルームっていう概念があって
ほう
完全に無限に発散していくけど
データクリーンルームっていう概念があるんですよ
データクリーンルームって知らん
アドバータイジング系のなんか
あー、これもそうだね
Trezorのフィッシング攻撃
これもこれ系なの?
そうそうそう
おもろ
いやー、なるほど
はい
すげー脱線した
最初の話一ミリも関係ない方向に飛んだったけど
一発目からもう関係なかったもんな
ワクバネティスができるのは分かってよっていう話だからさ
つながってるから微妙に
細い
まさに今日この辺を調べてたんだよ
そのなんか
ワクバネティスができるのは分かったんだけどさっていう
ところをなんかちょろっと調べて終わってたから
急に続きが始まった
つなげていきましょう
最後っすか
はい、お願いします
うーん
まあ、はい
ちょっと読み方わかんないですけど
Trezorのサポートプラットフォームがフィッシング攻撃に悪用されていることが報告されています
っていう話で
これTrezor自体が何の企業かちょっと見てないんですけど
これ何かっていうと
めちゃくちゃ汎用性高いシナリオだなって思ったんで紹介したいと思ったんですけど
どのサービスもサポートホームってあるじゃないですか
いろんな形のやつがあると思うんですけど
そのサポートホームを使ってるっていう話で
このTrezorのサポートホームの仕様は
多分返信先アドレスとして任意のアドレスを入力できる欄があるんですよね
それってよく見かける作りのフォームだと思うんですけど
そこに任意のアドレスを入れて
お問い合わせを送ると自動返信みたいな形で
そのアドレスに対して返信がされると
その返信の中に問い合わせ内容の本文が多分入るっていう状態になってて
これを利用してフィッシングが横行してるよって話ですね
多分文面的には暗号通過系なんだろうな
何が問題かっていうと
アドレス登録してできるのと
前に話した多分PayPalの住所変更悪用とか
Googleオース認証か何かの
App名かGoogleアプリ名
めっちゃ長い名前入れてみたいなやつだよね
そうそうそうそう
あれ系と似たやつなんだろうなって
思い出しながら聞いてたそれを
そうだよね まさにそれ系で
正規な正しい送信元の
なんだけど割と任意のカスタマイズしたURLを
本文を入れたフィッシングメールが作れちゃうようになってて
っていう話ですね
なるほどね
なんかめちゃくちゃ賢いし
めっちゃ汎用性高いなって思ったっていう
サービス性質自体では結構全然これ以外も狙えちゃうよな
だから限りなくなんか出てくるね
それと言うと可能性としては
大半こういう仕様になってるじゃん多分
アドレス入れると
ミーログインで問い合わせできるところは
大体そうだと思うんで
そうだよね
だから多分認識できるとしたら
メールのフォーマットというか
作り的にカスタマイズの余地をなくすとか
URL埋め込めなくするとかもあるのかもしれないけど
メールにユーザーコンテンツ入れないが最適化やと思う
サポートチケット切りました
サポートの対応はここのURLで確認できます
以上
確かにねそれでいいな
そうしましょう
そうですね
でもこれPayPal Google思い出す
このシリーズに名前つけたいのは何だろう
賢いな
よく考えるよな
この辺の使い方で何か
見つけられそうな気がする
例えば
パッと出てこねえよ
何だろう
メール送る系
でもなんかすごい
もっと
DNSアンプとかDNSリフレクションって呼ばれてるような
DOSの手法があるんだけど
DNSリフレクションは分かる
これとかはものすごく一般化したら
割と同じ思考が行き着いてるよね
この部分
確かにね第三者を介して
その上で本文がいろいろできるじゃん
ここっていうのが今悪用されてるわけだから
なんかあるかな
結構いろいろあるはするけど
Entra IDの理解
通じる概念というか考え方みたいな
でもちょっと思いつかないから
メールボックス見てたら思いつくかもしれない
頭いいフィッシングだからソフィスティケテッドフィッシングかなと思ったけど
でもそれが今のフィッシングの語源と言われていたりするから
さらに頭のいいフィッシングを今後人類は何と呼ぶことになるのかな
みたいなことを今考えてた
なるほどね
GitHubとかなのかな
GitHubとか通知めっちゃ届くけど
はいその記述でした
結構なんかチャット対応とかに切り替えてるところも多いからさ
それでもいっぱい残るからな
これ自体は
問い合わせの動線を超深いところに置いとく
ダークパターン見があるんだよな
攻撃者を見つけられないぐらい深いところに置いとく
攻撃者見つけられなかったら一般のやつは絶対無理だ
いやー
メール無くなる無くなるって
令和に無くなるのに30年ぐらいは残ってるんじゃないかな
意外と無くならないよね
意外と無くならないね
しかも見てないところに大事な連絡が入ってきたりするから
なんかそうだね
でもあれかな
メールを自分で読まない時代が来て安全性が高まるみたいな
世界観があり得るんだよね
いやでもプロンプトインジェクションされるんでしょ今度
いやーだりーなまじで
ほんともう勘弁して
困っちゃいますね
大丈夫
メールは自分で見ないといけない
AIでは大体できないかもしれない
いやー
みんな気をつけてね
いやー
過去一雑な回だったな
序盤の雑コメント4連続ぐらいがもう今日なの
今日を彩る
今日を象徴する
雑さだったな
でも記事は真面目に読んだよ面白かったな
今日結構好きだったな
偉いでしょ
MCP
42回でしょ
45、6回ぐらいを目指して実装しようかな
でもなんかサンプルを実装する分には瞬殺だよ
そうか
サンプルを実装しようってなると
そこまで入れるとちょっとめんどくさいな
サンプルの瞬殺な雰囲気は
どっちかっていうと
オースで動くやつの
リクエストレスポンスを観察するっていうのをやればいいと思うな
でもプラクシー通さないといけないんだな
めんどくさいな
公式サンパル
公式サンパル
タイプスクリプトの実装
公式サンプル出てないのかな
公式のSDKがあんのよ
タイプスクリプトとかだったらなんか
この辺
でもオース書いてあんじゃん
書いてある
オースで検索すると
タイプスクリプトSDKの
オースでそこ検索すると
本当だ
これがそのまま使えんのかとかは
ちょっとなんもわかんないけど
でもオースエクスターナルとかはなんかあれだな
なんかしらプロバイダーは良い
でも適当にオースアプリ作って
やればいいな
こうやって欲が出て結局実装できる
とりあえず何にもせんでいいから
動かすところをやればいいと思う
全ての煩悩を潰して
ついに公式のOSDKが出たんで
まだなんかちょっと変わるっぽいけど
公式と言いつつまだ安定してない
色めきだってるのをどっかで見た
水谷さんも置き換えた
みんなタイプスクリプト書けばいいのに
でもなんか
Goに関しては結構
ローカル向いてそうな気はしたけどな
確かにポータビリティ高いな
ポータビリティ高いから
ローカルのMCPサーバーに向いてるなと思ったのと
ただJavaScriptとかタイプスクリプトは
NPX経由で
NPMランとかでそのまま呼び出せたりするから
プロジェクト単位で
MCPサーバー置いておきたいみたいな時とかに
めちゃくちゃ便利なはずで
確かに確かに
一丁一単やね
ポータビリティの高さでいくと
Goは結構圧倒的な気がする
頑張ります
最初は元気な姿でお会いしたいですね
どうかな
あんま元気じゃないと
弊社は心配されちゃうから頑張る
違うんだよ日中頑張ってんだよ
逆にね
日中頑張ってるかも夜寝るかも
それはあるな
元気なんだよ
日中頑張った結果
眠くなってるだけ
ぐっすり寝て明日も元気に頑張りましょう
頑張りましょう
今日はこんな感じで
皆さん次回もお楽しみにしてください
おやすみなさい
