Oracle Databaseセキュリティ・ガイドのこのリリースの変更

この章の内容は次のとおりです。

Oracle Database Security 20cでの変更点

Oracle Database20cのOracle Databaseセキュリティ・ガイドには、新しいセキュリティ機能が記載されています。

アップグレードされたパスワード・ファイルでの強制的な大/小文字の区別

Oracle Database 20c以降では、パスワード・ファイルの大/小文字の区別を有効化または無効化するパラメータは削除されています。新しいパスワード・ファイル内のすべてのパスワードは大/小文字が区別されます。

大/小文字を区別するパスワード・ファイルは、大/小文字を区別しない古いパスワード・ファイルよりもセキュリティを強化します。大/小文字を区別するパスワード・ファイルを使用することをお薦めします。ただし、以前のOracle Databaseリリースからアップグレードされたパスワード・ファイルでは、元の大/小文字を区別しない状態が維持されます。パスワード・ファイルをある形式から別の形式に移行することで、パスワード・ファイルで強制的に大/小文字を区別できます。

データベース・プロパティでCMUウォレットおよびdsi.oraファイルの場所を指定する機能

PDBのデータベース・プロパティを使用して、個々のPDBの集中管理ユーザー(CMU)ウォレットおよびdsi.oraファイルの場所を指定できるようになりました。

この拡張によって、PDB管理者は、sqlnet.ora WALLET_LOCATIONパラメータによって制限されたり、デフォルトのウォレット・ロケーションを使用することなく、これらのファイルを格納する場所を指定できます。この機能は、WALLET_LOCATIONまたはデフォルトのウォレット・ロケーションを使用する場合とほぼ同じように動作しますが、ディレクトリ・オブジェクトがデータベースの一部であるため、管理権限を持つユーザーはデータベースを起動できません。データベース・ディレクトリ・オブジェクトによって指定された場所のパスにCMUウォレットとdsi.oraファイルを格納するには、CMU_WALLETデータベース・プロパティをこのディレクトリ・オブジェクトに設定する必要があります。

CMU_WALLETデータベース・プロパティを個々のPDBのディレクトリ・オブジェクトに設定した後は、このPDBのCMUウォレットとdsi.oraファイルをディレクトリ・オブジェクトで指定された場所に格納して、対応するファイル・システムからアクセスできるようにする必要があります。

USER_APPLICATION_ROLESデータ・ディクショナリ・ビューの追加

このリリース以降、USER_APPLICATION_ROLESデータ・ディクショナリ・ビューには、現在のユーザーにのみ適用されるDBA_APPLICATION_ROLESで使用可能なロールのサブセットが用意されています。

USER_APPLICATION_ROLESを使用すると、現在のユーザーに、DBA_APPLICATION_ROLESで使用可能なすべてのアプリケーション・ロールのリストではなく、ユーザーに付与されているすべてのアプリケーション・ロールが表示されます。

診断イベントの新しいシステム権限および初期化パラメータ

このリリースでは、ALTER SESSIONおよびALTER SYSTEM操作を介したデバッグ・イベント(イベント++、エラー番号)とデバッグ・アクションを設定するためのより優れたセキュリティ制御が提供されます。

この拡張をサポートするために、次の機能を使用できます。

  • ENABLE DIAGNOSTICSシステム権限
  • DIAGNOSTICS_CONTROL初期化パラメータ

デバッグ・イベントやデバッグ・アクションの中には安全でないものもあり、ユーザーには慎重に公開する必要があります。以前のリリースでは、これらの診断の使用に対する権限制御は十分ではありませんでした。この新しい権限制御により、通常のユーザーがこれらの診断を使用することをブロックして、業務分離をより適切にサポートできます。

1つのプロセスにおける個別のSSL接続に対する複数のウォレットのサポート

Oracle Database 20c以降では、様々なSSL証明書を使用して複数のSecure Sockets Layer (SSL)セッションを維持するようにデータベース・クライアントを構成できます。

この機能により、マルチスレッド・クライアントは、同時SSLセッションに対して異なる証明書を持つ複数のウォレットを使用できます。

この拡張により、データベース・クライアントは異なる外部IDで同時に接続できます。これにより、マルチスレッド・クライアントは、同時SSLセッションに対して異なる証明書を持つ複数のウォレットを使用できます。

オブジェクト・ストア資格証明に対するOracle SQL*Loaderサポート

Oracle Database 20c以降、Oracle SQL*Loaderはユーザー定義の資格証明を提示することによってオブジェクト・ストア内のデータにアクセスします。

Oracle SQL*Loaderでは、オブジェクト・ストア内のファイルをOracleデータベースにロードできるように定義する資格証明を指定できるようになりました。

統合監査ポリシー構成の変更の即時有効化

このリリース以降、統合監査ポリシーに行われた変更は、現在のセッションおよび他のすべての実行中のアクティブ・セッションですぐに有効になります。

以前のリリースでは、変更された統合監査ポリシーの影響を受けたユーザーは、統合監査ポリシーを有効にするために、ログアウトしてからセッションに戻る必要がありました。

現行ユーザーに対する統合監査ポリシーの適用

