課題に対する「予防的統制」と「発見的統制」

清野隼史氏(以下、清野):次のトピックにいきたいなと思います。先ほどのお話にもあったとおり、セキュリティ対策は本当に千差万別で、やれることもいろいろあって、「そもそも何からやっていけばいいか」というような、いろいろな課題があるのかなと思っています。

ここで、AWSさんが出しているものや、日々の経験の中のテクニックやプラクティスを、このタイミングでちょっと聞きたいなと思っています。こちらは勝原さんにお願いしてもよいですか?

勝原達也氏(以下、勝原):はい。(スライドを示して)こちらに投影しているのは非常に一般論な話で、ある意味きれいな世界の話をしています。

統制は代表的なものですよね。実際はもうちょっとありますが、ピックアップしてみると予防的統制と発見的統制というものがあるでしょう。

予防的統制は、「そもそもリスクが起きないように対策していこうよ」というもので、発見的統制は、「起きちゃったらすぐに気づいてダメージコントロールをして、ビジネスでのインパクトを可能な限り小さく抑えて鎮火させていこう」という話です。これらは1回作り込んで終わりではなくて、ちゃんとサイクルを回していかないと外的環境みたいなものは変わります。日々刻々とアクセスしてくる新しい手法が出てくるわけで、それに追従していき続けることも同時に大事なわけです。

みなさまもたぶん実感はそうかなと思っていると思うのですが、予防的統制は大好きだと思うんですよね。ガイドラインにも「これをやりましょう、入れなさい」と書いてあります。それによってリスクは取り去られます。取り去られると、「ともすればある意味見なくてもいい」みたいな方向に行きがちなんです。

だけどこれをやり過ぎると、がんじがらめになって気づくと過剰統制になっていて、「何かビジネスを立ち上げたいのに、例えばAWSサービスを使いたいのに中央の部門が、『このサービスは使いません』と言っていて説得するのが大変です」とか、そういう経験はあると思います。効果がけっこうわかりやすい分、制限が加わるので過剰統制になりやすいというか、なることに注意しなければいけないですね。

発見的統制は、逆にクラウドみたいな環境。オンプレミスだと、ログを集めるとか、何が起こっているのかを全部把握するのは一苦労だと思うのですが、クラウドでは情報を集めて可視化するところをサポートする機能はけっこうたくさんあります。

それを見ていけばいいのですが、見ていくということであれば、導入する時に環境の影響はそんなにないんですね。制約を加えたりするわけではなかったりするので、基本的にはそんなに影響がないです。ただ、可視性が高くなった、環境の影響が少ないから何か見始める。

ただ、何を見ればいいのかわからない、何の時に動けばいいのかわからない、どういうふうに継続的に回していけばいいかわからないみたいな話があるので、逆にこっちは運用へつなぐ難しさがあります。

運用についてはHowからでフィットする企業もある

勝原:(スライドを示して)セキュリティは運用につながっていないと効果を発揮しきれないので、運用というキーワードが意識されるのが右側ですね。こういった話があるのですが、「ではどうやってやっていけばいいの?」という時によく言われる話をここに書いています。

AWSとしてはAWS-Well-Architectedフレームワークというセキュリティの柱があります。これはさまざまなお客さまを支援してきた中のベストプラクティスですが、これである意味自分たちのシステムの健康診断ができます。「できているところはここ。できていないところはこれ」という色分けができます。

かたや業界標準のいろいろなフレームワークがあります。ISO27001やNISTのサイバーセキュリティフレームワーク、CIS Benchmark、PCI-DSSなどがあります。

一部AWSにテーラリングされているガイドラインはありますが、わりと一般的な情報システムという観点で書かれている場合が多いので、そのまま見て自分たちでどうすればいいのか、「細部でAWSで実装するにはどうすればいいの?」というところを決めるのにはけっこう苦労した経験があるんじゃないかということも同時に感じます。

最後は、専門家の経験に基づくプラクティスとして、手前みそですが「AWSアカウントで最初に作ったらやる10のこと」というスライドを2022年に更新して、セキュリティのビギナーズのサイトに上げていたりします。

あるいはAWSのSecurity Maturity Modelという成熟度モデルみたいなものも、もしかしたら参考になるものかもしれないなと思って公開していたりします。

こういったものは、どちらかというとハイレベルなところから「課題はこうである。だからだんだん落としていって細かいところでHowをどういうふうにするか」と、トップから落としていくアプローチとはやや対照的です。

取り組んでいるいろいろなお客さまの支援をしていると、「いろいろなビジネス、いろいろなシステム、いろいろなワークロードがあるけれど、まずはこれをやっておいたらいいんじゃないの?」というものが、ある程度ピックアップして見えてくる部分があります。

Howから入り過ぎるのはどうしても手段に偏るので良くない部分もあるのですが、「まずこれは」というものはあえてHowから入って、何に取り組めばいいのかをHowで並べて、「その理由はこうだからです」と示すといいと思います。

自分たちの組織に「どっちからいくのが合っているのか」を選ぶ時に、常にトップダウンである必要もなく、場合によってはHowからでフィットする会社さんもあります。なので、やり方はいろいろあっていいのですが、今日よりも明日をちゃんとセキュアにしていくという目的意識を持って使っていくことが大事なのではないかと感じています。

「AWS Security Hub」の利用はボトムアップの手っ取り早い現状確認の手法

臼田圭祐氏(以下、臼田):いいですか?

