システム設計で意識すべきセキュリティ【8つの原則を理解する】 - 底辺サラリーマンが学ぶべきビジネススキル集

セキュアな設計のために意識すべき8つの原則

システム設計時点で、セキュリティ対策を講じなければばならない。なぜならば、開発後にセキュリティを高めようとしたところで、余計なコストや期間が必要になってくるからだ。そのため、設計時点からセキュリティを意識する必要がある。

では、何を意識すれば、良いのか。

意識すべき設計原則は、以下の8つの原則である。

システムは小さく、単純、且つ素直な設計とすること
明示的に許可されていない限り、デフォルトとして拒否すること
セキュリティ機能がすべての処理に仲介すること
設計を隠すことに依存した設計としないこと
権限を分離すること
必要最小限の権限を利用すること
複数ユーザが共有し依存する規模を最小限にすること
ユーザが無意識に保護の仕組みを利用できる設計とすること

1975年から引き継がれる原則

上記原則は「Saltzer & Schroeder」を参照し、カスタマイズしたものである。約50年前から引き継がれるものであり、この原則をもとに、様々なセキュリティ対策が立案されている。そのため、各企業、各システムにおいても8つの原則を設計時点で意識して、チェック項目として落とし込めば十分である。

https://www.ipa.go.jp/files/000059838.pdf

チェック項目に落とし込む際の具体例

具体的に8つの原則がどういったことを指しているのかを確認しておく。

1. システムは小さく、単純、且つ素直な設計とすること

小さく、単純、且つ素直と言われても考え方にばらつきが出るため、設計パターンを定義することが必要である。設計パターンにおいて、やること、及びやらないことを定義する。　※以下リンク参考

codezine.jp

2. 明示的に許可されていない限り、デフォルトとして拒否すること

誤操作、誤動作が発生した場合でも、常に安全な方に制御することを意図し、フェイルセーフの考えを原則としている
たとえば車であれば、エンジンが故障した場合、エンジンの回転を制御できないような故障ではなく、回転が停止するような故障であれば、車自体が止まることになり安全である。このため、回転を止めるような故障モードへ自動的に（自然に）落とし込むような設計思想が、フェイルセーフとなる。

3. セキュリティ機能がすべての処理に仲介すること

ネットワーク経路で例えると、FWを1箇所に設置しても、実は出入り口が2箇所ある場合は、抜け道があり、セキュリティ的に意味がない。

4. 設計を隠すことに依存した設計としないこと

設計を隠すことに依存してしまうと、設計内容が知られたら終わりである。それよりは、安全性をパスワードなどの「比較的少数、且つ容易に変更可能な要素」に依存するべきである。それによって、第3者の検証も受けやすくなる。

5. 権限を分離すること

玄関の鍵で例えると、鍵を上下に2つ設置しておくと、どちらか取られて場合でも、侵入を未然に阻止できることになる。

6. 必要最小限の権限を利用すること

例えば、WEBサーバが乗っ取られて場合、同居しているメールサーバまで乗っ取られる可能性があるが、権限を最小限にしておけば、被害を最小限に食い止められ、メールサーバを実行できないので、乗っ取られなくで済む。

7. 複数ユーザが共有し依存する規模を最小限にすること

例えば、 /tmp や /var/tmp は共有で利用する場合があり、この場所で予期しない相互作用が発生した場合、情報流出の経路となる危険性を持っている。

8. ユーザが無意識に保護の仕組みを利用できる設計とすること

例えば、重要ファイルを暗号化する際に、いちいち暗号化するためのアプリケーションを立ち上げたり、暗号化するためのフォルダに保存しておくような施策は、ユーザー側の作業がひと手間かかるため、面倒臭がるユーザーもおり、抜け道を探そうとする。ただし、すべてのファイルやドライブを自動で暗号化する仕組みとしておけば、ユーザーは意識せずとも仕組みを利用できる。