type
status
date
slug
summary
tags
category
icon
password

理論

1. AWS Marketplaceの管理

  • Private Marketplace: 企業が事前に承認したサードパーティ製品のみを利用できるように制限するための仕組み。これにより、企業はセキュリティとコスト管理の面でリスクを軽減できる。
  • 管理者権限: Private Marketplaceの設定やソフトウェア購入に関する管理は、特定のユーザーや役割に制限する必要がある。これにより、誤った購入や非承認のソフトウェアの利用を防ぐ。

2. IAM(Identity and Access Management)と役割

  • IAMロール: 特定の役割に対してアクセス権限を与えるための設定。例えば、procurement-manager-roleというIAMロールを使って、調達管理者がMarketplaceの管理を行えるようにする。
  • インラインポリシー: IAMロールに直接追加するポリシーで、特定の操作を許可または拒否する。組織内の他のユーザーや役割には、Marketplaceの管理アクセスを拒否するインラインポリシーを適用することが推奨される。

3. サービスコントロールポリシー(SCP)

  • SCP: AWS Organizations内のアカウントに対して、アクセス権限を制御するためのポリシー。SCPは、特定の操作を組織全体または特定の組織単位(OU)に対して許可または拒否することができる。
  • SCPの利用: Private Marketplaceに関する管理権限を制限するため、SCPを使用して、procurement-manager-role以外のユーザーに対する管理権限を拒否することができる。これにより、アクセス権限を一元管理し、リスクを軽減する。

4. アクセス制御と最小権限の原則

  • 最小権限の原則: 各ユーザーや役割に必要最低限のアクセス権を付与することで、セキュリティリスクを減らす。この原則に基づき、開発者や他の社員には、ソフトウェアの選定や購入を行う権限を与えず、あらかじめ承認されたリストからのみ利用を許可する。
  • 権限の境界: AWSPrivateMarketplaceAdminFullAccessなどの管理権限を、特定の役割やユーザーに制限するために、権限の境界を設定することが推奨される。

結論

企業がAWS Marketplaceでサードパーティソフトウェアを管理する際には、IAMロール、インラインポリシー、SCPを効果的に組み合わせて、アクセス権限を厳格に管理することが重要です。最小権限の原則に従い、必要なユーザーだけに管理権限を与えることで、セキュリティと運用の効率性を向上させることができます。
 

実践

参照元:
 
 

一問道場

エンタープライズ企業がAWS Marketplaceでサードパーティソフトウェアを購入する要件

あるエンタープライズ企業では、開発者がAWS Marketplaceを通じてサードパーティソフトウェアを購入できるようにしたいと考えています。この企業は、AWS Organizationsのアカウント構造を利用しており、フル機能が有効化されています。また、各組織単位(OU)には、調達管理者が使用する共有サービスアカウントがあります。

要件:

  • 調達チームの方針
    • 開発者は、承認されたリストからのみソフトウェアを取得可能にする必要があります。
    • Private Marketplaceを使用してこの要件を実現します。
  • 管理の制限
    • Private Marketplaceの管理は、調達管理者が引き受けるprocurement-manager-roleというロールに限定します。
    • 他のIAMユーザー、グループ、ロール、およびアカウント管理者は、Private Marketplaceの管理アクセスを拒否されるべきです。

最も効率的な設計方法を選ぶ選択肢

A.
すべてのAWSアカウントにprocurement-manager-roleというIAMロールを作成する。
このロールにPowerUserAccessのマネージドポリシーを追加する。
さらに、すべてのIAMユーザーとロールに対して、インラインポリシーを適用してAWSPrivateMarketplaceAdminFullAccessのマネージドポリシーに関する権限を拒否する。

B.
すべてのAWSアカウントにprocurement-manager-roleというIAMロールを作成する。
このロールにAdministratorAccessのマネージドポリシーを追加する。
その上で、AWSPrivateMarketplaceAdminFullAccessマネージドポリシーを使用して権限境界を定義し、すべての開発者ロールに適用する。

C.
すべての共有サービスアカウントにprocurement-manager-roleというIAMロールを作成する。
このロールにAWSPrivateMarketplaceAdminFullAccessのマネージドポリシーを追加する。
OrganizationsのルートレベルでSCP(サービスコントロールポリシー)を作成し、次のことを行う:
  1. procurement-manager-role以外のすべてのユーザーに対して、Private Marketplaceの管理権限を拒否する。
  1. 組織内のすべてのユーザーに対して、procurement-manager-roleの作成を拒否する。

D.
開発者が使用するすべてのAWSアカウントにprocurement-manager-roleというIAMロールを作成する。
このロールにAWSPrivateMarketplaceAdminFullAccessのマネージドポリシーを追加する。
OrganizationsでSCPを作成し、次のことを行う:
  1. procurement-manager-role以外のすべてのユーザーに対して、Private Marketplaceの管理権限を拒否する。
  1. このSCPを組織内のすべての共有サービスアカウントに適用する。
 

