68【何を気をつける？】AI駆動開発のセキュリティ

脆弱性対策の基本は継続的なアップデート

こんにちは、AI駆動開発部の日常へようこそ。このポッドキャストでは、日々AI駆動開発を行う企業家の山本とエンジニアの阿部が、AI駆動開発のリアルを緩く語り合う番組です。

はい、じゃあよろしくお願いします。

よろしくお願いします。

はい、じゃあ前回がPHPの脆弱性の話があって、本当にね、最近セキュリティの問題がすごく目にしない日はないぐらいね、いろいろありますがっていうところで、

AI駆動開発とかするにあたって、どういうところ気をつければいいんだっけ、みたいなところをちょっと阿部ちゃんにアドバイスしてもらえると、僕も参考になるし、聞いてる人もちょっと気にしようかなっていう風にな

るのかなと思っておりますので、そんな時間できればと思っています。

あと個人で普通にセキュリティちょっと注意しなきゃ、普通にユーザーとしてもね、みたいなところも注意点とかこういうのをお勧めだよ、みたいなのがあれば教えていただけると嬉しいです。

なるほど。

まあね、セキュリティか開発してる時というか、なんかいろんな観点というかありそうですけど、例えば開発してる時に注意しなきゃいけないこととか、

開発をサイクルとして回していて、デプロイする時とか、そういう仕組みを作る時に注意しなきゃいけないところ、あとは実際に運用をしていて、使ってるアプリケーション自体に何か脆弱性っていうものが入っていた

りして、攻撃されないか注意しなきゃいけないこととかっていうのが結構あると思うんですよ。

で、まず先週とか話題になってたPHPの脆弱性っていうのは、今最後に話したような、実際運用しているアプリケーションの中に脆弱性が含まれていて、そこが攻撃されるところのリスクなんですけど、そこの辺りから話

していくといいのかな。

でも正直、これ多分エンジニアの皆さん、そうだよねっていう感じの話で全員合致するような話かなとは思うんですけど、前回のPHPの脆弱性とかに関しても究極的に言うと、アップデートを怠らなければ止まらないよね

みたいな。

そういう話に結局行き着くことが多くて。

前回に限っては若干特殊で、アップデートを細かくやってたとしても、脆弱性がアップデートが配布される前に公開されちゃったっていうので、ちょっとひともんちゃくあったりしたと思うんですけど。

とはいえ、いまだに1週間経って、僕が使ってるサービスとかだと昨日ぐらいにようやくアップデート終わって更新できましたみたいな。

あ、1週間もかかったんだみたいな。

そういうことも脆弱性が発生したときに出てきたりするんですけど。

すぐアップデートして対処終わっている会社さんだったりと、1週間ぐらい時間がかかってしまっているところの差って何かなって思うと、究極はやっぱりアップデートを普段しているかどうかにかかってくるんですよね。

で、やっぱりアップデートしてないと、バージョンっていうのがとにかく世界では、例えばワードプレスとかは1週間に1回とかそのぐらいの頻度でアップデートが走っていくと、

1年ぐらいとか半年放置しただけで、そこから最新に持っていくのがすごい大変になるかっていうので、こういう緊急の脆弱性の問題が起きて、早くアップデートしないとっていうときにすごく困ったりして。

で、困った結果、結局そこの修正するためにお金払えないとかになって、そのまま放置されて、最終的には情報漏洩とかに繋がってしまうみたいな。

そういうケースをよく見かけるなっていうふうには感じているので、究極的にはバージョンアップを常に行っていれば、困りにくくなるのかなっていうような感覚はありますよね。

バージョンアップは、常にし続ける仕組みみたいなのっていうのは、週間にするみたいな話なのか、こういうのをオンにしておくだけである程度検知できるかなみたいな、そういう仕組み上のものがあるのかみたいな。

これはね、2つどっちもあるんですよ。

例えばワードプレスとかだと、バージョンアップを自動で行う設定がありまして、特に僕らは何か動かなくても日々のマイナーアップデートっていって、セキュリティパッチみたいなものは日々適用されていくっていうのが

結構ありまして、標準に搭載されてまして。

企業さんとかだと、やっぱり知らないうちにアップデートされて、知らないうちにサイトがレイアウト崩れてるとか、そういうのを恐れて、やっぱりアップデートやめましょうみたいな判断を取られる時もあるのかなと思

うんですけど。

