クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス

Transcription

1 Oracle ホワイト ペーパー 2014 年 3 月 クレジットカード業界のデータ セキュリティ標準への持続可能なコンプライアンス

2 はじめに... 2 Oracle 製品とPCIソリューションのマッピング... 3 PCIデータ保護の課題 危険にさらされているカード会員データ 暗号化の発達 Oracle Databaseのリダクションおよび暗号化ソリューション 稼働中のデータの保護 バックアップ データの保護 マスクされたデータの使用 キー管理の解決 暗号化の弱点 キー管理に対するPCI 要件 Oracleのキー管理 カード会員データの保護の構築 強力な認証 監視 追跡 および監査 セキュアな構成の維持 特権アカウントの管理 内部の敵 PCIがリスクを認識 Oracleによる特権アカウントの管理 ID 管理によるコンプライアンスの実現とビジネスの強化 セキュアで柔軟なIDおよびアクセス管理 IDおよびアクセス管理に対するPCI 要件 ID 管理の課題 オラクルのID 管理ソリューション 結論 参考資料... 31

3 はじめに 多くの組織は クレジットカード業界データ セキュリティ標準 (PCI DSS) の準拠に対して頭を悩まし続けています これは クレジットカード業界で義務付けられているカード会員のデータ保護と不正防止を目的としたものです PIC DSSは大手 5 社のクレジットカード会社によって 各社のプログラムを調整して1 組の要件にまとめるために策定されました それ以来 PCI Security Standards Council(PCI SSC) は複数回の更新を発表しており 最新のバージョン3は2014 年 1 月に有効になっています 標準は12の要件とサポート ガイダンスからなり ほとんどの政府や業界のセキュリティ指令よりも慣例に基づいているものの これに準拠するには 多くの場合 本来あるべきレベルよりもはるかに多くのリソースと高いコストが必要になり エラーも多く発生します 担当者などが手動でログ データを収集 分析し レポートを集計し セキュリティ管理とポリシーを維持 検証する労力について考えると 組織の階層レベルによっては 平均コストが1 年あたり数十万ドルに達する場合もあるでしょう アクセス制御 データ保護 構成管理のポリシーは実装が難しく 実際に維持 管理 および適用するのはさらに困難です コンプライアンスとセキュリティに関する手続きは時間がかかるか柔軟性に欠けることが多く 現在のダイナミックなビジネス環境で変化するビジネス要件に対応できていません 手動制御 または不完全に実装され管理される制御はコストがかかりエラーも発生しやすく 実際には セキュリティを大幅に改善することなく 効率的なビジネスの妨げになっています 結果として 個人 ときには部門でさえ 業務を " 成し遂げる " ためにポリシーを避けて通ることがあります 驚くまでもなく 多くのデータ侵害は 技術的にはPCI DSSに準拠している組織で起こっています 組織は PCIで義務付けられた技術的な要件を満たし 標準の策定目的であるカード会員のデータ保護レベルを達成する 効率的で繰り返しと持続が可能なセキュリティ プログラムを実現できます このホワイト ペーパーでは 要件の中核の大半を構成する重要だが問題のある領域を中心に PCI コンプライアンス プログラムの要点について説明します カード会員データを不正使用から保護する 特権ユーザーとデータ アクセスに強力な制御を適用する 一元化され自動化されたロールベースのアクセス制御 認可 および認証を実装する システムとデータベースの監査を提供し データベース アクティビティを監視するデータ セキュリティ ID 管理 構成管理製品からなるオラクルの包括的ポートフォリオは 徹底的なセキュリティ保護を提供することで 12の要件のうちの6つに対応します 残りの要件 ( ) はそれぞれ アンチウイルスとネットワーク ファイアウォールの導入 パブリック ネットワークを介したカード会員データの暗号化送信 物理的なセキュリティ管理 テスト 管理者用ポリシーの維持に関係しています 2

4 Oracle 製品と PCI ソリューションのマッピング 次の表に 顧客のコンプライアンス要件への対応に役立つ データ セキュリティ ID 管理 構成管理の各ソリューションについてのオラクルのポートフォリオとPCI DSSの各セクションへのマッピングをまとめます 章 PCI 3.0 の要件適合するオラクルの機能 セキュアなネットワークおよびシステムの構築と維持 2 システム パスワードやその他のセキュリティ パラメータに ベンダー提供のデフォルト値を使用しないこと 悪意のある人物 ( 企業の内外を問わず ) は ベンダー提供のデフォルト パスワードやその他のデフォルト設定を使用して システムに侵入する場合があります これらのパスワードや設定はハッカー コミュニティでよく知られており 公開情報を通じて容易に特定できます 2.1 システムをネットワーク上に導入する前に ベンダー提供のデフォルト値を必ず変更し 不要なデフォルト アカウントは削除または無効化します これはすべてのデフォルト パスワードにあてはまります 例としては オペレーティング システムやセキュリティ サービスを提供するソフトウェア アプリケーション アカウントとシステム アカウント POS 端末 Simple Network Management Protocol(SNMP) コミュニティストリングなどが含まれますが この限りではありません Oracleデータベースのインストール中に デフォルト アカウントはロックされ デフォルト パスワードは失効します 管理者アカウントのパスワードは インストール中に入力するようプロンプトが表示されます Oracle Access Managerには PCI DSS 3.0の複雑さ要件を満たすポリシーが設定されたセルフサービス式のパスワード リセット機能が含まれています 2.2 すべてのシステム コンポーネントについて設定基準を作成します これらの基準は すべての既知のセキュリティ脆弱性に対応しており 業界で認知されたシステム強化基準に準拠したものでなければなりません 業界で認められたシステム強化基準の提供元には次が含まれますが この限りではありません Oracle Enterprise Managerは オラクル 顧客ポリシー 業界で広く受け入れられたプラクティスに基づく構成確認機能を提供します Enterprise ManagerはOracle Databaseの検出 プロビジョニング パッチ適用機能を提供します Center for Internet Security(CIS) International Organization for Standardization(ISO) SysAdmin Audit Network Security(SANS)Institute National Institute of Standards Technology(NIST) 誤用を防止するように システムのセキュリティ パラメータを設定します Oracle Databaseのセキュリティ ガイドラインに従います Oracle Configuration Managementを使用して監視します Oracle Audit Vault and Database Firewallは Windowsおよび Linuxプラットフォームに加えて Oracle Microsoft SQL Server IBM DB2 for LUW SAP Sybase ASE Oracle MySQLの各データベースから取得した監査データも統合します Oracle Audit Vault and Database Firewallは監査データについてレポートおよびアラートを発行可能です Oracle Database Vault の職務の分離機能により Oracle Databaseで不正な管理アクションが実行されることを防止できます スクリプト ドライバ 機能 サブシステム ファイル システム 不要なWebサーバーをはじめとする すべての不要な機能を削除します Oracle Databaseのカスタム インストールでは 特定のコンポーネントのインストールや削除が可能です 3

5 2.3 強力な暗号化を使用して コンソール以外からの管理用アクセスはすべて暗号化します Webベースの管理やその他のコンソール以外からの管理アクセスについては SSH VPN SSL/TLSなどのテクノロジーを使用してください Oracle Databaseが提供するネットワーク暗号化 (SSL/TLSおよびネイティブ ) では 中間層とデータベース間 クライアントとデータベース間 複数のデータベース間でのSQL*Net 経由の通信がすべて暗号化されます さらに Oracle Enterprise Manager などの管理ツールでは 管理用通信を保護するために 使用制限付きのSSLライセンスが提供されています 2.6 共有ホスティング プロバイダは それぞれの事業体のホスト環境およびカード会員データを保護しなければなりません これらのプロバイダは 付録 A" 共有ホスティング プロバイダ向けのPCI DSS 追加要件 " に詳述された要件を満たす必要があります 付録 A を参照してください カード会員データの保護 3 保存されるカード会員データの保護 暗号化 切捨て マスキング ハッシングなどの保護方法は カード会員データを保護するための重要な要素です たとえ侵入者がセキュリティ制御を巧みに逃れて 暗号化されたデータにアクセスできたとしても 正しい暗号化キーがなければ データを読み取り 使用することはできません 保管したデータを保護するその他の効果的な方法は 潜在的なリスク軽減の機会として考える必要があります たとえば リスクを最小化する方法には 必要でない限りカード会員データを保存しない プライマリ アカウント番号の全桁が必要でない場合はデータの端を切り捨てる エンドユーザーのメッセージング テクノロジー ( 電子メールやインスタント メッセージングなど ) を使用して 保護されていないプライマリ アカウント番号を送信しないなどが挙げられます " 強力な暗号化 " およびその他のPCI DSS 用語の定義については PCI DSS Glossary of Terms, Abbreviations, and Acronyms を参照してください 3.3 プライマリ アカウント番号は全体を表示させないようにして ( 最大でも 最初の6 桁と最後の4 桁のみを表示 ) 業務において正当な必要性のある担当者のみがプライマリ アカウント番号全体を参照できるようにします 注 : この要件は カード会員データの表示について さらに厳しい要件が適用されている場合 ( 例 :POSレシートに対する法的要件やクレジットカード ブランドの要件など ) に その要件に取って代わるものではありません アプリケーションでVirtual Private Database(VPD) の列関連ポリシーを利用して 番号全体を非表示にできます Oracle Advanced SecurityのData Redactionは アプリケーション内に表示されるデータを一貫してマスクします Oracle Data Masking and SubSettingは 非本番環境でテストや QAクオリティアシュアランスを目的として使用される本番データを保護します Oracle Label Securityが提供するセキュリティ制御を使用すると 誰がプライマリ アカウント番号にアクセスできるかを決定できます Oracle Database Vaultのレルムを使用して 特権ユーザーによるアプリケーション データへのアクセスを防止できます 4

