企業が持つべきセキュリティ意識とは？EGSS徳丸浩氏、細野英朋氏×クラスメソッドエンジニア座談会

日本でもクラウドサービスの充実や大規模採用が進み、企業のクラウド環境導⼊は今やスタンダードな選択肢となりました。その一方でセキュリティ上の課題は現在も大きなトピックとして日々話題に上がります。

企業として考えなければならないWebセキュリティとはどういったものでしょう。徳丸浩氏が代表を務めるEGセキュアソリューションズと、AWSセキュリティ監査ツールインサイトウォッチ（insightwatch）や技術支援サービスを提供するクラスメソッドによるセキュリティ座談会（2018年実施）をDevelopers.IOに再掲します。

（2018年9月21日 東京・EGセキュアソリューションズ株式会社にて収録）

境界防御から認証への意識変⾰

田子昌⾏（以下、田子）　クラスメソッドの田子です。⼊社以来10年ほどWebアプリ開発やビッグデータ分析基盤の構築などに関わってきました。今は「インサイトウォッチ（insightwatch）」をはじめとした⾃社サービス開発に関わっています。

⾅⽥佳祐（以下、⾅⽥）　⾅⽥です。⼊社して1年半ソリューションアーキテクトとしてお客様のAWS構築などをやっています。セキュリティ分野に注⼒していて、前職や学⽣時代もそうでした。実は以前「サイバー犯罪に関する⽩浜シンポジウム」の危機管理コンテストに出た頃に徳丸先⽣にはお会いしています（笑）。ちなみに学⽣の前に⾃衛官として⾃衛隊の暗号機の整備をやっていました。セキュリティにはその頃から馴染みがあります。

徳丸浩（以下、徳丸）　私はもともと京セラに85年⼊社し、FORTRANでプログラマをしてから⾃社ブランドのパッケージソフト開発でクライアントサーバアプリのコードを書いていました。 それをWeb化するところからWebの分野に親しむようになったのですが、次第にセキュリティを求められることが多くなり、開発からセキュリティにシフトしていくようになって。そして2008年に独⽴して⾃分の会社（EGセキュアソリューションズ。以下EGSS）を設⽴しました。いまはWebアプリのセキュリティを主にやっています。

細野英朋（以下、細野）　EGSSに2年少々在籍しています細野です。脆弱性診断とセキュリティのコンサルティングに携わり、開発段階からセキュリティ対策をやっています。前職はISPで、出向でセキュリティ組織に⾏ったときに 脆弱性情報の収集や侵⼊されているサイトの情報を扱い、そこからセキュリティに関⼼を持つようになりました。

――まずは漠然と「クラウドって今どうですか」ということを聞かせてください。

徳丸　いきなり難しいお題ですね（笑）。まあ「クラウド」をどう捉えるかですよね。仮想化技術を使いはするけれど、クラウドって実際はインターネット活⽤で、⽬的はさまざまです。例えば企業のストレージサービス利⽤のように、インターネットよりも深くネットワークを活⽤することがクラウドじゃないかなと思っています。

⾅⽥　はい。

徳丸　これって実はすごい変化で。もともと⽇本の情シスは境界防御という発想で「イントラネットを作ってファイアウォール（FW）で外の脅威から守る」ところから抜けられませんでした。でも、クラウドが便利だからインターネットの本格活⽤がどんどん進んで。そうなると企業の情報資産がインターネットにある以上「従来の境界防御だけではダメだよね」となっていったんです。

⽥⼦　お客様が「クラウドかどうか」を昔ほど気にしなくなりましたね。ここ10年でAWSに数々のマネージドサービスが出て、堅牢なセキュリティを⾃分たちで作り込む必要がなくなって。⾃分たちで作り込む場合はライブラリでちょっと注意を怠ると⽳ができてしまうのでその⽳をなるべく作らないようにする流れにすらなってきた気がします。

⾅⽥　僕は普段いろいろなお客様のもとに⾏って、クラウドを使えばセキュリティが強化されると思っているお客様もいれば、今でも「セキュリティ的に不安だよね」と話すお客様もいて、さまざまだなと感じます。