結局それで情報漏洩とかになるぐらいだったら、レイアウトの崩れぐらいは許容できるよねとかっていう判断で、バシバシアップデートを入れるとかっていうのも正直あるんじゃないかっていうのは感覚としてはあります

よね。

ちょっとそこは事業的な判断とかもあると、どうしてもレイアウト崩れたら致命的だみたいなのがもしかしたらあるのかもしれないんですけども、あんまりそれよりはセキュリティ的な問題に対策してる方がリスクテイク

できるんじゃないかなみたいな気持ちは僕の中ではあるんですけど。

その標準的にあるっていうのは、自動アップデートみたいなのをしてくれる仕組みがあるってこと?

もうありますね。ワードプレス上のデフォルトの設定とかで、基本的にはオンになってるはずなんですよね。

ワードプレスだったらってことか。

例えばですね。

じゃあないやつもあるってこと?

たぶんないような、一般的に使われてるようなサイトで言うとワードプレスなので今例に挙げてるんですけど、

例えばそれ以外のブログサイト、何があるかな?

ブログサイトだけじゃなくても、AI駆動開発で例えば僕みたいな営業を自分でして、

エンジニアの知見はないんだけど自分で開発もしてるみたいな人とかもいるわけだと思いますし、

だからブログとか以外とかも含めてなのかなと思ってて、

そんなにブログサービスとかにこだわる必要なくって感じなのかな?

変わってるというよりかは、アプリケーションとして使っている限り乗っかっていて、

そのアプリケーションが自動アップデートを提供しているのであれば、

当然それはオンにしておいた方がいいっていうのはあるんですけど、

例えば起業していて、ゼロから自分でシステム作ってますよみたいな、

例えばレイルズとかララベルとかネクストJSとか、

いろいろウェブのフレームワークとか使ってウェブサービス公開しますよみたいなことをやってる人たちがいると思うんですけど、

そういうウェブサービスを作るためのフレームワークを使っている場合は、

基本的にはアップデートは自分で行わなければいけないっていうのがありますよね。

なんでかっていうと、それっていうのは基本的には自分たちでフレームワークを開発環境にインストールして、

開発して、それをサーバーとかにアップロードしてリリースするみたいなサイクルをとっているので、

リリースを自分たちで組まなきゃいけないっていうところがあって、

そのリリースの仕組みの中に自分たちで自動アップデートの仕組みを入れるか、

手動で運用するかっていうのをどうしてもやる必要が出てくるっていう感じですよね。

聞きたかったのは、こういうツールを使っておくと便利だよみたいなのがないのかなっていうのが気になって聞いてた感じ。

それでいうと、例えばそういう人たちはGitHubっていうソースコードを管理するようなシステムを使うと思うんですけども、

GitHubとかはDependabotっていうソフトウェアのバージョンアップを自動的に検知して、

アップルリクエストを作成してくれるような仕組みがデフォルトでありますので、

もともとはこれDependabotってGitHubがデフォルトで提供していたものじゃなくてプラグインだったんですけど、

それがGitHubが買収してデフォルトで有効化されるようになったことによって、

自動でそういうアップデートを作れるようになっているので、

そういうアップルリクエストが来たら、自分で承認してリリースかけるとか、

あとはもうCI、CDのパイプラインの中で日時でアップデートを自動適用するみたいな仕組みを自分で作ることもできるので、

そういう形で自動アップデートを作ること自体はできるんですけど、やっぱりそれは自分で仕組みを作らなきゃいけない。

Dependabotはデフォルトでオンになっている?

そうだね、確かそのはず。

じゃあもしDependabotみたいなやつからプラグインが作成されてなかった場合は、

もしかしたらオンにする必要があるみたいなのがあるかもしれないっていう感じ?

そうだね、確か新しくリポジトリを作るときに、

Dependabotをデフォルトでオンにするかどうかを選択できるような気がしていて、

それをオンにしていればデフォルトでオンになっていて、

そのままだったら自動でプレリクエストが来るみたいな仕組みだったと思います。

もしオンになってなかったなと思ったとしても、

AIに言えばすぐオンにできるぐらいの設定にはなってますよね。

ちなみに毎日アップデートって言いましたけど、

とはいえすぐアップデートされても困るっていうのは、

変なコードが埋め込まれてみたいなリスクもあるわけですよね。

その辺も気をつけないといけないみたいな感じ。

例えばアップデートが使ってるパッケージができましたみたいなときに、

パッケージ自体にマルウェアが仕込まれているみたいな、

それをサプライチェーン広域とかって言うんですけど、

ああいうのは防御する必要がどうしてもあって、

