クレジット・カード業界のデータ・セキュリティ標準への持...

Oracleホワイト・ペーパー

2015年7月

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


はじめに .......................................................................................................................................................... 2

Oracle製品とPCIソリューションのマッピング ............................................................................... 3

PCIデータ保護の課題 ................................................................................................................................. 19

危険にさらされているカード会員データ ....................................................................................... 19

暗号化の発達 ................................................................................................................................................ 19

Oracle Databaseのリダクションおよび暗号化ソリューション ................................................ 19

稼働中のデータの保護 ......................................................................................................................... 20

バックアップ・データの保護 ............................................................................................................ 20

マスクされたデータの使用 ................................................................................................................ 21

キー管理の解決 ........................................................................................................................................... 21

暗号化の弱点 ......................................................................................................................................... 21

キー管理に対するPCI要件 ................................................................................................................... 22

Oracleのキー管理 ................................................................................................................................. 22

カード会員データの保護の構築 .............................................................................................................. 22

強力な認証.............................................................................................................................................. 22

監視、追跡、および監査..................................................................................................................... 23

セキュアな構成の維持 ......................................................................................................................... 23

特権アカウントの管理 ............................................................................................................................... 24

内部の敵 .................................................................................................................................................. 24

PCIがリスクを認識 ..................................................................................................................................... 25

Oracleによる特権アカウントの管理 ................................................................................................ 25

ID管理によるコンプライアンスの実現とビジネスの強化 ................................................................ 26

セキュアで柔軟なIDおよびアクセス管理 ....................................................................................... 26

IDおよびアクセス管理に対するPCI要件 .......................................................................................... 27

ID管理の課題 ................................................................................................................................................ 28

オラクルのID管理ソリューション .................................................................................................... 29

結論 ................................................................................................................................................................ 30

参考資料 ........................................................................................................................................................ 31


2

はじめに多くの組織は、クレジット・カード業界データ・セキュリティ標準（PCI DSS）の準拠に対して頭を悩まし続けています。これは、クレジット・カード業界で義務付けられているカード会員のデータ保護と不正防止を目的としたものです。PIC DSS標準は大手5社のクレジット・カード会社によって、各社のプログラムを調整して1組の要件にまとめるために策定されました。それ以来、PCI Security Standards Council（PCI SSC）は複数回の更新を発表しており、最新のバージョン3.1は2015年4月に有効になっています。

標準は12の要件とサポート・ガイダンスからなり、ほとんどの政府や業界のセキュリティ指令よりも慣例に基づいているものの、これに準拠するには、多くの場合、本来あるべきレベルよりもはるかに多くのリソースと高いコストが必要になり、エラーも多く発生します。非効率で労働集約型のプロセスを通じて手動でログ・データを収集・分析し、レポートを集計し、セキュリティ管理とポリシーを維持・検証する労力について考えると、組織の階層レベルによっては、平均コストが1年あたり数十万ドルに達する場合もあるでしょう。

アクセス制御、データ保護、構成管理のポリシーは実装が難しく、実際に維持、管理、および適用するのはさらに困難です。コンプライアンスとセキュリティに関する手続きは時間がかかるか柔軟性に欠けることが多く、現在のダイナミックなビジネス環境で変化するビジネス要件に対応できていません。手動制御、または不完全に実装され管理される制御はコストがかかりエラーも発生しやすく、実際には、セキュリティを大幅に改善することなく、効率的なビジネスの妨げになっています。結果として、個人、ときには部門でさえ、業務を"成し遂げる"ためにポリシーを避けて通ることがあります。驚くまでもなく、多くのデータ侵害は、技術的にはPCI DSSに準拠している組織で起こっています。

組織は、PCIで義務付けられた技術的な要件を満たし、標準の策定目的であるカード会員のデータ保護レベルを達成する、効率的で繰り返しと持続が可能なセキュリティ・プログラムを実現できます。このホワイト・ペーパーでは、要件の中核の大半を構成する重要だが問題のある領域を中心に、PCIコンプライアンス・プログラムの要点について説明します。

• カード会員データを不正使用から保護する

• 特権ユーザーとデータ・アクセスに強力な制御を適用する


3

• 一元化され自動化されたロールベースのアクセス制御、認可、および認証を実装する

• システムとデータベースの監査を提供し、データベース・アクティビティを監視する

データ・セキュリティ、ID管理、構成管理製品からなるオラクルの包括的ポートフォリオは、多層セキュリティ防御を提供することで、12の要件のうちの6つに対応します。残りの要件（1、4、5、9、11、12）はそれぞれ、アンチウイルスとネットワーク・ファイアウォールの導入、パブリック・ネットワークを介したカード会員データの暗号化送信、物理的なセキュリティ管理、テスト、管理者用ポリシーの維持に関係しています。

Oracle製品とPCIソリューションのマッピング

次の表に、顧客のコンプライアンス要件への対応に役立つ、データ・セキュリティ、ID管理、構成管理の各ソリューションについてのオラクルのポートフォリオとPCI DSSの各セクションへのマッピングをまとめます。

章 PCI 3.0 の要件適合するオラクルの機能

セキュアなネットワークおよびシステムの構築と維持

2: システム・パスワードやその他のセキュリティ・パラメータに、ベンダー提供のデフォルト値を使用しないこと

悪意のある人物（企業の内外を問わず）は、ベンダー提供のデフォルト・パスワードやその他のデフォルト設定を使用して、システ

ムに侵入する場合があります。これらのパスワードや設定はハッカー・コミュニティでよく知られており、公開情報を通じて容易に

特定できます。

2.1: システムをネットワーク上に導入する前に、ベンダー提供のデフォ

ルト値を必ず変更し、不要なデフォルト・アカウントは削除または

無効化します。これはすべてのデフォルト・パスワードに当てはま

ります。例としては、オペレーティング・システムやセキュリティ・

サービスを提供するソフトウェア、アプリケーション・アカウント

とシステム・アカウント、point-of-sale （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 Database Lifecycle Management Pack によっ

て、オラクル、顧客ポリシー、業界で広く受け入れられ

たプラクティス（例、セキュリティ技術導入ガイド

（STIG）コンプライアンス標準）に基づく追加設定不

要の構成スキャンが提供されます。

また、Oracle Database Lifecycle Management pack に

よって、Oracle Database の検出、プロビジョニング、

パッチ適用機能が提供されます。


4


2.2.4 誤用を防止するように、システムのセキュリティ・パラメー

タを設定します。 Oracle Database のセキュリティ・ガイドラインに従

います。Oracle Database Lifecycle Management pack を使用して構成を監視します。

Oracle Audit Vault and Database Firewall によって、

Oracle、Microsoft SQL Server、IBM DB2 for LUW、SAP Sybase ASE、Oracle MySQL の各データベースや

Windows、Solaris、Linux の各オペレーティング・シ

ステムから取得した監査データが統合されます。

Oracle Audit Vault and Database Firewall によって

syslog、イベント、監査データについてのレポートおよ

びアラート発行が可能です。

Oracle Database Vault の職務の分離機能により、Oracle Database で不正な管理アクションが実行されることを

防止できます。

2.2.5 スクリプト、ドライバ、機能、サブシステム、ファイル・

システム、不要なWebサーバーをはじめとする、すべての

不要な機能を削除します。

Oracle Databaseのカスタム・インストールでは、特定の

コンポーネントのインストールや削除が可能です。

2.3: 強力な暗号化を使用して、コンソール以外からの管理用アクセスはす

べて暗号化します。Webベースの管理やその他のコンソール以外から

の管理アクセスについては、SSH、VPN、TLSなどのテクノロジーを

使用してください

Oracle Databaseによって提供されるネットワーク暗

号化（TLS/SSLおよびネイティブ）では、中間層とデー

タベース間、クライアントとデータベース間、複数の

データベース間でのSQL*Net経由の通信がすべて暗

号化されます。さらに、管理ツールのEnterprise Managerとそのエージェントでは、通信にTLSプロト

コルがサポートされています。

2.6: 共有ホスティング・プロバイダは、それぞれの事業体のホスト環境および

カード会員データを保護しなければなりません。これらのプロバイダは、

付録A：共有ホスティング・プロバイダ向けのPCI DSS追加要件に詳述さ

れた具体的な要件を満たす必要があります。

付録Aを参照してください。

カード会員データの保護

3: 保存されるカード会員データの保護

暗号化、切捨て、マスキング、ハッシングなどの保護方法は、カード会員データを保護するための重要な要素です。たとえ侵入者がセ

キュリティ制御を巧みに逃れて、暗号化されたデータにアクセスできたとしても、正しい暗号化キーがなければ、データを読み取り、

