第148回 雲勉 Web アプリケーション セキュリティ 1

Web アプリケーションのセキュリティ対策で、よく聞く質問 Amazon ECS を保護する方法がわからない。 ウイルス対策を実施したいけどどうしたら良いの？ ウイルス対策 WAF は入れたほうがいいの？ 定期的にアクセス数が跳ねるけど、WAF で防げる？ DoS / DDoS 対策 サーバーサイドの対策は十分に検討している。 個人情報を取り扱う EC サイトの対策は充足している？ 個人情報の漏洩対策 2

3 つの解決策 Amazon ECS を保護する方法がわからない。 ウイルス対策を実施したいけどどうしたら良いの？ ウイルス対策 WAF は入れたほうがいいの？ 定期的にアクセス数が跳ねるけど、WAF で防げる？ DoS / DDoS 対策 サーバーサイドの対策は十分に検討している。 個人情報を取り扱う EC サイトの対策は充足している？ 個人情報の漏洩対策 コンテナの特性と CNAPP (Cloud Native Application Protection Platform) アクセス負荷に対応するための選択肢 クライアントセキュリティ 3

自己紹介 4 なかむら まさと 中村 昌登 しろうさ ▼ 略歴 大学 航空宇宙工学で、航空機の制御や空力を勉強 新卒 大手企業の社内SE、セキュリティとシステムを担当 現職 iret で大手会社のセキュリティコンサル等を実施 ▼ 座右の銘 『好きこそものの上手なれ』 ▼ 得意なこと ユーザー管理、セキュリティマネジメント、犬と戯れる ▼ 趣味 Typescript / React / Redux / Serverless Framework 第001124号

ボーダーコリーの宣伝 ボーダーコリーのステラです！ 最高に可愛いので見てください！ 5

コンテナの特性と CNAPP 6

質問 従来の方式のウイルス対策などによるセキュリティ対策を、 コンテナ上でも実現することは出来るでしょうか？ 7

質問 従来の方式のウイルス対策などによるセキュリティ対策を、 コンテナ上でも実現することは出来るでしょうか？ 回答 対応することは可能だが、とても難しい。 今まで通りのウイルス対策ソフトを導入することは場合によっては可能。 しかし、多くの問題があって現実的ではない。 ● ブラックボックス化 OS から、コンテナ内のウイルスが見えない。 ● 対応 OS の問題 アンチウイルスソフトがコンテナ OS に対応していない。 ● ライフサイクル問題 コンテナの多くは、オンデマンドに増減する。 詳細は次のページ 8

コンテナ上のアプリは、コンテナアプリケーションによってブラックボックス化。 一般的には OS 上で動作するアンチウイルスソフトで、コンテナを保護することは出来ません。 (仮想化に対応したウイルス対策ソフトであれば可能です) ブラックボックス化 ホスト上のウイルス対策ソフトでは、コンテナ内はチェックできない 9

コンテナ内で動作する OS は、最低限の機能を有する軽量 OS が利用されます。 そのため、アンチウイルスソフトのサポートしない環境であることも考えられます。 ( そもそも、コンテナ内に アンチウイルスソフトを入れるのはメリットが低い ) 対応 OS の問題 コンテナで使用される OS は、最低機能の軽量 OS コンテナ環境のデファクトスタンダード Linux 環境のデファクトスタンダード 10

70% のコンテナは 5分未満の寿命しかありません。※1 レガシーなウイルス対策では、定義ファイルのダウンロードで管理サーバーに負荷がかかる。 大量に並列で処理させたいコンテナでは、個々のオーバーヘッドも無視できません。 ライフサイクル問題 コンテナの多くは、数分の寿命しかない ※1: Sysdig 2024年版クラウドネイティブセキュリティおよび利用状況レポート 11

コンテナに、セキュリティ対策は不要？ コンテナは、コンテナ特有のリスクがある 12

コンテナに対するセキュリティ対策 設定ミスを防ぐ コンテナ実行環境の設定ミスを防ぐ イメージを守る コンテナは同一のイメージを展開するため、イメージを保護する ドリフトを防ぐ イメージ展開後に差分が出ていないことを確認する 実行時保護 実行時の環境が不正な処理を実行していないことを確認する コンテナ固有のリスクに対応 13

AWS Security Hub を利用することで、AWS 環境の設定不備を管理できます。 AWS Security Hub では、『CIS AWS Foundations Benchmark』 などの 標準に基づきAWS Account 内の設定不備や、組織の設定不備を管理できます。 AWS Security Hub による Cloud Security Posture 管理 設定ミスを防ぐ AWS Security Hub 14 ※ KSPM (Kubernetes -) は Security Hub が対応していないため、OSS の kube-bench 等で対応が必要です。

