#73 マッチポンプしながらセキュリティ専任の必要性について語った回

00:00

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

えー、こんばんは。73回。

来たねー、73回。

毎回、毎回その感じだよね。

いやー。いいの?

もういいよって感じだと思うけど、聞いてる人は。

でもなんかしみじみしちゃう。その、この数の。

え、73だよ、だって。

70、いや、なんかわかんないけど、

なんか普段聞いてるポッドキャストでその、

とかさ、いろんなテック系のポッドキャストで、

なんか、73って結構結構だと思うんだよなー、多分。

弊社のポッドキャストとかどんぐらいあるんだろう?

さすがにキャリアが違うか。

いやー。属性フェイムとかでも140でしょ?

うん。半分いったね。

多分これ歴史6年ぐらいだと思うけど、6、7年。

まあ、われわれ毎週やってますからね。

そうだね、まあそれは間違いなくでかいね。

そうなんですよ。

いやー、そんな感じでまあ今日もやっていきますか。

1月の年明けと違って、今日もね、ホクホク記事が多めなんで。

そうなんだよね。ちょっともうちょっと慣らしてほしかったんだけどね。

こっちの耳にもなってほしいよね。

まあまあならぬ世の中だなーって思いました。

まあ、記事書いてる側からしたらお前らが慣らせよって感じだろうけど。

そりゃね、そりゃそう。

貯金して。いやでも鮮度が大事だからね。

まあ、読んでいきましょうか。

はい。

はい、あ、で読む前にですね。

まあ、いつも通りお便りGoogleフォームでお待ちしてます。

収録前にちょっと話してたけど、

なんかしれっと書き足しておこう。

ハッシュタグでもいいし、Googleフォームもいつでもお待ちしております。

はい。

じゃあ1個目お願いしようかな。

お、了解でございます。

AWSからGoogleクラウドへのフェデレーション設計

AWSマルチアカウント環境からのGoogleクラウドフェデレーション設計。

AI時代に合わせた社内認証基盤作り。

LAXエンジニアブログの記事ですね。

ちょっと細かくは実は読み込んでないんだけど、

話としては、なんかAWSを、

AXってAWSベースだもんね、基本的にね。

文脈的にもそうだと思うな。

AWSをベースにして、Googleクラウドに対して、

いろんな操作をしたいよっていう話がまずあって、

二重管理はしんどいから、

AWSのIAMの管理なのかな、たぶんね。

そうだね、そっちはがっつりやれてるんだろうね。

きっとね。

で、それをベースにしてワークロードアイデンティティーフェデレーションで、

Googleクラウド側に認証をかけて操作をしましょうっていう話かな、たぶんね。

概要としてはそんな話ですね。

実績的には結構細かく設計とかここはこうしてとか、

いろいろつまづきポイントみたいなところかなり細かく書いてくれてるし、

それこそAWSがGoogleクラウド側の書き方だよね。

AWSからこういう値がくるからこういうふうに書けばこういうのを通せるとか、

パターンマッチで通すか絶対完全位置で通すかみたいなやつとかも書いてくれてて、

ほーって思いながら、

この辺は僕はAWSの解像度が低いんで正直ピンとこないんだけど、

知ってる人からしたらなるほどねってなるような知見なのかなっていう感じですね。

これはなんか面白かったですね。

そうですね。結構この、なんかたぶんこの、

なんて言ってるんだろうな。

テラフォームで書いてしまうとたぶんあっさりした内容なんだろうなと思うんだけど、

割と考えること多いなとは思いながら読みました、僕も。

結構ね、こう決めちゃえば作りはシンプルだけど。

いやーこれなんかうち弊社とかで考えるとさ、やるとしたら逆になるじゃん。

うちはGoogleクラウドメインで、

AWSは超一部限定的に使ってるみたいな感じで、

今回のLinuxさんのニーズと同じ道を辿ることはたぶんないと思うんだけど、

今回ってGoogleワークスペース使ってて、そこにアクセスするためにGoogleクラウドにアクセスしたくてって話だから、

そこはまあ違うんだけど、

でもなんかその、じゃあAWSもがっつり活用しますって言われたときに、

AWSでもGoogleクラウド側で築き上げてきたそのテラフォーム基盤と、

その権限管理とそこに対するいろんな統制を、

一からSREチームとかに死ぬ気で勉強してもらって作り直すみたいなことを考えると、

割とこのアプローチってかなりヘルシーだし、

抑える部分は抑えられてるし、

賢いなーってすごいシンプルに思ったな。

かなり合理的。

そうですね。

あとはそうだね、

Googleクラウドのワークロードアイデンティティ連携のベストプラクティスみたいなドキュメントとか、

僕は恥ずかしながら読めてた。

これそう、俺も知らなかったんだよね。

そのまさにそれが言及されてるところなんだけど、

そのワークロードアイデンティティフェデレーション専用のプロジェクトを作るっていうのが、

なんかベストプラクティスとされていてっていう風に言及されていて、

知らなかったなーと思って。

これ結構専用プロジェクト作って集約するのいいアイデアだなーって思いながら読んでたんですけど、

どうですか?

なんかうちの、うちで集めた場合は、

なんかリターンなんだろうなっていうの結構シンプルに思ったんだけど、

でもなんか、ちょっとノーションの方に書いたんだけど、

GitHubの話になっちゃうんだけど、

プロバイダーのIDとかさ、ネームとかさ、

IDだかネームだかなんか長いしめんどくさいじゃん。

しかもあれ、プロジェクトIDじゃなくてプロジェクトナンバーじゃなかったっけ?

頭の方に入ってるやつ。そうだよね。

結構長いしめんどくさいなと思ってて、

ここにつなげばうちのワークロイドアイデンティティフェデレーションは使えますよっていうのを1個共通化しておくと楽かなーとは思ったな。

それぐらいだな、でもしいといえば。

でもこれ地味にね、書いてるの見てなるほどなって思ったけどデカいと思う。

そうだよね。

オーガニゼーションのアクションズバリアブルに突っ込んでおけるから、

例えばうちの場合だと、かなり中の話になっちゃうけど、

テラフォームの設計ってプロジェクトごとにステートが分離されていてっていう設計になってるからさ、

ワークロイドアイデンティティ連携を1つのプロジェクトで管理するっていうのと、

そっからプリンシパルの設定を各プロジェクト側でやっていかなきゃいけないから、

ワークロイドアイデンティティ連携のIDとかプロジェクトを他のプロジェクトでハードコードして設計して書いていくみたいなのは、

超細かいけどオートコンプリート効かなくてだるいなとか、

そんぐらいって感じ、敷いてあげるんだよね。

でもこのGitHubのリターンは結構欲しいなって思った。

地味にいいよね。

すごく地味なんだけどね。

運用保守の観点だと結構慣れれば書けるんだけど慣れないと癖があるというか、

ワークロイドアイデンティティ連携の構文とかそういうのがあるって。

で、ドキュメントもあんま親切じゃないし、

だった時に僕が実際に仕事よくやるのは、こういう設計どうやるんだっけなみたいな感じで、

あの場所やってたなみたいな時に、さっき言ったプロジェクトをプロジェクトホリに行って、

これこれっていうのを探しに行って、コピペして修正してみたいなことをしたりしてるから、

その辺が一つのプロジェクトになってると多分、

真似しやすい行動が一箇所に集まるっていうのもあるし、

そもそも一箇所に集まっちゃえば、

そこに今だったらAI向けのドキュメント一緒にパッと書いて、

もうこれ通りに機械的にやってっていうんで、

多分9割は標準化できると思うから、

それは実装勝ちって言ってもできると思うんだけど、

でもやりやすいよなっていうのも普通に思ったな。

明日SREチームにどうすかっていうか、