使用することはできません。保管したデータを保護するその他の効果的な方法は、潜在的なリスク軽減の機会として考える必要があり

ます。たとえば、リスクを最小化する方法には、絶対に必要でない限りカード会員データを保存しないこと、プライマリ・アカウント

番号の全桁が必要でない場合はデータの端を切り捨てること、エンドユーザーのメッセージング・テクノロジー（電子メールやインス

タント・メッセージングなど）を使用して、保護されていないプライマリ・アカウント番号を送信しないことが挙げられます。

"強力な暗号化"およびその他の PCI DSS 用語の定義については、『PCI DSS Glossary of Terms, Abbreviations, and Acronyms』を参照

してください。


5


3.3: プライマリ・アカウント番号は全体を表示させないようにして（最大で

も、最初の 6 桁と最後の 4 桁のみを表示）、業務において正当な必要性

のある担当者のみがプライマリ・アカウント番号全体を参照できるよう

にします。

注：この要件は、カード会員データの表示について、さらに厳しい要件

が適用されている場合（例：POS レシートに対する法的要件やクレジッ

ト・カード・ブランドの要件など）に、その要件に取って代わるもので

はありません。

Oracle Advanced Security の Data Redaction は、アプ

リケーションのユーザー・インタフェースに表示され

るデータを一貫してマスクします。

また、アプリケーションで Virtual Private Database（VPD）の列関連ポリシーを利用して、番号全体を非

表示にできます。

Oracle Data Masking and Subsetting によって、非本

番環境でテストや QAのために使用される本番データ

が保護されます。

Oracle Label Security が提供するセキュリティ制御

を使用すると、誰がプライマリ・アカウント番号に

アクセスできるかを決定できます。

Oracle Database Vault のレルムを使用して、特権ユー

ザーによるアプリケーション・データへのアクセスを


3.4: プライマリ・アカウント番号は、どこに保管されていても（携帯デジ

タル・メディア、バックアップ・メディア、ログなど）、次のいずれ

かの手段を使用して判読不可能な状態にしておきます。

• 強力な暗号化技術に基づくワンウェイ・ハッシュ（プライマリ・

アカウント番号全体をハッシュする）

• 切捨て（ハッシングを使用してプライマリ・アカウント番号

の切捨て部分を置換することはできない）

• インデックス・トークンおよび PAD（PAD はセキュアに保存）

• 関連するキー管理のプロセスと手順による強力な暗号化手法

注：悪意のある人物が切り捨てられた番号とハッシングされた番号の両方

にアクセスできる場合、元のプライマリ・アカウント番号を復元すること

は比較的簡単です。同じプライマリ・アカウント番号に対してハッシング

された番号と切り捨てられた番号が同じ組織環境内に存在する場合、ハッ

シングされた番号と切り捨てられた番号を関連付けて元の番号を復元で

きないようにするため、追加の制御を適用する必要があります。

Oracle Advanced Security の Transparent Data Encryption（TDE）、列暗号化、表領域暗号化を使用

すると、データベース内のプライマリ・アカウント番

号を透過的に暗号化してストレージ・メディアにバッ

クアップできます。注：Advanced Security は、ディ

スクの暗号化に対して別の論理的なアクセスを義務

付ける要件 3.4.1 の影響を受けません。

Oracle Advanced Security の TDE にはキー管理が組

み込まれています。暗号化されたデータは、データ・

ファイル、REDO ログ、UNDO 表領域、TEMP 表領

域、バックアップ内でも暗号化されたままです。

Oracle RMAN を Oracle Advanced Security と併用す

ると、ディスクへのバックアップ時にディスク・バッ

クアップ全体を暗号化（および圧縮）できます。

Oracle Advanced Security の Oracle Data Pump に

よって、ソース・データベースのマスター暗号化

キー、または受信者と安全に共有できるパスフレー

ズのいずれかを使用して、データベースのエクス

ポート・ファイル全体を暗号化（および圧縮）でき

ます。

Oracle Secure Backupは、テープ・ストレージに直

接バックアップおよび暗号化するソリューションを

提供しています。

サポートされる暗号化アルゴリズムは、256 ビット、

192 ビット、または 128 ビットのキー長を持つ AESと 3DES168 です。


6


3.5: 保存されたカード会員データを漏洩や誤用から保護するために使用

されたキーの保護手順をドキュメント化し、実装します。

注：この要件は、保存されたカード会員データの暗号化に使用された

キーと、データ暗号化キーを保護するために使用されたキー暗号化

キーに適用されます。このようなキー暗号化キーは、少なくともデー

タ暗号化キーと同じ強度を持つ必要があります。

Oracle Advanced Security TDEの表キーおよび表領

域キーは、別のマスター・キーを使用して暗号化され

た状態でデータベースに保管されます。このマス

ター・キーは、オペレーティング・システム上の

PKCS#12ファイルであるOracle Wallet、または安全

なキー管理システムであるOracle Key Vaultに保存さ

れています。Oracle Walletは、ウォレット・パスワー

ド（PKCS#5に基づく）を使用して暗号化されていま

す。データベース内からウォレットを開くには、'alter system'権限が必要です。

Oracle Database Vault のコマンド・ルールを利用す

ると、さらに、誰が、いつ、どこから、'alter system'コマンドを実行できるかを制限できます。

3.5.1 暗号化キーへのアクセスは、必要最小限の管理者に制限し

ます。 Oracle Key Vaultによってマスター暗号化キーへのア

クセスが不要になります。

指定された担当者（DBAやデータベース・セキュリ

ティ管理者DSA）は、Oracle Key VaultまたはHSMの

認証文字列を使用する場合、ウォレット・パスワード

（知識分割が可能）または仮想ウォレット・パスワー

ドを要求される可能性があります。

暗号化データを正規のユーザーやアプリケーション

で利用できるようにウォレットを開いてマスター暗

号化キーをデータベースで有効にするための 'alter system’権限がウォレットを開くデータベース・ユー

ザーに必要です。

手動による操作なしに（’完全自動’操作）データベー

スの可用性を維持する必要がある場合は、ウォレット

をオートオープンに設定できます。このモードでは

ウォレットは自動的に開かれ、余分な手順なしにマス

ター暗号化を利用できます。

Oracle Database Vaultのコマンド・ルールを実装す

ると、誰が、いつ、どこから、'alter system'コ

マンドを実行できるかを制限できます。

3.5.2 カード会員データの暗号化/復号化に使用する秘密鍵は、常

に次のいずれかの形式で保存します。

• 少なくともデータ暗号化キーと同じ強度を持つ、デー

タ暗号化キーとは別の場所に保管されているキー暗

号化キーで暗号化された状態。

• セキュアな暗号化デバイス（ハードウェア・セキュリ

ティ・モジュール（HSM）や PTS 認可の加盟店端末

装置など）内。

• 業界で認められた方式に従う、少なくとも 2 つの全

長キー要素またはキー共有として。

注：公開鍵を上記の形式で保管する必要はありません。

マスター暗号化キーは、各データベースに 1 つだけ

存在します。一元的にマスター暗号化キーを管理す

るため、このキーを Oracle Wallet、Oracle Key Vaultまたは HSM デバイスに保管できます。


7


3.5.3 暗号化キーの保管場所を可能な限り少なくします。 Oracle データベースで TDE を使用する場合、Oracle Key Vault によって専用ネットワーク接続を利用した

TDE マスター・キーの一元管理が可能になり、ローカ

ルのウォレット・ファイルを複数のエンドポイントに

コピーする必要がありません。

ウォレットのコピーをローカルに保存するのではなく、

TDE マスター・キーを共有する方法は、TDE をデータ

ベース・クラスタで実行している場合に特に有効です。

Oracle Key Vault によって提供される共有 TDE キーを

使用すると、新しい TDE マスター・キーはキー・ロー

テーション操作の後、ただちにクラスタの他のノードと

共有されるため、ウォレットを手動でコピーする必要が

ありません。

一元管理はOracle Data Pump エクスポート/インポート、

またはトランスポータブル表領域を使用してデータベー

ス間で暗号化データをコピーする場合にも有効です。

3.6.1 強力な暗号化キーの生成 Oracle Advanced Security TDE は業界で定評のある

ライブラリを利用して、強力な暗号化キーを生成し

ます。Oracle Key Vault を使用する場合、マスター

暗号化キーの管理と保管は Oracle Key Vault によっ

て行われます。

3.6.2 セキュアな暗号化キーの配布 Oracle Advanced Security は、広く知られた

Diffie-Hellman 鍵交換アルゴリズムを使用してセキュ

アなキーを配布します。

3.6.3 セキュアな暗号化キーの保管 Oracle Advanced Security TDE の列キーおよび表領域

