エピソードの導入とテーマ設定
こんばんは、Replay.fm、第12回です。
こんばんは、なんか声出なかった?
今、すごい。
バグってた?なんか。
ホラー映画みたいな声出して。
そんなときもあったな。
え、なんか、なんかない?なんか、あの。
いや、あるよ、あるよ。
あるよね?びっくりした。
あるけど、このタイミングでやってくれたのすごい良いじゃないですか。
ピンポイントすぎるなぁ。
いやー、今回さ、今回からさ、その、僕の中で勝手に一個コーナーを考えてきて。
あら。
あの、前回深掘りできて、できなかった記事とか内容、復習してきたんで聞いてくれシリーズっていうのをやろうって思ってたんですけど。
まあ、言い訳なんですけど、家族がインフルエンザになったりできなかったんで、来週からお楽しみにしててください。
やったねー。
僕からは以上です。
楽しみだなー。楽しみだなー。
もうでも前回やった内容とか忘れちゃったよ。
聞いて思い出せばいいのか。
そっか、俺11回まだ聞いてねーな、そういえば自分で。
あ、ほんと?その、いやなんかさ、その、なんか、わかんない、自分で読んだけど時間なくて読み、深掘りできたなってパターンもあるし、
そのヤギ足が読んでくれて、あ、そんな、こんな良い記事あったのかみたいで、なんかちょっとちゃんと誠読したいなみたいな時に、
その復習のきっかけがあんま、だからその、このFMさ、当初の。
まあね、さらっとね。
新しいものは、あの、きちんと読むっていうとこに対するその強制力みたいなのが自分の中で今ループがいい感じ回ってるが、
さらっと読んだもののうち、なんか良いものを復習するみたいなとこの強制力はないんで、
ある意味自分に厳しくいこうとは思ったわけじゃないけど、まあでも普通になんか面白いかなーと思ってちょっと、
いや面白いかなーっていうか、まあなんかわかんないですね、思いついただけです。
でも聞けなかったんで。
やってみましょう。
はい、来週からやります。
はい。
はい、じゃあ今日はやりますか、上から。
テストのアプローチとプロセス
やりましょう。
一つ目がテストレシピをやってみたフリーデベロッパーズハブの記事です。
フリーのQAアドベントカレンダー2024の1日目の記事ですね。
えーと、今週分は12月1日までなんでまだそんなにないんだけど、
来週以降多分アドベントカレンダーの記事が大渋滞することになるので、なんかちょっとドキドキしてる感じですね。
若干返りが見えてるかと思いきやそんなに見えてないんだよな、今回またね。
はい。
えーと、まあなんか別にセキュリティの真ん中っていう記事ではないんだけれども、
えーと、ちょっとまた後でなんでこの辺を紹介するかって話をするんだけど、
えー、まあQAがボトルネックになっているとか、
継続的なテストができていないっていう方に対してのアプローチをしたよっていう話を
記事にしてくれてる感じですね。
で、具体的にはQAエンジニアが設計しているテストケースをエンジニアリングに
エンジニアに渡すことで、ユニットテストとシステムテストの、
これちょっと呼び名がいまいち分からんのだけど、
システムテストって呼んでるのは何なんだろう。
うーん、今ちょっと読み直してるんですけど、
まあ大抵で言うとそのクオリティコントロールの、
主導でExcelとかスプリットシートにこういうテストケースっていうのを羅列して、
そのQAが手作業で確認していくようなテストのことなんじゃないかなと、
僕は解釈しました。
なんか進め方のところも開発終了後にシステムテストを実施。
QAエンジニアがシステムテストを実施って書き方になってるんで、
多分それで合ってるんじゃないかと思います。
ありがとうございます。
まあそのユニットテストとシステムテストの重複削減を図ってよっていう記事ですね。
結果的にこれになってたよ、これに近いものになってたよっていうものとして、
The Art of Unit Testingっていう書籍で紹介されているテストレシピがこれに当たるよ、
みたいな形で紹介してくれていて、
テストレベルのバランスの適正化を目的として、
シナリオをもとにエンジニアとQAエンジニアの話し合いを通じて、
どのテストレベルを行うかを決めていくこと。
ちょっとよくわからなかったんだけど。
筆者曰くスクラムでの受け入れ条件と近い印象があって、
受け入れ条件にさらにテストレベルを付与したようなもの。
要は多分この受け入れ条件はどのテストで担保するよみたいな話なのかな。
そうだと思う。だからなんかその、わかんないけど、
パッと機能が思いつかないけど、
なんかいい機能ないかな。
商品を売るっていう機能があったときに、
1万円以下でしか売れないみたいな、
異常系、正常系いろんなケースがある中で、
これは単体テストで実装しちゃいましょうと、
これは手動で確認しましょうみたいなのを1個1個決めていく話なのかなと思いました。
テストレベルって言ってるのは、
どうなるのか、そのテストレベルのピラミッドみたいな定義が
もしかしたらどっかにあるのかもしれないけど、
自動でやるのか、言い継いでやるのか、
手動で担保するのかとか、
そういうグランデーションの話かなっていう風に思います。
ありがとうございます。
ちょっと細かいところは読んでくださいって感じなんですけど、
なんでこれを紹介してるかというと、
僕は答えることに常に言ってるんだけれども、
クオリティアシュアランスとプロダクトセキュリティって
かなり親和性が高いと思っていて、
これをセキュリティでもやれたらいいんじゃないかなって思うんですよね。
ここで言うと、このQAエンジニアがやってるテストケースっていうのが、
ある種のセキュリティテストのテストケースみたいになっていくようなイメージ。
それが極論ユニットテストに落とし込めてるんだったら、
それがベターだと思うし、
なんならQAエンジニアのテストケースに
セキュリティエンジニアがサポートして落とし込んでいくとかも
アリだと思うし、
システムテスト、なるほどね。
今テストレベルの引っ張ってきた図が入りましたけど、
単体テストがあって、単体ではエンドポイント単位で
APIのエンドポイント単位でテストをするみたいなテストがあって、
システムテストはシステム全体って言ってるけど、
この画面でこのボタンを押したらこれが起きるとか、
多分そういうのが出るって。
受け入れテストはユーザージャーニーとかのか、
まあ流度が多分違うのかな。
そうですね、おっしゃる通りですね。
今言ってくれたセキュリティのやつをテストケース、
何かしらのテストレベルのテストケースを落としましょうってなったときに、
それをしようと思うと、おのずとその使用時点で
セキュリティ観点での正常系、異常系みたいなのを
洗い出さないとそれができないよねっていう風になるはずだから、
そういう世界は目指したい人生ですね。
過去系にはしたくない、目指したい人生。
簡単ではなく目指したい人生だなってしみじみ思いますね。
そうなのよね。
あとなんか個人的にちょっと、
セキュリティもやりたいよねっていう部分も
つながらんくもないと思いつつ思ったのは、
この一つはテストレシピっていう名前をつけて、
こういう取り組みをしましょうっていう、
名前付けと定義がされてるのが一ついいなと思っていて、
これはQAだからとかいう話じゃなくて、
みんながいいと思って、
これって別に何か、いや分かんないです。
各社、これやってますよって人もいると思うんですよ。
僕はやってますとか、うちはやってますとかってあると思うんだけど、
組織としてこれをやってますっていうところになると、
そもそもこのプロセスってこういう名前を付けて
こういうタイミングでやってるみたいな、
定義がされてないとできてるとは言えないと思うんだけど、
フリーさんの事例ではテストレシピっていう名前を付けて、
こういうプロセスを会社として回し始めましたっていうところは、
素晴らしい枠組みだなっていうところと、
これやることによってソフトウェアエンジニアが
テストケースについてかなり早いタイミングで考えるっていうのが、
セキュリティとQAの関係性
プロセスで担保できるっていうのが結構個人的にいいなと思ってて、
開発スタイルとかプロセスによるんだけど、
結構多いんじゃないかなと思うのは、
仕様があって、その仕様通りにまず動くものをバーって書いて、
書いた後にこれに対してどういうテストがあるといいかなって、
そのタイミングで初めてテストケースに思いを馳せるみたいな、
開発をしてる人も、いい悪いじゃなくて、
そういう開発をしてる人もすごい多いと思うんですけど、
なんていうか、そういうふうになると、
そのテストケースの品質自体を担保するのは、
そのエンジニアの力量に完全によってしまうから、
得意不得意にも左右されるし、
せっかくそのクオリティーアシャランスをしてくれる専門家がチームにいるのに、
そういう人の目線を活かせないとか、
さっき言ったセキュリティー監督も入れたいよねってなるんだったら、
それもエンジニアの知識に依存したテストケースしか書けない、
その人が知らない異常系はもう一切書けないっていう風になるから、
早い段階で仕組みで抑えられてるのは、
これ実現できたらめっちゃいいなって個人的に思いました。
ですとね、リリース前のガードマン、
セキュリティーもQAもよくある共通項としては、
リリースする前にやってNG出ましたみたいな、
ガードマンみたいになっちゃってるみたいな話があったけど、
それを緩和というか、そうならないためのアプローチの範囲の一つだなって気はする。
確かに。
QA、そうだね、QAとセキュリティーは共通項多いですよね。
なんか来週の記事なんだけど、
QAというかソフトウェアテストっていう広い概念で言うと、
多分同じ領域にあるのかもしれないね、もしかするとね。
セキュリティーテストっていう観点で見た時には。
来週のテストとかでも探索的テストの話が多分あるのか。
これか。
それそれそれ。それは来週話すんだけど。
これできるんだったらセキュリティーテストできんじゃねっていう感じはすごくあって。
そうだね。
一方で、よくというか気になるところとしてはこれどうなんだろうな。
取り組み始めて、もう回ってますなのか取り組み始めましたのかわかんないけど、
でも6月に発表されたんですね。
やってみてどうだったかっていうところまで書いてくれてるから。
これが回って2ステップ目にセキュリティの観点も入れ込もうかとかが現実的な気がするな個人的には。
結構このテストレシピっていう名前何でもいいんですけど、
似たようなテストを回すことだけ結構大変だと思うんですけど。
順番はどっちでもいいかなと思っていて、
ある種のソフトウェアテストとかQAみたいな部分とセキュリティテストって神話性が高いよねっていう前提は変わらないと思っていて、
なので、だからまずQAともっと近いところに置きましょうっていう話を先にやった上で、
これをやったら自然と組み込まれていくだろうし、セキュリティの観点もね。
逆回りだと思う、もちろん。
QAとセキュリティの神話性をうまく活かしてる事例があれば結構知りたいな。
サイボーズなんかだってQAの組織がセキュリティテストやってるじゃん。
今もそうか分かんないけど、昔は少なくともそうだった。今もきっとそうと思うけど。
いやー、そういう形にしたいな。
品質保証の一環としてセキュリティテストをやるよっていう形でやってるので。
なるほどね。
それはだからもうど真ん中というかその、もう真正面からくっつけちゃいましたっていうパターンなんだよね。
それなんか、いやー、そうっすね。思います。
頭の中でいろんな現実を思い出しながら。
やっぱりやりたいっすね。
という記事でした。
ありがとうございます。
じゃあ次いきますか。
Chrome OS Flexの導入と障害対策
次がChrome OS Flexの導入で大規模障害に備えるっていうPR Timesさんの開発者ブログですね。
Windowsの障害対策としてChrome OS Flexを活用してるよっていう記事です。
ある日突然社内で前例のない規模のWindows OSの障害が発生しました。
何が原因なんだろう。
社内では画面がブルースクリーンになり動かない、Windowsが起動しないという問い合わせが相次ぎましたと。
皆まで言わないけど、どっかで聞いたような話だなっていう感じなんですけど。
それに対していろいろ社内の業務が回らんっていう状態に対してWindowsに依存せずに他のOSを活用するっていうアプローチを検討して
いろいろなやかになった結果、Chrome OS Flexを活用してみることにしたよっていうお話ですね。
MacBookとかChromeBookとかも検討したけれども、Macの場合は高額すぎるから障害対策用の備えっていう観点ではあんまり現実的じゃないよねとか
ChromeBookは比較的安価だけれども、新しくそのためだけに端末を大量に購入するっていうのはコストが高いよねみたいな話とか。
そういう中でChrome OS Flexであれば古いWindows端末とかにもインストールできるから、
保有してる古い端末をそのまま使って障害体制を持たせるっていうのができるようになったよっていうお話ですね。
検証の過程とかをつらつらと書いてくれていて、そんなに深い話はないんだけど一例として興味深いなっていう。
そうですね。これは全然知らなかった。
いやー、これ大変ですね。
BCPで何かどこまでちゃんとやれてるのかなとか、その何ていうか、現実に起こり得るシナリオに対してちゃんと備えができてるかみたいなのって、
実際どこまでみんな検証してるのかなっていうのはすごく気になるところで。
いやー、気になるね。
でもなんか今回、某インシデントに対してきちんと対策をしてここまでアウトプットできる形にできてるのはすごい良いことだなって思うね。
じゃあなんかこの冒険、別に濁す意味ないんでいいんですけど、そのクラウドストライクの味なんだとしたら、
なんかその辺再発しないような仕組みを作ったみたいな記事をどっかで見て、ここで話したかったと思いつつ、
多分取り上げられてない気がするんですけど、なんかWindows側の仕組みでなんかあれかな、
そのデカめのマイクロソフトのカンファレンスがあって、その辺ちゃんとする仕組みをリリースしましたみたいな話があったんだけど、
まあとはいえもう1回起きちゃってるんで、対策はした方がいいし、これはめちゃくちゃ…
まあそれに限らずってあると思っていて、極論そのマイクロソフトのWindowsのアップデートでWindowsが死ぬとかはなくはないかもしれない。
確かに確かに。確かにね、間違いないですね。
いやー、これは勉強になりました、素直に。
このChrome OS Flex自体もこういうスケースを想定してるのかな、それとも…
そんなことはないと思うけどね。
軽量なOSだよな。
Chrome OSファミリーの中になんかの位置づけであるんだろうね、きっとね。
バックグラウンドがGoogle Cloudになってんのかな、クラウドベースって書いてあるから。
Googleワークスペースとの親和性が高いって書いてあるね。
ちょっとクラウドコンプティングじゃないけど、LP見てると地球に優しいみたいなことが書いてあって、なるほど。
地球に優しい。
ある程度はクラウドで動いてて、全部じゃないと思うけど、
だいたい向こう側の計算結果画面描画してるだけとか、そういう感じの世界観なのかもしれない。
知らんけど、ちゃんと見ないとあれですけど。
はい。
はい、ありがとうございます。
じゃあ次いきますか。
次も私ですね。
フリー社のセキュリティ訓練
この投資詐欺、フリーから漏れた情報を悪用してるかも。
そのとき社員はどう動く? 当社のセキュリティ訓練が再び。
というタイトルのITメディアニュースさんの記事ですね。
タイトルの通りで、フリーさんで実施したセキュリティ訓練に関して取材をした記事なのかな、きっとね。
で、読んでくれとしか言わないんだけど、
いわゆる机上訓練よりはもうちょっと本格的なものでいったほうがいいのかな。
関係者をわーって集めて、たぶんシナリオを裏で用意しておいて、
事務局的な人がまずいて、その人はシナリオを全部知ってて、
徐々にその参加者側のアクションに応じて、シナリオに関する情報を開示していくっていうパターンなんじゃないかなと思うんだけど、
そこまでちょっとよくわからない。
今回のテーマが別々の窓口に寄せられた2つの問い合わせを結びつけてハンドリングできるか、みたいなテーマでやってたばかりで、
情報共有の難しさが課題だよねっていう。
要は横串で全然異なる問い合わせを結びつけて誰かが見てるっていうのが、
何ていうか、状況としてすごく難しいよねっていうことだと思うんだけど、きっと。
っていうのを紹介してくれてる。
かなり参考になる記事なので、ぜひ読んでくださいっていう感じなんだけど。
訓練系の、この手の訓練って割とありとあらゆる事情でやったほうがいいと思っていて、
現実的に回るのかとか、必要な役割が抜け落ちてないかみたいな観点とかって、
多分こういうふうにやったほうが早いと思っていて。
そうだね。
あるいはマニュアルがいるんじゃないかみたいなね。
いろいろ。
一線と対応のプレイブックみたいなのと多分一緒で。
やれば強制的に炙り出される部分は間違いなく作るよね。
そうそうそうそう。
いやー、なんか風物詩みたいになってますけど、
相変わらず素晴らしい取り組みだなって思いますね。
結構大変だよね。
いやー、めっちゃ大変だね。
シナリオ作るのもそうだし、
多分だけで人集めて貼り付いてもらってるはずなので、
うんうんうん。
なんか、なかなかいろいろ大変だろうなって。
ね。
なんかその辺、
うん。
まあ貼り付くことに普段の業務進めたいみたいな気持ちになる人もいろいろあるから、
なんか前情報というか。
逆に普段の業務の中でそれが入ってきた時に進められるのか、
ハンドリングできるのかみたいなのをやれるかもしれないけどね。
その、あえて貼り付かせずにみたいな。
はいはいはい。
なんか去年とかはそんな感じだったっぽいけどな。
まあでも、あっという間に今日貼り付けてるのかな。
その、やるよって日だけ決まってて、
うん。
たぶんいつ何が起きるかは誰もわからんみたいな感じ。
ああ、なるほどね。
うん。
だからその、必要な人が必要な場所にきちんとその呼び出されるかみたいなところがたぶん。
うん。
なんだけど、まあ今年はどうだったかな。
どれぐらいそのリアルにやってたのかが気になるんだよな。
セキュリティのアラートの話とかがなんかあったりとかして。
うんうんうん。
なんかその、いやー見学したいよね、NDAを結ばせて。
結ばせてくださいね。
見学したいね。
うんうんうん。
なんか個人的に、いやー強いというかいいなと思ったら、なんかちゃんとトレンドを割と、まあこれでもかというぐらい反映してるシナリオじゃないですか。
うんうん。
なんか流行りの特殊詐欺に、流行りのディープフェイクで、なんか裏側が実はウチだったみたいな。
うん。
まあその裏側がウチだったっていうとこは別にトレンドじゃないけど、その実際起きてること自体は割とトレンドみたいなところで、
なんかその会社の端っこって言い方なんですけど、セキュリティの関心からどうしても遠くなる部署とかポジションの人とかに、
まあ強制的にこの辺が、いや現実に全然起きますけどねみたいな感じのメッセージを発せるのがいいなっていう気はするのと。
あとなんか情報共有の部分は、今ちょっと手元でふと思ってみたんですけど、
フリーのその従業員数が4年前は620人で、2年前が1083人で、で今たぶん1300人ぐらいらしいんですよ。
なんで、まあ結構なペースで拡大をしていてっていう意味で言うと、そのなんというか、
3年前の訓練の時はそのめっちゃ綺麗に回ったのに、その規模が拡大したからまあこういう課題が実は出てきたみたいな、
なんかそういうさ、定期的にマシナリが違うにせよ大規模な訓練をしてるからこそ炙り出せる部分があるんじゃないかなっていう気はしていて、
別にその辺言及は確かなかった気はするんですけど、なんかその辺も学びになってそうで、定期的にきちんとやっていくっていうのはすごいいいなっていう気持ちがありますね、個人的には。
ね、なんか実施するその取り仕切る側のノウハウとかもあるから、なんか個人的には定期的に実施した方がいいんだろうなとは思うんだけど。
また不利者に対してつくづく思うけど、この辺ちゃんとそのたぶん気合の理解を得た上で、
得てないとやれないじゃないですか、こんな、コストで言うとかなりのコストを投資しなきゃいけない。
訓練の重要性と課題
まあね。
下手したら全社員になって電車集めるみたいなところで、そこにちゃんと雰囲気っていうのは欲しいなと思いますね。
いやー、だから2つその、まあそうですね。
はい。
いやなんかその、会社がその価値をきちんと認識できるってことと、認識できたとしてもこれをやる能力があるセキュリティチームを持ってるかどうかっていう、なんか2つ。
その、そんなに実はハードルの低い、まあ全、そうですね、両方ハードルの決して低くない条件を突破してるっていうのはすごい、いや素直に素晴らしい会社だなって思った。
でもじゃあ笑っちゃったのは、いやそこにそういう組織を作るのを、作れるのかなーみたいな気持ちで別に作る立場になるわけじゃないっていうのがいいかもしれないですけど、はい。
ちょっとそういう気持ちになりました。
うーん、そうね。
まあ、なんて言ったらいいんだろうな、なんか、うーん。
まあそれをやれるそのチームみたいな部分で言うと、その、まあやってるかも多分、なんか試行錯誤しながらだと思うので、うーん。
なんか事例自体がこうして共有されてくるっていうのが割と大事だよねと思っていて、これうちもやってみようよみたいな、やりやすい、言いやすいじゃないですか、この話が記事として出てくると。
確かに。
なんか脅威モデリングやってみました、みたいな話とかも多分同じだと思っていて、うーん。
みんな試行錯誤しながらやってるからさ。
うん、確かにね。
ガイドラインみたいなのは、あー、調べたら出てくるもんな。
でもなんか、それできないから困ってるんだって話で、こういう事例があると思うことで確かに。
まあ、あとその組織の形がさ、なんか会社によってそれぞれ違うわけで、その、うーん、一概にこうすればいいよっていうのがあるわけではない中で、
うーん。
確かに。
こうやってみるっていうのはやっぱ、いや、なんていうかすごく大事だよなと思うし。
うんうんうん。
うーん。
いやー、ありがとうございます。
別に机上訓練でもいいと思うんですよね。その、局の関係者だけ集めて、これでこういう例が起きました、あなたは何しますかっていうのを順々にこうヒアリングかけていくとかでも十分だと思うし。
うーん、確かにねー。
あるいはもっと小さい範囲でその、完結するようなシナリオでまずはやってみるとかでもいいと思うし。
うんうんうん。
インシデントレスポンスの重要性
それこそセキュリティとSREだけでとかさ。
うんうんうん。
チーム内だけだとちょっとあんまり、まあ価値がないとは言わないけど、こう、なんていうか、要は連携がちゃんとうまくいきますかっていうのをさ、一番確認したいから。
そうね。大事っすね。こういう系だ、その、訓練しないと絶対にその打席の数がむしろ増えたらまずい領域だから。
そうだね。
インシデントレスポンスとかも似たような、まあこれもインシデントレスポンスなんですけど、その、セキュリティの関係ないインシデントレスポンスも似たような課題があって、
うん。
なんか思い出した、ちょっと思い出したりしながら聞いてました。
うん。いや、まさにその通りだと思います。
うん。
うん。
そうですね。はい、ありがとうございます。
なんか、なんかが炎上してます?みたいなときとかね。
そうだね。それもインシデントだね。サービスが落ちたと。
うんうん。
いいよな。やんないとね、その、打席に立つ人が同じになっていって俗人化してみたいなのがもう、どの会社も絶対通っている道なんで、これないとね。
そうですね。
はい。じゃあ、次がDNSアビュースのテクニックスマトリックスっていう、何て言ったらいいんだろう。なんか、ドキュメントって言えばいいのかな。
うん。
JPサートさんがなんかXで投稿してて知ったんですけど、なんか、ファーストだったよね。確かに出してくれてる。うん、ファーストだよね。
ファーストっていう、多分、世界規模のCサートの、何て言ったらいいんだろう。その、集まりと言えばいいのか、組織と言えばいいのか分からないけど。
うん。
なんか、そういうところがまとめて出してくれてる。DNSのアビュースのテクニックと、それぞれに対して、何て言ったらいいんだろうな。検知ができる、いわゆるいろんなエンティティがあるわけじゃないですか。
エンドユーザーとか、Cサートとか、ホスティングプロバイダー、アプリケーションサービスプロバイダーとか、DNSに直で言うところで言うと、レジストラーとかレジストリーとかがある中で、それぞれのエンティティが各アビュースに関してディテクトするケイパビリティを持ってるかっていうのを、マトリックスとして、表としてまとめて出してくれてるっていうものですね。
で、ちょっと全部見てないんだけど、具体的に何を、取るべきアクションみたいなところもさらっと説明してくれてたりとか、それぞれのテクニックがどういうものなのかっていうのを紹介してくれてるところをリンク集を作ってくれてたりとか。
あとさっきのエンティティっていうのが、何なのみたいなのを説明をザーッと書いてくれてるところとか、いくつかページがあるような感じですね。
はい。
理解しました。パッと読んで、どう読めばいいんだって思ったけど、完全に理解しました。
DNSアビュースのテクニックスマトリックス
なるほどね。
こんだけ全部まとまってんの多分ないと思うので、他に。
うんうんうん。
うん。
すごいDNSピーコン、C2との通信。
なるほどね。
うん。
うんうん。
なので紙まとめですねっていう紹介ですね。
ありがとうございます。
これは会社で。
というか逆にこれ僕、多分分かんないやつとか正直いくつかあるんで、これを基にモラ的に勉強しようと思いました。
うん。
そういう使い方もね、いいかもね。
うん。
ちょっと前のウェブセキュリティの歩き方のスライドみたいな感じで、
ああ、そうだね。
これ分かんねえじゃんみたいなのをここから掘っていくっていうのは全然いいと思います。
結構ね、多分半分ぐらいしか分かんない気は。
ちょっと読んでみよう。
ありがとうございます。
うん。
紙まとめ。
ほい。
SRHMとかも読んでもいいだろうな。
うん。
うん。
多分実際そのDNSの管理とかって、まあどうなるんだろうな。
まあ会社によるか。
SRHMがやってるパターンもあると思うんで。
うん。
ほい。
じゃあ次いきますか。
はい。
ほい。
次は私で、
AWSWAFがあれば安心、甘い、甘すぎる。
第2回ゴートンカップ開催。
次の雷セキュリティチャンピオンは誰だ?
っていう雷さんの記事です。
はい。
ああじゃねえよ。
ああ。
いや、噛んじゃったなと思って。
あの、エクスクラメーションマークとね、はてなマークがすごいついてるんで、頑張ってるんですけど。
どういう記事かっていうと、あの社内でCTFみたいなのをやりましたと。
で、去年もやってて、その記事僕読んだ記憶あるんですけど、
まあそれは第2回やりましたよっていう記事です。
で、記事の内容自体は、いくつか具体的に出した問題をピックして紹介してくれてて、
なかなかいいなと思ったのは回答を載せてないっていうのがね、すごいいいなと思ったんですけど、
他まだちょっと解いてないんですけど、
そのタイトルにあるAWSWAFに対して、
WAFのシグネチャーの検知みたいなのがあると思うんですけど、
そのシグネチャーの検知を回避したいスケールインジェクションを投げるにはどうすればいいんですかみたいな問題とか、
実際にコードベースを渡して情報コードベースをさせる、
まあいろいろいくつかあってっていう感じですね。
っていう感じですね。
で、問題の紹介と仕込みの様子と、仕込みの様子というか仕込みのプロセスと、
大会当日の様子とするみたいなところで結構ワイを入れましたよっていうような記事になってます。
で、個人的に感想というか思ったのは、
なんか去年の記事も結構良かったなという気がしていて、
第1回の時はおそらく多分セキュリティエンジニア、セキュリティチームが1名とかだったと思うんですけど、
その中でセキュリティこれからプロダクトチームとしてやっていこうみたいなところで、
知ってもらうとか関心を持ってもらうっていうところでやってみて、
その目的みたいなの結構達成できたよねみたいな感じで去年確か。
すごいさっくり言うとそういう感じだったと思うんですけど、
それを継続してやってるっていうところはまず素直に素晴らしいなと思ったところと、
あとこれね、個人的にすごい思ったことなんですけど、
CTFっていうものに対して、
しっかりいろんな専門家の人から聞いたことあることとしては、
何でしょうね、物によるんでしょうけど、
例えばCTFを半年間があって勉強したらセキュリティ強くなるかっていうと、
監視もそうは限らない部分があるというか、
CTFによってはいろいろ知識を得られる部分もあるし、
でも実務につながりづらい部分もあるみたいな話をよく聞くなっていう気は個人的にはしつつ、
一方で何でしょうね、ソフトエンジニアの中でセキュリティは大事だっていう認識はあるが、
具体的にじゃあどういうふうに脅威があるのかとか、
どんな攻撃手法があるのかとか、
WASPトップ10ぐらいは分かりますけどとか、
そういう階層度のソフトエンジニアってあんまり少なくないと思っていて、
そういう人たちにセキュリティは結構実は面白いんですよとか、
実はこんなところがこんな脆弱性になってしまうんですよみたいな部分を知ってもらう切り口のきっかけとしては、
すごいいいんじゃないかなと僕は思っていて、
なのでこういうふうに社内で社内の人が結構問題を見ると分かるんですけど、
現実に業務でちょっと作っちゃいそうな脆弱性とかが多分多そうな気がしていて、
そんな感じで社内向けにやってっていうのは結構いいんじゃないかなと思っているし、
実際なんか記事にはやってみた後のアンケート結果、アンケートみたいな結果が書いてあるんですけど、
普段の開発で使えそうな学びがあったかとか、難易度みたいなところ、難しすぎるとやっぱりさっき言った目的から外れちゃうんで、
そういう部分をきちんと集めてその辺も狙いに近い結果になってそうだなというところで、
まあいいです。いいというか、いい形でCTFを活かしてるんじゃないかなって個人的には思いましたっていう感想です。
まあ設計次第だと思っていて、あくまでフォーマットがCTFですよっていうだけの話で、
別にある種のハンズオンを伴う研修ですよっていうふうに捉えると、別にフォーマットがCTFなだけですよっていう。
話だと思うし、別に。
確かにね。その表現しっくりくるな、なるほどね。
だからCTFが必ずしも直結しないっていうよりは、要はキョープロと一緒で、
トップコーダーの問題が業務に直結するかっていうとそんなことないよねとか、
でもアッドコーダーのビギナーズコンテストぐらいのレベル感だったら、業務でももしかしたら役に立つことがあるかもねみたいなのは、
ちょっとわかんねえな、エアアップだからなんとも言えない。
キョープラはちょっと、まあでも。
ちょっと毛色が違いすぎるけど、要はレベルが上がれば上がるほど、
強い人たちを奮いにかけなきゃいけないから、できるだけキワキワをついてくる問題にどうしてもなると思うし。
それは思います。
だから競技性を持たせない、ある種の教育コンテンツとしてやりますっていう場合は全然その限りではないと思う、僕は思っていて。
めっちゃ腑に落ちました。
はい、そんな気持ちです。いやー、いいですねって気持ち。
でも外してソフトエンジニアは問題解決が好きな人多いから、
まあ別に、よほど極端な問題じゃなければ、なんか楽しめる人が多いんじゃないかなって思うんだけど。
うん、そんな気はするね。
でもなんかあんまり、難易度調整は結構大事な気はしてて、結構ね、
やっぱお手上げみたいになっちゃうと、なんていうか、あんま学んだ感がないというか、その辺何倍は難しいなって気はする。
まあでも30本作ったらしくて、30本もあればたぶんグラデーションつけてやってるっぽいだろうから。
よう作ったなって感じな気はしますけど。
そんな記事でした。
社内CTFの実施とその影響
じゃあ次も、あ、私か、私ですね。
えーとこれは、AI Under the Microscope What's Changed in the WASP Top 10 for LMMs 2025ということで、
クイルス、クイルスのブログですね。
クォリス、クォリスです。
いやー、今頑張って思い出したけど間違えた、クイルスのブログです。
フリガナ振っとこうかな、はい。
えーと、で、記事の内容はですね、何かっていうと、
先週か前々週、前回か前々回ちょうど話題に出たあの WASP Top 10 for LMM Application っていうものがあるんですけれども、
それが2025年版っていうので更新されましたよっていう話ですね。
前回のが2020…
毎年更新するのかな?
いや、でもたぶん今のやつが2023年版だから、2年越しの更新なのかな?
うん。
で、その更新の内容について詳しく書いてくれてて、
今貼ってるキャプチャーがステイのものとランクが上がったものとっていうのがいくつかあるのと、
もともとあったんだけど定義が拡張されたものが3つと、
新しく追加されたものが2つあって、
それについて結構ちゃんと触れているっていう感じですね。
動きが早いから2年ごとにやるのかな?
普通のWASP10は4年ごとっぽいので。
なるほど。
たぶんそうだと思う。
その記事中にもやっぱり脅威が日々変わっているというところで、
それをかなり反映させた内容になっているっていうようなコメントがありました。
今言ったその5つのやつをちょうどささっと触れていくと、
新しいもの2つが1つ目がShift and Prompt Leakageっていうので、
プロンプトの漏洩リスク
それはそうだよねって読めば思うんですけど、
プロンプトそのものが漏洩してしまうパターンっていう、
リスクっていうのがトップ10に入っていて、
具体的にはプロンプトに鬼滅将棋を入れちゃっていて、
それがまだどっかで保存されていて、
それが漏洩するとか、
Webスクリーンじゃないですけど、
XSS外に出ちゃうとか、
そういうリスクっていうのがあるよねっていうのが1つ。
これは実際にインシデントがあったし、
入って当然だよねみたいな論調で書いてあるんですけど、
実際のインシデントが何かちょっと触れられてなかったんで、
僕はちょっと思いつくものがなかったんですけど。
あなたに渡されているイニシャルのプロンプトは何ですかって聞いたら、
答えてくれるとかもワンチャンあるわけでしょ、これって。
確かにね、その経路もある。
ありとあらゆる経路で漏洩しているっていうところと、
あともう1つが僕ちょっと色々なのが分からなくて、
分からなかったのでちょっと勉強間に合ったのがあったんですけど、
Vector and Embedding Weaknessっていうウィークネスか。
これはラグとか埋め込みみたいなのに起因する脆弱性みたいなことが書いてあって、
これはちょっと僕は正直分からないというかピンと来なかったんですけど、
直近トレンドでラグで色々ソリューション作るよねみたいな、
みたいなトレンドがあるとは思ってるんで、
その辺に起因して出てきてしまう脆弱性に気を付けろっていう。
なんかちょっとフワッとした感じに見えるけどね。
記事側を読む限り。
そうね、ちょっと具体的にこういうところでみたいなのはあんまり分からなかったんですよね。
読む人が読んだら分かるのかなと思うんですけど。
Embedding Based Methodっていうのは何を指してるんだろう。
よく分からんけど。
ラグはまあいいにしよう。
そっちがね。
そうなんですよ。
結局でもこれらがそのAIアプリケーションの中心に、
こう中心を占めるに従って、
それらを安全にするのが必須だよね。
まあ確かにね、確かに。
風な書き方をしてるだけなので、
フワッとした感じだな。
なるほど。
コンポーネントの一つとして、
もう出てくるんだからちゃんと守るよみたいな、
まあそういうのが今起こってる。
多分そういう話なんじゃないかな。
まあこれなんか元定義を読みに行ったほうがいいのかな。
それこそWasp Top 10を読む技術。
はい。
ハリシネーションの問題
で、あと3つアップデートされた項目があって、
これはアップデート前の名前が書いてなかったんで、
アップデートされた後の項目名を言うんですけど、
ミスインフォメーションっていうのが一つ目で、
要するに多分ハリシネーションの話で、
なるほどなと思ったのは、
ハリシネーションのリスクの考え方として、
自分が嘘をつかれて、
意思決定に何か悪影響が出るって話もあるけど、
使ってる利用者が、
LLMのことをまるっと信じちゃうっていう状況自体を利用して、
間違った情報を意図的に広めるみたいなこともできちゃうよねっていう話があって、
その観点でもリスクがありますっていうので、
それが個人的には確かにいいと思ったっていうところと、
もう一つがUnbounded Conceptionで、
これは更新前はDOSだったのかな、
サービス拒否攻撃に関する項目だったんですけど、
それに加えて、
リソースっていうのは多分LLMを合格したアプリケーション側の話なんですけど、
アプリケーションリソースとか、
それを組み合わせるコストっていうところに対して、
ある種のE-DOSとかも含めてってことですね。
そうですね。
それらも内包する形で定義がアップデートされました。
LLM自体の特性としてやっぱり動かす、
動作させるのに求められるインフラとか環境っていうのはどうしても高級なので、
費用もかかるし、システムの負担もかかるしっていうところで、
相対引きずられる形でリスクも大きいよねっていう感じになってます。
権限管理の重要性
こうした3つ目がExcessive Agencyで、
LLMに権限を移譲する、
行って渡していくみたいなアーキテクチャが増えていく中で、
それをやっていくと権限管理のところのリスクが高まるよねって話で、
その辺ちゃんと監視しないとダメだよっていうところですね。
僕がイメージしたのは、
LLMにNotionとかNotion AIみたいなの埋め込まれてますけど、
Notion AIは多分暗黙的に、
いや、それこそ使用把握してないですよ。
僕は使用把握してないけど、
例えばパブリックページに対しては全部権限持ってるんでしょうね、
おそらくNotion AI自体。
で、プライベートページももしかしたら持ってるかもしれないってなったときに、
その権限管理ちゃんと気を付けないと分かんないですけど、
Notion目線だとマークスペースまたいで、
そのAIが読みに行かないように気を付けなきゃいけないとか、
また僕らが何かLLMを使うときに、
インテグレーションして読み込ませたら、
そこから回答してくれるよみたいなサービスがあったときに、
そうやってそのリード権限を目的に渡してることになるけど、
大丈夫なんだっけとか、そういう部分とか。
社内で見えちゃいけない情報が見えちゃうみたいなのもあるし、
サービスプロバイダー観点でいうと、
要はユーザーとしては社内で見えちゃいけないものが、
そういうエージェントを通じて見えてしまうっていう問題もあるかもしれないし、
サービスプロバイダー観点でいうと、
さっき言ったようなテナントをまたいで権限を持たせちゃうと、
非常にまずいことが起こり得るよねみたいな話なのかな。
そうね。
なんかそれが書いてあったっていうよりか、
僕がちょっと想像したところ、
その辺なのかなと思って。
まあまあ、そういう話のように思うけれども。
うん。
アップデート前もそんなに似たような感じだった気がするんですよね、確か。
うん。
はい。
そんな記事でしたね。
うん。
なんかプロンプトの漏洩は結構個人的にはなるほどなって気はしてて、
何でしょうね。
なんか、
もともと僕が持ってた観点としては、
いろいろなサービス、会社で例えば使いたいって言われたときに、
じゃあそのデータって、渡したデータってどうなってるんですかみたいな、
ちゃんと揮発性があって発揮してくれるのか、
学習に使ってるのかみたいな、
学習に使ってるか使ってないかみたいな観点をずっと持ってたんですよね。
学習に使われたらまずいよねみたいな。
じゃあ機密書を入れないでとか使わないでとか、
そういう議論になってくるんだけど、
学習に使ってるか使ってないとしても、
向こう側がなんか、
ちょんぼして漏洩するみたいなのはなんか、
普通に原理上はあり得るのかっていうところを考えると、
うーん、めんどくさいなと思ったっていう。
まあどこまでディスク需要するのっていう、
まあ究極的には別にLLMアプリケーションじゃなくても、
いろいろノーションとか突っ込んでんじゃんみたいな話と一緒ではあるから、
まあまあまあって感じ。
だから利用者側が考えることっていうよりかは、
サービス事業者側がちゃんと考えるって話ではある気がしつつ、
まあそんなのは確かになーって思ったって感じですかね。
まあ権限の話とかは別に、
まあ、まあいいや。
まあまあまあそれはそうやろっていう。
なんか前も話したけどやっぱその、
そもそも別にLLMだからっていうところじゃない部分はあるよねって気がする。
うーん、例えばそのザピアのアクセスが会社内でフルオープンで視野されてたら、
その人が見えてるものは全部その、なんていうか、
アクセス経由で全部見えちゃうよねみたいな、
コネクション経由で全部見えちゃうよねみたいな話とかもあるし、
多分それと一緒だよねっていう。
社内の話とそれと一緒だと思うし。
はい、そんな感じのお聞きでございました。
じゃあ次、岩屋さんお願いします。
あー、マジかー。
なんで?
やんなきゃダメかなー。
先週のあのコードブルーのこかつさんのあれと同じなんだよな。
しんどーって思って。
はい、えーと、フラットセキュリティXSSチャレンジのライトアップですね。
はい、流れてきただけで全然知らん人の記事なんですけど、
えーと、ちょっと前にやってたフラットセキュリティさんのXSSチャレンジのライトアップです。
やりました?これ。
全然見逃してました。
なんで見逃したんだろう?
フィードリー壊れたかもしれない。
フラットセキュリティのXSSチャレンジはフィードリーには流れてきてなかったかもしれない。
えー、流れてきたんじゃない?だってブログに。
流れてきてて、あ、そういうことか。
あ、ごめんなさい。やってないです。
それ言うと。思い出しました。
いや、この記事が流れてこなかったっていうんですね。
あー、この記事はそうね。ツイッターでXで流れてきたの拾ってきただけだから。
うん。
はい、えーと、一応3問出てたんですが、えーと、ちょっとね、全部は、全部っていうか、
まあ1個ずつ解説するのも非常にしんどいんだけど、えーと、さらっと流していくと、
えーと、1問目がサーバーサイドサニタイゼーションっていう、マイアンさんっていう方の作文なのかな。
えーと、これをこう、まあ毎度のことながらこれを口頭で説明するのなんかの罰ゲームとしか思えないんだけど、
えーと、クエリパラメタ経由で渡すペイロードがバックエンドでDOMPURIFYでサニタイズされて、
えーと、EJSに、まあそのままEJS側のエスケープを扱わずにそのまま出力されるっていうページでXSSしてくださいってやつなんですが、
えーと、結論から言うと、DOMPURIFYでサニタイズするときに、そのどこに表示されるかのコンテキストは与えられてないので、
与えられてないかつ、そのリフレクションされるところがテキストエリアの中っていうのが前提としてまずあって、
なので、DOMPURIFYが完全に無視するID属性の中にテキストエリアのトジタグを仕込んであげると、
テキストエリア要素の外に出られるよっていう問題でしたよと。
なるほど。これは怖いなー。
いや、DOMPURIFY、いやわかんないです。業務で一応防止になってる。
うん。ちょっとなんかでもこのコンテキスト与えるみたいなのができるのかどうかがちょっとよくわからなかったんだけど、
この場合はだからテキスト、どうしたらいいんだろうね。
この場合テキストエリアのその囲ってるところも含めてサニタイズしてからリフレクトすればいいのかな、多分。
わかんねーけど。ちょっとそこまで試す時間がなかった。
記事帳を読むと文字実態参照になってるよみたいな書き方をしてるんだけど、
実際多分文字実態参照にはなってなくて、ちょっとサラッと試すコード置いといたんで後で手元で試してほしいんですけど、
文字実態参照にはなってなくて、単純に多分テキストエリアの挙動としてこういう挙動になるっていうものだと僕は思ってるんだけどちょっとわかんないですね。
次がクライアントサイドディシンクティバイ、りょうたけいさんの作文ですね。
リクエストスマグリングの理解
ここからだんだん解説が無理やりになっていくんだけど、すごく簡素なWebサーバーがPythonで書かれてて、
XSSを通せそうなパスのハンドラーが返してくるレスポンスが常にコンテントタイプテキストプレーンになってしまうのをリクエストスマグリング使って無理やりテキストHTMLで返させるみたいなものだと僕は理解したんだけど、
説明できるほど理解できてない感じ。
なんやかんやあって回答はこれっていうのを後ろの方に書いておいたんですけど、iFrame経由で呼び出した。そもそもリクエストスマグリングって言われてわかります?
わかんないっす。
一個のリクエストの中に別のリクエストを仕込むんですよ。
Webって一番裏方のバックエンドに届くまでにいろんなフィルターがかかる場合があるわけじゃないですか。
送られてきたTCP上のHTTPのメッセージの解釈に差があったりすると、ここまでが一個のHTTPリクエストですよって切っちゃった後に別のHTTPのリクエストが実は入っていて、
丸ごと裏に実はそのまま送られる状態で、裏では別々のHTTPリクエストとして処理されるとかそういうのが起こり得るんですけど、それを指してリクエストスマグリングっていうふうに呼んでいる。
会社の脆弱性取り味で一回ググったのを思い出しましたよ。難しいなって記憶があります。
っていうのをうまいこと使って、多分テキストHTMLで返してくれるパスにそれを分投げてあげると、具体的にノットファウンドなパスで送ったそのパスがそのまま画面上に表示されるので、
それをテキストプレインじゃなくてテキストHTMLで返させることができればXSSが成立するよっていうパターンなんですけど。
サニタイザーが動いていて、それをうまいことバイパスするみたいな話とかも書いてあったりする具合でございます。
ちょっと間違ってたらごめんなさいっていう感じですね。
チャーセットと課題解決
で、次がチャーセット、これチャーセットと読むかキャラセットと読むか、周波が分かれる気がするんだけど、僕そのままチャーセットって読んじゃうんですけど。
何て読みますかこれ。
僕もチャーセット派ですね。
チャーセット派ですか。
キャラセット派読み方、キャラセットらしいですよ。
キャラセットなんだけど、キャラセットなのは理解しつつチャーセットって読んじゃうんだけど。
チャーセットシェナリガンズっていう金川さんの作文ですね。
ごめんなさい、これは説明できない。
理解するには時間が足りなかったです。
BlobのURIとエンコーディングをゴニョゴニョしてやってる感じ。
各自読んでくるように。
ちょっとね、読み下してパッと理解がゴニョゴニョしてできなかった、これ。
前髪足が理解できないのは僕は5倍の時間かかるだろうな、理解するの。
なるほど、ありがとうございます。
これ解けるのすごいんですか?いやすごいですよね、たぶん。
いや分かんない、僕この問題自体は全然見てないから、分かんないけど。
解けた人どんぐらいいるんだろう。
ね。
気になるところですね。
その辺もまとめて公表してくれるんじゃないかな。
Blobの話見てオリジンの継承とかちゃんと思い出さないと全然分かんないなって思って。
MDNのドックスいくつか貼り付けてるんで興味あったら。
強みとコミュニケーションの重要性
ソータは読んでおいてください。
はい、僕は読みます。
公開ページには載ってこないので。
そうですね、読みます。
ありがとうございます。
以上です。
じゃあ次お願いします。
強みを2つ以上持つっていう、いつものオフトピー、コニファーさんブログですね。
オフトピー扱いして申し訳ないんだけど。
普通に面白い記事枠でいいんじゃないですか。
記事の中身は全く説明しないんだけど、
強みを2つ以上持つことを意識しておくといいよっていう記事ですね。
あなたの強みは何ですか。
あなたは喉から鼻からみたいな質問ですね。
強みか何なんですかね、あんまり整理したことないな。
何でもやるのが強いんじゃないですか。
何でもできるとは言わないっていうのがミソなんですけど。
何でもそれなりにやりますっていうのが多分。
それでも強みは何ですかって聞かれたら何か答えられないとまずいんじゃないですか。
僕みたいな人にこういう質問結構むずいんですよ。
なぜかというと結構器用貧乏なスキルセットになりつつあるんで。
強みの定義次第だけど、
バックエンドは言われたもん作れます。
フロントエンドも言われたもんギリ作れるかもだけど品質下がるかも。
セキュリティはかけ出しですみたいな。
プロダクト作り、仕様とかもちょっと口出してきますみたいな。
それぞれで、じゃあその単一の領域で食えるのって言われたら、
バックエンドだったら食えるんじゃないですかみたいな感じの。
その4つぐらい今出せるのが強みという解釈もできるし、
みたいな。でも僕自身の強さはあんまそこは本質的じゃない気はなんとなくしていて、
ソフトウェアという領域に限ってですけど、
それなりに課題解決ができるのが強いと思っているっていうのが、
頑張って答えるとしたらあるのかなって気はしますね、課題解決をするっていう。
その課題設定とどこからどう手をつけるかっていう部分の足元があるじゃないですか。
まずなんか課題を正しく認識するのもおかけして簡単だと思ってなくて、
一周から始めようって本とかありますけど、
一周設定ミスると多分仕事の設定めちゃくちゃ下がるはずなんで、
それをきちんとやるっていうのが大事だし、
やった上で解決する手段を持たなければアウトプットが出せないってなった時に、
その手段をどうにかやりくりするのが多分そこそこ得意なのかなーって気がしますね。
だからセキュリティの話とかも会社でセキュリティが一周だって見つけて、
一周は見つけたと、でもなんか手段がない、
セキュリティチームもない、専門家もいない、
なんかめっちゃ多分僕が一番まずいと思ってるみたいな、
じゃあなんか政治とまでは言わないけど、
必要なんだよっていう情報を集めて、
まずはチームを作ろうとか、
チーム作った上でわからんものは勉強しようとか、
あとその、じゃあ専門家いないともうどうしようもないか業務委託で引っ張ってこよう、
その予算を取ろうとか、
なんかそういう動きができるっていうのはわかんないですけど、
なんか最近は素直に、
なんか意外と同じ動きができる人ってそんなにいないかもなと思うような感じですかね。
そうね。
たぶん。
まあ強い貧乏になるのが怖いよっていう人は、
まあそういう人は大丈夫じゃないっていうふうにコニファーさんは書いていて。
あー、へー、なるほどですね。
そうだねー、貧乏。
でもなんか昔より怖くなくなったな。
昔めっちゃ怖かったけど、
最近はなんか、
いやー横転できることやっぱりいっぱいあるなって気がしますね。
そうね。
本当に。
それでもこれが自分の一番の強みって言える領域は持っておいた方がいいとも書いていて。
なるほど。
うん。
その心はなんだろうな。
まあ全部その平均的にやってもいいんだけど、
アイデンティティと言える何かがないとなんとなく不安になりやすいっていうふうに書いてる。
うん。
なるほどねー。
まあ確かに。
まあむずいところやな。
なんか僕的にはその不安を解消する手段はその強みを明確に作る以外にもなくはないんじゃないかなって気はしてて。
うん。
いやどうなんだろうな。
その強み自体がさ、
うーん。
まあでも評価軸によってその強みの点数、強みの定量化した時にその点数が変わっちゃう気がしてて。
例えばそのバッチャバックエンジニアを界隈みたいな捉え方をした時に。
まあね、それはね。
その、そこでナンバーワンとかさ。
ああ、でも一番の強みは何ですかっていう問いにおいてはそれは関係ないんじゃない。
その、自分のレーダーチャートの話だからさ、それって。
自分のレーダーチャートで一番尖ってんのどこですかっていう話でしょ、これって。
ああ、そういうことか。
その界隈でどうなのかとか別に何かそんな気にしてんでいいと思うけど。
ああ、なるほどね。
まあそれ、そうか。
まあその価値観。
わかんないけど、まあそこは僕の勝手な解釈だけで。
うーん、まあ確かに。
正解はなさそうな話し方。
いや何か思ったらその、うーん何だろうな。
いやーまあ難しいっすね。
僕は割と外に基準を求めちゃうかもな、この強みの話です。
まあなんでそういう解釈をしてるかっていうと、
結局一個の領域でてっぺんとの座編でも複数の領域を掛け合わせると、
まあなんていうか特色が出やすいよねっていう話をしてくれてるので。
うーん、なるほどね。
なるほど、面白いな。
僕は割と何か解決する課題によってその持ってるものが強みになるかどうかが変わると思ってるうちがある気がするな、なんか考えながら。
うーん。
まあその、まあ映像配信サイト来るために最適化ゴリゴリやってくださいバックエンジニアとしてって言われたら僕の、
いや僕はもうクソ雑魚ですってなるけど。
うーん。
なんていうか、いやでも見当たりと思うからな。
いやよくわかんねえな、よくわかんないっす。
八木さんの強みは何ですか?
僕の強みは、まあセキュリティー割と広く浅くできますようは一つの強みだと思っているのと、
割とどのレイヤーでも、どのレイヤーの人が相手でもなんとなく話ができる、話が通じるっていう。
まあ僕はこの二つを軸にして生存戦略を組んでいるんだけど。
なるほど。
うん。
確かにな、いや全く同意っすね。
一緒に仕事した経験もあるんで思いますけど。
いやー、なんかしみじみ思うけどさ、コミュニケーションスキルってさ、めっちゃ大事だよね。
いやそうなんですよ。
ソフトウェア界隈だからといってね、コミュニケーションは全くない場所に、いやコミュニケーションの中にはコミュニケーションスキルそんなに高くないけどバリを出すっていう人もいるけど、
この強みの話で言うと多分なんていうか、なんだろうな、二つ以上、コミュニケーションがないんだったらもう二つ必要みたいな感じになる。
うーん。
しかもその点高い点数が求められるというか。
うん。
そういう部分もある気がするな、知らないですけど。
誰かが傷ついたら申し訳ないけど。
うん。
うん、いや人と仕事するんでね、どうしても。
うん、だからそういう意味でもネオゲーション強みは確かに僕もそう思いますっていう感想です。
あーありがとうございます。
公認ということで。
公認。
リプレイドットFM公認。
リプレイドットFM公認。
リプレイドットFMの強み二つ。
あの、ツイッタープロフィールに書いていい?
あの、例書名とかに書いて、職務経歴書とかに。
リプレイドットFMでもこう言ってますって。
第三者認証取得済みって書いてる。
リファレンスチェックや。
リファレンスチェック。
あーそうですよって言ってこない?間違いないですって言って。
これ以上説明することありますか?
若干のうさんくささが漂うけど。
いや必要になったら頼もう。
お願いします。一度も読んでください。
ちょうどその、ちょうどなのか分からんけど、
2024年11月の経産省のサイバーセキュリティ人材の育成促進に向けた
これまでの議論の整理と継続的な検討事項っていう資料が
セキュリティキャンプ界隈って流れてきてチラッと見たんだけど
セキュリティキャンプの拡充
セキュリティキャンプの新たなキャンプを実施しようぜっていうことを書いてる。
セキュリティキャンプコネクトっていう箇所で書いてるんだけれども
多分やと合わせて裾野を広げようよみたいなものだと僕は解釈したんだけれども
そもそもセキュリティキャンプって枠が狭いじゃないですか。
会場のキャパとか講師のリソース面の話とかを考えたりすると
どうしてもある以上のキャパを持つって多分難しいんですよね。
それこそ講師の質も考えるとかなり難しいんだろうな。
複数回に分けるとかやったらワンチャンあるのかもなと思うんだけど
多分それだけの人を確保できないと思うんだよね。
そうだね、確かに確かに。
っていう中で複数の領域とセキュリティっていうのを合わせて
ちょっと対象を広げようよっていうのを検討してる僕って。
リベンジありますかワンチャン。
ないっしょ、学生じゃないもんだって。
社外字幕。
あれだよ、共産すれば見学いけるからさ。
共産すればいいんじゃない?個人話も今あるでしょ。
そうなの?マジか。
共産しようかな。
昔落ちました。
クセセイさんの問題にわけわかんない回答を出して落ちたすぎる。
お願いします。
覚えてるわ、今の。
問題も覚えてるし、自分が超また外れな回答したのも今のに覚えてる。
個人会員がね、あるから貼っといてあげる。
ありがとうございます。
そうね、確かに確かに。
いくらの。
いや、決して誰かを下げたいわけではないけど、
セキュリティの得と、
でも会社のフェーズによるんですけど、
例えばうちみたいな、プロダクト作り始めてみたいな、
今うち70人くらいですけど、100人とか200人とか500人くらいまでなんだな、
多分そういう会社で求められるセキュリティ人材と、
いわゆる大企業とかエンプラみたいなのを求められるセキュリティ人材って結構違う気がしてて、
後者は領域特化でいいと思うんだけど、
前者はやっぱどうしても掛け合わせがないと価値を出しづらい部分があって、
そういう人ってすごい少ない気がするんですよね、僕から見た。
多々あると思ってて、
僕は勝手に一人目人材って呼んでるんだけど、
一人目をやれるっていうのはかなり特殊なスキルセットだと思っていて、
表現、言語化できないんだけど結構独特のキャリアだよなっていうふうに思っているのが一つと、
あとは加えてカルチャーフィットの問題があるから、
そもそもその人がその会社に合うのか、その会社の文化、働き方に合うのかっていうところに加えて、
その人が一人目としてやっていけるのかっていうところが合わさって、掛け合わせで見ないといけないので、
めちゃくちゃ大変だよなっていうふうに思うし。
確かにね。
世の中大きい会社より小さい会社の方が絶対多いわけで、
考えた時に僕が勝手に一人目人材って呼んでいる人材の方が求められてる数っていうのは絶対多いはずで、
じゃあ一人目人材ってどうやったら育つんですかみたいなのは僕はちょっとよくわかんなくて、
どっちかって言って、やむにやまれずセキュリティやり始めたみたいな人の方が近いんじゃないかなって後ろ方針。
セキュリティとソフトエンジニアリング
だからそのセキュリティ特化っていうのがそもそも前提としてない世界なんじゃないかって思うんだけれども。
でもなんかそうだね、やむにやまれずやったパターンがまさに僕だと思うんですけど、
逆もあっていい気もするんだけど、
スキルセットとか経験が特定領域に偏ってても関心が強いとか、
仕事ではやったことないけどキャッチアップしてますみたいな人とかでもいいと思うんですよ個人的には。
今言った一人目人材で最初から100点取る人って多分マジでそこまで絞っちゃうと日本でも数えるぐらいしかいないだろうから。
その意味では横軸に関心を持つっていう人がいればいいなと思うんだけど、
一方でなんか意外とそういう人多くはないよなって思う。
そうね、これってなんかそのわーって決めてる人の方が確かに多いイメージはあるかな。
なんかそれは言い悪いっていうか業界の特性なのかなという気はしてて、
そういう意味では積極的な話はわかんないですけど。
でも現実問題そのなんていうか、
例えばクライアントもバックエンドも両方やりますみたいなソフトウェアエンジニアってそんなにいないと思うんですよね。
全体の総数に対しては多分そんなにいないじゃないですか。
確かに割合が、母数が違うかもしれないですね。
セキュリティの方よりはいるけど母数に対してその人材の割合っていう観点で見ると確かに同じぐらいかもしれない。
で、じゃあソフトウェアエンジニアリング以外の領域にも染み出すような人っていうふうに考えるともっと少なくなると思っていて、
だからそれだけその1個の領域から染み出すっていうのは、
それだけで難しさがあるしそれだけで価値があることなんだろうなとは思うんだけれども。
まあ確かにね、いやー。
まあでもちょっと壁は厚い気がするなあ、どうなんだろう。
セキュリティなんでそんな壁厚いのかなあっていうのはちょっと思ってて。
だってさ、YAMにやまれずやってみてどうでした?
意外とできちゃったなっていう感想だと思うんだけど。
そうだね。
まあでも、一つ気にしてるのは広すぎる、広すぎて深すぎるっていうのはやっぱある気はするんだよなあと思うんですけど。
多分ですけどね。
やってみる前の見え方としてっていうのもあるし、
ちょっとやってみたときの見え方としてもなんていうか。
結論としてなんか、結論っていうか勝手に結論に思っちゃうけど、
多分やってみてこう思うんじゃないかなって勝手に思ってるのは、
今その立場にいてセキュリティしかわかりませんって人と話が合うと思いますかっていう。
何かしらその接点がないとさ、難しくないと思うんだけどね。
まあね、その接点が強い関心、興味でもいいんじゃないかというか、
仮説あるが話してないとわからない。
だからそれはなんかバックエンドとかも一緒な気がしてて、
うちとかにバックエンドしかやったことないけど、
でもうちってそのクライアントもウェブも書くことありますっていうところに、
まあやればやれると思うんでやりますって言って入ってくる人とかいるように、
なんか同じような立てつけで入ってくれても全然いいと思いつつ、
まあまあまあ、そうっすね、まあでもなあ、まあまあ、いや、
まあ難しいな。
まああと身も蓋もない話をすると、
今やってる何かにセキュリティを合わせて持つと、
あなたの市場価値は上がりますよっていうのは絶対あると思ってて。
それはね、本当にそうだと思ってて、
それはね、みんなにもうちょっと知ってもらってもいいかも。
お金稼ぎたいソフトエンジニアでマジでセキュリティやればいいなってね、
この2年間めっちゃ思うようになった。
QAとの親和性の話もさっきしたけどさ、
セキュリティもできます。
QAもできます。
多分めちゃくちゃ売れる。
売れると思う。
でもセキュリティはなんか、
需要と供給のアンバランス差が、
そのソフトエンジニアより顕著だから、
と思ってるが、まあどうだろう。
なんでそんなに壁があるのかが昔からよくわかんなくって、どうして?
まあ一つ話しながら1個思いついたのは、
ソフトエンジニアはスコープが広がりづらいんですよ。
広がりづらいっていうのは絞りやすいというか、
この開発チームにジョインして活躍してくださいってなった時に、
そのミッションって、
WebアプリケーションとAPIサーバー1個ずつ面倒見てて、
それを何とか運用したり新規開発するみたいな風になると、
結構課題が限定されやすいというか、
そこで使われてる技術スタックは、
じゃあREST APIですってなったら、
別にグラフィック経路のこと、
別に知ってた方がいいのはそうなんだけど、
でも知らなくてもできるし、
GRPCも知らなくていい。
GRPC知らなくていいってことは、
プロトアウトも知らなくていいし、
その原理も知らなくていいとか、
なんかそういう風に結構課題を限定して入りやすいんだけど、
セキュリティは多分一つは全体像がまずつかめないっていうところと、
全体像が見えてきた時に、
じゃあ何でしょうね、
僕の昔の感覚でいうと、
いろいろやらなきゃいけないことが見えてきたねみたいな、
じゃあ一旦Googleクラウドの権限管理にだけこの半年間集中しようっていうのができるかと言うと、
なんていうか、
優先付け方としてあるべきなのはそうじゃなくて、
Googleクラウドの権限も大事なんだが、
それよりもっと危ないものがないかっていうのを目を見張っていかなきゃいけないし、
っていうふうに考えていくと、
結構見なきゃいけない範囲が広いっていう部分になって、
割と難しさがあるのかなって思った。
でもGoogleクラウドの権限管理は多分、
ソフトウェア開発っていう一括りにしちゃうのはあんまり良くないと思うんだけど、
例えばバックエンドのサービスを書いてますっていうところからちょっと遠いと思っていて、
でも一方でSREをやってますっていうところからはかなり近いと思うんですよね。
近いところから染み出せばいいと思うんだよな。
全体像分かる人なんて多分ほとんどいないわけで、
セキュリティやってる人でも。
そうね、確かにね。
なかなか難しい部分があるのは分からなくはない。
僕もフロントエンドとか全然メンタルモデルが構築できなくて、
すごく苦手なんだけど。
永遠になんかチュートリアルを繰り返してるわけで、
全然なんも理解できないんだけど。
確かに。
一定そういう領域っていうか壁があるのは理解はできなくないんだけど。
近いな。壁の厚さの差はありそうだね。
全然セキュリティ開発そうかもね、今普通に思ったけど。
なんかでもそのさ、なんて言ってるんだろう。
フロントエンド開発分かんなくてもXSS分かるんですよ、ある程度はそこそこね。
まあまあそこそこ。
そこそこね。
なんかそんなもんじゃないと思うんだけどね。
まあそうね。
まあまあちょっと考えすぎなのかもしんない。
みんな考えすぎなのかもね。
うん。
うん。
まあでもそうね、どっかのタイミングの話に戻ると、
やってみて意外とできたなっていうのは確かに本当にあるから、
なんかその、いつか話したかもしんないけど、
あとは足場があればいいかなっていう気はしてるね、職種として。
うん。
やっぱ僕みたいな、じゃあキャリアを歩みたいですって、
わかんない、そのセキュリティ経験のないソフトエンジニアが思った時に、
そもそもそんなポジションがどんぐらいあるのかっていうと、
最近はなんかちょっと増えてきた気がしてるけど、
でもまだまだ多くないから、
まあそれは増えていくといいなって個人的には思ったりしますね。
まあでもどんな環境でもあるとは思うんだけどね。
まあそこは。
例えばだけど、プロダクトセキュリティやってる側の立場で考えた時に、
そのソフトエンジニアやってます、
同じ会社でソフトエンジニアやってますっていう人のサポートがめちゃくちゃ欲しいし、
ありがたいわけですよ。
だからなんかセキュリティチームがすでにあるよっていうところであったとしても、
セキュリティ環境の重要性
そういうなんていうか環境っていうのは多分得られると思うし、
何もないんだったらなおさら多分、
まあ会社によるかもしれないけど、
なんか比較的得やすいっていう面は、
まああったりなかったりすると思うけど。
僕的には会社によるかなって気がしますね。
会社がまずセキュリティに投資してなかったら結構厳しいんじゃないかなって個人的にちょっと思って。
そのなんか趣味の感じでね。
業務としてなんかそのやろうとするから大変なんじゃないかな。
まあでも業務…
ユニットテストにセキュリティテストっぽいなんかテストケースが1個入ってるとかでも別にいいんじゃないかなと思う。
まあまあまあ。
まあそうね。
僕の認識的にはそこからもう一歩踏み込みたい時に、
なんかそういう環境に飛び込めるかみたいな感じの感覚なのかな。
そこは…
まあ会社によるかもしれないですね、確かに。
なんかバックエンドからフロントエンドにジョブチェンジしたりとかはできる会社いっぱいあると思うんですよ。
なぜならどっちのチームもだいたいあるから。
そのウェブアプリとか作ってるの。
だからセキュリティチームがないとかセキュリティをその領域として組織内のチームとして用意してないとかだと、
まあ限られちゃうんじゃないかなとかは思うって感じですね。
わかんないです。
別にいいんじゃない?なんかバックエンドエンジニア兼脆弱性絶対許さないマンとかでも別にいいんじゃないかなと思って。
まあね、いやでも、まあそうですね。
いやてかなんかそういう染み出しがないと、そのもう無理なんですよ。
だって人いないじゃん。
まあ僕ら的にはそうですよね。
まあでも、いやわかんないですけど、それが何の評価もされないとかすごいですねぐらいで終わったらさ、
まあじゃあ転職すればいいんじゃないですか。
僕的にはぶっちゃけ転職した方がいいと思う、そういうパターン。
まあまあ本当にそれが評価される環境、そういうこともやれる環境を目指すんだったら転職っていうのも一つの選択肢になるかもしれないし。
場所を作ってもまあいい場の道だけであるかもしれないし。
まあちょっとなんとも言えない、まあそれはその辺も人それぞれですね。
CTOとの関係性
まあ確かにそうですね。
はい。
これをさらにいつもありがとうございます。
ありがとうございます。
こんなに話ができましたおかげさまで。
第100回ぐらいでゲストに呼ばせてもらいます。
まあいいや。
呼び手。
うちの子がファンなんですって。
僕もファンですけどって言って、うちの子がすごい情熱を持ってて。
じゃあ次はまた別の推しですが、CTOとは一体何だったのか、バージョン2024っていう、まあ俺たちの総太郎さんの記事でございます。
はい。
まあ要約するのもちょっと恐れ多いんですが、
CTOっていうのは技術的なチャレンジと事業としての成功の両方を引き出す立場だよっていう話とか、なんかCTOみたいな役割は技術的な側面から経営を統制するっていうものもあるのかなって最近は思ってますっていう話とかがピンとくるというか。
具体的にはもっか結果を出しつつ中長期的にプロダクターが正しく進化できるようなギリギリのラインを見極めると、
あとはしかしそのラインを超えられるように、超えられぬように経営の意思決定を技術面から統制するっていうこの2つを挙げてて、
なるほどなと。
まあなんかあらゆるCXOがそうなのかもなとはちょっと思ったんだけど、CISOも特に同じことが言えるんじゃないかなとはなんとなく思った。
誰かCISOとは一体何だったのかを書いてくんねえかな。
確かに書いてほしいね。
僕個人的な考えとしてはCXOってもう会社によって千差万別になると思っていて、課題も変わるし事業が変わればとか組織系が変わればとか、
CTOだったらもはや技術スタッフが変わればとかもあると思うんですけど、その中ですごい良い最大公約数の抜き出し方だなっていう気はしたのと、
統制って考え方は全くもってその通りだなって思いますね、個人的には。
僕よく綱引きって表現使うんですけど、健全な綱引きとか健全なプロレスをしてほしいなって思っていて、
経営に対してもそう思うし、自分がセキュリティチームにいる中でその開発チームとかプロダクトチームと健全な綱引きをしたいなってすごい常々思ってるんですけど、
なんていうか、なんで綱引きかっていうと、どっちもやりたいことっていうか、どちらも、ここのラインは譲れないっていうラインがそれぞれある中で、
じゃあもうこのラインで、ここに書いてあることもまんまなんですけど、ギリギリのラインを見極めましょうっていう話で、
ただ一方でパワーバランスとかがアンバランスだと綱引きにならないわけじゃないですか、片方がずるずるって引きずって、
超えられたくないラインの遥か先で意思決定がされてしまうとか、それが状態化するとかっていうのが全然起きるわけで、
パワーバランスって観点も大事だし、お互い相互を理解し合うっていう部分も大事だし、
綱引きの重要性
僕はみんなと健全な綱引きがしたいなって思いながら、でも健全な綱引きするのって大変だなと思いながら生きてますって感じ。
何が言いたかったのかよくわからなかったけど。
CISの目線の話は聞きたいですね。
誰かなんかゲストで呼びましょうよ、CISを。
なんかこういうパブリックの中で話してくれるもんなのかな、話せるか別に。
なんかコネでこの人はっていうCISの方いらっしゃるんですかね。
カニーさん。
カニーさんを話したいです。
誰も聞いてないんだよ、誰も聞いてないんだよって。
こんなこんなポッドキャスト誰も聞いてないんだよって。
読んだらさ、タイトルにも入れずに。
いやでも失礼かな、それはそれで。
ちゃんと宣伝したほうがいいのかな。
どうせならなんか客寄せをしてほしいけど。
そんな下心に、
まあね、そうね。
その回だけさ、バーンって伸びてさ、
その翌週さ、また10人ぐらいだったらさ、
なんか、まあ別にいいですけどね、いいですけど、
いやなんかすごい落ち込んじゃいそうかなって思って。
落ち込まないですけど。
それの極みのなんか、
あの、YouTubeの動画があるから後で送ってあげる。
めっちゃ楽しみだなって、楽しみにしておきます。
その動画だけめっちゃ再生回数多い。
別になんかゲストが出てるとかではないんだけど、
その動画だけなぜか再生回数が多い。
そういうYouTubeチャンネルあるよね、たぶん。
うん。
嫌いじゃないな、それ。
実際、ごめん言っちゃうんだけど、
他の動画はそんなに刺さんない。
世知辛いなと思って。
まあまあまあ。
いやでも、僕たちは総太郎Kさんって感じっすね、ほんとにね。
ありがとうございました。
ありがとうございます。
あんま話したことないけど。
マジ、なんか一緒に、まあいいや。
ん?一緒に?
なんでもない、なんでもない。
いや、入社したらいなくなってたから。
別に総太郎さんが悪いわけではないんだけど。
そうだね、そうだね。
まあまあまあ。
いやー、なんか働きたい人がいたら、
もう速攻でみんなジョインしたらいいんじゃないですか、新年。
最速ジョインでいなくなってたからなー。
まあ、最初のパターンはちょっとしょうがなかったね。
うん。
まあまあまあ。
まあどっかでまた会うよ、わかんないけど。
マジ狭いから。
うん。
今日はこんな感じですか。
これがそうですね、最後の記事ですね。
はい。
オフトピーが最後に2つ並びましたが。
うん。
いやー、来週から楽しみですね。
多分厳選しないとダメだろうな、もしかしたら。
いやー、やばいよね。
だってさ、今日まだ火曜日なんだけど。
火曜の夜の時点で、だって今いくつあんのこれ。
2、3、4、5、6、7。
いや単純計算で7かける。
11個ある。
7かけるウォッチしてるアドベンタカレンダー。
あの、アイアナウンス関係関連のアドベンタカレンダー何個か。
これでピックしてるんですけど。
10個ぐらいあるでしょ。
年末にさ、良かったアドベンタカレンダーみたいな回を1回設ける。
あー、なるほどね、確かに。拾えなかったもん。
あんまりなんか、ガツガツ。
いや多分なんだけど、三谷さんのさアドベンタカレンダーとか全部繋がんないとなんか。
あー、確かにね。
紹介も何もないような気がしていて。
30、25連続連載系ね。
うん。
うん、確かにね、それはいいかも。
まあちょっといい感じに初めてなんでやりましょう。
あれ、今年ってさ。
うん。
ちょっと待ってね。やべ、忘れちゃった、出てこねえ。
えーと、えーと、ジャックさん。
ジャックさんってなんか、やんなそう記事出てねえからやってねえなって思ってた。
うん。
サードパーティークッキーアドベンタカレンダーがさ、めっちゃ良かったから。
まあ、ホットだったからね、あの時は。
うんうんうん。
っていうのがあると思うけど。
まあ、初期のダイアログとポップオーバーもだいぶ濃かったけどね。
うんうんうん。
まあ、ちょっと粛々とやんでいきましょう。
はい。
ほい。
じゃあ、また来週ですか。もう12月ですけど。
そうですね。
いやー、年末ですね。
年末やるんすか、この収録は、ちなみに。
じゃあ、有料コンテンツ時間で相談しましょう。
しましょう。
どこで課金すんの。
課金窓口が誰もいないからね。
あって見つけてください。
まあ、課金したかったらこっそりDMください。
ぺいぺいのQRコードをくるね。
うんうん、ぺいぺいのQRコードをくるね。
特殊詐欺みがすごいな、なんか。
新しいポッドキャスト詐欺み。
存在しない音源に対して請求かける。
今回は有料コンテンツありませんでした。
いかがでしたか。
最悪。
やばすぎる。
訴えられちゃう。
じゃあ、そんな感じで、また来週もお楽しみにしててください。
みなさんこん…
おやすみなさい。
おやすみなさい。
はい。
おやすみなさい。
