AWSアカウントセットアップガイド 〜アカウント作成から最低限やるべき設定までやってみた〜

あしざわです。

個人検証用AWSアカウントを新しく作成することにしたのですが、個人で1からアカウントを作成することが久しぶりだったので「何をやればいいんだっけ？」と迷いました。

こちらのブログにAWSアカウントで最初に何をすればいいのかがまとまっていてとても助かったのですが、「すぐに！全部やれ！」となるとさすがに大変だなと思ってしまいました。

とはいえAWSアカウントを運用する上でやっておくべき設定なので、重要度の高いものを選び優先度をつけて設定してみます。

本ブログで、それらの設定を実施した記録・手順を残しておきます。

そもそもなぜやるべきことがあるのか？

はじめにAWS初心者向けの前提知識として「そもそもなぜAWSアカウントを作成した後に色々やらないといけないのか？」を説明します。こんなこと知ってるよ！という方は章ごと飛ばしてください）

AWSアカウントはメールアドレスとクレジットカード情報があれば誰でも簡単に作成できます。

しかし、初期設定のAWSアカウントは主にセキュリティ面で不十分です。それを知らずにAWSアカウントを運用（もしくは放置）してしまうとAWS不正利用の原因となり高額なAWS利用料金を請求されてしまう可能性があります。

不正利用からの対策設定はいくつかあり、すべて最低限やるべき設定といえますが、それらは以下の２種類に分類できます。

• 不正利用を起こさないための設定(不正利用予防)
• 不正利用が起きたときに気付くための設定(不正利用通知)

不正利用予防の設定の代表例は、「ルートユーザーへのMFA設定」です。

ルートユーザーとは、AWSアカウントを作成した時、初回ログインに使用されるようなアカウント内のすべてのリソースの完全なアクセス権限を持つデフォルトの認証情報です。つまり超特権ユーザーです。

このユーザーの認証情報を悪意を持った誰かに取られ不正にログインされると、サーバー(EC2)を大量に建ててコインマイニングを実行されたり、インターネット上のどこかのWebサイトに対するDDoS攻撃の拠点として利用されたり、文字通りなんでもできてしまいます。攻撃の結果、数百万円規模の高額なAWS利用費の支払いやAWSアカウントの停止など、金銭的・ビジネス的に大きな代償を支払うことになりかねません。

ルートユーザーはユーザーパスワード認証で設定されるため、MFA(多要素認証)を設定することでユーザーの漏洩のリスクを低減できます。必ず設定するべきです。

ルートユーザーについては、以下記事も参考にしてください。

不正利用通知の設定の代表例は、「GaurdDutyの設定」です。

GuardDutyはAWS上の脅威検知を行うことができるAWSサービスです。検知できる脅威の例は、攻撃者によるIAMへの不正ログイン、EC2上のコインマイニング通信、S3バケットへの不審な通信などです。

十分対策できていると思っていても、万が一攻撃されてしまったときのために気付ける設定として最低限GuardDutyは設定すべきです。本記事では深く説明しませんが、GuardDutyによるアラートが発生した時にすぐ対応できるような体制づくりもやっておくと尚良いです。

GuardDutyの基本については、以下記事も参考にしてください。

個人的にこれらの2つ対策における対応優先順位をつけるなら、不正対策予防 > 不正対策通知となります。

この記事では、不正対策予防の設定を即時で対策すべき設定としてAWSアカウント作成後すぐにやるべき設定と定義しています。対して、不正対策通知の設定はなるべく早く対策すべき設定とAWSアカウント作成後即時ではないが早め（2週間以内くらい）に設定すべき設定と定義してみます。

不正利用からの防衛方法については、以下記事も参考になります。

また、本記事ではAWSアカウントの払い出し・設定をすべて個人で行いますが、リセラーを利用している場合はアカウントの払い出しや基本的なセキュリティ設定がリセラー側で実装されていることがあります。その場合、これらの手順・設定が不要とご理解ください。

前置きが長くなりましたが、ここからは実際の設定手順を紹介します。まずはAWSアカウントを作成するところから始めます。

AWSアカウント新規作成

AWSアカウントの作成の流れ・手順はAWS公式のサイトに詳しく掲載されており、こちらを参考にやっていきます。

