AWSアカウント開設直後にやるべき10の初期設定

AWSアカウントを作った直後は、何でもできる万能のrootユーザーが1つあるだけの、いわば「鍵のかかっていない家」です。EC2を立てる前に、まず家に鍵をかける——これが本記事の10項目です。当社が構成レビューで最初に確認するチェックリストそのものなので、既存アカウントの棚卸しにも使えます。自分のアカウントが何点か知りたい方は、先にセキュリティ自己診断ツールでどうぞ。

01rootユーザーにMFAを設定する

最優先です。rootはアカウントの解約すらできる絶対権限で、破られたら全損です。多要素認証（MFA）を必ず設定してください。可能ならスマホアプリより紛失・フィッシングに強いハードウェアセキュリティキーを。設定は5分で終わります。この5分を惜しんだ事故を、業界は数え切れないほど見てきました。

02rootを日常作業に使わない

rootの出番は、アカウント設定の変更や解約など年に数回だけです。日常の構築・運用は次項のIAMユーザーで行い、rootのアクセスキーは作らない（既にあるなら削除する）が鉄則です。「とりあえずrootで作業」が常態化しているアカウントは、それだけで要注意サインです。

03管理者は個人ごとのIAMユーザー／Identity Centerで

「admin」という共有ユーザーを全員で使い回すと、事故のとき「誰の操作か」が説明できません。管理者権限は必ず個人単位で発行します。複数人・複数アカウントになる見込みがあるなら、最初からIAM Identity Center（旧SSO）を使うと、後の統合が楽です。

04全ユーザーにMFAを強制する

rootだけでなく、コンソールにログインできる全ユーザーにMFAを。IAMポリシーで「MFAなしでは主要操作を拒否」する強制も可能です。パスワードはいつか漏れる前提で設計するのが現代のセキュリティです。

05CloudTrailを全リージョンで有効化する

「誰が・いつ・何をしたか」のAPI操作記録です。事故調査も監査対応も、証跡がなければ始まりません。ポイントは全リージョンで有効化すること。使っていないリージョンこそ、不正利用の隠れ場所になります。ログの保存先S3バケットには、改ざん防止のためのアクセス制限も忘れずに。

06アクセスキーの棚卸しルールを決める

プログラム用のアクセスキーは、発行した瞬間から漏えいリスクを抱えます。「どこで使っているか台帳をつける」「使っていないキーは削除」「定期的にローテーション」の3点をルール化してください。そもそもEC2やLambdaにはキーではなくIAMロールを使えば、キー自体を減らせます。GitHubへのキー混入は今でも事故原因の定番です。

07S3のパブリックアクセスブロックをアカウント単位で有効化

S3バケットの公開設定ミスによる情報漏えいは、AWS事故の定番中の定番です。「ブロックパブリックアクセス」をアカウントレベルで有効化しておけば、個々のバケットで設定を誤っても公開されません。公開が必要なバケットができたときだけ、個別に例外を検討します。

08GuardDutyを有効化する

不審なAPI操作、漏えいしたキーの利用、暗号資産マイニングなどを機械学習で検知するマネージドサービスです。有効化はワンクリック、料金はログ量に応じた従量制で、小規模アカウントなら月数ドル程度から。「何かあったら気づける」状態を最も安く買える設定です。

09請求アラート／AWS Budgetsを設定する

不正利用も設定ミスも、多くの場合まず請求額に現れます。「月◯ドルを超えたら通知」のBudgetsを設定しておけば、気づくのが翌月の請求書、という最悪の展開を避けられます。予算の8割で警告、10割で緊急通知の2段構えがおすすめです。

10バックアップの「復元テスト」までやる

最後は設定ではなく習慣の話です。スナップショットを取っているだけでは、いざという時に戻せるかは分かりません。年に1回でいいので、実際に復元して動くことを確認してください。「取ってあるだけのバックアップは、無いのと同じことがある」——これは移行と運用の現場で何度も見てきた真実です。

—まとめ：所要時間は半日、効果は永続

10項目すべてやっても、慣れていれば半日で終わります。そしてこの半日が、アカウントの生涯にわたって事故の確率を桁で下げます。逆に、リソースが増えてから後付けするのは何倍も大変です。既存アカウントの方は、セキュリティ自己診断ツールで現在地を確認するところから始めてください。6点以下だった場合は、正直、急いだほうがいいです。