専用Exadataインフラストラクチャ上のAutonomous Database内のアクセス制御

Autonomous Database on Dedicated Exadata Infrastructureを構成する際には、クラウド・ユーザーにアクセス権があることを確認して、職務を遂行するために適切な種類のクラウド・リソースのみを使用および作成する必要があります。さらに、認可された担当者およびアプリケーションのみが、専用インフラストラクチャ上に作成されたAutonomous Databaseにアクセスできるようにする必要があります。そうしない場合、専用インフラストラクチャ・リソースの"ランナウェイ"消費が発生したり、ミッションクリティカルなデータに適切にアクセスできなくなる可能性があります。

専用インフラストラクチャ機能を提供するクラウド・リソースの作成および使用を開始する前に、アクセス制御プランを形成し、適切なIAM (Identity and Access Management)リソースおよびネットワーキング・リソースを作成して、導入する必要があります。したがって、Autonomous Database内のアクセス制御は、様々なレベルで実装されます:

Oracleクラウドのユーザー・アクセス制御
クライアント・アクセス制御
データベース・ユーザー・アクセス制御

関連項目

主なセキュリティ機能

Oracle Cloudのユーザー・アクセス制御

Autonomous Database on Dedicated Exadata Infrastructureのデプロイメントを構成するクラウド・リソースに対する、テナンシ内のOracle Cloudユーザーのアクセス権を制御します。

Identity and Access Management (IAM)サービスを使用して、クラウド・ユーザーにアクセス権を付与し、職務を遂行するために適切な種類のAutonomous Databaseリソースのみを作成および使用できるようにします。クラウド・ユーザーのアクセス制御を設定するには、特定のコンパートメント内の特定の種類のリソースへの特定のアクセス権を特定のユーザー・グループに付与するポリシーを定義します。

IAMサービスには、セキュアなクラウド・ユーザー・アクセス戦略の定義および実装に役立つ複数の種類のコンポーネントが用意されています:

コンパートメント: 関連するリソースの集合。コンパートメントは、クラウド・リソースを編成および分離するためのOracle Cloud Infrastructureの基本コンポーネントです。
グループ: 特定のリソースまたはコンパートメントのセットに対して同じアクセス・タイプを必要とするユーザーのコレクション。
動的グループ: 定義したルールに一致するリソースを含む、特別なタイプのグループ。したがって、一致するリソースが作成または削除されると、メンバーシップが動的に変わる可能性があります。
ポリシー: 誰がどのリソースにどのようにアクセスできるかを指定する文のグループ。アクセス権はグループ・レベルおよびコンパートメント・レベルで付与します。つまり、特定のコンパートメント内の特定のリソース・タイプへのアクセス権を特定のグループに付与するポリシー・ステートメントを記述します。

ポリシーおよびポリシー・ステートメント

クラウド・ユーザーのアクセス制御の定義に使用される主要なツールは、ポリシーです。これは、「誰が」、「どのように」、「何を」および「どこで」という観点でアクセスを指定するポリシー・ステートメントが含まれたIAM (Identity and Access Management)リソースです。

ポリシー・ステートメントのフォーマットは次のとおりです:

Allow 
  group <group-name> 
  to <control-verb> 
  <resource-type> 
  in compartment <compartment-name>

