Finatextの @s_tajima です。
この記事は、Finatextグループ Advent Calendar 2024の25日目の記事です。
今回は、年末なのでAWSのルートユーザーの認証情報を大掃除して、その不正利用のリスクと運用の手間を削減した話です。
具体的には、AWSが最近リリースした Centrally manage root access in AWS Identity and Access Management (IAM) の機能を使いました。
自身の所属する組織において、AWSアカウントの管理を担当されている方に参考にしてもらえると嬉しいなと思っています。
Centrally manage root access とは
Centrally manage root access のリリースによって、主に以下の2つのことが実現できるようになりました。
- ルートユーザーの認証情報の管理: AWS Organizations における、メンバーアカウントのルートユーザーの認証情報を削除できるようになった
- メンバーアカウントでの特権アクションの実行: 今までメンバーアカウントのルートユーザーの認証情報が必要だった作業の一部を、AWS Organizations の管理アカウントの権限で実行できるようになった
この機能は、多くのAWSアカウントを管理する組織にとって非常に嬉しいものだと考えています。
Finatextグループも、AWS Organizations 内に200を超えるAWSアカウントを保有していて、非常に大きい恩恵を受けました。
Centrally manage root access が必要とされていた背景
そんな待望の Centrally manage root access のリリースですが、これが必要とされていた背景について簡単に触れておきます。
ルートユーザーとは
AWSにおけるルートユーザーとは、そのAWSアカウントにおけるすべての操作を行うことができる非常に強い権限です。
AWSアカウント管理における基礎中の基礎として、「本当に必要な時以外は使うべきではない」ものであると知られています。
AWSのドキュメントにおいても以下のような記述があります。
We strongly recommend you don’t access the AWS account root user unless you have a task that requires root user credentials.
https://docs.aws.amazon.com/IAM/latest/UserGuide/root-user-best-practices.html
このような厳密な管理の求められるルートユーザーの認証情報(パスワード等)を、どのように組織的に安全に管理するかは、1つの大きな悩みポイントでした。
また、ルートユーザーは、当然MFAによる保護も重要です。
AWSは、ルートユーザーの保護の強化のため、2024年にルートユーザーのMFAを必須にするというアナウンスもしていました。
新規AWSアカウントの作成時の手間
現在では、新しいAWSアカウントの開設は、AWS Organizations を使うことで簡単に実施できるようになっています。
AWS Organizations を使ったスクリプトを作るなど手軽にAWSアカウントを開設できるように工夫している組織もあると思います。
一方で、前述の通りMFAの設定が必要で、これは自動化が難しく、手作業で行われていることが多かったと思います。
特に、AWSアカウントを頻繁に開設する組織にとっては、チリツモで大きな手間となっていました。
ルートユーザーでの操作が必須となる作業
前述の "本当に必要な時" というのが具体的にどんなときかは、AWSのドキュメントにまとめられています。
様々ありますが、いくつか重要なものを抜粋すると、
- AWSアカウントのアカウント名・メールアドレスを変更するとき
- AWSアカウントをクローズするとき
- 誤って設定してしまいアクセスできなくなったS3バケットのバケットポリシーを削除・編集するとき
- 誤って設定してしまいアクセスできなくなったSQSのポリシーを削除・編集するとき
といった状況が該当します。
注意点としては、これらすべての作業がルートユーザーの認証情報なしで実行できるようになったわけではないという点があります。
実際に Centrally manage root access を使ってみた
現在、Finatextグループは200を超えるAWSアカウントを管理していて、ルートユーザーの管理の手間を感じていたため、早速この機能を利用することにしました。
その手順を簡単に記載しておきます。
Centralized root access の有効化
まずは、AWS OrganizationのマスターアカウントにてCentralized root access の有効化をする必要があります。
最初の手順としては、IAM の Root access magement のページから「有効化」をクリックします。
次の画面で、「ルートユーザーの認証情報の管理」「メンバーアカウントでの特権アクションの実行」のそれぞれを利用できるようにするかどうかの選択をします。
この機能をマスターアカウントから他のメンバーアカウントに委譲する場合は、そのアカウントIDを入力します。
その後、「有効化」をクリックします。
これで、有効化作業は完了です。
詳細な手順はこちらに記載されています。
ルートユーザーの認証情報の管理
前述の手順で Centralized root access を有効化すると、Root access management からメンバーアカウントの認証情報を操作できるようになります。
通常は、まずルートユーザーの認証情報を削除することになります。
以下の画面から、アカウントを選択し、「Take priviledged action」を選択します。
選択したメンバーアカウントの認証情報が存在している場合は、「Delete root user credentials」が選択できます。
実行前に、ルートユーザーの認証情報が最後に使われたのがいつかも表示されるので、削除による影響も確認することができます。
一方で、このマネジメントコンソールを使う方法だと、メンバーアカウントが大量にある場合には作業が大変なので、スクリプトなどで自動化することもおすすめします。
参考となるスクリプトも公開されています。
このルートユーザーの認証情報を削除した状態で、メンバーアカウントに対してパスワードリセットをしようとしても、このような画面になり拒否されることも検証しました。
もし、AWSアカウントの譲渡などでルートユーザーの認証情報が必要になった場合には、「Take priviledged action」から「Allow password recovery」を選択すると、パスワードリセットができるようになります。
メンバーアカウントでの特権アクションの実行
メンバーアカウントでの特権アクションの実行も、アカウントの選択は先ほどと同じ画面から行います。
例えば「誤って設定してしまいアクセスできなくなったS3バケットのバケットポリシーを削除・編集するとき」は、ここで「Delete S3 bucket policy」を選択し、あわせて対象のバケットも選択します。
尚、バケットポリシーを削除するタイミングではなく、その前の対象バケットを選ぶところですでにメンバーアカウント権限での操作が行われています。
ルートユーザーの認証情報削除の際のTips
ルートユーザーの認証情報を削除するにあたって、注意すべきポイントがあったのでまとめておきます。
ECSのAccount settingsについて
ECSには、サービス固有のAccount Settingsという概念があります。
この設定は、アカウントレベルまたは特定のIAMユーザーまたはIAMロールで区別して管理されますが、マネジメントコンソールからだと、以下のようにIAMユーザーまたはIAMロールレベルの設定変更しかできません。
アカウントレベルの設定を変更するには、ルートユーザーの認証情報が必要なように思えるのですが、
実際は put-account-setting-default を使うことで、ルートユーザー以外でも権限のあるIAMユーザーやIAMロールでもアカウントレベルの設定を変更できるようです。
まとめ
以上、Centrally manage root access を使ってルートユーザーの認証情報を大掃除したというお話でした。
アドベントカレンダー最終日なのにクリスマス感よりも年の瀬感を強めに出してしてしまったことは少しだけ反省しています。
Discussion