dev 補講: プロダクトセキュリティ / Product security overview

by wa6sn

Slide 1

Slide 1 text

dev 補講: プロダクトセキュリティ（公開版） 2024/10 版 1

Slide 2

Slide 2 text

Disclaimer この資料は、社内向けの研修資料スライドをもとに、公開用に修正したものです背景・補足情報は speakerdeck 概要にある、技術ブログ URL からご確認ください 2

Slide 3

Slide 3 text

この講義の目的セキュリティにまつわる概念・用語と、その必要性を知るエンジニアとしてプロダクト開発を行っていく上で、どのようにセキュリティと向き合っていけばよいのかを知る社内で行われている、セキュリティに関わる業務を知る困った時に助けを求められるようにする 3

Slide 4

Slide 4 text

社内のセキュリティ関連タスクの悩み、あるある一口に「セキュリティに気をつけて」と言われても、広範すぎて何をしたらいいか分からないお取引先からのセキュリティチェックシートで、何を求められているのか分からない「セキュリティ対応」とは、全ての穴を塞ぐことが必須のように考えている・・・を、多少緩和したいと思っています 4

Slide 5

Slide 5 text

話すこと・話さないこと話すことセキュリティとはギフティを取り巻く脅威セキュリティ対策の考え方・関わり方話さないこと具体的な攻撃手法の解説など、詳細な技術解説概念のみにとどめます 5

Slide 6

Slide 6 text

アイスブレイク: いくつ聞いたことがありますか？情報セキュリティにおける CIA とはリスク, 脅威, 脆弱性, といった言葉の違いランサムウェア DDoS CVE OWASP TOP 10 6

Slide 7

Slide 7 text

なぜ、セキュリティを学ぶのかお客さまの情報を守ることが法律で定められているから個人情報の保護に関する法律（個人情報保護法） https://elaws.e-gov.go.jp/document?lawid=415AC0000000057 あなたも当事者であるから例えば攻撃により情報漏洩が起こったとき、弊社もある種攻撃の被害者だが、だからといって弊社に対してユーザが納得するわけではないセキュリティに関連したインシデントは非可逆性が高いから一度情報が漏洩してしまうと、その情報の回収・消去はできない一度失った信頼の回復は難しい 7

Slide 8

Slide 8 text

ギフティの直面した脅威公開にあたり、社内情報を含むため削除 8

Slide 9

Slide 9 text

ビジネスモデルにちなんだ難しさ公開にあたり、社内情報を含むため削除 9

Slide 10

Slide 10 text

理論編「セキュリティ」とは 10

Slide 11

Slide 11 text

セキュリティとは ISO 27001 という国際規格では、以下を「情報セキュリティの 3 要素」としています。機密性（Confidentiality）: 権限をもつ人だけが情報にアクセスできること完全性（Integrity）: 情報が正確かつ一貫性をもって保持されていること可用性（Availability）: 情報が必要なときに利用できることそれぞれの頭文字から "CIA" と呼ばれています。これらを守ること全般を「（情報）セキュリティ」と呼びます。さらに真正性、責任追及性、否認防止、信頼性を追加したものを重要視することもあります。 11

Slide 12

Slide 12 text

Exercise 1: CIA が維持できていない、とは機密性、完全性、可用性が維持されていない例をそれぞれ考えてみましょうあなたは EC サイトを運営していますユーザは EC サイトにログインして、商品を購入することができますユーザは商品を購入するとき、EC サイトに住所・電話番号を登録しています EC サイトは、ユーザの住所・電話番号を使って、 EC サイトの契約する貸倉庫サービスから商品を配送します 12

Slide 13

Slide 13 text

例機密性（Confidentiality）が維持できていない EC サイトにて、ほかユーザの情報を閲覧できてしまう完全性（Integrity）が維持できていないサイト内のリンクが改ざんされ、悪意のあるサイトに誘導される可用性（Availability）が維持できていない大量のリクエストでサービスが停止している 13

Slide 14

Slide 14 text

さまざまな脅威 ref: https://www.ipa.go.jp/security/10threats/10threats2023.html 14

Slide 15

Slide 15 text

