クレジットカード業界の現状と課題 - Financial …...2014/11/18 · クレジットカード業界の動向 〜利用シーンの拡大と利用率の向上～ (1)少額支払い
クレジットカード業界の データ・セキュリティ標準への 持続 ... ·...
33
Oracleホワイト・ペーパー 2014年3月 クレジットカード業界の データ・セキュリティ標準への 持続可能なコンプライアンス
Transcript of クレジットカード業界の データ・セキュリティ標準への 持続 ... ·...
Oracleホワイト・ペーパー 2014年3月
クレジットカード業界の データ・セキュリティ標準への 持続可能なコンプライアンス
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
はじめに ...................................................................................................................................................... 2
Oracle製品とPCIソリューションのマッピング .................................................................................... 3
PCIデータ保護の課題 ............................................................................................................................. 18
危険にさらされているカード会員データ ..................................................................................... 18
暗号化の発達 ........................................................................................................................................... 18
Oracle Databaseのリダクションおよび暗号化ソリューション .............................................. 18
稼働中のデータの保護 ..................................................................................................................... 19
バックアップ・データの保護 ......................................................................................................... 19
マスクされたデータの使用 ............................................................................................................. 19
キー管理の解決 ....................................................................................................................................... 21
暗号化の弱点 ..................................................................................................................................... 21
キー管理に対するPCI要件 ............................................................................................................... 21
Oracleのキー管理 .............................................................................................................................. 22
カード会員データの保護の構築 ........................................................................................................... 22
強力な認証 ......................................................................................................................................... 22
監視、追跡、および監査 ................................................................................................................. 22
セキュアな構成の維持 ..................................................................................................................... 23
特権アカウントの管理 ........................................................................................................................... 24
内部の敵 ............................................................................................................................................. 24
PCIがリスクを認識 ................................................................................................................................. 25
Oracleによる特権アカウントの管理 ............................................................................................. 25
ID管理によるコンプライアンスの実現とビジネスの強化 .............................................................. 26
セキュアで柔軟なIDおよびアクセス管理 ..................................................................................... 26
IDおよびアクセス管理に対するPCI要件 ....................................................................................... 27
ID管理の課題 ........................................................................................................................................... 28
オラクルのID管理ソリューション ................................................................................................. 29
結論 ............................................................................................................................................................ 30
参考資料 ................................................................................................................................................... 31
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
はじめに
多くの組織は、クレジットカード業界データ・セキュリティ標準（PCI DSS）の準拠に対して頭を悩まし続けています。これは、クレジットカード業界で義務付けられているカード会員のデータ保護と不正防止を目的としたものです。PIC DSSは大手5社のクレジットカード会社によって、各社のプログラムを調整して1組の要件にまとめるために策定されました。それ以来、PCI Security Standards Council（PCI SSC）は複数回の更新を発表しており、最新のバージョン3は2014年1月に有効になっています。
標準は12の要件とサポート・ガイダンスからなり、ほとんどの政府や業界のセキュリティ指令よりも慣例に基づいているものの、これに準拠するには、多くの場合、本来あるべきレベルよりもはるかに多くのリソースと高いコストが必要になり、エラーも多く発生します。担当者などが手動でログ・データを収集・分析し、レポートを集計し、セキュリティ管理とポリシーを維持・検証する労力について考えると、組織の階層レベルによっては、平均コストが1年あたり数十万ドルに達する場合もあるでしょう。
アクセス制御、データ保護、構成管理のポリシーは実装が難しく、実際に維持、管理、および適用するのはさらに困難です。コンプライアンスとセキュリティに関する手続きは時間がかかるか柔軟性に欠けることが多く、現在のダイナミックなビジネス環境で変化するビジネス要件に対応できていません。手動制御、または不完全に実装され管理される制御はコストがかかりエラーも発生しやすく、実際には、セキュリティを大幅に改善することなく、効率的なビジネスの妨げになっています。結果として、個人、ときには部門でさえ、業務を"成し遂げる"ためにポリシーを避けて通ることがあります。驚くまでもなく、多くのデータ侵害は、技術的にはPCI DSSに準拠している組織で起こっています。
組織は、PCIで義務付けられた技術的な要件を満たし、標準の策定目的であるカード会員のデータ保護レベルを達成する、効率的で繰り返しと持続が可能なセキュリティ・プログラムを実現できます。このホワイト・ペーパーでは、要件の中核の大半を構成する重要だが問題のある領域を中心に、PCIコンプライアンス・プログラムの要点について説明します。
• カード会員データを不正使用から保護する
• 特権ユーザーとデータ・アクセスに強力な制御を適用する
• 一元化され自動化されたロールベースのアクセス制御、認可、および認証を実装する
• システムとデータベースの監査を提供し、データベース・アクティビティを監視する
データ・セキュリティ、ID管理、構成管理製品からなるオラクルの包括的ポートフォリオは、徹底的なセキュリティ保護を提供することで、12の要件のうちの6つに対応します。残りの要件（1、4、5、9、11、12）はそれぞれ、アンチウイルスとネットワーク・ファイアウォールの導入、パブリック・ネットワークを介したカード会員データの暗号化送信、物理的なセキュリティ管理、テスト、管理者用ポリシーの維持に関係しています。
2
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
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 すべてのシステム・コンポーネントについて設定基準を作成し
ます。これらの基準は、すべての既知のセキュリティ脆弱性に
対応しており、業界で認知されたシステム強化基準に準拠した
ものでなければなりません。業界で認められたシステム強化基
準の提供元には次が含まれますが、この限りではありません。
Center for Internet Security（CIS）
International Organization for Standardization（ISO）
SysAdmin Audit Network Security（SANS）Institute
National Institute of Standards Technology（NIST）
Oracle Enterprise Managerは、オラクル、顧客ポリシー、業界で
広く受け入れられたプラクティスに基づく構成確認機能を提供
します。Enterprise ManagerはOracle Databaseの検出、プロビ
ジョニング、パッチ適用機能を提供します。
2.2.4 誤用を防止するように、システムのセキュリティ・
パラメータを設定します。
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で不正な管理アクションが実行されることを防止でき
ます。
2.2.5 スクリプト、ドライバ、機能、サブシステム、ファ
イル・システム、不要なWebサーバーをはじめとす
る、すべての不要な機能を削除します。
Oracle Databaseのカスタム・インストールでは、特定のコンポー
ネントのインストールや削除が可能です。
3
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
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は、非本番環境でテストや
ＱＡクオリティアシュアランスを目的として使用される本番
データを保護します。
Oracle Label Securityが提供するセキュリティ制御を使用する
と、誰がプライマリ・アカウント番号にアクセスできるかを決定
できます。
Oracle Database Vaultのレルムを使用して、特権ユーザーによる
アプリケーション・データへのアクセスを防止できます。
4
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
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'コマンドを実行できる
かを制限できます。
3.5.1 暗号化キーへのアクセスは、必要最小限の管理者に
制限します。
Oracleを使用する場合、個人がマスター暗号化キーにアクセスす
る必要はありません。DBAやデータベース・セキュリティ管理者
（DSA）などの指定された担当者は、ウォレット・パスワードまたは
HSMの認証文字列を把握し、'alter system'権限を持っていれ
ば、ウォレットまたはHSMを開くことができます。そうすること
で、データベースでマスター暗号化キーを使用できます。
Oracle Database Vaultのコマンド・ルールを実装すると、誰が、
いつ、どこから、'alter system'コマンドを実行できるかを制
限できます。
5
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
3.5.2 カード会員データの暗号化/復号化に使用する秘密
鍵は、常に次のいずれかの形式で保存します。
• 少なくともデータ暗号化キーと同じ強度を持
つ、キー暗号化キーで暗号化されており、こ
のキー暗号化キーはデータ暗号化キーとは別
の場所に保管されている。
• セキュアな暗号化デバイス（ハードウェア・
セキュリティ・モジュール（HSM）やPTS認
可の加盟店端末装置など）。
• 少なくとも2つの全長キー要素または鍵共有
は業界で認められた方式に従う。
注：公開鍵を上記の形式で保管する必要はありません。
マスター暗号化キーは、各データベースに1つだけ存在します。
一元的にマスター暗号化キーを管理するため、このキーをOracle
WalletまたはHSMデバイスに保管します。
3.6 3.6.1 強力な暗号化キーの生成 Oracle Advanced Security TDEは業界で定評のあるライブラリを利
用して、強力な暗号化キーを生成します。ハードウェア・セキュリ
ティ・モジュール（HSM）を使用する場合、キーの生成と保管を含む
マスター暗号化キーの管理はHSMによって行われます。
3.6.2 セキュアな暗号化キーの配布 Oracle Advanced Securityは、広く知られたDiffie-Hellman鍵交換
アルゴリズムを使用してセキュアなキーを配布します。
3.6.3 セキュアな暗号化キーの保管 Oracle Advanced Security TDEの列キーおよび表領域キーは、
Oracle WalletまたはHSMデバイスに保存されたマスター・キーを
使用して暗号化された状態で、データベースに保管されます。
3.6.4 関連するアプリケーション・ベンダーまたはキー所
有者によって定義された方法で、業界のベスト・プ
ラクティスとガイドライン（例：NIST Special
Publication 800-57など）に従って、暗号有効期間の
期限に達した（例：規定された期間が経過した後や、
特定のキーによって一定量の暗号文が生成された
後）キーを暗号化キーが付け替えます。
Oracle Advanced Security TDEの列暗号化は、マスター暗号化
キーや表キーを個別にre-keyingする機能を提供しています。
Oracle Database 11g Release 2以降では、TDE表領域暗号化の
マスター暗号化キーも同様にre-keyingできます。PCIコンプライ
アンスでは、多くの場合、マスター暗号化キーのre-keying（ロー
テーション）で十分です。
脆弱性管理プログラムの整備
6 セキュアなシステムとアプリケーションを開発し、保守すること
悪意を持った人々は、セキュリティの脆弱性を利用して、システムへの特権アクセスを手に入れます。このような脆弱性の多くは、ベンダー
提供のセキュリティ・パッチにより修正されます。セキュリティ・パッチは、システムを管理する事業体がインストールする必要があります。
悪意ある人々や悪意あるソフトウェアによるカード会員データの不正使用および侵害を阻止するため、すべてのシステムにすべての適切なソ
フトウェア・パッチをインストールする必要があります。
注：適切なソフトウェア・パッチとは、そのパッチが既存のセキュリティ設定と矛盾しないことが十分に確認され、テストされたパッチを指
します。自社開発アプリケーションの場合、標準のシステム開発プロセスとセキュアなコーディング技術を使用することで、多くの脆弱性を
回避できます。
6
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
6.1 セキュリティ脆弱性に関する外部の信頼できる情報源を使用
して、セキュリティ脆弱性を特定するプロセスを確立し、新た
に検出したセキュリティ脆弱性にリスク・ランキング（例："
高"、"中"、"低"）を割り当てます
注：リスク・ランキングは、業界のベスト・プラクティスと潜
在的な影響を考慮して決定する必要があります。
オラクルはCritical Patch Updates（CPU）でリリースされるバグ
修正の重大度を評価する際、Common Vulnerability Scoring
System（CVSS）に従っています。
http://www.oracle.com/technetwork/topics/security/cvssscoringsy
stem-091884.html
Oracle Critical Patch Updates、Security Alerts、Third Party
Bulletinに関するRSSフィードに登録してください。
http://www.oracle.com/technetwork/topics/security/alerts-086861
.html
6.2 すべてのシステム・コンポーネントとソフトウェアを既知の脆
弱性から保護するため、ベンダーが提供するすべてのセキュリ
ティ・パッチをインストールします。重要なセキュリティ・パッ
チは、リリース後1カ月以内にインストールします。
Oracleデータベースを使用する場合、Oracle Enterprise Manager
Grid Controlを使用して自動化できます。
顧客のポリシーとプロセスの問題。オラクルは四半期ごとに
Critical Patch Updatesを提供しており、ほとんどの場合、顧客は
30日以内にこれを実装できます。
6.4 6.4.1 開発/テスト環境を本番環境から切り離し、アクセス
制御の分離を適用します。
Oracle Database Enterprise EditionのEnterprise User Security機
能をOracle Identity Managementと併用すると、データベース・
ユーザーとその認可を1カ所で集中管理できます。
Oracle Identity Governance Suiteに含まれるOracle Privileged
Account Managerは、権限の分離を可能にし、特権カウントに対
するセルフサービス式のリクエストを管理し、パスワードの使用
に関する監査とレポート作成機能を提供します。
Oracle Database Vaultを使用すると、Oracleデータベース内の本
番データへのDBAによるアクセスを保護できます。
6.4.3 テストまたは開発環境では、本番データ（実際のプ
ライマリ・アカウント番号）は使用しません。
Oracle Data Masking and SubSettingはテスト環境や開発環境向
けに、クレジットカード番号やその他の機密情報を識別不能にし
ます。
6.4.5 セキュリティ・パッチとソフトウェア変更の実装に
対する変更管理手順には、次が含まれている必要が
あります。
6.4.1 影響のドキュメント化
6.4.2 権限を持つ関係者によるドキュメント化され
た変更の承認
6.4.3 該当する変更がシステム・セキュリティに悪
影響を与えないことを検証するための機能テ
スト
6.4.4 バック・アウト手順
Oracle Change Managementを利用すると、データベース変更管
理手順を自動化できます。また、Oracle BPEL Process Manager
を使用して、変更管理や一般的なセキュリティ手順のプロセス管
理を実行できます。
Change Managementは、変更を実装する前に変更の依存関係を
分析し、影響レポートを生成します。また、変更を取り消すため
の情報を提供します。
Oracle Databaseに含まれる時間に関連する（Temporal）データベース
機能は、SQL:2011規格に準拠したトランザクション時間と有効時
間をサポートしています。フラッシュバック・データ・アーカイ
ブの履歴表は改ざんを防止する設計になっているため、重要デー
タの変更を含む、変更不可能で明確な履歴を監査担当者に提供で
きます。
7
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
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 140-2 Level 3の検
証）が得られます。
Oracle Database Standard EditionおよびEnterprise Editionでは、
SSL/TLSを使用して、Oracleデータベースに対するネットワーク
接続を暗号化できます。
6.5.1 インジェクションを利用した不正、特にSQLイン
ジェクション。また、OSコマンド・インジェクショ
ンやLDAPインジェクション、Xpathインジェクショ
ン、およびその他のインジェクションによる不正も
考慮に入れます。
6.5.3 セキュリティで保護されていない暗号化ストレージ。
6.5.4 セキュリティで保護されていない通信。
8
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
強固なアクセス制御手法の導入
7 カード会員データへのアクセスを業務上の必要範囲内に制限すること
権限を与えられた担当者のみが重要なデータにアクセスできるように、システムおよびプロセスを利用して、職責に応じたアクセスと必知事
項に基づくアクセスに制限する必要があります。
"必要な範囲"とは、職務の実行に必要な最小限のデータと権限に対してのみ、アクセス権が付与される状態を指します。
7.1 システム・コンポーネントとカード会員データへのアクセス
を、業務上必要な担当者に限定します。
7.1.1 次を含むアクセス要件をロールごとに定義します。
• 各ロールが職務を遂行するためにアクセスを必
要とするシステム・コンポーネントとデータ・
リソース
• リソースへのアクセスに必要な権限レベル
（ユーザー、管理者など）
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は、ジョブと機能の詳細な定義を提供す
るためのロールと短期の割当てを定義します。
7.1.2 特権ユーザーIDに付与されるアクセスを、職責を果
たすために必要な最小限の権限に制限します。
7.1.2 個々の担当者の職種と職務に基づいてアクセスを割
り当てます。
9
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
7.2 複数のユーザーを持つシステム・コンポーネントの場合、ユー
ザーの必知事項に基づいてアクセスを制限し、個別に許可され
ない限り"すべて拒否"に設定するアクセス制御システムを確立
します。
このアクセス制御システムには以下が含まれる必要がありま
す。
7.2.1 すべてのシステム・コンポーネントを対象に含める
こと
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は、ジョブと機能の詳細な定義を提供す
るためのロールと短期の割当てを定義します。
7.2.2 職種と職務権限に基づいて担当者に権限が割り当て
られていること
7.2.3 デフォルトは"すべて拒否"に設定すること
8 システム・コンポーネントに対するアクセスの識別と認証
10
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
アクセスを持つユーザーごとに一意の識別子（ID）を割り当てることで、各ユーザーが自分の行動に独自の責任を負うようにします。このよ
うな責任が課されている場合、重要なデータやシステムに対する操作が、既知の認可ユーザーおよびプロセスによって実行されていることを
確認できるだけでなく、操作からユーザーにさかのぼって追跡できるようになります。
パスワードの有効性はおもに認証システムの設計と実装によって決まります。特に、攻撃者がパスワードを試行する頻度や、送信中、保存中
にエントリ・ポイントでユーザー・パスワードを保護するセキュリティ手法によって異なります。
注：これらの要件は、管理機能を持つすべてのアカウント（POSアカウントを含む）と、カード会員データの参照とアクセス、またはカード
会員データを含むシステムへのアクセスに使用されるすべてのアカウントに当てはまります。これには、ベンダーやその他の第三者（サポー
トや保守用）によって使用されるアカウントも含まれます。ただし、1度に1つのカード番号のみにアクセスして単一トランザクションを実行
するPOS支払いアプリケーション内のユーザー・アカウント（レジ係のアカウントなど）に対して、要件8.1.1、8.2、8.5、8.2.3から8.2.5、8.1.6
から8.1.8は適用されません。
11
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
8.1 すべてのシステム・コンポーネント上で、非消費者ユーザーと
管理者に対して適切なユーザーID管理を徹底するためのポリ
シーと手順を定義し、実装します。
8.1.1 システム・コンポーネントまたはカード会員データ
へのアクセスを許可する前に、すべてのユーザーに
一意のIDを割り当てます。
Oracle Databaseの認証機能は、専用ユーザー・アカウントと
Kerberosを含む強力な認証機能をサポートします。
Oracle Identity Governance Suiteは自動ワークフローと集中リポ
ジトリを使用したエンタープライズ・ユーザー・プロビジョニン
グを提供します。ユーザーがアクティブでなくなると、自動的に
プロビジョニングが解除されます。特権アクセスはワンタイム・
パスワード（OTP）を使用した例外ベースで管理する必要があり
ます。特権アクセスやサポート・アクセスを詳細に監視すること
で、担当者が許可されたアクティビティのみを実行するように徹
底できます。
Oracle Access Management Suiteは、一元化されたアプリケー
ション・レイヤーのアクセス制御、認可、および認証を提供しま
す。
Oracle Identity Governance Suiteに含まれるOracle Privileged
Account Managerは、パスワードの生成、パスワードのプロビ
ジョニング、パスワードへのアクセス管理を行うセキュアなパス
ワード管理ソリューションです。アクセス試行が繰り返された場
合はアカウントのロックアウトを起動でき、試行回数と修正プロ
セスは設定が可能です。
8.1.2 ユーザーID、証明書、その他の識別子オブジェクト
の追加、削除、および変更を管理します。
8.1.3 離職したユーザーのアクセスはただちに取り消し
ます。
8.1.4 少なくとも90日ごとに、休眠状態にあるユーザー・
アカウントを削除または無効にします。
8.1.5 リモート・アクセスを介してシステム・コンポーネ
ントのアクセス、サポート、保守を行うためにベン
ダーによって使用されるIDを、次のように管理しま
す。
• 必要な期間のみ有効にし、使用しないときは
無効にします。
• 使用中はIDを監視します。
8.1.6 ユーザーIDをロックアウトすることにより、連続し
たアクセス試行を6回以内に制限します。
8.1.7 ロックアウト時間は最低で30分間、または管理者が
ユーザーIDを有効にするまでとします。
8.1.8 セッションのアイドル時間が15分を超えた場合、
ターミナル・セッションを再びアクティブ化するに
は、ユーザーが再認証を行う必要があります。
8.2 一意のIDの割当てに加えて、次の方法のうち少なくとも1つを
導入してすべてのユーザーを認証することで、すべてのシステ
ム・コンポーネント上での非消費者ユーザーと管理者に対する
適切なユーザー認証管理を実現します。
• パスワードやパスフレーズなどのユーザーが知っている
要素
• トークン・デバイスやスマート・カードなどのユーザーが
持っている要素
バイオメトリックなどのユーザー自身に関する要素
Oracle Databaseは2つの要素による認証を提供します。
Oracle Access Management Suiteは、強力な認証（トークン、ス
マート・カード、X.509証明書、フォーム）とパスワードをサポー
トします。さまざまなレベルのセキュリティ要件に対応する認証
の階層を提供します。
Oracle Adaptive Access Managerは、ソフトウェア形式で2つの
要素による認証を提供します。また、リアルタイム・リスク分析
を実行し、さらなる認証が必要かどうかを判断します。
12
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
8.1.2 送信中やすべてのシステム・コンポーネントに保管
中のあらゆる認証資格証明（パスワードやパスフ
レーズなど）は、強力な暗号化を使用して判読不可
能な状態にします。
Oracle DatabaseはデータベースのユーザーIDとパスワードを組
み合わせたハッシュを作成し、このハッシュは認証プロセス内で
レコード・ハッシュと比較されます。
Oracle Privileged Account Managerによって管理されるパスワー
ドとメタデータ情報は、Oracleデータベース内に暗号化された状
態で永続化されます。
Oracle Databaseは、Oracle Advanced SecurityとTransparent
Data Encryptionを使用して暗号化できます。
Oracle Databaseはネットワーク暗号化（SSL/TLS）と強力な認
証を提供します。
8.2.3 パスワード/パスフレーズは次の条件を満たす必要が
あります。
• 最小の長さは、少なくとも7文字以上にします。
• 数字と英字の両方を含みます。
別の方法として、パスワード/パスフレーズが、上記
で指定したパラメータと少なくとも同等の強度およ
び複雑さを持つ必要があります。
Oracle Access Managerには、PCI DSS 3.0の複雑さ要件を満た
すポリシーが設定されたセルフサービス式のパスワード・リセッ
ト機能が含まれています。
Oracle Databaseパスワードの複雑さのチェック：http://docs.oracle.com/
cd/B28359_01/server.111/b28337/tdpsg_user_accounts.htm#TDPSG2
0022
8.2.4 ユーザー・パスワード/パスフレーズは、少なくとも
90日ごとに変更します。
Oracle Databaseのプロファイル
Oracle Identity Manager
Oracle Access Manager
8.2.5 直近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は存在しない。
システム・コンポーネントを管理するために、共有ユーザーID
や汎用ユーザーIDは使用しません。
（顧客の内部ポリシー）、Oracle Database専用のユーザー・ア
カウント、Oracle Databaseのエンタープライズ・ユーザー・
セキュリティ、Oracle Databaseのプロキシ認証、Oracle Identity
Governance Suite
13
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
8.7 カード会員データを保管しているデータベースへのアクセス
（アプリケーション、管理者、その他すべてのユーザーによる
アクセスを含む）は次のとおりに制限します。
• データベースに対するすべてのユーザー・アクセスとユー
ザー問合せ、ユーザー・アクションは、プログラム的な手
法を介して実施します。
• データベース管理者のみが、データベースへの直接アクセ
スまたは問合せを実行できます。
データベース・アプリケーションのアプリケーションIDを使用
できるのはアプリケーションのみです（個人ユーザーやその他
の非アプリケーション・プロセスは使用できません）。
Oracle Databaseの認証機能
Oracle Advanced SecurityのKerberos、PKI、RADIUSサポート、
Oracle Identity Governance Suite、Oracle Database Valid Node
Checking
定期的なネットワークの監視およびテスト
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
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
10.2.1 カード会員データに対する、個人ユーザーによるす
べてのアクセス
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監査レポート
10.2.2 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
10.2.3 すべての監査証跡へのアクセス データベースの監査データはAudit Vault内に保管できます。
Oracle Access Management Suite、Oracle Identity Analytics、お
よびOracle Identity Governance Suite監査レポート
10.2.4 無効な論理的アクセス試行 Oracle Access Management Suiteはn回の不正なログイン試行後
にロックアウトを実行し、監査証跡を作成します。
Audit Vault and Database Firewallは、特権ユーザーによる無効な
論理アクセス試行に対してアラートを通知します。
標準のデータベース監査は、失敗したログイン試行を監査します。
10.2.5 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
10.2.7 システムレベル・オブジェクトの作成と削除 Oracle Databaseの監査機能
10.3 すべてのシステム・コンポーネントで、イベントごとに少なく
とも次の監査証跡を記録します。
10.3.1 ユーザーID Oracle Access Management Suite 監 査 レ ポ ー ト 、 Oracle
Databaseの監査 10.3.2 イベントのタイプ
10.3.3 日付と時刻 Oracle Audit Vault and Database Firewallの監査データ統合、レ
ポート、アラート、および保護
Oracleのクライアント識別子による、単一接続でのID伝播 10.3.4 成功または失敗の表示
10.3.5 イベントの起点
15
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
10.3.6 影響を受けたデータ、システム・コンポーネント、
リソースの識別子または名前
10.5 監査証跡は、改変できないように保護します。 Oracle Audit Vault and Database Firewallの監査データ統合は、
送信中と保管中の監査データを保護し、刑事訴追での使用に対す
る一連の保管要件を満たします。
10.5.1 監査証跡の閲覧は、それが業務上必要なユーザーに
制限します。
Oracle Audit Vault and Database Firewallの職務の分離機能によ
り、監査データへのアクセスが制限されます。
10.5.2 監査証跡ファイルは、改ざんされないように保護し
ます。
Oracle Audit Vault and Database Firewallの職務の分離機能は、管理者
（DBA）による監査データへのアクセスと変更を防止します。
10.5.3 監査証跡ファイルは、集中ログ・サーバーまたは改
ざんが難しいメディアにすみやかにバックアップ
します。
Oracle Audit Vault and Database Firewallの監査データ統合は、
スケーラブルでセキュアな監査ウェアハウスを提供します。
10.5.5 既存のログ・データが変更された場合、必ずアラー
トが発せられるように、ファイルの整合性監視や変
更検出を行うソフトウェアを使用します（新しい
データの追加に対してアラートは発生しません）。
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
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
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
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
PCIデータ保護の課題
危険にさらされているカード会員データ
PCI DSSは、組織にカード会員データを保護することを要求しています。基本的に、（実際の業務で使用される場合、通常は一緒に保管される）プライマリ・アカウント番号（PAN）、カード会員名、サービス・コード、有効期限がカード番号とともに保管される場合、これらはカード会員データの対象となります。
加盟店が手動デバイスでカードの刻印のカーボン・コピーを取るようになって以来、この情報は、犯罪者にとって非常に重要な情報となっています。今日、外部のハッカーや悪意あるインサイダーが、バックエンド・データベースに格納された数百万というクレジットカード・レコードを取り込み、それらを国際的なインターネット上のブラック市場で販売したり、それらの情報を使用して高額商品を購入したりする可能性があります。
不正な、あるいはより一般的には不必要なデータベースやオペレーティング・システムへのアクセスによって、データベース管理者やシステム管理者などの信頼できる特権ユーザーをはじめ、この情報にアクセスしたり確認したりする必要のない開発者やその他の従業員に対してまで、カード会員データが公開されてしまいます。欠陥のある展開やその後のエラーの結果生じた安全でないデータベース構成では、カード会員データが盗難される可能性がかなり高くなります。
暗号化の発達
データ暗号化は、企業のPCIコンプライアンス・プログラムにとって不可欠な要素です。ただし、明らかなセキュリティ上のメリットにもかかわらず、企業はパフォーマンスへの影響や管理の難しさを理由に暗号化を避けてきた過去があります。これはプロジェクトの中断や安全でない脆弱な実装の原因となっていました。特に、暗号化プロジェクトには、キー管理の問題が付きまとっていました。ネイティブまたは独自の暗号化ソリューションは、通常、組織に応じて拡縮しないため、会社は停止時、稼働中、バックアップ時にデータを処理するために複数のツールの組み合わせを使用しなければならない場合があります。さらに、独自または継ぎ接ぎのソリューションでは、データベース通信のセキュリティをより堅牢にするために、強力な認証を組み込むという課題に直面することは必至です。
PCI DSSおよびその他のコンプライアンスの要件により、環境は永続的に変化してきました。問題は、暗号化するかどうかではなく、どのように安全でスケーラブルかつ管理可能な方法で暗号化するかということです。
Oracle Data Redaction および暗号化ソリューション
Oracle Advanced Securityは、アプリケーションに対する機密データのリダクション(編集・編纂（へ
んさん）)とストレージやバックアップ・メディアに保管中のデータの暗号化を含む予防的なセキュ
リティ制御を提供します。
要件3.3は組織に対して、"プライマリ・アカウント番号は全体を表示させないようにして、業務において正当な必要性のある担当者のみがプライマリ・アカウント番号全体を参照できるように"することを命じています。スマートフォン・デバイスやタブレット・デバイスの保有により、機密データ公開の問題の緊急性が増しています。従来のオフィス環境以外でのデータ・アクセスが一般的になっているためです。従来のアプリケーションでも、機密データの公開を減らすためのより包括的なソリューションが必要です。たとえば、顧客のクレジット・カード情報や個人を識別できる情報が、
18
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
コール・センターのオペレーターに対して画面表示されるコール・センターのアプリケーションを考えてみましょう。
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要件ではこれらの担当者がカード会員情報を参照することを許可していません。要件6.4.3項では特に、実際のプライマリ・アカウント番号を開発用に使用することを禁止しています。このような使用例を減らすため、開発者はときどき、本番データをシミュレートするために仮のデータを生成し
19
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
ますが、特にテスト目的の場合、この処理が常に信頼できるとは限りません。
20
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
このような場合は、目に見えるデータによって、セキュリティやプライバシが侵害されないように、情報をマスクします。データ・マスキングは、フィールドの数やタイプに関係なく、データ形式を保持しながら、実際の値を偽の値で置き換えます。
ただし、企業内に多数の新しい継続中の開発プロジェクトが存在し、PCIやその他の規制要件が課せられている場合、自動ツールを使わないデータ・マスキングは困難になることがあります。
Oracle Data Masking and SubSettingは、クレジットカード番号と関連付けられたカード会員情報を現実的でありながら偽の値と置き換えることで、トランザクション、開発、テストを目的に、またはその他の本番以外の目的でアウトソース・パートナーやオフショア・パートナーと共有するために、本番データを安全に使用できるようにします。Oracle Data Masking and SubSettingはアプリケーションが引き続き正しく動作するように、テンプレートとフォーマットルールのライブラリを使用して一貫したデータ変換を行うことで、参照整合性を維持します。
キー管理の解決
暗号化の弱点
従来から、データの可用性を維持しながら暗号化キーを生成し保護することは、特にエンタープライズ規模で暗号化を実装するうえでの大きな障壁となっていました。
キー管理は、発行、保管、および更新が困難なため、複雑で難易度が高く、失敗することもあります。さらに悪いことに、キーを紛失すると、重要なデータを永遠に回復できない可能性があります。
ITマネージャがより急を要する優先事項に気をとられ、業務側からキー管理の制御を緩めるように圧力がかかると、キー管理があってもないに等しいセキュリティ制御になってしまうことがよくあります。結果として、キーは複数のユーザーが広く使用できるようになり、暗号化は役に立たないものになってしまいます。
キー管理に対するPCI要件
PCI標準では、要件3.5および3.6で、キー管理について詳しく述べています。3.5項では、キーの不正使用によるカード会員データへのアクセスを防ぐため、キーを強力に保護することを要求しています。特に、組織は、キーへのアクセスを可能な限り少数のユーザー（キー管理者）に制限し、可能な限り少数の場所にキーを安全に保管する必要があります。3.6項では、次の考慮事項を含めたキーの実装について詳しく述べています。
• 強力な暗号化キーの生成
• セキュアなキー配布（クリアテキストを使用せず、キー管理者のみに配布）。
• セキュアな暗号化されたストレージ
• 定期的なキー変更（自動化を推奨）
• 未使用のキーまたは解読された可能性のあるキーの破棄または交換
• 1人のユーザーがキー全体にアクセスするのを防ぐためのキー情報の分割とデュアル・コントロール
21
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
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
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
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
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
特権アカウントの管理
内部の敵
特権ユーザーのアクセス制御や特権ユーザーの認可、職務の分離などの重要な機能を手動手順に依存しなければならない場合、その管理と維持が困難になります。担当者および要件の変更や新たな資産の獲得といった一般的な要素を考慮に入れると、その傾向はさらに強くなります。しかし、残念なことに、組織は、複数の管理者でユーザーIDを共有したり（要件8.5により禁止）、ポリシーに違反した権限や所定のワークフロー・プロセス外の権限を割り当てたりすることでこれに対応しようとします。また、ログを監視して未承認アクティビティや不適切なアクティビティがないかを調査する作業には、多くの時間とリソースがかかり、エラーも生じやすいことから、組織はこのような作業を適切に実行しておらず、問題がさらに深刻化します。
皮肉にも、組織はシステム管理者やDBAなどの特権アカウントよりも汎用ユーザー・アカウントのセキュリティ管理に力を入れる傾向がありますが、特権アカウントはより高いセキュリティ・リスクの原因となります。このリスクをもたらすのは、特権アカウントがカード会員データなどの機密情報にアクセスし、システムを構成し、データベースを変更して他者に権限を付与できるためです。
しばしば、特権ユーザー・アカウントの管理がずさんとなっているのには、多くの理由があります。長年の間、高い権限を持つ個人は信頼できる人物であるが、その他の従業員はあまり信頼できないと考えられてきました。もちろん、大半の特権ユーザーは信頼できますが、私利私欲または報復のために権限を濫用する衝撃的な例があります。このようなシステム侵入の企ての標的となるのは、機密性の高いカード会員データを含むデータベースなどのシステムに潜在的に幅広くアクセスできる特権ユーザー・アカウントです。さらに、ミスはよくあることであり、表の削除は特権ユーザーが犯す間違いの一例にすぎません。
これらのアカウントの管理を実施するのは困難です。許可した権限が少なすぎて業務を妨げるリスクを負うよりは、過大な権限を許可する方が簡単です。特権は多くの場合、緊急時、少なくとも緊急とみなされる状況下で付与されますが、権限が取り消されることはありません。特権アカウントとそれらのパスワードは、便宜上、複数のユーザーで共有される傾向があります。
機密データベースへの完全なアクセスと制御に関して考えた場合、ずさんに制御され定義が不十分な特権アカウントがどのような結果を招くかは明らかです。
規制の圧力により、特権ユーザーと特権アカウントを調べ、これらの長期にわたるセキュリティ・リスクを修正することを組織は余儀なくされました。特権ユーザー・ロールは、組織内の誰よりも高い粒度レベルで定義し、それらがどのシステムとデータにアクセスでき、どの操作の実行が許可されるかを制御する必要があります。特に、職務分離に注意する必要があります。
特権ユーザーを管理および監視するシステムは、動作を遅らせたり、ビジネスを中断したりすることなく、正当なニーズに対応するために十分な柔軟性を備えている必要があります。そうでないと、過度に広範な高特権アカウントの問題にすぐに戻ってしまいます。
24
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
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
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
ID管理によるコンプライアンスの実現とビジネスの強化
セキュアで柔軟なIDおよびアクセス管理
データベース・セキュリティは、PCIコンプライアンス・プログラムの中心であり、王冠の宝石に匹敵するカード会員データを直接保護します。その中心を取り巻き、アクセス制御、認可、および認証を核として作成された堅牢なID管理が、自由に流れるビジネス・プロセスにセキュリティが緊密に統合された企業環境を生み出します。その結果、ビジネスを強化する一方で、コンプライアンス要件を満たすエンド・ツー・エンドのセキュリティが確立されます。
ユーザーとアプリケーションのアクセス制御は、PCI DSS要件の文言だけでなく、その含意も満たすため、実際にカード会員データを保護できます。現実的には、カード会員データは不活性ではありません。それは、パートナー、サプライヤ、ベンダー、および従業員にまでおよぶ非常に複雑な分散型企業で商取引を成功させるための要因の1つです。ID管理は、単なるユーザーID、パスワード、ファイル権限の集合ではありません。ユーザー、アプリケーション、データ、およびプライベート・ネットワークとパブリック・ネットワークの動的なエコシステムです。新しいアクセス要求や新しいアプリケーション、新しいビジネス・イニシアチブだけでなく、従業員や請負業者、パートナーなどの絶え間ない出入りにより、限定的な権限や一時的な権限が必要とされるため、このエコシステムは常に変化します。この絶え間ない変化が作り出すリスクの高い流動的な環境は、簡単に管理不可能な状態に陥ります。
ID管理の計画には、次のことを含める必要があります。
• 企業全体にわたり、ポリシーに従って、効率的に制御を維持できるように、個々のアプリケーションから分離された一元的に管理されたアクセス制御。
• 明確に定義された高い粒度のロールベースのアクセス制御（RBAC）。ロールは特定の職務権限ごとに作成し、ロールごとに必要な権限を定義されます。その後、ロールを個々のユーザーに割り当てるため、責務の追加や変更を簡単に行うことができます。
• 明確に定義された評価および承認ワークフローに基づいた、従業員、請負業者、認可権限のタイムリーで正確なプロビジョニングとデプロビジョニング。
• リアルタイムな監視とアラート発行、包括的でタイムリーな監査、および強力なレポート機能。
26
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
IDおよびアクセス管理に対するPCI要件
特権ユーザーに関して前述したとおり、PCI DSSには、同団体がアクセス制御を非常に重視していることが反映されています。
要件7では、カード会員データへのアクセスを、それを知る必要のあるユーザーのみに制限しています。このアクセスは、職務を遂行するための最低限の権限という原則と、個々の職務および職務権限に基づいて認可する必要があります。
要件8では、コンピュータにアクセスする各ユーザーに一意のユーザーIDを割り当てることを必須とし、適切とみなされる2つの要素による認証（リモート・アクセスの場合は必須）とパスワードに関するルールを含む、認証の要件を規定しています。要件では、プロビジョニングも対象に含まれています。重要なプロビジョニング機能の例を次に挙げます。
• ユーザーID、資格証明、その他のIDオブジェクトの追加、削除、および変更を制御し、管理を特定の権限を持つ小規模なグループに限定します。
• 離職したユーザーのアクセスはただちに取り消します。
• 少なくとも90日ごとに、休眠状態にあるユーザー・アカウントを削除または無効にします。
• ベンダーがリモート保守に使用するアカウントは、必要な時間帯のみ有効にします。
これについては、データベースへの直接アクセス、または特権ユーザーのアクティビティという概念を超えて検討してください。明確に定義されたロールとそれらをサポートする認可および認証要件がなければ、誰がカード会員データまたはカード会員データにアクセスするアプリケーションにアクセスしたか、またはそのアクセス権を取得したかを知ることはできません。実際に、どのアプリケーションがアクセス権を持つのかもわかりません。
要件10では、ネットワーク・リソースとカード会員データへのすべてのアクセスの追跡および監視という重要な領域を取り上げています。PCI DSSは、データへの直接アクセスだけを重視しているわけではなく、カード会員情報が、多数の関係者が存在し、部分的な移動や変更が多い動的な本番環境内に存在していることを認識しています。
また、最初に、アクセス制御、認可、プロビジョニング、および認証のルールが述べられ、その後、ユーザーおよびアプリケーションのアクティビティの監視が取り上げられている点にも注意してください。正しい許可されたアクティビティを制御するポリシーとプロセスがなければ、不正なアクティビティを監視することはできません。
要件では、システム・コンポーネントに対するすべてのアクセスを個々のユーザーに関連付けた包括的な監査証跡の実現が必要とされ、カード会員データに対するすべての個別ユーザー・アクセスを再現するプロセスが必要とされています。
監査証跡へのアクセスや無効なアクセスの試行、監査ログの初期化、システム・レベル・オブジェクトの作成と削除も要件の対象に含まれています。
27
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
ID管理の課題
PCI DSSのID管理関連の要件は、おそらく、実装するのがもっとも困難で、管理および維持するのはさらに困難です。このような問題は、組織がコンプライアンスに対する取組みを継続的に維持できない主要な原因の一部になっています。これらの問題により、組織が障害のあるシステムの修復や違反の修正を実行しようとして（利用可能な）データの収集と分析を行う際、理不尽な時間や労力、コストがかかる場合があります。
ID管理の問題は、制御機能をQSAに対して証明するが、実際は制御がほとんど有効でない理由を説明する事に終始しているという難題をもたらします。
これらの課題のいくつかについて検討してみましょう。これらの課題は通常、ポリシーは適切であるものの、それらを非効率な手動プロセスにより実施しようとした結果として生じます。
アクセス制御、認可および認証は、必然的に、一元的に管理されるのではなく、一般にアプリケーション単位で実行されます。その結果、ポリシーの実施にばらつきが生じ、人手のかかる管理となるため、常に変化するビジネス要件への対応は遅く非効率となり、結果にエラーが生じやすく、セキュリティは脆弱化します。
一元化されたポリシーベースの管理がなければ、ユーザー、グループ、アプリケーション、およびデータ・アクセスを対象に一貫して適切な認証制御を提供することは困難です。
ロールベースのアクセス制御は、理論的には優れていますが、実装および維持するのは容易ではありません。ロールを定義し、企業全体にわたるロールベースのアプローチを確立するには、膨大な時間とリソースを費やす必要があります。ユーザー、責務、および一連のレポートに関する情報は、通常、組織の至るところにあるサイロに収められているため、この状態はさらに悪化します。
複雑な分散型企業で一貫したポリシーを管理し、適用することはほぼ不可能です。
ユーザーのプロビジョニングとデプロビジョニングおよびユーザーの認可にはたいてい時間がかかり、ビジネスの妨げとなります。スプレッドシートベースの管理は、効果的にポリシーを適用できますが、多忙な管理者による対応の遅れと、担当マネージャによる評価と承認を待つ遅延時間が原因でボトルネックとなる場合があります。
一般に、このようなプロセスはさまざまな理由でエラーが起こりやすいと言えます。ロールベースの制御は、自動システムなしで定義および管理するのは困難です。そのため、個々のユーザーまたはグループの粗雑な割当てに基づいて、個々のユーザーに過少または過大な権限が付与される場合があります。管理者は、個々のユーザーが職務を遂行するために必要なものを確保するために、過剰に認可しすぎる傾向があります。これは、個々のユーザーが請負業者またはベンダーで、組織内で高特権を持ってしまった場合に、より重大な懸念事項となります。
このような環境では、該当する個々のユーザーが去った後に、"ゴースト"アカウント（不正アカウントとも呼ばれる）が長期間存続したり、一時的な認可が取り消されず残ったりすることがあります。アカウントは、引き続き企業システムとデータへのアクセス権を持つ以前の従業員、任務が終了した請負業者、または一時的な権限が付与されたが組織内での職務が変更になった既存の従業員に属している場合があります。
ユーザー・アクティビティの監視は、不可能でない場合でも、困難です。ほとんどの場合、リアルタイムの監視機能やアラート機能はありません。アクセスの制御と監視はアプリケーションやシステムごとに別々に管理されているため、現実的な問題として個人を監視することはほぼ不可能です。
28
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
監査作業も、PCI監査に関するレポートと同様に断片的で非効率になります。アプリケーションやシステム間でログが分割されているため、多くの場合、規制要件と内部要件の遵守も効率的に実行できません。手動で情報収集、分析、およびレポートを実行する必要があり、さらに複数のアプリケーションとシステムが関連する場合は相互の関連付けも行う必要があります。
オラクルのID管理ソリューション
オラクルのID管理ソリューション・スイート製品は、完全に統合、一元化、管理、自動化されたソリューションを提供します。アクセス制御、認可と認証、ロールベースの詳細制御、プロビジョニングの各機能が提供されており、PCI要件7、8、10の指令を遵守し、さらに上回るために役立ちます。
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
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
結論
PCI-DSSはおそらく、パブリック・インターネットの普及とインターネットによる不正の広がりによって、情報セキュリティに関する懸念が表面化し始めて以来、私達が目にした中でもっとも期待できる業界の自己管理への取組みです。何十億もの安全でない消費者情報レコードを悪用しようとして、犯罪者がオンライン上に移動してきたことから、クレジットカード会社は時代に遅れないようにするため、カード会員データを保護するための非常に規範的な詳細計画を作成しました。この設計書を強力な土台とすることで、IT組織は優れたデータ・セキュリティ・プログラムを構築できます。
多くの組織にとって、特に、その他の一部の業界ほどにはセキュリティ・ポリシーが成熟していない小売業者にとって、コンプライアンスとデータ・セキュリティは困難であることが実証されてきました。しかし、PCI DSSの目標は達成可能であり、この標準に含まれる要件は、持続可能な継続的プログラムを利用して遵守できます。これを推進するには、オラクルをはじめとするデータ・セキュリティ分野のリーダーが提供する自動化ツールと健全なセキュリティ・ポリシーの組合せが必要です。これにより、コンプライアンスが実現されると同時に、組織のビジネス・プラクティスの改善が可能になります。
30
クレジットカード業界のデータ・セキュリティ標準への持続可能なコンプライアンス
参考資料
次に、OracleソリューションとPCI DSSの遵守に関する詳しい情報を含むホワイト・ペーパーとWebサイトを示します。以下の情報は古くなっている場合があることに注意してください。
ホワイト・ペーパー：
• Oracle Enterprise Manager Configuration Management Packを使用したPCIコンプライアンスの対応 http://www.oracle.com/technetwork/jp/oem/grid-control/twp-config-for-pci-129339-ja.pdf
• Getting PCI DSS Compliance Right:How Identity Management Can Help Security Secure Information Access http://www.oracle.com/technetwork/middleware/id-mgmt/pci-compliance-identity-v2-133468.pdf
• Oracle Solaris 11 and PCI DSS Meeting PCI DSS Compliance with Oracle Solaris 11 http://www.oracle.com/us/products/servers-storage/solaris/solaris11/solaris11-pci-dss-wp-1937938.pdf
Webサイト
• Oracle Database Securityのソリューション http://www.oracle.com/jp/products/database/security/overview/index.html
• Oracle Identity Managementのソリューション http://www.oracle.com/jp/products/middleware/identity-management/overview/index.html
• Oracle Configuration Management http://www.oracle.com/technetwork/oem/config-mgmt/config-mgmt-094108.html
31
http://www.oracle.com/us/products/servers-storage/solaris/solaris11/solaris11-pci-dss-wp-1937938.pdf
クレジットカード業界の
データ・セキュリティ標準への
持続可能なコンプライアンス
2014年3月
Oracle Corporation
World Headquarters
500 Oracle Parkway
Redwood Shores, CA 94065
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
