キヤノンMJ/サイバーセキュリティ情報局

システムの企画・設計の段階からのセキュリティの考え方「セキュリティ・バイ・デザイン」とはなにか

  • この記事をはてなブックマークに追加
  • 本文印刷

本記事はキヤノンマーケティングジャパンが提供する「サイバーセキュリティ情報局」に掲載された「セキュリティ・バイ・デザインとは？安全なプログラミングの要点をおさらい」を再編集したものです。

　あらゆる組織がサイバー攻撃の標的になり得る昨今、システムの企画・設計の段階からセキュリティ対策を講じる「セキュリティ・バイ・デザイン」の考え方が注目されている。この記事では、ウェブサイトやウェブアプリケーションの運営者に向けて、セキュリティ・バイ・デザインの概要や構成要素、参照するべき情報を解説する。

セキュリティ・バイ・デザインとは

　ウェブサイトやウェブアプリケーションは、絶えずサイバー攻撃の脅威にさらされている。以前から用いられている手法から、複雑化・巧妙化した最新のものに至るまで、その攻撃手法は多岐にわたる。近年の巧妙化かつ複雑化した攻撃を踏まえ、開発・運用に必要なコストを抑えながらも、適切な対策を講じていかなければならない。

　そうした対策のひとつとして、セキュリティ・バイ・デザイン（Security by Design）という考え方が提唱されるようになった。セキュリティ・バイ・デザインとは、システムの企画・設計の段階からセキュリティ対策を講じる方法だ。運用後、インシデントが発生してから事後的に対応するのではなく、開発の段階からセキュリティの観点でソフトウェアの品質を確保し、脆弱性が入り込むリスクを軽減しようとする試みと言える。

　IPAが発行している「セキュリティ・バイ・デザイン導入指南書」では、設計・開発・テスト・運用の各フェーズでのセキュリティ対策コストを試算している。例えば、設計時のセキュリティ対策コストを1とした場合、開発局面では、その6.5倍に膨らむとされる。さらに、テスト局面ではコストがより上昇して15倍に。運用局面に至ると、100倍に達するという。

　セキュリティ・バイ・デザインに従って、開発のより早い段階、つまり上流工程でセキュリティ対策を講じることで、手戻りなどに要する工数が削減され、最終的にライフサイクル全体の工数・コストを抑制するのが狙いだ。また、保守・運用段階におけるメンテナンス性の高さも期待される。

　セキュリティ・バイ・デザインが求められる背景には、脆弱性を突いたサイバー攻撃の多様化・巧妙化が挙げられる。近年では、脆弱性が発覚した後、ただちに攻撃手法が編み出されるため、その脆弱性を抱えたシステムは攻撃に晒されてしまっていることも、そうした背景を後押ししていると言える。

　以下では、ウェブサイトやウェブアプリケーションに対する典型的な攻撃手法を解説する。

1) SQLインジェクション

　ウェブサイトにあるフォームへ特定の文字列を入力し、データベースを不正に操作する。保存されている個人情報の流出や、データの改ざん・破壊、サーバーの乗っ取りにつながる。

ウェブ改ざんはどのように行なわれるのか？ その手口と対策
https://eset-info.canon-its.jp/malware_info/special/detail/210105.html

2) クロスサイトスクリプティング（XSS）

　XSSは攻撃者がウェブサイトを改ざんし、悪意のあるウェブサイトへ誘導するリンクを設置する手法だ。訪問したユーザーの個人情報を詐取する、あるいはCookieを悪用してアカウントへの不正侵入を行なおうとする。

クロスサイトスクリプティング（XSS）とは？ウェブ改ざんを招かないための注意点と対策
https://eset-info.canon-its.jp/malware_info/special/detail/221115.html

3) ドライブバイダウンロード攻撃