例えばディペンドボットも制御できるんですよ、

どういうタイミングで通知を出すかとか、

どれぐらい間隔を空けるかとかっていうのが設定できて、

例えば1週間以上アップデートが発生してから、

1週間以上アプリケーションの方に適用がされてないときは通知を投げるみたいな、

そういうのを入れることで結構防げるんじゃないかなっていうふうに思いますよね。

そういう意味では今回のPHPのときは、ある種特集だったっていう感じなんですね。

すぐにアップデートしないといけないみたいな状態ってあんまりない?

基本的にはそんなになくて、

たまに緊急でアップデートしてねみたいな、なるべく早くアップデートしてねみたいなアナウンスが出たりするんですけど、

前回のPHPほど本当に今すぐ上げないとリスクにさらされるんじゃないかっていうことっていうのは、

そうそう起きないというのはあるんですよね。

なので基本的な運用としては割とやるのが、

例えば週に1回のアップデートをしているようなプロジェクトだったり、

1ヶ月に1回のアップデートをしているようなプロジェクトだったりすると、

次回のリリースにそのアップデートを混ぜて出しましょうみたいな、

そういう話をしたりもするんですよね。

でもそれもこれも結局、

日々アップデートをできるような体制がないと、

やっぱりアップデートすること自体に手こずってしまうっていうと、

トラブルを他で誘発するみたいなとも、

やっぱり起こりやすいので、

常日頃アップデートすることをやって、

体制としてできる状態を作るっていうのは結構重要なんじゃないかなっていうのは、

ライブラリ依存と自作の判断

ちなみに開発していくにあたって、

最近だとAIがある程度やってくれるからこそっていうところで、

ライブラリを使うのか、もしくは自作するのかっていう判断を迫られることって結構あると思っていて、

こういう問題、サプライチェーン攻撃とかそういうことまでひっくるめて考えたときに、

超安易に考えるとですけど、

究極的には何にも依存しない方がいいんじゃないかみたいな感覚にも落ちちゃうなって思ってて、

それ結構僕の中でも、とはいえ依存してた方がやっぱ、

結局動きを保証するという意味では、

いいライブラリに依存してた方が安定するみたいなところもあったりするけど、

サプライチェーン攻撃とかになってくると、

そのライブラリ自体は問題なくても、

そのライブラリがさらに依存している先みたいなのに問題があるみたいなところがあると、

依存が増えれば増えるほど、

もうクモの巣みたいにバーっとリスクが広がっていくというか、

っていう感覚があって、

そこってなんだろうね、

もちろん別にわざわざ依存する必要もないよねみたいなライブラリもあるのかもしれないけど、

結局作るってなるとしんどいよねみたいな、

だからこそそのライブラリは今まで存在しえたみたいなのも、

特にちゃんと一定認知があるものとかそうかもしれないですけど、

その辺の判断って、

僕もここは悩みますよね正直、

それこそ今言ってたように、

究極全部自分で作ればいいみたいな話が、

まさに先週とかそういう論が生まれてたりして、

言語から自分で作った方がいいんじゃねみたいなことも言ってる人もいたりしたんですけど、

それはそれで自分の作ってるやつに脆弱性が含まれることを、

かなり軽視した発言じゃないですか、

そうなんですよ。

例えばフレームワークを自分で作ろうっていうのも、

かなり難しい話かなって僕は捉えてて、

やっぱりフレームワークとかを運用して、

世界中の開発者がそれに対してコミットしてて、

日々脆弱性のアップデートを入れているんですけど、

その脆弱性もかなりアニメをつくような脆弱性が見つかったりするので、

それを一個一個自分でサポートして網羅していってみたいな、

全く起きないことを保証するっていうのも、

ほぼ無理に近いかって思っていて、

なので何かアプリケーションを使うとかフレームワークを使うっていうのは、

今後も必須になってくる選択肢なのかなと思っているんですけども、

一方でそれに依存して、

追加のライブラリとかを入れるかどうかみたいなものに関しては、

少し吟味するようになってきてますね、

まずは採用するかしないか自体も。

ある程度使用が明確で、

依存しなくてもAIにコードを書かせれば十分網羅できそうなぐらいの、

ライブラリを採用するのであったら、

もう自前で作った方がいいかなっていうのは思っていて、

この間、これまたワードプレスの話に戻ってしまうんですけど、

特にワードプレスはプラグインっていう仕組みがあって、

そのプラグインを使うことで脆弱性が仕込まれることもかなり多い、

