自己紹介とClassiについて
大南賢亮氏（以下、大南）：Classi株式会社の大南です。本日は「セキュリティインシデントを乗り越えるために行ったマルチアカウントでの取り組みについて」というタイトルで発表します。
大南賢亮です。直近10年くらいはBtoCサービスを中心に、DBA、サーバーサイドエンジニア、SREを経験しています。Classiには、2019年5月にSREとしてジョインしました。ここ数年はインフラとセキュリティ領域を中心に業務を行っています。
まずClassiについて説明します。Classiは教育現場を支援するクラウドサービスです。全国の高校の50パーセント超が導入、高校生の3人に1人が利用。利用者数100万人超、先生、生徒、保護者がつながる学習支援プラットフォームです。
本日話さないこととして、2020年4月5月の高負荷によるアクセス障害状態に関する取り組み。こちらはClassi開発者ブログ、またDevelopers Summit 2021年を見てください。
Developers Summit 2021では、弊社のVPoT、VPoEが「全国一斉休校によって教育プラットフォームの『Classi』に起こった大障害〜サービス・組織をどう変化させたのか〜」というタイトルで話をします。
セキュリティインシデントとその後の対策
それでは本編に入ります。まず、セキュリティインシデントについて。2020年4月5日、外部の攻撃者から不正アクセスを受け、サービスを停止しました。サービスは数時間後に復旧できたものの、ユーザー情報流出の可能性を確認しました。
5月17日には流出したすべてのユーザーのパスワード変更が完了し、対応自体は終わっています。また、7月には外部サイトで流出した個人情報の漏洩を確認しました。弊社では4月からインフラ、アプリケーションともに抜本的なセキュリティの見直しを実施して、対策を進めました。
対策を進めるうえでの戦略と評価について、まず話します。全体の戦略については、AWSのWell-Architected Framework Security Pillarを参考にしました。また、AWSアカウント管理の戦略については、Best Practices for Organizational Units with AWS Organizationsという記事を参考にしています。
セキュリティ評価については、AWSさまのプロフェッショナルサービスを利用しました。こちらでセキュリティ評価と、今後の対応のアクションプランについてアドバイスを受けています。
AWSアカウント管理と問題点
次に、AWSアカウント管理に入ります。もともとClassiでは、Organizationsは設定してあるだけの状態で、こちらのOrganizationsの図のように、ルート直下に各AWSアカウントがただぶら下がっている状況でした。
また、ログインについては、AzureADと連携したG Suiteにまずログインして、SAML連携してあるBastionアカウントにログインして、そこから各アカウントにSwitch Roleするかたちを取っていました。
問題点です。OU/SCPを利用していないのが、“有効に活用できていない”という意味で、問題点として認識していました。また、Productionアカウントが、以前はマスターアカウントと呼んでいたOrganizationの管理アカウントとして設定されており、最も厳密に管理したいはずのProduction稼働のアカウントが管理できていない状況にありました。
また、Bastionアカウントに関しては、開発者がSandbox環境としても利用している状態でした。Productionアカウントにログインするもとのアカウントが、Sandboxとして利用されていると。セキュアではないのがわかると思います。
管理アカウントの切り替えと結果のOU構成
やったことです。まず管理アカウントの切り替えをしました。管理アカウントを新規に作成し、既存アカウントは旧組織を離脱、課金回りの設定を追加し、新組織へ移動をポチポチやりました。これが非常に大変でした。これからOrganizationsを導入する方は、新規に管理アカウントを作ることを強くおすすめします。OU設計と配置にしては、戦略のところで話した内容を参考にしています。
その結果、ClassiのOrganizationsはこのような構成になりました。ルートにマスターアカウントが紐づき、Foundational_OU、Maintenance_OU、Suspended_OUが次の階層にあります。
Maintenance_OUは計画メンテナンス用のOUです。また、Suspended_OUはAWSアカウントを廃棄するときの待機期間に所属させるOUになっています。
Foundational_OUの配下にはWorkloads_OU、その下にはProductionのOUとSDLC（ソフトウェア開発ライフサイクル）、ステージングからデベロップメント、Sandboxなど、さまざまな開発用の環境を含めています。
そしてWorkloads_OUと並ぶかたちで、共通基盤系のアカウントを格納するInfra_OU。こちらはセキュリティのアカウント、各種ログ集約のアカウントなどが含まれます。そして、SCPのポリシーの変更などを試すような環境のPolicyStaging_OUを1つ作っています。こちらに一覧で書いてあります。
IDとアクセス管理とその問題点
次にIDとアクセス管理についてお話しします。はじめのほうで出てきた図に、ちょっと追記したものになります。マネジメントコンソールを利用する場合は、G Suiteからログインアカウントオートで個別にアクセスキーを発行して、プログラムアクセス用は、各アカウント内部で管理する仕組みになっています。
問題点として、Roleとアクセスキーの管理。こちらは別々に管理を行う必要があり、煩雑です。また、アクセスキー管理は永続的なアクセスキーの管理が、利用者任せになってしまい、把握できなくなる恐れがあります。
Switch Roleのセキュリティに関しては、過去スイッチ先RoleのPrincipalの設定のミス。こちらが広く指定されていることで、Bastionアカウントからいろいろな権限で入り放題になっていました。
ローカルマシン・AWSそれぞれの対策
やったことです。ローカルマシン側の対策として、awslabs/git-secrets。みなさん利用していると思いますが、アクセスキーなどの機密情報をGitリポジトリへのコミットを防ぐ目的で導入しています。
また、AWS側の対策としては、AWS SSOへの移行。9月にTokyo Regionにローンチしたタイミングで移行しました。
AzureADと直接連携することで、アカウント管理が非常にシンプルになっています。また、これはすごくいいポイントなんですが、アクセスキーを個別のAWSアカウントで管理する必要がなくなり、管理コストが大幅に下がっています。SaaS向けのアクセスキーに関しては除きます。
AWS SSOを導入したことで、各ユーザーの端末からAWS SSOのポータルを経て各アカウントにそのままログインできるようになり、手間もかなり減ってきています。
移行時にハマったトラブル
ここで1点、私が移行時にハマったトラブルとして伝えたいと思っているものがあります。事象としては、Switch Role時代の管理者用Roleをエイヤで削除したところ、サービスで利用しているCMKが閲覧、変更不可能になってしまいました。Administrator権限を持っているユーザーでも、rootでも、どうにもできない状況になりました。
原因としては、削除した管理者Roleのみをキーポリシーの管理者として指定していて。削除した時点で、キーポリシーから管理者の記載が消えてしまうため、管理者不在のキーになってしまうことがありました。
対応として、AWSのサポートへ問い合わせを行い、一時的なユーザーを作成。PutKeyPolicy権限をサポート側で付与してもらい、もとのキーポリシーを復活させて復旧できました。ただし、作業タイミングなどコントロールできない要素もあるので、戻せると思わずに、キーポリシーの管理者として複数のユーザー、もしくはRoleを付与しておくのがおすすめです。こちらはAWS SSO移行時の後始末として、注意しておくといいかと思います。
ガードレールについて
次に、ガードレールについてお話しします。予防的ガードレールとして、SCPの一般的な設定を導入しています。不使用リージョンの制限、監視系操作の制限、環境特有の制限、こちらは重要操作などを想定しています。全操作の禁止などです。
こちらは先ほどのOUと、設定しているSCPのマッピングを一覧にしたものです。これだけ見てもちょっと想像しづらいので、Organizationの図と照らし合わせて見ていきましょう。Foundational_OUに関しては、リージョンの制限と監査系操作の制限を付与しており、これが大部分のOU、AWSアカウントに対して警鐘されるようになっています。
Maintenance_OUに関しては、メンテナンス用で都度必要とされるポリシーは変わってくるので、ここは都度変更で設定していきます。Suspended_OUに関しては、廃棄予定のAWSを格納するOUなので、全操作の禁止を設定しています。
Workloads_OUに関しては、開発者向けの制限。Production_OUに関しては、重要操作の制限。Infra_OUに関しては共通基盤特有の制限、こちらは特定の機能だけしか使わないことが多いと思うので、そういう部分を絞っていきます。PolicyStaging_OUに関しては都度変更して試す場所なので、特に定めてはいません。
次に、発見的ガードレールについてお話しします。CloudTrailによる特定操作の監視やConfig、GuardDuty、SecurityHub、Trusted Advisorを利用しています。検知した内容のフィルタリングに関しては、まだまだチューニングを進めている状況です。
発見的ガードレールで利用する以下の3サービスに関しては、Configだけは自動有効化ができないため、CloudFormationのStackSetsを利用して有効化するようにしています。
Organizationsとセキュリティ系サービスのマルチアカウント対応はまだスムーズじゃない部分がちょこちょこあると思っているので、こちらには早くスムーズな統合が実現してほしいなと考えています。
今後の方向性とまとめ
今後です。今後は発見的ガードレールのチューニング、Config Rulesや、GuardDuty/SecurityHubの検知内容の精査を進めていきたいと考えています。またロギングとモニタリングに関しては強化を進め、SIEMの導入、特にSIEM on Amazon ESを検討しています。
また、AWSからちょっと離れますが、インシデントレスポンスの強化というところで、Hardeningイベントへの参加だったり研修だったりで、レスポンスの体制やスキルの強化を進めていきます。
まとめです。インシデント以降、マルチアカウント構成を活かしたかたちで対策を進めてきています。AWS SSOを利用することでアカウント管理コストが下がり、セキュアになりました。予防的、発見的ガードレールの導入で、よりセキュアになっています。みなさんもマルチアカウントを導入してセキュアな環境を手に入れよう、ということで終わりにしたいと思います。
ClassiではSREを絶賛募集しているので、興味がある方はよろしくお願いします。以上になります。
質疑応答
光野達朗氏（以下、光野）：大南さんありがとうございました。それでは質疑応答に移ります。最初に、「RoleとSCPの管理を行うのは負荷にならなかったですか？」こちらいかがでしょう？
大南：SCPの管理はそこまで細かくというか、多くないと思っていて。わりとはじめに定番のものを入れて、あとは微調整していくかたちだったので、それほど負荷にはならなかったです。
光野：ありがとうございます。次の質問、「予防的ガードレールとしてPermission Boundaryは使っていますか？」こちらの質問はいかがでしょう？
大南：Permission Boundaryに関しては使っていません。弊社では今SREが3人くらいますが、けっこうPermission Boundaryは管理が難しいと思っていて。設定しても見落としがちなところがけっこう、運用上の難しさのようなところをちょっと感じていて。弊社では利用していません。
光野：ありがとうございます。それでは次の質問。「本題ではないですが、AzureAD×GSuiteの構成が気になりました。AzureADからAWSへのSSOはできなかったのでしょうか？」
大南：もともとAWS SSOができる前からこういう構成だったので、そのまま使っていたと。AWS SSOはいいなとは思っていましたが、最初にお話したとおり、セキュリティの抜本的な見直しを進めていく中で、優先度を考えるとちょっと対応が後ろでもいいかなと思って見送りつつ、Tokyo Regionに来たらAWS SSOに移行しようと思っていました。
もとからそういう状態だったというところで、今回運用コストを下げたり、セキュリティ向上のために移行しました。以上です。
光野：ありがとうございます。それでは次の質問で、「Config Ruleは現在どのようなものを設定して運用していますか？カスタムルールも運用していますか？どのようなルールを使われていますか？」
大南：Config Ruleに関しては、まだあまりチューニングできていない状況で、基本的なものしか設定していないです。ただ、それでもけっこう引っかかってくるなっていう感じで（笑）。試しながら変えたりしているような状況で、あまり参考になる情報は伝えられないかなと思います。
ただ、ConfigでConformance PacksやAd Hocでバシッとセキュリティ上の問題を洗い出したりはしています。以上です。
光野：ありがとうございます。「他のセキュリティ系のサービスで導入を検討しているものはありますか？」こちらはいかがでしょう？
大南：今は使っていませんが、IAMのAccess Analyzerなどを検討しています。マルチアカウントの話とはちょっとズレますが、コンテナセキュリティではaquaをちょっと使ってみたいなと思っています。あと、SIEM on Amazon ESは優先度を上げて導入してみたいと思っています。
光野：ありがとうございます。「Config Ruleなどの検知設定のチューニング時の基準はありますか？必要不要の判断の際に参考にするバックグラウンドとなるセキュリティポリシーが存在するのでしょうか？」という質問について。こちらはいかがでしょう？
大南：現在もそこの基準をまずきちんと策定できていないので、そこはやっていこうとしています。セキュリティ対策の優先度順からいくと、まずはAWSのアカウント管理、アイデンティティ管理、アクセス管理、あとはロギング、モニタリングという順番で来て。そのあとでポリシーを詰めていこうかと思っている状況です。以上です。
光野：ありがとうございます。やはりたくさんSCPに関する質問をもらっていますね。ではそこから1つ。「SCPはAWS導入の初期から実施されましたか？AWSを運用した途中からSCPを入れるとしたら、苦労しましたか？」。こちらいかがでしょう？
大南：弊社ではAWSの運用期間はそれなりに長く、6年くらい経っていると思います。なので途中からになります。確かにあとから入れるのってすごく難しいんです。
とはいえ、もちろんセキュリティインシデントを起こしてしまった以上、そこは影響を見ながらでもやらなきゃいけない部分ではあったので問題があったらすぐに戻す感じで、計画メンテナンスのときなどに入れて確認したりはやっていました。
光野：ありがとうございます。「SCPはWAFみたいにカウントモード欲しいですよね」というコメントももらっています。
大南：そうですよね～。すごくよくわかります。
光野：それでは時間的にあと1つか2つですね。「SSOユーザーのアカウントへの紐づけ情報の棚卸しは実施されています？」という質問をもらっています。こちらはいかがでしょう？
大南：けっこう原始的ですが、スプレッドシートで管理しています（笑）。スプレッドシートでユーザーとPermission setの対応を管理しています。他にいい方法があったら教えてください。
光野：ありがとうございます。それではこちらで大南さんの登壇、質疑応答を終了したいと思います。大南さん、ありがとうございました。
大南：ありがとうございました。
