会社紹介とアマゾンウェブサービス(AWS)活用の概要

昨今主流となってきたマイクロサービスにおいて、もはや必須となっているコンテナについて、リスク等々、当社で実際に体験して実践してきた内容をご紹介いたします。

GMOペイメントゲートウェイとは

GMOペイメントゲートウェイは、キャッシュレス・FinTechといわれる決済のエリア、特に決済代行といわれる領域で業界シェアナンバーワンで、年間およそ7.4兆円^※の決済を取り扱っております。
上記チャートの右側にここ十数年の当社の営業利益の推移をグラフで示しておりますが、昨今15期連続^※で増収増益を継続しております。
その高い成長を支えているのは、内製にこだわったエンジニア集団であります。当社には現在約200名程度のエンジニアが在籍しており、オンプレミスとクラウドの両方を利用したハイブリッドな環境でサービスを提供しております。

※ 2021年6月末時点。

AWS活用の概要

次にワークロード特性をご紹介いたします。
メインのプロダクトである「PGマルチペイメントサービス」だけで、年間約33億件^※の決済トランザクションを取り扱っております。決済ですのでクレジットカード情報や個人情報など、その情報でお買い物ができてしまうというような、非常にセンシティブな情報を大量に取り扱っています。
したがって、当社はPCI DSSやPCI 3DSといった認証への対応が必須になりますし、常にハッカーの標的にさらされているという状況にあります。
あってはならないことですが、万が一侵入された場合も想定し、被害を最小限に抑えるべく業界最高レベルのセキュリティ要件が求められております。

※ 2021年6月末時点。

AWS活用への心配ごと

そのような特性を持った当社ですが、AWSの活用に当たっては当初四つぐらい心配事がありました。

一つは「提供スピード」です。クラウドを使うと本当に早くなるのかという疑問などがありました。
二つ目は「費用面」です。クラウドを使ったら、初めは安そうだけれどもだんだんと高くなってきてしまうのではないか、本当にコストパフォーマンスが測れるのだろうかといった心配です。
三つ目に「セキュリティ面」です。本当にクラウドは大丈夫だろうか、PCI DSSなどの認証をとらなければならないが、本当にクラウドで取得できるのか、というような心配。
四つ目は「スキル面」です。当社にはそのようなクラウドに関連するようなスキルを持っているメンバーがいなかったので、外部に頼るしかないのかなといった心配がありました。
そのようななか、大体4、5年くらいかけてクラウドにトライしてきて感じたことです。

1.提供スピード

まず「提供スピード」については、やはり外部委託したままクラウド化してもなかなかスピードは上がらないという結論に至りました。トライするなかで、小さくてもいいので、内製開発＋クラウドというのにチャレンジすることで早くなるというのを痛感しました。
「こんど払い byGMO」という当社のBNPL（後払いサービス）の新しいプロダクトがありますが、こちらは実際に約3カ月で開発出来たという実績があります。

2.費用面

2番目の「費用面」についてですが、試算した結果、単純にクラウドにしただけで安くなるというようなうまい話ではありませんでした。
課金体系やサービスのピーク制などを考慮した最適なデザインにし、AWSさんがいろいろ用意されているセービングプランといったものも活用することで、初めてコストが安くできるということが分かりました。結果として当社はクラウド利用に最適なアーキテクチャで作ることで、先ほどのケースであれば30％ぐらいオンプレよりも費用低減できたという実績がございます。

3.セキュリティ面

「セキュリティ面」についてですが、システムはアップツーデートな最新の状態に保つというのが非常に難しいです。PCI DSSもそういうのを求めてくるので、自分たちでやるということに苦しみを感じておりましたが、PCI DSSに準拠してくれているマネージドサービスというのもAWSさんは提供されております。そういうものをチョイスすることで無事に認証までたどり着くことができました。したがってこのことは、逆に運用面を考えると非常に楽になったという面があります。

4.スキル面

