Oracle Data Safeでのカスタム・アラート・ポリシーの概要 (2024/07/31)

Oracle Data Safeでのカスタム・アラート・ポリシーの概要 (2024/07/31)

https://blogs.oracle.com/database/post/data-safe-custom-alerts

投稿者: Angeline Dhanarani | Senior Principal Product Manager, Oracle Database Security


最近、Oracle Data Safeでカスタム・アラート・ポリシーのサポートが追加されました。この機能により、対象となる特定のデータベース・アクティビティを監視できます。カスタムアラートポリシーは、不要なアラートの「ノイズ」を減らし、不適切または潜在的に悪意のあるアクティビティを検出する能力を強化します。


異常なアクセス・パターンを検出する場合でも、クリティカル・データを不正に変更しようとする場合でも、潜在的な違反を示す異常な問合せを検出する場合でも、カスタム・アラート・ポリシーは、リスクがエスカレーションされる前に事前に特定して軽減するのに役立ちます。この新機能を活用して、インシデントの対応時間を短縮できます。


カスタム・アラート・ポリシーを使用すると、アラートするデータベースの変更をカスタマイズできます。この機能を使用すると、一連のルールおよび条件を調整して、重要度の低いアラートを除外できるため、最も関連性の高いアクション可能なアラートに優先順位を付けて集中できます。このターゲットを絞ったアプローチにより、真の脅威に集中できます。プロアクティブなセキュリティ・アプローチに不可欠な要素であり、組織はセキュリティ・アラートに効果的に優先順位を付け、潜在的な脅威への迅速な対応を可能にします。


Data Safeでは、「アラート・ポリシー」ページからカスタム・アラート・ポリシーを作成できます。この新機能には、実際のアクティビティに基づいてアラートを作成する機能が隠されています。「すべてのアクティビティ」監査レポートから、アラートを生成するアクティビティのみが表示されるまでフィルタをレポートに追加できます。次に、「アラート・ルールとして作成」をクリックして、それらのフィルタをアラート条件に転送します。「すべてのアクティビティ」監査レポートの利便性を使用して、フィルタされたイベント属性および監査レポートの値の条件を含むカスタム・アラート・ポリシーを作成する方法は、次のスクリーンショットを参照してください。


図1: Data Safeでの監査レポートからのカスタム・アラート・ポリシーの作成


カスタム・アラート・ポリシーは、Data Safeのセキュリティ・センター内の「アラート・ポリシー」ページから表示および管理できます。複数の個別のアラート・ルールで作成されたカスタム・アラート・ポリシーの例については、次のスクリーンショットを参照してください。各アラート・ルールは一意のフィルタリング基準で調整され、構成されたセキュリティ制御に対応する論理グループに編成されています。


図2: 個別のアラート・ルールを使用したカスタム・アラート・ポリシーの例



新しいカスタム・アラート機能を他のデータベース・セキュリティ機能と組み合せて使用する場合の参考にしてください。次の項では、セキュリティ管理者としてアプリケーション・データの保護を担当する実際のユース・ケースで、カスタム・アラート・ポリシーの可能性を探ります。


このシナリオでは、アプリケーション・スキーマEMPLOYEESEARCH_PRODは、内部HRアプリケーションの機密情報をホストします。アプリケーションは、サービス・アカウントを介してスキーマ内のデータにアクセスします。サービス・アカウントに加えて、様々な特権ユーザー(DBA)が管理タスクおよびメンテナンス・アクティビティのためにデータベースにアクセスします。


データを保護するには、次のスクリーンショットに示すように、3つのデータベース・セキュリティ制御(Oracle Database Vault、統合監査およびData Safe)を組み合せて実装します。

•    Database Vaultは、データへの特権ユーザー・アクセスをブロックします

•    統合監査では、通常のアプリケーション・アクティビティの外部からデータへのアクセス・レコードを取得します

•    Data Safeは、安全なストレージ、分析、レポート、および(このユースケースにとって最も重要な)疑わしいアクティビティをアラートするための監査データを取得します


図3: データ保護戦略



権限のあるユーザーおよび管理者からのアプリケーション・データ・アクセスをブロック


EMPLOYEESEARCH_PRODアプリケーション内のすべてのオブジェクトを保護するために、アプリケーション・スキーマをDatabase Vaultレルムに配置します。レルム・オブジェクトにアクセスする権限があるのは、EMPLOYEESEARCH_PRODスキーマ所有者のみです。


統合監査ポリシーによって、レルム・アクセスの違反が監査されます。


図4: 特権ユーザーおよび管理者からのアプリケーション・データ・アクセスをブロックするセキュリティ制御



ブログのリファレンス・セクションの表は、Database Vaultレルムおよび統合監査ポリシーを作成するためのコマンドを示しています。