キーは、Oracle Wallet、Oracle Key Vault、または 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.1: セキュリティ脆弱性に関する外部の信頼できる情報源を使用して、セ

キュリティ脆弱性を特定するプロセスを確立し、新たに検出したセキュ

リティ脆弱性にリスク・ランキング（例："高"、"中"、"低"）を割り当て

ます。

注：リスク・ランキングは、業界のベスト・プラクティスと潜在的な

影響を考慮して決定する必要があります。

オラクルは Critical Patch Updates（CPU）でリリースさ

れるバグ修正の重大度を評価する際、 Common Vulnerability Scoring System（CVSS）に従っています。

http://www.oracle.com/technetwork/topics/security/cvssscoringsystem-091884.html

Oracle Critical Patch Updates、Security Alerts、Third Party Bulletinに関するRSSフィードに登録してください





8


6.2: すべてのシステム・コンポーネントとソフトウェアを既知の脆弱性から

保護するため、ベンダーが提供するすべてのセキュリティ・パッチをイ

ンストールします。重要なセキュリティ・パッチは、リリース後1カ月

以内にインストールします。

Oracle Database Lifecycle Management packによっ

て、Oracle Databaseの検出、プロビジョニング、パッ

チ適用機能が提供されます。競合の有無がチェックさ

れ、パッチの大規模配布が可能になります。

顧客のポリシーとプロセスの問題。オラクルは四半期

ごとにCritical Patch Updatesを提供しており、ほとんど

の場合、顧客は30日以内にこれを実装できます。

6.4: 6.4.1 開発/テスト環境を本番環境から切り離し、アクセス制御の分

離を適用します。これはインフラストラクチャを何にするかの問題で

す。仮想化（Oracle VM）、Solaris Logical Domains、または個別のハードウェア・インフラストラクチャで

も本番環境から開発、テスト環境を分離することは可

能です。

Oracle Exadata、Oracle SuperCluster、Oracle Exalogicによってこの分離を実現する方法が提供されます。

Oracle Identity Governance Suiteに含まれるOracle Privileged Account Managerは、権限の分離を可能にし、

特権カウントに対するセルフサービス式のリクエスト

を管理し、パスワードの使用に関する監査とレポート

作成機能を提供します。

Oracle Database Vaultを使用すると、Oracleデータベー

ス内の本番データへのDBAによるアクセスを保護でき

ます。

6.4.3 テストまたは開発環境では、本番データ（実際のプライマ

リ・アカウント番号）は使用しません。 Oracle Data Masking and Subsetting packはテスト環

境や開発環境向けに、クレジット・カード番号やその

他の機密情報を識別不能にします。

6.4.5 セキュリティ・パッチとソフトウェア変更の実装に対する変

更管理手順には、次が含まれている必要があります。

6.4.1 影響のドキュメント化

6.4.2 権限を持つ関係者によるドキュメント化された変

更の承認

6.4.3 該当する変更がシステム・セキュリティに悪影響を

与えないことを検証するための機能テスト

6.4.4 バック・アウト手順

Oracle Database Lifecycle Management Packを利用す

ると、データベース変更管理手順とパッチ適用を自動

化できます

Real Application Testingによって、SQLのリグレッショ

ンやデータベース（または、OSやストレージのような

下位レイヤー）のパラメータや構成の変更による影響

がないか検証するフレームワークが提供されます。


9


6.5: 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 Audit Vault and Database Firewall でアプリケーションがデータベースに送信して

実行する SQL トラフィックに基づくホワイトリストを

作成できます。通常のトラフィックに合致しない SQL文はすべてブロックできます。

Oracle Advanced Security TDE のマスター暗号化キー

は暗号化ファイル（Oracle Wallet）に保管されており、

Oracle Wallet は PKCS#5 標準に基づいて、または

Oracle Key Vault でパスフレーズ（ウォレットの'パス

ワード'）によって暗号化されています。

TDE マスター暗号化キーを HSM に保管すると、さらに

高い確実性（FIPS 140-2 Level 3 の検証）が得られます。

Oracle Database Standard Edition および Enterprise Editionでは、TLSを使用して、Oracleデータベースに対

するネットワーク接続を暗号化できます。

6.5.1 インジェクションを利用した不正、特に SQL インジェクショ

ン。また、OS コマンド・インジェクションや LDAP インジェ

クション、Xpath インジェクション、およびその他のインジェ

クションによる不正も考慮に入れます。

6.5.3 セキュリティで保護されていない暗号化ストレージ。

6.5.4 セキュリティで保護されていない通信。


10


強固なアクセス制御手法の導入

7: カード会員データへのアクセスを業務上の必要範囲内に制限すること

権限を与えられた担当者のみが重要なデータにアクセスできるように、システムおよびプロセスを利用して、職責に応じたアクセスと必

知事項に基づくアクセスに制限する必要があります。

"必知事項"とは、職務の実行に必要な最小限のデータと権限に対してのみ、アクセス権が付与される状態を指します。

7.1: システム・コンポーネントとカード会員データへのアクセスを、業務上必要な担当者に限定します。

7.1.1

次を含むアクセス要件をロールごとに定義します。

• 各ロールが職務を遂行するためにアクセスを必要とす

るシステム・コンポーネントとデータ・リソース

• リソースへのアクセスに必要な権限レベル（ユーザー、

管理者など）

Oracle Database Vault：

• レルムによって特権ユーザーや DBAによるア

プリケーションやカード会員データに対する

アクセスが制限されます。

• ルール・セットを使用すると、動的にアクセス

権を決定できます。

• ファクタとコマンド・ルールは、アプリケー

ション、データ、およびデータベースへのアク

セスに対する厳密な制御を適用します。

• 職務の分離機能は、Oracle Database で不正な管

理アクションが実行されることを防止します。

• 権限分析を実行することで最小権限の原則が

適用できます

Oracle Label Security は必知事項や"最小権限"の要件に

基づく追加のセキュリティ属性を提供します。

Oracle Data Redaction は、組織と規制に関するポリシー

と要求者の権限の組み合わせに基づいて、機密性の高い

アプリケーション・データ・フィールドを削除またはマ

スクします。

Oracle Virtual Private Database は基本的な実行時のマ

スキング機能を提供します。

Oracle Database のオブジェクト権限とデータベース・

ロールにより、基本的なセキュリティが提供されます。

Oracle Identity Governance Suite は、許可されたコン

ピューティング・リソースとアプリケーション・リソー

スおよびデータにのみエンタープライズ・ユーザー・プ

ロビジョニングを提供します。

Oracle Identity Analytics は、ジョブと機能の詳細な定義

を提供するためのロールと短期の割当てを定義します。

7.1.2 特権ユーザーID に付与されるアクセスを、職責を果たすため

に必要な最小限の権限に制限します。

7.1.3 個々の担当者の職種と職務に基づいてアクセスを割り当てます。


11


7.2: 複数のユーザーを持つシステム・コンポーネントの場合、ユーザーの必

知事項に基づいてアクセスを制限し、個別に許可されない限り"すべて拒

否"に設定するアクセス制御システムを確立します。

このアクセス制御システムには次が含まれる必要があります。

Oracle Database Vault のレルムを利用すると、特権ユー

ザーやDBAによるアプリケーション・データおよびカー

ド会員データへのアクセスを制限できます。

Oracle Database Vault のファクタとコマンド・ルール

は、アプリケーション、データ、およびデータベースへ

のアクセスに対する厳密な制御を実現します。

Oracle Database Vault の職務の分離機能により、Oracle Database で不正な管理アクションが実行されることを


Oracle Database の必須レルム制御を利用すると、アプ

リケーション・オブジェクトへのアクセス（オブジェク

ト所有者などの直接付与されるオブジェクト・アクセス

権限を含む）を制限できます。

Oracle Database Vault で権限分析を実行することで最

小権限の原則が適用できます。

Oracle Label Security は、必知事項を特定する追加のセ

キュリティ属性を提供します。

Oracle Virtual Private Database は基本的な実行時のマ

スキング機能を提供します。

Oracle Data Redaction は、組織と規制に関するポリシー

と要求者の権限の組み合わせに基づいて、機密性の高い

アプリケーション・データ・フィールドを削除またはマ

スクします。



Oracle Access Management Suite は、一元化されたアク

セス制御、認可、および認証を提供します。

Oracle Identity Governance Suite は、ロール、職務、部

門、場所、その他の変数に基づき、許可されたコンピュー

ティング・リソースとアプリケーション・リソースおよ

びデータに対してのみエンタープライズ・ユーザー・プ

ロビジョニングを提供します。この機能は HR（HCM）

システムから自動的に開始できます。

Oracle Identity Analytics は、ジョブと機能の詳細な定義

を提供するためのロールと短期の割当てを定義します。

