#28 願わくばサービス側がセキュアになってくれれば…の回

00:00

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

こんばんは。

悲しい悲しいヤギ足くん、今日は…

キーボードをブンチンカーさせました。ついさっき、30分前ぐらいにブンチンカーさせました。

プロのセキュリティエンジニアだというね。

メルカリで買ったばっかりなのに。

怒りのヨドバシで新品注文かましたね。

くっそ、普通に出費が痛え。

ブンチン。

普通に出費が痛え。

いろいろね、欲しいものあるんだよな。そのお金があったらあれ欲しいなが、普通にちょっと頭の中に浮かぶのが普通にしんどい。

なるほどね。そういう悔しさか。

うん。

ま、確かに。

いやー、直んねーよなー。

なんか、そういうスラックないかな。わかんないけど。

なんかもう、バラしてもいいから直してくれませんかね。

なんか直んなくても何も請求せんからみたいな感じで。

うん、直ったらあげるよそれって。

え?

惜しい。

新品買っちゃったしね、それと言って。

あー、まあ確かにね。2台あるに越したことない。

別になんかジャンクでどっかに流せばいいんだよな。

まあね、それはそう。

なんかなー、どっかに、なんか謎の需要ありそうだけどな。

どうだろうね。

うん。

あ、キースイッチとかはなんか使う人いますかね。

あー、そうね、取り外せるなら全然。

うん、キーキャップとかね。

うんうん。

手元に持っといても良さそう。

はい、僕は眠いです。

何の報告って感じですけど。

本当ですね。

起きてください。

せーの。

今日もやるよ。コツコツと。

はい、やりましょう。

まあちょっと記事がね、少ないから。

ぬるっと。

ぬるっと読めますか。

でもなんか意外と良い記事が多い感じがするな。

いい感じに知ってる。

なんか日本語でも英語でもないやつ知ってない?

あの、フランス語です。

フランス語なんだこれ。

なぜフランス語なのかはちょっとお楽しみにということで。

あー、なるほどね。はいはいはい。

要拾ってきたね。

あの、あれです、前多分、

あー、このポッドキャストで話してた。

まあ、そうだね、ご実談的なね。

そうだね。またなんかそのリスキーウィズっていう、

僕らと多分同じことやってる海外のポッドキャストの、

記事バージョンもあるんですけど、

なんかそれを読むようにしてて、

それが、それでキャッチできたって感じかな。

はいはいはい。

それのカバリッジがめちゃくちゃ良くて、

うん。

なんかハッカーニュースとかリビングニュー、

コンピューター読むのやめようかなってちょっと迷ってるぐらい。

うんうんうん。

まあまあそういう余談もありつつ。

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

あ、私か。

クッキーのセキュリティ強化

クッキーの安全性を高めるHTTPオンリープレフィックスの提案しよう。

あすのかぜブログさんの記事です。

はい。

えーっと、

ちょっと今ね、本当に申し訳ないんだけど、

なんかタイトル読めばもう分かるでしょ、

説明めんどくさってちょっと思ってしまった。

まあでも、そうではある。

記事自体もね、2分あれば読めるぐらいの分量だし。

HTTPオンリーおよびホストHTTPオンリープレフィックス、

要はクッキーネームのそのプレフィックスがありまして、

それの新しいのを提案する、定義する提案だよっていう話です。

で、HTTPオンリーのほうがHTTPオンリーかつセキュアでなければならない、

セキュア属性がついてなければならない、

ホストHTTPオンリーっていうのがHTTPオンリーかつセキュアで、

かつパスがスラッシュで、

ドメインがないっていう状態でなければならないっていう仕様でございます。

で、クッキーにはクッキーネームプレフィックスっていう仕様がありますっていうのが、

記事の中でも書かれていまして、

もうそろそろRFCになりますって書いてあって、

なおすでにブラウザに実装されてますってなってるんですが、

RFCになってなかったのを僕は知らなかった、すいませんって感じなんですけど、

もともとセキュアとホストっていうプレフィックスが普通に使える、

ほぼ普通に今使える状態なんですが、知らなかったですか?

そうなんですよ、コメントに書いてあったんですよ。

知らなかった。

恥ずかしながらこの仕様知らなかった。

意外と知らない人多くて、私も知るの結構遅れた側の人間で、

多分2019年とか2020年あたりに知った気がする。

サファリが対応したのがそのあたりっぽいので、

ちょうど天気で使われだしたとかそんな感じなのかな、わからない。

なるほどね。

ちょうどそのあたりでメルカリが使い始めたんだよね。

はいはい。

これもうほんとちなみに、

こうやって今ついてなかったらウケるけど。

勉強してこいオブザイヤーって言われるんですけど、

これを使う嬉しさは、

あれですよね。

これらを、一時期版オンリーとか、

セキュア属性か、

を付け忘れるのを、このプレフィックスを付けることによって、

漏れなくできるのが嬉しいって感じなんですよね、多分。

ちょっと待ってね。

いや、もうちょっとややこしいんだよ。

なるほど。

もうちょっとややこしくて、

どう説明したらいいんだろうな。

なんかさらっと説明してくれてるやつないかな。

フラットセキュリティの基地とかがいいんじゃないかな。

なるほど。

ホストプレフィックスについては書いてくれてるんだけど、

要はなんて言ったらいいんだろうな。

ここの例で上がってるのは、

中間者攻撃によって書き換えられたレスポンスで、

サブドメインから上位ドメインのクッキーに対して、

クッキーをセットするようなシナリオ。

要はなんか、ものすごいふわっとした言い方になるんだけど、

クッキーをセットできるのって、

正規のサービスに限らない、

ここでいう中間者攻撃とかもそうだし、

XSSとかでもそうだし、

という問題がまずありまして。

HTTPでアクセスさせてしまえば、

その時に任意のクッキーをつけたりできるわけじゃないですか、

中間者攻撃とかで。

という時にセキュアプレフィックスとかが付いてると、

ちょっと待ってね、複雑なんですよ。

意外とややこしくて、

セキュアプレフィックスが付いてると、

セキュア属性がまず付いてないといけないじゃないですか。

HTTPのコンテキストにおいては、

セキュア属性付きのクッキーをセットできないと思うんですよね。

今の仕様って。

ゆえにセキュアプレフィックスが付いてれば、

任意のクッキーを植え付けるというのが成立しなくなるんですよ。

TLSで守られてる限りは。

ホストも似たような話で、

任意のサブドメインから上位ドメインに対して

クッキーをセットするとかがクッキーの収集できてしまうので、

という話だったはず。

ちょっとややこしい。

なるほどね、理解した。

ごめんなさい。

そっちに話が及ぶと思ってなかったから、

さらっと説明できる状態になってなかったけど、

そういう話です。

試したみたら申し訳ないけど。

直感的に理解したの結構難しい話であって。

フラットセキュリティさんの記事めっちゃいいね。

ちょっときちんと読み込んでおこう。

なるほどね。

という話が多分MDNのページとかにも書いてあるんじゃないかなと思うんだけど。

ホストにもお話があるんだよな。

そうですね。

それのHTTPオンリー版を作るよっていう話なんで、

さっき言った例えば、

XSSとかで設定できないって話になるんじゃないかなと思うんだけど、

どうなんだろう、よく分からんな。

確かにね。

基本に場合はどうかっていうと、

まあでも基本は同じなのかな。

何かしらの方法でHTTPオンリー属性を外して上書きをするっていうのが、

もう原理上できるっていう話ですよね。

どういうシナリオっていうのはちょっと具体的には思いつかないけど、

まあまあ話としては別に特にトレードオフもなく。

そうだね。

あとは前提として多分頭に置いておいていいのは、

