概要
DMBOKをベースにしたデータストア(データレイク、RDBMS、DWH等)におけるデータへの権限付与に関する指針を作成するための情報を整理します。
システムごとにばらばらとなっている用語の統一化による標準化を実施します。
データストアにおけるセキュリティプロセス
DMBOKにおいてデータストアにおけるセキュリティプロセスは下記のように記載されており、今回は権限付与を検討します。一般的には、データへの認可やデータアクセス制御と呼ばれる場合があります。
- アクセス:権限を持つ個人がタイムリーにシステムにアクセスできるようにする。
- 監査:セキュリティ対策とユーザーアクティビティを確認して、規制の遵守と企業の方針や基準へ確実に適合しているかを確認する。
- 認証:ユーザーのアクセスを検証する。
- 権限付与:割り当てられたロールに応じて、特定のビューを通してデータにアクセスできる権限を個人に付与する。
- エンタイトルメント:エンタイトルメントとは一度のアクセス権限によって一人のユーザーに公開されるデータエレメントの集合である。
引用元:DMBOK 2nd 第7章データセキュリティ
データストアへの権限付与
データストアに対する権限付与の分類
データストアへの権限付与方法には、下記に示すがあります。
- データストアシステムへの権限付与
- SQL命令(DDL、DCL)相当に対する実行の権限付与
- オブジェクト(スキーマ)一覧の閲覧の権限付与
- 子オブジェクトへの継承の権限付与
- データ参照の権限付与
- データ挿入・更新・削除の権限付与
- 他データストアに対するデータアクセス者の認証による権限付与
- 他データストアへのデータアクセス者のシングルサインオンに基づいた認証による権限付与
- 他データストアへのデータアクセス者の所有アカウントに基づいた認証による権限付与
- データへの権限付与
- 行レベルセキュリティ
- ルールベースによる行レベルセキュリティ
- データ権限(認可)テーブルを利用した行レベルセキュリティ
- 列レベルセキュリティ
- 列への参照権限付与による列レベルセキュリティ
- マスキング
- 永続データマスキングによる列レベルセキュリティ
- 動的データマスキングによる列レベルセキュリティ
- 行レベルセキュリティ
データストアに対する権限付与の用語
番号 | 用語 | 説明 | 評価対象 |
---|---|---|---|
10000 | データストアシステムへの権限付与 | データストアにおけるシステム全般に対する利用を許可すること。 | |
11000 | SQL命令(DDL、DCL)相当に対する実行の権限付与 | データ定義言語(Data Definition Language)、データ制御言語(Data Control Language、DCL)相当の実施を許可すること。データレイクにおけるフォルダ作成を含む。 | 〇 |
12000 | オブジェクト(スキーマ)一覧の閲覧の権限付与 | データのファイル、テーブルなどのデータを保持しているオブジェクトの一覧を取得を許可すること。 | 〇 |
13000 | 子オブジェクトへの継承の権限付与 | あるオブジェクトにおける子関係にあるオブジェクトに対して、権限の継承を許可すること。 | 〇 |
14000 | データ参照の権限付与 | データストアが保持しているデータを参照を許可すること。 | 〇 |
15000 | データ挿入・更新・削除の権限付与 | データストアに対して、データを挿入・更新・削除を許可すること。 | 〇 |
16000 | データストアに対するデータアクセス者の認証による権限付与 | 他のデータストアにて設定されている権限を利用して、データ利用を許可すること。 | |
16000 | 他データストアへのデータアクセス者のシングルサインオンに基づいた認証による権限付与 | シングルサイオン(Kureberos認証、SAML認証)により他のデータストアにて設定されている権限を利用して、データ利用を許可すること。 | 〇 |
16000 | 他データストアへのデータアクセス者の所有アカウントに基づいた認証による権限付与 | データアクセス者が所有しているアカウントにて、手動で他のデータストアにて設定されている権限を利用して、データ利用を許可すること。 | 〇 |
20000 | データへの権限付与 | データストアにおけるデータに対する利用を許可すること。 | |
21000 | 行レベルセキュリティ | レコード(行)へのアクセスを制限すること。 | |
21100 | ルールベースによる行レベルセキュリティ | 指定したデータ値に基づいたレコード(行)へのアクセスのみに制限すること。 | 〇 |
21200 | データ権限(認可)テーブルを利用した行レベルセキュリティ | ユーザーとマッピング可能なデータ値に基づいたレコード(行)のみに制限すること。 | 〇 |
22000 | 列レベルセキュリティ | データに列、および、列の値に対するアクセスを制限すること。 | |
22100 | 列への参照権限付与による列レベルセキュリティ | データの列の表示を制限すること。 | 〇 |
22200 | マスキングによる列レベルセキュリティ | データの意味や関係性を喪失することなく、元のデータ値を変換すること。 | |
22210 | 永続データマスキングによる列レベルセキュリティ | 永続的かつ不可逆的に、データの値を変換すること。 | 〇 |
22220 | 動的データマスキングによる列レベルセキュリティ | 元のデータを変換せずに、データの値を変換すること。 | 〇 |
データストアにおけるデータへの権限付与調査表
下記のような観点でデータストア別に評価を行うことをおすすめします。製品選定時や製品開発時の標準策定にも役立つものとなります。
<参考>マスキング手法について
DMBOKにおいて、下記のように紹介されております。
- 置換:文字や全他の値をテーブル牽引の値や標準パターンと置き換える。
- シャッフル:レコード内の同じ型のデータエレメントを交換するか、同一のデータエレメントをレコード間で入れ替える。
- 時間的分散:日付を前後に何日か移動する。
- 値の分散:ランダムなプラスやマイナスの何パーセントかの係数を適用する。
- NULL****化または削除:テストシステムに存在すべきではないデータを削除する。
- 暗号化:データエレメントの一部や全部をランダムな文字や単一文字の繰り返しで置き換える。
- 表現形式マスキング:すべての値をある表現形式に変更する。
- キーマスキング:このマスキングアルゴリズムとプロセスはデータベースのキー項目(または同様のもの)をマスキングするために利用され、その結果は一意で再現性がなければならない。
引用元:DMBOK 2nd 第7章データセキュリティ
データストアへの権限付与設定のプロセス
下記のプロセスにて、権限付与を実施します。
番号 | プロセス | 説明 |
---|---|---|
1 | 機密性レベル、および、エンタイトルメント(データのセキュリティグループ)の検討 | 規制を考慮した機密性レベル、および、エンタイトルメント(データのセキュリティグループ)を策定します。 公開用、社内向け、および、社外秘で1グループを作成し、制限付機密、および、登録者限定機密において管理単位ごとにグループを作成します。管理単位の例としては、会社、部署、役職などがあります。会社単位で行レベルセキュリティを実施したい場合には、会社のエンタイトルメントを作成します。 データストアに応じた設定方法もこの段階で決定しておくことで、プロジェクト個別での権限管理が避けることができます。 |
2 | データストアにおけるデータ(テーブル、ファイル等)の機密レベルの決定 | データストアに保持するデータに基づき、機密性レベルを決定します。 |
3 | データストアにおけるデータのエンタイトルメントの決定 | データストアに保持するデータに基づき、エンタイトルメントを決定します。 |
4 | 権限付与対象箇所の特定 | 制限付機密、および、登録者限定機密相当の扱いとなった場合に、データのどの列にて権限付与を行うか決定します。適切な列を保持していない場合には、バッチ処理にて列の追加を検討します。 |
5 | 権限付与の実施 | ここまでの検討内容に基づき、システムを実装します。 |
検討の前提について
データセキュリティにおけるエンタイトルメントを検討するには、機密性レベルと規制という2つの観点から整理するのがよさそうです。従うべき規制がある場合には、機密性レベルとして例示されている”制限付機密”、もしくは、”登録者限定機密”の1つとしてエンタイトルメントを規定してください。
- 機密性レベル:組織は、組織の外部や組織の特定の部門内においてでさえ知られてはならないデータの種類を決定する。「知る必要がある」かどうかという基準でのみ共有される。
- 規制:規制対象カテゴリは法律、条約、税関協定、業界規制などの外部ルールに基づいて割り当てられる。規制情報は「知ることが許される」かどうかという基準で共有される。
引用元:DMBOK 2nd 第7章データセキュリティ
機密性レベルについて
機密性レベルを検討する際には、下記DMBOKの分類を参考に、規定してください。
- 公開用:公衆を含む誰でも利用できる情報
- 社内向け:情報は従業員やメンバーに限定されるが、共有した場合のリスクは最小限である。
- 社外秘:適切に結ばれた機密保持契約やそれに類するものがない場合は、組織外で共有することができない情報。
- 制限付機密:「知る必要がある」一定のロールを持つ個人に限定された情報。
- 登録者限定機密:非常に機密レベルが高い情報で、データにアクセスするためには、情報にアクセスするすべての人が法的な合意に署名し、秘密のために責任を負わなければならない。
引用元:DMBOK 2nd 第7章データセキュリティ
規制について
下記がDMBOKにて例示されてます。
1. 規制対象ファミリ例
個人識別情報:個人の私的情報(PPI)とも呼ばれ、氏名、住所、電話番号、スケジュール、政府のID番号、年齢、人種、宗教、民族性、誕生日など、個人を一人一人識別できる情報が含まれる。
財務上のセンシティブデータ:「株主」や「インサイダー」データと呼ばれるもの、まだ公表されていない現在の財務情報を含む、すべての財務情報を指す。
医療上のデータ/個人健康情報:個人の健康や医療に関するすべての情報。
教育記録:個人の教育に関するすべての情報。
2. 業界、契約に基づく規制
PCI****データセキュリティ基準:PCI-DSSは業界で最も広く知られているデータセキュリティ基準である。名前、クレジットカード番号(カード上のすべての番号)、銀行口座番号、アカウントの有効期限など、金融機関のアカウントで個人を識別できる情報を対象としている。
競争上の優位性、企業秘密:企業は競争上の優位性を達成するために独自の方法、混合物、数式、ソース、デザイン、ツール、レシピ、運用技術を利用する場合、業界の規制や知的財産法によって保護される。
契約上の制限:ベンダーやパートナーとの契約において、組織は特定の情報の一部がどう利用できるかできないか、どの情報が共有できるかできないかを規定することがある
BI(Business Intelligence)からデータストアに接続する際の考慮事項
BIにおいてデータへの権限付与を実施できることから、BIもデータストアの1つとして捉える必要があります。フロントアプリケーションとなるBIであることから、BI側でデータセキュリティ(認証、データへの権限付与)をどのように実施するかが、データ分析基盤の検討に影響を与えます。
BI(≒フロントアプリケーション)からの利用時には、BI側で権限付与を実施するのか、データストア側で権限を実施するのかの決定が重要です。個人的な経験から、BI側で権限付与をされていることが多い印象があります。いわゆるデータの民主化(≒セルフサービスBIの文化構築)を行うためには、統合ユーザーIDによるシングルサイオンにより、データストアへの権限設定の利用を推進すべきです。
BIを利用時には、ライブ接続(Direct Query)時にはデータストア側での権限付与を利用して、データ抽出(データインポート)時にはBI側での権限付与を実施することになります。データストアでの管理に集中させるにはデータ抽出をライブ接続に変更する必要がありますが、パフォーマンスの低下がさけられません。BIでの管理に集中させるには、BI利用者に対してデータストアへの提供を制限する必要があります。
データへの権限付与を行うことで、開発・運用コストの増加だけでなく、システムのパフォーマンスが低下することがあります。具体的には、BI側でのキャッシュを利用できなくなることやデータへの権限付与によりデータストアで機能が利用できなくなることがあります。パフォーマンスとセキュリティは、トレードオフとなることが多いです。
参考文献
- 『データマネジメント知識体系ガイド 第二版』(日経BP社、ISBN 978-4296100491)