セキュリティ三大NGとは
ふて寝するほど話したい。この番組は、システム開発25年の株式会社プラムザが、赤坂より開発現場の今と本音をざっくばらんに話していこうという番組になります。
進行は私、鴨志田と、代表の島田と、風から復帰しました辰巳です。よろしくお願いします。
これ年明けの収録で、辰巳さんが風邪をひかれて、予定が変更になったということがあったから、先ほど辰巳さんが風邪からって話があったと思うんですけど、実は鴨志田も対象を崩してまして、辰巳さんと同じようなタイミングで、それを共有してずらしてもらうかどうか迷っていたので、結構助かったという感じです。
まあでも、今風邪結構流行ってますよね。
いや本当に、それこそ僕も帰省して、実家の家族がみんな風邪をひいてたんで、僕も一緒にいたらそれが映るようになって、明らかにNGなことをやってしまったという感じです。
全然ひかないな、俺は。
本当ですか?
年始に集まって、そこでおそらく映されたのか、なんか家族みんなカッコン糖ってわかりますかね、なんか漢方みたいなのを配って、これ飲んどきなーって配られてましたね。
効くらしいよね、カッコン糖ね。
カッコン糖結構効くと思いますね。飲んだことあります?
ありますあります。小さい頃、あの、すっごいまずいやつですよね、確かね。
あー、でも多分今飲んだらそこまでだとは。
あ、本当ですか。
飲みやすくなってるかわかんないですけど。
苦い感じのイメージですけど。
そうそう、まあでもおいしくはないですが、なんか聞き始めぐらい、ちょっと怪しいなぐらいに飲んどくと、結構治り早くなったりしたりするので、ぜひ全然、あ、じゃあカッコン糖の案件お待ちしておりますというところで。
どんな案件?
全然関係ないですよ。
教会と親和性がゼロですからね。
ちなみに今回のタイトルとも全く関係のない体調を崩したというところのタイトルですかね、今回のテーマいきたいと思います。
パスワード使い回しの危険
中小企業が絶対にやってはいけないセキュリティ三大NGというタイトルになります。
そうですね、年末に配信したどの収録が一番再生されているかという中で、セキュリティのものがぶっちぎりで再生されていたということもあってということだったり、ちょくちょくこれに近い話題って結構話してると思うんですが、改めて絶対にやってはいけないセキュリティ三大NGと、これどういった視点でのNG、運用になるんでしたっけこれ。
これをやってるとまずいよねっていう感じで、再生が結構あったエピソードに関しては汎用的と言いますか、一個ずつやっていくという段階を踏む中でどんどんできることが増えていくと思うんですけど、
NGリスト的な観点で今回はかつわかりやすくクリティカルなものをピックアップして、これってまずいよねみたいな話をしていければなと思います。
ありがとうございます。一応手元ではすでに3つ共有されているわけですが、これ読み上げてしまって良いですかね。
本当に簡単なやつは皆さんご存知だと思うんで、そういうのは除外して、もう少しワンランク上の話をしようという感じですね。
パスワードを付箋につけて貼っておくとか、そういうのはもう使い古されすぎてるし。
パスワードをパスワードにするとか、12345とかね。
それを今やってる人はもうきっと一緒にやるんでしょう。
というわけで、3大NG。1つ目、パスワード使い回し。
これはやめましょうというところで、3大NGの1つかなというところで、当然これはやっちゃいけないだろうと思いつつ、
どうしてもやはりこれは利便性が勝ってしまうというところで、よく行われてるだろうという感じですかね。
言い方を選ばずに言うと、ぶち破られていい環境とかのアカウントだったらこれでいいと思うんですよ。
まだ何もほぼ開発していないテスト環境みたいなところだったりとか。
本番環境とかでこれやっちゃうとアカウントですよね。
それこそ1個パスワードが分かってしまうと、いもずる式に他のアカウントとかも割り出されちゃって、
データ暗号化されてみたいなことにつながってしまうと思うんで。
これ多分2つ意味合いがあって、1つのパスワードを複数のサイトとかシステムで使い回してるというパターンと、
1つのアカウントを複数人で使い回してるという、これ使い回してるのはどういう意味?どっちなんだろう?
多分どっちかというと後者に近い気がします。
後者だよね。後者は1つのアカウントで管理者アカウントとかっていうのは会社で大体決まってて、
それを本部の人たちみんな使ってるとかね、運営のスタッフはみんな同じように使ってるとかっていうことが結構あったりすると思うんだけど、
それもまずいんだよね。
それはどういった観点でまずいんですか?
それもいくつかまずい理由はあるんだけど、1つにはメンバーの誰かが辞めたときに辞めた人が知ってるとかっていう状況が簡単に作られちゃうわけですよね。
そういうことをやってると、辞めた人とかは、あの会社は運営の人たちみんな同じアカウントを使ってるって知ってたりするんで、
例えば変えてもね、またちょっと1つ付けただけじゃないかとかさ、1を2にしただけじゃないかとかって推測されたりするんだよね。
運用の観点で1つ僕から言うと、みんなが同じアカウントを使ってると、
データベースでそのアカウントによって何かしらが書き換えられたり新しく作られたりしたら、結局誰がやったんで問題が出るんですかね。
問題が起きたときにたどれないっていうことが出てるんですね。
確かにそれはセキュリティ対策してるとは言いがたい、避けたいことですよね。
そうなんだよね。うちが作るシステムでも、ユーザーの管理画面で必ず作るんだけど、
お客さんによってはね、うちはみんな同じアカウント使うからユーザー管理画面いらないかみたいなことを言われたりするんだけど、
やめてって。
困るんですよね。完全に一生そのアカウントを使い続ける気ままみたいな感じだよね。
これは基本的に一人一アカウントとかログがたどりやすいように分けておくっていうのが基本的な運用になるんですかね。
もちろんそうだね。
同じスタッフでも権限がそもそも違うはずなんで、これ2つ目の話になっちゃうかもしれないですけど。
2つ目いきますか。
やってはいけないセキュリティ三大NG。2つ目、管理者権限で何でもやってしまう。
権限の管理と運用
先ほどの話と通ずるものがあるかもしれないですけれども、
役職とかメンバーによって同じシステムの中でも触っていい場所とか使う機能とかって本来違うはずなんですよね。
経理の人が営業の機能を使うことって多分ないと思うし、
営業部長の人と営業のスタッフの人と見れる情報って多分違うはずだと思う。
そこで権限をちゃんと細分化してないと良くないっていうところはまず一つありますよね。
これがそもそもそういった権限の設計っていうんですかね。
っていうものがちゃんとできてないとシステムにも当然落とし込めないので、
システムを作る時とかそういった時にせめてちゃんと整理しておいてほしいっていうところで、
実際にそう運用しましょうよっていうところがセキュリティにつながるっていうことなんですかね。
そうですね。初めに要件定義とか決めるときにしっかりその辺グルーピングして、
管理者どんなグループがあるのかっていうのを聞いて、
その設定をうちの場合は多分初めに聞いてデフォルトではしてあげると思うんだよね。
お客さんによってはそれをまとめて一番権限強いやつをみんなで使って運用が楽なんでね。
そういう会社は結構あるんだよね。
ありますね。それこそ直近ですけれども、
おそらく本来付与すべきでない権限を負ったユーザーがやってはいけない商業をしてしまって、
セルフ障害に近いものを起こしたっていうこともありましたんで、
やっぱりセキュリティというかシステム運用の観点でも、
そこって表裏一体だと思うんですけど、セキュリティの管理って、
そこらへん非常にシビアな話になってくるんで、後々往復引いてくる可能性が高いですよね。
でもこれを取り入れる、それこそ先ほどのパスワード使い回しとか、
管理者権限で何でもやってしまうということを避けるための障壁と言いますか、
単純にめんどくさいっていうことが大きいんですかね。
めんどくさいと。やっぱり前もちらっと話したことがあるんですけど、
基本的にセキュリティをしっかりしようとするとめんどくさいですし、
無視しようとすると楽なんですよね。便利というか。
トレードオフっていう話が確かありましたね。
そこでいい塩梅っていうのを組織の中で落としどころを見つけておくっていうのは重要です。
あとあれですかね、プラムザの場合だとある程度パスワードの管理の方法とか、
自社のシステムの中で完結しているというか、やりやすいようには決まっていると思うんですけど、
一般的な特にシステム関連じゃない会社さんとかだとパスワードの管理がめんどくさくなるのかなというのを
今改めて聞いていて思ったんですけど、皆さんどうやってるんですかね、パスワードの管理とかって。
今はね、最近はブラウザのシステムがほとんどなんで、
そういう意味ではブラウザは覚えてくれてるよね、Googleとかとね。
あれは一応セーフなんですか。
それは考え方にもよるけどね。
使っちゃダメっていう人もいるかもしれないですね。
そうなんだよ。
ただ端末ハックされたらもうおしまいっていうのは、
復元テストの重要性
一つの割り切りだったりするんだよね。
端末ハックされないっていうことを大前提にしてるっていう会社もあるし、
セキュリティのPマグとかISOとかのやつでもそこを守る。
端末をハックされないように守るっていう。
それをやるよね。
インターネットを社外に公開しないとか、
いろいろやり方あると思うんですけど。
そこら辺もトレードオフというところで、
しっかり最初に設計とか話し合ったりとかして決めていく必要がありそうって感じですよね。
では、やってはいけないセキュリティ三大NGの最後。
3つ目、復元テストをしていないというところが上がってますが、
復元テストってどういったことになるんでしょうか。
それこそさっきの話でパスワード漏えいしましたとか、
権限でやってはいけない操作してデータが壊れちゃいましたみたいなことがあると思うんですよね。
そこそこのシステムだったら定期的にデータのバックアップを取るんですよ。
それを復元用のサーバーとかで復元することを復元作業といって、
いきなり復元やったことないのにできないじゃないですか。
手順書とかもあらかじめ作る必要があるし。
定期的にテストとかもやったほうがいいんですよね。
めっちゃ簡単に言うと避難訓練ですよね。
避難訓練やってない状態で災害が起きたらどうするのって話ですね。
今までは起こらないようにっていう話をしていた中で、
起こってもすぐなんとかできるようにっていうところの対策ってことですかね。
まったくその通りです。
確かに復元テストをしていないと、
すぐに例えばサービスとして行っているようなシステムとか、
社内のシステムであったりしても、
単純に業務に支障が出るとか売上げに影響が出るってことですもんね。
ということです。
これもほぼ実例に近いものがございまして、
同社さんの名誉のためにオブラートにお話しますけれども、
とある事情でサーバーが全く使えなくなったんですよね、その本番環境。
テスト環境とかも同居してたんですよね。
復元できるものも何もないっていう、
サーバーの存在が消えてしまいましたっていうことが過去にございましてですね。
そうなったら復元の仕様も何もないよねっていう。
それどうしたんですか。
どうしようもないんで、一から作り直すしかないです。
ソースコードはリポジトリにあるんで。
セキュリティにおけるトレードオフ
それタサのシステムを引き継いだやつだよね。
引き継いではないです。ゼロから作りました。
お家がそこで設計したの?
先方にこういうリスクはありますよっていうのをあらかじめ言っておいて、
テスト環境と本番環境を同居したら、
どっちかがぶっ壊れてサーバー使えなくなったらもう終わりですよって話は当然してます。
でもコストメリットからそちらを選ばれて、結果的にそうなってしまった。
ちょっとそのリスクもゼロじゃなさそうだなと思ったんで、
僕も強めに言って絶対それをやめた方がいいですって言えばよかったなと思ったんですけど。
でも実際に起こるようなことを想定しておいたとしても、
コストの観点からとか、あまりセキュアにしすぎてもっていうところが
実際の運用のラインにどうしてもなってくるんだろうなっていうのを改めて引いていて。
コストにはかかってくるんで、復元のテストっていったって本番サーバーで復元テストできないので、
復元するためのサーバーが必要なんだよね。
その瞬間だけ、テストする瞬間だけ立ち上げるにしても、やっぱり環境を作っておかなきゃいけないので、
環境を作るのにもお金がかかるし、テストのときにはまたインフラを動かすお金がかかるし、
工事もかかるからね、作業費もね。
人間の日々の生活に例えると、常日頃地震と津波を想定して生きていくわけにもいかないので、
お金と時間とか、心のコストがすごいかかるんで。
そうですよね。やってらんないですもんね。
やってらんないと思うんですよ。
改めてセキュリティの話をしていくと、やっぱりトレードオフって、
今日の配信で何回言ったかわかんないですけど、
そこら辺がやっぱり肝なんだなっていうのを改めて思いましたね。
間違いないですね。そこをお客さんと我々で擦り合わせしながら、
ゴールがここだったら落ち着くのはここだよね、みたいなのがある程度わかりますんで。
今回の配信はそんなところですかね。島田さん最後に何かありますか?
そうですね。トレードオフなんで。また言っちゃったけど。
その辺はやっぱり経験豊富な会社が、開発会社の方である程度のところを提案していくしかないのかなというふうには思いますね。
お客さんの方ではわかんないこともあるし、やり始めたらキリがないとかね。
今日ちょっと話そうかと思ったんだけど、この2ファクター認証とかね、
いうのはありますけど、ああいうのもやればやるほど不便になっていくっていうのは間違いないのでね。
どの辺で落ち込むかっていうのはね、悩みどころですね。
じゃあ実際ちゃんと話しながら、具体的な現実的なラインをお客様と決めていくというところですかね。
そうですね。
ではこんなところで本日は終わりたいと思います。
本日はいかがでしたでしょうか。楽しんでいただけましたらフォローや評価をお願いします。
またXでも最新情報を随時発信していますのでよろしくお願いします。
システム開発に関するご相談がございましたら、公式ホームページからお気軽にお問い合わせください。
それではまた次回お会いしましょう。
ありがとうございました。
