ERR00-C. エラー処理には一貫性のある方針を採用する
システムは常に、攻撃や誤った入力、悪意のある入力、ハードウェアやソフトウェアの障害、ユーザの予想外の振る舞い、環境の変化といった「通常運用」の範疇を超える予期せぬストレスにさらされている。それでもシステムは、必要不可欠なサービスを適時に安全かつ確実に提供し続けなければならない。そのためには、堅牢性、信頼性、エラー耐性、耐障害性、性能、セキュリティなどの特性がシステムに備わっている必要がある。これらの特性はすべて、一貫性のあるエラー処理の上に成り立っている。
ISO/IEC TR 24772のセクション6.39.1 [ISO/IEC TR 24772]には次のように記載されている。
システムに対する信頼は、そのシステムが期待通りに動作し、通常の使用において障害が生じないという信頼に基づく。システムの信頼性と耐障害性は、構成要素の信頼性、可用性、安全性およびセキュリティから測ることができる。信頼性とは、要求されている機能を特定の条件の下で指定の期間にわたって実行できるシステムまたは構成要素の能力をいう [IEEE 1990 glossary]。可用性とは、利用者にとってシステムがどれほど適切に反応し信頼できるかを示す。この2つは、安全およびセキュリティが求められるシステムでは重要な要素である。最善を尽くしたとしても、システムが障害を起こすことはあるだろう。その原因は、品質の低い内部のソフトウェアによる場合もあれば、停電や電力の変動、洪水、その他の自然災害など外部要因による場合もある。障害にどのように対応するかが、システムの性能、特にシステムとその利用者の安全とセキュリティに影響を及ぼすことがある。
ストレス下でも運用を継続できるシステムを設計、実装、保守、運用するためには、効果的にエラーを処理すること(エラー報告、レポート集計、分析、対応、復旧)が重要である。「運用を継続できる」とは、攻撃や事故など、通常運用の範囲を超えるストレスにもかかわらずシステムがその使命を適時に遂行する能力を持つことである[Lipson 2000]。すなわち、ある与えられたストレス下ですべてのサービスを維持することができない場合には、提供するサービスを必要不可欠なもののみに縮小し、状況が改善すればその他のサービスの提供を再開できる機能を意味する。
エラー報告およびエラー処理は、運用継続性のあるシステムの設計と運用において中心的な役割を果たす。運用継続性はシステム全体として達成される特性だが[Fisher 1999]、システムの個々の構成要素の振る舞いおよび要素間のやり取りの影響を受ける。エラー処理の観点から見ると、個々のシステム構成要素は最も小さなルーチンに至るまで、システムの状態について何らかの報告を行うセンサーと見なすことができる。エラーや異常が無視されたり適切に処理されないと、必要不可欠なシステムサービスを提供できなくなるおそれが生じ、システムが支える組織や事業の使命を危うくする。
運用継続性の重要な特徴に、3つのR、すなわち抵抗力(resistance)、認識力(recognition)、復旧力(recovery)がある。抵抗力とは、特定のストレスに対してシステムを強化する方策を指し、認識力はストレスの発生とシステムへの影響の状況を認識する能力を指し、復旧力は、攻撃や事故など、システムのサービスを中断させた出来事の後に(また、場合によってはその最中から)システムがサービスを回復する能力を指す。
個別の構成要素またはルーチンの単位では、発生したエラーの原因を分析し回復と対応のための適切な方策を決定することは、多くの場合不可能である。何が起きているのかを把握して適切な措置を決定するには、複数のエラー報告を集約しそれらをより大局的な視点から解釈する必要がある。もちろん、システムが運用される領域に固有の事情は、復旧のための適切な方法と手段の決定に大きな影響を及ぼす。安全性が重視されるシステムでは、エラーへの対応として単純にシステムを停止させること(あるいは、問題のプロセスを終了すること)さえも、最善策ではないばかりか、大惨事を引き起こす可能性がある。システム全体の観点からは、エラーの処理方法は運用継続性を直接反映したものであるべきである。たとえば、同一構成のバックアップサービスへの完全な切り替えが適切な場合や、共通モード故障時の運用継続性を高めるために、構成は異なるが同等の機能を実現するシステムに切り換えることが適切な場合もあるだろう。
エラー処理方針は、エラーが発生したときそれをどのように報告し対応するか統一的に規定するものでなくてはならない。構成要素およびルーチンは、必ずステータス表示子を生成すべきであり、ルーチンから返されるエラーは必ず検査すべきである。すべての入力データは、要求仕様に合っているかどうか必ず検査すべきである。さらに、システムやその対象領域に関する特定の知識を根拠に、ルーチン呼び出しが正常に終了することが保証されていると想定してはならない。エラーやシステムの異常を適切に報告できなかったり対応できなかったりすると、システム全体の運用継続性が脅かされる。
ISO/IEC TR 24772:2013のセクション6.39.5[ISO/IEC TR 24772:2013]には次の緩和策が記述されている。
ソフトウェア開発者は、脆弱性やその影響を以下の方法で回避したり緩和したりできる。
- 障害処理の方法を定めておく。よく似た要素に対する障害処理には一貫性を持たせる。
- 多層的なアプローチで障害防止、検知、対応を行う。
- 障害処理の一貫性維持に役立つ、システム定義の構成要素をできるだけ利用する。たとえば、「実行時制約ハンドラ」([C言語仕様]の付属書Kに規定)を作成することで、さまざまなエラー条件に対して、直前のトランザクションを破棄して次のトランザクションから再開するなどといった、一貫した対応をとることができる。
- 複数のタスクがあるときの障害処理方針を明確にする。
- タスクを停止するが、リソースは確保したままにする(障害のあったタスクを再スタートできるように)
- タスクを停止し、使用していたリソースを解放する(他のタスクが再使用できるようにしたり、タスクを再作成できるように)
- タスクを停止し、プログラムの他の部分に対しても同様に停止するように通知する
リスク評価
一貫性のあるエラー処理方針を採用し実施しないと、システムの運用継続性に支障が生じ、システム運用上の特性に応じてさまざまな脆弱性を生む可能性がある。
レコメンデーション |
深刻度 |
可能性 |
修正コスト |
優先度 |
レベル |
---|---|---|---|---|---|
ERR00-C |
中 |
中 |
高 |
P4 |
L3 |
関連するガイドライン
CERT C++ Secure Coding Standard | ERR00-CPP. Adopt and implement a consistent and comprehensive error-handling policy |
ISO/IEC TR 24772:2013 | Termination Strategy [REU] |
MISRA-C | Rule 16.1 |
MITRE CWE | CWE-391, Unchecked error condition CWE-544, Missing standardized error handling mechanism |
参考資料
[Fisher 1999] | |
[Horton 1990] | Section 11, p. 168, and Section 14, p. 254 |
[Koenig 1989] | Section 5.4, p. 73 |
[Lipson 2000] | |
[Lipson 2006] | |
[Summit 2005] | C-FAQ Question 20.4 |
翻訳元
これは以下のページを翻訳したものです。
ERR00-C. Adopt and implement a consistent and comprehensive error-handling policy (revision 60)