安全なクラウドネイティブ実現へ：内製開発におけるプロダクトセキュリティ強化の軌跡と開発チームとの協調 - CNDT2023
21.3K Views
December 11, 23
スライド概要
Cloud Native Days Tokyo 2023 登壇資料です！
https://event.cloudnativedays.jp/cndt2023/talks/1992
メディア企業でプロダクトセキュリティをやっています。 CISSP/GCIH/GCFR/SANS FOR610, FOR572(Coin holders)/AWS CLF/GCP ACE,PCA,PSE /セキスペ
関連スライド
各ページのテキスト
安全なクラウドネイティブ実現へ 内製開発におけるプロダクトセキュリティ強化の軌跡と開発チームとの協調 2023年12⽉11⽇ 【CNDT2023】⽇本経済新聞社 藤⽥ 尚宏 1
発表者のプロフィール ● ㈱⽇本経済新聞社 セキュリティエンジニア ● 藤⽥ 尚宏 ( @tanafuji_sec ) ● 2022年 ⼊社 ⽇経が⾃社開発するプロダクトのセキュリティを 横断的に⾼める活動を推進。システムエンジニ ア、警視庁サイバー犯罪特別捜査官を経て現職。 ● 趣味 ○ クラフトビール（びあけん３級） 2
プロダクトセキュリティの世界へようこそ プラス‧セキュリティ プラス‧セキュリティ知識について（NISC資料） https://security-portal.nisc.go.jp/dx/plussecurity.html 3
おことわり ● コンテナやSRE的は話題にはほとんど触れていません。 ● 発表内容は個⼈の⾒解に基づくものであり、所属組織を代表す るものではありません。 記載されているロゴ、システム名、製品名は各社及び商標権者 の登録商標あるいは商標です。なお、本⽂および図表中では、 登録商標または商標表⽰は明記しておりません。 4
Purpose 考え、伝える。より⾃由で豊かな世界のために。 Better insights for a better world 日経の理念 https://www.nikkei.co.jp/nikkeiinfo/about/ 5
発表概要（CFPより転記） 内製開発チームが安全なクラウドネイティブ環境を実現するために、プロダクトセキュリ ティチームがどのように連携してきたかに焦点を当て、活動の軌跡と協調の重要性を紹介 します。 パート１ パート２ パート３ 本トークは、プロダクトセキュリティチームのリーダーとしての経験に基づいて⾔及し、 サーバレスで構築するシステムに対する脅威モデリング、セキュリティ⽂化を醸成するた めに取り組んできたSlackによるオープンコミュニケーションなど多岐にわたります。 本トークの視聴者は、セキュリティを意識してクラウド環境構築に取り組みたい⽅や、 開発チームとのコミュニケーションに悩むセキュリティ組織に所属する⽅を想定してお り、プロダクトセキュリティを実践するための有益な知識と洞察を提供します。 中級者向け 6
提唱 DSX （Developer Security Experience） (A→B) セキュリティが保たれているならば、開発者体験がよい (¬B→¬A) 開発者体験がよくないなら、セキュリティが保たれない 7
トークの全体像 導⼊ 本題 ● ⽇経のDevSecOpsの概観 ● チーム⽴ち上げ背景 1876年 中外物価新報の創刊 2013年 ⽇経電⼦版の内製化 2017年 ”爆速化”で話題に ● チームメンバー ● 当時の活動 ● サーバレスの脅威モデリング ● セキュリティ⽂化の醸成 ● セキュリティイベント運⽤ ● 開発者セキュリティ啓発と教育 過去 現在 2020年-2022年 ⽇経IDクラウド移⾏ 2021年 プロダクトセキュリティ チーム発⾜ 2022年4⽉ プロダクトセキュリティ 専任エンジニア⼊社 8
パート１ プロダクトセキュリティチーム 活動の軌跡 9
⽇経 デジタル有料購読者数 🎉 100万を突破 🎉 ⽇経、デジタル購読数100万に 専⾨メディアで法⼈開拓 （2023年12⽉8⽇付, ⽇経電⼦版より） 10
Mission 質の⾼い報道とサービスで 読者‧顧客の判断を助け 世界で最も公正で信頼されるメディアになる To be the most trusted, independent provider of quality journalism to a global community, helping our customers make better decisions. 日経の理念 https://www.nikkei.co.jp/nikkeiinfo/about/ 11
⽇経のプロダクト（例） BtoC BtoB その他サービス ‧ ⽇経電⼦版 ‧ 法⼈向け⽇経電⼦版 ‧ ⽇経マガジン ‧ ⽇経ID（ID基盤、課⾦決済） (PRO, FOR OFFICE) ‧ 各種イベント ‧ ⽇経転職版 ‧ ⽇経テレコン ‧ ⽇経リスキリング ‧ Nikkei Primeシリーズ ‧ ⽇経NEEDS ‧ ⽇経オフィスパス ‧ Nikkei Asia ‧ ⽇経バリューサーチ ‧ ⽇経リスク＆コンプライアンス 内部向け ‧ ⽇経スマートクリップ ‧ ⽇経COMPASS ‧ データ基盤(Atlas) ‧ 統合マーケティング(IMS) 12
チーム⽴ち上げ背景（2021年〜2022年） 背景 ● ⽇経IDのクラウドネイティブ化 ( Lift & Shift ) ➔ 個⼈情報がクラウドに保管されることによるセキュリティ意識の⾼まり チーム構成 ● 全員、開発チームからの”兼務”で招集 グループ⻑ リーダー 半年ごとに交代 メンバー メンバー メンバー バックエンド バックエンド インフラ/SRE バックエンド インフラ/SRE インフラ/SRE 13
発⾜当時の活動（2021年〜2022年） 組織横断的な活動 ● 個別チームへのセキュリティ定例、セキュリティレビューなどのサポート ● 横断的なインシデント調査等の対応（Log4jなど） クラウドセキュリティ ● 予防的、検知的ガードレール実装 (Terraformテンプレート) ● 脅威検出ログ監視基盤構築 ● クラウドアカウント（IAM）管理 ウェブセキュリティ ● 脆弱性⾃動スキャンツールの導⼊ ● CSP(Content Security Policy)の導⼊ など 14
⼊社時の課題感（2022年4⽉頃） “わからないこと”だらけ セキュリティ資料の散在 オンボーディング時にメンバーから１⼈ずつ説明を受ける 組織全体のセキュリティ施策 ノウハウが各チームに閉じている（NotionやQiita Teamを辿れば⾒れる） 属⼈的なセキュリティレビュー 議事録、指摘の履歴しか残っていない 全員”兼務”だからしょうがない 15
”兼務”だからこそ 理解を得ることや、説得への負担が少ない 当事者意識 ● 主務でもセキュリティ意識が⾼くなる ● 主務で感じたセキュリティ課題をセキュリティチームで解決 コラボレーション ● 主務で取り組んだセキュリティノウハウを横展開しやすい ● チーム横断活動が多く社内の⼈的ネットワークを強化できる ● “元”セキュリティチームのメンバーがいることの⼼強さ 専任と兼務のハイブリッドが良さそう 16
着任後に始めたこと チーム活動をドキュメントに集約 ● 過去の業務やセキュリティ⽀援 ● レビューの実施⼿順、レビュー結果 ● 開発プロセスごとのセキュリティ施策 効果 ● 開発T「レビューを相談したいのですが」 ➔ ドキュメントにまとめたので⾒てね！ ● 開発T「新たにこういう取り組みをしまして」 ➔ ドキュメントに書き⾜してくれると嬉しいです！ ⾃然にノウハウを集められる仕組みができた！ 17
ドキュメント執筆時の留意事項 ● ● ● ● 最近読んだ本でおすすめ ドキュメントのカテゴリや想定読者に沿った記述 想定読者の前提知識や情報量によらない記述 ドキュメントはなるべく単体で読めるようにする 可能な限り図や表を⽤いる等、情報を効果的に伝える その他 ● ● ● ● 開発者体験に配慮した記述（仲間意識！） 情報の距離 落とし⽳、他⼭の⽯ 既存資料やリポジトリへのリンク エンジニアのためのドキュメントライティング 著者 ジャレッド‧バーティ他、監訳 岩瀬 義昌 https://pub.jmam.co.jp/book/b622627.html 18
日経のDevSecOps概観 Sec Dev/Ops Dev Plan セキュリティレビュー 脅威モデリング Code SAST コードレビュー （静的アプリケーションセキュリティテスト） Build CI / CD パイプライン Test DAST （動的アプリケーションセキュリティテスト） 脆弱性診断 Deploy Ops Operate クラウドセキュリティテンプレート バグバウンティプログラム Monitor セキュリティ監視(SOC) インシデントレスポンス 19
日経のDevSecOps概観 本日説明 Sec Dev/Ops Dev Plan セキュリティレビュー 脅威モデリング Code SAST コードレビュー （静的アプリケーションセキュリティテスト） Build CI / CD パイプライン Test DAST （動的アプリケーションセキュリティテスト） 脆弱性診断 Deploy Ops Operate クラウドセキュリティテンプレート バグバウンティプログラム Monitor セキュリティ監視(SOC) インシデントレスポンス 20
パート２ サーバレスの脅威モデリング セキュリティレビューから派⽣した取り組み 21
セキュリティレビューの位置づけ 開発チームにとっての”セキュリティ”を⾃分事にする過程 ● “シフトレフト*”の最初の実践フェーズ ● 安全なクラウドネイティブ環境の要は”セキュアな設計” ● 運⽤開始後もセキュリティに関する相談がしやすい関係の⼟壌づくり ● 重箱の隅を突くわけではなく、チーム同⼠が⼀体となって作り上げる * シフトレフトは、システム開発の後⼯程でセキュリティリスクが発覚すること による⼿戻りを避けるために、早期からセキュリティ施策を組み込むこと 22
セキュリティレビューの過去と現在 チーム発⾜当初 現在 ● レビューの流れは⼿探り ● レビューの基本的な流れを資料化 ● 開発チームによる資料共有 ● 開発チームによる資料共有 ● 担当者が各⼈各様のヒアリング ● 脅威モデリングの実施 ←新たに導⼊ ● 質問事項、指摘事項、議事録の⼀覧 ● 質問事項、指摘事項、議事録の書式化 ● 指摘がなくなり社内申請が承認されれば 終了 ● 脅威モデリング結果を社内申請に添付し 承認されれば終了 → 再現の難しさ → 再現性と改善性 23
脅威モデリング ⽇経では、「システムの保護すべき資産と脅威や脆弱性を特定したうえでリ スクへの対処を講じるための⼀連のプロセス」と定義 脅威モデリングの流れ 1. 事前ヒアリング 2. 資産の特定(⻩) 3. 脅威の分析(紫) 4. 対策の検討(緑) 右図は３層アーキテクチャの例 技術書典14「Nikkei Development Book VOL.4」 「第4章 脅威モデリングによるプロダクトセキュリティ強化」より (⾃著、現在は販売終了) https://hack.nikkei.com/blog/tech_book_fest14/ 24
資産の特定 対象のシステムにとって守られるべき資産を特定する 例えば、 ● 個⼈情報や機密情報が含まれたデータベース ● 外部システムのクレデンシャル ● ⽂章や画像データなどの知的財産、ソースコード、アカウント ● 実⾏⽤のコンテナ環境 など 情報セキュリティにおけるCIA(機密性、完全性、可⽤性)の侵害や⾦銭的な被 害を引き起こすようなリソースにフォーカスして列挙 25
脅威の分析⼿法の検討 侵害によって引き起こされる脅威(CIA+α)を分析する ⼿法 STRIDE S T R I D E なりすまし 改ざん 否認 情報漏洩 サービス拒否 権限昇格 クラウドの重⼤セキュリティ脅威 11の悪質な脅威 （2019年, 原著Cloud Security Alliance、訳CSA ジャパン） MITRE ATT&CK （The MITRE Corporation） ⻑所 短所 個⼈的な⾒解 分類が少ないため、まず始めてみ るのにちょうどよい。 分析に時間をかけすぎずに済む。 脅威のシナリオが抽象的であるた め個別に補⾜説明が必要。 「それで全部なの？」が分かりづ らい。 セキュリティに馴染みがない開発 者の場合、実害がイメージしづら く、必然的にセキュリティ担当者 の関与度が⾼くなる。 クラウドを前提としていてかつ、 脅威のシナリオが具体的である。 STRIDEモデルを考慮した設計で ある。 オンプレミスやオンプレミスとク ラウドのハイブリッドには適⽤が 難しい。 脅威を理解するための学習コスト が必要。 クラウドネイティブやサーバレス の脅威モデリングを始めるのに適 している。 クラウドに限らず脅威のシナリオ が網羅的である。 点検項⽬が多いため時間がかかり すぎる。 クラウド以外の要素も多く含まれ るため点検作業が複雑になる。 より⾼度で網羅的なセキュリティ が求められる領域（⾦融‧医療 等）では使えそう。 26
クラウドの重⼤セキュリティ脅威 11の悪質な脅威 他組織で発⽣したインシデントや想定事例を参考に、開発中のシステムに起 こりうる脅威を推定できる。 脅威ごとの整理 ● ● ● ● ● ● 表題の資料, 概要説明より抜粋 https://www.cloudsecurityalliance.jp/site/?p=7968 ビジネスインパクト 要点 想定事例 ガイダンス コントロール STRIDE 27
脅威分析時の留意点 ● アタックサーフェス*に近いところから重点的に分析する ● 常に脅威分析にかけられる時間を考慮する ● 完璧なセキュリティは存在しない、攻撃者の⽬線で検討する ● 当然やってるだろうは通じない、不明なところは確認する * インターネットの表層にさらされて攻撃経路の起点となり得るところ。 IPアドレスとポートの組み合わせ、ネットワーク境界、ログイン画⾯や管理 画⾯のURL、アクセスキーなど。 28
対策の検討 脅威との向き合い⽅を上位から順に検討する。 スイスチーズモデル ● 軽減 ○ 技術選択の幅を狭めないために、多層防御で"対策"を検討する。 ● 受容 ○ 脅威の影響が⼩さい場合、⼯数や期⽇の兼ね合いから⼀時的にリスクを"受容"する。 ● 移転 ○ 脅威の影響が⼤きく、頻度が低い場合、保険加⼊などの”転嫁”を検討する。 ● 回避 ○ セキュリティを理由に”やらない”を決めること。”開発者体験”が悪くなる。 リスクマネジメントの分野(JIS Q 31000:2019 リスクマネジメント－指針)に おいて、リスク対策は軽減/受容/移転/回避の４つに分類される。 29
脅威モデリング（データウェアハウスの例） 下図は構想中のデータ分析基盤を一部抽象化したものです。 対策の⼀例 6 ● Cloud Identity ○ アカウント管理の適正化 1 1 2 3 2 3 3 4 5 1 ○ ⼆段階認証の必須化 4 ○ 監査ログの有効化 1 1 2 3 3 4 ● BigQuery 5 2 ○ ポリシータグによるアクセス制御 4 ● Data Loss Prevention (DLP API) ○ 個⼈情報の⾃動検出により、ポリシータグの付与漏れを検知 【参考】 ⽇本経済新聞社：⽇経電⼦版のアプリ基盤と全社データ分析基盤の刷新で開発 ‧運⽤の負荷軽減とコスト削減を実現 https://cloud.google.com/customers/nikkei/?hl=ja 30
脅威、資産、対策のマッピング ⼯夫：成果物は攻撃者⽬線 ● 分析時は資産→脅威→対策の順 ● ⼀覧表は脅威→資産→対策の順 必要に応じ検討の結果を別表にまとめる 脅威の分析 保護対象の資産 脅威 No 脅威 1 〜 1 データベース侵害 〃 〃 2 データ連携開発⽀ 援ツール侵害 ✔ 3 KMSの侵害 ✔ 11 具体的な脅威 資産 No 資産 アセットの 種類 対策 No 対策 悪意ある第三者に個⼈情報を含むデータ を読み取られる 1 データベース （バッチ⽤） PaaS (BigQuery) 1 権限管理 （BigQuery⽤） 〃 2 データベース （参照⽤） PaaS (BigQuery) 2 ポリシータグによる 個⼈情報アクセス制 御 悪意ある第三者に個⼈情報を含むデータ が書き換えられる、読み取られる 3 データ連携開発 ⽀援ツール PaaS (Dataform) 3 DLPによる個⼈情報 の定期確認 悪意ある第三者に機密情報を読みとられ る 4 KMS SaaS (KMS) … … (略) ✔ ✔ ✔ 対策の検討 31
脅威モデリングの結果 ● 改善提案 ○ シークレット管理やストレージ保護(暗号化、バージョニング）など ● ノウハウの蓄積 ○ 他のチームが実施しているプラクティスや失敗談などを集約 ○ 結果、組織としてのセキュリティ成熟度が⾼まる ● ⼼理的な安全性 ○ 開発者の不安解消 ○ 体系的な点検により仕様変更時も当時の分析結果が⾒れる ○ 内部監査部⾨から信頼を得た ○ セキュリティ監視の際も円滑に連絡できる 32
今後試してみたい脅威モデリング⼿法 Microsoft 公式のAzure Threat Research Matrix (ATRM) 33
［参考］クラウドネイティブセキュリティの始め⽅ 各クラウドに合わせたベストプラクティスが公開されています。 ● AWS ○ Well-Architected フレームワークの 5 本の柱（セキュリティ） ● GCP ○ セキュリティ ベスト プラクティス センター ● Azure ○ Azure セキュリティのベスト プラクティスとパターン 34
パート３ 開発チームとの協調 セキュリティ⽂化の醸成、セキュリティ窓⼝運⽤やバグバウンティ等 35
セキュリティ⽂化の醸成 とにかく社内認知を拡⼤し、相談しやすい雰囲気を作る 徹底したアウトプット主義 ‧ 情報の透明性 Slack Notion ‧ 暗黙知と形式知 Qiita Team 縦横無尽のコミュニケーション ‧ 社内交流 開発プレゼン会、もくもく会、悩み相談会 ‧ グループ間交流 情報交換会、⼈材交流 開発者のためにセキュリティをやっている⼈です！ 36
開発チーム 発信 開発チームとの協調 ● オープンなコミュニケーション 開発チーム プロダクトA セキュリティ：⾼ セキュリティチー ム発信 ● 分散モデル(ref. PSIRT Service Framework) 毎朝ニュース配信 (オープンチャネル) ナレッジ共有 (Notionなど) セキュリティ ベンダ 開発チーム プロダクトB セキュリティ：中 個別⽀援 定期交流 開発チーム プロダクトC ⼀般ウェブサイト 随時相談 審査‧監査 セキュリティ チーム 共通⾔語化 ガイドライン改定 監査部⾨ 37
バグバウンティ（脆弱性報奨⾦プログラム）関連 ● 2022年2回 ● 2023年4⽉ ● 2023年8⽉ 少⼈数招待制バグバウンティ開催 セキュリティ報告窓⼝(RFC9116対応)の設置 学⽣向けバグバウンティイベントの開催 経験できたこと ● 社内で気づくことが難しい脆弱性 ● 開発チームによる事前のハードニング 準備したこと ● 実施に伴う開発チームとの合意や連絡体制（予算含む） ● 報告の受け⼊れ体制、トリアージ⼿順の確⽴ ● 報告から報奨⾦認定までの流れの整理 デジタル庁「政府情報システムにおける脆 弱性診断導⼊ガイドライン」より引⽤ IssueHunt様によるインタビュー記事 38
Webセキュリティ セキュリティ報告窓⼝（security.txt）の公開 （2022年4⽉に公開された技術仕様(RFC9116)への対応） 日経のサービス ②脆弱性発⾒ ③報告先確認 ①設置 日経 日経 デジタル関連部署 日経 デジタル関連部署 デジタル関連部署 ④報告 有志の ホワイトハッカー セキュリティ報告窓口 （セキュリティチーム） 国内外から報告実績あり ⑤共有 経営企画室 （SIRT） ⑥共有 その他部署 海外拠点 等 (* nikkei.com配下) 39
「セキュリティ⼈材」のレベル感 弱 ● セキュリティ初学者：newbies “セキュリティに苦⼿意識がある⼈” ● セキュリティを意識している⼈：aware “セキュリティに関⼼はあるものの、現状ではセキュリティ の知識が限られており、今後その理解を深め、そのスキル を仕事に適⽤するための実⽤的な⽅法を学びたい⼈” 強 ● セキュリティ専⾨家：expert “セキュリティに関する多くのことに精通している⼈” セキュアなソフトウェアの設計と開発（ローレン‧ コンフェルダー 著）より対象読者の定義を引⽤ https://www.shuwasystem.co.jp/book/9784798069753.html 40
セキュリティ啓発と教育 １．独学 ‧ 書籍、資料、勉強会、X(旧Twitter)、Slack ‧ 規格、フレームワーク、ベンチマークを読む ‧ 競技⼤会、CTF(Capture The Flag)への取り組み ２．専⾨教育 ‧ セキュアコーディング研修「KENRO」 ‧ セキュリティ‧キャンプの聴講 ‧ 有償講習（CompTIA、(ISC)²、クラウドセキュリティ等） ３．資格取得 ‧ 情報処理安全確保⽀援⼠ ‧ CompTIA、CISSP等 ‧ クラウド関連資格(AWS/GCP) セキュリティ⽂化の醸成や啓発と教育について、Flatt Security様によるインタビュー記事 各領域のスペシャリストが結集しDevSecOpsに取り組む⽇本経済新聞社のプロダクトセキュリティチーム【プロダ クトセキュリティ組織の作り⽅ #3】#FlattSecurityMagazine 41
まとめ ● DSX（Developer Security Experience）を⾼めるためのチーム活動 ● プロダクトセキュリティチームの活動の軌跡と、開発チームとの協調の重要性 ● サーバレスで構築するシステムに対する脅威モデリング ● セキュリティ⽂化を醸成するために取り組んできたコミュニケーション ● バグバウンティ関連イベントの実施について紹介 ● セキュリティを意識してクラウド環境構築に取り組みたい⽅ ● コミュニケーションに悩むセキュリティ組織に所属する⽅ プロダクトセキュリティの世界に⾶び出しましょう！ 42
アドベントカレンダーのQR ご静聴ありがとうございました！ (2022年度分) 技術ブログ「HACK THE NIKKEI」 https://hack.nikkei.com/advent_calendar/2023/ 43