Amazon Inspector を利用することで、Elastic Container Registory に保管されている コンテナイメージをスキャンして、ソフトウェアの脆弱性を検知することができます。 イメージを保護することで、Image の脆弱性を管理できます。 Amazon Inspector による Container Image のスキャン イメージを守る Amazon Inspector 15

Falco などの OSS 製品や、サードパーティ製品などを活用して、 コンテナのドリフトを検知、対応します。 OSS 製品等を活用しドリフト検知 ドリフトを防ぐ 16

Amazon GuardDuty Runtime Monitoring で、コンテナの実行環境監視が可能です。 サイドカーコンテナとして動作して、ファイルアクセス、プロセス実行等のイベントを 潜在的な脅威を監視して、検出することが可能です。 Amazon GuardDuty の Runtime Monitoring を用いて実行環境監視 実行時保護 17 ホストOS コンテナOS アプリケーション 実行中コンテナの監視 サイドカーコンテナからの監視 Amazon GuardDuty

この章のまとめ コンテナのリスクには、コンテナのためのセキュリティ対策が必要 OS 環境に対してウイルス対策を実施していたように、 コンテナ環境には、コンテナの特性に応じたセキュリティ対策が必要となります。 ウイルス対策製品はコンテナとの相性が良くないため、実行時保護が重要です。 18

アクセス負荷に対応するための選択肢 19

質問 Web アプリケーションが攻撃を受けて過負荷になっています。 どのようなソリューションで対応が適切でしょうか？ 20

質問 Web アプリケーションが攻撃を受けて過負荷になっています。 どのようなソリューションで対応が適切でしょうか？ 回答 AWS Shield / CloudFront / Auto Scaling / WAF / etc. Web アプリケーションの保護に WAF が必要というのは、広く認知されています。 しかし、WAF 以外のソリューションが適切なことも多いです。 ● AWS Shield による、AWS ネットワーク入口での攻撃遮断 ● CloudFront による、コンテンツキャッシング ● WAF による、レートベースブロック ● Auto Scaling による、負荷分散の実施 21

DDoS / DoS 攻撃。 (Denial of Sustainability Attack) 提供者のサービスを停止させることが目的。 サービスを停止 金銭的な攻撃 サービスの相乗り 脆弱性の悪用 EDoS 攻撃。 (Economic Denial of Sustainability Attack) 提供者に対して、過剰な課金を発生させることが目的。 コンテンツの相乗り。 (直リンク等) 攻撃者のサイト上のコンテンツを、被害者のサイトからユーザーに配信。 Web サイトの脆弱性を悪用。 (SQL Injection 等) 提供者サイトの脆弱性を悪用して、情報を詐取することが目的。 宣伝、バズ、サービスリリース、アップデートなど。 正規の顧客の大量流入による過負荷。 正規の流入 大量のアクセス = DoS ではない 大量アクセスの目的って何？ 22

DDoS / DoS 攻撃。 (Denial of Sustainability Attack) 提供者のサービスを停止させることが目的。 サービスを停止 金銭的な攻撃 サービスの相乗り 脆弱性の悪用 EDoS 攻撃。 (Economic Denial of Sustainability Attack) 提供者に対して、過剰な課金を発生させることが目的。 コンテンツの相乗り。 (直リンク等) 攻撃者のサイト上のコンテンツを、被害者のサイトからユーザーに配信。 Web サイトの脆弱性を悪用。 (SQL Injection 等) 提供者サイトの脆弱性を悪用して、情報を詐取することが目的。 宣伝、バズ、サービスリリース、アップデートなど。 正規の顧客の大量流入による過負荷。 正規の流入 大量のアクセス = DoS ではない 大量アクセスの目的って何？ 多様な攻撃を、一つのサービスで防ぐことは不可能 23

AWS Shield による、入口での攻撃遮断 DDoS 攻撃に対する対応は、AWS のネットワークに入る前での対策が必要です。 Shield Standard は、全ての AWS 環境を保護していて、自動的に保護しています。 お客様固有の DDoS 保護や高度な DDoS 保護は、Shield Advanced で可能。 SYN flood / DNS Query flood のような DDoS 対策はコレ！ AWS Shield ISP-a ISP-b AWS AWS Account AWS Account Shield Standard はこのレイヤーの保護 24

CloudFront による、コンテンツキャッシング 静的サイトの大規模アクセス保護は、CloudFront によるコンテンツキャッシュが有効。 数分程度のキャッシュでも、DoS のような大規模なアクセスには効果があります。 短時間の大規模アクセス対策はコレ！ Amazon CloudFront ISP-a ISP-b AWS Edge Location Edge Location AWS Account Amazon CloudFront はこのレイヤーの保護 25