　ドライブバイダウンロード攻撃とは、ウェブサイトを閲覧した際に、勝手にマルウェアがダウンロードされるようにする攻撃の事だ。上記のXSSやCSRF（クロスサイト・リクエスト・フォージェリ）攻撃、あるいはサーバーへの不正アクセスによって、攻撃者はウェブサイトを改ざんし、マルウェアを設置する。ドライブバイダウンロード攻撃では、ユーザーが利用するOSやソフトウェアの脆弱性を狙って仕掛けられる。そのため、該当する脆弱性を有した状態でこうしたウェブサイトに誘導されてしまうと、ユーザーのデバイスにマルウェアがダウンロードされ、感染に至る危険性がある。

ドライブバイダウンロード攻撃が招くセキュリティリスクとは？
https://eset-info.canon-its.jp/malware_info/special/detail/220531.html

セキュリティ・バイ・デザインの構成要素と参照すべき情報

　ウェブサイトやウェブアプリケーションの開発工程において、セキュリティ・バイ・デザインを実践するためのタスクと参考資料を以下に紹介する。

1) 企画

　開発するウェブアプリケーションの企画段階で、セキュリティ対策の方針を策定する。具体的には、想定される脅威やサイバー攻撃を特定し、リスク（発生可能性と影響度）に応じた軽減策を講じる必要がある。例えば、ウェブサイトの脅威としては、先述のSQLインジェクションやXSSが代表的な存在だ。

参考資料としてIPA発行の「安全なウェブサイトの作り方（改訂第7版）」、OWASP（Open Web Application Security Project）発行の「Threat Modeling」などがある。

　また、セキュリティ・バイ・デザインという考え全般について把握したい場合、IPAによる「セキュリティ・バイ・デザイン導⼊指南書」、デジタル庁の「政府情報システムにおけるセキュリティ・バイ・デザインガイドライン」が参考になるだろう。

2) 要件定義

　機能面の要件定義を進めるタイミングで、セキュリティ面の要件定義も実施する必要がある。ウェブアプリケーションの機能やデータに対して、機密性（Confidentiality）、完全性（Integrity）、可用性（Availability）を担保するよう、要件を抽出するステップだ。あるいは、STRIDE（なりすまし、改ざん、否認、漏えい、サービス妨害、権限昇格）を防ぐ手段を練り上げる。

　抽出した要件を満たすためには、ファイアウォールのようなインフラ面も含めた多層防御が必要なケースも考えられる。また、サードパーティの製品を組み込んだり、外部に作業を委託したりする場合、それぞれに講じるセキュリティ対策の範囲を把握し、インシデント発生時の責任範囲を明確にする取り組みが欠かせない。

情報セキュリティのCIA？対策すべき脅威と守るべき資産とは？
https://eset-info.canon-its.jp/malware_info/special/detail/221117.html

3) 設計

　要件定義を踏まえ、セキュリティ要件を満たすアーキテクチャーを検討する。アプリケーションにとどまらず、OSやミドルウェア、ネットワーク、クラウドまでに対象が広がる場合もあるだろう。また、製品リリース後の運用・保守局面においても、セキュリティの堅持・改善が容易になるよう、設計時に考慮したい。

　設計時の考慮点については、IPA発行の「脆弱性対処に向けた製品開発者向けガイド」や、カーネギーメロン大学SEI（Software Engineering Institute）が公開している「Top 10 Secure Coding Practices」が参考になるだろう。

4) 開発

　脆弱性対策を考慮したプログラミング手法は、セキュアコーディングと呼ばれる。脆弱性につながる要因を事前に除去してサイバー攻撃に対する堅牢性を確保しようとする取り組みだ。どうしても効率性、工期が優先されがちなプログラミング局面でも、コーディング規約を徹底させるなどして、セキュリティに配慮したプログラムを目指す。

　特に、認証・認可、暗号化、入出力データの検証、例外処理やログ出力といった領域では、十分に注意を払うようにしたい。また、単体テスト・結合テスト・システムテストそれぞれにおいて、セキュリティ要件を満たす品質基準を設けることが望ましい。

　IPAによる「セキュア・プログラミング講座」や、プログラミング言語ごとに提供されるガイドラインを参照すると良いだろう。

5) 運用・保守