クッキーってセットクッキーヘッダーでしか、

このセキュア属性とかドメインとか露出しないんですよね。

要はクッキーヘッダーでクッキーを送られてくる側、

バックエンド側って、

そのクッキーがクライアント側でHTTPオンリー付いてるのか付いてないのか、

セキュア属性付いてるのか付いてないのか、

ドメイン属性付いてるのか付いてないのかって分かんないんですよ。

っていうところでこのプレフィックスが付いてることによって、

ある一定の状態がクライアント側で担保されてるよっていうのが分かる確実にできる。

なるほどね。

利点があるっていう中でのこのセキュアだったりホストだったりHTTPオンリーだったり、

ホストHTTPオンリーだったりっていうのが今出てきてるっていう風に理解してもらうのがいいのかなと思います。

大前提はやっぱりそこ。

完全に理解した。なるほどね。面白いな。

これ、多分使わない理由ってあんまないよね、おそらく。

使わない理由ないですね。

使わない理由ないし、クッキーの名前が変わっちゃうのでちょっと厄介ではあるんだけれども、

移行がちょっとめんどくさい部分はあるんだけれども、やらない理由がない。

し、別にこれによって何かが壊れるとかって基本的にはないので、

クッキーの名前にプレフィックスがついてるだけだから。

かつ、これでしか防げないものが明確にある。

要はクリックジャッキングに対しての対策がX-Frame OptionsかCSPのFrame Ancestors Directiveのどっちかしかないよっていうのと一緒で、

これもこれでしか防げない、何らかのシナリオがあるっていうのが明白なんで、

使わない理由は正直ない。

なるほどね。これ知らなかったな、ちょっと。

別にしかもこれついてて非対応ブラウザとかが入ってきても、それによって壊れることないので。

今手元で見たらNotionはプレフィックス使ってないけど、Google Mapsとかはセキュアプレフィックスついてる。

なるほどね、ってなってるわ。

なるほどね、覚えておこう。

これ、何で知らなかったんだろうな。

しかもね、メルカリ、これローカルストレージか、クッキーはさすがについてるよね。

メルカリはついてるわ。

ほんとだ。

いやー、ギーム教育で教えてほしかった。

意外と知らない、知られてないし、さっきも言ったけど、僕も遅れて知った側なんで。

何ならメルカリで確か誰かがつけてて、ボッって思ったんだよな。

どういうコンテキストで知ったのかも忘れちゃったけど。

なんか、フレーマークのレイヤーとかで集中してくれたらいい気もするけど、

まあでもクッキー名自分で決めるのかな。

なるほど、勉強になりました。

いやー、難しいな。

いや、なんか、どこで学ぶべきだったのかと、こういうので知らないのまだあるんだろうなって思うと、深いなっていう。

いいんじゃないですか、こういうポッドキャストで。

そうだね。

知っていけば。

そして俺がまた流行らせるぞ、流行らせるというふうに布教していく。

まあぜひ、やってほしいですね、俺は。

ありがとうございます。

はい、じゃあ次いきますか。

いきましょう。

OSVスキャナーV2の紹介

アナウンシングOSVスキャナーV2。

Vulnerability Scanner and Remediation Tool for Open Sourceっていう、

Googleセキュリティブログの記事ですね。

OSVスキャナーのV2を発表しましたよっていう記事です。

ちょっとごめんなさい、僕中身読んでないなこれ。

読んだ?

ふわっとしか読んでない。

そういえば読んでねえわ。

OSVスカリバーが出たときの記事でも研究されてて、

統合していくよみたいなことをそっちの記事でもともと言ってたんですよね。

両方触りたいなと思ってるんだけど、まだ時間取れてなくて、

有給消化中にでもやろうかなって思ってます。

そうですね。

持ってるのでオプシディアンにメモが書いてある、もうよし素晴らしい。

これも試したいなという気持ちと、

これ認可ってくれてるのか、前に読んだときのやつも。

そうだね。

確かそうだね、前のときはスキャナーとSボムとか生成するようなものが別々だったんだけど、

V2になって統合してより便利になったよって話かなっていうところですね。

なので、ぜひ使ってみてねっていう気持ちというか、

ぜひ使いたいなってシンプルに僕は思ったって感じですね。

HTMLとかはっきり出すようになってるし、どうなんでしょうね。

実運用でどう使うか、便利だな多分間違いないんだけど、

ちょっと手触り感というか触ってみないと、いつどういう場面で使えると嬉しいかとかは、

ちょっと分からんかなっていう気はするな。

あんまり話題になって、自分のTwitterとかでは見かけないだけだけど。

あんま見かけない、確かに。

そうだよね。

どうなんでしょうね。

こういうのを使って内製頑張るより、スニークとかを使ったりとかそういうのをやってたらあんま縁がないだろうし、

でもどうでしょうねって感じだな。

ITメディアの記事とかではちょっと取り上げられたりしてるな。

一部では多分、キャッチしてる人はキャッチしてるんだろうね。

あとは依存関係とかを管理しなきゃいけないようなポジションとか、

ポリシーみたいなものがある人とかは結構見たりするかな。

Twitter検索してるとかですね。

ITメディアの記事もめっちゃ出てくる。

はい。

ありがとうございます。

まあまあ下がってる感じかな。

では次は…

お願いします。

はい。

Devynを用いたセキュリティ対策

Dependabot…間違えた。

Devindabot。

デビンで実現するライブラリーの…

素手間違い。

自動対応システム、フリーのデベロッパーズハブですね。

地面がね。

言い間違いがもはやネタバレではあるんですけど、

そのDependabot運用を皆さん日々勤しんでる。

リノベートの方もいるかもしれないですけど、

勤しんでると思うんですけど、

いわゆるセキュリティアラートが上がってきて、

それに対してDependabotで手動でも自動でもいいんですけど、

プリリック立てて、自動で立てて、

マジしたらパッチが当たるみたいな仕組みがGitHubにはあるんですけど、

その仕組みは素晴らしいものの、

やっぱ考えなきゃいけないこととしては、

いつ誰がレビューしてマージするのとか、

レビューするときに何の観点を持ってマージするのとか、

物によってはブレイキングチェンジが入ってないかとか、

パッチの内容に応じてコードを変えなきゃいけないかとか、

結構いろいろ考えることがあるよねっていう感じなんですけど、

それに対してDevynを使って、

もろもろのプリリックの変更内容の分析とか、

対応の推奨とかをやっています。

やっているっていうような記事ですね。

これ前も別の会社でしょ?

なんかね、あったよね。

脆弱性じゃないんだけど、

普通にパッチ的用の話でやったと。

そっちはそうか。

これは割とセキュリティアラートに効果してて、

かなり詳しく書いてあるんで、

ぜひ詳しく読んでほしいなって感じなんですけど、

面白いなというか、

弊社もDevynにトレーヤー中なんですけど、

まだ僕もDevynに免許中で知らなかったのは、

ある程度なんだろうな、

プリリックできてから、

マージまでこういう流れでやるみたいなものを決めて、

それをプロンプトに落として、

あとはそれをどう回すかみたいなところで、

普通のDevynの使い方って、

例えばスラック上でこのプリリックレビューしてみて感じで、

プロンプトぶん投げてとか、

プロンプトはテンプレ的な感じで用意して、

マジックコマンドとかで呼び出すようになるんですけど、

この記事ではいわばアラートを見つけて、

対応していくっていうのを繰り返しやるために、

DevynのAPIを叩くっていう方法を紹介していて、

この方法自体はDevynを開発してる会社が紹介してるらしいんで、

それ通りにやってますっていうことが書いてあって、

なるほどなというか、

それやればかなりほぼほぼ自動化というか、

