RDS for OracleのDBリンクは暗号化されているのか｜KMS暗号化とOracle Net通信は別物

はじめに

2025年1月、異なるAWSアカウントにある2台のRDS for OracleをDatabase Link（以下、DBリンク）で接続する構成を検討していました。

一方はAWS KMSによるストレージ暗号化あり、もう一方は暗号化なしです。

本記事では、KMS暗号化ありのRDS AをDBリンク元、暗号化なしのRDS BをDBリンク先として説明します。NNEではDBリンク元とDBリンク先で設定するパラメータが異なるためです。

クロスアカウントRDS for OracleのDBリンク構成

つまり、A側に作成したDBリンクからBへ接続します。

ここでいう「DBリンクの方向」は接続を開始する方向です。AからBの表をSELECTすれば結果データはBからAへ返るため、DBリンクの向きとデータが流れる向きは同じとは限りません。

最初に疑問だったのは、

「KMSで暗号化されたRDSから、暗号化されていないRDSへDBリンクを張って問題ないのか」

ということでした。

問い合わせでは「データが文字化けしないか」という表現も使いました。しかし今振り返ると、本当に確認したかったのは文字コードの問題ではありません。

ストレージ上で暗号化されたデータがOracle Databaseからどう見え、DBリンクではどの状態で扱われるのか

という疑問でした。

さらに、

相手AWSアカウントへKMSキーを共有する必要があるのか
別VPC間でDBリンクを成立させるには何が必要なのか

も確認しました。

このとき印象的だったのが、AWSサポートから最初に、

「今回の暗号化とは、RDSのストレージボリューム暗号化という理解でよいか」

という趣旨の確認が入ったことです。

この確認が、今回の記事の本質です。

RDS for Oracleで「暗号化」と言っても、実際には複数のレイヤーがあります。

AWS KMSによるRDSストレージ暗号化
Oracle Transparent Data Encryption（TDE）
Oracle NetのNNE／SSL/TLS
AWSネットワーク基盤側の通信暗号化

「RDSが暗号化されている」ことと「DBリンク通信が暗号化されている」ことは別の話です。

本記事では、2026年8月時点のAWS公式仕様も確認しながら、この違いを整理します。

結論｜KMSによるRDS暗号化はDBリンクへ引き継がれない
RDS for Oracleで分けて考える4つの暗号化レイヤー
KMS暗号化はどこまでの話なのか｜TDEとの違いとKMSキー共有
1. Oracle TDEはKMS暗号化とは別物
2. DBリンク接続ではKMSキー共有は不要
別AWSアカウントのRDS間でDBリンクを成立させる条件
DBリンク通信の暗号化はKMSとは別に構成する｜NNEの設計
RDS間DBリンクはSSL/TLSでも暗号化できる
AWS基盤側の通信暗号化とOracle Net暗号化は分けて考える
まとめ｜「暗号化されているか」ではなく「どのレイヤーか」で考える

結論｜KMSによるRDS暗号化はDBリンクへ引き継がれない

結論から言えば、AWS KMSによるRDSストレージ暗号化が原因で、DBリンクのSELECT結果が暗号文になることはありません。

そもそも、DBリンク先のOracle Databaseがリンク元RDSのKMSキーを使ってデータを復号する仕組みではありません。

AWSサポートからも、KMSによる暗号化はストレージレイヤーで処理され、ストレージから読み出す際には透過的に復号されるため、ストレージ暗号化を原因としてDBリンクのデータが文字化けすることはない、という回答を得ています。

この「ストレージ暗号化を原因として」という限定も重要です。文字コードやOracle Netなど、別の原因による問題まで否定しているわけではありません。

AWS公式でも、RDSの保存時暗号化は基盤ストレージ、ログ、自動バックアップ、Read Replica、スナップショットなどを対象とし、RDSが復号を透過的に処理すると説明されています。

概念的には次の関係です。

KMSによるRDS暗号化とOracle Database／DBリンクの関係

