設計・開発・テストにおけるセキュリティの実践と考え方を知ろう - 広島ミニキャンプ
3.6K Views
October 25, 25
スライド概要
セキュリティ・キャンプ ミニ 広島ではなしたもの。
関連スライド
各ページのテキスト
セキュリティ・キャンプ ミニ 広島 2025 バージョン 設計・開発・テストにおける セキュリティの実践と考え方を知ろう Azara / Norihide SAITO (@a_zara_n) https://x.com/a_zara_n https://github.com/a-zara-n 🔗 https://misc.azara.jp
どうも、Azara です 2/86
今回の講師です 3/86
みなさんと同じく学生の時に セキュリティ・キャンプに参加しました (ミニにも) 4/86
大体 8 年前の話です 5/86
社会人は 5 年目の 28 歳になりました 6/86
当時は B トラック (現プロダクトセキュリティクラス)で Web アプリケーションやプロダクトの セキュリティを学んでいました 7/86
いまは GMO Flatt Security という会社に所属をしています 8/86
開発者や開発組織の 背中を預かる仕事をしています セキュリティの力で最高なプロダクトを守って、課題解決を支援しています 9/86
10/86
普段はクラウドと Web とセキュリティが大好 きで、もそもそと活動しています 11/86
12/86
13/86
設計・開発・テストにおけるセキュリティの実践と考え方を知ろう by @a-zara-n 14/86
AWS セキュリティの全体像を理解しよう - 初学者が知るべき脅威と対策 by @a-zara-n 15/86
え、私のFlagまるみえ!? クラウド問題やインフラにおける題設計ミスにみるクラウドセキュリティ(入門) - 魔女のお茶会 #7 お ふらいん! (2025冬) by @a-zara-n 16/86
● セキュリティ・キャンプ などの人材育成事業で講師や運営として従事 ● 国内の AWS コミュニティである JAWSの各種ユーザーグループやイベントででセキュリティに関する講演やワークショップ を実施 ● CloudSec JP の立ち上げ ● JSAC や CODEBLUE、BSides Lasvegas など国内外のカンファレンスで講演活動 ● AWS Community builder のセキュリティカテゴリに選出(2025) ● GMO インターネットグループのクラウドセキュリティエキスパートに選出(2025) 17/86
好きなクラウドは AWS 好きなサービスは Cognito と IAM の ファミリーサービスです 18/86
好きな言語は Go と TypeScript、Kotlin です 嫌いな言語はありません。時と場合によって使い分けます 19/86
最近は LLM の進化ってすげーと思いながら、 LLM が弱い部分を補うための MCP Server を TS で書いてます 20/86
そんな人間です 21/86
今回の講義では セキュリティ・キャンプ全国大会で話した内容 を少し手直しして プロダクトセキュリティの 実践的な話をします 22/86
多分偉そうなこと言いますが ゆるしてください！ 23/86
セキュリティ・キャンプ ミニ 広島 2025 バージョン 手を動かしながら学ぶ B to C プロダクトセキュリティ入門 1. 現代的なプロダクトの開発ってどんな感じ？ 2. プロダクトセキュリティの基本的な考え方と実践 3. BtoC プロダクトにおけるセキュリティ設計のポイント 4. ハンズオン 5. まとめ
現代的なプロダクトの開発ってどんな感じ？ プロダクトセキュリティの基本的な考え方と実践 BtoC プロダクトにおけるセキュリティ設計のポイント ハンズオン まとめ 1 - 現代的なプロダクトの開発ってどんな感じ？ システムが部品化し、クラウドネイティブ化している世界 開発・設計・テスト・インフラはどう変化しているのか？ 本トピックについて 1 過去と現在と未来（予想）における開発 2 過去における課題と現在の解決策 3 なぜ部品化・クラウドネイティブ化が進んだのか 4 LLM の登場と今後の展望
0 従来と現在と未来における開発 - 全体像 開発スタイルの変遷を理解することで、現代のセキュリティ要件を把握できるので、はじめに全体像を見ていきましょ う。 💡 従来 - 事前に準備/分業 💡 現在 - シームレスな連携 💡 未来 - 本質への向き合い ● 開発スタイル： 建築と似ており、 ● 開発スタイル： アジャイル・スクラ ● 開発スタイル： AI 支援開発が主流 要件を定義し、設計図を作成し、順 ムといった開発やチューニングされ になり、要件定義からコード生成、 序立てて構築していくウォーターフ たアジャイル型が主流 テスト、デプロイまで AI が支援 ォール型が主流 ● 職責： エンジニアも専門知識を持 ● 職責： AI がコード生成やテストを ● 職責： 分業体制を敷き、フロント っているエンジニアもいれば、 ジェ 自動化することで、エンジニアは設 エンド、バックエンド、インフラ、 ネラリスト的に幅広く対応できるエ 計や監督、クリエイティブな部分に セキュリティ、テスト、要件定義、 ンジニアもいる 集中 設計、運用といった各フェーズや強 ● DevOps や DevSecOps といっ ● システム： AI 最適化されたアーキ みごとに担当が分かれている た開発と運用、セキュリティの垣 テクチャが登場し、自己修復や自動 ● システム： 一枚岩のモノリシックア 根を越えたチーム編成が一般的に 最適化が可能に ーキテクチャが主流であり、オンプ なっています。 レミスの物理サーバーにデプロイさ ● システム： マイクロサービスアーキ れている テクチャが主流であり、クラウドプ ラットフォーム上にデプロイされて いる 26/86
1 過去の開発 (2000 年代前半) - モノリシック時代 大規模な一枚岩アプリケーションによる開発が主流だった時代 アーキテクチャの特徴 注釈: モノリシックとは ● 単一の大規模アプリケーション モノリシックアーキテクチャは、すべての機能が単一のコードベースに ● すべての機能が 1 つのコードベースに集約 統合されたアプリケーションの設計スタイルです。このアプローチで は、フロントエンド、バックエンド、データベースが密結合しており、 ● データベースも単一の巨大 DB 1 つの機能変更が全体に影響を与える可能性があります。 開発プロセス 一枚岩のように堅牢で一体化していることから「モノリシック ● ウォーターフォール型開発 （monolithic）」と呼ばれます。 ● リリースサイクル： 数ヶ月〜年単位 ● 大規模な計画駆動型の開発 インフラ環境 ● オンプレミスの物理サーバー ● 固定的なリソース配分 ● データセンターでの運用 過去と現在と未来における開発 過去における課題と現在の解決策 部品化・クラウドネイティブ化が進んだ理由 LLM の登場と今後の展望 27/86
1 モノリシックアーキテクチャの構成例 従来の一枚岩アプリケーションの典型的な構成 💬 メリット ⚠️ デメリット ● シンプルな構成 ● スケールが困難 ● デプロイが容易 ● 部分的な更新不可 ● トランザクション管理が簡単 ● 技術スタック固定 ● 大規模チームでの開発が困難 過去と現在と未来における開発 過去における課題と現在の解決策 セキュリティ ● 境界防御が明確 ● 単一の認証・認可 ● ただし 1 箇所の侵害で全体が危険 部品化・クラウドネイティブ化が進んだ理由 LLM の登場と今後の展望 28/86
1 現在の開発 (2020 年代) - クラウドネイティブ時代 マイクロサービスとクラウドによる柔軟な開発が主流の時代 💡 アーキテクチャの特徴 💡 開発プロセス ● サービス指向・マイクロサービスア ● アジャイル・スクラム開発 ーキテクチャ ● CI/CD による継続的デリバリー ● 各サービスが独立してデプロイ可能 ● リリースサイクル： 日次〜週次 ● サーバーレスアーキテクチャの活用 ● フィーチャーフラグによる段階的リ リース 過去と現在と未来における開発 過去における課題と現在の解決策 💡 インフラ環境 ● クラウドプラットフォーム (AWS, GCP, Azure) ● Infrastructure as Code (IaC) ● コンテナ・オーケストレーション ● サーバーレスコンピューティング 部品化・クラウドネイティブ化が進んだ理由 LLM の登場と今後の展望 29/86
1 マイクロサービスアーキテクチャの構成例 現代的なクラウドネイティブアプリケーションの典型的な構成 📖 アーキテクチャ図 💡 特徴 メリット ● 独立したスケーリング ● 技術スタックの自由度 ● 障害の局所化 ● チームの独立性向上 デメリット ● 分散システムの複雑性 ● サービス間通信の管理 ● データ整合性の担保 セキュリティ面 ● サービスメッシュでの通信暗号化 ● サービスごとの認証・認可 ● ただし攻撃対象領域が拡大 ┌─────────────┐ │ CloudFront │ (CDN) └──────┬──────┘ │ ┌──────▼──────┐ │ API Gateway │ └──┬──┬──┬────┘ │ │ │ ┌───────┘ │ └────────┐ │ │ │ ┌─────▼────┐ ┌──▼────┐ ┌───▼─────┐ │ User │ │Product│ │ Order │ │ Service │ │Service│ │ Service │ │(Lambda) │ │ (ECS) │ │(Lambda) │ └────┬─────┘ └───┬───┘ └────┬────┘ │ │ │ ┌────▼────┐ ┌───▼───┐ ┌───▼────┐ │DynamoDB │ │ RDS │ │SQS/SNS │ └─────────┘ └───────┘ └────────┘ 過去と現在と未来における開発 過去における課題と現在の解決策 部品化・クラウドネイティブ化が進んだ理由 LLM の登場と今後の展望 30/86
1 未来の開発 (予想) - AI 駆動開発時代 AI がコード生成からテストまでを支援する時代 アーキテクチャの特徴 ● AI 最適化されたアーキテクチャ ● 自動スケーリング・自動最適化 ● エッジコンピューティングの普及 開発プロセス ● AI 支援によるコード生成 ● 自動テスト・自動修正 ● 要件から実装までの時間短縮 インフラ環境 ● AI によるインフラ最適化 ● 自己修復システム ● 完全自動化されたセキュリティ 過去と現在と未来における開発 過去における課題と現在の解決策 部品化・クラウドネイティブ化が進んだ理由 LLM の登場と今後の展望 31/86
2 過去における課題と現在の解決策 - 概要 従来の開発手法が抱えていた 3 つの主要な課題 3 つの主要課題 1 スケーラビリティ - リソース調達と拡張性の問題 2 デプロイメント - リリースプロセスの複雑さとリスク 3 運用管理 - 継続的な保守とモニタリングの負荷 これらの課題が、セキュリティ対策の実施を困難にしていました 過去と現在と未来における開発 過去における課題と現在の解決策 部品化・クラウドネイティブ化が進んだ理由 LLM の登場と今後の展望 32/86
2 課題 1: スケーラビリティの問題 物理サーバー時代のリソース管理の困難さ ⚠️ 過去の課題 リソース調達の遅延 ● 物理サーバーの購入・納品： 2-8 週間 ● データセンター設置・設定： 1-2 週間 ● 合計： 最低 3 週間〜3 ヶ月 キャパシティプランニングの困難 ● 将来のトラフィック予測が必要 ● 過剰投資か機会損失の二択 ● 季節変動への対応が困難 スケールアップの限界 ● 垂直スケール（サーバースペック向上）のみ ● ハードウェアの物理的限界 過去と現在と未来における開発 💡 現在の解決策 即時のリソース調達 ● クラウドで数分でサーバー起動 ● API 一発でインフラ構築 ● 世界中のリージョンに即座に展開 動的スケーリング ● Auto Scaling Group で自動調整 ● トラフィックに応じて自動増減 ● コスト最適化も自動 水平スケール ● サーバーを増やすだけでスケール ● 理論上は無限にスケール可能 ● ロードバランサーで負荷分散 過去における課題と現在の解決策 部品化・クラウドネイティブ化が進んだ理由 LLM の登場と今後の展望 33/86
2 課題 2: デプロイメントの複雑さとリスク 手動デプロイプロセスによる問題 ⚠️ 過去の課題 手動作業によるヒューマンエラー ● デプロイ手順書に沿った手作業 ● コマンド打ち間違いのリスク ● 環境差異の見落とし ダウンタイムの発生 ● メンテナンス時間の確保が必要 ● 深夜・休日作業の常態化 ● ビジネス機会の損失 ロールバックの困難さ ● 問題発生時の切り戻し作業が複雑 ● バックアップからの復元に時間 ● データ整合性の問題 過去と現在と未来における開発 💡 現在の解決策 完全自動化されたデプロイ ● GitHub Actions や CircleCI で自動実行 ● コード変更を push するだけ ● 環境差異はコンテナで吸収 ゼロダウンタイムデプロイ ● ブルーグリーンデプロイメント ● ローリングアップデート ● カナリアリリース 安全なロールバック ● ワンクリックで前バージョンに戻せる ● Immutable Infrastructure で信頼性向上 ● データベースマイグレーションも管理 過去における課題と現在の解決策 部品化・クラウドネイティブ化が進んだ理由 LLM の登場と今後の展望 34/86
2 課題 3: 運用管理の負荷と属人化 インフラ運用にかかる継続的なコスト ⚠️ 過去の課題 インフラ管理の負荷 ● ハードウェア故障の対応 ● OS・ミドルウェアのパッチ適用 ● 電源・冷却・ネットワーク管理 モニタリングの困難さ ● 個別のログ管理 ● 障害の早期発見が困難 ● 根本原因の特定に時間 属人化のリスク ● 特定メンバーに知識が集中 ● 夜間・休日の呼び出し対応 ● 引き継ぎの困難さ 過去と現在と未来における開発 💡 現在の解決策 マネージドサービスの活用 ● AWS RDS: DB 管理を自動化 ● AWS Lambda: サーバーレスで運用不要 ● パッチ適用も自動化 統合モニタリング ● CloudWatch で一元管理 ● リアルタイムアラート ● ログ分析も自動化 Infrastructure as Code ● Terraform 等でインフラをコード化 ● GitHub で変更履歴を管理 ● 誰でも再現可能 過去における課題と現在の解決策 部品化・クラウドネイティブ化が進んだ理由 LLM の登場と今後の展望 35/86
3 なぜ部品化・クラウドネイティブ化が進んだのか - 概要 技術変革の背景にある 3 つの要因 変革を推進した 3 つの要因 1 ビジネススピード - 市場競争力の源泉 2 コスト効率化 - 持続可能な成長のために 3 開発者体験 - 人材獲得と生産性向上 これらの要因が、セキュリティの在り方も変えました 過去と現在と未来における開発 過去における課題と現在の解決策 部品化・クラウドネイティブ化が進んだ理由 LLM の登場と今後の展望 36/86
3 理由 1: ビジネススピードの要求 Time to Market が競争優位性を決める時代 市場投入までの時間短縮（Time to Market） ● MVP（Minimum Viable Product）の迅速な提供 ● ユーザーフィードバックを即座に反映 ● 競合より 1 日でも早くリリース アジャイル開発との相性 ● 1-2 週間のスプリントサイクル ● 継続的なデリバリー ● フィーチャーフラグによる段階的リリース 具体例 ● Netflix: 1 日に数 100 回のデプロイ ● Amazon: 11.6 秒に 1 回のデプロイ（2015 年時点） ● メルカリ： 1 日複数回のリリース 過去と現在と未来における開発 過去における課題と現在の解決策 部品化・クラウドネイティブ化が進んだ理由 LLM の登場と今後の展望 37/86
3 理由 2: コスト効率化の必要性 CapEx から OpEx への転換による財務メリット ⚠️ 過去のコスト構造 巨額の初期投資（CapEx） ● サーバー購入： 数百万〜数千万円 ● データセンター設備 ● ライセンス費用 固定的な運用コスト（OpEx） ● 電気代・冷却費 ● 保守契約費用 ● 運用人件費 無駄の発生 ● ピーク時に合わせた過剰投資 ● 稼働率 20-30%も珍しくない 過去と現在と未来における開発 💡 現在のコスト構造 初期投資ゼロ ● クラウドは従量課金 ● 必要な時に必要な分だけ ● 数百円から始められる 変動費化（OpEx 化） ● 使った分だけ支払い ● 需要に応じて自動調整 ● 予算管理が容易 コスト最適化 ● Auto Scaling で無駄ゼロ ● Reserved Instance で割引 ● Spot Instance でさらに削減 過去における課題と現在の解決策 部品化・クラウドネイティブ化が進んだ理由 LLM の登場と今後の展望 38/86
3 理由 3: 開発者体験（DX）の向上 生産性と人材獲得のために インフラ管理からの解放 ● サーバー管理不要、コードに集中 ● マネージドサービスで運用自動化 ● ローカル開発環境の整備 モダンな技術スタックの採用 ● 好きな言語・フレームワークを選択可能 ● 最新技術への追従が容易 ● エコシステムの恩恵 エンジニアの満足度向上 ● やりがいのある仕事に集中 ● ワークライフバランスの改善 ● 優秀な人材の獲得・定着 👀 重要 開発者体験の向上は、セキュリティ文化の浸透にも不可欠 過去と現在と未来における開発 過去における課題と現在の解決策 部品化・クラウドネイティブ化が進んだ理由 LLM の登場と今後の展望 39/86
4 LLM の登場と今後の展望 - 概要 AI 技術が開発プロセスに革命をもたらす LLM がもたらす 3 つの変化 1 開発生産性の飛躍的向上 - コード生成の自動化 2 新たなセキュリティリスク - AI が生成する脆弱性 3 セキュリティの民主化 - 誰でもセキュアなコードを この変化に対応するための知識が必要です 過去と現在と未来における開発 過去における課題と現在の解決策 部品化・クラウドネイティブ化が進んだ理由 LLM の登場と今後の展望 40/86
4 現在の LLM 活用 - 開発生産性の向上 AI 支援ツールが変える日常的な開発フロー コード生成・補完 ● GitHub Copilot: コメントから実装を自動生成 ● Claude Code: 要件からファイル作成まで自動化 ● Cursor: IDE 統合型の AI 支援 ドキュメント作成 ● README の自動生成 ● API 仕様書の作成支援 ● コメントの自動追加 テスト・レビュー ● ユニットテストの自動生成 ● コードレビューコメントの提案 ● リファクタリングの提案 過去と現在と未来における開発 過去における課題と現在の解決策 部品化・クラウドネイティブ化が進んだ理由 LLM の登場と今後の展望 41/86
4 LLM がもたらすセキュリティリスク AI 生成コードの脆弱性と新たな攻撃手法 ⚠️ リスク 1: 脆弱なコード生成 学習データの問題 ● 古い脆弱なコードを学習 ● StackOverflow の不適切な例を再現 具体的な脆弱性 ● SQL インジェクション ● XSS（クロスサイトスクリプティング） ● 不適切な認証・認可 ● ハードコードされたシークレット 検証の必要性 ● AI 生成コードは必ずレビュー ● 静的解析ツールでの検証 ● セキュリティテストの実施 過去と現在と未来における開発 ⚠️ リスク 2: AI 特有の脅威 プロンプトインジェクション ● 悪意あるプロンプトで AI 操作 ● 意図しない動作を引き起こす 機密情報の漏洩 ● プロンプトに秘密情報を含める ● AI の学習データに機密が混入 依存関係の問題 ● AI が古いライブラリを提案 ● 脆弱性のあるパッケージ使用 対策の重要性 ● 機密情報はプロンプトに含めない ● 依存関係の定期的な更新 ● プライベート LLM の検討 過去における課題と現在の解決策 部品化・クラウドネイティブ化が進んだ理由 LLM の登場と今後の展望 42/86
4 今後の展望 - AI によるセキュリティの進化 セキュリティも AI で自動化・民主化される未来 AI 駆動のセキュリティテスト ● 脆弱性の自動検出 ● ペネトレーションテストの自動化 ● 脅威モデリングの自動生成 自動修正と提案 ● 脆弱性を検出したら自動でパッチ生成 ● セキュアなコードパターンへのリファクタリング ● コンプライアンス違反の自動修正 セキュリティの民主化 ● 初心者でもセキュアなコード作成 ● ベストプラクティスの自動適用 ● セキュリティエキスパートの知識を誰でも利用可能 🗒️ ノート AI はツール。最終的な責任は開発者にあることを忘れずに 過去と現在と未来における開発 過去における課題と現在の解決策 部品化・クラウドネイティブ化が進んだ理由 LLM の登場と今後の展望 43/86
S セクション 1 のまとめ 現代的なプロダクト開発の変遷とこれから 過去から現在への変化 ● モノリシック → マイクロサービス ● オンプレミス → クラウドネイティブ ● ウォーターフォール → アジャイル 変化を推進した要因 ● ビジネススピードの要求 ● コスト効率化の必要性 ● 開発者体験の向上 LLM による新たな時代 ● 開発生産性の飛躍的向上 ● 新たなセキュリティリスクへの対応 ● セキュリティの自動化・民主化 次のセクションでは、この現代的な開発環境におけるプロダクトセキュリティの実践を学びます 過去と現在と未来における開発 過去における課題と現在の解決策 部品化・クラウドネイティブ化が進んだ理由 LLM の登場と今後の展望 44/86
現代的なプロダクトの開発ってどんな感じ？ プロダクトセキュリティの基本的な考え方と実践 BtoC プロダクトにおけるセキュリティ設計のポイント ハンズオン まとめ 2 - プロダクトセキュリティの基本的な考え方と実践 開発者もセキュリティ担当者も知っておくべきこと プロダクトの本質である「価値提供」を邪魔しないセキュリティのあり方 本トピックについて 1 SDLC や DevSecOps の基本概念を知る 2 設計におけるセキュリティの考え方 3 実装とテストにおけるセキュリティの考え方 4 システム全体としてみた時の複雑性とセキュリティ 5 戦略的なセキュリティ対策の考え方
1 SDLC と DevSecOps の基本概念 - 概要 セキュアな開発を実現するための基盤知識 理解すべき 3 つの概念 1 従来の開発手法の課題 - なぜセキュリティが後回しになるのか 2 Shift-Left アプローチ - 早期からのセキュリティ統合 3 DevSecOps の実践 - 自動化とセキュリティの融合 この理解が、現代的なプロダクトセキュリティの基盤となります SDLC や DevSecOps の基 本概念 設計におけるセキュリティの 考え方 実装とテストにおけるセキュリティ の考え方 システム全体としての複雑性とセキ ュリティ 戦略的なセキュリティ対策の 考え方 46/86
1 従来の開発手法におけるセキュリティの課題 - ウォーターフォール 順次型開発でのセキュリティ対応の問題点 ウォーターフォールの典型的なフェーズ 1 要件定義 → 2. 設計 → 3. 実装 → 4. テスト → 5. デプロイ・保守 セキュリティの問題点 ● 後工程での対応: セキュリティテストは「テスト」フェーズで初めて実施 ● 発見の遅延: 脆弱性発見が開発サイクルの終盤に集中 ● 修正コストの増大: 設計に起因する問題は大規模な手戻りが必要 ● リリース遅延: セキュリティ問題の修正でスケジュールに影響 結果として発生する問題 ● セキュリティが「後付け」になる ● 根本的な設計変更が困難 ● セキュリティチームと開発チームの対立 SDLC や DevSecOps の基 本概念 設計におけるセキュリティの 考え方 実装とテストにおけるセキュリティ の考え方 システム全体としての複雑性とセキ ュリティ 戦略的なセキュリティ対策の 考え方 47/86
1 従来の開発手法におけるセキュリティの課題 - アジャイル 反復型開発でのセキュリティ対応の問題点 アジャイルの基本原則 ● 顧客との協調 > 契約交渉 ● 動くソフトウェア > 包括的な文書 ● 変化への対応 > 計画の遵守 セキュリティの問題点 ● スプリント優先: 機能開発が優先され、セキュリティが後回し ● 技術的負債の蓄積: 「後でセキュリティ対策」が積み重なる ● セキュリティレビューの省略: 短いイテレーションで十分なレビューができない ● ドキュメント不足: セキュリティ要件や脅威モデルの文書化が疎かに よくある誤解 「アジャイルだからセキュリティは柔軟に対応」→ 実際は場当たり的になる 「継続的デリバリーで修正も早い」→ 本番環境での脆弱性露出リスクも高い SDLC や DevSecOps の基 本概念 設計におけるセキュリティの 考え方 実装とテストにおけるセキュリティ の考え方 システム全体としての複雑性とセキ ュリティ 戦略的なセキュリティ対策の 考え方 48/86
1 Shift-Left アプローチとは 開発の早期段階からセキュリティを組み込む考え方 ⚠️ 従来のアプローチ 開発完了後にセキュリティテスト ● 問題発見時の修正コストが高い ● リリース遅延のリスク ● セキュリティが「障害」として認識される コストの増大 ● Boehm のコスト曲線 ● 本番環境での修正は設計段階の 100 倍 SDLC や DevSecOps の基 本概念 設計におけるセキュリティの 考え方 💡 Shift-Left アプローチ 設計・開発段階からセキュリティを組み込み ● 早期発見・早期修正 ● 継続的なセキュリティ改善 ● セキュリティが「品質」として認識される メリット ● 修正コストの大幅削減 ● リリーススピードの向上 ● セキュアな設計の実現 実装とテストにおけるセキュリティ の考え方 システム全体としての複雑性とセキ ュリティ 戦略的なセキュリティ対策の 考え方 49/86
1 DevSecOps とは Dev（開発）・Sec（セキュリティ）・Ops（運用）の統合 DevSecOps の 3 つの柱 1 自動化 - セキュリティテストを CI/CD パイプラインに統合 2 協働 - 開発・セキュリティ・運用チームの壁を取り払う 3 継続的改善 - フィードバックループによる学習と改善 具体的な実践 ● SAST（静的解析）/ DAST（動的解析）の自動実行 ● 依存関係の脆弱性スキャン（SCA） ● Infrastructure as Code のセキュリティスキャン ● コンテナイメージのセキュリティチェック 👀 重要 DevSecOps はツールではなく、文化と考え方の変革 SDLC や DevSecOps の基 本概念 設計におけるセキュリティの 考え方 実装とテストにおけるセキュリティ の考え方 システム全体としての複雑性とセキ ュリティ 戦略的なセキュリティ対策の 考え方 50/86
2 設計におけるセキュリティの考え方 - 概要 セキュリティ・バイ・デザインの実践 設計段階で考慮すべき 3 つの要素 1 脅威モデリング - 想定される脅威の洗い出しと対策 2 アーキテクチャレベルのセキュリティ - 構造的なセキュリティの組み込み 3 セキュリティ原則の適用 - 最小権限・多層防御・Fail Safe 設計段階でのセキュリティ統合が、全体のコストを大幅に削減します SDLC や DevSecOps の基 本概念 設計におけるセキュリティの 考え方 実装とテストにおけるセキュリティ の考え方 システム全体としての複雑性とセキ ュリティ 戦略的なセキュリティ対策の 考え方 51/86
2 脅威モデリングの実践 設計段階で脅威を特定し対策を講じる STRIDE モデル ● Spoofing（なりすまし）: 認証の脆弱性 ● Tampering（改ざん）: データの完全性 ● Repudiation（否認）: ログと監査 ● Information Disclosure（情報漏洩）: 機密性 ● Denial of Service（サービス拒否）: 可用性 ● Elevation of Privilege（権限昇格）: 認可の脆弱性 実践ステップ 1 システム図を作成 2 各コンポーネントに STRIDE を適用 3 脅威に対する対策を設計 4 残存リスクを評価 SDLC や DevSecOps の基 本概念 設計におけるセキュリティの 考え方 実装とテストにおけるセキュリティ の考え方 システム全体としての複雑性とセキ ュリティ 戦略的なセキュリティ対策の 考え方 52/86
2 アーキテクチャレベルのセキュリティ 構造的にセキュアな設計を実現する セキュリティパターン ● ゼロトラストアーキテクチャ: 信頼境界を設けず、すべてを検証 ● マイクロセグメンテーション: サービス間通信を細かく制御 ● API Gateway パターン: 統一的なセキュリティポリシーの適用 セキュリティ原則 ● 最小権限の原則: 必要最小限の権限のみ付与 ● 多層防御: 複数のセキュリティ層を重ねる ● Fail Safe: 障害時は安全側に倒れる設計 具体例 ● AWS IAM ロールで Lambda に最小権限のみ付与 ● サービスメッシュ（Istio 等）で mTLS を強制 ● WAF + RASP + SIEM の多層防御 SDLC や DevSecOps の基 本概念 設計におけるセキュリティの 考え方 実装とテストにおけるセキュリティ の考え方 システム全体としての複雑性とセキ ュリティ 戦略的なセキュリティ対策の 考え方 53/86
3 実装とテストにおけるセキュリティ - 概要 セキュアコーディングと自動化テストの実践 実装段階で重要な 3 つの要素 1 セキュアコーディング - OWASP Top 10 などのベストプラクティス 2 静的解析・動的解析 - 自動化されたセキュリティテスト 3 テスト駆動セキュリティ - セキュリティ要件もテストで検証 コードレビューと自動化ツールの組み合わせが効果的です SDLC や DevSecOps の基 本概念 設計におけるセキュリティの 考え方 実装とテストにおけるセキュリティ の考え方 システム全体としての複雑性とセキ ュリティ 戦略的なセキュリティ対策の 考え方 54/86
3 セキュアコーディングプラクティス OWASP Top 10 を基にした実践的な対策 ⚠️ 主要な脆弱性と対策 インジェクション攻撃 ● SQL インジェクション ● コマンドインジェクション ● 対策: パラメータ化クエリ、ORM 使用 XSS（クロスサイトスクリプティング） ● 対策: 出力エスケープ、CSP ヘッダー 認証・認可の不備 ● 対策: OAuth 2.0、JWT、RBAC SDLC や DevSecOps の基 本概念 設計におけるセキュリティの 考え方 💡 コーディング規約 入力値検証 ● ホワイトリスト方式 ● 型チェックとバリデーション 機密情報の取り扱い ● ハードコードしない ● 環境変数や AWS Secrets Manager 使用 エラー処理 ● 詳細なエラー情報を外部に露出しない ● ログには十分な情報を記録 実装とテストにおけるセキュリティ の考え方 システム全体としての複雑性とセキ ュリティ 戦略的なセキュリティ対策の 考え方 55/86
3 静的解析(SAST)・動的解析(DAST)の活用 自動化ツールでセキュリティを担保 SAST（Static Application Security Testing） ● コードを実行せずに解析 ● SQL インジェクション、XSS などのパターンを検出 ● ツール: SonarQube, Semgrep, CodeQL DAST（Dynamic Application Security Testing） ● 実行中のアプリケーションをテスト ● 実際の攻撃をシミュレーション ● ツール: OWASP ZAP, Burp Suite SCA（Software Composition Analysis） ● 依存関係の脆弱性を検出 ● ツール: Dependabot, Snyk, npm audit 🗒️ ノート SAST は早期発見、DAST は実環境での検証。両方を組み合わせることが重要 SDLC や DevSecOps の基 本概念 設計におけるセキュリティの 考え方 実装とテストにおけるセキュリティ の考え方 システム全体としての複雑性とセキ ュリティ 戦略的なセキュリティ対策の 考え方 56/86
4 システム全体としての複雑性とセキュリティ - 概要 マイクロサービス時代の新たなセキュリティ課題 現代のシステムが抱える 3 つの複雑性 1 マイクロサービスの分散性 - サービス間通信の増加 2 サプライチェーンの複雑化 - 外部依存の増加 3 動的な環境 - コンテナ・サーバーレスの普及 セクション 1 で見た現代的な開発スタイルが生み出す新たな課題です SDLC や DevSecOps の基 本概念 設計におけるセキュリティの 考え方 実装とテストにおけるセキュリティ の考え方 システム全体としての複雑性とセキ ュリティ 戦略的なセキュリティ対策の 考え方 57/86
4 マイクロサービスのセキュリティ課題 分散システム特有のセキュリティ問題と対策 セキュリティ課題 ● 攻撃対象領域の拡大: 各サービスがエントリーポイントに ● サービス間認証・認可: A サービスから B サービスへのアクセス制御 ● データの分散: 各サービスが独自の DB を持つことによる複雑性 ● 監視の困難さ: 分散トレーシングとログ集約の必要性 対策 ● サービスメッシュ: Istio や Linkerd で mTLS を強制 ● API Gateway: 統一的なセキュリティポリシー ● 分散トレーシング: Jaeger や OpenTelemetry で可観測性向上 ● シークレット管理: AWS Secrets Manager、HashiCorp Vault SDLC や DevSecOps の基 本概念 設計におけるセキュリティの 考え方 実装とテストにおけるセキュリティ の考え方 システム全体としての複雑性とセキ ュリティ 戦略的なセキュリティ対策の 考え方 58/86
4 サプライチェーンセキュリティ 外部依存がもたらすリスクと対策 ⚠️ リスク ライブラリの脆弱性 ● log4j、OpenSSL など ● 依存関係の依存関係（推移的依存） 外部サービスの侵害 ● Auth0、Okta などの認証サービス ● AWS、GCP などのクラウドプロバイダー 供給元への攻撃 ● npm、PyPI などのパッケージリポジトリ ● GitHub などのソースコードリポジトリ SDLC や DevSecOps の基 本概念 設計におけるセキュリティの 考え方 💡 対策 依存関係の管理 ● Dependabot、Renovate での自動更新 ● SCA ツールでの継続的スキャン サプライヤーの評価 ● SOC 2、ISO 27001 などの認証確認 ● SLA、セキュリティ対応プロセスの確認 多層防御 ● 外部サービス障害時の Fallback ● 定期的なセキュリティ監査 実装とテストにおけるセキュリティ の考え方 システム全体としての複雑性とセキ ュリティ 戦略的なセキュリティ対策の 考え方 59/86
5 戦略的なセキュリティ対策の考え方 - 概要 リスクベースでセキュリティ投資を最適化 戦略的アプローチの 3 つの柱 1 リスクベースアプローチ - リスクの高い箇所に重点投資 2 継続的改善のサイクル - PDCA サイクルによる改善 3 セキュリティ文化の醸成 - 全員がセキュリティを意識 完璧なセキュリティは存在しない。リスクを管理し、継続的に改善することが重要 SDLC や DevSecOps の基 本概念 設計におけるセキュリティの 考え方 実装とテストにおけるセキュリティ の考え方 システム全体としての複雑性とセキ ュリティ 戦略的なセキュリティ対策の 考え方 60/86
5 リスクベースアプローチ リスクの高い箇所に重点的に投資する リスク評価の手順 1 資産の特定: 何を守るべきか（顧客データ、決済情報等） 2 脅威の特定: 何が脅威か（外部攻撃、内部不正等） 3 脆弱性の特定: どこに弱点があるか 4 影響度の評価: 侵害された場合の影響 5 対策の優先順位付け: リスクとコストのバランス 実践例 ● クレジットカード情報: 影響度「高」→ PCI DSS 準拠、トークン化 ● 一般的な商品情報: 影響度「低」→ 基本的な対策のみ ● 管理者機能: 影響度「高」→ 多要素認証、IP 制限 SDLC や DevSecOps の基 本概念 設計におけるセキュリティの 考え方 実装とテストにおけるセキュリティ の考え方 システム全体としての複雑性とセキ ュリティ 戦略的なセキュリティ対策の 考え方 61/86
5 継続的改善のサイクル PDCA サイクルによるセキュリティの向上 PDCA サイクル ● Plan（計画）: セキュリティ目標と施策の策定 ● Do（実行）: セキュリティ対策の実装 ● Check（評価）: 監査、ペネトレーションテストでの検証 ● Act（改善）: 発見した問題の修正とプロセス改善 フィードバックループ ● インシデント発生 → ポストモーテム → 再発防止策 ● 脆弱性発見 → 修正 → 同様のパターンを全体で検索 ● ペネトレーションテスト → 脆弱性修正 → プロセス改善 メトリクス ● MTTR（平均修復時間）の短縮 ● 脆弱性検出から修正までの時間 ● セキュリティテストのカバレッジ SDLC や DevSecOps の基 本概念 設計におけるセキュリティの 考え方 実装とテストにおけるセキュリティ の考え方 システム全体としての複雑性とセキ ュリティ 戦略的なセキュリティ対策の 考え方 62/86
5 セキュリティ文化の醸成 全員がセキュリティを意識する組織づくり 文化醸成の要素 ● 教育とトレーニング: セキュアコーディング研修、CTF 開催 ● 心理的安全性: 脆弱性を報告しやすい雰囲気 ● インセンティブ: セキュリティに貢献した社員を評価 ● ツールと環境の整備: 開発者がセキュアな選択を容易にできる環境 Paved Road（舗装された道）の提供 ● セキュアなライブラリ・フレームワークの推奨 ● セキュアなテンプレートやボイラープレートの提供 ● 自動化ツールの整備 👀 重要 セキュリティは特定の人の仕事ではなく、全員の責任 SDLC や DevSecOps の基 本概念 設計におけるセキュリティの 考え方 実装とテストにおけるセキュリティ の考え方 システム全体としての複雑性とセキ ュリティ 戦略的なセキュリティ対策の 考え方 63/86
S セクション 2 のまとめ プロダクトセキュリティの基本的な考え方 従来の課題と Shift-Left アプローチ ● ウォーターフォール・アジャイルの課題 ● Shift-Left による早期セキュリティ統合 ● DevSecOps の実践 各フェーズでのセキュリティ ● 設計: 脅威モデリング、アーキテクチャパターン ● 実装: セキュアコーディング、SAST/DAST ● システム全体: マイクロサービス、サプライチェーン 戦略的アプローチ ● リスクベースでの優先順位付け ● PDCA サイクルによる継続的改善 ● 全員参加のセキュリティ文化 次のセクションでは、BtoC プロダクトにおける具体的なセキュリティ設計のポイントを学びます SDLC や DevSecOps の基 本概念 設計におけるセキュリティの 考え方 実装とテストにおけるセキュリティ の考え方 システム全体としての複雑性とセキ ュリティ 戦略的なセキュリティ対策の 考え方 64/86
現代的なプロダクトの開発ってどんな感じ？ プロダクトセキュリティの基本的な考え方と実践 BtoC プロダクトにおけるセキュリティ設計・テストのポイント ハンズオン まとめ 3 - BtoC プロダクトにおけるセキュリティのポイント 顧客が求める安全性と利便性の両立 EC サイトを例に、具体的な設計・テストのポイントを解説 本トピックについて 1 BtoC、BtoB はどう違うのか？ 2 顧客が求める安全性と利便性の両立 3 取り扱いに考慮が必要なデータとは？ 4 決済や個人情報保護に関する設計のポイント 5 テストにおけるポイントと QA 的視点の重要性 6 発展： BtoBtoC ではどうするのか？
1 BtoC と BtoB の違い - ユーザー特性 BtoC と BtoB では、ユーザー特性が大きく異なり、それに応じたセキュリティ設計が求められます。 ⚠️ BtoC サービスとは？ 💡 BtoB サービスとは？ Bussiness to Consumer（対顧客事業）を BtoC と呼 Bussiness to Business（対企業事業）を BtoB と呼び、 び、一般消費者を対象とした商品やサービスを提供するビ 企業間で商品やサービスを提供するビジネスモデルです。 ジネスモデルです。 例： Salesforce、SmartHR、Freee など 例： Amazon、楽天、メルカリ、Netflix など 特定の組織ユーザー 不特定多数のユーザー ● 一定の IT リテラシーを期待可能 ● IT リテラシーの差が大きい ● 組織のセキュリティポリシーに従う ● セキュリティ意識もバラバラ ● 研修や教育が実施される ● マニュアルを読まない傾向 継続的な利用 高い離脱リスク ● 契約ベースの長期利用 ● 使いづらいと即座に離脱 ● 移行コストが高い ● 競合サービスへの移行が容易 ● サポート体制が充実 ● 第一印象が重要 BtoC、BtoB はど う違うのか？ 顧客が求める安全性と 利便性の両立 取り扱いに考慮が必要な データとは？ 決済や個人情報保護に関する 設計のポイント テストにおけるポイントと QA 的視点の重要性 発展： BtoBtoC ではど うするのか？ 66/86
1 BtoC と BtoB の違い - セキュリティ要求 ユーザー特性の違いは、セキュリティ要求の優先順位の違いにも直結します。 ⚠️ BtoC のセキュリティ要求 💡 BtoB のセキュリティ要求 利便性が最優先 セキュリティが最優先 ● ログインは簡単に ● 監査証跡の記録 ● 手順は最小限に ● アクセス制御の厳格化 ● エラーはわかりやすく ● コンプライアンス対応 見えないセキュリティ 明示的なセキュリティ ● 背後で守る仕組み ● セキュリティ機能の可視化 ● ユーザーに負担をかけない ● ログ・レポート機能 ● 透明性のある保護 ● 管理者による制御 BtoC、BtoB はど う違うのか？ 顧客が求める安全性と 利便性の両立 取り扱いに考慮が必要な データとは？ 決済や個人情報保護に関する 設計のポイント テストにおけるポイントと QA 的視点の重要性 発展： BtoBtoC ではど うするのか？ 67/86
2 安全性と利便性のトレードオフ? 例えば、認証における安全性と利便性のバランスを考えてみましょう。 ⚠️ 過度なセキュリティの問題 💡 適切なバランスの例 ユーザー離脱の原因 リスクベースアプローチ ● 複雑すぎるパスワード要求 ● 低リスク操作： 簡易認証 ● 頻繁な再認証 ● 高リスク操作： 強固な認証 ● わかりにくい MFA ● 状況に応じた制御 実例 実例 ● パスワード： 16 文字以上、記号必 ● 商品閲覧： ログイン不要 須 → 忘れて離脱 ● カート追加： 簡易ログイン（ソー ● セッション： 5 分で切れる → 買い シャルログイン OK） 物カゴが空に ● 決済： SMS 認証や生体認証 BtoC、BtoB はど う違うのか？ 顧客が求める安全性と 利便性の両立 取り扱いに考慮が必要な データとは？ 決済や個人情報保護に関する 設計のポイント 従来の認証手法からの転換 ● パスワード中心 → 多要素認証 (MFA) ● 固定認証 → リスクベース認証 ● ID/PW 管理 → パスワードレス認証 テストにおけるポイントと QA 的視点の重要性 発展： BtoBtoC ではど うするのか？ 68/86
2 リスクベース認証の実践 操作のリスクレベルに応じて認証強度を調整することで、利便性とセキュリティを両立できます。 💡 リスクレベルに応じた認証強度の調整 操作 BtoC、BtoB はど う違うのか？ リスクレベル 認証方式 例 商品閲覧 カート追加 購入 (少額) 低 低〜中 中 認証不要 ソーシャルログイン パスワード + セッション確認 Amazon、楽天 Google、Apple でログイン 〜10,000 円の買い物 購入 (高額) 登録情報変更 高 高 MFA (SMS、生体認証) MFA + メール確認 50,000 円以上の買い物 メールアドレス、住所変更 決済情報変更 最高 MFA + 本人確認 クレジットカード登録変更 顧客が求める安全性と 利便性の両立 取り扱いに考慮が必要な データとは？ 決済や個人情報保護に関する 設計のポイント テストにおけるポイントと QA 的視点の重要性 発展： BtoBtoC ではど うするのか？ 69/86
3 BtoC プロダクトで扱う機密データの分類 📖 データの機密性レベルと保護要件 機密レベル 最高 BtoC、BtoB はど う違うのか？ データ種別 決済情報 保護要件 PCI DSS 準拠、暗号化、トークン化 例 クレジットカード番号、CVV 高 高 中 認証情報 個人識別情報 (PII) 行動履歴 ハッシュ化、ソルト付き、MFA 暗号化、アクセス制御、監査ログ アクセス制御、匿名化オプション パスワード、秘密の質問 氏名、住所、電話番号、メール 購入履歴、閲覧履歴 低 公開プロフィール アクセス制御のみ ユーザー名、プロフィール画像 顧客が求める安全性と 利便性の両立 取り扱いに考慮が必要な データとは？ 決済や個人情報保護に関する 設計のポイント テストにおけるポイントと QA 的視点の重要性 発展： BtoBtoC ではど うするのか？ 70/86
3 個人情報保護法と GDPR の影響 📖 日本の個人情報保護法 主要な義務 ● 利用目的の明示・同意取得 ● 安全管理措置の実施 ● 第三者提供の制限 ● 開示・訂正・削除請求への対応 罰則 ● 法人： 最大 1 億円の罰金 ● 個人： 最大 2 年の懲役または 100 万円の罰金 BtoC、BtoB はど う違うのか？ 顧客が求める安全性と 利便性の両立 取り扱いに考慮が必要な データとは？ 📖 EU の GDPR (一般データ保護規則) 主要な権利 ● 忘れられる権利（データ削除） ● データポータビリティ（データ移行） ● プロファイリング拒否権 ● 同意の撤回権 罰則 ● 最大 2,000 万ユーロまたは全世界売上の 4% のいずれ か高い方 決済や個人情報保護に関する 設計のポイント テストにおけるポイントと QA 的視点の重要性 発展： BtoBtoC ではど うするのか？ 71/86
4 決済システムのセキュリティ設計 ⚠️ 自社で決済処理を実装 課題とリスク ● PCI DSS 準拠のコスト ● 年間数百万〜数千万円 ● カード情報の保護責任 ● 暗号化、ネットワーク分離 ● セキュリティ監査の負担 ● 定期的な脆弱性診断 推奨されないケース 小規模サービスや EC スタートアップ 💡 決済代行サービスの利用 メリット ● PCI DSS 準拠が不要 ● カード情報を保持しない ● 実装が容易 ● API/SDK が提供される ● セキュリティリスクの軽減 主要サービス ● Stripe: グローバル対応 ● PayPal: 信頼性が高い ● PAY.JP: 日本向け ● BtoC、BtoB はど う違うのか？ 顧客が求める安全性と 利便性の両立 取り扱いに考慮が必要な データとは？ 決済や個人情報保護に関する 設計のポイント テストにおけるポイントと QA 的視点の重要性 発展： BtoBtoC ではど うするのか？ 72/86
4 決済フローのセキュリティ対策 💡 決済時に実装すべきセキュリティ対策 [ユーザー] → [EC サイト] → [決済代行] → [カード会社] 1. HTTPS 通信の徹底 ● 全ての決済関連ページで TLS 1.2 以上を使用 ● 混在コンテンツ（HTTP リソース）を排除 2. 3D セキュアの導入 ● カード会社が提供する本人認証（SMS、アプリ認証） ● 不正利用時の責任を軽減（チャージバック対策） 3. 不正検知システムの導入 ● 異常な購買パターンの検出（同一カードで短時間に大量購入） ● IP アドレス、デバイスフィンガープリントの記録 BtoC、BtoB はど う違うのか？ 顧客が求める安全性と 利便性の両立 取り扱いに考慮が必要な データとは？ 決済や個人情報保護に関する 設計のポイント テストにおけるポイントと QA 的視点の重要性 発展： BtoBtoC ではど うするのか？ 73/86
4 換金制の高いポイントの取り扱い ⚠️ ポイントシステムのリスク ● ポイントの不正移転・換金のリスク ● 内部不正のリスク ● ポイント追加・削除の不正操作 ● 複数回のポイント付与 ● ポイント残高の改ざん BtoC、BtoB はど う違うのか？ 顧客が求める安全性と 利便性の両立 取り扱いに考慮が必要な データとは？ 💡 セキュリティ対策の例 ● ポイント操作の多要素認証 (MFA) ● 監査ログの記録と定期レビュー ● トランザクションの整合性チェック 決済や個人情報保護に関する 設計のポイント テストにおけるポイントと QA 的視点の重要性 発展： BtoBtoC ではど うするのか？ 74/86
4 決済などのトランザクション処理の整合性確保 - TOCTOU ポイントや決済において、トランザクションの整合性を確保することが重要です。例えば、Amazon のプリペイドカード の登録時に、複数回のポイント付与が発生しないようにする必要があります。 このためには、以下のような対策が考えられます。 ● トランザクション管理: データベースのトランザクション機能を利用し、ポイント付与処理を一括で行う。 ● ログの記録: ポイント付与の履歴をログに記録し、不正な操作が行われた場合に追跡できるようにする。 ● 定期的な監査: ポイント付与のルールや実績を定期的に監査し、不正な付与が行われていないか確認する。 https://wg1.isog-j.org/newtechtestdoc/docs/toctou/ BtoC、BtoB はど う違うのか？ 顧客が求める安全性と 利便性の両立 取り扱いに考慮が必要な データとは？ 決済や個人情報保護に関する 設計のポイント テストにおけるポイントと QA 的視点の重要性 発展： BtoBtoC ではど うするのか？ 75/86
4 個人情報の保護とアクセス制御 📖 データストアでの個人情報保護の実装例 機微情報の保管期間 ● 最小限の期間のみ保存 ● 法律で定められた保存期間を遵守 ● たとえば ● 本人確認書類は必要以上の期間保存しない(利用規約にて定める) ● 購入履歴は税法に基づき 7 年間保存 ● 保存期間終了後は安全に削除 アクセス制御 ● カスタマーサポート： 名前、メールのみ閲覧可能（住所は見えない） ● エンジニア： 本番環境の個人情報にアクセス不可（マスキング） ● 顧客: 他のユーザーの情報は見れてはいけない BtoC、BtoB はど う違うのか？ 顧客が求める安全性と 利便性の両立 取り扱いに考慮が必要な データとは？ 決済や個人情報保護に関する 設計のポイント テストにおけるポイントと QA 的視点の重要性 発展： BtoBtoC ではど うするのか？ 76/86
5 テストにおけるセキュリティの考慮点 ⚠️ テストデータの取り扱い やってはいけないこと ● 本番データをコピーして使用 ● 個人情報保護法違反 ● テストデータに実在の情報 ● メールアドレス、電話番号 リスク ● 情報漏洩 ● 誤送信（テストメールが実ユーザーに届く） ● コンプライアンス違反 BtoC、BtoB はど う違うのか？ 顧客が求める安全性と 利便性の両立 取り扱いに考慮が必要な データとは？ 💡 適切なテストデータ管理 ベストプラクティス ● 本番データのマスキング ● 個人情報を匿名化・仮名化 ● 合成データの生成 ● Faker ライブラリで架空データ作成 ツール例 ● Mockaroo: CSV で合成データ生成 ● Faker (Python/JS): プログラムで生成 決済や個人情報保護に関する 設計のポイント テストにおけるポイントと QA 的視点の重要性 発展： BtoBtoC ではど うするのか？ 77/86
5 QA 視点でのセキュリティテスト 📖 QA を行う際に実施すべきセキュリティテスト項目 1. 認証・認可のテスト ● ログインせずに保護されたページにアクセスできないか ● 他ユーザーの情報を見られないか（権限昇格） ● セッション切れ後の動作確認 2. 入力値検証のテスト ● XSS: <script>alert('XSS')</script> を入力欄に貼り付け ● SQL インジェクション： ' OR '1'='1 をログイン画面に入力 ● パストラバーサル： ../../etc/passwd をファイルアップロードで試す 3. エラーハンドリングのテスト ● エラーメッセージに機密情報が含まれないか（DB 構造、スタックトレース） ● 不正な入力でシステムがクラッシュしないか BtoC、BtoB はど う違うのか？ 顧客が求める安全性と 利便性の両立 取り扱いに考慮が必要な データとは？ 決済や個人情報保護に関する 設計のポイント テストにおけるポイントと QA 的視点の重要性 発展： BtoBtoC ではど うするのか？ 78/86
5 セキュリティテストの自動化 ⚠️ 手動テストの限界 課題 ● 時間がかかる ● 全ページを手動でチェックは困難 ● 見落としのリスク ● 人為的ミス ● 回帰テストの負担 ● コード変更のたびに再テスト BtoC、BtoB はど う違うのか？ 顧客が求める安全性と 利便性の両立 取り扱いに考慮が必要な データとは？ 💡 自動テストツールの活用 DAST (Dynamic Application Security Testing) ● OWASP ZAP: 無料、CI/CD 統合可能 ● Burp Suite: プロ向け、詳細な解析 ツールの役割 ● XSS、SQL インジェクション検出 ● セキュリティヘッダーのチェック ● 定期的な自動スキャン 決済や個人情報保護に関する 設計のポイント テストにおけるポイントと QA 的視点の重要性 発展： BtoBtoC ではど うするのか？ 79/86
6 BtoBtoC モデルの特徴 📖 BtoBtoC: 企業を通じてエンドユーザーにサービス提供 モデルの例 ● Shopify: 企業（店舗）向けに EC プラットフォーム提供 → 一般消費者が購入 ● Salesforce: 企業向け CRM → 顧客データは一般消費者の情報 ● LINE WORKS: 企業向けビジネスチャット → 社員と顧客がやり取り セキュリティの複雑さ ● 企業側のセキュリティ要求（BtoB） ● エンドユーザーの利便性要求（BtoC） ● 両方を満たす必要がある BtoC、BtoB はど う違うのか？ 顧客が求める安全性と 利便性の両立 取り扱いに考慮が必要な データとは？ 決済や個人情報保護に関する 設計のポイント テストにおけるポイントと QA 的視点の重要性 発展： BtoBtoC ではど うするのか？ 80/86
6 BtoBtoC におけるマルチテナント設計 ⚠️ データ分離の課題 マルチテナントのリスク ● テナント間のデータ漏洩 ● 企業 A の顧客データが企業 B に見える ● 誤った権限設定 ● 企業 A の管理者が企業 B のデータを操作 ● クエリの不備 ● WHERE tenant_id = ? の条件漏れ 💡 適切な分離アプローチ 物理分離 ● テナントごとに DB を分離 ● コスト高、管理複雑 論理分離（推奨） ● 単一 DB、tenant_id で分離 ● Row-Level Security (RLS) 使用 ● ORM レベルでテナント ID を強制 例: PostgreSQL の RLS ALTER TABLE users ENABLE ROW LEVEL SECURITY; CREATE POLICY tenant_isolation ON users USING (tenant_id = current_setting('app.tenant_id')::UUID); BtoC、BtoB はど う違うのか？ 顧客が求める安全性と 利便性の両立 取り扱いに考慮が必要な データとは？ 決済や個人情報保護に関する 設計のポイント テストにおけるポイントと QA 的視点の重要性 発展： BtoBtoC ではど うするのか？ 81/86
6 BtoBtoC における責任分界点の明確化 📖 プラットフォーム vs テナント企業の責任分担 セキュリティ領域 テナント企業側 例 (Shopify) インフラ サーバー、ネットワーク AWS の管理、DDoS 対策 アプリケーション コア機能、脆弱性対応 決済処理、在庫管理 認証基盤 SSO、MFA 提供 △ 設定・運用 テナントが MFA を有効化 データ保護 暗号化、バックアップ △ アクセス制御 テナントが社員の権限管理 エンドユーザー管理 コンプライアンス BtoC、BtoB はど う違うのか？ プラットフォーム側 顧客が求める安全性と 利便性の両立 △ 基本機能提供 GDPR、PCI DSS 基盤 取り扱いに考慮が必要な データとは？ 顧客対応 店舗が顧客サポート 顧客データの適法利用 店舗が利用規約で同意取得 決済や個人情報保護に関する 設計のポイント テストにおけるポイントと QA 的視点の重要性 発展： BtoBtoC ではど うするのか？ 82/86
S セクション 3 のまとめ ⭐ BtoC プロダクトにおけるセキュリティ設計の要点 1. BtoC と BtoB の違いを理解する ● BtoC: 利便性優先、リスクベース認証 ● BtoB: セキュリティ優先、監査・コンプライアンス 2. データの機密性レベルに応じた保護 ● 最高機密（決済情報）: PCI DSS、決済代行利用 ● 高機密（個人情報）: 暗号化、アクセス制御、監査ログ 3. QA とセキュリティテストの統合 ● テストデータの適切な管理（合成データ、マスキング） ● DAST ツールで自動化（OWASP ZAP、Burp Suite） 4. BtoBtoC ではマルチテナント設計と責任分界点の明確化 ● Row-Level Security で論理的データ分離 ● 契約書で責任範囲を明記 BtoC、BtoB はど う違うのか？ 顧客が求める安全性と 利便性の両立 取り扱いに考慮が必要な データとは？ 決済や個人情報保護に関する 設計のポイント テストにおけるポイントと QA 的視点の重要性 発展： BtoBtoC ではど うするのか？ 83/86
現代的なプロダクトの開発ってどんな感じ？ プロダクトセキュリティの基本的な考え方と実践 BtoC プロダクトにおけるセキュリティ設計・テストのポイント ハンズオン まとめ 4 - ハンズオン EC サイトを題材にしたセキュリティ設計・テストの実践 LLM を活用した設計のレビューや脆弱性の調査 本トピックについて 1 設計レビューの実践 2 脆弱性調査の実践 3 LLM を活用する際の注意点 4 ハンズオン 5 答え合わせ
ハ ンズオン みなさんには、EC サイトの簡易設計書とコード断片が与えられます。 Kintone にワークショップの進め方や資料がまとめられたページがありますので、そちらを参考に進めてください。 85/86
現代的なプロダクトの開発ってどんな感じ？ プロダクトセキュリティの基本的な考え方と実践 まとめ(口頭で) BtoC プロダクトにおけるセキュリティ設計・テストのポイント ハンズオン まとめ