group <group-name>は、既存のIAMグループの名前(個々のクラウド・ユーザーを割り当てることができるIAMリソース)を提供することで、「誰が」を指定します。
to <control-verb>は、次の事前定義済の制御動詞のいずれかを使用して、「どのように」を指定します。
- inspect: 特定のタイプのリソースを、機密情報や、そのリソースの一部である可能性があるユーザー指定のメタデータにはアクセスせずに一覧表示できます。
- read: inspectに加えて、ユーザー指定のメタデータと実際のリソースそのものを取得できます。
- use: readに加えて、既存のリソースを作業できます(作成や削除はできません)。また、「作業する」とは、各リソース・タイプで異なる操作を意味します。
- manage: リソース・タイプの作成および削除を含む、すべての権限。
専用インフラストラクチャ機能のコンテキストにおいては、フリート管理者は自律型コンテナ・データベースを管理でき、データベース管理者はそれを使用してAutonomous Databaseを作成できるのみです。
<resource-type>は、事前定義済のリソース・タイプを使用して、「何を」を指定します。専用インフラストラクチャ・リソースのリソース・タイプ値は次のとおりです:
- exadata-infrastructures
- autonomous-container-databases
- autonomous-databases
- autonomous-backups
専用インフラストラクチャ・リソースはネットワーキング・リソースを使用するため、作成するポリシー・ステートメントの一部はvirtual-network-familyリソース・タイプ値です。また、テナンシ内でタグ付けが使用されている場合は、tag-namespacesリソース・タイプ値を参照するポリシー・ステートメントを作成できます。
in compartment <compartment-name>は、既存のIAMコンパートメントの名前(リソースが作成されるIAMリソース)を指定することで、「どこで」を指定します。コンパートメントは、クラウド・リソースを編成および分離するためのOracle Cloud Infrastructureの基本コンポーネントです。

Autonomous Databaseのポリシーの詳細は、専用Exadataインフラストラクチャ上のAutonomous DatabaseのIAMポリシーを参照してください。

IAMサービスとそのコンポーネントの仕組みおよび使用方法の詳細は、Oracle Cloud Infrastructure Identity and Access Managementの概要を参照してください。IAMに関する一般的な質問への簡単な回答は、Identity and Access ManagementのFAQを参照してください。

アクセス制御を計画および構成する際のベスト・プラクティス

専用インフラストラクチャ機能のアクセス制御を計画および構成する際には、次のベスト・プラクティスを考慮する必要があります。

プライベート・サブネットのみを含む個別のVCNを作成します。ほぼすべてのケースにおいて、専用インフラストラクチャ上に作成されたAutonomous Databaseには企業の機密データが格納されます。通常、これには企業のプライベート・ネットワーク内からのみアクセスできます。パートナ、サプライヤ、コンシューマおよび顧客との共有データも、規制されたセキュアなチャネルを通じてそれぞれが利用できます。

したがって、このようなデータベースへのネットワーク・アクセスは、社内でプライベートにする必要があります。これを確実にするには、プライベート・サブネットとIPSec VPNまたはFastConnectを使用して企業のプライベート・ネットワークに接続するVCNを作成します。このような構成の設定の詳細は、Oracle Cloud InfrastructureドキュメントのシナリオB: VPNを使用したプライベート・サブネットを参照してください。

データベースへのネットワーク接続の保護の詳細は、Oracle Cloud Infrastructureドキュメントのネットワークを保護する方法を参照してください。
少なくとも2つのサブネットを作成します。少なくとも2つのサブネットを作成する必要があります: 1つはAutonomous Exadata VMクラスタ・リソースとAutonomous Container Databaseリソース用で、もう1つはAutonomous Databaseのクライアントおよびアプリケーションに関連付けられたリソース用です。
少なくとも2つのコンパートメントを作成します。少なくとも2つのコンパートメントを作成する必要があります。1つはExadataインフラストラクチャ、Autonomous Exadata VMクラスタおよびAutonomous Container Databaseリソース用で、もう1つはAutonomous Databaseリソース用です。
少なくとも2つのグループを作成します。少なくとも2つのグループを作成する必要があります: 1つはフリート管理者用で、もう1つはデータベース管理者用です。

クライアント・アクセス制御

クライアント・アクセス制御は、ネットワーク・アクセス制御およびクライアント接続を制御することによってAutonomous Databaseに実装されます。

ネットワーク・アクセス制御

Oracle Autonomous Databaseの専用デプロイメントを設定および構成するときに、Autonomous Databaseへのネットワーク・アクセス制御を定義します。その方法は、専用デプロイメントがOracle Public CloudとExadata Cloud@Customerのどちらにあるかによって異なります:

Oracle Public Cloudでは、ネットワーキング・サービスのコンポーネントを使用してネットワーク・アクセス制御を定義します。自律型データベースがネットワークにアクセスできるプライベート・サブネットを含むVirtual Cloud Network (VCN)を作成します。さらに、サブネット内のIPアドレスに出入りする特定タイプのトラフィックを許可するセキュリティ・ルールを作成します。

