00:00
はいどうも、kokorokagamiです。 当然です。
今週も1週間振り返っていきたいと思います。 はいはい。
もう、はや今年も半分過ぎましたけど、 やりたいことは進んでますか?
いや、やべえですね、という感じですけども。
まあまあ、ぼちぼちかなという感じですかね。
そうですね、まあお互いに4月の年度初めから すごくバタバタしてた思い出しかないじゃないですけど、
それも一段落してきた時期だと思うので、 実際にはテーマも、テーマというかプロジェクトも進め始めてっていう、
そういう段階に来ていると思うんで、 そろそろプライベートの方の住みタスクを消化していかないとっていう時期ですかね。
そうですね、本当に。あと半年しか、あと半分しかないですから、 いろいろやることやっていかんとっていう感じがありますね。
そうですね、忙しかったから休むかって言ってると 気づいたら年末になっちゃうんで。
はい、コロナも落ち着いてきてますからね。 まあ落ち着いてきてるって言って数万人レベルなんですけど。
うん、また東京増えたりしててちょっと不安ですけど、 ただ、あとどうぞ。
そうですね、増加傾向で今ちょうど1万人ぐらいだったかな、東京が。
はいはいはい。
なので、うーんって感じではありますけども。
まあそう言っててもね、もう我慢しててもしょうがないよねっていう感覚ではあるんで。
そうですね、ぼちぼちという感じもしますけど、難しい。
引きこもり切るというところからは…
ちょっと脱却しないとという気もしてますね。
最低限ね、対策だけしてもう外出は昔通りにするっていう感じですかね。
そうですね、1万人って言いましたけど全然違いましたね。 今3600人ぐらいですね、東京都自体は。
クラスターのマイクミュートを。
あーごめんなさい、そうでした。 クラスターどこ行った。
クラスターさん、OK。
はい。
えーと、最近の話題で言うと、EUの通信障害が結構大きなニュースになってますね。
そうですね、ちょうどこの録音してる昨日から今日にかけて通信障害がずっと発生してまして、
先ほどようやくなんか復活しましたよという宣言を出しましたみたいな感じらしいですね。
そうですね、ただ実態としてはまだまだ繋がりにくい状況みたいなので、
もう少し現場の人は大変だと思いますけれども。
そうですね、まあでもようやったと思いますわ、上から見せるんですけど。
5日の間でね、ほんと。
記者会見も見ましたけど、深夜に発生して、すぐに社長の方まで通達も行ってますし治してて、
03:04
えーと、その半日ぐらいかな?違うか、1日ぐらいか。1日ぐらいの時点で、
技術的には治ってて、治ってて、あとは渋滞してるのをちょっとずつ流していって、渋滞を解除するというところまで持っていきますということを言っていて。
なかなか一度渋滞が起こってしまうと、もうどうしようもないという感じもあったんで、そこからよく復活したなというところが。
そうですね。
なかなか大変ですねという感じでしたね。
ユーザーは問答無用でパケットを流し込んできますからね。
はい、死んでるサイトほどF5が発生するので。
そうですね。
そうですね。
ほんとよく立て直したと思います。
あまりちゃんとわかってないですけど、導入した最新のルーティング機器のソフトウェア不具合で、VOLT機器にトラフィックが集中して破綻した。
一部のVOLT機器か。本来だとロードバランスしなきゃいけないところがバランスしなくなっちゃったっていう。
そうですね。そこら辺ちょっと調査中ですという感じでしたけど、大体そういう感じで。
理論上は大丈夫なはずでしたけど、想定したよりもトラフィックが集中しちゃったので、ちょっとどうしようもなくなったという感じっぽかったですね。
それを普通の機器業の一般サービスだったら、「すいません、障害です。」って言って一旦完全にシャットアウトしてっていう話だと思うんですけど、
一部活かしつつ何とか徐々に復活させるという相当な高等テクニックで復活させてるので、それを2日間でやりきるのは現場のエンジニアリング力すげえなと素直に思いますけどね。
本当にすごいですね。インフラ系はやっぱり活線作業みたいなのがデフォルトなんで、電気とかもそうですけど、やりますわという感じでした、ほんま。
本当に頭がんないですね。一般顧客にもその難しさを理解してもらいたいところではありますけど、なかなか伝わってなさそうな雰囲気を感じますね。
そうですね。なかなか難しかった感じもありますし。
今回、auのサポートサイトはその通知をこまめに出してたんですけども、そもそも携帯しかネットインフラがない人は見れないというのは言われてみればそうな話っていうのも、会見でも社長も認めてた話で、
そこら辺を実店舗を持っている強みをあまり活かしきれなかったなみたいな反省も会見では言ってたんで、そこら辺も今後の課題としてはあったのかもしれませんね。
06:06
でもなかなかそれも社長からしてみたら、総務省指示でどんどんどんどん安くなっていった結果、既存店舗が維持できなくなって、インフラの冗長性は絞られていくけど、コスト最適化していこうっていうところに舵切った結果こうなので、
それに対して店舗での支援が足りないって顧客から言われてしまうのはなかなか辛いものがあるなと思いますけど。
まあ確かにそれはそうですね。実際店舗数も絞ってますし、何よりも通信本体を復旧させることに全力を注いでいる段階でこまめに店舗まで情報を下ろせるかっていうタイムリング、それもなかなか難しい話ですのでね。
そうですね。何せ今回のことを一般顧客がわかるような形で翻訳して説明するのがめちゃくちゃ難しいと思うので。
まあそうですね。
通信っていうのがどういう原理で起きてるのかわかってない人に通信の障害を言ってもきついよね。
そうですね。まあ会見でもなかなか難しいなみたいな、ティッシャーさんですら雰囲気もあったのでね。
はいはいはい。
いやはや、一エンジニアとしては横目に見ながらこっちも言いが痛くなるような話だなと思いながら見てましたね。
そうですね。結論としては無事復帰しそうなんで良かったです。お疲れ様でしたという。
お疲れ様でした、本当。
はい、じゃあ今日の本題に行こうと思います。
はい。
1点目。災害対応訓練がランサムウェア被害にも役立った徳島ハンド病院に学ぶBCPの重要性。ということで、テックプラスさんの記事です。
2021年10月31日。去年の話ですね。
徳島県のハンド病院に異変が起こった。院内のプリンターが一斉に強迫分を印刷し始め、電子カルテを含む全てのシステムが利用不可能となった。
プリンターは用紙が無くなるまで強迫分の印刷を続けたという。ランサムウェアロックビット2.0によるものとみられる。
ということで、去年度、ランサムウェア被害にあったハンド病院さんが最近ですね、調査報告書を発表してますと。
これは、実際に当時は災害対策病院として位置づけられていたので、ネットワークがダウンしたりとかシステムが機能しなくなった時でも稼働し続けられるように訓練していたので、
電子カルテから紙媒体に移ることで一応なんとか乗り越えたということなんですけれども、そもそもどういうことが起きていたのかというのを調査結果としてレポートが出てますと。
09:08
結論から言うと、すごくレガシーなシステムに対して保守契約がなかったというのがもう全てですね。
かつ、こっちの方がインパクトが強いという人もいると思うんですけど、病院のIT管理部門には1人しかいなくて、病院全体のITインフラを全てその人が見ていたという状態だった。
この2つが重なった結果、ハッキングされる経路ができてしまっていたけれども放置されてしまってたという感じですね。
具体的には2000年頃に導入したインフラの話になっていて、その当時使っていたVPNゲートウェイ機器であるFortiGateという商品のファイアウォール等々の設定がザルになってしまっていて、ハックされたと。
それの機器自体は公式から脆弱なものになってますよというのがあって、本家の方から実際ハンダ病院さんの方でこんな機器が使われていて脆弱だから何とかしてなさいねというのが数年前には発表がされていたと。
ただそれについて気づいてアクションを取れる人は誰もいなかったという状態ですね。
当時2000年時点での導入がどうなっていたかというところで言うと、病院とそのベンダーという1対1の関係だけではなくてですね、機器調達ベンダーとアプリ開発ベンダーとシステム構築ベンダー。
この3社が病院に対して関わっていて、それぞれ自分たちの範囲で納品したら終わりというところで契約をしていましたということから、その後継続的に報酬契約を結ぶ機会がなく、そういったセキュリティ問題とかが出ていたとしても自発的に気づける状態ではなかったということですね。
調査結果の中では、病院のITの人が1人なのは限界があるので、その人がセキュリティについて気づくのは無理だったでしょうと。
なので、ベンダー側が全管注意義務としてこういうことが起きているので何とかした方がいいですよというのを言うべきだったということが1つの答えとして書かれていて、
それに対して結構ネット界隈でもいろんな反応があるという状態ですね。
ベンダーからしてみれば報酬契約がないのであれば、そこまでするのはもうお金もらってないんだからできないだろうという割り切りの話と、
12:07
顧客目線でいうと、セキュリティというものをどう守ったらいいのか、どうやったら安全なのかってわからない人が自発的に気づいているとか、
その報酬契約が必要だというアクションを取ることすら不可能なので、導入したベンダー側に課題があるという話だったり、いろんなところで課題感があるなというところですね。
もう少し当時の技術状況の話でいくと、この2000年頃に入ったシステムっていうのは、最近サポートが切れたインターネットエクスプローラーを前提としていて、
当時は閉塞空間、インターネットから切り離された環境で利用するので問題なしというセキュリティの位置づけに置かれていたものでしたと。
かつ、2000年頃のセキュリティに対しての世の中一般の常識っていうのは、まだまだセキュリティっていうのは非常に高度な人たちが一部で頑張っているものであって、
一般の文化の中に浸透しているものではない、ちょっとウイルスバスターとかが、まだ登場してないのかなとか、そんなレベルの時代なので、
この当時にウイルス対策を入れられたかどうかというと、かなり難しかっただろうという感じですね。
なので実際今回導入されているシステムを見ていくと、ファイアウォールは全部無効化されていましたし、
ルーター機器のファイアウォール設定もほぼほぼザルだったというところになっていました。
ログイン認証とかもパスワードを受けたくらいのものしかなくてっていうところで、もう限りなくザル状態でやりたい放題の環境になってしまっていたという話です。
当然さんと少し話してみたいなと思っているのが、この現象に対して今後どうなっていくかって話ですね。
今回の件については契約書上、補修契約とか無かったから、前官注意義務だということは考慮になるけれども、
たちまちベンター側が叩かれるというか、法的に何か補償しなきゃいけないとか、そういった立場に立たされることはないと思うんですが、
じゃあ一方で今後こういうことがどんどん増えてくるとは思うんですよ。
どこまで行ってもこの契約書上サポート範囲外だったらやらなくていいっていうのが突き通し続けられるものなのかどうかっていう話があると思っていて、
15:00
電気系統の安全とかだとCSEとかそんなものをやってないとそもそも販売してはいけないとか、そういう基準になっていて、
セキュリティも同じような位置づけに変わっていくのであれば、そもそも補修契約とかセキュリティを維持担保するために、
必要な契約を結ばなかったベンダー側に責任があるっていう世界になっても不思議ではないよねっていう議論もあって、
そこら辺が今後どうなっていくかなというところでこのニュースは一つ注目を集めているって感じですね。
そうですね、
難しいですね。
どのようになっていくかという話に関しては、大前提として訴求はしないというのがあると思います。
なのでこれまで契約してきた範囲内の契約についてはその契約の範囲内で、
なので補修契約を締結してなければ仕方なかったよねとなってしまうとは思いますと思っています。
なので今後としてはそういう意味では一番わかりやすいのが法制弁か何かで、
指針、こうあるべきみたいな指針が示されて、
それに則るならば補修契約しないとダメだよねっていう流れにするのが一番なんじゃないかなと思っていますね。
そうですね、ビジネスの付き合いである以上はそういう法的な指針でもないとやはり難しいだろうなと思います。
何たって予算は限られているので、これまで払ってなかったその法律的にも必要とされていないことに対して、
予算を優先的に割り当てますかというとそうではないし、
そのシステムを何年使い続けるかもわかりませんということになるとやっぱり優先度はどうしても下がりがちですよね。
そうですね、結局今回クリティカルだったのはシステムを更新しなかったことだと思っていて、
なんで更新できなかったかというと気づく人がいなかった。
気づく人というのは病院側とベンダー側と、
20年前のベンダー側の責任者は誰なんだよって感じがしますけど、
一応そういう区分けはできると思うんですけど、どちらもやらなかったと。
なんでどちらもやらなかったって結局のところ予算がつかなかったからだと思っていて、
結局のところそこは保守を契約をするというのは前提になってしまうかなと思いますね。
18:08
そうですね、だからその辺は顧客側の勉強不足というか、
電気とかだったら電気はやっぱり人身事故とかが起きて危ないものみたいな一応一般認識を頑張ってつけてきたところではあると思うんですけど、
セキュリティーに対してはまだまだそこまで至ってなくて、
予算をつけましょうっていうのに対して素直にそうだよねって言ってもらいにくい状況にあるのは間違いないかな。
そうですね、なのでそこに関してなのでやっぱり強制力のある何か法制面が必要かなっていう位置に解釈するには必要かなとは思っているんですけども、
その前段階としてやっぱり問題だよねという意識づけが必要かなとは思っていて、
実際そこまで行ってないですよねというのが現在だと思います。
なのでそれを考えると今回のこのレポートは素晴らしいかなと思っていて、
問題提起がされている、やはり問題だよねという情報が公開されたので、
これに続いていろんなところがやっぱり問題ですと言ってくれれば、
そこ強制力のある何かしかをつけましょうねという話にはなると思うので、
そうなってほしいかなとは思いますね。
おっしゃった通り、今回のこの件はかなりそういう有識者会議でもピックアップされる対象として定義されていて、
かなり最初から最後まで情報がオープンになっていて、何が起きたのかがつまびらやかになっているので、
これを一つのセキュリティーインシデント事例として取り上げて、
今後の対策、いろんなところでセキュリティー事例がこんなのありましたというところに導入しようという動きが始まっていますし、
次につなげる活動というのは進んでいるかなと思いますね。
なので必要だよねという合意が得られた上で法制面で強制力を出して実行します。
あとは古いシステムを使っているところに置き換えさせるための強制力もできればあるといいと思うんですけど、
そこまで持てるかなという感じはないわけではないですけど。
そうですね。
結構個人的に課題だなと思っているのは、ビジネスというかマネタイズモデルを受け入れる土壌がなかなかないというところがしんどいなと思っていて、
21:17
割と一般顧客がこういうシステムを買うときって買い切り想定で予算を立てていることが多くて、
そのシステムの継続的な予算確保みたいなのをどんどんどんどん積み上げて、どんどんどんどん肥大化させていかないと運用できないっていう、
そういう予算の仕組みになってないので、その立て付けから考えなきゃいけなくて、
それを素直にやってしまうと、新しいことに予算が割けないみたいな財布の状態になってしまいかねないから、
そこは望むところではないってなっちゃうと思うんですよね、予算を出す側が。
なのでそこについて、ベンダー側、今のエンジニアの一般実力ではそこの顧客の課題を乗り越えてあげられることができなくて、
なぜならセキュリティってかなり専門知識と非常に細やかなアップデートを求められちゃうから、
技術的解決として、まあ1年に1回動けばいいやじゃなくて、日々動いとかないと守れないものになっちゃってるので、
その安くする方法が多分エンジニア側にはあまりないので、
発注する側は今までの感覚で発注することができないなってなってしまうところをどう乗り越えてあげるかが、
直近のビジネスに対してというと課題感があるなと思いますね。
それは継続的な支払いが難しいという話をしていますか?
そうです。
それであれば、最初に例えば5か年分まとめて支払いますとかでもいいかなという気もしますけど、
例えばiPhoneとかはタダではありますけど、2世代でしたっけ3世代でしたっけ、
まではOSのアップデートサポートします、それ以上は知りませんというのはもう前提なんですよね。
それと同じ方法で導入する時にサポート範囲を明確にさせて、その上で予算というか値段を決めるというのはあると思いますが、
結局顧客が支払う総額は変わらないので、そっちの方がどちらかというと投資できない気もしますけど。
24:01
どちらにしろサポートするのであれば予算はないと人が動かないので、金は必要だと思います。
そうですね。
そこに支払う金がないと言われてしまうと終わってしまって、実際今そうなっているという状態なので、
そこは結局のところもはや意識の改革しかないのかなと思っていて。
それはやっぱり自分たちがやりたいことっていうのはやっぱりめちゃくちゃ高級なシステムの話してるんだなって認識し直さないといけないってことですかね。
値段の話だけするとそうかもしれないですね。
なんでこれにもありましたけど、電子カルテに移行したから発生したと言われてしまうと、電子カルテあんま良くないじゃんって話はなると思うんですよね。
そうですね。
なんで値段とシステムを導入することでやれるメリット、コミコミで導入した方が良いと判断したならば導入するっていう感じになってしまうと思うんですけれども。
それはでも今の電子カルテも一緒なのかな。
そうですね。あとは原価消却期間をちゃんと決めてもらうところかな。
5年で使い物にならなくなりますっていう。
これはうちとしては保証する保証しないの関係なくもう5年で交換しないとそれはもう壊れたものと同じになるので5年経ったら変えてください。
5年だと長すぎるんですけど。
そういうふうにもうどれくらい経ったら壊れるものですみたいな説明の仕方からしていくのがいいのかなとか思いました。
それもなかなか難しいですね。
ヤクバとかでもハードディスクの有効期間って決められてて数年で交換とかはやってくれてるじゃないですか。
ああいう文脈で話した方が理解早いのかなって聞いてて思ったんですけど。
売り方ですね。
セキュリティ的には正しいと思うのでそれは良いと思います。
ただ強制力はないよねという話が引っかかっていて。
それって消費期限と同じだと思っていますね。
買うときにこの時までに食ってくださいよ消費期限がどちらかというと。
それ以上は知りませんよとは書いてありますけど実際消費期限切れた後に食べるかどうか私たちの自由じゃないですか。
それでお腹壊すのは私たちの自由なんですけど。
27:02
ある意味これも一緒の話で消費期限が切れたシステムを導入しててお腹壊してしまったという事例ですよね。
そうですね。
それは実際そうだのでじゃあお腹壊さないようにしましょうというやっぱり
なんていうか顧客に納得してもらって構造してもらう必要がある。
そこでやっぱり消費期限が切れたら自解するようなシステムを組むっていうのは何か違うような気もするなという気がしますけどね。
難しいところだな。
だからこれが顧客が自社のサービスとして運用するのをベンダーに発注しましたくらいだったらいいんだけど。
今回のように電子カルテを通じてそういう判断をした組織以外の人たちに強く影響を及ぼす社会的影響度の高いシステムだったというところがその辺の判断軸をぶれさせているのかなと思いますね。
そうですね。
なのでやっぱり結局のところは消費期限の話で言うなら、消費期限切れたものは冷蔵庫から取り除くようにハウスキーパーの人が来てくれるっていうことにせざるを得ないと思っていて、
それって何ですかって結局のところ保守契約なんで保守契約するしかないかなって気はしてるんですけど。
実際5年って言って何かクリティカルな事象が発生して3年でおじゃんになることもあるかもしれないじゃないですか。
そうですね。
最近もハードウェア的にやばい事象が発生するとおのことかありますからね。
そうですね。
そうだな。
やっぱり自分たちも作ってるシステムがどういうくらい社会的影響度の大きいそのクリティカルなシステムなのかとかでランク付けして、
そもそもそのランクのものではこういう契約体系しか私たちとしてはできませんくらいのそういうプランニングを持っといた方が良さそうな気がしますね。
そうですね。
それできれば嬉しいですがなかなか自社単体でその基準値を出すのも難しいですね。
難しい。
それ先行してやると多分やってないところばっかり採用されて競争負けするんで。
そういうのがあるんでコンソーシアムみたいなのが抜群するんですけども。
そうですね。
そういう今後の社会課題というかを感じさせるニュースだったんで紹介でした。
では次。
クレジットカード番号等取扱業者に対する行政処分を行いましたという経済産業上の記事です。
内容としては以前紹介した株式会社メタプスペイメントさんの話です。
30:04
以前話したので簡単にサマリだけ言うと、
クレジットカードのシステムを運用していたメタプスペイメントさんよりクレジットカード情報がいろいろ流出しましたよと。
この会社さんではPCI DSSという国際的な基準を持っているということだったにも関わらず流出してしまったということで、
そもそもこの国際的な基準がどうのこうのとか、
こういうクレジットカード決済とか金融事業のところでこういうことが起きてしまうのはいかがなものかということで、
以前話をした次第ですと。
それに対して経済産業省から改めて調査した結果、追加で分かってきたことがあったので紹介です。
結論として見えてきたのは、先ほど言ったPCI DSSで守られるべきものが守られていませんでしたというのが結論です。
どれくらい守れてなかったかというところで言うと、
まず今回流出した原因となったウェブアプリケーションがPCI DSSの監査対象に含まれていませんでした。
このウェブアプリケーションは元々ベンダーによって開発されたものだったんだけれども、
運用が進む中で自社のシステムに一括して取り込むということをした結果、
取り込む前のシステムリストで監査機関に通していて、
取り込んだ後のウェブアプリケーションがその監査対象から漏れてしまっていた。
次にこの取り込んだウェブアプリケーションに対して脆弱性診断ツールを用いて自社で実施していたんだけれども、
ハイとかミディアムとか、一般的にこれが出てたら直した方がいいでしょうという、特にハイですよね。
ハイという検出レベルに対してそんなものがなかったというふうに報告書が改ざんされていた。
このウェブアプリケーションだけじゃなくて、自社システムのサーバーを対象したネットワーク脆弱性スキャンにも行ってまして、
こちらに対してもハイレベルの脆弱性が複数検出されていたんだけれども、なかったものとして改ざんされていた。
ということで、もともとPCI DSSどうのこうのとか言ってたけれども、そもそものその基準に対する守り方がずさんすぎたので、
PCI DSSが悪いわけではなくて、運用が確実に悪いということが分かりました。
改ざんとかが容易に行える体制でもPCI DSSとして通っていいものかとか、その辺の議論はあるかもしれないですけど、
まず前回言っていた国際基準に対しての信用度とかそういった点では別に評価を落とすことではなくて、
33:06
このメタプロユニットさんの運用がただ著しく悪かったという結論ですね。
はい。
まあ落ち着くべきところに落ち着いたんで、良かったなって言い方もあれなんですけど、一番被害は少なかったかなという感じですね。
この会社だけに被害が留まったという意味では。
他の会社も同じことになって可能性もなきにしもあらずなんで、騒々ざらいする必要はあるかなという気もしますけど。
そうですね。
まあそうですね、使用自体にクリティカルにダメだったわけじゃなくて運用がダメだったという話なんで、運用を改善すれば発生しなくなるはずという、また期待を持てる分良かったかなという感じです。
この脆弱性診断の2つについて、またちょっとさっきの話から見てちょっと話をしたくてですね。
さっきセキュリティの対策っていうのが結構技術者的に高コストになってて費用を下げられないみたいな話をしたと思うんですけど、
この脆弱性診断の結果として出てきたハイとかミディアムの結果をハンドリングして適切に処置するっていうフローも合わせてるところってすごく少ないんですよね。
なぜかというと、さっきの病院側の立ち位置と一緒で、これを修正するというモチベーションが顧客側にないので出ましたよと言っても直す財布が出てこないんですよね。
聞こえてます?
大丈夫です。
大体このハイとかミディアム出ましたよという報告書は出たりするんですけど、それに対していつ直しましょう、優先度は後回しですねって言ってほったらかしになり続けるということがよくあります。
この脆弱性診断も現状ではフリーツールとかでパッと見れるという世界ではなくて、かなりセキュリティに強い一部のメーカーが出している専門ツールを用いて何とか出てくるので、
一方でOSSとか世の中一般に公開されているライブラリーというのが活用されている状況で、
36:03
活用されている事例はどんどん増えていて、現状だと世の中にあるシステムの92%くらいがOSSを利用していると。
OSSのメンテナンス頻度がどうなっているかというと、8割くらいが4年以上放置されているということがあって、
OSSはより使っていろんなサービスの開発は加速しているんだけれども、セキュリティはどんどん危ない状態になっていて、それを検証するツールというのがせっかくあるけれども、実際には放置されている。
このハイとかミディアムとかを対処する技術力があるかというと、それもなくてですね。
だいたいこの脆弱性診断ツールが言っていることは、最新のライブラリーにしたら治るよ、もしくは最新のライブラリーが出てないからこのライブラリーを使うのはやめてくださいというようなことしか回答として出てこないんですけど、
ライブラリーをやめるなんていう選択肢っていうのは、実質その機能周りを1からスクラッチで作り直しますという宣言に等しいので、そんな開発予算はどこからも出てこない。
バージョンアップができますかというと、そのバージョンアップのリリースタイミングというのが、次期他のリリースと一緒に合わせてやったらいいよねということになりがちで、
リリースのタイミングになったら時にこの脆弱性の問題を合わせて取り込む時間があるかというと、
だいたいその時期のリリースというのは何かしら不具合が見つかったりとか、緊急リリースタイミングだったりしてまた内側処理にされちゃうということがよくあります。
そもそもこういう脆弱性診断でハイとかミディアムがいっぱい出てくるというのが当たり前になっていくんだけれども、
そこに対しての予算確保や体制確保というのがまだうまくビジネスの中で定義付けられていないままズルズルいっちゃっているので、
今後さらにリスキーな環境が生まれていって似たようなニュースはいっぱい出てくるだろうなというのが初感でしたね。
はい。まず最初に、さっきと同じって話だったですけども、ハイとか診断されたシステムというのは自社のシステムですよね、多分。
なんで、そこはさすがに頑張ってほしいなと思うのがまず最初ですね。巻き取れる範囲なんで。
それをもって顧客は信用して契約しているので、そこは頑張ってくださいという感じ。
現実的に難しいという話については、そうだろうなというのはそうですね。
そこに対してどういう解決法があるんですかって言ったら、今はおそらくなくて。
39:01
ないので、Googleとかがオープンソースの資金提供インプラみたいなのをやらかしてるレベルなので、そういうのに参戦していくしかないんじゃないかなと思いますけどね。
企業度が低くても多少ないと思うより良くなる方策に参加していくしかないんじゃねえのかなとは思っていますと。
実社内で予算がつかんというのに関しては、もうそれはどうしましょうねという感じなんですけども。
現実問題としてでも、適合しているものを出していると言って製品を出している以上、それは宣伝に偽りありとなってしまうので、それはもはや何をもってしても左右性で直すしかないんじゃないかなという気はしています。
そうですね。もう完全におっしゃる通りだから、むしろどちらかというとあれですかね、三菱さんとか日産さんとかの工場現場での不正マインドと似た感覚がソフトウェア開発のこういう現場でも起きてるという感じですかね。
お客さんからクレームが来てないから別にいいっていう。
そうですね。現実問題みたいなところで大丈夫やろうと言って鉛筆なめなめしちゃうみたいな感じ。実際そうなかったもので改ざんしておかないといけないのでそうだと思うんですけども。
まあ、そこが価値じゃないよという話だと思うので、信用込みで運用込みで商品を買ってるっていう前提で商品を作るしかないんじゃないかなと思いますけどね。
いやもう完全にその通りだと思いますね。だからその鉛筆なめなめしやすい材料が結構この脆弱性診断ツールから取れちゃうのもあって。
このはいっていうときにこのライブラリーのこういうインターフェースをこう使ったときにこういうハッキングされる可能性がありますって書かれてたとき。
そのライブラリーの提供してこのAPI使ってるんですか使ってないんですかって言ったらいや使ってないですねって言ったらじゃあ別にはいだけどほったらかしていいよねってよく言いがちなんですよね。
じゃあそれが今後のアップデート含めて無視していい話なのかどうかとかいやそもそも基準としてははいが出たら直さないといけない話じゃなかったのとかそういう議論になかなかいかないって感じですね。
まあでもそこは難しいですね。
それはでも議論した上で何らかしらの基準に則って判断するしかないんじゃないかな。
42:06
そうですね。
そのコーストが念出できないっていう話になってしまうともう前提が崩れてるんじゃないかなと思うので。
それはそうなんですよね。
そこから何とかする前提が崩れた上で何とかするっていうのはちょっと無理というか良くならないんじゃないかなと思いますね。
これもこれで一ついろいろしっさに飛んだ話だったのと、以前話したことのアップデートということで紹介でした。
はい。
では最後ですね。
HTTP-3が正式に勧告。
That's TCP時代の幕開けかということでニッケークステックの記事です。
インターネット関連技術の標準化を手掛けるIETFは2020年6月6日、通信プロトコルHTTP-3をRFC-9114として勧告した。
HTTP-3はインターネット通信の多くを占めるウェブにおける通信プロトコルの最新版である。
最大の特徴はトランスポートのプロトコルにQuickを採用した点。
Quickは2021年にIETFでRFC-9000として勧告された。
その名前が示したようにTCPではなくUDPに基づくプロトコルだ。
TCPが備えていた最早制御の仕組みやTLSによる暗号化処理をQuickが実施する。
HTTPでは基本的に1対1のリクエストとレスポンスが独立して呼び出される。
それらを個々に処理すると効率が下がる。
そこでHTTP-3では複数のリクエストとレスポンスをまとめた仮想的なパイプラインで処理させることで
コネクション確率やエラー処理などのオーバーヘッドを低減させて高速化を図る。
従来のHTTP-2およびHTTP-1ではトランスポートのプロトコルにTCPを使っていた。
しかしTCPは通信データ量のかなりの部分をプロトコルによる制御を占めている。
このため遅延の影響を受けやすくオーバーヘッドも大きい。
特に無駄が大きいのが再接続時の処理だ。
HTTPは暗号化処理の際にTLSを併用する。
このため再接続時にはTCPで接続を確立した後にさらにTLSによるネゴシエーションが必要だった。
HTTP-3はQuickを採用することでこうしたオーバーヘッドを排除している。
HTTP-3はもともと米Googleが開発していた。
対応するウェブサーバーが増え、Google以外にも多くの事業者がHTTP-3への対応を進めている。
Q-Successの調査によると2022年6月時点で約25%のウェブサイトがすでにHTTP-3に対応している。
45:01
皆さん一般につながっているインターネットのベース技術であるHTTPに大きなアップデートが来そうですよということで紹介です。
専門的な話が多かったので、
ざっくり説明するとTCPとUDPという話がありました。
インターネットを閲覧したときにどういうふうにウェブのページが置かれているインターネット上にある外のサーバーと通信するかというプロトコルの仕組みの一つですね。
TCPの場合は、まず私だれだれです、あなただれだれです、こっちはこんなもんですという電話みたいなやり取りを最初にします。
その後、こんなことやりたいんですけど、こんなデータ送りたいんですけど大丈夫ですかとか、その辺のOK、NGみたいな会話をいっぱいした後にデータを送ってきてくださいねという話になります。
昔はそれだけで終わっていたのでまだ良かったんですが、最近セキュリティの対応でHTTPSというセキュリティのSが付いた通信がメジャーになってきています。
今のブラウザであれば基本的にHTTPS通信しか受け付けていないというくらいにはもう一般的になっているものですね。
最後のセキュリティの通信というのが、先ほど言ったこんな通信したいですの会話の後にようやくこんな鍵を使って今から暗号化した通信を始めたいんですけどという会話がそこから始まり、
その暗号化方式だったらうちはこんなふうな対応で受け付けられるよという会話が始まって、じゃあ暗号化うまいこといけますね、今から暗号化されたデータで送りますねという話になり、ようやくその後にデータが送られ始めるということになるんですけれども、
ここまでの過程があまりにも長すぎますし、その部分だけで通信帯域のおおよその部分を奪ってしまうというところもあって、非常にもどかしい通信をしていました。
それでも過去の系譜からしてそういう取り交わしをした方が確実に相手が分かってお互いがやりとりしやすい状態になってから通信するというためのお作法的な話ではあったので、
それ自体が特別悪かったというよりかは、いろんな機器がつながり得た昔のパブリックインターネットの環境、いろんなプロトコルが飛び交っていた環境の中では非常に有用だったという感じですかね。
現時点ではほとんどWebの世界ではHTTP、HTTPSによる通信が行われているので、それを最適化したいという話になり、先ほど今回登場させていたようなQuickによるUDPの通信に変わっていったと。
48:17
先ほどのTCPで発生していた最初のやりとりというのは、一番最初に接続したときだけ行われます。
以降の再接続やセッションというか、あるつながった時点から一定期間内の通信においては、そういったやりとりなくいつでもデータが送れるという形になります。
そうなるとデータの高速性だとか応答性も上がっていくので、Webゲーミングの世界ですとか、あとはFAの現場機器との通信ですとか、応答性が非常に重要視された世界にとっては非常に有用な話になっていて、
従来そういう環境だと、このHTTPではなくて別の通信方式、Webソケットとか、相手とのパイプを繋いでおいて、そのパイプを繋ぎっぱなしにして、一回も切れないようにすることでデータを常に高速にやりとりするという繋ぎ方があったんですけれども、
そういった方式を取るしかなかったんですが、このHTTP3になれば、もうこのHTTP3自体がそれと同じような状態になってくれているので、特別そのために新しい実装を追加したりということがなくなるので、開発コストとかその辺も幅に削減されていくという感じですね。
一般ユーザー目線で体験としてどう変わっていくかですけれども、例えば今までホームページに行ったときにしばらくタブを放置していて、もう一回そのページを開き直すと、また最初に入ったときと同じくらい遅い画面更新になっちゃうみたいなのがあると思うんですけど、あれがより高速化されるですとか、
スマートフォンのゲームアプリでバックグラウンドにほったらかしにしてたやつを開き直した後、ちょっと最初のスータップ、レスポンスが悪かったりみたいなのが改善されていたりとか、そういったことが起こり得るっていうことですね。
いいんじゃないでしょうかという感じですけど、まずTGPIPと言われていた、自分のように言ってたシステムがもう使われなくなるわけではないんですよね、これ。
最初は従来のプロトコルでやって、通信が確立されたらずっとそれを使い続けるようにするという話ですね。
なので、非常にいいんじゃないでしょうかという感じですね。既に25%のサイトが対応しているって話なんで、順調に進んでいけばいいのかなと思いますねという感じですね。
51:14
逆にさっき言ってたこれを使わないとWebソケットですか?常に繋がりっぱなしでちょっと技術的にどうなってるかわかんないですけど、トラフィックの帯域の圧迫とかもまたよくなさそうなので、冒頭にKDDIの話もしましたけど、そういう意味でもハードウェア的にも優しいそうな感じがしてていいんじゃないでしょうかと思ってます。
はい、その感覚は非常に正しくてですね。繋ぎ続けるという技術になった場合は、お互いにメモリとCPUをその帯域分確保しなきゃいけない。中間のレイヤーもそうですよね。確保し続けなきゃいけないので、リソース対効果が悪すぎるんですよね。
Webとかだとサーバー側に対して1万人がアクセスしてきたりとか複数人がアクセスしてくるわけですけれども、そこに対してパイプを作り続けるというメモリを確保しようとすると、そのメモリだけで100ギガとかいっちゃうみたいな。そんな世界になりかねないので、
実際には1万台とか接続するケースでそのWebソケット通信は現実的ではなくて、数台、できれば1対1くらいでしか使えないかなというのが技術的な現実感ですね。ただそこに対して今回のQuickであれば、そういった台数制約もかなり受けない、リソースに優しいプロトコル設計にはなっています。
いいんじゃないでしょうかという感じ。
あとはそうですね、これは勧告しましたっていう話らしいんですけど、これを標準としてくださいと言ったっていう意味なんですかね、これ。
何でしょうね。ここの団体が言ってるのはHDP3という次世代のプロトコルはこういうものですって宣言しただけです。
なるほど。公式で公的にみんなこれを採用しようねって言っただけで採用するかどうかとは言ってないっていう感じですね。
ここら辺の公式プロトコルって見ていくと結構面白いのがあって、鳥による伝聞とか公式に定義されてたりするんで、鳩を使った電子媒体の送付みたいなプロトコルがRFCに定義されてたりとか、本当にこういう通信はこうだよねっていうのを定めただけなんですよ、この人たちは。
そのHDP3を採用するかどうかはブラウザーのメーカーであるGoogleとかSafariを作ってるAppleとかそういったところが考えるし、あとはウェブページをホスティングする側のサービスとして手掛けているソフトウェアを開発しているメーカーだったり、オープンソフトウェアの開発者たちがこれいいじゃんと思って採用したりっていうことを自発的にやっていく形ですね。
54:24
なるほど。従来も4分の1のウェブサイトは対応しているって話したんで、市場の支持も得られているというわけですし、これが事実的な標準になるかなという雰囲気なのかな。
対互換性もあるのでそこら辺が強くてですね。
なるほど。
先ほどおっしゃってた通りですね、従来のTCPによるHTTP通信でHTTP3に対応しますかっていう問いが発生するんですよ。
はいはい。
対応していれば以降の通信がクイックによって効率化される。けれども対応しませんって言ったら今まで通りの通信ができるという仕組みになっているので、ブラウザ側が対応していなくてもサーバー側が対応していなくても特にお互いに困ることがないということで非常に導入しやすいんですよね。
なるほど。
いいですね。
なんかそこら辺ハードウェア側も見習わないといけないなという気がしますね。
ハードウェアはすぐフルスクラッチで作りたがりますけど。
そうですね。
こういうところはね、従来の機種もずっと動いているというのが前提ですからね。
なので本当にhttpは未だに1もちゃんと動きますし、2も3も継続して動くということで。
そういう意味で言うと最初に言ってたセキュリティ上の懸念はありますけど、そういう意味ではそこはさっき言った通りブラウザ側とかが勝手にアップデートしてくれるところで担保するっていう話になるんで。
更新さえしていれば問題ないかなという感じですね。
そうですね。こっちのアップデートについてはですね、ブラウザ側でhttpsしかサポートしませんみたいな割り切りを始めてた話あったと思うんですけど、そこと比べるとhttp3が標準化されたからといってhttp3になってないページは推奨しないとか、そういったことはあまりないかなとは思います。
ユーザー体験としてウェブページを見るインターネットサーフィングの体験が良くなるのは間違いないので、Googleとして検索上位に上げやすい、上げたほうがGoogleとして受けがいいっていう可能性があって、自分たちのホームページがそれをサポートしないばかりに検索上位に出ないってことは出てくるかもしれないです。
57:13
まあありそうですね。確かにそれは。それはありそうですし、さっき言ってた、どうなんでしょう。キックはさすがにしないとは思いますけど、推奨しませんよぐらいは出そう。
かもしれない。今のところは動きないけど。
今のところそのChromeも設定であって、私HTTPSじゃない接続サイトに接続しようと思ったら警告出すようにしてますよ。
なので毎回よく怒られるんですけど、普通に接続してますけど。
そういう機能も実装されているんで、そのうちそれちらがデフォルト有効になる可能性は十分あると思いますね。
そうですね、そうですね。はい、という最新技術の話でした。今日はこんなもんかな。
はい、では本日の内容は小納得にまとめていますのでご確認ください。
リカログではご意見ご感想やこんなことをお話ししてほしいと言いたい方もお待ちしています。
メールアドレスはrecalog.gmail.comになります。
ツイッターもやっていますのでフォローやダイレクトメッセージもお待ちしています。
本番にはpodcast.spotifyに打ち込めるべきことができます。
ぜひそちらでもよろしくお願いいたします。
はい、ではお疲れ様でした。
はい、お疲れ様でした。