だいぶ楽できそうだなっていうところと、

あとは何だっけな、

記事の最後に書いてあるんですけど、

Devynの指摘みたいなところの正しさが、

今のところ脅威の妥当性か、

指摘の正しさ、妥当性は脅威の100%ですって書いてあって、

これは結構すごいなというか、

もしかしたらプロンプトの精度がいいっていうところもあるのかなと思いつつ、

かなり良さそうだなって気はしてるので、

まるっと真似したいなと思ってですね。

で、稼働コストも1アラートあたり約700円っていうところで、

全然ペイするんじゃないかなと個人的に思うので、

真似したい、とか真似しようと思ってますって感じですね。

プロンプトかなりまるっと書いてくれてて、

いやー素晴らしい。

そうだね、助かるよね、そのまま。

これは良いな。

ちょっとこれ体験したいな。

そうだね。

かなり良いんですよね。

僕は特別指摘になったのはそのあたりかな。

いやー良いね。

そのセキュリティーの、やっぱりリノベートしっかり、

もう僕は慣れちゃったんで手癖でぽつぽつこの作業やれるんですけど、

やっぱみんながそこまで至れるかというと、

あるあるはリノベートマージマンが何人かいてその人たちに依存するとか、

ノウハウみたいなのをちょっと言語化しづらいみたいな部分多分あって、

何だろうな、何でしょうね、僕が普段見てるNode.jsのパッケージが多いんですけど、

こいつはマイナーアップデートでブレイキングチェンジたまに入れるからリリースノートちゃんと読むとか、

このライブラリーはCIも壊さないしプロダクションも壊さないから、

カジュアルマジシティみたいな暗黙の自分の中の知見みたいなのが、

やっぱりやってくと身に付いてきて、身に付くから自分の作業が速くなるんだけど、

他の人の作業も速くなんないというか、悪循環に落ち入りがちというか、

今までだとじゃあそれどう解決するのかっていうとあんまり銀の段がないイメージで、

すごい昔に会社名忘れたけど、その辺の課題解決でも強い意志で当番制にして、

ぐるぐる回して暗黙値を文書化してみたいな、でコツはやることみたいな、なんていうか、

やっぱもうやるしかないみたいな部分がどうしてもあったんだけど、

こういうふうに丸投げできるようになるとその辺を丸っと考えることもあるし、

なんか開発者がやることはDevinがいい感じに翻訳したものをレビューしてマージしたり、

あとそのコード修正も多分いけると思うんだよね。

ここで触れられるとかちょっと分からないけど、なんでかなりいい世界なんじゃないかなと思いますね。

いいなぁ。

フリーのピーサー統合チームはやっぱ面白いっていうか、いいっすね。この辺もちゃんと手を出してって感じ。

Devinの稼働コストが1アラートに対して2ACU、700円くらい?

うん。

700円か。

なんか判断難しいんだけど、

難しいね。

まあでも、慣らしたら安いんじゃないかな。

まあね、物理やって結構かかるもんな。

そうそう、ブレイキングチェンジが混ざってて、ちょっとアップデートノート読んだりドキュメント読んだり、

修正して試合回ってコケて、みたいなとか、

いやーでもさ、このガチの時間単価で比較されるの普通にしんどいな。

なんか人間としては結構しんどいな。

それはそうね。

いやー、経営目線はね、人件費とどっちが安いかっていう、

自分たちもその目線を持たなきゃいけないんだけど、

こういうのが当たり前になってきたら、これを手動でやること自体が悪みたいな、

悪みたいな、ちょっと悪くなるよね。

Devinの方が安いのになんで手でやってるんですかっていう話になってくるはずで。

Devinにできない高単価な仕事に向き合っていかなきゃいけないとか、

あとDevinに束ねてやっていくみたいな感じなんかな。

やりましょう。

じゃあ次、これはどっちでもいいけど。

お願いします。

じゃあやります。

GitHub Actionsの問題

GitHub Actions Supply Chain Attack Review Doc Action Setup with Blogの記事ですね。

先週話したTJ Actions Changed Filesの侵害の件と繋がってるやつの記事なんですけれども、

おさらいに向かって全体図を話すと、

TJ Actions Changed Filesにマリアとか悪いなコードが仕込まれたって事件が先々週の金曜、日本の土曜日か、にあったんですけど、

その侵害された原因みたいなのは、真の原因はもうちょっと100%の制度ではもう神の水と知るって感じなんだけど、

withのブログ、これとこの一つ前でもそうかな、

レポーティングされてるのが、TJ Actionsのどっかしらで動いてるレビュードックアクションのアクションセットアップっていう、また別のアクションズがあるんですけど、

そのアクションズの中に一時期悪いなコードが仕込まれていたことがwithの調査で分かっていて、

その話を書いてるブログっていう感じですね。

なので、認識すべきはそのレビュードックアクションセットアップ、もしくはブログに具体的に何個か書いてあるんですけど、

このレビュードックアクションセットアップを内部的に使ってる、また別のレビュードックのアクションズが何個かあって、

その辺の任意のバージョンをコミットハッシュとかで指定せずに使ってた人とかは、ちょっとちゃんと確認しておいた方がいい。

5個ぐらいかな。

なので確認しておいた方がいいっていうのと、またこのブログに書いてないけど、そうですね。

ヤギ足が補足してくれてる。これ追記は記事中にあったのかな。

多分そうだと思う。

そうなんですね。

記事中の、そうだね。新たな追記で、うわ書きされちゃってるけど、あった。

でもあるね。途中にあるね。

3月19日のアップデートで。

2つ追記があって、1つがレビュードックアクションセットアップがなんで侵害されちゃったのっていう部分がレビュードックの1週間でアナウンスが出ていて、

これちゃんとめちゃくちゃきちんと読んでないんですけど、

確かというか、レビュードックアクションセットアップのコントリビュート権限みたいなものを言って、

割と緩めの証券、多分何回かプリリック出してマージされたみたいな証券で貢献したら、

アットレビュードックアクションズメンテナーっていうチームがあるんだけど、それに自動で追加するような仕組みになっていて、

その中身自体は多分頼まわしとかしてなかったんで、

118メンバーがそこにいるっていう状態。

一定の権限を一定のコントリビュートしてくれた人に自動で渡す仕組みっていうのがずっと動いていて、

で、その中に多分悪い人が混ざっちゃってたっていう話が原因ですっていうところを、

はやぶささんが公式として出してくれてるって感じですね。

で、今はこの仕組み自体は止めてるはずで、っていうところなんですけど、

そうですね。

まあなんていうか、難しいというか、

個人的には、分かるというか、OSSをメンテする側の気持ちとしてはやっぱこれだけシェアがあって、

レビュードックファミリーというか、メンテしてるの一個だけじゃないんで、コントリビューターも多くあって、

最近のサイバー攻撃の考察

はやぶささんがメインコントリビューターだとしても、チーム的なところでメンテしてないっていうのを考えると、

この仕組み自体を一概に非難はできないなという気持ちと、

5年前だったらそんなにならなかったけど、

今はこういうのはちょっと危ないんだろうなという一つの判例として、

ありますよねってところが厳しいなっていうことを個人的に思ったりっていうのと、

あともう一つ追記があったのは、このコギー自体はTGアクションズチェンジドファイルズを経由して色んなものを盗もうとしたっていうものよりは、

そのコインベースのアクションズがTGアクションズチェンジドファイルズを使ってるんですけど、

こっちを狙ってコインベース側のサービスの認証情報とかを抜こうとしたんじゃないかっていうのも追記としてあるって感じですね。

割と標的型というか、狙い撃ちして実行したんじゃないかっていう考察が出てる。