このリリース以降、SQL文を実行する現行ユーザーに統合監査ポリシーが適用されます。

以前のリリースでは、統合監査ポリシーは、SQL文が実行されるトップレベル・ユーザー・セッション(ログイン・ユーザー・セッション)を所有するユーザーに適用されていました。

現行ユーザーがログイン・ユーザーと異なるシナリオには、次のものが含まれますが、これらに限定されません。

  • トリガーの実行
  • 定義者権限プロシージャの実行
  • ビューの評価中に実行されるファンクションおよびプロシージャ

セキュリティ技術導入ガイドのコンプライアンスに関する事前定義の統合監査ポリシー

このリリース以降、新しい事前定義の統合監査ポリシーを使用して、セキュリティ技術導入ガイド(STIG)のコンプライアンスを監査できます。

これらのポリシーは次のとおりです。

  • ORA_STIG_RECOMMENDATIONS
  • ORA_ALL_TOPLEVEL_ACTIONS
  • ORA_LOGON_LOGOFF

共通統合監査ポリシーのSYSLOG宛先

共通統合監査ポリシーからの統合監査レコードの特定の事前定義済列をUNIX SYSLOG宛先に書き込むことができます。

この機能を有効にするには、新しいCDBレベルのinit.oraパラメータであるUNIFIED_AUDIT_COMMON_SYSTEMLOGを設定します。この拡張によって、共通統合監査ポリシーのすべての監査レコードを1つの宛先に統合できます。

この機能は、UNIXプラットフォームのみで使用できます。Windowsでは使用できません。

Oracle XML DB HTTPおよびFTPサービスの監査

このリリース以降、HTTP、HTTPSおよびFTPのデータベース・プロトコル・サーバーを使用して行われたデータベース接続の統合監査ポリシーを作成できます。

統合監査ポリシーでは、Oracle Enterprise Manager Express、Oracle Database Native Web Services、Oracle XML DB Repositoryを使用するHTTPおよびFTPなどの、サーブレットに対して行われたリクエストを追跡できます。

この拡張により、WebDAVクライアントによるアクセスを含む、HTTP、HTTPSおよびFTPプロトコルによって提供されるOracle Databaseへのアクセスを追跡および監視できます

従来の監査の非推奨

従来の監査は、Oracle Database 20cでは非推奨となりました。統合監査を使用して、Oracle Database内で選択的でより効果的な監査を行うことをお薦めします。

Oracleでは、Oracle Database 12 cとの統合監査を導入しました。統合監査は、組込みの監査操作サポートを提供するだけでなく、データベース内の監査の管理を簡素化し、条件に基づいて監査を高速化する機能を提供し、データベースによって生成される監査データのセキュリティを強化します。統合監査と従来の監査(混合モード)は、Oracle Database 12c以降のデフォルトの監査モードでした。混合モードの監査は、統合監査に慣れ、従来の監査から移行するために提供されました。このリリースでは従来の監査が非推奨になったため、統合監査に移行することをお薦めします。

Oracle Database Security 19cでの変更点

Oracle Database19cのOracle Databaseセキュリティ・ガイドには、新しいセキュリティ機能が記載されています。

LOBロケータの署名ベース・セキュリティ

このリリース以降、ラージ・オブジェクト(LOB)ロケータの署名ベース・セキュリティを構成できます。

この機能は、特にLOBデータ型のインスタンス(CLOBおよびBLOB)が分散環境で使用される場合に、Oracle Database LOBのセキュリティを強化します。

LOB署名キーは、マルチテナントPDBまたはスタンドアロンの非マルチテナント・データベースのどちらでも使用できます。ALTER DATABASE DICTIONARY ENCRYPT CREDENTIALS SQL文を実行することで、LOB署名キー資格証明の暗号化を有効にできます。それ以外の場合、資格証明は不明瞭化された形式で格納されます。LOB署名キーを暗号化された形式で格納する場合、データベースまたはPDBにオープンTDEキーストアが必要です。

デフォルトのユーザー・アカウントがスキーマ限定になりました

Oracle Databaseリリース18cからスキーマ限定アカウント機能を使用すると、ほとんどのOracle Database提供スキーマ(users)で、ユーザーがこれらのアカウントに対して認証できないようにそのパスワードが削除されるようになりました。

この拡張機能はサンプル・スキーマには影響しません。サンプル・スキーマは、引き続きデフォルトのパスワードとともにインストールされます。

スキーマ限定であるデフォルト・スキーマの場合、管理者は、スキーマに対して認証する必要がある場合でもこれらのアカウントを引き続きパスワードで変更できますが、後でスキーマをスキーマ限定アカウントに戻すことをお薦めします。

この機能の利点は、管理者がこれらのOracle Database提供のスキーマのパスワードを定期的にローテーションする必要がなくなったことです。 この機能により、デフォルトのパスワードを使用してこれらのアカウントにハッキングする攻撃者のセキュリティ・リスクも削減されます。

権限分析ドキュメントのOracle Databaseセキュリティ・ガイドへの移動

権限分析のドキュメントは、『Oracle Database Vault管理者ガイド』から『Oracle Databaseセキュリティ・ガイド』に移動しました。

