#13 QAとセキュリティの親和性が高い説を強く唱えたいの回

ポッドキャストのイントロダクション

こんばんは、Replay.fm第13回です。

こんばんは。

調子はいかがですか?

今週は疲れましたね。

今週は疲れてねって話を、

20分ぐらいしたね。

この収録前に。

喉あっためがてらね。

喉あっためがてら。

いやー、マジ疲れたよ。

いや、やだなー、こんな疲れましたねって始まるポッドキャスト。

まあ、主役だしね。

こっちの成果だよってみんな思ってるよ。

まあ、でも本当に疲れてる人はこのポッドキャスト聞かないと思う。

本当に疲れてる人はこんなもの聞いてないで、

風呂入って寝たほうがいいと思うんで。

まあ、確かに。

これ聞いてて疲れてる人は、携帯を再生中のままベッドに置いてお風呂に行ってください。

セキュリティ対応組織の教科書の内容

そうだね。

じゃあお願いします。

なるべく癒しサウンドで頑張っていける。

いやー、あの、前回あれ、なんか過去読んだ記事の掘り下げました、報告しますって話したじゃないですか。

はいはい。

やってきたんですよ。やってきたっていうか。

すごい。

すごいでしょ。

うん。

有言実行を目指したんですけど、

まあ、あの、なんです、まあでもなんかもう本筋じゃないんで、まあすごいサクッと売れるんですけど。

いや、待って待って、この前のこの機能ってどういう機能なんですか?

僕全然使ってなくて。

全然今スクラップの画面を表示してるんですけど。

あ、スクラップっていうのがあるんだ。

そう、なんかスクラップと記事っていうのがあって、スクラップはね、なんか、なんだろうね、あの、記事を作るっていうよりかはポツポツね、一個一個コメントを投稿していけるっていうただそれだけですね。

やべえ、ちょっと俺向きかもしれない。

あ、ほんと?

そう、だから結構ね、みんな作業ログとかに使ってると思う。なんかトラブルシューティングとかでバーってログ残して、でそれがそのまま公開した記事になるし。

あと俺使ったことないけど、他のユーザーに許可、投稿許可ってやつもあるから、まあ、なんていうか、まあこれはちょっとわかんない。俺は使ったことない。

そう、まあなんで僕は結構これ読書とかに、最近たまに使ってて、昔とかも。

めっちゃ読書に使えそう。クソ便利。

そう、いいんすよ。雑説してるっていうか、メモをやめてるやつとかもあるんですけど。

まあでもなんか記事じゃないっていう意味では結構気軽に使えるし、別にね、って感じなんですけど。

うん、登録したわ。

お、ぜひぜひ。

でこれ、第何回で読んだか忘れたんですけど、セキュリティ対応組織の教科書の3.2番が出ましたっていう話を多分どっかでしたと思ってて。

で、まあ読みたいっすねって言いながら、その中身までは読んでなかったんですけど、読んできましたってやつで。

これ、まあ納書に貼っとくかな、貼っとこうかなって感じなんですけど、結論結構良かったなっていう気がしていて。

何が良かったかっていうと、僕なんかこれ読む前から、実はなんかこれがよく参照してるX1060っていうガイドラインがあって、セキュリティフレームワークみたいなのがあって、

でこれは何かっていうと、セキュリティ対応組織って表現をこのガイドラインでしているんだけど、

X1060の中ではCDC、サイバーディフェンスセンターって表記がされてて、このサイバーディフェンスセンターが持つべき機能みたいなのが、

例えばインシデントリスポンスみたいなカテゴリーがあって、その中に具体的にこういうサービスっていう呼び方をしてるんだけど、

要するに組織としてこういう能力を持つべきみたいなものが、

ガーッとカテゴリーとその中のサービス複数って感じで、64個とかだっけな、定義されてるものがあって、

で、それがあって、このセキュリティ対応組織の教科書は、カテゴリーみたいのがあるのは分かったんだけど、

じゃあそれを現実問題、あなたの働く組織でどういうふうに適応していけばいいかっていうところを、

定義に解説してくれてるのがこのセキュリティ対応組織の教科書だったっていう感じですね。

僕は先に、こういうカテゴリーがあって、こういう機能を持てばいいよっていう方を先に読んじゃったんで、

どういうふうに使えばいいかというのがいまいち分かんなかったんだけど、

こっちも読むと、こういうとこから手をつけていきましょうとか、またこういうライフサイクルでやっていくといいですよみたいなのが結構具体的に書いてあって、

なかなかいいですねって思いましたって感じですね。

具体的なとこ触れだすと30分使っちゃうんで結構。

読んでくださいって感じですね。

ぜひ結構お勧めだなと思いました。

セキュリティどこからやろうかなとか、自分たちがやってる取り組みがいまいちプロセス化できてないというか、

っていうような人たちには結構嬉しいんじゃないかなと思ったし、

僕はちょっと仕事で活用してみようかなと思いましたって感じですね。

あと何か個人的に。

組織のセキュリティ機能の重要性

ノーソンにも。

ノーソンに入れときました。

ありがとうございます。

個人的にちょっと面白受けると思ったのは、

セキュリティ対応組織の要因数みたいな項目があって、

具体的にこういう、それこそさっき言ったカテゴリとサービスで、

この領域はこれぐらいの成熟度、この領域はこれぐらいの成熟度、この領域はサポートしないみたいなパターンだとこれぐらい人数欲しいよねみたいな、

具体例がサンプルとして書いてあるんだけど。

そうそうそうそう。

これなんか個人的にめっちゃいいなと思ったのは、

組織の人数に対してこうじゃなくて、

組織がこういう機能を持ちたいんだったらこの人数必要ですっていう表現になってて、

それが個人的には結構、それはそうだよなって思ったというか、

現実世界はやっぱ難しいじゃないですか。

分かんないけど、50人の組織で4人セキュリティチームに当てますなんて、

よほどセキュリティ厳しい事業とかじゃないとできないと思うんだけど、

そういう考え方も確かに大事なんだけど、

自分たちが持ちたいセキュリティ機能がなんだっけって思った時に、

実際これぐらいは必要になっちゃうよねみたいなところで考えて、

じゃあそのギャップどうするんだっけみたいな感じで考えていくのも大事かもなってちょっと思ったりした感じですね。

一時対応って何か?

これはインシデントレスポンスとかアラート対応かな。

結構そのシーサーとSOCみたいな表現がよくこのガイドラインの中では出てくるんで、

その辺をちょっと意識してる部分が多いんですけど、

一時対応は僕がこのちょっとメモには書いてないんだけど、中には書いてあったかな。

ガイドラインの方を読めばわかるはずって感じですね。

結構これもあくまでこの領域でみたいな感じの立て付けであるって感じですね。

ここの例では4レベルで分かれてるんですけど、最高レベルだと26人の人員が必要らしくて大変だなって。

フォレンジックとかも自分たちでやりますとかそういうレベル感だから、

まあまあ結構大企業なのかなと思いますけど。

ぜひ読んでください。

私からのプレゼンは以上です。

これでも技術開発。

要因のモデルのこのモデルケースが。

技術開発日勤1名って現実回らんよなと思って。

書いてレビューしての相手がもういないじゃんね。

そうだね、そうだね。

それはそう。

まあなんかある程度なんていうか、技術開発って表現もだいぶ曖昧ではあるんで。

そうね。

それでいうともう一つめっちゃ分かったなって思ったのが、

さっき言ったこのカテゴリとこういう機能って定義がある方のフレームワークでは言及がなかったんですけど、

その組織によって、うちの組織ではこういう機能がフレームワークには定義されてないけど必要だよねみたいな、

カスタマイザーは必要に応じてやった方がいいみたいなことが書いてあって。

なんか、なんでしょうね、

カテゴリ、これかな、これが多分一覧に、

これはマトリックスにまとまっちゃってますけど、一覧になった時に、

ここにないけどやりたいことみたいなのは普通に独自に定義しちゃっていいみたいな言及があって、

これもあくまで一つのフレームに当てはめたって話であるから、

結構柔軟に考えていいんだなーっていうのは思ったりはしましたって感じですかね。

興味深い。

そうね、9つのカテゴリと64のサービス。

1回ね、業務でこの9つのカテゴリと64のサービスで自社の今のレベルを照らし合わせてスナップショット的に評価したんですけど、

次どうしようみたいな感じになっちゃったりしたんで。

まあその、そうだね、意味がないわけではなかったけど、

サイクロどう回していくかみたいなイメージはこれを読むことでかなり交換されるんじゃないかなと思います。

いやー、いいっすね、この深掘りシリーズ。

なんか、俺もなんかやるか。

うん、ぜひやって。

このスクラップにしてまとめといてもらえればそのまんまこのノーションに乗っけとくことができるから。

あー、確かにね。確かに。

作ってそのまま積んどけばいいね。

そうだね、そうだね。

じゃあ、好評のシリーズということで、無理なアイディアありますか。

はい、思いついたベースで。

なんか別に本読みましたとかでもいいわけだもんね。

あー、そうだね、確かに。

全然過去記事じゃなくても。

なんていうかね、この記事のライフサイクルに乗ってこないけど、読みたいものとかってたまにあったりするから。

それを自分でまとめ直して、タイムリーな記事にしてっていう。

そうね。

若干のポンプ効果があるけど、そうそうそうそう。

確かに確かに。

あ、そういうたてつけでいいか。

あ、それにいきましょうか。

まさにそんな感じだね。

なるほどね、なるほどね。

強制浮上じゃないけど。

著者が、著者が登場してくるパターンな感じになっちゃうけど、まあいいんじゃない、なんか面白いじゃん。

めっちゃいいね。

よし、じゃあそれじゃあお願いします。

はい。

はい、じゃあ積んどいた記事も上から順に言いますか。

今日はそこそこ大量かな、そこそこ大量だと思うんで。

そうですね、アドベントカレンダーがと言いつつ、そんなにアドベントカレンダーの記事ないよね。

そんなこともない。

まあまああるな。

5、6記事ぐらいはアドベントカレンダーなんじゃないかな。

なんか結構難しいのが、特定のテーマで同じ人がやってるようなものって1個の記事の濃さがどうしても薄くなってるパターンが多くって。

あー。

バラバラにいろんな人が書いてるやつは全然いいんだけど、

テーマは面白いんだけど紹介するか迷うなみたいなのが結構。

なるほどね。

そういうのはなんかうまくまとめちゃってもいいかもね。

そうだね、前も話したけど最後にこのアドベントカレンダーが面白かったっていう、なんか別に1個1個は紹介しなかったけどみたいな。

三谷さんのあれとかね。

そうだね、間違いない。

じゃあやりますか。

1個目がグーグルに帝国解体の危機、米司法省がクローム売却も要求っていう記事ですね。