補足: 今日もどこかでインシデントが発生している定義を知ったことで、"情報セキュリティの CIA" の観点でニュースを読むことが出来るようになりました諸機関の出している記事を読むと、日々様々なセキュリティインシデントが発生していることが分かりますが、「これは何が侵害されたんだろう？どういう目的で攻撃されたんだろう？」と考えながら読んでみてください。個人的おすすめは piyolog さんです。 15

Slide 16

Slide 16 text

補足: 認証制度きちんとしたセキュリティ体制を整えていることを証明するもの。これを取得・維持することで業務や契約が円滑になることも多い。 https://giftee.co.jp/security/ にも記載しています。 ISO 27001 （通称 ISMS）自社内の情報資産やリスクの管理が適切になされ、仕組みが運用されていることを証明するもの。国際規格。プライバシーマーク（通称 P マーク）個人情報の適切な取り扱いを行っていることを証明するもの。日本独自の規格。 16

Slide 17

Slide 17 text

"プロダクト" セキュリティとはなんだろう弊社では、自社プロダクトに対するセキュリティ（青枠）を指しますそれ以外の範囲は、コーポレートセキュリティと呼ばれることが多いです PSIRT, CSIRT といった単語と絡めると、守備範囲が分かりやすいかもしれません Web アプリケーションエンジニアとして責務を持つべき内容です 17

Slide 18

Slide 18 text

補足: コーポレートセキュリティの取り組みの例弊社が取得している認証である ISO 27001・プライバシーマーク、 METI・IPA が提供しているサイバーセキュリティ経営ガイドライン、お取引先からのセキュリティチェックなどを参考に、対応すべき事柄を決めています。具体例 PC やモバイル端末などの台帳化（管理すべき資産の識別）様々な SaaS ツールのアカウント管理（最小権限の付与） VPN 環境の整備（リモートアクセス管理）委託先の台帳化・月次確認（委託先管理）インシデント対応整備（規定整備や訓練など）セキュリティ教育（意識啓発） 18

Slide 19

Slide 19 text

リスクとは情報セキュリティにおけるリスク＝資産価値 × 脅威 × 脆弱性リスク損害や影響を発生させる可能性資産価値情報資産の価値脅威システムや組織に危害を与えるセキュリティ事故の潜在的な原因悪意のある人間（人為/意図的）、ケアレスミス（人為/偶発的）、災害（環境的）脆弱性脅威によって利用されるおそれのある弱点プログラムのバグ、バックアップがない DB、予備電源のないデータセンタ 19

Slide 20

Slide 20 text

リスクマネジメント（図は https://it-trend.jp/project_management/article/33-0031 より引用） 20

Slide 21

Slide 21 text

リスク対応リスクの発生可能性・大きさに応じて、「低減」「回避」「保有」「移転」といった選択肢から妥当な対応を検討する穴を塞いで固める（この図では「低減」に相当）だけが「対応」ではない（図は https://secure-navi.jp/blog/000036 より引用） 21

Slide 22

Slide 22 text

リスク対応例: 「個人情報を取り扱う機能を開発したい」とき、「情報漏えい」リスクに対して低減リスクの発生可能性を下げる・顕在化したときの影響を減らす対策をとる。必要以上の情報を取得しない等回避リスク要因そのものを取り除く。機能開発自体をあきらめる等保有対策を取らないという決定をする。受け入れられる大きさと判断した・現実的な対策がない等移転組織外にリスクを移転する。保険に加入する、専門家にアウトソースする等 22

Slide 23

Slide 23 text

セキュリティ対策の難しさ攻撃側が有利防御側は全方位を守らないといけないが、攻撃側は穴を一つ見つけたら勝ちシステムが堅牢でも、管理者が弱ければ意味がないやろうと思えば際限がないやりたいことはあくまでビジネスであり、セキュリティ対策ではないなぜ、不届き者のために追加のコストを支払わなければならないのか…… 「やりすぎ」にも「やらなさすぎ」にもならず、守るべきところを守れるよう、戦略的にセキュリティ対策を実施することが重要 23

Slide 24

Slide 24 text

多層防御の考え方 "防御側は全方位を守らないといけないが、攻撃側は穴を一つ見つけたら勝ち" どこかに穴があいていても、他の対策でカバーするのが多層防御オフィスに入るまで: ビル正門の施錠監視カメラ警備員ドア前のカードキーによるロック鍵によって侵入を防止しつつ、オフィスにそのまま PC を置かないという考え方もこれというわけで、色々な防御手段を知っておこう 24