WAF による、レートベースブロック 過剰なアクセスを含めた、Web Application に対する攻撃は AWS WAF が有効。 レートベースの保護を行えば、単位時間当たりのアクセス数でブロック可能。 他にも、SQL Injection などに対応するルールを利用することも可能です。 Web Application に対する攻撃を防ぐにはコレ！ AWS WAF ISP AWS Edge Location CloudFront は Edge Location で、Application Load Balancer は Region で保護。 26 AWS Account

Auto Scaling による、負荷分散の実施 サービスの可用性を向上させるためには Auto Scaling が重要です。 対策をしても、負荷はある程度バックエンドに到達します。 負荷的には EC2 1台で十分なサービスでも、可用性には Auto Scaling が重要です。 可用性を向上し、サービスの停止を防ぐにはコレ！ AWS Auto Scaling ISP-a ISP-b AWS AWS Account ⋯ AWS Auto Scaling はこのレイヤーの保護 27

多様な攻撃に対応するため、複数サービスの組み合わせを推奨 この章のまとめ 『Web Application に対する攻撃 = WAF を入れて解決』という誤解は意外に多いです。 しかし、過剰なアクセスに対して、WAF で解決することは、とても難しいです。 一つのサービスで解決せず、複数のサービスを組み合わせて、過剰なアクセスに対応したい。 AWS Shield による、入口での攻撃遮断 CloudFront による、コンテンツキャッシング WAF による、レートベースブロック Auto Scaling による、負荷分散の実施 28

クライアントセキュリティ 29

質問 AWS の対策や、サーバーの対策は完璧です。 個人情報漏えい対策は十分ですか？ 30

質問 AWS の対策や、サーバーの対策は完璧です。 個人情報漏えい対策は十分ですか？ 回答 セキュリティヘッダーによるブラウザ側の保護を行ってください。 ブラウザからの情報漏えいインシデントが後をたちません。 (e.g. 2024年 10月 タリーズコーヒー) 徳丸 浩 氏いわく 、『2018年以降のカード情報漏洩で、蓄積されたカード情報が 漏洩したケースは無いとのこと』とのことです。 ● CloudFront に Security Header Policy を追加 ● Content Security Policy (CSP) の追加 31

セキュリティヘッダーってなに？ ブラウザに対して、セキュリティ動作を指示するヘッダー Strict-Transport-Security HTTPS 要求 X-Content-Type-Options MIME スニッフィング対策 X-Frame-Options フレーム要求 Content-Security-Policy コンテンツセキュリティ HTML ページリクエスト ブラウザのセキュリティ動作を指示 ブラウザのセキュリティ動作を実施 etc. リソースの送受信、セキュリティ動作が強制 ブラウザセキュリティを実現 32

開発者の意識向上、 組織のセキュリティガバナンスにより、 サーバーサイドは対策が進んでいる。 攻撃者から見ると、対策が進んでいない ブラウザ側を狙う攻撃が増えている。 ブラウザ側の不正な動作によって 個人情報を詐取する被害が発生している。 そのため、セキュリティヘッダで ブラウザ側を保護することが必要。 XSS 不正な Script フィッシング クライアントサイドは 対策が進んでいない なぜ、ブラウザを保護する必要があるの？ サーバー側は堅牢化が進んでおり、ブラウザが標的にされている SQL Injection Command Injection 脆弱性悪用 サーバーサイドは 対策が進む 33

CloudFront でセキュリティヘッダーを設定 CloudFront を利用している場合、ポリシーのセキュリティヘッダーオプションから 簡単にセキュリティヘッダーを適用できます。 今回の雲勉では、 Content-Security-Policy を説明します。 簡易にセキュリティヘッダーを適用できる Amazon CloudFront 34

Content Security Policy (CSP) CSP は、超強力なブラウザセキュリティ機能 Content-Security-Policy: ; ; script-src Script の提供元と、XSS などで悪用されるインラインコードを制限する。 connect-src 通信の接続先を信頼できるサイトに制限する。 form-action Form のデータ送信先を信頼できるサイトに制限する。 child-src Frame 内の提供元を信頼できるサイトに制限する。 sandbox Frame 内の動作を信頼できる動作に制限する。 35 しろうさ厳選の 5 つを紹介します、すべてを知りたい人は mdn web docs のサイトを参照

script-src; Script の実行を制限 36 Script の提供先を、自身のサイトや信頼できる CDN に制限 script-src 'self' https://example.com/ 'sha256-XXXXX'; XSS XSS など、HTML 内に悪意あるコードを挿入し、実行する攻撃に対応。 ● デフォルトで、eval などの脆弱なコードは実行不可能になる。 ● XSS を受けても、被害が発生しなくなる。 Script タグ 改ざん スクリプト 改ざん HTML を改ざんし、悪意あるサイトから を読み込む攻撃に対応。 ● 自身 (self) や、信頼できる CDN (URL) を指定する。 ● 明示的に許可されないサイトは、Script を受信できなくなる。 信頼できるサイトの Script を改ざんして、悪意ある動作を実行する攻撃に対応。 ● Inline Script や 外部 Script (CSP 3.0) の Hash 値を指定する。 ● Hash 値が一致しない Script は実行ができなくなる。