四つ目の「スキル面」。これが一番大事かとは思いますが、なかなかクラウドをやったことがあるというメンバーがいませんでした。けれども「やってみたい」というメンバーは、実は沢山いました。
それだけ先進な取り組みというものをメンバーのみんなが感じてくれており、希望者には研修コースで学んでもらい、もちろんやる気があるので非常に即戦力として活用してくれました。これは非常に助かりましたし、本人にとってもやりたいことができてモチベーションアップに繋がり大活躍していただくことができました。やはりエンジニアなので、「やってみたい」という気持ちや実際にやっているときのワクワク感といったものを大事にすることが、成功の秘訣だったのかなという風に思っております。

AWS活用の取り組み状況と将来像

AWSの活用を四つのステップで進めてまいりました。
初めはWorkSpacesや、SageMakerなど、そのまま使えるサービスを活用することから始め、開発やPoC、テスト環境などの本番ではないワークロードでテスト的に利用して効果を確認しながら、その後の本番環境適用においては、先程のPCI DSS認証が必須になりますので、それらの段階を経て現在ようやくステップ4。本格的に活用する段階にきているという状況です。
決済というのは当たり前に存在するものなので、そこにおいてのフラストレーションやストレスといったものを感じさせないサービスを当社は目指しております。したがってこれからもAWSを活用して、新しいサービスをタイムリーに提供していきたいと考えております。

数字で見るマイクロサービス

前置きが長くなりましたが、これからマイクロサービスを数字で見ていきます。

企業の大多数が、マイクロサービスの価値を認めている

この数字はIBMの調査レポート^※を引用したものですが、「77％」。
何かというと「マイクロサービスがメリットをもたらす」と認めている企業のパーセンテージになります。
それから「68％」。これは「マイクロサービスの導入は労力と費用を投入するに値する」と答えた企業のパーセンテージです。
「66％」。これは「人材確保のためにもマイクロサービスが必要」と答えた企業の割合で、このように非常に多くの企業がその価値を認めているような状況にあると思います。

※出典：IBM調査レポート「Microservices in the enterprise, 2021」

コスト削減よりも、対顧客メリットやアプリケーション品質に価値

同じレポートですが、ビジネス面のメリットと開発上のメリットの上位3位をまとめたものです^※。
見ていただくと分かりますが、マイクロサービス化はやはりコスト削減よりも、対顧客・対市場に対してのメリットやアプリケーションの品質といった面でのメリットがあるというふうに皆様が評価されているというのが分かります。

※出典：IBM調査レポート「Microservices in the enterprise, 2021」

多くの企業が今後2年以内に投資を増やしマイクロサービス化を進める

さらにレポート^※では、今後2年というスパンで見た場合、なんとこれまでマイクロサービスを使っていないユーザーの56％が「新たに採用する」と言っており、ユーザーのうち78％が「マイクロサービスへ投資を増やす」と回答をしております。
それから今後2年間で作成されるアプリケーションのうち59％が「マイクロサービスを使用するのではいか」と答えています。もはやマイクロサービスが切っても切れないものになっているのではないかと思います。

※出典：IBM調査レポート「Microservices in the enterprise, 2021」

難易度と人材不足が主な障壁、セキュリティリスクも懸念事項

ここまで非常に期待と前向きなコメントを紹介してきましたが、ここからは障壁やリスクといったものを見ていきます。
同じレポート^※で「採用しない理由」というのを見ると、「革新的なペースについていけない」や「非常にモノリシックからのトランジションが難しい」、「実装が圧倒的に難しい」といったような意見があります。さらに導入拡大への課題という意味では人材の面、学習コストの面、それからセキュリティといったあたりも非常に上位にあがっているということがお分かりいただけると思います。

※出典：IBM調査レポート「Microservices in the enterprise, 2021」

モダンWebアプリ開発のベストプラクティス (12 Factor App)

少し話は変わりまして、2012年と古いものではありますが、現在でも結構引用されることの多い、モダンWebアプリ開発のベストプラクティスとよばれている「Twelve-Factors」^※というものがあります。
まずアプリのデザイン手法としてのマイクロサービス。これを使うことで、「Twelve-Factors」うちの3項目（「コードベース」「バックエンドサービス」「プロセス」）はカバーされます。さらに実装としてのコンテナ。これを適用するとなんとこのうちの九つ（「依存関係」「設定、ビルド、リリース実行」「ボートバインディング」「並行性」「廃棄容易性」「開発/本番一致」「ログ」「管理プロセス」）網羅されることになります。これで12個全部網羅されるわけですが、こうやって見るとコンテナは本当に最強ですね。それではコンテナは良いことばかりかというと、セキュリティ面の課題としてこのようなものもあげられております。

