FISCに準拠したAWSネットワーク構成の実現：金融機関が押さえるべきポイント

金融業界を取り巻く環境は、低金利による収益悪化の改善や、デジタル化によるビジネス変革の必要性から、大きな変化を遂げています。同時に、大規模なシステム障害の根本原因にセキュリティ対策の問題があったケースも多く、システムの設計・運用段階におけるセキュリティ対策の重要性が高まっています。このような背景から、金融機関は、お客様の大切な資産を預かるという大前提のもと、経営層を含めた関係者（管理者、経営企画担当、ユーザー）が密接に連携し、リスクを低減していくことが求められています。

本ブログでは、金融機関がAWS (Amazon Web Services) 上でFISC（金融情報システムセンター）の「金融機関等コンピュータシステムの安全対策基準・解説書」（以下、FISC安全対策基準）に準拠したネットワーク構成を実現するための主要なポイントと、その際に活用できるAWSの機能やリソースについて、具体的な内容を交えながら解説します。

1. FISC安全対策基準とAWS責任共有モデルの理解

金融情報システムセンター (FISC) が1985年に策定した「金融機関等コンピュータシステムの安全対策基準・解説書」（FISC安全対策基準・解説書）は、システムのアーキテクチャや運用に関する指針として多くの金融機関で活用されており、日本の金融機関における業界標準の一つとして広く認知されています。この基準書では、システムの安全性に関する管理策が統制、実務、設備、監査の4つの観点から示されています。

クラウドサービスを利用する金融機関は、FISC安全対策基準に準拠することが求められますが、その項目は多岐にわたり、クラウド事業者に対する準拠性の確認やクラウドサービス特有の対策検討は金融機関にとって高い負荷となっています。

ここで重要になるのが、AWSの責任共有モデルです。このモデルでは、セキュリティとコンプライアンスの責任がAWSとお客様の間で共有されます。

AWSの責任（クラウドのセキュリティ）：ホストオペレーティングシステム、仮想化レイヤー、サービスが運用される施設の物理的セキュリティなどを運用、管理、制御します。
お客様の責任（クラウド内でのセキュリティ）：ゲストオペレーティングシステム（更新やセキュリティパッチを含む）、関連アプリケーションソフトウェア、AWSが提供するセキュリティグループファイアウォールの設定などに対する責任と管理を負います。

AWSは、この責任共有モデルに基づき、「金融機関向け AWS FISC安全対策基準対応リファレンス」を提供しています。このリファレンスは、FISC安全対策基準が求める各管理策に対するAWSの取り組みとお客様の責任範囲で実施する事項をまとめており、お客様はAWSの対応状況を確認するために利用できます。また、TIS、NTTデータ、SCSKなどを含むAWSパートナー企業10社が共同で作成した「AWS FISC安全対策基準対応リファレンス」参考文書も、金融機関がAWSを安全に利用するための補足情報やノウハウを提供しており、活用イメージが図で示されています。

2. FISCに準拠したAWSネットワーク構成の主要要素

FISC安全対策基準に対応したAWSネットワーク構成を検討する際には、以下の主要な要素を考慮し、AWSのサービスとお客様の責任範囲を明確にしながら設計を進めることが不可欠です。

2.1. 高い可用性と災害対策

金融機関にとって、システムの可用性と災害対策は最重要課題の一つです。AWSは、以下の原則と機能により、強固な可用性を提供します。