前々回も一応このグーグルの反トラスト法だっけ、日本でいう独占禁止法絡みの話題を紹介したんですが、

日本語の記事でより細かくどういう話なんだよっていうのを紹介してくれる記事が出てきたのであげてます。

特にうわーっと思ったのが、グーグルはAppleやModulaといった企業に対してブラウザやデバイスのデフォルトの検索エンジンに設定する費用を支払っている。

司法省はこの支払いを提出するよう求めているっていう部分ですね。

まあこれなんかXでも結構話題になってたんだけど、この評判。

まあAppleはいいにしてもModulaに対してのその支払いが止まるって普通にModulaが死にかかれないよねみたいな話になっていて、

うーん、なんかうーんってなってる。

いやー、これじゃあうち側って言ってマイクロソフトが支払ったらどうなるんだろうね。また怒られるのかな。

うーん、怒られるかもしれないけど、まあでも中国企業とかがそういう話も話題に出てるのと、

結局あとはなんかちょっとそれはちゃうやろっていうのはなんかXでいくつか見かけたんだけど、

別にOSSなんだからなんか誰かがフォークして続ければいいだけなんじゃないのみたいな、OSSってそういうもんじゃみたいなのを言ってる人がいたんだけど、

Modulaってそういう機能じゃないので、そのFivefox単体で見ればそうかもしれないけど、

Web標準っていう意味でいくと全然果たして役割がもっと大きなものだから、なんかそういう話じゃないんだよなみたいなのは。

そうだね。

だってMDN消えるんですよ。

いやー、えぐいよね。

そう考えると国はめちゃくちゃ困るよ。

RFCとW3Cの韓国を毎回全部読んでくださいって言われるの結構しんどいと思うんだよね。

どうなんだろうな。一応さ、ポケットと連携したりとか、

あと半年前くらいだっけ、ダークウェイブのあなたは個人情報を消しますみたいなサービスをアメリカだけだけど展開してたりとか、

微妙にビジネスはやってるものの、

じゃあなんかそれだけで食っていけんのかとか全然知らないんですけど、

まあでもその、このGoogleからの収入の割合が小さくないのは容易に推測ができるから、ちょっとねーっていう、

結構Googleだけに収まんない話ですね。

そうだね、しかも世の中全てがChromiumフェースのプログラマーになるのって、

結局Chromeを売却したとしても、実質的にChrome持ってる、Chromeを売却した先が、

ウェブの業界そのものをそのある種独占する状態になっちゃうのは間違いなくて、むしろそれを止めることによって。

そうだね。

これなんか一個個人的に気になったのが、要求項目としてデータの開示と共有みたいな、具体的に何のデータかちょっと記事だけだとわからなかったんだけど、

これ他のブラウザベンダーやってんのかなっていうのはちょっと気になったりはしたな。

なんか理由があってChromeだけやれって話なのか、何のデータの開示なんだろうと思ったりしたんだけど。

これか、そうだね。競争相手との公平な競争環境を構築するために十分なデータを開示し、

検索結果か、検索結果をMicrosoft、OpenAI、DuckDuckGo、Braveなどに提供する必要がある。

これはGoogleの膨大な検索データを競合オッター社に共有することを意味する。

これは意味わかんないけどね。

そう、なんか。

それは意味がわかんないけど。

それは、何、でも絶対今さ、Microsoftも今名前挙げた記事を出してるわけないから何が公平なんだと思ったけど。

まあ、そうだね、個人的に。

ていうかGoogleだけいっぱい持ってるでしょって思ってるだけなんじゃないの、これって。

あー、なるほどね。偏りがあるでしょって言いたいのか。

うん。

まあ、確かに。

そうだね。

でも、なんか、どうなんだろうね。

しかも検索って別にChrome関係ないしな。

いや、関係あんのか。

なんかいろいろ、いやー。

いや、なんかいろんなもの絡めてる話じゃあるんだけど。

そっかそっか、確かに検索。

ブラウザと検索をセットでやってんの、セットで抑えに行くのってよくないよねっていうのは多分言ってるんだと思っていて。

うん。

いやー。

まあ、いやー。

頑張ってほしいな。

うん。

コインハイバーの時みたいに間髪乗られたら。

でも、金で解決できるわけじゃないんだよな。

うん。

でも、おもじらえの寄付はできるんじゃない?

あー、確かにね。確かに。

それはありかもね。

引き続きどうこう見たいっすね。

うん。

いやー、おもじらえの寄付はやるか。

ね。

ちょっと今やりますわ。

あー。

ちょっとページを貼り付けてみてください。

え、どこに?どこに?

おもじらファンデーションの寄付。

はい、ちょっとモーションに、はい。

あー、DONATE NOW、へー。

見つけました。

あー、ありがとうございます。

僕も寄付しております。

はい、皆さんも。

あー、住所の入力が大変やな、ちょっと。

収録後にやろ。

うん。

はい。

次いきますか。

いきますか。

ほい。

Generative AIのセキュリティ業務への活用

ポンポン言っちゃうぞ。

えーっと、僕が読んだ記事なので、

えー、エダルセリーイベント2024のレポート記事で、

で、これと他にもう一つあるんですけど、

もう一つですね、今日紹介するのはもう一つあるんですけど、

上梨さんの技術ブログの記事で、

えーっと、タイトルが

Generative AIを利用したこれからのセキュリティ対策に

足を踏み入れてみたっていうような記事です。

で、まあ、サマリーとしては、あのー、

記事タイトルを拾ったわけじゃないですけど、

ChatGPTのサマリーを、まあ、別に貼り付けてるんですけど、

まあ、Generative AIをセキュリティ業務でどう使うかみたいな

セッションがあって、

それの紹介をされていましたっていうところです。

で、まあ、具体的なユースケースが2つ紹介されていて、

まあ、AWSのカンパネさんで、

AWSで使うときって話なんですけど、

まあ、一つが、まあ、これは割と個人的に

結構見るかなと思うんですけど、

えーっと、AWSセキュリティハブ、

まあ、CSPM的なものだと僕は理解してるんですけど、

まあ、それで検出された結果を要約するっていうのと、

えーっと、どういうアクションを取るかっていうのを

提案してもらうっていうのを、

セキュリティAIを使ってやるっていうところの

デモが紹介されたよっていうところと、

あともう一つが個人的に、

なんか、あーなるほどって思ったんですけど、

まあ、セキュリティチャットボットっていうのを作って

社内で活用するっていう事例が紹介されていて、

まあ、その社内と、

会社が大きければ大きいほど、

どうしてもセキュリティ規定とかポリシーとかって

まあ、いろいろあって、

セキュリティチームの立場としては

運用していかなきゃいけない

というところにあると思うんですけど、

まあ、それを社員が全部覚えてるかっていうと

覚えてないよねって話があって、

まあ、そこら辺を学習というか

データとして加わせたチャットボットを

用意して、社内の開発者からの質問に対して

それを加味した上で回答するとか、

まあ、このドキュメントを参照してやってねみたいな

ことをしてくれるチャットボットっていうのが

事例というかアイデアとして紹介されていた

っていうような感じです。

はい、ですね。

で、結構なんか、

あの、サインを何回か前に

生成案に実際どう使うんだろうねみたいな話をして

みたいな話をしたんですけど、

まあ、そこへの回答の一つなのかなと思って、

個人的にはなんかCSPMはすごいあるあるというか、

なんか、そのCSPMサービスを提供している事業者の皆さんは

結構既にやってるアプローチかなと思うんですけど、

まあ、チャットボットは結構素直にやりたいなと思ったり

しましてね。

なんか、僕は立場上ガイドラインを書きまくって

展開するんですけど、

実際みんなが読んでるかというと、

全員は絶対読んでなくて、

どっちかというと質問が来た時に

このガイドライン読んでおけばOKですって、

スラック1行で返せる、返すために書いてる

みたいな部分があるけど、

その返すとかそのコミュニケーション部分も

肩代わりしてくれたり、

あとそのスケールしていくとセキュリティチームも

多分、規定したポリシーを全部

暗記はできないと思うんで、

そういう部分を肩代わりしてくれるっていうのが

実現できたらすごいいいなって思いましたっていう感じです。

セキュリティチャットボットの事例

なんかデザインドックの、

難しいな。

ドラフトかそうでないかの識別とか、

別の仕組みを組み合わせないといけないと思うんだけど、

デザインドック書き終わったら、

これに加わせると見るべきガイドラインを

教えてくれるとかやってもよさそうで、

聞きに来るまで待たなくても。

確かに確かに。

めっちゃいいね。

全然あると思う。

確かにな。

どっかで成果物があって、

それがLLMが解釈できるものがあったら、

全然できるだろうね。

うん。

確かに。

いやー、

これこそ割とさ、

なんか、

別に究極人間がやる必要はないけど、

人間がやらなきゃいけない系タスクじゃん。

うん。

そうだね。

うん。

もしかすると、

人間じゃないといけないこともあるけど、

その作業みたいな部分もあるだろうから。

うん。

確かにね。

確かに確かに。

やりてー。

他なんか、

LLMどう活用するかのアイデアの広がりが

僕の中もあんまり広くはなかったね。

結構面白かったなと。

うん。

紹介しました。

うん。

まあそれでいくと、

うちはひさしとかあるしな。

そういえば。

ひさし。

AI社員ってやつ。

ああー。

昔からいたでしょ。

なんか、

そうですね、僕辞める、

2020年に。

そうそうそうそう。

ひさしまだいるんだ。

いるいる。

ふっける。

あのー、出た頃は正直、

はっ!って感じだったけど、

うん。

なんか、最近普通に使えるよ。

あ、そうなんだ。

うん。

あれどこにあんのってなんか聞いたら教えてくれるから。

あー、めっちゃいいっすね。

結構使える。

そう言われてみると確かに、

なんか今あれが裏がLLMに置き換わってるかどうかはちょっと分かんないけど、

うんうん。

インタラクティブにそんなに会話してくれなかったと思うから今も。

うんうん。

うん。

なるほど。

なんかそう言われてみれば、

なんか確かに結構便利なとこだなって思ったわ。

うんうん。

マルチテナントのアイソレーション課題

うん。

確かに。

いやー、いい話だ。

いやー、

ちょっと未来に期待しつつ活用しつつって感じですね。

はい。

で、次に行くと、

次もその同じ文脈でイベント参加した、

同じ方かな、が書いた別記事になってる神梨さんの技術ブログの記事で、

こっちはタイトルがテナント・ブルリの考え方を整理したらRFC8693にたどり着いたっていう記事です。

うん。

で、これはちょっとうまく正しく説明できるか、

少し不安なところありつつ説明すると、

セッションの紹介なんですけど、

セッションの内容としては、

マルチテナント、SaaSを実装していくときに、

