残念ながらネットワークでは”当たり前”のセキュリティ構造（アーキテクチャー）がソフトウェアでは”当たり前”ではありません。 アーキテクチャーに問題がある場合、十分なリスク管理レベルを達成することが困難になります。 ネットワークの当たり前、をソフトウェアでも行うと確実に安全性が向上します。

1. ネットワークから学ぶ
ソフトウェアセキュリティの基礎
エレクトロニック・サービス・イニシアチブ
大垣 靖男

2. 自己紹介
• 氏名： 大垣 靖男
• SNS：yohgaki(FB/G+/TW)
• https://blog.ohgaki.net/
• yohgaki@ohgaki.net
• https://www.es-i.jp/
• エレクトロニック・サービス・
イニシアチブ有限会社 代表取締
役社長、PostgreSQLユーザー
会 理事、PHP技術者認定 顧問、
BOSSCON CTO、岡山大学大学
院 非常勤講師
• Webシステム開発のコンサル
ティング、テクニカルサポート、
セキュリティ検査など
• PHPコミッター
© Electronic Service Initiative, Ltd. https://es-i.jp/ 2

3. ある程度の規模のネットワーク構成
• エッジルーター
• インターネットに接続する境界のルーター
• インターネットとイントラネットを接続・分離
• 部門ルーター
• 各部門の部門ネットワークに接続されたルーター
• 各部門のネットワークの仕様に従って接続・分離
• 部門ネットワーク
• それぞれの部門はセキュリティ要求に従って接続・分離
© Electronic Service Initiative, Ltd. https://es-i.jp/ 3

5. 信頼境界線
• 一番重要な信頼境界線はインターネットとイントラネットの境界
• 各部門もそれぞれ信頼境界を持つ
© Electronic Service Initiative, Ltd. https://es-i.jp/ 5

6. インターネットと
イントラネットの
信頼境界
イントラネット内
にもそれぞれ
信頼境界
まず最外周の境界で可能な限りの防御
をするのがネットワークセキュリティ
の当たり前

7. 多層防御
• 多層防御：複数のレイヤーからなる防御策
• ネットワークではインターネットから分離して防御するだけで
なく、ネットワークセグメント別に更なる防御が実装されてい
る。
• ネットワークのみでなく、現在は普通にクライアントやデバイ
スにもファイアウォールが利用され、デバイス毎に境界防御を
行う。
© Electronic Service Initiative, Ltd. https://es-i.jp/ 7

8. ネットワークの多層防御イメージ
エッジ
ルーター
部門ルーター
部門
ネットワーク
デバイス
各信頼境で適切に防御
インターネット
© Electronic Service Initiative, Ltd. https://es-i.jp/ 8

9. ネットワークの基本セキュリティ
をソフトウェアに置き換える
主にWEBアプリを対象に
ネットワーク図はそのままソフトウェアのアーキテクチャとして利用
© Electronic Service Initiative, Ltd. https://es-i.jp/ 9

10. Webアプリ コントローラー
モデル
ライブラリ ライブラリ
ビュー ビュー ビュー

11. Webアプリで
よくあるセキュリティモデル
• モデルにより「入力境界の防御」を行う
• Rails系、MVC系のフレームワークはコレ
• ビューにより「出力境界の防御」を行う
• 先の図でいうと次の通り
© Electronic Service Initiative, Ltd. https://es-i.jp/ 11

12. Webアプリ コントローラー
モデル
ライブラリ ライブラリ
ビュー ビュー ビュー
まず最外周の境界で可能な限りの防御をする
のがネットワークセキュリティの当たり前だ
が、ソフトウェアでは・・・

13. Webアプリで
よくあるセキュリティモデル
• モデルにより「入力境界の防御」を行う
• Rails系、MVC系のフレームワークはコレ
• ビューにより「出力境界の防御」を行う
ネットワーク設計の場合なら、この
ようなセキュリティ設計をするエン
ジニアは失格でしょう
ソフトウェアの場合、セキュリティ設
計の概念が欠落している。このため、
ネットワーク設計なら「あり得ない設
計」でも許されている。
© Electronic Service Initiative, Ltd. https://es-i.jp/ 13

14. インターネットと
イントラネットの
信頼境界防御なし
イントラネット内
にもそれぞれ
信頼境界がない
ネットワークエンジニアであれば、
これはあり得ない設計・・・