あと攻撃者の実像もちょっと分かってなかったけど、多少活動時間帯的にヨーロッパの人っぽいみたいなぐらいの元気とか。

別の記者だったかな。

いや、面白いな。

ちょっと見ました。

面白いな。すごいな。そこまで掘りに行くのが。

フランス語と英語を話すことが分かっていて、ヨーロッパかアフリカの多分ワークタイムの人っぽいっていうのが書いてありますね、ウィズムの中に。

そうですね。

そこまで掘りに行くの、本当に面白いね。

どういう、なんかすごいね。

傾向というか。

アンゴ通貨ですかって気持ちですけど、まあまあまあ。

ああ、そうじゃなくて、英語とフランス語を話しっていう。

ああ、そうね。

どっからどうその突き止めたかはちょっと思ってないんですけど。

ああ、ギッターブか。攻撃者のギッターブアイデンティティまでたどり着いて、そいつの挙動的にってことっぽいな。

面白い。

まあでもこのコインベース狙ってたから、うちは使ってたけど安心っていう話では全然ないので、まあ捉え方は多分あまり変わんないというか。

個人情報保護法の重要性

私、レビュードックとティージアクションズを使わなければ大丈夫って話でも全然ないんで、まあまあ。

そうね。

向き合い方は先週話した通りかな、気はしますね。

いやー、なんか個人的には自分がセキュリティの仕事をしてる間にこんなに身近にちゃんと影響を受ける事件が起きるとは思ってなかったわけじゃないけど、起きたなーって気持ちがありますね。

ちょっと頑張りますって感じですね。

はい。

みなさんぜひもう一度お願いします。

はい。

次が、基礎から学び直す個人情報保護法と最新の実務対応っていう。

えーと、これリークトでいいのかな、読み方って。

うーん、わからん。

リークト、リークト、リークトってことにしましょう。

読み方。

違ったらすいません。

読み方。

うーん、読み方がわかんねえけど。

L-E-A-C-T。

うん。

はい。

導入事例にかわしき会社10Xさん入ってる?

あ、入ってる?

あ、じゃあ言えるわ。

あの、そうです、あの、お世話になってますこの方実は。

なんならこのスライド読んでめちゃくちゃいいやんと思って、その会社のスラックにこれ紙記、紙資料ですって貼り付けたら、この人お世話になってますって言って、え?ってなった。

しかもなんならねも、なんだっけ、まあいいや、はい、そのお世話になってます。

はい、はい。

どういうスライドでしょうか。

はい、っていう、えっと、話が飛びすぎてもう完全に頭から飛んだけど、えっと、のセコさんだったよね、セコさんの記事です、記事じゃないスライドです。

えっと、まあ一応なんか弁護士向けっていう風に銘打ってるんだけど、まあそんなに難しくなかったんで、まあぜひ読んでみてほしいなと思いつつ、その、なんて言ったらいいんだろうな、えっと、割と皆さんが仕事の中で関わるその個人情報がみたいな話に、え、まあなんて言ったらいいんだろうな、その、かなり近い部分の話だと思っていて、

なんかこの辺理解してないとなかなかしんどい側面があるよなという風に読みながら思ってましたというスライドでございます。

はい、まあ例えば個人情報保護法ってなんで難しいのって、日常用語とまず乖離があるよねとか、あとは、え、まあデータベースとかの技術的理解だったりとか、広告領域だったらクッキーってなんなのとかは理解してないとダメだよねって話とか、

あとは、え、個情報そのものにその超重要な情報が書かれてなかったりする、ガイドラインとかまで読みに行かないとわかんないみたいなのがあったりとか、え、裁判例が少ないよねって話とかを書いてくれてるのと、あとは個人情報と個人データの違いって何ですかみたいな話とか、なんかそういうところの、なんていうか、まあようわからんところまで触れてくれてるような感じですかね。

はい。で、あとはよくあるその、なんて言ったらいいんだろうな、その個人データの提供の種類、えっと、まあ関わってるとなんかもう常識なんだけど、その第三者提供と委託と個人データを取り扱わないことになってればいいっていう3種類、まあいわゆるクラウド例外とかみたいなやつ。

で、えっと、まあ3種類あるよねっていう話とかを書いてくれていて、この辺はなんか理解してないと多分話が通じない部分が結構あると思っていて、うん。なので、これは第三者提供になってるんでとか、これは委託に倒してるんでみたいな話とかが、まあよく出てくるんですよね、この辺の話をする中で。

なので、この辺はなんか理解しておかないと、なかなか今だけ厳しいよねっていう話があるので、まあぜひ読んでみてほしいなとは思いました。うん、とってもおすすめです。

法令への理解と学び

まあちょっとだけなんかプライバシー関連に足を踏み入れたおかげか、これを自分で説明することはできないんだけど、読んでて理解ができるのは良かったなって思いながら僕は読んでました。

いやー、めちゃくちゃ、めちゃくちゃ良かったです。わかりやすかった。

いや、なんかこの、あの、まあその、なんだろうな、この人の、多分この人の表現力というかその、うん。

プレゼン力なんだろうなって思うけどその、やっぱ法令って、なんか普段読まない意味からするとその法律の文章ってちょっとアレルギーとまでは言わないけど、頭に全然入ってこないというか、うん。

漢字とかその言葉はどう解釈せばいいんだろうとか、なんか結構難しいなって思いながら読むことがあるんだけど、そのこの人のこのスライドでは、じゃあこの情報について見てみましょうみたいな、

まあこのままとややこしいから、じゃあ一旦この3、3文節だけ抜いて、これはどういう意味なんですかとか、なんかかなり分解して丁寧に説明してくれていて、うん。

だからめちゃくちゃわかりやすいなっていうのと、またなんか弁護士目線も結構やっぱ難しいから、こんぐらい僕が理解できるぐらいまで噛み砕いて、そのインプットした人は、というか需要はあるんだなっていうのはちょっと素直に、うん。

弁護士にとっても本当に難しいんだなっていうのを、意外とまでは言わんけど、それぐらい難しいと思って向き合ってるなっていうのはちょっとしみじみ思ったりしたな。

確かにデータベースね、データベースわかんなかったらそうだねみたいな、途中でつまづくのは確かに読み進めてるな。

ネットシートしか知らない、Excelしか知らないっていう人たちにデータベースの概念を説明するのって確かに結構難しいなとこれ読んで思った。

難しいと思う。なんかユーザーIDでその名前を引っ張るとはみたいな。

なんか正規化とか正規系とかも普通に理解してるけど。

そうだね。そうだね。

理解してると言っていいのかちょっと自信はないけど、理解は普通に使ってるし、なんか。

いやー、でもこれめちゃくちゃ勉強になった。めちゃくちゃ勉強になったのとやっぱその、いやー大変だけど一回個人情報保護士のテキストだけ買って勉強時間取れてないんですけど、なんか一回ちゃんと勉強したいなって気持ちになったな。

6月じゃないですか、次。

6月か。3回ずつ。

5月8日までが締め切り。

ちょうどいいかも。

これどれくらい難しいのかな。

分かんないけど、ソフトエンジニアで取ってる人いる?

上級個人情報保護士とかあるんだ。面白い。情報セキュリティ管理士とかも一緒に紹介されてる。

なんだ情報セキュリティ管理士って。初めて聞いた。

それは知らんな。上級とかも分かんないな。個人情報保護士は公式テキストがあって、まあまあ多分それをIPAの試験みたいなのに勉強していけばいいのかなと思ってるけど。

合格率41.5%。

結構低いな。

問題数100問。合格基準は70%以上。

合格率70%。

有効期限あるんだ。

まあ法律が変わるからね。

