この記事をシェアする
LinkedInでフォローする
SAP Datasphereの世界へようこそ。データは単なる情報ではなく、現代ビジネスの生命線です。こうした環境では、データの神聖さを維持することが最優先であり、そのためには沈黙の守護者であるデータアクセス制御（DAC：Data Access Controls）が重要となってきます。
はじめに
SAP Datasphereのデータアクセス制御は、ユーザーのアクセス権を管理し、情報の安全性と正確性を確保します。より多くのデータが作成され、やり取りされるにつれ、機密情報が関係者以外の手に渡らないようにするための確固としたルールが必要不可欠となっています。今回の記事では、こうした制御がなぜ重要なのか、どのように役立つのか、そしてなぜデータを安全に管理するための要となるのかについてお話しします。
さまざまなシナリオを検討するために、SAPブログ「SAP Datasphere Analytic Model Series – Data Model Introduction」に掲載されたデータモデルの簡易版を使用します。このSAPブログで使用されたデータセットには、こちらのリンクからアクセスできます。このデータセットを使用して、さまざまなコンテキストで異なるシナリオの有効性をテスト、分析できます。シナリオを確認し、それらが生み出すさまざまな結果を詳しく見ていきましょう。
データモデル
上述のように、サンプルデータとサンプルビューを準備するため、次のファイルがインポートされています
テーブルをインポートすると、これらのテーブルを使用してSAP Datasphereにビューが作成され、さまざまなデータアクセスシナリオを検証できるようになります。このビューは、主にデータアクセスシナリオをテストするためのものであり、ビジネスの観点から最適な形で導入されていない可能性があることにご注意ください。
ビュー1：SAP Datasphereで作成されたメインビュー（SAPブログからのテーブルを含む）
それではシナリオを実行し、SAP Datasphereがどう機能するかを見ていきましょう。
シナリオ1
最初のシナリオでは、ユーザーに特定の販売組織へのアクセスのみが付与されています。これは基本のシナリオで、SAP Datasphereのデータアクセスを簡単に説明しています。以下のSAP Datasphereのテーブルは、販売組織463、949、765へのユーザーのアクセス権を示しています。
テーブル1 Users_Salesorg：ユーザー名と販売組織
以下のスクリーンショット（DAC 1）はデータアクション画面で、「権限エンティティ（Permissions Entity）」（ここでは販売組織）を追加します。
DAC 1：Permissions EntityはUsers_salesorg、ID列（Identifier Column）はusername
このDACをメインビュー（最初のビュー1）に追加すると、ユーザーは許可された販売組織に特化したデータのみを表示できます。以下のテーブルは、どのデータへのアクセスが許可されているかを示しており、対応する販売組織のみが表示されています。
結果1：アクセス権ルールとしてDAC 1を追加した後のメインビューの結果テーブル
上述のとおり、この例は基礎となるスタート地点です。ここからシナリオをより詳細に検討していきます。
シナリオ2
このシナリオでは、ユーザーが2つの異なる販売組織と商品カテゴリ3へのアクセス権を持っていると仮定します。
テーブル2：ユーザー名、販売組織、商品カテゴリ
予想どおり、ユーザーは販売組織463と949、商品カテゴリ3に関連するデータのみを表示でき、その他のデータにはアクセスできません。
結果2：アクセス権ルールとして上記テーブル2を追加した後のメインビューの結果テーブル
シナリオ3
次のシナリオでは、ユーザーロールをSAP Datasphereに追加できるかをテストしました。ユーザーロールは、複数のユーザーが関与するシステムやプラットフォームに不可欠な要素です。
管理者は、各ユーザーに個別に権限を割り当てる代わりに、定義済みの権限セットを含むロールを割り当てることができます。個々のユーザー権限ではなくロールのみを管理すればよいため、アクセス権の付与および取り消しのプロセスが簡素化されます。つまり、ロールに対応するアクセス権が、同じユーザーロールに割り当てられたすべてのユーザーに自動的に付与されます。
ユーザーロールを効率的に管理するため、ユーザーロールテーブルを作成しました。このテーブル内に、ユーザーロールUR1とUR2、販売組織、商品カテゴリを追加しました。
テーブル3：ユーザーロール、販売組織、商品カテゴリ
テーブル4：ユーザー、ユーザーロール
ユーザーロールテーブルとユーザーテーブルをマージするため、この2つをビュー内で結合しました。
ビュー2：結合されたユーザーロールとユーザーリスト
結果テーブルに、ユーザーロールUR1でアクセス可能な正しい値が表示されています。このことから、ユーザーロールをSAP Datasphereに追加して容易に管理できることが分かります。
結果3：アクセス権ルールとして上記ビューを追加した後のユーザーロールの結果テーブル
シナリオ4
次に、2つのDACが同じビューに適用された場合の相互関係を評価しました。システムは最初のDACを優先するのか、それとも最新のDACがそれ以前のDACを優先するのか。それを検証することで、2つのDACが単一のビュー内で同時に統合され、それらがお互いにどう影響し合うかを知ることができます。
テーブル5は、ユーザーが販売組織949にのみアクセスできるよう制限した最初のテーブルです。このテーブルを1つのDACに組み込み、「SalesOrg DAC」とラベル付けしました。
テーブル5：ユーザー名と販売組織
もう1つのDACには、前述のユーザーロールDACを使用し、「User Role DAC」とラベル付けしました。
ビュー3：2つ目のアクセス権制限として使用されるユーザーロールビュー
まず、メインビューに「SalesOrg DAC」を追加し、次に「User Role DAC」を追加しました。結果4と同様にデータを確認したところ、データは表示されませんでした。逆の順序で、「User Role DAC」、「SalesOrg DAC」の順に追加してみましたが、データは表示されませんでした（結果5）。つまり、1つのDACがもう1つのDACを優先してはならないため、データアクセスはプロセスに従って正しく機能していると言えます。
結果4：データなし
結果5：データなし
シナリオ5
このシナリオでは、「*」、「 」、「null」などのワイルドカードを使用した場合の動作をテストします。データアクセスにワイルドカードを実装し、ユーザーがシステム内のすべてのデータを表示し、それらのデータにアクセスできるかをテストします。このアプローチは、データアクセス制御の有効性を評価し、セキュリティ対策の潜在的な不備や脆弱性を特定するのに役立ちます。
ただし、すべてのデータへの無制限アクセスを許可することは、ほとんどのシナリオにおいて適切ではない、または推奨されない場合があります。一般的には、適切なデータガバナンスおよびセキュリティを確保するため、ユーザーロール、組織の要件、データの機密性に基づいて、特定のフィルタおよび制限を定義することが推奨されます。
ワイルドカードを実装したデータアクセステーブルを上記ビューに追加してみましょう。
テーブル6：ワイルドカードテーブルのユーザー名、販売組織、商品カテゴリ
結果6が示すように、上記ワイルドカードはいずれもワイルドカードDACでは機能していません。ワイルドカードを使用すると、時として意図しない不正確な結果につながる可能性があり、特定のクエリに必要な精度が得られない場合があります。SAP Datasphereでワイルドカードが機能しないことは利点と考えられます。ワイルドカードが機能しないとなると、ユーザーはより正確で制御された検索方法を採用しようとするため、データ分析プロセスにおいてより精度と信頼性の高い結果を得ることができます。
結果6：無効な番号：SQLエラー
まとめ
SAP Datasphere内でのデータアクセス制御を検証した結果、機密データのセキュリティ、整合性、および制御されたアクセスを確保する上で、データアクセス制御が果たす重要な役割が浮き彫りとなりました。さまざまなアクセスシナリオおよびデータモデルを使った一連のシナリオを通して、こうした制御の機能を詳しく知ることができました。
また今回のシナリオにより、SAP Datasphereのデータアクセス制御の有効性と柔軟性を確認することができました。こうした制御を活用することで、企業はデータセキュリティを確保し、コンプライアンス規制を遵守し、さまざまなアクセスレベルを持つユーザー間の効率的なコラボレーションを促進することができます。