これらのリソースの作成の詳細は、フリート管理者専用のOracle Autonomous Databaseのラボ1: OCI実装のためのプライベート・ネットワークの準備を参照してください。
Exadata Cloud@Customerの場合、ネットワーク・アクセス制御を定義するには、データ・センター内のクライアント・ネットワークを指定し、それをExadataインフラストラクチャ・リソース内のVMクラスタ・ネットワーク・リソースに記録します。

ゼロトラストパケットルーティング(ZPR)

適用対象: Oracle Public Cloudのみ

Oracle Cloud Infrastructure Zero Trust Packet Routing (ZPR)は、セキュリティ属性を割り当てるAutonomous Exadata VM Cluster (AVMC)など、リソース用に記述したインテントベースのセキュリティ・ポリシーを通じて、機密データを不正アクセスから保護します。

セキュリティー属性は、ZPRがリソースの識別や編成に使用するラベルです。ZPRは、ネットワークアーキテクチャーの変更や構成の誤りに関係なく、アクセスが要求されるたびにネットワークレベルでポリシーを適用します。ZPRは、既存のネットワーク・セキュリティ・グループ(NSG)およびセキュリティ制御リスト(SCL)のルールに基づいて構築されます。パケットがターゲットに到達するには、すべてのNSGおよびSCLルールおよびZPRポリシーを渡す必要があります。NSG、SCLまたはZPRのルールまたはポリシーでトラフィックが許可されていない場合、リクエストは削除されます。

ZPRを使用してネットワークを保護するには、次の3つのステップがあります。

ZPRアーティファクト(セキュリティ属性ネームスペースおよびセキュリティ属性)を作成します。
ZPRポリシーを記述して、セキュリティ属性を使用してリソースを接続します。ZPRはZPR Policy Language(ZPL)を使用し、定義されたリソースへのアクセスを制限します。専用Exadataインフラストラクチャ上のAutonomous Databaseのお客様として、テナンシにZPLベースのポリシーを記述して、AVMCのデータが認可されたユーザーおよびリソースによってのみアクセスされるようにできます。
リソースへのセキュリティ属性の割当て: ZPRポリシーを有効にします。

ノート:

Oracle Cloud Infrastructureコンソール、APIまたはCLIを使用してクラウド・リソースに説明、タグ、セキュリティ属性またはフレンドリ名を割り当てる場合、機密情報を入力しないでください。

詳細は、ゼロ・トラスト・パケット・ルーティングの開始を参照してください。

AVMCにZPRセキュリティ属性を適用するには、次のオプションがあります。

AVMCのプロビジョニング時にセキュリティ属性を適用します。詳細は、Autonomous Exadata VMクラスタの作成を参照してください。
既存のAVMCリソースにセキュリティー属性を適用します。詳細は、AVMCのZero Trust Packet Routing (ZPR)の構成を参照してください。

前提条件として、ZPRセキュリティ属性をAVMCに正常に追加するには、次のIAMポリシーを定義する必要があります:

allow group <group_name>
to { ZPR_TAG_NAMESPACE_USE, SECURITY_ATTRIBUTE_NAMESPACE_USE }
in tenancy

allow group <group_name>
to manage autonomous-database-family
in tenancy

allow group <group_name>
to read security-attribute-namespaces
in tenancy

アクセス制御リスト(ACL)

セキュリティを強化するために、Oracle Public CloudとExadata Cloud@Customerの両方の専用デプロイメントでアクセス制御リスト(ACL)を有効にできます。ACLは、特定のIPアドレスを持つクライアントのみにデータベースへの接続を許可することにより、データベースを保護します。IPアドレスは、個別に追加するか、CIDRブロックで追加することができます。IPv4ベースとIPv6ベースのIP/CIDRの両方がサポートされています。これにより、Autonomous Databaseのネットワーク・アクセスを特定のアプリケーションまたはクライアントに制限することで、ファイングレイン・アクセス・コントロール・ポリシーを形成できます。