15. Webアプリの
あるべきセキュリティモデル
• 最外周の信頼境界での境界防御が必要
• 現状は最外周の防御が「出力境界だけ」しかないモデルが当たり前
• 「出力境界の防御」だけが当たり前ではセキュアにならない
© Electronic Service Initiative, Ltd. https://es-i.jp/ 15

16. インターネットと
イントラネットの
信頼境界で入力検証
コントローラー
モデル
ライブラリ ライブラリ
ビュー ビュー ビュー
まず最外周の境界で可能な限りの防御
をするのがネットワークセキュリティ
の当たり前、はソフトウェアにも必要
ソフトウェア内にもそれぞ
れ信頼境界
出力境界の特に重要

17. Webアプリの多層防御イメージ
モデル
ライブラリ等
ビュー
各信頼境で適切に防御
インターネット
コントローラー
© Electronic Service Initiative, Ltd. https://es-i.jp/ 17

18. ネットワークでは
なぜ“最外周”の信頼境界防御が重要か？
• 内部のデバイス全てを「安全」にするのが理想だが現実は・・・
• 全てのデバイスを「安全」にするのは困難
• デバイスは入れ替わる場合が多い
• 全てのデバイスに全てのセキュリティパッチの即時適用は困難
• 意図的に古く脆弱なデバイスを使っている場合も
ソフトウェアエンジニア
でも困難であると解るはず
© Electronic Service Initiative, Ltd. https://es-i.jp/ 18

19. ソフトウェアでも
なぜ“最外周”の信頼境界防御が重要か？
• 内部のデバイス全てを「安全」にするのが理想だが現実は・・・
• 全てのデバイスコードを「安全」にするのは困難
• デバイスコードは入れ替わる（書き換えられる）場合が多い
• 全てのデバイスコードに全てのセキュリティパッチの即時適用は
困難
• 意図的に古く脆弱なデバイスコードを使っている場合も
ソフトウェアエンジニア
なら困難であると知っている
はず
© Electronic Service Initiative, Ltd. https://es-i.jp/ 19

20. 少し気になる誤解
• 入力境界の防御（入力バリデーション）は“ソフトウェアの仕
様”でセキュリティ対策ではない
• これは、明らかに誤りです。セキュアコーディング基礎を具体
的に解説していた旧版ISO27000では“リスク管理”の一環とし
てセキュリティ対策（リスク対応策）として、定期的なレ
ビュー（見直し）を求めています。
• “ソフトの仕様“としセキュリティ対策として管理（見直し）し
ない場合、重要な境界防御の脆弱性を見過ごすことに。
© Electronic Service Initiative, Ltd. https://es-i.jp/ 20

21. まとめ
© Electronic Service Initiative, Ltd. https://es-i.jp/ 21

22. ソフトウェアの
セキュリティアーキテクチャは・・・
• ネットワークセキュリティアーキテクチャと比べると
「失格レベル」のアーキテクチャが多い
© Electronic Service Initiative, Ltd. https://es-i.jp/ 22

23. なぜ失格レベルの
セキュリティアーキテクチャばかりなのか？
• セキュリティアーキテクチャが無いのが当たり前だった
• 習慣は変えづらい。今時、「関数などを無視した非構造化プログラミング
が良い！」と言う人は一人も居ない。しかし、ダイクストラが構造化プロ
グラミングを提唱した当時は“本気で非構造化でも構わない！”と反論した
開発者は多数居た。
• セキュリティ専門家でさえ「セキュアなソフトウェアアーキテ
クチャ」を教えていなかった、中には知らない人も
• ダイクストラの構造化プログラミングは有害だとする専門家もいたくらい
なので、これは仕方がないかも。だが周回遅れも甚だしい。
• 普通のコンピュータサイエンティストは遅くとも90年代初めに「防御的プ
ログラミング」が提唱された時、つまり4半世紀前から知っているはず
© Electronic Service Initiative, Ltd. https://es-i.jp/ 23

