はじめに

AWS を使う際、管理の基本単位は AWS Account になります。
各リソースは AWS Account 内に配置され、各ユーザーは AWS Account 内の IAM user で作られます。

そのため、AWS Account は、サービスや環境 (Prod, Stage, Dev) などで分離することが求められています。
これにより、各サービスや各環境間が適切に分離され、互いに悪影響を与えないためです。

しかし、このベストプラクティスには一つ、管理の課題がありました。
それは、AWS Accountごとに存在する root ユーザーアカウント (以下、root ユーザー) を、個別に管理する必要があるという点です。

この課題に対するソリューションが 2024 年 11 月 14 日にリリースされたため、紹介します。

root ユーザーとは

root ユーザーは、AWS Account の完全な管理権限を有するユーザーです。
このユーザーは、AWS Account を作成した際に自動的に作成されます。

このユーザーに対する管理や課題などを考えてみたいと思います。

root ユーザーの利用

root ユーザーは以下のような用途に利用されます。

  1. 初期設定 (管理者権限の作成など)
  2. Amazon S3 Bucket policy 不備などでアクセス不可能になった際の回復
  3. Amazon SQS Queue policy 不備などでアクセス不可能になった際の回復

これらは、通常の管理者権限を有するユーザー (AdministratorAccess) で代用することができません。
これらの特殊な操作は root ユーザーのみが可能な操作となっています。

これらの用途で利用する可能性があるため、root ユーザーは適切にメールアドレス、パスワード、MFA を管理することが求められています。

root ユーザーに対する通常利用の禁止

通常用途、たとえば Amazon EC2 の操作や Amazon RDS の操作などに root ユーザーを利用するべきではありません。

root ユーザーは完全な管理権限を有しているため、従業員による悪意ある操作や、攻撃者による遠隔操作などが発生した際に、その被害は AWS Account 全体に及びます。

そのため、通常の用途であれば、『最小権限の原則』に従う権限を有した IAM user を作成し、活用することが求められます。

root ユーザーの課題

root ユーザーは、すべての AWS Account に必ず存在しています。

サービスや環境が多くなると、用途ごとに多数の AWS Account が存在し、その数だけ root ユーザーが存在するということです。

Password の使いまわしは、パスワードリスト型攻撃に対して脆弱です。
そのため、組織の管理者は多数のパスワード、多数の MFA を管理することとなります。

また、root ユーザーのパスワードは永続です。
有効期間はなく、いつでもそのパスワードを利用することができます。
そのため、ブルートフォース攻撃の試行回数増加や、担当者変更時のパスワード更新忘れなどに繋がります。

この課題に対応するため、 ルートアクセスの一元管理 がリリースされました。

ルートアクセスの一元管理

ルートアクセスは、AWS Organizations の機能です。

この機能は root ユーザーの認証情報 (e.g. パスワード、Credentials) を管理することができます。

この機能では、大きく2つの機能が展開されています。

  • ルート認証情報の一元管理
    • root ユーザーの認証情報の管理 (削除等)
  • ルートセッション
    • root ユーザーに対する一時的な認証情報の作成

これにより、root ユーザーの認証情報を削除して、必要があるときにのみ一時的な認証情報を活用する運用が可能となります。

ルート認証情報の一元管理

これは、今まで必ず作成されていた root ユーザーの認証情報を削除したり、root ユーザーの認証情報なしで AWS Account を作成することが可能になる機能です。

root ユーザーの課題にあった、ブルートフォースや、退職後の管理者による不正などから、AWS Account を強力に保護することが可能となります。

これには、大きく 3つの機能が含まれています。

  • 認証情報の削除
    • ルート認証情報の削除をする。
    • ルート認証情報のリカバリの防止をして、将来の不正を抑止する。
  • セキュアバイ・デザイン
    • AWS Account 作成時に認証情報を作成しない。
  • コンプライアンス
    • ルート認証情報を一元的に管理して、ステータスの確認やコンプライアンス状況の確認ができる。

これにより、AWS Organizations 全体に対して root ユーザーを安全に保つことが可能となります。