権限分析のライセンス情報については、『Oracle Databaseライセンス情報ユーザー・マニュアル』を参照してください。

スキーマ限定アカウントに対して管理権限を付与または取り消す機能

SYSOPERSYSBACKUPなどの管理権限をスキーマ限定(パスワードなし)アカウントに付与できるようになりました。

現在管理権限を付与されている既存のユーザー・アカウント(アクティブ、ほとんどアクセスされていない、使用されていないユーザー)は、スキーマ限定アカウントになるように変更できます。この拡張により、管理者はこれらのアカウントのパスワードを管理する必要がなくなります。

SASLおよびSASL以外の両方のActive Directory接続の自動サポート

このリリース以降、Microsoft Active Directory接続では、Simple Authentication and Security Layer (SASL)およびTransport Layer Security (TLS)バインドの両方がサポートされています。

集中管理されたユーザーの場合、Oracleデータベースは最初にSASLバインドを使用してActive Directoryに接続しようとします。Active DirectoryサーバーがSASLバインド接続を拒否した場合、OracleデータベースはSASLバインドなしで接続を自動的に再試行しますが、引き続きTLSで保護されます。

Active Directory管理者はActive Directoryサーバーの接続パラメータを構成しますが、この新しいActive Directory接続拡張に一致するようにデータベースを構成する必要はありません。データベースは、SASLを使用するからSASLバインドを使用しないに、自動的に調整されます。

異なるユーザーに対するOracleネイティブ暗号化とSSL認証の同時サポート

以前のリリースのOracle Databaseでは、Oracleネイティブ暗号化 (Advanced Networking Option (ANO)暗号化とも呼ばれる)とSecure Sockets Layer (SSL)認証を併用できませんでした。

このリリース以降、新しいパラメータSQLNET.IGNORE_ANO_ENCRYPTION_FOR_TCPSTRUEに設定して、TCPSクライアントの使用とこれら2つのパラメータのいずれかがrequiredに設定されていることに競合がある場合、SQLNET.ENCRYPTION_CLIENTまたはSQLNET.ENCRYPTION_SERVERを無視できます。

サーバー証明書の照合におけるホスト名ベースの部分DN一致のサポート

部分DN一致に対するこの新しいサポートでは、クライアントがサーバー証明書をさらに検証する機能が追加されます。

Secure Sockets Layer (SSL)ハンドシェイク中に、サーバー証明書との完全DN一致を実行する以前の機能もサポートされています。クライアントは完全DN一致と部分DN一致の両方をサポートします。サーバーDN一致を有効にすると、部分DN一致がデフォルトになります。

証明書の検証に部分および完全DN一致を許可すると、証明書の作成方法に基づいて柔軟性が向上します。

トップレベルのSQL文のみを監査する機能

統合監査のトップレベルの文機能を使用すると、データベース内のトップ・レベル・ユーザー(または直接ユーザー)のアクティビティを監査できますが、間接ユーザー・アクティビティ監査データは収集されません。

この機能を使用すると、トップレベルのユーザーが直接発行したイベントのみを監査できます。間接SQL文のオーバーヘッドはありません。 トップレベルの文は、ユーザーが直接発行するSQL文です。これらの文は、セキュリティとコンプライアンスの両方にとって重要になる可能性があります。 PL/SQLプロシージャ内またはファンクション内から実行されるSQL文は、トップレベルとはみなされないため、監査目的にはあまり関係がない可能性があります。

統合監査証跡の読取りパフォーマンスの改善

統合監査証跡レコードを格納するAUDSYS.AUD$UNIFIEDシステム表は、読取りパフォーマンスを向上するためにパーティション・プルーニングを使用して再設計されました。

この再設計により、AUDSYS.AUD$UNIFIED表への新しい列の追加が必要になります。AUDSYS.AUD$UNIFIED表監査レコードの問合せを可能にするUNIFIED_AUDIT_TRAILデータ・ディクショナリ・ビューでは、新しいAUDSYS.AUD$UNIFIED表列に対応するEVENT_TIMESTAMP_UTC列が追加されました。この拡張に伴い、GV$UNIFIED_AUDIT_TRAILビューのEVENT_TIMESTAMP列のデータ型はTIMESTAMP(6)に変更されました。

UNIFIED_AUDIT_TRAILビューを問い合せる場合は、パーティション化プルーニングを実現するためにWHERE句にEVENT_TIMESTAMP_UTC列を含めることをお薦めします。

SYSLOGおよびWindowsイベントビューアの監査レコード・フィールドとしてのPDB_GUID

SYSLOGおよびWindowsイベントビューアの監査レコード・フィールドに、統合監査証跡レコードに関連付けられたプラガブル・データベースを識別するために新しいフィールドPDB_GUIDが追加されました。

マルチテナント・データベース・デプロイメントでは、統合監査証跡レコードを生成したプラガブル・データベースが監査証跡で識別される必要があります。このリリース以降、SYSLOGおよびWindowsイベントビューアには、この情報を取得するために新しいフィールドPDB_GUIDがあります。データ型はVARCHAR2です。