徳丸　確かに安全と不安それぞれの考えの⼈がいますね。不安な⼈はまがりなりにも境界で守られていたところから⾶び出し、リソースをインターネットに置く不安があるんだと思います。でも境界を守れば安全かというとそうではない。例えば標的型攻撃でウイルスに⼊られたら、境界の中も外も関係なくなります。私はそろそろ“境界モデル”から卒業して認証とか認可をしっかりやるべきだと思っています。乱暴ですが「企業内ネットワークもインターネットだ」と思えばいい。イントラネットもインターネットも区別しないよというほうがクラウドを安全に使えますし。

臼田　そうですね。

徳丸　AWS、Google、マイクロソフトなど各社にしっかりやってもらうのを信頼するのも、しっかりした基盤をリーズナブルに使えるのもいいこと。なので、極端に不安だから使わない⼈や、安全だと思い込んで⾃分で何もしない⼈が出るのはどちらもよくないことだと思います。任せるところと⾃分でやるところをしっかり区別して責任を果たすのが⼤事。

⾅⽥　お客様が不安になる場合って「クラウドとは」というところを知らないケースが多いですね。そこに関してはAWSをまるっとおまかせって形のコンサルティングをするので、お客様から⾒て「クラスメソッドがやってくれたら安⼼」という期待は感じるんですが（笑）。

⽥⼦　お客様⾃⾝でセキュリティポリシーを整備しているところもあるし、「クラスメソッドでうまくやってほしい」といったご相談を受けることも多いので、安⼼できる使い⽅をこれからも提案していかないといけないなとは思っています。

徳丸　典型的に、AWSにのっかるアプリやサービスはどんなものが多いですか？

⾅⽥　圧倒的にWeb+DBですね。モバイルアプリは弊社でも開発しますが、アプリ側は基本お客さま側で⽤意しています。少なくともAWS部分はやっていて、WAFや上位レイヤーをある程度カバーするオプションを提供するとか、「AWSでこういうサービスがあるので活⽤してみては？」と提案することはあります。OSやミドルウェアには構築時に携わることがありますね。 それで、セキュリティ⾯でいうとAWSの責任共有モデルに近くてOS、ミドルからはお客様という責任分担になるので「どうしたらいいですか」と相談を受けることは多いです。脆弱性管理のソリューションがあるので定常的にミドルウェアの情報をお客様が取るとか、重⼤な脆弱性が⾒つかった時にすぐアップデートする環境を整えられるようツールの提案をすることもありますね。

徳丸　私はクラウドって基本的にいいものだと思っています。ただIaaSとかVPSは基本的にOSから上は利⽤者側が考えないといけないということを考えず、安さから採⽤されることが多く、セキュリティがおざなりにされているんじゃないかって怖さがあります。いちばん怖いのはVPSで、レンタルサーバを使う⼈たちがSEO上有利になるという動機で導⼊するケースが実際にある。そこはクラウドのせいじゃないけど、クラウドが広まることによる弊害として⼼配しています。クラスメソッドではどういったことをしていますか？

⾅⽥　IaaS的な提供をされているものはお客様側で⾒る必要があります。SaaS的なものであればバックエンドのOS もラッピングされていてAWSのほうで⾯倒を⾒ているので、お客様はPythonなりNode.jsなりのコードだけで⼤丈夫ですね。「なるべくインフラの⾯倒をみたくない」という場合は、最近だとマネージドのサービスを使ってサーバーレスの構成にすることが増えてきています。

徳丸　お客様との間でそういう会話が出るだけでもすごくいいことだと思います。

⾅⽥　ただ、僕らが関わらない部分で何か問題が起きたらそれはそれで気になるので、クラスメソッドが提供するのはインフラだけど、アプリの設計やセキュリティも⼀緒に考えるといった感じでいけたらと思っていますね。

徳丸　確かに、こちら側の責任範囲じゃなくてもお客様に何か事故があれば冷や汗ですね。脆弱性診断を担当したお客様にセキュリティ事故があれば、実際は担当した範囲外だったとしてもそれを安⼼していいのかという葛藤があります。

クラウドセキュリティ課題はどこに︖

⾅⽥　クラウドを使うことで⼀定のセキュリティが担保されるとは思うんですけど、逆に、新たに出てくる課題はどのようなものがあるとお考えでしょうか︖