今あるものをわざわざ寄せるメリットがどれくらいあるかちょっと分かんない。

10Xの場合は結構特殊事情だなって思っていて、

いざ集約しましょうってなった時に、

ちょっとなんかうんってなっちゃうところは若干あるな。

そうだね。

でもこのプラクティス自体の意義は確かに。

そうだね。

意外とクラウド系のちゃんとベストプラクティスから、

読んでから手を動かすみたいなのは癖つけなきゃなって感じがする。

探せばあるんだよね、ちゃんとね。

探せばある。

差し迫ってるとどうしても後で追っかけやすいというか、

結構なんかしかも楽しいとこじゃん、

とりあえず動かそうみたいなさ。

そうだね。

一つ文句言うなら、

Googleクラウドに関しては突然によっと生えたりとか、

前なかったやつがあったりとかもするから、

もしかしたらギリ僕が触り始めたときになかったという言い訳は、

でも成り立たないんだろうな。

このページチラッと見たことあるんだよ、たぶん。

ちゃんと全然メイトしてないだけで。

残念でした。

困ったときに見たはず。

お疲れ様でした。

残念。

惜しいね。

まあまあでも。

しょうがないね。

とても良きだったな。

はい。

ありがとうございます。

とても良かったです。

とても良かった。

次。

PCI DSS準拠とSREの役割

クレジットカード決済基盤を支えるSRE。

厳格な監査とSRE運用の両立。

SRE会議2026のスマートバンクさんの水口さんという方の発表スライドでございます。

紹介しといて非常に申し訳ないんだけど、

スライド自体は今日紹介するつもりは実はなくて、

概要で言うとPCI DSSの準拠対応をSREがやりましたよっていう話で、

厳しさがこうでしたよみたいな話とか、

役割と課題がこうでみたいな話とかをしてて、

なんで持ってきたかというと、

SREの役割っていうところに対して、

なんでPCI DSS対応をSREがやるのっていうところに対しての回答が結構いいなと思って、

問いとしてセキュリティチームとか専門部署が対応すべきじゃないのっていう問いに対して、

人数が少ないフィンテックスタートアップだったからSREがやるんですよっていうのが23、24ページくらいに書いてあって、

この回答が割と全てではあるんだけれども、

何かの多分引用、SREコンの何かの発表の引用で、

セキュリティとSREは失敗を減らすのではなく、成功をより多くすることで達成されるみたいなことを言っている人がいるらしくて、

感染に引っかかれないようにするのではなく、

いい設計、いい運用を日常的に積み上げるっていうのを意識して、

その一環としてPCI DSS対応をやってるよっていう話なのかなと理解したんですが、

実際PCI DSSの文書上も、

BAUプロセスが異常を検知し、アラートと報告を行い、責任者が適時に対処できるようにすることが重要であるって書いてあって、

SREが日常的にやってることそのものではっていうふうに書いてくれてるんだけど、

そもそも別に親和性があるよっていう話ですね。

BAUって何だっけ、ビジネスアズユージュアルか。

いつものビジネス。

多分違うのかな。

でも合ってるんじゃないかな、ビジネスアズユージュアルっていうフレーズがどっかで見た気がするな。

通常、そうだね、合ってますね。

BAU化しましょうっていう話らしいですよと。

で、SREはPCI DSS準拠を29ページかな、29ページで、

PCI DSSは安全な公開のための公開日誌の書き方と点検項目のガイドラインになるもの。

比喩の話なんだけど。

SREはガイドラインをもとに自動操縦システムを構築し、

景気の異常を即座に修復するエンジニアリングをするよと。

セキュリティに関する討論

なのでSREはPCI DSS準拠っていうのを効率的に実現する手段として捉えるよっていう。

ちょっと日本語が若干よくわかんないんだけど、

まあっていうことが書いてあって、

長くなっちゃうんでこの辺にするんだけど、

結構いいなって思いながら読んでましたという話で、

興味ある方はぜひ読んでみてくださいっていう話なんですが、

わりとオフトピオリの話として今回持ってきてて、

セキュリティチームとか専門部署が対応すべきじゃないのかみたいな問いって、

よくある問いではあるかなと思ってて、

SREに対してもよく言われることなのかなと思うんだけど、

特にこのポッドキャストではセキュリティの話にフォーカスしたくて、

Web系スタートアップにおける専任のセキュリティ担当者の要不要の議論とか、

あとはWeb系スタートアップにおけるCISOっていう立場、

セキュリティをハイレイヤーでリードするような立場の人の要不要の議論みたいなのが結構あるような気がしていて、

こういう感じでSREとかプラットフォームチーム的なところがセキュリティを担うよっていう組織のところも当然にあるし、

CISOって立場を置いてなくてCTOが当然にその責務を負うみたいなやり方をしてる会社も多分あるし、

そういう主張をする人も別にその立場じゃなくてもそういう主張をする人も見受けられたりするよなと思っていて、

すごいオープンクエスチョンになっちゃうけどどう思いますか?

必要性と実装の観点

個人的には専任の要不要で言うと、多分CISOも回答一緒になると思うけど、

僕が今んとこ出してる結論としては、そもそもそこの観点はあんま重要じゃなくて、

どっちかっていうと重要なのは、まず会社があって事業があって、

その事業に求められてるセキュリティレベルとかセキュリティ機能があるはずで、

それを遂行する機能が会社として実装されてるかどうかっていうのが一番大事な気がしてる。

なんかフワッとした言葉言っちゃった。

もう一回いいっすか?すみません。

ごめんね。ごめん言いながら若いザカオ言っちゃったと思ったんだけど。

頑張ってうまく言語化してる。

頑張って応援してる。

何か事業やりますってなるときに、事業を作るためにプロダクトが必要で、

そのプロダクトにはこの機能がないとダメっていうのは分かりやすいものだと思うんだけど、

そういう機能要件じゃなくて非機能要件で求められることもいっぱいあるわけじゃないですか。

例えば何かレスポンスタイムが5分かかるようなものじゃ使い物にならないから、

それは実質求められてる非機能要件だよねみたいな。

それは品質の部分ですけど、

そういうものと同じようにセキュリティも一要素としてあるはずと思っていて、

ってなったときにWeb系スタートアップであっても、

どんな規模の会社であってもセキュリティっていうセクションは存在すると思うし、

それが必要か必要じゃないかで言うと僕は必要だと思っている。

っていうのが僕はまず前提として思っていて、

ただその必要性の有無とかレベル感はもう事業と会社のフェーズによるとしか言えないから、

領域としては確かに存在するんだけど、

もうぶっちゃけこのタイミングではノーガードでいいですっていうこともあれば、

例えばめっちゃ最初のフェーズであっても事業性質上このラインまでは守んなきゃいけないみたいな、

そこはもう本当正解もないし変数次第でめっちゃ変わるラインかなと思うんだけど、

前提そこだと思っていて、

その前提に立った上でさっきの問いが来ると思ってて、

じゃあそれを今のタイミングで僕らはセキュリティっていうセクションにおいて、

こういうところまで行かなきゃいけないってなったときに、

それをどう達成しますかってハウの部分のやり方の一つに、

じゃあ専任のチームを作るのか作らないのか、

経営レイヤーに近いところで干渉役員なのか、

支援者を立てるのか立てないのかっていう問いが来ると思ってるっていう感覚かな。

だから要不要かで言うと、

今言った前段の前提次第で変わると思うし、

会社によって何か正解が変わるんじゃないかっていうのが、

今のところの僕の結論っていう感じかな。

実務におけるアプローチ

なるほど。

だからこの、何だろうな、

ただ、まあそうだね、

その答えはあんま変わんないけど、

でも一方で、

ちょっと理想論的な部分はあると思っていて、

ニヤトリ卵じゃないけど、

セキュリティセクションを無理矢理こじ開けないと、

