1. Advanced Securityガイド
  2. 透過的データ暗号化の使用
  3. 透過的データ暗号化を使用する場合の一般的な考慮事項

5 透過的データ暗号化を使用する場合の一般的な考慮事項

透過的データ暗号化を使用するときは、セキュリティ、パフォーマンス、記憶域のオーバーヘッドなどの要因を考慮する必要があります。

親トピック: 透過的データ暗号化の使用

5.1 暗号化データの圧縮とデータ重複除外

表領域の暗号化を使用して、Oracle Databaseでは表領域の暗号化前に表と索引を圧縮します。

これにより、保存の暗号化のセキュリティを確保しながら、圧縮による、容量とパフォーマンス上のメリットを最大限に得ることができます。CREATE TABLESPACE SQL文には、COMPRESSとENCRYPT句の両方が含まれます。

列暗号化を使用すると、Oracle Databaseでは列を暗号化した後でデータを圧縮します。これは、圧縮には、暗号化された列で最小限の有効性があることを意味します。注目すべき例外が1つあります。列がSecureFiles LOBであり、暗号化がSecureFiles LOB暗号化を使用して実装され、圧縮(重複除外の場合もあり)がSecureFiles LOB圧縮および重複除外を使用して実装されている場合、圧縮は暗号化の前に実行されます。表領域の暗号化のCREATE TABLESPACE文と同様に、COMPRESSとENCRYPT句の両方が含まれます。

関連項目:

親トピック:  透過的 データ暗号化を使用する場合の一般的な考慮事項

5.2 透過的データ暗号化のセキュリティに関する考慮事項

TDEポリシーを作成する場合には、Oracle Databaseのすべての機能のときと同様に、セキュリティを考慮する必要があります。

親トピック:  透過的 データ暗号化を使用する場合の一般的な考慮事項

5.2.1 透過的データ暗号化のセキュリティに関する一般的なアドバイス

透過的データ暗号化(TDE)を使用する場合のセキュリティに関する考慮事項は、全システム・セキュリティの広範囲に適用されます。

次の一般的なガイドラインに従ってください。

  • データベースのデータの機密度、必要な保護、および対処するリスクのレベルを識別します。たとえば、厳密な保護を必要とする機密度の高いデータは、AES256アルゴリズムで暗号化できます。それほど機密度の高くないデータベースは、パフォーマンス上の利点を得るために、no saltまたはnomacオプションを使用して保護できます。

  • データおよびキーストアの保護にとって許容できるコストと利点を評価します。キーの保護によって、使用するキーストアのタイプ(自動ログイン・ソフトウェア・キーストア、パスワードベースのソフトウェア・キーストアまたは外部キーストア)が決定されます。

  • TDEとデータベースに個別のセキュリティ管理者を割り当てることを検討します。

  • TDEに個別の排他的キーストアを割り当てることを検討します。

  • 暗号化データのための保護されたバックアップ手順を実施します。

親トピック: 透過的データ暗号化のセキュリティに関する考慮事項

5.2.2 透過的データ暗号化の列暗号化固有のアドバイス

セキュリティに関するその他の考慮事項は、TDEを使用している場合の通常のデータベース操作およびネットワーク操作に適用されます。

暗号化列のデータは、データ・ファイル、UNDOログ、REDOログおよびシステム・グローバル領域(SGA)のバッファ・キャッシュ内では暗号化されたままになります。一方、データは式の評価時に復号化されるため、ディスク上のスワップ・ファイルには復号化後のデータを表示できます。権限のあるオペレーティング・システム・ユーザーは、このデータを表示できる可能性があります。

TDEを使用して暗号化された列値は、暗号化された形式でデータ・ファイルに格納されます。ただし、これらのデータ・ファイルには、表に対する過去のデータ操作で残されたゴースト・コピーと呼ばれるプレーン・テキストの断片が含まれている場合があります。これは、オペレーティング・システムによってファイルが削除された後に、ディスク上にデータが残存している場合に類似しています。

親トピック: 透過的データ暗号化のセキュリティに関する考慮事項

5.2.3 平文の断片のセキュリティの管理

一定期間存在する可能性のある古い平文の断片は削除する必要があります。

