Webセキュリティ対策例

本記事は SRE Advent Calaendar 2018 の18日目のエントリーです。

SREチームの責務として "セキュリティの強化" があげられますが、皆さんはどのような対策を実施していますか？

今回、私たちが新規オープンした Laig という家具プラットフォームサービスで実施したセキュリティ対策の内容を３点、簡単ではございますが紹介させていただきます。

構成

まず前提として、超ざっくりとした構成を。

• Infra
  • 全てAWS
• Frontend
  • Cloudfront+S3で静的ウェブサイトホスティング
  • SPAを採用
• Backend
  • ALB配下にWebAPIをオートスケールで設置
  • APIはCORSでアクセス元を制限

対策1：WAF

WAF(Web Application Firewall)とは、ウェブアプリケーションの脆弱性を悪用した攻撃からウェブアプリケーションを保護するセキュリティ対策の一つです。AWSにはAWS WAF マネージドルールと呼ばれる、セキュリティの専門家が作成/管理するWAFルールを簡単に適用できる仕組みがある為、そちらを利用させていただきました。
FrontendはCloudFront に、 BackendはALB に対して、それぞれ以下のマネージドルールを適用しています。

Frontend : Imperva – Managed Rules for IP Reputation on AWS WAF

静的サイトであるとはいえ、悪意ある攻撃元からのアクセスを未然に防ぐ為、IP制限ができないものに対してはImperva社のIPブラックリストのWAFを予防策として適用しています。

Backend : Fortinet Managed Rules for AWS WAF – Complete OWASP Top 10 RuleGroup

こちらが守護神的なもので、あらゆる攻撃をアプリケーションの前段で遮断してくれる事を期待して導入しています。
誤検知がないことを事前に確認する為、開発環境と本番環境で同様のルールを適用しています(本記事執筆時点で、WAFの誤検知によるブロック発生は0件でした)。

現在はBIG-IPでおなじみのF5社から同様のタイプのWAFが利用可能ですが、検討当初は存在しなかった為、Fortinet社のものを使い続けています。実際この２つの差はよくわからないので専門家による比較記事などがあれば参考にさせていただきたいところです。

対策２：セルフで脆弱性診断(失敗)

ツールを使った脆弱性の動的スキャン実施し、うまく動くようなら定期的にチェックさせようという目論見だったのですが、残念ながらSPAでは動的スキャンをうまく動作させることができませんでした。

ちなみに、AWSに対して脆弱性診断を実施する場合、事前に申請し承認を得ておく必要があります。
詳細はこちらをご参照ください → 侵入テスト

対策3：プロによる脆弱性診断

セキュリティのプロによる診断として、国際基準であるASVS(*1)やCVSS(*2)に準拠した脆弱性診断を対象サイトに対して実施していただきました。

*1 ASVS(Application Security Verification Standard) ：アプリケーションが満たすべき国際的なセキュリティ（脆弱性）診断水準
*2 CVSS(Common Vulnerability Scoring System) ：ベンダーに依存しない汎用的な脆弱性評価手法

どのような流れで実施したかについて以下に記します。

ヒアリング

こちらから、 対象サイトの概要、予算、要件 等の情報をお伝えし、
脆弱性診断業者(以下 業者)様から、 費用感、スケジュール、納品物、前提条件 等のヒアリングを行い業者を選定します。

診断計画

具体的な計画を立てます。

• 環境
  • 環境選定
    • 脆弱性診断実施のタイミングで本番環境は各方面により絶賛動作確認中につき、利用できない状況だった為、 診断対象として開発環境を解放 しました。
  • WAF設定
    • WAFが適用されている状況だと、アプリケーション本来の脆弱性を知ることができなくなる為、オフにした状態が推奨との事でした。とはいえ、せっかくの機会だしWAFの効果は知っておきたかった為、 WAF設定をBlockからCountにモード変更 しました。
  • データ準備
    • 対象の環境に対して業者様動作確認用ユーザの発行、商品データの準備等を行いました。
• 詳細計画・申し込み
  • 調査結果から、松竹梅のプランと見積もりを作成していただき、予算と希望に沿ったものに申し込みしました。

診断実施

実際に診断を実施します。

• 事前準備
  • AWSに侵入テスト申請を行います（内容は業者様から提示されました)。
• 診断中
  • 診断対象の把握
    • 診断する機能によっては、開発チームとデプロイスケジュール調整する必要があった為、今日はどこの機能を診断するなど事前にご連絡をいただくよう調整しました。
  • 速報
    • もし緊急性の高い脆弱性が検知された場合は、速報としてご連絡いただく事にしました。
  • モニタリング
    • 診断中のリソース状況をモニタリングします。
    • ちゃんとWAFが攻撃を検知していることが把握できました！

報告書受領

脆弱性の結果を報告書として受領します。
要素として、

• セキュリティ要素
  • 機密性(漏洩リスク
  • 完全性(改竄リスク
  • 可用性(サービス停止リスク
• システム要素
  • サーバ・ミドルウェア(ミドルウェアの問題
  • バックエンド(認証、入力フォーム、ロジックの問題
  • フロントエンド（フロント記述の問題

に関する採点と、
検知した脆弱性がレベル別(緊急 > 重要 > 警告 > 注意 > 情報)に報告書にまとめられておりました。

再診断の実施

今回業者様のオススメのプランとして、
報告書受領から1ヶ月間を質問可能な期間としてご用意 いただき、 検知した脆弱性の修正と、その結果確認の為の再診断１回を実施していただくプラン を選定していました。

報告書の内容から、対応すべき脆弱性をリストアップ、修正し、対策済みの脆弱性に対してのみ再診断を実施し、結果を確認しました。

対策3：プロによる脆弱性診断 は以上のような流れとなります。
スケジュールは ヒアリング〜診断計画までで約1ヶ月、診断実施〜再診断完了まで約1.5ヶ月、トータル2.5ヶ月程度で完了 しました。最優先タスクとして動いていなかった期間やプラン選定と稟議に時間がかかった面もあった為、もっと早く終えることも可能かと思われます。

プロによる脆弱性診断を終えた感想

やってよかった！と思いました。

プロによるASVS準拠の脆弱性試験を突破したということは大きな自信に繋がり、オープン前の不安が払拭されました。
正直、WAFなしでプロに試験してもらって もしボロボロだったらどうしよう。最悪リリース延期？？ のような一抹の不安もあったのですが、検知された脆弱性は全て警告レベル以下のもののみでした。 素直に 開発チームにお礼を言いたい です！あざーーーす！！

診断実施前は、検知されたとしてもWAFでブロックすればほとんど解決されるのでは？等と考えていたのですが、意外にも今回 検知された脆弱性はWAFでは防げないもののみ でした。

いくつか例をあげると、

• パスワードを繰り返し間違えた際にアカウントロックが作動しない
• パスワード変更時にセッションが無効化されないため、アカウント乗っ取りの危険がある
• セッションの有効期間が長い(管理画面にログイン後、15時間放置するテストを実施した模様
• レスポンスヘッダに ****** が存在しない

のようなもので、おそらく他にもいろいろと細かく確認してもらえていたのではないか？と思われます。

また、 再診断と質問期間があることもとてもありがたかった です。

セキュリティ対策用ヘッダの適用方法などは、報告書の詳細欄に対策方法の記載はあるものの、それだけではなかなか理解が難しいものが存在した為、具体的な対策方法について質問できるのはとても大きなメリットがありました。

あとがき

いかがでしたでしょうか？
今回はあくまで一例ではございますが、これからセキュリティ対策を検討している方の参考になれば幸いです。

最後まで読んでいただき、ありがとうございました！