type
status
date
slug
summary
tags
category
icon
password
理論
1. AWS OrganizationsとSCP(サービスコントロールポリシー)
- AWS Organizationsは複数のAWSアカウントを一元的に管理するサービスで、アカウントを組織単位(OU)で整理し、ポリシーを適用できます。
- *サービスコントロールポリシー(SCP)**は、AWS Organizations内でアクセス権限を制御するためのポリシーで、アカウントごとの許可や拒否を管理します。これにより、組織全体や特定のOUに対して特定のサービスや操作を制限できます。
- 例えば、「全てのサービスに対するアクセスを許可し、一部のサービスは拒否」といったポリシー設定が可能です。
2. IAM(Identity and Access Management)とアクセスアドバイザー
- *IAM(Identity and Access Management)**は、AWSリソースへのアクセスを管理するサービスです。IAMユーザー、グループ、ロール、ポリシーを使用して、リソースへのアクセス権限を制御できます。
- IAM アクセスアドバイザーは、IAMポリシーを基にユーザーやロールが使用したサービスを分析し、実際にアクセスされたリソースを確認するツールです。これを使って、不要なサービスへのアクセスを制限するためのポリシーを見直すことができます。
3. 組織単位(OU)
- *組織単位(OU)**は、AWS Organizations内でアカウントをグループ化するための方法です。OUごとに異なるポリシーを適用することができ、例えば本番環境と開発環境で異なる制限を設定することが可能です。
- 各OUに適用するSCPによって、サービスへのアクセスやリソースの管理に柔軟に対応できます。
4. アクセス制御戦略(許可リスト vs 否定リスト)
- 許可リスト(ホワイトリスト)戦略では、特定のサービスへのアクセスのみを許可し、それ以外はデフォルトで制限します。これにより、利用しないサービスに対して不必要なアクセスを防ぐことができます。
- 否定リスト(ブラックリスト)戦略では、アクセスを明示的に拒否したいサービスを定義し、それ以外は基本的に許可します。特定のサービスのみを制限するのに効果的です。
5. Trusted Advisor vs Access Advisor
- AWS Trusted Advisorは、AWSアカウントの設定やリソースに対する最適化、コスト削減、セキュリティのベストプラクティスを提案しますが、特定のサービスが「使用されているかどうか」を直接追跡するツールではありません。
- IAMアクセスアドバイザーは、ユーザーやロールが実際にどのAWSサービスを使用したかを追跡するため、アクセス制限をかける上で有用な情報源です。
結論
- AWS OrganizationsとSCPを利用して、複数のAWSアカウント間でアクセス制御を中央で管理することができます。IAMと組み合わせることで、さらに精緻なアクセス管理が可能です。
- アクセスアドバイザーを使って、実際に使用されているサービスを把握し、不要なサービスへのアクセスを制限するポリシー設定を行うことができます。
実践
略
一問道場
問題 #373
ある会社は複数の AWS アカウントを使用しており、複数の DevOps チームがこれらのアカウントで本番環境および非本番環境のワークロードを実行しています。
その会社は、DevOps チームが使用していないいくつかの AWS サービスへのアクセスを中央で制限したいと考えています。会社は AWS Organizations を使用し、すべての AWS アカウントを正常に組織に招待しました。現在使用中のサービスへのアクセスを許可し、いくつかの特定のサービスを拒否したいと考えています。また、複数のアカウントを単一のユニットとして管理したいと考えています。
ソリューションアーキテクトは、この要件を満たすためにどの組み合わせの手順を取るべきでしょうか?(3つ選択してください。)
A. 否定リスト戦略を使用する。
B. AWS IAM のアクセスアドバイザーを確認して、最近使用されたサービスを確認する。
C. AWS Trusted Advisor レポートを確認して、最近使用されたサービスを確認する。
D. デフォルトの FullAWSAccess SCP を削除する。
E. 組織単位(OU)を定義し、メンバーアカウントを OU に配置する。
F. デフォルトの DenyAWSAccess SCP を削除する。
解説
正解:
A. 否定リスト戦略を使用する。
- 否定リスト戦略では、許可したいサービスを「許可リスト」として設定せず、アクセスを明示的に拒否することで、DevOps チームが使わないサービスへのアクセスを制限します。この方法は、必要なサービスだけにアクセスを許可し、その他のサービスを制限するために有効です。
B. AWS IAM のアクセスアドバイザーを確認して、最近使用されたサービスを確認する。
- IAM アクセスアドバイザーを使用すると、各ユーザーやロールが最近使用した AWS サービスを確認できます。この情報を基に、使用されていないサービスを特定し、それらのサービスに対するアクセスを制限するための戦略を立てることができます。
E. 組織単位(OU)を定義し、メンバーアカウントを OU に配置する。
- AWS Organizations では、組織単位(OU)を使ってアカウントをグループ化できます。これにより、異なるアクセス制限ポリシーを組織単位ごとに設定することが可能です。例えば、本番環境と非本番環境を別々の OU に分け、それぞれに適切なポリシーを適用することができます。
解説:
- A: 否定リスト戦略を使用することで、使用しないサービスへのアクセスを制限し、必要なサービスのみを許可できます。
- B: IAM アクセスアドバイザーを利用して、現在使用されているサービスを確認し、不要なサービスを制限できます。
- E: 組織単位(OU)を使って、異なるポリシーを適用できるようにすることで、より細かい管理が可能になります。
不正解:
C. AWS Trusted Advisor レポートを確認して、最近使用されたサービスを確認する。
- Trusted Advisor は主にリソースの最適化やコスト削減を目的としたアドバイスを提供しますが、サービスの使用履歴に基づくアクセス制限のためには適していません。
D. デフォルトの FullAWSAccess SCP を削除する。
- デフォルトで適用されている
FullAWSAccess
ポリシーを削除するのは有効ですが、アクセス制限のためには、具体的にサービスを制限する SCP(サービスコントロールポリシー)を作成する必要があります。
F. デフォルトの DenyAWSAccess SCP を削除する。
DenyAWSAccess
というポリシーは存在しません。正しいポリシー名や設定が必要です。
まとめ
最適な選択肢は「A」「B」「E」です。これらのステップを踏むことで、適切にアクセス制限を行い、DevOps チームが使用しないサービスを中央で制御できます。
- 作者:みなみ
- 链接:https://tangly1024.com/資格勉強/178d7ae8-88e2-806e-8a85-c66baf8c42f8
- 声明:本文采用 CC BY-NC-SA 4.0 许可协议,转载请注明出处。
相关文章