問題の解説

この問題では、企業が AWS Marketplace の機能を活用して開発者がサードパーティソフトウェアを購入できるようにしたいという要件があります。しかし、同時に次のような制約が課されています:

要件の整理

  1. 開発者が購入できるのは承認済みのソフトウェアのみ
      • Private Marketplace を利用して、承認済みのソフトウェアのみをリストアップします。
  1. Private Marketplaceの管理者権限の制限
      • 管理権限を procurement-manager-role に限定し、他のIAMユーザー、グループ、ロール、またはアカウント管理者にはアクセスを禁止します。
  1. 効率的な管理が求められる
      • AWS Organizations構造を活用し、すべてのアカウントに効率的にポリシーを適用します。

選択肢の比較

選択肢 A

  • IAMロールをすべてのアカウントに作成し、PowerUserAccess ポリシーを付与。
  • IAMユーザーやロールにインラインポリシーを適用し、AWSPrivateMarketplaceAdminFullAccess を禁止。
問題点:
  • IAMユーザーやロールごとにインラインポリシーを適用する必要があり、スケーラビリティが低い。
  • 非効率で管理が複雑。

選択肢 B

  • すべてのアカウントにIAMロールを作成し、AdministratorAccess ポリシーを付与。
  • 開発者ロールに対して、AWSPrivateMarketplaceAdminFullAccess を制限するための境界ポリシーを設定。
問題点:
  • 開発者に関係のないAdministratorAccessを全アカウントで付与するのはセキュリティ上のリスク。
  • 設定が複雑になりやすい。

選択肢 C (正解)

  • 共有サービスアカウントprocurement-manager-roleを作成。
    • AWSPrivateMarketplaceAdminFullAccess ポリシーを付与。
  • AWS Organizationsで、次のSCP(Service Control Policy)を定義:
      1. procurement-manager-role以外にはPrivate Marketplace管理権限を付与しないポリシー。
      1. 他のユーザーがprocurement-manager-roleを作成する権限を禁止するポリシー。
理由:
  • SCPを利用することで、ポリシー適用を組織全体で一元管理可能。
  • procurement-manager-roleの管理権限を制限でき、他のIAMユーザーやロールに管理権限を与えないよう確実に制御できる。

選択肢 D

  • 開発者が利用するすべてのアカウントにprocurement-manager-roleを作成。
  • AWSPrivateMarketplaceAdminFullAccess を付与。
  • SCPを用いて管理権限をロールに限定し、共有サービスアカウントに適用。
問題点:
  • procurement-manager-role をすべてのアカウントに作成する手間がかかる。
  • 管理が煩雑で、共有サービスアカウントで一元管理するメリットを活用できていない。

結論

最も効率的かつセキュアな方法は 選択肢 C です。この方法では、次のような利点があります:
  1. 管理の効率化: procurement-manager-role を共有サービスアカウントに限定し、一元管理可能。
  1. セキュリティの強化: SCPによる組織全体の制御で、意図しない権限の付与を防止。
  1. スケーラビリティ: 全アカウントでポリシーを一括適用可能。
相关文章
クラウド技術の共有 | AWS Site-to-Site
Lazy loaded image
EKSでのWordPressデプロイ:KCNA-JP試験対策 (Kubernetes実践編)
Lazy loaded image
初心者向け!コンテナ化WordPressサイト構築ガイド(超詳細版)
Lazy loaded image
EFSを活用!AWS EC2でDockerを使ったWordPressサイト構築
Lazy loaded image
529-AWS SAP AWS 「理論・実践・一問道場」VPCエンドポイント
Lazy loaded image
528-AWS SAP AWS 「理論・実践・一問道場」Migration Evaluator
Lazy loaded image
032-AWS SAP AWS 「理論・実践・一問道場」SCP030-AWS SAP AWS 「理論・実践・一問道場」RAMで複数アカウントでの Transit Gateway
Loading...
みなみ
みなみ
一个普通的干饭人🍚
最新发布
02-生成AIパスポート試験対策:第2章「生成AI」
2025-2-1
01-生成AIパスポート試験対策:第1章「人口知能」
2025-2-1
究極のAWS認定 AI 実践者 AIF-C01 - 学習メモ
2025-1-27
不要再傻傻的直接买NISA啦
2025-1-27
Kubernetes、仮想マシンとコンテナの概念を超簡単に解説!
2025-1-24
529-AWS SAP AWS 「理論・実践・一問道場」VPCエンドポイント
2025-1-22
公告
🎉欢迎访问我的博客🎉
- 感谢您的支持 --
本站点于2024/09/01建立
👏主要分享IT相关主题👏
系统管理:
Redhat…
容器和编排:
Kubernetes、Openshift…
云计算:
AWS、IBM…
AI入门
以及技术笔记和考证经验
定期更新,欢迎互动。
感谢访问!
快速浏览相关标签