勝原:はい。

臼田:このあたりのフレームワークもいろいろあって、「どれからやったらいいんだ?」みたいなことがけっこうあるんですけど(笑)。

一方で、先ほど「トップダウンから」という話があったのですが、ボトムアップでやってもらうところで……。「最初にやるべきセキュリティ設定10のこと」の中にもたぶんあると思うのですが、AWS Security Hubを使ってもらうのは、めちゃくちゃ手っ取り早いボトムアップの現状の確認の手法だと思うんですね。

AWS Security Hubはいくつか機能があるのですが、メインで使っていく機能はとりあえずポチって有効化して、その中にいくつかのセキュリティチェックの項目があります。ぜひAWSセキュリティベストプラクティスのルールをチェックしてもらえればと思うのですが、それを有効化してもらうと、AWS環境ですでに出来上がっているものの中で、設定が緩いものを全部洗い出してくれるんですね。

例えば「セキュリティグループでSSHのポートが開いています」とか、「IAMユーザーのアクセスキーが作られていて、あまり使われていない」とか。そういうセキュリティ上、本当に具体的な設定レベル、リソースレベルの危ないものをあぶり出してくれるので、ボトムアップ的なところではまずSecurity Hubを使ってそういうものを洗い出して全部潰してくれるところからやってもらうと非常に良くて。

Security Hubを入れてもらうだけで、冗長が可視化できるんですよね。自分たちのAWS環境をちゃんと見ていなかったけど、「あ、この設定は緩くなっているんだ」みたいなところにすぐに気づけるんです。これはなかなかないことなんですよ。

今までのセキュリティ対策は、緩い場所に気づけるようなところはなくて、攻撃を受けてから気づくみたいなことが多いと思うんです。

AWSの環境など、最近だとクラウドではいわゆるCSPM(Cloud Security Posture Management)と言いますが、そういったものができるので、とりあえずSecurity Hubを有効化してほしいなと僕は常々言っています(笑)。

このタイミングで会場のみなさんにも聞いておきたいのですが、「Security Hubを有効化していますよ」という人がいたら挙手してください。

(会場挙手)

半分いるかいないかぐらいですかね。手を挙げていない方は、帰ったらすぐにSecurity Hubを使ってください。ボトムアップ的なアプローチなので、それをやった上で+αで、「そもそも、じゃあなんでSSHのポートが開いていたんだ?」みたいなところ。

なぜ・何(ということ)をやっていって「担当者が悪い」みたいな感じになっちゃうとアレですが、そうではなくて、セキュリティグループのSSHのポートを開けちゃっているということは、たぶん担当者の人がよくわからずにやっているとか、いろいろとやりくりしている中で一時的に開けたらそのままにしていたとか、いろいろな要因があると思うんですよね。

そういうところを、本当は組織の仕組みとしてカバーしていかないといけません。「セキュリティグループをそもそも使わないでできるようにSystems Manageを使いましょう」とか、「ポートを開けたとしてもすぐに閉じるようにしておきましょう」とか、いろいろな対策があると思います。

そういうことをやっていくために、こういうフレームワークを参考にして取り組んでいくといいのかなとバランス的には思います。どっちもやってもらったら良くて、とりあえず今は何をしたらいいかわからない場合には、Security Hubを有効化してください(笑)。

清野:ありがとうございます。一歩目としてまずはSecurity Hubを有効化してから、このあたりに取り組んでいこうというお話でしたね。ありがとうございます。

現場が権限をもらっておくことも大事

清野:こちらは佐竹さんにも聞いてみたいのですが、こういうプラクティスは1人でやれるものではなくて、やはり組織としてやっていくという話が一番大きいのかなと思っています。

佐竹さんは企業と一緒に伴走していくタイミングがあるんじゃないのかなと感じるんですが、プラクティスを導入するところを一緒にやっていくみたいな支援はあるんですか?

佐竹陽一氏(以下、佐竹):実際にあるんですが……。先ほど「運用が難しい」と話があったんですが、これもけっこう難しいです。これ(運用)がいきなり問題になるわけじゃないですよね?

清野:はい。

佐竹:現場の温度感が上げにくいということがけっこうあるので。私の最近の経験でいうと、勝手にやらせてもらえるように権限をある程度もらっておくのがいいかなと思います。

私みたいなリセラーの立場からすると、お客さんに「こうやったほうがいいですよ」と言っても、どうしてもやってもらえなかったりするので。なので、最近はお客さんと相談するのも、相談するのは後でいいので先に封じちゃって、その後「こんなことが起きていましたよ」というふうにしていったほうが、おそらく安全で速いんだろうなと強く思い始めているところです(笑)。

清野:ありがとうございます。ではある意味で突破力というか推進力というか。まず始めちゃうのがけっこう大事だったりするということですか。

佐竹:ちょっと言い方が悪いのですが、それで何か問題が起きた時に、リセラー、ベンダー、我々のせいにされやすい部分があるので、そういう視点でもやらせてほしいと思っているんですよね。他人事じゃないんですよというのもあります。

清野:なるほど。もう本当にそこをやることが、ただのアドバイスではなくて、自分たちの価値を……。

佐竹:自分の責任だと思って言っています。

清野:ありがとうございます。そうですね。今の話の中で、ベストプラクティスだったり、「その中で実際にどう使っていくんだろう」みたいな話もけっこういろいろと深く聞けたなと思っています。

(次回に続く)