Oracle Database自身が、KMSで暗号化されたストレージブロックを受け取ってKMSキーで復号しているわけではありません。

したがって、DBリンク接続のためにA側のKMSキーをB側AWSアカウントへ共有する必要もありません。

また、AからDBリンク経由でBへデータを書き込んだ場合、A側のストレージ暗号化属性がBへ引き継がれるわけでもありません。Bへ保存されたデータを暗号化するかどうかは、B自身のRDS暗号化設定で決まります。

なお、既存の非暗号化RDS DBインスタンスを、そのまま後から暗号化済みに変更することはできません。暗号化したスナップショットコピーを作成し、そこから新しいDBインスタンスをリストアする必要があります。

つまり、

「必要になったら後から暗号化をONにすればよい」

という設計にはできません。

RDS for Oracleで分けて考える4つの暗号化レイヤー

今回の話は、次の4レイヤーに分けると整理できます。

レイヤー	何を保護するか	主な仕組み	DBリンクとの関係	設計上のポイント
RDSストレージ	ストレージ、ログ、バックアップ、スナップショット等	AWS KMSを利用したRDS暗号化	KMSキーや暗号化属性はDBリンク先へ伝播しない	encryption at rest。Oracle Net通信とは別
Oracle Database	Oracleが管理する保存データ	Oracle TDE	復号後の論理データがOracle Netへ渡る	Enterprise Edition＋BYOL。KMS暗号化とは別レイヤー
Oracle Net	DB間・クライアント間の通信	NNEまたはSSL/TLS	DBリンク通信そのものをOracleレイヤーで暗号化する	NNEとSSL/TLSは同一DBインスタンスで併用不可
AWSネットワーク基盤	AWS基盤を流れる通信	Nitro、VPC Encryption Controls等	DBリンク通信も下位レイヤーで暗号化される場合がある	基盤側とOracle Net側の暗号化状態は別であり、一方の証跡だけでもう一方を証明・否定できない

ポイントは、どれか一つを有効にすれば他のレイヤーまで暗号化されるわけではないことです。

KMS暗号化はどこまでの話なのか｜TDEとの違いとKMSキー共有

Oracle TDEはKMS暗号化とは別物

Oracle Transparent Data Encryption（TDE）は、Oracle Database側でデータを暗号化する仕組みです。

RDSのKMS暗号化がOracleより下のストレージレイヤーで処理されるのに対し、TDEではOracle Databaseがデータを書き込む前に暗号化し、読み出す際に復号します。

RDS for OracleでTDEを利用できるのはOracle Enterprise Edition＋BYOLです。Oracle WalletとTDE master keyはAmazon RDSが管理します。

TDEには設計時に注意すべき制約があります。

AWSではRDS for OracleのTDEをpermanent／persistentなオプションとして扱っており、一度有効にすると無効化できず、TDEを含まないOption Groupへ変更することもできません。TDEを利用するDBスナップショットは共有できません。

つまり、TDEは後から簡単に外せるオプションではありません。

RDS for Oracleには、TDE以外にもオンプレOracleの前提をそのまま持ち込めない制約があります。詳しくは「RDS for Oracleを採用したら、オンプレ運用の前提が通用しなかった」で整理しています。

RDS for Oracleを採用したら、オンプレ運用の前提が通用しなかった｜開発中に見えた設計ギャップと代替アプローチ

RDS for Oracleではオンプレ運用の前提が通用しない。Storage-Full、アーカイブログ、SSH不可など、開発中に見えた9つの設計ギャップと代替アプローチを整理します。

また、TDEで保護されたデータも、暗号文のままDBリンクへ流れるわけではありません。Oracleが論理データへ復号した後、Oracle Netへ渡されます。

その先の通信を暗号化するのはNNEまたはSSL/TLSです。

RDSのKMS暗号化 ≠ Oracle TDE ≠ DBリンク通信の暗号化

という関係です。

DBリンク接続ではKMSキー共有は不要

DBリンクでは、各RDSの保存時暗号化は各RDS内で処理されます。