6 3.4 プライマリ アカウント番号は どこに保管されていても ( 携帯デジタル メディア バックアップ メディア ログなど ) 次のいずれかの手段を使用して判読不可能な状態にしておきます 強力な暗号化技術に基づくワンウェイ ハッシュ ( プライマリ アカウント番号全体をハッシュする ) 切捨て ( ハッシングを使用してプライマリ アカウント番号の切捨て部分を置換することはできない ) インデックス トークンおよびPAD(PADはセキュアに保存 ) 関連するキー管理のプロセスと手順による強力な暗号化手法注 : 悪意のある人物が切り捨てられた番号とハッシングされた番号の両方にアクセスできる場合 元のプライマリ アカウント番号を復元することは比較的簡単でしょう 同じプライマリ アカウント番号に対してハッシングされた番号と切り捨てられた番号が同じ事業体の環境内に存在する場合 ハッシングされた番号と切り捨てられた番号を関係付けて元の番号を復元できないようにするため 追加の制御を適用する必要があります Oracle Advanced Securityの Transparent Data Encryption(TDE) 列暗号化 表領域暗号化を使用すると データベース内のプライマリ アカウント番号を透過的に暗号化してストレージ メディアにバックアップできます 注 :Advanced Securityは ディスクの暗号化に対して別の論理的なアクセスを義務付ける要件 3.4.1の影響を受けません Oracle Advanced SecurityのTDEにはキー管理が組み込まれています 暗号化されたデータは データ ファイル REDOログ バックアップ内でも暗号化されたままです Oracle RMANをOracle Advanced Securityと併用すると ディスクへのバックアップ時にディスク バックアップ全体を暗号化 ( および圧縮 ) できます Oracle Data PumpをOracle Advanced Securityと併用すると ソース データベースのマスター暗号化キー または受信者と安全に共有できるパスフレーズのいずれかを使用して データベースのエクスポート ファイル全体を暗号化 ( および圧縮 ) できます Oracle Secure Backupは テープ ストレージに直接バックアップおよび暗号化するソリューションを提供しています サポートされる暗号化アルゴリズムは 256ビット 192ビット または128ビットのキー長を持つAESと3DES168です 3.5 保存されたカード会員データを漏洩や誤用から保護するために使用されたキーの保護手順をドキュメント化し 実装します 注 : この要件は 保存されたカード会員データの暗号化に使用されたキーと データ暗号化キーを保護するために使用されたキー暗号化キーに適用されます このようなキー暗号化キーは 少なくともデータ暗号化キーと同じ強度を持つ必要があります Oracle Advanced Security TDEの表キーおよび表領域キーは 別のマスター キーを使用して暗号化された状態でデータベースに保管されます このマスター キーは オペレーティング システム上のPKCS#12ファイルであるOracle Wallet またはハードウェア セキュリティ モジュール (HSM) に保存されています Oracle Walletは ウォレット パスワード (PKCS#5に基づく) を使用して暗号化されています データベース内からウォレットを開くには 'alter system' 権限が必要です Oracle Database Vaultのコマンド ルールを利用すると さらに 誰が いつ どこから 'alter system' コマンドを実行できるかを制限できます 暗号化キーへのアクセスは 必要最小限の管理者に制限します Oracleを使用する場合 個人がマスター暗号化キーにアクセスする必要はありません DBAやデータベース セキュリティ管理者 (DSA) などの指定された担当者は ウォレット パスワードまたは HSMの認証文字列を把握し 'alter system' 権限を持っていれば ウォレットまたはHSMを開くことができます そうすることで データベースでマスター暗号化キーを使用できます Oracle Database Vaultのコマンド ルールを実装すると 誰が いつ どこから 'alter system' コマンドを実行できるかを制限できます 5

7 3.5.2 カード会員データの暗号化 / 復号化に使用する秘密鍵は 常に次のいずれかの形式で保存します 少なくともデータ暗号化キーと同じ強度を持つ キー暗号化キーで暗号化されており このキー暗号化キーはデータ暗号化キーとは別の場所に保管されている マスター暗号化キーは 各データベースに1つだけ存在します 一元的にマスター暗号化キーを管理するため このキーをOracle WalletまたはHSMデバイスに保管します セキュアな暗号化デバイス ( ハードウェア セキュリティ モジュール (HSM) やPTS 認可の加盟店端末装置など ) 少なくとも2つの全長キー要素または鍵共有は業界で認められた方式に従う 注 : 公開鍵を上記の形式で保管する必要はありません 強力な暗号化キーの生成 Oracle Advanced Security TDEは業界で定評のあるライブラリを利用して 強力な暗号化キーを生成します ハードウェア セキュリティ モジュール (HSM) を使用する場合 キーの生成と保管を含むマスター暗号化キーの管理はHSMによって行われます セキュアな暗号化キーの配布 Oracle Advanced Securityは 広く知られたDiffie-Hellman 鍵交換 アルゴリズムを使用してセキュアなキーを配布します セキュアな暗号化キーの保管 Oracle Advanced Security TDEの列キーおよび表領域キーは Oracle WalletまたはHSMデバイスに保存されたマスター キーを 使用して暗号化された状態で データベースに保管されます 関連するアプリケーション ベンダーまたはキー所有者によって定義された方法で 業界のベスト プラクティスとガイドライン ( 例 :NIST Special Publication など ) に従って 暗号有効期間の期限に達した ( 例 : 規定された期間が経過した後や 特定のキーによって一定量の暗号文が生成された後 ) キーを暗号化キーが付け替えます Oracle Advanced Security TDEの列暗号化は マスター暗号化キーや表キーを個別にre-keyingする機能を提供しています Oracle Database 11g Release 2 以降では TDE 表領域暗号化のマスター暗号化キーも同様にre-keyingできます PCIコンプライアンスでは 多くの場合 マスター暗号化キーのre-keying( ローテーション ) で十分です 脆弱性管理プログラムの整備 6 セキュアなシステムとアプリケーションを開発し 保守すること 悪意を持った人々は セキュリティの脆弱性を利用して システムへの特権アクセスを手に入れます このような脆弱性の多くは ベンダー提供のセキュリティ パッチにより修正されます セキュリティ パッチは システムを管理する事業体がインストールする必要があります 悪意ある人々や悪意あるソフトウェアによるカード会員データの不正使用および侵害を阻止するため すべてのシステムにすべての適切なソフトウェア パッチをインストールする必要があります 注 : 適切なソフトウェア パッチとは そのパッチが既存のセキュリティ設定と矛盾しないことが十分に確認され テストされたパッチを指します 自社開発アプリケーションの場合 標準のシステム開発プロセスとセキュアなコーディング技術を使用することで 多くの脆弱性を回避できます 6

8 6.1 セキュリティ脆弱性に関する外部の信頼できる情報源を使用して セキュリティ脆弱性を特定するプロセスを確立し 新たに検出したセキュリティ脆弱性にリスク ランキング ( 例 :" 高 " " 中 " " 低 ") を割り当てます注 : リスク ランキングは 業界のベスト プラクティスと潜在的な影響を考慮して決定する必要があります オラクルはCritical Patch Updates(CPU) でリリースされるバグ修正の重大度を評価する際 Common Vulnerability Scoring System(CVSS) に従っています stem html Oracle Critical Patch Updates Security Alerts Third Party Bulletinに関するRSSフィードに登録してください すべてのシステム コンポーネントとソフトウェアを既知の脆弱性から保護するため ベンダーが提供するすべてのセキュリティ パッチをインストールします 重要なセキュリティ パッチは リリース後 1カ月以内にインストールします Oracleデータベースを使用する場合 Oracle Enterprise Manager Grid Controlを使用して自動化できます 顧客のポリシーとプロセスの問題 オラクルは四半期ごとに Critical Patch Updatesを提供しており ほとんどの場合 顧客は 30 日以内にこれを実装できます 開発 / テスト環境を本番環境から切り離し アクセス 制御の分離を適用します Oracle Database Enterprise EditionのEnterprise User Security 機能をOracle Identity Managementと併用すると データベース ユーザーとその認可を1カ所で集中管理できます Oracle Identity Governance Suiteに含まれるOracle Privileged Account Managerは 権限の分離を可能にし 特権カウントに対するセルフサービス式のリクエストを管理し パスワードの使用に関する監査とレポート作成機能を提供します Oracle Database Vaultを使用すると Oracleデータベース内の本番データへのDBAによるアクセスを保護できます テストまたは開発環境では 本番データ ( 実際のプライマリ アカウント番号 ) は使用しません Oracle Data Masking and SubSettingはテスト環境や開発環境向けに クレジットカード番号やその他の機密情報を識別不能にします セキュリティ パッチとソフトウェア変更の実装に対する変更管理手順には 次が含まれている必要があります 影響のドキュメント化 権限を持つ関係者によるドキュメント化された変更の承認 該当する変更がシステム セキュリティに悪影響を与えないことを検証するための機能テスト バック アウト手順 Oracle Change Managementを利用すると データベース変更管理手順を自動化できます また Oracle BPEL Process Manager を使用して 変更管理や一般的なセキュリティ手順のプロセス管理を実行できます Change Managementは 変更を実装する前に変更の依存関係を分析し 影響レポートを生成します また 変更を取り消すための情報を提供します Oracle Databaseに含まれる時間に関連する (Temporal) データベース機能は SQL:2011 規格に準拠したトランザクション時間と有効時間をサポートしています フラッシュバック データ アーカイブの履歴表は改ざんを防止する設計になっているため 重要データの変更を含む 変更不可能で明確な履歴を監査担当者に提供できます 7