ルートユーザーのメールアドレスとAWSアカウント名を入力し、メールアドレスの認証をします。

入力したメールアドレスにno-reply@signup.awsのアドレスからメールが届いていました。メールに記載のVerification codeコードをコピー、Verifyします。

It's you! Your email address has been successfully verified.というメッセージが表示されたので確認できたようです。

ルートユーザーのパスワードを入力して、次に進みます。

AWSのユースケースは個人利用なのでPersonalを選択し、その他個人情報を入力して、次に進みます。

AWS利用料の請求先クレジットカード情報を入力し、次に進みます。

SMSもしくは電話での本人認証を行うための情報を入力します。私はSMSにしました。

SMSに届いたコードを入力し、次に進みます。

AWSサポートのプランを選択します。今のところはBasicプランにしておきます。サポートプランは後からでも変更できます。

サインアップが完了しました！

以下の内容のメールが届いていました。これでAWSアカウントが使えるはず！

Welcome to Amazon Web Services. Thank you for creating an Amazon Web Services (AWS) account. For the next 12 months, you'll have free access to all AWS services within the limits of the Free Tier.

If you are unable to access AWS Services, please note that some services may take up to 24 hours to fully activate. If you’re still unable to access AWS Services after that time, please visit AWS Support.

Welcome to the AWS community!

The Amazon Web Services Team

作成したAWSアカウントへの初回ログインをやっていきます。

ルートユーザーを選択し、ルートユーザーのメールアドレスを入力、次に進みます。

ルートユーザーのパスワードを入力し、サインインします。

AWSマネジメントコンソールが表示され、初回ログインできました

即時で対策すべき設定

ここからはアカウントを作成した直後、すぐにやっておきたい設定を『即時で対策すべき設定』とみなしてやっていきます。

この設定は前述した通り、不正利用を起こさないための設定です。アカウント作成後、数日以内に必ず設定しましょう。

実施する設定内容はこちらです。

• ルートユーザーのMFA 認証設定
• IAM パスワードポリシーの設定
• IAMユーザーによる請求情報へのアクセス有効化
• 管理者用IAM ユーザーの作成
• 管理者用IAMユーザーのMFA 認証設定
• Cost Explorerの有効化

初回ログインに利用したルートユーザーでAWSアカウントにログインした状態ではじめてください。

ルートユーザーのMFA 認証設定

ここでは、制限不可能なフルアクセス権限を持つルートユーザーのログイン時にMFA(多要素認証)を設定します。

AWSマネジメントコンソールの右上端のAWSアカウント名のトグルを選択し、セキュリティ認証情報をクリックします。

IAMのセキュリティ認証情報の画面に遷移するので、MFA を割り当てるをクリックします

デバイス名とMFAデバイスの種類を選択します。私は個人で1passwordを利用しているのでAuthenticator appを選択しています。

QRコードを表示をクリックして、MFA設定用のQAコードを表示させ認証アプリ側でスキャンします。スキャン後認証アプリ上で表示される認証コードを入力し、MFAを登録します。

登録できました。

IAMユーザーによる請求情報へのアクセス有効化

デフォルトではルートユーザーを使わないと請求情報にアクセスできないため、後ほど作成する普段使い用に認証情報（IAMユーザー）から請求情報にアクセスできるようにするための設定を、ここで行います。

AWSマネジメントコンソールの右上端のAWSアカウント名のトグルを選択し、アカウントをクリックします。

IAM ユーザーおよびロールによる請求情報へのアクセス欄の編集を選択、そのままIAM アクセスをアクティブ化を有効化し、更新してください。

IAM ユーザー/ロールによる請求情報へのアクセスが有効化済みとなっていれば設定完了です。

AWS IAM パスワードポリシーの設定

後ほど作成するルートユーザーの代わりに使用する管理者用IAMユーザーのパスワードポリシーを強化します。パスワードポリシーを複雑にすることでブルートフォース(総当たり)攻撃によるアカウント漏洩が予防できます。

IAM > アカウント設定から、パスワードポリシーを変更します。

IAMのパスワードポリシーの推奨設定の強力な設定例として、AWS Security Hubのセキュリティ標準のうちの1つであるこちらを参考にしました。