※出典：「heroku 2012」

コンテナにはセキュリティ面での新たな課題もある

また別の調査です。CNCFのサーベイ結果ですが、32％が「コンテナ導入の最大の課題はセキュリティ」だと回答をしています^※1。
それから68％。これはノルウェーの大学の調査結果ですが、「Docker Hub上で脆弱性のあるイメージの割合」^※2ということで、Docker Hub上でもオフィシャルですら46％が脆弱性を含んでいると。もう何を信じたらいいのか分からない世界です。

※1 出典：「CNCF Survay 2020」
※2 出典：「NTNU Vulunerability Analysis of 2500 Docker Hub Images」

コンテナセキュリティ対策

ここまで数字でいろいろと見てきましたが、ここからは当社が実践した対策について、解説したいと思います。

コンテナセキュリティの指針（NIST SP800-190)

まずこの資料はNISTが2017年の9月に発表した「アプリケーションコンテナセキュリティガイド」でございます。IPAも日本語に翻訳して出してくれていますので、非常に参照しやすいと思います。

４つのコンテナセキュリティ対策 (NIST SP800-190へのマッピング)

それをここでは表形式にしてまとめてみました。
五つのカテゴリーで23個のリスクが定義されています。この中で当社は四つのセキュリティ対策を実際にとってきており、それをマップで表現しました。
まず一つ目、「マネージドサービスを利用」しようという施策において、このうちの三つのカテゴリーが埋まる形です。
それから二つ目。こちらは「コンテナのイメージスキャン」というような対策をすることで、イメージのリスクに対する対策がとれました。
三つ目は「コンテナのランタイム対策」で、コンテナ自体の対策をとりました。四つ目は横串になりますが、これらを「モニタリングして運営」する。このような形になります。
四つで網羅されたということがここでは示したいことなのですが、この四つの順を追って対策を具体的に説明していきます。

対策1:マネージドサービス利用

一つ目は「マネージドサービス利用」。
例えばKubernetes。これは3カ月ごとに更新が出て、サポート期間は9カ月から12カ月と非常に早いペースでアップグレードされているものになります。したがってこれに追随するというのは、エンタープライズの企業にとっては非常に難しい課題というのが一つ。
もう一つはここに列挙しましたが、例えばKubernetesを使う場合、それだけではオールインワンにはならないのです。
例えばネットワークのプラグインは何を使うかや、サービスプロキシはどうしようか、サービスメッシュは何にしようか、永続ストレージは、ログ収集は、モニタリングは？と、いろんなものを組み合わせなくてはいけない。これらがまたある程度の頻度で更新されてサポートが切れていくという、非常に難しい状況にあります。したがってこれらの組み合わせでの稼働確認をしなくてはいけませんし、更新時には様々な関係性の挙動について自分たちで確認しないといけないという難しさがございました。

したがってそれらを含めると、企業で一つのKubernetesの環境を作れば済むということでは全くないわけです。やはりバージョンアップなどで影響が大きすぎますし、長時間そんなに止められるサービスばかりではないですよね。複数のオーケストレーター環境を複数バージョンで管理運用するということをやらざるをえない。これらが障壁の一つと当社は感じました。そこでこのエリアで、当社は積極的にマネージドサービスを活用するという戦略に出ました。レジストリであればアマゾンのECR。オーケストレーションはECS。ホストOS自体も管理したくなかったのでFargateを活用。これらによっていろいろな更新ペースの追随や組み合わせ問題というものの解決を図りました。

対策2:コンテナイメージスキャン

対策の二つ目ですが、今度はコンテナのイメージスキャンです。
こちらは当社の実際の今の運用を図にしているものになりますが、コンテナのイメージを作ってプッシュしたときにスキャンするような仕組み。それから定期的にスキャンしたりオンデマンドでリクエストベースでスキャンしたり、といったものを取り入れたというような紹介です。
先ほどのレポートでも「Docker Hub上も68％が脆弱性を含んでいる」というのがありましたね。そんな衝撃的な調査結果もありますので、当社も自分の身は自分で守らないといけないということになります。