その割には2年でしょ。3年ごと見直しな。

そうか6月か。ちょっと頑張るか。締め切り行くと。

はい、まあまあまあ。

はい、じゃあ合格期が7月ぐらいに出てくるって言った。

この資料のおかげで合格しましたって。

いやー、嬉しいな。こんな紙資料作った人がうちをサポートしてくれてるのかと。

なんかさっき思い出さなかったんだけど、スライド投稿して実はうち手伝ってますよの1回目マジカと、別の人がこの人うちのスラックにいますよってセカンドマジカがあった。

なんか直接感想を言いに行ける。実は。

ゲストチャンネルに行くよ。

いやー面白すぎる。

世間狭いな。

狭すぎる。

えー、大好きテキスト。

いやー、ちょっとやってもいいけど。

いやでもカロリー高そうだなと思う。なんかそのIPAの試験とかとはまた別というか。

そうな気がする。

はい、まぁちょっと感想お待ちしてます。

頑張ります。

今年はいいかな。

次行きますか。

はい、行きましょう。

はーい。

お願いします。タイトル読めんのかしらけど。

タイトル読めないんでこれちょっと翻訳しますけど、なんだろこれ、なんて読むんだろ。

あの、冒頭に言ってたのフランス語の記事ですね。

冒頭言ってたよね。タイトルが読めない。

直訳すると国会は不安の夜に暗号化されたメッセージの機密性を維持することを決議。

まぁなんか多分ちょっと早すぎ。

メディアのタイトルだからその海外特有の。

英語に訳してもらえばいいんじゃないかな。

あーなるほどね。

これどうやって英語にするんだろう。

これをちょっとロマンチックな言い回しになってますけど、

ちょっと翻訳手元でやりながら話すとあれです。

先週か先々週に話してたフランスで

麻薬取り締まりの文脈で

ItsEとかのシグナルとかあの辺のアプリの通信内容っていうのを

政府から要求があった場合に開示できるようにバックドアを押し込むという法案が提案されていたっていう話があって

まぁ嫌ねーっていう話をしてたんですけど

その法案が否決されましたっていう記事ですね。

まぁちょっとその法案の背景とか否決された理由とかは正直

ちょっとフランスの政治事情に詳しくないとあまり読み解けなそうな感じがしなかったんで

詳しくは触れないというか触れられないんですけど

まぁとりあえず否決されたんでまぁまぁ良かったかなって気持ちと

あとなんか多分最終的にどっかの国会的なところで多数決になったっぽいんですけど

日本も119対24

110人が反対24人が賛成って感じで

まぁまぁまぁ惜しくも通らずって感じでもなかったっぽいんで

まぁまぁまぁまぁ安心というわけじゃないですけど

一つの結果として紹介したかったなって思って取り上げたって感じです

英語にすると

わかんねぇなよく

まぁでも

マジで日本語訳と何にも変わんない

フランス特有のなんか表現なのかな

謎だね

ただ一方でねちょっと国忘れちゃったし引っ張ってくるの忘れたけど

この記事をキャッチできたそのリスキービズで紹介させた別の国では

結構マイナーなヨーロッパじゃない国では

似たような法案が通っちゃったみたいなのがどっかであって

なんでまぁちょこちょこあるっぽいなっていう

そうこういう動きは引き続きちょっと雰囲気を見た方がいいかなって気持ちありつつって感じですね

なんかRSC 記事取り上げであったけど

セキュアなE2Eメッセージング

RSCの標準化の話とかもちょっと話題になってて

E2Eのメッセージングアプリの仕様みたいなのがちょっと詳しくないですかあって

それが進むと

AndroidとiOSのメッセージングアプリ同士でも同じプロトコルでE2Eのメッセージのやり取りができるみたいな話とかあって

なんでそっちはそっちへ進むしまぁでもそこに対するバックドア仕込みみたいな流れもあるし

まぁどうなるんでしょうねって感じの気持ちもありつつ

見守りましょうって気持ちですね

デンマークの方はまだ見てないな

デンマークが可決されたのかな

まぁいいやそれもちょっと分かったらまた紹介します

なんかニュースのお時間って感じでしたけど

ニュースのお時間

特にね語れることがないトピックなんだけど

まぁでも紹介したかったんで

じゃあ次は

頑張るぞって気持ちで僕が入れたんですけど

鈴木俊介さんのGitHub Actionsで世界にコードを修正するっていう前の記事ですね

でこれは

なんかいろんな前提知識がないと

これの嬉しさが多分伝わりづらいと思っているし

結構そのちゃんといろんな係数を整理しないと

これがなぜセキュアなのかっていうことをなんか理解できないので

実は理解するのがめっちゃ難易度高い記事だなと思ってるんですけど

一方でそのアプローチ自体はなるほどなぁと思ったので

いい感じの浅さでちょっとこの場では紹介できればなと思ってるんですけど

やりたいことはタイトルの通り

まずやりたいことは何かっていうとタイトルの通りで

そのGitHub Actionsでコミットを積むっていうのをやりたい場面ありますよねって話で

これはなんか仕事しっかりOSS活動しっかりいろんな場所でこのユースケースってあると思っていて

例えばリントを自動でかけてそのコミットを積むとか

バンドルされたファイルをコミットしたいになれば

特定のファイルがコミットされたらそのサブに合わせてバンドルして

サブになればそのコミットを積むとか

あと何でしょうねタグのアップデートとか

NPMだとよくやるのノードJSだとよくやるんですけど

パッケージJSONでリリースするときにそのパッケージJSONの中のバージョンのタグの部分を

自動でアップデートするコミットを積んでプリクを立てるとか

結構いろんなユースケースがあると思うんですけど

このコミットを自動で積むってことは何かしらのマシンユーザーを使うはずで

一番よく見る緩いやつはPADを使うとか

あとはGitHubトークン GitHub Actionsで自動で吐き出せるトークンを使うとか

ちゃんとやってる感度高くやってる人とかはGitHubを自分で作って

それのプライベート機器を使ってGitHubインストレーショントークンっていうのを使うとか

いろんな方法がありますよっていう感じなんですけど

これをセキュアにやるのが意外と難しいっていうのがまず必要な前提の認識ですね

なんでセキュアにやるのが難しいかっていうと

それこそさっき今日話したサプライチェーン攻撃の話につながってきますけど

じゃあPAD使ってコミットできるようにしようとなったときに

PADじゃなくても何でもいいんですけど

何かをシークレット使ってコミットできるようにしようって思ったときに

そうなるとそのコミットする権限を持つ何かしらを

アクション環境に置く必要がありますよね

例えばPADを置くとかGitHubのプライベート機器を置くとか

GitHubトークン自体にその権限を持たせるとかっていうのが必要になってくるはず

この状態でサプライチェーン攻撃が発生されたら

それ盗まれちゃってその権限を持ってしてコミット詰まれちゃうよね

コミット詰まれちゃうとワークフロー改変とかをして

フィーチャーブランチ環境からアクセスできるようなシークレットを盗まれたりとか

もしブランチプロテクションとかのルールとかが緩いと

下手したらデフォルトブランチのコード解散まで行っちゃうよねみたいなところがあって

じゃあどうするのっていうのが考えるのが結構難しいし

どこで止めるのかっていうのもいくつか選択肢があって

なかなかちょっと脳みそが爆発しそうになるような話がありますと

風呂敷を広げたんですけどその中でこの記事で触れられてる方法は何かっていうと

今言った何かコミット詰みたいリポジトリがあって

そのリポジトリで動くワークフローがあって

そのワークフロー上には直接コードをコミットするような権限を持つシークレットを置かないんだけど

でもコードのコミットする仕組みを作りましたっていうのがこの記事の話

