PCI DSS で疲弊しないための AWS Fargate 活用コイニー株式会社江良巧 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.

(1)

PCI DSS で疲弊しないための 

AWS Fargate 活用 

コイニー株式会社  江良巧 

(2)

自己紹介 

● @gushernobindsme 

● コイニー株式会社 ⬅ 会計パッケージベンダ 

● サーバサイドエンジニア 

(3)

今日の話 

● FinTech 系のサービスには「信頼」が求められる 

● PCI DSS に耐えうるインフラの構築には、マネージドサービスの活用が鍵 

○ コイニーではこの文脈で AWS Fargate がうまくハマった  

(4)

アジェンダ 

● コイニーと PCI DSS  ○ コイニーが提供するサービス   ○ システム構成   ● これまでのセキュリティ対策  ● コイニーでの AWS Fargate 導入  ● 今後の展望 

(5)

(6)

(7)

(8)

店舗・対面 QR決済 Coineyスキャンオンライン決済 Coineyペイジ店舗・対面クレジット決済 Coineyターミナル

(9)

(10)

FinTech 系サービスには「信頼」が求められる 

● 会社の信頼：お金を扱う上で、自己資本は一定満たされるか 

● 経営チームの信頼：お金を扱う上で、この経営陣は大丈夫か 

● プロダクトの信頼：お金を扱う上で、この製品は大丈夫か 

(11)

PCI DSS とは 

● クレジットカード会員の情報を保護することを目的に定められた、クレジットカード業界の情報セキュリティ基準  ● 国際カードブランドである American Express、Discover、JCB、MasterCard、VISA の 5 社によって策定  ● カード情報を「保存、処理、伝送」する事業者が対象（カード会社、カード加盟店、銀行、決済代行サービス企業など） 

(12)

PCI DSS で定められている 12 の要件 

安全なネットワークの構築と維持  要件 1  カード会員データを保護するために、ファイアウォールをインストールして構成を維持する  要件 2  システムパスワードおよびその他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない  カード会員データの保護  要件 3  保存されたカード会員データを保護する  要件 4  オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する  脆弱性管理プログラムの整備  要件 5  アンチウィルスソフトウェアまたはプログラムを使用し、定期的に更新する  要件 6  安全性の高いシステムとアプリケーションを開発し、保守する  強固なアクセス制御手法の導入  要件 7  カード会員データへのアクセスを、業務上必要な範囲内に制限する  要件 8  コンピュータにアクセスできる各ユーザに一意の ID を割り当てる  要件 9  カード会員データへの物理アクセスを制限する  ネットワークの定期的な監視およびテスト  要件 10  ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する  要件 11  セキュリティシステムおよびプロセスを定期的にテストする  情報セキュリティポリシーの整備  要件 12  すべての担当者の情報セキュリティポリシーを整備する 

(13)

コイニーにおける PCI DSS 対応 

● サービス開始当初から継続して準拠  ● 現在は最新 Version の 3.2 に準拠  ● PCI DSS 認証取得の方法  ○ PCI SSC によって認定された審査機関（QSA）によるオンサイト審査を年に一回実施   ○ PCI SSC 認定のスキャニングベンダー（ASV）によるネットワークスキャンを四半期に一回実施   ● クレジットカード情報は通過のみ非保持 

(14)

(15)

マーチャント側  

Coineyアプリ   ウェブ管理画面   社内管理画面 

社内側 

(16)

アプリケーション構成（概要） 

Backend  Frontend  Mobile  新サーバサイドアプリケーション   旧 Web 管理画面   新 Web 管理画面   社内管理画面   コイニーペイジ   旧サーバサイドアプリケーション  

旧 iOS アプリ   新 iOS アプリ   Android アプリ   マイクロサービスA   マイクロサービスB   マイクロサービスC   マイクロサービスD   マイクロサービスE   マイクロサービスF  

(17)

アプリケーション構成（概要） 

● Ruby on Rails ➡ Spring Boot に移行中 

○ 移行作業はストラングラーパターンで段階的に実施   ○ 新機能を追加する際は Spring Boot 側に実装  

○ 機能の特性に応じたアーキテクチャを採用できるよう、マイクロサービス化も少しずつ推進  

● 旧アプリは Amazon EC2 上で稼働 

● 新アプリは AWS Elastic Beanstalk 上で稼働 

○ 2019 年度から Amazon ECS（AWS Fargate）も使うようになりました   ■ ☝今回の話の焦点はここ  

(18)

(19)

インフラ構成（概要） 

● VPC を Operation/Test/Payment に分割 

○ テスト環境と本番環境を物理的に分離し、VPC 間の通信を遮断  

● Operation VPC には PCIDSS 要件の遵守に必要な各種サーバ群を配置 

