Skip to main content

PCI審査に向けたクラウドインフラのセキュリティ確保

著者
Headshot of DeveloperSteve Coochin

DeveloperSteve Coochin

feature snyk iac green

2022年3月3日

0 分で読めます

PCI認証のプロセスは非常に包括的で、インフラ、ソフトウェア、システムへの従業員のアクセス、特にデータセットとそのアクセス方法に関わります。こうしたチェックは、決済業界全体にとって重要であるだけでなく、データが保護されているという安心感をユーザーに提供するうえでも欠かせません。PCI準拠のプロセスでは通常、認定を受けた第三者機関が複数のチェックを実施し、安全なデータ取り扱いのプロセスが整備されていることを確認します。

この記事では、PCI準拠を実現するためにクラウドインフラをどのように保護できるかを見ていきます。

PCI準拠の要件とは?

PCI DSSとも呼ばれるPayment Card Industry Data Security Standard(PCIデータセキュリティ基準)は、カード会員の機密データを安全に保つための、業界で定められたガイドラインです。この基準はPCI Security Standards Councilが管理しており、準拠規制からPCI DSS認証を行う認定ベンダーまで、基準に関するあらゆる詳細を規定しています。

PCI準拠要件はさまざまな項目を網羅しており、特にソフトウェア開発ライフサイクル(SDLC)のあらゆる側面に関わります。包括的な一覧はこちらで確認できます。主な要件は次のとおりです。

  1. カード会員データを保護するためのファイアウォール設定を導入し、維持する。ファイアウォールはすべてのネットワークトラフィックを検査し、信頼されていないネットワークからシステムへのアクセスを遮断します。

  2. ベンダーが提供するシステムパスワードやその他のセキュリティパラメータの初期設定を変更する。こうしたパスワードは公開情報から簡単に特定でき、悪意ある人物がシステムへ不正アクセスするために利用される可能性があります。

  3. 保存されているカード会員データを保護する。カード会員データの保護には、暗号化、ハッシュ化、マスキング、切り捨てなどの方法が使われます。

  4. オープンなパブリックネットワーク上で送信されるカード会員データを暗号化する。信頼できる鍵と証明書のみを使うなど、強力な暗号化を実施することで、ハッキングを通じた悪意ある人物の標的となるリスクを軽減できます。

  5. すべてのシステムをマルウェアから保護し、ウイルス対策ソフトウェアを定期的に更新する。マルウェアは、インターネットの利用、従業員のメール、モバイルデバイス、ストレージデバイスなど、さまざまな経路でネットワークに侵入します。最新のウイルス対策ソフトウェアや補完的なマルウェア対策ソフトウェアを導入することで、マルウェアによる悪用のリスクを軽減できます。

  6. 安全なシステムとアプリケーションを開発し、維持する。システムやアプリケーションの脆弱性を悪用すると、悪意ある人物が特権アクセスを取得するおそれがあります。脆弱性を修正し、悪用やカード会員データの侵害を防ぐため、セキュリティパッチは速やかに適用する必要があります。

  7. カード会員データへのアクセスを、許可された担当者のみに制限する。「業務上知る必要がある」場合に限ってカード会員データにアクセスできるよう、システムとプロセスを整備する必要があります。

  8. システムコンポーネントへのアクセスを識別し、認証する。システムコンポーネントにアクセスする各担当者には一意の識別子(ID)を割り当て、重要なデータシステムへのアクセスを追跡できるようにする必要があります。

  9. カード会員データへの物理的なアクセスを制限する。カード会員データや、そのデータを保管するシステムへの物理的なアクセスを保護し、不正アクセスやデータの持ち出しを防ぐ必要があります。

  10. カード会員データやネットワークリソースへのすべてのアクセスを記録し、監視する。データ侵害の防止、検知、影響の最小化に重要なユーザーアクティビティを追跡できるよう、ログ記録の仕組みを整備する必要があります。

  11. セキュリティシステムとプロセスを定期的にテストする。新たな脆弱性は継続的に発見されています。悪意ある人物に悪用される可能性のある脆弱性を見つけるため、システム、プロセス、ソフトウェアを頻繁にテストする必要があります。

  12. すべての担当者を対象とする情報セキュリティポリシーを維持する。強固なセキュリティポリシーには、データの機密性と、それを保護する責任を担当者に理解してもらうことが含まれます。