今言った前段の整理もできねえよっていうパターンも

全然往々にして今の時代だとあると思ってて、

そうだね。

それはなぜかというと、

どっかの会で、

多分昔話したような話したような気もするけど、

セキュリティに限らずだけど、

会社を作るのって免許制じゃないくて、

プロダクト作るのに免許いらないってなった時に、

責任知識がなくてもできるし、

品質の知識がなくてもできるし、

何なら開発の知識がなくてもできる。

なんで経営者とか会社を作る人とかチームを立ち上げる人は、

自分に足りない手足を集めてくると思うんだけど、

その手足を集めてくるってなった時の優先、

集めてくるってなった時に、

一番最初に集めるのってやっぱ機能要件を満たすもの、

価値を生み出す人たちを集めていくっていうのが優先だから

どうしても高くなるし、

それはほぼほぼのステーションでは正解だと思うんだけど、

ただ一方で集めてきた人たちが、

例えばソフトエンジニア集めてきて、

その人たちは機能も作れるし、

でもこれ機能要件じゃないですけど、

実はセキュリティセクションここに明確なセクションがあって、

僕らの場合はここまで行かなきゃいけないから、

どうにかしようよってなったら、

会社として初めてそういう領域があって、

何かをしなきゃいけないなって認識ができるけど、

その認識に至らないっていうケースがめちゃくちゃある気はしていて、

そこを漏らさず領域として認識するんだったら、

チームを先に作っちゃうっていう手も、

少々乱暴な考え方だけではなくはないかなと思うって感じかな、

思うけど、

まあでもな、

だからニヤと言ったままなんだよね、

じゃあチーム作るってなっても、

いやでもそこにセクションないじゃんって言われたらおしまいだから、

やっぱなんか、

だからそこは本当会社に寄りきりだよね、

ボトムアップで会社なくていいと思ってたけど、

ボトムアップで突き上げて、

説明、責任果たして、

チームなのかセクション立ち上げるっていうパターンもあるだろうし、

まあ双方向に対話しつつやるってパターンもあるし、

だろうと思うし、

まあやり方がわかんないって会社ももしかしてあるかもしんないよね、

なんかやんなきゃいけないのかって言うけど、

なんかどのレベル突き詰めればいいかぶっちゃけわかんないし、

まあもしかしたらコンサルに頼むとかそういうのもあると思うし、

現実はなんか、

僕が言ったり、

形にきれいに収まるってことはないんだろうなっていうのは思うって感じかな、

そうね、

ユメミさんはどうですか?

うーん、

なんか異論、話聞いて別に異論はないなって思ったんだけど、

なんか、うーん、

異論はないなと思いつつ、

なんか、うーん、

実際それで回るのかなとはなんか普通に思ったし、

なんか、その、

なんて言ったらいいんだろうな、

僕らはどっちかというとその、

セキュリティの1000人の人たちが何人かいるよっていう体制でやってるんだけれども、

なんか、やること無限にあるじゃん、

その、

あるね、

ね、その、

気づかない気づけないみたいなのはまあ確かにあるんだろうなとは思うんだけど、

なんか、

割と今の世の中その、

それが許されるかというと結構際どい際してて、

確かにね、

うーん、

いや、言いたいことわかったわ、

分かった、

なんか、そうだね、

うん、

別になんかどんな、

誰かが何かと献認してても全然いいとは思うんだけど、

なんかその、

なんて言ったらいいんだろうな、

なんか、

バランス本当に取れんのっていうのは普通に思うし、

なんか、

まあ一方でその、

セキュリティのその1000人の人たちだけがセキュリティをやってるっていうのもおかしなことになるから、

なんか、

うん、

またそれはそれで難しいところなんだけど、

なんかその、

どうしてもみんなでやんなきゃいけないっていうのは大前提としてあるから、

なんか、

難しいなあと思うけど、

例えばSREとかがそのセキュリティもやってますっていう状況で、

なんか、

その、

さあ、

名前はSREで、

なんか、

別にいいと思うんだけどSREがセキュリティもやりますって全然いいと思うんだけど、

なんか、

その名前はSREでもセキュリティもまあ責務に入ってますよってなったときに、

その、

なんか、

セキュリティに裂かれるリソースって果たしてどれだけなのかなあとか、

なんか考えちゃうなあ、

なんか、

うん、

いやあ、

確かにね、

いや、

それで言うと、

やっぱチームあったほうがいいなって気持ちになっちゃったね、

なんかSREにおけるセキュリティみたいなのもあると思っていて、

その、

うん、

PCI DSSっていうのを軸にして、

その、

あ、これってSREが貢献できる領域じゃんっていう、

貢献するべき領域じゃんっていうのを見出してやってるっていうのはめちゃくちゃいいなと思ったし、

なんか、

うん、

それはあるべき姿だなあとは思うんだけど、

なんか、

うん、

でもなんか、

うーん、

それをその組織として、

それ、

その、

それができてる状態を作っていこうっていう、

そこに対して責務を負うのって多分、

なんかもっと別の何かなんじゃないかなって思ってしまうっていう話なのかなと。

確かにね、

いやあ、

それで言うと、

まあ、

ワンバンクさんがどうかは全然、

スマートバンクさんがどうかは全然わかんないけど、

あの、

あったほうがいいって言っちゃったけど、

まあ、

時間軸で見たときには、

その、

タイミングを逃さないっていうのが現実的には大事なのかなって気がしたな、

なんか、

うーん、

タイミングっていうのはその、

たぶん、

創業時点で、

初っ端から開発チームの立ち上げと同時にセキュリティチームが必要ってパターンは、

まあ、

よほどじゃないとたぶんない気はしていて、

そうだね。

うん。

それこそFintechのスタートアップ出し上げますみたいな、

なんか、

タイミングがあったら私と話が変わってくるかもしれないけどね。

うん。

だったときに、

まあその、

あの、

でもセキュリティセクション認識できた場合は、

それをじゃあみんなでカバーしていこうとか、

まあ、

SREがこんな形でカバーする、

今回紹介した記事みたいにカバーするっていうのもあると思うし、

うん。

あの、

開発チームが自分たちで、

あの、

自治していくっていうのも全然、

あの、

一定規模、

一定スコープまで、

セキュリティ専任の必要性

もう僕ら成り立ってほしいなと思う。

こう個人的に願っているっていうのもあるけど、

うんうん。

思うし、

ただ、

その、

今ヤガシが言った、

じゃあその全体こうやって、

ここはここで、

カバーし合ってこうよみたいな指針を立てるっていうのは確かに必要で、

そこは、

あの、

まあ、

異論、

異論は認めるが、

なんか、

うん。

その、

技術、

技術セクションの、

まあ、

最高責任者がやってほしいかなって気はするな。

うんうんうん。

あの、

やってほしいっていうのは、

その、

めっちゃセキュリティの専門性を持って、

その、

あの、

めちゃくちゃ精度の高いセキュリティ施策を考えてほしいとかじゃなくて、

まあ、

そのセキュリティもワンノブ全部だから、

まあ、

セキュリティもそうだし、

プロダクト作りもそうだし、

まあ、

SRE領域だって、

SREチームだって最初からない会社の方がずっと多いと思うから、

うん。

どういう意思決定をするのかとかっていう、

まあ、

やっぱその、

技術的な意思決定になると思うし、

あそこで、

その、

えっと、

セキュリティ一番ないけど、

技術分野の最高責任者が、

まあ、

ある程度の旗振りをする。

まあ、

いろんなリス、

えっと、

できてない、

できることできないことを認識した上で旗振りするっていうフェーズがあって、

で、

その次に、

まあじゃあ、

チームが必要だよねっていうのが、

これはもうなんか多分セキュリティに限らず、

もうSREとかもそうだし、