7.2.1 すべてのシステム・コンポーネントを対象に含めること

7.2.2 職種と職務権限に基づいて担当者に権限が割り当てられてい

ること

7.2.3 デフォルトは"すべて拒否"に設定すること

8: システム・コンポーネントに対するアクセスの識別と認証

アクセスを持つユーザーごとに一意の識別子（ID）を割り当てることで、各ユーザーが自分の行動に独自の責任を負うようにします。この

ような責任が課されている場合、重要なデータやシステムに対する操作が、既知の認可ユーザーおよびプロセスによって実行されているこ

とを確認できるだけでなく、操作からユーザーにさかのぼって追跡できるようになります。

特に、攻撃者がパスワードを試行する頻度や、送信中、保存中にエントリ・ポイントでユーザー・パスワードを保護するセキュリティ手法

によって異なります。

注：これらの要件は、管理機能を持つすべてのアカウント（POSアカウントを含む）と、カード会員データの参照とアクセス、またはカー

ド会員データを含むシステムへのアクセスに使用されるすべてのアカウントに当てはまります。これには、ベンダーやその他の第三者（サ

ポートや保守用）によって使用されるアカウントも含まれます。ただし、1度に1つのカード番号のみにアクセスして単一トランザクション

を実行するPOS支払いアプリケーション内のユーザー・アカウント（レジ係のアカウントなど）に対して、要件8.1.1、8.2、8.5、8.2.3から

8.2.5、8.1.6から8.1.8は適用されません。


12


8.1: すべてのシステム・コンポーネント上で、非消費者ユーザーと管理者に

対して適切なユーザーID管理を徹底するためのポリシーと手順を定義

し、実装します。

Oracle Database の認証機能は、専用ユーザー・アカウン

トと Kerberos を含む強力な認証機能をサポートします。

Oracle Identity Governance Suite は自動ワークフローと

集中リポジトリを使用したエンタープライズ・ユー

ザー・プロビジョニングを提供します。ユーザーがアク

ティブでなくなると、自動的にプロビジョニングが解除

されます。特権アクセスはワンタイム・パスワード

（OTP）を使用した例外ベースで管理する必要がありま

す。特権アクセスやサポート・アクセスを詳細に監視す

ることで、担当者が許可されたアクティビティのみを実

行するように徹底できます。

Oracle Access Management Suite は、一元化されたアプ

リケーション・レイヤーのアクセス制御、認可、および

認証を提供します。

Oracle Identity Governance Suiteに含まれるOracle Privileged Account Managerは、パスワードの生成、パ

スワードのプロビジョニング、パスワードへのアクセス

管理を行うセキュアなパスワード管理ソリューション

です。アクセス試行が繰り返された場合はアカウントの

ロックアウトを起動でき、試行回数と修正プロセスは設

定が可能です。

8.1.1 システム・コンポーネントまたはカード会員データへのアク

セスを許可する前に、すべてのユーザーに一意の ID を割り当

てます。

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 要素認証が提供されます。また、リアルタイ

ム・リスク分析を実行し、さらなる認証が必要かどうか

を判断します。

8.2.2 送信中やすべてのシステム・コンポーネントに保管中のあら

ゆる認証資格証明（パスワードやパスフレーズなど）は、強

力な暗号化を使用して判読不可能な状態にします。

Oracle Database はデータベースのユーザーID とパス

ワードを組み合わせたハッシュを作成し、このハッシュ

は認証プロセス内でレコード・ハッシュと比較されます。

Oracle Privileged Account Manager によって管理される

パスワードとメタデータ情報は、Oracle データベース内

に暗号化された状態で永続化されます。

Oracle Database は、Oracle Advanced Security の

Transparent Data Encryptionを使用して暗号化できます

Oracle Database によって、ネットワーク暗号化（TLS）と強力な認証が提供されます


13


8.2.3 パスワード/パスフレーズは次の条件を満たす必要があります。

• 最小の長さは、少なくとも 7 文字以上にします。

• 数字と英字の両方を含みます。

別の方法として、パスワード/パスフレーズが、上記で指定し

たパラメータと少なくとも同等の強度および複雑さを持つ必

要があります。

Oracle Access Manager には、PCI DSS 3.0 の複雑さ要

件を満たすポリシーが設定されたセルフサービス式の

パスワード・リセット機能が含まれています。

Oracle Database を使用するとパスワード検証機能を設

定でき、新しいパスワードや変更されたパスワードが、

パスワードを推測してシステムに忍び込もうとする侵入

者を阻止するのに十分複雑であることが保証されます

8.2.4 ユーザー・パスワード/パスフレーズは、少なくとも90日ごと

に1回は変更します。 Oracle Database profiles

Oracle Identity Manager

Oracle Access Manager

8.2.5 直近4回で使用されたパスワード/パスフレーズは、新しいパ

スワード/パスフレーズとして使用できないようにします。 Oracle Database profiles

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 Database によって 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 Audit Vault and Database Firewallによっ

てユーザー権限を検証する機能が提供されま

す。データベース監査機能は、ログインやログ

アウトを追跡するために有効化する必要があり

ます。

Oracle Identity Governance Suite

8.7: カード会員データを保管しているデータベースへのアクセス（アプリ

ケーション、管理者、その他すべてのユーザーによるアクセスを含む）

は次のとおりに制限します。

• データベースに対するすべてのユーザー・アクセスとユー

ザー問合せ、ユーザー・アクションは、プログラム的な手

法を介して実施します。

• データベース管理者のみが、データベースへの直接アクセ

スまたは問合せを実行できます。

• データベース・アプリケーションのアプリケーション ID を

使用できるのはアプリケーションのみです（個人ユーザーや

その他の非アプリケーション・プロセスは使用できません）。

Oracle Database の認証機能

プログラム的な手法でデータにアクセスする

ストアド・プロシージャの使い方。

Oracle Database Vault を使って特権ユーザーに

よるカード会員データの問い合わせを防止でき

ます。

Kerberos、PKI、RADIUS サポート、Oracle Identity Governance Suite、Oracle Database Valid Node Checking


14


定期的なネットワークの監視およびテスト

10: ネットワーク・リソースおよびカード会員データへのすべてのアクセスを追跡し、監視すること

データの検出を阻止したり、データ侵害の影響を最小化したりするために、ロギング・メカニズムとユーザー・アクティビティの追

跡機能は重要です。すべての環境にログが存在することにより、何らかの不都合が起きても詳しい追跡、アラート通知、分析が実行

できます。システム・アクティビティ・ログがない場合、セキュリティ侵害の原因解明が不可能になるか、または非常に難しくなり

ます。

10.1: 監査証跡を実装して、システム・コンポーネントに対するすべてのアク

セスを各個人ユーザーに関連付けます。（顧客の内部ポリシー）、専用の DBA アカウントをデー

タベースに作成し、Oracle Database の監査機能を有効

にします。

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: 次のイベントを復元できるように、すべてのシステム・コンポーネン

トに対して自動監査証跡を導入します。（個別の対応については以下を参照）

10.2.1 カード会員データに対する、個人ユーザーによるすべてのア

クセス Oracle Database Auditing、カード会員データに対する

Oracle Databaseの監査機能とOracle Databaseのファ

イングレイン監査（FGA）、Oracle Audit Vault and Database Firewallのレポートおよびアラート

Oracle Database Conditional Auditingは選ばれたイベ

ントに焦点を合わせることで、監査に関する負荷を軽

減します。


Oracle Access Management Suite監査レポート


15


10.2.2 root権限または管理者権限を持つ個人が行ったすべての操作 Oracle Audit Vault and Database Firewall によってデー

タベースとオペレーティング・システムの監査ログが収

集され、セキュアなウェアハウスに統合されます。

Oracle Audit Vault and Database Firewall の監査データ

統合により、エンタープライズ・レポートとエンタープ

ライズ・アラートが提供されます。

データベースに専用の DBA アカウントを作成します。

任意でプロキシ認証を使用すると、DBA 権限を持つアカ

ウントの数を制限しながら監査を実現できます。

Oracle Database Vault のレルムと職務の分離機能によ

り、データベース管理をより厳格に制御できます。

Oracle Database Vault のレルム・レポート、


Oracle Access Management Suite 監査レポート、

Oracle Identity Analytics

10.2.3 すべての監査証跡へのアクセスデータベースの監査データは Audit Vault Server に集約

され、元のサーバーから削除できます。

Oracle Access Management Suite、Oracle Identity Analytics、および Oracle Identity Governance Suite 監査

レポート

10.2.4 無効な論理的アクセス試行 Oracle Database Vault では、機密データを持つオブジェ

クトへのアクセス試行は成功したものも失敗したもの

も監査証跡に記録されます。