これ言っててすごくどういうことやねんって多分なってると思うんですけど

3週ぐらいしないとちゃんと理解できない

そうなんですよね難しいんですよ

でも今必死に思い出したり脳内をすごく冷静にしながら話してるんですけど

今言ったどうやるねんってやつをどうやってるかというと

記事中に出てる図が割と分かりやすいっちゃ分かりやすいんですけど

クライアントサーバーモデルで実現しましょうっていう話をしていて

クライアントは最終的にコミットが積まれるコミットを積みたいリポジトリ

サーバー側はそのコミットを代わりに積む役割を持つのがサーバーっていう表現をしてます

この記事中で触れられてる肝になってる部分は

このサーバーっていう部分を自前でサーバーとか立てんじゃなくて

リポジトリ一個立ててそいつにサーバーの役割をさせようよっていうのが

割と肝になってる

サーバーの役割を担ってくれる既存のサースみたいなものも実はあって

記事の一番最初に触れられてるんですけど

パブリックリポジトリだったらAutofix CIっていうサービスがあるので

それ使ってくださいっていうのが書いてあって

一方でこのAutofix CIをプライベートリポジトリとかで使うと思うと

シンプルにお金かかるとか

あとはそのAutofix CIっていうサービスに

自分のソースコードへのアクセス権限を預けなきゃいけないっていうのがあるんで

それを許容できない場合は今回鈴木清之介さんが作った

このクライアントサーバーモデルで

サーバー側の実態はリポジトリっていうものを

使うといいんじゃないかみたいなところで作ったとなって

クライアントサーバーモデルの提案

このクライアントサーバー側の話に戻すと

具体的にどういう手順でコミットが積まれるのかっていうと

まず一つがファーストステップがクライアント側から

こういうコード編集をしたいっていう

コードの差分をまず作ります

それをGitHub Artifactにアップロードします

その後サーバー側にあたるリポジトリに対して

一周のラベルを作ります

これ何でラベルかっていうのを後で説明します

一緒にラベルを作るっていうのをやります

なんでクライアント側は

そのサーバー側に対してラベルを作る権限を

何かしらの形で付与する必要はあります

GitHub Artifactとかになると思うんですけど

サーバー側はこのラベルが切られたのを

フックにしてワークフローが実行されて

切られたラベルのアクセス元とか

ラベルの内容に応じて

クライアント側でアップロードされた

アーティファクトの内容を引っ張ってきて

ソースコードも引っ張ってきて

サーバー側のワークフローで

引っ張ってきたアーティファクトの内容を

コミットしてクライアント側に

サーバー側からプッシュするっていうので

最終的にクライアント側に積みたい

コミットがプッシュされるようになる

っていう形になります

なんでこのアーキテクチャだと

クライアント側に置かなきゃいけない

クレデンシャルっていうのは

サーバー側に対してラベルを作るための

何かしらのトークンかキッターパックとか

認証情報だけ渡しておけばよくて

サーバー側にはクライアント側の

コミットを積むためのクレデンシャル

残るんですけど

このクライアントサーバーが1対1だったら

今までと管理する場所変わんないじゃん

ってなるんですけど

このクライアントが現実だと

たぶんたくさんいるはずで

いいところは

これは僕が解釈してるんですけど

いいところはクライアントがいくつ増えても

クライアント側に対してプッシュ権限を持つ

クレデンシャルはサーバー側でしか

管理しなくていいんで

たぶん守る場所が1箇所になるはず

っていうのがたぶん嬉しいのと

あとこのラベルを何で使ってるかというと

サーバー側に何かしらのアクションを

伝えるときの手段で

この記事中に振られてるのは

例えばリポジトリディスパッチとか

ワークフローディスパッチっていうイベントがあって

使いやすくて一般的なんだけど

この権限クライアント側に渡しちゃうと

結構アクションズライトっていう権限を

渡さなきゃいけなくて

そうなるとサーバー側の任意のワークフローを

任意の方法で呼び出すってことができちゃうんで

結構不安だよねってところで

ラベルイベントっていうのがあるじゃんってなって

このラベルイベントだったら

スマイル化としてもほぼほぼ何もできない

なんか一周を書いたりとかできるけど

一周ライトだから

これ使えるじゃんっていうのが

一つまずアイディアとしてあるっていう感じ

どことないバッドのオウハウ感

これをさせられるなんかその

ギター部の仕組みがやっぱ

僕は悶々とするなって思ってるんだけど

でも

何だったらいいのかもあるから

そうなんですよ

どっちかっていうとなんか普通に

PubSubっぽい感じで

イベントドリブンに

クライアント側の

いやでもクライアントサーバーイベント

サーバークライアントモデルで考えたときに

ちょっとなんか関係性が逆転してる気がするんだけど

クライアント側から

クライアント側のイベントサーバー側が

リストにしてるような形にして

イベントを検知して

特定のワークフローを動かすとかができればいいのかな

まぁまぁまぁちょっとタラレバな話なんで

深掘りしなくていいけど

じゃあこのラベルを使わなくていい方法って

どういうのがいいんだっけっていうのを考えたときに

地味にむずいなと

難しいね

またなんかちょっと

時間なくて理解しきれてない部分としては

クライアントからリスパッチする形でも

サーバーがリストにする形でもいいんだけど

気をつけなきゃいけないのは

確かにクライアント側に認証情報はないんだけど

そのクライアント側から

アクション通信ができたとして

その任意のコードを

任意のところにプッシュできるっていうのが

何かしらのコミュニケーション方法でできちゃうんであれば

状態としては変わんない

そこのプロトコルの設計は

多分気をつけなきゃいけない

その辺は

記事の一番下の方の

このケースで悪用できるかどうかみたいなところ

一個一個ちょっと丁寧に説明はされていて

これ多分ちょっと実装みたいな実際の挙動を見ないと

ピンとこないなって個人的には思ってるんですけど

ラベルクリエイトするときの

プロトコルで表現できる情報量を

多分意図的に絞ってるというか

っていう部分で多分担保してる

ぽいなっていう解釈をしてる感じかな

そうですね

だしそうだね

任意ブランチ

そうだね

そのプルリクに対してコミットを積むっていうシナリオだから

そのプルリク以外にコミット積みたいっていうのは

多分この鈴木俊介さんが作った仕組みだと

できないようにきちんとなってるって感じなのかな

だからこの辺もね

そうもうちょっと

セキュリティ意識の強化

手動かさないと理解むずいなと思ったりしてるんですけど

この辺は多分どのアーキテクチャでもそんな感じ

って感じかな

でこれは使えるんで

もし使いたい人がいればって感じですけど

でなんか先週

自分の中で理解できてなかったのは

Octo STSっていう

なんでしょうね

ギターバープを経由して

例えばコンテンツライトとかを

ワークロードアイデンティティ連携みたいな形で

制御できるギターバープとかがあって

そっちの方が筋いいんじゃないかって思って

ただなんでそれがいいんだっけっていうのが

自分の中で言語ができてなかったんですけど

Octo STSとかの場合は

そのOcto STSのギターバープのプライベートキーを

この話で言うとこの全クライアントにまかなきゃいけなくて

だからOcto STS側の設定とかがミスってたり

権限が課題だと

確かにアーク用のシナリオ増えるかっていうのを考えると

この鈴木俊介さんが考えたアーキテクチャであれば

ある程度は心配事は減るというか

守る箇所は減るよなっていうのは

シンプルに思ったかなっていう感じですね

なんかいらなくならないのかな

いらなくなってほしいよね

なんか不毛だよね

このためだけリポジテリー2つに分けましょうみたいな

そうなんだよね

私これさ