9 6.5 ソフトウェア開発プロセスにおける一般的なコーディング上の脆弱性には 次のとおりに対処します 一般的なコーディング上の脆弱性の回避を含むセキュアなコーディング手法を開発者に教育し 機密データがメモリ内で処理される方法の理解を促します セキュアなコーディングのガイドラインに基づいて アプリケーションを開発します 注 :6.5.1から6.5.10までに記載する脆弱性は 本バージョンの PCI DSSの公開時点で最新の業界ベスト プラクティスに従っています ただし 脆弱性管理に関する業界のベスト プラクティス (OWASPガイド SANS CWE Top 25 CERT Secure Codingなど ) は更新されるため これらの要件に対して最新のベスト プラクティスを使用する必要があります Oracle Audit Vault and Database Firewallは OracleおよびOracle 以外のデータベースに対して インバウンドSQL 文にSQLインジェクションが含まれていないかどうかを調査します Oracle Advanced Security TDEのマスター暗号化キーは暗号化ファイル (Oracle Wallet) に保管されており Oracle Walletは PKCS#5 標準に基づいて パスフレーズ ( ウォレットの ' パスワード ') によって暗号化されています TDEマスター暗号化キーを HSMに保管すると さらに高い確実性 (FIPS Level 3の検証 ) が得られます Oracle Database Standard EditionおよびEnterprise Editionでは SSL/TLSを使用して Oracleデータベースに対するネットワーク接続を暗号化できます インジェクションを利用した不正 特にSQLインジェクション また OSコマンド インジェクションやLDAPインジェクション Xpathインジェクション およびその他のインジェクションによる不正も考慮に入れます セキュリティで保護されていない暗号化ストレージ セキュリティで保護されていない通信 8

10 強固なアクセス制御手法の導入 7 カード会員データへのアクセスを業務上の必要範囲内に制限すること 権限を与えられた担当者のみが重要なデータにアクセスできるように システムおよびプロセスを利用して 職責に応じたアクセスと必知事項に基づくアクセスに制限する必要があります " 必要な範囲 " とは 職務の実行に必要な最小限のデータと権限に対してのみ アクセス権が付与される状態を指します 7.1 システム コンポーネントとカード会員データへのアクセスを 業務上必要な担当者に限定します 次を含むアクセス要件をロールごとに定義します 各ロールが職務を遂行するためにアクセスを必要とするシステム コンポーネントとデータ リソース リソースへのアクセスに必要な権限レベル ( ユーザー 管理者など ) 特権ユーザー IDに付与されるアクセスを 職責を果たすために必要な最小限の権限に制限します Oracle Database Vault: レルムは 特権ユーザーやDBAによるアプリケーション データおよびカード会員データへのアクセスを制限します 変数を使用すると 動的にアクセス権を決定できます ファクタとコマンド ルールは アプリケーション データ およびデータベースへのアクセスに対する厳密な制御を適用します 職務の分離機能は Oracle Databaseで不正な管理アクションが実行されることを防止します Oracle Label Securityは必要な範囲や最小権限の要件に基づく追加のセキュリティ属性を提供します Oracle Virtual Private Databaseは基本的な実行時のマスキング機能を提供します Oracle Data Redactionは 組織と規制に関するポリシーと要求者の権限の組み合わせに基づいて 機密性の高いのアプリケーション データ フィールドを削除またはマスクします Oracle Databaseのオブジェクト権限とデータベース ロールにより 基本的なセキュリティが提供されます 個々の担当者の職種と職務に基づいてアクセスを割り当てます Oracle Identity Governance Suiteは 許可されたコンピューティング リソースとアプリケーション リソースおよびデータにのみエンタープライズ ユーザー プロビジョニングを提供します Oracle Identity Analyticsは ジョブと機能の詳細な定義を提供するためのロールと短期の割当てを定義します 9

11 7.2 複数のユーザーを持つシステム コンポーネントの場合 ユーザーの必知事項に基づいてアクセスを制限し 個別に許可されない限り " すべて拒否 " に設定するアクセス制御システムを確立します このアクセス制御システムには以下が含まれる必要があります すべてのシステム コンポーネントを対象に含めること 職種と職務権限に基づいて担当者に権限が割り当てられていること Oracle Database Vaultのレルムを利用すると 特権ユーザーや DBAによるアプリケーション データおよびカード会員データへのアクセスを制限できます Oracle Database Vaultのファクタとコマンド ルールは アプリケーション データ およびデータベースへのアクセスに対する厳密な制御を実現します Oracle Database Vault の職務の分離機能により Oracle Databaseで不正な管理アクションが実行されることを防止できます Oracle Databaseの必須レルム制御を利用すると アプリケーション オブジェクトへのアクセス ( オブジェクト所有者などの直接付与されるオブジェクト アクセス権限を含む ) を制限できます Oracle Label Securityは 必要な範囲を決定する追加のセキュリティ属性を提供します デフォルトは " すべて拒否 " に設定すること Oracle Virtual Private Databaseは基本的な実行時のマスキング機能を提供します Oracle Data Redactionは 組織と規制に関するポリシーと要求者の権限の組み合わせに基づいて 機密性の高いアプリケーション データ フィールドを削除またはマスクします Oracle Databaseのオブジェクト権限とデータベース ロールにより 基本的なセキュリティが提供されます Oracle Access Management Suiteは 一元化されたアクセス制御 認可 および認証を提供します Oracle Identity Governance Suiteは ロール 職務 部門 場所 その他の変数に基づき 許可されたコンピューティング リソースとアプリケーション リソースおよびデータに対してのみエンタープライズ ユーザー プロビジョニングを提供します この機能はHR(HCM) システムから自動的に開始できます Oracle Identity Analyticsは ジョブと機能の詳細な定義を提供するためのロールと短期の割当てを定義します 8 システム コンポーネントに対するアクセスの識別と認証 10

12 アクセスを持つユーザーごとに一意の識別子 (ID) を割り当てることで 各ユーザーが自分の行動に独自の責任を負うようにします このような責任が課されている場合 重要なデータやシステムに対する操作が 既知の認可ユーザーおよびプロセスによって実行されていることを確認できるだけでなく 操作からユーザーにさかのぼって追跡できるようになります パスワードの有効性はおもに認証システムの設計と実装によって決まります 特に 攻撃者がパスワードを試行する頻度や 送信中 保存中にエントリ ポイントでユーザー パスワードを保護するセキュリティ手法によって異なります 注 : これらの要件は 管理機能を持つすべてのアカウント (POSアカウントを含む) と カード会員データの参照とアクセス またはカード会員データを含むシステムへのアクセスに使用されるすべてのアカウントに当てはまります これには ベンダーやその他の第三者 ( サポートや保守用 ) によって使用されるアカウントも含まれます ただし 1 度に1つのカード番号のみにアクセスして単一トランザクションを実行するPOS 支払いアプリケーション内のユーザー アカウント ( レジ係のアカウントなど ) に対して 要件 から から8.1.8は適用されません 11

13 8.1 すべてのシステム コンポーネント上で 非消費者ユーザーと管理者に対して適切なユーザー ID 管理を徹底するためのポリシーと手順を定義し 実装します システム コンポーネントまたはカード会員データへのアクセスを許可する前に すべてのユーザーに一意のIDを割り当てます ユーザー ID 証明書 その他の識別子オブジェクトの追加 削除 および変更を管理します 離職したユーザーのアクセスはただちに取り消します 少なくとも90 日ごとに 休眠状態にあるユーザー アカウントを削除または無効にします リモート アクセスを介してシステム コンポーネントのアクセス サポート 保守を行うためにベンダーによって使用されるIDを 次のように管理します Oracle Databaseの認証機能は 専用ユーザー アカウントと Kerberosを含む強力な認証機能をサポートします Oracle Identity Governance Suiteは自動ワークフローと集中リポジトリを使用したエンタープライズ ユーザー プロビジョニングを提供します ユーザーがアクティブでなくなると 自動的にプロビジョニングが解除されます 特権アクセスはワンタイム パスワード (OTP) を使用した例外ベースで管理する必要があります 特権アクセスやサポート アクセスを詳細に監視することで 担当者が許可されたアクティビティのみを実行するように徹底できます Oracle Access Management Suiteは 一元化されたアプリケーション レイヤーのアクセス制御 認可 および認証を提供します Oracle Identity Governance Suiteに含まれるOracle Privileged Account Managerは パスワードの生成 パスワードのプロビジョニング パスワードへのアクセス管理を行うセキュアなパスワード管理ソリューションです アクセス試行が繰り返された場合はアカウントのロックアウトを起動でき 試行回数と修正プロセスは設定が可能です 必要な期間のみ有効にし 使用しないときは無効にします 使用中はIDを監視します ユーザー IDをロックアウトすることにより 連続したアクセス試行を6 回以内に制限します ロックアウト時間は最低で30 分間 または管理者がユーザー IDを有効にするまでとします セッションのアイドル時間が15 分を超えた場合 ターミナル セッションを再びアクティブ化するには ユーザーが再認証を行う必要があります 8.2 一意のIDの割当てに加えて 次の方法のうち少なくとも1つを導入してすべてのユーザーを認証することで すべてのシステム コンポーネント上での非消費者ユーザーと管理者に対する適切なユーザー認証管理を実現します パスワードやパスフレーズなどのユーザーが知っている要素 トークン デバイスやスマート カードなどのユーザーが持っている要素 Oracle Databaseは2つの要素による認証を提供します Oracle Access Management Suiteは 強力な認証 ( トークン スマート カード X.509 証明書 フォーム ) とパスワードをサポートします さまざまなレベルのセキュリティ要件に対応する認証の階層を提供します Oracle Adaptive Access Managerは ソフトウェア形式で2つの要素による認証を提供します また リアルタイム リスク分析を実行し さらなる認証が必要かどうかを判断します バイオメトリックなどのユーザー自身に関する要素 12

