情報セキュリティ

  1. トップページ
  2. 情報セキュリティ
  3. セキュリティエコノミクス
  4. プラクティス・ナビ
  5. プラクティス5-4 セキュリティバイデザインを標準とする、クラウドベースの開発プロセスの励行

プラクティス5-4 セキュリティバイデザインを標準とする、クラウドベースの開発プロセスの励行

公開日：2026年4月28日

背景

従業員数500名規模の金融系IT子会社であるK社は、Fintechを含む金融系のサービスやプロダクトの開発・実証を行っている。現在、開発プロジェクトの対象はクラウドベンダの提供するIaaS上で運用するものが主流となっている。同社は従来、開発工程で諸機能を実装するタイミングでセキュリティ機能も検討していたが、対応すべき脅威が多様化する中、開発部門の責任者は担当者への負担増や、手戻りによる開発スケジュール遅延等の発生等を課題と感じていた。全社のセキュリティ開発を統括するセキュリティチームとの相談の結果、いわゆる「セキュリティバイデザイン」として企画・設計段階からセキュリティ機能を組み込むことが適切と判断し、自社の標準的な開発プロセスとして規定することとした。

K社の実践のステップ

セキュリティ機能は一般にソフトウェアの主たる目的には含まれないが、かといって後付けで実装しようとすると設計・開発段階まで手戻りが生じることにもなりかねない。近年、セキュリティバイデザインの重要性が認識されつつあるが、企画・設計段階でセキュリティ要件を明確化することは容易ではなく、同社も踏み込んだ検討には至っていなかった。K社のセキュリティチームのリーダーは、開発部門のニーズに合わせた脅威分析を支援することで、次のステップでセキュリティバイデザインの導入に取り組んだ。

  1. ソフトウェアの概念設計フェーズにおいて設計内容が固まった段階で、次ページ図の要領で開発と並行して脅威分析を行う手順を標準的な開発プロセスに追加した。なお、あくまで標準であって、プロジェクトの特徴に応じた個別対応を妨げるものとはしていない。
  2. 運用段階における対策については、インフラチームの協力を得ることで実装するクラウド環境における適切なセキュリティ設定の維持、仕様変更対応やインシデント対応体制等が担保されるようにした。
  3. 現状では上記(1)(2)を通じてセキュリティバイデザインを概ね実践できているが、さらなる効率化を実現するため、ソフトウェアの用途や環境に応じた脅威分析の適切な粒度を見極めるための手法について検討している。

K社の実践内容

K社が設計段階で実践しているセキュリティ対策は次の通りである。

  • 脅威分析にはSTRIDE（次ページ参照）を利用。概念設計段階で作成するDFD（Data Flow Diagram）をもとに、各ポイントでどのようなセキュリティ脅威があるかの洗い出しを実施。洗い出しはセキュリティチームで行うが、ユースケースによって脅威が異なってくることもあることから、必要に応じて設計チームと脅威の想定についてのディスカッションを行っている。
  • セキュリティ対策に関する要求仕様としては、公益財団法人金融情報システムセンターの『金融機関等コンピュータシステムの安全対策基準・解説書』に準拠しつつ、用途別にチェックリストを作成して対応。
  • クラウド環境において実施する対策の選定にはCISベンチマーク（下欄）を使用。これは要求されている対策が具体的で顧客や開発ベンダ等とのコミュニケーションにも使いやすいとの判断による。
  • クラウドが提供するアクセス制御機能やモニタリング機能等を活用。これらの可用性確保に関する保守をクラウドベンダに委ねることでセキュリティ機能の運用の効率化を実現。
  • セキュリティ機能の実装には、対象のクラウドサービス用に業界で用いられているテンプレートを適用することで、利用可能なベンダのセキュリティ機能を活用しながらセキュアな環境構築を行った。
  • 図2-5.3 K社のソフトウェアライフサイクルにおけるセキュリティバイデザイン導入の効果比較は以下のテキスト版をご確認ください。
    図2-5.3 K社のソフトウェアライフサイクルにおけるセキュリティバイデザイン導入の効果比較
図2-5.3 K社のソフトウェアライフサイクルにおけるセキュリティバイデザイン導入の効果比較（テキスト版）

開発フロー

  1. サービス/プロダクトの企画
  2. 機能仕様検討
  3. 設計
  4. 開発・テスト
  5. 運用・保守

従来

セキュリティ対策に関する担当者への負担増、手戻りによる開発遅延などが問題になっていた。

  1. 開発後のセキュリティテストで設計上の問題が発見され、設計・開発をやり直し
  2. 運用開始後、当社想定していなかった脅威が顕在化し、機能仕様から修正

現在

脅威分析自体のコストは大きなものではなく、スケジュール通りの開発、手戻りの削減、計画通りの運用負荷などの効果を発揮

  1. 機能仕様検討が終了した段階で脅威分析を開始
  2. 脅威分析の結果を、設計、開発・テスト、運用計画に反映

参考情報

  • CISベンチマーク
    • 米国の非営利法人Center for Internet Securityが公表している、情報システムの構築・運用における構成要素別のセキュリティ対策のベストプラクティスを定めたガイドライン
  • STRIDE（本URLは現在リンク切れとなっていますが、当該情報は掲載当時の参考情報として記載しています。）
    • https://www.ipa.go.jp/files/000046476.pdf
    • Microsoft が提唱する脅威の分類手法。「なりすまし」「改ざん」「否認」「情報漏えい」「サービス拒否」「特権の昇格」の6種類のカテゴリから脅威を洗い出す手法
前のページへ 次のページへ

更新履歴

  • 2026年4月28日

    新規公開