Slide 25

Slide 25 text

実践編セキュアに開発業務を行う、とは 25

Slide 26

Slide 26 text

dev として何をすればいいのか？ 1/2 日々の技術的なキャッチアップアプリケーションにおいては、フレームワークを正しく使うことで、脆弱性を埋め込んでしまうことの多くは防げるインフラも、プラットフォーム側のアップデートに追従することでバッドノウハウが過去のものになったり、簡潔・便利・堅牢に使えるようになったりする常にセキュリティ関連で特別なキャッチアップが必要、というわけではなく、健全に改善を行っていくことは結果的にセキュリティ対策にもなる例開発プロセスにセキュリティのタスクを組み込む安全なコード・設定になっているか、セルフチェック出来るようにする等 26

Slide 27

Slide 27 text

dev として何をすればいいのか？ 2/2 "ギークスーツ" で考えるアプリケーションの外である、サービス運用に脆弱性が潜んでいることも「取引先社員になりすまし、弊社から機微情報を聞きとろうとする」等も、あり得ない話ではないサービスによって脅威も対策も様々。biz/dev お互いの目線で考えることが大事さらに、攻撃者の目線でも考えてみましょう STRIDE のような、脅威を洗い出し、分類するためのフレームワークがあります参考: https://www.newton-consulting.co.jp/itilnavi/glossary/stride_model.html 27

Slide 28

Slide 28 text

まずは知ることから OWASP TOP 10 https://owasp.org/Top10/ja/ IPA 安全なウェブサイトの作り方 https://www.ipa.go.jp/security/vuln/websecurity/about.html IPA 情報セキュリティ10大脅威 2023 https://www.ipa.go.jp/security/10threats/10threats2023.html AWS Well-Architected Framework Security Pillar https://docs.aws.amazon.com/ja_jp/wellarchitected/latest/security-pillar/welcome.html 『安全なWebアプリケーションの作り方』（通称・徳丸本） https://wasbook.org/ 28

Slide 29

Slide 29 text

ギフティにおける、プロダクトセキュリティ施策の例 1. 脆弱性診断リリース前 or 定期で行われる、第三者による診断 2. 社内ガイドライン社内における、アプリケーション開発のガイドライン 3. インフラにおけるセキュリティガードレールの構築すべての AWS アカウントに対して行われるセキュリティ対策構築は Platform Unit ですが、運用は各事業部です 4. セキュアコーディング研修希望者は KENRO という、セキュアコーディングの学習サービスを受講できるようにしています 29

Slide 30

Slide 30 text

脆弱性診断 ref: <社内ドキュメントのため省略> 第三者機関での脆弱性診断原則、お客様に見せるプロダクトは受けてもらいます診断の結果、リスクが高いと判定されたものは対応することが原則リリース前に慌ててやることのないよう、「やるものだ」ということを覚えておき、スケジュールに組み込んでおきましょう 30

Slide 31

Slide 31 text

脆弱性診断の結果の例前述のドキュメントを経由して、実際の報告書が読めます閲覧権限を絞っているので、見たい方はリクエストしてください <社内情報のため、画像は削除> 31

Slide 32

Slide 32 text

社内ガイドライン ref: <社内ドキュメントのため省略> 社内における、アプリケーション開発のガイドライン。プロダクトに原則として要求したい要件を記したドキュメントです新規プロダクト構築時には、設計前に一通り目を通してもらい、設計に反映してもらう事を期待しています 32

Slide 33

Slide 33 text

インフラにおけるセキュリティガードレールの構築 ref: <社内ドキュメントのため省略> 弊社のプロダクトインフラのデファクトである AWS について、「意識せずとも行われるセキュリティ対策」を進めようという施策 33

Slide 34

Slide 34 text

各種サービスを用いたセキュリティ対策 IAM や VPC といった、基本的なサービスを正しく理解し扱うことはもちろんですが、 AWS で用意されているセキュリティ系サービスを使った対策を別途行っています IAM Identity Center（SSO） Security Hub, Trusted Advisor GuardDuty CloudTrail, AWS Config WAF （Inspector） 34

Slide 35

Slide 35 text

