データベース
 Computer >> コンピューター >  >> プログラミング >> データベース

Oracle E-Business Suite R12で透過的データ暗号化(TDE)を実装する方法

本記事では、Oracle® E-Business Suite®(EBS)R12環境において、透過的データ暗号化(TDE:Transparent Data Encryption)による列レベル暗号化を設定する手順について解説します。単一列のテーブルでも複数列のテーブルでも、ユーザーの要件に応じて列レベルの暗号化を設定することが可能です。

はじめに

TDEの列暗号化機能を利用すると、テーブル内の特定の列だけを選択して暗号化できます。暗号化が「透過的」であるため、アプリケーションコードを書き換える必要はなく、既存のコードをそのまま使用できます。「透過的」という言葉には、データベースセッションが暗号化されたデータを問題なく読み取れるという意味も含まれています。

本記事の手順に従うことで、EBS R12環境にTDEの列レベル暗号化を導入できるようになります。

TDE導入による影響

TDEの実装は、アプリケーションの以下の側面に影響を与える可能性があります。

  • パフォーマンス: TDEの実装には一定の制限事項があり、『Advanced Security Guide』に記載されています。導入前に必ず確認してください。また、暗号化する列の選択は慎重に行う必要があります。選択内容によって、DML(Data Manipulation Language)や暗号化列を使用するクエリのパフォーマンスに影響が出るためです。
  • パッチ適用: 利用可能なEBSパッチ、特にTDEで暗号化された列に変更を加えるパッチについては注意が必要です。これには、暗号化列へのインデックス追加などの変更も含まれます。

TDEの制限事項

TDEの列暗号化は、Streamsや論理スタンバイモードのDataGuardなど、Oracle LogMinerベースの技術ではサポートされていません。これらの技術を使用している場合、暗号化された列はレプリケートできません。一方、物理スタンバイモードでDataGuardを使用する場合はTDEがサポートされます。この場合、マスターキーを格納したウォレットをプライマリサーバーから物理スタンバイサーバーへコピーする必要があります。

Oracle E-Business Suite R12で透過的データ暗号化(TDE)を実装する方法

画像出典:https://docs.oracle.com/cd/E11882_01/network.112/e40393/asotrans.htm#ASOAG9567

TDEの実装手順

以下の手順に従ってTDEを実装します。

  1. 暗号化対象の特定: 暗号化が必要な列とテーブルの一覧を作成します。
  2. ウォレットフォルダの作成: 必要な場所にウォレットフォルダを作成します。
    $ mkdir TDEWallet
    
  3. sqlnet.oraの編集: sqlnet.oraまたはsqlnet_ifile.oraに、以下のようなエントリを追加します。
    [oratactp@odbprod1 tactprd_odbprod1]$ cat sqlnet_ifile.ora
    
  4. マスターキーの設定: 以下のコマンドを実行してマスターキーを設定します。これにより、前のステップで指定したウォレットの場所にウォレットファイルが作成されます。
    $ Sqlplus '/as sysdba'
    SQL> ALTER SYSTEM SET ENCRYPTION KEY IDENTIFIED BY "*****";
    System altered.
    
  5. パッチの適用: パッチ7337863が未適用の場合は、ダウンロードして適用します。
  6. aftdeval.sqlの実行: アプリケーション層から$FND_TOP/sqlにあるaftdeval.sqlを、暗号化対象のテーブルや列に対して実行します。
    SQL> @aftdeval.sql IBY IBY_CREDITCARD CCNUMBER E
    
  7. 暗号化コマンドの実行: aftdeval.sqlによって生成されたすべての暗号化コマンドを実行します。
  8. 暗号化の確認: 以下のコマンドで、暗号化された列を確認します。
    SQL> SELECT * FROM DBA_ENCRYPTED_COLUMNS;
    
    OWNER      TABLE_NAME                COLUMN_NAME          ENCRYPTION_ALG       SAL INTEGRITY_AL
    ---------- ------------------------- -------------------- -------------------- --- ------------
    IBY        IBY_CREDITCARD            CCNUMBER             AES 192 bits key     NO SHA-1
    
  9. ウォレットのオープン/クローズ: 以下のコマンドでウォレットを開閉できます。
    SQL> ALTER SYSTEM SET ENCRYPTION WALLET CLOSE IDENTIFIED BY "****";
    SQL> SELECT * FROM v$encryption_wallet;
    
    SQL> ALTER SYSTEM SET ENCRYPTION WALLET OPEN IDENTIFIED BY "****";
    
  10. 自動ログインの設定: 以下のコマンドでウォレットの自動ログインを設定できます。
    $ orapki wallet create -wallet <wallet_location> -auto_login
    