徳丸　それは純技術的な課題と、⼈間側のクラウドに対する過剰な期待で⽣まれる問題をわけて考える必要があります。最初は主に前者だったんです。仮想化基盤を使うので、CPUのバグが話題になったように、ホストマシンに複数のゲストが来て、ゲスト同⼠のやりとりから情報が漏れるんじゃないかっていう技術的な懸念がありました。あとは仮想化ソフトウェアのパッチをクラウド事業者がちゃんと適⽤できるのかというテクニカルな話題ですね。ですが、私はさほど現実の問題にはならないと思っています。実害がでたという話も聞かないですし。それより従来からあるものとして、ベタな話ですが、クラウドやVPSのコンソール画⾯、パスワードがバレればECサイトからクレカ情報が盗まれるなどたちまち⼤変なことになります。

⾅⽥　いままで物理で守っていたものがクラウドにいくので、それを操作するマネジメントコンソールなどのセキュリティが重要だと。

徳丸　はい。従来は境界で守られていたからパスワード管理が⽢くてもさほど⼤事故にならなかったんです。例えば退職者が悪いことをしようとしても、会社に⾏かないとデータには触れずリスクは低かった。でもクラウドだと、VPNなどをやっていなければログインまでは⾏けちゃう。過去にある会社の退職者が業務⽤VMを⼗数個削除して逮捕されたという⾝の⽑もよだつようなケースがありましたし、AWSなどのクラウド基盤が信頼できるとすれば、問題になるのは認証部分ですね。アカウント管理とかそういう部分の強化を⼆段階認証などでちゃんとしているかっていう。

⾅⽥　クラウドのセキュリティではアカウント管理もそうですが⼈的な問題もありますよね。

徳丸　アカウント管理は⼈と密接にむすびつくので、例えばみんながストレージサービスを使うなら使⽤者全員に訓練が必要になりますね。弊社でも認証の部分を特別に強化した上で使ったりします。

⾅⽥　S3はひとつ設定を間違えるとパブリックになりますから、社内のストレージとは違ってうっかりミスの取り返しがつかない。その情報をそこに置いていいのかという意識の問題もありますし。

細野　クラウドシフトによって、問題が境界防御から⼈がクローズアップされるようになりましたね。設定を間違えて漏れてしまうのは境界モデルの後遺症なんじゃないかと思います。場所のセキュリティから⼈のセキュリティへ移⾏し、とまどいが⽣じている。

⽥⼦　サービスの通信でサービス同⼠いろんな組み合わせがあります。そういった経路についてどう留意するべきでしょうか。

細野　経路だとVPNを張るっていうのもあると思うけど、クラウドをからめると経路制限はますます難しくなります。となるとやっぱり認証をどうやって守るかですね。我々としては認証や⼈に関してどういう注視をしていくかのソリューションになります。気をつけるところがないわけではないんですが、やりにくくなった感じはあります。

徳丸　過去にIoT基盤のコンサルをしたとき、それはクラウド上にさまざまなサーバなりサーバーレス環境なりを何かしら信⽤しないといけないシステムで。僕はもともとインターネット的な思考を持っていたので、証明書を⼊れて認証する⽅法を提案しました。HTTPSを使っていればサーバ間でIP側の通信は⼀応保証される。基本をちゃんとやればいい。 データセンターが使われていたときはDC内は平⽂で通信、⼀部は暗号化した⽅がいいという話はしたが、あまり暗号化していなかったんですね。でもクラウドはサーバ間でも基本的にHTTPSでやってくださいと。Googleは「メールもoverTLSにしましょうよ」って話をしていて、それは私も同意⾒です。インターネット活⽤って考えるとデフォルトTLSでいいんじゃないかと。盗聴よりも偽物を掴まされるリスクが⼤きいですし。

⽥⼦　⾝元の保証を、ということですね。

徳丸　はい。現実問題、国家規模ではなく⺠間レベルでファイバーの中を盗聴っていうのは普通はできないわけですが、いろんなテクニックで偽物をつかませることはできてしまう。サーバの認証は⼤事だと思います。

責任共有モデルが明確にしたもの

――セキュリティの責任範囲についてAWSは「責任共有モデル」というガイドを⽰しています。これを踏まえてユーザはAWSとどのような付き合い⽅を求められていると思いますか？

