Upgrade to Pro — share decks privately, control downloads, hide ads and more …

2024/05/23_SecurityJAWS登壇

snowwhite
May 23, 2024
650

 2024/05/23_SecurityJAWS登壇

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

snowwhite

May 23, 2024
Tweet

Transcript

  1. 自己紹介 ・Name・・・砂岡 雪 a.k.a 白”雪姫” ・Profile・・・2023年8月 ゆめみに入社。 入社前は10年ほど決済システムの構築・運用・保守・リプ レースを行ってきている。 ネットワークとセキュリティをメインにしつつ も現在は、SRE方面の仕事もしている。

    苗字で呼ばれるのを嫌うため、下の名前か X名で 呼んで頂く事が多い。 白”雪姫”はしらゆきひめではなくしらゆきと読みます。 ・Liked Service・・・Amazon Inspector ・X(旧Twitter)・・・@yuri_snowwhite ・Blog・・・https://kohaku-kageroh.hatenablog.com/
  2. 既存環境のコストが高い!もっと安くして!!! by 社長 要件は以下の通り ・既にPCI DSSに準拠した環境である →クレジットカード決済システムであるため継続して準拠が必要 ・既存はPCI DSS準拠のためにAWSで構築された管理VPC(以下、管理VPC)と自分たちで 構築するサービスVPCがあり、稼働費用がとても高い →管理VPCは自分たちが構築等ができない AWS環境が使われていて、

    これがとても高かった ・サービスVPCに存在するRDSはそのまま使いたい →決済トランザクションのみ管理している ・画面表示は必要なく、サーバ間の API通信がメインでブラウザで表示するのは管理側のト ランザクションデータのみ →管理側は見れなくても問題が無く API通信ができれば良いので EC2である必要が無い。
  3. サービス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群に偏っており、 通信経路も煩雑化していた。
  4. 満たしたセキュリティ要件 ・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の取り付けを簡単にして、保守性とセキュリティ性を 向上 →今までは、提供されていたセキュリティアプライアンスを使っていたので、 保守性、セキュリティの担保が説明しずらかった
  5. WAFで使ったルール ・SQLインジェクション対策 SQL database ・認証制御不備 Bot Control ・アクセス設定の不備 Bot Control,Admin

    Protection ・Cross-Site Scripting(XSS) Admin protection ・既知の脆弱性対策 Core rule set, SQL database ・不十分なログと監視設定 Bot Control 他にカスタマイズのルールをいくつか入れています(アプリケーション言語の既知の脆弱性対策など)
  6. リプレースして楽になったこと ・インフラの大部分がフルマネージドにできた →監査の際に、AWS Artifactからダウンロードを行った PCI DSSのAOCで準拠にしてもらえる ・インフラの展開内容が決まっているので IaC化も夢じゃ無くなった →仕様書レビューではなくコードレビューに切り替えることも夢じゃ無くなり、開発に人がコードレ ビューできるようになった。

    ※当時は、1人インフラだったので、外部にレビューを依頼してました ・定期スキャニングに関しては開発コードのみが対象となった。 →通常はPCIの要件で4半期(つまり90日)に1度、ネットワーク層の脆弱性のスキャンが免除になっ た ※AWS Artifactで準拠が確認できるため、不要となった。 ・仕様書などの作成資料が大幅に減った →おかげで、用意すべき監査資料が減った