14 8.1.2 送信中やすべてのシステム コンポーネントに保管中のあらゆる認証資格証明 ( パスワードやパスフレーズなど ) は 強力な暗号化を使用して判読不可能な状態にします Oracle Databaseはデータベースのユーザー IDとパスワードを組み合わせたハッシュを作成し このハッシュは認証プロセス内でレコード ハッシュと比較されます Oracle Privileged Account Managerによって管理されるパスワードとメタデータ情報は Oracleデータベース内に暗号化された状態で永続化されます Oracle Databaseは Oracle Advanced SecurityとTransparent Data Encryptionを使用して暗号化できます Oracle Databaseはネットワーク暗号化 (SSL/TLS) と強力な認証を提供します パスワード / パスフレーズは次の条件を満たす必要があります 最小の長さは 少なくとも7 文字以上にします 数字と英字の両方を含みます 別の方法として パスワード / パスフレーズが 上記で指定したパラメータと少なくとも同等の強度および複雑さを持つ必要があります Oracle Access Managerには PCI DSS 3.0の複雑さ要件を満たすポリシーが設定されたセルフサービス式のパスワード リセット機能が含まれています Oracle Databaseパスワードの複雑さのチェック : cd/b28359_01/server.111/b28337/tdpsg_user_accounts.htm#tdpsg ユーザー パスワード / パスフレーズは 少なくとも 90 日ごとに変更します Oracle Database のプロファイル Oracle Identity Manager Oracle Access Manager 直近 4 回で使用されたパスワード / パスフレーズは 新しいパスワード / パスフレーズとして使用できないようにします Oracle Database のプロファイル Oracle Identity Manager Oracle Access Manager 8.3 担当者 ( ユーザーと管理者を含む ) とすべての第三者によるネットワーク外部からのリモート ネットワーク アクセス ( サポートまたは保守用のベンダー アクセスを含む ) には 2つの要素による認証を実装します 注 :2つの要素による認証では 3つの認証方式 ( 認証方式の説明については要件 8.2を参照 ) のうちの2つを使用して認証を行う必要があります 1つの要素を2 回使用する ( 例 :2つの異なるパスワードの使用 ) ことは 2つの要素による認証とは見なされません 2 つの要素による認証テクノロジーの例には Remote Authentication and Dial-In Service(RADIUS) またはTerminal Access Controller Access Control System(TACACS) とトークンの組合せに加えて 2つの要素による認証を実現するその他のテクノロジーが含まれます Oracle Advanced Securityは Kerberos PKI およびRADIUSを利用した強力な認証機能を提供します Oracle Access Management Suiteは 強力な認証 ( トークン スマート カード X.509 証明書 フォーム ) とパスワードをサポートします さまざまなレベルのセキュリティ要件に対応する認証の階層を提供します Oracle Adaptive Access Managerは ソフトウェア形式で2つの要素による認証を提供します また リアルタイム リスク分析を実行し さらなる認証が必要かどうかを判断します 8.5 グループ 共有 汎用のID パスワード またはその他の認証方式は 以下の理由のため使用しないでください 汎用ユーザー IDは無効化されているか 削除されている システム管理やその他の重要な職務を実行するための共有ユーザー IDは存在しない ( 顧客の内部ポリシー ) Oracle Database 専用のユーザー アカウント Oracle Databaseのエンタープライズ ユーザー セキュリティ Oracle Databaseのプロキシ認証 Oracle Identity Governance Suite システム コンポーネントを管理するために 共有ユーザー ID や汎用ユーザー IDは使用しません 13

15 8.7 カード会員データを保管しているデータベースへのアクセス ( アプリケーション 管理者 その他すべてのユーザーによるアクセスを含む ) は次のとおりに制限します データベースに対するすべてのユーザー アクセスとユーザー問合せ ユーザー アクションは プログラム的な手法を介して実施します Oracle Databaseの認証機能 Oracle Advanced SecurityのKerberos PKI RADIUSサポート Oracle Identity Governance Suite Oracle Database Valid Node Checking データベース管理者のみが データベースへの直接アクセスまたは問合せを実行できます データベース アプリケーションのアプリケーションIDを使用できるのはアプリケーションのみです ( 個人ユーザーやその他の非アプリケーション プロセスは使用できません ) 定期的なネットワークの監視およびテスト 10 ネットワーク リソースおよびカード会員データへのすべてのアクセスを追跡し 監視すること データの検出を阻止したり データ侵害の影響を最小化したりするために ロギング メカニズムとユーザー アクティビティの追跡機能は重要です すべての環境にログが存在することにより 何らかの不都合が起きても詳しい追跡 アラート通知 分析が実行できます システム アクティビティ ログがない場合 セキュリティ侵害の原因解明が不可能になるか または非常に難しくなります 10.1 監査証跡を実装して システム コンポーネントに対するすべてのアクセスを各個人ユーザーに関連付けます ( 顧客の内部ポリシー ) 専用のDBAアカウントをデータベースに作成します Oracle Audit Vault and Database Firewallはデータベースとシステムの監査データを収集し 企業レポートとアラート用に一元化します Oracle Database Vault の監査証跡はOracle Audit Vault and Database Firewall 内で収集できます Oracle Database Fine Grained Auditing(Oracle FGA) では 監査レコードを生成するために必要となる条件とともに 監査ポリシーをアプリケーション表の列に関連付けることができます Oracle Audit Vault and Database Firewall 内で監査証跡を収集してレポートを作成できます Oracle Database Conditional Auditingはデータベース セッションのコンテキストに基づいてレコードを作成することで 厳選された効果的な監査を提供します ポリシーから外れた接続は全面的に監査され データは生成されません Oracle Identity Governance Suiteはエンタープライズ ユーザー プロビジョニング機能を提供し ユーザーのアクセス レベルと認可レベルを決定するロールの定義を支援します Oracle Access Management Suiteは システム コンポーネントに対するアクセス 認可 および認証の権限を制御します 10.2 次のイベントを復元できるように すべてのシステム コンポーネントに対して自動監査証跡を導入します ( 個別の対応については以下を参照 ) 14

16 カード会員データに対する 個人ユーザーによるすべてのアクセス Oracle Database Auditing カード会員データに対するOracle Databaseの監査機能とOracle Databaseのファイングレイン監査 (FGA) Oracle Audit Vault and Database Firewallのレポートおよびアラート Oracle Database Conditional Auditingは選ばれたイベントに焦点を合わせることで 監査に関する負荷を軽減します Oracle Identity Governance Suite Oracle Access Management Suite 監査レポート root 権限または管理者権限を持つ個人が行ったすべての操作 データベースに専用のDBAアカウントを作成します 任意でプロキシ認証を使用すると DBA 権限を持つアカウントの数を制限しながら監査を実現できます Oracle Database Vaultのレルムと職務の分離機能により データベース管理をより厳格に制御できます Oracle Database Vaultのレルム レポート Oracle Audit Vault and Database Firewallの監査データ統合により エンタープライズ レポートとエンタープライズ アラートが提供されます Oracle Identity Governance Suite Oracle Access Management Suite 監査レポート Oracle Identity Analytics すべての監査証跡へのアクセスデータベースの監査データは Audit Vault 内に保管できます Oracle Access Management Suite Oracle Identity Analytics およびOracle Identity Governance Suite 監査レポート 無効な論理的アクセス試行 Oracle Access Management Suiteはn 回の不正なログイン試行後にロックアウトを実行し 監査証跡を作成します Audit Vault and Database Firewallは 特権ユーザーによる無効な論理アクセス試行に対してアラートを通知します 標準のデータベース監査は 失敗したログイン試行を監査します IDおよび認証メカニズムの使用と変更 ( 新規アカウントの作成とより高い権限の付与などが含まれますが この限りではありません ) ルート権限や管理者権限を使用したアカウントの変更 追加 削除のすべて Oracle Databaseの認証と監査 Oracle Advanced SecurityのKerberos PKI RADIUS 認証 Oracle Access Management Suite 監査レポート Oracle Identity and Access Management Suite Oracle Audit Vault and Database Firewall システムレベル オブジェクトの作成と削除 Oracle Database の監査機能 10.3 すべてのシステム コンポーネントで イベントごとに少なくとも次の監査証跡を記録します ユーザー ID Oracle Access Management Suite 監査レポート Oracle イベントのタイプ Database の監査 日付と時刻 Oracle Audit Vault and Database Firewall の監査データ統合 レ 成功または失敗の表示 イベントの起点 ポート アラート および保護 Oracle のクライアント識別子による 単一接続での ID 伝播 15