A側OracleがB側のKMSキーを使うわけでも、B側OracleがA側のKMSキーを使うわけでもありません。

したがって、クロスアカウントDBリンクのためにKMSキーを共有する必要はありません。

一方、暗号化されたDBスナップショットそのものを別AWSアカウントへ共有する場合は、KMSキーへのクロスアカウントアクセスが関係します。

AWSアカウントのデフォルトKMSキーで暗号化されたスナップショットはそのまま共有できません。AWS公式では、対象アカウントへアクセスを許可したcustomer managed keyを用意し、そのキーでスナップショットをコピーして共有し、共有先でも自アカウントのKMSキーを指定してコピーする手順が案内されています。

DBリンクとスナップショット共有では、

論理データへアクセスするのか、暗号化されたAWSリソース自体を共有するのか

が違います。

別AWSアカウントのRDS間でDBリンクを成立させる条件

KMSキー共有が不要でも、別AWSアカウントのRDSへそのままDBリンクを張れるわけではありません。

先に、AからBへOracle Netで到達できるネットワークを作る必要があります。

確認順序は、

VPC間接続 → Route → Security Group／NACL → DNS → Oracle Net → Database Link

と考えると分かりやすいです。

AWSサポートからはVPC Peeringが例示されました。AWS公式のRDS for Oracle DBリンク手順でも、同一VPCまたはピア接続されたVPC間で、有効なルート、ACL、Security Group、名前解決を確認するよう案内されています。

ただし、Database LinkというOracle機能自体がVPC Peeringを要求しているわけではありません。

本質的な要件は、DBリンク元からDBリンク先のRDS endpointとOracle Listenerポートへ到達できることです。

本記事ではAをDBリンク元としているため、基本となる通信方向は、

A側：Bへのoutbound
B側：AからOracle Listenerポートへのinbound

です。

Security Groupはstatefulなので、戻り通信のためだけに対称のinboundルールを追加する必要はありません。一方、Network ACLを独自に制限している場合はstatelessなので、復路も確認します。

接続先にはIPアドレスを固定せず、RDS endpointのDNS名を使用します。RDS自身も、基盤IPはフェイルオーバー等で変わり得るため、DNS名を利用することを推奨しています。

別VPCの場合はDNSも確認します。

VPC Peering越しでAmazon提供DNSを利用する場合は、VPC側のenableDnsSupportと、Peering接続側のDNS解決サポートを確認します。カスタムDNSを利用している場合は、そのDNSサーバーがDBリンク先を解決できる必要があります。

つまり、

Routeがある／SGが通る／DNSが引ける

を分けて確認する必要があります。

DBリンク通信の暗号化はKMSとは別に構成する｜NNEの設計

DBリンクのOracle Net通信を暗号化する方法の一つがNative Network Encryption（NNE）です。

RDS for Oracleでは、Option GroupへNATIVE_NETWORK_ENCRYPTIONを追加して利用します。NNEはOracle Databaseの全エディションで利用できます。

ここで重要なのは、

NNEオプションを追加しただけで「暗号化を必須にした」と考えてはいけない

ことです。

DBリンク元RDSはOracle Net clientになる

本記事の構成では、

A：DBリンク元 → Oracle Net client
B：DBリンク先 → Oracle Net server

です。

AWS公式も、DBインスタンスがDatabase Linkを利用するとき、そのDBインスタンスはクライアントとして動作すると明記しています。

したがって主に確認するのは、

A側：

SQLNET.*CLIENT

B側：

SQLNET.*SERVER

です。

Requestedは「必須」ではない

RDSのNNE Optionでは、SQLNET.ENCRYPTION_CLIENTとSQLNET.ENCRYPTION_SERVERの既定値はいずれもRequestedです。

ただし、この既定値はNNEオプションを追加した後の話です。NNEオプションを追加していないRDSが、最初からNNEで通信しているという意味ではありません。

また、Requestedだから暗号化されないという意味でもありません。