旧、

まあ品質はもうちょっと早い気がするけど、

うん。

あの、

まあまあそういういろんなセクション、

で、

その、

もう1000人立ち上げてそのバランス取っていこうみたいな、

なんか、

レバーを引いていくのも、

まあ、

上回収によるけど、

まあ最終的には、

締め切りに間に合わせる責任は、

まあ、

そのCTO的なポジションの人がもしかしたら持ってんのかなって、

ふんわり思ったりはするな、

企業の成長とセキュリティの課題

まあCTOというよりか厳密には会社なのかなって気はするけど、

うーん、

厳密、

まあそう、

厳密、

厳密には会社、

それで言うとなんかもっとその、

そもそもなんか、

その、

想定CTO像の話とかもなんか入ってきちゃうなって思いながら、

ちょっとこれ、

なんか持ち込むときに考えてたんだけど、

そうだねー。

うん。

いやでもね、

CTOも全員スーパーマンじゃないし、

そのいろんなCTOのパターンがあるからね、

そうそうそうそう。

だからなんか結構、

いや、

むずいんだよな、

なんか会社に、

逃げ、

逃げの発言だけど、

会社によるんだよなー、

まあ結構、

うん。

うん、

そうですね。

あとは、

会社にもよるし、

あの、

まあもうその、

立ち上げもやったことない、

なんか、

一回のソフトエンジニアがマジ何言ってんだって思われると思うけど、

その、

そのCTOチョイスは大事だよねっていう話も、

なんかその、

会社を立ち上げる目線としてはあると思うなー、

なんか、

C、

事業主でできる、

はい、

そうっすか、

いやでも、

すげえ、

CTOチョイスってなんかすごい、

すごい、

なんか、

あの、

語録感があるけど、

なんか、

なんだろうなー、

その、

いやー難しいなー、

でも、

うーん、

じゃあなんかセキュリティ全くわからんCTOがダメな方言われたら、

必ず、

絶対にそうではないし、

なんか、

うーん、

まあでも、

なんか、

個人的にはその、

この、

この立場になって知ってしまった以上は、

うーん、

なんか、

セキュリティの難しさってさ、

あの、

その、

セキュリティを求めてくるのはさ、

自分、

なんか内在的なものではなくてさ、

もうその環境がもう求めてくるじゃん、

なんか、

そうだね、

うーん、

その、

別にいくら言い訳してもいいんだけど、

その、

知らなかったとか、

うーん、

できなかったとか、

お金がなかったとか、

いくら言い訳してもいいんだけど、

でもなんかその、

ど、

どう考えてもその、

それで攻撃したら手を止めないし、

そうだね、

あの、

損するのも自分たちっていう、

なんかすごく不合理な、

うーん、

あの、

領域だと思ってて、

うーん、

だからなんか、

厳しい、

厳しい気はするけど、

でもなんか知ってしまった以上は、

その、

うーん、

なんか、

いろいろ厳しいけど、

厳しい環境、

厳しいリソースに晒されがちなベンチャー、

理想的な組織体制の構築

界隈であってもなんかその条件は、

変わんないというか、

変えられない以上は多分、

望まなきゃいけないんだろうなと、

もし僕が仮に、

次に会社をどんな立場で、

あれ、

立ち上げるってなったら、

うん、

これはなんか同僚の、

あの、

沙田さんとも一回話したことあるけど、

うん、

なんか、

次その3人目、

4人目社員になるなら、

もう絶対最初からセキュリティやるっていう、

ははは、

話とか、

そうだよねー、

それはなんか、

セキュリティも立ち上げるって意味じゃなくて、

うーん、

その、

な、

やっぱさ、

その手戻りが、

手戻りが発生するようなものとかをもう、

わかるわかる、

先にして潰すとか、

その、

同じようなこと、

わかるわかる、

めっちゃわかる、

同じようなことを実は思ってて、

その、

うん、

なんか、

こう、

まあ、

ね、

密かな、

密かな野望と言ってて、

なんかあんまりもうなんか、

人生設計として、

自分の中で、

うん、

もうそれがそんなに重要じゃなくなってきちゃったんだけど、

なんか、

うん、

こう、

例えば3人目、

スタートアップの3人目として入りますみたいな、

ソフトエンジニアとして入りますみたいな時に、

なんか、

ソフトエンジニアとして働けたらいいなって思ってた時期があって、

いやー、

うんうん、

そう、

うん、

ってなった時になんかじゃあ、

強くてニューゲームができるのかどうなのかっていうのは、

なんかその、

1個、

こう、

なんていうか、

問いかけとして自分の中にずっと残ってるものとして、

あるな、

うん、

なんか、

うん、

いやー、

あるねー、

めっちゃやりたいなー、

いろんなものを見てきて、

いろんなものを踏み抜いてきたわけだけれども、

うん、

なんか、

じゃあ、

果たして、

なんていうか、

まあ、

そういうものを見てきた後で、

こう、

ね、

なんか、

うん、

そういう立場になって、

なんで?

理想のこう、

組織が作れるのかどうなのかみたいな、

うん、

なんか、

間違いなく、

もう、

踏み抜かないっていうのは無理だとは思うんだよね、

正直、

まあ、

そうだね、

その完璧な組織を持ってリスタートしても、

うんうんうん、

なぜならやっぱその、

価値提供が最優先のフェーズっていうのは、

1番最初、

それを、

使う、

で、

されるんじゃないかなって気はする、

うん、

普通に。

うん、

なんか、

うーん、

だからなんかそう思うと、

なんか、

そのそうだね、

んで、

そう考えていくと、

開発っていう方面に関してはまあ一つの、

布斎の、

布斎まあまあ何かその

布斎、

うん、

布斎というか、

大品質の一要素としてとらえていくと、

なんかそういう、

év

clan

lol

形でまあソフトエンジニアの、

うん、

持ってるとアドになるスキルだよね、

うん、

で、

思うし、

セキュリティ、乾杯セキュリティって言ってる上になってくるとそっちの方の初期フェーズのあるある夫妻みたいなの僕解像度があんま高くないからそっちはそっちでまた難しいんだろうけど

でも理屈は同じはずだよねなんか

そうはね

マシなやり方というか全然あると思うし

またその知ってるがゆえになんか無駄に無駄に気にしなくていいとこを気にすんなっていうこともできるよね

考えようと

そうだねやりすぎないというかなんか

そうそうそう仮になんかその仮にじゃあ事業性質上最初からセキュリティ気をつけなきゃいけないからってなって

いやーなんかちょっと

いや今言葉に詰まっているのは自分の経験を出すようになったけど

傷つく人がいるのかもしれないんで胸の奥にしまうんですけど

気になる人はDMで聞いてください DMで聞かれても答えない人いっぱいいると思うんですけど

なんだろうなそのなんか

そのなんだろうなセキュリティの知識がないけどでもセキュリティを恐れてるっていうその

ポジションというかそういう立場

そういうふうになんだろうな思えてるベンチャーのベンチャー企業にも全然あると思ってて

そうなった時に恐れ方を間違えるとさなんかいらない統制とかさそのいらないトレード法を飲むっていうのもあるわけじゃん

そこに対して僕らがもしいたとしたらいやなんかそのトレード法飲む必要ないですよなぜならリスク

例えばなんかいろんなパターンがあるじゃんねなんかそれやってもこっちはないてるんで意味ないですよとか

いやそれはそんな別にリスク観点で見たら大きくないですよとかもっとこんなこっちの方が楽にリスケッチできるんじゃないですかとか

なんかそういうところで価値を出せるっていうのもあるかもなっていうのはちょっと思ったな

いやでも強くてニューゲームはしてみたいっすね

してみたいよねなんかねうーん

いやー私なんか

結構明確にうーん