そのテナントのアイソレーションっていうのが常々課題になりますよねって話があって、

そこに対する実現方法みたいなところに関して、

ディスカッションとか議論しているっていうようなセッションですと。

で、

あ、いいよ、ごめん、何でもない、思い出しつつあるんだけど、

これじゃない話、後でするわ。

うっすうっす。

で、話の筋としては、

結構AWSのソリューションの名前がライズされているんですけど、

AWSはあんまり詳しくないんですけど、

要するにJOTトークンを払い出して、

そのトークン内にテナントIDに、

いや、ちょっとちゃんと思い出すわ。

正しく説明したいな。

サマリーを見るだけじゃダメですね。

あ、そうっすよね、そうっすよね。

そのJOTを、

新しいトークン管理の方法

トークン払い出すところから受け取って、

そのJOTトークンに含まれるテナントIDみたいなものを元に、

AMロールをアサインして実装するみたいなパターンが、

割と一般的だよねって話なんですけど、

この方法はアプリケーションロジック側に不具合があったら、

別テナントデータに容易にアクセスできちゃうので、

危ないよねって話で、

じゃあそこに対してこういうパターンどうかっていうのが、

このセッションの主題ですと。

で、この新しいパターンでは何をするかっていうと、

えー、この図がわかりやすいかな。

あー全然、

いやーこれ深掘り後でしたいやんけなんですけど、

えーと、

やばい全然、

記事がさ、多いからさ、

そう俺もさっきの最初のGoogleの話、

もう全く見覚えがなくて、

え、こんな記事読んだっけ?

サマリー回転の俺だわってちょっと思ったんだけど。

フォロワーだ、そうですね。

そうなんだよ。

ちゃんとね、ちゃんと理解したらなんだけど。

えーと、

そう、あのー、

えー、アクセスするときに、

えーと、

ジョット、

あーそっかそっかそっか、

えーと、

あれですね、

もともとのアプローチはジョットの中にテナントIDが入ってて、

それをもとにアプリケーション側のロジックで、

例えばそのIOMをアシュームしたり、

アクセスデータベースを切り替えるみたいな感じだったんだけど、

新しい、新しいっていうか、

ここで提案されているパターンは、

えーと、ジョットを渡したときに、

えー、

エラベースのIOM側で、

えーと、どういう権限を持つトークンか、

えー、どういう権限を持つかっていうのを判定して、

その権限にひも付くトークンを渡して、

それを引き回していくみたいなアプローチを取っていて、

で、これだと何がいいかっていうと、

えー、

まあその権限の制御みたいなところは、

IOM側に閉じれるんで、

まあアプリケーション側で制御する必要がなくなるんで、

まずアプリケーションキーのバグがなくなりますよっていうところと、

まあアプリケーション側のミスで、

まあ例えば別テナントのDBに行っちゃったみたいなパターンがあったときに、

そのDB側でその、

えー、IOMに基づく権限制御がきちんとされてるんであれば、

えー、

まあ弾かれるようになるよっていうような話かなと、

僕は理解しました。

AWSとポストグレスのセキュリティ

はい。

で、

タイトルにあるこのRFC8693にたどり着いたっていうところは、

このRFC8693がそもそも何かっていうと、

えーと、

OSのトークンエクスチェンジの仕様かな、

を、

えー、

思い出しましたっていうのは、

これはなんかセッションで触れてたっていうよりかは、

その、

筆者が、

まあ結構似たような概念ちゃうみたいな話で、

えー、

取り上げてくれていて、

まあこれもその、

何でしょうね、

えー、

まあトークンみたいなのを、

まあゆうさがが何かしら二種トークンを持ってアクセスして、

で、

そのアプリケーション側とかロジックに来る前に、

えー、

まあその、

渡したトークンを内部で使うためにトークンに交換して、

で、

それを引きますみたいなところは、

まあ結構一緒だよねみたいなところが、

書いてあるっていうところですね。

で、

えーと、

あともう一つ、

えー、

まあこの、

えーと、

あー、

そうですね、

この、

で、

この仕組みに対して筆者がセッションで質問したことが、

なるほどそれぞれって思ったんですけど、

さっき言ったその、

じゃあトークン引き回して、

えー、

まあもしかするとトークンじゃなくて、

じゃあその、

マルチテナントのデータベースで、

まあPostgresとかだとその、

どこだったかな、

言及あったはずなんですけど、

あ、

そうですね、

えーと、

まあPostgres側で認可制御みたいなのをしたときに、

まあそこの接続認証情報って一時トークンみたいなものが

仕組みじゃないんで、

じゃあそのテナントのIDパスワードを、

えー、

トークン交換サービスから返しますってなったときに、

まあそれってその生存期間がちょっとより圧倒的に長くなっちゃうけど、

それって危なくないの?みたいな質問をしていて、

あ、それは確かに課題だねみたいな回答をしてもらいましたみたいな言及があって、

まあ、

うーん、

なるほど、

確かにって思ったっていう、

まあすごいめっちゃ浅い感想なんですけど、

ちょっと実践、

AWSのなんかアーキテクチャがいまいち把握できてなくって、

うーん、

そうなんですよね、

僕も正直そうなんで、

結構概念的に理解した部分があるんですけど、

うーん、

正しいパターンでは、

AWS IAMがちょっと読み取って、

AWS STSにおる一時権限を付与します、

うーん、

データレイヤーはどうやって、

データレイヤーは、

例えばそのDynamoDB、

DynamoDB、

AWSのDynamoDBとかだと、

そのSTS、

IAMから吐き出されたSTSが、

ああ書いたと、

はいはいはい、

使えるから、

ここは多分結構嬉しいポイントで、

うーん、

で、

POSGRESだとローレベルセキュリティっていうのがあるよと、

いやまじ、

そうですね、

知らねえ、

うふふふふ、

あるですね、

ただこれはそのAWSのIAMの仕組みではなくて、

そのPOSGRESの概念なので、

うんうんうん、

まあ繋ぎ込む何かしらは必要なんだね、

そうそうそう、

だがそれがここでそうですね、

言及されてるのか、

ああ、

ローレベルセキュリティ面白いね、

これマイスケールだとないのかなあ、

ああ、

なんか、

なんかね、

なんかの本で読んだんですけど、

一部のセキュリティ機構はPOSGRESの方が優れてたはず、

何の本で読んだんだっけなあ、

何の本で読んだんだっけ、

えー、

マルチテナントシステムの考察

マルチテナントサースの入りなのかなあ、

割と最近の記事も多めな感じがするなあ、

えー、

ああ、

オラクルが一番最初に出したのかなあ、

なんかオラクルには昔からあったっぽい、

ああ、

面白いね、

えー、

意外と知らんもの多いなあ、

こういうの、

なんかもっと知ってても良さそうなもんだけど、

私とか、

業務でやらないとなかなか触れないのかねえ、

うーん、

なんか、

なるほどねえ、

僕なんかふわっとそういうものがあるっていうのは、

なんか本で読んだことあるとか、

そういうレベルぐらいでは認識してるんだけど、

やっぱ使わないから忘れるし、

具体的にじゃあどういう仕組みって説明を取られると、

ググんだけ分からないっていうか、

うーん、

スパナーとかもあるのかなあ、

スパナーなさそう、

あんのかなあ、

ああ、

データベースレベルの、

うーん、

ちょっとなんかパッと出てこないなあ、

えー、

面白いね、

なるほどね、

ちょっといい勉強になりました、

ああ、

まあ結構、

なるほどねえ、

っていうか、

おもろいなあと思いました、

おもろいなあと思いましたっていうか、

考え方としてはいろいろ応用が利きそうだなあと思ったって感じですね、

うーん、

まずSTFトークン払い出す部分を、

分かんないけど、

まあ今回は多分IAMの機能であるっぽいから、

楽なんだろうけど、

自前でやりましょうとかになってくるとちょっと、

まあ普通に大変かなと思うけど、

そこはバグってたらダメなのは同じなんで、

これってなんか、

マルチテナントに着目しているのは何でなのかなあ、

ああ、

まあ想像がしやすいからなのかなあ、

雷さんがまずマルチテナントっていうか、

雷さんがまずマルチテナントっていうテーマに対して、

まあ圧倒的に関心が高いっていうのもあるだろうし、

うーん、

まあでもそれ以前に、

そもそもマルチテナンシーを意識した、

多分、

公演だったわけだよね、

これ自体はね。

そうだね、

この公演自体のテーマがそこだったって感じ。

うーん、

いやなんかもっと、

もっと細かくすれば、

なんか、

もっと細かい、

その権限制御にも使えそうだなと思ったんだけど、

もっと細かいっていうのは例えば、

例えばお問い合わせ対応で特定のユーザーの情報しか見えないようにするとか、

ああ、

ケースを持ってったらそのケースに紐づくユーザーの情報しか見えないようにするとか、

はいはいはい、

ローレベルセキュリティまで組み合わせられるんだったら多分できるよね、

うんうんうん、

でき、

原理上はできそうで、

ユーザーIDとかをキーにしてっていうのはなんかワンチャンできそうな気がするんだけど、

うんうん、

その、

この記事の場合は、

AWSのIAMの仕組みに乗っかってるから、

その、

IAMが動的に、

ああ、だからIAMで制御できる単位でしかできないのか、

そうそうそう、

ああ、

またその動的にその、

IAMを更新するような仕組みとかが必要なのかな、もしかしたら、

うん、

その権限の付け替えとかをするときの、

だからなんか、

なんかそこ次第では、

まあ自前です、

そこまでカリッとしたものを、

まあでも、

現状はね、

実装すればいいだけではあるから、

うん、

まあでも確かに、

センターシェアしたとしてもありそう、

そうだね、

AWSを使ってっていうよりは、

なんかほんとPOSグレのローレベルセキュリティと、

うん、

えっと、

トークンベンディングマシン的なものを、

うん、

別に用意してあげて、

みたいな話になってくるんだろうね、

うん、

きっとね、

そうだね、

うん、

まあAWS関係ないから、

それはそれでちょっと、

なんか、

検討というか、

あの、

議論してみたい感じがするな、

面白そうだな、

そうだね、

うん、

結構ね、

なんか、

こういうケースだったらどうだろう、

みたいなところで、

うん、

この考え方を持っておくと、

面白い、

面白い実感、

うん、

いろいろ広がりそうだな、

うん、

と思いましたね、

えー、

神梨さん、

面白そう、

うん、

神梨では、

アクセス制御が好きなソフトウェアエンジニアも、

募集しています、

あははは、

えー、

あのー、

みんな大好きですよね、

うん、

アクセス制御が、

本当かなー、

言うてさー、

なんか結構適当なとこ多くない?

適当っていうのは、

そうなの?

アクセス制御が?

