AWS Fargate 活用 PCI DSS で疲弊しないための...アプリケーション構成（概要）...

© 2020, Amazon Web Services, Inc. or its affiliates. All rights reserved.

PCI DSS で疲弊しないためのAWS Fargate 活用

コイニー株式会社

江良巧

自己紹介

● @gushernobindsme

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

● サーバサイドエンジニア○ AWS/Java/Spring Boot

今日の話

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

● PCI DSS に耐えうるインフラの構築には、マネージドサービスの活用が鍵○ コイニーではこの文脈で AWS Fargate がうまくハマった

● 監査業務を省力化して、プロダクトの価値向上にフォーカスしよう

アジェンダ

● コイニーと PCI DSS○ コイニーが提供するサービス

○ システム構成

● これまでのセキュリティ対策

● コイニーでの AWS Fargate 導入

● 今後の展望

コイニーと PCI DSS

コイニーが提供するサービス

店舗・対面QR決済

Coineyスキャン

オンライン決済

Coineyペイジ

店舗・対面クレジット決済

Coineyターミナル

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

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

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

● プロダクトの信頼：お金を扱う上で、この製品は大丈夫か○ ここの信頼を得るうえで PCI DSS への準拠が重要な意味を持つ

PCI DSS とは

● クレジットカード会員の情報を保護することを目的に定められた、クレジットカード業

界の情報セキュリティ基準

● 国際カードブランドである American Express、Discover、JCB、MasterCard、VISA

の 5 社によって策定

● カード情報を「保存、処理、伝送」する事業者が対象（カード会社、カード加盟店、銀

行、決済代行サービス企業など）

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

安全なネットワークの構築と維持

要件 1 カード会員データを保護するために、ファイアウォールをインストールして構成を維持する

要件 2 システムパスワードおよびその他のセキュリティパラメータにベンダ提供のデフォルト値を使用しない

カード会員データの保護

要件 3 保存されたカード会員データを保護する

要件 4 オープンな公共ネットワーク経由でカード会員データを伝送する場合、暗号化する

脆弱性管理プログラムの整備

要件 5 アンチウィルスソフトウェアまたはプログラムを使用し、定期的に更新する

要件 6 安全性の高いシステムとアプリケーションを開発し、保守する

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

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

要件 8 コンピュータにアクセスできる各ユーザに一意の ID を割り当てる

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

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

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

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

情報セキュリティポリシーの整備要件 12 すべての担当者の情報セキュリティポリシーを整備する

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

● サービス開始当初から継続して準拠

● 現在は最新 Version の 3.2 に準拠

● PCI DSS 認証取得の方法○ PCI SSC によって認定された審査機関（QSA）によるオンサイト

審査を年に一回実施

○ PCI SSC 認定のスキャニングベンダー（ASV）によるネットワーク

スキャンを四半期に一回実施

● クレジットカード情報は通過のみ非保持

システム構成

マーチャント側

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

社内側

コイニーが提供するサービス・制作物

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

Backend

Frontend Mobile

新サーバサイドアプリケーション

旧 Web 管理画面新 Web 管理画面社内管理画面

コイニーペイジ

旧サーバサイドアプリケーション

旧 iOS アプリ新 iOS アプリ Android アプリ

マイクロサービスA

マイクロサービスB

マイクロサービスC

マイクロサービスD

マイクロサービスE

マイクロサービスF

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

● Ruby on Rails ➡ Spring Boot に移行中○ 移行作業はストラングラーパターンで段階的に実施

○ 新機能を追加する際は Spring Boot 側に実装

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

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

● 新アプリは AWS Elastic Beanstalk 上で稼働○ 2019 年度から Amazon ECS（AWS Fargate）も使うようになりました

■ ☝今回の話の焦点はここ

インフラ構成（概要）

インフラ構成（概要）

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

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

○ Radius OTP

○ SoftEther VPN

○ AD Controll

普通に作って出すだけでは不足

セキュリティ要件に耐えられるインフラ構成にする必要がある



















この部分にフォーカスして

説明します

これまでのセキュリティ対策

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

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

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

● 要件 11：侵入検知・変更検出についての要件

PCI DSS 要件 5 の概要

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

※ 5.4 の文書化要求に関する要件はここでは省略します。

要件 No 要求事項

5.1 悪意のあるソフトウェアの影響を受けやすいすべてのシステム（特にパーソナルコンピュータとサーバ）に、ウィルス対策ソフトウェアを導入する