セキュリティの方面のスキルはなんかこの文脈で言うと明確に価値があるなって結構思ってるなぁ

うん信じてると言ってもいいかもしんないけど

いやでもしんどいもんなんかその

技術臭いよりしんどいとはなんか別のしんどさというかなんか

がある時もあるからうん

まあそんな感じですねはい

セキュリティチームの重要性

何の話だったっけセキュリティチームセキュリティ担当者いるいらないと

試合相いるいらないどうでしたろっていうところで僕が1聞かれて150喋ったって

いやありがとうございましたうんそうっすね

うーんいやーでもそのあとあれだねそういう話が

チーム概ね通りだけどチームいないと回んないというかそのバランス取れないんじゃないみたいな

うーんの話だねなんかうーんそうなんだよね

バランス取れないっていうかうーんそのなんて言ったらいいんだろう要はなんかこう

別になんかセキュリティっていうその領域を権利にやってる人たちに対して何かディスりたいとかそういう意図は全くないんだけどなんかその

存在意義がセキュリティに寄ってないチームが果たしてそのセキュリティっていうところに対して真に責務を負えるのかみたいなのはなんかちょっと

若干気になるところではあるかななんか

僕は結論相当難しいでいいと思うななんか

よく綱引きって表現するんだけどセルフ綱引きしなきゃいけない状況に陥るはずそうそうそうそうそう

基本的にはやっぱ例えば開発チームだったらその事業上の事業に価値を生む何かミッションを持っててそれに紐づく開発タスクを持っていて

でそれがチームの目標だとした時に

セキュリティ品質みたいなのってそこに紐づかないからそこでじゃあ

いやでもここのライン守んなきゃいけないっていうなんか自分の中のラインとチームの目標個人目標っていうと個人目標というかもう

課せられたミッションっていうそんな引きをしなきゃいけなくてその時にやっぱなんか

その優秀優秀じゃないっていうかもう人間だし積力的にはもう全社に傾くのは当たり前だと思うし

かといってなんかそのじゃあそのチームにセキュリティも責務と指名確認を任せて両方ミッションとして持たせるかって言われると

なんかその設計もやっぱ難しいというかさ

ね

まあ誰かがそこの綱引きセルフ綱引きを吉田にやってくれるっていう世界観だったらあるのかなと思っていて

うーん

そうねーそれはでもなんかそれできるそれするできる

それができる能力のある企業だったらなんかもうチーム作っちゃえばいいじゃん可能性はありそうだったよね

いやーでもやることやることはマジで多いし

なんか僕らというか僕のケースで言うとチーム作ってマジで正解だったなって今となっては思うわ

特にその言ってくれたバランス感というところで多分箱がないともう

あの多分通常運用時は回ると思うんだけど

事業上のめちゃくちゃもう超最優先OKあるみたいなのが突然降ってきて半年間これ

全員集中みたいになった時にチームがセキュリティチームがなかったら多分

まあなぁなぁになるとかその手が緩むとか全然あると思うしまあなんか起きるべきをして起きると思うし

輪読会の実施

まあでもそういう時に箱があるとで転屈でもそういうこと起きたけどそういう時にセキュリティチームはあったから

ある種いい意味でそれとは独立して粛々と

半年目線でみんながそれを動いていると認識しつつまあそれを加味した上でまあ1年帯にじゃあ僕らは引き続きこれやりましょうとか

そういう地に足つけて取り組み進められたからまあそれはやっぱ良かったなって気はするね

まああとなんかシンプルにそのセキュリティという領域がめちゃくちゃ広いっていうのは多分あってなんか

どう頑張っても横串的な動きが求められる中でなんか似たようなその幅を持ってる

なんていうか領域とかチームってない気がするんだよなぁなんか

いやーそう思いますよだからなんかない方できないと思うんだよねそれで言うとなんか

まあね責務をばらしていろんなところに持たせるっていうのはできるかもしれないねでもなんかその責務をばらしていろんなところに持たせるができるんだったらなんか

まあでも結構言うはやしな気がするから

まあね難しいね

そのばらしてみたいなのもやっぱ全体感見る人がやっぱどっかに必要だと思うから

結局そうするとなんかその人セキュリティの人じゃないのってなっちゃうんだよね

しかもなんかそのばらす元のなんか全体像みたいなのも会社に乗って変わるからそれを多分作る人が必要だと思うし

だからそれで言うと一つなんかちょっと個人的に仮説としてあるのはなんかそのどこまで行ってもこれがベースラインでしょっていうラインを決めて

決める違うな何に向けて何なのかわかんないけどどんな状況でもこれがベースラインでしょっていうものは僕はなんか自分の中にあるというか

なんかありつつある気はしていてリノベートを回すとか言語のバージョンアップはちゃんとするとか

まあそういうやつですそういうやつはその何だろうな

まあどんなフェーズのどんな会社とかでもその認識してセキュリティの知識がなくても回すとかっていうのは夢じゃないかなって気はしてるな

でそれにプラスアルファでどれぐらい必要かはもうほんと会社と事業と組織次第って感じなのかなって気はするな

そういう意味ではなんかいやーそういう

いやーなんかそこに目が向けば今言ったことをやるツールはなくはないのかなって思うな

例えばAWS使ってるだったらAWSのセキュリティハブ使えばプリセットのルールでバーって出してくる

そうだね

それはちょっとセキュリティ分かんないし

ニスカセセントもできないけどまあそれはやろうとかは全然ありだと思うし

さっきのレイアックスさん紹介したベストプラクティスのやつもあん中にセキュリティの話も多分混ざってると思うし

セキュリティプラクティスみたいなのもドキュメントも読んだことあったりするしそういうのは守ろうとか

今の時代だとまともなサービスまともなツールだったそういうのってセットで提示してくれてるからそれを守るとかは全然どの会社のどの立場でもやってもいいかもなって思ったな

確かに

それはなんかソフトエンジニアが頑張る

まずソフトエンジニアとしてはなんか自分で頑張る頑張れた方がかっこいいなって思ったからね

まあね間違いない

そんな感じですかもう45回話しちゃったけど

だいぶ使ったね時間

いやこれはちょっといいテーマだったな

こんなに広がると思わなかった

じゃあというところから次は瞬殺で済む感じですか

あー瞬殺で済ませましょうか

セキュリティチームの輪読会についてご紹介。TENXプロダクトブログ。私の著作、著書、記事でございます

全然関係ないけどこの冒頭の挨拶でIDを紹介できるんだね

あーそうかね

これどうやって記録したらこれになるの

直しに書いてあげる

これいいなと思って

俺これやらんかったわと思って

あーなるほどね

えー

今からでも書いとこうかな

めんどくさいからいっか

あのはてなIDね

いやー

まあ記事の内容としては

まあ弊社やってセキュリティチームの輪読会の紹介なんですけど

まあキーポイント

僕の推しポイントというかこだわりポイントだけさらっと紹介すると

まあきっかけは結構

なんていうか

生々しいセルフで評価して申し訳ないんですけど

なんか生々しくていいなと思って

その輪読会始めた時は

まあヤギ足はいなかったし

えーと

まあいわゆる駆け出しセキュリティエンジニア

2人組って感じだったんで

いろんな業務で

まあ死ぬ気でキャッチアップしながら

まあさっき言った

クラウドだったら

ドキュメント読んで

クラウドID連携ってなんだって言いながら頑張って設定するとか

そういう感じでやってて

でその

その業務の中で

日々向き合わなきゃいけないものに関しては

今言ったようにそのドキュメントをとりあえず読んで

とりあえず動くところまでやるとかって感じで

キャッチアップさせられるというか

キャッチアップしないと仕事が進まないという状況なんで

まあいろいろ

自ずとインプットされていくんだけど

まあ一方でその

なんだろうな