古いプレーン・テキストの断片は、それらの値を含んでいるブロックがデータベースによって上書きされるまで、しばらく存在し続ける可能性があります。権限のあるオペレーティング・システム・ユーザーがデータベースのアクセス制御をバイパスした場合、表領域を保持するデータ・ファイル内のこれらの値に直接アクセスされる可能性があります。

このリスクを最小限に抑えるには:

  1. 新しいデータ・ファイルに新しい表領域を作成します。

    CREATE TABLESPACE文を使用して、この表領域を作成できます。

  2. 暗号化列を含む表を新しい表領域に移動します。ALTER TABLE.....MOVE文を使用できます。

    元の表領域のすべてのオブジェクトについて、このステップを繰り返します。

  3. 元の表領域を削除します。

    DROP TABLESPACE tablespace INCLUDING CONTENTS KEEP DATAFILES文を使用できます。データ・ファイルは、プラットフォーム固有のユーティリティを使用して安全に削除することをお薦めします。

  4. 古いデータ・ファイルを安全に削除するには、プラットフォームおよびファイル・システムに固有のユーティリティを使用してください。このようなユーティリティの例には、shred (Linuxの場合)やsdelete (Windowsの場合)などがあります。

親トピック: 透過的データ暗号化のセキュリティに関する考慮事項

5.3 透過的データ暗号化のパフォーマンスと記憶域のオーバーヘッド

透過的データ暗号化のパフォーマンスは変わる場合があります。

親トピック:  透過的 データ暗号化を使用する場合の一般的な考慮事項

5.3.1 透過的データ暗号化のパフォーマンスのオーバーヘッド

透過的データ暗号化の表領域暗号化には、パフォーマンスのオーバーヘッドが多少伴います。

アプリケーションに対する実際のパフォーマンスの影響は異なることがあります。TDE列暗号化がパフォーマンスに影響を与えるのは、暗号化列に対してデータの取得または挿入が行われた場合のみです。暗号化されていない列に関係する操作の場合は、これらの列が暗号化列を含む表内にあっても、パフォーマンスが低下することはありません。暗号化列のデータへのアクセスでは多少のパフォーマンス・オーバーヘッドが伴いますが、発生する正確なオーバーヘッドは異なる場合があります。

全体的なパフォーマンスのオーバーヘッドは、暗号化列の数とそのアクセス頻度によって異なります。暗号化するのが最も妥当な列は、最高機密のデータを含む列です。

既存の表で暗号化を有効化すると、表の特性を変更する他のALTER TABLE操作と同様に、完全な表更新が行われます。大規模な既存の表で暗号化を有効化する前に、データベース・サーバーに与えるパフォーマンスおよびREDOログの潜在的な影響を考慮する必要があります。

表に対する書込み操作は、暗号化の有効化中、TDE表キーのキー更新中または暗号化アルゴリズムの変更中は一時的に実行できなくなる場合があります。このような処理が実行されている場合は、表のオンライン再定義を使用して、表への書込み操作が可能かどうかを確認できます。

大規模な表に対してTDE列暗号化を有効化している場合は、操作に対応できるよう、REDOログのサイズを大きくする必要があることがあります。

索引付けされた列の暗号化には、索引のない列の暗号化よりも多くの時間を要します。索引が作成された列を暗号化する必要がある場合は、索引を削除してから列をNO SALTで暗号化し、その後で索引を再度作成できます。

暗号化列に索引を付ける場合、索引は暗号化された値に対して作成されます。暗号化列の値を問い合せると、SQL問合せで使用される値がOracle Databaseで透過的に暗号化されます。その後、暗号化された値を使用して、索引の参照が実行されます。

ノート:

索引付けされた暗号化列のレンジ・スキャンを実行する必要がある場合は、TDE列暗号化のかわりにTDE表領域暗号化を使用します。

関連項目:

親トピック: 透過的データ暗号化のパフォーマンスと記憶域のオーバーヘッド

5.3.2 透過的データ暗号化の記憶域のオーバーヘッド

TDE表領域暗号化には記憶域のオーバーヘッドはありませんが、TDE列暗号化には多少の記憶域のオーバーヘッドが伴います。