17 影響を受けたデータ システム コンポーネント リソースの識別子または名前 10.5 監査証跡は 改変できないように保護します Oracle Audit Vault and Database Firewallの監査データ統合は 送信中と保管中の監査データを保護し 刑事訴追での使用に対す る一連の保管要件を満たします 監査証跡の閲覧は それが業務上必要なユーザーに制限します Oracle Audit Vault and Database Firewallの職務の分離機能により 監査データへのアクセスが制限されます 監査証跡ファイルは 改ざんされないように保護します Oracle Audit Vault and Database Firewall の職務の分離機能は 管理者 (DBA) による監査データへのアクセスと変更を防止します 監査証跡ファイルは 集中ログ サーバーまたは改ざんが難しいメディアにすみやかにバックアップします Oracle Audit Vault and Database Firewallの監査データ統合は スケーラブルでセキュアな監査ウェアハウスを提供します 既存のログ データが変更された場合 必ずアラートが発せられるように ファイルの整合性監視や変更検出を行うソフトウェアを使用します ( 新しいデータの追加に対してアラートは発生しません ) Oracle Audit Vault and Database Firewallの監査データ統合により 監査データは送信中も保護されます Oracle Audit Vault and Database Firewallの職務の分離機能は 管理者 (DBA) による監査データへのアクセスと変更を防止します 10.6 すべてのシステム コンポーネントのログとセキュリティ イベントを調査して 異常や疑わしいアクティビティを特定します 注 : 要件に準拠するために ログの収集ツール 解析ツール アラート ツールを使用することもできます Oracle Audit Vault and Database Firewallは 監査データを監視するために 標準提供のレポート カスタマイズ可能なアラート アラート ダッシュボードを提供します カスタマイズしたレポートは Oracle Application Express Oracle Business Intelligence Publisher またはサード パーティ製のツールを使用して生成できます Oracle Access Management SuiteおよびOracle Identity Managerは すべてのユーザー アクティビティおよびプロビジョニング / デプロビジョニングのログを提供します 10.7 監査証跡の履歴は 少なくとも1 年間は保管しておき 最低 3カ月間は分析のためにすぐに閲覧できるようにします ( たとえば オンライン アーカイブ またはバックアップからリストア可能な形式 ) Oracle Audit Vault and Database Firewallが提供するスケーラブルでセキュアな監査ウェアハウスを使用すると 大容量 ( テラバイト ) の監査データを保管できます 付録 A: 共有ホスティング プロバイダ向けの PCI DSS 追加要件 A 共有ホスティング プロバイダは カード会員データ環境を保護すること 要件 12.8および12.9の記述のとおり カード会員データにアクセスできるすべてのサービス プロバイダ ( 共有ホスティング プロバイダを含む ) は PCI DSSを遵守しなければなりません さらに 要件 2.6には 共有ホスティング プロバイダはそれぞれの事業体のホスト環境やデータを保護しなければならない とあります したがって 共有ホスティング プロバイダは この付録に記載されている要件についても遵守しなければなりません A.1 A.1.1からA.1.4にあるとおり それぞれの事業体 ( 加盟店 サービス プロバイダ その他の事業体 ) のホスト環境とそのデータを保護します ホスティング プロバイダは PCI DSSにおけるその他の該当部分に加えて これらの要件を満たす必要があります 注 : ホスティング プロバイダがこれらの要件を満たしていても そのホスティング プロバイダを利用している事業体の準拠が保証されるわけではありません それぞれの事業体が PCI DSSに準拠し その準拠状況を検証しなければなりません 16

18 A.1.1 それぞれの事業体は その事業体のカード会員データ環境にアクセスするプロセスのみを実行します Oracle Database Vault: レルムは 高特権ユーザーやDBAによるアプリケーション データおよびカード会員データへのアクセスを制限します ファクタとコマンド ルールは アプリケーション データ およびデータベースへのアクセスに対する厳密な制御を適用します 職務の分離機能は Oracleデータベースで不正な管理アクションが実行されることを防止します Oracle Label Securityは 必要な範囲を決定するための行レベルの特権ユーザー制御を提供します Oracle Virtual Private Databaseは 必要な範囲に基づいた基本的な実行時マスキング機能を提供します Oracle Advanced Security Data Redactionはアプリケーションに表示される機密データを削除します Oracle Databaseのオブジェクト権限とデータベース ロールにより 基本的なセキュリティが提供されます Oracle Identity Governance Suiteは コンピューティング リソースへのエンタープライズでのユーザー プロビジョニング (IDライフサイクル管理 ) を提供します A.1.2 それぞれの事業体のアクセスと権限を その事業体に属するカード会員データ環境のみに制限します 上記に加えて : Oracle Access Management Suiteは 一元化されたアクセス制御 認可 および認証を提供します Oracle Identity Analyticsは 詳細なジョブ割当てとアクセスのためのロール定義を提供します A.1.3 それぞれの事業体のカード会員データ環境ごとに ロギングと監査証跡が有効化され PCI DSS 要件 10 に準拠していることを確認します Oracle Audit Vault and Database Firewallのポリシーはエンタープライズ データベースへの導入が容易なため カード会員データへのアクセスに対する一貫した監査を実現できます 監査管理者のみが監査ポリシーおよびプロセスを変更できます Oracle Access Management Suiteは すべてのユーザー アクティビティに関する監査レポートを提供します A.1.4 ホスティングする加盟店やサービス プロバイダにセキュリティ侵害が発生した場合 タイムリーにフォレンジック調査が実行できるように手順を確立します Oracle Audit Vault and Database Firewallは 監査データを監視するために 標準提供のレポート カスタマイズ可能なアラート アラート ダッシュボードを提供します カスタマイズしたレポートは Oracle Application Express Oracle Business Intelligence Publisher またはサード パーティ製のツールを使用して生成できます Oracle Audit Vault and Database Firewallでは ウェアハウス スキーマが公開されています 17

19 PCI データ保護の課題 危険にさらされているカード会員データ PCI DSSは 組織にカード会員データを保護することを要求しています 基本的に ( 実際の業務で使用される場合 通常は一緒に保管される ) プライマリ アカウント番号 (PAN) カード会員名 サービス コード 有効期限がカード番号とともに保管される場合 これらはカード会員データの対象となります 加盟店が手動デバイスでカードの刻印のカーボン コピーを取るようになって以来 この情報は 犯罪者にとって非常に重要な情報となっています 今日 外部のハッカーや悪意あるインサイダーが バックエンド データベースに格納された数百万というクレジットカード レコードを取り込み それらを国際的なインターネット上のブラック市場で販売したり それらの情報を使用して高額商品を購入したりする可能性があります 不正な あるいはより一般的には不必要なデータベースやオペレーティング システムへのアクセスによって データベース管理者やシステム管理者などの信頼できる特権ユーザーをはじめ この情報にアクセスしたり確認したりする必要のない開発者やその他の従業員に対してまで カード会員データが公開されてしまいます 欠陥のある展開やその後のエラーの結果生じた安全でないデータベース構成では カード会員データが盗難される可能性がかなり高くなります 暗号化の発達 データ暗号化は 企業のPCIコンプライアンス プログラムにとって不可欠な要素です ただし 明らかなセキュリティ上のメリットにもかかわらず 企業はパフォーマンスへの影響や管理の難しさを理由に暗号化を避けてきた過去があります これはプロジェクトの中断や安全でない脆弱な実装の原因となっていました 特に 暗号化プロジェクトには キー管理の問題が付きまとっていました ネイティブまたは独自の暗号化ソリューションは 通常 組織に応じて拡縮しないため 会社は停止時 稼働中 バックアップ時にデータを処理するために複数のツールの組み合わせを使用しなければならない場合があります さらに 独自または継ぎ接ぎのソリューションでは データベース通信のセキュリティをより堅牢にするために 強力な認証を組み込むという課題に直面することは必至です PCI DSSおよびその他のコンプライアンスの要件により 環境は永続的に変化してきました 問題は 暗号化するかどうかではなく どのように安全でスケーラブルかつ管理可能な方法で暗号化するかということです Oracle Data Redaction および暗号化ソリューション Oracle Advanced Securityは アプリケーションに対する機密データのリダクション ( 編集 編纂 ( へんさん )) とストレージやバックアップ メディアに保管中のデータの暗号化を含む予防的なセキュリティ制御を提供します 要件 3.3は組織に対して " プライマリ アカウント番号は全体を表示させないようにして 業務において正当な必要性のある担当者のみがプライマリ アカウント番号全体を参照できるように " することを命じています スマートフォン デバイスやタブレット デバイスの保有により 機密データ公開の問題の緊急性が増しています 従来のオフィス環境以外でのデータ アクセスが一般的になっているためです 従来のアプリケーションでも 機密データの公開を減らすためのより包括的なソリューションが必要です たとえば 顧客のクレジット カード情報や個人を識別できる情報が 18

20 コール センターのオペレーターに対して画面表示されるコール センターのアプリケーションを考えてみましょう Oracle Advanced SecurityのData Redactionでは データベースの問合せ結果内の機密データがアプリケーションで表示される前に 選択的にその場でリダクション ( マスキング ) を実行できます このため 未承認ユーザーが機密データを見ることはできません また 要件 3.4は " プライマリ アカウント番号は どこに保管されていても判読不可能な状態にしておく " ことを組織に命じています いくつかのオプションがありますが " 関連するキー管理のプロセスと手順を伴う 強力な暗号化手法 " はデータ ストア内のカード会員データを保護するための論理ソリューションで 堅牢な自動化されたツールを使用して企業規模のデータ保護を処理します Oracle Advanced SecurityのTransparent Data Encryption(TDE) は 透過的に ディスクに書き込まれた時点でデータを暗号化し ユーザーが正常に認証および認可された後に それを復号化します TDEはデータベースを迂回し ファイルに直接アクセスしようとする試行を阻止します Oracleは 特定の機密列のTDE 列暗号化による暗号化 またはアプリケーション全体のTDE 表領域暗号化による暗号化を透過的にサポートしています 稼働中のデータの保護 Oracle Databaseは データ スニフィング データ損失 再生 PIM(Person-In-the-Middle) 攻撃などを阻止することで データのプライバシと機密性を保持しながら Oracle Databaseとの通信を保護します ネイティブのネットワーク暗号化と PKIインフラストラクチャを保持している企業向けのSSL/TLSベースの暗号化の両方を提供します Oracle Databaseでは データを暗号化しないクライアントからの接続を拒否するように設定できます または 柔軟な展開を実現するために 暗号化されていない接続を任意で許可することもできます バックアップ データの保護 PCIでは テープやその他のバックアップ メディアの紛失または盗難から保護するために カード会員情報のバックアップを暗号化することが求められています 既存のバックアップ手順では TDEを使用して保護れた表領域は暗号化された時点でバックアップされ TDE 列暗号化を使用して保護された表の列は 自動的にバックアップ メディア上で暗号化されたままになります SYSTEM 表領域を含むすべてのデータベース ファイルの暗号化は Oracle Recovery Manager(Oracle RMAN) およびTDEを一緒に使用して実行できます Oracle RMANは TDE 暗号化アルゴリズムとマスター暗号化キーを使用してデータベース バックアップ全体を暗号化する機能を提供します さらに Oracle Secure Backupはテープを暗号化し 一元化されたテープ バックアップ管理を提供します マスクされたデータの使用カード会員情報とその他の本番データは開発およびテスト作業にとって重要であるため 顧客のサポート担当や開発者 QA 担当者などに大量のカード会員データが渡される可能性があります PCI 要件ではこれらの担当者がカード会員情報を参照することを許可していません 要件 項では特に 実際のプライマリ アカウント番号を開発用に使用することを禁止しています このような使用例を減らすため 開発者はときどき 本番データをシミュレートするために仮のデータを生成し 19