まあ業務で差し詰まってないけど

そのセキュリティエンジニアとして

まあなんでしょうね

摂取しておくべき

ナレッジというか

教養みたいなものって

まあソフトエンジニアも同じようにあるし

まあセキュリティエンジニアにもあるんだろうな

しかし当時の目線でも

僕らの目線でも

なんかこれちょっと読んでおきたいよね

とか知っておきたいよねみたいなのがちょこちょこあるんだけど

まあなかなか

その業務でさばくっていう

そういうのインプットするっていうのができてなかったんで

それをちょっと2人で苦しみながら

インプットしようみたいなのが

まあスタート地点って感じ

だったんですよね

なんでまあそれ前提に基本的には

その

なるべく長く

毎週1時間

ブロックして

継続的にインプットし続けるっていうのを

達成したかったんで

準備コストとか運営コストを超ゼロに近づきたくて

とかもう今も

ゼロと言って差し支えないんですけど

それは差してて

まあその結果今どういうスタイルでやってるかっていうと

まあ予習はゼロでよくて

で当日

決まった時間に集まって

でじゅんぐりに

その時に

今になっている本をただただ音読していく

っていうスタイルで

やってますっていう感じの

はい

を紹介してるって記事ですね

結構なんかこれで

音読

なんで音読に行き着いたかマジで全然覚えてないけど

臨読方式何個か調べてて

あ音読なるほどね

っていうかあと僕が昔

その

いたゼミで

卒業後の有志の臨読会でやってたんですよ

音読方式

でその時はくそむずい本を

苦しみながらみんなで読むって感じ

パタヘネとヘネパタ本かな

あのめちゃくちゃ難しいやつ

読んでたんですけど

まあ割と意外となんか

終わんないと思いきや

意外とちゃんとやれば終わるし

はいはい

まあ悪くなかった記憶あったんで

やってみたらまあなんだかんだ2年間続いて

チームが大きくなって今も続いてるし

まあ当初の目的だったら

いろいろインプットしていくっていうのもできたんで

僕は結構強くお勧めしたいなと思って

ここでも紹介したいなと思った

音読スタイルの利点

シテでございました

ありがとうございます

はい

ありがとうございます

なんか

入社して音読してて

びっくりした

そりゃそうだよね

音読しとるわと思って結構びっくりした

結構びっくりした

あのね

リモートワークっていうのも

その相性いいかもね

その相性いいっていうのは逆に

音読スタイルじゃないとなんか

リモートってなんか油断すると

意識が取りやすいというか

内職しちゃうというか

そうそうそうそう

スラック通知ぴょんってきて

見ちゃうとかさ

まあ自分が読むパターンになると

まあそれはできなくなるし

聞くパターンでも

聞き逃したらもう終えなくなっちゃうから

なんか国語の修行みがあるよね

そこは

うん

その意味でもまあいいっちゃいいのかな

っていう感じはする

まあこれがチーム何人までワークするか

ちょっとわかんないですけど

わかんないけどまあでも準備いらないからな

なんか別に

うん

でも人が増えれば増えるほど

脇道にそれてる時間も長くなっていくだろうから

なんか

そうね

そこはまたその興味みたいなのも

なんかあるだろうから

うん確かにね

セキュリティ専任の重要性

なんか本による

そうね

もっか課題になってんのは

セキュリティエンジニアとコープIT担当者

みたいな組み合わせで

何読む問題とかがね

あったりするからね

実際に

その辺はなんか

チームの成長に合わせて

最適化の余地あるかって感じですけど

まあまあ

似たような近況で困ってる人がいたら

おすすめですという感じですね

はい

じゃあ次

お願いしてもいいですか

はい

レッドチームは物語を語れ

技術レポートで組織は動かない

Googleが作成するナラティブレポートとは

スキャンネットセキュリティさんの記事ですね

一応なんか

会員登録しないと

読めない記事になっていて

あんまりなんか

記事の中身をどこまで紹介していいのかなって

ちょっと悩むところではある

確かにね

一応無料で

無料アカウントでも

月間3件までは

記事が読めるようになっていて

ごめんなさい

僕はこっそりで読んでるんですけど

で

えーと

はいなんかGoogleのレッドチームの話で

なんか

どう説明していけばいいのかな

読んでくださいとしか言いようがないんだよな

なんか

Googleのレッドチームの人の

講演のレポートで

内容としては

まあ

うーん

超ざっくり言うと

Google内部での

ペンティス的な

やるときの話だよね

で

そのときに

実際

結構僕は印象深かったのはやってみたら

まあスルッと大事なとこまでいけちゃった

みたいな話と

そこに対してどうゲームをしていくかみたいな

部分で

なんだろうな

僕もめっちゃ悩みではあるんですけど

例えばなんかこういう部分が

こういうセキュリティ観点で言うと

こういう

セキュリティホール

アタックサーフェイスになってしまって

こういう部分にこういう脅威があるから

だから危ないんだよみたいなことを説明しても

全然伝わらないというか受け止めてもらえない

けど

実際に

レッドチーミングして成功したときのように

こういう風に

攻撃者がヒョッとやって

こういう風にやられちゃったら取られちゃいますよねみたいな

そういう物語形式伝えたほうが

ずっと刺さるし

目的を果たす

レッドチームの啓蒙とか教育とか

っていう部分なのかな

めちゃくちゃ言い訳すると

そういう部分の目的って達成しやすいよねみたいな

素晴らしいまとめ力ですね

ありがとうございます

鍛えられたから

結構その技術報告書じゃなくて

物語形式の報告書

ナラティブレポートを

作成するとなんか結構

みんなに伝わるようになるみたいな

ものすごく大阪に行ったらそういうことなのかな

きっとね

早くフォーカスすべきだったよっていうことを

伝えてくれてたっていう

講演だったみたいです

成功しちゃったペンテストが

ペンテストというか

ペンテストって言っていいのか分からないけど

週1で面白かったな

入社4年目迎えた人に

Googleからのおめでとうをメッセージ

お祝いの品が

実はバリバリ

マリシアスなガジェットだった

Google

絶対騙されるよな

ワンチャンやるよな

って思っちゃうよね

グローバルカンペイント

海外しかもこういうの結構好きじゃん

入社時にさ

結構素敵なパッケージ

送ったりとかさ

いやー面白い

これは

Googleでもこういう今も

引っかかる人いるのか分からないけど

引っかかるは引っかかるんだよな

人間らしさを感じられて

個人的には良かった

次3件まで無料なんで

大企業と中小企業のギャップ

スキャネキットセキュリティの

宣伝ってわけじゃないけど

興味ある人読んでほしいです

ぜひ読んでみてください

非常に面白かった

おすすめです

意外と

プラクティスってわけじゃないんだけど

プラクティスではあるのかな

Googleネットチームは絶対これしないよとか

逆に絶対これするよとか

そういうのを紹介してくれたりも

していて

なるほどなって確かにそうだよな

みたいなのがあったりしたんで

とても良かったです

おすすめです

ありがとうございます

じゃあ次もスキャネットセキュリティ

いきますか

大企業の66.8%が

セキュリティ不備を理由に

取引停止や契約更新を見送る

しかし取引停止された

中小企業は

景気悪化等が理由とご認識

スキャネットセキュリティ

さんの記事です

どっか株式会社ミツモワ

っていうところの

サプライチェーンセキュリティに関する実態調査

っていうのが

あったらしくて

それの結果を買いつまんで

紹介してくれてるような記事なのかな

ほぼ

タイトル通りではあるんだけど

意外と

大企業の66.8%が

取引先が

ちょっとセキュリティ不安だな

みたいなので意外と

取引停止とか

縮小とかをしてたよっていう

話で一方で

認識に完全にギャップがあって

取引とかを停止されたり

縮小されたりした側としては

