【AWS Summit Tokyo 2017】AWS セキュリティアーキテクトが語る「クラウドセキュリティ指南」

アマゾン ウェブ サービス ジャパン セキュリティソリューションアーキテクト 桐山 隼人氏

「セキュリティ・オートメーションは戦略策定の礎であり、それを前提にAWSは設計された。むしろセキュリティ戦略の基盤としてAWSのクラウド環境は存在している」と、アマゾン ウェブ サービス ジャパン セキュリティソリューションアーキテクトの桐山 隼人氏は語る。AWS Summit Tokyo 2017のセッション「AWSで実現するセキュリティ・オートメーション」をレポートする。

なぜセキュリティをオートメーションするのか

数年前にオンプレミス環境からクラウド環境への移行に踏み切れない企業にアンケートしたところ、理由として一番挙げられた内容が「セキュリティ」だったと桐山氏。一方で同じ頃、米企業でクラウドへ移行した企業にその理由を尋ねたところ、こちらもまた「セキュリティ」を一番に挙げたそうだ。

「この調査結果は面白い。なぜなら、パブリッククラウドというものは、標準化されたITインフラ基盤をサービス化して均一に提供している。つまり、同じものを利用する前提にもかかわらず、まったく逆のイメージを抱いている結果となったからだ」(桐山氏)

もちろん、この話は日本を貶めているわけではなく「クラウドだからこそできるセキュリティというものを、認知してもらうことがAWSの使命だと考えている」(桐山氏)として、クラウドがいかにセキュアかの認知度がまだまだ足りない状況であると語った。

そして本題の「セキュリティ・オートメーション」だが、一口にセキュリティを自動化するという話ではピンとこない。そこで桐山氏が挙げたのはセールスフォース・オートメーションやマーケティング・オートメーションの事例だ。

どちらの自動化も、プロセスの効率化を図るためにSaaSを活用して営業活動の報告やナーチャリング手段の確立といったツールとしての活用が行われていた。しかし、このツールこそが後に革新を生み、報告データの分析で案件の確度判断ができるようになったり、案件化に至るリソースの最適化が可能となった。つまり、本来割くべきリソースを最適に分配できるようになり、自動化が効率化、そして「戦略」へと昇華したと桐山氏は説く。

これをセキュリティに適用するのが桐山氏の話すセキュリティ・オートメーションだが、前提としてガートナーが2014年に提唱した「適応型セキュリティアーキテクチャ」を、オートメーションの基本構造に用いる。これは、セキュリティが「防御」一辺倒だった時代から「侵入」が前提となる時代になる中で、PDCAサイクルをセキュリティのあるべき姿に沿った形で最適化したものだ。

「防御」と「検知」「対応」「予測」というサイクルを継続しつつ、継続的に監視・分析することでセキュリティシステムとしての最適化を進める。従来であれば固定化されたIT資産にこの考えは適用しづらかったが、クラウド環境であれば機能の組み換えはもちろんのこと、事業のスケールにあわせた「リソースの最適分配」も可能になる。

AWSの機能を組み合わせれば自前でセキュリティ機能を構築可能に

オートメーションを実現するAWSサービスはそれぞれの象限ごとに存在する。中には「オーバーラップしている機能もあるが、ここでは省略した」(桐山氏)

ここでAWSにおける「適応型セキュリティアーキテクチャ」の適用事例を桐山氏は紹介した。

例えばIPブラックリストをAWS WAFに自動反映する「オートメーション」では、CDNのCloudFrontでIP判別している中で、Lambdaを定期実行させて、SpamhausのDROPリストといったサードパーティのレピュテーションリストを自動取得する。Lambdaはこれを元に、AWS WAFのIPセットに更新をかけることでCloudFrontに到達したブラックIPの通信をブロックする。高価なWAFアプリケーションやオンプレ時代のように重厚長大なアプライアンスを導入していたことに比べれば、すべてAWSの機能で自前構築できるのはコストと時間の両面で大きいだろう。

また、オートメーションの中でも特に重要となるのが、侵入を許したあと、または内部犯行が発覚した際にその証跡を残すログ監視と分析だ。資産管理上、ガバナンスやコンプライアンスの観点、そして約1年後に施行が始まる欧州の個人情報保護法であるGDPRへの対策など、細かいログの取得と分析は企業にとって当然の対策となりつつある。(関連記事 : EUの個人情報保護法「GDPR」施行まであと1年、対応は「経営課題」)