セキュリティ向上のための可視化に取り組んだ話。複数AWSアカウントの管理方針

アソビューSREチームの三森です。

弊社ではパートナーやゲストへ提供しているプロダクトのインフラ環境はAWSで構築しています。 これまで実施してきたセキュリティ関連の運用への負荷が高まってきたため、効率化が求められるようになりました。 今回はセキュリティ関連の運用を楽にしたことについてお話をしようと思います。

困っていたこと

アソビューでは各提供サービスごとに複数のAWSアカウントを運用しています。そのため、各アカウントのセキュリティの状況は各アカウントで確認をしていますが、 運用の負荷が高くなってしまっておりました。 また、AWSリソースが複数アカウントにまたがっているため、セキュリティ課題の優先度判断に時間がかかっていました。

やったこと

課題を解決するために以下を目標としました。

  • できる限り多くのセキュリティに関する状態を一箇所で確認できるようにする
  • 外部からの攻撃の可能性や潜在的なリスクを洗い出せる状態にし、優先的に解決できるようにする

実際にやったこととしては主に2つです。

集約するためにアカウントを作成

AWSにはSecurity Reference Architecture というAWSが提供しているセキュリティサービスにフォーカスをした推奨アーキテクチャがあります。 このアーキテクチャにはセキュリティ関連サービスが描かれていますが、全てのサービスの利用を促進するものではなく、状況に合わせて利用することが推奨されているものになります。 詳細は以下のURLをご参照ください。

docs.aws.amazon.com

AWS organization and account structure of the AWS SRAの考え方に従い、Security Hubなどのツール情報収集用(Security tooling account)アカウントと CloudTrailのログの一元管理用(Log archive account)アカウントを作成して、役割を与えて管理を始めました。

前者は、Security HubやControl towerを導入して防御的ガードレールやプロアクティブにガードレールを設けて、全体的に運用できるような環境になっており、 後者は監査ログなどの情報を集約するためのアカウントとして作成して、主に監査ログの保護などを実施していくためにアカウントを用意しました。

Security tooling accountに関しての詳細は以下をご参照ください。 docs.aws.amazon.com

セキュリティに特化したAWSサービスを有効化&1つのアカウントで操作できるように集約

上記のツール情報収集用(Security tooling account)アカウントに管理者権限を委任し、 セキュリティ関連のAWSサービス(Trusted Advisor, AWS Cloudtrail, AWS GuardDuty, AWS Security Hub, AWS Config)の情報を一元管理を始めました。 これにより全アカウントのセキュリティレベルが可視化されるようになりました。

結果

実際にSecurity tooling accountを運用し始めて、各アカウントのセキュリティの状況を1アカウントで見れるようになり、運用が楽になりました。 具体例でいうと、AWSAWS Configを使い、全アカウントに設置されたセキュリティグループ内で(不要な)特定のIPアドレスを探すのが楽になったり、 GuradDutyによる一部のAWSリソースへのセキュリティ設定(監査ログなど)が一箇所でできるようになったりと運用にかける時間が短くなりました。

またセキュリティ関連のAWSサービスの結果を見直し、セキュリティ課題の優先度を決定が早くなり、アクションまでのリードタイムを短縮したことで、 アクセス設定でリスクのあるS3バケットの特定&対応が早くなったり、EC2のパッチ当てなどもすぐに対応ができるようになりました。

まとめ

今回のセキュリティ向上における取り組みで、優先順位の決定が早くなったことが大きな成果かなと思います。 例えば、EC2やコンテナの脆弱性の影響度やレベルがまとめてわかるようになり、影響度の大きいものから解決していくという流れが以前よりもスムーズになりました。

また、この対応を通じて各AWSリソースの設定においてどういったリスクがあるのかなど改めて理解が深まりました。 こうしたセキュリティリスクへの理解を深めることで、例えばS3のアクセス許可や暗号化など、 これまでちゃんと理解できていなかった設定にも意識を向けられるようになりました。

複数のAWSアカウントを運用されているケースは多いと思います。対応する工数や人が足りないなどの理由は様々ですが、 セキュリティ関連の運用への時間が多く割けないことが多いのではないでしょうか。

弊社のSREチームは少ない人数で組んでおりますが、AWSのベストプラクティスやフレームワークを運用に取り入れると、 AWSのマネージドサービスを取り入れた運用になり、結果的に少ない工数で運用ができる場合もあります。

セキュリティ周りの運用は状況に合うようにマネージドサービスを使う方が良いのではないかと考えています。

今回の対応はあくまでもセキュリティ向上する取り組みの序章にすぎません。 今後は取得したログや脆弱性の一覧をもとに、計画を立てて取り組んでいく必要があります。

セキュリティの取り組みが甘く大きなインシデントがニュースで取り上げられている昨今ですが、 今回な地道な取り組みの積み重ねで事前に防ぐことはできると思います。

最後に

SREチームでは、セキュリティの向上だけでなく、その他様々な取り組みを行っています。

扱っている技術や事業に興味がある方、アソビューでは一緒に働くメンバーを大募集しています! カジュアル面談もありますので、少しでも興味があればお気軽にご応募ください!

www.asoview.com