オーガニゼーションレベルで1個

要はここで言うクライアント

違う嘘ついた

ここで言うサーバー側になるやつか

サーバー側になるやつを

オーガニゼーションレベルとかで1個持つってこと?

もしこれを

そうだね1個持つ

あるいはリポジテリーごとに1個ずつ持つのかな

リポジテリーごとに1個ずつ持ったほうがマシなのかな

いやでも多分サーバー1個のほうがいいんじゃないかな

まあなんかその分

サーバー側の権限を分離したいんだったら

まあサーバー側をバラしたほうがいいけど

まあそこはなんかメンテコストとの兼ね合いかな

個人的には

本当に重要なもの以外は分けずに1箇所に集約して

ただそのサーバーリポジテリーをガッチガチに守るのがいいんじゃないかなと思うけどね

でその守るっていうのはそのリポジテリーに振る権限もそうだし

プッシュルールセットとかで

もう通常じゃ誰もプッシュできないようにしちゃうとか

例えば

そういうアプローチが

守る場所が1箇所なんであれば取れるかな

そうだね

まあ

なんかね

そうでもいらなくなってほしいのは本当に

そうは思う

どうにかね

その

いやー

いやーって感じなんですよね

ちょっとちゃんと時間かけて考えたことないけど

その

多分ねGitHubのその

ブランチプロテクションないし

ルールセットがもうちょっと進化してくれないときついんじゃないかなって気はしてるんだよね

先週話したんだっけな

そのセルフアプローブを防ぐみたいな

杉志元介さんの別の記事

あったけど

例えばその

他の人が作ったPRに自分がコミット載せて

その

自分でアプローブするパターンとかって

普通にルールセットで

GitHubの設定側で防いでほしくないというか

なんか

機械的には可能なわけじゃん

その

自分が

アプローブ

アプローブしたものを無効にするみたいな

普通にGitHub側でサポートしてくれればいいし

それが自然だと思うし

でもそれができないからじゃあ

穴が一個増えて考えなきゃいけないよねとか

これもその

そうね

コンテンツライト権限があって

任意コードプッシュできてみたいなところに対して

任意コードプッシュしても何も起きないようにすべきっていう話もあるし

ただ合わせて任意コードプッシュした後に

もう一個マシンユーザーがあったら

できちゃうかもしれないとか

またそのシークレットを

その

いい感じに守る方法は

まぁ今はエンバルメントシークレットっていう

機能があるけど難しいよねとか

あと何より問題はその

自分で言うのもなんだけど

僕ほど解像度があってもなんかこんなに脳みそがバグるものを

普通の開発者が理解できるわけがないと思っていて

だからその

あの

この記事もさハート20

いいね26しかついてないけど

僕的には

あの

いや

その

なんだろうね

あの

GitHubでやってくれよという気持ちはあるけど

この仕組み自体めちゃくちゃいいよ

あの

面白いアプローチだと思っているんだけど

多分みんな理解できないというか

なんか

その

ちょっと

なぁ

この

この時代

このサプライチェーン攻撃が

サプライチェーン攻撃自体は別に

記事アクションズの話じゃなくてもずっとなんか

危ない危ない言われてた中で

なかなか

開発者にここまで頭を使わせる

状態なのはもうちょっと良くなってほしいなっていうのは

シンプルに思う

するかな

感じですね

そうなんやね

またこの辺頭使いたくなかったら

AutoFixCAとかに課金しましょうとかでもいいかもしんないけど

でも

でも多分そのこの

前提とかコンテキストちゃんと理解してないと

AutoFixCAに金を払う意味が多分見出せないから

結果的に世間なんないんだよなっていう

その

もどかしさもあったりはするかな

うんうんうんうんうん

そうなんですよ

これはだいぶ理解に時間がかかったし

まだ100%理解はできてないんですけど

なるほどなって気持ちはありつつ

そうね

その児童でコミットね

児童でコミットを積むっていうのやめられればいいんだけどね

その

それができないとやっぱ

開発体験の幅が狭まってしまうんで

それは多分なんだよなって思うと

なかなか悩ましいなっていうところですね

ね

いやーむずいな

難しいな

なんか

うーん

いやーむずいな

なんか例えばGitじゃなかったらとか

あったりするのかな

Gitに行ったわけじゃないもんな

うーん

どっちかというとGitHubの機能かな

うーん

なんかVCSも含めてゼロから全部作ってくださいって言われたときに

うん

まあでもやっぱGitHubの機能だよな

うーん

なんかその

うーん

GitHub Actionsとかの仕様とかプルリクの仕様

まあルールセットの仕様

ブランチプロテクション仕様がネックかなって気がするな

俺がじゃあどういう機能入れんだよお前って言われたら多分

うーん

いやー難しいけどね

でもまあとりあえずアクションシークレットはどうにかしなきゃいけないよねって気はする

フィーチャーブランチ

なんか何でもいいからコミュニティをプッシュできたときに

アクションシークレットは全部盗めるっていう状態がやっぱきついよとか

うーん

いやー

難しいな

ノーミス爆発するんだよな

なんかいろんなケースがありすぎて

うーん

ちょっとなんかもくもくもないけど

ちょっと思うのはその何だろうな

その取られて困るようなワークフローをGitHubで動かさないのが一番実は悪いんじゃないかって気もする

うーん

極端かもしんないけど

うーんまあね究極そうだよね

うーん

デプロイ

なんかCDはGitHub Actionsに置かないとかさ

コード改ざんみたいなのは多分気を配らなきゃいけないけど

うーん

そうだねCDとか

いやでもそうそうそうだと思うよ

うーん

そのCDをGitHub Actionsに置くの結構怖いなって思ってるし

そうだね

うーん

うーんうちの場合をどこまで話していいのか分かんないけど

でも記事とかでちょこちょこあるよね

うーん

そうね

そもそもスピネーカーだったじゃんずっと

そうだね

うーん

なんかGitHub Actionsとか要はCI直結のCDみたいな

ちょっとどういう言い方するのがいいのか分からんけど

うーん

要はGitHubのそのワークフローと結合度高めのCDっていうのはもともと動かしてないんだよね

うんうんうんうん

で

うーん

で今どうなってますかの話は多分ねブログにね書かれてないので

うんうん

何も紹介できないんだけど

オフレコで

オフレコでっていうか

課金したとしても喋れないんで

そうなんですよ

まあまあ

なんか詳しそうな人にうちの採用とか多分

あの専攻とか受けたら多分詳しい人が出てくる

そうね

意味のベンチはいいかなと思いますけど

いやーそうね

それがいいんだろうね

生字ちょっと便利だからな

そのコードが近いし

結構書きやすいし

うん

なんかその他社がどんなになってるかとかは分かんないし

都知事社がどんなになってるかもちょっと喋れないけど

うんうん

でもやっぱその

なんかGitHub

アクションズ侵害されたら

されてもある程度大丈夫ですみたいな

その一番最初の水際が

水際というかラインが

もうちょっと奥に押しやれると

そもそもそう

逆にそのGitHub上で

CDを動かすとか本番中かなんか

結構強い権限でも何かを動かすとか

したいんだったらこういうのはもう

何かいくつかの脅威に向き合うんであれば

多分向き合わざるを得ないから

そこは一緒に頑張ろうっていう気持ちですね

僕の目線としては

そうねでも本当におっしゃる通り

なんかこれをせずに済むように

GitHubにしてほしいのが本当にそう

しなんかね

これに対してSaaS作って

っていうのはありがたいけどなんていうか

じゃあその企業買収してGitHubアクションズの中身

GitHubが自分で変えてくれよとか

まぁでもなぁ前も話したけど広報交換制とか

