データベースへの直接アクセス
Developers（危機対応用）、Fraud（読み取り権限のみ）アナリスト（読み取り権限のみ）など、データベースに直接アクセスして独自のクエリを作成する必要があるいくつかのDBA以外のワーカー。権限を減らすことはできませんが、管理者によって承認されています。彼らが異なるクエリを必要とするたびに、私はそれらを事前に構築されたプログラム的なメソッドに制限することはできません。
PCI DSS要件8.7.b統計「データベース管理者のみがデータベースに直接アクセスまたはクエリすることができます」
この要件をどのように満たすことができますか？あなたが提案できるそれらの関連する代償コントロールはありますか？
私の組織の一部の非DBAワーカー（DEV、不正、アナリストなど）は、独自のクエリを作成するためにデータベースに直接アクセスする必要があります。
...
PCI DSS要件8.7統計「データベース管理者のみがデータベースに直接アクセスまたはクエリすることができます」
これを処理する通常の方法は、PANデータおよびその他の機密データを削除または置換して、データベースのスクラブされたバージョンを作成することです。このスクラブされたデータベースは、PCIスコープ外にあり、あなたが説明する人々から直接質問された。
（詐欺の人々は、仕事のためにPANデータにアクセスする必要があるかもしれません...しかし、彼らはそのために自由形式のクエリを使用することができません。データへのアクセスを提供するアプリケーションを作成します実際のデータベースでは、事前に作成されたクエリを通じて必要です）。
開発者とアナリストにとって、スクラブされたバージョンは彼らのニーズに十分であるはずです。
PIIの問題も検討することをお勧めします。データサイエンスアナリストは、その詳細レベルにアクセスする必要があります。開発者はそうしないかもしれません。ただし、DSS要件の範囲外です。
この方法にはいくつかの欠点があります。
- ソースデータベースのサイズによっては、スクラブに時間とリソースがかかる可能性があります。
- データのカーディナリティから派生するテーブルインデックスは、インデックス付けされた列（PANなど）を削除または置換すると変更されます。つまり、「スクラブされた」データベースに対するパフォーマンス測定は、「実際の"データベース。
AFAIK、できません。 PCI DSSに準拠したい場合は、開発者もアナリストも本番データベースに直接アクセスしないでください。
それがいったん述べられたら、なぜproductionデータベースに直接アクセスする必要があるのか不思議に思うはずです。パフォーマンステストでサイズが首尾一貫している場合、開発者は通常、偽のデータを含む開発データベースで満足する必要があります。アナリストは、クエリを実行するために、プライベートベースにprodデータベースの抽出を持っている必要があります。ここでは、BIソリューションが可能な方法ではないのか疑問に思われるかもしれません。製品データベース-> ETL-> BIデータベース
実際、直接アクセスを許可するよりも複雑ですが、セキュリティ（および認証...）はコストがかかるだけです。