CLIENT／SERVERともにRequestedで双方がNNEを利用できれば暗号化は成立します。

問題は、相手が暗号化に対応しなくても、暗号化なしで接続できる場合があることです。

つまり、

「暗号化されることがある」と「暗号化を必須条件として保証する」は別です。

AからBへのDBリンクについて暗号化を必須にしたい場合、A側を例えば、

SQLNET.ENCRYPTION_CLIENT=Required

とします。

B側がRequestedでも、接続が成立すれば暗号化されます。暗号化条件を満たせなければ接続自体が失敗します。

一方、B側を、

SQLNET.ENCRYPTION_SERVER=Required

とすると、DBリンクだけでなくBへ接続する他のOracle Netクライアントにも暗号化を要求します。

したがって、

DBリンクだけを暗号化したいのか、RDSへの全接続を暗号化したいのか

を分けて設計します。

Requiredだけでなく暗号方式も確認する

さらに注意したいのが暗号アルゴリズムです。

Oracle Database 19cなどのRDS NNE設定では、既定候補にAESだけでなくRC4、3DES、DESも含まれ、既定リストはRC4_256から始まります。AWSはDES、3DES、RC4をsecure encryption methodとは扱っていません。

そのため、

SQLNET.ENCRYPTION_CLIENT=Required

だけでは、使用する暗号方式まで安全なものへ限定したことにはなりません。

例えばAES256へ限定する設計なら、

A側：

SQLNET.ENCRYPTION_CLIENT=Required
SQLNET.ENCRYPTION_TYPES_CLIENT=AES256

B側：

SQLNET.ENCRYPTION_SERVER=Requested または Required
SQLNET.ENCRYPTION_TYPES_SERVER=AES256

のように、CLIENT／SERVER双方で共通する方式を設定します。

SQLNET.ALLOW_WEAK_CRYPTOとSQLNET.ALLOW_WEAK_CRYPTO_CLIENTSはいずれも既定値がTRUEです。弱い方式を禁止する場合はこちらも確認しますが、既存クライアントのパッチレベルや互換性へ影響するため、接続元を確認した上で変更する必要があります。

暗号化と整合性チェックは別設定

NNEでは、通信の暗号化とは別にデータ改ざんを検知するチェックサムも設定できます。

SQLNET.ENCRYPTION_*をRequiredにしても、SQLNET.CRYPTO_CHECKSUM_*が自動的にRequiredになるわけではありません。

盗聴対策と改ざん検知は別々に設計する必要があります。

「暗号化されているか」だけでなく方式まで確認する

設定後はV$SESSION_CONNECT_INFOを確認し、実際にネゴシエーションされた暗号方式を確認できます。

SELECT NETWORK_SERVICE_BANNER
FROM V$SESSION_CONNECT_INFO
WHERE SID = SYS_CONTEXT('USERENV', 'SID');

NNEが有効ならencryption service adapterを含む行が表示され、AES256など実際にネゴシエーションされた方式を確認できます。

見るべきなのは、

「暗号化されているか」だけではなく「何で暗号化されているか」

です。

既定候補にはRC4_256も含まれるため、AES256など設計時に想定した方式が実際に使われているところまで確認する必要があります。

なお、DBリンクによって生成されたリモートセッションをどのように特定し、証跡化するかについては、DBリンク固有の実機確認が必要です。

RDS間DBリンクはSSL/TLSでも暗号化できる

DBリンクの暗号化方式はNNEだけではありません。

AWS公式には、Oracle DBインスタンス間では、各インスタンスにOracle SSLオプションが構成されていれば、SSL/TLS endpoint経由でDatabase Linkを確立でき、追加構成は不要と明記されています。

つまり、本記事のA→B構成でも、両RDS for OracleへSSLオプションを設定することでDBリンク通信をTLS化できます。

SSLオプションを入れただけでは全通信TLSにはならない

RDS for Oracleでは、SSL接続用に通常接続とは別の第2ポートを利用します。

そのため、

