翻訳は機械翻訳により提供されています。提供された翻訳内容と英語版の間で齟齬、不一致または矛盾がある場合、英語版が優先します。
# マルチアカウントアーキテクチャのアクセス許可とアクセスの管理
**Topics**
+ [エンジニアリング文化の考慮事項](engineering-cultural-considerations.md)
+ [許可セットの作成](creating-permission-sets.md)
+ [アクセス許可の境界の作成](creating-a-permissions-boundary.md)
+ [個人へのアクセス許可の管理](managing-permissions-for-individuals.md)
# エンジニアリング文化の考慮事項
AWS Well-Architected フレームワークの柱の 1 つは運用上の優秀性です。チームは[運用モデル](https://docs.aws.amazon.com/wellarchitected/latest/operational-excellence-pillar/operating-model.html)と、ビジネス成果を達成する上での各自の役割を理解している必要があります。各自の責任を理解していて、所有権を持つことができ、意思決定の方法を知っていれば、チームは共通の目標の達成に集中できます。
成長が早い初期段階の企業では、チームの全員が複数の役割を果たします。ユーザーが AWS アカウント全体に対して非常に特権的なアクセス権を持っていることは珍しくありません。企業が成長するにつれて、最小特権の原則に従い、ユーザーが仕事を遂行するのに必要な権限のみを付与することがよくあります。範囲の制限には、[AWS Identity and Access Management Access Analyzer](https://docs.aws.amazon.com/IAM/latest/UserGuide/what-is-access-analyzer.html) を使用してユーザーまたは IAM ロールが実際に使用しているアクセス権限を確認し、過度な権限を削除できます。
社内の誰に IAM ロールを作成する権限を持たせるかを判断するのは難しい場合があります。IAM ロールの作成は通常、権限を昇格させる手段です。権限昇格とは、ユーザーが自分の権限やアクセス範囲を拡大するときのことです。例えば、権限が制限されたユーザーが新しい IAM ロールを作成できる場合、そのユーザーは、`AdministratorAccess` 管理ポリシーが適用された新しい IAM ロールを作成して引き受けることで、権限を昇格させることができます。
企業によっては、IAM ロールのプロビジョニングを、信頼できる個人を集めたチームに限定しています。このアプローチの欠点は、ほとんどすべてが運用に IAM ロール AWS のサービス を必要とするため、このチームがすぐにボトルネックになる可能性があることです。別の方法として、[アクセス許可の境界](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_boundaries.html)を使用して、クラウドインフラストラクチャの開発、テスト、起動、管理を行うユーザーのみに IAM アクセスを委任する方法があります。ポリシーの例については、「[Example Permission Boundaries](https://github.com/aws-samples/example-permissions-boundary)」(GitHub) を参照してください。
プラットフォームチームとも呼ばれる開発運用 (DevOps) チームでは、多くの場合、複数の社内開発チームのセルフサービス機能とアプリケーション運用の安定性とのバランスを取る必要があります。職場における自主性、習得、目的を重視するエンジニアリング文化を育むことで、チームのモチベーションを向上させることができます。エンジニアは、他の人に頼ることなく、自主独立して仕事をすることを望んでいます。DevOps チームがセルフサービスソリューションを実装できれば、物事を済ませる際に他のチームが DevOps チームに頼る時間も短縮されます。
# 許可セットの作成
のアクセス[許可セット](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html)を使用して AWS アカウント アクセスを管理できます AWS IAM アイデンティティセンター。許可セットとは、IAM ポリシーを 1 つ以上、複数の AWS アカウントにデプロイすることができるテンプレートのことです。許可セットを AWS アカウントに割り当てると、IAM アイデンティティセンターが IAM ロールを作成し、IAM ポリシーをそのロールにアタッチします。詳細については、「[Create and manage permission sets](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsets.html)」(IAM アイデンティティセンターのドキュメント) を参照してください。
AWS では、ビジネス内のさまざまなペルソナにマッピングするアクセス許可セットを作成することをお勧めします。
**Topics**
+ [請求に対する許可セット](#billing-permission-set)
+ [開発者許可セット](#developer-permission-set)
+ [本番稼働用許可セット](#production-permission-set)
次のアクセス許可セットは、 AWS CloudFormation テンプレートからのスニペットです。このコードを開始点として使用し、ビジネスに合わせてカスタマイズしてください。CloudFormation テンプレートの詳細については、「[Learn template basics](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/gettingstarted.templatebasics.html)」(CloudFormation ドキュメント) を参照してください。
## 請求に対する許可セット
財務チームは **BillingAccessPermissionSet** を使用して、各アカウントの AWS Billing コンソールダッシュボードと AWS Cost Explorer を表示します。
```
BillingAccessPermissionSet:
Type: "AWS::SSO::PermissionSet"
Properties:
Description: Access to Billing and Cost Explorer
InstanceArn: !Sub "arn:${AWS::Partition}:sso:::instance/ssoins-instanceId"
ManagedPolicies:
- !Sub "arn:${AWS::Partition}:iam::aws:policy/job-function/Billing"
Name: BillingAccess
SessionDuration: PT8H
RelayStateType: https://console.aws.amazon.com/billing/home
```
## 開発者許可セット
エンジニアリングチームは、**DeveloperAccessPermissionSet** を使用して非本番稼働用アカウントにアクセスできます。
```
DeveloperAccessPermissionSet:
Type: "AWS::SSO::PermissionSet"
Properties:
Description: Access to provision resources through CloudFormation
InlinePolicy: !Sub |-
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:${AWS::Partition}:iam::*:role/CloudFormationRole",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "${!aws:PrincipalAccount}",
"iam:PassedToService": "cloudformation.${AWS::URLSuffix}"
}
}
},
{
"Effect": "Allow",
"Action": [
"cloudformation:ContinueUpdateRollback",
"cloudformation:CreateChangeSet",
"cloudformation:CreateStack",
"cloudformation:DeleteStack",
"cloudformation:RollbackStack",
"cloudformation:UpdateStack"
],
"Resource": "arn:${AWS::Partition}:cloudformation:*:*:stack/app-*",
"Condition": {
"ArnLike": {
"cloudformation:RoleArn": "arn:${AWS::Partition}:iam::${!aws:PrincipalAccount}:role/CloudFormationRole"
},
"Null": {
"cloudformation:ImportResourceTypes": true
}
}
},
{
"Effect": "Allow",
"Action": [
"cloudformation:CancelUpdateStack",
"cloudformation:DeleteChangeSet",
"cloudformation:DetectStackDrift",
"cloudformation:DetectStackResourceDrift",
"cloudformation:ExecuteChangeSet",
"cloudformation:TagResource",
"cloudformation:UntagResource",
"cloudformation:UpdateTerminationProtection"
],
"Resource": "arn:${AWS::Partition}:cloudformation:*:*:stack/app-*"
},
{
"Effect": "Allow",
"Action": [
"cloudformation:CreateUploadBucket",
"cloudformation:ValidateTemplate",
"cloudformation:EstimateTemplateCost"
],
"Resource": "*"
}
]
}
InstanceArn: !Sub "arn:${AWS::Partition}:sso:::instance/ssoins-instanceId"
ManagedPolicies:
- !Sub "arn:${AWS::Partition}:iam::aws:policy/AWSServiceCatalogEndUserFullAccess"
- !Sub "arn:${AWS::Partition}:iam::aws:policy/AWSBillingReadOnlyAccess"
- !Sub "arn:${AWS::Partition}:iam::aws:policy/AWSSupportAccess"
- !Sub "arn:${AWS::Partition}:iam::aws:policy/ReadOnlyAccess"
Name: DeveloperAccess
SessionDuration: PT8H
```
## 本番稼働用許可セット
エンジニアリングチームは、**ProductionPermissionSet** を使用して、本番稼働用アカウントにアクセスできます。この許可セットには制限があり、閲覧のみのアクセス権しかありません。
```
ProductionPermissionSet:
Type: "AWS::SSO::PermissionSet"
Properties:
Description: Access to production accounts
InlinePolicy: !Sub |-
{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": "iam:PassRole",
"Resource": "arn:${AWS::Partition}:iam::*:role/CloudFormationRole",
"Condition": {
"StringEquals": {
"aws:ResourceAccount": "${!aws:PrincipalAccount}",
"iam:PassedToService": "cloudformation.${AWS::URLSuffix}"
}
}
},
{
"Effect": "Allow",
"Action": "cloudformation:ContinueUpdateRollback",
"Resource": "arn:${AWS::Partition}:cloudformation:*:*:stack/app-*",
"Condition": {
"ArnLike": {
"cloudformation:RoleArn": "arn:${AWS::Partition}:iam::${!aws:PrincipalAccount}:role/CloudFormationRole"
}
}
},
{
"Effect": "Allow",
"Action": "cloudformation:CancelUpdateStack",
"Resource": "arn:${AWS::Partition}:cloudformation:*:*:stack/app-*"
}
]
}
InstanceArn: !Sub "arn:${AWS::Partition}:sso:::instance/ssoins-instanceId"
ManagedPolicies:
- !Sub "arn:${AWS::Partition}:iam::aws:policy/AWSBillingReadOnlyAccess"
- !Sub "arn:${AWS::Partition}:iam::aws:policy/AWSSupportAccess"
- !Sub "arn:${AWS::Partition}:iam::aws:policy/job-function/ViewOnlyAccess"
Name: ProductionAccess
SessionDuration: PT2H
```
# アクセス許可の境界の作成
許可セットをデプロイしたら、アクセス許可の境界を設定します。このアクセス許可の境界とは、クラウドインフラストラクチャを開発、テスト、起動、管理しているユーザーのみに IAM アクセスを委任するメカニズムのことです。これらのユーザーは、ポリシーとアクセス許可の境界で許可されているアクションのみを実行できます。
AWS CloudFormation テンプレートでアクセス許可の境界を定義し、CloudFormation StackSets を使用してテンプレートを複数のアカウントにデプロイできます。これにより、1 回の操作で組織全体に標準化されたポリシーを確立して維持できます。詳細については、「[Working with AWS CloudFormation StackSets](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/what-is-cfnstacksets.html)」(CloudFormation ドキュメント) を参照してください。
次の CloudFormation テンプレートは、IAM ロールをプロビジョニングし、アクセス許可の境界として機能する IAM ポリシーを作成します。スタックセットを使用すると、このテンプレートを組織内のすべてのメンバーアカウントにデプロイできます。
```
CloudFormationRole:
Type: "AWS::IAM::Role"
Properties:
AssumeRolePolicyDocument:
Version: "2012-10-17"
Statement:
Effect: Allow
Principal:
Service: !Sub "cloudformation.${AWS::URLSuffix}"
Action: "sts:AssumeRole"
Condition:
StringEquals:
"aws:SourceAccount": !Ref "AWS::AccountId"
Description: !Sub "DO NOT DELETE - Used by CloudFormation. Created by CloudFormation ${AWS::StackId}"
ManagedPolicyArns:
- !Sub "arn:${AWS::Partition}:iam::aws:policy/AdministratorAccess"
PermissionsBoundary: !Ref DeveloperBoundary
RoleName: CloudFormationRole
DeveloperBoundary:
Type: "AWS::IAM::ManagedPolicy"
Properties:
Description: Permission boundary for developers
ManagedPolicyName: PermissionsBoundary
PolicyDocument:
Version: "2012-10-17"
Statement:
- Sid: AllowModifyIamRolesWithBoundary
Effect: Allow
Action:
- "iam:AttachRolePolicy"
- "iam:CreateRole"
- "iam:DeleteRolePolicy"
- "iam:DetachRolePolicy"
- "iam:PutRolePermissionsBoundary"
- "iam:PutRolePolicy"
Resource: !Sub "arn:${AWS::Partition}:iam::${AWS::AccountId}:role/app/*"
Condition:
ArnEquals:
"iam:PermissionsBoundary": !Sub "arn:${AWS::Partition}:iam::${AWS::AccountId}:policy/PermissionsBoundary"
- Sid: AllowModifyIamRoles
Effect: Allow
Action:
- "iam:DeleteRole"
- "iam:TagRole"
- "iam:UntagRole"
- "iam:UpdateAssumeRolePolicy"
- "iam:UpdateRole"
- "iam:UpdateRoleDescription"
Resource: !Sub "arn:${AWS::Partition}:iam::${AWS::AccountId}:role/app/*"
- Sid: OverlyPermissiveAllowedServices
Effect: Allow
Action:
- "lambda:*"
- "apigateway:*"
- "events:*"
- "s3:*"
- "logs:*"
Resource: "*"
```
**CloudFormationRole** ロール、**PermissionsBoundary** ポリシー、**DeveloperAccess** 許可セットが連携して次の権限を付与します。
+ ユーザーは、**ReadOnlyAccess** AWS 管理ポリシーを通じて AWS のサービス、ほとんどの への読み取り専用アクセス権を持ちます。
+ ユーザーは、**AWSSupportAccess** AWS 管理ポリシーを通じて、オープンサポートケースにアクセスできます。
+ ユーザーは、**AWSBillingReadOnlyAccess** AWS 管理ポリシーを通じて、 AWS Billing コンソールダッシュボードに読み取り専用でアクセスできます。
+ ユーザーは、**AWSServiceCatalogEndUserFullAccess** AWS 管理ポリシーを通じて、Service Catalog から製品をプロビジョニングできます。
+ インラインポリシーによって、CloudFormation テンプレートのコストをどれでも検証して見積もることができます。
+ **CloudFormationRole** IAM ロールを使用することで、ユーザーは、**app/** で始まる CloudFormation スタックを作成、更新、削除できます。
+ CloudFormation を使用して、ユーザーは **app/** で始まる IAM ロールを作成、更新、削除できます。**PermissionsBoundary** IAM ポリシーは、ユーザーが権限を昇格することを防ぎます。
+ ユーザーは AWS Lambda、CloudFormation を使用してのみ、、Amazon EventBridge、Amazon CloudWatch、Amazon Simple Storage Service (Amazon S3)、および Amazon API Gateway リソースをプロビジョニングできます。
次の画像は、開発者などの権限を持つユーザーが、このガイドで説明されている許可セット、IAM ロール、アクセス許可の境界を使用してメンバーアカウントに新しい IAM ロールを作成する方法を示しています。
1. ユーザーは IAM アイデンティティセンターで認証を行い、**DeveloperAccess** IAM ロールを引き受けます。
1. ユーザーが `cloudformation:CreateStack` アクションを実行し、**CloudFormationRole** のIAM ロールを引き受けます。
1. ユーザーが `iam:CreateRole` アクションを実行し、CloudFormation を使用して新しい IAM ロールを作成します。
1. **PermissionsBoundary** のIAM ポリシーが新しい IAM ロールに適用されます。
![\[メンバーアカウントのアクセス許可の境界の対象となる IAM ロールを作成するユーザー\]](http://docs.aws.amazon.com/ja_jp/prescriptive-guidance/latest/transitioning-to-multiple-aws-accounts/images/2_create-iam-role.png)
**CloudFormationRole** のロールには[AdministratorAccess](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies_job-functions.html#jf_administrator) 管理ポリシーがアタッチされていますが、**PermissionsBoundary** IAM ポリシーにより **CloudFormationRole** のロールの有効な許可は **PermissionsBoundary** ポリシーと同じになります。**PermissionsBoundary** ポリシーは、`iam:CreateRole` アクションの許可時に自身のポリシーを参照します。これにより、アクセス許可の境界が適用されている場合にのみロールを作成できます。
# 個人へのアクセス許可の管理
許可セット、アクセス許可の境界、**CloudFormationRole** のIAM ロールを使用することで、個々のプリンシパルに直接割り当てる必要があるアクセス許可の量を制限できます。これにより、会社の成長に合わせてアクセスを管理し、最小特権を付与するというセキュリティのベストプラクティスを適用できます。
サービスにリンクされたロールを使用することもできます。これは、ユーザーに代わってリソースをプロビジョニングする権限を AWS サービスに付与するものです。IAM プリンシパル (ユーザー、ユーザーグループ、ロール) にアクセス権限を付与する代わりに、サービスにアクセス権限を付与できます。たとえば、 のサービスにリンクされたロール[AWS Service Catalog](https://docs.aws.amazon.com/servicecatalog/latest/adminguide/introduction.html)を使用すると、IAM プリンシパルにアクセス許可を割り当てることなく、独自のテンプレート、リソース、環境をプロビジョニングできます。詳細については、「[IAM と連携するAWS のサービス](https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_aws-services-that-work-with-iam.html)」および「[サービスリンクロールの使用](https://docs.aws.amazon.com/IAM/latest/UserGuide/using-service-linked-roles.html)」(IAM ドキュメント) を参照してください。
別のベストプラクティスは、個人の AWS マネジメントコンソールへアクセスできる量を制限することです。コンソールへのアクセスを制限することで、[AWS CloudFormation](https://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/Welcome.html)、[HashiCorp Terraform](https://www.terraform.io/)、[Pulumi](https://www.pulumi.com/) などの Infrastructure as Code (IaC) 技術を使用してリソースをプロビジョニングするよう個人に要求することができます。IaC によるインフラストラクチャの管理では、時間の経過に伴うリソースの変化を追跡し、GitHub のプルリクエストなどの変更を承認するメカニズムを導入できます。