00:00
こんばんは、Replay.fm第23回です。
こんばんは。
こんばんは。
はい。
こんばんは。
こんばんは。
こんばんは多いよな。
なんで?
音源編集したときに毎回思うんだけど。
どういうこと?回数が往復のあれだってこと?
あ、そうそうそうそう。
やり出しのね、こんばんは、絶対ミニマム2回な気がする。
そんなことないよ。
意味わかんないでしょ。
一回で。
じゃあ聞き直してみろよ。
絶対これ初めてだから、2回。
いやー、それはないわ。
それはちょっと、それは漫才すぎるな。
絶対これ初めて。間違いね。
いやー、誰かに後でいつか数えてもらおう。
なんか某ポッドキャストで、200回とかやってるようなやつで、似たような多分、この人がこれよく言うみたいなやつを200回全部聞いて数えましたみたいなお便りいただきましたっていうのを聞いたことがある。
それぐらいの愛と思ってもらえる。
でも結構すごい、すごいというかね、しょうもないんだけど。
そういう押され方もあるのかと思いながら聞きました。
20、23か。結構多いな。頑張ってるけど。
まあまあまあまあ。
いやー、ぬるっとやりましょう。
今日も、まあそこそこかな。代償様々ですけれども。
上からいきますか。
はい。
はい。
はい。
僕読むか。
今日はソーター多めだと思う。ごめん、詐欺ちった。
マジで?じゃあ大丈夫です。頑張ります。
PortSweegarのAI機能
Why it's time for AppSec to imbalance AI? How PortSweegar is leading the charge?
なんか長尺すぎてわかんない。
PortSweegarっていう企業名なのか?
バープを作ってる会社?
これはバープスイートを作ってるところ。
OKです。PortSweegarのブログですね。
記事の内容としては、
バープスイートで
AIを組み込んだ機能をリリースするよって話なんですけど、
ぜひ読んでみてほしいなと思うんですけど、面白いのが、
すごい慎重なスタンスで、きちんと価値のある形で
AIを組み込みましたよっていうのをすごく丁寧に記載していて、
他すごいわかるなって思った一文がどっかにあったんですけど、
追加でお金をもらうためにアップセルでAI機能を組み込むみたいな、
そういうわけでは全くなくて、
従来、本当にやりたいこと。
この記事の文脈は結構ペンテストの文脈で語られてる切り口が多いんですけど、
ペンテストにおいてAIが役立てられる場所がどこなんだって話と、
そこに対してどういうふうに援助できるのかっていう視点で、
本質的な機能を作ったよっていう話をしていて、
なんで、どっかで書いてあったのが、
今回の機能を叱り、
AI、要するにSSLMの文脈だと思うんですけど、
っていうのは、少なくとも現時点では別にペンテスト、
人間がやる何かの作業を置き換えることはできなくて、
ただ人間がやる作業を効率化するっていう文脈において、
かなり価値があるっていうことを信じて、
これをリリースしてますみたいなことを書いてくれてるって感じです。
ただ個人的にそうだよねってちょっと思ったのは、
やっぱりAIを導入していくっていう部分にあって、
お呼び越しになるというか、
リスクみたいなものも当然あるから、
そういうものも考えて作ってるし、
怖いよねって話がありつつ、
攻撃者がそれをリスクアセスメント待ってくれるのかというと、
全くそうではないので、
ホワイトハッカーの立場としても、
スピード感を持ってどういう形で守りに行かせるのかっていうのは、
きちんと考えなきゃいけないよねっていうところが、
だいぶ威厄したんですけど、
ボカソを捉えたっていう部分があって、
その通りだよね。
そう考えると不公平な話だよね。
いやー、ほんとに。
攻撃に使う側はさ、別に何も気にせんで使えるのに。
リスクないよね。
守る側はなんか結構慎重に入れなきゃいけないみたいな、
世界ってなんかどうなのって思っちゃうし。
もうずっとね、
もうこの構造はなんかもう変わんないんだろうなっていう気がするよね。
その、なんていうか、
結構ね。
確かに、確かに、それもあるね。
うん。
じゃあこれなんか、
特定のなんか機能が出るよみたいな話じゃなかったんだ。
うーん、
なんかね、
うーん、
そうだね、あの、
いや、ちょっと、
なんか機能紹介みたいなのが動画でされてて見ようと思ったんだけど、
僕はバープツイートを使いこなすなすぎてピンとこなかったんで、
ちょっと理解諦めたんだけど、
でもその、なんだろうな、
あの、
例えば、AIタブみたいなのがバンって出て、
そこでいろんな新しいことができるっていうよりかは、
既存の機能で、
動画でチラッと見たのはそのAIみたいなチェックボックスがあって、
そこをクリックすると、
一部の機能がAIによって演習されて動くよみたいな。
うーん。
だからなんか多分いろんな場所に多分、
使える形で組み込まれてるみたいな感じ、
なんじゃないかな。
で、あとはなんかそうだ、記事中で言ってたのは、
オプトインで使うようにしたよっていうのを結構強調していて、
いつの間にか動かさないんで安心してねっていうことも書いてあったかな。
だから逆に言うと使いたい人は多分、
きちんとドキュメントとかを読んで有効化する必要がある。
ちなみに多分、
これ自体は有料プランじゃないと使えないはずなんで、
そうですね。
少なくとも僕は試すことができないんですよね。
でも動画見れば。
コミュニティエディションは商用利用がそもそもNGなので、
あー、なるほど。
あー、そういうことね。
うん。
どっちにしろね。
仕事で試したいっていう人は結構資金が高いのかなって。
うん、そうだね。
ちゃんと正規のプロセスを持ってやってくださいって感じですね。
うん。
でもね。
高えんだよな。
そうだね。
まじで。
さあ、円安が。
いやー。
安定しすぎる。
今いくらぐらいなんだろうね。
449ドルでしょ。
まあ4万ぐらいで買えたんだよね、昔はね。
買い切りで?
買い切りじゃないけど、年間で。
年間。
まあまあまあまあ。
今6万8千円とかだから。
1ラインセンス作ったよね。
そうそうそう。
ちょっと高いんだよね。
ちょっと重いね。
うん。
いや、うちぐらいの規模だったら、
なんか予算を下ろせそうだなって。
まあちょっと使えるか。
そのコスパを使えるかどうか分かんないけど。
なるほど。
なんかでもカイドとかあるし、
あとZアタックプロキシーとかもあるので、
なんかその、
まああえてバープスイートじゃなくても
みたいなのは思わんでもないけど。
なるほど。
どっちも分からなかった。
Zアタック?
うん。
あのOWASP ZAPって呼ばれてたやつ。
ああ、はいはいはいはい。
名前変わったんだ。
OWASPがね、多分取れたんじゃなかった?
ZAPになってる。
ああ、ZAPアタックプロキシー。
ZAPになったか。
ああ、はいはいはい。
ああ、へえ。
これってなんかダスト的なもんだと思ってたけど。
ああ、また別のやつか。
なるほど。
カイド。
うん、ダスト的なやつもね、なんか入ってんだよね。
だからそれはちょっと触ってみたいなと思ってんだけど。
うんうん。
ちょっとなんか機器を呼ぶところによると、
そうそうそう。
保険値が多くてあんま使えなくて。
ああ、そうなんだ。
うーん。
あの。
なんかね、オートメーションは触れてんじゃん。
うんうん。
そんなダメなんだ。
ダメなんだっていうか。
あの。
難しいんだ。
また機器なんで。
ああ。
あんま間に受けないでほしいですけど。
僕は試したわけじゃないんで。
まあダストツールは正直それ付き物だから。
そうだね。
うん。
それは本当にそう。
うん。
へえ、カイドこれか。
へえ。
いやあ、なんかこういうの、なんか10日ぐらい山こもりしてやりたいな。
山の上の寺とかにこうやって。
ああ、でもそういう類のものじゃないな。
だから言うと、なんかそのさあ、なんかフロントエンドの開発者がChromeデブツールを使うのと一緒だと思う。
ああ、分かりやすい。
分かりやすい。
うん。
なるほどね。
うん。
なるほど。
確かにね。
確かにそれはそういうもんではないね確かに。
うん。
なるほど。
理解です。
だからカイドは年間200ドルだから結構安いですね。
うん。
ザップに至ってはただだもんね。
ザップはそうだね。
うん。
安いです。
オートメーションは知らんかったな。
触ってみようか。
はい、まあそんな記事でした。
使える方はぜひ使ってみてください。
はい。
じゃあ次は、まあ僕読むか。
セキュリティーインシデントと倫理観
CISO vs KISO セキュリティーインシデントの解決には倫理観が必要。
フリーCISO 重岩裕樹さん。
さん。
はい。
記事のタイトルに入ってないですけどつけました。
セキュリティーの記事ですね。
なんか読んでる途中気づいたけど、
去年のセキュリティデイズコンビットの発表の記事で、
なんかこの記事を出す頃にはもう多分今年のセキュリティデイズがあるらしいから、
なんか遅くてごめんなさいみたいなことがすごいまつりに書いてあったんですけど、
まあなんかそのなんでしょうね、
すごくざっくりさまってしまうと、
杉浦さんフリーでCISOとかPISOと立ち上げた第一者っていう認識をしてるんですけど、
その辺の背景の話とか、
またタイトル、記事のタイトルにあるところで言うところの、
倫理観みたいなところは、
いろんなことにセキュリティチームとして対応していく中で、
倫理観みたいなものも系と握って大事にしていかなきゃいけないよねって話をしてるっていうところ。
発表の内容のレポートみたいな感じですね。
で、なんかわかりやすい切り口として、
例えばランサムウェアに感染しちゃって暗号化されちゃいましたで復旧もできません。
ミノシロ金を払ってくださいと迫られたみたいな場面がもし仮にあったとして、
じゃあこれ払うべきかどうかっていうところで言うと、
教科書というか、別に法律はないんだけど、教科書とかプラクティスというか、
業界の雰囲気としては払ったとて帰ってくる証はどこにもない、
なぜなら相手は犯罪者だよねとか、
ミノシロ金を払ってしまうことで犯罪コミュニティにある意味加担してしまうことになるよねとか、
そういう側面から推奨されるものでは決してないだろうし、
あとは経営参照かな、国としても払わないでくださいみたいなことが言われてるんだけど、
じゃあ一方で払ってデータ戻さないともう会社潰れるかもしれませんみたいなことを迫られたときに、
本当に払わないと決断ができるんですかっていうような問い、すごい難しい問いみたいなところに。
どう転んでもリスキーだよねっていう話があってっていうところだよね。
倫理観と判断軸
そういうところに対して何か言って必要な判断軸に必要な一つの要素が倫理観なんじゃないかみたいなところが一つ例として挙げられてて、
確かにっていうところもありつつっていうところもですね。
ここの部分ですね。
何かその、何でしょうね、倫理観に取り組むためにこんな画期的なことをやってますみたいな、
そういう話とかではないんだけど、トピックとしていくかというところですね。
詳しくは読んでください。
あとは個人的にちょっとこういうのいいよなって思って、ちょっと本題とは逸れるかもしれないけど、
スライドのキャプチャーみたいなのがあって、セキュリティ対策の検討で脅威とリスクと、
そのリスクに対するストーリーと、それに対する対策みたいな図が書いてあって、
画像なんでちょっと言葉で説明するの難しいんですけど、
こういう解像度でこういうものを作れるようになりたいなってすごい地味に思ったというか、個人的には。
はい。
僕はこういうセキュリティにおいて、経営とか会社と対話するためのこういうアセットを作るのにすごく苦手意識があるというか。
いやー、でも苦手な先入観があるだけだと思うんだよな。
なんか、いや、苦手っちゅうか、表現難しいけど。
いや、素振りが足りてないだけだと思うよ。めちゃくちゃドライに突き放したこと言うけど。
いや、それはでもそう。だからなんかもっと正しい表現は、同じものを作るのに多分10倍の時間が今はかかる。
だから経験を進んでいったり、補強していくことでよくなってくると思うんだけど、
いや、なんかね、この感覚ね、伝えたい。
いや、なんかね、迷子になってる感覚があるんですよ、こういうのを作り始めると。
なんでなんだろうな。
いや、わかんない。たぶん、私もそういう時代があったと思うし、わかんないんだよな。
わかんないんだよなって、じゃあ別に、私がそんな上手にできるかって言うと、また別の話だけど、なんか。
なんか超ざっくり言うと、当たりをつける能力がまだ低いんだろうなって思ってるというか、
セキュリティっていう、なんかとても広い海の中で、1回100までできる企業は存在しないというか、不可能だから不可能だよねってなった時に、
じゃあどういう切り口で、この辺まずはやりましょうみたいな、なんか当たりをつけていく作業が必要なんじゃないかなと思っていて、
セキュリティ対策の必要性
なんかそれがうまくできないのかなっていう気は、自分ではちょっと思ってる。
でもそれってなんかCISコントロールとかさ、ICMSとかさ、なんかあるじゃん、その乗っかれるフレームワーク。
あー、そうね。
それをやれば完璧ですよっていう性質のものではないけれども、その当たりをつけるっていう意味だとさ、なんかそういう形で乗っかれるものが、まあ世の中大量にあふれてるわけで。
まあでも、それをじゃあなんか、わかんない、経営と対話する。
まあそれをかざすっていうの面白い人だし、それなんかその翻訳する作業が必要なんじゃないかなと思う。
翻訳する作業は必要だと思うよ。その自分の言葉で説明できますかっていう話だと思っていて、
なんかその、でも当たりをつけるっていうところは全然それに乗っかれると思うし、その上でじゃあなんていうか、
なぜそれが必要なのみたいなところは多分当たりがついた上だったら、なんか十分説明できるんじゃないかなって思ってしまうんだけどな。
まあでも素振りが足りないっていうのは多分一定事実としてあるんで、素振りしますって気持ちでは改めてなりました。
まあ、次回の意味もあるんだけれども、それでいくと。
私がじゃあ素振りが足りてるかっていうと、まあそんなことねえだろうなと。まだまだだとは思う。
これ座席に立てること自体が結構貴重だよね、なんかそもそもだけど。どうなってる?
いや、ていうかその、なんていうか、そんなことない。だって別になんか、別にセキュリティを業務としてやってますって人じゃなくても、これできるじゃん。
できるのか。
だって自分の会社のセキュリティについて考えてくださいっていうお題に対して、なんかこういうフレームワークがあってこれは使っていいですよって言われたら、当たりつけてやっていくことって多分できるじゃん。
まあ、そうね。そうだけど、その。
ソフトウェアエンジニアの役割
で、まあみんな何かしらのたぶん仕事をしていて、まあかなり多くの人がどこかしらの会社に雇われてるっていう状態なわけで、なんか。
まあ、座席に立つのが、立つ機会がそもそも貴重かというと、なんていうか、仕事としてこれやってくださいって言われる機会は確かに、まあ人によっては得がたいものかもしれないけど、
これを考えること自体はなんか。
まあまあ確かにね。
組織の誰であれできることであって。
なんかちょっとやっぱ特別視されすぎな、なんか感じがするんだよな。
セキュリティというもの自体が。
まあね、まあ再三話してることもあるよね、このときも。
なんかそんな、そんなんじゃないよって思うんだけど。
いやなんか、いや難しい。
なんか、そんなんじゃないよって言えるようになりたい。
なんかその、なんだろうな。
その、いや難しいっすよ。
まあ自分のパーソナリティもある気がするんだけどな。
なんかその、いや難しい。
みんな、みんなわかんないなりになんかやって進んでるんだよ。
まあまあまあ。
セキュリティやってる人たちも。
そうね。
で、なんかあの判断は間違ってたなみたいなのもやっぱりあって、
その、いろいろやっていく中で。
どうしてあそこでこういう動きができなかったのかなとか、
なんかそういうのもやっぱあるし、
なんか、そんな特別なものじゃないと思う。
言ってることもわかるし、でもなんかその、
自分の中にはまだ埋められてない溝があるなって思う。
なんかでもさ、
いやなんかその、
なんかあんまバイネームで出すのよくないかもしんないけど、
なんかユドウさんと昨日イベントで会って話しちゃうんだけど、
なんかユドウさんも、
なんか多分そういうこと思ってるんだよね。
なんかでもユドウさんはさ、
なんかまあ直接本人にも言ったけど、
なんかCISSPまで取ってるから、
もう振り切れてこっち側に入ってる人間のはずなのよ。
それでもそうっていうのはなぜなのかな。
その埋まらないと思うその溝は何なのかなって、
なんかちゃんと言語化したいなってちょっと思ってる。
ユドウさん呼ぶか。
ユドウさんと俺の悩みをヤギ足に聞いてもらう会をやりたい。
なんかね、
いやソフトエンジニア出身だからとかもあんのかな。
いややっぱそのソフトエンジニア時代、
ソフトエンジニアとして働いてきた期間が長いんで、
やっぱそのロジックの組み上げ方が、
そっちがもう意識的にベースになってると思っていて、
まあ別に、なんか難しいな、表現は難しいんだけど、
例えばバックエンドだったら、
分かんないけど、
その手の抜きどころが分かるというか、
なんかこういう要件でこういうシステム作りたい、
で、農機はこれぐらいですって言った時に、
その、なんだろうな、
なんか見るべきスコープがすごく、すごくちっちゃく思える。
セキュリティと比べると。
なんか、
まあデータ…
あ、ごめん、何言い方悪いけど、
事実小さいんじゃない?それって言うと。
うん、そう。
事実小さいんだと思うし、
でもそれがさ、めちゃくちゃ、
だからその、
なんていうか、
一周の粒の大きさがめちゃくちゃでかくなってった時に、
どうですかっていう話はあると思っていて、
うん。
例えばだけど、なんかグローバル展開するサービスを作ってください、
で、要件はこうですみたいなのが、
なんかボコボコボコ入ってきた時に、
多分なんか、
課題の大きさがやっぱ大きくなるっていうのは、
例えばあるわけじゃないですか。
そのサービスの特性とか、
ソフトウェアの作りの話で多分あるはずで。
でもなんか課題が大きくなっていっても、
その求められる知識のスタックとか、
その、なんだろうな。
あんまり…
ほんとかな、ほんとかな。
それはなんかソフトウェアエンジニアという枠からの染み出しが、
足りてないんじゃないかなって、
ちょっと思ってしまうな。
いや、なんか、
えー、そうなのかな。
いや、うーん、
なんか要件がある、
要求事項があるっていう状態から、
スタートしてるっていう話なのかな。
あー、
それは確かに差分としてあるかもね。
なんかじゃあ、
例えばメルカリで、
マイクロサービス化をやろうぜってなってた時って、
なんか、
モノリスのPHPのAPIがあって、
で、もうリリーススケジュールが抑えられません。
ま、なんかまともに開発してリリースするっていうのも全然回せませんみたいな状況だったわけだけど、
それを何とかしてくださいって言われたら、
うんうん。
なんか、何とかできる?
ま、回答を出すことはできると思う。
うーん。
その精度とかは、
さておきね。
うーん。
なんか、あんまりその、
分かんない人は全然ならないというか、
うーん。
な、なぜかというと、
ま、どこまで行ってもその、なんだろうな。
ま、当時の場合は別にHTTPサーブであればいい、
なんかま、
うん。
TLSを喋る何かを作ればいいっていうことは決まっていて、
うん。
だったらその裏側の作りとかアーキテクチャをいろんな変数を加味して、
ま、
うん。
一個一個詰めていくっていう、
うん。
だけかなって思うから、
ま、もちろんその自分が100点を取れるとは言わないけど、
うん。
なんか詰めていけるイメージは湧く。
だけど、
いやなんかその要求の抽象度が高すぎるのかな。
セキュリティちゃんとやりたいですみたいな。
セキュリティちゃんとやりたいですみたいな時に、
うん。
それをなんか一段どんどんブレイクダウンしていかなきゃいけない。
じゃあうちの会社でこの状況でセキュリティをちゃんとやるって何?って、
何をちゃんとしたいの?何を抑えたいの?っていうのをブレイクダウンしていって、
うん。
で、なんかその、枝分かれしていった時になんかすごく、
いやー、わかんねえなー、
どんな、この水は埋まんないのかもしれないと今思い始めたけど、
えーわかんないなー、なんか、
じゃあそのなんていうか、
まあ今ちょっと現実の、現実にあった課題を挙げたけど、
じゃあなんていうか、
例えばだけど2000人規模でエンジニアも数百人いるような会社で、
開発ちゃんとしたいですって言われたら、
うん。
その抽象度はまた違うの?
そのセキュリティちゃんとやりたいですと。
開発ちゃんとしたいですは、開発ちゃんとしたいです。
まあなんか、
あーなんかそれはもはやバックエンドじゃなくて、
組織課題な気がするから、またちょっと違う気はするんだけど。
あー。
それはまあ染み出す必要があるだろうね。
うんうんうん。
うん。
なんか、うーん、
でもなんか、えーどうなんだ?
わからんな。
ソフトウェアエンジニア像みたいな部分が多分、
ちょっとズレがあるのかもしれないな、それで言うと。
あー。
なんか、その、
まあある種ハイグレードなソフトウェアエンジニアって、
必然的になんかいろいろ染み出してくると思っていて、
マネジメントロールになってなかったとしても。
うーん。
セキュリティの意思決定
何らかその意思決定みたいなところに関わってくるようになると思うんだけど。
うーん。
組織面でもまあ部分的にはそうだろうし、
特に技術的意思決定っていうところでは間違いなくそうだろうし。
うーん。
なんだろうなー。
まあでもどこまで言ってもやっぱ、うーん、感覚の違いの具合ないんだよな。
その今の質問も難しいけど、
うーん。
いやーなんか、うーん、
まあでもそんぐらいのとこまで行くと、
今わかんない、じゃあセキュリティちゃんとしてって言われるのとも、
なんかちょっと並ぶかもしれないけど、
うーん。
なんか、いやー難しいな。
いやー。
なんかでも、その組織というもの、
まあ開発組織をどうしたいですか、
もうなんか究極的にはソフトウェアエンジニアリングの一つなんじゃないかと勝手に思ってるんだけど、
うーん。
なんか。
フィードバック不足の現状
わかんない、なんか俺が言いたかったのは、
うーん。
話とかからちょっとずれてる気がしてて、
なんかその、
あーあーあー、失礼します、失礼します。
なんか、
すいませんね。
わかんないけど、
いやなんかすごいシンプルに、
だから一番最初の、
なんかちっちゃいんじゃないっていうのがシリーズだと思ってて、
うーん。
バックエンドエンジニアとして、
わかんない、
ボンってなんかでかい型に投げられた時に考えなきゃいけない範囲、
もう本当になんか、
うん。
その範囲を本にした時の分厚さが全然違うんじゃないと思ってる。
なんていうか。
うーん。
で、セキュリティは、
もう分厚すぎるから、
全部読んでらんないから、
多分パラパラパラって読まなきゃいけない部分もあるし、
物によっては人に異常するとか、
外出しするとか、
うーん。
その、
いや、実はもう今は、
今のフェーズは、
なんかこの、
この第3章まるっと考えなくていいですとか、
そういう差し加減を現実的にはしなきゃいけないと思うし、
あとはその、
この道でやってきてる人の中では、
いろいろあると思うんだよね、
その人なりの、
なんていうか。
うーん。
このフェーズだったらこんなことしなくていいんじゃないとか、
その、
ナイスとハブだけどとか、
相対的にはこっちのほうがいいんじゃないとか、
なんかそういうものがすごく、
多く感じるし、
多く感じ、
で、
そうね、多く感じていて、
なんかその溝を埋めるには、
まあ、
最後に、
最初に戻るけども、
やっぱ鋭くするしかないっていうのも思うし、
うーん。
その、
ベンチマークとかその、
ガイドラインがよりどころになるっていうのは、
もちろん一定層ではあると思いつつ、
僕が一番最初の頃に、
今だからもう一回読み直したいなと思ってるんだけど、
そのセキュリティ勉強し始めた時に、
その辺最初に読んだ時に思ったのは、
なんていうか、
うーん、
何からやろうかみたいな、
なんていうか、
あの分厚いものを、
うん。
分厚いなみたいな、
長えなみたいな、
シンプルに。
うん。
なんか、
分かんないけど、
じゃあ新卒の子が、
なんかバックエンディング1から設計しないといけないんです、
そうたさん、
ちょっとチェックリスト見て作ってくださいって言われた時に、
あーはならないというか、
うふふふ。
なんていうか、
まあ、
壺みたいなのがまあなんか、
分かんない、
10個ぐらいあって、
まあそれだけ押さえとけば、
うん。
とりあえずいいよみたいな、
ことが言えるんだけど、
セキュリティはなんかその壺がまだまだ、
ちょっと僕には分かってない、
分かってないっていうか、
分かってきた部分もあるし、
でもまだ迷子になる部分も、
正直あるから、
すごい迷うこともあるし、
うーん。
あとはその迷ってるがゆえに、
まあ結論は出せるだろうけど、
出した結論にすごく、
自信とか裏付けを、
自分自身の中でどうつけるかが、
まだまだ、
いやー。
消化不力な部分。
まあ、
正直、
何事もなければ、
何事もないまま終わる系の話だと思っていて、
これでちゃんとできてたみたいな確証はないよ、
永遠に。
まあね。
それでいくと、
だから自分の、
なんか決めたことやったことに対しての、
フィードバックみたいなのが、
すごく薄い領域ではあると思う。
あー。
一方で何かが起きると、
めちゃくちゃネガティブなフィードバックが、
返ってくるっていう意味では、
まあ報われない領域ではあると思うよ。
なるほどね。
うん。
面白いね、確かに。
すごくしんどい、
しんどい領域ではあると思う、
そういう意味だと。
あー、
その性質は確かに、
結構差分としてでかいかもね、
意識した方が。
例えばじゃあ、
なんかそこそこでかめのAとBという脆弱性があって、
うん。
Aから直そうと決めてる間に、
Bを狙われて、
事故が起きましたみたいな。
うんうん。
なんでBから直すと決めなかったんだ?
倫理観とその重要性
あのー、
その頭じゃんって。
馬ちゃんね。
ならん。
いやー、
確かに面白いね。
うん。
そうかも。
まあある種、
究極的にはたまたまなんだろうけど、
でもそれでも、
まあAからやると決めた理由は何だっけっていうところは、
説明できないといけないし。
うんうんうん。
そういうものね。
まあ、でも最終的には、
まあ上から順に、
なんか、
まあもう本当どっちも同程度だったから、
とりあえずAからやっただけでしたって。
うん。
話になっちゃうこともあるかもしれないけど、
まあでもそういう意味だと、
すごくハードな領域ではあると思うよ。
うん。
フィードバックが、
ちょっとだいぶね。
超えないですが、面白いな。
うん。
確かに。
だってね、
なんか、
そのー、
さあ、
何事もなかったらさ、
うん。
評価の仕事がないね。
何事もない、
そうそうそう、
何事もないようにしなきゃいけないっていう仕事なんだけど、
うん。
何事もないと、
あ、上手くいったねっていう話ができない。
うんうん。
まあできることもあるよ。
うん。
そのー、
できるものもある。
そうだね。
例えば、検知して、
ハンドリングしましょうみたいな部分は、
まあこれ検知して、
ハンドリングするっていうプロセスがなかった、
プロセスとか仕組みがなかったら、
終わってたね、
みたいなのは、
うんうんうん。
もちろんあると思うし、
うん。
確かにね。
ただなんか、
結構そもそも狙われない、
みたいな、
なんていうか、
こう、
考えも、
まあ結構大事な領域だと思っていて、
うん。
なんかそこまでいくと、
いよいよその、
フィードバックがないよね。
そうだね、
そうだね。
うん。
いやー、
いやー、
しっくりきたわ、
しっくりくるな、
それは。
うーん。
まあ、
記事の内容と全く関係ないけど、
20分ぐらい話しちゃった。
記事の内容と。
いやーでもねー、
そう。
いやーでも、
大事なトピックですよ、
僕的には。
そう。
まあ記事の内容と全く関係ないんだけど、
でもなんか、
そのー、
なんて言ったらいいんだろうな、
そのー、
今こういう話を、
したけど、
なんか倫理観の話って、
なんかね、
なんかね、
なんかね、
なんかね、
なんかね、
倫理観の話って、
こういうのもあるんじゃないかなと思っていて、
ああ。
そのー、
何か、
うん、
それでもやらないといけないんですよっていう話だと思っていて、
うん。
それはなぜですか?って聞かれた時に、
何か、
突き詰めていくと、
必要なことだからですしか、
多分、
起こんない。
なるほど。
必要なのはなぜですか?ってやった時に、
なんか、
結構難しいけど、
何か、
うーん、
会社を守るためであり、
まあ、
お客様を守るためであり、
うんうんうん。
自分たちを守るためであり、自分を守るためである、なんかものすごく視野を広くしたときに、なんか世の中を守るためであり、なんか倫理観ってそういうことなのかなと、まあ勝手に解釈したけど。
全然しげいわさんの言うその倫理観と、私の思う倫理観みたいなのが、同じであるかどうかちょっとわかんないけど、ある種そういう話なのかなと思っていて。
確かにね。ロジックで考えだしちゃうとね、なんか急に、なんていうか、価値筋が見えなくなるときがあるというか、確かにそういう意味では大事な観点かもね。
なんかよくわかんないけど、熱量が高くて、なんかこう背中を押されるみたいな、なんか、そのなんていうかな、ある種のカリスマというか魅力みたいなのは多分必要なのかもね。
ニードする立場の人にってことだね。
うんうんうん。
そうね。
しげいわさんはそれがあるんだろうし。
うんうんうん。
いやー、確かにめちゃくちゃ広げちゃったけど、倫理観大切にしてるからね。
そこに対しての裏付けみたいなのさ、なんか、その、なんか、ね、その、なんだか事故るまでその裏付けが取れないっていうのは、なんか、まあまあまあまあそれによって推進されるみたいなのもよくあるストーリーではあるけど、なんか、全然褒められたことじゃないと思うし。
うん、そうだね。
だから、我々は自分の仕事をなくすために仕事をしてるんだよっていう、なんか、うん。
確かに。
いやー。
まあなんかそういう話なのかなと、ちょっと元々の記事になんか無理矢理結びつけると、なんか、そんなことを思いながら、まあ日々暮らしています私も。
いやー、僕この業界でこの領域でなくてやれるかな。
いやー、だからなんかさ、その、先週だか先々週だかの、なんか、その教育のリソース投下の話の記事とかもあったけど、なんか、まあ結果的にその教育にお金使ってそのまま出て行っちゃったみたいなので、まあ世の中全体としては良くなるのかもしれないけどっていう話があったと思うんだけど、なんか、そこで、まあ世の中全体が良くなるから、まあ回り回ってうちも助かるよねっていう思考を、その、
マジで本気で持てないんだったら、まあセキュリティっていう領域はなんか大変だろうなって思った。
あの時は言わなかったけど。
あー、そこそこ。確かにね、確かに。
いやー。
いやでもその埋まらない溝みたいなのは、ほんと言語化したいなって思ったんで、なんか、言語化会を設けましょうよ、これ。
まあ湯豆腐さんを呼ぶのが、呼ぶっていうか声かけてきてくれるかどうかわかんないけど、湯豆腐さんに声かけるのが良いのか、なんかもっと違う誰かに声かけるのが良いのかはわからないけど、なんか、私もすごく気になるし。
確かにね。ちょっとメモしときますよ。
まあでもそれこそなんかそういうイベントとかやってほしいよな。
うーん。
カニさんとかなんかそういうの答えを持ってそうな気がするんだよな。
なるほどね。
私が答えられない何かを持ってると思うんだよな。
確かに。
いやー、いろんな、そうだね。やりましょう、決定で。
あざます。
まあちょっといろんな人のいろんな話を聞きたいね、こういうの。
うん、そうだね。
歩んできた道筋次第、道筋次第で全然違う、違うというか別の視点からの話とかはありそうな気がする。
はい、次いきますか。
はい、いきましょう。
偽リポジトリの問題
次が、自分のOSSのマルウェア入り偽物を作られたので通報したっていう記事です。
記事の中に産業まとめがあって、それをそのまま読んじゃうんだけど、
自作のOSS、藤原さんっていう人が、藤原アップランシエライっていうOSSのマルウェア入りの偽物を作られてGitHubで公開されました。
偽物には大量の新規アカウントがスターを付けていたため、検索でオリジナルのものより上位に表示される状態でした。
GitHubに通報したところ、偽物を作ったアカウントはバンされたようですっていう話です。
いやー、ちょっと話題になりましたね。
ちょっと話題になってて、レイアイクスも多分同じ話でレイアイクスが公開しているリポジトリをコピーして、
悪意のあるコードが入っている状態で公開しているよっていうので、公式のアカウントで注意喚起してたりとか、
あとはハルプさんっていう、ハルプさんが誰なのか説明できないけど、
ハルプさんがいて、ハルプさんがいて、
いるんですね。
ハルプさんっていう人がいて、
ハルプさんがこの話題に対して似たコードが埋まっているものを探して投稿してたりとかして、ちょっと話題になってました。
なんていうか、トレンド知ってたらあんま驚かないけど、身近に来たなっていう気持ちかな。
いやーなんか、いやーこれGitHubが悩ましいだろうなー。
なんていうか、イタリコッコじゃないですか、バンしても作っては。
アドレス開ければ多分作れるもんなー。
難しいなー、なんかその、わかん…いやー難しいですね。
気をつけるしかないんだよなー、対策が。それが結構きついよなー。
AppleのCLIはどういう性質のものだったんだろう。
なんかそのパッケージ系とかはもう多分防げないよなー。
なんかGitHubはマルウェアスキャンとかはしてないんだろうなー、おそらくだけど。どうなんだろう。
でもしちゃったらアレだもんねー。
いやーっていうか、キリがないと思うんだよねー。数が多すぎて。
そうだね、そうだね。
CLIなんだ。
いやー、悩ましいですねー、ほんとに。
いやー、これなんか自社が真似されてるかどうかみたいなのをどうやって…
それで言うとREAXとか…
どうやって気づいたんだろうね。
ね。
この藤原さんのは、同僚の人がこんなのが出てるねーって気づいたところで、
同僚の人がなんか変な差分があるよって教えてくれたっていう。
はいはいはいはい。
あー、でTwitterで宣伝してるので教えてくれたのか。
うん。
あ、違う、自分で見つけたんだ。
そうそうそう。
あー、なるほどねー。
いやー、厳しいですねー。
13時間後にバン。バンまでのタイムラインはどのくらいなんだろう。
そんなすぐにバンは当たれないんだろうなー。
うん。
なんか、あの、被害者のある藤原さんにはめちゃくちゃ申し訳ない表現になるかもしれないけど、
なんか、日本の感度の高いエンジニアたちにこういうことが実際に起きるってことが知らしめられたって意味では、
まあまあまあ。
うん。
一つ注意喚起的な記事にもなって、事件にもなってたのかなーって気はしてます。
あんまり追っかけてなかったんだけど、アンテナに引っかかってなかったんだけど、なんかやり口としては全然前からずっとあるやつなんだよね。
ずっとある。
なんか名前もついてたよね。
うん。
あー、名前ついてたかな。
なんか僕があると認知してる理由は、ブリピンコンピューターとかハッカーニュースになんか、で、めっちゃ定期的に見るから。
で、スターを買う話もめっちゃ定期的に見るし、みたいな感じ。
まあスターを買う話はその、2、3回かな、なんか。
なんか、400円とかでポチって買えるプラットフォームが普通にあってみたいな。
作る側が悪用を想定してるかどうかわかんないけど、まあもう多分わかってて売ってるだろうねって気はするし。
だから多分、多分規約的に多分ダメだろうし。
まあまあまあ、そう、うん、そういう意味では全然。
まあ、まあやるよねーって気はしてる感じですね。
うーん。
あ、そうそう、リパッケージングアタックだ、そうそうそう。
うーん、名前がついてるんですね。
わかんない。
検索するとなんかAndroidとか上に出てくるけど、確かにな、そのアプリとかもあるんだよな。
その、なんかルイージアプリでマルウェイを混ぜてやるとか。
まあでもあれはさすがにコードまでコピーできてないだろうからちょっと違うか、また。
うーん。
そうですね。
はい、みなさんも気を付けください。
セキュリティ対策の重要性
もう気を付けしかないのかな、しんどいですね、というか。
うーん。
まあそのサプライチェンの方とかはもうちょっとやり終わるかもしれないけど、このCLI使いたくてダウンロードとかも多分どうしようもないでしょうね。
引っかかったらおしまいっていう。
うーん。
手元のPCの、なんていうか、ユイルスソフトを入れましょうなのかな。
前でも入れたもん抜けられたんだけどしな、もう難しい。
いやー。
うーん。
立ちごっこなのかわからない気がする。
なんかパターン検知だと多分見つかんないんだよな。
そうだね。
うーん。
まあでもただプロセスで見たときに、要は、なんだっけ、何で見てたっけ、カールかなんかで撮ってたよね。
ダブルゲットか、ダブルゲットで撮ってきたものをバッシュにパイプしてますみたいなのをプロセスで見たときに怪しいねみたいなのを検知できる可能性があると思っていて、
ホームブリューってさ、それで言うとさ、まだあのインストール方法なのかな、今。しばらく自分でインストールしてないから覚えてないけど。
これホームブリューがさ。
1回あったね、2003年。
ホームブリューは変わってないんだよな。
あれも一緒なの?
あれも一緒だからさ、これも。
ただプロセスで見たときに、こういうのがちょっと怪しいよねみたいな引っ掻き方は、そういうソリューションが入っていればできるかもしれないけど。
そうだね。
うん。
確かにこれホームブリューとか何が逆にいいんだろう。
まあでもそうだね、いやまあまあまあまあまあ。
いやあ、そうね。
振る舞いで見てもらうしかない。
ホームブリューはなんか難しい。
アートでやられたやつですね。
気をつけてください。
まあ個人レベルで気をつけるしかない。
そうだね。
じゃあ次行きますか。
お願いします。
The Security Strategy Blueprint from Vision to Implementationという記事です。
ごめんなさいこれね、実は結構ボリュームのある記事であんまり読んでない、中身読んでないんだけど。
昨日のレイアイクスでやってたイベントで、メルカリのジェイソンがこの記事を紹介してて、ちょっと良さそうだったので持ってきました。
このFrom Vision to Implementationっていうのが割と良いフレーズだなと思っていて、
そのビジュアリーな部分から、じゃあ実装をどうしますかっていう話を多分語ってくれてるんだろうと思っていて、
ヒントになりそうなものが多分あるんだろうなとは思うんだけど。
あとは図でちょっとノーションの方に貼ったんだけど、
Comprehensive Cybersecurity Strategy Frameworkっていうので、
サイバーセキュリティのストラテジーを立てるにあたって、こういうところからインプットを取ってくるんだよみたいな図があって、
この図は結構良かったなっていうふうに思ってる。
なるほどね。
当然のようにビジネスオブジェクティブとゴールがインプットになっているし。
コンプライアンスとかも法律まで触れてる。
そうそうそう。
素晴らしいね。
確かにね。
まあね、ただなんか、
マジで微妙蓋もない話をすると、
これが役に立つのは誰なんだろうってちょっと思った。
CISOとかなんじゃないですか。
遅くない?
CISOまで行く人は何となく自分のパターンを持ってて欲しいなあ、この話。
って思った。
なるほどね。
でも、そういう意味でいくと、
これを実行するというよりはこういう構造になっているべきというのを理解した上で、
セキュリティ担当者が動くみたいな、
そういう時に役に立てられるような話なのかなあ、きっと。
もしくは、それこそ僕みたいにちょっと迷子になりがちな人にとっては、
結構一つのモデリングケースというか、
かなりこういう系は本当ありがたくインプットさせてもらえますって気持ちになるけど。
そうだよね。
なんか意外と穴から刺さる人は多いんだろうな。
これをフックにね、なんかふわっとやってるものを動かすとかもあるだろうし、
なんか部分的に取り込めるエッセンスもありそうな気がするし。
全然、
まあ強い人はね、そうね、それはそうですねって感じはしつつ。
でもなんかいい気持ちだなって思った。
この人はなんかミロの人って言ってたよね。
そうなんだ。
ミロか。
ミロもね、確かにいろいろ乗っかってきそうだもんね。
読んでみよう。
こういう記事いいよね。
はい、ありがとうございます。
そんな感じですか。
面白いね。
この人のブログ記事は結構気になるタイトルが多いな、それで言うと。
チェケラーしとくか。
そうね。
From Startup to Enterprise How to Escape the Security Tech Debt Trapっていう。
いいね。
ちょっとタイトルだけ気になるし。
そうだね。
面白い。
面白いから。
これRSSあんのかな。
RSSあった。
RSSあったのでヒートリングにしましょう。
はい。
ありがとうございます。
じゃあ、次いきますか。
次もヤギハッシュかな。
ちょっと待って。
はい。
DNAのナンバー3のAI取材の会社経営と成長戦略っていう。
なんか取材か発表かの全文書き起こしなのかな。
なんかの発表の時の何の発表だったか理解してないんだけど。
ちょっと話題になってた発表の全文書き起こしだね、これは。
DNAの。
DNAテックカンファレンスか。
オープニングトークか。
キーノートみたいなもんなんじゃないかな。
たぶんこの話の中で既存の人員の半分でって話をしてるんだよね。
そうだね。
これまでの人員の半数で既存事業を伸ばしつつ、残りで新規事業をやっていくっていう方針が確かここで。
へー。
思い切りというか振り切れ方がすげーなーってちょっと思ったのと。
データベースのパスワード管理
で、ナンバー3自身がこういう使い方してるよっていうのがめちゃくちゃなんか、いいねーって感じだったから。
へー。
その文書の方にばっと貼っといたけど。
おー、なるほどね。
初めて会う人の情報はパープルキシティで、その方についての出読記事は何ですかと聞いて、URLをすべてノートブックLMにアップして、
YouTubeで発信してる場合は最近のものは全部URLでコピーしてノートブックLMに突っ込みますよと。
みたいな話とか。
そうするとその人の考え方とかがなんとなくまとまってきて、効率的にわかるよとか。
で、この方はトランプ政権については何言ってますかとか、スタートアップエコシステムについてはどうでしょうかとか聞くと、
その人の考えみたいなのが抜き出されてくるので、
なんていうか、もう会う前からなんとなくその人の、要は予習がめちゃくちゃしやすくなったって話だと思うんだけど。
なるほどね。おー、面白かった。
で、ミーティングに臨むときにサークルバックをオンにしていいですかと。
言える相手には許可を取って、ミーティングが終わるとすぐに記事録がある状態にしていると。
このオンにしていいですかってちゃんと聞いてるのもまたいいよね。
そうだね。ちゃんとリーテラシーが。
サークルバック知らなかった。
いや、群有関係だね。
なんかそのうちワンストップソリューションみたいなのが多分出てくるんだろうね。
これ言ってるやつも全部わかんないけど、ChatGPTに指示したらもうワンプロンプで完結みたいな世界になるのを見せる。
いや、わかるよ。
なるほど。勉強してみます。
いやー活用していきたいなー。なんかコード書きたいんだよなー。
コーディング文明において活用したい気持ちがありつつ。
まあなんか結構、すごい時代になったなと思いました。
追いついていかないとですね。パープルもそうですけど。
なんか先週先々週のやつとか、もしかしたら前のやつももしかしたら読んだそうなのかもしれないけど、やっぱりAIタグ付いてる記事めっちゃ多いなと思う。
なんだかんだ。
そうねー、なんだかんだね。
セキュリティ目線の話もそうだし、こういう風に使うといいぞ的な話もあるだろうし。
フィーチャー的なものもめっちゃ毎週、なんだかんだ毎週やっぱ見るしなみたいな。
あれはですね。
追いついていかないと、老害扱いさんに。
え、ノーション自分で書いてるんですか?先輩、マジっすか?
いや、いいんですけど、みたいな。
いやーでもなんかアウトプット、いやーそれすら古いと言われるかもしれないけど、アウトプットを通じて自分の考えを整理してる側面ってあるからさ、なんか。
そうね。
なんか物によっては脳みそ作り替えなきゃいけないかもなとか個人的にはちょっと思う。
あるねー。
その具体的にどうっていうのはないけど。
あるある。
やっぱ一緒パラダイムシフトだと捉えて。
そうねー、そこはちょっと頑張りたいね。
なんかわからないけど。
頑張りたいんだけどさ、そのなんか高いんだよなー。
いやわかる。
全てが。
ちょっとねー、高いんだよ。
そのー、なんか活用の度合いの問題なんだろうけど。
でもなんか結構最近は、なんかもうとりあえずちょっとGPTに突っ込むみたいなの結構やっとるなー。
ディープリサーチとかもね、運満2、3万ぐらいですか。
そうなんだよ、ちょっと高いんだよね。
課金して使うにはねー、なんかまだちょっと気が引けちゃうんだよなー。
まあ試しやすいものから順に試すっていうのも全然いいだろうし。
でもなんかさ、必然的に裏にさ、それなりのコストがかかってるのがわかってるからさ、安くなんないだろうなと思うんだよねー。
なんなら今もバーゲンプライスなんじゃないかなと思うんだけど、そんなことないのかなー。
安くはなると思うけどね、そのディープシークは。
だって電気代は安くなんなくない?
ディープシークの話はあんのか確かに。
そうそうそう、その技術革新自体はずっと起きてくだろうから。
革新というか、何かの記事でいい表現してたなと思ったけど、なんか小さいのコモディティ化が起きるとか言ってて。
なんていうか、ディープリサーチとかも結局論文が出て、こういうふうにやればいいのねっていうのをなるべく安くできないかっていうのを競合他社がやって、
結局多分それを繰り返していってどんどん価格競争には落ち着いていくんじゃないかというか。
知らんけどね、なんか普通に考えたらまあ。
まあもちろんその限界はあるだろうけどね。
で、あと電気代の話ももちろんあるし。
まあでもそのこの流れ自体がハードウェアに進化を促すっていう話もある気もするんだけど、まあそこまではわかんないな。
まあでも安くなることあったらもう高くなることはないんじゃないかと思うけど、自然に考えてる。
いやー、まあちょっと様子を見たいですね。
そうね。
あとその活用方法も、まあなんかそのスタンスは老害だよって言われたらごめんなさいだけど、
まあやっぱその、こうやって前の目に試してくれてる人たちがいっぱいいるわけだから、
中には有料サービス何個も契約してバーって比べてる人とかいるわけでしょ。
そういう人たちの知見を操るっていうのもまあ一つ手ではあるかなと思うので。
会社単位で発信してくれてるところとかもね、あるし。
次行きますか。
ヤギ足フェスだな。
マジで?本当だ。
えーと、まあ割と軽めの記事か。
データベースの固定パスワードをなくすっていうカムテックブログさんの記事です。
えーと一言というか一行で言うと、
AWSのRDSの機能を使って自動でパスワードのローテートをするのと、
IAMデータベース認証でデータベース接続するようにした話と理解しました。
合ってるかな。多分合ってると思うんだけど。
なんかAWS強くねってちょっと思って。
いいね。こんなことできるんだ。
そう。便利やんと思って。
あれAWSのRDSってさ、裏の実態は何なのこれ。
RDSはMySQL。
選べるのかな、MySQLなの?MySQLだけ?
わかんねーなー。
適当なこと言いながら。
でもなんかクラウド執行みたいな、
あ、6個の人気データベース宣言から選べるって書いてあります。
あ、そうなんだ。強っ。
AWS強いな。
Auroraはインターフェースはポスグレだけど裏側は全然別物だったはずで、
RDSは多分あれなんじゃない?
ものは多少最適化したものを動かしてるかもしれないけど。
オラクルもあるしDB2もあるし。
オラクルもある。
懐かしい。
いいね。確かにコメント書いてくれてるけど、
クラウドシーケルだとしんどいのは間違いない。
そうなんだよね。パスワードをどっかで管理しないといけなくて。
MySQLコマンドで、ローテともMySQLコマンド変えてとかしなきゃいけないし。
IAM接続はできなくもないけど、
でもIAM接続しても結局パスワードが必要だからパスワードも払い出す。
IAM接続の部分ってどっちかっていうと多分クラウドSQLプロキシみたいなところだよね。
そこでは弾かれるからいいんだけど。
二重にめんどくさいんだよね。
そうだね。
じゃあスパナー使えばいいじゃんってなると、
スパナーはスパナーであるというのがもううんっていう感じだから。
ある程度ロッキングされる前提でお金も払えますよっていう感じだったらスパナーでいいかなって思う。
お金もそうだし、そもそも向き不向きがあると思ってるから。
メンテナンスウィンドウかな、そもそもクラウドSQLの場合は。
AlloyDBはどうなんだろうね。
AlloyDBはメンテナンスウィンドウないから。
ただ高いね、めっちゃ高い。
高いんだ、スパナーとどっちが高いの?
さすがにスパナーじゃないかな。
でもAlloyDB、課金待機がそもそも違った気がする。
そうなんだ。ちょっと用途も違う感じなのかな。
そうだね。
ポスグレイインターフェース、なんかAWSのオーロラみたいなもんかなって思ってるけどね。
結構そのスケールどんどんしていくポスグレ交換のデータベース。
クラウドSQLの上位モデルじゃないけど。
RDBなんだけど、水平にスケールするのかな。
相当高いですよと。
というライトの記事だったんだけど、
この話自体は多分AWSが公式で記事とかドキュメントを出していて、
ドキュメントがね、それを読めば多分全部書いてある話だと思うんだけど、
これを読むまで全然知らなかったので、
そんなことできるんだって。
AWSいいね。
用できてる。
これだけ見ても何つも言えない側面はありますが、
やっぱりちょっとね、Googleクラウドとはまた違うところがあるのかなというので。
触ってみたいなアイドルですもん。
Androidの新機能
ありがとうございます。
そうなんだよね。結局自分の会社で作ってるものばっかり触っちゃうから。
そうなんだ。
アンテナもあんま触らんしね。
そうなんだよね、本当に。
プライベートでは仕事で使ってない方を使うみたいなのが本当はいいんだろうけど、
なんかね、めんどくさいよね。
触れるものも、
めんどくさいとか言っちゃダメだけど、
あるし触れないものもあるね、確かに。
そうそうそうそう。
スパナーとかね、プライベートで触るとかって言われるとちょっと。
用事がないよね。
用事がない、そうだね。本当にそうなんだよ。検証ぐらいなんだよな。
結構強いモチベーションがないとね、そのGKEとかもそうだし、EKSとかね。
インターリーフとか結構癖あってむずいなと思ったな。
そうなんだ。
癖があってというか、なんか若干RDBMSと違う考え方が求められるような雰囲気があって、
ようわからんかった。
なるほど。
ちゃんと理解する前にもう触らなくなってしまったから、何とも言えないけど。
まあいいんですよ、必要になったら勉強するんで。
以上です。
ありがとうございます。
はい。
じゃあ次、カルメかな?カルメの記事紹介ですけど、
Android's new feature blocks float stars from side-loading apps during callsっていう記事。
これよくわかんねえなと思ってスルーしちゃったんだけど。
Hacker Newsの記事ですね。
超シンプルで、Androidで電話中にアプリとかを落とせなくダウンロードできない。
もしくはダウンロードするときに警告を表示するっていう機能がベータ版でリリースされてるって話。
なんでかっていうと、電話口でアプリをインストールさせるっていう詐欺がある。
シンプルに。
なるほどね。
電話かけてきて、具体的に事例が書いてなかったので想像ですけど、
サポート詐欺的なやつで、このアプリを入れてこういう手順で操作してくださいみたいな感じでインストールさせるみたいな詐欺が恐らくあって、
それがそれのハードルを下げるとか、そこに対する防御策っぽいって感じですね。
なるほどね。
そんだけだと思う。
確かにサポート詐欺みたいなシナリオはありそうだな。
結構一般ユーザーというかリテラシーがない人たちを守る文脈というか、
仕事でどうこうっていうよりかはっていう感じはするんだけど。
ベータ版だから正式リリースされるのかはどうなんでしょうって感じかな。
されるんじゃないかな。
徐々にされていくような感じですかね。
iOSは同じような機能あるのかな。
でもiOSではアプリ自体そんな変なものがなかなか入ってこないって話があるだろうな。
Androidは野良アプリも落とそうと思えば落とせるじゃないですか。
そういう違いはあるかもしれない。
はい、そんな感じです。
ありがとうございます。
Android、あざす。
Android、なんか防御系ちょこちょこあっていいな。
面白い。
はい、じゃあ次は僕は読みますけど、
ログインIDの開発背景
メールアドレス以外の識別地でログイン。
ログインIDユーザー機能の開発舞台裏を紹介します。
レイアイクスさんのエンジニアングブログ記事ですね。
内容としてはタイトル通りであって、
社内でも実は似たようなというか、
仕事でこの仕様をこの記事が出る前に知ってたりしたんですけど、
爆落のログインIDにメアド以外が使えるようになったっていうアップデートがあって、
その裏側の話をしてくれてるって感じです。
もともとプレスがあったのか、確かにそうだね。
記事でもリンクしちゃった。
メアドなしで使えるようにした理由みたいなところも記事中で元気あるし、
プレスにも書いてあるんですけど、
事業者向けのサービスなんだけど、
その事業者のスタッフの中にはアドレスを持ってない人っていうのがどうしてもいて、
そこに対するユースケースっていうのが事業所必要って判断で、
作るって意思決定をして慎重に設計をしたよみたいな話ですね。
で、結構セキュラルにプロセスが書いてあって全部は読んでられないので、
ぜひ読んでみてほしいなと思うんですけど、
メアド以外使うってなった時に、
じゃあ何を考慮しなきゃいけないんだっけみたいなところで、
識別しどうするんだっけとか、
あとは認証要素っていうのがメールを使えないとなると減るよねっていう部分を、
じゃあどういう風にリスクエッチするのみたいなところとか、
あと確かになって思ったのは、
識別紙のところで結構面白いなと思ったんですけど、
例えばメアドなしのアカウントを発行する時ってどういう時なんだっけっていう時に、
従業員番号的なものがあってそれを管理者が設定するっていうのがありそうだよねとか、
スタッフが自分で決めるってパターンもありそうだよねとか、
社員番号フルってなった時に、
その社員番号が使い回される可能性ってあるんだっけみたいな、
いろんなビジネス上の要件みたいなのをどう吸収するかみたいな、
また爆落してオーガニゼーションって概念があって、
そこにアカウントが紐づく形になるんだけど、
爆落全体でそのIDをユニークにしてしまうと、
社員番号S001みたいな命名規則がある会社がたまたま2つあった時に、
登録できませんってなって使えないってなっちゃうみたいなパターンもあるよねとか、
じゃあIDとしてはダブってもいいようにするんだけど、
その裏側の識別紙は絶対にダブらないような設計にしておかないと破綻するよねみたいな話とか、
そういう一つ一つ解きほぐしてこういうふうにしていったよみたいなところを解説してくれてるっていうところですね。
この必要、利用シーンからログインIDにいかの性質が求められていると整理しましたっていう、
この必要な性質の整理がめちゃくちゃいいなってことだって。
そうだね、本当に。
なんか業務に寄り添っているというか、
結構なんかね、難しいところではね、いろんな会社があっていろんな事業があって、
いろんな勤務形態があってっていうところに、
普段働いてる中で自然と意識を向けるって結構難しくて、
なんか割とこういう要件が入ってきた時に頭抱えちゃうことの方が多分多いと思うんだけど、
いい記事だなと思いました。
めちゃくちゃいいっすね。
結構ちゃんと書いてくれてて嬉しい。
こういう意思欠点積み重ねですよね。
私こういうところがやっぱ腕の見せどころじゃないけど。
使えるもの作んないと意味ないですからね。
まあね、結構でも何か一定割り切りが必要だよねみたいな話は多分あって、
初期パスワードの話とかね。
そうだね。
初期パスワードは悪ですっていう頭でいるとさ、
ここの割り切ってどうしても難しい部分が出てくるかなって。
あとはそもそも何らかの手段で安全に従業員に初期パスワードを伝えるっていうのがさ、
その状態シーケンスに書いてあるけど、何らかの手段いつ何みたいなのはちょっと思わんでもないし、
まあまあまあでもそこは一定割り切るとこだよねっていう割り切りみたいなところはあると思うし。
あとはその何だろうね、何というか、
ある意味リスク転嫁じゃないけど、特定の領域はもう事業者さんの責任にきちんとやってねっていうのを、
契約ベースでも多分握るだろうし、
まあそこは何かトレードオフというか、利用者側に責任協会として求める部分っていう制度とかも、
言及なかった気がするけどまあまあそういうのもあるとは思うな。
あと個人の連絡先を利用する場合みたいなところもね、言及があったりとかして。
まあ多分この記事の裏に何か結構たくさんの議論があったんだろうな。
そうだね、間違いない。
良い記事でした。
良い記事でした。
うん、分量とか内容以上に何か、まあいろいろ何かね、いい記事だなっていう。
めちゃくちゃ良かった。
いやー、ありがてぇす。
はい、じゃあ次行きますか。
なんかこういうのをさ、記事として出してくれるのがいいよね。
そうだね。なかなか出てこないよね、何ていうか。
そうなんだよ。
出したくないわけじゃないと思うんだけど。
いやさ、何か自分の業務を振り返ってみても、
こういう感じで出せる何か決めって多分、私結構してると思ってて実は。
何かあるなーって思うんだけど、そうなんだよ。
多分いっぱいあるんだけど、出せないんだよなー。
出せないんだよなー。
それは何か、何か出すことによって助かる人がいるのかもしれないし、いないのかもしれないし、分かんないけど。
いや絶対いるよ、いるよ。
いや結構あるんだよなー。
はい、まあちょっとそんなことも思いましたが、以上です。
まあ出せる範囲で。
出せないものが、出せるチャンスがあったら出そう。
おかわりとそういう意識で生きてる。
そうね、何かまあね。
出せないものがあるのはマジで事実だと思う。
まあっていうのもあるし、何かどのブログに出すっていう問題もあるんだよな。
何かその必ずしも、何かエンジニアリングブログに出すような内容じゃない。
ああなるほどね。
要は何かっていうか、例えばだけどこういう機能を出しますっていう時に、こういうその悪用のされ方があるよねっていうところに対して、
その何ていうか、どういう強度でこう未然防止策を打っておきましたみたいな話と。
まあ全然エンジニアリングの話じゃないし。
まあね、まあでもさっきの一番最初話した講義で言うところのエンジニアリングというか、課題解決っていうのは全然いいと思うけどね。
不明な感があるな。
次行きますか。
はい行きましょう。
次僕かな。
これまあサクッとでいいかなって感じなんですけど、
GitHubのアップデート
GitHubのチェンジログでSecrets Scanning TTX Base64 Encoded GitHub Tokensっていう記事です。
タイトル通りで、あの伏線が多分3,4週間、3,4回前にあったと思うんですけど、
トリフォグの記事で、なんとGitHubのAdvanced2KTをBase64エンコードされたSecretsたちをスキャンしませんみたいなことを書いてあるんですけど、
GitHubのトークンに関してはそれがサポートされたよっていう記事ですね。
はい、そんだけではあります。
これサマリー、まあいいや、ちょっとミスってる気がする。
まあ他のやつもサポートするよとかは言及がなかったんで、まあどうなっていくんでしょうねって感じですけど、
まあまあいつか対応する、ただ人までも依存としてAdvanced2KTは高いんで、
恩恵受ける人は喜べばいいと思うし、起きられない人はいっぱい事業で稼ぎましょうって気持ちで作った感じです。
誰かの投稿で、Base64は有限状態トランスデューサーだからBase64後の文字率にマッチする正規表現がかけるはずっていう、
なんかどういう感じでやってるのかなみたいな裏の仕組みの話で、
いちいちデコードすると重くないみたいな話だと思うんだけど多分。
有限トランスデュース状態トランスデューサー。
有限状態トランスデューサーだから、全然頭の中に入ってこないんだけど、なんかあああああって感じなんだけど。
わかんねえ。
まあでも多分そうだね、そのトークン自体のフォーマットが決まってたはずだから、プレフィックスとかが。
で、トリフォークがAWSのシークレットキーとか、あの記事はまずにあったけど、
頭かお尻が固定だから、
そうだね。
Base64エンコード後の5文字ぐらいで検索しちゃえば。
コードのパターンがね。
そうそうそうそう。
いい話だったね、トリフォークの場合とかね。
でもこの投稿で言うのって、そのトークン○○正規表現に変換、Base64後の文字率にマッチする正規表現に変換できるはずだよねっていうのを言っていて、
あー。
そうそうそうそう、おーなるほどって思ったんだけど。
なるほどね。
どうなんだろうね。
まあその辺も込め込みでアドバンストというか、お金かかれるって感じかもな。
はい、そんな感じです。
じゃあ、次行きましょう。
権限制御の実装
これは、Building a Secure Rug with Python, Launching an OpenFGAっていうAuth0の記事ですね。
えーと、読んでない。
逆に僕、超ざっくりだけど読んだんで。
なんか割とハンズオンに近い感じだったから、なんか読むって感じがうーんと思って途中でやめちゃったんだけど。
権限制御突き抜ける問題のプラクティスの一つ。
そうだね、これなんかこの記事リストに入れなかったけど、もう一個別の記事があって、
そっちと合わせて読むとよくて、そっちはハンズオンの多分手前って感じの記事なんだけど。
あ、そうなんだ。
いわゆるラグシステムで権限突き抜ける問題があるけど、それをどうすんのっていうとこの回答の一つで、
この記事で触れられてんのかな、触れられてるかちょっと自信ないですけど、
オスゼロのこういうサービス使うとオスゼロ側の権限と紐付けていい感じにできるよみたいな話があって、
それを実際どう実装すんのかっていうのを、
OpenFGは多分オスゼロの製品なのかOSSなのかちょっと忘れちゃったんですけど、
その辺使っていい感じにできるって感じですね。
どれだっけな記事が、ちょっと忘れちゃったな。
見つけらんないや。見つけたらちょっと参考で貼っときます。
でもそのぐらいの理解で良さそう。
多分実際の実装はもうちょっとゴミってそうな気はしていて、
ずっと顔をざっくり見ていくと、
そのラグのおそらく組み方の専門知識じゃないと理解できないですから展開されてるんで、
僕は少なくとも理解できないんですけど、
実際の手順が書いてあるんでやってみるといいんじゃない?
機会があれば覚えておくと良さそうって気はしますね。
自社で製品を提供するときも多分使えるだろうし、
自社システムでそういうのを組むパターンがあるか分かんないけど、
あるとしたら選択肢の一つにはなるんじゃないかな。
もしくはこれを真似て作るとかもね、もしかしたらあるかもしれないし。
はい。
そんな感じでいいと思います。
ありがとうございます。
じゃあ次。
次行きましょう。
パスキー認証の導入
複数ブランドを支える認証認可基盤におけるパスキー認証実装の課題と解決策。
多分パスキーのイベントやってたんだよね。
サイン会とかやってた気がするんだけど。
ああやってたわ。
たぶんそのイベントじゃないかなと思うんだけど。
いくつかパスキー関連の発表スライドみたいなのが流れてきてて、
そん中の一つかな。
ビットキーっていう会社さんのスライドでございまして、
認証認可基盤にパスキー認証を実装し、試験運用中だよっていう話を元に、
悩んだポイントみたいなのを紹介してくれてるような感じかな。
現状本番運用はしてないんだけれども、
複数ブランドを会社として提供してるっていう前提において、
ならではの課題があってよって話と、
その上で課題と解決策みたいなのをそれに対してどう対処したよみたいな話を紹介してくれてる。
前提としてホームハブワークハブっていう2つのサービスを提供しているらしくて、
別ブランドだし別のメインだし別ログインページだしっていう状態において、
ビットキープラットフォームっていうそれぞれのサービスに認証機能を提供するような機能がありますよと。
例えばなんだけどそこでアカウントとユーザー情報一元管理している状態があって、
ただ現時点でこれが必要なユースケースは存在しないよみたいな、
そういう前提がありますよと。
現状パスワード認証がメインなので、
共通機能としてパスキー認証を実装したいねっていうのが動機としてあって、
ちょっとだいぶはしょって紹介していくんだけど、
ビットキープラットフォームのドメインをRPIDにすると、
ホームハブワークハブ側でパスキーを使えないという問題がありまして、
ページで言うと25かな。
選択肢として対処する方法として30ページあたりになるんだけど、
A案B案となって、A案がサービスに応じて党的にRPIDを設定するってやり方で、
B案がサービス共通のログイン用サイトを作るってやり方で、
結論から言うとA案を採用したよって話を書いてくれていて、
RPIDをサービスに応じて、
要はホームハブワークハブそれぞれに党的に変更する、
RPIDをそれぞれに合わせて変更するってやり方を取りましたよって話をしている。
結果的にホームハブワークハブそれぞれに同じところで提供しているけれども、
別々のパスキーを設定するっていう形になるが、
完全に独立したサービス、独立したブランドなので、
それによって損なわれるUXがないよっていうので、
それを選べたよっていう話。
パスキーの仕様でいいよな、
RelatedOriginRequestsは、
RelatedOriginRequestsっていう仕組みがあって、
要はこのオリジンは、
このオリジンと関連性がありますよっていうのを提示できるような仕様がある。
技術的にはそれで解決し得るものだけれども、
ニュースケースとしては合わないみたいな話を書いていて、
なので結論としては、
今回はこのA案、B案のうちのA案でよかったねっていう風に結んでいるような発表記事でございました。
意思決定の過程
これも結構面白い意思決定だなと思っていて、
素直に考えるとA案って選択しないよなと思うんだけど、
ただ難しいな、難しいとこですね。
これは例えば将来的にサービスが3つ目ができましたみたいなときに、
共通IDを使ってログイン画面も共通化しましょうみたいなニュースケースが出てくると、
多分めちゃくちゃ大変で、
パスキー全部作り直してもらわないといけないので、
なかなかある種というマッチと言ってもいいのかもしれない実装が多分、
割とメインストリームのやり方なんじゃないかなと思ってしまうんだけれども、
私の意に反してA案を取っているというのが結構興味深かった記事です。
記事というかスライド発表でした。
面白いね。
たぶん事業者の意思決定に近いだろうね。
近いね。
私だったらどうするかと言うと、
個人的にはRelated Origin Requestsを使いつつ、
認証を通せるかどうか。
要はそのユーザーがホームハブ、ワークハブそれぞれに認証は通せるけど、
サービスを使えるかどうかというのは分けて考えるというやり方のほうがいいんじゃないかなとはちょっと思ったけど。
例えばだけど新しくエンジニアが入ってきたときに、
サービスごとにRPIDが変わるっていうのが振る舞いとして結構認知負荷が高そうな気がするんだけど、
どうなんだろうな、分かんねえな。
正解はないところだと思うので、
なんとも言えないけど。
Related Origin Requestsのところまでまだ本を読み進めてない。
おなじみ。
ちゃんと理解したいな。
まあ確かにね、いろんな選択肢が通り得るね。
でもRelated Origin Requestsの紹介内容としてはこのスライドの中で紹介している内容で十分理解できると思うので、
ここだけ読めば全然分かると思う。
了解です。
面白いね。
Related Origin Requestsはね、どこに書いてるの?
作品から引けば出てくるでしょ。
122ページと100何章1ページの数です。結構先だね。
もうちょっと。
はいはいはい。複数止めで終わってる。
第8章で説明してるらしいよ。
あったじゃん。170ページだ。
170ページの。
そうだね、170ページ以降で。
まあでも、これやっちゃうとまたげちゃうんだもんね。
またげちゃうね。
またげちゃうので、だからそのサービス側でエンロールメントしてるかどうかは、
そのサービス側で判断してね。
認証は通るけど、使えるかどうかはまた別の概念だよねっていう考え方の方が、
まあ分からんけど柔軟性は担保できそうだなって思ってしまうんだけど。
One wayではないかもね、意思決定自体は。
まあ分かんねえな。
このワークハブとホームハブがどれぐらいつながり得ないのかっていうところが。
そうなんだよ。それによるからちょっと、まあ外からどうこう言える話ではないのは理解しつつ。
ちなみにワークハブ、弊社はお世話になってるんですけど、まあ確かにつながんなそうではある。
あ、そうなんだ。じゃあまあいいんだろうね。
うーん、なんかなんだろうな、難しいな。
その、2Bと2Cって感じかな、なんか著作。
うーん、まあなんか名前からしてそんな感じなんだろうなと思ってた。
本当につながんないんだろうなとは思ってたんだけど。
なんかつながると多分逆に気持ち悪いかもしれない、ユーザーの方が。
まあ、だからこそ取れる意思決定だった。
そうだね。
うん。
いやでもこれもなんかさっきのJXのやつに続いてありがたいですね、こういう。
そうそうそうそう。
うんうんうん。面白かった。
セキュアな感じそう。
なるほどね。いやー、いいね。
素振りしたくなりますね。
そうなんですよ。
うん、こういう現実的なやつに。
出席に立ちたい。
うん。
出席を。
まあね、こういうのが面白いとこだと思うんだよな。
なんかそういうやつでやるときの。
このなんか、まあこれがどこまで、そこまでこれは散り着いた意思決定ではないかもしれないけど。
うん。
なんか決めに行ける、決めに行くっていうところが面白いとこだよね。
うん。
うん。
ありがとうございます。
はい。
ありがとうございました。
じゃあ次。
次か。
LLM脆弱性の発見
LLM脆弱性の新発見。一つの絵文字が53トークンになる理由とは。
なんか聞いたっぽいタイトルの記事なんですが、別にディスりたいわけじゃなくて。
大丈夫ですよ。
はい、まあまあ出落ちというかタイトルの通りで。
うん。
なんかAI研究者の人が一つの絵文字がLLMで53トークンとして認識される現象を報告してるよっていう話で。
うん。
ユニコードの変態選択肢、バリエーションセレクターズと呼ばれる不可視文字の存在によってこれが起こるよっていう話で。
文字のスタイルとかバリエーションを指定するポートポイントで通常の表示には影響を与えないよっていう。
まあちょっとどっかで聞いたような話なんだけど、また後で紹介しますが。
うん。
LLMはトークン分割時にこれらを別の文字としてカウントし、トークン数が増加するよっていう話。
で、このこれによってなんか例えばトークン爆弾みたいなのを作ったりとか、
不可視文字を利用したプロンポイントインジェクションとかができたりするんじゃないっていう懸念がレイズされてるっていう感じですかね。
うん。
確かにね。
で、なんかどっかで聞いた話だなと思ってて、不可視文字でインジェクションするみたいな先週も見たんだけど、
それが同じ問題なのかなっていうのはちょっとまだ確認してないんだけど、
でもこのコードポイントを見ると見覚えがあるコードポイントだから多分同じ問題なのかもしれないよ。
でもトークン爆弾の発想は本当に興味深くて、
トークンベースでの課金だよね基本的にはね。
処理したトークン数での課金だと思ってるんだけど。
多分サービスによるんだけど今見たらChatGPTのウェブコンソールはメッセージの数だけど、
おそらくメッセージの長さに制限があるはずだから、
なぜか昔記事全部貼り付けて要約させようとしたら死んだから。
ただAPIはトークン課金だったよね。
トークン課金。
そうそう、そっちは見てて。
だからサンプルコードに爆弾仕込んでとかは全然できるだろうね。
なんかEDOSが容易に刺さるんだよな、それってこと。
刺さるのか、でも思うんだけどさ、
EDOSっていうの?
いや、EDOSね、EDOS。
EDOSっていうのがあるんですね。
EDOSっていうのがあるんですよ。
すいません。
EDOSっていうのがあるんですよ、あるんですけど。
あー、はいはいはい。
これを差し込める状況だったら別にこれじゃなくても差し込めるよな。
単純に長いものを、長い文章、長いテキストを差し込むっていうのは多分できるよなと思って。
本当にこのトークン爆弾っていうのが攻撃として成立するのかはちょっと疑問視してる。
確かに確かに。
結構いろいろ組み合わせないとあんまり役に立たないからね。
これ単体で云々っていうのは確かに。
じゃあバックエンドのプログラミング言語で文字列の長さをチェックしたときにどういう見え方するのかなっていうのがちょっと気になって。
サイバーセキュリティの経営ガイド
この何だっけ、一つの絵文字で53文字とかで判定されるみたいな文字を作るラストのコードが紹介されてたので、
それをラストの実行環境とかちょっとよくわからなくて、触ってないからわからないから、
PythonのコードにしたりとかGoのコードにしたりとかして動かしてみて確認してたけど、
実際何ていうか、普通に長さだけ愚直に長さだけチェックするとちゃんと長い文字列として確認されてたので。
なるほどね。面白い。
そんな刺さんのかなどうなんかなとかちょっとよくわかんない。
なんかどっちかっていうとわかんないけど、プロンプトで普通に使ってて普通になんか理由があって投げて、
あれなんか課金めっちゃ増えてるみたいな方が可能性としてはありそう。わかんないけど。
ね。
なるほどね。前のトレンドマイクロの方がまだ攻撃イメージは湧くかもな。攻撃って観点だけに立つと。
そうだね。
プロンプト投げさせる、もしくは投げるっていうステップが必要なのがやっぱり一つ意外と突破するのが難しいというか。
そうだね。
ちょっと考えがいがあるトピックかもしれない。
うーん。
これ面白かった。はい、次言いますか。
はい、いきましょう。
次はGMOサイバーセキュリティバイエラーへの記事で、サイバーセキュリティについて経営者は何を問うべきかっていう記事ですね。
で、なんか内容としてはイギリスだっけな、イギリス版サイバーセキュリティ経営ガイドみたいなものがあって、
そうですね、英国国家サイバーセキュリティセンター、NCSC公開してるQuestions for the World to Ask About Cybersecurityっていう文章があって、それを結構紹介してくれてるっていう記事ですね。
で、なんか問いみたいなのが9項目あって、9個なんでざっと読んじゃうと、
セキュリティは根付いてるか、セキュリティに前向きか、セキュリティ人材は育ってるか、重要資産を特定しているか、サイバー脅威を理解しているか、リスクマネジメントしてるか、
セキュリティの効果は出てるか、関係会社と連携してるか、最後がセキュリティ事故に備えてるかっていう9個の質問があって、
これをそれぞれ立て付けとしては関係者に問いかけて対話していくことで議論の入り口にしましょうみたいな感じで記事が書いてあって、
この9個の問いにそれぞれこういう話をできるといいですよねみたいなのが記事中では言及されてるっていう感じです。
わざわざ僕が紹介したいって言ったのは結構、取っ掛かりとしては面白いかもなって気はしていて、
サイバーセキュリティ系ガイドラインの話をこの場で多分したかな、したかしてないか終わってないですけど、
そっちよりはわりと明日何をするかのイメージが湧くというか、ざっとディスカッションし始めるには悪くないのかなって気持ちと、
ただ議論していったときにどこをゴールとするかみたいなとこは普通に自分で考えないといけないというか、
そういう部分はあるかなっていう。
もしかしたら元文章にそこも言及があるのかもしれなかったんだけど、ちょっと時間がなくて読めてなくてっていう感じですね。
なるほどね。
どうですか。
でも確かにざっと眺めて結構いいね。
この攻めない異文化の話とか、攻めない異文化の浸透みたいなのは確かに大事だなって思うし、
これさ、会社に売り切りというか、忘れがちな気もするんだけど、いわゆるいい会社にいると忘れがちな気もする。
そうだね、確かに。
結構大事だな。
間違いないね。
当たり前じゃないよな。
結構意識的に、そうだね、間違いない。
大事。
攻めると隠すんでね。
隠すというか、心理的安全性の話とかいろいろありますけど、
人に責任を求めないっていうのがめちゃくちゃ大事です。
そうですね、元文書は結構もう少しカロリーが高そうな内容かな。
すごいね、えぐい。何ページあるの?50ページ?
50ページ。
でもいいね、なんか一個のプラクティスとして、多分いろんなフレーマークとかガイドラインとかからブレークダウンされたものが多分エッセンスとして詰まってるんだと思うし。
そうだね、そうだね。
いや、よかったです。
これはなんか活かしやすいね。
うん、使いやすい。
明日から使える急行の問いみたいな、そんな感じで。
いい感じ、いい感じな、いい感じな気がするんだよな、その。
いやー、ちょっと話したいな。ドキドキしちゃうな。
じゅうよしさん特定できてますか?本当ですか?
こんなものある?ご存知ですか?
皆さん、問いかけてみてください。
うーん、はい。
はい。
はい。
じゃあ、次いきます。
はい。
バグバンティの監視ツール
次は僕で、またまた森岡さんのバグバンティの方の記事なんですけど、バグバンティにおけるJavaScriptファイルの監視ツールの事例っていう記事です。
記事の内容はタイトルの通りなんですけど、僕がちょっと個人的に勉強になったのは、ツールの紹介はいろいろあるんですけど、そもそもJavaScript監視ツールって何ぞやって話をしてくれていて、
結構一般的にバグバンティはインターネット上で動くサイトみたいなところにJavaScriptファイルが大体あるんで今の時代だと。
それを収集したり解析したりするんだけど、その辺を解析する時にバグバンティをするって観点であった時に、ずっと同じ状態ではもちろんないというか、リリースされるためにJavaScriptが更新されたりっていうところがあって、
その更新サーブみたいなところに結構新しい機能を知るとか、新しいバグみたいなものを発見するとか、随縮性を発見するっていうところをしていく中で結構大事な情報になっていくので、
その辺を監視して自分のDiscordとかSlackとかに通知するみたいなことが書いてあったりしたんですけど、そういうようなことを結構するよっていう話が書いてあって、
そのためにこの辺のツールを使うといいですよみたいなところがいくつか紹介されているという記事ですね。
僕は全然バグバンティの世界を知らなかったので、ちょっと面白いなと思って紹介したって感じですね。
あとなるほどなって思ったのはバグバンティ自体早いもの勝ちなんで、やっぱりリアルタイムに変更通知してバッと探しに行って、おいしい球がないかを見つけるみたいな話が多分あって、
それはちょっと面白いなと思ったというか、バウンティーって感じがして。
ここまでいくと結構現実の脅威に本当に近い感じがするよね。
攻撃者も同じことをしてるっていう。
いわゆるAPTというかAdvanced Persistent Threatみたいな粘着してずっと狙ってるようなシチュエーションにかなり近い気がする。
確かに。
攻撃者がってことだよね。バグバンティハンターが。
そうだね。
普通に使ってると思っているしかないよね。
前回のAIのやつとか思ったけど、やっぱバープスイートの記事の話じゃないけど。
AIしかりツールしかり、いつかの回で話したけど、バグバンティー用に紹介してるけど、悪用もできるよねっていう部分でやっぱ難しいところはあるね。
どう挙げてもやっぱ悪用できてしまうっていうのはしょうがない部分はありつつ。
でもバグバンティハンターがやりませんって言っても攻撃者やるからじゃあ先に見つけてっていうか。
俺さ、このバグバンティーの参入衝撃が高いよな。
そうだね。
ちょっと気軽に探そうみたいななんかさ、そういう感じになんないよね。
どうなんだろうね、この人が書いてた。
でもこの人が書いてたバグバンティーの始め方みたいな記事を読むと、始められそうな感触は個人的には得たけどね。
ただその、わからない、社会人やりながらできることをやるとちょっと難しいかなと思うんだけど。
あとはその、だからどのレベルで、あとはどのレベルでやりたいかなんじゃない?
こうやっていきたいってなると相当衝撃は高いというか。
でも衝撃が低いって言い方もできるんじゃない?こういうツールとかが公開されていて、AIのツールとかもあって。
昔だったら自前でスクリプト書かないとスタートライン立てなかったのが全部揃ってるっていう話とかもしかしたらあるのかもしれない。
知らんけど。
でもどこまでいっても技術力が必要だろうな。
想像で喋っておりますけど。
いやー。
ありがとうございます。
ありがとうございます。
YouTubeの脆弱性
で、次はそんな多分優秀なバグのアンティーハンターがバグを見つけた話で。
これね、僕じゃなくてヤゲ社がつけてくれたんだけどめっちゃ面白かったんで紹介したくて。
あれ?これ前に読まなかった?
いや、読んでないと思うよ。
ソフトキャストで読んでない?
そうか。
めちゃくちゃ既視感があるんだけど。
なんで?なんでこんなに既視感があるの?
2月12日の、そうですね。
ブリーピングコンピューターの記事で
Google Fixes Flows That Could Unmask YouTube Users' Email Addresses
っていうタイトルです。
で、まあまあ、事実は超サムルットタイトルの通りであって
YouTubeの厳密な動画を配信している人のユーザーの
Emailアドレスを調べられる脆弱性があったんで
それをGoogleが直したって話なんですけど
結構込み入っていてちょっと面白かったので紹介したいなと思ってて
じゃあどういう手順でYouTubeの配信者のメアドを特定できるのかっていうのを
順々にちょっと話していくと
まず一つ前提知識として
Googleのサービスの内部で
Googleアカウントの識別として横断的に使われる
内部的なIDっていうのがあるらしいと
これが外IDっていうらしいんですけど
そういうものがありますと
これはだからYouTubeのGoogleアカウント中間
Googleアカウントでログインできるサービスは
全て内部的にはGoogleアカウントが外IDに紐づいてて
裏側でこういうふうにやってるっていう構造になってらしい
この外ID自体は内部IDなんで
普通は外から参照できない
自分のアカウントをモデルにやっても参照できないようになってるんだけど
まず一つここに穴があって
YouTube APIの一部を利用することで外IDを
レスポンスから取れるっていうのが見つけましたよっていうのが一つ目
具体的には誰かをブロックしようとするときに
そのレスポンスに入っていて
操作自体は実際にブロックまでしなくても
ブロックするボタンをUI上で表示するだけで
リクエストが飛んでレスポンスが返ってくるらしくて
そのレスポンスにRESOLVEをエンコードされた外IDがまず入ってますっていうのが一つ
ここで一個目の事実としては
YouTube上のあらゆる動画
公開されてる動画の配信者の外IDが
集めることができますっていうのが一個目の話
これだけだとまだメアド取れないんですけど
この2ステップ目に外IDを使ってメアド取れないかっていうのを探してみたところ
Pixel RecorderっていうプチサービスみたいなGoogleのサービスがあって
このAPIの一部にどうやら外IDを投げるとメアドに変換できる
機能があるらしいぞっていうのを見つけました
これもちょっと面白くて
具体的にどのAPIがそれができたかっていうと
このPixel Recorderっていうのが録画をするサービスっぽいんですけど
録画共有APIのセキュリティ問題
録画したものを共有するAPIで
外IDからメアドを引っ張れることができるようになりました
ただ問題は共有先に外IDを指定するっていう仕様になってるんだけど
実際に録画共有しちゃうと
メアドを特定しようとしてる相手に共有メールが飛んじゃいますよと
共有APIなんで
収集はできるけどバレちゃうよねっていうところがあるんだけど
これ自体は録音ファイル名みたいなところのファイル名の長さに
バリエーションがかかってないっぽくて
はちゃめちゃなうん十万文字みたいな録画面を作って共有っていう風にすると
多分内部的にどっかでエラーが起きて
メールが実際に送信されないっていう挙動が見つけられたんで
相手に知られることなくPixel RecorderのAPIを使って
外IDからメアドを引くっていうのも達成できたっていう状態
これが2つ目
この2つを繋げると
ようやるな
ようやるなって感じでしょ
これでタイトルのやつにやっとたりつくって感じで
任意のYouTubeチャンネルの配信アカウントのメアドを引っ張れることができるよって話ですね
これはGoogleに報告してて
Oktaのセキュリティ設定
2月9日に修正済みで
最初はあれかな
多分外ID特定できるだけならって感じで休めの報酬だったけど
結果的に
1万ドル?
そうだね 結構な金額もらってますねって感じ
あれでした
なんかシンプルに
ようやるなっていうのが結構おもいないなと思ったのと
あと難しいなと思ったのは
Googleならではだなっていう気はしていて
なんなのな
めちゃくちゃ星の数ほどサービスを出してる中で
この外IDからメアド引けちゃいますっていうポイントを
抑え切るの結構大変そうだなというか
でもなんかその外IDのユースケースとして
間違った使い方なわけでしょ
おそらくね
だからそういう攻め方を多分するしかないんだろうな
そういうユースケースがないように
なんていうか
何かをするしかないんだろう
そうなんだね
なんか規約なのか
どこでどう開発をさせるのかみたいな
僕らも身近な話に落ちてくる気がするんだけど
結構ね
っていうのもあるし
なんかそのレスポンスに外IDが入ってないかっていうのが
わりと全てなんじゃないのこれって
違うのかな
そうだと思う
外ID自体は露出してもいいっていう話なのか
そもそも完全に内部IDだから
露出してはいけないっていうものなのかで
ちょっと話が変わってくると思っていて
基本的に露出してはいけませんっていうものだったら
また違うアプローチが取れると思うし
露出してもいいケースがあるけど
特定の外部向けIDと紐づけてしまうのは
ダメだよっていう話の中でどっちなんだろう
どっちなんだろうね
その辺はちょっと記事から読み取れなかったな
結構元ネタの記事も
バグバンティーの報告者側のブログだったんで
そうね
Googleの回答とか載ってなかったっぽいから
なんかGoogleのアンサー記事が欲しいなってちょっと
そうだね
まあそれで言うとあれかな
手元でYouTubeのブログのやつ見に行って
塞がれてたら
意図的じゃなかったんだっていうのは取りそう
でもこの件があった以上は多分予防的に
普通に露出させないっていうか
その外IDを取れる場所も
多分どこでもあったわけじゃないだろうから
探し合ってたっていう部分もあるだろうし
基本は露出しちゃいけないっていうのが
可能性は高そうな気がするね
多分ね
確かにね
露出すんなもそうだし
それを生の
ユーザーが叩けるARのAPIで
は少なくとも使えないようにしとかないとねって感じなんだろうな
面白かった個人的に
面白かった
なるほどねと思って
このなんか野良サービスさんのGoogleだなと思いながら
はい
じゃあ今日最後ですかお願いします
あら
Don't overlook these 6 critical Okta security configurations
っていうハッカニュースの記事です
Oktaの
なんていうか
やるべきその6つの設定みたいなのを紹介してくれていて
別になんか
なんてことはない記事なんだけど
パスワードポリシーの設定と
フィッシング体制のあるニュアンス認証の導入と
Oktaのスレッドインサイトの有効化と
管理者セッションのASNバインディングと
セッション有効期間の設定
行動ルールの設定
異常検知みたいなのをしてねっていう
ちょっと原文から翻訳した状態で
サマリーしちゃってるので
直接対応してないんだけど
この6つを紹介してくれていて
さらにSaaSセキュリティポスチャーマネジメントソリューション
SSPMを導入することで
Oktaを含む重要なSaaSアプリのセキュリティ設定を
継続的に監視し
ベストプラクティスからの5つを検知
ストーカーされた評価やリアルタイムのアナウンスと
セキュリティ構成の変更に対する迅速な対応が可能になります
SSPMとセキュリティの重要性
みたいな話を書いてくれてる記事
設定画面って自分で触ったことないからさOktaって
なんかオーンって思って
オーンって思って
打席に立ちたいなの気持ちになりましたよという話と
有効に使える会社は限られるかなと思うんだけど
ASNバインディングは結構頭いいなと思った
めっちゃいいこれやりたい
多分究極系はそもそも
自社のネットワークに
AS番号が振られていて
その番号に絞るっていうのが多分究極系だと思うんだけど
要は大量にオフィスがあって
でもASは1個に絞られている
出口が1個に絞られている
自社にネットワークに入ってこないと
そのAS番号からの接続ができないから安全だよっていう選び方が
多分一番ベストかなと思うんだけど
自社で契約しているISPのASに絞っておくっていう
オフィスで契約しているISPのASに絞っておくっていうのも
かなり緩めではあるがいいのかもなとか思ったり
でも結構その経路が潰れた時に
アクセスできなくなっちゃうと
面白そうだなっていうか
いいアイデアだなと思って
どっちかというとこれ1個で持ってきたような感じかな
この記事自体
SSPMっていうのもあるんだっていうのが
結構面白くて
シーナップの構成要素とか
SSPMみたいな名称もそうだけど
めまいがしてくるっていう
なんでもかんでも名前付けりゃいいってもんじゃないだろうって思うんだけど
売れるんだろうな
マジキリがない
ガートナーのシーテムとかもさ
ガートナーがシーテムを提言して
ガートナーがトレンドとして紹介してみたいな
すごいマッチポンプ感がすごくてさ
なんかちょっと
なんかちょっと拒否反応が
出るんだけど
まあなんかその
決済権持つ人に刺さりやすいんじゃないかなって思うけど
すごい平たく言うと
シーナップっていうのがあってですね
なんか本質から遠いなーって
ちょっと思っちゃうんだけど
まあまあまあって感じなのかな
SSPM個人的には気になるけど
なんか本当に?って思うけどな
どうなんだろう
普通に気になるな
まあまあまあそういうのがあったらいいよね確かにその通りなんだけどさ
なんでもかんでも名前付けんなよって
そうだねー
えー
オクタのSSPM誰か詳しい人いないかな
セールスの人が一番詳しいんだろうけど
オクタが出してるっていうよりはあれでしょ
あーそういうことか
そういうことか
こういうのをやってくれる監視するのに
SSPMっていうやり方があるよっていう
うんうん
さすがの進化したしなー
いやでもこういう
勉強になりました
なんかいや気持ちとしては
今仕事文脈でいろんなSaaSの管理者権限をとても手元に
集めてはないんですけど
いろいろ設定を見てもらったりしてるんですけど
こんな気の利いた設定してくれてるSaaSはマジで
本当に一握りだから
まあもちろんオクタは性質上ね
求められるセキュリティレベルが高いっていうのがあるから
全部にこれを求めるべきでは全然ないんだけど
まあでもなんか
これはあってほしいなみたいなやつやっぱ正直あったりするから
うん
そういう気持ちもありつつオクタ
さすがやんっていう気持ちもありつつって感じでしたね
良かった
本週最後の記事でございました
ありがとうございます
はい
結構読んだな
2時間くらいか
また2時間だよ
なんか最近多いね
なんて言ったらいいんだろう
ただ読むことに徹するべきなのか
そこから発展して違う話をするべきなのかを
ちょっと今日は考えさせられたよ
振り返り
まあまあでもそれを話したくてやってる側面はあるけど
まあまあしょうがないね
全然いいよ
なんていうか
4時間とかだったらちょっと2回目は良かったなっていう
その
あれなんだよな
ノーションAIを僕が活用した仕事により
スループットが上がってこっち側に幸せが来るっていう
そういう話はあるんだけど
それで言うと私は私のキャパで読めるものしか読んでないっていう節はあって多分
うん
まあでもにしてはそうだね
結構全然いい
昨日の発表でカニンさんも触れてたけど
あんまり情報収集みたいなの頑張ってもねみたいなこと言ってたし
うまいことバランスとって
そうだね
ちょっとその話聞いて思ったのは
記事読めてなかったなみたいなすごい
ダウナーになることがたまにあるんだけど
収録の時間中とかでもそれでもいいかなって気も
割り切りも必要だなって気はした
ラグの話とかね
切りないからやっぱ
へーみたいなふわってなぞるぐらい
なんかあずさんとかけんごさんの量
なんか見てるとちょっと感覚まぎるけど
完全にハズレ値なんだから
そういう気持ちで
たまにハズレ値がおるんよな
一人でアドベントカレンダーをやりきっちゃう人とかさ
ハズレ値だね
それはハズレ値
僕らは僕らなりにやっていきましょう
はいじゃあそんな感じで
今週も面白かったです
面白かった勉強になりましたか
じゃあまた来週もいっぱい勉強しましょう
おやすみなさーい
