セキュア･プログラミング講座
発行機関：情報処理推進機構
発行年月日：2016年10月
概要
「セキュア・プログラミング講座」では、製品プログラミングや、Webプログラミングを対象にした、ガイドラインを公開しています。このガイドラインでは、これまでの内容をまとめ、共通的なセキュリティ原則を抽出し、広く開発分野に関わる人に向けた、開発のガイドラインとして公開しています。
リスク＝【情報資産】×【脅威】×【脆弱性】
上記の式に基づき、それぞれの要素を0に近づけることで、リスク低減をはかっています。
セキュア・プログラミングには、脆弱性を作りこまない根本的解決策と予防的に影響を軽減する保険的対策があり、このガイドラインでは上記の2つの内容を含んでいます。
また、脅威モデリングを行い、想定される脅威に優先度をつけて対策していく考え方を解説しています。
設計時の原則
設計原則には、多くの設計原則でも参照されているSaltzer & Schroederの8原則を取り上げています。
- Economy of mechanism：効率的なメカニズム
単純で小さな設計を心がける。 - Fail-safe defaults：フェイルセーフなデフォルト
必要ないものを排除するのではなく、必要なものを許す判断を基本とする。 - Complete mediation：完全な仲介
あらゆるオブジェクトに対するすべての処理に関与する。 - Open design：オープンな設計
設計内容を秘密していることに頼らない。 - Separation of privilege：権限の分離
1 つの鍵を持つ者にアクセスを許してしまう仕組みよりも複数の鍵を使って保護する方が、強固だし柔軟でもある。 - Least privilege：最小限の権限
システムのすべてのプログラムおよびすべてのユーザは、業務を遂行するために必要な最小の権限の組み合わせを使って操作を行うべきである。 - Least common mechanism：共通メカニズムの最小化
複数のユーザが共有し依存する仕組みの規模を最小限に押える。
これには、共有されているオブジェクトとして、/tmp や /var/tmpの利用について触れており、これらのオブジェクトは情報流出の経路となる危険性を持っているとしています。 - Psychological acceptability：心理学的受容性
ユーザが日常的に無意識のうちに保護の仕組みを正しく利用できるように、使いやすさを優先した設計が重要である。
実装原則
実装原則にはSEI CERT Top 10 Secure Coding Practices20を取り上げています。
- 実装原則１：Validate input.
すべての信頼されていないデータソースからの入力を検証する。 - 実装原則２：Sanitize data sent to other systems.
外部に渡すデータは渡した先で問題を起こさないように加工する。渡す先によって問題となる条件は異なるのでそれに合わせた加工をする必要がある。例えばデータを渡す先がWeb ページへの出力部分ならば XSS 対策をする必要があるし、DBMS の SQL ならばSQL インジェクション対策を行う必要がある。 - 実装原則３：Heed compiler warnings.
コンパイラの警告に注意を払わなければならない。 - 実装原則４：Architect and design for security policies.
セキュリティポリシー実現のための実装と設計を行う。 - 実装原則５：Keep it simple.
シンプルを維持する。設計原則 1 の「Economy of mechanism：効率的なメカニズム」と同じ意図のものである。 - 実装原則６：Default deny.
拒否をデフォルトにする。設計原則 2 の「2.Fail-safe defaults：フェイルセーフなデフォルト」と同じ意図のものである。 - 実装原則７：Adhere to the principle of least privilege.
最小権限の原則に従う。設計原則 6 の「Least privilege：最小限の権限」と同じものである。
脅威モデリング
脅威の分類の手法としてSTRIDEを紹介しています。STRIDEは、ソフトウェアの脅威を識別するためのものとして以下の6種類の事象を示しています。
- S: なりすまし(Spoofing Identity)
攻撃者が他のユーザを装ったり、悪意のあるサーバが有効なサーバを装ったりすること。 - T: 改ざん(Tampering with data)
悪意を持ってデータを変更すること - R: 否認(Repudiation)
ユーザが行った操作の事実を否定すること。否認不能性の実現は元々それなりに手間ではある。ユーザのなりすましや履歴等の記録データの改ざんができないことが前提になる。 - I: 情報の漏洩(Information Disclosure)
不本意な相手に情報が開示されてしまうこと。 - D: サービス妨害(Denial of Service)
正当なユーザに対してサービスの提供ができなくなること。利用数やデータ量の制限なしにレスポンスも含めたサービス低下に対して対応することはできない。 - E: 権限昇格(Elevation of Privilege)
権限を与えられていないユーザが、高い権限を取得すること。
開発プロセス
ソフトウェアのセキュリティ品質を確保する行動として以下のものがあります。
- 設計工程における「セキュリティレビュー」
セキュリティレビューは、セキュリティ対策漏れを早くに見つけ出し、設計者へフィードバックすることを目的に、以下の観点でレビューを行います。
•セキュリティポリシーを満たしているか
•セキュリティ要件に対する対策漏れがないか
•既知の脆弱性対策が行えているか
- 実装工程における「ソースコードレビュー」
記述したソースコードを直接検証するソースコードレビューは、開発者担当者が書いたソースコードを閲読して読みやすく、分り易く書かれているか、更にはセキュリティ脆弱性あるいはそのきざしがないか読み取る作業です。
より手軽に始める方法としては、最初はソースコードの静的検査ツールを使い、ツールが自動で検出してくれる問題から手を付けるという方法があります。
更に CI(継続的統合)ツールと組みまわせて、常にシステム構成管理にチェックインされた際に自動的にツールの範囲でのチェックを実施することも行われるようになりつつあります。
- テスト工程における「セキュリティテスト」
セキュリティテストの目的は、作り上げたプログラムに十分なセキュリティ対策が実装されているかどうかを確認することです。