リスクがより高いものではあるので、

ほとんどプラグインは採用せずに自作するっていう対応を取ったりしたんですよ。

でもそれ自体そんなに難しい対応でもなくても、

AIにこういう仕様だから、あとはこういうプラグインがもともとあるので、

真似してねというか、こういう仕様なのでやってねって伝えるだけである程度できてますし、

ただ一方でそうともいかないライブラリだったりプラグインもあって、

それらに関してはもうなんか長年運用されているその信頼性を信じるとか、

あとはやっぱり依存関係がその網名、なんか地図繋ぎ的に、

依存するものにどこかに問題があったら影響を受けるよねみたいな話に関しては、

さっき話したようにリリースされてから1週間後にやっと入れるとか、

ちょっと時差を置いてアップデートかけていくような運用をすることで、

完璧ではないけど防御を入れていくっていうような、

そういう対策になってきているかなと。

なるほどね。

なんか、ちなみに、例えば、

そうだな、どういうケースが、

どういうケースっていうかあれかな、

例えば、ある程度目的がはっきりしてるってなった時に、

フルスタックのフレームワークを使う必要がないみたいな場合だったら、

みたいな時とかもあるけど、

けどとりあえずこれでやれみたいな感じの、やっとけみたいな感じの判断をする時もあるのかなと思っていて、

だからいわゆる将来においてできるだけ選択肢の広い技術選定をしていくみたいなイメージっていうのかな。

それをできるだけ薄いというか、目的が限定化されているものを使うようにするとか、

その先がないのであれば可能性としてね。

とかっていうのもあるのかな、イメージワークかな。

だから将来的な、よりスケールしたりとか機能をガッと増やしていく時とかに、

できなくなる可能性はあるけど、あえてそこは潰して、よりシンプルなフレームワークを選択するみたいな。

そうそうそうそう。

なんか僕とかだったら、それぐらいで限定できそうであれば、

フラッシュスクラッチでAIに書いてもらうっていうのを割とやったりすることもある。

なるほどね。

フレームワークを選択しないんだったら、軽量なライブラリーを使うよりかは、

ほぼフルスクラッチっぽく書いてもらう。

完全に依存をゼロにすること自体は、意外と難しかったりするんですけど、

それでも減らしていくようなことは全然選択肢としてあるし、

実際にやって動いているプロジェクトもあるので、

僕はそれでもいいかなと思ってます。

最近本当にコードを読みながら、

とにかくレビューであったり、実際に動かしている中で、

ユーザーにとって使いやすいかどうかっていうところと、

機能拡張の点で進むかどうかっていうところの二軸が、

関心ごとになっているっていうところがあって、

ユーザーにとって使いやすいかどうかは、僕たちが触って確かめて、

本当に触ってて違和感がないかなっていうところをチェック。

将来積むかどうかっていうのも、

正直フレームワークを選択しなかったとしても、

これは人間が開発していた時代は積みが発生していたと思うんですけど、

AIがフルスクラッチで書いたとしても、

あまり積みってやってこないというか、

なんとかやりきってくれる部分があるので、

そういう意味ではあえてフレームワークとかを選択しないことは、

全然あり得るかなとは思ってますよね。

ちなみに、例えばうちのいくつかの案件の中でも、

案件もそうだし、自社でララベルを使っているプロジェクトがあったりとか、

結構ちゃんとアップデートするじゃん、阿部ちゃんは。

基本的にアップデートしたがるって大変だけど、

アップデートしてきたがるタイプだったじゃん。

別にAI以前からも含めてだと思って。

それが酵素押しというか、

そんなにめっちゃ大事にならなかったみたいなところがあったと思ってて、

一方で引き継いだばっかりの案件で止めざるを得なかったみたいな。

使っていたプラグインの依存的にも、

アップデートしちゃうとそっちが壊れちゃうから、

もちろん頑張ったらできるんだけど、

今それをやるんだったら、

ちょうどうちがリニューアル任せてもらっていたからみたいなところがあったけど、

それだったらそっちを急いでリリースしましょうみたいな感じの

意思決定になったみたいなのがあったと思って、

それと同じような、

ネクストが結構古いのに依存してるんだったっけ?

なんか言ってたよね、昔。

ウェブパックとかに依存してるからって話かな。

そうそうそうそう。

ネクストがそういうケースに当たるのかどうかはさておき、

どうしてもコアな部分で古いものに依存してるが故に、

もうアップデートできませんみたいな状況って消えるのかなっていう。