⾅⽥　AWSの責任共有モデルは「インフラはAWSが、その上のOS部分からはお客様が」というのを提⽰してお互いが安⼼できるようになるものです。いままではお客様が物理から全部⾯倒をみなくてはいけなかったものが、物理は保守対象外になった。範囲が明確になって利⽤者がやりやすくなったと思います。

徳丸　私は「AWSだから全部やってくれるでしょ」「安全なんでしょ」という変な誤解を解いてくれたのがよかったなと思っています。しっかり線引きして「ここからは利⽤者の責任範囲なんだよ」と⾔ってくれた。ただ、まだ多分この考え⽅を知らない⼈が多いので、そこはAWSや、同じようなモデルにしている他社クラウド側だけでなく私達も啓発していくべきだなと思っています。

⽥⼦　確かに、気にされるお客様は⾃分たちで情報を参照したりしていますが、気にしていないお客様にはあらかじめ啓発をしていかないと思います。なので、それをどうやって届けていくかすごく関⼼が⾼いです。

徳丸　どうやって……我々にとってはグサッと来ますね（笑）。というのも、ブログ等でセキュリティに関する情報を発信していて、よく読んでもらえる記事のアクセスは数万におよびますが、実際に読んでいるのはもともとセキュリティに関⼼が⾼い層の⼈たちなんです。そうでない⼈たちにどうやって届けていくかは私⾃⾝の課題でもあると思っています。 以前、とあるPaaS事業者のエンジニアのかたと話をしていて「御社のサービスだとPaaSだから⾃動でパッチ当ててくれるんですか？」と聞いたら「ええ、コンパネからボタン⼀発で当たります」と⾔われて「えっ、ボタンを押さなきゃいけないんだ」と思って（笑）。まあ確かにターミナルからコマンド打つよりは楽ですけど、ボタンを押すそのひと⼿間が……。だってWordPressでプラグインのパッチが当たってないことがたびたび問題になりますが、WordPressは管理画⾯を⾒れば「新バージョンが出ています」と警告が出るわけで、それでもやってないわけですよ。ボタン⼀発を怠ってしまう。

⾅⽥　AWSのマネージドサービスであれば、基板側であるAWS側が対応しますが、それに近いのはEC2とかDBとかでしょうか。IaaSとして提供している部分では、どうしてもインスタンス⼊れ替えてくださいとかAWSを再起動してくださいってことはあります。 ただ、AWSなんで今までよりやりやすくはなりました。ストップスタートも物理じゃないので設置場所に直接⾏かなくていいですしリソースも代替のモノ、物理的な資産を横に⽴てておく必要もない。AWSが最終判断できない部分でも⽐較的クラウドっていうプラットフォームだからやりやすいんですよね。

徳丸　やりやすいというのは⼤事です。難しいからやらない、やりやすいから促進されるっていうのは現実的にある。⼀⽅で「ボタンを押しましたか？」って聞くのも⼤事ではありますが（笑）。

細野　やりやすくなったよさと同時に、いままで「誰がどこまで責任を負うかが⾒えなかった」のが境界防御の出発点だったんだなと。いろんなことが整理されて、どこを⼼配すればいいのかが明確になった。昔とは違うんですよっていうところを、よくわからないんで怖いっていう⼈たちにアピールできると広まるんじゃないか。ここまでの話の流れから思ったのは、明確にする環境がお膳⽴てされたのもクラウドの側⾯だということですね。

ユーザーのあるべき姿

――ユーザー、システムのオーナーはどこまで責任を意識しておくべきだと思いますか？

⾅⽥　できれば全部考えてほしいですが（笑）。

徳丸　ははは（笑）。でもまさに本来はそうあるべきですよね。オーナーが責任を負うわけなので。難しくて厳しい道なんですが、⽬指すべきところだと思います。責任共有モデルに似ているんですけど、私がIaaS、Paas、SaaSで利⽤者はここに責任があるというモデルを描いたものが⼀部で好評で、IPAのドキュメントにも載りまして、あろうことかそれが情報処理安全確保⽀援⼠の試験に出て、さらにあろうことか私もそれを受けていたんですが。

⼀同　（笑）

