再会の挨拶
こんばんは、Replay.fm第27回です。
こんばんは。
こんばんは。
お久しぶりです。3日ぶりぐらいですかね。
3日ぶりっすね。開いたね、なかなか。
いやー、久々ですね。
いやー、どんだけあってんだよ。
3日ぶりっすよ。
なんかね、今週は記事が少ないので、3日しかなかったけど、なんか割と体感、日数に合わせた感じの記事の数で、ちょっと面白い感じ。
そうね。
珍しい。
いやでもね、俺ちゃんと読んだんだよ。
あの、目技術に、目技術か見れる理論なんですけど。
あ、そうなんだ。
赤ニュースとかブリピンコンピューターね、一通り全部目通したんだけど。
いや、マジ偉いよな。
いや、ほんと偉いと思う。タイトルでかなりもう、なんか落としちゃってるわ。
うん。なんかちょっと、なんか楽しくなってきた。わかんないけど。
偉い。
そう。
あの、いや、ま、でもほんと、ほんとザサッと、ザサッと、ようや、ばーってぽちぽちに押して要約させて、で、もう15秒ぐらいばーって地図サラだけ折って、引っかかったやつ以外はほんとに読んでないけど、まあでも、そうだね。
うん。
まあそれだけでも結構潮流というかね、あ、インフォスティーラーの文字が増えてきたねーとかわかんないけどね、さっきのと。
うん。
うん。そういうの見えんだけども、いいかなっていう気持ちもありつつって感じですね。
Node.jsのCVE問題
はい。
はい。ま、普段のね、半分の量なんで、理論上は1時間で終わるのか。
まあいいや。
まあね、なんかでも鈴木俊介さんの記事とかは紹介しなくてよかったの?
あのー、これ?
うん。
これはね、出直してきますって感じです。
あー。
ちょっと言うと、試合で行動責任修正するためのアクション作ったんでツイート押さえてて。
うん。
新しいアクションがあって、これはね、ちょっと僕の中で、その、何がほんとに嬉しいのかをゆっくり整理したいなと思ってるんで。
あー。なんか記事も書いてくれてたよね、これね。
うん。
なるほどね。じゃあ、記事も書いてくれてたよね、前にね。
あ、マジで?
うん。
それ、まだ見てないかもな。
それ多分今週分に入ってないよ。
うん。入ってるとしたら来週分かな、多分。
昨日か今日あたりだった気がするから。
それ読めばもしかしたら、ちょっと脳内すっきりするかもなんで。
はい。
まあ、最悪マチポンポン式で。
うっそー。
はい。
じゃあ、上から行きますか。
行きますか。
えー、私読もうかしらね。
お願いします。
はい。
インプレスウォッチの記事で、いよいよ迎えた古いノードジェイスのCV…
不版って読むの?これ。
不版じゃない。
CV…
不版でいいよ。
はい。
30代我々、不版が読めない。
俺は読めない。
まあまあまあね、誰もがあるからね。
ありがとうございます。
ノードジェイスのCV不版、MITREに却下されてしまう。
これで不版じゃなかったら恥ずかしい。
はい。
で、開発チームが新方針発表、EOL版は便宜上今後新たな脆弱性すべてが該当する原則2っていう記事ですね。
はい。
で、これなんかね、サブスクライブしてないけどたまたま長い出来て、ちょっと興味深いなと思ったんで読んでみたら、まあ興味深かったなって感じなんですけど、
まあ、記事の内容ちょっと話すと、ノードの18かな、今22がLTSで、20がメンテナンスモードで、18がEOLになっていて、
で、ノードってその偶数の番号が基本的にLTSで、どんどんどんどん世代交代していくんですけど、そのEOLを迎えた18以前と奇数の19、21もEOLなのかな、ちょっと把握しないですけど、
まあその辺のEOLバージョンに対して、そのバージョン18全部にCVEを発行したかったっていうのがノードJS開発チーム側の要望としてあって、申請したんだけど、それが却下されちゃったっていう話です。
で、まあなんかこの話だけ聞くと結構乱暴というか、普通だったらその言語のバージョンで、このバージョンにこういう脆弱性が含まれてるよって感じでCVEが発行されて、リノベートとかでベンダマットを運用されてる方であれば、それを使ってるときにアラートが上がってきて、
これには脆弱性含まれてるのねっていうので対応するみたいな生活を送っている方がまあいらっしゃると思うんですけど、まあもうそのこのバージョンにこれが入ってるとかじゃなくて、このバージョンはもう脆弱ですっていうやつを開発チーム側がやりたくて、却下されちゃったって話で、で、却下の理由としては、別にそのバージョン全部に脆弱性入ってるわけじゃないじゃんというか、それはCVEのものとしてそういうものじゃないよねっていうところだと思うんですけど、
まあ一方で、じゃあ開発チームがなんでこの僕が乱暴と表現しちゃったけど、バージョン全体をCVEに、バージョン全体に対してCVEは発行したかったかっていうと、そのさっきも言った通り、そのNode.jsしっかり他のゲームもそうだと思うんですけど、複数バージョンをその並行してメンテナンスしてるんですよね。
今だったらNode 22をメインでサポートして、20をメンテナンスのためにサポートして、おそらく23のバージョンも頑張って開発してるんでしょうね。
ここで24が出たら、偶数番号3バージョンメンテしていくってことになるんですけど、メンテしていく中で、例えばバージョン22のこの部分の実装に脆弱性が見つかりましたってなったときに、その部分のコンポーネントが他のバージョンにも含まれてるかどうかっていうのを調べなきゃいけないんですよね。
例えば、22こんなのありましたってなったら、じゃあこれっていつからあるの?バージョン16あるっぽい。じゃあバージョン16にあるのかないのか。バージョン16具体的にどのバージョンにあるのかとか、それを16から17、18、19、20って全部調査していかなきゃいけなくて、厳密にやるとそんなことをしなきゃいけないんだけど、開発チームにはもうそんな要領がないですっていう話があるので、開発チームとしては、
EOL版の重要性
このEOLにしたものっていうのはもう僕らとしてはどのバージョンに脆弱性入ってるかなんてもういちいち調査もできないし保証できないので、し、そもそもEOLなんで脆弱なものとして扱ってサポートされてバージョンを使ってほしいっていうのが意図としてあるっていうような感じの議事です。
はいはいって感じですね。結構最初はなんかそれは却下されるだろうって記事を読みながら思って、途中からいや確かにちょっとこれは根深いというか、いちいち調査してらんないよなっていうのもあるし、言うてもその企業が開発する言語じゃないというか、ある程度のボランタリーで、その寄付金とかあると思うけど成り立ってる中で、
結構厳しいよなぁっていうのもありつつ。あとは逆に認識しなきゃいけないのは古いバージョン使ってるけど、defend.alert上がってないから大丈夫って思ってる人がいたら、Node.jsに関しては多分もうそうじゃないというか。
Node.jsに関しては、でもそれで言うともう古いバージョンはすべて該当するよって形でCVEが不満されていくことになったから引っかかってくるわけでしょ。
そうなったのか。
これ要は特定バージョンの利用そのものを脆弱性っていう形でCVEを不満しようとしたら却下されたけど、それが無理ならということで今後出てくる、今後不満されるCVEに関してはすべてEOLのバージョンは該当するよっていう形で出すっていう話だよね。
完全に読み違えてました。
なるほどね。
と思ったんだけど、合ってるよね多分。
そこで新たに発見された脆弱性が基本EOLバージョンすべてに影響するものとして扱われることになったっていうのが結論でしょ。
だから該当しないものが場合によっては反映される可能性はあるけど。
なるほどなるほど。
じゃあちゃんとそうだね、検診してるね。
ごめんなさい、読み違えてました。
正直これぐらい振り切れと対応してくれた方が助かる側面は絶対あると思っていて、
EOLの製品を使い続けることに関するリスクみたいなところを言わなきゃわからないんですかみたいな話とかって普通にどうしても生じ得る議論だと思っていて、
それは別に、でもEOLじゃなくても明日でかい脆弱性が降ってくるかもしれないし、
そこはEOLであってもなくても変わらないかもしれないんだけど、
サポートをどれだけ受け入れられるかみたいな話ってやっぱり変わってくると思うし。
そうだね、なんか変な話、
EOLなんだからそのバージョンで本当にクリティカルなものが出たときに、
何だろうな、じゃあゼロで出ましたみたいになったときに、でも公式はもうパチ出しませんちゃったときにどうするのみたいなところとか考えるとやっぱ。
出しませんって多分普通にあると思うんだよね。
例えばだけど、このNode.jsのケースでいうと、そもそもリソースがあんまねえよっていう話が一定としてあるわけだから、
例えば過去のバージョンに遡って、今回だけは本当にでかいんで直したい、直すべきなんだけれども、でもやっぱりもう体力がないので無理ですっていうのは普通にあり得るわけで、
あるいはめちゃくちゃ遅れるとかね、特定バージョンのエンパッチみたいなのが。
そういうのを考えるとやっぱり使うなっていう話にしかならないと思っていて、
これぐらい振り切れて対応してくれた方が説明がしやすいっていう側面はありそうだなと思う。
現場のセキュリティ担当者にとっては結構嬉しいよね。
この裁判があるだけで結構説得材料が一つ増えるというか。
あるのかないのかすら今後は分かりませんよっていう話になるわけだから。
そうだね、確かに確かに。
間違いない。
そんなものを抱えてられるんですかっていう話になるわけだから、今回はノートジェイスに限った話だけれども、
結構別にこの利用自体個人的にはまあいいんじゃないのっていうふうに思うので。
そうだね。
まあね、なんか実態に即してないっていう意味では若干の気持ち悪さはあるんだけど。
いやー、でもいいお年をこらえる気がするわ。
あとなんかちょっと話聞きながら思い出してググってみたけど、
本当にどうしようもない人はなんか、
ヒーローディブズっていう会社なのかながあって、
サポートが切れた言語とかフレームワークを課金したらサポートなんか無理やりメンテしてくれるっていうやつがあって。
すごいね。
これね、面白いんですよ。
まあだからあれでしょ、オレオレバックポートを作り続けてくれるってことでしょ。
そうだね。
今見たらノートジェイスも12、14、16、18はやってくれるらしい。
12ってさ、何年前のBHPとかいくつまでいけるの?7.2なんだ。
5Kは無理なのさすがに。
さすがにね。
いやー、時間かかったな。
ちょっと豆知識って感じですけど、どうしても説得できない。
逆にこれも説得材料にできるかもしれない。
いやでもさ、そんなにさお金払うんだったらさ、直せよって感じするんだけど、ダメなのかな。
お金の使いどころがなんか、いやーでもなんか、
めちゃくちゃ広範囲で使ってますみたいなケースもあるのかな。
うん。
だから一箇所直せばそれで済むみたいな話じゃ全然済まないケースもあるはずで。
そうだね。
うん。
まあ、もしくはもうどうしても開発リソースがなくて金で解決。
GitHub Actionsのベストプラクティス
いやでもさ、金で解決するんだったらさ、なんか移行とかにお金使った方がさ、なんかいいんじゃないの?
まあ確かにね、外注してね。
うん。
確かにね。
うん、確かにどこに、どこにあるのか。
これいくらかかんのよ。
10万のかな。
うん。
これね、結構高いはずなんですよ。
ノードJSの値段見てみますか。
あ、三つ盛りカスタム価格って書いてある。
うん。
恐ろしい。
じゃあ、ちょっと使ってみたの記事をお待ちしてます。
いやだな。
その使ってることはあんまバレたくないよな。
ほんとそれ。
うん。
そっかーって言って。
音者、メジャーアップデートできないのかなって。
もうわかんない。
なんかね、いろんな事情があるからその一応悪いと言いますけど。
うん。
うん。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
はい。
じゃあ次。
はい。
GitHub Actionsベストプラクティス2025っていう、さっき話した鈴木俊介さんのスライドですね。
どこで発表したやつなのかなこれ。
発表とかじゃなくて 単純にまとめ たやつなのかな わかんないけど
いや なんかの発表だった
うん はい で 私のメモは 投げ なんかわかんないけど たぶんいっぱい
ブログ記事を書いてくれてる印象 で たぶんそれのまとめなのかな
っていうふうに思ってるので まあ ちょっとGitHubのプロに解説を
頼みたいなと思います
GitHubのプロもどきです でも そう かもね ブログまとめプラス
ブログ全部読んでるわけじゃない けど 結構 その行間とか埋めたり
ブログになってないものも結構 まとまってるって感じで 一言で
言うと 今時点ではこれ全部やっとけば GitHub Actionsは考えることほぼなくなる
はずなわけだから 本当にそう思う だけど やろうと思ったらめっちゃ
難しいと思う 難しいものもちょこちょこ 混ざってるって感じですね
それはなんて言ったらいいんだろう トレードオフがでかいっていう
話なのかな
っていうよりかは このいくつかの 例えばですけど なんかいいのある
かな そうですね 例えばこの7ページ 目のDisallow allow GitHub Actions to create
an approved pull requestっていうオプション があって これを有効に効果しましょう
ってやつがあるんだけど これは 例えば GitHub Actionsが吐き出すデフォルト
トークンでプリリクの自動生成 みたいなのを 既にガチガチに組ま
れたリリースサイクルの中で使ってる 場合に これポチってやったら崩れる
わけじゃないですか なんで デフォルト トークン使えないからどうすんの
パッド使うの でもパッドってイマイチ だよね GitHub使うのとか それをリリース
を止めずに リリースを壊さずに やんなきゃいけないっていう難しさ
がある そういうのがちょこちょこ あるって感じですね 自分はそれ
こそ 多分どっかにあるんだけど 例えば パーミッション ミニマイズ
パーミッションズをGitHub Actionsトークン ってやつ パーミッション自体は
ちっちゃく削ってもらうし ブログ 昔書いたんですけど 多分どっか
にそれに触れると思うんですけど デフォルト パーミッションを全部
ライトを持つのから全部リード まで落とすっていうリストリフト
パーミッションみたいなのがあるん ですけど それとかも既存のアクションズ
がどのパーミッションが必要か って何というか 今って機械的に
検出する方法が何もないんで もう 読むしかないんですよ 読んで
これがあれば動くんじゃないか っていうのを切り詰めて 動作確認
して よし 動いたっていうので繰り返 していかなきゃいけないんだけど
ものによってはぶっつけ本番じゃない といけないというか 既存のワークフロー
の品質に多分依存するんですよね 動作確認がしづらいような構造
になっちゃってたりとか 本番叩 かないとちょっと動作できない
みたいな じゃあそれってちょっと もう次のリリースまで動かせない
からこけたら読んでくださいみたいな 感じでやるとか これはもう実際
難しいアクションの設計
に僕がやったことなんですけど そういうようなのがちょこちょこ
あるなっていう あるなとかある って感じですね そう 結構一個
一個は1枚のスライドでも定まるん だけど ちゃんと何が起きるかを
理解してないと 何だろうな 結構 つまずきやすいものとかはある
かなっていう感じですね そういう 意味で難しいものもあるって感じ
ですね あとはそうっていう気持ち とGitHubのセミプロでも知らなかった
やつ結構あったなと思ってて 勉強 になったなって感じで gshows setup
gitみたいなコマンドとかが紹介 されてたんですけど これは知らなくて
前に紹介した記事あったけど gitコマンドとかでリモートオリジン
とかを設定しちゃうと そのクレデンシャル がファイルに露出してみたいな話
とかが これ使うと可能性がある かしか
全然覚えてないけど はい ある な
多分パーシストクレデンシャル の話かなと思うんですけど
いや マジで雰囲気でGitHub使ってる な
アクションズはそこまで使ってない のは
いや これ長い間触んないと 多分 99パーセントの開発者は触っても
週1回じゃん アクションズって あと
っていうのもあるし 私自身はもう ほぼ個人の趣味の開発しかしてない
ので なんかもう全然気使ってないん だよね
そうなんですよね なんでそういう 細いのがいろいろとか いくつか
便利ツールも紹介されていたり とかって感じですね あとは何か
これ多分来週の記事にあったんで 読んでないけど 多分そっちで話
したほうがいいからあんま増えない けど リカードステータスチェック
問題の話がP29かに書いてあって これはめっちゃ分かるなって気持ち
で読んだりしてましたね 具体的に 何かっていうと 統制を効かせる
ためにこのCEIを通してないとマージ できないっていう設定をみんな
すると思うんですけど モノリポ 構成とか モノリポじゃなくても
例えばアクションズに対する 臨闘するワークフローがあって
これ通さないとマージできません ってしたいじゃないですか 例えば
だなったときに でもアクションズ のファイルに変更がないのにその
ワークフローを走らせるのはお金 がもったいないから GitHub Actions
のPathsみたいなプロパティーで そもそも実行されないようにしたい
みたいな話があったときに その 状態でリカードステータス リカード
チェックにそのワークフロー 入れちゃってると 節約のために
編集がないから走んないけど 走ってないからチェックが終わらず
にマージできないみたいなこと になって それどうするのって話
がこのProgram Zonesリカイドチェックス っていうスライドの話ですね
結構僕の中では2つアプローチがあって 1つは1個もエントリーポイント
を用意してそれをリカイドチェック にして その中でさっき言ったこういう
条件になったらこれを走らせる っていうのを擬似的に再現して
担保するって方法か あとはメモ に書いたんですけど もう多分
スライドでは触れなかったんだけど もう1円あると思ってて そのステータス
そのPRに紐づくステータスを全部 API経由で取ることができるんで
スキップされたやつもそう 込み で全部取ってきてNGが1個でもあれば
弾くっていうものを書いてそれを リカイドするって方法もあるかな
っていう でも今しゃべったと思った けど CI改変できる場合は意図的に
スキップさせればフェールさせ ずに突破できる気がするからダメ
かもしんない ちょっとダメかもな だから書いてないのかも
どっちが守りやすいかは正直今 パッとは分からないんだけれども
認知負荷の上ではどっちのほう が低いのかな
認知負荷的には圧倒的に後者だと 個人的に思ってて
そうだよね
前者 それこそうちの弊社の一番 でかいリポジトリは前者のスタイル
なんですけど
結局何がリカイドになるのかよく わかんないよね なんかパッと見て
結果だけ見れば分かるんだけど さ
そうね 作り次第なんだけどワーク フロー自体のネストが深くなる
のが結構きついなと思っていて もう2階層なのはそこで確定する
わけじゃん 1個エントリーポイント があって そこから実行したいもの
を全部バーって叩くって感じなんだ けど アクション自体を使い込んで
いったり整理していくと そこから さらに分解していってどんどん
ネストが深くなっていくはずで そうなってくると結構見通しが悪い
というか ログが追いづらくなったり とか あとネスト数の制限もある
からそれに引っかかんないように 気をつけなきゃいけないとかも
巨大化していくという話があった りして なかなかあんま深くしたくない
なって個人的には思うというか またさっき言ったパス判定みたい
なのも疑似的にというか 自前で やんなきゃいけないから せっかく
公式のプロパティで正規のもの があるのにそれを使えないっていう
のもあんま直感的じゃないよな とかは思ったりするかなと
なるほどね 個人的には
CI/CDの成熟度
なんかその辺ってGitHub Actionsその ものの成熟度合いの話なのか それ
ともCI-CD全般に言える話なのか といったらどっちなんだろうね
いや 気になるね CI 結構多く
なんか正直別にサークルCIとか Algo CDとかも別にめちゃくちゃ触り
込んだわけじゃないので 個人的に 実際どうなのかなっていうのが正直
よく分かってなくて
そうね それで僕も分かんないん じゃな GitHub Actionsしか触ってない
けど でも僕が最後に触ったサークル CIは運用不可能だなと思った記憶
ペラ一で書かなきゃいけないから もう無理無理無理って思ったな
構造化しにくいし再利用性で切り出す みたいなのを1枚の矢文の中で
ガチャガチャしなきゃいけない から 僕のIDの設定が悪かったのかもし
れないけど コードジャンプみたいな 概念がない中でそれを整理したり
読み解いたりっていうのは結構 キツかったなっていう でもサークル
CIの話をしようかというと 今は いいのかもしれないし うちのCIの
机が悪かったのかもしんないけど でも そうだね CIの成熟度という
か もうちょっと公式でどうにかな ってほしいなって思う部分は正直
まだまだあるなっていうところ かな 結構 前もちらっとやりましょう
って言ってくれたんですけど 交換性 とか意識するとなかなかとか
そういう部分はあるんだろうな と思うんだけど とはいえなんという
か ちょっとこの鈴木俊介さんしかり 勇士のなんか知見とかサードパティ
アクションで頑張んなきゃいけな すぎるなって気はするね 個人的
な まあなんかTとかとかなんかいろいろ
唸りたくなるようなトピックも 取り上げて こういうのがいいでしょう
みたいな話とかもいろいろ書いて あって かなり読みごたえのある
スライドだなというのと あとちょっと 個人的にめちゃくちゃそのその
みたいになっちゃうんですけど やっぱり素晴らしいなと思った
のは 結構セキュリティ面以外にも デベロッパーエクスペリエンス
の面でどうなのかみたいな部分 とか あとパフォーマンスメトリックス
アクションズを改善していくに あたってこういうメトリックツール
があるから使うといいよとか そういう部分もきちんと触れられて
いるのは素晴らしいなと思いました ね やっぱそのこの45ページ目まで
のGitHubアクションズのこうしたら いいよ全部やると本当にそのまま
やっちゃうと結構不便になるはず なんですよ そのサインドコミット
強制ってなったらみんなにまず SHP生成してGitコミット設定してもら
ってとか なんでしょうね なんかこういうタグを切ったら
プリティックが自動生成されて ここのブランチに向けて生成したい
みたいなやつをガチガチにやって くださいってなると結構自前で
組むってなるとなかなかしんどい みたいな部分 ある部分に対して
こういうので緩和できるよとか いい感じにできるよみたいな記事
の参照とかがあったりとかっていう 部分とか あとパフォーマンス
部分 最近はその公式がプレビュー で出してるんですけど ユーゼージ
見れるよって話も紹介してくれてる し 逆にそのプレビュー版で満たせない
部分はこういうツール使うといい ですよみたいな紹介されてて なかなか
隙がないスレードなんじゃないですか っていう気ですね 気がしてます
って感じですね GitHubアクションズ を粛清する福井をやりてえな
食っていける
食っていけるだろうね あとは多分 来週 この今日の記事に入ってる
わ 入ってるからそのときに話せば いいけど 直近もサードパーティー
アクションズのそこそこシェアのある サードパーティーアクションズ
が侵害された話とかがあって そういう 事件を考えみると あんまりなんていう
かね 結構面倒だし大変だし言った ように動いてるもの直すっていう
のはすごく骨が折れるんですけど あんまり後回しにできる世界じゃ
なくなってくるというか 後回し にできないと思うんですよねとか
は思いつつ いろいろ思うことある っていう感じですね そんな感じ
です
はい とても勉強になりました
これはチートシート的に思い出せる といいかもしれないですね アクションズ
どうにかしたいってなったときに これ一通り読んで 多分スライド
なんで なぜやらなきゃいけない のかとか 何のリスクに対して抑え
られるのかっていう部分は自分で 解像度上げる必要があるけど 鈴木
静之介さんのブログは多分大体 低くなるから そういうので保管
したり あと鈴木静之介さん以外にも ホワイトペーパーじゃないけど
こういう脅威があって こういう ふうにやるといいよみたいなリファレンス
もちょこちょこあったりするので 調べれば多分ぶつかるので ぜひ
皆さん読んでください
はい
ありがとうございます じゃあ次 お願いします
デジタルフォレンジックのガイドライン
証拠保全ガイドライン第10番です 証拠保全ガイドラインの第10番
が出たらしいよという デジタル フォレンジック研究会なんだっけ
確かに プレスとかなんもなしに このPDFのリンクがリリースにペッ
って貼ってあるだけみたいな感じ だったかな 証拠保全ガイドライン
どこで
デジタルフォレンジック協会
そう ペッって貼ってあるだけなので 何とも言えないんだけど 出たらしい
よという話で さらっと読んできたん だけど さっきお風呂で 大丈夫か
お帰りします
大丈夫です
多分初めて読んだと思うんだけど 結構良かった お世話になる日が
来ないことを祈るわけなんですが Twitterで誰かがツイートしてたの
Xで誰かが投稿してたの見かけて 拾ってきたんだけど どうやらクラウド
サービス周りの話が追加された ぽいのかなとは思うんだけど ちょっと
前回差分とかはよくわからない が 割とお風呂でざーっと斜め読み
する程度だったら すぐ読めちゃう ぐらいなので 1回ぐらい目を通して
おいても損はないのかなと思いました 電源をオンのままにする 切るのか
切らないのかとか オフのものを オンにするのかみたいな話とか
結構細かく書いてあって なるほど なーって思いながら読んでました
ちょっと読んでおこう 良いですね
おだしょー 多分クラウドサービス 周りの話って 多分SaaSを提供してる
側とかも地味に気にしたほうが いいような気がしていて そういう
会社はぜひそこだけでも読んで ほしいなと 個人的には思いました
これだけで全部済むっていうほど すべてが網羅されてるっていう
わけじゃないので ちょっと何とも 言えないですね 多分 何て言ったら
いいんだろうな 結局あれなんですよ ね 複製装置を持ってる持ってない
みたいな 1D 要はストレージの複製装置 とかを持ってる持ってないみたいな
話とか当然出てくるし 意外と 何て言ったらいいんだろうな これ
読んで 明日からできますねっていう ものではない こういう世界があるん
だなと理解するのが大事っていう タグインのほうなんですね
ちょっと席外しちゃって 心配させちゃったんですけど 昔
読んだ本でランサムクリア攻撃 に対するソースハンドブックっていう
のが 欲しいものリストに入ってる わ
本当 そう これを完全に 思い出したというか 今 間末の
多分あれのリファレンスとか書いた 人読んだら やっぱデジタルフォレンジ
業界の人がちょこちょこいたんだ けど まさにこれも似たような これ
は何やろ こっちの本は唐突に本の 紹介始めちゃうんですけど ランサ
ミヤにやられましたってときに どうすればいいかっていうのにかなり
めちゃくちゃ絞って書いてくれてる 本 で 誰に連絡すべきかとか さっき
の電源オンオフみたいな話とか これも何だろうな 一定ラインから
は フォレンジコインやる人向け とかのマニュアル的なものが書いて
あるんで 自分たちがやるかって 言うと そうではないんだけど どういう
感じの物事が進んでいくのかみたいな 部分とか その外観を知るっていう
意味ではいいだろうし お世話になる 日が来ないのがベスト
なんだけど お世話になる日が来て しまったときに 脳内素振りというか
ふわっと素振りができてるかできてない かで全然変わるんじゃないかな
って気はするので そういう意味で 僕は結構ランサミとかした部分
しか読んだことないから これは ぜひ1回目を通したいなって思いました
結構 後ろのほうにツールの 代表的なツールとかもバーッと
紹介されてたりして FTKメッシャー とか懐かしいとか思いながら 今
見てたんだけど あれだね なんなら ここに連絡すれば助けてくれるよ
みたいな 会社のリストとかもあるん だよね
それを知ってるだけでも 途方に くれる前に まずこれをググって
たどり着くとかね いいなって この境界自体を知ってるだけでも
もしかしたらいいかもしれないなと そうだね
いやー これは全然観測範囲がやったな
ちょっと読んどこう ざざっと読んだ感じも 割とぬるぬるっと読めそうな
分量だね ページ数はちょっと多い かもしんないけど でも すぐ読めそう
そうだね そしてあのワーキンググループのメンバーを今改めて初めて見てるんだけど
なんかメンツがすごいね なんか納得のメンツだとは なるほど なるほど
いやー
メンツがいいとやっぱこの成果物も素晴らしいですね
なんかどれとは言わないしどれのことを頭に浮かべてるわけでも決してないけど
なんかやっぱり読みやすいもの読みづらいものある気がしていて
それで言うと結構読みやすい側だなって気がします
そうだね 間違いなくそうだと思いました
ありがとうございます
では次に行きまして えーと まぁほぼオフトピースですね
GoogleのGeminiの影響
GoogleがGeminiのディープリサーチとGemsを無料提供するよーっていう
GDNETさんの記事です
暑いな まぁまだ来てないのかな 多分Gemとかがまだ私のGeminiでは使えなかったので
まだ来てないんじゃないかと思うんだけど
Gemini使ってないなぁ
なんか あのなんだっけ
コーダーシステム無料枠が大きかったりとかして
あーなんかあったね
うん 暑いなーと思ってたけどGoLandで使えないんだよな
あーそうなんだ
なんか使えそうな雰囲気があるんだけど使えないんだよね よくわかんない
いやー完全になんていうか カオスが出てきてないね
カオスっていうかそのプロダクト競争というか
うん
絶対赤字だよね
そうだねー
でもかっこいいコンデじゃないけど
ちょっと使ってみようこれは
チャットGPで使おうと思ったらいくら済んでるって話だよね 月1万とかね
そうだね
そう思うとなんかアーリアダプターじゃないけど
ちょっと大多数にはかなり嬉しいニュースだし
まあ大多数でなくてもちょっと1回触ってみたいですね
いやーいいっすねー Geminiに
ちょっとこのPodcast読む記事もたまにすごいカロリーが高い記事とか
このDeep Researchに加わせてみようかな
っていうのをまさにやったのが次の記事でして
おーそうなんですね
いや違うんだよ うまくいかなかったんだよ
うまくいかなかったんだ
ChromeのManifest V3について
Google Chromeで多数の拡張機能が利用不能に新仕様Manifest V3の影響を考察
っていう これもGDNETさんの記事なんだけど
直近皆さんの手元のChromeとかでも特定の拡張機能が
エクステンションが一時停止されてて
新規でファーミッションが必要だよみたいな通知とかが出てる人とかも
いたんじゃないかなと思うんだけど
多分それがこれの影響なんじゃないかなと思っていて
ManifestがV2からV3にアップデートされましたよっていう話ですね
ちょっとこれの具体の変更点が何なのっていうのを地味に聞いたんだけど
細かいところは分かりませんでしたかみたいなこと言ってきて
ふざけんなよとか思って
横鼻 ちょっとなのでごめんなさい
細かいどういうところ何が具体変わったのみたいなところは
正直ちょっとよく分からなかったんですけど
なので中身が気になりますねという話ですね
なんかこれ系記事何個か出てるけど
ちょっと気になってるのはそんなことないんじゃないって思いたいというか
僕は信頼してるって意味で懐疑的なんだけど
結構広告ブロッカー系のエクステンションがのきなみやられてるから
2024年の詐欺損失の増加
Chromeの人としては彼らも広告事業やってるから
それを理由つけてブロックしたいんじゃないのみたいな
なんか陰謀論かどうかよく分からないのかながいてて
どうなんでしょうねみたいな部分が
Manifest V3の場合は同等の機能提供がそもそもできないのかもね
多分一部のAPIが制限されたりっていう部分があるんじゃないかな
ちなみに今チャットGPTにV2V3の違いを
まさにAPI周りの違いがあるよっていうのはジェミンにも言ってた部分で
リモートコードの禁止とかUI関連の変更
あとバックグラウンドスクリプトがバックグラウンドページがなくなって
全部サービスバーカーになったよみたいな話とかもあったよね
イベントクルーで動作すると
なんかどこが広告ブロッカーに刺さってるのかっていうのは
そうなんだよ よく分からなかったよね
それがよく分からなくてブーンってなってたんだけど
なるほどね
多分だけど
多分だけど
ネットワークリクエスト処理の変更周り
ディクラレイティブネットリクエストAPIへの変更っていうのは
多分でかいんじゃないかなって思ったよね
チャットGPTも同じこと言ってるわ
WebリクエストAPIの制限
広くそのリクエストを取りに行くっていうのが
できなくなってるんじゃないかなと思って
広告ブロックをするのに
どこへのリクエストが飛んでるっていうのを
広く見ようとしたときに
この辺でブロックされてるんじゃないかなとは思うんだけど
V2だと任意のリクエスト同的にブロック変更できるけど
V3だと事前定義したルールでしかブロックできないと
だから明らかに広告のホストを
アドネットワークのホストを
弾きに行こうとしてるのは先に宣言されてるから
ストアにアップロードするときに弾けるっていう感じ
リクエスト解析みたいなのもV3だとできないと
でも難しいね
セキュリティー面で言うとできないほうがいいよね
この辺の変更によって
Chrome拡張に起因したセキュリティーイシューみたいなところが
解消されるのかされないのかっていうのも気になってて
だからちょっとわっとジェミニで調べようとしてみたんだけど
その辺の細かいところは正直よくわからなかった
なんかこれV3だったら大丈夫だったのにねっていうのが
タイミング的にも気になるじゃんね
解像度があるけど
なんかちょっと一個大きな動きとしてありましたよというお話でした
ありがとうございます
じゃあ次いきますか
次お願いします
僕が入れたのか
サクッとかな ちょっと説得できないのでサクッとなんですけど
数字を頭に刻みたい気持ちで読むと
US Government Says Americans Lost Record $12.5 Billion to Fraud in 2024
ブリビンコンピューターの記事ですね
なんか間違ってた
12.5ビリオンドララーズかな
そうそうそうそう
タイトル通りの記事ではあって
2024年に詐欺によってアメリカ人が失った金額が
12.5億ドル
125億ドル
120…これサマリが間違ってた
12.5…ビリオンって言ってたっけ?
10億ドル…125億ドルでいいのか
なんで1兆円近く
うん、合ってるよね
ビリオン10億だもんねビリオンが
ビリオンに15億ドルになるの一緒10億だったら
12億…12.5
10かける…あ、あってごめんなさい失礼しましたあってます
あってます
2本円にして1兆8000億とかになるのかな
エグい金額ですよねっていうところで
なんか円安エグいなの気持ちになった
そうだね
それもしっかりだね
ちょっとなんか何桁か数えるのめんどくさいぐらいの
びっくりした
でまぁそのサマリちょろっと読むと
記録的というか
前年比だから2023年に比べて25%も増えてる
っていうのと
まぁなんか日本も傾向中か
トレンド的には一緒かなと思うんですけど
投資削減が一番多くて
57億ドルなんで
125億ドル中の57億なんで
まぁ40…50%いかないぐらいが
まあ占めてるっていうところ
でえっと
まぁそのさ
あとは詐欺被害の44%が若年層の
20から29歳っていうんで
結構だよね44%が
この世代に集中してる
まぁそうだね全部
あらゆる詐欺を含めたあれだから
何とも言えないんだけど
まぁそうだね
あとは就職詐欺の報告が急増し
損失は4年間で9000万ドルから
5億ドルに増加っていうところも
これは多分
失業率とかその辺が絡んでとかはあるんだろうな
っていうところと
あと僕らがよく取り上げるというか
向き合うトピックであるオンライン詐欺みたいなところは
30億ドルを超える
なんで割合としては4分の1ぐらい
かなっていう感じで
まぁオンライン詐欺の定義がちょっと何なのかっていうのは
詳しく読めてないんですけど
まぁまぁっていうところですね
で
これ自体はその
であれですね
このレポート自体は
米国連邦取引委員会が出しているものなんで
まぁ割と信用できるものである一方
その報告されたり
把握できてるものが
話で
なんでしょうね
まぁ騙されて泣き寝入りしてるような人たち
で把握できないものは入ってないんで
実際はもっと被害が大きいはず
っていうことが書いてあって
んーなんか嫌になっちゃうな
みたいなところも
思ってまぁ取り上げたって感じですね
オンライン詐欺の傾向
125億ドルっていうのは結構
わけわかんない数字だよね
そう
ちょっとね
なんか
2022年
2020年は90ミリオン
ドルだったのが
2024年に501ミリオン
ドル
まぁ5倍
4年で5倍になったって感じかな
日本の
場合はどうなんだろうね
日本
どうなんだろうね
そういうレポート
見てないな
東京都のやつはパッと調べたら出てきたけど
うん
特殊詐欺の
研究率みたいなレポートは出てくるけど
詐欺全般みたいなところは
あれかもな
確かにこの辺ちょっと見てみたいな
うん
やっぱその
日本だとこの詐欺が
流行ってるとか急増してるみたいなのは
見るけど全体傾向みたいなのは
まぁでもその
調査すのも大変だよなこれ
よくやったよな
調査すんの確かにね
うーんその
ね
どっから情報を
むしろ集めてるのかな結構
相談窓口みたいな
通報ベースとかでやってるのかな
うん
そんな気するよね
なるほど
投資詐欺
なかなか
増えてる
そうですね悩ましいなって感じ
ですけど
やっぱ人が一番脆弱だな
っていうところと
本当に
これはお金を取られてる
けどもですねお金以外のもの
僕らは取られるんで
気を引き締めて頑張りたいなってところですね
GitHub Actionsのセキュリティ問題
はい
はいまぁふわっとなって感じです
じゃあ
次行きますか
好きそうなやつじゃんお願いします
好きですね
サマリーも何にも残ってないけど好きそう
ちゃんと書いてます
はいセムグレップの記事で
Popular GitHub Actions
TJ Actions
Changed Files is Compromised
っていう記事ですね
はいでこれ内容としては
タイトル通りであるんですけど
TJ Actions
スラッシュチェンジドファイルズっていう
これは
ギタバクションズの
スタートパーティーアクションズなんですけど
例えばプリリックとかで
これを使うとそのプリリックで変更された
ファイルの差分みたいなのが
いい感じのフォーマットでアウトプットに出るみたいな
便利アクションズって感じ
で割と多分
使われてる
スター数とか
僕も
副業先でも見たことあるし
弊社社内でも見たことあるんで
割と使われるし
多分これをやりたいと思ってググると
大体上に出てくんじゃないかなっていう
そこそこ大手のやつなんですけど
これが侵害されちゃったっていう
話ですね
侵害っていうのは具体的に何が
起きたのかっていうところでいうと
実装のコードの中に
アクションズ実行された
環境内で
取得できるシークレット
ギタバクションズのシークレットの中身を
全部ダンプして外に送信する
っていうものが
起きちゃってたっていうところが一つと
その仕込まれたコード
が含まれるリビジョンを
リリース済みのすべてのタグが
それを参照するように
変えられたっていうのが
目的ってこと
結構割と
結構割と大事件
使ってる人にとっては
これはなんか
まあいいや
これじゃあ原因
何だったのかっていうところで
いうと多分この記事には
追記されてたら
書いてあるかもしれないですけど
書かれたときは
書いてなくて
アップデートみたいなのがあるんで
もしかしたらちょっと読んだら書いてあるのかもしれないですけど
今読めないんで
僕が調べた範囲でいうと
このTGアクションズって
このギタバクションズ以外にも
すごいたくさんのアクションズを
開発していて
多分結構コンティビューターとかメンテナー
見てる感じは個人が
中心になってやってるっぽいんですけど
一部のワークフローの
自動化のために
Botアカウントみたいなのを作っていて
そいつがプロジェクト立てたり
してるっぽいんだけど
そのBotアカウントのパッドが
漏洩したっていうのが
どうやら原因っぽい
そのパッドに
各種のコンテンツライト原型がついてたので
さっき言った
まず悪意のある行動を
混ぜ込むっていうのは
リネグレートに見せかけたプリクラ
一つ立っていて
それをマージっていうのを
していて
コンテンツライトがあればタグの書き換えもできるはずなんで
タグの書き換えも多分それ全部バーってやって
っていう感じ
僕が最後に
その原因自体は
メンテナー本人が
一周で話してたんですけど
最後に見たときはそのパッドが漏れた原因
みたいなのは多分分かってない
で
僕のちょっと
潜入感もあるかもしんないけど
セキュリティの懸念
メンテナーの言いぶり的には
なんだろうな
シークレットでちゃんと管理してたから
どっから漏れたか
分かんないようじゃないけど
なんだろうな
分からんみたいな感じの言いぶりだし
ずっと言わせても分からんって言われたみたいな感じで
でも今はちゃんとしてるから安心して
みたいなこと言っていて
何を
本当に信頼すれば
その原因分かってないの結構気持ち悪いな
って思っている
という感じ
で
あともう一つここに続きがあって
このじゃあパッド
本人は分かってなさそうなんだけど
これ漏れたのレビュー読経由
なんじゃないかっていう記事が
ちょっと後で記事に貼っておきますけど
今日かな
そこが関連してるんだね
そう本当はちょっと来週に
話す記事
日付的には来週話すものなんですけど
繋がってるの話しちゃうと
ビルドックが侵害されたんじゃないかっていうのがあって
具体的に何かっていうとレビュー読の
一部のアクション
レビュー読ファミリーの一部のアクションが
どうやら一定期間だけ侵害されたっぽい
っていうのが見つかって
侵害自体は多分たまたま
何かのアップデートで直ったんだけど
一定期間あったっていうのが
事実っぽくて
その一定期間あったときの期間と
それを参照TGアクションズの
何か社のリポストで参照して使ってた期間
時系列的には
繋がりそうっていうのがあって
レビュー読侵害されました
それをTGアクションズで
多分元々使ってて
そして
脆弱というか
レアが含まれているような行動を実行して
その後TGアクションズが侵害されたっぽい
みたいな感じで繋がってるみたいな
だからどうやら
これが原因なんじゃないかみたいな記事が
今日出てたって感じですね
レビュー読の問題
その相関は多分
究極的には分かんないはずで
本当にパッド化する経由なのか
誰も分かんないんだけど
もしかしたらそういうふうにちょっと
まんまチェーンとして繋がっていった
かもっていう
話の
記事ですね
僕は知ってる全体像はそんな感じっていうところです
もうちょっと明らかになると
嬉しいな
そうね
そうなんすよね
あまりにも何も
分かんないよね
うーん
なんか結構
シークレット2設定してたのは確かに
本当にそれ
でも究極的には分かんないんですよね
そのパッドシークレット2
しか設定してなかったって言ってるのも
分かんないじゃないですか
もしかしたらローカル環境に消し忘れてて
あれは入ったんじゃないのとか
僕ら目線は
もうなんか
そうなんですよね
でもシークレット2に
本当にシークレット2しか入れてなくて
で
ってなると確かにそれを盗めるのって
そのシークレット2を読み出せるワークロードだけから
だからそのワークロードの中に
含まれるサードパーティアクションズに
脆弱性含まれていた
んであればまあまあまあ
ロジックとして成り立つんだけど
まあでもそのギターファクションズの
ログってその一定期間経ったら消えるんで
消えるんで
なんだろうな
消えちゃってたらログから調査することもできないし
そのログも
何もかも
デバッグログから何も出してくれてるわけじゃないし
その外部と通信ログとかも
当然多分出さないように
丸いは作られてると思うんで
ログが手に入ったところで
その後から
そういうこと証拠保全じゃないですけど
裏を取るっていうのは結構
難しいんじゃないかな
ときはしてるって感じですね
伏線回収が走りましたら
処方箋できないんじゃないかな
うん
そうですね
でまあまあまあ
って感じです
一応なんかその
これじゃあ使ってる人全員が
影響を受けたのかでいうと
厳密にはそうではなくて
この
全バージョンが侵害された
わけではないので
まあ該当のバージョン
もしくはその該当のバージョンを
指しているタグを参照した人
が
侵害をかつ
その状態でアクションズが走った人が
侵害を受ける
感じになっていて
具体的にはそのTwitterでも
その
それこそ今音の監督
いろんな人がワイワイ言ってますけど
サードパティアクションズの
参照方法として
指名とかはアウト
だし
タグの
タグだけで参照してるのも多分アウト
なぜならタグも全部付け替えられちゃったから
なんだけどコミットハッシュで指定する
って方法もあってこのコミットハッシュの場合は
アップデートしなければ
セーフだったっていう感じの
状態にはなるって感じですね
でこのなんか
コミットハッシュで指定するのが一番
セキュアっていう話はもう
何年も前から
プラクティスとしてはあって
うん ただね
それをやっててよかったって
なる事件が僕の記憶だとあんまり
なかったんで
なんかやっててよかったっていう事件が
まあ起きてしまったなっていう
気持ちと
弊社はセキュリティチームが
防御策の重要性
2年1年前ぐらいに全部やってたんで
やっててよかったっていう
偉すぎる
いやマジで偉いと思った
そう なんか
やっぱ
この場で行ったか別の場所で行ったかは
分かんないけど起きる事は起きる
起きると思ってる事は起きるっていうのはマジで
結構禁言かもなと思ってて
うん
起きたなっていう
のがちょっと個人的にしみじみ思った感じ
ですね
なるほどね これリノベートとかも
リノベートも
そうだけどdependabotとかも
なんかハッシュしてってサポートしてるの
えっと
僕の記憶だとしてるはずなんだけど
鈴木俊介さんがツイートでなんか動かないって言って
それに対して動きますよって
言ってる会話を見た
多分ね動くはず 動くはず
僕の認識だと動くはず
そうですね
dependabotのアップデートの方は
使ってないんだもん分かんないですけど
GitHub Actionsだけ動かないとか
そういう話だったりすんのかな
分からんけどもしかしたらね
いやでも動くんじゃないかな
なんでそこそこ
自信があってなぜかというと
dependabotのコメントフォーマットと
リノベートのコメントフォーマットが
違った時期があって
なんでその時点で両方動いてて
それがリノベートがdependabotが
フォーマットに寄せて
なんかハッピーだみたいな
話した記憶があるんで多分動くと思う
だよな
ただdependabotの
挙動に癖があるんで
ちょっとなんかまあまあって感じですけど
ちょっとリノベートのコンフィグ
全部これにしようかな
リノベートのコンフィグっていうのは
自分のリノベートのコンフィグを
全部これにしようかな
リノベート使ってる場合は
このコミットハッシュで
フル指定するっていう
ヘルパーがあってそれを1行足せば動くんで
それでいいのと
あとはTwitterでも話題になってましたけど
既存のやつを書き換えるのは
PinActっていう
鈴木俊介さんの
金星のツールがあるんで
それをやれば動くって
いつの間にか
指定がおかしくなってないかっていうのは
鈴木俊介さんのGHA Lintを
使えばチェックできますっていう
なんでもあるじゃん
マジでなんでもあるんだよ
なんでもある
あとは
そもそもだけど
タグの書き換え側のパターンに
関しては
今ImmutableActionsっていう
パブリックベータの
パブリックベータのGitActionsの機能があって
ここで取り上げた気もするけど
それが
GAになれば
解決するはず
っていうのは一度リリースしたものの内容は
どっかコンテナとして
コンポーズされるんで
後から上書きできないっていう仕様になる
文字通りImmutableになるんで
それ使って
まあでも
それで解決するはず
っていう感じかな
ただその場合でも
新しいバージョンで悪になるコードが入る
っていうやつに関しては防げないんで
そこは考える必要がある
って感じですね
いやーいいな
Actionsの発信の後オタクみたいにめっちゃペラペラ喋るな
俺ね
喋ってる
ここ2日すごいもう
体温にちょっと追われてたんで
だいぶ脳内整理されてるって感じなんですけど
うん
まあでもなんかそうっすね
その次期の概要とか対策はその辺
って感じで
あとは悩ましいのは
このサードパーティーアクションズとどう向き合うかみたいなのは結構
悩ましいなっていう気は
しましたね
いやー
そこなんだよな結局ね
なんか
ね
その
まあだから本質的にじゃあ
一緒なんだけど
うーん
ちょっとなー
ちょっと
むずいっすよね
っていうか
今回のとかその個人が
メンテしてるとかも僕は正直
そのいろいろ見て
初めて知ったし
でもじゃあ個人がメンテしてたら悪いのかっていうとそういうわけでもないし
まあでもなー
結構
うーん
僕の中の結論は
多層防御というかもう
抑えられる部分を一個一個
抑えるしかないかなって気はしてて
うーん
使うのやめるっていうのは
ちょっと考えづらいよなーって気はしてて
使うことをやめられる
サードパーティーアクションズも
少なくないと僕は思ってるが
まあゼロにはできない
ってなった時に
じゃあ盗まれるシークレットの数を減らすために
エンバイロメントシークレット使いましょうとか
うん
オルゴエドシークレッツ減らしましょうとか
アクセス絞りましょうとかもあるだろうし
そのシークレッツに突っ込むものに
の権限を
最小化しましょうとか
まああとはあらゆるそこに突っ込まれる
あらゆるシークレットめちゃくちゃ
短命にしとくとかなのかな
クラウドセキュリティの課題
あーそうだねそういうこと
だからそのワークロードアイデンティティ連
Google Cloudとかエドベストのワークロードアイデンティティに
全部ちゃんとしようよとか
うんうん
なんかね
それを割と多角的に聞いてる
まあそうだね
こんだけやられてると
もうやられる前提でじゃあ何ができるんですかっていう
うーん
そうだね
そうなんだよね
うん
まあやられても痛くも痒くもありませんみたいな
状況だったらいいかもしれないけど
ね 業務で使ってる人は
なかなかそんなことはないと思うんだよね
うん
なんで
なんかその伏線回収じゃないですけど
今日紹介したスライドのやつとかは
こういうとこに繋がってくる
かなって気がするね
最適なプロジェクト管理
何個かはここに繋がってくる
いやー
まあでも
なんかいい機会なんで
社内で自慢しようって話は
なんか不謹慎かもしれないけど
してます
雑談ちょっと雑談なんですけど
うん
伏線はねなんかその
もうV1って指定して楽したいじゃん
っていう話なんだけどやっぱね
危ないもん危ないっていう
話でしたね
はい ありがとうございました
これ聞いて
もしやってないっていう人がいたら
まあさすがにそんなことないと思うけど
めっちゃ急いでどうにかしてください
うん
いやでも多分元となるコードはもう消滅してるから
今は大丈夫なのかな
1回リポジトリ多分プライベートにされたか
削除されたかしてて
多分
今時点では起きないはずなんだけど
まあまあ
そんな感じです
はい
じゃあ次
お伺いもうか
はい
クラウドベストセキュリティのベストプラクティスと実装例
っていう
UBIの水谷さんのスライドですね
はい
クラウドセキュリティネイトっていうイベントの
スライドっぽいんですけども
UBIで
文字通りクラウドセキュリティをどうやってるか
って話で
タイトルは結構
その何でしょうね
強いというかベストプラクティスっていう
クラウドセキュリティのベストプラクティスって
めちゃくちゃ広そうだなって感じなんですけど
実際そのうちの一部として
3つ取り上げてくれてる
って感じで
プロジェクト
1個がプロジェクトアカウントの分割で
2個目が長期的に利用する認証情報の
非推奨
3個目がクラウド環境のログの収集保全みたいな
ところを取り上げてくれてる感じですね
あとは
恥ずかしがらなかったので読まなきゃ
と思ったんですけど
クラウドプラットフォーム
それぞれのガイドラインみたいなのが公式から
いろいろ
これ公式なのかな
公式じゃないかな
公式のものもあるし
Manistみたいな参照もあるんだけど
リンクがスライドだとクリックできないんで
どっかから探さなきゃって感じなんですけど
それはちょっと読もうかなと思いつつ
実際の実例も
見つつって感じですね
中身は
ぜひ読んでほしいなと思ったんですけど
個人的に
一番印象深かったなと思ってるのが
その
1個目のトピックであるプロジェクトアカウント分割する
っていう部分で
その
なんでしょうね
いくつか理由が書いてあったんですけど
例えば攻撃者がアカウント取れたときに
その
なんでしょうね
実際の侵害まで
書いてあることに
別のプロジェクトアカウントの権限範囲が
分かりにくくなるとか
権限範囲を限定的にするみたいなことが書いてあって
理屈は全然そうだよねって思うんですけど
じゃあこの分割するのを
どういう
観点で分割するの
ってなったときに
結構その
例えばデータの特性で分割するみたいなことが
書いてあって
データ基盤的なものはデータ基盤的なもので
プロジェクトを切るとか
認証情報とか個人識別
情報みたいな機微な情報を扱うものは
そういうプロジェクトに分けるとか
特殊なワークロードを
持つプロジェクトって書いてあるんですけど
セキュリティ監視基盤みたいなものとか
コンテナビルドイメージの保管デプロイみたいなのは
それのプロジェクト分割するとか
あとはデータ軸以外にも
なんだっけな
結構いろいろ
機能ごとにプロジェクト分割するとかもあって
例えば
コンピュートみたいなクラウドランとか
ファンクションズを配置するようなプロジェクト
データベースを配置するようなプロジェクト
シークレットを配置するようなプロジェクトみたいな感じで
結構多分
ゴリゴリに分割してそう
あとは地域によって分離みたいなのもあって
地域ごとの
地域ごとのレギュレーションに対応するために
JPUS
GLってなんだ
分割してるみたいな感じで
結果として
1500プロジェクトぐらいに
分かれてるらしくて
全部テラフォーム管理してて
やってるっていうので結構
マジかっていうのと
それを変更するときに大変なのかというと
エンジニア認知負荷は
低くないと言ってんのか
っていう状況であるんだけど
いろいろ内製のツールで頑張ってるみたいな
感じっぽいですね
1500プロジェクトの運用
印象深かった話に思うと
1500プロジェクトっていうのが結構
すごい シンプルにすごいなと思っていて
データ軸で分けるとか
ワークロジックで分けるっていうのは
言われてみれば確かに
そうやったほうが楽になる部分あるな
っていうのは結構自分の肌感としてはあって
例えばその
プロダクトで触るシークレットマネージャーみたいなのを
そのプロダクトのGKEの
と同じプロジェクトに突っ込むとか
クラウドランも同じプロジェクトにあるってなったときに
その
うちとかは一部で運用始めてるんですけど
そのプリビリッジアクセスマネジメントみたいな
機能がGoogleクラウドの場合はあって
一時権限付与みたいなのができるんですけど
普段の権限は
めちゃくちゃゴリゴリに落とす代わりに
じゃあ障害対応のときに一時的に
エディター権限30分
申請すれば付与できるようにしようとか
そういう世界観を
目指したり一部したりしてるんですけど
そうなったときに一つの
プロジェクトにいろいろあると確かに
なんか
いやでもエディターつけたらこれも触れちゃうじゃんみたいな
話とか出てきて
じゃあなんかどういう権限設計にするのみたいな
その
同じプロジェクト内にいろいろあるからこそ
あまり雑に設計できないみたいな
部分があって
それが分かれてると
やりやすいかもなっていうのはちょっと
思いつつ
実運用できるのかみたいな部分に対して
できてますって言ってんのは
すごくシンプルにすごいなと思ったというか
なんかできないって言い訳はできない
だなというか
いやー
真似しようって思ってるわけじゃないですけど
ようやっと
なんかちょっとメモとかは全然残してないけど
ざっと読んだけど
まあ
本当にすごいなって思ったし
うん
いやーすごい
これはなかなかできないよな
うん
いやもうなんか
そのSRチームが頑張りましたとか
セキュリティチームが頑張りましたじゃなくて
多分もう開発とか会社として
やったんだろうなって
そのそういう言及があったわけじゃないけど
うん
なんかそれぐらいその影響範囲も大きいし
ドラスティックな意思決定だと思うし
セキュリティっていうのは素晴らしいな
って気はするね
うん
1500プロジェクトですよ
ギター部で1500ディレクターで
多分表示できないでしょ
すごいよね
だからさ
いやー
うーん
いやー
なんか
いやー
うーん
なんか
そうね
何が言いたかったのかちょっとわかんなくなっちゃったんだけど
うん
なんか結局
いやーどうなんだろうな
なんかそのうちの場合は
うん
その割とマイクロサービス単位で
もうプロジェクトが分かれてるので
なんかその
なんて言ったらいいんだろうな
プロジェクトを分けるわけないのを
その判断軸が
マイクで分かりやすいんだよね
それに対してなんか
このやり方って果たしてその
分けるべきか分けるべきでないのか
みたいなところってなんか
本当にその
みんなが判断しきれるんだっけ
みたいなのはちょっと
なんか
確かにね確かに
言いたいことめっちゃわかる
確かになー
どうなんだろうね
その辺の基準の話だったら結構
気になるなー
結構作り込まないとブレそうというか
またその
分割して始めたけどいやめっちゃ不便だわ
とかで
でも後から合流するの大変とか
そういう話は確かにありそう
確かにね
見てみたいわ
1500プロジェクトを
見せてもらえないと思いますけど
面白いね確かに確かに
そうだね
うちもそこそこ
分割1500には
遠く及ばないけど分割してる方だけどやっぱ
結構
慎重に
プロジェクト切るもんな新しく
プロジェクト切るときは
そのコンテキストとか誰が触ることになるか
とか
誰が触っていいのかとか
なんかそのいい理由でさ
分割されてるほど
でも
管理がしやすいってのは間違いない
と思っていて
一方で
どうなんだろうね
分からんけど
この環境でついていける気がせん
そうね
ちょっとビビるよね
うーん
まあ
なんだろうな
一般的な
プロジェクト管理の課題
ソフトウェアエンジニアが
いくつのプロジェクトをまたいで仕事してるのか
みたいなのが知りたいね
確かにね
でも10個とかになり
知らんけど
10個で済むかな1500でしょ
済まんか
1環境10個
DevQAステージプロダクションだっけ
うんうんうん
だからデジ1個につき4環境
あったりするわけでしょ
そうだね
10×4の40とかになるからね
専用のサービステンプレートツールとか
サービスカタログで対応みたいな
話もあるけど
この辺
UBIさんのこの辺内製というか
投資をしまないイメージは
結構いい感じに
いい感じではないかもしれないけど
頑張ってると思うね
いやすごい
ちょっとビビった普通に
1500は
ちょっと別のサイトまた
見てみよう
UBIHubみたいなサイトがあるらしいですよ
すごいな
すごいね
なるほどね
これJPAI
インカイアリードクターQA
プロドステージングプロドQA
やっぱそうなるよね
結構大変そうだな
と思う
ここまでじゃないけど
うちも近しいダッシュボード
みたいなのはある
これに近いダッシュボードあったりする
さっきのUBIHub
扱う情報の機密性の
高さみたいなところに起因して
取れるトレードオフでもあるのかもね
もしかしたら
国が多いっていうのもあるよな
リージョン3つあったら掛け算だもんね
それ
実体としてグルーピングしたときに
いくつになるのっていうのは
1500プロジェクトがあるのは分かった
確かに確かに
実体として500個あって
それの
バリアントチェック
リージョンだったり
アクションデベロメントみたいな
種別で
分かれるものがいっぱいあるっていうような
話なのか
それとももうちょっと実際多くて
みたいな話なのか
非常に気になります
面白いな
マルチクラスターなんだね
なるほどね
よくやってるわ
フェーズを考えると
すごいね
1000人ぐらいの会社がやるような
話
分かんないけど
この規模でできるんだって感じだよね
面白いわ
配信の遅延とリスナーへの影響
全然気づかなかったけどこれが最後でした
本当に?本当だ
サクッとでしたね
サクッと
1時間はサクッと
デッキいいのか分かんないですけど
2倍再生だと30分ですかね
お疲れ様でした
これいつ出るんだっけ
これいつ出るんだっけ
早くて来週か
そうだね
今週頑張りたいけど
約束はできない
いつかしたらいいぞ
うん
今配信が遅延気味なんで頑張ります
3月忙しくてですね
なるべく早く配信したいんだよ
鮮度がね
ティージアクションズとかさ
影響範囲の方はご注意くださいとか言ってさ
3週間後に聞いても
なんでやねんって
確かにね
全然それでいいと思ってるけど
確かに
出たよって言うので
自分で聞き返してると
あれちょっと古いなって思う
そうだよね
あんまりない範囲で
楽しみにしてくださってる皆さん
これを皆さんにお届け
するのが
4月になってるのかなってないのかで
なんか
どうなのかなって
それ3月には絶対大丈夫
今週は厳しいけど
厳しいか厳しいかもしんない
だから次回ですね
はい
またお願いします
じゃあそんな感じで
今週もありがとうございます
来週もお楽しみに
ありがとうございました
おやすみなさい