21 ますが 特にテスト目的の場合 この処理が常に信頼できるとは限りません 20

22 このような場合は 目に見えるデータによって セキュリティやプライバシが侵害されないように 情報をマスクします データ マスキングは フィールドの数やタイプに関係なく データ形式を保持しながら 実際の値を偽の値で置き換えます ただし 企業内に多数の新しい継続中の開発プロジェクトが存在し PCIやその他の規制要件が課せられている場合 自動ツールを使わないデータ マスキングは困難になることがあります Oracle Data Masking and SubSettingは クレジットカード番号と関連付けられたカード会員情報を現実的でありながら偽の値と置き換えることで トランザクション 開発 テストを目的に またはその他の本番以外の目的でアウトソース パートナーやオフショア パートナーと共有するために 本番データを安全に使用できるようにします Oracle Data Masking and SubSettingはアプリケーションが引き続き正しく動作するように テンプレートとフォーマットルールのライブラリを使用して一貫したデータ変換を行うことで 参照整合性を維持します キー管理の解決 暗号化の弱点従来から データの可用性を維持しながら暗号化キーを生成し保護することは 特にエンタープライズ規模で暗号化を実装するうえでの大きな障壁となっていました キー管理は 発行 保管 および更新が困難なため 複雑で難易度が高く 失敗することもあります さらに悪いことに キーを紛失すると 重要なデータを永遠に回復できない可能性があります ITマネージャがより急を要する優先事項に気をとられ 業務側からキー管理の制御を緩めるように圧力がかかると キー管理があってもないに等しいセキュリティ制御になってしまうことがよくあります 結果として キーは複数のユーザーが広く使用できるようになり 暗号化は役に立たないものになってしまいます キー管理に対するPCI 要件 PCI 標準では 要件 3.5および3.6で キー管理について詳しく述べています 3.5 項では キーの不正使用によるカード会員データへのアクセスを防ぐため キーを強力に保護することを要求しています 特に 組織は キーへのアクセスを可能な限り少数のユーザー ( キー管理者 ) に制限し 可能な限り少数の場所にキーを安全に保管する必要があります 3.6 項では 次の考慮事項を含めたキーの実装について詳しく述べています 強力な暗号化キーの生成 セキュアなキー配布 ( クリアテキストを使用せず キー管理者のみに配布 ) セキュアな暗号化されたストレージ 定期的なキー変更 ( 自動化を推奨 ) 未使用のキーまたは解読された可能性のあるキーの破棄または交換 1 人のユーザーがキー全体にアクセスするのを防ぐためのキー情報の分割とデュアル コントロール 21

23 Oracleのキー管理 Oracle Advanced Security Transparent Data Encryption(TDE) は 組込みのキー管理機能でこれらの要件に対応します TDEは内部で自動的に暗号化キーを作成します 2 層のシステムには データ暗号化キーを保護するマスター暗号化キーがあります マスター キーは データベースの外部 つまり Oracle WalletにPKCS#12 形式ファイルでパスワード暗号化された状態で安全に保管されます マスター キーは より高度な安全性を確保するために ハードウェア セキュリティ モジュール (HSM) デバイスに保管することもできます オラクルは 業界標準のPKCS#11インタフェースを使用して Thales RSA Safenet Utimacoなどが提供している製品を含め 多数のHSMおよび外部キー管理システムと通信します カード会員データの保護の構築 強力な認証強力な認証の必要性は PCI DSS 全体を通じて何度も出現するテーマです 強力な認証の使用は 要件 8で推奨されています 要件 8では コンピュータへのアクセスに 一意のユーザー ID および相応の認証が必要であることが規定されています 特に 8.7では カード会員データを含むデータベースへのアクセスを認証する必要があると定められています Oracle DatabaseはKerberos PKI RADIUSを含む強力な認証ソリューションを提供しています 監視 追跡 および監査カード会員データの強力なデータ セキュリティ ポリシーと制御を維持するには それらが確実に意図したとおりに正しく動作し 実施されるように 継続して監視 追跡 および監査する必要があります 制御が有効であることを検証し 不正なアクティビティとエラーを検出して対処する機能により 堅牢なカード会員データ保護プログラムが完全なものになると同時に 組織は ポリシーと制御が有効に存続していることをQSAに確認できます PCI DSS 要件 10は 組織がカード会員データへのアクセスを追跡し 監視するように求めています この標準は監査機能も重視しており 特に要件 10.2では カード会員データへの個々のユーザー アクセスの監査証跡を実装することが義務付けられています Oracle Audit Vault and Database Firewallを使用することで セキュリティ担当者は 不正なアクセスの試み システム レベルの権限の濫用を示す可能性のあるアクティビティを検出および警告できます 収集された監査データを継続して監視し アプリケーションの表への変更や特権ユーザーの作成などのシステム イベントを含む 定義済みのアラート条件に対してアクティビティを評価します Oracle Audit Vault and Database FirewallはOracleおよびOracle 以外のデータベースだけでなく オペレーティング システム ディレクトリ その他のソースから監査証跡を収集します これにはOracle Databaseのファイングレイン監査と条件付き監査が含まれます 22

24 Oracle Audit Vault and Database Firewallは 広範なアクティビティを監視し QSAの評価と内部監査 セキュリティ プログラム および業務要件をサポートするための強力な組込みのレポート機能を提供しています Oracle Audit Vault and Database Firewallには 広範なアクティビティを監視するための強力なレポート機能が組み込まれています レポート ユーザーが疑わしい不正なアクティビティを迅速に検出できるように 特定の行を自動的にハイライトするルールを配置できます 標準のレポートには データベース アカウント管理 ロールと権限 オブジェクト管理 およびログイン失敗の情報が含まれます Oracle Audit Vault and Database Firewallは Oracle Database 監査設定の一元化された管理を提供し 企業全体に渡る監査設定の管理 およびQSAへのコンプライアンスと再現可能な制御の明確化における ITセキュリティ担当者と内部監査員の仕事を簡素化します セキュアな構成の維持攻撃者は データベース インスタンスの構成の弱点を悪用することがあります これは 悪意ある部外者がカード会員データを取り込むことができるいくつかの方法の1つです 脆弱な構成設定 構成実施標準の欠落 パッチの不足 エラー および変更管理手順以外で加えられた不正な変更を含む構成の " ずれ " はすべて カード会員データを攻撃に晒されやすくします 構成の監視と問題の検出および修正に取り組む組織にとって 資産の検出 追跡 および構成分析の手順が障害となっています これらの手順は多くの場合 手動で実行され 時間がかかり エラーを起こしがちです PCI DSSは セキュアな構成プラクティスのニーズに対応します 要件 2で 組織は パスワードや SNMPコミュニティ文字列などのベンダー提供のデフォルト値を変更し 不要なアカウントを削除するように命じています 2.2 項では 認知された強化基準に準拠し 既知の構成の脆弱性に対応した構成標準の開発を要求しています 要件 6では 最新のパッチを適用することが必須とされています Oracle Configuration Managementは データベース構成 ( オペレーティング システム ハードウェア アプリケーション サーバー およびパッケージ化されたアプリケーション構成も同様 ) の資産検出 追跡 および変更検出の機能を提供します 詳細な構成情報を定期的に収集し 企業に固有の構成値を決定するための分析と検索の機能を提供します Oracle Configuration Managementを使用して IT 管理者は 変更の検出 " 構成のずれ " の修正 予定された変更の検証を実行できます また Oracle Configuration Managementは 監査用に制御と構成手順を検証するための強力なコンプライアンス レポート機能も備えています 23