標準のデータベース監査は、失敗したログイン試行を監

査します。

Oracle Access Management Suiteはn回の不正なログイン

試行後にロックアウトを実行し、監査証跡を作成します。

Audit Vault and Database Firewall は、特権ユーザーによる

無効な論理アクセス試行に対してアラートを通知します。

10.2.5 ID および認証メカニズムの使用と変更（新規アカウントの作

成とより高い権限の付与などが含まれますが、この限りでは

ありません）、ルート権限や管理者権限を使用したアカウン

トの変更、追加、削除のすべて

Oracle Database の認証と監査

Oracle Advanced Security の Kerberos、PKI、 RADIUS 認証

Oracle Database Vault によって職務分掌を設定できま

す。セキュリティ管理者のプロファイルを割り当てられ

たユーザーが、DBA や SYSDBA に代わってユーザー・

アカウントを作成します。

Oracle Audit Vault and Database Firewall のエンタイト

ルメント・レポート

Oracle Access Management Suite 監査レポート、

Oracle Identity and Access Management Suite、

Oracle Audit Vault and Database Firewal

10.2.7 システムレベル・オブジェクトの作成と削除 Oracle Database の監査機能


16


10.3: すべてのシステム・コンポーネントで、イベントごとに少なくとも次の

監査証跡を記録します。

10.3.1 ユーザーID Oracle Database の監査機能


統合、レポート、アラート、および保護

Oracle のクライアント識別子による、単一接続での ID伝播

Oracle Access Management Suite監査レポート

10.3.2 イベントのタイプ

10.3.3 日付と時刻

10.3.4 成功または失敗の表示

10.3.5 イベントの起点

10.3.6 影響を受けたデータ、システム・コンポーネント、リソース

の識別子または名前

10.5: 監査証跡は、改変できないように保護します。

OSとデータベースの監査証跡は、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 の職務の分離

機能は、管理者（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 が提供するス

ケーラブルでセキュアな監査ウェアハウスを使用する

と、大容量（テラバイト）の監査データを保管できます。

Oracle Audit Vault and Database Firewall でデータの保

存方針（アーカイブ）を設定して監査データの保管期

間を決定できます。

セキュアなターゲット用のデータ保存方針によってター

ゲットに関する監査データの保管期間が決定されます。


17


付録A：共有ホスティング・プロバイダ向けのPCI DSS追加要件

A：共有ホスティング・プロバイダは、カード会員データ環境を保護すること

要件12.8および12.9の記述のとおり、カード会員データにアクセスできるすべてのサービス・プロバイダ（共有ホスティング・プロバイ

ダを含む）は、PCI DSSを遵守しなければなりません。さらに、要件2.6には、共有ホスティング・プロバイダはそれぞれの事業体のホス

ト環境やデータを保護しなければならない、とあります。したがって、共有ホスティング・プロバイダは、この付録に記載されている要

件についても遵守しなければなりません。

A.1: A.1.1からA.1.4にあるとおり、それぞれの事業体（加盟店、サービス・プロバイダ、その他の事業体）のホスト環境とそのデータ

を保護します。

ホスティング・プロバイダは、PCI DSSにおけるその他の該当部分に加えて、これらの要件を満たす必要があります。

注：ホスティング・プロバイダがこれらの要件を満たしていても、そのホスティング・プロバイダを利用している事業体の準拠が

保証されるわけではありません。それぞれの事業体が、PCI DSS に準拠し、その準拠状況を検証しなければなりません。

A.1.1

それぞれの事業体は、その事業体のカード会員データ環境に

アクセスするプロセスのみを実行します。 Oracle Database Vault：

• レルムは、高特権ユーザーやDBAによるアプリケー

ション・データおよびカード会員データへのアクセ

スを制限します。

• ファクタとコマンド・ルールは、アプリケーション、

データ、およびデータベースへのアクセスに対する

厳密な制御を適用します。

• 職務の分離機能は、Oracleデータベースで不正な管

理アクションが実行されることを防止します。

Oracle Label Security は、必知事項を特定するために行

レベルの特権ユーザー制御を提供します。

Oracle Virtual Private Database は、必知事項に基づいた

基本的な実行時マスキング機能を提供します。

Oracle Advanced Security Data Redaction はアプリケー

ションに表示された機密データを削除します。



Oracle Identity Governance Suite は、コンピューティン

グ・リソースへのエンタープライズ・ユーザー・プロビ

ジョニングを提供します。


18


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 BI Publisher、またはサード

・パーティ

製のツールを使用して生成できます。Oracle Audit Vault and Database Firewall では、ウェアハウス・ス

キーマが公開されています。


19

PCIデータ保護の課題

危険にさらされているカード会員データ

PCI DSSは、組織にカード会員データを保護することを要求しています。基本的に、プライマリ・アカウント番号（PAN）、カード会員名、サービス・コード、有効期限がカード番号とともに保管される場合（実際のビジネスで使用される場合、通常は一緒に保管される）、これらはカード会員データの対象となります。

加盟店が手動デバイスでカードの刻印のカーボン・コピーを取るようになって以来、この情報は、犯罪者にとって非常に重要な情報となっています。今日、外部のハッカーや悪意あるインサイダーが、バックエンド・データベースに格納された数百万というクレジット・カード・レコードを取り込み、それらを国際的なインターネット上のブラック市場で販売したり、それらの情報を使用して高額商品を購入したりする可能性があります。

不正な、あるいはより一般的には不必要なデータベースやオペレーティング・システムへのアクセスによって、データベース管理者やシステム管理者などの信頼できる特権ユーザーをはじめ、この情報にアクセスしたり確認したりする必要のない開発者やその他の従業員に対してまで、カード会員データが公開されてしまいます。欠陥のある展開やその後のエラーの結果生じた安全でないデータベース構成では、カード会員データが盗難される可能性がかなり高くなります。

暗号化の発達

データ暗号化は、企業のPCIコンプライアンス・プログラムにとって不可欠な要素です。ただし、明らかなセキュリティ上のメリットにもかかわらず、企業はパフォーマンスへの影響や管理の難しさを理由に暗号化を避けてきた過去があります。これはプロジェクトの中断や安全でない脆弱な実装の原因となっていました。特に、暗号化プロジェクトには、キー管理の問題が付きまとっていました。ネイティブまたは独自の暗号化ソリューションは、通常、組織に応じて拡縮しないため、会社は停止時、稼働中、バックアップ時にデータを処理するために複数のツールの組み合わせを使用しなければならない場合があります。さらに、独自またはつぎはぎのソリューションでは、データベース通信のセキュリティをより堅牢にするために、強力な認証を組み込むという課題に直面することは必至です。

PCI DSSおよびその他のコンプライアンスの要件により、環境は永続的に変化してきました。問題は、暗号化するかどうかではなく、どのように安全でスケーラブルかつ管理可能な方法で暗号化するかということです。

Oracle Databaseのリダクションおよび暗号化ソリューション

Oracle Advanced Securityは、アプリケーションに対する機密データのリダクションとストレージやバックアップ・メディアに保管中のデータの暗号化を含む予防的なセキュリティ制御を提供します。

要件3.3では組織に対し、”プライマリ・アカウント番号は全体を表示させないようにして、業務において正当な必要性のある担当者のみがプライマリ・アカウント番号全体を参照できるようにする”ことを命じています。スマートフォン・デバイスやタブレット・デバイスの保有により、機密データ公開の問題の緊急性が増しています。従来のオフィス環境以外でのデータ・アクセスが一般的になっているためです。従来のアプリケーションでも、機密データの公開を減らすためのより包括的なソリューションが必要です。たとえば、顧客のクレジット・カード情報や個人を識別できる情報が、


20

コール・センターのオペレーターに対して画面表示されるコール・センターのアプリケーションを考えてみましょう。

Oracle Advanced SecurityのData Redactionでは、データベースの問合せ結果内の機密データがアプリケーションで表示される前に、選択的にその場でリダクション（マスキング）を実行できます。このため、未承認ユーザーが機密データを見ることはできません。

また、要件3.4は、"プライマリ・アカウント番号は、どこに保管されていても判読不可能な状態にしておく"ことを組織に命じています。いくつかのオプションがありますが、"関連するキー管理のプロセスと手順を伴う、強力な暗号化手法"はデータ・ストア内のカード会員データを保護するための論理ソリューションで、堅牢な自動化されたツールを使用して企業規模のデータ保護を処理します。

Oracle Advanced SecurityのTransparent Data Encryption（TDE）は、透過的に、ディスクに書き込まれた時点でデータを暗号化し、ユーザーが正常に認証および認可された後に、それを復号化します。TDEはデータベースを迂回し、ファイルに直接アクセスしようとする試行を阻止します。Oracleは、特定の機密列のTDE列暗号化による暗号化、またはアプリケーション全体のTDE表領域暗号化による暗号化を透過的にサポートしています。