ルートセッション

ルートセッションは、root 認証情報を削除した際に安全に AWS Account に対して root ユーザーとしてアクセスをするためのサービスです。

root ユーザーの管理を行う集約ユーザーから、一時的な Credentials を利用して他の AWS Account に root ユーザーとしてログインすることが可能となります。

これにより、管理する root ユーザーや MFA が削減されることで、管理の省力化を行うとともに、パスワードや MFA が減少することから人員変更の際の変更作業などが簡略化されます。

この機能は、AWS のベストプラクティスと整合性が取られており、『最小権限の原則』と『一時的アクセス』が実現されます。

使ってみる

ルートアクセス管理の有効化

実際に、ルートアクセスの一元管理を利用してみます。

組織の管理アカウントに入ると、IAM の中に『ルートアクセス管理』という機能が増えています。

ここで、『有効化』を選択すると、有効にする機能や委任されたアカウント管理者の選択が出てきます。

『最小権限の原則』のため、権限をメンバーアカウントに委任して、以降の root ユーザー管理作業はそちらから実施します。

ルートアクセス管理の一元管理

有効にすると、委任されたアカウントからアカウント一覧を確認し、『ルートユーザー認証情報』として、root ユーザーの状況 (存在する場合の警告) を一覧で確認できるようになります。

特権的アクションの実行

アカウントを選択して『特権的なアクションを実行する』を選択するとアクションを選択できるようになります。

今回はメンバーアカウントのバケットポリシーを削除してみます。
テストで利用するバケットには、あらかじめバケットポリシーを適用済みです。

削除を選択することで、root ユーザーとして該当の AWS Account に入ることなく、バケットポリシーを削除可能であることが確認できました。

ルートアクセス管理の効果

この機能により、セキュリティ管理者にとっては各アカウントの root ユーザー利用状況を監査する事が可能となります。

AWS Organizations 運用者は、S3 Bucket policy や SQS Queue policy 不備の連絡に対し、簡易かつ最小権限の原則に従い安全に対応可能となります。

root ユーザーという、すべての AWS Account にあったアタックサーフェスを GUI ベースで安全に管理できることから、有用な機能であることが確認できました。

今後想定される攻撃

最後に、この機能により root ユーザーアクセスが完全に安全になったかというと、そうではないと考えます。

今後、 root ユーザー管理について、現在よりもリスクが高くなると考えられる事項について、考えてみたいと思います。

ここでは、2つのリスクを挙げます。

管理ツールを悪用

ルート認証情報の削除を行うと、ルートセッションアクセスを使用したアクセスが必要となります。

これらの操作は、AWS CLI や AWS SDK に精通していないユーザー、特にセキュリティ管理者などには操作が難しいと考えます。

そのため、それらの操作を簡易的に実行可能となるツールが出てくると考えられます。
そのツールに悪意あるコードを入力し、C&C サーバーに対して root クレデンシャルを漏洩させる攻撃が考えられます。

認証情報を取り扱うツールを導入する際は、十分に検証と、更新管理が必要となります。

ソーシャルエンジニアリング

ルートセッションアクセスは、セキュリティ管理者などのユーザーから管理下にあるすべての AWS Account に対してログインを可能とする機能です。

そのため、セキュリティ管理者に対してソーシャルエンジニアリングや、買収などを仕掛けることで、組織全体に関する完全なアクセス権を奪取する攻撃が想定されます。

メールや、その他の媒体からのフィッシングなどで、不正なツールを実行するなども考えられます。
そのため、ルートセッションアクセスに利用する集約的なユーザーは、通常の業務から分離した環境などで安全に管理する必要があると考えます。

まとめ

ルートアクセスの一元管理は、組織全体の root ユーザーを管理するための強力な機能を提供しています。

これらの機能を活用することで、AWS ベストプラクティスに適合する『最小権限の原則』や『一時的アクセス』を実現することが可能になります。

しかし、これらの機能は完全な安全を提供する機能ではありません。
これらを活用することで新たに発生するリスクも考慮し、組織全体を安全に管理することが、セキュリティ管理者には求められています。