暗号化列のデータには、プレーン・テキスト・データより多くの記憶域が必要です。さらに、TDEでは、暗号化された値が16バイトの倍数に拡張されます。これは、クレジット・カード番号の格納に9バイトが必要な場合、クレジット・カード番号を暗号化して格納するには、さらに7バイトが必要になることを意味します。

暗号化された各値は、20バイトの整合性チェックにも関連付けられます。これは、NOMACパラメータを使用して列を暗号化した場合には当てはまりません。saltを使用してデータを暗号化した場合は、暗号化された各値を格納するために、さらに16バイトの記憶域が必要になります。

暗号化された各値の記憶域の最大オーバーヘッドは1から52バイトです。

関連項目

親トピック: 透過的データ暗号化のパフォーマンスと記憶域のオーバーヘッド

5.4 透過的データ暗号化と組み合せて使用するためのアプリケーションの変更

アプリケーションで透過的データ暗号化を使用するよう、変更することができます。

  1. TDE用のソフトウェア・キーストアまたは外部キーストアを構成してから、マスター暗号化キーを設定します。

    詳細は、次の各項を参照してください。

  2. V$ENCRYPTION_KEYSビューのKEY_ID列を問い合せることで、マスター暗号化キーが作成されていることを確認します。

  3. 透過的データ暗号化による保護が必要な機密列(クレジット・カード・データが含まれるものなど)を特定します。

  4. TDE列暗号化またはTDE表領域暗号化のどちらを使用するか決定します。

    詳細は、次の各項を参照してください。

  5. キーストアを開きます。

    詳細は、次の各項を参照してください。

  6. 列または表領域を暗号化します。

    詳細は、次の各項を参照してください。

親トピック:  透過的 データ暗号化を使用する場合の一般的な考慮事項

5.5 ALTER SYSTEMおよびorapkiとADMINISTER KEY MANAGEMENTとの対応

ALTER SYSTEM文の多くの句は、ADMINISTER KEY MANAGEMENT文に対応しています。

表5-1では、透過的データ暗号化でのALTER SYSTEM文およびorapkiユーティリティの使用と、以前のリリースのADMINISTER KEY MANAGEMENT文を比較しています。

表5-1 ALTER SYSTEMおよびorapkiとADMINISTER KEY MANAGEMENTとの対応

動作                       ALTER SYSTEMまたはorapki ADMINISTER KEY MANAGEMENT                       

キーストアの作成

ソフトウェア・キーストアの場合(以前のリリースではウォレットと呼ばれていました) :

ALTER SYSTEM SET ENCRYPTION KEY
["certificate_ID"] IDENTIFIED
BY keystore_password;

外部キーストアの場合は、外部キーストアを構成した後に、キーストアを利用できるようになります。

ソフトウェア・キーストアの場合:

ADMINISTER KEY MANAGEMENT CREATE KEYSTORE
'keystore_location' 
IDENTIFIED BY software_keystore_password

外部キーストアの場合は、外部キーストアを構成した後に、キーストアを利用できるようになります。

自動ログイン・キーストアの作成

 
orapki wallet create -wallet
wallet_location 
-auto_login [-pwd password]

ソフトウェア・キーストアの場合:

ADMINISTER KEY MANAGEMENT CREATE [LOCAL]
AUTO_LOGIN KEYSTORE FROM KEYSTORE
'keystore_location' 
IDENTIFIED BY software_keystore_password;

このタイプのキーストアは、ソフトウェア・キーストアのみに適用されます。

キーストアを開く

 
ALTER SYSTEM SET [ENCRYPTION]
WALLET OPEN IDENTIFIED BY
password;
 
ADMINISTER KEY MANAGEMENT SET KEYSTORE 
OPEN IDENTIFIED BY keystore_password
[CONTAINER = ALL | CURRENT];

キーストアを閉じる

 
ALTER SYSTEM SET [ENCRYPTION]
WALLET CLOSE IDENTIFIED BY
password;

ソフトウェア・キーストアと外部キーストアの場合:

ADMINISTER KEY MANAGEMENT SET KEYSTORE 
CLOSE IDENTIFIED BY keystore_password
[CONTAINER = ALL | CURRENT];

外部キーストアからソフトウェア・キーストアへの移行