データベース・プロビジョニング時にオプションでACLを作成することも、後で作成することもできます。また、ACLはいつでも編集できます。IPアドレスのリストを空にしてACLを有効にすると、データベースにアクセスできなくなります。詳細は、専用Autonomous Databaseのアクセス制御リストの設定を参照してください。

Autonomous DatabaseでのACLの使用に関して、次のことに注意してください:

Autonomous Databaseサービス・コンソールは、ACLルールの対象ではありません。
Oracle Application Express (APEX)、RESTfulサービス、SQL Developer Webおよびパフォーマンス・ハブは、ACLの対象ではありません。
Autonomous Databaseの作成中にACLの設定に失敗すると、データベースのプロビジョニングも失敗します。
ACLの更新が許可されるのは、データベースが「使用可能」状態の場合のみです。
データベースをリストアしても、既存のACLは上書きされません。
データベースのクローニング(フルおよびメタデータ)は、ソース・データベースと同じアクセス制御設定になります。必要に応じて変更を加えることができます。
バックアップはACLルールの対象ではありません。
ACLの更新中、すべてのAutonomous Container Database (CDB)操作は許可されますが、Autonomous Database操作は許可されません。

Webアプリケーション・ファイアウォール(WAF)

アクセス制御リスト以外の高度なネットワーク制御の場合、Oracle Autonomous DatabaseではWeb Application Firewall (WAF)の使用がサポートされています。WAFは、悪意のある不要なインターネット・トラフィックからアプリケーションを保護します。WAFは、インターネット接続エンドポイントを保護することで、顧客のアプリケーションに対する一貫性のあるルール適用を実現できます。WAFを使用すると、クロスサイト・スクリプト(XSS)やSQLインジェクション、OWASP定義のその他の脆弱性を含むインターネットの脅威に対してルールを作成および管理できます。アクセス・ルールは、地理情報またはリクエストの署名に基づいて制限できます。WAFの構成方法のステップは、Web Application Firewallポリシーの開始を参照してください。

クライアント接続制御

Oracle Autonomous Databaseは、クライアント接続を認証するために、標準のTLS 1.2およびTLS 1.3証明書ベース認証を使用してクライアント接続制御を実装します。ただし、TLS 1.3はOracle Database 23ai以降でのみサポートされています。

デフォルトでは、Autonomous Databaseは自己署名証明書を使用します。ただし、Oracle Cloud Infrastructure (OCI)コンソールからCA署名のサーバー側証明書をインストールできます。独自の証明書を持ち込むには、証明書の作成で示すように、まずOracle Cloud Infrastructure (OCI)証明書サービスを使用して証明書を作成する必要があります。これらの証明書は署名済で、PEM形式である必要があります。つまり、ファイル拡張子は.pem、.cerまたは.crtのみである必要があります。詳細は、専用Autonomous Databaseでの証明書管理を参照してください。

データベース・ユーザー・アクセス制御

Oracle Autonomous Databaseは、Oracle Databaseの標準ユーザー管理機能を使用するように作成したデータベースを構成します。1つの管理ユーザー・アカウントADMINが作成されます。追加のユーザー・アカウントを作成したり、アカウントのアクセス制御を提供するには、これを使用します。

標準のユーザー管理では、システムやオブジェクトの権限、ロール、ユーザー・プロファイル、パスワード・ポリシーなど、機能および制御の堅牢なセットが提供されるため、ほとんどのケースでセキュアなデータベース・ユーザー・アクセス戦略を定義および実装できます。詳細な手順は、データベース・ユーザーの作成および管理を参照してください。

標準のユーザー管理に関する基本情報については、『Oracle Database概要』のユーザー・アカウントに関する項を参照してください。詳細は、Oracle Database 19cセキュリティ・ガイドまたはOracle Database 23aiセキュリティ・ガイドのOracle Databaseユーザーのセキュリティの管理を参照してください。