通常ポート：非SSL通信
SSLポート：SSL/TLS通信

を同じDBインスタンスで併存できます。

つまり、SSLオプションを追加しただけでは、そのRDSへの全通信がTLS必須になるわけではありません。

TLSを必須にする場合は、SSL/TLS endpointを利用することに加えて、Security Group等で非SSL経路を許可していないかも確認する必要があります。

NNEはOracle NetのネゴシエーションでRequiredを使って強制し、TLSはポートと接続経路で強制するという違いがあります。

TLSバージョンとCipher Suiteも確認する

2026年8月時点で、RDS for Oracleの19c／21cはTLS 1.0と1.2をサポートしています。

特に既存のOracle SSLオプションでは、SQLNET.SSL_VERSIONが自動的に1.0へ設定されています。既存環境では「SSLを使っている＝TLS 1.2」と判断せず、設定値を確認する必要があります。26aiではTLS 1.2のみがサポートされています。

Cipher Suiteも同様です。

19c／21cの既定Cipher SuiteであるSSL_RSA_WITH_AES_256_CBC_SHAはFIPS対応ですが、AWS公式表ではFedRAMP準拠ではありません。つまり、既定値のままで自分たちのセキュリティ要件を満たすとは限りません。

また、RDS for OracleではRSA証明書とECDSA証明書をサポートしており、SQLNET.CIPHER_SUITEへ指定する方式はDBインスタンスの証明書タイプと互換である必要があります。互換性のないCipher Suiteしか設定していないOption GroupはDBインスタンスへの関連付けに失敗します。

NNEとSSL/TLSは併用できない

NNEとSSL/TLSは、同じRDS for Oracle DBインスタンスで併用できません。

したがって、

NNEで暗号化した上にTLSを重ねる

という構成にはできません。

観点	NNE	SSL/TLS
方式	Oracle独自	業界標準
証明書	不要	使用
DBリンクで利用	可能	可能
強制方法	`Required`によるOracle Netネゴシエーション	SSLポートと接続経路
CLIENT／SERVER設定	区別あり	両RDSにSSLオプション
併用	TLSと併用不可	NNEと併用不可

どちらを採用するかは、既存の接続方式、証明書管理、接続クライアント、セキュリティ基準から判断します。

重要なのは、

KMSによるRDS暗号化とは別に、Oracle Net通信の暗号化方式を選ぶ

ことです。

AWS基盤側の通信暗号化とOracle Net暗号化は分けて考える

AWSネットワーク基盤側にも通信暗号化の仕組みがあります。

Amazon RDSでは、一部のインスタンスタイプについてNitro Systemによるインスタンス間通信の自動暗号化が提供されています。ただし、対象インスタンスタイプ、同一Region、同一VPCまたはVPC Peering、Transit Gateway等の仮想ネットワークサービスを経由しないことなどの条件があります。

RDS for Oracleでは、Oracleで利用可能なインスタンスクラスと、Nitroによる自動暗号化の対象一覧を別々に確認する必要があります。

例えば、RDS全体の自動暗号化対象一覧に含まれるM7g／R7gはRDS for Oracleの利用可能クラスには含まれていません。一方、RDS for Oracleで利用可能なM7i／R7i／M8i／R8iは、2026年8月時点の自動暗号化対象一覧には列挙されていません。

したがって、「新しい世代だから自動的に暗号化される」とは判断できません。

さらに2025年11月にはVPC Encryption Controlsが追加され、AWS基盤側の転送時暗号化をMonitor／Enforceで監視・強制できるようになりました。RDS公式でも、Enforce VPCでは転送時暗号化をサポートするNitroベースのDBインスタンスのみ新規プロビジョニングできるとされています。既存VPCをEnforceへ移行する際は、まずMonitorで非準拠リソースを確認・是正する必要があります。

ただし、ここでDBリンクの記事として重要なのは、AWS基盤側の証跡とOracle Net側の証跡は同じではないことです。

VPC Flow Logsではencryption-statusとして、