阿部ちゃんの言う罪みたいなので言うと、

最悪リアクトルーターとかタンスタックとかにガッと書き換えるみたいな。

もうできなくはないよねという意味で、

罪はしないだろうっていう話だと思うけど、

なんかそういうのとかってあったりするのかなっていう。

ちょっと具体的な例は思い浮かばないけど、

全然ある気はしていて。

例えばですけど、

ネクストが依存してるウェブパックっていうのは、

ネクスト自体をビルドするために必要なライブラリなので、

もう本当にコアのコア。

これがアップデートもうできない。

けど脆弱性あるとかになった時に、

じゃあ僕ならどうするかって言われる。

多分フルリプレイスを選択するか。

それこそウェブパックに自分でパッチ当てに行くとかして、

強制的に動く経路を確保するしかも方法はなくなるんじゃないかなとは思いますけどね。

仮にただ、

例えばですけどターンスタックとかリアクトルーターっていうのに乗せ替えましょうみたいな話になったりもすると思うんですけど、

正直それも乗せ替えもかなり大変で、

AIがやってくれるからといって、

多分AIにもループで実装機能を完全に模倣しようみたいな感じに言っても、

言っても完璧に仕上げてはくれないじゃないですか。

1週間とか2週間とか平気でかかる。

機能の数にもよると思うんですけど。

なので、あんまり乗せ替えること自体が未だに現実的ではなくて、

もしやるんだったら強制的に脆弱性のあるライブラリに対して、

パッチを当てて自前でビルドしてリリースするみたいな。

そういうことはできなくはないし、

かつ全然起こり得るリスクではあるのかなと思いますね。

ちなみにウェブパックの話は、

今聞いた感じで言うとビルドするためのもの?

そこに脆弱性が仕込まれるみたいなことはあんまりなさそうみたいな感じなの?

そう、厳密に言うと例としてウェブパックが出てきたので、

例えば話してたけど、実際にウェブパックに脆弱性が仕込まれて、

サイトに何か悪意のあるコードが埋め込まれるっていうこと自体は、

あんまりケースとしては少ないのかな。

ビルドするものは実行時に動くコードではないので、

よっぽど悪意があって、例えばビルドの中に、

ウェブパックがビルドするコードの中に、

セキュリティ的なセキュリティホールを埋め込むみたいな。

そういうことだったらあり得るかもしれないですけどね。

それは、そのバージョンは使わないようにするぐらいで阻止できそうな話。

そうだね、実行できなくなるみたいなね。

攻撃的な意味合いの脆弱性。

今回のPHPみたいな意味合いっていう感じではないよね、今の話。

ちょっとまた違うかなと思う。

あるとすればという意味で。

だとすると、

NEXTはそういう意味で言うと、

何を選定していても起き得るという意味ではあまり関係ない。

現時点では正直、NEXTがとか、リアクトレーターがとか、

ターンスタックがとか、どれが悪くなりそうみたいなのは、

正直予想不可能なものみたいなぐらいの感覚のイメージ。

だから、他の企業の社長さんとかから話して、

ワードプレスとかをいっぱい運用してるんですけど、

他のの世界先ないんですか?みたいな。

PHPの問題があったりとか、

ワードプレスってセキュリティの問題、結構耳にするよね、みたいな文脈で。

利用者が多いみたいなもんね、前提として。

利用者が多いっていうのもあるし、

じゃあワードプレスやめて、

じゃあNEXTで自前で作りましょうってなったとしても、

結局アップデートする体制があるかどうか次第で、

アップデートして脆弱性を回避することがし続けられれば、

別にワードプレスの方がむしろ全員の幸せとかっていうのは全然あり得るので、

やっぱり最初に言ったように究極はやっぱりアップデートできるのが一番大事みたいなところに戻ってくるなって。

そういうことだよね。結局だからM'とかクラウドフレアがワードプレスの思想をやって、

やってるワードプレスみたいなものを作ってみたいなのをやってるけど、

じゃあそっちにしても、ある種いまいま最近できたばっかだから、

破壊的変更ばっかで、脆弱性にはさらされてないんだけど、

めちゃくちゃ破壊的変更起きてアップデートしまうのが大変みたいなことにもなりかねないみたいなのもありそうだよね。

ワードプレスぐらいある意味PHPとかワードプレスぐらい枯れてないと、

そういう他の問題も起きそう。そうすると結果的にアップデートを阻む理由が増えるというか。

アップデート幅が無理でできて、結局だから枯れている技術で安定しているっていうことの方が、