まず脆弱性の診断という意味では、具体的にいうとOSや、ミドルウェアのパッチ情報なども含んでいるCVEというデータベースを元にチェックする必要があるわけですが、これはAWSが提供してくれているClairというものを利用しました。ただしそこでは網羅されないウイルスやマルウェアといったものの検出がありますので、当社はオープンソースのLambdaというものを利用しまして、これらの組み合わせで実現しました。

さらにテスト環境、開発環境、ステージングというあたりは頻繁にアップデートされますし、そこで何か脆弱性やウイルスが混入される危険性はもちろんあるわけです。したがってここで最終的に本番に適用しようというバージョンの物のみきちんと承認のフローを回すこともそうですし、スキャン結果OKをチェックするのもそうですし、そういうことで本番のレジストリは分けてここにコピーするというひと手間は入っていますが、これによってさらにもう一段防御するような構成を当社はとっております。

対策3:コンテナランタイム対策

対策の三つ目ですが、コンテナのランタイム対策になります。これには二つあります。
一つ目はリードオンリーコンテナの利用です。先程の対策2でコンテナの静的イメージについては脆弱性も無いしウイルスもマルウェアも無いという状況は作れましたが、実行環境で実行されている状態でウイルスやマルウェア、バックドアが配置されてしまうという可能性はあります。
したがってこれへの対策として動的スキャンが必要になるわけです。しかし、当社は動的スキャン、Falco等々いろいろと商用ツールがあるなか、これを使うよりももう少し手軽なリードオンリーコンテナという方式をとりました。これによってコンテナ自体への書き込みを禁止することでリスクを回避するという、大変シンプルな方法です。ランタイム上はこれでスキャンする必要はなくなることになります。ただしアプリケーションによってはリードオンリーコンテナでは稼働しない場合もありますので、アプリケーションを内製で開発して、工夫・修正することで対応できましたが、そういった場合にはFalcoを使うとか他の商用のソフトウェアなどでコンテナのウィルススキャンをするとか、そのような検討が要るかと思います。
よく「コンテナってウイルス対策いるの？」と聞かれることがあります。マルウェアやバックドア、そういったリスクを考えると実はコンテナでも変わらないのです。勘違いされがちですが、ここは要注意なところだと思います。

対策3のもう一つは、万が一にもあってはならないことですが、侵入されてしまった場合。その場合にも外部への持ち出しを抑止するというあたりが必要になります。内部からインターネット越しで外部へアクセスする際、比較的無防備にany portで開けているという企業も無くもないのですが、そういうことでは何かの脆弱性を突かれて入られたとき、世界中にあるいろいろなすでに乗っ取られているサイト等々を悪用され、データが持ち出しされてしまうというリスクがあります。
したがって当社はアクセス制限を実装したかったのですが、IPアドレスやポート番号であればマネージドサービスの世界でポリシーを定義することでできるのですが、昨今いろいろなサービスもクラウドを使っていたりで、動的にIPもどんどん変わっていってしまったりします。やはり名前でフィルタリングしたいというのが当社のニーズでした。
そこで、FQDNベースでのフィルタリング。これは今のところ、いろいろマネージドサービスでは見つからなかったため、自分たちでプロキシのコンテナを立て、そこでフィルタリングを定義するというような出口対策をとっております。
any向けのインターネットで口を開けるというのは、企業の規模にもよりますが比較的やりがちなことですので、実際にこれを開いていると相当まずいことになるというのは認識いただきたいと思います。

対策4:モニタリング&運営

