FISC「金融機関等におけるクラウド導入・運用に関する解説書（試行版）」発行によせて

公益財団法人 金融情報システムセンター（FISC）様では、金融機関の様々なお客様のクラウドの安全な利活用を促進するために、「金融機関等におけるクラウド導入・運用に関する解説書（試行版）」（以下、解説書）を公表いたしました。
多くのお客様が、クラウドを活用したイノベーションの促進を進めようとされる中で、様々なセキュリティに対してどのように対応していくか、そのためのリスク管理の基礎となるリスクベースアプローチへの取り組みに対し、FISCでは安全対策基準の第9版への改訂など、活発に活動されています。AWSでは、こうした活動を歓迎します。

本Blogでは、本解説書に基づき、AWSの利活用を進めるうえでのポイントや考え方をお伝えしていきます。特に今回は、金融サービスにおいて特に論点となる自然災害をふまえたサービスの可用性への適切な設計への考慮事項を例として紹介します。

クラウドサービスにおける責任共有モデルの多様化

本解説書にも示されている通り、サービスを提供する上での責任分界点の理解は安全な利活用の基礎となるものです。特にクラウド事業者においても、AWSのようにインフラストラクチャをサービスとして提供しているクラウド事業者も存在すれば、AWS上にクラウドサービスを立ちあげ、SaaSといった形でサービスを提供する事業者、もしくはシステムインテグレータのようにクラウドサービスという形態ではなくとも、お客様と一定の契約のもとに、サービスを構築、運用する事業者が存在します。このような事業者は、クラウドサービス事業者であり、かつ、クラウドサービスの利用者という二つの側面を持ちます。

さらにはAWSにも様々なサービスが存在し、お客様の設計により運用の負担や分担される責任が異なります。サービスとして実現したい価値にあわせて、最適な設計を行い、またそれを継続的に改善していくことが強く求められるようになっていると言えます。

責任共有モデルに基づく”管理主体の明確化”

本解説書においても、FISC安全対策基準に基づき、システムの洗い出しからコンテンジェンシープランの策定までのプロセスを紹介しています。その中でも”管理主体”を明らかにすることは、組織の説明責任、実行責任を果たすうえでの基礎となります。多くのコンプライアンスプログラムにおいて、サービスの提供における責任とサービスの利用に関わる責任は異なる管理主体が実行するものとして定義されます。AWSはお客様に様々な機能を提供しますが、機能を適切に活用することはお客様の設計及び運用となります。

こうした中で、本解説書の実務基準に基づく３．対策一覧の「クラウドサービス固有で対応すべき事項や特に留意すべき事項」の内容によっては、利用者（もしくはその利用者が起用しているサービス設計を担当する事業者やAWS上でサービス提供を行うクラウドサービス事業者）の設計および運用に依拠するケースが存在します。

解説書を読み解くためのヒント -管理主体と対象の明確化-

本解説書における管理策の一例として、暗証番号やパスワードを知られないための対策の実施（実務１ 基礎）が求められています。AWSにおいては、データのオーナーシップはお客様に帰属します。アクセス権や認証認可の管理はお客様により設計され、実装されます。

例えば、サービスに関連する認証情報等の秘密情報はお客様の利用される環境により多岐にわたります。マネジメントコンソールなどのAWSの機能を利用している場合もあれば、他のサービスを活用したシングルサインオンを行っている場合もあります。また、AWS上に構築したアプリケーションの認証情報に対する保護も存在します。

また、本解説書では、異常事態の早期発見のための監視対象や方法を定めること（実務46 基礎）などにも触れられています。AWSのService Health Dashboardは、AWSの状態をいち早く認識するために有効な手段です。なお、このダッシュボードは公開されており、AWSアカウントの有無にかかわらず、どなたでもAWSのサービスの稼働状況をほぼリアルタイムで確認ができます。