Oracleパッチ20181737を使用する場合: 

ALTER SYSTEM SET [ENCRYPTION] KEY
IDENTIFIED BY "Oracle_Key_Vault_password" 
MIGRATE USING wallet_password;
 
ADMINISTER KEY MANAGEMENT SET [ENCRYPTION]
KEY IDENTIFIED BY
software_keystore_password
REVERSE MIGRATE USING "external_key_manager_password"
WITH BACKUP [USING 'backup_identifier'];

ソフトウェア・キーストアからOracle Key Vaultへの移行

 
ALTER SYSTEM SET [ENCRYPTION] KEY
IDENTIFIED BY
"external_key_manager_password" MIGRATE
USING wallet_password;
 
ADMINISTER KEY MANAGEMENT SET [ENCRYPTION]
KEY IDENTIFIED BY "Oracle_Key_Vault_password"
MIGRATE USING wallet_password;

キーストア・パスワードの変更

 
orapki wallet change_pwd
-wallet wallet_location
[-oldpwd password ] 
[-newpwd password]

パスワードベースのソフトウェア・キーストアの場合:

ADMINISTER KEY MANAGEMENT ALTER KEYSTORE
PASSWORD IDENTIFIED BY
software_keystore_old_password 
SET software_keystore_new_password
[WITH BACKUP [USING 'backup_identifier']];

外部キーストアの場合は、キーストアを閉じ、外部キー・マネージャ・インタフェースで変更してから、キーストアを再度開きます。

パスワードベースのソフトウェア・キーストアのバックアップ

この機能と同等のALTER SYSTEMまたはorapkiはありません 

ADMINISTER KEY MANAGEMENT BACKUP KEYSTORE
[USING 'backup_identifier'] IDENTIFIED BY
software_keystore_password 
[TO 'keystore_location'];

2つのソフトウェア・キーストアから3つ目の新しいキーストアへのマージ

この機能と同等のALTER SYSTEMまたはorapkiはありません 

ADMINISTER KEY MANAGEMENT MERGE KEYSTORE
'keystore1_location' [IDENTIFIED BY
software_keystore1_password] 
AND KEYSTORE 'keystore2_location'
[IDENTIFIED BY software_keystore2_password]
INTO NEW KEYSTORE 'keystore3_location'
IDENTIFIED BY software_keystore3_password;

1つのソフトウェア・キーストアから別の既存のキーストアへのマージ

この機能と同等のALTER SYSTEMまたはorapkiはありません 

ADMINISTER KEY MANAGEMENT MERGE KEYSTORE
'keystore1_location' [IDENTIFIED BY
software_keystore1_password] 
INTO EXISTNG KEYSTORE 'keystore2_location'
IDENTIFIED BY software_keystore2_password
[WITH BACKUP [USING 'backup_identifier']];

マスター暗号化キーの設定またはローテーション

ソフトウェア・ウォレットの場合:

ALTER SYSTEM SET ENCRYPTION KEY
["certificate_ID"] IDENTIFIED
BY keystore_password;

外部キーストアの場合:

ALTER SYSTEM SET ENCRYPTION KEY
IDENTIFIED BY "external_key_manager_password"

ノート: ALTER SYSTEM SET ENCRYPTION KEY文は、暗号化キーをローテーションした後、V$ENCRYPTION_KEYS動的ビューを更新しません。 

ADMINISTER KEY MANAGEMENT 
SET ENCRYPTION KEY [USING TAG 'tag']
IDENTIFIED BY keystore_password 
WITH BACKUP [USING 'backup_identifier'] 
[CONTAINER = ALL | CURRENT];

暗号化キーをローテーションした後、V$ENCRYPTION_KEYS動的ビューが更新されます。

後で使用するマスター暗号化キーの作成

この機能と同等のALTER SYSTEMまたはorapkiはありません 

ADMINISTER KEY MANAGEMENT CREATE KEY 
[USING TAG 'tag'] 
IDENTIFIED BY keystore_password 
[WITH BACKUP [USING 'backup_identifier']]
[CONTAINER = (ALL|CURRENT)];

マスター暗号化キーのアクティブ化

この機能と同等のALTER SYSTEMまたはorapkiはありません 