(1/5) IAM Identity Center（SSO） IAM は大きな攻撃表面の一つであるため、IAM user ではなく IAM Identity Center によって各アカウントにログインすることを推奨しています退職者の IAM user が AWS アカウントに残り続けることを防ぎます長命なアクセスキーを管理する負担が軽減されますこれ自体は、GitHub リポジトリ上で IaC による管理を行っています ref: <社内ドキュメントのため省略> 35

Slide 36

Slide 36 text

(2/5) Security Hub, Trusted Advisor （社内のすべての AWS アカウントで有効化されています）特定の基準に基づいて、クラウド内のリスクの高い設定を検出しますいわゆる Cloud Security Posture Management (CSPM) 36

Slide 37

Slide 37 text

(2/5) Security Hub, Trusted Advisor 例: Security Hub による、Public Read アクセスが有効な S3 バケットの一覧化 37

Slide 38

Slide 38 text

(3/5) GuardDuty （社内のすべての AWS アカウントで有効化されています） EC2 への SSH Bruteforce, S3 バケットの Public access block policy の削除など、 AWS に構築されたリソースに対する脅威を検出するサービスいわゆる IDS（Intrusion Detection System）の一種です 38

Slide 39

Slide 39 text

(3/5) GuardDuty GuardDuty による、振る舞い検知の例 39

Slide 40

Slide 40 text

(3/5) CloudTrail, AWS Config （社内のすべての AWS アカウントで有効化されています） CloudTrail AWS アカウントで行われる API 操作をログに記録するサービス AWS アカウントでは、ほぼすべての操作は API 経由で行われるインフラ操作の証跡になります AWS Config AWS アカウント内のリソースの設定を評価するサービス特定時点のリソースの状況を記録しつつ、問題がないかチェックするようなイメージ Security Hub のデータソースでもあります 40

Slide 41

Slide 41 text

(3/5) CloudTrail, AWS Config CloudTrail に記録されているイベントの例 41

Slide 42

Slide 42 text

(4/5) AWS WAF （利用したい場合、アカウントごとに設定する必要があります） Web Application Firewall 名前の通り、アプリケーション（L7レイヤ）への攻撃を防ぐもので、ざっくり言うと攻撃っぽい文字列を含むリクエストをブロックしたりします GuardDuty は主にインフラを対象としているので、レイヤが異なります各自、必要に応じて設定を入れているはずなので、説明は省略します 42

Slide 43

Slide 43 text

(5/5) Inspector （利用したい場合、アカウントごとに有効化する必要があります）インスタンスやコンテナイメージに含まれるパッケージの脆弱性管理を行うもの「ところで log4j ってどのサーバに入っていたんだっけ？」を解決するもの 43

Slide 44

Slide 44 text

各事業部が把握しておくべきことガードレールとして使用している、各種サービスの存在を知っておきましょうセキュリティガードレールの dev 向けドキュメントにまとめています特に、Security Hub, Trusted Advisor, GuardDuty は定期的に確認しましょう 44

Slide 45

Slide 45 text

補足: "DevSecOps" という考え方 ref: https://owasp.org/www-project-devsecops-guideline/latest/00a-Overview 「開発・保守・管理」と「セキュリティ」を別々に考えるとアジリティが損なわれるため、開発プロセスにセキュリティタスクを組み込むという考え方（やみくもに全てを取り入れようとせず、うまく取捨選択しましょう） 45

Slide 46

Slide 46 text

補足: "Plan" プロセスに関連するタスクの例自分たちが作ろうとしているものを分析する脅威モデリング（後述）や設計レビューが該当するこの講義の Excersise の内容をイメージしていただければ社内ガイドラインを読み、関連するものがあるか確認することも Plan の一環です 46

Slide 47

Slide 47 text

脅威モデリング？システムを分析して起こりうる脆弱性を見つける、プロアクティブな活動メルカリさんの事例 , 社内プロダクトの事例実施の流れ i. モデル図（DFD など）の作成 ii. 起こりうる課題のブレスト脅威の幅出しとして STRIDE フレームワークを用いたりする iii. リスク分析 DREAD フレームワークによるスコア・順位付け iv. 課題への対応「低減」,「回避」,「保有」,「移転」の検討 47

Slide 48

Slide 48 text