うん、

マルチテナントのサースアーキテクチャ

結構バックリとしてるところ多くない?

あー、

いやー、

多いと思いますよ、

うん、

なんか、

そのー、

お客さんの性質によって、

かなーって個人的には思いますけど、

うん、

なんかニーズがないから作られないっていう話もあるし、

うん、

それは、

うん、

うっすら同意でございます。

そう、

で、

冒頭なんか思い出そうとしてたのは、

えっと、

ノーションのほうに貼ったんだけど、

ちょうどなんか、

この、

マルチテナントのサースなアーキテクチャの話を、

あー、

何かで見かけたなーって思って、

そのー、

はいはいはいはい、

1月にオライリーの、

なんか、

多分翻訳だよね、

うん、

翻訳だね、

マルチテナントサースアーキテクチャの構築っていう本が、

1月に出るんですけど、

うん、

あー、

こんなの出るんだーって思った記憶を、

記憶がどっかに今引っかかっていて、

なるほど、

あのー、

なるほど、

出てきてすっきりしたっていう感じ。

思い出してよかった。

いいっすね。

多分だからこの辺の話も、

まあ、

ドンピシャのものが載ってるわけではないだろうけど、

えっと、

こういう話が載ってるんだろうね、きっとね。

うーん、

そうだね。

うん。

この本は僕が予約しました。

JFLogのセキュリティリサーチ

ちょっと、

人の元なんで。

うん、

私もね、予約済みでした。

お、

いいっすねー。

うん。

じゃあ、

次いきますか。

いきましょう。

次も、

僕かな?

えーっと、

そうですね。

ほい、

これはですね、

えー、

記事のタイトルは

Machine Learning by Bonanza

Exploiting ML Clients and Safe Model Formats

っていう記事ですね。

JFLogの、

セキュリティリサーチの記事かなーっていう感じなんですけど、

まあどういう記事かっていうと、

JFLogにはまあ、

セキュリティ研究チームっていうのがあるらしいんですけど、

そのチームによる、

まあ、

MLのクライアントとか、

またモデルに関する脆弱性を複数発見して、

えー、

まあ、

CV振られましたよって話と、

まあ、

それごとに、

まあ、

概要をまとめてますっていう記事ですね。

なんで結構その、

まあ、

一個一個、

こういう脆弱性でこういう部分が危ないですっていうとか、

結構、

詳しく説明してくれています。

で、

まあ、

それ全部触れてくと、

まあ、

ちょっとあれなんで、

興味ある方は読んでほしいんですけど、

まあ、

あの、

結構面白くて、

何が面白いかって言うと、

MLの知識なくてもまあ、

わかるような脆弱性が多いというか、

いつかのWASPトップ10 LLMの時にも話したんですけど、

なんかLLMだからこその脆弱性っていうよりかは、

割と従来の、

なんでしょうね、

概念というか、

まあ、

古き良き脆弱性が結局起因で、

CV振られちゃってるものが多いなと思っていて、

で、

まあ、

1個その個人的に面白かったものを取り上げると、

えっと、

CV202427132。

チャットGPの、

チャットGP、

チャットGPTの予約が拾われてないという。

受け、

そうか。

切なすぎる。

ちょっと、

予約後にしますか。

2回、

2回お放棄されてる。

つらい。

えっとね、

ML Flow Recipe XSS to Code Executionってやつですね。

確かに、

拾われてないな。

ちょっと後で書き足しておきます。

ですけど、

これ、

まあ、

えっと、

どういう脆弱性かっていうと、

あの、

タイトル書いてあるとおりのXSSなんですけど、

その、

何かっていうとですね、

ML Flowか、

ML Flowっていう、

あの、

オープンソースの、

MLの、

まあ、

デベロッパーツールがあるんですけど、

そこになんかレシピ機能っていうのがあるんですよ。

で、

このレシピ機能っていうのは何かっていうと、

まあ、

YAML、

いろいろ、

多分、

あの、

いろんなコンフィグを書いたYAMLを加わせると、

いい感じに、

あの、

何でしょうね、

まあ、学習なり、

いろいろ実行できるっていう機能もあるんですけど、

このレシピの実行が失敗したときに、

えっと、

HTMLページがレンダリングされるっていうロジックがあって、

そのHTMLレンダリングのところのロジックが、

普通にSANに対してされてないので、

XSSが成り立つっていうやつですね。

なので、

本当にただただ、

エスケープしてなくて、

XSSが起きるっていう。

で、

歌でも記事の中に書いてあって、

まあ、

このYAMLの中に、

えっと、

まあ、

こんな感じで、

アラートタグを入れると、

まあ、

普通にXSSが起きますっていうような感じですと。

で、

これじゃあ、

なんか何が怖いかって話が、

まあ、

結構、

なるほどなと思ったんですけど、

えっと、

実際として、

じゃあ、

どこで困りうるかっていうと、

まあ、

このML系のツールは、

このMLフローに限らず、

Jupyter Labとかで実行することが、

まあまあまあ、

かなりあるあるだと思うんですけど、

Jupyter LabでXSSが成立してしまうと、

任意コード実行まで繋がる可能性がありますと。

で、

何でかっていうと、

Jupyter Labで実行されるJavaScriptは、

サンドボックス的な保護はされないので、

えっと、

まあ、

Jupyter Lab上で、

JavaScriptを実行することで、

任意のPythonコードを実行するところまで、

えっと、

いけてしまう。

で、

Jupyter Labを触った方は分かると思うんですけど、

まあ、

Python実行群なんで、

まあ結構、

そこまでいっちゃうと、

まあ攻撃者目線はかなり夢が広がってしまうっていうので、

まあまあまあ、

結構普通に危ないというか、

まあ実際のシナリオ、

じゃあなんかその、

危ないレシピを食わせる場面がどうかっていうところは、

そのMLフローを使ってるわけ、

僕は使ってるわけじゃないんで、

そこまで想像できてなかったり、

記事にもそこまでは言及ないんですけど、

まあまあ、

普通に考えできないCVEかなっていうところとか、

あとは、

まあこれもなるほどというか、

まあ他の概念でも通ずるかなって思ったところは、

これは多分CVEとかじゃなくて、

一般的な話かな、

そうですね、

見出し言うと、

Post Exploitation Lateral Movement from ML Clients to ML Services、

っていう見出しのところがあって紹介されていて、

Black Hat USA 2024でもセッションがあったっぽいんですけど、

ここまで4つぐらい脆弱性の解説がされてて、

中にはそのモデルを乗っ取れるものっていうか、

モデルまで侵害できるものがあるとなったときに、

クライアントか、

ML Clientsが侵害できるとなったときに、

そこまで侵害されちゃったときに、

MLのパイプラインとか、

MLのオプスかな、

オプスって呼ばれているようなシステムの中で横展開がされる恐れがあるよっていう言及をしていて、

なんでかっていうと、

MLオプスというかパイプラインとか組んだとある人は分かるだろうっていうところと、

僕も前職で結構その辺がっつり触ってたわけじゃないですけど、

外観は知ってたんで分かるんですけど、

かなりいろんなシステムが同一システム内で動いてて、

なったときに、

システム間の認可制御とかは割と緩く作られがちっていう話があって、

これはMLオプスに限らず、

結構なんでしょうね、

GKEとかで、

自分たちはデプロイスポットしかないからポットカーの通信ちゃんと、

そんなガチガチには認可制御してないとか、

GKEじゃなくてもなんでもいいんですけど、

同一VPC内でとか、

そういうのってすごいあるあるだと思うんですけど、

そこに付け込まれちゃうっていう部分があるんで、

一回ひとたび入られちゃったら、

MLクライアントからMLの中のサービスにどんどん横展開されていって、

悪さされちゃうよっていう話が書いてあって、

なので、

この一個一個のCVは基礎的な部分だし、

面白いなっていう部分がありつつ、

実際にやられちゃったときに、

全然何というか、

油断できないよねみたいなところはあるんだろうなって思いました、

という感じです。

MLフローの脆弱性リスク

なんか特にするコメントがないな。

なんか、

N1の声なんですけど、

よくヤギ足も言ってくれる話があると思うんですけど、

作るときの脳みそと守るときの脳みそが違う話あるじゃないですか。

で、

ML、

例えばモデル開発をするとか、

MLopsはもうちょっと開発的な脳みそになるんですけど、

その研究的な脳みその時って、

もっとこの守るとか攻撃される視点が抜けるんじゃないかなって気がしていて、

うーん、

なんていうか、

気持ちとしてはJupyter Notebookとか書いてるときも、

ローカル環境でデータ加わせてチューニングをひたすらするっていう、

別に保守するようなコードじゃないし、

書き捨てのコードをガンガンガンガンバーって書いていくみたいな感じでやっていくことが多分、

一般的なものなんだとしたときに、

じゃあそこでいちいちエッセンスされるかも、

だからコック気をつけようとか、

なんかここでRCやるか気をつけようとか、

なんないよなーって思ったり、

またそこで使うライブラリのバージョンの管理とか、

もう多分そんなにカッチリしてないことがあるんじゃないかなと思うと、

なんか、

そうね、付け込まれそうだなーって思ったりはしますね。

なんかよく僕が言ってるっていう話はあれですね、

作るときはどっちかというと何ができればいいか、

何ができないといけないかを考えるんだけれども、

攻撃する側の脳みそって何ができちゃいけないかっていうのを考えるから、

それって結構真逆の思考で、

なかなかそこを切り替えながらやるって、

あるいは両方維持しながらやるって開発するって難しいよって話を、

多分いつもしててその話だと思うんだけど、

確かにそれはありそうですね。

なんか、そうね、あんまり、

教員モデリングの重要性

そうね、なんか基礎的なものばっかなんだけど、

まあでも生まれるべきして生まれてるのかもなーとか思ったり、

まあ違ったらすいませんって感じなんですけど、

ちゃんとやってこれなんだよって言われると、

まあそれはすいませんって感じなんですけど、

まあまあまあまあ、ちょっと面白かったんで、

興味ある人呼んでください。

はい。

まあね、

いや、うーん、難しいな。

理屈上は特にML周り、MLops周りがっていうのはちょっと思わないけど、

なんか別に他と変わらんやんって思うんだけど、

まあどうなんだろうね、なんか。

うーん、なんか、

まあ、

まあ場所によるかなー。

うん。

まあこのXSSからのEコード実行って結構たびたび出るけど、

夢のあるパターンで、なんかいいっすよね。

そうだね。

やる側としてはね。

うん。

好きなんだよなー、このパターンで。

それはね、Python実行するための画面だからPython実行できちゃうよねみたいな。

ファイルも読み込めちゃうよねみたいな、結構。

面白い。

面白いって言うか、なるほどねって思います。

じゃあ次お願いします。