24. なぜ失格レベルの
セキュリティアーキテクチャばかりなのか？
• 特にインターネットでセキュリティを構造的・論理的に考えない開
発者（やセキュリティ専門家？）が、当たり前のセキュアなアーキ
テクチャを全力で否定している
• （まったくセキュリティを理解していないのに、異常に攻撃的な人が居る）
• （普通の人はこういうのに関わりたくないので、そのうち解るだろう、と傍観
することが多い）
• 私は成り行き上、なぜかセキュアなアーキテクチャの数少ないエバンジェリス
トになっている（ただし、ISO27000とかを真面目にしている会社は言わなく
てもやっている。ISO27000は2000年策定時からセキュアコーディングの基
礎技法を標準に記載していた。2014年版では「当たり前」になったとして、
セキュアプログラミング技術を採用する、と簡潔な表記に変更されています）
© Electronic Service Initiative, Ltd. https://es-i.jp/ 24

25. セキュリティ専門家は以前から推奨してい
た、がノイズにかき消されているのが現状
• ISO 27000
• CERT Top 10 Secure Coding Practices
• OWASP Secure Coding ‐ Quick Reference Guide
• CWE/SANS Top 25
• といった権威あるセキュリティ標準・ガイドラインは10年以上
というスパンで啓蒙している
© Electronic Service Initiative, Ltd. https://es-i.jp/ 25

26. • 言葉だと解りづらいので図にすると
© Electronic Service Initiative, Ltd. https://es-i.jp/ 26

27. • 基本アーキテクチャ – アプリケーション、モジュール、関
数・メソッド、粒度に関わらず共通
セキュアなソフトウェアアーキテクチャ
© Electronic Service Initiative, Ltd. https://es-i.jp/ 27
入力 （HTML/JavaScript/JSON/データベース/OS/WebAPIなど）
入力処理
ロジック処理
出力処理
出力 （HTML/JavaScript/JSON/データベース/OS/WebAPIなど）
アプリケーション
入力処理
ロジック処理
出力処理
入力処理
ロジック処理
出力処理
モジュール 関数・メソッド
各レイヤーの
境界防御
が防御の基本
✓ アプリケーションレベルの境界
防御が特に重要
✓ データは基本的に信頼できない
✓ アプリレベルで入力バリデー
ションすれば、アプリ全体に対
して妥当性を保証可能
信頼境界線

28. 入力
処理
出力
セキュリティ対策とコンテクスト
• 入力処理
• 入力のコンテクストで
バリデーション
• 出力処理
• 出力のコンテクストで、エス
ケープ、安全なAPI、バリデー
ション（ホワイトリスト）
© Electronic Service Initiative, Ltd. https://es-i.jp/ 28
✓ HTML：コンテンツ、URI、JavaScript
文字列など
✓ SQL：引数、識別子、SQL語句、拡張
機能（正規表現、XML、JSON）
✓ LDAP、XPath、コマンド、etc
✓ 何処に出力するデータか？が重要
✓ 金額、高さ、幅などの数値
✓ 名前、住所、コメントなどの文字列
✓ 電話、郵便番号などの定型文字列
✓ 都道府県、年代などの分類・集合
✓ それぞれのHTTP/SMTPヘッダーなど
✓ どのような入力データか？が重要
入力処理では
“入力のコンテクスト“が重要
出力処理では
”出力のコンテクスト”が重要
✓ できる限り“最終出力”に近い場所で
セキュリティ処理を行う
✓ “最終出力”に近い場所の方が
“コンテクスト”が明確
✓ アプリケーションの入力バリデーション
（ホワイトリスト型）が最も重要
✓ 重要なモジュール/関数は縦深（多層）
防御
ど
ち
ら
も
コ
ン
テ
ク
ス
ト
が
重
要
！
信頼境界線
信頼境界線

29. 最後に
• 脆弱性だけを潰していても、満足いくセキュリティレベルに到
達するのは「非常に困難」です。
• 理由： 合成の誤謬
• セキュアなアーキテクチャで作らないと、訴訟になった場合に
非常に不利です。契約金額以上の賠償金支払いの可能性があり
ます。
• 理由：契約金額以上の賠償金支払いとなる判決があった
• やっている所は黙ってやるべきことをやっています！
© Electronic Service Initiative, Ltd. https://es-i.jp/ 29

30. セキュアなアーキテクチャは使って
いる所では当たり前に使われていま
す。ノイズに惑わされないように。
ご清聴ありがとうございました。
弊社ではソースコード検査/研修/テクニカルサポートなどの
サービスも提供しています。お問い合わせはお気軽に。
© Electronic Service Initiative, Ltd. https://es-i.jp/ 30