金融機関がAWSでクラウド化　セキュリティ対策とコスト管理を両立させるには

FXトレード・フィナンシャルは、マルチサイト環境からAWSに完全移行した。金融機関に求められる堅牢なセキュリティと、コスト管理の両立を実現した方法、今後の課題について紹介する。

公開 2018年06月26日 05時02分

著者

上田奈々絵

[TechTargetジャパン]

印刷する

FXトレード・フィナンシャルの山田氏

　外国為替保証金取引（FX）のオンラインサービスを提供するFXトレード・フィナンシャル（以下、FXTF）は、複数の拠点（サイト）でシステムを運用するマルチサイト環境からAWSへ、主要システムのインフラを完全移行した。同社情報システム担当執行役員の山田将司氏が2018年5月31日、Amazon Web Services（AWS）に関するカンファレンス「AWS Summit Tokyo 2018」に登壇し、移行の理由や効果、課題を明らかにした。同氏による「FXTFにおけるAWS活用事例～金融サービス事業者における『オールインクラウド』実現までの道筋～」という事例セッションの内容を紹介する。

　移行前、FXTFは、AWSと他社クラウドの2つのクラウド、ASPサービス、本社のオンプレミス環境からなるマルチサイト環境で主要システムを稼働させていた。サイトごとに管理方法や機能、手続きが全く異なるため、情報システム担当の学習コストと管理コストが大きくなることや、サイト間を相互接続する際のセキュリティ対策に課題を抱えていた。

　AWSの選定理由は主に3点だ。1点目は金融機関のシステム管理体制を金融庁が検査する際に用いる、金融情報システムセンター（FISC）安全対策基準に準拠可能であること。2点目は他のクラウドサービスと比べてAWSのサービスが充実していたことだ。山田氏は「AWSにはユーザー企業の声を反映させた機能が充実しており、柔軟なシステム設計が可能だ」と話した。3点目にはAWSのサポート体制を挙げた。システムの管理に割ける人員が限られるため、AWS側の担当者によるサポート体制を重視したという。

併せて読みたいお薦めの記事

AWS Summit Tokyo 2018レポート

AWS Summit Tokyo 2017レポート

AWSへの完全移行

　AWSへの完全移行のために、各サイトで稼働するシステムごとに仮想ネットワーク「Amazon Virtual Private Cloud」（VPC）環境を準備した。

　FXTFは、移行前から一部のシステムで仮想マシンサービス「Amazon EC2」の「EC2-Classic」環境（VPCを用いない従来型のEC2環境）を利用していた。AWSのEC2-Classic環境からVPC環境へ移行する際は、EC2環境に関連付けて利用するIPアドレス「Elastic IP」の移行機能を使って、システムをVPCで再構築せずにそのまま移行した。システムごとにVPCを利用し、システム間連携の際は、2つのVPCを同じネットワークに存在しているかのように相互に接続するピアリング接続機能を利用した。

　顧客関係管理（CRM）システムを運用していたオンプレミス環境からVPCへの移行には、双方を専用線で接続するサービス「AWS Direct Connect」を利用。インターネット接続では、データの大きいCRMシステムなどの移行には帯域幅を多く必要としていることと、セキュリティへの懸念があったためだ。

セキュリティ対策の強化

　クラウドセキュリティのうち、FXTFが最も重要だと考えたのが、アカウント管理だ。管理には、エンドユーザーごとに個別のアカウントを付与してAWSサービスへのアクセス制御ができる「AWS Identity and Access Management」（IAM）を利用し、インフラ担当とシステム開発担当のアカウントを分離した。モバイル端末からのアクセスについてはワンタイムパスワードを用いた多要素認証を導入した。

　AWSの機能を用いて、各アカウントのログも記録した。VPCへのアクセスログを取得する「VPCフローログ」を利用し、ユーザーアクティビティーを記録する「AWS CloudTrail」によって、AWSアカウント内で誰がどのような操作をしたか確認できるようにした。VPCやセキュリティグループ（後述）をはじめとしたAWSリソースの設定の変更履歴を記録できる「AWS Config」を使い、API（アプリケーションプログラミングインタフェース）のログも管理している。

　以前は、サーバごとに利用するネットワークセキュリティシステムが異なる状況だったが、移行に伴いVPCごとに仮想ファイアウォール機能の「セキュリティグループ」を適用し、ポートベースでトラフィックを制御する形に統一した。主要システムをAWSに一元化することで、サーバごとのルールとアクセス権限が明確になり、全ての通信を理解して把握できるようになったという。

サードパーティー製品を活用したコスト管理

　セキュリティとデータ保全の一部には、費用対効果の観点からサードパーティー製品を利用した。VPCのセキュリティグループに加え、サードパーティー製のファイアウォールを導入することで、多層ファイアウォール化した。

　全社統合監視ツールとして、AWS以外のサイトとAWSのAPIの死活監視やリソース監視、ログ監視を同時にできるサードパーティー製のツールも導入した。

　コスト管理ツールには「AWS Cost Explorer」を利用し、システムごとにどのくらいのコストがかかるのかを容易に明確化できるようにした。従来は「Microsoft Excel」を使って手作業でコスト管理をしており、コストの把握に時間や手間がかかっていたという。取引システムの1つには、データセンター内のサーバ利用量を予約することで、利用料に割引が適用される「リザーブドインスタンス」という料金プランを利用した。結果、取引システムに利用している仮想サーバのランニングコストを15％削減できたという。設定されたコードを自動で実行する「AWS Lambda」を利用し、不要な仮想サーバを週末に止めて週明けに稼働させ、ランニングコストを削減する施策もした。

導入後の課題と展望

　山田氏は導入後に分かったAWSの評価点として、柔軟なシステム設計のための設備がそろっている点、日本のユーザーが多く、日本語のマニュアルやサポート体制が充実している点、Cost Explorerを使ってコストの可視化が容易にできる点を挙げた。

　AWSの注意点として山田氏は「サービスに影響を及ぼすほどの高い頻度でメンテナンスがある」ため、メンテナンスの開始・終了時間について常に注意しておく必要があることと、日本でまだ利用できないサービスがあることを挙げる。情報システム担当者の学習コストが大きい点にも課題が残る。機能管理コンソールの更新が頻繁にあり、機能が多岐にわたるため、更新のたびに利用方法や基礎知識を習得する必要があるためだ。同氏はこの課題に対し「機能をしっかり把握すれば、企業にあったシステム設計が可能になるのではないか」と語った。

　山田氏は今後のAWS活用の展望として、取引システムやCRMシステムの可用性を高めるために、アプリケーションを監視し、自動でリソースの使用量を調整する「AWS Auto Scaling」の導入を見込んでいる。リレーショナルデータベースである「Amazon Aurora」のパフォーマンスにも期待しているという。「あらゆるデータをAWSに集約してリアルタイム分析をしたい。仕組みを変えるために社内フローの整備も必要だ」（山田氏）

　自社の人的リソースが限られた状態でも、高度なセキュリティを維持しながら安定したシステムの運用を実現したい――。こうしたニーズを満たす手段として、セキュリティや運用のしやすさに配慮したクラウドで社内システムを一元管理することは、有力な選択肢となるはずだ。

印刷する