connect-src; 通信の接続先を制限 37 Fetch や XHR の通信先を、自身や信頼できる API に制限 script-src 'self' https://example.com/ https:; 個人情報 漏えい 攻撃者の用意したサイトに対して、JavaScript で個人情報を送信する攻撃に対応。 ● 自身 (self) や、信頼できる API (URL) 、プロトコル (https:) を指定する。 ● 明示的に許可されないサイトは、通信を開くことができなくなる。 DDoS 不正な Beacon サイト訪問者を、ターゲットサイトに対する DDoS に加担させる攻撃に対応。 ● 明示的に許可のない第三者サイトに対して通信ができなくなる。 ● POST 通信も含めて、DDoS 通信を送信できなくなる。 サイト訪問者の情報を、C&C サーバーに対して送信する攻撃に対応。 ● や Navigator.sendBeacon() も、connect-src で制御可能。 ● 信頼できない通信先に対して、Beacon を送信できなくなる。

form-action; Form の接続先を制限 38 タグの action としてデータの通信先を制限 form-action 'self' https://example.com/; 個人情報 漏えい を書き換え、個人情報を漏洩させる攻撃に対応。 ● 自身 (self) や、信頼できる API (URL) を指定する。 ● 明示的に許可されないサイトは、フォームの値を送信できなくなる。 XSS に、悪意ある JavaScript を入力して、実行する攻撃に対応。 ● 'none' を指定する場合、全ての form action が禁止される。 ● Inline JavaScript を含め、すべての動作が禁止になる。

child-src; Frame の提供元を制限 39 フレームなどの提供元を信頼できるサイトに制限 child-src 'self' https://example.com/; Script タグ 改ざん Web Worker として悪意あるサイトを読み込み、実行する攻撃に対応。 ● new Worker() に対しても、child-src で対応が可能。 ● 明示的に許可のないスクリプトは、Worker として動作できない。 アドウェア 悪意あるサイトを、広告等を通してフレーム内に表示する攻撃に対応。 ● 明示的に許可のないサイトはフレーム内に表示できなくなる。 クリック ジャッキング をサイト上に透明状態で表示し、ユーザーにクリックさせる攻撃に対応。 ● 自身 (self) や、信頼できるサイト (URL) を指定する。 ● 明示的な許可のない SNS などは、フレーム内で表示できなくなる。

sandbox; Frame 内の動作を制限 40 フレーム内の動作を、信頼できる動作に制限 sandbox; OR sandbox allow-downloads; 明示的許可 この指定は特殊で、許可したい値を列挙します。(Download / Script / Popup / etc.) 明示的に許可されない動作は、全て拒否されます。 安全な フレーム sandbox のみを指定した場合、 内で最も安全な状態となります。 セキュリティに影響を与えるような動作は、全て拒否されます。

クライアントを保護することは、サーバーの保護と同様に重要 この章のまとめ クライアントの保護は、サーバーの保護と比較して対応が進んでいません。 ブラウザは、Content Security Policy として強力な保護機能を提供しています。 ブラウザを保護して個人情報漏えいに備えることが求められています。 41 Web App 脆弱性診断 CSPM / KSPM ワークロードセキュリティ セキュリティヘッダー Content Security Policy

まとめ 42

Web Application に求められる対策について見てきました。 3 つの解決策 Amazon ECS を保護する方法がわからない。 ウイルス対策を実施したいけどどうしたら良いの？ ウイルス対策 WAF は入れたほうがいいの？ 定期的にアクセス数が跳ねるけど、WAF で防げる？ DoS / DDoS 対策 サーバーサイドの対策は十分に検討している。 個人情報を取り扱う EC サイトの対策は充足している？ 個人情報の漏洩対策 コンテナのリスクには、コンテナのためのセキュリティ対策が必要 多様な攻撃に対応するため、複数サービスの組み合わせを推奨 クライアントを保護することは、サーバーの保護と同様に重要 43

Web Application のセキュリティ対策 44 多くのサービスが SaaS 化され、 Web Application に求められるセキュリティ対策は高度化しています。 コンテナ化などの環境の変化 対策の難しい DDoS 攻撃の高度化 クライアントに対するセキュリティ対応 今回ご紹介した内容などを参考に、対策を検討してください 。

45 Web Application セキュリティもアイレットにおまかせください