○ Deep Security Manager   ○ Radius OTP 

○ SoftEther VPN   ○ AD Controll 

(20)

(21)

セキュリティ要件に耐えられる 

インフラ構成にする必要がある 

(22)

PCI DSS で定められている 12 の要件 

安全なネットワークの構築と維持  要件 1  カード会員データを保護するために、ファイアウォールをインストールして構成を維持する  要件 2  システムパスワードおよびその他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない  カード会員データの保護  要件 3  保存されたカード会員データを保護する  要件 4  オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する  脆弱性管理プログラムの整備  要件 5  アンチウィルスソフトウェアまたはプログラムを使用し、定期的に更新する  要件 6  安全性の高いシステムとアプリケーションを開発し、保守する  強固なアクセス制御手法の導入  要件 7  カード会員データへのアクセスを、業務上必要な範囲内に制限する  要件 8  コンピュータにアクセスできる各ユーザに一意の ID を割り当てる  要件 9  カード会員データへの物理アクセスを制限する  ネットワークの定期的な監視およびテスト  要件 10  ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する  要件 11  セキュリティシステムおよびプロセスを定期的にテストする  情報セキュリティポリシーの整備  要件 12  すべての担当者の情報セキュリティポリシーを整備する 

(23)

PCI DSS で定められている 12 の要件 

安全なネットワークの構築と維持  要件 1  カード会員データを保護するために、ファイアウォールをインストールして構成を維持する  要件 2  システムパスワードおよびその他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない  カード会員データの保護  要件 3  保存されたカード会員データを保護する  要件 4  オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する  脆弱性管理プログラムの整備  要件 5  アンチウィルスソフトウェアまたはプログラムを使用し、定期的に更新する  要件 6  安全性の高いシステムとアプリケーションを開発し、保守する  強固なアクセス制御手法の導入  要件 7  カード会員データへのアクセスを、業務上必要な範囲内に制限する  要件 8  コンピュータにアクセスできる各ユーザに一意の ID を割り当てる  要件 9  カード会員データへの物理アクセスを制限する  ネットワークの定期的な監視およびテスト  要件 10  ネットワークリソースおよびカード会員データへのすべてのアクセスを追跡および監視する  要件 11  セキュリティシステムおよびプロセスを定期的にテストする  情報セキュリティポリシーの整備  要件 12  すべての担当者の情報セキュリティポリシーを整備する  この部分に   フォーカスして   説明します  

(24)

(25)

まずは PCI DSS 要件の詳細を説明 

● 要件 5：ウイルス対策についての要件 

● 要件 6：ミドルウェアの脆弱性についての要件 

(26)

PCI DSS 要件 5 の概要 

● ウイルス対策についての要件  ※ 5.4 の文書化要求に関する要件はここでは省略します。  要件 No  要求事項  5.1  悪意のあるソフトウェアの影響を受けやすいすべてのシステム（特にパーソナルコンピュータとサーバ）に、ウィルス対策ソフトウェアを導入する   5.2  すべてのウィルス対策メカニズムが以下のように維持されていることを、確実にする   ・最新の状態である   ・定期的にスキャンを行う   ・PCI DSS 要件 10.7 に従って監査ログを生成・保持する   5.3  ウィルス対策メカニズムがアクティブに実行されており、経営陣からケースバイケースで期間を限って特別に許可されない限り、ユーザが無効にしたり、変更できないことを確実にする  

(27)

PCI DSS 要件 6 の概要 

● ミドルウェアの脆弱性についての要件  ※ 6.3〜6.7 のアプリケーション開発プロセス等に関する要件はここでは省略します。  要件 No  要求事項  6.1  セキュリティ脆弱性情報の信頼できる社外提供元を使ってセキュリティの脆弱性を識別し、新たに発見されたセキュリティの脆弱性にリスクのランク（「高」、「中」、「低」など）を割り当てるプロセスを確立する  6.2  すべてのシステムコンポーネントとソフトウェアに、ベンダ提供のセキュリティパッチがインストールされ、既知の脆弱性から保護されている事を確実にする。「高」リスクと「緊急」のセキュリティパッチは、リリース後 1 カ月以内にインストールする  

(28)

PCI DSS 要件 11 の概要 

● 侵入検知・変更検出についての要件  ※ 11.1〜11.3 の ASV スキャン、ペネトレーションテスト等に関する要件はここでは省略します。  要件 No  要求事項  11.4  侵入検知システムおよび/または侵入防止手法を使用して、ネットワークへの侵入を検知および/または防止する。カード会員データ環境との境界およびカード会員データ環境内の重要なポイントを通過するすべてのトラフィックを監視し、侵害の疑いがある場合は担当者に警告する   ・すべての侵入検知および防止エンジン、ベースライン、シグネチャを最新状態に保つ   11.5  変更検出メカニズム（ファイル整合性監視ツールなど）を導入して重要なシステムファイル、設定ファイル、またはコンテンツファイルの不正な変更(変更、追加、削除を含む)を担当者に警告し、重要なファイルの比較を少なくとも週に一度実行するようにソフトウェアを設定する  