5.2 すべてのウィルス対策メカニズムが以下のように維持されていることを、確実にする・最新の状態である・定期的にスキャンを行う・PCI DSS 要件 10.7 に従って監査ログを生成・保持する

5.3 ウィルス対策メカニズムがアクティブに実行されており、経営陣からケースバイケースで期間を限って特別に許可されない限り、ユーザが無効にしたり、変更できないことを確実にする


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

※ 6.3〜6.7 のアプリケーション開発プロセス等に関する要件はここでは省略します。


6.1 セキュリティ脆弱性情報の信頼できる社外提供元を使ってセキュリティの脆弱性を識別し、新たに発見されたセキュリティの脆弱性にリスクのランク（「高」、「中」、「低」など）を割り当てるプロセスを確立する

6.2 すべてのシステムコンポーネントとソフトウェアに、ベンダ提供のセキュリティパッチがインストールされ、既知の脆弱性から保護されている事を確実にする。「高」リスクと「緊急」のセキュリティパッチは、リリース後 1 カ月以内にインストールする


● 侵入検知・変更検出についての要件

※ 11.1〜11.3 の ASV スキャン、ペネトレーションテスト等に関する要件はここでは省略します。


11.4 侵入検知システムおよび/または侵入防止手法を使用して、ネットワークへの侵入を検知および/または防止する。カード会員データ環境との境界およびカード会員データ環境内の重要なポイントを通過するすべてのトラフィックを監視し、侵害の疑いがある場合は担当者に警告する・すべての侵入検知および防止エンジン、ベースライン、シグネチャを最新状態に保つ

11.5 変更検出メカニズム（ファイル整合性監視ツールなど）を導入して重要なシステムファイル、設定ファイル、またはコンテンツファイルの不正な変更(変更、追加、削除を含む)を担当者に警告し、重要なファイルの比較を少なくとも週に一度実行するようにソフトウェアを設定する

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

● 要件 5：ウイルス対策についての要件○ ClamAV で日次スキャン

○ 新バージョンがリリースされたらソフトウェアを更新

● 要件 6：ミドルウェアの脆弱性についての要件○ Amazon Inspector で週次スキャン

○ 脆弱性が見つかったらミドルウェアを更新

● 要件 11：侵入検知・変更検出についての要件○ Deep Security でリアルタイム監視

○ （運用は自動化できるが、ライセンス料が高額）

EC2

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

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

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

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

EC2

PCI DSS 要件 5 の課題

● 運用上の負荷が高い○ ウイルス定義ファイルの更新は自動で行える

○ ClamAV のソフトウェア自体の更新作業は別途行う必要がある

○ 運用していると、結構な頻度でアップデートがある

● 監査証跡の提出が手間○ 下記の作業が漏れなく行えていることを QSA に対して証明する必要がある

■ ウイルススキャンの実施

■ 定義ファイルの更新

○ 各ロググループから一生懸命ログを集めて回るのが一苦労 ……

EC2


● Amazon Inspector を使った脆弱性スキャンを週次で実行○ Amazon Inspector エージェントを各サーバにインストール

● スキャン結果を slack に通知

● 脆弱性が見つかったら一ヶ月以内に対応

EC2


EC2


● 運用上の負荷が高い○ Amazon Inspector がやってくれるのは「検知」まで

○ サーバに一つ一つ ssh ログインして yum update をかける必要がある

○ 運用していると、ほぼ毎月、何らかの脆弱性が見つかる

● リスクの高い作業が必要になる○ 脆弱性が見つかった場合、以下のような手順を実施している

■ メンテ対象のインスタンスをロードバランサから外す

■ yum update 実行

■ インスタンスを再起動

■ 古い kernel を削除（Amazon Inspector の誤検知を防ぐため）

■ メンテが終わったインスタンスをロードバランサに戻す

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

EC2


● Trend Micro Deep Security を導入し、侵入・変更のイベントをリアルタイム検知○ Deep Security の管理サーバを EC2 上に構築

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

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

EC2


● ライセンス料が高い○ 新たにサーバを立てる場合、DeepSecurity エージェントのインストールが必要になる

○ DeepSecurity で管理する対象のサーバが増えると、その分ライセンス料がかさむ

○ セキュリティのための投資が事業の足枷になってしまう

EC2

監査は準拠するまでだけでなく準拠した後も大変

…でもこの作業ってユーザの役に立ってるんだっけ？

「差別化に繋がらない重労働」

