508-AWS SAP AWS 「理論・実践・一問道場」AWS Service Catalog

type

status

date

slug

summary

理論

AWSを使用した安全な環境立ち上げに関するポイント

AWS環境で複数のユーザーや部門が関与する場合、適切な権限管理と効率的なプロビジョニングが重要です。以下は、関連する汎用的な知識を簡潔にまとめたものです。

1. 最小権限の原則（Principle of Least Privilege）

各ユーザーや役割（IAMロール）には、必要最小限の権限のみを付与する。

直接的なAPIやリソース操作を避け、制御された手段（例: AWS Service Catalog）を提供することでリスクを低減。

2. AWS Service Catalogの活用

概要: 管理者が事前に承認済みのリソースセット（CloudFormationテンプレートなど）をカタログ化し、ユーザーに提供。

利点:

起動制約を適用し、リソース作成時に指定のロールを使用させる。
環境の標準化と管理の簡素化。
ユーザーはAWS Service CatalogコンソールまたはCLIから安全に環境を立ち上げ可能。

3. AWS CloudFormationの活用

概要: インフラをコードとして管理し、リソースの構築・更新・削除を自動化。

利点:

再現性のある環境構築が可能。
IAMポリシーを使用して、特定のテンプレートとその作成リソースに限定的なアクセスを許可可能。

4. IAMロールの引き受け（Role Assumption）

概要: 特定の操作を行う際、一時的に権限を付与するロールを引き受ける仕組み。

利点:

必要なときだけ権限を有効化できる。
ロールを細かく制御することでセキュリティを強化。

5. AWS Elastic Beanstalkの利用（必要に応じて）

概要: Webアプリケーションやサービスを簡単にデプロイできるプラットフォーム。

利点:

アプリケーションのデプロイと運用を簡素化。

注意点: 汎用性が低く、既存のCloudFormationテンプレートを利用する場合には適さない場合がある。

6. セキュリティと管理のベストプラクティス

タグ付け: 各リソースにタグを付与して、監視やコスト管理を容易にする。

CloudTrailの利用: リソースやAPI操作の追跡を有効化し、監査ログを取得。

予算制限の設定: AWS Budgetsを活用して、利用コストを管理。

まとめ

AWS Service Catalogは、制御された環境立ち上げに最適であり、最小権限の原則を確保しやすい。

IAMロールやCloudFormationテンプレートを正しく設計することで、ユーザーが安全に環境を操作できる。

実践

略

一問道場

質問 #508

ある企業がアプリケーションを使用しており、このアプリケーションはAuto Scalingグループ内のAmazon EC2インスタンスを利用しています。品質保証（QA）部門では、大量の短期間の環境を立ち上げてアプリケーションをテストする必要があります。現在、アプリケーション環境はAWS CloudFormationテンプレートを使用して部門マネージャーが立ち上げています。スタックを立ち上げるために、マネージャーはCloudFormation、EC2、Auto Scaling APIを使用する権限を持つロールを使用しています。

マネージャーはテスターが自分たちで環境を立ち上げられるようにしたいと考えていますが、各ユーザーに広範な権限を与えることは避けたいとしています。

この目標を達成するためには、どのセットアップが適していますか？

A. AWS CloudFormationテンプレートをAmazon S3にアップロードします。QA部門のユーザーに、マネージャーのロールを引き受ける権限を付与し、そのテンプレートとそれが作成するリソースへの権限のみを許可するポリシーを追加します。ユーザーにCloudFormationコンソールからテンプレートを起動する方法を教えます。

B. 環境テンプレートからAWS Service Catalog製品を作成します。この製品に既存のロールを使用した起動制約を追加します。QA部門のユーザーにAWS Service Catalog APIの使用権限のみを付与します。ユーザーにAWS Service Catalogコンソールからテンプレートを起動する方法を教えます。

C. AWS CloudFormationテンプレートをAmazon S3にアップロードします。QA部門のユーザーにCloudFormationおよびS3 APIの使用権限を付与しますが、その権限をテンプレートとそれが作成するリソースに制限する条件を設定します。ユーザーにCloudFormationコンソールからテンプレートを起動する方法を教えます。

D. 環境テンプレートからAWS Elastic Beanstalkアプリケーションを作成します。QA部門のユーザーにElastic Beanstalk権限のみを付与します。Elastic Beanstalk CLIを使用して既存のロールをサービスロールとして環境に渡し、Elastic Beanstalk環境を起動する方法をユーザーに教えます。

解説

このシナリオでは、以下のポイントが重要です：

QA部門のユーザーが自分たちで環境を立ち上げられること

広範な権限を各ユーザーに与えることを避けること

現行のAWS CloudFormationテンプレートを使用することを考慮

各選択肢を検討すると、適切な答えは B です。以下でその理由を解説します。

選択肢の分析

A. マネージャーのロールを引き受ける権限を付与する方法

メリット: CloudFormationテンプレートを再利用でき、現在のマネージャーのロールを活用できる。

デメリット: 各ユーザーがマネージャーのロールを引き受けることになるため、意図せず広範な権限を与えてしまう可能性がある。

結論: ユーザーに最小権限を提供するという目標に反する。

B. AWS Service Catalogを利用する方法

メリット:

Service Catalogはカタログ化された製品をユーザーに提供し、背後の複雑さを隠すことができる。
既存のロールを使用した起動制約を適用することで、ユーザーに広範な権限を与えず、制御された環境の立ち上げを可能にする。
使い方を制御しやすく、権限もService Catalogの操作に限定できる。

デメリット: Service Catalogのセットアップが必要。ただし、一度設定すれば運用が容易。

結論: 目標に最も適している。

C. CloudFormationとS3 APIを直接使用する方法

メリット: テンプレートを再利用できる。

デメリット: S3 APIやCloudFormation APIを直接操作する権限をユーザーに付与する必要があり、設定が複雑になる。

また、テンプレートと作成リソースへのアクセス制御を設定するのが難しくなる可能性がある。

結論: 権限を厳密に制御するのが難しいため、最適ではない。

D. AWS Elastic Beanstalkを利用する方法

メリット: Elastic Beanstalkはアプリケーションの管理を簡素化できる。

デメリット:

現在のAWS CloudFormationテンプレートをElastic Beanstalk用に変更する必要があり、大きな変更が必要。
Elastic Beanstalkの設定がCloudFormationテンプレートと比較して柔軟性が低い可能性がある。

結論: 現状の構成と大きく異なり、目標達成に最適ではない。

正解: B. AWS Service Catalogを利用する方法

理由:

AWS Service Catalogを使用すれば、マネージャーが既存のCloudFormationテンプレートをカタログ製品として設定し、ユーザーにそのテンプレートを簡単に立ち上げる手段を提供できます。また、起動制約を設定することで、ユーザーが広範な権限を持つことを防ぎつつ、必要なリソースの作成を適切に管理できます。

これにより、**セキュリティ要件（最小権限の原則）**を満たしつつ、ユーザーが自律的に環境を作成することが可能になります。