(29)

PCI DSS 対策としてやっていること 

● 要件 5：ウイルス対策についての要件  ○ ClamAV で日次スキャン   ○ 新バージョンがリリースされたらソフトウェアを更新   ● 要件 6：ミドルウェアの脆弱性についての要件  ○ Amazon Inspector で週次スキャン   ○ 脆弱性が見つかったらミドルウェアを更新   ● 要件 11：侵入検知・変更検出についての要件  ○ Deep Security でリアルタイム監視   ○ （運用は自動化できるが、ライセンス料が高額）   EC2 

(30)

PCI DSS 要件 5 でやっていること 

● ClamAV によるウイルススキャンを cron で日次で実行 

● スキャンの実施ログは Amazon CloudWatch Logs に転送 

● 問題を検知したら、管理者宛にメールで通知 

(31)

PCI DSS 要件 5 の課題 

● 運用上の負荷が高い  ○ ウイルス定義ファイルの更新は自動で行える   ○ ClamAV のソフトウェア自体の更新作業は別途行う必要がある   ○ 運用していると、結構な頻度でアップデートがある   ● 監査証跡の提出が手間  ○ 下記の作業が漏れなく行えていることを QSA に対して証明する必要がある   ■ ウイルススキャンの実施   ■ 定義ファイルの更新   ○ 各ロググループから一生懸命ログを集めて回るのが一苦労 ……  EC2 

(32)

PCI DSS 要件 6 でやっていること 

● Amazon Inspector を使った脆弱性スキャンを週次で実行  ○ Amazon Inspector エージェントを各サーバにインストール   ● スキャン結果を slack に通知  ● 脆弱性が見つかったら一ヶ月以内に対応  EC2 

(33)

PCI DSS 要件 6 でやっていること 

(34)

PCI DSS 要件 6 でやっていること 

(35)

PCI DSS 要件 6 の課題 

● 運用上の負荷が高い  ○ Amazon Inspector がやってくれるのは「検知」まで   ○ サーバに一つ一つ ssh ログインして yum update をかける必要がある   ○ 運用していると、ほぼ毎月、何らかの脆弱性が見つかる   ● リスクの高い作業が必要になる  ○ 脆弱性が見つかった場合、以下のような手順を実施している   ■ メンテ対象のインスタンスをロードバランサから外す   ■ yum update 実行   ■ インスタンスを再起動  

■ 古い kernel を削除（Amazon Inspector の誤検知を防ぐため）   ■ メンテが終わったインスタンスをロードバランサに戻す  

○ 手順を誤るとサービスが停止するリスクがある   EC2 

(36)

PCI DSS 要件 11 でやっていること 

● Trend Micro Deep Security を導入し、侵入・変更のイベントをリアルタイム検知 

○ Deep Security の管理サーバを EC2 上に構築  

○ 検知対象のサーバには Deep Security Agent をインストール  

● 不正な動きを検知したら、管理者宛にメールで通知 

(37)

PCI DSS 要件 11 の課題 

● ライセンス料が高い  ○ 新たにサーバを立てる場合、DeepSecurity エージェントのインストールが必要になる   ○ DeepSecurity で管理する対象のサーバが増えると、その分ライセンス料がかさむ   ○ セキュリティのための投資が事業の足枷になってしまう   EC2 

(38)

監査は準拠するまでだけでなく 

準拠した後も大変 

(39)

…でもこの作業って 

(40)

(41)

(42)

Amazon ECS 

● Docker コンテナを簡単に実行、停止、管理できるコンテナ管理サービス 

● ローカルで作ったコンテナを簡単に AWS 環境でデプロイできる 

(43)

AWS Fargate 

● AWS Fargate は ECS の起動タイプの一つ 

○ Fargate 起動タイプ   ○ EC2 起動タイプ   ● AWS Fargate を使うことで、コンテナを動かすためのインフラストラクチャを抽象化できる  ○ 以下のような悩みから解放される   ■ 「EC2 のインスタンスタイプどれくらいにしよう」とか   ■ 「EBS のサイズはこれくらいかな」とか  

(44)

EC2 VS Fargate 

● EC2 起動タイプだと、足元で動いている EC2 を意識する必要がある 

● Fargate 起動タイプだと、EC2 を意識する必要がなくなる 