これらの保護が適用されている場合、アプリケーション・サービス・アカウントEMPLOYEESEARCH_PRODを使用してデータベースにアクセスするアプリケーションは、スキーマ内のすべてのオブジェクトにアクセスできます。ただし、DBAロールを持つデータベース管理者のような特権ユーザーは、通常の管理タスクおよび職責を実行できますが、EMPLOYEESEARCH_PRODスキーマ内のアプリケーション・データを表示することはできません。アクセス試行によってDatabase Vaultレルム違反が発生し、監査が行われ、イベントが統合監査証跡に記録されます。


Data Safeは、データベースから監査レコードを収集するように構成されています。Data Safeはレルム違反の監査レコードを収集し、次に示すように、カスタム・アラート・ポリシーのアラート・ルールがセキュリティ・アラートをトリガーするように構成されます。


図5: Data Vaultレルム違反をアラートするカスタム・アラート・ポリシー・ルール



アプリケーション資格証明の誤用をブロック


EMPLOYEESEARCH_PRODアプリケーション・サービス・アカウント資格証明の誤用を防ぐために、別のDatabase Vault機能、コマンド・ルールを使用します。認可されたエントリ・ポイントからのみCONNECTコマンドを実行できるように、コマンド・ルールを構成します。JDBC Thinクライアントおよびその関連エンドポイントを認可するルール・セットが作成され、CONNECTコマンド実行の認可エントリ・ポイントとして追加されます。統合監査ポリシーは、データベース・サーバーに直接接続しているすべてのユーザーの最上位レベルのアクションをすべて追跡するようにも設計されており、これによってLOGINの試行も追跡されます。


図6: アプリケーション資格証明の誤用をブロックするセキュリティ制御



ブログのリファレンス・セクションの表には、Database Vaultコマンド・ルールおよび統合監査ポリシーを作成するためのコマンドが示されています。


この保護が適用されている場合、不正なユーザーまたは開発者がEMPLOYEESEARCH_PRODアプリケーション・サービス・アカウントの資格証明を使用してデータベースに直接アクセスすることは、ログインできません。ログイン試行が失敗し、再度、この失敗したログイン・イベントが監査され、コマンド・ルール違反を示す適切なエラー・メッセージとともに監査証跡に記録されます。


データベースから監査を読み取るようにData Safeを構成すると、コマンド・ルール違反のために失敗したLOGON監査イベントが収集されます。次に示すように、カスタム・アラート・ポリシーのアラート・ルールは、セキュリティ・アラートをトリガーするように構成されます。


図7: アプリケーション資格証明の誤用を警告するカスタム・アラート・ポリシー・ルール


潜在的なデータ抽出の試行を監視


Database Vault対応インスタンスのEMPLOYEESEARCH_PRODアプリケーション・スキーマでOracle Data Pump操作を実行するようにユーザー・アカウントDATA_PUMP_USERに認可されていることを考慮すると、統合監査ポリシーによってエクスポート・アクティビティが追跡され、機密アプリケーション・データを漏洩する悪意のある試みが検出されます。


図8: 潜在的なデータ抽出の試行を監視するためのセキュリティ制御



ブログのリファレンスセクションの表には、承認および統合監査ポリシーを付与するためのコマンドが示されています。


Data Pumpのエクスポート操作は、この保護付きで統合監査証跡に記録されます。Data Safeはこれを収集し、次に示すように、カスタム・アラート・ポリシーのアラート・ルールがセキュリティ・アラートをトリガーしてセキュリティ管理者に通知するように構成されます。


図9: Data Pump操作でアラートするカスタム・アラート・ポリシー・ルール



データベース・セキュリティ制御が適用され、カスタム・アラート・ポリシー内の様々なルールで調整された条件に基づいて監査イベントを収集しアラートをトリガーするようにData Safeを構成すると、通常のアプリケーション・アクティビティ以外のアプリケーション・スキーマにアクセスするアクティビティを可視化できます。また、次に示すように、このようなアクセス試行のパターンに関する貴重なインサイトを得ることもできます。


図10: カスタムアラートポリシールールとアクセスパターンのインサイト



最初のアラート・ルールであるアプリケーション・スキーマに対するDatabase Vaultレルム違反は、レルム違反が発生した場合にセキュリティ・アラートをトリガーし、アプリケーション・スキーマ・オブジェクトへの不正アクセスの可能性を示します。


2番目のアラート・ルールであるアプリケーション・スキーマ所有者による直接データベース・アクセス試行は、レルム認可アプリケーション・アカウント資格証明がアプリケーション・データベースへの直接ログインの試行に誤用され、認可されたアプリケーションの信頼できるパスをバイパスした場合にセキュリティ・アラートをトリガーします。


3番目のアラート・ルールであるデータ・ポンプ・エクスポートは、アプリケーション・スキーマにData Pumpエクスポート・アクティビティがある場合、セキュリティ・アラートをトリガーします。この重要な活動を監視することで、アプリケーション・データを漏洩する悪意のある試みを阻止できます。