STRIDE フレームワーク？脅威を洗い出す方法論 S poofing（なりすまし）: 攻撃者は、他のユーザーになりすましできるか？ T ampering（改ざん）: 攻撃者は、不正にデータの変更ができるか？ R epudiation（否認）: 攻撃者は、自身の行った行動を否認できるか？ I nformation disclosure（情報漏えい）: 機密情報などにアクセスできるか？ D enial of service（サービス利用不可）: アプリケーションを停止させられるか？ E scalation of privilege（特権の昇格）: 管理者権限などを入手できるか？ 48

Slide 49

Slide 49 text

補足: "Code" プロセスに関連するタスクの例 SAST（Static Application Security Testing, 静的解析）脆弱性を含んだコードを書いていないかをテストするアプリケーション gosec, Brakeman Rails 8 では、Brakeman は標準で導入されるらしいインフラ tfsec, checkov "sast gosec brakeman ... " といったワードで検索すると、この手のまとめが出てきます 49

Slide 50

Slide 50 text

補足: "Test" プロセスに関連するタスクの例 DAST（Dynamic Application Security Testing）実際に動作するアプリケーションに攻撃リクエストを送信する手法 Burp Suite や OWASP ZAP を用いたテスト SAST に比べると、継続的に実施するコストは重い（第三者機関による）脆弱性診断今回の講義で説明したとおりです 50

Slide 51

Slide 51 text

補足: "Monitor" プロセスに関連するタスクの例セキュリティ監視 Security Hub, GuardDuty の棚卸しを行う実態に即した WAF Rule のメンテナンスインシデントレスポンスパッチマネジメント Inspector のようなサービスで、現存するパッケージの把握をする dependabot, renovate で積極的にアップデートしていく 51

Slide 52

Slide 52 text

その他のトピックと、まとめ 52

Slide 53

Slide 53 text

セキュリティの要求は体系化されている ISMS を例に挙げたように、セキュリティの要求は、国や取り扱うデータ等によって規則・基準が存在する個人情報保護法, GDPR, HIPAA, PCI DSS, ... セキュリティチェックシートの項目だって、各々の会社が完全に独自に定義しているわけではなく、「考えのよりどころ」があると考えてよいはず「規格がある」ということを知っていると、何かと有用各種チェックツールの指摘項目の背景を理解出来る、など 53

Slide 54

Slide 54 text

今日の講義をふまえて例えば、「ストレージ暗号化をすべき」という要求の背景について機密性（Confidentiality）に関わる問題なんだな、とわかる（お客様独自の要件ではなく）ISMS でも問われる内容だよね、とわかるこういう要求はまとめて静的解析でチェックできそうだな、という発想に到れる「AWS が管理しているから、ストレージが盗まれることは考えなくてよいのでは？」という疑問に、「内部犯のリスクは捨てきれない」や「防御層を追加している」といった議論ができる例えば、暗号化したスナップショットは、そのスナップショットへの権限以外にも、別途 KMS のアクセス権も必要、とか 54

Slide 55

Slide 55 text

インシデントが発生したら ref: <社内ドキュメントのため省略> 直ちにマネージャに連絡します。これだけは覚えておきましょう。一般的なセキュリティに関連する社内マニュアルは、上記にまとまっているので一読してみてください不安であれば、とりあえず相談してみましょう 55

Slide 56

Slide 56 text

心構え完全な防御は難しいので、どうしてもいつかはインシデントは発生しますいざというときに冷静に対処できるよう、どう対応するかを知っておきましょうセキュリティという分野も、常に勉強です一緒に勉強しましょう 56

Slide 57

Slide 57 text

ギフティにおける課題公開にあたり、社内情報を含むため削除 57

Slide 58

Slide 58 text

まとめ「セキュリティ」の原則と、社内におけるセキュリティ施策の例、 dev はどのようにプロダクトセキュリティに関わるのかを話しました冒頭に述べた、「セキュリティあるある」へのアンサーとしては…… 広範すぎて何をしたらいいか分からない、セキュリティチェックシートの言っている意図が分からない → 「セキュリティ」の原則を知ることで、要求の背景・意図が分かるようにすべての穴を塞ぐことが必須のように感じてしまう → リスクの大小に応じて対応すればよいことが分かった 58