はい、結局教員モデルとは何なのか。

TMC東京×斬新感想っていう、

えーと、ちょっと僕はご存じない方なんですけど、

ニキヌスさんっていう方のブログですね、はい。

えーと、

なんか、なんかの勉強会だかイベントだかわからんけど、

なんかで多分この辺の話をしたっぽくて、

それがまあTMC東京×斬新っていうところらしいんですが、

えーと、

なんだろう、イベントとしては、

教員モデリングとハードリングを連続で味わえるイベントだったらしくて、

めちゃくちゃ面白そうやんけって思うんだけど。

めちゃくちゃ面白そうやな。

次があったらぜひ行ってみてください。

行きます。

まあなんていうか、教員モデリングについて、

そのイベントを通じて得た理解っていうのを基準にして書いてくださってるようなものでございます。

えーと、

なんだろうな、

なんか、

むずいな。

えーと、

こうでしたよっていう話と、

それを得てなんかこんな解釈をしましたよみたいな話をつらつら書いてくれてる記事なんで、

まあ正直読んでくださいっていう感じではあるんだけれども、

例えばなんかそれぞれの構成要素について触れてたりする、

どういう図がいいのか、

それはデータフローダイアグラムだよねって。

でもそんなに細かく書く必要はなくて、

5分10分で書いてくださいっていうので書けるレベルでいったんはいいよねっていう話とか、

あとはインフラレベルの教員の予測までやるんだったら、

システム構成図がないとちょっと困るよねっていう話とか、

あとは教員のモデルとしてはストライドを使うで別にいいんじゃないっていう話とか、

あとはじゃあ識別した教員に関しての評価をどうするかっていう部分は、

ドレッドとかアタックツリーとかを使えばいいんじゃないっていうのを書いてくれてる。

ここいいなと思ったのが、

教員モデリングとはシステム担当がセキュリティに向き合うための準備体操っていうふうに書いてくれていて、

ベースラインアプローチとリスクベースアプローチを連結するために役立つっていうふうに書いてくれてるんですけど、

なるほどっていう、これは結構わかりやすいキャッチーなフレーズだなというふうに思って読んでました。

準備体操っていうのがいいよね。

ある種のハードな話に入っていく前にちょっとソフト寄りの話で、

心の準備ができるというか、

全体的に体温を感じる記事っていうか、良かったなっていうふうに思っていて、

個人的にも感覚は結構同じで、とりあえずやってみるぐらいのノリでやれるといいんじゃないかなっていうふうに、

教員モデリングについて僕は思っていて、

結局一人の頭の中で考えるのって結構難しいから、図を書き出して、

図の上でああなんじゃないか、こうなんじゃないかみたいな話とかをしていけるといいよねって思うし、

対面でやるのがすごくいいよなと思うんですけどね、こういうのはできれば。

確かにね。

ベースラインアプローチとリスクベースアプローチの連結っていうのは、

ハマヤンの紹介

これもかなりいい表現だなと思ったんだけれども、

基本的には連結っていうより、教員モデリングにおいてはそもそも境目がないっていう言い方の方が僕はしっくりくるなと思っていて、

そもそもベースラインアプローチとリスクベースアプローチはグラデーションのようにつながっている関係でありっていうのも記事中で書かれてて、

たぶん同じものを感じているんだと思うんだけれども、僕たちは割と境目がないっていう感触を持っていて、

こうあるべきだよねっていうよりは、ここにこういうのがあるんだったら最低限これやらなきゃダメじゃないっていう話をするのって割とあんまり境目がないっていうか。

なるほどね。

なるほどなるほど。そういう意味か。

理解です。

ここの通信って何?暗号化されてんの?TLS効いてる?みたいな話とかね。

いいですね。

いやー、なんかこういうこんなここまで混んだようなイベント、あれは作れないかもしれないけど、

こういうノリで身構えずに社内検証とかやったらいいのかなとかすごいぼんやり思ったりしましたね。

確かにな。

やってみて分かるみたいな部分はあるもんな。なんか自分もその業務でちょろっと。

まあやるかって感じでやってみて。

まあやってみて、意外と得るものがあるというか。

距離分析まで一時期めっちゃ調べてた。調べてるだけだとなんか座学だけだとすごい難しくて、

専門家じゃないとできなそうな空気を感じてしまうんだけど。

実際そんなことはないっていう部分は間違いなく分かるっていうのは分かるんで。

なるほどね。いいですね。

えーこのイベントもっかいやってくれないかな。

結構なんかカロリー消費の激しそうなイベントとかやってくれるかどうか分かんないけど。

それはそうですね。

観測範囲外だったな。

グループには参加しとこうかな。

今年から始まったなんかあれなんですね、イベントっていうかコミュニティっていうか。

地方でもやってるじゃないですか神戸とか。

えーちょっとぜひシーカーでもお願いします。

神戸まで行けや。そんな遠いのかな。

いやー神戸微妙な2時間。

大阪神戸間はそんなに離れてない。

いやー。

離れてないよね。

大阪神戸で35分。

そうなんよ。で大阪まで1時間半なんでうちからだと往復1時間になっちゃうんですよ。

あー結構かかるんだね。

神戸はねちょっと気合がいるね。

そうだね。

打ち上げ行かずに帰るって感じかな。

あー。

まあ別に。

まあじゃあ東京の方が早そうだね。

確かにね。

いやーありがとうございます。

はい。

じゃあ次行きますか。

またしても僕だしまたしても神梨さんのブログなんですけど。

大好きじゃないですか。

いやAWSの記事がめちゃくちゃ面白かったんですよ。

あとアドベントカレンダーかなこれ。

そうだねさっきのアドベントカレンダーかな違うかもしれない。

さっきと違うんですよ。

これは。

これも違いますね。

これも違うね。

なるほどじゃあ単純に神梨さんのアウトプット量が多い。

そうですね。

素晴らしい。

記事のタイトルがAWSアクセス管理を一歩先へ神梨のセキュアなAWSアクセス管理を実現するシステム紹介って記事です。

これはどういう記事かというとタイトルの通りであってAWSのアクセス制御をきちんと制御してないといけないと。

デベロッパー全員エディターがついているような状態はいけないですよねっていう部分で

普段はこういうアクセスをつけて特権中か何かの作業じゃこういうアクセスをつけるみたいなのが必要だねっていうところに対して

神梨の中ではどういうアプローチをとっているかというような記事です。

記事中ではハマヤンっていうシステムが紹介されていて

なんか由来が不明らしいんですけど

開発者が浜野さんだからハマヤンなのではっていう説があるらしいが審査は不明ですということです。

このハマヤンが何かっていうと

端的に言うと権限の一時扶養するシステムです。

権限の一時扶養を実現したかった理由としては

もともとはソフトエンジニアが全員アドミン権限を持っていて

まあまあ良くない状態だよねっていう部分があって

そこから権限を絞っていこうかとかガイドライン作ってそれ通りに運用しようかとか

IACやろうかみたいな

いろんな順当な進化を遂げた末に

ハマヤンに開発につながりましたというところで

ハマヤンで実現したいのは普段つけている権限ではなくて

何かのタイミングで何かの理由で一定期間必要な権限があったときに

それを提供するためのシステムになっていますと

多分ブログを読んでいったり

ブログの記事を開いていただいて

画像を見ると分かりやすいんですけど

スラックアップでハマヤンが動いているらしく

スラック上でアクセス権限をリクエストすることができて

対象のアカウントとかどういう権限が必要かとか

何時間必要かとかまた権限が何で必要なのかというのを

スラック上で記入しますと

それを記入して送ると

個人的になるほどって思ったのは

承認プロセスがないんですよね

承認プロセスがなくてスラック上に

この人にこういう理由で権限が振られるよってバッて流れて

自動で権限が振られるというような感じで

通知が来ますというような感じになっています

それの具体的な実装とかもいろいろ書いてあって

この辺はちょっと割愛しますけれども

AWSに今言ったテンポラリーで権限付与する仕組みが

実は純正であるらしいんですけど

それは実は採用見送りましたという話があって

理由はいくつか書いてあるんですけど

一つはハマヤンが開発済みで

運用が回っている状態のときに

この機能自体が公開されたので

わざわざ乗り換える理由がなかったという話と

また現在の上出しのニーズに対しては

機能型という部分があったらしいという部分と

またその機能型が故に

結構運用コストみたいなところが高そうというのがあるらしく

結構複雑性も高いんで

今の少人数の積電ジニアチームで

メンテナンスしていくには

負荷が高そうという部分があったみたいです

あとは有償券との結果を一部公開みたいな感じで書いてあって

これを使って開発してどうでしたかみたいなのも

結構まるっとキャプチャーで公開してくれてますというような記事でした

権限付与のトレードオフ

なんか個人的には

なるほどって思ったら

多分利便性というかトレードオフのところで

必要な権限をなるべく早く付与するとか

また承認する人のコストを減らすみたいな観点なのか

わかんないですけど

承認プロセスを設けずに権限をすぐ付与してるっていうのは

なるほどなと思ったというか

確かに組織規模とか状況とかポリシーにもありますけど

共有しちゃってもいいよなみたいな部分は思ったりとか

あとは気になったのは

機能型の部分はどこら辺が機能型だったのかが気になるなと思ったんですけど

QAとセキュリティの関係

それこそ自分で調べてこいって感じなので

どっかでキャッチアップしようかなというところと

あとこれは感想なんですけど

さっきは感想しか言ってないか

感想中かな

感想

感想しか言ってない

ポッドキャストの

そうですね感想

失礼しました感想を言います

この記事の感想じゃなくて

上梨さんのブログ

セキュリティ系のブログに関する

全般的な感想なんですけど

アンケートとってのはマジでいいなと思って

これやっぱ大事だよなって気はしていて

いろんなセキュリティで縛りを設けていく過程で

トレードオフがあって

トレードオフの中には

開発者体験が悪くなるっていう部分が絶対にあるんで

それが失われてないかみたいな部分をきちんと

アンケートという形で集計して

こんな感じで毎回ブログで公開してくれて

っていうのはすごい素晴らしい取り組みだなって

しみじみ思いましたし

プラットフォームチーム

チームトポロジー風に言うと

プラットフォームチームのあるべき姿だよなって

思ったという感じです

うーん

なるほどね

うちは前にも話したかもしれないけど

うん

えーっと

名前なんだっけ

キャリアなんだけど

うん

ちょっとね

綴りが

あー

いやマジ

これさ

ほんとしょうもないんだけど

昔からそうなんだけど

こう

あの

商品のさ

あれが

出てきちゃうからさ

その

メルカリなんとかで検索したら

商品のほうが先に出てくるからさ

このテックブログの記事にたどり着くの

地味に難しいんだよね

あの