四つ目最後の一つ。これが非常に大事になってきますが、モニタリングについて全体像を示したいと思います。
当社ははじめに申しあげたように、クラウド環境とオンプレ環境の両方をハイブリッドで活用しておりまして、上段がクラウド環境、下段がオンプレ環境です。まずクラウド環境においては、クラウドならではの設定不備というのは何かとありがちです。
例えばS3の設定上、外部に思いがけず公開してしまっていたとか。このあたりはAWSのセキュリティハブが非常に良く出来ており、PCI DSSのテンプレートもあり、そういうものを適用してチェックするような仕組みで活用しています。
また、実際に変更操作が行われた各所の監視。そのような不正侵入の検知等々については、もともとのCloudTrailやConfig、CloudWatch等からのアラートを受けてEventBridgeで検知し、それをアラート通知。そのような仕組みで実装しております。
オンプレも似たような仕組みです。不正操作であるとか、オンプレ自体の監視は当社はZabbixでやっています。ログの収集についてはFileBeat、Logstashなどで集めています。最終的にはその二つを合流させて、オンラインのモニタリングではチャットやメールにアラート通知する仕組みがあり、アラートの電話呼び出しを夜間や土日に行っています。
ただ、アラート通知しただけでは担当者の誰か拾ってくれたのかが分からなくなってしまうため、当番（オペレーションの当番等、日によって違う）を決めながらも、Opsgenieでハンドルし、その日のその時間の担当者にまずコールして、出なければ次にコールして、出た人はそれをピックして「自分が案件やり始めましたよ」と、このツールの中で宣言する。そのような仕組みにしています。
実は当社も昨年まではオペレーターの手運用でやっていたのですが、ようやくツールを入れました。

それからStatuspageというようなクラウドサービスも使っています。こちらはリアルタイムに障害情報をダッシュボードで見られるようにするページを、外部のお客様向けに展開して、当社の検知とともにお客様も同時に検知できるような仕組みを構築しています。それからログの収集は最終的にオンプレ、クラウドにかかわらずS3に全部集めて、それを機械学習のSageMakerを使って検出したり、SIEMの基盤としてElasticsearch、Kibanaを使って、相関分析してリアルタイムで検知したりしています。

最後、対策4の運営の側です。
テクノロジーでこのように仕組みはいろいろと作りますが、やはり継続して運用するためには体制が重要だなというのが最終的な結論だと思います。

一つ目は、我々のチームはもともと「サービス運用グループ」という組織の中でSREのチームにいました。このチームはツールをいろいろ使い、サービスの改善をしていたチームで、クラウドやSaaS、様々なものに詳しいエンジニアにどんどんなっていたんですね。結果、ここがCCOE、Cloud Center of Excellence、クラウドについても一番詳しいチームになったので兼務してもらい、司令塔になってスキルセットになって推進する。そんなような仕組みに持っていきました。

二つ目は、当たり前ですがクラウドを管理運営するには、テクノロジーの理解が不可欠です。ついついオペレーションをする、運用するフェーズになると手順書に従ってやる形が多いわけですが、やはりそうなっていくと様々な事象に対してプロアクティブな行動が取れなくなります。
したがって当社の場合はさきほどのCCOEに依存するだけではなく、全社的にスキルの底上げが必要だと感じており、毎年少なくとも6、7名ぐらいは研修コースに出して、合計15日、3つの5日間のコースに派遣することで、みんな楽しみながら「新しいテクノロジーやツールを使いたい」と思っているわけです。
そういう意欲をかきたてるような施策をして、底上げを図っています。

ということで、最終的には「企業は人なり」。いろいろとテクノロジーの話をしてきましたが、一番効くのはこれだと考えております。

まとめ

まとめになります。
「マイクロサービスにおけるセキュリティ対策」ということで話してきましたが、マネージドサービス利用によってスコープを減らそうというのが一つ。
イメージやコンテナの脆弱性はテクノロジーを使って対処していこうというところです。
モニタリングについては、なかなか自前で全部やっているという方はもういないと思いますが、ツールを組み合わせながら効率的にモニタリングをしていくと。
運営といいながらも、これも新しいスキルを学んで成長しながらやっていくことが大事。というかたちで、最後は締めさせていただきます。

やはりエンジニア自身がワクワクしながら仕事ができる環境、こういうものを作り出すということが、当社でいうと業界最高レベルのセキュリティ対策に繋がっていると私は信じていますし、実際にそうだと思います。これからも新しい物に触れる、試してみるというような環境としてクラウドは非常に最適だと思いますし、今後も適材適所でクラウドを使い倒してハッカーと戦っていきたいと思っております。

エンジニアイベント書き起こし記事一覧はこちら

採用情報はこちら

パートナーインタビュー記事一覧はこちら

※本コンテンツ内容の著作権は、GMOペイメントゲートウェイ株式会社に属します。