00:06
はい、6月21日、火曜日ですね、時刻は朝9時を回りました。
今日も東京はいい感じの天気で、むしろ昨日よりもどんどん暑くなってきて、もう夏が近づいたという感じですね。
はい、おはようございます。ゆめみのキースことくわはらです。
では本日も朝活を始めていきたいと思います。
えーと、昨日、なんだっけ、アンケートをツイートするって言っておきながら全然できてなくてですね、はい。
あの、まだ送ってないんですけど、ちょっと本当にこの後送ろうと思います。
で、今日読もうと思ってる記事ですけども、タイトルにあるとおり、Web Vitalsっていう、いわゆるパフォーマンス周りの記事ですね。
ちょっと古いんですけど、2020年なんですけど、花火になるというか、僕はちゃんとWebのパフォーマンスとか、計測周りとか全然やったことなかったので、その辺を読んでいこうかなと思います。
で、もう一個は、昨日Twitter見てて流れてきた、IPAが出している情報セキュリティ10大脅威ですね、知っておきたい用語や仕組みっていうところ、
そこを改めて読んで、セキュリティ周りの基礎知識をもう一回復習しようかなと思った次第ですね。
はい、じゃあ早速、前者のWeb Vitalsの方から読んでいきたいかなと思います。
はい、Core Web Vitalsってやつですね。
Core Web Vitalsの測定およびレポートを実施するためのスコアを改善するための推薦事項として、
その辺のWeb Vitals含まれているその他の指標とか進化を続けるWeb Vitalsっていうところを読んでいこうかなと思っています。
はい、じゃあ早速読んでいきたいかなと思います。
ユーザーエクスペリエンス品質の最適化っていうのは、ウェブ上に存在するあらゆるサイトに適応可能な長期的な成功を目指す上での秘訣であるといえます。
Web Vitalsは、ビジネスオーナー、マーケティング担当者、開発者などによる、自身が運営するサイトのユーザー体験の数値化や改善可能なポイントの特定をサポートします。
今から概要に入りますね。
Web Vitalsは、ウェブ上の優れたユーザー、優れたユーザーエクスペリエンスの提供に欠かすことのできない品質シグナルに関する統一的なガイダンスの提供目的としたGoogleによるイニシアチブであります。
Googleではパフォーマンスの測定及びレポートに関し、長年にわたり数多くのツールを提供してきました。
一部の開発者たちは、すでにこれらのツールの使用に精通しているものの、その他のユーザーにとっては、こういった豊富に存在するツールや指標に関する学習を進めていくことは結構難しく感じられてしまうようです。
ユーザーに提供されるエクスペリエンス品質を理解するために、サイトの所有者がサイトパフォーマンスの達人となる必要というのは本来ありません。
ウェブバイタルズのイニシアチブというのは、必要な観点をシンプルに整理し、最も重要な指標であるコアウェブバイタルズへと注力できるようにすることを目標としています。
では早速、コアウェブバイタルズとは何ぞやってどこに入っていきますか。
03:04
コアウェブバイタルズとは、すべてのウェブページに適用可能なウェブバイタルズのサブセットのことを指します。
そのすべてのサイト所有者にとって測定する価値のあるもので、Googleが提供するあらゆるツールで採用されています。
コアウェブバイタルズに含まれている各指標は、ユーザーエクスペリエンスに関する特徴的な観点を提供し、フィールドデータの測定が可能であり、ユーザーを中心とした重要な結果に基づくユーザーの体験を反映します。
このフィールドデータというものと、ユーザーを中心としたというところにリンクが貼ってあって、それぞれ別の記事が貼ってますね。
WebDevというサイトなので、Googleの出した記事だと思いますけど、こちらまで読んでいくとちょっと長そうな気がしているので、ちょっと軽く開いてみますね。
それぞれユーザーのユーザーセントリックパフォーマンスメトリクスとかですね、本当に指標とかの話をしてますので、かつこの記事だけで一本またすごく長いので、ここは割愛します。
後ほどこの今読んでいる記事のリンクをツイートしているので、そこからたどっていただけると嬉しいなと思います。
続いていきたいと思いますね。
Core Web Vitalsを構成する指標というのは、時間の経過とともに進化していて、2020年現在のセットというのはユーザーエクスペリエンスが持つ3つの観点、
いわゆる読み込み時間とインタラクティブ性、そして視覚的な安定性に焦点が当てられていて、以下の指標及び各指標の指揮地というのが含まれます。
大きく3つですね。
LCPと言われるものとFIDと言われるものとCLSです。
LCPというのはLargest Contentful Paint、最大視覚コンテンツの表示時間ということですね。
これは読み込みのパフォーマンスを測定するための指標です。
優れたユーザーエクスペリエンスを提供するためには、ページの読み込みが開始されてからのLCPを2.5秒以内にする必要があります。
今2.5秒に下がったんですね。僕の認識は3秒だったんですけど、2020年時点で2.5秒なんですね。
よりパフォーマンスを求められるようになりましたね。
そこがグッドと言われるものですね。
そこでNeeds Improvementですね。
最低でも4秒は必要だよなと言っていて、4秒以上かかるのはすでにそのサイトではプアだと言っていますね。
続いてFIDです。
こっちはFirst Input Delayというやつで、初回入力までの遅延時間ですね。
これはインタラクティブ性を測定するための指標です。
優れたユーザーエクスペリエンスを提供するためには、ページのFIDを100ミリ秒以下にする必要があります。
グッドは100ミリ秒で、Needs Improvementが300ミリ秒です。
06:03
それ以上はプアだと言っています。
この辺は分かるかもしれないですね。
入力しているのに0.3秒待たされる。
結構人間としては感覚が遅いと思われると思いますね。
続きまして、ラストですね。
CLSです。
これはCommulative Layout Shiftというやつですね。
これは類席レイアウトシフト数ACというものですね。
視覚的な安定性を測定するための指標です。
優れたユーザーエクスペリエンスを提供するためには、ページのCLSを0.1ミリ秒以下に維持する必要があります。
グッドは0.1ミリ秒で、Needs Improvementが0.25ミリ秒です。
それ以上はプアだということですね。
上記の各指標について、ほぼ全てのユーザーにとって好ましい推奨目標値を確実に達成するために、
モバイルデバイスとデスクトップデバイスに分けた上で、
総ページロード数の75パーセンタイルを敷地として測定しています。
一応さっきのLCPとFIDとCLSですね。
それぞれについてちゃんとWebDevがページを押さえて説明していますので、
この辺も見てもらうと、わりと参考になるんではないかなと思いますね。
Core Web Vitalsへの準期を評価するツールというのは、
上記の3つの指標全てにおいて75パーセンタイルという推奨目標値を達成している場合に、
そのページを合格として判断するように設定されていますというところでした。
これらの推奨事項の根拠となる調査及び方法論に関しては、
Core Web Vitalsの指標の敷地の定義というページも用意されているので、
そこを参照してくださいというところですね。
この記事リンクだらけで、Core Web Vitalsをちゃんとやるためには
そもそも予備知識が大量にいるということはよくわかりました。
続いてCore Web Vitalsの測定及びレポートを実施するためのツールとして入ってきますけど、
GoogleではCore Web Vitalsをあらゆるウェブエクスペリエンスにおける重要な指標として捉えています。
その結果として人気のある全てのGoogle製ツール、これもリンクが貼ってますね。
これらの指標の採用に結構取り組んでいます。
このセクションではCore Web Vitalsをサポートするツールについて詳しく説明していこうかなと思います。
続いてそのツールの説明ですけれども、
Chrome User Experience Reportという記事があります。
これもちゃんと別のリンクを貼ってますね。
これはdevelopers.google.comなので別の記事ですね。
ここにあるものが非特定化された実際のユーザーによる測定データを
Core Web Vitalsの各指標ごとに収集するツールです。
このデータを活用すればサイト所有者はページに手動でアナリティクスツールを設置しなくても
09:01
報判数を素早く評価できるようになり、
PageSpeed InsightsやSearch ConsoleのCore Web Vitals Reportなどのツールを
強化することもできるようになりますよと言ってますね。
一応他にもツール2つ載ってて、
Chrome User Experience ReportとPageSpeed Insightsと
Search Consoleですね。
Core Web Vitals Reportといういわゆるレポートだったり
そういうインサイツを使って自分たちのサイトを計測できますよと言ってます。
ちゃんとそれぞれ、LCPもFIDもCLSも測定できるような項目があるよ
ということを示してますね。
もちろんこれらのツールの使い方であったりとか
ユースケースごとに最適なツールの選別に関するガイドラインとか
ガイダンスですね、というものがまた別の記事にもあります。
Web Vitals測定の概要というのがあるので
もし導入しようと思っている方は
そっちの記事のリンクを見てくださいということでした。
続いてGoogle Chrome User Experience Reportというのが提供する
データの活用によってサイトのパフォーマンスを
素早く評価できるようにはなりますが
正確な診断、監視、パフォーマンスの低下に対する
迅速な対応などは実施するために必要となる可能性がある
詳細なページビュー単位のテレメトリーというのは提供されません。
そのためサイトには実際のユーザーを監視する仕組みを
独自に設定しておくことはもちろん強くお勧めしますよ
ということでした。
もちろんサポートはできますけど
これに依存するんじゃなくてというところですね。
監視とかというのは実際このツールではできなさそうなので
これは良い補足ですね。
続いてJavaScriptでCore Web Vitalsを測定するというところですね。
これより具体的な話ですね。
Core Web Vitalsの各指標というのは
標準のWeb APIを使用してJavaScriptで測定することができます。
Core Web Vitalsの各指標を全て測定するためには
Web Vitals JavaScriptライブラリを使用するのが最も簡単です。
Web Vitalsというリポジトリがありますね。
そのリンクが貼っています。
これはGoogle Chromeのオーガニゼーションの中に
入っているリポジトリですね。
JS製なのでこれをインポートしてくださいということでした。
NPMにそのまま公開されているっぽいですね。
このライブラリというのは前述した
全てのGoogle製ツールでレポートされている方法に
完全に一致する方法で各指標を測定することができる
基本的なWeb APIを集めた小さなラッパーですよと言ってますね。
これすごく分かりやすいとかありがたいですね。
このライブラリを使用することによって各指標の測定というのは
単一の関数の呼び出しと同じくらい簡単になります。
詳細な使用方法とかAPIに関するドキュメントというのは
それぞれのリンクがありますので見てくださいと。
このリンクというのがこのWeb Vitalsライブラリの
ReadMeに詳細なものが書いてあるので
12:00
その辺を見てくださいということでした。
簡単なソースコードが出てきているんですけど
使い方としては簡単で
Import FromでWeb Vitalsをインポートします。
ちゃんと名前を明示的にインポートします。
名前はGetCLSとGetFIDとGetLCPという
これも完全にメソッドですね。
というのをインポートしてそれぞれについて
実行してもらえればその通知が測定できますよと言ってます。
サンプルコードには関数が1個定義してあって
SendToAnalyticsという関数を定義してますね。
引数としてはメトリックというのを引数に受け取ってます。
そのメトリックはJSONオブジェクトで渡してくださいということですね。
中ではJSON Stringifyしてそれを変数に受け取って
あとはそのナビゲーターとかだったり
なんたらかんたらですね。
あとフェッチだったりとかそして
データを取得したりするよということをしてますね。
その辺の処理ガチャガチャやったものというのを定義して
それをGetCLSとかGetFID、GetLCPというメソッドに
引数として渡してあげて
それを実行するという感じですね。
なのでそれぞれの関数というのは
引数に関数を受け取るという感じですね。
ちょっと口頭で説明でイメージしづらいかもしれないので
これは上段の記事のコードを見てもらうといいなと思います。
続き読んでいきますね。
WebVitalsライブラリを使用して
Core Web Vitalsデータを測定し
Analytics Endpointへと送信するようサイトを構成したら
次のステップはそのデータの集計及びレポートを実施し
推奨指揮値、ページ別訪問数の少なくとも75%を
満たしているかどうかを確認することができます。
一部のアナリティクスプロバイダーには
Core Web Vitalsの各指標のサポート値が
最初から組み込まれていたりしますが
そうでない場合であっても
Core Web Vitalsを各ツール上で測定可能にするための
基本的なカスタム指標機能が備わっているはずです。
その一例として、サイトの所有者が
Google Analyticsを使用して
Core Web Vitalsを測定することができる
Web Vitalsレポートというのがありますよと言っていますね。
これもGitHubリポジトリのリンクが貼っていますね。
これはGoogle Chrome Labsという別のオーガニゼーションですね。
それの中にWeb Vitalsレポートという
リポジトリが入っている感じです。
その他のアナリティクスツールを使用して
Core Web Vitalsを測定する場合のガイダンスについては
Web Vitalsをフィールド測定するためのベストプラクティス
という別の記事があるのでそこを見てくださいということでした。
またWeb Vitals Chrome拡張機能というのもあるらしいですね。
これもリンクが貼ってあって
これはさっき出てきたGoogle Chromeという
オーガニゼーションの中に入っているリポジトリですね。
またこれもChromeのエクステンションで使えるんだと思います。
これを使用すればコードを記述しなくても
Core Web Vitalsの各指標をレポートすることができるようになります。
なのでざっくりやりたい人は
普通にChrome拡張でインポートして
そのまま使ってもらえればということですね。
それをちゃんとソースコードレベルで
ここのメソッドだけにピンポイントでとか
15:01
ここのフェッチのところだけで見たいとか
という細かなところをやる人は
Web VitalsのライブラリをNPMからインポートして
使ってくださいということですね。
この拡張機能は各指標の測定に
Web Vitalsライブラリを使っていて
内部的に使っているので
それを使ってウェブ閲覧の際に
ユーザーにも表示もできますよと言っています。
この拡張機能というのは
自身が運営されるサイトや競合他社のサイト
競合他社のサイトも確かに使えますね。
Chrome拡張があれば。
とりあえず画面から測定はできますのでね。
そしてWeb全体のパフォーマンスを
把握する場合にも
もちろん役立ちますよと言っていますね。
もちろんさっき述べてきたツールは
全部LCPとFID、CLS
全部ちゃんと測定できますよと言っていますね。
開発者の方で
これらの指標を基本的なWeb APIを使用して
直接測定したいなという場合には
以下のガイドから詳細な実装手順というのも
確認いただきますと。
今言っていた三つの指標ですね。
LCP、FID、CLSというのの測定を
JavaScriptを使ってどうやってやるのかというのが
それぞれ個別に記事のリンクが
貼っていますので
その辺見てくださいということでした。
一般的なアナリティクスサービス
独自の社内アナリティクスツールというのを使って
これらの指標を測定する方法に関しては
Web Vitalsはフィールド測定するためのベストプラクティス
というさっき出てきたリンクというのを見てください。
その中にもカスタマイズした
アナリティクスツールとかを使っている場合も
対応する方法を書いていますよと言っていますね。
続いてCore Web Vitalsの
ラボ測定を実施するためのツールってなんだ?
ラボ測定ってなんだ?
ちょっとわからないな。
ちょっと読んでいきます。
Core Web Vitalsに関しては
フィールドデータの測定が何よりも優先されますが
その多くはラボデータの場合でも測定が可能です。
そのラボデータの測定というのは
まだユーザーに対して公開されていない
開発段階の機能のパフォーマンスを
テストすれば最適な方法です。
またパフォーマンスの低下を
事前に察知したい場合にも最適ですと。
ラボ環境でCore Web Vitalsを測定する環境に
以下のツールが使用可能ですと。
ラボって言っているから
いわゆる僕らで言うステージングとか
実装途中のものかな。
そういう環境でWeb Vitalsを測定する場合には
以下のツールとして
いわゆるGoogleの
Chrome DevToolsとあとLighthouseですね。
なるほど。
この辺を見てくださいってことでした。
ただDevToolsとかLighthouseの方だと
LCPとCLSは取れるんですけど
FIDっていうのは使えませんよって言ってますね。
その代わりにTBTってものがあるので
そこを使ってくださいと。
TBTはトータルブロッキングタイムの略だそうですね。
ちょっとこの辺説明があるのでそこも読んでいきます。
Lighthouseのようなユーザーが存在しない
シミュレーション環境で
ページの読み込みを行うツールっていうのでは
FIDを測定することができませんと。
FIDの測定には
ユーザーによる入力が必要になります。
確かにそうですね。
ただしTBT、トータルブロッキングタイムですね。
いわゆる合計ブロック時間ですけど
18:01
っていうのの指標っていうのが
ラボ環境で測定可能であって
FIDに優れた代替指標となります。
ラボ環境でのTBTの改善に伴う
パフォーマンスの最適化がなされることによって
実際のユーザー環境でのFIDも
一緒に改善されるはずですよと。
公立するパフォーマーに関する
推奨指向というのも
参照してくださいということでした。
ラボ環境での測定っていうのは
優れたユーザー体験を提供する上で
不可欠な要素ではありますけど
実際のユーザー環境での測定にとって
変わるものではないですよ
というのに注意してくださいと。
サイトのパフォーマンスっていうのは
ユーザーが使用するデバイスの性能とか
ネットワークの状態
デバイス上の別のプロセスの実行状況とか
またユーザーによるページの操作方法に応じて
大きく変化しますよねって言ってます。
そりゃそうだよね。
実際にCore Web Vitalsの各指標のスコアっていうのは
ユーザーの操作に影響を受けます。
正確な全体像を把握することができるのは
実際のユーザー関係の測定のみですよ
って言ってますね。
この辺は皆さんも認識の通りだと思います。
続いてスコアを改善するための推奨指向です。
Core Web Vitalsの測定によって
改善点を見つけたら
次のステップはもちろん最適化ですよ
以下のガイドでは
ページを最適化するために必要となる
具体的な推奨指向を
Core Web Vitalsの各指標ごとに紹介しています。
これもさっきの3つの指標ごとに
それぞれ最適化するという記事が書かれてますので
そこの辺も見てくださいっていうことでした。
Web Vitalsに含まれているその他の指標
これが最後のセクション。
あと2つですね。
Core Web Vitalsは
優れたユーザーエクスペリエンスについての理解を深め
それらをユーザーに対して提供する際に
重要な意味を持つ指標ではありますが
重要な指標はこれ以外にも存在しますよと言ってます。
そういったWeb Vitalsのその他の指標というのは
多くの場合
Core Web Vitalsの代替指標または補足指標として機能し
ユーザー体験をより大きな観点から把握して
特定の問題を信頼したりする場合に役立ちます。
まずはCore Web Vitalsを注目してみていこうと
それがないとかそこだとカバーできない
という別の代替指標が欲しいときに使うのがいいですね。
例えばTTFBですね。
Time to First Byte
サーバーの初期応答時間というものとか
FCPですね。
これは皆さんよく聞いたことがあります。
First Contentful Paintですね。
資格コンテンツの初期表示時間とか
などの指標というのは
どちらも読み込み前のユーザー体験に関する重要な観点であって
それぞれがLCPに関する問題
いわゆるサーバーの応答時間ですね。
とかが長すぎる場合や
レンタリングを妨げるリソースに関する問題など
その辺の診断に役立ちますと言っています。
そうですね。確かに。
同様にTBTですね。
トータルブロッキングタイムとか
21:00
TTIってやつですね。
Time to Interactiveってやつですね。
操作可能になるまでのいわゆる時間ってやつですけど
この2つっていうのは
FIDに影響を及ぼす
潜在的なインタラクティブ性に関する問題を察知して
まず診断を実施するために不可欠な
ラボ環境での指標になりますと。
これらの指標っていうのは
実際のユーザー環境では測定できない
ものでして
ユーザーを中心とした
結果も反映していたいため
Core Vitalsには含まれていません
っていうことでした。
なるほどね。
その辺いろんな他の
基準とか指標があったりするので
これも補足として
使っていくといいと思いますよってことですね。
ラストです。
進化を続けるWeb Vitalsってことですね。
Web Vitalsおよび
Core Web Vitalsっていうのは
ウェブ上のユーザーエクスペリエンス品質の測定に関して
現在利用可能な
最高品質のシグナルを開発者に提供していますが
これらのシグナルも
もちろん完璧なものではなくて
将来的な改善や
機能追加ってのが期待されていますと。
Core Web Vitalsは
あらゆるウェブページに関連し
関連するウェブ製ツールにも
広く採用されているため
これらの指標に対する変更の時期っていうのは
広範囲に影響を及ぼしますと。
そのため開発者の方々は
Core Web Vitalsの定義および敷地が
安定していること
そして更に更新にですね
更新に関する情報が事前に通知され
かつ更新が予測可能な
一年中期で実施されていることを
期待しているものと思われます。
Core Web Vitalsの
その他の指標は
コンテキストやツールに特有のものが多く
実験的なものとなる場合もあります。
そのため
それらの指標の定義および敷地は
より頻繁に変更される可能性があります。
Web Vitalsに含まれる全ての指標に対して
実施された変更の内容については
公開されているチェンジログっていうのを
見てくださいと。
以上で一旦この
Web Vitalsっていう記事を終わりたいと思います。
この記事自体は確か2020年の
7月21日に更新されているので
そこからもう更新止まってますね。
なんですけど
それぞれのリンク先の記事っていうのは
別に年とかが振られていないので
常にこの記事っていうのは
更新され続けているものになると思うので
それぞれのリンク先のページっていうのは
参照していいものだと思いますね。
Web Vitalsの最新の記事もどうなのかっていうのを
ちょっとまだ僕は覚えてないんですけど
基本的な指標っていうのは
それほど大きくは多分動かないと思っていて
その数字の見直しだったり
ツールの改善だったりとか
いうところがあると思いますけど
未期となる考え方は
この記事に書かれているもので
全然正しいと思います。
でもその辺を使ってみていただければと思います。
結構勉強になりましたね、僕も。
ちゃんとサイトのパフォーマンスの計測とか
アナリティクスとか
アナリティクスは一応やってはいますけど
やっぱりアクセス数のほうばっかり見てしまっていて
パフォーマンス周りで
アナリティクス使ったことは
実はなかったりするので
ここでちょっと試してみたくなりましたね。
24:00
Web Vitalsっていうライブラリ自体も
ちゃんとNPMに出されていますので。
はい、というところで
この辺も使って
ユーザー待機運動をよくするために
いろいろ計測して改善
最適化していくっていうのは
大事だよねっていう話ですね。
この辺ちょっと僕も
つい先週ですかね
Web Vitalsの記事
久しぶりに目にする機会があって
改めてちょっと勉強したくなったので
今日読んでいきましたっていうところですね。
はい、そうしましたら
残り5分か
ちょっと僕予想では
この記事もっと早く読み終わる予定だったんですけど
5分だったので
もう一個の方ですね
IPAが出している
情報セキュリティ自由大脅威っていうところですね
知っておきたい用語や仕組みっていう
PDFがIPAから公開されていて
それをちょっと読んでいこうと思いました。
しかもこのPDF自体が
2022年の5月ですね
つい先月出たものなので
元々出たものをアップデートしたのかどうか
ちょっとわかんないですけど
これを読んでいこうかなと思いますと
大きく3章に置かれて
1つ目は理解は必須
2つ目が知っていますかというところで
3章目があっていますかという意識みたいなところですね
というところをちょっと見ていこうと思います
いわゆる1章というのは
呼び知識というか
名前すら知らないみたいな人たちのために書かれたものっぽいですね
脆弱性とか多段階認証
もしくは多様層認証ですね
キャッシュレス決済とかスマホ決済や
なんやかんやみたいなところですけど
残り時間5分なんで
どこまで読めるかわからないですけど
これ読んでいって続きは
明日読んでいこうかなと思いますね
結構大事な内容だったりするので
この辺は改めて
復習していきたいかなと思ったりはします
もちろんこの辺も
知ってるよという方に関しては
しゃがみ説法みたいな感じになってしまって申し訳ないんですけど
聞いてみたい人だけは
お付き合いいただければなと思います
始めに
パソコンやスマートフォン及びそれらを使った
インターネット上のサービスというのはすでに会社や家庭に
広く普及していて
生活基盤の一部となっています
様々な製品や
インターネット上のサービスが次が次へと登場してきていますが
それらをトラブルなく
安全に利用するためには
製品の取扱説明書やサービスの契約内容
利用規約等をよく読んで
その仕組みや注意するポイントを
よく理解することは大切ですと
しかし特に
新しい言葉や聞き慣れない用語等も多く
全てを調べ理解するのは高々大変だと思いますと
本書では
パソコンやスマートフォンインターネットを
利用するための対策を取る上で
ぜひ知っておきたい用語や仕組み
技術名称やサービス名称等を
いくつかピックアップして
それらについて概要や
よくある疑問点を解説していきますと
おっしゃることは正しいんですけど
全ての製品や
サービスの契約内容
利用規約を全部読んでいる人は
たぶん一握りだと思いますし
それ読むエネルギー
めちゃめちゃかかるので
ぶっちゃけサボってると思いますし
もちろん仕事上の契約書とかは
全然読みますけど
そうじゃない限りは実際そんなに読んでなくて
読んだ方が大切なのは分かるんですけど
いやー
なんか正論で殴られてきた感じですね
27:00
まあいいや
早速読んでいきます
一生理解は必須というところですね
一つ目は脆弱性ですね
もうこれこそ
社会説法かもしれないですけど
世の中に出回っている製品とか
インターネット上のサービスには脆弱性が含まれている
場合があります
脆弱性とは何かというと
脆弱性がある商品とか
製品およびサービスっていうのはどういうことか
どのように対策すればいいのかっていうのを
正しく理解し向き合っていく必要があります
脆弱性とは
ある製品やサービスに含まれる
セキュリティ上の弱点のことを指します
広くその中ですね
脆弱性を悪用されることで製品やサービス
利用者の情報が漏れしまったり
製品やサービスの機能を不正利用されたり
してしまいます
安全な製品やサービスを開発しようとしても
開発元が意図しないで
脆弱性が含まれてしまうことも多々あります
開発者がどれだけ注意しても
それをクラッキングしてくる人たちもいるので
なんとも言えないですけどね
また製品の発売時点や
サービスの開発時点では脆弱性がなかった
気づかなかったとしても
内在していた脆弱性が後々発見されたり
技術や環境を変化することで
新たに顕在化したりする場合ももちろんありますよ
よく発見される製品は危険ですか?
問いですけど
犯罪者等に
悪用されてしまうような脆弱性が含まれている
製品やサービスを利用する
というのは確かに危険なことと言えます
ただし完全に脆弱性のない製品やサービスを
開発することは非常に難しく
どんなものにも脆弱性は付きものです
いいですね
IPAがこういうことを言ってくれるのは結構嬉しいですね
100%そんなことないように作ってくれって
たまに言われますけど
そんなものを世の中見たことないわって感じですね
例えば
日々多くの脆弱性が発見され
頻繁にアップデートを実施している製品とか
サービスが危険なのかというと
一概にそうとは言えません
良い製品サービスであり
広く普及しているため脆弱性が発見されやすいが
製品提供元のサポートが手厚いので
頻繁にアップデートされているという
見方もあります
逆に
あまり利用されていない製品やサービスの場合は
一見脆弱性なさそうに見えても
単に脆弱性が発見されていないだけ
という場合もあります
これはライブラリの仕様でも結構似てますよね
イシューとかプロリクエスト
いっぱい出てますけど
ちゃんとチームが日々更新しているという
リポジトリ更新をしているのであれば
結構サポートもしてくれる可能性もありますけど
ただGitHubとかのイシューが
めちゃくちゃ多かったら
あまり見ていない可能性もあるので
そこは良し悪しですけどね
逆にそういうイシューとかプロリクエストが出てないけど
最終更新が数年前とかって
誰も使ってなさそうなものという意味では
それは確かに脆弱性が見えていないだけだ
という可能性もあるので
ライブラリ選定の時にこの辺の指標というのは
結構リンクするなと思いました
はい
脆弱性対策というのは最新版にアップデートしましょう
というところですね
基本脆弱性というのは放置することは非常に危険で
利用している製品に脆弱性が発見されたら
速やかに最新版にアップデートしましょうと
また製品を選択する場合には
その製品の機能価格だけではなく
脆弱性が発見された場合に
30:00
きちんと対応してくれるのかという
製品アップデートしたり
対策の方法を公開していますか
みたいなところですね
などサポートの手厚さやサポートの期限等も
考慮して製品を選択することが簡易ですよ
という風に書かれています
続いて
多段階認証と多要素認証というところですね
というところに行きたいんですけど
9時半を超えてしまいましたので
一旦今日の朝末はこちらで以上にしたいかなと思います
明日は続いて
このIPAの
情報セキュリティの話の
続きを読んでいこうかなと思います
今日もご参加いただいた
たくさんの方々ありがとうございました
明日もゆるーと読んでいきますので
もしご興味があれば
お付き合いいただければ嬉しいなと思います
では今日の朝末は
こちらで以上にしたいと思います
今日も頑張っていきましょう
