Help us understand the problem. What is going on with this article?

AWS アカウント管理のためにそれ系のサービスをキャッチアップしたメモ

AWS アカウント管理

プライベートで使っているAWSアカウントの整理と、そこから先に継続的で柔軟な開発を続けていくための下準備のために、AWSのアカウント保護や脅威検出周りで試したり、調べたことのまとめ。

まずルートアカウントの現状を整理した。アカウントは1個だけもっていたが、これをルートアカウントとして使っていき、組織を使ってサービス単位のアカウントを運用できるようにする。

  • ルートアカウントからすべてのリソースを削除
  • ルートアカウントの請求設定などを確認して不備があれば修正
  • ルートアカウントの組織の状態を確認
  • ルートアカウントに開発用のAdmin権限グループを作成
  • 個人の単位でIAMユーザを作成して、Admin権限グループに追加
  • 作成したIAMユーザに2要素認証を設定(IAMは基本的に、作るたびにMFAを必ずセットで有効化している)

アカウント保護

とりあえず、目的に対してやる意義が高そうとおもった順番から書いておく。

  • ControlTower
    • 安全なルールで・・・複数アカウントにまたがる保護
  • GuardDuty
    • アカウントワークロードの保護、驚異検出
  • SecurityHub
    • セキュリティとコンプライアンスのセンター
  • Detective
    • 潜在的なセキュリティ問題の調査と分析
  • Inspector
    • アプリケーションのセキュリティ分析
  • WAF & SHEILD
    • DDoS攻撃及び悪意のあるウェブトラフィックの保護

ControlTower

参考記事など

AWS公式ドキュメント: https://docs.aws.amazon.com/ja_jp/controltower/latest/userguide/what-is-control-tower.html

ClassMethodさんの記事: https://dev.classmethod.jp/articles/aws-control-tower-ga/

ControlTower自体はマネジメントコンソールの画面から操作する。ControlTowerを有効化すると、アカウントを横断的に監視してGuardRailsの基準に則って警告などを上げてくれるようになる。

2020年6月7日 時点だが、東京リージョンに来てないので、バージニア北部で試している。

  1. ControlTowerが利用するため、組織でAWS Config、AWS CloudTrail、CloudFormation StackSetsを利用可能なように設定変更しておく
  2. 既存のAWSアカウントで使用されていないメールアドレスを2つ用意する
    • ControlTowerが自動でアカウントを2作るため、ログ記録用と監査用アカウントの2つ
  3. ランディングゾーンの作成画面を開く
  4. 作成した2つのメールアドレスを入力して、ランディングゾーンの作成を開始する
  5. SSO(Single Sign On)やSNSのSubscriptionのメールが届くため、受け取ったメールからConfirmボタンを押していく

SSOでMFAを対応しておく:https://dev.classmethod.jp/articles/increase-aws-sso-security-with-mfa-using-authenticator-apps/

1時間ほどかかって、Landing Zoneの作成が完了する。ここから、アカウントファクトリーの機能を使ってアカウントの作成をする。

アカウントファクトリーでは、既存のAWSアカウントで利用されていないメールアドレスと、追加対象の組織グループ、そのアカウントの名前、SSOの対象アカウントメールアドレスを入力して、作成ボタンをクリックするだけ。

アカウントファクトリーでアカウントを作成したあとにやること

ルートアカウントでログインして下記を設定する。

  • IAMダッシュボードで警告がでているのをすべて緑にする
    • ルートアカウントのMAF設定
    • Admin権限を持つadminsグループの作成
    • adminsにadminユーザを作成
    • adminユーザにMFA設定
    • パスワードポリシーの設定
  • スイッチロールの設定
    • 追記予定

ちなみに、CloudFormationを見ると、ControlTowerから設定されたスタックを見ることができる。削除してはいけない。またCloudTrailなどもデフォルトでONになっている。

GuardDuty

CloudFormationも提供されているが、マネジメントコンソールで有効化のボタンをクリックするだけなので、自動化までするべきかどうか微妙。
新しいアカウントを組織に作成した際に、CloudFormation StackSetsで自動化することも検討できるが、全部が全部のリージョンに予め作るかとなるとそれも微妙で、かといってどれかのリージョンだけ個別に予め作成されるというのも変なので、AWSがそのあたりを自動化していないならそれに則っておいたほうが良さそう。

とりあえず組織のルートアカウントでは、バージニア北部と東京でGuardDutyを有効にしてみておいた。

SecurityHub

これもマネジメントコンソールでボタンをクリックるするだけ有効化できることと、全部のリージョンでいきなり有効化するかどうかの問題があるので、やってない。

とりあえず東京で有効化しておいた。

Detective

GuardDutyの有効化がDetective利用の前提条件であり、そのためにはGuardDutyを有効にしてから48時間待ってからのみ、Detectiveを有効化できるようで、まだ試せていない。

Inspector

EC2が対象で、今日日あんまりEC2使わないし、チェックしたい項目もピンとこなかったのでやってない。

WAF & Shield

リージョン別に、IPアドレスや、アクセス元情報を正規表現でチェックしたりして、対象のアクセスがあれば弾いてくれたりしてくれるらしい。攻撃対象をあるAWS程度目星をつけて、事前にパターンで防いだり、実際の事象から対象を決めていくことが多いと思い、最初からベストパターンで設定することなど不可能なので、見送った。

まとめ

なんとなく気になったAWSアカウントの保護周りのサービスをざっと触ってみたが、ControlTowerがほとんどカバーしてくれそうな感じ。さらに細かくセッティングしていくとなると個々のサービスを使うことになると思うが、お決まりでなんでも最初に設定しておくのはアプリケーションの方向性とかによって変わってきそうなので、要件とか優先事項が決まってから設定するものなのだと思った。

AWSアカウントを情報漏えいなどの対策として保護するのであれば、キーのローテーションと2要素認証を徹底すれば保護できる。もう少し踏み込んで、全体の監査をやってくれるControlTowerは強力。早く東京リージョンにも来てほしい。

それ以上にアプリケーション寄りになってくると、マイクロサービス的な観点で、それを開発する開発陣が裁量もって自分たちで試行錯誤と設定をしていく方がよほど効率的だと思う。

mediado
私たちメディアドゥは、電子書籍を読者に届けるために「テクノロジー」で「出版社」と「電子書店」を繋ぎ、その先にいる作家と読者を繋げる「電子書籍取次」事業を展開しております。業界最多のコンテンツラインナップとともに最新のテクノロジーを駆使した各種ソリューションを出版社や電子書店に提供し、グローバル且つマルチコンテンツ配信プラットフォームを目指しています。
https://mediado.jp
Why not register and get more from Qiita?
  1. We will deliver articles that match you
    By following users and tags, you can catch up information on technical fields that you are interested in as a whole
  2. you can read useful information later efficiently
    By "stocking" the articles you like, you can search right away