長年ウェブを運用するっていう観点でいうと、大事というか。

なので、やっぱりどうしてもPHPっていうのは世界の本当に様々なシステムで使われているので、

やっぱり脆弱性っていう文脈で注目を集めがちではあるんですけど、

疲れててアップデートがそれなりに早くて、

安定的である方が僕としては安心なんじゃないか。

あとはもう運用をしっかりすればいいっていう話なんじゃないのかなみたいなところがあります。

Cloudflare・VercelとAWSの使い分け

なるほど。しかも今の特に企業をして自分でサービスをエンジニアではないけどやるみたいな、

立ち上げるみたいになった時に、正直ララベルもレールズも選ばれないイメージがあって、

それはもうJavaScriptで全部統一みたいな方が正直多分初心者にとっては分かりやすいし、

結局AIはそれを選択したがるみたいな。

ユーザー側であえてララベル使いたいことを言わない限りは選択されなさそうだなみたいな、個人的には。

僕、こういうサービスを構想しててみたらよく相談するがゆえに思うことがあって、

そこはなんだろう、AIに委ね切ってた方がいいのかなんだろう。

例えば阿部ちゃんとかが自分でやるとか、

僕がだったら阿部ちゃんが大体オフィスにいるから

阿部ちゃん何がどう思うみたいな相談ができるみたいなのがあると思うけど、

前提として相談する相手がいない場合において、

どういう選択をしたらいいか。

僕の中でいろんな選択肢が提示された時に、

一番クロートが使ってそうな言語をできるだけ選ぶようにするっていう、

僕の中の共通ルールではある。

みんなが安易に手を出すようなところを出すと、

よく分からないコンテキストとかもいっぱい学習してる可能性があるっていう。

できるだけエンジニアが選びそうなものを選んでいく、

一つ筋としてはあるんですけど、選択する筋としては。

確かにね。

どうだろうね。

AIがお勧めするのがJS、JavaScriptとか、

それを使ってホスティングするクラウドフレアとかバーセルとか、

そういうのによりがちだと思うんですけど、

それはもうデプロイとかサーバー割りのエコシステムが、

JavaScriptの方が整ってるというか、

あとは選択肢をそんなに設けなくていいっていうのがあって、

多分JavaScriptとかでホスティングするようなものって、

要はそんなにサーバーの設定とか頑張らない前提なんですよ。

スペックもそうですし、前段にプロキシスサーバー用意したいよねみたいな、

それこだわりもなくて、とりあえずクラウドフレアとかにホスティングすればJavaScriptが配信されて、

それをHTMLが読み込んで動きのあるかっこいいサイトになるよねとか、

ウェブシステムになるよねみたいな。

なのでやっぱりAIはデプロイの簡易性とかも含めて、

クラウドフレアとかバーセルっていうのをお勧めしてくると思うんですよ。

バーセルも結構脆弱性があったりするとか、

これ周りに問題があってみたいな話が起きてきたりするんですけど、

サーバーにあまり詳しくなくて、

頑張ってPHPでAWSとかにデプロイしましょうみたいなことを頑張るぐらいだったら、

僕はクラウドフレアとかバーセルに乗せることの方をお勧めしたいかなっていう。

なるほどね。だからパッキングされてるからそれに乗っかってた方が、

むしろ素人が変にやるよりは安全だよねみたいな感じの意味ですね。

本当にそうで、Java AWSとかも結構やっぱり難しくて、

素人って言うとあれですけど、わからない人が触ろうとすると、

セキュリティグループとかIAMの設定とかって言って、

アカウント情報が漏れたときのダメージのデカさで言うと、

AWSがえげつなかったりするんですよ。

それこそ100万、1000万の請求が来るとか。

かつそれを踏み抜くパターンがあまりにも多いんですよ。

それは何でかって言うと、やっぱりフロート向けであるからこそ、

設定項目が多くて、いろんなカスタマイズができるんですよ。

そこを踏み抜くと、一気に情報を抜かれるとか、

サーバーに一気に侵入されて、

踏み台サーバーに使われるとかっていうのは起こりやすくて、

それよりも、やっぱりCloudflareとかバーセルとかは、

もう選択肢自体は少ないんですよ。

設定できるサーバーのスペック自体も、

ボタンで3種類とか、ポチポチって選択するぐらいしかできなくて、

モデルとしても影響の範囲は知れてる。

ダッシュボード見やすいとかね。

それがゆえにアップデートボタンも用意されているとかで、