徳丸　いまはAWS、IaaSを使おうとしている。基盤はAWSが⾯倒⾒てくれるけど、あとはこことここは⾃分たちで管理するっていうのをみんなが意識してくれればいいけど、なかなか進んでいないのが課題ですね。弊社もセキュリティに関⼼があるお客様からしか問い合わせが来ない。クラスメソッドのような企業のほうがより広くリーチできると思うので、啓発的な活動にも期待している。

⾅⽥　はい、ありがとうございます。

徳丸　以前、お客様への脆弱性診断の中で、これから構築するシステムのヒアリングをしていたことがあって。OS を確認して、そのパッチ適⽤は誰がしますかと質問したら先⽅が固まってしまったんですね。⾒たところそこをまったく考えていない様⼦だったんです。「それはシステム保守の業者がやると思っていた」はお客様の⾔い分で、逆に「パッチ適⽤は保守契約に含まれない」というシステムベンダー。これは本当に“あるある”で、⼊れてから⼀度もパッチが当たってないこともあった。これが現実です。いい加減なんとかしたい割と切実な問題。いまだにシェルショックやハートブリード（注︓いずれも過去に話題になった脆弱性）とかがある。責任共有モデルの裏返しで、「⾃分はここに責任があるんだ」という認識をしてもらうだけでもだいぶ違う。だから責任共有モデルは偉⼤だし、もっと広げたいですね。

組織としてセキュリティをどう扱うか

――セキュリティを担保してビジネスを展開していくにはどういった組織づくりがよいでしょうか。

徳丸　2つアプローチがありまして、ひとつはセキュリティの専⾨部隊を作るというのと、もうひとつは構築や保守のエンジニアがセキュリティのスキルを⾝につけるというものです。専⾨家がいてもいいですが、現場エンジニアのセキュリティの知識を上げるほうがいいと思います。セキュリティの素養があって、「このボタンを押さないといけない」というのがわかってないといけません。基盤側はかなり整ってきていますし、やっぱり⼈になっちゃいますし。

あと、パッチをなかなか当てられない理由には「当てたら動かなくなる」っていう不安がある。例えばStruts2というフレームワークで脆弱性が出た場合、システム保守を委託しているお客様からパッチ適⽤の依頼がきても、1週間かかりそうな試験が終わらないと当てられないと伝えて「我が社（お客様）が責任を持つから当ててくれ」という話があった。もちろん保守業者としてはサイト⽌めちゃいけないのはわかるので、私はクラウドの技術を使って「当てちゃいましょう」と⾔ったことがありました。ディスクイメージを取っておけば切り戻しは簡単にできますし。トータルコストは低いので、クラウドありきでのパッチ適⽤の⽅法も考えたほうがいいと思いました。

⽥⼦　アプリケーション開発を継続していくと、アップデートした段階でデグレードのリスクがあるけど、毎回すべてのテストを回すとどんどんコストが⾼くなってビジネスの要求に対応することが難しくなります。アプリケーションも切り戻しを容認して上げちゃう話も増えてきましたね。

徳丸　ああなるほど。そういう動きの中でパッチ適⽤もそれでいいじゃないかと。

⽥⼦　はい、レイヤーが違うだけの話なので、基盤としては問題が整ってきました。

徳丸　じゃあ、セキュリティ屋が遅れているんだ（笑）。

⼀同　（笑）

⾅⽥　クラウドが出て開発フローのサイクルが早くなれば、切り戻しも設計に合わせて都度考えていけます。それが できてないと、パッチ当てるまでの時間がかかって……。

徳丸　切り戻しも⼤変ですよね。下⼿したら「切り戻しの予⾏練習をしましょう」という話だって昔は実際にあったわけですし（笑）。それひとつとっても、すごいメリットで、クラウドの利便性はセキュリティにも効いてきますね。

⾅⽥　パッチ適⽤は場合によってはWAFで⼀時的にしのいでっていうのもありますよね。

徳丸　 ありますね。Strutsとか有名な脆弱性であればWAFのシグネイチャーがすぐ出ることもありますし。ざくっとWAFでとりあえずしのごう、みたい考えもありますが、そっちは危なっかしい。わかっていてやるならいいのですが。

明確な改善指標を提⽰する「インサイトウォッチ」

