Saltzer [1974] と Saltzer and Schroeder [1975]では、設計に当たって安全を 保護するのに、下記のような原則をまとめています。これは今なお有益です。
特権をできるだけ持たせない。 ユーザやプログラムにはできるだけ権限を持たせないようにしてください。 そうすれば、アクシデントやエラー、攻撃者によるダメージが最小限に抑えられ ます。 また、こうすることで特権をもったプログラム間相互の影響を可能な限り抑えら れるので、意図しない不要で不適切な特権を利用しなくなります。 このアイディアはプログラム内にも採用できます。プログラムの最小限の部分に だけ必要となる特権を持たせてください。 やり方の詳細は、Section 6.4 を見てください。
仕組みを単純に。 防御システムは小さく単純明快に設計します。 彼らによれば、 「ソフトウェアを一行毎に調査したり、ハードウェアを調査して、防御機構の実装を するテクニックが必要になったりします。 テクニックがうまくいくには、小さくかつ単純明快な設計が基本になります」 これを「KISS」の原則(「keep it simple, stupid」(こら、短くしとけ))と表現 する場合があります。
オープンな設計。 防御する仕組みは、攻撃者がその仕組みの知識を持ってないことに頼っては いけません。 そのかわり、公開された仕組みで、パスワードや秘密鍵のように比較的少ない項目 (そして簡単に変えられる)で秘密を守れるようにしてください。 オープンな設計は、広範囲な公開された精査が可能で、そうすることでユーザが そのシステムの利用が適切なのどうかを納得できます。 率直に言って、広く配布したシステムを密かにメンテナンスしようとするのは、 現実的ではありません。 デコンパイラ(逆コンパイラ)やハードウェアを壊してしまうことで、あっと言う間 にあらゆる「秘密」がばれてしまう可能性があります。 Bruce Schneier 氏は、頭の切れるエンジニアならば、「セキュリティに関する すべてのコードは、オープンソースであった方が良いと主張する」としています。 またそうすると、広く第三者からレビューを受けられ、そこで問題となった部分も 修正されることを証明しています[Schneier 1999]。
完全に仲介を行うこと. すべてのアクセスをチェックしなければいけません。チェックする仕組みは、壊され ない場所に置いてください。 たとえば、クライアント・サーバモデルであれば、サーバ側ですべてのアクセス をチェックする必要があります。それはユーザがクライアント側を新しく作成したり、 既存のものを修正したりできるからです。 これは、Chapter 4 や Section 6.2 にも 該当します。
フェイル・セーフをデフォルトとする(たとえば、 パーミッションを活用する方法)。 デフォルトではサービスを拒否してください。防御機構はどのアクセスを許可 しているのか、状況を認識していなければいけません。 詳しくは、Section 6.7 と Section 6.9 を見てください。
権限を集中させない。 対象へのアクセスに当たって、複数の条件をつけるのが理想的です。 そうすれば、もしある防御システムが破られても、無制限なアクセスを許すよう にはならないからです。
共通した仕組みはできるだけ用いない. 共通する仕組みの数とその利用度合を最小限にしてください(たとえば、/tmp や /var/tmp の利用)。 仕組みを共通化すると、そこが情報の流れの中で危険な経路になってしまったり、 予期しない相互作用が発生したりする恐れがあります。詳しくは、 Section 6.10 を見てください。
気持ちで受け入れられるか、簡単に使えるか。 ヒューマン・インタフェースは、ユーザが日常何気なく正しい防御の仕組みを使え るように、使いやすく設計しなければいけません。 セキュリティの仕組みがユーザが思い描く防御の目標とマッチしたなら、過ちは 減るでしょう。
セキュリティについての設計上の原則をいろいろと網羅している資料が Peter Neumann's CHATS Principles にあります。