不景気だからしょうがないなみたいな

そのことを思ってるみたいな

話らしくて

世知辛いなってちょっと思った

感じですね

続けて言うとちょっと

一個前の週なんだけど

持ってきました

記事の最後の

匿名のお声みたいなのが

生々しくてありそう

と思った

スキル不足及び情報不足により

セキュリティ対策に踏み切れず

導入依頼を無償でしてほしいと要請された

PCの操作方法を説明しても

相手のスキルがなく話が通じない

社内だったら

どうにかしようだけど

社外だったら

別のベターになってきちゃう

やめようってなるよね

このギャップは

埋まるのかな

構造的にめちゃくちゃ埋まりづらい

よね

中小企業目線はな

どういうコミュニケーションとってんのかな

なんでですかみたいな話

とかしないのかなって思うし

なんですかってのは

大企業から中小企業に

逆逆中小企業側から

取引停止ですって言われた時に

なんでですかみたいな

そこは分かんないけど

パワーガラスが歪んでるパターンとか

あるのかな

単純

どうなんだろう

すごい

偏見で語るの

ちょっと良くないかな

中小企業と大企業っていう関係性とかだと

バランス的には大企業側が

強いっていうか

強いっていうのは別に威圧的って意味じゃなくて

中小企業目線は

なんていうか

分かんないな

うん

なんでって聞いてるパターンはあるんじゃないかな

さすがにでも

なんか上手いこと

濁されたというか

また腹割って話してくれないとかも

あるのかもしれない

うん

分かんない

悪い妄想だけど

腹割って話しちゃうと堂々めぐりになるから

もう別の理由にしちゃおうとかも

普通にありそう正直

分かんないけど

古いパソコン使ってるからですよ

って言って古いパソコン何がいけないんですか

嫌だからこうでこうで

それがなんで失注するんですか

みたいな例えばだけどね

なんかすごい悪い妄想だけど

そういう風になっちゃうんだったらまだ大企業目線は

全然価格の理由で別のところで

申し訳ないですって言っちゃう

普通にありそう

なんか結構

結構双方不幸だなっていう

不幸な構図になる

なんかその

業界で言うと

あんまり

ここでは取り上げてないし

僕はなんか詳しくないんで多分これからも取り上げることだと思うんですけど

そのOTシステムというか

ハードウェアに近い

産業システムみたいなところとか

の記事ってたまに流れてくるんだけど

海外日本とか

結構それ系とかあと

例えばなんか国が

明確にIoTデバイスとか

多分開けやすいけど

セキュリティリスクがやっぱ相対的に

いろんなもの見たときに大きいから

先にしてガイドラインが

決まっていってとか

そのISMS的な

評価基準みたいなの決まって

こういうので製品

企業を評価しましょうみたいな

なって

そういうのが整ってる

何だろうな

業種とかはもしかしたらこういうの

ところをそういう

標準化とかで埋まってくれたりするのかな

と思うけど

相対的に

セキュリティ領域に関してリスクが

低いじゃないけど

需要されてないような業態とかは

こういう状況がしばらく続いちゃっても

おかしくないかもな

って思ったりするな

相対的に低いって

なんだよって感じもするんだけど

読んでて辛くなったな

セキュリティ対策の課題

なんか

これ

切ないですね

サポート切れの古いパソコンを使用してる

セキュリティの知識が足りないみたいなのを

言われる会社にならないために

やっぱなんか

さっきの結構

僕と試合2番目にめちゃくちゃ

ベラベラ喋った話に繋がって

個人的にあるんですよね

あるかもね間違いない

セキュリティセクションを

いつどのタイミングで認知できるかというか

認知できないまま10年20年経ってしまったら

こうなってしまっても

正直おかしくないと思うから

これ自体ね

実際にビジネスの基礎に伝わってるわけだし

まぁそれは後日消すぎ

かもしれないけど

はい

ありがとうございました

よし

あー

次

じゃあお願いします

はい

頑張って思い出そうと思って

SPAで発生しやすい

クライアントサイドパストラバーサル

リスクとその対策

JMOフラットセキュリティブログですね

SPAシングルページアプリケーションにおいて

クライアントサイドパストラバーサル

っていうものがありますよ

っていうところで

その解説と

そこに対する対策みたいなのをセットで

かなり丁寧に解説してくれてる

っていう記事ですね

いやーこれ忘れちゃったな

めっちゃ頑張って

読んで

でも割と序盤の

フローズが分かりやすかったかな

正常形と異常形のやつで

クライアントサイドの脆弱性

原理を説明してくれてたやつ

が

はい

あーはいはい思い出しました

そうですね

ブラウザの操作で

フロントエンドのJSの

挙動によって

意図しないAPIサーバー

とか場合によっては

別のオリジンに対して通信を飛ばしてしまう

みたいな脆弱性があったときに

他の要素と繋げると

クリティカルな脆弱性になり得るよ

みたいな話

いやー

思い出しましたこれめちゃくちゃ

面白いなー

面白かったなー

ようだし知らなかったな

なんで知らなかったんだろうって思ってすごい

これってなんかどうなんすか

メジャーというか

知らんとダメでしょ系な

感じですね

名前がついてるのは知らなかった実は

あーなるほどね

確かにこれ名前

なんかずっと名前ついてたのかな

それともなんかここで

これはまさにクライアントサイド

パストロバーサルだよねっていう呼び方を

してくれてるのかな

どうだろうね

確かになんかリンク的なものは

なさそうだね

チートとかするものは

でも参考文献

参考文献アサルトよさそう

あーまあありそうだね

クライアントサイドパストロバーサルって

一番上から二つ目にいるから

まだ名前としては元々あったんだね

あーなるほどね

仕組みとか実装上

まあそうなるよなっていうのは

めちゃくちゃなんか分かるんだけど

いやーこれ

なんだっけ

対策が結構悩ましいなと思って

カタナ

API JSONプロパティを

リクエストレスポンスで拒否するみたいな

でこれまあ多分

副次的な対策っていうよりか

副次的な対策って書いてあるけど

なんか

その

モバイルもかもしれないけど結構その

こういうなんか

クライアント向けのAPIで

そのレスポンスに

使わないけど

値が入ってくるっていうのがめっちゃある

あれだと思ってて

まあそうだね

まあなぜかというとその

フロントエンドで

なんかうねうね動いてるいろんな

ユースケースボタンを押す

なんか何かを入力する何かを表示するみたいな

いろんなユースケースに対して

一個一個APIなんて

いちいち実装してらんないからやっぱりその

既存の

このID渡したらこれ引っ張ってくるみたいな

APIを

のうちのこの値だけ使うとか

まあ複数API叩いて

ガッチャンフロントエンドからでガッチャン

こうして表示するとか

まあめちゃくちゃ普通に行われてることだと思うし

なんかそういう状況において

この対策は普通にきついよな

っていうのは思ったりはしたな

ゆえになんか

グラフ距離欲しいとか

まあ今だともうSSRで

フロントエンド側に持ってきちゃうみたいな

ちょっとトレンドになりつつある気はするけど

そういう動きもあるんだと思うし

いやー

なんかでもあんま現実的じゃない

気がするけどな

脅威するって

うーん

なんか攻撃

実際にあった事例みたいなのなかったもんね

なんか有名なサービスでこれで

とかはそんなに表になってないだけで

あんのかわかんないけど

まあでも概念としては

普通に起きそうっていう

起きそうっていうか

作り込めそうって感じはするから

そうだね

いや面白いけど

なんか面白いけどって感じやな

あー

なんかしんどくなっちゃうな

って感じはする

うーん

クライアントサイドでの入力値減少

まあでもこれもセキュアバイデザイン

本の考え方は

適応できる気はするな

普通に

なんか異常な値を

受け入れないっていう