コイニーでの AWS Fargate 導入

Amazon ECS

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

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

● AWS 上の各種サービスとの連携がスムーズに行えて便利

AWS Fargate

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

○ EC2 起動タイプ

● AWS Fargate を使うことで、コンテナを動かすためのインフラストラクチャを抽象化

できる○ 以下のような悩みから解放される

■ 「EC2 のインスタンスタイプどれくらいにしよう」とか

■ 「EBS のサイズはこれくらいかな」とか

EC2 VS Fargate

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

● Fargate 起動タイプだと、EC2 を意識する必要がなくなる○ つまり、コンテナ上で動くアプリケーションの開発に集中できる

どうやって始める？

● まずは小さく始めてみる○ ちょうど 2019 年に大きめの開発プロジェクトがあった

○ 要件的に、別サービスに切り出せそうなサービスが出てきそう

○ まずはこのサービスで試してみて、それから全体に適用するか判断しよう

● 事前に Responsibility Summary をよく確認しておく○ AWS のサービスも PCI DSS の監査を受けている

○ Responsibility Summary を参照して、自分たちで担保が必要なラインを見極めておこう

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

Code Build

1.PullRequest の作成、更新を Webhook で検知

1.マネジメントコンソールから直接実行

ECR

2.アプリケーションのbuild docker push

Code BuildCode Pipeline

ECS

4.docker pull 脆弱性スキャン

3.DockerImageの脆弱性サーバーへリクエスト

Container Cluster（ECS Fargate）

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

Code Pipeline

Code Deploy

Target Group

Container

ALB

1.CodePipelineを起動する　トリガーを作成

2.CodeDeploy起動

3.デプロイ

BFF から API 呼び出し

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

● 要件 5：ウイルス対策についての要件○ 追加作業なし

● 要件 6：ミドルウェアの脆弱性についての要件○ Amazon ECR イメージスキャンで週次スキャン

○ 脆弱性が見つかったらコンテナイメージを更新

● 要件 11：侵入検知・変更検出についての要件○ 追加作業なし

Fargate

PCI DSS 要件 5 の考え方

● Responsibility Summary を参照

● Fargate を使う場合、コンテナを動かすためのインフラストラクチャを抽象化できるた

め、サーバに対するウイルス対策は不要と判断○ ClamAV を運用する手間がなくせる、と判断

Fargate




め、サーバ自体の OS・ミドルウェアの脆弱性対策は不要と判断○ Amazon Inspector を運用する手間がなくせる、と判断

● ただし、コンテナイメージの管理については利用者の責任範囲○ 定期的にスキャンする仕組みが必要

○ 高レベルの脆弱性が検知されたら一ヶ月以内に対策できていることが必要

Fargate

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

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

● スキャン結果を slack に通知

● 脆弱性が見つかったら一ヶ月以内に対応

ECRLambda EventBridge

EventBridge

Lambda

Fargate

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

Fargate




め、サーバ自体の侵入検知・変更検出についての対策は不要と判断○ Deep Security を導入するコストが減らせる、と判断

Fargate

EC2 運用との比較

要件 No EC2 ECS（Fargate）

要件 5ClamAV で日次スキャン新バージョンがリリースされたらソフトウェアを更新

追加作業なし

要件 6Amazon Inspector で週次スキャン脆弱性が見つかったらミドルウェアを更新

Amazon ECR イメージスキャンで週次スキャン脆弱性が見つかったらコンテナイメージを更新

要件 11Deep Security でリアルタイム監視（運用は自動化できるが、ライセンス料が高額）

追加作業なし

結果…

2019年度も無事PCI DSS に準拠できました🎉

今後の展望

今後の展望

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

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

● より、プロダクト開発に集中できる状況を作りたい💪○ まだサービスの大部分は EC2 or Elastic Beanstalk で稼働している

○ Fargate に移行することで、監査対応をより効率化していきたい

○ 他の管理系サーバも EC2 からマネージドサービスに移行したい

まとめ

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

● PCI DSS に耐えうるインフラの構築には、マネージドサービスの活用が鍵○ コイニーではこの文脈で AWS Fargate がうまくハマった

● 監査業務を省力化して、プロダクトの価値向上にフォーカスしよう

AWS Fargate 活用 PCI DSS で疲弊しないための...アプリケーション構成（概要）...

Documents

Transcript of AWS Fargate 活用 PCI DSS で疲弊しないための...アプリケーション構成（概要）...