ボタンポチでアップデートできるとか、

そういうユーザー向けの便利さもサーバー側として担保してくれてるんで、

そっちの方がお勧めかなとは思います。

なるほどね。

そういう意味で究極的にはレプリットみたいに、

その中でDBも全部用意してくれてるみたいな。

そっちの方がむしろいいよねみたいなとかもしかしたらあるかもしれないし。

あるかもしれないし。

レプリットもレプリットで、データベースとか自分で用意してくれるから、

何でもかんでもAIにお願いしたら、

次は大事なユーザーの日々のあるデータとかも全部データベースに平分で放り込んじゃって、

それが脆弱性になるみたいな。

そういうリスクもやっぱりあるんですけど。

じゃあいざ本格的にエンジニアもチームに入ってもらって、

スケールを目指す環境のシステムみたいなのを作ろうみたいになった時に、

結構厳しいなみたいな感じ。

できなくはないけどみたいな感じにもなりそうよ。

レプリットとかで逆にロックインされてデータが持ち運べないとかで、

サーバー以降も大変だみたいな話になったりとかもあると思うから。

そういう意味ではレプリット内でも確かスーパーベースにするとか確かあったと思うから、

何の選択が不可逆になりそうかみたいなのは、

エンジニアには相談しておいた方がいいかなみたいなぐらいなのかな。

いいと思いますね。

スーパーベースも非常に便利で安いっていうエリットもありますし、

個人開発でデータベースを選択する時に第一級の選択肢になると思うんですよ。

他にはクラウドフレアのD1とかもあると思うんですけど、

あれらってすごい楽ではあるんですけど、

やっぱりネットワーク、全世界のネットワークに公開されるディスクもやっぱりあって。

例えばですけど、アプリケーションはクラウドフレアでホスティングしておいて、

データベースはスーパーベースにしましたみたいな時に、

クラウドフレアからスーパーベースに対してリクエストを送って、

それを公開されたネットワーク上でレスポンスとして受け取るみたいなことがあるので、

その中間の経路で抜かれるっていうディスクもやっぱり本当ははらんでいるので、

できればデータベースっていうのはネットワークにさらしたくないっていう前提としてはあるんですけど、

でもそれをやろうとするとやっぱりAWSとかになるので、

やっぱり急に難易度が上がるとか、

プライベートネットワークっていうのとパブリックネットワークっていう、

いろいろそういう考え方があって、

AWSがプライベートネットワークっていうのに完全に閉じて、

データベース自体は外にさらさないみたいな仕組みを作れたりとかもするので、

そっちがいいよねみたいな話もあったりするんですけど、

WAFとネットワーク経路の防御

あとあれかな、さっきアップデートの話が結構メインになったんですけど、

あとはあれですよね、開発してる時に注意したいというか、

新しいサービス公開する時とかに結構大事なのが、

ネットワークの経路をちゃんと防御的にしてあげるっていうのが大事かなと思ってて、

アプリケーションを作って、

例えばPHPとかそれこそJavaScriptとかもそうなんですけど、

そのままそれらをウェブサーバーにして公開して、

リクエストを受け付けるっていうこと自体はできるんですよ。

ただ間にお客さんからの通信とサーバー側の通信のところの間には、

必ずWAF、Web Application Firewallっていうネットワーク自体を監視して、

不審なアクセスがあったらブロックするっていう仕組みを必ず入れてあげたりとか、

あとはNode.jsとかPHPどっちもそれぞれがウェブサーバーになれるんですよ。

例えばPHPはPHP FPMっていうウェブサーバーがあったりしますし、

Node.js自体がサーバーになったり、

炎っていうウェブサーバーのクライアントを使ったりして、

それ自体をウェブに公開することができるんですけど、

必ず前段にEngineXとかApacheっていうリバースプロ機種っていうような仕組みを導入することもできて、

こういうWAF、リバースプロ機種でアプリケーションみたいな構成を作っておかないと、

U字があった時に結構困るっていうのがあって、

入れた方がいいよねっていうのがあって、

じゃあそれ何に困るのみたいな話なんですけど、

前回の、前回というか先週のPHPの話とかもそうなんですけど、

例えばPHPに脆弱性ありましたって、

じゃあサイトのアクセスを遮断しますみたいな、

サイトをブロックしますみたいな企業さん多数出てたと思うんですけど、

じゃあどこで止めるのみたいな話が起きるんですよ。

ネットワークの経路の中でどこで止めるのみたいな話になって。