マスター暗号化キーはOSのキーストア、Oracle Key Vault、またはHSM内に保存できます。

稼働中のデータの保護

Oracle Databaseは、データ・スニフィング、データ損失、再生、PIM（Person-In-the-Middle）攻撃などを阻止することで、データのプライバシーと機密性を保持しながら、Oracle Databaseとの通信を保護します。ネイティブのネットワーク暗号化と、PKIインフラストラクチャを保持している企業向けのTLSベースの暗号化の両方を提供します。PCI-DSS 3.1では、現在データ保護にSSLを使用できません。TLS 1.1や1.2であれば十分ですが、TLS 1.2の方が推奨されており、Oracle Databaseでは両方ともサポートされています。Oracle Databaseでは、データを暗号化しないクライアントからの接続を拒否するように設定できます。または、柔軟な展開を実現するために、暗号化されていない接続を任意で許可することもできます。

バックアップ・データの保護

PCIでは、テープやその他のバックアップ・メディアの紛失または盗難から保護するために、カード会員情報のバックアップを暗号化することが求められています。

既存のバックアップ手順では、TDEを使用して保護された表領域は暗号化された状態でバックアップされ、TDE列暗号化を使用して保護された表の列は、自動的にバックアップ・メディア上で暗号化されたままになります。SYSTEM表領域を含むすべてのデータベース・ファイルの暗号化は、Oracle Recovery Manager（Oracle RMAN）およびTDEを一緒に使用して実行できます。Oracle RMANは、TDE暗号化アルゴリズムとマスター暗号化キーを使用してデータベース・バックアップ全体を暗号化する機能を提供します。

さらに、Oracle Secure Backupはテープを暗号化し、一元化されたテープ・バックアップ管理を提供します。


21

マスクされたデータの使用

カード会員情報とその他の本番データは開発およびテスト作業にとって重要であるため、カスタマ・サポートや開発者、QA担当者などに大量のカード会員データが渡される可能性があります。PCI要件ではこれらの担当者がカード会員情報を参照することを許可していません。要件6.4.3項では特に、実際のプライマリ・アカウント番号を開発用に使用することを禁止しています。このような使用例を減らすため、開発者はときどき、本番データをシミュレートするために仮のデータを生成しますが、特にテスト目的の場合、この処理が常に信頼できるとは限りません。

このような場合は、目に見えるデータによって、セキュリティやプライバシーが侵害されないように、情報をマスクします。データ・マスキングは、フィールドの数やタイプに関係なく、データ形式を保持しながら、実際の値を偽の値で置き換えます。

ただし、企業内に多数の新しい継続中の開発プロジェクトが存在し、PCIやその他の規制要件が課せられている場合、自動ツールを使わないデータ・マスキングは困難になることがあります。

Oracle Data Masking and Subsetting Packは、クレジット・カード番号と関連付けられたカード会員情報を現実的でありながら偽の値と置き換えることで、トランザクション、開発、テストを目的に、またはその他の本番以外の目的でアウトソース・パートナーやオフショア・パートナーと共有するために、本番データを安全に使用できるようにします。Oracle Data Masking and Subsetting Packはアプリケーションが引き続き正しく動作するように、テンプレートと形式ルールのライブラリを使用して一貫したデータ変換を行うことで、参照整合性を維持します。

キー管理の解決

暗号化の弱点

従来から、データの可用性を維持しながら暗号化キーを生成し保護することは、特に企業規模で暗号化を実装する上での大きな障壁となっていました。

キー管理は、発行、保管、および更新が困難なため、複雑で難易度が高く、失敗することもあります。さらに悪いことに、キーを紛失すると、重要なデータを永遠に回復できない可能性があります。

ITマネージャーがより急を要する優先事項に気をとられ、業務側からキー管理の制御を緩めるように圧力がかかると、キー管理があってもないに等しいセキュリティ制御になってしまうことがよくあります。結果として、キーは複数のユーザーが広く使用できるようになり、暗号化は役に立たないものになってしまいます。


22

キー管理に対するPCI要件

PCI標準では、要件3.5および3.6で、キー管理について詳しく述べています。3.5項では、キーの不正使用によるカード会員データへのアクセスを防ぐため、キーを強力に保護することを要求しています。特に、組織は、キーへのアクセスを可能な限り少数のユーザー（キー管理者）に制限し、可能な限り少数の場所にキーを安全に保管する必要があります。3.6項では、次の考慮事項を含めたキーの実装について詳しく述べています。

• 強力な暗号化キーの生成

• セキュアなキー配布（クリアテキストを使用せず、キー管理者のみに配布）。

• セキュアな暗号化されたストレージ

• 定期的なキー変更（自動化を推奨）

• 未使用のキーまたは解読された可能性のあるキーの破棄または交換

• 1人のユーザーがキー全体にアクセスするのを防ぐためのキー情報の分割とデュアル・コントロール

Oracleのキー管理

Oracle Advanced Security Transparent Data Encryption（TDE）は、組込みのキー管理機能でこれらの要件に対応します。TDEは内部で自動的に暗号化キーを作成します。データ暗号化キーを保護するマスター暗号化キーがある2層のシステムがあります。マスター・キーは、データベースの外部に安全に保管されます。Oracle WalletにPKCS#12形式ファイルでパスワード暗号化された状態で保管されるか、またはOracle Key Vault（OKV）を使用してよりセキュアな方法で保管されます。OKVは、暗号化キー、Oracle Wallets、Javaキーストア、認証情報ファイルを一元管理するためのOracleのソリューションです。Oracle Advanced Securityの透過的データ暗号化(TDE)で使用するマスター・キー管理を最適化する機能もあります。ウォレットのバックアップまたはリストアの作成に使用できることに加え、直接接続モードではマスター・キーが実際にOKVに移動してローカルのオペレーティング・システムから削除されます。暗号化されたデータを保持するデータベースから、必要に応じてOKVにマスター暗号化キーが要求されます。OKVではキー管理の新しい国際規格（OASIS Key Management Interoperability Protocol– KMIP）がサポートされています。

カード会員データの保護の構築

強力な認証

強力な認証の必要性は、PCI DSS全体を通じて何度も出現するテーマです。強力な認証の使用は、要件8で推奨されています。要件8では、コンピュータへのアクセスに、一意のユーザーID、および相応の認証が必要であることが規定されています。

特に、8.7では、カード会員データを含むデータベースへのアクセスを認証する必要があると定められています。

Oracle DatabaseはKerberos、PKI、RADIUSを含む強力な認証ソリューションを提供しています。


23

監視、追跡、および監査

カード会員データの強力なデータ・セキュリティ・ポリシーと制御を維持するには、それらが確実に意図したとおりに正しく動作し、実施されるように、継続して監視、追跡、および監査する必要があります。制御が有効であることを検証し、不正なアクティビティとエラーを検出して対処する機能により、堅牢なカード会員データ保護プログラムが完全なものになると同時に、組織は、ポリシーと制御が有効に存続していることをQSAに確認できます。

PCI DSS要件10は、組織がカード会員データへのアクセスを追跡し、監視するよう求めています。この標準は監査機能も重視しており、特に要件10.2では、カード会員データへの個々のユーザー・アクセスの監査証跡を実装することが義務付けられています。

Oracle Audit Vault and Database Firewallを使用することで、セキュリティ担当者は、不正なアクセスの試み、システム・レベルの権限の濫用を示す可能性のあるアクティビティを検出および警告できます。収集された監査データを継続して監視し、アプリケーションの表への変更や特権ユーザーの作成などのシステム・イベントを含む、定義済みのアラート条件に対してアクティビティを評価します。Oracle Audit Vault and Database FirewallはOracleおよびOracle以外のデータベースだけでなく、オペレーティング・システム、ディレクトリ、その他のソースから監査証跡を収集します。これにはOracle Databaseのファイングレイン監査と条件付き監査が含まれます。

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では、最新のパッチを適用することが必須とされています。


24

Oracle Database Lifecycle Management Packは、データベース構成（オペレーティング・システム、ハードウェア、アプリケーション・サーバー、およびパッケージ化されたアプリケーション構成も同様）の資産検出、追跡、および変更検出の機能を提供します。詳細な構成情報を定期的に収集し、企業に固有の構成値を決定するための分析と検索の機能を提供します。Oracle Database Lifecycle Management Packを使用して、IT管理者は、変更の検出、"構成のずれ"の修正、予定された変更の検証を実行できます。また、Oracle Database Lifecycle Management Packは、監査用に制御と構成手順を検証するための強力なコンプライアンス・レポート機能も備えています。