• [IAM.7] IAM ユーザーのパスワードポリシーには強力な設定が必要です

具体的には、こちらを最低限設定すべきという内容です。

• パスワードには少なくとも 1 つの大文字が必要です: 有効化
• パスワードには少なくとも 1 つの小文字が必要です: 有効化
• パスワードには少なくとも 1 つの記号が必要です: 有効化
• パスワードには少なくとも 1 つの数字が必要です: 有効化
• パスワードに含まれる文字の最小数: 8

上記に加え、ユーザーにパスワードの変更を許可を追加しています。

変更を保存しようとすると、確認画面が表示されるのでそのまま設定します。

パスワードポリシーが変更できました。

管理者用IAM ユーザーの作成

リスクを回避するためにルートユーザーは可能な限り使わない方がよいです。代わりに管理者(Administrator)権限を持ったIAMユーザーを作成し、普段はその認証情報を使用してAWSアカウントを運用すべきです。

まずはIAM > ユーザーグループからグループを作成します。

任意のユーザーグループ名を設定し、許可ポリシーはAdministratorAccessを選択します。

ユーザーグループが作成できました。

続いて、IAM > ユーザーからユーザーを作成します。

任意のユーザー名を入力、ルートユーザー代替のアカウントになるためAWS マネジメントコンソールへのユーザーアクセスを提供するを選択し、IAMユーザーの作成を選択します。

パスワードは初回ログイン後に再設定するオプションにしています。

今回のユーザーは先ほど作成したグループを関連付けすることで権限を設定します。ユーザー個別にIAM権限を設定することも可能ですが、IAMユーザーの権限設定は個別ではなくグループごとに設定することがベストプラクティスです。

ユーザーをグループに追加をクリックし、追加対象のユーザーグループを選択します。

設定値を確認し、ユーザーを作成します。

IAMユーザーの作成が完了すると、ユーザー名/パスワード等のコンソールサインインの情報が表示されます。初期パスワードは画面遷移すると見られなくなるため、このページで忘れずに.csvファイル形式でダウンロードしておきましょう。

ルートアカウントからログアウトし、作成した管理者用IAMユーザーでAWSマネジメントコンソールにログインしてください。ダウンロードした.csvファイル内にあるコンソールサインインURL(例: `https://123456789012.signin.aws.amazon.com/console`)からログインポータルにアクセスする方法が一番楽です。

ユーザー/パスワード認証に成功すると、設定した通りパスワード変更が求められるため、任意のパスワードに変更します。

パスワード変更後、再度マネジメントコンソールへログインできるところまで確認できれば完了です。

今後はルートユーザーにログインする必要はないため、以降は管理者用IAMユーザーでログインして実施してください。

管理者用IAMユーザー MFA認証の設定

管理者用IAMユーザーについても、MFA認証の設定を必ずやっておきましょう。

IAMユーザーのMFA設定手順は、IAM > ユーザー > [IAMユーザー名]のセキュリティ認証情報タブから設定できますが、具体的な設定手順の流れはルートユーザー MFA 認証の設定と同じなので割愛します。

MFA設定が完了しました。

Cost Explorerの有効化

Cost Explorerを有効化しないと、AWSアカウントの利用日に関する情報にアクセスできないため、早めに有効化しておきましょう。

Billing and Cost Management(請求とコスト管理)のコンソールへ移動し、コスト分析 > Cost Explorerにアクセスすると、以下のようなアナウンス文が表示されました。

これは初めての訪問であるため、コストと使用状況のデータを準備するには時間がかかります。24 時間後にもう一度確認してください。

案内に従って24時間後に再アクセスします。請求とコスト管理のホーム画面が表示されていれば有効化完了です。

即時で対策すべき設定は、以上です。

なるべく早く対策すべき設定

ここからはAWSアカウント作成後即時ではないが早め（2週間以内くらい）に設定すべき設定を『なるべく早く対策すべき設定』とみなしてやっていきます。

この設定は前述した通り、不正利用が起きたときに気付くための設定です。アカウント作成後2週間以内を目処に必ず設定しましょう。

実施する設定内容はこちらです。