　定期的なログ分析や、問題発生時のアラート発出といった対応プロセスを事前に整備しておくことが推奨される。加えて、ミドルウェアやインフラを含め、さまざまな箇所で生じ得る、修正プログラム適用の抜け漏れを防ぐべく、更新ルールを標準化しておく必要がある。

　機能追加・脆弱性対応などの変更を加えた際にも、アーキテクチャー全体にわたり、その変更履歴を管理しておくようにしたい。加えて、脆弱性診断やペネトレーションテストを定期的に実施すれば、脆弱性を放置してしまうリスクを軽減できる。

脆弱性診断とペネトレーションテストの違いは？システムやソフトウェアの脆弱性を診断するには？
https://eset-info.canon-its.jp/malware_info/special/detail/230209.html

シフトレフトとDevSecOps

　セキュリティ・バイ・デザインと似た考え方として「シフトレフト（Shift Left）」が提唱されている。この言葉はウォーターフォール型の開発工程が一般的に左から右に書かれることに倣い、セキュリティ対策を講じる局面を右側（テスト段階）から左側（設計段階）へ移すべきという考え方だ。

　リリース前のテスト段階でセキュリティ対策を講じるのではなく、セキュリティの観点で見た成果物のレビューや品質保証のプロセスを要件定義・設計の段階から継続的に実施する。

図1：セキュリティ対策におけるシフトレフト

　近年、注目されているIoTの分野においてもシフトレフトの採用が進んできた。インターネットに接続するデバイスは、サイバー攻撃の標的となってしまう恐れがあるにも関わらず、多くのIoT機器ではメモリー容量が少ないために暗号化通信が難しいといった制約がある。シフトレフトの考え方に従い、リリース後の脆弱性対応・修正パッチ適用の方法も含め、要件定義・設計の段階からセキュリティ対策を講じる必要に迫られている。

　また、セキュリティ・バイ・デザインに関連した用語として、アジャイル開発におけるDevSecOpsが注目されるようになっている。まず、DevOpsは開発チームと運用チームが共通の目標を持って連携し、頻繁なリリースを繰り返しながらもサービスの安定稼働をもたらすものだった。CI/CDパイプラインを導入して、テストやデプロイを自動化・標準化するという特長があった。

　このDevOpsに継続的なセキュリティ対策を組み込んだのがDevSecOpsとなる。これまで、柔軟にサービスへ変更を加えるアジャイル開発においては、セキュリティ対策が後回しになる傾向があった。しかし、CI/CDパイプラインにセキュリティテストや脆弱性診断を組み込むといった対策を講じ、開発速度を維持しながらも、セキュリティを担保するプロセスと風土を生み出すことを目指す。

広がるプライバシー・バイ・デザインの考え方

　最後に、プライバシー・バイ・デザインの考え方も紹介する。先述のセキュリティ・バイ・デザインでは情報セキュリティ全般を対象としていた。一方で、個人情報の保護に特化して対策を講じるのがプライバシー・バイ・デザインだ。

　昨今のコンプライアンス、個人情報保護に対する意識の高まりを受け、設計段階からプライバシーに配慮するよう求める法規制・標準化が進められてきた。そのため、個人情報を収集するサービス運営者は、上流工程からプライバシー対策を講じておくことが求められている。

　具体的には、同意を得られた目的に限って必要最小限の個人情報のみを収集する、加えて、不正利用のリスクを軽減するといった対策を講じなければならない。

　あらゆるウェブサイト・ウェブアプリケーションがサイバー攻撃のリスクに直面している昨今、事後の対応ではさまざまな脅威に対処しきれなくなってきている。仮に、こうした場当たり的な対応にとどまっている組織は、実際の攻撃に遭遇した際に被害が拡大して、莫大な損失を被る恐れがある。中長期的な観点で見ると、セキュリティ対策を早い段階で講じれば、システム運用全体に要するコストが抑制されることが期待される。企画・設計の段階から対策を講じるセキュリティ・バイ・デザインの考え方は、今後より一層、ウェブサイト運営者にとって必要な考え方になっていくはずだ。

■関連サイト

キヤノンMJ トップへ