特権アカウントの管理

内部の敵

特権ユーザーのアクセス制御や特権ユーザーの認可、職務の分離などの重要な機能を手動手順に依存しなければならない場合、その管理と維持が困難になります。担当者および要件の変更や新たな資産の獲得といった一般的な要素を考慮に入れると、その傾向はさらに強くなります。しかし、残念なことに、組織は、複数の管理者でユーザーIDを共有したり（要件8.5により禁止）、ポリシーに違反した権限や所定のワークフロー・プロセス外の権限を割り当てたりすることでこれに対応しようとします。また、ログを監視して未承認アクティビティや不適切なアクティビティがないかを調査する作業には、多くの時間とリソースがかかり、エラーも生じやすいことから、組織はこのような作業を適切に実行しておらず、問題がさらに深刻化します。

皮肉にも、組織はシステム管理者やDBAなどの特権アカウントよりも汎用ユーザー・アカウントのセキュリティ管理に力を入れる傾向がありますが、特権アカウントはより高いセキュリティ・リスクの原因となります。このリスクをもたらすのは、特権アカウントがカード会員データなどの機密情報にアクセスし、システムを構成し、データベースを変更して他者に権限を付与できるためです。

しばしば、特権ユーザー・アカウントの管理がずさんとなっているのには、多くの理由があります。長年の間、高い権限を持つ個人は信頼できる人物であるが、その他の従業員はあまり信頼できないと考えられてきました。もちろん、大半の特権ユーザーは信頼できますが、私利私欲または報復のために権限を濫用する衝撃的な例があります。このようなシステム侵入の企ての標的となるのは、機密性の高いカード会員データを含むデータベースなどのシステムに潜在的に幅広くアクセスできる特権ユーザー・アカウントです。さらに、ミスはよくあることであり、表の削除は特権ユーザーが犯す間違いの一例にすぎません。

これらのアカウントの管理を実施するのは困難です。許可した権限が少なすぎて業務を妨げるリスクを負うよりは、過大な権限を許可する方が簡単です。特権は多くの場合、緊急時、少なくとも緊急とみなされる状況下で付与されますが、権限が取り消されることはありません。特権アカウントとそれらのパスワードは、便宜上、複数のユーザーで共有される傾向があります。

機密データベースへの完全なアクセスと制御に関して考えた場合、ずさんに制御され定義が不十分な特権アカウントがどのような結果を招くかは明らかです。


25

規制の圧力により、特権ユーザーと特権アカウントを調べ、これらの長期にわたるセキュリティ・リスクを修正することを組織は余儀なくされました。特権ユーザー・ロールは、組織内の誰よりも高い粒度レベルで定義し、それらがどのシステムとデータにアクセスでき、どの操作の実行が許可されるかを制御する必要があります。特に、職務分離に注意する必要があります。

特権ユーザーを管理および監視するシステムは、動作を遅らせたり、ビジネスを中断したりすることなく、正当なニーズに対応するために十分な柔軟性を備えている必要があります。そうでないと、過度に広範な高特権アカウントの問題にすぐに戻ってしまいます。

PCIがリスクを認識

特権ユーザーのアクセスと認可についての懸念は、PCI DSSに大きく反映されています。特権アカウントの場合は、アクセス制御、ユーザー認証、およびユーザー・アクティビティの追跡に関するグローバルな要件を強調する必要があり、要件はすべて何度も強調されています。組織が、一般のユーザーに妥当なレベルのアクセス制御を実施しても、特権ユーザー・アカウントを見合うレベルに合わせることができなかった場合は、中身のない勝利を得たことになります。

要件7の指令を実装するときは特権ユーザーに特に注意し、カード会員データへのアクセスは、それを知る必要のある業務の担当者のみに制限します。7.1項では、組織が、特権ユーザーIDへのアクセス権を業務の責任を果たすために必要な最低限の権限に制限するように、明示的に示されています。また、権限は職種と職務に基づいて決定することが求められています。特に高い特権を持つアカウントのリスクは最大になるため、これらの職種を必要に応じて見直し、再定義することが非常に重要です。

特権ユーザーに伴うリスクは、特に、カード会員データを含むデータベースへのすべてのアクセスを認証する必要性を述べている、要件8の堅牢な認証に関する指令においても重視すべき点です。

ネットワーク・リソースとカード会員データへのアクセスの追跡と監視について取り上げている要件10では、"システム・コンポーネントに対するすべてのアクセス（特にrootなどの管理権限を持つユーザーによって実行されたもの）を、個々のユーザーとリンクするための手順を確立する"と指定されています。

Oracleによる特権アカウントの管理

Oracle Database Vaultを使用して、組織は特権ユーザーを制御し、カード会員データなどの重要な資産を不要なリスクや公開から保護できます。Oracle Database Vaultは、特権ユーザーのアクセスと認可を厳密に定義し、職務分離を実施するための強力ながら柔軟で管理しやすいメカニズムを備えています。

Oracle Database Vaultは、"レルム"の概念を使用してデータベース内にファイアウォールを作成することで、強力な特権ユーザー・アクセス制御を提供します。機密性の高い表やアプリケーションはレルムに配置できるため、特権ユーザーはカード会員データへアクセスせずに職務を遂行できます。コマンド・ルールによって、複数ファクタ認可がデータベースへのアクセスを特定のサブネットまたはアプリケーション・サーバーのみに制限し、データ・アクセスのための信頼できるパスを作成できます。IPアドレス、時間、認証方式などの組込みのファクタを、柔軟で適応可能な方法で使用して、PCIコンプライアンスとビジネス要件を満たすようにアクセス制御を実施できます。


26

Oracle Database Vaultは、データベース内で責務別に3つの個別のロール（アカウント管理、セキュリティ管理、データベース管理）が定義された、標準として使用できる職務分離のベースラインを提供します。これらの各ロールは、特定のビジネス要件を満たすようにカスタマイズできます。

Oracle Database Vaultでは、レルムによってデータ・アクセス試行がブロックされたなどの情報を提供する多数の標準レポートが用意されています。そのため、たとえば、DBAがレルムによって保護されたデータ・アプリケーションの表にアクセスしようとすると、Oracle Database Vaultがアクセスをブロックし、レルム違反レポートで参照可能な監査レコードを作成します。

前述のとおり、Oracle Audit Vault and Database Firewallは、堅牢な監視、監査、およびレポート機能を提供し、これらは当然、すべてのタイプの特権ユーザーに適用できます。

ID管理によるコンプライアンスの実現とビジネスの強化

セキュアで柔軟なIDおよびアクセス管理

データベース・セキュリティは、PCIコンプライアンス・プログラムの中心であり、王冠の宝石に匹敵するカード会員データを直接保護します。その中心を取り巻き、アクセス制御、認可、および認証を核として作成された堅牢なID管理が、自由に流れるビジネス・プロセスにセキュリティが緊密に統合された企業環境を生み出します。その結果、ビジネスを強化する一方で、コンプライアンス要件を満たすエンド・ツー・エンドのセキュリティが確立されます。

ユーザーとアプリケーションのアクセス制御は、PCI DSS要件の文言だけでなく、その含意も満たすため、実際にカード会員データを保護できます。現実的には、カード会員データは不活性ではありません。それは、パートナー、サプライヤ、ベンダー、および従業員にまでおよぶ非常に複雑な分散型企業で商取引を成功させるための要因の1つです。ID管理は、単なるユーザーID、パスワード、ファイル権限の集合ではありません。ユーザー、アプリケーション、データ、およびプライベート・ネットワークとパブリック・ネットワークの動的なエコシステムです。新しいアクセス要求や新しいアプリケーション、新しいビジネス・イニシアチブだけでなく、従業員や請負業者、パートナーなどの絶え間ない出入りにより、限定的な権限や一時的な権限が必要とされるため、このエコシステムは常に変化します。この絶え間ない変化が作り出すリスクの高い流動的な環境は、簡単に管理不可能な状態に陥ります。

ID管理の計画には、次のことを含める必要があります。

• 企業全体にわたり、ポリシーに従って、効率的に制御を維持できるように、個々のアプリケーションから分離された一元的に管理されたアクセス制御。

• 明確に定義された高い粒度のロールベースのアクセス制御（RBAC）。ロールは特定の職務権限ごとに作成し、ロールごとに必要な権限を定義されます。その後、ロールを個々のユーザーに割り当てるため、責務の追加や変更を簡単に行うことができます。

• 明確に定義された評価および承認ワークフローに基づいた、従業員、請負業者、認可権限のタイムリーで正確なプロビジョニングとデプロビジョニング。

• リアルタイムな監視とアラート発行、包括的でタイムリーな監査、および強力なレポート機能。