• Budgetの設定
• GuardDutyの有効化
• GuardDutyの通知設定
• セキュリティログ用S3バケットの作成
• CloudTrail証跡の作成
• Config有効化(レコーダーの作成)

タイトル通りの不正利用が起きた時に気づくための設定は前半の3点目まで(Budget、GuardDuty)ですが、後から不正利用されてしまった/されたことに後から気づいた時の調査手段としてCloudTrail、Configが使えるように

Budgetの設定

AWSアカウントのBudget(予算)を設定することでAWSアカウントの利用費が指定した値の利用費に近づいたり、超過したときEメールアドレスにその旨を通知させることができます。意図せず利用費が高額になることを未然に防げます。

Billing and Cost Management(請求とコスト管理)のコンソールへ移動し、予算と計画 > 予算(Budget)にアクセス、予算の作成を選択します。

テンプレートを使用、月次コスト予算を選択し、予算額および通知先のEメールアドレスを入力します。

私の場合は、予算は$30、通知先のメールは業務用および個人のメールアドレスの2つとしました。

予算を設定しました。追加でゼロ支出予算の設定もやっておきました。そちらはすでに超過のステータスになっていますね。

GuardDutyの有効化

冒頭で説明したAWS脅威検知サービスであるGuardDutyを設定します。

GuardDutyのコンソールにアクセスし、今すぐ始めるをクリック。

GuardDutyを有効にするを選択します。

要約のページが表示されたら設定完了です。

今回は普段使いしている東京リージョンのみでサービスを有効化していますが、GuardDutyはリージョン単位でリソースの脅威検知を行うサービスです。

可能であれば全リージョンで有効化すべきなので、操作しているリージョンを変更し他のリージョンのGuardDutyも有効化しておきましょう。

私は取り急ぎバージニア北部リージョンのGuardDutyを追加で有効化させました。

以下記事を参考に一括して全リージョンで有効化させてしまうと楽です（後述する通知設定も含まれています）

GuardDutyの通知設定

GuardDutyのアラートが出た場合に通知させる設定をやっていきます。

以下の記事を参考にCloudFormationを利用して設定します。

まずはCloudFormationテンプレートファイルを作成します。ローカルでファイルを準備しても良いですが、できたらAWSコンソール上で操作を完結させたいので今回はApplication Composerという機能を利用します。

CloudFormationのコンソールへ移動し、Application Composerタブにアクセスします。

テンプレートを選択し、エディタ内に以下のYAMLテンプレートを入力します。

※参考記事内のテンプレートを、GuardDutyの有効化、Severityのフィルタを除くようにカスタマイズしたものです。

AWSTemplateFormatVersion: "2010-09-09"

Description: GuardDuty Stack

Parameters:
# ------------------------------------------------------------#
# Parameters
# ------------------------------------------------------------# 
  MailAddress:
    Type: String

Resources:
# ------------------------------------------------------------#
# SNS
# ------------------------------------------------------------# 
  SnsTopic:
    Type: AWS::SNS::Topic
    Properties: 
      Subscription:
        - Endpoint: !Ref MailAddress
          Protocol: email
      TopicName: sns-guardduty

  SnsTopicPolicy:
    Type: AWS::SNS::TopicPolicy
    Properties: 
      PolicyDocument:
        Version: '2012-10-17'
        Id: __default_policy_ID
        Statement:
          - Sid: __default_statement_ID
            Effect: Allow
            Principal: 
              AWS: '*'
            Action: 
              - 'SNS:GetTopicAttributes'
              - 'SNS:SetTopicAttributes'
              - 'SNS:AddPermission'
              - 'SNS:RemovePermission'
              - 'SNS:DeleteTopic'
              - 'SNS:Subscribe'
              - 'SNS:ListSubscriptionsByTopic'
              - 'SNS:Publish'
            Resource: !Ref SnsTopic
            Condition: 
              StringEquals: 
                'AWS:SourceOwner': !Sub ${AWS::AccountId}
          - Sid: AWSEvents_guardduty
            Effect: Allow
            Principal: 
              Service: events.amazonaws.com
            Action: 'sns:Publish'
            Resource: !Ref SnsTopic
      Topics:
        - !Ref SnsTopic

