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

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

発表動画・資料

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

資料はこちら

登壇内容の解説/リンク

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

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

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

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

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

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

以下詳細をご説明します

 

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

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

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

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

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

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

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

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

なお、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 アカウント作成後にすぐやるセキュリティ対策」の内容が非常に網羅的で良いと思っているので、ぜひ参考にしてください。

ハンズオン資料 | AWS クラウドサービス活用資料集

またAWS Security Hubの導入にあたっては、Developers.IOの記事を参考にさせて頂きました
ありがとうございます。

セキュリティチェックが捗る!AWS Security Hubで全リージョンのセキュリティ基準の結果を集約して見れるようになりました! | DevelopersIO
AWS Security Hubのセキュリティ基準が1箇所で全リージョンの結果を見ることが出来るようになりました!やったー!
【アップデート】AWS Security Hub が検出結果のリージョン集約に対応しました | DevelopersIO
AWS Security Hubの検出結果を楽ちんリージョン集約

 

AWS Security Hubによる運用

以上の設定により、AWS Security Hubによる一元管理ができるようになりました。

AWS Security Hub側でセキュリティ標準の適用を有効化することで、AWS Config Rules側にルールが自動反映されチェックされるので非常に便利です。(AWS Config側は有効化するのみでOK)

なお当方では個人環境ということもあり「AWS基礎セキュリティのベストプラクティス」のセキュリティ標準のみ有効化しておりますが、セキュリティ関連サービスで発生しているコストは概ね 3ドル/月 程度となっています。

CloudTrailで発生するログ量に依存しますので、量により課金に影響する可能性があります。
あくまで私の環境の例としてご理解ください。

 

マネジメントコンソールログイン時の通知

私の環境では同僚のブログ記事を参考に、AWSマネジメントコンソールにログインした際にAmazon SNS経由で通知する仕組みも導入しています。

こちらCloudFormationテンプレート付きで公開されているので、サクッと導入できると思います。
ぜひお試し下さい。

AWSコンソールサインインとIAM操作の通知を実装する方法 [AWS CloudFormation テンプレート付き]
皆様はAWSコンソールサインインやIAM操作の通知が欲しくなったことありますでしょうか。 今回は「AWSコンソールサインイン」と「IAM操作」の通知機能をさくっと実装する例を紹介します。すぐにプロビジョニングできるように 可能な限り、AWS CloudFormation テンプレートを付けさせていただきたいと思います。

 

まとめ

最後に、不正利用があった際に直ぐに気付くよう、AWS Budgetsの設定はしましょうね。

さて、以上登壇内容の解説でした。

今回は登壇準備が後手後手に回ってしまったこともあり、プレゼンはグダグダになってしまって申し訳ありませんでした。イベント後のアンケートも拝見しましたが、良い評価を頂き感激です。

最後に、本登壇機会を頂きました JAWS-UG 東京支部運営の皆様に感謝です。
ありがとうございましたー

コメント