ここでは、データセキュリティについて次の観点で解説します。
関連記事
データマネジメントの導入方法
データセキュリティとは
ではデータセキュリティを次のように定義しています。
セキュリティポリシーや手順を立案、開発、実行し、データ資産に対して適切な承認と権限付与を行、アクセスを制御し、監督すること
また、DMBOKでは、データセキュリティの活動目標を次のように定義しています。
- 全社データ資産に対して適切なアクセスを許可し不適切なアクセスを防止できるようになること
- プライバシー、保護、機密性に関する規則とポリシーを遵守できるようになること
- プライバシーと機密性に関するステークホルダーの要件が満たされていることを担保できるようになること
また、DMBOKであげているデータセキュリティに関する主な概念は以下です。
- 脆弱性
脆弱性とは攻撃や侵略を成功させてしまうシステム上の弱点や欠陥のことである。 - 脅威
脅威とは組織に対して起こり得る潜在的な攻撃的行動のことである。 - リスク
リスクは損失の危険性と潜在的な損失をもたらす物事や状況の双方を指す。 - データセキュリティ組織
データセキュリティ機能の全体については、通常、IT部門に属する専門のデータセキュリティグループが責任を負う。
大企業では、CIOやCEOの配下に最高情報セキュリティ責任者が置かれる。 - セキュリティプロセス
データセキュリティのプロセスは、アクセス（Access)、監査（Audit）、認証（Authentication）、認可（Authorization）という４つに分類される。
これを４つのAという。 - データセキュリティにおけるデータ完全性
不適切な変更、削除、追加から完全に保護された状態を表す。 - 暗号化
暗号化とは平文を複雑なコードに変換して社外機密情報を隠したり、送受信の完全性を検証したり、送信者の身元を確認したりする処理のことである。
主な方法には、ハッシュ、秘密鍵、公開鍵がある。 - 難読化またはマスキング
データの意味やデータと他のデータセットの関係を失うことなく、難読化（曖昧または不明瞭にする）やマスキングによってデータを利用できないようにする。
難読化は、参照用にセンシティブデータを画面に表示するときや、想定されるアプリケーションロジックに準拠した本番データからテスト用データセットを作成するときに役立つ。 - ネットワークセキュリティ
データのセキュリティには保存状態のデータと移動状態のデータの双方が含まれる。
移動状態のデータではシステム間を移動するためネットワークが必要である。
ネットワークを介したデータセキュリティの概念には、バックドア、ボットやゾンビ、クッキー、ファイアウォール、境界、DMZ、スーパユーザーアカウント、キーロガー、ペネとレーションテスト、VPNなどがある。 - データセキュリティの種類
データセキュリティは不適切なアクセスを防止するだけでなく、データへの適切なアクセスを可能にすることも含む。
データセキュリティの種類には、ファシリティセキュリティ（物理的セキュリティ）、デバイスセキュリティ、認証情報のセキュリティ、アイデンティティ管理システム、電子メールシステムのユーザーID標準、パスワード標準、多要素認証、電子通信セキュリティなどがある。 - データセキュリティ制限の種類
データの機密性レベルとデータ関連規制の２つの概念からデータセキュリティ制限が設定される。 - システムセキュリティのリスク
システムセキュリティのリスクにはネットワークやデータベースに損害を与える要素が含まれる。
このような脅威を放っておくと正当な従業員が意図的か偶発的に情報を誤用してしまったり悪意のあるハッカーに侵入を許してしまう。 - ハッキングやフィッシング
コンピュータータスクを実行する巧妙な方法を見つけることや、受信者を騙すメッセージを送ること。 - マルウェア
マルウェアとはコンピュータやネットワークに損傷、変更、不適切なアクセスをする目的で作成された悪意のあるソフトウェアを指す。
アドウェア、スパイウェア、トロイの木馬、ウィルス、ワーム、スパムなどがある。
さて、一般的に知られている言葉に情報セキュリティがあります。
情報セキュリティとは、一般的には、情報の機密性、完全性、可用性を確保することと定義されています。
- 機密性(Confidentiality)
ある情報へのアクセスを認められた人だけが、その情報にアクセスできる状態を確保すること。 - 完全性(Integrity)
情報が破壊、改ざん又は消去されていない状態を確保すること。 - 可用性(Availability)
情報へのアクセスを認められた人が、必要時に中断することなく、情報にアクセスできる状態を確保することをいいます。
それでは、情報セキュリティとデータセキュリティは何が違うのでしょうか。
DMBOKでは、セキュリティポリシーを次の３つに分類しています。
- 全社セキュリティポリシー
施設やその他資産への従業員のアクセス、電子メールの基準とポリシー、地位や肩書きに基づくセキュリティアクセスレベル、セキュリティ違反報告ポリシーなどグローバルポリシー - ITセキュリティポリシー
ディレクトリ構造の基準、パスワードポリシー、アイデンティティ管理フレームワーク - データセキュリティポリシー
個々のアプリケーション、データベースのロール、ユーザーグループ、情報のセンシティビティに関するカテゴリ
そこで、ここでは、情報セキュリティを、次のように全社セキュリティ、ITセキュリティ、データセキュリティに分けて考え、データセキュリティの部分を取り上げたいと思います。
- 全社セキュリティ
物理的な設備に対する人のアクセスも含めて、企業全体の最も広い範囲のセキュリティを扱う。 - ITセキュリティ
ハードウェア、ネットワークの内部にアクセスするための認証（Authentication）などハードウェア、ネットワークレベルのセキュリティを扱う。
ITセキュリティは、全社セキュリティを継承する。 - データセキュリティ
個々のアプリケーションがアクセスするデータも含めてデータにアクセスするための認可（Authorization）などデータレベルのセキュリティを扱う。
データセキュリティは、ITセキュリティを継承する。
データセキュリティ組織
DMBOKには、データセキュリティ組織について次のように記述されています。
情報セキュリティ機能の全体については通常、IT部門に属する専門の情報セキュリティグループが主として責任を負う。
大企業ではCIOやCEOの配下に最高情報セキュリティ責任者（CIO：Chief Information Security Officer）が置かれる。
専任の情報セキュリティ担当者がいない組織では、データセキュリティに対する責任はデータ管理者に委ねられる。
いづれのケースでも、データ管理者はデータセキュリティの取り組みに関与する必要がある。
また、データセキュリティの原則として次のように記述されています。
データセキュリティはITセキュリティ管理者、データスチュワード・データガバナンス、社内外の監査チーム、法務部門を含む共同作業である。
ここでは、情報セキュリティの分類と、それを実行する職務の関係を次のように考えます。
データガバナンス実行者については、データガバナンス組織の設計を参照ください。
データセキュリティプロセス
データセキュリティは次のようなビジネスプロセスで実行されます。
データセキュリティの設計
データセキュリティは、データマネジメントの設計の一環として設計されます。
データセキュリティの設計手順は次のようになります。
データセキュリティポリシーの定義
データセキュリティポリシーは、情報セキュリティポリシーを踏襲します。
情報セキュリティポリシーは、「基本方針」、「対策基準」、「実施手順」の3つの階層で構成されることが一般的です。
基本方針には、組織や企業の代表者による「なぜ情報セキュリティが必要であるのか」や「どのような方針で情報セキュリティを考えるのか」、「顧客情報はどのような方針で取り扱うのか」といった宣言が含まれます。
対策基準には、実際に情報セキュリティ対策の指針を記述します。多くの場合、対策基準にはどのような対策を行うのかという一般的な規定のみを記述します。
実施手順には、それぞれの対策基準ごとに、実施すべき情報セキュリティ対策の内容を具体的に手順として記載します。
データセキュリティポリシーは、情報セキュリティポリシーの基本方針に対応します。
NPO日本ネットワークセキュリティ協会の情報セキュリティポリシーの基本方針のサンプルを紹介します。
情報セキュリティ基本方針
情報セキュリティ方針
データセキュリティ基準の定義
データセキュリティポリシーは、情報セキュリティポリシーの対策基準を踏襲します。
NPO日本ネットワークセキュリティ協会の情報セキュリティポリシーの対策基準のサンプルを紹介します。
全社セキュリティポリシー関連対策基準
人的管理規程外部委託先管理規程監査規程物理的管理規程リスク管理規程セキュリティインシデント報告・対応規程
ITセキュリティポリシー関連対策基準
データセキュリティポリシー関連対策基準
文書管理規程システム開発規程システム変更管理規程システム管理規程システム利用規程
DMBOKでは、データセキュリティ基準として、データ機密レベル、および、データ規制対象カテゴリを定義し、ビジネスメタデータ（データ項目レベル）として設定することで、企業の全部門がセンシティブなデータに必要とされる保護レベルを正確に把握できるようにする必要があると説明しています。
データ機密レベル
組織は、組織の外部や組織の特定の部門内においてでさえ知られてはならい機密データの機密レベルを決定します。
機密レベルは次の例のように「知る必要がある」かどうかという基準で設定します。
- 公開用
公衆を含む誰でも利用できる情報。 - 社内向け
情報は社内のメンバーに限定されるが、共有した場合のリスクは最小限である情報。
組織外部に向けて表示したり、説明することはできるがコピーすることはできない。 - 社外秘
適切に結ばれた機密保持契約や、それに類するものがない場合は、組織外で共有することができない情報。 - 制限付機密
「知る必要がある」一定のロールを持つ個人に限定された情報。
制限付機密データにアクセスするには、個人が権限付与手続を踏む必要がある。 - 登録者限定機密
非常に機密レベルが高い情報で、データにアクセスするためには、情報にアクセスするすべての人が法的な合意に署名し、秘密のための責任を負わなければならない。
データ規制対象カテゴリ
特定の種類のデータは、外部の法律、業界標準、契約によって規制されます。
組織は、次の例のように、業務上のニーズを満たす規制対象グループを定義する必要があります。
法律上の規制
- 個人識別情報（PII：Personal Identification Information）
個人の私的情報で、氏名、住所、電話番号、スケジュール、政府のID番号、年齢、人種、宗教、民族性、誕生日、家族の氏名や仲間の名前、雇用情報（人事データ）、報酬など、個人一人一人を識別できる情報が含まれるもの。
日本の個人情報保護法、EUのプライバシー指令、PCI基準、米国FTC要件など。 - 財務上のセンシティブデータ
インサイダーデータと呼ばれるもので、また、公表されていない現在の財務情報を含む、すべての財務情報を指す。
さらに、未公開の将来事業計画、計画中の合弁、買収、分割、非公開の重要な企業問題、突発的な上級管理職の変更、包括的な売上、注文、請求データも含まれる。
米国ではインサイダー取引法、SOX法、GLBAの対象となっている。 - 医療上のデータ/個人健康情報（PHI:Personal Health Information）
個人の健康や医療に関するすべての情報。
米国では、HIPAAの対象。 - 教育記録
個人の教育に関するすべての情報。
米国ではFERPAの対象。
業界、契約に基づく規制
- PCIデータセキュリティ基準（PCI-DSS：Payment Card Industry Data Security Standard）
名前、クレジットカード番号、銀行口座番号、アカウントの有効期限など、金融機関のアカウントで個人を識別できる情報を対象としている。 - 競争上の優位性、企業秘密
企業は競争上の優位性を達成するために独自の方法、混合物、数式、ソース、デザイン、ツール、レシピ、運用技術を利用する場合、業界の規制や知的財産法によって保護される。 - 契約上の制限
ベンダーやパートナーとの契約において、組織は特定の情報の一部がどう利用できるかできなか、どの情報が共有できるかできないかを規定することがある。
環境レコード、有害物質報告、バッチ番号、調理時間、原産地、顧客パスワード、口座番号など。
データセキュリロールの定義
データの機密レベル、データ規制対象カテゴリ、ユーザー機能に基づいて、データセキュリティロールを定義し、それに個々のユーザーを割り当てます。
企業で定義された職務（ジョブ）をデータセキュリティロールとして用いても構いません。
セキュリティロールを定義するときは、該当データにどのようにアクセスできるか、許可されるアクセスも含めて定義するようにします。
例えば、許可されるアクセセス（Permission）を、CRUD（Create,Read,Update,Delete）で定義します。
データセキュリロールの定義例
この例の場合、マーケティング担当者は、キャンペーン用の個人識別情報（PII）に対して部分的にアクセスできますが、制限されたデータや顧客機密データにはアクセスできません。
データセキュリティ実施手順の定義
DMBOKには、データセキュリティのコントロールと手順には少なくとも次のことが含まれるべきだと説明しています。
- ユーザーがシステムやアプリケーションへのアクセス権をどのように取得し、喪失するか
- ユーザーがどのようにロールを割り当てられ、削除されるか
- 権限レベルをどのように監視するか
- アクセス変更の要求がどのように処理され、監視されるか
- 機密性と適用される規則に従ってどのようにデータを分類するか
- 検出されたデータ侵害にどのように対処するか
データセキュリティ実施手順を定義する例は次のようになります。
- データアーキテクチャのEDM（エンタープライズデータモデル）をベースに事業パーパスの実現を阻害する可能性のあるデータを選定する
マスターデータは全てセキュリティ重要なデータです。 - そのデータに対して、データマネジメントポリシーの対策基準で定義された機密レベルと規制を設定し、ビジネスメタデータとしてデータカタログに登録する
- データの機密レベル、規制に対応するアクセス権限を持つセキュリティロール（ジョブ）を定義する
※ユーザーはセキュリティロールに割り当てられる - データアーキテクチャのデータフローから上記データのライフサイクルに関係するビジネスプロセスと、データを管理するシステムを明確にする
- データを管理するシステムの非機能要件として、セキュリティ要件を定義し、それが解決できるよう、セキュリティロールに対応するアクセスコントロールや、データマスキングやビューの作成などによるデータ可用性の制御をする手順を定義する（実際にシステムが設計されたかどうかは下記データ設計の検証でチェックされる）
- データのライフサイクルに関係するビジネスプロセスで、実際にデータのライフサイクルに関わるアクティビティ（データの生成・取得、変換・蓄積、利用、破棄）に対するデータセキュリティ検証手順を、データマネジメントポリシーの実施手順（Procedure）として定義する（下記データ生成・取得の検証などでチェックされる）。
例えば、人事データにアクセスするアクティビティがある場合、定期的に、トランザクションログなどを使って、実際にどのユーザーがどのシステムのどのデータにどのようにアクセスしたか（CRUD）調査し、アクセス権限が有効になっているか、正しい方法でアクセスされたか（SQLなど）など検証する手順が定義されます。
データセキュリティ計画の策定
の「データマネジメント計画の策定」の一環として設計されます。
データ利用者のアクセスコントロール
の「データ利用者のアクセスコントロール」を参照してください。
データセキュリティの検証
の「データマネジメントの実施」プロセスの一環として実行される、セキュリティの監視プロセスです。
※例えば、データマネジメントプロセスの「データ生成・取得の検証」を参照してください。
データセキュリティの検証では、定期的に、上記データセキュリティ実施手順で定義された手順に従ってデータセキュリティが機能しているか検証します。
例えば、トランザクションログなどを使って、実際にどのユーザーがどのシステムのどのデータにどのようにアクセスしたか（CRUD）調査し、アクセス権限が有効になっているか、正しい方法でアクセスされたか（SQLなど）確認します。
これによって、データ資産にアクセスしているユーザーに関する情報やアクセス方法に関する情報が獲得でき、異常で突発的で不審な処理を検出できるようになります。
アクセスの挙動の監視と異常の検出をシステムで自動化することもできます。
もしアクセスの異常がインシデントとして検出されたら、問題解決のプロセス（PDCA）を実行するようにします。
データセキュリティ計画の検証
の「データマネジメント計画の検証」の一環として検証されます。
データセキュリティ計画の改善
の「データマネジメント計画の改善」の一環として改善されます。
[…] セキュリティ データの機密性、完全性、可用性が確保できているか […]
[…] 。 情報セキュリティについては、データセキュリティとはを参照してください。 […]
[…] システム品質の一部としてデータの信頼性やセキュリティに関する要件も定義します。 […]
[…] 情報は、組織の全てのレベルでリスクを識別、評価、対応し、さらには事業体を運営し、その目的達成のために必要です。 なので、的確な情報を収集、捕捉、加工、分析し、報告するにいたるデータライフサイクル全体を渡ってデータ価値、品質、セキュリティを管理するデータマネジメントの導入は重要です。 特に、適切な情報が、適切な形式かつ適切な詳細度で、適切な人に適時に行き渡らせるようにすることを確実にするデータ品質や、データセキュリティの管理は重要です。 […]