セキュアなソフトウェアアーキテクチャー

セキュアな
ソフトウェア
アーキテクチャー
アーキテクチャーなしでセキュアなソフトウェア構築は困難
エレクトロニック・サービス・イニシアチブ
大垣靖男

ソフトウェアの問題
• 安全なソフトウェアが作れない
• そもそも完璧に安全なソフトウェアは作れない
• 原因
• ソフトウェアは非常に複雑で、個人で全てを把握することが不
可能
• 非常に複雑なソフトウェアの開発に対して、システマティックなア
プローチを採用していない
• セキュアなソフトウェアアーキテクチャーを採用しない開発現場
2015/6/26Electronic Service Initiative, Ltd All Rights Reserved. http://www.es-i.jp/ 2

基礎知識

ITシステム導入の目的とは？
• “新しい価値”の創造
• 既存プロセスのコストダウン
• 新しいサービス・製品導入による価値の創造
• ITシステム導入には必ずリスクが伴う
• ITシステム導入自体がリスク – 上記目的達成のトレードオフ
• 情報の管理・利用リスク－情報漏えい・改ざん･不正利用
• ITシステムの信頼性のリスクーソフトウェア・ハードウェア両方

ITセキュリティ対策とは？
~ ISO 27000 の定義 ~
• 2.71
リスク対応
リスクを変化 (2.61)させる為のプロ
セス(2.54)
• ノート 1
リスク対応には以下の項目を含める
事ができる:
• １）リスクを発生させる活動を開始しない、または
継続しないことを決断することによりリスクを回避する
２）機会を獲得する為にリスクを選択または増加さ
せる３）リスクの原因を排除する 4）発生の頻
度を変える 5）結果を変える 6）他の組織（契
約企業やリスクの資金的処理を含む訳注：保険
など）とリスクを共有し 7）見聞のある選択により
リスクを抑える
• ノート 2
否定的な結果をもたらす事象のリス
ク対応は、”リスク緩和策”、”リスク
排除策”、”リスク防止策”、”リスク
削減策”などと呼ばれる事がある
• ノート 3
リスク対応は新しいリスクを生成した
り、既存のリスクを変更することができ
る

ITセキュリティ対策の目的とは？
• ITシステムを利用する上で必ず発生するリスクを
「軽減・緩和・排除・管理」することが目的
• ITシステムを利用するリスクの完全排除は無理
• 個々のリスクを排除しても、全てのリスク解除は不可能
• ITシステム利用リスクの完全排除はシステムを利用しない以外にない
• セキュリティ対策とはITシステム利用リスクを“許容範囲内”に収める管
理策
• ITセキュリティ対策とは本質的に全て“緩和策”

重要：標準ITセキュリティでは
セキュリティ対策 ≠ リスク排除
• よくある勘違い「セキュリティ対策＝リスク排除」
• 「セキュリティ対策＝リスク排除」では体系的な
セキュリティ構築は不可能
• 特定リスクの排除は全体としては緩和策に過ぎない
• 特定リスクの排除には、残存リスクや追加リスクが発生する
• 「セキュリティ対策＝緩和策」と考えると体系的
• 残存リスク・追加リスクの適切な評価
• 効果とコストの適切な評価

ソフトウェアのリスク

CWE/SANS TOP 25
Most Dangerous Software Errors
• ソフトウェア開発における
最も危険なリスクとその
対策集
• Guidance for Using the Top
25
• Brief Listing of the Top 25
• Category-Based View of
the Top 25
• Organization of the Top 25
• Detailed CWE Descriptions
• Monster Mitigations
https://www.sans.org/top25-software-errors/

Insecure Interaction Between
Components
CWE ID Name
CWE-89
Improper Neutralization of Special Elements used in an SQL
Command ('SQL Injection')
CWE-78
Improper Neutralization of Special Elements used in an OS
Command ('OS Command Injection')
CWE-79
Improper Neutralization of Input DuringWeb Page
Generation ('Cross-site Scripting')
CWE-434 Unrestricted Upload of File with DangerousType
CWE-352 Cross-Site Request Forgery (CSRF)
CWE-601 URL Redirection to Untrusted Site ('Open Redirect')

