それはそうとですね、このBODCASTも一応ゴールデンウィークにカコつけて1回休ませていただきまして。 そうね、久しぶりにお休みを。
であれですね、スペースやりましてまた。 また。君ら休んでないやん。
あんまり休んだ感ないんですよね、なんか。 でもね、ゴールデンウィークっていうのもあって、やっぱ人によったら落ち着いて聞けるみたいな意見いただきましたよ。
休みの日の方がそういう感じあんのかな。 そうそうそう。事前に言ってあって、なおかつ多くの方が休みの4日にしたんですよね。
そうですね。 だからこう、1、2、仕事をしてた人の次の日の3日ではなくて、1回あてて4日ぐらいがええかなみたいな思って4日にしたんですけど。
でそれでしたら、同時視聴者数みたいなやつが多分今までで一番多かったんですよね。 あれ何人ぐらい?
えっとね、一番多かった時で191やったかな。 190か191かそんなでしょ。僕がずっと見てたわけじゃないけど。
結構な数の方が聞いてらっしゃるんですか。 あんなっていうとあれですけど、かなり雑談的なゆるふわトークでしたけど。
そうですよね。なんかあんまりこうセキュリティの話っていうか、なんか注意喚起の話が多かったですね。
ね、なんかずっと注意喚起の話してましたね。 みんな大好き設定確認、定期的な設定確認みたいな話とか。
あールーターのやつか。 そうですね。ルーターの話とか、あとなんか最近のこう僕とカンゴさんの関心事みたいなやつとかですね。
いう話をして、まあ僕があんまり関心のがないみたいな話をしてて。 ゲームでゲームっていうね。
ゲームね、ゲームもやってる。あ、でもなんか紹介したのは、そのなんかドキュメントのレビューフローとかすごく最近僕なんか考えてるみたいな話をしてる。
なんからしくないね。 らしくないですか。僕でも意外と意外とそういうとこしっかりしてるのよ。
まあね、まあね。 そうそうそうそう。そういうのをなんか作ってた、作っててんけど、なんか公開したろうかなとかね、そういう話をしたりもして。
いろいろそういう多岐にわたるようなお話をしてましたね。 いいですね。唯一したゴールドウィークで。そうそうそうそう。
そんな感じでね、やってたんですけど、まあちょっと今日もお便りから入っていこうかなと思います。 お願いします。休みというのもあって、そんなに今日はお便り多くないんですけれども、
2つほどちょっと紹介したいんですが、1つはつい先日ヤフオクで2.5インチのハードディスクを買ったら
パーティションが切られていて、もしかしてと、 フォトレックで覗いたらリカバリー領域、Cドライブ、Dドライブらしいパーティションの中に大量のファイルが復元できそうだったので、ランダムで上書きしてから利用しましたっていう。
なるほど。タイムリーナ。 これすごいですよね。これ紳士的な対応ですよね。
まあ紳士的っていうか、その人は立派だと思うけど、自分でもさ、もし見つかっちゃったら、見えちゃったらさ、
物によったらどっかに届けてあげなきゃいけないとか、 面倒くさいってのもあるよね。
紳士的にやるかって言われたら、ちょっと自分的には微妙だけど、面倒くさいから消しちゃおうと思うかもしれないな。
確かに確かに。見たがゆえにっていう面倒くささも中にはね。 余計なものは見たくないっていうか。
確かに確かに。確かにね。これだって破棄というか、捨てた、 平たく言えば捨てたものなわけじゃないですか。
自分の手元からね、無くしたものなわけやから、 それは無くなったものとして処理するのが一番正しいのかもしれないですね。
なんかね、スマートではあるよね。 無いしは、見ちゃったらそれを叱るべきところにちゃんと責任を持って最後までやらないと、
なんかちょっとね、気持ち悪いというか。 確かにね。見てしまった内容によってはね、どこどこ本人なのか、違うとこなのかは別にして、
無かったことにできるようなレベルじゃないものが入ってるかもしれないですね。 そうそう、場合によったらね。
確かに確かに、見なきゃよかったものってあるかもしれんもんなぁ。 倫理的な話とかそういうところで考えるとね。
そういうのもありましたということでございます。 あとは、これは脅威アクターの命名の話なんですけど、
ご意見というか、自分はこう考えてますみたいなものを しっかり書いてくださっている方がいらっしゃったんですけれども、
私個人としてはスレッドアクターそのものを意識しすぎず、それぞれのインシデントの イニシャルアクセス及び侵害の流れ、各組織が採用した対策などに注目をしてますというような意見でして、
結局スレッドアクター全般の侵害リスクに対処する必要があるので、 アクターの特徴というよりは実際に使われたイニシャルアクセスとかラテラルムーブメントの手法が自分にとっては大事かなと。
ただ、脅威インテリジェンスを専門にする場合は、脅威アクターの個々の特徴は大事なので立場次第だと思いますという、
普段思っていることをきれいにまとめてくださったコメントをくださってたので、紹介してみましたということですね。
そうだよね。大半の人にとっては、今のお便りのスタンスが正しいのかなというか、
アクターが誰かとかどういう名前がついているかというのを気にするよりも、何すべきかというふうに注力したほうが生産的よね。
そうですね。この2つの立場みたいなものを挙げてくださってますけど、自分たちにとってはどうなのか。
メディアがどう報道しているとか他人がどう言っているとかっていうよりも、自分たちが対策を行う上で何が大事なんだっけっていう観点は忘れないようにしたいなというふうなのをこれを右手でまた改めて思いました。
ちょっとそういう意味で考えてやっているというのは素晴らしいですね。
そうですよね。というお便りを2ついただいておりましたということでございます。
ありがとうございます。
今日は休みも挟んだということでリハビリ会という感じで行くんですかね。
そんなの今までやったことあったっけ?
やったことない。やったことなくてすぐに通常運転し始めるという。
鳴らし運転というものを知らない3人ということでやってますけども。
今日はそうですね。誰から行きますかね。僕から行きますかね。
はい、お願いします。
今回はですね、紹介するのは40メールを侵入経路としたインシデントについての実例紹介というのをですね、
NTTセキュリティがブログという形なのかなというので出してくれていたので、
非常に内容もそうですし、これを聞いて結構僕も考えたことがあったので、
ちょっと興味深いなということで紹介したいんですけれども。
まず内容から紹介していきますが、これは2022年の3月から4月にかけて対応した、
このNTTセキュリティが対応したインシデントの中に40メールがイニシャルアクセスであると考えられるようなものがあったので、
それを紹介しますというふうなものでした。
このインシデント、そもそも何でこれが発覚したのかという発覚の部分から説明してくださっているんですけれども、
一番初めにこれが異常が起きたというのが分かったのは、内部のネットワークの中で、
ドメインコントローラー、ADですね、のプロックダンプというツールを使って、
LSSSのプロセス、認証の情報のダンプですよね。
ダンプをしているぞというふうなものをEDRが検知したというアラートからこの事件の発覚というふうになっていました。
だから一番内部まで、最重要のところまで入り込まれたところで検知したわけね。
もうあかんというタイミングってことですよね。
最後の最後だね。
普通に考えれば多くの場合、ドメインコントローラーというのはインターネットから直接アクセスできるなんてことはほぼないので、
横展開でここまで来たんだろうというふうに想定されたと。
これがきっかけで調査をどんどん開始していく中で、
40MailはDMZに存在していたんですけども、そこのDMZにある40MailのIPアドレスから
ドメインコントローラーに対してリモートデスクトップの接続が確認できたと。
でも40Mail自体にはリモートデスクトップのクライアント機能というのはないので、
悪用可能とされている、いわゆるKEVとかに乗っているような脆弱性が放置されている状態でもなかったと。
こうもやもやしますよね、この辺もね。
40Mailのログとかを調査していくわけなんですけれども、
設定ファイルとかログファイルを入手して、そこからファイルとかディレクトリに対する40Mailの中のタイムラインの分析、
ログイン、ログオフゾーナーされているのとか、あとファイル消されているものはないのとか、そういうふうなものを調査していったそうですと。
そしたらKログっていうところがあって、そこは重要なログイン、ログオフとかの内容が書かれてあるログのディレクトリがあるんですけども、
そこに一部の日付のログが欠けてしまっていると。
イベントログを復元していたところ、ある期間だけすっぽり抜けてて、前と後ろがあるのにそこだけないみたいなですね。
あとはログの書き出しの日付に乱れがあると。
例えば10日ごとに区切られる規則性みたいなものがあるのに、それが成立していなくてブチッと開いているみたいなものがあって、
その規則性が成立していないというおかしなポイントが見つかったというようなところですね。
インシデントに関連するようなログインというようなものは特になかったんですけども、
アップロードしたんじゃないかというふうに思われるようなログが2件ほど見つかったそうなんですよ。
どんな方法でアップロードしたのかというのはここからは分からなかったんですけれども、
ログのフィールドを見るとですね、UIフィールドというのがあって、
そのUIフィールドというのはどのインターフェースから、例えばWebなのかGUIなのか、
REST APIを使っているのかという何経由で上げられたのかというのを表すフィールドがあるらしいんですけど、
そこでWebとかGUIとか書かれるはずがヌルってなってたんですって。
だから通常起こり得ないっていうやつですよね。というふうなものが不審なものが見つかったということと、
あとはWebのインターフェースがインターネットに公開されている状態だったということが分かったそうです。
そのインターフェースに対してなんですけども、先ほど言ったみたいに悪用が認められているというような脆弱性自体は解消されているような状態なんですけれども、
ただ気になったのが認証なしでこのWebのGUIにアクセスすることができれば、
悪用可能とされている利用可能な脆弱性、脆弱性の利用条件ですね。
というふうにされているCVEでいうところの2021-24-007という認証なしでSQLインジェクションが可能な脆弱性というふうなものがあるので、
もしかしたらこれなんじゃないかなというふうに疑うというふうなことがログから判明したというふうなことが書かれてありました。
そこからアップロードログ、ここではこれは悪用されたかどうかわからないんですけども、
実際のこのアップロードログの中から調査を進めていったらですね、
Webシェルが2つアップロードされていたということも分かった。
1つはBusyBoxという知っている方は知っているようなものだと思いますけども、これを使うようなWebシェルで、
UNIX系のコマンド、攻撃者が扱いたいコマンドを実行環境を整えるようなものがあったりとか、
あとPythonで書かれたWebシェルがあって、アップロード、ダウンロードとかOSのコマンドを実行できるような、
Pythonで書かれているけども実行形式に変えられているものが保存されているというのが分かったそうです。
実際の侵害の流れというのはここから推測するしかないんですけども、
Webシェルとかを使って新たな攻撃ツールとかを設置したり実行したりすることによって、
侵害をした40メールを経由して攻撃者が外からリモートデスクトップを使って、
DCに攻撃をするという流れに至ったんじゃないか、みたいなことが書かれてあったんですけども、
ただDCの侵入方法というのはどうやってその認証情報を取ってやっていったのかというところまでは分からなかったですし、
40メールを経由するためのいわゆるトンネルリングツールみたいな風に言われるツールがありますけども、
そういったものも消されていたのかどうなのか復元できなかったのかは分かりませんけども、
実物自体は発見することができなかったということで、最終的にはどの脆弱性を使って40メールを侵害したのかというところは分からないんですけれども、
先ほど言った認証なしでSQLインジェクションが使える、SQLインジェクションを実行できるという
2021-24007が悪用されたのかもしれないなと推測の域を出ない結論で終わってはいるんですけども、
そういったことが書かれてありました。これを読んで思ったのは2つ思ったことがあって、
1つは外部からのアクセス制御をちゃんとしようよということと、内部から内部のアクセス制御というのもありますよね。
DMZに置いてある40メールからですね、そのままDCにリモートデスクトップを貼れるような状態というようなことも
よくない状態なので、そういったことの見直しというのは基本的なこととして必要かなというふうに思ったんですが、
我々いつもKEVの話をよくするじゃないですか。僕たちは第一歩としてああいったものを参考にして、
足りないもの、例えばCVEが発行されないものとか、あと日本独自なものとかもあるので、
合わないものは自分たちである程度埋めていくという、あれが全てではないという考え方で接していきつつも、
参考にするには結構踏み台という言い方がよくないかもしれないですけど、そういうふうに使えるんじゃないかという話をしてるんですが、
ただこれは推測の域は出ないとは言うものの、何を使ったかわからない状態で、この脆弱性かもというふうなことを考えると、
エクスプロイトコードとかPOCですね、そういったものが公開されていなくても、インターネットに公開されているサービスに関しては、
ああいったところに載っていなくても、ちょっと1段階上げないといけないような判断をする必要のある脆弱性というふうなものも考慮しないと、
ちょっと怖いというのがあるのかなというのがあったので、今回これを見ていて考えさせられたなというふうに思うのは、
KEVを押しすぎというふうに、まず人にどう見られるかわかりませんけど、それだけやってればいいんだという伝え方をしてしまわないようにしないとなというようなものを思いましたということでございます。
いろいろ、まず公益に関してはEDRで最後検知するまで、奥底にまで入り込まれるまでは気づかなかったということだから、
おそらく事後にNTTセキュリティさんがECAの対応して調べても、
手法の特定とかに至るようなログだったりなんだり、そういうものが多分足りてなかったんだろうね、もともとね。
そうですね。
そういうのがあれば、もしかしたらその公益の経路の途中で検知できたかもしれないけど、
そういう検知したり、あるいは後から公益情報を詳しく分析するのに十分なログとかがなかったり、
あるいは40メールのログも消されてたっていうのがあったけど、そういうのをちゃんとどっかで中継して取っておくとか、
なんかそういうような部分が少し足りてなかったのかなという感じがあるので、
そこはちょっとその事前の準備として不足してた部分があるかなと思うんだけど、
後半に言ってたさ、KEVとかに載ってない、POCも公開されていないし、
悪用が公には確認されていないけど、そこそこ危ない脆弱性。
特にこれ、CVSSにあまり依存するのは良くないけど、
でもこれ9.8でクリティカルだから非常に危険なやつじゃない?
というのをどう判断するかっていうのは、これはちょっと難しいよな。
ここの組織がどういう優先順位でこの脆弱性を管理したのかわかんないんで、
たまたま攻撃されるタイミングに間に合わなかったのか、
ないしは対応不要と判断しちゃったのかどうかちょっとよくわかんないけど、
そのあたりの取り味ってちょっと難しいよね。
結果論で後付けでやっておけばよかったねっていうのは誰でも言えるんだけど、
事前にそれができてたかと言われると、どうだろう。
わかんないよね。わかんないし、このブログの記事を見て、
うちも大丈夫かなって心配になったところ他にもあると思うんだけど、
ちょっとこの攻撃された組織がどういう種類のところかわからないんだけど、
ここだけが狙われたのか、ないしはこの脆弱性があるところを狙ったのかによってだいぶ変わってくるなというかさ、
同じ機器を使ってたところが他にも同じようなタイミングでやられてたらおかしくはないよね。
そうですね。手法自体は同じような使い回せるわけですからね。機器が同じなら。
幸いというか、公開は今の時点でもたぶんされてないと思うんで、
もし仮にこの脆弱性が悪用されたという推測が正しいんだとすると、
今回の攻撃者、ないしはその関連する攻撃者に限定される可能性は高いので、
そうですね。議事じゃないから。
そんなにすごく広く攻撃されるとは思えないんだけど、危ないといえば危ないよね。
そうですね。この脆弱性を気をつけようというよりも、こういうものがあるっていうことを知っておいた上で、
どこまでやるか問題だと思うんですよ、結局は。
そうだよね。
例えばアプローチとしては、ネギさんが言ったみたいに、
例えばドメインコントローラーに至るまで、所定の後のアクションですよね。
そういったものを経路上とかホスト上とかでどうやって検知していくのかっていう、
ダメージコントロールというか、そういったところにするのか、
例えば脆弱性管理の方法を攻撃方法がわかっている、いわゆるKEVに乗っているようなものとかっていうようなものはすぐに対処して、
クリティカルとか緊急とかに当てはまるようなものは、何週間、1週間とか何週間以内に対処してっていうふうに決めた上で、
それでもやられたら他のもので検知するかっていう風な受け皿を用意しとくっていうのは現実的なのかなっていう気はするんですけどね。
そうだね。あとこの事例、別に特殊な事例でもなんでもなくてさ、
一旦中に入られちゃうと、わりとズブズブで中はRDPし放題とかっていうのはよくある。
よくある話ですよね、そこはね。
あと今回の事例だけでなくて、ランサムウェア標的型の、いわゆる侵入型って言えばいいのか、
侵入型ランサムウェアとかでも内部展開でRDP使うだとかさ。
めちゃめちゃありますよね。
多いよね、多く使われるけども、結局そういうのって中ではやっぱり制限されてないっていうところが、
よくはないけど一般的な状態だと思うので。
一般的な運用かもしれないですね、その内部から内部ってやつはね。
そういうのを見ると国内だけでなく、広く境界防御の考え方が根強く残ってて、
外部からの入り口のところはなんとか目が行くんだけど、
入られた後の中の横展開についてはどうしても後手に回ってるというか、
あんまり考慮されてないっていうところがまだまだ多いのかなっていう感じはあるよね。
あとはあれですね、あんまりこう普段から考えてなかった、
できることは分かっているけどあんまり考えてなかったのは、
こういったネットワーク機器とはいえ中身はLinux、Unix、KOSで動いてるやつ多いじゃないですか。
そこでやられてることってあんまり検知に及ばないなっていうね。
例えば40メールの中にアンチウイルスとかそういうものを入れるってあんまり効かないじゃないですか。
ここを結構この中で見つけるっていうこともできればいいのになと思いましたけどね。
変更管理とかでできるんじゃないかなと思うんですけど。
もともとのセキュリティのアプライアンスだったり、
もともとそういう機器が持っている機能として、
そういうさまざまな攻撃の検知とかね、
そういうのあるものはたくさんあると思うんだけど、
一旦そういうのがバイパスされちゃうと、
だいたいデータクセがある場合ってそういう機能バイパスされちゃうことがあるから、
そうなっちゃうと、そのOSになっちゃうと、
あんまり手がないっていうことはあるかもしれないよね。
足元はやっぱり弱いみたいなというか、
自分自身に起きていることを検知するっていうのはちょっと弱いなっていう印象が強まりました。
そういう場合にはそこで見つからなかったら、
次どこでっていう手を考えておかないといけないんだろうね。
そうなんですよね。
今やっているこの管理の仕方が本当にこれでいいのかっていうのは、
やっぱりこれを見直すきっかけになる事例だなって思ったので、
紹介させていただいたという感じでございます。
こういう実際に対応した実例というものを紹介してもらうと、
説得力があるというか、いいよね、気づきになるというかね、
自分たちも調べてちゃんと対応しようというきっかけになるよね、こういうのはね。
なんか結構読んでて、何て言うんですかね、面白いというかすごく、
それでどうなった?どうなった?みたいな感じで読める記事でした、本当に。
読みやすいし、自分の知らんことが出てくるんじゃないかみたいな感じで、
学びが多かったんで、直接読んでみたらいいと思います、本当皆さんも。
はい。
はい、ということでございます。ありがとうございます。
ありがとうございます。
はい、じゃあ次はですね、半野さんいきましょうか。
はい、今回私はですね、新潟県で発生した公文書管理システムのファイル消失の事故について取り上げたいなと思っておりまして、
これもゴールデンウィーク前に公表されていたもので、4月21日付けで新潟県であったり、
あるいは開発や保証になっていた事業者である富士電機ITソリューションなどから、
転末というか、経緯などが公表されていたものでありますけども、
内容としては、これ事故というか、このインシデント自体は非常に目を引くというか、
いろんな人に興味・関心を引く事例だったので、すでにご存じの方も多いのではないかと思うんですけども、
改めて説明させていただくと、4月9日に、今ご紹介した公文書管理システム、
これ2022年の4月から運用が始められていたそうなんですけども、
約1年後の4月9日に、システム上で公文書に添付する形でファイルをくっつける事がシステムにできているということであったんですけども、
その添付されたファイル、約10万件が消失してしまったと。
期間で言いますと、3月の24日から、2023年の3月24日からその月末前ですね、31日までに登録されたファイル10万件が消失してしまったと。
非常に大量のファイルが公文書というものから消えてしまったということではあったんですけども、
これなんで消えてしまったのかというところが、なかなか注意をしておかないと、自分たちのところでも起こりかねないなというものではありまして、
パスワードデーなのにね。
もうそろそろいいよねっていう。
確かにパスワードデーがなくなることが目的やもんねこれってね。
Googleアカウントのパスキーっていう話なんだけど、パスキー自体はこのポートキャンセラーも何回か取り上げてるんで。
もうちょっと今更繰り返しになるんで詳しく話はしないですけど。
使えるようになったのはもうだいぶ前から使えるんだけど、Googleアカウントではまだ使えてなかったんだよね。
そうなんですよ。
やっぱりこういうのって大手のサービスが使い始めるとなかなか普及しないっていうのがあるので。
今回Googleがアカウントで使えるようになったっていうのは結構大きなマイルストーンかなと思うんだけど。
実際使えるようになったので使ってみたんだけど、非常に簡単で。
Googleのアカウント使ってる人だったら、だいたい使ってる人結構多いと思うんだけど。
スマホから、iPhoneとかAndroidとかスマホからGoogleアカウントにログインして、
セキュリティのメニューってのがあって、二段階認証とかそういうのを設定するメニューがあるじゃないですか。
あそこに新しくパスキーっていうボタンが表示されてるんで、それを選択して登録するだけなんで、
1分くらいあれば本当にできちゃうかなっていう感じで、めちゃくちゃ簡単なのね。
僕は個人的にいつもiPhone使ってるんで、Androidはちょっと使ってないから試してないんだけど、
説明読んだらAndroidであらかじめGoogleのアカウントで使ってる人は自動的にパスキーが生成されてるんだって、勝手に。
メニューに行くと、もう作ってありますよって出てきて、使いますかっていうのが。
使うかどうかの選択ってことですよね。
そう、使えますって言うだけで使えると。
iPhoneの場合にはそういうのはないんで、自分でパスキーを作成するってやると、
iOSの機能に遷移してパスキーが作られて、それがiPhoneの場合にはiCloudキーチェーンに登録されて、複数のデバイスで自動的に同期がされると。
こういう感じで、非常に使いやすいというか簡単に登録できるので便利ですよということなんだけど、
ちょっと使ってみてね、2つ注意点があるなと思って。
一つは、これパスキーを登録すると、まず自動的にパスワードレスの設定が有効になるような仕掛けになってるんで、
パスキーを登録したGoogleのアカウントでは、パスキーが使える環境だともうパスワードは使わなくなる。
自動的にね。一応この設定は後で自分で無効率することもできるんだけど、
でも多くの人で、いわゆる物理的なセキュリティキー、指キーとかああいうタイプの鍵を元々使ってた人以外は、
パスキーの方が基本的には安全なので、これはそのままの設定にして使うのがいいんじゃないかなというふうに思いますし、
仮にパスキーが使えない環境、ブラウザとかでサポートしてないとかも今でもあるんで、
そういうところで使おうと思ったら自動的にパスキー以外の元々の従来の認証方法が使えるので、
特に特段問題がなければ、この設定はそのままデフォルトの有効なままにするのがいいんじゃないかなと。
ただ一応勝手に有効になるので、一応注意点としては気をつけてねというのが一つと、
あともう一つ、これもあんまり使ってる人はいないと思うんだけど、
もともとGoogleって何年も前から、ファイドの今回のパスキーに対応する何年も前から、
独自のビルトインセキュリティキーっていう機能をもともと持ってて、
AndroidフォンとかiPhoneとかを物理的なセキュリティキーの代わりに使えますよっていうGoogle独自の機能がもともとあったのね。
AndroidだとOSにもともとビルトインでそういう機能があって、
iPhoneではこれもポートキャストで紹介した記憶があるんだけど、
Smart Lockっていうアプリをインストールすると、それが鍵代わりになって使えるっていう仕組みが昔からあったんだよね。
だけどこれは機能的には今回のパスキーと重複するんで、
どうなるかっていうと、パスキーを登録すると自動的にもともとビルトインセキュリティキーを使ってた人は、
これが無効になって置き換わる形になるのね。
今まで使えたやつが使えないって思っちゃわないように注意が必要というか、
よいよい手段に置き換わるっていう感じで、パスキーを使うと自動的にそっちが無効になるっていう仕掛けになっているので、
もともとビルトインセキュリティキーを使ってた人には、今回のタイミングでメールで通知が来てるはず。
あー、使えなくなりますよみたいな案内が来てるね。
そうそう、パスキー使うと置き換わりますよっていう案内が僕のところでも届いたんで、
一応そこは注意点としてはおって思う可能性があるので。
ただそれ以外はあまり気にせず、もともと今までパスワードと、
あと例えばよくあるGoogleオセンティケーターみたいな認証アプリを使って2段階認証してましたみたいな人は、
基本的にパスキーを使った方がフィッシング体制とかははるかに安全なので、
なのでできるだけパスキーを使う方がいいかなと思うので、
大半のGoogleアカウントを使っている人にはおすすめというか、
本当に簡単に使えるので、iPhoneとかAndroidとかのスマホを持っている人はすぐさまログイン画面に行ってパスキー登録ってやった方がいいんじゃないかなと。
そんな感じで非常に簡単だし使い勝手もいいし、よくできているかなと思ったので、
そんな感じで紹介をしておこうかなと思いました。
もう使ってみた?
僕まだ使ってないです。
本当?ちょっと使ってみて。
使ってないです。
これあれなんですよね、自動で作成されたパスキーと手動で作成されたパスキーが分かれて表示されるんですね。
Windowsでやったよとか、例えばGoogleのPixelでやったよとか。
一応端末ごとにパスキーってひも付くので、
Appleみたいに同期すれば、あとGoogleもGoogleのパスワードマネージャーを使って同期すれば一緒になるけど、
そうでない場合は基本的に端末ごとに生成するという形になっちゃうとバラバラになっちゃうので、
そこはちょっと管理があらかじめちゃんと考えておいた方がいいかもしれないね。
そうですよね。わけわからなくなっちゃうかもしれないですよね。
使ってみようかな。そろそろやっとGoogleも対応したし。
これでGoogleでそれなりにユーザー数多いから、
これだけ使ってる人が多いサービスが対応したら、一気に使うようになってもおかしくはないので、
ようやく一つの普及期に入るかなっていう感じで。
これで使い方に慣れていけば、いいなってなるんじゃないかなっていうか。
もうこれより便利なものでえへんかな。
そうね。出ないんじゃないか。安全性が高くて使い勝手もいいものっていう意味だよね。
もうパスワードや認証に関しては、これやっとけばもういいっす。これだけやってくださいみたいな。
一応これがファイナルアンサーなんじゃない?
と思うけど、しばらくはこれが普及するまではパスワードがなくなっていくっていう未来じゃないかな。
他には何かないと思うんだけどな。
パッと浮かばないですよね。すごい自分に身近なデバイスで追加で何か買う必要なくてみたいなものを考えると、そこも便利というかコスト面もね。
あとさっき言ったGoogleがもともと使ってた独自の仕組みとかっていうのは、結局スマートフォンにひも付いちゃうんで。
僕も例えば毎年買い替えてるじゃないスマートフォンを。
スマートフォンというかiPhone。
iPhone。そうすると毎回毎回買い替えるたびに鍵を再生成しなきゃいけないんだよ。
そうですね。端末に縛られるとね。
それがめちゃくちゃ面倒くさいんだけど、このパスキーが何がいいかっていうと、同期ができるっていう点が最大の利点なので、
同じね、僕だったらiPhoneだったら同じAppleアカウントを使ってるデバイスだったら簡単に同期できるし、
スマホ買い替えても同じアカウントで乗り換えればさ、勝手に同期されるから、再生成とかする必要が全くないから。
そうですよね。
そういう意味ではこれこそがファイナルアンサーとして。
そっか、確かに。
復旧してほしいな。
買い替えの面も全然フォローされてる。
そこが大きいよね、やっぱね。
なので、ぜひ騙されたと思ってとりあえず使ってみてください。
いや、騙されたらダメですからね。
そうね。
こんなクリティカルなところで騙されたらそれはもう終わりやからね。
どうだろう、これもまだ当面はオプトインというか、ユーザーが自ら使いますってやらないと使われないので、
まだまだちょっと一般の人が…
強制的に使わせるぐらいの動きがないと。
もうパスワードは無効にして強制的にこっちっていう風にやらないと、なかなかね、また復旧まではいかないかなとは。
そうですね、確かに。
この辺はやっぱり、なりすまし事案ってまだまだいっぱいあるじゃないですか。
特に個人アカウントのやつってよくニュースでも取り上げられたり。
そうだね。
今だったら組織だったらクラウドとか個人のクラウドから乗っ取られて、個人端末やられてみたいなのもあったりしますけど、
これをですね、そういった事件事項があった時に、じゃあどうすればいいんだっていう風なものを説明するときに、これを進めた方がいいのかなやっぱり。
2要素2段階ではなく。
今だったら使い勝手もそんなに悪くないし、個人の利用者にはパスキーとりあえず登録して使えるなら使いましょうじゃないかな。
選択肢って3つあるかなと思ってるんですよね。
今よりもより良いセキュリティレベルに上げるこのパスワードの管理使い方みたいなことで言うと、
今あるパスワードを本当に力技でバラバラにして、難しいが推測できないようなものにするという、今までのパスワードを強固にするというだけ。
2要素2段階の導入、パスキーの導入っていうのがあるんですけど、これをうまく、使える使えないがあるじゃないですかサービスの中には。
この選択肢が増えるっていうことになると、僕が聞いてと思ったのはせっかくGoogleがやっと対応してくれたってことがあるんで、
GoogleのGmailをリセットに使っている人って多いと思うんですよ。
GoogleとAppleやったらAppleの方をパスキーで強固に何としてでもこれだけはっていう風に進めるのがいいのかな。
今の3つで言ったら優先順位的な3,2,1だよ。
パスキーが使えないならとにかくパスキーを使う、パスキー使えないならしょうがないから2要素認証を導入しましょう。
それもダメならパスワードを強固にしましょうでしょ。
でもどれか1個しか嫌やねんって言われたら、パスキー使える、そういう主要なサービスっていう風なものだけでも。
どれか1個しか嫌やねんっていうのは?
全部バラバラやるの嫌なんですみたいな面倒くさいですっていう。
せめてこれだけやってって言うんやったらどこからかなっていう程度の話ね。
それを言い出したらさパスキーはまだ全然普及してないから、それだけで全て解決しないよ。
でもそれ普及するのを待ってたらいつまでも使われないんで。
そうなんですよね、そうなんですよね。程度が難しいなと思ってね。
使えるところはもうとりあえず使ってくれっていう。
これまで面倒くさかったら管理手法が1個増えるとそれだけ手間が増えちゃうっていうことだったと思うんだけど、
パスキーはそういう意味ではそんな手間が増えないんで、勝手に同期もされるし、
をクリアしていかないといけないものが追加されてたりとかみたいなのがあって、
結構面白いというかテレビの良かった時代みたいな感じが出てますね。
こんなめっちゃ枯れかけてるなみたいな感じがするんですよ。
あれすごい豪華なセット使ってやってたよね。
そうそう。緑山スタジオっていうよく仮面ライダーとかああいうの爆破シーンとか撮るようなところのスタジオでやってるんですよね。
屋外のスタジオで。でっかい大掛かりなセット作って、
例えばジブラルタル海峡とか、
取って手すりのない吊り橋みたいなの渡って下からドッジボールが飛ばされて落ちたらあかんみたいなやつとかね。
あと龍神池っていうやつとかね。
今回のAmazonプライムのやつはまだ見てないんだけどさ、
昔あったフォーマットをそのままリバイバルっていうか同じような感じでやってるわけ?
基本的にはそうですけど、昔よりかはちょっと緩めかな。
そうなんだ。
例えばなんかその難関にチャレンジして思いっきりダメでしたと、捕まりましたとか落ちましたとかってなったけど、
落ち方がおもろかったから突破みたいなのもあるんですよ。
普通に0-1でやったらすぐいなくなっちゃうと思うんですよ、挑戦者が。
全滅してしまうというのもあるんで、とんでもない落ち方したとか、めちゃめちゃ頑張ったとか、
そういうのがあると次に進めるみたいな、
敗者復活の救済措置みたいなのがあるんですよね。
そういうの見せずにやっちゃうとやらせみたいになるから見せてるんだと思うんですけど。
そういうのをやってるんで、あの頃知らない人もいるかと思うんですけど。
そうだね、もう結構その30何年前って言ったらもう全然知らないって人も多いはずだよな。
僕らの世代ぐらいがギリかな。
そうだろうね。
ちょうどよく見てた頃みたいなね。
そうね。
だしその頃って割とテレビ、今と比べたら何でも自由にまだまだやれてた時代っていうか。
テレビ前世紀みたいなとこもありましたしね。
そういう時だから、なんか懐かしいし、今見たら逆に新鮮かもね、わかんないけど。
そうなんですよ、こんなのないと思うんで、ここ20年30年ぐらいテレビ見てきても、
どんどんあの頃から景気も悪くなっていきましたしね、これぐらいの時期から。
だから今見ると逆に斬新なんて思いますね、皆さんが見ると。
だからこそそういうのがやられるんだろうね、今の時代にね。
そうそうそう。なんでちょっとAmazon入ってる方は、ちょろっとバカバカしくて何も考えずに見れるというか、
そういうのもいいかなと思うんで、見てみてもいいんじゃないかなというふうに思いますし、
結構難関なんですよ、みんなね。
ちなみに昔竹市場をやってた頃っていうのは、127戦中攻撃側のチームが勝ったのは8勝しかないので、