00:00
こんばんは、Replay.fm第79回でございます。
こんばんは。
こんばんはっす。
はい。
リスクアセスメントの重要性と個人的な失敗談
いやー…寒く…
あったかくなってきたね。
そう…そうだね、逆だね。
うん、あってるよ。
なんか…どうなんだろう、全国あったかいのかな?
昨日ぐらいから滋賀はちょっと異常なぐらいあったかくて、もう春だなって感じがするんですけど。
えー。
18度とか、今日は。
今日は確かに割合あったかかった気がするな。
全国的にあったかいんですね。
いやー…あの…最近小話なんですけど。
リスクアセスメントの大事さを痛感した出来事が2つありまして。
1個目がね、なんか今マンションに住んでるんですけど、
そのマンションの管理組合が自主的になんか…多分自主的に毎年防災訓練をやってて、全住民を対象に。
で、3回2回目なんですけど、結構面白くて、
多分近くのうちの市の消防署の人を実際に呼んできて、
だからその時来てくれたら消防車がうちの前に止まるっていう状態になるんですけど、
消防員の人に消火器の使い方の訓練的なアクティブなやつと座学みたいなやつで結構いろいろお話をしてくれるんですけど、
なんかその中で、対策かな、食料備蓄しましょうとか、ガラス被産防止しましょうとかで、
うちのマンションでアンケート取ったらこんな感じだったんですけど、どうなんすかねみたいな話があったんだけど、
消防員さんの言葉でもう基本的にもう震災起きると思って全部やった方がいいみたいなこと言っていて、
割と通ずるものがあるなというか、
マレアにも感染するしフィッシングも引っかかるし、サプライチェーンにも引っかかると思ってやるぐらいがやっぱいいよねっていうので、
防災も一緒だなっていうのをちょっと、ちょっとなんか説得力が違ったというか、
そうですよねと思って防災グッズ見直そうと思ったのと、
もう一つは外国が、アーティストの外国が大好きなんですけど、
とても大事にしていたスノードームのグッズがありまして、
それを昨日の朝、証拠デスク、
これもリスクアッセスメントの甘さが出てるんですけど、証拠デスクの上のスピーカーの上に飾ってたんですよ。
スピーカーの揺れで落ちるやつや。
そう、マックミニを今デスクに置いて配線いじるために証拠デスク上げ下げ上げ下げしてデスク揺らしたら、
シンプルに。
ドンドンガシャンっていう最悪な音が聞こえて、絶望しながら朝かいに15分遅刻するっていうイベントがありました。
LLP24のやつだよね多分ね。
かな。
私は大事に箱にしまってあるので無事です。
いやー、もうね、マジで、あのー、本当に結構虚無の気持ちで片付けながら、
もうマジでリスクアッセスメントした方が良かったなって本当に本気で後悔したから、
なんか、結構ね、もう千人モードみたいになっちゃってて、片付けぐらいに。
仕事でも同じ思いしないように、なんか何か甘く見積もるならやめなきゃなーみたいな気持ちで床のガラスを片付けてましたっていう。
うわー、これメルカリでいくらすんだろうと思ったけど普通に2万とかすんのね。
そう、3倍ぐらいにね。なんかそもそも結構もう割と早く売り切れたし、量産もできるようなもんじゃないだろうし、
まあ、現代だとね、転売の皆さんがイキイキとやってるんで。
いやー。
まあ一応その、あれですね、あのー、ちょっとできるかまだやってないんですけど、
そのガラスの縁全部綺麗にバリ取りして、そのドームとしてじゃなくて、オルゴールなんですよ。
オルゴールのグッズなんで、オルゴールとして使い続けられないかちょっと試そうと思ってるんですけど、
はい、もう皆さんも、まあいろんなそうですね、まあ今回そのドームでしたけど、
なんか大事な機材とかですね、水の近くにパソコン置くとかそういうリスクには備えていきましょうっていう話でした。
そっか、これオルゴールになってるのか。なんか箱から出してないからさ。
今鳴らしながらちょっと喋るか。これ聞こえるかな。
あー。
あの分かる人は分かる曲なんですけど。
はいはいはいはい。
この顔、もう悲しくなってきたわなんか。今もう目の前でもバリバリにバレた。
絶妙です。かわいそうすぎる。
いやー、まあまあ。
あとで新品未開封のやつの写真送ってあげるね。
なにこれまじで。ふざけんなよ。あの、もうちょっと、はい止まってください。
いやー、かわいそうすぎるな。
もう一個買っとけばよかったのに。
あー、それもいいね。それもいいリスクヘッジだね。
冗長性ですね。
うーん、確かに。まじでね、ほんとにまじで本気でちょっと今デスクマリ見直してるんで。
みなさんも気を付けてくださいって感じです。
まあ、じゃあそんな感じでわけわかんない話をしましたが、本編行きましょうか。
お便り引き続き皆さんお待ちしております。ハッシュタグでもGoogleフォームでも大丈夫です。
すごいなんかお便り募集っぽい喋り方が板についてきたね。
でしょ。なんか十数回ぐらいだと思うんで。
じゃあ、最初お願いしようかな。
GitHub OIDCトークンとカスタムプロパティ
アクションズOIDCトークンズナウサポートリポジショリカスタムプロパティスっていう記事でございまして、
GitHubのチェンジログですね、これは。
ちょっとサラッとした記事だし、サラッとしか読んでないんだけど、
たぶんGitHubのOIDCのクレーム数の中にカスタムプロパティが入るようになったっていう話かなと思ってるんですけど、
あってますかね、きっと。
あってます。設定すればオプトインで入るって感じかな。
オプトインなんだ、なるほどね。
このカスタムプロパティを含めるっていう設定をしてあると入るって感じだね。
何でもかんでも入ってこないんだ。どういう形で入るんだろうね、これ。
実際に見てみないとわかんないね。
ドキュメントあるんで、それ見ればわかると思うんですけど。
レポプロパティアンダースコアプレフィックスが付くんだ。
なるほどね。面白いね。
地味便利な機能ということで。
なんか良さそうと思いつつこれ、あんまりユースケースパッと思いつかなかったのと。
そうなんだよね。地味良さそうなんだけど。
なんか夢広がりそうな雰囲気だけ出してきてるけど、記事にはユースケースとか書いてないのと。
あとほんのちょっと気になるのは、これカスタムプロパティって権限ちゃんと統制してれば大丈夫だけど、
そうじゃなかったら割と書き換えられる値ではあって、
一方でYDストークンの別のフィールドって、
基本的には改ざんの余地がないGitHub側がコントロールしてるからってなって、
だからこれに頼って大事なものやりすぎるのはちょっとリスキーな場面もあるのかなっていうのは、
ちょっと思ったりもなかったりしたって感じですね。
それ考えるとなおさら何かどこに活かすんだろうなって結構気になっているんですよねって感じ。
ただなんか便利そう。
なんかでもプロダクションレディなレディですよみたいなラベルをカスタムプロパティでつけると、
初めてアクセスできるOctoSTSのトラストポリシーがあるとか面白いかもね。
面白そう以上に何かが出てこないな。
でも確かにそうか、そういう感じで。
なんかそのGoogle CloudのWorkload Identity Federationで、
割と絞ってユースケースを連携するイメージを持っちゃってたけど、
確かにその間ね、アトリュートコンディションとかで広く最初に絞るみたいなので使えたりはするのか。
特定のプロパティがついてたら、これは使っていいよっていうので、
特定のプロパティをつけるっていうところに対して何らか動作を効かせるっていうのは一つのやり方かもね。
そうすると別にプロリクエストを出してうんぬんかんぬんとかいらんし、
Google Cloudの設定を変えてうんぬんかんぬんとかはいらなくて、
別にワークフローをそこから切り離せるみたいなメリットがあるかもしれないね。
あとあれかもな、なんかその、
Workload Identity連携とかってその、
YDCの連携先のメンテナンスをするときに消し忘れとかで残っちゃってみたいなパターンがあったときに、
本来はちゃんと掃除してね、なんだけど、
プラスアルファでカスタムプロパティで、
プロアクションレディーもそうだし、
リタイアドみたいなのを設定できるようにして、
動いてるものじゃなかったら弾くみたいな設定を入れておくとかはガードレールとしてはもしかしたらありなのかもね。
そうだね、ありかもしれないね。
消し忘れてるとか。
あとはなんかあれかな、
なんだっけ、
分からん、そんなことがあるのか分からんけど、
難しいな。
これ見て、いやー、ごめん何でもないわ。
でもカスタムプロパティを既に活用してる組織だと結構イメージ湧くのかなっていうのは今ちょっと思ったな。
なんかこれのために何か無理矢理ひねり出すというよりかは、
既にあるちゃんと運用されているプロパティを活かしてガードレールを作るとか、
なんかそういう演習なのかな。
なんか複数の事業をやっていて、
GitHubのオーガニゼーション1個でみたいな、
メルカリみたいなパターンとかだともしかしたら生きるパターンのところもあるのかもね、
カスタムプロパティで。
リポジトリの名前のプレフィックスではなくて、
カスタムプロパティで、例えばメルカリ、メルペインみたいなのを分けて管理してますみたいなのをやってるときに、
それ見て何かするとかもしかしたらできるかもね。
確かに、擬似アイソレーションみたいな。
ただワークロードアイデンティティフェデレーションのときは別にそんなに旨味がないような気がしていて、
どうなんだ。
結構、僕らが仕事で直面してないけどもしかしたらあるかもなっていうのは、
割と幅広く緩くアクセスさせたいものがあったときに、
それをいい感じに絞るみたいなのはあり得るのかもな。
パッと思いつかないけど、なんだろうな。
アクションズシークレットじゃなくて、シークレットマネージャーで管理してて。
オーガニゼーションワイドシークレット的なものをGoogleクラウドとかAWSで管理してて、
そこに対するアクセスをリポストリ単位でかっちりやるほどではないんだけど、
でも全リポからアクセスさせるのはちょっとさっさかにみたいなときとかにカスタムプロパティで制御するとか。
分かんないけど、そういうのとはいいのかもな。
確かに。
でもこれはユースケース募集感がありますね。
パブリックプレビューなんでどうなるか分からないんですけど。
でも夢が広がり、話してると意外となくはないなって気がしてきた。
面白い。気になりますね。
こういうのがありますよっていうのがあれば、ぜひお便りで教えてもらえると助かります。
助かります。
じゃあ次いきますか。
ランサムウェアとセキュリティの倫理
ランサムウェアで考えるセキュリティの倫理っていうスライドなんですけど、
最近倫理に長谷川さんがハマってるからだと思うんだけど、
セキュリティにおける倫理みたいな部分の話で、
ランサムウェアを題材に倫理って何かを考えてみるっていうので、
それを題材に考えてみたよっていうスライドなんだけれども、
よく言われる話としてランサムウェア被害にあっても、
身の白金を払うべきではないっていう風な主張がまず前提としてあって、
支払うべきではない理由として、例えば支払ったとしても、
向こうがそれに応じて良くしてくれるっていう保証は全くないよねっていう話とか、
あとはそもそもそれって何ていうか、犯罪者に対して資金提供してることになるから、
余計犯罪被害が増えるだけじゃんみたいな話がまずあったりして、
特にこの倫理っていう部分で言うと、支払うことが犯罪者に対して資金を提供することになるっていう部分が、
倫理的な論点があるよねっていう話。
その上で、これって確かに一定正しさはある、一理あるみたいな話があって、
確かに犯罪者に対して資金提供しているっていうのは事実としてあるんだけれども、
それっていかなる場合においても禁じられるのかどうなのかみたいな話を論じていて、
例えばだけど、家族が誘拐されました身のしろ金を要求されていますっていうシチュエーションだったら、
それはしょうがないよねっていうふうに、罠にもすがる思いで身のしろ金を出すっていうこと自体は、
もう仕方がないよねっていう理解が得られるんじゃないかっていう、
そういう考え方もあるよねっていう一方で、ランストメイヤーの場合は、
家族が誘拐されていますっていうシチュエーションだったら、
人の命と家族が誘拐されています身のしろ金を要求されていますっていうところで、
身のしろ金を払うっていうのは、それも別にランストメイヤーの話と同様に、
犯罪者への資金提供につながるっていう側面はあるんだけれども、
でもちょっと難しいな、
人の命とお金、犯罪者にお金を支払うっていう資金提供してしまうっていう部分で、
比較して議論しているっていうのがそのシチュエーションであって、
ランストメイヤーの場合は、難しいな、
そういう議論があるからなんか正当化されるような感覚があるみたいな話なのかな、きっとね。
で、ランストメイヤーの場合は何と何が比較されるんだっけっていう話をしてくれてるっていう感じですね。
で、なんか公理主義っていうのがあって、
これは最大多数の幸福を基準に判断する倫理学の考え方っていう、
多分最大多数の最大幸福っていうことを言ってたベンサムっていう人がまずいまして、
高校で生計とかやってた人は多分、生計倫理辺りを取ってた人はもしかしたら知ってると思うんだけど、
っていうのがまずあって、公理主義っていうのがまずあります。
公理主義的な考え方をするんだったら、
身の代金を支払う支払わないことによって得られるその便益と不利益を比較考量して、
便益が最大となるような選択を取ることが倫理的だよねっていうふうなことを言っている。
なんかある種の思考実験として言っている。
で、経済的負担や犯罪者への資金提供を行ってでも、
漏洩を防ぐべきかどうかを判断することが公理主義では求められるよと。
機密情報の漏洩が防がれるっていうのが得られる便益として、可能性があるよっていうのが、
身の資料金を支払う場合の便益としてあるんだけれども、
人の命とお金みたいな、家族の誘拐みたいなシチュエーションで出てくる比較考量に対して、
機密情報っていうのがお金の、天秤の逆側に乗っかってくるわけなんだけれども、
それがどれぐらいの量だったら機密情報の漏洩が防がれるっていう便益が、
経済的な負担あるいは犯罪者に対する資金提供みたいなところより重くなるのか、
みたいなのを考えるのが倫理なんじゃないのっていう話をしている。
で、例えばマイナンバーを何万件みたいな話とか、
情報預けた個人の事情とか感情はどうなんだみたいな話とか、
別にここでは全然深掘りしてなくて、ライトニングトークだし、
なんていうか別に正解がないので、こういう論点があるはずだよねっていうことを言っていて、
こういうのも考慮せず身の白気を押し払わないっていう意見にただ従うだけっていうのが、
果たして倫理的な対応っていうふうに本当に言えるんですかっていう、
問いかけをしてくれてるっていうスライドですね。
ちょっとごめん、なんか説明がたどたどしくなっちゃったんだけど。
いえいえ。
いやー、これは、なるほどぐぬぬってなりましたね、僕は。
あんま、ちょっと盲目的になってた側かなと自分は思ったんで、
身の白気の例えはめちゃくちゃわかりやすかった。
確かにね、という。
正解ないですよね。
正解はないですね。
正解はないし、これ公理主義の話で言うと、
量的公理主義っていうのが最大多数の最大幸福っていう話で、
もう一個J.S. Millっていう人がいて、
その人は質的な公理主義、質的な快楽主義みたいなところを主張していて、
量的うぬんってアホらしいよねって、
どんだけ量的に満たされていたとしても、
質が質的に満たされていなければそれって人間じゃないよねっていう、
割と尖ったことを言っていた人がいて、
そっちの論点でも見るとどうなのかなとかはちょっと思ったな。
犯罪者への資金提供みたいな論点ってどっちかというとそっちに近いような気もしていて、
経済的な負担が発生すると機密情報の漏洩が防がれる可能性っていうところは、
純粋に量的な公理主義の論点で話せるような気がするんだけど、
世の中としてより良い方向に行くためには、
犯罪者に対して資金提供はしない方がいいよねっていうのが多分、
ある種の質的な論点として入ってくるような気がしていて、
そのためにはもう起きてしまった事故に対して、
いくらか機密情報の漏洩が防がれるっていう可能性があろうとも、
もうそれはしょうがないよねって、
質的により良い人間社会みたいなものを作るためにはもう一手しょうがないよねみたいな論点も、
もしかしたらあるのかもしれなくて、
結構この倫理で考えるっていうのはちょっと面白いなって思いながら読んでました。
なるほどね。確かにね。
実、そうだね。
難しいね。モデリングが難しいな。
あとはなんかその、犯罪コミュニティへの、
僕らにとっての不便気であり、彼らにとっての便気となる行動を取るかみたいな部分で言うと、
マクロに見るかミクロに見るかでもう変わり得ちゃうなって気はしてて、
ミクロに見ると自分たちの目線で言うんであれば普通に何かというか、
便気側に倒れる可能性の方が高くなっちゃう気はするんだけど、
もうちょっとマクロというか、何なら世界レベルで見た時には、
まあ、やらない方がいいよねっていうのはなる。
そういう風にはなる気はしてて、でもなんかそのために自分たちが不便気をこう持るんだっけみたいな部分を、
レバーを引くっていうのは、その場面に立たされたら結構難しいのかもな。
難しいね。
思ったりしたな。
まあ、基本的に難しいね。
あとはこのロジックで言うと、
もしかしたら被害範囲とか何が盗まれたかにもよっちゃうのかもなとか思ったりするな。
いやー、どうなんだろう。
まあ、でもちょっと難しい意思決定になっちゃうよな。
考え出しちゃうと。
まあ、正解はないですからね。
いざじゃあそうなった時に。
まあ、でもなんかそういう難しい意思決定を避けるっていうのもセキュリティーではあるよな、たぶん。
うーん、そうだね。
そうなんだよね。
まあ、なんかこの立場に立たされたことないから言える、まじでガヤの意見でしかないけど、
そのもう払わないってなんか、払くっていうのがなんか意外と、
まあね、これが思考法義なのかもしれないけど、
いやなんかさ、真剣に考えだすと変数結構多い気がしてて、
何のデータが盗まれたかとか、
場合によって相手のアクターが誰なのかみたいな、
で、そのアクターは過去の別のインシデントでは約束を守ってんのかどうかとかも変数に入ってきちゃうわけで、
で、もしかしたらそのじゃあ実際に交渉してみてどうかみたいなのも評価しなきゃいけないみたいになると、
なんかますますその意思決定が難しくなるし遅れうるのかなとか思ったりしたって感じですね、今。
なんかそのコスト払う価値がなんかその、もう事故が起きてしまって、
まあもう法的には責任を、少なくとも法的には責任を負わなきゃいけないし、
社会的責任もまあ負わなきゃいけない状況において、
なんかそこになんかコストを割く意味って何なんだろうなってちょっと思ったというか、
まあでもこう思うこと自体が逃げなのかもなとかも思いつつ、
まあ難しいなって感じですね。
難しいですね。
いやー、まあ、あとなんかどうなんだろうな、
なんかその本当になんか全然そのIT業界に詳しくない人の話をちょっと聞いてみたいわ。
なんか直近だとさ、その朝日グループとかがさ、
もう身の白金払わんってその大々的に宣言をしていて、
なんか僕みたいなその立場からすると、
なんかまあかっこいいって表現は変だけど、
まあその意思決定自体は尊重するし、
それをなんか会社として外に、
まあ社長の口から言い切ってんのもまあまあ一貫したスタンスとしていいなと思いつつ、
なんかあれをその一般の人が聞いた時に、
なんか実は無責任だと思うのか、
どう思うのか、なんかそこは結構ちょっと気になったな。
うーん。
まあ、うーん、そうね。
なんか、まああれの場合なんか、あれ別に漏れてないよね、その個人情報とか。
いや漏れてたんじゃない。
漏れたんだっけ、漏れたのか。
うん、漏れてる。
うん。
まあなんか運善万華とかそんなレベルではなかったはずだけど、
まあまあそれなりには漏れてた。
うん。
ちょっと。
暗号化されて止まっちゃったじゃなかったんだね、なんかそれで済まなかったのか。
なんか処方はその漏洩はわからんって感じ。
あ、そうだ。
あのアサギのサイトはね、年間認証を求められるっていう。
確か、えっと、
ああ、なんか最初の時点ではなかったよって言ってたって感じかな。
ああ、やっぱそうだね。
いやでも漏洩してるわ。
漏洩したと言ってはないけど、その流出の可能性がある。
だからもうその、漏れたか漏れてないかは断定できないし、
まあまあ10、100漏れてるでしょって感じなのかな。
なるほどね。
ああ、であれだ、インターネット上で公開されたっぽいっていうのもあったんだね。
だからまあ漏れてるんだろうね。
うん。
で、お問い合わせした人とかで150万件とか、
まあ180万件弱なのかな。
うん、はい。
まあまあこれでも取り戻せないっていう仕切りとしたケースもありますって話でしたね。
はい、まあ皆さまちょっと答えのない問い掛けに思い馳せてもやもやしてもらって。
まあでも大事ですね、こういう耳が痛いなと思いました。
じゃあ次行きますか。
AI時代を生き抜くセキュリティエンジニアの条件。
AI時代を生き抜くセキュリティエンジニアの条件
これが、
上野さんですね。
PenFestか、上野さんのスライドですね。
で、PenFestはあれですね、学生向けのセキュリティ系の割とデカめのイベントって感じで、
そこでの登壇された内容なのかなと思うんですけど、
ようやくお書きそこにてどういう話かを思い出しながら喋ると、
文字通りそのAI時代でセキュリティエンジニアってどうやって生き抜けばいいんだっけみたいな話で、
皆さんご存知の通り、AIがいろんな仕事を置き換えるじゃないけど、
いろんな部分で、
いろんな可能性を押し広げている、
ここ2年でございますが、
セキュリティ領域においてもそれは同じことですよねって話があって、
攻撃する側でいうとエクスプロイトをAIに書かせるとか、
前もちょっと紹介しましたけど、
ジュニアミドルの人がAI使って脆弱性探して侵入するとか、
そういうこともできるよねって話もあるし、
また防御面でいうと、脆弱性を発見して修正パッチを書かせるとか、
そういう部分でもどんどん性能が上がっていってますよと。
なのでこの辺をだけができるっていう部分が、
ある種民主化って表現がストレートで出されてるけど、
AI使えば誰でもできるようになりつつ、
どこまでかレベル感あるけど、
できるようになりつつあるよっていう部分で、
その前提において、
AIでも大体できない人間の専門性はどこにあるんでしょうみたいな部分を
掘り下げていってくれてるような、
おそらく発表ないしはスライドになってますという感じですね。
結構丁寧に、多分学生向けっていうのもあって、
丁寧に書いてあって面白いなと思ったんですけど、
そもそもLLMの特徴とか制約から弱点を知ろうみたいな部分で、
いろいろ話を書いてくれていて、
この辺はちょっと読んでくださいというか、
LLMキャッチアップしてる方だったら知ってるかなっていう部分を
丁寧に解説してくれてるという感じ。
結構そうじて表現は難しいんですけど、
めちゃくちゃそうじて言うんであれば、
LLMって基本的には次の文字列予測するくんというか、
そういう確立機械でしかないっていう部分があるんで、
例えば複雑な文脈を読むとか、
あとは暗黙地みたいなものを読む、
暗黙地っていうのはスライドの表現でいうと、
言語化されてないとか知識化されてないものっていうのは、
学習データにそもそもなり得ないので、
そういうものはできませんよねみたいな話とか、
あとはそれこそさっきのランスメーカーの正解がないって話もありましたけど、
そういう正解がない問題に対して、
ゼロ1かの判定っていうのはやっぱりできないし、
これが正解っていう学習データもないので、
そういうものも苦手だよねっていう部分が、
例えばで言うと挙げられてるって感じですね。
その過程において、
2つ条件を挙げてるのかな。
1つ目の条件は、
人間ならではの直感と攻撃者の意図の動作っていう部分が書いてあって、
その攻撃は何で行われたのかとか、
そこに合う戦略的な意味を理解することは難しいんじゃないかとか、
またその前提になったら、
この時代に来ていくエンジニアには、
攻撃者が何を考えているのかみたいなコンテキストをきちんと、
見抜く力が求められるんじゃないかみたいな話があったり、
第2の条件部分は、
アプリケーション使用そのものに潜む結果に対しては、
AIは無力に近いよねっていう話と、
またAI筋力エンジニアでは、
行動確触になる以上にシステム全体の制御性を確認する
観察役としての能力が問われるみたいなことを書いてるって感じですね。
第3のところもあるのか、
信頼を築く対応力みたいな部分は、
人間関係の問題でもある部分は人間がやらなきゃいけないとか、
あと組織文化としてセキュリティをインストールしていくっていう部分も、
AIには大体難しいよねみたいな部分がありますって感じですね。
セキュリティエンジニアの知識地図っていう本が、
これ上野さんが書かれた本があるんです。
上野さんプラスアルファかな、書かれた本があるんですけど、
その中でいろんな触手の紹介されてるんですけど、
その触手ごとにこれを当てはめていくとどういうことなんだっけっていうのを
バーッとまとめてくれてるっていうのが後半になってますという感じです。
で、なんかノーションのメモに僕も書いたし、
Gregationも書いてくれてるけど、
第2条件の1つ目はもう突破されるの時間の問題なんじゃないかなみたいな部分が
結構個人的には思ってて、
具体的にはアプリケーションの使用そのものに潜む欠陥に対しては
AIは無力に近いみたいな部分で、
スライドでは設計意図みたいなのを理解した上で、
指摘しなきゃいけないみたいな部分があるけど、
この辺はそのうち突破されるんじゃないかなみたいな気は個人的にはしてる感じです。
そうね、書いたんだけど、突破されるっていうよりは、
そもそも実は言語化が可能、あるいは究極的には形式検証とか、
だいぶ前だけどこの人が紹介して、
数学的に検証可能な領域だと個人的には思っていて、
究極的にはだいぶ難しそうな気がするし、
ビジネスロジックとかも多分言語化が可能というか、
こういう状態がNGなんですよっていうのは、
多分伝えることができると思うんだよね、言語化して。
それをLLMが判断するっていうのもできなきゃねえよなと思っていて。
あとは逆の話もある気がしていて、
言語化できる状態に落とし込むみたいなのも当然ある。
AIが必要な情報とかフォーマットを人間が用意しなきゃいけないっていう、
しなきゃいけないっていうか、
用意しないとそこに活かせないっていう状態になるんじゃないかなっていう。
今もなんか概ね赤字以外もそういう傾向あるじゃないですか、
ドキュメント、今までは人間が書いて人間が読むドキュメントだったけど、
絵が読めないと設計意図を理解できないとそもそもコードも書けないじゃんとか。
データフォーマットとか置き場所見直そうねみたいなのと同じように、
脆弱性を見抜くために必要なコンテキストとか情報はどこに置いてどうやって食わせるのかみたいな。
その時にフワッとした仕様書じゃダメだよねとか。
その部分にある種追い込まれるじゃないけど、
AIを生かし切るっていう土俵に立つならそこに向き合わなきゃいけないっていう感じのところになるんじゃないかなって気がするね。
究極的には多分人間も一緒なんだよな。
人間がやったところでその仕様書がフワッとしてたら、それが意図通りかどうかわかんないっていうのは一緒だから。
だからそこで長年の勘とか、これはこうだよねとか、
うちの会社のこのサービスはこうだよねみたいな部分を察するのはAIには無理っていう話あるけど、
その部分が仕事として残るかというと、逆にそれが仕事として残っちゃう会社で働きたいですかみたいな部分。
すごい意地悪な言い方だけど、僕は思っちゃうかな。
競争が激しいこの社会においてその状態で他の競合他社と渡り合えんだっけって言われると、
結構厳しいスタートラインだなって気はするんじゃないかな。
言うは安しちゃうんですけどね。僕も全然できてるわけじゃないんですけど、将来的には長期で見るとそうなるんじゃないかなって気はするな。
めっちゃいいまとめですね。
キャプチャーで引っ張ったけど、技術がどれほど高度化しても責任の根幹にあるのは人間が人間を、
人間の悪意から守るという極めてアナログな営みっていうフレーズがあって、これは確かにいいっていう。
めちゃくちゃいい。そうなんですよね。
悪意のある人間から守っていきましょう。
おおむねでも同意というか、全体的には確かにそうだなと思ったので、頑張っていきましょう。
そうだね、頑張っていきましょう。
ありがとうございます。
あと結構、そうはいってもAIに渡せる状態を作るみたいなのを、渡せる状態を作らないといけないみたいなのも意外と難しいよなと思っていて。
今めっちゃ過渡期だと思うね。
そうね、今が一番しんどい時期なのかもしれなくて、我々が日々やってるようなディペンダウォットアラートをさわきましょうみたいな、あれとかもさ、
あらゆる前提条件コンテキストみたいなのをなんとなく頭に入れたい上で、これは今は別にやらなくていいんじゃない、急がなくていいんじゃないって判断をしてるわけだけど、
あの量のコンテキストを全部今突っ込めるかというと、ある種機械過渡な状態にして突っ込めるかというと、まだちょっとそういう場が整ってないよなとは思っていて。
なんかハンドメイドの必要性がまだあるよね。
そうそうそうそう。
だからそこを埋めにきてるサースとかめっちゃあるよなって気がするな、なんていうか。
もしかしたらもうそもそもモデル作ってる側がいろんなものを今埋めにきてる状態なんで、そこは成熟してくるんだろうなって気は勝手に思ってますけどね。
AIコーディングとかも多分一緒だしな。
同じコードレビューしないようにスキルを手入れするとかクロード.mdを手入れするとかそういう、どっちかしいかもな。
じゃあ次いきますか。
サービス乗っ取りと暗号通貨詐欺
さらっと私からなんですけど、
ウェブサービスを作って公開したら何か知らないアカウントが開発者を辞書していたっていう、
前のどなたでしょう、個人の方の記事ですね。
ペプシャハラス。
これちょっとこんなのあるんだと思って知らなかったです。
紹介なんですけど、
起きたことは記事のタイトル通りで、
この方が個人サービスを作って公開して、
Redditとかなんかで宣伝したところ、
全然知らないアカウントが、これ私の紹介です。
これ私のサービスです、使ってねっていうつぶやきをXに投稿していて、
それにこの作者の方がアクセスログを見て気づいたみたいな感じですね。
なんでこんなわけわかんないことをしたのかというと、
この知らないアカウントが、これ私のイケてるサービスだよみたいなのを言って、
そこに紐づく暗号通貨を新しく発行して、みんなに買ってねみたいなことをやろうとしてる。
やったのかやろうとしたのかわかんないですけど、やったみたいで。
なんでその人のいい感じのサービスを見つけて、
暗号通貨売って逃げるっていうやり口に、
この方が被害に遭われたっていう感じらしいです。
で、なんかでかいところだと、
オープンクロウがMoltbotになった時に同じことをしてたらしくて、
めちゃくちゃ多分こっちの方が成功してニュースにもなったみたいな話があって、
なんで結構、賢いなじゃないですけど。
おもろいね。
おもしろいなと思ってちょろっと紹介です。
これなんかちょっとやられたとして、被害に遭うとしたらこれを勘違いして買っちゃう人なんで、
僕らとはちょっとまた違う属性の人たちがハマってそうな気がするんですけど、
まあとはいえね、見に覚えのない、
お前のコインを売るなんて問い合わせが来ても嫌ではあると思うんで、
なかなかなかなかなっていうのと、
あとなんかこの、
このトークンを買うっていう価権は結構どうなんでしょうね。
ちょこちょこ盛り上がってるような、なんかね。
結構僕は全く興味がないというか知らないっていう表現があったらしいですけど、
そんなカジュアルにぽんぽんみんな買っちゃうのかっていう感じで面白いなって思いました。
なんかまあとても言い方悪いけど攻撃者目線だと、
まあかもというかそこを狙ってるんだなっていう。
学びでしたって感じですね。
いやーって思ったもんじゃないよな。
まあなんか難しいね。
なんかそのなんか、
いやーこれ本人はなんか被害が、
まあ悪用されただけで別に自分自身がめっちゃ何か不利益をこむったってことは多分なかったのかなきっとね。
最後に。
今回のこの方は多分ないんじゃないかな。
なんか飛び火して自分が恨まれるとか嫌だしね。
ああそうあるとしたらそっちな気がするね。
でもなんかめっちゃイシューが荒れるみたいな。
分かんないけどね。
本当に行くとこまで行っちゃうとね。
はい。
さらっと。
次は、
GitHub Copilotの承認スキップ機能変更
次も私でGitHubのチェンジログなんですけど、
Optionally Skip Approval for Copilot Coding AgentActions Workflowsっていうチェンジログですね。
これ何かっていうとGitHub Copilotお使いの方はよくご存知だと思うんですけど、
UI上、ウェブサービス上で動くコパイロットエージェントでプロジェクト化を作成すると、
GitHub Actionsの実行が人間がアップロードしないと動かないようになるっていう仕様があって、
この仕様自体はAIが変なコードを生成してとか、
そういう経路があるかはさておきコパイロット経由で何か悪いコードをプッシュしたみたいなところに対して、
人間のガードレールを入れることでセキュリティリスクを軽減しようというモデルになっているんですけど、
これをにオプトインでアップロードなしでそのまま実行するようになりましたっていうチェンジログですね。
さらっと紹介を話せばいいなと思ったのは、仕事でもやる人は話しちゃったけど、
これ一番最初コパイロットを使い始めたときはこの機能めっちゃいいなと思っていたというか、
立場的にはAIが書いた不確実性のある確率で出力されたコードにリスクの高いワークフローを触らせるというのは結構抵抗感があったみたいな部分があって、
なんでみんなこのコパイロットみたいな仕組みになればいいのになというのは当初思っていたんですけど、
自分がAIを活用していく過程で結構このモデルいけてないかもなって思っていた部分もあるというのが今の正直な感想で、
いけてない部分っていうのは単純にアップロードを押しに行かないとワークフローが動かないんで、
ボコスカボコスカプリクエストを立てているときに押し忘れててああってなって作業効率が落ちるみたいなのもあるし、
そうやってその大量のやっぱ開発をしていると、何段考えずに押すようになってしまう。
僕は多分立場上結構手前味噌というかあれですけど、だいぶ意識はしてるんでちゃんと見るんだけど、
95%開発者これも見ずにたぶんポチポチ連打するだけだろうなっていう気はしていて、
だから本当に意味がある機構なのかみたいな部分はちょっと思ってた部分であるんで、
コパイロットが打ち出したセキュリティモデルに対して世間のトレンドというかニーズ的には、
むしろあんまり不必要なトレードオフを生み出す装置だったのかなっていうのを、
このチェンジログを見てなんとなく思ったなっていうのと、
あとは現実上ローカルで動くAIとかどうにもならないんで、
やっぱその滅多滅多にやられてもフィーチャーブランチでワークフロー開演される分には、
悪いことというかリスクのあることはできないっていうふうにワークフロー側を堅牢にしていくっていう流れが順当なのかなっていう、
それ自体は人間に対する体制を得るっていう意味では別に今までってやるべきこととしては変わんないんですけど、
改めてそこは思ったというか、ちょっと一つすごく地味なチェンジログだけど、
勝手にGitHubの意思を感じ取って紹介という感じでした。
ありがとうございます。
今一ポイントとしてはオーガニゼーションワイドで有効化できないんで、
GitHub管理者の皆様は頑張って全力でポチポチしてもらってください。
クロードコワークとかにやらせてください。
ちょっとコワーク僕まだ使ってないんで、そんなできるかわかんないですけど。
これAPIから叩けるのかな。
出たばっかりだからな。
まだかな。
どうだろうね。
見てないな。
しかもテラフォームでできないのは見た。
それもそうなんですけど。
テラフォームめっちゃ遅いんで。
じゃあ次。
MCPゲートへの実装。
MCPゲートウェイとFintechs Groupの技術構成
Finatext Group AIコネクトハブの技術構成。
これはさらっとしか実際読んでなくて、
説明できるほどは理解してないな。
っていうか前段の記事を読んでないんだよね実は。
なるほどね。
前段記事僕もね、読んだんだよな多分。
読んだ気はするけど、読んでないな。
読んだ読んだ。
読みました。
ふざけちゃった。
でも要約するのはすごい難しくて、
興味ある人はぜひ読んでくださいって思っていて、
っていうのもかなり具体的に重厚に書いてあって。
めちゃくちゃざっくり要約しちゃうと、
MCPゲートへっていうのは、
MCPサーバーって普通に使うと自分の手元で
Notion MCP使いたいと思ったらGoogleって
公式のやつに書いてあるJSONコピーして
APIトークン貼り付けて、
そうやってMCP JSONファイルを太らせていく
っていうスタイルになると思うんですけど、
そうじゃなくて、
企業が管理している一つのMCPサーバーがあって、
そこであらゆるMCPサーバーが動いているし、
認証とかも通したらいい感じに
オース認証とかもされるっていう、
一箇所に集めて統制化に行うっていうのが
MCPゲートへの基本的には考え方だと言っていいと思ってて、
それをヘアテキストでどういうふうに実現しているか
っていう部分をかなり詳細に踏み込んで
話しているところって感じですね。
この記事の肝としては、
このMCPゲートへっていろいろソリューションが
既にあって、
僕が知っているやつだと
CloudflareとかGitHubとかも
登録して統制みたいな機能があるし、
記事で紹介されているのはAWSだったかな。
そうだね。
その辺使えば割とマネージドでできるんですけど、
ヘアテキストの場合は足りない。
特に金融系の事業をやっているので、
その辺の要件とか、
あとは日本の関西大きいみたいな部分に対応しようと思うと、
なかなかマネージドなものだと厳しかったんで、
マネージドを活用しつつ、
一部は自分たちで内製して、
認証とか認可とかをこういう風にしたよという部分を
かなり丁寧に書いてくれているという感じですね。
ここが推しですというよりかは、
ぜひ読んでくださいという感じですね。
そのMCPゲートへに対する解説度がめちゃくちゃ高いし、
細かい部分もかなり書いてくれているし、
これやりきる体力もすごいなというのは素直に尊敬ですね。
結構大変だなと思うんで。
いやー、体力がすごいね。
体力がすごい。
強いよね。
これは、
いやー、はい。
マネできないなーのはいですか。
なんかでもやらないといけないんだろうなーとは思いつつ、
結局、
しんどい時代だなっていう。
そうだね。
必ずしもやらなきゃいけないとは思ってなくて、
組織の規模感とか、
あとは組織のメンバーのリテラシーとかもあるかなって気はしてて、
確かこの記事で読んだけど、
この記事だよな、どっかで、
そうだね。
CLI versus MCPみたいな話題がちょっと前に話題になってましたけど、
その話も取り上げてて、
確かに、
CLI versus MCPの話が何かっていうのを話すと、
MCP、去年の2月ぐらいにバーって盛り上がって標準化されて、
めちゃくちゃ流行ったけど、
エアコーディングをする過程では、
結局そのCLIを直接叩かせるのが効率がいいし、
トークンも節約できるし、変なことにならんっていうので、
MCPサーバーいらんみたいな論調とか、
多分、
新現地となった記事をリンクで貼ってくれてるのかなって感じなんですけど、
エアコーディングとかソフトエンジニアにとっては一定イエスだと言えるけど、
一方で、
AIを活用したい人って全エンジニアに限らないっていうのがあって、
Fintechsもその例に漏れず、
VisitiveとかBDMとか他の人も、
AIを活用していろんなことをしたいっていうことになると、
MCPって必須技術になるよね、
今時点だとっていうのがあって、
ただそこにじゃあみんなが使うんだったらガードレールが必要だよねっていうので、
取り組んでるから、
やっぱなんかこの取り組みをするべきかどうかのトリガーは、
その規模感とかリテラシーとか、
会社としてどんな人が触るかみたいな部分に結構依存するのかなって気はするな、
エンジニアでさえセキュリティ要件とかいろんなものを正しく理解してMCPサーバーを使うと結構難易度の高いことなのに、
それはなんか非エンジニアにも広く広めたり、
もしくは広まってるみたいなところだと、
どういうふうにしましょうかみたいな部分のハウとして、
もうこれ使えばもう全部大丈夫ですっていうものを用意するっていうのは、
人数が出かかったりすると、
一発クリアというか、
コスパのいい施策になり得るのかなって気はしますね。
そうっすね。
いやー。
いつかは向き合わなきゃいけないかもね。
っていうのもあるけど、
なんか小さいとこはじゃあどうしたらいいんだろうなとは思っちゃうな。
どう生き残っていけばいいんでしょうか。
でもこの事業に求められる要件がめっちゃ厳しくないなら、
やっぱマネージドなのを使うのが一番最初の選択肢なのかなと思うけど。
まあそうだね、それでできる範囲で何とかしましょうっていう話になっちゃうよね、きっと。
試したことがないんでね、ちょっと何ともなんですけど。
まあでもそれ使うにしてもやっぱ検証とか考えると、
ちょっと体力とかコースがかかるよね、正直。
やって終わりじゃないと思うし、
ホワイトリスト管理みたいなのが始まると思うから、
バージョンアップとか。
まあまあ、そうっすね。
会社に有権なんじゃないですか。
そこまで投資する価値があるかどうかを、
そのMCP系統に見出すかどうかだよね。
ぜひポケットに一つ入れておいていい記事かなと思います。
じゃあ次。
flat securityさんの記事で、
AWS SDKのパス・トラバーサル脆弱性
AWS公式SDKにも存在した署名付きURLにおけるパストラバーサルという記事ですね。
これは面白かったんですよ。
僕は結構面白い記事じゃなかったんで、
さっと紹介なんですけど、
タイトルは結構強烈なんですけど、
これ何かっていうと、
S3バケットの話ですと。
S3バケット、
使ったことある方は分かると思うんですけど、
UI上でそのS3バケットを見ると、
まずバケットがあって、
その中に複数のファイルをバーって突っ込めるんですけど、
ディレクトリ構造みたいなのを切れるんですよね。
ディレクトリ構造を切ると、
手元のPCのフォルダみたいな感じで、
階層で管理してっていう感じにできるんですけど、
ただ、S3の裏側としては、
実はファイル構造っていうのはフラットになっているっていうのが、
アーキテクチャとしてあって、
あくまで人間が分かりやすいように、
コンソールとかでURLを見せるときは、
フォルダの形式を表現してるけど、
実際は全部フラットに同じバケットに置いてるよって、
アーキテクチャになってるって話があります。
その実態を人間が分かりやすく表現するっていう部分に
気にしてかどうかは分からないですけど、
S3のバケットでとあるファイルのパスを表現するときに、
旧来の方式だと、
ローカルのファイルパスみたいな形でスラッシュで区切って、
UI上で見えるフォルダと同じように、
スラッシュで区切って表現するって方法と、
今はこっちが推奨されてる方法で言うと、
ドットつなぎでそのフォルダを表現するっていう、
スラッシュじゃないので表現するっていう、
2種類のパスの表現方法がありますっていうのが、
まず前提にありますという感じです。
この前提でじゃあどこにパストラバーサが入るかっていうと、
結論はS3にはパストラバーサはないんですよ。
なぜならさっき言った通り、
裏側のアーキテクチャはフラットになってるだけなんで、
別にそのパスを一気にするって概念がないんだけど、
ただこのさっき言ったレガシーの方のスラッシュのパスを扱うプログラムが、
例えばドットドットスラッシュを解釈して、
いい感じに避け直せをして丸めちゃうみたいなことを処理をしてると、
意図しないフォルダ、
意図しない場所にファイルを配置させてしまうっていう、
パストラバーサが成立するよっていうのが、
この記事の話してる、
脆弱性と言っていいのかな、
多分意図的でない挙動の話ですね。
この挙動自体はAWS公式SDKにもあって、
そっちは修正済みらしいんですけど、
この挙動自体が基本的にS3側で別に起きてるわけじゃなくて、
あくまでS3を叩くAPIとかSDKの中で、
そういう処理をしちゃってるとアウトっていう部分があるんで、
使ってるもの次第ですよみたいな部分と、
またパス形式を消せないのかみたいな部分で言うと、
広報互換性を考えるとどうしてもこれに依存してお客さんいるんで、
すぐには消さないよみたいな部分があるんで、
僕らユーザー目線としてはこれを知った上で、
公式SDK使ってれば今後は大丈夫だし、
そうじゃない場合は、
この罠に関しては、
頭の片隅に置いといた方がいいかもねっていうような感じですね。
具体的には多分、
同じバケット内でパスで制御してる、
このパスはこの人しか見えないみたいな制御をしてるときに、
そのAPIとかプログラム処理の中で、
パスを勝手に解釈するようなロジックがあると、
見えちゃいけないものが見れるとか、
配置できちゃいけない場所にファイルを配置できるとかが起き得るのかなっていう感じですね。
うまく解説できたかわからんけど、そんな感じでございます。
面白いですね。
いやー、パストラバーサル、
なんか、
このさ、
昔々のパストラバーサルっていうところから、
めちゃくちゃその概念としてのあれが変化してて、
面白いよね。
そうなんだよ、そうなんだよ。
古き良きパストラバーサルとは全然別物なんだよね、実は。
へーと思って。
最初タイトル見たとき、
え?と思って読んだら、
あー、なるほど。
放送事故です。
AWSが提供するサービスが起きましたけども、
いやー、そう、
なかなかね、
目の付けどころがシャープというか。
なんか同じ、似てる?
まあ、さすがにないか。
すでに探してそうだけど、
まあ、パスはじこりやすいですね。
なんかNode.jsとかなー、
もうやばいって。
Node.jsとかは割とパス回り気を付けないとすぐバグるんで、
皆さんお気を付けくださいっていう感じですかね。
じゃあ、本日最後ですか。
はい。
これね、タイトルだけ読みますか。
DNAが辿り着いた端末管理の完全自動化、
可動率100%と棚下ろしからの解放。
はい。
DNA社による端末管理の完全自動化
DNAが端末管理の完全自動化を実現しましたよと。
すごい。
ここでいう端末管理 is 何みたいな。
端末管理っていうのは、
例えば、
社員とか業務員とかの方が使ってる端末は、
貸し出したままですと。
退職して、
したものは漏れなく回収するとか、
給食してて、
動いてない端末は回収しに行くとか、
そういう話ですね。
かつ、回収する前に、
なるべく早くアカウントとか、
あとはMDMって書いてあるんですかね、
そういうものを止めるっていうのも、
多分、端末管理の中に含んでるっていう感じですね。
記事の内容としては、
セキュリティっていうよりかは、
完全にコーパーITの自動化の記事で、
コーパーITの記事としては、
もうめちゃくちゃ面白いんで、
ぜひ読んでくださいって感じなんですけど、
100%っていう手前として、
99%まではやれてたけど、
最後の1%が残るって話があって、
そこを自動化したよっていう部分が、
記事の味噌になってるんですけど、
結構個人的に、
セキュリティからのところで、
面白いなと思ったのは、
最後の1%壁が何かっていうと、
なんかわかんないけど、
動いてない端末があると。
動いてた端末の持ち主に、
スラックDMを送ったりしても、
例えば給食してるパターンとかだと、
もう答えらんないんで、
答えが返ってこずに、
ハングした状態になっちゃう、
その端末の中に。
だからそれをコーパーITの人が、
これ返事ないしどうなんだ、
みたいに言って、
人事に聞いてみたら、
実は給食してて、
じゃあ切りますね、
みたいなことをしなきゃいけないのが、
最後の1%壁になってたんだけど、
この1%の壁を、
ないしは端末管理やれずにいると、
いろんなデメリットがあるんだけど、
その中の一つにEDRが止まるっていうのが、
あるらしくて、
40日間ぐらいかな、
40日間その通信がないと、
EDRの管理から外れちゃうっていうのがあって、
なんでその認証情報は残ってんのに、
EDRは動かなくなっちゃう、
みたいなケースがあるらしくて、
これは結構普通に、
なんだろうな、
統制面ではめっちゃリスクだな、
っていうのは思ったんで、
こういう部分でも繋がるんだなっていうのは、
ちょっとしみじみ、
ちょっと自分がEDRがっつり運用したことがないんで、
解像度がなくて、
勉強になるなと思ったって感じですね、
面白かった、
普通に技術記事として、
読み応えがありましたね、
DNAの規模でね、
最後の1%って相当だからね、
数多いからね、1%、
だって5000台の1%だから、
50台、50台か、
いや違うんだよね、
やってらんねーよみたいな話も多分書いてあって、
最後の1%だから、
毎週毎週なんか、
なんかわからんけど止まって返事がない、
みたいなやつがあって、
そうかそうか、
毎日どっかでログ停止から45日を迎える端末が発生します、
いやー、もぐらたたき状態でした、
みたいな感じ、
いやー、
面白いねー、
なんか、
まあデカいとことくゆうの悩みというか、
僕らは多分永遠に、
この悩みを知ることはない、
そう、果たしてそうかな、
本当に、
わかんないよ、
いやー、
ない、
ないっしょ、
うちの会社がだって5000台になること多分ないでしょ、
まあ、
いやわかんないよ、
ある日、
爆発的に売れるサービスを発明してしまうかもしれない、
んで、
なんかわかんないけど、
いや何が起こるかわかんないですよ、
まあ、
そうね、
直近1年2年ぐらいはないだろうね、
ですか、
はい、
そんな感じです、
いやー、
本日も、
いっぱい、
まあぼちぼち読みましたね、
うん、
なんか、
うん、
いい感じに散ってたね、
まとめとリスナーへのメッセージ
そうだね、
トピックが、
うん、
面白かった、
フラットセキュリティのブログ久々だったな、
面白いから、
結構、
静寂性解説面白いから、
あの、
そんなポンポンねーよって感じだろう今日も、
また、
いっぱい出してほしいな、
いやー、
はい、
面白かった、
いい回でした、
程よい長さで、
うん、
うん、
じゃあそんな感じで皆さん、
寒暖差での風邪ひきとかは気をつけてください、
あと、
スノードームはマジで落とさない方がいいです、
いやー、
かわいそうに、
うん、
スノードーム思い出したけど、
あれなんですよ、
僕、
割るの2個目で、
だからそこもめっちゃ反省してる、
1個目の時で、
なぜ家のスノードームを全部、
配置を見直さなかったのかっていう、
だからそのインシデントレスポンスも大事っすね、
マジで、
ああ、
再発防止策がなってなかったと、
うん、
なんならそのアクション性取ってなかったから、
ああ、
日常生活に向かわせていきましょう、
はい、
あまり役に立たない、
リスクアセスメントの話でした、
役立っててよ、
まあ、
スノードーム開けてねえから、
俺、
ああ、
そうだった、
うん、
最高のセキュリティだから、
ははは、
立ち上げない、
確かにね、
動かさない、
リスク回避だね、
完全に、
いや、
でも地震で潰れるかもしんないから、
まあ、
その時はその時だね、
他のものもいっぱいいろいろ潰れるから、
それはしょうがないね、
確かに、
はい、
じゃあそんな感じで、
皆さん次回もお楽しみにしててください、
おやすみなさい、
おやすみなさい、
おやすみなさい、