ほとんどのセキュリティ問題は、最初の git init のずっと前から始まっている。セキュリティの問題は、アーキテクチャの決定や、見落とされた前提条件や、欠落した要件に潜んでいる。計画は、セキュアな開発を始めるべき場所である。ホワイトボードセッションで壊れた認証モデルを発見するほうが、2スプリント後にプロッドの違反にパッチを当てるよりも速い。このセクションでは、最初からセキュリティを考慮して設計する方法を紹介します。このセクションでは、最初からセキュリ ティを意識した設計を行う方法を紹介する。無駄話はありません。博士号は必要ありません。

プレースホルダ画像 画像の説明脅威モデリング、データ分類、安全なユーザーストーリーテンプレートのアイコンをスプリント計画ボードに重ねた設計フェーズのフロー。

開発チームのための軽量脅威モデリング - 博士号も3日間のワークショップも不要

何日もかけてアタックツリーを構築したり、14人の利害関係者と脅威モデリングのワークショップを開いたりする必要はない。ただ立ち止まって、適切なタイミングで適切な質問をするだけでいいのだ。

何が問題なのか？

これが重要な問題だ。トークンが漏れたらどうなるのか？誰かが入力を改ざんしたら？もしユーザーがクライアント側のコントロールをバイパスしたら？あなたの機能の基本的なフローを歩き、穴をあけてください。理想的なユーザーのために設計するのではなく、創造的な悪用から守るのだ。10分でも「もしも」を考えることで、ロジックの欠陥やバリデーションの欠落、明らかな信頼の境界を発見することができる。

クイックウィンSTRIDE-per-Feature、ホワイトボード・セッション

アプリ全体をモデリングする必要はない。新しいものを脅威モデル化すればいい。機能ごとのSTRIDEを試してみよう。5分かけて、その機能がなりすまし、改ざん、情報漏えい、特権の問題、サービス拒否を引き起こすかどうかを尋ねてください。あるいは、ホワイトボードを使ってデータの流れをスケッチしてみよう。誰が何と話すのか？ユーザー入力はどこから入るのか？どこをコントロールすべきか？ゆっくりと線を引くだけで、驚くほど多くのことが見えてくるはずだ。

ユーザーストーリーと要件にセキュリティを組み込む

セキュリティは、アーキテクチャー・ドキュメントやセキュリティ・チームのバックログにあるだけではだめだ。ストーリーの書き方から始まって、開発ワークフローの一部である必要がある。

"ユーザーとして、私は自分のデータが..."

ユーザーストーリーは、期待を書き込むのに最適な場所です。"ユーザーとして、パスワードをリセットしたい "と書くだけではいけません。"ユーザーとして、私はパスワードのリセットが安全で、ブルートフォースから保護されることを望みます。"と書いてみてください。この一文が、レート制限、トークンの有効期限、ロギングのディスカッションの引き金となる。セキュリティは、QAに付け足された後付けのものではなく、完了したことの定義の一部であるべきだ。

データの分類：フォートノックスとシンプルな南京錠の違いを知る

すべてのデータが同じように作成されるわけではありません。ユーザー名のように公開されるフィールドもある。SSNや認証トークンのように、暗号化、アクセス制御、厳密なロギングが必要なものもある。プランニングの際には、次のことを尋ねてみよう：どのようなデータを収集するのか？どこに保存するのか？漏洩した場合の影響は？それに応じてラベルを付ける。これにより、リスクに見合った保護を設計することができる。本格的なデータガバナンス戦略は必要ありません。

安全な開発とは、技術革新を止めることではない。早い段階で適切な質問をすることで、難しいことを後から修正する必要がなくなるのだ。 

コード・フェーズに移り、すべてのプル・リクエストをセキュリティ・インシデントにすることなく、セキュアなロジックを書く方法について話そう。