00:00
こんばんは、Replay.fm 第6回です。
こんばんはー。
こんばんは。ちょっと鼻がすげーむずむずする。
くしゃみ出そう。
いいよ、どうぞ。
まだ、まだ、まだ間に合う。まだ間に合う。まだ間に合う。
乗せてこ。
いや、大丈夫だわ。いけた。
耐えた。
いやー、今週も、
元気よく、いつも通りね、
やりますか。
元気ですか?大丈夫ですか?
まあまあっすね。
温度差、気温差にやられてないですか?
気温差、
今日なんかちょっとあったかかったよね。
今日、そうか、
東京あったかかったか。あったかかった。
滋賀は、
いや、でも日中あったかかったな。
確かに。
言えない?あたたかかった?
そこ。
あた、あた、あた、あたたかかった。
あたたかかった。
なんか、たとかが多い感じする。
分かるよ。
あたたかかっ、あ、なんか、
まあ、1個2個で多分、
バレないなって思った、今。
ポッドキャストなら。
あたたかかった。今日もあたたかかったです。
はい。
まあ、体調気をつけていきましょう。
文字起こしがさ、困っちゃうからさ。
なんか文字起こしそうね。
しかもさ、
第2回か3回さ、
ちょっと、
発狂してたよね。
30回ぐらいループしてて、すごいね。
ちょっとAIの限界ってやつを見たね。
闇を感じる、
感じる、なんか。
AIの限界なのか、無料のAIの限界なのか
ちょっと定かではないが。
ちょっとね、
ちょっと面白かった。
興味ある人は見てください。
はい。
別にちょっと怖かった。
焦って見に行ったもん。
見に行ったでしょ。
その、メールでさ、文字起こしできましたって言ってさ、
文が出ちゃってるか。
メールの本文に書いてあってさ、
えっ、壊した?みたいな。
うちのポッドキャストが何かしましたかって
気持ちで。
あそこの部分だけだったね。
いや、フィードバックした方がいいんだろうな。
フィードバックする場所あったら
しとこう。
はい。じゃあ、早速
行きますか。いや、重いな。
でもこういうのをね、元気なときにやっておいた方がいいね。
はい、行きますか。
ちなみに、僕はね、
正しやにしたけど、
若干、
時間ないと読めねえと思って、
分けられたんで、お願いします。
嘘やん。
いや、読んだよ。斜め読みはしたけど、
ああ。
ベースライン。
じゃあ、行きますか。
金融分野におけるサイバーセキュリティに関する
ガイドラインの解説。
金融機関における対策検討の
ポイントっていう、NRI
関与さんのブログです。
今年の10月4日に
主要校等
向けの総合的な
監督指針などを一部改定し、
金融分野におけるサイバー
03:00
セキュリティに関するガイドライン
として公表
しましたよと。
つらつら書いて
くれてるんですけど、規模特性に応じて
リスクベースアプローチで検査、モニタリングを
実施し、セキュリティ
管理体制の検証を行うことで
セキュリティ対策レベルの底上げを
促進してねという内容になっている
らしいです。
各金融機関は
このガイドラインなどを活用し、
リスクアセスメントを行った上で
優先度に応じて実質的
かつ効果的な対策を講じる
必要があるというふうに
書いてくれてます。
書いてある内容を
全部読み上げていくのも
特に意味がないので、
この記事ではこのガイドラインから
第2節のサイバーセキュリティ
管理体制について
解説をしていて、
気になったところだけ紹介して
いこうかなと思うんですが、
まず第1に
お金が絡むところって介して
特にセキュリティに関しては厳しく
なりがちなんで、
トレンドを追うにはいいよねというふうに思っていて、
あえてこういうふうに思ってきてるんですけど、
割と
厳しいのが多分最初に
入りやすい領域ではあるのかな
と思っていて。
この発想
なかったな。
これ恥ずかしながらこの発想には
至れなかったから、割とちょっと
こういう世界もあるのか
みたいな捉え方をしちゃってたけど。
なるほどね。
ダイレクトに
狙われやすいじゃないですか。
お金って。
金融機関もそうだし、
クレジットカードが絡むところ
とかもまさにそうですよね。
だから
世の中PCI DSSとかもあって、
ある種の
セキュリティスタンダードとして参照される
ものにもなっているし、
同様に
金融機関に関するガイドラインみたいなのも、
金融機関向けの
ガイドラインとかも同様に
厳しくなりがちなんで、
なんて言ったらいいんだろうな。
一つの
上の方に
あるフェースラインとして
追いかけておくには
いい領域だよねっていう感じですね。
はい。
とりあえず思ったのが
リスクベースアプローチって何やねんって
話なんだけど、
難しいな。
リスク評価に応じて
リスクの高いところに
より
効果的に対策を施しましょうね
っていう話。
平たく言うと、僕の理解だと。
貼ってくれてる
インクは図を
超簡単に説明してくれてるんだろうけど、
なるほどね。
色分けしようって話なのかな。
グラデーションつけてやってねって
話だと思うんだけど、
リスク評価が一番難しい
ポイントだと思っていて、
みんなどうしてるのかな、
どうすんのかなっていうのが
ちょっと気になったところ。
06:00
例えばだけど
取引の総額とかさ、
いくつか指標はあると思うんだけど
金融機関においては。
もうちょっと踏み込んでほしい
っていうか、
あるのかもしれないけど、
こういうフレームワーク使うといいよ
とかさ、
そういうところまで踏み込んでもらえた方が
会社としては参照しやすいよな
っていう風に思った。
これ系のガイドライン
結構難しいなと思うのが、
作る側の気持ちになるとさ、
じゃあ今言ってくれてるんですけど、
総額でこの値段
が目安だったときに、
でもこの値段以下を
切り捨てていいわけではないみたいな
それはそうね。
だからその結構
中小度をなんか
高く留めざるを得ないというか、
なんか解釈が
いや難しいよね、そのなんか。
うん。
書いてないのもなくて。
っていうのもあるしさ、
なんて言ったらいいんだろうな。
1兆円の取引のある金融機関と
100億円の
取引までしかない
金融機関とで
千引きも買われよねって
あると思うし、ケースバイケースだから
そんなん自分らでやれよって
分からなくはないんだけどさ、
思うのはその
評価のフレームワークは
共通化できると思うんだけど、
その評価の
フレームワークは共通化できると思っていて、
その上で指揮地をどこに置くかっていうのを
組織によって変えるべきだと思うんだよね。
うん、なるほどね。
まあ確かに。
1段階、1から5までの
5段階あったとして、3はいくら、
4はいくらみたいな部分のその
4はいくら、5はいくらの
その部分をこう
組織によって改変にしてあげた方が
組織間の互換性みたいなのもたぶん保たれるし。
うんうん。
いやー
難しいね。
それをまた最大公約数取ろうと思うと
CISベンチマークみたいなのができあがるのかな。
ああ、そうなるのかもしれないね。
でもさ、その
まあ、よらかにやりやすいと思うんだよな。
その、3が
この金額になってるのは
例えばだから取引金額のその
指標を作ろうとしたときに
3がこの金額になってるのは
なぜですかって聞かれて、
それに答えることはたぶんできるじゃん。
うんうん、確かに。
でもなんかそれが何にもない状態で
その、なんていうか
これが5なのはなぜですかって
これに評価が5なのはなぜですかって
聞かれたときに
まあ雰囲気で決めましたみたいになっちゃうじゃん。
うーん、なるほどね。
確かにね、再現性みたいなところ
とか
まあなんか
それこそ冒頭言ったように
結構大事な領域だし
わかんない、まあCISベンチマークほどとは言えないけど
ある程度重厚調査になっちゃっても
確かにな。
具体のところや
というか指標みたいなところは
09:00
出してあげてもいいのかもね。
うーん。
まあそれがこれから進化していくのかも
しれないのかな。
まあガイドライン本体とか
あの関連ガイドラインもしかしたらそういうのも
書いてあるのかもしれないけどね。
全部読んだことがないから何とも言えないけど。
確かに確かに。
というのがまず思ったのは
思ったのがまずそこで
えーっと、今日なんかダメだな、舌が回らんわ。
回ってるよ、大丈夫。
いい感じです。
えーっと、
紹介されてて気になったというか
思ったのが
人材育成に関する記載が細かくなった
というところで
単に以前は育成拡充
という風にしてたところから
外部人材の活用も含めて計画的に
確保という表現に変わっていて
なんか面白いなー
なるほどね。
採用と育成が
無理系なのが明らかになったのかな
というのをちょっと
思ってしまったんだけど。
そうだね。
なんかその、そうだよね。
人材に対して需要がもう
需要供給のバランスが
もう多分崩壊してるから
こうならざるを得ないだろうね。
でもさ、実際さ、
その
なんか供給がさ
十分にあったとってさ
雇うかって言ったら雇わないと思うんだよね。
あーなるほど。
そんなか。
そんなに雇うだって。
事業者で十人セキュリティエンジニアに雇ってください
ってなったらさ、なんか雇わないでしょ
多分。
必要なら雇うかもしんないけどさ、
必要ですってまずならないでしょ。
理想論だけで言ったら
このガイドラインがあって
このガイドラインを遵守していくときに
もうこの穴埋めをする
どうにかしなきゃいけないってなったときの
手段としてその採用が
来るであれば
そのロジックに乗っ取るなら
それで十人必要なら取るべきだと
個人的には思うが
うーん、まあそうね
強制力というか
なんかそれを説明していくのも
大変っちゃ大変
なのが
現実世界かもねっていうのは
思う。
いや雇わないと思うんだよな
感覚的に。
まああの規模によっては
そういう風にたくさん雇ってるところも
あるだろうし、十人っていうのはあくまで
大雑把に例としてあげてるだけ
だから。
でも逆に
二次元の目線に立つと
十人必要なのに十人雇われない会社は
この外部人材の
活用とかにお金を払えないんじゃない?
そこに
コスト投資をしたくないっていうこと
なんであれば結構
なんか割と
積んでそう。
分かんないけどね
そもそも供給が足らないっていう話も
ある一方で
供給があったとて
本当に十分に雇うのか
っていうとそれも微妙だよね
っていう話もありつつ
12:01
育成拡充
そうね
計画的に確保っていうのも結構大雑把だしね
分かんない。実際に書いたら
もっと細かく書いたのかもしれないけど
本体だから原文読まないといけないんだけどさ
あとは
必要な
その人材の種類みたいなのが
細かく
書かれるようになっていて
4種類
上がってるのかな
これが全部なのか
これ以外にもあるけど
省略されてるのかちょっと分かんないんだけど
新たなデジタル技術の導入に際し
所持有るサイバーセキュリティに関する
リスク評価を行う人材
サイバーセキュリティ戦略
計画の
企画立案を行う人材
サイバーセキュリティに関する研修や
人材育成を行う人材
サイバーセキュリティの観点から
システムの設計開発を
行う人材っていう感じで
4つ書かれてて
なんかどうですか
いやーなんか
いやまあでも変なこと書いてないというか
そうだよねって気持ちと
この4つ目のサイバーセキュリティの観点から
システムの設計開発を行える人材が
どれだけいるんだろうなっていう
気はするよね
リスク評価
リスク評価を
まあでもそうか
いやまあ難しいな
なんか大きい企業の景色が
個人的にはあんまり想像できてないから
分かんないけど
1個目のリスク
新しい技術を導入にするときの
サイバーセキュリティリスクを
評価する人材っていうのが
切り出されてるのもなんか
そこ
なんか流度
そことサイバーセキュリティの観点から
システムの設計開発を行う人材の
をなんか同じ
レイヤーというか
レベルというか流度で整理するんだ
っていう
まあ例えばっていうので上がってるから
あんま多分そこの流度は考えてないんだろうけど
うーん
なんか
そうか
いや元文読みたいな
元文ちゃんとやってましたってあれだけど
いやー結構
こここそはっきり
変えちゃえばいい気がするけどね
もうこの流気とこの流気とこの流気
いやーでもどうなんだろうな
いやーなんか思ったのは
その
いやそれができないから難しいんだよって今自分の中で
無限ループになっちゃったんだけど
サイバーセキュリティに
きちんと取り組みましょうってなったときに
その
サイバーセキュリティの領域に限らず
何かの仕事とか何かに
意志を説くときに
一定いろんな分野でベストプラクティスとか
手法があって
それを体系立ててじゃあこういう組織に
この規模だったらこういう組織がいいよねとか
こういう体系とか
こういう明かり分担でチーム組むと
まあ細かいチューニングは会社ごとに
会社とか事業ごとに必要だけど
まあまああるよねっていう
あるだろうから
15:01
このガイドラインにおいても
まあそのこの金融っていうスコープ
においてまあこういう
組織体系でこういう機能が
組織に必要だからそれができる
チームが必要でそこにはこういう
人材がいた方がいいよみたいな体系立てて
整理してあげても
してもらった方が
もうちょっとイメージ湧いたり
その何だろうな
穴埋めがしやすいって言うとちょっと
別に人間はパズル持ってるわけじゃないけど
何が足りてないって差分が
わかりやすいんじゃないかなと思ったけど
まあそれができたら苦労せん
やろがいっていうのと
まああと希望感とかによって
結局それも結構変わりうる
よねとか
まあ
ガイドラインレベルまで落とすのは難しいんだろうな
とかちょっと今脳内で
ぐるぐるループしてた感じ
多分なんか必要なのは
組織のその成熟度の
評価と
人材のスキルマップの
つなぎ込みじゃないの
なるほどねそれはそうかもしれない
スキルマップ上のこういうスキルを持ってる
人がこういう風に配置されて
いますっていうのと
組織の成熟度のつなぎ込み
をしてあげると
ここにこういう人が足りてないねみたいなのが
なんとなく出てくるような気がしていて
それでいくと
成熟度が評価できるフレームワークっていうのは
いくつかあると思うし
なんだっけ
スキルマップか
スキルマップもまあ
なくはないんじゃないかな
なんかどっか出してたよね日本の会社も
分かんない
でもなんか日本の会社は
分かんないかも海外のやつは
それこそエゲゲ社がなんかタイミングで
シェアしてくれた気がするけど
何個かあるよな
なんとかね
出てたんだよな
割と最近なんか出してくれた
気のせいかもしれない
一応なんか
昔からあるのが
JNSが出してる
セックボックっていうやつ
JNS
セックボック
セキュリティスキルマップとかで検索すれば
出てくるかな
へえ
なるほどね
これは知らなかった
いいっすね
2021結構ちゃんと
メンテもされてる
うん
うわーとか言ってた
いやこうなっちゃうんだよな
なんていうか
そうなんだよね
しょうがない広く深いしな
なるほどね
いいっすね
参考にできそう
大学シラブスとの連携とか
書いてある
へえ
海外の有名どころも多分
いつかあると思っていて
ちょっと今パッと出てこないんだけど
探せば多分いくらでも出てくると思うんだよ
うんうんうん
その辺の確かにつなぎ込みとかがあると
いいかも
18:00
いいかもっていうか
なんなら欲しい
欲しいっす
いやー
マチュリティでいくとなんだろうな
オアスプのサムとか
オアスプのサムも
良さそうだけど
CISのなんかとかも
使えそうな気がするし
うんうんうん
いやー
しかしなー
まあそうね
いやでもこれじゃあ
成熟度
成熟度の評価振りマークと
そことスキルマップがきれいにつながったときに
じゃあその成熟度
評価が正しくできるかが
もうまた難しいんだよな
うーん
そうなんだっけな
弊社ね
なんかのフレームワークを使ってみたんですけど
会社PC
なんかちょっと
パッと出てこない
あー思い出せない
思い出せないけど
実際やってみたんですよこういうガイドラインの成熟度評価みたいなやつ
やってみたけど
結構むずいなと思ったんですよね
で何がむずいかっていうと
例えばなんかこの項目の
この項目ができてるというためには
その成熟度を満たしなきゃいけないみたいなものがあったときに
なんか30パーぐらい
満たしてるなみたいなものとかがやっぱ
あーあるんですよね
なんかグー
グーグルクラウドではこれちゃんとできてるけど
AWSはちょっとできてないかもなとかなったときに
じゃあそういったの30点だよね
とかなんか
結構その1-0で判定できないものが多くて
そうなってきたときに
そこまでなんか対応して
うちが試したフレームワークはそこになんというか
別に総合点数を出すようなフレームワークではないんで
別にいいんですけど
自分たちがそう認知すればいいだけなのが
うーんなんか
どこまでやり込んだらこれできてるって言えるんだろうね
みたいな
なんかそういう評価がむずかったり
それが全項目でやっぱある
グラデーションがあったり
するのと
またなんか自分たちの見えてる部分はできてるけど
なんかなんだろうな
本当にそうなんだっけみたいなところを結構
まあそれは
正しいのかな
把握できてない部分があるよね
で把握しに行く動きができるかいいのかもしれないけど
うーん
なんか
なんだろうな
まあ感覚としては
事前に思ったほど
すって使ってパパパって当てはまんないな
と思ったというか
まあねなんか
ものすごい
原理主義的にいけば
Weakest LinkとかOKの理論って呼ばれてるように
その
弱いところで評価するべきなんだけど
本当はね
でもなんか
まあそういう風にその
場所場所によって
グラデーションができちゃうような場合は多分スコープを切って
このスコープではこれぐらい
このスコープではこれぐらいみたいな感じで
見ていった方が
多分いいんじゃないかなと思って
そうするとその各スコープごとの成熟度みたいなのが
まあ総合でどれぐらいですよ
21:01
っていうのが
出てくると思うので
その上で
その総合でいくつですよっていうのを
見た上でじゃあその総合で
いくつですよっていうのを一個挙げるためには
どうしたらいいんだっけっていうのを深掘りすれば
いいと思うし
確かに
いやーその辺の事例もっと
出てきてほしいな
いや知らないだけなのかなもっと調べようかな
なるほどね
確かに
いやーそういう
知識を
どこの学校に行けば教えてもらえるんですか
いや分かんないけど
でも別に適当喋ってるだけだよ
今
でもさ普通に考えてさ
普通に考えてさ
じゃあさテストのカバレッジ取りましょうって
言った時にさ
例えばだけど
一個のリポジトリの中でパッケージが複数
分かれてたとしてさ
パッケージごとのカバレッジも見るじゃん多分
まあね
全体でのカバレッジ見ちゃえば早いんだけどさ
でもねここのカバレッジが低いねとかさ
なんか見ない
見ます
なんかそういう話だと思ってて
なるほどねまあ確かに
いやでもテストはさ
無限に書いてきてから分かるけどさ
でもなんか物の考え方だからさ
ああまあまあ
確かにその辺は確かに応用できるかも
なるほどね
人材
採用は無理
育成も無理ゲーなのか
そういう話とかもあるしな
いやーこれさ育成
まあねだいぶなんかまた話が
逸れてきちゃう気がするけど
育成
ねえなんか
育成はどうしたらいいんすかね
やる気のあるやつを
見つけて
やっていいぞっていう
もうスタートアップマインドで
私は
なんか
うーん
例えば
だからもう一人自分を作れって言われた時にさ
どうしたらいいのか分かんないんだよね
うーん
まあ
うーん
まあそう確かに
いい質問するね確かに
いやまあ厳密には無理だけどさ
なんか似たような人間をもう一人
作ってください育成してくださいって言われた時にさ
うーん
でもなんか
0歳から始めればいいですかみたいな
その
いやまあね育成者の立場に
自分がなるんだったらその最終的に
解いてほしい実習があるわけでそこから
もうブレイクダウンしていくしかないん
じゃないかなって気がするよね
その実習をとくためにこういうスキルが必要で
まあこのなんか
10個ぐらいのスキルが必要でその10個ぐらいの
スキルのうちこの人は
成熟度モデルじゃないけど
いやー
そんな簡単にいくか
これは知らない
うーんまあえでもなんか
いやでも箸の使い方を教えてさ
24:01
うん
箸の使い方を教えたからといって
その豆を見て箸でつまむことを
考えるかどうかはなんか全然
違う話じゃない
そこはもう育成でしょ
これはつかむもんなんだぞって
つかむものはね
その100個の食材があった時に
100個に対して
僕らは多分これは豆が
箸でつかむもんなぞって
言われてないけど多分なんか
4,50個ぐらいインプットした頃で
まあ残りの50個もまあ
わかるとするじゃん
だからなんかそれと同じことを
するしかないんじゃないですか
うん
基礎知識のインプットとそれを
実地でもう
なるべく早く
勘所をつかんでもらうための
実際のユースケースとかを
加わせ続けるしかないという
まあ多分なんか
うんだし
どういうアプローチにしても
時間とお金はめっちゃかかるよね
うん
立ち上がり方は人それぞれ
という話全然あるにしても
多分どんなに優秀な人でも
どんなに短くても多分半年とかかかるよね
とか1年2年とか
かかってもおかしくないよねっていう前提で
組織設計とか
採用とかしなきゃいけないし
そのお給料払わなきゃいけないわけだから
そのコストを払う覚悟を
組織がちゃんと持たないと
成り立たない話ではあるとは思う
うん
いやー
まあなんかそんなことを
考えてると
ピープルマネジメントもちょっと興味あるなとは
思わんでもないんだけど
そうねー
でもピープルマネジメントなのかな
教育はまたちょっと
またちょっと違うのかね
まあまあでも組織とか
文化にもよるからそこは一概には言えない
まあそうだね
その
育成をするための箱を作るのは
ピープルマネジメントなのかなと
個人的には思うけどね
周りを整えるというか
うん
なんか育てたいのにさ
延長案件ばっかり突っ込まれ続けてたらもう
育つもんも育たんみたいな
そういう環境とかその
あーなるほどね
ちゃんと理解するために
翻訳する人とかはやっぱ必要だと思うから
うーん
あと人によってスタイルが違うとかも
あるだろうね
なんか延長案件にぶち込んだほうが成長する人もいれば
割とレイロシーで
立ち上がりが遅いかもしれない人もいるだろう
あー
いやーそうねー
いやでも延長案件に
突っ込んだほうが成長するかどうかを
先に見極めて延長案件に
突っ込むって無理だよ
売れちゃうかもしんないし
だからまあ初手それを取るのは
ダメなんじゃない
ある程度なんていうか
重ねた上で
延長案件に突っ込むのは多分どんな人でもダメだけど
えーそうなんで
それ言うとまあその
なんていうか
いやこいつ自分で走れるなーとかなんかその
27:01
傾向じゃないけどスタイルって
そういうのはある気がする
いいねー
難しいね
難しい
いやなんか
再現性のないキャリアを歩んでるなー
と思って
再現性のあるキャリア歩んできちゃっていないよ
大丈夫
いやなんかさー
まあお決まりのパターンってあるじゃん
まあまあまあ
まああるか
あるな
いやーでも
まあ
まあ大企業
とかじゃない限りないんじゃない
わかんないけどそのうちの業界
ぽんぽん転職するからさ
そういう意味ではもう同じパスをたどってる人はいない
と思うんだけど
そういうところの多様性というか
再現性のないキャリアはある気がする
うん
いやー胸張って生きとこう
次いきますか
良き記事でした
えー次
次は
僕読みますか
Google検索結果で青色の認証済みチェックマークをテスト中
っていう記事ですね
まあタイトル通りですかね
Googleの検索結果に
Googleお墨付きの
正規のこのサイトは本物です
っていう認証バッジ青いバッジ
Twitterの課金したら付くバッジと
まあほぼ一緒
あれっていうよりかは金色バッジかと同じ
わけだと思うんですけど
あれを付ける取り組みっていうのが始まってて
で
全員に展開されてなくて
おそらくABテストみたいな感じで
表示されてない人がいるっぽい
っていうところで
そのバッジは
全部に付いてるわけじゃなくて
比較的大企業とか
機密情報を扱う可能性の高いサイトって
言ってるからこれはまあよくわかんないけど
政府のサイトとか
なんすかね個人情報
でかいECサイトとかまあよくわかんないですけど
まあその優先度があるらしいと
で審査プロセスは
自然自動というわけではなくて
一部手動のプロセスが挟まってます
っていうのが記事では言及されていて
うん なるほどという
記事ですね
僕はまあ
良さそうだねと思いつつ
うーん
まあどんぐらい意味があるんだろうな
みたいな
Google検索だとその広告枠に
検索結果の一番上に
出てくるところにわかんないけど
Twitterって調べたら
Twitterを名乗る広告が出てきて
中身は実は別物みたいな
ああいうのとかに対してじゃあ交換のとか
またなんか今の時代
検索流入
まああるけどどうなんだろうな
とかまあちょっと
気になったんですけど
ヤガヤガさんの時にはどうですか
えー
わかんないな
なんか
ビミとかもそうなんだけどさ
30:01
なんか
今ばっかりかかる割に
うん
どうなのかなーって
うーん
ビミ知らなかった
こんなんあるんですね
うーん
なんかコスパいいかと言われるとって感じはするよね
うーん
まあだからまあ全展開してない
ってところで言うと本当に意味があるのか
どうかはまだ評価してる
っていうのはまあGoogleだし
ちゃんとやってそうな気はするけど
なんか
いやこれ元ソース
あんのかな
なぜやるのかみたいな部分がちょっと気になるかもね
うーん
ちゃんと読めなかったな
でもGoogleが認めなかったら正規サイトも正規サイトにならないってことでしょ
それはそうだろうね
いやなんかGoogleが
何を保証してくれんの
っていうのはなんか
あー
いやわかんないけどそのさ
なんかこう
漠然とした認証じゃない
その
パッと見て何をさ保証してくれてるのかもわからないし
うーん
だから何ってなっちゃう
部分はまあなくもないと思っていて
うーん
そうだねー
ローカル大手レストラン
うーん
まあ企業の
申請せよ
いやーでもなー
どうなんだろう
EVSSLはさ
なんかもう廃れたわけじゃん
そうだね
同じじゃないのってちょっと思った
うーん
Cっていうならユーザーから見たときに
わかりやすいバッジっていうぐらいなんじゃない
差分があるとしたら
EVSSLだってさ
なんか
アドレスバーに企業名出てたじゃん
まあでもあれはさその
なんていうか多分UIの
敗北ではないけどその
あのUIだとそのユーザーは認知しなかったっていう
結論
っていうだけであって
あれのリベンジなのか
わかんないけどその
どこでそのメッセージを
伝えるかみたいなところをもしかしたら
やりたいとかはあるのかもね
うーん
全部想像で喋ってるけど
だからわかんないしこれをわざわざコストかけてやるってことは
まあ
だからもう公式
セキュリティブログとかで出して欲しいなと思うけど
その検索流入で
あまりにもその偽物のサイトに
引っかかるとか
そういうシチュエーションとか
キリがないとか
でそれに対応も
全然追いつけないとか
そういうのがあんのか
もしくは既存の
フィッシングサイトのリアルタイム
結構
Chromeだったら
すごい短い時間で対応するみたいなやつがあった気がするけど
そういうのと合わせて
カーレッジを高めたいのか
その意図は知りたいよね
深刻指定審査とかじゃないよね
33:01
わからん
Googleが勝手にやってるんだよね
多分そう
Googleが収集した運なんて書いてあったもんね
そうだね
その青マークにはそう書いてるって感じかな
でもさ
Googleが収集したシグナルでさ
それが判別できるんだったらさ
そうじゃないもの出すなって話じゃないの
どうなん
そこはイタチごっこなんじゃない
多分だけど
攻撃者側もさ
無限に量産して
多分
検索結果から消されては
追加しみたいな
そもそもチェックしてなくて
作りは消し作りは消し
みたいなことしてる
で
それで対応しきれないとか
ここ
どうだろうね
でも言いたいことはわかる
これをやろうとするとさ
どう収集するんだろう
でもどうなんだろうな
今一瞬何を気にしたかっていうと
ドメインの分離とかをする選択肢を取りにくくなる
そうだなってちょっと思った
そうだね
ここはちょっと
なんていうか
高めの安全性を保ちたい
っていうところに対して
ここはちょっと怪しい
怪しいっていうか
アウトソースしてる部分とかも入ってるし
なんだっけ
ETLDプラスワンの部分でも分けておきたい
みたいなさ
話とかが出てきたときに
分けにくそうだな
って一瞬思ったんだけど
でもGoogleがその
認証済みの正規サイトから
そこにリンクが貼ってあることとかを
検出して
自動でマークつけてくれれば
手に広がっていくのかな
と思わんでもないけど
でも
そのマークがつくの待ちみたいな
時間とかが生じそうだなと思うし
どうしても
今調べてるけど
公式ソースがやっぱないから
見つけた人が
こんな理由でやってるんじゃないかみたいな
まあ公式の
見解を待ちたいな
個人的には なんかなぜやってるのかも
気になるし
何を狙ってるのかしらで結構
まあでも何にせよ
めちゃくちゃ筋がいいかどうかは
疑問のやつは残りそう
そうね
まあちょっと様子見ですねこれは
出してくれるでしょ
Googleのことなんで
うん 待ちましょう
はい
じゃあ次
私が読んだ記事で
リビンコンピューターだったかな
OpenAI confirms threat actors use
ChatGP to write malware
36:00
っていう記事なんですけど
まあ何の記事かというと
脅威アクターによるChatGPの
GPっていうのは
こういうところに関して
まあタイトルにある通り
マルウェアを作るとか
マークとかそういうところに対して
どういうふうに悪用してるかっていうところ
の話で
日付忘れたな
日付はもうちょっと10日前ぐらいに
OpenAIからその
レポートが出てるんですよね
このレポートちょっとまだ目を通せてないんですけど
54ページぐらいあって
まあそこそこ厚いやつなんですけど
ChatGPTを使って
話としては3つかな
ChatGPTを活用して
活用して
行われようとしていた
大規模な
キャンペーンとか犯罪っていうのを
まず阻止したよって話が
1つと
一方で悪用されちゃいましたみたいな
事例の話と
まあ主に2つか
あとは多分
悪用されちゃいましたの
他のうぞうむぞな悪用の
方法みたいな記事も
話もこの記事では結構触れられてて
このOpenAIのレポートの記事は
何個かあったんですけど
このブリーピングコンピューターが結構具体的に
こういうプロンプトを使ってますみたいな
例があって面白かったんで
引っ張ってきた感じですね
で もうちょっと
話すと
キャンペーン話みたいなのは
20を超える犯罪を阻止したぞって
OpenAI言っていて
そうですかっていうか
ちゃんとやってますよっていうところと
一方で
ちゃんと悪用もされちゃってるっていうところが
あって
で 例えばこの記事に書いてある
具体例のやつでいうと
なんかこれ見てもう
一概にブロックきついなと思ったというか
なんかホワイトハッカーとの見分けつかないなと思ったんですけど
例えばその
多分攻撃前の
リサーチとかで
ログ4Jの
脆弱性ってどういう脆弱性ですかっていう
プロモートを投げるとか
ログ4Jの脆弱性が
含まれるバージョンの探し方を教えてください
とか
特定のCVE番号を投げてきて
それについて詳しく説明してくださいみたいなものとか
またそれをじゃあどうやったら
悪用できますかみたいな質問とか
あとその
作りかけのマルウェアとかを
僕らがやってるのと一緒なんですよね
そのコード分投げて
これのバグで保してくださいとか
そういうことをやったりしている
っていうところが
記事中ではぼちぼち
触れられていて
もっといっぱいたくさんあるんですけど
気になる方は読んでくださいっていう感じですね
なんで
これ公開することで
より悪用されたりとかしないのかな
もう見つけられるパターンだから
公開しても大丈夫っていう感じなのかな
なんかちょっと個人的に
レポートちゃんと読みたいけど
39:00
自分で触れられているプロンプトを見て思ったのは
結局
多分攻撃者がGoogleでやってきたことを
チャットGPTでやってるっていうだけの
話なのかなって気はして
それはね
この辺の全部のプロンプトって
なんかそのチャットGPTが生まれたから
新しくできるようになったことってあんまなくて
自分で調べたり
頑張って勉強しなきゃいけなかったことが
ワンチャン
プロンプト投げれば帰ってくるみたいな
感じになってるから
だからその
何か新しい脅威が生まれたっていうかは
脅威が加速したり
またハードル下がったっていうのはあるんだろうね
技術力が良くてもまともにかなっちゃう
みたいな部分が
サウンドとしては結構でかいのかな
っていうことは思ったかな
あとはなんか
これ対応しなきゃいけないの
LLM事業者は
大変だなと思ったな
シンプルに
チャットGPTはちょっとあまりにシェアが大きいから
やっぱちゃんとやんなきゃいけない
っていうのもあるんだろうけど
チャットGPTが仮にこれ
対策完璧ですってなっても
別にベースのLLM
エンジンにみんな逃げるだけだし
まあ
活用される前提で防御しなきゃいけないよね
っていうのは
ぼんやり思ったなっていう
でもシークレットモードとかでさ
やられたらもう分かんないんじゃないの
そんなことないの
ないとは思う
一応アカバンはしてるから
アカウント
が
何かしらロジックで怪しいと判定されば
まあまあバーンはされるけど
作り直せばいいだけだし
100%
ブロック仕切るのは無理だろうね
そうだね
またその怪しい判定も
多分結構
情報集めきらないとできない
だろうから
結構見るの大変だよね
なんか
そうだねどういう検知ロジック
なのかとかまあその辺も
レポートにある程度
もしかしたら解説があるのかもしれないけど
って感じですね
まあ
よくされそうだよなっていう
防御なかなか
しきれないよねっていう
いやコードとかもさ
丸や全体投げたら多分さ
分かるけどさその一部分のロジック
変えるとか
ったらさ分かんないよね
分かんないね
強くしすぎたら多分
俺とかはじかえされば
はじかえかねないじゃんね
難しいなって思った
それでちょっとちゃんと読みたいな
と思うのはこの20を超える犯罪を
大規模犯罪を阻止しました
っていうのを書いてあって
どうやってっていうところは
気になるよねなんか露骨にやってて
まあ防ぎましたなのか
結構
頑張って防ぎましたよ
なんかどうやったのかとか
42:01
その辺詳しく書いてあると思うんで
ぜひちょっとご一読ください
っていう感じですね
読んでみよう
ぜひ
いや僕も読みます
はい
じゃあ次いきますか
これはね
ちょっと笑っちゃいけないんですけど
おもろと思ったんで
持ってきたんですけど
Hacker Newsの
FBI creates fake cryptocurrency
to expose widespread
crypto market manipulation
っていう記事なんですけど何かって言うと
仮想通貨で
悪さする詐欺詐欺師とかを
炙り出すためにFBIが
偽の仮想通貨を
本物の偽の仮想通貨を
作って犯罪者を釣り上げて
大規模な
逮捕しましたっていう記事ですね
なんか
すごい
ようやるなと思ったっていうのでちょっと
おもろと思ったって感じですね
うん
そうですね
わざわざ偽の仮想通貨を作って
あれかなその
資金洗浄とかに使われる
使いやすいようなものを意図して
多分作ったっていう感じだったかな
うん
結構大胆なことするな
っていうか
これでもなんか18人ぐらいか
そうだねしか対応できてないから
なんか
まあコスパはどうなんだろう
と思ったりもせんこともないけど
仮想通貨作ったことないんで
ちょっとわからんって感じですね
うん
おもしろいね
日本とかだと
法的にできるのかな
そうそれがちょっとね
気になった
どうなんだろうね
うん
取りそうさなのか何なのか
うーん
まあ仮想通貨を
作ること自体は
違法じゃないのかな
どうなんだろうね
まあよくわからん
ああ
こんな世界があるんだなと思って
ね
って感じですね
面白いね
ぜひ興味ある方は
読んで解説してください
丸投げ
はい
次いきますか
大丈夫ですか元気ですか
大丈夫ですちょっとお腹いっぱいでね
眠くなってきちゃった
寝落ちする前にどんどん
ガンガンいきましょう
大丈夫元気だよ
元気?よし
じゃあまあ次も
ずっと僕なんだよな僕のターン
そうなんだよ
ホーンって言いながら聞いてるだけになっちゃってるから
なるほどね
ちょっと頑張っていきますよ
これどっちだっけな
45:01
これハッカーニュースの
GitHub, Delegram, Bots, and ASCII QR Codes
Abused in New Wave of Phishing Attacks
っていう記事で
記事自体はですね
まあ
ラムコスラットっていうマルウェアが
保険金業界の標的として
フィッシングで配布されてる
っていうキャンペーンが
実施されてますっていう
話で
でまあ
言っちゃえばまあ
ハッカーニュース プリピンコンピューター
無限に流れてくるタイプの記事なんですけど
その手の方自体が
あの
まあ
フィッシングで
使ってもいいかなっていう気はしていて
どういう手法かっていうと
この
タイトルにGitHubって入ってるとこの理由なんですけど
その
Eメールの
フィッシングなんでメールを送ることが
あるんですが
そのメールに対してフィッシングメールだよとか
危ないメールだよっていうのを
検知されづらくするために
そのマルウェアをダウンロードするためのURLを
作る
っていう話があって
具体的にどういう利用してるかっていうと
GitHubの
仕様として
例えば一周コメントとかプロジェクトコメント
に対してファイルを
ドラッグ&ドロップとかで
画像でも何でもいいんですけどアップロード
する機能があるじゃないですか
で
あの機能でアップロードしたときに
アップロードされて
そのアップロード先のURLが
GitHub
から当然返ってくるんですけど
そのURLの
仕様がちょっと
ミソで
例えば有名なOSSの
httpsgithub.com
オーナーネームスラッシュリポジトリネーム
っていうところの一周コメントに
ファイルをアップロードすると
今言ったURLから
がプレフィックスとなって
そのファイル名のランスなりが
設定されるっていう風になるんで
そのURL自体が一見すると
そのリポジトリの
アセットっぽく見えるっていう
仕様になっていて
かつその一周コメントとかって
ファイルアップロード
ドラッグ&ドロップでアップロードした後に
コメントしないっていうのができるんですけど
コメントしなかったとしても
アップロードしたファイルのURLは
永久的に残っちゃうので
マルウェアとか
そこにアップロードしてURLは
有名リポジトリの
パスっぽいURLを手に入れて
それをメールで送るみたいな
検知側も
GitHubのっていうのもあるし
多分
ロジックはそれぞれなんでしょうけど
結構その
URLからマルウェアだよね
っていうのを見るから結構難しい
っていうような性質の
URLを作っているっていうような感じ
ですね
なんか他にも
予約サイトの
複数の手法が
48:01
紹介されてる記事だったんですけど
ここで話したいなと思ったのはそれだけなんで
他のやつは興味あれば読んでくださいって感じですね
そうね
ごめん
すいません
個人的に思ったのは
これなんかね
3、4ヶ月前くらいから
この記事に触れられてるかな
結構
初め発表されるっていう事例が出てから
そんなに
まあ何ヶ月かは
時間が経ってて
GitHub側は多分
今のとこは
明確に対応してないだろうな
って気はしてて
いつか対応するんだろうけど
いやしんどそうだなってちょっと思ったっていう
感じ
どうするのがいいのかな
なんかでも難しいな
なんかでも
基本的には
なんて言ったらいいんだろう
メールに記載されてる
URLで投稿
っていうのが
なんかそもそも無理ゲーじゃないのって
思っちゃうんだけどね
どっちかっていうと
アクセスして落としてきた
ものが何ですかっていうのを
多分見ないといけないし
落としてきて実行したものが何ですかっていうのを
見ないといけないし
やっぱそれがベストなんだろうけど
こうやってすり抜けてくるものって当然あるわけで
そうだね
事前の策としてどこで止められるんですかっていうところに
着目して見ないといけないはずで
っていう風になった時に
GitHubにアクセスできる程度には
一定ゆるさのある
組織とか環境だとした時に
確かに難しそうだなっていうのは
わかるっちゃわかる
あともとで言うと
100%のカバレッジは取れないかもしれないけど
カタログにあるようなマルウェアだったら
GitHubにアップロードした時に
GitHub側で弾くとかができればいいんだろうけど
これ似たような手法で
ドロップボックスとかGoogleドライブ
Googleドライブは引っかかりそうだけど
みんなが使うような信頼されているファイルホスティングサービスに
アップロードして
そのURLを送り付けるみたいな
手法が蔓延している中で
メジャーどころの事業者たちが
おのおのその対応しなきゃいけない
っていうのは結構
大変だよねっていう
あとなんかそれを
当然そのドロップボックス側とかも
対策してるんだけど
その対策を回避する結局イタチごっこになってて
暗号化したり上手いこと
バレないように圧縮したり
そのファイル自体をいじったりとか
そういう記事も見かけたんで
GitHub側も
そうしたら社員の時はやってるのかもしれないけど
そういうイタチごっこ
今もしてるのかもしれないし
でもできなくはないと思うけどね
だってGoogleドライブからダウンロードするときって
51:01
ウイルススキャン走るじゃん
そうだねGoogleドライブは
そうだね
あれもすり抜ける
どうなんだろうね
理屈上はすり抜けるじゃん
絶対のものはないわけだから
そうだね
すり抜けた先でどこで止めるんですかっていうのに
フォーカスしないといけないわけで
まあまあ難しいのはわかるし
まあね
まあそう結構
作る側としてはどうしようもないよね
そうだね
アップロードされたものが
何なのかなんてわかんないわけだしさ
何でも上げたい需要は実際あるわけです
そうだね
有名性だよな
はいそんな
記事でした
まあでもなんか
いやまあね
なんでもないわ
なんですか
いやいやいやその一周コメントに
一周コメント実際その残さなくても
ファイルは永続化して残るみたいなやつとかは
なんか
多少対策はできそうだなって思わんでもないけど
まあまあ
別に一定時間経過したら消えるってなったら
別にその一定時間の間ワルスするだけだな
って思って
あまり意味ないなと
確かに結構な
いや
しんどいよしんどそう
うーん
Gitホスティングサービスを作るときは
気をつけないといけない
違う
いやわかんない作るかもしんない
まあね
いや作るか
作んないでしょ
作るか
まあなんか冗談だけど
まあでもその
どうだろうね
まあこういう悪用の手法もある
っていうのは頭に入れといても
いい気がする
ファイルアップロード機能を作るとき
全般に気をつけなきゃいけないことだよね
そうだね
自社サービスがそのサービスが
リリースされるような
サービスになるとそれが返ってリリースされるというか
うーん
はい
次いきますか
えー
あー
これはなんか僕の勉強不足かもしれない
と思いつつ
へーと思ったんで取り上げたんですけど
えー
ユーロピア
government air-gapped systems
breached using custom malware
government
略語かこれ
はい
ブリーピングコンピューターの記事ですけど
はい
記事の内容としては欧州政府の
隔離システムの隔離が何なのかちょっと
わかんなかったんですけど
まあ
air-gappedなので
インターネットに繋がってないよっていう
うーんなるほどね
54:01
それが我々にやられちゃいましたって話
で
まあ記事読んで欲しいんですけど
まあなんで審議されたかっていう話が
えーっとまあ
なるほどこんな手法があって
まあ別に発想としては新しくないんだけど
個人的には
いやいや実害が生まれるんだと思ったんで
話したいなと思ったんですけど
やり方結構シンプルで
そのインターネットに
繋がってる端末に
まあマルウェアをまず感染させて
その端末に
まあ普通に業務とかでUSBを挿すと
USBが感染して
まあ宿主みたいな感じですよね
になってでそのUSBを
隔離されたシステム側の端末に
差し込んじゃうと
その端末側にも
感染していって
そのUSB経由で
インターネットは繋がってないんだけど端末を
跨いでインターネットに
繋がってる端末にたどり着いちゃうと
そのUSB経由で
まあUSB経由じゃないからそのUSBとその
USB
USBドライブ
USBドライブを介して
そのUSBドライブがその端末間を
跨ぐってことでしょ
両方で使われてるって話だよね
で挿しちゃった方がどっちも
まあマルウェアに感染してるんで
まあヨシナに
ファイルが渡ってしまうっていう
ああでもこれ面白いね
なんか結構
作るのが大変そうな気が
そう
そうだね
なんかいろんなものを
かなり時間差をさ設けてさ
その作り込んでいかないといけない
わけでしょ
コマンド&コントロールみたいなのやろうとしたときに
結構大変そうだけど
面白いね
そうなんですよ
で
手が込んでるってのもそうだし
セーフを狙ってるってのもあって
まあAPTというか
まあかなり狙い打ちで
またでもなんかどっかのセーフ系の
そのグループがやってるとかじゃないの
スタックスネットとかと同じような感じじゃないの
スタックスネットとは
スタックスネット
スタックスネットが通じねえのか
そうね
スタックスネットってなんすか
スタックスネット
綴りはね全然それじゃないんだけど
ああでもそれ
これもスタンダードローンのシステムに
ああこれかはいはいはい
この事件は知ってます
スタックスネットと通じながら
これはだからアメリカがやったよ
っていう話だったんだけど
そうだねこれと一緒だね確かに
一緒?一緒なのか一緒か
一緒か一緒じゃないかというと
まあ
うーんと
一緒なのかな
一緒なのかなどうなんだろうな
これはどっちかというともう
ワンウェイチケットというかその
こう
ああというかUSB
いってなんかやって終わりっていう
だったはずでこれは
ちょっと違うか
ちょっと違うんだけど
まあでもなんかやり口
57:01
とか狙い方からして
割とそういう
背景に国家がいるようなやつなんじゃないかな
とちょっと思うんだけどどうなんだろうね
どうだったかな
北朝鮮のとこだったっけな
特にはね
その辺は記事中には
ゴールデンジャッカル
って書いてるけど
ゴールデンジャッカルが何なのか
わかんないね
これなんかヨーロッパがやられたのは
初めてじゃないらしくて
南アジアだっけなどっかの国もやられてる
らしくて
まあ結構幅広く
なってるのかもしれないね
ゴールデンジャッカルは
目的は
スパイ活動であると考えられています
バックにいる国とかはちょっと
パッと出てこないけど
結構
多分無差別
攻撃とは対照的というか
あくまでAPTだからね
これなあ
自分がこの脅威に
立ち向かうことがあるかというと
わからんけど
なんていうか
USB
禁止するのが悪いのか
どうなんだろうっていう
ちゃんとやってるかみんな
ガチガチに禁止してんのかなっていうのと
エアキャップの
システム
の
まあそうね
いや
勝手に解釈しちゃったけど
メモリから出てる展示波を
使ってみたいなのもさ
何回か前の記事で
何回読まなかったかちょっと忘れちゃったけど
あったしさ
なんか
USBドライブが使えなければ別のものを
使うだけだし
確かにね
ちゃんと多層防御
1000回っていう
まあそれでいくとそもそも
インターネットコネクテッドPCのほうに
入られなければ問題なかったっていうのは
多分あると思うし
でもAPTの標的になっていて
っていうのも実のところ難しい部分は
あるかもしれないし
ちょっと難しいね
どこで防ぐのが良かったんですかって
聞かれちゃうと
ちょっと困っちゃうけど
こういうのってやっぱあれなのかな
いやでも分かんねえな
ていうよりなんか
このシナリオで
攻撃が成立するっていうのを
まずどうやって知ったのかが俺は気になるよ
あー
その時点でまずスパイが
入ってるわけじゃん
ここはこういう構成になってるなっていうのを
あーはいはい
でこのUSBドライブを介して何かを
するんだよっていうのが
もうすでにバレてるわけじゃん
なるほどね確かに
その時点で何かしら情報漏洩が
起きてるわけで
1:00:01
まあどうやってるのか
分かんないけど物理的にそこまで
人が入ってきたのか
するともうその誰かが
喋っちゃったのか
あるいはインターネットコネクト
のPCまで入ってから
それが分かったので
C&Cサーバーを経由して
何かそういうマルウェアをそこに配布して
そこからUSBドライブ経由で
横展開を
ラテラルムーブメント的にしていったのか
ちょっと分かんないけど
シナリオがどうだったのか分かんないけど
確かにどうなんだろうね
なんかもっと細かいシナリオが
これに関しては知りたいなって思ったな
なるほど
なるほどね
確かに勉強になります
面白いよね
要考えるなっていう
分かんないけど
爆戦とこれをやる側に
憧れるのもあるよね
なんか
犯罪なんだけど映画で見るような
ハッキングの世界にちょっと近いよね
ねえ
楽しいよね
いやあ
守っていくしかない
何か仮想的に
やるのは仮想的にやっていきましょう
うーん
はい
次は
次もワイかな
ワイのターンが終わらない
もうずっとだよ最後までそうだよ
最後も最後は
最後俺だ
なんでお願いしますよ
いいんじゃない最後
次は
ブリーピングコンピュータの
レゴズウェブサイト
ハクトプ
ハクトプシュ
クリプトクライアンシースキャン
はい
言えたね
おつかれさま
記事の内容は
タイトル通りで
レゴの
ウェブサイトが解散されちゃって
偽の暗号か
新しいレゴコインが
始まったよみたいに
リンクが貼られちゃって
当然詐欺で
引っかかっちゃうと大金を
取られちゃうってやつなんですけど
75分間ぐらい解散された状態が
続いちゃって
実際にトークン購入まで
行っちゃったのは数人程度らしいんですけど
被害がありましたという事件
個人的には
これその
詳しい原因とかは書いてないんで
詳しいのはちょっと深読みが
できないんですけど
こういうインシデント
やられちゃうね
っていうところは
インシデントとしてはそんなに驚かないんですけど
個人的に
コーポレートサイトって結構
僕の経験上だと
ソフトエンジニアが
がっつりちゃんとメンテしてるっていうのが
あんまりない気がしてて
一番最初だけガッて作って
あとはデザイン更新とか
1:03:00
ニュースの更新とか
文言変える時だけ
デザイナーがプリリクを送るみたいな
結構多いんじゃないかなと思っていて
僕は結構
ちゃんとリスクあるんだよ
っていうのを
社内でも言ってるというか
メンテナーちゃんと決めてください
とか言ってて
そういう
警告というか
そういうところの引き合いとして
覚えておきたいなと思ったって感じですね
ここまで極端にやられてるのは
結構LEGOっていう
ブランドネームがあったから
だとは思うんですけど
なんか
この記事の中で触られてたけど
結構派手にやってるから
多分すぐ問い合わせ来て気づいて
対応できたけど
もうちょっと地味にやって
バレるまでの時間を稼いで
悪用するってこともできたはずだと思うし
なんかあんま甘く見ちゃいけないんじゃない
って改めて
思ったって感じですね
そう
なんで
その
コスト構造的にしょうがないんだろうね
そこにちゃんとメンテナーが
つかないっていうのは
あとはその
更新頻度が問題かなと思ってて
個人的には
コップレーツサイトでも
更新しなきゃいけないようなソフトウェアだったら
多分メンテナー貼り付けよって自然となるし
運用の過程で
わからない コード汚いとか何かが
古いかったらジャックツエリに上げるかとか
そういう責力が働くけど
3回ずつに1回
文言修正のブリックが飛ぶような
ものに対して
そこのモチベーションを
自然 何もせずに
アクション起こさずに
そのモチベーションを知らないから
自然に生まれるとは
やっぱ思えないから
結構強く意識して
メンテナンスしないといけないし
もしくはそれができないんだったら
なんだろうな
今回の原因が
どういう原因なのかは分かんないけど
例えばパッケージのアップデートが
もうできません 誰もやりません
とかあったら
内省するんじゃなくて
何かに乗っかって利用しましょうとか
そういうのも選択肢の1つになり得るんじゃない
と思ったり
何かに乗っかったら何かに乗っかって
そっちがやられるんだよな
そこはもう
リスクとして
飲むしかないというか
どっちがいいかだよね
分かんないけど
うちとか結構
やっぱカスタムしたいみたいな
何かに乗っかってると
表現できないものを表現したいっていうので
内省してフレームワークを使って内部的には
いろいろ
出してるよね
そういうときに
抱えるリスクと
それに払わないと
リスクというか運用コスト
1:06:00
運用とメンテナンスコストと
乗っかったときにそれを払わずに済むけど
っていうところで
いろんな天秤に
かけながらっていうのはあるかな
でもね
みんなちゃんと
コーポレートサイト大丈夫ですか
結構ね
僕は今まで気を張られてなかったんで
ちゃんと
改めて
大事だなと思ったって感じですね
あとなんか
うちみたいな企業だと
サービス面広く知られたって言うけど
会社面
関係ないか
関係ないというか
言いたかったのは会社の顔じゃないですか
いわばコーポレートサイトって
分かりましたっていうのがニュースになったときに
なんか
普通に印象悪いというか
信用基礎になるだろうし
2Bのビジネスとかだったら
自分の
が預けた
個人情報に
被害がなかったとしてもコーポレートサイトだから
なかったとしても
じゃあなんかコーポレートサイトなら大丈夫ですね
ってなるかって絶対そうじゃないというか
コーポレートサイトハッキングされたらしいですけど
うちが契約してるサービスは大丈夫なんですか
ってなると思うし
そういう面でも全然甘く見ちゃいけないよねって
うん
はい
うちどういう構成で作ってんだろう
と思ってチラ見したけどよく分からなかったな
うちもなんかでも割と
割とがっつり作り込んでる
感じがするな
がっつり作り込んでそう
規模も規模だしね
うん
ほう
データベースはファイアベースらしいですよ
本当かいな
分かんない
ワッパライザーはそう言ってる
ねワッパライザーはそう言ってる
フレーマーク出てこないんだな
でもビューって出てこなかった
ナクスト出てこなかった
別のページで出てきた
でもなんかリダックスも動いてることになってる
マジでそれは俺が見てる
ワッパライザーと違うワッパライザーだ
そんなの教えてくれるの
そんなの
そんなの教えてくれるの
何で見てるの
普通に拡張機能で見てるよ
俺もワッパライザーで見てるけど
なんだろう
これ見えないか
見えないんだ拡張機能
画面共有
多分そのワッパライザーが出してる画面を
画面共有しないと見えない
別ウィンドウ扱いになってるはずだから
まあいいや
まあでもナクストもあるから
ちょっと矛盾した表示というか
誤検知かもね
なんだろうね
そんな君が見てるの
ん?
まあいいや
ワッパライザーは便利なんで
ワッパライザーは便利
はい
じゃあ次いきますか
これね
1:09:00
なんかちょっと難しいんで
ちょっと理解しきった自信がないんで
まあ割と
こういうトリックもあるんだって気持ちで
読んだんですけど
ユーログの
Using Chrome's Accessibility APIs
to Find Security Bugs
っていう記事で
結構ね興味深くて
どういう記事かっていうと
主題はタイトルの通り
Chromeの
Accessibility APIを利用して
脆弱性を見つける活動をしてます
っていう話で
ざっくり
頑張ってざっくり話していくと
セキュリティー
ティッシュもそうなんですけど
UIっていうのはやっぱ複雑だよね
っていう
なんでその性質上バグが
やっぱ発生しがちやし
あとはこっちがそうだよねって思うのは
見逃しがち
バグがあるのに見逃しちゃうみたいなことが
ありがちで
そのバグのうち
ものによってはそれが
セキュリティー問題に繋がってしまうこともあるよね
みたいなところがあって
具体例として
セキュリティー問題だったんですけど
こういうふうに
悪用できちゃうねみたいなものとかが
一見直結しないとしても
そういうものがあるよねっていうところがあって
これ僕知らなくて
すごい面白いなと思ったんですけど
ChromiumのPublic on Docsで
セキュリティガイドライン
for Security Issuesっていうページがあって
セキュリティー
イシューに対して評価を
付けするための基準が
公開されてて
UI関連で
こういうふうに悪用しうるんだったら
このセキュリティーですよみたいな
記載がきちんとされてる
ので
UIバグ
だからといって
セキュリティー関係ないわけじゃないっていうのが
結構強調されてるっていうところ
これは要は
アクセシビリティAPIを通じて
本来は
これはAですって言ってるものを
これはBですっていうふうに読ませるみたいな
話なのかな
Aですって言ってもBですって読ませる
いや
ちょっと違うかな
もっと違う話なんだ
どういう話かっていうと
このバグ自体の性質が
UIバグあるあるとして
それが本当にバグなのかっていうのが
まず判定むずいのと
あとこっちそうだよねって思ったら再現しないパターン
再現率が
低いっていうのがあって
これをどうにか自動で見つけたいっていう
話があって
ここで
これがChrome用語なのかちょっと
わかんないですけど
Chrome UI Controlsっていうのが
多分UI自体を構造化したものに対して
ソフトウェアからアクセスする手段があれば
じゃあ
それを利用して
UIの操作っていうのを
自動化して
バグを探索的に見つけられないかっていうところが
発想としてあるよっていうところで
1:12:00
そこで初めて
アクセシビティAPIの話が出てきてて
なぜかというと
そのChrome UI
アクセシビティ対応する過程で
スクリーンリーダーでも操作できるようにするとか
展示デバイスとかでも使えるようにするっていう
ところから
やっぱそのUI自体を
あるソフトウェアからアクセス可能なAPIとして
内部的に公開しなきゃいけない
ようになってるんで
その辺はきちんと投資してきて
っていう状態になってるから
これを使って脆弱性の
探索をしてますっていうので
具体的に何をしてるかっていうと
シンプルにファジングをしてますっていうところで
そのUIをセミランダムに
って書いてあってこれが
講述されるところの肝なんですけど
自動である程度
ランダムにUIを操作して
例えばクラッシュしないかっていうのを
自動でテストを回してる
っていうところで
これ優はやすしで難しいポイントっていうのも
ここ書いてあって
一つはそのUI操作の
なんだろうな この手順で操作すると
再現するみたいなパターンも
あったりするから
本当にランダムでやっちゃうと
実際全然見つけられないっていうのがあるので
そのファジングする上での
ベストプラクティスみたいなものが
これもまたなんかGoogleの
ドキュメントであるんですけど
これにのっとってやってますよとか
あとはその実機で見つけなきゃいけない
実機で再現するバグを
見つけなきゃいけないから
ヘッドレスブラウザーとか仮想環境とか
っていうのは使えないので
そこでなんか
インプロセスファザーっていう
クローミウム内部にある
フレームワークみたいなのがあるらしくて
それを活用してますよとか
あとは当然
オーバーヘッドがかなりかかる
実行にも時間かかるしリソースも食うので
そのテストケースの実行とか
そのコントロールっていうのをするための
これもフレームワークというか
コードもはやこれはコードのリンクが
貼ってあったんですけど
そういうものも開発してますっていう
話ですね
完全に理解しました
そうですそういう話
結構なるほどねと思って
面白いこれは
この
この記事ではまとめなかったけど
セビリティガイドラインズは結構
実業務で使えそうと思って
面白かったなっていうのもあったし
何が面白かったかっていうと
基準が割と明確なのと
このセブだったら
多分
Chromiumの開発ライフサイクルで
自動化されてて
多分次のマイルストーンに
セブが一番高かったら
3ヶ月以内にやんなきゃいけないって
マイルストーンに自動で乗っかってきて
自ずと多分開発者の手に渡っていく
だから緊急度の高いバグ
セキュリティバグがきちんと
修正されやすい
枠組みになっているよう
こういうのいいよね
こういうの素晴らしい
どうやったら
その辺の会社で
こういう構造に持っていけるのかな
よほどパワフルに
1:15:00
これを押し通す
力がないとやれないよね
スコープとしては開発チーム全体
もしくは事業チームが
ちゃんと合意してないときついよね
容易に事業上の優先順位の高い
事情によって覆されるというか
そこも覆せない
っていうような
決まりなのかな
会社としてそうしますっていう風にするしかないよね
会社でやろうと思ったら
クロミウムはどうなんだろうな
あとは事業性質にもよるだろうね
クロミウムはやっぱ
セブゼロのやつそのまま
コーチしたら影響出る人数が
運10億単位
とかになるっていう
その責任の重さがやっぱりあるから
きちんとやってるっていうのもあるだろうし
じゃあうちのサービスが
運10億人使ってるかっていうと
でもさ
そこまでの責任感を求めたいよね
サービスプロバイダーに対しては
自分が使う側だったとしてさ
今話してと思ったのは
責任を求めた一方で
規模がでかくなってきたときに
クロミウムの開発チームとか
社内外を含めた
すごい大きな開発コミュニティで
一個一個のバグ
セキュリティバグを評価する人と
それを渡される人がいたときに
事業としてトライアルを
何だろうな
事業としてトライアルなら
評価した人はこう評価しましたっていうのを
開発者に渡して
開発者は評価を受け取って
自分のチームの
ミッションと照らし合わせてやるやらないを
決めるみたいな意思決定が発生したときに
その量がめちゃくちゃ増えるわけじゃん
規模がでかくなると
その量が増えちゃうって
多分質のばらつきも増えるから
その一個一個をいちいち判断するって
コストもかかるから
じゃあもうちゃんと基準決めて
これは危ないってこう言い取りましょう
危ないものは何日年直すって
こう言い取りましょう
例外はあるならじゃあもうレーズしてください
みたいな方が全体最適としては
もしかしたらいいのかもな
っていうのをちょっと思って
いやマジ優は安しやんけんなんだ
そうそうそれはそう
いやでもそこ目指したいな
理想としてはね
優は安くて
いろいろ課題はあると思っていて
その
いろいろ課題はあるんだよ
まあね
まず人がそんなに潤沢にいないとかさ
そうだね
あとなんかChromiumの場合もしかしたら
その開発パイプラインが
太いとかはあるのかもな
現実の事業はさ
この領域はこのチームとかなってさ
じゃあバグがこのチームに偏ったら
とか
じゃあ分散できんのとかあるけど
ブラウザー分かんない
1:18:00
いろんな仕様といろんな
多分ある程度の得意領域はあるけど
まあでもなんかレスポンシビリティの
自己認識の問題だと思うんだけどな
個人的には
向き合いが
安全なブラウザを世の中にデリバーする
っていうのを
市場命題の一つとして抱えていればさ
必然的にそうなるじゃん
まあねまあまあ
それ自体が価値の一つですよっていう風に
組織としても認めているし
世の中もそれを認めているわけだから
確かに確かに
自分たちでそこの認識がなかったらさ
いくらやってもさ
どうしようもないじゃん
いやーそうだね
プロダクトとしての価値として
強いアイデンティティがある
っていうのはでかいかもね確かに
それがない会社でさ
プロダクトセキュリティやってもさ
張り合いがなくない?
いやーでも
すごい極端なこと言うとね
でも難しいよ
いつか話した話し分けをさせて
セキュリティを売りにしている
事業とかプロダクトもあるけどさ
そのやっぱ
当たり前品質でもあるよねっていう
認識があるのかな
俺が一番ムカつくのは
すごいタグチっぽくなっちゃうけど
いいよ
そのさ
表向きは安全な
サービスを提供したいです
って言うけれども
なんか別に
実際は全然振る舞いが一致してないじゃん
みたいな
すごい嫌で
その企業の指先まで
セキュリティはほどほどで
でもなんか
体験はいい感じですよ
っていう別にいいと思ってて
口が裂けても
それは言えないんだろうけどさ
そうねー
そういう2枚舌みたいなのがすごく嫌で
いやーでも
いろんな企業はそうだろうな
なんか口で言うしかないもんね安全ですって
口で言うしかないんだけど
それも分かるんだけどさ
確かにね社内にいる身としてはね
確かに
その組織にいるとしたら
いやーまあ確かに
そういう意味では確かに張り合いがないという
言い分も分かるわ
セキュリティはなんか
経営上のこういう課題に
位置づけてますよっていうのをさ
なんかはっきり言ってくれればさ
まだ分かりやすいというか
じゃあ
なんていうか例えば
他のものと比べたときに
これに優先するものではないんだな
通常これに優先するものではないんだな
っていうのはなんか理解できるよね
全部大事ですみたいな
言い方をするのは
確かに
なるほどね
いやー悩ましいっすね
それは
いや別にいいんだよ結局
詰まるところただのリスクマネジメントだからさ
財布全部金で解決しますって言ってくれるんだったら
それでもいいと思うし
どんな組織であれね
いやー
なるほどね確かに
1:21:00
難しいな
いやでも
いや僕は目指しますよ
何の宣言か分かんないけど
まあだからなんかその
ある種その
プロダクトのセキュリティをやりたいです
っていう人にとっては
こういうエリア
そういう領域ってすごく
魅力的な部分なのかな
確かにね
今思いました
プロダクトの命題と
方向が一致してるっていうのがいいんだろうね
便利なブラウザーを
届けるっていうのもそうだけど
根底に安全であるっていうのが
間違いなくあるよっていうのが
まあその
目に見えるじゃん
OSSだからこそっていうのも
多分あると思うけど
開発をやってる組織として
組織あるいは
コミュニティっていう言い方のほうがいいのかな
OSSだしね
いやー
そんな感じです
はい
あとねこの
ちゃんと触れなきゃいけないのは結構この取り組み自体は
そんなめっちゃやっててめっちゃ成果出てます
っていう話ではないっぽくて
結構やってて
アクセシビリティAPIのこの話ね
チャレンジしてるよっていう
ここはうまくいってないみたいなところの元気もあるんで
まあ続報に期待したいな
って感じです
あーでも面白いですね
Fuzzingのやり方としておーなるほど
うん
こっちはね読んでないんだけど
Fuzzingのベスプラ的なところとかは
うん
ちょっと読んでみたいね
いやーFuzzingって実はちゃんとやったことなくて
なんか
ちょっとやってみたいな
いやーないんじゃないやったことある人はなかなかそもそも
そんなことないんじゃない
結構研究テーマとしてはメジャーどころなんじゃないの
あーそうか
Fuzzerを書いてみましょうとかさ
うん
結構難しいのが
入力インターフェースをどう
つなぎ込みますかっていう部分なんじゃないかな
そうだね
それは確かに
あとは
何をもって異常と判断するかみたいなところなのかな
きっとね難しいな
想像だけど
確かに
リードミーだけ見ると
クラッシュが一つの
あれになってしまうけど
クラッシュ見つけるだけでも相当でかいよな
うん
はい
じゃあ次
私無双パート最後の一つですね
えっと
GitHubのブログですね
The Second Half of Software Supply Chain Security on GitHub
っていう記事なんですけれども
なんか
前後半の記事っぽくて
前半読んだ記憶ないけど多分読んだんだろうな
と思いつつ
内容としては
本題の
エクスキューザー
前後半っていうか
ここまで折り返しできたよ
っていう話じゃないの
そういうことか
タイトルだけ読むとそういう風に読めたけど
1:24:01
あーそうかも
2020年後半に
えー
なんかアメリカの
政府に対する大規模なサイバーセキュリティ攻撃が
公表されて
っていうところから始まって
ここまでで一旦折り返しですよ
ここから何が起きますよ
っていう話を書いてくれてる記事なんじゃないかな
タイトルだけ読むと思いましたが
ありがとうございます
英語力
その前段は今言ってくれたやつだね
その米国の大統領の話が
まあ要するに
ソフトウェアサプライチェーンちゃんとやらなきゃいけないけど
どうすんのって話で
本題としてはこの記事で
メインで触れられてるのは
GitHub Actions上で生成した
ソフトウェアの成果物に対して
署名っていうのが
簡単にできるように
なりましたよ
その検証自体も
GHCLIっていうGitHub禁制の
CLIコマンドがあるんですけど
それで簡単にできますっていう話ですね
これ本当に
多分僕ちょっとまだ
動作というか
実際に試してないんですけど
ドキュメント見る感じは
公式のActionsを
ドキュメント通りに使えば
何の問題もなく作れそうだなと思っていて
で
この署名自体を
通じて検証できること自体は
結構多くて
どのリポジトリでビルドされたかとか
ビルド手順への参照みたいなのがあって
これは多分
そのビルドが走った
ワークフローファイルへの参照があるのかな
で あとはそのセットで
そのハッシュ このハッシュの
このファイルで
ビルドされたソフトウェアですっていうのが
検証できたりとか
またどういうトリガー
ワークフローディスパッチなのか
プッシュなのかとか多分その辺が
署名を通じて保証されますと
これいいね
なんかGitHubならではというか
全部GitHub Gitのリポジトリの中で
管理してるからこそ このソースコードと
ビルド手順の
ハッシュを一致させることができる
間違いない
いや 間違いない めちゃくちゃいいんですよ
で 僕ちょっとまだ
勉強できてないんですけど
SLSA Framework
っていうのがあって
で これでいう
ところのその成果物に対する
検証みたいなので
レベルが0から3まであるんですけど
この
ドキュメント通りに
ワークフローを使ってビルドして
検証っていうプロセスを踏むだけで
このフレームワークのレベル的には
0から2に引き上げられるよ
っていうところと
あとその2と
じゃあレベル2とレベル3
一番高いところの差分は何かっていうと
そのビルド環境が
きちんと適切な
隔離がされてるかどうかっていうところが
差分になるみたいなんですけど
その辺はそのGitHub Actions
のワークフローを
例えばその実行する環境で
シークレット使うとか
特定のブランチしか実行しない
1:27:01
みたいなのをエンバイルメント
シークレットとかあとルールセットとかで
きちんと隔離することで
レベル3になるよっていう
話が書いてあって
具体的にどうすればええねんっていう
ドキュメントも
こんなこともあろうかという感じで
GitHubから用意したので
そこをきちんと
乗っていけば
このフレームワークで言うところの一番
レベルの高い
ソフトウェアの
署名と検証
実現できるよっていう
のが記事ですね
いい記事
いいよね そう いいんですよ
で これちょうどなんか
もともとこの署名のくだりは
知ってたんだけど
ちゃんと解説してる記事は
初めてというか結構ベータな雰囲気が
押し進める感じになったのかな
と思って
あとは社内で利用してる
JHLintっていう
GitHub ActionsのLintツールがあるんですけど
この製作者さんが
多分御社じゃないかな 今も御社なのか
分かんないけど
御社じゃないか まあいいや
鈴木俊介さんっていう方の
プロダクトなんですけど
この人は結構セキュリティちゃんと
いろいろ
ちゃんとやってる人なんで
JHLintの最新版がこの検証
というか署名を実装してて
なんで
早速
検証みたいなのを試してみようかなっていう
あと実業務で
いつ使うかなってなったときに
そのActionsの成果物
言うてもActionsの成果物を
どっかに
プロダクションデプロイするみたいなパターンって
うちは
GKE環境なんで
ドッカービルドしたものに
署名とかは
そもそもドッカー側の仕組みに乗っかればいいから
そんなにはないかもな
と思いつつ
GitHubのプライベートレジストリで
社内のパッケージを運用する
とかなったときは
この辺もし使えるんだったら使えるといいかもね
とか
使いどころが全然ありそうだなっていうのと
ただ主には
あれかな
Gitクローンしてきたものがちゃんと正しいかとか
ビルドされた
Goのバイナリーとか
あるあるだと思うんですけど
それを代わりで引っ張ってきたときに
それがちゃんと
意図したものであるのか
っていう検証には
使うってところは
全然やっても良さそうだなって思ったっていう
感じです
なんかGo
Goインストールとかと
組み合わせて使いたいというか
ビルドインされてほしいな
フックしてほしいよね
確かにね
その辺
組み合わせてほしいよな
何かいざこれじゃあ
全部やれるかって言われると多分
本当に危ないものから順にやる
とかなると思うんだけど
結構大変だよね
そういう意味でも
1:30:03
前回も言ったけど
パッケージレジストリにはぜひ頑張ってほしいな
わかんないけど
はい
GHって全然使ってないんだよね
本当
全然使ってないっていうか
なんなら全然違うエイリアスに
割り当ててたから今裏でコメントアウト
しながら
ちゃんと
ホームブリューで入れながら全然違う
エイリアス
今とりあえずそれ外してやるとこなんだけど
GH使う場面
そうだね
アクション上で使うことの方が
個人的に多いかもな
本当だよ俺もあんまり
API叩くときとかは便利だよ
カールで頑張らなくてもいいから
あと
そうだね
業務だとリポジション棚直しとか
シークレット一覧は取れないかな
API叩かないと取れないけど
でもその辺も結構
なんだかんだ便利だと思う
ログインがめんどくせえ
今
嫌になった話なんだけど
すぐに
全話急ぎで終わるんで
ログインコード出ないんだけど
頼むよ
ホームとかいっぱい
出ねえ
レースコード自体もちょっとずつ進化してるから
とても
後でやろう
じゃあ
よろしくお願いします
システム環境変数のパスに
設定するフォルダの権限にご注意を
ラックセキュリティごったに
ブログさんの記事ですね
2週連続の登場ですかね
先週は
バーコードとかQRコードの
話でしたね
一言で言ってしまうと
パスを通じて高権限で
定期実行する
定期実行されるプログラムが
ある場合
一言で説明するのむずいな
パス内の優先度の
より高い場所に一般ユーザー権限で
書き込みできるところがあると
ものがあるとやばいよっていう話
要は
今ので分かりました
僕は記事読んだんで
分かっちゃったんですけど
バラしてもいいかもねステップを
ステップをバラしますか
まず
ルート権限とかで定期実行してる
プログラムがあるとします
実際から
パスを参照して
実行ファイルの場所を
特定しているような
部分がありましたよ
という状態で
例えばなんですけど
パスAパスBパスCの順で
パスを参照していったときに
パスBに
実行されるファイルが
ある状態のとき
例えばパスAに
パスAが一般ユーザー権限で
書き込みができる状態だと
1:33:01
そこに同名の
難しいな
パスBの
例えばホゲホゲみたいな
ファイルを実行してたとすると
パスAのホゲホゲっていうのを
一般ユーザー権限で置いてあげると
ルート権限で
ファイルが実行されるので
権限昇格に
悪用できてしまうよっていう話
分かりやすい
はい
言われてみりゃ
そりゃそうだよねって話ではあるんだけれども
結構パスって雑に
足しがちじゃん
うん
結構雑に足してます
正直
結構
実際だとあれかな
Linuxサーバー自前で運用しててとか
ちょっと古いシステムで
クーロン
自分でシステム設定してとか
でも
ちゃんと考えようと思うと結構大変だろうね
クーロン以外も定期実行するような
何がどっから参照されてるかとかも分かんないし
ていうかそもそも
パスを使うなって話だよね
そういうとこでね
それはそうかもね
優先とかいうところはね
要はだから実行ファイルの最初でパスを
初期化してあげるとかさ
必ず統一の
必ず固定された条件の
固定された状態のパスで実行されるとか
あるいはパス自体は空っぽにしておいて
絶対パスで参照
常に絶対パスで参照しないといけないようにするとかさ
そういうやり方を取らないといけない
これこそ分かんない
本気で運用するなら
CSPM的な考え方で
設定的にダンプして
おかしくなってないかチェックしたくなるな
この時点で大丈夫ってなってもさ
どっかのタイミングで知らない人が
ぽって設定してアウトとか普通に
ありそう
本当に起きるのはすごい稀だと思うけど
別にでもそんなことせんでも
設定ファイルの
チェックサムとかで
十分なんじゃないの
要は環境を初期化する
イニシャライズのフェーズを
一個先に設けてあげて
イニシャライズのための設定ファイルの
チェックサムとかを先にチェックしてあげて
チェックサムが一致してなかったら
でも定期実行するときに
最初にそれをするってことでしょ
それ自体を
予想ってやつを
上位のパスに置けばいいんじゃない
チェックサムをするやつを
安全に守りきらなきゃいけないから
だからそこだけ担保するほうが
全部に気を配るよりは楽って話あるかもね
1:36:04
いやでもね
分かんない
新卒に
パスは
その設定ファイルで
常に初期化する前提でいたわ
リラックスするか
パスはそうか
そういうのができるのか
パスは常に
毎回実行時に初期化する前提において
かつその設定を
かつその設定ファイルみたいなのが
万が一書き換えられてたとしても
それはチェックサブで
話がややこしくなってきた
いろんな前提条件がフワフワしすぎちゃって
全然全部忘れてください
素朴に思ったのは
新卒のときのシステムは
クラウド化されてない世界だったんで
本番サーバーに
今考えたら遅いけど
SSHログインして
対応とかオペレーションとかクーロン設定することは
あったんですよ
これに気を配ってやれる人は
ほぼいないんじゃないかなと思うと
自前で運用したくないという
感想にしかなんねえな
確かに
という非常にあっさりした
記事でしたが
ありがとうございます
ラックさんのこのブログめっちゃいいね
面白いね
面白い
今後も
ウォッチしていきたいところですね
いっぱい読んだね
もういっぱい読んじゃったな
ほんとだよ
大丈夫ですか?
生きてますか?
まあまあですね
おねむ?
オープンAIのやつはちょっとちゃんと読んでおこうな
オープンAIのやつもちょっと読みときたい
オープンAIのやつ読みたいね
自分でも
ちょっと試してみたいわ
ああ確かにね
やりすぎたらバンされてすんのかな
いやされるんじゃない
お前脅威アクターやろって
あとね
触れなかったけど
チャットGP
オープンAI自体を狙う攻撃の話もね
触れられてたんだよね
だからその辺もしかしたら
深掘りすると面白いかもしれない
それは別トピックじゃねって思ったんだけど
取り上げてる以上は
もしかしたらなんか相関があるのかもね
結構ね結構長いんだよね
しんどそうだね
1:39:01
この分量の英語を読む
大体
いつ読もうかって感じ
なんか
本当いろいろ触れられてそうだな
はい
じゃあ今週もこんな感じで
また来週も
頑張って読みましょうか
うっす
じゃあ
なんだっけ
捨て台詞を忘れた
思い出しました
大事だからこういう
最初と最後にちゃんと決め台詞でね
あー
なんかもっとかっこいいの考えたよ
えーいやこんぐらい緩いのでいいよ
これぐらいが
いやわかんない僕は親しみやすい
いや別になんか
親しみやすさ重視で
言ってるんで
いやだってセキュリティさ
怖いもん親しみやすく
いこうよなんかあこんな鉄壁ペイがやってるんだって
思ってほしい俺はね
別にやけっしょすごい人なんで別にいいんですけど
僕はねペッペキペイでやっていきたいんで
ちょっと
ペッペキペイ感を出していきたい
と思ってます僕は
はい
出てんのかこれ
出てるはず
そんな感じで来週も
よろしくお願いします
おやすみなさーい
おやすみなさい
