信頼できるデザイン

セキュリティアーキテクチャと設計原則

セキュリティ三要素とセキュリティ設計原則

  • 完全性(Integrity)
  • 可用性(Availability)
  • 機密性(Confidentiality)

オープンデザイン原則

Open Design

  • 設計は秘密であってはならず、オープンな設計の方が安全である。
  • セキュリティは秘匿に依存しない。

フェイルセーフデフォルト原則

Fail-safe defaults

  • アクセス判断は「許可」に基づき、「拒否」に基づかないこと。
  • デフォルトではアクセスを許可せず、保護メカニズムは許可されたアクセスを識別するだけである。
  • フェイルセーフ:複雑なシステムは機能停止時の緊急安全メカニズムを持つべきであり、さらにエラーメッセージやログには注意を払い、情報漏洩を防ぐこと。
  • デフォルトセーフ:システムは初期状態で最小限のシステムとサービスを使用して最大の安全性を提供するデフォルト設定を持つべきである。

権限分離原則

Separation of Privilege

  • 保護メカニズムを解除するには1本の鍵より2本の鍵を使用した方が堅牢で柔軟である。
  • 権限分離の目的
  • 利益相反を防ぎ、個別の権力の乱用を防止する。
  • 重要な権限を複数の権限に分解し、保護対象が不正に取得されにくくし、より安全にする。
  • 異なるプロセスの権限と責任を分離する。

システムはデフォルトで3つの役割を設定でき、各システムアカウントの権限は相互に独立し、権限と責任が分離される:

  • システム管理者:システムの日常的なユーザー管理、設定管理を担当。
  • セキュリティ管理者:ユーザー状態、セキュリティ設定の有効化・無効化管理を担当。
  • セキュリティ監査員:上記2者の操作をログ監査し、ログ出力権限を持ち、システムユーザーの全操作の追跡可能性を保証する。

最小権限原則

Least Privilege

  • システムのすべてのユーザー、すべてのプログラムは、仕事を完了するために最小かつ必須の権限セットを使用すべきである。
  • アプリケーションが最低限の権限で実行されることを確保する。
  • データベース、WEBサーバー等のシステム上の各ユーザーのプログラム実行や接続には注意を払い、システムの最高権限アカウントであってはならない。
  • 新しいアカウントを作成する際、デフォルトで最小権限の役割を付与する。

経済的メカニズム原則

Economy of Mechanism

  • システム設計とコードを可能な限りシンプルかつコンパクトに保つ。
  • ソフトウェア設計が複雑になるほど、コードにバグが発生する確率が高くなる。設計をできるだけ巧妙にすれば、セキュリティ問題が発生する確率は小さくなる。
  • 必要のない冗長コードや機能モジュールを削除し、そのコードを残すことはシステムの攻撃面を増加させるだけである。
  • 冗長コードを減らすために再利用可能なコンポーネントを設計する。
  • 経済的適用:シンプルで巧妙、コンポーネント化。
  • 設計過多を避ける。

最小共通メカニズム原則

Least Common Mechanism

  • 複数のオブジェクトが同じリソースを共有するシナリオをできるだけ避けること。リソースへのアクセス共有の数と使用は可能な限り最小化すべきである。
  • 共有オブジェクトは情報フローと意図しない相互作用の潜在的危険なチャネルを提供するため、複数のオブジェクトが同じリソースを共有するシナリオをできるだけ避けること。
  • 1つまたは複数のオブジェクトが共有メカニズムが提供するサービスに満足しない場合、他のオブジェクトのバグによる間接的な攻撃を避けるために共有メカニズムを使用しない選択肢を持つべきである。
  • 共有メモリの最小化
  • ポートバインディングの最小化
  • 接続を減らし、DoS攻撃を防御する。

完全仲介原則

Complete Mediation

  • 完全仲介原則は、各オブジェクトへのすべてのアクセスがセキュリティチェックを経由しなければならないと要求する。
  • 主体が客体にアクセスしようとするとき、システムは毎回主体がその権限を持っているかを検証する。
  • 可能な限り、リソースの所有者自身がアクセス制御の決定を行うべきである。たとえばURLの場合、バックエンドサーバーがチェックし、フロントエンドでの判断は避けること。
  • キャッシュの使用とチェックに特に注意すること。キャッシュされた情報がハッカーに改ざんされていないことを保証できない。例:DNSキャッシュポイズニング。

心理的許容原則

Psychological Acceptability

  • セキュリティメカニズムはユーザーに追加の負担をかける可能性があるが、その負担は最小限かつ合理的でなければならない。
  • セキュリティメカニズムはシステムユーザーにとってできるだけユーザーフレンドリーで、システムの使用と理解を容易にすべきである。
  • 設定方法が複雑で煩雑すぎると、システム管理者が誤った設定をしてしまい、結果的にシステムが安全でなくなる可能性がある。
  • この原則は一般的に人間工学、UCD(User Centered Design)インターフェースに関連する。

深層防衛原則

Defense in Depth 深層防衛は非常に包括的で高い防御原則であり、一般的にシステムアーキテクトが他のさまざまなセキュリティ設計原則を総合的に活用し、複数のポイントと多重のセキュリティ検証メカニズムを採用し、システムアーキテクチャの観点から全体的なシステムレベルのセキュリティ防御メカニズムに注目し、単一のセキュリティメカニズムに依存してはならないことを要求する。