このように、自社のサービスの構成要素やその管理対象と責任の所在を識別する、つまり、解説書における”管理主体”を丁寧にひもとくことによって、本解説書をより効果的に読み込むことにつながります。

大阪リージョンとサービスの可用性

特に金融のお客様とのディスカッションにおいて、重要な論点の一つとなるのは災害を踏まえたサービスコンテンジェンシーの実現です。日本では伝統的に多くの金融機関のお客様が物理的に離れた拠点を活用することで地震などの自然災害に対するリスクマネジメントを実施しています。

2021年3月に開設されたAWSアジアパシフィック（大阪）リージョンにより、日本のお客様は直線距離で約 400km 離れた場所に位置する AWS アジアパシフィック (東京リージョン) と組みわせて利⽤することで、単⼀の AWS リージョン内にあるマルチ AZ 構成で充⾜が難しい災害や障害発⽣時の業務継続性要件が求められるワークロードやアプリケーションを⽇本国内にある 2 つのリージョンの連携により実現することが可能です。

AWSでは、リージョン内のアベイラビリティゾーンを活用することで、100km の範囲内で物理的に離れた場所にある複数のアベイラビリティーゾーン (AZ) をご活用いただけますが、それに加え、国内にある複数のアベイラビリティーゾーンを⽤いてシステムを構成することにより、単⼀のデータセンターでは実現できない⾼い可⽤性の実現が可能です。

つまり、金融機関における高い可用性やレジリエンシーを求められるサービスに対しては、コンテンジェンシープランによらず通常のオペレーションとしてマルチリージョンをご活用いただくことも、コンテンジェンシープランとしてリージョンを切り替えるサービスとすることも、お客様が主体的に設計し、運用することができます。

Design for failure

AWSの各種サービスに連携し、自動化されたバックアップサイトへの切り替えなどを実現することも可能です。AWSでは、サービス設計の原則として「Design for failure」というメッセージを伝えています。自然災害や故障などにより個々のコンポーネントが機能を停止することをゼロにすることは困難です。ただし、お客様は適切な設計によって、サービスの構成要素やAWSのアベイラビリティゾーンに障害が発生しても、お客様のサービス自体を問題なく継続させることができる様々な手段や選択肢を有しています。

サービスに求められるニーズに基づき適切な設計を実装すること、常にそれを検証することによって、サービス自体の品質に対する責任を果たすことができると言えます。

リスクベースアプローチは”実効性のある”選択肢を見出すための手段

安全対策基準や本解説書で求められるリスクベースアプローチは、形式的な判断ではなく、実質的にサービスの安全性や可用性を向上させる手段を選択するための取り組みとなります。

リスクアセスメントの基本的な考え方では、すべてのリスクをゼロにすることは現実的ではなく、また場合によっては大幅なコスト負担を強いるものとなります。適切な残存リスクへの認識と適切なコンテンジェンシープランの策定や、その継続的なテストがサービスの質的な向上をもたらします。

AWSでは、先述のDesign for failure等のサービス設計や運用のベストプラクティスを踏まえたWell Architectedフレームワークの提供や、日本における災害対策を踏まえた「Resiliency in Japan-日本におけるAWSリージョンのレジリエンス-」ホワイトペーパーの提供等ににより、お客様のコンテンジェンシープランの策定を支援しています。

お客様はAWSの金融サービスコンピテンシーパートナー様の知見やリソースを活用したり、AWS Marketplaceから様々なワークロードに見合うソリューションを迅速に活用することもできます。

まとめにかえて

本解説書に基づき、お客様がクラウドサービスを活用し、安全かつ安定的にエンドユーザーの皆様に金融サービスを提供できるようになることは非常によろこばしいことです。お客様、FISC様をはじめとした当局の皆様、そして何よりも安心してクラウド上の金融サービスをいただくエンドユーザー様への信頼向上に貢献していきたいと考えています。

このブログの著者
松本　照吾（Matsumoto, Shogo）
セキュリティ アシュアランス本部 本部長