インフラに関するPCI要件

より詳細な要件一覧を確認しながら、この記事ではSDLCの一環として特にインフラに関わる項目を取り上げます。

1.3 インターネットとカード会員データ環境内のシステムコンポーネントとの間の、直接的なパブリックアクセスを禁止する。

過去の脆弱性を悪用した侵害事例からもわかるように、この項目は、脆弱性や設定ミスによって中核データベースへの不正アクセスが可能にならないようにする必要性を示しています。また、セッションやユーザーがアクセス可能なコンポーネントへのアクセスにも関わります。

2.2.2 システムの機能に必要なサービス、プロトコル、デーモンなどのみを有効にする。

2.2.4 悪用を防ぐようにシステムのセキュリティパラメータを設定する。

2.2.3 安全でないと見なされる必要なサービス、プロトコル、デーモンには、追加のセキュリティ機能を実装する。

5.1.1 ウイルス対策プログラムが、既知のあらゆる種類の悪意あるソフトウェアを検知・削除し、それらからシステムを保護できることを確認する。

5.2 すべてのウイルス対策メカニズムが、次のように維持されていることを確認する。

  • 常に最新の状態に保つ

  • 定期的にスキャンを実行する

  • PCI DSS要件10.7に従って保持する監査ログを生成する。

5.3 ウイルス対策メカニズムが常に実行され、無効化や変更ができないことを確認する。ただし、管理者が個別に承認した場合は、限定された期間に限り例外とする。

幸い、これらはボタンを数回クリックするだけで簡単に自動チェックでき、無料のSnykアカウントを使ってプロセスやパイプラインに簡単に組み込めます。

Snyk ContainerとSnyk IaCでPCI審査を効率化

私が特に気に入っているのは自動化です。PCI準拠においては、CI/CDパイプラインに適切なセキュリティスキャンを設定することを意味します。これにより、ログの生成やインフラ内の脆弱な箇所の特定など、さまざまなメリットが得られます。

Snykでセキュリティスキャンを設定する方法はいくつかあります。Googleのeコマース向けmicroservices-demoを使った例を見てみましょう。

衣類、アクセサリー、家庭用品と価格を掲載した「人気商品」グリッドが表示されたOnline Boutiqueのストアフロント。

リポジトリから直接始める

手順を試してみる場合は、まずmicroservices-demoリポジトリをフォークします。

コードをGitHubアカウントに直接フォークすれば、プラットフォーム上で簡単に開発を進められます。開発中にブランチを作成し、必要に応じてカスタマイズするのも簡単です。また、ローカルの開発環境にクローンして、コードをテスト、実行することもできます。

developersteve/microservices-demoのGitHubリポジトリページ。GoogleCloudPlatformのクラウドネイティブなマイクロサービスサンプルアプリケーションをフォークしたリポジトリが表示されています。

Snykでセキュリティスキャン

ここからコードをテストする方法はいくつかあります。1つは、プロジェクトのルートからSnyk CLIを使う方法です。この方法では、snyk testでローカルのテストを実行したり、snyk monitorで脆弱性を継続的に監視したりできます。

フォークしたコードリポジトリをSnyk GitHubインテグレーションを使って、Snykアプリに直接接続することもできます。その場合は、Snykアカウントにログインし、Snykダッシュボードにあるプロジェクトを追加ボタンをクリックします。クイック追加プロジェクトメニューからさまざまなインテグレーションを選択できるほか、その他をクリックして、利用するGitプラットフォームを検索することもできます。

GitHub、Cloud Foundry、Bitbucket Cloud、CLI、公開GitHubリポジトリ、その他のオプションが表示されたプロジェクト作成メニュー

GitHubとのインテグレーションを接続したら、フォークしたmicroservices-demoリポジトリを検索して初回スキャンを開始できます。

「microservices-demo」のリポジトリ検索結果。developersteve組織と一致するリポジトリが表示されています。

リポジトリを選択すると、継続的にスキャンが実行され、検出された問題が表示されます。問題はプロジェクトの各コンポーネントに分けて表示されるため、詳しく調査できます。

マイクロサービスのデモリポジトリと、IstioおよびKubernetesのYAMLマニフェストに関するセキュリティ検出結果を表示するコード分析ダッシュボード。