ADMINISTER KEY MANAGEMENT USE KEY
'key_identifier' [USING TAG 'tag'] 
IDENTIFIED BY keystore_password 
[WITH BACKUP [USING 'backup_identifier']];

マスター暗号化キーのカスタム・タグの作成

この機能と同等のALTER SYSTEMまたはorapkiはありません 

ADMINISTER KEY MANAGEMENT SET TAG 'tag' 
FOR 'master_key_identifier' 
IDENTIFIED BY keystore_password 
[WITH BACKUP [USING 'backup_identifier']];

マスター暗号化キーのエクスポート

この機能と同等のALTER SYSTEMまたはorapkiはありません 

ADMINISTER KEY MANAGEMENT 
EXPORT [ENCRYPTION] KEYS 
WITH SECRET "export_secret" 
TO 'file_path' 
IDENTIFIED BY software_keystore_password
[WITH IDENTIFIER IN 
'key_id1', 'key_id2', 'key_idn' | 
(SQL_query)]

マスター暗号化キーのインポート

この機能と同等のALTER SYSTEMまたはorapkiはありません 

ADMINISTER KEY MANAGEMENT 
IMPORT [ENCRYPTION] KEYS 
WITH SECRET "import_secret" |  
FROM 'file_name' 
IDENTIFIED BY software_keystore_password
[WITH BACKUP [USING 'backup_identifier']];

キーストアへのOracle Databaseのシークレットの格納

この機能と同等のALTER SYSTEMまたはorapkiはありません

ソフトウェア・キーストアの場合:

