クレジットカード決済基盤を支えるSRE - 厳格な監査とSRE運用の両立 by 水口 洋輔

■ 発表カテゴリ

・Practices: SREの実践例と得られた教訓
・Architecture: SREの視点からのシステム設計

■ 発表概要（400字程度）

クレジットカード決済を扱う企業に要求されるPCI DSSというセキュリティ基準をご存知でしょうか。年1回の更新審査、監査ログのレビュー、多段の承認フローなど、厳格なコンプライアンス要件が課されます。

当社では、私たちSREがこれらの監査対応と準拠環境の運用を担当しています。監査証跡の取得やログレビューを手作業で対応すれば、SREが疲弊することになります。

私たちはこの課題に対して、SRE自身の運用負荷を最小化しつつ、セキュリティ要件をインフラ基盤で吸収するアプローチを取りました。AWSアカウント分離によるスコープ最小化、ECS FargateやCognitoなどマネージドサービスのフル活用、CI/CDへのセキュリティチェック組み込みなど、基本的なセキュリティ対策の積み重ねにより、開発速度を損なわずに堅牢なインフラ基盤を構築しています。

本セッションでは、当社のAI家計簿サービスでのSRE実践を通じて、クレジットカード決済基盤で実践してきた具体的なアプローチを共有します。PCI DSSという厳格な制約から学んだ、セキュリティ要件を設計要素として扱うインフラ設計の考え方を紹介します。

■ 発表の詳細（1000字程度）

クレジットカード決済を扱う当社では、PCI DSS準拠が事業継続の必須要件です。年1回の更新審査では、審査月の1ヶ月は対応にかかりきりになります。監査ログのレビュー、承認フロー管理、監査証跡の収集など、SREが担う作業は多岐にわたります。

本セッションでは、私たちが実践してきた「セキュリティ要件をインフラ基盤で吸収する」アプローチを共有します。マネージドサービスの活用、自動化の徹底、環境分離によるスコープ最小化などにより、SRE自身の運用負荷を最小化しつつ堅牢なインフラ基盤を構築してきた方法をお話しします。

具体的な内容については以下を想定しております。

1. はじめに

• 当社のサービス紹介
  • AI家計簿プリカを提供
  • クレジットカード決済を取り扱うため、PCI DSS準拠が必須
• PCI DSSの具体的な厳しさ
  • 年1回の更新審査（審査月の1ヶ月は対応にかかりきり）
  • 監査証跡の取得、ログレビュー、承認フロー管理
  • 要件文書の解釈とセキュリティ社内規定の作成
• 当社でのSREの役割
  • 監査対応と準拠環境の運用を担当
  • これらをすべて手作業で対応すればSREが疲弊する
• セキュリティ要件をインフラで吸収するアプローチの必要性

2. アプローチ: セキュリティ要件をインフラで吸収する

• SRE自身の運用負荷を最小化する必要性
• パブリッククラウドの活用
  • AWSなどが公開しているホワイトペーパー、コンプライアンス準拠状況を参考に
  • 責任共有モデルの理解
• 基本方針の3つの柱
  • スコープの最小化
  • マネージドサービスの活用
  • 自動化の徹底
• これは一般的なクラウドネイティブなインフラ構築の考え方そのもの
  • 特別なことではなく、基本的なセキュリティ対策の積み重ね

3. 実践例

スコープの最小化

• AWSアカウント分離で準拠環境と非準拠環境を明確に分割
  • セキュリティリスクの分離
  • コンプライアンス対応コストの最小化
• 準拠環境・非準拠環境をまたぐバッチ処理の実装方法

マネージドサービスの活用

• PCI DSS準拠のマネージドサービスを積極的に活用
• コンテナ技術（ECS Fargate）
  • readonlyRootFilesystemを有効化し、マルウェア対策を実現
  • EC2と比較して、セキュリティ設定の管理工数を大幅に削減
• 認証基盤（Cognito）
  • 社内管理画面のログイン認証に活用
  • 多要素認証（MFA）の強化が要求されるPCI DSS v4.0準拠に役立った
• 暗号化管理（KMS）
  • 機密情報を暗号化、キーローテーション

自動化の徹底

• CI/CDパイプラインへのセキュリティチェック組み込み（ECRスキャン、Trivy）
• GuardDutyとLambdaによる異常検知の自動化
• 監査証跡の収集とレビューの省力化（セキュリティエリア入退室ログなど）
• PAN（カード番号）が非準拠環境で見つかった際に備えた自動検知機構
• 定期タスクのGitHub Issue自動作成で手作業を削減

4. 得られた知見

• PCI DSSの厳しさは確かにある
• しかし、SRE自身の運用負荷を減らす工夫を積み重ねることで対応できた
• セキュリティ要件は「制約」ではなく「基盤の設計要素」
• この考え方は一般的なWebアプリケーションでも応用可能

5. まとめ

• セキュリティ要件をインフラで吸収することで、SREの運用負荷を削減しつつ、開発速度を損なわない堅牢な基盤を構築できる

■ 対象聴衆とその人たちが得られるもの

対象聴衆

• クレジットカード決済を扱う企業がどういう制約や運用を求められるか気になるエンジニア
• SREとして運用負荷を抑えつつセキュリティを向上させたいエンジニア
• コンプライアンス対応に不安を感じているSRE

聴衆が得られるもの

• 体系的なコンプライアンス対応のアプローチ（SREの日常活動として実現する方法）
• 実践的なインフラ設計パターン（環境分離、マネージドサービス活用、自動化）
• セキュリティ要件を「制約」ではなく「基盤の設計要素」として扱う設計思想
• SRE運用負荷を削減しつつ、堅牢なインフラを構築する方法論

■ なぜこのトピックについて話したいのか（モチベーション）

私自身、FinTechスタートアップに入社するまでは「厳格なコンプライアンスに準拠したサービスのインフラってどんなものなんだろう。ガチガチで身動きが取れないんじゃないかな」と考えていました。

PCI DSSのような厳格な規制への対応は、たしかに企業に大きな負担をもたらします。しかし、適切なインフラ設計と自動化によってその影響を最小限に抑え、SRE自身の運用負荷を削減しつつセキュリティ向上を実現できることが分かってきました。それは自分が他業界のSREとしてやってきたものと同様の、基本的な取り組みの積み重ねによるものでした。

私たちがやっている日常的な業務は一般的なWebアプリケーション開発でも応用可能なプラクティスだと考えています。「コンプライアンス対応は特別なことではなく、SREの日常的な活動で実現できる」という視点を通じて、コンプライアンス対応やサービスのセキュリティレベル向上に取り組んでいる皆さんの実践を後押しできれば嬉しいです。