原文
How to Strengthen Your Code: Essential Secure Design Principles for Developers
意訳+要約
Saltzer と Schroeder が概説した 8 つの基本原則と 2 つの追加原則が紹介されています。
重要で安全な設計原則
- 効率的なメカニズム
- 不要なアクセス パスを最小限に抑え、設計をシンプルかつコンパクトに保つ
- シンプル化のメリット
- 脆弱性の検査が容易
- 攻撃対象領域が減る
- 悪用される機会が減る
- 簡潔なハック的な記述は、時として混乱を招く可能性がある
- 簡潔さよりもクリーンなコードが優先
- フェイルセーフのデフォルト
- アクセスの決定は、除外ではなく許可に基づいて行う
- 許可ベースなら、ミスが起きても情報は守れる可能性が高い
- 除外ベースだと、エラーにより不正アクセスが発生する可能性がある
- 完全な調停
- データへのアクセスは、必ず権限チェックを受ける
- 権限に関する変更は即座に反映させる必要がある
- オープン設計の原則
- 暗号化システムのセキュリティはキーの秘密性のみに依存し、アルゴリズム自体は公開されるべき
- 効果的なセキュリティ設計は、実装をひどくすることはNG
- 隠蔽による安全性の確保は、根本的に間違い
- リバース エンジニアリングのリスク
- 設計文書が入手されるリスク
- セキュリティ監査とレビューの複雑化
- 権限の分離
- 複数の保護層
- 異なるメカニズムを使用する必要が
- すべてにアクセスできるスーパーユーザーに依存するのではなく、特殊な役割と権限を持つユーザーを作成する必要がある
- 最小権限
- 必要最小限の権限のみを与え、攻撃の影響を減らす
- デフォルトですべての権限を拒否し、必要に応じて段階的に権限を付与する
- 最も一般的でないメカニズム
- ユーザー間で共有されるメカニズムは最小限に抑える
- コンポーネント間の依存関係は、1 つが侵害されると広範囲に影響を受ける
- 共通変数を含むコンポーネントは、セキュリティ リスクを生み出す可能性が高い
- 心理的受容性
- 使いやすいUIを提供し、ユーザーが回避策を模索しないようにする
- セキュリティとユーザビリティは、トレードオフの関係にあるので、妥協点を探してバランスを取る
- 作業要因
- 攻撃者の動機と資産の価値を考慮して、セキュリティ対策を行う
- 過度なコストをかけすぎない
- 侵害の記録
- 効果的なログ記録と証拠収集
- 攻撃に気付かなければ、結果は深刻になる可能性がある
- 侵害を検出することは、損害を最小限に抑え、インシデント対応を促進するために必要
関連リンク
コンピューターセキュリティにおける基本原則：Saltzer & Schroederの8原則 | emgr
感想＋雑記
内容は一読して要約したつもりだけど、ちゃんと理解できているかは怪しいな。。。
特に、オープン設計の原則。言わんとしてることは分かるんだけど、秘匿の方が安全では？って思ってしまう。
普段心がけているクリーンコードが、最終的にセキュリティも高めてる認識でいる。
結局、シンプルかつ無駄のない実装が、影響範囲を局所化したり、無駄な脆弱スポットの作成を防止してくれるのだと思ってる。
効率的なメカニズムで言われているハック的な記述は、たまにしてしまうことがあるので、注意したい。アレを書くと、なんか自分がすごいヤツっぽく感じてしまうんだよねぇ。。。
第三者視点がないと、陥りがちな気がする。
あと、だいたい言っていることがISMSに似てるなぁ～とは感じた。