25 特権アカウントの管理 内部の敵特権ユーザーのアクセス制御や特権ユーザーの認可 職務の分離などの重要な機能を手動手順に依存しなければならない場合 その管理と維持が困難になります 担当者および要件の変更や新たな資産の獲得といった一般的な要素を考慮に入れると その傾向はさらに強くなります しかし 残念なことに 組織は 複数の管理者でユーザー IDを共有したり ( 要件 8.5により禁止 ) ポリシーに違反した権限や所定のワークフロー プロセス外の権限を割り当てたりすることでこれに対応しようとします また ログを監視して未承認アクティビティや不適切なアクティビティがないかを調査する作業には 多くの時間とリソースがかかり エラーも生じやすいことから 組織はこのような作業を適切に実行しておらず 問題がさらに深刻化します 皮肉にも 組織はシステム管理者やDBAなどの特権アカウントよりも汎用ユーザー アカウントのセキュリティ管理に力を入れる傾向がありますが 特権アカウントはより高いセキュリティ リスクの原因となります このリスクをもたらすのは 特権アカウントがカード会員データなどの機密情報にアクセスし システムを構成し データベースを変更して他者に権限を付与できるためです しばしば 特権ユーザー アカウントの管理がずさんとなっているのには 多くの理由があります 長年の間 高い権限を持つ個人は信頼できる人物であるが その他の従業員はあまり信頼できないと考えられてきました もちろん 大半の特権ユーザーは信頼できますが 私利私欲または報復のために権限を濫用する衝撃的な例があります このようなシステム侵入の企ての標的となるのは 機密性の高いカード会員データを含むデータベースなどのシステムに潜在的に幅広くアクセスできる特権ユーザー アカウントです さらに ミスはよくあることであり 表の削除は特権ユーザーが犯す間違いの一例にすぎません これらのアカウントの管理を実施するのは困難です 許可した権限が少なすぎて業務を妨げるリスクを負うよりは 過大な権限を許可する方が簡単です 特権は多くの場合 緊急時 少なくとも緊急とみなされる状況下で付与されますが 権限が取り消されることはありません 特権アカウントとそれらのパスワードは 便宜上 複数のユーザーで共有される傾向があります 機密データベースへの完全なアクセスと制御に関して考えた場合 ずさんに制御され定義が不十分な特権アカウントがどのような結果を招くかは明らかです 規制の圧力により 特権ユーザーと特権アカウントを調べ これらの長期にわたるセキュリティ リスクを修正することを組織は余儀なくされました 特権ユーザー ロールは 組織内の誰よりも高い粒度レベルで定義し それらがどのシステムとデータにアクセスでき どの操作の実行が許可されるかを制御する必要があります 特に 職務分離に注意する必要があります 特権ユーザーを管理および監視するシステムは 動作を遅らせたり ビジネスを中断したりすることなく 正当なニーズに対応するために十分な柔軟性を備えている必要があります そうでないと 過度に広範な高特権アカウントの問題にすぐに戻ってしまいます 24

26 PCI がリスクを認識 特権ユーザーのアクセスと認可についての懸念は PCI DSSに大きく反映されています 特権アカウントの場合は アクセス制御 ユーザー認証 およびユーザー アクティビティの追跡に関するグローバルな要件を強調する必要があり 要件はすべて何度も強調されています 組織が 一般のユーザーに妥当なレベルのアクセス制御を実施しても 特権ユーザー アカウントを見合うレベルに合わせることができなかった場合は 中身のない勝利を得たことになります 要件 7の指令を実装するときは特権ユーザーに特に注意し カード会員データへのアクセスは それを知る必要のある業務の担当者のみに制限します 7.1 項では 組織が 特権ユーザー IDへのアクセス権を業務の責任を果たすために必要な最低限の権限に制限するように 明示的に示されています また 権限は職種と職務に基づいて決定することが求められています 特に高い特権を持つアカウントのリスクは最大になるため これらの職種を必要に応じて見直し 再定義することが非常に重要です 特権ユーザーに伴うリスクは 特に カード会員データを含むデータベースへのすべてのアクセスを認証する必要性を述べている 要件 8の堅牢な認証に関する指令においても重視すべき点です ネットワーク リソースとカード会員データへのアクセスの追跡と監視について取り上げている要件 10では " システム コンポーネントに対するすべてのアクセス ( 特にrootなどの管理権限を持つユーザーによって実行されたもの ) を 個々のユーザーとリンクするための手順を確立する " と指定されています Oracleによる特権アカウントの管理 Oracle Database Vaultを使用して 組織は特権ユーザーを制御し カード会員データなどの重要な資産を不要なリスクや公開から保護できます Oracle Database Vaultは 特権ユーザーのアクセスと認可を厳密に定義し 職務分離を実施するための強力ながら柔軟で管理しやすいメカニズムを備えています Oracle Database Vaultは " レルム " の概念を使用してデータベース内にファイアウォールを作成することで 強力な特権ユーザー アクセス制御を提供します 機密性の高い表やアプリケーションはレルムに配置できるため 特権ユーザーはカード会員データへアクセスせずに職務を遂行できます コマンド ルールによって 複数ファクタ認可がデータベースへのアクセスを特定のサブネットまたはアプリケーション サーバーのみに制限し データ アクセスのための信頼できるパスを作成できます IPアドレス 時間 認証方式などの組込みのファクタを 柔軟で適応可能な方法で使用して PCIコンプライアンスとビジネス要件を満たすようにアクセス制御を実施できます Oracle Database Vaultは データベース内で責務別に3つの個別のロール ( アカウント管理 セキュリティ管理 データベース管理 ) を定義し 標準使用できる職務分離のベースラインを提供します これらの各ロールは 特定のビジネス要件を満たすようにカスタマイズできます Oracle Database Vaultでは レルムによってデータ アクセス試行がブロックされたなどの情報を提供する多数の標準レポートが用意されています そのため たとえば DBAがレルムによって保護されたデータ アプリケーションの表にアクセスしようとすると Oracle Database Vaultがアクセスをブロックし レルム違反レポートで参照可能な監査レコードを作成します 前述のとおり Oracle Audit Vault and Database Firewallは 堅牢な監視 監査 およびレポート機能を提供し これらは当然 すべてのタイプの特権ユーザーに適用できます 25

27 ID 管理によるコンプライアンスの実現とビジネスの強化 セキュアで柔軟なIDおよびアクセス管理データベース セキュリティは PCIコンプライアンス プログラムの中心であり 王冠の宝石に匹敵するカード会員データを直接保護します その中心を取り巻き アクセス制御 認可 および認証を核として作成された堅牢なID 管理が 自由に流れるビジネス プロセスにセキュリティが緊密に統合された企業環境を生み出します その結果 ビジネスを強化する一方で コンプライアンス要件を満たすエンド ツー エンドのセキュリティが確立されます ユーザーとアプリケーションのアクセス制御は PCI DSS 要件の文言だけでなく その含意も満たすため 実際にカード会員データを保護できます 現実的には カード会員データは不活性ではありません それは パートナー サプライヤ ベンダー および従業員にまでおよぶ非常に複雑な分散型企業で商取引を成功させるための要因の1つです ID 管理は 単なるユーザー ID パスワード ファイル権限の集合ではありません ユーザー アプリケーション データ およびプライベート ネットワークとパブリック ネットワークの動的なエコシステムです 新しいアクセス要求や新しいアプリケーション 新しいビジネス イニシアチブだけでなく 従業員や請負業者 パートナーなどの絶え間ない出入りにより 限定的な権限や一時的な権限が必要とされるため このエコシステムは常に変化します この絶え間ない変化が作り出すリスクの高い流動的な環境は 簡単に管理不可能な状態に陥ります ID 管理の計画には 次のことを含める必要があります 企業全体にわたり ポリシーに従って 効率的に制御を維持できるように 個々のアプリケーションから分離された一元的に管理されたアクセス制御 明確に定義された高い粒度のロールベースのアクセス制御 (RBAC) ロールは特定の職務権限ごとに作成し ロールごとに必要な権限を定義されます その後 ロールを個々のユーザーに割り当てるため 責務の追加や変更を簡単に行うことができます 明確に定義された評価および承認ワークフローに基づいた 従業員 請負業者 認可権限のタイムリーで正確なプロビジョニングとデプロビジョニング リアルタイムな監視とアラート発行 包括的でタイムリーな監査 および強力なレポート機能 26

28 IDおよびアクセス管理に対するPCI 要件特権ユーザーに関して前述したとおり PCI DSSには 同団体がアクセス制御を非常に重視していることが反映されています 要件 7では カード会員データへのアクセスを それを知る必要のあるユーザーのみに制限しています このアクセスは 職務を遂行するための最低限の権限という原則と 個々の職務および職務権限に基づいて認可する必要があります 要件 8では コンピュータにアクセスする各ユーザーに一意のユーザー IDを割り当てることを必須とし 適切とみなされる2つの要素による認証 ( リモート アクセスの場合は必須 ) とパスワードに関するルールを含む 認証の要件を規定しています 要件では プロビジョニングも対象に含まれています 重要なプロビジョニング機能の例を次に挙げます ユーザー ID 資格証明 その他のIDオブジェクトの追加 削除 および変更を制御し 管理を特定の権限を持つ小規模なグループに限定します 離職したユーザーのアクセスはただちに取り消します 少なくとも90 日ごとに 休眠状態にあるユーザー アカウントを削除または無効にします ベンダーがリモート保守に使用するアカウントは 必要な時間帯のみ有効にします これについては データベースへの直接アクセス または特権ユーザーのアクティビティという概念を超えて検討してください 明確に定義されたロールとそれらをサポートする認可および認証要件がなければ 誰がカード会員データまたはカード会員データにアクセスするアプリケーションにアクセスしたか またはそのアクセス権を取得したかを知ることはできません 実際に どのアプリケーションがアクセス権を持つのかもわかりません 要件 10では ネットワーク リソースとカード会員データへのすべてのアクセスの追跡および監視という重要な領域を取り上げています PCI DSSは データへの直接アクセスだけを重視しているわけではなく カード会員情報が 多数の関係者が存在し 部分的な移動や変更が多い動的な本番環境内に存在していることを認識しています また 最初に アクセス制御 認可 プロビジョニング および認証のルールが述べられ その後 ユーザーおよびアプリケーションのアクティビティの監視が取り上げられている点にも注意してください 正しい許可されたアクティビティを制御するポリシーとプロセスがなければ 不正なアクティビティを監視することはできません 要件では システム コンポーネントに対するすべてのアクセスを個々のユーザーに関連付けた包括的な監査証跡の実現が必要とされ カード会員データに対するすべての個別ユーザー アクセスを再現するプロセスが必要とされています 監査証跡へのアクセスや無効なアクセスの試行 監査ログの初期化 システム レベル オブジェクトの作成と削除も要件の対象に含まれています 27

