システム開発セキュリティ｜政府ガイドラインを超訳！「手戻りさせない」開発の鉄則

はい、承知いたしました。 ご指示に基づき、出典に関する記載部分をすべて指定のボックス形式で囲ったものを以下に出力します。 Generated html

システム開発を進める中で、「セキュリティ対策、何から始めれば…」と悩んだ経験はありませんか。

特に、専門用語が並ぶガイドラインを目にすると、どこから手をつければ良いのか分からなくなりがちです。

実は、対策を後回しにした結果、開発の最終段階で手戻りが発生し、開発の遅延や修正コストの大幅な増加につながってしまうケースは決して少なくないのです。

こうしたリスクを避け、安全なシステムを効率的に作る鍵こそ、開発の初期段階でセキュリティを組み込む「セキュリティ・バイ・デザイン」という考え方です。

この記事では、数ある政府の指針の中でも、特に実践的でシステム開発の現場に寄り添った内容である「デジタル社会推進実践ガイドブック DS-200 政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」に焦点を絞り、その要点を紐解きながら、開発現場で本当に役立つ「セキュリティ・バイ・デザイン」の実践ポイントを分かりやすく解説します。

読み終える頃には、あなたのプロジェクトで次に何をすべきか、その具体的なステップが見えているはずです。

まずは基本から！セキュリティ・バイ・デザインの考え方とは？

「セキュリティ・バイ・デザイン」と聞くと、何か特別なツールを導入したり、専門家だけの難しい話に聞こえるかもしれません。

しかし、その本質は「システム開発の企画・設計段階から、あらかじめセキュリティを考慮した仕組みを組み込んでおく」という、きわめてシンプルな考え方です。

従来のように、開発がすべて完了してから対策を行うやり方では、手戻りやコスト増大を招くだけでなく、巧妙化するサイバー攻撃にも対抗できません。

この非効率な状況を打開するのが、セキュリティ・バイ・デザインなのです。

 

では、この考え方を具体的にどう開発現場に落とし込めば良いのでしょうか。

その強力な道しるべとなるのが、国が示すガイドラインです。

ただし、政府からはさまざまなガイドラインが公表されていますが、中には理念的で、すぐに具体的なアクションに繋げにくいものも少なくありません。

そこでこの記事では、数ある指針の中から、特に開発ライフサイクルの各工程で「誰が・何を・いつやるべきか」が明確に示され、実践的だと評価されている「DS-200」に焦点を絞って解説します。

このガイドラインを読み解くことが、あなたのプロジェクトでセキュリティ・バイ・デザインを実践するための、もっとも確実な近道となるはずです。

企画・設計という開発の最も早い段階からセキュリティ要件を組み込むことで、品質・コスト・納期のすべてにおいてメリットをもたらす、いわば「良い製品を作るための本質的な開発思想」と言えます。

国際的なアプリケーションセキュリティの指標である「OWASP Top 10 2021」でも、新たに「A04:2021 – 安全でない設計（Insecure Design）」が脅威の上位に組み込まれ、この考え方の重要性は世界的な潮流となっています。

あわせて読みたい

OWASP TOP10 とは？対策必須のリスクと費用対効果を最大化する対策

「うちのWebシステムのセキュリティ、本当にこれで大丈夫なのかな…？」 「Webアプリのセキュリティ対策、何から手をつければいいんだろう…？」 Webアプリケーションの開発や運用に携わっていると、こんな不安を感じることはありませんか？ セキュリティ対策は、今や避けて通れない重要な課題ですよね。

政府ガイドラインの要点！セキュリティ・バイ・デザイン6つの基本方針

それでは、具体的にガイドラインの中身を見ていきましょう。

ガイドラインでは、「セキュリティ・バイ・デザイン」を実践するための基本方針として、以下の6つが示されています。 ここでは、それぞれのポイントを「つまり、どういうことか？」という視点で分かりやすく解説します。

1. 経営者のリーダーシップとリスク分析が全ての始まり

セキュリティ対策には、コストも時間もかかります。

現場の開発者だけで「やりましょう」と声を上げても、予算や人員の確保は困難です。

だからこそ、経営者がその重要性を理解し、リーダーシップを発揮して全社的に取り組む姿勢を示すことが、すべての始まりです。

