2024/05/23_SecurityJAWS登壇

2024年5月23日のSecurityJAWSに登壇を行ったときの資料です。

Transcript

1. APIGWとLambdaで 決済APIをPCI DSSに準拠したお話 2024/05/23 株式会社ゆめみ　砂岡雪
2. 自己紹介 ・Name・・・砂岡 雪 a.k.a 白”雪姫” ・Profile・・・2023年8月　ゆめみに入社。 入社前は10年ほど決済システムの構築・運用・保守・リプ レースを行ってきている。 ネットワークとセキュリティをメインにしつつ も現在は、SRE方面の仕事もしている。 苗字で呼ばれるのを嫌うため、下の名前か X名で 呼んで頂く事が多い。 白”雪姫”はしらゆきひめではなくしらゆきと読みます。 ・Liked Service・・・Amazon Inspector ・X（旧Twitter）・・・@yuri_snowwhite ・Blog・・・https://kohaku-kageroh.hatenablog.com/
3. 注意事項 現在も稼働している某社の決済システムを元にお話しします。 そのため部分部分で一部、表示をしていない機能・構成については割愛しております。 今回の登壇での、セキュリティの説明においては問題がありません。 ご了承いただければ幸いです。 m( _ _ )m
4. そもそもPCI DSSとは？ クレジットカード決済における、システムを構築する際 に、クレジットカード会員データ(以下のスライドでは PANデータ）を安全に扱うことを目的としたセキュリ ティ基準のこと。 12個の要件と6個の目的に準拠する必要がある。
5. なぜ、APIGWとLambdaで PCI DSSに準拠することになった？
6. 既存環境のコストが高い！もっと安くして！！！　by　社長 要件は以下の通り ・既にPCI DSSに準拠した環境である →クレジットカード決済システムであるため継続して準拠が必要 ・既存はPCI DSS準拠のためにAWSで構築された管理VPC(以下、管理VPC)と自分たちで 構築するサービスVPCがあり、稼働費用がとても高い →管理VPCは自分たちが構築等ができない AWS環境が使われていて、 これがとても高かった ・サービスVPCに存在するRDSはそのまま使いたい →決済トランザクションのみ管理している ・画面表示は必要なく、サーバ間の API通信がメインでブラウザで表示するのは管理側のト ランザクションデータのみ →管理側は見れなくても問題が無く API通信ができれば良いので EC2である必要が無い。
7. サービスVPC群 管理VPC群 既存環境の概略図(もの凄くざっくり) Availability Zone Availability Zone Availability Zone Availability Zone VPC Public subnet VPC Public subnet Private subnet VPC Public subnet Private subnet WEB WEB Mail SimpleAD SimpleAD Proxy VPN セキュリティ管理 コストが管理VPC群に偏っており、 通信経路も煩雑化していた。
8. とりあえず、管理VPCは解約する方針。 既存の通信でAPI通信ができれば良いなら ApacheとかのWebサーバも要らない。 Amazon CloudWatch上で見るとトランザクショ ンも多くない、メール用に立ち上げてるインスタ ンスも送信専用と言うことであればAmazon SES やAmazon API Gatewayに移行もできるので は？
9. そんな訳で、設計してみました！ ▪最終的に使ったサービス Amazon VPC NAT Gateway AWS WAF AWS Lambda Amazon CloudWatch Amazon Cloudfront Amazon S3 Amazon RDS Amazon RDS Proxy
10. 決済システムVPC サービスVPC リプレース後の構成図はこんな感じになりました(部分的に非表示)
11. 満たしたセキュリティ要件 ・PCI DSSの対象環境は決済システム VPCのみ ・RDSは、既存のトランザクションデータの保存要件の関係上から既存 RDSを利用 →PCI DSSの要件対象になるカードデータ情報が無いため、対象外へ ・ピアリング接続を行いローカル IP通信をすることで、VLAN分離の要件から回避 →ピアリング間の通信・接続出来るサービスを限定もセキュリティグループで確保、 年に1度VPCAnalyzerで通信要件を確認 ・AWS WAFのマネジメントルールを用いて、基本的セキュリティ対策 (OWASPのTOP10やNISTに書かれたセ キュリティ基準に対応） ・ログは全てCloudWatchLogsへ出力して1年間保存 ・Lambdaから契約決済先へに通信を行うときは NAT Gatewayを経由して通信 →不用意にLambdaそのものにアクセスをさせないため ・API Gatewayを用いることで、オリジナルドメイン・ WAFの取り付けを簡単にして、保守性とセキュリティ性を 向上 →今までは、提供されていたセキュリティアプライアンスを使っていたので、 保守性、セキュリティの担保が説明しずらかった
12. 発生した問題
13. 一部加盟店に提供してた決済用画面が利用できなくなった PCI DSSに準拠させる都合上、カード会員データを通過させるス コープを最小限にしていたため、決済用画面が利用出来なくなる 問題が発生。 このリプレースの機会にS3上に、Cloudfront＋S3を用いて、作 成、Cloud front内でルーティングを行うことで、提供していた画 面を表示することで対処。 API Gatewayに接続しているCloudfrontと共有化しているた め、結果的にユーザから見たURL等が増えることは無く安心。
14. WAFがPOST通信をデフォルトでは拒否 通常のWEBアクセスではGETリクエストで行われる通信だが、 決済システムは通信を読み取られないようにするという一貫 で、POSTリクエストが通常使われる。 そのため、利用したルールの関係で、 AWS WAFでは拒否され てしまった。 拒否をされたルールを検知モード変更し、一定以上連続で通信 した場合にのみアラートを出すように設定を変更を実施。 PCI DSSの要件では、WAFもしくはIPS/IDSを用いて通信を検 出することが要件のため取り外すことはできなかったため。
15. マネジメントコンソールのログイン画面がPCI DSSの対象に ・AWSマネジメントコンソールのログイン画面が監査対象となってしまい、 ログインのロックアウトと検知を入れる必要が出てきた →ロックアウトはできないので、代替コントロールとして、 CloudTrailの監視ログを有効にしてCloudWatchで監視。 6回目をミスしたら通知するように設定を変更 この時は、通知のみで良かったが、 Lambda関数を呼び出して、ログイン出来ても All Denyにする等の対処ができたかなと思っています。
16. WAFで使ったルール ・SQLインジェクション対策 SQL database ・認証制御不備 Bot Control ・アクセス設定の不備 Bot Control,Admin Protection ・Cross-Site Scripting（XSS） Admin protection ・既知の脆弱性対策 Core rule set, SQL database ・不十分なログと監視設定 Bot Control 他にカスタマイズのルールをいくつか入れています（アプリケーション言語の既知の脆弱性対策など）
17. リプレースして楽になったこと ・インフラの大部分がフルマネージドにできた →監査の際に、AWS Artifactからダウンロードを行った PCI DSSのAOCで準拠にしてもらえる ・インフラの展開内容が決まっているので IaC化も夢じゃ無くなった →仕様書レビューではなくコードレビューに切り替えることも夢じゃ無くなり、開発に人がコードレ ビューできるようになった。 ※当時は、1人インフラだったので、外部にレビューを依頼してました ・定期スキャニングに関しては開発コードのみが対象となった。 →通常はPCIの要件で4半期（つまり90日）に1度、ネットワーク層の脆弱性のスキャンが免除になっ た ※AWS Artifactで準拠が確認できるため、不要となった。 ・仕様書などの作成資料が大幅に減った →おかげで、用意すべき監査資料が減った
18. ご静聴ありがとうございました。