個人検証アカウントでも最低限設定したいプラクティス～私の環境のご紹介～

皆さんこんばんは。
2024年1月30日に開催された JAWS-UG 東京支部主催オンラインイベント、「AWS個人検証アカウントどう運用してる？ランチ共有会」にて発表しましたので、解説いたします。

発表動画・資料
登壇内容の解説/リンク
まとめ

発表動画・資料

映像はこちらになります。

資料はこちら

登壇内容の解説/リンク

SpeakersDeck上のデッキにあるリンクはクリックできないようですので、登壇内容の解説をしつつ関連URLをご紹介します。

私の個人AWSアカウントについて

私の個人AWSアカウントは2015年から開設しています。
個人アカウントとは言え、検証用途だけではなく、一部本番用途にも利用しています。

本番用途
- 本ブログサイト (Amazon CloudFront / AWS WAF / Amazon EC2)
- オンプレミスNASのバックアップ（Amazon S3 Glacier Instant Retrieval）
- AWSブログを巡回してアップデートを通知するスクリプト (AWS Lambda / Amazon Translate等）
検証用途
- ハンズオン参加時や、ブログ記事執筆時の検証環境
- 会議脱出ボタンデモ環境（AWS Lambda / Amazon Connect)

従来は1つのAWSアカウント内で本番環境（東京リージョン）と検証環境（オレゴンリージョン）で便宜的に分け運用することで区切っていました。しかし、この運用ではIAM設定が混ざったり、一部リージョン指定のハンズオン実施に問題があったため、2年前に構成を見直しました。

対応内容はこんな感じです。

アカウント分離
- AWS Organizationsの導入
- AWS IAM Identity CenterによるSSO実現
セキュリティ運用
- CloudTrailによる証跡保存
- GuardDutyによる脅威検出
- AWS Configによる設定変更履歴の記録
- AWS Security Hubによる統合管理
- ログイン通知の実施

以下詳細をご説明します

本番/検証AWSアカウントの分離

まず、AWS Organizationsを用いて本番環境と検証環境のアカウント分離を行いました。

AWS Organizationsを用いたアカウント分離のメリットとしては、以下が挙げられるかと思います。

設定や課金額が完全に分離できること
子アカウントをいつでも廃止できること
アカウント分離しても一括請求であること
新規アカウント向けの無料枠が適用できること

なお、私のAWSアカウントでは上記の経緯から管理アカウントと検証アカウントの２アカウント構成になっているのですが、本来であれば管理アカウントは管理に徹してリソースは設置せず、本番環境用アカウントも分離すべきかと思います。

最も大きな理由はSCP（サービスコントロールポリシー）の制約ですね。
AWS Organizationsを用いればSCPを用いて各アカウントへの統制を掛けることができますが、管理アカウントにその制約を掛けることができません。

後のセクションで採りあげるセキュリティ設定は管理下に置いたリージョンでのみ有効であるため、管理外のリージョンで不正利用・侵害があった際に検出漏れとなる可能性があります。
そもそも使わないリージョンはSCPで制限を掛けてしまうことが非常に有用かと思います。

SCPでリージョンに制限を掛ける設定例は、AWS Organizationsのユーザーガイドに記述があります。

一般的な例 - AWS Organizations

このカテゴリの例 SCP でリージョン拒否を使用するには AWS Control Tower、 AWS Control Tower 「コントロールリファレンスガイド」の「リクエスト AWS されたに基づくへのアクセス拒否 AWS ...

なお、AWS Control Towerを用いればAWSが推奨するマルチアカウント構成が実現できますが、正直個人アカウントに適用するのはオーバースペックと考え利用は見送っています。

AWS IAM Identity CenterによるSSO導入

AWS Organizationsの導入後には、AWS IAM Identity Center(以下IAM IdC)によるSSO環境の導入も併せて行うことをお勧めします。

本サービスを用いることで、複数のAWSアカウントやSAML 2.0対応外部サービスへのSSOが実現できます。
また最近はIAM IdCを必須としているAWSサービスが増えてきていますね。

AWS Managed Service for Grafana
Amazon Monitron
AWS Supply Chain
など

さらにトピックスとして、IAM IdCを用いるとMFAデバイスとしてOSの生体認証デバイスが使えるのも嬉しいです。

IAM IdCの導入方法については、以前記事にまとめております。参考になれば幸いです。

AWS IAM Identity Centerで多要素認証つきシングルサインオン環境の実現

AWS Organizationsを用いたマルチアカウント環境を構成した際は管理が増え煩雑になりがちですが、AWS IAM Identity Centerを用いればシングルサインオンが実現できます。設定方法を解説します

セキュリティ設定

個人アカウントではありますが、AWSのベストプラクティスに則ったセキュリティサービスも設定しています。

AWS CloudTrailによる操作ログの取得、証跡の保存
AWS Configによる設定変更履歴の記録と評価
Amazon GuardDutyによる脅威検出
AWS Security Hubによる一元管理、セキュリティ標準に則ったチェック

なおAWS ConfigやAmazon GuardDutyは、アカウント／リージョンごとの設定となる点は留意してください。

私のアカウントの構成を図示するとこんな感じで、利用するアカウント、リージョンの検出結果を管理アカウントのAWS Security Hubで一元管理しています。

AWS CloudTrail、AWS ConfigやAmazon GuardDutyの設定手順にあたっては、AWSハンズオン資料（Hands-on for Beginners）にある「Security #1 アカウント作成後にすぐやるセキュリティ対策」の内容が非常に網羅的で良いと思っているので、ぜひ参考にしてください。