第10回のSecurity JAWSでは、クラスメソッドとNetskopeからAWSを安心して使うための2つのツールが紹介された。また、リクルートテクノロジーズはユーザー企業の立場からAWS WAFの検証について知見を披露した。
安心してAWSを使うために、チェックツールを用いて「うっかりミス」の発見を
クラスメソッドの田子昌行氏（AWS事業本部 プロダクトグループ）は、「小さな発見を大きな安心に～insightwatchのご紹介～」と題し、AWSのセキュリティをチェックする「insightwatch」を紹介した。「AWSのユーザーが増えているが、それと同時に『どういうセキュリティ対策をすれば良いか分からない』『ベンダーに任せているけれど、これでいいか分からない』『複数のAWSアカウントにまたがって状況を確認するのが難しい』といった困った声を耳にしている。これまで培ってきたノウハウを生かして何かできないかと考え、作ったものの1つがinsightwatchだ」と田子氏は紹介する。
クラスメソッド 田子昌行氏
insightwatchは5月21日にリリースされたばかりだ。AWSの責任共有モデルを前提に、CISベンチマーク Ver 1.1.0に沿ってIAMやロギング関連の設定など全52項目を調査し、その結果をWebインターフェイス上に表示するができ、「誰でも簡単に、無料でAWSの環境がベストプラクティスに沿って構築されているかを調べるWebサービスだ」と田子氏は述べた。発覚した問題をどのように修正すべきかという設定ガイドも提供されるほか、複数のアカウントに対する一括チェックも可能だ。
たびたび報道されているように、S3バケットに保存した重要なデータが公開されていたり、担当者がプロジェクトを外れていた後もIAMユーザーが残っているといったリスクが残っていると、ビジネスの根幹をゆるがす事態になる恐れがある。田子氏はそうした状況を説明し、「AWSにどんどん新しいサービスが追加されていることは素晴らしいが、反面、使い方を誤るとセキュリティ上のリスクにつながる恐れがある。責任共有モデルの上に載せるアプリについては、ユーザー自身がきちんと管理していく必要がある」と指摘した。
そして、簡単に使えるinsightwatchのようなツールを一度きりではなく定期的に活用し、継続的にセキュリティを確認してほしいと述べた。「日々の小さな発見とそれに対する適切な対応が、事故の発生を防止し、大きな安心につながる」（田子氏）
続けてNetskope Japanの橋本一文氏が「設定の誤りや外部脅威を防御するNetskopeのAWSセキュリティ自動化」と題するセッションを行ない、CASBならびにセキュリティチェックを実施する製品「Netskope」を紹介した。こちらもinsightwatch同様、責任共有モデルを前提にIaaS特有のセキュリティ問題をチェックするもので、CISガイドラインに沿って、各種設定や脆弱性の有無をAPI経由で確認し、修正方法とともに表示するものだ。
Netskope Japan 橋本一文氏
「IaaSでは、あまり深く考えずに禁止されているはずの仮想マシンをデプロイしてしまったり、誤設定など単純な設定ミスに起因するセキュリティ問題が多い」と指摘する橋本氏。この製品ではAWSも含め複数のクラウドサービスに対してチェックを行ない、ルール違反を検知する。
特徴は、リアルタイムスキャンだけでなく非リアルタイムでも、またIaaSに限らずさまざまなSaaSに対しても、同一のポリシーでチェックが行なえることだ。またアノマリー検知によって、「普段と異なる振る舞い」も検出できる点もユニーク。「『S3からファイルをダウンロードし、2時間以内にGoogle Driveにアップロードした』といった不審な動きを可視化できる」（橋本氏）という。また、S3内のコンテンツGDPRに抵触するような個人情報や機密情報が含まれていないかをチェックするDLPスキャン機能も備えている。
「『何が起きたか分からないうちに漏れている』というのが一番怖い。だが、記録さえあれば、追跡することもできる」と橋本氏は述べ、クラウドを安心して利用していくには、いつ、どこで、誰が、どのサービスで、何をやったのかを記録し、可視化していくことが重要だとした。
オンプレミスのWAFとクラウドWAF、運用面も含めた比較検証の結果は？
次はユーザー側からの視点のセッションとなった。外部任せではなく自社でセキュアなエンジニアリングからセキュリティ監視、インシデントレスポンスに至るまで、さまざまな対策に取り組んでいる「Recruit-CSIRT」に所属するリクルートテクノロジーズの徳田聡介氏と安東美穂氏が「ほんとうに大事なサービスを守れるのか！？実運用に向けてAWS WAFを検討してみた」と題するプレゼンテーションを行なった。
リクルートテクノロジーズではこれまでオンプレミス環境でインフラを構築してきたが、「時代の流れもあり、クラウドを活用したアプリ開発も増えてきた。特にAWSを使った開発が広まっているが、そのセキュリティをどうするかが課題になってきた」（徳田氏）ことから、AWS WAFの検証作業を行なった。
リクルートテクノロジーズ 徳田聡介氏
AWS WAFでは、AWSやベンダーが提供する「マネージドルール」のほか、「カスタムルール」を用いて攻撃を検知できる。Recruit-CSIRTでは、攻撃系と正常系、2つのデータセットを用意し、8種類のマネージドルールとカスタムルールを用いて、「どの程度攻撃を検知できるか」と同時に「過検知がどの程度あるか」を検証。さらに、運用に備えて仕様や構築手順もチェックした。結果として、ルール設定時にリクエストのデコード方法を正しく設定しないときちんと検知できない、という落とし穴はあったものの、「個人的には、総評としてはなかなかよいと感じた。きちんと攻撃をブロックできるし、誤検知も少ない。一部のベンダーのマネージドルールは非常によかったし、カスタムルールも想像以上によかった」と徳田氏は振り返る。
一方で、実運用をにらむと、いくつかの課題も見えてきたそうだ。1つは、やはりWAFにはつきものの「誤遮断」だ。「特定のSQL関数やSQL構文があると遮断されることがわかった。こういった要素がリクエストに入る環境には適さない場合もあるため、事前検証は必須だと思う」と安東氏は指摘する。
リクルートテクノロジーズ 安東美穂氏
2つ目はルールのチューニングに関してだ。「コンディショニングの設定は『リクエストのどこを見て、それらをどう処理するか』というとてもシンプルなもので、中身が分からない。誤遮断や誤検知があって、特定のURLを除外したいと思ってもその設定が難しい」（安東氏）。
そして最後は、検知ログの扱いだ。「ダッシュボードでは、どんなURLで何件検知したかを確認できるが、あくまで一部が抽出される仕様で、すべてが見られるわけではない。しかも、ログが保存される期間は3時間となっていて、それ以上過去に遡って調査したくてもできない。もっと詳しく調べたい場合には工夫が必要だ」（安東氏）。
一方で、これまでオンプレミスでWAFを導入する際には、調達からポリシー設定、検証、チューニング、そのアップデート・保守……といった煩雑なプロセスが必要で、時間もかかっていたが、AWS WAFではそれらの手間が省ける。「非常に簡単に、コンソールでぽちぽち入力するだけで有効にできることは評価できる」と安東氏。その限界を踏まえた上で、「PCI DSS準拠」や、脆弱性が分かっているアプリに対する特定のリクエストの遮断、あるいは動的なファイアウォールとして利用するといった、AWS WAFに適したユースケースが考えられると述べ、さらなる活用に向けて情報交換したいと述べた。