例えばPHPだけで動かしてる時って、

PHPでリクエストを受けちゃうんで、

止めるって言ったらもう本当にPHPのサーバー自体を落とすみたいな話になって、

じゃあメンテナンス中ですみたいな画面出せないよねみたいな。

メンテナンス中の画面出そうかなと思って、

それを用意するとPHPで結局動いてるから、

それって防げてないみたいな。

そういうことね、PHP自分だけじゃんみたいなね。

そうなっちゃうんですよ。

そういうのを回避するために、

例えばNGXとかパッチは別のシステムで、

PHPとは関係のないもので動いて、

そこに決まったページを表示するみたいな仕組みを作ることができるので、

そこでメンテナンス中ですっていうのを出してあげたりとか、

さらにその前段階にWAFとか同じようなレイヤーに

CDNっていうクラウドフレアとかがやってるような仕組みがあるので、

そのCDN側で今はメンテナンス中ですって画面を出すことによって、

本当にアプリケーションがウェブに対して到達しないようにも、

通信経路を遮断することが間に合ってできるので、

そういう仕組みは入れておかないと結構有事の時に困るっていう。

それは何でも言えること。

例えばワードプレイスやりますみたいな感じで、

ブログやりますみたいなのも含めてってこと?

それかウェブサービス、全てにいる。

全てにいます。ワードプレイスもそうなんですよ。

だからXサーバーで、実際にこれ僕対応してる時に

なんで?ってなったことがあったんですけど、

Xサーバーって、Xサーバーの管理画面自体がPHPで動いてるんですよ。

あの先週のPHPの問題が起きた時に、

Xサーバーが何したっていうと、

管理画面を完全にメンテナンスモードに突破で入れたんですよ。

ってなると一般的な利用者からすると、

なんかワードプレイスに問題がある。

じゃあXサーバー側のサーバーの設定をいじって

公開を停止しようって思った時に、

管理画面にアクセスできないから停止できないんですよ。

じゃあしょうがないからワードプレイスで

ベーシック認証のプラグインを入れて止めようかなとか

っていうようなことをしようとしても、

そのワードプレイスのプラグインであるようなベーシック認証って

PP側で止めようとしたりするんで

ワードプレイス側でやってるからってことだよね。

アプリケーション、到達してほしくないアプリケーションのところに

立てることになるみたいな感じになるんだよね。

そう、ことになるんで

結構なんか

踏んだというか

どうしようってなった人多いんじゃないかなと思って。

どうしたの?

僕はあれですね、サーバーに直接入り込む

SSHができるようにしてあるので

サーバーに直接入り込んで

アパッチの方で

咳止めるっていう対応を入れて

ウェブから遮断するような対応を取ったりしていたんですよ。

なので、普段

SSHとかしてない人はもう結構困ったんじゃないかなとは思います。

なるほどね。

なので

必ずそれを入れる仕組みは

どこかに設けておいた方が

良いかなと。レンタルサーバー系だと割と

ちゃんとやってくれてるところが多いっていうか

基本的にどこまでやってると思うんですけど

気にしてあげるといいポイント。

あれはね、AIで

エンジニアがこれから不要になるんじゃないかって

世間でニュースにもなってる中で

急にワードプレスとか

いわゆる今まで素人でもちょっと勉強したら

ブログサービス立ち上げれますみたいな。

しかもそれで何だったら受注して稼げますみたいな。

オウンドメディア建てるみたいな。

みたいなところから一変して

ワードプレスでさえって言ったらちょっと変だけど

でさえエンジニアにお願いした方が

ちょっと安全面考えると良さそうみたいな

世界に急転換してる。

考えるとなんかおもろいね。

そうだよね。

そういう細かい何かあった時のテクニックみたいなのは

専門って言うとあれですけど

長年それなりの期間ずっと

それに対してやってるからこそ

いろいろ引き出しがあるので

そういうのはできるなって。

僕なんてもうAIいるからエンジニア不要になってんなと思って

仕事なくなるなって思ったんですけど

今回も変で

意外とそうかって思って

ある意味安心みたいな。

ある意味安心だけどある意味セキュリティに侵され続ける

結構大変よね。

責任の所在が一番怖いところに

どんどん僕は寄ってきてる。

総スター数

エピソードをシェアする

Instagram シェア画像

埋め込みプレイヤーのカスタマイズ

プレビュー

カラーテーマ

AI駆動開発部の日常

感想

サマリー

目次

総スター数

コメント

感想を書く

このエピソードのトピック