単一のカスタム・アラート・ポリシーを使用して、データベース内の異常またはノートに残るイベントに対するセキュリティ・アラートをトリガーすると、Data Safe内のコンテキスト通知とさらに統合して、HRアプリケーション・データベース管理者に適切な措置を講じるよう事前通知できます。コンプライアンスを示すために、これらのアラート・ルールでフィルタされたファイングレイン・アラート・レポートを作成することを検討してください。


一言で言えば、組織がセキュリティ体制を強化するためのプロアクティブでデータ主導のアプローチを採用するのに役立つ、カスタム・アラート・ポリシー機能の変革的な影響について調査しました。


構成およびカスタム・アラート・ポリシーのデモの動作を確認するには、このビデオを参照してください。



参照


このブログで概説されている3つのセキュリティ制御ユースケースについて、Database Vaultおよび統合監査ポリシー構成に関するインサイトについては、次を参照してください。


Table 1; Examples of commands used in this blog
Block application data access from privileged users and administrators 

 ----To create Database Vault realm----
DVSYS.DBMS_MACADM.CREATE_REALM(
   realm_name => 'PROTECT_EMPLOYEESEARCH_PROD'
  ,description => 'A mandatory realm to protect the EMPLOYEESEARCH_PROD schema.'
  ,enabled => DBMS_MACUTL.G_YES
  ,audit_options => DBMS_MACUTL.G_REALM_AUDIT_FAIL
  ,realm_type => 1); 

 ----To add application objects into Database Vault realm----
DVSYS.DBMS_MACADM.ADD_OBJECT_TO_REALM(
   realm_name => 'PROTECT_EMPLOYEESEARCH_PROD'
  ,object_owner => 'EMPLOYEESEARCH_PROD'
  ,object_name => '%'
  ,object_type => '%'); 

----To authorize user into Database Vault realm----
DVSYS.DBMS_MACADM.ADD_AUTH_TO_REALM(
   realm_name => 'PROTECT_EMPLOYEESEARCH_PROD'
  ,grantee => 'EMPLOYEESEARCH_PROD'
  ,rule_set_name => '' 
  ,auth_options => '1' ); 

----To create audit to track Database Vault realm violation----
CREATE AUDIT POLICY dv_realm_employeesearch
      ACTIONS COMPONENT=DV Realm Violation ON "PROTECT_EMPLOYEESEARCH_PROD";
AUDIT POLICY dv_realm_employeesearch;

Block application credential misuse

    --- To create the rule "Application Connection" ---DVSYS.DBMS_MACADM.CREATE_RULE(
  rule_name => 'Application Connection'
, rule_expr => ${RULE_EXPR});
--Make sure to set the RULE_EXPR to allowed trusted paths

----To associate the rule set "Trusted Application Path" to the rule "Application Connection"
DVSYS.DBMS_MACADM.ADD_RULE_TO_RULE_SET(
  rule_set_name  => 'Trusted Application Path'
 ,rule_name      => 'Application Connection'
 ,rule_order     => 1
 ,enabled        => DBMS_MACUTL.G_YES);

----To create the Command Rule on Connect for "Application Connection"----
 DVSYS.DBMS_MACADM.CREATE_CONNECT_COMMAND_RULE(
   user_name    => 'EMPLOYEESEARCH_PROD'
  ,rule_set_name => 'Trusted Application Path'
  ,enabled => DBMS_MACUTL.G_YES);

----To create audit to track direct DB server access----
CREATE AUDIT POLICY direct_db_access ACTIONS ALL WHEN '(SYS_CONTEXT(''USERENV'',''IP_ADDRESS'') IS NULL)' EVALUATE PER SESSION ONLY TOPLEVEL;
audit policy direct_db_access;

Monitor potential data exfiltration attempts 

--- To authorize DATA_PUMP_USER account to perform Oracle Data Pump operations on EMPLOYEESEARCH_PROD application schema in Database Vault enabled instance-----

DBMS_MACADM.AUTHORIZE_DATAPUMP_USER(' DATA_PUMP_USER ','EMPLOYEESEARCH_PROD');

---To create an audit policy to track Data Pump export activity---
create audit policy audit_dp_export_pol ACTIONS COMPONENT=DATAPUMP EXPORT;
audit policy audit_dp_export_pol;

 


ユース・ケースを試す場合は、次のステップを考慮してください。


•    このDatabase Vault LiveLabに従って、HRアプリケーション・スキーマおよびデータベースVaultを構成します。

•    上の表に示すように、監査ポリシーを作成します

•    ターゲットを検出し、Data Safeで監査収集を開始します

•    ブログで概説されているカスタム・アラート・ポリシーの作成を開始します


追加リンク:

•    Oracle Data Safeの詳細

•    Oracle Data Safeのドキュメント


コメント

このブログの人気の投稿

Oracle RACによるメンテナンスのためのドレインとアプリケーション・コンティニュイティの仕組み (2023/11/01)

Oracle APEXのInteractive Gridで、Oracle Formsと比較して、重複行の検証を制御/通過させる方法 (2022/07/21)

Oracle APEX 24.1の一般提供の発表 (2024/06/17)