データベース・ユーザーのアクセス戦略で標準のユーザー管理よりも多くの制御が必要な場合は、より厳格な要件を満たすために、次のいずれかのツールを使用するように自律型データベースを構成できます。

ツール	説明
Database Vault	Oracle Database Vaultは事前構成されており、Autonomous Databaseですぐに使用できます。その強力なセキュリティ制御を使用して、特権データベース・ユーザーによるアプリケーション・データへのアクセスを制限することで、内部および外部の脅威のリスクを減らし、一般的なコンプライアンス要件に対応できます。詳細は、Autonomous Databaseのセキュリティ機能のデータ保護を参照してください。
Oracle Cloud Infrastructure Identity and Access Management (IAM)	Oracle Cloud Infrastructure Identity and Access Management (IAM)の認証および認可を使用するようにAutonomous Databaseを構成し、IAMユーザーがIAM資格証明を使用してAutonomous Databaseにアクセスできるようにします。このオプションをデータベースで使用するには、「Autonomous Databaseに対するIdentity and Access Management (IAM)認証の使用」を参照してください。
Azure OAuth2アクセス・トークン	Microsoft Azure Active Directory (Azure AD)サービスで、Azure `oAuth2`アクセス・トークンを使用してOracle Autonomous Databaseユーザーを集中管理できます。このタイプの統合により、Azure ADユーザーはOracle Autonomous Databaseインスタンスにアクセスできます。Azure ADユーザーおよびアプリケーションは、Azure ADシングル・サインオン(SSO)資格証明を使用してログインし、Azure AD `OAuth2`アクセス・トークンを取得してデータベースに送信できます。 Microsoft Azure Active Directoryとデータベースの統合の詳細は、Autonomous DatabaseのMicrosoft Azure Active Directoryユーザーの認証および認可を参照してください。
Microsoft Active Directory (CMU-AD)	Microsoft Active Directoryをユーザー・リポジトリとして使用する場合は、Microsoft Active Directoryユーザーを認証および認可するようにAutonomous Databaseを構成できます。この統合により、標準のユーザー管理、Database Vault、Real Application Securityまたは仮想プライベート・データベースのいずれを使用するかに関係なく、ユーザー・リポジトリを統合しつつ、厳格なデータベース・ユーザー・アクセス戦略を実装できます。 Microsoft Active Directoryとデータベースの統合の詳細は、Microsoft Active DirectoryとAutonomous Databaseを参照してください。
Kerberos	Kerberosは、共有秘密を使用するサード・パーティの認証システムです。Kerberosは、サード・パーティがセキュアであることを保障し、シングル・サインオン機能、集中化されたパスワード・ストレージ、データベース・リンク認証、拡張されたPCセキュリティを提供します。Kerberosは、Kerberos認証サーバーを使用して認証を行います。 Autonomous DatabaseはKerberosをサポートしており、Oracleユーザーにシングル・サインオンおよび集中化された認証の利点を提供します。詳細は、Kerberosを使用したAutonomous Databaseユーザーの認証を参照してください。
CMU-ADを使用したKerberos	Microsoft Active DirectoryユーザーにCMU-AD Kerberos認証を提供するために、CMU-AD上にKerberos認証を構成できます。 Microsoft Active DirectoryユーザーにCMU-AD Kerberos認証を提供するために、「Autonomous DatabaseでのKerberos認証の有効化」で説明した例に示すように、`type`を`CMU`に設定し、外部認証を有効にすることで、CMU-AD上でKerberos認証を有効にできます。
Real Application Securityおよび仮想プライベート・データベース	Oracle Real Application Security (RAS)は、保護対象のビジネス・オブジェクトだけでなく、それらのビジネス・オブジェクトに対する操作権限を持つプリンシパル(ユーザーおよびロール)も網羅するセキュリティ・ポリシーを有効にする宣言モデルを提供します。RASは、先行のOracle Virtual Private Databaseよりも安全かつスケーラブルで、コスト効率に優れています。 Oracle RASを使用すると、アプリケーション・ユーザーはデータベース内だけでなくアプリケーション層でも認証されます。データ・アクセス・パスに関係なく、データベース内のエンドユーザーのネイティブ・セッションに基づいて、データベース・カーネル内でデータ・セキュリティ・ポリシーが適用されます。ユーザーに割り当てられた権限によって、データベース・オブジェクトの行と列に対して実行できる操作のタイプ(選択、挿入、更新および削除)が制御されます。 Oracle RASの詳細は、Oracle Database 19c Real Application Security管理者および開発者ガイドまたはOracle Database 23ai Real Application Security管理者および開発者ガイドのOracle Database Real Application Securityの概要を参照してください。 Oracle Autonomous Databaseでは、Oracle RASに先行するOracle Virtual Private Database(VPD)もサポートされています。Oracle VPDをすでに使い慣れている場合は、それを構成してAutonomous Databaseで使用できます。仮想プライベート・データベースの詳細は、『Oracle Database 19cセキュリティ・ガイド』または『Oracle Database 23aiセキュリティ・ガイド』のOracle Virtual Private Databaseを使用したデータ・アクセスの制御を参照してください。

