背景
セキュリティ設計にも何かSOLID原則や、コンポーネント原則といった
設計原則の思想を持ち込めるのではないか？と考えていた矢先に、
Findy主催の認証系のイベントで自分の仮説の検証ができるいい気付きを得られたので
ここに残したいと思います。
前提知識
リスコフの置換原則
これはSOLID原則のLです。
よく見かけるインターフェイスの公開メソッドをオーバーライドした実装側では、
インターフェイス側の戻り値の型がXと指定されていたら、XまたはXのサブタイプの型でないといけないなど、
インターフェイス側で指定された、事前事後条件を共に満たしていないといけない。
そうでないとポリモーフィズムが成立しない。
これは抽象クラスや具象クラスを継承し、スーパータイプの方だけをクライアントに公開したい場合も同様。
この場合には、事前事後以外にも、属性があり得るので不変条件まで継承先では満たさないといけません。
インターフェイス側でのアクセス修飾子を引き継いだpublicのままであったりは(publicより緩いアクセス修飾子ないから)、ここから来ています。
ここでは継承元がインターフェイスなのか、抽象クラスなのかに依らず、
実装先でオーバーライドして呼び出し側からは、インターフェイスまたは抽象クラスしか視えていない
ような時の継承を 型を継承しているとして意味継承と呼ぶことにします。
また投げる例外とかは事後条件に該当していますね。
※ここでは省略しますが、非検査例外時の意味継承は気を付けてください。
検査例外と違ってコンパイラーがエラー出してくれないので、最悪クライアント側が例外処理できず落ちます。
演繹法
演繹法は前提法則に当てはめて未来に起こる結果を推測する推論法です。
もしもその結果が外れた場合には、当てはめた前提が違っていたということになり得ます。
そのように検証することから個人的には、
この前提法則がインターフェイスに、各具体な事象が実装クラスに相当すると考えると、
演繹法はリスコフの置換原則と似た関係構造になっていると感じます。
セキュリティポリシー
ポリシーとは方針であり、それは抽象的なものです。
ポリシーパターンなどといった名前のデザインパターンがあったりしますが、
あれは具象ルールの上位概念のインターフェイス部分を抜き取ったものを方針として定義しています。
その方針の事前事後条件という制約に従ってさえいれば、各々具体なルールはなんでもOKというもの。
これと同じことがこのセキュリティポリシーにも言えると感じました。
またセキュリティポリシーには、その企業ごとに取り決めているものから、
組織に依存しない業界ポリシーというものもあります。
それらをレイヤーで分けて考えると下図のようになります。
組織ポリシーの方が当然、業界ポリシーより具体な概念となります。
そしてそれらの間の関係は、意味継承でリスコフの原則を満たした関係性。
そして組織の抱えるプロダクトのセキュリティ要件は、
もしも組織セキュリティポリシーが存在していれば、図のように組織セキュリティポリシーを実現する形になっていなくてはいけません。
そしてもしも組織の抱えるプロダクトのセキュリティ要件を変えた方が、
顧客にとってかちのあるものであると、具体なプロダクトを通して知見として得られたなら、
前提となっている自分たちの組織のセキュリティポリシーを見直す必要があります。
これが具体での検証を通して、前提の抽象概念を変更するという上記の演繹法の発想です。
またこの組織のセキュリティポリシーを変える際には、
業界のポリシーの条件を満たすように変更しなくてはいけません。