# ------------------------------------------------------------#
# EventBridge
# ------------------------------------------------------------# 
  EventBridge:
    Type: AWS::Events::Rule
    Properties: 
      EventPattern: 
        source: 
          - aws.guardduty
        detail-type: 
          - 'GuardDuty Finding'
      Name: guardduty-event
      State: ENABLED
      Targets: 
        - Arn: !Ref SnsTopic
          Id: guardduty-event
          InputTransformer: 
            InputPathsMap: 
              'severity': '$.detail.severity'
              'Account_ID': '$.detail.accountId'
              'Finding_ID': '$.detail.id'
              'Finding_Type': '$.detail.type'
              'region': '$.region'
              'time': '$.time'
              'Finding_description': '$.detail.description'
            InputTemplate: |
              "AWSアカウント：<Account_ID> で重要度：<severity> のイベントが検出されました。"
              "検出時間：<time>"
              "検出タイプ：<Finding_Type>"
              "リージョン：<region>"
              "検出タイプ説明：<Finding_description>."
              "マネジメントコンソールから詳細をご確認ください。https://console.aws.amazon.com/guardduty/home?region=<region>#/findings?search=id=<Finding_ID>"

入力後、一旦キャンパスモードに変更するとテンプレートを作成ボタンがアクティブになるので、クリックします。

確認してCloudFormationに進むを選択。このテンプレートはApplication Composer用のS3バケットに保存されるようです。

CloudFormationのコンソールに自動遷移するのでそのまま進めていきます。

任意のスタック名、通知先のメールアドレスを入力して進めます。

そのまま進めていくとCloudFormationテンプレートが実行されます。

スタックの状態がCREATE_COMPLETEになったらOKです。

上記がどこかうまくいかなかったら、ローカル環境で前述の内容のyamlファイルを作成し、別途CloudFomationテンプレートとして実行してみてください。

通知先のメールアドレスにAWS Notification - Subscription Confirmationというタイトルのメールが届いているため、メール本文のConfirm subscriptionをクリックしてください。

Subscription confirmed!と表示されたら通知設定は完了です。

本当に正しく設定ができているか確認したい場合は、以下記事を参考に通知テストを実施してください。

セキュリティログ保存用S3バケットの作成

後述する2つのセキュリティサービスのログを保存するためのS3バケットを作成します。

S3のコンソールへアクセスし、バケットを作成をクリックします。

S3バケット名は全世界で一意のものを設定します。一意のバケット名をつける個人的なテクニックとして、バケット名のどこかにAWSアカウントID(123456789012など12桁の数列)を入れることをオススメしたいです。

他はデフォルト設定で問題ないです。

バケット作成後、作成したS3バケットの設定を変更していきます。

アクセス許可タブのバケットポリシー欄の編集をクリックします。

後述する内容のバケットポリシーをポリシー欄に入力します。ここでは、のちの手順で有効化するConfigレコーダー有効化のための権限設定を実施しています。

アカウントID(123456789012)、S3バケット名(sample-logs-123456789012)はサンプルの情報を入力しているため、設定する際は自身の環境の合うようにポリシーを変更してください。なお、このポリシーは公式ドキュメントを参考に作成しています。

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AWSConfigBucketPermissionsCheck",
      "Effect": "Allow",
      "Principal": {
        "Service": "config.amazonaws.com"
      },
      "Action": "s3:GetBucketAcl",
      "Resource": "arn:aws:s3:::sample-logs-123456789012",
      "Condition": {
        "StringEquals": {
          "AWS:SourceAccount": "123456789012"
        }
      }
    },
    {
      "Sid": "AWSConfigBucketExistenceCheck",
      "Effect": "Allow",
      "Principal": {
        "Service": "config.amazonaws.com"
      },
      "Action": "s3:ListBucket",
      "Resource": "arn:aws:s3:::sample-logs-123456789012",
      "Condition": {
        "StringEquals": {
          "AWS:SourceAccount": "123456789012"
        }
      }
    },
    {
      "Sid": "AWSConfigBucketDelivery",
      "Effect": "Allow",
      "Principal": {
        "Service": "config.amazonaws.com"
      },
      "Action": "s3:PutObject",
      "Resource": "arn:aws:s3:::sample-logs-123456789012/AWSLogs/123456789012/Config/*",
      "Condition": {
        "StringEquals": {
          "s3:x-amz-acl": "bucket-owner-full-control",
          "AWS:SourceAccount": "123456789012"
        }
      }
    }
  ]
}