特権アクセス管理(PAM)

製品およびサービス全体でのユーザー・アクセスおよび権限管理に関するOracleのセキュリティ状態は、Oracle Access Controlに記載されています。

専用Exadataインフラストラクチャ上のAutonomous Databaseは、カスタマ・サービスおよびデータベース・データを不正アクセスから分離して保護するように設計されています。Autonomous Databaseは、顧客とOracleの間で職務を分離します。顧客は、データベース・スキーマへのアクセスを制御します。Oracleは、Oracle管理インフラストラクチャおよびソフトウェア・コンポーネントへのアクセスを制御します。

Autonomous Database on Dedicated Exadata Infrastructureは、お客様が認可した使用のためにデータを保護し、不正アクセスからデータを保護できるように設計されています。これには、Oracle Cloud Opsスタッフによる顧客データへのアクセスの防止が含まれます。Exadataインフラストラクチャ、Autonomous VMsおよびOracleデータベース・データへの不正アクセスから保護するために設計されたセキュリティ対策には、次のものがあります。

Oracle Databaseデータは、Oracle Transparent Data Encryption (TDE)キーによって保護されます。
お客様はTDE暗号化キーへのアクセスを制御し、そのようなキーを外部のOracle Key Vaultキー管理システムに格納することを選択できます。
Oracle Database Vaultは、特権ユーザーがAutonomous Databaseの顧客データにアクセスできないように事前構成されています。
お客様は、オペレータ・アクセス・コントロール・サービス登録を介してオペレータ・アクセスを承認することを選択できます。
すべてのオペレータ・アクセスは、FIPS 140-2レベル3のハードウェア多要素認証に基づいており、Oracle承認デバイスで実装されたハードウェアYubiKeyで実装されています。
オペレータ・アクションはすべてコマンド・レベルで記録され、ほぼリアルタイムでOCIロギング・サービスまたは顧客SIEMに送信できます。
Oracle Operations Access Controlは、Oracle Cloudの運用およびサポート・スタッフがパフォーマンスの監視および分析に使用するユーザー・アカウントが、Autonomous Databaseのデータにアクセスできないようにします。Oracle Cloudの運用およびサポート・スタッフは、Autonomous Databaseのデータにアクセスできません。Autonomous Container Databaseを作成する場合、専用Exadataインフラストラクチャ上のAutonomous Databaseは、コンテナ・データベースで作成されたAutonomous Databaseのデータへの共通ユーザーのアクセスをブロックするように、Oracle Database Vaultの操作制御機能を有効にして構成します。
運用制御がアクティブになっていることを確認するには、Autonomous Databaseで次のSQL文を入力します:
```
SELECT * FROM DBA_DV_STATUS;
```
ステータスがAPPLICATION CONTROLであれば、運用制御がアクティブになっています。

ノート:
操作制御は、以前はアプリケーション制御と呼ばれていました。

Autonomous Databaseのセキュリティ機能で説明されているように、PAMはデータ保護のためにDatabase Vaultとともに実装されます。

タイトルおよび著作権情報

Oracle and/or its affiliates.