27

IDおよびアクセス管理に対するPCI要件

特権ユーザーに関して前述したとおり、PCI DSSには、同団体がアクセス制御を非常に重視していることが反映されています。

要件7では、カード会員データへのアクセスを、それを知る必要のあるユーザーのみに制限しています。このアクセスは、職務を遂行するための最低限の権限という原則と、個々の職務および職務権限に基づいて認可する必要があります。

要件8では、コンピュータにアクセスする各ユーザーに一意のユーザーIDを割り当てることを必須とし、適切とみなされる2つの要素による認証（リモート・アクセスの場合は必須）とパスワードに関するルールを含む、認証の要件を規定しています。要件では、プロビジョニングも対象に含まれています。重要なプロビジョニング機能の例を次に挙げます。

• ユーザーID、資格証明、その他のIDオブジェクトの追加、削除、および変更を制御し、管理を特定の権限を持つ小規模なグループに限定します。

• 離職したユーザーのアクセスはただちに取り消します。

• 少なくとも90日ごとに、休眠状態にあるユーザー・アカウントを削除または無効にします。

• ベンダーがリモート保守に使用するアカウントは、必要な時間帯のみ有効にします。

これについては、データベースへの直接アクセス、または特権ユーザーのアクティビティという概念を超えて検討してください。明確に定義されたロールとそれらをサポートする認可および認証要件がなければ、誰がカード会員データまたはカード会員データにアクセスするアプリケーションにアクセスしたか、またはそのアクセス権を取得したかを知ることはできません。実際に、どのアプリケーションがアクセス権を持つのかもわかりません。

要件10では、ネットワーク・リソースとカード会員データへのすべてのアクセスの追跡および監視という重要な領域を取り上げています。PCI DSSは、データへの直接アクセスだけを重視しているわけではなく、カード会員情報が、多数の関係者が存在し、部分的な移動や変更が多い動的な本番環境内に存在していることを認識しています。

また、最初に、アクセス制御、認可、プロビジョニング、および認証のルールが述べられ、その後、ユーザーおよびアプリケーションのアクティビティの監視が取り上げられている点にも注意してください。正しい許可されたアクティビティを制御するポリシーとプロセスがなければ、不正なアクティビティを監視することはできません。

要件では、システム・コンポーネントに対するすべてのアクセスを個々のユーザーに関連付けて包括的な監査証跡を実現し、カード会員データに対するすべての個別ユーザー・アクセスを再現するプロセスが必要とされています。監査証跡へのアクセスや無効なアクセスの試行、監査ログの初期化、システム・レベル・オブジェクトの作成と削除も要件の対象に含まれています。


28

ID管理の課題

PCI DSSのID管理関連の要件は、おそらく、実装するのがもっとも困難で、管理および維持するのはさらに困難です。このような問題は、組織がコンプライアンスに対する取組みを継続的に維持できない主要な原因の一部になっています。これらの問題により、組織が障害のあるシステムの修復や違反の是正を実行しようとして（利用可能な）データの収集と分析を行う際、理不尽な時間や労力、コストがかかる場合があります。ID管理の問題は、制御機能をQSAに対して証明し、実際は制御がほとんど有効でない理由を説明するという難題をもたらします。

これらの課題のいくつかについて検討してみましょう。これらの課題は通常、ポリシーは適切であるものの、それらを非効率な手動プロセスにより実施しようとした結果として生じます。

アクセス制御、認可および認証は、必然的に、一元的に管理されるのではなく、一般にアプリケーション単位で実行されます。その結果、ポリシーの実施にばらつきが生じ、人手のかかる管理となるため、常に変化するビジネス要件への対応は遅く非効率となり、結果にエラーが生じやすく、セキュリティは脆弱化します。

一元化されたポリシーベースの管理がなければ、ユーザー、グループ、アプリケーション、およびデータ・アクセスを対象に一貫して適切な認証制御を提供することは困難です。

ロールベースのアクセス制御は、理論的には優れていますが、実装および維持するのは容易ではありません。ロールを定義し、企業全体にわたるロールベースのアプローチを確立するには、膨大な時間とリソースを費やす必要があります。ユーザー、責務、および一連のレポートに関する情報は、通常、組織の至るところにあるサイロに収められているため、この状態はさらに悪化します。

複雑な分散型企業で一貫したポリシーを管理し、適用することはほぼ不可能です。

ユーザーのプロビジョニングとデプロビジョニングおよびユーザーの認可にはたいてい時間がかかり、ビジネスの妨げとなります。スプレッドシートベースの管理は、効果的にポリシーを適用できますが、多忙な管理者による対応の遅れと、担当マネージャーによる評価と承認を待つ遅延時間が原因でボトルネックとなる場合があります。

一般に、このようなプロセスはさまざまな理由でエラーが起こりやすいと言えます。ロールベースの制御は、自動システムなしで定義および管理するのは困難です。そのため、個々のユーザーまたはグループの粗雑な割当てに基づいて、個々のユーザーに過少または過大な権限が付与される場合があります。管理者は、個々のユーザーが職務を遂行するために必要なものを確保するために、過剰に認可しすぎる傾向があります。これは、個々のユーザーが請負業者またはベンダーで、組織内で高特権を持ってしまった場合に、より重大な懸念事項となります。

このような環境では、該当する個々のユーザーが去った後に、"ゴースト"アカウント（不正アカウントとも呼ばれる）が長期間存続したり、一時的な認可が取り消されず残ったりすることがあります。アカウントは、引き続き企業システムとデータへのアクセス権を持つ以前の従業員、任務が終了した請負業者、または一時的な権限が付与されたが組織内での職務が変更になった既存の従業員に属している場合があります。

ユーザー・アクティビティの監視は、不可能でないとしても、困難です。ほとんどの場合、リアルタイムの監視機能やアラート機能はありません。アクセスの制御と監視はアプリケーションやシステムごとに別々に管理されているため、現実的な問題として個人を監視することはほぼ不可能です。


29

監査作業も、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の監査サービスは、認証の成功または失敗など、監視したイベントを詳細かつ柔軟にロギングします。監査ログはフラット・ファイルまたはデータベースに書き込むことができ、任意のサード・パーティのレポート・ツールにエクスポートして包括的な監査レポートを生成できます。


30

結論

PCI-DSSはおそらく、パブリック・インターネットの普及とインターネットによる不正の広がりによって、情報セキュリティに関する懸念が表面化し始めて以来、私達が目にした中でもっとも期待できる業界の自己管理への取組みです。何十億もの安全でない消費者情報レコードを悪用しようとして、犯罪者がオンライン上に移動してきたことから、クレジット・カード会社は時代に遅れないようにするため、カード会員データを保護するための非常に規範的な詳細計画を作成しました。この設計書を強力な土台とすることで、IT組織は優れたデータ・セキュリティ・プログラムを構築できます。

多くの組織にとって、特に、その他の一部の業界ほどにはセキュリティ・ポリシーが成熟していない小売業者にとって、コンプライアンスとデータ・セキュリティは困難であることが実証されてきました。しかし、PCI DSSの目標は達成可能であり、この標準に含まれる要件は、持続可能な継続的プログラムを利用して遵守できます。これを推進するには、オラクルをはじめとするデータ・セキュリティ分野のリーダーが提供する自動化ツールと健全なセキュリティ・ポリシーの組合せが必要です。これにより、コンプライアンスが実現されると同時に、組織のビジネス・プラクティスの改善が可能になります。


31

参考資料

次に、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:ID管理によって情報アクセスを保護するセキュリティ手法

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のセキュリティ・ソリューション

https://www.oracle.com/database/security/index.html

• オラクルのID管理ソリューション

http://www.oracle.com/jp/products/middleware/identity-management/overview/index.html

• Oracle Lifecycle Management Pack

http://www.oracle.com/technetwork/jp/oem/lifecycle-mgmt/index.html

http://www.oracle.com/technetwork/jp/oem/grid-control/twp-config-for-pci-129339-ja.pdf





https://www.oracle.com/database/security/index.html

http://www.oracle.com/jp/products/middleware/identity-management/overview/index.html

http://www.oracle.com/technetwork/jp/oem/lifecycle-mgmt/index.html


クレジット・カード業界の

データ・セキュリティ標準への

持続可能なコンプライアンス

2015年7月

Oracle Corporation World Headquarters 500 Oracle Parkway Redwood Shores, CA 94065 U.S.A. 海外からのお問い合わせ窓口：

電話：+1.650.506.7000

ファクシミリ：+1.650.506.7200

oracle.com

Copyright © 2015, 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

クレジット・カード業界のデータ・ セキュリティ標準への持...

Documents

クレジット・カード業界のデータ・セキュリティ標準への持...