PCI審査の追跡に特に役立つのは、検出結果がそれぞれの項目の履歴セクションに保存される点です。スキャンの実行ごとに、検出された問題と修正方法が表示されるため、PCI準拠の監査に役立ちます。

cartservice.yaml の Kubernetes マニフェスト履歴。snyk.io による最新のスキャンで、既知の問題が5件検出されています。

さらに、SnykはコーディングIDEともインテグレーションできるため、アプリの開発中に問題を特定できます。コーディングしながら問題を検出し、修正方法を確認できるのでとても便利です。

CI/CDパイプラインにセキュリティを組み込む

自動化は、SDLCのあらゆる段階に関わる人にとって有益です。定期的なデプロイを効率化するだけでなく、デプロイに必要な手順やプロセスを明確にできます。優れた自動化パイプラインなら、Gitブランチからコードを取得し、テストを組み込みながらステージングしてデプロイできます。

SDLC自動化の基盤となるのがCI/CDパイプラインです。SDLCのあらゆる側面と連携できるように設定する必要があります。

セキュリティも継続的に確保する必要があるため、CI/CDパイプラインの一部としてセキュリティを設定することを強くおすすめします。Snykはさまざまなパイプラインや、AWS、GCP、Azureといった主要なクラウドプロバイダーすべてとインテグレーションできます。CI/CDインテグレーションのベストプラクティスについては、CI/CDのベストプラクティスをご覧ください。

AWS CodePipelineのセキュリティ設定例

この例では、Snyk AWSインテグレーションを使ってAWS CodePipelineにセキュリティスキャンを組み込みます。

まず、microservicesデモアプリケーションを使ったデプロイ用に基本的なAWS CodePipelineを構築し、その後、Snykをインテグレーションしてセキュリティスキャンを実行します。

空のパイプライン一覧とオレンジ色の「パイプラインを作成」ボタンが表示されたAWS CodePipelineのパイプラインページ

AWS CodePipelinesダッシュボードに移動し、パイプラインを作成をクリックします。ステップ1の画面でパイプライン名を設定し、サービスロールを選択します。ステップ2では、デプロイするコードがあるGitリポジトリを選択します。Gitサービスに初めて接続する場合は、接続手順に沿って必要な権限を付与します。

GitHub Version 2が選択され、既存の接続が選択されているAWS CodePipelineのソースステージ追加画面。

コードソースの場所を接続したら、デプロイフローで使用するリポジトリとブランチを選択します。

便利なヒント:ここでGitHubに接続する場合は、GitHubバージョン2の接続方法を使用してください。GitHubバージョン1はまもなく廃止されます。

GitHub接続の設定画面。接続準備完了の表示、選択されたリポジトリ developersteve/microservices-demo、ブランチ選択フィールドが表示されています

次へをクリックして、ビルドパラメータを設定するステップ3に進みます。ビルドプロバイダーには、通常AWS CodeBuildを使用しますが、ここでJenkinsとの接続を追加することもできます。プロジェクト名と、アプリケーションに必要な環境変数を設定します。

AWS CodePipelineのビルド設定画面。AWS CodeBuildが選択され、testappプロジェクト、環境変数、単一ビルドオプションが表示されています

基本的なデモアプリケーションのデプロイには、ビルドタイプとして単一ビルドを使用できます。より複雑なデプロイで、大規模なインフラ要件に対応する場合は、バッチビルドが便利です。

次に、ステップ4でデプロイ設定を定義します。このデモでは、事前定義されたインフラを使用するAWS CodeDeployを選択できます。このステップの以降の項目では、使用するインフラを選択します。選択内容によって項目が変わります。

デプロイプロバイダーのメニューを開き、AWS CodeDeployを選択したAWSデプロイ設定画面

最後のステップ5では、AWS CodePipelineの設定を確認して保存します。その後、デプロイするコードの取得からパイプラインのデプロイプロセスが開始されます。

AWS CodePipelineのページ。正常に作成されたMicroservices_demoパイプラインが表示され、Sourceは進行中、Buildは保留中

パイプラインにSnykのセキュリティ機能を追加する

次に、Snyk AWS CodePipelineインテグレーションを使って、このフローにSnykのセキュリティスキャンを追加します。ダッシュボードでCodePipelineの名前をクリックすると、デプロイフローの各ステップが表示されます。

GitHubのソースステップが成功し、Snykのセキュリティステップが実行中へ移行するパイプライン画面