「Design for failure」の原則：AWSでは、個々のコンポーネントが機能を停止することをゼロにすることは困難であるという前提に立ち、「Design for failure（障害を前提とした設計）」のメッセージを伝えています。お客様は、適切な設計によって、サービスの構成要素やAWSのアベイラビリティゾーンに障害が発生しても、お客様のサービス自体を問題なく継続させることができる様々な手段や選択肢を有しています。
マルチアベイラビリティゾーン (AZ) 構成：AWSリージョン内の複数のAZを活用することで、単一のデータセンターでは実現できない高い可用性が実現可能です。AZは、一般的な都市地域内で物理的に分離されており、火災、洪水、大規模な停電などの災害イベントから隔離されるよう設計されています。
マルチリージョン戦略：日本では、伝統的に多くの金融機関が物理的に離れた拠点を活用して自然災害リスクマネジメントを行っています。2021年3月に開設されたAWSアジアパシフィック（大阪）リージョンをAWSアジアパシフィック（東京）リージョンと組み合わせて利用することで、直線距離で約400km離れた2つのリージョン間での連携により、単一リージョン内でのマルチAZ構成では充足が難しい災害発生時の業務継続性要件を満たすことが可能です。これにより、コンテンジェンシープランとしてリージョンを切り替えるサービスや、通常のオペレーションとしてマルチリージョンを活用するといった設計をお客様が主体的に行えます。
自動化されたバックアップとリカバリ：
- AWSの各種サービス（Amazon RDS、Amazon DynamoDBなど）は、ポイントインタイムリカバリ (PITR) を可能にする自動バックアップ機能を提供しています。
- AWS Backupは、AWSサービス全体のデータ保護を一元化・自動化する機能を提供します。
- AWS Elastic Disaster Recoveryを使用すると、オンプレミス、クロスAZ、またはクロスリージョンで継続的なデータ保護を維持し、サーバーワークロード全体をコピーできます。
- Amazon S3は、セルフマネージドおよびAWSマネージドデータソースのバックアップ先として利用でき、S3 GlacierやS3 Glacier Deep Archiveなどの低コストなストレージ階層も提供しています。
- AWS Import/Exportサービスにより、ポータブル記憶装置を用いてAWS内外への大容量データの高速転送も可能です。

2.2. 強固なネットワークセキュリティ

FISCに準拠したネットワーク構成には、多層的なセキュリティ対策が求められます。

DDoS攻撃対策：AWS Shield Standardは、ウェブサイトやアプリケーションを標的にした最も一般的で頻繁に発生するネットワークおよびトランスポートレイヤーのDDoS攻撃を防御し、すべてのお客様に対し追加料金なしで自動的に有効化されます。AWS Shield Advancedを有効化することで、より高度で大規模なDDoS攻撃からの保護を強化できます。
Webアプリケーション保護：AWS WAF (Web Application Firewall) は、一般的なウェブエクスプロイトやボットからウェブベースのトラフィックを保護し、許可、ブロック、監視するルールを設定してワークロードを守ります。
VPCと多層防御：Amazon Virtual Private Cloud (VPC) を使用し、セキュリティグループ、ネットワークACL、サブネットといった多層防御アプローチでインバウンドおよびアウトバウンドトラフィックを制御します。
VPCエンドポイントとS3 Public Block Access：重要なファイルへのアクセスをVPCからのみ許可することで、ネットワークレイヤでの対策を追加できます。例えば、Amazon S3に保存する場合、VPCエンドポイントやパブリックブロックアクセスを活用することで実現可能です。
セキュアな通信とプライベート接続：AWSのサービスは、通信にTLS (Transport Layer Security) を使用し、HTTPSエンドポイントを提供することで、伝送中のデータを暗号化できます。また、AWS Direct ConnectやVPNを使用して、お客様のネットワークとAWS VPC間のトラフィックを暗号化し、セキュアな接続を確立することが可能です。
脆弱性管理：AWSは、サービスエンドポイントのIPアドレスに接するすべてのインターネットの脆弱性を定期的にスキャンし、検出された脆弱性は適切な関係者に通知され修正されます。お客様は、自身のインスタンスに対しては、AWS利用規約に違反しない範囲で、事前に承認を得て脆弱性スキャンを実施することができます。
脅威検出：Amazon GuardDutyは、VPCフローログ、CloudTrailイベント、DNSログを継続的に分析し、S3読み取りアクティビティに対するExfiltration:S3/AnomalousBehaviorのような疑わしい活動を自動的に検出することで、AWSアカウントとワークロードを保護します。

2.3. データ保護と暗号化

AWSでは、お客様のデータの所有権と管理権をお客様に付与し、その保護のために様々な機能を提供しています。

保存データと転送データの暗号化：S3、EBS、EC2など、ほぼすべてのAWSサービスで、お客様が独自の暗号化メカニズムを使用できます。Amazon S3は、お客様向けオプションとしてサーバー側暗号化も提供しています。VPCへのIPSecトンネルも暗号化されます。
キー管理：AWS Key Management Service (KMS) を活用して暗号化キーの作成、管理、制御を行うことが可能です。KMSではエンベロープ暗号化を使用し、カスタマー管理キー (CMK) の使用によりセキュリティが強化されます。暗号化を行う秘密鍵の管理者とデータを所有するリソースの管理者を分離することで、より強固なセキュリティ対策が可能です。
強力なテナント隔離：AWSに保存されるお客様のデータはすべて、強力なテナント隔離セキュリティと統制機能によって保護されています。AWSシステムは、仮想化ソフトウェアによるフィルタ処理によって、お客様に割り当てられていない物理ホストや物理インスタンスにアクセスできないように設計されています。