サイトクエリーで頑張るしかないね

うーん

これか

ゼロタッチプロダクションへの移行ってやつだね

うんうん

そうですね

これも

このGoogleの多分

テンポラリーアクセスが出てくる前に

Googleクラウドのテンポラリーアクセスが出てくる前に

作り始めちゃって

結局多分

まあわからないな

最近触ってないからわからんけど

どうなんだろう

似たようなものをやってるんだけど

こっちはどっちかっていうと

えーっとなんだっけ

GKEの本番関係へのアクセスっていうところに

かなりフォーカスしている部分があって

ちょっとなんか役割が違う

役割が違う

でゆえに

本番環境へのアクセスなので

えーっと承認も必須になっていたりとかして

まあかなり考え方が違うんだけど

やってることは

えーとても近しい

スラックでポチポチすればできるしみたいな

なるほどね

うんスラックでポチポチはできねえわ

嘘だわ通知がスラックで来るだけだ

あー

承認がスラックでできるようになってたと思うけど

なんかこういう系

OSSであってもよさそうなのにね

まあでもなんか

ポリシーとか承認プロセス違うから

やっぱ内製になる

うーん

まあ必要な権限の単位とかも多分

違うと思うしね

あー確かにな確かに確かに

いやーそれでいうとこの神谷さんのやつも

そうなんだよな

このアカウントとか権限とか

そのプルダウンで多分選ぶような

まあモザイクかかってるんでスイズムですけど

だけど

そうだよねアカウントとか全部出したら絶対

やばいことになるから

業務で使うの大体

この辺

あれば有助スカバできるみたいな感じでやってたり

するんだろうなー

とか今ちょっとふと思いました

うん

確かに確かに

うん

はいそんな感じです

面白かった

いやー

いいですね

渡したい場合もあるだろうし

えーっと

どうする

えーっと

Google Cloudで

ロールの中に入ってるやつ

パーミッションかな

そうパーミッションかな

うん

パーミッション単位で渡したいっていうのは

あんまりないのかな

Google Cloudの場合は

そもそもパーミッションで渡せないから

ロールを作らないといけないから大変だよね

そうそうそうそう

NRSは多分その辺ちょっと違うっぽいんだけど

あそうなんだじゃあその辺は結構

事情としては違うかもね

うん

あとその

リソース単位Google Cloudで言うと

そのリソース単位で

ロールを振るかとかもあるだろうね

そうだね

プロジェクトじゃなくて特定リソースに対して

特定ロール振る

確かにその辺考えると

意外と

OSSにするの大変な

感じするよねその汎用的に

っていうのは難しそうな

あらゆるユースケースを

吸収して爆発しそうだね

普通に

ジラみたいなのができちゃうから

そうかも

なるほどね

まあGoogle CloudもNRSもそうですけど

その公式が提供し始めてくれたんで

そっちの進化はね

期待したいところですけどね

個人的には

なんかもう限界がありそうだからな

インターフェースどうしましょう

みたいな部分はやっぱ

組織ごとの作り込みなんじゃない

それは確かに

そこだけなんか

簡素にOSSにいろいろ出てくると

嬉しい

お前が作る案件なんですけど

お

まあまあ

広報期で

何の予定もないけど

ひどいな

はい

じゃあ

次いきますか

いきますか

MySQLのアップデートで

MySQLデッドロックの問題

インクの要素が多すぎてデッドロックした話

レイヤーXのテッカー・アドカレからの

記事ですね

長いし

一個一個説明していくの大変なんで

2行だけ紹介すると

インクの要素が

1000個と多いせいで

オプティマイザーがフルスキャンを選択し

全体のレコード操作&ロックしようと

している可能性がありそうです

インクの要素を減らしたらどうなるか

試しに要素数を500個まで減らして確認してみます

すると

タイプがレンジに変わりました

自己規格の話に変わりました

ここに全てが

詰まってる

面白事象というか

インクに渡す要素が

多すぎるとフルスキャンになっちゃう

みたいな話でした

ものすごく平たく言うとそういう理解です

なんでこれが

単純に面白事象

っていうのもあるんだけれども

ユーザー入力の

入り方によっては

DOSに使えたりするのかな

ってちょっと思ったんだけど

どうなんすかね

作りが悪かったら

ありそう

デッドロックだって検知したら

そのまま落ちるだけだから

相当件数が多分

正規の操作が

その操作が

デッドロックによってブロックされるっていうのが

発生すれば

DOSはできるのか

そうだね

そうだし

フルスキャンで

ギャップロックを取る

そのリクエストを

ひたすら投げ続ければ

かなりコスパよく

ありとあらゆる操作ができなくなる

っていう意味でDOSが成立するわけだな

確かに納得したわ

確かに

またこれ

そういえばって思ったけど

このアップデートだけの

話なのかな

セレクトも同じなのかな

ギャップロック取ろうとしてるから

そうだね

ギャップロック取ってるので

アップデート

セレクト4アップデートとかすると多分

ギャップロック取ろうといかず

なるほどね

アップデートのインクを

10個以上ユーザーに入力できるパターン

そうそうないかなって気はしてて

ないと思うけど

それこそさっき言ってたジラとかのバルクアップデート

とかあるかもね

ああいう作りのもの

だったらあるかもしんない

まあ確かに確かに

いや

確かに

これ

すごい全然話が変わるけど

マルチテナントで

ローレベルセキュリティをやってます

うん

ローレベルセキュリティって要は

マルチテナントのデータをデータベース分離せずに

って話だよね

そう

理解しております

ギャップロック取るときってあれどうなるの

そもそもボスぐらいにギャップロックって存在する

割とMySQL特有の挙動のような気がしてたんだけど

RDB博士が

欲しいな

カゼブロさん呼ばないとだめ

あまりに贅沢だ

どうなんだろうね

7256

まあでもなんか結構

分岐に違いそうな空気もありつつ

全然

まあ要は何が言いたいかっていうと

マルチテナントでかつ

ローレベルセキュリティで

分離してますみたいなケースだと

ギャップロックでドスが発生しますみたいになったときに

全テナントに

なるほどね

ギャップロックが

ギャップロック側でローレベルセキュリティを

ローレベルセキュリティって

言ってるぐらいだから別に

ローレベルのアイソレーションではないわけだから

ギャップロック取るってなったら

全部またぐんだろうね

もし取るのとしたら

そうだね

あれは

気になるね

ケンケンあろうがなかろうが

だって

ローレベルセキュリティ自体の理解度が低いから

なんとも言えないけど

あれだって

アクセスレベルの話じゃないの

そうだと思いつつ

例えばじゃあなんかその

あーどこなんだろう

いやちょっと

勉強していきますって感じですね

適当なこと言いながら

クエリの実行時に

そのコールしてくれないでしょ

きっと

いやそのクエリを実行

だって

B3とかその

インデックスの構築をさ

ローレベルセキュリティまで

コールしてやってくれるわけじゃないでしょ

あーどうなんだろうね

それやってくれないと

結構きつくないか

って気がするけどどうなんだろう

まあなんか

キャビジ的には暗黙的に

ローレベルセキュリティ

インデックスで調べれば

多分欲しい答えに

近づけるんだな

ローレベルセキュリティ

このフレーズが正解だった気がするわ

ローレベルセキュリティが実行計画に

与える影響を確認してみる

ローレベルセキュリティは

DBユーザー等の属性をもとに

フラット操作の影響を受ける

対象レコードを制限できる機能です

あーなるほどね

そうすると実行計画の時点で

もう

弾かれてるはずだから

そうするとロックも取りに

いかないのかな

ローレベルセキュリティの影響

そうなんじゃないかなって思うけど

そうであってほしいなと思うけど

勉強していきましょう

宿題ですこれは

前の最初のスクラップが

それになるわけですね

そうそうそうそう

この場で勉強したらもう

多分2時間コースなんで

いやいいねー

なんか新しく勉強するものがあるというのは

とても楽しいですね

何歳になってもわからんことばらけ

車のテクノロジーとかもね

面白いんですよね

あーなるほどね

知らないことってことね

はい

まあそういう記事でした

まあちょっとなんかそんなこともあるんだな

という感じです

勉強になりました

はい

USA's Chinese hackers are still rocking in American phone networks

っていう記事です

えーと

うーん

記事としては重くないんだけれども

アメリカのなんかちょっと

公的機関的なところが

えーと

中国系のスパイだかハッカーだかが

通信大手の各社に

侵入しててまだなんか

距離が残ってるよっていう

注意喚起をしてるよって話ですね

えーと

なんかよくわかんないんだけど

昔々の法律に基づいて

バックドア的なものを

その通信各社のシステムの中に

入ってるらしいんですよね

そこに侵入されちゃったよ

っていう記事が

まあ一応前日担当して

まずあって

アメリカ国民に対して

E2EEをやってね

使ってねっていうのを推奨してるらしい

うん

でもNSAとか泣いちゃうんじゃないかな

これ

逆に背に腹はかえらんねー

っていう話になるのかな

それとも面白いけど

まあ脅威だよ

まあでも脅威ではあるよね

こっから言うの

これなんか結構

ずっとだよね

その

ブリピンコンピューターとか発火ニュース読んでると

なんかわかんないけど1年前とか半年前とかに

もう

なんかしょっちゅう

侵入されてるじゃないけど

その

もう入られちゃってるのは

もう確定みたいな

基地をよく見てしまうんだけど

うん

見つけては

排除して見つけて排除してみたいな感じで

依然として脅威残ってる

ってことはまあもう

大丈夫って

もう言い切れませんってことなのかな

もうずっと

うん

いやー

大変だなーこれは

名前忘れちゃったTモバイルとか

Tモバイルかなんかもやられてた気がするけど

いやー

嫌になっちゃいますね

日本は

大丈夫なんか

日本もやられてる前提で

生きていくしかないかって思ってたけど

いやーそうなんだよね

うん

大丈夫なのかなって

うん

まあ1から100大丈夫ではないんじゃないかな

ああまあね

そんなん誰も言えないんだけどさ

うん

なんか

アメリカだから見つかってるだけで

日本はなんか実は入られ放題

でしたみたいなのが

本当にないのかなー

コパイロットのセキュリティ問題

ってちょっとドキドキしちゃうんだけど

神のみぞ知るやん

いやーでも

驚かないけどね

まあ神のみぞ知るでは困るんだけどさ

その

知ることができる何かは

誰かは

いて欲しいんだけどさ

そうだねそうだね

いやーでもさアメリカ

そうだねアメリカレベル

国家としてここまで

セキュリティに投資してやっと見つけ

まあやっとではないのかもしんないけど

まあ投資したらすぐ見つかるのかも

わかんないですけど

日本はちょっと状況が違うじゃないですか

うん

でその

進捗としてはアメリカの