その上で、自分たちのシステムにとっての「リスク」とは何かを具体的に洗い出します。

「顧客情報が漏洩すること」が最大のリスクなのか、「サービスが停止すること」が最大のリスクなのか。守るべきものの優先順位を明確にすることで、限られたリソースをどこに集中させるべきかが見えてきます。

2. 開発委託先や利用サービスも含めたサプライチェーン全体の安全確保

自社のコードがどんなに安全でも、利用している外部のコンポーネントに脆弱性があれば、そこが攻撃の侵入口になり得ます。

事実、IPAが発表した「情報セキュリティ10大脅威 2024」でも、「サプライチェーンの弱点を悪用した攻撃」は組織向け脅威の第2位にランクインしており、自社だけでなく取引先や利用サービスも含めた全体のリスク管理が欠かせません。

3. 「侵入される前提」で考える多層防御の考え方

例えば、城の防御を考えてみてください。

城壁だけで守るのではなく、堀があり、石垣があり、いくつもの門が構えられています。

どれか一つが突破されても、簡単には中心部にたどり着けないようになっています。

システムのセキュリティもこれと同じです。

ネットワークの入り口での防御（ファイアウォール）、サーバーへのアクセス制限、データの暗号化、不正アクセスの監視など、複数の異なる対策を組み合わせることで、もしもの時にも被害を最小限に抑えることができます。

4. コストを抑える鍵は「シフトレフト」にあり

これが、まさにセキュリティ・バイ・デザインの核心です。

建物の設計図が完成してから「耐震性が足りないので柱を増やしてください」と言われたら、設計を根本からやり直す必要があり、大変な手間とコストがかかります。

システム開発も同じで、実装やテストの段階で重大な設計上の欠陥が見つかると、その影響は計り知れません。

早い段階で対策を行うほど、修正コストは劇的に抑えられます。

5. 一度作って終わりではない！変化への備えと継続的な改善

具体的には、不正アクセスを検知するためのログ監視の仕組みや、脆弱性が見つかった際に速やかにパッチを適用できる運用体制などを、開発段階から想定しておくことが大切です。

事実、IPAの「情報セキュリティ10大脅威 2024」では、脆弱性情報が公開された後に攻撃を仕掛ける「公開された脆弱性の悪用」が常に上位に入っており、リリース後の継続的な脆弱性管理がいかに重要かを示しています。

6. もしもの時に被害を抑えるインシデント対応計画

実際に、IBM社の調査レポートによれば、サイバー攻撃を受けてからその侵害を発見し封じ込めるまでに要した日数は、平均で277日（約9ヶ月）にも上ったといいます。

事前の計画や訓練がなければ、被害がどこまでも拡大してしまうリスクがあるのです。

【実践編】開発フェーズごとのセキュリティ実践ポイント

さて、ここからはより実践的な内容に入っていきましょう。

6つの基本方針を踏まえ、実際のシステム開発ライフサイクル（企画から運用まで）の各フェーズで、具体的にどのようなセキュリティ対策を行えばよいかを見ていきます。

なぜ「シフトレフト」が重要？データが示すコストとリスク

これから各開発フェーズでの具体的なポイントを解説しますが、その前に、なぜ「シフトレフト（上流工程での対策）」がこれほど大切なのかを、データからご紹介します。

これらのデータは、「開発の後工程で対応しようとすること」の非効率さと限界を示しています。

この記事を読んでいる皆さんと私たちのゴールは、この負の連鎖を断ち切ることです。

【企画】リスク分析と管理体制の構築

プロジェクトの開始地点で「自分たちのシステムには、どのような脅威が存在し、何を重点的に守るべきか」を明確にする

これが、この後の全工程の土台となります。

このフェーズでは、まず自社のシステムがどのような情報を扱い、誰が利用し、他のどんなシステムと連携するのかといった全体像（システムプロファイル）を整理します。

その上で、「STRIDE」のような脅威モデリングのフレームワークを参考に、想定される脅威を網羅的に洗い出します。

「情報セキュリティ10大脅威 2024」で挙げられているような標的型攻撃やランサムウェアといった脅威を自分たちのシステムに当てはめ、「もし攻撃されたらどうなるか？」と具体的にシミュレーションしてみることで、初めて具体的なリスクが浮き彫りになります。

