今更聞けないセキュリティ用語の基礎知識 2025新春

Transcript

1. 今更聞けないセキュリティ用語の基礎知識 2025新春 2025.01.16 SATOSHI KANEYASU
2. 2 自己紹介 氏名：兼安 聡 所属：株式会社サーバーワークス アプリケーションサービス部 在住：広島（フルリモート） 担当：DevOps、技術支援、PM、SM 2024 Japan AWS Top Engineers (Database) 2024 Japan AWS All Certifications Engineers Certified ScrumMaster PMP X：@satoshi256kbyte
3. 3 本発表について ➢今更質問しづらいセキュリティ用語を解説していきます。 ➢よくあるWEBシステム開発とそのガントチャートをベースに話していったら、 いつ使うものか？というイメージが湧く気がするのでそのように話をしていきます。 ➢途中からAWSの用語が少しずつ増えるのでご了承ください。
4. 4 脅威と脆弱性とインシデント ➢脅威 ➢情報資産に損害を与える可能性のある存在や行為 ➢脆弱性 ➢運用ルールの弱点・欠陥・設定ミスなど、脅威の攻撃を受けやすくする要素 ➢インシデント ➢情報セキュリティ上の問題や事故 ➢例：情報漏えい ➢脅威：ハッカーが企業サーバーに不正アクセスを試みる／試みた形跡がある ➢脆弱性：サーバーのセキュリティパッチが適用されていない ➢インシデント：顧客情報が盗まれて漏えいした
5. 5 シフトレフト 工程／月 01 02 03 04 05 06 07 08 09 10 11 12 要件定義 基本設計 詳細設計 実装・単体テスト 結合テスト 総合テスト 受入テスト リリース ➢セキュリティ対策をガントチャート上の右側＝下流工程でやるのではなく、 左側＝上流工程から着手すること ➢セキュリティテストを総合テストあたりだけでなんとかするのは避けたい このあたりから セキュリティ対策を始める
6. 6 脅威分析 工程／月 01 02 03 04 05 06 07 08 09 10 11 12 要件定義 基本設計 ➢PJの初期段階で行う ➢攻撃者視点で潜在的な脅威と攻撃パターンを特定・評価 ➢フレームワークがある ➢STRIDE、PASTA、LINDDUNなど この辺り
7. 7 リスクアセスメント 工程／月 01 02 03 04 05 06 07 08 09 10 11 12 要件定義 基本設計 ➢PJの初期段階で行う ➢リスク全般（脅威＋脆弱性＋資産）の影響と発生確率を評価、リスクコストの算出 ➢脅威分析とリスクアセスメント相互補完関係 ➢これらの分析に基づいた対策を要件に盛り込み、基本設計以降に取り組んでいく この辺り
8. 8 OWASP Top 10 工程／月 01 02 03 04 05 06 07 08 09 10 11 12 要件定義 基本設計 ➢Webアプリケーションの代表的な脆弱性トップ10をまとめたリスト、毎年更新される ➢https://owasp.org/www-project-mobile-top-10/ ➢設計時に考慮すべきセキュリティ項目 ➢ 例: SQLインジェクション、セキュリティ設定ミス ➢仕組みで防げるものが多く、これらは要件としてあがっていなくてもWEBの常識として対策して おく必要があるので基本設計ぐらいで盛り込んでおくのがよいと思う この辺り
9. 9 ゼロトラスト ➢決して信用せず、常に検証せよ ➢ネットワークの境界を問わず、すべてのデバイスやユーザー、通信ネットワークを監視し、適切な レベルでセキュリティを確保すべきという考え方 ➢ファイアウォールがあるからといって、サーバーのOSパッチ適用を怠っていいとはならない ➢会社に鍵がかかっているからといって、机の上に重要書類を置きっぱなしでいいとはならない ➢ネットワークの「内側・外側」の区別は無意味であり、常に細かいレベルでアクセス制御と監視 を行うべき 工程／月 01 02 03 04 05 06 07 08 09 10 11 12 基本設計 詳細設計 実装・単体テスト この辺り
10. 10 DevSecOps 工程／月 01 02 03 04 05 06 07 08 09 10 11 12 基本設計 詳細設計 実装・単体テスト ➢開発（Dev）・運用（Ops）プロセスにセキュリティ（Sec）を組み込むアプローチ ➢本当は開発ライフサイクルの初期段階からセキュリティ対策を組み込むことで、脆弱性の早期 発見や対応コストの削減を図ること ➢実態としては、CI/CDにセキュリティチェックを組み込み、アプリケーションの実装とデプロイの流 れに自動のセキュリティチェックを入れることを指すことが多い この辺り＋リリース後の改修
11. 11 静的コード解析（SAST）、動的解析（DAST）、依存関係チェック（SCA） 工程／月 01 02 03 04 05 06 07 08 09 10 11 12 実装・単体テスト ➢いずれもCI/CDパイプラインの自動プロセスに組み込み可能 ➢動的解析(DAST)については、フルで行うと時間がかかりすぎる（数日かかる）ので、総合テ ストあたりで別途行い、CI/CDでは簡易チェックに留めるのが良いと思う 静的コード解析（SAST） 動的解析（DAST） 依存関係チェック（SCA） 対象 ソースコード 稼働中のアプリケーション ライブラリ・フレームワーク・依存モジュール 検出できる脆弱性 コーディングミス 設定ミス、認証・認可の不備、動作中の脆弱性 既知の脆弱性（CVE）、ライセンス違反 検出方法 ソースコードの静的解析 疑似攻撃を実施 使用中のライブラリや依存関係のチェック 代表的なツール SonarQube, CodeQL, Checkmarx OWASP ZAP, Burp Suite, AppScan Snyk, GitHub Dependabot, OWASP Dependency-Check この辺り＋リリース後の改修
12. 12 依存関係チェック（SCA）とSBOM ➢依存関係チェック（SCA）は、使用中のライブラリや依存関係のチェックを行う ➢チェックの結果で得られたシステムの依存関係を、国際的な標準規格で出力したものが SBOM（Software Bill of Materials） ➢SPDX（Software Package Data Exchange） ➢CycloneDX ➢SWID タグ（Software Identification タグ） ➢SBOMは、すでに一部の業界・国ではいつでも提出可能になることが求められている。 ➢医療業界では2024年の春に薬事法が改正、SBOMの記載が追記 ➢厚生労働省 - 医療機器の基本要件基準第12条第3項の適合性の確認について ➢SBOMは脆弱性データベースと突き合わせて使用中のライブラリに脆弱性がいないか調べるこ とが可能
13. 13 SBOMと脆弱性データベース ➢脆弱性データベースは、ソフトウェアやシステムの脆弱性情報を体系的に収集・整理し、一般 に公開するための情報プラットフォーム ➢OSSのツールやライブラリなどの脆弱性と発生するバージョン、対策の状況が記載されている ➢含まれる情報 ➢脆弱性の詳細情報（脆弱性の内容や影響範囲） ➢影響を受ける製品・バージョン（OSSや商用ソフトウェア） ➢脆弱性の深刻度（CVSSスコアなどで評価） ➢脆弱性識別番号（例：CVE-ID） ➢対策情報（パッチや回避策、アップデート情報） ➢公開日・更新日（脆弱性が発見・公開された日付）
14. 14 SBOMと脆弱性データベース データベース名 概要 主な対象範囲 NVD（National Vulnerability Database） アメリカ国立標準技術研究所 （NIST）が運営。CVE情報の詳細版。 OSS・商用ソフト全般 JVN（Japan Vulnerability Notes） IPAとJPCERT/CCが運営する日本の脆 弱性情報サイト。 OSS・商用ソフト全般 （日本寄り） CVE（Common Vulnerabilities and Exposures） MITREが管理。脆弱性を一意に識別す るための識別子（CVE-ID）を提供。 OSS・商用ソフト全般 GitHub Advisory Database GitHubが提供。OSSライブラリの脆弱 性情報と修正情報を掲載。 OSSライブラリ ➢SBOMと脆弱性データベースはツール・サービスで突き合わせることが可能 ➢Amazon Inspector、Trivy、yamory ➢例えばTrivyはSBOMとNVDを突き合わせてライブラリの脆弱性の有無をチェック可能
15. 15 脆弱性データベースの関係 ➢我々日本人がよく目にするのは、JVNだが、NVDもベースは同じなので大丈夫！ CVE 共通脆弱性識別子 NVD National Vulnerability Database アメリカ国立標準技術研究所(NIST) JVN Japan Vulnerability Notes JPCERT/CCとIPAが共同で運営 連携 連携
16. 16 セキュリティ診断／ペネトレーションテスト 工程／月 01 02 03 04 05 06 07 08 09 10 11 12 総合テスト 受入テスト リリース ➢システムに対し動的解析(DAST)などで擬似攻撃を行い、脆弱性の有無をチェックする ➢私見ですが、数日（それ以上の可能性あり）かかる上、高度なスキルと綿密な準備が求めら れるため、第三者機関に依頼するのがお勧めです。 ➢ペネトレーションテストは侵入テストだが、一緒くたになってセキュリティ診断という名前でサービス が展開されていることが多い印象 ➢これらのテストは擬似攻撃を用いるので、必ずサーバー管理者／クラウドベンダーへの事前 連絡が必要 この辺り
17. ここからAWSの用語が増えていきます
18. 18 WAF（Web Application Firewall） ➢脆弱性を悪用した攻撃からWebサイトを保護するセキュリティ対策ツール ➢WEBサーバーの前に置く ➢AWSの場合、AWS WAF ➢AWS WAFの場合、何を防ぐかのルール設定が必要で、これは定期的な見直しが必要 ➢開発の早い段階でAWS WAFを立ててしまうと、バグで動かないのか、WAFで弾かれてるの かわからなくなり調査が困難になり得るので要注意 工程／月 01 02 03 04 05 06 07 08 09 10 11 12 総合テスト 受入テスト リリース この辺りというかここから先
19. 19 設定監視／脆弱性検知／脅威検知 工程／月 01 02 03 04 05 06 07 08 09 10 11 12 総合テスト 受入テスト リリース この辺りというかここから先 分類 目的 AWS サービス 設定監視 リソース設定の変更検知・準拠監査 ポリシー違反を検出 AWS Config 脆弱性検知 OS・ソフトウェアの脆弱性の検出・修正 Amazon Inspector 脅威検知 リアルタイムの脅威検知・異常行動検出 Amazon GuardDuty AWS Security Hub これらを一元管理 ➢上2つは予防であり事前対策、事前・事後の対策を施して監視しるづけるのが大事
20. 20 Well-Architected Framework 工程／月 01 02 03 04 05 06 07 08 09 10 11 12 総合テスト 受入テスト リリース この辺りというかここから先 ➢クラウド上でワークロードを設計および実行するための主要な概念、設計原則、 アーキテクチャのベストプラクティスを集めたもの ➢AWS以外にもある ➢必ずしもこれに沿ってないといけないわけではないが、これと照らし合わせるこ とでシステムの弱点や改善点を見つけることができる ➢ベストプラクティス自体が時代とともに変化していくので、定期的に照らし合わ せることが必要
21. 21 まとめ ➢シフトレフト ➢脅威分析 ➢リスクアセスメント ➢ゼロトラスト ➢DevSecOps ➢静的コード解析（SAST） ➢動的解析（DAST） ➢依存関係チェック（SCA） ➢SBOM ➢脆弱性データベース ➢セキュリティ診断 ➢ペネトレーションテスト ➢WAF（Web Application Firewall） ➢設定監視 ➢脆弱性検知 ➢脅威検知 ➢Well-Architected Framework