29 ID 管理の課題 PCI DSSのID 管理関連の要件は おそらく 実装するのがもっとも困難で 管理および維持するのはさらに困難です このような問題は 組織がコンプライアンスに対する取組みを継続的に維持できない主要な原因の一部になっています これらの問題により 組織が障害のあるシステムの修復や違反の修正を実行しようとして ( 利用可能な ) データの収集と分析を行う際 理不尽な時間や労力 コストがかかる場合があります ID 管理の問題は 制御機能をQSAに対して証明するが 実際は制御がほとんど有効でない理由を説明する事に終始しているという難題をもたらします これらの課題のいくつかについて検討してみましょう これらの課題は通常 ポリシーは適切であるものの それらを非効率な手動プロセスにより実施しようとした結果として生じます アクセス制御 認可および認証は 必然的に 一元的に管理されるのではなく 一般にアプリケーション単位で実行されます その結果 ポリシーの実施にばらつきが生じ 人手のかかる管理となるため 常に変化するビジネス要件への対応は遅く非効率となり 結果にエラーが生じやすく セキュリティは脆弱化します 一元化されたポリシーベースの管理がなければ ユーザー グループ アプリケーション およびデータ アクセスを対象に一貫して適切な認証制御を提供することは困難です ロールベースのアクセス制御は 理論的には優れていますが 実装および維持するのは容易ではありません ロールを定義し 企業全体にわたるロールベースのアプローチを確立するには 膨大な時間とリソースを費やす必要があります ユーザー 責務 および一連のレポートに関する情報は 通常 組織の至るところにあるサイロに収められているため この状態はさらに悪化します 複雑な分散型企業で一貫したポリシーを管理し 適用することはほぼ不可能です ユーザーのプロビジョニングとデプロビジョニングおよびユーザーの認可にはたいてい時間がかかり ビジネスの妨げとなります スプレッドシートベースの管理は 効果的にポリシーを適用できますが 多忙な管理者による対応の遅れと 担当マネージャによる評価と承認を待つ遅延時間が原因でボトルネックとなる場合があります 一般に このようなプロセスはさまざまな理由でエラーが起こりやすいと言えます ロールベースの制御は 自動システムなしで定義および管理するのは困難です そのため 個々のユーザーまたはグループの粗雑な割当てに基づいて 個々のユーザーに過少または過大な権限が付与される場合があります 管理者は 個々のユーザーが職務を遂行するために必要なものを確保するために 過剰に認可しすぎる傾向があります これは 個々のユーザーが請負業者またはベンダーで 組織内で高特権を持ってしまった場合に より重大な懸念事項となります このような環境では 該当する個々のユーザーが去った後に " ゴースト " アカウント ( 不正アカウントとも呼ばれる ) が長期間存続したり 一時的な認可が取り消されず残ったりすることがあります アカウントは 引き続き企業システムとデータへのアクセス権を持つ以前の従業員 任務が終了した請負業者 または一時的な権限が付与されたが組織内での職務が変更になった既存の従業員に属している場合があります ユーザー アクティビティの監視は 不可能でない場合でも 困難です ほとんどの場合 リアルタイムの監視機能やアラート機能はありません アクセスの制御と監視はアプリケーションやシステムごとに別々に管理されているため 現実的な問題として個人を監視することはほぼ不可能です 28

30 監査作業も PCI 監査に関するレポートと同様に断片的で非効率になります アプリケーションやシステム間でログが分割されているため 多くの場合 規制要件と内部要件の遵守も効率的に実行できません 手動で情報収集 分析 およびレポートを実行する必要があり さらに複数のアプリケーションとシステムが関連する場合は相互の関連付けも行う必要があります オラクルのID 管理ソリューションオラクルのID 管理ソリューション スイート製品は 完全に統合 一元化 管理 自動化されたソリューションを提供します アクセス制御 認可と認証 ロールベースの詳細制御 プロビジョニングの各機能が提供されており PCI 要件 の指令を遵守し さらに上回るために役立ちます Oracle Access Management Suiteは 一元化された認可 認証 および監査を通じてアクセス制御のセキュリティを確保し ユーザーに対して透過的なシングル サインオン機能を実現します 認可機能をアプリケーションから分離することで 組織はビジネス要件に従い ポリシーとカスタマイズ可能なルールに基づいて 組織全体にわたりアクセス権限を管理および監視できます アクセス システムは一元化されたポリシーベースの認可サービスを提供しています それを使用して 管理者は ユーザー ロール グループ メンバーシップ ( 静的 ネスト または動的 ) 時間 曜日 IPアドレスなどに基づき アクセスを特定のリソースに制限するポリシーを定義できます Oracle Access Management SuiteにはPCIの認証要件が実装されており X.509 証明書 スマート カード 2 要素認証 トークンやフォーム ベースの認証をサポートしています それによって 組織は 標準アプリケーションや情報ソースへの一般的なログインの場合にはパスワード認証のみを要求し より機密性の高いアクセスの場合にはトークンの使用などの強力な認証を要求できるように 認証の階層を確立することができます Oracle Identity Governance Suiteは堅牢なプロビジョニングおよびデプロビジョニング製品であり 組織がすばやく簡単にユーザーをプロビジョニングし ビジネス要件に基づいて永続的または一時的に認可を提供できるようにします さらに セキュリティを強化し PCI 要件 8の該当する項を遵守します Oracle Identity Analyticsは 現在 Oracle Identity Governance Suiteに統合されているものではあるが ロールベースの詳細なアクセス制御やロールの分析とレポート作成 およびSODチェックを提供することで 組織がニーズに合わせて正確にロールを定義し 割り当てられるようにします これにより 最小権限および職種と職務の原則に基づいてアクセスと認可を割り当てるという要件が満たされます オラクルのID 管理製品は 強力な監視 監査 およびレポート機能を備え 監視と監査に対するPCI 要件 10を効率的に満たします Oracle Access Management Suiteは ポリシーベースの認証を設定および適用し ユーザーのアクセス アクティビティを監視します Oracle Identity Managerは 不正アカウントを検出し ユーザー アクセス権限に変更を加えます Oracle Access Management Suiteの監査サービスは 認証の成功または失敗など 監視したイベントを詳細かつ柔軟にロギングします 監査ログはフラット ファイルまたはデータベースに書き込むことができ 任意のサード パーティのレポート ツールにエクスポートして包括的な監査レポートを生成できます 29

31 結論 PCI-DSSはおそらく パブリック インターネットの普及とインターネットによる不正の広がりによって 情報セキュリティに関する懸念が表面化し始めて以来 私達が目にした中でもっとも期待できる業界の自己管理への取組みです 何十億もの安全でない消費者情報レコードを悪用しようとして 犯罪者がオンライン上に移動してきたことから クレジットカード会社は時代に遅れないようにするため カード会員データを保護するための非常に規範的な詳細計画を作成しました この設計書を強力な土台とすることで IT 組織は優れたデータ セキュリティ プログラムを構築できます 多くの組織にとって 特に その他の一部の業界ほどにはセキュリティ ポリシーが成熟していない小売業者にとって コンプライアンスとデータ セキュリティは困難であることが実証されてきました しかし PCI DSSの目標は達成可能であり この標準に含まれる要件は 持続可能な継続的プログラムを利用して遵守できます これを推進するには オラクルをはじめとするデータ セキュリティ分野のリーダーが提供する自動化ツールと健全なセキュリティ ポリシーの組合せが必要です これにより コンプライアンスが実現されると同時に 組織のビジネス プラクティスの改善が可能になります 30

32 参考資料 次に OracleソリューションとPCI DSSの遵守に関する詳しい情報を含むホワイト ペーパーとWeb サイトを示します 以下の情報は古くなっている場合があることに注意してください ホワイト ペーパー : Oracle Enterprise Manager Configuration Management Packを使用したPCIコンプライアンスの対応 Getting PCI DSS Compliance Right:How Identity Management Can Help Security Secure Information Access pdf Oracle Solaris 11 and PCI DSS Meeting PCI DSS Compliance with Oracle Solaris pdf Webサイト Oracle Database Securityのソリューション Oracle Identity Managementのソリューション Oracle Configuration Management 31

33 2014 年 3 月 Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA U.S.A. Copyright 2014, Oracle and/or its affiliates. All rights reserved 本文書は情報提供のみを目的として提供されており ここに記載される内容は予告なく変更されることがあります 本文書は一切間違いがないことを保証するものではなく さらに 口述による明示または法律による黙示を問わず 特定の目的に対する商品性もしくは適合性についての黙示的な保証を含み いかなる他の保証や条件も提供するものではありません オラクル社は本文書に関するいかなる法的責任も明確に否認し 本文書によって直接的または間接的に確立される契約義務はないものとします 本文書はオラクル社の書面による許可を前もって得ることなく いかなる目的のためにも 電子または印刷を含むいかなる形式や手段によっても再作成または送信することはできません Oracle および Java は Oracle およびその子会社 関連会社の登録商標です その他の名称はそれぞれの会社の商標です IntelおよびIntel XeonはIntel Corporationの商標または登録商標です すべてのSPARC 商標はライセンスに基づいて使用されるSPARC International, Inc. の商標または登録商標です AMD Opteron AMDロゴおよびAMD Opteronロゴは Advanced Micro Devicesの商標または登録商標です UNIXは The Open Groupの登録商標です 0113