次に、このCodePipelineフローにセキュリティステップを追加します。右上の編集ボタンをクリックします。

Microservices_demoパイプラインのAWS CodePipeline編集画面。GitHubソースとAWS CodeBuildのステージが表示されています

追加するステージの名前を入力します。この例では、最終的なCodePipelineフローに表示する名前としてsecurityを使用します。

ステージ名に「security」と入力されたステージ追加ダイアログと、オレンジ色の「ステージを追加」ボタン

ステージを追加をクリックすると、ステージの設定ページが表示されます。アクション名を設定し、ドロップダウンリストの呼び出しセクションにあるアクションプロバイダーからSnykを検索します。

Action providerのドロップダウンが開いたAWSコンソールの編集アクション画面。利用可能なインテグレーションの中からSnykが選択されています

入力アーティファクトのセクションでは、SourceArtifactからビルドできます。これにより、アプリケーションのビルド前に直接スキャンを実行できます。

Snykに接続ボタンをクリックすると、Snyk for AWS CodePipelineのインテグレーション画面が表示されます。

AWS CodePipelinesのSnyk設定フォーム。脆弱性のブロック、モニタリング設定、プロジェクト名「microservices_pipeline」が表示されている

ログインすると、Snyk AWS CodePipelinesの設定画面に戻ります。ここで組織を設定し、脆弱性が見つかった場合にブロックするためのゲート制御と、重要度を設定できます。

すべて設定したら、続行をクリックします。アクションの編集ページに戻るので、出力アーティファクトの名前と任意の名前空間フィールドを入力し、完了をクリックします。

Snykをプロバイダー、SourceArtifactを入力アーティファクト、reportを出力アーティファクトとして設定したアクションの設定画面。

最後に、変更をリリースボタンをクリックして、本番環境に変更を反映するのを忘れないでください。デプロイのフローが再実行され、デプロイ時にコードがスキャンされます。

Microservices_demoパイプラインが表示されたAWS CodePipelineのページ。ソースステージは成功しており、編集、停止、複製、変更のリリースを行うための操作項目が表示されています。

前述のリポジトリを直接スキャンする例と同様に、スキャンのログはすべて保存されるため、PCIコンプライアンスの審査に役立ちます。AWS CodePipelineとのインテグレーションについて詳しくは、こちらのブログ記事をご覧ください。Snykを使ってAWS CodePipelineで脆弱性スキャンを自動化する。

Snykでクラウドインフラを無料で保護

PCIコンプライアンスのチェックは、第三者の認定機関が年に一度実施する非常に重要な作業です。プロセスは詳細で時間がかかることもありますが、適切なチェックとログを用意しておけば、手続きを迅速化できます。そして何より、アプリ、プラットフォーム、ユーザーを安全に保つことができます。

無料のSnykプランでコードの保護を始めましょう。コンテナとIaCのスキャンに加え、脆弱なベースイメージの自動修正や、IaCの設定ミスに対するコード内での開発者向け修正ガイダンスも利用できます。

ソースコードの段階からインフラを保護

Snykはワークフロー内のIaCセキュリティとコンプライアンスを自動化し、構成ドリフトや不足しているリソースを検出します。

続きを読む

AI Background min crop
Blog

AIが、あなたが受け入れてきたあらゆるリスクを一気に顕在化させる:AI Security Panel: Unfilteredから得た7つの洞察

AIによって攻撃はより安価かつ高速になり、組織がすでに抱えているリスクが露呈しています。4人のセキュリティリーダーが、機械の速度に対応する防御と迅速な修復が今不可欠である理由を語ります。

blog feature ai violet
Blog

VulnBump:AIエージェントはビルドを壊さずに脆弱な依存関係を修正できるか?

VulnBumpでは、実際の依存関係のアップグレード307件をAIエージェントで検証します。脆弱性が解消され、ビルドとテストが正常に通った場合にのみ、修正成功と判定します。

blog feature snyk container custom base recommendations
Blog

Evo Agentic AppSecのご紹介:AI開発のスピードに追随するセキュリティ

AIを活用した開発は、従来のセキュリティワークフローを上回るスピードで進んでいます。SnykのAgentic AppSecは、セキュリティエージェントが脆弱性を継続的に検出、修正、検証し、人が基準を定められるようにします。