結構後ろいってる認識なんで

まあそういう意味では

まあやられてもおかしくないかな

って個人的には思いますね

うん

残念ですけど

わかんないもうあのめちゃくちゃ

頑張ってんだぞっていう

現場の人がいたらめっちゃ

勉強不足ですいませんって感じ

なんだけど

うん

まあねそうだね

個人としてはいついいしをするしかないね

確かに

いやー

ああ

なんかちょっと気になりましたという

お話でした

あんま感覚麻痺させずに

定期的に考えたほうがいいだろうな

考えるっていうかインプットしたほうがいいですね

ありがとうございます

はい

次の記事は

これねパンチラインだなと思ってたんですけど

えっとちょっとサムリ書いてあるんで

後は書きますけど記事のタイトルが

マイクロソフトのコパイロットを導入したら

経営陣の自信ボックスが社員から突然

丸見えに懸念に広がるっていう

記事で

記事はなんかビジネス系の多分メディアの

記事なんですけどタイトルの通り

ですねタイトルの通りで

えっと

まあそういうセキュリティインシェントが発生しました

っていう話ですね

でこれ通責が有料会員

なんで読めてなくてちゃんとソース

覚えてないんですけど

まあ原理上はまあありそうだな

っていう

てかなんか前回だっけワースプトップ10

かなんかで触れてたやつ

だよねまさにその

LLMの

あーそうだね

そうそうそうアシスタント側の権限が

強すぎるとそこへいろいろ漏れるよ

っていう話の連携例だと思っていて

確かに確かに確かに

なんかインパーソネーションするような仕組みが

多分必要でその

アクセスしている人間の権限を

持って何かをするっていう

権限異常的な仕組みが本来は必要だと思うんだけど

確かに確かに

うん

そもそもなんでメール壊しちゃったんだろうなっていう

メール

あーでもそうかメールを

LLMが知ってたわけじゃなくて

LLMが持っている権限がメールにアクセスできた

そうそうそう

確かに確かに確かに

確かにね

いやーなるほどね

これはね

ちょっと

タイトルのインパクトが強すぎて

ちょっと

なるほどと思ったけど

確かにな

はい

まあちょっとなんとも

まあ自分たちが

作る立場になった時に気を付けなきゃねって

気持ちは入りつつって感じですね

うん

まあ要はLLMのアシスタントがその

Google Cloudの

ロールズエディターを持っているような状態

っていうことで

そうだねぇかもしれなかったっていう

感じです

次いきますか

はい

あーこれ

あー俺読んでねーこれ

読まなきゃ

記事のタイトルは

絶対暇じゃないと思うんですけど

暇だし過去15年間の

サイバーセキュリティーな

大統領令を見る2017年まで

っていう

ふざけんなよって感じだよね

暇なわけねーだろ

ケンゴさんの記事です

ケンゴさんの優秀さを

知ってるんでそんな

絶対仕事いっぱいあると思うんですけど

暇らしいんでまとめてました

はい

記事の内容はタイトルの通りではあって

大統領令っていうのが

その

まあアメリカの

大統領令っていうのが

過去いろいろ

セキュリティーに関連するものが

えー

セキュリティー以外のものかな

まあまあまあ

サイバーセキュリティー

IT周りとかで出てるっていうものを

2017年のものまでまとめました

っていうような記事ですと

記事自体まとめではあるんで

そのそれぞれの大統領令について

いろいろ

解説を一個一個

簡易的に

してくれてるんですけれども

個人的には

かなり勉強になったな

と思っていて

ありがとうございますという気持ちで

えー

これ2017年までってなってるんですけど

一番最初の紹介されてる

大統領令が2009年の

大統領令から

えー

10年10年11年13年14年って感じで

刻んで出てるんですけど

このタイミングでこういうのが出てきましたよね

このタイミングで

こういう

トレンドになりましたよねとか

っていうのが一個一個

付加情報としてコメントしてあるんで

最近セキュリティ業界に

身を投じた立場としては

今

ありがたく頂戴してるこの情報は

このタイミングでこの潮流から

出たんだねーみたいな

歴史を知れるっていう意味ですごい良かったな

って感じですね

NISTのCSFとかも

これから繋がりましたよね

って話とか

この大統領令の時に

出てきたガイドラインを防衛省が

調達する基準として

採用したよねとか

そういう注釈があってすごい勉強になりました

って感じです

なんか結構

アメリカの

なんかあれって

面白いですよね大統領令をきっかけに

大統領令

アメリカの大統領令とサイバーセキュリティ

っていうのもなんか実は

日本語で大統領令と呼ぶときは

微妙にその意味が

揺らいだりするらしいんだけど

なんか

こういうのを

視点に何かをやるっていう形になってるのが

面白いというか

そうだね

あとなんか

すごいうっすらではあるけど

攻撃中か

脅威のトレンド

が透けて見えるような気もしてて

面白かったですね

うん

なんか

CSFが出たってことはなんかいろいろやられるところが

多かったんだろうなーっていう感じだね

そうねそうね

いろいろ

2018年以降のバージョンも

多分来週

紹介文に上がってるんで

すごい楽しみにしてるんですけど

そっちとかあと

僕でも知ってるってものとか

出てくると思うんですけど

Sボム周りとか

割とトレンドっぽいよね

いろいろ繋がりそうだなって感じで

思ってます

これはぜひ読んでほしい

セキュリティに身を閉じている人は

ぜひ読んでほしいんじゃないかなって思いました

はい

じゃあ次お願いします

OSOIDCのクライアント管理を

カタで制する

フリークライアントタイプの奇跡

という記事です

フリーデベロッパーズアドベントカレンダー

2024の記事ですね

えーと

まあ

ぶっちゃけ別に特に話すことないんですけど

うん

割となんか僕自身好きなアイデアだな

って思ったので紹介をしたくて

えーと

まあ

フリーの認可サーバー

のクライアントっていうのが

いろんなタイプのクライアントがいて

NIST Cybersecurity Frameworkのアップデート

このクライアントはこれができる

このクライアントはこれができるみたいなのを

細かくそのクライアントごとに

制御するのがすごく大変だから

そのクライアントタイプっていう

カタで

制御するよっていうのをやってるらしくて

あーなるほど

ちょっと面白いなと思ったので

まあ紹介したかった感じですね

はい

まあというだけですね

なんかこれ面白いなと思うのが

まあ

いいアイデアなのかどうか

ちょっと僕にはよくわかんなくて

まあ面白いなと思っただけなんだけれども

うーん

なんかその

フリーだからこそっていう

この答えに着いたっていう

のもありそうな気はしてて

結構その

フリーの多数連携周り

一回仕事でちょっと触ったことあるんですけど

すごいよくできていて

そのサードパーティーっていうか

自前のアプリを

連結するのも結構

やりやすくなっていたり

とか

あとそのフリー自体が

実装するような多分サードパーティー

違うのかな

いろいろなんかそのサービスの性質上

できるようなサービスであるって話もあるし

あとその内部事情

そんな知ってるわけじゃないですけど

その

マルチプロダクト

じゃないですか

フリー展開してるものがあって

まあ認証画面とかを見てると

その裏側では別々で独立してて

みたいなところが透けて見えてたり

するんでその

システム関連の連携で

内部的に保守してるもので動いてるものも

ありそうだなとか思うと

まあなんていうか

何かしらの手を打たないと

結構大変なんだろうな

っていうのはちょっと思ったんで

良さそうっていう

なんかコード見たいなって

僕は素直に思いました

コード見る時は

出せるわけないだろうなと思いながら

転職するしかないです

ちょっと1週間だけお願いします

このアウトプットに相応する

その見返りを

僕が1週間で提供できるわけがない

ちょっとあれなんですけど

まあはい

そうですね面白かったですね

はい

じゃあ次行きますか

次行きましょう

えーっと

6パーソナルテイクアウェイ

from the updated

NIST Cybersecurity Framework

っていう記事です

えーっと

何の記事だっけ

ブリーピングコンピューターだ

はい

NISTのSP863Bのアップデートから

テイクアウェイを6個

紹介してくれてます

はい

長いので読んでください

シリーズになっちゃうんだけど

えーっと

まあ6個

そんなに長くねえな

まあいいや

6個

タイトルだけヘッドラインだけさーっとさらっていくと

パスワードレンクス

より

パスワードレンクスのほうが

パスワードコンプレキシティより重要だよ

パスワードの複雑さよりも

パスワードの長さを重視してねって話と

あとはファシュリテッドロンガーパスワード

っていうまあ長いパスワードを推奨してね

っていう話

推奨っていうか

まあ難しいな

長いパスワードになるように

ねって話

妨げないって言い方のほうがいいのかもしれないけど

中身を読む感じ

なるほどね確かに

インプリメントMFA

多様性認証を実装してねって話と

アボイドフリクエントパスワードチェンジ

っていうまあパスワードの

変更をこう

なんていうか何回もやるっていうのは

良くないよねって話

あとは

Prevent the use of

already breached passwords

まあ漏えいしたパスワードを

使わせないっていう話と

Discontinue password hints

and other

knowledge-based recovery

まあパスワードヒントと

えーっと

knowledge-based recoveryなんて秘密の

質問とかですね

もうやめようよっていうのを

言ってくれてるらしい

これが全部で6つですね

うん

で

まあ

3万5000号のガイドラインを

読む時間ないよねみたいな

だから6個まとめてくれたよ

まとめといたよって記事なんだけど

ほんとそれよって思って

ほんとそれよ

まあ読んだ方がいいのは分かってるんだけどさ

ほんとそれだね

まあその時間がない中で

付き合い方としてはそのこの6個を

押さえつつその根拠を

ちゃんと深く知るべきタイミングで

掘りに行くとかがいいのかもね

うん

まあでもなんかどうなんだろう

読んでから

考えた方がいいか

読んだことでここからさらに

踏み込んだ造形が得られるのかっていうのは

分かんないなと思ったりするんですけど

うん

大体なんか

割と言われてきたものばっかりではあるじゃないですか

うん

なので

いや

3万5000号の

お金の中で読んでたんです

切な的に生きてるんで

いやまあ読んべき時には読みましょう

確かに

ありがとうございます

次行きますか

いいかなこれ

じゃあOKでございます

よかったんで読んどいてください

Googleクラウドのギターブ管理

読みはねしたよ

じゃあいいや

何だったかは

有料版で紹介するので

しばらく

じゃあ

こっち読みます

お願いします

えーと

ベルカリエンジニアイングブログの記事で

Googleクラウドからギターパッドと秘密カギをなくす

トークンサーバーのGoogleクラウドへの拡張

っていう記事ですと

でこれサマリー書いてないんで

思い出しつつちょっと

話すんですけれども

そうですね

タイトルの通りではあるのかな

あの

