プライマリ・コンテンツに移動
Oracle® Database Advanced Securityガイド
12cリリース1 (12.1)
B71313-13
目次へ移動
目次 		索引へ移動
索引
前
前 		次
次

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

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

内容は次のとおりです。

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

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

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

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

関連項目:

  • 拡張圧縮オプションの詳細は、Oracle Databaseバックアップおよびリカバリ・ユーザーズ・ガイドを参照してください。

  • SecureFiles LOB記憶域の詳細は、『Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイド』を参照

  • SecureFiles圧縮の詳細は、Oracle Database SecureFilesおよびラージ・オブジェクト開発者ガイドを参照してください。

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

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

内容は次のとおりです。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

透過的データ暗号化のパフォーマンスは変わる場合があります。記憶域にはオーバーヘッドはありませんが、TDE列暗号化に関係する記憶域のオーバーヘッドは多少あります。

内容は次のとおりです。

関連項目:

透過的データ暗号化に関するパフォーマンスの質問

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

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

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

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

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

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

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

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

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

注意:

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

関連項目:

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

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

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

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

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

関連項目:

外部表への暗号化列の作成

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

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

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

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

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

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

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

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

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

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

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

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

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];

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

使用不可

 
ADMINISTER KEY MANAGEMENT SET ENCRYPTION
KEY IDENTIFIED BY
software_keystore_password 
REVERSE MIGRATE USING "user_id:password"
[WITH BACKUP [USING 'backup_identifier']];

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

 
ALTER SYSTEM SET ENCRYPTION KEY
IDENTIFIED BY
"user_id:password" MIGRATE
USING wallet_password;
 
ADMINISTER KEY MANAGEMENT SET ENCRYPTION
KEY IDENTIFIED BY "user_id:password"
MIGRATE USING software_keystore_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']];

ハードウェア・キーストアの場合、キーストアを閉じてハードウェア・セキュリティ・モジュール・インタフェースで変更してから、再びキーストアを開きます。

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

使用不可

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

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

使用不可

 
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つのソフトウェア・キーストアから別の既存のキーストアへのマージ

使用不可

 
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 "user_id: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動的ビューが更新されます。

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

使用不可

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

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

使用不可

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

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

使用不可

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

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

使用不可

 
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)]

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

使用不可

 
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のシークレットの格納

使用不可

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

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 "user_id:password" 
[WITH BACKUP [USING 'backup_identifier'];

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

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

内容は次のとおりです。

注意:

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

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

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

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

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

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

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

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

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

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以外の暗号化鍵には適用されません。

前
前 		次
次
目次へ移動
目次 		索引へ移動
索引