PCI DSSで学ぶAWSセキュリティ③ ~要件別のセキュリティ対策後編~

セキュリティ

2021.10.22

前回(https://www.intellilink.co.jp/column/security/2021/091000.aspx)は、PCI DSS [1]のうち前半部分の要件1から6に沿ってAWSプラットフォーム上のセキュリティ対策をAWSから公開されているガイダンス文書 [2]をもとに説明しました。今回は、後半の要件7から12について紹介したいと思います。

PCI DSSの6つの目標と12個の要件

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

本要件では、職種と職務に基づいた業務に必要な最小限のアクセス権の割当てが求められます。AWSプラットフォーム上ではAWS Identity and Access Management (IAM)によりAWSのサービスやリソースへのアクセスが管理されます。IAMでは、ユーザー/ユーザーグループ/ロールに対してポリシーを作成して適用します。ポリシーは許可または拒否されるアクションやリソース、条件を定義するJSON形式のドキュメントです。
以下の例では、Administratorというユーザーに管理者特権を、NWAdminGroupsというユーザーグループにネットワークリソースの作成や維持権限を、LogsAccessRoleというロールにCloudWatchLogsにアクセスするための権限を付与しています。なおロールとは、任意のユーザーやアプリケーション、サービスに対して一時的な認証情報を提供し、アクセス権を委任するために使用されます。例えば、自身が構築したEC2インスタンスにLogsAccessRoleを割り当てることで、インスタンス上のOSログなどをCloudWatchLogsに転送できるようになります。

カード会員データへのアクセスを、業務上必要な範囲内に制限

要件8:システムコンポーネントへのアクセスを識別・認証する

本要件では、アカウントおよび認証情報の適切な設定と管理が求められます。具体的には、個人識別可能なアカウント払出し、パスワードの複雑性や文字数制限などの認証ポリシーの構成、多要素認証(MFA)の実装などが必要となりますが、AWSが提供するマネジメントコンソールによるAWSプラットフォームへのアクセスや、EC2インスタンスを使用して自分達で構築したオペレーティングシステムへのアクセスなどのアカウント管理や認証ポリシーの構成は利用者側の責任です。

  • AWSマネジメントコンソール等によるプラットフォームへのアクセス
    複雑性/文字長/定期変更/再利用防止などのパスワードポリシーや多要素認証が構成可能です。一方、ログイン失敗時のアカウントロックなど一部要件を直接満たすことができないため、代替策(AWS CloudTrailやLambdaの組合せによるログイン失敗検知・制限機構の実装)の検討、ないしはAWS Managed Microsoft Active Directory(AWS Directory Service)などの別の認証機構の利用が必要です。
  • EC2インスタンスへのアクセス
    オペレーティングシステム(Linux、Windowsなど)へのアクセスにパスワード使用は推奨されず、デフォルトでAmazon EC2キーペアが使用されます。また可能な限り、AWS System Manager Sessions Managerを使用してsshやRDPのインタフェースは最小化または無くしていくことが推奨されます。
  • AWSサービスやデータベース等へのプログラムによるアクセス
    AWSサービスへのAPI呼出しなどのプログラムによるアクセスはアクセスキー(アクセスキー IDおよびシークレットアクセスキーで構成される認証情報)ではなくロール(一時的な認証情報)の使用が推奨されます。また、データベースなどへの接続認証情報はアプリケーションに直接埋め込まずAWS Secrets Managerなどによってセキュアに保存することが重要です。

システムコンポーネントへのアクセスを識別・認証

要件9:カード会員データへの物理アクセスを制限する

本要件では物理的なセキュリティ対策が要求されますが、AWSプラットフォームの物理セキュリティやメディア管理はAWSが責任を担います。

【AWSが公表している物理セキュリティの例】

  • 監視カメラ、侵入検知システム
  • 24h365d の監視体制
  • 専門セキュリティスタッフ、身分証明書の提示
  • 認定スタッフのフロアアクセスは最低2回の多要素認証が要求

ただし、AWSに接続される利用者のオンプレミス環境の物理セキュリティやメディア管理は利用者責任となるため、注意が必要です。

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

本要件では、AWSサービスやインスタンス内の各種ソフトウェアなどのログの有効化、要件に沿った適切な保存および監視が求められます。

【AWSサービスのログ設定の例】

  • AWS CloudTrail:AWSサービスを使用して行われたアクションのログ
  • RDS 監査ログ:重要な情報が置かれたデータベースへのアクセスログ
  • S3サーバアクセスログ:S3ストレージ上の監査ログファイル等へのアクセスログ
  • Amazon VPCフローログ:ネットワークトラフィックのログ
  • EC2インスタンス上の各種ログ:CloudWatch エージェントなどを介して収集するシステムログやアプリケーションログ

ログはセキュリティインシデントが発生した際にログの比較や時系列に沿って追跡できるようAmazon Time Sync Serviceなどを利用して正確な時刻情報との同期が必要です。また、S3などに集約保存してIAMポリシーによるアクセス制限や暗号化、変更監視を行い不正な改ざんや削除から保護することも重要です。加えて、不審な兆候などを検知してセキュリティインシデントを未然に防げるようCloudWatch EventsとAWS Lambdaなどを活用してログポリシーに基づいた通知や自動復旧の仕組みを実装しましょう。

要件11:セキュリティシステムおよびプロセスを定期的にテストする

本要件では、セキュリティ診断(脆弱性スキャンおよびペネトレーションテスト)の実施、IDS/IPSや変更検出メカニズムによる監視などが求められます。AWSから提供される各種サービスや専用の製品を個別導入して実現します。

  • セキュリティ診断の実施
    EC2インスタンスなどAWSで許可されたサービスに対して事前承認なしにセキュリティ診断の実施が可能です。ただし、禁止される行為(DoS攻撃など)について記載されている「侵入テストのAWSカスタマーサポートポリシー」への留意が必要です。
  • IDS/IPSによる監視
    安全でないネットワークとの境界やその他重要なポイントを通過するすべてのトラフィックを監視し、侵害の疑いがある場合に担当者に警告されるよう構成することが求められます。IDS/IPSアプライアンス製品を境界部分や重要なポイントに導入したり、ホストベースのIDS/IPSソリューションを対象インスタンスに導入したりすることによって実現します。AWSのサービスであるGuardDutyによっても悪意あるアクティビティなどの監視が可能ですが、ネットワークパケットデータのコンテンツ検査まではしないことからPCI DSSへの準拠性についてQSA(認定セキュリティ評価機関)によって意見が分かれているとあり留意が必要です。
  • 変更検出メカニズムによる監視
    重要なシステムファイルや構成ファイル、コンテンツなどに対する変更有無を監視し、担当者に警告されるよう構成することが求められます。AWSサービスの構成設定はAWS Configを有効化し、EC2インスタンス上のファイルは変更監視機能を持つソリューションを導入する等によって変更監視の仕組みを確立することが可能です。

要件12:すべての担当者の情報セキュリティに対応するポリシーを維持する

本要件では情報セキュリティポリシーとプログラムの維持が求められますが、AWSプラットフォーム上でのポリシーの確立や維持は利用者責任です。また、PCI DSSへの準拠ステータスの監視などによりAWSなどのサードパーティプロバイダを管理することが求められます。加えて、AWSから提供されるインシデント対応に関するガイダンス(EC2インスタンスのメモリダンプファイル取得方法など)を確認して、セキュリティインシデント発生時の対応計画に反映する必要があります。

まとめ

クレジットカード業界のセキュリティ基準であるPCI DSSをベースにAWSプラットフォーム上でセキュアにシステムを構成する際の留意点について全3回にわたって紹介してきました。
ご紹介してきたなかで特に留意いただきたいポイントとして以下の点が挙げられます。

  • セグメンテーションによるスコープの最小化
    環境の分離(AWSアカウント分割)やネットワークの分離(VPC/Security Groupによるアクセス制御)などの手段によりセグメンテーション境界を設けて重要な情報を取り扱う領域を他の環境から分離しましょう。すべての環境に対して同レベルの対策を講じることには限界があります。特に守るべき範囲にフォーカスして、重要な情報の暗号化や厳格な鍵管理などPCI DSSレベルの対策を講じていくことが推奨されます。
  • 各要件で関連するAWSサービスの理解、責任範囲の正確な把握
    責任共有モデルに基づいて自身の責任範囲を把握したうえでPCI DSS要件などに沿った対策を確実に講じる必要があります。EC2インスタンス上にて自分たちでオペレーティングシステムから構築しているような場合は責任の所在が分かりやすいのですが、AWSマネージドのサービスを利用しているような場合において対策が抜け漏れてしまうケースがみられます。例えばS3のようなストレージサービスを使用する場合に、インターネットからアクセスできないよう構成したり、重要な情報が置かれる領域に対して厳格なアクセス制御を行ったり、必要と考えられるログを有効化したりする責任は利用者にあります。自分たちが利用するAWSのサービスを正確に理解し、必要な対策に漏れのないよう注意しましょう。

PCI DSSは守るべき情報を保護するためのセキュリティ対策が具体的かつ体系的にまとめられています。AWSプラットフォームでシステム構築するにあたり、カード情報を扱うシステムに限らず様々なシステムでPCI DSSを活用していただければ幸いです。

 

参考リソース

お問い合わせ

AWSなどのパブリッククラウド環境のセキュリティについてまずは現状把握が重要です。PCI DSSなどのセキュリティ基準に基づいたアセスメントサービス、各種セキュリティ診断サービスなどでのご支援が可能です。

また、本コラムではAWSのガイダンスをもとに各種AWSサービスを活用してのセキュリティ対策を中心に説明しましたが、マルチクラウドやハイブリッドクラウドでの対応、24h365dでの監視、より厳格な情報保護が求められている場合などAWSサービスだけではカバーできない点について弊社ソリューションにより実現可能な範囲もございます。お気軽にお問い合わせください。
https://www.intellilink.co.jp/contact-us.aspx

※Amazon Web Services、「Powered by Amazon Web Services」ロゴ、およびかかる資料で使用されるその他のAWS商標は、米国および/またはその他の諸国における、Amazon.com, Inc.またはその関連会社の商標です。

PCI DSSで学ぶAWSセキュリティ③ ~要件別のセキュリティ対策後編~