主張
データ利活用のためInformationビューのあとのデータには、
品質指標の定義ができた方がデータ観点での品質考慮もできていい。
基本的に考察結果から、大体いまのUAFと同じ構成配置になると考えられる。
以下で言うデータとは業務データと分析データ両方のことを指す。
背景
最近品質保証や品質管理について興味関心が強く、
その中のセキュリティについても探究心が強くなってきた。
というのもあらゆるものが繋がる世界においては、
セキュリティは単なる品質の１つという枠だけでなく、
必ず考慮しなくてはならない横断的関心事だと痛感してきたからである。
しかしながらセキュリティをただ強めればいいってもんでもなく、
強くし過ぎたがためにコストがかかりまくる、
データの利活用がしにくいといった事態に繋がって、
それが上位の目的を阻害してしまっては、何のためにセキュリティを強化したのか本末転倒になってしまう。
戦略的セキュリティ設計
あらゆるデータに対して一様にセキュリティを高めるというのは、
コストも無駄遣いしてしまうし、データによって利便性高くあってほしいもの、
そうではないものとまちまちであるはずだ。
そのため、データごとにセキュリティの強さはメリハリを持たせた戦略的設計が重要である。
さらには、法律の変化やステークホルダーの関心の変化などによって、
当然データに求められるセキュリティの強さなども変わってくる。
ここでいろんなデータが大量にあるとそのメンテコストもかかってくるし、
データの構造だって当然変化していくもの。
不要なデータが残ったままでは、それのメンテする必要性が出てきたり、
それによって本当に重要なデータ群に対する再設計にかかる労力などのコストが足りなくなってしまいかねない。
そこでセキュリティのそもそものWhyにあたる考察、
こんなデータはどの程度重要であり、決して悪用されることは許されない。
などを考えるデータの観点での企画～要件定義に立ち返ることにした。
データの企画～要件定義
データ構造も動的構造と一緒で、上位概念ほど安定していて、
下位の具体レイヤーに行けば行くほど変化が起こりやすい不安定な構造になっていることが
メンテナンス性が高いといえる。(データクリーンアーキテクチャと呼ぶことにする)
まずそもそもデータの制約
・一般データ保護規則
・消費者プライバシー法が前提制約としてある。
この制約をもとにして、データの観点でのAsIs-ToBeやリスク分析が必要である。
これもまた各種データがどのような能力値(加工のしやすさ、想定される利活用頻度)
があるべきなのか？
このデータは特に重要であり、閉じた領域でのみ活用したいのか？
それとも他の限られた領域にも相互展開していきたいものなのか？
といった品質特性の考察や、実際にそのデータを採取しようとするとコスト的に可能なのか？
仮説でもいいからそのデータを採取して利活用することで、どのくらいの利益を生むと考えられるのか？
といったことまで考察するだけでなく、
データフロー図などを用いて、データに対する脅威シナリオを想定したうえで、
リスク分析結果からデータのセキュリティを利便性などの他の観点と考慮したうえでデータの要件定義を行う。
もちろん、データも変えていかなくてはならないので、
事前に「この数値をこの頻度で下回ってきたら、データアーキテクチャの再検討をする」
「法律の改定といった前提条件が変わったら再検討する」
という運用面での要件定義も事前にしておくことが重要である。
データのリスク分析
先にKPIツリーを作成しておいて、データの構造のベースを作成しておく。
そのうえで、「このデータは今までにないうちだけのブランドを表す変数であるため、
他に漏らしたくないものである」といったものや、
「このデータが流出または悪用されたら、甚大な被害が発生する」
「不整合が起きたことで甚大な混乱が起きる」という脅威シナリオの分析をしてみる。
これもあらゆる脅威シナリオを検討するのではなく、
あくまでも脅威自体の発生頻度の多さ、経営へのインパクトの大きさ、
そのデータ自体の現在の脆弱性といった考察の上で、ピンポイントで重要な脅威シナリオに専念するべきである。
脆弱性っていうのは、結局どの程度セキュリティが高くあってほしいのか？
というToBeと、現在のそのデータ自体のセキュリティの強さAsIsによって決まってくる。
ここのギャップがさほどない所をコストかけて脆弱分析したところであまり意味はないからだと考えている。
データの品質特性同士のトレードオフ
データの品質には代表的なものとして、CIAがあげられる。
これらは互いにトレードオフな部分がある。
データ面の運用
データの要件が決まれば、その要件を本当に満たせているのか？
常に監視できるように、何を監視すればいいのか？まで事前に定義しておく。
「本当に当初の想定の範囲内の利用頻度なのか」
「本当に当初の想定の範囲内の加工のしやすさなのか」
「本当に当初の想定の範囲内のリスク軽減ができているのか」
「この領域は当初の想定のように同時にデータ構造が変更されるか」
「統制の甘さによって、内部のユーザによって予期せぬ使われ方をしていないか」
「データのコンテキストを分けてしまったがために予期せぬ不整合は起きていないか」
といった重要なデータにおける品質が保証されてるのか？を監視する。
想定してた脅威と思われる者以外からの予期しなかった悪用の監視も必要である。
この辺は別にデータ観点特有の考え方でなく、一般的なリスク分析と同じ考え方だ。
データガバナンス
データの脅威分析が終わったら、今度はその分析結果をもとに
データ観点でのルール決め、データガバナンスを定義しなくてはいけない。
そのビジネス固有のデータ観点でのルール決めである。
それによってリスクの回避や軽減をできる仕組みをデータの側面でも作成するのが、
このデータガバナンスの目的である。
ここでの考え方もリスコフの置換原則を思い出してほしい。
下位特有のルールが、より上位のルールに従っていない、
リスコフ置換原則違反を起こしていないかのチェックはマストである。
データの側面でもこの設計思想は引用できると考えている。