Googleクラウドからギターブにアクセスしたい時に

PATと

秘密カギっていうのは

ギターバップとかの秘密カギのことだと思うんですけど

をなくすための

システムを作りましたっていうような

記事です

でこれがなんか

うーんまあ

詳しくは読んでくださいなんですけど

そのセキュリティチームの体力が

ある会社は

ここまでやれるんだな

って素直に

羨ましいなって思ったというか

まあ結構その

ギターブへのアクセス

の

権限制御問題は結構

自分は運用してる

中々悩ましいところは

あって

まあ悩ましさはいくつかあるんですけど

例えばそのまあこの記事で言われてる

PATと秘密カギをどこでどう交換するのか

っていう話とか

あとその

保管者としてその

ギターブ運用とかだと

なんでしょうね

例えばどのリポジトリに

どういう権限を持つかっていうものを

ギターブのGUIで

設定しないといけないんですよ

なんで

決め細やかにやろうと

思えばやるほど

ギターブアップの数がどんどん増えていくし

それをGUIで

ある程度保守しなきゃいけない

IPAとか入ってるんで頑張ればできるんですけど

結構大変なはず

なんでなかなか辛いことになるはず

なんですけど

その辺も多分このシステムがあれば

かなり

コネシエルルーレットみたいな

ところを書けば

いい感じに

定義できるようになってるっていうのが

いやいいよね

っていうところを

って感じですね

あとはその

結構

頑張って理解しながら読んでたんですけど

最後のどっかでちょろっと

紹介されてたのはSTS

オクトSTSっていう

ギターブアップがあって

これがちょっと似たようなことができる

んですよ

なんで

そこで僕は割とこの記事で

達成したことをすんなり

理解したんですけど

何にしてする体力がなくて

ギターブアップないとかで

自分だったらこのオクトSTSがいいよな

って個人的に思ったりしてて

まだちょっと試してないんですけど

さっき言ったその複数のギターブアップを

頑張って管理しなきゃいけない

みたいなところから

ある程度解放されるっていう

ソリューションですね

ただこのメルカリの事例

メルカリさんの事例だと

このギターブにその閉じずに

Googleクラウドからの接続っていう部分もあるんで

その辺はこのオクトSTSでは

吸収できない

吸収できないところであるんで

まあまあまあ

内施するのは順当なのかな

ってところですね

XSリークス攻撃について

はい

以上です

これはですね

頭を黙って読み始めてしまった

頭を黙って読み解き始めてしまったんだけど

これはね

いやでもよくできてる

と思いますよ本当に

ストレッションアクセルとか

そうですね

だからあれかな

実体としてはギターブアップが一ついるんだろうな

おそらくだけど

だからそのアップへの

いやそんなことないか

そんなことないわ

そしたら意味ないもんな

ストレッション

読んでいきます

はい

申し訳ないですけど

これはね本当に素晴らしいですよ

素晴らしい

はい

まあいいや

じゃあ次

お願いします

スペキュレーションルールスを利用した

XSリークス

セクコンCTF13の

オーサーズライトアップ

です

たぬきうどんっていう問題の

ライトアップですね

作文した人のライトアップです

CTFアドベントカレンダー

2024の記事ですね

えーっと

なんか

俺の持ってくる記事さ

うん

紹介すんの

いつも大変なの

なんだよな

うーん

なんか

読む感想部分だけでも

えーっと

なんか

TLDRをもう記事の中に

書いてくれてるので

読んじゃうと

次のような状況を満たすときに

スペキュレーションルールスを用いた

XSリークス攻撃を行うことができます

1 攻撃者が被害者のサイトに

スペキュレーションルールスを

損にすることができる

2 どのページがプリフェッチ

プリレンダーされたかを

攻撃者が知ることができる

これらの状況を満たすとき

セレクターマッチするより

CSSセレクターを利用して

取得できる範囲の情報

漏洩させることができます

そもそもXSリークスという

クロスサイトリークスの説明

攻撃を知っていますか

知りませんでした

今は知ってる

クロスサイトリークスの略称なんですけど

サイトをまたいで

難しいな

これの話をたぶんしながら

あれしたほうがいいんだろうな

でもこれって

例えばだけど

その

任意のURLをどうにか

XSSが生出したときに

攻撃を知った情報収集用の

URLの

パラメータに

取りたい情報を

付与して

アクセスさせて

アクセス録画収集するとか

そういうような

そういう感じなんですけど

どっちかというと

買い概念って言ったほうが

いいのかな

感覚的には

要は

XSSまでは

いかないんだけれども

ページ上に描画されている情報を

外部にリークすることができる

なるほどね

例えば

できるできないは別として

例えばだけれども

CSSの

あれはなんだっけな

CSSの

ビジテッドか

CSSの議事クラスで

ビジテッドっていうのがあるじゃないですか

訪問済みの

リンクとかに適用されるやつ

あれで例えば色が変わったことを

外から

判別する

手段があったときに

あなたはこのサイトに

訪れたことがありますね

っていうのが

情報として1ビットで分かるわけじゃん

なるほど

話としてはそういう話

確かに

ふわっと

ふわっとする

それがそうって話じゃなくてそう

攻撃というか

問題としてはよくあるノートアプリで

なんていうか

ノートをバーっとリンクで並べて

表示するみたいな形になっていて

作為的に

コンテントが含まれる

レスポンスヘッダー

逆じゃね

コンテントが含まれないじゃなかったっけ

そうだね

コンテントが含まれる

ものを除き

レスポンスヘッダーを

一つ追加できる

っていう

機能がついてるらしいです

問題自体は見てないので分かんないけど

立ち替えて

Speculation Rules APIっていうのが

何なのっていう話をすると

ブラウザの登記的なページ読み込み

プリフェッジとか

描画

プリレンダーの動作をサポートする

APIですよ

スクリプトタイプ

スペキュレーションルールス

スペキュレーションルールスヘッダーで動作を指定するよ

っていう形らしいです

ルールのサンプルは

ノーションにもあったけど

ブログに書いてある通りです

MDNのウェブのドックスがありますので

細かいところはそちらを見てほしくて

基本的なアイディアは

これもブログからそのまま

引っ張ってくるんだけど

Wearのマッチングを利用して

そのノートのIDを漏えいさせること

要は多分これフラグの

ノートのIDはランダムに

割り振られるんだけど

IDが分かれば

そのページは誰でも見ることができる

って状態になってるんじゃないかなと

推測するんだけれども

なのでそこのノートのIDが分かれば

フラッグがそこに書いてあるから分かるっていう

なのでフラッグのIDが

知りたいよっていう形になってるっぽい

で

攻撃者は

自分のサーバーを参照する

イメージ要素をノートに

含めることでそのノートがプリレンダーされたか

どうかを知ることができる

要は

多分このBotの動作の話は先に

読まないといけないのか

多分

何らかの操作に紐づいて

CTFのサーバー側で

Botが動いていて

Botが何らかの特定の動作を

しながら

自分の

攻撃者が

自分が

用意したノートに

アクセスしにくるんだと思うんだけれども

そこで

うまいことクロスエイトリークスを成立させて

そのBotしか知り得ない

フラッグが書いてある

ノートのIDを外に

リークさせるっていうのをやってね

っていう話っぽい

うん

はい

イメージがプリレンダされたかどうかが

わかるのでそれを利用して

フラッグのノートのIDに一部マッチしたときに

一部のノートがプリレンダされて

マッチしないときプリレンダされないような

オラクルが作成できれば

クロスエイトリークスが成立するよ

っていう話ですね

要は1ビットずつバーってチェックしていって

最終的に完全一致のノートのIDが

手に入れば

探索的テストの重要性

OKっていう感じですね

はい

ハズっていう疑似クラスだっけ

疑似セレクターだっけ

疑似クラス

疑似クラスを使ってあげて

得点ノートID

得点ノートのIDのページが存在したら

自分のサーバーに向けたイメージ要素を

イメージ要素とかを含む

自分のノートを

プリレンダさせて

IDの特定をする

アイディアらしいです

読んでくださいっていう感じになっちゃうんですけど

でもなんか

めっちゃ面白そう

読んでみよう

このスペキュレーション

ルール僕も知らなかったっすね

知らなかった

こんなのあるんだ

エクステメンタルな機能では

ありつつ

ブラウザコンパビリティ

Firefoxは実装してないけど

Chrome Tetcher動くんですね

Safariも実装してないな

へー

おもろ

よく考えるな

なるほどっすね

うん

これは面白い

これはもう

流石に

ソースコードは

エクスプロイトかこれは

エクスプロイトだね

まだちょっと動いてるかどうかわからないけど

どうなんだろう

結局でも

想定外の回で

バカスが解かれちゃったらしいんだけど

あ、そうなんだ

マークダウンの

多分

Evilのマークダウンそのまま通しちゃって

XSSで強大できちゃったらしい

あーなるほどね

大変やな作文側も

本当だ

悲劇想定外

なるほど

ちょっとこれも読んでみよう

はい

ありがとうございます

はい

はーい

じゃあ次は

あーこれまたしか

レイアX爆落事業部における探索的テストへの取り組み

レイアXテックアドベントカレンダー2024の記事ですね

えーと

なんか読むことあるかな

えーっとね

タイトル通り

なんですけど

探索的テストっていうのをやってるよ

っていう記事です

えー

探索的テストっていうのは

テストケースを事前に詳細に定めず

テスト設計とテスト実行を並行して行う

柔軟なアプローチですよ

っていう話らしくって

うんなんか

向き不向きはあるけれども

システムやプロダクトの未知の部分を

発見するのに非常に効果的らしい

うん

なんか別にこれ散々言ってるんだけど

その

なんかテストとかQAとセキュリティ

まあセキュリティテストって結構相性がいいよ

って話を散々してると思うんだけど

まあこれできるならちょっと勉強すれば

セキュリティテストもとりあえず回せるようになるんじゃないの

極みだなと思って

うん

どうなんだろうな

って思った感じですね

なんかこういう

本当にガチである種の

セキュリティテストに近いようなテストのアプローチも

ちゃんとあるんだなっていうのが

ちょっと新鮮だったかも

うん

なんかこれモンキーテストとの違い何なんだろうな

と思ったけど調べたら

あれですね

探索的テストは何かテストして

その結果に基づいて

じゃあ次こういうテストしようかみたいな感じで

ああ

割と目的とか手順とか

こういう観点で見ていこうみたいなのを

結構柔軟に決めながら

進めるみたいな感じ

めっちゃセキュリティテストじゃない

そうだね

確かに

確かにね

確かに

ただやるには

セキュリティの知識はある程度必要とか

でもそうだね

スター

エピソードをシェアする

メッセージを送信

Sota Sugiura

サマリー

目次

スター

コメント

こちらもおすすめ