【要件定義・設計】セキュリティ要件を設計に落とし込む

洗い出した脅威に対して、「どのような対策をとるか」という具体的なセキュリティ機能を設計に落とし込む

このフェーズでは、「多層防御」の考え方に基づき、認証・認可（アクセス制御）の方式、暗号化の対象と方式、監視のために取得すべきログの内容といった、具体的なセキュリティ要件を定義し、設計書に明記します。

「OWASP Top 10 2021」で脅威の第1位となっている「アクセス制御の不備」が示すように、要件定義の段階で「誰が、何に、どのようにアクセスできるか」を厳密に定義し、それを設計に反映することがきわめて大切です。

【実装】脆弱性を作り込まないセキュアコーディング

安全なコーディングルールを守ることが、脆弱性を作り込まないための鍵

どんなに素晴らしい設計図があっても、現場の工事がいい加減では安全な建物は建ちません。

実装フェーズも同様で、セキュアコーディングの原則を守ることが不可欠です。

たとえば、IPAが公開している「安全なウェブサイトの作り方」や、OWASPが提供する「チートシートシリーズ」などを参考に、組織としてコーディング規約を定め、それに従って開発を進めるとよいでしょう。

特に、SQLインジェクションやクロスサイト・スクリプティングといった代表的な脆弱性を生まないための「入力値の検証（バリデーション）」や「出力値のエスケープ」は、必ず徹底すべき基本中の基本です。

【テスト】リリース前の最後の砦！脆弱性診断

設計通りに安全なコードが書かれているか、専門家の目で厳しくチェックすること

テストフェーズでは、機能が要件通りに動くかを確認するだけでなく、セキュリティの観点からのテストも欠かせません。

ここで見逃されていた脆弱性を発見した場合には、リリース前に修正します。

ツールによる機械的な診断（SAST/DAST）も重要ですが、それだけでは攻撃者の巧妙な手口や、ビジネスロジックの盲点を突いた攻撃を防ぎきることは困難です。

だからこそ、リリース前の「最後の砦」として、経験豊富な専門家が攻撃者の視点でシステムの弱点を洗い出すペネトレーションテスト（脆弱性診断）が、極めて重要なのです。

株式会社アイ・エフ・ティは、1,000件以上の診断実績で培った豊富な知見とノウハウを元に、ツールでは発見困難な脆弱性まで深く掘り下げて特定します。

単に問題点を指摘するだけでなく、開発現場がすぐに対応できる具体的な改善策まで踏み込んで提案することで、皆さんのシステムをより安全な状態へと導きます。

【運用】継続的な監視と速やかな対応体制

システムをリリースした後も、セキュリティの戦いは続きます。

新たな脆弱性が見つかれば、速やかにセキュリティパッチを適用する必要があります。

また、システムのログを常に監視し、不審なアクセスの兆候がないかを確認し、インシデントの発生を早期に検知する体制も欠かせません。

まとめ：セキュリティ対策は次のステージへ、開発プロセスからの変革が鍵

この記事では、政府のガイドラインを基に、システム開発における「セキュリティ・バイ・デザイン」の重要性と、具体的な実践方法を解説してきました。

もはやセキュリティ対策は、開発の後工程で付け加えるコストではなく、手戻りを防ぎ品質を向上させるための重要な投資です。

この記事で解説したポイントを、ぜひあなたのプロジェクトでも意識してみてください。

今回解説した「セキュリティ・バイ・デザイン」を実践することで、手戻りのリスクは大幅に削減できるはずです。

しかし、「本当に自分たちの対策は万全だろうか？」「設計や実装段階での見落としはないだろうか？」といった懸念は、どうしても残るものです。

その最後の不安を解消し、自信を持ってシステムをリリースするための最終チェックが、専門家による脆弱性診断です。

株式会社アイ・エフ・ティは、1,000件以上の診断実績を持つ脆弱性診断のプロフェッショナルです。

お客様のシステムに潜むリスクを攻撃者の視点で洗い出し、具体的な改善策までご提案します。

「自社のセキュリティレベルを客観的に把握したい」

「リリース前の最終確認を専門家に頼みたい」

そんな時は、ぜひ一度私たちにご相談ください。