このページの本文へ

前へ 1 2 次へ

満漢全席を食らえ!JAWS DAYS 2019レポート第9回

Fintech企業として高いレベルのセキュリティと運用をAWS上で実現

Kubernetesに移行中のfreee、セキュリティとモニタリングを語る

2019年04月16日 10時00分更新

文● 高橋睦美

  • この記事をはてなブックマークに追加
  • 本文印刷

 JAWS DAYS 2019では、EC2からKubernetesに移行中のfreeeがセキュリティやモニタリングについて説明するセッションが披露された。スタートアップ企業である以上、ビジネスのスピードも重要な要素。一定のリスクを犯しながら高いセキュリティを実現するという、バランスを追求しながらのタスクになる。「EC2からKubernetesへの移行をセキュリティ/モニタリングから考える」と題するセッションではその取り組みの一端が紹介された。

freee CSIRT専属エンジニア 杉浦英史さん

AWSの機能やサードパーティのツールを活用して基盤を保護

 「スモールビジネスを世界の主役に」というミッションを掲げてクラウドベースの会計・人事労務サービスを展開しているfreeeにとって、セキュリティの確保は至上命題だ。多数の金融機関と連携し、決済・会計に関する情報をリアルタイムに扱っているだけでなく、電子決済・振り込み業務も担い始めた同社から情報が漏洩するようなことがあれば、影響は計り知れない。

 同社の杉浦英史さんらは、「万一失敗すればfreeeだけでなく、日本のFinTech業界にも迷惑をかけることになる」という危機感を持って、AWS EC2上に構築されたfreeeのセキュリティ運用に取り組んできたそうだ。

freeeの失敗=FinTech業界の危機

 freeeの基盤は約6年前の創業以来、AWS EC2上で運用されてきた。2018年に発覚したCPUの脆弱性にせよ、ごく最近明らかになったDockerの脆弱性にせよ、利用者側がそれと意識する間もなくAWS側が対応してきた経験を踏まえ、杉浦さんは「AWSのセキュリティは責任共有モデルと言われるが、AWSはIaaSとしてしごくまっとうな対応を行なってきた。AWSがインフラの部分について責任を持ってくれるのだから、私たちはそれよりも上の部分のセキュリティを作らないといけない」と語る。

 freeeでは、侵入から潜伏、探索、データの奪取という攻撃の「サイバーキルチェーン」に沿って対策を考えている。それも「インターネット側から入ってくる場合」と「管理用コンソールから入ってくる場合」という2つの想定攻撃経路それぞれについて検討し、防御手段を埋め込んできた。具体的には、AWS自身が提供するセキュリティグループなどの機能に加え、AWS WAFとトレンドマイクロの「Deep Security」、さらに「Amazon GuardDuty」を活用し、多層防御を実現しているという。

 たとえば、外部からの不正アクセスについては、「ELBを用いてIPアドレスやポートを制限した上で、AWS WAFで大まかな網をかけ、さらにDeep SecurityのIPS機能を用いてシグネチャへのマッチングを行なっている。そしてNginxでレートリミットをかけ、アプリケーションロジックで例外をはじき、侵入者がファイルを作成しようとする段階ではもう一度Deep Securityで中身を見る、という構造になっている」(杉浦さん)

 別の臼田さんのセッションでも触れられたアカウント管理についても考慮しており、SSHのログイン時には多要素認証(MFA)を実施しているほか、ログイン、ログアウトといった挙動が発生すればSlackに通知が来るほか、コンソールの動きもすべてロギングしてS3に保存する仕組みだそうだ。さらに、管理コンソールへのアクセスについては、ID as a Serviceの「OneLogin」を利用し、アクセスシークレットやアクセス制御の管理を簡素化した。

freeeでのDeep Securityの活用

 一方、侵入者による内部探索を見つけ出す方法についてはまだ模索の途中で、まずはVPC Flow Logsを用いてリジェクトログを取得するところから開始した。さらに、外部のEC2サーバーとの通信やデータ奪取を防ぐため、「セキュリティグループでアウトバウンド通信をなるべく減らすといった地道な手を打っている」(杉浦さん)そうだ。

 一連のログは「AWSなのでやはり『S3セントリック』な考え方でS3に集めており、そこに集めたものを解析してSlackに通知を飛ばしている」(杉浦さん)。その後、アラートが誤検知か、それとも対処が必要かの精査を加え、セキュリティ・開発担当の区別なく全員で原因を考え、修正など必要な措置を打っていく。「今は、アラートが起きてから始まるイベントドリブンのフローが大半だが、いずれは何らかの予兆を前もって検知して動けるようなインテリジェンスドリブンが理想的」と杉浦さんは述べた。

 他にも、AWS WAFではデフォルトのルールだけでなくサイバーセキュリティクラウドが提供する「WafCharm」というマネージドシグネチャを採用したり、DeepSecurityのアラートをリアルタイムに拾えるようsyslogに吐き出したり、GuardDutyを用いてリスクの高い設定を洗い出したりと、さまざまな機能を組み合わせ、セキュリティ運用に当たっている。

EC2とコンテナのいいところ取りを目指し、マイクロサービスへの移行中

 そんなfreeeが現在取り組んでいるのが、マイクロサービスへの移行だ。「エンジニアが今や130名ほどに増えた結果、1日に2回ほどしかデプロイができなくなってきた。できるなら1日10回くらいデプロイしたい」という意図から、EC2インスタンスとコンテナの「いい所取り」を目指しているという。

 とはいえ、マイクロサービス化を検討し始めた1年前、利用可能な選択肢はFargateとAmazon ECSのみだった。だが、プロダクションサービスに耐える仕組みを求めていた上、ワーカーノードだけでなくクラスターノードも含めてDevOpsを実現したいと考えていたことから、freeeではオープンソースの「kube-AWS」を採用し、環境を整えてきたそうだ。

 だがkube-AWSにも課題はあった。1つは、多層防御の一部を担うDeepSecurityがkube-AWSでは動かないこと。このためEC2の上にポッドを載せることにしたが、ネットワークポリシーの設定など作業すべき事柄が増えてしまった。

 もう1つは、マルチネームスペースの運用だ。「1つのクラスタの中にマルチネームスペースがあるのはよくある話だが、なるべくやりたくない。KubenetesのRBACとIAMロールのマッピング、EC2インスタンスのプロファイルとKubenetesのポッドやノードのマッピング、セキュリティルグープとネットワークのマッピングをして、どうオートスケールすれば調和した世界が来るかというと、これはもう無理」(杉浦さん)

 そんな悩みを抱いていたところに、2018年12月20日にリリースされたのが「Amazon EKS」だった。「何がうれしいかというと、コントロールノードの部分をマネージドで提供してくれること。このためAPIサーバの管理などから解放される。公式なAMIも利用できるし、クラスタの追加・削除が簡単なこともうれしい」(杉浦さん)。個別にコンソールロギングなどの機能を用意する必要もなくなった。

 もちろん課題がないわけではないが、オープンソースの「eksctl」を利用したり、ネームスペースとクラスタを1対1の関係にするシングルクラスタを採用したりと工夫を凝らし、マイクロサービス基盤をkube-AWSからAmazon EKSへと移行させる作業を進めている。これにより、クラスタごとブルーグリーンデプロイできるようにしたいという狙いがあるという。

「私たちfreeeは最高速で前に進まなければいけないと考えている。そのためには、マネージドで提供されているものを積極的に利用し、他の会社がやっていない価値のあるところに注力して開発するというスタンスでミッションを完遂したいと考えている」(杉浦さん)

前へ 1 2 次へ

この連載の記事