ADMINISTER KEY MANAGEMENT
ADD SECRET|UPDATE SECRET|DELETE SECRET
"secret" FOR CLIENT 'client_identifier' 
[USING TAG'tag'] 
IDENTIFIED BY keystore_password 
[WITH BACKUP [USING 'backup_identifier'];

外部キーストアの場合:

ADMINISTER KEY MANAGEMENT
ADD SECRET|UPDATE SECRET|DELETE SECRET
"secret" FOR CLIENT 'client_identifier' 
[USING TAG 'tag'] 
IDENTIFIED BY "external_key_manager_password" 
[WITH BACKUP [USING 'backup_identifier'];

親トピック:  透過的 データ暗号化を使用する場合の一般的な考慮事項

5.6 PKI暗号化での透過的データ暗号化の使用

PKIによる暗号化は非推奨となっていますが、これをまだ使用している場合は、考慮する必要のある問題がいくつかあります。

ノート:

PKI暗号化と透過的データ暗号化を組み合せた使用は非推奨です。透過的データ暗号化を構成するには、ADMINISTER KEY MANAGEMENT SQL文を使用します。

親トピック:  透過的 データ暗号化を使用する場合の一般的な考慮事項

5.6.1 ソフトウェア・マスター暗号化キーとPKIキー・ペアとの併用

マスター暗号化キーは、暗号化用に指定されたPKI証明書の既存のキー・ペアにすることができます。

次の点に注意してください。

  • 組織内にすでにPKIをデプロイしている場合は、キー供託およびリカバリなどのPKIサービスを活用できます。ただし、現在のPKIアルゴリズムを使用する暗号化では、対称キー暗号化よりもはるかに多くのシステム・リソースが必要になります。マスター暗号化キーとしてPKIキー・ペアを使用すると、データベース内の暗号化列にアクセスする場合にパフォーマンスが大幅に低下する可能性があります。

  • PKIベースのキーの場合、証明書の失効を強制すると、暗号化されたデータベース内の情報すべてにアクセスできなくなる可能性があるため、証明書失効リストは強制されません。ただし、同じ証明書を使用してマスター暗号化キーを再び作成することはできません。

親トピック: PKI暗号化での透過的データ暗号化の使用

5.6.2 PKI暗号化とTDEの表領域およびハードウェア・キーストア

PKI暗号化は、2つのキー(公開キーと秘密キー)を使用してデータを暗号化する暗号システムです。

PKIベースの暗号化をTDE表領域暗号化やハードウェア・キーストアと一緒に使用することはできません。

親トピック: PKI暗号化での透過的データ暗号化の使用

5.6.3 PKIキー・ペアのバックアップおよびリカバリ

ソフトウェア・キーストアの場合、透過的データ暗号化では、列暗号化のためにマスター暗号化キーとしてPKI非対称キー・ペアを使用できます。

これにより、データベースでは、主要な認証局ベンダーの既存のキーのバックアップ、供託およびリカバリ機能を使用できます。

現在のキー供託またはリカバリ・システムでは、秘密キーのバージョンまたは秘密キーのリカバリに役立つ情報は、通常、キーのリカバリ機能を提供する認証局に保管されます。秘密キーが失われた場合、認証局に連絡し、キーのリカバリ・プロセスを開始することで、元のキーおよび証明書をリカバリできます。

通常、キーのリカバリ・プロセスは自動化されており、ユーザーは認証局に対して特定の認証資格証明を提示する必要があります。リカバリ対象となるキーおよびその関連証明書が、キーストアにインポート可能なPKCS#12ファイルである必要があることを除き、TDEでは、キーのリカバリ・プロセスに制限を設けていません。この要件は、主要な認証局のキーのリカバリ・メカニズムと同じです。

元の証明書および秘密キーを含むPKCS#12ファイルの取得後は、以前のキーストアと同じ場所に空のキーストアを作成する必要があります。その後、同じユーティリティを使用してPKCS#12ファイルを新しいキーストアにインポートできます。キーストアを保護するために強力なパスワードを選択する必要があります。

ADMINISTER KEY MANAGEMENT文を使用してキーストアを作成して正しい暗号化キーをインポートした後、データベースにログオンして、SQLプロンプトで次のALTER SYSTEM文を実行し、リカバリ・プロセスを完了します。 

ALTER SYSTEM SET ENCRYPTION KEY "cert_id" IDENTIFIED BY keystore_password;

ここでは次のように指定します。

  • cert_idは、マスター暗号化キーとして使用する証明書の証明書IDです。

  • keystore_passwordは、作成するパスワードです。

ノート:

ALTER SYSTEM文を使用して、PKIキー・ペア専用の暗号化キーを再生成する必要があります。この制約はPKI以外の暗号化キーには適用されません。

親トピック: PKI暗号化での透過的データ暗号化の使用

5.7 暗号化済の列のある表への外部ファイルからのデータのロード

SQL*Loaderを使用して、ファイルから暗号化列がある表へのデータ・ロードを実行できます。

SQL*Loaderを使用する場合、ORACLE_LOADERタイプの外部表の列定義にENCRYPT句を含めることはできませんが、ORACLE_DATAPUMPタイプの外部表の列定義にこの句を含めることはできる点に注意してください。

  • タイプORACLE_LOADERの外部表

    タイプORACLE_LOADERの外部表の列定義にENCRYPT句を含めることができない理由は、タイプORACLE_LOADERの外部表の内容が、ユーザー指定の平文の「バッキング・ファイル」からのものである必要があり、このような平文ファイルにはTDE暗号化データを含めることができないためです。

    タイプORACLE_LOADERの外部表の定義にENCRYPT句を使用した場合、外部表内のTDE暗号化された列に問い合せると、問合せは失敗します。これは、TDEが外部データが暗号化されていることを期待しているので、ロード時に自動的に復号化を試行するためです。「バッキング・ファイル」は平文のみを含むため、このアクションは失敗します。

  • タイプORACLE_DATAPUMPの外部表

    タイプORACLE_DATAPUMPの外部表でTDE列暗号化を使用できます。これは、ORACLE_DATAPUMPタイプの外部表では、「バッキング・ファイル」が常にOracle Databaseによって作成される(アンロード操作中)ために、暗号化済データで移入されるためのサポートがあるからです。

親トピック:  透過的 データ暗号化を使用する場合の一般的な考慮事項

5.8 透過的データ暗号化とデータベースのクローズ操作

データベースを閉じる前に、ソフトウェア・キーストアまたは外部キーストアが開いていることを確認する必要があります。

データベースのクローズ操作中は、マスター・キーが必要になる場合があります。データベースのクローズ操作では、ソフトウェア・キーストアまたは外部キーストアは自動的に閉じます。

関連項目

親トピック:  透過的 データ暗号化を使用する場合の一般的な考慮事項