TDE実装時の制約

TDEの実装には、以下の制約が適用されます。

  • 暗号化できるのは一部のデータ型のみです。
  • 3932バイト未満の長さとして定義された列のみ暗号化できます。
  • 外部キーの一部である列や、他のデータベース制約で使用されている列は暗号化できません。
  • 関数ベースインデックスが設定されている列は暗号化できません。
  • インデックスが設定された列を暗号化した場合、その列に対するレンジスキャンではインデックスが使用されなくなり、代わりに全表走査が行われます。
  • パーティション化されたテーブルでパーティションまたはサブパーティションを交換する場合は、すべてのテーブルパーティションが同様に暗号化されている必要があります。現在この条件に該当するテーブルは以下のとおりです。
    • EGO_MTL_SY_ITEMS_EXT_B
    • EGO_MTL_SY_ITEMS_EXT_TL
    • WF_LOCAL_ROLES
    • WF_LOCAL_ROLES_STAGE
    • WF_USER_ROLE_ASSIGNMENTS
    • WF_UR_ASSIGNMENTS_STAGE
    • WF_LOCAL_USER_ROLES
    • WF_LOCAL_USER_ROLES_STAGE
    • WF_LOCAL_ROLES_TL
    • WF_LOCAL_ROLES_TL_STAGE

バックアウト(ロールバック)計画

列の暗号化が不要になった場合は、以下のコマンドをバックアウト計画として実行します。

SQL> ALTER TABLE IBY.IBY_CREDITCARD modify (CCNUMBER decrypt); << 暗号化したすべての列/テーブルに対して繰り返し実行

sqlnet_ifile.ora の ENCRYPTION_WALLET_LOCATION をコメントアウト

上記コマンドの実行後、環境を再起動し、完全なサニティテストを実施してください。

まとめ

列レベルでTDEを実装することにより、クレジットカード番号や人事データなど、列に保存された機密データをユーザーが閲覧することを防げます。また、暗号化後にアプリケーションコードを書き換える必要はなく、既存のコードをそのまま利用でき、データベースセッションも暗号化データを問題なく処理できます。

ご意見やご質問がある場合は、フィードバックタブからお知らせください。データベースサービスの詳細については、ぜひご相談ください。

  1. 透過的データ暗号化(TDE)とは?Oracleデータベースの暗号化機能を徹底解説

    Oracle®は、セキュリティ対策の一環として、Oracle 12cにおいて透過的データ暗号化(Transparent Data Encryption:TDE)機能を導入しました。この機能により、ユーザーは機密データに対して表領域レベルおよび列レベルの暗号化を有効にできるようになります。 TDEの概要 データを暗号化すると、許可されたユーザーやアプリケーションのみがそのデータにアクセスできるようになります。Oracleでは、認証・権限付与・監査のためのツールやプロセスがデータベースに対して提供されていますが、データを格納しているOSのデータファイル自体は保護対象外でした。そこでTDEが重要な役

  2. MongoDBのスケーリング手法:シャーディングインフラの構築ガイド

    前回のブログ記事では、MongoDBのスケーリングが「いつ」必要になるのかについて解説しました。今回は、MongoDBを「どのように」スケーリングするかに焦点を当てていきます。MongoDB 3.0では、WiredTigerがデフォルトのストレージエンジンとして導入されました。これにより、MongoDBはスケーラビリティに関して2つのアプローチを提供できるようになりました。すなわち、垂直スケーリング(スケールアップ)と水平スケーリング(スケールアウト)です。それぞれのアプローチについて詳しく見ていきましょう。垂直スケーリング(スケールアップ)とは垂直スケーリングは、CPUの数や種類、RAM容量