新年の挨拶と過去の振り返り
こんばんは、Replay.fm 第16回です。
本当に?
前回16じゃなかった?
前回15です。
前回15、素晴らしい。
じゃあ、16回ということで。
はい。
明けましておめでとうございます。
明けましておめでとうございます。
今年もよろしくお願いいたします。
お願いします。
はい。
これ何?
いやー。
1年間順調にやったら、第何回までいった?
50回分だね。
週1でしょ。
そうだね。
360…52か。
なるほどね。
結構な…いや、週1で結構…そうですよ。
いやでもさ、2年やってもようやく100回ってことでしょ。
まあ、そうだね。それはそう。
それで言うと死にせの100…なんか200回とかの配信の方々は、もう死にせも死にせって感じですよ。
ね。
やっとんな。
リビルドとか400だしな。398だった。
いつからやってる?
8年とかやってるってことじゃん。
すごい。
パスキーの技術的な側面
あ、でも週1とは限らないのか。
そう。週1はベースでしかも更新してないと思うから。
うん。
まあ、頑張ってスクロールしてるけど、2016年5月に142回やってる。
相当、ポッドキャストが流行るずっと前からやってるんだろうね。
うん。
こういう…だからもう自分…自前でそのサイト作ってホスティングしてってやんないとあれだよね。
確かに。
2013年2月。
あーこれね、今はめっちゃ便利ですからね。
ポチポチってやれば全部にババッと配信されるんで。
ね。
楽なもんですよ。
SSHログインを知らない若者と…いや、わかんない。知ってるか。SSHログインぐらい。
いや、でも下手したらさ、SSHやったことないですって人いるよね。
俺らでさえそもそもやんないから若者がやるわけないっていう話は普通にあるよね。
仕事でオンプレとかだったらとか、ないっしょ基本。
うーん、まぁGCE使ってればGcloud Compute SSHとかはする機会あるかもしんないけど。
それぐらいかもね、確かに。
うん。
だいたいもうコンテナライズされた世界線が多い気がするんで。
だからイスコンでしかSSHコンフィを書かないって。
あー、でも確かにもう何年も触ってない気がするなぁ。
まぁ、イスコンはちゃんと素振りしないとまずSSHでつまずく。
いやー、なんかそう言われてみると確かにそうかも。
絶妙にね、そう、いやいけるはずなのにあんな単純なあれなのになぜかそこでやっぱちゃんと素振りしないとつまずくっていうのはね、もうちょっと。
いや面白すぎる。
面白いね。
エンジンXの再起動とかね。
あー、システムコントロール。
そうそうそう、ログのパーミション変えるとか微妙なやつ。
あー、システムコントロールとかもう、いやー、システムコントロールのコンフィがあれじゃん。
要は自分で起動時にサービスを立ち上げたいみたいなのをやるときに書くやつとか。
覚えてないな。全く覚えてないな。
もうググって。
それこそなんかちゃんとGPTでいいんじゃない?
あー、そうだね、それはそう。
向いてそうだよね、そういうの。
まあまあまあ、何の話だっけ?
SSHの話。
SSHの話。
なんかからSSHの話、まあいいや。
なんかからはね、あれだよ、あのー、今日のワンパスワードの記事の話でしょ、きっと。
いや、違う。
違うんだ。
いや、違う。
いや、その前のなんかの話で、何かの何かが若者にとってのSSHログインみたいなもんかって俺が言ったんだよ。
その前段がね、忘れたんだっていう。
まあ聞き直せば。
研究してなかった気がするけどな。
なんか唐突にSSHの話になってきた気がするけど。
いや、あー。
実はね、若干ね、頭に入ってない部分があって、何故かというと唐突にノーションが固まって、
なんか直すのに必死だったんでしょ、今裏で。
なるほどね、なるほどね。おつかれさまでした。
じゃあそれは、まあ音源聞き直して。
はい、みなさんを楽しみにということで。
みなさんは多分もう、これだぞって思いながら聞いてる。
記憶喪失になってんなって多分思いながら聞いてるんだろうな。
まあ、やりますか。
やりますか。
じゃあ新年一発目の記事、これでいいんですか?
これでいいんですかと言っちゃったんだけど。
いいんじゃないですか。
これがいいですか?
なんでダメなの逆に。
別にダメです。
これがいいです。
はい、じゃあ。
え、僕ですか?
え、そうですよ。
ああ、そうか。
じゃあ、パスキーとうまく付き合うコツっていう、
エイジさん、Googleでオース、オーサリゼーションオーセンティケーションマリオの仕事をなさってる、
エイジさんという方がいるんですけど、その方の個人ブログの記事ですね。
で、内容としては結構タイトルの通りで、
本当にそのパスキーって何ぞやって話から、
パスキーって使いづらい場面ありますよねってところで、
じゃあその使いづらいとか、パスキー見つからないみたいになった時に、
どういうケースがあり得るのかっていうのを結構整理してくれているっていうところで、
で、なんでその目線としてはパスキーの技術的な側面というよりかは、
パスキーを使う人目線で結構きれいに整理してくれてるっていうところと、
あとはそのパスキーを使いこなすコツみたいな部分で、
本当、記事がすごい詳しくてですね。
Windowsだったら、このWindowsでこのブラウザだったら、
このパスキープロパイダーだとこういうことをするよみたいなことをいろいろ表でまとめてる。
いや、こういうのを欲しかったんだよね。
そうだね。
欲しかったんだよね。
地味にないもんね。
そうですね。
パスキーを実装する側の話も一応書いてて、
これも技術的な話というよりかは、
こういう仕様にしたら使いやすくというか便利にできるよねみたいな部分っていくつか書いてるんですね。
なのでかなり、たぶん2024年12月内初、2025年1月時点のパスキーに関する記事としては相当きれいにまとまっている、
しばらく使えるリファレンスになるような記事かなと個人的には思いました。
ユーザー体験と将来の展望
そうですね。
これ僕が、そうか、僕が追加したのか。
そうです。
僕が思ったのはめっちゃいい記事なんですけど、
この記事の縦のスクロール長さがパスキーの現状をよく表してるなという気はしてて、
これ一般の何もわからないユーザーが、
このボリュームを把握しながらパスキーを使いこなすって多分不可能だし、
僕も多分これ1から10までは当然暗記とかはしてないんで、
結構やっぱいろんなケースがあるよなっていう部分がしみじみ思ったんで、
この記事の2026年、7年、8年版で何も考えなくても付けられるようになりましたってなる世界を目指したいなってしみじみ思ったぐらいですかね。
うん、そうね。
よくまとまっている。
なんかこの同期できないパスキーやパスキープロパイダーをユーザーに分かるようにするっていうのはまさに結構ここトラップだなと思ってて、
例えばメルカリとかでビットワーデンのパスキーを追加すると、
iOSで作ったとき、違うな、Appleってなってるんだよな。
表記がAppleになっちゃうんですよ、鍵の名前が。
iCloudキーチェーンに入ってるやつも多分Appleになってて見分けがつかないとか、
あとデバイスバウンドパスキーとシンクトパスキーの差分とかもぱっと見でよくわからなくて、
あとシンクトパスキー、デバイスバウンドパスキーを指定して作らせるっていうのも作るタイミングではできなくて、
作ったのがシンクトかデバイスバウンドかを見て拒否するみたいなのはできなくはないらしいんだけど、
なんかその辺が結構トラップだなっていうのは最近思うところですね。
なるほどね、確かに。
Appleは困るね。
そうなんだよ、困るんだよ。
めちゃくちゃ困る。
もうちょいなんとかならねえのかなと自分とこのサービスながら思わんでもないんだけど。
それサービス側で直せるもんなのか。
名前つけてるのはこっちだから、分かれば多分なんとかなると思うんだけど。
でも多分なんだけど、クライアント側のAPIの仕様としてもう見えないんじゃないかなと思うんだよね。
その透過的に何がパスキープロバイダーとして振る舞ってるか分からないんじゃないかなと思うんだよね。
iPhoneで作るとiPhoneってなるんだよね、確か。
いやそうじゃない嘘だわ、シンクトパスキーだと全部アプリになっちゃうのかな、きっと。
iPhone SE2っていうのがなんか俺の画面で今言ったから、
だからデバイスバウンドのパスキーだった気がするからな、それ使ってた時代は。
もうあなたも使ってないから消しちゃおうか。
年末。
消しちゃおうっつってさ、ログインできなくなったりしてね。
いやー。
ありそうなんだよ。
ありそう。
この鍵はいつ使ったよとかさ、補足情報は多分あればあるほど良くって。
そうだね。
もう使ってないものを頻繁に使ってるものとかね。
なんか管理画面を用意するみたいな。
パスキーのデザインガイドラインではパスキーの管理画面を作ることを推奨してますね。
こういうのがあるといいんだけどね。
なんかあるかさえ、俺ワンパス使っちゃってるからな、ワンパスで完結できちゃってるから。
それはそれで迷うんだよな、トックフーリングのためにワンパスをあえて使わずに苦しんでみるか。
面倒だしな気持ちにワンパス使ってるんですけど。
でもこのサービス画っていうのはかなり大事で、パスキープロバイダーどこの使ってるのかがわからんっていう前提がどうしてもある中で、
サービス画でできることっていうのはこういうことだよねっていうのは間違いなくあって。
要はパスワードマネージャーを使うことを強制できない以上、多分散々言ってるけど、
サービス提供事業者の責務としてはもうパスキーに乗っかっていくしかないわけで、
その中でどういう体験を提供するべきですかっていうのは常々考えていかないといけないし、
この管理画面みたいな話とかどういう情報を各鍵ペアに紐づけて出していくかみたいな部分ももちろん一つの改善ポイントにはなると思うし。
この考え方自体が、ここで紹介されてるような内容自体が小さくなっていくっていうのは多分なくて、ないんじゃないかな。ないと思うんだよな。
これがベターですよっていう部分はそんなにもうなんか出てこない、出てこないっていうか減っていかないような気がしていて、
これがスタンダードとしてどれだけ普及していくかがむしろ鍵になるんじゃないかなとは思うんだけれども。
なるほどね。
だからなれるしかないよねっていうのはなくはないと思うんだけど、そうは言ってもっていうのもその通りだと思うし。
もう少し。
でも鍵の動機っていう部分は確かにコツ4っていうところでなんか紹介してくれてるけれども、
いろいろ例えばGoogleとかAppleとかがうまいこと鍵の動機の部分をそういうところの利便性を高めようっていう動きをしてくれてるみたいなので、
なんかその辺で勝手に便利になっていくっていうのは絶対あると思うし。
そうだね。
願うくはな、そっちも頑張ってほしいとか。
だから管理画面が必要だよねとかは絶対について回ると思うし。
またそのトラブった時の対処法のプラクティスが確立されてくるといいのかもね。
リカバリーは確かにね一つのハードルというか大きな障壁になってる部分はあるし、それは正直サービスプロバイダーとしても間違いなくあって、
難しいな。
ウィーキャストリンクがどうしてもリカバリーの手段になりがちというか、
全部例えば免許証提出させて本人確認ができたらリカバリーさせるようなフローにすると絶対回らなくなるので、
かといって他のパス機よりも弱い認証の手段を持ってリカバリーさせようみたいなことをすると今度そこがウィーキャストリンクになっちゃうし、
頭を抱える系の話ではあるんだけれども結構難しいところですね正直。
なんかの時に話した政府発行のアイデンティティ認証のAPIとかがめちゃくちゃ普及したりしたらいい感じになるかもしれないって一瞬妄想したけど、
その世界線が日本であるとしたら10年後ぐらいかな。
国内でしか展開しないサービスならそれもありかもしれないけどね。
確かに国によってとかなると。
確かに確かに確かに。
まあでも頑張っていきたいな。
今年もな、いろいろアップデートがあると思うから頑張っていきたいですね。
まあ嫌でも目に入ってくると思うし正直。
そうだね。
じゃあ次は。
次私行きますか。
お願いします。
不正利用防止策の概要
より良いプロダクトを目指してフリー請求書のメール送付機能不正利用防止対策の話。
なんかこれ日本語がぶっ壊れてない。
タイトルの日本語がぶっ壊れてるよな。
請求書のメール送付機能不正利用防止対策の話。
ぶっ壊れてるかもしれない。
タイトルタイトル。
頭に書かれてる。
そうそうそうそう。読んでてうーってなっています。
声に出してることちょっとバグる。
バグりましたが。
フリー請求書のメール送付機能を利用してスパム送信されると困るので対策をしてるよっていう話ですね。
具体的にはレートリミッティングあとはレイリズ特有の事象なんだけれどもレートリミットに引っかかったリクエストのログがちゃんと残るようにするだとか
あとはレートリミットに関するデータトップのモニターの設定をしたりだとか
E-mailアドレスバリデーションAPIの導入
これはSendGridのAPIらしいんですけど
悪質なメール
違うな難しいな
メール送付時にこのAPIでメールアドレスを検証して
不正利用の可能性があると判定された場合即座に対応できるような仕組みっていうのを導入してるらしいです。
なんかね見た感じね
存在してるメールアドレスとか存在してないメールアドレスかとかそういうのが分かったりとか
なんか色々あるみたいなんだけれども
結構便利そうなAPIだなとサービスだなと思ってみてました。
何とは言わんが具体的になんかこれちょっとこういうので使いたいなみたいなユースケースとかも実際あるし
なんかちょっと気になりましたっていう感じですね。
なんか正直それだけなんですけど
これね僕も知らなかった
でもなんか割と具体的なコードでスキララに書いてくれて
なんかつまびらかに全部こうやって明らかにしてるの珍しいなちょっと思いましたね
こういうのなぁなんかその理屈はまあこういう風にやればいいっていう
なんかその空中線投稿はよく見かけるけど
なんかコードでやったらこういう風にデザインしてますよみたいな話ってあんまり
いやまあ見るけどそんなにめちゃくちゃ見たりはしてないかな
まあオカルギー書かないですけど
まあでもなるほどねと思ったらふわっと読めてよかったです
はい以上です
確かに何のアドレス
確かフリーさんならではだな
はいありがとうございます
次は
TENXのセキュリティ対策
セキュリティチームの日々の取り組みの紹介
TENXアドベントカレンダー2024の記事ですね
26日目の記事
26日目の記事成立
人数があぶれたからなんかわかんないけど
延長戦やってたんだ
延長戦やってた
はい
TENXセキュリティチームの沢田さんの記事ですね
文字通り日々の取り組みの紹介っていう感じで
時間の単位はわからんけど
セキュリティチームの1週間みたいな
そんな感じの記事だなというふうに思って読んでました
なんかプロダクトの設計と実装レビューやったりとか
プロダクトに関わる脆弱性アラートの取り味やったりとか
クレデンシャルレビューやったりとか
クレデンシャルレビューっていうのは難しいな
いろんなところに散在しているクレデンシャルを記録とって
管理方法とかをレビューするっていうような感じなのかなきっとね
はい
外部セキュリティアドバイザーとの相談会とか
アクセス制御の不備のチェック会とか
セキュリティリンドック会とかやってるよっていう記事でした
割となんか世の中鼻のある部分しか見えてないことが多いんだけれども
こういうのなんか結構地味に
ドロクサワークというか地味に貴重だなというふうに思いました
アクセス制御不備のチェック会とかはまさにそうで
結局こういうの必要ですよねっていうのはあると思っていて
全部自動化したり全部機械化できればいいんだけれども
そうもいかないよねっていう典型例だと思うし
そうだね
できてほしい部分ではあるんだけれども
なんかテンクセキュリティチームに所属してるんですけど
ひと回ししないとなんかそういうところにも踏み込めないよなっていう
ある気はしてて
今言ってくれたアクセス制御不備とかはやってみると
とりあえずドロクサワークやってみると
なんかこの部分は自動化の余地があってこの部分はちょっと引き付けてるとか
結果に対してその次のアクションが取れるとか
実態を把握した上でどうするかっていうステップを踏めるから
割とそこは地味なんだけど価値があるなっていう気はするね
これなんか別にバーって見てて
これとりあえずグリップで対象を洗い出すだけだったらできるねとかさ
うんうんうんそうだねそうだね
これはリンターかけそうだねとかさ
なんかシャクとか出そうだねとかさ
リンターかくんだとちょっとめんどくさそうだねとかさ
なんかいろいろあると思うんだけど
あるね
その辺がやっぱその会社とかコードベースとかによって違ったりはするから
もちろん経験が生きる部分もありつつ
まあまあやってみるといいという話もある気はする
セキュリティチームっていう立場に立った時にさ
その実際に動いてるコード見ないと話にならなくない?
さあ
結構極端なことを言ってる自覚はあるんだけど
なんかでもさ話ができなくない?
開発してる人たちと
そうね
それで言うととにかくそのプロダクトの設計と実装レベル1個目に上がってるやつとかは
そのできなくはないけど仕事の人はめっちゃ下がると思う
うん
そのなんていうかそうねコード読めないとね
そのコンテキストというか
いろいろスキップできる気はするんだよね
なんかそのヒアリングとかディスカッションする時の事前準備が結構スキップできる
話は間違いなくあって
普通になんかこのエンドポイントでこういうことしようとしてますって言ったら
じゃあ事前にパーって読んで
そこにこういうの入れようとしてるんですね
じゃあどうしましょうって話ができるけど
もしコード読めなかったら多分
そうだね
あとあれどうなってるんだっけっていうのをさ
人に聞かなきゃいけないのと自分でサクッとその場で確認できるのとだと
全然その効率も変わってくると思うし
そうだね
あとはそのもしかしたら出せる解決策の流度が
抽象度が上がっちゃったりするかもね
コード読めると
イナーの実装とかデザインがこうなってて
それにこれ差し込むってなった時に
いやーなんかあるじゃん
わかるわかる
認可制御とか
フワッとした話にしかならないんだよね
実装が正しい
あなたが正しく実装ができる前提に基づいてこうしてください
フワッとしたことしか言えなくなるから
そうだね
いやーわかる
そこの解像度があると今の認可のやつはもう全部ハードコードなんで
そこはもう気をつけてくださいとか
じゃあちょっとテストで担保しておいてとか
そこまで踏み込めるっていうのは
かなり価値が大きいかもね
っていうのもあるし
なんか割と局所最適に走られがちというか
そういうその
なんていうか
関わり方をしてると
確かにそれでいいけどさみたいな
なりがちというか
いやー確かになんかでも考えれば確かに
こう読めるのいいな
そうなんですよ
なんか普段から見て触れて
把握してることが一番大事だと
全社は
脆弱性あると取り合いしても地味に生きたりするかもなとか
そのこのパッケージでこういうのは出てるけど
本当に影響あるのってあった時に普通にコード読むとか
できるとね
あと知識とかもね
ただそれスケールしないっていう問題もあって
セキュリティチームのそのメンバーが
それを全部やってると全然スケールしないので
それはそれでまた悩ましいところではあるんですが
そうだね
今はねうちは
開発エンジニア20人
回ってるのかな回ってる
100点は取れてないと思うけど
まあまあそこそこ回ってるみたいな感じだけど
大体なんかあれはあそこにあるよねみたいな
見通しが立ってる状態でしょ多分
そうだね
どこに見に行けばいいのか分かるし
これが開発者40人60人とかになった時に
セキュリティチーム同じレベルのメンバーを
2人ずつ増やすわけにいかないんだから
まあちょっとやり方変えなきゃいけない
例えばもう俺はうちのそのコードは正直よく分からん部分の方が多くて
見たことないコードの方が多い
それでも大体みんな号で書いてるからなんか別に
読みに行けば分かるけど
ただそもそもこの機能どこのサービスが持ってんのか分かんない
マイクロサービスアーキテクチャーだと
名前からなんかゲスするしかなくて
はいはいはい
サービスカタログみたいなの欲しくなるね
欲しいね
こいつの裏に何がいるのとかの見通しがなんかすごく悪い感じがする
ちょっとデカすぎるので正直もう分からんので
そこまで行くともうなんかその
コード分からんと話にならんよねみたいなこと言いはしたけれども
もうなんかその分かるの要求レベルが高くなりすぎて
なんかちょっとしんどい感じがする
またそのなんかまあ文業を進めていったりするのかなってイメージは
あったりはするけどね
まだなんかその難しいとこだね
なんかどういうそのそうなった時にどういう体制が望ましいんだっけ
みたいなのは結構悩ましい難しいところで
その辺でフリーさんのセキュリティーチャンピオンはどうなってるか聞きたいんだよな
フリーって何人くらいいるのかな
前グループ全体2000人じゃなかった
そんなにいるのフリーって
収録で調べたよ
1700人でした
そんなにいるんだ
でも営業さんとかも多いんだよねきっとね
そうだねエンジニアプロダクトチームで言うとどうなんだろう
確かにどんぐらいなんだろうね
まあでもその部分的にマイクロサービスアーキテクチャーだった気がするし
結構そのなんだろうな
かなり多分1チームが全部把握みたいなのは厳しそうな雰囲気はする
アドベントカレンダー見てても
いろんな機能とかフリー触ってたら思うんだよ
あれなんですけど日々頑張ってます
フリーは結構大きいんだな
次行きますか
花のある部分しかっていう部分に対して実際はこうだよっていうのが出てきたので
いい記事でした
チームのさらなる取り組み
ありがとうございます
泥草チームで売っていきます
次がApple Googleと米司法庁の独近法裁判へ介入
ユーザーに悪影響というインプレスウォッチさんの記事ですね
普通にニュース記事ですね
Appleが何回か話題にしてる
ここでも話題にしてる
Googleの独占禁止法違反裁判への参加の意思表明をしたよという記事で
Chrome手放せとかModularとかAppleへのお金の流れを止めなさいみたいな話とかが争点になっていたんですが
それやられるとApple側も困るので
困るからAppleも当事者だし
Appleの不利益についてGoogleが代表する立場にはないよねみたいな話とかが書いてあって
ゆえにAppleも混ぜろっていう形で参戦しているらしいです
Modularも声明出してたんですね
取り上げ忘れちゃったんだけど
ログイン機能の設計
書いてあることとしては現状が公正な競争環境でないことはModularは同意するけど
それへの対応策として今の秘書省が出している対応案はとて受け入れられない
そのかえって競争環境が発火させる可能性が普通にあるよねっていう部分と
Modular自体ももちろん立ち行かなくなったらブラウザーエンジンのうちの一つも潰れるし
あとModular自体がシェアは大きくないけど
守っている領域をユーザーの領域っていうのがあって
Chromeでは実現できないプライバシーの保護とかそういうのを望むユーザーに対する選択肢を潰す
Modular始めいろんなブラウザーが提供して潰すことになります
なることはWebにとって望ましくないみたいな
超ざっくり言うとそんな感じですね
いいですね
これでいい方向に行くといいなとは思っていて
理屈的にはその
明治法書的には他の会社を守るためにGoogleを産んだんだけど
他の会社はやや違うだろって言ってるってわけだから
ちゃんと声は聞いて欲しいなっていう
するけどね
あとマイクロソフトか
マイクロソフト
なかなか盛り上がってまいりましたって感じがするね
これ何かいつ
続いてるのか裁判自体は
そうだね多分その2時期
そうだね
まぁちょっと見守りたいですね
今年の前半ぐらいで何か一つ
いやーでも時間かかるかな
ドキドキしますね
どうなることやらっていう感じなんですが
頼むアップル様
アップル様っていうかみんな頼む
あとModularは何か
さっき言い忘れてたけど良かったのはその
別になんかGoogleが金くれるから
Google検索をデフォルトにしてるわけじゃないって話も結構書いてあって良かったですね
いろんな検索エンジンをもちろん試してきて
ユーザーにとって価値があるかどうかっていろいろ考えてきて
結果Googleになってるんであってみたいなことを
結構強い温度感で書いてましたね
確かにね個人的に思ったりしたんですけど
ありがとうございます
次は私ですね
当人認証 見元確認 クレデンシャル設定を組み合わせた
積みにくいログイン機能の設計
リトーさんだかRリトーさんだか分かんないけど
リトーさんの記事ですね
タイトルの通りなんですけど
当人認証と見元確認とクレデンシャルリセット
3つを組み合わせたログイン機能の設計についての話
ユーザー視点やサービス視点それぞれでのリカバリの見え方とか
アカウントリカバリの手段の見え方とか
リカバリのポリシーはサービス側で決めなきゃいけない部分もあるんだよ
みたいな部分の話とかを書いてくれてる記事です
なんで俺がこれを紹介してるかっていうと
この記事で言う当人認証と見元確認がごっちゃになってる人が多くて
なんかしんどいことが割とある
この辺の前提の知識が揃ってる人と話すだけでかなり安心できるというか
なんかしんどくないという場面がよくありまして
全人類これを読んでほしいなと思った次第でございます
AIとマルウェアの関係
なるほどですね
僕は多分恥ずかしながらごっちゃになってるか分かんないけど
認識ができてなかったんでちょっと勉強しますって感じですね
またなんかNIST SP800シリーズでこの辺
いろいろ定義されてるって部分は知らなかったのでちょっと読んでみようかなと思って
なるほどね
ちょっと正月を受けした後まで読む時間がなくて
きちんと目は通してないですけど
前事前読んでください
会社で読んでくださいって言おう
別にこれ読まなくてもいいと思うんだけど
要は会員登録の時のそのSMSにOTPが飛んでくるやつと
ログインの時にSMSにOTPが飛んでくるやつは役割が違うよねっていうのを
説明しなくても理解できるかどうかっていうのは会話をする上でかなり
なんていうか例えばですけどね
そこの認識違ってたら会話が成立しないじゃないですか
相手が言っているそれが何なのかがもう分かんないわけですよ
今の俺直近の仕事であったことを思い出して
なるほどなって気持ちになったわ
あとは例えばパスキーとか話をする上でも
パスキー設定以前にユーザーが持っていた情報資産を
後からパスキーの設定をさせたとて
一貫してパスキーで保護することは不可能ですよねっていう話とか
パスキーで保護されている機関の中に取得した情報資産は
パスキーで一貫して保護されているけれども
それがずれていたら一貫して保護することはできないですよねみたいな話とか
サービスとか機能のエンロールメントの時点でパスキーを設定させる
あるいはパスキーの認証を一回そこで通す挟むみたいなのが大事なんですよみたいな話とか
なんか保護したいものが何なのか保護する方法が何なのかとか
どうやったらその保護の要件を満たせるのかみたいな部分の話とかって
なんて言ったらいいんだろう
まあいいやちょっと愚痴っぽくなってきちゃうけど
なんていうか
言いたいことは分かる
その辺が共通認識としてシンプルに持っておかないと多分
そう別にしかもそんな難しい話じゃないと思うんですよね
例えばあなたが家を建てました
玄関のドアにしばらく鍵がつきませんでしたって言われたら
例えば監視カメラを置くとかで対応はできるかもしれんけど
鍵がつくまでの期間誰も入ってないことを
じゃあ担保できますかそれでっていう
例えばですけど
誰か勝手に入ってるかもしれないじゃないですか
まあちょっと鍵の例えはイマイチすぎるけれどもさすがに
そんな難しい話じゃないと思っていて
別にセキュリティが分かる人とか認証認可が分かる人だから
それが分かるみたいなそういうもので全然ないと思っていて
まあね確かに
いやでも意外と分かりやすく説明するの難しいかもなってきは
意外とね
その概念としては現実世界の何かで置き換えられるようなものでは
正直あんまりないと思うので
そこがなあそこが難しいんだよなあ
なんかの時にもちょっと思ったんだよなあ
これ物理世界で同じ概念ないなって
ないね
うーん
なんか
いやでもちょっと
精査してきちんと読もうと思いました
まあ読んだんですけど
ありがとうございます
みんな読んでください
じゃあ次僕ですね
なんかAI
AIマルウェアばっかり引っ張ってくるな
まあはい言いますけど
ハッカーニュースの記事で
この記事自体は
なんというかこのタイトルのものとプラス2トピックぐらい
マルウェア関連のトピックを取り上げてるんですけど
ここではちょっとタイトルで取り上げられてるやつだけ
ちょっと話したくて
さまにいろいろ書いてるんですけど
記事中だと
AIに
LLMに
元のオリジナルマルウェアがあって
そのマルウェア元に足を1万個以上ババって作らせて
その作った足のうち88%がスキャナー
ウイルストータルとかも含め回避できましたっていう話しか書いてないんですけど
元ネタの方を見るともうちょっとちゃんと詳しく書いてあって
回避するために作ったっていうよりかは
スキャナーを作ってる会社っぽくてなんで
これが脅威だよねって話と
それに対して
それに対応するスキャナーを作りますよって話をしてるんで
もうちょっと読み込んだ話をしてて
そっちの記事も読んでみてちょっと面白かったのが
まずメモを上から順に読むと
LLMってそもそもマルウェア作ればいいじゃんって話が
発想としてはあると思うんですけど
少なくとも今時点でLLMのクオリティだと
一から有効なマルウェアを作るっていうのはまずできませんと
できないんだが
既存のマルウェアのアシを作るのは結構簡単でっていうのが
趣旨ですと
実際に作ってみて結構回避できちゃいましたっていう話で
これなんで回避できるようなものを作れるのかっていう話で
そもそもLLMじゃなくても
マルウェアのアシを作るようなツールってある
すでにありますとあるんだけど
そことの違いとしては
既存のツールだと結構
敵にも守る側にも知られたプラクティスを
何かしらのロジックで適用してるだけなんで
スキャナー側も割と対応はしやすくて
例えばオブフルスケータード対応っていう
NPMライブラリなのかな
要するにスクリプトの読み込み元として
あるあるで仕込まれるような
JavaScriptホスティングサイトがあって
そういうものとかが使われてるってなると
大体のスキャナーはそれを見つけて
弾けるようになるから
ツールで作った足とかも
弾けるよって感じなんだけど
LLMはその辺の
決まった型じゃなくて
ある程度
自然言語で指示出して
こういう風にやると
従来のものより
従来のツールよりも
検出率が上がるっていうのと
まだちょっと僕の
見せ方を理解できなかったんですけど
もともとのオリジナルのマリア
加工後の足のマリアがあったときに
従来のツールだとLLMによるものだと
ソースコードに含まれるランダム性みたいなものを
分析したときに
オリジナルにより近いものを
LLMで生成できるって話があって
よくわからんけど
この辺がスキャナに効いてそうっていう感じらしいと
面白かった
もう一個ちょっとおもろいなと思ったのは
これ実際にやってみたっていうのも
ちょっと解説されていて
サンプルとして
悪意のあるJSONのサンプルコードをまず用意して
それ自体はウイルストータルに突っ込んでも
真っ赤くなるし
この記事を出してくれてる会社の製品でも
検出できる状態
スコアとしてもほぼ100%
0から100で100が怪しいっていう感じだけど
100%なんだけど
そこからLLMにまず空白を削除させて
これだけだとちょっとしか低下しないし
これ多分ツールでもできるんじゃないかなと思うんですけど
その後特定の文字列を表現して
多分この文字列を分割するみたいな感じで
指示出してるんですけど
文字列の変数みたいなのを
ほんとシンプルに
ABCって文字列使ったら
AプラスBCみたいな感じで
バラバラにするみたいなテクニックを
仕込むことで
まず100%だった点数が91%まで減って
その後変数名を変えるっていうのをやってみて
この変数名自体はある程度ランダムに
やってくれみたいな指示を出して
これをすると
マジかと思ったんですけど
情報漏洩の背景
91%だったスコアが0.75%まで下がっちゃって
ウィルストータルの判定も
グリーンで通り抜けられちゃったっていう
これはなんかそのエクスキューズとして
このサンプルにはこういう手順で
ここまで精度下げられたけど
多分適用する周りは次第で
どういう指示をどういう順番で
LLMに出すかっていうのは
チューニングが必要っていうのはあるらしいんだけど
なんていうかあんま高度なことをせずに
大胆にスコアが下がっちゃってて
おおっと思ったって感じですね
一応この記事の締めとしては
これを守る側
このスキャナを作る側なんで
作る側で自分たちでやって
自分たちの好きな穴を見つけて
改善することで10%くらい精度を上げました
締めくくりにはいってるっていうような記事ですね
なるほどね
やってること自体は
よくある何度かのあれと
かなり近しいと思っていて
ミニファイして
文字列の分割をします
レンズ名の変更は
ランダムじゃないんだけど
短いものに変えますとか
これ自体はかなり
よくあるやり方な気がするんだけれども
ここまでは
そうなんだよね
いろいろ目によらせると
いい感じにできてしまうらしい
だから何度かのパターンが決まっているはずで
記事のものだと
そういうパターンから外れるから
パターンマッチングをしたときに
外れるんだろうねきっとね
変数名のパターンとかもあると思うし
確かに確かに
0Aが必ず出てくるとかさ
0Aの続きに0Bが出てくるとかさ
たぶんいくつか変数名のパターンとか
絶対あるはずで
お決まりのパターンとか
ミニファイは変わらないだろうからな
ミニファイ自体も
だと0.1%ぐらいしかスコア下がらなかったから
そういう意味ではたぶん
LL名でも対応してるんだろうね
なるほどね確かに
っていうのでたぶん外れるんじゃないかなとは
思うんだけれども
面白いですねこれは
こんなシンプルにいけちゃうんだな
なんか結構
なんていうか
スキャナー通せば安心は
別にもともと思ってたわけじゃないけど
まあまあなかなか言えないよな
っていうところと
まだこの
この記事出してくれてる会社も実際やってるし
他の会社もやってるのかもわからんけど
LL名前提でスキャナーもアップデートしていくっていう
もしくはLL名自体に
違う違うスキャナー自体にLL名を組み込むとかも
もしかしたらあるのかもしれないですけど
なんかその辺のいたちごっこが
防御側が頑張ってほしいなっていう
運用不備と発生原因
しみじみ思いつつって感じですね
まあたぶん極論都度
その何度かを
別々に何度かして出してくるとか
普通にやってくるだろうし
これだけコストが低い
そうだねそうだね
てかなんかでもこれで下がるよっていうのが
上がってれば別にこれだけやる
その何度かツールって作れると思うから
LL名じゃなくてもいいと思うんだよな
あーどうなんだろうね
極論ね
そのやってること自体はさ
確かに確かに確かに
別にもはや機械化できると思うので
LL名じゃなくてもいいと思うし
うん
だからLL名でっていう話じゃないんだろうな
きっと極論
その知らん何度かのパターンが来ると
そのすり抜けがちだよっていう話でしかなくって
これって
うんうんうん
そうねー
だからその辺がねちょっと多分
このランダム性のところに絡んでる気がしてて
僕の脳みそは分かんなかったんだけど
LL名で生成したやつとツールで生成したやつだと
そのランダム性みたいなところの
法則が全然違うみたいなのがあって
まあでもそれが今言ってくれた話なのかな
どうなんだろう
このくだりがね
エントロピー分布の表があるんですけど
エントロピーが分かったら分からんと思って
まあよりだから人間が書いた風に見えるかどうか
っていう話なんじゃないかなと思うんだけど
どうなんだろうね
あーそういうことか
ちょっと元の記事の方読んでないから
何とも言えないんだけれども
うんうん
でも結構面白かったです
これ逆はできないのかな
あー逆っていうのは
何度かされたコードを人間が読みやすい形に戻す
っていうのをLL名使ってできないのかな
あー
できそうだけどね
スキャナーで別に
なんか白黒判定してくれるのはいいんだけど
そのどっちかっていうと逆じゃねっていう気がする
逆じゃねっていうか
人間がさその
なんかこう
読みたくならんかなと思うんだけどね
実際に何か対応してるタイミングにおいて
そのあれを日々集めて
実行してるような研究者ポジションの人たちは
もしかしたら
インシデントレスポンスの中でも多分必要になると思う
あーまあ確かに確かに
できそうだけどね
ねできそうだよね
得意そう
ありがとうございます
じゃあ次も私ですね
えっと
セキュリティネクストの記事で
セキュリティニュース
利用者間で個人情報が流出
同一アカウント発行で
スクーっていう記事ですね
タイトルの通りスクーさんで
利用者間での個人情報が流出しましたっていう
インシデントの話ですね
で記事自体にはあんまり
あんまりというかまあ
その3割しか書いてなくて
元ネタの
元ネタというか
公式が出してるお詫びみたいなのがあったんで
ちょっとそっちを読んでいろいろ
メモを書いて
で個人的には結構
なんというか他人事と思えなかったんで
わざわざ持ってきたって感じ
なんですけど
まずその
何が起きたかを話す前に
まず前提から話すと
この前提自体僕が報告書からちょっと推測した
ところなんですけど
まずそのスクー自体が
企業に対して
本契約みたいなのが多分あると
ありますと
でその本契約前に
トライアルというか
使用期間みたいなステータスがあって
ありますと
でその本契約前の状態では
お試しのアカウントを発行するというプロセスがあって
でこのお試しアカウントっていうのは
管理アカウントにぶら下がる形で
発行されますという感じですと
でこの管理アカウントにぶら下がる
この使用アカウントが
多分複数あり得るってことなんですけど
この複数の使用アカウントの間では
データのアイソレーションが行われない
っていう
まあこれは多分おそらく使用で
でこれ自体多分
これがバグとかっていうよりかは
その同じ企業に対して
例えば
じゃあ株式会社Aさん
お試ししますかって
しますって言った時に
3アカウントくださいって言われたら
同じ管理アカウントにその
ぶら下がる3アカウントを発行するみたいな
ユースケースが
多分想定されてるのかなっていう感じ
で
でこのお試しアカウント自体の発行は
スクー本社が行うこともあるし
そのスクーの多分
契約を
販売する代理店みたいなのがあって
その代理店がその発行を行うケースもある
っていうのが
ここまでの前提ですと
でこの前提のもと
何が起きたかっていうのが
2つで
1つがスクー側の運用不備による漏洩で
2つ目が
販売代理店側に
こういう風な運用をしてね
っていう指示が漏れてて
不備があって漏洩しました
っていうところで
で2つ分けられてるんですけど
起きたことは一緒で
シンプルにさっき言った
管理アカウントに複数
お試しアカウントがぶら下がってたときに
同じ管理アカウントの配下に
複数社のお試しアカウントが
ぶら下がっちゃってたとき
状態ですと
でその状態で
ある特定の機能を利用したときにだけ
相互に個人情報が閲覧できる状態になっていた
っていうのがこの事件の全貌という感じで
具体的になんだったっけな
多分なんか
集合学習機能っていうのがあるんですけど
スクールの授業とかを
みんなで同時に視聴しながら
視聴者間同士でコミュニケーションを取る
部屋みたいなのを作れるっていう感じ
でなんでその
作っちゃうと
多分何々さんが作った部屋だったっていうのが
参加する側から見えるし
参加
誰か部屋から入ってきたら
相互にインタラクションできるはずなんで
相互にその
何々さんと会話するみたいな感じで
同じ管理アカウントに
ぶら下がる環境であれば
見えるっていう状態が
多分漏洩につながったのかな
っていうところですね
でなんか個人的に
なんかちょっと
難しそうだなって思ったのは
漏洩件数めちゃくちゃ
少なくはない
少ない多いではないですけど
合計で980人で
発覚経路はお客様からの報告で
発生してた期間が
2020年の3月30日から
去年の12月23日になって
丸4年ぐらいですか
そうっすね
ぐらい
気づけなかったっていうのがあって
結構
なんていうか
かなりなんか
限定的な条件化じゃないと
見つけられなかったやつなんだろうな
っていうのを思うと
なかなか難しいなっていうところと
あとは販売代理店に
そのアカウント発行してもらう
っていうプロセスがあるのは
確かに事業としては
事業次第ではあるのか
っていうところで
ちょっと勉強になるな
と思ったっていう感じですね
これ詰まるってことは
仕様っすよね
管理アカウントに
ぶら下がる複数の
仕様アカウント間の
情報が閲覧できるのは
おそらく仕様だと
だからこれ要は
普通に契約している
ユーザー企業が
集合学習機能を使うと
その組織内における
アカウント間では
いろいろ閲覧ができるはずで
ってことですよね
多分ね
だから詰まると
運用でカバーしてるわけですよね
そうだね
デモ環境が欲しい
サンドボックス環境が欲しい
仕様アカウントが欲しい
みたいなユースケースに対して
運用でカバーを
やっていた結果
こういうことが起きましたよ
って話ですよね
いくつか
ほんと外からだから
推測しかできないけど
推測できそうなのは
言うても
情報管理の重要性
ドイツ管理アカウントかの
アカウント間で
個人情報が閲覧できることを
知らなかったっていうパターンも
ありそうだし
もしくは
そうだな
分かんねえな
でも管理
分かんないけど
どうなんですかね
言ってしまうと
言ってしまうとというか
弊社も似たような
プロセスがあるんですよ
微妙かな
全然違うけど
契約する前に
試したいみたいなところに対して
アカウントを発行したり
仕様アカウントの運用
環境用意するっていう
プロセスがあるんですけど
多分結構むずいのは
発行する人は
別にエンジニアとか
プロダクトチームじゃないことが
多いんじゃないかなって
気がしてて
この事件の前は
なおさら
販売代理店が発行できてるってことは
知識がない人が
もらったマニュアルをもとに
発行するみたいな状態だと思ってて
そうなった時に
相互に閲覧できてしまうよねみたいな
仕様を全然知らずに
その運用を
くるくる回してたっていうのは
全然考えられるし
かつ仕様アカウントだから
これって分かんないけど
同時期に複数社が
同時に仕様をお試ししてて
かつその機能を
同じタイミングで利用してるみたいな
結構な条件かぶんないと
気づかないみたいなところは
普通に複数社に営業かけてたら
普通に複数社が
仕様アカウント作るっていうのは
起こりうると思うし
あとはプロダクトチーム側が
そんな運用してたんですかって
なってる可能性も
全然あると思う
そこの
なんていうか
分からんけどね
でもさ仕様アカウントが欲しいんですって
普通に言われると思うしさ
じゃあこれ使ってくださいって
言ってると思うんだよな
プロダクトチームも
いや分かんない
でも販売代理店
すげえ外から
適当なこと言ってるだけなんだけど
でもなんか販売代理店が
作業してるから
どうなんだろうね
その時も
本社に指示
本社に問い合わせがあって
やってんのか
分かんないね
だってこんだけ普通に使っててさ
その相談が
言ってないわけないと思うんだよね
うーん
あとこれなんか
実務面の話を考えると
この
漏洩範囲の特定が
すげえだるそうだなと思った
そうだね
その
この仕様アカウントは
この期間から
この期間生存していて
みたいな
この機能を使ったのは
いつでみたいな
すげえだるい
その仕様アカウントが
同一会社なのかどうかとかね
そうそうそうそう
情報漏洩の特定
いやー確かにね
めっちゃ大変だね
それで言うと
特定できてよかったね
これ特定できてなかったら
すごいやだったな
あるいは
なんか若干どんぶり感情で
その
えーっと
なんて言ったらいいんだろう
上振れしない数字を
確実に上振れしない数字を
出してるのかもしれないけど
あーなるほどね
分かんないけどね
まあまあまあまあ
確かにね
確かに
最大でもこれで収まる
っていう数字で
もしかしたら
何らか出してるのかもしれないけど
うーん
確かにね
でもなんか結構
まあ面白いって言ったら
面白くねえよって本の中の人が
怒られると思うんですけど
まあすごい勉強になるパターンだ
と思ったって感じですね
個人的には
普通にありそうだけどな
いろんなところで
いやーなんかさ
思うんだけど
その
なんか
まあ
その
やめに余れず
こういう運用してたのかもしれないし
その
それ自体を
まあ
なんて言ったらいいんだろうな
その
うーん
まあそれ自体は別に否定する気はない
っていうか
なんか
それの正しい正しくないよ
あんまりこう
論じたくはないんだけれども
なんか
ある種の手抜きじゃないですか
これって
そうね
仕様環境を作りましょう
サンドボックス環境を
営業をかけてる会社ごとに
顧客ごとに作れるようにしましょう
とかさ
なんか
そういう部分を怠った結果
これが起きてるわけでしょ
うん
だから
その
なんて言ったらいいんだろうな
なんか
良くないですよね
こういうの
うーん
またなんか
その
このフォトキャスト外で話したことありますけど
その
もしかしたら
一番最初はこれで問題ない
それもあるかもしれないですね
営業スタイルとか
うーん
そういうその
集合学習みたいなのが
そもそもありませんでした
みたいな
ああ
当時はね
全然ありそう
全然あると思うけど
うん
でもさ
それも含めての話だと思っていて
なんていうか
だってどう考えてもさ
その
おかしいじゃん
そのデータの構造的に
まあね
まあまあまあ
お互いにこう情報が見えちゃいけないユーザー同士が
えーっと
同一のテナント配下にいるっていうのは
そのデータ構造的にやっぱりおかしいわけで
うん
でそれが使用のために
使用をするためにそういうふうにしてますっていうのは
なんか
なんて言ったらいいんだろうな
一時的には許容されることがあったとしても
それがその
なんて言ったらいいんだろうな
4年でしょうだって
4年
そこが
なんか
サービス提出上難しかったのかもなと思ったりするけどね
そのスクーってその
僕の理解だと
まあオンライン授業でしょ
データ構造の問題
うん
で2B契約ってことはその
わかんないけど
例えば
うちの会社にこの研修を受けさせるために
スクーのこの教材が欲しいとか
うん
なった時に
普通の使い方って
でもそれ使用じゃないじゃん
ログインして
使用
使用アカウントの話
ああ
まあでもどうなんだろうね
使用アカウントであるけど
まあ
わからない
使用アカウントが何を指すか自体は
言及されてないから
おため使用のアカウントじゃないの
こういう機能がありますよね
そうではあると
まあでも基本的にはその
契約した時に使えるものを
一通り使えばするんじゃないかなと思って
まあそれはそうだろうけどその
うん
本契約法はだって
作るでしょ
その
アカウント
アカウント
いやなんか
言いたかったのはその
その
今はそういう機能があるけど
その
元来のシンプルな
うん
スクーっていう
スクーのアイデンティティを
極限まで授業としたときに
残る機能としては
うん
なんかそもそもなんか
生徒が相互に情報を見えるって
発想に語り至りづらいというか
なんか
当時は普通にそうだったんじゃないかな
ああ
なるほどね
そう
ただなんかその
サービス拡大とか
広域があったらいいじゃんっていうので
いつの間にかできてて
でもその時に
リスクの評価を見直しはしなかったとか
誰も気づけなかったとか
そこが結構
うん
むずいんじゃないかなっていう
だって分かんないけどその
まあそうね
まあ分かんないです
まあまあ
外からでは何とでも言えるんですけど
なんか
見逃すべくして見逃した気もするんだよな
っていう
感じかな
まあでも
やっぱりデータ構造としておかしいじゃん
っていう
そうね
話に尽きると思っていて
僕は
うーん
まあね
うーん
まあそんな感じです
だって分かんないけど
ちゃんとしてるところって普通に
サンドボックス環境作ってくれません?
お試し用に
うーん
まあね
そうだと思う
まあちゃんとしてないって言いたいわけじゃなくて
その
まあさっきも言ったけど
正しい正しくないをあんまり論じたくないんだけれども
その
ビジネス上さ
その
何が正しいかなんて
なんとも言えないわけで
これが
実際にこういう事故が起きてなければ
まあそれが正しかったのかもしれないし
分かんないけれども
なんか
うーん
でも分かんないですよ
シングルテナントアーキテクチャになってて
環境作るのにめちゃくちゃコストが
まあでも
でも4年でしょって思っちゃうんだよね
その
いやだから
そうね
個人的には
もう
その
短くはできたんじゃないとは思う
うん
その
短くするチャンスは
あ
まあ分かんないけどね
あったんじゃないかなって気がするし
うん
自分が同じ立場に
だからねこれを起こさない
自分の会社で似たような事を起こさないようにしようと思った時には
なんかその
まあもうちょっとエリアはあるのかなって思ったりするかな
うん
まあ
言わなきゃいけないんだよね
こういうのね
ちゃんとその
うんそうだね
うん
いや分からんけどなんか
7年今の仕事してきて思うのはなんか
想像したことって大体起こるというか
まあ
そんなに
だからなんか管理アカウントの下に使用アカウントぶら下げるんですか
なんかそれ絶対事故りますよね
うん
で仮にそのそれやり始める時に思ったとしたら
起こるんですよね実際
うん
うん
いやその問題マジ普遍的だよな
うん
なんか開発でもあるじゃん
そうある
そのコードベース3年後に100パックされますよって言ったから
うん
やるじゃん
うん
なんか
何なんだろうね
そう何なんだろうねと思っててその
さっきも言ったけどある種の手抜きですよねこれっていうのは
うん
あると思っていて
分かんないけどね
中の人じゃないし
まあでも
外からワイワイガヤガヤ言ってるだけだからその
もし中の人聞いてたら本当に申し訳ないんですけど
うん
うん
まあその認識を取れるのは難しいよね
なんかセキュリティーを起こせたら難しい気がしててその
さっきの開発の話で言うとPDM目線とかを見た時に
分かんないけどプラス2ヶ月かけるだけで3年の寿命が4年になるかもしれないっていう
年末年始のテクノロジーの影響
のを理解させるのって超難しいように
うん
セキュリティーのこういうプラクティスじゃないけど
いや普通に考えたらこうでしょっていうものを
じゃあなんかそのために2ヶ月今のめちゃくちゃなアーキテクチャを改善しなきゃいけないっていう
選択を迫られた時にその2ヶ月を通していけるかどうかって
そのステークホルダーというか意思決定する人がどこまで理解してくれるのかって話になるし
そのいや起きる時は起きるんですよっていうのを
その本当に真に理解してもらうってやっぱ
まあ命題というか僕らの
そうなんですよね
まあそういう意味で言うと言い方悪いけれどもそのいい事例
そうだねそうだね
これ何社ぐらいに謝りに行ったんですかね
何社っていうのは出てたのかな
だって適時開示でしょ
いや本当だってなんか
なんか
まあそのさ
仕様アカウントのちゃんと機能として提供しましょうみたいな考えた時にかかるコストとか考えると
そのなんかまあそんな単純なものではないとは思うけれども
ただそれだけのためだけに適時開示までしてさ
なんか何社に謝りに行ったのかわからないけど
人数しか出してないよねだってね報告書でもね
人数しか出てない
だって謝りに行くわけじゃんなんか
そうですね
漏れちゃったところにも謝りに行かないといけないし
漏れてないところにもなんか
まあ下手したら説明を求められるって普通にあると思うし
だってずっとつきまとうわけでしょ
このあそこは過去にお漏らししたところだよねっていうのがずっとつきまとうわけですよ
なんだかなと思っちゃうんだよな
だってメルカニアンってまだ現金出てたとこだよねって言われてるでしょ
3年前の話だよって思うんだけど
なんか永遠に擦られ続けるわけでしょこういうのって
そうだねそうだね
2Bの事業でさそういうのって普通になんかそこそこ大きな傷だと思うし
特にね2Bだと
ちゃんとお金でお金なくなるよっていう話は
いろんな事例でインプットし続けなきゃいけないのかなって気はするんですけど
単純な人権運動もそうだし事業上の機械損失もあるわけじゃないですか
ちゃんとあそこまでそれも込みでいいよって言われたらもうそれはそういう会社ですっていうしかないけど
99%の会社はこんなことになるとはって思ってるはずだから
使用アカウントを綺麗に作るのにかかったコストと今回のこの一件で
生じる機械損失とか対応コストとかどっちが安かったですかって
ちゃんと振り返ってほしいよね
確かにね
まあわかんないでもその2020年当時でその使用アカウント機能みたいなのをちゃんともし作ってたとしたらもう会社が潰れてましたっていう可能性もなくはないわけで
だからこそさっきから言ってるように正しいか正しくないかをあんまり論じたくなくて
そこは正直何とも言えないんだけれども
でもそれでやり切ったと本当に今言えますかっていうのはすごく気になる
やり切った結果どうしようもなかったんですって話なのか
でも事故ってるわけじゃん現実
そうね
まあその振り返りだよね
どのタイミングで何の手を打ってたらこうならなかったんだっけみたいな
いやでもなまあまあまあ
まあ言うてもそんななんかそのセンシティブなものは漏れてないわけだもんねこれね
その要はスクーに登録し得るぐらいの中身しか見えてないわけでしょ
まあ氏名と顔写真とかが漏れてる可能性があるのかなプロフィール画像だからね
そうだねあとはその漏洩範囲も全員じゃなくて
その多分同じ機関に契約してた別の会社にみたいな感じであるから
まあだからオッケーとはならない
まあだからオッケーとはならないけどでもまあかなり継承の類だとは思っていて
なんか小さく済んだからこそここからなんかどんな学びを得られるかっていうのが大事なんじゃないかなと
すごい何様目線で話してるのかわからんけど
思いました
自分の自分の多山の石だっけ
うん多山の石ですね
自分もここに刻もうと思いましたって感じです
GitHub Copilotの活用法
まあ結構なんかそうですね割と勉強にしましたって感じです
ありがとうございます
じゃあ次お願いします
GitHub CopilotでTypeScriptのコードを生成するワザップっていうスライドです
どこで発表したスライドなのかなわからないけど
GitHub Copilotでいい具合にそのTypeScriptのコードを生成するとかサジェストさせるみたいなコツを紹介してくれてるやつですね
例えばコーディングルールとかファイル命名規則とかなんかこういう風に設定するといいよみたいな話とか
あとはこういうやり方をするとなんかうまくいかないよみたいな話とかをつらつらと紹介してくれてます
これ知らなかっためっちゃ便利
使ってみた
いやーVS Code
Intellijayどうなんだろ
VS Codeそろそろ使ってるのかな
でもIntellijayも一緒なんだよな
ああそうなんだ
VS Codeなんかいやーもうおじさんだからなんかきつくってその
あのキーボードのあれとかが
そうねショートカット覚え直しとか
あとなんかなんだかんだやっぱIntellijay金かかってるなって思っちゃった
そうなんだよねそう
ちょっとねどうしても馴染めなくてなんかWebStormが無料になったからもうじゃあそれ使うわって
あーなるほどね
確かにねコメント書いてくれてるけど確かにセキュリティ要件的なもんね
セキュリティ要件みたいなの組み込むとそのまあコード生成なのでそのレビューをしてくれるわけじゃないからなんとも見えないけれども
なんか何らか要件みたいなのそれこそさっき話したアクセス制御の部分みたいな話とかさ
なんかこういうのでうまいことできたりしないのかなって
その生成してくれるものが最初からいい感じになっていて
なんかよほど変ないじり方せん限り
それこそ先週か先々週話したAPIキーハードコードしちゃう君もなんかこれでちゃんと円分にしろとかいけるかもね
確かになこれなんかオーガニゼーショングローバルで設定できないのかな
オーガニゼーショングローバルでは難しいかもねリポジトリ単位にはできそうじゃなかった
そうだねこれリポジトリ単位の話だと
GitとGitHubディレクトリ配下だからそうだねリポジトリ単位になるから
オーガニゼーションでできるようになるかはどうだろうね
結局でもリポジトリ側で上書きできちゃうし
グローバルとそうだねパブリックプレミアなんだねこの人まだ
まあ将来的にはそういうのもできるようになるかもしれないけれども
あるとしたらこのGitHubコパイロットインストラクションズが
別のコパイロットインストラクションを参照できるようになったらいい
まあでもドットMDだからな
そうね
確かにその発想なかったな
なんかリノベートとかでパッケージとして認識できたらいいんだよねこれもね
オーガニゼーション配下にこれが置いてあるリポジトリがあって
そこで新しいバージョンのタグ切るとリノベートがワーって回って更新してくれるとか
まあ別にそれぐらいだったら自前で作ってもいいな
その組織内のリポジトリ全部更新して回るぐらいだったら別にやってもいい
プッシュして回るだけなの
確かに勉強になりますこれ
はいというお話でございました
DMMビットコインの不正流出
アドバンス
じゃあ次は私か
トレーダートレイターによるDMMビットコインのビットコイン不正流出についてまとめてみた
P.O.ログさんの記事ですね
サマリーはP.O.ログさんの時いつも書いてなくて
もうなぜならP.O.ログがもういい感じのサマリーになって
これって結局
なんかコールドウォレットの管理がそんなによろしくなくてみたいな話とかでしたよね確か
その経緯は確かにこの話なんだろうけれども
金融庁だっけ金融庁かどっかの省庁が発表したやつは見たんだ
あこれだ行政省これかこれかな
またAトックの設定がリセットされてて
我が打てねえ
頑張れ流れとしてはリンクドイン上で
トレーダートレイターという教員グループがリクルーターになりすまして
日本の従業員に接触して
その従業員に対して採用前試験をよそった悪意あるPythonスクリプトへのURLを送付して
それを自分のギターページにコピーしちゃって侵害されちゃいましたっていうのが入り口の部分かな
不正取引のリクエストが
その侵害を受けた従業員になりすますためにクッキーを盗んで
2MM従業員として不正取引のリクエスト改ざんしたものと認められます
しか警察庁のやつには書いてない
別の話か
もしくはどっかで触れられてたのかもしれない
話としてはシンプル
シンプルではないんだけど
APTではないんだけどそのレベルのところから狙い撃ちされちゃってっていう感じではありますね
ここに書いてありましたね
改ざんされたリクエスト送信
これあれか
銀行
そうですね
詳しくは読んでくださいって感じなんですけど
シンプルに思ったのは
これ入られた
わからない
侵入された入り口の人を攻めることがあんまりできない気はしていて
もう狙い撃ちでやられちゃってるし
別の記事にも取り上げたんですけど
このグループはじめ北朝鮮グループもバカすか金取ってるんで
なんというか
侵入される前提で防御しないといけないよなって改めて思ったっていう感じですね
あと暗号通過自体はもうめっちゃ狙われてるのはわかってるから
頑張ってたのかどうかわかんないけど
自分の事業次第では頑張らないといけないよねっていう感じですね
キャンプタウンは自転車活用するんだよね
そうですね
それはそうかも
でもGitHubに貼り付けたんでしょ
自分のGitHubページにコピー
リクルーターから来てる
GitHub上のPythonスクリプトにアクセスするURL
ああまあそうか
そうかそうだね
なんか別に業務環境で業務端末で実行するそのあれがない全然
2MM側のあれだな
一番新しいのこれか
再発防止策みたいなとこちょっと読んでくれよかった
話がねでかいし結構長いですよねこの話
そうだね8月ぐらい
これとあれと
なんかねあった気がするんだよね
当社銀行に対して暗号試算接種の具体的な手口や被害を防止するような
もうちょっと出てきそうだないろいろ
いやちょっとダメだな
話がかなり大きくて
どっちかというとだからこれはトレーダーのそのアクティビティーにそのフォーカスして
紹介してくれているので
うんうんうんうん
そうかこれで俺と打ったのに縫われちゃったのか
いやー
はいその感じです
まあちょっとね
だいぶふわっとこなし仕事になってきましたね
いや僕のちょっと読みが汗かったんだけどね
いや皆さん気をつけてください
はい次は僕かな
サクッと
お願いします
えーっとまあ軽くでいいんですけど
ボイスフィッシングによる不正送信被害が急増
詐欺電話の増加
警察庁が対策を呼びかけというスキャンネットセキュリティの記事ですね
で記事自体はそんなもうタイトルでほぼ回収って感じで
サイバー警察局頼りっていうところから
なんか古き良きポスターみたいなのが出て
まあこれが元ネタなんですけど
ボイスフィッシング自体はもうまんまですね
その電話でなんかいろんな
あの手この手で情報入力させたりするっていうやつなんですけど
ちょっと個人的に気になったのでウォッチしたいのは
どれぐらい被害出てるのかが
ちょっとこの収録までの時間だと見つけられなくて
このポスターとか記事には言及がなくてですね
なんかこれぐらい被害急増してますみたいなところがわかんないんで
シンプルに気になったなーっていうのと
あとなんかその
まあこのボイスフィッシングしかり
その詐欺電話めっちゃ短いなってきたなって気が
肌感としてしてて
今あのあれですね1月2日に収録してるんですけど
その正月に弟夫婦が家に来てくれて
大人4人僕のパートナー含め大人4人いたんですけど
なんかその詐欺電話の話になって
全員1週間以内に詐欺電話をもらってて
まあもしかしたら正月になってるとかもあるかもしれないけど
まあ僕以外はそんなに
まあ何ですかね
まあ人は関係ないか
まあでもなんかその
4人中4人かかってきてんのは結構時代だな
っていうところを感じたっていう感じですね
なんかまあ僕らみたいな人は引っかかんないし
引っかかる人いるのかなって思う気持ちもあるけど
まあやっぱいるんだなっていうのが
このニュースを見て思ったっていうところかな
また知らなかったんですけど
なんかボイスフィッシングはビッシングっていうらしくて
いいと思いました
だから僕の勉強不足で知らなかったです
はい
知らなかった
何でも舐めつけるね
そうスミッシングとかね
ボイスフィッシングで分かりやすいけどね
フィッシング協会のレポートにはさ
このボイスフィッシングが載ってこないから
なんかあんま把握できないなと思って
まあ把握する必要があるのか分かんないけど
ちょっと気になるなーって
なんかそれで思い出したんだけど
そのビデオってあるじゃないですか
ビデオ
ビデオ映像とかどうかな
あれもオーディオの資格版として
そのなんかラテン語の
ネタル言語とかビジョン
ビジョンの語源になってるような
ラテン語とかから派生して
なるほど
ビデオっていうのがなんかできたよ
みたいな話を見たことがあって
じゃあ同じの意味でビッシング
人間そういうの多分好きなんだよねきっとね
なるほどね
それとビッシング自体海外の造語なのかな
どうなんすかね
まあそもそもフィッシングがさ
ソフィスケイテッドフィッシングの
PHを取ってるフィッシングじゃん
だからそのフィッシングという言葉自体が
そういうなりたちだから
神話性が高いのかもしれないね
海外生まれるのかどうかちょっと分からんけど
いやー
ビッシングって単語でちょっと後でもっかい
調べてみよう
ボイスフィッシングで頑張って調べてたけど
まあはいそんな記事です
みんなも気をつけてね
そもそもでも知らん番号からの電話出なくない?
イミュータブルアクションズの紹介
出ないんだけど
基本出ない
調べてかけ直すはあるけどたまに
たまに
たまに出ちゃうな
たまに出ちゃう?
初期はピクセル使ってるんですけど
迷惑電話フィルター結構走ってくれてたから
がばんがん切れてたんだけど
最近なんか普通にすり抜けてくるから
迷って出ちゃって
なんだろうね
どうやってのかよく分かんないけど
めっちゃすり抜けてくるね
あとめっちゃ増えてる普通に
なんか微妙に電話を待ってる生活のシーンとかと出ちゃったりする
どっかに予約をしててとか
で登録してないじゃん1日その番号とか
あれこの番号だったっけなって出て
あなたのうんと上がってきてブチってきるみたいな
分かんないですけど
僕はそんな感じです
気をつけましょう
気をつけてください
これもなんかLLMとかですごい人間っぽい喋り方をするようなやつとか出てきたりするのかな
すでに出てきてるはず普通に
被害も出てるから
自分で出たことなくてさ実は
それで言うとあれじゃないさすがにその
ある程度狙い打ちコストがかかるだろうから
無差別で使われてるわけではないのかも
でもなんかニュースは見たことある気がする
あとその映像と組み合わせて音声とかもあるから
だいぶ
だからそっち側のコストが安くなってきたらとうとう嫌な感じになるじゃん
高くなることはあっても安くなることはなさそうだからな
どうなんでしょう
じゃあ次
ずっと僕だな
そうなんですよ
ほぼそうなんです今回
正月暇じゃなかったけどいっぱい読みました
すげー読んでると思って
やべー俺読むやつねーじゃんって思ってたんだけど
たまにはね
次が
D-2.1はイミュータブルなアクションなど
プロダクトウィークリー
2024年12月4日
11日27日
まあまあ記事のタイトルはあれなんですけど
サイボーツさんの生産性工場チームの
ウィークリーのやつですね
いろんな
いろんな記事の紹介をしてる記事の紹介って感じなんですけど
僕が話したいのは1個だけなんで
それだけフォーカスしてちょっと取り上げるんですけど
ギター部イミュータブルアクションズの紹介
APC技術ブログっていう記事が紹介されていて
知らなかったんでちょっと読んでみたんですけど
パブリックプレビューになってる
イミュータブルアクションズっていう機能があって
これ何かっていうと
カスタムアクション
これサイドパーティーアクションって読み替えていいと思うんですけど
そういうサイドパーティーアクションを
リリースするときって今は普通に
コードギター部において
マーケットにパブリッシュするだけ
以上って感じだし
マーケットにパブリッシュする必要もない
ですけど
これはオーシアイメージ
どっかなりで
ビルドしてパブリッシュするっていう仕組みですね
今までと何が違うかで言うと
まずアテステーションが必須なのかな
ビルドするときに必須なんで
出書証明が保証されるよって話と
あと普通に変更不可能なタグ
今のやつとかだと
タグ振っててもそのタグ振り直すと
裏側でコミットハッシュを入れ替えることができるみたいな話が
あったりするんですけど
そういうのはできなくなりますよっていうところと
あとはネームスペースは多分
スラッシュの手前の部分かなっていう部分で
不変性とか再作成ができないっていうところの特徴がある
なので一応作ってパブリッシュした後に
それを下げて同じものを作るとかが多分できない
差し替えができないっていう解釈でいいかな
って感じですね
個人的に思ったのは
これが普通にあるべき世界だよなって気がしてて
今だとさっき言ったように
タグ付け替えたらハッシュ変えられ
気づかずに差し替えられちゃうよね
そういうところはずっと脅威としては言われているし
なんでコミュニティフルハッシュで
ピン止めしましょうみたいなのが
GitHub側のセキュリティプラクティスの
ドキュメントにも書いてあって
普通にめっちゃめんどくさい
リノベート使えば多少楽なんですけど
やっぱめんどくささが否めないので
けどそれって他のライブラリでやったことないなと思うと
普通にこれがあればいいじゃんっていうところかな
あとパブリッシュ側が
オーシャイイメージでパブリッシュだるいなと思ったんですけど
実際パブリックプレイビューの中で
このアクション使えばできますってやつがあって
ドキュメント見てると特に何も
アティステーションして
アクションズパブリッシュイメージアクションっていう
公式のアクションがあるんですけど
これを呼び出すだけっぽくて
これなら全然すぐにできるなと思ったんで
ちょっと試したいなって思ったところですね
これでこうあってほしいっていう世界に近づけてくれてるって感じがして
いい話だなって思いました
2025年いい話オブザイヤーが決定して
年初にして
年初にして
これがね年末ぐらいにGAになって
やっぱ今年の大賞でしたねってなるといいですね
まだパブリックプレイビューなんでね
なるかな
もうちょっといいもの出てきてほしい気もするけど
これもいいものだけれども
なんかその下の方にさ
GitHub認定試験について
GitHub認定試験が日本語に対応しましたって書いてあるじゃん
そうですねそれはあります
下らしいです
受けました?
まだ受けてないですそんな
そんな
そんな早くは受けらんねえかな
あれだってテストセンターで受けるやつだからいつでも受けられるんでしょう
子育て舐めんねえよそんないつでもテストセンター行けねえから
子持ちじゃない人とのなんか格差社会を感じるわ
格差っていうか
いやまあまあでもそうですね
まずそもそも勉強してないから勉強してない
勉強
ちょっと能弁で言ってみてよ
能弁で余裕だったわ
いやークッションズどうだろうな
ミクシー2に投稿したし
まあちょっとそっちはそっちは
まあ確かに今年は目標にしようかな
資格一個ぐらい取りたい
全館しよう
全部全部取ろう
GitHubの資格
任せろ
いい報告待ってください
いいな俺もなんかやろうかな
GitHubのアドミニストレーションはめっちゃいいだろうな
いやまじGitHubのアドミニストレーション持ったことないんですよ私
持ったらわかるけどね勉強すべきだなって思ったわ
それはね
機能多い
持ったことない
勉強する機会がないのが
持ってない人こそやるべきなのかなもしかしたら
自分で使えない機能の勉強してもしょうがなくない
それもそうね
まあまあまあ
何やろうかな
なんかいいもんないかな
程よいやつ
まあクションズ受けてくださいね
普通に
いやクションズ全員受けたほうがいいよ
ランボーカー全員
ソフトエンジニアみんな受けたほうがいいと思うんだよ
いいぞ
主語をでかくしていこう
主語をでかくして
炎上したくない
はい次
いきます
でね次が
まあはい
2024年国内セキュリティニュースの振り返り
日本は安全という神話の崩壊
最近のセキュリティトピック
っていうヤフーニュースですね
ヤフーニュースを取り上げる日が来るとは思わなかったんですけど
なんだっけな
これなんかアドベントカレンダーで入ってたのかな
やってたんですよね
なんで読んだんすけど
サマリーとしては
タイトルの通りで
去年ですね
去年の国内でセキュリティ等に関する
トピックをまとめてくれてて
ざっくり触れてあるのをザーッといっちゃうと
インプレゾンブによるデモの拡散がありましたよねとか
内部性でいうと
コンタクトセンター業務で
集まった個人情報を10年間
不正売却してましたっていう話とか
銀行の貸し金庫から
社員が金品を盗んでましたって話がありましたよねとか
あとランサムの話でいうと
SNSとかメディアが
リークサイトの情報を盛んに報道してたよねっていう
これは
ドワンゴさんのやつ
ドワンゴさんのやつですね
あれね
やはり
130億を超える売上高の減少とか
20億を超える特別損失を計上した
某電気企業って会社がいましたねとか
またその決算報告書がもう
ランサムの被害で間に合わなくて
停止前に調整したような事例もありましたねとか
またその
闇バイトの話とか
指示役に
その
闇バイトの指示役に役用される
個人情報みたいなところの話とか
あと先週
話しましたけど
DDoS攻撃が
中学生のお小遣いでできちゃいますとか
ストレス発散でやられるとか
そういう世界になってるねっていうのを
全体的にざっくり触れてくれてる記事ですね
記事の書き味とか内容自体は
僕ら向けっていうよりかは
セキュリティそんなに関心ない人向けかな
っていう書き味で
なんか日本が安全という神話の崩壊とか
これまでは正前説だったけど
正悪説やらなきゃいけないとか
そういうものがあって
その辺は僕は正直
ピンとこないというか
そうだったんだっていう感じ
なんで
気になるところがなくはない
一方で
なんでしょうね
昨今
実際に差し迫ってる
セキュリティ上の脅威というか
トレンドというか
こういう事件が実際に普通に起きてるんですよ
って話を
ざっくり
あんまり関心ない人に伝えるっていう意味では
なんかいい記事なのかなって
ちょっと思ったって感じですね
うん
はい
でなんか
セキュリティが分からないでは通用しない時代っていうのが
これは多分主に経営文脈かな
経営者に
セキュリティって分かりますかって聞いた時に
セキュリティってよく分からないって言う人多いですけど
それは通用しませんよっていうことが
一言がズバッと書いてあって
まあそうだなーってしみじみ
うん
思いつつ
まあまあまあって感じですね
はい
で
うん
なんか個人的には
フワッとシュッと刺す
刺し込む記事として
表面と
なんかまあまあ
あとは
まあ一通り事件知ってたから
自分キャッチアップ頑張ってたなーって気持ちにも
これはなんかあんま関係ないですけど
なってきました
この
一応ね事件とか全部
社名出てないんですけど
あああの会社と
これはこの会社だなってなったのは
偉すぎるなー
もう普通になんか
うん
忘れてるなー
え
え
うん
調べないと思い出せない感じではあるなー
うーん
まあ本当に全部はわかるんですよ
でもなんか
まあまあこの辺はそうだねとか
この辺
この辺とか
はい
これも
これはまあ役者が教えてくれたやつですけど
うん
あー
ありましたね
はい
じゃあ各位ちょっとこだわらせしといてもらって
じゃああとは
次いきますね
はい引き続きお願いします
もうずーっと
あと最後まで
あ最後だけ俺や
うん最後お願いします
じゃあ次は
replace.env with onepassado sdk
get started with secure programming
っていう
onepassadoさんのブログですね
でサマリーは
うーん
まあタイトル通りではあってですね
その.envファイルを
まあGitにコミットしない形で
皆さんよく使って
そこにAPIキーとか
環境変数として定義すると思うんですけど
それをonepassadoで置き換えられるよっていう話ですね
でその置き換え自体はVSCodeかな
VSCodeのプラグインを使うことができますよって話で
えーとonepassadoにその
設定した.envをボルトに
えー突っ込んどいて
まあそれでプラグインも設定して
でその上でいろいろちょこちょこっとやれば
.envに依存せずに使えますよっていうところとか
まあそうすることで
例えばチーム開発だったら
その一箇所で簡単にできますよねとか
ローテーション簡単にできますよねとか
あとはそのまあローカルに
一応ファイルを置かないことにはなるので
まあ何かしら侵害された時に
まあ比較的安全かもねみたいな話とか
が書いてあるっていうところです
はいなんか個人的にはちょっと思ったのは
結構便利かもなって普通に思ってて
チーム開発とかで確かにその
なんていうか
結局onepassに置いてるじゃないですか
こういう.envで共有していいような開発のやつって
だからそのドキュメントにonepassのこれを
ピピッしてこの環境変数として.envに設定してくださいとか
やってるはずで
それがなくなるのはいいなっていうところと
あとなんかそのonepassのこのシリーズで
そのsshキーとjcliとか一部のcliツールの
認証情報をonepassに置くっていうのが
設定できて
知ってから使ってみてるんですけど
結構シンプルに大抵いいなと思ってて
まあonepass契約してない人使えないんで
そこはあれなんですけど
個人的には推せる機能だなと思いました
っていう感じですね
これ.envじゃなくて.envrcとかでも使えるかな
VS Codeのプラグインだから
そのプラグインの使用次第かな
envrcはリアenvだよね
そうそうそう
思ったんだけどこれ.envがさ
でもそうか.env
ごめん勘違いというか
あんま禁止しなきゃいいやつだったかもしんないんだけど
.envの内容がさ
即座に環境変数に展開されるような構成だと
そのonepassWordの侵害が
要は横展開に使われそうだなってちょっと思った
あとはローカルで変更した時にどういう形で
例えばonepassWordチーム内で
ローカルで.envをいじった時に
それが横展開されますという形だった時に
.envの内容が即座に環境変数に展開されますよ
という構成になっていると
ちょっと怖いなって一瞬思ったんだけど
そうすると.envだとその辺は
変更が構成がかかるとさ
.envアラウを打たないとコマンドとして
展開されないじゃないですか
って思ったんだけど
ただ.envって
即座にそれを環境変数に展開するような構成って
あんまりやらないよなって思って
言うてもアプリケーションのコードから読み取るとか
はよくあるけど
そうだね あとはその辺聞く知ってか
何でか分からなかったけどboltをわざわざ1個切ってて
それはそういう理由だったのかって今気づいたわ
多分.envに
実際には.envにこういう
ふうに設定するんだけど
そのboltをちゃんと切らないと
そのboltの中にあるやつは
今映してるのはカスタム言われるんですか
カスタム言われる系で抜けちゃうから
そういう意味ではちょっと気を扱わないといけないのかな
なるほどね
だから本来参照しなくていいbolt2
っていうパターンがあるのと
自分が見えちゃいけないものとかも見えるようになっちゃう可能性があるのか
というよりかは
多分流れとしてはboltがあって
そのboltにこのSDK経由でアクセスしていい
っていう許可をまずワンパス上でするはずで
それは既存のboltを利用しちゃうと
.envに設定しないやつもすでに入ってた場合に
それに.env経由でアクセスできるようになっちゃうから
それは良くないよねって理解
そうだね
まあでも
そうですね
何にせよ開発環境以外では
あんま使わない方がいい
開発環境以外で使わなきゃいけない場面じゃないと思ってるけど
開発環境以外で使わなきゃいけない場面は間違いないんだけれども
とはいえ端末の
侵害の横展開とかに使われそうだなって一瞬思った
onepassadoの利用
うん
ちゃんと設定してれば大丈夫なんじゃないかなって気がするけどね
大丈夫っていうか.envにベタ書きパターンとそんな変わらない気がする
おそらくね
というより
言いたかったのは
ローカルでの変更あるいはワンパスワードでの変更が
即座に
そういうことか
.envに書いてあることは特に問題意識してなくて
外から入ってきたものがそこで展開されるっていうのが
なんだかの侵害の経路になるんじゃないのって一瞬思っただけ
確かに確かに
それは
.envを読み込むアプリケーションの仕様もあるだろうね
もしかしたら
分かんない
大半はホットリロードで対処ファイルの変更が入ったら
とかな気がするから
環境変数の変化は見ないと思うんだけど
分かんないですねフレームワークによるかも
何とも言えんなと思ったところなんですが
そうすると.envの作りって
なんとなく
理にかなってたんだなってちょっと思って
一人で納得してた
いい話だ
ありがとうございます そんな感じです
僕の今日の最後の紹介記事なんですけども
アクションズチェックアウトの
パーシストクレデンシャルズを
フォルスにするリンターと修正するっていう
鈴木俊輔さん
我らが鈴木俊輔さんの記事ですね
記事としては
紹介したことあると思うんですけど
ギターアクションズの積極プラクティスに
準拠するためのリンターツールがあるんですけど
それのV1.2.0の新機能として
アクションズチェックアウトのパーシストクレデンシャルズ
GitHub Actionsの新機能
っていうオプションをフォルスにするっていうのを
強制するルールが追加されましたっていう
アップデートがありました
このオプションって何かっていうと
知らなくてこの記事で勉強したんですけど
チェックアウトするときに
チェックアウトって裏側としてはGitクローン
何かしらの方法でしてきてるはず
実行したアクションズのリポジトリ自身を
クローンする場合であってもそうのはずなんで
そのときにGitコンフィグとかに
クレデンシャルを設定してますと
それは何を設定してるかは指定したアプション次第で
GitHubアクセストークン デフォルトだとGitHubアクセストークン
アクションズ内でだけ使える
GitHub.トークンっていうのがあるんですけど
それを使ってるしSSHキーを
指定するような場合は多分それがクレデンシャルとして
設定されていてそれを
このアクションズチェックアウトの実行ステップ以降も
保持するかどうかっていうのを指定するオプションが
パーシストクレデンシャルズですと
このオプションはデフォルトだと
トゥルーになってるんで
何も考えずに使っていると基本的にはこのステップ以降も
そのステップでGitクローンするために
使ったクレデンシャルに
別のステップも原理上アクセスできるっていう状態になっていて
なんで何がまずいかっていうと
その後続のステップに
サドパートアクションになり
アクセスされたスクリプトを実行される
もし起きた場合にそのアクションチェックアウトで利用した
クレデンシャルがアクセス可能になってしまうので
それは意図的でない場合は
やらない方がいいよっていう話で
リンタのルールとして追加しました
これそもそも
このオプションをデフォルトでフォルスにしようよっていう
イシューが立ってて議論はあるんですけど
実現はされてないっぽくて結構前から一周渡ってるみたいなんですけど
これデフォルト
向こうにすると壊れるやつがいっぱいあるのかな
そうだろうね
GitHub Actions API自体のバージョニングってできてる?
APIのバージョニングはできてる
でもこれGitの話だからおそらく
Gitクローンとかをしてるわけでしょ裏側では
API経由なのかな
GitのコースかどうかはGitHub Actions
それで言うとActionsのバージョン管理はしてない?
してないっていうか概念はない?
ないねないわ
今YAMLファイル見に行ってたんだけど
Docker Composeとかバージョンがあるじゃん
サークルCIとかもあったよね
そういうのがないかなと思ったんだけど
ブレイキングチェンジは結構ちょこちょこ
Actions of Artifactsとか入ってるけど
Actions側でやるべき話なのか
Actions Checkoutでやるべき話なのか
それだったらActions Checkoutだったらバージョン切ってるからさ
Actions Checkoutはバージョン切ってるから
普通にActions Checkoutでやるだけだと思う
これ実行環境の話じゃないから
Actions Checkoutの挙動の話だね
Actions Checkoutでデフォルトフォルスにしてくれればいいんだよね
セキュリティのリスク
それはあんまりやらない理由なさそうだけどね
既存のバージョンでっていうのは確かに難しいだろうから
今後のバージョンはっていう感じでやるしかないけど
だってしたらブレイキングチェンジでメジャーアップデートでやることに
やるとしたらやめると思う
やれない理由もなさそうだけど
そうなってくれればめっちゃ多分一番楽
ね
これ僕知らなくて
知ってましたこれ
知らないっていうか
そういうオプションがあるのを知らなかった
僕自体が見えちゃうっていうのは何となく分かってたけど
知らなくてね
具体的にどういう
理屈は分かるんだけどどういう場面でまずいのかが
最初パッと思いつけなくてメモにバーって書いたんですけど
普通に外部で提供してるアクションズに
悪意のあるものが入ってきたらアウトだよね
そうだねただ
ケースバイケースかなって気はしてて
例えばサーディパーティアクションズの場合は
github.tokenを何もオプション付けずに
アクションチェックアウト付けた場合は
パーシストクレデンシャルズをフォルスにしても
トークンは抜けるんですよ
サーディパーティアクションズの使用というか
参照できちゃうんでgithub.tokenっていう
githubアクションのコンテキストを参照できるから
パーシストクレデンシャルズをフォルスにしても
同一ジョブ内だったら参照はできる
だけど
一方で確かに任意のスクリプトを動かしたパターンの時は
スクリプトからおそらくコンテキストにはアクセスできないんで
確かにパーシストクレデンシャルズをトルにしたら
安全ということに
自分の脳内で整理して確かに価値がありそうというところと
あとプラス明確に価値があるのは
アクションチェックアウトに別のトークンを
明示的に指定してるパターンの時は
それこそSSHのクレデンシャルとかを
明示的に使ってるっていう
そうだね
そういうのはシークレッツとかと何かしらで指定してるから
そういうのをサードパーティアクションから
サードパーティアクションはそこにはアクセスできないから
確かに価値があるというか
パーシストクレデンシャルズをトルにしちゃうとファイルに残るから
誰でもアクセスできるって状態なんだけど
それを防げるって意味ではかなり価値があるなっていうのに気づきましたというか
僕の脳内整理がされました
ポリシー管理の考察
難しいですね
確かに実はピント付けれなかった
結構アクションズ取り付いたね
そうなんだよ
ギターブトークン
考え方としてはギターブトークン自体は元々コンテキスト経路では
同一のジョブ内で誰でもアクセスできるし
できて
かつサードパーティアクションからは
アクセスできるっていう状態で
そのアクセス経路に実はアクションズチェックアウトを使った場合は
Gitコンフィグに入っちゃいますよっていうパターンがあったっていう
そういう考え方はたぶんスッキリするかなっていう気がするかな
うん
難しい
難しい
実物を示されないとパッと頭の中に入ってこない
そうだね
これたぶん手元で動かすのが一番分かりやすい気はしてて
あえて具体的なコードは載せてないって書いてあるから
うん
それがいいのか悪いのかは分からんけど
やってみるか
たぶん別に普通にできる気がする
これちょっと一個悩んでるのが
会社内で有効にしたいんだけどさ
これ説明できねえなと思って
できるけど
アクションズ不便じゃんやる側
開発側ちょっと不便だなと思って
まぁでもやったほうがいいんだよなって気持ちで
デフォルトでフォルスにしてほしいなって気持ちになりました
ちなみに一括修正は
一括修正のツールを
鈴木さんが出してくれてるんで
ご安心をって感じで
隙のない記事にはなってるんですけど
まぁでもそもそも動きが壊れちゃうみたいなところまでは
カバーできないわけでしょ
暗黙的にそこに依存してるスクリプトがあったりするとアウトだね
まぁでもそれもプルリクエスト作った段階で
気づけるっちゃ気づけるから
とりあえず一回やってみればいいんじゃない
プルリクエスト順番に立てて回っていけばいいじゃん
事前にお知らせした上で
そんなことしかやってねえんだよな
リンター入れちゃえば
以後の支援を求められるから
っていうところから始める
増やさないから始めて
GHAリント自体はかなり大規模に導入してるんで
いつもお世話になってますっていう感じですね
GHAリントを
とてもいいというか
ないんですよ
外の動きをするものがマジでなくて
これ
実質一択というか
ルール何倍も僕は結構直感的に
このルールが欲しかったというものしかないんで
ありがたいなって感じですね
アクションリントGHリント組み合わせれば
それに従っておけば
大半のことは何も考えずに書けばいい気がする
ありがとうございます
大変勉強になりました
いまいちまだ理解しきれない感じがするけど
ちょっと手動かさないとわからんけど
次が
セキュリティ活動を
カフスでいいのかな
カフスマトリックスで整理してみたっていう
アドベントカレンダー12月23日の記事ですね
フローとストックっていう本があって
その本をヒントに
フローとストックの考え方から
セキュリティポリシーから実務までの接続について
考察した記事です
カフスマトリックスっていうのが
具体コンクリート
抽象アブストラクトフロー
ストックの四概念二軸の
マトリックスで
その上で
セキュリティポリシー絡みのいろんな業務を置いてみて
考えるみたいなことをやっている記事なんですが
まだ
結構詰められる余地あるんじゃないかなと思うんだけれども
考え方が興味深かったので
紹介したいなと思って持ってきました
なんか
そうですね
セキュリティポリシーなどの文書とともに
実現される状態そのものもストックに分類されるんじゃないか
みたいな考え方とかは僕はちょっと違和感あって
これだと環境要因での
状態そのものへの影響とかを
吸収しきれないんじゃないかなと
なんとなく思っていて
外で活発に活動している
脅威ファクターがあって
リスクが上がってますみたいな話とかは
これだと吸収しきれないような気がしていて
どっちかというとこのマップの外にある
っていう考え方かあるいはこのマップ自体を内包する
っていうその状態そのものの話に関しては
そういう考え方の方がしっくりくるんじゃないかな
とかそんなことを思いながら
何となく
大事だなと思ったのは
実務とポリシー管理の独立性というか
マッピングの下の方に全体像の整理というので
実際にマッピングをしてくれているイメージの図があるんですけど
実務とポリシー管理の独立性というか
独立性を担保した上で
この記事のここまでの話の中で出てきている
フィードバックの経路みたいな話とかがあったりするんですけど
フィードバックの経路を構築しないといけない
独立性を担保した上でフィードバックの経路を構築しないといけない
そういう説明をしたいときにハマりそうな気がしていて
よく言われる3ラインズモデルの
リスク管理とセキュリティの重要性
1線と2線の業務の抽象度の違いという風に
言い換えてもいいのかなとか思いながら読んでたんですけど
かなりフワッとした抽象度の高い話なので
あえて説明するような話でもないんですけど
結構色々と
いろんなところにセキュリティに限らず
いろんなものに効いてきそうな話だなとはなんとなく思って
要はガバナンスとかコンプライアンスみたいな部門というか
そういうところに関わるような
その業務をしている人には結構刺さる話なんじゃないかな
と思わんでもないんですけど
どうなのかなみたいなのをちょっと思っているというところですかね
はいはいはい
そうですね
僕はちょっとあんまり実は
たぶんちゃんと理解しきれてないところ
難しいなと思って
自分の中のストックとフローの結構
ストックとフローってこうじゃねみたいなところに
ちょっと噛み合わなくてうまく咀嚼できなかったんですけど
今の話を聞きながらちょっとなるほどなという気持ちと
うーん
まあ1つモデリングとしては
興味深いのかな
まあなんか別に考え方として何か新しいものがあるっていう感じじゃないんですけど
その整理がこれによってうまくできるんじゃないっていう考察をしてくれていて
結構なんか
僕は興味深いなと思いながら
読んでた感じですね
なんかこういう
こういうのにセキュリティの仕事始めて一番最初に
めっちゃやりたいなって気持ちがあったな
いやもちろん今もやりたいんですけど
なんていうかその
やっぱり広くて深くて曖昧な
曖昧というか抽象が高い取り組みもあるじゃないですか
好きに勝つとサイバーセキュリティというのを捉えたときに
だからなんかある程度
何かしらそのモデリングというか
こういう形で考え方でやりましょうとか
こういう構造でやりましょうみたいなのは
ないと結構動きづらいなって
当時はその勉強をどっから手つけようかって
気持ちがあって
そういうときになんかもう一つの回答として
なるほどなって
それで言うとなんか僕はもう少し広く見ていて
その例えばリーガルとか
プライバシーとか
うちの会社だとAMLとかも入ってくるんですけど
そのいわゆるスリーラインズモデルで言われるような
リスク管理を担うような部門部署
全般における
こういう共通の構造みたいなのがあるんじゃないかと思っていて
そういう考え方に見たときに
この考え方が結構興味深いなと思っていてた
それが正しいかどうかうまくはまるかどうかはちょっとわからない
正直わからないけどなんか興味深いなって思っていて
なぜそういう話をしてるかっていうと
セキュリティだけこうしたいですってめっちゃ非効率で
組織が大きくなればなるほど
リダンダントな部分が増えてくるというか
あっちでもこっちでも同じようなことしてて
効率が悪いみたいなのが普通に起き得ると思っていて
共通の構造を持ってるんだったら
その構造に基づいて
全部が一箇所に乗るような仕組みを作った方が効率よくないって思っていて
そういうものがあるんじゃないかと
うっすら思っているんだけれども
その中にセキュリティも含まれているっていう考え方
要は事業を行う上でのリスク全般において
共通する構造がなんかあるんじゃないっていう風に思っている
リスク管理を行う上で
セキュリティもだって別に極論リスク管理が
その根底にあるわけで
セキュリティだけこうですよねっていうのは正直ないと思っている
この構造は全てに当てはまるんじゃないかっていうのを
ずっと考えていて
勉強になります
でもそれをやらないと
例えばなんだけど
特定のリスクドメインがめっちゃ軽視されるとかが起こると思っていて
共通のフレームワークで
例えばリスク評価のフレームワークは
リスク評価のフレームワークとかを考える上で
リスク評価のやり方はリスクドメインごとに独立して
いろんなものを使っているんだけれども
出てくるアウトプットは共通みたいな形にしてあげると
あげないとまずそもそも
リスク評価のフレームワークそのものも
共通化しちゃうと
特定のリスクドメインだけめっちゃ軽く見られがち
みたいなのが起こるので
常にリーガルリスクよりセキュリティリスクが
後回しにされるとかが起こる
どう足掻いてもセキュリティリスクはリーガルリスクより大きな
例えばだけど現実にそうという話があって
どう足掻いてもセキュリティで見ている範囲における
リスクの最大値
同じフレームワークで評価したときのリスクの最大値が
例えば5だったとして
リーガルの見ている範囲でのリスク評価のフレームワークでの
リスク評価の最低値が
例えば6だったとすると
十何回でそういうような状況がもし起きたとすると
セキュリティで最大のリスクだと評価したとしても
常にリーガルリスクより優先度が下がる
リスク評価のフレームワークとかも
そういう話が絶対あると思っていて
みたいなことを最近は考えている
年末年始のメディア活動
なるほど
そういう視点で見たときの
できない
本業で忙しいじゃん
そんなこと言わないでよ
難しいよ 図解してよ
できないよ
できる人いるよ
なるほどね
私は本業ではそういうのを今考えていて
面白い
全然面白くない 普通に疲れる
それは知らない
普通にセキュリティやりたいな
でもぐるぐる回るんじゃない
セキュリティやっても結局そっちは抑えないと
結果的にはそうだろうなと思うんだけど
なんか横口でさ
リスク管理をちゃんとしたいよねっていう
気持ちがすごくあって
面白い
良くも悪くもセキュリティっていう枠から
飛び出ていろいろやってるっていう
ステータスではあるんだけれども
良くも悪くもって感じですね
水谷さんも最近ツイートしてたら
セキュリティリスク自体は数ある
軽リスクのうちの一つっていう
強制的にはないと何も進まないよね
確かに
視野が
僕はまだ視野がキュってなることが多いんで
確かに思いました
セキュリティじゃない何かで
リスク管理をしてくださいみたいなことを言われた時に
多分この記事で紹介してるような
考え方とか考察とかをするようになると思っていて
僕はそれを今の会社でできたので
良くも悪くも良い経験だったかなとは思って
なるほどね
リスクリスクって言ってるけど
あなたが言ってるリスクって何ですかっていうのを
具体的に何を指してるんですかそれはっていうのを
コンコンと突き詰めていくようなことを
散々やってたので
とはいえでもリスク管理って標準的には
こういうフレームワークがフローとかがありますよね
みたいなのを当てはめていく作業を
ずっとしてたので
興味深く読ませていただきましたという
紹介でございました
ありがとうございます
僕も今の話を受けてもう一回読み直してみようと思います
要は何て言ったらいいんだろう
多分あると思うんですよ
どうしてこれの優先順位が上がらないんだろうみたいな
コミュニケーションの問題だけじゃないんじゃないっていう
構造じゃないけど
整理の仕方とか
確かにね
確かに
もう決めてかかってしまって
そういうものですよ
言い方悪いけどある種押し付けるような
アプローチも時には必要なんじゃないかと思っていて
とはいえ
実務との兼ね合いってどうしても生じるよね
みたいなのはあると思うし
実務からのフィードバックで回していかなきゃいけない部分ももちろんあるし
どういうものが
うちにはフィットするんだろうねみたいな話を
考えないといけない局面が
絶対あるはずで
面白いね
局所的な形で見るんだったら
例えばコーディング規約の話とか
セキュリティ要件をその中に組み込みたいねってなったときに
実際に開発をしてコードを書いてる実務と
それに対してどういう規約を設ければ
実務の実際に開発者が書いているコードが安全になるのかっていう
ポリシーを作る側の視点と両方あるわけで
それってフィードバックのサイクルが絶対必要じゃん
こんなポリシーを定められても実務に落とし込めません
みたいなのは絶対あるはずで
例えばそういう感じ
構造的には
難しいな
入れ子になってるなって最近思わんでもないんだけど
要は
今のコーディング規約的なものをポリシー管理をする
人たちと実務をする人たちっていうのが
さっきのマトリックスのマッピングの図で言うと
右下の実務っていう青い箱の中に
同じ構造でまた存在していてみたいなのが
構造としてあり得るんじゃないかなって
このマッピングで言うとね
だから各々の業務の中での
局所的にこういう構造になっている部分っていうのは
なくはないんじゃないかなと思っていて
確かに確かに
今の結構イメージいっぱいとかも
こういうクソふわっとした話を
特に去年1年とかはずっとやってて
結論人は疲れるんですよって話なんだけど
キャッチフレーズみたいにすんだけど
いやーおもろいな
ありがとうございます
年史だけどいっぱい読んだね
いいなんかあれだったんじゃないですか
ポッドキャスト初めになったんじゃないですか
面白い記事多かった楽しかった
読んでないけど面白かった記事とかもあるんだよね
いろいろね
来週もなんか何だかんだ
年末年始に
入れてないだけ
年末年始学んだのは日本のまとめ系メディアは止まるけど
ブリピングコンピューターとハッカーニュースは容赦なく
記事ぶっ込んでくるっていう
いつ休んでるんやろうな
アメリカだと2日から普通に仕事らしい
自由の国と
Xでそんなことを投稿してる人がいて
日本人のDNAがそれを拒否している
俺もそうだな
2日から仕事しろってやられたらきついな
間違いない
来週はクロームエクステンションのごちゃごちゃしてるな
早く上げといてください
はい上げときます
来週
水曜だ
喋れなかった
やめろやめろ
小声小声
今年も元気に
新年よろしくお願いします
今年も1年またよろしくお願いします
分かんないけど
分かんないけど生き残ってないかもしれないから
なんて言ったらいいんじゃ分かんないけど
今年も1年よろしくお願いします
皆さん来週もお楽しみにしてください
おやすみなさい