――クラスメソッドのセキュリティ診断ツール「インサイトウォッチ」とEGSSのセキュリティ⽀援サービスはそれぞれどう活⽤することでセキュリティを⾼めていけるのでしょうか。

⽥⼦　インサイトウォッチは、AWS利⽤をもっと便利にするヘルパー的なものとして始めた無料ツールです。企画開発を進めていく中で「構築やコンサルティングで困るのはセキュリティ」という声を聞くことが多かったので、そういったところに役⽴つようなツールとして今はAWSのセキュリティチェック機能を提供しています。現状ではCISのAWSベンチマークをベースとした監査を⾏い、AWS設定の診断ができるようになっています。 責任共有モデルで⾔えば、このツールがカバーするのは、ユーザが責任を持つ範囲のうちIAMや監視、それからインフラに絡むところで⾔えばVPCのセキュリティグループといったFW的な設定の部分です。 ⼀⽅でその上のアプリケーション部分はカバーできていないので、御社のような専⾨家や、別のツールの⼒が必要になってきます。

徳丸　AWSも⾮常に機能が豊富で巨⼤なシステムになったので、インサイトウォッチのようなものがあることはいいことだと思います。私⾃⾝は複雑なものを把握するっていうのは得意じゃないので（笑）、AWSのセキュリティがパッとわかるものがあると便利ですね。⾃分でAWSを使っていると不安になるときが来るんですよ。原理はわかっても「AWS上こうしなきゃいけない」ってわからないと思うので。 その上で、利⽤者側の責任を持たないといけないOSから上の部分ですと確かに弊社がお役に⽴てるのかなと思います。OS、アプリケーションの診断やWAFですね。

⽥⼦　技術ブログ「Developers.IO」で弊社の情シスがインサイトウォッチを適⽤してみたというインタビュー記事を公開したんですが、「現場担当者からは『これが正しいかどうかはわからない』っていう声がよく出る」という話があったんですね。パスワードのポリシーも何⽂字以上ならいいのか？と決めるのは難しい。 その点、インサイトウォッチは監査の基準としてアメリカの監査基準であるCISベンチマークを参照するので、現場はもちろん経営層に対しても説明がしやすいんですよね。安⼼のために必要な根拠付けをCISで安⼼してもらえる。CISなら解決⽅法を「こういうコマンドを叩いてください」レベルで具体的に教えてくれるので対応しやすいんです。

徳丸　投資をしているわけなので、それに対する報告は⼤事。⼤企業になればなるほど必要ですよね。それが楽に正確にできるのはメリットだと思います。CISの対策しやすさもすごく⼤きいですね。向こうの⼈は抽象的な考え⽅が得意なのか、けっこう漠然とした資料が多くて現場で使えない場合がある。具体的なところのブレイクダウンは運⽤上では⼤事です。

加算⽅式の脆弱性診断が招く弊害

⾅⽥　EGSSだと脆弱性診断、アプリ診断をやることがあると思うのですが、セキュリティの指標はどういったものがあるのでしょうか？

徳丸　そこはですね。徳丸が「⾼」「中」「低」ってランクを付ける感じで。

⼀同　（笑）

徳丸　もちろん指標はあって明⽰もできるのですが、（その出し⽅を）私⾃⾝があんまり信⽤していない。脆弱性についてどれほどのリスクがあるかを⾒積もること⾃体が我々の価値だと思っているんです。それをできるだけわかりやすく伝えるのが脆弱性診断の使命としています。

⾅⽥　出てきた結果をただ渡すのではなく、サービスやお客様の状態を⾒て判断する、ということでしょうか。

徳丸　その通りです。多くの同業他社はSQLインジェクションなら何点、クロスサイトスクリプティング（以下、XSS）だったら何点といった感じで決め撃ちの採点です。でも弊社はそうではなくて、このXSSならば実際の脅威としての影響は低いので「低」にしようとか、そういう判断を常にやっています。

細野　社内で、たとえばXSSが発⾒された場合、「実際に何ができてしまうのか？」というのを検証しています。我々が評価していただいているところはそこで、やはりお客様も決め打ちの脆弱性診断に対しては不信感を持っているんです。