(45)

どうやって始める？ 

● まずは小さく始めてみる  ○ ちょうど 2019 年に大きめの開発プロジェクトがあった   ○ 要件的に、別サービスに切り出せそうなサービスが出てきそう   ○ まずはこのサービスで試してみて、それから全体に適用するか判断しよう   ● 事前に Responsibility Summary をよく確認しておく  ○ AWS のサービスも PCI DSS の監査を受けている   ○ Responsibility Summary を参照して、自分たちで担保が必要なラインを見極めておこう  

(46)

インフラ構成 - ビルド環境 

Code Build  1.PullRequest の作成、更新   を Webhook で検知     1.マネジメントコンソール   から直接実行     ECR  2.アプリケーションのbuild   docker push     Code Build  Code Pipeline  ECS  4.docker pull   脆弱性スキャン     3.DockerImageの脆弱性   サーバーへリクエスト    

(47)

Container Cluster  （ECS Fargate） 

インフラ構成 - デプロイ環境 

Code Pipeline  Code Deploy  Target Group  Container  ALB  1.CodePipelineを起動する   　トリガーを作成     2.CodeDeploy起動   3.デプロイ   BFF から API 呼び出し  

(48)

PCI DSS 対策としてやったこと 

● 要件 5：ウイルス対策についての要件  ○ 追加作業なし   ● 要件 6：ミドルウェアの脆弱性についての要件  ○ Amazon ECR イメージスキャンで週次スキャン   ○ 脆弱性が見つかったらコンテナイメージを更新   ● 要件 11：侵入検知・変更検出についての要件  ○ 追加作業なし   Fargate 

(49)

PCI DSS 要件 5 の考え方 

● Responsibility Summary を参照  ● Fargate を使う場合、コンテナを動かすためのインフラストラクチャを抽象化できるため、サーバに対するウイルス対策は不要と判断  ○ ClamAV を運用する手間がなくせる、と判断   Fargate 

(50)

PCI DSS 要件 6 の考え方 

● Responsibility Summary を参照  ● Fargate を使う場合、コンテナを動かすためのインフラストラクチャを抽象化できるため、サーバ自体の OS・ミドルウェアの脆弱性対策は不要と判断  ○ Amazon Inspector を運用する手間がなくせる、と判断   ● ただし、コンテナイメージの管理については利用者の責任範囲  ○ 定期的にスキャンする仕組みが必要   ○ 高レベルの脆弱性が検知されたら一ヶ月以内に対策できていることが必要   Fargate 

(51)

PCI DSS 要件 6 でやったこと（コンテナ編） 

● Amazon ECR の API を使ったコンテナイメージのスキャンを週次で実行 

● スキャン結果を slack に通知  ● 脆弱性が見つかったら一ヶ月以内に対応  ECR  Lambda  EventBridge  EventBridge  Lambda  Fargate 

(52)

PCI DSS 要件 6 でやったこと（コンテナ編） 

(53)

PCI DSS 要件 11 の考え方 

● Responsibility Summary を参照  ● Fargate を使う場合、コンテナを動かすためのインフラストラクチャを抽象化できるため、サーバ自体の侵入検知・変更検出についての対策は不要と判断  ○ Deep Security を導入するコストが減らせる、と判断   Fargate 

(54)

EC2 運用との比較 

要件 No  EC2  ECS（Fargate）  

要件 5  ClamAV で日次スキャン  新バージョンがリリースされたらソフトウェアを更新  追加作業なし  要件 6  Amazon Inspector で週次スキャン  脆弱性が見つかったらミドルウェアを更新  Amazon ECR イメージスキャンで週次スキャン  脆弱性が見つかったらコンテナイメージを更新  要件 11  Deep Security でリアルタイム監視  （運用は自動化できるが、ライセンス料が高額）  追加作業なし 

(55)

(56)

2019年度も無事 

(57)

(58)

(59)

(60)

(61)

今後の展望 

● 事業として、まだまだやることは盛りだくさん 

● サービスの「信頼」を守るため PCI DSS 4.0 への対応も必要 

● より、プロダクト開発に集中できる状況を作りたい💪 

○ まだサービスの大部分は EC2 or Elastic Beanstalk で稼働している   ○ Fargate に移行することで、監査対応をより効率化していきたい   ○ 他の管理系サーバも EC2 からマネージドサービスに移行したい  

(62)

まとめ 

● FinTech 系のサービスには「信頼」が求められる 

● PCI DSS に耐えうるインフラの構築には、マネージドサービスの活用が鍵 

○ コイニーではこの文脈で AWS Fargate がうまくハマった  

(63)

PCI DSS で疲弊しないための AWS Fargate 活用 コイニー株式会社 江良 巧 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.