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

社内向け資料を公開用に編集したものです。
背景情報は https://tech.giftee.co.jp/entry/2024/11/12/101202 をご覧ください。

Transcript

1. dev 補講: プロダクトセキュリティ（公開版） 2024/10 版 1
2. Disclaimer この資料は、社内向けの研修資料スライドをもとに、公開用に修正したものです 背景・補足情報は speakerdeck 概要にある、技術ブログ URL からご確認ください 2
3. この講義の目的 セキュリティにまつわる概念・用語と、その必要性を知る エンジニアとしてプロダクト開発を行っていく上で、 どのようにセキュリティと向き合っていけばよいのかを知る 社内で行われている、セキュリティに関わる業務を知る 困った時に助けを求められるようにする 3
4. 社内のセキュリティ関連タスクの悩み、あるある 一口に「セキュリティに気をつけて」と言われても、 広範すぎて何をしたらいいか分からない お取引先からのセキュリティチェックシートで、 何を求められているのか分からない 「セキュリティ対応」とは、全ての穴を塞ぐことが必須のように考えている ・・・ を、多少緩和したいと思っています 4
5. 話すこと・話さないこと 話すこと セキュリティとは ギフティを取り巻く脅威 セキュリティ対策の考え方・関わり方 話さないこと 具体的な攻撃手法の解説など、詳細な技術解説 概念のみにとどめます 5
6. アイスブレイク: いくつ聞いたことがありますか？ 情報セキュリティにおける CIA とは リスク, 脅威, 脆弱性, といった言葉の違い ランサムウェア DDoS CVE OWASP TOP 10 6
7. なぜ、セキュリティを学ぶのか お客さまの情報を守ることが法律で定められているから 個人情報の保護に関する 法律 （個人情報保護法） https://elaws.e-gov.go.jp/document?lawid=415AC0000000057 あなたも当事者であるから 例えば攻撃により情報漏洩が起こったとき、弊社もある種攻撃の被害者だが、 だからといって弊社に対してユーザが納得するわけではない セキュリティに関連したインシデントは非可逆性が高いから 一度情報が漏洩してしまうと、その情報の回収・消去はできない 一度失った信頼の回復は難しい 7
8. ギフティの直面した脅威 公開にあたり、社内情報を含むため削除 8
9. ビジネスモデルにちなんだ難しさ 公開にあたり、社内情報を含むため削除 9
10. 理論編 「セキュリティ」とは 10
11. セキュリティとは ISO 27001 という国際規格では、以下を「情報セキュリティの 3 要素」としています。 機密性 （Confidentiality）: 権限をもつ人だけが情報にアクセスできること 完全性 （Integrity）: 情報が正確かつ一貫性をもって保持されていること 可用性 （Availability）: 情報が必要なときに利用できること それぞれの頭文字から "CIA" と呼ばれています。これらを守ること全般を「 （情報）セ キュリティ」と呼びます。 さらに 真正性、責任追及性、否認防止、信頼性 を追加したものを重要視することもあ ります。 11
12. Exercise 1: CIA が維持できていない、とは 機密性、完全性、可用性 が維持されていない例をそれぞれ考えてみましょう あなたは EC サイトを運営しています ユーザは EC サイトにログインして、商品を購入することができます ユーザは商品を購入するとき、EC サイトに住所・電話番号を登録しています EC サイトは、ユーザの住所・電話番号を使って、 EC サイトの契約する貸倉庫サービスから商品を配送します 12
13. 例 機密性 （Confidentiality） が維持できていない EC サイトにて、ほかユーザの情報を閲覧できてしまう 完全性 （Integrity） が維持できていない サイト内のリンクが改ざんされ、悪意のあるサイトに誘導される 可用性 （Availability） が維持できていない 大量のリクエストでサービスが停止している 13
14. さまざまな脅威 ref: https://www.ipa.go.jp/security/10threats/10threats2023.html 14
15. 補足: 今日もどこかでインシデントが発生している 定義を知ったことで、"情報セキュリティの CIA" の観点でニュースを読むことが 出来るようになりました 諸機関の出している記事を読むと、日々様々なセキュリティインシデントが発生して いることが分かりますが、 「これは何が侵害されたんだろう？どういう目的で攻撃され たんだろう？」と考えながら読んでみてください。 個人的おすすめは piyolog さん です。 15
16. 補足: 認証制度 きちんとしたセキュリティ体制を整えていることを証明するもの。 これを取得・維持することで業務や契約が円滑になることも多い。 https://giftee.co.jp/security/ にも記載しています。 ISO 27001 （通称 ISMS） 自社内の情報資産やリスクの管理が適切になされ、 仕組みが運用されていることを証明するもの。国際規格。 プライバシーマーク （通称 P マーク） 個人情報の適切な取り扱いを行っていることを証明するもの。日本独自の規格。 16
17. "プロダクト" セキュリティとはなんだろう 弊社では、自社プロダクトに対するセキュリティ（青枠）を指します それ以外の範囲は、コーポレートセキュリティと呼ばれることが多いです PSIRT, CSIRT といった単語と絡めると、守備範囲が分かりやすいかもしれません Web アプリケーションエンジニアとして責務を持つべき内容 です 17
18. 補足: コーポレートセキュリティの取り組みの例 弊社が取得している認証である ISO 27001・プライバシーマーク、 METI・IPA が提供している サイバーセキュリティ経営ガイドライン、お取引先からの セキュリティチェックなどを参考に、対応すべき事柄を決めています。 具体例 PC やモバイル端末などの台帳化（管理すべき資産の識別） 様々な SaaS ツールのアカウント管理（最小権限の付与） VPN 環境の整備（リモートアクセス管理） 委託先の台帳化・月次確認（委託先管理） インシデント対応整備（規定整備や訓練など） セキュリティ教育（意識啓発） 18
19. リスクとは 情報セキュリティにおけるリスク ＝ 資産価値 × 脅威 × 脆弱性 リスク 損害や影響を発生させる可能性 資産価値 情報資産の価値 脅威 システムや組織に危害を与えるセキュリティ事故の潜在的な原因 悪意のある人間（人為/意図的） 、ケアレスミス（人為/偶発的） 、災害（環境的） 脆弱性 脅威によって利用されるおそれのある弱点 プログラムのバグ、バックアップがない DB、予備電源のないデータセンタ 19
20. リスクマネジメント （図は https://it-trend.jp/project_management/article/33-0031 より引用） 20
21. リスク対応 リスクの発生可能性・大きさに応じて、 「低減」 「回避」 「保有」 「移転」 といった選択肢から妥当な対応を検討する 穴を塞いで固める（この図では「低減」に相当）だけが「対応」ではない （図は https://secure-navi.jp/blog/000036 より引用） 21
22. リスク対応 例: 「個人情報を取り扱う機能を開発したい」とき、 「情報漏えい」リスクに対して 低減 リスクの発生可能性を下げる・顕在化したときの影響を減らす対策をとる。 必要以上の情報を取得しない等 回避 リスク要因そのものを取り除く。機能開発自体をあきらめる等 保有 対策を取らないという決定をする。 受け入れられる大きさと判断した・現実的な対策がない等 移転 組織外にリスクを移転する。保険に加入する、専門家にアウトソースする等 22
23. セキュリティ対策の難しさ 攻撃側が有利 防御側は全方位を守らないといけないが、攻撃側は穴を一つ見つけたら勝ち システムが堅牢でも、管理者が弱ければ意味がない やろうと思えば際限がない やりたいことはあくまでビジネスであり、セキュリティ対策ではない なぜ、不届き者のために追加のコストを支払わなければならないのか…… 「やりすぎ」にも「やらなさすぎ」にもならず、守るべきところを守れる よう、 戦略的にセキュリティ対策を実施することが重要 23
24. 多層防御の考え方 "防御側は全方位を守らないといけないが、攻撃側は穴を一つ見つけたら勝ち" どこかに穴があいていても、他の対策でカバーするのが多層防御 オフィスに入るまで: ビル正門の施錠 監視カメラ 警備員 ドア前のカードキーによるロック 鍵によって侵入を防止しつつ、オフィスにそのまま PC を置かないという考え方もこれ というわけで、色々な防御手段を知っておこう 24
25. 実践編 セキュアに開発業務を行う、とは 25
26. dev として何をすればいいのか？ 1/2 日々の技術的なキャッチアップ アプリケーションにおいては、フレームワークを正しく使うことで、 脆弱性を埋め込んでしまうことの多くは防げる インフラも、プラットフォーム側のアップデートに追従すること でバッドノウハウが 過去のものになったり、簡潔・便利・堅牢に使えるようになったりする 常にセキュリティ関連で特別なキャッチアップが必要、というわけではなく、 健全に改善を行っていくことは結果的にセキュリティ対策にもなる例 開発プロセスにセキュリティのタスクを組み込む 安全なコード・設定になっているか、セルフチェック出来るようにする等 26
27. dev として何をすればいいのか？ 2/2 "ギークスーツ" で考える アプリケーションの外である、サービス運用 に脆弱性が潜んでいることも 「取引先社員になりすまし、弊社から機微情報を聞きとろうとする」等も、 あり得ない話ではない サービスによって脅威も対策も様々。biz/dev お互いの目線で考えることが大事 さらに、攻撃者の目線でも考えてみましょう STRIDE のような、脅威を洗い出し、分類するためのフレームワークがあります 参考: https://www.newton-consulting.co.jp/itilnavi/glossary/stride_model.html 27
28. まずは知ることから 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
29. ギフティにおける、プロダクトセキュリティ施策の例 1. 脆弱性診断 リリース前 or 定期で行われる、第三者による診断 2. 社内ガイドライン 社内における、アプリケーション開発のガイドライン 3. インフラにおけるセキュリティガードレールの構築 すべての AWS アカウントに対して行われるセキュリティ対策 構築は Platform Unit ですが、運用は各事業部です 4. セキュアコーディング研修 希望者は KENRO という、 セキュアコーディングの学習サービスを受講できるようにしています 29
30. 脆弱性診断 ref: <社内ドキュメントのため省略> 第三者機関での脆弱性診断 原則、お客様に見せるプロダクトは受けてもらいます 診断の結果、リスクが高いと判定されたものは対応することが原則 リリース前に慌ててやることのないよう、 「やるものだ」ということを覚えておき、スケジュールに組み込んでおきましょう 30
31. 脆弱性診断の結果の例 前述のドキュメントを経由して、実際の報告書が読めます 閲覧権限を絞っているので、見たい方はリクエストしてください <社内情報のため、画像は削除> 31
32. 社内ガイドライン ref: <社内ドキュメントのため省略> 社内における、アプリケーション開発のガイドライン。 プロダクトに原則として要求したい要件を記したドキュメントです 新規プロダクト構築時には、設計前に一通り目を通してもらい、 設計に反映してもらう事を期待しています 32
33. インフラにおけるセキュリティガードレールの構築 ref: <社内ドキュメントのため省略> 弊社のプロダクトインフラのデファクトである AWS について、 「意識せずとも行われるセキュリティ対策」を進めようという施策 33
34. 各種サービスを用いたセキュリティ対策 IAM や VPC といった、基本的なサービスを正しく理解し扱うことはもちろんですが、 AWS で用意されているセキュリティ系サービスを使った対策を別途行っています IAM Identity Center（SSO） Security Hub, Trusted Advisor GuardDuty CloudTrail, AWS Config WAF （Inspector） 34
35. (1/5) IAM Identity Center（SSO） IAM は大きな攻撃表面の一つであるため、IAM user ではなく IAM Identity Center によって各アカウントにログインすることを推奨しています 退職者の IAM user が AWS アカウントに残り続けることを防ぎます 長命なアクセスキーを管理する負担が軽減されます これ自体は、GitHub リポジトリ上で IaC による管理を行っています ref: <社内ドキュメントのため省略> 35
36. (2/5) Security Hub, Trusted Advisor （社内のすべての AWS アカウントで有効化されています） 特定の基準に基づいて、クラウド内のリスクの高い設定を検出します いわゆる Cloud Security Posture Management (CSPM) 36
37. (2/5) Security Hub, Trusted Advisor 例: Security Hub による、Public Read アクセスが有効な S3 バケットの一覧化 37
38. (3/5) GuardDuty （社内のすべての AWS アカウントで有効化されています） EC2 への SSH Bruteforce, S3 バケットの Public access block policy の削除など、 AWS に構築されたリソースに対する脅威を検出するサービス いわゆる IDS（Intrusion Detection System）の一種です 38
39. (3/5) GuardDuty GuardDuty による、振る舞い検知の例 39
40. (3/5) CloudTrail, AWS Config （社内のすべての AWS アカウントで有効化されています） CloudTrail AWS アカウントで行われる API 操作をログに記録するサービス AWS アカウントでは、ほぼすべての操作は API 経由で行われる インフラ操作の 証跡 になります AWS Config AWS アカウント内のリソースの設定を評価するサービス 特定時点のリソースの状況を記録しつつ、問題がないかチェックするようなイメージ Security Hub のデータソースでもあります 40
41. (3/5) CloudTrail, AWS Config CloudTrail に記録されているイベントの例 41
42. (4/5) AWS WAF （利用したい場合、アカウントごとに設定する必要があります） Web Application Firewall 名前の通り、アプリケーション（L7レイヤ）への攻撃を防ぐもので、 ざっくり言うと攻撃っぽい文字列を含むリクエストをブロックしたりします GuardDuty は主にインフラを対象としているので、レイヤが異なります 各自、必要に応じて設定を入れているはずなので、説明は省略します 42
43. (5/5) Inspector （利用したい場合、アカウントごとに有効化する必要があります） インスタンスやコンテナイメージに含まれるパッケージの脆弱性管理を行うもの 「ところで log4j ってどのサーバに入っていたんだっけ？」を解決するもの 43
44. 各事業部が把握しておくべきこと ガードレールとして使用している、各種サービスの存在を知っておきましょう セキュリティガードレールの dev 向けドキュメント にまとめています 特に、Security Hub, Trusted Advisor, GuardDuty は定期的に確認しましょう 44
45. 補足: "DevSecOps" という考え方 ref: https://owasp.org/www-project-devsecops-guideline/latest/00a-Overview 「開発・保守・管理」と「セキュリティ」を別々に考えるとアジリティが 損なわれるため、開発プロセスにセキュリティタスクを組み込む という考え方 （やみくもに全てを取り入れようとせず、うまく取捨選択しましょう） 45
46. 補足: "Plan" プロセスに関連するタスクの例 自分たちが作ろうとしているものを分析する 脅威モデリング（後述）や設計レビューが該当する この講義の Excersise の内容をイメージしていただければ 社内ガイドラインを読み、関連するものがあるか確認することも Plan の一環です 46
47. 脅威モデリング？ システムを分析して起こりうる脆弱性を見つける、プロアクティブな活動 メルカリさんの事例 , 社内プロダクトの事例 実施の流れ i. モデル図（DFD など）の作成 ii. 起こりうる課題のブレスト 脅威の幅出しとして STRIDE フレームワークを用いたりする iii. リスク分析 DREAD フレームワーク によるスコア・順位付け iv. 課題への対応 「低減」,「回避」,「保有」,「移転」の検討 47
48. STRIDE フレームワーク？ 脅威を洗い出す方法論 S poofing（なりすまし）: 攻撃者は、他のユーザーになりすましできるか？ T ampering（改ざん）: 攻撃者は、不正にデータの変更ができるか？ R epudiation（否認）: 攻撃者は、自身の行った行動を否認できるか？ I nformation disclosure（情報漏えい）: 機密情報などにアクセスできるか？ D enial of service（サービス利用不可）: アプリケーションを停止させられるか？ E scalation of privilege（特権の昇格）: 管理者権限などを入手できるか？ 48
49. 補足: "Code" プロセスに関連するタスクの例 SAST（Static Application Security Testing, 静的解析） 脆弱性を含んだコードを書いていないかをテストする アプリケーション gosec, Brakeman Rails 8 では、Brakeman は 標準で導入される らしい インフラ tfsec, checkov "sast gosec brakeman ... " といったワードで検索すると、この手のまとめが出てきます 49
50. 補足: "Test" プロセスに関連するタスクの例 DAST（Dynamic Application Security Testing） 実際に動作するアプリケーションに攻撃リクエストを送信する手法 Burp Suite や OWASP ZAP を用いたテスト SAST に比べると、継続的に実施するコストは重い （第三者機関による）脆弱性診断 今回の講義で説明したとおりです 50
51. 補足: "Monitor" プロセスに関連するタスクの例 セキュリティ監視 Security Hub, GuardDuty の棚卸しを行う 実態に即した WAF Rule のメンテナンス インシデントレスポンス パッチマネジメント Inspector のようなサービスで、現存するパッケージの把握をする dependabot, renovate で積極的にアップデートしていく 51
52. その他のトピックと、まとめ 52
53. セキュリティの要求は体系化されている ISMS を例に挙げたように、セキュリティの要求は、 国や取り扱うデータ等によって規則・基準が存在する 個人情報保護法, GDPR, HIPAA, PCI DSS, ... セキュリティチェックシートの項目だって、各々の会社が完全に独自に 定義しているわけではなく、 「考えのよりどころ」があると考えてよいはず 「規格がある」ということを知っている と、何かと有用 各種チェックツールの指摘項目の背景を理解出来る、など 53
54. 今日の講義をふまえて 例えば、 「ストレージ暗号化をすべき」という要求の背景について 機密性（Confidentiality） に関わる問題なんだな、とわかる （お客様独自の要件ではなく）ISMS でも問われる内容だよね、とわかる こういう要求はまとめて静的解析でチェックできそうだな、という発想に到れる 「AWS が管理しているから、ストレージが盗まれることは考えなくてよいので は？」という疑問に、 「内部犯のリスクは捨てきれない」や「防御層を追加してい る」といった議論ができる 例えば、暗号化したスナップショットは、そのスナップショットへの権限以外にも、 別途 KMS のアクセス権も必要、とか 54
55. インシデントが発生したら ref: <社内ドキュメントのため省略> 直ちにマネージャに連絡します。これだけは覚えておきましょう。 一般的なセキュリティに関連する社内マニュアルは、 上記にまとまっているので一読してみてください 不安であれば、とりあえず相談してみましょう 55
56. 心構え 完全な防御は難しいので、どうしてもいつかはインシデントは発生します いざというときに冷静に対処できるよう、どう対応するかを知っておきましょう セキュリティという分野も、常に勉強です 一緒に勉強しましょう 56
57. ギフティにおける課題 公開にあたり、社内情報を含むため削除 57
58. まとめ 「セキュリティ」の原則と、社内におけるセキュリティ施策の例、 dev はどのようにプロダクトセキュリティに関わるのかを話しました 冒頭に述べた、 「セキュリティあるある」へのアンサーとしては…… 広範すぎて何をしたらいいか分からない、 セキュリティチェックシートの言っている意図が分からない → 「セキュリティ」の原則を知ることで、要求の背景・意図が分かるように すべての穴を塞ぐことが必須のように感じてしまう → リスクの大小に応じて対応すればよいことが分かった 58