00:00
こんばんは、Replay.fm、第46回です。
こんばんは、46回。
うん。
いや、足疲れてる。 46。
足疲れてる。
早くやろう。
今日、先週のやつ、編集で聞き直したとき、
2人ともテンション低すぎて笑ったんだよ。
今日はそれ以上にもしかしたらテンション低いかも。
日に日に疲れている。
いやー。
会社心配されちゃう。
会社心配されちゃうよな。
いや、楽しいんだよ。楽しいんだけど、その、なんかね、楽しいんだよ。
なんかあのー、ちゃんと毎日体力使い切って仕事してる感がある。
うん。
のかなー。
なんか。
でもこれ収録、夜10時、9時10時とかだからもうなんか、
燃えかすみたいな。
そうなの。完全にそんな感じなんだよ。完全に燃えかすなの。
そうなんだよなー。
だって夜中にプルリクエストレビューしてくれる人いたら仕事しちゃうよな、きっと。
誰も、なんかみんなちゃんとなんか夜中は仕事してないから、
俺も仕事してないだけで。
そうねー。レビューしてくれる人がいるのか。
まあでもSREとか割と夜が遠いよな。
それにしてもじゃん、なんか夜中とかでレビュー以来来ても、見ててもなんかでももう反応しないもん、普段。
まあね、いやそれが正解。
夜は一人でコツコツやるのが一番いいっすよ。
あの、読んだ記事じゃないんだけど、最初お詫び記事が、
お詫び案件があってですね。
あの、先週、パスキーか、パスキーで、
クロスデバイス、
名前忘れた。
クロスデバイスの印象?
あ、そうだね。
クロスデバイスサインでフィッシングが可能みたいなブログがあって、
近接、Bluetoothで繋いでないとダメなんじゃないみたいな、でも分からんね、穴があんのかなみたいな話があったんですけど、
その同じブログが続報を出してて、結論間違ってました、ごめんなさいってブログを出してたんで、
ちょっと先週そうなのかと思った人がいたらすいませんっていう、お詫び。
結局あれだよね、やっぱ近接確認入るからっていう話、あってるってことだよね。
あってる。
で、まあ表現としては正しく実装してればみたいな言い方してるけど、
まあでも、少なくとも送ったかな、送ったかなんかで検証して、
多分前回のブログは送ったかなんかで検証して、成立したよみたいな言い方を多分してたっぽくて、
それはもうそんなことはなかったです、ごめんなさいみたいな、結構。
まあ割と怒られたんだろうね。
技術ブログのレビュープロセスとか、ちゃんと見直しますみたいなこと言ってて、
一応なんかセキュリティ製品を売ってる会社のブログだったから、
まあ確かに怒られたろうなと思いつつ、ちょっと個人的には、
セキュリティ会社のやつでも鵜呑みにしたら、鵜呑みにしてたわけではないんだけど、
まあもうちょっとキャッチアップしようって個人的に反省しつつ、お知らせという感じです。
ありがとう。
そうなんですよ。
良かった。
そりゃそうだよな、フィッシングレジリエンスになってきてるんだしね。
レジスタントなのか。
レジスタントなのか。
もうだめだ、カタカナが覚えられない。
いや、この、もう10年生きてんのに、10年仕事してんのにさ、
覚えらんないカタカナワードリストみたいな。
いやいや、ちょっと言い訳タイム読みましょう。
でもタイタンパ製とかさ、出てきたでしょ。なんかいろんな試験とかで。
タイタンパ製は出てきた。
あれ、タイタンパ製はね、覚えられない。
あれはだからタンパレジスタント。
タンパレジスタンス、タンパレジスタント。
なるほどね。確かに、そうやって繋げていきたいな。
そう、覚えられない、なかなか意味が覚えられないカタカナ用語シリーズっていうのを手元に実はメモしてるんだけど。
それをじゃあ、禅にあげて。
マッシュポップ記事紹介しよう。
オフトピもいいとこだよな。
なんか、覚えやすい歌とかにしてさ、歌おうよ。
イタタリで。
YouTuberデビューするかも。
スポーツファイで配信しよう。
嫌ですよ。バンザリちゃう。
今日はね、記事が多いんで。
そんなでもないけどな。
ここ最近が少なすぎて、ちょっと感覚バグってるけど。
バンザリ。
別に多くはないよ。
まあ、そりゃそうか。
でも、まあ、そうね。ぼちぼちな音量ですけど。
よし、テンション上がんねえ。
上げてこう。
声が晴れねえよ。
じゃあ、代わりに読んであげよう。
やったー。
1個目。
はい、メディアは何のメディアなんだろうな。
ユニーチスって読むのかな。
ユニーチス。
多分、IT系のメディアの記事なんですけど、
DDoS攻撃の概要
天気.jpのDDoS被害事例に学ぶ事業判断と対策フロー AWS Summit Japan 2025レポートという記事ですね。
タイトル通り、AWS Summit Japanの登壇なんですかね。
多分そうだね。
AWS製品の紹介も入ってるわけだしね。
内容としては、忘れたのかちょっと知らなかったかわかんないけど、
天気.jpが1月に大規模なDDoS攻撃を食らっていて。
全然知らなかったね。
ピークで60Gbpsぐらいの。
結構でかい。
かつ長く2週間ぐらいネチネチ攻撃されて、
割と2週間落ちたり復旧したり繰り返すような事件があったらしく。
それの対応の話とその反省を踏まえて、
AWS製品を入れて対策をしたよというのが超ざっくりのサマリーですね。
結構生々しさがあっていい記事、いい発表だったんだろうなと思っていて。
攻撃自体の傾向も詳しく書いてくれてるし、
それに対する対応プロセスみたいなところも割と書いてあって、
1日目とかもある種インフラ、
天気.jpってインフラと言っても差し支えない、
印象的に使えるサービスなんで、
それ落としてしまったみたいなところの焦りがあってみたいな話もあるし、
あとはビジネス判断みたいな話も書いていて、
具体的にビジネス側からどうとかっていうところまで言い切ってないのかなと思うんですけど、
ビジネス判断と対策
割と短期的にこうすればいいんじゃないかみたいなところが結果的には乗り越えられなくて、
中長期の投資っていうのをこういう時代に備えてやっておくべきだったよね。
その意思決定自体はビジネス判断、ビジネスサイトでも持ってもらって判断すべきだよねみたいなところも書いてあるって感じですかね。
言い訳しすぎ?
短期的にどうこうしようと思ったけどうまくいかなくて、
結局中長期も見据えた対応を取ることにして、
その中長期の対応の意思決定の中で今稼働中のものに容易に導入検証ができるっていうこととか、
継続的にそれを改善していくことができるエコシステムが存在するみたいな要件として、
選定ポイントとして入れていったよって。
それがAWSのサービスだったよっていう、ソリューションだったよって話じゃない?
平時に云々関連の話はしてないよ、多分。
そこまで言ってないか。
これ多分、障害対応中には中長期の話はしてないんじゃないかなって解釈したんだけど、どうなんだろう。
障害発生時であってもビジネスサイトは中期的に考えることが必要だから、
確かに平時だけじゃなくていう話であるのか。
多分、起きた時は2週間も続くかわかんなくて、
とりあえず、まず戻すみたいな視点でやってたけど、
まあいい訳するしかないな。
まず戻すっていうのをやってたけど、結局塞げなくて2週間続いた。
そうだね。
その反省を踏まえて、中長期的な教訓から、ここをどう解釈するかやな。
あるいは改めて中長期的な試験に立ち、まず必要な、
だから事後に中長期で考えて、ソリューションを考えたって話ですよね。
結局だから、インシデント発生から約1ヶ月で入れてるよって話だから、
だから2週間経って、塞げなくて困ったねって言って、
そこから2週間で塞いだってことでしょ。
そうだね。
まあでも確かにそういう意味でいくと、結構ようわからん話だな。
ようわからん話っていうのは?
ようわからん話。
中長期って何か…
中長期的な視点を持って考えることがどう解決に寄与したのかって、
全然語られてないよね。
下のほうの、どのセクションだっけ?
セキュリティ対策は余分なコスターの貢献みたいな。
読み取って実態が違ったらめっちゃ申し訳ないけど、
ある種、中長期どうなんだろうな。
これ多分さ、発表のまとめ方がさ、おかしいんじゃないの?
だってその、論理的にさ、構造がおかしいじゃん、全体的に。
そうかもね。
だから発表がそうなのか、このまとめの記事がそうなのかはちょっと分かんないな。
そうだね。確かにね。
ちょっと元ネタを、10日あんのかな、見たほうがいいかもね、もしかしたら。
まあこんなことがありましたね。
なんか、でも10日か、AWS入れるって決めて、
10日で本番環境の実装までたどり着いてるって書いてあって、
すごいいい時代になったなってしみじみ思ったら、
10日っすよ。自前でクラウドない時代にやろうと思ったら、超一大プロジェクトになるよな。
もともとAWSに載ってたのかな?
うーん、分からんすね。そこは言及がない気がする。
なかったよね。
まあ、構成的には、たぶんもともとAWSに載ってなくても使える構成になってる気がするから。
和風立てて、そこを通して、バジェットはそれで管理して、
で、ルールはクラウドフロントで。
ちょっとAWS詳しくないんで、間違ったらすまないけど。
ああ、クラウドフロントはそうか。CDの感想ね。
まあ、このAWSサミットだから言えない、しゃべれない、しゃべらないんだろうけど。
例えばクラウドフレアとかと比べてどうだったかとかちょっと気になるな。
全然DDoS対策技術戦で詳しくないけど。
まあ、でもなんか面白いっすね。
うーん、生々触ってよかったな。
またなんか、食らってこうしましたみたいな話あんま国内だと見かけたことがない気がするから。
企業で細かい話出してくるところってあんまりないかもね。
うーん、なんか1月だんだん思い出してきたけどあれだよね。
なんかいろいろ、アナとかも、JALかアナも食らってたんだよな。
日本全体的に食らってて。
なんだっけ、どっかから注意喚起が出るぐらいかな。
なるほど。
その流れだったのかな。
ああ、12月か。12月にJALが食らってたのか。
DDoS攻撃の影響
いや、なんかDDoSに興味がなかった。全然。
あとあれか、銀行系も食らってて。
天気JPもピュアログで書いてあるな。
何のキャンペーンだったんだろうね。
ん?
何のキャンペーンだったんだろう。
そうね、原因が結局わかってないんじゃないかな。
そんなにめっちゃちゃんと追ってるわけじゃないけど。
DDoSキモいのはここだよね。
日本のインフラというか、いまいち銀行とJALと天気JPっていう。
年越しと正月でハッピーになっちゃう。
はい、ぜひ読んでみてください。
じゃあ次も。
Devinのセキュリティ課題
運用して初めてわかったDevinのセキュリティ課題。
Devin Meetup Tokyo 2025のメルカリの方の発表スライドです。
詳しくは読んでくださいとしか言いようがないんだけど、どうでした?
めっちゃよくまとまってるなって思った。
自分が認識しているDevinを使う上での
普通に考えて危ないよねっていう部分もあれば
原理上きわきわまできちんと考えると
ここまでが危ないよねっていうのと
っていう部分で認識が一致してたなと。
それに対してだいぶ丁寧に
これはこう、これはこうみたいな。
書いてあったんでよかったのと
あとはその、何ページ目だっけな。
後半の
そうですね、26ページ。
違う、27ページだ。27ページの
インターネットとつながってる以上は
プロンプトインジェクションとかを成立しちゃうと
外に情報を持ち出せるみたいな話は
多分もうこのスライドの感じだと
リスク飲んでるのかなと思ってて。
なぜかというと対応する対策が書いてないから。
しかも原理上無理みたいな話が書いてある。
プロンプトで完全な制御できない。
そこはもうトレードオフを取るみたいな話がある。
そこはやっぱりそうなんだな。
Devinを使う限りは無理なんだろうね。
そうね。
Devinを使う限りというか
要はその、何て言ったらいいんだろう。
Vertex AIだっけ。
Vertex AIはモデルセルフホストする。
あれとかペットロックとか
ああいうのを上手いこと仕込めるような形で
Devin的なものを作れれば
色々やり余地はあるのかもしれないけど。
そうね。それで言うとクロードコードとかは
ホワイトリストで通信先管理できたりとか
Devinもちょっと僕は知らないけど
もしかしたら通信を切るとかできるのかもしれないけど
いずれにせよ多分トレードオフがあるし
ホワイトリストにしたところで多分
ゲットパラメータでバーって付けちゃうとかは
原理上あり得るよねとか。
こいつらってなんかGoogle検索するのかな。
どうなんだろうね。
Google検索するんだったら結構さ
もう無理じゃない。
まあ今々だとしないとは言えないよね。
アナリティクスとかでさ
普通に検索ワード経由でさ
何でも持ち出せたりするんじゃないの?
それもそうだし
プラントプットインジェクションのこと考えちゃうと
もう持ち出し放題なんじゃないかなって気はするね。
サイトだけ用意して叩かせればいいわけで。
でもそれはなんか接続先のさ
ホワイトリストとかで最悪絞れるじゃん。
でもGoogle検索はさせないといけないってなったらさ
アナリティクスとかで持ち出せちゃう。
ホワイトリスト管理するってことはもう
Google検索は
Google検索は使えないと困るよって
なっちゃわないのかな、どうなんだろうね。
どうだろうね。
まあそこは結構ポリシーとか考え方によるかもね。
なんかそのサイト内検索がないサイトを
ホワイトリストに入れたところでたどり着けんじゃんみたいな
Google検索を経由するとかちょっとあるかと思ったり
クロードコードどうなってんだろうな、それでいうと。
結構吉谷に
クローリングしまくってんのかな
回遊して見つけてんのかどうなんでしょうね。
あとなんかこの
ポリシーボットってやつは知らなかったね。
ポリシーボットの可能性
知らなかった。なんかセルフアプローブどうすりゃいいんだろうなって
結構思ってたんだけど、なんか普通にいいコンテンツだなと思った。
鈴木駿介さんが
これに特化したやつ作ってて
社内とかではそれ使おうかなとか
一部実は動いてるんですけど、思ってたよ。
で、何セルフアプローブみたいな
なんか前話したことあったけど
ここではどれか取り上げたかもね
これ関連記事何個かあって
紹介した記事の後にもちょっとアップデート入ってて
結構シンプルに使えるようになってて
ユースケース絞っ
セルフアプローブ絞るぐらいだったらこれでもいいかなっていう
ただこのポリシーボット気になったのは
結構複雑なポリシー識別法で良さそうだなと
全然中身掘れてないんだけど
ファイルの中身を見てとかできたら最高だなとは思うんだけど
ちょっとそこまでは確認できてない
これね
コードオーナーとかだと吸収できないユースケースみたいな
吸収できるならめちゃくちゃ良さそうだなとか
普通に便利そうな
知らないだけであるんだよな
これですね、パリレートPRレビューアクションっていうのがあって
参考になると
でもなんかセルフアプローブの問題ってさ
セルフではないけどリノベートのプリリックとかもさ
結構Botが作って承認してみたいな感じじゃん
そうだね
デビンの方が割と何でも書けるみたいなのがあるから
問題になるかは分かるけど
運用する前から分かるだろうとは思っちゃった
マジやぼな指摘だけど
運用し始めたから
まあ難しいところだね
メルカリだったら事前に元々ありそうな気もせんでもないけど
リノベートとかも
リノベートに限らずだけど
結局Bot経由で
GitHubの仕組みだとPRのオーサーしか見ないから
コミット詰めるって話はあるはずで
そうそうまさにその話がしたかった
デビン関係ないって話はある
だからきっとこのPolicyBotで
それもしたかったんじゃないかなと思ったけど
原理上は
そうだね
いやでもこれ良かった
最後の方のデビンへのリクエストの部分とかも結構いいなって思って
サインドコミットの話とかは完全にそうだよなって思う
だから一番最後の
ああそれそれ
リクエストね
いやでもねどうなんでしょうね
いや分かんないなんかすごくジャスリだけど
セキュリティ要件は
今は分かんない気がするんだよな
どこなんだ
AIエージェント戦争になってるから
どちらかというとデリバリーに効く
新機能に全力でやってんだろうなって
だからこそじゃん
結構差別化要因にできると思うんだけど
まあね
サインドコミットとかそんな難しいのかな
サインドコミットは
GitHub Appとしてサインドコミットしようとすると結構大変なのかな
いやそんなことない
別にAPIがあって確か難しくないはず
まあ難しくないというのは実装を知らないから言ってるだけです
デビンの実装的には難しいって話はあるかもしれないけど
でも別にデビン管理のVMで動いてるわけでしょ
そうだね
ややこしいとしたら
自分になり代わってPRを立てるっていうのができる
そういう時にコミット署名できないよねとか
どうするかとか思うんじゃあるかな
オーサーは自分だけど
サインドコミットは
でもその場合に何とかするんだったら
どうするのが正解か分からんけど
でも別に
自分になり代わってやるから
そういう場合はデビンから公開鍵を出してもらって
それを自分のアカウントに登録するわけでしょ
そうだね
でもそうしちゃうと自分の
サインドコミットを作れる権利を渡すっていうのはどうなんでしょう
みたいなところは
オースでうまいことやってくれる感はあるよな
まあね
まあでも
こんなユースケット想定できないよって感じな気もするのもないんだよな
でもそのコミットが
デビンがしたものですよっていうのが
ちゃんと担保できるようにしてくれよとは思うな普通に
今のオーサーの仕組みでもできるか
できるかできるか
できんのかできるか
クライアントIDとかは分かるはずだから
そのディポジトリのライト権限を持つだけの
トークンを引っ張って
サインするとか
分かんねえなあ
あんま詳しくない
俺たちが雰囲気でセキュリティをやってる
いやーこんな
やってらんねえっすよ1から10まで
まあでもよかった
そうだよねって気持ちと
ここまでちゃんとやりたいなって気持ちが
こうしたら悔しい気持ちになった感じかな
やっぱ1000人でチーム立てられるのいいなあ
強いなあ
ここまでちゃんとって言っても
ここまでちゃんとな
課題整理してそれぞれ対策を立てて
あるし当たり前のことなんだけど
STS作りましたみたいな話
まだ手の届きやすいところだ
どうなの
どうだろうな
スライドの消耗量
で見るとあれかも
これを実施するコストで見ちゃったりだけど
ここにたどり着くのは大変だと思って
これを片溜めでできるかと言われると
すごく時間かかるかなっていう
個人的な瞬間
これシェボットか知らんかったし
このAPI機の話ってここまでよく整理されて
あとGitHub Actionでやりましょうとか
なるほどなと思ったりもしたし
これは完全に僕は思いついてなかった
頭が回らんってこと
レビンに例えばサービス監督機器とかを
シークレットとして渡して
それをVM上で使うっていうのができるんですよ
でもそれやると
そのシークレットどう扱うかとかが
分かんないし
VM自体はレビン使う人だったら誰でも使えるから
広く共有される前提で置いとかなきゃいけない
だけど
GitHub Actionsの活用
その辺の連携とか認証が必要な場合は
GitHub Actionでやるようにしちゃえばいいじゃんっていう話
例えばデバッグとか
うちも多分ユースケースとしてあるんだけど
どうしてもビッグクエリと繋がないと
テストが実行できないみたいなものがあったときに
どっかで動かすビッグクエリに繋ぐ必要があって
それをレビン上でやると
SA機しか手段がないけど
そのテストは例えばGitHub Actions上でやれば
GitHub Actionsにできるよねとか
そういう話かなっていう
何でもかんでもそうすべきかは
扱う権限次第だと思うんだけど
実際には
デビンでやらなくて済むことはデビンじゃないってことでやれって話ね
そうそうそう
デビンのAPI自体はあるから
Actionsからデビンを叩くみたいなこともできるはずで
あるし
Google OSSリビルドツール
ワークフローディスパッチができれば
デビンがその結果を取ってくるってこともできるわけだもんね
そうそうそう
Actionsの実行権限も渡してるはずだから
なるほど
ワークフローディスパッチが
それを
ディスパッチできなくていいじゃんと思って
口をつきそうになったけど
無理ですね
時代的にそんなことは言えなくなって
クライムを叩きに行くだろうし
そこは置いといて
良い話ですね
そんな感じですか
あんだけでかい会社でも
とんでもないことをやってる
いやまさしく
こういう話が一番いいよ
次お願いします
Google Launches OSS Review to Expose Malicious Code in Widely Used Open Source Packages
っていうハッカーニュースの記事ですね
元ネタの方を貼ってるんで
読む人はそちらを
Googleオンラインセキュリティブログの方にあるんで
読んでくればって感じなんですけど
OSSリビルドっていう
ややこしいな
OSSリビルドっていう名前のOSSを公開しましたって話ですね
これが何かっていうと
世のオープンソースパッケージの
出元の検証 ビルドの検証っていうのを
行うためのメタデータを付与するための
豪華な 豪勢のツールを公開したよっていう話ですね
このツールが何をしてくれるかっていうと
既存の 既に自前でメンテしてる方もいると思うんですけど
世にパブリッシュされる
今サポートしてんのはなんだっけな
npmとpypyとlastのパッケージがあるものに対して
割とコマンド一つで
証明付きのメタデータを作れて
使う側は同じくコマンド一発で
それを検証することができるよっていうツールですね
なので 割とだいぶ前に紹介した
GitHubのアテステーションと同じようなものかなとは思っていて
コマンド一発で証明して それを検証できる
なので 具体的にどこまで検証できるのかは
ちょっと見れてないんですけど
あれかな 誰が検証したとか
もしかしたらパッケージごとに異なるのかもしれないですけど
ちょっとそこまでは読めてないのかな
その検証のキー 証明するキーとか検証のキー
どうなってんだろうなと思っていたんですけど
リードミー見てると 多分クラウドKMSで配置されるようになってて
かつパブリッククラウドKMSっていう表現がされてるんで
GitHubさんの Googleさんの財布ですかっていう感じなのか
もしくはこれを署名する人が
自分でGoogleクラウド用意してねって話なのか
ちょっとそこは追ってないんですけど
何せばパブリックアクセスできるKMSで その辺はやるらしい
AIコーディングエージェントのリスク
これ使う側 検証する側は無料アカウントでもいいから
Googleクラウドのアカウント認証が必要らしくて
そこはちょっと面倒だなって 率直に思ったって感じかな
個人的には思想はいいよねって思いつつ
今んとこはGitHubのアテステーションズのほうが 便利かなって感じかな
こっちのほうが
GitHubのカギどこにあるんだっけ
よく分かんなかったんだよね
誰の何のカギで署名してるのこれって
前に読んだときよく分かんなかったんだよね 確かに
確かにね 言われてみればどうなってんだろうね
GitHubがやってくれてるのかな
GitHub アテステーションズの検証がGHコマンドでできる
内部的にはAPIで叩いてるはず
だからGitHub側で管理してんじゃないかなって
素直に考えると
一回触ってみると分からんな
署名するのやったことないんだよな
署名を検証するっていうのは 社内でも実は動いていて
まずGHアテステーションが付いてるような ライブラリがまだまだ多くないんだけど
GHA Lintとかは付いてるから 一応使う前に検証して
鈴木俊介さんのリポジトリでビルドされたやつって 担保したりして
そうだね キー
キーの話は書いてない でも探せばあるのかな
なので今後に期待なのかな
流行らないと流行らない系だよなとは思うし
あとパッケージをホスティングする側に これをやるメリットみたいなのは
それはアテステーションズも全く同じ話なんだけど
インセンティブがあるかみたいなとこは 結構気になるな
もしかしたらNPMコマンドとかが
この署名サポートして裏側はこいつが動いてるよとか
そういう世界とかはあり得るかもなと思うけど
結構意識高いコントリビューターじゃないと まだまだなのかな
その辺はちょっと実態気になるな 今ふと思ったけど
使っていこう
うん 確かにね 自分が使っていくのも間違いなくありすね
でもリードミー見る限りは かなり使いやすくしてくれてるんじゃないかなって気はするんで
あれかな 署名の内容 検証の内容は多分
そのプリントできるようになってるから
それ見て自前で検証みたいなの書けるのかもね もしかしたら
いやでもな まあいいや
そんな感じっす
もうテンション上がりすぎるわ
僕がテンション上げてあげようは無理だな
僕 中和するぐらいテンション高くいくわ じゃあ
そんなことできるんですか
まあ 頑張りますよ
いやなんか今日普通に朝から会社行っててさ
朝早かったんだよ
おねむな
画面社会人みたいで言い訳やめよ
いやまじおねむなんだよ普通に
いいよ じゃあ読んであげよう
いいよいいよ読むよ
フリーにおけるAIコーディングエージェント 前者導入とセキュリティリスク
デビン・カーソル・クライン 前者導入 セキュリティリスクにどう対策した
っていうイベントがあって
それでフリーさんの控えさんっていう方が発表してた
なんか結構このPodcastでもフリーの
コーディングエージェント周りの
ブログ記事って取り扱ってきたと思うんだけど
割とブログで触れてない話も多かったので
初出の話が結構あったかな
で なんか割とまとめのスライドとしてもよくできたし
結構その一つ一つのリスクの目線とかが
改めて我々と近いなっていう風に思って
真剣に考えて聞けた感じです
とても良かった
とても良かったね
なんか結構なるほどねと思ったところで言うと
ブログ記事を通して全部のモデルにアクセスすると
社内の使用状況がなんとなく分かるっていう話とか
要は何がトレンドなのかみたいな話とか
あとはガードレールのポリシー違反をスラッグ通知するようにして
なんか変なものをローカルで実行しようとしたらすぐ分かるみたいな話とか
あとはちょっとちゃんと理解はしきれてないんだけど
モードで変わるMCPサーバーの話
23ページあたりかな
が結構面白くて興味深い
面白いねこれ
これ実現できるのさすがだよな
実導入とかも含めてなんかこの細かい話をここまで
開示できる状態まで持ってきてるのがまずすごいなって
やってるのもすごいな
ただこんだけやっててもAIトックみたいなのが
一応境目として存在してるっていうのは
そこはちょっと気になったところで
トック以外でこれを導入しようと思ったときに
何がハードルになってるのかみたいなところは聞けなかったけど
気になってるところである
前のブログ記事のところで言うと
新しく試したいものがトックで
いろいろ明らかにして
でどうこのスライドで言うと
歩道と車道どう分けられるのかみたいな
話を詰めていくって感じなのかなっていう気はするけど
だから一定そのトックみたいなところもさ
検証環境としての有用性みたいなのがないといけない
あーそうね
どういうその基準でトックというのか
要は何を持ってトックと認定してるのかなみたいな
安全な環境っていうところだねこれで言うと
どうなんでしょうね
じゃあトックとそれ以外の割合ってどんなもんなのとか
そういうところはちょっと気になったところかな
それこそこのモード
情報レベル定義で言うとこの
例えばAはトックでは絶対触っちゃダメだとか
そういうのがあったりするのかな
一つありそうな線引きとしては
またスコープをめっちゃ絞りとか
個人的にはこの14ページのやつとかは
いやーこういうのちゃんとやるべきだよなって気持ちになったな
っていうのとちゃんとやれるのが素晴らしいなと
このAIポリシー
キャプチャーにはGitHubのGitHubのCPServeの
AIポリシーが書いてあるんだけど
全操作に対してOKNG
みたいな部分をちゃんと全部定義してる
これ偉すぎる
ここまでやれればなんというか
コントロールできてるねっていう
気持ちになれるというか割と言える
ある程度自信持って言えるよね
うちはやれるだけのことをやってます
言えそうな気がするしこんだけやってれば
実際どう思ってるのかとかは分からないけれども
いいな
こういう知見で始めたのすごいいいな
今日だってメルカリートワースで2つ目だもんね
でもちょっと団地だよなフリーのこれは
先だってまだ
店やワイン屋し始めて
2月3月ぐらいから
爆発的に流行り始めて半年でここまで来れてる
一貫して25ページのスタンスとかもめっちゃいいですね
AI使えない環境にするってこと自体がリスクだから
そこのバランス感は
いやーマジでちょっと
頑張りたいね
そうだね
セキュリティだけじゃないんだけどもちろん
セキュリティに限らずいろんな
セキュリティに限らずいろんな
セキュリティに限らずいろんなものの積み重ねで
今があるっていう前提はありつつも
どうしても
NOと言わなきゃいけないケースっていうのが
やっぱりあるわけで
これ誰かと話なんだけど
会社としての魅力も損なうよね
そう思うよ
社内の
誰かと?
ソータと話してたんだっけ?
その場にいたか忘れたけど
名前出すとあれなんですけど
データ基盤チームの人と話してたのは
使えないイコールキャリア上のリスクになる
まさにまったく同じ話だね
言ったんじゃないかな
別にAI使えないから退職するとまでは言わないけど
正確に
いるメンバーにとってもネガティブだし
入るメンバーにとってもネガティブになり得るよね
こんだけ
パラレルのシフトになると
逃げずに向き合っていきたいですね
今日は眠いから明日からやるよ
はい
じゃあ次いきますか
M365アカウント侵害時の対応
M365アカウント侵害時の初動対応
伊藤中サイバー&インテリジェンス株式会社さんの
何の何なのか全然わからないんだけど
何の何なのかわからないけど
のスライドです
何だろうね確かに
何の何なんだろう
これはどういうやつですか
テンション上げて教えてください
覚えてねえ
言われてから時間が経ち過ぎて覚えてないんだけど
じゃあ僕さっき読んだんで
タイトル通りではある
MS365
M365なのか
マイクロソフト365のアカウントが侵害された時に
何をしなきゃいけないか
これなんか結構
面白くて多分このスライドそのまんま
インシデントレスポンスの手順書になるような構成になっていて
かなり具体的に色々書いてある
一つは単純にインシデントレスポンスとして
どういうプロセスを踏まなきゃいけないかって話があって
誰を巻き込んで
誰にヒアリングをしてどういう優先順位で対応していくか
みたいな部分が書いてあって
ラーナーページのやつとか
ヒアリングしてアクセス経路
攻撃者からのアクセス経路を塞ぎ書籍を保存し
引き継ぎ注意喚起をしていきましょうみたいな順序が書いてあったり
それぞれのステップの詳しく書いてあったりとか
対応がめっちゃ詳しく書いてあって
使ってないんで知らんかったってやつがすごいあるんですけど
パスワードリセットセッション取り消しあてりは
分かるって感じなんだけど
攻撃者が二要素認証で別の手段を登録しておいて
回復してくるケースとかもあるから
それもないかっていうのを確認して削除しましょうとか
これもあるって感じなんだけど
アプリパスワードみたいな概念が多分あって
これ悪用してるみたいな記事見たんですけど
MS365の概念のはずで
APIキーみたいなものなのかな
これとかは確認して消さなきゃダメだよとか
あとメール これはなるほどなと思ったけど
メール転送みたいなのを設定して情報を抜くみたいなのが
あるみたいなのもあるから
転送ルール 民に覚えのない転送ルールが増えてないかを
確認しましょうとか
これでも現状復帰しんどいね
一旦更新したい気持ちが出てくるな
そうね
ゲストアカウントみたいなの すごい多いんだよ
これ思ったのは
うちはGoogleワークスペースIDで使ってるけど
結構転用できる考え方が多いなと思ってて
Gmailで転送仕込むとかもありそうだし
エントラIDもそうだけど
1個アカウント盗めた時に触れるサービスが多すぎる
ストレージも触れる
メールも触れる
コミュニケーションツールも触れるのかなとか
なんで結構対応が幅広くなるっていう部分は
このIDP系は共通してありそうかもな
っていうのとか
またその証拠保全みたいなとこで
ここでこのログ取れるよみたいなのもかなり
これいいよね これ超便利だな
普通にチートシートとして手元に持っておきたい
そんなことを思ったのができたんですよ
読んだら読み忘れちゃう
あとは耳が痛いなと思ったのは
どっかのツールに書いてあったんだけど
普段からちゃんとやっとかないとこれ無理なんで
ちゃんとやっといてねみたいなのが書いてあって
分かるって気持ちと
これをやる体力
こうする体力はなかなかだよなって思った
でもなんか
普段からやっとくが無理なら
何かのタイミングでドキュメントに書き起こしておく
書き残しておくみたいな話になるのかな
って思うんだけど
結構めんどくさがらずにやらなきゃいけないよね
っていうだけの話のような気もするし
そうね
絶対に仕事をしないとやっぱダメなんだね
っていう話になるかな
盗まれたらかなりクリティカルなものではあるから
そういう意味でも
やるべきではあるっていう感じがね
このログとか
最近Google Earth Spacesの監査ログとか見始めて思うけど
触らんとやっぱ分かんない癖とか
集まりポイントみたいな
多分画面見て満足したらマジでダメだなというか
画面見てこんな検索できるんだ
じゃあ大丈夫だねじゃなくて検索してみて
意外と欲しい情報ねえみたいなのが普通だから
特にGoogleのサービスとか
欲しい情報を欲しい検索の方法で検索できないっていうのも結構ある
ドライブの監査ログが完全にそれだったんだよな
メルカリで触った時に
大変だったんだよ
別にインシデント対応とかじゃなかったんだけど
どっちかというと
動作検証みたいなあれで触ってたんだけど
大変だったんだよ
あれこれこっちの検索だとこれ出せるけど
こっちの実際に使いたい検索の手段が使えるこっちと
これ出てこないじゃんみたいな
分かりそう
地道になっていくしかないね
大変勉強になる
これのGitHub版とか書きたいな
ふと思ったけど
ないのかな
公式ドキュメントはね
全然参考にならなくて
ペイルドさえ分かんないんですよ
フィールドJSON形式で吐き出してくれるんですけど
フィールドさえドキュメンティッドじゃないから
今だと自分で調べるしかなくて
そういうノウハウの記事はもしかしたら出てるかも
CISベンチマークみたいなやつの
延長線上でこういうところも
触れられると良さそうだな
確かにね
ちょっと待って
調べたら僕が書いた会社ブログの
GitHubの監査ログの記事が3番目に出て
それはダメじゃねと思ってプライベートウィンドウで検索したが
プライベートウィンドウで検索しても3番目に出てきた
素晴らしいおめでとうございます3番目の男や
GitHub監査ログ
大事
いいな ちゃんと僕もアウトプットして
GitHub版を作ろう今決意した
どこで発表するの
発表でもいいしブログでもいいけど
発表してもいいかもね
良かったぜひ手元に一冊皆さん置いておいてください
よし最後
最後じゃない
もう一個だけ残ってます
シャドウドームのセキュリティ
シャドウドームとセキュリティ
ガリット掛けの境界を探る
渋谷XSテックトーク13回の
稲川さんの発表のスライドですね
ちょっとタイムラグがあって出てきた感じ
どうでしたか
丸投げなんだけど
読んでね以外のことを言うつもりはこれに関してはなくて
でも
趣旨としてはあれだよね
タイトルからは最初読み取れなかった
シャドウドーム自体が
僕もシャドウドーム触ったことないし
忘れてたんでその復讐も兼ねてぐらい気持ちを読んだんですけど
シャドウドーム自体はある種のスコープトな
コンポーネントというかHTMLの
名前通りドームみたいな
シャドウドームの世界とシャドウドームの外側の世界みたいなのが
あった時に外側の世界からシャドウドームの内部に
アクセスできないような思想では作られてる
けどじゃあなんかサンドボックス的に
何かを守るものとして使えるんだっけみたいな
話をツラツラと書いてくれた感じ
他の人が見つけた
抜け穴みたいなのもいくつか紹介してて
例えば何だっけな
普通にシャドウドーム作ってそこに何か文字列入れて
普通のまともなAPI系では取れないんだけど
何だっけな
あれか参照を取るようなAPIなんだっけ
ファインドじゃなかった?一番最初に出てきた
ファインドかそう
ファインドとかだと実は抜けちゃうよみたいな
細かい穴がいくつかあって
いろいろまとめてくれてて
実際に
じゃあこうだったら守れるんじゃないみたいなのも
いろいろ検証したけど結論これをサンドボックスとして
使うのは無理だしそもそも何か作られた想定として
セキュリティ機構として作られてないから
もし穴があってもバグだよねで済まされて直されない可能性もあるから
そういうものではいいですよっていう結論って感じかな
でも読むものとして面白いっていうのは
マジであったなあんなっていうのはめちゃくちゃ思ってて
やっぱなんか思うけど
ウェブの面白さがやっぱ会話見える
なんか金沢さんの
なんか仮にそういうものじゃないけど
じゃあサンドボックスとしてシャドウボムを
作ろうって思った時に不可能だなって
しみじみ思わされたなっていう
なんていうか
あるAPIに対して
防御しきるっていうのは多分無理だろうなって思うし
ブラウザごとに
Chromeだと刺さんないけどFirefoxだと刺さるみたいな紹介もあって
もうこんなん多分やってられんよなとか
要を見つけてくるなっていうのもあるんだけど
要を見つけてくるな本当に
やっぱなんかもうアーキテクチャとして
同じプロセス同じレンダラーの中の世界で
区切るみたいなのがそもそも無理だよねみたいな
のがふわっとどっかで書いてあったのかな
なんで
本当にちゃんとアイソレーションするのは
そういうレベルでやっていかないとっていう
そうしてちょっと半端な機能なのかな
元々何をその意図して何のために生えたの
そうね
なんか有識者を呼びたい
前にもちょっと話してたけど
いまいちね僕がフロントエンドそこそこ刺した時期は
いまいち
いいものだろうけどシャドウドームをわざわざ使う理由は
なかなか見出せんかったな
スコプトシーセスぐらいしか思いつかなかったな
って感じかな
またWebコンポーネントね
純正のWebコンポーネント
わざわざ使う
流行ってないってことはそういうことなのかな
個人的には
でも仕様として生きてるってことはあれなのかもしれない
消せないじゃん
動いちゃってるだろうからね
それも含めてWebのあれだけど
マジググっても全然事例
ちゃんとググり方が悪いのかもしれないけど
触ってみた記事しか出てこない
最後はね
これすごいね
軽く
ブリピンコンピューターの記事ですね
タイトル通りなんですけど
イギリスの法案計画
イギリスの政府が
法案を計画中でどういう法案かというと
ランサムな攻撃にあったときに
身の使用金を要求されるんですけど
その身の使用金を支払うことを法律で禁止するということを検討した記事ですね
一応グラデーションはあって
重要インフラとか公共機関は明確に禁止
払うことは違法っていう
それ以外の民間の
それ以外としての民間セクターとかも
禁止はしないんだけど必ず報告はする
っていうような縛りを
適用する法案を実案中って感じですね
法律の影響と課題
計画中なんで
それ以上しゃべることはないっちゃないんですけど
結構
実現したらどうなるだろうなっていうのは気になりつつ
自分がランサムギャング目線だったら
法律家じゃないんで適当なこと言ってるかもしれないけど
法律ってやっぱ
何だろうな
個人情報保護周りとかで見てて思うけど
ある程度実態の解釈に
委ねざるを得ない部分とかを
多分抽象度上げて定義してるみたいな部分があるんです
この法律作ってた時に
ランサムギャングって何なのかとか
サイバー攻撃とは何なのかとか身の使用金って何なのかみたいな
されたらされたで悪さする目線は
それをフィルターして
僕らにお金払っても違法にならないよっていうスキームを
考えるんだろうなとか思いつつ
そんなことできるのか成立しないと分からないけど
っていう感じで妄想したりしてました
別記事ではロシアに資金が流入するのを防ぎたい
っていう背景があるっていうのを見て
これは公式の見解かどうかわかんないんで
参考程度にっていう感じですけど
そういう知性学的なところももしかしたら
ありそうっていう話ですかね
どこどこの株を買えみたいな落とし方があるか
あー面白い
いいね
それでいこう
法律としてどういう話なのか分からないね
どう縛るんだろうなっていうの結構シンプルに
多分数としては減らないと思うんだよね
イギリスだけこれやっても
そうだね
そんな気はする
むしろ放置されるだけ
どうせ払わんのでしょうって知らんわ
そういう扱いをされるだけでしょ
攻撃できた側できた側で別に
美味しくないしみたいな感じになりかねない
だから狙わないっていう世界が
成立するのかどうか正直わかんないけど
今の時点では
面白いね
試みとしては続報が出たら見ときたい
という気持ちで取り上げました
そんなところですか
はい
マジで
マジ眠いな今日
本当に46回の中で
一番眠そうだと思う
今にも消えそうな声で
本当に眠い
一日の中の
コンテキストスイッチがすごいことになってて
そう思うよ
ぐっすり寝ましょう
お疲れ様でした
こんな感じで
来週は元気なヤギ足に
出会えることを願って
願っていてください
来週もっと眠そうだ
そんな感じで
皆さん次回もお楽しみにしていてください
大丈夫ですか
おやすみなさい
