億単位の損害を出すインシデントのリスクも軽減できる　貸付ファンドのオンラインマーケット「Funds」のアーキテクチャ

貸付ファンドのオンラインマーケット「Funds」のアーキテクチャ

若松慶信氏（以下、若松）：株式会社クラウドポートの若松と申します。今日は「Fundsのアーキテクチャについて」という題でお話をさせていただきたいと思います。

まず最初に、会社およびサービスについてです。

資産運用をしたい個人とお金を借りたい企業を結ぶ、貸付ファンドのオンラインマーケット「Funds」というサービスを運用しています。第二種金融商品取引業者という、金融庁の管轄下にある会社として、株式会社クラウドポートが運営をしています。

次に、システムアーキテクチャの話をします。

アーキテクチャですが、まずネットワークとしてはこういったかたちになっています。

Public・Privateを含む3層のサブネットと、同じような構成を持つVPCをいくつか運用していまして、これらを共通のVPCを使って結合しています。

システムの全体像としてはこういったものになっています。

スライド真ん中の上側がWebサイトのアプリケーション、右側が社内環境、社内向けのオペレーションシステム。この2つで共通のAPIとworkerを使用しています。マネージドサービスとしてAmazon AuroraやAmazon ElastiCacheなどを使用しています。

続いてDevOpsですね。

DevOpsでは、サービスごとにプロビジョニングしたファイルを事前に用意しておいて、デプロイは、AWS CodePipelineを使ってビルドとデプロイを行っています。運営している最中のログやモニタリングの仕組みも準備しています。

アーキテクチャ採用 7つの理由

若松：ここから、このアーキテクチャを採用している理由についてお話しします。

このアーキテクチャを採用している理由ですが、1つは金融サービスとして必要なセキュリティを実現するためです。金融庁も「金融分野におけるサイバーセキュリティ強化に向けた取組方針」を掲げていまして、非常に重要視しています。これが1点目です。

もう1点なんですけれども、少人数の運用チームでも安全に運用できるようにするためです。弊社はエンジニアが3人なので、その3人の中でもトラブルを予想できるような技術ということで、ある程度枯れているものを中心に使用しています。

ここからWell Architectedな7つのポイントについてお話しします。ちょっとセキュリティなので細かいところもあるんですけれども。

まず1つ目が、3層サブネットとワークロードのSecurity Groupで、NACLで大まかなセキュリティを、Security Groupで細かいルールを設定することで、トラフィックを必要十分に制限しています。

2つ目に「本番」「ステージング」「QA」という3者の環境があるんですけれども、これらをVPCレベルで分類して、共通のGatewayVPCでPeeringにより接続しています。本番環境とその他の環境の間の接続を防止したり、オペレーションするにあたって接続可能なルートを最小限に限定するといったことをやっています。

3番目が、AWS WAFを使っているのとAWS GuardDutyの利用です。WAFは外からの侵入、GuardDutyに関しては、VPC内部のCommand & Controlなどの不正なトラフィックの検出・分析などに使っています。

4番目がIAM Roleでの認可管理というところで、これはサービスごとに必要十分な認可の付与。あと、クレデンシャルの管理を不要にして、漏洩などを防止しています。

5番目がストレージレベルの暗号化。KMSを使ってアプリケーションレベルの暗号化というのも行っていまして、データの保護レベルに応じた複数の暗号化手段を適用しています。

それから6番目なんですけれども、Auto ScalingのScheduled Actionを利用して、定期的にインスタンス数を増減させることで古いインスタンスをdrainするようなものを作っています。これは、アドホックな設定やエクスプロイトの定着防止という役割でこういったことをしています。

最後にログとメトリクスの記録。これはAmazon CloudWatchやAmazon S3のバケットに運用中のログを記録するというようなもので、あとから分析可能にしています。

ビジネスに影響を与えるインシデント対策

若松：こういったポイントがあるんですけれども、アーキテクチャによるビジネスへの貢献というところで最後にお話しします。

金融サービスなので、インシデント発生時のビジネスへの影響度が非常に大きいと考えています。その中で、このアーキテクチャを適用することによって、まずインシデント発生自体のリスク軽減が挙げられるかなと思います。

実際にインシデントが起きてしまうと億単位の損害が出てしまうので、そういったリスクを軽減しています。あと、万が一インシデントが発生した場合の調査ですとか分析も可能にしています。

最後なんですけれども、顧客からのサービスに対する信頼獲得というところで、こちらは、アプリケーションレベルでいうと、2段階認証みたいなものが、けっこうお客様にとって安心して使用できるよという話を聞きます。

それをアーキテクチャレベルでもこういうことをやることによって、信頼を獲得できるのではないかなと思います。

ご清聴ありがとうございました。

（会場拍手）

司会者：はい、ありがとうございました。若松さん、おつかれさまでした。じゃあ審査員のみなさんから、誰かコメントや質問をいただければと思うのですが、いかがでしょうか？

松本勇気氏：今回のアーキテクチャについて、3人しか社員がいないと書いてあって、けっこう人への依存が激しいなと思ったんですけど。スタートアップで仕方ないかなと思っているんですが、どう割り切った監査の仕方をしているのか知りたいです。

若松：人によるオペレーションは最小限に絞るようにしています。例えばデプロイですと、CodeDeployなんですけれども、これもGitHubのPushをもとに、自動的に全部デプロイまでもらえるようにしています。属人性みたいなものは極力排除するというようなかたちでやっています。構成管理などもTerraformを使っています。

司会者：大丈夫でしょうか。すみません、時間が短くて。ありがとうございました。では、もう1回、若松さんに大きな拍手をお願いいたします。

（会場拍手）