セキュリティ視点以外の重要な脅威分析

Transcript

1. セキュリティ視点以外の 重要な脅威分析 工藤 由美 2025/1/29 脅威モデリングイベント
2. トピック一覧 • 脅威モデリングとの出会い • 様々な視点における脅威 • ビューとパースペクティブ • 価値駆動との相性
3. 自己紹介 • 氏名:工藤 由美 • 所属:2月よりYumemiビジネスアーキテクトチーム • 特技:抽象化、モデリング • 趣味:音楽聴くor編曲、方法論構築 • 好き:ベビパンが⿁好き
4. 防衛案件etc案件に入る。 初のアーキテクト案件 2022 年11月 品質を考慮する際にリスクベー スで考慮した方がいいと気づく。 2023 年5月 脅威モデリング初対面 「DDDっぽい!」と感動 2023年8月末 脅威モデリングの考えを 案件に取り入れてみる 2023 年10月～ チートポと無意識に組み合わ せて使っていて効果を感じ始 めた。 2024 年 2月 価値を支えるものとして脅 威モデリングという価値観へ 脅威モデリングとの出会い
5. セキュリティ観点だけでなく、 他の品質観点などからも複合的に考えた上で、 全体最適な目線でリスク対策が考えられるようになりたい。 【届けたいセグメント】 特定の品質観点に偏って脅威モデリングしている人 この登壇の目的
6. 様々な視点に おける脅威
7. 経営上の脅威 必要物資が届かない →価値の流れが滞り納期遅延 →売上が出ず事業崩壊
8. • 構築したシステムが大量のCO₂排出してしまう • 許容できないほどの有害物質を排出してしまう • システムが大量の電力や水を消費してしまう 環境リスク系の脅威
9. 効率性・・・ 該当システムを利用することで、 業務資源(時間・作業要員・エネルギー・材料) がどのくらい効率的なのか? • システムを導入したのに、作業時間も材料、人的コストetcが削減でき ていない → 運用者などの認知負荷増大につながる 効率性(efficiency)の脅威
10. • 法律に違反してしまっていて、そもそもリリースできない。 • リリース後に違反していることが発覚し、訴えられる。 法律上の脅威
11. • 複雑で理解しづらいコードによってデリバリーが遅くなってしまう • テストが不十分であり、リファクタリングができない • 依存関係が複雑で、変更やアップグレードの際に予期せぬ問題発生 • 重複コードが大量生産されることで、メンテコストが増えてしまう • 仕様変更の際の影響範囲がシステム広範囲に渡ってしまう 保守性における脅威
12. • 本当はリアルタイムな整合性が求められるのに、不整合な時間がある • 分散型アーキになっていることで、トランザクション管理がΩ＼ζ°)ﾁｰﾝ • 大事な業務データが消えてしまった、、、 Ω＼ζ°)ﾁｰﾝ これ以外にもいろいろあるけど、 スライド増えるの嫌だから、一部に抜粋しました。 業務データにおける脅威
13. • ベテラン開発者が風邪でダウンしてしまい納期遅延可能性が増加 • ステークホルダーの抜け漏れ←めっちゃある • ステークホルダーの重要な関心の変化に気づけない • プログラマーに対してあまりにも認知負荷がかかるほどの要件 • 保守担当者がモチベを削がれるような意図不明なコード • (外出先で作業して機密情報がダダ洩れ) PM系の脅威
14. つながる世界のソフトウェア品質ガイド あたらしい価値提供のための品質モデル活用のすすめ 利用時品質、製品品質、データ品質が 副特性まで、構造化されて説明されている。 品質測定量の算出式も書かれているのでオススメ。 参考文献
15. ステークホルダーごとの視点が異なる脅威であっても、 抽象度や見る角度が異なるだけ。 それらは互いに密接に関連しあっている。 それを図で可視化するの大事! でないと個別最適に走りがち & 矛盾に気づきにくい。 脅威同士は密接にかかわっている
16. セキュリティだけとか、保守性の観点だけで脅威モデリングを行うと →ほぼ確実に個別最適な視野に陥ってしまう。 まずは全体をマクロに俯瞰した脅威モデリングが必要。 →複数の品質評価軸で俯瞰して考える。 個別最適に陥らないために
17. セキュリティはSTRIDEやらDREADなどのフレームワークがある。 しかしながら他の品質特性では見かけない。 そこで我流で無理やり編み出した便利な思考の型を紹介。 でも、Sec以外の品質における脅威分析FWない
18. 具体的なHowでシュ Howを技術的なものと 組織体制に分けて話しマシュ
19. 具体的なHow 技術的な術編
20. 効果を保証できるものではないです。 ただし、今からの図解ベースでのステークホルダーとの対話を通して、 以下のことが可能になります。 • 相手の言語化できていないものを可視化すること • 相手及び自分たちの認知領域を広げること • それによってより本質的に避けたいと思う脅威のあぶり出し ※超主観です
21. ステークホルダーにとっての 価値を起点として各要求を出す 価値駆動型の方法論。 (引用元:匠BusinessPlace) これをパクって、不安駆動で 脅威モデリングを行います。 匠メソッド
22. 組織内部のステークホルダー • 経営者 • オペレーション担当者 • 運用者 • 開発者 • QAさん • セキュリティエンジニア • データエンジニア 組織外部のステークホルダー • エンドユーザーさん • 資金提供者 • 物資の提供業者(外部SaaS など含む) • 将来的なエンドユーザー まずはステークホルダーを網羅、、、
23. 先程の組織内外にわけて ステークホルダーを網羅するのもいいが、 抜け漏れが起きやすい。 網羅しても各ステークホルダーの 関心の視座の高さもわかりにくい。 →視座や視点が整理されたFWに頼る でも何もない状態で網羅は難しい
24. 便利な思考の フレームワーク
25. エンタープライズ全体を 経営～システムリソースまで 抽象～具体までの一気通貫の トレーサビリティを取りやすくするための アーキテクチャフレームワーク。 抽象度を合わせやすい!! 詳しくは私のQiitaのUAF記事へ。 ☆Unified Architecture Framework (UAF)
26. 組織内部のステークホルダー • 経営者や事業責任者 • オペレーション責任者 • サービスマネジメント担当者 • 運用者 • 開発者、データエンジニア、QA • PM、PdM 組織外部のステークホルダー Strategic Operational Services Personnel Resource Project ステークホルダーの抜け漏れや関心の強い視座が認知しやすい。 • 資金提供者 • 物資の提供業者 • 現在&将来的なエンドユーザー • 外部ベンダー ①各階層で内外に分けてステークホルダーを網羅
27. • シチュエーション • 手段 • 脅威の言葉 (安心して住めるので嬉しい) を全て脅威記述に盛り込む。 手段には、特に重要な品質が わかるような文章を書く。 その際に意識したいのは、次のビューとパースペクティブ ②脅威記述
28. システムアーキテクチャ構築の原理より引用 • 機能はシステムユースケースなど • 情報はデータの関心系(ER、DFDで表現) パースペクティブは品質系。 ※図のビューやパースペクティブはごく一部。 (機能、情報、運用は絶対マスト) ※各グリッドの抽象度には触れられていない。 よってUAFとセットで使うと便利。 ☆ビューとパースペクティブ
29. • 機能的ビューの要求分析ツリーと情報ビューの要求分析ツリーでわけて 考えて あとから融合する。 • データエンジニアとは情報ビューで議論したり。 観点を分けて後から融合する
30. • トップダウンで脅威記述 • ボトムアップに他の品質軸での脅威記述 両方からの折衷式で定性的に優先度付けて 折衷で脅威を決める
31. 影響範囲とかは可視化されていないとわかんな～い。 誰にとっての脅威を放置すると 他の誰にとっての脅威が起きるか という因果関係モデルを この図で認識揃える。 (ステークホルダーの視座の抽象度は揃える。) 要求定義の段階でリスクへの対策の 矛盾に気づきやすい。 要求分析ツリーの作成
32. 具体的なHow 組織体制
33. チームトポロジー ×脅威モデリング
34. ユーザに対して 「素早く」「頻繁に」「安定的に」 価値を届けたい時に、 組織を構成する各チームが ・それぞれそんな責務を持ち ・どんな連携モードを取るのか? をデザインパターン的にまとめた 組織設計の思想。 チームトポロジーの概要説明
35. ストリームアラインド以外は、 ストリームを支援するチーム と覚えとけばいい。 ・コラボ→別チームと協同状態 ・XaaS→別チームと分業状態 チームの代表者がAPI接続点として 振舞う。 4つものチームタイプと3つの連携モード
36. ①個別のチーム(コンポーネント)内における脅威だけ見ていても、 連携させたときの脅威は見えてこないから。 ②複数の品質特性視点で脅威の考察できる兵はおらん! ゆえにストリームアラインドチームが複数の視点で考察できるように、 他３タイプのチームが支援する。 ③コンウェイの法則→次ページ なぜチームトポロジー×脅威モデリングなのか?
37. システム設計する組織は、組織のコミュニケーション構造をコピーした システムアーキテクチャを生み出す。 ようは、 組織とシステムアーキテクチャは 互いに強い相互作用力学が働いている。 コンウェイの法則
38. 実際、防衛の案件でこれを意識した コミュニケーションパスの設計したら、 以下の効果が得られた。 ・ファシリをするイネイブラーさんが自ら現れた ・肌感覚的にチーム全体がマクロとミクロ レベルでのリスク対策が考えられるようになった。(具体と抽象脅威モデリング) チートポ脅威モデリングを行った実際の効果
39. • チームのタイプや連携モードは固定ではなく、状況に応じ動的に変化する。 • イネイブリングモデラーはストリームアラインドを自律させるため、いつかは別れあり。 • 結局、他チームとの連携は必須だからマトリクス型組織体制が必要。 • デザインパターンやっちゃいけないあるあるのように、パターンに当てはめて組織設計せ よという意味ではない。そのチームがどの責務タイプなのか? どの連携タイプで他チー ムと結合されているのか?を考えやすくするパターンと思っておけばいい。 注意点リスト
40. 1: 匠メソッド式に 脅威同士の関係性 を構造化 2: チートポ連携して 脅威モデリング 重要なポイント のまとめ
41. • 脅威の構造化をして脅威同士の関係性を可視化 • チームトポロジー×脅威モデリング 行動要請
42. セキュリティポリシーの 設計や運用の際に必要な 設計原則についてお話しできたらいいな。 次回発表するとしたら
43. Qiita:せやかて駆動 @Kudo_pandada Twitter アジャイルアーキテクト ありがとうございました!