いろいろあるんでしょうね

うん

はい

そういう感じです

まぁぜひ興味ある人は読み込んでみてください

はい

じゃあ次お願いしようかな

はい

社内でCTFを開催してみたという記事です

えーっとサイボーズさんのブログですね

えーっと

どう紹介していこうかな

まぁタイトル通りなんですけど

セキュリティを身近に感じてもらって

日々の開発や運用にセキュリティ意識を持ってもらうことを

目的として

社内のイベントの中で社内CTFを開催したよっていう

まぁレポート記事みたいなものですね

で準備期間これぐらいかけたよっていう話とか

こういうコンセプトで問題作ったよとか

問題何問って言ってたっけ

結構多かった23問ぐらい確か

そんなに多かったんだ23問だはい

よく覚えてたのだ

はいで

準備と実施

まぁなんかいろいろ準備をして

最終的に楽しんでもらえたよという記事でございました

でなんかまぁ終えてみて

えーっと時間がない中でゼロからやってみたけど

無事に終えられたよっていう部分とか

あとはまぁなんかチュートリアル

チュートリアル会みたいなのをやることで

あとまぁまた社内での口コミとかも含めて

未経験者でも参加しやすい環境を作れたよとか

そういう意味もありつつ

作文に時間がかかったので

次回は書き本の理由なども検討する必要があるねっていう反省点とか

次へ向けてのそのポイントとかを書いてくれてるような感じですね

はい

なんか

そうですね

これなんで紹介しようと思ったんだっけな

読んでみてどうでした?

なんか

紹介性並みの感想ですけど問題性食いなって思いました

問題性食い

まぁでもあとちゃんとなんていうか

あのきちんと準備してきちんと参加者集まって

きちんといいフィードバックもらってるのはやっぱさすがだなというか

うん

楽しそうだなと思ったし

そういうことは何回か話したことあるけど

セキュリティに興味を持つとかかりとして僕はそんなに悪く

CTRは結構いいアプローチの一つかなって

開発目線としては思うんで

いいなっていう気持ちですね

まぁ一応なんか割といろんな人が参加してくれたよっていうのは書いていて

目的は一応達成できたのかなあとは記事からは読めるんだけど

僕が思ったのは目的に対しての効果測定みたいなのが

この形式だとめちゃくちゃ難しいよねと思っていて

良かったねのお気持ちで終わってしまいがちだよなとは思うんですよね

その辺がやり方として結構難しいなと思っていて

逆に面白いよねに振るんだったらそれでいいんじゃないかなと思うし

社内イベントみたいなところだから

そんなにゴリゴリにRY側みたいな話とかってしなくてもいいと思うので

わかんないけれども

ある種そこに交渉な目的があるような感じにしてしまうことによって

むしろ自分の首を絞めるみたいなのがないんじゃないのかなどうなんだろうな

みたいなのをちょっと読んでて思ったっていうのがまず一つと

定期的に実施したいっぽいんだけれども準備が割と大変なので

問題の使い回しの是非とあとは開催頻度の問題で多分悩む

目的を考慮するんだったら問題は使い回して

毎回同じコンテンツでやるでもいいんだけど

多分参加者が毎回ほぼ全員ローテするよみたいな環境ではないので

要は初動で参加してくれる人はもう多分いいんだけど

2回3回繰り返していった時に多分なかなか来ないと思うんだよな人が

徐々に減っていくんじゃないかなと思っていて

そうすると何かじゃあ例えばそれで問題を毎回新しくしますってなっても

結局同じ人が参加してるとかになったりしがちな気もするし

結構この辺はバランスが難しそうだなとちょっと読んでて思った

そもそもその任意参加というか有志にするのかとか

ある気がするね

そうなんだよね

会社とか組織による部分もありそうだけど

なんかそのCTFを作る側にとても回る余力も

権限管理の複雑さ

余力かな余力がないんで僕の頭の中のただの妄想なんですけど

もしうちの会社で同じことやるんだったら

開発チームのオフサイトみたいな時に

そのコンテンツとしてやれるという差そうかなとか思ったりするな

またなんかそのCTF 目的次第だよね

なんか僕目的次第ですね目的次第なんで

これがこの細部さんの例がいい悪いの話じゃなくて

例えばなんかある種の啓蒙とか興味を持ってるのを

みんなもらうみたいなとこに目的を汲んでいれば

なんかCTFを社内でやるっていうのは

HOWのうちの一つに落とせるかもしれないという気がしてて

だからなんか毎年CTFをやるっていうよりかは

今年はCTFをやろうかとか

そうね

次の年はハーデニング的なことをしようかとか

そういう感じとかでやりたいするというか

そっちの方が結構続けられるイメージも湧くし

そうなんだよね

例えばね

確かに毎年毎年問題考えるの大変だろうな 23問でしょ結構

好きな人がいないと続かないよね多分作文が

そうなんですよ

なんかそうだから

難しいなぁと思って

そうだね

なんか作文に関してはちょっと

いやでもわかんねえなやってみないとわかんないけど

ちょっと思ってるのはその社内で実際にあったネタ使えば

実はそこそこネタはあるんじゃないかという気持ちが

なくはないんだよな

具体的なことは何も言えないんですけど

いいと思うよ

いいと思うよとしか言いようがない

あれですねCTF運営側として長くやってきた見上げ社だからこそ

多分いろんなあれもあるんだろうなという

お察しはするんですけど

いやてか私の場合はむしろあれだったから

初心者向けみたいなのを歌って全国を回ってたので

かつ基本2回目はお断りっていうスタンスでやってたから

確かね

参加者が基本漏ってするっていう前提なので

そんなにしんどくなかったんですよ

コンテンツ使いまわしてよかったし

確かに同じだったね

そうなんですよ

そうだからね結構

どうなんだろうなと思いながらやってました

ふわっとしているけれど

雷さんとかは確か2年連続やって2年とも良さそうみたいな話をしてたけど

実際に話を聞いてみたいところもあるかな

詳しい人お便り待ってます

社内CTF運営に詳しい人知らんけど

でもあんま考え…やりたいと思ったらお祭り的にやるぐらい

だからさっきも言った通りで

それぐらいが良いんじゃないっていう風に言ってるのは

つまりそういうことで目的がーみたいなのを

持ち出してくるとしんどくなっちゃうから

こういうの楽しいよね良いよね何か良いよねぐらいに

整えるのが良いんじゃないかなって思ったわけですよ

持続性のためにもね

そうだね

無理して続けるもんでもないしな

別にCTFに限らずだと思うけど

ありがとうございます

そんなところですか

じゃあ最後は

最後?

最後なんですよ

最後じゃないですか

割とねぬるっと

最後だけどちょっと軽く話せればなって気持ちで

奥がピックしてきたんですけど

当然のこれはアイブリーさんのテクノログの記事で

GitHubの権限とチームを整理して

テラフォーム化したっていう記事ですね

内容としては

テラフォームの公式のGitHubプロバイダーがあって

それを使って

IAC化したよって話で

いくつかいろいろ課題があって

いやあるあるだなと思うんですけど

オーナーがたくさんいて権限がバラバラだよとか

これ地味にあるんですけど

GitHubアカウントが

会社の誰か分かんないみたいな

これはマジであるあるだと思ってて

あるある

確かに確かにとか

マジ、待って

たまにマジで分かんない人いるよね

マジで分かんない人いる

本当に分かんない人いる

本当にマジで分かんないんだよね

なんのその

なんていうかさ

ガチでスラックのアカウントとかとのひも付きが何もなくって

星の数

エピソードをシェアする

メッセージを送信

Sota Sugiura

サマリー

目次

星の数

コメント

こちらもおすすめ