AWS Organizations を使用するお客様のためのルートアクセスの一元管理

ルートユーザー認証情報の大規模な管理
長い間、Amazon Web Services (AWS) アカウントは、アカウントに対する無制限のアクセスを持つ高度な特権が付与されたルートユーザー認証情報を使用してプロビジョニングされていました。このルートアクセスは強力である一方で、重大なセキュリティリスクをもたらすものでもありました。各 AWS アカウントのルートユーザーは、多要素認証 (MFA) などの保護レイヤーを追加することによって保護する必要がありました。セキュリティチームは、これらのルート認証情報を手動で管理および保護する必要がありました。このプロセスでは、認証情報を定期的にローテーションし、安全に保管して、認証情報がセキュリティポリシーに準拠していることを確認する必要がありました。

お客様が AWS 環境を拡張するにつれて、この手動アプローチは煩雑になり、エラーが発生しやすくなりました。例えば、数百または数千のメンバーアカウントを運用している大企業は、すべてのアカウントで一貫性をもってルートアクセスを保護するのに苦労していました。手動での介入は運用上のオーバーヘッドを増やすだけでなく、アカウントのプロビジョニングに遅れを生じさせ、完全なオートメーションを妨げ、セキュリティリスクを増大させます。ルートアクセスは、適切に保護されていない場合、アカウントの乗っ取りや機密リソースへの不正アクセスにつながる可能性があります。

さらに、Amazon Simple Storage Service (Amazon S3) バケットポリシーまたは Amazon Simple Queue Service (Amazon SQS) リソースポリシーのロック解除などの特定のルートアクションが必要な場合、セキュリティチームはルート認証情報を取得して使用する必要があり、これはアタックサーフェスを拡大させます。厳密なモニタリングと強力なセキュリティポリシーがあっても、ルート認証情報を長期間にわたって維持すると、管理上のミス、コンプライアンスリスク、および人的エラーが発生する可能性が生じます。

セキュリティチームは、より自動化されたスケーラブルなソリューションを求め始めました。ルート認証情報の管理を一元化するだけでなく、そもそも長期的な認証情報を必要とせずにルートアクセスをプログラムで管理する方法を必要としていました。

ルートアクセスを一元管理する
ルートアクセスを一元管理する新しい機能により、複数のアカウントにわたるルート認証情報の管理という長年の課題に対処できます。この新しい機能では、ルート認証情報の一元管理とルートセッションという 2 つの重要な機能が導入されています。これらを組み合わせることで、セキュリティチームは AWS Organizations のメンバーアカウント全体でルートアクセスを管理するための安全かつスケーラブルでコンプライアンスに準拠した方法を利用できるようになります。

まず、ルート認証情報の一元管理について説明しましょう。この機能により、AWS Organizations のすべてのアカウントで特権ルート認証情報を一元管理および保護できるようになりました。ルート認証情報管理により、次が可能になります。

長期ルート認証情報を削除する – セキュリティチームは、メンバーアカウントからルートユーザー認証情報をプログラムで削除できるようになりました。これにより、長期の特権認証情報が悪用される脆弱性を排除できます。
認証情報をリカバリできないようにする – 認証情報を削除するだけでなく、リカバリも防止し、将来における意図しないまたは不正なルートアクセスから保護します。
セキュアバイデフォルトアカウントをプロビジョニングする – 最初からルート認証情報なしでメンバーアカウントを作成できるようになったため、アカウントのプロビジョニング後に MFA などの追加のセキュリティ対策を適用する必要がなくなりました。アカウントはセキュアバイデフォルトであるため、長期的なルートアクセスに関連するセキュリティリスクが大幅に軽減され、プロビジョニングプロセス全体が簡素化されます。
コンプライアンス状態の維持をサポートする – ルート認証情報の管理により、セキュリティチームは、すべてのメンバーアカウントのルート認証情報のステータスを一元的に検出およびモニタリングすることでコンプライアンスを実証できます。この自動化された可視性により、長期的なルート認証情報が存在しなくなるため、セキュリティポリシーと規制要件を満たしやすくなります。

しかし、アカウントで選択したルートアクションを実行できることをどのように確認すればよいでしょうか。ここで、11 月 15 日にリリースした 2 番目の機能、ルートセッションをご紹介します。これは、長期的なルートアクセスを維持する安全な代替手段を提供します。セキュリティチームは、特権アクションが必要なときにいつでも手動でルート認証情報にアクセスする代わりに、メンバーアカウントに対する、タスクの範囲に限定された短期ルートアクセスを取得できるようになりました。この機能により、S3 バケットポリシーや SQS キューポリシーのロック解除などのアクションを、長期ルート認証情報を必要とせずに安全に実行できるようになります。

ルートセッションの主な利点には次が含まれます。

タスクの範囲に限定されたルートアクセス – AWS は、最小特権のベストプラクティスに準拠して、特定のアクションのための短期ルートアクセスを有効にします。これにより、実行できるアクションの範囲が制限されるとともに、アクセス期間が最小限に抑えられ、潜在的なリスクが軽減されます。
一元管理 – 各メンバーアカウントに個別にログインすることなく、中心的なアカウントから特権ルートアクションを実行できるようになりました。これにより、プロセスが合理化されるとともに、セキュリティチームの運用上の負担が軽減され、より高度なタスクに注力できるようになります。
AWS のベストプラクティスとの整合 – 短期認証情報を使用することで、組織は AWS セキュリティのベストプラクティスと整合できます。このベストプラクティスでは、最小特権の原則と、可能な場合は短期の一時アクセスの使用が重視されています。