バケットポリシーが正常に保存できればOKです。

必須の設定は以上ですが、追加の設定としてS3のライフサイクルルールを設定しておくとコスト削減効果が期待できます(今回は割愛します)

以下を参考にS3バケット作成後ライフサイクルルールでオブジェクトの有効期限を設定し、保存したログが一定期間で自動削除されるよう設定してください。余裕があれば設定をオススメします。

• オブジェクトの有効期限 - Amazon Simple Storage Service

CloudTrail証跡の作成

AWSアカウントで実行されたAPIの履歴を保存するCloudTrailのログを長期保存（90日以上）するために証跡を作成します。

続けてCloudTrailのコンソールにアクセスし、CloudTrail > 証跡から証跡の作成をクリックします、

証跡名を指定し、既存のS3バケットを使用するから先ほど作成したS3バケットを選択します。コストを抑えるためにログファイルの SSE-KMS 暗号化は無効化としました。

ログイベント設定はデフォルト設定のまま、進めます。

証跡が作成できました。

この時、証跡の保存先S3バケットポリシーを確認すると以下のようなバケットポリシーが追加で設定されていることがわかります。

{
  "Sid": "AWSCloudTrailAclCheck[ランダム文字列]",
  "Effect": "Allow",
  "Principal": {
      "Service": "cloudtrail.amazonaws.com"
  },
  "Action": "s3:GetBucketAcl",
  "Resource": "arn:aws:s3:::sample-logs-123456789012",
  "Condition": {
      "StringEquals": {
          "AWS:SourceArn": "arn:aws:cloudtrail:ap-northeast-1:123456789012:trail/manaegment-event"
      }
  }
},
{
  "Sid": "AWSCloudTrailWrite[ランダム文字列]",
  "Effect": "Allow",
  "Principal": {
      "Service": "cloudtrail.amazonaws.com"
  },
  "Action": "s3:PutObject",
  "Resource": "arn:aws:s3:::sample-logs-123456789012/AWSLogs/123456789012/*",
  "Condition": {
      "StringEquals": {
          "s3:x-amz-acl": "bucket-owner-full-control",
          "AWS:SourceArn": "arn:aws:cloudtrail:ap-northeast-1:123456789012:trail/manaegment-event"
      }
  }
}

Config有効化(レコーダーの作成)

AWS上のリソースの変更履歴を記録するためのConfigレコーダーを有効化させます。

Configのコンソールの今すぐ始めるからセットアップを始めます。

Configも基本的にデフォルト設定、ログの保存先S3バケットだけ先ほど作成したものに変更しています。

コスト削減のため、グローバルに記録されたすべての IAM リソースタイプは記録から除外しています。IAM記録頻度を日次にすることで更なるコスト削減も可能ですが、一旦は継続的な記録としています。

そのまま、Configルールは設定せず、レコーダーのみを作成します。

エラーにならず、AWS Configのダッシュボードの遷移すれば正常に設定が完了しています。

なるべく早く対策すべき設定は、以上です。

まとめ

本記事ではAWSアカウントの作成を行い、追加で最低限やっておくべき設定を即時で対策すべき設定となるべく早く対策すべき設定の2つに分けて対応しました。

注意点として、あくまでこの記事の内容は「最低限の設定」であることをご認識いただきたいです。

記事の設定はAWS上のみのセキュリティ設定であり、本番ワークロードを安全に動作させるためにセキュリティ観点でやるべきことはまだまだたくさんあります。

例えば、ネットワーク、OS/アプリケーション、コンテナ、サーバレスです。詳しくは以下記事を参考にしてください。

今回は単一のAWSアカウント いわばシングルアカウント想定でセキュリティ設定を行いました。個人的にOrganizationsを利用したマルチアカウント環境を運用したいので、続編で「セキュアなマルチアカウント環境の実装編」を執筆してみます。

以上です。