Risky Resource Management
CWE ID Name
CWE-120
Buffer Copy without Checking Size of Input ('Classic Buffer
Overflow')
CWE-22
Improper Limitation of a Pathname to a Restricted Directory
('PathTraversal')
CWE-494 Download of Code Without IntegrityCheck
CWE-829 Inclusion of Functionality from Untrusted Control Sphere
CWE-676 Use of Potentially Dangerous Function
CWE-131 Incorrect Calculation of Buffer Size
CWE-134 Uncontrolled Format String
CWE-190 Integer Overflow or Wraparound

Porous Defenses
CWE ID Name
CWE-306 MissingAuthentication for Critical Function
CWE-862 MissingAuthorization
CWE-798 Use of Hard-coded Credentials
CWE-311 Missing Encryption of Sensitive Data
CWE-807 Reliance on Untrusted Inputs in a Security Decision
CWE-250 Execution with Unnecessary Privileges
CWE-863 Incorrect Authorization
CWE-732 Incorrect PermissionAssignment for Critical Resource
CWE-327 Use of a Broken or RiskyCryptographicAlgorithm
CWE-307 Improper Restriction of ExcessiveAuthentication Attempts
CWE-759 Use of a One-Way Hash without a Salt

OWASP TOP 10
• A1 Injection
• A2 XSS
• A3 Weak
authentication and
session
management
• A4 Insecure Direct
Object Reference
• A5 Cross Site
Request Forgery
• A6 Security
Misconfiguration
• A7 Insufficient
Cryptographic
Storage
• A8 Failure to
Restrict URL access
• A9 Insufficient
Transport Layer
Protection
• A10 Unvalidated
Redirects and
Forwards
https://www.owasp.org/index.php/Category:OWASP_Top_Ten_Project

CWE/SANS TOP 25
OWASP TOP 10
これが全てのリスクか？
• CWE（Common Weakness Enumeration）
• 共通脆弱性タイプ
• 脆弱性の種別をカタログ化したデータベース。CVEを管理する
MITRE社が管理
• CWE/SANS TOP 25はCWE中のトップ25に過ぎない
• CWEは共通脆弱性カタログ、
つまり共通する脆弱性を“一般化”したカタログ
• 環境別、個別の脆弱性に対応するには
“共通”ではなく“個別”の対応が必要となる

CWEカタログ
共通脆弱性だけで719！
環境別に脆弱性を考慮する
とこの何倍もの個別ソフト
ウェア脆弱性が存在する
https://cwe.mitre.org/data/slices/2000.html

セキュアなソフトウェア開発
防御的プログラミング

防御的プログラミングとは？
• 別名：セキュアプログラミング/セキュアコーディング
• プログラミング原則の一つ
• 個々の脆弱性対策の
み
• セキュアアーキテク
チャー無し
レガシー開発
• セキュアな開発方針
として、プログラミ
ングを防御的に行う
• セキュアアーキテク
チャー有り
セキュア開発

CERT Top 10
セキュアコーディングプラクティス
1. 入力をバリデーション
する
2. コンパイラの警告に用
心する
3. セキュリティポリシーの
為に構成／設計する
4. 簡易にする
5. デフォルトで拒否する
6. 最小権限の原則を支
持する
7. 他のシステムに送信
するデータを無害化
する
8. 縦深防御を実践する
9. 効果的な品質保証テ
クニックを利用する
10.セキュアコーディング
標準を採用する

CERT Top 10
セキュアコーディングプラクティス
のアーキテクチャー
入力処理
プログラムロジック
出力処理
１．入力をバリデーションする
５．デフォルトで拒否する
６．最小権限の原則を支持する
４．簡易にする
８．縦深防御を実践する
７．他のシステムに送信するデータ
を無害化する

関数
メソッド
セキュアコーディングアーキテクチャー
は全ての粒度で行える
入力処理
出力処理
７．他のシステムに送信する
データを無害化する
ライブラリ
入力処理
出力処理
アプリケー
ション
入力処理
出力処理

セキュアソフトウェアアーキテクチャー
の課題
• 多くのソフトウェア開発者がセキュアソフ
トウェアアーキテクチャーを知らず・意識
せずに開発
そもそも知らない
• 細かい粒度でのセキュアアーキテクチャー
の採用はソフトウェア性能に影響
• 解決策：契約プログラミング
パフォーマンス

アプリケーション開発者にとって最も大切
かつ責任を持つモノはアプリケーション
関数
メソッド
入力処理
出力処理
ライブラリ
入力処理
出力処理
アプリケー
ション
入力処理
出力処理

レガシー・カジュアルな
アプリケーション開発現場の現状
アプリケー
ション
入力処理
出力処理
セキュアなアーキテ
クチャー自体は90年
代初めに確立
残念ながら
適切なセキュリティ
アーキテクチャー
概念無しで開発

セキュアなアーキテクチャー
Webアプリ
情報
HTML/CSS
FW/API
OSコマンド
URL/ファイル
パス
SQL/Xpath/LD
AP/etc
JavaScript
GET/POST/HE
ADER
Web
サービス
信頼境界線
信頼境界線を越える“もの”
全てに“安全性対策”が必要
つまり、全ての入力・出力で
対策

Webアプリ
情報
HTML/CSS
FW/API
OSコマンド
URL/ファイル
パス
SQL/Xpath/LD
AP/etc
JavaScript
GET/POST/HE
ADER
Web
サービス
信頼境界線
対策
アプリのコードを信頼するには
検証が必要！
アプリが持つ情報はそのまま出
力して安全とは限らない！

全体最適化されていない
セキュリティーアーキテクチャー
アプリケー
ション
入力処理
（コントローラー）
（モデル）
出力処理
（ビュー）
データベースモデルに渡すべきでない
パラメーターをのみ排除
（他の入力バリデーションなし）
入力バリデーション
（本来入力処理で“も”行う処理）
デフォルトHTMLエスケープ
よくあるWebアプリフレームワークの
セキュリティアーキテクチャー
NG
NG
Acceptable

全体最適化されていない
セキュリティーアーキテクチャー
アプリケー
ション
入力処理
（コントローラー）
（モデル）
出力処理
（ビュー）
データベースモデルに渡すべきでない
パラメーターをのみ排除
（他の入力バリデーションなし）
入力バリデーション
（本来入力処理で“も”行う処理）
デフォルトHTMLエスケープ
よくあるWebアプリフレームワークの
セキュリティアーキテクチャー
NG
NG
Acceptable
モデル（データベースなど）でバリ
デーションすることは「縦深防御」
（多層防御）として推奨される。
モデルレベルでの「境界防御」と考
えることも可能。

全体最適化でない場合のリスクの例
～誤った仮定～
演習問題

全体最適化でない場合のリスクの例
～リクエストフォージェリ～
演習問題

契約プログラミング
• 契約プログラミング（Contract Programming /
Design by Contract）はセキュアアーキテクチャーで
も高性能かつ高信頼性を達成できる手法
• 契約プログラミングの基本
• 呼び出し側が呼び出される側の「契約」（制約・前提）を守る
• 呼び出された側は実行終了時の出力（戻り値）および状態
（オブジェクトプロパティ、グローバル変数など）の「契約」を守
る

契約プログラミングを実践すると・・・
必然的にアプリケーションで
• 「入力バリデーション」
• 「安全な出力」
を行うことに帰結する
外部からの入力に「契約遵守」は期待できない
外部への出力で「契約違反」をして、安全に実
行される保障がない

Webアプリ
情報
HTML/CSS
FW/API
OSコマンド
URL/ファイル
パス
SQL/Xpath/LD
AP/etc
JavaScript
GET/POST/HE
ADER
Web
サービス
信頼境界線
対策
信頼境界線での防
御がセキュアコー
ディングの要！

まとめ

セキュアなコーディング・アーキテク
チャーの概念は簡単！
• 概念は簡単だが、誤解されたり、知られていなかったり
すること多い！
• セキュアなアーキテクチャー無しでセキュアなソフトウェア
開発は困難！
• できたとしてもコストが大きい
• 入力バリデーションをセキュリティ対策として取り入れる
• インターフェースはコードより安定している
• 幅広い脆弱性を防止・緩和できる
• 未知の脆弱性まで防止・緩和できる
• 入力バリデーションはデフォルト拒否（つまりホワイトリスト）

目的と手段を明確に区別
• ITセキュリティ対策の目的は「ITシステムの利用リスク
を許容範囲内に抑える」
• 目的達成の為に効果的な手法を取り入れる
• セキュアなアーキテクチャー、防御的プログラミング、契約プログラ
ミング
• 個々の脆弱性対策は手段
• 手段を間違えると目的の達成は困難なので重要
• しかし、個々の脆弱性対策だけでは「全体最適化」は困難

セキュアなアーキテクチャーと
セキュアなコーディングで
セキュアなソフトウェアを実現！
基本は難しくありません！
お問い合わせはエレクトロニック・サービス・イニシアチブへ
http://www.es-i.jp/

セキュアなソフトウェアアーキテクチャー

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to セキュアなソフトウェアアーキテクチャー

Similar to セキュアなソフトウェアアーキテクチャー (20)

More from Yasuo Ohgaki

More from Yasuo Ohgaki (8)

セキュアなソフトウェアアーキテクチャー