この新しい機能は、フルルートアクセスを付与しません。以下の 5 つの特定のアクションのいずれかを実行するための一時的な認証情報を提供します。最初の 3 つのアクションは、ルートアカウントの中央管理で可能です。最後の 2 つは、ルートセッションを有効にすると可能になります。

ルートユーザー認証情報の監査 – ルートユーザー情報を確認するための読み取り専用アクセス
アカウントリカバリの再有効化 – ルート認証情報なしでのアカウントリカバリの再アクティブ化
ルートユーザー認証情報の削除 – コンソールパスワード、アクセスキー、署名証明書、および MFA デバイスの削除
S3 バケットポリシーのロック解除 – すべてのプリンシパルを拒否する S3 バケットポリシーの編集または削除
SQS キューポリシーのロック解除 – すべてのプリンシパルを拒否する Amazon SQS リソースポリシーの編集または削除

メンバーアカウントでルート認証情報を取得する方法
このデモでは、管理アカウントを準備し、ルート認証情報なしでメンバーアカウントを作成して、そのメンバーアカウントで 5 つの承認済み API コールのいずれかを実行するために一時的なルート認証情報を取得する方法を説明します。組織は既に作成されているものとします。

まず、メンバーアカウントを作成します。

aws organizations create-account    \
     --email stormacq+rootaccountdemo@amazon.com \
     --account-name 'Root Accounts Demo account'
{
    "CreateAccountStatus": {
        "Id": "car-695abd4ee1ca4b85a34e5dcdcd1b944f",
        "AccountName": "Root Accounts Demo account",
        "State": "IN_PROGRESS",
        "RequestedTimestamp": "2024-09-04T20:04:09.960000+00:00"
    }
}

その後、管理アカウントで 2 つの新しい機能を有効にします。心配しないでください。これらのコマンドは、新しい機能の使用を有効にする以外に、アカウントの動作を変更することはありません。

➜  aws organizations enable-aws-service-access \
        --service-principal iam.amazonaws.com

➜  aws iam enable-organizations-root-credentials-management
{
    "OrganizationId": "o-rlrup7z3ao",
    "EnabledFeatures": [
        "RootCredentialsManagement"
    ]
}

➜  aws iam enable-organizations-root-sessions
{
    "OrganizationId": "o-rlrup7z3ao",
    "EnabledFeatures": [
        "RootSessions",
        "RootCredentialsManagement"
    ]
}

あるいは、管理アカウントのコンソールを使用することもできます。[アクセス管理] で、[アカウントの設定] を選択します。

これで、一時的なルート認証情報を取得するためのリクエストを実行する準備ができました。認証情報の範囲を特定のアクションに絞り込むには、5 つのマネージド IAM ポリシーのうち、1 つを渡す必要があります。

➜  aws sts assume-root \
       --target-principal <my member account id> \
       --task-policy-arn arn=arn:aws:iam::aws:policy/root-task/S3UnlockBucketPolicy 

{
    "Credentials": {
        "AccessKeyId": "AS....XIG",
        "SecretAccessKey": "ao...QxG",
        "SessionToken": "IQ...SS",
        "Expiration": "2024-09-23T17:44:50+00:00"
    }
}

アクセスキー ID、シークレットアクセスキー、セッショントークンを取得したら、いつもどおり AWS コマンドラインインターフェイス (AWS CLI) または AWS SDK で使用します。

例えば、これらの 3 つの値を環境変数として渡すことができます。

$ export AWS_ACCESS_KEY_ID=ASIA356SJWJITG32xxx
$ export AWS_SECRET_ACCESS_KEY=JFZzOAWWLocoq2of5Exxx
$ export AWS_SESSION_TOKEN=IQoJb3JpZ2luX2VjEMb//////////wEaCXVxxxx

一時的な認証情報を受け取ったので、メンバーアカウントでルートとして制限された API コールを実行できます。まず、ルート認証情報があることを検証します。[Arn] フィールドでは、ルートアカウントを使用していることを確認できます。


# get Caller Identity を呼び出し、メンバーアカウントで自分がルートであることを確認します
$ aws sts get-caller-identity
{
   "UserId": "012345678901",
   "Account": "012345678901",
   "Arn": "arn:aws:iam::012345678901:root"
}

その後、S3 の delete-bucket-policy を使用して、バケットに適用されている誤ったポリシーを削除します。無効なポリシーにより、あらゆるユーザーのすべてのバケットアクセスが削除されました。このようなポリシーを削除するには、ルート認証情報が必要です。

aws s3api delete-bucket-policy --bucket my_bucket_with_incorrect_policy

出力がないことは、オペレーションが成功したことを意味します。これで、このバケットに正しいアクセスポリシーを適用できます。

認証情報は 15 分間のみ有効です。認証情報を JSON として取得して、正しい環境変数をエクスポートし、ルートとして実行するコマンドを発行するプロセスを自動化する短いシェルスクリプトを記述しました。

利用可能なリージョン
ルートアクセスの一元管理は、ルートアカウントがない AWS GovCloud (米国) および AWS 中国リージョンを除くすべての AWS リージョンで追加料金なしでご利用いただけます。ルートセッションはどこでもご利用いただけます。

IAM コンソール、AWS CLI、または AWS SDK を通じて使用を開始できます。詳細については、ドキュメントの「AWS アカウントのルートユーザー」にアクセスし、AWS アカウントを保護するためのベストプラクティスに従ってください。

— seb

原文はこちらです。

Amazon Web Services ブログ

AWS Organizations を使用するお客様のためのルートアクセスの一元管理

お役立ちリンク

フォローお願いいたします