FinatextにおけるAWSのガードレール戦略の紹介

Satoshi Tajima

·

Follow

Published in

The Finatext Tech Blog

·

7 min read

·

Dec 11, 2019

--

Share

はじめに

こんにちは、Finatextでエンジニアをしている @s_tajima です。

Finatextでは、現在約40個のAWSアカウントを管理しています。
それぞれのAWSアカウントは、あるサービス専用になっていたり、いくつかのサービスが同居していたり、本番環境用だったり、開発環境用だったりと用途は様々です。
この中には、 証券ビジネスプラットフォームのBaaS を提供しているAWSアカウントも含まれます。

このBaaSに限らずとも、金融ドメインで広くサービスを提供しているFinatextでは、その基盤となっているAWSのセキュリティの管理が非常に重要になってきます。
今回は、弊社がAWSのセキュリティを担保するためにどんな運用をしているかというお話です。
既に複数のAWSアカウントを管理している方、特に管理はしているもののいまいち適切な状態になっていないと感じている方に読んでいただけるとよいかなと思っています。

一部の話は、6月に行われたAWS Summit Tokyo 2019でも紹介していますので合わせてご覧ください。
https://aws.amazon.com/jp/blogs/startup/summit2019_day2_recap/

基本方針

弊社では、現時点ではエンジニアを、アプリケーションエンジニア/インフラエンジニア/AWSエンジニア/XXXエンジニア等と明確に区別することはせず、多くのエンジニアが必要に応じてAWSのリソースを操作する機会や必要性を作っています。

よって、基本方針としては「IAMの権限を厳しく、保有する人を極度に限定して安全性を高める」というよりは、「権限は付与するが、本当にリスクの高い操作はできない、もしくはすぐにそれに気づくことができ、ログを確実に追うことができる」状態を目指しています。

これは、近年AWSが提唱している「ガードレール」の考え方も参考にしています。
今回は、この方針に基づきどんな運用を行っているかを、項目として

• AWSアカウントの一覧管理
• AWSアカウントへのログインの管理
• AWS上のログの管理
• AWS上のオペレーションの制限
• AWS上のオペレーションの監視

というくくりで紹介します。
全体の概要図はこんな感じです。

AWSアカウントの一覧管理

「AWSアカウントのセキュリティを担保しましょう！」と言っても、まずは対象となるAWSアカウントをきちんと把握できなければいけません。

弊社では、基本的にはすべてのAWSアカウントを1つのAWS Organizationで管理しています。
https://aws.amazon.com/jp/organizations/

AWS Organizationを使うことで、AWSアカウントの一覧が簡単に参照できるようになるだけでなく、
後述のSCPs (Service control policies) を使うことで、ルートアカウントに対しても権限の制限をかけることができるようになります。また、新しいAWSアカウントの作成プロセスも簡単になります。

AWS Organizationを使わずに複数のAWSアカウントを管理している状態から、1つのOrganizationで管理ができる状態に持っていくには、1つひとつのアカウントを招待する必要があり、数によっては少し骨が折れます。
また、Organization単位でAWSの請求がまとまるので、会社の経理の方との調整が必要になる場合もあるのでその点は注意です。

AWSアカウントへのログインの管理

人間 (※ボット等ではないという意味) がAWSのマネジメントコンソールにログインしたり、CLI等からAWSの操作をする場合は、ある専用のAWSアカウントに作成した個人用のIAMユーザを使い、操作対象AWSアカウントに作ったIAMロールに対するAssumeRoleをしてクロスアカウントアクセスをします。つまり、それぞれのAWSアカウントに個人用のIAMユーザを作るということはしません。

この方式を採用することで、IAMのクレデンシャルを定期的にローテートしたり、MFAを強制したり、退職者のアカウント削除をしたりなどの管理の手間が大幅に減ります。

AWS上のログの管理

CloudTrail, AWS Config, VPC FlowLogs, ALBのアクセスログといった、AWSで出力できるログは基本的にはすべて有効化する方針です。
また、出力先は個別のAWSアカウントではなく、専用のAWSアカウントにしています。
これには、

• 専用のAWSアカウントであれば権限を厳しくしやすいので、誰もログが削除できない状態にできる。
• ログが一箇所に集中するのでログを監査する仕組みはそこを対象にするだけでよい。

というメリットがあります。

AWS上のオペレーションの制限

前述のAWS OrganizationのSCPsを使うと、たとえAdministratorAccessの権限があっても実行できないAPIを定義することができます。
弊社では、このSCPsを活用し、以下のような制限をかけています。(リンク先がポリシーのJSONのサンプルになっています。)

• AWS Organizationからの脱退の禁止
• CloudTrail, AWS Config, GuardDuty, SecurityHubの設定の変更の禁止
• RDS, ElastiCache, S3 Bucket等の永続化データが置かれうるリソースの削除の禁止
• 東京リージョン以外の利用禁止

最後の東京リージョン以外の利用禁止を設定することで、社内のメンバーもしくは悪意のある第三者が、海外リージョンにリソースを作成してしまい、それに長い間気付けずになるといった事態を防ぐことができます。また、それらのリージョンでリソースを起動できないことを担保できれば、AWS Config, GuardDutyのようなリージョン毎に設定しなければならないサービスの設定を省略することができるだろうという考えです。

AWS上のオペレーションの監視

AWS上で行われたオペレーションのうち、高いリスクが発生しうるものについてはSlackに通知が飛ぶようになっています。
これは、CloudTrailやAWS ConfigのログをLambdaで監視することで実現しています。
具体的には以下のような形です。

0.0.0.0/0 に開放した場合にはメンションがつくようになっています。

こうすることで、AWSに慣れていなかったり、まだ技術的理解度が高くないメンバーにも権限をわたすことができ、不適切なオペレーションが発生したときには分かる人が声をかけて改善できるような環境になっています。

以上 、FinatextにおけるAWSのガードレールの実現方法の紹介でした。
このようなガードレールを効率的に管理するために、設定をすべてTerraformで管理し、Atlantis をつかって運用のコストを削減する工夫などもしているのですが、それについては別の記事でシェアできればと思います。

最後に

Finatextでは、一緒に働く仲間を募集しています！
全く新しい金融ビジネスプラットフォームを創造することに興味がある方、ぜひご連絡ください！
https://recruit.jobcan.jp/finatext/show/001/115496