.png)
ほとんどのセキュリティ問題は、最初のgit initよりもずっと前から始まっています。それらはアーキテクチャの決定、見落とされた前提、不足している要件に組み込まれています。セキュアな開発は計画段階から始めるべきです。それは楽しいからではなく、コストが低いからです。ホワイトボードセッションで壊れた認証モデルを発見する方が、2スプリント後に本番環境の侵害をパッチするよりも迅速です。このセクションでは、最初からセキュリティを考慮した設計方法を紹介します。煩わしくない軽量な脅威モデリングの実施方法、セキュリティに焦点を当てたユーザーストーリーの作成方法、プロのようにデータを分類する方法を学びます。無駄な情報はありません。博士号も不要です。
プレースホルダー画像: 画像説明: スプリント計画ボードに重ねられた、脅威モデリング、データ分類、セキュアなユーザーストーリーテンプレートのアイコンを含む設計フェーズのフロー。
開発チーム向けの軽量な脅威モデリング – 博士号や3日間のワークショップは不要です
アタックツリーの構築に何日も費やしたり、14人の関係者と脅威モデリングワークショップを実施したりする必要はありません。適切なタイミングで立ち止まり、適切な質問をするだけでよいのです。
何が問題になりうるか？
これが重要な質問です。トークンが漏洩したらどうなりますか？誰かが入力を改ざんしたらどうなりますか？ユーザーがクライアントサイドの制御をバイパスしたらどうなりますか？機能の基本的なフローをたどり、そこに欠陥がないか探してください。理想的なユーザーのために設計しているのではなく、巧妙な悪用から防御しているのです。たった10分間の「もしも」という思考でも、ロジックの欠陥、検証の漏れ、または明白な信頼境界を捕捉できます。
即効性のある対策：STRIDE-per-Feature、ホワイトボードセッション
アプリケーション全体をモデリングする必要はありません。新しい部分だけを脅威モデリングしてください。STRIDE-per-featureを試しましょう。5分間かけて、その機能がスプーフィング、改ざん、情報漏洩、権限の問題、またはサービス拒否を引き起こすかどうかを問いかけてください。あるいは、ホワイトボードを使ってデータフローをスケッチしましょう。何が何と通信しますか？ユーザー入力はどこから入りますか？どこで制御を行うべきですか？ただ立ち止まって線を描くだけで、どれだけ多くの問題を発見できるかに驚くでしょう。
ユーザーストーリーと要件へのセキュリティの組み込み
セキュリティは、アーキテクチャドキュメントやセキュリティチームのバックログだけに留まるべきではありません。ストーリーの書き方から始めて、開発ワークフローの一部である必要があります。
"ユーザーとして、私のデータが...であることを望みます"
ユーザーストーリーは、期待を組み込むのに最適な場所です。単に「ユーザーとして、パスワードをリセットしたい」と書くだけでなく、「ユーザーとして、パスワードリセットが安全であり、ブルートフォース攻撃から保護されていることを望む」と試してみてください。この一文が、コードが書かれる前にレート制限、トークン有効期限、およびロギングに関する議論を引き起こします。セキュリティは、QAに後付けされるものではなく、「完了の定義」の一部であるべきです。
データ分類: フォートノックスが必要なものと、シンプルな南京錠で済むものを知る
すべてのデータが同じ価値を持つわけではありません。ユーザー名のような一部のフィールドは公開されています。SSNや認証トークンのようなその他のデータは、暗号化、アクセス制御、厳格なロギングが必要です。計画段階で、どのようなデータを収集しているか、どこに保存されているか、漏洩した場合の影響は何かを問いかけましょう。それに応じてラベル付けしてください。これにより、リスクに見合った保護を設計できます。本格的なデータガバナンス戦略をすぐに導入する必要はありません。少しのラベリングと常識があれば十分です。
セキュア開発はイノベーションを止めることではありません。それは、早期に適切な質問をすることで、後になって困難な問題を修正する必要がなくなるようにすることです。
コードフェーズに移り、すべてのプルリクエストをセキュリティインシデントに変えることなく、安全なロジックを記述する方法について説明します。
