2024年5月1日8:10
近年、クラウド環境を利用してシステムを構築する企業が増加している。パブリッククラウドが登場した当初と比べ、機能の拡充が進んでいることもあり、クラウド環境へ移行する企業は今後ますます増えていくと考えられる。クレジットカードに関するセキュリティの国際基準であるPCI DSSもそうした変化の影響を受けており、最新バージョンのv4.0ではクラウド環境への柔軟な対応を意図した要件が多数見受けられる。クラウド環境でPCI DSSに準拠する場合、クラウドプロバイダの提供する各種サービスをうまく活用することで、要件への対応を効率的に実施できる。一方で、具体的なサービスの選び方やその設定はユーザに委ねられているため、正しい運用方法をユーザ側で理解することも重要だ。本記事では、2024年4月1日のPCI DSS v4.0必須化を間近に控えたタイミングで、v4.0基準からいくつかの要件をピックアップし、クラウド環境における対応方法と注意点を解説していく。
NRI セキュアテクノロジーズ株式会社 決済セキュリティコンサルティング部
セキュリティコンサルタント
CISA, CISM, QSA(PCI DSS), P2PE Assessor 田中 茉理絵
クラウド環境における責任分界点について
「責任共有モデル」を理解する
各要件の解説に入る前に、まずはユーザとクラウドプロバイダの責任分界点について確認しておきたい。
パブリッククラウドでは基本的に、ユーザとプロバイダで管理責任を分担する「責任共有モデル」の考え方が採用されている。そして、その責任分界点を示すマトリックスが各プロバイダから公開されている。
例えば下記の（図1）は、MicrosoftのAzure環境における責任分界点を示したマトリックスである。この図では、ユーザ（Customer）とプロバイダ（Microsoft）のどちらが責任を持つべきかがコンポーネントのタイプごとに示されている。
サービスの利用形態がクラウドの場合、”Physical datacenter”などの物理的な施設・コンポーネントの管理については、いずれもプロバイダ責任となっている。一方で、”Information and data”や”Accounts and identities”など、クラウド上に保存するデータや認証情報の管理についてはユーザ責任となっていることが分かる。責任分界点はプロバイダによって多少異なるが、大まかには同様の線引きがなされていると言って良いだろう。ユーザはプロバイダ側に責任をシフトできる範囲を見極め、ユーザ責任の範囲にリソースを集中的に割り当てることで、オンプレミス環境よりも効率的な運用を行うことができる。
PCI DSSへの対応を進める際も、ユーザ責任の領域を明確化することが第一歩となる。各プロバイダもPCI DSSを意識した取り組みを行っており、プロバイダ責任の範囲においてPCI DSSに準拠しているパブリッククラウドも多い。また、ユーザ向けにPCI DSS対応のためのガイダンスやベストプラクティスをまとめ、ブログ等で公開しているプロバイダも見受けられる。
サービスを活用した要件への対応
続いて、本題であるクラウド環境におけるv4.0要件への対応方法について解説していきたい。
今回は全12要件の中から、責任分界点の切り分けが特に重要である要件や対応の負荷が高い要件をピックアップし、要件を満たすためのポイントも交えて記述する。
要件３ 保存されたアカウントデータの保護
まずはPCI DSSの要とも言えるアカウントデータの保護を規定した、要件3を例に挙げて考えてみる。この中で特に負荷の高いものとしては、PAN（Primary Account Number：カード会員番号）の読み取り不能化を求めた要件3.5.1が挙げられる。要件自体はv3.2.1からある既存のものだが、クラウド環境で対応する場合の考え方を改めて整理してみよう。
【要件3.5.1】PAN は、以下のいずれかの方法を用いて、保存されている場所での読み取りを不能にする。
• 強力な暗号化技術に基づくPAN全体の一方向ハッシュ
• トランケーション
• インデックストークン
• 強力な暗号化技術と関連する鍵管理プロセスおよび手順
読み取り不能化の方法はさまざまだが、4点目の「強力な暗号化技術と関連する鍵管理プロセスおよび手順」には、各社のクラウド環境で提供されている暗号化サービスと鍵管理サービスを活用することができる。
暗号化サービスを利用した暗号化の形式としては、まず大きく以下の2つに分けられる。
• サーバーサイド暗号化：クラウド側のサーバ環境で暗号化を行う形式
• クライアントサイド暗号化：ユーザ側がクラウド環境へのアップロード前に暗号化を行う形式
クライアントサイド暗号化を選択した場合、鍵の生成や強度の設定、鍵管理はユーザ側に委ねられる形となる。そのためサーバーサイド暗号化を選択して責任をプロバイダにシフトすると良いのだが、サーバーサイド暗号化はさらに種類が細分化されているケースが多く、その選び方に注意が必要となっている。
ここで、Amazon Web ServicesのAWS環境を例として具体的なケースを考えてみる。AWSのストレージサービスである「Amazon S3」にPANを保存してサーバーサイド暗号化を行う場合、以下の4通りの方法がある。
Amazon S3マネージドキーによる暗号化（SSE-S3）
S3にデフォルトで設定されている、AWSの用意したAES-256鍵による各オブジェクトの暗号化。この鍵は定期的にローテーションされるルート鍵により暗号化され、保護される。
AWS KMSキーによる暗号化（SSE-KMS）
AWS Key Management Service（AWS KMS）を利用した暗号化。KMSで生成・管理されている鍵による暗号化を実施できるほか、鍵のライフサイクルの設定やアクセス権の設定など、SSE-S3よりも細かいコントロールが可能となる。
AWS KMSキーによる二層式暗号化（DSSE-KMS）
SSE-KMS と基本的な仕組みは同じだが、異なるレイヤーで二重の暗号化が行われるより強固な方式。それぞれ独立したレイヤーで暗号化が行われるため、どちらか片方が侵害されてもデータを保護することができる。
カスタマーキーによる暗号化（SSE-C）
ユーザが指定した鍵を利用する暗号化。鍵の生成や管理はすべてユーザ責任で行う必要がある。
下へ行くにつれてユーザ責任の範囲が広がるため、一番上のSSE-S3を選択すれば鍵管理の負担は最も軽くなる。しかし、この形式を選んだ場合、以下の鍵管理に関する要件を満たせない可能性がある。
【要件3.6.1】保存されたアカウントデータを開示や誤用から保護する暗号鍵を保護するため、以下のような手順を定義し実施する。
• 暗号化鍵へのアクセスを、必要最小限の管理者に制限する。
• 鍵暗号化鍵の強度は、少なくとも保護対象データの暗号化鍵と同一とする。
• 鍵暗号化鍵は、データ暗号化鍵とは別に保存する。
• 鍵の保存場所と形式を最小限にし、安全に保存する。
SSE-S3で利用する鍵はAWSによって管理されるが、個別のアクセス制御を行うことができない。そのためS3へアクセスできるユーザ＝鍵へアクセスできるユーザとなり、「暗号化鍵へのアクセスを必要最小限の管理者に制限する」という要件を満たせないケースが考えられる。また、鍵暗号化鍵に該当するルート鍵については強度や保存場所が開示されていないため、それらの要件を満たせるかどうかも不明瞭なものとなっている。PCI DSS対応のベストプラクティスとしては、SSE-S3以外の方式を選択した上で、ユーザ側で鍵の強度設定やアクセス制御を実施すると良いだろう。
上記ではAWSを例に挙げたが、他のクラウド環境でもサーバーサイド暗号化は一般的に数種類に分かれており、プロバイダ側のコントロール範囲が大きい方式からユーザ側のコントロール範囲が大きい方式まで、幅広く選択できるようになっている。要件への対応可否を考慮した上で、実現したいセキュリティレベルと鍵管理に割けるリソースのバランスを考え、自社にとってベストな方式を選んでもらえればと思う。
要件6 安全なシステムおよびソフトウェアの開発と維持