このクライアントサイドトラバーサル

パストラバーサルのために

やるんじゃなくて

そもそも変な値入ったらバグるかもしんないし

UIも変になるかもしんないから

まあ

クライアント側で

バリエーションしましょうっていう

ので十分防げる気はしたな

SDLCと新しいフレームワーク

うんそうだね

なんか

1個

あれするところがあるとすれば

あれだね

今までその

入力値検証みたいなのをしましょう

っていう風にプラクティスとして言われてた

クライアントとバックエンドの

境目なんだよね

たぶん従来から言われてたなって

でこれってクライアントの中にも境界線が

1個あるよねっていうことを言っていて

うんうん

そういう意味でいくと

なんて言ったらいいんだろう

ちょっと難しいなっていうか

昔ながらの

思考みたいな話じゃなくて

もう1個ここにもレイヤーがあるよね

っていうのを認知しないといけないから

ちょっと大変だなとは思った

いや確かにね

その意識を持っててる

フロントエンド開発者がどのくらいいるかというと

あんま分かんねえな

うん

分かんない聞いてみてえな

うん

ヒロッピーにこれ知ってるっていう

何かとヒロッピーの名前出してるけど

ヒロッピーはだいたい何でも知ってるから大丈夫っしょ

この記事が

この記事をツイートしてる人探してみよう

海外で話題になってる

いやでも面白かった

ブックもすごいついてる

いやあ

クソコメがついてるけど

ありがとうございます

はい

じゃあ次

えっと

はい

SATF

The First Threat Framework for SDLC Infrastructure

Reasonable

ですね

何かと言うとですね

SDLCって言ってるのは

ソフトウェアデベロップメントライフサイクル

っていうの略

というのを僕も知ったんですけど

具体的には

記事中の1個目の数が

分かりやすくて

開発プロセス開発ライフサイクル

っていうのをちょっと

モデリング分解したときに

ここでは

まずエンドポイントとIDが

一番最初にあって

開発者が開発してる端末と

その端末上で

動かしてるIDですよね

VSコードなのかVMなのか

Emacsなのか分からないですけど

そういうものがあって

そこからVCS GitHubとか

GitHubとかにGitを通して

プッシュしてコードを管理して

それをCICDで検証したり

デリバリーしたりして

レジストリ

次にレジストリがあって

CDで作った成果物とかを

どっかイメージなのか

パッケージなのかジップラインなのか

分からないですけど

レジストリに上げて

最後それがプロダクションクラウド上で

動くっていう5つの段階に分けて

整理してるんですけど

このSITFっていうのは何かっていうと

この5つに分けたものに対して

どのポイントで

どういう脅威があるのか

っていうのを

いい感じに可視化整理するための

フレームワークっていう感じですね

ぜひ多分

声

音声で聞くより

触ったほうが100倍

もしくはその記事の画像を見たほうが

100倍理解が早いので

ぜひ興味ある人は触ってほしいなと思うんですけど

具体的にどうなのかみたいなところで言うと

例えばシャイフラット攻撃が

ここでも取り上げましたけど

シャイフラット2.0に対して

実際にこのフレームワークを

適用してみると

シャイフラット2.0の

対して実際にこのフレームワークを

適用してみたよみたいな

のとかが

活用例として書いてあって

例えばどこだ

完成像みたいな

パッと出てこないな

これかこれでいいのか

例えば

一番最初に

CICDに

シャイフラット前は侵害されて

その中で

シークレット

フロムワークローって書いてありますけど

シークレット抜くとか

シークレット抜いちゃうと

その中にNPMのやつがあったら

Publishing malicious package

レジストリのところでやられちゃって

そこからまた別の

サプライチェーンアタックに行ってとか

そこからエンドポイントのほうに戻っていって

みたいな感じで

いい感じにビジュアライズできるっていうものになっている

って感じですね

このアプリケーション自体は

オンラインでも

GitHub Pagesで動いてるんで

誰でも触れますし

あとはオープンソースになってるんで

手元でローカルで動かしてっていうのもできるし

一応このサイトで動かしたものとかは

別に保存されたりどこかに送信されたりしないから

使ってもいいよって言ってるけど

業務で使うんだったら

ローカルで動かすのがいいのかなっていう感じですね

結構いい感じに

今手元グリグリ動かしてますけど

こんな感じで動かして

イメージ的には

マイターアタックみたいな

フレームワークみたいな感じで

この横軸

縦軸でこの領域があって

この領域においてはこういう攻撃手法

こういうのがありますよみたいなのが

このフレームワークでも

さっき言った5つの

カテゴリーに対して

ウィズが構築した

フレームワークをもとに

いろいろこういう教諭があるよっていうのを

整理してくれてるって感じですね

記事を読みながら

めちゃくちゃいいじゃんって思いつつ

マイターアタックとかと

何が違うのかというか

マイターアタックじゃ何がダメなんだっけみたいなところ

を言いながら読むと

一番最後に言及もあって

既存のマイターアタックとか

OWASP

CICD TOP10 これ僕知らなかったんだ

って言わなきゃなって言ってるんですけど

そういうフレームワークとかいろいろあるけど

その

SDLC

デベロップメントライフサイクルに着目して

こういう

何だろうな

脅威モデリングというか

どこに何があってどう繋がるのかみたいな部分を

可視化したり整理する

いい感じのツールってなかったよねっていうところから

こういうものを作りました

っていうことを言っていて

確かにそれは

僕がないと生きるほどその知識は

なんともいないけど

モチベーションは

分かるなと思うし

シャイフラットの2.0のやつとかを

整理した図とかを見ると

Octane STSの導入

なるほど使えそうって思って

ご紹介という感じですね

間に合ったら仕事で

ワンチャン使って

使ってみたって言ったかったけど

それは

機会があったら記事書きますか

普通にちょっと使ってみたいな

と思ったけど

WeMusicalと比べてどうですか

WeMusicalと比べて圧倒的に

厳密

コンセプトはめちゃくちゃ

良くてなんで

あとは

この5個のカテゴリーに振られてる

あらかじめ

さっき言ったシークレット抜かれるとか

全然見れてないけど

どういうのあるんだろうね

CICDとかだと

セルフホスティットランナーで映像化されるとか

そういうのが

いくつかあるんですけど

これの充実具合変わってしないかなって感じかな

個人的には

これで

これないじゃんってなると

どうしようってなると思うから

あとは

あれかな

そのカバレッジ次第かな

でもウィズ性だし

いけんじゃねって勝手に思ってるけど

それが

担保されてるのはWeMusicalより

圧倒的に良いと思います

良いという

そうね

全然場面で使えるとは言わないけど

例えば

GitHubのこのリポジトリのCICDの

脅威分析したいなとか

もうちょっと全体

GitHub全体の脅威分析とか

あと使えそうなのは

この

リプレイFMの取り組みで腐るほど見てますけど

こんな挙動をする

悪意のあるVSコードが出たと

エクステンションが出たとか

そういうのも多分これで整理できると思うし

結構使えるイメージは

個人的には湧いてるなって感じですね

良いね

ちょっと使ってみたいですね

うん

だいぶ作りこまれてる気はする

うん

サナイでも使ってるのかなきっとね

あーそうかもね

もしかしたら

なんならお客さんに提供してるかもしんない

知らんけど

うん

結構なんか色んな攻撃リサーチして

リサーチブログ出してるし

便利なんだろうね

自分たちもこれだった方が

うん

このエンドポイントIDEとかなんか

ちょっといいなって思ったな

なんかいいなっていうのはエンドポイントじゃなくて

IDEっていうのをわざわざ入れるというか

うん確かにね

星の数

エピソードをシェアする

メッセージを送信

Sota Sugiura

サマリー

目次

星の数

コメント

こちらもおすすめ