2.4. アクセス管理と監視

適切なアクセス管理と継続的な監視は、FISC準拠のネットワーク構成に不可欠です。

AWS Identity and Access Management (IAM)：IAMは、AWSリソースへのアクセスを安全に制御するサービスです。ユーザー、グループ、ロールを作成し、必要最小限のアクセス許可（最小権限の原則）を付与することで、セキュリティを強化します。
多要素認証 (MFA)：MFAを要求することで、サインイン認証情報が不注意に開示されたり推測されたりするリスクを軽減できます。
ログとモニタリング：
- AWS CloudTrail：AWS APIへの呼び出し（誰が、いつ、どのAPIを呼び出したか）を記録し、ログファイルの整合性を検証できます。
- Amazon S3アクセスログ：各S3バケットに対して行われたリクエストを監視できます。
- Amazon CloudWatch：AWSクラウドのリソースやお客様が実行するアプリケーションのメトリクス収集、ログファイルの監視、アラーム設定を提供します。これにより、システム全体の可視性を得られます。
- Amazon GuardDuty：CloudTrailログ、VPCフローログ、DNSログを継続的に分析し、悪意のある動作や不正な動作を自動的に検出します。
- Amazon S3 Access Analyzer：S3バケット内で誰がどのデータにアクセス可能かを評価するのに役立ちます。
- 監査処理の失敗時には、自動化されたアラートが担当者に通知されます。

3. 継続的なコンプライアンス維持のための運用

FISCに準拠したネットワーク構成は、一度構築すれば終わりではありません。継続的な運用と改善が不可欠です。

変更管理：AWSは、システム的なアプローチで変更管理を行っており、お客様に影響を与えるサービスの変更は、徹底的に検証、テスト、承認され、段階的にデプロイされます。お客様も同様に、変更管理プロセスを確立し、実行する必要があります。
リスクベースアプローチの適用：金融機関は、システム特性（重要性、機密性、可用性など）を分析し、リスクベースアプローチ（RBA）に基づいて適切な安全対策を決定することが求められます。これにより、経営資源を適切に配分し、実効的な対策を実施できます。
監査と第三者認証の活用：AWSは、FISC安全対策基準、PCI DSS、HIPAA/HITECH、FedRAMP、ISO 9001、ISO 27001, ISO 27018など、143以上のセキュリティ標準とコンプライアンス認証をサポートしており、第三者の独立監査人によって定期的に検証されています。SOC 1 Type IIレポートやISO/IEC 27001などの認証情報は、お客様の監査チームやコンプライアンスチームがAWSの統制を把握し、監査を行う上で役立ちます。AWS Artifactを通じて、これらのレポートにオンデマンドでアクセス可能です。
FISC対応APNコンソーシアムの参考文書：NTTデータ、SCSK、TISなどのパートナー企業が共同で作成した「AWS FISC安全対策基準対応リファレンス」参考文書は、AWSの対応状況や金融機関が必要な対策の具体例を明示しており、金融機関の負荷軽減に貢献します。特に、AWS Well-Architected フレームワーク FSI Lens for FISCは、金融サービス業界のワークロードの設計に焦点を当てたベストプラクティス集であり、FISC安全対策基準の実務基準の準拠状況を定量的に可視化するのに役立ちます。

まとめ

FISCに準拠したAWSネットワーク構成の実現は、金融機関にとって複雑な課題ですが、AWSが提供する堅牢なサービス群と「責任共有モデル」の明確な理解によって、より安全かつ効率的に構築・運用することが可能です。AWSのグローバルなインフラストラクチャ、包括的なセキュリティ機能、そして継続的なコンプライアンスへの取り組みは、金融機関がイノベーションを推進しつつ、お客様の大切な資産を守るための強力な基盤となります。

このブログが、FISCに準拠したAWSネットワーク構成を検討する上での一助となれば幸いです。

参考資料