徳丸　脆弱性診断で変な話っていっぱいあって、そのひとつは脆弱性診断対策というものです。例えば企業の監査で、それを乗り切るために社内で“監査対策”をやってしまっているというケースがあります。いま脆弱性診断にも近いことが起きていて、それはこの診断が普及したことによる負の側⾯でもあるのですが、私はいかがなものかと思っています。 なんでそんなことが起こるのかというと、危険度判定がおかしいからということになる。実害がないものに⾼危険度が付いていたりすると、実害がないのに対策に注⼒する脆弱性診断対策になっちゃうんです。「よくわからないからやりましょう」「脆弱性診断で良い点をもらいたいからやりましょう」というのは、無意味とまでは⾔わないけどちょっと寂しいですね。本質的じゃなくて英語⼒が付かないTOEIC対策なんかと同じですね。

⾅⽥　アプリだと「バグを100個みつけなさい」みたいな。

徳丸　ありますね（笑）。あらかじめバグを⼊れたりして「バグがなくてよかった」で突破しないといけないのにズルをしてしまうというのはよくないし無駄ですね。仕込んだバグを取り忘れたら本当のバグになってしまうのに。

⾅⽥　そういう、お客様で判断できないところは専⾨家にまかせてくれって感じですね。ツールから出た結果だけだとどうしようもない。

それぞれ最適なセキュリティ対策を

――セキュリティを負担にしないようにうまくやっていくには？

⽥⼦　今までの話にも出たように企業に専⾨家がいる状態は理想ですが、簡単ではありません。なのでセキュリティ基準を知り、とっかかりとして何が危険かをわかっていただくのがいいですね。AWSに関してはインサイトウォッチを使って、⾃分たちの状態やシステムの“体調”を把握してもらうことが第⼀歩かなと思います。

⾅⽥　そうやって状態を確認されたお客様からもう少し知りたいと⾔っていただいたり、AWSのセキュリティについて頼っていただけたらと思います。そしたらクラスメソッドはAWSの専⾨家として構成の改善案や設定などをコンサルティングしてお客様のセキュリティを⾼めていけるので。

細野　クラウド時代になって、誰が何をやったらいいのか整理されてきました。なので、お客様にもある程度セキュリティに詳しくなっていただたいけれど、1から10まで知っている社内セキュリティの専⾨家が必要という話ではなくなってきています。インサイトウォッチみたいなツールもありますし、弊社のような専⾨家を活⽤してもらえると負担のないセキュリティにつながると思います。

徳丸　セキュリティは、ぶっちゃけ難しいですよ。ただ、何をしなきゃいけないかはある程度決まっているはずなんで、そこを知っていただくことがまずあります。それで、サイトを企画する⽅は、基盤やウワモノの設定を⾏うと同時に、「ここは⾃分たちでやって、ここは任せる」っていうのを決めなきゃいけなくて、それを判断できるくらいはがんばって勉強していただけるといいと思います。そうなればインターネットは相当平和になるんじゃないかと思いますし、それが難しかったらEGSSのような専⾨家にご相談ください。そんなに⾼くないですよ（笑）。 今やサイバーセキュリティは経営課題ですが、まだまだ顧問弁護⼠のように外部の専⾨家に相談したり、定期的に監査を受けたりするというような状況にはなっていません。セキュリティの専⾨家に相談するハードルは決して⾼くありません。EGSSではお客様の課題に合わせて最適なご⽀援を提案していますので、脆弱性診断のご依頼はもちろん、どんな相談をすればよいかわからない、という場合でもぜひ⼀度気軽にご相談いただけたらと思います。

取材協力：EGセキュアソリューションズ株式会社
EGセキュアソリューションズは、増え続けるサーバーセキュリティの課題に対して、経験と実績に裏打ちされた本質的な解決策を提供することをミッションとし、脆弱性診断をはじめ教育やコンサルティング等の専⾨ソリューションを提供しています。

さいごに

クラスメソッドが提供する無料サービス「インサイトウォッチ（insightwatch）」は、ご利用中のAWSアカウントを無料でチェックし、 セキュリティのガイドラインに沿った運用なのか、数分で確認いただけます。今後もAWSを利用される方の環境がセキュアに保つための一助になればと考え、開発を続けています。今後ともどうぞよろしくお願いいたします。